State Medicaid Exclusion Check Automation

Check a provider against a state’s own Medicaid exclusion and sanction list: found or not-found status with the sanction type and dates, an evidence screenshot, and a timestamp, as one structured record. The state layer of exclusion screening, built state by state.

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

Overview

What this workflow does

Every state maintains its own Medicaid exclusion and sanction list, and it’s a genuinely different list from the federal ones: it carries state-level actions, exclusions, for-cause terminations, disbarments, that originate with the state’s own Medicaid program. A browser agent runs the check against the state’s official search: it enters the provider’s name, reads the results, and returns the same structured screening envelope as the OIG and SAM.gov checks, so all three layers of a screening program produce records in one shape.

The workflow is built per state, Louisiana today via the Louisiana Department of Health’s State Adverse Actions List search, and cloned state by state as coverage grows. A request for a state that isn’t built yet ends with a clear scoped error naming what’s supported, never a wrong answer dressed as a right one.

How Asteroid runs this workflow

The state layer of exclusion screening, in the same record shape as the federal checks

A roster arrives for one or more state Medicaid exclusion sources, Asteroid searches each state's own list, captures any sanction finding with evidence, and returns a normalized result to your screening queue, with name-only matches and unclear source language routed to your compliance team.

How it actually runs

1. 01 The agent opens the state’s official Medicaid exclusion and sanction search. For Louisiana that’s the LDH State Adverse Actions List, a public site with no login.
2. 02 It searches by the provider’s first and last name only. It never enters a Social Security Number, and never outputs one.
3. 03 It reads the results and classifies them: no matching record is a clean not-found; one match is found; several are multiple matches, with an NPI used to disambiguate when the list displays one.
4. 04 For every match it captures the listed name, the NPI if shown, the sanction type, exclusion, for-cause termination, disbarment, and the effective and reinstatement dates in ISO format.
5. 05 It screenshots the results as audit evidence, timestamps the check, and returns one structured record.

A not-found run is a successful clean check, on record with evidence, which is the thing an auditor actually asks for.

Steps to check a provider

• A provider roster is ready for one or more state Medicaid exclusion sources
• Select state source
• Search provider
• Resolve possible match
• Capture exclusion finding
• Normalize state result
• Delivered to your screening queue

The state-specific result lands in the screening queue with its evidence and timestamp, normalized to the roster's record shape: one cadence and one queue across the OIG, SAM.gov, and state layers.

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.

Example Structured Output

{
  "source": "LDH State Adverse Actions List",
  "status": "not_found",
  "checked_at": "2026-07-16T14:02:11Z",
  "result": {
    "excluded": false,
    "match_count": 0,
    "matches": []
  },
  "evidence_screenshot_url": "https://…/evidence/run_2c91….png"
}

Your state’s list knows things the federal lists don’t

The OIG list covers federal healthcare-program exclusions and SAM.gov covers government-wide debarment, but a for-cause termination or a sanction from a state Medicaid program lives on the state’s own list, and it can sit there without a matching federal entry. That’s why screening guidance treats the state list as its own required layer rather than a redundancy. A monthly pass that runs the OIG check and the SAM.gov check but skips the state layer has a gap exactly where the most local, most recent findings appear.

Frequently asked questions

Our state screening procedure has its own rules. What gets adapted?

The check wraps your procedure rather than replacing it. Asteroid configures the inputs you send (first and last name, with NPI used to disambiguate when the state list displays one), the fields captured per match (sanction type, effective and reinstatement dates), the record format, the delivery destination, and which outcomes pause for your compliance team. Because the output uses the same screening envelope as the OIG and SAM.gov checks, your monthly pass produces one record shape across all three layers, and your reviewers keep one queue.

Does the state check need portal accounts or an integration to start?

No source credentials at all. For Louisiana the agent searches the LDH State Adverse Actions List, a public site with no login, so there is nothing to provision or rotate on the state side. Roster inputs arrive as CSVs, sheets, or API calls, and each structured record (with its evidence screenshot and timestamp) returns through whichever channel you already use. An API integration is available when you want one. Delivery access stays least-privilege and revocable.

What if a provider's state is not supported, or the search cannot resolve a name?

A request for a state that is not built yet ends with a clear scoped error naming what is supported, never a wrong answer dressed as a right one, and never a silently skipped check. Multiple matches on a common name are reported in full, with the NPI as tiebreaker when the LDH list shows one, and a person confirms identity. An unreachable site is an explicit technical error, retried before it is reported. The agent never enters or invents identity data such as an SSN.

What does the audit trail look like, and who signs off on a sanction finding?

Every run returns one structured record: found or not_found status, sanction detail (exclusion, for-cause termination, disbarment) with ISO dates, a screenshot of the state's results page, and a checked_at timestamp. A not-found run is a successful clean check on record with evidence, exactly what an auditor asks for. A found result is also a completed run: a state sanction is an employment and billing decision, so it routes to your compliance team with the state's own wording and the screenshot attached.

Which state lists are covered, and how are different source formats normalized?

Louisiana today, via the LDH State Adverse Actions List, with the workflow deliberately built to be cloned state by state as coverage grows. Whatever a state's search displays, results are normalized into the same screening envelope the OIG and SAM.gov checks use (status, match detail, sanction type, effective and reinstatement dates in ISO format), so a multi-state roster produces uniform records.

How do name-only searches handle possible matches without using SSNs?

By design the agent searches by first and last name only, and never enters or outputs a Social Security Number anywhere in the run. When the state list displays NPIs, those disambiguate common names; when several candidates remain, the run classifies them as multiple matches and returns every record with sanction type and dates for a person to resolve. Identity confirmation is a human decision made once with evidence attached. The agent reports matches faithfully and never declares that a listed sanction is your provider.