EN 62304:2006+A1:2015 Section 5.4. Software detailed design. Is required for Class B and Class C software only. For Class A software, the standard does not require a detailed design activity; the architecture from Section 5.3 and the implementation from Section 5.5 are the two documented levels. For Class B, the required depth is decomposition of each software item into software units with documented interfaces between units. For Class C, the required depth is the fullest refinement. Each unit specified at a level that supports direct implementation and supports the Class C acceptance criteria categories that Section 5.5 calls out. The scope of the activity scales with the software safety class. The MDR is the North Star; EN 62304:2006+A1:2015 is the harmonised tool that operationalises the detailed design obligation under MDR Annex I Section 17.2.

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

TL;DR

  • EN 62304:2006+A1:2015 Section 5.4 requires software detailed design only for Class B and Class C software items. Class A items are not required to go through Section 5.4 as a distinct activity.
  • For Class B, the standard requires each software item to be decomposed into software units, with the interfaces between units documented.
  • For Class C, the standard requires the fullest refinement. Each unit specified at a depth that supports direct implementation and supports the Class C acceptance criteria categories under Section 5.5.
  • A Class A item can legitimately skip Section 5.4 only if the EN ISO 14971:2019+A11:2021 risk analysis supports the Class A claim and the architecture either avoids sharing resources with higher-class items or carries a documented segregation argument under Section 5.3.
  • The detailed design is part of the design information in the technical documentation under MDR Annex II. Notified Bodies read it as structural evidence that unit verification under Section 5.5 has acceptance criteria to verify against.
  • The cheapest mistake is bulk-assigning every item to Class C and paying the Section 5.4 cost across the whole system. The most expensive mistake is bulk-assigning every item to Class A and getting caught at audit.

Why "how much" is the question that decides the schedule

Most teams that hit Section 5.4 of EN 62304:2006+A1:2015 for the first time ask two questions in the wrong order. They ask "how do we write detailed design" before they ask "how much detailed design do we owe, and for which parts of the system." Getting the second question right is what keeps the activity proportionate to the risk. Getting it wrong is how a six-person startup ends up writing unit specifications for a configuration parser that could never contribute to a hazardous situation.

The standard is explicit that the depth of Section 5.4 scales with the software safety class assigned at the software-item level. That scaling is not a nicety. It is the mechanism by which EN 62304:2006+A1:2015 prevents the lifecycle from crushing teams whose risk profile does not justify the heaviest activities. A team that respects the scaling arrives at Section 5.4 with a short list of items that need detailed design and a longer list that does not. A team that ignores the scaling arrives with every item treated the same way, and pays the cost on the whole system regardless of where the risk actually sits.

This post is the "how much and when" companion to the how-to. If you want the artefact-level guidance on what the detailed design looks like in the repository and how to keep it in sync with the code, that is a separate question covered in the sibling post on software detailed design IEC 62304. What follows here is the scoping decision that comes first. How deep the activity goes for each class, and when a class can honestly skip it.

What Section 5.4 covers. And where it sits in the lifecycle

Section 5.4 of EN 62304:2006+A1:2015 is the software detailed design clause. It sits between software architectural design (Section 5.3), where the system is decomposed into software items, and software unit implementation and verification (Section 5.5), where the code is written and verified against its acceptance criteria. The function of the clause is to refine the architecture to the software unit level and to specify each unit's behaviour and interfaces at a depth that supports both implementation and unit verification.

The clause has two obligations. First, the manufacturer refines the software architecture into a detailed design by decomposing each software item into software units. Second, the manufacturer documents the detailed design of each software unit and specifies the interfaces between software units and between each software unit and external components. The standard does not prescribe a notation. Structured text, diagrams, tables, pseudocode, or type-annotated signatures with pre- and post-condition statements are all acceptable, as long as the resulting design is specific enough to implement from and to verify against.

Upward, the clause connects to MDR Annex I Section 17, which requires software to be developed in accordance with the state of the art taking into account the principles of development life cycle, risk management, verification, and validation. (Regulation (EU) 2017/745, Annex I, Section 17.) The detailed design is part of the design information in the technical documentation described in MDR Annex II. (Regulation (EU) 2017/745, Annex II.) EN 62304:2006+A1:2015 is the harmonised standard the Notified Body reads to judge whether the software lifecycle satisfies Annex I Section 17.2.

How much detail each class actually needs

The core scoping rule is that Section 5.4 scales with the software safety class assigned to each software item through the EN ISO 14971:2019+A11:2021 risk analysis. The class is not a project-level label. It is an item-level determination, and the Section 5.4 obligation applies item by item.

Class A. Section 5.4 is not required for Class A software items. The standard recognises that a software item that cannot contribute to a hazardous situation, even indirectly, does not justify the formalisation cost of a separate detailed design activity. For a Class A item, the two documented levels under EN 62304:2006+A1:2015 are the architecture from Section 5.3 and the implementation from Section 5.5. Most teams still write some inline comments and type-annotated signatures for Class A code because it helps the engineering, but no detailed design artefact is owed to the regulatory file for a Class A item.

