Why take this course?
Risk management for AI/ML-enabled medical devices introduces considerations that are not always adequately addressed through conventional software risk analysis alone. The behavior of an ML-enabled function can be influenced by the data used to develop and evaluate the model, characteristics of the intended population, input variability, model performance, foreseeable use, and changes that occur throughout the product lifecycle. These factors need to be considered within the established ISO 14971 risk management process. ISO/TS 24971-2:2026 provides specific guidance for applying ISO 14971 to medical devices that use machine learning. For design and quality teams, this means understanding how ML-specific considerations affect hazard identification, risk estimation and evaluation, selection of risk controls, verification of those controls, residual risk, and the continued review of risk after the device is released.
This webinar focuses on putting that framework into practice. Presenter will examine Product Hazard Analysis and the use of FMEA and Fault Tree Analysis for ML-related risks, including risks associated with data, model behavior, incorrect or unexpected outputs, and performance variability. The session will also address how identified risks are translated into design and risk-control requirements and traced through verification and supporting evidence. The discussion then follows the risk file across the Total Product Life Cycle, including algorithm and model changes, postmarket performance, cybersecurity considerations, and anticipated modifications under PCCPs. It will conclude by connecting these activities with design and development under QMSR and the risk-management evidence relevant to FDA marketing submissions.
Key Areas Covered
Meredith Crabtree
Meredith L. Crabtree is a quality and regulatory professional with extensive experience supporting medical device and life sciences organizations in quality systems, regulatory compliance, risk management, validation, and emerging technology applications. Her work includes helping organizations address the practical quality and compliance implications of AI-enabled systems, product lifecycle activities, supplier and process controls, postmarket activities, validation, and evolving regulatory expectations. Her training focuses on translating regulatory and quality requirements into practical decisions that technical and quality teams can apply within their existing systems and processes.
Commonly Asked Questions About This Subject
How should risk be evaluated when an AI/ML medical device performs well overall but performs materially worse for a particular patient population?
The subgroup performance needs its own risk evaluation when the difference could affect clinical safety or effectiveness. Strong aggregate performance can conceal clinically important variation across populations, input characteristics, disease presentations, acquisition conditions, or other circumstances relevant to intended use.
The difficult decision is whether the variation creates a new hazardous situation, changes the probability of an existing harm, weakens a risk control, or requires a restriction on intended use. Simply documenting that overall acceptance criteria were met may provide little assurance for the affected population.
Evidence should connect observed performance differences with the clinical consequences of incorrect, missed, or delayed outputs. That may lead to additional controls such as operating boundaries, user information, input-quality requirements, performance monitoring, or design changes.
Averages are useful for characterizing a model. Risk management has to examine where those averages can hide failures that matter to the patient.
What should happen when postmarket data reveal an AI/ML failure mode that was technically foreseeable but was judged highly unlikely during development?
The original risk estimate should be revisited using the postmarket evidence rather than defended because the hazard was already listed in the risk file. Actual field experience can change the assumptions used to estimate probability, characterize hazardous situations, or judge the effectiveness of existing controls.
This becomes difficult when the risk file contains the correct hazard terminology but remains unchanged after complaints, performance monitoring, or real-world use provides materially different information. Prior identification of the hazard does not resolve the question of whether its current risk remains acceptable.
The review should examine the circumstances surrounding the events, affected populations or inputs, severity of potential harm, existing controls, and whether the observed pattern exposes limitations that development testing did not reveal.
A risk file carries greater regulatory weight when it visibly learns from field performance. Continuing to rely on an old probability estimate after contrary evidence accumulates makes the lifecycle risk-management process increasingly difficult to defend.
How can a manufacturer show that an AI/ML risk control actually reduces patient risk rather than simply improving a technical performance metric?
The evidence should connect the technical control to the hazardous situation and resulting risk it was intended to reduce. An improvement in sensitivity, specificity, error rate, confidence score, or another model metric does not automatically demonstrate the expected reduction in patient risk.
Suppose a control reduces false negatives. The risk argument should explain which hazardous scenario those false negatives create, under what conditions the control operates, how its effectiveness was verified, and what residual failures remain possible. That connection becomes particularly important when model performance varies across populations or operating conditions.
Weak risk files sometimes contain excellent model-performance evidence but leave the clinical consequence several steps removed from the verification result. Reviewers then have to infer why the test demonstrates effective risk control.
A stronger record preserves the chain from hazard through control, implementation, verification, and residual risk. Technical performance becomes meaningful evidence because its relationship to patient safety has been explicitly established.
When an AI/ML model is modified under a predetermined change plan, what evidence is needed to show that previously controlled risks have not quietly reappeared?
An anticipated modification still needs evidence that existing risk controls remain effective after the change. A predetermined change control plan can establish how certain modifications will be managed, but it does not make the safety consequences of those modifications self-evident.
The concern is regression outside the performance characteristic that motivated the update. Improving performance for one population, input condition, or clinical objective can alter behavior elsewhere. Previously acceptable failure modes may increase, new interactions may appear, or assumptions supporting residual-risk conclusions may no longer hold.
Post-change evaluation should therefore revisit affected hazards and controls, including areas where performance was expected to remain unchanged. Evidence from predefined acceptance criteria, comparative testing, subgroup analysis, and relevant postmarket monitoring can help establish continuity of control.
The strongest change record shows more than successful implementation of the intended improvement. It demonstrates that the modification did not undermine the risk-management conclusions on which the existing device configuration depended.
Your TalkFDA Webinar Experience
1. Confirmation
3. Join the Live Training
4. Watch Again Anytime
Testimonials
Ready to Strengthen Your Team? Let’s Build Your Training Plan.
Your team deserves the clarity.
Your organization deserves the confidence.


