What It Checks

RosterGuard screens your roster against six sources — the OIG exclusion list plus five CMS integrity signals. Each one is curated, kept current, and ships with the app, so screening happens entirely inside your account. Here's what each source is, what it means for your providers, and how often it refreshes.

Every screen stamps the exact vintage of each source it used, so you always know which version an answer came from.

The exclusion check

OIG excluded individuals (LEIE)

The federal List of Excluded Individuals/Entities — providers barred from federal healthcare programs. A provider on this list who's still on your roster is the finding RosterGuard exists to catch. Because only about 1 in 10 exclusion records carries an NPI, RosterGuard matches on name and date of birth as well, and grades each hit Strong / Likely / Possible. Each hit also shows what the exclusion was for in plain language (the authority and category), not just a statute code.

Refreshes monthly, on OIG's release cadence.

The five CMS integrity signals

These surface on the Roster health dashboard as you screen — data‑quality and eligibility issues that become payment problems if nobody owns them.

NPPES deactivations

NPIs that CMS has deactivated in the national provider registry. A deactivated NPI on your roster may mean the provider is no longer active. Refreshes weekly.

PECOS enrollment presence

Whether each NPI is present in the current Medicare enrollment snapshot. A roster provider missing from it may not be enrolled to bill Medicare. Refreshes quarterly (the snapshot quarter is always shown).

Medicare opt‑out affidavits

Providers who have formally opted out of Medicare. Billing Medicare for an opted‑out provider's services is a denial waiting to happen. Refreshes on CMS's release cadence.

Order & Referring eligibility

Whether each NPI is eligible to order and refer Medicare services (Part B, home health, power mobility, hospice). A provider who orders or refers but isn't eligible is a claims risk. Refreshes on CMS's publication cadence.

Revalidation due dates

Providers whose Medicare revalidation is coming due — surfaced when a deadline falls within 90 days, so it can be handled before it lapses. Refreshes on CMS's release cadence.

How it stays current

• All six sources are read‑only and update automatically as we refresh them — nothing to maintain on your side.

• Every screen and every export records the exact vintage of each source it used, so an auditor's "which list did the March screen run against?" is answered on the screen.

• The only thing in your account RosterGuard reads is the single roster table you connect (read‑only).

Query the data directly (optional)

You never need SQL — every screen works without it. But the reference data RosterGuard ships with, and your own review history, are read‑only tables inside the installed app you can query directly for ad‑hoc analysis or to join into your own reporting. Anyone you've granted the app_user or app_admin role can read them. (<app_name> below is whatever your admin named the app at install.)

• <app_name>.shared_dw.* — the reference data behind screening: the OIG exclusion list, NPPES deactivations, PECOS enrollment presence, Medicare opt‑outs, Order & Referring eligibility, revalidation due dates, and the exclusion‑authority reference.

• <app_name>.rg_state.* — your own results: review_queue (every hit with its evidence), run_log (every screen), and dispositions (the append‑only audit trail).

Your still-open Strong and Likely matches (hits with no disposition recorded yet), with a friendly confidence label:

SELECT q.hit_id,
       CASE q.tier WHEN 'T1'  THEN 'Strong'
                   WHEN 'T2A' THEN 'Likely'
                   WHEN 'T2B' THEN 'Likely'
                   WHEN 'T3'  THEN 'Possible' END AS confidence,
       q.npi, q.matched_on, q.created_at
FROM <app_name>.rg_state.review_queue q
LEFT JOIN (
    SELECT hit_id, MAX_BY(disposition, disposed_at) AS disposition
    FROM <app_name>.rg_state.dispositions
    GROUP BY hit_id
) d ON d.hit_id = q.hit_id
WHERE q.tier IN ('T1', 'T2A', 'T2B')   -- Strong + Likely; add 'T3' for Possible
  AND d.disposition IS NULL            -- still open — drop this line for all matches
ORDER BY q.created_at DESC;

The review queue is append-only, so a hit stays until a reviewer dispositions it; the dispositions join is what makes "still open" meaningful.

What share of the exclusion list carries an NPI — the gap RosterGuard's name + date‑of‑birth matching is built to close:

SELECT has_npi,
       COUNT(*)                                        AS excluded_persons,
       ROUND(100 * COUNT(*) / SUM(COUNT(*)) OVER (), 1) AS pct
FROM <app_name>.shared_dw.rosterguard_leie_individuals_dw
GROUP BY has_npi;

The tier column stores the engine's internal codes (T1, T2A, T2B, T3); the app shows these as Strong, Likely, and Possible — the CASE above is the exact mapping.

---

RosterGuard docs: Overview · Quickstart · Using the App · Understanding Matches · Security & Plans