Trust & compliance
Security & UK health readiness
Product controls for clinicians, organisations and technical reviewers. UK health-system deployment is the primary readiness pathway. This is product documentation, not a claim of NHS approval, DTAC approval, DSPT status, UKCA marking or legal compliance certification.
Product posture
- Clinician authority: AI-assisted drafts remain provisional, editable and attributable until the clinician owns the final output.
- Invite-gated access: authenticated accounts with role separation and restricted operational access.
- Data minimisation: transactional email does not contain case content.
- nou is not an EHR and does not replace the organisation's official clinical record.
- Session hygiene: idle timeout, HttpOnly session cookies and HTTPS in production.
UK / NHS readiness pathway
Before deployment with NHS organisations or identifiable NHS clinical data, Nou's operating model must be evidenced against the applicable UK requirements. Work is being organised around the following areas:
- UK GDPR / Data Protection Act: controller-processor roles, lawful basis, special-category processing, DPIA, retention and data-subject rights.
- Clinical safety: formal safety case, hazard log and accountable clinical-safety ownership aligned to the NHS clinical-safety standards applicable to the deployment.
- DTAC: evidence across clinical safety, data protection, technical security, interoperability, usability and accessibility.
- DSPT / data security: organisation-level controls and evidence where required by the deployment model.
- Medical-device regulation: intended-purpose assessment before making claims or enabling functions that could bring Nou within UK medical-device regulation.
See the public NHS readiness register for a clear implemented / in-preparation split.
Hosted subprocessors
Hosted production currently relies on:
- Vercel — application hosting and edge delivery
- Neon — Postgres when
DATABASE_URLis configured - Resend — transactional mail; no case content
- Configured AI provider — provisional draft generation when enabled
Data locations, retention, contractual terms and processor/subprocessor obligations must be verified for the exact deployment before identifiable clinical data is used.
Technical control register
| Control | Nou implementation | Status |
|---|---|---|
| Unique user identification | Authenticated accounts; invite-gated | Implemented |
| Role-based access | Clinician role; restricted operational administration | Implemented |
| Automatic log-off | Idle session timeout | Implemented |
| Audit controls | Access, generation and export events when the database is enabled | Implemented |
| Encryption in transit | Production HTTPS, TLS and HSTS | Production |
| Encryption at rest | Managed database / host encryption when production database is configured | Provider control |
| Integrity / versioning | Version history, export IDs and provisional AI labels | Implemented |
| Clinical-content email minimisation | Transactional mail excludes case content | Implemented |
Pilot rule
Do not treat a pilot as an exemption from governance. Identifiable clinical material should only be introduced once the pilot's controller/processor roles, lawful basis, DPIA, security controls, clinical-safety ownership, data flows and contractual terms have been agreed by the participating organisation.
US pathway
US HIPAA readiness remains a secondary market pathway. Hosted US PHI use requires the appropriate HIPAA-eligible infrastructure and executed agreements; see the existingagreements pathway.
Product documentation only. Formal legal, information-governance, clinical-safety and medical-device assessments must be completed by appropriately qualified parties for the intended deployment.