---
title: Writing a Software Architecture Document for MDR (IEC 62304)
description: An audit-ready software architecture document under EN 62304 clause 5.3: decomposition, SOUP, segregation of safety items, and the diagrams auditors expect.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: software architecture document IEC 62304 MDR
canonical_url: https://zechmeister-solutions.com/en/blog/software-architecture-document-iec-62304
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# Writing a Software Architecture Document for MDR (IEC 62304)

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

> **A software architecture document under EN 62304:2006+A1:2015 clause 5.3 is the artefact that decomposes the software into items, identifies SOUP, shows the interfaces, and argues the segregation of items implementing risk controls. For MDR conformity under Annex I §17, it is the single most important design-level document the notified body will read.**

**By Tibor Zechmeister and Felix Lenhard.**

## TL;DR
- EN 62304:2006+A1:2015 clause 5.3 defines six sub-activities for software architecture: transform requirements into architecture, develop architecture for the interfaces, specify functional and performance requirements of SOUP, specify system hardware and software required by SOUP, identify segregation between software items, and verify the architecture.
- The architecture document translates the SRS into software items, shows how they communicate, and identifies every SOUP (Software Of Unknown Provenance) by name, version and supplier.
- For Class B and C software, the architecture must show the segregation argument for items implementing risk controls.
- The MDR legal anchor is Annex I §17 on electronic programmable systems, with EN 62304 as the presumption-of-conformity route.
- An audit-ready architecture document is typically 15 to 50 pages and is reviewed by the notified body line by line.

## Why this matters

When I open a software folder during an audit, the architecture document is where I decide whether the team understands their own system. The SRS tells me what they want the software to do. The architecture tells me whether they know how they built it.

The failure modes I see most often: architecture diagrams drawn in a whiteboard tool six months before release, never updated. SOUP mentioned nowhere in the architecture but used everywhere in the code. Risk controls listed in the risk management file but with no visible home in any software item. A single diagram labelled "architecture" with five boxes and no text.

These failures are not cosmetic. Clause 5.3 is the place where EN 62304 demands that the team prove they can point at a component and say: this is the thing that implements that risk control, here is why it is isolated from the rest of the system, and here is the SOUP it depends on. If that proof cannot be produced, there is no conformity argument to make.

## What EN 62304 actually requires

EN 62304:2006+A1:2015 clause 5.3 contains six sub-clauses. Each one maps to a specific deliverable inside the architecture document.

**5.3.1 Transform software requirements into an architecture.** The architecture shall describe the software's structure and identify the software items. A software item, per clause 3, is any identifiable part of a software product. Items can be further decomposed into sub-items and eventually into units.

**5.3.2 Develop an architecture for the interfaces of software items.** Every interface between items, and between items and things outside the software system (hardware, users, external software, networks), must be specified. Direction, data, protocol, timing, error behaviour.

**5.3.3 Specify functional and performance requirements of SOUP items.** Every SOUP must have documented functional and performance requirements it is expected to meet. You are not reverse-engineering the SOUP; you are declaring what you depend on it for, at the level needed to evaluate its fitness.

**5.3.4 Specify system hardware and software required by SOUP items.** The environment the SOUP needs to run: OS, runtime, memory, other libraries. This is what makes SOUP boundaries real — if you cannot describe what the SOUP needs, you cannot verify it is present in the production environment.

**5.3.5 Identify segregation necessary for risk control.** For Class B and C software, the architecture must identify software items that are necessary for risk control and show the segregation between these items and other items. Segregation means the design prevents one item from compromising the safety behaviour of another.

**5.3.6 Verify software architecture.** The architecture shall be verified to: implement system and software requirements, be able to support interfaces, and enable the medical device to fulfil its intended use. Verification is documented, not implied.

The MDR connection runs through Annex I §17 on electronic programmable systems. §17.2 requires software to be developed according to the state of the art, accounting for lifecycle, risk management and verification. EN 62304 is the harmonised route, and clause 5.3 is the architecture gate inside it.

## What an audit-ready architecture document contains

Here is the structure that survives audits. Treat it as a template.

**1. Purpose and scope.** Which software system, which version, which device, which safety class. A single paragraph.

**2. Inputs.** Reference to the SRS version and the risk management file version this architecture implements.

