QMS and PLM Integration for Medical Device Design Controls

Most medical device companies I talk with, or read about, have two systems that each hold half of the design history. The PLM knows what the product is: the parts, the drawings, the revisions, the bill of materials. The QMS knows whether the company is allowed to believe in it: the approvals, the risk files, the nonconformances, the change records, the training. Design controls live in the space between those two halves, and in many companies that space is bridged by a person with a spreadsheet.

I have come to think the integration question is usually asked backwards. People ask "how do we connect the two systems?" before they have decided what each system is the authority on. Connecting two systems that both think they own the same record is how you get two versions of the truth and an auditor who finds the seam in about ten minutes.

This article is a working guide to doing it in the right order: decide ownership, define the objects that need to link, choose a pattern, and then worry about the technology.

Why Do Design Controls Need Both a QMS and a PLM?

Design controls are a chain of evidence. A user need becomes a design input, the input becomes a design output, the output is verified against the input, and the finished device is validated against the user need. Risk management runs alongside the whole chain, and every change after release has to be assessed against it.

A PLM is built to manage the product structure and the engineering change process. A QMS is built to manage controlled documents, approvals, quality events, and the evidence that procedures were followed. Each does its own job well, and neither does the other's job well. A PLM can store a verification report, but it is not designed to tell you that the report was reviewed by someone independent of the design, that the person was trained, and that the nonconformance found during testing was closed before release.

The regulatory structure reflects the same split. Since the Quality Management System Regulation took effect on February 2, 2026 (the final rule was published in the Federal Register on February 2, 2024), 21 CFR Part 820 incorporates ISO 13485:2016 by reference. Design and development requirements now sit in ISO 13485:2016 clause 7.3, which runs from planning (7.3.2) through inputs (7.3.3), outputs (7.3.4), review (7.3.5), verification (7.3.6), validation (7.3.7), transfer (7.3.8), change control (7.3.9), and the design and development file (7.3.10). Clause 7.3.10 requires a file for each device type or family that contains or references the records showing conformity to the design requirements and records for design changes.

That last phrase, "contains or references," matters for integration. The standard does not say all records must sit in one system. It says the file must be able to produce them. That is permission to have two systems, along with an obligation to make them behave like one file.

Who Should Own What? Deciding System of Record

Before drawing any integration diagram, I would write a one-page ownership table. For every object in the design history, one system is the system of record, and the other holds a reference or a read-only copy. When both systems let users edit the same field, the integration will eventually fight itself.

The requirements row deserves its own comment. Some companies manage user needs and design inputs in the PLM, some in a dedicated requirements tool, and some in the QMS. All three can work. What does not work is splitting them: user needs in one tool, design inputs in another, and the trace matrix in a spreadsheet that someone updates before audits. Pick one home for the requirements and trace links, and make everything else point to it.

Which Objects Must Be Linked?

An integration succeeds or fails on a short list of cross-references. In my view, there are six links worth getting right before you build anything else.

1. Change records to design elements

Every engineering change in the PLM should carry a reference to the quality change record in the QMS, and the reverse should also be true. ISO 13485:2016 clause 7.3.9 requires design changes to be identified, reviewed, verified, validated as appropriate, and approved before implementation, and it requires evaluating the effect of the change on constituent parts and on product already delivered. If the PLM can release a revision without a approved QMS record behind it, you have a gap that no amount of procedure writing will close.

2. Revisions to documents

A verification report is written against a specific revision of a specific design. When the design moves from revision B to revision C, you need to know which reports still apply. This means the QMS document must record the PLM item and revision it covers, and the PLM should be able to show which controlled documents reference the current revision.

3. Risk controls to design outputs

Risk controls identified under the risk management process in ISO 14971:2019 usually become design features, labeling, or manufacturing controls. The risk file should link each control to the design output that implements it and the verification that shows it works. When a design change touches that output, the risk file should flag itself for review.

4. Nonconformances and CAPA to affected items

When a test failure, supplier problem, or complaint points to a design element, the quality event should link to the PLM item. The payoff arrives later, when an engineer opens that item and can see the open and closed quality events against it without asking anyone.

5. Approvals to identities and training

