Security & Privacy

Protecting your patients' information

Health information is among the most private data a person has. The platform is built to guard it carefully, in plain and practical ways. Here is how, explained without the technical jargon.

How your information is kept safe

Only the right people get in

Every member of staff signs in with their own account, and each role only sees what they need for their job. The platform administration area is protected by an extra sign-in step for added safety.

A code from your phone, not just a password

Encryption protects the files on the disk. It does nothing about someone who has a member of staff's password — and that is the way these things actually go wrong. Two-step sign-in closes that gap, and it is now available to doctors and staff rather than the platform administrators alone.

Anyone can turn it on for themselves under Two-step sign-in on their profile.
A clinic administrator can make it compulsory for chosen roles under Settings › Privacy & Security. People affected are asked to set it up the next time they load a page — nobody is locked out mid-shift.
Everyone who enrols gets ten recovery codes, shown once. They are what gets you in when the phone is lost, broken or replaced. Print them and keep them somewhere other than the phone.
If someone loses both the phone and the codes, an administrator can clear their two-step sign-in and they set it up again. An administrator can never issue a working code for someone else's account — if they could, they would be that account's second factor.

Platform Admin sign-ins may reuse a completed two-step challenge for at most two hours, and only in the same browser and from the same resolved IP address. The trust cookie is signed, HTTP-only, and SameSite=Strict; a changed IP, an expired or missing cookie, signing out, or a new browser always requires a new code. See Platform Admin OTP trust.

Patient and company document uploads are inspected from their actual bytes, not the browser-provided file type. Only recognizable JPG, PNG, GIF, WEBP, HEIC, HEIF, and PDF files are stored; downloads are forced attachments with content sniffing disabled.

A large file uploaded to imaging, the health board or an appointment moves to the server in small pieces rather than one request, but chunking itself grants no trust: once the pieces are reassembled, the resulting file is sniffed from its first 64 KB and checked against the same type allowlist as any other upload. While a transfer is still in progress, the incomplete file is held under the clinic's own storage — outside the web root, reachable only by the clinic's own application, and never served to a browser. The token that lets a form claim an in-progress upload is honoured only for the tenant and the staff member who started it, and it is consumed the moment it is used, so it cannot be replayed. These partial files are removed automatically once an upload is abandoned, and are excluded from a clinic's data export.

Tenant Administrators can review and export the electronic prescription log. It is tenant-scoped and records append-only snapshots when prescriptions are issued, changed, or deleted; filters support operational date, doctor, status, and event review.

Every connection is encrypted (HTTPS)

All traffic is served over a secure, encrypted HTTPS connection. If someone ever reaches the site over an insecure link, their browser is shown a brief security notice and is automatically moved to the secure address.

Your patients' names are scrambled too, not just their medical details

Most systems encrypt the medical record and leave the name beside it. That is half a protection: a list of who attends your clinic is itself sensitive, and in some cases more so than what was written down.

On CareClinic, the details that say who a record is about are stored scrambled along with everything clinical — the name, email address, phone number, home address and date of birth. Someone who got hold of the raw files would find no readable list of your patients at all. Each clinic has its own keys, so one clinic's data can never be read with another's.

And it did not cost you anything to use. Your front desk still types three letters and finds the person. The list still sorts by surname. Reports still break down by sex and age group. None of that changed when the scrambling did — the work happens behind the scenes, on a short-lived working copy that lives in memory for a few minutes, is itself encrypted, and is never written to disk or included in any export.

Where the protection ends — stated plainly

A security claim is only worth what its limits are worth, so here are ours.

It protects the stored files. A stolen backup, a copy of the database, a discarded disk: unreadable.
It does not protect against a signed-in account. Someone using a valid login sees what that login allows. That is exactly what two-step sign-in is for — turn it on, and a stolen password stops being enough on its own.
Sex, civil status and year of birth are the deliberate exception. So your reports can still count patients by sex or age bracket, those are stored as a fixed code or, for the year, in the clear. Someone studying a stolen copy could work out what the codes mean. Everything else — including the full date of birth — cannot be worked out that way.

