Healthcare Exclusion Screening API - LEIE + State Medicaid + FDA (JSON)

Who this is for: compliance-SaaS builders, hospital and practice credentialing teams, health plan network/vendor-management teams, and pharma/clinical-research GxP compliance programs that need to check whether a provider, vendor, or investigator is excluded from federal healthcare programs (or FDA-debarred) before you credential them, pay them, or bring them onto a study - in one call across federal LEIE, four state Medicaid exclusion lists, and FDA debarment/disqualified- investigator lists, instead of building and maintaining seven separate integrations yourself.

No API key required. This actor screens names against the federal HHS-OIG List of Excluded Individuals/Entities (LEIE), four confirmed-clean state Medicaid exclusion lists (California, Georgia, Ohio, New York), and FDA's drug-application debarment list plus disqualified/restricted clinical investigators - all in one normalized feed, all keyless public sources, no scraping behind logins or bot walls. Optional incremental monitoring for scheduled runs, and a screening-attestation output record that gives you a clean audit trail when a full-coverage screen finds zero matches.

Worked example

Say your credentialing team is onboarding a new dental contractor named "Diamond" and needs to know, before payroll goes live, whether that name shows up on any of the 7 sources this actor covers. You call this actor with:

{ "names": ["Diamond"] }

With the default sources left untouched (all 7), the run returns one exclusion-record per hit

• in this real example, 25 records across 4 of the 7 sources, including:

{
  "recordType": "exclusion-record",
  "source": "LEIE",
  "entityName": "DIAMOND DENTAL SERVICES, LLP",
  "providerType": "DENTAL PRACTICE",
  "exclusionType": "1128b8",
  "effectiveDate": "20030520",
  "city": "POCATELLO",
  "state": "ID"
}

That's your answer: don't onboard this vendor without review - the entity is on the federal exclusion list. If instead you screen a clean name and get zero matches across all 7 sources, you don't just get an empty dataset - you get a screening-attestation record (

{ recordType: "screening-attestation", namesScreened, sourcesScreened, matchCount: 0, message, attestedAt }

1. What this is for

This actor is a data feed for developers and compliance-SaaS builders embedding healthcare exclusion screening into their own product or workflow - not a consumer background-check tool, and not a claim that any single source here satisfies every applicable legal requirement on its own. See "Honest scope" below before relying on this for a compliance program.

2. Honest scope (read this before you rely on it for compliance)

• This is NOT required by a single federal regulation covering every source here. 42 CFR Section 455.436 requires state Medicaid agencies to check the federal databases (LEIE, NPPES, the Death Master File, SAM.gov) monthly - it does not name state exclusion lists. Several states independently require checking their own list in addition to LEIE (a real, if less centralized, obligation) - this actor exists to make that broader check practical, not to imply one master statute compels all seven sources.
• Do not use this for employee background checks or general people-search. This is program-eligibility/billing-compliance screening (is this individual or entity excluded from Medicare/Medicaid/federal healthcare programs, or FDA-debarred), a narrow purpose distinct from FCRA-governed consumer background checks. Positioned and priced for compliance-SaaS builders and developers embedding a data feed, not as a "cheap alternative" to a practice-level compliance subscription (a real $40/mo competitor - Exclusion Screening LLC's all-46-state product - already owns that specific positioning; this actor's real edge is the data feed, not being cheaper at the same job).
• Only 4 states, not "all 50." California, Georgia, Ohio, and New York were verified at file level as genuinely public, keyless, and reliably parseable. Illinois was evaluated and excluded (its listed data source turned out to be a bot-hostile portal with no real bulk file, contradicting an independent source that had already flagged it). Texas was evaluated and excluded (Akamai edge block). This is a deliberate, verified subset - never marketed as comprehensive state coverage.

3. Sources and what each one's legal/business hook actually is

