How we know what we know.

Every published figure starts from a public, reproducible federal source. Our primary inputs are CMS, HRSA, and BLS public datasets — the canonical authorities for U.S. healthcare provider identity, Medicare facility quality, shortage-area exposure, and healthcare workforce context.

Examples: CMS NPPES for the active provider population, CMS PECOS for Medicare enrollment status, CMS Care Compare for facility-level quality, HRSA HPSA for shortage-area context, BLS OEWS for healthcare workforce wages, BEA Regional for healthcare per-capita economic context.

• CMS NPPES + CMS PECOS (provider identity + Medicare enrollment)
• CMS Care Compare (facility-level quality across 8 modules)
• HRSA HPSA (shortage-area exposure)
• BLS OEWS + BEA Regional (healthcare workforce + economic context)
• State medical / nursing boards (Sprint 3 ingestion in progress for CA, FL, AZ, LA)
• Human editorial review (deduplication, specialty / facility-class assignment)

We track healthcare providers and Medicare-certified facilities with a physical US presence across two source families: (a) Direct Provider Data — CMS NPPES, CMS PECOS, CMS Care Compare; (b) Healthcare Workforce & Economic Context — HRSA HPSA, BLS OEWS, BEA Regional. A record enters the catalog when it meets three tests: a stable federal identifier (NPI / CCN / state license), a publicly accessible source record, and at least one cross-source reconciliation.

We explicitly exclude non-healthcare provider records and entities outside the federal-source coverage we ingest. Known gaps — recently-issued NPIs not yet in the public NPPES snapshot, providers at facilities awaiting Care Compare reporting eligibility — are documented in each study.

Listings refresh on a rolling 30-day cadence; ratings and review counts refresh weekly for the highly-rated segment (rating ≥4.5 with ≥50 reviews). Research-grade snapshots — the numbers we cite in studies and on the brand hub — are dated and versioned so readers can reproduce any cited stat at the publication date.

For healthcare provider records normalized across federal CMS sources and healthcare workforce data sources, the credential status we surface is what those public sources themselves publish — facility-level records (CMS NPPES, CMS PECOS), quality-and-outcomes records (CMS Care Compare modules), workforce records (HRSA HPSA, BLS OEWS) — not credentials we independently audit. We do not assert credentials we cannot trace to a federal public source.

We do not claim to independently vet provider quality. We claim to publish what independent federal sources have already measured, and to make those sources auditable.

Business owners, journalists, and readers can report an error to corrections@fonteum.com. We acknowledge every report within two business days and publish the resolution — accepted, rejected with reasoning, or in-review — on a public corrections log.

Substantive research corrections update the affected article and append a dated note at the top. Minor factual corrections to directory listings update the listing and log the change. No correction is silent.

Rankings are derived from public ratings and credentials; they are not influenced by any commercial relationship. When a business pays to enhance a directory listing, the enhancement is disclosed on the listing page. Research content is never sponsored.

We do not ghostwrite reviews, host sponsored placements disguised as editorial, or adjust rankings in response to claim-status upgrades. A paid listing and a high-rated listing are different things, and we show both, clearly.

Each study declares its sample size, inclusion criteria, temporal coverage, and statistical methods up front. Datasets are published alongside the article as downloadable CSVs so any finding can be reproduced or reinterpreted.

Where a study uses correlations or modeled estimates, the methods section names the estimator, the assumptions, and the magnitude of uncertainty. When we don't know, we say so.

Each registered source family — CMS NPPES, CMS PECOS, CMS Care Compare, BLS OEWS, HRSA HPSA, U.S. Census Bureau population estimates — passes through the same five-stage ingestion pipeline before any field it produces becomes visible on a public profile or a research snapshot.

Stage 1, manifest authoring: a versioned manifest declares the source's authority, refresh cadence, distribution license, and the explicit set of fields we intend to surface. The manifest is reviewed against the §125 restricted-source list and the §94 displayability rules. Stage 2, dry-run pilot: a small geographic or specialty-bounded run validates field coverage and match rates against a held-out sample. Stage 3, confidence calibration: the per-field match-rate and confidence distribution are reviewed; low-confidence rows are excluded from the displayable set. Stage 4, registry write: the source row is committed to src/lib/brand/sources-registry.ts with its tier, status, refresh cadence, and explicit limitations. Stage 5, public surfacing: the SourceChip and ProvenanceCard render the source per the four-field contract documented at /data-platform/schema.

• Stage 1 — versioned manifest + license + field list
• Stage 2 — bounded dry-run + match-rate validation
• Stage 3 — confidence calibration + low-confidence exclusion
• Stage 4 — registry write to src/lib/brand/sources-registry.ts
• Stage 5 — public surfacing via SourceChip + ProvenanceCard

Entity matching is a deterministic pipeline today, with probabilistic scoring layered on top for the ambiguous tail. The deterministic stage matches on a stable identifier when the source provides one — NPI for NPPES/PECOS, license number for state contractor boards, CMS Certification Number for CMS Care Compare. Where no stable identifier exists, the probabilistic stage scores candidate matches on (name, address, locality, taxonomy or specialty) using normalized string distance plus geocode proximity.

The §95 confidence tier is assigned at this stage. High-confidence matches require a stable identifier match plus address agreement at the locality level. Medium-confidence matches require multi-field agreement without an identifier. Low-confidence matches do not ship to the public surface; they remain visible only in operator tooling and are flagged for manual review.

