OpenEMR patient portal implementation: what the module covers and when teams implement it
The OpenEMR patient portal is the module that lets patients reach their practice record from a browser, including online appointment booking, secure messaging, payments and completion of intake forms. A rollout has to settle which of these functions go live first, which network path patients use to reach the portal, and who in the practice owns each function after go-live. The portal is part of the OpenEMR codebase, which is licensed under the GNU GPL v3.0, and there is no paid edition of the software, so the license itself adds no cost. Practices that already run OpenEMR for scheduling and records usually want the portal so patients can book, message, pay and complete forms without a second system holding their information.
Version history should shape the plan. OpenEMR 8.3.0 and 8.4.0 both fixed security vulnerabilities, and the fixes covered the patient portal along with FHIR APIs, billing, the fax and SMS module and the fee sheet. Read the release notes for each version you plan to run, confirm which fixes touch the features you enable, and set a patch cadence before go-live. Recent releases also require PHP 8.3 or later and a MySQL- or MariaDB-compatible database, so the target version affects the host image, the database and the upgrade path. Confirm these requirements against the exact release you intend to deploy, because they change between versions.
Internet exposure is the main risk. A portal is an internet-facing application that handles patient identity, messages, payments and records, so the decision is how to expose it and in what order to harden it. The Securing OpenEMR guidance says to allow only HTTPS, consider opening only port 443, remove setup.php and other admin scripts after installation, and block direct web access to the documents directory. It also recommends multi-factor authentication and strong password policies. Settle the access path, such as a reverse proxy, a web application firewall or a VPN-protected route for staff, and name the person who reviews portal logs, before the build starts.
Teams usually implement the portal once their scheduling and records workflows are stable, someone is named to own patient communication, and the practice can run an internet-facing service with patching and monitoring. They often wait if identity verification for new patients is unsettled, if there is no plan for reviewing messages outside office hours, or if billing setup is still changing, since payments and fee sheets are affected by the same security fixes. DeployOpen plans, builds and hardens the portal inside your own cloud accounts, data center or network. This section is not legal advice. Whether portal use creates HIPAA obligations for your practice, what your business associate agreements must say, and how state law treats patient messages are questions for your counsel and compliance lead.
What the OpenEMR patient portal does, according to the platform docs
The cards below cover the portal functions named in this topic's scope, plus the sign-in controls that protect them. Each one ties a function to what OpenEMR's documentation supports and what to confirm in the release you plan to run. The docs describe these areas at a general level, so gateways, form types and workflows should be checked against release notes and a test instance before scope is fixed.
Online appointment scheduling
Patients can request or book appointments through the portal, which connects the scheduling module directly to the people who use it. The main configuration decision is which appointment types, providers and time windows patients can see and act on. Confirm in your target release exactly which scheduling actions the portal exposes, then test a booking end to end against the provider calendars your front desk uses.
Secure messaging with the practice
Secure messaging lets patients exchange messages with the practice inside the portal. Because these messages carry protected health information, the configuration questions are who receives each message category, how staff are notified, and how long messages are retained. The 8.3.0 and 8.4.0 releases both fixed security vulnerabilities in the patient portal, so confirm your target release includes those fixes and recheck message routing after upgrading.
Online payments from patients
Patients can view balances and pay bills through the portal, which ties the portal to billing and fee records. The documentation reviewed here does not name the payment gateways the portal supports, so confirm which processors are available in your release, whether any requires a separate account or add-on, and how payments post back to patient accounts. Card data handling affects your PCI DSS scope, so involve your payment and security owners before choosing a gateway.
Patient forms and intake
Patients complete registration, intake or health history forms in the portal before a visit. Confirm which form types ship with your release, which can be customized, and whether submitted answers are written to the chart automatically or held for staff review. Map each form field to the chart location it will populate, and test a completed form on a staging instance before patients use it.
Portal account sign-in controls
Portal accounts are an internet-facing identity surface that patients use directly. The Securing OpenEMR guide recommends multi-factor authentication and strong password policies, and OpenEMR 6.0.0 added password length, complexity, reuse and expiration settings to its global configuration. Confirm which of these settings apply to portal patient accounts in your release, and whether multi-factor authentication covers them, before you open the portal to patients.
How to expose the OpenEMR portal to the internet without widening the attack surface
The first decision is how patients reach the portal, because each option sets what else on the server is exposed. With direct internet exposure, the web server that runs OpenEMR accepts connections from anywhere, so every script and folder it serves is reachable by anyone who finds it. A reverse proxy in a demilitarized zone changes that picture: the proxy is the only internet-facing host, forwards only the portal paths, and keeps the application and database on the internal network. The proxy then becomes a high-value target that must be patched and configured with the same care. A VPN keeps the whole OpenEMR server off the public internet, but it requires patients to install a client and enroll, which suits staff and remote clinicians better than a patient-facing portal. Document the choice in writing, along with who owns the proxy or VPN and who reviews its logs.
The Securing OpenEMR guide sets the baseline for whichever model you choose. It says to allow only HTTPS, and to consider opening only port 443 so that no plain HTTP or other service listens publicly. After installation, remove setup.php and other administrative scripts from the web root, because an installer left in place is an easy foothold. The guide also says to block direct web access to sites/*/documents, the directory where uploaded patient files are stored. Verify each step from outside your network: scan the public address to confirm that only 443 responds, request setup.php and a known path under sites/*/documents, and confirm both are refused. Repeat these checks after every upgrade, because upgrades can restore files or change web server rules.
The guide recommends multi-factor authentication and strong password policies. 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. Version 6.0.0 also added LDAP and Active Directory login, which validates passwords against the directory but still requires the user to exist in OpenEMR. Staff and patient identity should be decided separately. Staff usually belong in your directory, so reusing it may fit. Patients rarely do, so confirm with your vendor and in your own test environment whether the portal can enforce MFA for patient accounts, and whether that requires an external identity layer in front of the portal.
Enforcement shows why these choices need evidence. France's CNIL fined Hopital Prive de la Loire EUR 500,000 on 3 September 2026 under GDPR Articles 32 and 34. The CNIL found that external access to its patient record system lacked a VPN and multi-factor authentication, and that access control ignored the care team's need to know. The case is illustrative of the risk, not a ruling on OpenEMR. For US organizations, HIPAA's Security Rule does not certify any configuration. HHS states that no standard requires certifying compliance and that private certifications do not stop HHS from later finding a violation. The Office for Civil Rights relies on complaints, compliance reviews and audits, so keep dated records of your exposure design, scan results, MFA settings and access reviews.
Configuration decisions for the portal and when each option fits
This table lists the configuration choices to settle before the OpenEMR patient portal goes live, with what each option changes for patients and staff and when it fits. Confirm default values and available settings in the Administration Globals page for your target version, because options differ between releases. Treat each row as a decision with an owner, not a default to accept.
| Decision | Option | What it changes for patients and staff | When it fits |
|---|---|---|---|
| Portal features | Scheduling, messaging, payments and forms, each enabled separately | Patients submit requests and pay online, and staff receive new queues to answer and reconcile | Enable one workflow at a time, with a named staff owner and tested process |
| Network path: direct HTTPS | Patients reach the portal over HTTPS on port 443 | Portal is reachable without an intermediary, so the web server carries full exposure | When the hosting team can harden, patch and monitor the web server directly |
| Network path: reverse proxy | A proxy sits in front of OpenEMR and forwards portal traffic | Logging, client address handling and some access controls move to the proxy layer | When an existing edge service already filters traffic; confirm forwarding settings for your version |
| Network path: VPN | Patients or partners connect through a VPN before reaching the portal | Users must install and use client software, which limits general patient access | Staff or partner access to sensitive functions; France's CNIL fined a hospital in 2026 for external access without VPN or MFA |
| Patient authentication: local passwords | Portal passwords with length limits, character rules, reuse prevention and expiration | Patients face stricter password rules, and reset and lockout requests are likely to rise | Sites without a directory for patients; the strong rule requires all four character types |
| Patient authentication: MFA | Second factor required at portal login, if available for portal accounts in your version | Patients complete an extra step at sign-in, and support must handle lost or changed devices | Any internet-facing portal holding ePHI; the Securing OpenEMR guide recommends multi-factor authentication |
| File uploads and document encryption | Upload file white list plus encryption of items stored on disk | Patients can send only permitted file types, and encrypted storage adds key management duties | Portals accepting forms or images; confirm key custody before enabling, since lost keys can make documents unreadable |
| Password hashing | Bcrypt, Argon or SHA512, selected in Administration Globals | Sets how portal and staff passwords are stored; confirm how existing hashes are handled when changed | Choose the option your team can verify and document for the target version, and confirm its default there |
What data must be in place before patients log in to the portal
The patient portal is only as reliable as the chart data behind it. Before anyone receives an invitation or logs in, the practice needs patient records that match its identity rules. Decide which demographic fields must agree before a portal account is linked to a chart, how the front desk handles a patient who changes a name or phone number, and who approves merges of duplicate charts. Write these rules down first, then run a duplicate search across the existing patient list and resolve every match. A portal account linked to the wrong chart exposes one patient's health information to another, so this check must be complete before go-live.
Online booking depends on configuration that many teams treat as administrative. Confirm which providers are active in OpenEMR and which appointment types patients may book themselves, along with the duration, rendering provider and facility for each. Retired providers and internal-only appointment types should be inactive so they never appear in a patient's options. On the billing side, review the fee schedule and payment settings the portal will display or collect against, and decide which charges patients can pay online. Finally, build or review the form templates patients will complete, such as intake and consent forms, and confirm which ones are required before a first visit. Assign an owner to each template who signs off on its wording.
Data from a prior system needs a load and check cycle before the portal is tested. Map each source field to its OpenEMR location, load a small batch first, then compare record counts, allergies, medications and appointment history against the source for a sample of patients chosen by clinicians. OpenEMR's FHIR API implements FHIR Bulk Data v1.0 export at system, patient and group level in NDJSON format, which supports extraction for migrations and analytics. Use it to pull data out for reconciliation or reporting, but treat the export as a reconciliation aid only. The portal itself must be tested against migrated records: sign in as test patients and confirm account linking, existing messages, balances and bookable slots.
Patient-level data moved into the portal is ePHI and carries the same obligations as the rest of the system. Under the HIPAA Security Rule, which applies to covered entities and their business associates for all ePHI they create, receive, maintain or transmit, the portal, its database, exports and staging files need the same unique user identification, automatic logoff, access control and audit logging as the EHR itself. Apply the same encryption decisions to exports and backups, and set a rule for where NDJSON extracts are stored, who can read them and when they are deleted. If a consultant or migration partner handles the data, confirm that a business associate contract exists requiring Security Rule compliance and incident reporting. HIPAA has no certification, so ask for evidence of these controls and the records that prove them.
Rollout sequence for the OpenEMR patient portal, with the output of each step
This sequence moves the OpenEMR patient portal from a confirmed scope to a tested, hardened and handed-over system in infrastructure the practice controls. Each step ends with a named output, so the owner can check progress before the next step begins.
Confirm scope and target release
The practice and the implementation lead agree which portal functions are in scope: online scheduling, secure messaging, payments and forms. They confirm the target OpenEMR release, using the release that fixed portal vulnerabilities as the baseline. Recent releases require PHP 8.3 or later and a MySQL or MariaDB compatible database, so the hosting platform must be checked against these requirements. The 8.4.1 release was published on September 20, 2026, after 8.4.0 on September 13, 2026, so teams should confirm the current release on the OpenEMR releases page before signing. Output: a signed scope document that names the release, the database, the PHP version and the portal features in scope.
Set up a test environment
The implementation team builds a non-production OpenEMR instance that matches the target release, PHP version and database engine. Docker deployment options are available, and the team should decide whether the test instance uses the same container images, reverse proxy and TLS setup as production. Authentication is connected to the test directory or test accounts, and backups are configured so the test instance can be rebuilt. The instance is complete when a clean install runs, the portal login page loads over HTTPS, and the version and database checks match the signed scope. Output: a configured test instance with a short build record listing versions, images and settings.
Configure portal features and access policy
The team enables and configures the portal functions named in the scope, including scheduling rules, message routing, forms and payment settings. Payment configuration depends on the payment processor the practice has chosen, so the team confirms the processor's requirements before configuring it. Access policy is set in the global administration settings: password length and complexity, password reuse and expiration rules, and multi-factor authentication for portal accounts. The team documents every setting so that later changes can be traced. Output: a configuration record and a draft runbook section for portal administration, reviewed by the practice's clinical and privacy leads.
Build the network path and harden
The team designs the path from the internet to the portal, typically through a reverse proxy or web application firewall in front of the OpenEMR web server. Only HTTPS is permitted, and the team considers exposing only port 443. Setup and other administrative scripts are removed after installation, direct web access to the patient document directories is blocked, and the upload file allow list is applied. The team also decides whether files stored on disk are encrypted and confirms that administrative access uses a separate, restricted path. Output: a hardening checklist with each control marked as applied, tested or accepted with a reason.
Load and test functional data
The team loads synthetic patient records, appointment templates and form content into the test instance. Real patient data is not used in test environments unless the practice has approved that use under its own privacy and security controls. Testers walk through each portal workflow: booking an appointment, sending and reading a secure message, completing a form and making a test payment. They record each failed step, its cause and its fix. Output: a functional test report that lists each scenario, its result, open defects and the person accountable for each defect.
Run access and security testing
The security team tests the portal the way an outside user or attacker would reach it. The work covers authentication and session handling, authorization between patients and between staff roles, input handling in messaging and forms, file uploads, and the exposed web and API endpoints. Known vulnerabilities in the chosen release are checked against the vendor's security notes. Each finding is rated, assigned and retested after the fix. The team confirms that multi-factor authentication cannot be bypassed through the portal login path. Output: a security test report with findings, fixes, retest results and any accepted risks signed by the practice owner.
Pilot with a limited patient group
The practice opens the portal to a small, defined group of patients and a named set of staff. The group is chosen so that the practice can support it closely, and its members agree to take part. The team monitors sign-in failures, support requests, message delivery, payment outcomes and any access complaints. A rollback plan is written and rehearsed before the pilot starts, so staff know how to close the portal quickly. The pilot ends with a go or no-go decision based on the agreed criteria. Output: a pilot report with metrics, issues, fixes made during the pilot and a recorded go or no-go decision.
Go live and hand over
The team schedules the production cutover, applies the hardening checklist and the tested configuration to production, and confirms that the security controls still hold after the change. Monitoring, log collection and backup jobs are checked before the portal is opened to all patients. Administrators receive training, and the practice assigns owners for patching, user administration, incident response and vendor contacts. Patch and upgrade steps are written into the runbook, and the team confirms the process for applying future OpenEMR security releases. Output: a production go-live checklist, a runbook and a handover pack signed by the practice's operations owner.
What drives portal implementation effort and how to keep it down
This table lists the main drivers of OpenEMR patient portal effort, how each one raises the work, and what keeps it contained. Read each row as a question to answer in your written scope before the build starts. The main takeaway is that a narrow launch scope, clean patient data and reused identity lower effort more than any single setting. No price is given here, because cost follows from a written scope agreed before work begins.
| Driver | How it raises effort | What keeps it down |
|---|---|---|
| Number of portal features enabled | Each function, such as scheduling, secure messaging, payments or forms, needs configuration, role mapping, testing and staff training. | Launch with a small set of functions and add others in later phases after the first release is stable. |
| Number of providers and locations | Each provider calendar, location, appointment type and visit rule must be modeled and tested before patients can book online. | Start with one location and the providers who will take online bookings first, then extend the schedule model. |
| Quality of existing patient data | Duplicate records, missing contact details and inconsistent demographics break portal account matching, reminders and messaging. | Deduplicate and validate demographics before migration, and agree who owns each cleanup step and its sign-off. |
| Integrations with billing, messaging and imaging | Payments, statements, text or secure message delivery and imaging links each need interface design, field mapping and error handling. | Define the data each integration exchanges, and defer non-essential links until the portal runs reliably. |
| Network complexity and existing VPN or reverse proxy | Internet exposure needs a publishing path, TLS, port rules and firewall changes that the security team must review and approve. | Reuse the existing reverse proxy or load balancer, allow only HTTPS, and document the traffic path before the build starts. |
| MFA and identity source choices | A separate login store for patients or staff adds account lifecycle, password policy and MFA work. Directory login still needs a matching OpenEMR user record. | Reuse the directory staff already use where it fits, and confirm which patient-side MFA options your OpenEMR version supports. |
| Amount of custom forms work | Each intake, consent or registration form needs layout, field mapping, validation, legal review and decisions on where data is stored. | Reuse existing forms, limit custom forms to those the clinical or legal owner approves, and version each form. |
How the OpenEMR patient portal connects to the rest of the platform and other systems
The portal reads and writes data held by several OpenEMR modules and relies on external identity and messaging services. Each connection below has a purpose and a check to run before go-live. Confirm that every third-party connection is supported in the release you plan to deploy.
Scheduling and the calendar
Online booking reads availability from the OpenEMR calendar, so the slots patients see depend on provider schedules, appointment categories and visit types configured in the core application. Decide which appointment types patients may book online and who may cancel or reschedule them. Verify by booking, rescheduling and cancelling a test appointment as a test patient, then confirm the slot is released in the calendar for other patients.
Billing and payments
Patients view balances and pay through the portal, and those payments post against the same billing records your claims process uses. Confirm which payment processor your release supports and whether card data is handled in a hosted form. Assign an owner to reconcile portal receipts with deposits. Verify with a sandbox payment and a declined test card, then check that the ledger, the patient statement and the processor report agree.
Forms and clinical documentation
Intake questionnaires and consent forms completed in the portal are filed into the patient's chart, where clinicians review them. Decide which forms patients can complete before a visit, how staff review and sign them, and where uploaded documents are stored. Verify by submitting a test form as a test patient, then confirm it appears in the correct chart with the expected date, author and status, and that the patient cannot open another chart.
FHIR API with OAuth 2.0 and SMART
External apps reach patient data through the FHIR API, which implements FHIR R4, US Core 8.0 and SMART on FHIR v2.2.0 with OAuth 2.0 and OpenID Connect. Register each app with the narrowest scopes it needs and require PKCE for public clients. Verify by completing a SMART launch with a test patient, confirming the issued token carries only approved scopes, and checking that a request outside those scopes is refused.
LDAP, Active Directory and Google Sign-In
Staff logins can validate passwords against LDAP or Active Directory, a capability added in version 6.0.0, and can use Google Sign-In, added in version 6.1.0. The directory check does not remove the requirement that the user already exists in OpenEMR, so provisioning and removal need a defined process. Confirm whether these options apply to patient portal accounts in your release. Verify with a disabled directory account and with a valid account that has no OpenEMR user record.
Fax and SMS module
The fax and SMS module sends messages that can carry appointment details or other health information outside the portal. OpenEMR 8.3.0 and 8.4.0 both fixed security vulnerabilities in this module, so any deployment on an earlier release should plan an upgrade before enabling it. Confirm which messaging provider your release supports, and decide which message types may contain health information. Verify by sending test messages to test numbers and reviewing the sending logs.
Questions buyers ask before hiring help with the OpenEMR patient portal
How much does an OpenEMR patient portal rollout cost?
No public price applies, because the software is free. OpenEMR is licensed under the GNU GPL v3.0 and has no paid edition, so the money goes to people and infrastructure. The main cost components are:
- Labor for scoping, configuration, integration with scheduling and billing data, testing and go-live. This is usually one-time.
- Hosting in your cloud account, data center or network, including servers, storage and network paths. This recurs.
- Security work such as TLS certificates, backups, monitoring, access controls and security testing. Setup is one-time, while backups, monitoring and patching recur.
- Your staff time for decisions, reviews and testing.
Costs rise with the number of portal functions enabled, the number of integrations, the amount of data cleanup and the number of sites. Ask any provider for a written scope that lists each component as one-time or recurring, then compare quotes against that same scope.
How long does an OpenEMR patient portal rollout take?
No fixed duration can be stated without a written scope. The timeline depends mainly on which portal functions go live first, because online scheduling, secure messaging, payments and forms each change different configuration and staff workflows. Other drivers include:
- the number of integrations with existing systems
- the amount of data that needs review or cleanup
- whether the portal is exposed to the internet at launch or starts on an internal network
- how many test patients and reviewers your staff can release
- how quickly your team can approve decisions
Security review and any upgrade to a recent release also add time. OpenEMR 8.3.0 and 8.4.0 both fixed security vulnerabilities in the patient portal, so the baseline version affects the plan. Ask for a schedule with milestones, the staff hours assumed for each milestone and the dependencies that would move the dates.
What does a practice have to provide for a portal rollout?
The practice supplies decisions, people, access and test data. A provider can build and configure the portal, but several inputs depend on your organization:
- Decisions: which portal functions to enable, who may send and receive secure messages, scheduling rules, payment handling and which forms patients complete.
- Staff time: a named owner who can approve changes, plus front-desk and clinical reviewers for testing.
- Test patients: realistic records in a test copy of the system, with consent and privacy rules applied to any real data you use.
- Network access: administrator access to your hosting environment, DNS control for the portal address, certificate issuance and firewall changes.
- Business documents: a signed business associate agreement before any protected data moves to a provider.
Confirm these items in the written scope so that delays caused by missing inputs are visible early.
Can a small practice run an OpenEMR patient portal rollout alone?
A small practice can attempt it alone, but it needs specific skills in-house. OpenEMR is free, documented and supported by a community of volunteers and professionals, and the project maintains a list of professional support vendors. The work still requires skills in several areas:
- running a PHP application (recent releases require PHP 8.3 or later) on a MySQL- or MariaDB-compatible database, or on the Docker deployment options
- Linux server administration, TLS and firewall configuration
- applying security settings such as multi-factor authentication and password policy
- patching promptly when a release fixes portal vulnerabilities
- restoring backups and testing that restores work
If no one on staff can cover those areas, or if the practice cannot patch within a short window, a partner or a managed support arrangement may be the safer path. Ask any provider to name the people who will do the work and the skills each one brings.
Does the OpenEMR patient portal make a practice HIPAA compliant?
No. Software does not make a practice HIPAA compliant. HIPAA has no certification. HHS states that no Security Rule standard requires an entity to certify compliance, and that private certifications do not prevent HHS from later finding a violation. The HIPAA Security Rule applies to covered entities and their business associates for all electronic protected health information they create, receive, maintain or transmit. That means your organization must run its own risk analysis, policies, workforce training, access controls, audit controls and vendor oversight.
OpenEMR's ONC certification covers the product's functions. It does not cover how your organization operates. For penalties assessed on or after 28 January 2026, HHS's inflation-adjusted civil money penalty ranges from $145 to $2,190,294 per violation, with a calendar-year cap of $2,190,294 (45 CFR 102.3). Confirm your obligations with counsel and your compliance advisers.
What must a business associate agreement require for a portal hosting provider?
The agreement must require the provider to comply with the Security Rule. Under 45 CFR 164.314(a)(2)(i), a business associate contract must require the business associate to:
- comply with the applicable Security Rule requirements for electronic protected health information
- pass the same terms down to any subcontractor that creates, receives, maintains or transmits that information
- report security incidents to the covered entity, including breaches of unsecured protected health information
The contract should also state how the provider will support your risk analysis, how it will handle access to your data and how data is returned or destroyed when the engagement ends. Those last points are not set by that section alone, so confirm them with counsel and with the provider before signing. Ask for the draft agreement early so that legal review does not delay the portal schedule.
Which OpenEMR portal security settings should engineers check before internet exposure?
Check transport, exposure, authentication and file handling first. The Securing OpenEMR guide gives several baseline steps:
- Allow only HTTPS, and consider opening only port 443.
- Remove setup.php and other administration scripts after installation.
- Block direct web access to sites/*/documents.
- Enable multi-factor authentication and a strong password policy. OpenEMR 6.0.0 added password length limits, a rule requiring all four character types, reuse prevention for up to five prior passwords and expiration settings.
- Apply the upload file white list and consider encrypting items stored on disk.
The guide also points to a security assessment page for HIPAA and Meaningful Use requirements. Test each setting after deployment with an external scan and a manual check of the portal login, messaging and file upload paths. Record the results as evidence for your risk analysis.
Will the proposed HIPAA Security Rule revision change portal requirements?
Possibly, but the rule is not final, so design to the current rule. HHS proposed a major Security Rule revision on 6 January 2025 (90 FR 898). As of October 2026, no final rule has been published, and the Unified Agenda projects final action for July 2027 (RIN 0945-AA22). The proposal would strengthen the cybersecurity requirements for electronic protected health information, so it is sensible to build the portal with those requirements in mind. Practical steps include documenting the configuration, keeping asset and access inventories current, keeping your business associate contracts up to date and planning for regular patching and testing. Ask any provider how it tracks regulatory changes and how a change to the rule would affect an existing scope.
How DeployOpen scopes, delivers and supports the OpenEMR patient portal
DeployOpen plans, implements, hardens, documents and supports OpenEMR patient portal deployments inside your own cloud accounts, data centers or air-gapped networks. Engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts. Ongoing support, upgrades and continuous testing are available as retainers.
How we scope
- A written scope lists which portal features go live: online scheduling, secure messaging, payments and forms.
- It names the internet exposure model, including which hostnames, ports and network paths the portal may use.
- It sets acceptance tests, including checks that the OpenEMR version in use carries the security fixes it requires.
How we build
- We deploy OpenEMR on infrastructure you control, with PHP 8.3 or later and a MySQL- or MariaDB-compatible database.
- We allow only HTTPS, remove setup.php and admin scripts, and block direct web access to document folders.
- We configure multi-factor authentication, password rules, the upload allow list and file encryption, then test each one.
How we hand over
- You receive configuration records, network and exposure diagrams, and runbooks for portal administrators and your operations team.
- Test evidence covers portal logins, access control between patients and staff, and the upload and file storage settings.
- Documentation records your decisions on multi-factor methods, password policy, and the OpenEMR version and fixes running.
How we support
- Ongoing support, upgrades and continuous testing are available as retainers after go-live.
- When OpenEMR publishes security fixes to portal code, we plan and apply the upgrade in your environment.
- Application and API security testing can cover the portal and the FHIR endpoints your integrations depend on.