• LEIE (federal) - HHS-OIG's List of Excluded Individuals/Entities, oig.hhs.gov/exclusions. 42 CFR Section 1001 et seq. governs the underlying exclusion authority; the closest citable monthly-check norm is 42 CFR Section 455.436 (binds state Medicaid agencies to check federal databases, LEIE included).
• CA/GA/OH/NY (state) - each state's own Medicaid program-integrity exclusion list. The monthly-check norm for these is a matter of STATE-level policy/guidance, not one federal statute
  • verify your own state's specific requirement before treating this as a compliance mandate.
• FDA_DEBARMENT / FDA_INVESTIGATORS - FDA's drug-application debarment list (21 U.S.C. Section 335a) and disqualified/restricted clinical investigators list. The real ongoing-monitoring hook here is 21 U.S.C. Section 335b's continuous civil monetary penalty exposure (up to $250,000 per individual, $1,000,000 per entity, per violation) for knowingly using a debarred person's services - plus standard GxP vendor-qualification norms in pharma/clinical-research compliance programs. This is a real, ongoing CMP-liability driver, not a one-time "check at application" formality, but it is also not a "mandate" in the sense of a required recurring-screening statute - described honestly as a liability-avoidance driver.

4. Why the state-list "coverage gap" claim is real, not marketing

Verisys (a compliance vendor in this exact space) states LEIE alone "misses up to 61% of exclusions at the state level" - that statistic traces to a 2011 OIG audit of 2008 data, cited here with that vintage attributed explicitly rather than presented as a current measurement. It's the best publicly available evidence for the coverage-gap thesis, not a fresh number.

5. How it works

1. Names to screen (names input, optional): substring match, diacritic-folded, tolerant of "Last, First" vs "First Last" order - the same deliberately simple screening approach (not a fuzzy-matching compliance engine) this fleet's OFAC sanctions actor uses, and the same documented limitation applies: no phonetic matching, no typo tolerance.
2. Sources to include (sources input, default = all 7): LEIE, CA, GA, OH, NY, FDA_DEBARMENT, FDA_INVESTIGATORS.
3. Bare/no-names default stays cheap on purpose: with no names and the default sources left untouched, this actor pulls ONLY the current LEIE monthly supplement (new exclusions added that month - real, small, non-empty) rather than all 7 full sources. Pushing LEIE's full ~83,000-row history (let alone all 7 sources) as individual dataset items on every zero-input run would risk the same Apify run-cost-cap abort this fleet's OFAC actor hit once on its own unbounded default. A real screen (names provided) always uses the FULL LEIE file and all requested sources - this narrowing never applies once there's something real to screen.
4. Optional incremental monitor mode (monitorMode): remembers what's already been seen (via a persistent named key-value store) and emits a separate new-listing record for anything newly added since the last run. Also switches LEIE's fetch to the monthly supplement (instead of the full file) when no names are being screened, since "what's new" is the natural monitoring question - a real screen (names provided) still always uses the full file regardless of monitor mode.
5. A quota guard (maxRecordsPerRun) caps matched records delivered PER SOURCE independently - never a shared budget, so one large source can't silently starve a smaller one while the run still reports success.

6. Input

See the Input tab for the full form with inline descriptions.

7. Output fields

