Holdfast

A map, not a manual

How Holdfast is set up, and how people actually move through it

Below is the whole system as one map - stations are screens, decisions and outcomes; lines are journeys, colour-coded by who's doing what. Filter it by role, trace a single journey, or just click around. Full written detail for each journey sits underneath for anyone who wants it.

The Holdfast system map

An interactive map of Holdfast. Along the top, a Platform setup line runs from Trust tenant to ICBs, to clinical teams, to staff invited, to pathway configuration, feeding down into the Risk engine. In the middle, the Patient journey line runs from Referral received, through Consent granted, Patient onboards, to Check-in, into the Risk engine interchange, which forks into a Low risk branch (Scored green, to the Caseload dashboard, looping back to Check-in) and a Risk escalation branch (Scored amber or red, to Escalation raised, Reviewed, then to Safety plan or an MHA referral). A parallel Carer line runs from Referral (child) through Carer added into the same Check-in and Risk engine. A Waiting Well and Right to Choose branch runs from Referral through Wait threshold crossed, Flagged and signposted, to a Transfer decision resulting in either Transferred out or History retained. A One-off screener branch runs from Need identified through Screener requested to Completed once. Every branch feeds into a central Audit log, which connects on to a Security dashboard for Admins, a Hazard log for the Clinical Safety Officer, and an Aggregate report for Commissioners. Full written detail for each journey is provided in the sections below the map.

Highlight a journey:
Filter by role:

Click any station on the map to learn more, or hover a line to trace where it goes.

Roles

  • Patient
  • Carer
  • Support worker
  • Clinician
  • Admin
  • Clinical Safety Officer
  • Commissioner
  • Shared / automatic

Line weight

  • Common "highway" route
  • Standard connection
  • Optional / edge-case route
  • Automatic, written to audit log

Shapes

  • Screen or action
  • Interchange - journeys meet
  • Decision point

Setting up, maintaining and monitoring the platform

The slate "Platform setup" line along the top of the map is what everything else runs on: a Trust tenant, its ICBs, its clinical teams, the staff invited into them, and how each pathway is configured - feeding straight into the Risk engine that scores every check-in, and out again through the Audit log to Admin, Clinical Safety Officer and Commissioner oversight.

Step by step, in full
  1. Platform admin provisions a new Trust tenant - a one-off step per Trust: a new, logically isolated tenant is stood up on the shared platform. Nothing else can happen until this exists.
  2. Trust admin adds the ICBs it commissions for - each ICB is its own commissioning boundary within the tenant, matching the real data-sharing agreement rather than a shared back office.
  3. Admin stands up clinical teams and assigns pathways - a team is created per caseload, each locked to the pathway(s) it runs. Two teams sharing an ICB never see each other's patients.
  4. Staff are invited, scoped to their role and team - support workers and clinicians are scoped to a team's caseload; a Clinical Safety Officer and a Commissioner are added as distinct, ICB-wide, mostly read-only seats. Access is live within minutes.
  5. Clinicians configure how their pathway runs - check-in cadence, which screeners are in use, and safety-plan templates are set by the clinicians running that team.
  6. The team runs day to day - support workers work their risk-sorted caseload, clinicians review escalations and author safety plans, and every state change is written to the immutable audit log automatically.
  7. Oversight runs continuously - the Admin checks the security & compliance dashboard, the Clinical Safety Officer works the DCB0129 hazard log from the same audit trail, the Commissioner reviews aggregate, de-identified outcomes. None of the three see each other's view.
  8. Staff and access are kept current - when someone leaves a team, an Admin deactivates their account rather than deleting it. Access is revoked immediately, the audit trail stays intact, and the deactivation itself is logged.

Five journeys through the same map

Everything below traces a route already visible on the map above: what differs is who completes the check-in, what happens when risk crosses a threshold, and what happens when the wait itself becomes the issue. Click a card's map button to jump back up and see the route highlighted, or open "step by step" for the full written detail.

Standard check-in - risk stays low

Most common path

The everyday loop for most patients, most of the time: referral → consent → onboarding → check-in → scored GREEN → caseload → repeats.

Step by step, in full
  1. A support worker creates the patient and referral record for their pathway, scoped to their team.
  2. Explicit, versioned, withdrawable consent is captured before a single check-in begins.
  3. A short, skippable introduction explains what a check-in is and who sees it. The patient can switch to easy-read mode and one of five additional languages here.
  4. The patient completes a check-in on the cadence their clinician set - e.g. CORE-10 and WSAS, weekly or fortnightly.
  5. A deterministic, rules-based engine scores it and records the named reasons behind the score.
  6. The score stays GREEN. It feeds the support worker's risk-sorted caseload as a visible, settled, low-risk entry - not just an absence of alerts.
  7. Each cadence, the cycle repeats. Between check-ins, the Waiting Well panel keeps surfacing pathway-specific self-help resources.

