Clinical Validation Requirements for AI Diagnostic Software

1,357 AI and machine learning devices had cleared or been approved by the FDA through late 2025, according to a systematic analysis in PLOS Digital Health. That number alone tells you something changed. Annual approvals grew roughly twentyfold between 2015 and 2023 compared to the prior two decades, and orthopaedic surgery devices alone jumped from a three-year average of 3.0 clearances a year (2017-2019) to 16.6 a year (2022-2024). Fast growth like that usually means one of two things happened: either the bar dropped, or more people learned how to clear it.

The second explanation holds up better. But it comes with a catch I'll get to later, when the actual evidence behind some of those approvals turns out to be thinner than the headline number suggests. What follows is a walk through the sequence that takes a device from concept to clearance and, more to the point, keeps it there.

Where an AI diagnostic tool sits in the regulatory classification system before any validation begins

Before anyone enrolls a single patient, the FDA has already made the decision that shapes everything downstream: what risk category does this thing belong to? AI diagnostic software falls under the Software as a Medical Device umbrella, and its tier, low, medium, or high, decides how much proof you'll eventually owe.

Three pathways exist, and they are not evenly used. The 510(k) route, which asks you to show your device is substantially equivalent to something already on the market, accounted for 97% of AI-enabled device clearances as of August 2024. De Novo, reserved for low-to-moderate risk devices with no existing predicate, covered 22 devices in that window. Premarket Approval, the toughest road, applied to just 4 AI devices. Line those numbers up and the pattern is hard to miss: almost everybody finds a predicate.

That 97% is a decision point, not a shortcut. Picking the right predicate is the first real technical judgment a developer makes, and getting it wrong poisons everything downstream. Choose a predicate that doesn't hold up under scrutiny, and the whole submission starts to wobble before it even gets read closely.

Clinical decision support tools carry their own wrinkle. Make a specific diagnostic or treatment call, and your software gets regulated. Just match patient data against standard guidelines for common conditions without pushing toward a particular decision, and you might be exempt. Small distinction on paper. It decides whether you're staring down a full validation program or something considerably lighter.

Cross the Atlantic and the rules change shape entirely. The EU AI Act, Regulation 2024/1689, took effect in August 2024 and labels any AI-enabled medical device "high-risk" automatically. EU developers stack two frameworks from day one, the Medical Device Regulation and the AI Act, running side by side. A 2025 revision to guidance document MDCG 2019-11 widened how Rule 11 gets read, weighing how autonomous the software is and whether it plays a primary or supporting role in diagnosis. Most AI diagnostic tools land in Class IIa, IIb, or III depending on those answers.

China adds a third data point for anyone thinking beyond two markets. By mid-2023, 59 AI medical devices had cleared there, per Liu and colleagues writing in Nature Digital Medicine in 2024, and novel algorithms face a comparatively stringent review process.

None of this is paperwork you file and forget. Classification decides whether a reader study satisfies reviewers or whether a prospective randomized trial gets required instead. Get it wrong early, and you find out the hard way, usually a year and a budget later, holding evidence that answers the wrong question.

The technical and quality standards that must be in place before clinical testing starts

Regulators on three continents agree on one thing, at least: Good Machine Learning Practice. In 2021 the FDA, Health Canada, and the UK's MHRA jointly released ten guiding principles under that name. In January 2025 the International Medical Device Regulators Forum published a convergence document, IMDRF/AIML WG/N88 FINAL:2025.

What does GMLP actually ask for before anyone touches a patient? Dataset independence sits at the top. Training data and test data can't overlap, not by patient, not by acquisition site, not by anything that lets a model quietly memorize its own answer key. Datasets also need to represent the population the device will serve, across age, sex, race, and ethnicity, not just whichever hospital happened to have a convenient data-sharing agreement on file. The software has to come out of recognized engineering discipline too: IEC 62304 in the EU, and equivalent engineering discipline requirements in the US.

Risk management documentation needs to exist before the clinical study starts, not after it wraps. Regulators want the risk analysis shaping how the study gets designed, not explaining away results that already happened. That ordering matters more than it sounds like it should.

In Europe, quality management and IEC 62304 lifecycle compliance are the entry fee for CE marking under MDR, not optional add-ons. The FDA's January 2025 draft guidance on Total Product Lifecycle management makes the underlying philosophy explicit: design controls, testing, and real-world surveillance run as one continuous thread, not three separate projects tossed between departments like a hot potato nobody wants to own.

Here's where developers actually get burned. A team starts its clinical study before locking down dataset independence, then finds out during submission review that the training-test split had quiet overlap. Maybe a handful of patients showed up in both buckets. Maybe images came from the same scanner sharing a calibration file. Either way, the study is compromised and needs a rerun, an expensive way to learn a lesson GMLP spelled out from the start.

