# Open-source patient scheduling: two paths, and the one nobody warns you about

> In healthcare the scheduler ships inside the record system. What OpenEMR, OpenMRS, Medplum and the generic self-hosted schedulers actually get you — and the one archived project worth reading first.

URL: https://opencals.com/blog/open-source-patient-scheduling
Author: Stanislav Tyshchenko
Published: 2026-09-08
Updated: 2026-10-27
Categories: industry-guide, comparison

> **Key takeaway**
>
> Searching for open-source patient scheduling gets you two very different things: electronic health record systems that happen to include a scheduler, and generic self-hosted schedulers that know nothing about patients. The first is a much larger commitment than "we need online booking". The second leaves the appointment disconnected from the chart. Decide which of those you're actually signing up for before you compare features.

A physiotherapy practice in Kraków asked their IT contractor for online booking last year. Four therapists, one address, patients who mostly ring the front desk. The quote that came back was for a nine-month OpenEMR implementation.

The contractor wasn't being dishonest. He'd searched for open-source patient scheduling, found what everyone finds, and priced the thing he found. It's just that the practice had asked for a booking page and been quoted a records system, because in healthcare those are frequently the same product.

## In healthcare the scheduler is a feature of the chart

Every other resource-booking category has standalone tools. Meeting rooms have MRBS. Desks have Seatsurfing. Restaurants have — barely — TastyIgniter. Healthcare doesn't work that way, and the reason is that an appointment is worth very little on its own.

A booking in a clinic wants to know: which patient, which record, which encounter type, which insurance, which clinician's licence covers this, and what happened at the last visit. All of that lives in the record system. So the open-source projects that scheduled patients well grew into record systems, and the ones that stayed pure schedulers stayed generic — they'll book a person into a slot, and that person is a name and an email, not a patient.

Which means the honest first question isn't "which scheduler". It's whether you're replacing your record system or not.

## Path one: take the EHR, get the scheduler with it

**OpenEMR** is the one you'll keep hitting, and for a small clinic replacing paper or an ageing local install, it's the serious option. GPL-3.0, PHP, around 5,400 stars, over 3,000 forks, and — the number that actually matters — commits landing this week. It's been maintained continuously for two decades, which is rare enough in this category to be the headline.

Its scheduler is a real one. Provider calendars, recurring appointments, appointment categories mapped to encounter types, room and equipment as bookable resources, patient portal self-booking, reminders. It's tied to the patient record, so booking somebody creates or attaches to a chart rather than to a row in a bookings table.

The cost is that it's a full practice-management system and it looks and feels like one. The admin surface is enormous. The patient portal is functional rather than pleasant, and if your reason for wanting online booking was that your existing booking page looks dated, OpenEMR's portal is not going to feel like an upgrade to patients. Installing it is a weekend; configuring encounter types, fee schedules, providers, facilities and access control is not. Budget for someone who has done it before, and read the forums before you assume a feature works the way its checkbox implies.

**OpenMRS** is a different animal — MPL-2.0, Java, a modular platform built for public health and used at scale in hospitals across Africa and Asia. It ships as a platform plus modules rather than a finished product, and **Bahmni** is the distribution most people actually deploy, bundling OpenMRS with OpenELIS and Odoo into something a hospital can run. If you're a district hospital in a low-resource setting with a technical partner, this is the mature answer and it's not close. If you're four physios in Kraków, it's the wrong scale by an order of magnitude, and the implementation partner is not optional.

**Medplum** is the newer shape, and the interesting one for anyone who thinks in APIs rather than in installs. Apache-2.0, TypeScript, actively developed, FHIR-native. It isn't a clinic product you hand to a receptionist — it's a backend you build a clinic product on, with scheduling as FHIR `Schedule`, `Slot` and `Appointment` resources. If you're a health-tech team building your own patient-facing app and you want the data model to be standards-compliant from day one, start here rather than with a PHP monolith. If you have no engineering team, this is not a route.

**GNU Health** deserves a mention and a caveat. It's a genuine hospital information system with real deployments — ministries of health, teaching hospitals, listed publicly on their site — and it takes social medicine seriously in a way the others don't. It also lives outside GitHub, on the GNU infrastructure, which means the usual signals people use to judge project health don't apply and you'll have to evaluate it on its own mailing lists. Built on Tryton, Python, GPL.

