FDA QMSR: More than Meets the Eye. Are You Ready?

Introduction:

FDA’s new Quality Management System Regulation (QMSR) is nearly upon us. The QMSR replaces the current Quality System Regulation (QS Regulation). Specifically, after a generous two-year transitional period, the QMSR becomes effective in just a few weeks on February 2, 2026.

The QMSR represents a number of changes compared to the existing QS Regulation. Although FDA generally states that the QMSR is substantially similar to the outgoing QS Regulation, it nonetheless contains some significant changes about which firms need to be aware and for which specific QMS solutions need to be documented in the QMS.

Overview of QMSR Basic Structure/Contents:

• • • 820.1 Scope.

    • 820.3 Definitions.

    • 820.5 [Reserved]

    • 820.7 Incorporation by reference (see ISO 13485:2016).

    • 820.10 Requirements for a quality management system: (a) document a QMS; (b) partial identification of other FDA regulatory requirements related to ISO 13485; (c) design control device scope; (d) traceability of life supporting/sustaining devices; (e) adulteration warning

• • • 820.20–820.30 [Reserved]

    • 820.35 Control of records: (a) complaint handling and records; (b) service records; (c) UDI and UDI records; (d) Confidentiality of records

    • 820.40 Reserved]

    • 820.45 Device labeling and packaging controls.

QMSR Requirements Unique From ISO 13485:

• • • Scope

    • Terminology/definitions (one example is that FDA is adopting ISO 13485’s definition of “product” as stated in the new Part 820, but FDA is also keeping its legacy definition)

    • Device traceability (Part 821, life-supporting/sustaining, initial consignee)

    • Complaint investigation scope, records,

    • Service records,

    • UDI and UDI records

    • Confidentiality of records

    • Labeling and packaging controls (prescriptive, copy of primary label/labeling)

    • Design reviews in general and regarding reviews of design verification

    • Design change control time-zero

    • “Clinical evaluation” is limited to FDA IDE / GCP scope

    • All processes require some form of qualification, verification, or validation

    • Customer property handling shall assure S&E

    • Scientific evidence for, and close monitoring of, acceptance by concession

    • Verify or validate process/device CAPA

New Items Not Covered by the Current QS Regulation:

• • • Structure, order, descriptions, of ISO 13485

    • QMSR has a different structure and order than the QS Reg

    • QS Reg now called QMSR

    • DHF, DMR, DHR are still required, yet not called by these names

    • MDF (analogous to QS Regulation DMR) has some differences

    • “established” (defined, documented, and implemented) is now “documented” (established, implemented, and maintained)

    • FDA no longer taking enforcement discretion for review of internal audit, management review, and supplier audit reports

    • Process validation required where the process cannot be or is not fully verified

    • All processes require some form of qualification, verification, or validation

    • Risk-based storage added to existing extensive QS Reg risk-based approach

    • Requested records to be provided by FDA’s deadline

    • Electronic records/signatures (Part 11) allowed but must meet ISO 13485 too

    • Automated readers for labels/packaging must be supplemented by human sampling inspection

    • Clarification of existing practice: Packaging to be included in the label accuracy inspection

    • Corporate procedural control required for multi-site complaint handling operations

Implementation Approach Recommended by FDA:

• • • Familiarize yourself with FDA regulations and applicable standards

    • Gap Analysis

    • Revise and implement robust documentation

    • Foster a culture of compliance

      • Train

      • Implement

      • Monitor

Feel free to reach out to ComplianceAcuity for help with your FDA QMSR transition!

FDA’s QMSR Final Rule Issued

FDA has issued its Final Rule on its new Quality Management System Regulation (QMSR) amending its device current good manufacturing practice (CGMP) requirements of the 1996 Quality System (QS) regulation (21 CFR Part 820) to harmonize and modernize it primarily by incorporating by reference ISO 13485:2016 3rd Ed., March 1, 2016, but with additional requirements and conforming edits to clarify the device CGMP requirements.  The Final Rule is scheduled to be officially published in the Federal Register this Friday, February 2, 2024.  It will have a generous two-year transitional period whereby the Final Rule becomes effective on February 2, 2026.

