Profiles · provenance · FHIR R4
- active providers
CMS NPPES
Profile data backbone
active NPI records (8.9M total records) with available taxonomy, enumeration type, and submitted address fields. NPPES is the assigning source for NPIs, but its administrative fields do not establish licensure, credentialing, or appointment availability.
- Nullable source metadata
Field-level provenance
Source metadata
Provider responses can include source, observation-date, and limitation fields. Coverage varies by resource and field, and a missing provenance value must not be inferred. The active production registry does not establish loaded, complete, or fresh coverage.
- 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.
Show the source, not a badge
Show available citations
A patient making a care decision is in a YMYL context where accuracy is consequential. Fonteum renders source, observation-date, and limitation metadata as a SourceChip when the selected field supplies those values. Coverage varies by field; an absent value is not presented as an attestation.
Federal data, no PHI
Fonteum carries public provider records drawn from and other public sources, not patient records. A portal remains responsible for its own patient data and compliance posture.
Standards-conformant embed
The FHIR R4 surface exposes Practitioner, PractitionerRole, Organization, Location, and HealthcareService resources. Resource metadata can carry source and observation fields where populated; the CapabilityStatement does not establish universal provenance coverage.
From federal portal to embedded profile
Ingest
Publisher cadence and loaded dates are separate. In the July 12 production audit, NPPES had a June 10, 2026 newest system date, PECOS had a June 18 source date, and OIG LEIE had a May 8 source date. These observations do not establish that a scheduled refresh completed after those dates.
Provenance
Source, observation-date, and limitation metadata is exposed where the resource supplies it. Those fields are nullable and vary by endpoint; a missing value is not evidence of a completed check or cryptographic linkage.
Deliver
Provider profiles are available at /providers and /npi, through the FHIR R4 surface, and via semantic search at /search. Scoped pilot feeds start at $2,500/mo; source metadata varies by selected field and response.
Common questions
- What does a public-source provider profile mean for a patient portal?
- It means the profile displays fields drawn from named public datasets, with source and observation metadata where a response supplies it. That metadata is nullable and varies by field. A patient portal should display the available citation and limitations, and should not treat an absent provenance value as an attestation. Fonteum does not endorse or rate a provider.
- 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 uses a SourceChip to display source, observation-date, and limitation metadata when those values are available. Coverage is not universal across provider fields or FHIR resources. A portal can render the supplied metadata, but should not invent a citation or date when the response leaves it null.
- Where does the provider profile data come from?
- The profile backbone is CMS NPPES, published by CMS as a weekly full-replacement file; Fonteum's newest observed production system date was June 10, 2026. Profiles can also expose loaded , QPP MIPS, and exclusion records. The exclusion check includes supported loaded state Medicaid lists; the other states are not covered. Source and observation metadata varies by signal and response.
- Does using Fonteum require handling protected health information (PHI)?
- Fonteum's provider layer uses public records and does not carry patient records. A portal still owns its own patient data and compliance posture. Fonteum responses can include source and observation metadata, but that metadata varies by field and is not a universal attestation.
- Is the data free, and what does the pilot tier add?
- Public provider records are browsable at /providers and /npi, with research downloads at /research. The scoped pilot tier, starting at $2,500/mo, adds custom exports and embed support. SourceChip metadata is included only where the selected response supplies source and observation fields.
Request a profile-embed pilot.
Scope a provider-profile feed with available source metadata for your portal. Free public data at /providers and the provenance pipeline at /data-provenance. Pilot tier from $2,500/mo.
- /providers → Provider profiles with available source metadata — the public find-a-doctor surface.
- /data-provenance → Field-level 14-tuple provenance pipeline.
- /docs/fhir → FHIR R4 US Core 6.1.0 endpoint reference and CapabilityStatement.
- /use-cases/telehealth → NPI, specialty, and shortage-area data for cross-jurisdiction care.