Medplum security hardening and HIPAA readiness guide

Why Medplum security hardening takes more than a checklist

Medplum security hardening is a set of infrastructure, identity, access and patching decisions that the customer owns once it self-hosts the platform. A team that runs Medplum inside its own AWS account, Kubernetes cluster or data center controls the network path, the database and cache, the identity configuration and the upgrade calendar, and those choices determine whether the deployment can support a HIPAA readiness effort. Medplum's compliance documentation covers HIPAA, SOC 2 Type II and several other frameworks, and it describes compliance as a shared responsibility between Medplum and its customers. The vendor's controls and documentation are one input. The customer must still build its own side of the boundary and collect evidence that it operates that side as designed.

The difficulty is that the obvious boundary is not the real one. The Medplum server is a Node.js and TypeScript application that uses PostgreSQL as its database and Redis as its cache, and both sit behind the FHIR API rather than in front of it. Clients should reach only the API and the web application, so the security review has to confirm that the database and Redis endpoints are unreachable from user networks, that their credentials are scoped and rotated, and that backups and logs holding PHI are protected as well. A firewall rule on the API alone does not show that these stores are isolated. Teams should write down each data store, its network path and its owner before they configure anything, so the auditor's questions have answers that exist on paper.

Patching is the second area where a checklist falls short. Medplum's versioning policy sets targets for security patches: within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). Those are vendor targets for releases, so the customer must also be able to deploy a patch inside its own change process within the time its own policy allows. That requires a tested pipeline, a staging environment that mirrors production, and a named owner who can approve an emergency change. Medplum's upgrading guide adds a constraint: self-hosted servers must move through each minor version in sequence, because skipping versions causes startup failures, and post-deploy data migrations can run for hours or days on large datasets. A security patch that arrives during a long migration window is therefore a scheduling problem, not only a technical one.

Before any hardening work starts, the team should confirm three things in writing: which Medplum edition and version it will run, which parts of the compliance documentation apply to its deployment model, and which controls it expects to inherit from the vendor. It should also decide who holds each responsibility, from network segmentation and identity to access reviews and audit log retention. DeployOpen can plan, implement and document these controls inside the client's environment and prepare the evidence an independent assessor will request. DeployOpen does not issue audit reports, attestations or certifications, so the final HIPAA assessment must come from the assessor the organization engages. Confirm the scope of that assessment with your compliance lead before the hardening plan is fixed.

Which Medplum components widen the attack surface

A self-hosted Medplum deployment is several services with different data and different exposure. Each component below holds or serves something an attacker would want, so hardening effort should follow the data path, not the org chart. Treat each card as a list of decisions to make and verify before go-live.

Medplum Auth and token issuance

Medplum Auth handles OAuth, OpenID Connect and SMART-on-FHIR flows, so it issues the tokens that gate every clinical record. Check which identity providers are trusted, how client credentials are scoped for server-to-server integrations, and whether multi-factor authentication is enforced for human users. Confirm token lifetimes and redirect URI allowlists with your security team, since loose redirect handling is a common path to token theft.

FHIR R4 API and GraphQL endpoints

The FHIR R4 API and its GraphQL support are the main read and write surface for patient data, and GraphQL adds a second query path that must be governed by the same access rules. Review which resource types are reachable by each client, whether search parameters can return data outside a user's compartment, and whether query depth and complexity are limited. Test both interfaces with the same access cases, not only the REST one.

Clinical data repository

The clinical data repository is where patient resources are persisted, and it is the component that most directly establishes what HIPAA treats as protected health information. Map which resource types hold identifiers, free-text notes and attachments, and decide how versioned history and deletion are handled. Confirm with the vendor how audit-relevant changes are recorded so that you can answer who changed what and when.

Bots running server-side logic

Bots execute custom code on the server with access to clinical data, so they behave like privileged internal services. Each Bot should run under its own identity with the narrowest access it needs, and its code, dependencies and outbound network destinations should be reviewed as you would any service that touches PHI. Check who can deploy or modify a Bot, because a changed Bot can read the same data the API does.

HL7 client and server

The HL7 client and server exchange messages with external systems, so they open a network path that is not a web browser session. Decide which peers may connect, how message transport is secured, and where inbound messages are validated before they are persisted. Log message receipt and failures, because interface traffic is often where data leaves the boundary without a user action.

Web app and SDK clients