The Final Rule contains FDA’s formal responses to 83 comment groups. For those of us who had already performed gap assessments using the Proposed Rule, here is a summary of the changes between the Proposed Rule and the Final Rule:

• Various non-substantive clarifications that won’t impact the gap assessments performed by my firm

• More broadly citing (but not changing) the FD&C Act’s existing adulteration basis for refusal of entry of foreign devices

• Vocabulary

• Adding additional parameters to be met for granting of a statutory variance(s)

• More prescriptive complaint handling and records

• Packaging and labeling controls adjusted (to prevent, among other things, mixups rather than errors, and to allow inspection any time before use rather than immediately before use)

Remember that the foregoing explanation compares the QMSR Proposed Rule to the QMSR Final Rule.  It doesn’t compare the current outgoing Part 820 (which the remains in effect through Feb. 1, 2026) to the QMSR Final Rule.  Stay tuned for that ultimate comparison.

Is that eQMS platform (such as SharePoint) fit for its purpose?

I saw a question today wondering whether SharePoint is suitable for maintaining a medical device QMS documents system and record control. In a nutshell, SharePoint (or whatever other eQMS practice is proposed) may or may not be suitable for maintaining the QMS documents system and record control, or for other QMS operations, depending on the case.  Here are some key points to consider when figuring out whether a computer platform is suitable for QMS purposes:

• ISO 13485:2016 (as amended; hereinafter “ISO 13485”) is intended (clause 0.1) to allow flexibility, rather than mandated uniformity, in the structure of different quality management systems.  Accordingly, ISO 13485 doesn’t out right prohibit the use of SharePoint, nor any other eQMS solution, to facilitate QMS operations.

• ISO 13485 doesn’t really allow anyone to just “believe” that an eQMS approach is unfit.  Instead, we are expected to employ an impartial scientific method whereby we validate the software for its defined intended use per clause 7.5.6, fourth paragraph.  If the software fails that process, only then can we conclude it is unfit for its purpose.  Don’t be tempted to assert unfitness apart from that impartial scientific method.

• The U.S. FDA’s eQMS software validation requirements [21 CFR §820.70(i)] reflect the same principles as described above for ISO 13485.

Don’t confuse FDA’s Part 11 with FDA’s software validation requirements of §820.70(i)

I oftentimes see narratives that state or imply that FDA’s security and integrity requirements for electronic records and signatures from 21 CFR Part 11 are the same thing as FDA’s quality system or manufacturing “software validation” requirements in 21 CFR §820.70(i) .  But these two things, though related, aren’t the same.  Specifically,

• 21 CFR 820.70(i) requires (among a couple other things) that, whenever computers or automated data processing systems are used as part of the QMS, then the manufacturer shall validate computer software for its intended use according to an established protocol.  This is FDA’s primary medical device QMS software validation regulation. As an aside, it is generally understood in the software validation community that the OQ/PQ concepts from the process validation world aren’t proper fits regarding software validation.  This is because the OQ/PQ concepts, when deployed as intended, are focused on process development and repetition which aren’t generally germane for software validation.  Indeed, if a software validation protocol employs the OQ/PQ concepts, then it’s most likely that it isn’t actually real OQ/PQ that is being done.

• Regarding 21 CFR Part 11, it’s important to remember and distinguish that its fundamental purpose is limited to, and focused on, when required records and signatures are kept in electronic format.  If so, then it demands the security and integrity controls of 21 CFR Part 11.  But two important points there:

1. 1. Don’t holistically equate Part 11’s coincidental validation requirements with the overarching software validation requirements of 820.70(i); and

   2. Remember in any event that FDA is currently employing Part 11 enforcement discretion as follows:

      1. fewer records are subject to Part 11 (FDA is only applying Part 11 if the required records or signatures are kept in electronic format instead of paper, or if one other similar condition is met);

      2. For those records that remain subject to Part 11, FDA is exercising enforcement discretion with regard to Part 11’s requirements for validation, audit trails, record retention, and record copying, yet while Part 11’s other requirements (e.g., limiting system access, use of various checks, etc.) continue to apply.

