Quick Answer
Medical device complaint management software helps manufacturers document complaints, investigate product issues, assess Medical Device Reporting obligations, trend postmarket signals, link CAPA, and retain complaint files. Device teams should connect complaint records to FDA QMSR, 21 CFR Part 803 MDR requirements, 21 CFR Part 806 corrections and removals decisions, CAPA, supplier quality, and Part 11 controls where records or signatures are electronic.
Key Takeaways
- Complaint management is a postmarket QMS workflow, not just customer support.
- 21 CFR Part 803 establishes medical device reporting requirements for manufacturers, importers, and user facilities.
- Corrections and removals decisions may implicate 21 CFR Part 806.
- Complaints should link to investigations, MDR assessment, CAPA, trend review, and risk management.
- Complaint data can affect submissions, labeling, postmarket surveillance, and inspection readiness.
- Medical device complaints are regulatory signals. A support ticket may become a complaint file, MDR assessment, CAPA, field action decision, or future submission consideration.
- This guide explains what complaint management software should support for device companies.
Complaint Management Is a Quality Process
Medical device complaint management is often confused with customer support because support teams are usually closest to the first report. The regulated process is different. A device company needs a controlled way to determine whether incoming information is a complaint, investigate the issue, evaluate reportability, trend similar events, and preserve the record.
The software should support both speed and discipline. Serious events need rapid escalation. Routine complaints need enough structure to support investigation and trending. Non-complaint support interactions still need a documented rationale when procedures require complaint determination.
Good complaint records usually capture:
- Reporter and source information
- Product, model, catalog number, UDI, lot, serial number, and software version where applicable
- Event description, date, location, and user or patient impact
- Whether the product is available for return or evaluation
- Complaint determination and rationale
- MDR assessment and timing
- Investigation plan and conclusion
- CAPA, nonconformance, supplier, or field action links
- Closure approval and retention
If the system cannot distinguish support intake from regulated complaint evaluation, teams will struggle during inspection and postmarket reviews.
Complaint Workflow Structure
| Stage | Software Need |
|---|---|
| Intake | Capture source, product, lot, UDI, patient/user impact, and event description |
| Complaint determination | Decide whether the record is a complaint under procedures |
| Investigation | Document evidence, device evaluation, root cause, and conclusions |
| MDR assessment | Determine reportability and deadlines under Part 803 |
| CAPA decision | Escalate systemic or serious issues |
| Corrections and removals assessment | Evaluate whether Part 806 obligations may apply |
| Trend review | Detect repeat signals |
| Closure | Quality approval and record retention |
For pharma complaint context, see complaint handling guide.
Complaint Determination and Triage
The first workflow decision is whether the incoming information meets the company's complaint definition under its procedures. The software should make that decision visible, not implicit.
Typical triage questions include:
- Does the report allege a deficiency related to identity, quality, durability, reliability, safety, effectiveness, or performance?
- Is the product a distributed device, component, accessory, software version, or service-related issue?
- Is there a death, serious injury, malfunction, or potential malfunction?
- Is there a need to obtain the device, logs, images, or additional user information?
- Does the event involve off-label use, user error, labeling confusion, cybersecurity, packaging, sterility, or shipment damage?
- Does the complaint indicate a trend that should be escalated?
These questions should not be buried in free text. Structured fields help teams triage consistently and create useful trend data later.
Intake Channels and Data Quality
Complaint intake can come from customer support, sales, service teams, distributors, hospitals, patients, field engineers, app telemetry, social channels, or regulators. The software should make it easy for front-line teams to capture the report quickly while giving quality teams enough structure to complete the regulated evaluation.
Useful intake controls include required product identifiers, event date, reporter contact information, country or market, patient or user outcome, device availability, and missing-information follow-up. If the first report is incomplete, the record should show what follow-up was attempted and when.
This matters because complaint quality often determines MDR assessment quality. A vague intake record can lead to late follow-up, weak investigation, and uncertain reportability decisions.
MDR and Part 806 Fit
21 CFR Part 803 establishes reporting requirements for medical device adverse events. Manufacturers must evaluate reportability for deaths, serious injuries, and certain malfunctions.
21 CFR Part 806 addresses reports and records of corrections and removals. Complaint software should preserve the evidence used to support these decisions.
Important capabilities include:
- Reportability assessment fields
- Deadline tracking
- Follow-up reporting
- Complaint files and attachments
- CAPA linkage
- Field action and recall assessment linkage
- Trend dashboards
MDR Workflow Needs
MDR assessment should be explicit and time-aware. The software should support reportability questions, due dates, follow-up information, and final rationale.
Manufacturers generally need to evaluate whether an event involves death, serious injury, or a malfunction that would be likely to cause or contribute to death or serious injury if it recurred. Some circumstances may also require 5-work-day reporting, such as when remedial action is needed to prevent an unreasonable risk of substantial harm to public health or when FDA requests it.
Practical software capabilities include:
- Awareness date capture
- Reportability decision and rationale
- 30-day and 5-work-day report tracking where applicable
- Follow-up report tracking
- Attachments and device evaluation evidence
- Links to CAPA, risk management, and corrections/removals assessment
- Audit trail for reportability decision changes
The record should show not only the final MDR decision, but also the information available when the decision was made. That distinction matters when new information arrives later.
Investigation and Device Evaluation
Complaint investigation quality depends on evidence. Complaint software should help teams track whether the device was returned, whether evaluation was possible, and what evidence supported the conclusion.
Investigation evidence may include:
- Returned product evaluation
- Photographs, videos, device logs, or software logs
- Manufacturing and device history review
- Service and repair history
- Supplier component data
- Sterilization, packaging, or labeling review
- Risk file review
- Similar complaint trend review
- User follow-up and missing information attempts
Not every complaint can be fully investigated. Devices may be unavailable, users may not respond, or evidence may be incomplete. The software should let teams document those limits clearly instead of forcing unsupported conclusions.
Complaint Records and Submissions
Complaint history can affect future 510(k), De Novo, PMA, PMA supplement, labeling, risk management, and FDA questions. If complaint data show a trend, the submission story may need to account for design changes, CAPA, labeling updates, or postmarket controls.
Assyro's eSTAR Validation and medical device regulatory submission software help connect postmarket quality evidence to submission readiness.
Trend Review and Escalation
Complaint data becomes more valuable when it is trended by product, failure mode, severity, lot, software version, geography, use environment, supplier, and time period. The goal is to detect signals early enough to act.
Useful trend views include:
- Repeat failure modes by product family
- Complaints per installed base or units distributed
- MDR-reportable events by product and time period
- Complaint-to-CAPA conversion rate
- Recurrence after CAPA or design change
- Complaints linked to supplier lots or components
- Labeling, usability, or training-related events
Trend thresholds should match the company's risk management and postmarket procedures. The software should make escalation decisions traceable so a reviewer can see why a trend did or did not trigger CAPA, field action review, or regulatory reporting.
Vendor Demo Scenarios
Ask vendors to demonstrate complaint cases that reflect real device work:
- A serious injury complaint that triggers MDR assessment, device evaluation, risk review, and follow-up reporting.
- A malfunction trend that escalates to CAPA after several similar complaints.
- A complaint linked to a supplier component and a supplier corrective action request.
- A returned device investigation where the product evaluation is inconclusive.
- A complaint trend that leads to labeling, design, or software change assessment.
- A correction/removal decision that must preserve Part 806 rationale.
During the demo, look for clean handoffs. Complaint, MDR, CAPA, risk, supplier, and submission evidence should not live in separate systems with manual copy-paste between them.
Common Mistakes
| Mistake | Why It Matters |
|---|---|
| Treating complaints as support tickets only | Regulatory evaluation and record retention can be missed |
| Hiding MDR rationale in free text | Reportability decisions become hard to defend |
| Weak returned-device tracking | Investigations may close without clear evidence limits |
| No link between complaints and CAPA | Trend signals may not drive corrective action |
| No Part 806 decision record | Field action rationale may be hard to reconstruct |
| Trend dashboards without escalation logic | Teams can see data but not prove why action was or was not taken |
It is software for managing device complaint intake, complaint determination, investigation, MDR assessment, CAPA linkage, trend review, field action assessment, and complaint file retention. The best systems connect complaint evidence to risk, postmarket surveillance, supplier quality, and submission readiness.
References
This guide reflects FDA QMSR, MDR, Part 806, and Part 11 information current as of May 2026. Confirm device-specific complaint and reporting procedures before implementation.
About the author
Assyro Team
Expert regulatory operations consultants helping pharmaceutical companies navigate complex compliance challenges.
See Assyro in action
Catch eCTD and eSTAR errors before your FDA review cycle.
Book a 20-minute demo this week. We'll validate a sample of your submission live and show you exactly where Assyro catches what your current QC misses.