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 Petra 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

2.2 Identity header

• Preferred name reads with the name CHANGED: the "Known as" value appears in brackets after the name in the identity header (Mrs Edith Carter (Edie)) instead of occupying its own detail row. It is the name a responder or ARC operator will actually use on the phone, so it belongs where the name is read, not several rows below it. Still editable as its own field in the Edit-details popup.
• Print to PDF CHANGED: opens the print dialog immediately, consistent with every other print action in the platform, rather than leaving the user on an intermediate page with a Print button to find.

3.1 Summary

• Active incident – ARC response timeline NEW: while an urgent request is live on this agreement, the Summary tab leads with a red-accented "Active incident" card carrying the ARC colour-coded timeline (sent → accepted → en route → arrived → completed) with the ETA, the responder and the SLA, plus direct links to the request and to Live Service. The timeline already existed but only inside the Requests tab, so an active incident was not visible when the profile opened – exactly the moment a responder or an ARC operator needs to know that someone is already on their way. The card is not rendered when there is no live incident, so the Summary stays quiet in the normal case. The Requests-tab copy is unchanged. S-024, extends S-013
• 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).
• Cost is an amount plus a period CHANGED: the Add / Edit service popups carry a Cost field and a separate Period dropdown (Per day · Per week · Per month · Per year). Cost was previously hard-wired to "per week", which is wrong for services billed per visit, monthly or annually. Both values come from the admin service type and are not hand-edited. S-021
• Extend service CHANGED: nothing is pre-selected. The New end date opens empty and the Or extend by dropdown defaults to "please select". A billing-affecting change must be an explicit decision, not an accepted default; the two controls are alternatives and setting one clears the other. Confirming without a choice is refused. S-021
• Note column NEW on the Services table – free text per service, hidden by default and switched on from the Columns control (which then remembers the choice per user).
• Columns control placement CHANGED: on the Services table the Columns control is icon-only (with the platform's styled "Columns" tooltip) and sits to the left of the primary action rather than after it. Implemented generically in table-tools.js via an opt-in [data-tt-slot] placement slot, so any header with its own primary action can position it the same way.
• 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.
• Availability editor rules CHANGED: ticking "all day unavailable" disables the day's time fields and greys them out, so the row reads as switched off at a glance – but the entered times are kept, not cleared: unticking the box must give the person their schedule back, not an empty row to retype. A window's start time cannot be on or after its end time; an invalid pair is flagged on both fields and the editor refuses to save until it is corrected. Rows that are marked all-day-unavailable are excluded from that check, since their times are inert. The weekly grid carries no Columns control – its columns are the schedule, so hiding one would hide half the week.
• Multiple phone numbers per contact CHANGED: entered as a repeatable list of rows with an "Add phone" button, exactly as in the service-user edit popup. The earlier bespoke "type + number + Add number" chip control is retired, so the platform has one phone-entry pattern rather than two.
• One telephone glyph CHANGED: the mobile / home / work icons are replaced by a single phone icon throughout. The platform does not record which kind of number it is, so three different glyphs were asserting a distinction the data does not carry.
• 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 a repeatable list.
  The popup opens blank CHANGED – it creates a new contact, so no name, relation, category or phone number is pre-filled. Name is the first field (it is what you know first, and it is required), with email beneath it driving the existing-contact lookup; the suggestion list appears while the email has content and disappears when it is cleared. Email is the one field carrying sample data in the wireframe, because without it the link-an-existing-person flow cannot be demonstrated.
• Contact email doubles as the future Friends & Family app login (X-003).
• Header actions CHANGED: Change priority and New contact sit hard against the right edge of the card header, with the icon-only Columns control placed ahead of them via the shared [data-tt-slot] mechanism. Previously table-tools.js appended Columns after the button group with its own margin-left:auto, and the two auto margins split the free space between them – which is why the buttons sat adrift of the right edge instead of against it.

3.2c Requests tab: one Request column CHANGED

3.2b Messages tab is read-only CHANGED

3.2a Table header grammar (all tabs) CHANGED

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 (S-012; "finally in the new SM version, which we're not going to get" – Rob).
• Linked requests across the property / linked agreement NEW: where requests exist for the same dwelling or a linked agreement, a banner indicates them and the relevant rows carry a Linked tag, so the operator sees a request shared with another resident (e.g. Harold Carter) (Q-018).

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 (revised 19 Jun 2026, Q-013): Type and Priority are the first two fields; for a new request only Type, Priority, Title and Details show initially and choosing a type reveals the rest – a prominent per-type SLA panel (Q-006), the type-specific group, the auto-added default task set (each with a "N/A – close immediately" tick, Q-003, plus "＋ Add custom task"), the channel and the cross-user option. 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 list to who is on shift the chosen visit day (Q-015); the operator can open the schedule and assign directly, after which the booked date/time shows under the assignee. The "Show nearest online staff" panel was removed at Ivan's direction (10 Jun 2026) – distance-ranked / route assignment returns with the Scheduling module (C-004). Applies to all involved: an option raises the request for every resident at the dwelling / linked agreement, creating the paired linked request (Q-018).

4.3 Request detail Q-005…Q-009, Q-016

CHANGED There is one canonical request-detail layout – the detail opened from this Requests tab is identical to the one opened from the all-Requests console (file 14): Details / Links / Actions in the left 330px panel, Tasks and Stock in the wide column (Q-016).

• 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).
• Follow-on request on publish NEW: the publish confirmation carries an optional Follow-on request field. An assessment usually concludes that something must now happen - equipment to fit, a call schedule to start, a falls referral to make, a safeguarding concern to raise - and the moment the finding is in front of you is the moment it actually gets raised. The follow-on is a welfare call back to the service user, and the assessor chooses the interval, not a calendar date: Call in 3 days, Call in 5 days, Call in 2 weeks. The due date is derived from the interval chosen, never hand-picked (Q-006), and a note carries the finding that prompted it. This is on top of the automatic +12-month review request, which is still created regardless; leaving the field on "none" reproduces exactly the old behaviour. S-016
• 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.
• Print / export to PDF NEW: a completed (published) assessment can be printed, or saved as a PDF from the browser's print dialog – the copy that goes to the GP, the funder, the family, or into an evidence bundle. Printing is scoped to the assessment: the app shell (menu, top bar, ticker, drawer) and the modal chrome drop away, and a print header carries the service user, agreement number, address, assessment version, assessor, publication date and a "printed on / by" stamp, so a loose page is always identifiable. Wireframe chips and annotations are suppressed on paper. Because published versions are locked (S-016), the printed copy is a faithful record of what was published – which is the whole point of the coroner's-court rule. Drafts cannot be printed: publish first, so no unversioned document can escape the system. Available from the assessment view and directly from the row in the Assessments list. Implementation note: the assessment is cloned into a top-level print root rather than printed where it sits. The assessment lives inside the tabbed page structure, so printing it in place meant overriding every ancestor's layout – and one of those overrides (hiding the page behind the modal) won, producing a blank page. A clone at document level has no ancestors to fight, and is removed again once the print dialog closes. S-023
• 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 (Petra, 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" – Paula; 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" (Greg, 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" – Petra, 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"); Greg Mason 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).

Changes from Ivan's 15 Jun review. Several refine or reverse Round-11 decisions (noted below); each is reflected in the wireframes (03).

• 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).