Service User Profile — Functional Specification v0.9

The old SM treats Service Agreements as a menu section with three subsections (Quick Agreement, Search, Workspace). In the SSL Service Manager none of these survive as navigation items (G-004…G-007):

1.1 Search bar (all pages)

• Searches service users by: name, service agreement number, customer reference, other IDs, address, postcode, telephone number, equipment serial (G-005). Partial matches supported (current SM already matches display-ID fragments).
• Results show: name, DOB, agreement no., address, status badge, organisation. Click → Service User Profile.
• Terminated agreements are excluded unless a linked agreement at the same dwelling is live, in which case the terminated one appears flagged "Terminated — linked" (S-008, dual-occupancy history for the ARC).

1.2 Advanced search page G-005, S-014

Opened from the search bar on any page. Replaces old SM "Service Agreements → Search" (Basic + Advanced) and absorbs the old History views.

• Fields carried over from the old Advanced Search: Service, Status (multi-select), Funder, Name, Agreement No., Address, Telephone Number, NHS Number, SS Ref Number, NI Number, Social Care Reference Number, PNC Equipment Id, Customer Reference.
• Extended to (almost) every agreement field — modelled on the data-migration search page Dagmara demoed in M2 ("you can see absolutely every field that's available and search by it… that's out of the box"). A field picker adds criteria beyond the defaults, e.g. activated/terminated dates.
• Because status and status-change dates are searchable, the old Status History / Service Level History pages are not rebuilt (S-014); "as of" queries come with the audit layer (P-002).
• Results: Agreement No., Customer Reference, Full Name, Address, Status, Open Requests + show/hide columns with per-user column memory (P-002). Row click → Service User Profile.
• Basic search (the simple box) and advanced search are the same page in two modes, as today — but globally reachable instead of buried in a menu section.

2.1 Identity panel

2.2 Action bar

