---
title: MDR Software Architecture Documentation: Using IEC 62304 for System Design
description: EN 62304 Section 5.3 requires software architecture documentation. Here is what it must contain, how SOUP is flagged, and how startups keep it lean.
authors: Tibor Zechmeister, Felix Lenhard
category: Software as a Medical Device
primary_keyword: software architecture IEC 62304 MDR
canonical_url: https://zechmeister-solutions.com/en/blog/software-architecture-documentation-iec-62304
source: zechmeister-solutions.com
license: All rights reserved. Content may be cited with attribution and a link to the canonical URL.
---

# MDR Software Architecture Documentation: Using IEC 62304 for System Design

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

> **EN 62304:2006+A1:2015 Section 5.3 requires the manufacturer to transform the software requirements into a documented architecture that describes the structure of the software. The architecture must identify the software items that make up the software system, specify the interfaces between those items and between the software and external components, describe the interfaces for any SOUP (Software Of Unknown Provenance) items, and support segregation arguments where software items of different safety classes share a system. The documentation has to be detailed enough that the design, implementation, and verification activities that follow can be derived from it, and that a Notified Body can read the architecture and trace every software item back to the requirements it implements and the risk controls it enforces. The MDR is the North Star. EN 62304:2006+A1:2015 is the tool.**

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

---

## TL;DR

- EN 62304:2006+A1:2015 Section 5.3 is the clause that requires a documented software architecture for every medical device software project, derived from the software requirements written under Section 5.2.
- The architecture must identify the software items, specify the interfaces between them, specify the interfaces to external systems, and document the interfaces of any SOUP items in use.
- SOUP — Software Of Unknown Provenance — is the standard's term for software that was not developed under EN 62304:2006+A1:2015 and is used inside the medical device software. Every SOUP item has to be identified, its version pinned, its required interfaces and performance documented, and its residual risks addressed.
- Segregation — the architectural argument that software items of different safety classes cannot interfere with each other — is what lets a team isolate a Class C module inside a system where most items are Class A or Class B. Without a documented segregation argument, the higher class applies to the whole system.
- The architecture documentation is read by the Notified Body as part of the MDR Annex II technical documentation. It is the structural view that connects requirements, risk controls, code, and verification into one traceable file.
- The common failure is not missing architecture — it is architecture that exists as whiteboard photos in a Notion page, with no software item list, no interface definitions, and no link to the requirements or the risk file.

---

## Why architecture is the activity where lifecycle traceability gets structural

Software requirements tell you what the software has to do. Architecture tells you how it is structured to do it. Without the architecture layer, the requirements cannot be allocated to anything, the risk controls implemented in software have no home, SOUP components drift into the code base without being tracked, and the verification activities have no structural view to plan against. Every team that has tried to skip the architecture activity and jump from requirements to code has paid for it later — in rework, in duplicated components, in orphaned risk controls, and in audit findings that the file cannot explain.

The architecture is also where the honest conversation about software safety classes happens. A team that has done requirements well arrives at the architecture activity with a list of behaviours the software has to produce and a set of risk controls the software has to enforce. The architecture activity allocates those behaviours and controls to specific software items, and in doing so forces the team to decide which items are safety-critical and which are not. An item that implements a Class C risk control is Class C. An item that cannot affect any hazardous situation, even indirectly, is Class A. Without an architecture, the team cannot make these allocations — the whole code base collapses into one big lump and the highest class applies to everything.

EN 62304:2006+A1:2015 Section 5.3 is the clause that forces this structure to exist on paper. It is not asking for UML diagrams as art. It is asking for a documented, traceable, risk-aware view of the software that a competent reviewer can follow from requirements to items to interfaces to SOUP to segregation to verification. This post walks through what the clause requires, how to document the software items, how to handle SOUP correctly, how to build a segregation argument that survives audit, how to document interfaces, how a resource-constrained startup keeps the activity lean, and the mistakes we see repeatedly.

## Section 5.3 requirements — what the clause actually asks for

Section 5.3 of EN 62304:2006+A1:2015 — Software architectural design — sits directly after software requirements analysis (Section 5.2) and before software detailed design (Section 5.4). The sequence is deliberate. Architecture is the layer that takes the verified requirements from Section 5.2 and produces a structural decomposition that the design and implementation activities can work from.

The clause requires the manufacturer to transform the software requirements into a documented architecture. The architecture must describe the software items — the top-level structural components that the software is decomposed into — and the interfaces between those items and between the software and components external to it. The architecture must be sufficient to support the detailed design activity that follows.

