IPCMS · Case Study
UX Case Study

International Patient Care Management System

A revamped platform for the Department of Health, Abu Dhabi — coordinating the full journey of patients treated outside the UAE, across Local, Pre-Travel, Post-Travel and Follow-Up teams, hospitals, and doctors abroad.

Client
Department of Health, Abu Dhabi
Scope
BRD → wireframes → hi-fi UI → design system
Platform
Web, bilingual (English / Arabic)
Users
DoH staff · Hospitals & doctors · Service providers
IPCMS dashboard for a Local Medical Evaluator
01

Business Problem

International Patient Care (IPC) is the unit inside DoH that arranges treatment abroad for patients the UAE can't fully treat locally. A case — an episode — moves through three broad phases: pre-travel (evaluation, opinions, board decision, logistics), post-travel (treatment abroad, hospital & doctor coordination), and follow-up (after the patient returns). Along the way it touches Medical Evaluators, Case Coordinators, Authorizers, a Medical Board, hospitals and doctors abroad, and external logistics/travel service providers — more than a dozen distinct roles in total.

The problem

The legacy system wasn't built around this many roles or this much cross-organisation handoff. Requests, opinions, approvals and attachments lived in disconnected views, medical evaluators had no consolidated read on caseload, and external parties — hospitals, doctors, service providers — had no proper task queue of their own. The BRD's stated goal was blunt: simplify and modernise the system enough that every one of these roles could actually work faster inside it.

02

My Role

Sole UX/UI designer, working from a 6,000+ line Business Requirements Document covering 13+ personas and 19 request types, through to a documented design system ready for build.

  • 01BRD analysis — read the full requirements set (login, admin, episode registration, dashboard, task handling, reports, finance) and mapped it to a persona & navigation model.
  • 02Low-fidelity wireframing — hand-sketched the core task and episode-detail flows first, across the Hospital SPOC, treatment, and login journeys.
  • 03High-fidelity UI design — built the visual system and applied it to dashboards, task lists, episode detail views, and admin screens (Centre of Excellence).
  • 04Design system documentation — produced a standalone button library and full colour palette sheet (status, priority, department, and calendar colour tokens) for developer handoff.
  • 05Case study & handoff docs — this document, plus screen-level notes for the OutSystems/dev build.
Scale of the requirement

The BRD alone defines 13+ personas (Administrator, Local/Pre-Travel/Post-Travel Medical Evaluators & Case Coordinators, Authorizers, Board Secretary, Board Member, Hospital SPOC, Doctor, three types of Service Provider) and 19 request types. A large share of the design effort went into finding the handful of reusable patterns — task card, episode detail shell, request-history thread — that could carry all of that without becoming 13 different products.

03

Objectives

Taken directly from the BRD's project objectives, translated into design priorities.

01

Simplify a 13-persona system

Make one platform feel intuitive to Administrators, Medical Evaluators, Coordinators, Boards, hospitals and service providers alike.

02

Centralise the episode record

Every request, opinion, attachment, and decision against a patient episode in one place, with full history.

03

Support the full IPC lifecycle

Pre-travel, post-travel and follow-up phases handled as one continuous episode, not three separate systems.

04

Open the door to external parties

Hospitals, doctors, and service providers get their own scoped task queues instead of email-based coordination.

05

Real-time oversight

Dashboards with live counts, charts, and team-lead visibility instead of manual status chasing.

06

Boost productivity, not just add features

The BRD is explicit: usability and efficiency for everyday users, not feature checklist compliance.

04

User Personas

Four personas from the BRD's role table, shown here because they map directly to shipped screens. The full system defines well over a dozen roles in total.

S
Salman Farzee — Local Medical Evaluator
DoH · Internal

"I need to know my whole caseload's health the moment I log in — not after I've opened ten episodes."

Goals
  • See To Do / In Progress / Board Decision counts at a glance
  • Move an episode from evaluation to a recommendation quickly
Frustrations
  • No single view of caseload across special vs. normal cases
  • Hard to tell how old an episode is without opening it
R
Riyas — Local Case Coordinator
DoH · Internal