## Path two: a generic scheduler in front of whatever you already run

If you're keeping your record system and you just want patients to be able to book online, two self-hosted schedulers come up constantly and both are legitimate.

**Easy!Appointments** — GPL-3.0, PHP, about 4,350 stars, still moving. Providers, services, working plans, a clean public booking page, Google Calendar sync. It's the most pleasant thing in this article to actually install, and for a solo practitioner who wants a booking page on their own server, it does the job in an afternoon.

**LibreBooking** — GPL-3.0, PHP, the maintained fork of the old Booked Scheduler. It's a resource scheduler at heart, so it'll handle rooms and equipment better than it handles clinicians, and it's overkill if patients are all you're booking. We've written separately about [what happened to Booked and where its users went](https://opencals.com/blog/booked-scheduler-alternatives).

The shared limitation is the one that matters: neither knows what a patient is. A booking is a name, an email and a service. It doesn't link to a chart, it doesn't carry an encounter type, it won't tell your clinician what happened last visit, and if you want it to, you're writing that integration. For a single-clinician practice where the "record system" is a filing cabinet, that's fine and I'd genuinely recommend Easy!Appointments. For anything with a real EHR behind it, you're building a bridge that will need maintaining forever.

## HospitalRun is the case worth reading before you commit

HospitalRun was an open-source hospital information system aimed at low-resource environments — offline-first, MIT licensed, 6,888 stars on GitHub. It's the sort of number that makes a project look safe in a procurement document.

It was archived in January 2023. No commits since.

I'm not saying this to be unkind about a project people put real work into; the goal was good and the reason it stopped is the ordinary one. I'm saying it because the star count is still there, the README still reads well, and it will still show up when you search. In healthcare specifically, adopting an abandoned system isn't a maintenance inconvenience — it's a patient-data system with no security patches and a migration nobody scoped.

> **Check this before anything else**
>
> Open the repository, sort by most recent commit, and look at the date. Then look at whether the commits are substantive or dependency bumps from a bot. Stars measure how many people once thought a project was a good idea. The commit log measures whether anyone will fix a vulnerability for you next year.

## Where the two paths diverge

|                                       | EHR with built-in scheduling                           | Generic self-hosted scheduler             |
| ------------------------------------- | ------------------------------------------------------ | ----------------------------------------- |
| Examples                              | OpenEMR, OpenMRS/Bahmni, Medplum, GNU Health           | Easy!Appointments, LibreBooking           |
| Booking links to a patient record     | Yes, that's the point                                  | No — name and email only                  |
| Time to something patients can use    | Weeks to months                                        | An afternoon to a week                    |
| Replaces your existing records system | Yes, and that's the real project                       | No                                        |
| Takes payment or deposits             | Billing modules exist; card payment usually needs work | Not really — plugins at best              |
| Who this suits                        | Clinics changing their records system anyway           | Solo practitioners and cash-pay practices |
| Who maintains it                      | You, or a paid implementation partner                  | You                                       |

The row I'd read first is the third one. Time-to-live is where most of these projects fail — not because the software doesn't work, but because a practice that wanted a booking page in March doesn't have a booking page in September and has gone back to the phone.

## Compliance is the part the licence doesn't give you

Self-hosting comes up in healthcare conversations as though it settles the compliance question. It doesn't. Running OpenEMR on your own server doesn't make you HIPAA compliant, and it doesn't make you GDPR compliant either — it makes you the party responsible for encryption at rest, access logging, backup, retention, breach notification and staff training. The software can support all of that. It doesn't do it for you, and there's no vendor to share the liability with.

That's a fair trade if you have the capability. It's a bad trade if the reason you chose self-hosted was to avoid a monthly fee, because the capability costs more than the fee.

And here's ours, plainly: [Opencals](https://opencals.com/industries/medical-and-health) is a booking and payments platform, not a clinical system. We don't store charts, we don't market ourselves as HIPAA compliant, and we haven't been certified as such. Clinics use us for the front end — patients pick a clinician, a location and a time, pay a deposit, get reminders, reschedule themselves — while the clinical record stays wherever it already lives. If your requirement is that appointments and charts sit in one certified system, we're not it. [Ask us first](https://opencals.com/contact) rather than assuming, and be ready for the answer to be no.

