Does Fonteum's FHIR R4 API support SMART Backend Services authentication?

Yes. Fonteum's FHIR R4 US Core 6.1.0 implementation supports SMART Backend Services — the SMART App Launch Framework Backend Services profile — for unattended system-to-system integrations. The pattern is a JSON Web Token (JWT) client assertion signed with RS384, exchanged at the token endpoint for a short-lived bearer access token; no interactive user login is involved, which is what server-side ETL and credentialing pipelines require. This is the auth profile expected for integrations with CMS, VA, and OIG systems that mandate SMART-on-FHIR conformance. The CapabilityStatement at /api/fhir/metadata declares the supported auth flows in its security extension, so a consuming system can discover the token endpoint and scopes programmatically before exchanging credentials. All five USCDI v3 Provider resources — Practitioner, Organization, Location, PractitionerRole, and HealthcareService — are reachable through the same authenticated REST surface and through the asynchronous HL7 Bulk Data Access ($export) endpoint for large extracts.

Is Fonteum's provider data suitable for federal procurement contracts?

Fonteum publishes records from named public sources and exposes available source, date, and methodology metadata. Coverage and provenance fields vary by source. Publisher cadence is documented separately from loaded dates; Fonteum does not claim its serving tables always match the newest agency file.

What federal data sources does Fonteum ingest?

The documented healthcare catalog includes CMS NPPES, PECOS, Care Compare modules, PBJ staffing, SNF All Owners, POS iQIES, OIG LEIE, HRSA, QPP MIPS, HCRIS, Medicare Provider Utilization, BLS, BEA, and Census pages. Each page reports publisher cadence, loaded observation where available, jurisdiction coverage, and redistribution posture. Catalog presence is not proof of a loaded or fresh dataset.

Does Fonteum have a CapabilityStatement for its FHIR R4 API?

Yes. The CapabilityStatement — the FHIR conformance resource — is served at /api/fhir/metadata, the standard discovery endpoint that Epic, Cerner, and athenahealth probe first during any integration. It enumerates all five supported USCDI v3 Provider resource types (Practitioner, Organization, Location, PractitionerRole, HealthcareService), the supported search parameters for each, and the SMART Backend Services auth profile in the security extension. The endpoint returns application/fhir+json and is reachable without authentication for capability discovery, which lets a consuming system negotiate its integration before exchanging any credentials. The description field uses the phrase "5 distinct" USCDI v3 Provider resources rather than a hardcoded ratio, so the conformance statement stays accurate if the resource set changes. For government contractors building against CMS-9115-F obligations, this is the document that demonstrates standards conformance to a technical reviewer.

How does Fonteum help contractors meet the CMS Interoperability and Patient Access Final Rule (CMS-9115-F)?

CMS-9115-F, the Interoperability and Patient Access Final Rule, requires CMS-regulated payers to expose provider directory data through a standards-based FHIR R4 US Core API. Fonteum is built to serve as an upstream public-record data layer for that obligation: all five USCDI v3 Provider resources are implemented against US Core 6.1.0, reachable via REST and via HL7 Bulk Data Access ($export) for large directory loads. The source data includes CMS NPPES (6.8M+ active providers; newest serving-table system timestamp June 10 when checked July 12, 2026) and PECOS enrollment files. Where a resource carries a provenance tag, it records the named source, dataset identifier, last-checked date, and methodology version for review.

FONTEUM · USE CASE · GOVERNMENT CONTRACTORS

LEIE exclusions

Federal healthcare data, auditable to the original record.

FHIR R4 US Core 6.1.0, SMART Backend Services auth, and HL7 Bulk Data Access for CMS, VA, and OIG integrations.

Request access →

Technical stack

Federal sources · FHIR R4 · Bulk export

Documented federal-source catalog
the documented federal-source catalog
Primary-source data layer
CMS NPPES ( active providers), PECOS, Care Compare (8 modules), PBJ Daily Nurse Staffing ( daily records/quarter), SNF All Owners ( ownership rows), POS iQIES, OIG LEIE ( excluded parties), HRSA HPSA, HRSA UDS, CMS QPP MIPS, CMS HCRIS, BLS OEWS, Census — all with explicit federal dataset citations.
Documentation →
5 USCDI v3 resources
FHIR R4 US Core 6.1.0
Standards-conformant API
5 USCDI v3 Provider resources: Practitioner, Organization, Location, PractitionerRole, HealthcareService. CapabilityStatement at /api/fhir/metadata. SMART Backend Services auth for system-to-system integrations.
Documentation →
Async NDJSON $export
HL7 Bulk Data Access
$export endpoint
Async NDJSON bulk export via HL7 FHIR R4 Bulk Data Access ($export). Inngest-backed job queue, status polling, SMART Backend Services auth. Designed for large-scale government data pipelines.
Documentation →

Built for federal integration patterns

Standards-conformant. Primary-source. Auditable.

FHIR R4 US Core 6.1.0 — full USCDI v3 Provider conformance

Fonteum implements all 5 USCDI v3 Provider resources defined in US Core 6.1.0: Practitioner, Organization, Location, PractitionerRole, and HealthcareService. The CMS Interoperability and Patient Access Final Rule (CMS-9115-F) requires CMS-regulated payers to expose provider directory data via FHIR R4 US Core; Fonteum's implementation is an upstream data layer for that obligation, drawing directory entries from CMS NPPES ( active providers; newest serving-table system timestamp June 10 when checked July 12, 2026). The CapabilityStatement at /api/fhir/metadata enumerates all five resources for technical review.

SMART Backend Services for system-to-system integrations

