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

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

Update: The FDA has implemented new features to its 510(k) program, such as STeP and Breakthrough, under its  510(k) Modernization Program, to allow more devices that "push the envelope", i.e., what they call "beneficial iteration", to be included at the 510(k) level of review rather than the time consuming and more costly PMA (and to some degree the De Novo) process, with their attendant clinical trials. - JEL 10/20/2021

Update:  As of October 01, 2023, 510(k) submissions are only allowed under the FDA's new eSTAR electronic portal. - JEL 05/01/24

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 a spreadsheet); 

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, and cybersecurity (if networked), ..., PQ to repeatedly challenge key operations, especially addressing "allowable worst case" variables (I usually have one PQ for each allowable variable, e.g., 24/7 shifts(if that's what's used for this product's routine production = 1 (or more) PQ for day, 1 for swing, 1 for night, 1 for weekend/Sunday, and 1 for next holiday (the PQ test cases are the same, only the shift changes for each PQ); if validating software used by the company on different hardware platforms, use 1 PQ for each hardware platform / operating system, e.g., 1 PQ for an I phone, 1 for an Android, 1 for an I Pad, 1 for a Windows Tablet, and so on.

4.  Extract proofs for each test case from retroactive files (for preexisting systems); perform any additional test cases proactively (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 a word processing app.  Initial /date any copies.

jel@jelincoln.com

Updated 10/20/2021; 09/06/2023

See also entry of 05/23/2022 on Requirements Validation. 

The Guidance Document on software and 510(k) submissions has recently been revised - among other changes there are now only 10 categories. - JEL 09/19/2023

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 wants to see “risk” tied specifically to to patient (and user) risk. The recently revised ISO 14971:2019 requires the patient risk be considered in all applicable company's QMS systems.  

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

     -  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 / financial risk / schedule risk / compliance risk / “safety”, et al.

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."  (bottom paragraph, page 3; emphasis added).

 - https://www.fda.gov/media/77391/download

John E. Lincoln        jel@jelincoln.com

Updated 05/23/2022; 06/20/2022

ISO 14971:2019 in its Introduction defines risk as 1) Patient risk; 2) User (clinician ...) risk; and/or 3) Use environment risk. - JEL 02/06/2023  

