Building an EHR on Medplum: What You Get, What You Build and When to Skip It

Medplum is an open-source healthcare platform: a FHIR server, login and access rules, audit logs, serverless functions called Bots, a React component library and a sample clinician app. Most of it is free under the Apache 2.0 licence. If you want Medplum to host it, paid plans start at $2,000 a month (Production) and $6,000 a month (Premium), as listed on 27 October 2026.

Choose Medplum when you have a TypeScript team, your data model can live in FHIR, and you want to spend your budget on your own clinical workflow instead of plumbing. Skip it when you need a finished, configurable EHR that non-developers can run, or when you have no one who can work in FHIR.

This guide covers what Medplum gives you out of the box, what you still build for a real EHR, where it falls short, how to choose between self-hosting and Medplum's hosted service, and when not to use it at all.

What Medplum is, in one paragraph

Medplum calls itself "a healthcare platform that helps you quickly develop high-quality compliant applications" on its GitHub repository. It is the back half of an EHR, plus building blocks for the front half. The server stores every record as a FHIR resource (FHIR is the US standard format for exchanging health data). People in the industry call this a headless EHR: the clinical data engine without a fixed set of screens. The code is TypeScript on Node.js, and a server needs PostgreSQL and Redis underneath it. The latest published package at the time of writing was @medplum/core 5.2.9, released on 26 October 2026.

If you are still deciding whether to build an EHR at all, start with our guide to custom EHR software development. This page assumes you are building, and asks whether Medplum should be your base.

How an EHR built on Medplum fits together

An EHR built on Medplum has three layers. Your clinicians, patients and partner apps use the app you build. Medplum sits in the middle: it stores every record as a FHIR resource, decides who can see what, logs access as audit events and runs your automation. Around it sit the outside systems every US practice needs: labs, an e-prescribing network, a clearinghouse or billing partner, and the larger EHRs and health information exchanges that hold your patients' records.

In the simplest design, Medplum is the only system of record. Your app reads and writes FHIR through the Medplum API, and each integration reads and writes the same records through Bots. That keeps the data in one place and ready for FHIR APIs and AI tools from the first day.

What you get out of the box

Here is what Medplum provides today, checked against its own documentation on 27 October 2026.

A FHIR server with an API. Medplum's open-source page lists the FHIR server, core APIs, developer SDKs, the React component library, command-line tools, and documentation and examples as Apache 2.0 software.

Login, access rules and audit. Medplum's certified product covers authentication and access control, auditable events, audit reports, automatic timeout, emergency access and multi-factor login, among other criteria listed on its ONC certification page. ONC is the US federal office that certifies health IT.

Bots for your own logic. Bots are small functions that run when something happens in the data. Medplum's docs say they are "similar to AWS Lambda functions" and that they "drive many of the major integrations" on the platform. On the hosted service, Bots are a paid feature and must be switched on for your project.

A clinician app you can fork. Medplum Provider is an open-source web app for clinical and operations staff. Medplum says you can use it "as your system of record, as a starting point, or as an implementation reference". One command (npm init medplum) copies it into a repository you own. Its documented features today are patient profiles, a schedule, visits, tasks and an AI workspace called Spaces. Messages, labs and medications are listed as "Documentation Coming Soon."

React components. The component library is built on Mantine, a React UI kit. The @medplum/react package in the Medplum repository depends on Mantine 8. If your team already uses another UI kit, plan for that mismatch.

A catalog of integrations. The integrations page lists first-party connectors for e-prescribing (DoseSpot, ScriptSure), billing (Candid Health, Stedi), labs (Health Gorilla, Labcorp, Quest), fax, SMS, SSO providers and Epic's FHIR API. For HL7 v2 feeds from hospitals and labs, the Medplum Agent runs inside your network and relays messages over a secure connection.

Compliance paperwork for the hosted service. Medplum states it has SOC 2 Type II, HITRUST e1 for its AWS-hosted platform, and an ONC certification for "Medplum, 5" dated 31 December 2025 (certification number 15.04.04.3147.Medp.05.03.1.251231, per its ONC page). Its HIPAA page offers a BAA template. A BAA (business associate agreement) is the contract HIPAA requires with any vendor that handles patient data.

What you still have to build for a real EHR

This is where most of your budget goes. Medplum's decision guides describe the split clearly, and we quote them below.

Scheduling

Medplum's scheduling guide says: "Medplum provides availability calculation and atomic booking operations. Your application supplies business rules such as licensure checks, patient preferences, approval workflows, and integrations." The same page says the scheduling APIs are in beta. Beta means the shape can change between releases, so pin your version and read the changelog before every upgrade.

Billing hand-off

Medplum's billing guide sums it up: "a clearinghouse moves your claims; an RCM platform runs your revenue cycle." In its own table, coverage and charge capture are marked "You build" in every model, including the one where an outside billing system does the rest. If you connect straight to a clearinghouse, you also build claim scrubbing, remittance posting, denials and AR reporting. If you hand off to an RCM partner, the partner owns the back half and sends billing tasks back into Medplum.

