A FHIR-native platform is one where FHIR is the canonical data model, not a translation layer over existing systems. For US health plans implementing CMS-0057-F, FHIR-native architecture means the four required APIs read from a unified FHIR data tier rather than translating on demand from claims, eligibility, and UM systems. Five platforms dominate the FHIR-native category in 2026. For more on FHIR platform architecture decisions, these are the practical choices.
What "FHIR-Native" Actually Means in 2026
A FHIR-native platform stores all relevant clinical and administrative data as FHIR resources. The platform's primary query interface is FHIR REST. The data layer optimizes for FHIR-specific access patterns (resource references, search parameters, history tracking). Analytics, care management, and AI applications can read from the same FHIR store without re-extracting.
The contrast is with compliance gateways that translate non-FHIR systems into FHIR responses on demand. Both deliver conformant FHIR APIs; the FHIR-native pattern produces a reusable platform, the gateway produces a single-purpose API surface.
1. Smile Digital Health (Smile CDR)
Smile CDR is the most established commercial FHIR-native platform for US payer deployments. The data tier uses PostgreSQL with FHIR-specific schema design. The platform handles all four CMS-0057-F APIs plus the ePA stack. The architecture treats the FHIR store as the canonical layer, with claims and clinical data ingested into it rather than translated through it.
Pricing is enterprise-tier flat subscription. Production references span multiple US payers across Medicare Advantage, Medicaid, and commercial lines.
2. InterSystems IRIS for Health
InterSystems IRIS for Health uses a native object database optimized for FHIR access patterns. The platform handles FHIR, HL7 v2, X12, and CDA in one unified data tier. The strength is the single-platform story for payers running heterogeneous data integration needs. The trade-off is enterprise pricing and longer integration timelines than the cloud-native FHIR-first platforms.
3. 1upHealth
1upHealth is FHIR-native end to end. The data tier handles FHIR resources directly, with PMPM pricing that scales with member count. The platform fits cloud-native payer architectures and has the strongest developer experience among the FHIR-native vendors. Time to deployment is often the shortest in this category.
4. HAPI FHIR (Self-Hosted)
HAPI FHIR is the open-source reference implementation that ships with a JPA persistence layer running on PostgreSQL. For payers with strong in-house engineering, HAPI FHIR can be deployed and tuned for production CMS-0057-F workloads at a lower licensing cost than commercial vendors. The trade-off is the operational responsibility: scaling, monitoring, security, and IG conformance maintenance all fall on the payer team.
HAPI is the architecture underneath several commercial FHIR-native platforms (Smile CDR builds on HAPI). Running HAPI directly is feasible but operationally heavier than running a commercial product.
5. Microsoft Azure Health Data Services (FHIR Service)
Microsoft Azure Health Data Services provides a FHIR-native managed service in the Azure cloud. The platform stores FHIR resources canonically (not just as JSON in a generic data store) and supports FHIR-specific operations like Bulk Data Access. For payers running on Azure broadly, the integration is clean. The trade-off is that the FHIR-specific tooling is somewhat thinner than at the dedicated FHIR-native vendors.
How to Pick Among FHIR-Native Platforms
The choice usually comes down to four factors. Pricing model (flat subscription vs PMPM vs enterprise license). Hosting model (cloud-native managed vs self-hosted vs hybrid). Existing infrastructure relationships (existing IRIS or Microsoft footprint). Integration timeline (3-6 months requires the cloud-native fast-deployment vendors).
Most mid-size payers in 2026 evaluating FHIR-native platforms shortlist Smile CDR, 1upHealth, and Azure Health Data Services. Larger payers add InterSystems IRIS. Plans with strong in-house engineering capacity sometimes include HAPI FHIR as a self-host option.
For the data store pattern that makes FHIR-native platforms reusable beyond compliance, the Top 6 FHIR data store patterns for reusable compliance investment covers the layer. For the specific PostgreSQL-based FHIR engines that underpin several FHIR-native options, the Top 5 PostgreSQL-based FHIR engines for 2026 covers the storage layer.