Where the software uses SOUP items, the architecture must specify the functional and performance requirements for each SOUP item that are necessary for its intended use, and must specify the system hardware and software required to support that SOUP item. Where the architecture relies on segregation to ensure that software items of different safety classes cannot interfere with each other, the manufacturer must document the segregation and justify that it is effective.

The architecture must also be verified. Verification at this level asks whether the architecture implements the requirements, whether the architecture is consistent with itself, whether the architecture supports the risk controls the software has to enforce, and whether the segregation arguments are sound. Verification closes the activity before detailed design begins.

The scope of the clause scales with the software safety class. Class C software requires the fullest architectural documentation. Class B software requires architecture down to the software-item level with interface definitions. Class A software has the lightest requirements — essentially, enough structure to identify the items and their external interfaces. The class-driven scaling is what lets a startup with a Class A module produce lean architecture documentation without under-delivering on the standard.

## Identification of software items — what a software item actually is

A software item under EN 62304:2006+A1:2015 is "any identifiable part of a computer program" — the definition is deliberately flexible. In practice, a software item is whatever unit of the software the architecture treats as a building block. It might be a service, a module, a library, a microservice, a container, a package, a layer — the name depends on the technology stack. What matters is that each software item is identifiable, has a defined responsibility, has defined interfaces, and can be assigned a software safety class.

The architecture document lists every software item in the system, with a short description of its responsibility and its safety class. The list is not an org chart — it is the inventory the rest of the lifecycle activities work against. Design activities target specific items. Verification activities target specific items. Risk controls are allocated to specific items. Configuration management tracks specific items. If an item is not on the list, it does not exist in the file, and anything that happens to it downstream breaks traceability.

The granularity of the decomposition is a judgement call. Decompose too coarsely — treat the whole back end as one software item — and the safety class of the largest risk control applies to the whole thing. Decompose too finely — list every class and function as a software item — and the architecture document becomes unreadable and unmaintainable. The rule of thumb we use with startup teams is that a software item is a unit that could plausibly be developed, verified, and released as a coherent whole. A microservice with its own deployment is a software item. A single helper function is not. A third-party library the team depends on is a software item — specifically, a SOUP item, covered below.

Each software item on the list is tagged with the software safety class assigned to it. The class determines the depth of the design, implementation, and verification activities for that item. An item that cannot contribute to any hazardous situation is Class A. An item that can contribute to non-serious injury is Class B. An item that can contribute to death or serious injury is Class C. The tagging is what makes the architecture the mechanism through which the software safety classification actually bites into the engineering work.

## SOUP flagging — Software Of Unknown Provenance

SOUP is the term EN 62304:2006+A1:2015 uses for software that was not developed under the standard and is used inside the medical device software. Open-source libraries, third-party frameworks, operating systems, database engines, cloud services, machine-learning runtimes — all of these are SOUP when the manufacturer did not develop them under a compliant lifecycle. For modern medical software, SOUP is often the majority of the code that runs in production, and the standard takes SOUP seriously because the manufacturer is still responsible for the behaviour of the software as a whole.

The architecture must identify every SOUP item in use. For each SOUP item the manufacturer documents the item's name, version (pinned to a specific release, not a version range), supplier, and the purpose it serves in the architecture. The manufacturer also documents the functional and performance requirements the SOUP item must meet for the software to work as intended, and the system hardware and software the SOUP item requires to operate — the operating system version, the runtime, the dependencies, the hardware characteristics.

The risk side of SOUP is addressed through the software risk-management process. Every SOUP item is evaluated for the risks it introduces: known anomalies, vulnerability disclosures, maintenance status, update path, and whether the item has caused incidents in similar deployments. Anomalies the manufacturer is aware of are assessed against the intended use and addressed in the risk file. SOUP items that carry unacceptable residual risk are either replaced or the risk is controlled outside the SOUP — through wrappers, input validation, monitoring, or architectural segregation.

The SOUP list is not a one-time artefact. It is updated whenever a SOUP item is added, removed, or upgraded, and it is reviewed as part of the software maintenance and problem resolution processes. A new vulnerability disclosure against a SOUP item triggers a risk-file update. A version bump triggers a re-verification of the interface and performance requirements. The discipline that makes SOUP manageable is treating each SOUP item as a first-class component of the architecture, not as an invisible dependency the build system happens to pull in.

## Segregation for safety — the architectural argument that isolates the highest class

