IEC 62304 2nd Edition: All Areas of Application and Changes

For years, the standards committee has been striving to revise the first edition of IEC 62304, which dates back to 2005 – a time before the iPhone. Consequently, there are growing doubts as to whether the standard still reflects the state of the art.
This article provides information on the current status and objectives of the 2nd edition of IEC 62304.

The Latest News in Brief

Timetable

Following the 2025 “Committee Draft” (CD1), the IEC SC62A MT49 working group had to incorporate just under 1,500 comments. It now plans to publish not the second edition of the standard, but the second Committee Draft (CD2) in the coming weeks.

Consequently, an FDIS is not expected until 2028, which means publication may not take place until 2029. This is possibly more realistic than the current ‘Forecast Publication’ (October 2028) according to the IEC.

In parallel, the CENELEC working group intends to begin work on the Z annexes shortly, so that these can then be published at the same time, enabling the standard to be listed in the Official Journal as a harmonised standard for the MDR and IVDR.

Contents

The new edition of IEC 62304 stipulates as a “Design Spec” that the level of detail and the rigour of the methods and controls should be “commensurate” with the product (intended use, risk). I interpret this as ‘risk-based’. The ‘Design Spec’ states:

• “4.2 IV The risk management process used at the product level should be commensurate with the intended use of the product and the software.”
• “5.1 Planning is a key element of good software; however, it is often not robust. Planning documentation is required for all levels of rigour of software within the scope of this standard. This section of IEC 62304 should be made more explicit and specific in order to adequately describe the application of methods for a specific software development project commensurate with the required level of rigour (e.g., design review methods: pair programming (lowest level of rigour) to formal review methods (highest level of rigour)).”

Within the German committee DKE AK 804.3.1 “Software”, there is a desire to describe a comprehensive and uniform approach to how the concept set out in 5.1 can be put into practice. The Software Development Plan is regarded as an obvious and suitable place to document this approach.

It is being discussed that, in such a document for Software Process Rigor Level II (SPRL II), manufacturers could in fact reintroduce the old Safety Classes B and C to a certain extent. This would leave the old process unchanged, whilst ensuring compliance with the new planned edition.

History of IEC 62304 (2nd edition)

The first version of the standard was published as IEC 62304:2006. Apart from an editorial correction in 2008, the standard remained unchanged for almost 10 years. It was not until 2015 that Amendment 1 (A1:2015) was published. The consolidated and current version of the standard is IEC 62304:2015. Although this version has not yet been harmonised, it represents the state of the art.

The standards committee has since also finalised IEC 82304-1. Its aim is to address health software that is not a medical device or part of one.

At the same time, the standards committee was working on the 2nd edition of IEC 62304. However, its status was marked as ‘withdrawn’ at the turn of the year 2021/2022.

The following standards are therefore in force:

• IEC 62304:2006 (with a correction in 2008)
• IEC 62304:2015 (IEC 62304:2006 + correction in 2008 + Amendment I in 2015). This version is also referred to as ‘Version 1.1’.
• IEC 62304 (2nd edition). This version was initially available as a draft under the designation IEC/DIS 62304 (2nd edition). However, its status was changed to ‘withdrawn’.

Scope of Application of IEC 62304, 2nd Edition

Unlike the previous standards, the 2nd edition applies to ‘health software’ and no longer solely to ‘medical device software’.

Health Software is a superset of Medical Device Software and is not limited to medical devices.

Medical device software may form part of a medical device or constitute a medical device in its own right (stand-alone software).

Changes introduced by the 2nd edition of IEC 62304

The structure of the chapters already suggests that the changes will remain manageable:

IEC 62304 „version 1.1“ Medical device software – software life cycle processes	IEC 62304 „version 2“ Health software – software life cycle processes	Comment
1 Scope	1 Scope	Now „Health Software“ instead of „Medical Device Software“
1.1 Purpose	1.1 Purpose
1.2 Field of application	1.2 Field of application
1.3 Relationship to other standards	1.3 Relationship to other standards
1.4 Compliance	1.4 Compliance
2 Normative references	2 Normative references
3 Terms and definitions	3 Terms and definitions	Additions and amendments (see ‘Criticism’)
4 General requirements	4 General requirements
	4.1 Legal and regulatory obligations	Manufacturers must identify and comply with all relevant regulatory requirements. This is already a requirement under ISO 13485:2016 (German, translation follows).
4.1 Quality management system	4.2 Quality management system
4.2 Risk management	4.3 Risk management	In justified cases, compliance with ISO 14971 is no longer required.
	4.4 Security Risk management	Security is explicitly demanded as part of risk management (see ‘Criticism’).
	4.5 Usability engineering	Manufacturers must manage risks arising from a lack of fitness for purpose. IEC 62366 is not a mandatory standard.
