OpenEMR security hardening and HIPAA guide

Why OpenEMR security hardening is more than a checklist

If a clinic or health system is running OpenEMR and must show HIPAA safeguards for patient data, hardening is the set of server and application measures that reduce exposure of that data, plus the evidence that those measures are in place and kept in place. The Securing OpenEMR guide is the project's starting point. It lists concrete steps: allow only HTTPS and consider opening only port 443, remove setup.php and other admin scripts after installation, block direct web access to sites/*/documents, enforce multi-factor authentication, set strong password policies, use the upload file white list, and optionally encrypt items stored on drive. It also points to a security assessment page for HIPAA and Meaningful Use requirements, which is where the mapping from settings to obligations begins.

The guide is a checklist, but the platform does not stay still. OpenEMR's FHIR API, patient portal, billing, fax and SMS module and fee sheet have all had security fixes in recent releases. The 8.3.0 and 8.4.0 releases fixed vulnerabilities in several of these areas, and 8.4.1 followed. That means a configuration that was sound at go-live can drift out of step once a security release lands. Hardening therefore needs an owner, a patch intake process and a test environment where each release is checked before production. Ask your team who will read release notes, how quickly security releases are applied, and where the change record for each upgrade is kept.

Several hardening decisions depend on how your environment is built, and these are the ones to settle early. Decide whether the FHIR API and patient portal are exposed to the internet or restricted to specific networks, because that choice changes which controls matter most. Decide which roles can export data, including FHIR Bulk Data exports at system, patient and group level, and who approves them. Confirm your password hashing and expiration settings in the Administration Globals, and whether LDAP or Active Directory will enforce identity so that OpenEMR does not hold a separate password policy. Confirm whether drive encryption is required by your own policy and whether your hosting provider already encrypts storage. Each answer produces a documented control and an item of evidence.

DeployOpen prepares the controls, configuration records, test results and evidence that a HIPAA assessment will ask for, mapped to your environment. DeployOpen does not issue HIPAA attestations, audit reports or certifications. Those come from your own compliance function and, where applicable, independent assessors. The ONC certification status of the OpenEMR version you run is a separate question. Confirm it directly with the project and your vendor, and do not treat hardening work as proof of certification. Plan for the assessor to test the configuration you can demonstrate, so keep the evidence current after each change.

Which OpenEMR components carry the hardening work

Hardening an OpenEMR server centers on a small set of locations that control who can reach the application, which files are exposed, and how logins and data are protected. The six components below are the ones the project's securing guide points to, and each one relates to HIPAA expectations for access control, transmission security and integrity. Check each one in your own environment after installation and after every upgrade.

Web server and port 443

Controls which network paths reach OpenEMR. The securing guide says to allow only HTTPS and to consider opening only port 443, so plain HTTP and other listening ports should be closed or redirected at the edge. For patient data in transit, confirm the certificate chain, the TLS configuration and that no login page or API endpoint answers over HTTP. Test these from outside the clinic network, because internal checks can miss exposed ports.

Web root and setup scripts

Controls which PHP scripts an outside user can run. The securing guide says to remove setup.php and other admin scripts after installation, since a leftover installer or admin tool gives an attacker a route to reconfigure or reset the system. Check the deployed web root after every upgrade or redeploy, because container images and file copies can bring these scripts back. Keep the removal result as evidence for your access control review.

Documents directory and upload controls

