No need for a DHF *

* If among most US Class 1 devices, and/or the Class 2 or 3 device was developed prior to 1996-7, and no device changes made since. 

I was recently contacted by a client who was in the middle of an FDA inspection.  The Inspector was questioning why one of their product's lacked a DHF (Design History File, 21 CFR 820.30; Design and Development File, ISO 13485 7.3).  I had previously inspected that company and found no problems, and had in fact done some of their current and "retroactive" (for missing) DHFs.  I had also done some 510(k)s for them, and as part of such a project, I also did the associated DHFs, since the 510(k) draws much of its information from documentation identical to and/or contained within or referenced in the DHF. 

After the initial, typical "panic" reaction to a possible 483 observation of an area of the company we were justifiably proud of (and I had previously inspected) passed, we checked their records and verified that the product in question was developed prior to 1996-7, as proven by their 510(k) for it, and that there were no changes to it since (based on visual checks, 510(k) and current documentation comparisons, and change history data reviews; it was a needle). They did have a Device Risk Management File (per ISO 14971) for that family of products that also covered it, so that was not an inspection issue.

The Inspector took this additional information back to their office and supervisor, and then later indicated that the FDA agreed with our rationale and would not be writing a 483 observation for that issue. 

Two previous FDA inspections had never raised this issue. 

I recommended the client  add a "Memo to File" / "one page DHF" to their DHF files for this product (and any similar older, "grandfathered", unchanged product), detailing the above points, to eliminate any similar questions / challenges during future inspections. 

I also mentioned that while they were compiling such a "Memo to File / DHF", if additional provable / documented information was available that pertained to that product's development, it could certainly be so noted and included in the "Memo / DHF", for future reference and/or company IP purposes.
 

See also my blog post on "DHF's ...", dated 10/09/2017, below. 

Note:  Even for older, pre-1996-7 developed devices, I encourage companies to develop a retroactive DHF, to the degree possible, to capture available development history before it disappears due to employee turnover, retirements, deaths, etc., for IP purposes, assist in Root Cause Analysis, training, line extensions / product improvement, future 510(k)s, and similar.   

-- jel@jelincoln.com

A Key Cybersecurity Vulnerability

The easiest hacking / entry point to networked computer systems is company personnel clicking bogus links in e-mails, pop-ups, or simulated trusted sites (often with a minor change in the URL, like a "1 (one)" for an "l (el)" or "i (eye)", and similar).  Difficult to address:  Frequent reminders / traininig, IT unannounced simulations ...

- jel@jelincoln.com

 

Vulnerabilities and Risk in  Cybersecurity

FDA states that a cybersecurity vulnerability exists whenever the software provides the opportunity for unauthorized access to the network or the medical device. Cybersecurity vulnerabilities open the door to unwanted software changes that may have an effect on the safety and effectiveness of the medical device.  Failure to properly address these vulnerabilities could result in an adverse effect on public health. A major concern with OTS software is the need for timely software patches to correct newly discovered vulnerabilities in the software.

The FDA recommends that the manufacturer conduct a vulnerability analysis, both initially (premarket) and ongoing (post-market).  The approach should appropriately address the following elements: 

·         Identification of assets, threats, and vulnerabilities;

·         Assessment of the impact of threats and vulnerabilities on device functionality and end  users / patients;

·         Assessment of the likelihood of a threat and of a vulnerability being exploited;

·         Determination of risk levels and suitable mitigation strategies; and

·         Assessment of residual risk and risk acceptance criteria. 

As mentioned above, and especially software / firmware, initial design and subsequent continuous improvement activities must consider hazards / risk, per ISO 14971.  Such risk is focused on the end user – patient and/or clinician.   The hazard analysis should address both “normal" as well as “fault” risks, i.e., not just failure mode risk, the most prevalent approach, but also risk posed by the proper function of the product.  In such an analysis, the manufacturer must also consider cybersecurity as part of this regular hazard analysis. Exposure to the web, as in the networked devices focused on in this guidance, increases such cybersecurity risks to the patient / clinician.  Hazard / risk analysis’ goal is risk mitigation, documented in the Risk Management File and Report (ISO 14971), as well as in the Design History File (21 CFR 820.30).   Consider system boundaries, and connections to the external environment. In all such analysis, software must be considered with its associated hardware. 

