Viz C — One patient, one ledger: every event from three data layers, the rules that fired, and the action

The patient-level view from the kickoff package. The strip at the top is the queue; pick a patient. Rows are events badged by source layer; hatched rows are silences where a rule expected an event. A fired rule has a red "Act" button that opens the action panel; the disposition you choose is written back through the API and appears as a new L2 row.

Illustrative patients. All identifiers and dates are fictional; event types, sources, timers and API calls are real.

Action

Click a red Act button in the rules column to open the next step for this patient.

Reading the ledger

  • L1 webhook (stage_counselear): the event clock, ~5 min latency.
  • L2 API (Web Services v4): what the program or an app wrote back.
  • L3 prod copy: daily reconciled state, no time of day.
  • none: an expected step that left no record. The leaks, as silence.

Rules for this patient

    Interaction pattern

    1. Queue strip: the open items, oldest first; the same items the badges in A, B and C count. Deep link ?patient=P2 lands here from any of them.
    2. Header: state, days in state against the SOP timer, owner of the next touch, current color tag.
    3. Ledger: filter by layer with the chips; hatched rows are the missed steps; every row names its source so the "no log means it didn't happen" rule is visible per event.
    4. Act: a fired rule's red button opens the action panel: the script line, two open slots read live from AppointmentsByDateRange, and disposition buttons. Choosing one writes back (Appointments create/update, Patients tags or consent flags), appends the L2 row, updates the state, and removes the item from the queue.
    5. Hand off: "Send to Matthew" and "Escalate" are dispositions too; they create the task appointment for the next actor.
    Good at: turning a leak into a next action and proving the three-layer model per event. Bad at: the aggregate; it is what you land on from A, B or C.