The question behind "vertical or horizontal" is really who is looking, and what decision do they make. A partner-practice lead needs a story; a PCC needs a queue; Bill needs the leak in one picture; the build team needs the register. One drawing will not do all four, but they can share one data model and link to each other, which is what these mockups are meant to test.
Viz — working views
Viz A · Prism — clinic worklists
Every stuck patient with color, days in color and SLA flag, where stuck, days stuck, named owner queue (Campaign #1–#6) and the recommended next action; sortable and filterable by color; priority sort puts SLA breaches and VIPs first. The patient page carries both color axes, the action hub (LIVE / SIMULATED labelled), every outreach option for the color, the encounter timeline, disposition history and audiogram attempts.
Open Viz AViz B · Screener — before the Dx is booked
The stage the portal does not yet cover: who was invited, who answered, who scored positive and is still not booked, whose visit is about to happen unanswered. Blue Form answers with Ryan's scoring math, the band and the positive rule; actions to resend the link, book or add the test to the visit, log a call, print for the chart, hand the paper form, or set do-not-text.
Open Viz BViz C · Patient event ledger
The patient-level altitude from the kickoff package. Every row names its source layer; hatched rows are silences where an SOP or PFP step should have left a record. The portal's drill-down (Viz A) is this view built for real; Viz C keeps the source-layer badge on every row and the hatched silences where an SOP or PFP step should have left a record.
Open Viz CMgt — management and design views
Mgt A · Swimlane process map
Every register card sits in the cell where it happens. The left stripe (or fill, with the toggle) says whether the touch is recorded with a clock, only in a daily copy, or not at all. Hatched cells are measured leaks.
Open Mgt AMgt B · Subway map
Built to be understood in thirty seconds by someone who has never seen the register. Leaks are dashed exits with the number we measured; the ribbon under each station shows which data layer sees it.
Open Mgt BMgt C · Station × channel grid
The only view where an empty cell is visible. Forces the "none by design" versus "gap" decision, and makes the data problem a shape: the SMS rows are green because CounselEAR logs them, the voice rows are red.
Open Mgt CMgt E · Layer architecture
How the program is built rather than what the patient experiences. Customer.io is the whole orchestration layer, drawn in its own vocabulary: segments hold the rules, campaigns and journeys hold the flow, actions (message, webhook, attribute update, worklist push) do the work. Processing holds the engines and pipelines that compute what a segment cannot — the PRISM decision engine fed by a real-time NOAH API adapter, the Azure rules and event jobs (Action-based: fired by a webhook or by hand), the CounselEAR write-back adapter, the Blue Form pipelines, the signature checker, the mFax adapter, the Fax Manager, Gloria and Matthew, the call center. Thick arrows are the buses; click a box for its connections; the story walks a Green patient through one loop.
Open Mgt EComparison
| Question | Mgt A · Swimlane | Mgt B · Subway | Mgt C · Grid | Viz C · Ledger |
|---|---|---|---|---|
| Who is it for | Ops leads, build team (Lisa, Ryan, CBB) | Bill, partner practices, board | Register owners (Paul, Rick, Morgan) | PCC / RCM / clinic managers working a queue |
| Decision it supports | Who owns this step; is it recorded; where do we add a rule | Where the funnel leaks and how much; which entry lines matter | Is the map complete; which cells are gaps; which channels are dark | What do I do for this patient now |
| Orientation | Horizontal (time left to right; actors stacked) | Horizontal (four lines converge at Dx; external referrals run along the top and join the direct-HTE row) | Matrix | Vertical (time down) |
| How data sources appear | Color stripe / fill per card + a "Data layer" lane | Colored dots at stations + ribbon | Cell color = weakest source; side panel lists the missing source | Badge on every row (webhook / API / prod / none); hatched silences |
| How missing sources appear | Red cards; hatched leak cells | Red dots; dashed exits with the measured number | Red cells; explicit "fix" text per cell | Hatched rows: the absence of an event where a rule expected one |
| Scales to 109 cards? | Needs filters; ~40 visible at once | Overview no; the expanded line holds its own stops (W3 Digital BFHS: 12 stops, 8 exits, 3 re-routes) plus five color tracks between Dx completed and HTE booked (Green, Blue clearance, Yellow PVC, Orange nurture, Pink clean-and-check), each stop citing its SOP | Yes (counts), with drill-down | Per patient, so yes |
| Shows volume / flow | Only as leak pills | Yes, as labels; could become a Sankey | Counts of cards, not patients | No |
| Relationship to Ryan's v22 map | Same family: cards in phases; adds actor lanes and the data layer | Complementary summary | Complementary audit | The instance view v22 describes but does not draw |
| Effort to make live | Medium: register table + coverage flag per card | Low: hand-drawn SVG, refreshed numbers | Low: pivot of the register | High: needs identity spine, webhook subscription, rules engine (it IS the dashboard patient view) |
Other approaches considered
| Approach | What it would add | Why not first |
|---|---|---|
| Sankey / quantified funnel (Dx color → fax → HTE → treated with patient counts) | Volume honesty: widths are patients, not cards. Natural next step for B once the identity spine gives one count per patient per station. | Needs reconciled counts (the blue-form definitional gap) or it launches on a disputed baseline; kickoff package rails. |
| State-machine board (Kanban: columns = patient states, cards = patients, timers on cards) | The live operational queue; each column is a register exit state. | Requires the rules engine and one canonical disposition vocabulary; it is WS3's UI, not a map of the process. |
| Ryan's card map as-is, extended with data fields | Keeps one artifact and one owner; SIPOC already there. Add "recorded in", "webhook event", "API write" fields per step. | No actor lanes, so ownership is a field not a position; 76 steps is already dense. Still the right home for the SOP-level detail. |
| Vertical timeline of the whole journey (one column, phases stacked) | Reads like a document; prints well. | Hides parallelism (five entries, four color tracks); becomes a scroll. |
| Geographic / pod view (map of 10 pods with per-site leak rates) | Where to intervene first; practice-facing. | Not a process view; a dashboard filter on top of any of the above. |
The proto2 portal (openclaw-mb-01) versus these mockups
Bill's team has a working prototype of the Visibility layer at https://openclaw-mb-01.tail34706b.ts.net:10000/ (synthetic patients, simulated sends, shared passcode). Its views were reviewed on September 29 against A, B, C and D. Verdicts below; the layer architecture (E) now shows the portal's views as the Visibility band.
| Portal view | What it does | Nearest mockup | Verdict |
|---|---|---|---|
| Clinic worklists (per clinic, combined) | Every stuck patient, oldest first; sort any column; filter by color; days in color with SLA flag; named owner queue (Campaign #1–#6); recommended next action | A's action badges; D's queue strip | The portal wins. A keeps only its process-map role (who owns each step, is it recorded); its queue badges are retired. |
| Patient drill-down + action hub | Snapshot, frozen diagnostic color vs moving working color, next actions (LIVE / SIMULATED labelled), encounter timeline with who logged each touch, disposition history, audiogram attempts | Viz C · Ledger | Viz C built for real. Viz C's three-layer source badges and hatched silences are the one thing worth carrying into the portal. |
| Management rollup | Clinics worst-first: stuck, SLA breaches, worst and average days, top stuck reason, won / lost; working-color counts per clinic | B's station KPIs; C's totals | Complements B (B tells the story, the rollup gives the numbers). Does not replace C: the rollup counts patients, C audits whether the register is recorded at all. |
| Audiogram cohort | Every diagnostic attempt: how they entered, owner, happened / no-show / rescheduled, hearing loss, color at diagnostic | — | New; Bill's cohort tracker from the dashboard spec. |
| Live event feed (Patient Zero) | One patient's journey as an event list, each row tagged LIVE or SIMULATED and naming the rail it stands in for | Viz C · Ledger | Pairs with Viz C; it is the proof surface for what is wired. |
| Search | Fuzzy name, DOB in any format, color, voice dictation | — | New. |
| Rules card · talk track | The Prism rulebook per color with Ryan's ratifications inline; PAI call framework v2; Reach outreach SOP | Contact map Part I; B's SOP citations | The reference data made visible; B's drawer now cites it. |
| Patient-facing Blue Form | Five questions, any DOB format, voice; scored at submit with Ryan's math | — | An action-layer app with the only patient-facing screen; listed in the Visibility band for that reason. |
Ratifications picked up from the rules card and applied to B's tracks: Red is a 12-month rescreen recall, not terminal; Black has no re-test campaign (the 4–6 week nudge is dropped); White is an annual retest recall, not event-driven coverage watching; Blue carries a 10-day medical-clearance clock in proto2 beside the practice's 28-day flag; Green is not terminal and can re-color to Orange, Pink, Yellow or White; BLUE→GREEN and BLUE→YELLOW with clearance documented are automatable now; Orange = Campaign #1 (45-day email + 6-month text), Yellow = #2, Pink = #3 (3–18 months, 8 touches + 2 texts), Green = #4 same-day, Blue = #5, Gray = #6 (3-day results review).
A suggested combination
Use B as the one-page story for Bill and the practices, fed by the rollup's numbers. Use A as the design-time process map for the core team (ownership and recording per step). Keep C as the completeness audit behind the register and the annual BAA attestation. Viz C is the design reference for the portal's patient drill-down and event feed; a leak clicked in Mgt A or Mgt B should land on the drill-down. E shows where all of this sits in the five-layer stack. Ryan's v22 and the Prism rules card stay the SOP-level definitions everything points to.
Interaction patterns and action indicators, side by side
| Question | Mgt A · Swimlane | Mgt B · Subway | Mgt C · Grid | Viz C · Ledger |
|---|---|---|---|---|
| Where is the action indicator | Red pulsing badge on the card (count of open items); red count in the column header; hatched leak cells | Red count beside a station; dashed red exits with the measured number | Red badge in the cell; row / column totals of unrecorded and open; hatched undecided cells in Gap mode | Red "Act" button on every fired rule; the queue strip itself |
| What a click does | Card → drawer (owner, SOP, PFP step, timer, source, missing source, open items). Leak pill → drawer scoped to the station's queue | Line (legend or the line itself) → strip map of that line below the overview: every stop, exits as red sidings, re-routes to other lines as dashed pills (click to follow), skips and loops; a look-ahead selector rewrites the timers. Stop → drawer (who, on whose behalf, system, timer, data layer, register card, ways out, open items). Station → drawer (numbers, benchmark, sparkline, sources, open items). Exit → the patients behind it | Cell → side panel (cards, open items, missing source, decide none / gap, request feed, create rule) | Act → action panel: script, live slots, disposition buttons |
| Can you get from the indicator to the action | Yes: "Open →" on each item lands on D with that patient | Yes: "Work this list →" lands on D; "See detail" lands on A with the column highlighted | Yes: "Work first item →" lands on D; "Station on swimlane" lands on A | Yes, in place: choosing a disposition writes back via the API, appends an L2 row, clears the queue item |
| Filters / modes | Lane, recording status, search, "only cards with open items", data-layer toggle, future-state toggle | Click a line to expand; hover to isolate; ◐ to hide from the overview; look-ahead 2 / 3 / 7 / 14 days | Coverage / Open items / Gap decisions; future-state toggle | Layer chips (L1 / L2 / L3 / none); patient switcher |
| Deep links in | ?station=S5&card=S5-07 | ?line=w3 opens a line expanded | — | ?patient=P2 |
| Who lands here first | Core team review | Bill; practice leads | Register owners; data lane | PCC / RCM working the day |
Data caveats: counts are from the September 23 evidence pass; the ledger patient is fictional; future-state cards come from PFP v22.