Bottom line. ONC's HTI-1 rule makes algorithm transparency an enterprise-readiness issue for clinical AI startups that enable or interface with predictive decision support in certified health IT. Physician investors should verify which product and deployment path is actually in scope, who must populate the required source attributes, whether intervention risk management is operational, and how the company separates ONC certification from FDA device status. Certification can improve access to information; it is not government validation of a model's clinical performance, fairness, or commercial value.[1]

Key takeaways

  • HTI-1 is a transparency and health-IT capability regime, not an approval pathway for clinical algorithms.
  • Scope turns on the certified module, the predictive DSI, and whether the certified developer supplies the intervention as part of that module; integration architecture and contracts matter.
  • Source attributes should make intended use, development, external validation, fairness, performance, maintenance, and local monitoring inspectable, but the rule does not mandate one validity or fairness metric.
  • Intervention risk management must be evidenced through risk analysis, mitigation, and governance, rather than reduced to a policy document or a model card.
  • FDA classification remains a separate function-by-function analysis, so a startup needs a defensible two-regulator perimeter instead of one generic clinical AI conclusion.
  • Investors should value faster enterprise diligence and lower documentation debt only when source data, ownership, monitoring, and change controls are demonstrably complete.

Why HTI-1 belongs in clinical AI investment diligence

The HTI-1 final rule updated the ONC Health IT Certification Program under the 21st Century Cures Act. ONC describes its algorithm-transparency provisions as a baseline that allows clinical users to assess whether predictive algorithms are fair, appropriate, valid, effective, and safe. The distribution channel is important: ONC reports that certified health IT supports care delivered by more than 96% of hospitals and 78% of office-based physicians.[1] A startup selling into EHR-centered workflows can therefore encounter HTI-1 expectations even when it is not itself a certified EHR developer.

The rule became effective in March 2024, and the revised decision-support criterion has ongoing maintenance obligations. The current regulatory text requires capabilities for selecting interventions, exposing and editing source attributes, exporting feedback, and applying intervention risk management to predictive DSIs supplied by a certified developer as part of its module.[2][3] For an investor, these are not abstract compliance topics. They affect sales-cycle evidence, product architecture, counterparty allocation, deployment support, and the cost of keeping documentation current across model versions.

The search intent in one sentence

A physician investor evaluating a clinical AI company should be able to answer: does this deployment enter the HTI-1 predictive DSI framework, what evidence must follow the model into certified health IT, and does the company have an operating system that keeps that evidence trustworthy after launch?

Start with scope: product, module, and supply relationship

ONC defines a predictive decision support intervention as technology that supports decision-making through algorithms or models that derive relationships from training data and produce a prediction, classification, recommendation, evaluation, or analysis. The definition is broader than generative AI and can capture conventional statistical or machine-learning models. The certified developer is responsible for deciding whether a technology meets the definition; ONC does not make model-by-model scope determinations.[4] That makes a documented classification rationale a core diligence artifact rather than an informal assumption.

Certification scope is not the same as startup scope

A certified health IT developer does not have to author or directly provide a predictive DSI to earn certification to the decision-support criterion. The ONC companion guide also distinguishes a model supplied by the certified developer as part of its module from an outside intervention that merely uses module data or sends output through the module. For the latter, the certified developer must provide relevant capabilities but is not automatically accountable for populating the outside model's source-attribute content.[4] Investors should not translate that allocation into no obligation for the startup: a hospital or EHR partner may shift documentation, update, audit, and incident duties through contract.

Build the deployment-path responsibility map

Deployment path Evidence to verify Investor interpretation
Certified developer supplies the DSI CHPL-listed module, product documentation, source attributes, IRM summary, version ownership, and customer access. Direct certification maintenance and stewardship are central; failure can impair a scaled distribution channel.
Independent DSI connects to certified health IT Interface design, source-attribute handoff, customer permissions, contract allocation, monitoring feeds, and update notices. Regulatory accountability may be divided, but documentation debt and integration friction can still sit with the startup.
Standalone or non-certified workflow Actual customers, data flow, intended use, marketing claims, and planned EHR roadmap. HTI-1 may not directly govern the current path; FDA, privacy, safety, contract, and future-channel risks remain.

