Clinical intelligence platform / Case study

Turning scattered medical records into clear clinical decisions.

I rebuilt a doctor-facing workspace around one practical question: what does the clinician need to understand and do next?

Product
Clineo Health OS
Role
Product designer
Timeline
Aug 2025 to Feb 2026
Users
Doctors
Scope
Audit, UX, UI, prototypes, testing
Clineo Today worklist ordered by clinical priority
Fig. 01 The home screen became a clinical worklist. Each row keeps the patient, concern, urgency, and next action aligned.

New product name / fictional patients / local-only data / no client service connected

01

What I inherited

The product had grown in Bubble.io before the team began moving it to React. It could already collect records, extract clinical data, and generate reports. But the interface had accumulated the kind of debt that makes a capable product feel slow and difficult to trust.

The staging environment repeatedly timed out on everyday create, search, and pagination actions. I cannot prove Bubble itself caused every delay, but the experience was slow enough to interrupt basic review work.

20+

Open UI/UX issues

The migration carried a visible backlog of layout, interaction, and consistency problems.

3+

Interactions to one graph

There was no useful trend signal until a doctor opened each biomarker and changed tabs.

48

Button variants

Similar actions looked and behaved differently across the product.

86

Documented colours

The visual system had more options than the interface could use consistently.

Internal product audit and migration records / January to February 2026

The real problem was the interaction debt

A complex patient can arrive with years of labs, medications, diagnoses, procedures, and scanned reports. The information exists, but it is spread across formats and screens. The doctor still has to assemble the story while making a decision.

The interface had the same problem. Each module could display its own data, yet the full workflow did not make priority, safety, chronology, and evidence feel connected.

01 / Records

Evidence arrived in pieces

PDFs, images, lab results, and historical notes all carried part of the clinical picture.

02 / Interface

Every module felt separate

A doctor could find the data, but moving between areas made the story harder to follow.

03 / Action

Some workflows stopped early

An alert or button could appear without showing what changed after the doctor acted.

The job was to make the next decision clear without hiding the evidence behind it.
Patient directory with profile images, clinical identifiers, and view actions
Fig. 02 The patient directory gives each person a recognisable identity while keeping clinical identifiers and actions easy to scan.
02

How I framed it

I stopped treating the home screen as another dashboard. I used four questions to decide what belonged in the first layer and what could wait.

  1. What needs my attention now?
  2. What patient context can I not miss?
  3. What changed over time?
  4. What evidence supports the next decision?

I reviewed the existing screens, traced incomplete actions, compared clinical interface patterns, and tested the rebuilt flows in the local React app. Where I did not have clinical usability data, I treated the outcome as a design direction rather than a proven impact.

Evidence rule: this case study only reports changes visible in the portfolio build and its test suite. It does not claim clinical accuracy, adoption, or time saved.
03

The product decisions

The same rule guided every screen: compress the signal, then let the doctor expand the context and source evidence.

Decision 01

Make the home screen a worklist

The original cards were too wide and slow to scan. I changed the page into a compact queue, ordered by clinical priority.

Repeated fields now stay in columns. Patient photos help recognition, while text and status labels carry the clinical meaning.

Notification inbox with aligned icons, patient context, priority, and follow-up actions
Fig. 03 The notification inbox uses the same triage logic: aligned signals, enough patient context, and one clear follow-up action.

Decision 02

Keep safety context in one stable place

Patient identity and allergy status now begin every patient workflow. The main action sits with the page heading, and the safety area no longer floats at the edge of the layout.

The same structure carries into medication review, so the doctor does not have to relearn where critical context lives.

Patient overview with identity, allergy safety context, attention items, and clinical summary
Fig. 04 Overview starts with identity and safety, then moves into attention, context, and the next decision.
Medication review using the same patient identity and allergy safety structure
Fig. 05 Medication review keeps the same patient header and makes the review action visible at the top.
Medication review dialog with dose, schedule, indication, and three required safety checks
Fig. 06 The review cannot be completed until the doctor confirms the dose, indication, and allergy check. The action now has a real finish state.

