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

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.

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.

Where the two paths diverge

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 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 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 are MIT and yours to fork, including Clarity, a clinic booking front end in Next.js, but the platform behind them is a hosted API. If everything has to run on your metal, the open-source survey 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 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.