Controls how scanned and uploaded patient files are stored and served. The sites/*/documents directory holds patient documents, so direct web access to it should be blocked and files should be served only through application logic that checks the user's rights. Pair this with the upload file white list, which limits accepted file types, and the option to encrypt items stored on drive. Confirm each setting in the admin globals and test a direct URL to a known document.

Password and MFA policy

Controls how staff prove who they are. OpenEMR 6.0.0 added password length limits, a rule requiring all four character types, reuse prevention for up to five prior passwords, expiration settings and a choice of Bcrypt, Argon or SHA512 hashing. The securing guide also recommends multi-factor authentication. Set these in the global settings, decide which accounts must use MFA, including remote and privileged users, and confirm the policy with a test account before relying on it.

FHIR API and patient portal

Controls the two surfaces that reach patient data from outside the clinic. The FHIR API implements SMART on FHIR v2.2.0 with OAuth 2.0 and OpenID Connect, and the patient portal gives patients direct access to their records. OpenEMR 8.3.0 and 8.4.0 fixed security vulnerabilities in both areas, so review scopes, enabled apps, portal account setup and your release level first. Inventory which third-party apps hold tokens and revoke any that the clinic no longer uses.

PHP and database runtime

Controls the code and data layers beneath OpenEMR. Recent releases require PHP 8.3 or later and run on a MySQL- or MariaDB-compatible database, so both runtimes must be supported and patched alongside the application. Check that the database account holds only the privileges OpenEMR needs, that the database accepts connections only from the application tier, and that backups are encrypted. Confirm exact version requirements in the release notes for your target version.

Decisions to settle before changing the server

This table compares the main choices to settle before changing an OpenEMR server, with the conditions where each option fits and the ongoing cost it carries. Read each row as a decision to record with the people who own security, clinical operations and infrastructure, since several choices affect each other. Settling TLS placement, encryption, identity and exposure first keeps the later hardening steps from being redone.

Decision	When it fits	Operational cost
TLS termination on the OpenEMR host	Small single-server installs with no load balancer, where the web server must handle certificates directly	Certificate renewal and web server configuration sit with the OpenEMR team; the host must be patched and monitored for TLS settings
TLS termination at a load balancer or reverse proxy	Environments that already run a managed proxy or load balancer with central certificate handling and logging	Proxy configuration, header trust settings and access controls must be reviewed; the proxy becomes an in-scope system for HIPAA risk analysis
Application-level encryption of stored items	When the goal is to protect specific stored items such as uploaded documents even if the volume is copied, and the team can test restores	Key management and recovery procedures must be designed and documented; a lost key means lost data, and the feature needs testing after upgrades
Full-disk or volume encryption at the infrastructure layer	When the hosting platform offers managed encryption and the team wants one control covering database, documents and backups	Depends on the cloud or data center key model; key custody, rotation and access to keys must be written into the operating procedures
Native OpenEMR MFA and password policy	Small deployments with a limited number of users and no central identity system, where policy can be set in OpenEMR itself	Staff must be enrolled and supported through resets; policy changes need communication to clinicians and periodic review of account lockouts
External identity provider	Organizations already running LDAP, Active Directory or a cloud identity service that must control access centrally (see the SSO topic for setup)	Directory integration, group mapping and joiner-mover-leaver processes add ongoing administration; the identity system becomes a dependency for clinical access
Password hashing: Bcrypt, Argon or SHA512	Bcrypt is the conservative default for most teams; Argon or SHA512 suit teams that have confirmed the option and their support tooling for it, in OpenEMR 6.0.0 or later	Changing the hashing choice affects how existing passwords are verified and rehashed; confirm the behavior with the OpenEMR documentation and test in a copy before changing it
Patient portal exposed to the internet	Practices that need patients to view records or message clinicians online, with a separate hardened public entry point	Public exposure needs its own access controls, monitoring, rate limiting and patch cadence; security testing of the portal is advisable before go-live
Bare-metal or VM install	Teams that manage operating systems, PHP and the database directly and want full control of the stack, and that can keep package versions current	Ongoing patching of the operating system, PHP 8.3 or later and the database falls to the internal team; configuration drift is a risk
Docker deployment	Teams with container platform experience that want repeatable builds and faster rebuilds from a known image	Image sourcing, scanning, secrets handling and volume backups need defined processes; the team must confirm which image and tag they are running for each release

Build sequence for a hardened OpenEMR server

This sequence takes a fresh or existing OpenEMR server from default settings to a configuration that exposes only HTTPS, removes setup scripts, protects stored documents, enforces password and MFA policy, and has a documented patch routine. Each step ends with a check you can record as evidence for your HIPAA risk work.

Confirm version, PHP and database baseline
Record the running OpenEMR version, the PHP version, and the database engine and version before changing anything. Recent OpenEMR releases require PHP 8.3 or later and run on a MySQL- or MariaDB-compatible database, so an older PHP runtime is a blocker to fix first. Compare your running version against the releases page and plan the move to a currently supported release before hardening, because patching an unsupported base leaves known gaps. Done means you have a written baseline with versions and a dated upgrade plan your team has approved.
Restrict inbound traffic to HTTPS
Configure the firewall, load balancer or container ingress so that only HTTPS on port 443 is reachable from the networks that need it, and confirm that the upstream guidance on opening only that port applies to your topology. Disable or redirect plain HTTP. Your network engineer runs the scan and your security engineer reviews the result. Done means a scan from an allowed network shows port 443 open, and a plain HTTP request to the site is refused or not answered.
Remove setup and admin scripts
After installation is complete, delete setup.php and any other administrative or installer scripts from the web root, or block their paths at the web server. The application administrator performs this and records the file list. Done means a direct request to setup.php and each removed script returns not found, and the removal is noted in the change record so a later upgrade does not restore them unnoticed.
Block direct web access to documents
Block direct web access to the sites/*/documents directory so that stored patient files can only be reached through the application's authorized paths. The web server administrator writes the rule and tests it. Done means a direct request for a known stored file path fails, while the same document opens normally when retrieved by an authorized user inside OpenEMR.
Set password policy and test it
In the OpenEMR administration settings, configure the minimum and maximum password length, the complexity rule, the reuse restriction and the expiration interval. Choose the password hashing algorithm your team has validated. The security administrator sets these values and creates a test account to confirm them. Done means a new account is rejected for a short password, a password that lacks required character types, a reused password, and an expired password, and each rejection is logged in your evidence file.
Enable MFA and test enrollment and recovery
Turn on multi-factor authentication for clinical and administrative roles first, then extend it as your policy requires. Enroll a test user in each role, then test the recovery path, such as a lost device or reset by an administrator. Confirm who can reset MFA and how that action is logged. Done means every privileged role completes enrollment, a failed second factor blocks login, and the recovery procedure has been performed once with a written record of the outcome.
Enable upload controls and file encryption
Enable the upload file white list so only approved file types can be stored, and enable the option to encrypt items stored on the drive if your design calls for it. Encryption choices affect key handling and backup restores, so decide them with your infrastructure team before go-live. Done means a disallowed file type is refused on upload, and a copy of a stored file taken from the disk outside the application cannot be opened as readable content.
Document settings and set a patch routine
Write down every setting changed in the previous steps, with the value, the owner and the date, and map each control to the HIPAA Security Rule standard it supports with your compliance lead. Then set a recurring patch review that checks the OpenEMR releases page and the security fixes listed in each release, and assign an owner who records the decision to apply or defer each one. Done means the settings register is approved, the review owner and cadence are named, and the first review is logged against the current release.

