HAPI FHIR

In one line

HAPI FHIR is the open-source toolkit that turns the FHIR specification into working Java code — parse, validate, store and serve FHIR resources — and it underpins a large share of real FHIR deployments. Licence: Apache 2.0 (fully open).

Why it matters

The FHIR specification is a document; HAPI is the running code that implements it, and has since FHIR's early days. When a hospital, registry, or vendor says "we stood up a FHIR server," it is very often HAPI underneath. That ubiquity makes it the practical reference for how FHIR actually behaves, not just how the spec reads.

Three things it gives you

• A parser / serialiser — convert FHIR resources between Java objects and JSON or XML, handling versions, references and extensions correctly.
• A client — call other FHIR servers fluently (client.read().resource(Patient.class)…), for integration and testing.
• A server (the "JPA server") — a complete, deployable FHIR server that persists resources to a relational database, with search, validation against profiles, terminology services, transaction Bundles, and SMART-on-FHIR / OAuth2 support.

You model interactions as RESTful resource operations — GET /Patient?name=…, POST /Observation, a transaction Bundle — and HAPI handles versioning, referential integrity and conformance.

Versions and validation

HAPI tracks the FHIR versions closely (R4, R4B, R5) and can validate incoming resources against profiles (US Core, India's NRCeS), rejecting non-conformant data — the difference between "accepts JSON" and "enforces a clinical data contract."

Where it sits among the options

Tool	Stack	Best for
HAPI FHIR	Java	the reference server; embedding FHIR in Java systems
Medplum	TypeScript/React	app developers wanting batteries included
Cloud (HealthLake, Azure Health)	managed	enterprise, hands-off ops

Where it shows up in digital health

EHR FHIR façades, national/registry endpoints, vendor products, and learning environments. It is the reference you reach for when learning FHIR by doing — the exact REST patterns practised in the FHIR Sandbox and FHIR Mapper labs are what HAPI serves in production. Pair it with Synthea data and you have a complete local FHIR playground.

Common pitfalls

• Skipping validation — a server that accepts anything isn't interoperable; turn on profile validation for the data contract you actually need.
• Undersizing the database — the JPA server's search indexes grow; plan storage and tuning.
• Confusing "has a FHIR endpoint" with "is conformant" — conformance is about profiles and behaviours, which HAPI can enforce only if you configure it to.

Key takeaways

• HAPI FHIR = parser + client + full JPA server, the de-facto open-source FHIR stack in Java.
• It enforces real FHIR behaviour: search, references, transactions, profile validation, SMART.
• Tracks R4/R4B/R5; the production counterpart to the FHIR labs.
• HAPI (Java reference) vs Medplum (app-dev) vs cloud — choose by stack and ops appetite.