# Healthcare Exclusion Screening - No API Key Required (`mooseandraven/healthcare-exclusion-suite`) Actor No API key required - screen names against the federal LEIE, 4 state Medicaid exclusion lists, and FDA debarment/investigator lists for healthcare compliance. - **URL**: https://apify.com/mooseandraven/healthcare-exclusion-suite.md - **Developed by:** [Moose & Raven](https://apify.com/mooseandraven) (community) - **Categories:** Lead generation, Business, Automation - **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks - **User rating**: No ratings yet ## Pricing from $5.00 / 1,000 exclusion records This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events. Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event ## What's an Apify Actor? Actors are a software tools running on the Apify platform, for all kinds of web data extraction and automation use cases. In Batch mode, an Actor accepts a well-defined JSON input, performs an action which can take anything from a few seconds to a few hours, and optionally produces a well-defined JSON output, datasets with results, or files in key-value store. In Standby mode, an Actor provides a web server which can be used as a website, API, or an MCP server. Actors are written with capital "A". ## How to integrate an Actor? If asked about integration, you help developers integrate Actors into their projects. You adapt to their stack and deliver integrations that are safe, well-documented, and production-ready. The best way to integrate Actors is as follows. In JavaScript/TypeScript projects, use official [JavaScript/TypeScript client](https://docs.apify.com/api/client/js/docs.md): ```bash npm install apify-client ``` In Python projects, use official [Python client library](https://docs.apify.com/api/client/python/docs.md): ```bash pip install apify-client ``` In shell scripts, use [Apify CLI](https://docs.apify.com/cli/docs.md): ````bash # MacOS / Linux curl -fsSL https://apify.com/install-cli.sh | bash # Windows irm https://apify.com/install-cli.ps1 | iex ```bash In AI frameworks, you might use the [Apify MCP server](https://docs.apify.com/integrations/mcp.md). If your project is in a different language, use the [REST API](https://docs.apify.com/api/v2.md). For usage examples, see the [API](#api) section below. For more details, see Apify documentation as [Markdown index](https://docs.apify.com/llms.txt) and [Markdown full-text](https://docs.apify.com/llms-full.txt). # README ## 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: ```json { "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: ```json { "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 }`) you can keep on file as positive, machine-readable proof the screen actually ran clean, not just silence that could mean "nothing loaded." That attestation record is this actor's own audit-trail differentiator - see section 7 for the full output shape. ### 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 | Field | Type | Notes | |---|---|---| | `names` | array | Names to screen across all included sources. Omit for a bare/monitoring-only run | | `sources` | array | Default = all 7: `LEIE`, `CA`, `GA`, `OH`, `NY`, `FDA_DEBARMENT`, `FDA_INVESTIGATORS` | | `monitorMode` | boolean | Persistent incremental "new since last run" tracking per source | | `maxRecordsPerRun` | integer | Per-source cap, independent for each of the 7 sources | 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): | Field | Type | Notes | |---|---|---| | `source` | string | `"LEIE"`, `"CA"`, `"GA"`, `"OH"`, `"NY"`, `"FDA_DEBARMENT"`, or `"FDA_INVESTIGATORS"` | | `entityName`, `individualName` | string | null | Whichever applies - an individual exclusion has `individualName` set and `entityName` null, and vice versa | | `npi`, `licenseNumber` | string | null | Present when the source publishes them - LEIE's placeholder NPI (`"0000000000"`) is normalized to `null`, not passed through | | `providerType`, `exclusionType` | string | null | Source-specific vocabulary, passed through as published (not normalized across sources into one taxonomy) | | `effectiveDate`, `endDate` | string | null | Format varies by source (e.g. LEIE's `YYYYMMDD` vs. CA's `MM/DD/YYYY`) - passed through exactly as each source publishes it, not reformatted | | `city`, `state`, `address` | string | null | Present when the source publishes them | | `fetchedAt`, `sourceUrl` | | `sourceUrl` names the specific originating page for that source | **`new-listing`** (monitor mode only): `{ recordType: "new-listing", source, key, record, detectedAt }` - `record` is the full `exclusion-record` shape above, embedded. **`sources-coverage`**: emitted whenever a run covers fewer than all 7 sources - `{ recordType: "sources-coverage", sourcesScreened, sourcesOmitted, message, detectedAt }`. Fires both for a caller's own explicit narrower `sources` choice AND for the cheap bare-run default, so a coverage gap is never silent either way. **`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 }`. A positive, machine-readable audit-trail record confirming the screen actually ran clean against all sources, not just an absence of other records in the dataset. **`source-status`**: `{ recordType: "source-status", source, status: "SKIPPED"|"TRUNCATED", reason, message, detectedAt }` - a per-source delivery problem, never silently absorbed into an otherwise-clean-looking result. #### 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: ```json { "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" } ``` ```json { "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. # Actor input Schema ## `names` (type: `array`): Individual or business names to screen against the selected exclusion sources (substring match, diacritic-folded, tolerant of "Last, First" vs "First Last" order — a deliberately simple screen, not a fuzzy-matching compliance engine; see README). Leave empty to just fetch/monitor the selected sources without screening a specific list of names — in that case, with the default sources left untouched, this actor pulls only the current LEIE monthly supplement (a cheap, real, non-empty default) rather than all 7 full sources, to stay fast and cheap with zero configuration. Provide names for a real, exhaustive screen across ALL selected sources. ## `sources` (type: `array`): Which sources to pull this run. LEIE = federal HHS-OIG List of Excluded Individuals/Entities. CA/GA/OH/NY = state Medicaid exclusion lists (only these 4 states are included — Illinois and Texas were evaluated and excluded: Illinois's data source turned out to be a bot-hostile portal with no real bulk file, Texas is Akamai-blocked). FDA\_DEBARMENT = FDA drug-application debarment list. FDA\_INVESTIGATORS = FDA disqualified/restricted clinical investigators. This is NOT a legally-mandated "screen all 50 states" product — see README for the honest scope and mandate framing. ## `monitorMode` (type: `boolean`): When on, remembers what's already been seen (via Apify's key-value store) and emits a separate `new-listing` record for anything not seen on a prior run — designed for scheduled runs watching for newly-added exclusions. Also switches LEIE's fetch to the monthly supplement file (new additions only) instead of the full historical file when no names are being screened, since "what's new" is the natural monitoring question. Charges one `monitor-run` PPE event in addition to per-record events. ## `maxRecordsPerRun` (type: `integer`): Safety cap on matched records delivered per source, applied INDEPENDENTLY to each source (not shared — a shared budget would let one large source starve a smaller one while the run still reports success). Set to 0 for no cap (default for a real screen — screening should be exhaustive). The bare zero-input default path (no names, default sources) is internally capped at 500 regardless of this setting, to guarantee Apify's own daily auto-test run stays fast and cheap. ## Actor input object example ```json { "names": [], "sources": [ "LEIE", "CA", "GA", "OH", "NY", "FDA_DEBARMENT", "FDA_INVESTIGATORS" ], "monitorMode": false, "maxRecordsPerRun": 0 } ``` # API You can run this Actor programmatically using our API. Below are code examples in JavaScript, Python, and CLI, as well as the OpenAPI specification and MCP server setup. ## JavaScript example ```javascript import { ApifyClient } from 'apify-client'; // Initialize the ApifyClient with your Apify API token // Replace the '' with your token const client = new ApifyClient({ token: '', }); // Prepare Actor input const input = {}; // Run the Actor and wait for it to finish const run = await client.actor("mooseandraven/healthcare-exclusion-suite").call(input); // Fetch and print Actor results from the run's dataset (if any) console.log('Results from dataset'); console.log(`💾 Check your data here: https://console.apify.com/storage/datasets/${run.defaultDatasetId}`); const { items } = await client.dataset(run.defaultDatasetId).listItems(); items.forEach((item) => { console.dir(item); }); // 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/js/docs ``` ## Python example ```python from apify_client import ApifyClient # Initialize the ApifyClient with your Apify API token # Replace '' with your token. client = ApifyClient("") # Prepare the Actor input run_input = {} # Run the Actor and wait for it to finish run = client.actor("mooseandraven/healthcare-exclusion-suite").call(run_input=run_input) # Fetch and print Actor results from the run's dataset (if there are any) print("💾 Check your data here: https://console.apify.com/storage/datasets/" + run["defaultDatasetId"]) for item in client.dataset(run["defaultDatasetId"]).iterate_items(): print(item) # 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start ``` ## CLI example ```bash echo '{}' | apify call mooseandraven/healthcare-exclusion-suite --silent --output-dataset ``` ## MCP server setup ```json { "mcpServers": { "apify": { "command": "npx", "args": [ "mcp-remote", "https://mcp.apify.com/?tools=mooseandraven/healthcare-exclusion-suite", "--header", "Authorization: Bearer " ] } } } ``` ## OpenAPI specification ```json { "openapi": "3.0.1", "info": { "title": "Healthcare Exclusion Screening - No API Key Required", "description": "No API key required - screen names against the federal LEIE, 4 state Medicaid exclusion lists, and FDA debarment/investigator lists for healthcare compliance.", "version": "0.1", "x-build-id": "ff8hadfCdkf8pDd5O" }, "servers": [ { "url": "https://api.apify.com/v2" } ], "paths": { "/acts/mooseandraven~healthcare-exclusion-suite/run-sync-get-dataset-items": { "post": { "operationId": "run-sync-get-dataset-items-mooseandraven-healthcare-exclusion-suite", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for its completion, and returns Actor's dataset items in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } }, "/acts/mooseandraven~healthcare-exclusion-suite/runs": { "post": { "operationId": "runs-sync-mooseandraven-healthcare-exclusion-suite", "x-openai-isConsequential": false, "summary": "Executes an Actor and returns information about the initiated run in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK", "content": { "application/json": { "schema": { "$ref": "#/components/schemas/runsResponseSchema" } } } } } } }, "/acts/mooseandraven~healthcare-exclusion-suite/run-sync": { "post": { "operationId": "run-sync-mooseandraven-healthcare-exclusion-suite", "x-openai-isConsequential": false, "summary": "Executes an Actor, waits for completion, and returns the OUTPUT from Key-value store in response.", "tags": [ "Run Actor" ], "requestBody": { "required": true, "content": { "application/json": { "schema": { "$ref": "#/components/schemas/inputSchema" } } } }, "parameters": [ { "name": "token", "in": "query", "required": true, "schema": { "type": "string" }, "description": "Enter your Apify token here" } ], "responses": { "200": { "description": "OK" } } } } }, "components": { "schemas": { "inputSchema": { "type": "object", "properties": { "names": { "title": "Names to screen", "type": "array", "description": "Individual or business names to screen against the selected exclusion sources (substring match, diacritic-folded, tolerant of \"Last, First\" vs \"First Last\" order — a deliberately simple screen, not a fuzzy-matching compliance engine; see README). Leave empty to just fetch/monitor the selected sources without screening a specific list of names — in that case, with the default sources left untouched, this actor pulls only the current LEIE monthly supplement (a cheap, real, non-empty default) rather than all 7 full sources, to stay fast and cheap with zero configuration. Provide names for a real, exhaustive screen across ALL selected sources.", "default": [], "items": { "type": "string" } }, "sources": { "title": "Exclusion sources to include", "type": "array", "description": "Which sources to pull this run. LEIE = federal HHS-OIG List of Excluded Individuals/Entities. CA/GA/OH/NY = state Medicaid exclusion lists (only these 4 states are included — Illinois and Texas were evaluated and excluded: Illinois's data source turned out to be a bot-hostile portal with no real bulk file, Texas is Akamai-blocked). FDA_DEBARMENT = FDA drug-application debarment list. FDA_INVESTIGATORS = FDA disqualified/restricted clinical investigators. This is NOT a legally-mandated \"screen all 50 states\" product — see README for the honest scope and mandate framing.", "items": { "type": "string", "enum": [ "LEIE", "CA", "GA", "OH", "NY", "FDA_DEBARMENT", "FDA_INVESTIGATORS" ] }, "default": [ "LEIE", "CA", "GA", "OH", "NY", "FDA_DEBARMENT", "FDA_INVESTIGATORS" ] }, "monitorMode": { "title": "Incremental monitor mode", "type": "boolean", "description": "When on, remembers what's already been seen (via Apify's key-value store) and emits a separate `new-listing` record for anything not seen on a prior run — designed for scheduled runs watching for newly-added exclusions. Also switches LEIE's fetch to the monthly supplement file (new additions only) instead of the full historical file when no names are being screened, since \"what's new\" is the natural monitoring question. Charges one `monitor-run` PPE event in addition to per-record events.", "default": false }, "maxRecordsPerRun": { "title": "Max records per source (quota guard)", "minimum": 0, "type": "integer", "description": "Safety cap on matched records delivered per source, applied INDEPENDENTLY to each source (not shared — a shared budget would let one large source starve a smaller one while the run still reports success). Set to 0 for no cap (default for a real screen — screening should be exhaustive). The bare zero-input default path (no names, default sources) is internally capped at 500 regardless of this setting, to guarantee Apify's own daily auto-test run stays fast and cheap.", "default": 0 } } }, "runsResponseSchema": { "type": "object", "properties": { "data": { "type": "object", "properties": { "id": { "type": "string" }, "actId": { "type": "string" }, "userId": { "type": "string" }, "startedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "finishedAt": { "type": "string", "format": "date-time", "example": "2025-01-08T00:00:00.000Z" }, "status": { "type": "string", "example": "READY" }, "meta": { "type": "object", "properties": { "origin": { "type": "string", "example": "API" }, "userAgent": { "type": "string" } } }, "stats": { "type": "object", "properties": { "inputBodyLen": { "type": "integer", "example": 2000 }, "rebootCount": { "type": "integer", "example": 0 }, "restartCount": { "type": "integer", "example": 0 }, "resurrectCount": { "type": "integer", "example": 0 }, "computeUnits": { "type": "integer", "example": 0 } } }, "options": { "type": "object", "properties": { "build": { "type": "string", "example": "latest" }, "timeoutSecs": { "type": "integer", "example": 300 }, "memoryMbytes": { "type": "integer", "example": 1024 }, "diskMbytes": { "type": "integer", "example": 2048 } } }, "buildId": { "type": "string" }, "defaultKeyValueStoreId": { "type": "string" }, "defaultDatasetId": { "type": "string" }, "defaultRequestQueueId": { "type": "string" }, "buildNumber": { "type": "string", "example": "1.0.0" }, "containerUrl": { "type": "string" }, "usage": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "integer", "example": 1 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } }, "usageTotalUsd": { "type": "number", "example": 0.00005 }, "usageUsd": { "type": "object", "properties": { "ACTOR_COMPUTE_UNITS": { "type": "integer", "example": 0 }, "DATASET_READS": { "type": "integer", "example": 0 }, "DATASET_WRITES": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_READS": { "type": "integer", "example": 0 }, "KEY_VALUE_STORE_WRITES": { "type": "number", "example": 0.00005 }, "KEY_VALUE_STORE_LISTS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_READS": { "type": "integer", "example": 0 }, "REQUEST_QUEUE_WRITES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_INTERNAL_GBYTES": { "type": "integer", "example": 0 }, "DATA_TRANSFER_EXTERNAL_GBYTES": { "type": "integer", "example": 0 }, "PROXY_RESIDENTIAL_TRANSFER_GBYTES": { "type": "integer", "example": 0 }, "PROXY_SERPS": { "type": "integer", "example": 0 } } } } } } } } } } ```