OIG Exclusion Check Automation

Check any provider against the OIG List of Excluded Individuals and Entities (LEIE), with structured results and screenshot evidence for your audit file. One check per run, on the official federal source, no login required.

Go-live in as little as 30 min·Browser agent·Public source

Overview

What this workflow does

A browser agent runs the search a credentialing coordinator runs today: it opens the OIG’s official online searchable database, enters the provider’s name, reads the results, and returns a clear status: found, not_found, or multiple_matches. A not_found run is a successful clean check, not a failure.

You provide a first and last name. NPI, date of birth, and specialty are optional, and are used to qualify which match likely corresponds when common names return several records.

How Asteroid runs this workflow

A roster in, a defensible LEIE screening record per provider out

A roster or single-provider request arrives, Asteroid searches the OIG LEIE, classifies the result, and files the evidence back to your screening status, and a possible match routes to a person for identity confirmation, because the agent never clears an ambiguous result on its own.

OIG LEIE database

How it actually runs

1. 01 The agent opens the OIG LEIE online searchable database. It is a public federal site, so there is no portal credential to manage.
2. 02 It searches the provider by last and first name, handling the site’s own input restrictions.
3. 03 It reads the results and classifies them: no records, one match, or multiple matches.
4. 04 For every match, it opens the detail record and extracts the exclusion type (the statute citation, for example 1128(a)(1)), the exclusion date, reinstatement date if any, and the listed city and state.
5. 05 It captures a screenshot of the results page as audit evidence, timestamps the check in UTC, and returns everything as one structured record.

Each check returns: the status, the match count and details, the echo of exactly what was searched, the evidence screenshot, and when the check ran. That record is your answer to an auditor’s “show me the screening for this provider, on this date.”

A provider roster or single-provider screening request is ready

1. Open OIG LEIE
2. Search names and aliases
3. Assess possible matches
4. Retrieve exclusion detail
5. Record evidence
6. Delivered to your screening status

The clear or possible-match result lands with its exclusion detail, evidence screenshot, and UTC timestamp: the per-provider record an auditor asks for, feeding the monthly pass.

Possible match needs identity confirmation: All matching records return with exclusion type, dates, and the screenshot attached; a person confirms identity once. Per OIG guidance, a name match is never treated as a confirmed exclusion.

Closing the loop

What lands back in your system

Nobody on your team reads this JSON. Your system does. Each run delivers its record wherever the work already lives, and the loop closes on its own: requests in, records back, no one in the middle.

structured output · jsonagent running…

▸ run triggered · request received from your system
▸ agent working the source…  
✓ run complete · record delivered back

{
  "source": "OIG LEIE",
  "status": "found",
  "checked_at": "2026-07-16T14:02:11Z",
  "result": {
    "excluded": true,
    "match_count": 1,
    "matches": [
      {
        "name": "SAMPLE, JOHN A",
        "npi": "1•••••••21",
        "exclusion_type": "1128(a)(1)",
        "exclusion_date": "2019-08-20",
        "reinstatement_date": null,
        "address": {
          "city": "DALLAS",
          "state": "TX"
        }
      }
    ]
  },
  "evidence_screenshot_url": "https://…/evidence/run_8f3a….png"
}

The check can say “match found.” Only you can say “excluded.”

OIG’s own guidance is that a name match is not a confirmed identity: confirming that a listed exclusion is actually your provider requires SSN verification, which a search cannot do. This workflow reports matches faithfully and never claims confirmed identity. An exclusion tool that turns a name search into a definitive “excluded” verdict is overclaiming, and that overclaim becomes your compliance problem, not the vendor’s.

When a match or multiple matches come back, the record routes to a person with the full detail attached. Identity confirmation stays a human decision, made once, with evidence, instead of a re-search.

At scale

One check, or a monthly screening program

Exclusion screening has tightened to a monthly cadence for many practices, and a state audit catching a manual gap is a common reason teams look for automation in the first place. This check is a single-purpose primitive built to run in bulk: a CSV of your roster in, one structured record per provider out, exceptions queued for review.

It composes with the SAM.gov federal exclusion check and the state Medicaid exclusion check for full screening coverage. Full-list screening is part of the credentialing and verification workflow library, alongside license verification and NPI checks.

Human in the loop

What escalates to a human

Screening runs execute on HIPAA-compliant, SOC 2 Type II infrastructure, and every check leaves a timestamped record of what was searched and what came back, which is the artifact a state auditor actually asks for.

Multiple matches on a common name.

All matches are reported with detail; a person confirms identity.

A found result.

Exclusion is a hiring and billing decision. The agent delivers the evidence; it never makes the call.

Site errors or downtime.

The run returns an explicit error status rather than a silent pass. A screening program never records a check that didn’t happen.

Frequently asked questions

Our screening SOP is not identical to this template. What actually changes?

The check is configured around your SOP, not the other way round. You choose which inputs you send (first and last name required; NPI, date of birth, and specialty optional), which fields come back in the structured record, the output format, where results land, and which statuses (found or multiple_matches, typically) pause for a reviewer. Your coordinators keep working from their existing queue; the LEIE search itself, the evidence screenshot, and the UTC timestamp are unchanged. Configuration sits with Asteroid, not your operations team.

What systems or credentials do we need before OIG checks can run?

None on the source side. The OIG LEIE online searchable database is a public federal site, so there is no portal login to manage. On your side, inputs arrive however you already work (a CSV of your roster, rows from your credentialing system, or an API call), and each structured record returns the same way. A direct API integration is optional, never a prerequisite. Any delivery access you grant stays least-privilege and revocable, with credential handling covered on the security page.

What happens when a name search goes sideways or the LEIE site is down?

The run stops and says why. Site errors or downtime end in an explicit error status, never a silent pass. A screening program never records a check that did not happen, and a failed run is retried before it is reported.

How do we audit what was actually searched, and who approves findings?

Every run returns one structured record: the status, the match detail, an echo of exactly what was searched, a UTC checked_at timestamp, and a screenshot of the LEIE results page.

Is a not-found result enough to treat a provider as clear, and how are aliases or possible matches handled?

A not_found run proves the provider did not appear on the LEIE at the timestamp of the check, with a screenshot to show for it, but full screening also covers SAM.gov and your state Medicaid list, which are separate sources.

Can this run on a roster-wide schedule and retain evidence for every screening cycle?

Yes. The check is a single-purpose primitive built to run in bulk: a CSV of your roster in, one structured record per provider out, exceptions queued for review. Monthly is the cadence many practices hold themselves to, aligned with the LEIE's monthly updates.