Segregation is the architectural mechanism that lets software items of different safety classes coexist in the same software system without the highest class applying to everything. The standard allows segregation, but it requires the manufacturer to document and justify it. Without a documented segregation argument, the highest class of any software item in the system applies to every software item in the system — which usually means writing a Class C lifecycle for items that would otherwise be Class A.

A segregation argument is a structured claim that the architecture prevents a software item of a given safety class from interfering with the operation of a software item of a lower safety class. "Interfering" is broad — it includes sharing memory, sharing execution context, sharing data in ways that could propagate errors, sharing timing resources, and sharing any communication channel that could carry a fault. The argument has to be specific to the technology in use: a process-isolation argument on a desktop OS looks different from a container-isolation argument in Kubernetes, which looks different from an MPU-based isolation argument in an RTOS.

The argument has three parts. First, the mechanism — what specifically provides the isolation (process boundaries, container boundaries, hardware memory protection, network segmentation, language-level sandboxing). Second, the effectiveness — why the mechanism actually works against the fault modes the risk file identifies, including cases where one item misbehaves, crashes, or is compromised. Third, the evidence — what testing, analysis, or external certification supports the effectiveness claim. A segregation argument without evidence is a hope, not a control.

Segregation is worth the work when the cost of applying the higher class to the whole system exceeds the cost of building and documenting the isolation. For many startups, this is true: a small, well-isolated Class C module inside a mostly Class A or Class B system is much cheaper to develop and verify than the alternative of treating the whole system as Class C. But the savings evaporate if the segregation is not robust, because a Notified Body that does not believe the argument will treat the whole system at the higher class.

## Interfaces — between items and to external systems

The architecture must specify the interfaces between software items inside the system and the interfaces between the software and components external to it. Interfaces are where errors propagate, where requirements become observable, and where SOUP meets custom code. Documenting them is not an optional elegance — it is what makes the architecture a working engineering document.

An internal interface specification describes the contract between two software items: the data passed, the format, the timing, the error modes, the sequencing, and the assumptions each side makes about the other. An external interface specification describes the contract at the boundary of the software: the hardware devices, the networks, the users, the third-party services, the operating environment. The specifications do not have to be UML — plain structured text is fine — but they have to be specific enough that a developer on either side of the interface can implement or consume it without guessing, and a tester can verify conformance to the contract.

Interfaces between the software and SOUP are a special case. The architecture documents the interface the SOUP item exposes (as published by the supplier) and the subset of that interface the manufacturer actually uses. The subset matters because SOUP items usually expose much more functionality than any one user needs, and the risk assessment only has to cover the subset in use.

## How startups document architecture lightly

The default response to Section 5.3 is to draw diagrams and write documents until the architecture folder is full. That is usually waste. The lean approach that works across the startup teams we have worked with uses a small number of disciplined moves.

Keep the architecture in the same repository as the code. A single architecture document in the repo, written in structured markdown, linked by stable identifiers to the requirements file and the risk file. The document is versioned with the code, reviewed in pull requests, and always matches the current state of the system. Architecture that lives in a Confluence page nobody updates is architecture that will fail audit.

List the software items as a table. Item identifier, short description, safety class, SOUP or custom, interfaces in, interfaces out. The table is the spine of the architecture; the diagrams are commentary. Keep the diagrams if they help the team reason, but do not make them the primary artefact — tables are easier to keep in sync with reality.

Document SOUP in a SOUP register that is part of the architecture file, not a separate document. Name, version (pinned), supplier, purpose, interface used, required environment, known anomalies considered, risk-file link. Update the register as part of the change process whenever a SOUP item is added or upgraded.

Write segregation arguments where the class differential justifies the work, and not everywhere. For systems where almost everything is the same class, segregation is not worth documenting. For systems where a small high-class module sits inside a larger lower-class system, the segregation argument is often the single highest-leverage document in the file.

Verify the architecture before starting detailed design. Verification at this level is a structured review by someone competent — does the architecture implement the requirements, are the items well-chosen, are the interfaces specified, are the SOUP items identified, is the segregation argument sound? The review closes the activity and creates the record that lets downstream activities proceed.

## Common mistakes startups make with software architecture

The same mistakes appear across teams, and they are all fixable before the audit if someone is watching for them.

**No software item list.** The team has a mental model of the architecture but no written list. Everything downstream breaks. The fix is to write the list, even if it feels redundant to the team that "already knows" the structure.