How hardening controls map to HIPAA safeguards

Access control is where most of the hardening work maps to the safeguards that govern who can reach patient information. Every clinician, front-desk worker and contractor should have a unique OpenEMR user account, so that actions in the record can be tied to a named person. The password settings in the administration globals, including minimum length, the rule requiring all four character types, reuse prevention and expiration, support this control. Multi-factor authentication adds a second check for remote and administrative logins. Ask your compliance lead which settings your written policy requires and record who approved them. Shared accounts, if any exist today, are the first thing to remove.

Transmission security maps most directly to the technical safeguards covering data in transit. Allowing only HTTPS, and where your network permits, exposing only port 443, keeps sessions, API calls and patient portal traffic from crossing the network in clear text. Verify this from outside your network, because a forgotten HTTP virtual host or an exposed setup path can undo the setting. Physical safeguards are mostly about the infrastructure: who can reach the server room or hosting console, where backups sit and what happens to disks that leave service. Confirm with your hosting provider or infrastructure team which of these controls they own and document them in writing.

Integrity and protection of stored data depend on keeping the documents directory out of web reach. The Securing OpenEMR guide asks you to block direct web access to the sites documents path and to remove setup.php and other admin scripts after installation. Pair this with the upload file white list so that only expected file types enter the record, and use the option to encrypt items stored on drive where your risk analysis calls for it. For audit controls, confirm which events your installed version logs, where logs are stored, who reviews them and how long they are kept. Vulnerability management covers the requirement to address known risks. Releases 8.3.0 and 8.4.0 fixed vulnerabilities in FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet, so plan to test and apply security releases on a fixed schedule.

