Cloud-native FHIR hosting reduces operational burden substantially for health plans that do not have strong on-premise infrastructure or specific data-residency requirements. The major cloud providers all offer FHIR services with varying depth and CMS-0057-F-specific capability. Five options dominate the cloud-native category for US health payers in 2026. For related FHIR infrastructure guides on this site, these are the practical choices.
What "Cloud-Native" Actually Means for FHIR
A cloud-native FHIR service is a managed offering where the cloud provider runs the FHIR engine, data tier, and operational infrastructure. The payer integrates against the FHIR API surface but does not operate the underlying servers, databases, or scaling logic. Patching, monitoring, and infrastructure-level operations are the cloud provider's responsibility.
The contrast is with self-hosted FHIR (running Smile CDR, HAPI FHIR, InterSystems IRIS, or others on infrastructure the payer manages). Self-hosted offers more control; cloud-native offers less operational burden.
1. Microsoft Azure Health Data Services (FHIR Service)
Microsoft Azure Health Data Services provides a fully managed FHIR-conformant service. The platform supports FHIR R4, Bulk Data Access, SMART App Launch, and integrates with Azure Active Directory for authentication. For US payers running on Azure broadly, the integration with other Azure services (Synapse for analytics, AKS for application hosting) is clean.
The FHIR-specific tooling is somewhat thinner than at dedicated payer-interoperability vendors. The platform handles the FHIR engine well; CMS-0057-F-specific features (Provider Directory PDex Plan Net conformance, CARIN BB v2.0.0 profile sets, Da Vinci ePA stack) may require additional configuration or third-party tooling on top.
2. AWS HealthLake
AWS HealthLake provides managed FHIR-conformant storage and APIs as part of the AWS healthcare suite. The platform integrates with other AWS services (S3, Comprehend Medical for NLP, SageMaker for ML, Athena for analytics). For US payers running on AWS, the same patterns apply as for Azure customers running on Microsoft.
HealthLake handles the FHIR engine and the data tier; CMS-0057-F-specific work (Provider Access Bulk Data export at payer scale, Payer-to-Payer Member Match, Da Vinci ePA) often requires additional tooling.
3. Google Cloud Healthcare API
Google Cloud Healthcare API provides managed FHIR storage and access as part of GCP. The platform integrates with BigQuery for analytics, Vertex AI for ML, and other GCP services. Adoption among US payers is smaller than Azure or AWS but growing.
The FHIR engine is competent. CMS-0057-F-specific features are less mature than at the Azure or AWS equivalents; payers running on GCP often need to pair the FHIR service with third-party tooling for the full CMS-0057-F stack.
4. Smile Digital Health (Cloud-Hosted SaaS)
Smile Digital Health offers Smile CDR as a cloud-hosted SaaS deployment in addition to the on-premise option. The cloud-hosted offering provides the full Smile CDR feature set (FHIR-native data tier, CMS-0057-F APIs, ePA stack, Member Match, Bulk Data) without the on-premise operational responsibility. The hosting cloud is typically AWS but configurable.
This option fits payers that want the depth of Smile's FHIR-native capability with the operational simplicity of managed hosting.
5. 1upHealth Cloud Platform
1upHealth runs entirely as a cloud-native SaaS. The platform handles FHIR data, all four CMS-0057-F APIs, Member Match, Bulk Data, and the ePA stack. The deployment model is multi-tenant cloud with PMPM pricing. For payers without on-premise infrastructure requirements, 1upHealth offers a fast onboarding path.
The trade-off is that 1upHealth's cloud architecture is the only deployment model; payers requiring on-premise have to look elsewhere.
How to Pick the Cloud Hosting Path
The choice usually comes down to four factors. Existing cloud relationships (Azure customer, AWS customer, GCP customer, multi-cloud). Depth of CMS-0057-F-specific capability needed (do payer-interop-vendor features matter, or is the FHIR engine sufficient). Pricing model preference (PMPM, flat subscription, consumption-based). Time-to-deployment requirements (3-6 month versus longer).
For the contrast with on-premise hosting models that fit different deployment requirements, the Best on-premise FHIR platforms for regulated payer deployments covers the alternative. For the broader cloud-vs-self-hosted decision, the Cloud-Hosted vs Self-Hosted FHIR platforms for CMS-0057-F comparison covers the trade-offs.