ISO 14971 is risk management for devices (and the device's QMS); ICH Q9 is risk management for drugs. Recently, the FDA has also used "risk" in the context of security risk, especially related to cybersecurity issues, but even here the emphasis is on patient safety. - JEL 09/06/2023 

... and CGMP compliance risk, which also emphasizes people risk. - JEL 10/20/2024 

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 implemented, 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 management / 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

USABILITY  ENGINEERING / HUMAN  FACTORS  ENGINEERING -- THE NEW IEC 62366-1:2015, and IEC/TR 62366-2:2016

Some answers to some questions raised on my webinar on the above subject:

Ques: Examples of FDA HF guidance documents, etc?:

https://www.fda.gov/MedicalDevices/DeviceRegulationandGuidance/HumanFactors/ucm119190.htm#guidancehf

As mentioned, use the search box in upper right on FDA web site, as well as links from the above link.

Ques:  HE75?

Ans:  The ANSI web site sells both HE75 and IEC 62366-1:2015 together, and states:

"The ANSI/AAMI HE75 and ANSI/AAMI/IEC 62366 Human Factor Set addresses a broad range of human factors engineering (HFE) topics in a structured format. The material emphasizes adoption of a user-centered focus throughout the product design and development process, with the goal of making medical devices easier to use and less prone to use error. By providing a structured approach to user interface design, this set documents can help manufacturers develop safe and usable medical devices.

• The ANSI/AAMI HE75 and ANSI/AAMI/IEC 62366 Human Factor Set includes
• ANSI/AAMI HE75:2009 (R2013) (ANSI/AAMI HE 75:2009 (R2013))
• ANSI/AAMI/IEC 62366-1:2015"

http://webstore.ansi.org/RecordDetail.aspx?sku=ANSI%2FAAMI+HE75+and+ANSI%2FAAMI%2FIEC+62366+Human+Factor+Set&source=google&adgroup=ansi-aami&gclid=CjwKEAiA0fnFBRC6g8rgmICvrw0SJADx1_zAwESZsbs9ED83LJflK_Qq0H773imIq4qMb-lGfKA12hoCrbnw_wcB

Not too helpful in my opinion.

The FDA allows you the manufacturer to determine how to address (and they allow plenty of leeway as long as the requirements are addressed by your procedures , and you follow your own procedures).  For CE-marking, work with the preferences of your Notified Body, following the general outline presented in the webinar / standard (the 9 stages, documented in a Usability Engineering File), and and  with consideration of the new EU MDR.

I still believe that the new IEC 62366-1:2015 is the documented process to follow with all current and further UE projects, following and documenting the 9 stages in the UE File as we discussed in the webinar.  The FDA and ANSI/AAMI HE 75 and others could be used in the actual HF/UE analysis where appropriate for ideas, but the documented process should follow IEE 62366-1:2015's 9 stages and the document deliverable in the UE File.

I suspect it will take awhile for some consensus in implementation to build (with the EU implementation).  But I believe that the "end" result will be similar to what I've outlined above. 

-- John E. Lincoln  --  jel@jelincoln.com 

For the basic UE / HF process to follow (and for the basic format of a UE / HF Product File), use the 9 stages defined in IEC 62366-1, worldwide; for the specific UE / HF techniques to employ, use the various other UE / HF standards and/or guidance documents, as applicable. - JEL 03/27/2024 

"Catchup" 510(k)s

This issue was posed by an attendee at my recent webinar on Device Changes and the 510(k),
discussing FDA's K97-1 and their two new August 8, 2016 draft guidance documents.

We have several older devices that were cleared in the late 90's. These have gone through several changes over the years that were all justified as being not significant, so no new 510(k)'s were filed. We have heard about companies in our industry doing what they would consider "catchup" 510(k)'s where they are essentially submitting a 510(k) every so often since the creep effect tends to happen even if they do not see all of the changes as necessarily justifying a new 510(k) per the regs. We would like to do this with some of our products. My questions are 1. Have you ever seen/heard of this approach and would you recommend it and 2. If we did this, obviously it would be for all of the changes that have already taken place on the device so how would that affect the marketing of your device during the review? I know you mentioned that if you had a change and decided to submit a new 510(k) you would obviously have to wait on the FDA's approval before enacting that change, but all of our changes have already been enacted. Would you need to wait until your next change/come up with a small change to submit a new 510(k)?

My responses:

QUES 1. Have you ever seen/heard of this approach and would you recommend it?

ANS:  Tho I've heard of it occasionally I don't recommend it.  I view it as a waste of the company's money and the FDA's time.  

I've repeatedly seen FDA Investigators have no problems with routine changes to devices having the last 510(k) dated from the early 1990's, subject to the following caveats:  

IF the principles of design control are used for the changes (820.30)(remember design control came on in 1996-7, so while a DHF and the other 8 elements weren't a requirement before the mid-90's, they would  be for the changed device after); 

AND/OR CGMP document / production process change control is rigorous (820.40 and 820.70), well documented; 

AND fully supported by patient risk management (ISO 14971), usability (human factors) engineering (IEC 62366-1, -2); 

AND applicable verifications (tests) and validations (sum total of tests for a device/process/equipment), as appropriate, fully / scientifically support the decision; 

AND the points in the webinar per K97-1 (and the drafts) are followed / documented;

AND all the above lead to an honest decision that each change, And the cummulative changes, DO NOT raise new issues of safety / effectiveness (or the mandatory issues for a new 510(k) like Indications for Use, Performance ... aren't applicable...).  

"Catchup" is not an FDA term or requirement per se.  It is only applicable if one of the two points emphasized in the FDA memo / guidances and the webinar apply:  

1) the last change is major enough to raise new issues of safety /  effectiveness; or 

2) all the cummulative minor changes, with the last one being the "tipping point" considered together, now raise new issues of safety / effectiveness. 

