Security
What the prototype implements today, described without overclaiming.
Implemented in this prototype
- Authentication
- Email/password and Google sign-in issuing signed JWT sessions. Passwords are hashed by the managed auth service; the application never stores them.
- Role-based access
- Roles are stored in a dedicated table and checked server-side. Roles are never read from client storage.
- Row-level authorisation
- Every data table enforces organisation-scoped row-level security, so a session can only read its own organisation's records.
- Server-side authorisation
- Screening, review, consent and allocation run as authenticated server functions that re-verify the caller before writing.
- Audit logging
- Actions are appended to an audit record with actor, entity, timestamp and metadata.
- Synthetic data
- Demo records are synthetic. No real patient data is loaded.
- Environment-based configuration
- Secrets and service credentials are supplied by the environment, not committed to the repository.
Required before production use
- Formal validation
- Documented system validation, test evidence and change control.
- Encryption governance
- Key management, rotation policy and customer-managed keys.
- PHI controls
- De-identification review, data retention schedules, breach procedures and BAAs/DPAs.
- Independent assessment
- External security testing and a formal privacy impact assessment.
- Monitoring
- Continuous log review, alerting and incident response runbooks.
ClinQSphereX is currently a research prototype and is not intended for production PHI without additional security, privacy, validation and regulatory controls. No compliance certification is claimed or implied.