Tab set: Summary · Contacts · Requests · Assessments · Equipment · Call History · Notes · Messages · Audit. Removed: Tasks (nested under Requests), Incidents (urgent requests), History (advanced search), Service Cases (unknown purpose — dropped from Mark's design), Medication (until NHS link), Health Events (separate discussion). S-012/13/14/18

3.1 Summary

• Identity panel (§2.1) + Services panel: each service has type, start/end date, cost, payee; services may be time-boxed; auto-cancel at end date; "expiring within 7 days" surfaced (S-021).
• Recent Activity feed (read-only, no action buttons — S-010).

3.2 Contacts S-011

• Syncs with the ARC (one person store; equivalent of NSM "Circle of Care").
• Categories per contact: Primary, Emergency, Keyholder, Next of Kin (max one per service user), Power of Attorney (multiple allowed). "Keyholder" naming kept (= access holder, incl. door codes).
• Availability NEW: each contact row carries an "Edit availability" action opening the schedule editor. Editor design: one row per weekday with up to two available time windows (from–to time fields; anything outside them is unavailable), an "all day unavailable" tick, and a per-day "Copy ↓" button applying that day's windows to the remaining days ("set the remainder of the week the same as this particular day" — the PNC shortcut kept by decision). Below it: short-term unavailability (from/to dates + operator-visible reason, e.g. "On holiday — use neighbour first") which overrides the weekly schedule. Unavailable contacts grey out for operators at call time.
• Multiple phone numbers per contact with type (home / work / mobile) and matching icon.
• Single "＋ New contact" entry point: one button opens a popup that, as the email/name is typed, suggests existing people within the logged-in user's organisation who match — suggestions disappear when the lookup field is cleared. Link the existing person (no duplicate created, relation defined per service user) or continue to create a new one. Email matching keeps the lookup privacy-safe (name search deemed too easy to fish with). One person can be a contact for several service users with a different relation to each ("neighbour for 57, son for 53"). In the form: categories are checkboxes (multiple allowed; Next of Kin enforces the one-per-service-user rule), and phone numbers are added one by one, each with a type dropdown (mobile/home/work), building a removable list.
• Contact email doubles as the future Friends & Family app login (X-003).

3.3 Equipment S-017

• Query on installed equipment; live by default, toggle to show decommissioned. (Most queries are "what has Mrs Jones currently got installed".)
• Device detail view per item: model + model no., serial, PNC equipment id, firmware, SIM/line, location, installed date + installer, battery due, warranty, last test call, paired peripherals; actions: open DMP status, raise change request (equipment changes always flow through a request).
• DMP button NEW: per device, opens the DMP status panel — connectivity, mains power, battery health, periodic-call success, firmware, SIM status (suspend-on-scrap is the SaaS4 ask, X-004), recent device events (the integration "everybody has asked for").
• "Request equipment" link NEW: initiates an equipment-assignment request from this tab; assigning equipment always flows through a request → task (never direct).

3.4 Call History S-015

• Query on ARC call history via the service layer; most recent calls also packaged into the responder/engineer app work package.
• Internal Teams/Zoom calls appear here tagged Internal, with colleague, status and the notes entered when logging (S-009). A "Log internal call" action is available from the tab itself as well as the action bar.

3.5 Notes S-019

• Two categories (ILOS model): permanent and temporary (short-term, with expiry).
• Each note shows who created it and when (plus origin: PNC migration / ARC sync). "＋ Add note" opens a dialog: type, text, and — only when the type is Temporary — an expiry date; saved with the author and timestamp.
• Pulled from the ARC where already present; merged with migrated PNC notes.
• Task-work notes do NOT live here — they belong to the task (Q-007).

3.6 Messages S-019

• Filter of the global Messages console to this service user; send to individuals or admin-defined teams (assessment, dispatch, hospital…).
• Bulk/group SMS cost flagged as a commercial risk (Dumfries 3,000-user weather warnings) — limits/policy TBD; app-delivered messages are free.

3.7 Audit S-014

• Columns: when · who · source system (Service Manager / ARC — one shared database, two writers) · entity · action · from → to. Covers field changes, request/task lifecycle events, assessment status changes, system-generated records (e.g. auto-created review requests), internal call logs, and self-service edits from the Friends & Family app.
• Filters: entity type, source system, date range — the date filter underpins "as of" reporting (P-002). Full from→to edit history is a SaaS4 ask.
• ARC already captures its audit trail; the two are linked when the SM goes live.

4.1 Requests list S-012

• All the resident's requests with their tasks nested beneath each request row (task name, assignee, status, SLA — no separate Tasks tab). Each request shows its Title (e.g. "Replace lost fall detector pendant") so its purpose is visible at a glance. Filter pills All / Live (default) / Closed; closed requests appear greyed with their completed tasks and any follow-on requests they spawned.
• Multiple open requests allowed NEW — forced by incidents becoming urgent requests ("Rob going out tomorrow doesn't mean she won't fall this afternoon" — Kat, M4). Old constraint (one of installation/change/decommission) drops; conflicting combinations left to user judgment, no system validation (Q-001).
• Urgent requests (= old incidents) badge red; keep ARC colour-coded status timeline + responder notification (S-013).
• Follow-on request NEW: any request can save an associated follow-on request at the same time; the parent can close while the follow-on stays open, auto-scheduled for its date (Q-012/S-012; "finally in the new SM version, which we're not going to get" — Rob).

4.2 Request creation Q-001, Q-003, S-012

Opened from the profile action bar or Requests tab. The form is dynamic, as in Mark's SM (inbox → create): the type selection drives which fields appear. Mark's seven "Route to" forms (Response request / Technology Work / Ticket / Task / Message / Customer note / Assessment) do not survive as routes — the meetings consolidated everything into Requests with the agreed types (G-001, Q-001) — but their field patterns are reused per type. Messages and notes have their own tabs; assessments are created via requests (S-016).

Conflict rule applied: where Mark's form contradicts a meeting decision, the meeting wins. Consequently there are no user-set due dates (next action is SLA-derived, Q-006 — Mark's "Due by"/"Due" fields dropped) and the Custom task-type list comes from Administration, not Mark's hardcoded list (Q-003). Fields taken from Mark with no meeting decision either way are marked ＋Mark — to confirm below and listed in the open questions.

Form layout & behaviour (per review, 10 Jun 2026): Title + Details sit at the top; the Type selector follows and swaps the type-specific group; the auto-added default task set is displayed for every type with a per-task "N/A — close immediately" tick (Q-003), plus "＋ Add custom task". Installation is selectable (defaults: Pick stock → Install → Financial assessment → Welfare follow-up call) with a note that installations normally originate from referrals (Q-001). Assignment flow: select the Responsible's user group first, which filters the Assigned person list to that group (and derives the responsible manager) (Q-005). The "Show nearest online staff" panel was removed at Ivan's direction (10 Jun 2026) — distance-ranked assignment returns with the Scheduling module (C-004).

4.3 Request detail Q-005…Q-009

