Security & Data Protection

QueueCare was built to move a queue, not to hold a medical record. That shapes everything below, so it is worth starting with what never enters our systems at all:

• No lab results.
• No medical reports.
• No imaging files, and no DICOM.
• No diagnosis.
• No prescriptions.

What we do hold is what a queue needs: the patient's name and phone, file number, gender and age band, queue number and visit times, the payment method, amount and insurer, the procedure description and attending doctor, and the names and numbers of anyone with them.

Two of those are clinical — the procedure description and the requested scan type — and we say so rather than let anyone find it later. They are the only clinical fields we define, and the product is built to stay on this side of that line.

Notes your staff write

Reception and doctors can leave a short note on a patient — the ones that appear on the board. That is free text, so what your staff write is what we store, and it travels with the alert to a doctor who has linked Telegram. No centre is using notes today. We mention it because it is the one place where what we hold is up to your team rather than to us.

An older table, still in the database

There is a permanent patient file in the schema — a four-part name, date of birth, city and district, workplace and occupation — left from an earlier build. Nothing in the product writes to it or opens it, and it holds seventeen rows in total. Your technical reviewer will find it when they read the schema, and we would rather they hear it from us first.

Four companies hold or handle part of the service. Each publishes its own security page, and we link them so you can read their claims from them rather than from us.

• Convex — the database: your patient rows, the queue and the day's ledger. Runs on AWS.
• Railway — the application: Google Cloud us-east4, in Ashburn, Virginia.
• Clerk — staff sign-in: the email addresses and passwords your staff sign in with, hosted in the United States. No patient data reaches it.
• Azure AI Speech — the spoken call: Microsoft's uaenorth region, in the United Arab Emirates. It receives the announcement your waiting-room screen is about to say.

What they certify

• Convex: SOC 2 Type II, GDPR, a HIPAA business associate agreement on request, and 256-bit AES encryption at rest.
• Railway: SOC 2 Type 2 and SOC 3, GDPR, HIPAA, and encryption at rest.
• Clerk: SOC 2 Type 2 since 2022, HIPAA with a business associate agreement on its enterprise plan, and self-certification under the EU–US Data Privacy Framework.

Convex, Railway and Clerk will all sign HIPAA arrangements. That does not make QueueCare HIPAA compliant — compliance belongs to your system and your contracts — but it means the layer underneath is not the thing standing in your way, which is what a serious centre is really asking.

Your records stay for as long as you want them. We do not delete a centre's data on a timer, and we would rather you decided than have the system decide for you.

The reason is practical. A patient row is also a line in your day's ledger — the payment, who took it, at what time — and seven other tables point at it: cash vouchers, ledger edits, imaging orders, Telegram messages, chat, notes and desk-sync. Erasing the row erases your own books with it.

So the timed erasure that exists in the code is switched on for nobody, and we do not offer to switch it on. What we offer instead is better: you can export everything whenever you like, and you can have all of it deleted, both from Settings → Access & Security, and both take effect the same day you ask.

One honest detail: a backup taken before a deletion keeps a copy for up to seven days from the day it was made, then expires by itself.

• In transit: TLS on every connection, with HSTS, so a browser will not fall back to an unencrypted one.
• At rest: 256-bit AES. Convex publishes this on its security page, and Railway states encryption at rest in its trust centre.

Both links are above, so you can read those two claims from the companies that make them.

This is the one that matters most, and it is settled on the server rather than in the browser: every query is scoped to your centre's id, taken from the session of whoever is asking. Nothing the client sends can widen it.

We reviewed the whole public surface and closed every isolation gap we found. What keeps it closed is not memory: a dedicated isolation test suite runs on every single change, and two automated checks fail the build outright if the pattern ever comes back. We keep reviewing as the product grows, and those tests hold the line in between.

• Your staff sign in through Clerk, each with their own account.
• Four roles — centre administrator, doctor, reception and workstation — each with the least it needs.
• Passwords are hashed with bcrypt at cost 10, salted from a secure random generator, with an eight-character minimum.
• The shared centre-password door allows ten attempts an hour and no more.
• You can revoke every session in your centre in one action.

Two-factor sign-in is not part of the product today. When it is, it will be on this page.

Your centre has its own log, and nothing in the product can edit a line of it or delete one — there is no such function in the code to call. Twenty-five kinds of event are recorded, from a fixed list rather than free text: workstation sign-ins and sign-outs, sessions revoked, staff invited and removed, policy changes, rooms and screens and floors deleted, exports requested and completed, deletion requested, cancelled or carried out — and every time our own team is granted access, has it withdrawn, or uses it. It is kept for twelve months.

