Risk-Based Approach

A lot of authorities and regulations talk about a risk-based approach. However, they do not define the term or give any examples.

This article will give you an overview of what a “risk-based approach” is and provide you with concrete advice on how companies can meet these regulatory requirements.

1. Risk-based approach - what is it?

a) Which risks / harm are involved?

ISO 14971defines the term “risk” as "the combination of the probability of occurrence of harm and the severity of that harm". The standard defines harm primarily as physical injuries and damage to health. But it also includes harm to goods and the environment.

In contrast, in addition to physical harm for patients, users and third parties, the risk-based approach also includes the harm and consequences resulting from regulatory non-compliance such as:

  1. Certificate revocation
  2. Audit deviations
  3. Issuing of a new certificate being delayed or prevented

b) Adjustment of activities to risks

The risk-based approach is about companies adapting their quality management activities to the level of risk. This helps achieve the following objectives:

  1. Avoiding unnecessary activities and quality management bureaucracy
  2. Focusing resources on “critical” aspects
  3. Increasing safety and legal conformity 
Risk-Based Approach

Fig. 1: Risk-based approach: focusing on high risk aspects and adapting activities to them (click to enlarge)

Examples of the risk-based approach are:

  • Risk-based auditing
  • Risk-based testing
  • Risk-based maintenance

The risk-based approach can be defined as follows:

Definition: Risk-based approach

“A quality management approach that adapts activities to the size of a risk to minimize risks.”

Source: Johner Institute

 

2. Regulatory framework for a risk-based approach

a) ISO 13485:2016

What the standard requires

The most comprehensive requirements for the risk-based approach are set out in ISO 13485:2016. This approach must be reflected in the quality management system:

  • Control of internal processes (section 4)
  • Control of outsourced process and decisions on outsourcing (section 4)
  • Validation of computerized systems (CSV) (section 4)
  • Review of the effectiveness of training (section 6.2)
  • Product development (section 7.1 - 7.3)
  • Evaluation and selection of suppliers (section 7.4)
  • Control of suppliers including verification of the purchased products (section 7.4)
  • Validation of processes and computer software (sections 7.5 and 7.6)
  • Prevention of unwanted results by improving the QM system (section 8)

In some places, the standard uses the term “risk-based”, and in others it uses “appropriate”.

N.B!

In section 4.1, ISO 13485:2016 requires risk-based control of all processes and not just a “risk-based approach” to the processes named in the other sections.

What the standard does not require

ISO 13485:2016 does not impose any requirements on how and where the manufacturer must demonstrate how it is implementing the risk-based approach. In particular, there is no requirement to discuss it in any particular document. The corresponding requirements from notified bodies lack a legal basis.

The Johner Institute recommends describing the risks and the risk-based approach in, for example, the quality management manual. More on that later.

b) MDR

The MDR does indeed mention the concept of a risk-based approach. However, it does not establish specific requirements for manufacturers.

c) USA / FDA

Inspections

The FDA also bases the selection, intensity and frequency of company inspections on a “risk-based approach”. Companies are more likely to be inspected if:

  • Their products can cause serious harm
  • They have had problems with products or inspections in the past.

The risk-based approach enables the FDA to be as effective as possible with limited resources.

Risk-based efforts in the guidance documents

The FDA demands a “risk-based approach” in a lot of guidance documents. As with ISO 13485, this approach should be applied to QM processes such as the validation of processes and products:

  • Off-The-Shelf Software Use in Medical Devices: The approach to the selection and validation of OTS components should be “safety-based”. The FDA obviously wants the approach to be adapted to the possible severity of harm, not to the risk.
  • General Principles of Software Validation: The approach to the validation and re-validation of software should be dependent on the risk of the software (update).
  • Applying Human Factors and Usability Engineering to Medical Devices: The approach to validation (usability tests) should also be dependent on the risks.
  • Content of Premarket Submissions for Management of Cybersecurity in Medical Devices: “employ a risk-based approach to the design and development of medical devices with appropriate cybersecurity protections;”

d) Special case: ISO 9001

ISO 9001 has referred to the principle of a risk-based approach since the 2015 version. It states:

"Actions taken to address risks and opportunities shall be proportionate to the potential impact on the conformity of products and services."

Source: ISO 9001:2015 section 6.1

3. Implementing a risk-based approach

a) Step 1: Identify the risks associated with each process

List, for example in your QM manual, all relevant processes and identify the associated risks. You can do this in a table (see Table 1).

You should consider both regulatory risks and risks as defined by ISO 14971 (regarding physical integrity in particular).

b) Step 2: Defining measures

In an additional column, add the actions you will perform to control the risks. ISO 9001:2015 includes the following as possible types of action:

  • Avoidance of risks
  • Acceptance of risks
  • Reduction of risks by changing the severity or likelihood of harm
  • Elimination of risks (“inherent safety”), e.g. by fixing the cause

This table might look, for example, like this:

Process (area)

Process and work instructions

Risks

Actions

Document control

Document control process instruction, control of records process instruction

Regulatory risks: documents are not controlled
Risks according to ISO 14971: defective products due to incorrect test instructions

Both process instructions require the use of a DMS. Release process for new documents

Human resources

