MTL-113: Essential Performance and Safety Concepts

What you will learn

By the end of this topic, you should be able to distinguish general performance, basic safety, essential performance and primary functions; determine whether loss or degradation of a clinical function can create unacceptable risk; establish measurable performance limits; and connect those decisions to architecture, risk controls, verification and lifecycle evidence.

Use the right language

Teams often use “safety-critical”, “essential”, “important” and “primary” as if they mean the same thing. They do not. A shared vocabulary prevents regulatory conclusions from becoming disconnected from engineering decisions.

Safety

The condition in which residual risk has been reduced to, and remains at, an acceptable level for the device and its intended use.

Basic safety

Within IEC 60601-1, protection against unacceptable risk arising directly from physical hazards associated with medical electrical equipment in normal and single-fault conditions.

Essential performance

Performance of a clinical function, separate from basic safety, whose loss or degradation beyond defined limits would result in unacceptable risk.

Primary function

A term used by some device-specific standards for functions that are fundamental to the device. The applicable standard may establish a minimum set and its own requirements.

General performance

What the device is intended to do, including functions whose degradation may be inconvenient or commercially important without creating unacceptable risk.

Risk control

A measure selected to reduce risk. It may preserve essential performance, prevent a hazardous situation, provide protection or communicate safety information.

Essential performance is not a list of the device’s most valuable features

It is a risk-based conclusion about clinical functions and the limits beyond which their loss or degradation would make risk unacceptable.

Determine essential performance from risk

Begin with the clinical function, then examine what happens when it is absent, delayed, inaccurate, intermittent, excessive, misleading or otherwise degraded. Follow the sequence through hazardous situation to possible harm.

Clinical functionWhat clinically relevant action or information does the device provide?

Loss or degradationHow can performance depart from its intended behaviour?

Hazardous situationHow could a person become exposed to a source of harm?

Possible harmWhat injury, deterioration or inappropriate clinical action could result?

Risk evaluationWould the risk be unacceptable without maintaining defined performance?

Conclusion and limitsIs the function essential, and within which measurable boundaries?

The analysis must include direct and indirect harm. A monitor that provides no energy to the patient may still create serious risk through a missed alarm. An analyser may cause harm through a misleading result. A connected system may degrade a clinical function through delayed, lost or corrupted data.

Can a device have no essential performance?

Yes. Within an IEC 60601-1 assessment, a manufacturer may conclude that no clinical function has essential performance if loss or degradation of every relevant function still leaves risk acceptable. That conclusion must be supported by the risk-management process and remain consistent with applicable collateral and particular standards.

The reasoning must not be circular. If maintaining a performance limit is itself necessary to reduce a risk to an acceptable level, that performance remains essential. The fact that residual risk is acceptable after the control is applied does not make the essential performance disappear.

A device-specific standard may also identify particular functions or minimum performance expectations. Those requirements cannot be dismissed merely because the manufacturer would prefer a different risk conclusion.

Define clinically meaningful performance limits

“The device shall maintain essential performance” is not a usable requirement. The manufacturer must define the point at which degradation becomes clinically unsafe, then translate it into testable engineering limits.

Accuracy, precision, repeatability, resolution and drift.
Minimum and maximum output, delivery rate, force, pressure or energy.
Response time, latency, alarm delay, sampling interval and data age.
Availability, continuity, interruption duration and recovery time.
Detection limits, false-positive and false-negative performance.
Permitted operating modes, environmental conditions and configurations.
Behaviour at boundaries, during transitions and under foreseeable disturbances.
Fault detection, protective action, user notification and safe continuation or shutdown.

Limits should come from clinical need and risk, not solely from what the prototype happens to achieve. They may be informed by standards, clinical evidence, state of the art, usability work, scientific validity, manufacturing capability and measurement uncertainty.

Safe does not always mean stopped

For active therapy, sample processing or a controlled movement, immediate shutdown may introduce greater risk. Define the required behaviour for the actual clinical sequence and hazardous situation.

