Last updated

August 30, 2026

•

8 min read

Medplum Design System: bridging frontend & FHIR for custom EHRs

Amanda Savluchinske

Product Manager

Summarize with ChatGPT

Table of Contents

Key Takeaways

What it is: The Medplum Design System is a free, open-source Figma library that maps one-to-one to Medplum's React/Mantine component code, so designers and developers work from the same source of truth.
Who it's for: Healthcare founders, Clinical Operations (ClinOps) leaders, and design-engineering teams building or modernizing an EHR who need workflow control without building a frontend from zero.
When to use it: Choose Medplum + this design system over an off-the-shelf EHR when your workflows are non-standard, role-based UX matters, or you need FHIR-native interoperability — and choose it over a fully custom build when you want to avoid the budget and timeline risk documented in EHR/data migration research (see References).
Core benefit: It cuts the design-to-development handoff gap, because every Figma component carries the same name and props as its real Medplum Storybook counterpart.
Tool stack: Medplum (FHIR-native backend + React components) + Mantine (UI library) + Figma (design system) + Storybook (living component library), wrapped around a Product Discovery process.
Typical timeline to MVP: Roughly 8–14 weeks from kickoff to a validated build — 1–2 weeks of discovery, 2–3 weeks of design and component mapping, 1–2 weeks of prototype validation, and 4–8 weeks of build, run partly in parallel with compliance review.
Where to get it: The design system is open-source on the Medplum Design System Figma Community file, and the underlying components live in the Medplum React Storybook.

‍

What is Medplum and how does it differ from off-the-shelf or white-label EHRs?

Medplum is an open-source, FHIR-native developer platform that gives engineering teams the building blocks for a custom EHR instead of a rigid, pre-built one.

Launched in 2021, Medplum provides a FHIR R4 datastore, REST and GraphQL APIs, OAuth 2.0/SMART on FHIR authentication, and a React component library — all released under the Apache 2.0 license. Unlike white-label EHR products, which lock teams into pre-defined workflows and screens, Medplum is built API-first so every workflow, role-based view, and UI screen can be assembled to match how a specific care team actually operates. It ships with HIPAA- and SOC 2 Type II–aligned compliance infrastructure out of the box, and it's ONC-certified.

This matters most where clinical settings diverge from generic templates: a hospital may need fast, tablet-friendly charting, while a telemedicine network prioritizes scheduling, secure messaging, and real-time patient updates. Medplum's modularity lets both be built on the same backend without forcing either into the other's mold.

When should you customize an EHR versus buy off-the-shelf?

Customize when your workflows, roles, or interoperability needs are structurally different from what a pre-built system supports — buy off-the-shelf when they aren't.

Off-the-shelf EHRs are a legitimate, cost-effective starting point, and they cover a wide range of standard clinical scenarios well. They start to break down when operations grow past what the vendor anticipated: specialty clinics with unusual intake processes, research institutions with custom data collection needs, or organizations trying to cut clicks out of high-volume, role-specific tasks.

The alternative (building a fully custom EHR from scratch) carries its own, well-documented risk. Bloor Research's widely cited data migration survey found that more than 80% of data migration projects run over time or over budget, with average cost overruns of roughly 30% and average schedule overruns of roughly 41% (Bloor Research, cited via bloorresearch.com). EHR migrations inherit this same risk profile, and in a startup context, a blown timeline doesn't just cost money — it can delay go-to-market plans, jeopardize a funding round, or stall user adoption.

Medplum + Mantine + the Design System is positioned in the middle: more flexible than an off-the-shelf product, without inheriting the budget and timeline risk of building a compliant, interoperable EHR entirely from zero.

Should you customize your EHR now? A decision checklist

Answer yes or no to each item:

Do more than one clinical role (providers, front desk, care coordinators) need meaningfully different views of the same patient data?
Does your care model include workflows an off-the-shelf EHR doesn't support out of the box (non-standard intake, remote monitoring, specialty charting)?
Do high-volume tasks central to your business (scheduling, charting, triage) need fewer clicks or steps than a generic EHR gives you?
Do you need to exchange FHIR-based data with more than one external system (labs, payers, health information exchanges)?
Is the patient or provider experience a competitive differentiator for your product, not just an operational necessity?
Have you already tested at least one off-the-shelf or white-label EHR and found it structurally unable to support a core workflow — not just missing a minor feature?
Do you have, or can you contract, engineering capacity comfortable with FHIR, and API-first architectures?
Do you need HIPAA- and SOC 2-aligned compliance from day one, with visibility into how that compliance is implemented — not inherited as a vendor black box?
Will you need to scale across multiple clinical settings or specialties, each requiring a different workflow variant?
Would an 8–14 week build-to-MVP fit your funding or go-to-market timeline meaningfully better than a 12+ month fully custom build?

