Verify every provider, automatically.

Run NPI, exclusion, license, DEA, and state registry checks without opening every source manually.

Browser-based, no API required.

Bringing one provider in means checking the NPI registry, running federal and state exclusion checks, confirming license status with the right state medical board, and tracking down DEA registration, each in its own portal. Asteroid runs all four checks in parallel as one reusable workflow.

Workflow context

These workflows commonly involve government registries, state medical board portals, federal exclusion lists, and professional licensing databases.

One provider in. Six sources checked.

Asteroid runs every verification check in parallel — navigating each source the way your team would, using your existing accounts and permissions. No API setup required.

What Asteroid returns

• ✓Verified provider identity
• ✓Exclusion status
• ✓License status
• ✓DEA registration status
• ✓Source links and evidence
• ✓Timestamped audit trail
• ✓Exceptions flagged for review

Before

• –Search each source manually
• –Copy results into spreadsheets
• –Screenshot evidence
• –Recheck stale records
• –Chase exceptions manually

After · with Asteroid

• ✓Submit provider once
• ✓Checks run in parallel
• ✓Results return structured
• ✓Evidence is captured
• ✓Exceptions route for review

Workflow templates

These reusable workflow templates can be configured around your team's existing process, review rules, accounts, permissions, and output format.

Frequently asked questions

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

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.

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

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.

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

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.

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

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.

How are restricted-source credentials and provider data handled?

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.

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

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.