Direct Service Worker (DSW) Registry Check Automation

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.

See it run on your systems.

We map your process, volume, and exception paths, then recommend a practical first scope.

Overview

What this workflow does

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

The pre-hire registry gate, run before every offer

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.

LDH State Adverse Actions List

How it actually runs

1. The agent opens the state’s adverse-actions registry search. For Louisiana that’s the LDH State Adverse Actions List, a public site with no login.
2. It searches by the person’s first and last name only. It never enters a Social Security Number and never outputs one; a date of birth, when provided, disambiguates same-name matches instead.
3. It reads the results and classifies them: a matching finding means not eligible; no match means eligible; several same-name candidates are reported as multiple matches for a person to resolve.
4. For a finding it captures the listed name, the registry or case identifier when shown, the finding’s status, and its effective date. For a clean check it returns the eligible record with the searched name echoed.
5. It screenshots the results as audit evidence, timestamps the check, and returns one structured record.

What lands back in your system

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.

Closing the loop

A registry check after the offer letter is an audit finding, not a screen

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.

At scale

One candidate, or every hire and re-screen

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.

Human in the loop

What escalates to a human

Checks run on HIPAA-compliant, SOC 2 Type II infrastructure and log every result, so hiring-eligibility screening holds up in a state review.

Questions

Frequently asked questions

Our pre-hire checklist is our own. How does this check fit into it?

The check is fitted to your hiring sequence, not the reverse. Asteroid configures the inputs you send (first and last name, with date of birth optionally supplied to disambiguate), the shape of the eligible or not-eligible record, where results land (your ATS queue, a sheet, or an API), and which outcomes pause for HR review. The registry search itself, the evidence screenshot, and the timestamp are fixed, so every candidate gets the same screen regardless of who requests it. Recruiters keep their existing workflow.

What access does the registry check need, and where do results arrive?

No source credentials: Louisiana's LDH State Adverse Actions List is a public site with no login, so there is nothing to provision or rotate on the registry side. Candidate names arrive however your hiring process already works (individual requests, batches, or an API call), and each run returns one structured record with the eligibility answer, the screenshot, and the timestamp through the same channel. An integration is optional. Delivery access stays least-privilege and revocable by you.

What happens when the registry is down or a candidate's name matches several records?

An unreachable registry ends the run as an explicit error, never a silently recorded clean check before a hire, which is exactly the failure a pre-hire gate cannot afford. Several same-name candidates come back classified as multiple matches, with date of birth as the tiebreaker when the registry shows one, and a person resolves identity before any hiring decision.

What evidence does each check leave for a state review, and who makes the hiring call?

Every run returns one structured record: the eligible or not-eligible answer, the listed name, the registry or case identifier when shown, the finding's status and effective date, an evidence screenshot, and a timestamp. A clean check is a populated, affirmative record (who was checked, what it means, when), not a bare empty result, and both outcomes are normal successes. A finding means the state says not eligible; that record and its evidence go to your team, and the hiring file shows exactly why.

How is this different from a state Medicaid exclusion check when both use the same source?

Same Louisiana source (the LDH State Adverse Actions List), different question and different output shape.