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.
Go-live in as little as 30 minBrowser agentPublic source
We map your process, volume, and exception paths, then recommend a practical first scope.
Building internally? Read the docs →
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. 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.
How Asteroid runs this workflow
A direct service worker record enters the screening queue, Asteroid searches the state's adverse-actions registry and returns an eligible or not-eligible answer with evidence, and any name-only possible match goes to compliance review instead of becoming a verdict on its own.
How it actually runs
A direct service worker record enters the screening queue
Delivered to your screening queue
The eligible or not-eligible answer lands in the screening queue with the matched identity, evidence screenshot, and timestamp: the disposition the hire waits on.
Name-only match or incomplete identity: The same-name candidates return with the registry's detail and the date of birth as tiebreaker when shown; a compliance reviewer confirms identity once before any hiring decision.
Closing the loop
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.
{ "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.