Many medical device companies still treat risk management and design controls as two different universes. One team builds the product. Another team documents hazards and residual risks. On paper this looks tidy. In practice it creates gaps, rework and a safety story that feels stitched together instead of intentional.

The better path is simple. Treat risk management and design controls as one system. One flow. One narrative.

Why This Matters

Medical devices live in the real world. Real users. Real environments. Real consequences.
You cannot bolt risk controls onto a design after the fact. By then the important decisions are already locked in.

When risk thinking is part of design from the start, everything gets easier. Requirements become clearer. Reviews become faster. Verification and validation become more focused. Surprises become rare.

This is not only what regulators expect. It is what good engineering looks like.

User Needs Are Your First Safety Activity

User needs are often written like marketing notes or feature lists. But they also carry safety meaning. They should reflect foreseeable misuse, environmental conditions, human factors and safety related performance.

When user needs include these elements, they stop being vague statements. They become the first building block of a safe design. And they make validation far more meaningful later.

Let Risk Drive Your Design Inputs

A strong development process shows a clean line of reasoning:

Hazards lead to hazardous situations.
Hazardous situations lead to risk evaluation.
Risk evaluation leads to risk based requirements.
Those requirements become design inputs.

This is the traceability regulators look for. It is also what engineers need. Risk based inputs are specific, measurable and tied to real safety outcomes. Which means they are easier to verify.

Verification and Validation Become Sharper

When design inputs come from risk, verification becomes a focused question:
Do the design outputs meet the risk based requirements?

And when user needs include safety expectations, validation becomes more than a checkbox. It becomes a real test of whether the device works for real users in real conditions.

This alignment cuts ambiguity. It speeds up reviews. It strengthens confidence.

Risk Tools Should Shape Decisions, Not Fill Binders

Hazard analyses, FMEAs and similar tools are often treated as documentation tasks. But their real purpose is to influence design. A risk tool that never changed a requirement is just paperwork. A simple analysis that led to a design change is far more valuable.

The goal is not perfect documents. The goal is safer devices.

Build a Coherent Risk Based Story

Regulators expect to see risk thinking woven through the entire design control process. They want to see how hazards informed requirements, how requirements shaped design, how verification confirmed risk based inputs and how validation confirmed user needs.

This is what makes a design history file coherent instead of chaotic.

Integration Is a Competitive Advantage

Teams that integrate risk and design controls do more than comply. They build better products. They avoid late stage surprises. They improve usability. They move faster because they make fewer wrong turns.

In a field where safety and speed both matter, integration is not a luxury. It is the only path that works.

AI is no longer experimental in medical devices.

Over 1,000 AI-enabled devices have already been authorized, with most applications in imaging, diagnostics, and decision support.

The common narrative is that AI introduces entirely new risks.

That is only partially true.

The real issue isn’t the technology

AI does introduce specific challenges:

• Data bias and discrimination

• Model drift over time

• Lack of interpretability

• Hallucinations and inconsistent outputs in LLM-based systems

But in practice, these are not where most risk management failures originate.

The bigger issue is this:

AI exposes weaknesses that were already present in how risk management is applied.

Why AI stresses the system

Traditional devices are relatively stable.

AI systems are not.

They are:

• data-dependent

• context-sensitive

• dynamic over time

That difference matters.

It forces you to answer questions that were often handled superficially before:

• What exactly is the system, beyond the model?

• How is the output used in real workflows?

• What happens when conditions change?

If those answers are unclear, the risk analysis may look complete, but it is not robust.

Where the gaps typically show up

Across AI-enabled systems, the same patterns appear.

1. System definition is incomplete

Risk is often assessed at the model level.

But patient impact occurs at the system level.

Example:
An AI tool flags potential stroke cases from imaging. The model performs well in testing.

But in practice:

• Who reviews the alert first?

• Is it integrated into triage or just displayed in PACS?

• What happens during high workload periods?

If that workflow is not clearly defined, the risk is not understood.

2. Risk logic lacks depth

A common shortcut is jumping from “the model was wrong” to “the patient was harmed” without describing the real-world pathway in between.

Without clearly describing how exposure happens, it becomes difficult to:

• estimate likelihood meaningfully

• design targeted controls

• verify effectiveness

What is usually missing:

• Was the AI used as a primary reader or second reader?

• Did the clinician rely on it or override it?

• Was uncertainty communicated?

Without that pathway, controls tend to default to “more validation,” which does not address the real risk.

3. Validation is disconnected from real use

Performance metrics are necessary, but not sufficient.

Validation needs to reflect:

• real-world variability

• edge cases

• user interaction with outputs

Example:
A dermatology model shows high accuracy on curated datasets.

In deployment:

• image quality varies

• lighting conditions differ

• patients fall outside the training distribution

Performance drops, but this was never tested.

In many AI applications, even defining a stable ground truth is challenging.

4. Human-AI interaction is underestimated

A significant portion of risk comes from how users interact with the system:

• over-reliance on outputs

• ignoring valid recommendations

• misinterpreting confidence or uncertainty

Example:
An AI tool outputs a “high confidence” classification.

Users interpret this as “high certainty,” even though the model confidence is not calibrated to clinical risk.

The issue is not the algorithm.

It is how the output is understood.

5. Risk management stops too early

AI systems change over time.

• Data evolves

• Models drift

• Clinical practice shifts

A one-time, pre-market risk assessment is not enough.

Example:
A model trained on historical imaging data performs well at launch.

Over time:

• new imaging protocols are introduced

• patient populations shift

• performance degrades gradually

Without monitoring and predefined reassessment triggers, this goes unnoticed.

This is why a Total Product Lifecycle approach is becoming essential.

This is already reflected in regulatory expectations

Recent FDA direction consistently emphasizes:

• continuous performance monitoring

• real-world evidence

• predetermined change control plans

• transparency of system behavior

These are not new frameworks.

They are extensions of existing principles into a more dynamic environment.

What this means in practice

The takeaway is not that AI requires a completely new approach.

It requires a more rigorous application of the existing one.

In practice, that means:

• defining the full system, not just the model

• describing realistic use scenarios, not just abstract risk rationale

• validating in context, not only on datasets

• extending risk management into post-market activities with monitoring and predefined reassessment triggers

• expanding controls beyond testing to include workflow design, training, and transparency

Final thought

Good risk management is not about just following the process. It is about understanding the system well enough to apply it correctly.

AI makes it obvious when that understanding is missing.

Concept decisions are like pouring concrete. You can remodel later, but the foundation is already set, including the cracks.

That is what the concept phase is in medical device development. It is the pre design input period where you decide the fundamentals: intended use, core workflow, operating principle, and high-level architecture. Once those choices harden, many safety outcomes become expensive or impossible to change without redesigning the system.

This is why risk often feels “discovered” late.

Not because teams ignore safety.
Because by the time risk analysis becomes formal, the highest leverage choices are already locked.

The part ISO 14971 does not do for you

ISO 14971 gives structure for identifying hazards, describing hazardous situations, linking to harms, and evaluating controls.

What it does not do is protect you from early decisions that quietly narrow your control options.

On paper, you can be fully structured.

In reality, the concept phase sets the boundary conditions for what you can truly control through design, and what you will later try to manage with weaker measures like labeling, training, and procedural steps.

How risk gets locked in before you estimate it

When people say “risk is baked in,” they usually mean three things.

1. The concept defines exposure pathways

You do not just choose features. You choose how a hazard can become a hazardous situation in real use.

If your concept increases exposure frequency, removes barriers to exposure, or creates new dependency chains, you have changed the risk landscape before you assign any probability band.

2. Architecture decides whether controls will be strong or fragile

Some controls reduce risk through design by making hazardous situations harder to reach.

Other controls rely on behavior and context. They assume attention, training, stable workflows, and perfect interpretation under pressure.

If safety depends on perfect behavior, the system is brittle, even if documentation looks clean.

3. Assumptions become commitments before they become visible

Many teams can list design inputs.

Fewer teams can list the assumptions that make those inputs “work.”

Common concept assumptions:

• the user will follow the intended workflow every time

• the sensor will behave across real patient variability

• connectivity will be available when it matters

• alarms will be interpreted correctly in a busy environment

• labeling will prevent edge case harm

Those are not neutral statements. They are safety bets.

If you cannot say what would prove an assumption wrong, you are not managing uncertainty. You are postponing ownership.

Intended use is the first risk decision

Teams often treat intended use as something to finalize later for submission.

That delay has a cost.

Intended use defines the context for safety and effectiveness. It sets the boundary for:

• patient population

• user profile

• use environment

• clinical objective

• reasonably foreseeable misuse in context

If intended use is vague in concept, your hazard identification will be incomplete in a predictable way. You will not be reasoning about the real world your device will actually encounter.

Why this becomes risk debt

Once the concept hardens, risk reduction gets expensive.

A meaningful change can cascade into:

• architecture redesign

• rework of usability and training assumptions

• revised verification strategy

• changed clinical evidence expectations

• expanded warnings and labeling to compensate

Teams then try to defend the concept with documentation.

But documentation does not change exposure conditions. It only changes how the story is told.

A concept phase check that keeps you honest

You do not need more templates. You need an earlier, sharper conversation.

Ask five questions before design inputs and architecture are effectively frozen.

1. What harms are we truly designing against
   Name harm as injury or damage, not a failure mode.

2. What hazardous situations does this concept make easy to reach
   Hazardous situation is the exposure state. Concept choices create exposure states.

3. Which controls are we relying on, and how strong are they outside ideal conditions
   Separate design controls from behavioral controls.

