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, flow charts, cause and effect diagrams, etc.  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

I would add to the above, knowledge of your products and their use in the field (see below on visits to hospitals, et al), knowledge of the manufacturing / assembly processes for those products - spend time on the shop floor, in general, and especially if you have to draft or check the accuracy of an SOP), and some general knowledge of the functions / responsibilities of the other departments in your company. - JEL, 08/14/2025 

One of the most useful texts on industrial statistics is "DataMyte Handbook: A Practical Guide to Computerized Data Collection for Statistical Process Control", out of print, but which was given to engineers, etc., for decades, free. The section on SPC is the value, the catalog is outdated.  You can usually find one available on Amazon or E-bay, several editions, where the SPC section is basically the same, for a reasonable price (+/- $10.00 USD) - covers many of the tools used in the FDA's device and pharma Production and Process Controls (SPC, 6 Sigma, et al) section of the CGMPs. FDA Guidance Documents can be Googled, or searched on fda.gov - start search with the general subject, then select guidance document or other applicable reference, go there and usually you will get further sources to check as well. Beware of AI, as, while it can be useful, can also provide misleading or wrong information on specialized aspects of regulatory requirements.  Also check with Marketing or Management to see if you can go to a hospital or...  with a company rep to see the actual use of your products on patients, reality vs theory!  -- JEL, 07/07/25

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 similar 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 familiar 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

To clarify, the FDA expects a DHF to be completed prior to design transfer, so it can affect the product design to improve safety and usability of the device.  My above-referenced use of retrospective development of a DHR is usually helping a client after they got a 483 or Warning Letter for failing to have a DHF.  It's assumed by the FDA that when you file a marketing request (510(k), PMA, IDE, NDA, ANDA, Combo device...) that you've followed the CGMPs to get to that point, which includes compiling a DHF for devices or combo products having a device component. - JEL, 07/07/25 

Test case examples from my V&V webinars:

IQ:

Activity Completed       Signed/Dated (or N/A’d)

        01. Utilities: 

o   Power Hooked Up Properly       _____________________

o   UPS required/added       _____________________

o   Air Hooked Up Properly       _____________________

o   Surge Tanks required/added       _____________________

o   Water Hooked Up Properly       _____________________

o   Incoming Air Filtered       _____________________

               o   Incoming Water Treated/Filtered   ___________________

o   Exhaust Air/Oil Controlled             _____________________

o   Spent Water Controlled       _____________________

       02. Equipment/Tool/Fixture Number Assigned/Affixed       _____________________

03. Instruments Calibrated or NCI Tagged       _____________________

04. Safety/OSHA Requirements Addressed       _____________________

    05.   Documentation (Dwgs, Software...) Received       _____________________

06. Floor/Area Layout Approved       _____________________

07. Environmental Testing Completed/Acceptable       _____________________

           08.    SOP’s Written/Approved                 _____________________

09. Meets QS Regulation requirements       _____________________

           10.   PM Program/Spare Parts       _____________________

11. Process Control Required/Addressed       _____________________

Comments: __________________________________________________________________ 

OQ:

Verify proper blow molder heating, shot injection / size (no short shots), “preforms”:

Verification Element	Expected Outcome	Observed Outcome
Heater elements inj. barrel; screw cycle / operation. Screw / injection cycle.   “Preforms” properly configured; no molding anomalies / non conformances.   “Preform” ejections.	Resin achieves proper melt.   Proper shot size.   “Preforms” / cap interface to spec.  No short shots, splay, black specs, thin walls, et al.   “Preforms” ejected properly and without damage.

Tested by:  ___________________     Date:  ______________

                                     Verified by:  __________________     Date:  ______________

PQs (3 or more):

Similar to the above but the test case "elements" are replaced with repetitive samples (e.g., 10, 30 125, or ...).

-- jel@jelincoln.com

PQ Test Case Example (repeat in each PQ)      

Performed By:  _____________  Date: _______

Verified By: ________________  Date: _______ 

- JEL, 08/15/2025

 

Working Definitions for V&V - Why Needed?

From several of my V&V webinar slides

 

ISO and CGMP definitions generally can’t be easily followed without some additional explanation.  Hence, the need for “working definitions”, workable explanations.

Note:  The information  presented here has also specifically been field tested with the FDA and various N-Bs over several decades; it is not theoretical or derivative of other consultants work.  

These definitions are also in basic agreement with several guidance documents, ISO standards, and similar.

Verification:  Inspection, testing or checking; includes most “qualifications”; Decommissioning; Product: Design Output = Design Input. Usually verify one "Requirement"

Validation (includes a series of verifications, many involving destructive testing); may include “commissioning”, Usually validate a series of "Requirements / Qualifications":

Product: Customer Needs (+ standards, guidance documents, etc.) = Resulting product

FAT, SAT (may need supplemental V&Vs)

Commissioning

