Urgent Reminder!

The FDA deadline for the change from Medical Device QSR to the new QMSR is fast approaching -  February 02, 2026!  FDA CGMP Compliance Inspections are currently being conducted to the old QSR/QSIT (old 21 CFR 820) up to February 02, 2026, but after that date will be conducted to the new QMSR - the new 820, Subparts A and B, ISO 13485 in its entirety, and Clause 3 of ISO 9000.

This requires that a company's Quality Manual, QMS SOPs, and training be updated to the new QMSR and be completed with all QMS systems ready to go live on February 02, 2026.

We are rewriting QMs and SOPs for clients, to conform to these new requirements and would be happy to assist your company in doing so.

- JEL, jel@jelincoln.com   

Questions received from a recent seminar on Post-Market Surveillance - MDR's

QUES: In "Become aware" - it says "including any trend analysis." This suggests that non-public information is included in all this. Please speak to any difference between public and company-private (secret) information?

ANS:  The FDA has not made a distinction between public and private information in a MDR investigation and response.  And they repeatedly require trending of CAPA / Complaint data in their 483’s (I have also seen this personally) and have sometimes done it themselves (the trending) when such data is missing.  You do have the right to indicate what information you supply that you desire to be treated as “confidential” and/or redacted from FOI responses from them (21 CFR 803.9(b)(1)).  They may or may not agree/comply. 

QUES: Manufacturer Reporting Requirements –

A reportable death, serious injury, or malfunction is based on information a manufacturer receives or otherwise becomes aware of, from any source.

• Here and throughout subsequently, it appears that this includes company-internal information. Okay. But, what does that mean in practice? Of course, it does not mean everything, such as lunch-cooler conversations. Is there some easy definitions, such as information that is subject to audit? Or, something else?

ANS:  If you become aware of any instance of your device causing a death or serious injury, or could cause such, from any source, you are required to report it – the only qualifier is the following on “reasonably suggests” (which could even apply to your lunch-cooler example, depending…).  21 CFR 803.03 “Become aware means that an employee of the entity required to report has acquired information that reasonably suggests a reportable adverse event has occurred.” You start an investigation, first to determine if it is true, and report the findings up to the time you report initially to the FDA at/within the timeline required, with the information you have at the time.  If incomplete, you then continue your investigation until you have gone as far as you can in good faith efforts, reporting what is verifiable to the FDA as supplements / updates to the original MDR.  

In cases where you determine that the problem is not MDR-reportable, you should still record it as a complaint, and include the investigation data leading to the conclusion not to report, retained in your complaint file (such as your example of serious event lunch-cooler talk found to be incorrect).  

QUES:  The “Manufacturer” - Manufactures components or accessories that are medical devices.

• Consider product produced inside and outside US either by true manufacturer or under license by another.

Consider illicit versions (copies) produced not by or under license of the true manufacturer.

Produced not in US, used not in US.

• Is FDA involved?

 ANS:  The FDA is involved in devices produced in the US, no matter where sold, if the conditions of an MDR submission are met. Same for product produced outside the US but marketed and/or used (e.g., IDEs …) in the US.

 Counterfeit devices in complaints that were presented to you as yours by the user, initially as your product (and third party reprocessed SUDs where you are the OEM and not the reprocessor but thought to be the one responsible due to old labeling…) are reportable to the FDA by you, if you're the one who becomes aware of the problem, and if they meet the requirements of MDR submission, with the subsequent findings (and follow-on MDR update / submission to the FDA) that the product is not yours with justification / facts proving so.

QUES: “Become aware” - 1

You said: "You can't blow this stuff off."

• No question, but this was a key takeaway that prompted my questions.

 “Become aware” – 2

• You talked about "delay."
• The following question comes up often for us. Can you answer or provide a resource to answer this question:

Is there a difference between a Delayed Result < 24 hours vs. Delayed Result >= 24 hours?

This question is in the context of a lab instrument giving a result to the doctor: bacterial identification, antimicrobial susceptibility, blood work, etc.

Where the typical answer is on the order of < 24 hours response time.

 ANS:  I don’t remember saying “You can’t blow this stuff off”, but I agree with the thought.

