How to read the screening audit report
Every screening run produces one PDF. It is written to be handed to a surveyor, an auditor or a payer without explanation, so the first page says what happened in plain sentences and the technical material sits in an appendix at the back. This page walks through it section by section. The sample report (PDF) uses this exact layout with a fictional roster and real source data.
1. The summary box
Three sentences and five numbers. How many roster names were screened, on what date, against how many sources and files. How many potential matches were found and, of those, how many still need review, how many a reviewer cleared, and how many a reviewer confirmed. Whether every source file was current at screening time. If anything needs review, a next-step line says where to do it.
Two words to know. A potential match means a roster name resembled a public source record closely enough to warrant a look. It is not a determination about the person; that determination is the reviewer's, and the report records it. Current means our copy of that source file had been verified against the publisher within the expected window when the run happened.
2. Degraded screening notice
This red box appears only when at least one source file was not current. It names each file and why (stale, missing or quarantined), and the summary box says how many. A run with this notice is complete only for the sources marked Current; the same fact is visible to anyone on the public status board. We never hide it, because a screening that silently skipped a list is worse than one that says so.
3. Sources checked
One row per source file, named as the publisher names the list: the federal OIG LEIE and its two monthly supplements, SAM.gov, and each state list. The columns are the file (full list, daily extract, supplement), its status, the publisher's own publication date where the publisher prints one, the age in days since our copy was last verified, and the number of records in the version used.
4. Potential matches
A short legend explains match strength, then each potential match gets its own block. The heading reads like a sentence: the roster name, "may match a record in", the source, and the review state. Under it, "How it matched" says which of four tests the pair passed:
| T1 | NPI matched exactly. The strongest test, because an NPI identifies one provider. |
|---|---|
| T2 | Name and date of birth both matched exactly. |
| T3 | Name matched exactly, but a date of birth was not available on one or both sides. Most state lists publish no date of birth, so most state matches are T3. |
| T4 | Weaker name evidence: a similar name by fuzzy comparison (the report prints the similarity score), a first and last name transposition, a nickname pair, or an exact name with a conflicting date of birth. The Match basis line says which. |
The evidence table puts your roster entry on the left and the source record on the right: name (and any other names the source lists for that record), date of birth comparison, NPI, the sanction on record with its effective date, and the match basis. The Review history under the table lists every decision recorded for that pair, who recorded it, when, and the note they left. A decision recorded after a report was generated appears in the next run's report; issued reports are never rewritten.
5. What to do with a match that needs review
Open Matches in ExclusionSentry. The same evidence is there, with two actions: clear with a note, or confirm. Clearing means you compared the two records and they are not the same person; the note is your reasoning and it becomes part of the audit record. Confirming means you believe they are the same person. What your organization does after a confirmation is your decision, made under your own policies and, where needed, with counsel; the software documents the screening and does not advise on employment or program participation. See what a potential match means.
6. Verification appendix
The last page holds what a third party needs to verify the report against our archive: the run ID, the roster content digest, every source file's version identifier and SHA-256 checksum, and a citation for each potential match (record key and source version). Every source file is archived with its checksum before we parse it, so a checksum in the appendix can be matched to the exact bytes we screened against. The PDF's own SHA-256 is recorded when the file is stored and shown on the Reports page, so a copy handed to a surveyor can be checked against the original.
See the sample report (PDF), or run a free federal single-name check, which uses the same source data.