The K97-1 and the two drafts emphasize that it is the company's responsibility to make the decision re: need for a new 510(k), and that most device changes handled under the QS Regulation (21 CFR 820) will not require a new 510(k).

To do "catchup" just to play it safe to me is a cop out (trying to push the company's responsibility to make that decision into the FDA's lap) against the above disciplines that have to be in force at a company anyway for it to be CGMP compliant.  My opinion. 

QUES 2. If we did this, obviously it would be for all of the changes that have already taken place on the device so how would that affect the marketing of your device during the review? I know you mentioned that if you had a change and decided to submit a new 510(k) you would obviously have to wait on the FDA’s approval before enacting that change, but all of our changes have already been enacted. Would you need to wait until your next change/come up with a small change to submit a new 510(k)?

ANS:  My answer to the above is the same as my discussion on the slide about a "wrong" decision, tho in this case it is the company, not the FDA, that thinks the company should have filed a new 510(k) for an earlier change. 

Again, the issue is if the last change(s) raised new issues of safety and efficacy that cannot be fully settled by test (V&V) data, or are expressesly called for in the K97-1 / guidances (as mentioned in 1 above), then a new 510(k) is required.

If a new 510(k) is required for safety / efficacy issues, or the other reasons mentioned in K97-1 / draft guidances (not just a general "catchup"), then the version(s) having the new safety / efficacy issues cannot be marketed until cleared (by a cleared 510(k)) by the FDA. 

The version of the device having those previous changes up to the point where those new issues are raised can continue to be marketed / sold.

If the decision to file a new 510(k) is based on new safety / efficacy issues (not just "catchup"), you would file at the point of that finding, e.g., due to an internal audit, FDA audit, etc., and not wait to have another change before filing.

Any time a new 510(k) is filled, all changes to the device, from  the last cleared company 510(k) to the time of filing the new would be included in the new submission.

Once the new 510(k) is cleared by the FDA, the cycle above (and as discussed by the webinar and in the guidances) starts over, with the new, cleared 510(k) as your new device "baseline".

[note:  K 97-1 and the two draft guidance documents on device / software changes have been replaced by two new guidance documents (on devices, and on software in devices or as a device) on evaluating changes as to need to file a new 510(k)]

John E. Lincoln    jel@jelincoln.com

Updated: 06/20/2022

V&V of Browser

Recently an attendee at my last V&V workshop asked about validating a browser used on their iPads at their company.  It was a new one on me. 

My initial reply:  
However, since you are using the browser only for viewing - that's your requirement - you'd just need to verify that the views you pull up are correct.  So I'd write a description of the scope / purpose, state your requirement(s), do a brief IQ (desired browser(s) there), OQ (browser(s) operate), and PQ(s) (browser information is correct), consider any applicable Part 11 issues under OQ, and this may be an exception to my class recommendation on number of PQs.  One PQ, having a small sample, say n=30 (use my citation for n=30 in your narrative, from Juran and Gryna's "Quality Planning and Analysis"), might be sufficient, basically comparing what you pull up on the browser(s) being used in your company, with another source(s) / alternative browsers.  The risk seems to be low to non-existent, so I'd analyze risk in the document to justify the minimal verification effort.  If you've already validated the use of the iPads in your use environment, perhaps some of your tests involved use of a browser, and you could add an addendum to that validation to specifically reference the browser usage, and that there were not problems noted.

Also, there is no guidance document on browsers.  Any browser use is probably not a serious issue for validation, in that basically what it does is find a URL, or a subject on some server based on what you type in.  Then you in a sense verify the results when you check what was found against your request.  Browsers are not responsible for accuracy of content, which the user is responsible for.  Depending upon how you use it, you may be able to show that there's nothing to verify in its operations.  If so, I'd write that as part of the rationale or justification for not doing a V&V and include it in the file, or make that the brief file.