Quickstart
From install to your first reviewed screen in about 15 minutes.
Prerequisites: a Snowflake role that can install Marketplace apps, and SELECT on the roster table you want to screen. Nothing else — installing requires no account‑level privileges, the app makes no external calls, and it reads nothing in your account until you connect a roster table in step 3.
1. Install the app
Get RosterGuard from the Snowflake Marketplace and install it into your account. When the install finishes, open the app from Data Products → Apps in Snowsight. You'll land on the Roster setup page.
Want to try it before connecting your own data? The app includes a built‑in demo roster — 120 synthetic providers (no real people) with 10 planted matches (2 Strong, 4 Likely, 4 Possible). Choose Use demo roster in step 3 and skip to step 5.
2. Grant your team access
The app installs with two roles you grant to your team:
app_user
Reviewers, analysts
Run screens, work the review queue, export
app_admin
Admins
Everything above, plus connecting a roster, mapping columns, and scheduling
Your Snowflake admin grants these to existing roles — one statement each:
GRANT APPLICATION ROLE <app_name>.app_user TO ROLE <your_reviewer_role>;
GRANT APPLICATION ROLE <app_name>.app_admin TO ROLE <your_admin_role>;<app_name> is whatever your admin named the app at install. If you're a reviewer reading this, forward this step to your Snowflake admin.
3. Connect your roster (Roster setup — step 1)
On the Roster setup page, choose Connect your roster. Snowflake's grant dialog opens — pick the table or view holding your provider roster and grant read‑only SELECT on that one object. The app can see nothing else in your account, and you can revoke or reconnect at any time. Once you save, RosterGuard confirms the connection and shows the table you picked, then a Continue to mapping button takes you to step 2.
Your roster works as‑is — any table with one row per provider. If your provider data is spread across HR, credentialing, and scheduling systems, a simple view that unions them into one row per provider is enough; you don't need a master‑data project to start. For the strongest matching it should have last name, first name, and date of birth (required), plus NPI (recommended) and license state (optional).
Roster shape — one row per provider:
last name
TEXT
Yes
first name
TEXT
Yes
date of birth
DATE or TEXT
Yes
A DATE, or a parseable string — ISO YYYY-MM-DD is safest. This is the gate for Likely (name + DOB) matches.
NPI
TEXT
Recommended
10‑digit identifier — store as text so it isn't numerically coerced.
license state
TEXT
Optional
Two‑letter code.
Sample row:
Prefer to try it first? Choose Use demo roster on the Roster setup page to map, screen, work the review queue, and export end to end — exercising every confidence level — before you connect any real data.
4. Map your columns (Roster setup — steps 2–3)
Step 2 shows your roster's columns next to the fields RosterGuard matches on. Pick the column for each field; live coverage indicators show how usable each one is (e.g. "DOB parseable 96.7%").
The mapping step shows per‑field coverage as you map, so you know before the first screen whether your roster supports the Likely (name + DOB) matches — not after.
Why DOB matters: date of birth is what makes name matching precise — it divides the chance‑collision space by roughly 15,000. If fewer than 80% of your rows have a parseable DOB, the wizard pauses and asks you to acknowledge degraded mode (NPI‑only‑strength screening) before continuing. Fixing DOB coverage at the source is almost always worth it.
Step 3 shows the validation summary — row count, per‑field coverage, and what each gap means for match strength. Select Confirm mapping — run first screening → to save the mapping. You're ready to screen.
5. Run your first screen (Screen & run)
Open Screen & run. Above the run button you'll see the freshness tiles — the exact vintage of the OIG exclusion list and the other sources this screen will use. Select Run screening.
The run takes seconds to a few minutes depending on roster size. When it finishes you'll see rows screened and hits graded by strength:
Strong
Exact NPI match against an exclusion record
Likely
Same name and date of birth
Possible
Advisory: same name and state, with no date‑of‑birth corroboration
On the trial, screening is capped at the first 1,000 providers. A larger roster is only partially screened — the rows beyond the cap are reported as not screened until you upgrade.
Every screen also checks your NPIs against deactivations, PECOS enrollment presence, opt‑outs, and upcoming revalidation deadlines — those land on the Roster health page.
6. Confirm it worked
You don't need SQL to verify a screen ran. On Settings & export, the run log shows every screen with its date, type (manual or scheduled), rows screened, status, and the exact source vintages it used. A row with your screen's timestamp and pinned vintages means your install, connection, and mapping are all working.
From here: work any hits in the Review queue (each disposition requires a note and becomes a permanent audit record), check Roster health for deactivations, PECOS gaps, opt‑outs, and revalidation deadlines, and export your CSV audit log or HTML evidence pack from Settings & export.
Troubleshooting
A freshness tile shows AGING (or the run button is blocked). AGING means a source is past its expected refresh window but still within the screening threshold — you can run, and the exact vintage is pinned to the run record. A blocked run button means the exclusion list itself has gone materially stale; you can tick Run against stale LEIE — record acknowledgment to run immediately (the stale vintage is pinned to that run), or wait for the block to clear when the source refreshes. Either way, the vintage stamped on the run record is what you cite for the monthly attestation.
"Run screening" is greyed out
Cause: the column mapping hasn't been confirmed yet — a connected roster can't be screened until the mapping is saved.
Solution:
Go back to Roster setup and complete the wizard through Confirm mapping — run first screening →.
Return to Screen & run — the Run screening button enables once the mapping is confirmed.
The table picker doesn't show my roster table
Cause: the role you're using in Snowsight lacks SELECT on the table, or you don't hold the app's app_admin role.
Solution:
Switch to a role with SELECT on the roster table.
Confirm app_admin was granted to that role (step 2).
Re‑open Connect your roster — the table picker lists only objects your current role can see.
The wizard pauses with a "degraded mode" warning
Cause: fewer than 80% of your roster rows have a parseable date of birth, so the Likely (name + DOB) matches can't run.
Solution:
Check the DOB column's format in your source table (mixed formats are the usual culprit).
Fix coverage at the source and re‑run validation — it's almost always worth it.
Or acknowledge degraded mode to continue with NPI‑only‑strength screening.
My first screen returns zero hits
Cause: usually a healthy roster — most screens of a clean roster return few or no exclusion hits. If you expected demo hits, the demo roster may not be the connected roster.
Solution:
Confirm which roster is connected on the Roster setup page.
Use the built‑in demo roster — it contains 10 planted matches (2 Strong, 4 Likely, 4 Possible).
Check Roster health: deactivations, PECOS gaps, opt‑outs, and revalidation deadlines surface there, not in the review queue.
Enabling the monthly schedule asks for new privileges
Cause: expected — the schedule runs automatically in your account on your chosen day, which needs a scheduling privilege you grant.
Solution:
Grant the privileges in the Snowsight dialog (they're opt‑in and scoped to the app).
Or keep screening on‑demand — manual screens never need account‑level privileges.
Next steps
Work hits and dispositions screen‑by‑screen: Using the App
Understand the confidence levels and the measured recall behind them: Understanding Matches
See exactly what RosterGuard screens against: What It Checks
RosterGuard docs: Overview · Using the App · Understanding Matches · What It Checks · Security & Plans
Last updated