Open Source EHR

What is an open source EHR?

An open source EHR is an electronic health record whose source code is published under a licence that lets anyone use, study, modify and share it. There is no per-user licence fee, but the organization running it takes on hosting, security, upgrades, support and integration, either with its own staff or through a vendor.

Open source describes the licence, not the quality or the scope. Some projects are full practice systems with billing; others are platforms meant to be extended; and one, VistA, is a large government system released through public records law.

Do not confuse an open source EHR with openEHR. openEHR is an open specification for modelling clinical data with archetypes and templates, not a product you install. Some systems store data using openEHR models, but choosing an open source EHR and adopting openEHR are separate decisions.

Which open source EHRs are most widely used?

OpenEMR, OpenMRS and VistA are the three projects most often considered. Each grew out of a different setting, which explains most of their differences today.

• OpenEMR: A practice management and EHR system aimed at outpatient practices. Its project site describes it as free and open source, ONC certified, and able to produce X12 5010 claims.
• OpenMRS: A medical record platform built to be extended with modules, widely used in low- and middle-income countries. It is released under the Mozilla Public License 2.0 with a Healthcare Disclaimer.
• VistA: The VA's longstanding health information system. The VA publishes a version obtained under the Freedom of Information Act, with monthly patches posted and some content redacted.

How do OpenEMR, OpenMRS and VistA differ?

They differ in who they were built for, how they are built and how much of a finished product they are out of the box. The right one depends on whether you need a ready practice system, a platform for a national program, or a large inpatient-capable system.

• Intended setting: OpenEMR targets U.S. and international outpatient practices; OpenMRS targets programs that need a configurable record for many clinics; VistA was built for a large integrated hospital system.
• Technology: OpenEMR is a PHP web application on MySQL or MariaDB; OpenMRS is Java-based; VistA runs on the M language with its own built-in database.
• Billing: OpenEMR includes claims billing; OpenMRS focuses on the clinical record and relies on other tools or modules for billing; VistA's billing was built around the VA's needs.
• Certification: OpenEMR states it is ONC certified, which matters for U.S. practices taking part in CMS programs; the others are not usually chosen for that reason.
• Integration: The VistA Monograph describes access through APIs, remote procedure calls and HL7 interfaces; the other two expose web APIs and support standards through their communities and modules.

What do open source EHR licences allow?

Open source licences allow free use and modification, but they attach conditions, mostly about sharing source code when you distribute the software. Those conditions matter most to vendors who build products on top of an open source EHR.

• Using it internally: Running an open source EHR for your own clinics rarely triggers any obligation to publish your changes.
• Distributing it: Selling or giving the software, or a modified version, to others can require you to share source code under the licence's terms.
• OpenMRS modules: The OpenMRS License FAQ says modules can be released under other licences, including closed source, which lets vendors build commercial add-ons.
• Healthcare Disclaimer: OpenMRS adds a disclaimer that the software is provided without warranty for clinical use, so the deploying organization owns clinical safety.
• Trademarks: Project names are often protected separately from the code, so a modified product may need its own name.

Have counsel review the exact licence and version before you build a product on any of these projects. Licence questions are cheap to answer early and expensive to unwind after release.

What does free leave out?

Free leaves out everything a commercial vendor would normally bundle: hosting, security monitoring, upgrades, support, training, interfaces and regulatory upkeep. Those costs are real, and for many organizations they exceed what a licence would have cost.

• Hosting: Servers or cloud services, backups, disaster recovery and uptime monitoring.
• Security: Patching the application, database and operating system, plus access reviews, logging and penetration testing.
• Upgrades: Testing each new release against your customizations before rolling it out.
• Support: A help desk for users and an escalation path for defects, either in-house or through a support partner.
• Interfaces: Connections to labs, imaging, pharmacies, clearinghouses and health information exchanges.
• Data migration: Moving records from the old system, including history that does not map neatly.
• Training: Role-based training and refreshers as workflows change.

