Does QMSR require a medical device manufacturer to hold an ISO 13485 certificate?

No. FDA states that it will not require certificates of conformance to ISO 13485, and holding a certificate does not exempt a manufacturer from FDA inspection. Under QMSR, the requirement is to document a quality management system that complies with ISO 13485:2016 as incorporated by reference into Part 820. A certificate may matter for commercial or customer purposes, but it is not the FDA requirement itself. The practical consequence is that a certificate cannot stand in for the documented quality system and the records it produces, which remain the manufacturer's to maintain.

Does every medical device complaint need its own investigation under QMSR?

No. Part 820 allows a manufacturer not to conduct a new investigation when a similar complaint has already been investigated and another investigation is not necessary. But that is not a free pass. The manufacturer still has to document the reason no new investigation was performed. That justification belongs in the complaint record, not in a side note or informal explanation. The practical consequence for system design is that the complaint workflow has to support that branching decision and capture the rationale in a controlled field, not as a free-text workaround.

Which complaints need the full set of details recorded under Part 820?

The full set of specified complaint-record details applies to three complaint categories under Part 820: complaints reportable under Part 803, complaints the manufacturer determines must be investigated, and complaints the manufacturer investigated anyway. Not every intake event is treated the same way, but once a complaint falls into one of those categories, the specified record content follows. The system consequence is that the complaint workflow has to support that branching logic and make sure required fields are captured in the controlled record, not outside it.

What does Part 820 require a manufacturer to record when a device is serviced?

Part 820 requires the servicing record to hold, at a minimum, six items: the name of the device serviced; any UDI or UPC, and any other device identification; the date of service; the individual or individuals who serviced the device; the service performed; and any test and inspection data. These sit alongside the servicing activities clause of ISO 13485. For system design, servicing records are a requirement of their own: they should not be assumed to be covered because shipment, complaint, or work order data already exists elsewhere in the environment.

Do component suppliers have to follow Part 820?

No. Part 820 states that component manufacturers are not subject to the regulation, though they are encouraged to consider its relevant provisions. That does not remove the finished device manufacturer's responsibility. Supplier controls still sit inside the manufacturer's own quality management system. So the implementation consequence is indirect but real: supplier qualification, purchasing controls, and supplier-related quality records still need to support the finished device manufacturer's obligations under its own QMS, regardless of what the supplier's internal practices are.

Which devices need implant-level traceability under QMSR?

Part 820 requires the Traceability for Implantable Devices clause of ISO 13485, Clause 7.5.9.2, for manufacturers of devices that support or sustain life and whose failure to perform, when properly used according to the instructions for use in the labeling, can reasonably be expected to result in a significant injury. The practical consequence is that a manufacturer has to classify which products fall into that category and make sure the traceability design supports the level of identification and record continuity those devices require. That classification decision should be settled before the traceability configuration is built.

Can FDA review management review and audit reports during a QMSR inspection?

Yes. FDA states that under QMSR it has authority to inspect management review records, quality audit reports, and supplier audit reports. FDA also states that inspections now follow Compliance Program 7382.850, replacing the withdrawn QSIT approach. These records are not outside inspection scope because they are sensitive or internal. A manufacturer's system design should assume that controlled quality records need to be retrievable and understandable on demand. The question is not whether they exist somewhere, but whether they are maintained in a form the organization can stand behind.

Should a device manufacturer plan its CRM at the same time as an Epicor Kinetic implementation?

Yes. The implementation guidance is to plan the CRM at the same time, even if the build happens later when the team is ready. The benefit is that the customer master and pricing can be designed once from the start instead of being reworked after ERP decisions are already fixed. In a device environment where customer records, shipment history, complaint intake, and certification status cross systems, a CRM planned separately from the ERP creates integration debt that has to be paid later. The Epicor Kinetic implementation service covers how those connected decisions can be planned together.

Can a Kinetic implementation already under way at a device manufacturer be handed to a new partner?

Yes. A Kinetic implementation already in progress can be taken over through a structured health-check process, followed by a fixed-price plan to finish or fix the work. That matters when the issue is not software selection but execution quality, scope drift, or unresolved design decisions around records, migration, and process ownership. A handover does not erase what has already been built, but it can reset the project around a clear plan. The Epicor Kinetic implementation service describes how that process works.

