By Integration

FHIR Server vs API Gateway: Which Wins for EHR Integration

The same EHR integration use case can be served by two very different architectural choices. One puts a full FHIR server in front of the EHR, taking responsibility for resource persistence, profile validation, and a conformant FHIR API. The other puts a general-purpose API gateway in front of the EHR, handling routing, authentication, and rate limiting while leaving the FHIR semantics to the systems behind it. The choice is consequential and not always made deliberately. For broader background, see more on healthcare integration patterns.

The FHIR integration platforms reference guide covers the broader architectural picture in which this choice sits.

What Each Approach Actually Does

A FHIR server in front of the EHR is a full conformant server: it accepts resources, validates them against profiles, persists them, and exposes the standard REST endpoints. It owns the FHIR semantics. Servers like HAPI, Smile Digital Health, and Aidbox are typical choices.

An API gateway in front of the EHR is a thinner layer: it routes inbound requests to one or more downstream FHIR-capable systems, handles OAuth, applies rate limits, and observes traffic. Kong, Apigee, and AWS API Gateway are typical choices. It does not own FHIR semantics; the downstream systems do.

The two patterns overlap in places, which is why the choice can be confusing. The clean way to distinguish them is to ask where profile validation, persistence, and resource consistency live. If those responsibilities live in the front layer, it is a FHIR server. If they live downstream, it is a gateway.

When Each One Wins

A FHIR server wins when the team needs:

  1. A single conformant FHIR surface that absorbs EHR quirks and presents normalized resources to downstream consumers.
  2. Persistence-level control over FHIR resources, including profile validation at write time.
  3. Bulk Data $export, Subscriptions, and other operations that depend on the server owning the resource state.

An API gateway wins when the team needs:

  1. Lightweight routing in front of multiple FHIR-capable downstream systems, with the downstream systems owning the resource state.
  2. Strong, general-purpose API management features like rate limiting, quota enforcement, and developer portals.
  3. A pass-through architecture where adding FHIR-specific behavior at the front layer would force a redesign of the downstream systems.

The top FHIR servers for EHR connectivity walkthrough covers the server side; gateway options come from the general API-management ecosystem and are not FHIR-specific.

How Teams Should Pick

The honest deciding question is whether the front layer needs to own FHIR resource state. If yes, pick a FHIR server. If no, pick a gateway. Teams that try to bolt FHIR-specific behavior onto a general-purpose gateway end up reinventing pieces of a FHIR server in plugin code, and the result is usually fragile.

The trade-off is real but not universal. A hybrid pattern is also common: a gateway in front for general API management, with a FHIR server behind it for FHIR semantics. That pattern works when the responsibilities are split cleanly, and it falls apart when both layers try to own the same concern.

For EMR vendors thinking about this architectural choice inside their own product, the best FHIR integration engines for EMR vendors walkthrough covers the engine-level decisions that precede this question. The right choice tends to be visible in retrospect by what the team stopped thinking about, not by what they advocated for during selection.

Sources