Security in MindFlow is layered: who you are (authentication), what you can do (authorisation), and what happened (audit). Every sensitive action produces an immutable audit record. The system is designed so that a compromised password alone is never sufficient to access patient data.
All staff accounts support TOTP-based 2FA (RFC 6238, the same standard used by Google Authenticator, Authy, and Microsoft Authenticator). Recovery codes are generated at setup and stored in hashed form. A stolen password cannot be used to log in without the second factor.
Passwords are hashed using Argon2id, the current strongest standard for password hashing, with tuned memory and time cost parameters. Minimum complexity rules are enforced at account creation and password change.
Failed login attempts are tracked per IP address and per username. After a configured number of failures within a short window, the account is soft-locked and an alert email is sent to the clinic admin. This prevents credential-stuffing and brute-force attacks.
Staff can optionally sign in using their Google Workspace account via the standard Google OAuth2 flow. This is an additional login option, not a replacement, 2FA still applies when Google login is used.
Every staff member is assigned a role. Each role is mapped to a set of permission strings, one per action, per module (e.g., view patients, create prescriptions, edit billing). Permissions are checked on every protected action, both in the interface and at the API level.
Permissions are defined at the action level (view, create, edit, delete) per module. A receptionist can be given appointment-booking permissions without access to clinical notes. A pharmacist has pharmacy permissions but cannot access billing for non-pharmacy items.
Module-level access (e.g., the pharmacy portal or the IPD environment) is controlled by plan-level feature flags before RBAC is even checked. A module that is disabled at the plan level is inaccessible regardless of any role assignment.
Default roles (Admin, Doctor, Nurse, Receptionist, Pharmacist) provide a sensible starting point. Clinic admins can define additional custom roles with any combination of permissions to match their specific staffing structure.
Every significant action, patient record viewed, note saved, prescription signed, billing change, role change, login, logout, is appended to an audit log with the staff member's identity, the action, the affected record, the IP address, the device, and the timestamp. This log cannot be modified retroactively.
A formal register for data breaches, unauthorised access events, and other security incidents, separate from clinical records and accessible only to clinic admins. Each entry tracks severity, affected patient count, containment actions, and resolution status.
Patient Subject Access Requests and erasure requests (under the DPDP Act) are tracked as formal tasks with response deadlines. Status moves from received → acknowledged → fulfilled or rejected. The register is available to clinic admins and, for compliance purposes, to the admin of the SaaS platform.
Database backups run on a configurable schedule managed from within the admin interface. Backups are compressed and optionally encrypted. Backup history and download access are visible in the admin UI, no server access is required.
When a patient erasure request is fulfilled, personally identifying fields are hard-deleted. Linked clinical records are soft-deleted. The audit log retains the anonymised event (action type and timestamp) but not the patient's identity, satisfying the DPDP erasure requirement while preserving the audit trail integrity.
All background tasks, reminders, backups, sync jobs, expiry alerts, AI health audits, are visible and controllable from a single admin screen. Each task shows its schedule, last run time, and a pass/fail log. Tasks are triggered by a server-level cron job and execute independently, so a slow task does not block others.
Software updates, including database schema migrations and code changes, can be applied from within the admin interface without requiring server access. The update process runs migrations in order and is safe to re-run if interrupted.
The plugin architecture allows additional capabilities to be installed without modifying core code. Plugins register their own navigation items, API handlers, and scheduled tasks through a defined hook system. Installed plugins are listed with enable/disable controls in the admin interface. Plugins cannot override or bypass core permission checks.
A REST/JSON API allows external systems (hospital management, accounting, HR) to access patient and billing data using API keys. All API calls are logged with the endpoint, response code, and latency. Rate limiting is configurable per key.
The demo comes pre-loaded with real sample data, so you can click through actual appointments, patients and prescriptions.