4. What are the top three assumptions we are betting the program on
   Write them down. Add what you would expect to observe if each were false.

5. What uncertainty will still exist at launch, and what is our plan for it
   Monitoring is not neutral. If you choose monitoring, define reassessment triggers up front.

Two defensible paths, and one common non decision

When concept work reveals uncomfortable risk, there are usually two defensible options.

Option A: change the concept while it is still cheap

This is not perfectionism. It is leverage.

Option B: proceed, but treat it as explicit risk acceptance under uncertainty

This can be reasonable when benefits are strong and alternatives are limited.

But it requires discipline:

• stronger evidence expectations

• clear triggers for escalation

• visible ownership of residual risk

The common failure is the unofficial third path.

Proceed as if you chose neither.
Call it “to be validated.”
Let it drift into later phases.
Then act surprised when change becomes hard.

That is how risk gets locked in without anyone actually deciding to accept it.

The smallest next step

Hold a 60 minute concept risk lock in review before design inputs and architecture are frozen.

Three voices:

• engineering, to speak to architecture reality

• clinical or medical, to speak to harms and use context

• quality or risk leadership, to keep the decision defensible

End with four sentences:
Decision.
Rationale.
Risk explicitly accepted.
What would change the decision.

That short paragraph will do more for patient safety than a perfect risk table written after the window for meaningful change has closed.

Ask almost anyone on a device team where risk “lives” and you will usually get pointed to the matrix.

Green, yellow, red.
A score.
A box.

The problem is not that scoring is useless.

The problem is that scoring becomes a substitute for thinking. Risk is not a number. Risk is a sequence of events that can lead to a hazardous situation and then to harm.

If you want to understand where safety actually breaks down, stop staring at the score and start walking the chain.

The Move That Changes Everything

A risk analysis row is not complete when it has probability and severity.

It is complete when you can describe, plainly:

• the hazard (potential source of harm)

• the sequence of events

• the step in that sequence where exposure occurs, stated as the hazardous situation

• the harm

• which risk control measure breaks the sequence, and under what conditions it does not

That “sequence of events” is where real learning happens. Because it forces you to explain how the world actually works, not how you wish it worked.

What the score can’t tell you

A matrix tells you where to look first. It cannot tell you what to change.

Only the sequence of events shows:

• when exposure occurs (the hazardous situation)

• which control breaks

• why harm becomes possible

What a Useful Sequence of Events Looks Like

Most teams write sequences that are either too short or too polite.

Too short: “failure leads to harm.”
Too polite: “user will notice.”

A useful sequence has enough detail that someone could challenge it.

It names:

• a realistic initiating event, including reasonably foreseeable misuse and relevant external dependencies

• what changes in device behavior, output, or information

• what the user does next, and why that response is foreseeable

• when exposure occurs, stated as the hazardous situation

• which risk control measure breaks the sequence, and under what conditions it does not

If the sequence reads like a story that could happen, you can test it. If it reads like a slogan, you can’t.

The Four Places a Chain Breaks (and Where Controls Actually Work)

When a patient is harmed, the chain usually broke in one of four places.

1) The initiating event was more plausible than you assumed

Configuration states are common in the field. Workflows are rushed. Environments are noisy. Dependencies behave differently outside test conditions.

If your initiating event is wrong, your probability estimate is wrong.

2) Exposure was never clearly defined

Teams often skip the hazardous situation and jump straight to harm.

But exposure is the whole point. If you cannot state when a person is exposed to the hazard, you cannot argue that a control “reduces risk.”

3) Detection failed quietly

Alarms delayed, masked, or ignored. Interfaces that look normal. Loss of monitoring that is not obvious.

This is where “we have an alarm” becomes “we assumed an alarm.”

4) Recovery depended on perfect behavior

A lot of chains “work” on paper because they require the user to notice, interpret, and act correctly every time.

If a control depends on perfect recognition under pressure, treat it as weak unless you have evidence it holds in real use.

A Real Device Example: Infusion Pump Concentration Mismatch

This is a common place where teams learn the difference between a score and a sequence.

• Initiating event (reasonably foreseeable misuse and dependencies): The clinician selects the wrong concentration from a list under time pressure, or the drug library is out of date (dependency: drug library configuration and update process).

• What changes: The pump calculates the infusion rate using the wrong concentration assumption. The displayed rate can still look reasonable.

• Foreseeable user action: The clinician starts the infusion because the workflow cues appear consistent and the situation is time-pressured.

• Hazardous situation: The patient is connected and receives infusion while the pump is operating with an incorrect concentration assumption relative to the actual medication prepared.

• Harm: Over-infusion or under-infusion leading to drug-specific injury (for example hypotension, respiratory depression, inadequate analgesia).

• Risk control measure that breaks the sequence: drug library hard limits, independent double-check, barcode medication verification, and explicit concentration confirmation prompts.

• Conditions where it fails: limits are set too wide, overrides are routine, barcoding is unavailable, or confirmations become click-through.

Notice what this sequence forces you to decide: are you preventing the hazardous situation, or relying on detection and recovery after exposure?

A score does not show that distinction. A chain does.

The Fastest Way to Improve Your Risk File

Pick three rows that are “acceptable” but make you uneasy.

Then do one thing: write the sequence of events as if you were explaining it to someone who disagrees with you.

If you cannot write a credible sequence without hand-waving, you have found a weak assumption.

That is where safety work is.

The Decision That Matters

A risk score can help you prioritize.

A sequence of events tells you what to change.

If you want defensible risk judgments, treat the chain as the object of analysis and the score as the summary, not the other way around.

The RiskWise MedTech question

For one risk you currently call acceptable, can you walk the full chain from initiating event to hazardous situation to harm, and point to the specific risk control measure that breaks it in real use?

Ask almost anyone in medical device development what a “good” risk analysis looks like and you will usually hear the same answer:

Identify hazards.
Estimate probability and severity.
Assign a risk level.
Add controls.

This shows up in standards, training, and internal procedures because it feels complete.

What fails is not calculation. It’s definition.

Teams often jump from hazard to harm without defining the hazardous situation in between. When that step is missing, the analysis can look structured, but it is built on undefined exposure.

The Step Everyone Skips (and Why It Matters)

ISO 14971 separates three things for a reason:

• Hazard: a potential source of harm (examples include energy, biological agents, chemicals, radiation, and information).

• Hazardous situation: the circumstance in which a person is exposed to the hazard.

• Harm: the injury or damage to health (or property or the environment).

If you skip the hazardous situation, you skip the part that determines whether anyone is actually exposed. And that undermines everything that follows, including:

• whether your sequence of events is realistic

• what probability you are estimating

• whether your controls interrupt the right part of the chain

• whether your residual risk conclusion is defensible

You can still fill out the table. You just can’t be confident it means what you think it means.

Why “Hazard” Gets Misused

Most risk files quietly treat these as hazards:

• “software failure”

• “alarm failure”

• “use error”

• “incorrect display”

Those are usually failure modes or causes, not hazards.

A hazard is the “thing” that can injure. A hazardous situation is when someone is exposed to it.

When you label failure modes as hazards, probability, control rationale, and verification strategy drift, because the exposure step was never made explicit.

What a Hazardous Situation Actually Does

A hazardous situation forces three clarifying moves that “hazard” and “harm” alone do not.

1) It defines exposure, not just possibility

A hazard can exist in a design forever. A hazardous situation is about use.

Electrical energy exists as a hazard in many devices.
The hazardous situation is when a patient or user can be exposed to that energy under specific conditions.

2) It makes the sequence of events testable

Without a hazardous situation, sequences collapse into vague statements like “failure leads to harm” or optimistic statements like “user will notice.”

A hazardous situation forces you to specify conditions:

• who is using it

• what workflow they are in

• what they assume is true

• what foreseeable errors occur

• what dependencies exist (network, accessories, configuration, environment)

Now you can ask a concrete question: is that exposure plausible in the intended use environment?

3) It tells you where controls need to act

Controls do different jobs:

• prevent the hazardous situation

• reduce the probability of harm after exposure

• reduce severity through mitigation

If you never define the hazardous situation, it becomes easy to over-credit controls that do not actually prevent exposure or reduce the probability of harm.

A Simple Rewrite That Fixes Most Risk Tables

For each row, force this three-line structure first:

1. Hazard: potential source of harm

2. Hazardous situation: who is exposed, to what, under what conditions

3. Harm: the injury outcome

Only then add your sequence of events and controls.

Practical test:

If you cannot write the hazardous situation as a sentence, you are not ready to estimate probability or argue acceptability.

Two Examples (Written the ISO 14971 Way)

Example 1: Electrical energy

• Hazard: electrical energy

• Hazardous situation: during use, a fault condition makes accessible parts energized while a patient is connected

• Harm: shock, burn, arrhythmia

Example 2: Information used for clinical decisions

• Hazard: information used for clinical decision-making can be incorrect or delayed

• Hazardous situation: clinician relies on an incorrect or delayed displayed value in a time-critical situation without independent confirmation

• Harm: delayed intervention, inappropriate therapy, injury

Notice what changes when you write it this way.

You are no longer describing “something went wrong” and jumping to harm.

You are defining the source of harm (information that can be wrong or late), then the exposure condition (reliance in a time-critical context), then the injury outcome. That middle sentence is what makes probability and controls defensible, because it tells you exactly when someone is exposed and what needs to be prevented, detected, or mitigated.

The Failure Pattern You See When Hazardous Situations Are Missing

When hazardous situations are absent, risk analyses tend to collapse into one of two patterns.