**3. Architectural overview.** One context diagram (software system in its environment) and one high-level component diagram showing the named software items. Each item has a name, a one-sentence purpose, and a stable ID.

**4. Software item catalogue.** A table. One row per software item. Columns: ID, name, purpose, responsible developer or team, safety relevance (yes/no, and which risk controls), trust boundary membership.

**5. Item-by-item description.** For each software item: its responsibilities, its interfaces (inbound and outbound), its data ownership, its SOUP dependencies, its links to requirements it implements, its links to risk controls it implements.

**6. Interface specification.** For each interface: the two endpoints, the direction, the data model (reference to data definitions in the SRS), the protocol, the error behaviour, the timing constraints where relevant.

**7. SOUP list.** A table. One row per SOUP. Columns: name, supplier or source, version, license, functional requirements (what we use it for), performance requirements (what we need it to deliver), required environment, anomaly evaluation reference, verification approach.

**8. Segregation argument (Class B and C).** For each software item implementing a risk control, a statement describing how segregation is achieved: process isolation, address space separation, API boundaries, data validation at the boundary, hardware separation where applicable. A segregation diagram showing the boundaries.

**9. Architectural decisions and rationale.** Key design decisions, the alternatives considered, and the reasons for the choice. Keep it short. Auditors read this to understand whether the team made decisions or drifted into the current shape.

**10. Verification of the architecture (clause 5.3.6).** Evidence that the architecture has been reviewed against the SRS and the risk management file, including reviewer names, dates and outcomes.

## SOUP, properly handled

SOUP is the audit minefield for almost every startup. The pattern to avoid: SOUP is used in the code, mentioned in a license file, and nowhere in the architecture.

The pattern that works:

Every third-party dependency — library, framework, runtime, cloud service where it affects the behaviour inside the device boundary — is a SOUP item. It gets a row in the SOUP list. It gets a functional requirement statement ("we use libfoo to render PDFs from HTML input"). It gets a performance requirement ("libfoo shall render a 20-page document in under 3 seconds on the target hardware"). It gets an environment statement ("libfoo requires glibc 2.31 or newer"). It gets an anomaly evaluation (a documented check of the SOUP's known issue list against the device's hazards). It gets a verification approach (integration tests that exercise the relevant behaviour).

The SOUP list is reviewed every time a dependency is added, removed or upgraded. Not at audit time. At merge time.

For the deeper view on SOUP selection and documentation, see [SOUP and OTS software under MDR](/blog/soup-ots-software-mdr) and [evaluating and documenting SOUP components](/blog/evaluate-document-soup-ots-components).

## Segregation of safety items

Clause 5.3.5 is the clause teams misread most often. Segregation does not mean "the code is in a separate file." It means the design argument shows that failures or defects in non-safety items cannot propagate into safety items.

Segregation mechanisms that usually count: separate processes with defined IPC; separate containers with controlled APIs; memory protection boundaries; hardware watchdogs and monitors; input validation at the boundary of the safety item; out-of-band verification of safety-critical computations.

Segregation mechanisms that usually do not count on their own: "we reviewed the code carefully"; "the safety item is in its own class"; "we followed clean architecture principles." These are practices. They are not segregation evidence.

The segregation argument is explicit. It says: item X implements risk control R. Item X is segregated from items Y and Z by mechanism M. The segregation is verified by test T. Reference the test in the verification records.

## A worked example

A Class IIb infusion monitoring system, software safety Class C. The architecture document grew from a 6-page draft to a 42-page controlled document over three months.

The core items: Acquisition (reads sensor data), Analysis (applies alerting rules), Alerting (generates clinician alerts), Logging (writes audit trail), UI (presents state to the clinician), API (communicates with the hospital system). Six items, each with a stable ID and a single responsible owner.

The segregation argument centered on Alerting. The risk controls for missed-alert hazards were implemented in Alerting. The segregation mechanism: Alerting ran in its own process, received data from Analysis through a validated IPC channel, wrote alerts to a dedicated UI channel, and had its own watchdog. Any failure in Acquisition, Analysis or UI could not silently suppress an alert, because Alerting's liveness and output were monitored independently.

The SOUP list had 14 entries: runtime, web framework, database driver, charting library, validation library, cryptography library, time sync library, plus hospital-system SDKs. Each entry had its functional statement, performance requirement, environment, anomaly check, and a verification strategy.

