Failure analysis of the 2nd editions of IEC 62304

A group of experts from the IEC/SC62A + ISO/215/JWG7 committees were appointed by to determine the causes of failure of the three projects of the 2nd edition of IEC 62304 and to define recommendations for the new version of the standard, with the aim of helping the committees national authorities to develop a more assertive version of the norm.

The 2nd edition project went through 3 CDVs* without an agreement between ISO and IEC, the main dispute was in defining which quality system requirements require Risk Management.

As time went by, other points did not find consensus either:

▫Safety classification (based on injury)

▫legacy SW

▫Lack of provisions for new technologies (ex. IA)

The group recommended that design 62304 Edition 2.0 should have a design specification based on specific requirements, in addition to:

The 2nd edition project went through 3 CDVs (Committee draft for voting - Document prepared by the study group to be evaluated by the commission) without an agreement between ISO and IEC, the main dispute was in defining which quality system requirements require Quality Management Risk.

As time went by, other points did not find consensus either:

▫Safety classification (based on injury)

▫legacy SW

▫Lack of provisions for new technologies (ex. IA)

The group recommended that design 62304 Edition 2.0 should have a design specification based on specific requirements, in addition to:

2) Extending the scope to include healthcare software was problematic to reach consensus on the standard. The scope of the standard should be left to IEC/SC62A, ISO/TC215 (and ISO/TC210) and national committees to decide on the need for standardization for healthcare software lifecycle processes.

Expanding the scope for healthcare software was a central point in reaching consensus on the 2nd edition of 62304 due to the differing interests of the parties involved. A set of stakeholders wanted the standard for medical devices and regulatory use, making it challenging to be unbiased about the regulatory for healthcare software. There also continues to be a discussion that medical device software is regulated differently across jurisdictions - what is medical device software in one jurisdiction is not in another jurisdiction.

The question is, is this a problem to be solved by the standard? Or is it up to the manufacturer to choose the standards to be used?

If this is an issue to be resolved by the standard, the group recommends not diluting the requirements of IEC 62304 to include healthcare software at risk of ed2 not being recognized by the FDA or harmonized in the EU.

Another point to be aware of is that restricting the scope of IEC 62304 to medical device software can cause problems calling the IEC 82304-1 standard (which covers SaMD and non-medical healthcare software products). This will also leave a gap in the ISO / TC215 standards architecture for healthcare software development/maintenance processes.

IEC 82304-1: HEALTH SOFTWARE PRODUCTS is intended for the MANUFACTURER to manage, maintain or improve the health of individual persons or the provision of care. HEALTH SOFTWARE refers to software that contributes to the health of individual persons as observed and/or demonstrated using measurable health parameters or clinical experience.

*software as a medical device (etc.) - SaMD is software that performs one or more medical functions. Although the software may be embedded in a piece of hardware (as is often the case), it is the software itself that performs the medical function.

3) A short development cycle for the draft standard would be beneficial (3-year development cycle).

The experience of the 62304 2nd Edition design team shows that the project took a long time (6 years). Over that time, some initial fundamentals changed 180 degrees due to the regulatory environment and there was a “scope increase” to add new requirements for the state of the art. This contributed to the difficulty of reaching consensus between ISO and IEC stakeholders.

4) The standard should help manufacturers work with outside contractors.

There is an industry trend towards outsourcing software development, even to developers not specializing in the medical device industry. Software outsourcing could be better supported by increasing the clarity of the standard in the following areas:

1. a) The process interface between the processes at the product manufacturer level and the software development processes
3. b) Compliance with process rigor levels through the development of outsourced software based on the risk assessment by the product manufacturer
5. c) A balance between the prescribed process outcomes needed by the manufacturer with the software vendor's need to protect its intellectual property
7. d) The criteria used by the manufacturer to evaluate a candidate for software development outsourcing and its compliance with the standard

5) The standard should define requirements to control tools and support methods necessary to achieve defined software requirements.

For example, how and with which AI algorithm should be trained. The standard should not include detailed requirements on how to train a net. Still, it should require that this training be documented as part of any other design documentation that allows for repeatability of the software build.

6) There were comments that the standard should consider providing more details of other development process models (eg agile vs. waterfall models)

The group feels that the standard should be impartial in the choice of development model.

Providing informative appendices on using 62304 requirements with different development models would be helpful for users and evaluators. The development of a “Guidance for the application of IEC 62304” could also be considered, as ISO / TR24971 was developed for the ISO 14971 risk management standard.

7) There were comments that the standard should consider more modern deployment models and hardware infrastructure.

The current standard has many SiMD examples, but a more diverse set of examples should be considered, including cloud computing.

The acronym SIMD (Single Instruction, Multiple Data), describes a method of operation of computers with several operational units in parallel computing. In this mode, the same instruction is applied simultaneously to several data to produce more results.

8) Normative references to medical device standards were problematic within the IEC 62304 healthcare software lifecycle standard. Stakeholders have different views on whether such normative references are useful and necessary.

An alternative could be to define process / information flow interfaces, such as:

• ▫System / product requirements and architectural information flow between system and software processes
• ▫Risk management allocation (flow of risk management information between system and software processes (hazardous situations and associated risk)

9) There was an agreement of the interested parties that the conformity assessment should be supported by the definition of measurable results for the assessment.

This will allow evaluators (third-party evaluation or vendor/supplier manufacturer) to more easily assess compliance with the standard. An alternative would be to extend an annex that explains how compliance can be achieved.

• This will be useful for the evaluation of the IECEE CB scheme when included in the IEC 60601-1 test / evaluation.
• Certifying bodies check manufacturers' compliance with the standard. This will allow for an easier verification that the requirements of the standard are being met by the company.

10) Stakeholders had different views on how to manage generic software, which becomes healthcare software.

We received comments that this case should be considered and that legacy software should not be considered.

The group recommends that the standard provide a means of compliance without requiring a complete software redesign.

This is for managing generic software that, due to regulatory changes, suddenly becomes healthcare software or a functional growth that changes the intended use of a product to become healthcare software.

11) Here were stakeholder comments to further define requirements on how to use pre-existing software items (eg software reuse, open source, SOUP)

12) There was a divided opinion on the software's security rating and the different levels of rigor of the process related

There are at least two aspects here.

▫ How the rigor levels of the process are determined, but also whether it is necessary.

▫A complete removal of the process rigor approach will likely result in a standard with the highest process rigor (Class C) to satisfy regulatory requirements.

▫ However, to allow for a scope expansion, we as a group find it logical to expect another process rigor for a harmless application compared to a life support control software system.

There are several possible methods for determining the software rating that can be further investigated.

▫Todays classification is based on injuries, and the group suggests basing the classification on damage instead. This change would better align with ISO 14971 and better include security aspects than is possible today.

▫It is also suggested to adopt the 62304 CDV3 modifications in the flowchart to remove the “escape route” to level A.

▫The group recommends adopting proposed change 62304 CDV3 for process rigor levels (versus software safety rating).

▫There was a view that determination of software rigor level should be done by calling standards (ie outside 62304) because such a decision should be made by risk management activities at the product/system level. This method would need additional coordination with the so-called standards and development standards committee.

▫62304 CDV3 also included an informative annex on the SaMD risk categorization and how the rigor levels of the 62304 process might align. The group recommends the adoption of this information in a new 2nd edition.

13) There were different opinions on how much of the lifecycle should be included in the standard.

As a group, we recommend adopting the decommissioning addition that was included in 62304 CDV3.

Other improvements may include selecting and maintaining the proper use of SOUP items or managing software system updates and re-releases.