What I built
Medicare Provider Outliers compares provider costs and service volumes with peers in the same taxonomy and state. I loaded 43.7 million rows from 2023 Medicare Part B/D files and an April 2026 NPPES registry snapshot into Snowflake, modeled them with dbt and published a static data app with supporting model documentation. The source documentation records those distinct vintages.
Loading and modeling the data
Raw columns load as text so staging can handle CMS suppression markers before casting numeric values. DuckDB filters the large NPPES extract before it is uploaded to Snowflake.
Eleven dbt models cover staging, provider-year aggregates, peer statistics and reporting marts. The repository defines 59 checks: 53 generic data tests, three singular data tests and three unit tests. Its passing-test count is a historical local-build report, not a current CI result.
CI parses project configuration and declared model/source dependencies without connecting to Snowflake. It does not validate executable SQL, inspect warehouse columns or execute those tests. A green parse job therefore does not establish that the models build or the data checks pass.
Choosing peers
The first version grouped providers using CMS specialty text. Internal Medicine combined providers with substantially different prescribing patterns. Switching to NPPES taxonomy codes split that category into 28 subspecialties and changed its recorded flag rate from 45% to 31.8%.
The provider profile model uses NPPES taxonomy and prefers its practice state, falling back to Medicare state fields when needed. These comparisons classify 2023 utilization with later registry attributes; specialty or location changes can affect which peers are grouped together.
The model requires at least 30 peers and exposes coverage counts per metric. In this dataset, 9,490 taxonomy-by-state groups meet the floor. The threshold is a modeling choice; meeting it does not make every comparison clinically equivalent.
The application exposes both a MAD modified z-score and a classical z-score. At the configured thresholds, their recorded overall flag rates are 5.23% and 2.01%. Those rates divide by all 7,062,726 registry providers in the mart, including providers without observed Part B or Part D activity. The summary records 1,069,017 Part D prescribers and 1,076,323 Part B providers; these populations overlap. The rates are not the proportion flagged among Medicare-active or metric-eligible providers.
The rules use different cutoffs: 3.5 for modified z and 2.0 for classical z. No labeled evaluation establishes false-positive rates, actionable-case recall or that the larger flagged set is better. The committed summary and extraction SQL expose the denominator and coverage counts.
Reviewing a flag
The app includes a ranked table, provider drill-down, state comparison and methodology page. A reviewer can inspect the measure, peer group, peer count and deviation before deciding what additional context is needed.
A statistical flag identifies a difference to investigate, not its cause or misconduct. Facility-level attribution is one possible explanation for extreme totals; the provider aggregates do not establish it. Specialty differences and patient populations can also complicate interpretation. Any financial gap shown by the analysis is a comparison under stated assumptions, rather than a savings estimate.
Public delivery and tradeoff
The data app serves committed extracts without requiring warehouse credentials. Its ranked table contains the top 1,000 extracted rows per metric, and its provider selector contains six selected examples. Searching those controls does not query the full mart; a missing provider is not evidence that they were unflagged. Full per-NPI lookup is not implemented in the public app.
The dbt documentation supplies model lineage, column definitions and tests. Updating the public app requires refreshing those extracts.
A Hex specification documents a possible warehouse-querying version. The image below is a mockup of that version; the shipped interactive application uses Evidence.
Hex specification mockup. The linked Evidence app is the live implementation.
Next steps
Additional years would support comparisons over time. More work is also needed to distinguish individual-provider patterns from organizational billing and to test alternative geographic peer groups. These changes would alter the interpretation of flags and should be evaluated before expanding the analysis.