The Startup MDVisit Website →
← Back to blog

U.S. Health IT Teams: HTI-1 6 Step Implementation Checklist

September 30, 2026
U.S. Health IT Teams: HTI-1 6 Step Implementation Checklist

HTI-1 is the ONC final rule that updates the certification program, mandates algorithm transparency through Decision Support Interventions, and creates the Insights Condition, which requires ongoing developer reporting. The two priorities that matter most operationally are DSI transparency and Insights Condition telemetry. USCDI Version 1 expires for certification purposes on January 1, 2026, and several DSI and API obligations are already in effect for developers.

TL;DR:

  • Developers must have comprehensive documentation and ongoing telemetry systems in place for Predictive Decision Support Interventions to comply with HTI-1's transparency requirements.
  • USCDI Version 3 will be the certification data standard baseline starting January 1, 2026, requiring updates to data models, vocabularies, and APIs before that date.
  • Certification updates will now occur incrementally rather than through large editions, making continuous commitment to compliance a core operational practice for vendors.
  • Organizations relying on TEFCA for data sharing must verify actual participation and document alternative fulfillment methods when responding to information requests.
  • Building structured, retrievable source-attribute documentation and telemetry infrastructure early is critical to meet the upcoming reporting deadlines and avoid costly retrofitting.
The StartupMD
Operationalize Your HTI-1 Readiness
The StartUp MD helps healthcare SaaS teams navigate growth challenges with tailored advisory and fractional consulting support.
Explore The StartUp MD

Table of Contents

What HTI-1 covers and why it matters

HTI-1 exists because the 21st Century Cures Act gave ONC authority to set Conditions and Maintenance of Certification for health IT, expand the EHR Reporting Program, and address information blocking. The rule uses that authority to move the certification program away from periodic "editions" and toward continuous, incremental updates. ONC calls this an edition-less approach, and it changes how vendors plan releases, not just what they build.

The policy goals behind HTI-1 are straightforward once you strip away the regulatory language. ONC wants health IT that exchanges information more reliably, algorithms that clinicians and patients can actually understand before trusting them, and a feedback loop that lets policymakers see how certified technology performs in the real world rather than relying on developer claims alone.

That last goal is what makes the Insights Condition distinct from prior reporting requirements. Instead of static compliance attestations, ONC now wants usage data that reflects how systems function in production.

A few outcomes ONC is aiming for with HTI-1:

  • Faster, less disruptive certification updates through incremental rulemaking instead of large periodic editions
  • Clearer visibility into how predictive algorithms are built, validated, and maintained
  • Better exchange of electronic health information across care settings
  • Evidence-based policy grounded in real usage data rather than developer self-reporting

For product and compliance leaders, the practical translation is this: certification is no longer a one-time gate you pass and forget. It is an ongoing obligation tied to how your software actually behaves after it ships.

Key dates and implementation timeline

Teams planning HTI-1 work need a clear runway, because several deadlines are sequential and some have already passed. The rule itself was published in the Federal Register on January 9, 2024, and ONC has issued fact sheets clarifying how the phased dates apply in practice.

  • December 31, 2024: Developers certified to the API criterion had to publish service base URLs in a standardized FHIR-based format, free of charge, and DSI-related certified module updates were due.
  • January 1, 2026: USCDI Version 1 expires for certification purposes, making USCDI Version 3 the required baseline for affected criteria.
  • December 31, 2025: Updated C-CDA Companion Guide requirements and minimum standard code set upgrades are due for certification.
  • CY 2026: The first full calendar year of data collection begins under the Insights Condition.
  • July 2027: The first Insights Condition reporting deadline (Year 1 measures) arrives for developers who must submit collected data.

ONC's fact sheet lays out a phased Insights Condition schedule spanning Years 1 through 3, with additional measures added in later years as developers build reporting capacity. That phasing matters because it signals ONC expects telemetry infrastructure to mature over time, not appear fully formed on day one.

The sequencing is worth internalizing. API and DSI work came first because they touch product architecture. USCDI v3 adoption follows because it depends on updated data models. Insights Condition reporting comes last because it depends on both of the earlier layers being in place and generating usable data. Teams that treat these as independent projects tend to rebuild the same instrumentation twice.

