Did you know that complaint handling continues to be a big reason medical device companies receive 438's and warning letters from the FDA?
Companies have a lot going on once a medical device has reached the market and it can be challenging to keep up with requirements of post-market surveillance and any implications for your risk management.There’s also often some confusion - how exactly do you integrate complaint handling and your risk management procedures?
Let’s take a look:
Free Resource:4 Steps to Gather Accurate Complaint Data. Click here to download this PDF.
Any complaint handling happens after your device has been launched onto the marketplace. As the only quality process you have where you directly interact with the customer, it is a unique task for companies to handle.
Historically, the FDA has focused on ensuring processes and procedures are in place to handle complaints. An extreme case is if the complaint did, or could have lead to serious injury or death, the FDA considers this an MDR - a reportable event.
When ISO 13485 hit the scene, they talked about feedback rather than complaints. Their focus was all about soliciting feedback and being proactive in how you approach post-market surveillance.
More recently with ISO 13485:2016, it talks about complaint handling and is more in sync with FDA regulations, including discussing regulatory reporting. “Customer feedback” is the bigger umbrella under which complaint handling sits.
Complaint handling and risk share a critical relationship - those complaints play a big role in monitoring, analysing and taking action on risk matters once the device has hit the market. Your risk assessment might even impact major inputs for the device.
You want feedback when you’ve launched your product. It might be good, bad or indifferent, but what you do about it and how it relates to risk management is important.
Let’s make an assumption that you’ve done a risk assessment and have a risk management file in place once you’ve launched your product (if any company doesn’t, you need to get The Definitive Guide to ISO 14971 from us here!). We also assume that you’ve estimated probability and severity of possible events that can happen and have all of this documented prior to the product going to market.
Next minute, someone in your team receives a phone call. There is a complaint being made about your device and you need to know a few critical details. What happened? How? Was anyone hurt or injured? Has this happened before? What steps did the user go through for this to happen? You want to understand as much about the event as you can.
You go back to your risk management file - did you think about this scenario when you originally compiled it? Was this a foreseeable set of events? If you did, you now have to determine whether your estimation of the probability and severity of harm was accurate. If it was, maybe it requires no change and you simply record it the complaint and assess whether there is anything else you can do.
If you incorrectly assessed probability and severity, this information means you need to go back and do another assessment. This type of event is potentially a cause for change. You need to update that risk management file and ensure that, as intended, it is a full product lifecycle document. (If you’ve assessed risk too high or too low, either is a cause for an update of the file). You might get executive management, quality, regulatory and engineering involved to update the assessment and align it with what really happened - involve the team or teams relevant to the complaint.
When you first document risk it is based on the information you have at the time, which is another good reason why it needs to be a living document. You will learn new things all the time during a product’s lifecycle. You may even need to create a cross-functional team to make sure the complaint is properly investigated and risk is correctly assessed.
You reassess probability based on new information. If risk is considered to be at an unacceptable level, it may drive you to do more, such as enact a CAPA. Through CAPA, you may even initiate changes to product design as part of your risk reduction and mitigation activities. It might be that the user needs more training (or perhaps changes made to the labeling), or it could involve changes to the product.
Backing up another step, if you didn’t think about this possible scenario beforehand, you need to start at the beginning with a risk assessment. It could fall within a region where you accept the risk level, or, if it’s at an unacceptable risk level according to your criteria, again, it might drive a CAPA and fundamental changes to the product.
When you learn new things in the form of a complaint, it can impact how you design or manufacture the product, depending on your risk assessment. This is where that integration of complaint handling and risk management is important - you need a good, cohesive system to help present you with all of the information you need, when you need it. At the end of the day, the safety and efficacy of the device is always the key goal.
Traceability is an important concept here. Globally speaking, there is a connection between a complaint and all of the products that relate to that complaint. All products have information in the form of design controls and risk management files, as well as quality events that happen like non-conformances or CAPAs.
If all of this is paper-based, it gets very fragmented because a different group tends to own each set of documentation and records. Each group may not have visibility into the files and records that other groups have. If you investigate a complaint in a paper-based world, it can be almost impossible to track things down. You may have different locations across cities, states or countries and documentation kept in different systems - hard drives, file cabinets, someone’s desk drawer.
The aim of investigating the complaint is to get to the bottom of it so that you can ensure it doesn’t happen again. You need to be able to build a full story about the product and find all of the different parts related to it.
Using Greenlight Guru's medical device specific QMS Software makes it much simpler to gather all of the information needed because your complaint handling, risk management and CAPAs are all integrated, rather than chasing fragment data across different systems and locations. You are able to see the real big picture and ensure you’re not missing anything critical. It also means that anyone can access up-to-date information at any time and from any location.
Free Resource:4 Steps to Gather Accurate Complaint Data. Click here to download this PDF.
Complaint handling is a key part of post-market surveillance activities, although unfortunately, many medical device companies have found that the FDA is not pleased with their management of complaints. It’s an area that is responsible for a lot of 483s and warning letters that go out to companies.
Risk management is a critical integration with complaint handling because it impacts your overall approach to ensuring the safety and efficacy of your device. Where a complaint leads to a high risk measure against your criteria, you may find your company initiating CAPA and changing key elements of the device.
Given all of the contributing materials to risk and complaint management, a risk management file should always be kept as a living document and it’s much easier if a cloud-based software is used to store the information. Ensure that, when any complaint comes in, you have all relevant information easily accessible to conduct a proper assessment.
Looking for a quality system designed specifically to align with medical device processes out-of-the-box that integrates your complaint handling, risk management, CAPAs, training and more? Get your free demo of Greenlight Guru Quality now ➔
Etienne Nichols is the Head of Industry Insights & Education at Greenlight Guru. As a Mechanical Engineer and Medical Device Guru, he specializes in simplifying complex ideas, teaching system integration, and connecting industry leaders. While hosting the Global Medical Device Podcast, Etienne has led over 200...