• List of assessments (risk assessments / annual inspections) with status: Draft or Published.
• Form content per "Connect assessment form.xlsm" (Ivan, 10 Jun 2026): four groups — General info (service user's name, assessment date, assessor, identifier type + number e.g. NHS Number), Wellbeing (9 questions: crisis/services, outlook, confidence, carer + impact, resilience, 3 free-text interests), Supported Self-Management (12: general health, falls count, steadiness, sight/hearing, conditions count, home suitability, continence, money barrier, condition management, free-texts), Connectedness (8: contact frequency, satisfaction, people count, loneliness, relationship quality, digital use, free-texts). Scored options exactly per the form's option lists (ScoredResponse model).
• Initial vs Full assessment: the initial subset (Q1–3, 10–12, 22–24) pre-populates the full form. Section progress shown per group.
• Output: recommended intensity from the scoring logic — Level 1 (1 call/quarter) · Level 2 (1 call/month) · Level 3 (1 call/week) · Level 4 (Refer to CRT) — plus priority ranking as percentage of risk (Home Environment, Falls, Connectedness, Digital Inclusion, Supported Self-Management). Shown live while editing and on the published view.
• Draft → Publish lifecycle NEW: editable while draft (fix mistakes, add late info — the #1 ARC complaint); on publish the version locks permanently ("coroner's court: you can't take out that she was on blood-thinning tablets"). Changes after publishing = new assessment (version-control mental model).
• Forced publishing: a request cannot complete until its linked assessment is published — prevents eternal drafts and matches today's "can't close until assessment done" behaviour.
• Auto-review: on publish, a follow-on review request is auto-created, default +12 months (TSA standard), configurable. It replaces the old single "next action date" field (which users had to manually juggle between 4-week follow-ups and 12-month reviews). The review request is managed like any request but linked to, and viewable with, the assessment.
• Assessment answers can map to database fields (e.g. middle name) — published answers update the master record via the audit trail.
• View flow (published): read-only question/answer view with the locked banner, version number, link to the auto-created review request and to previous versions.
• Edit flow (draft): editable answers with Save draft (stays editable) and Publish…, which opens a confirmation dialog spelling out the permanent lock and the auto-created +12-month review request before publishing.
• On decommission, open follow-on/review requests auto-cancel (§6.2).

6.1 States

Pending → Active → Terminating → Terminated → (Redacted), with Reactivate available ≤ 3 months after decommission. No Suspended state (S-004): all eight customers confirmed nobody operates suspension because it has no billing consequence.

6.2 Decommission S-005

• Creates a decommission request with an equipment-recovery task to schedule.
• Dual occupancy guard: only the involved resident's equipment is recovered (their bed/chair sensors), shared equipment stays or is partially recovered — confirmed by the person processing the task.
• On completion: operator chooses where recovered equipment goes (→ secondary store → quarantine flow, I-008); client data archived; records removed from the ARC.
• Auto-cancel all live requests including scheduled follow-on/review requests (avoids ghost calendar entries next year).

6.3 Reactivate S-006

• Reverses a decommission within 3 months: restores the data, and restores the equipment if already removed (per the agreed requirement). Heavily used ("South Tyneside… brilliant for bringing people back on").
• Equipment handling depends on recovery progress (Dagmara, M3): recovery task not yet done → it is simply cancelled, equipment never left the dwelling; equipment already removed → a restore/reinstall request is auto-created to return equivalent equipment (via the normal pick-stock flow, Q-004).
• Reactivation popup (from the archive): shows the window deadline, an item-by-item restore preview (data → restored in full + ARC records re-created; removed equipment → restore request; pending recoveries → cancelled, equipment kept in place), and a reinstall visit date for the restore request. On confirm: status → Active, profile leaves the archive, redaction schedule cleared, restore request visible under the profile's Requests tab.

6.4 Termination & redaction S-008, S-022

• Users create closing tasks; once stopped the agreement is frozen (read-only).
• Redaction runs automatically (the old 1am script) after the admin-configured retention period (e.g. 36 months; typically 3–7 years), with a do-not-redact flag (e.g. coroner's court). One retention rule set spans SM, ARC and migrated PNC data.

• Separate archive page — terminated profiles must NOT appear among live ones ("I don't think you should be seeing all of these terminated profiles in the rest of the system" — Nikki; customers also pay per live connection).
• Search/filter: agreement number (works even after redaction), name (empty for redacted records), status (All / Redacted / Do-not-redact flagged — no "Terminated" option since everything here is terminated), terminated date range (from / to).
• Search by agreement number even after redaction: the number survives, personal fields show as redacted — this is the data-removal verification tool for subject access requests ("has my data been removed?").
• Automatic redaction + stop flag: redaction happens automatically per the agreed dates — a nightly job (the old 1am script) redacts each agreement once its admin-configured retention period (e.g. 36 months; typically 3–7 years) elapses. A per-agreement do-not-redact flag stops it (e.g. coroner's court); settable at decommission time and from this archive. Because the flag governs irreversible data erasure, changing it is deliberately not a one-click toggle: a "Change…" button opens a confirmation popup spelling out the consequence (turning it off after the retention date means redaction runs on the next nightly job, irreversibly) and requiring a reason — permission-controlled, recorded in the audit trail with who/when/reason. One retention rule set spans SM, ARC and migrated PNC data.
• Linked-live exception: terminated agreement visible from the live linked agreement (dwelling history for the ARC).
• Reactivate possible from here within the 3-month window (restores data, and equipment if already removed — §6.3).

The old Workspace was a cross-client advanced search over requests (Assigned, Responsible, Type, Status, Request Hold Reason, Address, Name, PNC Equipment Id, Agreement No., Customer Reference → queue table with Next Action, Assigned To, Priority). Customers called it "over complicated" (SaaS4). Decision: it moves out of Service Agreements into the Requests/Tasks area (G-007) as the team work queue. It is specced here because it is part of the old section; it will be wireframed in its final home, with a preview included in this module's wireframes.

• Two scopes (naming from Mark's app, endorsed in M2): Work list — everything in the user's organisation; My work — items assigned to the logged-in user.
• Filters: request type, status (incl. On hold), hold reason, priority, assigned person, responsible team, SLA state (RAG), date window. The old per-field text filters are kept via the advanced field picker.
• On-hold query NEW: surfaces all on-hold tasks with reason, who placed the hold, and when (Q-008) — the place to chase tasks waiting on ordered equipment.
• RAG SLA colouring on every row (X-001 — explicitly liked); next-action column is the SLA-derived window (Q-006).
• Row click → request detail (§4.2); the service-user column links to the profile.
• Roster-change reassignment workflows (C-002) start from this queue — Scheduling module phase.

Quick Agreement (5 screens) is not rebuilt. It existed to rush hospital discharges onto the platform and did so by creating ghost equipment, breaking stock integrity — "a fudge that was quickly deployed without true detailed planning" (Andy, M2). Replacement, agreed in M2:

• A simplified referral form in the Referrals module covering the same urgency (combining referral + risk assessment in one step) — full spec lands in the Referrals phase.
• Unlike the old Quick Agreement, the simplified referral may include a proper stock section ("maybe the quick one does have the stock section… at that point you will be assigning some stock" — Dagmara, M2). Stock is picked/reserved through the normal flow — no ghost equipment, stock integrity maintained (Q-004).
• SaaS4 corroboration: "ability to bypass referral for emergency installs" requested; "quick agreements not used as cause too much trouble later / cause stock issues" — both point the same way: keep the speed, fix the stock.
• Details flagged TBD in the notes ("details — to be discussed"); Andy Hart to supply sample referrals (R-004).

Every screenshot group from "Current Service Manager / 5 Service Agreements" mapped to its SSL home. ✅ = specced + wireframed in this module · 📄 = specced here, wireframed in a later module · ➡ = owned by a later module · ✂ = removed by decision.

Counts are screenshot files per group (some files show the same screen in different states). Total 98 ✓.

Changes made in response to Ivan's 12 Jun review and the two critique reports (05 stakeholder, 06 UI/UX). Each is reflected in the wireframes (03) and, where structural, in the build spec (04).

• Keyword colour model: full palette vs 3 ILOS colours; migration mapping for customers using 10+ colours (G-008).
• Bulk SMS limits/charging policy for Messages (cost risk raised by Rob).
• Request cancellation end-to-end flow (Q-011) — promised follow-up discussion.
• Assessment editability window: drafts editable forever, or only until the next assessment is created?
• Review-request default period: always 12 months, or configurable per assessment type?
• Day-one audit scope: SM works off the ARC database initially — is the ARC audit view enough until the service layer lands?
• Request-creation fields taken from Mark's form without a meeting decision — confirm or drop: Channel, Requester + phone, Location (customer-address default + what3words), Summary/Details as separate fields, "Technical requirement" on change requests (§4.2).
• Health Events tab: separate discussion to schedule (SNOMED/NHS records).