---
title: System Architecture Documentation for Medical Devices Under MDR
description: What a system architecture document must contain for a medical device under MDR Annex II, including hardware/software boundaries and safety segregation.
authors: Tibor Zechmeister, Felix Lenhard
category: Electrical Safety & Systems Engineering
primary_keyword: system architecture medical devices MDR
canonical_url: https://zechmeister-solutions.com/en/blog/system-architecture-medical-devices-mdr
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# System Architecture Documentation for Medical Devices Under MDR

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

> **A system architecture document describes the structure of a medical device — its subsystems, interfaces, hardware/software boundaries, and safety-relevant segregation — in a form that lets a reviewer understand how requirements are allocated and how risks are controlled. Under MDR Annex II §6 and EN ISO 13485:2016+A11:2021 clause 7.3.3, it is not optional.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- System architecture sits between system requirements and detailed design — it allocates requirements to subsystems and defines how they interact.
- MDR Annex II §4 and §6 require the technical documentation to explain the design stages and allow a reviewer to understand how the device meets its requirements. Architecture is how you make that understanding possible.
- Safety-relevant architectural decisions — segregation of patient-contact circuits, separation of safety-critical software from non-critical software, redundant paths for single-fault conditions — must be explicitly documented and justified against the risk file.
- EN 62304:2006+A1:2015 clause 5.3 requires a software architecture document for all safety classes; EN ISO 13485:2016+A11:2021 clause 7.3.3 covers the hardware side under design inputs and outputs.
- An audit-ready architecture document is short, diagrammatic, decision-oriented, and traceable to requirements and risks. It is not a 200-page block diagram dump.

## Why architecture documentation matters

A Notified Body reviewer opens a technical file, flips to the architecture section, and within five minutes must be able to answer three questions: what are the major building blocks, how do they talk to each other, and where are the safety-critical boundaries. If the reviewer cannot answer those questions quickly, the architecture is inadequate — regardless of how much work went into the device.

Most startup founders skip architecture documentation because "the team already knows how it works". That is exactly the problem. Team knowledge does not survive a single new hire, let alone an audit. And it is invisible to the one person whose opinion matters most in the certification moment — the Notified Body reviewer who has 90 minutes to understand your device.

Architecture documentation is the bridge between "the team knows" and "the file shows". It does not need to be long. It needs to be honest, diagrammatic, and tied to decisions that a reviewer would otherwise have to infer.

## What MDR and the standards actually say

MDR Annex II §4 (General Description of the Device and its Intended Purpose) requires the technical documentation to contain a description that allows the device to be understood. §4(c) specifically requires information on the components, including software where applicable. §4(g) requires a general description of the key functional elements — for example, its parts and components, their composition, and their functionality.

MDR Annex II §6 (Product Verification and Validation) requires the documentation to contain the results and critical analyses of all verifications and validation tests, including pre-clinical and clinical data. For verification results to be interpretable, a reviewer must know what was verified — which requires an architectural description.

EN ISO 13485:2016+A11:2021 clause 7.3.3 lists design inputs (the requirements) and 7.3.4 lists design outputs. Architecture is a design output. The clause requires design outputs to "be in a form suitable for verification against the design and development inputs", which means the architecture must be written in a way that lets a tester check that every requirement is allocated somewhere.

EN 62304:2006+A1:2015 clause 5.3 is explicit for software. The manufacturer shall transform the requirements of the medical device software into a documented architecture that describes its structure and identifies the software items. For software items containing SOUP (Software of Unknown Provenance), the architecture shall specify functional and performance requirements and the system hardware and software required by the SOUP item. For software safety class B and C, the architecture shall be designed such that software items are segregated into items that contribute to the safety of the device and items that do not.

EN ISO 14971:2019+A11:2021 feeds the architecture with required safety controls. A risk control that says "redundant temperature monitor with independent power supply" is an architectural requirement, not just a risk file entry.

## A worked example: a Class IIb infusion pump

