HTI-1 through HTI-4 & USCDI v3/v4 Implementation Guide

What is HTI-1?

The Health Data, Technology, and Interoperability (HTI-1) rule is an ONC final rule published in the Federal Register on January 9, 2024. It implements provisions of the 21st Century Cures Act and updates the ONC Health IT Certification Program with new standards, implementation specifications, and certification criteria. HTI-1 advances interoperability, improves transparency, and supports the access, exchange, and use of electronic health information (EHI).

Key Compliance Deadlines

• December 31, 2024: Health IT developers must update health IT currently certified to the prior CDS criterion (170.315(a)(9)) to meet the DSI criterion (170.315(b)(11)) and provide the updated certified health IT to customers.
• January 1, 2025: Maintenance of certification requirement (170.402(b)(4)) becomes effective. The DSI criterion becomes required for health care providers to meet the Base EHR definition and thus have "Certified EHR Technology" for certain CMS programs.
• January 1, 2026: USCDI v3 becomes the only USCDI version required within the ONC Health IT Certification Program (45 CFR 170.213).

Health IT developers must update certified Health IT Modules to all applicable revised certification criteria, provide updated modules to customers, and follow timeliness requirements specified in the rule.

HTI Rollout Schedule 2026–2027

Clean timeline of key deadlines for HTI rules and USCDI adoption:

HTI-1, HTI-2, HTI-3, HTI-4 Final Rules: Official Resources

The ONC Health IT Certification Program is updated through a series of HTI (Health Data, Technology, and Interoperability) Final Rules. Each rule addresses specific certification criteria, standards, and deadlines.

• HTI-1 Final Rule

  USCDI v3, DSI (algorithm transparency), information blocking revisions, Insights Condition. Effective March 11, 2024.

  HTI-1 Final Rule (HealthIT.gov) | Overview and Key Dates (PDF)
• HTI-2 Final Rule

  TEFCA-related provisions, information blocking amendments, 45 CFR Part 172. DSI criterion (b)(11) privacy and security updates due December 31, 2027.

  HTI-2 Final Rule (HealthIT.gov)
• HTI-3 Final Rule (Protecting Care Access)

  Information blocking regulatory enhancements, reproductive health care definition, Privacy Exception and Protecting Care Access Exception revisions.

  HTI-3 Final Rule (HealthIT.gov)
• HTI-4 Final Rule

  Electronic prescribing, real-time prescription benefit, electronic prior authorization. New criteria: RTPB (§170.315(b)(4)), provider prior authorization APIs (§170.315(g)(31)–(33)), workflow triggers for DSI clients (§170.315(j)(20)), subscriptions-client (§170.315(j)(21)). Electronic prescribing updates due December 31, 2027.

  HTI-4 Final Rule (HealthIT.gov) | Program Resources (HTI-4 Overview PDF)

Master reference: ONC Certification Criteria for Health IT by Regulatory Update Deadline: criteria, deadlines, and rule references in one table. Program Resources: fact sheets, overviews, and Certification Companion Guides. ONC Health IT Certification Program Overview (PDF): program structure, certification criteria, Conditions and Maintenance of Certification, surveillance, and Direct Review.

USCDI v3 Data Class Mapping

USCDI v3 was adopted as a standard at 45 CFR 170.213. It expands from USCDI v1's 52 data elements in 16 data classes to 94 data elements across 19 data classes. US Core 6.1.0 FHIR profiles are designed to implement USCDI v3 requirements.

USCDI v3 Data Classes

• Allergies and Intolerances
• Assessment and Plan of Treatment
• Care Team Members
• Clinical Notes
• Clinical Tests
• Diagnostic Imaging
• Encounter Information
• Goals
• Health Insurance Information
• Health Status/Assessments
• Immunizations
• Laboratory
• Medications
• Patient Demographics
• Procedures
• Problems
• Provenance
• Unique Device Identifiers
• Vital Signs

Implementation Best Practices

