Health software needs more than one kind of proof

A current source, a bounded question

The FDA’s final Clinical Decision Support Software guidance was issued on 29 January 2026 and superseded its 6 January version. It explains the agency’s thinking about when certain decision-support software functions are excluded from the device definition. One relevant criterion concerns whether a healthcare professional can independently review the basis for a recommendation instead of relying primarily on it. The guidance is nonbinding and does not determine the status of an unnamed startup’s product. Read the FDA guidance page and the dated final document.

The useful founder question is therefore about a specific function, intended user and intended use—not whether “health AI” is regulated as one uniform category. This note is educational research, not legal, regulatory or clinical advice. A real product assessment needs qualified review in its intended jurisdiction.

Separate three evidence questions

The International Medical Device Regulators Forum’s 2017 clinical-evaluation document distinguishes a valid clinical association, analytical validation and clinical validation for software as a medical device. In plain language: is the output meaningfully associated with the clinical condition, does the software process inputs accurately and reliably, and does it achieve its intended purpose in the intended population and context? The framework also treats evaluation as an ongoing activity. It is a set of international principles, not a substitute for national requirements. Read the IMDRF document record and the final framework.

Our editorial implication: do not collapse these questions into one accuracy number. A technically reproducible output and a clinically useful intervention answer different questions.

Add the operating case

For research interviews, we suggest drawing the existing workflow before proposing a replacement. Who supplies the input? Who notices a bad result? Who acts on it? Which team maintains the integration? Who controls the budget? These are prompts for discovery, not claims about how every healthcare organization buys software.

Keep a separate log for each answer. An enthusiastic user is not automatically a procurement decision-maker. A willing buyer is not evidence of clinical performance. A deployment agreement is not evidence that people can safely interpret the output under real working conditions.

A small evidence matrix can keep the distinctions visible: the proposed claim, the intended setting, the evidence available, the evidence still missing and the person responsible for reviewing it. Mark untested assumptions explicitly. Avoid filling a missing cell with a testimonial that answers another question.

Make the next experiment smaller

Before adding another feature, identify the uncertainty that could invalidate the project. It may concern input quality, interpretation, integration or the ability to conduct an appropriate evaluation. Design the next investigation around that uncertainty.

Retain the version of the product, the intended-use statement and the source documents used in the review. A change to the product or claim should trigger reconsideration of the evidence it needs. The aim is not to declare a product ready from this article; it is to prevent three distinct proof problems from being mistaken for one.