The web app runs in the user's browser and calls the API with the user's token, so its risks are session handling, content injection and exposure of configuration. Confirm the deployed origins, content security policy, token storage approach and session timeout behavior, and test them against your own identity provider settings. Remember that the SDK and React components ship in client code, so they must not embed secrets.

Node.js and TypeScript server

The Node.js and TypeScript server is the application process that enforces access policies, runs Bots and handles every request. Its security depends on the Node.js runtime, its npm dependency tree and the container or host it runs in, so patching and dependency scanning belong in the operating plan. Ask the vendor how security fixes are delivered and tested, and confirm your own patch window against Medplum's published targets.

PostgreSQL and Redis as separate targets

PostgreSQL stores the persistent clinical record and must be protected as the system of record, with encrypted connections, restricted network reachability, least-privilege roles and encrypted backups. Redis serves as the cache, but cached data can still contain sensitive content and its default configuration does not assume a hostile network, so it needs its own authentication, network isolation and eviction review. Protect each as its own target, because compromising one does not require compromising the other.

How the shared responsibility split maps to HIPAA evidence

Medplum states in its compliance documentation that compliance is a shared responsibility between Medplum and its customers. For a self-hosted instance, the customer's share covers how the deployment is built, who can reach it, what is logged, and how patches are applied. That is the part your environment controls, so it is the part an assessor will ask you to evidence. Start by splitting the control set into two lists: controls Medplum documents as its own, and controls that depend on how you run the platform. Treat the second list as your project scope.

Map the customer side to the families a HIPAA Security Rule assessment usually examines. Access controls cover unique user identification, emergency access and automatic logoff. In Medplum this maps to how you configure Medplum Auth, your external identity provider, multi-factor authentication and client credentials for integrations, plus the access policies that limit what each role can read and write. Audit controls cover recording and examining activity in systems that hold ePHI. Transmission security covers TLS on every hop, including the path from the load balancer to the Medplum server and from the server to PostgreSQL and Redis. Integrity covers protection against improper alteration. Contingency planning covers backup, restore testing and recovery objectives for the database and the file storage you use.

Each of these areas produces evidence only if your environment generates it. Access logs, identity provider sign-in records, load balancer and network flow logs, TLS configuration output, database backup job records and restore test results all come from your cloud account, your data center or your ticketing system. DeployOpen can plan, configure and document these controls and prepare the evidence set, but it does not issue audit reports, attestations or certifications. Independent auditors and certification bodies judge whether the controls operate as described. Agree with your assessor early which artifacts they expect and in what format, so the evidence is collected as the system runs rather than reconstructed later.

Before you finalize the split, confirm with Medplum exactly which controls its own compliance materials cover, which are inherited by the hosted service, and which remain with the customer when you self-host. Ask for the scope statement and the customer responsibility matrix that goes with it, and check whether the matrix refers to the version you plan to run. Also confirm how Medplum's security patch targets apply to your self-hosted version, since those obligations sit on your side of the line. Record each confirmed answer in your control register with an owner and a review date.

Finally, decide who owns each customer-side control before build starts. Assign named owners for identity configuration, network exposure, database protection, logging and patching, and agree how their evidence will be stored. Gaps usually appear at the boundaries, such as a log that the platform team assumes the security team collects. Walking the control register with each owner once, before go-live, shows which evidence is missing while there is still time to add the logging or change the configuration.

Which hosting and identity decisions shape the hardening scope

This table compares the main hosting and identity choices for Medplum and what each one moves into or out of your hardening scope. Read each row against your own shared-responsibility split: the more infrastructure and identity your team operates, the more controls you must build, configure and evidence yourselves.

