Our PROMISE: Our ads will never cover up content.
Our children thank you.
Jon Speer
Published: Tuesday, January 30, 2018 - 13:02 Complaint handling continues to be one of the biggest reasons medical device companies receive 438s and warning letters from the U.S. Food and Drug Administration (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 often some confusion, too: How exactly do you integrate complaint handling and your risk management procedures? Any complaint handling happens after your device has been launched into 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 lead, or could have led, to serious injury or death, then the FDA’s Medical Device Reporting (MDR) regulation kicks in, and the complaint becomes a reportable event. When ISO 13485 first hit the scene in 1993, the standard talked about feedback rather than complaints. The focus was all about soliciting feedback and being proactive in how you approach post-market surveillance. More recently, ISO 13485:2016 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, analyzing, and taking action on risk matters once the device has hit the market. Your risk assessment might even affect major inputs for the device. You want feedback when you’ve launched your product. The feedback 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. We’ll also assume 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, someone on 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 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 complete product life cycle document. (If you’ve assessed risk too high or too low, either is a cause to update 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 the report needs to be a living document. You will learn new things all the time during a product’s life cycle. 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 corrective and preventive action (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, 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 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, such as nonconformances 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, e.g., hard drives, file cabinets, or 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 the different parts related to it. Using 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 fragmented data across different systems and locations. You are able to see the big picture in real time and ensure you’re not missing anything critical. It also means that stakeholders can access up-to-date information at any time and from any location. 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 affects 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 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. First published on the greenlight guru blog. Quality Digest does not charge readers for its content. We believe that industry news is important for you to do your job, and Quality Digest supports businesses of all types. However, someone has to pay for this content. And that’s where advertising comes in. Most people consider ads a nuisance, but they do serve a useful function besides allowing media companies to stay afloat. They keep you aware of new products and services relevant to your industry. All ads in Quality Digest apply directly to products and services that most of our readers need. You won’t see automobile or health supplement ads. So please consider turning off your ad blocker for our site. Thanks, Jon Speer is the founder and vice president of quality assurance and regulatory affairs at Greenlight Guru, a software company that produces the only medical device quality management software solution. Device makers in more than 50 countries use Greenlight Guru to get safer products to market faster. Speer has served more than 20 years in the medical device industry and helped dozens of devices get to market. As a thought leader and speaker, he regularly contributes to numerous industry publications. He is also the host of Global Medical Device Podcast. How to Integrate Complaint Handling and Risk Management
Let technology help
Complaint handling overview
Complaints and risk management
Why use medical device QMS software?
Final thoughts
Our PROMISE: Quality Digest only displays static ads that never overlay or cover up content. They never get in your way. They are there for you to read, or not.
Quality Digest Discuss
About The Author
Jon Speer
© 2023 Quality Digest. Copyright on content held by Quality Digest or by individual authors. Contact Quality Digest for reprint information.
“Quality Digest" is a trademark owned by Quality Circle Institute, Inc.