Software in Medical Devices, by MD101 Consulting

Let's see again the graphic representing the relationships of IEC 82304-1 with other standards. It requires IEC 62304 but not ISO 14971.
How is it possible and what are the consequences?

References to IEC 62304

IEC 82304-1 references several times IEC 62304 in the requirements or in the notes.
The main reference is in the section 5 of IEC 82304-1 titled HEALTH SOFTWARE - software lifecycle process:

• It references sections 4.2, 4.3, 5, 6, 7, 8 and 9 of IEC 62304,
• It doesn't reference the section 4.1 (the section about QMS) of IEC 62304,
• It doesn't reference the section 1 either (and particularly section 1.4 about the compliance with IEC 62304).

Anyway, given the small subset of requirements not applicable, all the more those with little consequences on software development and maintenance, take it for granted that you have to apply IEC 62304.

Manufacturers of health software, welcome to the marvelous world of IEC 62304 and its costly requirements!

References to ISO 14971

IEC 82304-1 doesn't reference ISO 14971 as a mandatory standard in its requirements. It only requires to:

• perform a risk assessment at system level in section 4.1 Initial RISK ASSESSMENT of HEALTH SOFTWARE PRODUCT, and
• define risk mitigation actions in the section 4.5 system requirements.
  

But the note at the bottom of section 4.1 suggests to apply the first steps of ISO 14971 to do this initial risk assessment. These first steps are those found in section 4 of ISO 14971.

Guess what?
Are you going to apply a risk management process different from the one described in ISO 14971?
No, this would add complexity to risk management, which is complex enough like that!

So, You are going to apply the first steps of ISO 14971 to do this initial risk assessment!

Logical approach

But this approach remains logical.
IEC 82304-1 requires a preliminary risk assessment at system level, when requirements are perhaps not yet defined (section 4.1 is the very first section of the standard with requirements about health software). Reading between the lines, it says:

• do an initial (or preliminary call it as you want) risk assessment to know where you're going: critical software or risk-free software,
• then write your system requirements with regards to this initial risk assessment.

Consequences at system level

Mimiking the management of software risks of IEC 62304, IEC 82304-1 requires to define mitigations actions in the form of system requirements (software requirements for IEC 62304).
IEC 82304-1 also requires to validate the health software product. Thus the validation plan shall contain tests, which bring evidence that the mitigation actions are in place and effective (like software system tests for IEC 62304).

Types of risks

Risks found and mitigated at system level will include a larger set of hazardous situations, that are not addressed explicitly by IEC 62304, focused on software:

• Instructions for use,
• Labelling,
• IT systems (detailed in section 7.2.3.2 of IEC 82304-1).

It doesn't come immediately to the mind of the reader of IEC 62304 to think about these types of risks. Software risk management is usually focused on software failure, not the aforementioned types of risks.

For those who know IEC 60601-1, we see here once again that IEC 82304-1 takes the same role as IEC 60601-1, but for standalone software.

ISO 14971 is mandatory

Strictly speaking, the mandatory nature of ISO 14971 is only given by the requirements in the section 4.2 of IEC 62304.
Section 4.2 of IEC 62304 is called by section 5 of IEC 82304-1. Thus ISO 14971 is mandatory for the software lifecycle processes. No surprise here, ISO 14971 is really the gold standard for patient risk management.
It looks more consistent to apply the risk management process of ISO 14971, throughout the full lifecycle of health software. But IEC 82304-1 leaves the door open for other risk management process at system level.

Exemption for 3rd party software

IEC 82304-1 leaves the door open also at software level. The section 5 of IEC 82304-1 authorizes the health software manufacturer to apply partially the ISO 14971 risk management process when health software contains third party software.
This looks pretty much like the SOUP concept of IEC 62304, since IEC 82304-1 requires to analyze residual risks for this third party software and implement mitigation actions if risks are unacceptable.

References to IEC 62366-1

IEC 82304-1 requires in section 4.2 to define the HEALTH SOFTWARE PRODUCT use requirements. But it doesn't require to apply IEC 62366-1 (nor the previous version IEC 62366:2008). IEC 62366-1 is only quoted in a note at the bottom of the section, as a potential source of information.
But, for health software qualified as medical device, IEC 62366-1 is already recognized by the regulation authorities (only by the FDA, at the time of writing). Thus even if IEC 62366-1 is not referenced, manufacturers of standalone software medical device will apply IEC 62366-1.

Anyway, for health software NOT qualified as medical device IEC 62366-1 is absolutely not required.

System-level requirements

The references of IEC 82304-1 to other standards makes a framework, which allows to reuse the state-of-the-art in the software development, maintenance and risk management processes. But the novelty of the standard resides in the specific sections dealing with the system level.
The clauses of IEC 82304-1 aim to define a framework for the design of the standalone software system:

• Use requirements: the top-most requirements,
• System requirements: technical requirements consistent with use requirements,
• Validation: how to validate the use requirements.

They also aim to define a framework for user documentation and labeling, with clauses about:

• Identification,
• Accompanying documents,
• Content of accompanying documents, especially for the system administrator.

And they finally aim to define a framework for post-market activities:

• Software maintenance,
• Revalidation,
• Communication with interested parties,
• Decommissioning and disposal.

Health Software Validation

The best improvement of IEC 82304-1 is its intent to fill the big gap between the software verification of IEC 62304 and the software validation requirements of regulations, when health software is regulated as a medical device.
Validation is performed versus a set of top-level requirements. That's why IEC 82340-1 contains clauses about use requirements, system requirements, and accompanying documents.

Validation is not a step, this is a journey. Health software product shall be maintained validated during its whole life on the field. That's why IEC 82304-1 contains clauses about post-market activities.

Conclusion

IEC 82304-1 fills the gap between IEC 62304 and software medical device validation required by regulations. To do so, it contains a minimum set of clauses defining what is needed at system level, and it references existing state-of-the-art standards (ISO 14971 and IEC 62304) for the software level.
This approach makes IEC 82304-1 relatively short, compared to IEC 62304, ISO 14971, and IEC 62366-1. But its content is essential, to ensure health software products are correctly maintained in a validated state.


Next Article is on the application of IEC 82304-1 with agile methods.