FDA Clearance for Health Software: The Complete Guide

Getting a piece of health software through FDA takes a sequence of decisions: whether it is a device at all, which of three pathways fits, how you build a predicate argument (or a direct safety case, if you have no predicate to lean on), what documentation FDA actually expects, and how you run the quality system underneath all of it. This guide walks the full sequence in order, links out to the deep-dive spokes on each stage, and adds the decision structure, the review-friction reality, and the AI-specific mechanics that tie them together into one route.

In short: Getting health software through FDA means: confirm it's a device, pick the pathway — 510(k) with a predicate, De Novo without one, PMA for Class III — then build submission-grade documentation. First-time 510(k)s typically run 6–12 months from submission to clearance, and by one industry estimate roughly two-thirds face some form of hold or additional-information request, mostly on preventable gaps.

On this page: Device determination recap · Pathway choice: 510(k), De Novo, PMA, 513(g) · Predicate strategy · The Pre-Sub playbook · Software documentation · AI/ML extras and the PCCP · QMSR: the quality layer · The review: holds and deficiencies · After clearance · FAQ

Is my software even an FDA device? A quick recap

Before any of the pathway or documentation questions below matter, one question has to be settled first: does FDA regulate your product as a medical device at all? That determination turns on intended use and function, against the device definition in section 201(h) of the Federal Food, Drug, and Cosmetic Act. Whether it involves health data or runs on a phone doesn't decide it. Software that diagnoses, treats, monitors, or makes a specific clinical recommendation about an identifiable condition is very likely a device. Software that supports general wellness, without a disease-specific claim (per FDA's General Wellness: Policy for Low Risk Devices final guidance, September 2019), or that meets the four-part clinical decision support carve-out test under FD&C Act §520(o)(1)(E) (added by the 21st Century Cures Act) — no direct analysis or interpretation of medical images or signals, support rather than replacement of clinical judgment, a clinician able to independently review the basis for the recommendation, plus direction to a healthcare professional rather than a patient — may sit outside FDA's device definition entirely. One caution before relying on the CDS carve-out: FDA's final CDS guidance (September 2022) reads it narrowly — "signals" reaches patterns and signals from signal-acquisition systems, and the independent-review condition is applied strictly — so more CDS software qualifies as a device than founders tend to expect.

This determination is the foundation everything else in this guide sits on top of, and it deserves more space than a recap chapter can give it: the pillar on classification under MDR and FDA rules covers the full determination logic, worked examples across the device/non-device boundary, and how the same underlying question gets asked (and answered differently) on the EU side under MDR Rule 11. If you have not yet run your product through that determination, start there. Pathway choice, predicate strategy, and documentation planning only become live questions once it's settled.

One thing worth stating plainly here, because it recurs throughout the rest of this guide: FDA's device determination and its classification into Class I, II, or III are related but distinct steps. Class I is mostly self-certified and rarely reaches the pathway questions this guide focuses on. Class II is where the large majority of health software lands, and where the 510(k)/De Novo choice below actually gets made. Class III is where PMA lives. If you already know your likely class from the classification guide above, you can move directly to the pathway chapter below with a head start on which branch of the decision structure applies to you.

It's also worth naming a pattern specific to software, since it trips up more founders than the classification logic itself: a device determination is not fixed for the life of your product. A feature you add later can move the needle. A new clinical claim, a recommendation engine layered on top of what was previously a passive display tool, an alert threshold that starts to look like a diagnostic call rather than an informational one — any of these can move a product that was genuinely outside FDA's device definition into it, or push a Class I self-certified product into Class II territory, where FDA premarket review (a 510(k) or De Novo — conducted by FDA itself, not a third party) suddenly applies. Teams that treat their original device determination as a one-time gate, checked once at incorporation and never revisited, are the ones most likely to discover the problem late. Usually the discovery comes from an investor's diligence question or a partner's legal team, not from FDA directly, and by then a roadmap feature has quietly changed the product's regulatory status months before anyone flagged it internally. Revisiting the determination at each major feature or claim decision is cheap; discovering the gap after the feature has already shipped to users is not.

Which FDA pathway fits: 510(k) vs. De Novo vs. PMA vs. 513(g)

Once you know you are building a device, the next decision is which of FDA's premarket pathways to pursue. This decision shapes your engineering priorities, your evidence budget, and your fundraising timeline, not just your regulatory paperwork. There are three substantive pathways, plus one classification tool that sits alongside them rather than acting as a fourth pathway.

The four options in one table

All cost and timeline figures above are industry-cited ranges, sourced from regulatory-consultancy benchmarking rather than FDA-published statistics or a Venitara guarantee — treat them as planning context, not a quote for your specific device. 510(k) vs De Novo vs PMA: Which FDA Pathway goes deeper on the decision logic below, including the flowchart form and three fully worked examples (one per pathway), and Why Most 510(k)s Get an Information Request breaks the 510(k) figures down further.

The decision structure

The pathway decision runs through a small number of genuinely sequential, mostly binary questions:

START: Is your device high-risk — supports or sustains life, is
       implanted, or carries significant potential risk of illness
       or injury if it fails?
