DTAC self-assessment

Domain 1

Clinical safety

Standards followed

How risk is assessed

Every check-in is scored by a single, pure, deterministic scoring engine - no machine learning, no black-box model, no probabilistic judgement of any kind. Each point on the score traces to a named rule surfaced alongside the score, so a Clinical Safety Officer or clinician can read and challenge the reasoning on the same screen as the result. This scoring engine is treated as the single highest-risk piece of logic in the product and is held to a correspondingly high automated test-coverage bar (a minimum 90% branch-coverage target).

• Scores map to RED / AMBER / GREEN.
• RED, or disclosure of self-harm ideation on a standard NHS questionnaire item, auto-raises an escalation with a service-configurable response deadline (e.g. 4 hours) and notifies the patient's named support worker.
• Free-text answers are pattern-matched for concerning keywords and floor the result to AMBER for human review - the system deliberately does not attempt to interpret free text itself.
• If a response deadline is not met, the escalation is flagged as breached and the assigned worker plus every tenant administrator are re-notified.
• Patients who stop checking in are not treated as "no news" - an engagement-status monitor auto-raises a review escalation for a disengaged patient with a prior amber/red history.
• A second, equally deterministic layer looks across a patient's history rather than at one check-in in isolation - a falling mood trend over several check-ins, repeated amber results, risk-to-self reported on consecutive check-ins, or a PHQ-9/GAD-7 score climbing between administrations. Each pattern is a named, explainable rule; the more serious ones auto-raise an escalation, the rest annotate the caseload. This catches the slow slide toward crisis that no single check-in would flag.

Hazard log (current, live in the product)

Eleven hazards are formally logged with cause, effect, existing controls, and an initial/residual risk rating, each backed by a live evidence query against production data - not static claims.

Every hazard entry is maintained alongside the software that implements its controls, so the hazard log cannot silently drift out of date with the shipped behaviour - a change to the scoring rules or the escalation/monitoring logic is expected to update the corresponding hazard entry in the same change.

Crisis safety

If a patient discloses any level of risk-to-self, crisis signposting (NHS 111 option 2, Samaritans 116 123, Shout 85258, 999) is shown immediately on selecting the answer, before submission - in case the form is abandoned - and repeated on the confirmation screen and persistently on the patient's home page. The wording is deliberately written to never promise real-time monitoring or an immediate clinical response, since the service reviews escalations within working arrangements, not 24/7. Each patient also has an optional personalised safety plan (warning signs, coping strategies, personal/professional contacts) visible to them at all times.

Optional patient-facing features, off by default

Two features that change what a patient sees are each an explicit per-ICB opt-in, disabled until a trust reviews and enables them - so an assessor sees exactly what is active for a given deployment. Worker-to-patient notes let a support worker send a patient a short message from a Clinical-Safety-Officer-approved template only - never free text, no reply path, and every message ends with a fixed line stating it is not monitored and pointing to NHS 111 option 2, Samaritans and 999. Self-management nudges match patterns in recent check-ins (poor sleep, anxiety, loneliness) to established NHS self-help resources; they are withheld entirely whenever the patient has an open escalation, so a deteriorating patient is routed to a person, not a link. Both are covered by hazards HAZ-10 and HAZ-11 above.

Clinical coverage and instruments

Pathways: general mental health, ADHD (adult/child), autism, eating disorder, perinatal, older adult, trauma. Instruments: a bespoke 4-item check-in, PHQ-9, GAD-7, CORE-10, WSAS, AUDIT-C, EPDS, ASRS-v1.1, AQ-10, SNAP-IV 26, 6-CIT, GDS-15, TSQ, PCL-5, DAST-10 - all standard NHS-used measures. Two children-and-young-people instruments (RCADS and SDQ) are deliberately not embedded yet, because correct use requires the publisher's official norm tables and, for SDQ, a licence - both need to be sourced formally during clinical-safety review rather than reconstructed from memory, since a mis-worded or mis-normed instrument for children would itself be a clinical hazard. An interim advisory control (an under-16 age gate on the adult PHQ-9/GAD-7 cadence) is in place until those instruments are properly sourced.

Domain 3

Technical security

Authentication and access control

• Authentication is provider-abstracted: the software supports a real managed identity provider in deployed environments, with a separate, clearly-labelled local-only mechanism used purely for development and demonstration purposes. Route-level access logic is written against a single interface and never knows which provider is actually authenticating a given request.
• Staff authentication uses a managed identity provider with a Secure Remote Password authentication flow and a 12-character minimum password policy. In the production-shaped configuration: multi-factor authentication is required (an authenticator app for staff, SMS for patients) and advanced identity-protection features (compromised-credential blocking, adaptive authentication) are enforced. The current cost-optimised demo environment deliberately runs with multi-factor authentication and advanced protection switched off to keep the disposable test environment cheap and simple to reset - this distinction is explicit and must be confirmed with any assessor testing a specific deployment, since it materially changes the account-takeover risk profile of what they're looking at.
• Role-based access control: support worker, clinician, administrator, commissioner, clinical safety officer, patient, and carer roles - each scoped to their own caseload/team/organisation on the server side, not just hidden in the interface.
• Token revocation on deactivation: a deactivated staff account's still-valid login session is rejected on the very next request, not just at its natural expiry.
• Rate limiting: a per-IP request limiter protects login and session-establishment endpoints; in the production-shaped configuration this is additionally backed by a managed web application firewall rate-based rule in front of the public-facing API.
• Login/security telemetry: every login success, failure, and rate-limit event is recorded and surfaced on an in-app security status screen for administrator and clinical safety officer roles.

