How Smarteeva Connects Complaint Data to the Risk File

Every number in a risk management file started as a judgment. Someone looked at a hazard, considered the test data and the history of comparable devices, and estimated how often the harm would occur. That estimate went into the file. The benefit-risk conclusion was built on top of it, and a Notified Body reviewed the whole structure. Then the device shipped, and the estimate started being checked against reality, whether anyone was looking or not.

What the regulations actually ask for

ISO 14971 is explicit that risk management continues through production and post-production. Clause 10 requires manufacturers to collect and review information about the device in production and post-production, and to reassess whether previously acceptable residual risk is still acceptable.

EU MDR made the same expectation harder to sidestep. Article 83 requires a post-market surveillance system that actively gathers data, and Annex III ties the surveillance plan directly to updating the risk management documentation. The PSUR then reports on what that surveillance found.

Read together, these create a loop. The surveillance plan feeds the risk file, and the risk file feeds the periodic safety report. Each depends on the other being current.

Auditors have adjusted their questions accordingly. The request used to be "show me your risk management file." It is now closer to "show me how this complaint trend changed your risk file." Those two questions need very different systems to answer well.

Why a complaint count answers nothing

The instinct is to count complaints. It does not work, and the reason is arithmetic.

Fifty complaints against a hazard sounds serious. Across a thousand units shipped, it is. Across five million units, it may sit comfortably below what your risk file already assumed.

Occurrence is a rate. Rates need two numbers, and only one of them lives in your quality system.

The denominator, units sold or shipped or procedures performed, usually sits in ERP or a sales system. Which means every honest check of an occurrence estimate is a join across two systems that were built by different vendors for different departments in different decades.

That join is the single reason most manufacturers do this annually rather than continuously. Not indifference, and not sloppiness. The work is genuinely awkward.

The three things a complaint needs before it counts as evidence

To turn a complaint into evidence about a specific hazard, three things must be true.

• The complaint has to point at a hazard. Not a product, not a category, a specific hazard and hazardous situation in the file. Without that link, all you have is a pile of reports about a device.
• The hazards have to be countable. If the risk file is a spreadsheet and the complaints are in a quality system, nothing counts anything automatically. Somebody reads and tallies.
• The denominator has to be reachable. Otherwise the count stays a count.

Most quality architectures deliver none of the three, because the risk module and the complaint module were designed as neighbours rather than as one system.

How Smarteeva does it

1. Hazards are records, not rows in a document - In Smarteeva, hazards, hazardous situations and intended use exist as objects in the same platform as complaints, investigations and adverse events. This sounds like an implementation detail, and it is the whole thing. Once a hazard is a record, other records can point at it, and pointing is what makes a loop possible.
2. IMDRF Annex codes carry the mapping - Your complaints are already coded to IMDRF Annex terms, because regulatory reporting requires it. That coding is the bridge. Smarteeva uses the Annex codes to assign the hazard and the severity level, ranging from negligible to catastrophic. The assignment runs on deterministic rules rather than a probabilistic model, which means the same input produces the same output every time, and the logic can be read, versioned and defended. This matters more than it might sound. A model that classifies hazards well but differently on Tuesday than on Monday is a validation problem in a submission workflow. Rules are inspectable. When an auditor asks how a complaint was mapped to a hazard, the answer is a rule rather than a confidence score. It also means the work is already mostly done. The coding effort your team spends on MDR and MIR reporting now does double duty as risk evidence.
3. Unit volumes come from the systems that hold them - Distribution and unit data is drawn from Salesforce or your ERP, which supplies the denominator. Occurrence becomes a rate that can be compared against what the risk file assumed, rather than a number somebody has to contextualise by hand.
4. Reports assemble from the same records - Analysis workflows run on Orchestra and the report template is applied through Smart Documents. AI drafts the narrative sections from the ingested data. The team reviews, edits and approves before anything is issued. Manufacturers who previously spent one to three months assembling a risk assessment report now generate it in 8 to 10 minutes.

‍

What changed for one manufacturer

The obvious consequence of that speed is cadence. One manufacturer moved from a review cycle of one to three years to a six month warning and an annual report. That is a different safety posture, not a different reporting schedule.

The less obvious consequence is the more interesting one.

When the assessment was automated, it surfaced problems in the manual version: missing investigations, hazards that had been mapped incorrectly, and calculation inaccuracies that human reviewers had passed over across several cycles.

This is worth sitting with, because it inverts the usual argument for automation. The claim is normally that software does the same work faster. Here the software did the same work faster and found that the previous work had been wrong in places nobody had noticed.

That is what tends to happen when a manual process is large enough. Not carelessness, volume. Hundreds of hazards, dozens of product families, thousands of complaints, and a human being making the same judgment call several thousand times in a row.

What stays with people

Everything above is assembly. Linking, counting, dividing, comparing, drafting.

The judgments do not move. Whether a residual risk is acceptable, whether the benefit still outweighs it, and what to do when an occurrence rate exceeds what the file assumed. That last decision means choosing between a CAPA, a design change, a labelling update or a field action.

Those decisions carry regulatory accountability, and accountability does not delegate to software. A model cannot be the author of a benefit-risk determination, and no regulator would accept it as one. What changes is where the time goes. Teams that spent months assembling evidence spend that time interpreting it instead.

Where to start

You do not need a platform to begin. You need to know whether the loop exists at all. Pick one hazard from your risk file. Find the occurrence estimate. Then answer three questions: how many complaints in the last twelve months mapped to it, how many units were in the field over the same period, and how the observed rate compares to the estimate.

Time yourself. If it takes an afternoon for one hazard, you now know what your annual review actually costs, and roughly how long a drifting rate could go unnoticed.

‍

‍

FAQs

• Does EU MDR require the risk file to be updated from complaint data? Yes. Article 83 requires an active post-market surveillance system, and Annex III links the surveillance plan to updating risk management documentation. ISO 14971 Clause 10 sets the same expectation through its production and post-production requirements.
• What is occurrence rate in ISO 14971? Occurrence is the probability that a harm will happen. Expressed as a rate, it requires both a count of events associated with a hazard and a denominator of units or procedures in the field, since a raw complaint count carries no meaning without exposure data.
• How often should a risk file be reviewed against complaint data? The standards require it to be continuous rather than periodic. Most manufacturers review annually because joining complaint data to hazard records is manual. The gap between those two facts is where safety signals go unnoticed.
• How are complaints mapped to hazards in Smarteeva? Through IMDRF Annex codes, using deterministic rules that assign both hazard and severity. The mapping is inspectable and repeatable rather than probabilistic.
• Does AI make the hazard classification decision? No. Hazard and severity assignment is rules-based. AI drafts narrative sections of the risk assessment report, which people then review and approve.
• How long does a risk assessment report take to generate? 8 to 10 minutes, for manufacturers who previously spent one to three months assembling the same report manually.

‍

‍