The above is to be supplemented by on-going monitoring of actual and potential vulnerabilities,  consistent with the Quality System Regulation (21 CFR part 820), including complaint handling, internal quality audits, CAPA (corrective and preventive action), software validation and risk analysis, and servicing.  Such programs should emphasize addressing vulnerabilities which may permit the unauthorized access, modification, misuse or denial of use, or the unauthorized use of information that is stored, accessed, or transferred from a medical device to an external recipient, and may impact patient safety. 

The Agency defines critical components of such a program to include:

·         Monitoring cybersecurity information sources for identification and detection of cybersecurity vulnerabilities and risk;

·         Understanding, assessing and detecting presence and impact of a vulnerability;

·         Establishing and communicating processes for vulnerability intake and handling;

·         Clearly defining essential clinical performance to develop mitigations that protect, respond and recover from the cybersecurity risk;

·         Adopting a coordinated vulnerability disclosure policy and practice; and

·         Deploying mitigations that address cybersecurity risk early and prior to exploitation. 

Postmarket cybersecurity information may originate from an array of sources including a company’s own CAPA / warranty / complaint system,  independent security researchers, in-house testing, suppliers of software or hardware technology, health care facilities, and information sharing and analysis organizations. To manage postmarket cybersecurity risks for medical devices, a company should have a structured and systematic approach to risk management and quality management systems consistent with the CGMPs.

- jel@jelincoln.com

Cybersecurity

Cybersecurity is a growing concern for all – legal, financial, consumer, personal, and …

 Cybersecurity is a recent concern for the medical products industries, a result of their increased reliance on networked electronic software, records and signatures.  Initially there were regulations such as 21 CFR Part 11 in the U.S. and Annex 11 in Europe.  But more must be done to ensure the integrity of CGMP documents / records.  Cybersecurity is an issue that will only increase over time, as records become more electronic, and communications are more networked or accessible.

 As a result, the US FDA has issued the following Guidances for Industry:

1.       “Cybersecurity for Networked Medical Devices Containing Off-the-Shelf (OTS) Software     Document”,  issued on: January 14, 2005; and

             2.      “Content of Premarket Submissions for Management of Cybersecurity in Medical                                     Devices”, issued on: October 2, 2014; and

3.      “Postmarket Management of Cybersecurity in Medical Devices” -- Draft Guidance, issued             on: January 22, 2016

As the titles above indicate, the focus is on medical devices.  But the principles can and should be applied to a company’s computerized systems as well.  In this article, we will also focus on devices, but will also draw attention to company computerized systems where appropriate, to flag related potential problems with an e-records based QMS, computer-facilitated production and/or test / lab equipment / systems.

Of necessity, cybersecurity in the medical products industries is coming under increased regulatory review.  Regulatory agencies leave the how of cybersecurity compliance up to the manufacturer, as long as the principles in the guidances are met in the resulting product and/or system.  Related issues are primarily addressed by the CGMPs, specifically design control (21 CFR 820.30) for devices, and post-production by the CAPA system, among others.

- jel@jelincoln.com

Part Validation for Single Lot Run

Ever have the need to validate one lot of parts from a vendor.  Here's some ideas, based on a one lot run off a new molding tool by a vendor prior to shipping the tool off to the manufacturer to be used in on-going production.  One possible approach --

________ Molding Validation Outline

John E. Lincoln

1.    1.  Purpose:  To provide a short term one-lot validation of the Injection Molding Press, New Tool, and resulting small one-time run of a [part]  lot of approx. [quantity] pieces, to be done by a contract molder  [name, address]. After this run the tool will be shipped to [destination] for ongoing production. Once the tool is received by [Manufacturer], it will be formally validated in dedicated press(es) for subsequent production runs. The [part] is a low patient / user risk part [supported by ISO 14971:2019 Risk Management File].

2.      2.   Name / address / contact of SLC Molder / Vendor;

3.       3.  Injection Molding Press:  [Description – Manufacturer, Model, S/N, capacity];

4.       4 .  Tool / Mold Description / Number, cavities …;

