One of the most important CGMP requirements for Vendors / Suppliers...

Change Control, documented, and reviewed agreed to prior to implementation by the customer(s).  This is a hard one to get vendor buy-in or enforce.  However, failure to do so will get the customer (contracting company)  into major trouble with the user / market and regulatory agencies.  Device changes have to be documented, validated, and compared to the last cleared 510(k) per two guidance documents (device itself, and device software / firmware) on  device changes and the 510(k) with analysis of the last change and the cumulative change since the last cleared 510(k) documented - usually done by the company, not the vendor.

-- jel@jelincoln.com 

 Q&A from a recent one of my VMP (Validation Master Plan[ing]) Webinars

Ques:  Using vendor developed/administered tests as part of a company's qualification for vendor-supplied production / test equipment.

Many times vendor templates are not meeting internal documentation requirements. For example all tests are not signed/checked individually; one signed at the end of page or document.

How to handle this when vendor documentation is not fulfilling internal requirements?

Ans:  As mentioned, you would have to "fill in the blanks" with supplemental verifications/testing, so the vendor's documentation and the additional verifications complete your company's SOP requirements for the validation.

 

Ques:  Risk based validation.

Is validation really risk based if it is based just on URS requirements. A Validation is checking just URS requirements and maybe some internal documents. Should there be a formal risk assessment on which validation is based?

 

Ans:  Risk, i.e., patient safety (ISO 14971, ICH Q9)-based Risk Management Reports/Files addressing the subject being validated, are used to direct the test cases focus, depth, size, sampling, design, et al - not just the URS.  The higher the risk based on the Risk Management File / ISO 14971:2019, the more detail, et al, included in the V&V Report's test cases as per an example test case in the webinar (the test case introduction / narrative ties that test case to specific references / line items on a Risk File document, e.g., FMECA) to define the patient risk associated with that test case.     

 

Ques:  Documentation practices.

Test should be signed individually and at right time (in real time).

In some cases multiple tests are on same page and only one signature at the end of the page. Is this really fulfilling the requirement of right time?

 

Ans:  It depends.  FDA's Guidance Document on Data Integrity on test data does not agree with different test's data being combined under one signature  (in my opinion).  However, if one signature is used  to certify the accuracy of the report, with supporting information and signatures for the individual reports readily available elsewhere, that may be allowable, depending...  And would have to be clearly stated how it can be viewed as allowable in an SOP which is then followed!

 

Ques:  Document templates. During the webinar  specific example test templates weren’t available. Are they now?

 

Ans:  No,  That would be a specific consulting project. Complete validation templates are very specialized / unique and I don't supply them in an "all-purpose" webinar.  I do develop them as part of a dedicated consulting project.  However, the basic /generic format / outline was provided a couple of times on the slides, as well as an example of an IQ check list, an OQ test case and a PQ multiple sample (n=10, n=30 ...) test case, which all also can vary.  A list of product tests / verifications was also included in the slides:

E.g., Basic Test Report Format:

• Control Number, Title
• Scope, Purpose
• Pre-Approval
• Test description, lay-out, drawings / pix...
• Pre-determined test acceptance criteria
• Test materials (P/N, Lot No., description, Qty...)
• Test equipment (asset no., S/N, Model, Description...)
• DQ, IQ, OQ, PQs -list or test cases
• Software 10 elements (see Blog, elsewhere) if applicable, Pt 11 (OQ), Cybersecurity (OQ, if applicable
• Results:  Filled-in test cases. data sheets
• Conclusions:  Compare test case results to pre-determined acceptance criteria
• Appendix:  Training Record copies, calibration ccs,  red-lined SOPs, etc.

-- jel@jelincoln.com  

 

 The New US FDA Predetermined Change Control Plans (PCCPs)

The US FDA is proposing a new addition to 510(k)s and PMA submissions:  Predetermined Change Control Plans (PCCPs) for devices requiring premarket approval (PMA) or premarket notification (510(k)).  A PCCP is the documentation describing what modifications will be made to a device and how the modifications will be assessed.

A recently published draft guidance, “Predetermined Change Control Plans for Medical Devices”, Draft Guidance for Industry and FDA Staff, for comment only, issued on August 22, 2024, provides FDA’s current thinking on the information to include in a PCCP.  It is also soliciting comments from stakeholders as to the proposals it discusses.  This draft guidance recommends that a PCCP describe the planned device modifications, the associated methodology to develop, validate, and implement those modifications, and an assessment of their impact.

FDA reviews the PCCP as part of a marketing submission for a device to ensure the continued safety and effectiveness of the device, without necessitating additional marketing submissions for implementing each modification described in the PCCP.  By including a PCCP in a marketing submission for a device, manufacturers can prospectively specify and seek premarket clearance / approval for intended future modifications to a device without needing to submit additional marketing submissions or obtain further FDA authorization before implementing such modifications – provided the changes are consistent with the PCCP that has been submitted and FDA-reviewed / cleared / approved.

Obviously this is a provision where future changes / models / improvements are basically known at the time of the original 510(k) or PMA submission.  For changes made to address unforeseen issues at the time of initial submission, the two guidance documents of changes to devices needing a new submission would apply instead.  

-- jel@jelincoln.com