4.3 Software safety classification	4.6 Software safety classification	Minor but significant changes; see below under ‘Issues’ and ‘Improvements’
4.4 Legacy software	4.7 Legacy software
5 Software development process	5. Software development process
5.1 Software development planning	5.1 Software development planning
5.2 Software requirements analysis	5.2 Software requirements analysis
5.3 Software architectural design	5.3 Software architectural design
5.4 Software detailed design	5.4 Software detailed design
5.5 Software unit implementation and verification	5.5 Software unit implementation
5.6 Software integration and integration testing	5.6 Software integration and integration testing
5.7 Software system testing	5.7 Software system testing
5.8 Software release	5.8 Software release for utilization at a system level
6 Software maintenance process	6. Software maintenance process
6.1 Establish software maintenance plan	6.1 Establish software maintenance plan
6.2 Problem and modification analysis	6.2 Problem and modification analysis
6.3 Modification implementation	6.3 Modification implementation
7 Software risk management process	7 Software safety risk management process
7.1 Analysis of software contributing to hazardous situations	7.1 Analysis of software contributing to hazardous situations
7.2 Risk control measures	7.2 Risk control measures
7.3 Verification of risk control measures	7.3 Verification of risk control measures
7.4 Risk management of software changes	7.4 Risk management of software changes
8 Software configuration management process	8. Software configuration management process
8.1 Configuration identification	8.1 Configuration identification
8.2 Change control	8.2 Change control
8.3 Configuration status accounting	8.3 Configuration status accounting
9 Software problem resolution process	9 Software problem resolution process
9.1 Prepare problem reports	9.1 Prepare problem reports
9.2 Investigate the problem	9.2 Investigate the problem
9.3 Advise relevant parties	9.3 Advise relevant parties
9.4 Use change control process	9.4 Use change control process
9.5 Maintain records	9.5 Maintain records
9.6 Analyse problems for trends	9.6 Analyse problems for trends
9.7 Verify software problem resolution	9.7 Verify software problem resolution
9.8 Test documentation contents	9.8 Test documentation contents

This overview shows that no chapters have been omitted, but that a number of subchapters have been added. The changes include, in particular, the following:

Scope

The ‘2nd edition’ of IEC 62304 is intended to remain applicable to standalone and embedded software (i.e. as a medical device or part of one). However, it is also intended to apply more generally to health software. This means that for software in fitness equipment and standalone software such as fitness apps, the 2nd edition of IEC 62304 describes the state of the art.

For medical device manufacturers, the changes are therefore significant.

Consequently, the title of the standard changes from ‘Medical Device Software’ to ‘Health Software’.

Safety Classes

The definition of safety classes, as already published in Amendment I to IEC 62304, is incorporated into the 2nd edition of IEC 62304. There is, however, one minor change, which we discuss below.

New Requirements for the Requirements

The software requirements (Chapter 5.2) must explicitly take into account the aspects of Safety and Security. This includes requirements to ensure cyber security. New in this context is the term Security Threat Management.

A separate sub-chapter is also devoted to the topic of usability.

Risk management

The IEC 62304 2nd edition abandons the normative requirement for risk management in accordance with ISO 14971. The manufacturer may justify the use of other process models. Whether the Notified Bodies will go along with this is, of course, another matter.

Criticism

The changes in the 2nd edition of IEC 62304 are manageable. This makes the transition much easier. The latest version of the standard retains tried-and-tested concepts. Unfortunately, it also retains old problems.

Old Problems Remain

a) Definitions

We still haven’t got rid of the terms ‘software item’ and ‘software unit’. Developers have a different understanding of ‘software unit’ and miss the concept of the software component. But perhaps a change would have caused too much ‘upheaval’.

b) Software Safety Classification

The rules for determining the safety class were significantly improved by Amendment 1. Unfortunately, the standard still contains the sentence ‘The probability of a software failure shall be assumed to be 1.’ Manufacturers tend to overlook the explanatory sentence accompanying this (which is simply about determining the safety class).

c) Sequences

Both Figure 1 and the order of the chapters suggest to the reader that there is a sequence of the following activities:

1. Draw up a software development plan
2. Define software requirements
3. Design the software architecture

At first glance, this seems sensible. But how can one specify tools in the development plan before the requirements and the technical implementation (architecture) are clear? Of course, an iterative approach is permissible. But some requirements would be better dealt with in other sections.

This applies not only to tools such as those for code analysis, but equally to those for configuration and version management.

d) Software Requirements

IEC 62304 leaves the problematic Chapter 5.2 unchanged. The original authors had drawn on ISO 9126 (German, translation follows). In doing so, they largely undermined the logic of ISO 9126. The result was a chapter that lacks conceptual integrity and is, in parts, misleading. Examples:

• Functional and performance requirements are orthogonal to one another. Requirements for the runtime environment are likewise orthogonal. IEC 62304 throws all this into disarray.
• Do interfaces to other systems not count as inputs and outputs?
• Requirements relating to ‘data definition and databases’ are only very rarely part of the software requirements. These are aspects of the solution space, specifically the software architecture.
• Regulatory requirements are classified as stakeholder requirements. Only in exceptional cases should these be incorporated unchanged into a Software Requirements Specification (software requirements).