Require management to map every material SKU and integration, not just the flagship configuration. A model can be offered through a certified module to one customer, connected as an outside service to another, and sold as a standalone application to a third. The same algorithm may therefore carry different documentation owners, user controls, and change-notification obligations. Unit economics that ignore this deployment variance can understate implementation and support cost.

Source attributes turn model documentation into a commercial interface

The decision-support criterion requires a certified module to support complete and current plain-language source information. For predictive DSIs, the regulated fields reach into the intervention's intended use, development, validation, performance, fairness, maintenance, and deployed monitoring context. Users must also be able to see when specified information is unavailable and, for authorized users, record or change source attributes.[3][4] A PDF assembled during enterprise diligence is not enough if it cannot remain aligned with the production model and workflow.

Test the evidence behind each attribute

  • Intended use: target decision, user, population, setting, workflow position, output, known exclusions, and foreseeable misuse.
  • Development: model owner, training-data provenance, representativeness, feature construction, reference standard, and version lineage.
  • Validation: internal and external cohorts, sites, dates, comparators, missingness, thresholds, confidence intervals, and subgroup results.
  • Performance and fairness: clinically meaningful measures, disaggregation rationale, failure modes, calibration where relevant, and limits on generalization.
  • Maintenance: monitoring population, data-drift and performance triggers, human review, update cadence, change control, retirement, and customer communication.
  • Local use: whether local performance information exists, who can provide it, how feedback is exported, and how findings alter deployment decisions.

The most important caveat is easy to miss: ONC does not prescribe a specific validity or fairness measure. Its companion guide allows unavailable fields to be marked unknown in defined circumstances and expects developers to exercise due diligence before doing so.[4] A complete screen can therefore contain weak evidence, irrelevant metrics, or unknowns. Physician investors add value by asking whether each measure fits the actual decision and harm, whether denominators and confidence intervals are visible, and whether the clinical workflow changes the model's observed utility.

Intervention risk management must operate throughout the lifecycle

For each predictive DSI supplied by a certified developer as part of its module, the criterion requires intervention risk-management practices covering risk analysis, risk mitigation, and governance. Summary information is part of the certification ecosystem, while ongoing maintenance requires review and updating of source attributes and risk-management information as necessary.[4] The investment question is whether governance can detect a changed risk, authorize action, and produce records before a customer or regulator asks.

Use NIST as an operating cross-check, not a compliance certificate

ONC points to the NIST AI Risk Management Framework as an optional resource rather than a mandatory methodology. NIST organizes work through govern, map, measure, and manage.[9] Its Core calls for repeatable testing and evaluation processes plus post-deployment monitoring, user input, override, incident response, recovery, change management, and decommissioning.[10] Those outcomes make a useful board-level cross-check because they connect documentation to action without implying that framework adoption proves HTI-1 conformity or clinical quality.

Ask for one model-version evidence packet

Select a deployed version and trace its intended use, training lineage, validation report, subgroup analysis, source-attribute publication, release approval, customer list, monitoring dashboard, feedback export, incidents, and update decision. Then reconcile the packet to code and production configuration. A policy that cannot produce this chain is not a control. The exercise also exposes whether responsibility fragments across data science, clinical, quality, security, product, an EHR partner, and the customer.

Keep ONC transparency separate from FDA device analysis

The January 2026 FDA clinical decision support guidance explains how the agency interprets the Cures Act exclusion for certain non-device CDS functions. FDA evaluates software functions against statutory criteria, including the intended user, the information processed, the recommendation or support provided, and whether the healthcare professional can independently review the basis for the recommendation.[6] The agency's policy navigator adds examples of medical information and independently verified support that can inform the analysis.[7] This is a different question from whether a predictive DSI is supported through certified health IT.

A company should maintain a function-level matrix covering both regimes. One feature may be non-device CDS under FDA's interpretation yet still require HTI-1-facing transparency in a certified environment. Another may be a regulated device software function and also appear as a predictive DSI in certified health IT. As of August 2, 2026, FDA is also seeking input for its 2026 report on risks and benefits of non-device software functions, with comments due August 13, 2026, underscoring that the non-device boundary remains an active policy area.[8] Investors should verify the current guidance before relying on a classification.

The physician investor's seven-part diligence framework

1. Classify every function and deployment path

List each model, user, output, clinical purpose, customer type, interface, and certified module. Record management's HTI-1 and FDA conclusions, the evidence owner, counsel or regulatory review, and the change triggers. Avoid a company-wide label such as decision support platform; scope attaches to facts at the function and deployment level.

