Medical device complaint process flowchart (intake to vigilance report)

Medical device complaint process flowchart template: complaint definition check, safety screen, US and EU vigilance reportability, device return and evaluation, root cause, field action or CAPA, final report and trending.

Use this template

What the medical device complaint process flowchart (intake to vigilance report) process is

A medical device complaint is not a dissatisfied customer. Under ISO 13485 it is any written, electronic or oral communication that alleges a deficiency in the identity, quality, durability, reliability, usability, safety or performance of a device that has left the manufacturer's control, and the process that handles it is a regulated one with clocks attached. The trigger is the moment anyone in the organisation becomes aware of such a communication, whether it arrives through the complaint mailbox, a sales visit, a service call, a distributor, social media or a published case report. The chart below follows one complaint from that moment to a signed-off file: the record opened and acknowledged, the determination that it is a complaint, the safety screen, the reportability assessment and any initial report to a competent authority, the request for the device, its evaluation, the investigation or the justification for not investigating, the field action and CAPA decision, the reply to the complainant, the final report where one is owed, and trending.

This chart is specific to devices and the vigilance obligations that come with them. A generic quality complaint process, and the commercial handling of an unhappy customer, reach the reportability question and stop there. This chart carries the device obligations that come after it: the returned-device evaluation and the rule against altering a unit tied to a serious incident, the recorded justification when a complaint is not investigated, reportability assessed market by market and reassessed once the device has been examined, and the trending duty at the end. Pharmacovigilance is separate again: an adverse event on a medicine is an individual case assessed for seriousness, expectedness and causality, on its own timelines. 'Field action or CAPA needed?' hands a field safety corrective action to the recall process and a systemic fix to the CAPA process; this chart keeps only the complaint file. It is a starting point to be adapted under your own procedures, the regulations of each market you sell into and review by a competent person; it does not make anyone compliant on its own.

Four of the nine decisions carry the process. 'Meets the complaint definition?' sits with the complaint handling unit because that is the team trained on the definition and the one whose rationale an auditor will sample. 'Death, serious injury or malfunction alleged?' is placed in the Quality / investigation lane, before the investigation rather than after it, because the reporting clock runs from awareness and cannot wait for a root cause. 'Reportable to a competent authority?' belongs to Regulatory affairs, who know each market's criteria and deadlines and who submit the report; the chart comes back to them at 'Reportability changed by the findings?' once the device has been examined, because a complaint the screen let through becomes reportable the moment an evaluation confirms a malfunction that could have caused serious harm. 'Field action or CAPA needed?' sits with Management, because committing the company to a field action is not a decision the complaint unit should make alone.

What this flowchart covers

In this template

  • Five swimlanes (Customer / user, Complaint handling unit, Quality / investigation, Regulatory affairs and Management) across six phases: intake, complaint determination, safety and reportability, device evaluation, investigation and CAPA, and close and trend
  • A 'Meets the complaint definition?' decision straight after the record is opened, with the not-a-complaint branch routed into trending rather than dropped, so feedback that fails the definition still counts in the post-market surveillance data
  • A safety screen and reportability assessment ahead of any investigation: 'Death, serious injury or malfunction alleged?' in the Quality / investigation lane, then Regulatory affairs assessing each market and submitting an initial report by the statutory deadline where one applies
  • A written reportability decision on every file, including the ones screened out at the safety question, and a 'Reportability changed by the findings?' decision that sends the file back to the reportability assessment when the evaluation finds a malfunction the screen missed
  • Device evaluation as its own phase: the device and questionnaire requested from the complainant, a 'Device returned for evaluation?' decision with a chase branch back to the request, decontamination, inspection and testing, and a 'Root cause confirmed?' loop for inconclusive evidence
  • A 'Full investigation required?' decision with a documented justification for not investigating, a management-level 'Field action or CAPA needed?' decision with three branches, the reply to the complainant, a 'Report still open with the authority?' check before closure, and trending for signals

When to use this template

  • You are writing or revising the complaint handling procedure for a device quality management system and need the handoffs between intake, quality, regulatory and management on one page
  • A regulatory report has been late or missed because a complaint sat in a sales inbox or a service log before anyone recognised it, and you need the intake and awareness points made explicit
  • An audit or inspection finding says complaints were closed without an investigation or without a recorded reason for not investigating, and the corrective action is a clearer process
  • You are selecting or configuring a complaint management module and want the decisions, records and deadlines agreed before workflow states and fields are built
  • Your organisation is moving from the former US quality system regulation to the QMSR and wants to check that the complaint records it keeps match what the amended rule now asks for

