HAPI FHIR vs Microsoft FHIR Server

Start with the FHIR versions your partners and internal consumers actually send and expect, because that decides whether a server's version coverage is a constraint. HAPI FHIR's JPA server covers DSTU2, DSTU3, R4, R4B and R5, so one deployment can serve clients on different versions, provided each version path is tested against your own data. The microsoft/fhir-server project states that R4 remains supported and R4B support ended on 1 July 2026. Any interface that still depends on R4B must move to R4 or to another server before you rely on the Microsoft project. Teams that need DSTU2 or DSTU3 endpoints should verify directly with Microsoft that the project meets them before assuming parity.

The persistence decision is more time sensitive. The microsoft/fhir-server README says Cosmos DB provider support ended on 30 September 2026, while the SQL Database provider remains supported. If your current Azure environment uses the Cosmos DB provider, moving to the SQL Database provider is a migration project, not a configuration change. Confirm the supported migration steps and tooling with Microsoft in writing. Then rehearse a restore and validation on a copy of production data, check search parameters and indexes after the move, and agree a cutover window with clinical and integration owners before you commit a date.

HAPI's JPA model is not tied to one database technology. The hapi-fhir-jpaserver-starter defaults to an embedded H2 database, supports PostgreSQL and Microsoft SQL Server for production, and does not support MySQL. A team that standardizes on MySQL must choose another engine or confirm support with HAPI's maintainers. Microsoft's project uses a pluggable persistence layer, and the SQL Database provider is the supported store going forward, which ties that path to Azure data services if you run in Azure. If your organization already operates PostgreSQL or SQL Server well, that skill set may settle the store question, but confirm schema, search and backup behavior for your chosen store with each vendor and record the answer in the design document.

HAPI FHIR does not ship a single security layer. It offers building blocks: authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Your team writes the policy that connects them. In practice that means deciding who may read or write each resource type, which compartments or patients a clinician can see, how consent directives narrow search results, and where audit events are stored and reviewed. The policy is your work product, and it needs its own design review and test cases before go-live.

Microsoft's project takes a different starting point. The microsoft/fhir-server README says it provides scripts to map the server to Azure Active Directory for role-based access control, and the Azure deployment paths are documented around that wiring. If your identity provider is Entra ID and your roles already map cleanly to FHIR access needs, much of the identity plumbing is prepared for you. Outside Azure, that mapping is not a drop-in. Confirm with Microsoft, through the project's issues or support channels, which identity providers and token configurations the project supports, and which parts of the Azure scripts you would need to replace.

Whichever server you choose, test the access model rather than trusting the configuration. Build a matrix of roles, patient contexts and resource types, then run positive and negative tests against each server in your own environment, including token expiry, revoked roles and cross-tenant reads if you run partitions. Record the results as evidence for your security review. Ask each vendor for their documented identity integration steps in writing, and treat any step they cannot document as a gap in your plan.

Implementing HAPI FHIR is mostly a platform build, and the work is front-loaded. You size and provision the database first: the JPA starter defaults to an embedded H2 database, so a production deployment means choosing PostgreSQL or Microsoft SQL Server (MySQL is not supported) and planning storage, backups and index tuning for your expected resource volume. Next you decide on partitioning, since HAPI places each resource in a partition used for multitenancy, data source separation or regional grouping, and that choice is hard to unwind once data is loaded. Authorization and audit are yours to assemble: HAPI provides the AuthorizationInterceptor, consent and search narrowing interceptors and BALP audit logging, but states it does not supply a single security layer. Upgrades are an ongoing cost. Version 8.2.0 and later require JDK 17, so your runtime, container base image and Spring or servlet container all need to move with the server. Confirm the exact JDK level for the release you pin, and test schema migrations on a copy of production data.

Implementing the Microsoft project depends on where you run it. If you use the managed FHIR service in Azure Health Data Services, the work is Azure provisioning: the quickstarts cover the portal, CLI and PowerShell, and scripts and ARM templates are available for provisioning in the Microsoft Cloud. Running the open-source server outside Azure means you build that provisioning yourself. The persistence provider is the key early decision. The README says the SQL Database provider remains supported, while Cosmos DB provider support ended on 30 September 2026, so any plan that assumes Cosmos DB needs to be rebuilt on SQL before go-live. Identity mapping is the other early decision: the project provides scripts to map to Azure Active Directory for role-based access control, and you must map your own roles, groups and SMART scopes onto those roles. Confirm which identity provider you will use and how its claims map to FHIR access.

Projects on either server usually run long in four places. Identity integration is the most common, because SMART on FHIR scopes, consent rules, break-glass access and clinician role mapping touch the identity provider, the application and the audit trail at once. Data migration is next, especially when legacy records need mapping to FHIR resources and profiles, and when Microsoft's $convert-data operation or your own transformation code must be validated against the source. Terminology and validation work is easy to underestimate, because code systems, value sets and profile conformance must be loaded and tested, and HAPI's terminology and validation services need configuration to match your profiles. Conformance testing comes last and takes the longest to close. Ask any partner to write the test plan, including profile validation against your implementation guides and the FHIR versions you must support, before you agree on a scope.