Infrastructure security

• Cloud provider and region: AWS, deployed entirely within a single UK region (London) - UK-only data residency for every patient-data-holding component.
• Network: the deployed network uses no internet gateway for outbound traffic from the private compute tier (a deliberate cost-optimisation for the current demo footprint); access control is enforced by fine-grained network security group rules rather than subnet-level isolation alone - the database only ever accepts connections from the application's own compute tier on its database port, and the application's compute tier only ever accepts connections from the public load balancer. The database is not directly reachable from the internet under any configuration tested.
• Compute: the API runs as a managed, serverless container service behind an internet-facing load balancer terminating TLS with a managed certificate (HTTP is redirected to HTTPS, never served in plaintext). The web application is a static single-page app served from private object storage via a content-delivery network, with no public access to the underlying storage bucket itself.
• Secrets management: the session-signing key, the NHS-number and phone-number encryption keys, and database credentials are all held in a dedicated managed secrets store and injected into the running application at start-up by a narrowly-scoped deployment role - never embedded in source code, container images, or plain configuration files.
• Identity and access management: a least-privilege split is enforced between the role that deploys and starts the application (image pull, log write, secret fetch) and the role the running application itself holds (a small set of scoped identity-provider administrative actions and outbound notification permissions only - no direct secret-store access, since secrets are already resolved before the application starts).
• Optional evidence layer: an additional, separately-deployable set of account-wide security services - a multi-region audit trail (one year retention), continuous automated threat detection, and configuration-compliance rule evaluation (checking, for example, that the audit trail stays enabled, that privileged accounts have multi-factor authentication, and that no storage bucket is publicly readable) - exists and can be switched on for any environment, but is not currently deployed in the disposable demo environment, where it is off the critical path.

Application-layer security practices

The codebase this product is built from is held to an internal security standard modelled on the OWASP Top 10 and equivalent guidance for AI/agent-adjacent tooling, covering: no hard-coded secrets (all secrets are environment-injected, with secret-scanning expected in the development workflow), least-privilege service accounts, parameterised database queries via an object-relational mapping layer (no raw string-concatenated SQL), a mandatory vulnerability/licence/provenance gate before any new third-party software dependency is introduced, and a documented incident-response and audit-logging expectation.

Disaster recovery and business continuity

A disaster recovery plan exists and is kept current alongside the system it describes, covering scenarios from application data loss through to a region-wide cloud outage. The current MVP demo environment has basic, cloud-provider-native recovery capability - a daily automated database backup (1-day retention) and a fully reproducible compute/network/frontend layer that can be rebuilt from source at any time - but no automated disaster-recovery tooling, no multi-availability-zone database redundancy, no cross-region resilience, and no formally committed recovery-time/recovery-point service level at this stage. This is a deliberate, documented scope decision for a pre-production, single-tenant demo environment holding no live patient-safety dependency, with a concrete backlog already scoped for reaching production-grade disaster recovery - the two highest-priority items being extending backup retention with point-in-time recovery, and changing the database's deletion posture so an accidental infrastructure teardown cannot delete production data. Both are small, low-risk changes intended to land before any live Trust/ICB relies on the platform.

Penetration testing and formal certification

Domain 5

Usability and accessibility

• Design system: an NHS-brand-aligned interface built specifically to keep patient interactions to about one minute per check-in.
• Accessibility: the patient-facing and sign-in screens have had a dedicated screen-reader and keyboard-access pass - a skip-to-content link, the page name announced and focus moved on every navigation, programmatically labelled form fields, the rating scales exposed as keyboard-navigable ARIA radio groups, an error summary that is announced on submit and links straight to each field, status and error messages in live regions, a page language that follows the language switcher, and reduced-motion support. This is a WCAG 2.1-informed build pass - not yet independently audited or formally certified against a specific conformance level.
• Language support: Welsh language support is built into the product's translation infrastructure. The language switcher is currently enabled in the demo environment specifically for translation review purposes, not because full clinical sign-off on the translated content has occurred yet - this distinction is recorded and must be checked before relying on the Welsh content clinically.
• Patient experience: patients never see risk scores, ratings, or clinical categories - only a simple check-in flow and, where relevant, immediate crisis signposting. This is a deliberate usability/safety decision, not a missing feature.
• Mobile: a mobile app exists alongside the primary web app (check-in flow, multi-factor login, jailbreak/root detection) as a stretch/optional component of the current build.