> For the complete documentation index, see [llms.txt](https://docs.dataplex-consulting.com/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://docs.dataplex-consulting.com/data-catalog/rosterguard-app/data-dictionary.md).

# 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; there is 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.*`** holds 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.*`** holds 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:

```sql
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:

```sql
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](/data-catalog/rosterguard-app.md) · [Quickstart](/data-catalog/rosterguard-app/quickstart.md) · [Using the App](/data-catalog/rosterguard-app/using-the-app.md) · [Understanding Matches](/data-catalog/rosterguard-app/methodology.md) · [Security & Plans](/data-catalog/rosterguard-app/security-and-plans.md)


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://docs.dataplex-consulting.com/data-catalog/rosterguard-app/data-dictionary.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.