Beyond the Assay: Why Diagnostic Device Development Needs Three Separate Specifications

Beyond the Assay: Why Diagnostic Device Development Needs Three Separate Specifications

When a new diagnostic assay produces promising results in the laboratory, attention naturally turns to automation and commercialisation. Investors want to see progress, funding is finite, and everyone is eager to see the shape of the future product. It is at this point that many development programmes make an understandable assumption: that the next step is to design the device that will eventually be sold.

On the face of it, the logic is sound. If an assay is ultimately intended to become a point-of-care instrument or automated laboratory product, why not start developing that product immediately? In our experience, this approach risks an increase in development time and cost, rather than a reduction. The conversion of a working laboratory assay into a successful commercial product is rarely achieved in a single development step. There is usually an important intermediate stage that is too often overlooked.

So, rather than thinking in terms of two systems, it is often more useful to think about three: the manual assay, the assay automation development platform and the automated product. Each serves a different purpose, has a different set of users, and requires its own specification.

System One: The Manual Assay

By the time an engineering development team, like ours, becomes involved, there is usually a functioning assay already in place. The process may have evolved through months or even years of laboratory experimentation, with parameters adjusted, reagents substituted, timings modified and work-flow steps refined until useful and repeatable results are achieved. On the surface, this looks like a well-understood process.

In reality, what often exists is a successful practice rather than a fully understood workflow.

Much of the workflow will be documented, but some of it may exist only in the experience of the scientists who perform the assay day to day. This is where one of the most challenging categories of knowledge comes into play; something we think of as the ‘unknown knowns’: behaviours, assumptions and observations that experienced operators understand but that have never been explicitly captured.

Perhaps a tube is always mixed slightly more vigorously than the written procedure suggests. Perhaps a mixed solution consistently sits for longer than intended because the operator naturally prepares the next stage whilst waiting. Perhaps one member of the lab has developed a technique that improves consistency without even realising it.

Details such as these tend to remain invisible until someone attempts to automate the process, because automation faithfully reproduces what is specified and nothing more. It cannot reproduce knowledge that was never written down, which is why the real assay must first be understood before a successful product can be developed.

System Two: The Assay Automation Development Platform

This intermediate stage is frequently underestimated. Many organisations assume that assay automation development and product development are effectively stages in the same workflow and therefore attempt to use early prototypes of the final commercial device as test and development platforms. Unfortunately, the requirements for an assay automation development platform are often very different from those of the eventual product.

The purpose of an assay automation development platform is not simply to automate the manual assay; it is to understand it. The platform must provide a means of discovering which parameters matter and which do not: where tolerances can be relaxed and where tighter control is required.

To achieve this, the platform typically needs capabilities that would be undesirable in a commercial product. It may be built from overspecified off-the-shelf components, with fluidic paths that are easy to access, extensive diagnostic features and operating parameters that can be configured in software. It will often carry additional sensors and instrumentation, and log operational data in considerable detail. The resulting system may well be larger, more expensive and less elegant than the eventual product.

That is not a failure. It is simply doing a different job. At this stage, the goal is learning rather than optimisation. Prematurely optimised hardware will likely reduce flexibility and increase development time of the assay automation development platform.

Take a temperature-controlled assay, as an example. A commercial product ultimately requires a tightly defined thermal solution, but before that solution can be specified, the team needs to understand how sensitive the assay is to temperature variation in the first place. If performance remains stable across several degrees of variation product development may become significantly simpler and less expensive. If, on the other hand, the assay performance deteriorates rapidly outside a narrow temperature range, engineering effort can be focused where it delivers genuine value. Without that knowledge, product decisions are made largely on assumptions.

Trust the platform, test the assay

The assay automation development platform brings with it another important consideration, and one that is sometimes overlooked: its own performance must first be understood and demonstrated to be repeatable before the assay results it produces can be trusted.

If a platform delivers inconsistent assay results, what exactly is being tested? The observed variation might be caused by the chemistry, but it could just as easily come from the fluid dispensing inaccuracies, thermal control variability, mixing performance or timing errors. For this reason, the platform itself must first become a reliable experimental tool.

In effect, the platform becomes a system that must be prototyped, tested, and iterated before it can be used as a tool for testing something else. Scientists want to use the platform to learn about the assay, they do not want every experiment to turn into an investigation into whether the platform itself is behaving correctly. The more confidence there is in the platform, the more meaningful the assay results become.

System Three: The Product

Only once sufficient understanding has been gained does the focus shift towards the commercial product, and this is an entirely different optimisation challenge.

Now the questions are about how the device can be manufactured reliably, how material cost can be reduced and assembly simplified, how usability can be improved, how regulatory requirements will be met, and how consistent performance can be maintained over production volumes. The information generated during assay automation development provides the specification and allows every one of these questions to be answered appropriately and tested against key performance criteria.

Many diagnostic systems, for example, contain both a reusable reader with a disposable consumable, and the assay automation development process helps to inform where functionality should reside. Should a heater be integrated into the disposable because that offers optimal thermal performance, or could it be located in the reader to minimise consumable cost? Neither answer is universally correct.

What matters is that the decision is informed by evidence rather than assumptions, and the same principle applies throughout the system architecture. What appears to be an expensive feature in one specification may ultimately reduce overall system, and/or life-cycle cost. Whilst something that initially seems to simplify the design may later prove difficult to manufacture or control. These trade-offs become much easier to evaluate once the underlying assay requirements are properly understood.

Three Systems, Three Specifications

The common thread running through all of this is that each stage exists for a different purpose. The manual assay demonstrates scientific feasibility, the assay automation development platform converts assumptions into knowledge, and the product delivers a commercially viable solution.

Trying to combine all three objectives into a single specification too early often creates the worst of all worlds. Laboratory users are constrained by a platform that has been optimised too early and is difficult to adapt, while engineers are forced to make product decisions before they understand the requirements that those decisions must satisfy.

A more effective approach is to recognise that the three systems are different and to define them accordingly.

All three contribute to the same outcome, but each answers a different set of questions.

Knowledge Is Progress

Development programmes often measure progress by the sophistication or maturity of the hardware they produce. We would argue that a more useful measure is the knowledge they acquire.

Every stage should reduce uncertainty, whether that uncertainty concerns chemistry and biology or fluidics, thermal control, manufacturing and usability. The most valuable outcome of a development activity is not always a design that can be carried forward unchanged; sometimes it is the evidence that allows a better design, the right design, to be created in the next iteration.

In that sense, setting a design aside is not starting again. It is moving forward with more knowledge than before; and in diagnostic device development, knowledge is often the most valuable product of all.

Ready to accelerate your innovation?

If you have an assay that is performing well in the lab and you are wondering what comes next, we can help you. Whether you are still uncovering the unknown knowns in a manual process, need a development platform that helps your scientists learn faster, or are ready to start shaping the product itself, our team has been helping clients through exactly these decisions for almost 25 years.

Please get in touch with our team via email on design@egtechnology.co.uk, by giving us a call on +44 01223 813184, or by clicking here.