**Coarse decomposition that forces the highest class on everything.** Treating the whole back end as one software item means the highest-class risk control in the back end sets the class for all of it. The fix is to decompose along the lines where safety classes actually differ, and to document segregation where the differential is worth the work.

**SOUP drift.** New dependencies show up in the lock file without appearing in the SOUP register. The fix is to gate dependency changes on SOUP register updates, enforced in the pull-request process.

**Unpinned SOUP versions.** The SOUP register lists a library but not a specific version, or lists a version range. The fix is to pin to exact versions and update the register on every bump.

**Segregation asserted without evidence.** The architecture claims isolation but provides no mechanism, effectiveness analysis, or testing. The fix is to write the three-part argument or drop the segregation claim and accept the higher class.

**Interfaces documented only on the diagram.** A box-and-arrow diagram with no text specification of what flows across the arrows is not an interface definition. The fix is to write the contract in text, with data, timing, error modes, and sequencing.

**Architecture drift from code.** The document describes a system that does not match what is deployed. The fix is to keep the architecture in the repository, review it in pull requests, and treat architectural changes as first-class changes that require the same rigour as code changes.

## The Subtract to Ship angle

The Subtract to Ship move on software architecture is to document exactly as much structure as the standard, the risk file, and the safety class demand, and not one diagram more. The activity rewards discipline, not volume. A three-page architecture with a clean software item table, a pinned SOUP register, a clear interface section, and a specific segregation argument where needed is worth more than a thirty-page architecture document full of context-free diagrams.

The subtraction test on architecture is sharp. Does every software item on the list have a safety class assigned? If not, add it or cut the item. Is every SOUP item pinned to a version and linked to a risk entry? If not, fix the register. Is every interface between items documented at a level a developer can implement against without guessing? If not, rewrite it. Does the segregation argument have a mechanism, an effectiveness claim, and evidence? If not, strengthen it or drop it. Is every architectural element traceable upward to a requirement and forward to a verification activity? If not, close the chain. The document that remains is short, precise, and audit-ready. For the broader framework applied to MDR, see post 065.

## Reality Check — Is your software architecture documentation audit-ready?

1. Do you have a written list of every software item in the system, with a safety class assigned to each one?
2. Is every SOUP item identified by name, pinned version, supplier, purpose, and the interface subset you actually use?
3. Have you evaluated each SOUP item for known anomalies and linked the evaluation to the EN ISO 14971:2019+A11:2021 risk file?
4. Where software items of different safety classes share the system, do you have a documented segregation argument with a mechanism, an effectiveness claim, and supporting evidence?
5. Are the interfaces between software items, and between the software and external components, specified in text — not only on diagrams — at a level a developer could implement against?
6. Does every software item on the list trace backward to the software requirements it implements and forward to the verification activities that prove it?
7. Is the architecture document in the same repository as the code, reviewed in the same change process, and consistent with what is deployed?
8. Would the architecture document survive a Notified Body reviewer reading it as part of the technical documentation under MDR Annex II?

Any question you cannot answer with a clear yes is a gap that will surface at audit. The earlier the gap is closed, the cheaper the fix.

## Frequently Asked Questions

**What is a software item under EN 62304:2006+A1:2015?**
A software item is any identifiable part of the software that the architecture treats as a building block — typically a service, module, library, container, or package that has a defined responsibility, defined interfaces, and can be assigned a software safety class. The granularity is a judgement call, but the rule of thumb is that a software item is a unit that could plausibly be developed, verified, and released as a coherent whole. Every software item appears on the architecture's software item list and is tagged with its safety class.

**What counts as SOUP, and what does the standard require for it?**
SOUP — Software Of Unknown Provenance — is any software used inside the medical device software that was not developed under EN 62304:2006+A1:2015. Open-source libraries, third-party frameworks, operating systems, runtimes, and cloud services are all SOUP when the manufacturer did not develop them under a compliant lifecycle. The standard requires the manufacturer to identify each SOUP item, pin its version, document its supplier and purpose, specify the functional and performance requirements it must meet, specify the environment it needs, and assess its known anomalies against the intended use through the risk-management process.

**Does the architecture have to use UML or a specific notation?**
No. EN 62304:2006+A1:2015 does not prescribe a notation. The architecture can be documented in plain structured text, in diagrams, in tables, or in any combination that makes the structure clear. What matters is that the software items are identified, the interfaces are specified, the SOUP items are listed, the segregation arguments are justified, and the document can be followed by a reviewer to connect requirements to verification. Tables in a markdown file work. UML works. Both can work together.