The notified body audit spent two hours on the architecture document. The reviewer walked three random requirements from the SRS into the architecture, then walked two risk controls from the risk management file into the segregation argument. Zero findings.

## The Subtract to Ship playbook

**Draw the architecture once the SRS is stable, not before.** Drawing architecture against a moving SRS is expensive waste.

**One diagram per question.** Context diagram, component diagram, segregation diagram, deployment diagram. Each answers one question. Avoid the "one big diagram" that answers nothing.

**Name the items and freeze the names.** Item names appear in code, tests, commit messages, and audit transcripts. Renames are expensive. Choose names once, deliberately.

**Keep the SOUP list in the repo.** A machine-readable file (YAML or JSON) that generates the human-readable SOUP table. Every dependency change is a pull request that updates the file.

**Write the segregation argument in English, not diagrams.** Diagrams support the argument. They do not replace it. The argument is a paragraph per safety item, naming the mechanism, the assumption, and the verification.

**Verify the architecture formally.** Clause 5.3.6 is not optional. A documented review, with reviewers, findings, and sign-off, must exist for every version of the architecture document that ships.

For the companion documents, see [the complete software documentation package](/blog/software-documentation-package-iec-62304), [the software requirements specification for MDR](/blog/software-requirements-specification-mdr), and the overview post on [software architecture documentation under IEC 62304](/blog/software-architecture-documentation-iec-62304).

## Reality Check

1. Does every software item in your architecture have a stable ID that appears in your code?
2. Is your SOUP list current to this merge — not this quarter?
3. For every risk control implemented in software, can you point to the item that implements it and the segregation mechanism that protects it?
4. Does your architecture document reference the exact SRS version it implements?
5. Is there a documented verification of the architecture (clause 5.3.6) for the current version?
6. Can a new developer read the architecture document alone and understand how data flows through the system?
7. Have you evaluated the known anomaly list of every SOUP against your device hazards?
8. Is the segregation argument written in prose, not inferred from a diagram?

## Frequently Asked Questions

**Do Class A systems need a segregation argument?**
No. Clause 5.3.5 applies to items implementing risk controls, and for Class A software there are no software failures that could contribute to a hazardous situation. You still need the architecture document, just without the segregation section.

**How many software items should I have?**
As many as you need to make the interfaces clean and the segregation argument credible. Too few (one big item) defeats the point of decomposition. Too many creates unmaintainable documentation. For typical SaMD startups, 5 to 15 items is common.

**Is a cloud service a SOUP?**
If the software depends on the service for behaviour that affects the medical device function, yes. The functional and performance requirements (clauses 5.3.3 and 5.3.4) become the SLA you depend on. Document the service, the version or API level, and the assumptions.

**Can I use C4 model diagrams?**
Yes. C4 works well for EN 62304 architecture documentation. Context, Containers and Components map naturally to the item hierarchy. You still need the clause 5.3.3 to 5.3.6 content alongside the diagrams.

**What if my architecture changes during development?**
It will. Version the document. Link versions to SRS versions. Update before the next release baseline. The one thing you cannot do is ship a release against an outdated architecture document.

**Does open source count as SOUP?**
Yes. Open source is SOUP under EN 62304. You own the verification, the environment, the anomaly check, and the fitness argument, regardless of license.

## Related reading
- [Software architecture documentation under IEC 62304](/blog/software-architecture-documentation-iec-62304) — companion overview.
- [Software documentation package](/blog/software-documentation-package-iec-62304) — how architecture fits the full artefact set.
- [Software requirements specification for MDR](/blog/software-requirements-specification-mdr) — the upstream document.
- [SOUP and OTS software under MDR](/blog/soup-ots-software-mdr) — the SOUP concept in depth.
- [Evaluating and documenting SOUP components](/blog/evaluate-document-soup-ots-components) — the practical SOUP workflow.

## Sources
1. Regulation (EU) 2017/745 on medical devices, consolidated text. Annex I §17.
2. EN 62304:2006+A1:2015 — Medical device software — Software life cycle processes. Clause 5.3.
3. EN ISO 14971:2019+A11:2021 — Application of risk management to medical devices.

---

*This post is part of the [Software as a Medical Device](https://zechmeister-solutions.com/en/blog/category/samd) 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).*