Medplum

Medplum is an open-source healthcare developer platform built around a FHIR-native backend, giving engineering teams a compliant Clinical Data Repository (CDR), API, and SDKs instead of forcing them to build one from scratch. Where legacy Electronic Health Record systems like Epic Systems ship as closed, monolithic platforms that hospitals configure rather than extend, Medplum (a YC S2023 company) is a full-stack TypeScript monorepo that developers can self-host, fork, and integrate directly into custom clinical, telehealth, and health-tech products.

The platform bundles the pieces a healthcare app actually needs: Medplum Auth for OAuth/OpenID/SMART-on-FHIR identity, a FHIR-based Medplum API for reading and writing clinical data, client SDKs and a React component library for building patient- and provider-facing UIs quickly, and Medplum Bots — serverless functions triggered by FHIR Subscriptions — for wiring up integrations like eligibility checks, e-prescribing, or lab result processing without standing up separate infrastructure.

Interoperability is treated as a first-class concern rather than an afterthought: the server implements FHIR R4 search semantics with a custom Postgres query layer, HL7v2 and C-CDA conversion for talking to legacy hospital systems, FHIRcast for real-time context sync with EHRs and PACS viewers, and an on-premise Agent binary for bridging medical devices that can’t reach the public internet directly. Compliance documentation spans SOC2 Type II, HIPAA, ONC certification, HITRUST e1, ISO 9001, and CFR Part 11, reflecting real deployments in clinical and regulated settings.

With over 2,500 GitHub stars, 100+ tagged releases, and a release cadence of multiple ships per week, Medplum is actively used to power production products ranging from patient intake and scheduling apps to lab and pharmacy integrations, and it ships more than twenty reference example apps (including a full patient portal, SMART on FHIR demo, and pharmacy/lab integrations) to jump-start new builds.

What You Get

• A FHIR R4-compliant Clinical Data Repository (CDR) with a Postgres-backed search implementation that maps FHIR SearchParameters onto typed, indexed database columns
• Medplum Auth: an OAuth2/OpenID Connect and SMART-on-FHIR identity provider for patients, practitioners, and third-party apps
• Client SDKs (@medplum/core) plus a React component library and hooks package (@medplum/react, @medplum/react-hooks) for building clinical UIs fast
• Medplum Bots — serverless TypeScript functions triggered by FHIR Subscriptions for webhooks, scheduled jobs, and custom FHIR operations
• The Medplum App, a ready-to-use web console for viewing and editing FHIR data and managing users, projects, and access policies
• An on-premise Agent for connecting legacy hospital devices and HL7v2/DICOM endpoints to the cloud FHIR API
• Interoperability tooling: HL7v2 parsing, C-CDA import/export, FHIRcast context sync, and a GraphQL endpoint over FHIR resources
• Infrastructure-as-code for self-hosting on AWS (CDK), GCP/Azure (Terraform), Ubuntu (APT), Docker, or Kubernetes (Helm)

Common Use Cases

• Building a custom EHR, patient portal, or clinician-facing app on top of a standards-compliant FHIR backend instead of building data storage and auth from scratch
• Powering telehealth, remote patient monitoring, or digital health startups that need HIPAA-aligned infrastructure without a multi-year build
• Automating clinical workflows (eligibility checks, e-prescribing via Photon, lab orders/results) using Bots triggered by FHIR Subscriptions
• Integrating legacy hospital systems and medical devices (HL7v2, DICOM) with modern cloud applications via the on-prem Agent
• Running a self-hosted, data-sovereign FHIR server for research, medical devices, or regulated environments that can’t use a third-party cloud

Under The Hood

Architecture Medplum is organized as a layered, modular TypeScript monorepo: HTTP routes in the server package delegate to per-resource FHIR operation handlers, which call into a central Repository data-access layer (fhir/repo.ts) that evaluates project-level AccessPolicy and ProjectMembership rules before any SQL is executed, then hands off to a dedicated query-building layer (fhir/sql.ts, token-column.ts, range-column.ts, sharding.ts) that translates FHIR search semantics into Postgres queries. Shared logic that both the server and browser clients need — FHIR types, FHIRPath evaluation, search-request parsing — lives in an isomorphic @medplum/core package, while a separate @medplum/fhir-router package isolates the URL-routing and batch/transaction logic so it can be reused outside the main server. Background work (subscriptions, downloads, bulk exports) runs through BullMQ workers backed by Redis, decoupling slow operations from the request/response cycle. Changing the core FHIR resource model would ripple through nearly every package, since fhirtypes, core, fhir-router, server, and the react UI library all depend directly on it — a deliberate tradeoff for keeping FHIR compliance consistent everywhere.

