IEC 60601-1-10 is the collateral standard for physiologic closed-loop controllers (PCLCs) in medical electrical equipment. If your device measures a patient variable and automatically adjusts therapy based on that measurement — insulin pump with CGM input, ventilator with end-tidal CO2 control, anesthesia depth monitoring — this standard defines the lifecycle activities, validation, and failure-mode analysis you must complete.

By Tibor Zechmeister and Felix Lenhard.

TL;DR

  • IEC 60601-1-10 applies to devices where a physiologic variable is measured, compared to a setpoint, and used to automatically adjust therapy.
  • Typical examples: automated insulin delivery, closed-loop ventilation, target-controlled anesthesia infusion, automated blood pressure control.
  • The standard defines a development lifecycle — requirements, design, verification, validation, risk management — specific to the controller.
  • MDR Annex I §14 and §17 are the legal anchors; §22 on devices used by lay persons adds obligations for home-use closed-loop systems.
  • Risk management under EN ISO 14971:2019+A11:2021 must explicitly address controller failure modes: sensor drift, actuator saturation, algorithm divergence, communication loss.
  • These devices are almost always Class IIb or III under MDR Annex VIII, depending on the invasive pathway and therapy type.
  • Validation must demonstrate stable, safe control across the full range of patient physiology, not just a nominal patient.

Why this matters

Closed-loop control is the most dangerous feature you can add to a medical device. The moment the device starts adjusting therapy without a human in the loop, the failure modes become cascade failures. A continuous glucose monitor reading 20 percent low for 15 minutes is an annoyance. An insulin pump acting on a continuous glucose monitor reading 20 percent low for 15 minutes is a medical emergency.

We have seen three startups in the past two years build promising closed-loop prototypes and then discover at Month 10 that they had no structured framework for validating the control loop. They had validated the sensor. They had validated the actuator. They had not validated the loop as a system with a patient in it. IEC 60601-1-10 is the framework that prevents exactly this gap.

It is not a lightweight standard. It sits on top of EN 60601-1, EN 62304 for software, and EN ISO 14971 for risk management. You do not get to choose between them — you need all of them, and IEC 60601-1-10 coordinates how they integrate for the control loop specifically.

What MDR actually says

MDR Annex I lays down the obligations that closed-loop controllers must meet:

§14 (Construction of devices and interaction with their environment) requires devices to be designed and manufactured in such a way that, when used under normal conditions, they are suitable for their intended purpose. For a closed-loop controller, "normal conditions" includes the full expected range of patient physiology, sensor noise, and actuator variability.

§17 (Electronic programmable systems — devices that incorporate electronic programmable systems and software that are devices in themselves) requires such systems to be designed to ensure repeatability, reliability and performance in line with their intended use. In the event of a single fault condition, appropriate means shall be adopted to eliminate or reduce as far as possible consequent risks or impairment of performance. This is the direct legal hook for fault-tolerant controller design.

§22 (Protection against the risks posed by devices intended by the manufacturer for use by lay persons) adds obligations when the device is used by a non-professional — a person with diabetes wearing a hybrid closed-loop system at home. The device must reduce the risk of incorrect use resulting from ergonomic features and the environment in which the device is intended to be used.

IEC 60601-1-10 is the collateral standard in the EN 60601-1 family that operationalises these requirements for physiologic closed-loop control specifically. It defines the development lifecycle, the risk-based design approach, the verification and validation activities, and the documentation expected.

The standard interacts with three other standards you will also need: - EN 60601-1:2006+A1+A12+A2+A13:2024 for general basic safety and essential performance. - EN 62304:2006+A1:2015 for the software lifecycle of the controller software. - EN ISO 14971:2019+A11:2021 for the risk management process that drives controller design decisions.

Together, these four standards are the backbone of closed-loop controller compliance under MDR.

A worked example

A startup is building a Class III automated insulin delivery (AID) system: a continuous glucose monitor (sensor), a control algorithm (software), and an insulin pump (actuator). Intended use is adult patients with Type 1 diabetes, home use, 24/7 operation.

Here is how IEC 60601-1-10 structures their development.

Phase 1: Define the controlled variable and the setpoint range. Controlled variable: blood glucose, 70-180 mg/dL target range. Measurement via CGM with known accuracy: MARD ≤9 percent across the relevant range. Setpoint adjustable by user within clinical guardrails (e.g., 100-130 mg/dL).

Phase 2: Define essential performance of the controller. Essential performance: maintain blood glucose within target range ≥70 percent of the time, with hypoglycemia (<54 mg/dL) occurring less than 1 percent of time-in-range, based on validation in simulated patient populations and clinical investigation per MDR Chapter VI.

Phase 3: Risk management — controller-specific failure modes. The team lists failure modes that are unique to closed-loop operation: - Sensor drift over wear time (day 7 vs day 1) - Sensor noise during exercise or compression - Loss of CGM-to-pump Bluetooth connection - Insulin absorption variability (site, temperature, activity) - Algorithm divergence under rapidly changing glucose - User override conflicts (manual bolus during automated mode) - Occlusion in pump actuator during sustained high-rate delivery

Each failure mode gets a risk analysis per EN ISO 14971:2019+A11:2021 and a design control. For example: on loss of CGM signal for >20 minutes, the controller reverts to a pre-programmed safe basal rate and alarms the user.

Phase 4: Develop and verify the control algorithm. Software is developed per EN 62304:2006+A1:2015 Class C (software contributing to a hazardous situation that could result in death or serious injury). This drives the full lifecycle: software development plan, requirements, architecture, unit design, implementation, unit verification, integration testing, system testing, problem resolution.