Pattern A: “Label, then harm”

Hazard: something bad
Harm: injury

It reads like a risk statement, but nothing is anchored. You cannot tell who is exposed, how, or under what use conditions.

Pattern B: “Probability by intuition”

Teams assign probability scores without agreeing on what event they are estimating.

Probability that a failure occurs?
Probability that someone is exposed?
Probability that harm occurs?

Those are different. The hazardous situation is the bridge that keeps those from being blended into a single number.

What to Do Tomorrow, Not Next Quarter

If you suspect your risk file is light on hazardous situations, you do not need to rewrite everything.

Pick the 10 rows that matter most (highest severity, most debated, most clinically important) and do one repair pass:

Rewrite each row so it includes a hazardous situation sentence.

You will quickly find:

• rows that are duplicates once exposure is clarified

• harms that are not clinically defined

• controls that do not actually interrupt exposure

• probability estimates that were never anchored to a specific event

That is not rework. That is making the analysis real.

The Decision That Matters

The point of risk analysis is not to populate a matrix.

It is to make a defensible claim that for foreseeable use, residual risk is acceptable given the benefits and the available controls.

You cannot make that claim if you have not defined exposure.

The RiskWise MedTech question

If you had to write the hazardous situation in one sentence, what would change in your sequence of events and in how you estimate the probability that exposure leads to harm?

Ask almost anyone in medical device development how risk is calculated and you will usually hear the same answer:

Risk equals probability multiplied by severity.

This formulation shows up in standards, training, and internal procedures because it’s simple and intuitive.

The problem is rarely the arithmetic.

The problem is that teams often score probability and severity without anchoring them to a specific hazardous situation, a sequence of events, and a defined harm. When that anchor is missing, risk estimates look precise but are built on undefined inputs.

The Equation Everyone Uses (and What It’s Really Saying)

At its core, the logic is sound:

• A severe harm that occurs rarely may be acceptable.

• A minor harm that occurs frequently may be acceptable.

• A severe harm that occurs frequently is not.

That logic is often expressed as:

Risk = probability of occurrence of harm × severity of that harm

Used well, this helps prioritize what matters. Used loosely, it turns into a scoring exercise that hides uncertainty instead of clarifying it.

The Hidden Problem: “Probability” Is Not One Thing

In many risk analyses, “probability” is treated as a single value.

In reality, it often contains (at least) two distinct probabilities:

• P1: Probability that a hazardous situation occurs (the exposure happens)

• P2: Probability that harm occurs given the hazardous situation (the exposure leads to injury/damage)

These are fundamentally different. Collapsing them into one number obscures where the uncertainty actually sits.

In many medical device scenarios, the dominant uncertainty is not what happens after exposure. It’s:

How often does the system place the user or patient into the hazardous situation in the first place?

If that question isn’t answered clearly, probability estimates drift toward guesswork.

Severity Is More Stable But Often Applied to the Wrong Thing

Severity is typically easier to discuss because clinical outcomes are better understood.

But a common mistake is assigning severity to something that is not a harm.

Examples that often get mislabeled as harms:

• Overdose

• Incorrect diagnosis

These are usually hazardous situations (or outcomes of a failure) — not harms.

Severity should be assigned to harms such as:

• Physiological injury

• Permanent impairment

When teams blur hazardous situations and harms, severity ratings become inconsistent, and risk comparisons lose meaning.

The Real Structure of Risk: A Chain, Not a Score

Risk does not arise directly from hazards.

It emerges through a chain:

Hazard (source of harm) → Hazardous Situation (exposure) → Harm (injury/damage)

Risk estimation becomes meaningful when it is tied to the hazardous situation, because that is where exposure occurs and where sequences of events can be interrupted.

This has two practical implications:

• Probability must be tied to a defined sequence of events, not an abstract “hazard.”

• Severity must be tied to a defined harm, not an intermediate state.

When those are mixed, the resulting risk numbers lose explanatory power—even if they look tidy in a matrix.

A Worked Mini-Example: Where Probability Actually Lives

Consider an electrical safety scenario:

• Hazard (source of harm): electrical energy

• Hazardous situation (exposure): user touches an accessible conductive part during a single-fault condition

• Harm: electric shock leading to burn, arrhythmia, or death (specify the clinical endpoint)

Now split probability:

• P1 (hazardous situation occurs): depends on fault occurrence and whether touch is realistically possible during use/maintenance

• P2 (harm given exposure): depends on current path, duration, patient condition, and other factors

Decision impact:
If uncertainty is mostly in P1, arguing about injury likelihood is not the best use of time. The better risk move is to reduce or prevent the hazardous situation (e.g., insulation, barriers, protective earth, interlocks, design limits that prevent accessibility).

This is what “probability × severity” can’t show unless you first model the chain.

Why Probability Estimates Drift Toward Subjectivity

Many devices (especially early in development) lack hard data:

• New technology, little history

• Variable clinical use conditions

• Inconsistent user behavior

• Complex system interactions

So teams assign categories like remote, occasional, frequent.

These labels can be useful for discussion, but they are not measurements. The problem is not using judgment. The problem is treating judgment as if it were precise.

Risk matrices can reinforce that illusion by producing clean outputs from undefined inputs.

Software: Probability Still Matters, But It Moves

Software highlights why “failure rate” thinking can mislead.

Software contributions are often systematic: if triggering conditions exist, the behavior is repeatable. That shifts the practical question from:

• “How often does the software fail?”

to:

• “How often do the triggering conditions and exposure pathways occur in real use?”

So software risk analysis becomes less about guessing defect frequency and more about:

• identifying hazardous scenarios

• defining triggering conditions

• understanding exposure in use

• ensuring controls interrupt the sequence (requirements, architecture, mitigations, alarms, usability, verification evidence)

Probability isn’t gone. It’s just attached to conditions and exposure, not randomness.

Risk Is Not a Calculation. It Is a Model of System Behavior

The probability × severity relationship remains useful, but it is incomplete unless you can answer:

• What is the hazard (source of harm)?

• What is the hazardous situation (exposure) and how does it occur?

• What sequence of events leads there?

• What is the harm (clinical endpoint)?

• Where can the sequence be interrupted (controls)?

• What evidence supports P1 and P2?

These are questions about system behavior, not just numbers.

A More Useful Question Than “What’s the Probability?”

Instead of asking:

“What is the probability of this harm?”

Ask:

• How does the hazardous situation occur?

• What sequence of events leads to exposure?

• How often might those conditions realistically arise?

• What control breaks the sequence most reliably?

• What evidence would change our estimate?

That shift moves risk management from scoring to understanding and makes acceptability judgments more defensible.

You can often judge the quality of a risk analysis in less than five minutes.

Just look at how the team uses the word hazard.

If hazards, harms, and failures are all mixed together in the same column of a spreadsheet, something has gone wrong.

And unfortunately, this happens all the time.

Many Risk Analyses Use the Wrong Language

Risk management relies on a simple chain of ideas.

A hazard is a potential source of harm.

A hazardous situation occurs when someone is exposed to that hazard.

Harm is the injury or damage that may result.

That sequence matters.

Because if you skip steps, your analysis stops describing how accidents actually happen.

Yet many risk tables look like this:

At first glance this seems reasonable.

But look closer.

“Battery failure” is not a hazard.
“Software bug” is not a hazard.

Those are failures.

They might lead to hazards. But they are not hazards themselves.

When terminology becomes sloppy, the logic of the analysis begins to collapse.

How Accidents Actually Occur

Accidents rarely happen because something simply “failed.”

They occur through chains of events.

Consider a very simple example.

A medical device contains a battery.

The battery can overheat.

If the device casing becomes hot enough, a user touching it may be burned.

That sequence might look like this:

Battery fault → overheating → hot surface → user contact → burn

The hazard in this example is the hot surface.

The hazardous situation is the user touching that surface.

The harm is the burn.

If you remove the intermediate steps and simply write “battery failure → burn,” you lose the structure of the problem.

And once the structure disappears, effective risk controls become harder to design.

Why the Distinction Matters

The purpose of risk management is not simply to list bad outcomes.

It is to understand how harm can occur.

That understanding allows engineers to intervene earlier in the chain.

For example, you could reduce risk by:

• preventing the battery from overheating

• insulating the device surface

• detecting overheating and shutting the device down

• warning the user

Each of these solutions addresses a different point in the causal chain.

If your analysis jumps directly from “failure” to “harm,” those opportunities may never appear.

Hazards Exist Even Without Failures

Another reason this distinction matters is that hazards are not always caused by malfunctions.

Some hazards exist during normal operation.

A surgical laser generates intense energy.
An infusion pump delivers medication into the bloodstream.
A defibrillator releases high-voltage electrical pulses.

These hazards are not defects.

They are inherent properties of the technology.

Risk management must therefore consider not only failures, but also normal use and reasonably foreseeable misuse.

If the analysis focuses only on failure modes, it may miss some of the most important safety problems.

Language Shapes Thinking

Risk management is partly an analytical discipline.

But it is also a language discipline.

The words used in a risk analysis influence how engineers think about the system.

If terminology is precise, teams can reason clearly about cause, exposure, and outcome.

If terminology becomes vague, risk management quickly turns into a list of loosely connected problems.

Unfortunately, many organizations treat the vocabulary of risk management as a formality rather than a tool.

That is a mistake.

Clear language is the foundation of clear safety thinking.

A Simple Test

The next time you review a risk analysis, try a quick experiment.

Look at the first few rows of the table and ask three questions:

1. Is the hazard actually a source of harm, or just a failure?

