Customer complaints for medical devices

During a navigated spine surgery, the first screw slipped to the side.

The surgeon completed the procedure using alternative navigation and intraoperative O-arm imaging, and the surgery was delayed by more than 30 minutes.

No patient injury was reported, and yet the manufacturer reported the event to the FDA as a malfunction.

I have seen many companies that never defined what counts as a complaint for them, and in those companies a contact like this one stays a service call.

Often this comes from avoiding looking the complaint in the eye, for example when nobody wants to deal with a known problem in the device that would require a redesign.

In this article I will walk through the complaint handling process, from the first contact all the way to the risk management file.

Let's start with the first question: is the report about the slipped screw a complaint?

How to define a complaint

ISO 13485 defines a complaint in clause 3.4 as a written, electronic or oral communication that alleges deficiencies related to the identity, quality, durability, reliability, usability, safety or performance of a device that has been released from the organization's control, or of a service that affects its performance. The FDA has also referred to this definition since the QMSR took effect on February 2, 2026. The channel does not matter: a phone call from a technician or a message from a distributor is a complaint just as much as a formal letter.

The standard's definition is general, so what the company needs is a definition that fits its own device, meaning which allegations count as a deficiency.

Four sources help you build it:

  • Knowing the device. What counts as a deficiency in performance, usability, software, packaging and labeling.

  • The risk analysis. Every hazardous situation identified in it is a type of contact that should be logged as a complaint, because the analysis has already established what can go wrong and what the possible harm is.

  • The IMDRF terminology document for adverse event reporting, N43. It is a catalog of device problem types, components and cause investigation. You go through it and mark what is relevant to your device, and that way your complaint coding also matches the European reporting form from the start.

  • The MAUDE database. Search it for problems reported on competitors and on similar devices, and use it as inspiration for failure types you had not thought of. It is good for ideas, not for calculating event rates, because the reporting in it is incomplete.

The detailed definition is what separates a complaint from a service call.

A service call is a request for maintenance, repair, training or support, with no allegation of a deficiency.

When a call contains an allegation of a deficiency of the type you defined, such as an accuracy deviation, it is a complaint even if it was opened in the service system.

Clause 7.5.4 requires you to analyze service records to decide whether they contain a complaint.

The decision on whether a contact is a complaint is recorded even when the answer is no, and the rationale is kept. Under ISO 13485, this evaluation is separate from the investigation.

Contact

Classification

Explanation

"How do I swap an instrument in the interface?"

Service call

A support request with no allegation of a deficiency. If it keeps coming up, it is worth looking at usability.

"We need to schedule the annual calibration"

Service call

Planned maintenance.

"The navigation showed a position that was off by a few millimeters"

Complaint

An allegation of a performance deficiency, even if it was opened as a service call.

"The invoice doesn't match the order"

Not a complaint

Commercial feedback unrelated to the device's performance.

Two cases from MAUDE

To illustrate, I chose two reports from the FDA's MAUDE database on surgical navigation systems. Each report is what the manufacturer sent to the FDA after handling the complaint, so the original contact is not visible in it, and the conclusions in the table are the manufacturers' conclusions as reported.

Complaint A: cranial navigation

Complaint B: spinal navigation

What happened

During a biopsy, the needle path deviated by about 7 to 10 mm from the planned trajectory. There was minor bleeding that did not require intervention.

During spine surgery, while the first screw was being placed, the screw slipped toward the midline, with the registration block clamped on S1.

The other screws in the block were accurate. The surgeon completed the procedure using alternative navigation and intraoperative O-arm imaging, and there was a delay of more than 30 minutes. No patient injury was reported.

Event date

May 6, 2021

May 9, 2025

Date the manufacturer received the information

May 11, 2021

May 9, 2025

Date submitted to the FDA

June 7, 2021

June 6, 2025

Report type

Serious injury, 30-day report

Malfunction, 30-day report

Cause according to the manufacturer

Incorrect registration of the patient to the system: scanning that did not follow the protocol, and registration points in non-recommended locations. Faulty hardware may have contributed. No systemic malfunction was found.

Not published. The device was not available for evaluation.

Look at Complaint A. The cause was incorrect use by the user, and yet the manufacturer classified it as a serious injury, because a risk to the patient's health could not be ruled out.

A complaint caused by the user can still be a reportable complaint.

Before you go on, a few questions to think about:

  • What do you think was not done well in each of the cases?

  • What should have happened to prevent the event, or to detect it earlier?

  • Would you report it, and within what time frame?

The answers are further down in the article.

Dates: the awareness date is not the date the complaint was opened

In the US there is a concept called the aware date, the date of awareness. It is not the event date, and it is not the date the complaint was opened either.