Which sign-ins appear there

The centre-password door — including attempts that failed, and why — and every workstation. Your administrator's own account sign-in is kept by Clerk, whose record of it is separate from your log.

What it deliberately does not record

The day's queue on a reception screen. A board left open re-runs its query dozens of times an hour with nobody touching it, and recording that would bury the decisions that matter under millions of non-events. What the log holds instead is the session: who signed in, at which station, and when.

Opening one named patient's file is wired to be recorded — who, when, which file, and refused attempts too — with no patient name and no search text in the log itself, only a count. Nothing in the product opens that file today, so there is nothing to record yet. It is there for when there is.

Backups are taken by hand and live for seven days. The first one for production took ten seconds and included stored files.

We have rehearsed a full restore end to end on an isolated copy and written the procedure from what it taught us — that the order of the steps matters, and that scheduled jobs will start working on restored data before a human has checked it. Both are in the runbook now. We have not needed to run one against live data.

The plan is written and the first notification is already drafted, because nobody writes a good disclosure in the middle of a crisis. Six steps: detection, containment, assessment, notification, correction, documentation.

We tell you within 24 hours of knowing — tighter than the 72 hours common elsewhere, and written into the agreement we sign with your centre.

We also keep an incident log, with dates, exact durations and what each one taught us, including outages we caused ourselves. It holds six entries. A register with only disasters in it teaches nothing, and an empty one usually means nobody is writing.

Three companies receive a patient's name in the course of doing their job, and we name them here so nothing about it is a surprise later. The full list of everyone we work with is in section 5 of the Privacy Policy.

• Telegram: the patient's name in a doctor's alert, and the note text if your staff have written one.
• Azure AI Speech: the name, to say it out loud in the waiting room.
• OneSignal: the name inside a push notification to your staff's devices.

Telegram and OneSignal can both be switched off by your centre. And what the waiting-room screen says — which is also what gets spoken — is yours to shorten in Settings → Access & Security: the full name, the first name with a family initial, or the queue number on its own.

And one that receives no patient data

OpenAI helps us tidy the map. It receives the distinct area names your reception types — the many spellings of one neighbourhood — as bare strings, so they can be collapsed onto a single region. No name, no file number, no count and no date goes with them, and no patient record. We name it anyway, because an AI provider that touches nothing is still one you should know about.

The data you put into QueueCare belongs to your centre. The Terms of Service say so explicitly: we claim no ownership of it, and we do not use it for anything but running the service for you.

Export

One click in Settings → Access & Security produces a complete JSON copy, covering exactly the tables a deletion would remove — the two are one list in the code, and a test keeps them from drifting apart. It carries a count per table so you can check it against itself, names anything not included and why, and stays available for seven days.

Deletion

On the same screen, directly below the export — export first, then delete, which is the order both the page and the agreement read in. You type your centre's name to confirm, and a seven-day window opens with its date shown and a cancel button beside it. After that your data is removed from forty tables and the centre's own row: the permanent patient file, imaging orders, appointments, cash vouchers, notes, chat attachments, and the floors of a multi-floor centre.

One record is kept on purpose: the audit log, because it is the only proof the deletion happened. It holds no patient name or file number — there is no field for either. The one piece of free text in it is the reason you type when you make the request, so it is worth writing that line the way you would want it kept for twelve months.

Whether anyone at QueueCare can open your centre's data is a setting in your own dashboard, under Settings → Access & Security, and it takes effect the moment you change it.

• Centres joining now start closed. We cannot read your data unless your administrator grants it.
• Centres that joined before 13 September 2026 start open — the support arrangement they already had, which we did not change on their behalf, because quietly cutting support from a working centre is not ours to do. One click closes it, and the click is theirs.

Either way you can see it: every grant, every withdrawal and every single time we look is written to your own audit log under its own kind of entry, and you can read them all.

There is an emergency route — our administrator account can grant itself access during an incident — and it is written to your log as its own distinct kind of entry, so a decision you made and an entry we made are never the same line. It is a control over everyday access rather than a cryptographic barrier, which is true of any such control inside any application, and the agreement we sign with you sets it out in full.

If your technical reviewer wants the data processing agreement, the sub-processor list, the incident response plan or the restore procedure, ask and we will send them. And if anything on this page does not match what you find, tell us — we would far rather hear it from you than let it stand.

This page describes how the service works today, in plain words. What binds us is the Terms of Service, and the data processing agreement we sign with your centre.