Government contractor integrations with CMS systems typically require SMART App Launch Backend Services auth — JSON Web Token (JWT) assertions signed with RS384, exchanged for a short-lived access token. Fonteum's FHIR R4 endpoints support this profile. The CapabilityStatement at /api/fhir/metadata enumerates the supported auth flows in the security extension, which is the discovery entry point for Epic, Cerner, and athenahealth integrations.

Documented federal-source pages with dataset-specific citations

Records with available provenance can cite a named federal dataset. The citation fields vary by response. The OIG LEIE serving table held rows from the May 8 source release when checked July 12, 2026. The /sources catalog documents redistribution posture where recorded; it does not establish loaded coverage.

How it works

Ingest · Provenance · Deliver

Step 1 / Ingest

Pull directly from federal data portals

Load named agency files and report the source release or observation date that is actually present. A configured weekly, monthly, or quarterly schedule is not proof that the serving table matches the agency's newest file.

Step 2 / Provenance

Carry available source, date, and limitation metadata

Where field-level provenance is present, it records the source name, loaded release or observation date, and known limitation. FHIR resources expose the available chain inline in meta.tag so the citation can travel with the data into contract-compliance documentation.

Step 3 / Deliver

Standards-conformant access for integration

Consume it through free public research datasets, the FHIR R4 US Core 6.1.0 REST API with SMART Backend Services auth (JWT/RS384), the HL7 Bulk Data Access NDJSON $export for large directory loads, or the researcher API. Scoped pilot exports for production federal pipelines start at $2,500/mo. The CapabilityStatement at /api/fhir/metadata is the discovery entry point your technical reviewers probe first.

Procurement glossary

Federal contracting terms used in the source stack.

FAQ

Common questions

Does Fonteum's FHIR R4 API support SMART Backend Services authentication?: Yes. Fonteum's FHIR R4 US Core 6.1.0 implementation supports SMART Backend Services — the SMART App Launch Framework Backend Services profile — for unattended system-to-system integrations. The pattern is a JSON Web Token (JWT) client assertion signed with RS384, exchanged at the token endpoint for a short-lived bearer access token; no interactive user login is involved, which is what server-side ETL and credentialing pipelines require. This is the auth profile expected for integrations with CMS, VA, and OIG systems that mandate SMART-on-FHIR conformance. The CapabilityStatement at /api/fhir/metadata declares the supported auth flows in its security extension, so a consuming system can discover the token endpoint and scopes programmatically before exchanging credentials. All five USCDI v3 Provider resources — Practitioner, Organization, Location, PractitionerRole, and HealthcareService — are reachable through the same authenticated REST surface and through the asynchronous HL7 Bulk Data Access ($export) endpoint for large extracts.
Is Fonteum's provider data suitable for federal procurement contracts?: Fonteum publishes records from named public sources and exposes available source, date, and methodology metadata. Coverage and provenance fields vary by source. Publisher cadence is documented separately from loaded dates; Fonteum does not claim its serving tables always match the newest agency file.
What federal data sources does Fonteum ingest?: The documented healthcare catalog includes CMS NPPES, PECOS, Care Compare modules, PBJ staffing, SNF All Owners, POS iQIES, OIG LEIE, HRSA, QPP MIPS, HCRIS, Medicare Provider Utilization, BLS, BEA, and Census pages. Each page reports publisher cadence, loaded observation where available, jurisdiction coverage, and redistribution posture. Catalog presence is not proof of a loaded or fresh dataset.
Does Fonteum have a CapabilityStatement for its FHIR R4 API?: Yes. The CapabilityStatement — the FHIR conformance resource — is served at /api/fhir/metadata, the standard discovery endpoint that Epic, Cerner, and athenahealth probe first during any integration. It enumerates all five supported USCDI v3 Provider resource types (Practitioner, Organization, Location, PractitionerRole, HealthcareService), the supported search parameters for each, and the SMART Backend Services auth profile in the security extension. The endpoint returns application/fhir+json and is reachable without authentication for capability discovery, which lets a consuming system negotiate its integration before exchanging any credentials. The description field uses the phrase "5 distinct" USCDI v3 Provider resources rather than a hardcoded ratio, so the conformance statement stays accurate if the resource set changes. For government contractors building against CMS-9115-F obligations, this is the document that demonstrates standards conformance to a technical reviewer.
How does Fonteum help contractors meet the CMS Interoperability and Patient Access Final Rule (CMS-9115-F)?: CMS-9115-F, the Interoperability and Patient Access Final Rule, requires CMS-regulated payers to expose provider directory data through a standards-based FHIR R4 US Core API. Fonteum is built to serve as an upstream public-record data layer for that obligation: all five USCDI v3 Provider resources are implemented against US Core 6.1.0, reachable via REST and via HL7 Bulk Data Access ($export) for large directory loads. The source data includes CMS NPPES ( active providers; newest serving-table system timestamp June 10 when checked July 12, 2026) and PECOS enrollment files. Where a resource carries a provenance tag, it records the named source, dataset identifier, last-checked date, and methodology version for review.
What does the auditable citation chain look like for a federal deliverable?: For records that carry field-level provenance, a contractor can document four parts: source name (for example, CMS NPPES or OIG LEIE), dataset identifier or file path, the loaded release or observation date, and the methodology version used at extraction. FHIR resources expose the available chain inline in meta.tag. The loaded OIG LEIE table held a May 8 source date when checked July 12, 2026. That identifies the release used for a screening result; it does not promise that every source can be replayed on any later date. Retained row history is source-specific.

Request access

Review the technical documentation.

FHIR R4 reference at /docs/fhir. Bulk export at /docs/bulk-export. Source registry at /sources. Pilot tier from $2,500/mo.

Request access →or view the CapabilityStatement →

FONTEUM · PILOT

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

Request access → Read the methodology