Jump to ContentJump to Main Navigation
Show Summary Details
More options …

Current Directions in Biomedical Engineering

Joint Journal of the German Society for Biomedical Engineering in VDE and the Austrian and Swiss Societies for Biomedical Engineering

Editor-in-Chief: Dössel, Olaf

Editorial Board: Augat, Peter / Buzug, Thorsten M. / Haueisen, Jens / Jockenhoevel, Stefan / Knaup-Gregori, Petra / Kraft, Marc / Lenarz, Thomas / Leonhardt, Steffen / Malberg, Hagen / Penzel, Thomas / Plank, Gernot / Radermacher, Klaus M. / Schkommodau, Erik / Stieglitz, Thomas / Urban, Gerald A.

CiteScore 2018: 0.47

Source Normalized Impact per Paper (SNIP) 2018: 0.377

Open Access
See all formats and pricing
More options …

Risk management for medical devices in research projects

Christian Sauter / Marion Heinloth / Andreas Tobola / Nadine Pensky / Christian Weigand
Published Online: 2015-09-12 | DOI: https://doi.org/10.1515/cdbme-2015-0129


In applied research for medical devices exists a conflict between effective research and regulations. While researchers need sufficient freedom the regulations require a complex technical documentation for a medical device. One relevant aspect of the regulations is risk management which takes time and therefore is ignored in many research projects. With adoptions to the standard the effort can be reduced: Identifying of risks can be focused on critical risks, measures can be categorised and only some categories need to be implemented. Research teams using this method can provide results which can be transferred into commercial products easier, cheaper and faster.

Keywords: Risk management; 14971; research; time to market; regulatory affairs; efficiency

1 Introduction

Today many research projects can be categorised as “applied research” which is also known as Research and Development (R&D) (BPB; Forschung und Entwicklung (FuE): Finanzierung und Ausgaben; 2012; www.bpb.de). The goal of those projects is to transfer recent research findings in products.

When developing medical devices for the EU-market, one of three European directives is applicable (94/42/EWG (Medical Device Directive - MDD), 98/79/EG (In Vitro Diagnostica Directive - IVDD) and 90/385/EWG (Active Implantable Medical Devices Directive)). The MDD is the most common one. As all of them have the same structure the thoughts of this paper are relevant for all of them. The most important aspect of those European directives is that essential requirements have to be fulfilled before placing devices on market. The first essential requirement contains: “The devices must be designed and manufactured in such a way that [...] they will not compromise the clinical condition or the safety of patients [...]” (MDD - Annex I), which is usually fulfilled by a risk management following ISO 14971.

To proof that all essential requirements were fulfilled a technical documentation is needed. Such a technical documentation requires great effort (the amount of overhead is not be quantified in literature, but mentioned, e.g. [4]).

The literature agrees that is important to integrate, practise and learn safety in projects throughout the complete life-cycle. [13, 5] Nevertheless in many projects this aspect is ignored [2]. Even if safety considerations are made they are usually not documented in a risk management file. Researches need flexibility, creativity and sufficient time to generate results and this is why research teams usually try to minimise documentation effort. Due to this development needs to start over from scratch to transfer the results into a product. This conflict between safety considerations and efficiency needs to be resolved by scaling risk management to an helpful and effective level.

2 Decision about the necessity and extent of risk management

As mentioned above, risk management should be performed in all projects researching and developing medical devices. Since medical devices are not the only products that are regulated, but all products need to be safe (see also 2001/95/EG (General Product Safety Directive)), a basic risk management is recommended for most kinds of projects.

If a decision in favour of risk management is made, the extend of risk management is scalable. Influencing factors are:

Product related work: If the final development of a product is planed directly after the actual research project the risk management activities should be elevated in comparison to a very basic proof of concept with many more steps of research.

General risk of the project: If the intended use of the project is obviously harmless (a completely harmless product is usually not possible, but some software has only very indirect and low influence on the health of humans), less risk management is necessary than in a high risk project (e.g. devices that are life-sustaining or devices with high voltages, radiation or mechanical functions).

3 Risk management method

The already mentioned standard ISO 14971 (the actual version is EN ISO 14971:2012 ”‘Application of risk management to medical devices”’) requires several steps; the following chapters show profound ideas how some important steps can be included into research projects efficiently. Nevertheless, this is not a complete listing of all necessary steps. Furthermore it is important to mention, that there are two kinds of risk management. The standard focuses on humans and their safety (“this International Standard deals with processes for managing risks, primarily to the patient, but also to the operator, other persons, other equipment and the environment.” Introduction of EN ISO 14971:2012). The other category, the risks for the project itself (e.g. financial risks due to higher amount of time, loosing know-how due to a leaving employee), is not covered by the mentioned standard. The techniques are basically the same.