Medical Device ERP Under QMSR: What Kinetic Handles

Q: Who can change the certification status that lets product ship to a facility?

The certification status is controlled, not manually overridden by a sales rep. In the described MedTech CRM workflow, the certified flag on the location is read-only and is set only when the signature process completes. A rep cannot tick a box to push product out the door. That matters because the shipping gate depends on a controlled status rather than a discretionary user action. The setup behind that gate, and how it connects to the shipment workflow, is covered on the CRM for MedTech page.

A medical device ERP now sits inside a new regulatory frame. Since February 2, 2026, FDA's device quality rule has carried a new title: the Quality Management System Regulation, or QMSR. Under the current 21 CFR Part 820 text, a manufacturer documents a quality management system that complies with ISO 13485:2016, and the definitions of ISO 13485 and Clause 3 of ISO 9000 apply.

That change matters because it changes how an implementation team should read the rule. And the practical question for any team running or selecting Epicor Kinetic is not whether the ERP is compliant. The better question is which records Part 820 still spells out field by field, which system should own each one, and what has to be configured before go-live so those records can be created without improvisation.

This article reads the QMSR record requirements as an ERP specification. It maps each requirement to the system that should hold it in a Kinetic environment and names the configuration decisions to make before the project closes.

What QMSR Changed for a Medical Device ERP

Part 820 has been revised. Since February 2, 2026, the rule incorporates ISO 13485:2016 by reference. The definitions that apply are those of ISO 13485 and Clause 3 of ISO 9000. The term the current text uses is medical device file.

The current Part 820 text does not contain the terms device history record or device master record. Those terms appeared in the prior version of the rule. If your internal requirements documents, work instructions, or project templates still use them, the practical step is to reread the current Part 820 text and identify which records it still spells out. That is a reading task, not a rename obligation.

The more useful frame is this. QMSR does not tell you which software to buy. It does tell you that certain records must exist, and for some of them it tells you what those records must contain. Those fields are not abstract regulatory concepts. They are system design decisions.

Part 820 covers the design, manufacture, packaging, labeling, storage, installation, and servicing of all finished devices intended for human use. A manufacturer that performs only some of those operations complies with the requirements for those operations only. So the right implementation scope starts with your actual operation, not a generic checklist.

What Part 820 still spells out

QMSR adds a short list of record requirements with specified content that sits alongside the ISO 13485:2016 quality management system obligation. Those requirements appear in:

820.10(b): The documented system for unique device identification, traceability procedures where applicable, and the reporting pathway for complaints that meet Part 803 criteria.
820.35: Complaint records, including the specific fields required for reportable complaints, investigated complaints, and complaints investigated regardless of reportability.
820.45: Labeling and packaging examination before release or storage, documented release, and mixup prevention with inspection results recorded.

Each of those requirements produces data. That data has to live somewhere. The rest of this article is about where.

The Records Part 820 Spells Out, Mapped to the System That Holds Them

The most useful way to read these sections is as a system-boundary exercise. The rule states what has to be documented. Your implementation has to decide where each field is created, which system owns it, and which connected systems only read it.

Requirement	What the rule asks for	Where we recommend the data live	Decision to make
820.10(b)(1)	A documented system to assign unique device identification under Part 830	Quality system plus ERP-connected operational workflow	Where the UDI is captured, and which system is the source for assigned and carried identification
820.35(a)	Complaint records with specified content for reportable complaints, complaints the manufacturer determines must be investigated, and complaints investigated anyway	Quality system as the complaint record owner, fed by CRM and ERP data	Which system owns the complaint record, and how customer, device, shipment, and corrective-action data feed it
820.35(c)	The UDI must be recorded for each medical device or batch of medical devices	Operational record where device or batch traceability is captured, connected to ERP traceability data	Whether UDI is captured at device level or batch level, and at what point in the process it is recorded
820.45	Labeling and packaging examined for accuracy before release or storage, including correct UDI or UPC, expiration date, storage, handling, and additional processing instructions; release of labeling documented; mixup prevention with inspection results recorded	ERP-supported labeling and shipping workflow, with quality review where the manufacturer's process requires it	Which step checks label data, how release is documented, and how mixup prevention and inspection results are recorded

