Which open-source FHIR servers fit your situation
Suppose your team has a FHIR requirement, a shortlist of three or four servers, and a deadline to choose. The answer depends mostly on who will build and run the system. HAPI FHIR fits a Java-centric team that wants a self-run server it can deploy in its own infrastructure. The JPA server covers FHIR DSTU2, DSTU3, R4, R4B and R5, and the starter can run as a Docker image, under Spring Boot, as a WAR, or on Kubernetes. Its security is a set of building blocks rather than a finished layer, so your team will assemble authentication, authorization and audit logging itself. Confirm that your Java skills and your database choice (the starter defaults to embedded H2 and supports PostgreSQL and Microsoft SQL Server for production) match that workload.
Medplum fits a team that wants a FHIR platform with identity and developer tooling included. Medplum Auth covers OAuth, OpenID Connect and SMART-on-FHIR, and the platform adds Bots for server-side logic, a React component library and an SDK. The server runs on Node.js and TypeScript with PostgreSQL and Redis. Self-hosting is practical, but plan for its release policy: self-hosted upgrades must pass through each minor version in sequence, and post-deploy data migrations can take a long time on large datasets. Medplum's hosted plans and self-hosted Enterprise terms are priced differently, so ask for a written quote tied to your scope. Microsoft's FHIR Server (microsoft/fhir-server, MIT-licensed) suits a team already committed to Azure, since Microsoft says its Azure PaaS FHIR servers are backed by this project. Check the README's notices before you commit, including that FHIR R4B support ended on 1 July 2026 and the Cosmos DB provider ended on 30 September 2026.
Blaze is a research-focused FHIR server, and this comparison does not rate its production readiness. Treat it as a candidate for evaluation work and confirm its maintenance status and support options directly with its maintainers before you consider it for live clinical data. Whichever server you pick, none of the three is a compliance certification. A FHIR server supports your HIPAA, ONC or other obligations only as one part of a system whose access controls, audit logs, backups and policies you design, operate and evidence. Make the final decision by checking three things: your team's language skills, whether you will host it yourself or buy a hosted service, and how your identity design (SMART-on-FHIR, client credentials, corporate identity providers) must work from day one.
Which FHIR server to shortlist for each scenario
This table maps common team situations to the FHIR server most likely to fit, with the condition that makes each choice right and the condition under which another option wins. Read it against your language stack, identity model and hosting target, then confirm the details in the vendor documentation before you commit.
| Scenario | Best fit | Why |
|---|---|---|
| Java team embedding FHIR into an existing JVM estate | HAPI FHIR | Apache 2.0 Java library and JPA server that runs as a Spring Boot app, WAR or Docker image. Another option wins if your team does not run JVM services or needs a built-in developer platform. |
| Team wanting a full developer platform with built-in auth and client SDKs | Medplum | Ships Medplum Auth (OAuth, OpenID Connect, SMART-on-FHIR), an SDK, a React component library and Bots. HAPI FHIR wins if you only need a FHIR API and will build the rest yourself. |
| Azure-first organization | Microsoft FHIR Server | MIT-licensed, with an Azure deployment path and Azure Active Directory role mapping. Another option wins if you need to run on AWS or on-premises without Azure dependencies, or you are on Cosmos DB, which is no longer supported. |
| Team that must self-host on Kubernetes or a VM | HAPI FHIR | Documented Docker, Kubernetes Helm, WAR on Tomcat and Spring Boot paths, with PostgreSQL or SQL Server for production. Medplum also self-hosts on Kubernetes, but expect a Node.js and PostgreSQL stack with Redis and strict sequential upgrades. |
| Research or evaluation project | Blaze | Suited to exploring FHIR behavior and prototypes. Choose a production-oriented option if you need supported operations, documented compliance evidence or a vendor support path. |
| Team that needs commercial support | HAPI FHIR (via Smile CDR) or Medplum Enterprise | HAPI FHIR's README points to Smile CDR for commercial support. Medplum offers hosted and custom-priced Enterprise plans. Confirm support terms, response commitments and scope in writing with the vendor. |
How each open-source FHIR server is built and licensed
The four servers differ most in what they are built on and how they are licensed. Apache 2.0, MIT and Apache Software License 2.0 are OSI-approved open-source licenses, while Medplum's hosted tiers and Enterprise Self-Hosted are commercial products. Check the license and the support model before you compare features.
HAPI FHIR
HAPI FHIR is a Java API for HL7 FHIR clients and servers, licensed under the Apache Software License 2.0. Its JPA server covers FHIR DSTU2, DSTU3, R4, R4B and R5, with terminology, validation, MDM and partitioning. It is a library you build into a Java service, so your team owns the runtime, the deployment and the security layer. HAPI states it does not provide a single one-size-fits-all security layer, so plan your authorization design early. Commercial support is available from Smile CDR, which the project's README names.
Medplum
Medplum is released under the Apache 2.0 license and built on Node.js and TypeScript, using PostgreSQL as its database and Redis as its cache. Its components include Medplum Auth (OAuth, OpenID Connect and SMART-on-FHIR), a FHIR R4 API with GraphQL, Bots for server-side logic, an HL7 client and server, and a React component library. Hosted plans and Enterprise Self-Hosted are commercial, so confirm which features sit in the open-source Community option before you commit to a self-hosted design.
Microsoft's FHIR Server
The MIT-licensed microsoft/fhir-server project is the open-source base for the FHIR service in Azure Health Data Services, which Microsoft says is backed by this project. The SQL Database provider remains supported, while Cosmos DB provider support ended on 30 September 2026. FHIR R4 remains supported and R4B support ended on 1 July 2026. Its deployment scripts and ARM templates target Microsoft Cloud, so confirm how far a non-Azure deployment is supported before you plan one.
Blaze
Blaze is a FHIR server positioned as research-focused. No supplied facts cover its license, supported FHIR versions or production track record, so do not assume any of them from this page. Confirm the license text, the FHIR versions it implements, its persistence options and its production use directly with the project before you put it on a shortlist for a clinical workload.
How the FHIR servers compare on capability
This table sets HAPI FHIR, Medplum and Microsoft's FHIR Server side by side on language, FHIR versions, storage, identity, deployment, hosting, support and extensibility. Read each row as a question to answer for your own environment, and treat Blaze cells as items to confirm with the project before shortlisting.
| Capability | HAPI FHIR | Medplum | Microsoft FHIR Server |
|---|---|---|---|
| Implementation language | Java, built on the HAPI FHIR API and JPA server | TypeScript on Node.js, with an SDK and React component library | Open-source implementation of FHIR, maintained by Microsoft (confirm the implementation stack in the repository) |
| FHIR versions | DSTU2, DSTU3, R4, R4B and R5 in the JPA server | FHIR R4 API with GraphQL support | FHIR R4 supported; R4B support ended on 1 July 2026 |
| Database options | H2 by default; PostgreSQL and Microsoft SQL Server for production; MySQL not supported | PostgreSQL as the database and Redis as the cache | SQL Database provider supported; Cosmos DB provider support ended 30 September 2026 |
| Identity and access options | Authentication and AuthorizationInterceptor building blocks, consent and search narrowing, BALP audit logging; no single built-in security layer | Medplum Auth with OAuth, OpenID Connect and SMART on FHIR; external IdPs, client credentials and MFA | Scripts to map to Azure Active Directory for role-based access control (confirm the current identity model with Microsoft) |
| Deployment methods | Docker image, Docker Compose, Spring Boot, WAR on Tomcat, Jetty or Wildfly, Kubernetes with Helm | AWS with CDK and CloudFormation, Ubuntu APT, Docker, Kubernetes, DigitalOcean, source build; Terraform for GCP and Azure marked Beta | Azure portal, CLI and PowerShell quickstarts, ARM templates for Microsoft Cloud provisioning |
| Hosted counterpart | Public demonstration server at hapi.fhir.org, not a managed production service | Hosted plans with Free, Production, Premium and custom Enterprise tiers | Azure Health Data Services, which can host a FHIR server and a DICOM server in one workspace |
| Commercial support | Smile CDR is named in the README for commercial support | Enterprise and Enterprise Self-Hosted tiers, priced on request | Through Microsoft and Azure support plans (confirm terms with Microsoft) |
| Extensibility | JPA partitioning for multitenancy, data source separation or regional grouping; terminology, validation and MDM services | Bots for server-side logic, an HL7 client and server, and a web app built on the SDK | Bulk Export and the $convert-data operation; pluggable persistence layer (confirm custom operation support) |
What running each FHIR server takes from your team
HAPI FHIR is a Java library, and its JPA server starter is the usual route to a running FHIR server. The starter can be deployed as the hapiproject/hapi Docker image, with Docker Compose, with Spring Boot, as a WAR on Tomcat, Jetty or Wildfly, or on Kubernetes with a Helm chart. Your team chooses the runtime, the database and the surrounding infrastructure, and owns each of those decisions.
- Deployment paths: Several supported paths exist, so the platform team picks one and standardizes on it. The starter defaults to an embedded H2 database, which is not a production choice. PostgreSQL and Microsoft SQL Server are the supported production options, and MySQL is not supported.
- Upgrade model: Upgrades are yours to plan and test against your own customizations, interceptors and database schema. Check the JDK requirement for the version you target, since HAPI FHIR 8.2.0 requires JDK 17.
- Security design: HAPI FHIR does not provide a single security layer. Your team builds authentication, then sets the AuthorizationInterceptor rules, consent and search narrowing, CORS, and BALP audit logging.
- Authorization and audit: Access rules, consent logic and audit records must be specified, tested and retained as part of your system, not inherited from the framework.
- Partitioning: If you separate tenants, regions or data sources, partition design becomes a schema and access decision made early.
Confirm with your security and compliance leads which authorization, consent and audit controls they expect before choosing this path, and confirm the supported database and JDK for the version you plan to run.
Medplum is built on Node.js and TypeScript, uses PostgreSQL as its database and Redis as its cache, and offers self-hosting paths including AWS with CDK and CloudFormation (the recommended option), Ubuntu via an APT repository, Docker, Kubernetes, DigitalOcean, building from source, and Terraform-based GCP and Azure deployments marked Beta. Self-hosting gives you the full stack, and the upgrade rules are the part most teams underestimate.
- Sequential upgrades: Self-hosted Medplum must be upgraded through each minor version in order. Skipping versions, for example going from v3.1.2 straight to v4.3.4, causes startup failures.
- Data migrations: Post-deploy data migrations can run for hours or days on large datasets, so plan maintenance windows and test migration timing on a copy of production data.
- Release cadence: Medplum ships major versions annually in Q4, minor versions two to three times a year and patch versions weekly. Each major version gets one year of Active support and one year of Maintenance, with an Enterprise extension for security patches.
- Patch targets: Medplum's policy targets security patches within 7 days for critical vulnerabilities and within 14 days for high ones. Your own change process must be able to absorb those patches.
- Shared responsibility: Medplum's compliance documentation states that compliance is shared between Medplum and its customers, so hosting, access and evidence collection remain partly yours.
Before committing, ask Medplum to confirm the upgrade path, migration timing and support terms for the version you intend to run, and confirm your own staffing for a recurring upgrade cycle.
Microsoft's FHIR Server (microsoft/fhir-server) is MIT-licensed, and Microsoft says its Azure PaaS FHIR servers, including the FHIR service in Azure Health Data Services, are backed by this project. The most common route is managed hosting in Azure, where Microsoft operates the service and your team configures it. Self-hosting the open-source project is possible, but the persistence and identity work then sits with you.
- Managed hosting: Quickstarts cover deployment through the Azure portal, CLI and PowerShell, and scripts and ARM templates support provisioning. Azure Health Data Services can host a FHIR server and a DICOM server in one workspace.
- Persistence choice: The SQL Database provider remains supported, while Cosmos DB provider support ended on 30 September 2026. Choose SQL-based persistence for new work and confirm the provider lifecycle before you plan.
- FHIR versions: FHIR R4 remains supported, and R4B support ended on 1 July 2026. Confirm which version your interfaces need.
- Identity mapping: The project provides scripts to map to Azure Active Directory for role-based access control. Your team owns role design and the mapping to your clinical and administrative roles.
- Operations: Bulk Export and the $convert-data operation are available, and your team must schedule and monitor them as part of the workload.
Confirm with Microsoft which hosting model, persistence provider and FHIR version apply to your tenant, and whether your organization's cloud policy allows the managed service.
What licensing and paid editions mean for a regulated buyer
Apache 2.0 code carries no license fee, but it does not carry zero cost. HAPI FHIR is licensed under the Apache Software License 2.0, and Medplum is released under Apache 2.0, so your organization can run either without paying a license fee to the vendor. The money moves elsewhere: cloud or data center capacity, the database and its backups, the staff who patch, monitor and upgrade the server, and any commercial support contract you choose to buy. For a regulated buyer, the question is not whether the code is free but which of those costs you will carry and which you will outsource.
Medplum sells the same platform in several forms, and the supplied pricing page lists Free, Production at $2,000 per month, Premium at $6,000 per month and a custom-priced Enterprise plan for hosted use. Self-hosting is offered as a free Community option or a custom-priced Enterprise Self-Hosted option, according to the Medplum pricing page. Compare those published figures with your own estimate of running the stack, and confirm in writing what the Enterprise Self-Hosted price includes, such as upgrade assistance, support response times and indemnity terms. HAPI FHIR has no equivalent paid edition in its README. Its commercial support comes from Smile CDR, a separate company and contract, so price that relationship on its own terms.
Medplum's compliance documentation lists HIPAA, SOC 2 Type II, ONC certification, CFR Part 11, HITRUST e1, CLIA/CAP and ISO 9001, and states that compliance is a shared responsibility between Medplum and its customers. Ask which controls Medplum operates for a hosted tenant and which fall to your team when you self-host, and get that split in writing before signing. Whatever route you choose, request the support windows, security patch commitments and indemnity language as contract terms rather than relying on the README or the documentation summary.
How to choose and pilot a FHIR server
This sequence turns a shortlist of HAPI FHIR, Medplum and Microsoft's FHIR Server into a decision your security, data and operations teams can defend. Each step produces a written record that feeds the next, so the pilot tests the questions that matter for your environment.
Define required FHIR versions and resource types
Clinical informatics and integration leads list the FHIR versions each trading partner, payer or internal consumer requires, along with the resource types, operations and search parameters they will call. Compare that list against each candidate's documented support: HAPI FHIR's JPA server covers DSTU2 through R5, Medplum's FHIR R4 API is the documented core, and Microsoft's FHIR Server README states R4 remains supported while R4B support ended on 1 July 2026. Done when the team signs a requirements matrix that names every version and resource type in scope, and any gap is flagged for vendor confirmation. Keep the matrix as evidence for the architecture review.
Decide how identity federates with corporate login
The security architect documents whether clinicians and applications must sign in through your corporate identity provider, whether SMART on FHIR launch is required, and how server-to-server clients authenticate. Medplum documents its own identity provider, external providers, domain-level corporate providers, client credentials and multi-factor authentication. HAPI FHIR provides authentication interceptors and an AuthorizationInterceptor but states it has no single security layer, so the team must design and test that integration itself. Done when a written identity flow diagram exists and each candidate has been asked to demonstrate it. Retain the diagram, the role-to-scope mapping and the test results.
Choose the database your DBA team will support
The database administrators confirm which engines they can back up, patch, monitor and restore under your standards before any product is tested. HAPI FHIR's JPA starter defaults to embedded H2 and supports PostgreSQL and Microsoft SQL Server for production, not MySQL. Medplum uses PostgreSQL with Redis as a cache. Microsoft's FHIR Server documents a SQL Database provider as supported, while Cosmos DB provider support ended on 30 September 2026. Done when the DBA team approves one engine per candidate in writing, including backup and restore responsibilities. Keep the approval and the restore test log for the security file.
Test an upgrade path in non-production
The platform engineering lead deploys each shortlisted candidate in a non-production environment, then rehearses an upgrade to the next supported release. For Medplum, the upgrading guide requires stepping through each minor version in sequence, since skipping versions causes startup failures, and post-deploy data migrations can run for hours or days on large datasets. Record how long each step takes on your data volume and whether rollback is possible. Confirm HAPI FHIR's required JDK version for the release you plan to run. Done when a dated upgrade runbook exists and has been executed once. Retain the runbook, logs and any vendor confirmations of the upgrade sequence.
Run a de-identified pilot with interface traffic
Integration engineers replay representative interface traffic, such as admission, lab and medication messages converted to FHIR, against each candidate using de-identified data shaped like your production records. Include bulk operations, search patterns and any consent or partition rules you need, such as HAPI FHIR partitioning for regional separation. Security staff review audit logging, such as BALP support in HAPI FHIR, and whether access decisions match the role matrix from step two. Done when pass or fail results for each requirement are recorded against the same test cases. Keep the test scripts, de-identification method, audit log samples and results.
Compare licensing, editions and support terms
Procurement and the CISO compare what each option costs to own, separating the free software from the parts you pay for. Medplum lists hosted and self-hosted paths, including a free Community option and custom-priced Enterprise Self-Hosted, and its compliance documentation states compliance is a shared responsibility. HAPI FHIR points to Smile CDR for commercial support, and Microsoft's Azure-hosted options are managed services. Ask each vendor for a written quote tied to your scope, support hours, patch windows and exit terms. Done when the team holds comparable written quotes and a responsibility matrix covering who patches, monitors and documents each control. Retain both documents for the vendor risk file.
Decide hosting and ongoing support model
The steering group selects where the server runs, whether in your cloud accounts, a data center, a managed service or a combination, and who provides ongoing patching, monitoring and upgrades. Medplum's self-hosting docs list AWS, Ubuntu, Docker, Kubernetes and other paths, with some Terraform-based options marked Beta. Microsoft offers managed Azure deployment through its FHIR service. A partner such as DeployOpen can plan, implement, harden, document and support a self-hosted platform inside your infrastructure, typically under a written, fixed scope. Done when the hosting decision, support owner and escalation path are approved and linked to the security review. Keep the decision record and the support agreement with the evidence package.
Questions buyers ask before hiring outside help
Which open-source FHIR server costs the least to run?
The license cost is zero for all three, so the real difference is operating cost. HAPI FHIR and Microsoft's FHIR Server are both Apache or MIT licensed Java and .NET style deployments you run yourself, and Medplum's Community self-hosting option is free to download. What drives your bill is infrastructure, database administration, upgrades and the people who run them. Medplum's hosted Production plan is listed at $2,000 per month on its pricing page, which is a useful benchmark against your own staffing cost, but self-hosting avoids that line while adding operating work. Ask any vendor or partner for a written quote that separates one-time setup from recurring operations.
How much staff time does self-hosting a FHIR server take?
The time depends on how many components you own, how often you upgrade, and how much security and compliance evidence you must produce. Medplum's self-hosting path includes PostgreSQL and Redis, and its upgrade guide says each minor version must be applied in sequence, with post-deploy data migrations that can run for hours or days on large datasets. HAPI FHIR's JPA server needs a supported database, and HAPI states it provides building blocks for security rather than a complete security layer. Plan for recurring work in patching, backup testing, monitoring and access reviews. Ask for an estimate of hours per month tied to your named components and release cadence.
Can our team run HAPI FHIR or Medplum without outside help?
Yes, a team with strong Java or Node.js operations skills, PostgreSQL experience and a clear security owner can run either one, but the question is whether it has the capacity to do so continuously. HAPI FHIR's documentation covers Docker, Spring Boot, Tomcat and Kubernetes deployments, while Medplum publishes self-hosting guides for AWS, Docker, Kubernetes and other targets. Outside help tends to matter most for the first deployment, identity integration, hardening evidence and the upgrade path. Assess your team against the specific tasks in the deployment guide before deciding, and treat any gap as a scope item.
How long does a FHIR server pilot take, and what sets its length?
Pilot length is set by scope, not by the server brand alone. The main drivers are how many resource types and FHIR versions you must support, how many source systems feed the server, whether you need bulk export or terminology services, and how fast your identity and network approvals move. Medplum's release policy and HAPI FHIR's version support both affect how much you rebuild later, so pin the version before starting. DeployOpen does not publish timelines; most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work begins, so ask for a schedule tied to named milestones.
What does the work need from our side?
Expect to supply four things: an identity provider, a database host, network access and a named sign-off owner. Medplum supports its own identity, external providers such as Google, Auth0 or AWS Cognito, corporate domain identity providers, client credentials and multi-factor authentication, so decide which one governs clinicians and which governs system clients early. HAPI FHIR leaves authorization design to you through its interceptors. Confirm your PostgreSQL or Microsoft SQL Server host, since HAPI's JPA starter defaults to embedded H2 and does not support MySQL. Ask the partner to list each dependency, owner and approval date in the scope document.
Does choosing one of these FHIR servers make our system compliant?
No. A FHIR server can support compliance work, but no software product makes a system compliant on its own, and DeployOpen does not issue audit reports, attestations or certifications. Medplum's compliance documentation lists HIPAA, SOC 2 Type II, ONC certification and other programs, and states that compliance is a shared responsibility between Medplum and its customers. Independent auditors and certification bodies produce the evidence that counts. Your own configuration, access controls, logging and policies remain your responsibility, so ask for a readiness assessment that maps each control to an owner and a piece of evidence.
How do we get a fixed-scope quote for implementation?
Start with a written scope that names the server, version, deployment target, data sources, identity model, testing and handover. DeployOpen does not publish a price list; a quote follows from that written scope, and most engagements are fixed-scope with deliverables and timelines agreed in writing before work starts. Ask each bidder to separate one-time setup, integration, testing and documentation from recurring items such as upgrades and support retainers. Request the assumptions behind each line, the client dependencies, and what changes the price, so you can compare offers on equal terms.
How DeployOpen scopes a FHIR server selection and build
DeployOpen plans, implements, integrates, hardens and documents self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks. For FHIR servers, that means starting from your use cases and governance constraints, then working through a written scope before any build begins.
How we scope
- We start with the use cases, FHIR versions and identity model your applications need before naming a server.
- Scope documents the target hosting environment, database choice and the identity provider the server must trust.
- Engagements are fixed-scope, so deliverables and timelines are agreed in writing before work starts.
How we build
- We deploy the chosen server into your infrastructure, using the deployment method your platform team already runs.
- Authorization, consent, audit logging and CORS settings are configured and tested against your written access rules.
- We integrate the server with your identity provider, existing clinical systems and any SMART on FHIR applications in scope.
How we hand over
- Handover includes the configuration, hardening decisions, backup and upgrade procedures and test evidence in the written scope.
- We document the version upgrade path so your team can plan changes before they reach production.
- Your staff are walked through the runbooks, and you confirm which compliance evidence the scope includes.
How we support
- Ongoing support, upgrades and continuous security testing are available as retainers after handover.
- Ask us to confirm the retainer scope covers version upgrades, patch windows and incident response before you sign.
- Independent auditors and certification bodies issue any audit reports or certifications; we prepare the systems and evidence.