If a person approves a design review or signs a change, the record should reflect that they were qualified to do so. This is where a QMS with training records has an advantage over a PLM, and it is also where electronic signature expectations come in. Where you are relying on electronic records and signatures, 21 CFR Part 11 sets the expectations for controls like unique user identification, audit trails, and signature manifestation.

6. Design transfer to manufacturing records

Clause 7.3.8 requires design outputs to be verified as suitable for manufacturing before they become final. In practice, that means the released BOM, work instructions, inspection plans, and supplier requirements must all agree. If your ERP or manufacturing execution system is also in the picture, the same ownership question comes back again; I wrote about the mechanics of that in connecting a QMS to SAP, Oracle, or NetSuite, and much of it applies to PLM as well.

What Integration Patterns Are Available?

There are roughly four ways companies connect these systems. They differ in cost, fragility, and how much an inspector will trust them.

For a small or mid-size manufacturer with one PLM and a modest change volume, I think the best starting point is usually a thin API integration limited to the six links above, and nothing more. The temptation is to mirror everything, and the cost of that temptation is a large validation burden for data nobody needed in the other system.

The pattern also matters for what can be enforced. A scheduled export can tell you after the fact that a change was released without approval. An event-based integration can stop the release. Those are different levels of control, and an inspector reading your procedures will want to know which one you actually have.

How Should the Change Control Workflow Run?

Change control is where integration earns its keep, so it is worth walking through a concrete flow.

1. An engineer proposes a change in the PLM. The PLM creates a draft change object with the affected items and revisions.
2. The integration creates a linked change assessment in the QMS. It carries the item numbers, the revisions, a description, and a link back.
3. Quality, regulatory, and other reviewers assess the change in the QMS. They look at the risk file, the verification and validation scope, labeling, any need for a regulatory submission, and impact on product already in the field.
4. The QMS returns a decision. Approved, approved with conditions (for example, additional verification required), or rejected.
5. The PLM gates the release. The change cannot move to released state unless the linked QMS record is approved.
6. Closure feeds back. When the verification evidence is attached and approved, the QMS record closes and the PLM shows the evidence link.

The important mechanism is step five. Without a gate, the integration is only informational. With a gate, the quality decision actually controls the product record, which is what clause 7.3.9 is asking for when it says changes must be approved before implementation.

One design question I would settle early is who can bypass the gate and under what circumstances. Emergency changes happen. A documented expedited path that still produces the same record, only faster, is much better than an informal workaround that produces nothing.

How Do You Build and Maintain Traceability?

Traceability is the part of design controls that people dread most, and the part that benefits most from integration. The trace chain runs from user need to design input, to design output, to verification, and to validation, with risk controls woven through.

A few practices have served me well in thinking about this:

• Trace at the level of individual requirements, not documents. A link from a 200-page specification to a 40-page report tells an inspector very little. A link from requirement 4.2.1 to test case 17 and its result tells them what they need.
• Make orphans visible. Any requirement with no verification, any verification with no requirement, and any risk control with no design output should appear on a report that someone reviews on a schedule.
• Treat the trace matrix as a view, not a document. If it is generated from live links, it is always current. If it is a spreadsheet exported once, it begins decaying the moment it is saved.
• Version the baseline at each design review. Reviews need a frozen snapshot of what was true on that date, even while the live links keep moving.

The design and development file under clause 7.3.10 is much easier to assemble when these links exist as data. An inspector asking for the design history of a particular device is asking for a query result, and the faster you can answer it, the less the rest of the conversation tends to wander.

What Needs to Be Validated?

The integration itself is software that supports your quality system, so it falls under your own expectations for software validation. ISO 13485:2016 clause 4.1.6 requires the organization to document procedures for validating the application of computer software used in the quality management system, with validation before initial use and after changes, proportionate to the risk. For US-regulated companies, the FDA's guidance on Computer Software Assurance, finalized in September 2025, describes a risk-based approach that emphasizes critical thinking and testing focused on the functions that matter.

Applied to a QMS-PLM integration, that means being specific about intended use. The functions that carry real risk are usually these:

• Does the change gate actually block unapproved releases?
• Do the revision identifiers transfer without alteration?
• Are approvals and statuses transferred accurately in both directions?
• What happens when the connection fails, and does someone find out?

