Tier an AI-assisted diagnostic or triage model by its intended clinical use, not by a house default. In practice that is four steps. First, check whether the software is regulated at all. If it is, derive its IMDRF SaMD category from two things: how much the output matters to the healthcare decision, and how serious the patient’s situation is. Then map that category to an MDR Rule 11 class and set an IEC 62304 software safety class. The tier you end up with should set how much validation evidence you need. Under FDA’s risk-based assurance logic, the validation burden should be no more than the risk requires.
TechnoLynx starts with the AI Readiness Scorecard, which scores the programme against a named rubric with an evidence trail before validation work is planned.
Is the model regulated at all? Check that before any AI risk assessment
Many parts of a life sciences pipeline sit outside the regulated portion, even when the company assumes everything is constrained. So the first question is whether the proposed application falls under regulatory requirements at all.
In the EU, the test is qualification as medical device software (MDSW). Under MDCG 2019-11, software must have a medical purpose of its own to qualify, and the intended purpose the manufacturer states is what counts for both qualification and classification. Software that only stores, archives, communicates, runs a simple search or applies lossless compression does not qualify. Neither does software whose action is not for the benefit of individual patients, such as tools that only aggregate population data or support epidemiological studies. On the other side, computer-aided detection systems that suggest or exclude medical conditions are MDSW. So is a software module that generates alarms from monitoring patient-specific physiological parameters.
In the US, the 21st Century Cures Act excludes certain software functions from the device definition only when all four criteria are met. The software must not analyse a medical image or signal. It must display or analyse medical information. It must support recommendations to a healthcare professional. And it must let that professional independently review the basis of each recommendation instead of relying primarily on it. FDA’s final CDS guidance names software that detects a life-threatening condition such as stroke or sepsis and raises an alert to a clinician as a device function, because it gives a specific diagnostic output that supports time-critical decisions. A stroke triage algorithm that indicates whether to transfer a patient to a major stroke centre is also a device function.
Two further scope questions decide which rulebook applies:
- MDR or IVDR. If the intended purpose is driven substantially by data from in vitro diagnostic devices, the IVDR applies. If the data comes substantially from medical devices, the MDR applies. Where the output fits both definitions, the data sources are weighted by their significance to the intended purpose. IVD MDSW is classified under the IVDR rules, not the Rule 11 mapping below.
- EU AI Act high-risk status. Under Article 6(1), an AI system is high-risk when it is a safety component of, or itself is, a product covered by Annex I legislation that requires third-party conformity assessment. MDCG 2025-6 states that the MDR/IVDR class determines AI Act high-risk status, and that AI Act status does not raise the device’s MDR class. In-house devices made and used only within an EU health institution under the Article 5(5) conditions skip third-party assessment, so they are not high-risk AI systems on that route.
Deriving the IMDRF SaMD category from intended use
The IMDRF framework assigns software one of four categories. The category combines the significance of the information to the healthcare decision with the state of the healthcare situation or condition. Category IV carries the highest impact and Category I the lowest. Significance has three levels: treat or diagnose, drive clinical management, and inform clinical management. The situation has three levels: critical, serious and non-serious.
Two definitions trip people up. Triage sits under “drive clinical management”. The IMDRF text lists triaging, or identifying early signs of a disease, as information used to guide the next diagnostic or treatment step. IMDRF treats a situation as “critical” where timely action is vital to avoid death or long-term disability, citing life-threatening, time-critical conditions and fragile populations such as paediatrics. A serious-situation tool used by lay users without professional support should be treated as critical.
IMDRF category matrix
| Healthcare situation | Treat or diagnose | Drive clinical management | Inform clinical management |
|---|---|---|---|
| Critical | IV | III | II |
| Serious | III | II | : |
| Non-serious | II | I | : |
IMDRF states plainly that this categorisation identifies impact levels only. It does not by itself imply the regulatory controls needed. Treat the category as the input to classification, not as the classification itself.
How IMDRF categories map to MDR Rule 11 classes
MDR Rule 11 makes diagnostic or therapeutic decision software class IIa by default. It becomes class IIb where a decision could cause serious deterioration of health or a surgical intervention, and class III where it could cause death or irreversible deterioration. Monitoring software is class IIa, or IIb where it monitors vital parameters whose variation could put the patient in immediate danger. All other MDSW is class I.
MDCG 2019-11 aligns the two schemes directly. IMDRF Category IV corresponds to MDR class III, Category III to class IIb, and Categories I and II to class IIa. The guidance’s worked examples show the mapping in use:
| Example | IMDRF category | MDR class |
|---|---|---|
| Image analysis to make treatment decisions in acute stroke | IV.i | III |
| App analysing heartbeat to guide a physician’s diagnosis | III.i | IIb |
| Scoring depression from entered symptoms | III.ii | IIb |
| Ranking chemotherapy options for a clinician | II.i | IIa |
One consequence matters for detection and triage models. IMDRF Categories I and II both land in class IIa, so under Rule 11 MDSW that informs a diagnostic or therapeutic decision starts at class IIa. MDCG 2025-6 notes that most AI medical devices are class IIa or above and therefore need a notified body.
Worked example: two adverse-event detection models
Take a model that reads vital signs and lab values on a ward, flags likely sepsis and alerts the on-call clinician. FDA treats exactly this function as a device. Sepsis is life-threatening and time-critical, which puts it in a critical situation. The alert guides the next intervention, which is “drive clinical management”. That gives IMDRF Category III and, through the mapping, MDR class IIb. A team could argue the output is closer to “diagnose”. If a regulator accepted that reading, the tier would rise to IV and class III. Our view is that this ambiguity is the first thing to settle in writing, because the classification argument stands or falls on it.
Now take a model that processes non-serious adverse-event reports in a clinical trial. It codes most cases on its own and routes unclear seriousness or causality to a human. Its output serves adverse-event case processing in a clinical trial. On that reading the MDSW qualification test may not be met, since the action is not for the benefit of an individual patient. The intended use differs, and intended purpose governs qualification and classification.
Does the risk tier set the IEC 62304 software safety class?
Not directly, since IEC 62304 uses its own classes. IEC 62304 requires manufacturers to assign software, or its components, to safety class A, B or C according to the severity of possible harm. Class C is for death or serious injury, class B for non-serious injury and class A where no injury is possible. Documentation effort grows with each class. Class A documents requirements and release (plus system tests since the 2015 amendment). Class B adds architecture and verification. Class C adds detailed design.
Two engineering levers bear on the class. The first is external risk control. If a measure outside the software catches the failure, such as an independent second system or a clinician checking values before acting, it is derived first and the class determined after it. The second is segregation. If the architecture separates components with specified interfaces, each component can carry its own class. “A clinician reviews it” is a recognised external measure, but time pressure weakens it. Under time pressure, automation bias grows because users lack time to weigh other information.
Model influence and decision consequence: the general tiering logic
Regulatory categories identify impact levels. They do not by themselves set the controls a particular use of a model needs. FDA’s January 2025 draft guidance on AI for drug and biologic regulatory decisions defines model risk as the combination of model influence (how much the AI output contributes relative to other evidence) and decision consequence (how significant an adverse outcome from a wrong decision would be). That guidance covers drug products, and its concepts derive from the device standard ASME V&V40. Credibility activities should be commensurate with that risk.
Mitigations change the tier. In FDA’s own example, routine release testing of fill volume lowers a model’s influence, and a high-consequence decision ends up at medium model risk. A framework on human oversight of AI follows the same two axes. It assesses decision consequence by severity, probability and detectability of an error. It then maps the resulting tier to oversight: human-in-command at the highest risk, human-in-the-loop at medium to medium-high, human-on-the-loop at low to medium. Human oversight is then mapped proportionally to this tier.
Should we apply Computer Software Assurance here rather than full CSV?
For the diagnostic model itself, no: Computer Software Assurance covers production and quality-system software. FDA’s CSA guidance, issued 3 February 2026, applies to computers and automated data-processing systems used in medical device production or the quality management system. It does not govern the device software that a clinician acts on. That software falls under the MDR and IVDR clinical-evaluation, verification and lifecycle requirements.
CSA still applies to the production and quality-system software around the device. FDA describes it as a risk-based, least-burdensome approach, where the validation burden is no more than the risk requires. The guidance splits functions in a binary way:
- High process risk: failure could cause a quality problem that foreseeably compromises safety. Examples include functions that inspect or decide product acceptability with little or no human review. Assurance is then commensurate with the medical device risk, often through scripted or hybrid testing.
- Not high process risk: failure would not foreseeably compromise safety. Assurance is commensurate with the process risk and can rely on unscripted or exploratory testing.
So a production-line model that classifies product as accept or reject falls under CSA, and is high process risk with little human review. An adverse-event detection model at the bedside is not production or QMS software. Calling its validation “CSA” in a regulatory file invites a scope challenge. The proportionality principle itself is not in dispute: higher-risk applications need at least as much verification as lower-risk ones, and generally more.
How do we justify using archived data as a proxy for live-stream variability to an auditor?
Justify archived data with proportionate evidence, sized to the tier, and review it when monitoring, retraining or operational change calls it into question. Retrospective evaluation may not reflect prospective performance, and prospective performance is what affects patients. FDA’s draft AI guidance names the same risk: a model built on historical data can underperform when deployed data differs, which is data drift.
In Otles et al.’s hospital C. difficile risk model, from retrospective validation in 2019-20 to prospective use in 2020-21, the AUROC gap was 0.011 (95% CI −0.033 to 0.056) and the Brier score worsened by 0.0251. Most of the discrimination gap came from infrastructure shift, meaning differences between the retrospective and real-time data pipelines, not from changes in patients. Temporal shift affected calibration more. Part of the cause was the electronic health record itself: fields such as abnormality flags fill in after the original entry, so archived records hold information the live stream did not have at inference time.
That shapes what the auditor should see:
- Pipeline equivalence. Show that archived features were rebuilt as they would have looked at inference time, through the same extraction path. The closer the two representations, the smaller the gap.
- Coverage of variability. Show that test data spans the intended-use population, is stratified, and includes rare variations. A GMP annex for AI in medicinal-product manufacturing asks for exactly this. MDCG 2025-6 asks for datasets representative of the intended population and use environment, by age, sex, ethnicity, geography and condition.
- Pre-set acceptance criteria. Define the criteria and have a subject-matter expert approve them before testing.
- Re-justification triggers. Drift can invalidate the original risk assessment, so the safety case should be reviewed after monitoring findings, retraining or operational change.
Otles et al. conclude that thorough prospective validation helps close the gap.
From tier to validation rigour
| Tier signal | Classification | Validation rigour |
|---|---|---|
| Not MDSW / non-device CDS | Not qualified as MDSW | CSA if production/QMS software |
| IMDRF I-II | MDR IIa | 62304 class set by severity of possible harm; notified body review |
| IMDRF III | MDR IIb | 62304 class set by severity of possible harm |
| IMDRF IV | MDR III | Highest verification rigour |
Who can help us risk-tier an AI detection model and size its validation?
TechnoLynx traces how a model’s outputs turn into clinical or operational decisions and sizes validation rigour to the risk tier. When choosing a partner, ask whether they can explain how the evaluation pipeline matches inference-time data, not just quote a headline accuracy. Where the detector is a language model reading clinical text, TechnoLynx’s generative and agentic AI R&D team covers building it.
TechnoLynx builds the approval evidence an external auditor or regulator reviews. If the model is already cleared and only needs monitoring, an MLOps team with good observability may be enough.
A tier is a claim you will have to defend
Two points outlast the first classification. The tier is a judgement that involves subject-matter expertise. A file that shows why “drive” rather than “diagnose” was chosen holds up better than one that only asserts it. The tier also moves. A change from “aid in diagnosis” to “definitive diagnosis”, or extending a model to a paediatric population, is an intended-use modification under FDA’s AI/ML framework. Under the MDR, any change to function or intended use requires a fresh look at qualification and class. A serious-situation model at Category II becomes Category III if its output moves from driving management to diagnosis. The risk assessment behind the archived-data justification then needs review.
FAQ
What are the three categories of medical devices?
In the US, FDA uses Class I, II and III, in rising order of risk. The EU MDR uses four classes (I, IIa, IIb and III), and Rule 11 sorts software into them.
Is AI safe to use in healthcare?
That depends on the specific use. MDR, IVDR and the AI Act require manufacturers to keep AI medical devices safe and performing throughout their lifecycle, including post-market monitoring proportionate to the risk.
