IEC 82304 – What the standard requires of “health software”

IEC 82304 is now available. This is a good reason to take a closer look at this standard for “health software products.”

IEC 82304: Why another standard?

Closing the IEC 62304 validation gap

IEC 62304 was launched with the claim of being applicable to all medical device software – whether standalone or embedded. However, the authors seemed to have had embedded software more in mind when writing the standard, as can be clearly seen in some chapters (e.g., 5.5.4). Unfortunately, this resulted in the standard making no statement about validation because embedded software cannot be validated; only the entire medical device can.

Formulate requirements also for non-medical device software

IEC 82304 has now begun not only to close this gap but also to regulate the growing market of software products that have something to do with medicine, health, or wellness but are not (yet) a medical device.

Scope of application of IEC 82304

Who the standard is addressed to

Even though IEC 82304 is part of the “number range” of 80000 standards, which also includes IEC 80001-1, it is addressed only to manufacturers, not to operators.

For which software this standard is to be applied

IEC 82304 feels responsible for “health software products.” This is what the standard means:

IEC 82304 defines the term health software as follows:

Only for standalone software

I.e., the standard is intended to apply to standalone software, not to “embedded software,” i.e., not to software that is part of a medical device, especially not if it is an IVD or medical device that falls within the “scope” of IEC 60601-1.

Not only for medical devices

The standard is not limited to medical devices. Since software for the fitness sector serves to improve health, it also falls within the scope.

Obligation

IEC 82304 is planned to be harmonized in 2024. However, notified bodies already now ask for it. This is for the following reasons:

1. Notified bodies or auditors are increasingly disputing that the standards (e.g., in the harmonized versions) represent the state of the art. In the view of many, IEC 82304 does (already now).
2. There is currently no standard that adequately addresses software validation. (Note: Unlike the FDA describes it, software validation does not mean software quality assurance as a whole). Whether IEC 82304 adequately describes the state of the art in validation is discussed below.

What IEC 82304 requires from you

The IEC 62304 applies too, the ISO 14971 not exactly

IEC 82304 makes it easy for itself and references IEC 62304 Chapters 5 to 9.

The part of IEC 62304 that IEC 82304 does not reference as mandatory is very manageable since Chapters five to nine (i.e., all processes) must be observed. Only in the case of ISO 14971, referenced by IEC 62304, IEC 82304 allows manufacturers to make certain concessions.

Overview of the requirements

The chapter structure already suggests the most important requirements, which we present in the following chapter.

Requirements in detail

Chapter 4: Product requirements

Manufacturers must formulate clear requirements for the device and, in doing so, be aware of the risks posed by the device – and control these risks by taking appropriate measures. This also includes the manufacturer specifying which users in which (usage) environment on which hardware are to use the device for which objective.

The requirements to be specified by the manufacturer must not only relate to the device and its interfaces to other systems (interoperability). They must also consider the documentation, accompanying documents, installation, updates, support, etc.

Chapter 5: Life-cycle

The requirements of this chapter can be summarized in one sentence: “Do it as written by IEC 62304 in Chapters five to nine”.

Chapter 6: Validation

The sixth Chapter states that one must plan, perform, and document validation. It lists some examples of methods such as “inspection, analysis.” However, the validation is to check whether the “Use Requirements” (user requirements) are fulfilled, which is mentioned in Chapter 4.2. However, only limited user requirements can be found, but other stakeholder requirements and system requirements are named.

The requirements for competence and independence of the validation team from the development team are noteworthy.

Chapter 7: Accompanying documents

Chapter 7.2 is surprisingly detailed: The standard describes in great detail which documents the manufacturers must provide with which information:

• Instructions for use: intended purpose, network environment, safety instructions, installation, etc.
• Technical description: hardware, platform, installation, configuration, maintenance, network requirements and associated risks, etc.

Chapter 8: Post-production phase

The responsibility of the manufacturers does not end with the marketing of the devices. Now you have to react to errors (e.g., bug-fixing), revalidate changed parts of the software, update the accompanying materials, and communicate all of this. For medical device manufacturers this part is less relevant as the requirements of the MDR are even more detailed.

IEC 82304: A critique

The following considerations are, of course, subjective but nevertheless helpful in classifying the standard.

Positive aspects

1. A short standard
   IEC 82304 is a compact standard with 28 pages (almost half of which are non-normative). This is positive.
2. State of the art described
   It is also positive that the state of the art for non-medical device software has been described, even though other, non-medical device-specific standards also already do this. However, the risk management aspect is missing there.
3. Accompanying materials
   In Chapter 7, the standard describes the requirements for accompanying materials very specifically and in (almost too) great detail. This can almost be used as a checklist.
4. Post-production phase
   The requirements to evaluate, validate, document, and communicate changes to the software sound trivial, but very often, they are not fulfilled. Now, there is clarity.

Surprising aspects

1. Too many requirements
   A reference to an IEC 62304 is quickly written. But what does this mean for the manufacturers? With this reference, the authors have included overwhelming requirements regarding scope and complexity. Even medical device manufacturers are more than challenged by this. We know this from our daily consulting practice. Confronting manufacturers of fitness apps with this amount of information may be frightening.
2. Lack of usability
   It’s not just about the amount of requirements but also about the fact that companies have to enter a world of medical device regulations that they are not ready for. That isn’t good for the companies, but good for the consulting firms.
   Note: We also provide free help in our micro-consulting.
3. Little guidance for action in validation
   If you hoped to finally get guidance on validating software (in the sense of the definition of IEC 82304), you would be disappointed. Not even the appendix mentions methods. Manufacturers must look elsewhere for the differentiation between validation, usability validation and clinical validation. Examples of software validation (or its methods) would have been expected to be included in the appendix.
   Note: You can find an article on the validation of medical devices here.
4. Stringency (in some places)
   IEC 82304 repeats the definition of validation (confirmation, through the provision of objective evidence, that the requirements for a specific intended use or application have been fulfilled). Chapter 6 on validation then deals primarily with the inspection against the “use requirements”. These user requirements are sometimes equated with the intended purpose.
   However, user requirements are a special form of stakeholder requirements, including functional requirements, i.e., requirements for the work product. If you would only focus on the “use requirements”, the software validation would be limited to usability validation. However, this is not the intention of the authors.
   Conclusion: It is not wrong what IEC 82304 writes. However, a standard that can become a problem for many people and companies requires absolute stringency and precision.

Conclusion

IEC 82304 covers a relevant regulatory gap. None of us wants to be exposed to faulty software if it involves health risks – regardless of whether the manufacturer has classified this software as a medical device.

At key points, the standard overshoots the target to some extent. It will likely become a difficult document for many manufacturers, especially due to the normatively referenced IEC 62304.