Tuesday, March 26, 2019

ISO 11135:2014 and The QMS

A little more on my answer to the question posed after the EO sterilization webinar:
Ques:  I have a vendor ETO a load for me... what do i need to ensure that they let the load sit or air out between PQ runs?    ISO  11135 or FDA requirement?

Ans:  As mentioned early in the presentation, ISO 11135 presupposes the existence of a viable QMS / CGMP system, as well as adherence to the validation requirements of the standard to complete a successful validation.  Since ISO 11135 is an international standard, it specifically references ISO 13485 requirements under (page 11 of the standard) 4 Quality Management System, 4.1 Documentation, and 4.2 Management Responsibility, and 4.3 Product Realization, et al.   ISO 13485 requires, among others, that a company and its supply chain / vendors adhere to the requirements of 13485 for medical devices.  The US FDA recognizes ISO 11135 as a consensus standard, so for the US, the QSR 21 CFR 820, the CGMPs would be the device QMS in lieu of ISO 13485 (both requirements are very similar).  
So such adherence would assure that your question is addressed.  This can be reaffirmed by a Quality Agreement or Contractual Requirement, verified by Certification / Audit, and/or by other means. 
-- John E. Lincoln     jel@jelincoln.com
A vendor must follow your written requirements/specifications, in this case your validated EO cycle, which also should include a defined minimum aeration time under specified, controlled conditions, all documented, a verified copy of which should be supplied and checked by your QA as part of a sterile load release, all retained in your DHR (lot history).  Since EO gas is a carcinogen, aeration is also a safety requirement.  - JEL, 07/07/25 

The validated aeration time is confirmed by a product's EO residuals data, which have been reviewed and cleared by the FDA as part of a 510(k) clearance or PMA approval. Adherence to a validated sterilization cycle should be clearly stated in the PO, or Contract, or Quality Agreement between the company and the contract sterilizer, and cycle parameters for the lot supplied from the vendor, included with the shipment of sterilized product and checked by the receiving company's QA prior to acceptance at incoming, and prior to final release to the field, and recorded in the DHR for that sterile load, and the individual product lots' DHR's from that sterile load.  - JEL, 08/15/2025  

Saturday, March 23, 2019

CRO and Client Disagreement

Here's my further response to the question from the Device Changes webinar of 03/20:
Ques:    What is a CRO's responsibility in educating the sponsor in whether or not the product is a medical device or not? Often times sponsors argue that their product is a cosmetic when it is more like a medical device.
Ans:   As I mentioned, I'm not qualified to directly answer this question.  It goes to the heart of how you as a CRO determine what potential clients you will accept as a formal client, and your legal department's and corporate policies.  As mentioned, as a consultant, I lay out the terms under which I will take on a client, and one of those is clarity of the definition of the project and its scope.  That includes agreement on applicable FDA requirements and definitions.  If the definition is subject to disagreement, then clarify what the proposal will address.
If the definition of cosmetic or device is not clear then define in your agreement just what your services cover, and the approach required by the FDA based on the definition chosen, and that the results are dependent on the chosen definition as it lays out the approaches taken.  This obviously has to be run through your legal department (as mentioned, I am not a lawyer and do not give legal advice). 
You have the right (and responsibility) to turn down clients that will not work with you, and certainly those who will not abide by FDA requirements.
Ref:  https://www.fda.gov/downloads/RegulatoryInformation/Guidances/ucm127073.pdf
Hope that helps.
jel@jelincoln.com

Friday, February 22, 2019

Does the addition of new production equipment require a revalidation of the sterilization process?

To answer that question:  If the particulate count only increases, that will not usually affect the sterilization validation.  If the bioburden load increases then additional verification / testing will be required.  I doubt that the addition of another piece of equipment will increase bioburden, though it will increase particulate (and possibly oil vapor if any compressed air escapes into the controlled environment; should be plumbed out)).  If the equipment also requires additional human handling of the product, then there could be increased product bioburden.
After the implementation of the new equipment, If there is increased product bioburden, then at the very least a half cycle should be run on the product, and then test sterility of some product / PCDs in the most difficult to sterilize locations in the load at a half cycle.  Then either complete the cycle or do a full cycle on the load if that was a production run (with data to prove that additional sterilization runs do not negatively affect product function). 
Generally the addition of some additional equipment into a controlled environment does not create a serious challenge to the sterilization cycle.  Of course, consideration of any potential disruption in the air flow in the clean room by the equipment addition must also be addressed.
Of course document all the above.  Could be an addendum to the last sterilization validation test report.

jel@jelincoln.com
updated 10/20/21
Note:  The above response mostly assumes EO sterilization. - JEL 09/20/2023
However the addition of new equipment / personnel can disrupt the laminar flow in the room, particulate counts (as mentioned above), affecting meeting ISO room classification requirements, etc. - JEL, 02/25/25 

Tuesday, September 18, 2018

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 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.

-- jel@jelincoln.com

Saturday, August 18, 2018

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

*  Above ref is not current.  For a reference to the JVT and a search feature, see:
https://www.pharmaceuticalonline.com/doc/journal-of-validation-technology-0002

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

*  Added replacement URL for JVT, 10/13/23  - JEL

Thursday, July 26, 2018

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) Qualifications.

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

Monday, October 9, 2017

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 -- as mentioned in the webinar the DHF portrays device design  / development over time, its history of development, and to prove compliance to 820.30, design control.  The Tech File is a EU MDR / 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 -- but as I also mentioned in the webinar, the Technical File / Design Dossier (now Technical Documentation) is a "snapshot in time" proving the device meets the requirements of the EU's MDD (soon to be MDR).  I have in the past addressed that, as mentioned in the presentation, with a copy of the Design Control 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).

So, while the Technical Documentation proves compliance to the now EU MDR, et al, at the time of CE-marking, sale in authorized EU countries, it does also include the requirement for a section addressing design control / design and development planning per ISO 13485:2016  7.3 which shows the device's development history over time.  As mentioned in the webinar, this is another example of the documentation on both sides of the Atlantic moving closer toward harmonization. 


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 (date of US FDA implementation in 21 CFR 820.30; ISO 13485 7.3 was changed later) 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. This activity is valuable to a company as it becomes part of a company's IP (intellectual property) . 
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. 
Remember:  Any individual change, and the cumulative changes, since the last cleared company 510(k) require an analysis (documented) as to the need to file a new 510(k), see FDA's guidances on the subject.


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, e.g., IQ, OQ, PQs (or equivalents) , and the 11 documents recommended in my post of 06/28/2017, and including to 21 CFR 11, and cybersecurity, as applicable.

jel@jelincoln.com

Note:  After this blog entry was first written, I received a call from one of my client device companies in the process of an FDA inspection, where the inspector wanted to see a DHF for a product developed prior to 1996/97 and never changed.  I explained the time line mentioned above, the inspector went back to his office and verified that, and came back and agreed with the company.  However, I recommended that the company write up a brief report about the design of the product to the degree known / supported by the company documents, and proof that no changes had been done to the product since 1995, added to and retained with the other DHF's, in order to minimize the issue coming up again. - JEL 01/09/23 

See additional point in 07/12/2021 Blog.
Updated 01/09/2023 - JEL