What the performance evaluation must actually demonstrate, and how study design determines whether it does

Two separate questions get asked here, and conflating them is a common mistake. Analytical performance asks whether the algorithm gets the right answer against a known gold standard: sensitivity, specificity, area under the curve, reproducibility. Clinical performance asks something harder: does using this thing actually help, in a real workflow, with real clinicians making real decisions under real time pressure?

The FDA usually wants a reader study to answer that second question, one where multiple clinicians evaluate the same cases with and without AI help, to see whether the tool moves diagnostic performance rather than just looking good on a spreadsheet.

IDx-DR, the autonomous diabetic retinopathy screener, is the case everyone points back to. Its clearance rested on a prospective trial of 900 patients, landing at 87.2% sensitivity and 90.7% specificity, clearing the pre-set targets with room to spare. That trial reads almost like a template now: prospective, run in the intended setting, targets fixed in advance rather than discovered after the fact.

Study design follows something close to a hierarchy in practice. Retrospective validation on historical data is the floor, necessary but no longer sufficient on its own in the eyes of most reviewers or peer journals. Prospective studies run in the actual clinical workflow sit above that, and they're now strongly preferred for 510(k) and De Novo filings. Randomized controlled trials sit at the top, required for the highest-risk applications and increasingly expected to show an actual outcome benefit, not just a bump in diagnostic accuracy.

Why does this hierarchy matter so much? Performance measured in a lab doesn't always survive contact with an actual hospital. A 2022 systematic review found that 81% of deep learning algorithms underperformed when tested on external datasets outside their original training environment, with 49% showing a modest drop and 24% showing something substantial. A device that looked great at home and stumbled the moment it left the driveway.

A related pattern emerges when models move out of retrospective evaluation and into live deployment: the performance measured in controlled settings does not always hold once a device meets real-world variation. Submissions built only on retrospective data run into this gap eventually, usually right after clearance, which is the worst possible moment to meet it.

The EU has started writing this expectation directly into law. Under the AI Act, test datasets must be, in the regulation's own words, relevant, representative, free of errors, and complete, with appropriate statistical properties. Not aspirational language. Regulatory text, with enforcement behind it.

Why the current evidence base for cleared devices is weaker than the approval count implies

Despite a rapidly growing approval count, the evidence base behind many cleared AI devices remains thinner than the headline numbers suggest. A scoping review of 692 FDA-approved AI and machine learning devices spanning 1995 to 2023 turned up gaps that are hard to read as anything but concerning. Only 3.6% of approvals reported race or ethnicity data, and 99.1% gave no socioeconomic data at all. Age of study subjects went unreported in 81.6% of cases. Only 46.1% offered detailed, full results from their performance studies, and just 1.9% linked to a published paper with safety and efficacy data. Only 9.0% included a prospective study for post-market surveillance.

Orthopaedic devices tell this story with unusual clarity, and it's a genuinely mixed picture. Devices cleared between 2017 and 2019 lacked any clinical testing in 62.2% of cases. That fell to 19.7% for devices cleared between 2022 and 2024, real progress by any reasonable measure. Zoom out across the full dataset, though, and 22.8% still lack clinical testing entirely, 68.6% rely only on retrospective data, and just 8.6% went through a formal prospective trial.

A 2026 systematic review in PLOS Digital Health looked at 50 studies of AI clinical decision support tools and found prospective validation in only 8% of them, four out of fifty. Algorithmic bias got an explicit assessment in just 4%, two studies. Around 70%, thirty-five of the fifty, had no external validation at all.

None of this indicts devices already on the market. It's a snapshot of where the field has been standing, useful mainly so anyone building a new submission understands what "meeting current expectations" actually requires now. Regulators know this history too, which is exactly why the FDA's January 2025 TPLC guidance and the EU's 2026 compliance deadline both signal a floor that's rising underfoot. A submission that sailed through review in 2020 isn't guaranteed the same welcome in 2026. Treating past clearance patterns as a map for future ones is asking for trouble.

How algorithmic bias becomes a validation requirement, not just an ethical consideration

Only 4% of AI clinical decision support studies in that 2026 review explicitly checked for algorithmic bias, even though regulators now expect it demonstrated, not assumed. That gap between what's been done and what's required is exactly where a lot of future submissions are going to trip.

The real-world consequence isn't hypothetical. AI diagnostic tools trained on non-representative populations have shown measurably worse performance in underrepresented groups. That traces back to who was and wasn't represented in the training data, not some flaw buried in the math. Skewed input produces skewed outcome; the algorithm just does what it was taught to do.