**What is segregation and when should a team document it?**
Segregation is the architectural argument that software items of different safety classes cannot interfere with each other, which allows the manufacturer to apply the higher class only to the high-class items instead of to the whole system. A team should document segregation when the system has items of clearly different safety classes and the cost of applying the higher class to everything exceeds the cost of building and documenting the isolation. The argument must include a specific isolation mechanism, an effectiveness analysis against the fault modes, and supporting evidence — without all three, the segregation claim will not survive audit.

**How detailed does the architecture have to be for Class A software?**
Class A software has the lightest architectural requirements under Section 5.3 — essentially, enough structure to identify the software items and their external interfaces, with the safety class assigned and the SOUP items documented. Class B software requires architecture down to the software-item level with interface definitions between items. Class C software requires the fullest architectural documentation, including the detailed decomposition that supports unit-level design downstream. The scaling is what lets a startup with a Class A module produce lean architecture documentation without under-delivering on the standard.

**Where does software architecture fit into the MDR technical documentation?**
MDR Annex II lists the design and manufacturing information the technical documentation must contain, and the software architecture is part of that design information for any device where software qualifies as a medical device or is an integral part of the device. The Notified Body reads the architecture as evidence that the manufacturer has a disciplined design process under Annex I Section 17 and can connect requirements, risk controls, code, and verification into a traceable file. An architecture that satisfies Section 5.3 of EN 62304:2006+A1:2015 is the form that evidence takes for the structural view of the software.

## Related reading

- [MDR Software Classification Under Rule 11](/blog/mdr-software-classification-rule-11) — post 371, the MDR device class that sits above the software safety class.
- [MDR Software Lifecycle Requirements: How IEC 62304 Helps You Demonstrate Conformity](/blog/mdr-software-lifecycle-iec-62304) — post 376, the lifecycle overview this architecture post sits inside.
- [MDR Software Safety Classification: Understanding IEC 62304 Class A, B, and C](/blog/software-safety-classification-iec-62304) — post 377, the class determination that the architecture allocates to software items.
- [MDR Software Development Planning: Using IEC 62304 for the Software Development Plan](/blog/software-development-planning-iec-62304) — post 379, the planning activity that defines how architecture will be written and managed.
- [MDR Software Requirements: Using IEC 62304 to Write Compliant Requirements](/blog/software-requirements-iec-62304) — post 380, the activity immediately before architecture.
- [Software Detailed Design Under EN 62304](/blog/software-detailed-design-en-62304) — post 382, the detailed design activity that follows architecture.
- [Software Verification and System Testing Under EN 62304](/blog/software-verification-system-testing-en-62304) — post 383, the activity that proves the architecture implements the requirements.
- [Software Risk Management Integration with EN ISO 14971](/blog/software-risk-management-iec-62304) — post 391, the risk bridge that drives safety classes and segregation arguments.
- [Tool Qualification and Control Under EN 62304](/blog/tool-qualification-en-62304) — post 417, the controls on tools whose output enters the architectural file.
- [The Subtract to Ship Framework for MDR Compliance](/blog/subtract-to-ship-framework-mdr) — post 065, the methodology pillar this post applies to software architecture.

## Sources

1. Regulation (EU) 2017/745 of the European Parliament and of the Council of 5 April 2017 on medical devices, Annex I Section 17; Annex II. Official Journal L 117, 5.5.2017.
2. EN 62304:2006+A1:2015 — Medical device software — Software life-cycle processes (IEC 62304:2006 + IEC 62304:2006/A1:2015), Section 5.3 Software architectural design. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.
3. EN ISO 14971:2019+A11:2021 — Medical devices — Application of risk management to medical devices. Harmonised standard referenced for risk management under MDR Annex I.
4. EN ISO 13485:2016+A11:2021 — Medical devices — Quality management systems — Requirements for regulatory purposes. Harmonised standard referenced for the QMS under MDR Article 10(9) and Annex IX.

---

*This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the software architectural design activity required by EN 62304:2006+A1:2015 Section 5.3. Authored by Felix Lenhard and Tibor Zechmeister. The MDR is the North Star for every claim in this post — EN 62304:2006+A1:2015 is the harmonised tool that provides presumption of conformity with the software-lifecycle aspects of MDR Annex I Section 17, and the software architecture is part of the technical documentation required by MDR Annex II, not an independent authority. For startup-specific support on documenting software architecture that matches a real engineering team, handles SOUP correctly, and survives Notified Body audit, Zechmeister Strategic Solutions is where this work is done in practice.*

---

*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).*