---
title: MDR Requirements for PEMS: Programmable Electrical Medical Systems via IEC 60601-1
description: PEMS sit at the intersection of EN 60601-1 and EN 62304. Here is how the two standards combine for programmable electrical medical systems under MDR.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: MDR PEMS IEC 60601-1
canonical_url: https://zechmeister-solutions.com/en/blog/mdr-pems-iec-60601-1
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Requirements for PEMS: Programmable Electrical Medical Systems via IEC 60601-1

*By Tibor Zechmeister (EU MDR Expert, Notified Body Lead Auditor) and Felix Lenhard.*

> **A Programmable Electrical Medical System (PEMS) is a medical electrical device or system that contains a programmable electronic subsystem — typically a microcontroller, an embedded processor, or an on-device computer running software that influences basic safety or essential performance. Under MDR, PEMS sit at the intersection of two harmonised standards: EN 60601-1:2006+A1+A12+A2+A13:2024, whose Clause 14 defines the PEMS development process at the system level, and EN 62304:2006+A1:2015, which defines the software lifecycle processes for the software inside that system. Clause 14 tells you what the overall PEMS has to prove. EN 62304:2006+A1:2015 tells you how the software component gets built to support that proof. Both standards then map back to MDR Annex I Sections 14, 17, and 18. Treating them as two separate silos is the single most common mistake founders make on programmable devices — and the single most expensive one to fix late.**

**By Tibor Zechmeister and Felix Lenhard. Last updated 10 April 2026.**

---

## TL;DR

- A PEMS is a medical electrical system that contains a programmable electronic subsystem whose behaviour contributes to basic safety or essential performance. Most modern Class IIa and Class IIb electrical devices meet this definition.
- EN 60601-1:2006+A1+A12+A2+A13:2024 Clause 14 defines the PEMS development process at the system level — requirements specification, risk management, architecture, verification and validation, and a PEMS development life-cycle file.
- EN 62304:2006+A1:2015 defines the software lifecycle processes for the software component — software safety classification (Class A, B, C), development planning, requirements, architecture, unit implementation, integration, system testing, and release.
- Clause 14 and EN 62304:2006+A1:2015 are complementary, not duplicative. Clause 14 owns the system boundary; EN 62304:2006+A1:2015 owns the software boundary. Both sit inside a single EN ISO 14971:2019+A11:2021 risk management file.
- The whole structure traces to MDR Annex I Sections 14, 17, and 18. No Annex I section says the word "PEMS", but Section 17 on electronic programmable systems is the direct legal anchor.

---

## Why PEMS is the concept that ties hardware and software together

Most of the electrical devices coming out of European startups today have a microcontroller, an RTOS or a Linux stack, and firmware that decides what the device does. The device might also talk to a mobile app, a cloud backend, and a hospital network. On paper, that is five or six different engineering domains. On the test bench, it is one device that either keeps the patient safe or does not.

PEMS is the vocabulary EN 60601-1:2006+A1+A12+A2+A13:2024 uses to handle this reality. Rather than pretending the electronics, the firmware, and the system integration can be certified independently, the standard defines a system-level concept — the Programmable Electrical Medical System — and requires the manufacturer to treat the combined hardware and software as one artifact with one risk story. The software details then get handed off to EN 62304:2006+A1:2015, which covers the software lifecycle in depth. But the software lifecycle file does not stand alone. It lives inside the PEMS story.

Founders who skip this framing end up with two disconnected files — a hardware test report on one side, a software lifecycle file on the other — and no document that ties them together. The Notified Body reviewer asks where the system-level architecture sits. Silence. That silence is a finding, and the finding blocks certification until the PEMS story gets written retroactively. Writing it retroactively is possible. It is also expensive and uncomfortable, and the design decisions it would have shaped are already frozen.

## What qualifies as a PEMS

EN 60601-1:2006+A1+A12+A2+A13:2024 defines a PEMS as a medical electrical system that contains one or more programmable electronic subsystems (PESS). A programmable electronic subsystem is a subsystem based on one or more central processing units (CPUs), including the associated software and interfaces.

In practice, this catches almost any modern electrical medical device. A patient monitor with an embedded ARM processor running firmware that filters the ECG signal — PEMS. An infusion pump with a microcontroller driving the motor and enforcing the dose limits — PEMS. A bedside ventilator with a Linux-based control stack — PEMS. A handheld diagnostic device with a Bluetooth radio and an RTOS — PEMS. A therapy device whose FPGA runs firmware generating the output waveform — PEMS.

