Software in Medical Devices, by MD101 Consulting

March 2021 edit: see there the latest news on IEC 62034 2nd edition.

Major changes

The first major change is the product scope covered by this new version. In the will of alignment of IEC 82304-1 and IEC 62304, the latter has now an extended product scope with a better coverage of the former: Health Software. To be sure that the reader understands that both are aligned, the diagram found in IEC 82304 Annex A has been copied into IEC 62304 Clause 1 "Scope". We can anticipate that the next version of IEC 82304-1 will see the diagram in annex A be moved to Clause 1 accordingly.
Yet, the big difference between IEC 62304 and IEC 82304-1 remains: IEC 62304 covers embedded software, not IEC 82304-1 (replaced by IEC 60601-1 for embedded software).

Risk management and cybersecurity

The wording of clause 4.2 on risk management process has been reviewed, to cope with cases where no hazardous situation exists (most probably some health software not qualified as medical device). But this has no impact on medical devices.

The major change in this clause is the appearance of Security, equivalent to the more popular term: cybersecurity. Thus, compliance to IEC 62304 2nd edition will require a software lifecycle that fully implements a cybersecurity management process.
Mirroring this change, the list of potential causes of contribution in clause 7.1.2 has been updated. See below.

Usability everywhere

A new clause 4.3 is added, requiring a usability engineering process. The standard on usability and human factors engineering, IEC 62366-1, is referenced in a note at the bottom of this clause.
This clause is consistent with ISO 13485:2016, which requires usability in design inputs, and refers to IEC 62366-1.
Note that the clause on software safety class is now clause 4.4, pushed down by the new clause 4.3 on usability.

Legacy software

Validation of legacy software was introduced in the Amendment 1 in 2015. It is still present in the 2019 draft, with the same spirit: a kind of retrospective validation based on analysis of post-market data, gap analysis and gap closure.
To be aligned with clauses 4.2 and 4.3, legacy software validation found in clause 4.5 requires addressing usability and cybersecurity, on top of safety risks.

But the very major change about legacy software is dug into the details of the wording: the clause 4.5.4.c was changed (emphasis is mine):

• From: Changes to the LEGACY SOFTWARE shall be performed in accordance with clause 6
  
• To: Changes to the LEGACY SOFTWARE shall be performed in accordance with this document
  

Clause 6 deals with software maintenance only, namely for patches or minor changes. Conversely, This document means that we can refer to clause 5 about software development.

Thus, we can take a legacy software, perform the retrospective validation, and declare it is compliant to IEC 62304. Then from this legacy version, we can create a new major version where we will document, according to clause 5, only the parts new or modified in this major version!
This is magic!
Hurray to the IEC 62304 working group!


These are the only major changes. Medical device manufacturers, your gap analysis won't be too heavy.

Minor changes in 4.4 software safety class

The most prominent change is the rework of the clause about software safety class, now 4.4, hence 4.3 is for the new clause about human factors engineering.
While the text has been quite amended, the assessment of the software safety class hasn't changed in substance, e.g. still 100% probability of software failure, still a dose of acceptability for class A. Changes were obviously brought for the sake of clarity.
Several notes are added, two of which could retain your attention:

• Note 3: Software failures are not only bugs, but also requirements failures, or failures in human factors,
• Note 6: External risk control measures can be not only hardware or external system, but also healthcare procedures or other means.

Note 3 closes a possible discussion on the fact that foreseeable misuse of software isn't a software failure. Yes, wrong GUI, wrong man-machine interaction can be a software failure, which shall be undertaken in the assignment of a software safety class! This has all the more been present in clause 7.1.2 since the first version of the standard in 2006.

Note 6 closes another possible discussion on the fact that only tangible (hardware, external system) means are acceptable risk control measures. Yes, an intangible healthcare procedure can be a risk control measure!

Minor changes in 7.1.2 potential causes of contribution to a hazardous situation

This clause was amended to explicitly cover all the potential causes of hazardous situations related to software, in design and at runtime.

Common software defects

The clause 5.1.12 about identification and avoidance of common software defect has vanished! It hasn't been moved to another location in the text.
Rest assured, the requirement is still there, merged into the list of potential causes of contribution to a hazardous situation : 7.1.2 f) defects that may be based on the selected programming technology, including programming language issues.
This is actually more consistent to find this in the chapter on software risk management process, rather than in the software development plan.

Defects from software tools

In the same vein, the list of potential causes of contribution to a hazardous situation now contains 7.1.2 e) defects that may be introduced by the used software environment, including tools and libraries; defects that may be introduced by the software development environment.
This closes a third discussion on the fact that failure of software design tools shall be included in the identification of risks. Although they are not SOUP within a strict interpretation of the definition of SOUP found in IEC 62304, they are Off-The-Shelf Software (OTSS, FDA acronym) and they can contribue to a software failure. E.g. an error of compilation.

Cybersecurity

As mentioned above, the list also contains 7.1.2 h) cyberattacks and security breaches (e,g., denial of service, malware hacking, unauthorized access via user interface). Thus cybersecurity vulnerabilities have to be taken as a hazardous phenomenon with regard to ISO 14971. This is pretty well synthesized in the Figure B.1 of informative Annex B.

IEC 62304:2019 CDV contains quite a good update of clause 7.1.2. It now contains a very comprehensive list of potential software causes of contribution to a hazardous situation.

Other changes

Dozens of notes, rewording for clarification, references to other standards, a very articulate Annex B with examples on how to assign a software safety class. These are the other minor changes.
The reason is obviously to make the standard more readable per se, and more readable by people who are not used to medical devices standards. Like medical device start-ups, or ... health software vendors.

Signing session

To my mind, The members of the IEC 62304 2nd edition working group could organize a signing session! When it is published, in 2020.

Manufacturers of software in class I falling into class IIa, your technical file is not very ... up-to-date? You're the happy owners of legacy software? Don't pretend your documentation is up-to-date, and enjoy the new legacy software requirements. The working group members are waiting for you at the signing session with your (very expensive) hardcopy of IEC 62304 2nd edition!