│
├─ YES → PMA is your likely route. Full premarket approval,
│        device-specific clinical data, regardless of whether a
│        predicate exists. This is the only pathway where
│        "approval" is the correct term.
│
└─ NO → Does a legally marketed device already exist with the
         same intended use and similar technological
         characteristics to yours?
         │
         ├─ YES → 510(k) is your likely route. Demonstrate
         │        substantial equivalence to that predicate.
         │        If technological differences exist, confirm
         │        they don't raise new safety/effectiveness
         │        questions — this is where predicate strength
         │        matters most (see the next chapter).
         │
         └─ NO → Is your device low-to-moderate risk despite
                  having no predicate?
                  │
                  ├─ YES → De Novo is your likely route. FDA
                  │        reviews directly against general and
                  │        special controls; a grant creates a
                  │        new device classification (and,
                  │        usually, a new predicate category
                  │        future entrants can cite).
                  │
                  └─ GENUINELY UNSURE at any branch above →
                           File a 513(g) request: ask FDA
                           directly how it would classify your
                           device before committing to a full
                           submission strategy.

Two things worth adding to this structure that a flowchart alone won't tell you. First, the "high-risk" branch at the top simplifies a genuinely more nuanced classification exercise: a device can sit closer to a boundary than a binary yes/no suggests, and a "maybe" at any branch is a signal to use the 513(g) option rather than guess. Second, the branches are not equally reversible. Discovering mid-review that your chosen predicate does not hold up is a materially more expensive correction than discovering it during Pre-Sub planning — which is why the next two chapters, predicate strategy and the Pre-Sub playbook, matter as much as the initial pathway choice itself.

510(k): the default for most health software

The 510(k), named for its section of the Federal Food, Drug, and Cosmetic Act, is a comparative pathway. Rather than asking FDA to independently verify your device is safe and effective in isolation, you demonstrate substantial equivalence — same intended use, and, where technological characteristics differ, evidence that those differences don't raise new questions of safety or effectiveness — to a predicate device already legally on the US market. A successful 510(k) results in clearance, not approval. This is the pathway the large majority of AI-enabled and standalone health software targets today, because enough comparable devices now exist across several categories to serve as predicates for new entrants.

De Novo: the pathway for genuinely novel, lower-risk devices

De Novo exists for devices that are low-to-moderate risk but have no suitable predicate, typically because the underlying technology or intended use is genuinely new to the market. FDA reviews the device directly against general and, where established, special controls, rather than against a comparator. A grant results in classification — sometimes described as authorization — and, usefully for a first mover, often creates a new predicate category that subsequent similar devices can then cite in their own 510(k) submissions. The honest cost comparison with a 510(k): De Novo generally takes longer and demands more original evidence, because there is no existing comparator to lean on and FDA is evaluating your safety and effectiveness case more directly.

PMA: the high-risk, Class III route

Premarket Approval is FDA's most rigorous pathway, reserved for Class III devices — generally those that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential unreasonable risk of illness or injury. PMA requires the most extensive evidence of the three pathways, typically including clinical data specific to your device, and correspondingly carries the longest timeline and highest cost. It is also the only pathway where approval is the technically correct outcome term: a 510(k) is cleared, a De Novo is classified or authorized, and using "approved" loosely for either is a factual inaccuracy that regulatory-literate readers, investors, and FDA itself will notice. PMA is rare for software-only devices, generally limited to software that directly controls or is inseparable from a Class III function, such as certain closed-loop therapeutic control systems.

513(g): the classification question, not a fourth pathway

A Section 513(g) request lets you formally ask FDA how it would classify your device, and by extension which pathway would apply, before committing to a full submission. It is narrower than a Pre-Submission meeting (covered in the next chapter but one): specifically a classification question, and it produces a written FDA response rather than an informal consultation. It generally takes a few months and does not commit you to any specific pathway. It is most useful when genuine ambiguity remains after working through the decision structure above — for instance when a candidate predicate exists but its suitability is genuinely unclear.

How do you actually win a predicate argument?

If the pathway chapter above answers "which route," this chapter answers the question that determines whether a 510(k) route actually works for you. Predicate selection is the central strategic decision of a 510(k) — not a formality completed after the real engineering work is done — and it is where most 510(k)s are won or lost.

What makes a predicate strong

A strong predicate shares your intended use closely, not adjacently, and not merely "close enough to explain." Its technological characteristics need to be similar enough that any remaining differences are straightforward to address with existing or readily generated performance data. The strength of a predicate has less to do with how similar the two products look from a marketing description, and more to do with how much of the substantial-equivalence argument the predicate does for you versus how much your own performance data has to carry. A predicate chosen because it is the closest available match, rather than a genuinely suitable one, forces you to carry the burden of proving that meaningful technological differences don't raise new safety or effectiveness questions. That's a harder, more evidence-intensive argument to win, and, per the review-friction discussion in chapter 8, one of the two dominant reasons submissions stall.

A worked comparison: strong predicate vs. weak predicate

Two hypothetical AI-assisted triage tools make the difference concrete. Team A builds a tool that flags likely arrhythmias on a standard 12-lead ECG for physician review, and selects as its predicate an already-cleared AI-assisted arrhythmia-flagging tool with a near-identical intended use statement, the same input modality, and a similar (though not identical) model architecture. The comparison work is genuinely comparative: matching intended use language closely, then building performance data specifically addressing the one meaningful technological difference — a different training approach — and showing that difference doesn't raise a new question about diagnostic accuracy or failure modes. This is a defensible, evidence-focused 510(k) built around a strong predicate.

