The AI Learning Hub Journal

Software as a Medical Device and Intended Use

The governance stack around a deployed clinical AI toolThe tool, in front of a patienteverything below has to hold for this to be safeMonitoring in useperformance, incidents, and whether it is still used as intendedChange control for model updatesan update is a change: re-check, re-approve, re-communicateInstitutional review and sign-offclinical, safety, information governance and IT each hold a vetoRegulatory pathwaywhat kind of product this is, and what that classification demandsINTENDED-USE STATEMENT — the foundationwhich population, which task, which setting, which claimuse it outside this and none of the assurance above appliesGOVERNS EVERY LAYER ABOVE ITACCOUNTABILITYCUTS ACROSS ALL OF ITA named clinical ownerA named technical ownerA route to raise concernsA record of who decided whatA defined way to switch it offThe tool never holdsthe responsibility. Aclinician remainsanswerable for the care.Read the intended-use statement first — it tells you what every other document in the stack is actually about
Intended use is the foundation, not the paperwork — every layer above it is only meaningful relative to the claim being made

What Makes Software a Medical Device

Across major jurisdictions, whether software is regulated as a medical device turns on its intended purpose rather than its technology. Software intended for diagnosis, prevention, monitoring, prediction, prognosis, treatment, or alleviation of disease generally falls within the definition. Software that only stores, transmits, or displays data, or that supports administration, generally does not. The technology is irrelevant to the classification: a simple rule-based calculator can be a regulated device while a sophisticated model can sit outside scope, purely because of what each claims to do. This is counter-intuitive to engineers and to buyers, and it is the single most important structural fact about healthcare AI regulation.

  • Classification follows intended purpose, not sophistication or technology
  • Diagnosis, prognosis, monitoring, prediction, and treatment support tend to fall in scope
  • Storage, transmission, display, and administration generally sit outside it
  • A simple calculator can be regulated while a complex model is not — the claim determines it

The Intended-Use Statement Governs Everything

The intended-use statement is the most consequential document attached to a clinical AI product. It defines the condition, the patient population, the clinical setting, the user, the role in the decision, and the data the product operates on. Everything else follows from it: the evidence required, the risk classification, the labelling, the post-market obligations, and the boundary of what the manufacturer stands behind. Two products with identical code and different intended-use statements have different regulatory lives. For a buyer, this means the useful question is never "is this approved?" but "approved for what, for whom, in which setting, and in which role?" A regulatory clearance is not a general endorsement of a product.

  • Intended use fixes condition, population, setting, user, role, and input data
  • Evidence, classification, labelling, and post-market duties all flow from it
  • Ask not "is it approved" but "approved for what, for whom, in which setting, in which role"

Drifting Outside the Envelope

Real deployments drift. A tool cleared as a second reader gets used concurrently because it is faster. A tool validated in adults is used in adolescents because the case was borderline. A prioritisation tool becomes a de facto rule-out because clinicians learn to trust its silence. Each step is locally reasonable and cumulatively takes the deployment outside the envelope the evidence and the approval cover — usually without any decision that anyone would recognise as a decision. This is an institutional governance responsibility rather than a manufacturer one: the institution has to define permitted use, communicate it to users, and periodically check what is actually happening in the workflow versus what was authorised.

  • Drift happens incrementally through locally reasonable choices, not through a decision
  • Population, role, and setting are the three axes that drift most often
  • Define permitted use, communicate it, and audit actual use against it
  • Out-of-envelope use shifts responsibility toward the institution

Prefer slides, quizzes, and saved progress? Read this lesson in the library — free, no sign-up.