CLS Healthcare · Clinical Pathology · Case study

Clinical Pathology Results Review

Designing and validating a results-review workflow for lab professionals moving off two decades of legacy-system habits. The work was grounded in Jobs-to-Be-Done research and journey mapping with a Client Advisory Group of five client laboratories, then evaluated through prototype design and moderated sessions.

01 · Executive summary

Replacing a legacy system used for decades, not just adding another workflow.

Clinical Pathology results review was being brought into CLS as part of a larger effort to expand the platform from environmental testing into healthcare. The new experience had to replace a legacy system used by laboratory technicians for decades, while addressing a review process that required clicking through every auto-verified result with no way to configure review behavior by department.

Research with a Client Advisory Group of five laboratories surfaced recurring problems with result visibility, worklist organization, historical context, and configurable review behavior. Journey mapping and Jobs-to-Be-Done research translated those findings into the CLS Results Review prototype, which was evaluated in two moderated sessions with practicing lab professionals.

Results Review has since been released, and its widget panel, a pattern the prevailing view inside Clinisys considered dated, was later adopted by the Anatomic Pathology initiative.

02 · Approach

Discovery first, then definition, then validation.

Contributions

Attended the Client Advisory Group and built the journey map from their recurring themes
Created the Jobs-to-Be-Done canvas and led four workshops with the Product Owner, Business Analyst, and an internal SME
Designed the CLS Results Review prototype: backlog, results table, and widget panel
Planned and moderated two evaluation sessions with practicing lab professionals
Synthesized 10 evidence-based findings spanning query management, worklist organization, verification, and specimen visibility

Method

The journey map and the JTBD canvas established the design principles behind the CLS Results Review prototype, which two moderated sessions then evaluated. Both were scoped as usability testing but shifted into open, exploratory feedback once it was clear the participants had limited hands-on CLS experience.

03 · Context & problem

A patient-centered experience layered onto a batch, task-based core.

CLS was originally built as an environmental Laboratory Management System: task-based, where work runs in batches, suited to testing pond water or soil samples rather than reviewing an individual patient's results one specimen at a time, the model healthcare labs run on. The CLS Expansion Initiative set out to build proper healthcare support into CLS without changing the batch architecture that environmental work still depends on.

For healthcare clients, this replaces a DOS-based, "roll and scroll" legacy system some clients had used for over twenty years. Results Review was also heavily keyboard-dependent, and it ran into the Grid-versus-Table gap described in Keyboard Accessibility & Interaction Strategy: it was built as a Table but needed to behave like a Data Grid.

Research objectives

Define the technician's complete job, from entering the backlog through releasing a result.
Map how the current-state Resulting workflow actually behaved, grounded in the Client Advisory Group.
Evaluate whether the resulting prototype held up for lab professionals transitioning off years of legacy-system habits.

04 · Research: journey map

Mapping the workflow as it actually happens, from a Client Advisory Group of five labs.

The Client Advisory Group met regularly throughout the project, spanning technologists, supervisors, lab managers, administrators, and pathologists. I attended, documented observations, and synthesized the recurring themes into the journey map, reviewing and updating it in weekly working sessions with the Product Owner, Business Analyst, and an internal Subject Matter Expert.

Key discovery

What started as a request to improve visibility into failed auto-verification results expanded into a broader workflow problem spanning worklist organization, result context, review, and handoffs. View the full map ↗ · Read the full report ↗

01 · Access resulting backlog