Decision 03

Make time feel continuous

The first timeline used separate date blocks. It looked tidy, but the dividers interrupted the chronology. I rebuilt it around one vertical spine.

The date is now part of each event. The doctor can read down the history without cross-referencing a detached column.

Continuous vertical clinical timeline with dates attached to medical events
Fig. 07 One uninterrupted spine preserves the sequence while filters narrow the type of event.

Decision 04

Bring the signal closer to the list

Seeing the direction of one biomarker originally took three interactions. The portfolio build brings the latest result and direction into the list.

Before / 3 interactions

Open item → switch tab → open graph

Demo / 0 interactions

Latest result + direction in the list

Labs and trends interface showing latest biomarker results and direction in the list
Fig. 08 The primary list shows the latest result and direction. A deeper comparison graph remains a proposed next layer.

Decision 05

Show review state before sharing

A generated medical report still needs clinical judgement. The list makes processing, review, and completion visible instead of treating generation as the finish line.

The public case study does not reproduce source report content. It shows the workflow and keeps sensitive-looking evidence out of the portfolio.

Clinical reports list with processing, review, and completed states
Fig. 09 Review state stays visible in the list so report generation never looks like automatic clinical approval.

Decision 06

Make every action finish the job

Several actions used to end with a generic toast. In the local demo, acknowledgement, review, notes, and restored attention items now change the visible state.

Source records open from the table, and Settings changes the local interface without an account, password, or external service.

Medical records table with source document and review actions
Fig. 10 Source evidence stays one clear action away from the medical-record table.
Local-only Settings screen with profile, notification, density, and text controls
Fig. 11 Settings uses one compact shell, and every control changes the local portfolio experience.
Original medical record viewer with document preview, source metadata, and close control
Fig. 12 The original-record viewer preserves source context in a focused document stage, so the doctor can verify extracted data without losing the patient workflow.
04

The report was the end product

The platform was designed to move from scattered source records to one clinician-reviewed health report. That report had to carry the evidence, surface the important findings, and still make it obvious that a doctor was responsible for the final interpretation.

I explored eight report directions and used a 28-point review checklist. The professional direction below became the clearest end-to-end expression of the product: summary first, trends and detailed results second, then recommendations and follow-up.

Interactive report prototype
Scroll inside the report Open full report
Artifact / Final report A scrollable, fictional report prototype showing how extracted records become a reviewable clinical narrative.
05

What changed

By the end of the project, the product had moved from disconnected Bubble screens to a reusable React system built around one doctor workflow. The work connected patient review, clinical records and report generation instead of treating them as separate tools.

10 Product areas designed

Seven clinical modules plus patient management, billing and onboarding.

28 Checks in the CHR framework

A repeatable quality bar for structure, graphs, evidence and clinical readability.

26 Platform documents

Five sections that gave design and engineering a shared product reference.

Also reported by the project: reusable React layouts and closer design-to-code collaboration saved roughly 50% of development time. The original calculation was not available in the reviewed archive, so this remains a team estimate.
06

What the team said

The work moved quickly, but the feedback I value most was about the quality of the thinking and how closely design and implementation stayed connected.

“Outstanding job! In just one week, it felt as though we had been working together for over a month.”
Jasper MiddendorpEngineering Lead, N1.care / shared over Slack
“Dhrumil is an exceptional UI/UX designer and Framer developer with meticulous attention to detail. He delivered expertly crafted, highly interactive designs that were extremely thoughtful from a usability standpoint.”
Jean-Yves SireauFounder and CEO, N1.care / excerpt from Upwork
07

I stopped designing pages and started designing decisions

That changed how I chose components, wrote labels, positioned actions, and judged density. A clean page still fails when the next decision is unclear. A working button still feels broken when nothing visible changes.

The most useful design move was often simple: keep safety context stable, attach dates to events, align repeated fields, and show what happened after an action.

End of case study / Clineo Health OS Talk about a project