Decision	When it fits	What it costs you operationally
Self-hosting on AWS with CDK and CloudFormation	Your team runs AWS and wants the path Medplum documents as recommended for self-hosting	You own network design, PostgreSQL and Redis configuration, backups, patching and all AWS account controls
Self-hosting on Kubernetes or Docker	You already operate a container platform and need portability across environments	You own cluster hardening, image provenance, secrets handling and the database and cache services you run beside Medplum
Ubuntu via APT repository	You prefer a traditional server build managed by configuration management	You own host hardening, OS patch cadence, service isolation and every upgrade step between minor versions
Terraform-based GCP or Azure (Beta)	Your standard cloud is GCP or Azure and you accept Beta maturity for this path	You must validate Beta modules against your controls and confirm their current status with Medplum before committing
Medplum as the identity provider	You want one identity store for clinicians, staff and client applications with fewer moving parts	You own password policy, MFA enrollment, account lifecycle and access reviews inside Medplum
External provider such as Google, Auth0 or AWS Cognito	You need a managed identity service for users while keeping Medplum as the FHIR authorization layer	You own the integration, token and claim mapping, and confirm the provider's own HIPAA terms and logging
Domain-level corporate identity provider	Your workforce already signs in through corporate SSO and you want central deprovisioning	Multiple external identity providers for SSO are an enterprise feature, so confirm entitlement before scoping
Hosted Medplum cloud with standard BAA	You want Medplum to operate infrastructure and sign a business associate agreement for hosted paid plans	You rely on Medplum for infrastructure controls and must still document the shared responsibilities in your risk assessment
Self-hosting under Community or Enterprise Self-Hosted	You need data to stay in your own infrastructure or your environment cannot use the hosted service	You carry the full hardening, patching and evidence workload; confirm which support and security commitments your edition includes

How to harden the network, database and cache layers in sequence

This sequence hardens the network, database and cache layers of a self-hosted Medplum deployment, starting with the boundary that faces users. Each step closes with a check the team can run and record as evidence for HIPAA readiness work, and each step builds on the one before it.

Place the API and web app behind controlled ingress
The platform team places the Medplum API and web app behind a single controlled entry point, such as a load balancer or ingress controller, and terminates TLS there with a certificate the organization manages. Application hosts receive traffic only from that entry point, and the team confirms the exact routing and certificate settings in the Medplum self-hosting documentation before configuring them. Done means a request to the application's address on any other path fails, and a TLS scan of the public hostname returns a valid, unexpired certificate chain.
Restrict PostgreSQL and Redis to the private network
Network engineers place the PostgreSQL database and the Redis cache on private subnets with no public IP addresses and no internet route. Security groups or firewall rules allow connections only from the Medplum server hosts, and the team confirms the required connection settings in the Medplum docs. Done means an external port scan of the data subnet shows no open database or cache ports, and a connection attempt from an unauthorized host inside the same network is refused.
Require authenticated, encrypted data store connections
The team enables TLS for connections to PostgreSQL and Redis where the chosen deployment method supports it, and requires a password or equivalent credential for every client. Credentials are stored in the organization's secrets manager and rotated under a documented procedure, not embedded in images or configuration files. Done means a connection without credentials is rejected, a connection without TLS is rejected where TLS is enforced, and a successful test connection is recorded in the change log.
Separate production from non-production environments
Development, test and production run in separate accounts, networks and databases, each with its own credentials, certificates and identity provider configuration. Engineers receive production access only through the approved access path, and test data never copies production records without a documented de-identification step. Done means a credential issued for a non-production environment fails authentication against production endpoints, and the team can show the environment boundary in an architecture diagram that matches the deployed network.
Configure identity providers and MFA before provisioning users
Before any clinical or administrative user account exists, the team connects Medplum to the identity provider the organization uses, whether Medplum Auth, an external provider, or a domain-level corporate provider, and enables multi-factor authentication. Client credentials for server-to-server integrations are issued separately and scoped to named integrations. Done means a sign-in with a valid password but no second factor fails, and a test user who completes MFA reaches the expected screen and no others.
Confirm the instance serves only expected paths
The team runs an external scan against the public hostname and reviews the routes the application exposes, then compares them with the list of paths the deployment is meant to serve. Administrative, health and debugging endpoints should be reachable only from internal addresses, and the team confirms which endpoints the Medplum documentation expects to be public. Done means the scan results match the approved route inventory, and any difference is either fixed or documented as an accepted exception with an owner.

Which controls protect PostgreSQL, Redis, secrets and audit logs

Medplum keeps clinical data in PostgreSQL, caches through Redis, and relies on credentials and logs that all need protection. The controls below cover the data stores, the secrets that unlock them, and the records that show who did what. Each one needs an owner, a configuration check, and evidence that it works in your own environment.

Database access limited by role

Medplum's server connects to PostgreSQL with its own database role, and that role should hold only the privileges the server needs. Administrative access should go through separate named accounts with logging, not the application credential. Check who can connect to the database from outside the server subnet, and confirm which schema changes the application role can make during upgrades.

Encryption at rest and in transit

