Questions from my recent webinar on the Master Validation Plan:

My response:

 

Ques. 1: How would you structure or link design documentation for a hardware system and the disposable sets used on that system?

Ans: It depends on whether the disposables are your company's designs/ supplied by you, or purchased separately from another company by the user.  If yours, you would address them / their design/risk the same as the basic system, either in the system's DHF, or in additional / supplemental DHF's, referencing the original DHF.  If another company's, you would address your product's interfaces to the outside products, for all that you claim compatibility with, e.g., standard luer fittings, et al, in your DHF / Risk files. 

Ques.2: On Risk Management Files, you say that overall residual product risk is acceptable and that not every residual risk must be disclosed. 

ANS:  If the supporting data, FME[C]As, FTA, et al, show residual risk then you make the determination as to whether the residual risk is acceptable and analyze that conslusion in your Benefit / Risk (to patient/user) Analysis .  All residual risks are shown in the supporting documents, FTA, FME[C]As..., but not all have to be specifically analyzed, only those that pose important risks to the user/patient. 

 

(A) How would you summarize individual risk into an overall product risk?

ANS:  That's a decision your company's product experts would have to determine, and define in your design control DHF / Risk Management File SOP(s).  The overall Product Risk is the sum total of all your product's individual risks from design issues, production failures, and use errors, etc.

 

(B)Would you not disclose your full FMEA document to the FDA?

ANS: Of course you'd disclose it/them..  Your DHF and Risk Management File ( and Human Factors File, if used) are all to be accessible to an FDA inspector, and some may be submitted to the FDA in a Marketing Authorization submission (510(k), De Novo, PMA...) to show your product's risk in general and in relation to a predicate device, or in response to a 483 remediation, or ...

-- jel@jelincoln.com  05/18/2026

 Questions from one of my recent webinars on Validation Master Plans:

My responses:

Ques:  Attendee Query:  “I asked two questions in the session chat and was hoping to have them answered live. Since that did not happen, could you please provide the answers via email? I work for a virtual company. As a virtual company, are we required to write our own Master Validation Plan, or can we rely on our CDMO’s Master Validation Plan? 

 Ans:  Sorry, I never saw these questions. The short answer is you can do either.  However, Virtual or not, if you are the top level company, you are ultimately responsible to the FDA for all the CGMP compliance, even if you contract / PO / or Quality Agreement that out to a CMO (Contract Manufacturer). So you have to continually monitor and periodically audit for compliance with those you contact to do the actual work to insure that they do it and are in compliance while doing it. And/or do yourself what's lacking.

Ques:  Do we require a Master Validation Plan for commercial packaging validations?

Ans:  Yes, fhe MVP should include any packaging equipment and its software. However if contracted organizations have their own MVP you can reference them in your's without going into further details, but have to ensue they are following their plan.  As mentioned in the webinar, someone's MVP should address all validatable (per FDA) systems in the company / under the company's product's requirements / needs / control, and how you address them, e.g.,  by validation per an SOP(s) (cited), or by calibration (per SOP), or by Preventative Maintenance, or User Standardization, or contracted, or some combination of those.

Ques:  If a Master Validation Plan is required for a virtual company, do you have a template we can use?

Ans:  One was provided in the webinar.  However, here it is, as a suggestion, as the FDA doesn't specify a specific format / content:

 

VMP / MVP -– A  Typical  Entry:

 

Production / Test Equipment [Description]:

•  V&V per SOP VVV

•  Software / Firmware V&V per SOP FFF

•  Annual V&V Review per SOP VVV

•  Maintain State of Validation and Statistical Control (DHR reviews,  

      CpK studies, Control Charts …) per SOP SSS

•  Calibration Program per SOP CCC

•  PM Program per SOP PPP  …

•  Revalidation, if / when required (per SOP VVV).

-- jel@jelincoln.com  05/12/2026

- Added a SOP to "Revalidation" - JEL, 05/16/26

 FDA's Remote Compliance Inspections/Audits:

