Clinical Pathology Results Review

Clinisys was expanding CLS — a task-based Laboratory Management System originally designed for Environmental laboratories — to support healthcare, and needed a workflow for the Resulting stage of Clinical Pathology: the post-analytical phase of the testing process, part of a broader initiative to consolidate the company's many laboratory products onto a single platform. It had to replace a legacy system's manual, click-heavy review process and work for lab technicians who'd built their instincts around a different system, some for over twenty years. The existing legacy experience required clicking through every auto-verified result and offered no way to configure review behavior by department.

As UX Researcher and Designer, I attended the Client Advisory Group and built the journey map directly from their recurring themes, created a Jobs-to-Be-Done canvas, and led four JTBD workshops with the Product Owner, Business Analyst, and an internal Subject Matter Expert to define the technician's job. That research shaped the CLS Results Review prototype, which two moderated evaluation sessions with three practicing lab professionals then put to the test.

The evaluation sessions produced 10 evidence-based findings and validated several of the prototype's core decisions, including its flag-based verification model and inline historical results. What began as scripted usability testing shifted into open, exploratory feedback once it became clear the participants had limited hands-on CLS exposure.

CLS was originally built as an environmental LMS (Laboratory Management System), a task-based system where work runs in batches, suited to testing pond water or soil samples rather than reviewing an individual patient's results. Healthcare labs run on an LIS (Laboratory Information System) model instead: patient-centered, with results reviewed one specimen at a time. Some disciplines, like microbiology, straddle both worlds. The same instrument can process a blood culture or an environmental sample, so a few clients had already been running healthcare work through CLS's environmental, task-based screens, and the fit was inefficient. Many of those healthcare clients had started out as environmental customers and expanded into healthcare as a growth opportunity, especially during COVID. The CLS Expansion Initiative set out to build proper healthcare support into CLS: a patient-centered results-review experience layered onto the same task-based core, without changing the batch architecture that environmental work (and shared disciplines like microbiology) still depend on. It was one piece of a broader push to consolidate the company's many separate laboratory products onto a single CLS platform.

The Clinical Pathology Results Review functionality evaluated here covers one stage of that initiative: the Resulting step, the post-analytical phase of testing, not the complete healthcare experience. It's newly built, not a redesign of an existing CLS screen, because no patient-centered review experience existed in CLS before it. For healthcare clients, it replaces one of several legacy products the company was consolidating onto CLS, a DOS-based, "roll and scroll" system some clients had used for over twenty years, predating the company's acquisition of the platform that became CLS. Analysts now navigate and filter results, verify flagged entries, and manage pending tasks from a backlog page instead. This study asked whether that new workflow held up for lab professionals who'd spent years, in some cases decades, inside that legacy system's habits.

Task completion wasn't the only goal. The bigger question was whether CLS matched the terminology, review pace, and organizational habits analysts rely on daily, for people transitioning off a legacy system rather than starting fresh.

Discovery ran on two tracks. The Client Advisory Group fed the journey map I built, showing how the current workflow actually behaves. Separately, four JTBD workshops with the Product Owner, Business Analyst, and an internal Subject Matter Expert defined what technicians needed from the job itself. Together, these two tracks surfaced three recurring problems: repetitive navigation, decision-making information scattered across multiple sources, and exception workflows that interrupted the primary process instead of integrating with it. Those problems became the design principles below, which shaped the CLS Results Review prototype that two rounds of usability testing then evaluated.

Eight principles, distilled from the Jobs-to-Be-Done and journey-mapping research (including evidence from the Client Advisory Group), guided the CLS Results Review prototype design.

The CLS Results Review prototype

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, grouped by instrument, department, and priority, while opening a single result shifts into a patient-centered workspace built around one specimen at a time. That split let Results Review sit on top of the existing task-based core without requiring CLS to change it.

The widget panel wasn't a new idea. Clinisys had built a web-interface application for the legacy system, starting with Anatomic Pathology, and pathologists responded well to the specialized widgets that let them review information and complete tasks without leaving the report they were writing. Performance problems were severe enough that the application never expanded past Anatomic Pathology into other disciplines, but the widget pattern itself proved out. That precedent carried directly into how Clinical Pathology Results Review's own widget library was designed.

Left to right: Backlog / batch triage · Multi-run result comparison · Result review with widget panel. Click to enlarge.

Widget Library

The project delivered 10 evidence-based findings, eight design principles, and a set of validated design decisions: the concrete outputs this research produced for the product team to act on. Results Review has 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 given how large and complex these systems are; clients already on CLS received the new functionality in smaller phased releases instead, to test and iron out issues before wider implementation.

Two moderated sessions and monthly Client Advisory Group meetings throughout the project pointed the same direction: CLS's backlog-based review model and flag-driven verification are directionally right for users moving off the legacy system's manual, click-heavy workflow. But adoption depends on giving departments control over refresh behavior, worklist organization, and query management, rather than enforcing one fixed configuration.

The most urgent gaps to address as rollout continues are compliance-adjacent: call-log linkage and specimen-condition visibility. And because both sessions drifted from usability testing into open-ended feedback, these findings are directional rather than conclusive. A follow-up round with hands-on CLS prototypes would help validate the resulting design changes.

Results Review is scoped to one stage of the testing process, the post-analytical phase, not the complete healthcare experience CLS is expanding to support, but it's also part of a broader consolidation still underway across the company's other products. How well it lands for users transitioning off decades of legacy habits will likely shape the approach for the workflows and products still making that same move.