Exclusion Screening Integration: OIG LEIE, SAM.gov and Medicaid Checks (2026)

Updated October 2026

Exclusion screening checks whether a person or company is barred from US federal healthcare programs, using the OIG List of Excluded Individuals and Entities (LEIE), the SAM.gov exclusions list and state Medicaid exclusion lists. An exclusion screening integration builds those checks into your own software, so every new hire, provider or vendor is checked before they start and again every month, with possible matches sent to a person and every result kept for audit.

This guide is for the teams that build or buy that integration: healthcare staffing and HR platforms, credentialing software, background screening companies, payers and health plans, pharmacies, home health agencies and health systems. It covers every data source, how to load and search each one, how to match names without false alarms, monthly monitoring, the audit record, the rules behind it and how we built a screening service that checks LEIE, SAM.gov, a state Medicaid list and OFAC in parallel.

If you want this built into your platform, our healthcare compliance software team can scope it with you. The rest of this guide shows how the integration works so you can plan it either way.

What exclusion screening is and why healthcare requires it

The HHS Office of Inspector General (OIG) can exclude people and companies from Medicare, Medicaid and other federal healthcare programs, usually after fraud, patient abuse, certain convictions or loss of a licence. Federal programs will not pay for items or services an excluded person provides, orders or prescribes, directly or indirectly.

That rule reaches the employer. OIG's 2013 Special Advisory Bulletin on the Effect of Exclusion says a provider that employs or contracts with someone it knows or should know is excluded can face civil money penalties for each item or service involved, plus up to three times the amount claimed, and can itself be excluded. Using a screening vendor does not move that liability away from the provider. The bulletin recommends checking the LEIE monthly.

For Medicaid, 42 CFR 455.436 requires state Medicaid agencies to check providers against the LEIE and SAM.gov (which replaced the older EPLS list) no less than monthly, and to check other databases such as NPPES when providers enroll. Many states and Medicaid managed care plans write the same monthly checks, plus the state's own exclusion list, into provider contracts and ask for attestations.

In practice that makes exclusion screening a monthly job for anyone who bills or works for a federal healthcare program, and a feature buyers expect in HR, staffing, credentialing and vendor management software.

Who needs an exclusion screening integration

The data sources, one by one

OIG LEIE

The LEIE is the list that matters most in healthcare. OIG publishes it three ways:

• The full database file. A CSV with every exclusion currently in effect. OIG replaces it each month with the newest version and recommends using it for complete data.
• Monthly supplement files. Only that month's new exclusions and reinstatements. OIG says not to rely on them alone, and keeps only the last 12 months.
• Online search. For one-off lookups. When a name matches, the online search lets you verify the match by entering the person's SSN or the company's EIN. The downloadable file does not include SSNs.

For an integration, download the full file every month and replace your local copy. Do not build deltas from the supplements. When OIG reinstates someone, the person simply disappears from the full file, and a delta approach can miss that.

The LEIE file has one row per exclusion. These are the columns an integration uses:

Many older records have no NPI, so name and date of birth carry most matches.

SAM.gov exclusions

SAM.gov, run by the General Services Administration, holds exclusions from across the federal government, including debarments and suspensions. Healthcare organizations check it alongside the LEIE.

• Exclusions API. You request a public API key from your SAM.gov account. The API takes name fields, and an SSN or TIN when paired with a name, plus address details. It returns matching records with exclusion type, classification, active date, termination date and the excluding agency.
• Rate limits. Daily request limits depend on your account type. Going over returns HTTP 429. Plan a local daily quota and backoff.
• No date of birth. SAM.gov does not take date of birth, so disambiguation leans on SSN or TIN and address.
• Active and terminated. A record whose exclusion has ended is history, not a current bar. Show it differently from an active exclusion.
• Keys expire. Plan to rotate the API key on a schedule and alert before it expires, or every check quietly starts failing.
• Terms of use. Read SAM.gov's terms for your use case, especially if you resell screening as a commercial service.