What originally appeared to be a temporary arrangement to adjust to the Covid 19 shutdown of 2020-2023 - remote / virtual inspections, now appears to be a regular feature used by the FDA remotely / virtually as needed to accomplish some lower risk (patient/user) CGMP compliance and other type inspections previously done in-person, on-site.

J. E. Lincoln and Associates LLC has performed several such internal audits (an annual requirement for regulated companies) for clients (new and established clients) over the past several years (since 2022) 100% remotely / virtually, with excellent results. One of these JELALLC virtual audits was to resolve a 483 from the FDA (for the company having done no internal/self audits) on a recently concluded site inspection, for which the FDA found our remediation method acceptable. 

Some considerations:

• An Audit Plan, developed by the auditor, addressing how some areas will be addressed remotely; a brief follow-up phone or e-mail discussion of the Plan and the development of a simplified flow plan / floor plan of the audit site /company by the auditor (approximately 1 week in advance);  
• Pre-submissions of some key documentation by the company to the auditor (prior or during);
• Client provides some one proficient with a camera (or phone camera) for site tour videos / pictures, document close-ups, and similar;
• Prearranged Zoom, Teams, or similar meeting (by the auditor, the Audit Meeting), starting with the meeting with the company team, a discussion of the Plan / Schedule / Audit Questionnaire / Matrix based on the applicable CGMPs / Regulations / Standards / FDA Inspection Manual 7283.850 (Devices, 2026) or FDA Inspection Manuals 7356.002 or-F (Pharma, General / Q10,2022, or -F, APIs, Q7, 2015) Check List (the day (1-2) of the audit, for usually 2 hours, +/-); 
• A "tour" of the facility (included in the above time frame)
• Q&A (the "meat of the audit") by the auditor using the Inspection Check List, verified by photos, videos, submissions as needed to resolve questionable areas / documentation / records (part of the above, any additional time to resolve any serious issues);
• Break.  Auditor drafts preliminary report based on the Questionnaire  (usually 1 - 2 hours);
• Resume Virtual Meeting with QA/Company principals to review the Draft report (usually 1 hour or less);
• Resolve any disagreements and develop remediation plan / responses as needed (included in above or a separate series of communications;
• Draft Final Report and submit for review and discussion (usually an e-mail or text discussion, about one+ weeks later);
• Submit Final Report, in agreed electronic format as well as a written Report by mail (usually 1-2 days after final draft review). 

The above is for a small or medium-sized company, with the actual audit taking portions of one to two days.

Note:  Per the new FDA Device Inspection Manual, Feb 02, 2026 (and 21 CFR 820 / QMSR Final Rule Preamble), company internal audits, vendor audits, and similar, are no longer "off limits" to an FDA inspector / inspection). 