Two limits affect how you present this mapping. OpenEMR's security assessment page for HIPAA and Meaningful Use is a starting point that still needs your review, and the final mapping has to be confirmed by your compliance lead or counsel against your own environment. OpenEMR's ONC certification history, including the 7.0.0 certification in July 2022 and the project's advice to upgrade to version 8 by March 1, 2026 to keep certification active, describes software tested under a specific edition. It does not replace your organization's HIPAA risk analysis, which must cover your hosting, staff, backups, interfaces and business associates.

What drives hardening effort and how to keep it down

This table pairs each driver of OpenEMR hardening work with the decision that shrinks it. Use it to see which factors in your environment will raise a quote and which you can settle before asking for one. The main takeaway is that exposure, instance count and file storage tend to matter more than the hardening checklist itself.

Driver	Why it changes effort	How to keep it down
Number of instances and environments	Each production, test and backup copy needs its own configuration, access review, HTTPS settings and evidence. Scope grows with every copy.	Limit to production plus one non-production copy where possible. Keep configuration in version control so each environment is built the same way.
Users and roles needing MFA and password rules	Multi-factor authentication, password length, complexity, reuse and expiration settings must be set per role and tested with real logins.	Group users into a small number of roles before hardening. Ask whether directory login (LDAP or Active Directory) can carry MFA so the policy lives in one place.
Patient portal and FHIR API exposure	Internet-facing portal and API endpoints need the most testing, access control and monitoring. OpenEMR's recent releases fixed security issues in these areas.	Decide early which parties need access and which do not. Restrict API clients by scope and disable endpoints you do not use.
Documents already stored on disk	Existing files may need the documents directory blocked from direct web access, encryption at rest, or migration to a protected location. Effort rises with file volume.	Measure the document store before scoping. Clean up unused files and confirm the upload file white list covers current file types.
Custom forms and modules	Each custom change needs regression testing after every OpenEMR update and security release.	Keep customizations few and documented. Ask the vendor to test them against each release as a fixed item in the quote.
Version gap to current release	Older installs may need PHP and database upgrades before security fixes can be applied. The latest supplied release is 8.4.1, dated September 20, 2026.	Stay on a supported version and apply security releases on a set schedule. Ask whether the quote includes the upgrade path from your current version.
Depth of compliance evidence	Assessors may expect written configuration baselines, access logs, backup tests and risk analysis records. Each item adds collection and review work.	Agree the evidence list with your compliance lead before work starts. DeployOpen prepares evidence for assessments but does not issue audit reports or certifications.
Hosting layers the team controls	Each layer (operating system, web server, database, network, backups, drive encryption) adds configuration and monitoring scope, and ownership gaps create open questions.	Name one owner per layer in writing. Ask the quote to state which layers are in scope and which remain with your team or hosting provider.

How hardening differs by deployment model

On a single virtual machine or physical server, the web server, PHP runtime, database and OpenEMR files usually share one host, so most hardening work falls to the team that manages that host. The Securing OpenEMR guide's direction to allow only HTTPS and block direct web access to sites/*/documents is applied in the web server configuration on that host.

TLS: Usually terminated by the web server on the host itself, so certificate issuance, cipher configuration and renewal belong to the server team.
Drive encryption: Typically full-disk encryption at the operating system level. OpenEMR's option to encrypt items stored on drive is a separate application setting that must be enabled and tested.
Security releases: The team downloads the OpenEMR release and applies PHP and operating system updates through its own process, testing first on a copy of the database and files.
Documents backups: The documents directory sits on the same disk as the application, so backup jobs must capture it with the database and restrict access to the backup target.
Host packages: The server team patches the operating system and PHP packages on its own cycle, so package checks are part of the host patch process.

Confirm with the vendor which PHP and database versions the target release requires, and confirm whether the encryption-at-rest option covers documents already stored on the server.

Access, secrets and exposure controls to set

These controls protect the hardening work itself. If an attacker can read database credentials, reach unencrypted backup keys, or sign in with a forgotten default account, the HTTPS and documents directory settings offer little protection. Each card names the risk it closes and the check that shows the control is in place.

