Security brief

For hospital administrators and IT · 1 September 2026 · Not a certificate pack

Healthcare buyers are trained to distrust badges. This page lists controls that exist in the product today, and states plainly what we have not claimed.

We do not display ISO, SOC 2, HIPAA or DPDP certification marks. If a later audit is completed, this page will name the standard and the date. Until then, evaluate the controls below.

1. Tenant isolation

Every hospital is a separate tenant. Patient lists, doctor rosters and tokens are scoped to that hospital. Isolation is enforced with PostgreSQL Row Level Security so a query cannot casually read another hospital’s rows even if application code is sloppy.

2. Role separation

Four surfaces exist: reception, doctor, patient, manager. A receptionist does not get manager history by opening a different URL. A patient sees their token and wait, not the full roster.

3. Staff authentication

Reception and doctor access use a hospital PIN verified on the server. PINs can be reset by the manager. Do not treat a PIN as a replacement for physical control of the reception PC.

4. Transport encryption

The application is served over HTTPS. Credentials and queue updates leave the browser only on that channel.

5. What we store

Operational queue data: hospital identity, staff access material, doctors, token numbers, status changes, timestamps, and the patient fields reception enters to issue a token. We do not need full EMR charts to run a queue, and we do not ask for them to start.

6. What a pilot hospital should still ask

Where is the database region, and is that acceptable for your policy?
Who on our side holds the manager PIN?
What is the export / deletion path if we stop?
Do we need a written processing addendum before live patients are entered?

Those answers belong on a demo call, in writing, for your file — not as a badge on a homepage.

Contact for IT review

hello@smarthospitalqueue.com · Subject line: “Security review — [hospital name]”