Service:
FDA Submission Strategy & Management
Client:
Post-Trial, Pre-Submission
Duration:
5 months
CONFIDENTIALITY NOTE:This case study represents a composite of multiple client engagements with software-based medical devices. Details have been changed to protect client confidentiality. The submission strategies described reflect real FDA review processes.
Great Data, Zero Clue How to Get to Clearance
The CEO had done everything right up to this point.
She'd spent 20 years at a major medical device company. VP of R&D. Knew the device world inside and out. When she left to start her own company, she brought the IP with her and backing from her former employer's venture arm.
She'd raised good money. Built a strong product. Run a clean clinical trial.
The data was excellent. The device worked. Patients benefited. Investigators were impressed.
But now she was stuck.
Her team was 35 people—mostly software engineers and product managers. Not a single person had ever written a 510(k) submission.
She'd hired a regulatory consultant to "handle FDA stuff," but that person was focused on quality systems and documentation, not submission strategy.
Her board wanted to know: "When are we getting cleared?"
Her honest answer: "I have no idea what happens next."
That's when she called.
The Problem: Engineering Mindset Meets FDA Reality
Here's what she told me on our first call:
"We have all this clinical data. It shows the device works. Why can't we just send it to FDA and get cleared?"
This is what happens when smart people from big companies try to navigate FDA as a startup.
At her old company (think Medtronic-sized), there was a 50-person regulatory team. When a trial finished, someone else handled the submission. She never saw that part.
Now she was that person. And she was realizing that having good data and knowing how to package it for FDA are completely different skills.
What Was Wrong
I asked to see what they had so far.
They'd started putting together a submission package. It was... not good.
Problem #1: Wrong Predicate Device
They'd identified a predicate device (the previously cleared device they'd compare themselves to) based on a Google search and what "seemed similar."
The predicate they chose was cleared 8 years ago under different guidance. Worse, it had a different intended use than their device.
If they'd submitted with this predicate, FDA would have rejected it immediately as "not substantially equivalent."
Problem #2: Clinical Data Was Buried
They'd included their clinical study report in the submission. All 200 pages of it. Dense. Statistical. Unreadable.
No summary. No "here's what this means" translation. Just raw data dump.
FDA reviewers don't have time to dig through 200 pages to figure out if your device works.
Problem #3: They Hadn't Anticipated FDA's Questions
Every 510(k) gets questions from FDA. It's normal. The key is anticipating what they'll ask and addressing it upfront in your submission.
Their submission didn't do this.
I could already see 5-6 questions FDA would ask. Each one would add weeks to the review timeline.
Problem #4: Software Documentation Was Incomplete
For software devices, FDA wants specific documentation about how the software was developed, tested, and validated.
Their software team had done good work. But they'd documented it the way software engineers document things (code comments, internal wikis, Jira tickets).
FDA wants it documented differently. Formal verification and validation protocols. Traceability matrices. Risk analysis.
They had the work done. They just didn't have it documented the way FDA expected.
Problem #5: Labeling Was an Afterthought
They'd drafted user instructions and labeling at the last minute.
Labeling isn't just the manual that comes with the device. It's how FDA understands what your device does, who it's for, and what claims you're making.
Their labeling had vague language, unsupported claims, and didn't match the clinical data.
FDA would shred it.
WHAT WE DID
Month 1: Build the Submission Strategy
I didn't start by writing the 510(k). I started by building the strategy.
Step 1: Find the Right Predicate
I searched FDA's database for devices that were:
Recently cleared (within last 3 years)
Same intended use as their device
Similar technological characteristics
Cleared through 510(k) (not De Novo, not PMA)
Found three candidates. Pulled the 510(k) summaries for each. Analyzed what FDA asked for in those submissions.
Picked the best match.
Step 2: Map Their Data to FDA's Questions
I listed every question FDA would likely ask:
How is this device different from the predicate?
What clinical data supports the claims?
How was the software validated?
What are the risks and how are they mitigated?
Who should and shouldn't use this device?
Then I mapped their existing data and documentation to each question.
Where we had gaps, we created a plan to fill them.
Step 3: Outline the Submission
510(k)s follow a standard format, but how you organize and present information matters.
I outlined the entire submission:
Executive summary (2 pages max—tell FDA the story upfront)
Device description (clear, specific)
Substantial equivalence comparison (side-by-side with predicate)
Performance testing summary (non-clinical bench testing)
Clinical evaluation (the trial data, summarized properly)
Software documentation (V&V, risk analysis)
Labeling (instructions, indications for use)
Each section had a clear purpose: answer FDA's questions before they ask them.
Month 2-3: Execute the Submission
I didn't write the entire 510(k) myself—that would be inefficient.
What I did:
Wrote the executive summary and substantial equivalence section (this is the most critical part)
Worked with their team to restructure the clinical data (turned 200 pages into a 15-page summary with the full report as an appendix)
Worked with their software team to document V&V properly (taught them what FDA needed to see)
Rewrote the labeling (clear indications, supported claims, appropriate warnings)
Reviewed every section before it went into the final package
We also did something smart: we had a regulatory medical writer review the draft and fill in FDA-required boilerplate sections.
Total package: About 400 pages (this is normal for a software device with clinical data).
But the first 50 pages told the complete story. The rest was supporting documentation.
Month 3: Pre-Submission Check
Before submitting, I did something that saved us weeks:
I sent the draft to two former FDA reviewers I know (both now in consulting). Asked them to review it like they were still at FDA.
They caught:
A minor inconsistency in our labeling vs. clinical data
A missing piece of software documentation (FDA would definitely ask for it)
A better way to frame one of our safety arguments
We fixed all of it before submitting.
Cost: A few thousand dollars in consulting fees.
Value: Probably saved 4-6 weeks of back-and-forth with FDA.
Month 4: Submission and Management
We submitted in Month 4.
FDA's initial response came 2 weeks later: Additional Information request.
This is normal. Almost every 510(k) gets at least one.
They asked for:
Clarification on a specific software test result
Additional information on how the device handles a certain edge case
Minor labeling changes
We'd anticipated two of these three questions and had the answers ready. The third one (the edge case) required us to run one additional software test.
We responded in 10 days.
FDA came back with one more minor question (labeling clarification).
We responded in 3 days.
Then: Clearance letter.
Total time from submission to clearance: 5 months.
Cleared Faster Than Expected
Industry average for 510(k) review: 6-9 months, often with multiple rounds of questions.
Their result: 5 months, two rounds of questions, both minor.
Why it was fast:
We chose the right predicate
We answered FDA's questions upfront
We had clean, well-organized documentation
We responded to questions quickly and thoroughly
Business Impact
The CEO had told her board "clearance in 12 months" (conservative estimate based on industry averages).
We got them cleared in 5 months from submission (7 months total from when I started).
That 5-month acceleration meant:
They launched to customers a full quarter earlier than planned
They hit their revenue targets for the year (would have missed them with a delay)
They went into their next funding round with an FDA-cleared product and early revenue (much stronger position)
The Money
I can't disclose exact costs (NDA), but here's the general picture:
My engagement: 4 months of work
Medical writer: Additional cost for documentation support
Former FDA reviewers (pre-submission review): A few thousand dollars
Compare to:
If they'd submitted the original version: Likely rejection or 12+ months of back-and-forth
If they'd hired a big regulatory consulting firm: $150K-300K
If they'd delayed launch by 6 months: Lost revenue worth far more than our fees
The CFO told the board: "Best money we spent this year."
Lessons Learned
Good Data Doesn't Speak for Itself
They had excellent clinical data. But buried in a 200-page report, FDA wouldn't find it.
You need to tell the story: Here's what we tested. Here's what we found. Here's why it matters.
FDA reviewers are smart, but they're busy. Make their job easy.
Predicate Selection Is Critical
Choose the wrong predicate, and your submission is dead on arrival.
Choose the right one, and FDA's review is straightforward.
This isn't something you figure out with a Google search. You need to understand FDA's database, recent clearances, and what makes devices "substantially equivalent."
Pre-Submission Review Is Worth It
Having former FDA reviewers look at your submission before you file it is the best insurance you can buy.
A few thousand dollars and 2 weeks of time saved them months of FDA back-and-forth.
Name Withheld (NDA)
CEO, Digital Health Company *Client confidentiality maintained