Class B. For Class B software items, Section 5.4 requires the manufacturer to refine the architecture so that each software item is decomposed into software units, and to document the interfaces between those units. The required depth is enough to give unit implementation a target to build against and unit verification something concrete to verify. The specification does not have to address every Class C category. The standard calibrates Class B as the middle tier because Class B items can contribute to a non-serious injury but not to death or serious injury, and the formalisation depth reflects that.

Class C. For Class C software items, Section 5.4 requires the fullest refinement. Each software unit is specified at a depth that supports direct implementation and supports the Class C acceptance criteria categories that Section 5.5 calls out for unit verification. Event sequencing, data and control flow, resource allocation, fault handling, initialisation, self-diagnostics, memory management, and boundary conditions. The specification has to be specific enough that unit verification can check the unit against these categories without inventing the criteria after the fact.

The short version. Class A: no detailed design activity owed. Class B: item decomposed into units, unit interfaces documented. Class C: every unit specified at a depth that supports direct implementation and verification against the Class C categories.

When Class A can legitimately skip the activity

The most consequential scoping question on most projects is which items can honestly be classified as Class A and skipped. The answer is not "whichever items you do not want to document." The answer is governed by the EN ISO 14971:2019+A11:2021 risk analysis at the software-item level and by the architecture decisions recorded under Section 5.3.

A software item is Class A only if it cannot contribute to a hazardous situation, even indirectly, as determined by the risk analysis applied honestly to that item. The "even indirectly" is the part that gets most teams. A configuration loader that feeds parameters into a Class C risk-control unit is not Class A just because the loader is "only" parsing a file. If wrong parameters can cause the risk control to behave incorrectly, the loader contributes indirectly and the class rises.

There is a second condition. The architecture has to either not share resources with higher-class items, or carry a documented segregation argument under Section 5.3 that isolates the Class A code from the higher-class code. Without segregation, the highest class applied in the system propagates across shared resources and the whole subsystem inherits it. A team that has a single monolithic back end with Class C risk-control logic embedded inside it cannot claim Class A anywhere in that back end. The whole thing is Class C, and Section 5.4 applies to all of it.

If both conditions are met. Honest Class A per risk analysis, and no shared resources with higher-class items or a documented segregation argument. The team does not owe a Section 5.4 artefact for the Class A item. That is a legitimate and substantial subtraction. If either condition fails, the Class A claim does not hold and Section 5.4 applies.

Class A vs B vs C. Three concrete examples

Class A example: a read-only log viewer. A back-end service that reads application logs from a database and renders them in a dashboard, with no write path into any clinical data and no influence on any risk control, is a reasonable Class A candidate. The risk analysis documents that the worst-case failure of the log viewer is a display error with no patient impact. The architecture places the log viewer on a separate runtime from the clinical logic. Section 5.4 is not owed for this item.

Class B example: a non-critical measurement display. A module that displays measurement values computed by a Class C calculation engine, where the displayed value can influence a clinician's non-urgent decisions but cannot directly cause death or serious injury, is typically Class B. Section 5.4 applies. The team decomposes the display module into software units. A value formatter, a unit converter, a presentation layer. And documents the interfaces between them. The depth is sufficient to support unit verification, but does not have to address the full set of Class C categories.

Class C example: a therapy-dose calculation unit. A module that calculates a therapy dose whose incorrect value could cause serious injury or death is Class C. Section 5.4 applies at the fullest depth. Each unit. Input validation, the calculation itself, boundary checking, fault handling, the output writer. Is specified at a level that supports direct implementation. Preconditions, postconditions, error modes, resource constraints, and boundary behaviour are all documented, because Section 5.5 verification has to check the unit against these Class C categories.

The three examples share one pattern. The class is determined by the risk analysis, not by subjective judgement about "how important" the code feels. The Section 5.4 depth follows from the class, not from team preference. Get the class right and the depth falls out of the standard.

The right-sized detailed design playbook

The playbook for keeping Section 5.4 proportionate runs in four steps.

Step 1. Classify honestly, item by item, with the risk analysis. Every software item in the architecture gets a class assigned through EN ISO 14971:2019+A11:2021 applied at the item level. No bulk assignment in either direction. The risk analysis records the reasoning for each class and the evidence that supports it.

Step 2. Record the segregation decisions from Section 5.3. Where the architecture uses segregation to isolate higher-class items from lower-class items, the segregation argument is documented as part of the architecture. Without that documentation, Class A claims that depend on segregation will not survive audit.

Step 3. Scope the Section 5.4 activity by class. The project plan lists the items that owe detailed design. Class B and Class C only. And specifies the depth for each. Class A items are listed as out of scope for Section 5.4, with a reference to the risk analysis and the segregation argument. Class B items are scoped to item decomposition and interface specification. Class C items are scoped to the full refinement.

