Risk Management: The Big Picture, Key Concepts and the Standards Landscape

Risk management shows up in design and development, in production, in complaint handling, in incident reporting and in every change made after the device is already on the market. The structure of the process shows how all of these connect, so it is worth knowing it before going into the details. This series of articles goes through the standard and the guidance that accompanies it, clause by clause.

This first article explains what the standard covers, how the process is built, what changed in the third edition, which concepts must be clear before you start, and how all the other standards connect to it.

What the standard covers and what it leaves open

The standard specifies terminology, principles and a process for risk management of medical devices. It also applies to software as a medical device and to in vitro diagnostic medical devices, and its requirements apply to every stage of the life cycle, from the initial concept to final decommissioning and disposal.

The process applies to many kinds of risk, among them biocompatibility, data and systems security, electricity, moving parts, radiation and usability. There is no separate process for security. The standard defines harm to include damage to property and the environment as well, so damage to data or software falls within the same framework when it leads to harm.

Two things are outside the scope:

• decisions on the use of a medical device in the context of a particular clinical procedure

• and business risk management.

Some of these decisions can only be made by a healthcare professional who knows the patient's condition and the patient's wishes.

The standard also does not specify acceptable risk levels. It requires the manufacturer to define objective criteria for risk acceptability, and that definition stays with the manufacturer.

The rationale, given in Annex A: the range of devices is too wide for a single level, and laws, customs and perceptions of risk differ between regions. That is why this definition is one of the central documents in an organization's risk management, and the next article is devoted to it.

The standard does not require the organization to have a quality management system. Almost every manufacturer runs one, and the standard is built so that it can be integrated into it.

Clause 7 of ISO 13485:2016 describes the product realization processes, and the risk management process should be integrated into them.

The process at a glance

Clause 4 is the system that wraps around everything else: a process applied throughout the life cycle (4.1), top management's responsibility for providing resources and for the policy for establishing criteria for risk acceptability (4.2), the competence of personnel (4.3), a risk management plan for each device (4.4), and a risk management file that provides traceability from each hazard to the evaluation of residual risk (4.5).

The following clauses run on top of it:

• Risk analysis, clause 5: intended use and reasonably foreseeable misuse, characteristics related to safety, identification of hazards and hazardous situations, and risk estimation.

• Risk evaluation, clause 6: comparison with the criteria defined in the plan.

• Risk control, clause 7: choosing the measures, implementing and verifying them, evaluating residual risk, benefit-risk analysis, risks arising from the risk control measures, and completeness.

• Evaluation of overall residual risk, clause 8.

• The risk management review and the risk management report before release to the market, clause 9.

• Production and post-production activities, clause 10.

Information from the market goes back into the analysis, and the results of the review feed back into top management's review of the suitability of the process itself (4.2).

Clauses 5 to 7 are carried out for each hazardous situation separately, and the overall picture is built only in clause 8.

What changed in the third edition

The third edition was published in December 2019 with these main changes:

• Three new terms were defined: benefit, reasonably foreseeable misuse and state of the art.

• More emphasis on the expected benefits of the device. The term benefit-risk analysis was aligned with the terminology used in regulations.

• The method for evaluating the overall residual risk and the criteria for its acceptability must be defined in the risk management plan. These criteria can differ from the criteria for individual risks.

• The requirement to disclose residual risks was merged and moved to one place, after the overall residual risk has been judged acceptable.

• The review before release of the device checks the execution of the plan, and its results are recorded in the risk management report.

• The requirements for production and post-production activities were clarified and restructured, including the sources of information and the actions required.

• The standard states explicitly that the process also applies to data and systems security risks.

Several informative annexes moved from the standard to the TR, which was revised in parallel.

This way the guidance can be updated more often without reopening the standard.

Basic concepts: hazard, hazardous situation, harm and risk

Five terms carry the whole process, and using them inconsistently is the source of most of the confusion in risk files.

Safety is defined as freedom from unacceptable risk (3.26).

Residual risk is the risk remaining after risk control measures have been implemented (3.17).