We would rather tell you exactly where the line is than let you assume it is somewhere it is not.

Clinics are kept apart

One clinic can never see another clinic's patients or records. That separation is built into the foundations of the system and checked constantly.

When a clinic links a patient to a company through the Employer & HMO Portal, that company sees only the patients the clinic has explicitly associated with it — and never the most sensitive free-text medical fields. The rest of each clinic's data stays fully separate, so a controlled, deliberate share never opens a door to anything else.

And you record why you may share. Linking a patient to an employer opens a real door, so the patient's own screen asks on what authority: the patient's consent (with the date they gave it), an obligation under employment law, treatment or insurance administration, a legal claim, or protection of life and health. Associations made before this existed show honestly as no basis recorded rather than being quietly relabelled as consent — the panel counts them for you.

A patient can take it back. If they withdraw consent, record it and the company stops being able to see them from that moment. Not a flag someone has to remember to act on: the portal itself refuses the read. The link stays on file, so you keep the history of what happened and when.

Sign-ins are guarded

Repeated failed sign-in attempts are slowed down and blocked, which helps stop outsiders from guessing their way in.

Accounts belong to a clinic role

An email address and a role assignment do not open the clinic system by themselves. The account must also be linked to an active doctor or staff profile in that clinic. This check applies when someone signs in and while their web or API session is used.

The clinic's first administrator is linked as a doctor and keeps both the admin and doctor roles. Add later administrators through Staff with the admin role. If an older account cannot sign in because its operational profile is missing, the system administrator can inspect it first, then run php bin/260808-tenant-membership.php --tenant=<uuid> --fix to repair a safe, role-based link.

Each account stays signed in on a single browser session and a single mobile session at once. If someone tries to sign in again while a session is already active, the new attempt is politely turned away — the existing session is kept rather than quietly taken over. That means an account can't be used in two places at the same time, and a forgotten session frees up on its own after a while, or the moment you sign out.

Activity is recorded — and the record resists being edited

Important actions are logged, so there is a trail of what happened and when. Private medical details are deliberately kept out of these logs.

Each entry is also cryptographically linked to the one before it. Changing an old entry, or deleting one, breaks the links that follow and shows up the next time the trail is checked. That matters because an audit trail is only worth what it is worth against someone with access — a log anyone could quietly edit proves nothing in the one situation you need it.

What this does and does not do. It makes tampering visible; it does not make it impossible. Someone with direct database access could rewrite the whole chain — which is why each period is separately sealed with a key kept outside the database, and why those seals can be exported and stored somewhere out of reach. We would rather describe the protection accurately than let it sound like more than it is.

And so is who merely looked

Most systems log what people changed. That misses the thing that goes wrong quietly — a staff member reading the record of a neighbour, an ex-partner or someone in the news. Changing nothing, it leaves no trace at all.

CareClinic records who opened a patient's record: the person, which part of the record, and when. Never what it said.

Each patient's page shows the recent history, and Settings › Record Access Log covers the whole clinic, filterable by patient name, staff member, kind of user, part of the record or date. The filtered list exports to Excel, which is what a written request from a patient or the Commission actually needs.
Each entry also carries the device it came from — an in-clinic browser session reads differently from the doctor mobile app — and the specific document where there was one.
Reads from an employer or HMO portal are recorded in your clinic's trail — you hold the record, so you can see who outside the clinic has looked.
Repeat visits within a short period count once, so the list reads as visits rather than page refreshes.
It is kept for two years and then removed, because a permanent record of who consulted whom becomes its own problem.

This is what you show a patient who asks who has seen their file, and what you check first when you have a suspicion instead of a certainty.

Alerts about a patient say nothing about the patient

Staff can ask to be notified when something happens to a patient they are following. What arrives says only what kind of thing happened — Charge recorded, Lab result validated — and carries a link. No name, no diagnosis, no figure, on the screen, on a phone lock screen, or in the stored alert.

That is deliberate. A notification travels further than the record it refers to: it sits in a list, it lights up a phone that someone else may be holding. Following a patient also grants nothing — the link opens the profile with the same permissions as always, and the visit is written to the access log like any other. Someone who cannot open a patient's file cannot ask to be told about it either.