Named admin accounts and least privilege

Give each administrator a named account with only the rights their role needs, and remove or disable the default and setup logins left over from installation. Shared administrator accounts make it impossible to tell who changed a clinical setting or exported a chart. Check by listing every account with administrative rights, confirming each maps to a named person, and confirming the default and setup logins can no longer sign in.

Database credentials outside the web root

Keep the database connection settings and any file holding passwords or keys in a location the web server cannot serve. A credential file readable through the browser exposes the entire patient data set. Check by requesting the configuration file's path over HTTP and confirming the request is refused, then confirming the database account holds only the privileges OpenEMR needs and that its password is not reused elsewhere.

Restricted network path to the database

Allow connections to the MySQL- or MariaDB-compatible database only from the application server or its subnet, and close the database port on any public interface. A reachable database port gives an attacker a second route around the web application. Check with a port scan from outside the trusted network, and confirm the database listens only on the interface the application uses.

Backup encryption keys stored apart

Encrypt backups of the database and documents, and store the encryption keys in a separate system with its own access control, not beside the backup files. A backup that can be decrypted with a key stored in the same location offers no protection if that location is copied. Check by restoring a backup on a test system using only the key from its separate store, and confirm that people who can read backups cannot also read the key without approval.

Administrative change logging

Record administrative changes, including user creation, permission changes, global setting edits and administrator access to patient records, in a log administrators cannot silently edit. Without this record, a HIPAA audit of who changed a setting or accessed a chart has no supporting evidence. Check which events your OpenEMR version records, forward logs to storage outside the server, and test by making a known change and confirming it appears with the user and time.

FHIR API and portal client limits

Limit the FHIR API and patient portal to the applications that need them, and grant each client only the granular scopes its use case requires. OpenEMR's FHIR API uses OAuth 2.0 and OpenID Connect with SMART on FHIR, and OpenEMR 8.3.0 and 8.4.0 both fixed security vulnerabilities in the FHIR API and patient portal. Check the registered clients, their scopes and redirect URIs, and PKCE use for public apps, then confirm an unregistered client or out-of-scope request is refused.

How to test that hardening holds and fails safely

Verification for OpenEMR hardening should be a written list of pass and fail tests, each with its expected result recorded before anyone runs it. A test that cannot fail proves nothing. Start with the network and web tests against the production hostname. A plain HTTP request should be refused or redirected to HTTPS, and if you have closed port 80, nothing should answer there at all. Request setup.php and the other admin scripts you removed after installation. Each should return not found. Request a direct URL to a file under sites/default/documents and expect it to be blocked. Record the status code and response body for every test, because a screenshot alone is weak evidence when an assessor asks how a result was produced.

The authentication tests check the policy as configured, not as intended. Attempt to save a password that breaks the length limit, the four-character-type rule or the reuse rule, and confirm each one is rejected. Set a password, change it to a recent one, and confirm the reuse check refuses it. Confirm the reuse count on the Administration Globals settings page matches the number in your written policy, because the setting, not the documentation, controls behavior. Log in with valid credentials and confirm MFA is required before access is granted. Then test recovery: lost-device recovery and an administrator-initiated reset. Confirm each restores access through a documented path and that neither one lets a user skip MFA.

Encryption and logging need tests from outside the application. If drive encryption is enabled, log in to the host as an operator without an OpenEMR session and inspect a stored document. It should not open as readable content. Confirm in the vendor documentation which item types the encryption option covers, and record that scope in your compliance file. For logging, trigger a failed login and an administrator change, such as altering a user's role. Confirm both events appear with the account, timestamp and source address. Then confirm the log copies are stored where application administrators cannot quietly edit them, and test that a log entry is still written when the application itself is under load.

Retest on a schedule tied to change. Rerun the full suite after every OpenEMR security release, and read each release note for the affected areas. The 8.3.0 and 8.4.0 releases, for example, fixed security issues in FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet, so those areas need the same scrutiny as the login path. Run the suite again after each configuration change, including Globals, web server, PHP and database settings. Keep the configuration files in version control so each change can be matched to a test run. Targeted reruns for a narrow change are reasonable, but schedule a full run at intervals your organization sets in its own policy.