Training and further education process instruction, performance review work instruction

Regulatory risks: training does not take place, is not documented, absence of performance review
Risks according to ISO ISO 14971: defective products because employees develop or produce them incorrectly

Process instruction requires performance review and regular review of implementation

Product realization

Development process instruction, purchasing process instruction, goods receipt work instruction, production process instruction 

Development: defective products

Development process instruction: design reviews verifies compliance with the process

 

 

Purchasing: products that do not conform due to components that do not meet the specifications

Supplier process instruction requires qualification of suppliers, work instruction requires inspection of incoming goods

Table 1: Assignment of tasks to QM specifications

c) Step 3: Establishing risk classes

In the third step, manufacturers define risk classes, e.g.:

Risk class

Regulatory risks

Risks according to ISO 14971

A: Minor

Minor non-conformity

No noteworthy physical harm

B: Medium

Major non-conformity in audit

Product defect that could result in physical injury or disability

C: Major

Withdrawal or suspension of certificate, court case

Product defect that could lead to irreversible harm or death

Table 2: Definition of risk classes

Note: Strictly speaking, the two right-hand columns do not describe risks, but instead describe the severity of harm with unclear probability. The probability should be understood as 'reasonably foreseeable'.

d) Step 4: Adaptation of actions to the risk class

Now it is necessary to adjust the scope of the actions (right column in Table 1) to the risk (risk class). This is the risk-based approach.

Example 1: Design review

The time and effort spent on the design review can be adapted to the risk classes. For example, this time and effort can be adjusted through:

  • Frequency
  • Intensity: Duration, test aspects
  • People involved
  • Etc.

Risk class

Frequency

Intensity

People involved

A: Minor

When releasing the system specification and at the same time as the design transfer

Checklist A

Development and project manager, QM manager, production manager

B: Medium

As for A. Additionally when releasing the system architecture and before system tests

Checklists A + B

As for A

C: Major

At the end of every sprint (4-6 weeks)

Checklists A + B and C

As for A. Additionally “product owner”

Table 3: Example of a risk-based approach to design review

Example 2: Qualification of suppliers

The “risk-based approach” must also be used for the selection, evaluation and monitoring of suppliers according to ISO 13485:2016.

Risk class

Certified QMS

QAA

Supplier audit

Self-declaration

A: Minor

 

 

 

X

B: Medium

 

X

X

X

C: Major

X

X

X

X

Table 4: Example of a risk-based approach to supplier qualification

Example 3: Validation of computer software

For computer software validations, manufacturers can make use of several dimensions to adapt the time and effort to the risks:

  1. Functionality: The validation can concentrate on “critical” software functions. These functionalities can take the form of:

    • Use scenarios and use cases
    • Software requirements

  2. Test procedures: Various different test methods can be used depending on the risk

    • “Happy path” testing versus error-based testing
    • Systematic derivation of test cases using black box test methods such as equivalence class testing, limit testing, decision table testing, etc.

  3. Test coverage: There are several ways of quantifying test coverage:

    • Percentage of use scenarios tested
    • Statement coverage
    • Branch coverage
    • Percentage of UI elements tested
    • And many more

  4. Test aspects according to ISO 25010

    • Functionality
    • Portability
    • IT security
    • Usability
    • Performance (time behavior, resource consumption)
    • Interoperability
    • Robustness
    • Maintainability

  5. Test levels

    • Unit testing
    • Integration testing
    • Software system testing
    • Tests after installation and configuration in the target environment
    • Other validation, e.g. usability tests

Further information

Read more on the topics of software testing and computerized systems validation (CSV).

Example 4: Incoming goods

In the case of goods receipt, aspects that can be adapted for a “risk-based approach” include:

  • Percentage of parts inspected
  • AQL value
  • Percentage of tested properties of a part

Example 5: Software development

IEC 62304 already implements the risk-based approach in the form of safety classes. Depending on these classes, manufacturers must perform and document activities such as a detailed design.

Manufacturers are free to consider the risk of the respective software even more granularly in the development plan. Possible adjustments include:

  1. Everything mentioned in example 1 (design review)
  2. Everything mentioned in example 3 (CSV)
  3. Architecture modeling depth
  4. Decision on automation of tests e.g. for the GUI
  5. Process model
  6. Requirements for the competence of the team (explicit ISO 13485:2016 requirement)
  7. Decisions on the use of SOUP and the outsourcing of parts of development

Conclusion

The risk-based approach gives manufacturers the opportunity to adapt the time and effort they spend on quality management to the risks. This enables them to concentrate their efforts on the relevant aspects - i.e. high risks.

Manufacturers should make use of this option. At the same time, they should not equate the risk-based approach with risk management. The risk-based approach is a preventive action and, therefore, it is at best a subsection for risk management.

Manufacturers should not just take a risk-based approach to analytical quality assurance (e.g., audits, inspections, testing), they should also use it for constructive quality assurance (e.g., development, maintenance) and all post-market activities.

Author:

Prof. Dr. Christian Johner

Starter-Kit_rot_dunkel

A quick overview: Our

Starter-Kit

Learn More Pfeil_weiß
blog_rot_dunkel

Always up to date: Our

Institutejournal

Learn More Pfeil_grau