Case study 03

LabSoluvia — Medical Laboratory Management Platform

Healthcare · Lab Management · SaaS · Diagnostics

A multi-tenant laboratory information system for small and mid-sized diagnostic labs. It takes a lab from registering a patient to a report in their hands: orders and billing, sample labels, fast result entry with automatic flagging, optional pathologist verification and reports sent by SMS, plus the admin tools to run it without a developer.

My role: Product designer & UX researcher: research, UX/UI, design system
Platform: Installable web app (PWA) for desktop, tablet and phone
Users: Front-desk staff, lab technicians, pathologists, lab admins, and the patients who receive the reports
Scope: Registration to delivered report, plus catalog, templates, roles, branches and audit

Minutes → seconds to find a patient’s history, estimated against the old Word-and-folder routine

The challenge

Small labs ran on paper registers, Word templates and a local folder for each patient. The biggest losses were errors (typing values by hand, missed critical results, the wrong reference range) and turnaround time (finding old reports, patients queuing or phoning to collect them). The work was to shorten both without adding steps for the people at the bench.

What the product had to do

Cut the time from sample to trustworthy result, without adding steps for the technician.
Make abnormal and critical values impossible to miss or to skip past unacknowledged.
Keep every past report exactly as it was issued, even when the test catalog changes later.
Serve many labs from one platform, each fully isolated, with branches, roles, and an audit trail.

Design process

In a lab the cost of a mistake is high, so I designed around the sample’s journey and the moments where an error could reach a patient.

Follow one sample end to end

Mapped the journey from registration to the patient’s phone, and how reports were made in Word and filed in folders.

Interviews with technicians, pathologists and front-desk staff
Workflow mapping from sample intake to report delivery

Find where errors and waiting live

Looked for the handoffs where a value could be mistyped, missed or left waiting.

Error and rework analysis across handoffs
Transcription, missed critical values, wrong ranges, report collection

Design the shortest safe path

Built the flow around the order statuses: register, bill, collect, enter, verify, send.

Order, result-entry, verification and report flows
Component library, dark mode and mobile navigation

Test the risky moments

Put the moments that matter most in front of lab staff first.

Usability testing of result entry and report review
Critical-value acknowledgement

Hand over with the gaps named

Worked with engineering through build, and wrote down what was still missing.

Seeded reference ranges flagged as placeholders
A list of design-review gaps for the next round

Pain points

History scattered across local folders

Finding a patient’s past reports meant searching folders and opening several Word files, so comparing results over time was rarely done.

Duplicate patient records

The same patient could be registered more than once, splitting their history. Some patients also don’t know their date of birth.

Every value checked against a range by eye

Technicians compared each value with a reference range by hand, which is slow and easy to get wrong.

Results lost when the Wi-Fi drops

In clinics with patchy internet, a dropped connection could lose the values a technician had just typed.

Critical values nobody acted on

A critical result buried in a long report is a patient-safety risk, not just a usability flaw.

Old reports that changed after the fact

Edit a reference range later and an old report could look different, which erodes trust in every report.

Patients queuing or phoning for reports

Collecting a paper report meant coming back to the lab, and the front desk answered “is it ready?” calls all day.

Test menu changes needed a developer

Adding a test, a range or a package was a technical job instead of something the lab could do itself.

Discounts given freely at the counter

Without a rule, any staff member could reduce a bill, and building a package order by hand was slow.

UX research methodology

Stakeholder interviews with lab technicians, pathologists and front-desk staff
Review of the existing routine: reports typed into Word and saved in one local folder per patient
End-to-end workflow mapping from sample intake to report delivery
Error and rework analysis across handoffs
Usability testing of result entry and report review flows

Key research insights

The biggest losses were errors and turnaround time, not features: transcription mistakes, missed critical values, wrong ranges, and waiting for reports
Manual handoffs between intake, testing and reporting were the main source of rework and delay
A patient’s history was spread across local folders, so comparing results over time was rare
Technicians needed fast, low-error result entry; pathologists needed clear review and sign-off
Patients and referring clinics wanted timely, trustworthy reports without calling the lab

Who we designed for

Tharindu — Lab technician

Enters results for a steady stream of samples and needs speed without losing accuracy.

Goals

Enter results quickly with minimal clicks
Spot abnormal values without checking ranges by hand
Know which samples are waiting

Frustrations

Comparing values to reference ranges by eye
Re-typing patient and test details
No clear sign of what’s urgent

Dr. Sanduni — Pathologist

Reviews and signs off results, with particular attention to critical and unusual values.

Goals

See abnormal and critical results first
Verify with the context of past values
Sign off with a clear audit trail

Frustrations

Critical values buried in long reports
No view of how a patient’s results have changed
Unclear who entered or changed a value

Piumi — Front-desk receptionist

Registers patients, builds orders, takes payment, and answers “is my report ready?” calls.

Goals

Register a patient and create an order quickly
Take payment and print sample labels in one flow
Tell patients when their report is ready

Frustrations

Entering the same patient details more than once
Switching between billing and lab tools
Constant status calls from patients

Design decisions

Register without slowing the counter

