DIN EN IEC 80001-1:2023

IEC 80001-1 has the long title “Application of risk management for IT-networks containing medical devices – Part 1: Tasks, responsibilities and activities“.

This article reveals what the standard requires and why manufacturers should also consider it.

1. About DIN EN IEC 80001-1

a) Objectives of DIN EN IEC 80001-1

The standard aims to help minimize the risks posed by faulty IT networks.

In addition to safety and security, it also refers to effectiveness. But the latter is not to be understood in the sense of clinical effectiveness, as with medical devices.

b) Scope of DIN EN IEC 80001-1

Definitions

The standard feels responsible for health IT systems within a health IT Infrastructure. The definitions of these terms can be found in ISO 81001-1, which is closely related to ISO/IEC 80001-1.

The standard includes health software, medical devices, IT hardware, data, and procedures among these systems.

As examples of this infrastructure, the standard again mentions data, health software, medical devices, and other IT (networks, computers, SaaS applications) as well as procedures. In contrast to the definition of a health IT system, it also adds: people with their capabilities and “non-tangibles” such as reputation.

Scope

IEC 80001-1 is applicable whenever organizations use IT infrastructures that also contain medical devices and or health software to achieve specific health-related objectives – i.e., to diagnose, monitor, or treat patients.

Thus, the standard is particularly applicable in hospitals, doctors’ offices, laboratories, and other operators.

c) Regulatory relevance

The standard is not harmonized. Although it represents the state of the art, it does not have a prominent role in proving legal requirements. In Germany, for example, these include the Medical Device Operator Ordinance, which requires:

Medical devices connected to each other as well as medical devices connected to accessories including software or medical devices connected to other objects may only be operated and used if they are suitable for use in this combination, taking into account their intended purpose and the safety of patients, users, employees, or third parties. (translated from German)

§ 4, Paragraph 4 MPBetreibV

2. IEC 80001-1 requirements

a) Structure of the standard

DIN EN IEC 80001-1 comprises six chapters (see Fig. 1).

b) Overview of the requirements

#	Chapter	Key requirements
1	Scope	Sets the scope (see above)
2	Normative references	There are no references …
3	Terms	… but the standard uses the definitions of IEC 81001-1.
4	Principles	On about one page, the standard formulates principles for risk management. These include that the organization is responsible for this process and refers to a socio-technical ecosystem. This chapter does not contain any verifiable requirements.
5	Framework	This chapter provides comparatively general requirements for risk management: risk management plan risk management files documentation of the socio-technical system (objectives, IT, medical devices, processes, responsibilities) “commitment” of the management: it must provide the resources. This includes the Health-IT Risk Manager in this version. involvement of all stakeholders (including external stakeholders such as suppliers)
6	Risk management process	This chapter is the most concrete. 6.1 formulates the requirements for the process described in Subchapter 6.2.

c) Requirements for the risk management process

The activities in the listed risk management process are reminiscent of ISO 14971, but IEC 80001-1 only partially formulates the requirements specifically for the health IT context.

Aspect	Chapter	Specific requirement
General	6.1.1	The process is to be applied over the entire life-cycle, which in this case begins with purchase and ends with decommissioning.
Hazard/risk analysis	6.1.2.1 until 6.1.2.3	Specific roles must participate in the risk analysis, such as top management, medical staff, administrators, and users. The “intended use” of the health IT system should be taken into account. This is often more difficult to describe than for a medical device. The standard recommends a workshop for risk analysis. The manufacturer’s documentation should be involved.
Risk evaluation	6.1.2.4, 6.1.4	These requirements are largely similar to ISO 14971. A risk acceptance matrix must be used in the assessment and the most likely case must be assumed.
Risk control	6.1.4.1, 6.1.4.2	The requirements in this section are largely non-specific to health IT.
Verification of the activities	6.1.4.3, 6.1.4.4	Before any change is made to a health IT system, the measures must be evaluated, and a report must document the residual risks and the activities carried out.

c) Requirements for the life-cycle activities

Quasi “orthogonal” to the risk management process, the organizations should carry out the life-cycle activities. In doing so, they must subject these activities in whole or in part to the risk management process.

3. Critical evaluation of the standard

The standard does not have the precision and conceptual clarity of ISO 14971.

a) Lack of usability

IEC 80001-1 is pleasantly short; nevertheless, it is difficult to keep track of the requirements. One reason for this is that the standard contains cascading requirements.

For example, if you want to comply with Chapter 6.2.6, you must also observe the requirements of Chapter 6.2.5. This, in turn, refers to the requirements of Chapter 6.2.4, which in turn includes the requirements of Chapter 6.1.1.

b) Limited conceptual integrity

The standard is neither sufficiently coordinated with other standards nor coherent in itself. This also applies to the terminology. Although it defines the term harm in the same way as ISO 14971, it refers to the risks as “severity of consequences of harm.”

The idea of combining risk management activities with the life cycle seems logical at first glance. But IEC 80001-1 does not follow through with the concept consistently:

• It does away with necessary activities.
• Instead, it introduces completely new concepts, such as the incident management process in the chapter on operation and maintenance.
• In order to formulate the requirements for this process, the authors have interrupted a sequentially numbered list, which further complicates readability and assignment.
• It is not understandable why this process should no longer be relevant during decommissioning.

c) Unspecified requirements

Standards should not only formulate the objectives but also set verifiable requirements for the activities and the outputs to be achieved. A requirement such as that a process “must ensure a communication mechanism” does not fulfill this desire.

4. Importance of IEC 80001-1 for manufacturers

a) Manufacturers who are also operators

More and more manufacturers are also becoming operators because they operate health IT systems for health institutions or patients. They are thus subject to the MPBetreibV.

b) Manufacturers responsible for a health IT system

In DIN EN IEC 80001-1:2012, a manufacturer did not(!) fall within the scope if it assumed responsibility as an individual for the IT network containing medical devices. This restriction no longer exists in the new edition.

c) Manufacturer as consultant

The standard is not characterized by comprehensibility and ease of implementation. The need for advice and the interest in solutions that help meet the normative and legal requirements are correspondingly high. Both create new business opportunities for manufacturers.

5. Summary and conclusion

Anyone who had hoped that DIN EN IEC 80001-1:2023 would provide an easy-to-understand recipe for risk management in health IT systems will be disappointed. Too many of the requirements of the standard are too banal, too abstract, or too complicated. The specifications of older editions were much more helpful. The specifications of AAMI TIR 57 are likewise.

Operators are thus faced with the task of having to define their processes and procedures without a concrete action guide – from purchasing to operating to decommissioning elements of health IT.

The ITIL processes are helpful here but must be supplemented by the special features of the healthcare sector, in particular, risk management.