A K-number isn't always a 510(k)

A record in openFDA’s device/510k dataset looks like exactly one thing: a 510(k) clearance, numbered the way FDA numbers 510(k)s, sitting in the dataset FDA built for 510(k)s. That reading is correct for most rows and wrong for a specific minority of them — and the field that would tell you which is which is not a field most queries think to check.

One field, two pathways

FDA’s own field reference for the device/510k endpoint documents k_number as the FDA-assigned number for the record, and spells out what the leading letters mean. A plain K or BK prefix is a premarket notification — a 510(k) in the ordinary sense, reviewed for substantial equivalence to a predicate. A DEN prefix is something else by law: a request evaluated under 513(f)(2), the automatic Class III designation pathway better known as De Novo, which grants marketing authorization to a novel device with no predicate at all. De Novo never got its own openFDA endpoint. Its granted requests were filed into the same device/510k dataset, under the same k_number field, distinguished from a true 510(k) by three letters at the front of the string and nothing else in the record’s shape.

What a careless count actually counts

That matters the moment anyone treats device/510k as a 510(k)-volume dataset without excluding the DEN-prefixed rows first. A query built to total a product code’s 510(k) clearances for the year, or to flag every new 510(k) against a competitor’s firm name, will silently fold De Novo grants into the same count unless it was written by someone who knew to filter the prefix out. The dataset doesn’t mislabel anything — it never claimed the field meant only 510(k) — but a reader who assumes the endpoint’s name describes every row in it will overcount one pathway and never notice the other one is mixed in.

The exemption that isn’t anywhere

Run the same check for a Humanitarian Device Exemption and the problem inverts. An HDE, authorized under 21 CFR Part 814, Subpart H for a device treating a disease or condition too rare to support a traditional effectiveness study, gets its own number — an H prefix — and its own public database at FDA’s own site. It does not get a row in device/510k, a row in device/pma, or an endpoint of its own among the device APIs openFDA documents: 510k, pma, classification, registrationlisting, enforcement, udi, and covid19serology. An HDE is not filtered out of openFDA. It was never ingested, because none of the endpoints openFDA publishes for devices was built to carry it.

A De Novo grant hides inside a dataset named for something else. An HDE isn’t hiding — it simply isn’t a resident of any device dataset openFDA offers. Absence means two different things here, and the record gives no sign of which.

The practice, stated plainly

Reading openFDA’s device endpoints as a map of everything FDA has authorized is a mistake in both directions at once: inflated where a pathway shares a field it doesn’t really belong to, and silent where a pathway has no field reserved for it anywhere. Before trusting a 510(k) count, strip the DEN-prefixed rows or decide, with reasons, to keep them in. Before trusting an openFDA-based watch to have caught everything authorized against a product code, ask separately whether the authorization in question was ever the kind these endpoints carry at all.

Which authorizations belong in a specific portfolio review, and what an openFDA gap should change about how that review gets built, is regulatory intelligence and method, never regulatory advice — a judgment for whoever owns the product. FDA Radar ingests the device/510k dataset as one of its sources, which means a De Novo grant can reach a subscriber through the same path a 510(k) does, and a Humanitarian Device Exemption cannot reach them through this product at all, for the same structural reason it cannot reach anyone through openFDA.