How Smarteeva Automates Medical Device Risk Management
.png)
What ISO 14971 Actually Requires After a Device Ships
Risk management in medical devices carries two identities. On paper, ISO 14971 makes it the backbone of patient safety, the discipline that ties every hazard a device could present to the evidence that the hazard remains under control. In practice, it often runs as a periodic manual exercise, a scheduled scramble to refresh assessments that everyone knows are out of date the day they are signed.
The standard itself does not ask for that. ISO 14971:2019 Clause 10 covers production and post-production activities, and it requires manufacturers to establish a system for collecting and reviewing information about the device once it is on the market. That information includes complaints, adverse events, and production data, and the requirement is to evaluate whether it affects the risk assessment already on file.
EU MDR reinforces the same expectation from a different direction. Article 83 requires a post-market surveillance system that actively gathers device performance data, and Annex I requires risk management to run as a continuous iterative process across the device lifecycle. The word used in both places is continuous.
How a Traditional Risk Assessment Gets Built
The mechanics explain why the annual cycle persists. A risk assessment asks a team to take each hazard and hazardous situation from the risk file and reconcile it against real-world evidence: how many complaints, adverse events, and nonconformances mapped to that hazard over the past twelve months.
That raw count means nothing on its own. It has to be normalized against denominator data, meaning units sold, units produced, and procedures performed, to determine whether the observed probability of occurrence still matches what the risk file assumed. A hazard with forty complaints against two million units shipped sits in a very different place than the same forty complaints against forty thousand units.
Now multiply that across hundreds of hazards and dozens of product families, with the evidence scattered across complaint handling systems, MedWatch and vigilance databases, quality management systems, and ERP platforms. Risk assessments consume weeks of skilled quality engineering time, happen once a year at best, and rest on manual classification decisions that vary from analyst to analyst.
Why the Annual Cycle Creates a Detection Gap
Inefficiency is the smaller problem here. Latency is the real one. If a device's real-world failure rate begins drifting above the threshold assumed in the risk file in February, but the annual review happens in November, the organization spends nine months unaware that one of its documented assumptions no longer holds.
Signal detection and risk management end up running as parallel, disconnected processes. One hunts for trends in complaint data, the other periodically checks old assumptions against a fixed schedule. They should be the same activity.
Why This Matters Beyond Compliance
The risk file is the lens regulators care most about. It is the document that connects a hazard to a harm, a harm to a probability, and a probability to a decision about whether the benefit-risk profile still holds. An inspector reading a complaint trend will ask which hazard it maps to and what the risk file assumed.
When risk assessment and trending run as separate programs, that connection gets made retrospectively, by a person, under time pressure. When they run as one process, every signal arrives already framed in risk management terms: which hazard is drifting, which harm it relates to, and whether the benefit-risk profile is affected.
That framing shortens the path from detection to decision, whether the decision is a CAPA, a design change, a labeling update, or a field action.
What Continuous Risk Assessment Looks Like in Practice
Two capabilities have to be in place, and they solve different problems.
The first is orchestration. Something has to connect directly to the systems where post-market evidence actually lives: complaint handling, adverse event reporting, nonconformance and CAPA systems, service records, and the ERP and sales systems that hold denominator data. Instead of analysts exporting spreadsheets and reconciling them by hand, current data pulls from each source continuously and stays aligned to the product hierarchy and the risk file.
The second is classification. The heaviest manual work in any risk assessment is reading each complaint narrative or nonconformance description and deciding which hazard, harm, and failure mode it represents. Large language models are well suited to reading unstructured complaint text at scale and mapping each record to the correct hazard and hazardous situation, with a consistency that manual coding rarely achieves.
The design decision that matters is what happens to ambiguous records. A system that forces a binary classification on every record will produce a clean-looking risk file built on quiet errors. A system that flags ambiguity for human review produces a defensible one.
Put both capabilities together and the risk assessment stops being a document refreshed annually. It becomes a live calculation. Occurrence rates for every hazard recalculate as new complaints and nonconformances arrive and as denominator data updates, and when an observed rate approaches or exceeds the probability the risk file assumed, it surfaces immediately with the underlying records attached as evidence.
How Smarteeva Automates ISO 14971 Risk Assessment
Smarteeva runs risk assessment inside the post-market workflow rather than alongside it. The platform is built natively on Salesforce, and every module shares one data model, so complaints, adverse events, CAPA records, and risk assessments sit in the same environment.
Risk assessment triggers on complaint creation
When a complaint is created, a risk assessment is triggered automatically against preconfigured scoring criteria for the affected product family. Severity, occurrence, and detection scoring runs across process, design, and system levels through FMEA, pFMEA, and dFMEA. The scoring happens inside the complaint record, so there is no export and no separate spreadsheet to reconcile later.
Denominators come from ERP
Occurrence scoring means nothing without exposure data. Smarteeva pulls units sold and units produced from ERP, so an occurrence rate is calculated against current volume rather than against a figure someone keyed in at the start of a review cycle.
AI scoring adapts as complaint data arrives
Machine learning models read incoming complaint evidence and surface emerging risk patterns across product codes, geographies, and time periods. Decision trees and risk scores adjust as new records land, which is what keeps an assessment current between formal reviews.
Adaptive thresholds replace the calendar
Rather than waiting for a scheduled review, the platform alerts when an incident rate deviates from its baseline. From that alert, the path to a CAPA runs inside the same system. Dashboards allow drill-down by product, complaint category, geography, and time period, and they update as the underlying data changes.
Every step is logged
Traceability runs from the originating complaint through the risk score to the mitigation action, and every AI decision carries an audit trail. That is what makes the file defensible when an inspector asks how a particular score was reached.
What Changes for Quality Teams
Four patterns show up repeatedly in how teams use this.
Complaint-triggered risk review means nobody has to remember to open an assessment. Trend-based escalation flags a product when complaint frequency exceeds its rolling baseline, which is exactly the drift an annual cycle misses. Audit preparation becomes a query rather than a reconstruction, because the risk history for any product already holds every assessment, score change, and mitigation action with timestamps.
The fourth change is organizational. Quality, clinical, and manufacturing teams work from one risk view instead of separate spreadsheets that disagree with each other.
Where Human Judgment Stays
None of this removes people from the loop, nor should it. Judgment about risk acceptability, benefit-risk determinations, and mitigation strategy remains firmly with qualified people, and no regulator will accept an automated decision on any of those.
What automation removes is the drudgery and the delay, the months spent assembling data instead of interpreting it. The question for quality leaders is no longer whether risk assessments can run continuously. It is how soon their risk file starts working as the real-time read on product safety it was always meant to be.
FAQs
How often should a medical device risk management file be updated?
ISO 14971 does not set a fixed interval. Clause 10 requires manufacturers to collect and review production and post-production information on an ongoing basis and to reassess risk when that information indicates the original assessment no longer holds. Many manufacturers default to an annual review, but the standard's requirement is triggered by new information rather than by the calendar.
What is denominator data in medical device risk management?
Denominator data is the exposure figure used to convert a raw event count into a rate. It typically means units sold, units produced, or procedures performed over the same period as the complaint or adverse event count. Without it, forty complaints cannot be compared against the probability of occurrence recorded in the risk file.
Can ISO 14971 risk assessments be automated?
The data collection, normalization, and classification steps can be automated. Judgment about risk acceptability, benefit-risk determination, and mitigation strategy cannot, and ISO 14971 assigns those decisions to qualified people. A defensible automated system routes ambiguous records to human review rather than forcing a classification.
What is the difference between signal detection and risk management?
Signal detection looks for emerging trends in post-market data. Risk management checks whether documented assumptions about hazards and their probabilities still hold. Run separately they duplicate work and detect the same problem at different times, which is why continuous risk assessment treats them as one activity.
What data sources feed a continuous risk assessment?
Complaint handling systems, adverse event and vigilance databases, nonconformance and CAPA records, service records, and the ERP or sales systems that hold denominator data. The risk file itself supplies the hazards, hazardous situations, and assumed probabilities that incoming records are measured against.
Does AI replace human judgment in medical device risk management?
No. AI handles reading unstructured complaint narratives at scale and mapping them to hazards, which is the most labor-intensive and least consistent manual step. Risk acceptability and benefit-risk decisions stay with qualified people, and every AI classification should be reviewable with the underlying records attached.
.png)
.png)
