The least interesting fact in a 510(k)

A cleared 510(k) has one headline fact, and it is the least interesting thing in the record: cleared. Watch a product code for a year and you will read dozens of these. If the headline is all you take from each one, you have read the same fact dozens of times and missed the three that actually vary.

Substantially equivalent is not one code

The decision on a 510(k) is stored as a short code, not a yes/no flag, and the codes are not interchangeable. SESE means substantially equivalent, plain. SESU means substantially equivalent with limitations. SESP means substantially equivalent with postmarket surveillance required. NSE means not substantially equivalent — a decision that sits in the same database as every clearance, easy to miss if you are scanning for “cleared” and skipping the rest of the row. A device cleared SESU or SESP carries a condition FDA attached on the way through; a device cleared SESE did not. That is a materially different fact about a competitor’s device than “it cleared,” and it is sitting in a field most monitoring stops before reaching.

Whether a person read the file, or FDA did

A second field records whether the review happened inside FDA at all. Certain Class I and II devices are eligible for FDA’s 510(k) Third Party Review Program — a voluntary route where an accredited third-party organization reviews the submission and forwards a recommendation, with FDA aiming to issue the final decision within about thirty calendar days of receiving the complete review package. There is no FDA user fee on this path; the submitter pays the accredited reviewer directly. The record’s third-party flag is a plain yes or no, and it tells you which of those two reviews actually happened — worth knowing before you assume every clearance in a product code went through the same scrutiny.

The disclosure choice, made before day one

The third field is the one that decides whether a public record of the underlying safety and effectiveness data will ever exist. Before submitting, an applicant chooses between a 510(k) summary — content and format set by 21 CFR 807.92, which FDA posts publicly once the device clears — and a 510(k) statement under 21 CFR 807.93, a commitment to provide that same information within thirty days to anyone who asks, instead of it being posted at all. The choice locks in once the substantial-equivalence determination is made. So a predicate file built from public 510(k) summaries has a gap built into the method before you start reading: any predicate that chose the statement route has no public summary to read, and the record’s own field says so before you go looking for one.

None of this is a substitute for reading the file. It is regulatory intelligence and method — what a field means, not what your submission should say about it. But a product code is a stack of these records, not one, and the pattern across the stack — how many carry conditions, how many went through a third party, how many chose disclosure and how many chose the thirty-day commitment instead — is a different, and better, question than counting how many cleared. FDA Radar ingests these fields daily and joins them to your portfolio by product code; per what we monitor and how often, that feed is built to answer “who else cleared in my product code,” and it is deliberately never pushed into your daily digest as volume for its own sake.