Patient messaging is a choice each clinic makes and is off until switched on (Settings → Patient Messaging). A clinic that never turns it on exchanges no messages at all; one that turns it off keeps what was already written, as part of the patient record, but no new message can be sent by either side and the conversation is no longer shown.

Patient-message alerts follow a narrower rule. Clinic IMS may show a patient name and short preview in its three-message alert bar because the viewer has signed in and holds patients.view. Email and mobile push alerts contain neither. The message sender name and body stay encrypted in the database with the clinic's tenant key, and staff must open the authenticated thread to read the full text.

Printed documents can be checked

Every PDF the system produces carries a QR code beside the signature. Anyone holding the paper — an employer, a pharmacy, another clinic — can scan it to confirm your clinic really issued that document, instead of taking it on trust. The page they reach shows the patient's initials only and no medical information whatsoever, because a printed page can be dropped or passed on. A document issued in error can be revoked, after which scanning it says so.

A medical certificate can carry the clinical fields requested by the clinic's template, including vital signs, APE assessments and consultation findings. Notes and results require a separate selection: a lab result or imaging report is never on a certificate unless the clinician ticked it. Lab results must be validated and final or amended; imaging reports must be signed, final or amended, with no unreviewed amendment pending. The issuer also needs the corresponding viewing permission and enabled module. The verification page behind the QR code is unaffected by any of this: it shows initials and no clinical certificate content. A recipient holding the certificate itself can read the details the clinic included.

An appointment-linked certificate uses that visit's records. A standalone certificate can use the patient's latest intake, APE and consultation observations or recommendations, which may have different dates; consultation diagnosis and treatment require an appointment-linked medical record. Staff should check those dates and each selected record before sharing. Source changes do not update the saved certificate body, so a correction may require reissuance. Automatic page fitting changes the body-text size, not the clinic's choice of information to disclose.

Images are marked, and the original is kept back

A scan is not a row in a table. It is a picture of a person, and it identifies them whether or not a name is printed on it — so imaging is protected differently from the rest of the record.

Image files never sit in a public folder. Every one is served through your clinic's login, to someone whose role permits it. The viewer draws them to a canvas rather than handing the browser a plain image, so a scan is not one right-click from somebody's desktop.

Every copy anyone else sees — in the viewer, in the printed report, on the patient's own portal — carries your clinic's name, the patient's name and the study date across the picture. This does not make an image unsaveable, and we would rather say so than imply otherwise: anyone looking at a screen can photograph it. What the marking does is make an escaped copy traceable back to where it came from. The original, unmarked file is reachable only by the staff who take or read the studies.

A study reaches the patient only after a doctor has signed the read. Images that have been taken but not yet reported are deliberately not shown — an unread scan is not an answer, and showing one invites a conclusion nobody has drawn yet.

Emailing a result narrows what the link can reach

When staff send a result by email — a lab result, a prescription, an imaging report, a certificate, an APE form or a visit summary — the link that goes out opens that document alone: its label, its date, your clinic's name, and a Download button. Nothing else on the patient's record is reachable from it, whether the link goes to the patient or to a listed contact person such as a guardian. This applies uniformly now, including to the patient's own copy — staff never have to reason about which kind of link a given recipient is about to receive, because every emailed result works the same way. A patient's full portal access, where they can message the clinic and see everything on file, still reaches them through the ordinary booking and appointment emails; it is only a specific result sent this way that is narrowed to itself.

The PDF itself is never attached to the email, on purpose. The message says a result is ready and gives a link to it; it never states a value or a finding. A mistyped address then reaches a sign-in wall instead of a diagnosis, and nothing that already left the platform as an attachment can be recalled — a link can be revoked, an attachment cannot. Revoking a sent link withdraws access outright and cannot be undone by anyone short of sending it again; a link that has expired on its own, or been pulled back, offers the recipient a way to ask your clinic to send it again rather than reaching a dead end with no path forward.

Giving a patient their records — in one click