Encryption depends on what your chosen cloud or data center offers for disk volumes, managed database storage, and TLS between the Medplum server, PostgreSQL, and Redis. Confirm which options are enabled by default in your deployment template, who holds the encryption keys, and whether connections to the database require TLS. Record the settings as evidence for your HIPAA risk analysis.

Backup protection and restore testing

Backups hold the same clinical records as the live database, so they need the same access control and encryption as production. Confirm where snapshots are stored, who can restore them, and whether backup copies are kept in a separate account or region. A restore test into an isolated environment is the only proof that the backup works, so schedule one and keep the result.

Redis access restriction and authentication

Redis is used as Medplum's cache, so it should never be reachable from public networks or from workloads that do not need it. Require authentication on the Redis endpoint, keep it on a private subnet, and restrict security groups to the Medplum server. Confirm that the connection settings in your deployment use the credentials you intend, and that Redis cannot be reached by a debugging tool left running in the same network.

Secrets stored outside source control

Database passwords, Redis credentials, and client secrets should live in a managed secret store, not in configuration files or repositories. Use the secret manager that your cloud provides, grant read access per service, and rotate values on a schedule you document. Scan repositories and build logs for leaked credentials, and confirm that your infrastructure code references secrets by name rather than by value.

Client credentials scoped per integration

Medplum supports client credentials for server-to-server access, and each integration should have its own client with the narrowest access policy that works. Avoid sharing one client across an HL7 feed, a Bot, and an analytics job. Review which clients exist, which projects and resource types each can reach, and retire clients that no integration still uses.

Audit logging of access and changes

Audit records should cover authentication events, reads and writes to clinical resources, and administrative changes such as policy edits or client creation. Confirm which audit events Medplum emits by default, how they are exposed, and how to forward them to your central log store. Ask your compliance lead to set the retention period, since the value should come from your own HIPAA and organizational policy.

How AWS, Kubernetes and Docker deployments change the hardening work

The self-hosting docs present AWS deployment with CDK and CloudFormation as the recommended option, so most regulated teams will start here. The template provisions the infrastructure, so your first task is to read what it creates, record which settings it fixes, and compare those settings with your own security baseline. Confirm the following in the current docs:

Whether the load balancer terminates TLS with a certificate you control, and which listener policy applies.
Encryption settings for the PostgreSQL and Redis resources, including key ownership and backup retention.
Where the server's secrets, such as database credentials and signing keys, are stored and how they rotate.
Network placement of the database and cache, and which security groups allow inbound traffic.
Which logs the load balancer, containers and database emit, and where they are sent.

Your team typically adds what the template leaves open: IAM roles scoped to the minimum each service needs, a review of the managed database parameter group, and alerts on configuration drift. The GCP and Azure Terraform deployments are marked Beta in the same docs, so confirm their readiness for regulated workloads before choosing either. Verify every control above against the template version you deploy, because defaults can change between releases.

How to test that Medplum hardening holds and fails safely

The hardening decisions for a self-hosted Medplum deployment are only useful if you can show they still hold after the next change, and that they fail closed when something breaks. Verification should start from the outside in. Begin with an external exposure review of everything reachable from the internet or from networks outside your private segment: the API endpoint, the web app, the Auth endpoints, and any load balancer or ingress you placed in front of them. Compare what you find against the intended design. Anything that answers that should only be reachable from inside the VPC, cluster or data center is a finding, regardless of whether authentication would reject the request.

Next, test reachability of the data stores directly. PostgreSQL and Redis should not accept connections from outside the private network, from the public subnet, or from a developer workstation over a bastion you did not intend to expose. Run the test from a network position that mirrors an attacker's, not from inside the application subnet, and record the result for each port and each security group or firewall rule. Confirm that Redis requires authentication and that the database account used by the application cannot connect with a superuser role. Ask your platform team to show the rule set, then prove it with a connection attempt rather than accepting the diagram.

Authentication tests should cover the cases that tend to fail quietly. Confirm that MFA is enforced for every human login path you configured, including any external identity provider you connected, and that a user who has not enrolled cannot reach protected resources. For client credentials used by integrations, test that an expired secret is refused, that a revoked client is refused on its next token request, and that a token issued before revocation stops working within the lifetime you agreed. Then test access policy boundaries: a user in one project or role should receive denial, not an empty result set that looks like success, when they request records outside their scope. Also check that error responses for malformed requests, failed logins and server faults do not include stack traces, internal hostnames, database messages or secrets. Treat any of these leaks as a defect to fix before go-live.