Certification program changes: what "edition-less" really means

ONC renamed the certification framework to the "ONC Certification Criteria for Health IT" and dropped the edition numbering that defined prior rules like the 2015 Edition. This is not just a naming change. Under the edition-less model, ONC can add or revise individual criteria through incremental rulemaking, which means certified developers face a steadier stream of smaller updates instead of one disruptive overhaul every few years.

Alongside that shift, HTI-1 strengthens the Conditions and Maintenance of Certification that developers agreed to under prior rules. These require vendors to:

  • Provide assurances to customers that certified capabilities will keep functioning as intended
  • Update certified products within specified timeframes when criteria change
  • Notify affected customers when certification status or functionality changes
  • Maintain documentation demonstrating ongoing compliance, not just point-in-time test results

For product teams, this changes how release planning works. A criterion update is no longer a distant deadline you schedule around; it is a recurring input into your roadmap, similar to a security patch cycle. Contracts and customer communications need language that reflects continuous certification maintenance rather than a one-time "certified as of" statement. Health systems evaluating vendors should ask directly how a vendor tracks and documents these ongoing assurances, since that process is now part of what certification actually guarantees. Teams building out this kind of assurance documentation often find it overlaps with broader security and compliance work, similar to how organizations approach security assurance frameworks when presenting readiness to health system customers.

Decision Support Interventions and algorithm transparency

Decision Support Interventions cover software functions that provide clinicians, patients, or caregivers with recommendations or guidance based on patient data. HTI-1 splits DSI requirements into two categories, and the split determines how much documentation a developer owes. Evidence-based DSIs, the more traditional rules-based clinical decision support, carry 13 required source attributes developers must disclose. Predictive DSIs, meaning anything using machine learning or statistical models to generate a prediction, carry a longer list of 31 source attributes.

Those attributes function like a structured model card. They ask developers to describe where the model came from, what data trained it, how it performs, what populations it was validated against, and where its known limitations sit. That is a meaningfully different obligation than the intervention-focused disclosures required under earlier clinical decision support rules.

Attributes developers need to be ready to document include:

  • Intended use and the clinical problem the DSI addresses
  • Development approach, including whether the model is proprietary or externally sourced
  • Training data characteristics, including relevant population descriptors
  • Performance metrics and validation methodology
  • Known limitations, including fairness or bias considerations
  • Ongoing monitoring and update processes once the DSI is deployed

DSI's Predictive DSI attributes effectively require structured model-card documentation, and startups without existing telemetry and governance infrastructure will struggle to produce it on demand. That gap shows up most often in companies that built a predictive feature quickly and never formalized the validation and monitoring records ONC now expects as a matter of course.

The maintenance obligation is where many teams underestimate the work. It is not enough to document a model once at launch. Developers are expected to keep source-attribute information current as models are retrained or retuned, which means validation evidence, risk analyses, and release notes need to live somewhere structured and exportable, not scattered across engineering tickets and slide decks. Vendor responsibility does not extend to guaranteeing clinical outcomes, but it does extend to giving clinicians enough information to judge a DSI's fitness for a given patient population before they rely on it.

Pro Tip: Build your DSI source-attribute documentation into your model development workflow from the start, not as a compliance step bolted on before an audit.

Clinical governance teams should treat this as a cross-functional requirement rather than a legal one. Engineering owns the technical attributes, clinical leadership owns the intended-use and limitations framing, and someone needs to own keeping both in sync as the model changes. Health systems evaluating a Predictive DSI vendor should ask to see this documentation directly, since HTI-1 gives them the right to expect it.

Decision Support Interventions and algorithm transparency — overview diagram

USCDI v3 and the standards updates behind interoperability

USCDI Version 3 becomes the required baseline once USCDI v1 expires for certification purposes on January 1, 2026. That expiration touches several certification criteria simultaneously, which is why standards teams cannot treat it as a single-field update.

