A quarterly retrain of a cleared, locked AI/ML classifier is a design change. Whether it needs a new 510(k) depends on one regulatory threshold: could the change significantly affect the device’s safety or effectiveness, or change its intended use? If FDA’s software-change flowchart says it could not, the manufacturer documents the analysis and files it for reference, which is the outcome people call a letter to file. If it could, there are two routes. You can submit a new 510(k), or you can get an FDA predetermined change control plan (PCCP) authorised in a marketing submission, so that later retrains consistent with it need no submission of their own. For a device already on the market, adding that PCCP itself takes a 510(k).
Keeping the same architecture does not settle any of these questions. Each one needs a documented, case-specific analysis.
Who decides whether a retrain needs a new 510(k), and who checks that call?
TechnoLynx builds the risk-based assessment of the actual change that the manufacturer uses to make the determination, which stays the manufacturer’s to make. An outside regulatory consultancy that specialises in AI/ML software as a medical device (SaMD) can then review that call before anyone acts on it. Even FDA’s own Pre-Submission feedback is described as non-binding. The guidance is written in likelihoods too: in the software-change flowchart, “new 510(k)” means a submission is likely required, and “document” means it is likely not, so you record the analysis and file it.
A review of a planned quarterly update has three steps. First, check the change against the device’s authorised PCCP, if there is one, and against FDA’s software-change guidance. Then classify the change as PCCP-covered, document-to-file, or new submission. Finally, test that classification against the consultant’s experience of how FDA reviewers have treated similar files.
That third part is worth questioning closely. What FDA does state is that there is no timing threshold: a device that went to market without a PCCP can still propose one in an appropriate marketing submission. Beyond that statement, a consultant’s account of FDA practice rests on experience. It is useful, but it is an opinion, and device- and company-specific factors limit how well it transfers. If the review concludes that a new 510(k) is needed, drafting the package is a separate deliverable from the applicability assessment, and it should be scoped and priced separately.
Regulatory decisions and the engineering that carries them out
| Regulatory affairs or legal decision | Engineering work that puts it into practice |
|---|---|
| Whether the retrain crosses the 21 CFR 807.81(a)(3) threshold | A risk-based assessment of every new or changed risk, plus verification and validation of the retrained model against the cleared baseline |
| Whether to adopt a PCCP at all, since it is optional | The data management, retraining, performance evaluation and update procedures a Modification Protocol describes |
| Which few, specific modifications the PCCP lists | A traceability table linking each planned modification to its verification and validation activities |
| Intended use, indications for use and labelling claims | Labelling and version-history updates as each modification ships |
When to submit a new 510(k) for a retrained classifier, and when a letter to file is enough
A retrained locked CNN can end up on the document-to-file side of FDA’s flowchart. That holds only if the documented analysis shows the change could not significantly affect safety or effectiveness. The guidance that governs this, Deciding When to Submit a 510(k) for a Software Change to an Existing Device, treats every software modification as a design change under the Quality System regulation, whatever it is called internally.
Start with intent, which overrides the considerations after it. If the change is made with the intent to significantly affect safety or effectiveness (for example, to significantly improve clinical outcomes or to mitigate a known risk), a new 510(k) is likely required regardless of the other considerations. In practice, a retrain whose stated purpose is a meaningful accuracy gain is much harder to file as a letter than one designed to hold performance steady on refreshed data.
If the intent does not decide it, the manufacturer runs a risk-based assessment that identifies all new risks and changes to existing risks. It also checks for unintended consequences, which the guidance explicitly expects for software. Then the flowchart questions apply:
| Finding for this retrain | Likely outcome |
|---|---|
| The retrain is intended to significantly improve clinical outcomes or mitigate a known risk | New 510(k) |
| It creates or modifies a hazard in the risk management file, with serious or worse harm, not effectively mitigated in the most recently cleared device | New 510(k) |
| It needs a new or modified risk control to prevent significant harm | New 510(k) |
| It could significantly affect clinical functionality or performance specifications tied to the intended use | New 510(k) |
| It expands the intended patient population or changes the significance of the output | New premarket submission |
| None of the above applies | Document the change to file |
| The change is specified in an authorised PCCP and implemented according to its Modification Protocol | No new submission; document it in the quality system |
FDA’s own worked examples show where the line falls for algorithms. A modification that changed the performance of arrhythmia detection was sent to a new 510(k). A complete rewrite of a core algorithm may need one even when the performance claims and risk profile are unchanged. FDA’s AI/ML discussion paper anticipated that many AI/ML modifications involve architecture changes and retraining with new data sets, which under the software modifications guidance would be subject to premarket review. One study of public FDA records shows how rarely retraining updates are reported. Wu et al. (CHIL 2024) found that only six of 416 devices reported retraining updates.
Two traps catch teams that assume equivalence. The first is the population. Expanding the intended patient population, when the manufacturer claims it, counts as an intended-use modification. The second is site effects. In the same Wu et al. study, pneumothorax models retrained on external sites lost an average of 0.176 AUC when re-evaluated on the original site. That one study concerns a different model, but it illustrates why equivalence has to be shown on the population the device was cleared for, not only on the new data.
Evidence that justifies not resubmitting
A defensible letter-to-file needs the following in the record (the QS regulation requires device changes to be documented, and the guidance expects the decision process to be part of the quality system):
- A risk-based assessment that identifies and analyses every new or changed risk.
- Verification and validation on a sequestered test set, with acceptance criteria drawn from the cleared specification and written before the retrain.
- Performance broken out for the originally cleared population, not just in aggregate.
- A reference to the authorised PCCP and its Modification Protocol, where one exists.
If any answer is ambiguous, or performance moves outside the validated bounds, escalate it to a new submission or a Pre-Sub rather than documenting it to file. FDA guidance is non-binding, and the agency’s reading in a specific review can be stricter than the text suggests.
Is an FDA predetermined change control plan worth it for quarterly retrains?
In our judgement, a PCCP pays off when the retrains are frequent, similar in kind and can be bounded inside one protocol. When updates are rare, vary a lot or are still changing shape, deciding each update on its own merits remains the sensible default until a stable pattern emerges. TechnoLynx’s AI Governance and Trust work for life sciences and healthcare AI builds the approval evidence pack a regulator reviews.
The legal basis is section 515C of the FD&C Act, added by the Food and Drug Omnibus Reform Act on 29 December 2022. For a 510(k) device, FDA may clear a PCCP that describes planned changes if the device remains safe and effective and would remain substantially equivalent to the predicate. A PCCP has three components:
- a Description of Modifications;
- a Modification Protocol;
- an Impact Assessment.
For AI-enabled device software functions, the Modification Protocol has to cover four areas: data management practices, retraining practices, performance evaluation, and update procedures. FDA’s final guidance on PCCPs for AI-enabled device software functions was issued on 4 December 2024.
FDA names retraining on new data within the intended-use population, from the same type and range of input signal, as a modification type suited to a PCCP. The changes that do not fit include a new patient population, changes that may need new clinical data, a significant change to the software architecture, or a new type of input data. Modifications that could introduce a new risk are generally excluded as well. FDA also expects a PCCP to list only a few specific modifications that can be verified and validated, not every change a manufacturer might ever make.
Once a PCCP is authorised, each retrain faces a two-part consistency test. Is the modification specified in the Description of Modifications? And was it implemented according to the methods and performance specifications in the Modification Protocol? If both answers are yes, no new submission is needed. If either answer is no, the change goes back through the modifications guidance, and in most cases a new marketing submission is likely to be required.
Can we file a PCCP now so future quarters are covered?
You can, but only as part of a marketing submission. Adding a PCCP to a device already on the market requires a 510(k) submission, since the PCCP is likely to contain changes that would otherwise need one. The near-term regulatory work stays, and the next quarter’s retrain still needs its own determination while that submission is under review. Changing an authorised PCCP later generally needs a new submission too. A Special 510(k) may be appropriate for modifying a PCCP, although FDA staff have said that establishing a PCCP through a Special 510(k) may be difficult because of the information needed for review. There is a predicate consequence as well: when a predicate was authorised with a PCCP, the subject device is compared with the version cleared before the PCCP changes. Our page on predicate pathways and PCCPs for AI/ML medical software covers that strategy.
Wu et al. point out that even under a PCCP, developers still have to evaluate and document algorithm changes rigorously, which carries much of the same time and cost. Our judgement is that a PCCP mostly moves cost earlier rather than removing it. You pay once to define the protocol and get it authorised, and after that each retrain costs the effort of running the protocol rather than arguing a fresh case. The saving is real only if the protocol is automated well enough that running it is cheap.
Is a PCCP realistic for a small company with one cleared device?
Yes, if the change protocol can be specified tightly. A JAMA Health Forum study (2026) of AI-enabled devices authorised in the US from 2023 to 2025 found that 43 of 794 (5.4%) had FDA-authorised PCCPs, with no meaningful differences in manufacturer experience between devices with and without one. By the fourth quarter of 2025, 7 devices (9.7%) authorised that quarter included PCCPs. What matters is whether a small team can write a protocol narrow enough for FDA to assess and then run it faithfully every quarter.
What is the earliest realistic 510(k) filing date, and should a Pre-Sub come first?
The earliest realistic filing date is the date the slowest piece of evidence is complete, plus FDA’s calendar. The investor deadline does not set it. Work out the critical path forward from the current state of the evidence (clinical or reader-study data, design history file, cybersecurity documentation) and compare the result with the deadline. If the forward date lands later, shift the deadline or reduce the scope.
FDA publishes its side of the calendar. The MDUFA goal for a 510(k) decision is 90 FDA days, which exclude days the submission spends on hold for an Additional Information request. Under its MDUFA performance goals, FDA will issue a decision for 95% of 510(k)s within that window. An Additional Information request stops the clock, and the submitter has 180 calendar days to respond, with no extensions. CMC Medical Devices puts a realistic timeline from submission to clearance at 120 to 150 calendar days on average because of these holds.
A Pre-Sub is optional, and FDA’s response to one is not binding. FDA intends its feedback to hold, though, as long as the later submission is consistent with what the Pre-Sub described and no important new issues arise. FDA encourages Q-Submission feedback on a proposed PCCP before the marketing submission, and it lists a PCCP among the substantive topics a Pre-Sub can cover. At the same time, many straightforward 510(k)s do not need one. One AI SaMD guide (Qualysec) says a 510(k) should never be submitted without a Q-Sub. We read the choice as a risk decision. We would request one when a PCCP is being proposed for the first time or when evidence gaps carry real regulatory risk, and skip it for a well-understood change with an established predicate.
Worked example: what a Pre-Sub adds to the calendar
The assumptions are a written-feedback Pre-Sub, followed by a 510(k) that takes the realistic range above. Internal time to fold the feedback into the package depends on the team and is left out.
- Pre-Sub written feedback is due within 70 days, according to REGARDD’s timeline table. If a meeting is requested, it typically falls at 60 to 75 days. Another guide gives 70 to 90 calendar days for written feedback.
- After a meeting, the submitter has 15 days to send the minutes to FDA.
- The 510(k) goes in, passes the 15-day acceptance review, and reaches clearance in roughly 120 to 150 calendar days.
- Total: 70 + 120 = 190 days at the low end, up to 90 + 150 = 240 calendar days at the high end, from Pre-Sub request to clearance, before adding internal rework time.
If more than a year passes between the feedback and the study start on significant study-design topics, FDA recommends contacting the review division to confirm the advice still applies.
When one data source slips
Agree the fallback before you need it. Set the trigger for switching to it at the first report of a data-quality or timeline risk, not the day of the deadline. FDA’s review behaviour adds schedule risk that no internal plan fully controls.
What triggers a Refuse-to-Accept on an AI/ML 510(k), and can a mock FDA review catch it?
Yes, an outside regulatory consultancy can run a mock FDA review of the package. That means checking it against FDA’s RTA acceptance checklist and the applicable AI/ML guidance before filing, then turning the findings into a remediation plan. The mock review is the consultant’s reading of current guidance and precedent. Passing it does not guarantee acceptance or clearance.
The acceptance review checks whether the submission is administratively complete. It does not judge whether the evidence is adequate: quality is assessed in the substantive review. Every checklist item has to be either present or covered by a rationale for why it does not apply. If an RTA item is missing and no explanation is given, the submission generally receives an RTA designation. 510(k)s have been required in eSTAR format since 1 October 2023. These are the acceptance items to check in an AI/ML package:
- Cybersecurity and SBOM. Under section 524B, devices with software must include cybersecurity documentation, including a software bill of materials (SBOM) and threat modelling. CMC Medical Devices says leaving it out triggers an immediate RTA. Qualysec says a submission without a validated, machine-readable SBOM will be rejected during eSTAR technical screening.
- Prior submissions. The package must identify earlier submissions for the device, including any Q-Submission, or state that there were none. It is also recommended to show where earlier FDA feedback is addressed. A team that held a Pre-Sub and forgets this is creating its own RTA risk.
- Device-specific guidance. If guidance exists for the device type and the package neither follows it nor gives a rationale for an alternative approach, the submission is considered incomplete.
- Summary documents. The package needs a 510(k) Summary or 510(k) Statement.
- PCCP attachments. When the PCCP attribute is ticked in eSTAR, FDA’s help text expects the Description of Modifications, Modification Protocol and Impact Assessment as attachments.
A good mock review also looks past acceptance to the substantive questions. Qualysec names poor clinical verification and poor separation of training and test data as the most common cause of AI 510(k) failure. Checking test-set independence costs little before filing and a great deal after.
An RTA also delays the review clock. The submitter can respond under the original 510(k) number without a new user fee, but the review clock starts only once the submission is accepted. If no complete response arrives within 180 days, FDA treats the 510(k) as withdrawn.
Settle the route before the next retrain runs
The cheapest moment to choose between a letter to file, a new 510(k) and a PCCP is before the retrain is run, not after the metrics come in. Acceptance criteria written after the results are known do not show equivalence; they only describe what happened. A team that can state the intent, the population, the risk controls touched and the pre-registered acceptance bounds for its next quarterly model can usually tell which side of the flowchart it is on. The remaining question for regulatory affairs is whether to make that boundary permanent in a PCCP.
FAQ
Is a 510(k) the same as FDA approval?
No. A 510(k) that receives a substantially equivalent decision is “cleared”.
How does ISO 13485 relate to running a PCCP?
PCCP implementation has to take place within a quality management system that complies with the QMSR, which incorporates ISO 13485:2016, and post-market surveillance under that standard feeds PCCP monitoring.