The FDA considers the manufacturer to have become aware of an event when any of its employees becomes aware of it, and the 30 days are counted from that point. That is why the complaint form needs to track several dates separately:

  • Event date: when the incident happened.

  • Awareness date: when the organization, meaning any employee, became aware of the event. A sales representative who heard about the case while visiting a customer counts as awareness.

  • Complaint opening date: when it was logged in the system. This date can be later than the awareness date.

  • Awareness date for reportability: when it became known that the event is reportable. In the European MIR form this is a separate field.

  • Reporting dates: the due date, the initial submission and any follow-ups.

In Complaint A, the event happened on May 6 and the information reached the manufacturer on May 11. The report was submitted on June 7, which is 27 days after the information was received and 32 days after the event.

Had the count started from the event, the report would have exceeded the 30 days. In Complaint B, the event and the receipt of the information fell on the same day, May 9, and the report was submitted after 28 days.

What the standard requires

Clause 8.2.2 of ISO 13485 states that the organization shall document a procedure for timely complaint handling in accordance with applicable regulatory requirements.

The procedure covers at least six points: receiving and recording the information, evaluating whether the contact is a complaint, investigation, determining whether it must be reported to the authorities, handling of the product related to the complaint, and deciding whether a correction or corrective action is needed.

Alongside these six points, the standard requires a few more things:

  • A complaint that is not investigated requires a written justification.

  • Any correction or corrective action resulting from the complaint is documented.

  • If the investigation shows that an external party contributed to the complaint, such as a supplier, a distributor or any kind of representative, you pass the relevant information on to them and get information back. This is usually set out in a contract or a quality agreement.

  • Records of complaint handling and of any reporting are kept in line with the procedure for control of quality records.

ISO's practical guide adds clarifications that help with implementation:

  • The evaluation takes place in three separate steps: whether it is a complaint, whether it needs to be investigated, and whether it is an event that must be reported under clause 8.2.3.

  • You need to appoint a person responsible for collecting all complaints, with the authority to send any complaint involving injury, death or a hazard for review immediately.

  • When information is missing, you need to show a reasonable effort to obtain it. One phone call to a hospital is not a reasonable effort, while three attempts at different times over several days is. The effort is scaled to the level of risk.

  • A device that meets its specification can still cause a problem in use. In that case the problem may lie in the design output or in the instructions for use. Complaint A is an example of this: according to the manufacturer, the cause was use that did not follow the instructions.

Clause 8.2.3 requires a procedure for reporting to the authorities and for keeping reporting records. Clause 8.5.2 requires you to review nonconformities, including all complaints, and to evaluate whether action is needed to prevent recurrence, in proportion to the severity of the finding. Clause 7.5.4 requires you to analyze service records to decide whether they contain a complaint.

According to clause 8.2.2 of ISO's practical guide, an investigation record includes the device name, the date received, the UDI or control number, the complainant's details and the nature of the complaint. It also includes a summary of the investigation (review of production records, manufacturing nonconformities, examination of the returned product and review of changes that were introduced), the results, the corrections and the corrective action or the rationale for taking no action, the investigation dates and the names of the investigators, any report made to the authorities, and the reply to the complainant. The record can contain personal health information, so the procedure also needs to define how it is stored.

The regulatory requirements

US: the QMSR and Part 803

Complaint handling under the QMSR is based on clause 8.2.2 of ISO 13485, and 21 CFR 820.35(a) adds record requirements. This section applies to complaints about the possibility that a device, its labeling or its packaging does not meet specifications. If a similar complaint has already been investigated, there is no need to investigate again, but the rationale is recorded.

For a complaint that must be reported, a complaint the company decided to investigate, and a complaint that was investigated even without an obligation, the record includes the device name, the date received, the UDI or other identification code, the complainant's name, address and phone number, the nature of the complaint, any correction or corrective action taken, and any reply sent to the complainant.

Reporting to the FDA is governed by Part 803. A manufacturer reports within 30 calendar days of becoming aware of a death, a serious injury or a reportable malfunction, and within 5 work days when action is needed to prevent an unreasonable risk of substantial harm to the public health, or when the FDA has requested a written report. A report is required when the information reasonably suggests that the device may have caused or contributed to a death or serious injury, or that a malfunction of the device would be likely to cause or contribute to one if it recurred. The need for action can also emerge from trend analysis. Corrections and removals intended to reduce a risk to health are reported separately, under Part 806.

Europe: the MDR and MDCG documents

Article 2 of the MDR defines an incident and a serious incident. A serious incident is an incident that directly or indirectly led, might have led or might lead to death, a temporary or permanent serious deterioration in a person's state of health, or a serious public health threat. The manufacturer reports it to the competent authority of the country where the incident occurred, under Article 87. The deadlines are counted from the moment the manufacturer became aware: 15 days by default, 10 days for a death or an unanticipated serious deterioration in health, and 2 days for a serious public health threat.

