Azure API for FHIR retires September 2026. What healthcare teams need to know about their gateway stack.

Microsoft announced that Azure API for FHIR will be retired on September 30, 2026. New deployments have been blocked since April 2025. Healthcare organisations running on Azure API for FHIR are mid-migration — to Azure Health Data Services, to HAPI FHIR, or to another self-hosted option.

The migration is a natural forcing function to evaluate what sits in front of your FHIR server. Most teams have a FHIR server. Fewer have a proper gateway layer that handles authentication, access control, audit logging, and data residency in a way that satisfies HIPAA and their internal security requirements.

This is the checklist you need.

What a FHIR API gateway layer must do

SMART on FHIR and OAuth 2.0 / OIDC token validation. SMART on FHIR is the de facto standard for healthcare app authorization. It defines how applications request access to patient resources using OAuth 2.0 and OpenID Connect, with scope-based access control at the resource level.

Your gateway needs to validate SMART tokens — checking that the token was issued by a trusted identity provider, that the requested scopes are granted, and that the caller is allowed to access the resource type they are requesting.

This should happen at the gateway, before the request reaches the FHIR server. Delegating token validation to the FHIR server itself creates coupling between your auth model and your FHIR implementation.

Scope-based and role-based access control. Not every app or system should access every FHIR resource type. A patient-facing app needs access to Patient and Observation. A clinical decision support tool needs access to MedicationRequest and Condition. An analytics pipeline has read-only access to a de-identified subset.

The gateway enforces these access levels by verifying that the token's scopes match what is permitted for the calling client, and by blocking resource types that fall outside the client's authorised access level.

Audit logging that satisfies HIPAA. HIPAA requires that you can answer: who accessed which patient records, from which system, at what time? Your audit log needs to capture the client identity, the resource type accessed, the operation performed, and the timestamp — for every request.

That log needs to be in a format your SIEM can ingest, filterable by date range and client identity, and retained for the period your compliance programme requires. "We have logs" is not enough. "We can produce a filtered report of all access to Patient resources by this application in March" is what auditors actually need.

Data residency — PHI stays inside your perimeter. For most health systems, PHI cannot leave a defined boundary. That boundary may be a specific cloud region, an on-premises data centre, or an air-gapped environment. The gateway must operate within that boundary — no telemetry to a vendor control plane, no credential validation against an external service, no logs forwarded outside the perimeter.

This rules out API gateways that require a cloud-hosted management plane, a vendor-hosted OAuth validation service, or telemetry that phones home to a SaaS provider.

Request and response transformation for backend compatibility. Different FHIR server implementations — HAPI FHIR, Azure Health Data Services, a cloud-hosted FHIR service — may behave slightly differently in their response formats or error codes. The gateway should be able to normalise these differences, so client applications do not break when the backend changes.

The Azure migration is an architecture decision

Many teams migrating off Azure API for FHIR are treating the migration as a like-for-like swap — find a new FHIR server, point the same clients at it. That works. But it misses the opportunity to separate concerns properly.

A FHIR server should do one thing: store and retrieve FHIR resources. Authentication, access control, audit logging, and rate limiting should live in the gateway layer in front of it. This separation means:

You can swap FHIR server implementations without changing your auth or audit model
You can add a new FHIR backend (or move to a multi-region setup) without rebuilding security
Your security team can reason about the gateway layer without understanding FHIR internals
When your next FHIR server vendor changes their product (or retires it), the migration is simpler

The teams that will handle the next migration most easily are the ones that build the separation now.

Deployment options that support data residency

For health data, self-hosted deployment is not a preference — it is frequently a legal and contractual requirement. Your gateway should support:

Docker Compose deployment for single-node or smaller-scale on-premises setups
Kubernetes deployment for production-scale, multi-replica, high-availability environments
Air-gapped operation — no outbound network calls at runtime for policy enforcement, credential validation, or telemetry

If your gateway vendor requires an internet connection to validate licenses, download policy updates, or send metrics to their cloud, they cannot operate inside a strict data residency boundary.

The migration timeline

With the Azure API for FHIR retirement set for September 2026, healthcare teams should be completing FHIR server migrations by mid-2026 at the latest, leaving time to validate before the retirement date.

The gateway layer — authentication, access control, audit logging — should be evaluated and deployed in parallel with the FHIR server migration, not after it. Discovering that your new FHIR server needs SMART on FHIR validation logic that was previously handled by the managed service is a late-stage surprise that delays go-live.

Zerq supports SMART on FHIR token validation, scope-based access control, HIPAA-ready audit logging, and fully self-hosted deployment with no outbound runtime dependencies. See the healthcare use case or request a demo to map your FHIR migration against your security and compliance requirements.