GMLP spells out the fix. Study participants and datasets need to reflect the population the device will actually serve, with age, sex, race, and ethnicity represented in reasonable proportion. Training and test data need enough independence that hidden demographic clustering doesn't mask a subgroup where the model quietly performs badly. Performance results need to be broken out by subgroup, not folded into one tidy aggregate number that hides more than it reveals.

Europe has written this straight into law. The AI Act's data governance rules require training and validation data to be high-quality, representative, and checked for bias, which moves bias mitigation from an ethical nice-to-have into a legal obligation with teeth. The FDA's January 2025 TPLC draft guidance does something similar, naming algorithmic bias and transparency as things a submission has to address, framed as an ongoing lifecycle concern rather than a box checked once before launch and forgotten.

What does this mean for how a study actually gets built? Subgroup breakdowns have to get planned at the protocol stage, before a single patient enrolls. Trying to retrofit demographic analysis onto a study that was never sized to detect subgroup differences won't satisfy a reviewer looking for real evidence. It's a bit like trying to weigh a package after you've already thrown out the box; the number you get back isn't the number that matters.

Predetermined Change Control Plans and why adaptive AI needs a different submission strategy

Predetermined Change Control Plans give developers a pre-approved framework for updating adaptive AI without triggering a full new submission for every retraining cycle. Traditional device regulation runs on a simpler rule: change the software in a meaningful way, file a new submission. Fine for a pacemaker's firmware. It falls apart for an AI model built to keep learning from new data, because under the old logic, every meaningful retraining cycle triggers another round of review, indefinitely.

Predetermined Change Control Plans, PCCPs, are the FDA's answer to that treadmill. A developer defines in advance which kinds of modifications are allowed and exactly how each will be carried out and verified. Stay inside that pre-approved plan, and the change goes through without a fresh submission every time.

The December 2024 final guidance, fully in effect since August 2025, lays out three required sections. Section I describes the modifications anticipated and what falls inside scope. Section II is the device modification protocol, covering how each change gets developed, tested, and verified. Section III is the impact assessment: how the developer confirms the modified device is still safe and effective once the change goes live.

A PCCP isn't a free pass to update whatever, whenever. The modification protocol has to spell out validation requirements for every anticipated change, so the clinical evidence burden doesn't vanish. It just moves earlier, into the protocol's design, instead of getting resolved case-by-case after the fact.

There's a strategic wrinkle here too. A developer who builds a PCCP into the original 510(k) or De Novo filing gets a kind of flexibility that a competitor filing years later, without one, will find hard to bolt on after the fact.

Europe is heading toward something similar in spirit, if not in exact mechanism. The AI Act's requirements for ongoing monitoring and logging of AI system behavior serve a comparable purpose. Regulators on both sides of the Atlantic are converging on the same underlying idea, whether they'd phrase it this way or not: accountability across the device's whole lifecycle, not one verdict handed down at the moment of clearance.

Post-market surveillance obligations that now begin at submission, not after clearance

The FDA's January 2025 TPLC draft guidance requires postmarket performance monitoring plans to be described in the submission itself, written down before clearance is even granted, not drafted afterward or promised in some follow-up letter that may or may not show up.

What actually belongs in a monitoring plan that holds up under scrutiny? Real-world performance needs tracking against the same metrics the premarket study established, so there's a consistent baseline to measure drift against. Subgroup performance needs its own separate tracking, since deployment populations rarely match validation cohorts exactly, and bias invisible at launch can surface once the device reaches a wider, messier patient base. Logging and transparency requirements need to let someone reconstruct, after the fact, how an AI-assisted decision actually got made. And there need to be pre-specified triggers: a performance drop past a defined threshold should force a new submission or a PCCP amendment, not a shrug and a wait-and-see approach.

Only 9.0% of those 692 reviewed FDA-approved devices from 1995 to 2023 included a prospective post-market surveillance study. That's the baseline current expectations are moving sharply away from, and fast.

Europe's timeline adds real pressure to get this right. August 2026 is the compliance deadline for core AI Act obligations, including conformity assessments and human oversight requirements for high-risk AI systems. August 2027 applies to AI systems already regulated as medical devices under MDR or IVDR that need Notified Body assessment. Fixed runway, not a suggestion, and developers building for the EU market should treat those dates accordingly.

GMLP's tenth principle, tucked at the end of the original ten, covers human-AI team performance and real-world monitoring after deployment. It matters just as much as the first nine. Regulators increasingly treat the moment a device goes live as the start of a new data collection phase, not a finish line. A developer who treats clearance as the finish line tends to find the device flagged down the road in post-market review, while one who treats the postmarket plan as part of the original clinical validation package, built alongside the premarket study rather than bolted on afterward, ends up with the infrastructure to keep that clearance standing, and to make good use of a PCCP the next time a model update is ready.