Need help on defining scope for Design Verification File for Class III IVD

[redknight07]

Hi all,

I am in the process of developing a design verification document for HIV rapid test device, class III IVD. The general concept of this document is to provide a reasonable justification through testing that all the claims made in the design output file have been verified through lab testing and a good way of presenting this would be in a tabular matrix form.

I am confused regarding the scope/topics to be addressed in this document and how to go about with things. Where should I begin with and what are the sections which I should address in this documentation. for ex. justifications for the reagents and their concentrations used in the device, temperature/specificity/sensitivity claims made on the device, testing for temperature extremes for the device and so on.

I have tried reading through design control guidances but feel very lost in a heap of information at the moment. I will hugely appreciate any pointers that you guys have through experience that could assist me.

Thanks,
Aniket

 

[Ronen E]

Hi Aniket,

It would help clarify / focus if you told us what is the regulatory context of your query. If it's FDA oriented, it could also help if you specified the FDA ProCode.

Beside all that, I'd say that your company QS design Control SOPs would be a good place to start from.

Cheers,
Ronen.

 

[redknight07]

Thank you for going through my query, Ronen. I am a graduate student who just stated interning at a medical device company making III IVDs (HIV Rapid test device). Current company acquired the technology from another company and does not have the design control documents in the proper format as required by FDA.

I recently compiled design input and output documents for the device using the existing documentation according to design control guidance document requirements and the templates provided on this forum and have to prepare the design verification document next.

In the input file I have included: performance requirements, functional requirements, product requirements and user interface requirements. In this section we have made claims such as the accuracy, sensitivity, specificity needs to be a certain %. there should be no cross reactions, the storage conditions/shelf life should be within a particular range and so on.

In the output document I have included: specifications of every raw material used (pH range, grade state of matter of the materials, pKa, impurities etc from the data I already present at the company), dimensions and specifications of the sub-assembly and final device including engineering drawings of all the parts, labeling, packaging and so on.

I understand that verification is the process by which the lab verifies that the established performance claims of an IVD test or product as mentioned in the input and output files can be replicated in the lab before patient testing. How do I tackle these issues when writing the verification file, what protocols to use, what format to use? Couldn't find any templates regarding this. I do know that it will need evidence and justification to every claim made in the input-output files.

Phew!!

 

[Ronen E]

Hi,

You have done some valuable work, but I suspect some of the fundamentals aren't there yet.

You didn't specifically said otherwise, so I'm going to assume that we are discussing all of this from an FDA perspective.

You really need to get the classification sorted first. Namely, identify the ProCode. This will start solidifying what you actually need to do / have.

Further, the fact that the technology is acquired / licensed doesn't provide any concessions. All applicable Design Control requirements have to be met, one way or another. Access to relevant information is typically a requirement in the acuisition agreements.

Before jumping on actually preparing the Design Control docs (input, output etc.), your company has to have it's relevant Quality System (QS) Standard Operating Procedures (SOP) in place. In general, it has to comply with 21 CFR 820. Those SOPs should tell you what to do, and how, including what reports are needed and what they should include.

Specifically, Design Verification is the process of making sure that Design Outputs are established, are accessible and properly address the Design Inputs (i.e. all pre-defined requirements are met). Verification is about demonstration; proof belongs to the Validation stage. This is true for all devices.

Cheers,
Ronen.

P.S. Perhaps you should start here, and follow through:

https://www.fda.gov/ MedicalDevices/DeviceRegulationandGuidance/HowtoMarketYourDevice/default.htm

 

[redknight07]

Ronen, thank you for your assessment of my query. I am just about to graduate from University and am doing an internship at this company since September. I aspire to have a career in Regulatory Affairs and this is my first job as a regulatory professional.

You really need to get the classification sorted first. Namely, identify the ProCode. This will start solidifying what you actually need to do / have.

Further, the fact that the technology is acquired / licensed doesn't provide any concessions. All applicable Design Control requirements have to be met, one way or another. Access to relevant information is typically a requirement in the acuisition agreements.

The device in question is HIV Rapid test to detect HIV 1/2 antibodies using blood and serum/plasma samples. I was not able to find the product code for the device which is really strange. Never had such problems when had to look out for codes for devices. Under CLIA, since the device uses both blood and plasma, the complexity is moderate.


You didn't specifically said otherwise, so I'm going to assume that we are discussing all of this from an FDA perspective.

PMA submission is being considered for the coming year.


Before jumping on actually preparing the Design Control docs (input, output etc.), your company has to have it's relevant Quality System (QS) Standard Operating Procedures (SOP) in place. In general, it has to comply with 21 CFR 820. Those SOPs should tell you what to do, and how, including what reports are needed and what they should include.

The company does have a quality system in place which cover most sections of 820 but there are no guidance's on how to go about with design control documentation related to .


Specifically, Design Verification is the process of making sure that Design Outputs are established, are accessible and properly address the Design Inputs (i.e. all pre-defined requirements are met). Verification is about demonstration; proof belongs to the Validation stage. This is true for all devices.

I have tried my best to use all the information at hand regarding the device and compiled the input-output documents with the information that needs to be in these documents.

With verification, the approach I have taken here is to state every claim made in the input files and to provide evidence and justification for the same in the output and verification files.

A

 

[Ronen E]

With verification, the approach I have taken here is to state every claim made in the input files and to provide evidence and justification for the same in the output and verification files.

Spot on.

 

[yodon]

As Ronen noted, you have grasped the basic intent of the regulation.

But there's much more to V&V than just verifying your claims. For example, you need to do a hazard analysis / risk assessment. Controls to mitigate hazards need to be verified for implementation and effectiveness.

Without (hopefully) confusing matters for you too much, the 'V model' is a good approach (https://en.wikipedia.org/wiki/V-Model). Customer requirements / claims are validated and specifications (including risk controls) are verified.

 

[Ronen E]

As Ronen noted, you have grasped the basic intent of the regulation.

But there's much more to V&V than just verifying your claims. For example, you need to do a hazard analysis / risk assessment. Controls to mitigate hazards need to be verified for implementation and effectiveness.

Without (hopefully) confusing matters for you too much, the 'V model' is a good approach (https://en.wikipedia.org/wiki/V-Model). Customer requirements / claims are validated and specifications (including risk controls) are verified.

As much as I agree on a general level, FDA's requirements are not that clear / elaborate WRT risk management. In that context I would do 2 things to satisfy the FDA:

1. Include formal risk management in Design Validation.
2. Adopt a general approach of recurring risk management through various stages of device lifecycle.

The question of whether to run a full blown risk management session at Design Verification is - IMO - a question of benefit to resources ratio, and should be answered on a case by case basis. In my understanding Design Verification and Design Validation should be separate, clearly distinct activities, and since Verification is more about demonstration than about proof, I think risk management would add much more value at the Design Input and Design Validation stages.

Cheers,
Ronen.

 

[redknight07]

Thank you Yodon and Ronen for your inputs.

I do understand that risk assessment needs to start from the design input stage and the controls used to mitigate need to be verified against implementation. At this moment I am planning to keep verification and validation as separate files.

Cheers,
Aniket