How Smarteeva Automates IMDRF Code Assignment in Medical Device Complaint Workflows

What IMDRF codes are and how the taxonomy is structured

The International Medical Device Regulators Forum (IMDRF) maintains a globally harmonized coding system for classifying events related to medical devices. The taxonomy is organized into annexes, each covering a different dimension of the event.

Annex A defines device problem codes. These describe what went wrong with the device from a functional perspective: failure to deliver therapy, software malfunction, power supply interruption, material deformation, false alarm, or loss of integrity. The annex contains hundreds of codes organized in a hierarchical structure where broad categories contain specific subcodes.

Annex B defines patient problem codes. These describe the clinical outcome or health impact on the patient: injury, death, insufficient or excessive therapy, unintended exposure, allergic reaction, or no clinical consequence. Patient codes are paired with device codes to create a complete picture of the event.

Annex C defines component type codes that identify which part of the device was involved. Annexes D through G cover investigation conclusion types, investigation methodology, investigation results, and additional descriptors. Together, the seven annexes create a structured vocabulary that regulatory authorities worldwide use to aggregate and analyze device safety data across manufacturers, device types, and jurisdictions.

The codes serve three functions in the post-market surveillance lifecycle. First, they categorize individual complaints for investigation routing and documentation. Second, they drive trend analysis: complaint rates by device problem code over time are the primary signal detection mechanism for identifying emerging safety issues. Third, they are embedded in regulatory submissions. FDA MDRs, EU MIRs, Health Canada CVRs, and PSUR trend analyses all reference IMDRF codes.

Why coding inconsistency is a data integrity problem

The taxonomy is large enough, and the event descriptions are ambiguous enough that two equally qualified specialists will sometimes assign different codes to the same complaint. This is not a training problem. It is a structural challenge inherent to manual classification of unstructured natural language against a complex taxonomy.

A complaint describes a "device that stopped responding to user input during a procedure." The specialist must decide: is the device problem "failure to respond to user interface input" or "device shuts down unexpectedly"? Both are valid Annex A codes. Both could reasonably describe the event. The choice depends on interpretation.

At the individual complaint level, this ambiguity is manageable. At scale, it creates systematic inconsistency. A manufacturer processing 200 complaints per month across three shifts at two facilities will see different coding patterns between teams, between shifts, and between individuals. Some specialists default to broad category codes when unsure. Others select the most specific code available. The variation is not random. It is systematic and it compounds.

The downstream impact is measurable. One Smarteeva customer audited their coding consistency and found a 9% mismatch rate between IMDRF codes on complaint records and the codes on corresponding MDR reports. This meant 1 in 11 regulatory submissions carried a categorization discrepancy. The complaint said one thing. The regulatory report said another.

For trend analysis, inconsistent coding is particularly damaging. A genuine increase in a specific device problem code might not reach statistical significance if 9% of relevant complaints were coded under a different category. Safety signals get diluted. The trend that should have triggered a review at 50 complaints does not surface until 80 complaints accumulate, because 30 of the earlier ones were miscoded.

Notified Bodies and FDA inspectors increasingly compare IMDRF codes across complaint files, regulatory submissions, and PSUR trend data during audits. When the codes do not align, it raises questions about the integrity of the entire classification system. These questions are time-consuming to answer and can result in findings that require corrective action.

What manual IMDRF coding looks like in practice

The typical coding workflow begins after intake. The complaint record exists in the eQMS with an event description. A Quality specialist opens the record, reads the description, opens the IMDRF taxonomy (either in a reference document, a dropdown menu, or a separate tool), navigates through the hierarchical structure to find the most appropriate code, and enters it.

For straightforward events, this takes 5 minutes. For ambiguous events where the device problem spans multiple categories or the patient outcome is unclear, it takes 10 to 15 minutes. At 200 complaints per month, manual coding consumes 16-50 hours of specialist time.

The process is particularly slow when the specialist needs to assign codes across multiple annexes. A single complaint might require a device problem code (Annex A), a patient problem code (Annex B), and a component code (Annex C). Each requires a separate navigation through the taxonomy.

The biggest operational problem with manual coding is that it happens as a separate step after intake. The person who entered the complaint and read the original email or phone transcript is not always the person who assigns the codes. Context is lost between steps. The coder reads a summarized event description rather than the original complaint source, and the summary may have lost the nuance that would have pointed to a more accurate code.

How Smarteeva automates IMDRF code assignment

AI suggestion at the point of intake

Smarteeva suggests IMDRF codes at the moment the complaint record is created. The system reads the event description and proposes codes across the relevant annexes. This happens during intake, not after it, which means the person with the most context about the complaint (the one who read the original source) is the one reviewing and confirming the codes.

The AI considers four inputs: the complaint narrative text, the device type from the device master record, the device's intended use (indications for use), and historical IMDRF assignments on similar complaints within the manufacturer's database. This context-aware approach produces better suggestions than keyword matching because it interprets the event description the way a trained specialist would.

Ranked confidence scores

The system does not suggest a single code. It proposes multiple options ranked by confidence. For a complaint about fluid handling, the top suggestion might be Annex A code A2008 (Fluid Handling, Aspiration) at 94% confidence, with A2003 (Fluid Handling, Dispense) at 31% and A1306 (Sensor, Level Detection) at 18%.

When the top suggestion is at 94% confidence, the specialist confirms and moves on. When the top suggestion is at 55% confidence, the specialist knows to look more carefully. The confidence score is the feature, not the suggestion. It tells the human when to trust the AI and when to apply their own judgment.

Bidirectional sync with regulatory reports

When IMDRF codes are confirmed on a complaint record, they automatically populate the corresponding fields on any linked regulatory report (MDR, MIR, CVR). If a code is subsequently changed on the complaint, the linked report updates. If a code is changed on the regulatory report, the complaint record updates.

This bidirectional sync eliminated the 9% mismatch rate at one customer site. After implementation, the mismatch rate dropped to less than 0.001%. The complaint and the regulatory report always carry the same codes because they reference the same data.

What consistent coding makes possible

When every complaint is coded consistently, capabilities that were previously unreliable become actionable.

Trend analysis surfaces real signals. An increase in a specific Annex A device problem code over the last 90 days is visible and statistically significant when every complaint in that window is coded the same way. Before consistent coding, the same increase might have been masked by miscategorized complaints scattered across adjacent codes.

Cross-product comparisons become valid. Comparing complaint patterns between two device families requires that both are coded using the same methodology. When different teams code differently, the comparison reflects coding style rather than actual safety performance. Automated coding applies the same model to every complaint regardless of team or facility.

Regulatory submissions are defensible. When an auditor reviews PSUR trend data and asks how complaint rates were calculated, the manufacturer can demonstrate that every complaint was coded by the same AI system, reviewed by a human, and synced to the corresponding regulatory report. The methodology is documented, repeatable, and consistent across reporting periods.

IMDRF code assignment at the point of intake also accelerates the compliance timeline. When codes are assigned during intake rather than as a separate downstream step, the reportability assessment (which references IMDRF codes) happens faster, the MDR form (which includes IMDRF codes) is populated faster, and the complaint is ready for investigation sooner. Every downstream process benefits from having the codes established at the earliest possible moment.

Smarteeva's IMDRF automation is part of the post-market surveillance suite. Teams already using the platform for complaint intake, adverse events, or regulatory reporting can activate IMDRF code suggestion without a separate implementation. The IMDRF tool page at smarteeva.com/tools provides a public reference for exploring the coding taxonomy.

‍