A readiness review gets scheduled two weeks before a submission and then treated like a formality — one more meeting to confirm what everyone in the room already believes, which is that the file is done. That belief is exactly what the review exists to test. Its job is not to re-run the Refuse to Accept checklist. It is to look at the submission the way a stranger will, before FDA does, and find the places where the file quietly disagrees with itself.
What a readiness review is actually checking
The RTA checklist is an administrative-completeness test: does the submission contain the elements 21 CFR Part 807, Subpart E requires, in some form, somewhere in the file. A readiness review asks a different question: do those elements agree with each other. Does the predicate comparison table describe the predicate FDA actually cleared — the version, the indication, the technological characteristics as cleared — or an earlier draft of it that got updated in one place and not another. Does every claim in the labeling trace to a test report that is physically in the file, not a report you're confident exists somewhere. Does the device description in the 510(k) summary match, word for word, the device description in the test protocols, or has one of them drifted since the last major revision.
None of this shows up as a missing section. A file can satisfy every line of the RTA checklist and still contain three internally contradictory descriptions of the same device, because the checklist confirms presence, not coherence. That gap is where a readiness review earns its time.
Who belongs in the room
Bring someone from the test or engineering side who did not write the file, and have them walk the labeling and the predicate comparison cold, out loud. Bring a second regulatory reviewer if one is available — ideally someone who has taken this submission type through to clearance before. And if a finding touches a claim or a scope statement, bring in whoever wrote the regulatory rationale behind it, since a rationale that no longer matches the file in front of you is the single most common thing this kind of review catches. Keep the room small. The goal isn't consensus; it's a list.
Where this goes wrong
Scheduling it too late to change anything
Once a submission date has been said out loud to leadership, findings stop being fixes and start being negotiations. Run the review while there is still slack in the calendar to act on what it turns up.
Mistaking “complete” for “consistent”
The RTA checklist passes a file that has every required section. A readiness review is the check for whether those sections agree with each other — and a predicate table and a device description can each be individually complete while directly contradicting one another.
Letting the author review their own file
Whoever wrote the submission has already resolved every ambiguity in their own head, in whichever direction seemed obvious at the time. That resolved feeling is precisely the blind spot a second reader is there for.
A readiness review isn't a gate you pass so much as the last chance to catch, on your own schedule, what a reviewer will otherwise catch on theirs. Whatever it finds is worth writing down even after it's fixed — a short note in a decision log costs a few minutes now and saves you from re-litigating the same question from memory when someone asks about it after clearance.
Sources & further reading
- 21 CFR Part 807, Subpart E — premarket notification procedures and required content ecfr.gov
- FDA — Acceptance Review for 510(k)s: Refuse to Accept Policy for 510(k)s fda.gov
- Regulatory Academy — How to read FDA’s RTA checklist regulatoryacademy.com
- Regulatory Academy — How to write a regulatory rationale you can defend regulatoryacademy.com
- Regulatory Academy — The case for keeping a regulatory decision log regulatoryacademy.com
This essay is provided for general educational purposes and reflects the regulatory landscape as of its publication date. It is not legal, regulatory, or career advice.