The rule of thumb: one owning system per field

The critical discipline here is single ownership. A field can be visible in more than one place, but it should be authored in one place. If a complaint record needs the device name, that value should not be typed freehand in three systems. If a labeling check needs an expiration date, that date should not be maintained in a spreadsheet and then re-entered into the release workflow.

The third column in the table above is a recommendation, not a claim about Epicor-stated architecture. The rule tells you what must exist. It does not assign software modules. So the right implementation posture is to recommend a design that reduces duplicate entry and makes record ownership explicit before go-live.

In a Kinetic environment, that means lot and serial traceability can live in ERP records where manufacturing and shipment activity already occur. It does not mean every regulatory record should be declared an ERP record by default. Complaint ownership, UDI capture point, and labeling release evidence all need an intentional design decision before the project closes.

Why the decision matters before migration

That design choice has a downstream consequence that is easy to underestimate. Migration and training follow the ownership decision. If you decide late that customer service enters complaint intake in one system, quality completes investigation in another, and ERP contributes shipment data from a third, you are not changing a preference. You are changing fields, roles, integrations, and work instructions. Getting the ownership map right early means the system you configure and the one you train users on are the same system.

Lot and Serial Traceability: What Kinetic Has to Hold

Part 820 requires a documented system to assign unique device identification under Part 830. It also requires traceability procedures under Part 821 where applicable. And in its records section, it states that the UDI must be recorded for each medical device or batch of medical devices.

That is where Kinetic enters the picture in a concrete way. Epicor lists Lot and Serial Tracked Parts, WIP PCIDs, Serial Genealogy of components and products, and the ability to allocate parts to customers by lot and serial designation among its medical device capabilities. Those are manufacturing and traceability capabilities. They are directly relevant because they determine whether the ERP can carry the production and shipment evidence needed when a device or batch has to be identified later.

But the implementation decision is narrower than the capability label. Kinetic can hold lot and serial data. Your team still has to decide where the UDI is captured, how it is linked to the device or batch, and how that identification travels into downstream records.

The configuration decisions in traceability

Which parts are lot tracked and which are serial tracked.
This is a product and process decision before it is a configuration decision. If the wrong tracking mode is assigned, downstream genealogy and shipment history lose value.
Where the UDI is captured in the process.
Part 820 requires a documented system to assign UDI, but your implementation must decide whether capture happens at manufacturing, labeling, packaging, or another controlled step. That decision drives which workflow becomes the source for later records.
How deep genealogy needs to go.
Epicor describes serial genealogy of components and products. The project still has to decide how far back and how far forward genealogy needs to be visible for your operation and your product types.
How shipment records carry lot and serial designation.
Epicor states that parts can be allocated to customers by lot and serial designation. That matters because the shipment side is where traceability meets the customer record, and where complaint lookup will start if an issue surfaces later.

The UDI is not the same as lot and serial

The practical mistake here is to collapse UDI into lot and serial without thinking through the capture point. Lot and serial data are core traceability data in Kinetic. They support identification, genealogy, and shipment history. The UDI decision is broader. It has to account for the point where the identifier is assigned or recorded, the form in which it is carried, and the system that becomes the source for later complaint, labeling, or shipment lookups.

Kinetic supplies lot and serial data. Where the UDI is captured, and which system becomes the record of that capture, is the decision your team has to make before the configuration step begins. If that decision is deferred, the traceability design will be built on an assumption that may not hold.

Labeling Checks, Release and the Shipment Hold

Section 820.45 is a labeling and packaging control. It requires labeling and packaging to be examined for accuracy before release or storage. That examination covers five items the rule names:

The correct UDI or UPC
Expiration date
Storage instructions
Handling instructions
Any additional processing instructions

It also requires that release of labeling be documented, and that operations be set up to prevent mixups, with inspection results recorded.

That is narrower than a general release checklist. The requirement is about labeling and packaging accuracy, documented release, and mixup prevention. It is not a finished-device release record in the broader sense.

What the ERP holds for this