The narrow exceptions are fully analog devices with no processor at all, and devices where the processor is so simple and so isolated from safety-relevant functions that the manufacturer can justify in the risk file that it does not contribute to basic safety or essential performance. Those justifications exist, but they are rarer every year. The safe default assumption for a modern electrical device with a CPU is that it is a PEMS and the Clause 14 process applies.

Getting this determination in writing early is non-negotiable. The determination shapes the development plan, the test scope, and the technical file structure. Teams that deliberate on it for a month at the end of the project waste weeks reconstructing documents that should have been produced in real time.

## Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024 — what the standard asks for at the system level

Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024 is the clause that defines the PEMS development process. It does not specify individual tests. It specifies a structured development and documentation process that the manufacturer must follow for the system as a whole. The clause is organised around a small number of deliverables.

**A PEMS development life-cycle.** The manufacturer must establish, document, and maintain a development life-cycle for the PEMS. The life-cycle must cover planning, requirements specification, architecture, design and implementation, verification, validation, release, and post-market activities. The life-cycle is not mandated to follow a specific model (waterfall, V-model, incremental) — but it must be defined, documented, and actually followed.

**Risk management integrated with the life-cycle.** Clause 14 explicitly requires PEMS risk management to be performed in accordance with the risk management process of the standard, which in turn hooks into EN ISO 14971:2019+A11:2021. Every development life-cycle stage produces inputs to the risk file; every risk control implemented in hardware or software produces evidence back into the development file.

**A PEMS requirements specification.** The standard requires a written specification of what the PEMS has to do, including inputs, outputs, interfaces, performance, operating environment, and the risk control measures allocated to the PEMS. This specification is the single document from which basic safety and essential performance are traced down into subsystem and software requirements.

**Architecture.** The standard requires a PEMS architecture document that describes how the system is decomposed into subsystems, how the subsystems interact, which subsystems implement which risk control measures, and which subsystems are programmable (and therefore trigger EN 62304:2006+A1:2015 downstream). The architecture is where the hardware-software boundary gets drawn.

**Verification and validation.** The standard requires verification that each PEMS requirement has been met and validation that the PEMS fulfils its intended use. Both activities produce records that feed the technical file.

**A PEMS development life-cycle file.** All of the above is collected in a single file — conceptually analogous to a design history file, organised around the PEMS. This file is what the Notified Body reviewer asks for first when the device is programmable. Its absence is what the Notified Body writes up when it is missing.

Clause 14 does not replace the rest of the standard. Basic safety tests under the electrical, mechanical, thermal, and radiation clauses still happen. Clause 14 adds the system-level development discipline on top of those tests, because a programmable device can fail through a software defect in ways a pure hardware test regime would never catch.

## Where EN 62304:2006+A1:2015 takes over — the software lifecycle

EN 62304:2006+A1:2015 is the harmonised standard for medical device software lifecycle processes. It covers what the PEMS standard hands off at the software boundary: how the software component inside the PEMS gets built, tested, and released.

The standard organises its requirements around software safety classification. Every software item in a medical device is assigned to one of three classes:

- **Class A** — no injury or damage to health is possible from a software failure.
- **Class B** — non-serious injury is possible from a software failure.
- **Class C** — death or serious injury is possible from a software failure.

The classification is risk-based and flows from the EN ISO 14971:2019+A11:2021 risk file, not from a guess. Once assigned, the class determines the depth of the lifecycle activities required. Class A software has the lightest obligations. Class C software has the full set — detailed software architecture, unit implementation and verification, integration testing, software system testing, traceability from requirements to tests, and formal release activities.

The processes EN 62304:2006+A1:2015 defines include software development planning, software requirements analysis, software architectural design, software detailed design (for Class C), software unit implementation and verification, software integration and integration testing, software system testing, and software release. It also defines software maintenance, software risk management, software configuration management, and software problem resolution as ongoing processes that continue after the first release.

Crucially, EN 62304:2006+A1:2015 assumes a risk management system already exists — it does not define the risk management method itself. The standard points to EN ISO 14971:2019+A11:2021 as the source, and its software classification depends on hazards identified under that risk process. Software lifecycle without an active risk file is a compliance illusion.

