Medplum
An open-source, FHIR-native developer platform — a headless backend with a FHIR datastore, auth, subscriptions and automation — for building healthcare apps fast.
In one line
Medplum is a modern, developer-first FHIR backend you can self-host: store everything as FHIR, get authentication, access control, subscriptions and serverless "bots" out of the box, and ship a healthcare app without building the plumbing. Licence: Apache 2.0 (fully open).
The problem it solves
Every health-tech team rebuilds the same plumbing: a patient datastore, login, role-based access to clinical data, audit logging, webhooks when something changes. That's months of undifferentiated work — and getting access control to PHI wrong is dangerous. Medplum ships that plumbing as an open-source, FHIR-native backend so a team can spend its time on the product, not the substrate.
What you get out of the box
- A FHIR datastore — every object is a FHIR resource; CRUD and search are the FHIR REST API, so you're standards-correct by construction.
- Identity & access policies — authentication plus fine-grained access policies (which users/roles can read or write which resources), the hard part of health apps.
- Subscriptions — real-time notifications when matching resources change (the basis for reactive workflows).
- Bots — serverless functions that run on data events (e.g. when a lab result arrives, normalise it, fire an alert). Automation without a separate service.
- Client SDKs & React components — TypeScript/React libraries that make CRUD-on-FHIR and even SMART-on-FHIR login feel like any modern API.
- A hosted admin app to browse and edit resources.
Medplum vs HAPI FHIR — who each is for
Both are open-source FHIR servers, but the audience differs:
| Medplum | HAPI FHIR | |
|---|---|---|
| Stack | TypeScript / React, app-developer-first | Java, reference implementation |
| Sweet spot | building a product fast (startups) | embedding FHIR in Java systems / vendors |
| Extras | auth, access policies, bots, UI bundled | parser + client + JPA server, you assemble |
| Hosting | self-host (open) or managed cloud | self-host |
Where it shows up in digital health
Medplum is popular with health-tech startups that want to be FHIR-correct from day one without standing up infrastructure — patient portals, intake flows, lab and telehealth apps, EHR-lite products. It illustrates the same resources and SMART-on-FHIR launch you practise in the labs, from an app-builder's vantage point rather than a server admin's.
Common pitfalls
- Leaning on defaults for access control — the power is in configuring access policies for your data model; default-open is a PHI risk.
- Treating bots as a full integration engine — great for event reactions, but heavy pipelines may still want a dedicated tool.
- Assuming managed = compliant — self-host vs cloud, you still own your regulatory posture (HIPAA/DPDP).
Key takeaways
- Medplum = an open, FHIR-native backend (datastore + auth + access policies + subscriptions + bots) so teams skip the plumbing.
- Developer-first (TypeScript/React); HAPI is the Java reference server — pick by stack and goal.
- Standards-correct by construction, because the datastore is FHIR.
- Self-host (Apache 2.0) or managed — either way, access control is yours to design.
Check your recall
0 of 2 recalledActive recall beats re-reading — try to answer, then reveal.
What does Medplum give a health-app developer out of the box?
Medplum vs HAPI FHIR — who is each for?