Clinical Pathology Results Review

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 challenge was not simply adding another workflow. The new experience had to replace a legacy system used by laboratory technicians for decades, while addressing a review process that required them to click through every auto-verified result and provided no way to configure review behavior by department.

I used the Client Advisory Group to understand how laboratories reviewed results in practice and built a journey map from the recurring themes across those discussions. I then created a Jobs-to-Be-Done canvas and led four workshops with the Product Owner, Business Analyst, and internal Subject Matter Expert to define what technicians needed to accomplish during review and where the existing process was working against them.

Those findings shaped the CLS Results Review prototype. I evaluated the design in two moderated sessions with three practicing laboratory professionals, producing 10 evidence-based findings and validating core decisions, including flag-based verification and inline historical results. Because participants had limited hands-on experience with CLS, the sessions evolved beyond the original usability-testing script into a more exploratory evaluation of the workflow and interaction model.

The prototype’s widget panel became the most consequential decision in the project. Widgets were widely viewed inside Clinisys as an outdated pattern, but I advocated for reviving and modernizing the concept, and client demonstrations of the panel drew a markedly strong response. The approach went on to shape direction beyond this project: Anatomic Pathology, a separate CLS initiative, restructured its own workflow to adopt the same widget-based pattern after seeing Clinical Pathology succeed.

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 one specimen at a time, the model healthcare labs actually run on. 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 an earlier web-based application that let pathologists work remotely by connecting them to their in-house legacy system, and pathologists responded well to its specialized widgets, which let them review information and complete tasks without leaving the report they were writing. That application stayed confined to remote review for pathologists and never extended into other roles or disciplines, but the widget pattern itself proved out. That precedent carried directly into how Clinical Pathology Results Review's own widget library was designed.

Reviving that pattern wasn't an easy sell. The prevailing view inside Clinisys was that widgets were dated, a relic of early-2000s interface design, not a serious pattern for a modern product. I advocated for it anyway, and rather than reusing the earlier concept as it was, I modernized it and packaged it into the library Results Review shipped with.

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.

Client reception reinforced that direction. Demonstrations of the widget panel and the results-review workflow drew a markedly strong response from clients, 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.

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.

That influence isn't hypothetical; it's already happened once. The widget-based approach built for this project met real internal resistance as a dated pattern, but it proved itself through client reception strong enough that Anatomic Pathology restructured its own workflow to match it. That's the clearest evidence of how far this project's impact reached beyond its own scope.