A letter to file never reaches FDA, but has to survive one

This blog has already walked through the two-prong test 21 CFR 807.81(a)(3) sets for deciding whether a device change needs a new 510(k), and the four flowcharts FDA's 2017 guidance uses to apply that test to a real engineering change. Most of the time, that analysis ends in a negative: no new submission required. What the guidance does not let a manufacturer do is treat that negative as the end of the paperwork. The document a negative conclusion produces has a name industry settled on before FDA ever used it in guidance text — a letter to file — and it has to be built to survive a reading it was never written for.

A record built for a reader who wasn't there

A letter to file goes nowhere near FDA at the time it's written. It sits inside the manufacturer's own design history file or change-control record, created and dated the same day the change evaluation concludes, and it stays there — read only by people inside the manufacturer's own quality system, unless and until an FDA investigator asks for it years later during a for-cause or routine inspection. That gap between when it's written and when it might be read is the whole design problem: the document has to make sense cold, to someone who wasn't in the room for the engineering discussion and has no context beyond what the letter itself supplies.

FDA's own guidance names what has to survive that reading

FDA's 2017 guidance, Deciding When to Submit a 510(k) for a Change to an Existing Device, is explicit that documenting a negative conclusion isn't optional, and explicit about what that documentation has to do: let a reviewer or an investigator reconstruct the rationale behind the decision at each point in the applicable flowchart, not just record which box was checked. A letter to file that states the change and the bottom line — “changed supplier, no new 510(k) required” — without walking through why the flowchart's own questions resolved that way has recorded a conclusion, not the reasoning the guidance actually asks for.

A conclusion has to rest on finished verification, not a flowchart alone

The guidance treats a negative answer as provisional until it's confirmed by successful, routine verification and validation activities specific to the change, which means a letter to file written and closed out before that V&V data exists has documented a conclusion the manufacturer hadn't actually earned yet. The same discipline a design-and-development record already owes its own Clause 7.3 file applies here: a letter to file isn't a parallel, lighter-weight record running alongside the engineering change file, it's the regulatory conclusion that change file's own verification data has to support before the letter can close.

The record a “yes” never needed to write

A manufacturer that reaches the opposite conclusion skips the letter to file entirely and goes straight into a new 510(k) submission instead, often the same Special 510(k) pathway built to streamline review when the change is the kind the pathway was designed for. The two outcomes don't produce parallel paperwork; a yes retires the question into a new clearance, and a no retires it into a file that has to keep answering the same question indefinitely, every time an inspector opens it.

What makes a letter to file worth trusting later

The same test this blog has already applied to every other record built to survive a cold read applies here without modification: does it name the change precisely enough that a reader unfamiliar with the engineering can tell what actually moved, does it show the flowchart's own reasoning rather than its conclusion, and does it point to the verification data rather than asserting the data exists. A letter to file that passes all three has done the one thing the guidance actually asks for. One that passes only the first has written a memo, not a regulatory record.

Where this meets the file

A change-evaluation record built around this structure — the flowchart walked question by question, the confirming V&V data referenced by its own record, and the rationale written as if the reader has no other context — is previewed in the launch catalog. If your program writes a letter to file differently, the shelf takes that correction directly.