Security
Every gate exists at least twice.
Medical software earns trust by what it refuses, not by what it promises. This page describes the mechanisms — including the ones that are not there.
Three layers, asking the same questions
A single check is a single point of failure. Each of these can enforce the rule alone, so a mistake in one does not open the door.
In the database
Every table carries row-level policies that scope its rows to the practice that owns them. A query for another practice’s patients returns nothing — not an error page, nothing. The app cannot opt out of this, because it is not the app applying it.
In the stored procedures
Privileged operations run with elevated rights, so each one re-checks who is calling it before doing anything. Being allowed to call a procedure is not the same as being allowed to have its result.
On the server
The functions behind video, payments and messaging independently verify the session, membership of the relevant practice, and the plan entitlement — even though the app has already checked. Especially because it has.
Specifics
Client-side checks are treated as hints
The code that hides a feature you are not entitled to says so in its own documentation. The control is on the server; the hidden button is only a courtesy.
Reports are never publicly addressable
Patient reports and prescriptions live in private storage and are reached only through short-lived signed links. There is no permanent URL to leak, guess or forward.
Cross-practice access is closed twice
Holding a doctor account does not let you into another practice’s consultation or raise a charge against their patient — active membership of that practice is required, and a refused request looks identical to one for something that does not exist.
Google sign-in only
There is no password to steal, reuse or phish, because Shifora does not have any. Sign-in is Google, on the web and in the Android app.
Verification codes are handled properly
Booking codes are stored hashed, expire in ten minutes, allow five attempts, and are rate-limited per number, per IP and by a resend cooldown.
An audit trail, and a delivery log
Administrative actions and appointment status changes are recorded, and every message sent is logged per channel with its outcome — so a practice can show what happened rather than assert it.
Storage is bounded per practice
The plan’s storage limit is enforced when a file is written, not counted up afterwards.
Sending on your behalf is constrained
A patient account cannot use the platform’s verified sending domain to email an arbitrary address. Recipients are restricted to themselves and their doctor.
Incoming webhooks are authenticated
Payment and messaging callbacks are verified by signature or key and, for payments, re-checked directly with the provider before anything is marked paid.
What we do not claim
A security page that only lists strengths is not a security page.
- Shifora holds no security or privacy certification, and this page makes no compliance claim.
- Shifora staff can access practice data in order to operate and support the platform. Administrative actions are recorded in an audit log.
- Data is processed and stored outside Bangladesh, on the managed cloud infrastructure Shifora runs on.
- Video consultations are not recorded. The text transcript of a consultation is stored with the appointment.
- There is no self-serve export of all of a practice’s data. Ask us and we will help.
Questions we have not answered here?
If you are evaluating Shifora for a clinic and need detail this page does not cover, ask us directly.