## How Clause 14 and EN 62304:2006+A1:2015 fit together

The simplest mental model: Clause 14 owns the system; EN 62304:2006+A1:2015 owns the software inside the system. The boundary between them is the PEMS architecture document.

Clause 14 asks: what does the programmable system as a whole have to do, and how do we prove it does it safely? The answer lives in the PEMS requirements specification, the PEMS architecture, the PEMS verification and validation records, and the PEMS development life-cycle file.

EN 62304:2006+A1:2015 asks: for the software component inside that system, how do we plan, build, test, and maintain the software so that it supports the PEMS-level safety and performance claims? The answer lives in the software development plan, software requirements, software architecture, unit and integration and system test records, and the software release file.

The two files reference each other. The PEMS requirements specification allocates requirements to the software item. The software requirements specification accepts those allocations and traces them down. A risk control measure identified at the PEMS level — for example, "a watchdog must reset the motor driver if the control loop fails to update within 100 ms" — becomes a software requirement whose implementation is verified under EN 62304:2006+A1:2015 and whose effectiveness is validated under Clause 14.

When the Notified Body reviewer walks the technical file, they read vertically: from the MDR Annex I obligation, to the PEMS requirement, to the software requirement, to the software test record, to the PEMS-level validation. That vertical trace is what the two standards together produce when they are applied as one system. It is what two disconnected files cannot produce at all.

## Risk management integration — one file, not two

Teams sometimes assemble a hardware risk file and a separate software risk file. That is not what either standard requires, and it produces trouble downstream.

EN ISO 14971:2019+A11:2021 is the risk management standard for the whole device. Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024 requires PEMS risk management to be performed within that process. EN 62304:2006+A1:2015 requires software risk management to be integrated into the same process. The result is one risk management file with one hazard list, one set of risk controls, and one residual risk evaluation — containing hardware-implemented controls, software-implemented controls, and information-for-safety controls side by side.

A single hazard — "motor delivers more current than intended" — might have one hardware control (a current-limiting resistor), one software control (a firmware limit check), and one information control (a warning in the IFU). These three controls sit together under the same hazard entry in the risk file, traceable to the same Annex I obligation. That is the structure the Notified Body expects.

## The hardware-software boundary — where design decisions get made

The hardware-software boundary is where the PEMS architecture earns its keep. Every risk control measure has to sit on one side of the line or the other, and the decision has cost and risk consequences.

Putting a control in hardware is often more robust — a mechanical limit switch, a fuse, an analog comparator — but it is harder to change after the PCB is tooled. Putting a control in software is cheaper and more flexible, but it inherits the full weight of EN 62304:2006+A1:2015 activities for the class of software that implements it. A safety-critical control in software on a device with Class C software means formal unit-level verification and integration testing against the specific safety function. Teams that default to "we will do it in firmware" without understanding what that choice adds downstream often double the software work.

The discipline is to make hardware-software allocation decisions explicitly, in the architecture document, with the risk file and the software class in view. Subtract to Ship applied here means pushing controls to the side of the boundary where the total cost — hardware BOM plus software lifecycle burden plus change control — is lowest for the same residual risk. Sometimes that is hardware. Sometimes software. The decision should be defensible, not accidental.

## Common gaps in PEMS files

A short list of the gaps that show up repeatedly in Notified Body findings on programmable devices.

- **No PEMS determination in writing.** The device is clearly a PEMS, but the file contains no statement saying so. The reviewer flags the absence; the team writes the determination retroactively; everything in the file has to be reconciled against the new framing.
- **No PEMS development life-cycle file.** A hardware file exists, a software file exists, but the system-level Clause 14 file does not. The reviewer reads two disconnected stories and cannot trace the safety argument top to bottom.
- **Software classification done by guess.** Class assigned as A or B without a documented trace to the risk file. The reviewer asks for the trace and does not get one.
- **Risk files that do not cross the boundary.** Hardware risks in one file, software risks in another, with no shared hazard list. Residual risk cannot be evaluated for hazards that have mixed controls.
- **Architecture document that stops at block diagrams.** No allocation of risk controls to subsystems. No identification of which subsystems are programmable and which are not. The hardware-software boundary is not drawn.
- **EN 62304:2006+A1:2015 evidence without traceability to PEMS requirements.** Unit tests and integration tests exist, but they cannot be traced to specific software requirements, and those requirements cannot be traced back to PEMS-level safety and performance claims. The lifecycle exists; the trace does not.