Regulatory Review of Marketing Literature and other DHF Elements

Virtually all aspects of design and development are officially regulated activities, especially labeling/advertising development.  Moreover, the quality management system demands that all personnel whose work can affect compliance shall be competent regarding their respective assignments.  But even if sales and marketing (or other functional group) believes they have the regulatory qualifications and experience to replace or exclude the actual regulatory contributor, it remains that the quality management system requirements for responsibility and authority don’t generally allow regulatory to be cut out.  This is because there is required to be independence between the compliance function and operating functions like sales & marketing, manufacturing, engineering, etc.  This is to avoid conflicts of interest, and to ensure proper checks and balances; not because regulatory says so, but because regulatory requirements demand such impartiality.

Excluding regulatory from the review of sales and marketing literature (i.e., medical device labeling) is a classic and proven recipe for misbranded (i.e., illegal) medical devices.  The regulations themselves don’t believe that medical device labeling can be consistently safe in the absence of regulatory controls.

There may be more flexibility regarding other DHF documents like verification and validation documents.  For example, I actually recommend and prefer that engineering become the organization’s experts regarding things like software life-cycle development, electrical safety, usability engineering, process validation, and so on.  Proper training and qualifications in those areas can enable more autonomy apart from regulatory.  Yet ultimately, regulatory should still be a contributor and signatory for those, as they are vital elements of successful premarket submissions.

I question the notion that having regulatory on the approval routing somehow adds significant burden to the approval process.  To those lobbying for exclusion of regulatory from the approval routing, I would be interested to know their basis for the questionable notion that regulatory review is adding significant delays.  If delays are happening because regulatory is discovering deficiencies in the documents, then the onus is on the other departments to become better qualified and proficient in those areas.  On the other hand, if delays are happening because the documents are logistically/administratively stalled in regulatory’s queue awaiting review, then regulatory needs to implement a policy whereby it always expedites these reviews and approvals, such that the documents are only in regulatory’s queue in fleeting fashion.

Ultimately, having a proper culture of quality and compliance is key.  Indeed for example, FDA reminds us that there could be a tendency to focus only on the time and effort required in developing and incorporating the controls into the design process. But we should keep in mind the intrinsic value of design controls too. It is a well established fact that the cost to correct design errors is lower when errors are detected early in the design and development process.  History has proven this out, where lack of proper regulatory/quality oversight has been proven to lead to increased recalls and compromised public health.

Problem Containment Actions for Controlling Regulatory Impact

Today I received a question wrestling with the fact that problem containment actions tend to primarily focus on product containment and patient impact/risk, while not so much on containment actions aimed at controlling regulatory risk.  This reminds me of ISO 13485’s deliberate distinction between risks involving device safety/performance as differentiated from risks related to meeting applicable regulatory requirements.

Indeed, there’s not much available in terms of a standardized approach to managing regulatory risk.  For example, ISO 13485 and its creator ISO/TC 210 don’t (as far as I know) elaborate further on the distinction.  Likewise, ISO 14971 (as amended) and ISO/TR 24971 (as amended) are also short on this notion except regarding where the regulatory requirements are tethered to product safety, which only drives us back to the first aforementioned ISO 13485 arm of risk.

To help fill in the gaps, here are some examples of correction/containment steps to consider that involve regulatory risk:

• Marketed device recall notices and agency notifications associated with device corrections/containment/removal.

• Stock recovery (a regulatory concept patterned from the U.S. FDA).

• Invalidation of pending or existing marketing authorizations.

• Invalidation of existing clinical investigations, clinical data/results, or other design/developmental data that were collected for what is now an outdated / unrepresentative version of the developmental device.

• Adverse event reporting if somehow not already done for the instance.

There could be others too. If one were to try and formalize consideration of such regulatory impacts, then that should be done via supplementing the organization’s procedures for correction/containment, for premarket regulatory authorizations, for recalls, for design/development, etc., with appropriate handshakes back and forth between them.

