T Jull - Product Development for Point-of-Care Testing Systems
1 | P a g e
Product Development for Point-of-Care Testing
Tue, 02/03/2015 - Thomas Jull (Resources)
One of the key considerations when starting out on a
product development project for a Point-of-Care
Testing system is how to manage the development of
the two main components.
Usually, these components are:
1. A test kit or consumable used to collect a patient sample
near the site of patient care.
2. An instrument used in close proximity to the patient to
analyze the test sample and produce a result within a short
period of time
In this article we provide you with 4 top tips to start you off on the
1. Lock down the design as early as possible
2. Design both the consumable and the instrument with flexibility in mind
3. Have a project risk management plan
4. Start with a product soft launch and then release a version two
Some basics on developing Point-of-care testing systems
Depending on the type of patient sample (whole blood, saliva, urine) and patient test (blood glucose, infectious
disease, drug abuse screening, etc.) Product design of the consumable (sometimes referred to as cassette or
cartridge) needs to consider numerous areas of engineering application and technology.
2 | P a g e
These can be things like:
Fluid dynamics e.g. microfluidics
Other areas such as sample tracking and counterfeit prevention
In much the same way, the product development of the instrument has to consider the same areas of engineering
and technology in addition to:
Processing the sample via mechanisms or pumps
Reading the sample (maybe optically)
Control and analysis via software and algorithms,
And all while providing a well-designed user interface, and possibly, while connected to an external
In such cases, integration of the cartridge with the instrument for testing requires a high degree of coupling
between the two components in the areas mentioned above. Within the cartridge and within the instrument there
may also be a high dependency on neighboring components for correct functionality.
So it’s best to develop the consumable and instrument at the same
3 | P a g e
Some of the most common reasons for developing both the consumable and instrument in parallel are:
The need for reduced time to product launch when you’re trying to beat the competition to market
Pressure to ensure that you meet targets set by investors
Serving demand from customers in need of the product sooner rather than later
In practice though, when such POCT development projects are undertaken, small changes to the cartridge result
in a need for changes to the instrument. This is especially true in cases where a contract product development
firm is used alongside in-house development of a chemistry used within the consumable.
Here a butterfly effect occurs, sending ripples through the rest of the design of both the cartridge and the
instrument. At this point during the development (or worse, in hindsight at the end of a project) it is easy to say,
‘if only we could have designed the consumable first and then the instrument’.
Development of the consumable and instrument in-series is probably
not a feasible option.
The nature of development usually results in iteration to the design as a way of continuous improvement or to
correct negative emergence (the occurrence of unexpected and unwanted effects that emerge from internal or
external interactions inherent in complex systems) to the consumable, the instrument or both.
We realize that timescales and funding streams won’t permit you to develop the consumable before the
instrument (and in fact, taking a systems approach needs some overlap in the development of both) but there are
some ways to mitigate the risks.
ITL Virginia's 4 Top Tips
So what can be done to prevent total redesign? Well,
whilst each POCT system development project and
product is different the general points below may be
1. Lock down the requirements specifications as
early as possible
Locking down the functional requirements and constraints of
both the consumable and the instrument is important, and needs
to be done early in the project.
ISO/IEC 15288 is a Systems Engineering standard concerned with processes and life cycle stages. It serves as a
good guide here, highlighting processes for requirements definition and requirements analysis, architectural
design, and implementation.
You should also make sure that all stakeholders understand and agree to what is needed. This helps provide a
direction for the design with a shared perspective.
4 | P a g e
Remember to document this in a way which allows easy verification and validation later on in the project to
ensure that the criteria have been met. One effective way of doing this is to break down both the consumable
and the instrument into sub-systems or modules.
2. Design both the consumable and the instrument with flexibility in mind
It’s worth pointing out here that this can be easier said than done, especially for complex POCT systems which
require multiple technologies for functionality and/or small scale components or modules. If, for example, a
requirement is changed during development, the sizes, placement or configuration of design features may be
affected, along with the choice of components.
If a changed requirement affects the design features of the consumable, this could also have a major effect on
some of the sub-systems within the instrument which couple with the consumable. Other changes may occur to
optimize performance, save cost or to replace an obsolete part. Flexible design allows adaption to change for
• Flexibility for the selection of different components. Space to do this needs to be considered, whether its
physical space for mechanical parts, extra capacity for electrical connections/power, or memory/processing for
software and control. Also, when selecting a critical component, its nice to know that similar components can
be obtained, and from different suppliers too.
• Flexibility for the selection of different component suppliers. If off-the-shelf components are used, utilizing a
different supplier is not too much of a problem. However, if custom parts are used, transfer of the manufacture
to a different supplier can result in problems with regards to capabilities, ces and quality. Make sure you know
your options before you design.
• Flexibility for the change in manufacturing technique and/or material. If the first batch of products is a
relatively small quantity and uses custom parts, then machined parts or soft tooling is a good option. However,
when transferring to bigger volumes hard tooling may be desired but the design of the parts has to allow this.
Remember to design for manufacture.
3. Have a Project Risk Management Plan
Having a plan in place to manage project risks is crucial and relates to ISO/IEC 15288 (above).
The Project Management Institute (PMI) has published a Practice Standard for this which is great for risk
management planning, risk identification, and qualitative and quantitative risk analysis.
Instead of parallel development of both the consumable and instrument, you could plan the development of the
instrument to slightly lag the consumable. It may also be a good idea to take a staged approach for developing
the modules or sub-systems.
Ultimately, be systematic, but systemic at the same time, and consider the POCT system as a whole.
4. Start with a product soft launch and then release a V.2
If timescales are tight and investors are breathing down your neck to get the system on the market, then doing a
soft launch with a V.1 one product isn’t always a bad idea.
5 | P a g e
If a POCT system has been given the appropriate approvals and markings for market, then distribution within a
set of customers who understand that the product will be improved and upgraded to a version 2 later on can start
bringing in some much-needed revenue. More on start-up strategies here.
Although clinical trials and usability testing should have been performed during development, getting feedback
from the actual market on product performance can be very useful for product success. Yes, this can result in
changes to the design, but that’s why you need to do the other 3 things too. After all, aren’t POCT systems all
about innovation and opportunity anyway?