Healthcare · Clinical workflow design
A zero-to-one engagement connecting professional onboarding, patient registration, case management, treatment planning, chemotherapy scheduling, treatment sessions, and follow-up in one longitudinal platform. Delivered through Techtrail Consultancy Services. The end client, geography, release scale, and all patient and professional data remain confidential.
Context and challenge
The client needed more than a patient-record interface. The product had to connect patient administration, case ownership, treatment planning, chemotherapy delivery, and follow-up across several professional roles. The existing problem space was fragmented across clinical and administrative activities. Designing each stage as an isolated feature would make teams repeatedly relocate the patient, reconstruct context, and reconcile treatment information across separate parts of the workflow.
The platform also generated medicine suggestions from predefined clinical rules reviewed by specialist oncologists. The system could support professional judgment, but the treating oncologist needed to remain visibly responsible for modifying and confirming the final treatment plan.
How might we connect patient administration, oncology case management, treatment planning, chemotherapy delivery, and follow-up in one coherent workflow while keeping clinicians visibly in control?
Clinical inputs and product synthesis
Research and clinical discovery were led by the wider team. I did not personally conduct the interviews or formal usability studies. My responsibility was to interpret the documented inputs, specialist review, and product requirements and translate them into workflows, information architecture, forms, states, and interaction behaviour.
Specialist oncologists validated terminology, treatment rules, regimen logic, and dosage-related requirements. I used that input to determine how information should be structured, where plan-level and session-level data needed to separate, and where clinician authority needed to remain explicit.
Clinical input to design decision
These are consolidated product inputs, not direct participant quotations.
Clinical input
Patient, diagnosis, treatment, and follow-up context could not fragment when ownership or task changed.
Product decision
Create one persistent case workspace across the longitudinal journey.
Clinical input
Protocol intent, cycle schedule, session activity, delays, and follow-up required related but distinct structures.
Product decision
Separate plan-level, cycle-level, sitting-level, and follow-up information.
Clinical input
Generated medicines needed specialist-approved logic and an explicit path for clinician modification.
Product decision
Keep generated suggestions editable and the final plan clinician-controlled.
Multi-role system
The available materials support these workflow responsibilities; they do not fully document every role-by-role permission rule.
Reviewed clinical context, created or modified treatment plans, and retained responsibility for the final treatment decision.
Supported treatment-session activity, observations, documentation, and follow-up continuity.
Supported patient registration, appointments, records, and operational coordination.
Supported case continuity, scheduling, institutional association, and transfer-related work.
End-to-end workflow
Case views—not a mandatory sequence
Active, pending approval, transferred, and archived were distinct case views or states. “All cases” was a consolidated view, not another lifecycle step.
Design decisions
Longitudinal case model
Clinical workflow structure
This flow describes the supported scheduling logic without claiming that every date was recalculated automatically.
Human-in-the-loop decision support
Clinical boundary: Specialist oncologists validated the rule logic and terminology; the treating oncologist retained responsibility for the final treatment decision.
Cross-functional collaboration
Design trade-off
The product needed to make established treatment logic available within the workflow without obscuring who owned the final decision. Specialist oncologists validated the clinical rules and terminology. I translated that input into an editable suggestion flow, while product and engineering shaped scope, data behaviour, and implementation feasibility.
The resulting model preserved consistency and speed while keeping the treating oncologist visibly responsible for reviewing, modifying, and confirming the plan.
Design to delivery
As the designer, I defined the product workflows, information architecture, navigation, forms, interaction states, and visual design. I also contributed to the ReactJS front end by translating approved page structures, navigation, forms, validation states, and interaction behaviour into the working product.
The available material does not preserve exact module-by-module code ownership, so I do not claim that I independently built the full released application. Backend services, integration, QA, deployment, and the final client environment were owned by the wider team.
The product progressed through a confidential pilot and client release involving real clinical and administrative users. Release scale, client acceptance details, usage data, and clinical or business outcomes remain confidential or unavailable.