I did not discuss anything on any “delayed result<24 hours vs. delayed result + or > 24 hours”, and am not sure of the question.  If this is a manufacturer-defined malfunction, which is a reportable category for the MDR if that was a requirement for the product and it didn’t meet it - it malfunctioned. Your MDR SOP should define how to handle, but the FDA doesn’t want splitting hairs on timing of problems, etc.  If a problem occurred at a certain time interval, it’s possible / assumed it could occur sooner or later the next time, absent test data to the contrary. However this is a specific product question which I cannot address in this general context further.

The only "delay I would have talked about is a "become aware" delay, i.e., the information may have related to an event that occurred much earlier, but was delayed in getting to you / the company.  You are obligated to send the MDR once you become aware of it, even it it actually occurred considerably earlier - days, weeks, months (I haven't seen a time limit, as long as the version of the device causing the problem is still on the marketplace - there's still a risk posed to the potential users, hence the need for the MDR).   

QUES:  “Caused or contributed” to death / serious injury

• If someone using the device makes a mistake? This is easily understood as: reportable.
• What about off-label use? You said: reportable. Okay.
• What about an actor that is purposely doing it wrong? I understand this to be same as off-label use: reportable.
• What about a bad actor? That is, someone purposefully using the device to cause harm?

ANS:  All the above are reportable, including the last bullet point.  Your findings of such (such as bad actor / willful misuse) would then be included in your MDR to the FDA.  Most risk and use / human factors requirements include user error as a consideration, but purposeful misuse is not (in use / risk analysis, unless done by a doctor who can use a device in any way they deem necessary to benefit a patient, usually with the patient’s agreement after informed of the benefit / risk – ISO 14971 …), as I mention in other presentations on use / human factors engineering and/or device risk management.  So you would still report a “a bad actor” in your findings and if you have solid proof, you would have no way to prevent that (as you have no way to prevent a doctor from their “off label” use of the same product), which would become part of your findings (cite as part of your rationale the references cited above).  

 QUES:  The most famous case at our company internally: A device analyzing blood running in a hospital lab would beep when it needed attention. There was an instance where the device was beeping at night, which bothered a person somewhat like a janitor, someone not in the lab hierarchy. They knew how to and did  turn off the beeping. When the morning shift came in, the machine was not beeping so they missed doing what they need to with it, and did not report a result to the doctor as they would have if they had known to address it. A death occurred.

• Was this a mistake? No. Was this an actor-purposely-wrong? Probably. What if this had been a bad actor, purposely causing harm?
• Perhaps you have other examples (or a book or articles I could read) about this topic? 

ANS:  Sorry, I don’t have a reference for such a book.  However, ICH 62366-1 on Usability Engineering and ISO 14971 on Device Risk Management discuss briefly purposeful misuse.

However, since a death could (and did) occur, the MDR requires that it be reported.  The findings reported to the FDA would be as indicated above.  The organization having that incident and their legal department, et al, and senior management, would have to determine corrective actions to be taken internally regarding controls and behavior of company personnel to prevent such from recurring – e.g., both the janitor who made an unauthorized change to the device, AND the morning shift who should have verified it’s operation first thing.  Your IFU’s may have to address the fact that such events could compromise results.

Be aware that any change to your labeling for your products’ field problems may require a new marketing submission, e.g., 510(k), especially a caution or warning.  See the two guidance documents on Device Changes and the 510(k):

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-change-existing-device

https://www.fda.gov/regulatory-information/search-fda-guidance-documents/deciding-when-submit-510k-software-change-existing-device

 - jel@jelincoln.com

 Can other companies use one company's 510(k) to market their own device?

For a question from one of my clients

Ans:  The company that owns the 510(k) is the only one to use that 510(k) to market the device in the US.  It is also the only one who can make regulatory decisions about that device and its 510(k) content, e.g., device changes and when its necessary to submit a new 510(k).  The submitting company (unless the 510(k) was sold along with the device to another company), is the one solely responsible for its content and "updates" / submissions to the FDA, and the FDA checks for this during each inspection; if the last inspection had no problems with the product / its 510(k), it's safe to say that the device / 510(k) has no problems (unless new data received by the company, e.g., complaints, test data, or similar) say otherwise.  

