Medical Device Complaint Handling Flowchart: From Intake to Closure
Share
Medical Device Complaint Handling Flowchart: From Intake to Closure
A complaint process can look deceptively simple on paper: receive the complaint, investigate it, document the result, and close the record.
In practice, that is where things often start to unravel.
The initial information may come through customer service, field service, sales, technical support, a distributor, or even an informal conversation with a customer. Someone has to recognize that the information may represent a complaint, route it correctly, determine whether it requires investigation or regulatory reporting, document the outcome, and make sure the record does not disappear into a backlog.
For a growing medical device company, the challenge is not just writing a complaint procedure. It is building a workflow that people can actually follow.
A Simple Medical Device Complaint Handling Flow
A practical complaint-handling process can be organized around the following decision path:
1. Information Received
Customer feedback, service request, support call, distributor notification, returned product, sales communication, or other post-market information is received.
↓
2. Complaint Screening
Determine whether the information alleges a deficiency related to the identity, quality, durability, reliability, usability, safety, effectiveness, or performance of a released medical device.
↓
3. Complaint Record Created
Capture the available information, assign responsibility, establish dates, and document the initial classification.
↓
4. Regulatory Reporting Assessment
Determine whether the event requires evaluation under applicable medical device reporting requirements or other jurisdiction-specific reporting obligations.
↓
5. Investigation Decision
Determine whether investigation is required. If an investigation is not performed, document and justify the decision according to the company's approved process.
↓
6. Investigation
Review available device history, service information, returned product findings, manufacturing records, software data, prior complaints, and other relevant evidence.
↓
7. Cause and Risk Evaluation
Document findings, determine whether the issue indicates a broader quality problem, and evaluate whether escalation into CAPA or another quality-system process is appropriate.
↓
8. Complaint Closure
Confirm required documentation is complete, regulatory decisions are recorded, investigation conclusions are supported, and any related actions are properly linked before closing the complaint.
↓
9. Trending and Management Review
Use complaint data to identify recurring issues, product trends, service trends, systemic failures, and potential emerging risks.
Why Complaint Intake Is Usually the Weakest Point
Many complaint systems fail before the complaint record is ever created.
A field service engineer may describe the event as a repair. Technical support may record it as a ticket. Customer service may treat it as a routine request. Sales may receive feedback during a customer visit and never recognize that the information should enter the quality system.
That is why complaint intake should not depend entirely on employees knowing regulatory definitions from memory.
A better approach is to give customer-facing teams a short screening process built around recognizable questions:
- Is the customer alleging that the device failed to perform as expected?
- Was there a concern involving safety, effectiveness, reliability, usability, quality, or performance?
- Did the issue occur after the device was released for distribution?
- Could the event involve patient or user harm?
- Has the same or a similar issue happened before?
If the answer suggests a potential complaint, the information should be routed for formal evaluation rather than dismissed at the intake stage.
Complaint vs. Service Request
One of the most common operational problems is treating service records and complaint records as completely separate systems.
They may be separate records, but the information often overlaps.
A service request such as preventive maintenance, relocation, installation assistance, or routine configuration support may not represent a complaint. A service call describing repeated device failures, unexpected shutdowns, inaccurate results, damaged components, software malfunctions, or other alleged performance deficiencies may require complaint evaluation.
The important control is not whether the event started in the service department. The control is whether the information received meets the company's complaint-evaluation criteria.
Related: Medical Device Complaint vs. Service Request: Where Is the Line?
The Complaint Record Should Tell the Story
A reviewer should be able to open a complaint record months later and understand what happened without reconstructing the event from several disconnected systems.
At a minimum, the record should make it clear:
- What was reported
- When the information was received
- Which device or product was involved
- Who performed the initial evaluation
- Whether regulatory reporting was considered
- Whether an investigation was required
- What evidence was reviewed
- What the investigation concluded
- Whether corrective or preventive action was considered
- Why the complaint was closed
The current FDA Quality Management System Regulation incorporates ISO 13485:2016 into 21 CFR Part 820. Complaint-handling requirements are addressed through ISO 13485:2016, including Clause 8.2.2, while FDA-specific complaint-record requirements are also contained in 21 CFR 820.35. Companies selling medical devices in the United States should make sure their complaint process addresses both the incorporated quality-system requirements and applicable FDA-specific requirements.
Do Not Treat the Investigation as a Checkbox
An investigation should answer a meaningful question: what does the available evidence tell us about the reported problem?
That may require reviewing:
- Returned product findings
- Service records
- Manufacturing history
- Device logs or software records
- Lot, serial number, or configuration information
- Installation history
- Previous complaints involving similar symptoms
- Supplier information
- Known product or software issues
For some complaints, the investigation may be relatively straightforward. For others, there may not be enough evidence to establish a definitive root cause.
That is acceptable when the limitation is documented honestly.
What creates risk is closing records with vague conclusions such as “unable to duplicate,” “customer issue,” or “no problem found” without showing what was actually reviewed.
Build Regulatory Reporting Into the Workflow
Complaint handling and regulatory reporting should not operate as unrelated processes.
The complaint workflow should include an early assessment of whether the information could trigger Medical Device Reporting requirements under 21 CFR Part 803 or another applicable reporting obligation.
The assessment does not necessarily mean that every complaint is reportable. It means the organization has a defined method for identifying events that require further regulatory evaluation.
This is particularly important when complaint information first enters through technical support or field service, where the employee receiving the information may be focused on restoring the device rather than evaluating regulatory significance.
Do Not Wait Until Closure to Think About Trending
Complaint trending is often treated as a monthly or quarterly reporting exercise. That misses part of its value.
The complaint process itself should capture structured information that makes meaningful trending possible later.
Useful categories might include:
- Product family
- Failure mode
- Component
- Software version
- Root cause category
- Service activity
- Geographic region
- Severity
- Repeat occurrence
If every complaint is described differently in free text, trending becomes difficult and unreliable.
A simple controlled taxonomy can make a significant difference.
When Should a Complaint Escalate to CAPA?
Not every complaint requires a CAPA.
But complaint handling should include a defined method for identifying issues that may need broader corrective action.
Examples might include:
- Repeated failures involving the same component
- Increasing complaint frequency
- A significant safety or performance issue
- A systemic process failure
- A recurring software defect
- A supplier-related pattern
- An issue affecting multiple customers or devices
The complaint record does not need to contain the entire CAPA investigation, but it should clearly document the relationship when an escalation occurs.
What Startups Commonly Get Wrong
Growing medical device companies often make the same complaint-management mistakes:
- Only Quality employees know how to recognize a complaint.
- Service tickets and complaints are maintained with no connection between them.
- Complaint investigations depend on informal email conversations.
- Returned parts are not connected back to complaint records.
- Regulatory reporting decisions are poorly documented.
- Complaint closure becomes a backlog-clearing exercise.
- Complaint categories are inconsistent, making trending nearly impossible.
- CAPA escalation criteria are unclear.
Most of these problems are not solved by writing a longer SOP.
They are solved by designing a clearer process.
A Practical Complaint Management System
A startup does not need an enormous enterprise complaint platform on day one.
It does need a controlled system that establishes:
- How complaints are identified
- Who owns complaint evaluation
- How reporting decisions are made
- How investigations are documented
- How service and returned-product information is connected
- How complaints are approved for closure
- How recurring issues are trended
- How potential systemic issues are escalated
If those controls are clear, the technology supporting them can evolve as the company grows.
Build the Workflow Before the Backlog
Complaint management gets much harder once records begin accumulating faster than the organization can evaluate them.
Building the workflow early gives customer support, service, quality, regulatory, and engineering teams a shared understanding of what happens when a customer reports a problem.
That is the real purpose of the complaint flowchart.
It is not simply a diagram for an SOP. It is the operating model connecting customer feedback to the quality system.
Need a Starting Point?
Groundwork Quality Systems created the Medical Device Complaint Management & Investigation Starter Kit to help growing medical device companies establish a practical complaint-handling framework without starting from a blank page.
View the Medical Device Complaint Management & Investigation Starter Kit →
You can also download the Medical Device Startup SOP Checklist to review other core procedures a growing quality system may need.
Download the Medical Device Startup SOP Checklist →
References
- U.S. Food and Drug Administration, Quality Management System Regulation (QMSR)
- 21 CFR Part 820, Quality Management System Regulation
- ISO 13485:2016, Medical devices — Quality management systems — Requirements for regulatory purposes
- 21 CFR Part 803, Medical Device Reporting
This article is provided for general educational purposes and does not constitute legal or regulatory advice. Medical device manufacturers should evaluate the requirements applicable to their specific products, markets, and quality systems.