Process / Equipment / Facility:  DQ, IQ, OQ, PQ

Software:  In-product, As-product, Process / Equipment; 11 elements (U.S. FDA guidance “model”)

Software:  QMS; 21 CFR Part 11 ER / ES

Master Validation Plan

Site “qualification”.

Product Verification / Testing Examples:

Biocompatibility:  Cytotoxicity, Hemolysis, Sensitization / Irritation, Carcinogenicity ...

Functional and In-process functional testing / QC

Software / firmware testing if appropriate

Accelerated aging, and start of concurrent real-time aging

Shake / drop, shipping

Product bioburden, LAL (bacterial endotoxin test), particulate

Sterilization (and residuals if EO)

Other testing as appropriate per product, standards, guidance documents

Each of the above tests is a verification.  Put them all together and you've validated a product.  Compile all verification documentation into the product validation  package.

DQ, IQ, OQ, PQ “Working” Definitions  

DQ (Design Qualification):  Insure requirements are ID’d =  Requirements Spec(s) are complete (include applicable Guidances and Standards)

IQ (Installation Qualification): Verification that item is installed per vendor’s / company’s / legal & regulatory requirements

OQ (Operational Qualification):  Optimize settings / parameters and tolerance ranges; DOE; ensure all Requirements are functional

PQs (Performance Qualification):  Prove system reproducibility / repeatability over extended time periods with expected company “allowable worst case” inputs (shifts, times, personnel, RM, et al) – 3 or more, the exact number of PQs determined by the number of different inputs, e.g., 24/7 work shifts:  1-3 PQs for the1st shift, 1 for Swing, 1 for Night, 1 for weekend/Sunday, 1 for holiday (next one coming up) = 5-7 PQs just to address a 24/7 production schedule.

Determine / Draft  Test  Cases: 

For IQs (usually a checklist, with each verified requirement signed by a qualified individual, e.g., plumber, electrician, rigger, etc.), OQs, PQs (test cases for OQ and PQs, signed by the one running the test case / operator, and verified by an impartial party, e.g., QC, and dated):

 List all requirements; group under installation requirements under the IQ; and all other requirements under the OQ (to prove they do what they should and don't do what they shouldn't); any OQ requirements that are subject to a company's "allowable worst case inputs" would also be challenged by 3 or more PQ's, with each test case expanded by samples, e.g., n=10, n=3-, n=125, etc., with justification for the sample sizes chosen.

Expand requirements to specific elements that support each requirement (rephrase each element into a question to assist);

Consider how each element can be verified;

Develop a test case for each element;

State the element, the expected observation / outcome / output;

Provide check boxes, fill in the blank, or area for actual observations / outcomes / outputs; and

Include provision for Tester’s signature / initials and date, and a Verifier’s signature / initials and date  (Initials require a “log” …).

Review / refine with team.

-- jel@jelincoln.com

 

Trending Audit Findings:   \

Ques:  I have a question on the alert and actions limits - can we set action and alert limits for Audit findings (both internal and external). I am well aware of the sheets and formula for calculation of Alert and action limit but my question is different, How can we set limits for complaint or audit findings?

Ans:  For audits, observations / corrective actions - they should be made into CAPAs, and CAPAs would then be trended as per normal CAPA trending. 

However, it should be noted that in starting trending, it's important for meaningful Alert and Action limits to be established.  The standard deviation should be developed from a lot of readings, not usually only one month's worth.  Control Charts usually require one hundred measurements to establish the standard deviation, from which the Alert and Action levels are determined, and that's what I'd recommend here.  So in most cases a trend chart's Alert and Action limits won't have a useful value until at least 100 measurements exist from which a more representative standard deviation can be calculated for the trend chart. Once established those values for Alert and Action would carry over month to month, unless the categories change substantially, or some other event requires a re-evaluation.  The re-evaluation could be part of the annual QA senior management review.

-- jel@jelincoln.com

02/14/25:  Any changes would be under change control, of course. - JEL

 Trend Limits

Ques:  Solutions to CAPA data: 

Ans:    Re: problem of the expanding 3 sigma limits as complaints increase; the only approach I have used when this problem surfaces, is to have SOP defined steps to react to the absolute number of complaints (if of a high risk nature) rather than the Alert (1.96-2 sigma) and Action (3.0 sigma) limits; e.g.,  a "may cause death" problem requires a resolution to that specific event, not to a trend. The Alert / Action limits will only trigger action if there's a major bolus of a category of complaints in one month.

Oues:  Other process capability tools other than Cpk:

Ans:  The Control Chart, or % defective; or range of SD (standard deviations) of a key dimension; or the reverse of the Cpk, the Zmax3e:  3 sigma limit of tail of distribution / curve furthest  from the specation mid point (or:  Cpk = Zmin/3), where Cpk is the 3 sigma limit of the tail of the distribution / curve closest to the specification mid point); I've never seen this used.