The patient record

One record per patient, from first enquiry to discharge and back again. No second system for notes, no shared drive for referral letters, no spreadsheet of who still owes for June.

What is in it

• Timeline — every appointment, message, form, invoice and note, in order, so the question "what actually happened with this patient" has one answer.
• Clinical notes — structured or free, versioned, with an audit trail.
• Care plans — the course of treatment, sessions used and sessions left, so a plan that has quietly lapsed is visible instead of forgotten.
• Documents — referrals, imaging reports, letters, shareable to the patient's portal when the clinician chooses.
• Consents — what the patient agreed to, when, and on the wording in force at the time.
• Balance — what is outstanding, and against which invoice.

Isolation is enforced by the database, not by the code

This is the part worth being specific about, because "multi-tenant" is a word every practice management system uses and almost none of them explain.

Orla's application connects to Postgres as a non-superuser role that cannot bypass row-level security. Every table carrying a clinic identifier has an isolation policy attached, and those policies are derived from the database catalogue rather than a hand-written list — so a new table cannot ship unprotected by somebody forgetting to add it. A query that "forgets" to filter by clinic returns nothing rather than returning somebody else's patients.

A foreign key is not a tenancy check. A WHERE clause written by a careful developer is not a tenancy check either, because it depends on every developer being careful every time. A policy the database applies underneath the query is a tenancy check.

Reads are journalled, not only writes

Most systems can tell you who changed a record. The question that matters under GDPR is usually who looked at one.

Orla writes to an append-only journal, and viewing a patient record is one of the things it records. Append-only is enforced in the database: the application role has had UPDATE and DELETE on that table revoked, and triggers refuse the mutation and the truncation even if something tried. The clinic can show what was done and by whom; nobody, including us, can quietly tidy the history afterwards.

Each entry records who acted, whether they were a person, the system, an automation or the API, what they did, which record it concerned, and when.

Who can see what

Role gates live on the server, on the procedure that fetches the data — not in the navigation. Hiding a menu item is a design decision; refusing the request is a security control, and only the second one survives somebody typing the URL.

The front desk sees the diary, the patients and the money. Clinical notes require a clinical role. Owner-level settings require an owner. A receptionist who navigates to a clinical note is refused by the server, and the refusal is the same whether they guessed the URL or found a stale link.

Times and dates behave

Every time in the record renders in the clinic's timezone, never the viewer's, so a practitioner checking the diary from abroad sees the clinic's day rather than their own. Dates render day-first — 04.09.2026 — because that is how they are read in Ireland, and a date format that flips between screens is a clinical risk rather than a style preference.

What the patient sees

The same record, filtered to their half of it, in the patient portal: their appointments, the documents the clinic shared, their invoices, the forms they still need to fill in, and their own contact and insurance details, which they can correct themselves.

What they can edit is a fixed list — contact details, address, insurer, GP, emergency contact. Their name and date of birth are not on it, because those are the identity the chart is filed under, and a record that can be renamed from outside the clinic is not a chart.