Risk escalation - a check-in crosses the threshold

AMBER / RED

The reason the system exists: check-in → scored AMBER/RED → escalation raised → reviewed → safety plan or MHA referral → logged.

Step by step, in full
  1. The patient completes a check-in as usual.
  2. The risk engine scores it AMBER or RED - one or more named rules fire, e.g. a sharp score increase, a specific risk item flagged, or a run of missed check-ins.
  3. An escalation is raised automatically, routed straight to the patient's named support worker or clinician.
  4. They review the score, the specific reasons behind it, and the patient's recent check-in history in one place, then acknowledge the escalation.
  5. Action is taken and recorded: contact is made, a safety plan is authored or updated, or - for a RED result - a referral for a Mental Health Act assessment is made.
  6. Every step - raised, acknowledged, actioned - is written to the audit log with who and when, ready for the Clinical Safety Officer's DCB0129 hazard review.

Carer-completed check-in - a child pathway

Child ADHD / Autism

Same loop, different respondent: referral (child) → carer added → carer completes check-in → scored and routed as normal.

Step by step, in full
  1. A referral is created on a child pathway - e.g. Child ADHD or the child variant of the Autism pathway.
  2. A carer is added and given their own login, scoped to exactly the one patient they support - not a generic family account with wider access.
  3. The carer completes the instrument on the cadence the clinician has set. The record is tagged with a carer-completed respondent type, distinct from a self-report.
  4. Scoring and escalation run exactly as in the standard flow - same deterministic engine, same automatic routing to the assigned clinician if a threshold is crossed.

One-off screener - clinician-requested

Any pathway

A side route off the main map: need identified → screener requested → completed once → recorded and visible.

Step by step, in full
  1. A clinician identifies a specific need - e.g. an AUDIT-C alcohol-use check, a DAST-10 comorbidity screen, or choosing between the TSQ quick triage and the fuller PCL-5 for a trauma referral.
  2. The clinician raises a one-off screener request tied to that patient, separate from their standing check-in cadence.
  3. A one-time prompt appears alongside the patient's normal check-in flow.
  4. The result is stored as its own assessment record, visible to the requesting clinician and feeding the same risk view - not a separate PDF to chase down.

Right to Choose & transfer-out

Long-wait pathway

Risk isn't the only thing worth flagging: threshold crossed → flagged & signposted → transferred or retained, history kept either way.

Step by step, in full
  1. A wait crosses its pathway's NHS Right to Choose review threshold, tracked against the referral date automatically.
  2. The case is flagged on the caseload screen. Staff see a plain-language signposting panel on the case page - explicitly not clinical or legal advice, just NHS-sourced information they can share with confidence.
  3. If the patient transfers to another provider, that's recorded as its own outcome, distinct from a generic "discharged" state, so waiting-list-by-pathway reporting keeps telling the truth about where people actually went.
  4. Their check-in and risk history stays attached to the record rather than being discarded, in case they return to the service.

One check-in screen, a dozen different instruments underneath

The "Check-in" station on the map above is a single point on the journey, but what it actually presents changes completely by pathway - the same short, mobile-friendly screen can run any of the standard, published instruments below, on whatever cadence the clinician sets, scored by the same deterministic risk engine either way.

  • Self-report
  • Carer-completed
  • Clinician-requested, one-off

Mental health

Distress, functioning and alcohol-use, on a regular cadence.

  • CORE-10
  • WSAS
  • PHQ-9
  • GAD-7
  • AUDIT-C

Adult ADHD

Self-report screening while someone waits years for assessment.

  • ASRS

Child ADHD

Completed by a parent or carer through their own scoped login.

  • SNAP-IV

Autism

Adult, adolescent and child variants, with carer options.

  • AQ-10 (adult)
  • AQ-10 (adolescent)
  • AQ-10 (child)

Older adult & memory services

Cognitive screening alongside mood and comorbidity checks.

  • 6-CIT
  • GDS-15
  • DAST-10

Trauma & PTSD

Quick triage or full severity detail, picked per patient.

  • TSQ
  • PCL-5
  • DAST-10

Every one of these results lands in the same place - scored by the same rules-based engine, visible on the same risk-sorted caseload, written to the same audit log. Adding a pathway means configuring which instruments it uses, not building a new app.

Want to see this against your own pathways?

Every route on the map above maps to a real Trust or ICB structure - we can walk through how your teams and pathways would fit before any commitment.

Talk to us about a pilot