Rule of thumb: 5 or more "yes" answers suggest Medplum-based customization is likely the better path than either an off-the-shelf EHR or a fully custom build from scratch.

Off-the-shelf vs. fully custom vs. Medplum + Mantine + Design System

Ratings are qualitative, derived from the claims and figures discussed in this article.
Attribute	Off-the-shelf EHR	Fully custom EHR	Medplum + Mantine + Design System
Time to MVP	Fastest — days to weeks (configuration only)	Slowest — often 12+ months, with ~41% average schedule overrun risk	Moderate — roughly 8–14 weeks including discovery and compliance review
Cost profile	Lowest upfront, but licensing scales with usage and customization requests	Highest upfront and ongoing; ~30% average cost overrun risk on migrations	Mid-range — cost concentrated in build phase, less spent on compliance/backend plumbing
Interoperability	Varies by vendor; often proprietary APIs or limited FHIR support	Fully controllable, but must be built and maintained in-house	Native FHIR R4 support out of the box via Medplum's API
UX control	Low — limited to vendor's configuration options	Full — every screen and interaction is bespoke	High — Figma/Storybook mapping gives granular control while reusing proven components
Compliance	Inherited from vendor, limited visibility into implementation	Fully owned, but must be built, tested, and certified from scratch	HIPAA and SOC 2 Type II–aligned infrastructure included; compliance review is a discrete step
Extensibility	Low — constrained by vendor roadmap	High, but every extension is custom-built and custom-maintained	High — modular, API-first architecture designed for extension
Team skill requirements	Low — mostly configuration and admin skills	High — full-stack team fluent in healthcare compliance and interoperability	Moderate — React/TypeScript and FHIR familiarity, accelerated by pre-built components

Ratings are qualitative and derived from the claims and figures discussed in this article; actual results vary by team size, scope, and existing technical debt.

How does Mantine map to Medplum's UI, and what is Storybook's role?

Medplum's UI layer is built on Mantine, and its React Storybook documents every resulting component, but only in code, which is why a Figma-side design system exists.

Mantine is an open-source (MIT-licensed) React component library offering more than 120 customizable components and 70+ hooks, with a large open-source community (over 30,000 GitHub stars and 5M+ monthly downloads on its core hooks package as of this writing).

It gives Medplum cross-browser compatible, accessible components with theming support, so Medplum's engineering team doesn't rebuild basic UI primitives from scratch. Mantine itself lists Medplum among its official sponsors, reflecting the depth of that dependency.

Medplum uses Mantine to build its React Storybook — a living library where components like SearchControl, ResourceTable, PatientTimeline, and ResourceHistoryTable can be inspected in isolation, with their real props and states.

The problem: Storybook lives in the codebase. Designers working in Figma have no direct line of sight into it, which is exactly the gap the Medplum Design System was built to close; a two-week delivery deadline on a real client project made that gap impossible to ignore.

What is the Medplum Design System, and what does it include?

It's an open-source Figma library where every component is mapped, name-for-name, to a real Medplum/Mantine code component, so a Figma prototype and a developer's implementation stay in sync automatically.

Vinta built the Medplum Design System on top of Mantine and Medplum's Storybook components specifically so that a design decision made in Figma is technically feasible and FHIR-aligned before a single line of code gets written. Because component names match the codebase, handoff between design and engineering doesn't require a re-translation step.

Design system inventory

A flat list of what's inside, and where each piece lives:

Artifact	What it is	Open-source?	Where to find it
Design tokens	Single-source values (spacing, radii, sizing) that propagate across every component when changed once	Yes	Figma Community file
Typography scale	Predefined heading/body text styles aligned with Mantine's type system	Yes	Figma Community file
Color themes & variables	Branding-ready color variables that can be swapped at a single point of change	Yes	Figma Community file
Light and dark modes	Pre-built theme variants for both color schemes	Yes	Figma Community file
Personas	Editable sample user/patient data that updates across an entire flow from one change point	Yes	Figma Community file
FHIR field patterns	Structured components for FHIR-shaped data, like patient names and addresses	Yes	Figma Community file
Workflow templates	Reusable screen patterns for charting, scheduling, and intake	Yes	Figma Community file
Accessibility guidance	Inherited from Mantine's built-in accessibility features, applied consistently across components	Yes (inherited from Mantine)	Mantine docs
Real code components	Every Figma component's counterpart, implemented and documented	Yes	Medplum React Storybook