Testing those directly, including failure cases, is more useful than a long script that exercises every screen. If you want a sense of how protocol generation can lighten that work, I covered it in validation and qualification protocol generation using AI QMS tools.

Two details are easy to forget. Monitoring is part of the control, so a failed sync job should raise an alert and not wait to be discovered. And upgrades on either side, a PLM version update or a QMS release, can break an interface that worked yesterday. Your change control for the software should include a check of the integration.

What Are the Common Ways This Goes Wrong?

Looking at how these projects tend to struggle, the failures cluster in a handful of places.

Dual ownership. Both systems allow edits to the same field, and nobody decided which wins. The fix is the ownership table, enforced by making fields read-only on the non-authoritative side.

Mirroring too much. Teams copy everything across because it seems safer, then spend months validating and reconciling data that no one uses. Link first, copy only when there is a clear reason.

Gates with no exceptions path. If the gate is too rigid, people route around the system, usually with a verbal approval and a promise to document it later. Design the expedited path on purpose.

Ignoring legacy records. Devices already on the market have design history in old documents, old folders, and sometimes old systems. Decide whether to migrate, link, or archive, and write the decision down. The considerations are similar to those in switching QMS vendors, though I will not repeat them here.

Treating it as an IT project. The people who know where design controls actually break are quality, regulatory, and engineering. If the project is run only by IT, the integration will faithfully automate the existing confusion.

The honest summary is that the technology is rarely the hard part. The hard part is getting engineering and quality to agree on what a "change" is, when it begins, and who gets to say it is done.

A Practical Sequence for Getting Started

For a team starting from scratch, this is the order I would take:

1. Map the current design control process as it is actually practiced, including the workarounds.
2. Write the ownership table and get engineering, quality, and regulatory to sign it.
3. Choose the six links you need first and ignore the rest for now.
4. Pick the integration pattern that matches the level of control you need, and be honest about whether you need a hard gate.
5. Define intended use and risk-based validation scope for the interface.
6. Pilot on one product family, run it through at least one real change, and look at what the records look like.
7. Roll out, monitor, and review orphan reports on a schedule.

Smaller companies sometimes ask whether this is overkill. In my view, the right size depends on change volume and product risk. A company with one device and a handful of changes a year may be well served by disciplined manual cross-referencing with a periodic reconciliation. A company with several product families and dozens of changes a month will probably feel the pain of manual links long before an auditor points it out.

What I find myself returning to is that design controls were never meant to be paperwork produced after the engineering. They are supposed to be the record of how the team decided the device was safe and effective enough to release. When the product system and the quality system can see each other, that record stops being something you assemble and becomes something you already have. Whether your two systems are close to that today is a question worth asking the person who maintains the spreadsheet.

Last updated: 2026-10-09

Frequently Asked Questions

Do I need to integrate my QMS and PLM to meet design control requirements?

No regulation requires a system integration. ISO 13485:2016 clause 7.3.10 requires a design and development file that contains or references the required records, so separate systems are acceptable as long as you can reliably produce a complete, consistent file. Integration is a way to make that dependable, not a mandate.

Which system should be the system of record for design changes?

A common split is that the PLM executes the engineering change (redlines, BOM, effectivity) while the QMS owns the cross-functional assessment and approval. The key is that each field has one authoritative owner, and the PLM should not release a revision until the linked QMS approval exists.

Does a QMS-PLM integration need to be validated?

Yes, in proportion to risk. ISO 13485:2016 clause 4.1.6 requires validation of software used in the quality management system before initial use and after changes. Focus testing on high-risk functions such as the release gate, revision transfer, status accuracy, and failure alerting.

What is the minimum set of links between QMS and PLM?

At minimum: change records to design elements, document revisions to design revisions, risk controls to design outputs, quality events to affected items, approvals to qualified identities, and design transfer records to manufacturing records. Starting with these keeps validation scope manageable.

How does the QMSR change design controls for device manufacturers?

The Quality Management System Regulation, effective February 2, 2026, incorporates ISO 13485:2016 into 21 CFR Part 820 by reference. Design and development requirements are now organized under ISO 13485 clause 7.3, replacing the former 21 CFR 820.30 structure.