2. Does the analysis describe how someone becomes exposed to that hazard?

3. Is the harm clearly separated from the hazard itself?

If those three elements are not visible, the analysis probably needs revision.

Because good risk management does not just catalog problems.

It explains how accidents can happen.

RiskWise Question

When you review risk analyses in your organization, what is the most common terminology mistake you see?

Risk management did not appear because regulators wanted more paperwork.

It appeared because technology can hurt people.

Medical devices interact directly with the human body. They deliver energy, chemicals, mechanical forces, and increasingly software-driven decisions. When these systems fail, or behave in ways designers did not anticipate, the consequences can be severe.

This is why the medical device industry treats risk management as a core engineering discipline rather than an optional activity.

But understanding why risk management exists requires accepting a difficult truth.

Medical devices can never be completely safe

Many people instinctively think safety means the absence of risk.

That is not how safety works in engineering.

Every medical device introduces hazards.

A surgical robot delivers force inside the body.
An infusion pump pushes medication into the bloodstream.
A defibrillator releases high-energy electrical pulses into the heart.

Each of these technologies is both beneficial and potentially dangerous.

The goal of safety engineering is therefore not to eliminate risk entirely. That is impossible.

Instead, the objective is to reduce risk to a level that is acceptable in light of the benefit the device provides.

This principle underpins modern medical device regulation. Devices are allowed onto the market only when the expected benefits justify the remaining risks.

Risk management came from other industries

Healthcare did not invent systematic risk analysis.

Industries such as aviation, nuclear power, and chemical processing faced similar problems decades earlier. Their systems were complex, their technologies powerful, and the consequences of failure catastrophic.

Engineers in those industries discovered something important.

Accidents rarely occur because of a single failure.

They occur when multiple events align:

• a design weakness

• a component malfunction

• an environmental condition

• a human action

Together these events create a situation where harm becomes possible.

Medical devices share the same characteristics.

They combine hardware, software, clinical workflows, and human interaction. When these elements interact in unexpected ways, hazards can emerge.

Risk management provides a structured way to analyze those interactions before a product reaches patients.

Risk management is not just engineering

Another misconception is that risk management is purely a technical activity.

In reality, it requires contributions from many disciplines.

Engineers understand system behavior.
Clinicians understand patient impact.
Human factors specialists understand how users behave.
Regulatory professionals understand compliance requirements.
Cybersecurity experts understand digital threats.

Each perspective reveals different pathways to harm.

A design that appears technically sound may still create problems when used in a real clinical environment. A user interface that seems intuitive during development may lead to dangerous errors during stressful emergency situations.

Risk management forces organizations to bring these perspectives together.

Risk does not come only from failure

Many engineers initially think about risk in terms of failures.

Components break. Software crashes. Sensors drift.

But some hazards exist even when the device works exactly as intended.

Radiation therapy is supposed to deliver radiation.
Electrosurgical devices are supposed to generate heat.
Implantable devices are supposed to interact with living tissue.

These technologies inherently involve hazards.

Risk management therefore does not focus only on malfunction. It also considers:

• normal operation

• foreseeable misuse

• environmental conditions

• interactions between system components

Ignoring these factors leads to incomplete safety analysis.

The real value of risk management

In many companies risk management becomes a documentation exercise.

Teams populate spreadsheets, assign severity scores, and produce a large “risk management file” just before regulatory submission.

When that happens, the process loses its real value.

The true benefit of risk management is the thinking it forces during product development.

When teams systematically explore questions like:

• What hazards exist in this system?

• How could users be exposed to them?

• What chain of events could lead to harm?

• How can we interrupt that chain?

they often discover design weaknesses early.

These insights can lead to safer architectures, better monitoring, improved alarms, or clearer user interfaces.

In other words, risk management is most valuable when it influences design decisions, not when it produces documentation.

A better way to think about risk management

Many engineers learn to treat risk as a formula:

probability multiplied by severity.

While this mathematical view is useful, it captures only part of the problem.

Risk management is fundamentally about understanding systems.

It requires mapping how hazards arise, how people interact with devices, how failures propagate, and how safeguards interrupt dangerous sequences.

When done well, risk management becomes a powerful design tool.

When done poorly, it becomes paperwork.

The difference depends on how seriously teams treat the discipline.

A question for practitioners

Think about the last medical device project you worked on.

Did the risk analysis change the design?

Or did it simply document decisions that had already been made?

That answer often reveals how mature an organization’s risk management culture really is.

Most teams treat benefit–risk analysis like a closing paragraph in a report.
A few lines on clinical value, a short conclusion, and it’s done.

But this is the part regulators read the most carefully.

They are not checking whether the section exists.
They are assessing whether the argument holds.

This is about trade-offs, not safety

In theory, every hazard could be designed out. High voltage removed. Sharp edges eliminated. Software faults reduced as far as possible.

But what would be left?

A device with zero risk usually delivers zero benefit. Remove the hazard from a surgical laser, and you remove its ability to cut tissue. What remains may be safer, but it is no longer useful.

This is the trade-off. Not a flaw in the system, but the reality of it.

Stating benefit is easy. Proving it is not.

Most submissions claim clinical benefit. That is expected.

What matters is whether it holds up under scrutiny.

Does the device improve outcomes compared to current practice?
How often does that benefit actually occur in real use?
And when it fails, what does the harm look like?

If those answers are unclear, the argument does not hold.

Hiding risk weakens your position

Some teams still try to soften residual risks. They reduce visibility, adjust wording, or move details out of focus.

That approach signals uncertainty.

A stronger position is explicit. Acknowledge the risk, show how it was reduced, and explain why it remains acceptable.

That is what a defensible argument looks like.

This is where the real decision is made

No template can carry this section for you.

You are asking a regulator, and ultimately a patient, to accept risk in exchange for benefit.

That is a decision with consequences.

It requires judgment, not formatting.

Real expertise is not presenting a device as flawless. It is demonstrating, with clarity and evidence, that the device improves outcomes despite its limitations.

🧠When you look at your latest risk-benefit analysis, are you truly justifying the risk, or are you just trying to explain it away?

Most medical device organizations have a Risk Management File that is technically perfect.

It has the signatures. It has the traceability. It passes the audit.

But if you look closely, you will find that the file was authored in a vacuum. It lives in a silo, usually the “Quality” or “Regulatory” corner of the office, and it only interacts with the rest of the company when it needs a signature to hit a milestone.

On paper, the process is compliant. In reality, the risk management is lonely. And in MedTech, lonely risk management is a disaster waiting to happen.

The Bicycle Principle

Safety is what engineers call an emergent property.

Think about a bicycle. You can lay out the chain, the pedals, the frame, and the handlebars on the floor. You can perform a rigorous stress test on every single part. You can prove, with mathematical certainty, that the chain will not break under five hundred pounds of pressure.

But “transportation” does not exist in the chain. It does not exist in the pedals. It only emerges when you put the parts together and a human being tries to ride it.

Risk management is the same. If your software team is identifying bugs in one silo, and your clinical team is defining “harm” in another silo, and your hardware team is mitigating heat dissipation in a third, you do not have a safe device. You have a pile of parts and a very expensive paper trail.

Where the Silos Fail the Patient

When risk management is isolated, the most dangerous hazards do not just stay in their departments. They fall through the cracks between them.

• The Engineering Silo knows the battery might overheat if the vents are blocked. But they do not know that in a real world ICU, a tired nurse might drape a heavy blanket over the device to keep it quiet.

• The Clinical Silo knows the patient needs a precise dosage. But they have not seen the software UI, so they do not realize how easy it is to accidentally hit “100” instead of “10” on a touchscreen while wearing gloves.

• The Manufacturing Silo sees a slight shift in a component’s tolerance. It is within spec, so they do not mention it to the design team. They do not realize that shift just invalidated a critical assumption in the Hazard Analysis.

ISO 14971 requires a multidisciplinary team. That is not just a suggestion for a diverse meeting. It is a recognition that no single person, and no single department, is smart enough to see the whole picture.

The 3:00 AM Stress Test

You cannot manage risk from a spreadsheet.

Real risk management happens when you force the person who wrote the code to sit in a room with the person who understands how a surgeon’s hands shake at 3:00 AM after a double shift. It happens when the person who designed the power supply hears from the person who handles field complaints about minor sparks in the field.

When risk management is integrated, it becomes a bridge. It connects how we built it to how it is actually used.

When it is a silo, it is just a barrier. It becomes a “Quality task” that engineers try to bypass so they can get back to what they consider real work.

The Cultural Stress Test

If you want to know if your risk management is a silo or a system, look at your Design Reviews.

• Is the Risk Management Report presented at the very end as a completed artifact? That is a silo.

• Or does the risk analysis drive the design requirements from day one? That is a system.

Is your Risk Management File a dead document that sits on a server for five years until the next audit? Or does a single unusual complaint in the field trigger an immediate, cross functional review of your initial assumptions?

Compliance is a Starting Point

ISO 14971 gives you a defensible framework. It tells you what to document. But it cannot force your departments to talk to each other. It cannot make an engineer care about a usability edge case.

At the end of the day, a compliant, siloed risk file might satisfy an auditor. But it will not protect your patients, and it will not protect your company from a massive recall when the “impossible” happens because two departments did not share a cup of coffee.

Do not just build a file. Build a conversation.

🧠What is the clearest sign you have seen that a risk file was compliant but not truly integrated into the design?

One of the most powerful tools I use in risk work isn’t a matrix, or a template, or a clause from ISO 14971.