Each dataset item has a recordType of "exclusion-record", "new-listing" (monitor mode only), "source-status" (only when a source's delivery was truncated by maxRecordsPerRun), "sources-coverage" (only when fewer than all 7 sources were included this run), or "screening-attestation" (only when a real, full-coverage screen finds zero matches).

exclusion-record - one flat shape shared by all 7 sources (fields not applicable to a given source are simply null, rather than 7 separate schemas):

new-listing (monitor mode only):

{ recordType: "new-listing", source, key, record, detectedAt }

sources-coverage: emitted whenever a run covers fewer than all 7 sources -

{ recordType: "sources-coverage", sourcesScreened, sourcesOmitted, message, detectedAt }

screening-attestation: emitted when a real, full-coverage screen (names provided, all 7 sources) finds zero matches -

{ recordType: "screening-attestation", namesScreened, sourcesScreened, matchCount: 0, message, attestedAt }

source-status:

{ recordType: "source-status", source, status: "SKIPPED"|"TRUNCATED", reason, message, detectedAt }

Real sample output

Live-fetched screening {"names":["Diamond"]} - not a fabricated example. This single query matched across 4 of the 7 sources (LEIE x16, CA x5, GA x1, OH x2, FDA_INVESTIGATORS x1), confirming cross-source matching works, not just single-source lookups:

{
  "recordType": "exclusion-record",
  "source": "LEIE",
  "entityName": "DIAMOND DENTAL SERVICES, LLP",
  "individualName": null,
  "npi": null,
  "licenseNumber": null,
  "providerType": "DENTAL PRACTICE",
  "exclusionType": "1128b8",
  "effectiveDate": "20030520",
  "endDate": null,
  "city": "POCATELLO",
  "state": "ID",
  "address": "353 N 4TH AVE, STE 102",
  "fetchedAt": "2026-07-18T01:37:05.150Z",
  "sourceUrl": "oig.hhs.gov/exclusions"
}

{
  "recordType": "exclusion-record",
  "source": "CA",
  "entityName": null,
  "individualName": "Mary Stephania Diamond",
  "npi": null,
  "licenseNumber": "647777",
  "providerType": "Registered Nurse",
  "exclusionType": "Indefinitely effective",
  "effectiveDate": "08/17/2018",
  "endDate": null,
  "city": null,
  "state": null,
  "address": "2550 Ruby Ct., Redding, CA, 96001-3733",
  "fetchedAt": "2026-07-18T01:37:07.560Z",
  "sourceUrl": "data.chhs.ca.gov (Provider Suspended and Ineligible List)"
}

Note entityName/individualName are mutually exclusive per record (an entity exclusion vs. an individual exclusion), and effectiveDate's format differs between the two sources - both are the honest, expected shape given each source's own native format, not a normalization gap.

8. Use cases

• Compliance-SaaS platforms - embed cross-source exclusion screening (federal + state + FDA) into an existing credentialing or vendor-onboarding product via one data feed instead of seven separate integrations.
• Healthcare provider credentialing - screen new hires, contractors, and vendors against LEIE plus your state's own Medicaid exclusion list in one call.
• Pharma / clinical-research GxP compliance - screen investigators and vendors against FDA debarment and disqualified-investigator lists as part of vendor qualification (see the Section 335b CMP-liability note above).
• Legal / M&A due diligence - pull a target's exclusion history across all 7 sources before closing a healthcare-sector transaction.
• Ongoing monitoring - monitorMode catches newly-added exclusions against a standing provider/vendor roster without re-screening from scratch every run.

9. Setting up monitoring alerts (Apify Schedules + your own notification channel)

This actor produces structured data; wiring that into an email/Slack/Teams alert is done with Apify's own platform features, not actor-specific code:

1. Create an Apify Schedule pointing at this actor, with monitorMode: true and your names/sources set. Monthly aligns with LEIE's own supplement cadence; more frequent runs are still safe (state sources refresh on their own independent schedules).
2. Attach a Webhook to the schedule/actor for the ACTOR.RUN.SUCCEEDED event. Apify's webhook payload includes the run's dataset ID, so your webhook target can fetch the new items.
3. Route the webhook to Slack/Teams via their native "incoming webhook" URL, or to email via a lightweight relay (e.g. a Zapier/Make webhook-to-email step) - filter for

   recordType: "new-listing"
   so every triggered notification represents a genuinely new exclusion, not a repeat.
4. Because the dataset always distinguishes exclusion-record/new-listing from source-status/sources-coverage/screening-attestation records, your alert logic can (and should) treat the status records as operational signal (a source degraded, or coverage was narrower than expected) rather than silently trusting an empty result as clean.

10. Pricing

Pay per event (current live pricing - confirmed via the Apify API at time of writing):

• exclusion-record - $0.005 per exclusion/debarment record delivered (any of the 7 sources)
• monitor-run - $0.05 per scheduled monitor-mode run, in addition to per-record charges

See the actor's Pricing tab for the authoritative, current numbers.

11. Use from Claude, Cursor, and other AI agents (MCP)

This actor can be called as a tool by any MCP-compatible AI client (Claude Desktop, Cursor, VS Code, etc.) via Apify's hosted MCP server, without any actor-specific integration code:

1. Point your MCP client at https://mcp.apify.com, authenticated with your Apify API token (as a bearer header or via OAuth - see Apify's MCP docs for client-specific config).
2. Expose this actor specifically with the tools query parameter: https://mcp.apify.com?tools=mooseandraven/healthcare-exclusion-suite
3. Your agent can then call it directly - e.g. "check if Jane Doe is on any healthcare exclusion list" maps naturally onto names. The actor's own input schema (this page's Input tab) is what the MCP tool schema is built from, so any filter documented here is available to the agent.