2. Authenticate the certification and contract perimeter

Verify the certified product and criterion, what the EHR partner actually supplies, which entity controls source attributes, and who owns updates, feedback, audit support, and customer communication. Review sales statements that use certified, compliant, approved, or validated. Overbroad certification claims create trust and diligence risk even when the underlying technical integration works.

3. Reperform the source-attribute evidence chain

Sample the highest-revenue or highest-risk model. Tie every material source attribute to a version-controlled source, responsible person, approval date, and update event. Test whether a customer can understand limitations without access to the development team. Unknown values should have a documented basis, remediation decision, and commercial consequence.

4. Challenge clinical validity and local fit

Ask whether the validation population, prevalence, sites, devices, practice patterns, and intervention threshold resemble the target deployment. Examine alert burden, false reassurance, automation bias, override, and downstream action. Transparency is valuable only if the information helps a customer decide whether and how to use the model safely in its own workflow.

5. Test monitoring and change control

Inspect live measures, minimum sample rules, alert thresholds, subgroup surveillance, complaint and feedback intake, escalation, release gates, rollback or containment, incident communication, and retirement. Confirm that customer-facing documentation changes with the deployed version. Include third-party models and foundation-model dependencies in the monitoring inventory.

6. Match staffing and systems to the sales plan

Compare expected integrations and update cadence with clinical, data, product, quality, regulatory, security, legal, and customer-success capacity. Manual questionnaires may work for three customers and fail at thirty. Underwrite the structured evidence repository, permissions, versioning, API or export capability, and partner operations required for scale.

7. Price documentation debt and dependency risk

Build a remediation schedule for missing provenance, weak external validation, incomplete subgroup analysis, ambiguous ownership, manual monitoring, or unsupported claims. Model EHR-partner delay and contract renegotiation separately from technical development. Use closing conditions, milestones, reserves, information rights, or specific representations as appropriate with qualified advisers.

Valuation: credit verified enterprise readiness

HTI-1 readiness can create value when it shortens health-system diligence, makes limitations understandable, reduces duplicate evidence work, and gives EHR partners confidence in lifecycle support. The premium should attach to verified capabilities: structured source data, reproducible validation, reliable version linkage, monitoring, contract clarity, and experienced owners. Certification language without model-level evidence deserves no quality premium.

Treat regulatory deadlines as roadmap inputs rather than marketing events. ONC's current update page identifies a December 31, 2027 deadline for specified privacy and security certification dependencies associated with the decision-support criterion under HTI-2.[5] Even when that duty falls on a certified partner, the startup may face integration testing, security evidence, contracting, or customer scheduling effects. The forecast should identify who funds and executes those dependencies.

Red flags that should change valuation or timing

  • Management describes ONC certification as proof that its model is clinically accurate, unbiased, safe, or FDA-cleared.
  • The company cannot identify which certified module, criterion, model version, and supply relationship support its HTI-1 claim.
  • Source attributes are copied from a sales deck, lack owners or dates, or do not match the deployed model and intended population.
  • External validation, local performance, subgroup results, or important limitations are marked unknown without a documented diligence basis.
  • Risk management is a static policy with no version-level decisions, thresholds, incident records, or board reporting.
  • The EHR partner, startup, and customer each assume another party owns documentation updates, feedback export, or incident communication.
  • The FDA analysis uses one company-wide conclusion and does not address individual software functions or current intended-use claims.
  • Enterprise growth depends on manual questionnaires and one key employee rather than a controlled evidence system.

A 100-day board plan after investment

In the first thirty days, approve the function and deployment inventory, verify certification touchpoints, and assign each source attribute and risk control to an owner. By day sixty, complete a model-version evidence trace, close critical claim or contract gaps, and baseline monitoring. By day one hundred, run a drift or safety-event tabletop with the EHR partner and one customer, validate documentation updates and feedback export, fund the remaining evidence roadmap, and establish quarterly board reporting on model changes, performance signals, incidents, unknown attributes, and regulatory classifications.

Frequently asked questions

Does HTI-1 mean ONC approves a clinical AI model?

No. ONC certification evaluates whether a health IT module conforms to specified certification capabilities. ONC states that it does not decide whether a particular technology meets the predictive DSI definition, and the certification program does not prescribe a validity or fairness metric. Investors still need model-level evidence and local-use diligence.