It’s a simple question:

“Who owns this?”

Not “who updates the form?”
Not “who was in the meeting?”
Who owns this risk decision going forward?

Before we go any further, let’s clear up one thing:

• ISO 14971 does not literally say: “Each individual risk shall have an owner.”

• What it does expect is: clear responsibility and authority for risk management activities and for deciding whether risks are acceptable.

Everything that follows is about how you can implement that expectation in practice.

The Meeting Where the Risk “Belonged to the Team”

You’ve probably lived this scene.

Risk review meeting. On the screen:

• A serious but rare potential harm

• Some ambiguous complaint data

• A justification along the lines of: “low probability, no trend identified so far”

The group discusses. Someone tightens the wording. Someone else says, “We’ll monitor in PMS.”

No one loves it, but no one is panicking either.

The chair wraps up:

“Okay, so we’re aligned that no further action is needed for now?”

Heads nod. Laptops close. On paper, it looks great:

• Thorough discussion

• Clear rationale

• Decision: No additional control. Residual risk acceptable.

What didn’t get said:

• No person or role was named as owning that decision.

• No one is clearly accountable for being wrong later.

• No explicit trigger was set for re-opening the decision if new information shows up.

The risk now lives in a document.

It does not clearly live in anyone’s head, calendar, or job description.

That’s the governance gap “Who owns this?” is trying to close.

What ISO 14971 Actually Cares About (and What It Leaves to You)

ISO 14971 doesn’t prescribe a column in your risk table labelled “Owner”.

Instead, it focuses on things like:

• Defining responsibilities and authorities for risk management activities

• Ensuring people making risk acceptability and benefit–risk decisions have the right competence and authority

• Having someone at the right level decide whether the overall residual risk of the device is acceptable in relation to its benefits

How you implement that is largely up to you.

So when I push the question “Who owns this?”, I’m not claiming:

“ISO 14971 requires each risk to have a named owner.”

What I am doing is turning those fuzzy words - responsibility, authority, acceptability into something operational:

For any meaningful risk decision, we should be able to answer:
“Who owns this, and who would re-open it if our assumptions change?”

That’s a design choice, not a made-up clause.

Two Kinds of Ownership (That Often Get Confused)

It helps to separate process ownership from decision ownership.

1. Process ownership

This is the obvious one:

• Who owns the risk management process?

• Who maintains procedures, templates, training, tool integration, etc.?

This is usually Quality, a Risk Manager, or a Safety Officer.

Important, yes. But if you stop there, you end up with:

“Quality owns risk.”

Which sounds neat, but quietly breaks reality.

2. Decision ownership

This is the one that really matters for safety:

• For this specific risk (or group of similar risks), who has the authority to say “acceptable” or “not acceptable”?

• Who is responsible for re-opening that decision if the world changes (new PMS data, new use pattern, new clinical knowledge)?

• Who ultimately carries the benefit–risk trade-off on behalf of patients, users, and the business?

ISO expects this to exist, but it does not tell you exactly how to structure it.

That’s where “Who owns this?” becomes a very sharp practical question.

“Who Owns This?” ≠ “Who Do We Blame?”

In some cultures, as soon as you ask “Who owns this?”, people hear:

• “Whose fault will this be if something goes wrong?”

• “Whose name will be on the investigation report?”

• “Whose career is at risk here?”

That’s not what I’m advocating.

A healthier interpretation looks like this:

• Ownership is about duty: “I will actively monitor this and re-open it if needed.”

• Ownership is about authority: “I am actually empowered to make and change this decision.”

• Ownership is about clarity: “Everyone knows I’m the one carrying this, not some anonymous ‘team’.”

Blame lives in the past.
Ownership lives in the present and future.

How to Make Ownership Real (Without Drowning in Admin)

You don’t need an “Owner” column on every FMEA line. What you do need is a few clear anchors where ownership is explicit.

In practice, that usually means three simple things:

1. Define who owns risk by domain or product.
For example:

• Product Line Owner – overall benefit–risk for the product

• Clinical Safety Lead – clinical performance and patient harms

• Usability Lead – use-error-driven harms

• Cybersecurity Lead – security/integrity-related harms

Put this map somewhere visible (risk management plan, risk summary, governance doc), so it’s clear which roles carry which types of risk decisions.

2. Call out ownership for borderline or tricky risks.
Most “routine” decisions can sit under those domain owners.

But when a decision is uncomfortable or controversial, document:

• Who accepted it (role/committee)

• On whose behalf (safety board, etc.)

• What would make them re-open it (complaint trend, serious incident, new clinical data, volume threshold…)

This can be one sentence in the minutes:

“Residual risk accepted by Clinical Safety Board on behalf of the Medical Safety Committee; will be re-evaluated if serious incidents of type X occur or complaint rate exceeds Y per Z units.”

3. Make decision records smarter, not longer.
You don’t need more documents. You need slightly richer ones.

For key decisions, don’t just record what was decided. Add:

• Accepted by: [role/committee]

• On behalf of: [organization segment]

• Revisit if: [trigger or timeframe]

For example:

“Decision: No additional risk control for [risk X].
Accepted by: Product Line Owner, on behalf of the [Therapy Area] BU.
Will be reconsidered if: new PMS data shows an increase in event rate above [threshold] or new clinical data changes the benefit profile.”

That’s it. No new matrix, no extra SOPs. Just adding a clear “who” to the decisions that actually matter.

Where Ownership Quietly Disappears

A few familiar spots where ownership tends to evaporate:

1. Cross-functional reviews

You know the drill:

• Design review

• Risk review

• Change Control Board

Lots of good discussion, then the minutes say:

“The team agreed that the residual risk is acceptable.”

But “the team” is not a legal entity.
In reality, some roles in that room have the actual authority, others don’t.

“Who owns this?” forces that underlying structure to surface.

2. Risk matrices and categories

We love summaries like:

• “Risk level: Low”

• “Within risk appetite”

• “Acceptable with current controls”

Those labels are fine, but they’re not the whole story. Somewhere you also need:

“Accepted by [role] on behalf of [organization segment].”

Otherwise, when something goes wrong, everyone can hide behind:

“Well, it was ‘low’ at the time; we were all aligned.”

That’s not accountability. That’s camouflage.

3. “Quality owns risk”

When everything is “owned by Quality,” what usually happened is:

• Real decisions were made by product, clinical, or business leadership.

• But those decisions were parked in a system managed by Quality.

• Over time, everyone started talking as if “Quality” had made the call.

Quality can own:

• The process

• The documentation

• The challenge function (“Have you considered X?”)

But Quality does not own:

• The clinical trade-off that a particular harm is justified by benefit

• The business trade-off that a certain risk is acceptable for a market

“Quality owns risk” is a comfort story.
In reality, risk always belongs to people whose decisions shape the product.

How to Ask “Who Owns This?” Without Starting a Fight

You don’t need to march in waving standards.

Start with quiet, neutral questions that invite clarity.

In a risk review

When the room is about to move on from a tricky risk:

“Before we close this, can we be explicit:
which role owns this decision going forward?
As in, who would re-open it if new information changes the picture?”

If people hesitate, offer a suggestion:

“Given this is a benefit–risk question, I’d expect it to sit with [Product Line Owner / Clinical Safety Lead]. Does that align with how we want to handle it?”

You’re not forcing an answer; you’re helping them design their own governance.

In a CAPA discussion

When someone argues that an issue doesn’t need a CAPA:

“If we decide not to escalate this into a CAPA,
who owns that call and will keep an eye on this pattern?”

Now the room isn’t just choosing “CAPA or not”; it’s choosing:

“Are we comfortable that someone is owning the risk of inaction?”

When reviewing PMS data

You see a weird, non-trending signal:

“This doesn’t meet our formal trend criteria yet, but it’s interesting.
Who owns this as a risk signal? On whose radar should this formally live?”

If the answer is “PMS,” ask one more:

“PMS can monitor and report, but who ultimately decides what action, if any, we take if this moves?”

That’s usually where the real risk owner appears.

If You’re in QA/RA: What’s Your Role in All This?

If you’re QA/RA, you’re in a special position:

• You rarely own the product risk.

• But you do own the clarity of how risk decisions are made and revisited.

Your job isn’t just “do we comply with ISO 14971?”

Your job is also:

• Make sure assumptions and trade-offs are visible.

• Make sure decisions can be traced to roles that actually have authority.

• Make it hard for the organization to say “we didn’t realize” with a straight face.

You’re less the “no” person and more the “let’s be honest about what we’re choosing” person.

“Who owns this?” is one of the gentlest, most powerful ways to do that.

The Shift This Question Creates

When “Who owns this?” becomes normal, a few things change:

• “The team agreed…” turns into “This role accepted, on behalf of…”

• Leaders think more deliberately about the risk they are actually willing to carry.

• PMS and CAPA signals connect more cleanly back to specific decisions and owners.

Most importantly:

Your risk management system stops being just a pile of documents and starts looking like what it truly is:

A network of real human decisions, made by people with names, roles, and responsibilities.

That’s where safety, compliance, and sane governance finally start to work together.

Your Next Experiment

In your next risk or CAPA meeting, try this once:

When everyone thinks you’re done with a tricky decision, ask:

“One last thing:
Which role owns this decision, and what would make them re-open it?”

Then watch:

• Is there a confident answer?

• Do people instinctively turn to Quality?

• Does someone realize, “Actually, this belongs one level higher”?

Whatever happens, you’ll have learned something important about how risk really works in your organization. Far beyond what any SOP says.

