OpenEMR vs Medplum

HIPAA duties attach to covered entities and their business associates for the electronic protected health information they handle, so the first decision is whether your organization is a covered entity, a business associate, or both once a platform vendor touches patient data. Under 45 CFR 164.314, a business associate contract must require the business associate to comply with the Security Rule, flow the same terms down to subcontractors that handle ePHI, and report security incidents, including breaches of unsecured PHI. Ask any vendor or host for that contract language in writing before pilot data moves. Also note that there is no HIPAA certification. HHS states that no Security Rule standard requires certification, so a vendor claim of being "HIPAA certified" should be treated as a question to answer, not as evidence.

With Medplum, the hosted service and the company's compliance documentation describe compliance as a shared responsibility between Medplum and its customers. Confirm in writing which controls Medplum operates (infrastructure, encryption, logging, backup, incident response) and which ones your team configures, such as user provisioning, MFA enforcement, client application scopes and the clinical apps you build on the FHIR API. Self-hosted Medplum moves more of that line onto your side. With self-hosted OpenEMR, the organization owns the hosting controls: the server, database, TLS termination, backups, access to the sites/ directory and the administrative scripts, and the patient portal exposure. The OpenEMR security guidance on allowing only HTTPS and removing setup scripts after installation is a checklist your own team must run and evidence. If you choose a cloud host for either path, get that host's BAA as well, and map every system that stores or transmits ePHI, including backups, logs and third-party SDKs.

Before signing, request four things in writing from every vendor and hosting provider: the BAA text, a responsibility matrix that assigns each Security Rule safeguard to a named party, the exact hosting boundary (regions, subprocessors, and where backups and logs live), and the incident notification timeline and contact. Compare the answers across the two paths. A hosted Medplum plan and a self-hosted OpenEMR deployment on a cloud account may both require a BAA with the cloud provider, but only one of them may hold the operational controls you are being asked to evidence. Independent auditors, not the vendor and not DeployOpen, issue any attestation you might later need, so ask which assessments the vendor holds and their scope before relying on them.

Neither platform charges a license fee at its open-source tier, so the cost of OpenEMR and Medplum lies in the people, infrastructure and evidence around them. For OpenEMR, the one-time costs are configuration, interface work, data migration and the decision about who hosts it. The recurring costs are hosting, database and backup operations, patching and the staff who apply OpenEMR upgrades. For Medplum, the one-time costs include designing the application on the FHIR API, building SMART-on-FHIR apps and Bots, and setting up identity through Medplum Auth or an external provider. The recurring costs are the cloud footprint for the PostgreSQL and Redis services, engineering time to keep the application current, and any hosted or enterprise subscription you choose. Medplum's hosted tiers are priced on its pricing page, and you should compare those figures against your own infrastructure quote rather than assume either option is cheaper.

The largest variable on the Medplum side is upgrade effort. Its upgrading guide says self-hosted deployments must move through each minor version in sequence, that skipping versions causes startup failures, and that post-deploy data migrations can run for hours or days on large datasets. Plan a staging environment with a copy of production data, a maintenance window and a rollback path, and ask your team or DeployOpen to estimate the migration window against your data volume before you commit. OpenEMR upgrades carry their own cost, since the project's security fixes and its requirement to move to version 8 to keep certification active mean you should budget for regular upgrade testing. Security testing applies to both paths. Ask for the testing scope in writing, including the custom application and its FHIR and SMART endpoints, and confirm whether the quote includes retesting after each upgrade.

Compliance evidence is often the cost that surprises teams. Medplum's compliance documentation says compliance is a shared responsibility, so the policies, access reviews, risk analysis and vendor agreements that cover your application fall to your organization. OpenEMR's certification is a product-level attestation that does not transfer to your local configuration, so you still prepare evidence for your own deployment. Ask any quote to separate the one-time evidence build (policies, data flow diagrams, control mapping and a first risk assessment) from the recurring work of collecting evidence each year. Also ask who signs business associate agreements for hosting and subcontractors, because those contracts add legal and procurement effort that appears in neither product's license. Optional paid support from the vendor or an implementation partner should be quoted as a separate line with stated response expectations.

On the OpenEMR path, the schedule usually slips in configuration and integration rather than in installation. Standing up the application is the short part. The longer work is mapping clinical workflows to templates, forms, scheduling rules and billing setup, then deciding which external systems (labs, imaging, payers, a patient portal) must talk to OpenEMR through its FHIR API. Hosting hardening adds its own queue: the Securing OpenEMR guide asks you to allow only HTTPS, consider opening only port 443, remove setup.php and other admin scripts after installation, and block direct web access to sites/*/documents. Confirm who owns each of those steps, and whether your web server and firewall team can make those changes within your change-control process. Identity is the other common delay. OpenEMR's LDAP and Active Directory login validates passwords against the directory but still requires the user to exist in OpenEMR, so account provisioning and deprovisioning must be designed, not assumed. Google Sign-In, added in version 6.1.0, needs its own review of which accounts are allowed.

On the Medplum path, the schedule usually slips earlier, in application architecture and FHIR data modeling. Your team must decide which resources hold clinical data, how custom extensions and profiles represent local concepts, and where business logic lives: in the React front end, in Bots for server-side logic, or in both. Each of those choices affects validation and testing later. Identity provider configuration is the next risk. Medplum supports its own identity provider, external providers such as Google, Auth0 or AWS Cognito, domain-level corporate identity providers, client credentials and multi-factor authentication, and the combination you choose needs explicit testing for both clinician and patient flows. Self-hosting adds upgrade sequencing: Medplum's upgrading guide says each minor version must be applied in order, skipping versions causes startup failures, and post-deploy data migrations can run for hours or days on large datasets. Plan a staging rehearsal with a production-sized copy of the data before you commit to a date.

Validation of the clinical application itself is the step most often underestimated on either path. A certified EHR arrives with its certification scope already defined, but a custom application built on Medplum does not inherit any certification, and Medplum's compliance documentation states that compliance is a shared responsibility between Medplum and its customers. Confirm early which clinical workflows, safety checks, audit logging and access rules your organization must test and document, and who signs off on them. Ask your implementation partner to show how test evidence, change records and access reviews will be produced during the build, not after it. The schedule risk is usually the gap between a working prototype and an application your quality, security and compliance owners will accept. Agree on that acceptance standard in writing before fixing the scope.