Quality Agreements – Ownership and Format

The Quality and/or Regulatory departments need to be the primary authors of the Quality Agreement.  Yet the Quality Agreement nonetheless still needs to be corporately/legally executed between the parties.  Thus, the signatories should be executive officers in order to assure the Agreement has the necessary weight.

If you are working on your Quality Agreements, then kudos to you.  Those are international, including U.S. FDA, staples of proper supplier control.  While it may be tempting to conclude that Quality Agreements are just a figment of ex-U.S. ISO 13485 scenarios, U.S. FDA investigators will in fact (I’ve had it happen) ask to see your “Quality Agreements” also.  Not only is FDA already using that language in practice, the agency is only 12-24 months (my estimate) from formally putting it into its revised Quality Management System Regulation (QMSR); so don’t get caught off guard or pick a semantical fight that you won’t win with FDA.

Indeed, while FDA’s current QS Regulation doesn’t actually use the words “Quality Agreement” (instead using “quality requirements”, “purchasing data”, and “purchasing documents”), the fundamental intent and requirements are generally the same.  Remember that FDA’s current QS Regulation’s supplier control requirements were fashioned after ISO’s “subCONTRACTor” requirements.  And FDA and other international agencies can be preferential to the GHTF’s (Global Harmonization Task Force’s) and NBOG approach, which also push this into contractual terms.  So we are in fact talking about quality contracts (“Agreements”) here.

In general, Quality Agreements need to cover a number of key things such as, but not necessarily limited to:

• Corrective action and preventive action, Process Validation

• Acceptance and verification activities

• Complaint investigational support

• Supplier training/competence

• Design process

• Change control

• Handling of non-conformities

• Access for audits

• and others.

I would recommend against getting too creative or cute when achieving the parties’ contractual agreement on these topics, especially since the world has already adopted, with FDA soon to officially follow, the “Quality Agreement” vernacular.

DHF Documentation of Design Changes

Neither the FDA nor ISO 13485 mandate a required format for the Design History File (DHF).  Accordingly, we have latitude to decide what structure, format, and organizational approach we use to meet the basic regulatory requirements and objectives for the DHF.  Accordingly, if your system does that for each type of device via a single DHF or via a composite of DHFs, then both ways can work.  Accordingly, the main focal point is instead for us to be sure that the DHF, in whatever format we use, ultimately captures those changes via proper design change principles and procedures.  Indeed, it is common and expected that the design attributes, such as the intended use or indications, might evolve, or be refined, during the design process.

For example, the U.S. FDA has said that we are not expected to maintain records of changes made during the very early stages of product development.  Instead, only those design changes made after the approval of the design inputs need be documented using proper design change controls.  So, as long as the evolution of your intended use and indications are properly managed and processed using proper design change controls, then you should be on solid ground.  For example, if the changes made to the intended use or indications are no longer representative of the intended use or indications for which you’ve previously completed design verification and/or validation, then those studies would need to be supplemented or redone.  As long as your DHF, in whatever form you keep it, captures this, then that would be a compliant DHF.

FDA’s 21 CFR §820.72 Metrology Requirements vs. Test Method / Process Validation

My experience has been that FDA views a test method as a process that produces an output.  And if such output can’t be fully verified, then it must be validated.  Since FDA’s 21 CFR §820.72 is not generally related to “validation” (a very specialized, very robust, very deliberate term defined by §820.3), I’ve seen FDA handle process validation (be it for a production process yielding a tangible physical output or for a test method producing a data output) via §820.75.  For example, in a February 19, 2002 Warning Letter, FDA states, “…[we]…collected information that revealed serious regulatory problems…as follows:…Failure to validate with a high degree of assurance a process that cannot be fully verified by subsequent inspection and test as required by 21 CFR 820.75(a). For example:…The testing procedure used for…has not been validated…”

I would be very hesitant to try and integrate the principles of “validation” into my instrument metrology program.  That’s not something I’ve seen before in the many metrology programs I’ve encountered.  FDA and its explanations of §820.72 are generally aimed at assuring metrological adequacy of instruments rather than the adequacy of test/measurement processes.

