Saturday, June 11, 2022

Two Major CGMP Non-Conformances - CAPA and "Risk"

I have recently completed US FDA remediation assistance with two companies outside the US, manufacturing product sold in the US - one in Europe, one in India.  They had had several Notified-Body inspections of their QMS to ISO 13485, with great results.  However, they failed their first CGMP inspection by a US FDA CSO.

The key reason for failures in both cases, both resulting in Warning Letters (primarily due to CAPA) were:

1.  Poor CAPA systems and lack of trending; and

2. Wrong definition of risk, as in "risk-based" activities.

Let's focus on the second (for information on CAPA trending, see post of 08.04/2020; for CAPA problems leading to 483 Observations, see FDA's Inspectional Observations DB at fda.gov -

https://www.fda.gov/inspections-compliance-enforcement-and-criminal-investigations/inspection-references/inspection-observations  ).

I find that outside the US, many companies adhere to the basic premise of ISO 31000, i.e., risk is business risk, legislative risk, regulatory risk, schedule risk, financial risk, budget risk, etc.  And these are real risks to a business, and have to be considered.  But - the key point of this blog - those other legitimate definitions of risk aren't what the FDA is focused on when it talks "risk".  

This broader definition of risk exists in US companies selling to the US market as well, but it's not supported by or allowed to perpetuate in the QMS by regulatory inspections, which in these cases are US FDA- administered.  Any confusion over definitions is quickly addressed by the first FDA inspection, and is not supported by any alternate QMS inspection paradigm (unless the company is also selling product outside the US, and thus subject to Notified-body audits as well) as was the case with those companies in Europe and Asia . 

When the FDA talks "risk-based", they're talking about ISO 14971 risk ONLY, i.e., per ISO 14971:2019, "Introduction", pg. vi, para  3:

     1. Risk to patient (safety of the patient in use of the product);

     2.  Risk to the clinician (facilitating the patient's use of the product); and 

     3.  Risk to the use environment.

Nothing else!

Such a definition of risk must permeate the company's QMS / CGMP system, must be part of the product design process (ISO 14971 for devices under Design Control, 21 CFR 820; and ICH Q9 for pharma), and must be part of the Failure Investigation / Root Cause Analysis process in CAPA resolutions, Verification and Validation issues, and similar.

Note:  Another key reason for 483 observations, not part of the above discussion, is failure to follow one's own company's SOPs / WIs, leading to "adulterated" product.   

- jel@jelincoln.com

Updated 06/20/2022 - JEL

Further update:  Recently the FDA has added security risk (i.e., cybersecurity) in it's use of "risk-based". So based on the FDA's use of the word and its context, FDA risk can mean either 1) patient/user/use environment safety risk (ISO 14971 / ICH Q9), or 2) cybersecurity risk (see their Guidance Documents on the subject), which ultimately translates into patient, et al, risk as well. 

One such Guidance Document: "Cybersecurity in Medical Devices:  Quality Systems Considerations and Content of Premarket Submissions", Draft of April 2023, beginning at line 304:

"The process for performing security risk management is a distinct process from performing safety risk management as described in ISO 14971:2019. This is due to the scope of possible harm and the risk assessment factors in the context of security may be different than those in the context of safety.  Also, while safety risk management focuses on physical injury or damage to property or the environment, security risk management may include not only risks that can result in patient harm but also those risks that are outside of FDA’s assessment of safety and effectiveness such as those related to business or reputational risks." . - JEL 08/11/2023 















Wednesday, June 1, 2022

Problem Solving / Problem Avoidance with a Flow Chart

As a consultant, I'm frequently called upon to do CGMP inspections / audits, and/or review or write SOPs.  One of the most frequent US FDA 483 Observation is for company personnel found not following their own SOPs.  How to minimize?