Commission an independent penetration test scoped to the web application, the API, including the FHIR endpoints, and the patient portal. Give the tester the same authenticated roles your staff and patients use, and agree the rules of engagement in writing before testing starts. Ask for a report with reproduction steps, severity and a retest of each fix. Treat the findings and retest results as evidence for the compliance file. They support it but do not replace an audit, and an independent auditor or certification body makes its own determination. Ask your compliance lead which evidence the assessor will expect before you schedule the test.

What to monitor, back up, patch and document after go-live

Hardening settings only stay effective if someone watches them. The cards below cover the recurring work that keeps an OpenEMR server aligned with its security controls and the HIPAA Security Rule after launch. Each item feeds the next: logs show what happened, backups limit the damage, patches close known gaps, and records prove the work was done.

Monitor failed logins and admin changes

Set up alerts or log review for repeated failed logins, lockouts, changes to user accounts and permissions, and edits to global settings such as password, MFA and audit options. Confirm where OpenEMR and the web server write their logs and how long they are kept. Test the alert by triggering a failed login on a non-production copy so you know it fires.

Monitor web server and application errors

Collect PHP and web server error logs centrally and review them on a set schedule. Repeated errors on upload, login or API paths can point to probing, misconfiguration or a broken security control, such as a directory that should block web access but does not. Confirm which log files your Docker or host install writes and who receives them.

Back up the database and documents directory

Back up the MySQL- or MariaDB-compatible database and the sites documents directory together so records and their attachments stay in step. Encrypt backups, store a copy outside the primary host, and record retention periods. Confirm whether encryption at rest for stored files is enabled, because a backup of encrypted items is only useful with the matching keys.

Test restores on a schedule

A backup that has never been restored is an assumption. Restore the database and documents directory to an isolated environment at a set interval, then open a sample patient chart, check an attached document and confirm user logins work. Record the date, the restore time and any gaps, and treat failures as incidents.

Follow OpenEMR release notes and security fixes

Read each release note, not only the version number. Releases 8.3.0 and 8.4.0 fixed security vulnerabilities in FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet, so each one should be assessed for your enabled modules. Set a patch window, test in staging first, and keep a log of which fixes were applied and when.

Track PHP and database versions

Recent OpenEMR releases require PHP 8.3 or later and a MySQL- or MariaDB-compatible database. Maintain an inventory of PHP, database, operating system and container image versions, and check them against each release's requirements before upgrading. Ask your support provider or internal team to confirm end-of-life dates for each component so unsupported runtimes are flagged early.

Re-run hardening checks after upgrades

Every upgrade can reset files, restore default configuration or add new admin scripts. After each upgrade, repeat the checks from your hardening baseline: HTTPS only, setup and admin scripts removed, direct web access blocked to the documents directory, and MFA and password policies still enforced. Keep the results with the change record so you can show the controls were tested after the change.

Keep the configuration record and risk analysis current

Maintain a configuration record that lists enabled modules, interfaces, FHIR client registrations, storage encryption settings and hosting boundaries. Update your HIPAA risk analysis when these change, since the Securing OpenEMR guide points to a security assessment page for HIPAA and Meaningful Use requirements. Confirm with your compliance lead which evidence auditors will ask for and where it is stored.

Review user and MFA device access on a cadence

Review active user accounts, role assignments and MFA devices at a set interval, and remove leavers, shared accounts and unused service access promptly. Check that MFA enrollment covers all accounts that can view or export patient data, including administrators. Document each review with the reviewer, the date and the changes made, since this record supports access control evidence.

What does OpenEMR hardening cost and what do we need to provide?

Is OpenEMR free, and what does that not include?

The software itself is free. OpenEMR is licensed under the GNU GPL v3.0 and there is no paid edition, so the license fee is zero. What the license does not cover is everything around the software: the server and its operating system, PHP and database upkeep, TLS certificates, backups, encryption of the host, access control design, logging, security testing, and the time your staff spends on each release. Those costs are real and they recur, so compare them against the full cost of running the system, not against the license line alone.

What drives the cost of OpenEMR security hardening?

