Bench Testing & Pre-verification vs. Formal verification

#1
Hi All,

I'm having a challenging time with understanding what the difference between bench testing or pre-verification testing compared to formal verification testing with respect to how it relates to medical device development?

My interpretation is that the term bench testing and pre-verification are used to describe 'verification' activities that are conducted on prototypes that are under design control but are not yet actual production product that is to be marketed or submitted for regulatory agency approval. So in essence, it is a type of development verification activity. Since this testing and type of verification is conducted during development, it can be viewed as the verification activities that an organization determines are necessary in order to document and verify that a prototype is ready to be used in a pre-clinical, early feasibility study (IRB), IDE (FDA), or pivotal study.

Obviously, not all requirements or risk will be understood or captured early in the development process and therefore not all verification activities required for the final product will be fully understood until later in the process. My understanding is that this is in part why independent parties (IRB's, FDA IDE, etc.) play a hand a reviewing and approving clinical study devices.

So to summarize, the way I'm viewing this is that;

Bench Testing/Pre-Verification --> Used on prototypes --> Testing conducted is inclusive of best effort determination of necessary requirements that developer has determined is needed to ensure function and patient safety --> Independent parties (FDA, IRB's) are the gates that determine that inputs and outputs identified and the planned and executed verification activities are appropriate to move forward with a prototype study.

Formal Verification --> Used on product --> Testing is inclusive of all requirements. FDA is gate that reviews that all inputs and outputs meet the regulatory requirements for the production design.

Is the above understanding consistent with how others view the difference between bench testing and verification?
 

yodon

Staff member
Super Moderator
#2
I'm not sure "pre-verification testing" is a thing (from a regulatory / compliance perspective).

Verification activities provide objective evidence that the product meets the (approved) requirements. Frequently, you can't verify requirements on production units as it may require special test configurations / setups. Rationale for the test approach should be documented in the test plan or protocol.

Clinical studies are outside the scope of verification and production equivalent devices need to be used. If not production devices, rationale needs to be documented why the devices are production equivalent.

Using the 'classic' V model, User Needs are at the top of the requirements tree. Validation provides the objective evidence that user needs are met. System requirements elaborate the user needs and verification provides the objective evidence that requirements are met.

Does that help?
 

Ronen E

Just a person
Staff member
Super Moderator
#3
Yodon’s response is very much spot on. I’m also new to the term/concept of “pre-verification”. Isn’t it just a fancy name for informal testing you do during development?

Bench testing is a category of testing that can be part of anything. Typically formal verification includes bench tests. You can do bench testing on prototypes or on production units. You can also base a regulatory submission on prototype tests.

I would definitely not recommend using any product, whether you call it a “prototype” or a “production unit” (or equivalent) in pre-clinical, early feasibility, IDE or pivotal study before it passed full, formal verification, including any necessary bench tests.

External parties play a part in reviewing and approving clinical studies (of any type) mainly for ensuring subject safety and rights are not compromised; not to help you complete your requirement-set or risk management process. The latter are taken care of through multiple design iterations - typically a new device is not fully developed through a single design/verification iteration. Typically you’d go back to the design inputs and the design itself after your first verification round.
 
#4
Thanks yodon and Ronen on your reposnses.

What I find challenging is the fairly binary criteria of performing full and formal verification on something such as an EFS study device. Part of my understanding of an EFS is that it is a small study used to gain valuable insights into the development of a new technology. As such it would seem unreasonable to me that all user needs and requirements would be completely understood or captured within this part of the development process as these could be key outputs of a EFS. Secondly, it wouldn't seem reasonable in some instances to have certain devices run through the full gamut of some of the verification tests such as IEC 60601, in order to proceed with an EFS.

Yes, user/patient safety is important and this should be the primary concern of the developer, however is there not reasonable justification as to why perhaps a developer may verify only certain clauses of IEC 60601 (ground fault, EMC, etc.) and exclude things like drop and ingress if the number of devices is limited and the device is going to be used in a controlled environment under supervision or use of trained individuals??

The reason I ask is because the last item noted is basically me paraphrasing some input from a regulatory/quality director that recently weighed in on a conversation I was sitting in.
 

Ronen E

Just a person
Staff member
Super Moderator
#5
"Full and formal verification" just means that all the design inputs stated (reviewed & approved) at that stage have been met. It doesn't mean that the design inputs are necessarily complete or watertight. And yes, an EFS may expose new needs or shortcomings in the application as understood/envisioned at that stage.

Going into a clinical trial, the reviewing committee should have access to all previous test summaries as well as justifications for tests not completed (e.g. certain 60601 clauses). That should allow you to argue for reasonability/proportionality and them to consider subjects' wellbeing against any residual risk.
 

Top Bottom