HTI-1 algorithm transparency targets certified health IT—not model approval
ONC's HTI-1 rule creates transparency requirements for AI and other predictive algorithms that are part of certified health IT. The disclosure baseline supports user assessment; it is not a federal approval of a model or a local decision to use it.
Editorial figure by Health Interoperability Review. Source context: ASTP/ONC — HTI-1 Final Rule.
Certification scope comes before an algorithm claim
The direct answer on ONC's HTI-1 page is scoped to the Certification Program: the algorithm-transparency requirements address AI and other predictive algorithms that are part of certified health IT. That framing requires an exact record of the certified health IT module, certification criteria and version, developer, decision-support intervention or predictive model relationship, deployment, and effective requirements before teams generalize a transparency claim.
A health system may use models inside certified technology, beside it, or through connected services. Those arrangements can create different certification, contract, data, clinical-governance, security, and operational responsibilities. A vendor statement that a product is certified does not by itself identify every model in a local workflow or prove that every connected algorithm falls within the same criterion and evidence package.
Transparency information supports assessment rather than approval
ONC says the requirements make a consistent baseline set of information available so clinical users can assess algorithms for fairness, appropriateness, validity, effectiveness, and safety. Those are assessment dimensions, not an ONC declaration that a particular model is clinically appropriate for every population, setting, interface, or decision. Local use still depends on the model, data, intended use, workflow, monitoring, and accountable clinical governance.
An interoperable model inventory should link the disclosed source information to local version, purpose, inputs and outputs, population and setting, integration path, human review, override, performance evidence, change history, incident and feedback records, and approval state. The system must preserve when vendor evidence ends and local validation, deployment, and monitoring evidence begins.
HTI-1 contains several different operating changes
The official page also identifies USCDI Version 3 adoption in the Certification Program, revisions to information-blocking definitions and exceptions, a TEFCA-related exception, and reporting metrics for certified-health-IT developers. These provisions address different objects: data-standard baselines, information-sharing practices, exchange conditions, and developer reporting. They should not be reduced to one broad 'HTI-1 ready' field.
For interoperability teams, the practical test is whether product and governance records map each applicable provision to the correct module, criterion, actor, data class, exchange or use, implementation date, evidence, and owner. A USCDI version does not establish semantic completeness in a particular receiving workflow; a transparency record does not authorize disclosure; and a reporting metric does not prove effective local use.
Production use remains a local, evidence-based decision
A buyer demonstration should start with the certified module and official certification record, identify one algorithm in scope, retrieve the required transparency information, then trace the locally deployed version through data flow, clinician presentation, action or override, monitoring, change, and retirement. It should expose missing or conflicting evidence and show who can approve, restrict, suspend, or escalate use.
This article does not determine certification scope, algorithm quality, clinical validity, fairness, safety, legal compliance, information-blocking status, or appropriateness for any patient or workflow. Organizations need the final rule and current guidance, official certification evidence, developer disclosures, local data and performance evidence, and qualified clinical, informatics, safety, security, privacy, compliance, and legal judgment. Transparency is a prerequisite for review—not the review outcome.
Enterprise buyer test
Translate this change into the exact population, record type, workflow stage, decision owner, effective date, and evidence that could be affected. Ask current or prospective providers to demonstrate the named workflow with representative data and an exception—not a polished feature tour. Record what official documentation establishes, what a provider states, what the team observes, and what remains unresolved.
A defensible review also identifies the dependency outside the product. Authority interpretation, policy configuration, data quality, integrations, human judgment, approval rights, release governance, training, and retained evidence may remain customer or service responsibilities. The evaluation should preserve those boundaries instead of treating a technology claim as the complete operating model.
What we will watch next
Health Interoperability Review will watch the named source and affected market records for later evidence that changes status, scope, availability, implementation timing, workflow consequence, or the limits of the initial report. A later announcement does not silently overwrite this dated account; the change ledger preserves the sequence.