Criteria that must reflect USCDI v3 include:

  • Transitions of care criteria, which govern what data must be included when a patient moves between care settings
  • View, download, and transmit to a third party functionality
  • The standardized API criterion that supports patient and third-party app access

Alongside USCDI v3, ONC finalized updates to the C-CDA Companion Guide, with certified products expected to reflect those changes by December 31, 2025. Minimum standard code sets, the vocabularies and terminologies certified systems must support, get version upgrades on the same general timeline.

For API teams specifically, HTI-1 reinforces expectations that certified systems support FHIR Release 4 and publish service base URLs in a standardized, machine-readable format at no cost to third-party applications. That requirement was already due by the end of 2024, so any developer still treating it as a lower priority is behind schedule.

Practically, this means data model updates, terminology mapping work, and API conformance testing need to happen together rather than sequentially. A system that updates its data model to USCDI v3 but leaves its C-CDA implementation on older code sets will pass one certification check and fail another.

Information blocking updates and the TEFCA manner exception

HTI-1 refines the information blocking exceptions that determine when withholding electronic health information is defensible rather than a violation. The rule revises the infeasibility exception and adds a manner exception specifically addressing participation in the Trusted Exchange Framework and Common Agreement, commonly known as TEFCA.

The TEFCA manner exception matters for organizations weighing how to respond to a data request when multiple technically possible methods exist. Under the exception, an actor can decline to fulfill a request in the specific manner requested if it instead offers to fulfill the request through TEFCA, provided the actor is a QHIN, participant, or subparticipant capable of doing so. Practical checks worth running before relying on this exception:

  • Confirm your organization's actual TEFCA participation status, not just its stated intent to join
  • Verify that fulfilling the request through TEFCA meets the same timeliness the requester needs
  • Document the alternative offer in writing so the exception's manner condition is clearly satisfied

Beyond TEFCA, HTI-1 also clarifies how organizations should handle third-party modification requests and patient-initiated restriction requests submitted through online portals or apps. The rule expects organizations to have clear internal processes for routing these requests rather than defaulting to denial when a request arrives through an unfamiliar channel.

None of this changes the underlying principle that information blocking is the default assumption unless a specific exception applies. Teams unfamiliar with how these exceptions function in practice may find it useful to review a breakdown of information blocking exceptions alongside their own workflow documentation before finalizing new denial or restriction procedures.

Practical HTI-1 compliance checklist for developers and health system implementers

Turning HTI-1 into action items works best when you separate what needs attention now from what can wait a few quarters. Here is a sequence that reflects how the rule's obligations actually depend on each other.

  1. Run a DSI inventory now. List every clinical decision support and predictive feature in your product, then classify each as evidence-based or Predictive DSI.
  2. Assign source-attribute ownership immediately. Pair an engineering lead with a clinical lead for each Predictive DSI to document the required attributes.
  3. Audit USCDI v3 field coverage within the next 3 to 6 months. Identify gaps between your current data model and the v3 baseline before the January 2026 expiration of v1.
  4. Verify API and FHIR conformance within the next 3 to 6 months. Confirm service base URLs are published and that endpoints meet current standardized API requirements.
  5. Design Insights Condition telemetry within the next 6 to 18 months. Map planned usage metrics to ONC's published measures rather than building generic analytics and retrofitting later.
  6. Build a documentation retention process on an ongoing basis. Store validation evidence, risk analyses, and release notes in a structured, exportable format for both certification maintenance and Insights reporting.

Compliance ownership should not sit with one department. Engineering handles technical implementation, product owns roadmap sequencing, compliance tracks deadlines and documentation, and clinical leads validate that DSI disclosures are clinically meaningful, not just technically complete.

Pro Tip: Treat Insights Condition telemetry as a product feature you ship, not a report you generate once a year, since the measures require sustained data collection starting in CY 2026.

The most common shortfall among smaller health tech companies is the absence of built-in telemetry. Teams that added analytics as an afterthought often discover they cannot reconstruct the usage history ONC's measures require, because the instrumentation simply was not there when the feature launched. Retrofitting telemetry after the fact is possible, but it costs more engineering time than building it in from the start. Reviewing a structured ONC certification readiness process early can help teams sequence this work before deadlines compress the timeline.