A startup is developing a small-volume syringe infusion pump. Class IIb (MDR Annex VIII Rule 12 — active therapeutic device intended to administer medicinal products in a potentially hazardous way). Software safety class C under EN 62304. Here is what the system architecture document might look like.

**Section 1 — Context diagram.** One page. Shows the pump, the user (nurse), the patient, the drug container, the hospital network (optional), the power supply, and the service laptop used for maintenance. Every arrow is labelled with the information or material that crosses it.

**Section 2 — Major subsystems.** A block diagram with five blocks:

1. Drive mechanism (motor, lead screw, syringe holder)
2. Sensing subsystem (force sensor, occlusion detection, air-in-line detector)
3. Control electronics (main MCU, safety MCU, power management)
4. User interface (touchscreen, buzzer, LEDs, physical stop button)
5. Communications (BLE, optional Wi-Fi for alarms)

**Section 3 — Hardware/software allocation.** A table showing which system requirements are met by hardware only, software only, or the combination. For example, the physical stop button meets SR-0087 (emergency stop) in hardware only; the occlusion alarm meets SR-0112 (alarm within 30 seconds of occlusion) via hardware sensor plus software algorithm.

**Section 4 — Safety segregation.** This is the section that matters most for a Class IIb device. The architecture has two MCUs: a main MCU running the user interface and control loop, and an independent safety MCU that monitors the drive motor, the occlusion sensor, and the watchdog. The two MCUs communicate over a dedicated serial link. A single failure in the main MCU cannot cause an uncontrolled infusion because the safety MCU can independently cut motor power. This decision traces to risk controls RCM-0015, RCM-0016 and RCM-0044 in the risk management file. The segregation also satisfies EN 62304 clause 5.3 requirements for software safety class C.

**Section 5 — Interfaces.** A table of every interface: physical (mechanical mount, power connector), electrical (connector pinouts, voltage levels), logical (serial protocols, BLE services), human (touchscreen interactions, audible alarms).

**Section 6 — Key architectural decisions.** Each decision is a short paragraph: the decision, the alternatives considered, the rationale, the impact on requirements and risks. Example: "Decision to use two separate MCUs rather than a single MCU with software partitioning. Alternative considered: single MCU with memory protection unit and software partitioning. Rationale: hardware segregation provides stronger single-fault tolerance and simplifies verification for software safety class C. Impact: higher BOM cost by €3.40, but eliminates the need for formal software partitioning analysis."

The entire document is 22 pages. That is enough.

## The Subtract to Ship playbook for architecture documentation

**Step 1 — Draw before you write.** Start with a whiteboard, a marker, and the team. Sketch the context diagram, the subsystem diagram, and the safety segregation. Photograph the whiteboard. The photograph is the first draft. Words come later.

**Step 2 — Keep it diagrammatic.** Every major section should open with a diagram. Prose explains the diagram, not the other way round. Reviewers scan diagrams in seconds; they skim prose in minutes.

**Step 3 — Write decision records.** Architecture is a sequence of decisions. Each decision has a context, alternatives considered, chosen option, and rationale. The format comes from software engineering practice (sometimes called "architecture decision records") but the discipline is pure MDR Annex II §4: explain the design stages so a reviewer can understand them.

**Step 4 — Call out safety-relevant decisions explicitly.** Any architectural decision that was driven by a risk control, a single-fault condition, a GSPR, or a standard must be flagged. Reviewers look for these. The easiest format is a column in the decision table labelled "Safety relevance" with a trace to the risk file entry.

**Step 5 — Trace every subsystem to system requirements.** A subsystem that does not implement at least one system requirement should not exist. A system requirement that is not allocated to any subsystem is an orphan. Both situations are findings.

**Step 6 — Document the hardware/software boundary rigorously.** For any requirement that is met by a combination of hardware and software, state clearly what the hardware provides and what the software provides. This is where most architecture documents fail — the boundary is implicit and reviewers have to guess.