"Getting three doctors to weigh in on one opinion request shouldn't mean three separate email threads."

Goals
  • Coordinate SME/doctor opinions against one request thread
  • Track SLA and request status without leaving the episode
Frustrations
  • SME responses scattered across channels
  • No visual cue for which SME has or hasn't replied
A
Abdul Rahman — Hospital SPOC
External · Hospital

"I'm the single point of contact for every doctor in my hospital — don't make me dig for what's actually pending."

Goals
  • Triage new requests against SLA before doctors get overloaded
  • Act on behalf of any doctor at the hospital when needed
Frustrations
  • No system-side task list — historically ad hoc via phone/email
  • Hard to see patient context (diagnosis, reports) before responding
M
Mohammed Feroz — Administrator
DoH · Internal

"Hospitals and doctors change constantly — I need to onboard and retire them without a ticket to IT."

Goals
  • Maintain the Centre of Excellence hospital & doctor directory
  • Manage users, groups, boards, and knowledge articles centrally
Frustrations
  • Doctor/hospital data previously lived outside the core system
  • No consistent card format for comparing specialists
05

Journey Map

Mapped from the Hospital SPOC's point of view — an abroad opinion request landing in an external inbox, through to a closed loop the local team can see.

Stage 1

Request received

TouchpointMy Task Requests — To Do tab
Pain pointNo prior system-side queue — coordination happened by phone/email
Design responseA dedicated task list scoped to this SPOC's hospital only
Stage 2

Review patient context

TouchpointRequest detail — patient info, diagnosis, medical reports
Pain pointReports and history previously requested separately by email
Design responseDiagnosis, SLA, and attachments together on one screen
Stage 3

Coordinate with SMEs

TouchpointRequest History — threaded discussion
Pain pointNo shared record of which doctor said what, or when
Design responsePer-doctor threaded tabs inside one request history view
Stage 4

Submit opinion

Touchpoint"Enter your opinion" composer
Pain pointOpinions previously undocumented against the episode
Design responseOpinion becomes part of the permanent episode record
Stage 5

SLA close-out

TouchpointStatus moves to Completed; local team sees it instantly
Pain pointNo visibility for the local team on abroad response time
Design responseShared SLA countdown visible to both local & hospital sides
06

The Episode Lifecycle

Every screen in IPCMS is really a view onto one of six lifecycle stages a patient episode passes through — this became the structural spine for the whole system, the same way the Hospital SPOC journey above is one lens on it.

1

Registration

From TAMM, Source of Approval, or VPP team

2

Evaluation

Medical Evaluator starts evaluation, opens requests

3

Authorization

Local Authorizer approves, rejects, or amends

4

Board decision

Board Secretary & Medical Board Member decide treatment path

5

Treatment abroad

Hospital SPOC & doctors coordinate care

6

Follow-up & closure

Patient returns; episode closed with reason

07

Process

Phase 1

BRD analysis

Worked through the full Business Requirements Document — login, admin, episode registration, dashboard, task handling, team-lead features, reports, call centre, patient experience, and finance — to extract the entity model (episode, request, phase, persona) before sketching anything.

Phase 2

Low-fidelity wireframes

Sketched the highest-traffic flows first: the Hospital SPOC's task list and request detail, the treatment-phase episode view, and login — including a bilingual (English/Arabic) toggle from the very first login sketch, since that requirement came directly from the BRD.

Phase 3

High-fidelity UI & design system

Built out the DoH-branded visual system — aquatic green primary, a large semantic colour set for status/priority/department, and a documented button library — then applied it across dashboards, task lists, episode details, and the Centre of Excellence admin screens.

08

Low-Fidelity Wireframes

Hand-sketched exploration across the Hospital SPOC and treatment-phase flows, plus the bilingual login — rough enough that early reviews stayed about structure, not visual polish.

