> ## Documentation Index
> Fetch the complete documentation index at: https://docs.withdovetail.com/llms.txt
> Use this file to discover all available pages before exploring further.
# Complaint Log
> Track customer complaints systematically enabling trend analysis and quality improvement.
## Summary
The Complaint Log systematically records and tracks **customer complaints** and **negative product events** related to device performance, safety, or effectiveness. This document serves as your central repository for complaint management, enabling **regulatory compliance**, **trend analysis**, and **quality improvement** activities.
## Why is Complaint Log important?
The Complaint Log provides **regulatory evidence** that you systematically monitor and respond to customer feedback about device safety and performance issues. Regulatory authorities require documented complaint handling processes to ensure manufacturers identify and address potential safety risks before they cause patient harm. Your complaint log feeds directly into **post-market surveillance activities**, **trend analysis**, and **corrective action decisions**. Without proper complaint documentation, you risk **regulatory non-compliance**, **missed safety signals**, and potential liability for failing to address known device issues.
## Regulatory Context
Under **21 CFR Part 820** (Quality System Regulation):
* **Complaint files** required under Section 820.198 for device-related complaints
* Must maintain records of **oral and written complaints** involving device failures
* **Investigation and evaluation** of complaints affecting device safety required
* **Medical Device Reports (MDRs)** under 21 CFR 803 for serious complaints
**Special attention required for:**
* **Class III devices** requiring enhanced complaint investigation
* **Software malfunctions** that could affect patient safety
* **Repeat complaints** indicating systematic quality issues
* **Use errors** potentially related to design or labeling deficiencies
Under **EU MDR 2017/745**:
* **Complaint handling** required as part of quality management system (Article 10)
* Must comply with **EN ISO 13485:2016** complaint handling requirements
* **Serious incidents** must be reported to EUDAMED within specified timeframes
* **Trend analysis** required for complaint pattern identification
**Special attention required for:**
* **Serious incidents** requiring immediate regulatory reporting (Article 87)
* **Field Safety Corrective Actions** based on complaint investigations
* **Post-market surveillance** integration with complaint data analysis
* **Clinical evaluation updates** based on real-world use experience
## Guide
Your Complaint Log must capture all **device-related complaints** and **negative product events** while distinguishing them from general customer support inquiries that don't relate to device performance or safety.
### Complaint Identification and Classification
**Distinguish between complaints and general feedback** by focusing on communications alleging deficiencies in device **identity**, **quality**, **durability**, **reliability**, **safety**, **effectiveness**, or **performance**. Record complaints that cannot be resolved by providing basic use instructions or clarifying information to users.
**Identify negative product events** including any feedback resulting from device problems that could cause or may have caused death or serious health deterioration, device malfunctions affecting characteristics or performance, use errors due to ergonomic features, inadequate manufacturer information, or undesirable side effects.
**Assign unique complaint identifiers** using the format "CT" followed by a four-digit number (e.g., CT0001, CT0002) to ensure traceability and systematic tracking throughout your quality management system.
### Data Collection and Documentation
**Capture essential complaint information** including customer identification, date received, product version affected, complaint source (email, social media, vigilance database), detailed issue description, and assessment of impact on device performance or safety.
**Document resolution processes** by categorizing complaints according to their nature and required response: software issues requiring bug resolution procedures, product issues potentially leading to regulatory non-compliance requiring corrective actions, changes requiring change management processes, or minor issues requiring only documentation for future improvements.
**Track complaint resolution** from initial receipt through final closure, documenting specific actions taken and justification for decisions including no action when appropriate. Record closure dates when complaints are sent to appropriate resolution processes, not when those processes are completed.
### Quality Management Integration
**Connect complaints to your quality system** by routing software issues through **Software Problem Resolution** procedures, product compliance issues through **Corrective and Preventive Action (CAPA)** systems, and required changes through **Change Management** processes.
**Evaluate complaint significance** by assessing whether issues relate to device performance, safety, or regulatory compliance. Complaints affecting these areas require more serious investigation and potential regulatory reporting compared to user preferences or unverifiable issues.
**Perform trend analysis** by reviewing complaint patterns, frequencies, and types to identify systematic issues requiring preventive action. Use complaint data to inform **post-market surveillance reports** and **risk management file** updates.
### Regulatory Reporting and Follow-up
**Assess regulatory reporting requirements** for serious complaints that may constitute reportable incidents under FDA MDR requirements or EU MDR serious incident reporting obligations. Determine appropriate timeframes and notification procedures based on complaint severity.
**Monitor complaint effectiveness** by tracking whether implemented solutions successfully address underlying issues and prevent recurrence. Document lessons learned and process improvements based on complaint investigation outcomes.
**Maintain complaint records** according to regulatory requirements for record retention, ensuring complaint files remain accessible for regulatory inspections and audit activities.
## Example
**Scenario:** You manufacture a glucose monitoring app and receive various customer communications. You need to distinguish between complaints requiring documentation and general support inquiries while properly categorizing and processing each complaint through appropriate resolution procedures.
### Complaint Log for GlucoTrack Mobile App
| Complaint ID | Customer ID | Date Received | Product / Version | Source | Description | Impact on Performance / Safety | Resolution Process | Action Taken | Date Closed |
| ------------ | ----------- | ------------- | ----------------- | ---------------- | ------------------------------------------------------------ | -------------------------------------------------- | -------------------------------- | ------------------------------------------------------ | ----------- |
| CT0001 | CS0001 | 2024-03-15 | GlucoTrack v2.1 | Email complaint | App crashes when entering glucose values above 400 mg/dL | Yes - prevents critical high glucose documentation | SOP Software Problem Resolution | Bug fix implemented in v2.1.1, user notified of update | 2024-03-18 |
| CT0002 | CS0002 | 2024-03-20 | GlucoTrack v2.1 | App store review | Insulin calculator provides incorrect dosing recommendations | Yes - potential for medication errors | SOP CAPA | CAPA-2024-001 initiated, algorithm validation required | 2024-03-21 |
| CT0003 | CS0003 | 2024-03-25 | GlucoTrack v2.1 | Customer support | Cannot sync data with doctor's system | Yes - affects clinical decision support | SOP Change Management | CR-2024-005 submitted for API compatibility update | 2024-03-26 |
| CT0004 | CS0004 | 2024-04-02 | GlucoTrack v2.1 | Social media | Prefers different color scheme for charts | No - user preference only | Recorded for future improvements | Feedback documented for next version planning | 2024-04-02 |
**Complaint Processing Examples:**
**CT0001** - Software crash affecting safety-critical functionality required immediate software problem resolution with user notification and version update.
**CT0002** - Dosing calculation error identified as potential regulatory compliance issue requiring formal CAPA investigation and algorithm validation.
**CT0003** - Data synchronization failure affecting clinical workflow required change management process to evaluate and implement system compatibility improvements.
**CT0004** - User interface preference classified as enhancement request for future consideration without immediate action required.
## Q\&A
Record complaints alleging deficiencies in device identity, quality, durability, reliability, safety, effectiveness, or performance that cannot be resolved with basic instructions. Include negative product events that could cause health deterioration, device malfunctions, use errors, or inadequate information. General support inquiries and user preferences don't require complaint log entry.
Log only feedback related to device performance or safety in your complaint log. General feedback or support issues that can be resolved with instructions don't need QMS documentation. Use separate systems like ticketing platforms to track non-complaint feedback while ensuring medical device-related issues are properly categorized.
Implement ticket management systems that categorize medical and non-medical device complaints. Log all complaints but mark their relevance to medical device performance. Track additional criteria for relevant complaints including severity, resolution requirements, and regulatory implications. Consider automation tools for initial categorization.
Route software issues through Software Problem Resolution procedures, product compliance issues through CAPA systems, and required changes through Change Management processes. Document complaints that are duplicate, unverifiable, or represent user preferences for future improvements or mark as requiring no immediate action.
Maintain running lists of all complaints specifying their relevance to medical device performance. Use systematic categorization based on impact on performance, safety, or compliance. Ensure complaint logs support post-market surveillance activities and provide evidence of systematic complaint handling for regulatory inspections.
Report serious incidents immediately when complaints involve death, serious injury, or life-threatening situations. Assess whether complaint patterns indicate trends requiring regulatory notification. Consult regulatory requirements for specific timeframes and reporting procedures based on complaint severity and geographic markets.