When does ONC certification matter?

ONC certification matters when a U.S. practice or hospital takes part in CMS programs that require certified EHR technology, such as the Promoting Interoperability measures. If certification is a requirement, check the exact certified version and configuration, not just the project name.

Certification also has an upkeep cost. Heavy local changes can move a deployment away from the configuration that was certified, and new certification criteria arrive on ONC's schedule, not yours. Plan for both before customizing.

• Look it up: Search ONC's Certified Health IT Product List for the project and version, and note which criteria the listing covers.
• Match the version: Run the certified release, or confirm with your support partner that your release carries the certification you need.
• Fill the gaps: Some criteria may be met by separate certified modules, such as e-prescribing, which you then have to license and connect.
• Track changes: Assign someone to follow new certification criteria and the project's plans to meet them.

How should you judge an open source EHR project?

Judge an open source EHR project by the health of its community and its release process as much as by its features. A project with an active community, regular releases and a clear security process is safer than a feature-rich project that has gone quiet.

• 1. Activity: Look at commit frequency, the number of active contributors and how quickly issues are answered.
• 2. Releases: Check the release history, the upgrade notes and how long older versions receive fixes.
• 3. Security: Find the project's process for reporting vulnerabilities and how fast past issues were patched.
• 4. Support partners: List the companies that offer paid hosting and support, and speak to their customers.
• 5. Documentation: Read the install, admin and API docs, and test whether they match the current release.
• 6. Standards: Confirm support for the HL7 v2 messages and FHIR resources you need, with working examples.
• 7. Exit path: Check how you would export all data if you later moved to another system.

How do you integrate an open source EHR?

You integrate an open source EHR the same way as a commercial one: HL7 v2 for feeds such as admissions, orders and results, FHIR APIs for apps and data exchange, and X12 for claims where the system bills. The difference is that you can add or fix an interface in the code yourself.

That freedom has a cost. Every interface you add to the core code is something you must carry through each upgrade. Where possible, build integrations as modules or as separate services behind an interface engine, so the EHR can be upgraded without rewriting them.

• Inventory first: List every feed and API the clinics need, with volumes and the partner on the other side.
• Use the engine: Route HL7 v2 traffic through an interface engine so mapping changes do not touch the EHR code.
• Prefer standard APIs: Use the project's FHIR or REST APIs rather than reading its database directly.
• Test on upgrade: Keep a regression suite of sample messages and API calls, and run it against every new release.

What are the risks of running an open source EHR?

The main risks are falling behind on security patches, drifting into a private fork, and depending on one or two people who understand the system.

• Patch lag: Security fixes are published openly, which also tells attackers what to look for in unpatched systems.
• Private forks: Local changes pile up until upgrading becomes too costly, and the system stops receiving community fixes.
• Key-person risk: One developer or administrator holds most of the knowledge, and leaves.
• Unclear accountability: Nobody owns clinical safety, uptime or compliance because there is no vendor contract to point to.

Each risk has a plain answer. Set a patch window and keep to it, record every local change with the reason for it, document the system well enough that a new administrator can run it, and sign a support agreement that names who is accountable for uptime and security. A HIPAA risk analysis should cover the open source system like any other.

Organizations that run open source EHRs well tend to contribute fixes back to the project. Upstream contributions mean fewer local changes to carry, and they build the relationships that help when a hard problem appears.

How Agnotic can help

Agnotic Technologies helps clients evaluate open source EHRs against their needs, then host, secure and extend the chosen system, building custom features as modules so upgrades stay manageable.

Agnotic also builds the HL7 v2, FHIR and X12 interfaces that connect an open source EHR to labs, payers, health information exchanges and other EHRs, and handles data migration from the system it replaces.

Sources

• OpenEMR project site
• OpenMRS License FAQ
• U.S. Department of Veterans Affairs: VistA Monograph
• U.S. Department of Veterans Affairs: FOIA Version of VistA