What does a source-attested provider profile mean for a patient portal?

It means every fact shown on a provider profile — name, NPI, specialty, practice location — carries a record of where it came from and when it was last checked, rather than appearing as an unsourced attribute. Fonteum attaches a provider_field_provenance row to each rendered value: source name (for example CMS NPPES), dataset identifier, last-checked date, and any documented limitation of that source. Drawn from a graph of 44 federal source families, a patient portal can render the federal facts and, alongside each, a SourceChip showing the citation and date. For a patient making a care decision — a YMYL context where accuracy is consequential — that visible chain of custody is the difference between a directory listing and an attested record. Fonteum is a source-provenanced data layer over public federal data; it does not assert claims about a provider beyond what the cited federal file supports, and trust language unsupported by a provenance row is excluded by doctrine.

Can I embed Fonteum find-a-doctor data in our patient-facing surface?

Yes. Fonteum exposes provider data through a FHIR R4 US Core 6.1.0 REST API — the Practitioner, PractitionerRole, Organization, Location, and HealthcareService resources — plus semantic search at /search for natural-language find-a-doctor queries by specialty, geography, or clinical context across 6.8M+ active NPI records. SMART Backend Services auth (a JWT client assertion signed with RS384, exchanged for a short-lived token) supports unattended server-side integration, so a portal's backend can fetch profiles without a human in the loop. The CapabilityStatement at /api/fhir/metadata enumerates the resources and search parameters an embed can use. Because the data is public federal record, an embed is not gated behind PHI-handling requirements — Fonteum carries no patient data, only public provider data — which keeps the integration surface narrow.

How does field-level provenance render for a patient?

Fonteum's signature display component is the SourceChip — a small per-field marker showing the source name, the date that field was last checked, and any limitation of the source. On a public Fonteum provider page each rendered fact carries one, and the same chain is available programmatically: in a FHIR response it rides inline as a 14-tuple provenance tag on the resource's meta.tag. A patient portal can surface this directly so a patient sees not just 'this provider's specialty is X' but 'sourced from CMS NPPES, last checked on this date.' That transparency is deliberate: rather than presenting a provider as endorsed or rated, Fonteum presents the federal fact and its citation, letting the patient see the basis for it. The design doctrine is radical transparency — show the source, not a badge.

Where does the provider profile data come from?

The profile backbone is CMS NPPES — the national provider registry of 6.8M+ active providers, refreshed weekly as a full-replacement file — supplying NPI, NUCC taxonomy, entity type, and practice address. Beyond identity, a profile can layer additional federal signals each with its own provenance: CMS PECOS Medicare enrollment status, CMS QPP MIPS quality scores, and the unified exclusion check across OIG LEIE, SAM.gov, and state Medicaid lists. All 44 federal source families are documented at /sources with tier, refresh cadence, and redistribution posture. The key property for a patient surface is that these signals stay attributable to distinct named sources rather than being blended into one opaque profile score — a portal can choose which federal facts to show and cite each precisely.

Does using Fonteum require handling protected health information (PHI)?

No. Fonteum carries only public provider data — the federal records published by CMS, OIG, HRSA, and others — and no patient data of any kind. A patient portal integrating Fonteum's find-a-doctor profiles or FHIR provider resources is consuming public federal record, not exchanging PHI, so the integration does not expand the portal's PHI-handling surface. This is a deliberate scoping decision: Fonteum's pilots run on public data only, with no PHI, which keeps the data-governance review narrow and the provenance chain entirely traceable to public files. A portal still owns its own patient data and its own compliance posture for that; what Fonteum adds is an auditable, source-attested provider layer that sits beside it.

Is the data free, and what does the pilot tier add?

The federal datasets behind provider profiles — CMS NPPES, PECOS, QPP MIPS, and the exclusion lists — are published openly, browsable at /providers and /npi with research datasets and CSV/JSON downloads at /research. The FHIR R4 US Core 6.1.0 API and semantic search are documented at /docs/fhir and /search. Free access reflects the doctrine that public-source federal data should stay public. The scoped pilot tier, starting at $2,500/mo, adds custom exports and embed support — for example a provider-profile feed scoped to the specialties and regions your portal serves, delivered with the field-level provenance and SourceChip metadata intact so your surface can render the citation per field. The pilot is about scoping, delivery, and integration support, not about gating access to the underlying federal record.

FONTEUM · USE CASE · PATIENT PORTALS

providers

Source-attested provider profiles, ready to embed.

Find-a-doctor profiles with field-level 14-tuple provenance over a FHIR R4 API — every fact a patient sees traces to its federal source. Public data only, no PHI.

Request access →

Federal source stack

Profiles · provenance · FHIR R4

