2. Proof of principle testing
Once you have proven through the proof of concept stage that the fundamentals of your product are sound, you can now test your medical device’s performance against some early specifications. An example might be looking whether your device can deliver a formulation to observe how much and how fast this happens.
As you’re starting to think more about the detailed functions of the device, while still firmly in development, proof of principle testing involves a balance of qualitative and quantitative tests, with increased rigour in the test approaches. Even though you’re still in the development phases, you should be aware of the formalities to come, including eventually medical device design verification. This means that at this stage it’s important to get the right balance of agility and detail to keep your project on track while de-risking to avoid any unwanted surprises later.
Some questions you might want to ask yourself are:
- Can I rely on my test data?
For example, if you are using a sensor to capture data, you need to be sure it’s accurate and precise. Using a calibrated sensor will give you some confidence that recorded data are accurate. Similarly, make sure you understand the influence custom test jigs and fixtures have on the measurements.
- Is the user influencing the performance?
How much of what you are seeing is down to user technique or influence? If you are trying to assess the performance of a device away from user influences, consider removing the user as a variable e.g., automated, or semi-automated testing.
- How many samples should I be testing?
If you are making decisions which influence the design or are analysing data against specification limits, even at this early stage, these shouldn’t be based on the performance of a single sample. Deciding on the number of samples that need to be tested at this stage needs to be pragmatic, and should be based on several factors, including: the availability of parts, how representative the parts are, or whether a well-controlled manufacturing process produces the parts.
- Could someone else repeat what I have done?
A documented approach should be generated for this testing. Ideally, another competent operator should be able to repeat the test in the same way, and anyone looking at your work later should be able to understand what you did.
- Is what I’ve done traceable?
Which sample did you test? Where did it come from (e.g., manufacturing process, materials of construction)? Where is it now? What was the design revision? The traceability of your parts and design is key to enabling you to investigate any unusual or interesting results.
At this point in the development, your testing and methods can be seen as an iterative step towards design verification. If done correctly, they can be used as the building blocks for later formal test methods and protocols.
During this phase you should aim to produce data and evidence to show that, in principle, based on the current embodiment of the design, your device is likely to meet its functional requirements. Achieving this will help de-risk your device’s progression to the next phase of development.
Top tips:
- Get input on your test approach from colleagues who are likely to be involved in your medical device verification test program. Anything which can be done now and fed into later testing will make the development smoother. Seeking independent input can also be helpful to check that what you are planning to do has the right level of control and detail for this phase of the development.
- Anything which can be done to speed up testing, without compromising its quality, can also be useful. If a simple rig can be built which can speed up testing significantly, it is worth investing the time now, particularly if the rig may be useful in future testing phases.
- You might be establishing your device’s functional requirements. When doing this, having test approaches in mind is a good way of sanity checking that your key requirements are written to be clear, unambiguous, and measurable / ‘testable’.
- Preserve the independence between the design and testing teams. It’s even more important at this stage that someone independent is also assessing the device design.
Documents to be completed:
- (Draft) Product / Functional / Technical Requirements Specification
- Test methods or documented method statements
- Test report(s)
- Requirements for any rigs or fixtures