Check a prospective direct service worker against the state’s adverse-actions registry before the hire: an eligible or not-eligible answer with the finding’s detail, an evidence screenshot, and a timestamp. Louisiana’s LDH registry today, built state by state.
Overview
States that maintain a direct service worker registry require employers to check it before hiring: a listed finding, abuse, neglect, misappropriation, or another sanction, means the person is not eligible to be hired. This workflow runs that pre-hire gate as a browser agent: it searches the state’s registry by name, reads the result, and returns a clear answer with evidence.
The semantics are hiring semantics, which makes this check different from the provider screening checks in this library. A match means an adverse finding exists and the answer is not eligible. No match means eligible, and the run returns that as a populated, affirmative record, who was checked, what it means, when, not as a bare empty result. Both outcomes are normal successes; the check exists to produce exactly one of them.
Step by step
Structured output
Every run ends as a record like this in your system, not a portal screenshot someone transcribes. This is the part your team stops doing by hand.
{ "source": "LDH State Adverse Actions List", "status": "found", "checked_at": "2026-07-16T14:02:11Z", "result": { "eligible": false, "registry_status": "not_eligible", "name": "SAMPLE, MARY K", "registry_id": "•••4406", "effective_date": "2023-11-02" }, "evidence_screenshot_url": "https://…/evidence/run_b774….png"}The point of a pre-hire registry check is the sequence: the check comes first, the hire second, and the state’s mandate is written in exactly those terms. Run manually, this check competes with everything else on an onboarding checklist and sometimes loses. Run as an agent, it’s a step that can’t be skipped quietly: every candidate gets the same search, the same evidence screenshot, the same timestamped record, and a not-eligible answer arrives before the offer, when it’s a screen, instead of after, when it’s a liability.
It shares its Louisiana source with the state Medicaid exclusion check, but answers a different question: that check screens providers for billing sanctions; this one screens people for hiring eligibility.
At scale
A single run answers one candidate’s eligibility. As a program, the check runs at the front of every DSW hire and on whatever re-screening cadence your compliance posture requires, and the not-eligible findings land with your team with the state’s own record attached. The check is part of the credentialing and verification workflow library.
Human in the loop
Checks run on HIPAA-compliant, SOC 2 Type II infrastructure and log every result, so hiring-eligibility screening holds up in a state review. Details on the security page.
A finding on the registry.
Not eligible is the state’s answer, and the record with its evidence goes to your team; the hiring file shows exactly why.
Multiple same-name candidates.
Reported for a person to resolve, with date of birth as the tiebreaker when the registry shows one.
The registry being unreachable.
An explicit error, never a silently recorded clean check before a hire.
Questions
The DSW registry check is one workflow in the credentialing and verification workflow library. A finding discovered after the hire is a liability, not a screen. Screening only counts if it happens before the start date.
Disclaimer
Third-party names, including government agencies and registries, are used only to identify systems commonly involved in healthcare operations workflows. Asteroid is not affiliated with, endorsed by, sponsored by, or certified by those third parties unless expressly stated. Workflow availability depends on customer authorization, account permissions, configuration, and applicable system terms.