Risk management file tie into complaint handling system

At my company, when a complaint comes in it gets coded against a risk ID in our hazard traceability matrix. The complaints are then trended using that risk ID as a descriptor. There are at least two situations when I struggle with this method. First, is when a complaint comes in for a patient who has a sign (e.g., swelling) or a symptom (e.g., pain) near the device but no diagnosis on the cause reported. Second, is when a complaint comes in for an observation made during a surgery or a follow up visit but there is no immediate harm to report (i.e., patient is asymptomatic). In both of these cases I struggle with having to pick just one risk ID. In the first case, the symptom (i.e., harm) could be caused by a variety of hazardous situations and by an even greater number of initiating events/circumstances. In the second case, what the complainant observed could lead to a variety of hazardous situations and subsequent harms. I would be inclined to list all risk IDs to show that our company has considered that the symptom/harm could be caused by a variety of reasons leading to variety of hazardous situations and, in the second case, that risks associated with that observation have been considered in the risk analysis. This of course means it does not fit in a nice bucket for complaint trending and our quality group exactly excited about that since it complicates trending (i.e., what do they list on the X-axis of a Pareto chart for example).

The other issue, and this is more about the complaint trending, is that there is no consistency in how a complaint might be described. For example, sometimes the compliant is described by the harm (especially when only a symptom is reported), sometimes by the hazardous situation, or the event/circumstance (especially when there is no hazardous situation or harm reported).

Any thoughts on or solutions to my predicament?

This is where you need to investigate to fill the gaps. Then hopefully you will be able to link specific hazardous situations.

I am writing this post as a Heathcare Services Management professional, not as a quality guy.
It's great to see how much you care about risks. In many cases, doing our best is the acceptable solution. It seems to me that you are talking about MD post-market surveillance. Although it's more about RA, it's obviously also under the accountability of QMS. In both situations described, you may opt to assign only one case ID to each event, with a description (as detailed as possible/with supporting docs/images etc.). Once case may have multiple risks. In risk management, we need to evaluate the significance of risks and any possible causes & effects. Sometimes, healthcare professionals need to be involved. IMHO, you may want to standardize your risks using relevant codes/key words in the ICD-10-CM (International Classification of Diseases, 10th Revision, Clinical Modification) coding system. That would somehow facilitate your reporting.
If the description of complaints lack consistency, a potential remedy is to implement a standardized reporting form. Regardless, ensure customers have a designated space for unrestricted editing to gather maximum information.

What is the purpose of trending? When you understand and accept that you won’t struggle with this categorization - QA has to accept it too.
Trending of data is not a precise specific science. The data in almost all databases is inherently inaccurate to some degree. I always say that as long as you are about 80% accurate you’re able to properly trend and prioritize Problems for resolution (and reporting) as long as you use SPC.
In my long history of this I’ve used miscellaneous or ‘unknown’ as a category for trending and that can go in your Pareto. If Misc. gets to be the largest category then you knwow you have to investigate. Remember (and accept) that data trending and mining will rarely point you to any cause or solution - it is there to point you to the most important problems to solve. In other words save your energy for solving problems and not in quantifying them, tracking them and fretting about them.

I can't speak for the OP, but one of the purposes of "trending" complaints (in the medical device industry) is as an input to periodic risk reviews. the trending is a relatively easy/straightforward way to do the following:

• It can be a sort of no-brainer, order-of-magnitude, check of (occurrence ratings in) the risk file
• A check to make sure the risk files aren't missing consideration of things that are occurring in the field (in the post-market era)

The trending during complaint handling doesn't have to be super precise, but it can help (the periodic risk review process) if there are efforts made to categorize and trend complaints contemporaneously.

To me this is a measurement system error.

Are you looking for trends or shifts in trends? If so, forcing each event into a bucket with unresolved uncertainty isn't a necessary step.
Are you trying to assess rates against trigger levels or performance limits? Incomplete data analysis techniques such as assigning a % of indeterminate events to their potential buckets. (i.e. 30% of our swelling events are due to X and 70% are due to Y, so if we have 10 swelling events with unknown cause we will assign 3 to cause X and 7 to cause Y.)

Also its not clear how force assigning hazards is helpful in post-market monitoring. Assigning harms is certainly helpful and necessary in a robust post-market risk management system so if you aren't doing that, I'd recommend changing tracking of hazards to tracking of harms. Additionally assigning and trending of failure modes is very helpful to understand the quality of the product and provide feedback to the engineering teams.

To me hazards are just along for the ride. While interesting, its not terribly meaningful or helpful in assuring safety (harm monitoring) and quality (failure mode monitoring). If the hazard is due to a malfunction that should be fairly obvious and thus your FM monitoring will give you visibility to it. If there is no malfunction and the issue is due to an inherent risk associated with the product/procedure those can be assessed by looking at harms. If your non-malfunction harms are misbehaving then you'll want to understand what the specific hazards leading to the harms are to understand if you've missed a hazard or misjudged the incidence of harm given the inherent hazardous situation.

Lastly, how does the existing methodology allow for identifying new hazards or failure modes. The described method will never allow an unexpected hazard to get identified without an 'other' or 'unknown' bucket? If I blindly follow the forced assignment, I'll never have signal that there may have been an unanticipated hazard. If you see your 'other' bucket grow or is where a significant number of events get assigned, it may be a signal you need to refine your categories or learn more about the product.