There are two recall databases, not one
openFDA publishes two separate device recall datasets, sourced and shaped differently — one carries the K-number and PMA number a recall traces back to, the other carries the classification that says how serious it was. No record in either has both.
By Connor Griggs — Regulatory & Quality Strategist
Ask openFDA for device recalls and it answers with two different datasets, not one. device/recall.json and device/enforcement.json both cover the same category of event, and they are not two views of one table. They carry different fields, and neither is a superset of the other.
The endpoint that knows the K-number
device/recall.json is CDRH’s own recall record, running from 2002 to the present. It carries a k_numbers field and a pma_numbers field — the actual clearance or approval number the recalled device traces back to — plus a root_cause_description and a cfres_id tying the record to CDRH’s internal recall system. What it does not carry is a recall classification field. Class I, II, or III, the single fact most recall monitoring exists to surface, is not a field on this record at all.
The endpoint that knows the class
device/enforcement.json is a different dataset: openFDA’s harmonized enforcement report, the same schema shared with drug and food recalls, sourced from FDA’s Recall Enterprise System and covering publicly releasable records from 2004 forward. This one carries classification, voluntary_mandated, and distribution_pattern — fields earlier posts on this blog have already read closely. What it does not carry is a K-number or a PMA number. A query that joins a recall to the clearance it affects, by reading this endpoint’s own fields, has nothing to join on; the only submission-adjacent field here is openFDA’s own product_code annotation, which names a device category, not the specific 510(k) or PMA the recalled device cleared under.
Ask “which of my cleared devices got recalled” of the endpoint built for classification, and it cannot answer by K-number. Ask it of the endpoint built for K-numbers, and it cannot say how bad the recall was. Neither gap is a defect in the one you happened to query.
The practice
Decide which fact the question needs before writing the query. “How severe were this quarter’s device recalls” wants classification, and belongs on the enforcement endpoint. “Did this specific 510(k) ever get recalled” wants the K-number field, and belongs on the recall endpoint, joined by hand against a K-number list, since the enforcement endpoint has no field to join on for that question. Assume one endpoint answers both, and a script either returns nothing for a question it was never built to answer, or silently drops the severity read the exercise depended on.
Which endpoint is right is a question about the record, not about a specific device or filing — that judgment, like every reading in Signals, is regulatory intelligence and method, never regulatory advice about a submission of your own.
FDA Radar’s recall corpus is built on the enforcement endpoint: classification is the field a monitoring product needs to tell a Class I recall from a Class III one, and it is not on the other dataset at all. The K-number link is the tradeoff that comes with it — one this page names directly, rather than leaving a reader to discover it from a query that comes back empty.
Primary sources
- openFDA — Device Recall Overview
- openFDA — Device Recall field reference
- openFDA — Device Enforcement Overview
- openFDA — Device Enforcement field reference
- FDA Radar — what we monitor and how often
Regulatory intelligence, not regulatory advice. This post describes method and published FDA records as of its date; decisions about a specific device belong with your regulatory professional.