HAPI vs Aidbox vs Medplum for US Health Systems

Three FHIR servers show up in almost every US health system shortlist these days: HAPI, Aidbox, and Medplum. They look similar on a checklist (US Core compliant, R4/R5 ready, SMART on FHIR support) and very different in the operational reality. This comparison is for American hospital teams trying to decide which of the three actually fits their team and roadmap in 2026.

If you want the broader context before this head-to-head, the 2026 Buyer's Guide to FHIR Servers sets the framing. The US healthcare interoperability hub has more reference material across silos.

HAPI: Open-Source Workhorse

HAPI is the open-source FHIR server that essentially defined the category. It is Java-based, mature, and has the largest community of any FHIR project. American hospital teams pick HAPI when they want maximum control, when they have Java developers in-house, and when they are comfortable owning indexing, terminology, audit, and operations work. The trade-off is that running HAPI in production requires a real engineering investment. The Top 7 open-source FHIR servers for American hospital IT puts HAPI alongside the rest of the open-source landscape.

Aidbox: Commercial Server with Developer Focus

Aidbox is a commercial FHIR server that ships with the operational features that HAPI would require you to build: built-in audit logging, fine-grained access control, fast bulk-data export, and managed terminology. American hospital teams pick Aidbox when they want a managed option that still gives them low-level access for customization, and when they value developer ergonomics during integration projects. The licensing cost is the obvious trade-off, but the saved engineering time often more than offsets it.

Medplum: Newer Open-Core Alternative

Medplum is the youngest of the three and the option that picked up the most US adoption in the last two years. Open-core, US Core compliant, with a clean React-friendly developer SDK that healthcare startups gravitate to. American hospitals running Medplum tend to use it as a buffer layer for patient-facing apps, not always as the primary EHR FHIR endpoint. Production at hospital-system scale is still less common than for HAPI or Aidbox, but the trajectory is real.

How They Stack on Specific Capabilities

For US Core profile validation, all three pass. HAPI requires configuration. Aidbox and Medplum work out of the box. For bulk-data $export at hospital scale, Aidbox has the most consistent performance, HAPI handles it well if tuned, and Medplum is acceptable but newer to large-scale deployments. For SMART on FHIR launch from Epic and Cerner, all three work, with Aidbox being the least surprising to integrate. For audit logging that survives a HIPAA review, Aidbox and Smile (built on HAPI) ship managed audit; raw HAPI requires custom work.

The Deployment Question

The deployment model is the second axis that matters. HAPI is self-hosted by default; you can buy support from Smile to manage it. Aidbox can be self-hosted or managed by the vendor. Medplum can be self-hosted or managed by Medplum's cloud. The self-hosted vs managed FHIR servers question is the right place to think this part through, because the answer reshapes total cost more than license fees do.

A Reasonable Decision Framework

Pick HAPI if you have a Java team that wants to own the stack. Pick Aidbox if you want managed operations and developer-friendly tooling, and budget permits. Pick Medplum if you are building a patient-facing app layer that needs a clean FHIR backend and want the open-core flexibility. Proof of concept against your real US Core data is the only test that reliably picks among them in 2026.