The consequences of this suboptimal chapter, which we observe in practice on a daily basis, are:

• The blurring of the distinction between stakeholder requirements and product/software requirements. ISO 13485 makes a clear distinction between the two.
• The blurring of the distinction between software requirements and software architecture
• Software requirements that merely reference regulatory requirements
• Software requirements that, whilst covering the aspects of IEC 62304, are unusable as input for development. In some cases, even large corporations produce two versions of this documentation: one for the auditors and one for the developers.
• An illogical structure of the Software Requirements Specification and/or a chapter structure modelled on that of Chapter 5.2

e) “Software Detailed Design”

Furthermore, the 2nd edition of IEC 62304 also requires a “detailed design” to be developed for each software unit. How is this supposed to work? A software unit is a software component which the manufacturer does not break down any further. Now, the manufacturer is required to develop a detailed design for this component. A design corresponds to a detailed architecture. And architecture is defined as the decomposition of a system into components and a description of the interfaces between them.

What does IEC 62304 expect from manufacturers in Chapter 5.4.2?

f) Acceptance Criteria for Software Units

Work on IEC 62304 began more than 10 years ago. The fact that programming languages have evolved since then appears to have been overlooked in the list of acceptance criteria in Chapter 5.5.4. A look at the TIOBE Index might be helpful in identifying the most important programming languages – and in proposing somewhat more specific and up-to-date acceptance criteria.

Whether a standard should address technical details such as the initialisation of variables at all is another matter entirely.

g) Agility

Agility is a reality in most software development departments, in a wide variety of forms. The FDA is at least attempting to provide guidance through TIR 45. IEC 62304 (2nd edition) does not even mention this document.

What does it do instead? Whilst it does mention the possibility of agile development, it uses the (flawed) diagram of the V-model from IEC 60601-1. It is obvious what manufacturers will conclude from this.

h) Problem-Solving and Maintenance Processes

The standard does not describe the interaction between the problem-solving process (German, translation follows), the maintenance process and the configuration management process particularly well. It is only in the informative annex that it becomes clear how the authors intended to distinguish between the problem-solving and maintenance processes in particular.

Many manufacturers do not really understand why both processes impose requirements on problem reports. It is unclear to them within the framework of which process these reports are to be drawn up, evaluated and taken into account.

New problems are Introduced

Unfortunately, the latest version of the standard also introduces new problems:

a) Definitions of Terms

After Amendment I had finally adopted the definitions of terms such as harm, hazard and hazard situation from ISO 14971, the draft standard reverts once again to ISO/IEC Guide 51:2014. This does not make things any easier for manufacturers.

b) Security Risk Management

It is not immediately clear why risk management is being split into ‘risk management’ and ‘security risk management’. Of course, this aspect is becoming increasingly important. However, the requirement can be (mis)interpreted as suggesting that a second risk management system is necessary.

Similarly, the reference to ISO 27000 is misleading. Even though the concepts overlap, the IT security of a product is not the same as the IT security of an organisation.

c) Is risk Management in Accordance with ISO 14971 Mandatory?

On the one hand, the new IEC 62304 does not insist on compliance with ISO 14971 in every case. On the other hand, risk control measures must be defined, implemented and documented in accordance with ISO 14971.

Improvements

The 2nd edition offers a number of improvements for manufacturers:

a) Regulations

The changes bring the 2nd edition of IEC 62304 even closer to the FDA’s requirements.

Usability engineering is now explicitly required. At the same time, IEC 62366 is no longer a normative requirement. This makes sense, as the 2nd edition of IEC 62304 is not limited to medical device software.

b) Safety Classification

The decision tree no longer contains the almost absurd phrase “Does failure of the software result in unacceptable risk?”. If that were the case, only Safety Class A software would have been possible. It now reads “Considering the external RCM: Can the hazardous situation lead to unacceptable risk?”.

This isn’t quite brilliant yet: the probability is now embedded, on the one hand, in the risk itself and, on the other, in the word ‘can’. This will require further clarification. Or a better Version 2.0.

Conclusion

To speak of a second edition of IEC 62304 is perhaps a bit of an exaggeration. The changes introduced by Amendment 1 were almost more significant. But version 1.2 doesn’t sound quite as ambitious as version 2.

Anyone wishing to extend the scope to ‘Health Software’ should do more than simply replace the term ‘Medical Device Software’ with ‘Health Software’. Using largely the same set of tools, the standard targets software that is a medical device or part thereof, as well as other software.

Because the changes are so manageable, manufacturers will be able to upgrade relatively quickly and easily. The second edition of IEC 62304 does not seem to fully capitalise on the opportunities for a quantum leap and for resolving long-standing issues.

Nevertheless, it remains my favourite standard.

---

Version history:

• 2026-07-02: Introduction revised; ‘Latest News in Brief’ section added; the rest of the article has not yet been fully updated to reflect the latest draft version
• 2022-06-01: Note on the current status updated