Process Verification / Validation

An answer to a query:

Ques:  The  company  (site) that I work for, manufactures intermediate products.  The question that we have is-If a change is made to a process,  should we do validation or is verification sufficient?  All our processes have QC/acceptance criteria.  For example, we got a validated instrument from another site (of our company).   We got IQ/OQ done by the vendor at our site.  We also have the same instrument from another vendor, which will be retired in couple of months.  Can we do verification of the new instrument by writing a technical report ?    In other words, we will  first conduct  a risk assessment and then do experiments to compare the data of the two instruments and record them in a report.  Actually we have already done feasibility studies to show that the new instrument gives the same data as the old one for the same samples .  I heard , in your talk that FDA doesn't require validation if we have the means for 100% checking.  We have similar situations in which we sometimes make a change in the process but we always have means to verify the final product because we have acceptance criteria in place.  Is verification enough for such situations?    Please advise.

Ans:  "FDA doesn't require validation if ..."  The specific reference for my comment for medical device manufacturing is 820.75 "Process validation, (a) "where a the results of a process cannot be fully verified by subsequent inspection and test, the process shall be validated with a high degree of assurance..."  The key exception to this is automated (computerized) processes, which per 820.70(i) must be validated no matter what.

As to the rest of your question, part of the answer depends upon your definitions of verification and validation, technical report, feasibility studies, et al.  Any change requires some level of verification (testing, checking, feasibility studies, etc), or a series of verifications (part of a validation) to prove that the change does what it should and doesn't do what it shouldn't.  While I won't state what you've outlined will satisfy requirements (though on the surface it appears to), if you've satisfied the CGMPs and what I've outlined above, yielding data that nothing has changed and that product quality / specifications are assured after the changes per your data, documented, then you've met the requirements.

Method Validations

Some Q&A from a recent webinar:

Ques: Do you have any recommended references to create risk categories for method validations?

 Ans:

JVT Article 2004, especially note flow charts; caveat – include potential problems from normal use, not just from a failure mode:

 http://www.validation.org/wp-content/uploads/2015/02/JVT2004_Risk-Management.pdf

PDA Slides:

https://www.slideshare.net/StephanOKrausePhD1/riskbased-analytical-method-validation-and-maintenance-strategies-sksep13

Q8, Q9, & Q10 Questions and Answers, U.S. FDA:

https://www.fda.gov/drugs/guidancecomplianceregulatoryinformation/guidances/ucm313087.htm

U.S. FDA Guidance, 2015: Analytical Procedures and Methods Validation for Drugs and Biologics; note several of the headings may provide risk categories, e.g, Apparatus/Equipment, Operating Parameters, Reagents/Standards, Sample Preparation, Standards Control Solution Preparation, Procedure, System Suitability, Calculations, Data Reporting... :


https://www.fda.gov/downloads/drugs/guidancecomplianceregulatoryinformation/guidances/ucm386366.pdf

jel@jelincoln.com

CE-Marking and China; Design Inputs / Requirements


Answers to some questions from my recent 3 hour DHF, DMR, DHR ... TD webinar:

CE Mark and China?

The European Union comprises 28 countries that require CE-Marking. Three additional countries (Norway, Iceland, Liechtenstein), although not officially part of the European Union, are signatories to the European Economic Area (EEA). Switzerland is not an EU member nor a signatory to the EEA, but they have transposed the Medical Devices Directives into their national law and these countries require CE Marking. -- https://www.emergobyul.com/resources/europe/where-ce-mark-is-required

 As I mentioned, the China Food and Drug Administration (CFDA) is the administrative body responsible for the regulation of medical devices and pharmaceuticals on the Chinese mainland. The US FDA resident posts in China assisted them in setting up their CFDA.  I personally know that many Chinese companies that manufacture finished devices and components for sale in the EU are certified to ISO 13485 and the CE-Marking of those products.  And those that do so for US destined products are also registered with the US FDA and subject to US FDA periodic inspections.

Writing good design inputs / requirements [for devices, processes, equipment (manufacturing, test)]?

• List requirements needed / the reason why acquiring the equipment, RM, components in the "requirements"; expectations for it, (see below "functional, performance, interface" also),  Marketing, company manufacturing / engineering inputs; documentation and calibratable instrumentation requirements; spare parts; etc;

• Also address the following as applicable (from one of my webinar slides): 

           "Virtually every product will have requirements of the following three types:

1.Functional requirements:  what the device does, focusing on the operational capabilities of the device and processing of inputs and the resultant outputs;

2.Performance requirements:  how much or how well the device must perform:  e.g., speed, strength, response times, accuracy, limits of operation, etc. This includes a quantitative characterization of the use environment, including, temperature, humidity, shock, vibration, and electromagnetic compatibility.  Device reliability and safety (see ISO 14971, Device Risk Management)  fit into this category;

