Security & data handling
How ClinicArchitect handles patient data
Clinics are asked to put identifying patient information into this system, so the controls behind it should be stated plainly rather than summarised as “bank-grade security”. This page describes the specific mechanisms, and is explicit about what is not claimed.
Last reviewed
Is patient data encrypted?
Yes. Identifying patient fields — name, phone, email, address and passport details — are encrypted with AES-256-GCM before they are written to the database. The plaintext is never stored in those columns.
AES-256-GCM is an authenticated cipher, so a stored value that has been tampered with fails to decrypt rather than returning altered data. The encryption key is held in the application environment, separately from the database.
Searching encrypted fields is the usual trade-off in this design, and it is solved without weakening the encryption: patient name search runs against a separate column holding a normalised form of the name — lowercased with diacritics stripped — indexed for full-text search. Search therefore never needs to decrypt a record, and the encrypted columns are never queried by content.
Can one clinic see another clinic's patients?
No. Every clinic-scoped request must present a clinic identifier, and the server independently resolves the caller's membership and role in that clinic before returning any data.
The clinic identifier on a request is never trusted on its own. The server confirms the clinic exists and is active, then looks up the caller’s membership record and role for that specific clinic. A caller with no membership gets no data, regardless of what identifier they send. A user account also belongs to one clinic at a time, enforced at the invitation, join-request and clinic-creation endpoints alike.
How is staff access controlled?
Each role carries a permission matrix over 14 areas of the product, and an individual staff member can hold an override on top of their role. Permission is checked on the server for every request, not in the interface.
The 14 controlled areas are:
- Patients, appointments and visits
- Pre-operative and post-operative assessments
- Staff and roles
- Clinic settings and billing
- Files, hotel bookings and flight tickets
- Custom fields and the dashboard
Overrides merge on top of the role, with the override winning, so one nurse can be granted access to post-operative notes without changing the nurse role for everyone. Hiding a button in the interface is not the control — the server rejects the request.
What stops two staff members double-booking the same slot?
A database-level advisory lock keyed on the doctor and the appointment's start minute. It is taken before the overlap check and released after the insert, so the check and the write cannot be interleaved by a second request.
This is a correctness guarantee rather than a UI convenience. Two receptionists pressing save at the same moment for the same doctor and time produce one appointment and one rejection, not two overlapping appointments — which a check-then-insert without a lock would allow. The guide to preventing double booking walks through the race condition step by step.
Is there a record of who did what?
Yes. Each clinic has its own audit log, viewable by staff whose role grants it, recording actions taken within that clinic.
Clinics also nominate which roles receive push notifications for specific events — patient created, appointment created, appointment updated and visit created — so changes surface to the people accountable for them rather than only appearing in a log.
What is deliberately not claimed here?
ClinicArchitect does not claim a HIPAA, ISO 27001 or SOC 2 certification, and does not publish an uptime guarantee. No figure appears on this site that is not verifiable.
A certification is a third-party attestation with a certificate behind it. Where ClinicArchitect does not hold one, it says so rather than implying compliance through language like “HIPAA-ready”. Clinics with a regulatory obligation of their own should read the privacy policy and raise a data processing agreement with legal@clinicarchitect.app before putting patient data into any system, including this one. The patient data security checklist lists the questions to put to any vendor.
| Patient field encryption | AES-256-GCM, application layer, before database write |
|---|---|
| Searchable name column | Normalised, diacritics stripped, no plaintext name stored |
| Tenant isolation | Server-side membership and role resolution per request |
| Permission model | Role matrix over 14 areas + per-member override |
| Booking concurrency | Database advisory lock on doctor + start minute |
| Audit | Per-clinic audit log, role-gated |
| Transport | HTTPS only |
| Backups | Monthly on Premium; weekly database and file backups on Pro |
| Certifications held | None claimed |
| Uptime guarantee | None offered |
| Data controller | Caymaz TechHealth Yazilim Tic. Ltd. Sti. |
How do I report a security issue?
Email legal@clinicarchitect.app with the details. Reports about personal data handling can go to legal@clinicarchitect.app.
Please include the affected endpoint or screen and the steps to reproduce. There is no paid bounty programme.