Rebuilt a fragmented oncology EMR around the workflows of doctors, nurses and administrative teams.

The Objective

MOC's existing EMR had accumulated features across departments, but the experience wasn't designed as one connected system. My challenge was to understand how clinical, operational and administrative teams interacted with the same patient journey—and create a product architecture that could simplify those workflows without losing the depth required by a hospital.

Role:

Lead Product Designer

Scope:

Product strategy · UX architecture · Interaction design · Design system

Environment:

Multi-centre oncology hospital

Users:

Consultants · RMOs · Nurses · Front office · Billing · Pharmacy · Insurance

Focus:

Clinical workflows · Patient journey · Operational efficiency

The problem was not the UI

The EMR was organised around modules. But, the hospital operated around patients and workflows.

Existing EMR

Appointments

Clinical

Billing

IPD

Pharmacy

Insurance

PATIENT

Actual hospital workflow is

Patient arrives

Appointment

Registration

Consultation

Treatment decision

Treatment allocation

Procedure

Billing

Follow-up

Understanding the system before designing the interface

I initially mapped the system by department. But this created another problem: every department had its own view of the patient. I therefore shifted the model from department-centric navigation to patient-centric workflows.

Design principles that defined for the entire system

Patient before module

The patient journey should remain the primary context, rather than forcing users to think in terms of system modules.

Surface information at the moment of decision

Clinicians shouldn't have to navigate through multiple screens to understand patient history.

Reduce operational memory

The system should remember information that staff repeatedly enter or look up.

One system, different working modes

A consultant, nurse and front-office executive may work with the same patient but need different information hierarchies. operational memory

Design patterns, not isolated screens

New workflows should be assembled from reusable interaction patterns rather than redesigned from scratch.

Design decision #1 (Major)

Oncologist were required to reconstruct a patient's history from fragmented records.

The insight

A patient is not a collection of modules. Their treatment is a continuous journey.

So the decision was

Create a persistent Smart Patient Summary that acts as the contextual layer across the EMR.

Smart summary UI

Decision #2

From navigation-heavy to task-oriented workflows

Applicable modules

Appointment booking

Consultant availability

Bed allocation

Appointment management

Before

Find consultant

↓

Open directory

↓

Select centre

↓

Check schedule

↓

Return to bookingk

↓

Enter patient details

↓

Book

After Identifying Reality

Patient arrives

↓

Appointment

↓

Registration

↓

Consultation

↓

Treatment decision

↓

Treatment allocation

↓

Procedure

↓

Billing

↓

Follow-up

Rather than simplifying individual screens, I simplified the sequence of decisions required to complete the task.

Decision #3

Remove repetitive work from high-volume workflows

Designed to reduce repetitive data entry and minimise booking errors.

The priciple

Existing patient

↓

Recognise patient

↓

Retrieve existing information

↓

Only ask for new information

Book appointment flow

Decision #4

Bed allocation wasn't treated as a simple booking interface. It was modelled as a resource-allocation problem involving patient requirements, treatment duration and real-time availability.

Bed allocation flow

Decision #5

One calendar system, multiple working views

The treatment schedule is shared by multiple teams, but they don't use it in the same way.

A front-office executive may need to understand which patients are currently receiving treatment. A nurse managing a high patient volume needs to scan the schedule quickly. Another user may need to understand where each patient is located and how the treatment floor is occupied.

The treatment schedule is shared by multiple teams, but they don't use it in the same way.

What I decided

Instead of creating separate products or completely different workflows for each role, I designed a common treatment calendar with flexible views.

The underlying data remains consistent, while the way it is presented changes according to the user's task.

Instead of creating separate products or completely different workflows for each role, I designed a common treatment calendar with flexible views.

The underlying data remains consistent, while the way it is presented changes according to the user's task.

Patient-centric view

Larger cards provide more context when staff need to understand an individual patient's treatment.

High-volume view

Information density increases when the priority shifts from understanding each patient to quickly scanning a larger number of patients.

Bed occupancy view

Users can switch between understanding when treatment is happening and where patients are located, without leaving the same working environment.

Decision #5

Designing for a multi-centre, user base system

MOC wasn't a single-user application. The same product needed to support:

Multiple centres

Different appointment types

Homecare

Multiple departments

OPD

Short procedures

Multiple user roles

IPD

Different treatment workflows

Multiple centres

Multiple user roles

OPD

Homecare

Different treatment workflows

Multiple departments

Different appointment types

IPD

Short procedures

Multiple centres

Multiple departments

Multiple user roles

Different appointment types

OPD

IPD

Homecare

Short procedures

Different treatment workflows

Appointment card UI

Instead of designing separate experiences for each visit type, I established a common appointment model with contextual states.

Decision #6

Design system as infrastructure

FOUNDATIONS

Typography

Spacing

Colour

Grid

Iconography

CORE COMPONENTS

Buttons

Inputs

Cards

Tables

Tabs

Status

Navigation

DOMAIN PATTERNS

Appointment card

Patient summary

Bed card

Treatment timeline

Billing components

PRODUCT FLOWS

Booking

Clinical

IPD

Billing

Patient management

The design system wasn't only a visual consistency exercise. It became a mechanism for scaling the product across departments and workflows.

The decisions behind the design

CHALLENGE

Too much patient information

Complex appointment workflow

Multiple user roles

Dense clinical data

Multiple centres

Complex billing

DECISION

Prioritised contextual information

Reduced steps

Shared system patterns + role-specific hierarchy

Progressive disclosure

Reusable workflow patterns

Modular billing components

TRADE-OFF

Not everything visible at once

Advanced controls moved deeper

More initial architecture work

Some information requires interaction

Avoided centre-specific UI

More structured configuration

Outcome

The redesign wasn't about making an old EMR look modern. It was about restructuring how a complex hospital system represents patients, workflows, resources and responsibilities.

What this project changed in my approach

MOC reinforced an important principle in my product-design practice: when a product becomes complex, adding better screens rarely solves the underlying problem. The designer needs to understand the system behind the interface—people, workflows, information, dependencies and constraints—and then design the product around those relationships.

Next project