A simplified example of a person search and one record from the answer, trimmed to the fields an integration reads (synthetic values; the field names are the ones our integration parses, and SAM.gov's documentation is the reference for the full layout):

GET https://api.sam.gov/entity-information/v4/exclusions
    ?api_key=YOUR_KEY
    &firstName=JANE&lastName=DOE
    &ssnOrTinOrEin=XXXXXXXXX

One record in the response (trimmed):
{
  "exclusionDetails": {
    "classificationType": "Individual",
    "exclusionType": "Ineligible (Proceedings Completed)",
    "exclusionProgram": "Reciprocal",
    "excludingAgencyName": "HHS"
  },
  "exclusionIdentification": { "firstName": "JANE", "lastName": "DOE" },
  "exclusionActions": { "activeDate": "2024-03-11", "terminationDate": null }
}

The response also carries a total record count and pages of up to 10 records. Read every page.

Map the answer to three outcomes: no records (clear for SAM.gov), at least one record still active (flag for review), or only records whose termination date has passed (clear with history).

State Medicaid exclusion lists

There is no single national list of state Medicaid exclusions. Many states publish their own list of terminated or excluded providers, each with its own format, fields and update rhythm. A provider excluded by one state's Medicaid program may not appear on the LEIE yet.

For an integration, treat each state as its own source with its own loader. Pick the states that match where your customers operate and where their workers live and have worked. New York's Office of the Medicaid Inspector General (OMIG) is a good example: it publishes a full exclusion file as tab-separated text and a separate short list of exclusions from the last 30 days, which helps catch new additions between full loads.

Record per state where the file comes from, how often it changes, the date format and which identifiers it has. That sheet becomes the source of truth for coverage questions from customers.

OFAC sanctions list

OFAC's Specially Designated Nationals (SDN) list is not a healthcare exclusion list, but many screening packages include it because the same platform screens people for many reasons. It publishes often and has aliases, so match on aliases as well as primary names.

NPPES (NPI registry)

NPPES is not an exclusion list. It confirms that an NPI exists, belongs to the person you think it does and has not been deactivated. Use it to validate NPIs before you match on them, and as an enrollment check.

Build, buy or integrate: your options

The public sources for LEIE, SAM.gov and OFAC are free. The cost of building is engineering and operations: keeping data fresh, getting matching right and proving it to auditors.

Architecture of an exclusion screening integration

Loading bulk files safely

1. Download on a schedule that matches the source: monthly for LEIE, monthly plus a daily short list for states that offer one, daily for OFAC.
2. Load into a staging table, parsing each row and normalizing names and dates. Formats differ: LEIE dates are YYYYMMDD, New York OMIG uses MM/DD/YYYY.
3. Check the size before switching. If the new file has far fewer rows than the last one, for example less than half, stop and alert. A truncated download should never replace good data.
4. Swap staging into place in one step, then rebuild indexes, so searches never see a half-loaded list.
5. Record the load: source, file date, row count, load time. Every screening result points back to this record.
6. Watch freshness. A separate daily check alerts when a source has not loaded within its window. Failures alert on their own, but a stopped scheduler fails silently, and only a freshness check catches it.

Calling SAM.gov safely

• Run the call in a background job, never inside the user's request.
• Validate input first: SAM.gov needs a name, and SSN or TIN must be sent with a name.
• Retry network errors and 429 responses with growing waits, then mark the check as needing attention instead of guessing.
• Keep a local daily counter below your quota, and queue the rest for the next day.
• Log each call with timing and status, without logging SSNs.
• Check the API key's health daily with a harmless test query, and alert before it expires.

Matching names without drowning in false alarms

Exclusion lists hold common names, and many records have no NPI. A system that flags every "John Smith" teaches reviewers to click past alerts, which is worse than no system. Match in tiers, strongest first.

Normalizing names

• Upper-case, trim spaces and remove punctuation, so "O'Brien" and "OBRIEN" compare.
• Store first, middle and last names separately, plus a combined form.
• Keep every name the person has used. Maiden names and aliases from a background check or the person's own form matter, because the list may hold an older name.
• For businesses, strip suffixes such as LLC and INC before comparing, and keep the original.

Matching logic in code

A simplified version of the tiered search against a local list, the way we structure it:

function screenPerson(p, list) {
  const name = normalize(p.firstName + " " + p.lastName);
  const hits = [];
  if (p.npi)  hits.push(...list.byNpi(p.npi).map(r => ({ r, tier: "NPI" })));
  if (p.dob)  hits.push(...list.byNameAndDob(name, p.dob).map(r => ({ r, tier: "NAME_DOB" })));
  hits.push(...list.byExactName(name).map(r => ({ r, tier: "NAME" })));
  hits.push(...list.byLastNameAndFirstPrefix(
      normalize(p.lastName), normalize(p.firstName).slice(0, 3)
    ).map(r => ({ r, tier: "PARTIAL" })));
  for (const alias of p.otherNames || []) { /* repeat the name tiers for each alias */ }
  const unique = dedupeByRecordId(hits);            // keep the strongest tier per record
  return unique.length === 0
    ? { status: "CLEAR", matches: [] }
    : { status: "FLAGGED", matches: unique };      // a person verifies every flag
}

Edge cases to plan for

• Name changes. Screen every name the person has used. Exclusions often sit under an earlier name.
• Waivers. An LEIE record with a waiver may allow work in one state. Do not auto-clear or auto-reject; route to review.
• Owners and managing employees. For vendors and agencies, screen the business name and the people who own or manage it.
• Reinstatement. A person reinstated by OIG leaves the full file. Keep your past results; they were true when made.
• Ended SAM.gov exclusions. Show them as history with dates, so a reviewer can judge.
• Missing data. No date of birth means no tier-2 matches. Show the reviewer which identifiers were available.
• Duplicates across sources. The same person can appear on LEIE, SAM.gov and a state list. Group matches per person so the reviewer decides once with all evidence.

Verifying a possible match

• LEIE: use the OIG online search's verify step with the person's SSN or the entity's EIN.
• SAM.gov: search with the SSN or TIN paired with the name, and compare address and dates.
• State lists: compare licence number, NPI and provider type, or contact the state.
• Record who verified, what they compared and the outcome: confirmed or false match. Save the evidence.

Never take an employment action on an unverified name match. If you are a background screening company reporting to an employer, the Fair Credit Reporting Act also requires reasonable procedures for accuracy and gives the person a chance to dispute.

The screening workflow, step by step

1. Request. Your platform asks for a check with name, other names, date of birth, NPI, SSN (where allowed) and address. The order is created at once with a pending status.
2. Validate. The job checks required fields per source. A source that cannot run because of missing data is marked as such, not silently skipped.
3. Search in parallel. Local lists (LEIE, state lists, OFAC) and the SAM.gov API run at the same time. One source failing must not stop the others; the result shows which sources ran.
4. Decide. No match anywhere: clear. Any strong or possible match: send to review with the evidence. A source that failed: needs attention, then retry.
5. Review. A trained person verifies and records the decision.
6. Record. Save the source, the file date or API response time, the input, the matches and the decision.

Result statuses that work in practice

Monthly monitoring

A clean check at hire proves nothing about next month. Monitoring re-runs the check for every active person on a fixed cycle, usually every 30 days, against the newest data.

• Who: everyone currently working, contracted, credentialed or paid. Stop monitoring people who left, and record when.
• When: run daily and pick up each person whose last check is older than 30 days, so the load spreads across the month.
• What changes: new exclusions (a person was clear and now matches), reinstatements (a person drops off a list) and data updates (a new state file, a new SAM.gov record).
• Alerts: a new match on a current worker goes to compliance at once, with the evidence.
• Proof: a monthly report per customer listing who was screened, against which source versions, and the outcomes. This is what auditors and health plans ask for.

The audit record

When a regulator or a health plan asks "did you screen this person in March?", the answer has to come from data, not memory. Store for every check:

• The person screened and the identifiers used (with SSNs encrypted or masked).
• Each source checked, with the file date and load ID for bulk sources, or the request time and status for SAM.gov.
• Every match returned, its tier and the matched record's details.
• The reviewer, the decision, the reason and the time.
• Any source that did not run, and why.

A simple data model

How we built an exclusion screening service

We built exclusion screening into a background screening platform used by healthcare and other employers. It replaced a paid data vendor for these checks with the free public sources. The client is not named; the healthcare staffing screening case study describes the wider platform. Here is what the screening service does and what we learned.

• Four sources in parallel. OIG LEIE, SAM.gov, New York OMIG and OFAC run side by side for each person. Each source is a separate search that returns the same result shape, and one source failing does not stop the others.
• Bulk lists loaded locally. LEIE loads on the 15th of each month, after OIG publishes. OMIG loads monthly, and its 30-day short list loads daily to catch new exclusions sooner. OFAC loads daily. Each load goes into a staging collection and swaps in only if the new file has at least half the rows of the old one.
• SAM.gov through the live API with retries and growing waits on rate limits, a local daily quota, input checks before any call, and statuses for active, terminated-only and needs-attention results.
• Key health check. A daily job sends a harmless query to SAM.gov and alerts when the key is failing. It also alerts at 75, 85 and 89 days after the key was rotated, because in our setup keys had to be rotated every 90 days.
• Freshness canary. A daily check alerts if OFAC has not loaded in 48 hours, or LEIE or OMIG in 40 days, or if a source has never loaded at all.
• Match tiers without fuzzy matching. NPI exact, then name plus date of birth, then exact name, then last name plus first-name prefix. We started without fuzzy or sound-alike matching on purpose, so every flag is explainable to a reviewer.
• Background job per order. The order is created at once and the screening runs in a worker, so a slow SAM.gov response never blocks the user. Running the same job twice has no effect.
• Monitoring every 30 days for active people, run daily so the load spreads out, skipping people whose last activity is long past.

What we learned

• Silent staleness is the biggest risk. Sync jobs alerted on failure, but a stopped worker produced no failure at all. The freshness canary is what closes that gap.
• Full replace beats deltas for LEIE. Reinstated people vanish from the file; only a full replace removes them reliably.
• Guard against bad files. A half-downloaded file looks like a valid file with fewer rows. The row-count guard keeps the old data until a good file arrives.
• Expired keys fail quietly. When the SAM.gov key expired, the source would simply fail while the rest of the order completed. The daily key check turns that into an alert.
• Explainable matches win reviewer trust. Reviewers act faster when each flag says exactly which fields matched.

Compliance checklist

Testing checklist before go-live

• A known excluded test record from the current LEIE file matches on name and date of birth.
• A person with a common name and a different date of birth is not flagged as strong.
• A reinstated record from last month's file no longer matches after this month's load.
• A truncated test file is refused by the row-count guard and the old data stays.
• A SAM.gov 429 response leads to retries, then needs attention, never a false clear.
• A failed source shows as not run in the result, and the other sources still complete.
• A terminated SAM.gov record shows as history, not as an active exclusion.
• Monitoring picks up a person whose last check is 31 days old.
• The freshness canary alerts when a source's last load is past its window.
• Logs contain no SSNs or full dates of birth.

What to monitor once it is live

What drives the effort

How Nirmitee helps

We build exclusion screening into healthcare platforms: LEIE and state list loaders with freshness checks, SAM.gov API integration with quota and key monitoring, tiered matching with a review queue, monthly monitoring and the audit record, connected to your HR, staffing, credentialing or screening product. See our healthcare compliance software and healthcare integration services, and for related work read our Labcorp API and drug testing integration guide.