Each of these gaps is preventable at planning time. None of them is cheap to fix at audit time.

## The Subtract to Ship angle on PEMS

The PEMS framing is where the instinct to add every possible document collides hardest with the constraint of actually shipping. Clause 14 and EN 62304:2006+A1:2015 together define a lot of documents — and a resource-constrained startup has to be precise about which ones are required for the device at hand, at the software class that genuinely applies, against the hazards that genuinely exist.

The subtraction moves that work:

- **Classify the software honestly and narrowly.** If the risk file supports Class B, do not do Class C activities just to look thorough. Class C activities cost real engineering time, and adding them without a corresponding hazard is waste. If the risk file supports Class A for a given software item, the lifecycle burden for that item is much smaller.
- **Write the PEMS file as one file, not a pile.** One requirements specification, one architecture, one verification and validation summary, one life-cycle file — tied to one risk file. Reviewers read this faster; the team maintains it faster; change control is cheaper.
- **Allocate risk controls to the cheapest defensible side of the boundary.** Hardware when change flexibility does not matter and robustness does. Software when the class is low and change flexibility is worth the lifecycle burden. Never default.
- **Do not duplicate evidence across Clause 14 and EN 62304:2006+A1:2015.** A software system test that validates a PEMS-level requirement can serve both files with one record, if the record is structured to reference both. Two parallel test campaigns testing the same thing is the purest form of additive waste.

The obligation is MDR Annex I — Sections 14, 17, and 18. Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024 and EN 62304:2006+A1:2015 are the tools that let you prove the obligation efficiently when the device is programmable. Keep the direction straight between the Regulation and the standards, and the PEMS work becomes a single coherent story instead of two files that do not meet.

## Reality Check — Where do you stand?

1. Have you written down whether your device is a PEMS, with a justification tied to the presence or absence of a programmable subsystem that affects basic safety or essential performance?
2. Do you have a single PEMS development life-cycle file, or do you have a hardware file and a software file with no document that ties them together?
3. Is your software safety classification (Class A, B, or C) traced back to specific hazards in your EN ISO 14971:2019+A11:2021 risk file?
4. Does your PEMS architecture document explicitly identify which subsystems are programmable and allocate each risk control measure to a specific subsystem?
5. Can you trace a single Annex I safety obligation through a PEMS requirement, a software requirement, a software test, and a PEMS-level validation record?
6. Is your risk management file one file — hardware, software, and information controls side by side — or is it split across files that do not talk to each other?
7. Have you made the hardware-software allocation decisions for your safety-critical functions deliberately, with cost and lifecycle burden in view, or did the defaults just happen?

## Frequently Asked Questions

**Is every medical electrical device with a microcontroller automatically a PEMS?**
In practical terms, yes. EN 60601-1:2006+A1+A12+A2+A13:2024 defines a PEMS as a medical electrical system containing a programmable electronic subsystem, and a programmable electronic subsystem is any CPU-based subsystem with its software and interfaces. A microcontroller qualifies. The narrow exceptions require a written justification in the risk file that the processor does not contribute to basic safety or essential performance, and those justifications are rare for modern devices.

**Do I need both EN 60601-1:2006+A1+A12+A2+A13:2024 and EN 62304:2006+A1:2015, or can I pick one?**
You need both, and they cover different scopes. EN 60601-1:2006+A1+A12+A2+A13:2024 Clause 14 covers the PEMS at the system level — requirements, architecture, verification, validation, life-cycle file. EN 62304:2006+A1:2015 covers the software component inside the PEMS — software planning, requirements, architecture, implementation, testing, release. The two are complementary. Notified Bodies expect both for programmable devices.

**What is the relationship between PEMS software and SaMD?**
They are different categories. SaMD (Software as a Medical Device) is software that performs a medical function without being part of a hardware medical device — for example, a diagnostic app running on a general-purpose phone. PEMS software is software that is part of a medical electrical device — for example, the firmware inside a patient monitor. SaMD does not trigger EN 60601-1:2006+A1+A12+A2+A13:2024 because there is no medical electrical equipment involved. PEMS software does, because the software is inside electrical equipment. Both categories use EN 62304:2006+A1:2015 for the software lifecycle.