Executive perspective: what HTI-1 means for product and clinical leadership

Executives evaluating HTI-1 often ask the wrong first question: what is the minimum needed to stay certified. The better question is where transparency itself becomes a competitive asset. A well-documented Predictive DSI, complete with clear provenance and honest limitation statements, signals maturity to health system buyers who are increasingly wary of black-box algorithms.

Boards and investors evaluating healthcare SaaS companies are starting to ask about algorithm governance the way they once asked about data security. Founders who can show a working DSI documentation process and a telemetry plan already aligned to Insights Condition measures are answering a due-diligence question before it gets asked.

Prioritization matters more than speed here. Spend governance dollars on the DSI and telemetry work that regulators will actually check, not on peripheral compliance theater. This is precisely the gap fractional Chief Medical Officer services aim to close: translating regulatory obligation into a roadmap a technical team can execute without losing months to misread requirements.

— Paul Bergeron MD, MBA

How The StartUp MD helps teams operationalize HTI-1

Getting HTI-1 right is less about legal interpretation and more about sequencing the right work in the right order with the right people accountable for it. Specialized healthcare consultancy firms work with healthcare SaaS companies and digital health startups to turn regulatory obligations like this into a roadmap their engineering and clinical teams can actually execute.

The StartupMD

Through fractional Chief Medical Officer engagements and advisory services, consultants help founders and executives connect clinical governance to product decisions instead of treating them as separate tracks. Typical support may include:

  • Building a readiness roadmap that sequences DSI documentation, USCDI v3 updates, and telemetry work realistically
  • Designing a telemetry and reporting plan aligned to Insights Condition measures
  • Reviewing clinical governance processes for Predictive DSIs before they reach health system customers
  • Aligning product roadmap decisions with regulatory-readiness timelines

If your team needs hands-on guidance translating HTI-1 into a plan your engineers and clinicians can both follow, visit The StartUp MD's services page to see how fractional CMO and advisory support could fit your stage and team.

Where to read the primary HTI-1 documents

For legal interpretation, the Federal Register final rule text is the authoritative source, since it contains the full regulatory language behind Conditions of Certification, DSI requirements, and USCDI v3 adoption.

For practical implementation detail, ONC's own fact sheets are more digestible. The HTI-1 Final Rule Overview and Key Dates fact sheet summarizes timelines clearly, while the HTI-1 DSI fact sheet walks through source attributes in detail. HHS also issued a public announcement summarizing the rule's goals for readers who want a plain-language starting point.

This article is general information, not a substitute for advice from a qualified lawyer. Consult a qualified legal professional about your own circumstances before acting on anything here.

Sources

FAQ

What is the ONC HTI-1 rule?

HTI-1 is an ONC final rule under the 21st Century Cures Act that updates health IT certification requirements, introduces algorithm transparency rules for Decision Support Interventions, and creates the Insights Condition reporting program. It also revises information blocking exceptions and adopts USCDI Version 3 as the new data standard baseline.

What does HTI-1 stand for in the context of 2026 certification requirements?

HTI-1 stands for "Health Data, Technology, and Interoperability" and refers to the first rule in ONC's series implementing these updates. By 2026, its most consequential requirement is the USCDI v3 baseline, since USCDI v1 expires for certification purposes on January 1, 2026.

What is the purpose of the HITECH Act?

The HITECH Act, part of the broader legislative foundation that preceded the Cures Act, was designed to promote the adoption and meaningful use of health information technology, including electronic health records. HTI-1 builds on that foundation but derives its specific authority from the 21st Century Cures Act rather than HITECH directly.

When does the Insights Condition reporting requirement begin?

Data collection for the Insights Condition begins in calendar year 2026, with the first reporting deadline for Year 1 measures arriving in July 2027. Additional measures phase in during Years 2 and 3 as reporting infrastructure matures.

What are Predictive DSI source attributes?

Predictive DSI source attributes are the 31 categories of information developers must disclose about a predictive algorithm, covering provenance, training data, performance, and known limitations. They function similarly to a structured model card that clinicians can review before relying on the tool.