Question 1

Why can't we cover this with one credentialing API or monitoring vendor?

Accepted Answer

Because no single source covers a real license mix. National aggregators like Nursys and the FSMB Physician Data Center stop at nurses and physicians. Psychologists, LCSWs, LPCs, and LMFTs have no aggregator at all, so verification runs board by board across ~50 state portals. Monitoring vendors resell the same public screening data and still miss niche boards. Running checks directly against each registry covers exactly the sources your roster requires, with evidence attached to every check.

Question 2

How does this adapt to our source list, professions, states, and screening cadence?

Accepted Answer

Each workflow is configured around your screening program, not the other way round: your source list (OIG/LEIE, SAM.gov, state Medicaid lists, the boards your license mix touches), your roster format in, your output format back, and your cadence (monthly exclusion sweeps, license expiry monitoring, onboarding checks). Your team keeps working from the same roster and queue; what changes is that the portal visits and transcription stop being manual.

Question 3

What happens when a source returns a possible match or the agent cannot verify a record?

Accepted Answer

It stops and hands off rather than deciding. A possible or multiple match returns every candidate record with the full detail attached, and a person confirms identity once. OIG's own guidance is that name matches need SSN verification no search can do. A not-found result is a successful clean check, not a failure. If a portal is down or the search itself errors, that comes back as an explicit technical failure, never a silently clean record.

Question 4

What evidence comes back, and how do we prove each check ran?

Accepted Answer

Every run returns a structured record: the status, exactly what was searched, match details where they exist, a screenshot of the source's results page, and a UTC timestamp. Execution history keeps the full trail, so an auditor's 'show me the screening for this provider on this date' is a lookup, not a reconstruction. An excluded or expired finding is recorded as a completed check with a business result, distinct from a run that failed and needs re-running.

Question 5

How are restricted-source credentials and provider data handled?

Accepted Answer

Most credentialing sources are public and need no credential at all. Where one is required (your SAM.gov API key, your DEA lookup login), the agent uses your accounts under least-privilege scoping, and you can rotate or revoke that access at any time. Provider data flows through HIPAA-compliant, SOC 2 Type II infrastructure with an audit trail per execution; the full access-control posture is on the security page.

Question 6

What if a registry, board, or exclusion source we need is not in the library?

Accepted Answer

The catalogue is where deployments start, not where they end. A new board or registry is a scoped addition, not a project: map the workflow in Asteroid's builder (a first working version is often running in under 30 minutes), or have Asteroid build and operate it as a managed service. Buyers with unusual license mixes typically add their niche boards in the first configuration pass.

Verify every provider, automatically.

One provider in. Six sources checked.

Frequently asked questions