active providers
CMS NPPES
Profile data backbone
active providers (~8M total NPI records) — NPI, NUCC taxonomy, entity type, and practice address. The federal registry behind every provider profile, so a find-a-doctor surface shows facts drawn from the authoritative source rather than scraped or hand-keyed listings.
Source documentation →
Source on every field
Field-level provenance
14-tuple attestation
Every rendered fact ties to a provider_field_provenance row carrying source name, dataset identifier, last-checked date, and documented limitation. In FHIR responses the same chain rides inline as a 14-tuple tag on each resource's meta.tag — so a patient-facing profile can show, per field, exactly where the fact came from. One of 44 federal source families feeding it.
Source documentation →
5 USCDI v3 resources
FHIR R4 US Core 6.1.0
Embeddable profile API
5 distinct USCDI v3 Provider resources — Practitioner, PractitionerRole, Organization, Location, HealthcareService — over a standards-conformant REST API. SMART Backend Services auth for system-to-system integration. The CapabilityStatement at /api/fhir/metadata is the discovery entry point for an embed.
Source documentation →

Why source provenance matters for patient surfaces

Show the source, not a badge

Every fact carries its citation

A patient making a care decision is in a YMYL context where accuracy is consequential. Fonteum attaches a to every rendered fact — source name, dataset identifier, last-checked date, limitation — and renders it as a SourceChip. A profile shows not just a provider's specialty but where that fact came from and when it was checked, which is the difference between a directory listing and an attested record.

Federal data, no PHI

Fonteum carries only public provider data drawn from and the other federal sources — no patient data of any kind. A portal embedding find-a-doctor profiles is consuming public federal record, so the integration does not expand its PHI-handling surface. Pilots run on public data only, no PHI, keeping the data-governance review narrow and every fact traceable to a public file.

Standards-conformant embed

The profile API is FHIR R4 US Core 6.1.0 — the same standard a patient portal already speaks for clinical data — exposing Practitioner, PractitionerRole, Organization, Location, and HealthcareService. SMART Backend Services auth supports unattended server-side fetches, and the 14-tuple provenance tag rides inline on each resource's meta.tag, so the citation an embed needs to render a SourceChip travels with the data rather than living in separate documentation.

How it works

From federal portal to embedded profile

Step 1 / Ingest

Ingest

Fonteum pulls directly from the federal portals on each source's native cadence — CMS NPPES as a weekly full-replacement file ( active providers), plus PECOS, QPP MIPS, and the OIG exclusion lists on their schedules. No intermediary aggregator sits between the profile and the government file, so a patient-facing fact reflects the current federal source.

Step 2 / Provenance

Provenance

Every field is written with its source name, dataset identifier, last-checked date, and documented limitation through the provider_field_provenance layer. The same chain is exposed inline as a 14-tuple provenance tag on each FHIR resource's meta.tag and rendered as a SourceChip on public surfaces — so the citation travels with the data into your portal and a patient can see, per field, where the fact came from.

Step 3 / Deliver

Deliver

Provider profiles are available free as public pages at /providers and /npi, through the FHIR R4 US Core 6.1.0 API with SMART Backend Services auth for an embed, and via semantic search at /search. No PHI is involved — Fonteum carries only public provider data. Scoped pilot feeds for a patient-facing surface start at $2,500/mo with the field-level provenance and SourceChip metadata intact.

FAQ

Common questions

