FDA Intel: Device Clearance Monitor avatar

FDA Intel: Device Clearance Monitor

Pricing

from $5.00 / 1,000 510(k) or pma decision rows

Go to Apify Store
FDA Intel: Device Clearance Monitor

FDA Intel: Device Clearance Monitor

Every new FDA 510(k), PMA, and De Novo clearance plus device recalls, enforcement actions, and establishment registrations for your product codes or companies, with weekly diff mode. Clean rows, summary links.

Pricing

from $5.00 / 1,000 510(k) or pma decision rows

Rating

0.0

(0)

Developer

Martyn Gross

Martyn Gross

Maintained by Community

Actor stats

0

Bookmarked

2

Total users

1

Monthly active users

23 days ago

Last modified

Categories

Share

Part of Iceni Data · FDA Intel

FDA Intel: Device Watchlist

Monitor FDA device clearances, recalls, and registrations by product code, applicant, or review panel — with a diff mode that returns only new clearances/recalls since a given date. Built on openFDA's /device/510k, /device/pma, /device/classification, /device/recall, /device/enforcement, and /device/registrationlisting 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 Watchlist do?

This Actor is a single watchlist over three independent FDA data sources, selected with the record_types input:

  • Clearance (510k, pma, de_novo) — every 510(k) clearance, PMA approval/supplement, and De Novo classification grant for a product code, applicant, or review panel. This is the original Clearance Monitor behavior, unchanged.
  • Recall (recall, enforcement) — device recalls from openFDA's /device/recall and the broader FDA compliance recall/enforcement reports from /device/enforcement, for the same product codes and applicant.
  • Registration (registration) — FDA establishment registrations and device listings: who's registered to make or distribute a product code, and where.

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, every recall against it, and every facility registered to make it — who, when, and where. 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 clearances/recalls since then — useful for competitive intelligence, regulatory tracking, or feeding a Slack/email alert.

Why use FDA Device Watchlist?

  • Competitive intelligence: know the moment a competitor's device clears FDA, gets recalled, or a new facility registers to make it.
  • Regulatory tracking: watch your own product codes for clearance, recall, and registration activity across the whole category, not just your own filings.
  • Supply chain / diligence: pull every registered establishment and every recall for a product code before you partner with, acquire, or compete against a device maker.
  • Market research: pull every decision, recall, or registration for a product code or panel to size a device category by volume, applicant, and pathway.
  • No scraping of openFDA data — it's read straight from openFDA's stable, documented JSON APIs. Schedule it, hit it via the Apify API, or wire it into a webhook/integration.

How to use FDA Device Watchlist

  1. Click Try for free (or Start) on this Actor's page.
  2. In the Input tab, set record_types to whichever of clearance, recall, and registration you want (default: clearance only — you can select all three).
  3. Set product_codes, applicant_contains, and/or (for clearance) review_panel to whatever you want to track. Leave them blank to match everything (not recommended without decision_after — see Pricing).
  4. Optionally set decision_after to a date (YYYY-MM-DD) to only get clearance/recall rows since then — this is the diff mode, and what you'd use on a recurring schedule. Registrations have no decision date and are unaffected by it.
  5. Click Start. When the run finishes, open the Dataset tab to view, filter, or export the results (JSON, CSV, Excel, HTML, and more) — or switch between the Clearances, Recalls, and Registrations views for a layout suited to each record type.
  6. To track De Novo decisions too (include_de_novo: true, the default, only relevant when record_types includes clearance), 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.

FieldTypeDescription
record_typesarray of stringsWhich of "clearance", "recall", "registration" to fetch. Default ["clearance"].
product_codesarray of stringsFDA product codes to filter on, e.g. ["QAS", "OBO"]. Applies to every selected record type. Empty = match any.
applicant_containsstringCase-insensitive substring match on applicant/requester (clearance), recalling firm (recall), or owner/operator (registration) name, e.g. "Medtronic". Applies to every selected record type.
review_panelstringTwo-letter advisory committee code ("CV") or full name ("Cardiovascular"). Clearance rows only.
decision_afterstring (date)YYYY-MM-DD. Only clearance/recall rows on/after this date — the diff-mode knob. No effect on registration rows.
include_de_novobooleanWhen record_types includes clearance, include cached De Novo grants alongside 510(k)/PMA. Default true.
refresh_de_novobooleanMaintenance mode: refresh the De Novo cache and exit. No rows, no charges. Default false.

