Orla vs Cliniko

Two things should be said before anything else, because a comparison page that does not say them is selling rather than informing.

Cliniko is a good product. It has been running clinics for well over a decade, it is stable, its support is well regarded, and thousands of practices use it happily. If it is working for you, "it is working" is a perfectly good reason to stay.

Orla is not finished. It is in build, it is recruiting build partners, and some of what the feature pages describe shipped last month rather than last decade. A ten-year-old product will do things a one-year-old product does not.

With that said, here is where the two are actually different — and, more usefully, how to check any of it yourself.

Where Orla is different by design

The waitlist acts on its own

This is the difference clinics notice first. In most systems a waitlist is a list: a cancellation appears, and somebody has to notice it, open the list and start ringing. In Orla, a cancellation triggers an offer to every waiting patient who genuinely matches the freed slot — right service, right practitioner, right room — all at once, with an expiry, and the first to tap takes it. The rest are told plainly that it went.

The whole mechanism is written up on waitlist auto-fill, including what it refuses to do.

Consent is enforced in the code, not promised in a policy

Every message Orla sends passes a guard that checks the consent its template requires. A marketing consent is not a transactional consent, and a send without the right one is refused and the refusal recorded on the patient's thread. It is not a setting somebody can quietly turn off, and it is not an instruction in a manual — it is the send path itself.

That matters most to whoever in your practice would have to answer a supervisory authority. Consent and messaging sets out how it works.

Separation between clinics is a database policy

Orla enforces per-clinic isolation with PostgreSQL row-level security, applied underneath every query, and the account the application connects as cannot bypass it. The practical difference from filtering in application code is that a new table cannot ship unprotected by somebody forgetting to add a WHERE clause.

The patient record page describes what that covers.

Reads are journalled, not only writes

Orla records who looked at a record, not just who changed it, in a log the application role has had UPDATE and DELETE revoked on. Most systems can tell you who edited a note. Fewer can tell you who read one, which is the question that actually gets asked after an incident.

Built for how Irish clinics bill

Dates read dd.mm.yyyy everywhere. Invoices carry the practitioner and CORU number a patient needs to claim health expenses. The clinic's timezone, not the viewer's, decides what "today" means — including across daylight saving, in both directions. None of this is exotic; it is just built in rather than worked around.

What to check before you move — including on us

Do not take a vendor's comparison page as evidence, this one included. These are the questions worth putting to any practice management system, and the answers are checkable:

• Can you leave? Ask for a full export, in a format you can read, with no exit fee. Ask what happens to it if you stop paying. Orla's answer is on this page.
• Where does patient data live, and under whose control? Special category data outside the EU makes the clinic the controller who has to justify the transfer.
• Who can see a record, and can you prove it afterwards? Ask specifically whether reads are logged, not just edits.
• What does a migration actually involve? Ask for the import to run as a dry run first, with counts on both sides.
• How long has it been running, and who else runs it? This is the one where Cliniko has the better answer and Orla does not pretend otherwise.

Moving, if you decide to

Cliniko exports CSV. Orla reads it directly: patients, appointments, notes, documents and balances, with duplicate detection and a checked count on both sides. The import runs as a dry run before it writes anything, and you run a parallel week with your old system still live before you switch.

The step-by-step is in moving from Cliniko, Zanda or Pabau.

When Cliniko is the better choice

Plainly, because you will find this out anyway:

• You need it to be proven today. Cliniko has a decade of production behind it. Orla has a roadmap and a small number of build-partner clinics.
• You are outside Ireland and the EU. Orla's Irish and EU specifics — CORU numbers, health-expenses receipts, EU-only hosting — are the point of it. Elsewhere they are dead weight.
• You depend on a particular integration. Cliniko's ecosystem is larger. Ask us about a specific one rather than assuming either way.
• You want to buy and go. Orla is currently taking build partners, which means weekly calls and telling us when something is wrong. That is a real commitment, and it is not for everyone.

If you would rather shape a system than adopt one, that is what we are asking for.