Build a coherent safety concept

A safety concept is the organised explanation of how the device prevents unacceptable risk. It connects intended purpose and foreseeable use to safety goals, architecture, requirements, risk controls and objective evidence.

Safety context

Device purpose, users, patients, environments, clinical workflow, system boundary, external dependencies and assumptions.

Safety goals

High-level outcomes that must be preserved, such as preventing unintended therapy or ensuring clinically significant faults become detectable.

Safety functions

Clinical and protective functions, their required limits, operating states, fault responses and dependencies.

Safety architecture

Allocation, independence, monitoring, redundancy, diversity, containment and control of common-cause failures.

Operational measures

User actions, training, maintenance, installation, production controls, service activities and information for safety.

Assurance evidence

Analyses, reviews, traceability, verification, validation, production acceptance and post-market monitoring.

The safety concept need not be one mandatory document unless the organisation or applicable standard requires it. What matters is that the reasoning is coherent, controlled and easy to navigate. A concise safety-concept document can be valuable as the integrating view across the risk file, system architecture and verification evidence.

See MTL-105 — Medical-device Risk Management for the broader risk-management process.

Make safety visible in the architecture

Essential-performance and safety conclusions must influence the system design. Risk controls scattered across requirements without an architectural rationale are difficult to review and vulnerable to common-cause failure.

Allocate every safety function and performance limit to identified system elements.
Show sensing, decision, actuation, indication and protective paths.
Define independence where one function monitors or protects another.
Identify shared power, clocks, processors, data, components and external services.
Specify interface behaviour for normal, boundary, degraded and fault conditions.
Define permitted modes, state transitions, priority and recovery.
Control latent faults, diagnostic coverage and proof-test or maintenance intervals.
Address cybersecurity conditions that can affect safety or essential performance.
Trace architectural measures to risks, requirements and verification evidence.

A claimed independent monitor is not independent if it relies on the same corrupted data, power rail, clock, software component or calibration value as the function it monitors. Independence must be argued at the level needed by the risk.

See MTL-112 — Systems Engineering, Architecture and Interfaces for system allocation, states and interface control.

Practical examples

Infusion device

Protection against electric shock is basic safety. Delivery accuracy or prevention of unintended delivery may be essential performance where deviation can expose the patient to unacceptable risk.

Patient monitor

Measurement accuracy, alarm generation or alarm latency may be essential when degradation could delay necessary clinical intervention.

IVD analyser

Result accuracy, sample identity or detection of invalid conditions may be safety-significant because an erroneous result can lead to inappropriate treatment.

Needle-based injector

ISO 11608-1 treats dose delivery as a primary function at minimum. The applicable requirements and risk analysis establish performance limits and any additional primary functions.

Connected therapy system

A device may deliver safely without the cloud, while a remote-control or dose-calculation function could make communication integrity, latency or availability safety-significant.

Convenience feature

Loss of a non-clinical history display may frustrate users but is not essential performance unless the resulting sequence can lead to unacceptable risk.

The same function can have different safety significance in different products. Context, indication, patient population, user capability, environment, clinical detectability and available intervention all matter.

Develop and maintain the concept across the lifecycle

Essential performance is not a label added before electrical-safety testing. It develops with the product definition and must remain current as architecture, evidence and field knowledge mature.

Define the medical purpose

Start with the intended purpose, patient population, users, use environments, clinical workflow and claims. These establish which functions have clinical significance.

Typical evidence: Intended-purpose statement, user and environment definitions, clinical workflow, claims and foreseeable-use scenarios.

Identify clinical functions

List the functions that diagnose, monitor, treat, compensate, warn, measure or otherwise contribute to the intended medical benefit.

Typical evidence: Functional analysis, operating concept, use scenarios and a clear distinction between clinical and supporting functions.

Analyse loss and degradation

