4 min read
Designing Patient Journeys: Turning Clinic Workflows Into Software Flows

I’ve been CTO at TIBU Health for about a year now. The biggest challenge isn’t writing code - it’s translating how clinics actually work into software that people will actually use. Most healthcare apps fail because engineers build what makes sense to them, not what makes sense to a nurse juggling 40 patients or a doctor running late.

Start with the Physical Workflow

When we built our first patient portal, I assumed patients would book online, check in digitally, and move through care smoothly. Reality was messier: patients called to book because data is expensive, arrived at random times, forgot phone numbers, and needed paper receipts for insurance.

My instinct early on was to try to fix this - to design software that nudged patients toward cleaner behaviour. That was wrong. The job is to digitize the workflow that exists, not force a new one. I now spend days shadowing clinic operations before writing a single line of code:

  • How do patients arrive? Walk-in, referred, or scheduled?
  • What information do nurses collect first? Insurance, vitals, or the chief complaint?
  • Where do paper forms go? Are they scanned, filed, or lost?
  • What happens when a patient can’t pay? Are they turned away, or do they use a payment plan?

Every clinic has exceptions and workarounds. If the software doesn’t account for these, staff will abandon it - and then nothing else matters.

Map the Patient Journey in Stages

We break our patient flows into discrete stages with clear triggers and outcomes:

  1. Pre-visit: Booking, reminders, pre-registration.
  2. Arrival: Check-in, triage, queue assignment.
  3. Consultation: Vitals capture, diagnosis, prescription.
  4. Post-visit: Payment, follow-up scheduling, discharge instructions.
  5. Follow-up: Reminders, adherence tracking, outcome monitoring.

Each stage needs a “happy path” and documented exception paths. For example:

  • Happy path: Check in → vitals → doctor visit → payment → leave.
  • Exception 1: Patient arrives without appointment → receptionist adds walk-in → patient joins queue.
  • Exception 2: Patient cannot pay → finance creates payment plan → account flagged for follow-up.
  • Exception 3: Patient needs urgent care → nurse escalates → doctor sees them immediately.

Automation Should Reduce Work

We automate predictable tasks so staff can focus on exceptions:

  • SMS Reminders: Sent 24 hours before to reduce no-shows by ~30%.
  • Auto-queueing: Assignment based on appointment type (general vs specialist).
  • Pre-filled forms: Using data from previous visits so patients only confirm details.
  • Payment receipts: Generated and sent automatically via SMS.

We don’t automate decisions that require judgment. If vitals are abnormal, the system flags the nurse but doesn’t decide whether to escalate.

Build for Intermittent Connectivity

COVID-19 pushed us to move faster on telehealth, but internet in Kenya is not consistent. Our software is offline-first:

  • Nurses capture vitals on tablets without Wi-Fi.
  • Data syncs to the server when connectivity returns.
  • Doctors view cached patient records during consultations.
  • Queue status updates in the background without blocking the UI.

Measure What Matters to Clinics

I used to track API response times. Those matter, but clinic managers care about operational KPIs:

  • Average wait time: From queue to consultation.
  • Patient throughput: Patients seen per day.
  • No-show rate: Appointments missed.
  • Payment collection rate: Revenue captured vs deferred.

When we reduced average wait time from 45 minutes to 28 minutes by optimising queue logic, clinic managers started trusting the system. That trust is what gets features adopted.

The Workflow is Never “Done”

Clinics evolve as they add services or change staff. Our workflow engine allows admins to:

  • Add new appointment types without code changes.
  • Adjust queue priorities (e.g., urgent care > general).
  • Customise forms per clinic location.
  • Enable or disable payment methods.

The goal is software that adapts to the clinic. I’ve found that the more time engineers spend in actual clinics - watching real patients move through real workflows, messy exceptions and all - the better the software gets.