Step 4. Run the activity, then close the traceability chain. For every Class B and Class C item, the detailed design is written where the code lives, versioned with the code, and linked to the architecture upstream and to the acceptance criteria and unit verification cases downstream. The traceability chain is the evidence that the scoping decisions from steps 1–3 were followed through.

This playbook is deliberately shorter than the how-to on what detailed design looks like in the repository. The how-to is covered separately in the sibling post on software detailed design IEC 62304. The point of the scoping playbook is to decide the schedule and the budget before any unit specification is written, so the team does not pay for depth that the standard does not require.

Reality Check. Have you scoped Section 5.4 honestly?

  1. Have you classified every software item using the EN ISO 14971:2019+A11:2021 risk analysis applied at the item level, rather than a project-wide class label?
  2. For every Class A item you are planning to skip under Section 5.4, does the risk analysis record that the item cannot contribute to a hazardous situation even indirectly?
  3. Where your Class A claims depend on architectural segregation from higher-class items, is the segregation argument documented as part of Section 5.3?
  4. For every Class B item, is the planned Section 5.4 depth scoped to item decomposition into software units and interface documentation?
  5. For every Class C item, is the planned Section 5.4 depth scoped to support direct implementation and the Class C acceptance criteria categories that Section 5.5 calls out?
  6. Does your project plan list the Section 5.4 scope item by item, so the depth per item is decided before the activity starts rather than improvised during it?
  7. Would a Notified Body reviewer reading the scoping record agree that the Section 5.4 depth applied to each item is proportionate to its software safety class under MDR Annex II?

Any question you cannot answer with a clear yes is a scoping gap that will either surface at audit or cost the team more work than the standard requires. Close it before the activity begins, not during it.

Frequently Asked Questions

When does EN 62304:2006+A1:2015 require software detailed design? EN 62304:2006+A1:2015 Section 5.4 requires software detailed design for Class B and Class C software items. For Class A items, Section 5.4 is not required as a distinct activity. The architecture from Section 5.3 and the implementation from Section 5.5 are the two documented levels. The obligation scales with the software safety class assigned through the EN ISO 14971:2019+A11:2021 risk analysis at the software-item level.

How much detail does Class B software actually need under Section 5.4? For Class B software, Section 5.4 requires each software item to be decomposed into software units, with the interfaces between units documented at a depth sufficient to support unit implementation and verification. Class B does not require the full set of Class C acceptance criteria categories, but the interfaces between units have to be specific enough that unit verification has documented criteria to check against.

What extra depth does Class C software require compared to Class B? For Class C software, Section 5.4 requires the fullest refinement. Each unit is specified at a level that supports direct implementation and supports the Class C acceptance criteria categories under Section 5.5. Event sequencing, data and control flow, resource allocation, fault handling, initialisation, self-diagnostics, memory management, and boundary conditions. Class B can stop at item decomposition and interface specification; Class C has to reach unit-level behavioural specification.

Can a Class A software item legitimately skip Section 5.4 entirely? Yes, provided two conditions hold. First, the EN ISO 14971:2019+A11:2021 risk analysis supports the Class A assignment. The item cannot contribute to a hazardous situation, even indirectly. Second, the architecture either avoids sharing resources with higher-class items or carries a documented segregation argument under Section 5.3. If both conditions are met, Section 5.4 does not apply to the item and no detailed design artefact is owed for it.

Is there a shortcut where every item is assigned to Class A to avoid Section 5.4? No. The software safety class is determined by the risk analysis at the item level, not by convenience. A Class A claim that is not supported by the risk analysis or the segregation argument will not survive a Notified Body review of the risk file and the software lifecycle documentation. The cheaper mistake is bulk-assigning to Class C and overspending; the more expensive mistake is bulk-assigning to Class A and getting caught.

Where does the Section 5.4 output sit in the MDR technical documentation? MDR Annex II lists the design and manufacturing information the technical documentation must contain, and the detailed design for Class B and Class C software items is part of the design information for any device where software qualifies as a medical device or is an integral part of the device. (Regulation (EU) 2017/745, Annex II.) The Notified Body reads the detailed design as structural evidence that unit verification under Section 5.5 has documented acceptance criteria to verify against.

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 (Technical Documentation). 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.4 Software detailed design and Section 5.5 Software unit implementation and verification. Harmonised standard referenced for the software lifecycle under MDR Annex I Section 17.2.
  3. EN ISO 14971:2019+A11:2021. Medical devices. Application of risk management to medical devices. Harmonised standard referenced for the software safety class determination that scales Section 5.4.

This post is a category-9 spoke in the Subtract to Ship: MDR blog, focused on the scoping of EN 62304:2006+A1:2015 Section 5.4 by software safety class. 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 operationalises the detailed design obligation under MDR Annex I Section 17.2, and the detailed design output is part of the technical documentation under MDR Annex II. For startup-specific support on honest software classification and proportionate detailed design scoping, Zechmeister Strategic Solutions is where this work is done in practice.