The problem. The same patient could be registered twice, splitting their history, and some patients don’t know their date of birth.

The decision. A duplicate check runs at registration using a match key built from name, date of birth or age, and phone. An approximate age is allowed when the date of birth is unknown, so registration is never blocked.

Duplicate check on registration
Approximate-age fallback for walk-ins

Packages and discounts that follow the rules

The problem. Building a package order by hand was slow, and discounts were given freely.

The decision. Choosing a bundle adds every test in it and applies the saving as a discount. Discounts above a threshold (10% by default) need admin approval, and flat discounts are converted to a percentage so there is no loophole.

One click per test package
Admin approval above the threshold
Invoice and order numbers run per branch, e.g. COL-000123
Labels and receipts printed from the order

Result entry that flags as you type

The problem. Technicians compared every value with a reference range by eye, which is slow and error-prone.

The decision. Each value is flagged Normal, Low, High or Critical as it is typed, in the browser and again on the server, using the range for the patient’s sex and age. Derived values, such as the cholesterol to HDL ratio, calculate themselves.

Range chosen by sex and age
Checked in the browser and on the server
Calculated values fill in automatically

Keyboard-first entry that saves itself

The problem. Data entry was keyboard-heavy, a forgotten Save button meant lost work, and a dropped connection lost results.

The decision. Enter moves to the next field and each field saves itself after half a second, so there is no Save button. A failed save is queued in the browser and resent when the connection returns, with the status shown as saving, saved or queued.

Enter moves to the next field
Autosave after 500 ms
Offline queue with a visible status

Critical values can’t slip by

The problem. A critical result buried in a long report is a patient-safety risk.

The decision. A critical result opens a blocking dialog, and the technician must write an acknowledgement note before the order can be completed. It is recorded with who and when. Many small-lab systems skip this.

History is never rewritten

The problem. Editing a reference range could silently change an old report, and there was no record of who did what.

The decision. Each result keeps a copy of the range used when it was entered, so later changes never alter what was issued. Each result records who entered it and when, who verified it and when, and a full audit log sits behind it.

Reference range stored with each result
Who and when for entry and verification
Audit log

Sign-off that fits the lab

The problem. A one-person lab and a 20-person lab cannot share one rigid verification workflow.

The decision. Verification can be switched on or off per lab, and technicians can be allowed to verify their own work, so both kinds of lab use the same product without fighting the workflow.

Reports patients can actually use

The problem. Patients queued or phoned for reports, SMS could fail silently, and printed reports were hard to trust.

The decision. When the report is ready the patient gets an SMS with a secure link. The message carries only the order number and the link, with no medical details, and the link expires after 72 hours by default. A failed send is retried once, then goes to a “needs attention” queue. Printed reports carry a QR code, and trend charts show a value across visits.

SMS with no medical details in it
Link expires after 72 hours; the public page is rate-limited
Retry once, then a staff queue
QR code on printed reports
Trend chart per test value

Control without a developer

The problem. Changing the test menu, the roles or the branches was a technical job, and shared counter computers were a risk.

The decision. Admins edit tests, values, reference ranges, report templates and bundles themselves. A per-lab screen of role-by-permission checkboxes replaces hard-coded roles, scoped to a branch or the whole organisation. Sessions time out after 15 minutes and accounts lock after repeated failed logins.

Editable tests, ranges, templates and bundles
Role and permission matrix
Per-branch prices and a shareable patient registry
15-minute session timeout

Results

Find a patient’s past reports: Minutes → seconds
Compare a value over time: Trend chart
Enter results and produce a report: Faster
Get the report to the patient: Automatic
Numeric values flagged automatically: Enforced
Critical results completed without an acknowledgement: Enforced

How I measured

The figures are estimates of the old routine (reports typed into Word, one local folder per patient). They have not been timed in a real lab yet.

Planned timing study: time 20–30 cases of each task with a stopwatch in the old workflow and again in LabSoluvia at one lab, and report the median, not the average.
Ongoing numbers the app already records: turnaround time, the delay between entry and verification, critical-value acknowledgement rate, SMS delivery success, and digital versus printed reports.

Limits of the data

Estimates, not measurements.
The automatic-flagging and critical-value rows are rules the design enforces, so they describe behaviour, not an outcome.

My role and process

I was the product designer and UX researcher on LabSoluvia. I mapped the sample’s journey from registration to SMS with technicians, pathologists and front-desk staff, and studied how reports were being written in Word and filed in local folders. From that I designed the order, result-entry, verification and report flows, plus a shared component library, dark mode and mobile navigation, and worked with engineering through the build. The seeded reference ranges are placeholders and need review by a qualified lab professional before any real patient use.

Tools and skills: Figma, Design system, Prototyping, Usability testing, Information architecture

What I'd do next

Add a delta check that flags a sudden change from the patient’s last result, since the trend data already exists. Replace the browser prompt used to mark a value N/A with a dropdown of standard reasons, such as haemolysed or insufficient sample. Add barcode scanning to open an order or a sample, referring-doctor and corporate billing, and WhatsApp as a report channel. Show clearly which reference ranges are still unreviewed defaults until a pathologist signs them off. Then run the timing study to replace the estimates above.