Sketch of Hospital SPOC My Task list
Sketch
My Task — Hospital SPOC
New / Active / Completed tabs with request cards for Abroad Opinion, Appointment, and Travel Fitness requests — establishing the card-based task pattern.
Sketch of Abroad Opinion Request detail
Sketch
Abroad Opinion Request — detail
Patient info, diagnosis, medical reports and a request-history thread with an opinion composer at the foot of the page.
Sketch of bilingual login screen
Sketch
Login — bilingual
"Welcome to the International Patient Care Portal," with an Arabic-language toggle in the top corner from the first pass — a direct requirement from the BRD, not a later addition.
Sketch of Patients in Treatment episode view
Sketch
Patients in Treatment
The treatment-phase episode shell — patient summary on the left, a tabbed record (Activity, Source of Approval, Attachments, Malaffi, Appointments) on the right — reused later for every episode-detail screen.
09

Before vs. After Wireframes

Sketch to shipped, for the two screens that anchor the Hospital SPOC's experience.

My Task Requests
Hospital SPOC
Before — sketch
Low-fidelity sketch of Hospital SPOC task list
Dashboard — hi-fi
Hi-fidelity My Task Requests screen
The card-per-request layout, tab structure, and column set (Patient, Gender, DOB, Case Type, Episode Type, Priority, Doctor/SME, SLA) carried straight through. Hi-fi added patient/doctor avatars and colour-coded episode-type chips (Royal, Special-MB) — small additions that make the queue scannable at a glance rather than requiring a read of every row.
Login
All roles, bilingual
Before — sketch
Low-fidelity sketch of bilingual login screen
Dashboard — hi-fi
Hi-fidelity dashboard, post-login
The split layout — brand story on the left, sign-in form on the right — and the Arabic-language toggle were both locked at the sketch stage and shipped unchanged in structure. Design decision: keeping the language toggle in the same top-corner position across every screen (not just login) so switching languages never requires re-learning where the control lives.
10

Key Screens

The rest of the hi-fi surface — dashboard, episode discussion, treatment record, and the Centre of Excellence admin area.

Local Medical Evaluator dashboard
Screen · Oversight

Dashboard — My Patient Episode Requests

Local Medical Evaluator

Five stat cards (To Do, In Progress, With MBM Queue, With MB Members, Board Decision) each split by Special vs. Normal case count, a monthly completion chart, and an "Episodes Last Updated" donut grouped by staleness (3 days / 1 week / 10+ days) — the BRD's requirement for "numbers of episodes mapped with each status" turned into something a Medical Evaluator actually scans each morning.

Special vs. Normal splitStaleness donutAppointment & task reminders
My Episodes detail view
Screen · Episode management

My Episodes — Detail View

Local Medical Evaluator

The episode shell the BRD calls for: patient header, evaluator/coordinator assignment, diagnosis fields, and a tabbed record (Activity, Episode History, Request History, Attachments, Malaffi, Appointments...) with a comment composer fixed at the foot of the page — reused, tab-for-tab, across every persona's episode view.

Multi-tab recordInline comment threadSLA countdown
Local Opinion Request discussion thread
Screen · Collaboration

Request History — SME Discussion

Local Case Coordinator

Directly answers the BRD's Local/Abroad Opinion Request requirement: a per-SME tab (Dr. Mohammed Aslam, Dr. Johnson, Dr. Amanda) inside one request, each holding its own threaded conversation, with the overall request status ("SME's Working on the request") visible above the thread — so a coordinator never has to guess who's replied.

Per-SME threadsShared request statusAvatar-led messaging
Centre of Excellence doctor list
Screen · Administration

Centre of Excellence — Doctor List

Administrator

The Admin's Centre of Excellence directory from the BRD, built as a card grid rather than a table — photo, name, specialty, years of experience, contact details, and hospital affiliation, with a VPP badge for Visiting Physician Program doctors. Hospital List sits one tab over, sharing the same card pattern.

Card-based directoryVPP badgeHospital ↔ Doctor linkage
11

Design System

Documented as standalone reference sheets for developer handoff — shown here in full since they're genuine project artefacts, not illustrative recreations.