Article 88 requires trend reporting when there is a statistically significant increase in the frequency or severity of incidents that are not serious, or of expected undesirable side effects, that could affect the benefit-risk analysis. Article 89 requires investigation of a serious incident, and a field safety corrective action where needed. Importers and distributors must forward complaints about suspected incidents to the manufacturer immediately and keep a register of complaints, under Articles 13 and 14, so it is worth defining in your distributor agreement how much time they have to pass a contact on.

The interpretation of the terms appears in the questions and answers document MDCG 2023-3, and the MDCG 2024-1 documents set out the expectations for specific device types.

A serious incident report is submitted on the MIR form. Version 7.3.1 is mandatory from May 1, 2026, after the original date of November 2025 was postponed because of problems with the form. The form allows an initial report, a follow-up report, a final report and a combined report. In Europe, the IMDRF device problem codes are mandatory, and they are updated every year, usually in March.

Topic

US

Europe

What is reported

Death, serious injury, or a malfunction that could cause them if it recurred

Serious incident: death, serious deterioration in health, or a public health threat

Deadline

30 calendar days, or 5 work days when action is needed for an unreasonable risk

15 days; 10 days for a death or an unanticipated serious deterioration; 2 days for a serious threat

Form

FDA Form 3500A

MIR form version 7.3.1

Trends

The need for action can emerge from trend analysis

Separate trend report under Article 88

Field action

Correction and removal under Part 806

Field safety corrective action (FSCA) under Article 89

Deciding whether to report

In Complaint A, the answer to the first question is yes, because a risk to the patient's health cannot be ruled out, even though the cause was incorrect use, and so you report. In Complaint B, the answer to the first question is no and the answer to the second is yes: it is a navigation malfunction that could cause injury if it recurred, and so you report.

In both cases, the deadline is counted from the day the information reached the company.

How to handle a complaint

  1. Receiving and recording. Every contact is recorded, from every channel: service, sales, a distributor, a representative or a field technician. Record the device, the serial number or UDI, the complainant's details and what the complainant alleged, with each of the dates in its own field. It is a good idea to state in the procedure that every employee passes a contact on to the complaint owner within the same working day.

  2. Initial evaluation. Decide whether it is a complaint, and record the decision even when it is no. If information is missing, try to obtain it and document the effort.

  3. Immediate reportability check. Go through the two questions in the decision tree, even before the investigation has started. The clock starts at awareness, not at the end of the investigation, and if the answer could be yes, you report and add information in a follow-up report.

  4. Deciding whether to investigate. The default is to investigate. You may skip an investigation only with a written justification, for example when a similar complaint has already been investigated, in which case you refer to it.

  5. Investigation. Review production records, nonconformities, the returned product and changes that were introduced, and examine whether the device met its specification. Look at data from other sources as well: previous complaints, returns, service reports and audits.

  6. Handling the product related to the complaint. Segregate it from good stock, label it, and decontaminate it before examination when there is a risk of contamination, as with a product returned from an operating room.

  7. Closure and reply. Document the correction, the corrective action or the rationale for taking no action, send a reply to the complainant, and feed the complaint into the trend analysis.

The table shows what needs to be done at each stage for the two complaints.

Stage

Complaint A

Complaint B

Reportability

Yes. A risk to the patient's health cannot be ruled out, so you report.

The deadline is counted from the day the information reached the company.

Yes. It is a malfunction that could cause injury if it recurred, so you report.

Investigation

Check the scan, the registration points and the hardware.

The device is available, so it can be examined.

The device is not available.

Ask the site for system logs and a description of the registration and clamping steps.

Related product

Take the faulty hardware out of use until it is examined.

The device remains at the site.

Ask the site to keep it as it is until it is clear what happened.

Closure

Reply to the customer, repeat the scanning and registration instructions, and pass it on for a decision on corrective action.

No closure before the cause is known.

The complaint stays open and goes on to an escalation decision.

When to open a corrective action and when not to

Not every complaint justifies a corrective action.

Clause 8.5.2 of ISO 13485 requires you to evaluate whether action is needed to prevent recurrence, and requires the action to be proportionate to the effects of the nonconformity.

The document GHTF/SG3/N18:2010, prepared in 2010 by the GHTF, the body that preceded the IMDRF, explains how to decide:

The manufacturer determines the significance of the nonconformity, the risk associated with it and the likelihood that it will recur, and one of four outcomes follows from that.

Scenario

Decision

When it fits

A

No correction and no escalation

The risk is low, the event is isolated, the cause is known, and there is no reason to expect it to recur.

B

Correction only

The specific item or site needs to be dealt with, and the cause is local and not expected to recur.

C

Correction and escalation to corrective action

The item needs to be dealt with, and the cause may be systemic or the risk is high, so it could recur elsewhere as well.

D

Escalation without correction