Together, these let a design team validate a workflow (and a simplified working prototype) often within the first few weeks of a project, before development budget is fully committed.

‍

Real-world applications: EHRs built with this stack

Rewind (Type 2 diabetes reversal program): needed an EHR that could replace Healthie and be FHIR-compliant. Vinta implemented a fully customizable Medplum-based system, improving charting, provider messaging, and patient interactions. Read more.

‍

Quilted Health (maternal care): needed to migrate off a 14-year-old legacy system onto a modern FHIR-based EHR. Vinta used Medplum's headless architecture to build a future-proof, HIPAA-compliant platform with interoperability built in from day one. Read more.

How to implement it: the Medplum + Mantine playbook

A numbered sequence from kickoff to launch, with expected duration, inputs, and outputs for each step.

Discovery — 1–2 weeks. Input: stakeholder access, existing workflow documentation, any current EHR/system to migrate from. Output: validated problem statement, prioritized workflow list, and a go/no-go recommendation on customization (use the decision checklist above).
Figma & theming — 1 week. Input: brand guidelines, discovery findings. Output: a themed instance of the Design System (color variables, typography, and personas configured for the client).
Component mapping to Medplum Storybook — 1 week. Input: the themed Figma file. Output: each screen's Figma components matched to their Storybook equivalents (e.g., SearchControl, ResourceTable), flagging any gap that needs a custom component.
Prototype validation — 1–2 weeks. Input: mapped Figma prototype. Output: stakeholder and end-user feedback, a validated workflow design, and a locked scope for build.
Build — 4–8 weeks. Input: validated prototype, component mapping. Output: a working application using real Medplum/Mantine components, wired to FHIR resources.
Compliance review. Input: built application. Output: verification against HIPAA and SOC 2-aligned controls before go-live; can run partially in parallel with the later part of the build.
Launch. Input: reviewed, compliant build. Output: production deployment and handoff to the client's team.

Definitions

Short reference for terms used throughout this article.

EHR (Electronic Health Record): Digital software that stores and manages patient health information (charts, orders, scheduling, and communication) replacing paper records.
FHIR (Fast Healthcare Interoperability Resources): An HL7-maintained, API-based standard for structuring and exchanging health data electronically between systems, built on typed resources like Patient, Appointment, and Observation.
Medplum: An open-source (Apache 2.0), FHIR-native developer platform that provides a hosted or self-hostable backend, React component library, and compliance infrastructure for building healthcare applications.
Mantine: An open-source React component library (MIT licensed) offering 120+ accessible, themeable UI components and 70+ hooks, used by Medplum to build its React component library.
Storybook: A tool for developing and documenting UI components in isolation; Medplum's public Storybook shows every React component it ships, with live props and variants.
HIPAA (Health Insurance Portability and Accountability Act): U.S. federal law whose Privacy and Security Rules set national standards for protecting patients' health information, applying to covered entities and their business associates.
SOC 2: An auditing standard (AICPA) that evaluates a service organization's controls around security, availability, and confidentiality of customer data; SOC 2 Type II confirms those controls operated effectively over a period of time.
Product Discovery: A structured, time-boxed process (UX research, stakeholder workshops, and technical assessment) used to validate whether a custom build is the right call before committing engineering budget.‍
FHIR-aware design constraints: FHIR's search and filtering capabilities are powerful but not unlimited, especially across related resources. A common example: FHIR does not offer a native "next upcoming appointment" sort, so the design system builds this behavior with a toggle between future and past appointments rather than a single sortable field. Baking this kind of constraint into the design system upfront keeps prototypes technically feasible instead of promising interactions FHIR can't cleanly support later.

References

Bloor Research, Data Migration Customer Survey (findings widely cited, including on bloorresearch.com/research/data-migration) — source for the "over 80% of data migration projects run over budget or schedule" statistic used in this article.
Medplum, "Why Medplum Is Open Source" — Medplum Inc., accessed 2026.
Medplum, medplum.com — product site; source for HIPAA/SOC 2/ONC compliance and platform scale claims.
Mantine, mantine.dev — Mantine (Vitaly Rtishchev and contributors); source for current component count, hooks, GitHub stars, and download figures.
Medplum, React Storybook — source for named React components referenced in this article.
Vinta Software, Medplum Design System — Figma Community file — the open-source design system discussed throughout.
U.S. Department of Health and Human Services, "Summary of the HIPAA Privacy Rule" — HHS.gov.
HL7 International, FHIR Overview — hl7.org.
Vinta Software, Rewind case study and Quilted Health case study — vintasoftware.com

Table of Contents