There's a particular kind of institutional frustration that sets in when you realize the rules you're supposed to follow were written for someone else's product. That's the situation combination product manufacturers have been living in for decades — caught between two regulatory frameworks, each one internally coherent, each one designed for a different kind of thing, and both of them required at once.
I've spent a lot of time thinking about why combination product QMS programs fail. The proximate cause is usually documentation — gaps in procedures, misaligned records, or a validation package that satisfies one framework and quietly ignores the other. But the deeper cause is almost always conceptual. The team never fully worked out what it means to have one quality system that genuinely satisfies two distinct sets of requirements. They built two partial systems instead, patched them together, and hoped no one would look too closely.
Someone always looks.
What Makes Combination Products Different
A combination product, in the FDA's definition, is a product that combines a drug, device, biologic, or any two or three of those in a single entity — and whose components are physically combined or packaged together, or co-packaged, or cross-labeled for use together. The canonical example is a prefilled autoinjector: the biologic drug and the delivery device are inseparable in any meaningful clinical sense, so the FDA regulates them as a unit.
The challenge isn't that the FDA doesn't have rules for this. They do — 21 CFR Part 4, finalized in 2013, is specifically about combination product quality systems. The challenge is what those rules require: a manufacturer must comply with the quality systems regulation applicable to the constituent part that represents the product's primary mode of action (PMOA), plus incorporate specific provisions from the other constituent part's quality system requirements.
In practice, for most drug-device combination products, that means: - Drug-led PMOA: 21 CFR Part 211 (cGMP for finished pharmaceuticals) is your primary framework, plus you must incorporate specific 21 CFR Part 820 device quality system provisions - Device-led PMOA: 21 CFR Part 820 (Quality System Regulation — now harmonized toward ISO 13485:2016 under the updated Quality Management System Regulation) is primary, plus you must incorporate specific 21 CFR Part 211 provisions
The provisions you're required to incorporate from the non-primary framework aren't optional suggestions. They have the force of regulation. And the FDA has made clear through guidance and enforcement that "we follow Part 211 for everything" is not a compliant answer when your product has a device constituent part, regardless of PMOA.
The Scale of the Problem
Combination products are not a niche category. FDA's Office of Combination Products (OCP), which has been coordinating combination product regulation since it was established in 2002, receives between 200 and 300 Request for Designation (RFD) submissions annually. The global combination products market was valued at approximately $153 billion in 2023 and is projected to exceed $230 billion by 2030, driven largely by the growth of biologics and the delivery systems required for them.
More telling is what the FDA's own inspection data shows: combination product manufacturers are among the most frequently cited in multi-framework Form 483 observations — situations where the inspector cites deficiencies under both drug and device regulations in the same inspection. That isn't coincidence. It reflects a structural problem with how most QMS programs are built for these products.
The FDA issued a compliance policy guide specifically for combination product QMS inspections in 2020, signaling that the agency intended to inspect these products more systematically. The frequency of combination-product-specific observations in warning letters has increased since then.
The Two-QMS Trap
Here's what I see most often when I look at combination product QMS programs that are struggling: they were built by people who came from one side or the other. A pharmaceutical company that added an autoinjector hired device engineers and told them to "handle the device side." A device company that added a drug payload hired a pharma regulatory specialist and told them to "cover the drug requirements." Both teams wrote procedures. Nobody reconciled them into a single, coherent operating system.
The result is what I'd call the two-QMS trap: two parallel sets of procedures, two sets of records, two sets of training curricula, and — when inspection comes — two different answers to the same question depending on who you ask. The FDA investigator doesn't experience this as "two frameworks gracefully coexisting." She experiences it as confusion, and confusion in a QMS is a red flag.
The solution isn't to pick one framework and minimize the other. That's the most common workaround and it fails regularly. The solution is to genuinely integrate the requirements so that your operating system doesn't have seams.
Mapping the Key Requirement Gaps
The following table shows the major areas where drug (Part 211) and device (Part 820/QMSR) requirements diverge most sharply — the places where integration is most likely to break down if you're not deliberate about it.
| QMS Area | 21 CFR Part 211 (Drug) | 21 CFR Part 820/QMSR (Device) | Integration Challenge |
|---|---|---|---|
| Design Controls | Not required (drug formulation assumed fixed) | Required — full design history file, design input/output/review/verification/validation/transfer | Device-led products must maintain full DHF; drug-led products that incorporate Part 820 must add design control provisions for the device constituent |
| Complaint Handling | Required — investigation, trending, MDR evaluation | Required — MDR mandatory, includes vigilance reporting for international | Both frameworks require complaint investigations; records must satisfy both standards simultaneously |
| Process Validation | Required — prospective process validation for drug manufacturing | Required — process validation for device manufacturing | Different validation terminology and evidence standards; must reconcile IQ/OQ/PQ (device) with prospective/concurrent/retrospective (drug) |
| Change Control | Required — some changes require Prior Approval Supplement | Required — all changes documented, some require revalidation | Regulatory submission impact must be evaluated against both frameworks; a device change may trigger drug supplement requirement |
| Sterility and Environmental Monitoring | Required — detailed contamination control provisions | Required — environmental monitoring for sterile devices | Must satisfy both standards; usually one program can serve both if designed correctly from the start |
| Labeling Controls | Required — strict labeling content and approval requirements | Required — labeling as a device constituent part | Combination product labeling must address both the drug and device use; two separate labeling approval chains |
| Supplier Controls | Required — component qualification | Required — supplier qualification with risk-based approach | Device framework is more prescriptive on supplier auditing; drug framework emphasizes component testing; both required |
| CAPA | Required — implicitly through investigations | Explicitly required — formal CAPA system | The device CAPA framework is more structured; both frameworks expect systemic root cause analysis |
What this table should make clear is that the integration points aren't optional edge cases. They're the core operating processes of any QMS — design controls, change management, complaint handling, CAPA. If those are duplicated and inconsistent, the whole system is fragile.
How to Build an Integrated Combination Product QMS
The right way to think about this isn't "compliance with two frameworks." It's "one quality system that happens to satisfy two frameworks simultaneously." That reframing matters because it changes where you put the work. You're not patching — you're designing.
Start with a regulatory matrix. Before writing a single procedure, map every applicable requirement from Part 211, Part 820/QMSR, and Part 4 against each element of your intended QMS. For each element, identify which framework is more demanding — that's your minimum standard. For elements where both frameworks apply, document how your single procedure will satisfy both. This matrix becomes your compliance backbone.
Make design controls the linchpin. For device-led combination products in particular, the design history file is where everything converges. Your drug constituent part's formulation specifications become design inputs. Your drug-device compatibility data becomes design verification. Your clinical data becomes design validation. A well-constructed DHF for a combination product is simultaneously a design history file and a substantial portion of your drug regulatory dossier. I've seen companies treat these as entirely separate documents and spend enormous effort reconciling them before each submission. If you architect the DHF correctly from the beginning, it carries both frameworks.
Unify your change control procedure — and make it smart about submission impact. Change control is the most dangerous seam in a combination product QMS. A change to the container-closure system, for example, could simultaneously require a device design change record (Part 820), a retrospective process validation assessment (Part 211), and potentially a Prior Approval Supplement to the drug application. If those three consequences live in three separate procedures owned by three separate teams, changes routinely fall through the cracks. One change control procedure with explicit decision trees for submission impact assessment is better than three procedures that theoretically cover the same ground.
Build complaint handling for MDR from both directions. Medical Device Reports and drug adverse event reports have different triggers, different timelines, and different submission pathways. But they start from the same source: a complaint that something went wrong. A unified complaint handling procedure should triage every complaint against both MDR and drug adverse event reporting criteria before routing. Teams that separate this by "is this a drug complaint or a device complaint?" will miss events that are genuinely both — and those are often the most serious ones.
Don't underestimate labeling. Combination product labeling has to satisfy FDA drug labeling requirements and device labeling requirements. In practice, this means your labeling approval procedure must involve both regulatory functions, and your labeling change control must evaluate both sets of requirements. This sounds obvious but I've seen mature combination product programs where the device team didn't know about a drug labeling update until it was already in production.
The PMOA Determination Question
One thing that comes up constantly in combination product QMS conversations: what if we haven't formally determined the PMOA? Or what if we disagree with the FDA's determination?
The honest answer is that PMOA determination uncertainty is not a reason to delay building an integrated QMS. In my view, the safer posture — especially for early-stage combination product developers — is to build toward the more demanding framework in ambiguous areas, regardless of PMOA. If your product has meaningful device complexity, build design controls. If it has meaningful drug complexity, build cGMP-compliant manufacturing processes. A QMS that satisfies both frameworks fully is more defensible than one that made a bet on PMOA and got it wrong.
If you have a genuine disagreement with FDA's PMOA designation, the RFD process exists for that purpose. But that's a regulatory strategy conversation, not a QMS design conversation. Don't let the regulatory question block the quality system work.
Where AI and Software Are Changing This
One of the things I think about a lot in the context of Nova QMS is how software tools for combination product quality management have historically made the two-QMS problem worse rather than better. Most QMS software was built for either pharma or devices — not both. Teams end up with two software systems, two sets of records, and all the reconciliation problems that implies.
The more interesting development over the last few years is AI-assisted QMS platforms that can surface regulatory requirement mapping dynamically. Instead of a static regulatory matrix that someone built once and probably hasn't updated since the QMSR harmonization, an AI-powered system can flag when a proposed change or new procedure has implications across both frameworks — in real time, before the gap becomes a finding.
That's not a distant concept. The requirement logic is knowable. The gap-detection is pattern-matching against a finite (if complex) regulatory framework. The value is in applying that intelligence consistently across every procedure, every change, every complaint — not just when a regulatory specialist happens to be in the room.
The Structural Argument
Here's what I keep coming back to: the difficulty of combination product QMS isn't really about the rules being unclear. 21 CFR Part 4 is actually quite direct about what's required. The difficulty is that building a genuinely integrated quality system requires resolving a fundamental organizational question — who owns quality for this product? — and most organizations answer that question by compromise rather than design.
"Drug team owns the drug side, device team owns the device side" is not a quality system. It's a governance structure that produces a quality system with a seam running directly through its most critical processes. The seam will show up in inspections. It will show up in complaints. It will show up in change controls that went wrong.
An integrated combination product QMS requires someone — or some function — with a clear mandate to own the whole system, not each team's piece of it. That's a structural choice. It's also, in my view, the most important one you'll make.
For more on how AI-powered QMS tools are reshaping compliance in regulated industries, explore Nova QMS and our thinking on quality system design for complex regulated products.
Last updated: 2026-06-22
Jared Clark
Founder, Nova QMS
Jared Clark is the founder of Nova QMS, building AI-powered quality management systems that make compliance accessible for organizations of all sizes.