The 510(k) Pathway: Substantial Equivalence to a Predicate

The most common pathway for AI medical devices. How to identify predicates, what "substantial equivalence" means, timeline and cost, and what a complete submission includes.

The 510(k) pathway is the workhorse of medical device regulation. It’s the route most AI diagnostic tools and decision-support systems take to get FDA clearance. The basic idea is that if your device is substantially equivalent to a device the FDA has already approved (called a predicate), you don’t need to go through the full premarket approval gauntlet. You submit a focused package of evidence showing equivalence, the FDA reviews it, and you get clearance in somewhere between three and six months.

For Class II devices (which is where most AI falls, as we discussed in device classification), the 510(k) pathway is usually your goal. It’s faster than a full PMA, cheaper than a full PMA, and the FDA has built institutional knowledge around how to evaluate 510(k) submissions for digital health tools. The tradeoff is that you need to find a suitable predicate device and prove that your device is comparable.

This section walks you through what that actually means, what the process looks like, what it costs, and where the pit traps are lurking.

Substantial Equivalence: The Core Concept

Here’s the legal definition of substantial equivalence: your device has the same intended use as the predicate device, it has the same technological characteristics, and any different characteristics don’t raise new or different safety/effectiveness questions. Let’s unpack that.

Same intended use means you’re solving the same clinical problem in the same clinical context. If the predicate is a CADe system for detecting lung nodules on CT scans, your device should also be for detecting lung nodules on CT scans. Not “detecting any suspicious finding,” but specifically lung nodules. Intended use is about specificity.

Same technological characteristics means the same general approach. However, your technology doesn’t have to be identical to the predicate’s. You could use a deep learning model while the predicate used random forests. You could use a different neural network architecture. You could have different preprocessing steps. The important thing is that these differences don’t introduce new safety or effectiveness concerns. If the predicate was a 2D image analysis tool and you’re proposing a 3D volumetric analysis tool, that’s potentially a different technological characteristic. To stick with a 510(k), which is absolutly what you want to do, you need to explain why that difference is safe and effective.

The FDA’s practical guidance on this is that if you can find a predicate with the same intended use and you can argue (by which we mean provide evidence) that your approach is equivalent or better, you’re on solid ground. The art is in finding a predicate that’s close enough, then documenting why the differences don’t matter.

Finding and Justifying Your Predicate

This is where a lot of people spend their first serious effort (or their first serious coin, hiring a consultant). You need to search the FDA’s 510(k) database and identify a device that’s similar enough to serve as your predicate.

Start with the FDA 510(k) database. You can search by device type, intended use, keywords, or product code. If you’re building a chest X-ray analysis tool, search for “chest X-ray” or look up the relevant product codes. You’ll see thousands of submissions for devices already cleared.

Look for devices with similar intended uses. Read their 510(k) summaries (or full submissions, if available). Pay attention to:

What clinical problem they solve
What the output looks like (binary classification, risk score, region of interest, flagged findings)
What role the clinician plays (reviewing findings, making final diagnosis, deciding on treatment)
What imaging modalities or data types they handle
What performance metrics they reported

You might find one device that’s very close to what you’re building, or you might find several with similar intent but different technical approaches. Either way, document these candidates. You’ll discuss your predicate choice in your Q-Submission (more on that below). As you search for a credible predicate, though, don’t be tempted to stretch a predicate too far just because you don’t want to go through the De Novo pathway. If your device is genuinely different in intended use or technological approach, the FDA will notice. There are no loopholes here, regard this as a search for the truth. A weak predicate justification can slow down your submission or even lead to rejection. Better to acknowledge upfront that no good predicate exists and plan for De Novo from the start. It won’t be the end of the world, especially if you recognize it early.

What Goes into a 510(k) Submission

Once you’ve identified your predicate, you’ll assemble a submission package. The FDA has a standard format and required contents. Here’s what a typical 510(k) for an AI/ML device includes:

Regulatory information: The name and intended use of your device, the predicate device you’re claiming equivalence to, and your company’s registration details.

Device description and specifications: What your device does, how it works (in non-jargony terms), inputs and outputs, and what hardware/software platforms it runs on. For AI devices, this includes a high-level description of the model architecture (without disclosing proprietary algorithm details, since all this data will be public).

Predicate equivalence justification: Detailed explanation of why your device is substantially equivalent to the predicate. You describe the intended use, the technological approach, and note any differences along with your arguments why those differences are not clinically significant.

Analytical validation studies: Evidence that your algorithm works as claimed. This typically includes studies showing that your model’s outputs are accurate, reliable, and consistent. You will include performance metrics like sensitivity, specificity, AUC-ROC, and confusion matrices (which metrics are approriate depends on the type of model, see section 4, “Evaluating Models”). Include tests on holdout datasets and external validation if available.

Clinical validation studies: Evidence that your algorithm performs as claimed in actual clinical use or in a realistic clinical setting. This might be a retrospective study where clinicians use your algorithm on real patient data, or a prospective pilot study. The FDA wants to see that the AI’s outputs match what the algorithm promised.

Software documentation: You need to document your software development process, which to the FDA means documented processes and artifacts for requirements, testing, version control, and cybersecurity measures. The FDA wants to know that you built this professionally and that you’ll maintain it. What they mean by “professionally” aligns well with a 1980’s style waterfall process (as defined in IEC 62304). You will not convince them otherwise, and must adapt your process to produce the documentation they want to see.

