> 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/methodology.md).
# Understanding Matches
This page explains how RosterGuard decides two people are the same, what the three confidence levels mean, how accurate the matching is (with the numbers behind it), and where the boundaries are.
## Why name matching at all
Only about 1 in 10 OIG LEIE records carries an NPI (roughly 8,600 of 83,000 in the current exclusion list), so the check most teams write first, roster NPI against the list, is blind to about 90% of it. Among excluded nurses the coverage is worse: under 1% carry an NPI. Closing that gap means matching on **name and date of birth**, and doing it defensibly means published accuracy, published false‑positive behavior, and per‑hit evidence, which is what the rest of this page is.
Names are compared after the same cleanup on both sides: case and punctuation removed, suffixes dropped, and hyphenated or multi‑part surnames split so each surname still matches on its own (which is how married‑name and hyphenation changes still line up). Date of birth is the precision anchor: it divides the chance‑collision space by roughly 15,000, which is what lets name‑based matching run at a usable false‑positive rate.
## The three confidence levels
From exact‑identifier match to advisory signal
| Confidence | What matched | How to treat it |
| ------------ | --------------------------------------------------- | ------------------------------------------------------ |
| **Strong** | Exact NPI match against an exclusion record | An identifier match, the highest‑evidence hit |
| **Likely** | Same name and date of birth | Strong evidence; review the per‑hit fields and confirm |
| **Possible** | Same name and state, no date‑of‑birth corroboration | Advisory only: a research signal, never auto‑confirmed |
A Strong hit whose exclusion NPI actually belongs to an **organization** (not the person) is held back for review rather than treated as a confirmed match. Every hit carries per‑field evidence: which fields matched exactly, which agreed after cleanup, which conflict, and the exclusion's authority with a plain‑language description of what it was for. Likely and Possible results are potential matches; verify via OIG's online SSN check (the LEIE search / SSN verification at oig.hhs.gov/exclusions) before adverse action.
## How accurate it is
These figures are measured against a validation set and re‑measured on every release; every screen also shows the exact source vintages it ran against.
| Measure | Result | Basis |
| ----------------------------------------------- | ------ | ------------------------------- |
| Excluded providers found by name + DOB (Likely) | \~95% | \~7,000‑provider validation set |
| Found once the wider name variant is included | \~98% | same validation set |
| Exclusion records carrying an NPI | \~10% | current exclusion list |
| Excluded nurses carrying an NPI | \~0.7% | current exclusion list |
In practice, an organization running monthly screens of a \~2,500‑provider roster should expect roughly **one strong‑evidence false positive every six years**: the matching is tuned to be quiet. The Possible tier is deliberately noisier (a name + state coincidence surfaces a handful of research rows per screen) and is never treated as a match.
**The validation set:** it was built from providers whose exclusion records carry an NPI (so the right answer is knowable) and it over‑represents physicians. The accuracy figures describe that set, not every excluded provider; a heavily nurse‑weighted roster, for example, isn't separately measured.
## What this is not
* **Not SAM.gov or state Medicaid list screening.** RosterGuard screens against the OIG LEIE plus CMS enrollment‑derived signals. It complements, but does not replace, your SAM.gov and state Medicaid screening program.
* **No point‑in‑time / historical claims.** RosterGuard screens against the current exclusion list. It does not reconstruct "was this provider excluded as of {date}."
* **Possible matches are advisory.** A name + state match with no date of birth is a research signal. Acting on it without secondary‑identifier verification is outside the product's intended use.
* **Determinations are yours.** The app records dispositions; it never makes them.
{% hint style="warning" %}
RosterGuard is a screening aid. Match dispositions are determinations made by your organization's reviewers. Likely and Possible results are potential matches; verify via OIG's online SSN check (oig.hhs.gov/exclusions) before adverse action.
{% endhint %}
***
**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) · [What It Checks](/data-catalog/rosterguard-app/data-dictionary.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/methodology.md?ask=&goal=
```
`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.