If you do try it, I’d be genuinely curious what happened.
What did people say? What surprised you? That’s where the real learning lives.

If you’ve been around device development for a while, you’ve probably lived some version of this scene.

The slide deck is open. The design review is running late.
Someone finally asks the question that can derail the whole meeting:

“Are we covered on risk?”

The team glances at the risk file. It’s complete. The matrix looks reasonable.
Someone says the line everyone recognizes:

“We take a lifecycle approach to risk.”

Heads nod. Milestones stay green. The project moves on.

What almost nobody does in that moment is fast-forward five years and ask:

“Will this risk story still feel true when the device has been out in the world for a while?”

Because that’s where the illusion creeps in.

On paper, the company has “integrated risk into the lifecycle.”
In reality, the device keeps learning, and the risk file often doesn’t.

The straight line we like to draw

Most slide decks show some version of:

Concept → Design & Development → Launch → Post-Market → End of Life

I’m using that as a simple shorthand for what ISO 14971 is getting at with concept, development, production, and post-production. The standard doesn’t care what you call the boxes; it cares that risk thinking runs through all of them.

The way that picture is drawn, though, sends a quiet message:

• risk is “done” in development

• the rest is operations, support, and surveillance

In practice, it looks more like this:

• During design and development, teams build a detailed story about hazards, hazardous situations, harms, and controls. It’s thoughtful work, but necessarily full of assumptions.

• After launch, reality starts talking back in a different language: complaints, service calls, odd field modifications, usability issues, regulatory questions.

• CAPAs, changes, and workarounds become the day-to-day response to that reality.

Whether that adds up to lifecycle risk management or just lifecycle firefighting depends on one thing:

Do these post-market signals actually change the way the organization understands and manages risk for that device?

Or do they just generate more tickets, more documentation, and a thicker PMS report?

When experienced regulators walk a product through your system, that’s what they’re reading between the lines.

What “lifecycle” quietly requires

The mechanics are familiar to everyone: risk files, complaint systems, CAPA workflows, Management Review decks.

Underneath those mechanics, lifecycle risk management is really doing three quieter jobs.

Keeping the risk story alive

Before launch, most teams are doing honest work with imperfect information:

• trying to anticipate how the device might fail

• imagining how people will actually use it (and misuse it)

• deciding which controls are enough

• making a call that the residual risk is acceptable

That’s version 1.0 of the risk story.

As soon as the device hits the field, the story starts getting new chapters:

• complaints that don’t quite fit any existing failure mode

• user behaviors nobody predicted in verification or usability studies

• rare but serious events that make everyone reread the FMEA

• field workarounds that quietly rewrite the intended use

In organizations where the lifecycle is genuinely integrated, those new chapters eventually show up in the risk file, the design, and how the product is monitored.

In organizations where it isn’t, the pre-market story stays frozen while the real story moves on without it.

A lot of seasoned QA/RA folks will admit, off the record, that there are products on the market today where they would not bet their reputation that the risk file still reflects reality. That gap is the lifecycle risk illusion.

Making judgment visible, not just metrics

Every team is deciding under uncertainty. The difference is whether that uncertainty is acknowledged or buried.

In a thin system, most post-market discussions orbit around:

• counts and rates

• trend lines

• threshold logic

• phrases like “no significant increase observed”

Those things matter. But they don’t tell you how confident you should feel.

In stronger systems, people are willing to ask more uncomfortable questions, for example:

• “Which of our launch assumptions does this signal poke at?”

• “If this is the first visible edge of something bigger, what’s the worst plausible story we’re looking at?”

• “Does our benefit–risk story still feel honest, given what we now know?”

When those kinds of questions never surface, you still have a lifecycle on paper… but not much lifecycle judgment.

You can usually tell by watching Management Review:

Are leaders just signing off on dashboards, or are they occasionally forced into a real conversation about changed risk, changed confidence, and what they’re willing to own?

Turning learning into control, not just commentary

Experienced people often have a simple heuristic:

“Show me what actually changed after that issue, and I’ll tell you how serious your system is.”

When a device runs into trouble, sometimes the path looks like this:

• investigation

• root cause narrative

• retraining and IFU updates

• CAPA closed

The documentation is tidy; the device barely changes. Complaints may dip for a while, then drift back.

Other times, the same kind of trigger leads to:

• a re-look at usability or workflow

• a small but meaningful design adjustment

• tighter process or supplier control around a safety-critical characteristic

• a change to what PMS is watching for next time

On the surface, both scenarios involve “complaints, CAPA, and monitoring.” On the inside, only one of them is really integrating new risk knowledge into the lifecycle.

People working close to the product can feel the difference immediately.

One path feels like paperwork.
The other feels like the device and the system actually learned something.

Where the lifecycle tends to break

When you trace a single product end-to-end, the weak spots tend to recur.

The risk story doesn’t survive the team

Early in the lifecycle, there’s usually a handful of people who could stand at a whiteboard and explain the risk thinking behind the device: why certain controls were chosen, which scenarios were deemed implausible, which trade-offs were made.

Fast-forward a few years and a couple of reorganizations, and that story is often scattered:

• parts of it in old slide decks

• parts in people’s heads

• parts never written down at all

The complaints group sees patterns, but not the original assumptions those patterns are challenging.
Field teams sense “something isn’t right,” but don’t know how to link that back to design intent.

That’s how rare but important signals end up closed as “no trend” – not because anyone is careless, but because the original context has evaporated.

PMS becomes a sorting office

Most companies can show you a well-structured PMS process:

• complaints are logged and coded

• rates are calculated

• thresholds are defined

• reporting decisions are made

What’s much rarer is a regular space where people are allowed to say:

“This handful of cases doesn’t meet any threshold, but it’s making us uneasy. Let’s talk about why.”

That sort of conversation is where early lifecycle learning often lives.

Without it, PMS slips into a purely transactional role: move tickets, watch charts, feed reports. The system is technically “covering” post-production, but not really challenging the pre-market risk picture.

CAPA chases closure, not learning

Most CAPA systems were built to prove that action was taken, not to preserve what was learned.

It shows up in small ways:

• risk sections that repeat “risk remains acceptable” as a stock phrase

• “user error” as a convenient root cause that ends the conversation

• effectiveness checks that confirm actions were completed, not that risk actually dropped

When CAPA runs like this, lifecycle integration becomes hard to see. Events are processed; knowledge doesn’t accumulate.

In contrast, the CAPAs that quietly strengthen the lifecycle tend to be the ones where someone insists on answering, even informally:

• what did this teach us about how the device can actually fail or be used?

• what does that do to our confidence in the risk story?

• what would have to change – in the device, the process, or the way we watch it – for us to say “we’ve truly absorbed this”?

Those are uncomfortable questions. But they’re the ones that keep the lifecycle from becoming theatre.

Management Review reads the dashboards, not the story

By the time risk reaches top management, it has usually been reduced to:

• counts

• rates

• colors

• a few conclusions

In many reviews, every metric is technically accurate and the overall picture still feels strangely bloodless.

What’s often missing is even a short segment that sounds like:

“This product’s risk story has moved in the last year – here’s how.

These are the assumptions we no longer fully trust.
These are the areas where our confidence is actually stronger.
And here’s what we’re watching because we’re not as sure as we used to be.”

That kind of narrative takes more work than listing trends, but it’s also the moment where “lifecycle” becomes real for leadership.

Without it, the illusion stays intact: the lifecycle looks calm; the learning is opaque.

How experienced people quietly shift the system

People who’ve been through a few product lifecycles don’t usually start by rewriting procedures. They start by changing the conversations.

A few patterns tend to show up when they do.

They treat the Risk Management Plan as a living contract

On paper, the Risk Management Plan is a document. In practice, experienced folks use it more like a commitment:

• this is how we’ll think about risk while we’re designing

• this is how we agree to revisit that thinking once the device is used for real

• this is who will be in the room when new information appears

• this is where those decisions will land so they’re not forgotten

The plan stops being something you file before design transfer and starts being something you pull out when the device, the field picture, or your own confidence changes.

The clauses haven’t moved. The attitude has.

They make space for “weird but worrying”

People who’ve lived through surprises rarely trust trends alone.

They know most serious issues start as a few awkward, explainable cases. So they pay attention to the small, nagging patterns that don’t yet justify a bar chart.

Sometimes that’s as simple as keeping an informal list in PMS meetings:

• things that are rare but strange

• things that feel “off” even if the numbers are tiny

And asking, once in a while:

“If this ends up being the first visible edge of something significant, what will we wish we had noticed earlier?”

The answer is often, “That the story didn’t fit our assumptions anymore.”

Lifecycle integration grows from that kind of discomfort.

They agree in advance when to go back upstream

When pressure is high, it’s very easy to talk yourself out of revisiting design or risk.

So experienced teams set some lines in calmer moments:

• if a new type of harm appears

• if severity or frequency is clearly different from what we assumed

• if users keep “failing” in the same way despite our training and labeling

• if process or supplier changes touch safety-critical characteristics

…then we don’t debate whether to bring design and risk back in. We already agreed: that’s a design re-entry moment.

Nothing in ISO 14971 mandates exactly those triggers, but the spirit of “throughout the lifecycle” looks a lot like this in real companies.

They use CAPA to anchor the story, not just the fix

In more mature organizations, the CAPAs that matter are the ones that leave a trace in three places:

• the risk file

• what PMS looks for next

• what gets mentioned, even briefly, in Management Review

Not because the procedure demands it, but because people have learned the hard way what happens when knowledge stays trapped in one part of the system.

