Reframing outpatient flow as an operating-system problem
A self-initiated prototype for examining how patients, front-desk teams, clinicians and billing staff move through a high-volume outpatient workflow. It makes queue state, handoff ownership and operating assumptions visible so the next intervention can be chosen on evidence.
Prototype materials available on request.
I can walk through the operating problem, the evidence, the decisions made and the limits of the prototype.
Request a case walkthroughRegistration, consultation, diagnostics and billing form one journey but operate as separate queues. Patients absorb the uncertainty while staff lack a shared view of status, exceptions and ownership; automating the wrong step could simply move the bottleneck.
The prototype maps the journey as linked decisions, then models token, billing and escalation states around the handoffs most likely to constrain flow. It prioritises visibility and exception ownership before automation. Any efficiency effect is illustrative; future validation would compare stage-level wait time, unresolved handoffs and billing exceptions against a documented baseline.
Journey map
- Input
- Patient path across outpatient functions
- Engine
- Process decomposition and handoff mapping
- Output
- A shared view of queues, ownership gaps and decisions
Control model
- Input
- Token, billing and exception states
- Engine
- Rules, transitions and escalation paths
- Output
- A model for testing operating controls
Management view
- Input
- Queue and handoff signals
- Engine
- Constraint prioritisation
- Output
- A basis for deciding where to investigate next
diagnosis
- Patient-journey mapping
- Queue and handoff analysis
controls
- Token-state model
- Billing checkpoints
- Exception routing
decisions
- Constraint prioritisation
- Management visibility
Maps who is waiting, who owns the next action and where the workflow can stall.
Prioritises queue visibility and exception handling before deeper automation.
Separates repository evidence from assumptions about operating impact.
Proposed validation: observe stage timestamps and exception resolution in a consenting setting; no deployment or realised savings are claimed.