Part of Iceni Data · FDA Intel

FDA Intel: Device Clearance Monitor

Monitor new FDA 510(k), PMA, and De Novo device decisions by product code, applicant, or review panel — with a diff mode that returns only decisions since a given date. Built on openFDA's /device/510k, /device/pma, and /device/classification endpoints, plus a weekly-refreshed cache of FDA's De Novo database (which has no official API). Runs on the Apify platform, so you get scheduling, an API, webhooks, and monitoring for free.

What does FDA Device Clearance Monitor do?

This Actor queries FDA's public device-decision data and returns one flat row per decision — a 510(k) clearance, a PMA approval/supplement, or a De Novo classification grant — filtered by product code, applicant name, or review panel. Point it at a product code you care about (say QAS, radiological triage software) and it tells you every clearance FDA has issued for it, who got it, and when.

Run it once for the full history, or schedule it daily/weekly with decision_after set to your last run date to get a diff of only new decisions — useful for competitive intelligence, regulatory tracking, or feeding a Slack/email alert when a competitor (or you) gets cleared.

Why use FDA Device Clearance Monitor?

• Competitive intelligence: know the moment a competitor's device clears FDA, in which product code, under which review panel.
• Regulatory tracking: watch your own product codes for De Novo/PMA/510(k) activity across the whole category, not just your own filings.
• Market research: pull every decision for a product code or panel to size a device category by decision volume, applicant, and clearance pathway.
• No scraping of FDA's 510(k)/PMA data — it's read straight from openFDA's stable, documented JSON API. Schedule it, hit it via the Apify API, or wire it into a webhook/integration.

How to use FDA Device Clearance Monitor

1. Click Try for free (or Start) on this Actor's page.
2. In the Input tab, set product_codes, applicant_contains, and/or review_panel to whatever you want to track. Leave them blank to match everything (not recommended without decision_after — see Pricing).
3. Optionally set decision_after to a date (YYYY-MM-DD) to only get decisions since then — this is the diff mode, and what you'd use on a recurring schedule.
4. Click Start. When the run finishes, open the Dataset tab to view, filter, or export the results (JSON, CSV, Excel, HTML, and more).
5. To track De Novo decisions too (include_de_novo: true, the default), someone first needs to have run this Actor once with refresh_de_novo: true to build the cache — see De Novo data below. If the cache doesn't exist yet, De Novo rows are simply omitted; everything else still works.

Input

All fields are optional and every field has a description and example in the Input tab. Full schema: .actor/input_schema.json.

Field	Type	Description
product_codes	array of strings	FDA product codes to filter on, e.g. ["QAS", "OBO"]. Empty = match any.
applicant_contains	string	Case-insensitive substring match on applicant/requester name, e.g. "Medtronic".
review_panel	string	Two-letter advisory committee code ("CV") or full name ("Cardiovascular").
decision_after	string (date)	YYYY-MM-DD. Only decisions on/after this date — the diff-mode knob.
include_de_novo	boolean	Include cached De Novo grants alongside 510(k)/PMA. Default true.
refresh_de_novo	boolean	Maintenance mode: refresh the De Novo cache and exit. No rows, no charges. Default false.

Three worked inputs

1. Everything FDA has cleared for a specific product code:

{
  "product_codes": ["QAS"],
  "include_de_novo": true
}

2. Diff mode — new decisions across two product codes since a date, for a scheduled daily/weekly run:

{
  "product_codes": ["QAS", "OBO"],
  "decision_after": "2026-08-01",
  "include_de_novo": true
}

3. Everything a specific applicant has gotten cleared in a review panel, all history:

{
  "applicant_contains": "Medtronic",
  "review_panel": "CV",
  "include_de_novo": false
}

Maintenance run (typically on its own weekly schedule, with no other filters):

{
  "refresh_de_novo": true
}

Output

One flat JSON object per decision, pushed to the default dataset. You can download it as JSON, CSV, Excel, HTML, XML, or RSS from the Export results button. Dates are ISO 8601 (YYYY-MM-DD); missing values are null, never empty strings.

Example output row

{
  "decision_type": "510k",
  "number": "K261085",
  "device_name": "Rapid Vessel Occlusion (Rapid VO)",
  "applicant": "iSchemaView",
  "product_code": "QAS",
  "device_class": "2",
  "regulation_number": "892.2080",
  "review_panel": "Radiology",
  "decision_date": "2026-07-13",
  "decision_code": "SESE",
  "summary_url": "https://www.accessdata.fda.gov/cdrh_docs/pdf26/K261085.pdf",
  "applicant_city": "Golden",
  "applicant_state": "CO",
  "applicant_country": "US",
  "data_as_of": "2026-09-04",
  "source_urls": [
    "https://api.fda.gov/device/510k.json?search=k_number:\"K261085\"",
    "https://api.fda.gov/device/classification.json?search=product_code:\"QAS\""
  ]
}

Data table

