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

Risk vs. Risk

RISK  VS. RISK

"Risk-based ...", a source of confusion to the medical products industries.

Some say this should be a generalized approach throughout a company. This is partially correct.  If a company is primarily addressing ISO 9001, then they are focused on ISO 31000, Risk Management, which addresses all manner of business risk.      

   

However, if we are dealing with medical products, the U.S. FDA want to see “risk” tied specifically to to patient (and user) risk.

I have always recommended that companies tie such key medical product risk-based decisions to a Product Risk Document -  ISO 14971 Risk Management File / Report, or ICH Q9;

     -  Cite specific line items, e.g., from a FMECA;

     -  Include “Normal” as well as “Failure / Fault” in Hazard List / FMECAs.

“Risk” in FDA-regulated industries usually means patient risk, not business, IT, legal, etc., risks, though some are obviously tied together.  If you are marketing medical products both in the U.S. and EU / overseas, then your documentation will have to clearly address both types of risk, product / patient, and business.

ISO 14971 patient risk / safety vs. ISO 31000 business risk / “safety”.

Understanding such patient “risk” will determine how far to proceed on test cases, failure investigations / root cause analysis, degree of documentation, etc., needed to resolve a medical product risk issue.

Additional references:

"Pharmaceutical cGMPs for the 21st Century - A Risk-Based Approach", September 2004: 

"FDA has identified a risk-based orientation as one of the driving principles of the CGMP initiative.  The progress outlined below reflects FDA's commitment to the adoption of risk management principles that will enhance the Agency's inspection and enforcement program, which is focused on protecting the public health."  (emphasis added)
 -- https://www.fda.gov/drugs/developmentapprovalprocess/manufacturing/questionsandanswersoncurrentgoodmanufacturingpracticescgmpfordrugs/ucm137175.htm#_Toc84065737 

John E. Lincoln        jel@jelincoln.com

FURTHER USABILITY ENGINEERING Q & A

Ques: The first question is applicability of usability engineering on all products including legacy.  Do we need to go back and remediate all legacy product files that do not have usability? Is there an expectation to remediate or on a forward moving basis as we make changes to legacy products.

Ans:  I'm not aware of any expectation on the part of the FDA to require such for legacy products until they undergo sufficient change(s) to warrant such (which should be defined in your SOP, as determined by your company's analysis of the usability issues your products pose; and a discussion / rationale written - almost a memo to file or "one page" UE File).  For CE Marking, you'd have to talk to your N-B. 

Ques:  Is the expectation that all devices go through usability? For example for a simple device like a syringe where the risk is well understood and low would we conduct usability? Do you have recommendations for how to proceduralize which products we apply usability to?

Ans:  I would analyze all, even if only to have a UE File that basically says it's not necessary, e.g., your example of the syringe.  Of course if it has some non-stick component, then it would probably require such.  Your company would have to make the decisions as to how to proceduralize / decide which to apply UE to.  In my webinar, I basically stated that some products, like needles (not non-stick), have such a field use history over many decades that they probably wouldn't need it, but that decision / rationale should be defined by SOP and recorded per first ans above.

  

Ques:   Annex C of IEC 62366-1 has a statement on user interface of unknown provenance, can you explain the intent of this? Is this referring to legacy that does not have usability documentation?

Ans:  As discussed in the webinar, UOUP, applies to user interfaces for which there is no real UE or similar documentation available from a company / vendor.  How it will be specifically applied I don't yet know -- we'll need some field history.  Pending that, I tend to recommend that it be applied for anything posing a serious UE issue for which evidence of any HF / UE activity hasn't been performed / documented.  The principle could apply for a company's own legacy products. Since the analogy to SOUP software was made, how that principle is implements re: software, might help in defining how to implement UOUP.

Ques:  What class devices does usability apply to?

Ans:  There's no specific reference to class of devices, either US or EU.  Obviously, Class II (and IIa, -b) and III would be more complicated, higher risk, and more likely to require  more HF / UE action -- with new major changes, or new devices, a written discussion / rationale appropriate to need / risk, would be appropriate. General controls / cgmps (includes 820.30 where risk mgmt / HF / UE are employed / documented) are also a requirement for Class I in the US, so address as appropriate, defined by your SOP.

John E. Lincoln  jel@jelincoln.com