Requirements Engineering in the lab – LIS as a success factor

Outdated Laboratory Information Systems (LIS) slow down lab operations: parameter configurations have grown organically over time, domain knowledge resides in people’s heads or Excel sheets, and compliance requirements are increasing. A simple system replacement won’t suffice. Requirements Engineering (RE) ensures that the new LIS truly supports operational workflows – through precise requirements gathering, clear documentation, early validation, and structured requirements management. The following fictional case study illustrates how a Swiss lab accelerated its LIS transition with systematic RE – ensuring sustainable digital transformation.

When Labor Helvex AG celebrated its 20th anniversary in spring 2023, the mood was mixed. On one hand, operations were running smoothly: over 3,000 samples processed daily, seamless workflows, and a dedicated team. On the other hand, it was clear that the core system – the aging Laboratory Information System – was no longer up to the task. The user interface felt outdated, reminiscent of another era, interfaces required manual adjustments, and many business rules existed only in people’s heads or Excel files.

The decision to replace the LIS wasn’t driven by excitement for innovation but by necessity. The vendor had declared the end of support for the system, and every system extension felt like performing surgery on a patient without anaesthesia. However, it quickly became apparent during the initial project meetings that a simple system swap wouldn’t suffice. To future-proof its operations, Helvex needed a new LIS that could support its domain logic, quality standards, and operational flexibility – achievable only through systematic Requirements Engineering.

Thus, the journey began – not with code, but with questions.

“What exactly do we do today – and why?” asked the RE analyst during the first workshop.

The room fell silent for a moment before stories started pouring out: tales of reflex tests no one could explain anymore, workarounds that had evolved from temporary fixes into silent standards. These workshops became a magnifying glass for what Requirements Engineering can achieve: understanding before changing.

In the first few weeks, the team created a process map – not a rigid diagram, but a dynamic representation of daily lab operations. This “map” captured every step: from sample arrival to analysis and result approval. Along the way, countless small but critical rules were uncovered – the invisible routines that keep a lab running.

The glossary that emerged became a shared language: What does “critical finding” mean? When is a sample considered “complete”? How do routine and emergency analyses differ? These seemingly simple questions turned out to be the key to a clear, shared understanding.

With the present mapped out, the team turned its gaze to the future. Through interviews, test scenarios, and validation rounds, the vision for the new system began to take shape.

Instead of relying on tables and static lists, Helvex worked with scenarios – real-world examples from daily lab operations.

“Imagine a sample is mistakenly registered twice – how should the new system respond?” Questions like these made requirements tangible. Step by step, rules were made explicit: reflex tests, plausibility checks, approval workflows. What was once considered “institutional knowledge” was now documented in a transparent rulebook – traceable, verifiable, and version-controlled.

In parallel, prototypes were developed. Biomedical analysts clicked through simulated interfaces on large screens, testing inputs and workflows. This was no longer an abstract IT project but a collaborative discovery process.

As the go-live date approached, testing became more concrete. Requirements that had initially been words on paper turned into criteria within the test system. Every use case now had a clear definition of “done” – verifiable, measurable, and documented.

For example, in a reflex test for a specific pathogen, the system had to automatically trigger an additional analysis, document three verification steps, and display the result within two minutes. Scenarios like these transformed abstract requirements into real quality benchmarks.

Of course, not everything went smoothly. During the migration of old master data, it became apparent that some values had been overwritten multiple times over the past decade. However, because the RE team had identified data quality as a priority early on, the cleanup was part of the plan – not a critical blocker.

The result: a lab that understands its system

When the new LIS finally went live, the tension was palpable. Weeks of simulations, testing, and fine-tuning had led to this moment. And yet, when the first sample was registered in the new system, there was a combination of relief and pride.

The results were quick to follow:

• Turnaround times for routine analyses measurably decreased
• Manual corrections dropped by more than a third
• Employees understood the system logic – because they had helped develop it
• Quality management could instantly show which rule was changed, when, and by whom

Helvex had achieved more than just implementing a new LIS.

The lab had learned to reflect on its own workflows – and translate them into requirements that bridged technology and domain expertise. Or, as the lab director later put it: “we didn’t just implement a system. We gained a better understanding of ourselves.”

Replacing an LIS means more than swapping software. Systematically gathering, clearly documenting, validating early, and actively managing requirements reduces risks, accelerates go-live, and sustainably improves quality and adaptability. The fictional case of Labor Helvex AG demonstrates that Requirements Engineering is essential for integrating domain logic, ensuring compliance, and enhancing operational security in a new LIS – and driving digital transformation in the lab.

How does your lab handle rule sets, parameterization, and interfaces? What challenges have you faced during LIS transitions? Let’s discuss – and contact us if you need support with requirements, validation, or requirements management.