Repeatable reporting checks

Check the files. Account for the changed total.

Compare two snapshots of the same reporting period. Check their structure and values, then account for changes in eligible event count.

Files stay in this browser. No uploads or automatic saving. Each file: up to 10 MB and 100,000 rows.

Data mode

Explore a complete synthetic dataset

1,000 encounters per snapshot, 250 invented patient IDs, three sites, and three programs. Choose snapshots below, or download the CSVs and select them from your drive.

Database, supporting tables, and expected results

The complete SQL file creates a SQLite database with patient, site, program, and encounter-history tables plus baseline/current views. All records and definitions were invented for this example.

With the supplied profile and August period, the eligible count changes from 800 to 794. The duplicate-key file should block reconciliation.

1. Choose your snapshots

No files selected.

Coverage is your confirmation, not something inferred from file dates. Unconfirmed coverage blocks the total reconciliation.

2. Define the check once

Profiles contain settings and column names, never selected data. Dates and coverage are entered each run.

Column mappings and additional rules

Mappings use one source=destination per line. Names after mapping are used by all rules. Values remain text; identifiers keep leading zeros.

Dates must be YYYY-MM-DD. Same-day events pass. The measure's service date remains required even if another chronology check allows an open end.

What this establishes

A complete result accounts for the count difference under your selected definition. It does not infer causes, reconstruct overwritten history, validate clinical decisions, or add together distinct-person counts. Changed records that remain eligible contribute zero to this count; inspect other changes in the extract comparison.

Study historical cutoffs, referral chronology, and dated mappings in the executable reporting packs.