Team B builds a tool that continuously monitors a novel derived physiological signal, not directly measured by any cleared device, to flag early signs of a specific condition. No predicate measures the same signal for the same purpose, so the team selects the closest analog available: a cleared device that monitors a different but related signal for a related, though not identical, clinical purpose. On paper, the comparison looks plausible. In practice, the intended use doesn't match closely, and the technological differences are substantial enough to raise exactly the kind of new safety and effectiveness questions that a 510(k)'s comparative logic isn't built to absorb. This is the pattern that most often surfaces as a "not substantially equivalent" determination mid-review, and the underlying device usually isn't flawed — the pathway choice itself was optimistic rather than evidence-based. Team B's more defensible route, recognized early rather than after a stalled 510(k), is very likely De Novo.

The predicate-strength checklist

Work through these questions honestly, ideally before you've committed engineering resources to a specific product design:

• Intended use match. Does the predicate's FDA-cleared intended use statement match yours closely, not just the general clinical area? A predicate cleared for a narrower or differently framed intended use than your actual product is a weaker match than it looks on a first read of the 510(k) summary.
• Technological characteristics. Where your device differs technologically from the predicate — a different algorithm class, a different input modality, a different user interface for a clinical decision — can you show the difference doesn't raise a new question of safety or effectiveness, ideally with data rather than argument alone?
• Predicate's own review history. A predicate that itself faced significant scrutiny, multiple Additional Information cycles, or a narrowly worded clearance is a less stable foundation to build a comparison on than one that cleared cleanly with a broad, clearly worded intended use.
• Recency and currency. An older predicate is not automatically weaker, but if the underlying technology category has moved on substantially since it cleared, expect a reviewer to scrutinize technological-difference arguments more closely.
• Multiple candidate predicates. Where more than one plausible predicate exists, the strongest available one — not the first one your team found, and not the one that superficially looks most like your marketing description — should drive the comparison.

Where predicate strategy intersects with product design

The most underused lever here is timing: predicate availability can and should inform product design choices made well before submission. A device engineered with a clear, well-matched predicate in mind from the start avoids the harder De Novo argument later. Conversely, recognizing early that your device is likely headed for De Novo — because it is genuinely novel and no suitable predicate exists — should change your evidence-generation timeline and budget at the fundraising stage, before a 510(k) attempt has already stalled on predicate mismatch.

Multiple predicates, reference devices — and the split predicate FDA rejects

It's worth knowing that a 510(k) is not limited to a single predicate — but the rules on how multiple devices can be combined are stricter than many teams assume, and one popular-sounding approach is explicitly off the table. FDA's 2014 guidance, The 510(k) Program: Evaluating Substantial Equivalence in Premarket Notifications, rejects the "split predicate" approach — citing one predicate for your intended use and a second predicate with a different intended use for your technological characteristics — as inconsistent with the substantial-equivalence standard. If you hear "split predicate" pitched as a strategy, treat it as a red flag: FDA will not accept it, and a submission built on it can burn a full review cycle before that becomes clear. What FDA does permit is multiple predicates that all share the same intended use — useful for software that combines functions each individually precedented in cleared devices with that same intended use — and, separately, reference devices, which can supply supporting technological or performance data but cannot be used to establish your intended use. Either construction is more complex than a single-predicate comparison and more exposed to reviewer questions about whether the combination itself raises a new safety or effectiveness question, so it's worth validating with a Pre-Sub (covered next) before committing to it.

510(k) vs De Novo vs PMA: Which FDA Pathway covers predicate selection as part of the full pathway decision, including worked examples of a strong AI-assisted diagnostic predicate match. Why Most 510(k)s Get an Information Request covers predicate mismatch specifically as the leading substantive cause of review delay, including how it differs in cost and timing from the more mechanically fixable documentation-gap failure mode.

How do you use a Pre-Sub to de-risk the review clock?

FDA's Pre-Submission program — the Pre-Sub, one submission type within the broader Q-Submission (Q-Sub) program — lets you request formal, written FDA feedback on key aspects of your planned submission before you commit to a full filing. It isn't a formal review, and it doesn't guarantee your eventual submission will clear without further questions. Used well, though, it's the single highest-leverage step available to a team before submission, because it substantially reduces the risk of discovering a fundamental predicate or evidence-strategy problem only after submission, when addressing it costs a full review cycle rather than a planning conversation.

What a Pre-Sub is actually for

A Pre-Sub meeting request should be built around specific questions you want FDA's written feedback on, rather than a general "does this look okay" conversation. The questions that get the most useful answers tend to fall into three categories: predicate suitability (does FDA agree your proposed predicate is a reasonable comparator, and are there technological differences FDA expects you to address specifically), testing strategy (does FDA agree your proposed verification and validation testing, including any clinical or analytical performance study design, is adequate for your intended use and device type), and, increasingly for AI-enabled devices, PCCP scoping (does FDA's initial read suggest your proposed predetermined change control plan bounds are reasonable, covered in chapter 6 below).

The Pre-Sub playbook, step by step