For an ERP design, that means the system has to support the data and process steps around label content accuracy and release documentation. Kinetic's listed modules include Inventory Management, Warehouse Management, Shipping and Receiving, and Quality Management. Those are the areas where product, lot, expiry, and movement data can be organized into a controlled labeling and release flow.

The practical implementation question is not whether one screen can display everything. It is whether the data used in labeling and packaging checks is sourced consistently, and whether release documentation and inspection results are captured where the process actually happens.

A team also has to decide how to prevent mixups operationally. That can include how labels are generated, how packaging is matched to the right device or batch, what gets inspected before release or storage, and where the inspection result is recorded. If those controls sit partly in ERP and partly in an adjacent quality workflow, the handoff between them has to be explicit.

The commercial gate alongside the labeling control

There is a separate release-side business rule that sits next to the 820.45 control but is not the same requirement. In the SugarAI setup described on the CRM for MedTech page, operations will not release product to a site unless a certified doctor is there. The certified flag on the location is read-only and is set only when the signature process completes. A rep cannot tick a box to push product out the door.

That is a commercial and operational gate tied to customer readiness. It should be designed alongside ERP shipping logic because it can stop a shipment. But it is not an 820.45 requirement. The labeling and packaging control and the certification gate address different things and should be configured with that distinction in place.

Complaints Start Outside the Plant

A complaint does not start as a quality record. It starts as an event. A rep hears about it. Customer service receives a call. A hospital contact raises an issue. By the time quality reviews it, parts of the record already exist in other systems, or they should.

That is why 820.35(a) is so important for ERP design. For complaints that are reportable under Part 803, complaints the manufacturer determines must be investigated, and complaints it investigated anyway, the rule specifies seven items the record must hold. Those items should be mapped deliberately before the system goes live.

The seven items, and where each should come from

1. The device name.
This should come from the product data already governed in the operational system. It should not be free text typed into the complaint workflow by whoever handles intake.

2. The date received.
This belongs to the intake event. The system that first logs the complaint should create this field. If intake happens in a CRM or customer service tool, the date should carry forward rather than be re-entered later.

3. Any UDI or UPC, and any other device identification.
This is the rule's own wording, and it is broader than lot and serial. Where this identification comes from depends on where the UDI is captured, the traceability decision described above. Kinetic supplies lot and serial data, which supports identification and traceability. The broader identification field has to be sourced from the system that owns the UDI capture point.

4. The complainant's name, address and phone number.
These are customer-side fields. They should come from the customer-facing side of the environment, not be rebuilt from scratch by the quality team working the complaint.

5. The nature and details of the complaint.
This starts with intake and must be preserved in the complaint-owning record. If the intake system is not the complaint-owning system, the transfer has to be explicit, not a copy-paste.

6. Any correction or corrective action.
This belongs with the quality process that evaluates and acts on the complaint. It originates in the quality system rather than in ERP or CRM.

7. Any reply to the complainant.
This may originate through customer-facing teams, but it should be attached to the complaint record so the full history stays in one place.

Which system owns the complaint record

Your team has to decide which system is the complaint record owner. Our recommended design is that the quality system owns the complaint record, with ERP and CRM feeding the fields they already control. That keeps corrective action with the quality workflow while still pulling in the product, shipment, and customer data needed to make the record complete without re-entering it.

The integration between Kinetic and SugarAI matters here because accounts, parts, quotes, orders, shipments, and invoices flow between the two. If the customer and commercial history already lives across Kinetic and SugarAI, complaint intake should use that shared context instead of creating a parallel record.

Epicor describes medical device capabilities that include complaints handling and electronic Medical Device Reporting, as well as integrated support for CAPA, Supplier Corrective Action Requests, and planned deviations. That is useful context. It shows that complaint processes are part of the medical device capability set Epicor describes. It does not remove the implementation decision about which system owns the record of complaint.

Part 820 also requires that complaints meeting Part 803 reporting criteria be reported to FDA. That is a process consequence of the complaint evaluation, not a separate ERP field. But it does mean the complaint workflow has to include a step where reportability is assessed and documented.

If your team is also sorting out the handoff between customer-facing workflows and ERP data, read ERP vs CRM for medical device manufacturers for the boundary question. This article covers the complaint record consequence of that boundary, not the boundary itself.

