FHIR platform architecture is the part of CMS-0057-F that gets less attention than the API endpoints but determines more of the long-term cost and capability. The choice of platform architecture shapes what the payer's compliance investment becomes after January 2027. A FHIR-native data store with reusable infrastructure becomes a clinical data platform. A compliance gateway optimized only for API delivery becomes a single-purpose appliance. The two paths diverge sharply in year three of the deployment, even when they look similar at go-live. This guide lays out the architecture decisions worth thinking about carefully for the FHIR architecture knowledge base on this site.
The Architectural Fork That Defines Everything Else
The first decision is whether FHIR is the canonical data layer or a translation surface. A FHIR-native architecture stores claims, EOBs, clinical data, provider directory entries, attribution, and Prior Auth decisions as FHIR resources in one data tier. APIs read from this tier. Analytics, care management, and AI applications read from the same tier.
A compliance gateway architecture treats existing systems as the records of truth and uses FHIR only as a public API surface. Claims live in the claims platform. Eligibility lives in the eligibility platform. The FHIR APIs translate on demand, often without persisting the FHIR representation.
Both approaches deliver CMS-0057-F conformance. They produce very different stacks afterward. For deeper coverage of this fork, the FHIR-Native vs Compliance Gateway architectural trade-offs comparison covers the choice in depth.
The Hosting Model Decision
After the canonical-vs-gateway choice, the next decision is hosting. Cloud-native managed services (AWS HealthLake, Microsoft Azure Health Data Services, Google Cloud Healthcare API) offer minimal operational burden at the cost of less control over the data tier and the underlying infrastructure. Self-hosted platforms (Smile CDR, InterSystems IRIS, 1upHealth on-prem, HAPI FHIR) offer more control at the cost of operational responsibility.
For most mid-market payers in 2026, the cloud-native path is the default unless specific compliance, regulatory, or data-residency requirements push toward self-hosting. The trade-off lands differently for larger payers with strong in-house engineering capacity.
For specific cloud options, the Top 5 cloud-native FHIR hosting options for US health payers covers the leaders. For on-premise options, the Best on-premise FHIR platforms for regulated payer deployments covers the choices.
The Storage Layer Choice
For self-hosted FHIR platforms, the storage layer choice matters substantially. PostgreSQL-based FHIR engines (Smile CDR, HAPI FHIR with JPA persistence) leverage decades of relational database optimization and operational tooling. Native FHIR engines (InterSystems IRIS Object Model, some specialty engines) optimize for FHIR-specific access patterns at the cost of less ecosystem support.
PostgreSQL has become the default storage choice for FHIR in 2026. The JSONB column type handles FHIR resources cleanly. The query optimizer handles FHIR search semantics with reasonable performance. The ecosystem tooling (backup, monitoring, replication, scaling) is mature.
The Multi-Tenancy Question for Health Plans
Multi-tenant FHIR hosting is a specific architectural decision for payers that serve multiple lines of business (Medicare Advantage plus Medicaid plus commercial), multiple delegated entities (specialty benefit managers, behavioral health carve-outs), or multiple state markets. The decision affects how data isolation, consent management, and audit trails work.
Strong multi-tenant FHIR platforms isolate tenants at the data layer rather than the application layer. A delegated entity accessing the platform sees only its own data; the isolation is enforced by the platform, not by the application code.
The Capability That Determines Year-Three Value
The capability that matters most three years into a CMS-0057-F deployment is whether the FHIR data store powers anything beyond compliance. Plans whose investment becomes a clinical data platform have substantial leverage for analytics, care management, AI, and population health. Plans whose investment stays a compliance gateway have to make a second platform investment when these needs emerge.
The architectural choices made at go-live constrain what is possible later. Plans that invest in FHIR-native architecture buy optionality. Plans that invest in compliance gateways buy a fixed-purpose appliance.