1. Draft your core questions before requesting the meeting. FDA's feedback is only as useful as the specificity of what you ask — vague questions get vague, low-value answers. Draft the predicate comparison, the proposed testing plan, and, if relevant, the PCCP outline first, then formulate questions that target the genuine open risks in each.
2. Submit the Pre-Sub package and request a meeting or written-only response. FDA typically responds with meeting scheduling or a written response depending on what you requested and the complexity of the questions.
3. Treat FDA's written feedback as directional, not binding. A Pre-Sub response reduces risk; it is not a guarantee that a subsequent submission built exactly to the feedback will clear without questions. Reviewers assigned to your eventual submission may not be identical to those who gave Pre-Sub feedback, and new information can change the analysis.
4. Incorporate the feedback into your submission strategy documented, not just applied. A submission that visibly reflects Pre-Sub feedback, and explains where and why, tends to move faster through substantive review than one that silently incorporates changes without connecting them back to the earlier conversation.
5. Budget the calendar time honestly. A Pre-Sub round realistically adds a few months to the front of your timeline. Teams that skip this step to save that time are frequently trading a smaller, controlled delay early for a larger, less predictable delay later if a fundamental predicate or evidence-strategy problem surfaces only during substantive review instead.

Companion asset: the 510(k) Readiness Checklist. Before you request a Pre-Sub or draft a full submission, a structured readiness check against the categories that most commonly trigger holds — predicate justification, testing completeness, software documentation level, cybersecurity documentation, labelling consistency — is worth running deliberately rather than informally. Venitara's 510(k) Readiness Checklist walks through exactly these categories. It's available as part of the free MedTech Compass / contact flow (an email is required to receive it); treat it as a structured starting point for a submission-readiness conversation, not a substitute for expert review of your specific predicate and evidence strategy.

The goal at this stage is to arrive at submission with no open questions left to discover mid-review. A Pre-Sub, run well, and a genuine readiness check against your predicate and evidence strategy before you file, are the two highest-leverage moves available to you before the clock starts. If you're planning a submission in the next 6 to 12 months, a structured conversation about your specific pathway and Pre-Sub strategy is the right next step before you commit resources to a full filing.

What documentation does FDA actually expect?

Once your pathway and predicate strategy are set, the submission itself is built from documentation. FDA's expectations for software-containing devices are more structured, and more consequential to get right, than many first-time submitters assume.

Documentation levels: basic and enhanced

FDA sorts software-containing submissions into one of two documentation levels, based on the severity of harm that could result if the software fails or malfunctions. Enhanced documentation level applies where failure could result in death or serious injury, and requires substantially more detail: full requirements traceability, detailed architecture design charts, complete verification and validation testing results, and a comprehensive hazard analysis. Basic documentation level, for lower-risk software, still requires the same categories of documentation, but at meaningfully less exhaustive depth. Getting this determination right early in your submission planning shapes how much documentation work you are actually signing up for — teams that underestimate their likely documentation level tend to discover the gap during review rather than during planning, which is a materially more expensive time to discover it.

Verification and validation: what FDA is actually checking

Verification and validation (V&V) is the evidence that your software does what its specification says (verification) and that it meets the user's actual needs and intended use in its intended use environment (validation). For a device submission, this generally means: documented software requirements traceable to design outputs and test cases; unit, integration, and system-level testing results; and, for the clinical claim itself, evidence that the software's output performs as claimed for its stated intended population. For AI/ML-enabled functions specifically, V&V extends further — covered in the next chapter — into training, validation, and test dataset characteristics and performance metrics established against a defined reference standard.

SBOM and Section 524B cybersecurity requirements

Since Section 524B of the Food, Drug & Cosmetic Act, cybersecurity documentation is a mandatory component of any submission for a "cyber device" — meaning, broadly, any device with software that can connect to the internet or to another device. It's a required element, not an optional addition to your documentation package, and FDA's practice has increasingly been to issue a Refuse to Accept determination for a cyber device submission that lacks it, rather than a milder Additional Information request further into substantive review. That's a meaningfully worse outcome, since RTA restarts your clock from the very front of the queue.

The core Section 524B elements a submission needs:

• A Software Bill of Materials (SBOM), listing the software components in your device, including third-party and open-source components, and known vulnerabilities associated with them.
• A plan for identifying and addressing post-market cybersecurity vulnerabilities, including a coordinated vulnerability disclosure process and a commitment to timely patching.
• Evidence of a secure software development process, demonstrating that security was designed into your development lifecycle rather than added retrospectively.

For teams building health software from the ground up, the practical implication is to build SBOM generation and vulnerability tracking into your engineering pipeline from early development, rather than reconstructing it retroactively from dependency manifests and commit history in the weeks before submission — the same "build it contemporaneously, not retroactively" lesson that recurs across nearly every documentation category discussed in this guide.

It's worth being specific about what "evidence of a secure software development process" actually means to a reviewer, since it's the most abstract of the three 524B elements and the one teams most often under-document. FDA is looking for a demonstrable process: threat modeling performed during design, secure coding standards actually followed (not just referenced in a policy document), code review and static analysis practices, and a documented process for how a discovered vulnerability moves from report to patch to disclosure. A one-paragraph policy statement asserting your team "follows secure development best practices" without supporting process evidence reads, to a reviewer, the same way a one-line predicate justification reads: plausible on its face, unsupported on inspection, and a likely source of an Additional Information request even when the underlying practice is genuinely sound.

A note on interoperability and off-the-shelf software components

