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 →Federal sources · FHIR R4 · Bulk export
- federal source families
22 Federal Source Families
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.
- 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.
- 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.
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 the upstream data layer for that obligation, drawing directory entries from CMS NPPES ( active providers, weekly full-replacement) so each is traceable to its authoritative federal record. 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.
federal source families with explicit dataset citations
Every data point in Fonteum traces to a named federal dataset with an explicit source citation — CMS dataset identifier, OIG HHS file path, or HRSA data portal URL — all of which are US Government Works in the public domain under 17 U.S.C. § 105. For federal IT contracts that require an auditable primary-source provenance chain, Fonteum provides the complete citation: source name · dataset ID · download date · methodology version. That covers screening against the OIG LEIE ( excluded parties, monthly) and ownership analysis from CMS SNF All Owners ( ownership rows). The registry at /sources documents redistribution posture and terms for each of the source families.
Ingest · Provenance · Deliver
Pull directly from federal data portals
Fonteum re-pulls each of the federal source families on its own native cadence — CMS NPPES as a weekly full-replacement file ( active providers), OIG LEIE monthly from oig.hhs.gov/exclusions/, PECOS and Care Compare on their published refresh schedules. For a federal integration, that means the directory or screening data behind your deliverable reflects the same currency a CMS or OIG reviewer sees in the original portal file.
Attach source, date, and limitation to every field
Each rendered fact ties to a provider_field_provenance row recording source name, last-checked date, and known limitation, which references a named federal dataset. The same chain is exposed inline as a 14-tuple provenance tag on each FHIR resource's meta.tag, so the citation travels with the data into your contract-compliance documentation rather than living in a separate spreadsheet a reviewer has to reconcile by hand.
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.
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's data is sourced from public federal records — CMS, OIG HHS, HRSA, BLS, and Census — that are themselves US Government Works in the public domain under 17 U.S.C. § 105, meaning the underlying records carry no federal copyright restriction on redistribution. The source citations and methodology are documented publicly at /sources and /methodology. For federal IT contracts that require an auditable primary-source data layer behind provider directories, credentialing, or compliance screening, Fonteum attaches a complete citation chain to every rendered field: source name, dataset identifier, download date, and methodology version. That chain is the artifact contracting officers and auditors ask for when a deliverable has to be traced back to its authoritative origin. Because Fonteum re-pulls each source on its native federal cadence — NPPES weekly, OIG LEIE monthly — the contract-compliance documentation reflects the same currency a CMS or OIG reviewer would see in the original file.
- What federal data sources does Fonteum ingest?
- federal source families: CMS NPPES (the NPI registry, active providers from roughly 8M total records, refreshed as a weekly full-replacement file), CMS PECOS (enrollment), CMS Care Compare (8 facility modules including Nursing Home, Home Health, Hospice, Dialysis, and ASC), CMS PBJ Daily Nurse Staffing ( daily records per quarter across 14,537 facilities), CMS SNF All Owners ( ownership rows across 14,425 facilities), CMS Provider of Services (POS iQIES), OIG LEIE ( excluded individuals and entities, refreshed monthly from oig.hhs.gov/exclusions/), HRSA HPSA (shortage-area designations), HRSA UDS (FQHC sites), CMS QPP MIPS (quality scores), CMS HCRIS (hospital cost reports), CMS Medicare Provider Utilization, BLS OEWS, BEA Regional, and Census PEP. Each family is documented at /sources with its tier, refresh cadence, jurisdiction coverage, and redistribution posture so an integrating contractor can confirm terms before relying on it in a deliverable.
- 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 the upstream primary-source 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. Because the data originates from CMS NPPES ( active providers, weekly full-replacement) and PECOS enrollment files, a contractor populating a payer's Provider Directory API can trace each entry to its authoritative federal record rather than a scraped or hand-keyed source. The 14-tuple provenance tag carried on each FHIR resource's meta.tag records the source, dataset identifier, last-checked date, and methodology version, which is the evidence a CMS reviewer or contract auditor needs to confirm the directory was assembled from authoritative public records.
- What does the auditable citation chain look like for a federal deliverable?
- Every rendered field in Fonteum ties to a row in the provider_field_provenance layer, which in turn references a named federal data source. The chain a contractor can document for contract compliance is four parts: source name (for example, CMS NPPES or OIG LEIE), dataset identifier or file path, the date that field was last checked against the federal portal, and the methodology version pinned at extraction. For FHIR consumers the same chain is exposed inline as a 14-tuple provenance tag on each resource's meta.tag, so the citation travels with the data into a downstream system rather than living only in separate documentation. This matters for screening workflows in particular: an OIG LEIE exclusion check ( excluded parties, refreshed monthly) is only defensible if the contractor can show which monthly file the determination was made against. Fonteum records that, so the deliverable's provenance is reproducible from the public CMS and OIG files at any later date.
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.
- /docs/fhir → FHIR R4 US Core 6.1.0 endpoint reference and CapabilityStatement.
- /docs/bulk-export → HL7 Bulk Data Access $export endpoint reference.
- /sources → 22 federal source families — tier, cadence, redistribution posture.
- /use-cases/healthcare-analytics → Healthcare provider data for analytics teams.