What does a source-attested provider profile mean for a patient portal?: It means every fact shown on a provider profile — name, NPI, specialty, practice location — carries a record of where it came from and when it was last checked, rather than appearing as an unsourced attribute. Fonteum attaches a provider_field_provenance row to each rendered value: source name (for example CMS NPPES), dataset identifier, last-checked date, and any documented limitation of that source. Drawn from a graph of 44 federal source families, a patient portal can render the federal facts and, alongside each, a SourceChip showing the citation and date. For a patient making a care decision — a YMYL context where accuracy is consequential — that visible chain of custody is the difference between a directory listing and an attested record. Fonteum is a source-provenanced data layer over public federal data; it does not assert claims about a provider beyond what the cited federal file supports, and trust language unsupported by a is excluded by doctrine.
Can I embed Fonteum find-a-doctor data in our patient-facing surface?: Yes. Fonteum exposes provider data through a FHIR R4 US Core 6.1.0 REST API — the Practitioner, PractitionerRole, Organization, Location, and HealthcareService resources — plus semantic search at /search for natural-language find-a-doctor queries by specialty, geography, or clinical context across active NPI records. SMART Backend Services auth (a JWT client assertion signed with RS384, exchanged for a short-lived token) supports unattended server-side integration, so a portal's backend can fetch profiles without a human in the loop. The CapabilityStatement at /api/fhir/metadata enumerates the resources and search parameters an embed can use. Because the data is public federal record, an embed is not gated behind PHI-handling requirements — Fonteum carries no patient data, only public provider data — which keeps the integration surface narrow.
How does field-level provenance render for a patient?: Fonteum's signature display component is the SourceChip — a small per-field marker showing the source name, the date that field was last checked, and any limitation of the source. On a public Fonteum provider page each rendered fact carries one, and the same chain is available programmatically: in a FHIR response it rides inline as a 14-tuple provenance tag on the resource's meta.tag. A patient portal can surface this directly so a patient sees not just 'this provider's specialty is X' but 'sourced from CMS NPPES, last checked on this date.' That transparency is deliberate: rather than presenting a provider as endorsed or rated, Fonteum presents the federal fact and its citation, letting the patient see the basis for it. The design doctrine is radical transparency — show the source, not a badge.
Where does the provider profile data come from?: The profile backbone is CMS NPPES — the national provider registry of active providers, refreshed weekly as a full-replacement file — supplying NPI, NUCC taxonomy, entity type, and practice address. Beyond identity, a profile can layer additional federal signals each with its own provenance: CMS Medicare enrollment status, CMS QPP MIPS quality scores, and the unified exclusion check across OIG LEIE, SAM.gov, and state Medicaid lists. All are documented at /sources with tier, refresh cadence, and redistribution posture. The key property for a patient surface is that these signals stay attributable to distinct named sources rather than being blended into one opaque profile score — a portal can choose which federal facts to show and cite each precisely.
Does using Fonteum require handling protected health information (PHI)?: No. Fonteum carries only public provider data — the federal records published by CMS, OIG, HRSA, and others — and no patient data of any kind. A patient portal integrating Fonteum's find-a-doctor profiles or FHIR provider resources is consuming public federal record, not exchanging PHI, so the integration does not expand the portal's PHI-handling surface. This is a deliberate scoping decision: Fonteum's pilots run on public data only, with no PHI, which keeps the data-governance review narrow and the provenance chain entirely traceable to public files. A portal still owns its own patient data and its own compliance posture for that; what Fonteum adds is an auditable, source-attested provider layer that sits beside it.
Is the data free, and what does the pilot tier add?: The federal datasets behind provider profiles — CMS NPPES, PECOS, QPP MIPS, and the exclusion lists — are published openly, browsable at /providers and /npi with research datasets and CSV/JSON downloads at /research. The FHIR R4 US Core 6.1.0 API and semantic search are documented at /docs/fhir and /search. Free access reflects the doctrine that public-source federal data should stay public. The scoped pilot tier, starting at $2,500/mo, adds custom exports and embed support — for example a provider-profile feed scoped to the specialties and regions your portal serves, delivered with the field-level provenance and SourceChip metadata intact so your surface can render the citation per field. The pilot is about scoping, delivery, and integration support, not about gating access to the underlying federal record.

Request access →

Request a profile-embed pilot.

Scope a source-attested provider-profile feed for your portal. Free public data at /providers and the provenance pipeline at /data-provenance. Pilot tier from $2,500/mo.

Request access →or read the FHIR R4 docs →

FONTEUM · PILOT

Run a 90-day pilot. Public data only. No PHI.

Request access → Read the methodology

Source-attested provider profiles, ready to embed.

Find-a-doctor profiles with field-level 14-tuple provenance over a FHIR R4 API — every fact a patient sees traces to its federal source. Public data only, no PHI.

Request access →

Federal source stack

Profiles · provenance · FHIR R4

active providers
CMS NPPES
Profile data backbone
active providers (~8M total NPI records) — NPI, NUCC taxonomy, entity type, and practice address. The federal registry behind every provider profile, so a find-a-doctor surface shows facts drawn from the authoritative source rather than scraped or hand-keyed listings.
Source documentation →
Source on every field
Field-level provenance
14-tuple attestation
Every rendered fact ties to a provider_field_provenance row carrying source name, dataset identifier, last-checked date, and documented limitation. In FHIR responses the same chain rides inline as a 14-tuple tag on each resource's meta.tag — so a patient-facing profile can show, per field, exactly where the fact came from. One of 44 federal source families feeding it.
Source documentation →
5 USCDI v3 resources
FHIR R4 US Core 6.1.0
Embeddable profile API
5 distinct USCDI v3 Provider resources — Practitioner, PractitionerRole, Organization, Location, HealthcareService — over a standards-conformant REST API. SMART Backend Services auth for system-to-system integration. The CapabilityStatement at /api/fhir/metadata is the discovery entry point for an embed.
Source documentation →

Why source provenance matters for patient surfaces

Show the source, not a badge

Every fact carries its citation

Federal data, no PHI

Standards-conformant embed

How it works

From federal portal to embedded profile

Step 1 / Ingest