Is another company (other than distributers) trying to use the device owner company's 510(k) to sell products to other companies? If so, that would not be permissible.  Each company ordering that type of device for themselves for resale under their own name has to have their own 510(k), or, in the case of a procedure tray/kit, have a 510(k)  themselves for the kit, and per the 510(k) for kits from the FDA, maintain a file for every class 2 device in the kit, each having it's own 510(k) or one covered by the kit's 510(k),  providing the device hasn't been modified, retains its original labeling / primary packaging;  Sterilization / re-sterilization may be allowed if test data shows no device degradation and maintains its proper function and sterility (part of the data submitted to the FDA for review of the kit 510(k)).  

Further, companies manufacturing devices for sale to other companies cannot use someone else's 510(k) for their customer's use (they or their customer has to have at least one applicable 510(k) for that device in order to market it).

- jel@jelincoln.com

Note:  The above is pertaining to one company using another company's 510(k) to sell the first company's product (which doesn't have a 510(k); it not discussing one company selling another company's device which has it's own 510(k), e.g., a kit packer / procedure tray manufacturer. - JEL 07/02/25

When to Use Device Risk Management and/or Human Factors in Device Design

IEC 62366-1 outlines a process (9 stages) to follow to perform a Use Engineering / Human Factors analysis.  The specifics for the actual UE/HF tests (formative / verification or summative / validation) is found in other standards and guidances.  UE/HF is only needed where the user interface presents challenges of use[r] error and/or the device is specifically listed by the US FDA as needing such. 

In other cases it does not have to be used, e.g., where the use(r) interface (device shape, weight, color, knob usage, graphic output, alarm output, keyboard input, on-unit labeling, etc.), is intuitive, familiar, not prone to excessive use[r] error, et al.  

On the other hand, device Risk Analysis / Management per ISO 14971 (patient / user / environment  safety (and regulatory compliance), is always required, for both new product development as well as in significant changes - this will be more emphasized with the new device QMSR (new 21 CFR 820), but it is a current expectation of the FDA.

Both these tools, when used, are to be used to feed into any new designs or design changes, to use the design process to reduce use risk or use error or both. 

Possible UE/HF File Format (IEC 62366-1):  1) Intro, device description, approvals, discussion of device under evaluation, executive summary of findings, and similar background; 2) A section on each of the 9 stages in IEC 62366-1 (discuss specific tests used under Stage 5 -  5.7.1, 5.7.2 and 5.7.3 - of IEC 62366-1 in the UE/HF File); 3) Conclusions (mitigations...).

Possible Device Risk Management File (ISO 14971, or ICH Q9):  Intro, as above, assumptions, risk management team, preferably including a clinician familiar with the device's use; 2) Hazard Analysis; 3) Expand Hazards with a Fault Tree Analysis; 4) Expand Hazards with three FMEAs / FMECAs:  I) Design FME[C]A, II) Process FME[C]A, and III) Use  FME[C]; 5)Review/Report - Residual Risks, Benefit / Risk analysis / statement.   Use FTA and FME[C]As with the addition of a "Normal Usage Causing Problems" Matrix.  This format has been reviewed in detail by the FDA in 2003 and extensively used and subject to FDA and Notified Body inspections and remediation projects since then with no negative comments / findings / 483s. 

-- John E. Lincoln

 

One of the most important CGMP requirements for Vendors / Suppliers...

Change Control, documented, and reviewed agreed to prior to implementation by the customer(s).  This is a hard one to get vendor buy-in or enforce.  However, failure to do so will get the customer (contracting company)  into major trouble with the user / market and regulatory agencies.  Device changes have to be documented, validated, and compared to the last cleared 510(k) per two guidance documents (device itself, and device software / firmware) on  device changes and the 510(k) with analysis of the last change and the cumulative change since the last cleared 510(k) documented - usually done by the company, not the vendor.

-- jel@jelincoln.com 

 Q&A from a recent one of my VMP (Validation Master Plan[ing]) Webinars

Ques:  Using vendor developed/administered tests as part of a company's qualification for vendor-supplied production / test equipment.

Many times vendor templates are not meeting internal documentation requirements. For example all tests are not signed/checked individually; one signed at the end of page or document.

How to handle this when vendor documentation is not fulfilling internal requirements?