• Profile mapping: Map each USCDI data class to the corresponding US Core 6.1.0 profile. For example: Allergies → US Core AllergyIntolerance; Clinical Notes → US Core DocumentReference and DiagnosticReport; Encounter Information → US Core Encounter and Condition Encounter Diagnosis.
• Element validation: Ensure every required USCDI element is present and correctly populated in your FHIR resources. Missing or optional elements can cause certification failures.
• SDOH data: USCDI v3 adds SDOH (Social Determinants of Health) elements: Problems, Health Concerns, Assessment. Plan for SDOH Problems/Health Concerns and SDOH Assessment data capture and exchange.
• Health Status/Assessments: New elements include Health Concerns, Functional Status, Disability Status, Mental/Cognitive Status, Pregnancy Status, Smoking Status. Validate these are supported in your clinical workflows.

Reference: USCDI on the Interoperability Standards Platform | HL7 US Core Implementation Guide

USCDI v4 Support

USCDI v4 was released July 2023 and adds 20 new data elements and one new data class to advance equity, diversity, and access across healthcare settings. USCDI v3 is the version currently required for ONC certification (effective January 1, 2026). USCDI v4 adoption is expected in future rules; plan for v4 data elements when architecting new systems.

• Current requirement: USCDI v3 (45 CFR 170.213), required for certification as of Jan 1, 2026
• USCDI v4: Published; includes 20 new elements (e.g., equity, SDOH expansions). Plan for forward compatibility.
• US Core alignment: Map USCDI v3/v4 data classes to US Core 6.1.0+ FHIR profiles.

Reference: USCDI Versions (HealthIT.gov)

Algorithm Transparency (DSI Criterion 170.315(b)(11))

The HTI-1 rule adopts the Decision Support Interventions (DSI) certification criterion, replacing the prior CDS criterion (170.315(a)(9)). This is the first substantial revision to clinical decision support requirements since 2012. The DSI criterion establishes transparency requirements for both evidence-based DSIs and Predictive DSIs.

The 31 Predictive DSI source attributes create a consistent, industry-wide baseline upon which public-private collaboratives can build structured "model cards" and related initiatives. Over time, these attributes enable health care organizations and clinical users to assess whether their Predictive DSIs are fair, appropriate, valid, effective, and safe (FAVES).

Evidence-Based vs. Predictive DSIs

The DSI criterion requires different source attributes depending on the type of intervention:

• Evidence-based DSIs: 13 source attributes. Interventions grounded in published clinical evidence (e.g., guidelines, literature).
• Predictive DSIs: 31 source attributes. Technology that supports decision-making based on algorithms or models that derive relationships from training data and produce outputs for prediction, classification, recommendation, evaluation, or analysis.

Predictive DSIs include simple statistical models, machine learning algorithms, natural language processing, and large language models.

Developer Scope and Maintenance Requirements

Base EHR and Certified EHR Technology

Starting January 1, 2025, the DSI criterion is required for health care providers to have health IT that meets the Base EHR definition and thus qualifies as Certified EHR Technology for certain Centers for Medicare & Medicaid Services (CMS) programs.

The 31 Predictive DSI Source Attributes (9 Categories)

Health IT certified to the DSI criterion must support all 31 source attributes for each Predictive DSI. Use this as an implementation checklist:

1. 1. Details and output of the intervention
   • Name and contact information for the intervention developer
   • Funding source of the technical implementation for the intervention's development
   • Description of value that the intervention produces as an output
   • Whether the intervention output is a prediction, classification, recommendation, evaluation, analysis, or other type of output
2. 2. Purpose of the intervention
   • Intended use of the intervention
   • Intended patient population(s) for the intervention's use
   • Intended user(s)
   • Intended decision-making role (e.g., informs, augments, replaces clinical management)
3. 3. Cautioned out-of-scope use
   • Description of tasks, situations, or populations where a user is cautioned against applying the intervention
   • Known risks, inappropriate settings, inappropriate uses, or known limitations
4. 4. Intervention development details and input features
   • Exclusion and inclusion criteria that influenced the training data set
   • Use of variables (per paragraph (b)(11)(iv)(A)(5)-(13)) as input features
   • Description of demographic representativeness according to those variables, including at minimum those used as input features
   • Description of relevance of training data to intended deployed setting