Ingest

Step 2 / Provenance

Provenance

Step 3 / Deliver

Deliver

FAQ

Common questions

What does a source-attested provider profile mean for a patient portal?: It means every fact shown on a provider profile — name, NPI, specialty, practice location — carries a record of where it came from and when it was last checked, rather than appearing as an unsourced attribute. Fonteum attaches a provider_field_provenance row to each rendered value: source name (for example CMS NPPES), dataset identifier, last-checked date, and any documented limitation of that source. Drawn from a graph of 44 federal source families, a patient portal can render the federal facts and, alongside each, a SourceChip showing the citation and date. For a patient making a care decision — a YMYL context where accuracy is consequential — that visible chain of custody is the difference between a directory listing and an attested record. Fonteum is a source-provenanced data layer over public federal data; it does not assert claims about a provider beyond what the cited federal file supports, and trust language unsupported by a is excluded by doctrine.
Can I embed Fonteum find-a-doctor data in our patient-facing surface?: Yes. Fonteum exposes provider data through a FHIR R4 US Core 6.1.0 REST API — the Practitioner, PractitionerRole, Organization, Location, and HealthcareService resources — plus semantic search at /search for natural-language find-a-doctor queries by specialty, geography, or clinical context across active NPI records. SMART Backend Services auth (a JWT client assertion signed with RS384, exchanged for a short-lived token) supports unattended server-side integration, so a portal's backend can fetch profiles without a human in the loop. The CapabilityStatement at /api/fhir/metadata enumerates the resources and search parameters an embed can use. Because the data is public federal record, an embed is not gated behind PHI-handling requirements — Fonteum carries no patient data, only public provider data — which keeps the integration surface narrow.
How does field-level provenance render for a patient?: Fonteum's signature display component is the SourceChip — a small per-field marker showing the source name, the date that field was last checked, and any limitation of the source. On a public Fonteum provider page each rendered fact carries one, and the same chain is available programmatically: in a FHIR response it rides inline as a 14-tuple provenance tag on the resource's meta.tag. A patient portal can surface this directly so a patient sees not just 'this provider's specialty is X' but 'sourced from CMS NPPES, last checked on this date.' That transparency is deliberate: rather than presenting a provider as endorsed or rated, Fonteum presents the federal fact and its citation, letting the patient see the basis for it. The design doctrine is radical transparency — show the source, not a badge.
Where does the provider profile data come from?: The profile backbone is CMS NPPES — the national provider registry of active providers, refreshed weekly as a full-replacement file — supplying NPI, NUCC taxonomy, entity type, and practice address. Beyond identity, a profile can layer additional federal signals each with its own provenance: CMS Medicare enrollment status, CMS QPP MIPS quality scores, and the unified exclusion check across OIG LEIE, SAM.gov, and state Medicaid lists. All are documented at /sources with tier, refresh cadence, and redistribution posture. The key property for a patient surface is that these signals stay attributable to distinct named sources rather than being blended into one opaque profile score — a portal can choose which federal facts to show and cite each precisely.
Does using Fonteum require handling protected health information (PHI)?: No. Fonteum carries only public provider data — the federal records published by CMS, OIG, HRSA, and others — and no patient data of any kind. A patient portal integrating Fonteum's find-a-doctor profiles or FHIR provider resources is consuming public federal record, not exchanging PHI, so the integration does not expand the portal's PHI-handling surface. This is a deliberate scoping decision: Fonteum's pilots run on public data only, with no PHI, which keeps the data-governance review narrow and the provenance chain entirely traceable to public files. A portal still owns its own patient data and its own compliance posture for that; what Fonteum adds is an auditable, source-attested provider layer that sits beside it.
Is the data free, and what does the pilot tier add?: The federal datasets behind provider profiles — CMS NPPES, PECOS, QPP MIPS, and the exclusion lists — are published openly, browsable at /providers and /npi with research datasets and CSV/JSON downloads at /research. The FHIR R4 US Core 6.1.0 API and semantic search are documented at /docs/fhir and /search. Free access reflects the doctrine that public-source federal data should stay public. The scoped pilot tier, starting at $2,500/mo, adds custom exports and embed support — for example a provider-profile feed scoped to the specialties and regions your portal serves, delivered with the field-level provenance and SourceChip metadata intact so your surface can render the citation per field. The pilot is about scoping, delivery, and integration support, not about gating access to the underlying federal record.

Request access →

Request a profile-embed pilot.

Scope a source-attested provider-profile feed for your portal. Free public data at /providers and the provenance pipeline at /data-provenance. Pilot tier from $2,500/mo.

Request access →or read the FHIR R4 docs →

FONTEUM · PILOT

Run a 90-day pilot. Public data only. No PHI.

Request access → Read the methodology