Core elements of an intended use statement
An effective statement covers four structural elements. Together they define what the model may do, for whom, under whose authority, and in which clinical context.
Clinical function
The specific task, such as screening, diagnosis, monitoring, or treatment guidance.
Patient population
The population the model was validated for, including documented exclusions.
Intended user
The clinical role authorized to act on the model’s output.
Care setting and workflow role
The environment and whether the AI functions in an adjunctive or autonomous role.
What an intended use statement defines and why it matters
Under 21 CFR 801.4, FDA defines intended use as the objective intent of the persons legally responsible for a device’s labeling, determined from labeling claims, advertising, and written or oral statements. For clinical AI, this means the intended use statement is not a general description of software capability. It is a specific, evidentiary claim about what the model does, for whom, and in what context.
FDA’s AI/ML SaMD Action Plan reinforces this by calling for a total product lifecycle approach that monitors real-world performance against the documented intended use, not against the model’s theoretical capability. A poorly scoped intended use statement creates two downstream problems: it weakens the regulatory basis for the submission, and it removes the boundary that governance teams need to detect when a model is being used outside its validated scope.
Intended use vs. indications for use vs. clinical claims
These three terms are often used interchangeably inside organizations, which creates confusion in both regulatory submissions and internal governance documentation. The distinctions matter for documentation quality and for how promotional language is interpreted later.
| Term | What it covers | Where it shows up |
|---|---|---|
| Intended use | General statement of clinical function and target population | Labeling, governance scope, change control boundary |
| Indications for use | More specific subset naming disease or condition, patient population, and use environment | FDA Form 3881; required under 21 CFR 814.20 for PMA applications |
| Clinical claims | Measured performance or outcomes that must not expand beyond documented intended use | Marketing, promotional material, performance summaries |
FDA’s evidentiary standard under 21 CFR 801.4 draws directly on advertising and promotional material, so marketing language that implies a broader clinical role than the documented intended use can itself become evidence of an unauthorized use claim.
Required components of a clinical AI intended use statement
Use the following components as a drafting checklist. Each item should be explicit enough that a reviewer or governance system can test real-world use against it.
- The specific clinical task the model performs, such as screening, diagnostic support, monitoring, or treatment guidance, rather than a general software category.
- The intended patient population, including age range, condition, and any documented exclusion criteria for populations the model was not validated against.
- The intended user role, such as a licensed radiologist or primary care physician, since FDA treats intended user as part of intended use scope.
- The care setting and workflow context in which the model is meant to operate.
- The model’s role in clinical decision-making, specifically whether it functions adjunctively to a clinician or supports more autonomous decision-making.
- A reference to the authorized change boundary if the device is covered by a Predetermined Change Control Plan, since PCCP modifications must remain within that boundary.
From documentation to runtime enforcement
FDA guidance addresses premarket documentation and lifecycle management expectations, including monitoring real-world use against the documented intended use. It does not specify how an organization should mechanically enforce that boundary once the model is running in a production clinical environment.
That translation step, converting a written population and scope constraint into a machine-readable policy attribute such as an age range, care setting, or authorized user role, is an internal governance responsibility. This is where an intended use statement functions as more than a compliance document: it becomes the source of truth for runtime access decisions.
Runtime governance note
Trussed AI provides runtime governance and policy enforcement capabilities that allow governance teams to encode documented scope constraints, such as intended user role or care setting, as enforceable runtime controls, without altering or extending the underlying regulatory documentation.
Governance considerations for lifecycle management
Treat intended use as an operational control surface across the model lifecycle, not only as a premarket artifact:
- Treat the intended use statement as a living document tied to model version, not a one-time submission artifact.
- Require governance sign-off before any modification that would push model behavior outside the documented intended use, even if the change appears minor.
- Audit marketing and product descriptions against the documented intended use, since promotional language can itself be treated as evidence of intended use under FDA’s evidentiary standard.
- Confirm that runtime access controls map to the documented intended user role rather than to broader system-level access.
- Log and monitor usage patterns against the documented population and setting constraints to support the total product lifecycle monitoring expectation.