OpenEMR or GNU Health: which fits your organization's scope
If you run an ambulatory practice or clinic group in the United States and need an electronic health record with scheduling and billing, OpenEMR is the more direct fit. If you are standing up a hospital, a public health program or a multi-department health information system with laboratory and imaging workflows, GNU Health is the one to evaluate first. The section below sets out the conditions under which each applies, so you can test them against your own organization. Choose OpenEMR when your core need is ambulatory care with US billing. It is a free, GPL-3.0 application with scheduling, billing and internationalization, and the project states that it is ONC certified. Its FHIR API implements FHIR R4, US Core 8.0 and SMART on FHIR v2.2.0 with OAuth 2.0 and OpenID Connect, which matters if your integrations must meet US Core profiles. The stack is PHP with a MySQL- or MariaDB-compatible database, so your team should be comfortable operating that combination. Confirm the current release and certification status directly with the OpenEMR project before you commit.
Choose GNU Health when the decision is about a hospital or public health program. Its HMIS covers hospital management, an electronic medical record, a laboratory information system and medical imaging orders, with deployments reported in several countries. It is built on Tryton and PostgreSQL, so the skills you need are Python, PostgreSQL and Tryton administration rather than PHP. Its FHIR REST server is documented as still in development and not fulfilling the FHIR specification, so any plan that depends on standards-based exchange should be tested against your target profiles first. Ask your shortlist which FHIR resources and profiles they must support on day one, and which lab and imaging interfaces are required. The decision turns on those four questions: scope, FHIR requirements, lab and imaging, and the PostgreSQL and Tryton versus PHP and MySQL or MariaDB skills you have in house.
Which platform fits which scenario
This table maps common healthcare scenarios to the platform with the stronger fit and the supplied reason behind it. Read each row as a starting point, then confirm the gaps noted in the cells against the current release and your own environment. The main takeaway is that OpenEMR fits US practice and FHIR-app work, while GNU Health fits hospital, laboratory, imaging and public health programs that can accept a FHIR server still in development.
| Scenario | Better fit | Reason and what to confirm |
|---|---|---|
| Single or multi-site outpatient practice | OpenEMR | Scheduling, billing and practice management are core to OpenEMR, and it holds ONC certification as a 2015 Edition Base EHR. Confirm the certification edition and status your practice needs. |
| Hospital needing lab and imaging orders | GNU Health | GNU Health HIS includes a laboratory information system, laboratory and medical imaging orders, and DICOM worklists. Confirm which hospital workflows your staff need beyond these modules. |
| Public health or national program | GNU Health | GNU Health covers epidemiological reporting and has deployments in several countries. Confirm the reporting formats and the local requirements of your health authority. |
| Organization needing FHIR apps now | OpenEMR | OpenEMR's FHIR API implements FHIR R4, US Core 8.0 and SMART on FHIR v2.2.0. GNU Health's FHIR REST server is documented as still in development and not fulfilling the FHIR specification, so test any app against it before committing. |
| Team that must interoperate with a regional network | GNU Health, if the region uses Thalamus | GNU Health's Thalamus server interconnects nodes into regional or national networks. OpenEMR does not have a supplied equivalent, so confirm the network's required protocols before choosing. |
| Team with a US practice that needs bulk data for analytics | OpenEMR | OpenEMR implements FHIR Bulk Data v1.0 export at system, patient and group level in NDJSON format. Confirm the export scope your analytics pipeline needs. |
| Team with a Tryton-skilled or Python-capable IT group | GNU Health | GNU Health HIS runs on Tryton with PostgreSQL 15 or later and Python 3.10 or later. Confirm that your staff can maintain this stack, since OpenEMR runs on PHP 8.3 or later with MySQL or MariaDB. |
How each platform is built and what that means for operations
OpenEMR and GNU Health HIS are both self-hosted, but they sit on different stacks with different install paths, database requirements and upgrade rhythms. The cards below set out the components each team will patch, back up and staff, and the checks to run before committing.
OpenEMR's PHP application stack
OpenEMR runs as a PHP application on a MySQL- or MariaDB-compatible database. Recent releases require PHP 8.3 or later, so your team must track PHP runtime support alongside OpenEMR's own security releases. The project also offers Docker deployment options, which can simplify packaging but still leave the host, database and web server patching with you. Confirm which PHP and database versions your target release supports before you pick an operating system image.
GNU Health's Tryton application stack
GNU Health HIS is a Tryton application running on PostgreSQL 15 or later, with Python 3.10 or later, Gunicorn and Tryton 7.0 for the latest stable HMIS component. Your team therefore needs PostgreSQL administration, Python service management and Tryton module knowledge, which differs from a typical PHP web application team. Check whether your staff can support a PostgreSQL and Python service layer before comparing it to OpenEMR's stack.
Install methods that must not be mixed
GNU Health offers several install paths: a vanilla installation with gnuhealth-control, Ansible since 4.4, operating system packages, a virtual machine image and an embedded Raspberry Pi edition. The documentation warns against mixing these methods on one system. Choose one path at the start, record it in your runbook, and ask your implementation partner how upgrades will follow that same path, because switching later can mean a rebuild.
Patching cadence and release tracking
OpenEMR publishes frequent point releases, and the 8.3.0 and 8.4.0 releases fixed security vulnerabilities in FHIR APIs, the patient portal, billing and the fee sheet. GNU Health HIS has a 5.0 major line and patch releases such as 5.0.7. Your patch process should cover both the application and its runtime, and it should set a named owner for reviewing security advisories. Ask each vendor for its supported-version policy in writing before you commit.
Backups across application and database
Both platforms keep clinical data in a relational database, so backups must capture the database and the uploaded documents together. OpenEMR's documents live in the site directories, which the Securing OpenEMR guide asks you to protect from direct web access. GNU Health's Tryton data sits in PostgreSQL, so point-in-time recovery and restore testing depend on PostgreSQL skills. Test a full restore on both stacks before go-live and record the recovery time you achieve.
In-house skills and staffing
OpenEMR favors teams with PHP, MySQL or MariaDB and web server administration experience, along with HTTPS and access control hardening. GNU Health favors teams comfortable with Linux, PostgreSQL, Python services and Tryton configuration. Neither platform's skill profile is a substitute for clinical informatics. Map your current staff to each profile, and ask a partner to quote the training, documentation and handover needed to close any gap.
How FHIR, SMART and identity logins work in each platform
OpenEMR gives you a published FHIR R4 API (4.0.1) aligned to US Core 8.0 and SMART on FHIR v2.2.0, with OAuth 2.0 and OpenID Connect, PKCE for public apps and granular scopes. Bulk Data v1.0 export runs at system, patient and group level in NDJSON, which is the practical route for migrations and analytics extracts. On the sign-in side, OpenEMR added LDAP and Active Directory login in version 6.0.0, which validates passwords against the directory but still requires the user to exist in OpenEMR, and Google Sign-In arrived in version 6.1.0. The directory check does not create the local account, so provisioning and deprovisioning need an explicit process. Confirm how your directory groups map to OpenEMR roles and whether the SMART scopes your apps request match the granular scopes you plan to grant.
GNU Health's FHIR REST server is documented as still in development and as not fulfilling the FHIR specification, so it should not be the integration layer for a FHIR-dependent project today. Its identity and federation story is different: Thalamus is the GNU Health Federation message and authentication server that interconnects nodes, which suits multi-site networks but is not the same thing as a SMART-on-FHIR authorization server. Do not assume SMART launch, PKCE or directory login behavior from either project's marketing. Read the current GNU Health documentation for supported authentication methods and confirm them against the release you intend to run.
Run a pilot before you commit. Register one test SMART app, request the scopes your use case needs, and confirm that a user with a restricted role cannot read resources outside those scopes. Test a directory login for a user who is disabled in Active Directory and one who exists in the directory but not in OpenEMR. For a Bulk Data export, time a full patient-group extract and check the NDJSON output against your schema. Record each result in writing, because these checks will become your evidence for the security assessment and your rollback criteria if an integration fails.
Capability comparison: scope, lab, imaging, FHIR and licensing
This table sets OpenEMR's practice EHR against GNU Health's hospital and public health system across license, certification, billing, laboratory, imaging, FHIR, bulk data, identity and deployments. Read each row as a question to answer for your own setting, and treat blank or unverified items as confirmation tasks before shortlisting.
| Capability | OpenEMR | GNU Health HIS |
|---|---|---|
| License | GNU GPL v3.0 | GNU GPL v3 or later |
| Primary setting | Medical practices and clinics, with scheduling, billing and EHR for outpatient care | Hospitals and health information systems, with public health and community modules |
| Certification | ONC certified as a 2015 Edition Base EHR; version 7.0.0 certified 7/19/22. Confirm current certification status for your version | No ONC certification was supplied. Confirm with the GNU Health project and your certifying body before relying on it |
| Billing | Included, as part of the practice management scope | Health center finances and billing are listed as features. Confirm claim formats and payer integrations for your market |
| Laboratory information system | Lab orders and results are part of the EHR. Confirm depth against your lab workflow | A laboratory information system is part of the HMIS, introduced as new in version 5.0. Confirm analyzer and interface support |
| Medical imaging and DICOM worklists | Confirm imaging order and PACS integration needs with the project and your integrator | Refactored imaging packages include DICOM worklists and better integration with the Orthanc PACS server in version 5.0 |
| FHIR implementation | FHIR R4 (4.0.1), US Core 8.0 and SMART on FHIR v2.2.0 with OAuth 2.0 and OpenID Connect | FHIR REST server is documented as still in development and not fulfilling the FHIR specification. Treat it as unsuitable for FHIR-dependent integration today |
| Bulk data | FHIR Bulk Data v1.0 export at system, patient and group level in NDJSON | No bulk data export was supplied. Confirm with the project before planning migrations |
| Identity options | LDAP and Active Directory login (6.0.0), Google Sign-In (6.1.0), strong password rules and hashing choices | Confirm supported directory and single sign-on options for the HMIS and Tryton-based access |
| Public deployments | Widely deployed in US clinics and practices; ask for references in your segment | Documented deployments include Spain, Argentina, Jamaica, India, Laos, Cameroon, Pakistan and Gambia |
What each license and edition covers, and what is not sold
OpenEMR is licensed under the GNU GPL v3.0, a copyleft license that lets you use, copy, modify and redistribute the software without a license fee. The project describes itself as free and open source, and scheduling, billing and internationalization ship in the same codebase. The license itself is not sold, so your spending goes to the work around the software.
- No license fee: Running OpenEMR does not require a license purchase. The GPL v3.0 governs copying and distribution of the code.
- Copyleft on distribution: If you distribute modified OpenEMR code to others, the GPL v3.0 terms apply to that distribution. Internal use in your own organization generally does not trigger redistribution, but confirm the position with counsel for your arrangement.
- No paid edition described: The sources reviewed for this page describe no commercial or paid edition of OpenEMR. Ask any vendor selling a paid OpenEMR version which features and support it adds, and where those are documented.
- Certification follows the version: ONC certification applies to a specific certified product version, so the release you run in production matters as much as the license.
Check whether your environment depends on a certified version, and confirm with the OpenEMR project which release your certification covers before you commit to an upgrade path.
GNU Health is licensed under the GPL v3 or later, with copyright held by Luis Falcon and GNU Solidario. The or-later clause lets recipients choose a later version of the GPL when one is published, so the license terms can change only through the GPL itself. As with OpenEMR, the license carries no fee, so the cost of a GNU Health deployment sits in the services and infrastructure around it.
- Same free-to-use starting point: Downloading and running the hospital information system does not carry a license fee under the stated license.
- Named copyright holders: Because copyright is held by named parties, ask who maintains contributor agreements and controls the release process that your deployment depends on.
- No paid edition described: The sources reviewed for this page describe no paid edition of GNU Health HIS. Confirm with the GNU Health project and any service provider whether a paid edition, subscription or support tier exists.
- Components carry their own terms: The HIS, the MyGNUHealth personal health record and Thalamus are separate components. Check the license of each one you deploy, along with the terms of dependencies such as Tryton and PostgreSQL.
Request a written list of every component in your planned deployment and its license, since a hospital information system usually spans more than one package.
Because both licenses permit free use, the recurring costs sit in the work around the software. Services are sold by implementation partners, hosting providers, testing firms and support organizations, and each one is quoted separately. The largest variable costs usually come from hosting, integration and the staff who keep the system patched, configured and documented. Costs also shift with your own environment, such as whether you run a single server, a high-availability pair or a cloud deployment in your own account.
- Hosting: You pay for servers or cloud accounts, backups, storage and network capacity in your own environment. These costs recur for as long as the system runs.
- Configuration and integration: Build work for interfaces, identity connections and laboratory or imaging links is typically one-time, though later changes recur.
- Testing and validation: Penetration testing, regression testing and compliance evidence are purchased separately. DeployOpen plans and performs security testing and prepares compliance evidence, but independent auditors and certification bodies issue any attestation or certificate.
- Support and upgrades: Support contracts and retainers recur. Ask whether the quote covers upgrades, security patches and out-of-hours response.
Request line items for one-time setup, recurring hosting and support, and optional testing, so you can compare the two platforms on the same basis.
OpenEMR's ONC certification was earned by a specific version. Version 7.0.0 was certified on 7/19/22 as a 2015 Edition Base EHR after testing by SLI concluded on 6/30/22. The project's website told users to upgrade to version 8 by March 1, 2026 to keep their system's active certification, so certification is an ongoing maintenance question rather than a one-time event. Confirm the certification status of GNU Health for your jurisdiction with the project before assuming any equivalent.
- Certified version tracking: Keep a record of the certified version and the upgrade path, and confirm with the project how each release affects certification.
- Security fixes in 8.3.0 and 8.4.0: Both releases fixed security vulnerabilities in the FHIR APIs, the patient portal, billing, the fax and SMS module and the fee sheet. Plan regression tests for these areas after each upgrade.
- Release cadence: Version 8.3.0 shipped on August 18, 2026, 8.4.0 on September 13, 2026 and 8.4.1 on September 20, 2026. Plan staff time for frequent point releases, and confirm what 8.4.1 changes before scheduling it.
- Runtime requirements: Recent OpenEMR releases require PHP 8.3 or later and a MySQL- or MariaDB-compatible database, so your platform team must keep those components supported.
Confirm with the OpenEMR project which release your certification covers, then schedule a test window before each security update.
What drives the running cost of each platform
The running cost of either platform is mostly people and hosting, not license fees, because both OpenEMR and GNU Health are free to download under open-source licenses. Expect to pay for infrastructure, database administration, upgrades and security patching, integration work and training, and to decide whether any of these come from your staff, a systems integrator or a vendor support contract. Most of these costs recur every year. Initial setup, data migration, interface build and staff training are one-time costs, while patching, backups, monitoring and on-call coverage recur for as long as the system runs.
The skills underneath each platform differ, and that changes who you pay. OpenEMR runs on PHP 8.3 or later with a MySQL- or MariaDB-compatible database, so the team needs PHP and database administration skills and a plan for keeping up with releases such as 8.3.0, 8.4.0 and 8.4.1. GNU Health HMIS runs on Tryton 7.0 with PostgreSQL 15 or later, Python 3.10 or later and Gunicorn, so the team needs Python, Tryton and PostgreSQL skills. If you adopt GNU Health's Orthanc integration, the imaging path adds a PACS to patch and back up, and Orthanc's own support is sold separately by Orthanc Team SRL, quoted on request. Thalamus federation connectivity is another line item to confirm if you plan to join a regional network. Ask each vendor or integrator to price these skills and support hours in writing rather than assuming they are included.
Ask for a written quote that splits the work into fixed-scope deliverables: installation method, hosting and backup design, database operations, a patch and upgrade calendar, interface and FHIR integration, training, and handover documentation. Ask whether the quote covers the first year only, whether support hours expire, and what happens when a major release changes the stack. Because GNU Health's own documentation says its FHIR REST server is still in development and does not fulfill the FHIR specification, ask for a costed plan for any custom FHIR work instead of assuming it will be off the shelf. Ask OpenEMR's integrators to show the FHIR, SMART and Bulk Data work they have already delivered, and ask for the effort on each.
Moving from one platform to the other
This sequence moves demographics, encounters, orders, results and billing from one system to the other with a documented mapping, a validation record and a dated cutover. It produces a system you can run in parallel, check and retire without losing clinical or financial history.
Inventory the data and workflows in scope
Your clinical lead, practice or hospital administrator and the platform team list every data domain to move: demographics, encounters, orders, results, medications, documents, imaging references and billing. For each one, record where it lives today, who owns it and whether it is needed for active care, reporting or legal retention. The output is a signed scope document that separates data to migrate, data to archive and data to leave behind. Confirm each domain against the target product documentation before you commit to it.
Map source fields to target structures
Your data architect and a clinical informaticist build a field-by-field mapping from the source model to the target model. Going from OpenEMR to GNU Health, this covers the patient record, encounters, lab orders and results, and billing codes. Going from GNU Health to OpenEMR, it covers the same domains through the source's export options. Terminology, code sets and units are the usual failure points, so the mapping must name every code system and every transformation rule. The output is a reviewed mapping workbook with open questions logged and assigned.
Extract source data through standard interfaces
Your integration engineers pull the data out. OpenEMR's FHIR API implements FHIR Bulk Data v1.0 export at system, patient and group level in NDJSON format, which suits bulk extraction for migration and analytics, provided the calling application is authorized through its SMART on FHIR scopes. For GNU Health, confirm with the vendor how records are exported, because its FHIR REST server is documented as still in development and not fully compliant with the FHIR specification. Run the extract into a staging area with checksums and record counts for each resource type. Done means every count reconciles with the source system.
Rebuild laboratory and imaging workflows
Your lab manager, radiology lead and GNU Health implementation partner rebuild order-to-result paths rather than copying them. GNU Health 5.0 added a new laboratory information system and refactored imaging packages with DICOM worklists and better integration with the Orthanc PACS server, so confirm which of these your version and configuration support. OpenEMR's order and result handling must be mapped onto GNU Health's lab catalog, specimen types and reference ranges. Expect this to be configuration and testing work, not a bulk data load. The output is a tested set of order sets, result codes and imaging worklist entries signed off by the lab and radiology leads.
Load, validate and reconcile the data
Your migration engineer loads the transformed data into a non-production target and runs reconciliation scripts. Counts, patient match rates, duplicate detection, encounter-to-order links and billing balances are compared with the source. A clinical reviewer samples charts across each specialty and checks that allergies, medications and problem lists are intact. Failed records go to a defect log with an owner. The output is a reconciliation report that the clinical and finance leads accept in writing.
Run both systems in parallel
Your operations lead keeps the source system live for a defined period while staff enter new work in the target system under agreed rules. Each day, a reconciliation run compares new orders, results and charges between the two platforms and logs differences. Parallel running exposes workflow gaps that testing misses, especially in billing and imaging. The output is a parallel-run log with a closed defect list and a go or no-go decision recorded by the sponsor. Set the length of this period with your vendor and clinical leads, not from a general rule.
Cut over and freeze the source
Your change manager and the platform team schedule the final delta load, freeze writes in the source system and confirm that the target is the system of record. Access controls for both systems are reviewed, since audit trails and user accounts must match the new roles. Staff receive short, role-specific instructions and a support route for the first days of live use. The output is a signed cutover record listing the final reconciliation, the freeze time and the named system owner.
Archive and retire the source system
Your records manager and security lead export a read-only archive of the source system, store it under the retention rules that apply to your organization, and document where it sits. Access to the archive is restricted and logged, and the source servers, backups and credentials are decommissioned in a planned change. Confirm retention obligations with your legal and compliance teams before any deletion. The output is a retirement certificate, an archive index and an updated asset register.
What implementing each platform involves and where projects run long
Plan an OpenEMR project as a configuration and hardening exercise on a PHP and MySQL- or MariaDB-compatible stack, which means someone must own the web server, database, PHP 8.3 or later runtime, and upgrade cadence from day one. Start with the Securing OpenEMR guide: allow only HTTPS, consider exposing only port 443, remove setup.php and other admin scripts after installation, and block direct web access to sites/*/documents. Then configure the practice-side work that drives most of the effort: scheduling, clinic workflows, the fee sheet and billing setup, and user roles. If you need certification-related configuration, confirm with your own assessor which settings and evidence matter for your scope, because DeployOpen prepares controls and evidence but does not issue certifications. Also confirm whether your OpenEMR version carries the current security fixes, since the 8.3.0 and 8.4.0 releases fixed vulnerabilities in FHIR APIs, the patient portal, billing and the fee sheet.
GNU Health asks for a different kind of setup. Choose the installation method first (vanilla installation with gnuhealth-control, Ansible, operating system packages, the virtual machine image or the Raspberry Pi edition) and do not mix methods, because the documentation warns against it. The vanilla path expects a GNU/Linux or BSD server, PostgreSQL 15 or later, Python 3.10 or later, Gunicorn and Tryton, so budget for database administration and Tryton module management, not just application installation. Imaging is its own track: the 5.0 line brought DICOM worklists and better integration with the Orthanc PACS server, and that integration must be configured and tested against your modality set. Local content is also substantial, including codes, catalogs, the health center's own packages and staff training on a Tryton client. Confirm early which components your setting needs, such as the HIS, MyGNUHealth or Thalamus federation, because each adds an operating and governance load.
Projects tend to slip in four places regardless of platform. Data mapping is usually first: patient identifiers, legacy encounter records and billing codes rarely map cleanly, so run a mapping review with clinical and finance owners before migration scripts are written. Interface work is second; if you plan to use OpenEMR's FHIR R4 and Bulk Data export or GNU Health's FHIR interfaces, confirm the exact resources and scopes you need, because GNU Health's documentation states its FHIR REST server is still in development and does not fulfill the FHIR specification. Lab and imaging integration is third, with device, order and result flows that need end-to-end testing. Staff training is last and most often underestimated, so schedule it against go-live dates rather than after them. Ask any implementation partner for a written scope that names these four items and the acceptance tests for each.
Questions buyers ask before choosing or hiring help
How much does each platform cost to run?
Both packages are free to download under open-source licenses, so the recurring cost is the infrastructure, the staff time to operate them and any paid help you buy. Neither project publishes a fixed run cost in the sources we used. OpenEMR is licensed under the GNU GPL v3.0, and its releases require PHP 8.3 or later with a MySQL- or MariaDB-compatible database, so hosting and database administration are your cost. GNU Health is licensed under the GPL v3 or later and requires PostgreSQL 15 or later, Python 3.10 or later and Tryton 7.0 on a GNU/Linux or BSD server. Ask any vendor or integrator for a written list of one-time setup, recurring hosting, support hours and upgrade work, and for what each line covers.
How long does an implementation take, and what drives it?
No duration is given in the sources for either platform, so treat any timeline as something to request in writing. The main drivers are the number of sites and users, how much existing data must be migrated, which modules you turn on (for OpenEMR, billing and patient portal; for GNU Health, laboratory, imaging and pharmacy), the interfaces to labs, imaging and payers, and whether you need a validated configuration for your regulator. GNU Health offers several installation paths, and its documentation warns against mixing them, so pick one method before the project starts. Ask for the phases, the acceptance tests and the assumptions behind the schedule.
What does the work need from my team?
Expect to need people who can run Linux servers, manage PostgreSQL or MySQL-compatible databases, apply security patches and back up and restore data. For OpenEMR, you also need someone who owns the PHP runtime, the web server configuration and the FHIR client registrations. The OpenEMR Securing guide asks you to allow only HTTPS, remove setup.php and other admin scripts after installation, and block direct web access to the documents directory. For GNU Health, you also need staff who can run Tryton and Gunicorn and who understand its module model. Clinical and billing staff must be trained, and someone must own clinical content, such as codes and forms. Confirm these roles in your own environment before you commit.
Can a small practice deploy either platform on its own?
A technically capable practice can deploy OpenEMR on its own using the project's Docker options or a traditional LAMP-style stack, provided someone can maintain the server, certificates, backups and monthly updates. GNU Health is more demanding to self-deploy: it has a vanilla installation path, an Ansible option since 4.4, a virtual machine image and a Raspberry Pi edition, but it is built for hospitals and public health programs. A small practice without IT staff should price managed hosting or an implementation partner, and should ask for a written scope covering patching, backups and restore testing before going live.
Can GNU Health replace an existing EHR in a US practice?
Probably not as a direct replacement without a formal fit assessment. GNU Health is a hospital management and health information system with an electronic medical record, laboratory and imaging modules, and it is listed as deployed in countries including Spain, Argentina and India. Its own documentation says the FHIR REST server is still in development and does not fulfill the FHIR specification. OpenEMR, by contrast, is ONC certified as a 2015 Edition Base EHR and implements FHIR R4, US Core 8.0 and SMART on FHIR v2.2.0. Before deciding, confirm with the vendor which US certification and interface standards you must meet, and whether GNU Health's data model and integrations cover your billing and reporting needs.
When is outside help worth paying for?
Outside help makes most sense when the work needs skills your team lacks, when a go-live date carries regulatory or patient-safety weight, or when you must integrate with labs, imaging or payers. DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms in your own cloud accounts, data centers or air-gapped networks. Most engagements are fixed-scope, with scope, deliverables and timelines agreed in writing before work starts, and ongoing support is available as a retainer. DeployOpen does not issue audit reports or certifications. Ask any partner for a written scope, named deliverables, an acceptance test plan and a handover of documentation.
What compliance evidence does each platform bring to my audit?
Neither open-source project gives you an audit report. OpenEMR states that it is ONC certified and that users must upgrade to version 8 to keep their system's active certification, and its certification of 7.0.0 was completed on 7/19/22 after testing by SLI. Certification covers the software at the tested version, not your deployment, so your own controls, risk analysis and policies remain your responsibility. GNU Health does not publish an equivalent certification in the sources we used, so ask its maintainers and your assessor which evidence applies. Independent auditors and certification bodies, not DeployOpen, issue the reports you may need.
How DeployOpen helps choose, implement or migrate
DeployOpen plans, implements, customizes, integrates, hardens, backs up, upgrades, documents and supports self-hosted open-source platforms inside your own infrastructure. For OpenEMR vs GNU Health, that means starting from your clinical scope, your lab and imaging workflows and your team's skills before any installation decision is made.
How we scope
- Map which workflows you need: practice scheduling and billing, hospital operations, laboratory or imaging orders
- Confirm FHIR, SMART on FHIR and bulk export requirements against each platform's documented support
- Agree the scope, deliverables and timeline in writing before any work starts, since most engagements are fixed-scope
How we build
- Install and configure the chosen platform in your cloud account, data center or air-gapped network
- Integrate identity, lab, imaging and interface points, and document each configuration decision
- Test the platform, harden the deployment and prepare the controls and evidence your compliance assessment will need
How we hand over
- Deliver runbooks for backup, upgrades, patching and access management for your own operators
- Provide documentation covering configuration, integrations and the test results behind each delivered control
- Walk your team through the operational procedures so your staff can run the system after handover
How we support
- Offer ongoing support, upgrades and continuous testing as a retainer after handover
- Plan upgrade windows around each platform's release cadence and your own change control process
- Keep compliance evidence current so your independent auditor or certification body has an accurate record to review