Note:  While an FDA virtual inspection may follow a similar plant/format, including giving a company an idea of it's concerns after each day's inspection and providing the company a chance to correct (however the 483 observation remains, tho' the comment is added that it was corrected prior to completion of the inspection) and their timing may vary somewhat; the above done by JELALLC adds a client review/comment of the draft, with some possible revisions, and the same with the Final Report.  Such reviews can clear up misunderstandings so they don't remain in the final report, but they do not remove any valid findings, tho' some company explanation may be added.

-  jel@jelincoln.com    04/30 - 05/02/2026,; some clarification added after initial 4/30 publication. 

Questions Received From One of My Recent Webinars on Software V&V:

My responses:

 Q1. Do we need to define and perform periodic validation, or is it mainly an analysis to determine whether changes have occurred that require re-validation?  

ANS:  I believe I mentioned that I don't believe in calendar-scheduled revalidation, nor are they required by regulators.  There should be a periodic re-evaluation for any changes that require a re-validation, e.g., physical move, major repairs, etc., documented if the decision is to not revalidate.  You can also set up systems to maintain equipment in a validated state (challenged, recorded in a log, lot records, or...)  All allowed by the FDA

 

Q2. If we are using COTS software with low risk, can we skip the validation process?

ANS:  No.  FDA has stated that software is a risk-based activity, that's patient/user risk per ISO 14971, documented.  Some validation is necessary for all COTS (all software), at least to verify that it meets your / regulatory needs / requirements, that it does what it should do and doesn't do anything it shouldn't - no unintended consequences.  And Part 11 is mandatory if the COTS is used for CGMP compliance records/sigs. Ditto Cybersecurity, if software can be or is connected to the Internet (including by flash drive, CD-0ROM...). Any V&V done by the vendor, if you have access to it, can be used to reduce what you need to supplement it in your test documentation.

 

Q3. When using SaaS for testing activities (e.g., test tools), where we do not have control over vendor-driven version changes, how can we maintain a validated state? This is especially relevant when vendors provide advanced features but are not specifically focused on the medical device industry.

ANS:  Such vendor change control reporting is a problem in all industries, and especially with cloud-based software.  You're going to have to 1) try to select companies willing to commit to such change notifications, 2) put such requirements in contracts, POs, etc., 3) set up systems to catch changes when such are implemented without notification (common with software changes), 4) shift to CGMP/ISO compliant-vendors, or those who want to be to be more competitive.  Failure to do so will jeopardize $1000's in past validations, put you in conflict with the CGMPs, et al.  This is an on-going problem, and not just with our industry. 

 

Q4. How detailed should a test report be? We conduct multiple V&V rounds for both feature and regression testing, resulting in very detailed test steps. If we generate a final report, it can run into hundreds of pages with step-by-step pass/fail analysis. Is it acceptable to provide a summarized report instead of including detailed step-by-step results to keep the document concise?

ANS:  It should be patient/user risk- based for amount of detail / length.  Don't make the mistake of a "one-size fits all" software V&V test report SOP, which I see all too often with companies. I don't see how a summarized report saves anything if it's a summary of more extensive tests. Obviously 100's of pps should not be necessary for a PLC conveyor system validation or similar, but would be for a cancer drug pump. They can be large multi-page reports for complex, high risk (to people) systems/equipment, or a few pages in a Lab Book for low risk, and/or less complex systems.  They should all have enough information to allow replication:  Project/test No., Title, Purpose/Scope, Approvals, pre-determined acceptance criteria, Materials used in test( P/Ns, Descrip.,  Lot No., qty...) , Equipment used (Equip/Asset No., S/N, Descrip., ...), test set up descrip'n, diagrams...), Requirements/needs to be V&V's, test cases addressing each requirement, results (filled in test cases / data), conclusions (results compared to pre-determined acceptance criteria), Post-Approvals, Appendix -- expand / contract based on risk.   

 

Hope that answers the questions.

-- jel@jelincoln.com  04/28/2026

-- Minor clarifications, Q1 & Q2, 04 /29/26 - JEL

 Some "Test Case" Examples:

Each test case should be based on the test subject's requirements / needs (customers, Standards, legal, manufacturing capabilities, et al) that are being tested (verified / validated)

                                                                            OQ:

PQ:

Include on Each PQ Sheet (2nd Test Case for 

software, i.e., UPS, generator tests):

-- Added Test Case Titles, 04/29/26 - jel@jelincoln.com

- jel@jelincoln   04/27/2026

 Recommended In-House Test Format:

Your in-house test documentation should be structured similar as follows, each test in a formal document / Test Report or Lab Book, preferable per an SOP on testing:

• Title;
• Test Number, date(s);
• Description, Scope, Purpose...;
• Pre-approvals signatures/dates, including Tester, Verifyer/QC;
• Material (Description, Part Numbers, Quantity, Lot Numbers...);
• Test Equipment (Description, Asset No., Item No., Serial Numbers... (as appropriate));
• Test Set-Up (Drawings, Schematics, Photos, Diagrams, etc.);
• Predetermined acceptance criteria / expectations;
• Test object's Requirements;
• Test Cases / Protocol (at least one for each requirement, single or in combination);
• Results (filled in test cases, data);
• Conclusions (how test cases fulfilled pre-determined acceptance criteria ("pass/fail"));
• Post approvals, including tester, Verifier/QC. 
• Appendix, as needed.

 Include enough information to allow the test to be replicated and obtain similar results. 

- jel@jelincoln.com  04/27/2026

 - Added "similar" in 1st sentence; and "object's" to Requirements. - JEL, 04/30/26 

 Response to a question received on one of my webinars on V& V:

My response:

“John, I understand the concept of "Freeze changes" for the Validation Planning, but does "Freeze" mean absolutely no changes, or are minor changes which do not impact on safety and effectiveness permissible?  I struggle with this part of validation, because there is never perfect information at the start of a validation.  No argument that the changes must be frozen but let me give some examples:

  

 During a mixing step for a liquid bulk reagent, one step states to mix at room temperature for 15 - 30 minutes.  If it turns out that this time interval is not convenient, and objective data can be used to justify a change, could the mix at room temperature be revised to stir for at least 15 minutes, but no more than 10 hours?

1. A raw material is stored frozen, until time of use, and then it is thawed the night prior to the liquid bulking process.  Again, if objective data can be used to justify the change, and it is known the material thaws to room conditions within 3 hours, can the procedure be revised to thaw the material, and the material may be used within 10 hours.

Revising a protocol will cause a new revision level, which immediately catches attention with QA, who insists the revision level is not permissible as part of the validation.  Again, the changes can be mitigated as not impacting on product design.

 

Thank you for any thoughts and suggestions.”

 

ANS: I won't comment on your specifics as I would have to know more, and that becomes a consulting project.  However, some basics:

•  The definition of "change" should be in your company's SOP. In your example, some questions - "What is room temperature?"  "Thaws within 3 hrs?" Acceptable for use "within 10 hrs"?, etc. Changes of any sort would need to be verified / tested, as the very least in a lab book, for your "objective evidence".  Temp at freezing, and thawed should be defined / repeatable / verified by instrumentation, everything verified. 
• Not sure what you mean by "changes can be mitigated as not impacting on product design" - that's not a complete CGMP definition of change. Many CGMP-defined controlled changes do not impact product design, yet must be controlled, or otherwise can lead to the FDA's claim of "adulterated product", in this case meaning that a review of an SOP, et al, to see what was done to a lot/batch, may not indicate what actually was done at some point in time when that specific revision was in effect.
• Of course a change requires validation to make sure the change does what it should and doesn't do what it shouldn't (no unintended consequences) and a document(s) revision if controlled/CGMP as all changes should be.  E.g., every statement in para 1b above would need to be verified or validated (tested/proved) that the requirement(s) were each met / achieved. Even the statement "It is known" is not true of itself and  also needs what it refers to, to be proved / verified to truly be "known".
• Changes should be accomplished before validation, which includes the subsequent change in the revision level of any impacted documentation by said change, the point I made in the webinar and the whole point of this discussion, as the question being resolved is "what is it you're validating, and why validate something that is being changed, before the change occurs, waste of time and money and resulting in a meaningless validation.".

- JEL@jelincoln.com  03/03/2026

The FDA's New CSA (Computer Software Assurance) requirements

The New CSA requirements per the FDA's new guidance document can be summed up as follows:  Computer software assurance focuses on preventing the introduction of defects into the software development cycle and it encourages the use of a risk-based (patient / user) approach to establish confidence that software is fit for its intended use.

- jel@jelincoln.com  02/12/2026

Ques:  "We had a question from the previous webinar on IQ, OQ, PQ:

 

“Mr. Lincoln, what if a validated commercial software was originally validated using a software system that is no longer supported by the software company and/or the commercial software has been updated.  Does the validation have to be repeated?  For example, Microsoft Version 7 was used as part of the validation process for Lab Solutions, a system software used to support Shimadzu spectrophotometers.  This was completed in 2007.  In 2026 Microsoft no longer supports Version 7 and/or Shimadzu has updated the Lab Solutions software.  What needs to occur to avoid a 483 observation during an audit? ” 

 

ANS: These situations happen frequently. Usually as part of your annual QMS Review. you consider the status of existing V&V's, and that would apply here.  If nothing has changed in terms of the validation's issues being resolved by the validation, that the resolution / answers are still valid, then the version or updates involved in components of the V&V would not be an issue - that's basically the 'bottom line'. 

On the other hand, if the updates / obsolesce, et al, was due to any inherent defect in the supporting test mechanisms, then there is an issue, and a possible re-verification or re-validation may be required, and any additional follow-ups to remediate any product affected may need to be addressed, depending upon Failure Investigation / Root Cause Analysis findings. Ditto if there's any negative trends / irregularities in the data provided by the spectro system, per your NCMR / CAPA system. 

You should call out this analysis and results in your QMS management review documentation, whether done now or as part of any upcoming annual review, and revisit as necessary in the future, if necessary per the above.

- jel@jelincoln.com 02/10/2026

 FDA Town Hall – Quality Management System Regulation: Risk and Design and Development,   01/14/26, Wednesday, 2:00 PM ET,  US FDA, ~1 hour

I just attended an FDA Teams audio presentation on the new QMSR to be implemented on February 02, 2026, by all Medical Device Companies selling product in the US.  

Some key takeaways:

-  Risk management is an important part of the new QMSR / ISO 13485: 3.17, 3.18, 4.1.2(b), 7.1, 7.3, and 7.4;

-  Design and Development ( the old Design Control) is an important component of risk management; or rather Risk Management (and, if necessary, Use / Human Factors Engineering) are an important part of Design Control; 

-  The FDA expects that the design review team(s) have independence for decision making;

-  ISO 14971 or a similar risk management system should form the basis of the QMS / device risk       

   management activities, especially pertaining to QA/QC, Production and Purchasing; 

   Note that harm (to patient / people is the focus of FDA's/ISO 14971's requirements, not financial /  

   scheduling / business risks; 

-  Design control is not retroactive for devices;  only a requirement for devices designed or changed since 

   October 1997 (when 820.30 Design Control was implemented);

-  Changes to a device can be documented in the DHF or under the company's CGMP change control   

   system;

-  The DHF or applicable product documents (and risk management documents) should be reviewed 

   periodically or when a new risk is   

   determined, and updated / addressed accordingly;

-  Ditto the risk management elements of the QMS (and the Device Risk Management file);

-  The FDA does not expect companies to change existing historical documents (e.g., DHFs, archived  

   documents) to reference the new changes, references, terminology.    

One key point that was not addressed was the Final Rule / Preamble emphasis that the QMSR is not intended to, nor does it substantially change the QMS of the old QSR, that ISO 13485 meets the basic requirements of the old 21 CFR 820, except for a change in references (generally from 820 to ISO 13485),  some terminology changes, and a few legal requirements unique to the USA as required in the FD and C Act, under which the FDA acts, addressed in the new 820, Subparts A and B. 

A transcript of the meeting should be available on fda.gov in approximately 2 weeks.  

-  jel@jelincoln.com 01/14/2026

Some grammatical changes to para. 3. - JEL 02/19/26

- added last comment to 2nd bullet point above, " or rather..." ; and diagrams below - JEL, 02/24/26 

US FDA’S QUALITY MANAGEMENT SYSTEM REGULATION (QMSR, 21 CFR PART 820)

NEW COMPLIANCE INSPECTION / AUDIT MODEL (replacing QSIT), dated 02/02/2026

  

   OAFR’s:

  MDRs;

      Reports of Corrections and

            Removals; 

       Medical Device Tracking

            Requirements;

       Unique Device Identification