A hazard is only a potential.

It becomes a hazardous situation when a sequence of events or circumstances, including normal use, exposes people to it, and only then can a risk be estimated: the probability of harm and its severity. The standard allows the probability of occurrence of harm to be broken into two parts:

• the probability that the hazardous situation occurs, marked P1

• and the probability that it leads to harm, marked P2.

The breakdown is not mandatory.

When one of the two values cannot be estimated, the TR allows a conservative approach of setting the unknown value to 1 (clause 5.5.2).

The example in the image above is taken from Table C.3 of the standard.

The battery of an implantable defibrillator reaches the end of its useful life, and the interval between follow-up visits is too long. The device cannot deliver a shock when an arrhythmia occurs, and the possible outcome is death.

Notice two things. The end of battery life and the follow-up interval are events in the sequence, and they are not the hazard. And the description of the hazardous situation includes a person's exposure: the shock that was not delivered when it was needed.

Let's take another example:

Imaging software displays an image flipped left to right. Table C.1 lists, under performance-related hazards, diagnostic information, which includes image orientation. The example itself is ours, and only image orientation comes from the table. The hazard is incorrect diagnostic information. The sequence can be an error in image processing and the user not detecting the error. The hazardous situation is a clinician who receives incorrect information and acts on it. The harm is, for example, treatment on the wrong side.

A description like this makes it possible to determine later what the risk is and which risk control measures fit.

"A software bug" is a possible cause in the sequence of events, not the hazard.

Once this chain is clear, three working rules follow from the standard:

• Events and circumstances such as software security vulnerabilities or electrostatic discharge belong in the sequence of events (Tables C.2 and C.3), not in the hazard column.

• The level at which a hazardous situation is described is the manufacturer's decision. A cover left off a high voltage terminal and a person in contact with the terminal are two possible descriptions. What matters is that the description makes it possible to estimate probability and severity (Annex C.4).

• For systematic faults, the TR says to focus on building robust systems that prevent them rather than trying to estimate their probability (5.4.5). More on this in the article on faults and software.

The standards landscape

ISO 14971 is a process standard, and it connects to other standards at defined points.

The TR describes these connections in Annex E.

Some of the differences between the standards carry particular weight in daily work:

• ISO 13485:2016. The quality management system standard. ISO 14971 refers to it in the notes to clauses 4.1 and 10.1, among others to clause 7 (product realization), 7.3.3, 8.2.1, 8.4 and 8.5. Risk management is embedded in the realization processes of the quality management system.

• IEC 60601-1, clause 4.2. The standard for medical electrical equipment (ME equipment) requires a risk management process according to ISO 14971, but leaves out two parts of it: planning and carrying out production and post-production monitoring (clauses 4.1, 4.4 g and 10 of ISO 14971), and the periodic review of the suitability of the process (clause 4.2). IEC 60601-1 itself states that the process it requires is not as comprehensive as ISO 14971. A device that meets IEC 60601-1 still needs to complete the two missing parts in the quality management system to meet ISO 14971. In addition, "fault condition" in ISO 14971 includes the single fault conditions defined in IEC 60601-1.

• IEC 62366-1 and IEC 60601-1-6. The usability engineering process is part of risk management. IEC 62366-1, clause 4.1.2, repeats the ISO 14971 priority order for choosing risk control measures: inherently safe design, protective measures, and only then information for safety. When information for safety is used as a risk control measure, clause 4.1.3 requires checking that it is perceivable, understandable and supports correct use. Clause 5.3 requires identifying hazards and hazardous situations related to use, and clause 5.9 requires a summative evaluation as part of risk management. One point will get a whole article: abnormal use is outside the usability process, so its risks are addressed in risk management itself. IEC 60601-1-6 refers to IEC 62366-1 and also leaves out post-production monitoring of usability.