Field	Description
decision_type	"510k", "pma", or "de_novo".
number	The decision's identifying number (K123456, P123456 or P123456/S001, DEN123456).
device_name	Device/trade name as filed.
applicant	Applicant/requester company name.
product_code	FDA 3-letter product code.
device_class	1, 2, or 3, from the classification join.
regulation_number	21 CFR regulation number, from the classification join.
review_panel	FDA medical specialty / advisory committee panel name.
decision_date	Date FDA issued the decision.
decision_code	FDA's short decision code (e.g. SESE, APPR, DENG).
summary_url	Link to the decision's public summary — a PDF for 510(k)/De Novo, FDA's database page for PMA. Not parsed — this Actor never opens or extracts text from these documents.
applicant_city / applicant_state / applicant_country	Applicant's filed address, where the source provides it.
data_as_of	Snapshot date this row's data reflects.
source_urls	The exact API/page URL(s) this row was built from.

What it does not return

• No PDF text extraction or parsing of any kind — summary_url is a link, not content.
• No enrichment from third-party sources (company financials, news, LinkedIn, etc.) — every field comes directly from FDA/openFDA.
• No personal data — these are corporate regulatory filings, not individuals.
• PMA rows have no applicant_country — openFDA's /device/pma endpoint doesn't expose one.

De Novo data

FDA has no official API and no bulk-download file for De Novo classification grants (openFDA doesn't cover it at all — verified against its own endpoint manifest). The only source is FDA's HTML search interface at accessdata.fda.gov, which is bot-protected. Because of that, De Novo works differently from 510(k)/PMA:

• A separate maintenance run with refresh_de_novo: true scrapes FDA's De Novo database (through a ScraperAPI-style proxy — set the SCRAPER_API_KEY environment variable) and stores a snapshot in the Actor's key-value store. This run returns no rows and charges nothing. Schedule this weekly.
• Normal monitoring runs with include_de_novo: true read that cached snapshot and filter it the same way as 510(k)/PMA results — they never hit FDA's site directly.
• If nobody has run a refresh yet, De Novo rows are simply omitted (a log warning explains why); 510(k)/PMA results are unaffected.
• De Novo rows are charged via the de_novo_returned event only when the cache is 14 days old or less. Older ("stale") cached rows are still returned — useful if a refresh has been failing — but aren't charged, and data_as_of reflects the cache's actual snapshot date, not today.
• The refresh is incremental (only fetches DEN numbers not already cached, newest first, capped per run) and self-heals a full backfill over a few weekly runs rather than one long one.

Refresh cadence by source

Source	Refresh cadence
/device/510k, /device/pma	Live on every run — openFDA is a stable, documented JSON API.
/device/classification	Live on every run, joined by product_code.
De Novo	Weekly, via a dedicated refresh_de_novo: true run. Never fetched live from a monitoring run.

Pricing / Cost estimation

This Actor uses the pay-per-event pricing model — you pay per row returned, not per compute second:

• record_returned — charged once per 510(k)/PMA row ($0.005/row).
• de_novo_returned — charged once per De Novo row, only when served from a fresh (≤14-day-old) cache.

(Event prices are configured in Apify Console under this Actor's monetization settings, not in code.)

Free-plan users are capped at 25 rows per run. Once that's hit, the Actor stops, sets the status message to Free tier limit reached, and exits normally (not an error) — no partial charges, no crash. Narrow your filters (product_codes, applicant_contains, review_panel, decision_after) to stay under that on the free plan, or upgrade for unlimited rows.

An unfiltered run (no product_codes, no applicant_contains, no review_panel, no decision_after) queries FDA's entire device-decision history — expect a lot of rows and, on the free plan, hitting the cap almost immediately. Always set at least one filter.

Tips / Advanced options

• Combine product_codes and decision_after for the tightest, cheapest diff-mode queries.
• review_panel accepts either the 2-letter advisory committee code or the descriptive name — both work, e.g. "CV" and "Cardiovascular" are equivalent.
• Run the refresh_de_novo: true maintenance task on a separate weekly schedule from your monitoring runs.
• source_urls on every row is a deterministic, single-record openFDA (or FDA page) URL — reusable outside the Actor to spot-check any row.

FAQ, disclaimers, and support

• Is this legal? Yes — 510(k), PMA, and De Novo decisions are public FDA regulatory records. The 510(k)/PMA/classification data comes from openFDA's public API, per its terms of use. The De Novo cache-refresh step respects robots.txt and skips itself if disallowed.
• This isn't medical or regulatory advice. Per openFDA's own disclaimer, don't rely on this data (or on openFDA) to make decisions regarding medical care; treat all results as unvalidated and verify anything decision-critical directly against FDA's own systems.
• Known limitations: PMA rows have no applicant country (not in the source data). The constructed 510(k)/De Novo PDF summary_url follows FDA's standard document-path convention but isn't returned directly by openFDA, so it can occasionally 404 for older or corrected submissions. De Novo data depends on a separately-maintained weekly cache and a working SCRAPER_API_KEY.
• Found a bug or have a feature request? Use this Actor's Issues tab. Need a custom variant (different sources, extra filters, alerting)? Reach out via the same tab.

Related tools

Part of the FDA Intel family on Apify:

• Recall & Enforcement Monitor — coming soon.
• Adverse Events (MAUDE) — coming soon.