You still see retraining. You still see IFU updates. But they’re not the default reflex. They’re part of a broader question:

“Given what we’ve learned, what would it mean to really absorb this into the lifecycle of this product?”

That question doesn’t show up on a form, but you can hear it when you talk to the people doing the work.

Why this matters more than it looks on paper

It’s easy to treat “lifecycle risk management” as a phrase to keep regulators and auditors happy.

But the people who end up carrying the weight when something truly goes wrong know it’s more than that. They’re the ones who get the calls, sit in the rooms, and have to explain how this could happen given all the documents that said it wouldn’t.

For them, the goal quietly shifts from:

• “Can we show we did risk management?”

to:

• “Can we tell an honest, evolving story about the risk of this product – one we’re willing to stand behind when the device has been out there for years?”

Standards like ISO 14971 point in that direction when they talk about concept, development, production, and post-production. They’re trying to force the conversation out of the DHF and into the life of the product.

When the lifecycle is working, you can feel it:

• complaints don’t just close; they teach

• CAPAs don’t just fix; they change how people think

• Management Review doesn’t just report; it owns

And the risk file stops being a snapshot and starts feeling more like a logbook.

A quiet test

If you want a simple, internal check – one you don’t show to anyone – pick a single marketed product and walk it through your system in your head:

• What did you believe about its risk at launch?

• What have you actually learned since then?

• Where has that learning genuinely changed what you do – in design, manufacturing, labeling, training, or monitoring – not just what you write?

And then the harder part:

If you had to explain this device’s risk story to someone skeptical, would you reach for the latest risk file first… or would you start talking about things that never made it into the file at all?

The distance between those two is where your real lifecycle lives.

Most medical device organizations I’ve seen are formally compliant with post-market requirements.

They have a complaints handling process.
They run trending reports.
They write their PMS plans and reports.
They produce PSURs or PMSRs where required.

From a regulatory standpoint, the framework is there.

And yet, safety issues still seem to “come out of nowhere.” Recalls feel like surprises. Regulatory findings point to “missed signals.” Internal reviews reveal that early complaints were present long before action was taken.

In those moments, the PMS procedure itself is rarely the limiting factor.

The process is structurally sound.
What fails is how it is used.

PMS Was Never Meant to Be Just Complaints + Reports

ISO 14971’s post-production phase doesn’t treat PMS as an add-on. It treats it as proof that risk management actually works in the real world.

The underlying obligation is not “have a PMS procedure.” It is to operate a systematic, active, and integrated post-market risk system:

• Systematic – intentional and structured, not just periodic.

• Active – seeking signals, not waiting for trends.

• Integrated – feeding intelligence back into design, risk management, and the wider QMS.

By contrast, what many organizations actually run is:

• a complaints factory (focused on closure and reportability), and

• a reporting factory (PMSR/PSUR for regulators, slides for management).

Taken together, they are compliant.
But they are not a risk engine.

Where a Weak PMS Culture Shows Up

Weak PMS culture rarely appears as “we don’t care about safety.” It shows up as how people behave around uncertainty.

Common patterns:

• Post-launch resource collapse.
  Core design engineers move to the next project. The product enters “maintenance mode.” Risk responsibility devolves to custodians with less context.

• Complaints = PMS.
  PMS ownership is effectively assigned to the complaints team. The focus becomes case closure, not signal formation. Complaints handling sees the trees; nobody is looking at the forest.

• Trending as comfort blanket.
  Threshold-based charts dominate. If no line crosses the red threshold, the conclusion is “no trend observed”. Treated as evidence that risk is under control.

• “No harm reported” as assurance.
  Absence of documented injury is quietly taken as proof of safety, rather than as a comment on reporting behavior.

None of this is malicious. It is how systems behave when they are optimized for compliance and volume, not for weak-signal detection and risk learning.

But it changes how the post-market part of ISO 14971 is applied in practice.

On paper, PMS is counting.
In reality, it should be sense-making.

The One-Off Complaint That No One Wants

If you want to see whether PMS acts as a risk engine, don’t look at trends. Look at what happens to one unusual event.

A single complaint with alleged patient harm.
No obvious device malfunction.
Confounding factors everywhere.
Statistically insignificant. Easy to rationalize away.

In many systems, this is what happens:

• It is processed through the standard complaint template.

• Regulatory reportability is assessed via the decision tree.

• The case is closed. It does not move any trend line.

• It never reaches the people who own risk files or design decisions.

On paper, everything was done correctly.

In a risk-aware organization, the same event is treated differently:

• Complaints staff know the current risk profile of the device and can recognize when something doesn’t fit.

• They are empowered to say, “This feels odd,” and bring it to cross-functional specialists, even if the trend charts are flat.

• At least one person in the room is allowed to ask:

“What assumption about device safety would have to be wrong for this to be an early signal rather than a one-off?”

That difference is culture, not procedure.

Complaints Handling Is Not the Same as PMS

One of the most persistent confusions is equating complaints handling with post-market surveillance.

• Complaints handling is about individual cases: receive, document, investigate, decide reportability, respond, close.

• PMS is about system behavior: build a view of how the device is performing in the field, how risk is evolving, and what actions are needed.

A healthy PMS process deliberately widens its lens:

• beyond complaints, to include service reports, returned devices, usability feedback, clinical data, literature, social media, and competitor actions;

• beyond “is this reportable?”, to “does this change our understanding of the device’s risk profile?”

When PMS ownership sits entirely inside the complaints silo, you get excellent trees and a very blurry forest.

When PMS Doesn’t Talk to Risk Management

In a strong system, there is a clear, lived connection between PMS and the risk file:

• New hazards and hazardous situations discovered post-market feed back into hazard analysis.

• New use-errors and misuses discovered in real-world use update risk assessments and controls, not just the IFU.

• Residual risk is periodically re-evaluated in light of emerging information, not assumed static after launch.

In many organizations, that linkage is weak:

• PMS, CAPA, and Design & Development behave as separate processes with poor connectivity.

• Design re-entry triggers are vague or resisted; engaging the original D&D team post-launch is seen as a disruption rather than a normal part of risk management.

• New misuse patterns or edge-case use environments lead to label updates rather than design changes, even when design could shoulder more of the safety burden.

The risk file remains tidy.
The device’s risk reality quietly drifts away from it.

From Surveillance to Risk Knowledge

Turning PMS into something truly useful is less about adding more tools and more about changing its purpose.

Right now, many PMS processes are optimized to:

• satisfy reporting requirements,

• demonstrate trending and monitoring activity,

• show that “no trend observed” justifies staying the course.

A risk-aware PMS, by contrast, is optimized to:

• Expand risk knowledge – Treat every new data point as a test of your assumptions, not just as an entry in a database.

• Detect weak signals – Accept that emerging safety issues will often show up as rare, unusual, or narrative-heavy events, not as clean statistical trends.

• Trigger learning decisions – Use both formal mechanisms (signal detection rules, escalation criteria) and informal mechanisms (cross-functional “listening sessions” with complaints staff) to decide when to pause, investigate, or escalate.

• Drive action on both the device and the system – Separate decisions about design/field action from decisions about improving PMS and risk management itself.

In that environment, PMS is not just watching risk; it is changing risk.

How Leaders Quietly Shape PMS Behavior

As with ISO 14971 overall, leadership behavior matters more than PMS policy.

Some leverage points:

• What gets rewarded.
  Are complaint teams praised for fast closure and low backlog, or for surfacing uncomfortable patterns that create more work?

• How “monitor only” decisions are made.
  When leadership chooses to monitor rather than act, is there a clear decision rationale - context, evidence, assumptions, alternatives, revisit triggers - or just “no trend yet, continue to monitor”?

• Who owns emerging signals.
  Is there a name attached to the decision not to escalate yet, along with clear conditions that would trigger re-evaluation? Or does ownership dissolve into the committee?

Over time, people learn:

• whether it is safe to escalate weak signals early,

• whether “no harm reported” will be accepted as reassurance,

• whether PMS is a learning function or just a reporting function.

That learning gradually shapes how seriously post-market data is taken, long before any formal governance change.

Compliance Is the Floor, Not the Ceiling

Regulators expect you to have a PMS process. The procedures, plans, and reports are non-negotiable.

But patients will never see your PMS procedure.
What they experience is whether you notice trouble early enough to do something about it.

The critical moments are rarely dramatic. They look like this:

• a complaint that doesn’t quite fit the known patterns,

• a small cluster of service calls that feels “odd but probably nothing,”

• a usability comment that sounds isolated,

• a field failure that could be the device, the user, or the environment.

At those points, nobody is asking, “Are we compliant?”
The real questions are:

• Do we have enough curiosity to treat this as a possible signal?

• Do we have a place for this uncertainty to go, other than the archive?

• Is anyone clearly accountable for deciding whether we act or watch?

If the honest answer is “not really,” then the gap isn’t in your PMS template.
It’s in how your organization thinks about post-market risk.

You don’t need a whole new system to change that. You need a few different habits:

• letting one-off complaints start a conversation, not end one;

• asking, “What assumption might this undermine?” before asking, “Is this a trend?”;

• making it normal, not heroic, to bring weak signals into the light.

Safety problems will never stop happening completely. Devices live in messy, real-world contexts.

But they should stop surprising us.

Whether they do has less to do with the sophistication of your PMS, and much more to do with how willing your organization is to listen when the data is still quiet.

🧠What’s the earliest “weak signal” you’ve seen later turn into a real safety issue, and what was missed at the time?

Most medical device organizations I’ve seen are formally compliant with ISO 14971.

