Members and account security
Sessions, idle sign-out, and what happens the moment access is revoked.
Sign-in is per person. Sessions are carried in a signed, HTTP-only cookie, and a long idle period signs you out — a panel left open on a front desk is a real risk, not a theoretical one.
Revoking access
Removing a member takes effect at the database, not just in the interface. Their role is carried as a signed claim that the access rules check on every read and write, so revoking it stops an open tab as well as a fresh login — and stops file downloads as well as page loads.
Keeping credentials secure and removing people who leave are your responsibility under the Terms. We can make it a single click; we cannot notice that someone left.
Passwords
Each person sets their own and can reset it from the sign-in page. The strength meter names the rule that is not met rather than saying "weak", because "weak" is not an instruction.
A short list worth actually doing
- One account per person. No shared front-desk login — it is a role you cannot narrow and a log you cannot read.
- Review the member list quarterly. Locums, students and the person who left in March.
- Give the export permission deliberately, not as part of a default.
- Keep the roles module with the owner.
The most common way a clinic loses control of its records is not an attack. It is an account nobody remembered to close.
Common questions
- Is there two-factor authentication?
- Not today. Strong unique passwords and prompt removal of leavers are what is available, and the second matters more than most clinics assume.
- Can I see who is currently signed in?
- Not as a live list. The audit log shows what was done and by whom, which is the more useful question after the fact.