A failure drill tests the behavior that the controls depend on. Choose one scenario per drill and run it in a non-production environment that matches production configuration: stop the identity provider the platform relies on, rotate a client credential while an integration is active, or fail over the PostgreSQL primary to a standby. For each, confirm three things. Requests that depend on the failed component should be refused rather than served from a cached or default identity. Errors should be visible to operators rather than silently retried into an open state. Events, including failed logins, credential changes, and access denials, should appear in your log pipeline with timestamps and identifiers, and someone should be able to trace them. Record the time each step took and what your runbook told the on-call engineer to do.

Independent testing should be a separate engagement from the build. The team that configured the deployment should not be the only team that judges it. DeployOpen runs security testing of applications, APIs and infrastructure, which can cover the exposure review and authentication tests above, and can be scoped in writing before work starts. Ask any tester to state which Medplum version and configuration they tested, and to report findings against that baseline. Compliance opinions are a different matter. DeployOpen prepares systems, controls and evidence, but independent assessors issue any HIPAA-related attestation or certification. Confirm with your assessor, before testing begins, which evidence they will need and in what form.

What drives the effort of a HIPAA-ready Medplum hardening project

This table lists the factors that change how much work a Medplum hardening and HIPAA readiness project involves, why each one matters, and how to keep it contained. Use it to see which factors your own environment raises before asking for a written, fixed-scope proposal, because the agreed scope depends on these drivers.

Driver	Why it changes the work	How to keep it down
Deployment model and number of environments	Each environment (development, staging, production, disaster recovery) needs its own network controls, secrets, backups and evidence. Separate clusters or stacks multiply the configuration to review and test.	Limit production to one hardened baseline, build other environments from the same infrastructure code, and agree in writing which environments are in scope.
Number and type of identity providers	Medplum supports its own auth, external providers such as Google, Auth0 or AWS Cognito, and domain-level corporate providers. Each provider adds login flows, MFA settings, claim mapping and access policy checks to test.	Confirm the provider list early, standardize on one primary corporate provider where possible, and document which accounts may use local Medplum login.
Number of integrations using client credentials	Client credentials give server-to-server access with long-lived secrets. Every integration needs its own client, scope, rotation process and access policy, and each one is a credential an assessor will ask about.	Inventory all clients before work starts, grant the narrowest scope, retire unused clients, and move secrets into a managed vault with a rotation schedule.
Custom Bots and HL7 interfaces	Bots run server-side logic and the HL7 client and server accept inbound clinical messages. Custom code and open listening ports widen the attack surface and need input validation, logging and review.	Keep the Bot count small, review each Bot's permissions, restrict HL7 endpoints to known sending systems, and treat interface changes as controlled releases.
Existing logging and SIEM maturity	Medplum audit events, load balancer logs, database logs and cloud trail records must reach a central store with retention, alerting and access control. A team with no SIEM must build this, while a mature team maps the existing pipeline.	Confirm which log sources your SIEM already ingests, reuse existing alert rules and retention policies, and define the log fields Medplum must emit before implementation.
Volume of evidence the assessor requests	HIPAA readiness depends on showing that safeguards operate, not only that they exist. The more samples, time periods and screenshots requested, the more collection and tracing work the team carries.	Ask the assessor for a written evidence list early, map each item to an owner and a system source, and automate exports such as access reviews and configuration snapshots.
Ownership of cloud and database administration	If your team already runs the cloud accounts, PostgreSQL and Redis, the work shifts to configuration and evidence. If not, the project must also define administrator roles, backups, patch windows and monitoring for those layers.	Document who holds each administrative role today, decide which duties a partner covers under a written scope, and name a single internal owner for each control.

How patching under Medplum's security targets works in practice

Medplum's policy sets the clock: security patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). Patch versions are released weekly. On a self-hosted deployment, though, those windows belong to your change process, not to Medplum. Before go-live, name the person who watches Medplum's release feed, the person who assesses whether a given CVE affects your deployment, and the approver who can schedule the change. Ask Medplum how advisories are published and confirm which channel your on-call team monitors, so the 7 and 14 day clocks start from a known date.

A target only helps if you can apply the patch, which means a staging environment that matches production in the parts that matter: the same Medplum version, the same PostgreSQL and Redis versions, the same identity provider configuration and a dataset large enough to exercise real query paths. Use staging to run a short smoke test after every patch: a SMART-on-FHIR app launch, a Bot execution, a client credentials token request and a check that audit records are still being written. If the weekly patch cadence consumes your first-time setup work, the pipeline is not ready. The routine should be boring enough to run on short notice.