We're also not open source, and I'd rather say that than let the word do work it hasn't earned: the [booking website templates](https://opencals.com/open-source) are MIT and yours to fork, including [Clarity, a clinic booking front end in Next.js](https://opencals.com/blog/templates/clarity), but the platform behind them is a hosted API. If everything has to run on your metal, [the open-source survey](https://opencals.com/blog/open-source-booking-system) is a better starting point than this paragraph.

## Where I'd land

If you're changing your record system anyway, take OpenEMR and get the scheduler as part of the deal. It's the only project here that's both complete and demonstrably maintained, and paying an implementation partner for six weeks is cheaper than the alternative you'll build.

If your records are fine and the problem is that patients can't book online, don't touch your EHR. Put a booking layer in front of it — Easy!Appointments if you want it self-hosted and free and you can live without payments, a hosted platform if you need deposits, card payments, SMS reminders and someone else operating the queue. At [$0.99 per completed appointment](https://opencals.com/pricing) the arithmetic against a server plus your own hours is not close for most practices, but run it for your own volume rather than taking my word for it, because at high volume it flips.

What would change my mind on the first recommendation: if Medplum's ecosystem keeps growing at its current rate, the "build your own clinic app on a FHIR backend" route stops being engineering-team-only, and that's a better long-term shape than a PHP monolith. I don't think it's there yet for a four-person practice. Ask me again in a year.

- [Open-source booking systems in 2026](https://opencals.com/blog/open-source-booking-system): What is still open source after Cal.com closed, and what self-hosting costs.
- [Clarity: clinic booking template](https://opencals.com/blog/templates/clarity): A free Next.js clinic booking website, MIT licensed, on the Opencals API.
- [Open-source equipment booking systems](https://opencals.com/blog/open-source-equipment-booking-system): What self-hosted tools actually reserve gear, and where they stop.
- [Buchungssystem Open Source (Deutsch)](https://opencals.com/blog/buchungssystem-open-source): Die deutsche Fassung: was nach Cal.com an quelloffenen Buchungssystemen übrig ist.
- [Booked Scheduler alternatives](https://opencals.com/blog/booked-scheduler-alternatives): Booked is hosted-only now: LibreBooking, Easy!Appointments, MRBS and what migrating costs.

## Frequently asked questions

### Is there a genuinely free open-source patient scheduling system?

Yes — OpenEMR, OpenMRS, Easy!Appointments and LibreBooking are all free to download and use under GPL or MPL licences. Free to run is a different question. Hosting, TLS, backups, upgrades, security patching and the person who does all that are real costs, and in healthcare so is the compliance work that no licence covers. For a solo practitioner comfortable with a Linux server, free is close to true. For a clinic with staff, it usually isn't.

### Does OpenEMR include online patient self-booking?

It does, through the patient portal — patients can request or book appointments depending on how you configure it, and providers approve or manage them from the calendar. It works. It also looks like software built for clinicians rather than for patients, so if the reason you want online booking is that your current front door feels dated, look at the portal before you commit rather than after.

### Can I use a generic scheduler and connect it to my EHR later?

You can, and people do, but budget for it honestly. There's no standard integration between Easy!Appointments and an arbitrary EHR — you're writing and then maintaining a bridge, usually against whatever export or API your records system offers. If patient-record linkage is a requirement rather than a nice-to-have, choosing the EHR-native scheduler from the start is cheaper.

### Is self-hosting more HIPAA compliant than a hosted platform?

No. Self-hosting moves responsibility rather than removing it. HIPAA compliance depends on how a system is configured, secured, logged, backed up and operated, and on the agreements in place — not on where the server sits. Self-hosting means every one of those controls is yours to implement and evidence, with no vendor sharing liability. Whether that's better depends entirely on your capability.

### What should I check before adopting any of these projects?

The date of the last substantive commit, whether releases are still being cut, whether the issue tracker gets maintainer replies, and how a security report would reach someone. Then check that a migration path exists — can you export patient and appointment data in a format another system will read. HospitalRun had 6,888 stars and stopped in January 2023; popularity is not maintenance.

### Which is right for a single therapist or small private practice?

Almost never a full EHR. The implementation cost swamps the benefit at that size. Either self-host a simple scheduler if you're technical and don't need to take payment online, or use a hosted booking platform if you want deposits, card payments, reminders and reschedules to work without you operating anything. Keep clinical notes wherever they already are.