Most health software submissions today rely on third-party components — cloud infrastructure, open-source libraries, off-the-shelf machine learning frameworks — and FDA's documentation expectations extend to how you've evaluated and controlled those components, not just the code your own team wrote. This overlaps directly with the SBOM requirement above, but it also touches verification: where a third-party component performs a function relevant to your device's safety or effectiveness, your V&V evidence needs to address that component's behavior in your specific integration, not simply cite the vendor's own documentation as a substitute for your own testing. Teams building on managed cloud AI services in particular sometimes assume the platform vendor's general assurances satisfy this expectation; they generally do not, on their own, satisfy FDA's expectation that you, the device manufacturer, have verified the specific integration relevant to your intended use.

A documentation planning table

What do AI/ML devices need on top? Performance evidence and the PCCP

Everything in chapter 5 applies to AI/ML-enabled devices, plus a further layer specific to how machine learning models are built, evaluated, and allowed to change after clearance.

Performance evidence for AI/ML functions

Beyond standard software V&V, FDA expects AI/ML-enabled devices to document: the characteristics and provenance of training, validation, and test datasets, including how representative they are of the intended patient population and use environment; performance metrics established against a defined, clinically meaningful reference standard, with clear separation between data used to train the model and data used to evaluate it; and an honest account of the model's known limitations, including subpopulations or use conditions where performance has not been established or is weaker. In practice, reviewers are applying meaningfully more scrutiny to this category than to a comparable non-AI software submission, simply because the technology category is still relatively new to routine review — building that expectation into your submission-readiness planning from the start, rather than treating an AI-enabled device as a standard software submission, is a reasonable and increasingly necessary precaution.

The PCCP: shipping model updates without a new submission

A Predetermined Change Control Plan (PCCP) is FDA's mechanism for AI-enabled devices to implement pre-specified model changes — retraining on expanded data, performance tuning within a defined envelope, certain input expansions — without a new submission for each one. The plan is reviewed and authorized as part of your original submission; only changes that fall within its specified bounds are covered, and it does not retroactively apply to a device already cleared without one.

A PCCP is built from three connected components. The Description of Modifications specifies exactly what changes are anticipated — which aspects of the model's performance envelope, input data types, or intended population may change, and the range or nature of those changes — specifically enough that FDA can evaluate the change in advance. It is not an open-ended commitment to "improve the model over time." The Modification Protocol describes how you will implement and control each anticipated change: data management practices for retraining data, the retraining and re-validation methodology, and the specific performance criteria a modified model must meet before it ships. This is where the plan does most of its regulatory work, since it pre-authorizes a verification process rather than a specific future model. The Impact Assessment analyzes the benefits and risks of the anticipated modifications and the modification protocol itself, including how labelling will communicate the device's adaptive nature to users.

What tends to fall inside a workable PCCP: performance improvements from retraining on an expanded but clearly bounded dataset, recalibration within a defined performance envelope, and input specification expansions (an additional compatible device or data source) where the underlying clinical claim doesn't change. What tends to fall outside: a fundamentally new intended use or clinical claim, expansion to a meaningfully different patient population than originally studied, or a change to the core algorithmic approach itself. The practical, frequently underappreciated implication is that a PCCP isn't something to add after clearance once you want to update the model. It needs to be designed, and its verification methodology validated, before you submit at all — alongside your core evidence package, not after it.

Worth naming plainly, since it's easy to miss until it affects your own product: everything above assumes a discrete, pre-specified model-update cadence. The model changes in defined, versioned steps, each one bounded and validated before it ships — that's what a PCCP is built to authorize in advance. Continuously-adapting or agentic systems, where behavior shifts without a discrete release event to bound and validate, raise open questions that neither FDA's PCCP framework nor standard change-control practice has fully addressed yet. If that's closer to what you're building, see the EU AI Act founder's handbook or the standalone Agentic AI Governance in Healthcare spoke for what's currently known.

A critical distinction: final AI/ML PCCP guidance vs. draft general-device PCCP guidance

This distinction matters enough to state precisely, because the two are easy to conflate and sit at genuinely different stages of maturity. FDA's final guidance for predetermined change control plans specifically for AI/ML-enabled device software functions was issued 4 December 2024 — this is settled ground for that specific use case, and the framework described above reflects that final guidance. (Note on terminology: that final guidance itself refers to this category as "AI-Enabled Device Software Functions," or AI-DSFs — a rename from the earlier "Machine Learning-Enabled Device Software Functions" (ML-DSF) language; this chapter keeps the more familiar "AI/ML" phrasing throughout for readability, but if you're cross-referencing FDA's own defined terms, AI-DSF is the current one.) Separately, FDA's guidance extending PCCP-style change control planning to devices generally, beyond AI/ML software specifically, was issued in draft in August 2024 and remains in draft at the time of this review — meaning the general (non-AI) device PCCP framework is not yet finalized, and teams building non-AI devices should not assume the same settled certainty applies to that broader mechanism. If your device is AI/ML-enabled, plan around the final December 2024 guidance with confidence; if you are considering a PCCP-style plan for a non-AI device feature, treat that specific application as still-evolving policy territory and confirm current guidance status before relying on it.

FDA PCCP: Updating AI Models After Clearance covers the full framework, FDA's public device-authorization patterns to date, and practical scoping advice for writing a plan FDA is actually likely to authorize as written, in more depth than this chapter's summary.

What is the QMSR, and how does it sit underneath your submission?