Does HTI-1 apply directly to every clinical AI startup?

No. The direct certification duties generally attach to developers of certified health IT and the certified modules within scope. An independent model vendor can nevertheless face material contractual and commercial demands when its product is supplied through, embedded in, or documented within a certified module.

Is a non-device FDA conclusion enough to satisfy HTI-1?

No. FDA device status and ONC certification are separate analyses with different purposes. A software function can fall outside the device definition yet still be a predictive DSI in a certified health IT environment, and an ONC transparency capability does not establish that FDA requirements are satisfied.

What is the highest-value HTI-1 diligence artifact?

Start with a responsibility and evidence matrix that maps each model, deployment path, certified module, source attribute, risk-management control, document owner, update trigger, and customer obligation. It exposes where transparency depends on an unsupported assumption or a counterparty.

How should an investment committee value HTI-1 readiness?

Credit verified documentation, monitoring, governance, and integration capabilities that shorten enterprise review or reduce rework. Discount claims that rely on certification as a quality seal, undocumented third-party inputs, weak local validation, or contracts that leave source-attribute and incident duties unresolved.

Conclusion

HTI-1 gives clinical AI buyers a more consistent window into predictive decision support, but the window is not the underlying evidence. Physician investors should connect certification scope, source attributes, risk management, FDA classification, local clinical fit, and contractual responsibility into one diligence view. The investable asset is not a completed transparency screen. It is a company that can explain the right model, in the right workflow, with current evidence, detect when reality changes, and act before documentation debt becomes commercial or patient-safety debt.

References

  1. Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. HTI-1 Final Rule. Accessed August 2, 2026. https://healthit.gov/regulations/hti-rules/hti-1-final-rule/
  2. U.S. Department of Health and Human Services. Health Data, Technology, and Interoperability: Certification Program Updates, Algorithm Transparency, and Information Sharing. 89 FR 1192, January 9, 2024. Accessed August 2, 2026. https://www.federalregister.gov/documents/2024/01/09/2023-28857/health-data-technology-and-interoperability-certification-program-updates-algorithm-transparency
  3. Electronic Code of Federal Regulations. 45 CFR 170.315(b)(11), Decision support interventions. Accessed August 2, 2026. https://www.ecfr.gov/current/title-45/subtitle-A/subchapter-D/part-170/subpart-C/section-170.315
  4. Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. Decision Support Interventions Certification Companion Guide and Test Method, updated May 5, 2026. Accessed August 2, 2026. https://healthit.gov/test-method/decision-support-interventions/
  5. Assistant Secretary for Technology Policy/Office of the National Coordinator for Health Information Technology. ONC Certification Criteria for Health IT by Regulatory Update Deadline. Accessed August 2, 2026. https://healthit.gov/certification-health-it/onc-certification-criteria-health-it-regulatory-update-deadline/
  6. U.S. Food and Drug Administration. Clinical Decision Support Software: Guidance for Industry and Food and Drug Administration Staff. Final Guidance, January 2026. Accessed August 2, 2026. https://www.fda.gov/regulatory-information/search-fda-guidance-documents/clinical-decision-support-software
  7. U.S. Food and Drug Administration. Digital Health Policy Navigator, Step 6: Is the Software Function Intended to Provide Clinical Decision Support? Accessed August 2, 2026. https://www.fda.gov/medical-devices/digital-health-center-excellence/step-6-software-function-intended-provide-clinical-decision-support
  8. U.S. Food and Drug Administration. Reports on Non-Device Software Functions, including the 2026 public-comment request. Accessed August 2, 2026. https://www.fda.gov/about-fda/cdrh-reports/reports-non-device-software-functions
  9. National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework (AI RMF 1.0), NIST AI 100-1, January 2023. Accessed August 2, 2026. https://www.nist.gov/publications/artificial-intelligence-risk-management-framework-ai-rmf-10
  10. National Institute of Standards and Technology, Trustworthy and Responsible AI Resource Center. AI RMF Core. Accessed August 2, 2026. https://airc.nist.gov/airmf-resources/airmf/5-sec-core/

Editorial disclaimer: This article is for educational purposes only and does not constitute medical, legal, tax, accounting, regulatory, cybersecurity, or investment advice. Requirements, guidance, and product classifications are fact-specific and can change. Readers should consult qualified professionals and verify current primary sources before acting.