They have the procedure.
They have structured hazard analyses.
They have traceability between hazards, harms, and controls.
They generate the required risk management report.

From a regulatory standpoint, the framework is there.

And yet, compliance with ISO 14971 is often necessary but not sufficient for effective risk management.

On paper, the process is defined. In practice, the way people behave under pressure quietly reshapes how that process is used.

ISO 14971 can give you structure, but it cannot compensate for a culture that avoids bad news, softens uncomfortable conclusions, or prioritizes schedule over uncertainty.
That part is on the organization.

The Standard Assumes More Than It Says

ISO 14971 defines a lifecycle process: identify hazards, estimate and evaluate risks, implement controls, assess residual risk, monitor post-market data.

But the standard assumes something that is not written explicitly.

It assumes that people raise concerns early.
It assumes management is willing to hear uncomfortable conclusions.
It assumes benefit–risk decisions are explored honestly.
It assumes post-market feedback leads to reassessment rather than defensiveness.
It assumes those responsible for risk decisions have enough competence and authority to challenge optimistic assumptions.

Those are cultural conditions.

If they are present, the process works well.
If they are strained, the process can become technically compliant but strategically fragile.

Where Risk Culture Becomes Visible

Risk culture in medical devices rarely announces itself loudly. It shows up in subtle shifts.

Close to verification.
Close to submission.
Close to commercial launch.

That is when trade-offs sharpen.

Language around probability becomes more optimistic.
Severity discussions become more “contextual.”
Mitigations lean more heavily on labeling.

Phrases like:

• “We haven’t seen this in the field,”

• “That’s very unlikely,”

• “We can handle this in the IFU,”

start appearing more often in reviews.

None of this is usually malicious. It is the natural effect of pressure.

But it changes how ISO 14971 is applied.

You can often sense the difference between a residual risk discussion that is analytical and one that is converging toward closure.

That difference is culture.

Leadership Behavior Carries More Weight Than Policy

Every company says patient safety comes first. What shapes risk culture is how leadership behaves when safety conflicts with schedule or cost.

If unresolved safety issues routinely survive because timelines are tight, teams internalize that signal.
If a launch is delayed due to a safety concern and leadership stands behind that decision, teams internalize that too.

Over time, those repeated signals influence:

• how engineers estimate probability,

• how teams frame mitigation strength,

• how openly concerns are escalated.

Policies rarely create culture. Behavior does.

Integration Determines Whether Risk Management Is Alive

In some organizations, risk management is deeply integrated into development. It is present in:

• system architecture discussions,

• software design decisions,

• cybersecurity threat modeling,

• clinical evaluation strategy,

• complaint review and CAPA governance,

• post-market performance reviews.

In others, the risk file progresses alongside the design but not fully within it.

ISO 14971 requires lifecycle thinking. That means risk assessment evolves with design changes and real-world data. When risk management is structurally embedded in governance and design reviews, that evolution happens naturally.

When it is more isolated, the documentation may remain complete, but its influence can weaken.

Residual Risk Is Often the Cultural Stress Test

Residual risk evaluation tends to reveal the true posture of an organization.

In mature environments, these discussions are rigorous. Trade-offs are openly debated. Uncertainty is acknowledged. The benefit–risk rationale feels deliberate.

In more pressured environments, the conversation subtly shifts toward justification. The goal becomes closure rather than exploration.

The numbers may look the same in both cases. The tone is different.

And the tone matters, because it reveals whether uncertainty is something to be acknowledged and managed, or something to be argued away.

That difference influences how future risks are handled.

Post-Market Surveillance Exposes the System

If you want to understand how risk management truly functions in an organization, look at how post-market data is handled.

When new complaint patterns emerge, does the hazard analysis change quickly?
Are assumptions revisited?
Is there openness to re-evaluating previously accepted residual risks?

Just as revealing: when a single, unusual event occurs, can anyone trigger a deeper look, or does it quietly disappear into the database because it doesn’t move the trend line?

ISO 14971 expects continuous reassessment. That expectation only works in an environment that supports learning over defensiveness.

How Leaders Quietly Shape Risk Culture

Three simple, observable behaviors make a disproportionate difference:

• What gets asked in reviews.
  Do design and management reviews ask, “Is the risk file up to date?”
  Or do they ask, “What have we learned about risk since the last review that changes our confidence?”

• How PMS information is used.
  Are complaint summaries and vigilance data treated as a reporting requirement,
  or as input that can change design priorities, labeling, monitoring plans, or even go-to-market strategy?

• Which trade-offs become stories.
  Does the organization remember and retell moments when launches were delayed or features cut for safety reasons. Or only when dates were protected at all costs?

Over time, these patterns of behavior tell teams whether ISO 14971 is a living system, or a set of forms.

Compliance Is a Starting Point

ISO 14971 gives you a defensible framework. Regulators expect you to have it. Patients will never hear its name.

What they experience is the sum of thousands of quiet decisions your organization makes under pressure. How early concerns are raised, how uncomfortable evidence is handled, and whether launch dates ever move when residual risk feels unresolved.

On paper, most medical device companies “do” risk management. The real separation happens in how they behave when:

• the numbers are fuzzy,

• the complaint looks like a one-off,

• or the risk matrix says “acceptable” but the room still feels uneasy.

At that point, ISO 14971 will not make the decision for you. Your culture will.

As a senior leader, you already own the outcome. The only open question is whether you are shaping that culture on purpose or letting schedule pressure, optimism, and silence do it for you.

🧠What’s the clearest sign you’ve seen that a risk file was “compliant” but not truly effective, and what would you do differently now?

Repeated user error is usually a message: the design, the workflow, and real-life conditions are lining up in a way that makes the same failure likely. If you learn to notice that early, you prevent harm. You also build better products, and you build better judgment as a team.

Takeaway

If the same “user error” keeps happening, it’s not noise. It’s a design signal.

Why this matters

We’ve often treated usability and human behavior as “soft.” Something nice to talk about, but not the main event. In practice, it’s one of the biggest drivers of safety outcomes.

Repeated user error is often an early warning sign. You can catch it before it turns into a trend, a field action, or a tough audit discussion. And you don’t need a huge program to start. A quick scan of FDA MAUDE is enough to spot patterns worth looking at.

What repeats

Across many device types, the same stories show up again and again:

• Setup steps get skipped
  People move forward too early because the device looks ready, or the steps are not enforced.
  You’ll often see: “did not confirm,” “skipped step,” “did not perform.”

• Connections look OK but aren’t
  Something feels connected, but it is not fully seated or secure. The wrong port or accessory may be used.
  You’ll often see: “did not latch,” “disconnected,” “leak,” “wrong connection.”

• Alarms don’t help enough
  The alarm is unclear, easy to silence, or does not tell the user what to do first.
  You’ll often see: “alarm ignored,” “silenced,” “did not respond,” “did not understand.”

If you keep seeing the same story, treat it like a warning light, not background noise.

The pattern in real life

Here’s a chain that repeats in many settings:

During setup, the device gives a “looks good” signal even though a required step is not complete. The user moves on.
During connection, an accessory or line is attached in a way that feels secure, but it is not fully latched.
Then an alarm happens, but the message is vague or easy to silence, so the user does not fix the right thing fast enough.

The result can be delayed therapy, incorrect delivery, or harm.

If this chain repeats, treat it as a design signal. The system is allowing the mistake, detecting it too late, or making recovery unclear.

How to scan MAUDE in 20 minutes

This is a quick pattern check, not a research study.

1. Pick your focus
   Setup, connection, alarms, or the chain: setup → connection → alarm response.

2. Use simple search words
   Try: “did not”, “failed to”, “skipped”, “setup”, “connect”, “disconnect”, “latch”, “leak”, “alarm”, “silenced”, “ignored”, “no response”.

3. Stay recent
   Start with the last 12 to 24 months.

4. Grab a small sample
   Take 20 to 50 reports. Copy the key sentence (or the key idea) into a table.

5. Tag fast
   You only need a few tags:

• Step: setup / connection / alarms

• What happened: missed step / incomplete latch / alarm misunderstood

• Likely cause: unclear UI / weak feedback / workflow / environment

• Outcome: near miss / harm

Example (filled in):

• Step: Setup

• Key sentence: User moved forward before a required prep step was completed.

• Outcome: Delay / harm reported

• Hypothesis: Device looked ready too early.

• Action: Add hard stop + clearer readiness confirmation. Test with interruptions.

6. Look for repeats
   Same step. Same mistake. Similar wording. That’s your signal.

What to do with what you find

Do not stop at “people should be more careful.” That’s not a plan. Turn the pattern into a simple hypothesis, then take one concrete action.

Write a one-line hypothesis, like:

• People move past setup because the device looks ready too early.

• The connection can feel secure even when it isn’t fully latched.

• The alarm does not tell the user what to check first.

Then pick actions, like:

• Add a hard stop for critical setup steps.

• Make readiness obvious (clear state, clear confirmation).

• Detect incomplete connections and show clear feedback.

• Improve alarms: what happened + what to do first.

• Add usability tests that include interruptions and alarm recovery.

• Add a trigger: “if this pattern appears X times, we review it.”

Next time someone says “user error,” pause and ask: does it repeat? If yes, treat it as a real signal. That shift alone changes how teams think, how designs improve, and how early risks get addressed.

Sources

• FDA MAUDE: https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfmaude/search.cfm

• FDA Human Factors: https://www.fda.gov/medical-devices/human-factors-and-usability-engineering

Disclaimer
MAUDE reports are a signal source and do not establish root cause for any specific device.