Ans:  As mentioned, you would have to "fill in the blanks" with supplemental verifications/testing, so the vendor's documentation and the additional verifications complete your company's SOP requirements for the validation.

 

Ques:  Risk based validation.

Is validation really risk based if it is based just on URS requirements. A Validation is checking just URS requirements and maybe some internal documents. Should there be a formal risk assessment on which validation is based?

 

Ans:  Risk, i.e., patient safety (ISO 14971, ICH Q9)-based Risk Management Reports/Files addressing the subject being validated, are used to direct the test cases focus, depth, size, sampling, design, et al - not just the URS.  The higher the risk based on the Risk Management File / ISO 14971:2019, the more detail, et al, included in the V&V Report's test cases as per an example test case in the webinar (the test case introduction / narrative ties that test case to specific references / line items on a Risk File document, e.g., FMECA) to define the patient risk associated with that test case.     

 

Ques:  Documentation practices.

Test should be signed individually and at right time (in real time).

In some cases multiple tests are on same page and only one signature at the end of the page. Is this really fulfilling the requirement of right time?

 

Ans:  It depends.  FDA's Guidance Document on Data Integrity on test data does not agree with different test's data being combined under one signature  (in my opinion).  However, if one signature is used  to certify the accuracy of the report, with supporting information and signatures for the individual reports readily available elsewhere, that may be allowable, depending...  And would have to be clearly stated how it can be viewed as allowable in an SOP which is then followed!

 

Ques:  Document templates. During the webinar  specific example test templates weren’t available. Are they now?

 

Ans:  No,  That would be a specific consulting project. Complete validation templates are very specialized / unique and I don't supply them in an "all-purpose" webinar.  I do develop them as part of a dedicated consulting project.  However, the basic /generic format / outline was provided a couple of times on the slides, as well as an example of an IQ check list, an OQ test case and a PQ multiple sample (n=10, n=30 ...) test case, which all also can vary.  A list of product tests / verifications was also included in the slides:

E.g., Basic Test Report Format:

• Control Number, Title
• Scope, Purpose
• Pre-Approval
• Test description, lay-out, drawings / pix...
• Pre-determined test acceptance criteria
• Test materials (P/N, Lot No., description, Qty...)
• Test equipment (asset no., S/N, Model, Description...)
• DQ, IQ, OQ, PQs -list or test cases
• Software 10 elements (see Blog, elsewhere) if applicable, Pt 11 (OQ), Cybersecurity (OQ), if applicable
• Results:  Filled-in test cases. data sheets
• Conclusions:  Compare test case results to pre-determined acceptance criteria
• Appendix:  Training Record copies, calibration ccs,  red-lined SOPs, etc.

-- jel@jelincoln.com  

 

 The New US FDA Predetermined Change Control Plans (PCCPs)

The US FDA is proposing a new addition to 510(k)s and PMA submissions:  Predetermined Change Control Plans (PCCPs) for devices requiring premarket approval (PMA) or premarket notification (510(k)).  A PCCP is the documentation describing what modifications will be made to a device and how the modifications will be assessed.

A recently published draft guidance, “Predetermined Change Control Plans for Medical Devices”, Draft Guidance for Industry and FDA Staff, for comment only, issued on August 22, 2024, provides FDA’s current thinking on the information to include in a PCCP.  It is also soliciting comments from stakeholders as to the proposals it discusses.  This draft guidance recommends that a PCCP describe the planned device modifications, the associated methodology to develop, validate, and implement those modifications, and an assessment of their impact.

FDA reviews the PCCP as part of a marketing submission for a device to ensure the continued safety and effectiveness of the device, without necessitating additional marketing submissions for implementing each modification described in the PCCP.  By including a PCCP in a marketing submission for a device, manufacturers can prospectively specify and seek premarket clearance / approval for intended future modifications to a device without needing to submit additional marketing submissions or obtain further FDA authorization before implementing such modifications – provided the changes are consistent with the PCCP that has been submitted and FDA-reviewed / cleared / approved.

Obviously this is a provision where future changes / models / improvements are basically known at the time of the original 510(k) or PMA submission.  For changes made to address unforeseen issues at the time of initial submission, the two guidance documents of changes to devices needing a new submission would apply instead.  

-- jel@jelincoln.com