How it works

  1. Rename the lanes to your roles

    Replace Customer / user, Complaint handling unit, Quality / investigation, Regulatory affairs and Management with the roles that actually exist. In a small manufacturer the complaint handling unit and the investigators are often the same two people, and regulatory affairs may be a consultant; merge or rename rather than drawing a handoff nobody makes.

  2. Write your complaint definition onto the first decision

    Copy the definition your procedure uses, list the sources feedback arrives through, and state what happens to a report that fails the definition. Put the words of the definition next to the 'Meets the complaint definition?' decision so the person applying it does not have to remember it, and make recording the rationale for a no part of the step.

  3. Set the reportability criteria and deadlines per market

    For each market you sell into, write the reportable event criteria and the statutory clock next to the 'Reportable to a competent authority?' decision. The deadlines in this template are illustrative of the US and EU rules at the time of writing; verify them against the current regulation for every jurisdiction you report to and note that the clock starts at awareness.

  4. Decide how the returned device is handled

    State who requests the device, what the complaint questionnaire asks, how many attempts the 'Chase again' branch allows before the file records that it was not returned, and how a returned device is quarantined, decontaminated and photographed before anyone tests it. Add the rule that a device tied to a reportable event is not altered until the authority knows what you intend to do.

  5. Write the rule for skipping an investigation

    Define when 'Already covered' is a legitimate answer to 'Full investigation required?': typically an earlier investigation of the same failure mode on the same device family, referenced by number. Say who may make that call, what the justification record must contain and how often a repeated complaint on the same reference forces a fresh investigation anyway.

  6. Fix who decides on field action and CAPA

    Name the management forum or individual behind 'Field action or CAPA needed?', the inputs they see (investigation result, risk file update, complaint history for the reference) and what each branch triggers. A field action always hands off to the recall process and normally raises a CAPA; write the trigger for CAPA on a non-field-action complaint too.

  7. Walk it against three closed complaint files

    Take one complaint that was reported, one that was investigated but not reportable and one closed on a justification, and trace each through the chart. Every step people describe that the chart does not show, and every step the chart shows that the file does not evidence, is a finding to fix before the procedure is issued.

Frequently asked questions

What are the steps in a medical device complaint process?

A complaint record is opened and acknowledged when feedback arrives from any source. The complaint handling unit decides whether it meets the complaint definition; a no is recorded and still trended. Quality screens for a death, serious injury or malfunction; if one is alleged, regulatory affairs assesses reportability per market, submits any report due and records the decision. The device is requested, chased if it does not arrive, then decontaminated, inspected and tested. Quality investigates root cause against the device history record and updates the risk file, looping back when inconclusive, or records why an earlier file covers it. Regulatory affairs asks whether the findings changed reportability. Management decides between field action, CAPA only or neither; the complainant gets the outcome, any open report finalised, the complaint trended and the record closed with sign-off.

What counts as a complaint under ISO 13485, and what is just feedback?

ISO 13485:2016 defines a complaint as a written, electronic or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, usability, safety or performance of a medical device released from the organisation's control, or to a service that affects its performance. The test is the allegation, not the tone or the channel: a nurse's calm remark that a connector is fiddly alleges a usability deficiency and is a complaint; a catalogue request is not. Feedback that fails the definition is still post-market surveillance data, so this chart trends it rather than discarding it. The standard's complaint handling clause expects a documented procedure covering receipt and recording, evaluation, investigation, the decision to report to authorities, handling the returned product and the decision on correction or corrective action, with records throughout.

When must a device complaint be reported to a regulator, and how quickly?

It depends on the market, and the clock starts when the manufacturer becomes aware, not when the investigation concludes. In the US, 21 CFR Part 803 requires a report within 30 calendar days of becoming aware that a device may have caused or contributed to a death or serious injury, or malfunctioned in a way likely to cause or contribute to one if it recurred; events needing remedial action to prevent an unreasonable risk of substantial harm to public health, or designated by FDA, are due within 5 work days. In the EU, Regulation 2017/745 Article 87 requires a serious incident to be reported immediately and no later than 15 days after awareness, 10 days for a death or an unanticipated serious deterioration in health, and 2 days for a serious public health threat. Other jurisdictions set their own rules. File an incomplete report on time and follow it up; a late one is a finding.

Can a complaint be closed without an investigation?

Yes, but only with a written justification. ISO 13485 clause 8.2.2 requires the reason to be documented when a complaint is not investigated, and the FDA's Quality Management System Regulation, in force since 2 February 2026 and incorporating ISO 13485:2016, says the same at 21 CFR 820.35(a): where a similar complaint has already been investigated another is not necessary, provided records document the justification, which should cite the earlier file and confirm the failure mode and device match. The same rule scopes record requirements to complaints reportable under Part 803, complaints you determine must be investigated and any you do investigate: their records must carry the device name, date received, device identifiers, complainant details, the nature and details of the complaint, any correction or corrective action and any reply. Missing information is not a justification.

How is medical device complaint handling different from pharmacovigilance?

Both start with a report of harm and end with a regulator and a corrective decision, but they are organised around different objects. Pharmacovigilance is built around the individual case: a valid case needs an identifiable reporter, patient, product and event, and its seriousness, expectedness and causality set the timeline. Device complaint handling is built around the device and its file: the reportability question is whether the device caused or contributed to a death, serious injury or serious deterioration, or malfunctioned in a way that could, and the investigation is physical, on the returned unit, the device history record and the risk file. Device vigilance also carries a trending obligation: under EU MDR Article 88 a statistically significant increase in non-serious incidents or expected side effects is reportable where it could significantly affect the benefit-risk balance.

Use this template

More in Quality management process templates

More in Process flowchart templates

Browse all Quality management process templates