Tech Stack The stack is full-stack TypeScript managed as an npm workspace monorepo with Turborepo orchestrating builds, tests, and caching across roughly two dozen packages. The server runs on Node.js with Express, PostgreSQL as the system of record (with denormalized, typed columns per FHIR search parameter for query performance), and Redis plus BullMQ for background jobs and real-time subscription delivery. OpenTelemetry instrumentation is wired through HTTP, GraphQL, Postgres, and Redis calls for tracing and metrics export. Cloud integrations span AWS (S3, Lambda, SES, Secrets Manager, Textract, Comprehend Medical, CloudFront), Azure (Key Vault, Blob Storage), and Google Cloud (Secret Manager, Storage), reflecting genuine multi-cloud self-hosting support rather than a single-vendor lock-in. The frontend is React with a Vite build pipeline, a Mantine-based component library (@medplum/react), and a companion hooks package, plus a bundled GraphiQL instance for exploring the GraphQL API. Deployment artifacts include AWS CDK stacks, Terraform for GCP/Azure, an Ubuntu APT repository, Docker images, and Kubernetes Helm charts.

Code Quality The repository has an extensive automated test suite — hundreds of colocated *.test.ts files exercising routes, repository logic, search behavior, and access control with Vitest — plus dedicated CI workflows for CodeQL security scanning, OpenSSF Scorecard, SonarCloud quality gates, Coveralls coverage tracking, Chromatic visual-regression testing for the UI library, and Madge circular-dependency checks. Linting is enforced through both Biome and ESLint with the TypeScript preset, and TSDoc conventions are used for public API documentation. Contributions require a Developer Certificate of Origin and follow a documented local-dev and testing workflow. Together this reflects a genuinely mature, CI-heavy engineering process rather than a lightly-tested side project.

What Makes It Unique Most open-source attempts at FHIR servers either wrap a generic document store or implement search naively against JSON blobs; Medplum instead compiles FHIR SearchParameters into typed, indexed Postgres columns and dedicated lookup tables, giving it search performance closer to a purpose-built relational schema while staying fully FHIR-compliant. That’s paired with capabilities rarely bundled together in one open-source project: an on-premise Agent binary for bridging legacy hospital devices that can’t reach the public internet, native FHIRcast support for real-time EHR/imaging context sharing, HL7v2 and C-CDA conversion for legacy interoperability, and a documented compliance program (SOC2 Type II, HIPAA, ONC, HITRUST, CFR Part 11) that goes well beyond what most infrastructure-focused open-source projects publish.

Self-Hosting

Licensing Model Apache License 2.0 across the entire monorepo — the server, core libraries, React UI kit, CLI, and on-prem Agent are all fully open source under one license, with no separate proprietary “enterprise edition” or dual-licensed packages found in the codebase.

Self-Hosting Restrictions

• No license keys or code-level feature flags were found gating functionality in the self-hosted server; a Super Admin can enable any project-level feature — including Bots — directly from the Medplum App at no cost.

Enterprise Features

• None are documented as self-hosting-only paid add-ons; the open-source repo is the same code Medplum runs for its own hosted service.

Cloud vs Self-Hosted

• On the Medplum Hosted Service, Bots are billed as a paid feature that must be enabled by Medplum on request, while self-hosted deployments can turn Bots on for free via a Super Admin project setting.
• Cloud-hosted Premium and Enterprise plans add managed operations (Medplum handles maintenance, patching, and scaling) plus log-streaming integrations with tools like SumoLogic and Datadog; Medplum’s own docs estimate self-hosters need roughly 0.5 FTE of ongoing operational effort to run the stack themselves.
• The hosted service also carries Medplum’s compliance certifications (SOC2 Type II, HIPAA, ONC, HITRUST e1, ISO 9001, CFR Part 11) out of the box; self-hosters are responsible for pursuing and maintaining their own certifications on their own infrastructure.

License Key Required No. Self-hosted deployments run without any license key — the only gating identified is the hosted-service-only paid Bots feature, not a restriction in the open-source code itself.