For most clinics we would hand off to an RCM partner or the practice's existing billing system. Building a full back office is a product of its own.

E-prescribing

Medplum says e-prescribing "is part of the Medplum EHR, not a standalone product" and runs through a vendor on the Surescripts network. Two details catch teams late:

• Controlled substances need a separate enrollment for each prescriber, with identity proofing and two-factor login, before they can send.
• Only professionals authorized to prescribe in the United States can prescribe. Staff outside the United States can hold only support roles, and even those need vendor enrollment.

Specialty templates

Medplum's charting guide recommends one visit template per visit type, built from structured forms, with free text kept for the assessment. That is a sound design. It also means a dermatology, behavioral health or orthopedic EHR needs its own template library, screening forms and order sets. Medplum gives you the frame. Your clinicians and your team fill it.

Interfaces

Medplum says "any system that exposes an API (REST/FHIR), HL7, or SFTP interface can be connected", with the logic written as Bots that you own. That is flexible. It also means each lab, hospital or HIE feed is your code to map, test and watch. Budget each interface as its own small project.

How to build an EHR on Medplum, step by step

This is the path we recommend for a first release. Each step names the Medplum feature that does the heavy lifting.

1. Map one care setting. List the visit types, the roles that touch each visit and the forms each one needs. Keep the first release to one specialty.
2. Model the data in FHIR. For each visit type, decide which Questionnaires, Observations, Conditions and orders it creates. Medplum's charting guide recommends one visit template per visit type.
3. Set up projects, access policies and sign-in. Decide roles, care-team visibility and single sign-on before you build screens. Sign-in was the part we underestimated on our own build.
4. Start from the Provider app or the React components. npm init medplum copies the open-source Provider app into a repository you own.
5. Add scheduling rules. Use the scheduling APIs for availability and booking, and add your own visit types, hours and reminders. The APIs are in beta, so pin your version.
6. Connect the outside systems. Add the e-prescribing vendor, labs through the Medplum Agent, and a clearinghouse or billing partner. Write each mapping as a Bot with its own error queue.
7. Add the admin layer. Build admin screens for templates and users, audit review and the reports your practice needs.
8. Test, migrate and go live. Run real clinical scenarios with clinicians, load and check migrated data, choose hosting and plan support.

Adding SMART on FHIR apps

Medplum supports the SMART App Launch standard, so partner apps and your own tools can open inside your EHR with the current patient already selected. The app receives a token limited by your access policies, so it reads only what each policy allows.

This is also how you add new tools later without rebuilding the EHR: a scheduling widget, a remote monitoring dashboard or a clinical calculator can each launch as a SMART app.

Automating work with Bots and Subscriptions

Subscriptions watch the data. When a record matching a rule is created or changed, Medplum runs the Bot attached to it. Bots are TypeScript functions that Medplum compares to AWS Lambda functions. The Medplum Agent runs inside a hospital or lab network and relays HL7 v2 messages to and from your Bots, which is how most lab interfaces work on Medplum.

Give every inbound Bot an error queue. When a result cannot be matched to a patient or an order, it should become a task for a person to resolve. The same pattern works for AI tools that read and write clinical data, which we cover in our guide to building AI agents on FHIR data.

Where Medplum falls short

Plan for each of these costs.

It is a developer platform. Medplum's charting docs say "Medplum is headless: your app owns the screens." Forms and workflows are set up by developers. If your clinic expects an admin to build templates in a settings screen, you will be building that screen.

FHIR is not hidden from you. Your team works in FHIR resources directly. That pays off later for data exchange and AI work. In the first month it slows down developers who have never used FHIR.

Some core areas are new. Scheduling is in beta. The Provider app's labs, medications and messages documentation is marked "coming soon." Expect those parts to change, and test them against each new release.

The UI kit is fixed. The component library is tied to Mantine. You can use other React code, but the ready-made pieces assume Mantine.

Premium integrations sit behind a contract. The integrations page says premium connectors such as Health Gorilla and ScriptSure are available to self-hosted teams on the Enterprise plan. On paid hosted plans, e-prescribing, labs and HIE come with a usage allowance, and fax and clearinghouse traffic carry usage fees, per the pricing page.

Certification does not copy itself onto your product. Medplum's ONC certification is for its own product. The pricing page lists "ONC-Certified EHR: Available under your Medplum agreement" and separate "ONC Certification Guidance" for custom apps and self-hosted setups. If your buyers need certified EHR technology, confirm in writing with Medplum what your specific build can claim.

Licence and hosting: self-host or Medplum Cloud

The licence

The core code is Apache 2.0. You may use it, change it and sell products built on it, and you are not forced to publish your changes. Medplum's open-source page says hosted infrastructure, enterprise support, and integrations and custom work need a commercial relationship.

Self-hosting: free code, real running costs

You can run Medplum on your own servers without paying Medplum anything. Medplum's own guide, Should you Self-Host?, lists what that means in practice:

