Security & Data Protection

QueueCare moves a queue. It is not a medical record, and the things a medical record holds never enter it:

• No lab results.
• No medical reports.
• No scans or imaging files.
• No diagnosis.
• No prescriptions.

What we hold is what a queue needs: who is waiting, for which doctor, when they arrived and when they left, and what was paid at the desk.

Notes your staff write

Reception and doctors can leave a short note on a patient — the kind that shows on the board. It is free text, so what your team writes is what we store, and it travels with the alert to a doctor who has linked Telegram.

Four companies hold or run the service itself, and each publishes its own security page. We link them so you can read their claims from them, not from us. Section 5 of the Privacy Policy names everyone else we work with.

• 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 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 agreement on request, and AES-256 at rest.
• Railway: SOC 2 Type 2 and SOC 3, GDPR, HIPAA, and encryption at rest.
• Clerk: SOC 2 Type 2 since 2022, HIPAA on its enterprise plan, and self-certification under the EU–US Data Privacy Framework.

Convex, Railway and Clerk will all sign HIPAA arrangements. Compliance itself belongs to your centre and your contracts. The layer underneath is not what stands 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.

There is a practical reason too. A patient's row is also a line in your day's books: the payment, who took it, at what time. Erasing rows on a schedule would erase your own accounts with them.

So the timed erasure that exists in the code is switched on for nobody. What we offer instead is simpler, both from Settings → Access & Security. Export everything whenever you like, ready the same day. Or delete all of it: that opens a seven-day window you can cancel in.

One detail worth knowing: a backup taken before a deletion keeps a copy for up to seven days, 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: AES-256. 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, not 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.

What keeps it that way is not memory. A dedicated set of isolation tests runs on every single change, and two automated checks fail the build outright if the pattern is ever broken.

• 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, 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. Nothing in the product can edit a line of it or delete one: there is no such function in the code. It is kept for twelve months.

Twenty-five kinds of event are recorded, from a fixed list: workstation sign-ins and sign-outs, sessions revoked, staff invited and removed, policy changes, exports and deletions. Every time our own team is granted access, loses it, or uses it is in there too.

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.

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

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. We have not needed to run one against live data.

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 what a deletion would remove. The two are one list in the code, and a test keeps them together. It carries a count per table so you can check it against itself, and stays available for seven days.

Deletion

On the same screen, directly below the export — export first, then delete. 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 every table that holds it, and the centre's own record with it.

One record is kept on purpose: the audit log, because it is the only proof the deletion happened. It holds no patient name and no 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. Like the rest of the log, it is 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. 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. One click closes it, and the click is theirs.

Either way you can see it. Every grant, every withdrawal and every time we look goes to your own audit log, under its own kind of entry.

There is an emergency route: our administrator account can grant itself access during an incident. It is written to your log as its own kind of entry, so a decision of yours and an entry of ours are never the same line. The agreement we sign with you sets it out in full.

Section 5 of the Privacy Policy lists every company we work with and what each one receives. If your reviewer wants more, ask: the data processing agreement, the exact fields we store, the incident response plan, the restore procedure. And if anything here does not match what you find, tell us.

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.