12. FAQ

How fresh is the data? Each source refreshes on its own independent schedule (LEIE monthly, state lists per their own release cadence) - this actor fetches live at run time, so results are as current as each source's own latest publication.

Do I need an API key for any of the 7 sources? No - all 7 are fully keyless, confirmed live.

Why did I get a screening-attestation record instead of just an empty result? A real, full-coverage screen (names + all 7 sources) that finds zero matches emits this as a positive, machine-readable proof the screen actually ran clean - useful for an audit trail where "the dataset is empty" alone isn't distinguishable from "something went wrong and nothing loaded."

Why did I get a sources-coverage record instead of just exclusion records? Either you explicitly passed a narrower sources list, or you ran with no names (which uses this actor's own cheap bare-run default of LEIE's monthly supplement only) - either way, this actor never lets a narrower-than-full-7 screen look like a complete one.

What's the pricing/subscription model? Pay-per-event, not a flat subscription - see Pricing above.

Is this a substitute for a state-specific compliance requirement I already have? Not necessarily - see Honest scope above. This actor covers 4 confirmed-clean states; verify your own state's specific requirement, especially if you operate outside CA/GA/OH/NY.

13. What it does NOT do / Limitations

• State/CA/GA/OH filenames and URLs churn - California's CSV filename embeds the current month (resolved dynamically via the CKAN API's package_show action, not hardcoded), and Georgia's and Ohio's document links update per release (resolved by scraping the current link off each state's listing page at runtime). If a state redesigns its page entirely, this actor will fail loudly (a clear "page shape may have changed" error) rather than silently parsing garbage.
• Ohio requires a browser User-Agent - confirmed live; a bare/generic UA gets a different response. This actor sends a real browser UA on every request as a result (a safe superset, not a workaround for anything resembling CAPTCHA/bot-detection bypass).
• FDA's own "download in Excel format" link is deliberately NOT used for the clinical investigators list - it sits behind Akamai bot-management (confirmed live: an anomalous 503 with _abck/bm_sz challenge cookies). The plain results page returns identical data cleanly with a real browser UA and no bot-challenge artifacts, so that's the source actually used.
• This is a deliberately simple screen (substring + diacritic-fold + name-order-swap), not a fuzzy-matching/phonetic compliance engine - same documented limitation as this fleet's OFAC actor.
• Only 4 states, not "all 50" - see Honest scope above.
• The matching-engine and per-source parsers are all live-verified (2026-07-17) against the real production endpoints, not just fixtures - see MAINTENANCE.md/TEST_MATRIX.md for the full verification record, including one real bug (an FDA page's   entity) a fixture-only test suite did not catch and a live run did.

Local development

npm install
npm test                # recorded-fixture unit tests, no network needed
npx apify-cli run       # local end-to-end run against the REAL live sources (keyless, no
                         # credentials needed) - see MAINTENANCE.md for the full live-verification
                         # record from this actor's initial build

Support

Built and maintained by Moose & Raven. Questions or issues: support@mooseandraven.com.