Phase 5: Validate the closed-loop system. This is where IEC 60601-1-10 adds structure beyond EN 62304. Validation is not just "the algorithm does what the spec says". It is "the closed loop, under the full range of patient physiology and environmental conditions, produces safe and effective therapy".

The team performs: - In silico validation using a validated virtual patient population (e.g., the UVA/Padova simulator, which is FDA-accepted for preclinical AID validation). - Bench validation with CGM simulators and pump emulators. - Clinical investigation under EN ISO 14155:2020+A11:2024 and MDR Chapter VI — first a supervised inpatient study, then a home-use pivotal study.

Phase 6: Document for the technical file. Everything lands in Annex II: system description, risk management file, software file, verification and validation reports, clinical evaluation report, IFU with clear guardrails for lay users, training materials.

The notified body review will scrutinise this technical file intensively. AID systems are not devices you certify on a thin dossier.

The Subtract to Ship playbook

Closed-loop controllers cannot be subtracted down to a lean MVP the way a simple wearable can. The risk profile does not permit it. But you can still avoid unnecessary work by sequencing correctly.

Do not build the full closed loop on Day 1. Build the sensor path first. Validate it to its own specification. Build the actuator path separately. Validate it. Only then integrate them under IEC 60601-1-10 discipline. If you try to build all three subsystems simultaneously and integrate them at the end, you will have no idea which subsystem is causing which failure during validation.

Define essential performance before you write the first line of control code. If you cannot state "the controller is successful if X happens Y percent of the time under conditions Z", you are not ready to start development. This is the single most common gap we see.

Use validated simulators before touching a patient. For glycemic control, the UVA/Padova simulator is the gold standard. For ventilation, there are validated lung models. For anesthesia, there are published PK/PD models. In silico validation is cheap, fast, and catches 80 percent of algorithm bugs before clinical exposure.

Keep the user (or clinician) in the loop on the top three failure modes. Even in "fully automatic" mode, build in manual overrides, alarms, and a clear fallback to a safe default. MDR §17 requires it; IEC 60601-1-10 structures it; EN 62366-1:2015+A1:2020 (usability) validates that the user can actually execute the override.

Treat the control algorithm as a software item of the highest safety class under EN 62304. For insulin delivery and ventilation, this is almost always Class C. Do not argue it down to Class B to save work. The notified body will not accept it and the clinical risk is real.

Plan your clinical investigation early and budget it honestly. Closed-loop pivotal studies for Class III devices run 500,000 to 3,000,000 EUR and 12-24 months. This is not where you save money.

File a pre-submission meeting request with your notified body. For novel closed-loop devices, a pre-submission conversation about your validation strategy, clinical plan and risk management approach saves months of back-and-forth later.

Reality Check

  1. Can you write a single sentence describing the controlled variable, the actuator, and the essential performance of your closed-loop system?
  2. Have you listed at least 10 failure modes specific to the closed loop (not just to the sensor or the actuator individually)?
  3. Is your control algorithm software classified as EN 62304 Class C, or are you hoping to get away with Class B?
  4. Do you have a validated simulator or virtual patient model you can use for in silico validation before clinical exposure?
  5. Does your risk management file include explicit control measures for sensor dropout, actuator saturation, and communication loss?
  6. If the controller detects an unexpected condition, does it revert to a defined safe state, and have you validated that transition?
  7. Have you scheduled a pre-submission meeting with your notified body to discuss validation strategy for the closed loop specifically?
  8. Is your clinical investigation plan designed to test the controller across the full range of expected patient physiology, not just a nominal patient?

Frequently Asked Questions

Does IEC 60601-1-10 apply to software-only devices (SaMD) with closed-loop control? The standard was originally scoped to medical electrical equipment, so . In practice, if your SaMD implements a physiologic closed-loop control function, notified bodies will expect the same design and validation rigour regardless of whether the standard is formally applicable.

Is IEC 60601-1-10 on the EU harmonised standards list? . If it is not harmonised, it does not grant presumption of conformity, but it remains state of the art and notified bodies treat it as the expected framework.

What is the difference between feedback control and closed-loop physiologic control? Feedback control is a general engineering concept (a thermostat, a PID loop). Physiologic closed-loop control is specifically where the controlled variable is a patient physiologic measurement and the actuator delivers therapy to that patient. IEC 60601-1-10 applies only to the latter.

Can I use off-the-shelf control algorithms (PID, model predictive control) in a medical device? Yes, but they are SOUP (software of unknown provenance) under EN 62304:2006+A1:2015. You must evaluate them, document their behaviour, and take responsibility for their integration into the safety-critical path.

How does MDR classification apply to closed-loop devices? Usually Rule 11 (software), Rule 22 (active therapeutic devices intended to administer or remove medicines), or Rule 9 (active therapeutic devices intended to exchange energy with the patient) under MDR Annex VIII. Most closed-loop devices land in Class IIb or III.

Do I need a clinical investigation for a closed-loop device? Almost always yes, unless you can demonstrate equivalence per MDCG 2020-5 to an existing closed-loop device — which is a high bar for novel algorithms. Expect to run a clinical investigation per MDR Chapter VI and EN ISO 14155:2020+A11:2024.

Sources

  1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I, §14, §17, §22.
  2. IEC 60601-1-10 — Medical electrical equipment — Part 1-10: General requirements for basic safety and essential performance — Collateral Standard: Requirements for the development of physiologic closed-loop controllers .
  3. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment — Part 1: General requirements for basic safety and essential performance.
  4. EN 62304:2006+A1:2015 — Medical device software — Software lifecycle processes.
  5. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.