Consider absence, delay, inaccuracy, intermittency, excess output, unintended operation, corrupted information and misleading indication for each function.

Typical evidence: Hazard analysis, failure scenarios, sequence of events, foreseeable misuse and affected users or patients.

Determine safety significance

Decide whether each degraded state could lead to unacceptable risk, taking account of severity, probability, detectability, clinical intervention and exposure.

Typical evidence: Risk estimates, acceptability decisions, clinical rationale, assumptions and links to the risk-management file.

Set performance limits

For safety-significant functions, define measurable boundaries within which performance remains clinically acceptable and risk stays controlled.

Typical evidence: Quantified limits, tolerances, timing, accuracy, alarm, availability, environmental and fault-condition requirements.

Implement the safety concept

Allocate prevention, protection, monitoring, independence, fault response and information measures across hardware, software, users and external systems.

Typical evidence: Safety goals, architecture, risk-control requirements, interface specifications, fault responses and design rationale.

Verify and maintain

Demonstrate the required performance in representative normal, abnormal and fault conditions, then reassess it when the device or field knowledge changes.

Typical evidence: Verification and validation results, fault testing, configuration records, production controls, change assessments and post-market review.

Verification, validation and evidence

Verification should show that essential performance and safety measures work at the element, interface and complete-system levels. Validation should confirm that the resulting behaviour supports intended users and intended use in representative conditions.

Identify each essential-performance requirement and its clinical or risk rationale.
Use representative hardware, software, accessories, configurations and production state.
Test across specified environmental, supply, load and operating boundaries.
Apply relevant normal-condition, single-fault, abnormal-use and disturbance scenarios.
Challenge detection, annunciation, protective action, recovery and data persistence.
Confirm that safety controls do not introduce new unacceptable risks.
Account for measurement uncertainty when results approach acceptance limits.
Record deviations, anomalies and the exact configuration to which conclusions apply.
Trace every claimed safety measure to implementation and effectiveness evidence.

For medical electrical equipment, the risk-management file should make the essential-performance determination available to the IEC 60601 assessment. The test laboratory can test declared limits and conditions, but it cannot invent the manufacturer’s clinical risk rationale.

See MTL-106 — Verification and Validation for planning and organising objective evidence.

Common misconceptions

“Every intended function is essential performance.”

No. Only clinical functions whose loss or degradation beyond defined limits would create unacceptable risk meet the concept.

“No essential performance means no safety work.”

No. Basic safety, other hazards, usability, software, cybersecurity and general risk controls still require appropriate analysis and evidence.

“Acceptable residual risk means the function is no longer essential.”

No. If maintaining that function or limit is part of what makes the risk acceptable, the essential-performance designation remains.

“The test laboratory decides essential performance.”

No. The manufacturer establishes the clinical and risk rationale; the laboratory assesses and tests the applicable declared requirements.

“A safe state always means switching off.”

No. The safest response can be controlled continuation, completion of a safe step, degraded operation, alarm, recovery or shutdown depending on context.

“Primary function and essential performance are interchangeable.”

No. They come from different standards contexts. Determine what the applicable product standard requires and preserve the distinction in the evidence.

Essential-performance practical checklist

Define intended purpose, users, environments, clinical workflow and system boundary.
List every clinical function and its supporting dependencies.
Analyse complete loss, partial degradation, delay, excess, intermittency and misleading output.
Connect each failure condition to hazardous situations, harms and risk evaluation.
Identify functions whose defined performance is required to keep risk acceptable.
Check applicable general, collateral, particular and device-specific standards.
Define measurable, clinically justified limits and operating conditions.
Allocate safety measures through a coherent system architecture.
Verify implementation and effectiveness in representative normal and fault conditions.
Maintain the determination through changes, production and post-market learning.

Authoritative starting points

Apply the editions, amendments, national adoptions and product-specific standards required for the target markets and device. Definitions and mandatory performance requirements should always be checked in the controlled standards available to the organisation.