• IEC 62304. The software life cycle standard. Clause 4.2 requires a process according to ISO 14971. Clause 4.3 classifies the software system into classes A, B and C by whether it can contribute to a hazardous situation and whether the resulting risk is acceptable after risk control measures external to the software, then by the severity of the possible harm (the rationale in Annex B.4.3 assumes the probability of a software failure is 1). Clause 7 adds specific requirements: identifying software items that contribute to hazardous situations, risk control measures and their verification. The software risk management process is part of the process for the whole device.

• ISO 10993-1. Biological evaluation within a risk management process. According to Annex E of the TR, biological evaluation is handled like any other risk: analysis, evaluation, control and evaluation of overall risk. The TR refers to the 2018 version, so before quoting clause numbers it is worth confirming the current edition of the standard.

• ISO/TR 20416:2020. Guidance on the post-market surveillance process. It is consistent with ISO 13485 and ISO 14971, and its outputs serve as input to risk management, to design change processes and to improvement processes.

• ISO/TR 24971:2020. The guidance that accompanies the standard, with supporting annexes: questions for identifying characteristics related to safety (Annex A), risk analysis techniques (Annex B), the relation between the policy and the criteria (Annex C), information for safety and disclosure of residual risk (Annex D), standards (Annex E), security (Annex F), components and devices designed without using ISO 14971 (Annex G) and IVD devices (Annex H).

Risk management and reporting to the authorities

In Europe, the regulatory context links the risk file to the clock for incident reporting.

The guidance document MDCG 2023-3 Rev.2 states that a serious incident is reported immediately once a causal relationship is established, and no later than 15 days.

A death or an unanticipated serious deterioration in state of health is reported within 10 days at most, and a serious public health threat within two days.

The days are calendar days, and day one is the day after the manufacturer's awareness date.

The distinction between an anticipated and an unanticipated deterioration (Q12 in the document) relies on the risk file.

A deterioration is considered anticipated if it was considered in the manufacturer's risk analysis and documented in the risk management report.

To determine that it is anticipated, the manufacturer needs documented evidence that a risk management method was used to eliminate or reduce the risk as far as possible, or that the risk appears in the information the manufacturer provides to the user, for example in the instructions for use. Harm that was not included in the analysis is unanticipated, and its clock is 5 days shorter.

Two more points from MDCG 2023-3 will come back in the series.

• A use error caused by the ergonomic features of the device is an incident according to the document, and if it meets the criteria of a serious incident, it is reported. Other use errors are handled in the quality management system.

• Information on abnormal use must be documented and managed in the quality management system, and reasonably foreseeable misuse must be documented.

On European harmonization: the version EN ISO 14971:2019+A11:2021 adds Annexes ZA and ZB, which map the clauses of the standard to the general safety and performance requirements (GSPR) of the MDR and the IVDR. The differences between the wording of the standard and the MDR requirements, such as the requirement to reduce risk "as far as possible", will be covered in the articles on risk control and on benefit-risk analysis.

What to check in your company

This list fits companies at different stages, so it is split by situation:

• Startup before certification. Do you have a policy for risk acceptability signed by management, and a risk management plan for the device written before the analysis started? The acceptability criteria and the method for evaluating the overall residual risk are set in the plan, not after the analysis. It is worth planning now how information from the market will enter the process.

• Company with a product on the market. Is clause 10 actually connected to complaints, incident reporting, post-market surveillance and the literature? Clause 10.2 of ISO 14971 has a list of information sources, and it includes information from the supply chain as well as information on the state of the art.

• Company making a change. Clause 5.1 of the standard allows a limited scope of analysis, for example analyzing the impact of a change on an existing device. The scope and purpose of the analysis should be documented: who performed it, when, and what the scope was.

• Electrical device or device with software. Have you completed what IEC 60601-1 leaves out? Does the software classification under IEC 62304 match the severity in the risk analysis?

• The risk file. Is there traceability from each hazard to the analysis, the evaluation, the implementation and verification of the risk control measures, and the evaluation of residual risk (clause 4.5)? And do the serious harms that could occur appear in it, so they can be documented as anticipated if they happen?

In the next article: top management responsibilities, the policy for risk acceptability and the competence of the people involved in risk management.