Technicians filter by instrument, department, and date every time (filters that don't persist), and can't see why a result failed auto-verification until they open it.

02 · Review result record

Runs, historical results, QC, scattergrams, and flags exist but are spread across separate locations; comparing multiple runs adds complexity.

03 · Manual differential (optional)

Technicians need to document findings without losing their place in the Resulting workflow.

04 · Supervisor review (optional)

Supervisors need clear ownership of assigned work, supporting information without extra digging, and a clean handoff back.

05 · Research: Jobs to Be Done

The job: review a specimen test panel and release the complete result.

I planned and facilitated four Jobs-to-Be-Done workshops with the Product Owner, Business Analyst, and an internal SME, using Client Advisory Group findings to define who performs the job, what starts and completes it, and which rules vary by client.

Key discovery

Three requirements carried straight into the first prototype: table configurations had to persist across sessions, active and historical results needed to be presented together, and review and release had to adapt to each client's configured rules rather than assume one workflow fit every laboratory. View the full canvas ↗ · Read the full report ↗

What workshops surfaced

Canceled, rejected, and stale items were clouding the backlog view.
A current result needs interpreting against every other run for the specimen, not just the latest value.
A questionable result needs paths to rerun, change dilution, switch instruments, or send for additional review without losing the original.

06 · Design principles

Six principles, distilled from the journey map and JTBD research, guided the prototype.

Preserve user context

Technicians shouldn't lose their place, filters, or train of thought moving between the backlog, a record, and back again, including through manual differential or supervisor review handoffs.

Reduce repetitive interactions

Resulting happens continuously through the day; the same filtering and setup shouldn't repeat every time.

Surface information early

Why a result failed auto-verification should be visible from the backlog, not discovered after opening the record.

Support decisions in one workspace

Instrument runs, historical results, QC, scattergrams, and flags should live in one place.

Improve prioritization visually

What needs attention first should be obvious at a glance, not something technicians have to work out themselves.

Support configurable workflows

Auto-Post, dashboard widgets, and review processes vary by client; the workflow needs to flex rather than assume one setup fits every lab.

07 · Design & validation

Two moderated sessions, three participants, drifting from scripted testing into open feedback.

Two moderated sessions evaluated an earlier round of the prototype, grouping supporting information into a fixed sidebar of always-visible panels rather than the modular widgets that came later. Both sessions were originally scoped as usability testing but shifted into open, exploratory feedback once it was clear none of the participants had much hands-on CLS experience. Read the full report ↗

Early Review Sample wireframe with fixed info sidebar

Query & worklist management

Shared, admin-managed queries were preferred over each user building their own.
Worklists need status-based grouping (new vs. pending vs. smear review).

"Most of us are generalists working across departments. Simple filters might be more practical than each member of the team building their own queries." P1, Session 1

Verification & critical results

Clicking through every auto-verified result was called out directly as unnecessary friction.
Critical results need a call-log system tied to individual results, with canned text for consistency.

"Right now, the legacy system requires clicking through every auto-verified result. I'd love a system that skips those unnecessary steps." P1, Session 1

Context & continuity

Inline historical results were called out as a genuine improvement over switching systems to look something up. Trend graphing and cross-instrument, same-patient grouping of critical results would reduce the risk of missing clinically significant patterns.

"If an analyzer initiates a rerun, could the system mark it as 'in progress' to prevent premature review?" P2, Session 2

10evidence-based findings

6design principles

3evaluation participants

4journey-map stages

08 · The prototype

A widget panel nobody thought would work, until clients saw it.

The final prototype: the backlog analysts triage first, the results table for a single record, and the same table with the right-side widget panel (condition codes, outstanding tests, call log, additional information, comments) open. The backlog stays true to CLS's batch/task structure, while opening a single result shifts into a patient-centered workspace built around one specimen at a time. Read the full report ↗

CLS Results Review results table comparing two runs

CLS Results Review with the widget panel open

Reviving a pattern nobody wanted

The prevailing view inside Clinisys was that widgets were dated. I advocated for the pattern anyway, drawing on an earlier Clinisys remote-review application where it had worked for pathologists, then modernized it into the library Results Review shipped with. Read the widget decision report ↗

09 · Outcome

Released, rolling out in phases, and influential beyond its own scope.

Results Review shipped, but full adoption is still rolling out: clients moving off the legacy system need CLS implemented and their data migrated first, typically a 9 to 12 month process, while clients already on CLS received the new functionality in smaller phased releases to test and iron out issues.

Next steps

Run a follow-up round with hands-on CLS prototypes, since both sessions drifted into open-ended feedback.
Validate dashboard and visualization concepts, like trend graphs, against an actual design.

The research continued

Clinical Microbiology Setup & Results was researched in parallel, and the two overlapped around the resulting experience, letting each concentrate on what was genuinely different.

The clearest evidence of impact

Client reception reinforced the widget-panel decision. Demonstrations drew a markedly strong response, and the approach proved influential beyond this one project: Anatomic Pathology, a separate CLS initiative, restructured its own workflow to incorporate the same widget-based approach after seeing Clinical Pathology succeed.

Next case studyClinical Microbiology Setup & Results →