No field on a 510(k) says what it treats
Intended use and indications for use are legally distinct questions under FDA's own rules, and neither is a field in the 510(k) record the API actually publishes — only a product code stands in for what a cleared device is for.
By Connor Griggs — Regulatory & Quality Strategist
A 510(k) record answers what a device is — device name, applicant, product code, decision date. It does not answer what the device is for, and a competitive landscape built by clinical indication routinely assumes otherwise. “Intended use” and “indications for use” get used as synonyms in hallway conversation, and neither term is a searchable field in the public record that assumption is built on.
Two questions FDA treats as legally distinct
21 CFR 801.4 defines “intended uses” as the objective intent of the persons legally responsible for a device’s labeling — shown by labeling claims, advertising, oral or written statements, or the circumstances under which the device is actually sold, not by what a label alone says. Indications for use is narrower and more specific. FDA’s own guidance, Determination of Intended Use for 510(k) Devices (an update to K98-1, finalized December 2002), describes the indications for use statement — the disease or condition a device treats, diagnoses, or mitigates, and the patient population it is for — as one factor in determining intended use, not a synonym for it. A device’s intended use can stay the same across a change in indications; a change in indications creates a new intended use only when the difference affects safety or effectiveness enough that substantial equivalence can no longer absorb it. The two questions are evaluated together on every 510(k). They are not the same question.
What the record actually stores
Neither term is a field in openFDA’s 510(k) dataset. An applicant enters indications for use on Form FDA 3881 filed with the submission — free text, checked against the device’s labeling, never transcribed into the structured record FDA publishes through its API. What the API does expose is a product code — a three-letter identifier tied to a device’s classification regulation and generic type, close enough to “what kind of device this is” to support product-code matching, and not close enough to answer “what does it treat.” Two clearances filed under the same product code can carry materially different indications for use; two devices with entirely different intended uses can share device-name text an applicant chose freely, with nothing in the row that flags the difference.
A product code says what class of device this is. It has never said what the device treats.
The practice
Reading indications for use means opening the file behind the row — the 510(k) summary or the statement it names — not filtering the row itself. This is regulatory intelligence and method, never regulatory advice: a database read honestly tells you what it does and does not encode, and this one, honestly read, does not encode clinical indication. Anyone building a competitive landscape by condition treated, rather than by product code, should plan for reading the underlying files, because no filter on the public record does that reading first. FDA Radar joins clearances to a portfolio by product code, per what we monitor and how often — a product code stands in for a device’s classification, never for its clinical indication, and no field in the record we ingest closes that gap.
Primary sources
- eCFR — 21 CFR 801.4, Meaning of intended uses
- FDA — Determination of Intended Use for 510(k) Devices; Guidance for CDRH Staff (Update to K98-1)
- FDA — 510(k) Forms (Form FDA 3881, Indications for Use)
- openFDA — Device 510(k) 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.