5. 5. Process used to ensure fairness in development
   • Description of the approach to ensure the intervention's output is fair
   • Description of approaches to manage, reduce, or eliminate bias
6. 6. External validation process
   • Description of the data source, clinical setting, or environment where validity and fairness were assessed (other than training/testing data)
   • Party that conducted the external testing
   • Description of demographic representativeness of external data
   • Description of external validation process
7. 7. Quantitative measures of performance
   • Validity of intervention in test data derived from the same source as initial training data
   • Fairness of intervention in test data derived from the same source as initial training data
   • Validity of intervention in data external to or from a different source than initial training data
   • Fairness of intervention in data external to or from a different source than initial training data
   • References to evaluation of use of the intervention on outcomes (e.g., bibliographic citations or hyperlinks to evaluations of morbidity, mortality, length of stay, or other outcomes)
8. 8. Ongoing maintenance of intervention implementation and use
   • Description of process and frequency by which the intervention's validity is monitored over time
   • Validity of intervention in local data
   • Description of process and frequency by which the intervention's fairness is monitored over time
   • Fairness of intervention in local data
9. 9. Update and continued validation or fairness assessment schedule
   • Description of process and frequency by which the intervention is updated
   • Description of frequency by which the intervention's performance is corrected when risks related to validity and fairness are identified

Implementation Best Practices

• Attribute inventory: Create a manifest for each Predictive DSI with all 31 required attributes organized by the 9 categories above. Store in a machine-readable format (e.g., FHIR-based or structured JSON) that can be surfaced to clinical users.
• Risk management: Implement risk analysis, risk mitigation, and governance for Predictive DSIs. Document processes for ongoing monitoring, updates, and performance correction when validity or fairness risks are identified.
• Scope: Developers are responsible only for Predictive DSIs they supply as part of certified health IT, not third-party solutions.
• Evidence-based DSIs: If your certified health IT includes evidence-based DSIs, ensure you support the 13 source attributes required for those interventions. See the HTI-1 DSI Fact Sheet for the full list.

Reference: HTI-1 DSI Fact Sheet (PDF) | HTI-1 Final Rule

Anti-Information Blocking Validation

HTI-1 revises information blocking definitions and exceptions to support information sharing. Health IT developers must provide Assurances that they will not interfere with customers' timely access to interoperable health IT certified under the Program.

Information Blocking

Information blocking occurs when a practice is likely to interfere with the access, exchange, or use of electronic health information (EHI). Practices that meet the definition of information blocking are prohibited unless a regulatory exception applies.

Implementation Best Practices

• EHI access: Ensure your systems do not impose technical or contractual barriers that prevent or delay access to EHI. Validate that APIs, FHIR endpoints, and export capabilities support timely access.
• Conditions of Certification: Comply with the Assurances Condition. Document your practices and policies that demonstrate you do not interfere with access.
• FHIR support: Health IT certified under the Program must support FHIR-based exchange. Validate that your FHIR API implementation aligns with US Core 6.1.0 and USCDI v3.
• Testing: Conduct end-to-end testing of EHR/EMR integrations to ensure data flows are not blocked. Validate data acceptance and clinical workflows across vendor boundaries.

Reference: ONC Information Blocking

Who Is Affected?

HTI-1 applies to:

• Health IT developers who certify products under the ONC Health IT Certification Program
• HealthTech startups building EHR integrations, FHIR APIs, or clinical decision support
• Payers and providers who ingest or exchange data with certified systems
• Vendors whose products connect to certified systems

If your application connects to certified systems or you are pursuing certification, you must meet HTI-1 requirements.

Additional HTI-1 Provisions

• Insights Condition: Developers must report certain metrics (e.g., individual access, FHIR use, apps supported) as part of the Certification Program.
• TEFCA exception: A new exception encourages secure, standards-based exchange under the Trusted Exchange Framework and Common Agreement (TEFCA).

Need HTI-1 through HTI-4 & USCDI v3/v4 Audit Support?

I audit USCDI v3/v4 data class mapping, DSI algorithm transparency, and anti-information blocking validation for HealthTech companies. 15 years of clinical data engineering and zero-fail validation at scale.