The summary FDA writes, not the sponsor

A 510(k) applicant chooses, under 21 CFR 807.92, between a public 510(k) Summary and a thinner 510(k) Statement that only promises the underlying data to whoever asks for it within 30 days. A PMA applicant gets no equivalent choice. FDA writes the disclosure document itself, and the statute that requires it doesn’t care which way the application came out.

The statute that requires FDA to write it

Section 520(h)(1)(A) of the FD&C Act — 21 U.S.C. § 360j(h)(1)(A) — requires FDA to make a Summary of Safety and Effectiveness Data, an SSED, publicly available once it issues an order on a PMA. The obligation runs to FDA, not the applicant. A sponsor shapes what goes into the application. It does not get to choose the format the public ultimately reads, the way a 510(k) submitter does.

Approved or denied, one gets written either way

The SSED is not an approval artifact only. FDA prepares one for an approval order and for a denial order alike — the same document type, the same statutory trigger, regardless of which way the review came out. A 510(k) that fails to clear as Not Substantially Equivalent leaves no comparable public summary behind. A PMA that FDA turns down does.

What can be withheld, and what can’t

21 CFR 814.9 lets a sponsor ask FDA to withhold trade-secret or confidential commercial information from what becomes public, and FDA redacts accordingly. What it doesn’t do is make the underlying disclosure discretionary. A protocol for a test or study in the file is available for public disclosure unless it’s actually shown to meet that confidentiality standard — the sponsor argues for a specific redaction, not for skipping the summary altogether.

A PMA sponsor shapes the application. FDA writes what the public reads.

A document, not a field

openFDA’s PMA endpoint returns a decision_code — APPR for approval, DENY for denial, and several others — alongside the applicant, the product code, and the advisory committee. It returns no SSED content and no link to one. The document itself lives as a standalone PDF, indexed by PMA number, outside every field the API actually carries. Reading it is a separate step from reading the record, and it is the step that actually carries the clinical data — study design, endpoints, adverse events — a predicate or competitor assessment usually wants.

The practice

When a PMA record shows up on a device your portfolio compares against, treat decision_code as the pointer, not the substance, and go read the SSED behind it — approval or denial both have one. Per what we monitor and how often, this is regulatory intelligence and method for reading a public PMA record, never regulatory advice about what a specific device’s data means for your own submission — that judgment belongs with your regulatory professional.