IPCMS colour palette reference sheet
Primary palette (Red, Black, Aquatic Green #006871, Blue, Light Green, Light Brown), a 7-step Aquatic Green scale, secondary Blue/Grey/Brown ramps, and a large semantic set — case-type tags (Royal, Special, VIP, Normal), SLA Warning, status pairs (In Progress / Overdue / Completed, each with a background + text token), department, doctor, and calendar colours. Scroll within the panel to see the full sheet.
IPCMS button component sheet
Primary, secondary, outline, ghost, and icon-only button variants across default / hover / disabled states, plus toggle and radio controls — the full interactive-control vocabulary used across every screen in the system.
Status colour, in practice
Completed In Progress Overdue

Every list and dashboard in the product pulls from this same semantic set — a SPOC's request queue, a Medical Evaluator's dashboard, and a Team Lead's report all render "overdue" with the identical background/text pair, so status reads the same no matter which of the 13 personas is looking at it.

12

Design Decisions

Challenge
13+ personas can't mean 13 different UIs.
Reduced everything to three reusable shells — task/request card, tabbed episode detail, and threaded discussion — and reused them across Medical Evaluator, Coordinator, SPOC and Doctor views. Solution: a Hospital SPOC's task list and a Medical Evaluator's dashboard look related on sight, even with different data.
Challenge
One episode, three lifecycle phases, no re-entry of data.
The tabbed episode shell (Activity, History, Request History, Attachments...) stays identical whether the episode is in Local, Pre-Travel, or Post-Travel phase — only the available actions change, so handover between phases doesn't feel like moving to a new system.
Challenge
Medical opinions from multiple doctors need a shared record.
Built per-SME tabs inside one request thread rather than separate requests per doctor — Request History shows every opinion in context, with the overall request status computed from all three threads at once.
Challenge
External users (hospitals, doctors, service providers) needed their own front door.
Gave Hospital SPOC and Doctor roles a simplified nav (My Task Requests, Calendar, Help) instead of the full internal menu — a fraction of the surface area a Medical Evaluator sees, because their job is answering requests, not managing the system.
13

Challenges & Constraints

Government healthcare data, mixed authentication models, and a bilingual mandate all shaped what the design could and couldn't do.

Identity

Two authentication models

Internal DoH staff sign in via SSO; external hospitals, doctors, and service providers use email + password. Both had to feel native to the same login screen, not bolted together.

Language

Bilingual, English / Arabic

Arabic requires RTL layout mirroring, not just translated strings — a constraint that had to be designed for from the login screen onward, not retrofitted later.

Data sensitivity

Live clinical data via Malaffi

The product embeds Malaffi, Abu Dhabi's health information exchange, in-app — meaning real patient admission/discharge records render inside IPCMS, raising the bar on access control and on how much clinical detail surfaces at each role level.

Scope

19 request types, one system

Local Opinion, Abroad Opinion, Evaluation, Teleconsultation, VPP, Travel Fitness Form, Medical Clearance, Ticket Booking, Logistic Medical/Non-Medical, and more — each with its own fields, but all needing to fit inside one card-and-detail pattern rather than 19 bespoke screens.

14

Impact

IPCMS is a design-stage case study, not a post-launch report — these reflect what changed in how the work itself could be seen and coordinated.

13+ roles

Distinct personas served from three reusable UI shells instead of one-off screens per role.

19 → 1

Request types unified under a single card + detail + history pattern.

6-stage

Episode lifecycle made continuous across Local, Pre-Travel, Post-Travel and Follow-Up phases.

2 languages

English/Arabic supported from the first login sketch, not retrofitted after hi-fi.

The clearest win is giving external parties — hospitals, doctors, service providers — a real task queue for the first time, in place of phone calls and email threads. A Hospital SPOC opening "My Task Requests" now sees exactly what the DoH team sees on their side of the same request: same status language, same SLA countdown, same patient context. That shared visibility is what a cross-border care coordination system is actually for.

15

Reflection

IPCMS is a much bigger surface area than it first looks — a 6,000-line BRD and over a dozen personas can easily tempt a designer into building bespoke screens per role. The decision that held the project together was refusing that temptation: three shells (task card, tabbed episode detail, threaded discussion) carry the entire system, from an Administrator managing hospitals to a doctor abroad answering one opinion request. Designing the bilingual login first, rather than treating Arabic as a translation pass at the end, also paid off — RTL considerations that would have been expensive to retrofit were baked in from the first sketch.