With any SOP I'm auditing or writing, I start with a simple flow chart.  For an existing SOP, I'll flow chart (or try to) the written sequence described.  Often, I can't complete the chart because there is no "flow".  Whoever wrote the SOP did not visit the shop floor, or carefully observe the steps involved in an operation, or replicate the steps themselves, or similar.  And then the company wonders why the SOP isn't followed, or choses to blame the operator for not following or changing the steps outlined in order to do their job (see Dr. Deming  for who's really responsible for this non-conformance / CGMP major violation - the operator or management). 

Whenever I have to write an SOP, I'll observe the actual work / operation being performed, and/or try to duplicate it myself, and then flow chart each key step. Then I write the SOP following the flow verified by the flow chart. I will then usually include a simplified version of the flow chart in the SOP!

Such use of a simple tool, the flow chart, will find problems in existing SOPs (and systems) or prevent their occurrence in SOPs / systems under development.

- jel@jelincoln.com  

Updated 06/20/2022 - JEL

Monday, May 23, 2022

"Requirements" Validation 

A simple way to structure a Validation Test report that involves IQ, OQ, and PQs, or their equivalents:

1.  List all Requirements, e.g., Use-, Functional-, Standards, Guidance Documents, Marketing, Company capabilities, etc;

2.  Pull out those Requirements that deal with Installation (e.g., software in hardware, equipment in the facility, etc); and place these into an IQ / checklist;

3.  Take all the remaining Requirements and place in the OQ, writing at least one test case for each Requirement (the number of test elements in a test case is determined by risk to the patient / end user of the action / component / factor produced by the activity being validated);

4.  Take those OQ Requirements and determine which can be impacted by "allowable worst case variances" in your company, and place those also in the PQs, which are challenging repeatability, replicatability, reproduceability.  

E.g., if your company runs 24/7 and you're validating a piece of production equipment, you might have one PQ for the Day Shift, one for Swing, and one for Night, also one for Weekend / Sunday, and one for the next upcoming Holiday, for a minimum total of 5 PQs. 

If you're validating smart instruments usage and/or their applications / software / firmware, you might have 1 PQ for an Apple phone iOS, 1 for an Android phone, 1 for an iPad, 1 for a Tablet, 1 for a Mac laptop, 1 for a Windows laptop, 1 for an Android laptop, 1 for a Mac computer, 1 for a Windows computer, 1 for a Unix computer, or 1 for a workstation and / or 1 for a Server, and/or 1 for Mainframe, depending upon what smart instruments are allowed for use in your company *. 

Note:  the FDA has backed away from a de facto "rule of three" PQs.  You determine the number based on the above discussion.  In no case can you have less than three, in order  to prove the  3 "R's" listed above pertaining to the purpose for the PQ (to prove repeatability / reproducibility / replicatability using "allowable worst case inputs"). **

See Q&A #5:  https://www.fda.gov/drugs/guidances-drugs/questions-and-answers-current-good-manufacturing-practice-regulations-production-and-process#5  *. 

And PQ test cases would have many samples (vs. OQ test cases, which basically verify the existence and proper operation of a Requirement; hence I usually include Part 11 and cybersecurity test cases in the OQ), e.g., n=30, or n=125, or n=525, etc. (with justifications for sample sizes chosen).

I like to also have each PQ have a Shut Down, Cool Down and Start Up cycle Test Case included.

I also like to have one Unplanned Power Outage ("Pull the Plug") Test Case for all the PQs, if feasible, and definitely for software / firmware V&V to test UPS' / back-up generator functions.

- jel@jelincoln.com

08/03/23 added "back-up" to generator. - JEL

* 10/13/23 added "depending" phrase to end of para. 7. And added source for the demise of the "rule of three". - JEL

** 05/01/24 added parenthetical phrase at end of note. - JEL

       

 

Test Method Validation

Ques:  Test Method Validation, when is it required?  Only on CTQs (critical to quality)?  What is the logic behind determining if its applicable?

Ans:  Whenever you use a test to address a CGMP requirement, it is your responsibility to ensure that the test is appropriate to need and yields accurate results (see US FDA's  Data Integrity Guidance Document).  If it’s defined by a standard, USP, or similar, then it can be used as-is, ‘tho’ I would recommend some minimum verification of your company's usage, documented, initially and periodically to ensure that all variables behave as expected. 

If it’s a variation on an established test, or new / developed in-house, then it would need to be validated. 

If a test is used on CTQs, then the degree of patient risk (e.g. ISO 14971 or ICH Q9) needs to be considered as to the rigor / depth of the validation, and frequency of checks / verifications that the validation does not need to be re-done.  You as a company make these decisions, and document them, though they are subject to challenge by a regulatory inspector.

How your company addresses the above, under what conditions, would be outlined in a company SOP.

-  jel@jelincoln.com

Monday, January 3, 2022

 Disclaimer


The information provided in this blog is taken from sources and material which we believe to be reliable, and/or express the opinions of the writers and/or presenter. In such condensed and generalized form, the material certainly should not be considered a complete study or report on the subject mater, especially as to how it might relate to a specific company / user’s application. Conclusions are based solely on available data, and the judgments and analysis of technical factors offered are not intended to replace the utilization of additional research and/or appropriate professional counsel in adapting material to a specific application.


© 2022  by J. E. Lincoln and Associates LLC.  All rights reserved.  Reproduction in whole or in part without written permission is prohibited. 

Also, I may reread a blog and notice a typo, grammar problem, spelling.  If so, I'll usually correct that at the time without a notation.  However, if I feel I need to change, update, omit or add information, I will add a note explaining the change / update and the date. - JEL 09/19/2023 



Tuesday, November 9, 2021

 

Audit Core Matrix – Device CGMPs Documentation Review:  Systems, SOPs, records, et al, (references are to 21 CFR Part 820, Quality System Regulation:

 

Subpart                Description                                                     Reviewed (‘Y’ or ‘N’) / Comments

 

  A                           General (820.1, -.3, -.5)  

  B                           Quality System Requirements    (820.20, 

                                -.22, -.25)

  C                           Design Controls (820.30)                

  D                           Document Controls (820.40)       

  E                           Purchasing Controls (820.50)      

  F                           ID and Traceability (820.60,  -.65) 

  G                          P and PC (820.70, -.72, -.75)                                                        

  H                          Acceptance (820.80, -.86)              

  I                           Nonconforming Product (820.90) 

  J                           CAPA (820.100) 

  K                          Labeling and Packaging Control (820.120

                               -.130)                

  L                          Handling, … (820.140, -.150, .160-.170)                                                         

  M                         Records (820.180, -.181, -.184, -.186, -.198)                                                         

  N                          Servicing (820.200) 

  O                          Statistical (820.250)


-- jel@jelincoln.com

Monday, November 8, 2021

The Virtual / Remote Compliance Audit


The following three posts address an approach to virtual / remote internal or vendor audits;  starting with the final report, then the conduct of the Audit, then back to the Audit Plan.  Use a video conferencing app, solicit key documents in e-form prior to audit.  Then follow the Audit Plan with a discussion of each element with the team, requesting any supporting documentation in e-format, or similar, camera pix, or similar.  


Remote / Virtual Audits - Internal or Vendor Audits -  The Final Audit Report


 

ISO 13485  COMPLIANCE  AUDIT  REPORT

 

 

 

CONFIDENTIAL

 

 

 

 

Prepared For: 

 

         

                                                          

                                                          

 

 

 

 

Site Audited (Remote / Virtual):

 

     

 

 

                                                          

                                                                       

 

 

___________________________________________________________________________

 

J.E.LINCOLN and Associates LLC                                                                                phone     435-840-0252

P O Box 2786                                                                                                                       

St George  UT  84771-2876                                                                                            www.jelincoln.com                                                                                                                                                   e-mail     jel@jelincoln.com

 

 

 [page break]

 

COMPLIANCE AUDIT REPORT  

 

CONFIDENTIAL

 

SITE:                                                   

 

AREA(S) AUDITED:

 

AUDIT TEAM:           John E. Lincoln

 

DATE(S) OF AUDIT:

 

DATE OF REPORT: 

 

PERSON(S)

         CONTACTED:  

 

[page break]


 

01.  INTRODUCTION:  [Background, scope, team, process, timing, approach …]

 

 

 

03.  MAJOR  FINDINGS  AND  OBSERVATIONS:

 

[Completed Matrix findings and expamded discussions of findings]  

 

04.  RECOMMENDATIONS:

 

Signed:                                     

 

Printed Name: John E. Lincoln

 

Date:               

 

 

-- END OF  AUDIT  REPORT BODY –

 

 

 

Attachments:                 1 – ISO 13485:2016, Filled-In Audit Matrix

                                       2 – Current Company SOP Listing.

                                       3 – Audit Plan

4 – Audit Flow Chart


-- jel@jelincoln.com