3.Interface requirements:   characteristics of the device critical to compatibility with external systems;  characteristics mandated by external systems and outside the control of the developers.  One such important interface is the user and/or patient interface (see Use / Human Factors Engineering IEC 62366-1)."

• Add required ISO + standards;
• Add applicable US FDA guidance document requirements or their equivalent;
• Convert to quantifiable / measurable terms where necessary;

Remember the requirements become the basis for V&V -- Instalation (IQ) and Operational  (OQ, all the remainining requirements) / Performance (PQs;  those requirements that need additional challenging due to allowable "worst case" inputs, e.g., different operator shifts, large volume RM, power fluctuations, other highly variable inputs.

As I mentioned, DIs and DO's during the R&D process is an iterative process, recognized as such by the FDA in it's Design Control Guidance Document.  A DI becomes a DO which in turn becomes a DI at the next level of development, which becomes a DO, until the product reaches the final stage of development.  Generally I recommend that the interim "DO's" be retained under Design Input in the DHF, and only the final DO that outputs to Design Transfer to Manufacturing, be retained under Design Output.  But the company would develop a system that works best for their culture / system, and then specify this in their Design Control SOP and then follow their SOP. 

jel@jelincoln.com

DHFs / D&DFs for Older Products -- Responses to Questions from My Recent Webinar

My responses: 

QUES:  I have been tasked with a project to remediate the DHFs of all our CE-marked products.  This arose from a finding in our audit with our Notified Body.  First, having watched your presentation, it seems strange now that our NB would issue a finding on our DHFs when they have already accepted our Technical Files.  Do you know why they would push us on the “history of development” aspect when the requirement for the Technical File is just “a point in time”?

ANS:  As I mentioned in my webinar, I defer to N-B's on specifics for CE marking.  So I'd recommend that you run your proposed solutions by them.  With that said, my own rationale on your question:  The DHF is an FDA CGMP term and requirement (21 CFR 820) since 1996-7 as you also stated.  The Tech File is a EU / CE-marking requirement, which also requires a section on Design Control, presumably now in accordance with ISO 13485:2016's 7.3 Design and Development Planning (and File), which D&DF is basically the same as the DHF, and proof of compliance to 820.30 or 7.3's 10 requirements.  I have in the past addressed that, as mentioned in the presentation, with a copy of the Des Cont SOP added to the Tech File,  existing at the time of the Tech File audit, together with and a description as to how all its requirements were met in the design / development of the product (and referencing the applicable DHF). 

QUES:  Second, some of these products were originally developed in the 1960’s or even 50’s.  Given the requirement on Design Control was instituted in 1996, can we use that as a cutoff point for documentation in the DHF?  I’ve reviewed the paper files in storage and a few of them go back the 1980’s, but nothing dates back to the actual origin of these devices.  That also presents a problem for defining the start date you promoted.  Any suggestions on how to address that?

ANS:  It presents a problem across the board. Certainly you could use 1996/7 as the cutoff date for the requirement for a DHF. You could address that by your Design Control / Design and Development Planning SOP, which could discuss how your company will provide for "grandfathered" devices.  I mentioned that some companies develop such files for older products anyway as an attempt to capture any available history prior to it all disappearing with personnel retirements, etc.  If your N-B wants a DHF/ D&DF no matter what, this is the approach I'd take. Obviously such DHFs / D&DFs would be very abbreviated with a fairly short narrative as to approximate time of acquisition, method of acquisition (in-house, purchase, contract ...) and any other information so obtained, how obtained, refer to the Design Control SOP on "grandfathered product" and similar, signed and dated by QA ...  

And device changes since 1996/7 on older / grandfathered product, require such files to be developed (with such older products) or amended (with post 1996/7 products).  Another alternative is to develop DHFs/D&DFs for all the older products, with whatever data you're able to capture (I use old lab books, 510(k)s, some companies actually had Project History Files as their own requirement for product development history before it was a regulatory requirement ...) and have an explanation as to why this approach is being taken -- the FDA's history of Design Control starting in 1996/7, and these products predate that.  You may be able to find out some basic data how products were developed (or acquired) by your company for any old documents still available, interviews with retirees or others, current methods which may not have changed much, etc.

Start date unknown:  Obviously "start date" is for a current project (the actual reason for design control), and could also be recorded for a retroactively developed file from recent history.  As I mentioned, I often am called in to address a 483 and retroactively compile a DHF, but this is for products developed after 1996/7, and all that background and reason  for the retroactive compilation is stated in a cover document / narrative, including the reason for any omissions.   

QUES:  Finally, are paper DHFs still common and/or preferred?  Various people in our organization have been pushing for scanning the remaining paper and using all-digital storage.

ANS:  I still see a lot of paper DHFs, but the trend is to electronic records.  In which case, the system and records / signatures used for such a record / file retention system must be validated, including to 21 CFR 11.

jel@jelincoln.com

Are Today's 510(k) Reviews Tougher?

A comment to the following article:
https://mastercontrolinc.blogspot.com/2017/08/is-510k-process-as-worthless-as-federal.html?source=sm-qt

Excellent analysis. My experience over several decades of 510(k) submissions, is that the process and documentation demands have become much more rigorous, with more data required. The 20 hour average cited in your article, if based on actual FDA averages must be considered in light of the fact that the reviewer starts and stops the "clock" when requesting additional information from the submitter. Not exactly like a lawyer bills a client. And that average must also be considered in light of the fact that the majority of 510(k)s are basically "me too" products, i.e., the whole 510(k) process is predicated upon the requirement to identify a "predicate" device, and then prove "substantial equivalence" to it. The principle being that the new device poses basically the same risks (and benefits) as the predicate. and is cleared on that basis. Yes some 510(k) products push the envelope, but then the Agency usually requires an IDE (Investigational Device Exemption) submission leading to clinical trials prior to the submission of the 510(k). I very much agree that today's requirements are much more extensive than those existing in 1982. The e-copy requirement is not only for filing purposes, but to allow the review to easily involve others in the Agency when questions of safety and efficacy arise. Requirements such as Design Control, started in 1996-7, device risk management per ISO 14971, and human factors engineering / usability engineering per IEC 62366-1:2015, and -2:2016, and similar, have also been incrementally added as appropriate. And a growing list of software / hardware requirements. New guidance documents, which state that they are voluntary, but I have found to be required if applicable to a submission, e.g., the documentation required for devices containing software, cybersecurity, et al. The sheer volume of documentation required in a submission between 1982 and 2017, has grown exponentially as a result, and my experience is that it is all given careful study based on the follow-up questions I receive from the reviewer(s).

jel@jelincoln.com

What Medical Devices Require the CGMPs?

Ques:  I have a question regarding FDA Class 1 medical devices which are exempt from GMP. Are Class 1 devices also exempt from the Design history files and the general records needed for design?

Ans:  The question can be taken two ways.  First, not all US Class I medical devices are exempt from the CGMPs, 21 CFR 820.  That's specifically addressed under 820.1 Scope (s)(1) "... of all finished devices intended for human use."  Yes, there are some exceptions . Check for your family of device under 21 CFR 8xx, which will state whether your specific device is exempt.

https://www.fda.gov/medicaldevices/deviceregulationandguidance/overview/generalandspecialcontrols/ucm055910.htm

states that "General Controls" under which all Classes if medical devices fall, including the majority of Class1, include the GMPs.

But, see also:

https://www.fda.gov/medicaldevices/deviceregulationandguidance/postmarketrequirements/qualitysystemsregulations/    which states in part:

"FDA has determined that certain types of medical devices are exempt from GMP requirements.  These devices are exempted by FDA classification regulations published in the Federal Register and codified in 21 CFR 862 to 892.  Exemption from the GMP requirements does not exempt manufacturers of finished devices from keeping complaint files (21 CFR 820.198) or from general requirements concerning records (21 CFR 820.180)."

Also, note 820.30 Design Control (a)(2) list Class 1 devices that are specifically subject to design controls.

So, to determine the exact state of your medical device, you'd have to find its family listing under 21 CFR 8xx, and note what is said regarding FDA requirements.

jel@jelincoln.com

Software V&V "In Brief"

To summarize:

0.  Download FDA SW Guidance documents, especially: 

"Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices", and obtain / generate / group documentation per Table 3 (for all SW V&V, not just devices / 510(k)s:

https://www.fda.gov/medicaldevices/deviceregulationandguidance/guidancedocuments/ucm089543.htm

1.  Establish risk to patient by your company's / product's activities addressed by the software (Level of Concern, ISO 14971/ FMEAs...);

2. Develop a Project Plan (phases, milestones, tasks ...; timelines; responsibilities; I prefer the Gantt chart done on Excel); 

2.  List all your requirements for the software (the SRS), including applicable 21 CFR 11 (e-records / e-sigs); and cybersecurity if networked (especially firewalls, training to prevent opening unknown links, etc). 

3. Write an introductory narrative explaining the system and your validation approach; Write test cases to address all the requirements, e.g., IQ (for installation / hardware meets software rqmts ...), OQ (all software modules exist and initialize and shut down properly; 21 CFR Part 11 issues, especially limited access, audit trail / change history, names tied to files, date / time stamping ..., PQ to repeatedly challenge key operations;

4.  Extract proofs for each test case from retroactive files (for preexisting systems); perform any additional test cases proactivel (or all for new or remodeled systems);

5.  Compile all the above and other documentation (11 categories) into a Test Report / SW V&V File, and sign off.  Most documents can be generated in Word.  Initial /date any copies.

jel@jelincoln.com