The first time a research model I had worked on was seriously proposed as a product, the conversation I remember was not about accuracy. It was someone from the regulatory side asking what the intended use statement said, and the room discovering that nobody had written one.
That is the recurring pattern. Engineering teams treat regulation as a gate at the end — a submission you prepare once the model works. It is closer to a specification you should have been building against from the start, because the questions it asks are mostly about evidence you cannot generate retrospectively.
What follows is an orientation to the shape of the regime, written from the development side. It is deliberately light on specific numbers, because the specifics change, vary by product, and are what you hire regulatory professionals for. Anyone using this as a substitute for that advice is making a mistake.
First question: is it a device at all?
Not all clinical software is regulated as a medical device, and this is the first thing to establish because everything else depends on it.
In the US, software intended for diagnosis, treatment, prevention or mitigation of disease generally falls within the device definition. Certain clinical decision support software is carved out by statute, under criteria added by the 21st Century Cures Act. The criteria are specific and the FDA has published guidance interpreting them, but the intuition behind them is worth understanding: software that presents information to a clinician in a way that lets them independently review the basis for the recommendation is treated differently from software that produces an output the clinician is expected to rely on without being able to evaluate how it was reached.
That distinction cuts against opaque models in an interesting way. A tool that shows its inputs and reasoning has a stronger claim to the exclusion than one that emits a score. Whether a deep learning system can ever satisfy the independent-review criterion is a live question, and most imaging AI does not try — it accepts device status.
Elsewhere the analysis differs. In the EU, the Medical Device Regulation's classification rule for software pushed most clinical software into a class requiring notified body involvement, which was a significant change from the previous directive and caught a lot of products out.
The US pathways, and why the vocabulary matters
There are three principal routes to market, and people conflate them constantly. The FDA's own overview of device approvals and clearances is the authoritative description and distinguishes between them explicitly.
510(k) rests on demonstrating substantial equivalence to a legally marketed predicate device. The output is a clearance, not an approval. This is how the overwhelming majority of AI imaging software has reached the US market. It does not require demonstrating clinical outcome benefit; it requires showing your device is as safe and effective as the predicate for the same intended use.
De Novo exists for novel devices of low to moderate risk that have no suitable predicate. A successful De Novo request creates a new classification, which then becomes available as a predicate for others. Genuinely new categories of AI device — the first autonomous diabetic retinopathy screening system, the first AI pathology product — arrived this way.
Premarket approval (PMA) applies to the highest-risk class and requires valid scientific evidence of safety and effectiveness, typically clinical trial data. Very little imaging AI sits here.
The words are not interchangeable. "FDA approved" is a specific and stronger claim than "FDA cleared," and using the former when you mean the latter is both a marketing problem and, in promotional material, a compliance one. It is also the single most common inaccuracy in writing about this field.
Worth being clear on what a clearance does and does not tell you. It says a regulator reviewed the submission and found the device substantially equivalent for a stated intended use. It does not say the device improves outcomes, that it will perform the same way at your hospital, or that it was tested on a population resembling yours.
What the evidence package is actually about
The intuition engineers arrive with is that the regulator wants to see high accuracy. What they want to see is that you know what your device does, under what conditions, and how you established it.
The intended use statement is the foundational document and is narrower than people expect. It names the clinical task, the patient population, the care setting, the user, and often the compatible imaging equipment. Everything else in the submission is evidence about that statement. Widen the statement and you widen the evidence burden; a common and expensive mistake is claiming a broader indication than the data supports.
Validation data independence is scrutinised carefully. Test data must be genuinely separated from training and tuning data — not just a random split, but separated by site and by patient where it matters. Patient-level leakage, where multiple studies from the same person land on both sides of the split, is a classic finding.
Subgroup performance is increasingly expected rather than optional. How does the device perform across age, sex, race and ethnicity, across scanner manufacturers, across image quality strata? Reporting only an aggregate figure invites the question.
Reference standard definition matters as much as the results. How was ground truth established, by whom, with what qualifications, and with what adjudication when readers disagreed?
Software lifecycle and risk documentation is the part engineering teams most underestimate. The expectations are set by recognised standards — software lifecycle processes, risk management, and a quality management system — and they are about process evidence rather than product performance. Requirements traced to design outputs traced to verification. A risk analysis identifying hazards and the controls mitigating them. Version control and change management you can demonstrate. Retrofitting this onto a research codebase after the fact is miserable and expensive, which is the practical argument for adopting it early.
The problem the regime was not built for
Conventional devices do not change after clearance. Models can, and the whole value proposition of machine learning is partly that they should — retrained on more data, adapted to a new scanner, improved as the field advances.
Under the traditional framework, a significant modification means a new submission. Applied literally to a model you want to retrain quarterly, that is unworkable.
The FDA's response has been the predetermined change control plan: a manufacturer specifies up front what modifications they anticipate making, how they will be implemented, and how each will be validated. The agency's programme on artificial intelligence and machine learning in software as a medical device sets out this thinking, alongside the good machine learning practice principles developed jointly with the Canadian and UK regulators.
This is a sensible accommodation and it has limits. The plan has to be specified in advance, which means you need to know at submission time what kinds of change you will want to make. Genuinely unanticipated changes still need a new submission.
The rest of the world, briefly
The EU route runs through conformity assessment against the Medical Device Regulation, performed by a notified body, resulting in a CE mark. This is a different mechanism from FDA review rather than a translation of it — it is a third-party assessment against the regulation's requirements, and notified body capacity has been a real bottleneck since the MDR came into force. Note that the EMA is not involved; it regulates medicines, not devices, and the two are frequently confused.
Layered on top in the EU is the AI Act, under which AI systems that are safety components of products requiring third-party conformity assessment are treated as high-risk, bringing additional obligations around data governance, documentation, transparency, human oversight and post-market monitoring. For a medical imaging AI product this means satisfying two overlapping regimes.
The UK operates its own route through the MHRA. Other major markets — Canada, Japan, Australia, Brazil, India — each have their own frameworks, with varying degrees of reliance on FDA or EU decisions.
What I would tell an engineering team
Write the intended use statement first, before the model. It disciplines everything, and discovering late that your data does not support the indication you wanted is the expensive failure mode.
Design the validation split for the submission you will eventually make, not for the paper. Site-level and patient-level separation, planned from the start.
Stratify every result you report internally. If a subgroup gap exists you want to find it in month six, not in a review question.
Adopt the lifecycle process early. It feels like overhead when there are three of you; it is far cheaper than reconstructing traceability for two years of work.
Decide what you will want to change post-market, and design the change control plan around that reality rather than hoping the question does not come up.
And treat clearance as a beginning. The obligations that follow — adverse event reporting, monitoring real-world performance, managing modifications — run for the life of the product, and they are where the resourcing is most often forgotten.
Tags
Taresh Sharan
support@sharaninitiatives.com