A patient asking for "my records" used to mean someone assembling a folder by hand. On the patient's page, Give patient a copy produces the whole record two ways:

A PDF — everything in one readable document: their details, consultations, prescriptions, released lab results, appointments, certificates issued and billing. Print it, email it, hand it over.
A data file — the same record in a form another clinic's system can import, which is what the law means by a "structured, commonly used" format.

Three things are deliberately kept back. Notes a clinician wrote for their own working use are not included — a record a doctor can't write candidly in is a worse record for the patient, and the export says plainly that this material exists and how to ask for it. Only laboratory results the lab has released appear; a preliminary number is a working figure, not a finding. And imaging files are not packaged into the export — they are far too large to sit inside a record download; the signed radiology report prints as its own PDF, and the images themselves are provided on request.

Both downloads are recorded in the record access log. A whole record leaving the building is a bigger event than a screen being opened, and it's the one you'd want to see if it ever went somewhere it shouldn't have.

If your clinic sends secure portal links, patients can see all of this themselves and download either form without asking anyone — see the patient portal.

Your clinic's own privacy contact

Your clinic holds its patients' records, so your clinic — not us — answers for what happens to them. Under Settings › Data Protection Officer you name the person patients should contact about their own data, and it appears on your clinic's page in the public directory.

Use a role address that outlives one employee. A name with no email and no phone isn't a contact anyone can use, and the screen will tell you so rather than showing a tick over an unreachable person.

When someone asks about their own record

A patient can ask to see what you hold, to have something corrected, to object to how it is used, or to have it removed. Your clinic is the controller, so the answer is yours to give — and the law gives you 15 working days to give it.

Settings › Data requests is where that lives. Log the request the day it arrives; the deadline counts working days from when you received it, not from when you got round to writing it down, so a request that sat in an inbox for a week shows as a week gone rather than a week saved. Holidays are not counted, so treat the date shown as the date to answer by rather than the last lawful one.

Requests to see, correct, take away or remove a record cannot be marked answered until you have recorded that you checked who was asking. Handing a medical record to the wrong person is the mistake this step exists to prevent — and an heir or representative acting for someone is recorded as such.
Marking one answered asks what you actually did. Refusing asks the ground. Neither is a bare tick, because "handled" with nothing behind it is what a complaint is built on.
A request to delete hands off to the existing deletion workflow — same review, same archive, same 30-day undo — and the entry keeps the link, so "what happened to that request" is one click.
Anything still open and past its date shows at the top of the screen, in red.

Deleting records, and what survives it

Nothing on the platform can be erased on impulse. Deletion is a reviewed request: someone asks, someone else approves, and even then the records are only hidden at first.

The three stages

Approved — the records disappear from the system straight away. Nothing is destroyed.
For the next 30 days — the deletion can still be undone. This window exists because deletions raised in error are a real risk, and catching one is worth more than deleting quickly.
After 30 days — a scheduled job permanently removes the information. There is no undo past this point.

Before anything is hidden, an archive of the records is prepared automatically, so the clinic has a copy of what it held.

What is kept on purpose

Billing history. A deleted patient's charges, payments and receipts stay in the accounts, but the patient becomes "Deleted patient #4" — the clinic's books still balance and the entries no longer identify anyone.
Authorship of clinical records. Closing a doctor's or staff member's account destroys their sign-in but keeps their name on the prescriptions, certificates and notes they issued. Those are medical records; a document nobody appears to have signed is worse for the patient.

Safety rails

The system refuses a deletion that would cause a worse problem, and says why:

A patient with an unpaid balance cannot be deleted until it is settled or written off — otherwise the clinic is left with a debt against a record nobody can identify.
A clinic's last active administrator cannot be deleted, or nobody would be able to manage the clinic or let anyone back in.

What this means for you

Clinics can reassure patients that their information is handled responsibly.
Doctors and staff can work knowing the system is watching their back.
Patients can trust that their records are private, protected, seen only by those caring for them — and that they can ask for them to be removed.

Security is never "finished." The platform is maintained and updated over time so protections keep pace with new risks.