Another way to put my experience is that §820.72 is related to the principles embodied by ISO 10012 / EN ISO 10012 clause 7.1 (metrological confirmation, i.e., “calibration”), whereas “validation” is instead related to the principles embodied by that standard’s clause 7.2 (measurement process development and validation).  Those sections provide a nice distinction between instrument metrology vs. measurement process (e.g., test method) validation.  They show that clause 7.1 (and I would say §820.72) is to ensure that metrological instruments are fit for their intended use, whereas 7.2 (and I would say §820.75) ensure that a process (e.g., a measurement process, i.e., a test method) is fit for the process’s intended use.

Because of these principles, my experience is that FDA generally associates test method validation with §820.75 rather than §820.72.  As mentioned above, I’ve seen FDA issue test method validation audit citations against §820.75 rather than §820.72.  So it seems that FDA definitely demands that we perform test method validation pursuant to §820.75 rather than §820.72.  If we applied the principles of §820.72 for test method validation, then I would get ready for a real wallop from FDA and other regulators like ISO auditors.

Risks from an Inadequate Development Process for Software

The most fundamental reason for medical device design and development controls (e.g., ISO 13485 clause 7.3; the U.S. FDA’s 21 CFR 820.30, etc.) is to control risks that come from an inadequate development process.  That fact is unequivocally true and stands in stark contrast to the erroneous notion that there are no risks from the software development process.  For example, in a 6-year study, FDA found that approximately 44 percent of medical device quality problems leading to recalls were attributed to design errors that FDA says may have been prevented by adequate design controls.  And regarding design and development of software, FDA did a subsequent study for fiscal year (FY) 1983 through FY 1991 and found that a whopping 90 percent of all software-related device failures were from failure to have a proper software development process.

When approaching risk management regarding the software development process itself (as distinguished from risk management of the software medical device), the general paradigm needs to start from a process-focused approach rather than a device-focused starting point.

There are multiple ways to do process-focused risk analysis.  Now, we all know how important it is to realize that FMEA, on its own, is not sufficient to meet ISO 14971’s risk management and analysis requirements.  But for temporary discussion purposes, I’m going to dare say something slightly to the contrary in order to help drive home the process-focused concept mentioned above.  Specifically, to really grasp the distinction of the process-focused concept, think in terms of p(process) FMEA vs. d(design) FMEA.  Okay, there I said it.  Now quickly, while my colleagues (and me too of course) are catching their breath and settling down about the mention of FMEA in the context of risk management, I’ll reiterate the disclaimer that we need to be sure and remember FMEA’s intrinsic limitations and intent.

So, if you’re familiar with doing risk analysis for a process (instead of a device), then those principles are the ones that should be applied in order to do risk management of the software development process itself.  What can be confusing is that the ultimate purpose of medical device risk management is to control the risks to patients and users.  Consequently, it may well be (as the U.S. FDA has indicated), that an inadequate development process can indeed be ultimately correlated to patient and user harms.  But there may also be process-centric hazards and harms (derived e.g., via FMEA) that are focused on the process itself.  When that is the case, then bridge the ISO 14971 risk management gap by being sure to, where appropriate, ultimately extrapolate (by representation as resulting hazardous situations and sequences of events) into the patient or user harms.

Check out AAMI TIR 36 (Annex B ‘Severity’ explanation under ‘Risk management terminology as it applies to quality and production systems) and ISO 80002-2 (Annex B section B.4) for interesting interpretations of how process risk analysis can differ from product risk analysis. In addition, IEC 60812 also contains some good basic process FMEA insights which can reasonably be adapted for software development process risk analysis.

(Note that it’s only by mere coincidence that AAMI TIR 36 and ISO 80002-2 which I cited happen to involve a software-related context; please note that they aren’t intended to address medical device software validation, nor device software development.  Instead, I recommended these resources simply because they coincidentally happen to provide some good illustrations about doing process-focused risk analysis as distinguished from device-focused disk analysis.)