Functional Safety Is Not a Feature. It Is the Architecture.

Functional Safety Is Not a Feature. It Is the Architecture.

Most MedTech teams treat safety as something you add.

A mitigation.
A control.
A line item in the risk file.

But in functional safety, that thinking is backwards.

Safety is not added to the design.
Safety defines the design.

And if you do not let it drive your architecture early, you will spend the rest of the lifecycle compensating for it.

The Silent Gap in MedTech Engineering

In industrial systems, this is explicit.

Standards like ISO 13849-1 and IEC 61508 force a hard linkage between:

• Risk reduction requirements

• Diagnostic capability

• Fault tolerance

• And ultimately, system architecture

Higher risk → higher integrity → different architecture.

No debate.

In MedTech, we operate differently.

ISO 14971 gives us a rigorous process.
But it does not prescribe architecture.

It does not tell you:

• When you need redundancy

• When dual-channel becomes mandatory

• When diagnostics must reach a certain threshold

So, what happens?

Two devices with very different clinical risk profiles often end up with very similar architectures.

That is not a compliance issue.
That is an engineering leadership issue.

Architecture Is the Real Risk Control

If a safety function matters, then the system must be architected to:

• Detect faults

• Tolerate faults

• Respond correctly to faults

That is where functional safety lives.

Not in the risk file.
In the structure of the system.

ISO 13849-1 gives us a powerful lens to think about this.

The Architecture Ladder Most MedTech Teams Never Use

Let’s simplify the categories into engineering reality:

Category B / 1

• Single channel

• Minimal fault tolerance

• Relies on component reliability

• Failure = loss of safety function

Category 2

• Still single channel

• Adds periodic diagnostics

• Detects faults, but does not prevent them in real time

Category 3

• Dual-channel architecture

• Tolerates a single fault

• Introduces real fault resilience

Category 4

• Dual-channel + high diagnostic coverage

• Detects faults before they accumulate

• Designed for high-risk applications

This is not academic classification.

This is a maturity model of how seriously your architecture treats failure.

1oo1 vs 1oo2 vs 2oo2 vs 2oo3: The Tradeoffs You Cannot Avoid

These architectures define how your system makes decisions under uncertainty.

1oo1 (One out of One)

• One path

• No redundancy

• Fast, simple, fragile

1oo2 (One out of Two)

• Redundant channels

• One channel can protect the system

• Strong safety performance

• Higher complexity

2oo2 (Two out of Two)

• Both channels must agree

• Reduces nuisance trips

• Can block safety action if poorly designed

2oo3 (Two out of Three)

• Majority voting

• Balances safety and availability

• Higher system complexity

Here is the uncomfortable truth:

You are always trading between:

• Safety

• Availability

• Complexity

• Cost

If you are not explicitly making this tradeoff, you are making it accidentally.

Single vs Dual Channel: The Illusion of Redundancy

Many MedTech devices claim “redundancy.”

But in reality, they have:

• Two sensors feeding the same processor

• Two software routines running the same logic

• Two channels sharing the same failure mode

That is not redundancy.

That is duplication.

True dual-channel architecture requires:

• Independence

• Separation

• Protection against common cause failure

Otherwise, both channels fail the same way, at the same time.

And your “redundancy” disappears exactly when you need it most.

Diagnostic Coverage: Where Most Designs Fall Apart

Diagnostic Coverage (DC) answers one critical question:

What percentage of dangerous failures do you actually detect?

Not:

• “Do we have a watchdog?”

• “Do we run a self-test?”

But:

• Are we detecting the failures that matter?

• Are we detecting them in time?

Low DC gives you visibility.
High DC gives you protection.

And here is the key insight:

You do not achieve high DC by adding features.
You achieve it by designing the architecture differently.

Cross-monitoring.
Independent validation.
End-to-end verification.

This is where Category 4 systems separate themselves.

Safe State Is Not Always “Off”

One of the most critical, and most misunderstood, design decisions:

What is the safe state of your device?

In some cases, it is obvious.

Safe state = OFF

• Infusion pump stops delivery

• Surgical laser shuts down

But in many MedTech systems, that assumption is wrong.

Safe state = ON

• Ventilator must continue airflow

• Cardiopulmonary bypass must maintain circulation

Turning off is not safe.
It is catastrophic.

This is the dividing line between:

• Fail-safe systems

• Fail-operational systems

And it fundamentally changes your architecture.

The MedTech Reality: No One Will Tell You the Right Architecture

Here is the critical insight:

There is no medical device standard that tells you:

• Use 1oo2

• Use Category 3

• Use dual-channel

You must derive it.

From:

• Hazard severity

• Time to harm

• Detectability

• Clinical context

This is where engineering maturity shows up.

Not in documentation.

In decisions.

Two Devices. Two Opposite Definitions of Safe

This is where functional safety stops being theoretical and becomes architectural reality.

Infusion System (Safe State = OFF)

• Active delivery of medication

• Short time-to-harm in case of over-infusion

• Primary risk: uncontrolled or excessive delivery

• Safe response: stop energy, stop flow

Architecture implication:

• Strong fault detection tied to immediate shutdown

• Emphasis on interruption capability

• Fail-safe design dominates

Ventilator (Safe State = ON)

• Sustains respiratory function

• Immediate harm if airflow stops

• Primary risk: loss of life-support function

• Safe response: continue operation, even in degraded mode

Architecture implication:

• Fault tolerance over simple shutdown

• Redundancy becomes critical

• Fail-operational design dominates

Same clinical environment.
Completely different safety philosophy.

In one system, stopping is safe.
In the other, stopping is the failure.

And that single distinction drives everything:

• Architecture

• Redundancy strategy

• Diagnostic approach

• System behavior under fault

If you define the safe state wrong,
no amount of risk documentation will fix the design.

Final Thought: This Is Where MedTech Must Evolve

MedTech does not need to copy industrial functional safety.

But it must adopt its mindset.

The future is not:

• More documentation

• More risk tables

• More checklists

The future is:

Architecture as a risk control.

The organizations that win will be the ones that can demonstrate:

• The hazard drove the architecture

• Architecture enables detection

• The system responds correctly

• The safe state is intentional

That is how you move from compliant to resilient.

🔶 What Comes Next

In the next article, we will connect this directly to:

FMEA 4.0 and architecture-driven risk modeling

Because if your architecture is not reflected in your DFMEA and PFMEA…

You are not managing risk.

You are documenting it.