See how TCP implements Epicor Kinetic

Suppliers and the Shop Floor

Supplier and production evidence should not be treated as cleanup work after the fact. In a Kinetic environment, those records are stronger when they are created as the work runs, not assembled from memory and paper notes afterward.

On the supplier side, Kinetic lists Supplier Relationship Management and Purchase Management among its modules. Epicor also describes Supplier Corrective Action Requests (SCAR) and CAPA as part of its medical device capability set. That matters because supplier issues do not stay isolated. They affect incoming material control, purchasing decisions, quality follow-up, and in some cases complaint or corrective-action history. The implementation decision is how those flows connect, and which system triggers which action when a supplier issue is identified.

Shop-floor evidence created in real time

On the shop floor side, Advanced MES adds a different kind of evidence creation. Advanced MES captures machine and operator data in real time, applies SPC and SQC, records scrap, yield and quality metrics, and feeds them back to the ERP.

That changes the implementation posture in a practical way. Real-time capture means production evidence is generated where the work occurs, then fed back into the ERP record set that operations and quality already use. The alternative, assembling production evidence after the fact from operator memory and paper logs, introduces gaps that are hard to close later.

The ERP and MES roles stay distinct. ERP owns the broader operational record. MES contributes execution-level data that the ERP should not ask users to recreate manually. If you want the fuller boundary between the two, read Epicor MES vs ERP. For a device plant, the relevant point is simpler: if MES is in scope, the data flow back to ERP has to be designed before go-live, not discovered during training.

Decisions to Make Before Kinetic Goes Live

If a device manufacturer waits until testing or training to answer these questions, the project is already late. These decisions belong before go-live because they affect configuration, migration, roles, and connected workflows. Each one is tied to an earlier section of this article.

Set tracking mode per part.
Decide which parts are lot tracked and which are serial tracked. This choice drives genealogy, shipment history, and later complaint lookup. Getting it wrong at the start means undoing it after data is already in the system.
Choose the UDI capture point.
Part 820 requires a documented system to assign unique device identification under Part 830. Your implementation has to decide where that capture happens, which step in the process creates or records it, and which system becomes the source for later complaint, labeling, and shipment records.
Define label data and the labeling release step.
Decide where the correct UDI or UPC, expiration date, storage instructions, handling instructions, and additional processing instructions are authored, checked, and released. Decide how release is documented and how inspection results are recorded.
Choose the complaint record owner and define the feeds into it.
Decide which system owns the complaint record, then define how product, shipment, customer, and corrective-action data feed it. The goal is one record with no duplicate entry.
Define supplier and nonconformance flow.
If supplier issues can trigger SCAR, CAPA, or downstream quality action, decide how that handoff works before users invent their own workarounds.
Decide where shop-floor data enters.
If Advanced MES is in scope, decide what gets captured there and how it feeds back to the ERP. That design belongs before configuration, not after go-live.
Handle open lots and serials in migration.
Migration covers items, BOMs, routings, customers, suppliers, open orders, and open AP and AR. For a device plant, open lots and serial-linked operational records need a migration rule too. Leaving them out means the historical traceability record has a gap from day one.
Treat deployment cadence as an input to your own validation plan.
Kinetic can be deployed as multi-tenant SaaS, private cloud, on-premises, or hybrid. Epicor states that Kinetic updates run on a deferred cadence that supports compliance requirements. Your quality system owns the decisions about how that environment is governed and validated.

If you want the broader implementation phase view, read the Epicor Kinetic implementation guide. This article is narrower by design. It covers the record and workflow decisions that should be settled before those phases begin.

TCP is an Epicor Platinum Partner and SugarAI Elite Partner with over 600 implementations across the Americas, and has built lot and serial tracking for medical and other regulated manufacturers.

Your quality and regulatory program, and final responsibility for it, remains with you. What an implementation partner can do is make sure every record the rule spells out has one system that owns it, and that the system is configured before training starts, not after.

Talk to TCP about Kinetic for a device plant

If your QMSR records still live across spreadsheets and shared drives, TCP can implement Kinetic so every record the rule spells out has one system that owns it.