Risk analysis and mitigation: You identify potential failure modes (what could go wrong), assess the risk, and explain how you’ve designed the device to mitigate that risk. For an AI tool, this might include: model drift over time (you have monitoring in place), adversarial inputs (you test edge cases), or cybersecurity vulnerabilities (you follow NIST standards).

Labeling and instructions for use: What will you tell clinicians and end users about how to use your device, what it does, what it doesn’t do, and what risks or limitations they should know about. This becomes your IFU (Instructions for Use) document.

Timeline and Cost

A 510(k) review by the FDA takes roughly 90 days from submission to decision, if your submission is complete. In practice, the FDA often sends you deficiency letters asking for clarification or additional data, which extends the timeline. Budget 3-6 months from submission to final clearance when you include back-and-forth.

The front-end work, before you submit, is what varies wildly. If you’ve already been running validation studies as part of your research, you might be ready to submit in 3-4 months. If you’re starting from scratch, doing clinical validation, and assembling the regulatory package, you could be looking at 9-12 months of preparation.

The FDA user fee for a 510(k) is approximately $6500 for small businesses and higher for larger companies (as of 2026; check the FDA website for current fees). Beyond the user fee, you need to budget for the actual work: hiring regulatory consultants (if you don’t have in-house expertise), conducting validation studies, writing the regulatory documents, and managing the FDA interactions. A well-executed 510(k) with external support typically costs $150K in total out-of-pocket costs for simple cases, up to $400k for more complex situations.

The Q-Submission: Your Pre-Submission Meeting with the FDA

Before you commit to all that work, there’s a strategic move available: the Q-Submission (sometimes called a Pre-Submission meeting). This is a formal written request to meet with the FDA before you submit your actual 510(k). You tell them, in writing, what device you’re planning to develop, what predicate you’re thinking of using, and what questions you have. The FDA responds, in writing, typically within 75 days, with guidance on your regulatory pathway.

This is free and it’s strategically valuable. You’re essentially asking the FDA, “Is the 510(k) pathway appropriate for my device? Is this predicate acceptable? Do you have any concerns about my approach?” The FDA gives you written answers that you can rely on. If they say “yes, this predicate works and your planned validation studies are sufficient,” you know you’re on the right path. If they say “no, we don’t think this is a good predicate, consider De Novo instead,” you’ve just saved yourself months of wasted effort.

The Q-Submission is a best practice. Almost every successful AI device sponsor does one. It costs only the staff time to prepare a good Q-Submission letter, and it de-risks your regulatory strategy significantly. You can have back-and-forth questions with the FDA during the process, which helps you refine your approach before you’re locked into a full submission.

The trade-off is that the Q-Submission process adds 2-3 months to your timeline upfront. But if it steers you away from a bad predicate or confirms you’re on the right track, it’s time well spent.

Common Pitfalls

Weak predicate selection: You find a device that’s sort of similar and claim equivalence without really thinking through the differences. Maybe the predicate was for 2D image analysis and you’re doing 3D, or the predicate was for screening and you’re building a diagnostic tool. The FDA will ask you to justify why these differences don’t matter, and if you can’t, your submission stalls. This is the most common reason for deficiency letters.

Incomplete validation studies: You submit performance metrics from your training dataset but not from an external test set. Or you report sensitivity and specificity but not the false positive rate, which is clinically important for your use case. The FDA wants to see that you’ve actually validated your device, not just built a good research model. Incomplete data leads to deficiency letters and delays.

Vague intended use statements: You say your device is “for diagnostic imaging” instead of “for assisting radiologists in identifying lung nodules on chest CT scans.” Vague intent makes it hard to justify your predicate and hard for the FDA to evaluate your submission. Keep intended use specific.

Underestimating software documentation: You built the algorithm in a research environment (notebooks, lots of ad-hoc scripts, maybe some manual preprocessing steps). Now you’re trying to package it into a regulatory submission and realizing you haven’t documented the development process well. This is fixable, but it takes time: some companies have had to re-do many of the experiments using more formal processes. You can probably find software that makes this problem go away entirely (cough, cough ).

Not engaging with the FDA early: You build everything, think you’re ready, submit, and get a deficiency letter saying they wanted to see something specific that you didn’t plan for. This is why the Q-Submission exists, and why it’s foolish to not use it.

When 510(k) Isn’t the Right Path

If you search and search and can’t find a suitable predicate device, the 510(k) pathway isn’t available to you. This is when you pivot to the De Novo pathway. A De Novo is more expensive and takes longer, but it’s the right answer if you’re truly building something novel that doesn’t fit existing device classifications.

Key Takeaways

The 510(k) pathway is the most common route for Class II AI devices, based on proving substantial equivalence to a predicate device
Intended use and technological characteristics define substantial equivalence, both to the predicate and in your own device description
Search the FDA 510(k) database to identify candidate predicates with similar clinical intent
A typical 510(k) submission includes predicate justification, analytical and clinical validation studies, software documentation, risk analysis, and labeling
Timeline: 3-6 months preparation, 90 days FDA review (plus back-and-forth time)
Cost: ~$22K user fee plus $50K-$150K for the full submission package (consultant support, validation studies, documentation)
Use a Q-Submission (Pre-Submission meeting) before committing to your full submission; it’s free, clarifies pathway, and de-risks your strategy
Common pitfalls: weak predicate selection, incomplete validation studies, vague intended use, poor software documentation
If no suitable predicate exists, pivot to De Novo pathway