There is not yet enough information to make a correction, and the potential severity justifies investigating before deciding.

For our two complaints, this is what I would do.

Please note that this is my recommendation based on what was published in the reports.

Complaint

Scenario

What needs to be done

A

C

Correction: take the faulty hardware out of use and go over the scanning and registration instructions with the customer again. Escalation to corrective action, because the cause does not stop at one site. Faulty hardware after incorrect handling may also be found at other customers, and a user who approved a registration with a deviation shows that the control measure depends on the user's judgment. The action includes checking the hardware across the installed base, reviewing the instructions for use and the interface, and updating the risk management file.

B

D

There is nothing to correct yet, because the cause is unknown. Escalate to investigation: obtain system logs and a description of the registration and clamping steps, and look for similar complaints from other systems and sites.

If the investigation finds that the problem lies in the clamping of the registration block, or similar complaints appear at other sites, move to scenario C.

A few principles from the document help with the decision:

  • The escalation criteria are set in advance and appear in the procedure. An event that alleges death or serious injury goes straight to investigation and action.

  • When complaints are handled within their own process without escalation, you need trend analysis to identify when an accumulation justifies action.

  • Horizontal analysis looks at the complaint against other sources of information: returns, service reports, nonconformities, audits and customer surveys. An accumulation across sources can justify action even when no single source has crossed the threshold on its own.

  • A correction deals with the defective item, and a corrective action deals with the cause. When the cause is systemic, updating a procedure and training alone are not always enough.

Once a corrective action has been decided on, the document defines three more things:

  • Verification of the action before implementation, including a check of whether it creates new risks,

  • An effectiveness criterion set in advance, with a data source and a time frame,

  • And a return to the investigation stage if the action is not effective.

When to go back to the risk analysis

The risk management file is built before the device goes to market, and complaints are the first source of information about what happens in actual use.

According to ISO's practical guide, complaints should be reviewed as input for updating risk management activities, and the documents should be updated in a timely way.

Three situations require going back to the file:

  • A new hazard or failure mode. The complaint reveals something that did not appear in the analysis.

  • A frequency different from the estimate. The complaint rate for a hazardous situation is higher than the probability set in the file. In the risk management table, you rate the probability that the hazardous situation will occur (P1) and the probability that it will lead to harm (P2), and the complaint data shows whether these ratings are still appropriate.

  • A different severity. The complaint shows more serious harm than was estimated.

The guide adds that even when a new hazard does not exceed the organization's acceptance criteria, updating and tracking it matter, because that is how a trend is built.

Answers to the questions from the beginning of the article

Do you remember the questions I asked you at the beginning of the article?

  • What do you think was not done well in each of the cases?

  • What should have happened to prevent the event, or to detect it earlier?

  • Would you report it, and within what time frame?

Please note that these answers are a professional opinion based on the reports, not what the manufacturers actually did.

What was not done well

What should have happened

Complaint A

The scan did not follow the manufacturer's protocol, and the registration points were taken in non-recommended areas. The user saw a deviation of up to 5 mm in the registration check and approved it anyway, and no adequate accuracy verification was performed after registration and during the biopsy. Faulty hardware remained in use at the customer.

Control measures that do not rely only on the user's judgment: a defined deviation threshold beyond which the procedure must not continue, accuracy verification before every invasive step, periodic checks of the hardware, and refresher training. In the risk management file, check whether the probability that a user will accept an inaccurate registration is estimated in line with what happened.

Complaint B

The failure appeared only in the first screw, with the registration block clamped on S1, and the other screws were accurate. In my opinion this points to the registration or to the clamping at that point. The report does not mention an accuracy verification before the first screw.

Ask the site for system logs and a description of the registration and clamping steps, even without the device. In the risk management file, check whether registration shift during clamping of the block appears as a hazardous situation, and whether accuracy verification before the first screw and switching to an alternative system are defined as control measures or as instructions to the user.

If the investigation finds that the problem lies in the clamping of the registration block, or similar complaints appear at other sites, move on to corrective action.

The opposite direction matters too. In the action verification stage, the GHTF document includes a question about whether the action creates new risks, so a corrective action is also checked against the risk management file. When the residual risk is no longer acceptable, a corrective action within the process is not enough, and you need to consider a field safety corrective action in Europe (FSCA) or a correction and removal in the US (C&R). The findings also feed into the post-market surveillance plan and the management review.

In closing

When the company has defined in advance what counts as a complaint, and records the event date, the awareness date and the decision on whether to report separately, you can explain to a notified body auditor or to an FDA investigator what was done with each complaint and why.

A gift for newsletter subscribers: a complaint form in Word that tracks all the dates and includes a calculator for FDA and EU reporting deadlines, IMDRF codes to choose from and a reporting decision tree. The form is in English and works in the desktop version of Word.