The cost follows the size and state of your environment. Hardening work is priced from a written scope, and the main drivers are the number of servers and containers, whether the install is Docker-based or a traditional host, how much existing configuration needs review, whether you need MFA or directory integration built as part of the work, how much evidence you want produced for HIPAA readiness, and whether a test of the running system is included. Ask any quote to list each item as a separate deliverable so you can see what is one-time work and what is a recurring retainer for upgrades and testing.

How long does OpenEMR hardening take?

Duration depends on the factors that set the work, not on a fixed number. The main factors are how many environments are in scope, how current the install is (recent releases require PHP 8.3 or later and a MySQL- or MariaDB-compatible database, so older stacks may need upgrading first), how many settings must change in the admin globals, how much of the hosting layer is under your control, and how quickly your team can review and approve changes. Ask for a timeline tied to these inputs in the written scope, and confirm which items depend on your own change windows.

Can our team harden OpenEMR without a partner?

Yes, if you have the skills and time to own the work. The Securing OpenEMR guide lists the core steps: allow only HTTPS, consider exposing only port 443, remove setup.php and other admin scripts after installation, block direct web access to the documents directory, and set multi-factor authentication, password policy and encryption of stored files. Your team would also need to keep the server patched and track each security release. A partner is most useful when staff capacity is limited, when you need an outside review of the result, or when you want the configuration and evidence documented for an independent assessor.

What access and information does DeployOpen need to start?

You provide scoped access to the environment and the people who know it. Typically this includes the OpenEMR version and deployment method, the hosting platform and network diagram, the web server and PHP configuration, the database setup, current admin and user account lists, the directory service if you use LDAP or Active Directory, your backup and logging arrangements, and the named owner for approvals. Access should be granted through your own accounts and change process, with least privilege and a defined end date. Confirm the exact list during scoping, because it changes with your hosting model.

Does DeployOpen certify that our OpenEMR system is HIPAA compliant?

No. DeployOpen does not issue HIPAA certifications or attestations. HIPAA compliance is assessed by your organization and, where you choose or require it, by an independent auditor. DeployOpen prepares the controls, configuration, documentation and evidence that an assessor would review, mapped to the HIPAA Security Rule requirements that apply to your setup. The OpenEMR Securing guide also points to a security assessment page for HIPAA and Meaningful Use requirements, which is a useful starting reference for your own review.

How are OpenEMR security releases handled after go-live?

Security releases need an agreed owner, a test step and a change window. OpenEMR publishes releases on its GitHub repository. Recent releases fixed security vulnerabilities in areas such as the FHIR APIs, the patient portal and billing, so timely application matters. After go-live, agree in writing who monitors releases, who tests the update in a non-production copy, who approves the change, and how fast a security release is applied. Support and upgrade work can be covered under a retainer, and you should confirm the response expectations in that agreement rather than assume them.

How DeployOpen scopes and hands over OpenEMR hardening

DeployOpen plans, implements, hardens and documents self-hosted platforms inside the client's own infrastructure, so OpenEMR runs in your cloud account, data center or air-gapped network. Hardening work starts from the Securing OpenEMR guide and is scoped against your HIPAA requirements in writing before any change is made. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing first.

How we scope

The written scope lists each hardening item, such as HTTPS-only access, setup script removal and documents directory protection.
Scope records which HIPAA safeguards each control supports, and which remain with your compliance team to assess.
Engagements are fixed-scope, and ongoing support is available as a retainer after handover.

How we build

Hardening changes go to a staging copy of your OpenEMR install before production.
Authentication settings cover password length, reuse, expiration and hashing, plus MFA where OpenEMR supports it.
Web server rules block direct access to the documents directory and restrict the upload file types.

How we hand over

Handover includes a configuration record for each hardened setting, with the file or menu path where it lives.
Test evidence covers HTTPS redirects, blocked script paths, blocked documents URLs and login policy checks.
Runbooks describe how your team applies future OpenEMR security releases and reruns these checks.

How we support

Retainers can cover monitoring of OpenEMR security releases and applying them in staging first.
Periodic reviews can re-check configuration after OpenEMR upgrades, PHP changes or server rebuilds.
Confirm with your auditor which HIPAA evidence they need, since DeployOpen prepares evidence but does not attest.