The Email That Ends Weeks of Work in 60 Seconds
You hit submit on a Tuesday. Eighteen months of runway, a predicate you're confident about, a test program that nearly broke the team, and a submission package everyone proofread twice. You exhale. Maybe you even take Friday off.
Then, around day fourteen, an email lands from a.fda.gov address. Your K number in the subject line. And a word nobody rehearses for: Refuse.
Let me tell you what actually just happened, because the accelerator definitely didn't. For 510(k)s, FDA doesn't even technically call this a "refusal to file", that's PMA language. The 510(k) version is Refuse to Accept, and it comes out of a mandatory acceptance review that happens within the first fifteen calendar days of your submission landing. Here's the part that stings: the person making that call hasn't evaluated your science. Can't. Hasn't read it. They're running a checklist and asking one cold, bureaucratic question, can a reviewer safely start the clock on this package?
That's the mindset. Not "is this device good?" Not "is the data impressive?" Just: is this complete and clear enough to triage? Most founders treat the RTA letter like a verdict on their technology. It's not. It's a verdict on your paperwork discipline. Which is brutal news and great news at the same time, because paperwork is fixable.
Here are the five ways the teams who don't get bounced do it, and how to respond if you already did.
This article is for educational purposes only. It is not financial advice, it is not legal advice, and it is not tax advice; figures vary by device, pathway, and company stage, so consult a qualified professional before acting on anything here.
Way #1, Build a "Refusal-Resistant" Submission: Make the Package Triage-Proof
Here's the insider secret that saves you twelve weeks: FDA literally publishes the acceptance review checklist. The RTA guidance lays out exactly what the screener will look for, section by section. The test is open-book. People still fail it constantly, because knowing the checklist exists and auditing your own package against it are two very different things.
Since October 2023, every 510(k) goes through eSTAR, the electronic submission template. Insiders have mixed feelings about it, but here's the practical reality: eSTAR forces structure on you. Required fields, defined attachments, a fixed architecture. If you complete it properly and honestly, you've neutralized maybe half the RTA checklist before a human ever looks at your file. What eSTAR cannot fix is internal contradiction, and that's where startups die.
I once watched a company get bounced because the software version in the labeling said 2.1, the verification report said 2.1.3, and nowhere did anyone explain the relationship between them. Nobody lied. Nobody hid anything. The screener simply couldn't reconcile the identifiers in the time triage allows, and unchecked a box. Twelve weeks, gone.
So here's the discipline. Every component, every test article, every software and firmware version, every acceptance criterion gets one name, used everywhere. Device description, risk file, test reports, labeling, executive summary, identical identifiers, or an explicit stated mapping. Then build crosswalks: a simple table linking each performance claim to the test method that supports it, the result, and the exact spot in labeling where the claim appears. Reviewers love crosswalks. Screeners love them more, because crosswalks make a package fast to triage, and fast-to-triage packages don't get refused.
And kill the "we'll explain later" instinct. That's the single most expensive sentence in startup regulatory work. FDA's posture is the opposite: explain once, clearly, with evidence, in the place the reviewer expects to find it. They are not going to email you to ask. They are going to refuse, and ask you to pay for the privilege of resubmitting.
Way #2, Nail the Predicate Strategy: Don't Force Equivalence Where It Doesn't Exist
Most RTAs I see trace back to predicate problems, and almost all of them were visible weeks before submission if anyone had been willing to look. The behind-the-scenes truth: senior reviewers mentally model substantial equivalence as a shortest defensible path. They want the straightest line between your device and something already legally marketed. When a submission takes a scenic route, a glamorous predicate with a different energy source, a bigger-name device with narrower indications, the screener's red flags go up before the substantive reviewer ever gets a chance.
The logic itself is simple. Your device needs the same intended use as the predicate, and either the same technological characteristics, or different ones that raise no new questions of safety and effectiveness and are backed by performance data. Startups fail this in two ways: they pick a predicate whose intended use almost-but-not-quite matches, hoping nobody notices the gap, or they gloss technological differences in a single summary paragraph instead of arguing them.
Fix one: match intended use and indications first, before you fall in love with any candidate. If the intended use doesn't line up, move on, no amount of clever writing bridges it. Fix two: build a difference-by-difference comparison that reads like a prosecution brief. Every difference named, every difference analyzed for whether it raises new questions, every analysis tied to evidence. Not a vibes paragraph. A table with teeth.
Two more hard truths. First, split predicates are dead, you can't borrow intended use from one device and technology from another, and submissions that quietly try get flagged fast. Second, when your predicate doesn't cover a claim you want, you have exactly two honest options: narrow the claim, or generate the data. Stretching the predicate is the third option, and it's the one that gets you the letter.
Way #3, Label Like a Reviewer Will: Consistency Between Indications, Claims, and Instructions
Treat your Indications for Use statement as a contract, because that's how FDA reads it. Every word in it gets tested against everything else you submitted, the device description, the performance claims, the warnings, the IFU, the test summaries. Contradiction anywhere in that web is a refusal trigger, and it's one of the most common ones I see. The executive summary says one thing, the labeling says something slightly broader, the risk file assumes something narrower. The screener doesn't adjudicate which version is true. They just refuse.
So run what I call the red-pen pass: print the indications, the device description, the method of operation, the contraindications and warnings, the performance limits, and the IFU. Read them side by side, hunting for drift. Does every performance claim in the labeling have a test summary with a defined acceptance criterion somewhere in the body? Does any warning contradict a use described elsewhere? Does the intended user match the usability work you actually did?
Software startups, listen up, because this is where you're soft right now. The software version in your labeling must reconcile with the version in your verification reports, and your documentation needs to match FDA's current Basic versus Enhanced documentation levels, the old "level of concern" era is over. If your device is a "cyber device," Section 524B of the FD&C Act means FDA expects a cybersecurity plan and a software bill of materials, and yes, missing cyber documentation can absolutely get you refused at acceptance. I've watched connected-device teams treat the SBOM as a post-clearance problem. It is a pre-filing problem.
Every claim, a test. Every test, a traceable acceptance criterion. Every criterion, consistent with the labeling. That chain is what "reviewable" means.
Way #4, De-Risk Your Evidence: Test Methods, Benchmarks, and Risk Are Not Separate Projects
Silos kill submissions. On weak teams, the risk file lives with the quality person, the test plans live with engineering, and the labeling lives with whoever writes well, and the three never truly meet. FDA reads your package as one integrated story, whether you wrote it that way or not: risk management feeds requirements, requirements drive test plans, test plans justify your performance and safety claims. When the screener sees risk controls that no test ever verified, or test endpoints with no rationale, the story breaks.
Build the evidence as three linked modules. Performance and verification testing with pre-defined acceptance criteria. Biocompatibility, sterilization, or material safety work where your device touches the patient. And the usability, software, and risk-control verification that proves the device is safe in real hands. Each module needs a stated rationale, why these tests, why these endpoints, especially anywhere your device differs technologically from the predicate.
Here's a pro move that costs less than you think: bench-test your device side by side against the actual predicate. Buy the comparator unit. Run the same protocol. When differences exist, nothing defuses them like direct comparative data with pre-set acceptance criteria. It's far more persuasive than literature citations and far cheaper than the resubmission you're avoiding.
Then close the loop with an evidence-to-claims crosswalk table, and make sure the table's numbering and names match the body of the submission exactly. A crosswalk that points to the wrong section is worse than no crosswalk, because now you've demonstrated you can't trace your own file. Here's how one example team scored before and after integrating their evidence story:
Notice the pattern: nothing about their science changed. The integration did. That's the whole game.
Way #5, Win the First Response: Turn a Refusal Letter into a Filing-Upgrade Plan
So the letter came anyway. Here's where teams split into two camps: the ones who argue, and the ones who rebuild. Be the second one.
The RTA letter is a gift in an ugly envelope, because it arrives with the annotated checklist, FDA tells you exactly which boxes failed. Your first move is classification, not drafting. Sort every flagged item into one of three buckets: missing (the section or attachment genuinely isn't there), insufficient (it's there but the justification is thin), or mismatch (two parts of the package contradict each other). Mismatches are the silent killers, because adding more pages won't fix them, only reconciling the documents will.
From that classification, build a gap map: each reviewer concern on one side, the exact fix and its location in the resubmission on the other. Then revise with ruthless version control. Clean file names, dated drafts, and, this is the piece everyone skips, a difference log that summarizes what changed between the refused submission and the new one. When your resubmission lands, that log is the first thing a screener can use to see the improvements instantly. You're not writing a rebuttal. You're handing them a faster triage.
One insider tip that founders underuse: if any deficiency in the letter is genuinely ambiguous, ask for clarification. A short call with the review team beats guessing wrong and eating a second refusal. Reviewers will tell you what "adequate" looks like. They won't write your submission, but they'll define the bar.
Operationally, run the response as a war room. Regulatory lead, technical lead, labeling lead, quality lead, one room, one shared source of truth, one owner per gap. The failure mode I see most often: the regulatory person writes a beautiful narrative response while the underlying sections never actually get fixed, and the resubmission carries the same contradictions in a longer package. Don't add pages. Fix sections. Expect the resubmission to start a new clock and, generally, a new fee, which is exactly why speed and completeness matter more than eloquence here.
What the Veterans Know
A refusal to accept feels like the end of the story. It isn't even the middle. The teams that clear fastest aren't the ones with the flashiest devices, they're the ones who treat the reviewer like a user, and the submission like a product that has to work on the first open.
Three things to tattoo on your regulatory brain:
- Refusal is usually a completeness and clarity failure. Make the package easy to triage and hard to misunderstand, and half the battle never happens.
- Traceability is the whole pattern: claims ↔ labeling ↔ tests ↔ risk controls, with a difference-by-difference predicate argument wherever your technology diverges.
- The first response is a rebuild plan, not a debate. Gap map, difference log, version-controlled fixes, one war room.
Six months from now, you'll barely remember the sting of that email. What you'll remember is whether your team spent those weeks arguing with the checklist, or beating it.
