HAPI FHIR vs Medplum

In a HAPI FHIR build, your team owns the application shell that wraps the server, and the security composition is yours to design. HAPI provides building blocks rather than a finished layer: authentication interceptors to validate who is calling, the AuthorizationInterceptor to decide what each caller may read or write, consent and search narrowing interceptors to limit results, CORS support for browser clients, and BALP audit logging. Partitioning, documented in HAPI's partitioning guide, lets you place each resource in a partition for multitenancy, separate data sources, or keep regional data apart, but the partition rules and the mapping from identity to partition are also yours to write and test. HAPI explicitly does not provide a single one-size-fits-all security layer, so treat the composition as a deliverable with its own design review and negative tests, not a default you inherit.

In a Medplum deployment, several of these pieces arrive as part of the platform. Medplum Auth covers OAuth, OpenID Connect and SMART-on-FHIR, and its identity options include Medplum as the identity provider, external providers, domain-level corporate identity providers, client credentials for server-to-server access and multi-factor authentication. Bots run server-side logic inside the platform, and the web app and React components sit on the same access model. Your team still owns the access policies that define which projects, roles and clients can do what, the handling of bot credentials, and the network and hosting controls around a self-hosted install. Confirm with Medplum exactly which access controls, audit outputs and consent handling your edition provides, since the shared responsibility model in its compliance documentation assigns part of that work to you.

Use this split to size the work before comparing prices. Ask each vendor, or your implementation partner, to map every row of your access and audit requirements to a named component: an interceptor or custom code in HAPI, or a built-in Medplum feature or configuration you verify. Where the answer is custom code, that code needs owners, tests and an upgrade plan, because it will be carried across every HAPI version bump. A short test plan that tries cross-tenant reads, consent bypass through search parameters and browser requests from unexpected origins will show quickly which model your team can actually operate.

On a HAPI FHIR project, the authorization and consent design is usually the longest item, because HAPI does not ship a single security layer. It gives you building blocks: authentication interceptors, the AuthorizationInterceptor, consent and search narrowing interceptors, CORS support and BALP audit logging. Someone must decide which rules apply to which resource types, how patient context is enforced in searches, and how the pieces compose so that a request cannot bypass a check. Partitioning is the other common delay. JPA partitioning assigns each resource to a partition, which can serve multitenancy, separate data sources or group data by region, and changing that model after data is loaded is costly. Database tuning on PostgreSQL or Microsoft SQL Server and test coverage of the security composition should be scoped explicitly, not left as a final phase.

On a Medplum project, the slow points sit mostly around the platform's surroundings. Self-hosting infrastructure is the first decision: the recommended path is AWS with CDK and CloudFormation, while Terraform-based GCP and Azure deployments are marked Beta, so confirm which option your cloud team can own. Identity provider integration comes next. Medplum supports its own identity provider, external providers, domain-level corporate identity providers, client credentials and multi-factor authentication, and the mapping of your workforce and application identities to those options needs agreement early. Upgrade sequencing also takes planning, because self-hosted Medplum must move through each minor version in order, and post-deploy data migrations can run for hours or days on large datasets. Finally, Medplum's compliance documentation states that compliance is a shared responsibility, so each control on its published list needs an owner on your side.

DeployOpen scopes these areas as separate, fixed items in the written statement of work: the authorization and consent design, the partitioning model, database configuration and test coverage for HAPI, and the infrastructure target, identity integration, upgrade runbook and responsibility matrix for Medplum. Each deliverable is named with its owner, acceptance criteria and dependencies before work starts, and the timeline follows from that scope rather than from an estimate. Ask any implementation partner, including DeployOpen, to show which of these items sit in the scope and which remain with your team, and to confirm how upgrades and post-go-live support are handled under a retainer. Your own environment, cloud policies and data classification will decide much of the real effort, so confirm them before comparing quotes.

DeployOpen can help you choose between HAPI FHIR and Medplum, then build the platform you pick inside your own infrastructure. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your cloud accounts, data centers or air-gapped networks. For this decision, that means the work can cover either a Java HAPI FHIR server with its chosen database, interceptors and deployment target, or a self-hosted Medplum stack with its Node.js server, PostgreSQL, Redis and identity configuration. DeployOpen also runs security testing of the resulting applications and APIs, and prepares systems, controls and evidence for compliance assessments. It does not issue audit reports, attestations or certifications. Independent auditors and certification bodies do that work, and your compliance requirements should be confirmed with them early.

The engagement starts with a written scope. Most DeployOpen engagements are fixed-scope, so the scope, deliverables and timelines are agreed in writing before work begins. Ask for the scope to name the decisions it covers: FHIR versions, the database, the authorization model, how SMART-on-FHIR or OpenID Connect sign-in is wired, how audit logging is produced, and who operates upgrades after go-live. Medplum's self-hosted upgrade path requires stepping through each minor version in sequence, so an upgrade plan belongs in the scope rather than being left to a later retainer. Ongoing support, upgrades and continuous testing are available as retainers, and those recurring costs should be quoted separately from the one-time build. DeployOpen does not publish a price list, so the quote follows from the written scope.

DeployOpen is not an official partner, reseller or certified provider of HAPI FHIR, Medplum or any standards body. That matters for this comparison: the recommendation should follow your requirements, including your FHIR version targets, data residency, the skills your team already has, and whether you want a hosted option at all. A useful first step is to write down those requirements, then ask DeployOpen to test both options against them in a short scoping discussion. If the answer is HAPI FHIR, the team will need to commit to JDK 17 or later and to building the surrounding platform. If the answer is Medplum, the team will need to confirm which self-hosting path and identity provider match its environment. Either way, the decision should be recorded in the written scope before any build begins.