**Step 7 — For software, follow EN 62304 clause 5.3.** The software architecture document lists software items, identifies SOUP, specifies the segregation between safety-related and non-safety-related items (for Class B and C), and documents the interfaces between software items. This document can be a subsection of the system architecture or a standalone document — either works.

**Step 8 — Version and baseline.** The architecture document is under document control per clause 4.2.4. Changes after baseline go through the design change process per clause 7.3.9. An architecture document that is edited freely is not controlled, and the whole audit trail collapses.

**Step 9 — Keep it shorter than the reviewer expects.** A 25-page architecture document for a Class IIa device is usually better than a 150-page one. Brevity forces clarity. Reviewers reward clarity.

**Step 10 — Test the document with a naive reader.** Give the architecture to someone who was not involved in writing it — ideally an external reviewer — and ask them to answer the three reviewer questions: what are the major blocks, how do they interact, where are the safety boundaries. If they cannot answer in 10 minutes, rewrite.

## Reality Check

1. Can a reviewer answer "what are the major subsystems, how do they interact, where are the safety boundaries" from your architecture document in under 10 minutes?
2. Does every system requirement from your specification trace to at least one subsystem in the architecture?
3. Are safety-relevant architectural decisions explicitly tied to entries in your EN ISO 14971 risk file?
4. For software safety class B or C items, does your architecture explicitly show segregation between safety and non-safety items as required by EN 62304 clause 5.3?
5. Is the hardware/software boundary documented for every requirement that is met by a combination?
6. Are architectural decisions recorded with rationale, or only as outcomes?
7. Is the architecture document under version control and baselined before verification began?
8. If a new engineer joined tomorrow, could they understand the system structure from the architecture document alone?

## Frequently Asked Questions

**Do I need a system architecture document if I only have software?**
Yes. EN 62304:2006+A1:2015 clause 5.3 requires a software architecture document for all safety classes. For a software-only medical device, the software architecture effectively is the system architecture. You still need to describe interfaces to the host platform, external services, and users.

**How is system architecture different from software architecture?**
System architecture covers the whole device — hardware, software, mechanical, user interface, interfaces to users and external systems. Software architecture is a subset that describes the internal structure of the software. For a purely software device the two converge.

**Can I just use the block diagram from the pitch deck?**
No. A pitch diagram shows marketing concepts. An architecture diagram shows how requirements are allocated, how subsystems interface, and where safety boundaries live. The two have different purposes and different readers.

**How detailed should interface documentation be?**
Detailed enough that a different team could implement one side of the interface and have it work with the other. Signal levels, timing, protocol, error behaviour, and physical connectors all belong in interface documentation.

**What happens if the architecture changes during development?**
Changes go through the design change process per EN ISO 13485:2016+A11:2021 clause 7.3.9 with impact analysis on requirements, verification, validation and risk management. The updated architecture becomes the new baseline.

**How often should the architecture document be reviewed?**
Once before baseline, once at every significant design review, and once again before the Notified Body audit. Between those points, updates happen through controlled change.

## Related reading
- [Systems Engineering V-Model for Startups](/blog/systems-engineering-v-model-startups) — how architecture fits into the overall V.
- [System Requirements for Medical Devices](/blog/system-requirements-medical-devices) — the inputs that architecture allocates.
- [Software Architecture Documentation under EN 62304](/blog/software-architecture-documentation-iec-62304) — the software-specific companion to system architecture.
- [Software Safety Class Drives Effort](/blog/software-safety-class-drives-effort) — why Class B and C change architecture requirements.
- [Design and Manufacturing Information in the Technical File](/blog/design-manufacturing-information-tech-doc) — how architecture feeds the technical documentation.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex II §4, §6; Annex I.
2. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes, clause 7.3.3 and 7.3.4.
3. EN 62304:2006+A1:2015 — Medical device software — Software lifecycle processes, clause 5.3.
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](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).*