Medplum requires self-hosted installations to move through each minor version in sequence. Skipping steps causes startup failures, and the documented example is a jump from v3.1.2 straight to v4.3.4. Treat the upgrade path as a written list: identify your current minor version, list every minor version up to your target, and rehearse each step in staging, recording the outcome and any configuration changes. Use Medplum's upgrading guide as the reference for each step. If you are several minors behind, ask Medplum in writing whether a critical fix will be delivered on your current line or only on a newer one, because that answer determines whether you can meet the 7 day target at all.

Some upgrades run post-deploy data migrations after the new version starts, and on large datasets these can run for hours or days. Measure migration time in staging against a copy of production-sized data, then schedule the window with that number, not with an assumption. Take and verify a backup before each step, define a rollback point, and decide in advance whether clinical writes are paused during the migration. Medplum's support lifecycle sets the outer limits: each major version receives 1 year of Active support and 1 year of Maintenance, and the Enterprise extension adds 12 more months of security patches for 36 months in total. Put the end of security patching on your calendar and confirm the extension terms in writing if your plan depends on them.

What buyers ask before hardening a self-hosted Medplum deployment

How much does hardening a self-hosted Medplum deployment cost?

Cost comes from four places: the cloud or data center infrastructure you run, staff time to configure and verify controls, any implementation partner fees under a written scope, and ongoing patching and monitoring. Medplum is released under the Apache 2.0 license, so the Community self-hosting option carries no software license fee, while Enterprise Self-Hosted is custom-priced. For comparison, Medplum's pricing page lists the hosted Production plan at $2,000 per month and Premium at $6,000 per month, which moves infrastructure work to the vendor. DeployOpen does not publish prices. Ask for a quote built from a written scope that lists environments, identity provider integrations, logging destinations and the evidence set, and separate one-time hardening work from recurring patch and support costs. The effort-driver table on this page shows which inputs move the total most.

How long does it take to harden a self-hosted Medplum deployment?

The timeline is set by scope, and no single duration fits every deployment. The biggest drivers are the number of environments (development, staging and production each need the same controls), the hosting path, the identity provider integration, and the size of the existing dataset. Medplum's recommended self-hosting path is AWS with CDK and CloudFormation, while Kubernetes, Docker, DigitalOcean and Ubuntu options each need their own network and secrets work, and the Terraform-based GCP and Azure options are marked Beta in the docs. If the installation is behind the current release, sequential minor upgrades usually come first, and they can add post-deploy migrations that run for hours or days on large datasets. Change windows and customer review cycles also affect the schedule. Confirm the milestones, dependencies and review points in the written plan before work starts.

What does our team need to provide for a Medplum hardening project?

Your team needs named owners for each control area, not only general access. That means a cloud account administrator with rights to change network, IAM and secrets settings, a network and security contact for exposure decisions, and an owner for PostgreSQL and Redis who can approve configuration changes. You also need an identity administrator for the chosen provider, whether Medplum Auth, Google, Auth0, AWS Cognito, Okta or Azure, and a clinical or compliance owner who approves access policies and audit log scope. Someone must own patch intake, because Medplum's versioning policy targets security patches within 7 days for critical vulnerabilities (CVSS 9.0 or higher) and within 14 days for high ones (CVSS 7.0 to 8.9). Finally, provide staging access, a change process and a retention decision for audit logs.

Can our internal platform team harden Medplum without an outside partner?

Yes, a capable internal team can do it if it already has skills in the areas the work touches. Those include cloud network segmentation, PostgreSQL and Redis hardening, operating Node.js and TypeScript services, designing FHIR access policies, configuring OAuth, OpenID Connect and SMART-on-FHIR flows, and mapping controls to HIPAA safeguards. The usual gap is not the first configuration but the repeatable part: consistent configuration records, change history, and verification after each upgrade or weekly patch. An internal team keeps the knowledge in-house but absorbs the schedule risk and the ongoing patch clock. A fixed-scope partner engagement puts deliverables and timelines in writing before work starts. To decide, check your team against the skill list above and confirm who will own the patch targets when a critical advisory lands.

Does a Medplum BAA mean our self-hosted deployment is HIPAA ready?