• "A single server version upgrade can run from one week to one month" of a dedicated engineer's time, and Medplum ships often.
• Major upgrades of PostgreSQL and Redis can take "a couple days to a full month" of a dedicated engineer.
• "Your team will need 24/7 on-call coverage for outages."
• The certifications on Medplum's Trust Center apply to "Medplum's hosted environment and how we operate it, not the open-source code itself."

So if you self-host, your HIPAA controls, BAAs with your cloud provider, audit evidence and security reviews are yours to produce. Medplum's HIPAA page says its documents "apply to the Medplum hosted environment."

Medplum is a vendor with a hosted product to sell, so read its self-hosting guide with that in mind. We think its list of running costs is fair. Medplum says self-hosting makes sense for strict data-location or contract rules, low-connectivity or edge deployments, and education or non-production use.

Medplum Cloud: what the plans say

As listed on the pricing page on 27 October 2026:

Paid plans include a usage allowance, and extra usage is billed separately. The HL7 connection through Medplum Agent and the data warehouse connector are paid add-ons on every paid plan.

Our estimate, not Medplum's figure: at the listed starting prices, a year of hosting comes to at least $24,000 on Production or $72,000 on Premium, before usage, add-ons and integration fees. Ask Medplum for a quote at your expected patient and user volumes.

Medplum vs building from scratch vs HAPI FHIR or OpenEMR

This is our own comparison. Facts in each row come from the linked pages. The "effort" and "best for" rows are our judgement from building EHRs, not measured results.

The licence row matters most for OpenEMR. GPL-3.0 is a copyleft licence: if you distribute a changed version, the GPL can require you to share your changes under the same licence. Ask your lawyer how that applies to a hosted product before you fork it.

When not to use Medplum

Our advice is to pass on Medplum in these cases:

• You need a finished EHR next quarter and have no developers. Buy a product, or start from OpenEMR. Medplum assumes an engineering team.
• Your team writes Java or .NET and will not switch. HAPI FHIR or a cloud FHIR service fits that stack better.
• Your data does not fit FHIR. Medplum does not hide FHIR. If your core records are research datasets or device streams with no clinical shape, a custom schema may be simpler.
• You plan to self-host with a part-time ops person. Medplum's own guide describes recurring upgrade work and 24/7 on-call. If you cannot staff that, pay for hosting or pick another path.
• Your buyers need certified EHR technology on day one, and your contract with Medplum does not cover your build. Settle the certification question before you write code.
• Most of your product is billing. If revenue cycle is the product, Medplum's billing guide says you build the full back office yourself on the clearinghouse path. Look at billing platforms first.

What we learned building on Medplum

We built a provider platform for a digital health company on a Medplum FHIR server. Patients, practitioners, appointments, slots, care plans, lab results, messages and invoices are all standard FHIR resources on that server, with no private database beside it. It is a working MVP running against a development environment, not live in production.

We also run the same company's consumer health-records mobile app, which we took over from earlier vendors and keep shipping to the app stores. Working on both sides, the patient app and the provider platform, is where most of the lessons below come from.

Three lessons carry over to any Medplum build:

1. Let the FHIR server be the whole backend, and use transactions. Booking an appointment creates the Appointment and marks every affected Slot as busy in one FHIR transaction bundle, then emails the patient. Either everything is saved or nothing is, so there are no half-booked slots to clean up later.
2. Sign-in is the part we underestimated. The client already used Keycloak for single sign-on. Users sign in there, and the platform exchanges that sign-in for a Medplum token through an OAuth token exchange. If that exchange breaks, nobody can sign in, so plan and test it early.
3. No private database is a real choice with a real cost. It keeps your data portable and ready for FHIR APIs and AI tools from the first day. It also means reporting, search tuning and some admin views take more design work, because you cannot add a quick SQL table next to the FHIR store. Model each visit type's forms, observations and orders before designing screens.

What we would harden before production: configuration and secret handling that are fine for a development environment but not for live patient data.

We also maintain an open-source headless EHR with a FHIR R4 API and SMART App Launch. It passed 47 of 47 ONC (g)(10) SMART App Launch tests in Inferno on 11 June 2026. The code is at github.com/Nirmitee-tech/headless-ehr-fhir.

What a Medplum-based EHR costs to build

Hosting is only part of the bill. The larger part is the team that builds your templates, scheduling rules, eRx workflow, billing hand-off and interfaces.

Our published price bands for custom EHR builds, whichever base we choose with you:

We confirm a fixed price after a short discovery. Hosting fees, Medplum plan fees and vendor fees (e-prescribing, labs, clearinghouse) are separate.

Planning a Medplum EHR with us

If you are weighing Medplum against another base, bring us your specialty, your first three workflows and your hosting rules. We will work through the base choice with you in a short discovery and then confirm a fixed price. See prices and example screens on our custom EHR development services page, explore our healthcare interoperability and custom healthcare software development work, or talk to our team.

For the wider build decision, read our guide to custom EHR software development.