Organizing Risk Analysis and Controls for a New Medical Device (ISO 14971)



Hello everyone, advance apologies for an incoming wall of text.

I'm currently trying to plan and execute risk management for a new device according to ISO 14971 and I'm running up against a wall.

My first problem seems to be in documenting the sequences of events resulting in a hazardous situation. No matter how I seem to approach this, I find the posssible sequences multiplying and branching out uncontrollably.

For example;

For my device (a novel vascular access system) a hazard is 'Loss of functionality (gas/fluid sealing)' with an associated hazardous situation of 'Leakage of device connections'.

In considering the foreseeable sequence of events leading to the hazardous situation the basic iniating events come easily enough (eg, "Connector design/materials are inappropriate for expected loadings" or "User applies pressure loadings outside the safe range"), but once I start to consider more detailed initiators (eg, "production deviations result in degraded connection sealing" or "Degradation due to environmental exposures during transport/storage or use") the possible event sequences multiply uncontrollably due to consideration of issues such as multiple degradation sources (temperature, humidity, x-ray, UV, procedural materials etc) in multiple environments (transport/storage, cath lab, hospital environment, outpatient environment etc).

This becomes further compounded by consideration of deviations in the production and how these interact with the identified events and I end up with multiple additional events to consider "Production deviations result in compromised performance of connections" and "Production deviations result in substitution of materials incompatible with expected environmental. exposures"​

At this point I'm already confused, but this is further exacerbated by the fact that each control I consider seems to beg additional controls, for example; if I introduce a control "Device packaging will include an opaque outer layer to prevent degradation due to UV exposure" or "Device materials will be selected for compatibility with expected X-ray exposure over in-situ life", I find myself compelled to consider the possibility of production deviations resulting in omission of these controls, introducing new events ad infinitum (ad nauseam?).

I think there must be some principle for organising risk analyses (particularly sequences of events), or dividing it into manageable chunks that I must be missing. Otherwise, something about my approach is deeply, fundamentally flawed.

Does anyone have any insights into this particular madness that might steer me in the right direction?


Gert Sorensen

A few thoughts:

It is not unreasonable to see multiple hazardous situations and harms related to one hazard, they sort of branch out in a tree-like manner. So, one hazard can have e.g. 5 hazardous situations, and 15 harms. But use the hazard to bundle them into manageable chunks.

Remember to keep in mind that Risk Analysis should handle reasonably foreseeable risks, i.e. you should not get yourself into this mindset where everybody dies at the end of every hazard. Likewise some of the mitigating scenarios may be irrelevant as the defined lifetime of the device renders the hazardous situation obsolete. You may think about it like this: Is degradation of material a real risk if the lifetime as defined is one year or less?


Super Moderator
One thought for organizing may be to take a Fault Tree Analysis approach. That may help with the bundling Gert mentioned.


I have tried documenting the sequences of events for each hazardous situation in the form of trees, but I still find the sequences for a particular hazardous situation multiplying ridiculously out of control once I begin to bring in material degradation (and all of its root causes such as material selection or exposure to conditions outside operating ranges) and production deviations as contributing events for each of the individual device assemblies (overall device consists of multiple 'sub-devices' used together).

Also I still can't get past the problem that many controls I try to introduce seem to require an additional control. For instance, one of the identified hazards I have is thrombosis inside the lumen of the device, the main control for that is an occlusive member meant to exclude blood from the main device assembly when not in use. Do I then have to consider all the possible circumstances that could lead to non-functioning of the occluder (such as inappropriate dimensioning, deviation in production, failure to correctly insert the occluder etc). It seems very clumsy to be applying additional controls directly to a selected risk control.

To clarify for Gert: My issue isn't multiple hazardous situations and harms coming from a single hazard, its consistently dealing with the multiplicity of sequences of contributing events for a single hazardous situation.


Peter Selvey

Super Moderator
This highlights one of the failures of ISO 14971 to provide any kind of screen or filter to decide what goes in the risk management file. In reality there are literally 10,000s of viable scenarios which could reasonably be considered in a risk control context (i.e. scenarios which have significant risk and there is some form of a risk control).

I saw an ISO 14971 youtube video on once that used an example of putting the wrong size fuse in an electrical device during production. Yes, it is a valid sequence, but the inclusion should make any reasonable engineer shudder, as there are literally 1000s of similar scenarios in final production alone, let alone suppliers, shipment, installation, interface between the medical device and the user, environment, other medical devices and the patient operator, servicing, removal ...

In practice the example makes no sense as including it in the risk management file provides no tangible benefit. Any manufacturer that is so poorly organised such that wrong fuse is a realistic concern should not be in the business of making medical devices. Production controls will exist, adding the line in the file makes no difference and actually increases risk by diverting resources and cluttering up the file with useless data.

Each organisation should have a filter in place which decides what information should go in the file. Considerations for excluding scenarios might include:
- is the situation covered by a risk control that is well established, understood and broadly accepted, such that a reasonably qualified person would be expected to implement irrespective of the risk management file;
- are the specifications such that the risk acceptability is obvious by inspection (clearly safe)
- is the issue already well covered by published standards
- is there a "gate" type of risk control that catches a large number of scenarios (meaning individual scenarios don't need to be documented)

Considerations that might trigger scenarios being put in the file:
- borderline situations where the manufacturer chooses to take no action (cost, limit of technology, competition influence the decision)
- situations where the risk control type is clear, but the suitability of the specifications is not obvious by inspection (e.g. reason why ±15°C limits were set for a temperature alarm in a production process which might appear high to a reasonably qualified person)
- risk controls that could be plausible forgotten even if simple
- for gate type of risk controls, a line item that lumps a large number of scenarios together

Other reasons/rational for the could be developed based on experience, it is likely to be different for different types of products.

It is important not to overload the file, as more line items usually means less detail and lower quality information, yielding poor decisions. It is better to have a file that documents the top 10-20 risks well, than a file with 1000 items documented poorly.

Under the current standard, in the absence of any clause that talks about the filter function, this could be handled through a careful wording of the policy.
Last edited:
Top Bottom