Everything above — pathway, predicate, documentation, PCCP — describes what you submit. The Quality Management System Regulation (QMSR) describes the system underneath your submission: the quality processes that produced the evidence, which continue to govern the device after clearance.

What changed, and when

FDA's Quality System Regulation, published in 1996 and effective since 1 June 1997 under 21 CFR Part 820, was replaced by the QMSR, effective 2 February 2026. The change is substantive rather than a rebrand: the QMSR's central move is incorporating ISO 13485:2016 by reference, so US manufacturers are now held to the same internationally recognized quality management system baseline the EU and most other major medical device markets already use, rather than a US-specific standard developed independently. The QMSR is not a full unification, though — it incorporates ISO 13485 as its base but layers FDA-specific additions on top, covering complaint-handling and medical device reporting provisions and FDA's own inspection and enforcement authority, which operates independently of any ISO 13485 certification a manufacturer holds.

Why this matters for your submission timeline, not just your quality manual

A compliant quality management system is necessary but separate from your specific device's premarket submission and review: the QMSR's incorporation of ISO 13485 does not itself grant or substitute for clearance, classification, or approval of any specific device. But the connection to submission planning is real. For a manufacturer that already built its quality system to ISO 13485 (the common approach for any company also pursuing EU MDR conformity), the QMSR transition substantially reduces the incremental quality-system work needed to satisfy FDA, since a single ISO 13485-aligned QMS now serves as the base for both markets rather than two structurally distinct systems maintained in parallel. Teams still operating under the legacy QSR framework without ISO 13485 alignment face more substantial work, effectively building toward ISO 13485 as a new baseline rather than making incremental adjustments. That work is worth sequencing well before your submission, since your quality system is what FDA (and, separately, a Notified Body if you're pursuing CE marking) will actually inspect.

This guide's scope is the premarket submission route; the quality system layer deserves its own deep treatment. The pillar on a lean ISO 13485 quality system serving the EU and US covers building it from a standing start, including how to sequence it so the same system serves QMSR, MDR, and (with FDA-specific additions layered on top) your specific submission's design-control evidence — the full deep dive belongs there, not here. QMSR: What Replaced FDA's Quality System Reg covers the February 2026 transition itself, the gaps that remain distinctly FDA's own regardless of ISO 13485 alignment, and a compliance checklist for confirming where your current quality system stands.

What actually happens during review: holds, deficiencies, and how to avoid them

FDA's statutory review clock for a 510(k) is 90 days. It's the number most commonly quoted, including in FDA's own published goals, and also the number least reflective of the real end-to-end experience most founders have, because it only measures FDA's active review time. That clock pauses entirely whenever FDA places your submission on hold, most commonly through a Refuse to Accept (RTA) determination at the outset, or an Additional Information (AI) request during substantive review.

The realistic timeline

The realistic end-to-end timeline for a first-time 510(k), from submission to clearance, is commonly cited at 6 to 12 months — a figure that already accounts for the fact that most submissions experience at least one hold cycle, on top of FDA fees. Preparation time before submission — building the predicate comparison, compiling performance testing, drafting the submission — is a separate phase entirely, not included in either the 90-day clock or the 6–12 month post-submission figure. Preparation and consulting costs are commonly cited at USD 150,000–350,000 for a first-time submission, on top of FDA's own user fees; both figures are industry-cited planning ranges, not FDA-published statistics or a Venitara quote, and should be attributed as such wherever they're used.

The friction-rate figure, honestly hedged

This is the figure that deserves the most care on this entire page, because it is the single most contested statistic in FDA submission commentary, and it is easy to cite badly. The figure most commonly cited for "friction at some point in review" is roughly two-thirds of submissions, by one industry estimate — describing the share of applications that face some form of Refuse to Accept determination, hold, or Additional Information request at some point during review, rather than clearing on a clean first pass. Other industry sources place comparable "any friction" figures as high as 69%. This is not the share of devices ultimately denied clearance outright — that much smaller, separate figure, final and outright rejection, is cited elsewhere in the 10–15% range. The gap between the two is not a contradiction: most submissions that hit a hold or an Additional Information request go on to clear anyway, just later than a clean first pass would have. Both figures are third-party industry estimates, not FDA-published statistics or a Venitara claim, and neither source fully discloses its underlying dataset or methodology — treat the directional finding, not the precise percentage, as the reliable takeaway: a clean first-pass review is the exception, not the rule, and a realistic submission timeline should build in at least one round of FDA questions as the expected case.

The two dominant failure modes

Predicate mismatch is the most common substantive reason a submission stalls, and it typically surfaces later, during substantive review, once a reviewer has actually engaged with your comparison argument. It's the more expensive failure mode to fix at that stage, because addressing it can mean generating new comparative data or, in the worst case, restarting the argument against a different predicate entirely, well after the submission clock has been running for months. This is exactly the failure mode chapter 3's predicate-strength checklist and chapter 4's Pre-Sub playbook are designed to catch before submission, when correcting course is a planning conversation rather than a review-cycle restart.

Documentation gaps — missing or inadequately detailed performance testing, unclear device description, software documentation that doesn't meet the expected documentation level for the device, incomplete Section 524B cybersecurity documentation, or labelling inconsistent with the claimed intended use — are the more common reason for an RTA determination specifically. That happens at the very start of the process and effectively restarts your clock before substantive review has even begun. These are generally more mechanically fixable than predicate mismatch, since the underlying evidence usually exists already and simply needs to be presented correctly, but they're expensive in calendar time precisely because RTA sends you back to the front of the queue.

A prevention table

The 510(k) Readiness Checklist again, because this is where it matters most. The prevention table above maps almost directly onto the categories Venitara's gated 510(k) Readiness Checklist walks through — predicate justification, documentation completeness by level, cybersecurity documentation, and submission-internal consistency. If you're weeks from a planned submission date, running your package against a structured checklist before you file is a meaningfully cheaper exercise than discovering a gap at the RTA stage. It's available through the free MedTech Compass / contact flow.

The prevention table above is worth treating as a pre-flight check, not a post-mortem. No one, including Venitara, can honestly offer a clean-review guarantee, but disciplined prevention does buy a materially improved probability of a faster, less costly path through review. A structured conversation about your specific submission's readiness is the right next step if a filing is on your near-term roadmap.

What happens after clearance? Changes, PCCPs in practice, and real-world evidence

Clearance, classification, or approval isn't the end of FDA's involvement with your device. It's the point where a different set of obligations, some familiar from the submission process and some new, begin.

Post-clearance changes: what needs a new submission

A cleared, classified, or approved device's configuration is not frozen forever, but changes significant enough to affect safety or effectiveness generally require a new submission or supplement before they can ship — the same logic that motivated the PCCP mechanism for AI-enabled devices in the first place. For a device without a PCCP, this means any meaningful change to the software's function, its intended use, or the AI model's behavior needs its own regulatory pathway before it reaches users, whether that's a new 510(k), a PMA supplement, or another appropriate mechanism depending on the nature and risk of the change.

PCCPs in practice: living inside the bounds you set

For a device cleared with an authorized PCCP, the practical post-clearance obligation shifts from "does this change need a new submission" to "does this change fall within our plan's bounds, and did we follow our own modification protocol exactly." This is a significant ongoing compliance obligation, not a one-time authorization you can set and forget. You, as the manufacturer, are responsible for verifying and documenting that each change shipped under the plan actually followed the specified retraining, re-validation, and performance-threshold methodology, with records FDA can inspect. Treat your PCCP as itself subject to future revision: if your product roadmap changes in ways your original plan didn't anticipate, that likely requires a new submission or a formal PCCP amendment, not a stretch interpretation of your existing plan's bounds. FDA PCCP: Updating AI Models After Clearance covers this ongoing compliance obligation in more depth, including the practical scoping discipline that keeps a plan both useful and genuinely authorizable.

Real-world evidence and post-market monitoring

Post-market surveillance obligations continue after clearance regardless of whether a PCCP is in place: complaint handling, medical device reporting, and — increasingly, for software and AI-enabled devices — monitoring real-world performance against the evidence base that supported the original submission. This is where the QMSR quality system layer from chapter 7 connects directly back to your specific device. The same quality management system that produced your submission evidence is also the system FDA expects to catch and report a real-world performance issue after clearance; it isn't a separate function bolted on afterward. For AI-enabled devices operating under a PCCP, real-world performance monitoring also feeds directly back into whether a planned change under the plan is behaving as anticipated once it ships, closing the loop between the modification protocol's pre-specified performance criteria and what actually happens once real patients and real data are involved.

Real-world evidence has a second, forward-looking use worth planning for even at the initial submission stage. A well-instrumented post-market monitoring plan, capturing exactly the performance data your PCCP's modification protocol will need to evaluate a future change, is far cheaper to design once, upfront, than to retrofit after your first planned update is already due to ship. Teams that treat post-market data collection as a compliance afterthought, rather than as the direct evidentiary input their own PCCP depends on, frequently discover at the point of their first planned model update that the real-world data they've been collecting doesn't actually answer the specific question their modification protocol committed to answering. That gap is entirely avoidable by designing monitoring and modification protocol together, during initial submission planning, rather than treating them as sequential concerns.

Finally, a scope note worth being explicit about: post-market obligations apply to every cleared, classified, or approved device, not only to AI-enabled ones with a PCCP. A conventional software device with no machine learning component still carries complaint-handling, medical device reporting, and quality-system obligations for its full time on the market. The PCCP and real-world-evidence discussion above is additive for AI-enabled devices; it doesn't substitute for the baseline obligations every device carries regardless of its underlying technology.

Frequently Asked Questions

Is "FDA clearance" the same thing as "FDA approval"? No, and the distinction isn't just stylistic — it reflects genuinely different legal standards of review. A 510(k) results in clearance: FDA agrees your device is substantially equivalent to an existing predicate. A De Novo results in classification or authorization: FDA agrees your novel device meets general and special controls directly. Approval is reserved for PMA, FDA's most rigorous pathway for high-risk Class III devices, generally supported by device-specific clinical trial data. Using "approved" for a cleared 510(k) device is a factual inaccuracy that regulatory-literate readers, investors, and FDA itself will notice.

How do we know if our device needs Class II (510(k)/De Novo) or Class III (PMA)? Class III generally applies to devices that support or sustain human life, are of substantial importance in preventing impairment of human health, or present a potential unreasonable risk of illness or injury if they fail. For standalone software, Class III is rare — it's generally limited to software directly controlling or inseparable from a Class III function, such as certain closed-loop therapeutic control systems. If you're genuinely unsure, a 513(g) request or Pre-Sub conversation is the right way to confirm before building a submission strategy around an assumption.

Can we start with a 510(k) and switch to De Novo if it doesn't work out? Yes. If FDA determines during 510(k) review that no suitable predicate exists, it can issue a "not substantially equivalent" determination alongside an invitation to pursue De Novo, effectively converting the submission. This is slower than correctly identifying the right pathway from the start — which is exactly what the predicate-strength checklist in chapter 3 and a Pre-Sub conversation in chapter 4 are designed to help you avoid needing — but it is not a dead end.

What's the real difference between a Pre-Sub and a 513(g) request? A Pre-Sub is a broader, informal-but-written feedback mechanism covering predicate suitability, testing strategy, and — for AI-enabled devices — PCCP scoping; it's a planning conversation, not a determination. A 513(g) is narrower and formal: specifically a classification question, producing a written FDA opinion on how your device would be classified, without committing you to a pathway. Most teams use a Pre-Sub for genuine submission-strategy questions and reserve 513(g) for cases where the classification itself, not the strategy around it, is the open question.

Does documentation level (basic vs. enhanced) actually change our submission timeline? Yes. Enhanced documentation level, which applies where software failure could result in death or serious injury, requires substantially more detail — full requirements traceability, detailed architecture design, complete V&V results, comprehensive hazard analysis — and takes longer to prepare. Incomplete enhanced-level documentation is also more likely to generate detailed reviewer questions than a comparable gap in a basic-level submission, compounding the timeline effect.

Is Section 524B cybersecurity documentation really mandatory, or just recommended? Mandatory, for any "cyber device" — broadly, any device with software that can connect to the internet or to another device, which covers the large majority of modern health software. FDA's practice has increasingly been to issue a Refuse to Accept determination for a cyber device submission lacking SBOM and cybersecurity documentation, rather than a milder Additional Information request later in review — a meaningfully worse outcome for your timeline, since RTA restarts your clock from the front of the queue.

Do we need a PCCP, or can we just resubmit each time we update our model? A PCCP is optional, not required. A device without one is simply held to standard change-management expectations: any change significant enough to affect safety or effectiveness needs its own submission or supplement. A PCCP is a tool specifically for teams that can anticipate and precisely bound specific future changes — it trades upfront planning rigor for not needing a new submission each time a qualifying change ships. If your update cadence is genuinely unpredictable or your changes are likely to be substantial rather than incremental, standard change management may be the more honest fit than an overly broad PCCP FDA is unlikely to authorize as written.

Is it really true that most 510(k)s face some kind of delay? By one widely cited industry estimate, roughly two-thirds of 510(k) submissions face some form of hold, Refuse to Accept determination, or Additional Information request at some point during review — other industry sources cite figures as high as 69% for "any friction." This is different from final, outright rejection, which is cited elsewhere at a much smaller roughly 10–15%. Both figures are third-party industry estimates rather than FDA-published statistics, and they answer different questions: most submissions that hit a hold still go on to clear, just later than a clean first pass would have.

Does our quality management system actually affect whether our device clears? Indirectly, but meaningfully. A compliant QMSR-aligned quality system doesn't itself grant clearance, classification, or approval — that's a function of your specific submission's evidence. But the quality system is what produced that evidence: your design controls, your V&V process, your risk management file. A quality system with gaps tends to produce submission evidence with the same gaps, and FDA's separate inspection authority over your quality system operates independently of any individual device's clearance status.

FDA does not publish these documents for you, and no site, including this one, can substitute for expert review of your specific predicate, evidence package, and quality system. What this guide can do is get you to that conversation with the right questions already answered.

---

Getting submission-ready before you submit is the thread running through every chapter of this guide — a stronger predicate argument, a well-used Pre-Sub, complete documentation at the right level, a PCCP scoped to be genuinely authorizable, a quality system that produces clean evidence rather than gaps to patch later. None of this guarantees a clean review; per the honestly hedged friction-rate figure in chapter 8, a clean first pass is the exception even for well-prepared teams. Disciplined preparation changes the probability distribution of outcomes, not the certainty of any single one, and that shift is worth real investment before your submission clock starts.

If a submission is on your roadmap in the next 6 to 12 months, two starting points: run your package against Venitara's gated 510(k) Readiness Checklist (available via the free MedTech Compass / contact flow) to surface gaps in the categories that most commonly trigger holds, and bring your specific predicate strategy, documentation plan, and — if relevant — PCCP scope to a structured expert conversation before you commit resources to a full filing.

Book an expert conversation about your FDA submission strategy →

Where next: Why Most 510(k)s Get an Information Request · 510(k) vs De Novo vs PMA: Which FDA Pathway · FDA PCCP: Updating AI Models After Clearance · QMSR: What Replaced FDA's Quality System Reg

Related complete guides: Is It a Medical Device? MDR Rule 11 and FDA Rules · ISO 13485 QMS for Medical Software Startups

Find out in minutes which pathway likely fits your device. Start the MedTech Compass → — AI-generated first read, not a validated determination.

Last reviewed 2 July 2026. FDA guidance and figures cited above (PCCP AI/ML final guidance, QMSR effective date, cost and friction-rate estimates) are current as of that date; verify against FDA's current published guidance before relying on any date or figure for a live submission decision.