What a Medplum implementation involves
Standing up a self-hosted Medplum deployment means building a complete FHIR platform inside infrastructure you control. The core server is built on Node.js and TypeScript, uses PostgreSQL as its database and Redis as its cache, and is deployed on AWS with CDK and CloudFormation (the option the self-hosting documentation recommends), on Kubernetes, or through the other supported paths. Around that server you also configure identity through Medplum Auth, the web app and React component layer, Bots for server-side logic, and the HL7 client and server if your interfaces need them. Confirm each deployment path and its current status against the self-hosting documentation before you commit to one.
Teams usually start this work for one of three reasons: a new clinical application that needs a FHIR R4 backend, a planned replacement of a legacy integration layer, or a regulated build-out where the platform must exist before any clinical workflow goes live. Each trigger changes the order of work. A replacement project depends on how data enters the platform, while a regulated build-out depends on which controls and evidence exist from day one. Decide the trigger first, because it sets the sequence, the environments you need and the people who must sign off.
In-house versus partner is a question of where your skills already sit. Engineers with FHIR, Node.js or TypeScript experience can build the infrastructure, the Bots and much of the app layer without outside help. Partners are most often used for three areas: the sequenced upgrade path, since Medplum requires each minor version to be applied in order; data model decisions, such as profiles, extensions, access policies and resource design, which are hard to reverse once clinical data is loaded; and compliance evidence, which Medplum describes as a shared responsibility with customers. Ask any partner to show how they will handle each of these three areas in the written scope.
Some related work is planned separately. Moving existing clinical data, ongoing upgrades and support, identity and SSO detail, hardening and HIPAA readiness, and total cost of ownership each have their own treatment on this site. Use this section to decide whether you need those services, then scope them in their own statements of work so that the implementation quote does not absorb them by default.
What the work includes
A fixed-scope Medplum implementation is split into work packages that each end in a named deliverable. The list below shows what the client receives from each package and what to confirm before the scope is signed.
AWS infrastructure with CDK
Medplum's recommended self-hosting path on AWS uses CDK and CloudFormation. The package covers the stack, networking, environments for development, staging and production, and the deployment pipeline. Clients receive an architecture document and deployed environments, and should confirm which AWS accounts, regions and network boundaries are in scope.
Kubernetes deployment path
Where the organization runs Kubernetes, the package covers the Medplum deployment, ingress, secrets handling and configuration for the cluster the client controls. Clients receive manifests or charts, a deployed environment and a runbook. Confirm which Kubernetes distribution and cluster ownership model apply before choosing this path over AWS CDK.
PostgreSQL and Redis setup
Medplum uses PostgreSQL as its database and Redis as its cache. This package sizes, provisions and configures both services, including backups, access controls and failover design. Clients receive a configuration specification and tested backup and restore procedures. Confirm managed service versus self-run operation, since that choice drives ongoing operations effort.
FHIR R4 resource model and profiles
This package maps the organization's clinical and administrative data to FHIR R4 resources, defines profiles, extensions and value sets, and sets search parameter and access expectations. Clients receive a resource model specification that their clinical and data governance owners sign off. Scope depends on how many resource types and source systems are involved.
Bots for server-side logic
Bots run server-side logic in Medplum, such as validation, routing, enrichment and integration tasks. The package defines which logic belongs in Bots, builds and tests them, and configures their triggers and permissions. Clients receive a configured Bot set with source, test coverage notes and a deployment procedure. Confirm the number and complexity of workflows during scoping.
React and SDK app layer
This package builds the application layer on Medplum's SDK and React component library, including authentication flows and the screens staff or patients use. Clients receive source code, a deployed front end and component usage guidance. Confirm how many applications, user roles and device types are in scope, since these drive most of the effort.
HL7 client or server
If the organization exchanges HL7 v2 messages, this package configures Medplum's HL7 client or server, defines message mappings, and tests acknowledgements and error handling. Clients receive a message interface specification and test results. Confirm the message types, sending systems and transport requirements before scoping, since these set the effort.
Operational runbooks and handover
The final package gives operators the procedures to run the platform: deployment, upgrades through each minor version in sequence, backups, incident response and access changes. Clients receive runbooks, a handover session and a list of open risks. Confirm who on the client side will own each runbook after handover.
What drives cost and duration
The table lists the factors that move the effort and cost of a self-hosted Medplum build, why each one matters, and how to keep it under control in scoping.
| Driver | Why it moves the price | How to keep it down |
|---|---|---|
| Target deployment path | AWS CDK with CloudFormation is the vendor's recommended self-hosting route. Kubernetes, Docker, and the Terraform-based GCP and Azure paths (marked Beta) each add platform engineering, testing, and ongoing maintenance work. | Standardize on the recommended AWS route unless a cloud or data residency rule requires otherwise. Confirm the Beta status of GCP and Azure paths before committing. |
| FHIR resource types and profiles | Each resource type, extension, and profile needs mapping, validation rules, and test data. Broad or highly customized profiles increase design sessions and test cases. | Limit the first release to the resource types your use cases need. Defer optional profiles to a later phase. |
| Number of Bots and external integrations | Each Bot carries code, secrets handling, error paths, and testing. Each external system adds interface specifications, credentials, and monitoring. Integrations are often the largest share of build effort. | Inventory integrations early, rank them by business need, and build the core flows first. Reuse one pattern for similar Bots. |
| App layer scope | Custom React apps built on the Medplum component library need UI design, access control checks, and browser testing. Each additional app adds release and support work. | Start with the Medplum web app and one custom app for the highest priority workflow. Add others after the first release is in use. |
| Number of environments | Each environment (development, test, staging, production) requires its own infrastructure, configuration, data seeding, and deployment runs. Staging that matches production raises infrastructure cost. | Keep a minimal set of environments and automate provisioning with the CDK or Helm definitions so new environments are repeatable. |
| Identity provider choices | Medplum's own auth is the simplest path. External providers such as Google, Auth0, or Cognito, and domain-level corporate providers, require configuration, claim mapping, and testing for each login flow. Multiple external SSO providers are an enterprise feature. | Confirm the identity provider and its licensing before design. Use one identity provider for workforce access in the first phase. |
| Compliance evidence depth | Medplum documents HIPAA, SOC 2 Type II, and other programs, and compliance is a shared responsibility. Your own controls, logging, access reviews, and evidence collection add work that scales with the audit scope. | Agree the evidence list with your assessor before the build starts. Reuse the vendor's documentation for the controls it covers and document your own share. |
| Edition: Community or Enterprise Self-Hosted | Community self-hosting has no license fee, but your team or partner carries all operational work. Enterprise Self-Hosted is custom-priced and adds vendor-side terms and support. The license cost comes from a quote, not a list price. | Ask the vendor for an Enterprise Self-Hosted quote with the same written scope as the Community option so the comparison is fair. Include run costs for both. |
Project phases and outputs
The sequence moves from agreed architecture through a repeatable environment, a validated data and access model, tested Bots and app code, and evidence preparation to a supported cutover and handover.
Run discovery and architecture design
DeployOpen reviews your clinical workflows, data sources, identity requirements and hosting constraints with your architects and compliance leads, then documents the target design, including the hosting option (AWS with CDK or CloudFormation, Kubernetes, or another supported path), the PostgreSQL and Redis layout, and network boundaries. The step closes with a signed-off architecture document that both parties approve in writing.
Build the environment from infrastructure as code
The team builds non-production and production environments from version-controlled infrastructure as code covering compute, PostgreSQL, Redis, networking, secrets and logging, all inside your cloud account or data center. Each environment is provisioned from the same template and the output is a repeatable infrastructure template plus a deployed Medplum server that starts cleanly and passes health checks.
Design the FHIR data model and access policies
Working with your clinical and security owners, DeployOpen maps the FHIR R4 resources and extensions your use cases need, defines profiles and search parameters, and designs access policies per role, client and identity provider. The output is a FHIR data model specification and an access policy set that is reviewed and approved before it is configured in the environment.
Build the Bot and app layer
The team implements server-side Bots for validation, transformation and workflow logic, along with the React or SMART-on-FHIR applications your users need, and connects identity through the agreed provider. Each Bot and app is tested against the approved data model and access policies. The output is tested Bots, deployable app code and a record of test results.
Integrate and test end to end
Source systems, HL7 feeds and external services are connected to the platform and exercised with representative test data, including failure and reprocessing cases. DeployOpen runs functional, access control and performance checks and logs defects until the agreed acceptance criteria are met. The step closes with a signed test report and a defect list showing what remains open.
Prepare compliance evidence
DeployOpen assembles the technical evidence your compliance program needs, such as configuration baselines, access policy records, audit logging settings, backup and restore results, and patching procedures, mapped to the HIPAA or other frameworks you are assessing. DeployOpen prepares this material but does not issue audit reports or certifications, which remain with your independent assessor. The output is an evidence pack and a gap list.
Cut over and hand over
The team runs a rehearsed cutover plan with rollback steps, moves production traffic, and confirms operations are stable. Handover covers a runbook for deployments, backups, incident response and upgrades, plus training for your operators. Upgrades then follow the sequencing rule that minor versions are applied in order from the first deployed version, so the runbook includes that procedure. The output is a live system and a signed handover package.
What teams keep in-house and what they outsource
This table shows who usually owns each workstream in a self-hosted Medplum build, the skills each part needs, and which decisions stay with your clinical and security owners even when a partner does the build.
| Workstream | Usual owner | Skills each part needs |
|---|---|---|
| Infrastructure as code on AWS or Kubernetes | Partner builds, client platform team approves and operates | Cloud networking, IaC tooling, Kubernetes or AWS CDK and CloudFormation, secrets handling |
| PostgreSQL and Redis operations | Shared: partner sets up, client database team runs backups and restores | PostgreSQL tuning and point-in-time recovery, Redis configuration, failover testing, monitoring |
| FHIR data modeling and terminology choices | Clinical informatics lead decides, partner implements | FHIR R4 resource modeling, profiles, code systems such as LOINC and SNOMED CT, clinical workflow knowledge |
| Bot development in TypeScript | Partner builds, client engineering reviews and owns after handover | TypeScript and Node.js, FHIR API usage, error handling, testing of server-side logic |
| React app layer | Partner builds with client front-end team, client owns UX decisions | React, Medplum component library, accessibility standards, clinical usability review |
| Identity configuration | Client identity team decides, partner configures | OAuth, OpenID Connect and SMART-on-FHIR, identity provider administration, MFA and access policy design |
| Compliance evidence owners | Client compliance and security owners, partner prepares artifacts | HIPAA safeguards mapping, audit log review, control ownership, evidence collection for assessors |
| Clinical sign-off | Client clinical owners only, never delegated to a build partner | Clinical safety review, validation of data mappings against clinical intent, acceptance of workflows |
What usually goes wrong
Most Medplum delays and cost overruns trace back to a handful of planning decisions made early. Each card names a risk specific to a self-hosted Medplum deployment and the step that prevents it.
Planning from the latest major version
Teams often plan against the newest Medplum major release and skip the minor versions in between. Self-hosted Medplum must be upgraded through each minor version in sequence, and skipping versions causes startup failures. Ask for a written upgrade path from your starting version to your target before the infrastructure is sized.
Underestimating post-deploy data migration
Some upgrade steps run data migrations after the new version starts, and these can run for hours or days on large datasets. The effort is easy to miss in a plan that only counts installation. Ask the partner to estimate migration duration from a copy of your real data volume and to schedule it into the cutover window.
Data model changes late in the build
Resource profiles, extensions, search parameters and Bot logic all depend on how clinical data is modeled in FHIR R4. Changing the model after app development has started forces rework across the React front end, Bots and integrations. Freeze the data model design with clinical and compliance owners before build sprints begin.
Bots holding credentials or logic without review
Bots run server-side logic and may hold credentials for external systems. Bots deployed without code review, secret rotation or access limits can expose patient data or create untracked behavior. Require a review gate, a secrets store outside the code, and a documented owner for every Bot before it reaches production.
Shared responsibility gaps in compliance
Medplum's compliance documentation states that compliance is a shared responsibility between Medplum and its customers. Infrastructure, access policies, logging and backup procedures sit with the deploying organization. Build a responsibility matrix that assigns each HIPAA-related control to a named internal owner or to the partner, and confirm it with your assessor.
Unclear ownership of Redis and PostgreSQL backups
Medplum uses PostgreSQL as its database and Redis as its cache. Teams often assume a backup exists for both without assigning who runs it, where it is stored or how it is restored. Name an owner for each backup, document recovery point and recovery time targets, and test a restore into a separate environment.
Identity provider chosen after app development
Medplum supports its own identity provider, external providers, domain-level corporate identity and client credentials for integrations. If the provider is chosen after the apps are built, login flows, MFA and role mapping often need rework. Select the identity provider and its access model during planning, and confirm which options your plan includes.
How the work changes by starting point
A new build on AWS uses CDK and CloudFormation, which the Medplum self-hosting docs describe as the recommended option. Scope centers on the account structure, network layout and the Medplum deployment itself, with the data model and app layer added on top.
- Scope: VPC and account setup, CDK deployment, database and cache configuration, and DNS and certificates.
- Client supplies: AWS accounts with approved landing zone rules, a naming and tagging standard, and a decision on the identity provider.
- Risks that rise: Drift between CDK stacks and manual console changes, and unclear ownership of the PostgreSQL and Redis tiers.
- Confirm: Which CDK and Medplum release your build will pin, and how later minor upgrades will be staged.
When the client already runs Kubernetes, the work moves from building a platform to fitting Medplum into one. The Kubernetes path in the self-hosting docs is a starting point, and the cluster's own controls shape much of the design.
- Scope: Manifests or charts adapted to your cluster, ingress and TLS, secrets handling, and storage classes for PostgreSQL and Redis.
- Client supplies: Cluster access with a named platform owner, the ingress and certificate standard, and the choice between a managed or self-run database.
- Risks that rise: Conflicts between cluster policy and Medplum's requirements, and collisions when cluster upgrades overlap with sequential Medplum minor upgrades.
- Confirm: Which Kubernetes versions and distribution your team supports for the Medplum release you select.
Docker and Ubuntu APT installs suit single-host or small deployments. Infrastructure scope is smaller, but the hardening, patching and backup duties stay visible and largely sit with the client's own team.
- Scope: Host preparation, PostgreSQL and Redis setup, configuration, TLS termination and a tested backup routine.
- Client supplies: Host capacity, OS standards, a patching window, and an owner for database backups and restores.
- Risks that rise: Single points of failure, configuration drift across hosts, and slower recovery when the team has never restored the database.
- Confirm: Which Ubuntu release the Medplum APT repository currently supports, and whether Docker images will be pulled through an internal registry.
Restricted networks change how software arrives and how the platform reaches identity, logging and other services. The self-hosting docs mark the Terraform-based GCP and Azure deployments as Beta, so treat those paths as less proven than the AWS CDK route.
- Scope: Offline artifact transfer, internal package and image mirrors, egress rules, and a register of every external dependency.
- Client supplies: An approved transfer process, internal registries, access to an internal identity provider, and a sign-off path for each artifact.
- Risks that rise: Upgrades take longer because each release and dependency must be staged, and the transfer process must fit the vendor's 7-day target for critical security patches.
- Confirm: Which Medplum components need outbound access, and whether your change board accepts a Beta deployment path.
Two starting points share a data-movement problem: moving from Medplum's hosted cloud to self-hosting, or replacing an existing FHIR server or EHR with Medplum. Both change who runs the platform, and the clinical data work is covered in the migration topic, so this tab focuses on the operating shift.
- Scope: Environment build, export and load paths, cutover planning, and a parallel-run period agreed in writing.
- Client supplies: Access to the hosted tenant or source system, a named data mapping owner, and clinical sign-off on cutover.
- Risks that rise: Mapping errors and data loss, and long post-deploy migrations when a version change runs against a large dataset.
- Confirm: Whether leaving the hosted service affects your BAA or MSA terms, and how the hosted data will be exported and verified.
What the client needs to provide
The quote for a Medplum implementation depends on a short list of inputs that the client supplies before the scoping workshop closes. Without them, the partner can only price assumptions, and those assumptions tend to be the first thing that moves once work starts. Ask for each item in writing so the scope can name it. Start with cloud accounts and network approvals. Confirm which AWS accounts or Kubernetes clusters will host Medplum, who can grant IAM roles, and whether outbound access to the Medplum package sources and any identity provider is allowed. Approval lead times for accounts and firewall changes often decide the start date more than engineering effort does.
Name one accountable owner in each area: infrastructure, security, clinical content and compliance. The infrastructure owner decides the hosting pattern and backup location. The security owner approves network exposure, secrets handling and access policy. The clinical owner signs off on the data model and the meaning of each resource type. The compliance owner confirms which HIPAA evidence the organization needs. A missing owner usually shows up as a deferred decision, and deferred decisions add change requests to a fixed-scope quote.
Provide sample FHIR resources or a data dictionary for the records you expect to store, such as Patient, Encounter, Observation or custom extensions your teams already use. Include a short list of the Bots and apps you want, with the trigger, the data each one reads and writes, and any external system it calls. Bots and custom profiles drive most of the design and test effort, so an incomplete list is the most common source of later estimate growth.
Share your identity provider details (for example Okta, Azure AD, Google, Auth0 or AWS Cognito), the domain names that need corporate sign-in, and your rules for multi-factor authentication and client credentials. Also decide the edition and deployment target: the free Community option or Enterprise Self-Hosted, and whether the target is AWS with CDK, Kubernetes, or another supported method. Each decision changes the infrastructure, licensing and support lines in the quote, so ask the partner to show which line each one affects.
Common questions about Medplum implementation cost and effort
What drives the cost of a self-hosted Medplum implementation?
The main drivers are the target infrastructure, the size and shape of your data model, the number of Bots and integrations, and the identity and app work needed around the platform. Medplum is licensed under Apache 2.0, so the software itself carries no license fee in the Community option, but the surrounding work is paid for separately: cloud infrastructure, engineering time, and compliance preparation. Ask the partner to price each of these as its own line in the written scope so you can see what moves the total.
Can our own team implement self-hosted Medplum without a partner?
Yes, a capable platform team can deploy Medplum, since the self-hosting docs cover AWS with CDK and CloudFormation, Docker, Kubernetes and building from source. The harder part is the surrounding design: FHIR data modeling, Bot logic, identity integration, and a repeatable upgrade routine. Assess your team against those skills honestly. If the work is mostly deployment, in-house delivery is realistic; if it includes new clinical workflows and integrations, a partner can shorten the learning curve. Confirm which deployment target your environment requires before you decide.
How long does a Medplum implementation take, and why is it set in the written scope?
Duration depends on the deployment target, the number of resource types and workflows, the integrations, and how much data must be migrated. DeployOpen does not publish a timeline, because the length follows from the scope: phases, deliverables and client dependencies are agreed in writing before work starts. A fixed scope makes the schedule testable, since each phase has a defined output. Ask for the phase list, the client inputs each phase requires, and the acceptance criteria for each one.
What does the implementation need from our side?
Expect to provide cloud account access, network and DNS decisions, the identity provider you will use, clinical and compliance owners who can confirm the data model, and staff who will operate the platform after handover. Delays usually come from slow approvals and unresolved design questions, not from the build itself. Before signing, confirm who owns each input, how quickly decisions are needed, and who signs off the design.
Does the Community or Enterprise Self-Hosted edition change the implementation cost?
The edition changes the license and support terms more than the build itself. Medplum lists self-hosting as a free Community option or as custom-priced Enterprise Self-Hosted, and multiple external identity providers are listed as an enterprise feature. Check which identity and support features your design requires, because they can change the work. Ask the vendor to confirm the current edition terms in writing, and review the cost-of-ownership topic for recurring license and staffing costs.
What should we ask for in a Medplum implementation quote?
Ask for a written scope with named phases, deliverables, client responsibilities, assumptions and exclusions, plus a separate line for infrastructure you will pay directly. Also request acceptance criteria, the upgrade and support approach, and whether compliance evidence is included. For recurring costs such as patching, upgrades and support, see the Medplum upgrades and support topic and the cost-of-ownership topic. DeployOpen prepares systems and evidence for assessments but does not issue audit reports or certifications.
How DeployOpen scopes, builds and hands over Medplum
DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside your own cloud accounts, data centers or air-gapped networks, and that is how we approach a self-hosted Medplum FHIR platform. Each engagement starts from a written scope that sets out the infrastructure, data model, Bots and app layer you need.
How we scope
- Engagements are fixed-scope, with deliverables and timelines agreed in writing before any build work starts.
- The written scope names the hosting path, such as AWS with CDK and CloudFormation, Kubernetes or another target you control.
- Scope also covers the FHIR resource model, Bots, identity integration and the app layer, with each item listed as in or out.
How we build
- We deploy Medplum with its PostgreSQL database and Redis cache inside your environment, and document each component's configuration.
- Data model design, Bots and app work are built against the agreed scope and tested in a non-production environment first.
- Testing covers functional behavior and security checks, and results are recorded in the project documentation.
How we hand over
- Handover includes architecture documentation, runbooks, configuration records and the deployment code used to build the environment.
- We document the upgrade path, including the requirement to move through each minor version in sequence before a major upgrade.
- Your team receives a walkthrough of operations, backups and recovery steps before the engagement closes.
How we support
- Ongoing support, upgrades and continuous testing are available as a retainer after handover.
- A retainer can cover applying Medplum's weekly patch releases and sequential minor upgrades in your environment.
- Confirm with us during scoping which response windows, upgrade work and testing activities a retainer includes.
