Security
Every row in this system is a real person’s data.
This page says exactly what happens to your patients’ data — in words you can check, not slogans.
Clinic data kept apart — one clinic from another
Each clinic’s data is kept apart from every other clinic’s in the query itself. It isn’t a rule in a guidelines document that someone could forget while adding a new screen: every read from the database is built so that it must know the clinic, and if the clinic isn’t known it refuses to run at all.
So a session working in one clinic doesn’t reach another clinic’s records, even if someone tries a record number that isn’t theirs. The only exception isn’t one clinic seeing another — it’s the platform operator’s access itself, described in detail below.
The platform operator’s access
The company that runs NoriClinic has an admin panel entirely separate from any clinic’s — a different sign-in, a different accounts table, and no code path linking the two. Through it we can see the de-identified clinical research data your clinic built — the same data you see on the “Clinical research” page, not the patient’s medical record, name or phone number.
Every time someone at the company opens or exports your clinic’s research data, it’s recorded in your clinic’s own audit log — not just ours — with who did it and exactly when. You can see it from the Settings page at any time.
Identifiable data — the patient’s name, phone number, record number — isn’t available from the company’s panel at all, under the same separate permission you control for identifiable exports inside your clinic.
Who sees what
Four roles, each seeing what its work needs. On top of them, the admin can grant or block a permission for one named person without changing their role.
| Role | Sees |
|---|---|
| Clinic owner | The day board, the medical record, and the month strip. |
| Physician | The day board, patient records, prescriptions and follow-ups. |
| Reception | The day and its flow only — not the medical record, not the analytics. |
| Staff | The minimum, plus named permissions if the admin chooses. |
Blocking here isn’t hiding from the menu. If someone opens the link to a page they aren’t allowed to see, the request is refused before it reaches the data at all.
What we can say exactly
- Isolation between clinics. Each clinic’s data is kept apart at the query; one clinic’s session doesn’t reach another clinic’s records — without exception.
- The platform operator’s access. One exception only, entirely separate from clinic accounts: de-identified clinical research, recorded in your own clinic’s audit log.
- Permissions inside the clinic. Access by role, with named exceptions the admin controls.
- The connection. All traffic runs over encrypted HTTPS, and browsers are told to always use it.
- Passwords. Stored hashed with bcrypt — not stored as text, and they can’t be turned back.
- Requests. Every request that changes something is protected against cross-site request forgery (CSRF).
- The log. Actions are recorded in an audit log.
And what we won’t say
Some things get written on pages like this that either mean nothing or mean a certificate someone else issued. You won’t find here:
- “HIPAA compliant” or “GDPR compliant”
- “Military-grade encryption” or “bank-level security”
- “Unhackable”
- Certifications or security audits that haven’t happened
If the system passes a real audit or earns a real certification one day, you’ll find its name and date here. Until then, blank is more honest.
What’s needed from you
The weakest point in any medical system isn’t the code — it’s the accounts. Two things really make a difference:
- Everyone on their own account. One account shared by the whole front desk means the audit log can’t tell you who did what.
- Close the account of anyone who leaves. From Settings, the same day.
Want to try it on your clinic?
Accounts are opened one at a time. Leave your details and we’ll get back to you to set the clinic up with you.