| LEIE row ID | 12345 |
| Type | PERMEXC |
| Exclusion date | 2024-01-15 |
| Description | Fraud |
| Dataset release | 2026-05-01 |
CMS NPPES NPI Registry Data
Fonteum wraps the CMS National Plan and Provider Enumeration System — across — with available source metadata, FHIR R4 output for the supported provider-identity layer, and bulk export via the HL7 $export specification. Health-tech teams and analytics platforms can use this layer for NPI-keyed data pipelines while inspecting the loaded source date supplied by each response.
Exact public-record matching for NPI-linked exclusions
Fonteum can match an NPI to a named public exclusion-list source and return the source row, date, and citation. The public page shows representative OIG LEIE records; API access to per-NPI risk records is key-gated.
What is NPPES?
The National Plan and Provider Enumeration System is the CMS system that assigns and tracks National Provider Identifiers for eligible individuals and organizations. HIPAA-covered providers must obtain an NPI for standard transactions; other eligible providers may enumerate. The NPI is intelligence-free and does not establish licensure, credentialing, payer enrollment, or current practice. It is a deterministic join key only where another source publishes the same identifier.
The NPPES full-file download covers approximately 8 million records, with 6.8 million+ active records at any given snapshot. Public fields can include NPI, enumeration type (individual vs. organization), name, submitted addresses, taxonomy, enumeration date, last-update date, and deactivation date. Field availability varies. For a field-by-field breakdown of the intelligence-free NPI structure, check-digit algorithm, separate Type 1 vs. Type 2 enumeration field, and NUCC taxonomy codes, see the NPPES data-model deep-dive.
Limitations: NPPES is self-reported. Providers update their records on an honor-system basis; address and specialty data can lag real-world changes by months. Fonteum responses can expose a limitation where the route and row supply one, but limitation metadata is nullable and not guaranteed on every field. The methodology page documents the named comparison used for any published mismatch rate.
The FHIR R4 wrapper and provenance layer
Fonteum exposes supported NPPES-derived identity rows through FHIR R4 Practitioner and Organization routes. Availability and mapping vary by row and route. The CapabilityStatement at /api/fhir/metadata is the current declaration of supported resources and interactions; it is not a blanket guarantee that every NPPES field or USCDI element is populated.
FHIR responses can carry source and observation metadata where the route and underlying row supply it. The provenance schema defines up to fourteen nullable fields; consumers must inspect the returned resource and must not infer a source date, confidence value, cross-reference, or signature when it is absent.
Bulk export: the HL7 FHIR R4 Bulk Data Access $export endpoint at /api/fhir/Practitioner/$export exposes supported loaded Practitioner rows as NDJSON. Authentication and throughput depend on the requested API tier; the export does not imply complete national coverage or a signature on each row.
Who uses NPI data with provenance
NPPES can supply an NPI administrative record with a retrieval date. It does not establish licensure or credentialing, and whether that record satisfies a payer, CAQH, URAC, or another workflow requirement must be evaluated separately.
Finding in-network providers by specialty, accepting-new-patients status, and location requires a clean, taxonomy-normalized provider dataset. NPPES is the primary source; Fonteum adds address validation, taxonomy normalization, and real-time FHIR queries.
Analytics products can use NPI as a join key when each participating source publishes it. Fonteum's bulk export preserves source metadata and makes NPPES ingestion a managed dependency rather than a bespoke ETL job.
Frequently asked questions
- What is NPPES and what data does it contain?
- The National Plan and Provider Enumeration System (NPPES) is the CMS system that assigns NPIs to eligible individuals and organizations. Public records can include names, submitted addresses, taxonomy codes, enumeration dates, and a separate Type 1 or Type 2 field. Availability varies, and an NPI or NPPES field does not establish licensure or credentialing. Fonteum parses the public bulk file into structured records.
- How does Fonteum's NPPES layer differ from the public NPPES API (NPI Registry)?
- CMS provides a public NPI lookup API at npiregistry.cms.hhs.gov with per-record query support. Fonteum adds bulk $export over FHIR R4 Bulk Data Access, field-level source metadata, and taxonomy-code normalization against the NUCC code set. It joins to PECOS or the NPI-bearing subset of OIG LEIE only where those source rows publish the same NPI.
- Does Fonteum provide NPPES data for all provider types?
- The loaded NPPES table includes Type 1 and Type 2 records across many NUCC taxonomy codes. Individual rows can omit or carry multiple taxonomy values, and an NPI does not prove provider type, licensure, enrollment, or current practice. Taxonomy-specific exports are filters over the represented loaded rows, not a claim of complete provider coverage.
- Can I use Fonteum's NPI data to build a provider directory or lookup tool?
- Yes, subject to the data-platform agreement and attribution requirements. NPPES data is published under U.S. Government Works and is freely redistributable. Fonteum's provenance layer and API infrastructure carry separate terms. For provider-directory builds at scale — including deduplication, address normalization, and taxonomy mapping — Fonteum's audit-pack export is the fastest path to a clean, structured provider dataset.
- How current is Fonteum's NPPES data and how is freshness tracked?
- CMS publishes NPPES replacement files on its own schedule. Fonteum's newest production system timestamp observed 2026-07-12 was 2026-06-10. The source page and response metadata show the saved observation available to the product; they do not imply that every CMS release was ingested.
Access the NPPES data layer
The Audit Pack includes a pre-built NPPES export matched to CMS Care Compare and LEIE on NPI. For bulk FHIR access, custom taxonomy filters, or dedicated delivery schedules, contact the data engineering team.
- Barred, but still listed: excluded providers stay active in the provider directory2026-06-20 · 10 min
- Why 14% of skilled nursing facilities had a quality drop in Q12026-05-12 · 8 min
What the provider population looks like, on the NPI key
Fonteum's provider backbone joins the NPPES NPI registry to the CMS PECOS enrollment file on the shared NPI. In the committed 2026-05-28 snapshot it holds Medicare enrollment records spanning distinct NPIs across 56 states and territories and 325 CMS provider types — 85.5% individual practitioners and 14.5% organizations. Source and observation metadata varies by record and response; it is not a universal signature link.
Largest provider-enrollment types
Top states by enrollment volume
Related Fonteum surfaces: the per-provider profiles show available source metadata for an NPI, the OIG sanctions surface cross-joins exclusions on the same key, and the data catalog lists the published federal-source catalog.
Methodology
CMS publishes NPPES full-replacement files weekly and PECOS enrollment files monthly; those publisher cadences do not prove a completed Fonteum load. This analysis uses the committed 2026-05-28 snapshot. In the July 12 production audit, NPPES had a June 10 newest system date and PECOS had a June 18 source date. The pipeline runs in five stages: (1) source acquisition from data.cms.gov, (2) entity resolution on the NPI, (3) NPPES-to-PECOS join on the NPI key, (4) quality checks against published CMS record counts, and (5) source-metadata projection. Provenance fields are nullable, and no provenance fact currently links deterministically to a signature.
These four fields describe the committed analysis artifact. The broader, nullable source-metadata contract is documented on the data sources reference.
Source comparison: grain, cadence, and access
| Source | Data grain | Cadence | Access | Provenance |
|---|---|---|---|---|
| Fonteum | NPI-level + field provenance | Loaded system date: 2026-06-10; no platform cadence promised | API + bulk $export, free base | Nullable source metadata |
| CMS NPI Registry API | NPI-level (per-record) | Daily | Free, no bulk export | None |
| Definitive Healthcare | Provider / affiliation | Quarterly | Paid subscription | None |
| IQVIA OneKey | Provider / claim | Quarterly | Paid enterprise | None |
Sources
- NPPES NPI Registry — Full Replacement File — Centers for Medicare & Medicaid Services (CMS), Weekly. Primary source ↗ · Archive ↗
Used for: NPI identity, taxonomy, names, addresses, enumeration and deactivation dates. - PECOS Public Provider Enrollment File (PPEF) — Centers for Medicare & Medicaid Services (CMS), Monthly. Primary source ↗ · Archive ↗
Used for: Medicare enrollment status, provider type, and reassignment on the NPI key. - NPI Registry public lookup API — Centers for Medicare & Medicaid Services (CMS), Daily. Primary source ↗ · Archive ↗
Used for: Per-record cross-check of a single NPI against the live CMS registry. - OIG LEIE — List of Excluded Individuals/Entities — U.S. Department of Health & Human Services, Office of Inspector General, Monthly. Primary source ↗ · Archive ↗
Used for: Federal-exclusion cross-join on the same NPI key (sanctions overlay).
Committed analysis snapshot: 2026-05-28 · Reviewed by Jennifer Montecillo, MD · June 2026. Non-practicing medical reviewer.