• Deterministic match on stable identifier (NPI / license / CCN)
• Probabilistic fallback on (name, address, taxonomy)
• §95 confidence tier assigned at match time
• Low-confidence matches stay internal — never surface publicly

The Fonteum provenance contract is a four-field per-(provider, source, field) row: source name, last-checked ISO date, confidence tier, and display permission. The contract aligns with W3C PROV-DM's separation of Entity / Activity / Agent and with the FAIR data principles' Findable + Accessible + Interoperable + Reusable axes — every published field is findable via the source registry, accessible at a stable URL, interoperable through the JSON-LD Dataset emission on each research study, and reusable under the published attribution license.

The wire shape is documented at /data-platform/schema. The visible UI shape is documented at /data-provenance, where the same contract renders the ProvenanceCard on every public profile. The launch gate enforces that no public field renders without a matching provenance row.

• Four-field contract: source · last-checked · confidence · display permission
• W3C PROV-DM: Entity / Activity / Agent decomposition
• FAIR principles: Findable · Accessible · Interoperable · Reusable
• Wire shape at /data-platform/schema · UI shape at /data-provenance

Confidence scoring is the hand-off between matching (which says 'this profile is probably this source row') and display (which decides whether to show it). The §95 tier is high · medium · low. High requires a stable-identifier match plus address agreement. Medium requires multi-field agreement without a stable identifier. Low covers the residual ambiguity tail. Public surfaces render high-confidence rows by default; medium-confidence rows render with explicit hedging copy where applicable; low-confidence rows do not render at all.

The confidence threshold is not a learned model today; it is a deterministic rule documented in the §95 matching plan and reviewed quarterly. A learned-model approach is part of the planned roadmap once the per-source false-positive baselines are calibrated against a labeled gold set. The current state is named explicitly as 'deterministic threshold + manual review of the medium tier' so a citing reader has the actual posture, not a future-state aspiration.

• Tier high — stable identifier + address agreement
• Tier medium — multi-field match, no stable identifier
• Tier low — residual ambiguity; not displayed
• Threshold is deterministic + manually reviewed today; learned-model approach is on the roadmap

We version the value, not the surrounding metadata. A renamed clinic gets a new name change record; a license expiration update gets a new state_license_expiration change record. The change shape is documented at /data-platform/schema and includes provider_id, field, previous_value, new_value, source, observed_at, and snapshot_id.

Change feeds are emitted per snapshot and tied to the originating source's refresh cadence. CMS NPPES runs daily. CMS PECOS runs weekly. HRSA HPSA runs monthly. CMS Care Compare runs quarterly. BLS OEWS and BEA Regional refresh annually. The observed_at field is the timestamp our pipeline reconciled against the source — not the snapshot date, which can lag.

Every published research study under /research ships with the input dataset (CSV at /research/data/<slug>.csv), the temporal-coverage range, the inclusion criteria, the sample-size declaration, and the methodology block. A motivated researcher could pull the same source dataset from its origin (CMS Care Compare's data.cms.gov surface, the CMS NPPES NPI Registry API, the HRSA HPSA download, etc.) and reproduce the per-state aggregates we publish.

Where a study uses our internal indexed dataset (e.g. dermatology access density), the data file we ship is the same file that produced the published numbers; aggregations are simple group-bys documented in the technical appendix on the study page. Where a study aggregates a federal source (e.g. the CMS Care Compare snapshots), our aggregation script lives in scripts/research/ and the data file we ship matches what the script emits.

• Every study ships its CSV at /research/data/<slug>.csv
• Methodology block declares sample size + inclusion + temporal coverage
• Federal-source studies → aggregation script in scripts/research/
• Indexed-dataset studies → simple group-by documented in technical appendix

Each individual research study page carries a copy-paste citation block at /research/<slug>#cite. The press kit at /press surfaces the same block for the top-3 ready-to-cite picks plus an AP-short variant. The minimum acceptable citation includes the study title, the publication month + year, and a link to the canonical study URL.

Datasets are free to cite under attribution. The recommended citation form is: Fonteum Research, "<Study Title>," <Month YYYY>. https://fonteum.com/research/<slug>. Dataset: https://fonteum.com/research/data/<slug>.csv. APA, BibTeX, and the AP-style short form are surfaced on each study page under the §165 citation upgrade.

• APA: per-study /research/<slug>#cite
• AP short: (Fonteum Research, <Month YYYY>)
• BibTeX: per-study /research/<slug>#cite
• Dataset: /research/data/<slug>.csv

Counts published on this site describe the Fonteum indexed provider dataset — currently 26,417 healthcare-confirmed providers across 6 federal public-record sources — not a representative sample of the U.S. healthcare provider data landscape. Where a study cites a network-level number, the source is the snapshot file shipped with the codebase. Where we don't have an aggregate, we mark the section as deferred rather than estimate it.

We do not own, manage, or moderate the Google reviews referenced across our studies. Reviews originate on Google Business Profiles and are owned by Google and the original reviewers. Our role is aggregation and presentation under a published methodology — not authorship.

We do not change organic ranking in exchange for payment. Featured slots, where they exist, are clearly labelled as Featured. Claiming a listing transfers control of the published profile to the owner; it does not alter ranking signals.

We do not apply the banned v-word adjective family to listings in user-facing copy unless an explicit credential check from a public licensing source supports it. SOP §10 prohibits the general-purpose adjective network-wide.

• Indexed dataset, not a national survey
• We don't own or moderate Google reviews
• No pay-to-rank in organic placement
• No unsupported v-word adjective in user-facing copy