Building a working file of predicate and precedent devices

Everyone researching a predicate ends up on FDA's 510(k) database eventually: search, skim a few summaries, find what's needed for the submission at hand, close the tab. Nothing about that research survives to be useful the next time, which means the same search, on a related device a year later, starts from zero again.

The public database gives you the outcome, not the reasoning

The content requirements for a 510(k) summary under 21 CFR 807.92 produce a document written to be accepted, not to teach — a compressed, defensive account of why a device is substantially equivalent to its predicate, not a narrative of how the review actually went. Two devices with similar public summaries can have had very different paths to clearance: a difficult first cycle, an additional information request that narrowed the indication, a testing method that got questioned before the sponsor switched to a recognized standard. None of that shows up in the record FDA publishes. Your own notes about what actually mattered — not what the summary says, but what you noticed while reading it against the device's product code and the standards it cites — are knowledge nobody else's file has, which is exactly what makes a working file worth keeping instead of just researching a predicate fresh every time.

What to actually put in an entry

Keep it simple enough that you'll actually maintain it: product code and regulation number first, since that's how you'll search it later, then the K number, submitter, and clearance date, a one-line note on why the device is relevant to your own product area, and — when you can tell — the one thing that stood out, whether that's a testing standard cited, an indication narrowed during review, or a predicate relationship worth remembering in a year. Organize by product code, not device name; you'll remember what you were building far more reliably than you'll remember what FDA called someone else's device three years ago. The file works best as a byproduct of normal work, not a separate research project: every time a submission sends you back to the database, spend two extra minutes writing down why the entry mattered before you close the tab.

No single entry in a file like this is worth much on its own — the FDA's public database already has it. What the file gives you, after a few years of consistent entries, is a fast, honest answer to a question worth being able to answer quickly: has anyone tried this before, and what actually happened when they did.