Point of care diagnostics: navigating systems architectures

Diagnostic testing is rapidly moving out of the lab and into the hands of untrained users. But developing the system architecture for a
high-performance test that is also easy to use is a complex challenge.

A great example of advancements in point-of-care (PoC) testing is the pregnancy test. In the 1970s, Wampole’s 10-step test took two hours by a trained lab technician. Today it is carried out in minutes in the privacy of your own home using an off-the-shelf disposable device. 

PoC diagnostic tests should be quick and simple – and ideally not rely on the user’s skill to generate a reliable result. But, unlike pregnancy tests, molecular-based tests currently need more complex steps. For example, sample preparation may be needed to lyse cells, remove inhibitors or increase titre (see my earlier blog – Sample preparation: the curse of point-of-care diagnostics) and this can be extremely challenging to implement at the point of care at acceptable cost and device complexity.

Wampole’s test could be categorised as a ‘chemistry set’ where the skill of the operator is critical to generate an accurate result – there might be several critical timing steps, mixing and resuspension steps performed using a manual pipette, metering and sub-sampling precise volumes followed by vortexing and ‘gentle’ heating before looking for a subtle colour change. Lots to go wrong and not at all user friendly.

The Clinical Laboratory Improvement Amendment (CLIA) from the Food and Drug Administration (FDA) regulates laboratory testing for human diagnostics in the US and has categorised the complexity of a diagnostic test as either: waived, moderate complexity or high complexity. The level of complexity is determined by adding up the scores from seven criteria. A CLIA waived test means it is ‘simple to use, and there is little chance the test will provide wrong information or cause harm if it is done incorrectly’.

The simplest test for the user is to ‘add sample and walk away’ and the device carries out the necessary assay functions. This convenience typically generates significant market share over more labour-intensive competitor devices but there are trade-offs with device complexity and development risk. For complicated assays, ‘reader’ and ‘consumable’ system architectures are frequently used. However, consumables tend to be bulky and expensive, and the readers even more so. 

Below I outline some high-level considerations when developing system architectures for a PoC diagnostic device, and how to navigate between the ‘chemistry set’ and ‘fully integrated product’.

Assay robustness

It all starts with the foundation of any diagnostic test – the assay. A correctly implemented assay is fundamental to providing high-performance, reliable and repeatable results in the intended use environment.

Identifying sensitive parts of the assay that require careful controls, and functions that are more tolerant to variability, provides the first insights into the required architecture. For example, flow-rate variations may have a significant impact on test performance, which necessitates the use of an automated pump – or the detection method may require special optics. An untrained operator may not be capable of performing these steps with the appropriate control, so reader hardware may be needed.

Ideally the assay is well characterised in the lab before the system architecture is developed – but this is seldom the case. Another issue is that lab processes can be difficult or costly to implement in a ‘highly useable’, low-cost PoC test. So designing a system architecture that is capable of accommodating the necessary functions based on preliminary lab results is a tricky challenge. Capturing risks and uncertainties, and carrying out feasibility testing of the high-risk aspects during early stages of the project, will better inform the system architecture and can avoid unpleasant discoveries later on.

User burden

Although CLIA waive is highly desirable, many PoC devices are categorised as ‘moderately complex’ – it may be a good option for the user to carry out certain functions if they are tolerant to sources of variability (i.e. by understanding assay robustness and assessing operation against CLIA scoring criteria).

User involvement can significantly reduce device complexity but operators are busy people and can easily get distracted in a PoC setting. Failure alerts and fail-safe features help reduce the risk of generating an erroneous result. Mechanical guides and ‘poka yoke’ mistake-proofing features, as well as electronic timeouts and sensing (e.g. QR code read by the reader), can notify the operator that an incorrect or expired component is used. In the event of inactivity, the reader may invalidate the test altogether.

Device complexity

Every project is constrained by time and money and, if the development team has done its job properly, the device will be just complex enough to satisfy user convenience and assay needs. Of course, it’s not as simple as that – other crucial factors such as cost of goods and ‘platform’ requirements also need consideration.

Estimating device cost early on – and continuously updating the estimates – informs the viability of the architecture and ultimate success of the product. If cost estimates are high, it may be necessary to re-examine the assay and explore alternative, lower-cost technical solutions or implement more of a ‘chemistry set’ approach (but understand the impact to the user and viability of the product). Directing functionality (and cost) away from the consumable and onto the reader is generally a good option as non-disposable parts are less cost sensitive.

When designing system architectures intended to be a ‘platform’, it is important to consider the requirements of future assays and, if necessary, build in redundant capability to minimise the effort to accommodate new tests. This is easier said than done under tight timescales. But modular system architectures and components that allow modification – for example, volume expansion or increased flow rate – allow potential flexibility.    

Navigating the trade-offs to develop a system architecture that addresses all the considerations is a difficult challenge – and one that is often rushed as businesses are keen to meet their next milestone.

At Cambridge Design Partnership we use a holistic development approach involving close collaboration between our in-house human factors, mechanical, electronic, software and manufacturing engineers, as well as assay scientists. In the early phases of a project we identify the technical and market uncertainties – and thoroughly explore different architectures whilst characterising the assay and understanding user involvement, regulatory issues, manufacturing processes and ultimate device cost. This manages project risk and sets the course for a high-performance system delivered quickly to market. Get in touch via hello@cambridge-design.co.uk for help with your next diagnostic challenge.