3.1 Risk policy

The standard ISO 14971 requires a risk policy which usually does not exist explicitly in research projects. The risk policy can be depicted in a matrix showing how often an “accident” of a certain severity is accepted. (See example in table 1) (it is strongly suggested to replace qualitative descriptions like “sometimes” by quantitative values fitting to the project like “between 2 % and 10 %”). It is suggested to define a risk policy already for research projects. It helps to have specific numbers for discussions and decisions concerning risks. In order to minimise unnecessary overhead and due to the fact that many probabilities are not easily definable in early stages, the number of columns should be reduced to general classes. For example, the NACA-Score [6] consists of seven severities, usually the four severity-categories shown in table 1 are sufficient for research projects. Normally the risk policy is defined by the management. However, for research projects this can be carried out by the project team or the project manager. It is time saving if an experienced person makes a suggestion, since depending on the intended use, each project needs to define its own risk policy (example: The risk policy for a device for measuring blood pressure differs from the risk policy for surgery equipment).

Table 1

Risk policy - a red field indicates that the combination of probability and severity is critical while a yellow field represents a combination that can be tolerated, but ISO 14971 requires to reduced them as far as possible.

3.2 Initial risk management workshop

As research teams want to know all influences of the risk management on their project as early as possible they should identify those influences as soon as possible. An initial risk management meeting before the architecture is defined ensures that obvious risks and their countermeasures are known early enough. This initial risk management team should consist (like required by the standard) of experts of all affected parties. This includes technical experts as well as medical specialists and professionals for risk management. They should analyse each part of the project systematically and start identifying risks. In research projects it is sufficient to identify risks in different levels of detail. It is possible to focus on those risks that are somehow “critical”, meaning they are in the “red area” of the risk policy or they might have an influence on the architecture or other project decision. In this case the details of the risk should be explored in more details. If any area is identified as “not critical” it is sufficient to mention this without listing many details. This is sketched in Fig. 1.

This figure shows Depending on the risk categorisation, it is necessary to put more or less focus on it. This figure shows an example for focusing on critical aspects: Aspects with very low risk (green) need less effort than aspects with medium risk (yellow) or high risk(red).
Figure 1

This figure shows Depending on the risk categorisation, it is necessary to put more or less focus on it. This figure shows an example for focusing on critical aspects: Aspects with very low risk (green) need less effort than aspects with medium risk (yellow) or high risk(red).

3.3 Documenting risk management

In the later development phase everything needs to be documented according to the defined procedures (ISO 13485 describes a quality management system (QMS) for medical devices, but in some cases manufacturer do not need a complete QMS. In this case they need to define procedures for development.). However, it is important to recall that details in research projects usually are subject to many changes. This is why the documentation should be easy to change and not too extensive. Therefore the results should be digitalised, to ease changes. Possible tools will be presented later on.

3.4 Updating risk management

The standard requires a continuous risk management. This means on the one hand that any identified risk, independent from the context, should be added immediately to the risk management and on the other hand that the complete risk management should be reviewed regularly. In research projects this is even more important than in regular projects, since numerous changes in the project can result in new or changed risks. In this case two possibilities exist: a) risk is not critical, then it is just documented, without bureaucracy, but very efficient; b) risk is critical, then relevant persons need to be informed and measures (actions to reduce risks are called “risk control measures” (ISO 14971 chapters 2.19, 6.1.3) . In the following the expression “measure” is used) have to be defined together.

3.5 Measures

One of the main focuses of risk management is to control risks by implementing measures. In many cases the implementation of measures is not necessary during research phase. Therefore, the measures are the main aspect, in which the risk management can be much more efficient than in development projects.

3.5.1 Influencing aspects for implementation of risk management measures

Basically there are four aspects that should help to decide when the measure needs to be realized:

Risks for humans during research phase: If the risk during the research phase for persons is too elevated, the corresponding measures have to be implemented. But if the demonstrator is only handled by a small group of persons who know how to avoid the risk the implementation can be postponed.

Example: The device does not need an enhanced usability during research since all persons using the demonstrator know its functionality.

Influence on the architecture: If the measure has an influence on the architecture, the measure should be considered during the definition of architecture, even if it is not necessary to implement it during research phase.

Example: If the measure is “sending an alarm”, it is necessary to provide an architecture for software and hardware that provides all necessary interfaces, even if no alarm is implemented during research.