5.       5.  [Part Description], P/N, P/N Specification, Lot Number, Quantity [total, fall-off, released];

6.      . 6.  Press calibration data (on gauges for:  Injection Pressure, Time, Tool Temperature …;)

7.       7.  Molding Set-up Card true copy;

8.       8.  Molding Lot / Batch actual press run data  [Injection Pressure, Time, Tool Temperature …] true copy;

9.      9.   Part’s 1st Article Test Results true copy;

10. 10.  Part’s QC In-process test data (if any) true copy;

11.  11.  Part’s QA Finished Part test /release data true copy;

12.  12.  Any Deviations, Non-conformances, Change Orders, if any, and how resolved – true copies (see below).  

13. 13.   [Manufacturer]  receiving / IQC test data for this lot.

For these purposes, a true copy can be a xerographic copy, certified on each  document as a “true, exact, complete and unaltered” copy, and signed and dated by an authorized representative for the vendor.  Either each document so annotated, or a collective single “certificate” listing each of the documents, stating the above, and signed / dated by an authorized representative for the vendor.

Provide above to assist in drafting a “mini-validation” for that lot, based on the above outline, for [the Manufacturer's] files.

14.  Results:  Once the above data is gathered, compare the set-up data, the run data / parameters, the 1st Article data, the In-process QC and final lot QA test / dimension data, to the part drawings / specifications, add functional test data (including any destructive stress testing), assembly test data, visual inspection data, et al.

15.  Conclusion:  Evaluate the requirements for the part to the actual results of the  parts in the lot run, and write up the conclusions.

Follow up with a formal validation of the tool in it's assigned injection molding press(es) for continued production.

-- jel@jelincoln.com

 

Further on:  "DHFs / D&DFs for Older Products -- Responses to Questions From My Recent Webinar" (see 10/09/2017 blog):

I recently reviewed my response to the above and feel the need to add an important qualifier.  Yes the US DHF / EU D&DPF provide the development history of a device, while the EU Technical File / Design Dossier / Technical Documentation files are primarily a "snapshot" in time, the current description of the device and how it meets the requirements of applicable EU regulations, especially the old EU MDD (Medical Device Directive, especially the Essential Requirements) and now the EU MDR (Medical Device Regulation, especially the General Safety and Performance Requirements).

The point I failed to sufficiently emphasize, and why Design Control / Design and Development Planning is to be addressed in the first place, in the EUs Technical Documentation File (and why it is a focus of a device CGMP compliance inspection by the FDA), is not just for the development history over time (which is also valuable IP), but primarily for design control, i.e, control / evaluation of the changes in the design as it evolves during R&D and prior to Design Transfer for manufacture.  

When Design Control, 21 CFR 820.30 was added as a CGMP requirement in 1996-97, it was emphasized by FDA spokespersons such as Kim Trautman, that it's primary purpose was to control / formalize design changes under a review (2nd party) and verification system, in the previous poorly controlled R&D change control environment.  This was to address the fact the FDA had identified in its post-production device monitoring, that changes to a device under development were often reactive to one problem, and then not fully vetted as to it's positive effect on a problem, but also not evaluating  any possible negative effects, which need to be identified and eliminated.  The DHF / D&DF documents the design process, including such changes, resulting in a safe and effective device, with minimal to no design flaws that could negatively impact a patient / end user.

-- jel@jelincoln.com

 

My response to a query from one of the participant attended my webinar “Design History Files (DHF), Device Master Records (DMR), Device History Records (DHR), Technical Documentation Files”. 

 Query : Thank you for this webinar – I definitely learned a few things. I had asked a question about whether a full PV on the fully scaled up manufacturing process was required for EU MDR submission – and you indicated yes.  We have also had that interpretation from at least one other person.

Ans:  My answer was more geared to the FDA. For EU MDR, double check with your Notified-Body.  But things can happen from pilot to scale up, hence my answer.

Also my comments on "Like For Like" -- isn't!  There's always subtle differences in so-called "identical" equipment / processes, which must be addressed in a verification or validation, albeit perhaps in a reduced format, depending upon user / patient risk, and or nature of the potential variance. 

Ques: I was just thinking that through and am wondering if that means we need to expand the scope of our Design Inputs to include the stages of Process Transfer and Validation?

We use a DIOVV Matrix – Design Inputs, outputs, verification, and validation – and start with a stakeholder need that then translates in to one or more design inputs.  And of course then the design outputs, verification documents, and validation documents as appropriate for each design input get listed.

Just wondering if we need to add a section to the DIOVV so that we address Process Transfer and Validation?  Would you consider those things as legitimate Design Inputs??

Design inputs really are very tricky things – we spend a lot of time debating them.

 Ans:  Agreed. As I mentioned in the webinar, the definitions of DI and DO elicit strong opinions, and when I meet with clients on Design Control, we spend the majority of a session just on those two elements of the 10 in Design Control.

Bottom line as mentioned in the webinar:  You as a company define what will be a DI and a DO, as DI’s become Interim DO’s become interim DI’s, ad infinitum. Certainly the initial DI’s would be under the DI category, as would the final DO’s be under the DO category, with the interim DI’s and DO’s being placed where they are easiest to understand per your company’s methods / definitions, as spelled out in your SOPs.   

https://www.fda.gov/media/116573/download  

Notice last para (2^nd half), pg 3, Concurrent engineering pg 5, discussion on DI and DO, pp. 13-21, note especially the root problem on the top of page 20 “The design output in one stage is often part of the design input in subsequent stages.”

... and Design Transfer per 820.30 is a separate / discrete step / milestone in the R&D project subject to Design Control, i.e., one destined to commercialization (see below).

Ques: It’s potentially an interesting paradigm shift because typically R&D ‘owns’ the DIOVV – we do Process Transfer – and Operations executes the final PV(s) – and so this would mean engaging Operations earlier in the Development Process, which might be a good thing.

Ans:  Under Design Control, Design Transfer is a formal discrete activity.  But per Concurrent Engineering in the above referenced Guidance documents, it goes easier if all stakeholders are involved in the project from the very beginning as mentioned in the webinar, and the “good thing” you mentioned above – I would expand the early participants to more than operations, including manufacturing / production, manufacturing engineering and QA/QC and RA and others. I practiced that with new product development in the 1980’s to great effect with minimal “surprises” and meeting schedule.

-- John E. Lincoln

jel@jelincoln.com

My responses to questions re: my recent webinar on cybersecurity:

1.  The System Administrator is a key weak link?  How can we address that?  

Ans:  The Sys Ad can make changes to the program to adapt to user needs; this can be abused.  It needs checks and balances.  All changes should be documented by the Sys Ad; evaluated as to need for V&V, with rationale; that documentation / log(?) / lab book(?) should be reviewed and signed off / approved by an independent party (QC/QA?). The  Sys Ad should be a reliable CGMP / QA/RA-inclined IT individual;

2. We're moving more of our applications and storage to the cloud.  What should we be focusing on to reduce risk?  

Ans:  Focus on the cloud provider; do they understand and agree to the need for CGMP / change control, understand the need for their clients to validate the cloud programs and are willing to give advance notice of anticipated changes well in advance of such changes to allow the client to perform any necessary regression testing, V&V; 

3.  It seems that phishing attacks are growing.  How can we compensate for the weak point - our people? 

Ans: Weak point is people. Follow the NIST guidelines discussed to train personnel on how to scan e-mails, pop-ups, websites, et al, as to authenticity (of URL, site ...) vs. spoofing, check the URLs (look for purposely misspelled URLs), avoid the unsolicited content and go back to the actual source from their own addresses / URL, rather than clicking the furnished link;  Train with unsolicited / unannounced company IT-initiated phishing "attacks" periodically (with personnel informed that such "tests" are part of the job; but not told when or what means to be used).

4.  Where in the software V&V should we best add cyber tests?  

Ans:  The OQ, since the primary goal is to prove the requirement has been met, does what it should do, and doesn't do what it shouldn't;  if there is allowable "worst case" input variability in the company's implementation of that requirement, due to platforms, shifts, types of records, etc., then also expand that OQ test case into a PQ test cases with several PQs, each with many samples (with rationale for sample number selected included in the protocol).

-- John E. Lincoln

   jel@jelincoln.com