No. A business associate agreement is a contract term with the vendor, and it does not configure your deployment. Medplum's paid cloud plans include standard BAA and MSA agreements, which covers the hosted service it operates. Medplum's compliance documentation states that compliance is a shared responsibility between Medplum and its customers. In a self-hosted deployment, your team still owns network exposure, PostgreSQL and Redis protection, access policies, audit logging and patch timing inside your own infrastructure. Ask Medplum whether a BAA applies to the self-hosted edition you plan to buy, what it covers, and which responsibilities stay with you. Then map each safeguard to a named owner and a piece of evidence.

Does DeployOpen issue HIPAA certification for our Medplum deployment?

No. DeployOpen does not issue HIPAA certifications, attestations or audit reports. DeployOpen prepares systems, controls and evidence so your organization can go into a compliance assessment with a documented configuration. Independent auditors and certification bodies perform the assessment and issue any report or certification. Before work starts, ask your assessor which evidence they expect for network controls, database and cache protection, access policies, audit logs and patch records, and confirm that the scope agreed in writing matches that list. Medplum's compliance documentation covers several frameworks, but the deployment you run is your responsibility to document and defend.

What should we confirm with Medplum before signing a contract?

Confirm several points in writing before you sign. First, check which release line your version falls into, since each major version gets 1 year of Active support and 1 year of Maintenance, with an Enterprise extension of 12 more months of security patches for 36 months in total. Second, confirm the security patch targets in the contract, which are currently 7 days for critical and 14 days for high vulnerabilities under the versioning policy. Third, confirm whether the BAA covers the exact edition and deployment model you are buying. Fourth, request the shared responsibility breakdown for your deployment, along with access to the SOC 2 Type II report under the appropriate confidentiality terms. Fifth, confirm upgrade and migration support, including what happens if a sequential minor upgrade is missed.

How do Medplum upgrades affect hardening work over time?

Each upgrade can change the controls you tested, so hardening is not a one-time task. Self-hosted Medplum must move through each minor version in sequence. Skipping versions causes startup failures, as Medplum's upgrading guide describes for a jump from v3.1.2 straight to v4.3.4. Post-deploy data migrations can also run for hours or days on large datasets, which affects your change window. After each upgrade, re-test the network rules, Redis authentication, PostgreSQL roles, access policies and audit log output. Medplum publishes patch releases weekly, so plan a recurring patch cycle that fits the 7-day and 14-day targets. Record each test result as evidence, because an assessor will ask how the controls were verified after a change.

How DeployOpen scopes, hardens and hands over Medplum security work

DeployOpen plans, implements, hardens, documents and supports self-hosted open-source platforms inside the client's own infrastructure, including Medplum. For Medplum security hardening and HIPAA readiness, we start from a written scope, harden the deployment in your cloud account or data center, and hand over controls and evidence that your team and independent auditors can review.

How we scope

Engagements are fixed-scope, with the scope, deliverables and timelines agreed in writing before work starts.
The written scope lists which Medplum components, network paths, databases and identity flows are in and out of the hardening work.
Scoping confirms which HIPAA safeguards your organization expects DeployOpen to prepare evidence for, and which remain with your team.
Scoping confirms whether Medplum is deployed on AWS, Kubernetes, Docker or another target, since that changes the hardening steps.

How we build

We review network exposure of the Medplum API, web app and Auth endpoints and restrict access paths to what your users and integrations need.
We configure PostgreSQL and Redis access, encryption and authentication settings, and confirm they are not reachable beyond the intended services.
We set up access policies, identity provider settings and multi-factor authentication aligned with the roles your organization defines.
We enable audit logging and test that the logs capture the access and change events your evidence plan requires.

How we hand over

You receive a written record of the configuration changes made, with the reasons for each control and the systems it covers.
We map implemented controls to HIPAA Security Rule safeguards and identify gaps that remain open, so your compliance lead can act on them.
We document the patching process, including how your team will track Medplum security releases and apply them within the vendor's stated windows.
Runbooks cover routine checks, log review, access reviews and the steps to take if a control stops working after an upgrade.

How we support

Ongoing support, upgrades and continuous testing are available as retainers, separate from the initial fixed-scope work.
A support retainer can cover applying Medplum patch and minor releases in the required sequence, with your change approval process.
Periodic security testing of the hardened deployment can be added to a retainer if your organization requires it.
Before any retainer starts, confirm in writing what it covers, who responds to incidents and how evidence is delivered to your auditors.

Medplum security hardening and HIPAA readiness