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

S

SRM049

#1
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?

Thanks,
 
Elsmar Forum Sponsor

Gert Sorensen

Forum Moderator
Moderator
#2
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?
:bigwave:
 

yodon

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

SRM049

#4
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.

Thanks,
 

Peter Selvey

Staff member
Moderator
#5
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:
Thread starter Similar threads Forum Replies Date
B AS9100 Rev D Quality Manual - How are you organizing? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 9
S Clarification in organizing required documents for ISO 27001 IEC 27001 - Information Security Management Systems (ISMS) 6
Proud Liberal Minitab - Organizing a large number of graphs using file details Using Minitab Software 5
S Organizing Uncertainty Budgets for different Measurement Equipment Measurement Uncertainty (MU) 4
M How to handle the task of Organizing a Regulatory File Room Document Control Systems, Procedures, Forms and Templates 2
K Global Quality Department Organizing and Planning Quality Manager and Management Related Issues 3
E Quality Assurance on Event Organizing (Medical Conferences, Yearly Festivals, etc.) Service Industry Specific Topics 0
V Suggestions on Organizing Documents using SharePoint 2010 Document Control Systems, Procedures, Forms and Templates 13
B Newbie, easy to follow guide for organizing/assembling very first PPAP booklet APQP and PPAP 3
B Organizing data to run simple regresson Using Minitab Software 4
T Organizing Medical Device Requirements - How you carried out yours? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
GStough Looking for Options in Organizing Internal Audit Paperwork - Any ideas? Internal Auditing 20
R Risk assessment on IT containers and the information they contain IEC 27001 - Information Security Management Systems (ISMS) 4
B Threat/Vulnerability Catalogue for risk assessment IEC 27001 - Information Security Management Systems (ISMS) 4
R Opportunity For Improvement vs Opportunity (Positive Risk) ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 18
R FOD Risk Assessment - What tools would you recommend for assessing FOD risk? AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
R Identify Medical Device characterstics as Annex C of ISO 14971 Risk Management ISO 14971 - Medical Device Risk Management 5
A ISO 14971 PFMEA Manufacturing Risk ISO 14971 - Medical Device Risk Management 2
Q Example of the Risk Template Document Control Systems, Procedures, Forms and Templates 1
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
A IEC 60601 11.2.2.1 Risk of Fire in an Oxygen Rich Environment, Source of Ignition IEC 60601 - Medical Electrical Equipment Safety Standards Series 0
D Importing a general wellness low risk product Other US Medical Device Regulations 3
C Quantifying risk in choosing the number of parts, operators and replicates in a GR&R Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 4
R AQL, Consumer Risk and MA Statistical Analysis Tools, Techniques and SPC 2
M Risk managment report of Surgical Mask Example ISO 14971 - Medical Device Risk Management 14
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
R ECG Risk Analysis Standards ISO 14971 - Medical Device Risk Management 2
N Device Labeling - Medtronic Ventilator Files (Risk Management documents) Coffee Break and Water Cooler Discussions 2
A 5 x 5 Risk Matrix - Looking for a good example Manufacturing and Related Processes 2
F Risk for Quality Assurance Department in a Hospital - Hospital Incident Reporting ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 7
M Should volume of sales be factored into risk probability assessments? ISO 14971 - Medical Device Risk Management 33
T How do you define your Hazards? <a Risk Management discussion> ISO 14971 - Medical Device Risk Management 16
adir88 Documenting Risk Control Option Analysis ISO 14971 - Medical Device Risk Management 8
B Risk Assessment Checklist for Non product Software IEC 62304 - Medical Device Software Life Cycle Processes 1
MrTetris Should potential bugs be considered in software risk analysis? ISO 14971 - Medical Device Risk Management 5
K Identification of hazards and Risk file IEC 62366 - Medical Device Usability Engineering 7
S Risk based internal auditing Internal Auditing 6
Robert Stanley I'm @ RISK of not showing my RISKS! ISO 9000, ISO 9001, and ISO 9004 Quality Management Systems Standards 20
M Estimating the benefit-risk ration under MDR EU Medical Device Regulations 1
adir88 Information of safety can reduce risk now? ISO 14971 - Medical Device Risk Management 12
G Any good examples of CAPA forms that include a risk based approach? ISO 13485:2016 - Medical Device Quality Management Systems 8
adir88 MDR requirement: Risk Management Plan for "each device" ISO 14971 - Medical Device Risk Management 5
M Has anyone heard of Run at Risk? Manufacturing and Related Processes 15
Tagin Is SARS-CoV-2/COVID-19 on your risk register? Misc. Quality Assurance and Business Systems Related Topics 11
D IEC 62304 Risk Classification - With and without hardware control IEC 62304 - Medical Device Software Life Cycle Processes 2
J ISO 14971 applied to ISO 13485? Low risk class 1 devices ISO 13485:2016 - Medical Device Quality Management Systems 3
DuncanGibbons Classification of aerospace parts depending on their risk and criticality etc. Federal Aviation Administration (FAA) Standards and Requirements 3
D Performance specification as a Risk Control Measure, EN 14971 ISO 14971 - Medical Device Risk Management 7
M Risk Classification For Supplier - Clinical Research Organisation (CRO) Supply Chain Security Management Systems 3

Similar threads

Top Bottom