Medical Device Regulatory Career Training:

A recent question from one of my webinars and my response:

I attended the recent Medical Device labeling webinar and I have a question... 
Mr. Lincoln, as someone who is just getting started in my work with medical
devices, would you recommend the RAC training and certification? Is there
another training that you would recommend that will help me understand the
registration process as well as make me an appealing candidate for medical
device roles?
I appreciate any advice you can offer!

My answer:  

RAC certs are useful to employers to see a basic level of expertise in devices.  I also recommend knowledge of technical writing, verbal communication skills, ability to read drawings / drafting, some basic business / industrial statistics / 6 sigma / SPC.  Learn the basics of the 510(k) and the applicable CGMPs (devices are 21 CFR 820) which can be self-taught off the FDA's website. The FDA has many guidance documents of 510(k)s, IDEs, PMAs, DeNovo, the CGMPs, clinicals, data integrity, cybersecurity, etc., which are good to read, reread to gain familiarity of basic regulatory requirements.  If you're in devices, also look at pharma, etc., for principles that apply to all, e.g., the 2011 guidance document on pharma process validation which discusses basic statistical principles of reduction of variation, homogeneity within lots, consistency between lots, etc., a common goal of all manufacturing. 

And, or course, selective appropriate webinars.

Best regards, John

jel@jelincoln.com

Compiling the DHF Q&A:

I attended the Effective Design Control (21 CFR Part 820.30) webinar on 01Feb2023 and found the information presented to be very useful. Thank you for the invite to send follow-up questions.

Our company divides product development into 5 phases: Product Initiation, Feasibility, Optimization, Validation & Transfer, and Launch. Each of these phases has a checklist of actions and deliverables applicable for the phase. We consider these checklists, our Design Plan. One of my goals this year is to streamline the DHF compilation process. My email to you is to confirm that I am interpreting the following 2 points correctly:

1) I liked what you said on slide 10, "Not all of the records generated during the project are design outputs and as such do not need to be retained in the Design History File", that only the outputs need to be retained. For example: No, the email from Finance noting what the pricing should be for the product does NOT need to be retained in the DHF or Supply Agreements.

My Answer:

That's correct per FDA requirements.  I did say that key interim inputs / outputs should be captured under either the DI or DO DHF "file" tabs. Your company should define what are "key" to show the path from initial DI to final DO, and the SOP should state where (under which heading) those interim DI/DO's should be placed.  And I mentioned that the DHF can serve a valuable additon to your company's IP, so that's also a consideration as to any supplemental information you'd also want to include beyond the CGMP minimums.

2) Currently, our checklists note the date the action/deliverable was completed. I noticed on slide 6 that adding the completion dates for each individual activity is not necessary. This makes sense to me because the date that the phase review takes place IS recorded in the meeting minutes for the phase review and those are all retained in the DHF. 

My answer:

Again true.  However having a record of start and completion dates for each Milestone / Task / Deliverable may be of use to your company in providing a more accurate time frame for future similar activities than a "guestimate" and may be desirable to retain for that reason.  However, if the key dates are addressed in the Review minutes for each phase / milestone/task which should be retained in the DHF also, there's no need for redundancy.  As a project leader on these type of projects, I usually liked to keep such information on my Gantt Charts, which charts were then added to the DHF, usually in the beginning of the File, under Plan.

-- jel@jelincoln.com

 

Retroactive Combination Product DHF Compilation

Question from a recent seminar:

I attended the Effective Design Control seminar today, 1Feb2023. Thank you for providing a thorough and informative seminar.
To follow up on my previous question about design control requirements for drug-device combinations for ophthalmic vial (Class 1 device) that was approved as a drug.
We are looking to develop design history file for the an approved, marketed product. We are thinking to leverage the product development reports and documents from 32P of the NDA. What are your thoughts on this approach? What gaps are there between 32P and required docs for Class 1 device design history file. We can also leverage the process validation documents. What about PQ documents? We are working to compile the document package and not reinvent the wheel for an approved product already in commercial production.

My Answer:

Nothing wrong with your approach.  A little "reverse engineering" / retrospective compilation.  Not the most desirable to the FDA as it defeats some of the purpose of Design Control, i.e., affecting the initial design process to produce a safer device.  Your approach is certainly appropriate as some of the the Combo / NDA information would have come from the DHF had such been developed first.  It's similiar to the approach I would take in compiling a DHF after the fact. In a combo product per 21 CFR 4, if the drug is the higher risk component, your CGMP "operating system" is 21 CFR 210, -211, with 21 CFR 820.30, Design Control, to be added for the device component.  Design control is focused on the device component, and the effects of any drug-device interactions primarily.  

Device design V&V (Verification and Validation) can also be compiled retroactively (again the least desirable to the FDA, vs concurent and prospective (most desirable)), but acceptable. the IQ/OQ/PQs are for the production / test equipment and software.  Your device design V&V should focus on the Device / Combo Requirements / "User" Needs, as per the slide  on Product Verification / Testing Examples slide, e.g., biocompatibility, functionality, sterility, etc., and consideration of the drug / device interaction, e.g., leachables, also system biocompatibility, stabiltiy, shelf life, packaging/shake and drop/cross country shipping and similar. Each one of these verifications would generally be a lab test report, and put all together, would make up the device validation.

Wherever possible, by all means, use already developed material, and merely fill in the gaps to complete the DHF.  Include  a description of what was done and why in your cover narrative in the DHF. Don't forget reference to a Risk Management File (ISO 14971; mandatory) and maybe a Use / Human Factors Engineering File (IEC 62366-1; possibly if your device has some not too famiIiar use interface features).  I have not seen any problem with this approach in my personal experience with both the FDA and N-B inspectors.

-- jel@jelincoln.com