Six worked inputs

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

{
"record_types": ["clearance"],
"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:

{
"record_types": ["clearance"],
"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:

{
"record_types": ["clearance"],
"applicant_contains": "Medtronic",
"review_panel": "CV",
"include_de_novo": false
}

4. Recall watchlist — every device recall and enforcement report for a product code since a date:

{
"record_types": ["recall"],
"product_codes": ["LWS"],
"decision_after": "2026-01-01"
}

5. Registration watchlist — every facility registered to make a product code:

{
"record_types": ["registration"],
"product_codes": ["QAS"]
}

6. Full watchlist on one applicant — clearances, recalls, and registrations together:

{
"record_types": ["clearance", "recall", "registration"],
"applicant_contains": "iSchemaView"
}

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

{
"refresh_de_novo": true
}

Output

One flat JSON object per clearance, recall/enforcement report, or registered product listing, 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; fields that don't apply to a row's decision_type are simply null.

What each record type returns

  • Clearance (decision_type: 510k / pma / de_novo) — the decision number, device/trade name, applicant, product code, device class, regulation number, review panel, decision date/code, and a link to the public summary document.
  • Recall (decision_type: recall / enforcement) — the FDA recall number, device/product description, recalling firm, product code, recall classification (Class I/II/III — only reported by /device/enforcement), reason for recall, root cause (only reported by /device/recall), status, event initiation date, report date, and any 510(k) numbers openFDA has linked to the recalled product.
  • Registration (decision_type: registration) — the FDA registration number, proprietary (device trade) name, owner/operator firm, product code, and the registered establishment's type, city, state, and country.

What it does not return

  • No PDF text extraction or parsing of any kind — summary_url is a link, not content.
  • No MedWatch adverse-event narratives (MAUDE) — this Actor covers clearances, recalls/enforcement, and registrations only, not adverse event reports.
  • No UDI/GUDID data (device identifiers, packaging, or catalog numbers) — that's a separate FDA database. AccessGUDID has its own free public API if you need it.
  • 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. Recall/enforcement's product_code is populated inconsistently by FDA — /device/recall covers it reliably, /device/enforcement often leaves it blank.

Example output rows

Clearance:

{
"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",
"classification": null,
"reason_for_recall": null,
"root_cause": null,
"status": null,
"event_initiation_date": null,
"openfda_k_numbers": [],
"establishment_type": null,
"establishment_city": null,
"establishment_state": null,
"establishment_country": null,
"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\""
]
}

Recall:

{
"decision_type": "recall",
"number": "Z-0001-04",
"device_name": "Sedecal SP-HF 4.0 Portable X-Ray System",
"applicant": "Sedecal USA, Inc",
"product_code": "IZL",
"device_class": null,
"regulation_number": null,
"review_panel": null,
"decision_date": "2003-10-29",
"decision_code": null,
"summary_url": null,
"applicant_city": null,
"applicant_state": null,
"applicant_country": null,
"classification": null,
"reason_for_recall": "A minimum source-skin-distance of less than 30 cm and not identifying the tube manufacturer on the tube housing label resulted in the SP-HF-4.0 Portable Systems not complying with the U.S. Federal performance standard.",
"root_cause": "Other",
"status": "Terminated",
"event_initiation_date": "2003-10-27",
"openfda_k_numbers": ["K020436"],
"establishment_type": null,
"establishment_city": null,
"establishment_state": null,
"establishment_country": null,
"data_as_of": "2026-09-04",
"source_urls": ["https://api.fda.gov/device/recall.json?search=product_res_number:\"Z-0001-04\""]
}

Registration:

{
"decision_type": "registration",
"number": "3011205675",
"device_name": "Rapid ICH",
"applicant": "iSchemaView, Inc.",
"product_code": "QAS",
"device_class": null,
"regulation_number": null,
"review_panel": null,
"decision_date": null,
"decision_code": null,
"summary_url": null,
"applicant_city": null,
"applicant_state": null,
"applicant_country": null,
"classification": null,
"reason_for_recall": null,
"root_cause": null,
"status": null,
"event_initiation_date": null,
"openfda_k_numbers": [],
"establishment_type": "Manufacture Medical Device",
"establishment_city": "Golden",
"establishment_state": "CO",
"establishment_country": "US",
"data_as_of": "2026-09-04",
"source_urls": ["https://api.fda.gov/device/registrationlisting.json?search=registration.registration_number:\"3011205675\""]
}

Data table

FieldDescription
decision_type"510k", "pma", "de_novo", "recall", "enforcement", or "registration".
numberThe row's identifying number: K123456/P123456 (or P123456/S001)/DEN123456 for clearances, an FDA recall number (e.g. Z-1234-24) for recall/enforcement, or an FDA registration number for registrations.
device_nameDevice/trade name (clearances), device or product description (recall/enforcement), or proprietary name (registrations).
applicantApplicant/requester company (clearances), recalling firm (recall/enforcement), or owner/operator firm (registrations).
product_codeFDA 3-letter product code.
device_classClearance only. 1, 2, or 3, from the classification join.
regulation_numberClearance only. 21 CFR regulation number, from the classification join.
review_panelClearance only. FDA medical specialty / advisory committee panel name.
decision_dateDate FDA issued the decision (clearance) or the report date (recall/enforcement). null for registrations.
decision_codeClearance only. FDA's short decision code (e.g. SESE, APPR, DENG).
summary_urlClearance only. Link to the decision's public summary — a PDF for 510(k)/De Novo, FDA's database page for PMA. Not parsed.
applicant_city / applicant_state / applicant_countryClearance only. Applicant's filed address, where the source provides it.
classificationRecall/enforcement only. FDA recall class I, II, or III. Only /device/enforcement reports this — always null on recall rows.
reason_for_recallRecall/enforcement only. FDA's stated reason for the recall.
root_causeRecall only. Firm-reported root cause. Always null on enforcement rows.
statusRecall/enforcement only. Recall status, e.g. Ongoing, Terminated, Open, Classified.
event_initiation_dateRecall/enforcement only. Date the firm initiated the recall.
openfda_k_numbersRecall/enforcement only. 510(k) number(s) openFDA has linked to the recalled product. Often empty.
establishment_type / establishment_city / establishment_state / establishment_countryRegistration only. The registered establishment's operation type and address.
data_as_ofSnapshot date this row's data reflects.
source_urlsThe exact API/page URL(s) this row was built from.

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 record_types including clearance and 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

SourceRefresh cadence
/device/510k, /device/pmaLive on every run — openFDA is a stable, documented JSON API.
/device/classificationLive on every run, joined by product_code.
/device/recall, /device/enforcementLive on every run.
/device/registrationlistingLive on every run.
De NovoWeekly, 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 clearance (510(k)/PMA) row or registration row ($0.005/row).
  • de_novo_returned — charged once per De Novo row, only when served from a fresh (≤14-day-old) cache.
  • recall_returned — charged once per recall/enforcement row.

(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, combined across every selected record_type. 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 history for whichever record_types you selected — 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.
  • Select multiple record_types in one run to build a single company or product-code dossier — clearances, recalls, and registered manufacturing sites together — instead of running three separate Actors.
  • 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/De Novo decisions, recalls, enforcement reports, and establishment registrations are all public FDA regulatory records. The live-queried 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. /device/enforcement's product_code field is populated for only a minority of records — recall coverage by product code is stronger via /device/recall. 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.

Part of the FDA Intel family on Apify:

  • FDA Intel: Device Watchlist (this Actor) — clearances, recalls & enforcement, and registrations & listings.
  • Adverse Events (MAUDE) — coming soon.
  • Adverse Event Summaries — MAUDE adverse event report summaries by device or manufacturer.