Obviousness how the measure can be realized: If it is obvious how a measure is realized, it does not need to be implemented at once. If research is needed to verify the effectiveness of a planned measure, at least an implementation of a “proof of concept” can be helpful to decide if the measure is sufficient.

Necessity for the research project: Many measures do not only affect the risk management but are also a solution for another requirement. In this case the measure should be implemented.

3.5.2 Decision for implementation

After having checked all aspects of the previous chapter it should be decided for each measure if it will be considered in the planning and architecture as well as in which time or project phase the implementation is done (e.g. month/year or “in a following development phase”). Especially if the implementation is postponed to a phase beyond the project it helps to minimise the effort of risk management in research projects.

3.6 Risk management report

A risk management report is generally not necessary during research. That is why this document usually does not need to be written. Nevertheless there are cases, where a risk management report is helpful. Some are listed here:

  • A customer or someone else wants to use the results

  • The device is used in some kind of study – then the risk management report needs to address at least the risks that can affect the participants of the study.

4 Risk management tools

The most important aspect of risk management is to list all known risks together with their relevant data (relevant data of a risk includes description, causes, effects, assess-ment(probability and severity according to the risk policy), measures and reassessment).

Neither the standard or the law require a special form and there exist special tools, which are normally quite expensive. Some of them are specialised on risk management and others try to depict the complete “life cycle” of the product. Nevertheless, one of the most used tools are spreadsheets that are available in each office software. Those do not provide special help, but are easy to edit, mostly available and most scientists are familiar with them. Furthermore, at least a basic evaluation can be realized easily.

5 Discussion

Even though the importance of risk management is widely accepted, there are many research projects ignoring it. One reason might be the funding policy of research calls. In those calls applied research is funded but not the developing of a product. And therefore in research proposals seldom resources for risk management and other quality related aspects are considered. So it is understandable that those aspects do not get sufficient consideration. Therefore a balance has to be found between effectiveness in the next stages, freedom of research and financing efforts used for risk management.

6 Summary

Since safety considerations are indispensable, at least a basic risk management is beneficial in research projects. During the several steps of risk management there are many possibilities to scale the effort compared to a full risk management while the main advantages of risk management can be used during research and the results are usable for a later transition to a product.

It is important to identify risks as early as possible and decide which risks are relevant and need measures during research. Especially important is to consider risks affecting the definition of the architecture to reduce expensive changes in later phases. The results should be documented in a form that is already adequate for the technical documentation although the extent can be reduced in earlier stages and detail content can be supplemented in later stages.

Including a scaled risk management in early stages reduces time to market as well as costs and improves the chance of commercialization.


Fraunhofer IIS is specialised on applied research. During the last years in the ”Department of Image Processing and Medical Engineering BMT” a method was developed how research and quality management can be combined effectively. This method was tested and improved in several research projects. Some of the results focusing on risk management are presented.


  • [1]

    BVMed (GER). Risikomanagement für Medizinprodukte. Berlin 2009. Google Scholar

  • [2]

    Dössel, O. Patientensicherheit in der medizintechnischen Forschung. Bundesgesundheitsblatt-Gesundheitsforschung-Gesundheitsschutz, 2009, 52. Jg., Nr. 6, S. 579-583. Google Scholar

  • [3]

    Gärtner, A. Medizinproduktesicherheit-Band 1: Medizinproduktegesetzgebung und Regelwerk. Köln: TÜV Media, 2008. Google Scholar

  • [4]

    Imhoff, Michael. Risk management for medical networks in intensive care and emergency medicine–a joint position paper on IEC 80001-1, 2013 

  • [5]

    Regan, G., et al. Medical device standards’ requirements for traceability during the software development lifecycle and implementation of a traceability assessment model. Computer Standards & Interfaces, 2013, 36. Jg., Nr. 1, S. 3-9. Google Scholar

  • [6]

    Schlechtriemen, T., et al. Der Münchner NACA-Score. Notfall & Rettungsmedizin, 2005, 8. Jg., Nr. 2, S. 109-111. Google Scholar

About the article

Published Online: 2015-09-12

Published in Print: 2015-09-01

Author's Statement

Conflict of interest: Authors state no conflict of interest. Material and Methods: Informed consent: Informed consent is not applicable. Ethical approval: The conducted research is not related to either human or animals use.

Citation Information: Current Directions in Biomedical Engineering, Volume 1, Issue 1, Pages 543–546, ISSN (Online) 2364-5504, DOI: https://doi.org/10.1515/cdbme-2015-0129.

Export Citation

© 2015 by Walter de Gruyter GmbH, Berlin/Boston.Get Permission

Comments (0)

Please log in or register to comment.
Log in