Intake
- Call center, email, web form and field service
- App store reviews and support tickets for SaMD
- Required complaint fields enforced
- Aware date captured on receipt
Medical Device Complaint Handling
Medical device complaint handling software
A complaint that sits in an inbox can turn into a late medical device report. Agnotic Technologies builds complaint handling software that takes every complaint from intake to a documented reportability decision and an eMDR filing, with AI that helps sort complaints while your people make every call.
Aware-date clocksReportability decisionseMDR filingPeople decide
Trusted by global innovators
Complaint handling
What is medical device complaint handling software?
Medical device complaint handling software takes each complaint from intake through investigation, the MDR reportability decision and electronic submission to FDA, and keeps the records FDA expects. Agnotic Technologies builds complaint handling software for device and SaMD makers, using AI only to sort and group complaints while qualified people make every reportability call.
The clock starts when anyone in your company becomes aware of a possible reportable event, not when the complaint reaches the quality team. So the software is built around the aware date.
Complaints also feed corrective action and trend analysis. Those live in your quality management system; this software hands each complaint over with the link intact.
Decision table
Which report does each complaint event trigger?
The table the reportability screen is built from, per 21 CFR Part 803 and the QMSR. Your regulatory lead confirms the wording and owns every decision.
| Complaint event | Report it triggers | Clock | Record the software keeps |
|---|---|---|---|
| Device may have caused or contributed to a death | Medical device report to FDA | 30 calendar days from becoming aware | Event details, investigation, reportability reasoning, submission and FDA acknowledgment |
| Device may have caused or contributed to a serious injury | Medical device report to FDA | 30 calendar days from becoming aware | The same, plus which serious injury criteria were met |
| Malfunction that would likely cause death or serious injury if it recurred | Medical device report to FDA | 30 calendar days from becoming aware | Malfunction analysis and the recurrence assessment |
| Reportable event that needs remedial action to prevent an unreasonable risk of substantial harm | 5-day report | 5 work days from becoming aware | The remedial action decision and any linked correction or removal record |
| Event type covered by a written FDA request | 5-day reports for those events | 5 work days, for the period FDA names | The request, its period and every report filed under it |
| New information after a report was filed | Supplemental report | 30 calendar days from receiving it | Report version history and what changed |
| Complaint with no possible adverse event | No medical device report | None | Complaint record, investigation or the reason none was needed, and the not-reportable decision |
A correction or removal started to reduce a risk to health also needs its own report to FDA within 10 working days under 21 CFR 806.10, so the remedial action screen links to that record.
Complaint lifecycle
How does a complaint move from intake to report?
Six stages, each with an owner and a record. The aware date travels with the complaint from the first one.
Triage
- AI suggests category and problem codes
- Possible injury words raise priority
- Similar complaints grouped
- A person confirms every suggestion
Investigation
- Device history, lot and UDI
- Returned device analysis
- Link to an earlier similar investigation
- Findings recorded with the investigator
Decision
- Reportability screen from the decision table
- Reasoning required for both outcomes
- Clock shown against the aware date
Submission
- eMDR prepared from Form FDA 3500A content
- Sent through FDA's electronic gateway
- Acknowledgments stored
- Supplemental reports versioned
File and hand-off
- MDR event file kept for its retention period
- CAPA link to your QMS
- Complaint data shared for trending
AI triage limits
Where does AI help, and where does a person decide?
AI driven insights for medical device complaint handling are useful for sorting and grouping. They never decide whether a complaint is reportable.
01
Suggest
Example: Sort a free-text complaint into categories and problem codes
Approach: AI proposes; the complaint handler accepts or edits, and both versions are stored
02
Group
Example: Find similar complaints across lots, sites and channels
Approach: AI groups; a quality engineer confirms before a group is used to skip a repeat investigation
03
Flag
Example: Spot words that suggest injury or death in a long narrative
Approach: A flag can only raise priority, never lower it, and trained staff still read the complaint
04
Draft
Example: Draft the event narrative for the report
Approach: A regulatory specialist edits and approves every word before submission
05
Never
Example: Decide reportable or not reportable, or close a complaint
Approach: People only, with their reasoning recorded in the MDR event file
SaMD complaints
What changes when the device is software?
Optimizing SaMD complaint handling means catching complaints that never arrive as a returned device.
- Complaints arrive as app store reviews, support tickets and social posts, so each channel feeds intake
- A defect found by your own testing is a bug; a user's report that the software failed is a complaint, and the software keeps the two apart
- Software version and build stand in for the lot, and are recorded with the UDI where the product has one
- Logs and telemetry from the user's session are attached to the investigation instead of a returned unit
- Security vulnerabilities reported by researchers go to both the complaint and the vulnerability process
- A fix shipped in an update is linked to the complaints it answers
What do we build into complaint handling software?
Modules we scope one by one, so a first release can cover one product line and still meet every rule that applies to it.
Multichannel intake
Forms for call center, field and web complaints with the QMSR record fields enforced, plus connectors for support and app store channels.
Aware-date clocks
Every complaint carries its aware date, and the 30-day and 5-day clocks show on each screen and in daily alerts.
Investigation workspace
Device history, lot and UDI lookup, returned device analysis, attachments and a link to earlier investigations of similar complaints.
Reportability decision form
Questions built from the decision table, a required reasoning field and the name and time of the person who decided.
eMDR preparation and submission
Report content assembled from the complaint record, submitted electronically, with acknowledgments and supplemental reports tracked.
AI triage assistant
Category suggestions, injury flags and similar-complaint groups, each confirmed by a person and logged.
MDR event files
Deliberations, reports and acknowledgments kept together for each event and retained for the required period.
CAPA and trending hand-off
Each complaint links to corrective action and trend analysis in your quality management system.
Compliance-First Healthcare App Development Services Backed by Global Standards
01
HIPAA
Health Insurance Portability and Accountability Act
Protect PHI with privacy-first architecture, encrypted storage and transmission, strict access controls, and traceable audit logs.
02
GDPR
General Data Protection Regulation
Implement lawful consent flows, data minimization, retention controls, and secure processing for sensitive health data.
03
FHIR
Fast Healthcare Interoperability Resources
Enable standardized health data exchange across apps, care teams, and systems through standards-based FHIR APIs.
04
HL7
Health Level Seven International
Support enterprise-grade interoperability with HL7-based integrations for records, events, and clinical messaging workflows.
05
HITRUST
Health Information Trust Alliance
Align security programs to healthcare-specific control and risk management practices trusted by providers and ecosystem partners.
06
HITECH
Health Information Technology for Economic and Clinical Health Act
Design with breach notification readiness, digital record safeguards, and operational controls that support regulated care programs.
07
SaMD
FDA Software as a Medical Device
Plan software quality, traceability, and documentation pathways for products that may require SaMD review and submission.
08
MDR (EU)
Medical Device Regulation (European Union)
Prepare EU market-ready processes for risk classification, evidence tracking, and lifecycle governance under MDR expectations.
09
SAMHSA
Substance Abuse and Mental Health Services Administration
Apply confidentiality controls and consent-aware sharing models for behavioral and mental health data experiences.
Standards and rules
Rules complaint handling software is built to
The regulations and standards behind the decision table and the complaint record.
21 CFR Part 80321 CFR Part 820ISO 13485:2016 8.2.221 CFR 80621 CFR Part 11IEC 62304
Facts and sources
Facts behind complaint handling software
Rules the reportability screen and complaint record are built from, each linked to its primary source.
A device manufacturer must report to FDA no later than 30 calendar days after becoming aware of information, from any source, that reasonably suggests a device it markets may have caused or contributed to a death or serious injury, or has malfunctioned in a way that would likely cause one if it recurred.
Source: 21 CFR 803.50(a) (eCFR)A manufacturer must submit a 5-day report no later than 5 work days after becoming aware that a reportable event needs remedial action to prevent an unreasonable risk of substantial harm to public health, or after FDA asks for one in writing.
Source: 21 CFR 803.53 (eCFR)Manufacturers and importers must submit initial, supplemental and follow-up medical device reports to FDA in an electronic format that FDA can process, review and archive.
Source: 21 CFR 803.12(a) (eCFR)MDR event files must hold the documentation of the deliberations and decision-making used to decide whether an event was reportable, and a manufacturer keeps each file for 2 years from the event or the expected life of the device, whichever is greater.
Source: 21 CFR 803.18(b) and (c) (eCFR)Under the Quality Management System Regulation, complaint records for reportable or investigated complaints must include the device name, date received, any UDI or UPC, the complainant's contact details, the nature of the complaint, any correction or corrective action, and any reply to the complainant.
Source: 21 CFR 820.35(a) (eCFR)
Who it is for
Who do we build complaint handling software for?
Teams that need complaint handling built around their products and channels.
Device makers leaving spreadsheets
Complaints, investigations and reports moved from shared files into one system with clocks.
SaMD companies
Intake from app stores and support tools, with software version and telemetry attached to each complaint.
Growth-stage device startups
A complaint process ready before the first commercial launch, sized for a small quality team.
Importers
Complaint intake and report routing for importers, who carry their own reporting duties.
Teams adding AI triage
Category and grouping suggestions added to an existing complaint system, with people confirming each one.
Scope and cost
What drives the cost of complaint handling software?
We do not publish prices. These are the things that change the size of a build, and we price them on the scoping call.
Intake channels
Call center, field service, web, email, support tools and app stores each add a connector and tests.
Product range
How many device families, and whether software products sit beside hardware.
Connected systems
Your QMS, ERP for lot and UDI data, CRM and service systems.
Report volume
How many reports you file, which shapes how much of the eMDR preparation is automated.
AI triage
Whether AI suggestions are in the first release, and the review and testing they need.
Validation
Computer software assurance and Part 11 evidence your quality team needs before go-live.
Engagement
How does a complaint handling engagement work?
Three stages, each with a clear output.
1.
Scoping call
We map your channels, products, current complaint flow and where reports have run close to their clocks.
Scope2.
Fixed-scope first release
Intake, investigation, the reportability decision and the event file for one product line, with validation evidence.
Build3.
Scale and support
More channels, products and AI triage, plus support under your change control procedure.
ScaleFrequently Asked Questions
No. AI can suggest categories, flag possible injuries and group similar complaints, but a trained person makes and records every reportability decision. A flag can raise a complaint's priority; it can never lower it.
A complaint is any allegation that a device failed to meet its specifications. A medical device report is what you file with FDA when a complaint, or any other information, suggests a reportable death, serious injury or malfunction.
Every complaint records the date your company first became aware of it. Each report's deadline is calculated from that date, shown on every screen and sent in daily alerts until the report is filed or the complaint is judged not reportable.
Yes. It assembles the report content from the complaint record, submits it electronically and stores FDA's acknowledgments. Supplemental reports are versioned against the original.
No. It handles complaints and reports and links each complaint to corrective action and trending in your existing QMS. Our quality management system software page covers that side.
SaMD complaint handling adds intake from app stores and support tools, records the software version and build, attaches session logs and keeps internal bug reports apart from user complaints.
We deliver the validation evidence your quality team needs, including requirements, risk-based testing and Part 11 controls for electronic records and signatures. Your quality team approves the release.
It depends on scope; we agree a fixed first release on the scoping call. Validation and the number of connected systems usually shape the timing more than the screens do.