# OIG LEIE & SAM Exclusion Screening API: 49 Official Lists (`friendlyapi/healthcare-exclusion-screening`) Actor

Screen employees, providers and vendors against the federal OIG LEIE, SAM.gov exclusions, and state Medicaid exclusion lists, with match scores, provenance and list freshness. Built for the OIG-mandated monthly re-screening cycle.

- **URL**: https://apify.com/friendlyapi/healthcare-exclusion-screening.md
- **Developed by:** [FriendlyAPI](https://apify.com/friendlyapi) (community)
- **Categories:** Business, Developer tools, MCP servers
- **Stats:** 2 total users, 1 monthly users, 100.0% runs succeeded, 0 bookmarks
- **User rating**: No ratings yet

## Pricing

from $60.00 / 1,000 party screeneds

This Actor is paid per event. You are not charged for the Apify platform usage, but only a fixed price for specific events.
Since this Actor supports Apify Store discounts, the price gets lower the higher subscription plan you have.

Learn more: https://docs.apify.com/platform/actors/running/actors-in-store#pay-per-event

## What's an Apify Actor?

Actors are web data automations that power AI and operations. They run on the Apify platform to scrape websites, process data, connect APIs, and automate workflows.
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.

- **AI agents and MCP clients** — the [Apify MCP server](https://docs.apify.com/integrations/mcp.md) at `https://mcp.apify.com` (remote, streamable HTTP, OAuth on first use).
- **Agentic workflows and local Actor development** — [Agent Skills](https://apify.com/.well-known/agent-skills/index.json) with the [Apify CLI](https://docs.apify.com/cli/docs.md): `npm install -g apify-cli`, then `apify login`.
- **JavaScript/TypeScript projects** — the official [JS/TS client](https://docs.apify.com/api/client/js/docs.md): `npm install apify-client`.
- **Python projects** — the official [Python client](https://docs.apify.com/api/client/python/docs.md): `pip install apify-client`.
- **Any other language** — 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

## OIG LEIE & SAM Exclusion Screening API: 49 official US lists in one call

Screen employees, providers, contractors and vendors against **the federal
exclusion lists and the state Medicaid exclusion lists in one call**, with
match scores, per-list provenance, and a public freshness ledger you can audit
before you trust us.

**Why this exists:** HHS-OIG guidance directs healthcare employers to screen
staff and vendors against the exclusion lists **at hire and monthly thereafter**.
Employing or contracting with an excluded party can trigger Civil Monetary
Penalties. The federal LEIE is the easy part, and every vendor does it. The states
are the hard part: each publishes its own list, on its own schedule, in its own
format, at a URL that keeps moving. Most teams either pay enterprise prices or
click through forty-odd state websites by hand every month.

### What is in the dataset

| Source | Records | Refresh |
|---|---:|---|
| **OIG LEIE** (federal List of Excluded Individuals/Entities) | ~83,700 | monthly, on OIG's cycle |
| **SAM.gov Exclusions** (federal procurement/debarment) | ~168,000 | daily full snapshot |
| **State Medicaid exclusion lists** | tens of thousands | per state, weekly to yearly |

Every response carries the as-of date of every list consulted. The `lists` mode
publishes the same ledger for free, **including what we do *not* cover**.

### Coverage, stated honestly

Call `lists` for the live map. It answers the question that actually matters,
*what did you not check?*, in three parts:

- **Automated**: ingested, with per-source freshness dates.
- **Manual**: the state publishes a list we cannot yet fetch automatically
  (a form-POST portal or a bot wall). We name the state and give you its
  official URL rather than pretending it isn't there.
- **Publishes no list**: 7 states, DC and all 5 territories publish no
  Medicaid exclusion list at all, each verified individually against the
  official source. For those jurisdictions **LEIE + SAM.gov IS the complete
  screening surface**. that is a finding, not a gap.

We would rather show you a named gap than an inflated number.

### Modes

| Mode | What it does | Billing |
|---|---|---|
| `search` | Screen one person (`last_name`/`first_name`, optional `npi`) or one entity (`business_name`) | 1 screening event |
| `screen_roster` | Batch-screen a roster; returns per-party hits | 1 event per party |
| `lists` | Dataset freshness and coverage map | **free** |

**Thresholds differ by mode, deliberately.** `search` defaults to `min_score`
0.6 (wider, for a human reviewing one party); `screen_roster` defaults to 0.75
(tighter, so a large roster is not buried in near-misses). Set `min_score`
explicitly on either if you want them to agree.

### The monthly re-screen, in one field

Pass a stable `monitor_id` (e.g. `"main-staff"`) with `screen_roster`, and give
every party your own stable `id`. Each run then compares against the previous
run for that roster and tags each party `new_or_changed_hit`, `cleared`,
`unchanged`, or `no_baseline` on the first run. Schedule it monthly and you get
**only what changed**.

Both fields are required for change tracking, and the reason is worth stating:
`cleared` is a claim that someone came **off** a list. Without a stable
`monitor_id` two different rosters would share one baseline; without your own
party `id`, reordering the roster would attribute one person's exclusion to
another. We refuse rather than guess.

For the same reason the API **suppresses** `cleared` and reports
`unverified_this_run` instead whenever the comparison is not like-for-like,
if you changed `min_score` between runs, or if a source failed out of that
day's build. A party disappearing because a state website was down is not a
party who was cleared, and `comparison_note` in the summary says which it was.

### Match quality: scored candidates, never a bare yes/no

- `npi_exact` (1.0): NPI match, the strongest signal
- `exact_name` (1.0): normalized name match (suffixes, punctuation, case folded)
- `last_exact_first_initial` (0.9), and tiered partials
- `fuzzy` (0.6 to 0.9): edit-distance candidates, with phonetic recall so
  common misspellings still surface (SMYTH/SMITH, JONSON/JOHNSON). Review
  the score: a fuzzy hit is a candidate for a human to judge, not a finding.

Two design decisions worth knowing:

1. **A party on several lists comes back once per list, with provenance.**
   We do not collapse them into one anonymous "hit". *Which* list someone is on
   is the compliance answer, and a state exclusion is not a federal one.
2. **Most LEIE individuals carry NPI `0000000000`.** Anyone promising you clean
   NPI joins has not read the data. Name-and-date matching is the real work, so
   results are candidates with scores and provenance for human review.

Compliance decisions need a human. This API is engineered so the right
candidates are in front of that human, each saying which list it came from,
which version, and why it matched.

### Typical uses

- Credentialing and HR onboarding checks inside your own product
- The monthly re-screen, scheduled, reporting only changes
- Vendor and contractor due diligence before signature

### What this is NOT: read before you integrate

**Not a background-check service.** The Provider is not a consumer reporting
agency and nothing here is a consumer report under the FCRA or any state
analogue. **You may not use this Service as a factor in deciding about a
person**: hiring, firing, promotion, credit, insurance, housing or benefits.

That sounds like it contradicts the use case, so here is the line precisely:
use this to *find* the candidates that need looking at, then verify each one
against the official source it names and make your decision on that verified
record. A hit here is a pointer to a government publication, never a finding
about a person.

### Honest limits

Not legal advice. Not a substitute for primary-source verification where a match is acted
upon. Every match names the list it came from (`source_id`), and the free
`lists` mode gives that list's official URL and as-of date, so any hit can
be checked against the government source it came from.
Where a state is listed as manual, we have not checked it for you; its official
URL is in the source row.

Methodology: every record is built from, and checked against, the official primary source, and each source's URL and as-of date are published so you can verify any result yourself.

**Support:** friendlyapidev@gmail.com

***

## Terms of Use

**Effective 9 August 2026.** These Terms govern this and every other data service published by the Provider. "The Provider" means the operator of the Service, reachable at **friendlyapidev@gmail.com**. "The user" means anyone who accesses the Service, paid or free. By using it you agree to them.

*§1's consumer-reporting provisions and §5's prohibition on decisions about individuals are directed principally at services that return records about named people.*

### 1. What this service is

The Service provides **structured data compiled from public government
sources**. It is an information product. It is **not** legal advice, not a
compliance determination, and not a background-check or consumer report.

Nothing in the Service constitutes a verdict about any person or entity. The
Service returns **candidate matches with confidence scores and source
provenance**, which a competent human must review before any action is taken.

**The Provider is not a consumer reporting agency**, and nothing the Service
returns is a "consumer report" or "investigative consumer report" within the
meaning of the Fair Credit Reporting Act (15 U.S.C. § 1681 et seq.) or any
state analogue. The Service is not assembled or evaluated for the purpose of
establishing a consumer's eligibility for employment, credit, insurance, or
housing, and the Provider does not follow the procedures the FCRA requires of
consumer reporting agencies. Permitted uses are set out in §5.

### 2. No warranty

THE SERVICE AND ALL DATA ARE PROVIDED "AS IS" AND "AS AVAILABLE", WITHOUT
WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING WITHOUT LIMITATION ANY
WARRANTY OF ACCURACY, COMPLETENESS, CURRENCY, MERCHANTABILITY, FITNESS FOR A
PARTICULAR PURPOSE, OR NON-INFRINGEMENT.

Specifically, and without limiting the above, the Provider does **not**
warrant that:

- the data is complete, current, or free from error;
- every relevant record has been collected, or that any particular
  jurisdiction, list, or record is included;
- a "no match" result means a person or entity is not subject to any
  exclusion, sanction, action, or legal obligation;
- source publications will remain available, unchanged in format, or on any
  particular schedule.

### 3. The data comes from third parties we do not control

All data is derived from **public government publications**. Those publishers
control what they publish, when, in what format, and whether it is accurate.
They change formats without notice, take sites offline, and publish records
containing their own errors. The Provider reproduces and normalises what those
sources publish and **does not independently verify the truth of any
underlying record**.

Each result identifies the source it came from, and the Service publishes the
as-of date and official URL of every source it carries, so any result can be
checked against the government publication it derives from.

### 4. The user's verification duty

The user is solely responsible for verifying any result against the official
primary source before relying on it or acting on it, and for obtaining
professional advice appropriate to their circumstances.

**The Service's published coverage statement is part of these Terms.** It
states which jurisdictions are collected automatically, which are published by
their source in a form the Service does not collect, and which publish nothing
at all. A user who acts on the Service without reading it does so at their own
risk.

### 5. Acceptable use

**Permitted.** Query the Service, integrate it into your own product, and
display individual results to your own users, including as part of a
compliance workflow you operate.

**Prohibited.** The user shall not:

1. **Use the Service, in whole or in part, as a factor in any decision about
   an individual's employment, engagement, retention, promotion, credit,
   insurance, housing, or eligibility for any benefit.** The Service is not a
   consumer report (§1). Screening obligations that arise from law or
   regulation must be discharged against the official primary source, and any
   decision about a person must rest on that verified source and the user's
   own judgement, not on this Service.
2. Extract, copy, or redistribute the dataset in bulk, or use it to build,
   train, or populate a competing dataset or data feed. (Querying the Service
   and showing results to your own users is expressly permitted above.)
3. Use the Service in violation of any law, or to re-identify, harass, or
   defame any individual appearing in the data.

A record in these datasets means only that a government body published it.
It is not a finding by the Provider about any person.

### 6. Limitation of liability

TO THE MAXIMUM EXTENT PERMITTED BY LAW, THE PROVIDER SHALL NOT BE LIABLE FOR
ANY INDIRECT, INCIDENTAL, SPECIAL, CONSEQUENTIAL, EXEMPLARY, OR PUNITIVE
DAMAGES, OR FOR ANY LOSS OF PROFITS, REVENUE, DATA, GOODWILL, OR BUSINESS
OPPORTUNITY, ARISING OUT OF OR RELATING TO THE SERVICE, WHETHER IN CONTRACT,
TORT (INCLUDING NEGLIGENCE), OR ANY OTHER THEORY, EVEN IF ADVISED OF THE
POSSIBILITY OF SUCH DAMAGES.

THE PROVIDER'S TOTAL AGGREGATE LIABILITY ARISING OUT OF OR RELATING TO THE
SERVICE, IN THE AGGREGATE AND FOR ALL CLAIMS COMBINED, SHALL NOT EXCEED **ONE
HUNDRED US DOLLARS (US$100)**.

The user acknowledges that this limitation is a material part of the bargain,
that the fees charged reflect it, and that the Provider would not offer the
Service on these terms without it.

Two notes on why the cap is a flat figure rather than a multiple of fees. It
is never zero. A cap of zero for a user who paid nothing invites the argument
that the clause is illusory, and a court that agrees may strike the whole
limitation rather than read it down. And it is fixed rather than computed, so
there is nothing to reconstruct from billing records years later.

Nothing in these Terms excludes or limits liability that cannot lawfully be
excluded or limited. If any part of this section is held unenforceable, the
remainder continues to apply to the fullest extent permitted.

### 7. Indemnity

The user shall indemnify and hold the Provider harmless from any claim arising
from the user's use of the Service, including any decision made in reliance on
it and any breach of §5.

### 8. Availability and changes

The Service may change, add, or remove data sources and coverage at any time,
and may be unavailable. Changes to coverage are reflected in the published
coverage statement.

### 9. Governing law

These Terms are governed by the laws of the **State of New York**, without
regard to conflict-of-laws principles. The parties submit to the **exclusive
jurisdiction of the state and federal courts located in the State of New
York**, and each waives any objection to that venue.

Disputes are resolved in court; these Terms do not require arbitration.

### Pricing

Pay per event, no subscription. Prices fall on higher Apify plans.

| Event | What triggers it | Price |
|---|---|---|
| `screening` | One person or organisation screened against all 49 lists | **$0.10** (from $0.06) |

`lists` mode, which shows every source and its freshness, is **free**. A 500
person roster is $50 to screen against 348,040 records; commercial screening
services charge that per seat per month.

### 10. Contact

**friendlyapidev@gmail.com**

Support is handled by email. There is no telephone support and no guaranteed
response time.

***

# Actor input Schema

## `mode` (type: `string`):

search = screen one party; screen\_roster = batch screen a list; lists = show dataset freshness (free)

## `last_name` (type: `string`):

Individual's last name (search mode)

## `first_name` (type: `string`):

Individual's first name (search mode)

## `business_name` (type: `string`):

Organization/entity name (search mode)

## `npi` (type: `string`):

10-digit National Provider Identifier, strongest match signal

## `min_score` (type: `number`):

0.6 (looser, review-oriented) to 1.0 (exact only). Default 0.6 for search, 0.75 for rosters. Changing it between monitored runs suppresses 'cleared' for that run, because a different threshold is not evidence that a party came off a list.

## `parties` (type: `array`):

List of parties. Give each a stable 'id' of your own: \[{"id": "emp-1", "last\_name": "...", "first\_name": "..."}, {"id": "vend-1", "business\_name": "..."}]. The id is required when monitor\_id is set, because positional ordering would attribute one person's exclusion to another if the roster is reordered.

## `monitor_id` (type: `string`):

Stable name for this roster (e.g. 'main-staff'). Required for change tracking, along with your own 'id' on every party. Runs with the same monitor\_id report what CHANGED since the previous run. Omit for a one-off screen with no change tracking.

## Actor input object example

```json
{
  "mode": "screen_roster",
  "min_score": 0.75,
  "parties": [
    {
      "id": "emp-1",
      "last_name": "Smith",
      "first_name": "John"
    },
    {
      "id": "emp-2",
      "last_name": "Garcia",
      "first_name": "Maria"
    },
    {
      "id": "vend-1",
      "business_name": "Acme Home Care"
    }
  ]
}
```

# Actor output Schema

## `results` (type: `string`):

Every screened party with its matches, ready to consume.

## `csv` (type: `string`):

For compliance officers who work in a spreadsheet.

## `runInConsole` (type: `string`):

No description

## `summaryOnly` (type: `string`):

Party, hit, match count and what changed. No nested match detail.

# 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 '<YOUR_API_TOKEN>' with your token
const client = new ApifyClient({
    token: '<YOUR_API_TOKEN>',
});

// Prepare Actor input
const input = {
    "mode": "screen_roster",
    "min_score": 0.75,
    "parties": [
        {
            "id": "emp-1",
            "last_name": "Smith",
            "first_name": "John"
        },
        {
            "id": "emp-2",
            "last_name": "Garcia",
            "first_name": "Maria"
        },
        {
            "id": "vend-1",
            "business_name": "Acme Home Care"
        }
    ]
};

// Run the Actor and wait for it to finish
const run = await client.actor("friendlyapi/healthcare-exclusion-screening").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 '<YOUR_API_TOKEN>' with your token.
client = ApifyClient("<YOUR_API_TOKEN>")

# Prepare the Actor input
run_input = {
    "mode": "screen_roster",
    "min_score": 0.75,
    "parties": [
        {
            "id": "emp-1",
            "last_name": "Smith",
            "first_name": "John",
        },
        {
            "id": "emp-2",
            "last_name": "Garcia",
            "first_name": "Maria",
        },
        {
            "id": "vend-1",
            "business_name": "Acme Home Care",
        },
    ],
}

# Run the Actor and wait for it to finish
run = client.actor("friendlyapi/healthcare-exclusion-screening").call(run_input=run_input)

# Fetch and print Actor results from the run's dataset (if there are any)
print(f"💾 Check your data here: https://console.apify.com/storage/datasets/{run.default_dataset_id}")
for item in client.dataset(run.default_dataset_id).iterate_items():
    print(item)

# 📚 Want to learn more 📖? Go to → https://docs.apify.com/api/client/python/docs/quick-start

```

## CLI example

```bash
echo '{
  "mode": "screen_roster",
  "min_score": 0.75,
  "parties": [
    {
      "id": "emp-1",
      "last_name": "Smith",
      "first_name": "John"
    },
    {
      "id": "emp-2",
      "last_name": "Garcia",
      "first_name": "Maria"
    },
    {
      "id": "vend-1",
      "business_name": "Acme Home Care"
    }
  ]
}' |
apify call friendlyapi/healthcare-exclusion-screening --silent --output-dataset

```

## MCP server setup

```json
{
    "mcpServers": {
        "apify": {
            "type": "http",
            "url": "https://mcp.apify.com/?tools=fetch-actor-details,friendlyapi/healthcare-exclusion-screening"
        }
    }
}

```

The hosted server signs you in with OAuth on first connect, so no API token belongs in this config. Clients without OAuth support can send an `Authorization: Bearer <APIFY_API_TOKEN>` header instead, using a token from API & Integrations in Apify Console (https://console.apify.com/settings/integrations).

## OpenAPI specification

Download the OpenAPI definition: https://api.apify.com/v2/actors/huXk1SxVEsQnYHrKF/builds/gU8V1lVka7hLulvXF/openapi.json