How to plan a FHIR server deployment: stakeholders, questions, and architecture

When a FHIR deployment goes wrong, the failure usually traces back to something decided, or not decided, before any software was installed.

Security wasn’t brought in until the design was already done. Nobody asked how many requests production would actually see. Nobody asked whether the FHIR server would be the source of truth or just a synced copy, and that single question ends up shaping half the architecture.

This is essentially the conversation we have with every customer before anything gets built, generalized enough that any team can run it themselves.

It has less to do with technology than you’d think. The most important thing is getting the right people in the room early and asking a short list of questions whose answers determine everything else.

Who needs to be in the room

Who you get in the room matters more than which reference architecture you pick.

In practice that looks like:

• Project Manager: manages requirements and timelines; ideally someone who understands FHIR.

• Lead Architect: owns the overall design, networking, deployment, security posture, and integration strategy.

• Software and Integration Engineers: connect and map source data, secure the environment, manage traffic, and implement custom business rules.

• Compliance: knows which regulations and implementation guides apply, along with their deadlines.

• Subject Matter Experts: FHIR specialists and health system analysts who know the underlying data and can navigate terminologies like SNOMED, ICD-10, LOINC, and other value sets and coding systems FHIR relies on.

• Data Security: responsible for ensuring no one accesses PHI who shouldn’t. This role can slow a project down, but that’s not a knock against it, just something to plan for. Security approval is usually the hardest to get, given the PHI and HIPAA risk involved. The best thing you can do for your timeline is bring security in on day one, rather than discovering their requirements at the end.

Some organizations cover all of these roles with two people. Others need a full team per function. The roles matter, not the headcount.

The questions that decide the architecture

A handful of questions, asked honestly, do most of the planning work.

Which implementation guides do you need to support? That decides your conformance resources: custom search parameters, profiles, code systems, value sets, and for quality use cases, measures and libraries.

How many requests will production actually see? The honest range runs from a few requests a month for a compliance-only deployment to thousands of requests per second when the FHIR server is the central interoperability layer for seven or eight applications. Those are different architectures. It’s also important to plan for potential growth in use over the next few years. If it’s possible that use could grow quickly, plan a scalable platform from the beginning.

How much data? Thousands of resources sit fine in a simple database and basic FHIR server, but millions/billions change your storage, indexing, and loading strategy.

Is the API public or secured? Public endpoints change your threat model completely. Public APIs are where it gets scary, because anyone who knows the endpoint can hit it. In practice, it’s often the provider directory, the least sensitive data you host, that draws the most traffic, including the app that re-downloads everything every 30 seconds. That’s what rate limiting with a proxy service is for.

Do you need validation in production? Validation is expensive to run in the request pipeline. If outside parties write to your server, you likely need it there, along with a plan for handling failures: either reject invalid data strictly or admit it while flagging it for review. Either way, you need somewhere for failed messages to land, since not everyone using your API knows how to interpret an OperationOutcome.

If only your own internal pipeline writes to the server, validate earlier in that pipeline instead, before data reaches the server. One advantage: validation scales out well. Since it barely touches the database layer, you can place multiple validating servers/services in front of your main server to handle the load.

Source of truth or sync target?

One question decides your backup strategy, your availability requirements, and a chunk of your cost: Is the FHIR server the system of record, or a synchronized copy?

If it’s the source of truth, back it up like the transactional system it is. If it’s not, backing up billions of resources is an expensive way to protect data that already lives somewhere else. You might be better off reloading from source using your staging area and a last-updated window. Knowing which one you’re dealing with changes how much high-availability you buy and how much disaster recovery you build into the system.

The same logic applies to deployment. Cloud gives you scaling, geographic redundancy, and low upfront cost, and it’s the default preference for me. But regulation and data residency can override that, and costs are hard to predict until it’s running. On-premises trades capital cost and dedicated system engineers for control. A hybrid setup, data on-premises with compute in the cloud over a secure pipe, is often the workable middle ground.

Portability matters too. Whatever you choose, you want the option to move it later without a rebuild, since regulation, cost, or a platform migration can force that decision for you.

Access and identity

Almost every FHIR server sits behind a proxy service to direct traffic, reroute during upgrades, and rate-limit clients that misbehave. Behind that, SMART on FHIR, built on OAuth2, is the standard for authorizing clients, with your identity provider (Microsoft Entra ID, Okta, Keycloak, AWS Cognito) federated via OpenID Connect or SAML.

Here’s the catch: off-the-shelf identity providers aren’t SMART-aware. Entra ID, for example, wants to issue roles, not scopes, and has no idea which patient resource a logged-in user maps to. Something must own that mapping and inject the right scopes and claims into tokens, which is why we built Firely Auth to sit between the identity provider and the server, rather than asking a general-purpose product to speak FHIR.

We learned one lesson the hard way, too: audit belongs elsewhere. We once had a server that had become 98% audit events and hardly any actual data. Audit trails belong in Splunk, Elasticsearch, or your observability platform, not stored as resources next to the clinical data.

FHIR server architectures

Get the questions answered honestly, and the architecture decisions mostly make themselves.

Serving multiple separate client organizations off one deployment points toward multi-tenancy. A single organization with clean isolation needs is better served as single-tenant.

A legacy system you can’t migrate but still need to expose in real time calls for a facade in front of it. Otherwise, a native FHIR repository is the better fit.

And if multiple FHIR versions or US Core versions are in play, that usually means separate servers per version, with the proxy routing requests to the right one by profile, since resources don’t map one to one across versions.

None of these are exotic. All of it goes faster and cheaper when the right people answer the right questions before the first server gets provisioned. Plan the room first. The server is the easy part.

Whether you’re just starting to think this through, or already in the middle of it and want another perspective, get in touch. We’re always happy to talk it through.