**Who decides the software safety class under EN 62304:2006+A1:2015?**
The manufacturer decides, based on the EN ISO 14971:2019+A11:2021 risk analysis. The class is not chosen for convenience — it has to be justified against the hazards the software could produce if it failed. A Notified Body reviewer will check the justification. A classification that does not match the risk file is a finding.

**Does the PEMS life-cycle file replace the technical documentation required by MDR Annex II?**
No. The PEMS life-cycle file is a specific artifact required by Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024. The MDR Annex II technical documentation is the broader set of documents required by the Regulation itself, covering the whole device. The PEMS life-cycle file is a component of that broader technical documentation, not a replacement for it.

**Can legacy firmware developed before EN 62304:2006+A1:2015 was adopted still be used in a new MDR submission?**
It depends on how the legacy firmware is handled. EN 62304:2006+A1:2015 contains provisions for software of unknown provenance (SOUP) that allow legacy components to be integrated if they are identified, classified, and risk-assessed within the current lifecycle. The legacy code itself does not have to be rewritten, but its integration into the current PEMS has to be planned, documented, and tested under the current standard. Skipping this step is a common finding on devices that reuse older firmware modules.

## Related reading

- [MDR Electrical Safety Requirements: How IEC 60601-1 Helps You Demonstrate Conformity](https://www.zechmeister-solutions.com/blog/mdr-electrical-safety-requirements) — the hub post for the Electrical Safety category.
- [MDR Basic Safety and Essential Performance: Understanding IEC 60601-1 Requirements](https://www.zechmeister-solutions.com/blog/basic-safety-essential-performance-iec-60601-1) — the two concepts the PEMS process is designed to protect.
- [Single Fault Condition Analysis Under IEC 60601-1](https://www.zechmeister-solutions.com/blog/single-fault-condition-iec-60601-1) — how single-fault analysis applies to programmable subsystems.
- [Electrical Hazard Protection Under IEC 60601-1](https://www.zechmeister-solutions.com/blog/electrical-hazard-protection-iec-60601-1) — the hardware-side hazards a PEMS must still defend against.
- [Mechanical Hazards Under IEC 60601-1](https://www.zechmeister-solutions.com/blog/mechanical-hazards-iec-60601-1) — mechanical hazards that cut across the PEMS boundary.
- [Thermal Hazards and Touch Temperature Under IEC 60601-1](https://www.zechmeister-solutions.com/blog/thermal-hazards-iec-60601-1) — thermal hazards in programmable devices where firmware drives heat-producing components.
- [MDR Software Safety Classification Under EN 62304](https://www.zechmeister-solutions.com/blog/mdr-software-safety-classification-en-62304) — how software Class A, B, and C assignments are made and defended.
- [EN 62304 Software Lifecycle Processes for MDR Compliance](https://www.zechmeister-solutions.com/blog/en-62304-software-lifecycle-mdr) — the software lifecycle processes Clause 14 hands off to.
- [The Subtract to Ship Framework for MDR Compliance](https://www.zechmeister-solutions.com/blog/subtract-to-ship-framework-mdr) — the methodology that keeps PEMS scope honest.
- [ME Systems and Combined Equipment Under IEC 60601-1](https://www.zechmeister-solutions.com/blog/me-systems-iec-60601-1) — how PEMS concepts extend when the device is part of a larger system.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I Chapter II, Section 14 (construction of devices and interaction with their environment), Section 17 (electronic programmable systems), Section 18 (active devices and devices connected to them). Official Journal L 117, 5.5.2017.
2. EN 60601-1:2006+A1+A12+A2+A13:2024 — Medical electrical equipment — Part 1: General requirements for basic safety and essential performance. Clause 14 (Programmable Electrical Medical Systems).
3. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes.
4. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices.

---

*This post is part of the Electrical Safety & Systems Engineering Under MDR series in the Subtract to Ship: MDR blog. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star. Clause 14 of EN 60601-1:2006+A1+A12+A2+A13:2024 and EN 62304:2006+A1:2015 are the two harmonised tools that, together, prove a programmable medical device meets Annex I — useful, powerful, and only ever in service of the Regulation itself.*

---

*This post is part of the [Electrical Safety & Systems Engineering](https://zechmeister-solutions.com/en/blog/category/electrical-safety) cluster in the [Subtract to Ship: MDR Blog](https://zechmeister-solutions.com/en/blog). For EU MDR certification consulting, see [zechmeister-solutions.com](https://zechmeister-solutions.com).*