ISO 14971 Risk Management questions and comments

Marcelo

Inactive Registered Visitor
#1
Hello all

Sometime ago a member, emailed me privately with some questions he had about ISO 14971 and risk management. I tried to return to him but his email had some problem. So, i will put his questions (no personal information) here as a way for him to see and also because i think the information might help others.

Questions

1- Risk Management Plan- I understand the risk management plan identifies the device and provides a description, states the action levels, etc... can a product development plan serve the same purpose?

2- We have decided to use the FMEA method, does the FMEA for a particular device have to be all encompassing: include PFMEA, SFMEA, etc... how thorough does it have to be?

3- Risk Management Report: can this report be a part of the management review?

Answers / comments

1 - the interface between RM and product development is, in my experience, the most problematic aspect manufacturers have with the risk management process. This depends on what kind of product development process your using. Is your product development based on NPD (whole product life-cycle from initial planning and concept until product disposal) or the old approach which only lasts until product launch (the old "project" phase)? As risk management is a life-cycle approach, for it to be fully included in the rpoduct developemnt, the product development process also have to use the life-cycle approach. But just this is not enough, because of some other points related to the RM process and regulatory requirements in general.

First, let´s get some things straight: you said "I understand the risk management plan identifies the device and provides a description, states the action levels, etc."... identification and description of the device is the last important thing in the plan IMHO (and this surely can be easily tied to the producr development plan)...what is really important in the plan (in any of those plans) is HOW, meaning, the actions, we will perform to achieve the objectives (as you seem to have a lot of experience in other industries maybe i would not need to make this clear, but as some people has a "weird "vision of planning, i usually repeat this "mantra" so we are on the same level of understanding irf we were not: plannning means,you plan the actions, then you do as planned...simple as that). So your product development plan serves to detail the steps you will take to develop the product, and in then the rest of your product development process will simply perform what you planned. The RM plan is the same, you plan the actions you will take to fulfill your RM process objectives, and then follow the actions.

One of the problems is here: the objectives of the product development process and the RM process are different (although you can always say that the objective of the development process is to develop safe product, this in practice cannot be done).

Second problem: as with every regulatory requirement, RM is a "control" to something.....and as a control, it has to be "put" on some defined points in the process it´s trying to control, and, worse, it has to begin in a specific time. Where do the risk management, as defined by regulatory requirements and ISO 14971, begins? Well, again it depends on the development process you use.

Let´s assume you use the life-cycle approach to development. Then, planned stages of your development would be something like:

1 - strategic planning for products (or product portifolio plannning) - for the strategic development of all products
2 - product planning (for the product in question - this would be what you call "product development plan" )
3 - informational project
4 - conceptual project (at the end of this phase you would choose between some concepts and then commit to develop the the concecpt of choice)
5 - detailed project
6 - manufacturing preparation
7 - product launch
8 - product use/ service/ etc.
9 - product disposal

Let´s also assume that you make you RM plan in conjunction with the development planning (stage 2). When will RM for the product begins? In fact, the regulatory/ISO 14971 RM is a "life-cycle aprroach", in fact the activities of the process (after planning) can only begin at the detailed project phase (5), after a concept has been choosen...before that, you do not have a "product" but a lot of product ideas.

(Important: You sure can (and i recommend this for my clients) use RM for the first phases, but these RM would not be the "product RM" required by regulations and ISo 14971. These will be more business risk management and project risk management)

There are some more problems, but i think you already got the point.

So, resuming point 1 - answer to your question "can a product development plan serve the same purpose?" is NO. But, you CAN do the RM plan in conjunction with product development plan, as long as your product development plan can accomodate a paralell RM plan (it need to be life-cycle based and some other detaisl). They´re are not the same because they don´t have the same objects / purpose but you have to take into account all these little problems (and others) i cited...in the end, thought, i would really advice you make a separate RM plan (in fact, the whole RMprocess), because it will facilitate, in the future, the audit of such system.

2 - let´s try to get it more quickly this time. Reg requirements (and ISO 14971) require that a product always be safe in the entire product lifecycle. So you have to make sure that at all stages the risk is minimized. This includes, design and development, manifacturing, services, everything. Take manufacturing for example: you could design a beautifully safe product in the design, but if your manufacturing process introduces other safety concerns, the you could end up in the end with a hazardous product to your client. So you have to use the risk management process in all phases to make sure that the product is always safe.

Regarding FMEA: as you know by expericence, FMEA is a risk analysis technique, meaning that it applies to a portion ot the RM process (important one, but not the process as a whole). There are a lot of debates on the use (or misuse) of FMEA in medical device risk management / analysis (take a look at this article by Mike Schmidt for example - The use and misuse of FMEA in risk analysis - http://www.devicelink.com/mddi/archive/04/03/001.html). The problem here is, manufacturers in general think that FMEA is synonymous with risk management. Thins means that they have a lot of trouble adjusting the process when they realize or are told (by an auditor NC?) that that´s not the case.


Just as a comment, what i always says to my costumers is: forget about the technique and think first about the whole process...then, use the right techniques at the right time (and know and do not forget the technique´s limitations - for example, , in the development process is described, FMEA is best used from the middle to the end of the detailed project phase (6) when you have more detailed components, and thus the "bottom-up" nature of FMEA makes more sense and can be used effectively).

3 - "Risk Management Report: can this report be a part of the management review?" - first and foremost, this document has to be part of the risk mangement file (as required by the standard) and of the planned "risk management process management review" (this can also be made in conjunction with the general management review, but you have to detail this in the risk management plan.

Anyway, you can USE the information, or even include the document (again) in the general management review (as defined, the risk management report "is intended to be a summary of the review of the final results of the risk management process.." so it´s is obviously an input for the general management review too as the management review have to review all enterprise processes).
 
Elsmar Forum Sponsor
R

Roland Cooke

#2
Thanks for posting this Marcelo, useful stuff.

Here's another one for your razor-sharp brain. I have my own views on the matter, but I'd like to hear yours.

I have visited many subcontract/outsource manufacturers over the past few years; they have had differing levels of understanding of, and compliance to, ISO13485 7.1 / ISO14971.

On more than a few occasions it has been explained to me that Risk Management doesn't apply to them, as they have nothing to do with the design, indeed don't know how the product will be used (if they know anything about it all).

How would you say ISO13485 7.1 / ISO14971 applies to them, i.e. the requirement to implement risk management across all of product realization?

In particular how can they address risk management as it pertains to customer-related processes (7.2)?
 
M

MIREGMGR

#3
Can I chime in with an opinion? We do a large amount of medical Contract Manufacturing under both FDA and 13485/MDD regulatory purview, and we also have many products of our own.

During Contract Review and at other input-points in our operational management, we sort jobs into the following categories:

1. OEM owns the design and handles regulatory compliance. We are a Contract Manufacturer.
In this instance, we expect our customer to work with us to collect information they need and direct our processes and operations as required to meet their obligations, including risk management. We cannot be responsible for product-use aspects of risk management; post-market surveillance; product validation; etc.
2. We own the design and market the product directly, and/or private label it for one or more distributors.
In this instance, we have full responsibility. The customer(s) are involved minimally or not at all. (Edit addition) Private-label customers may have specifications and idiosyncratic preferences for their labels, but we are regulatoriliy responsible for those labels.
3. OEM owns the design. We are a Contract Manufacturer, but also are contracted to handle design and regulatory compliance elements.
In this instance, the customer has full responsibility to regulatory authorities, including for risk management. We have shared regulatory responsibility for certain regulated processes, if applicable to the job in question, and dependent on the work contract.

Because we are an FDA-registered Establishment and are certificated for ISO 13485/MDD and CE, we may have more regulatory responsibility than would be the case if we were a non-medical manufacturer performing the same contract manufacturing processes. We know of instances where the FDA has regarded firms with both Contract Manufacturing and own-product manufacturing as having a "higher bar to clear" in regard to shared responsibilities during Contract Manufacturing.

We are contracturally responsible to the customer to handle certain specified aspects of the actual work necessary for them to be regulatorily compliant. That could involve beginning-to-end design services, maintenance of the DMR/DHF/technical file, life-cycle risk management, life-cycle product surveillance, etc. In such a contractural relationship, we expect the customer to supervise our work, since they have regulatory responsibility for it.
 
Last edited by a moderator:
R

Roland Cooke

#4
Great post MIREGMGR, you've captured what I consider to be the key criteria.

I would go a bit further though, purely on the assumption that not every organization is as enlightened as yours! :D

In many cases I've seen, the subcontracted company has a lot more knowledge and experience than the 'parent'. The obvious example is outsourced sterilization; many 'parent' companies have adequate understanding of validation, but many others do not, and these have to work more closely with the sterilization company to get things squared away.
In this example the sterilization company doesn't control design, but clearly their input can greatly influence the final risk management report.


In other cases, the subcontracted company can have technical knowledge of their processes that the parent simply doesn't know or understand. That knowledge can potentially affect the safety and effectiveness of the finished device.

So whilst the regulatory responsibility does indeed still lie with the 'parent', it is basically just good business practise for the two companies to establish the level of understanding between them early on in the process, and the subcontracted company shouldn't necessarily sit back.
To an extent that can be considered contributory risk management on the part of the subcontracted company.
 

Marcelo

Inactive Registered Visitor
#5
Hello All

Sorry for the late reply.

Nice question and comments, Roland and MIREGMGR.

I think that the main problema here, regarding the views of contractors and subcontractors, is that a lot of people do not have a "theoretical" and "systemic" view of what is required; Or, if they do, they try to avoid it :) (i do understand that a company needs a more practical focused approach to regulations, anyway)

I think the main points here are: who is responsible, and for what? And, more importantly, when?

Generally speaking, reg requirements wants that medical devices be safe and effective (and what else they might ask) during the product lifecycle.

The responsability for this is always with the "manufacturer", which could be a lot of things but to generalize, is the company which "register" the product.

So the manufacturer has the responsability of complying with reg requirements...this is the who and what..the when is also simply..at all times, because of the lifecycle approach.meaning they are always "on".

How this manufacturer deals with specific points of the lifecycle is not generally detailed (at least in the ISO 13485-ISO 14971-European new approach reg view).

Now, turning to subcontrating and design - as with the rest, the regulations are always "on" on them, so if a manufacturer subcontracts something, he has to make sure that what is subcontracted is according to regulations. Theoretically speaking, this is for everything, but, getting real, this is usually applied to things - processes, equipment, parts, etc - which can impact the safety and effective of the device (you would not expect, i hope, that a manufacturer has a detailed policy on how to buy toilet paper :))

Now, going to the "management system" aspect, it´s intereting to note that, when you subcontract, it´s expected (but not always understood) that you subcontract a service with the same level of "everything" that you do. To tell you the truth, theoretically speaking again, i think that, if you are working under a ISO 13485 management system, you would need to subcontract a company which have the same requirements, meaning, a company running an ISO 13485 management system. Not that, due to the nature of the risk management process, this is also true to the risk management process. This view is being noticed by some, and i´ve seen a lot of discussions (and service providers adhering) to this, in what is called "management system parity". For me this is what things are going to (and this also happens in other sectors, specially riskier ones).

Now, going back to earth, surely there´s some options here. I think MIREGMGR summarized very well almost all of the options.

Expanding a little on what he said andtrying to tie up all thins to answer your questions...

I would expect that a manufacturer has requirements for subcontracting, obviously. These requirements should be derived from the requirements for the product (7.2.1). But the extent os the requirements depends on the type of agreement between the manufacturer and the service provider. This also depends on other factors, such as the regulatory strategy and what the manufacter can/want to do, as MIREGMGR exemplified.

(also, take in mind that the "customer-related process" name is a little misleading because, in fact, the majority of a product requirements are not directly expected from the customer, but derived from the solutions implemented to fulfill the general, high-level costumer requirements..that´s why i prefer to always use "product requirements")

Taking the risk management process, for example. The manufacturer could decide that all risk management tasks would be deal internally. In this case, he would be boyng a "black box" solution and apply the risk management process to this solution, only with the "final" solution (for example, the manufacturer buys a transformer for the equipment they manufacture). But what is needed, then, is that this solution requirements be detailed enough for the solution provider....the manufacturer would have to guarantee that the "final" solution incorporates all the requirements necessary to comply with the requirements (for example, clearance and creepage distances complying with IEC 60601-1 on the transformer) and that the solution is always the same (or the expected limits). As you can see, this is going back to the management system. This also mean that the "risk managent process" would have to be done in conjunction with the requirements development (which i think is a good design practice - in the process i implement in my clients, there´s a "requirements engineering process" which is tied direcly to the risk management process - when there´s a new requirement,they feed them in the risk management process to determine if there´s risk related to it, then control if necessary, etc - it´s all part of the big management system).

Now, if the manufacturer wanted to go for the "same level of "everything"" that i said, he could require that the solution provider be incorporated in his risk management process. This is a good solution, it would be what you called "contributory risk management" (and example 1 from MIREGMGR), but truth is, it´s in so straighforward..it can be easily done, but it´s not complete, because, there should be other requirements, not just "putting the guys inside our risk management process"..and the requirements for a management system? Why only have requirements for the risks management part?

Well, again, in my opinion the best solution would be to require that the solution provider have management systems (quality, risk management, and others) in place. This solution also has a lot of problema (there would be need to detail the partciular requirements for the product in question anyway...also, there´s a debate if these solution providers systems mneed to be certified or if not, etc.) but it can help a lot of things.

Wow, again a big message. Sorry for that....I do prefer more short, to the pont messages, but of late i´m using the discussions here to organize my own thoughts :)
 
J

Jim-S

#6
I am currently struggling with implementing risk management at my company, so I thought maybe I could get your feedback on my situation.

My company purchased the rights to a single marketed medical device from another company. The previous owners created a risk management plan that is thorough and is still valid for the product. - Right now we have a lot of confusion on our site. People are trying to incorporate risk management into their own SOPs, instead of deferring to the risk management procedure and design review. In other words, one person is revising the complaints SOP to include a risk assessment of the complaints. Then, another person is asking to revise the purchasing SOP to include a risk assessment of each supplier.

I’m not really sure what the best way to address all of this is, so I was wondering how everyone else is treats this. Am I correct in thinking that all of the risk management information for this product should be captured in the risk management file and design review? Do we really need to have all of these mini-risk assessment procedures incorporated into our existing SOPs?
 

Marcelo

Inactive Registered Visitor
#7
You would do better treating risk management as a "process", instead of pulverized procedures (but this depends on uour company approach to management systems).

The best way is to define a team to handle the process, with a process owner, measurements, etc.....the information about the process will have to be in the risk management file (and other files defined by ISO 14971, if you´re using it), so there´s no need to pulverize the ifnromation in a lot of other procedures.....you might need some cross-references, though.
 
M

MIREGMGR

#8
We like the functional benefits from a distributed process, with a risk analysis element to most of our operational decisions.

We of course do a product risk analysis for those products for which we have appropriate responsibility, focused on product-safety-and-effectiveness-related hazards to the patient, user, and other persons and to the environment in regard to secondary hazards to persons. That analysis considers product design, product manufacturing processes, and product use including user actions. I'm sure there's room for improvement, but that's where we are at the moment.

We do a risk analysis of production processes, focused on their effective ability to turn out product that conforms to specifications and meets our and our customers' other goals, including business goals. This one and the product risk analysis are distinct because they use different definitions of hazard, harm, severity, probability and control/detectability. We want the flexibility to consider a sufficiently egregious failure to meet specifications, but with no significant potential for harm to persons or the environment, to be of maximum Severity anyway so as to make the analysis maximally beneficial to our process engineering efforts.

We do a risk analysis of each post-market surveillance contact, including any complaints or adverse event reports.

We do a risk analysis in regard to going forward with certain product types and customer requests.

When we first began trying to grasp what "risk analysis" would mean to us, we thought that we could do just one big analysis, and we'd be done. Well, it turns out that the concept may be broadly applicable, but the working definitions need to be specific to the class of issues being addressed. Thus we now think multiple analyses are essential.
 
R

Roland Cooke

#9
I am currently struggling with implementing risk management at my company, so I thought maybe I could get your feedback on my situation.

My company purchased the rights to a single marketed medical device from another company. The previous owners created a risk management plan that is thorough and is still valid for the product. - Right now we have a lot of confusion on our site. People are trying to incorporate risk management into their own SOPs, instead of deferring to the risk management procedure and design review. In other words, one person is revising the complaints SOP to include a risk assessment of the complaints. Then, another person is asking to revise the purchasing SOP to include a risk assessment of each supplier.

I’m not really sure what the best way to address all of this is, so I was wondering how everyone else is treats this. Am I correct in thinking that all of the risk management information for this product should be captured in the risk management file and design review? Do we really need to have all of these mini-risk assessment procedures incorporated into our existing SOPs?
I think the answer to your basic question is "yes, we need to incorporate risk-based decision-making across all our processes".

However you may want to start off more strategically and work down through the QMS (over a few weeks/months) rather than try to ram this down everyone's throats straightaway.
You need everyone's buy-in, you can't afford to alienate them.
 
W

Watchwait

#10
GREAT conversation in this thread. Very helpful and informative.

My question focuses on the documentation required in the risk management process, in particular the specific contents of the "Risk Management File". Presently, we have one document, a Hazard Analysis for each device that comprises the "Risk management File". Our NB auditor has indicated that the HA itself is fine, but that the RM file is incomplete. So again, I'm looking for direction as to exactly what other documents are required to create and maintain a Risk Management file in accordance with ISO 14971 requirements. :thanx:
 
Thread starter Similar threads Forum Replies Date
M ISO 14971:2019: Criteria for overall residual risk ISO 14971 - Medical Device Risk Management 6
R Risk control measures as per ISO 14971 ISO 14971 - Medical Device Risk Management 6
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
K Overall residual risk according to ISO 14971:2019 ISO 14971 - Medical Device Risk Management 5
M Risk Analysis Flow - Confusion between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
J ISO 14971 applied to ISO 13485? Low risk class 1 devices ISO 13485:2016 - Medical Device Quality Management Systems 5
P Risk acceptability alignment between ISO 14971 and IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 6
S ISO 14971 Risk Management - Questions for Hazard identification ISO 14971 - Medical Device Risk Management 2
R The difference b/w FMEA & Risk analysis as per iso 14971 ISO 14971 - Medical Device Risk Management 8
D Risk management according to ISO 14971 - When to document risk controls? ISO 14971 - Medical Device Risk Management 10
D Where does FMEA fit in your ISO 14971 Risk Management process? ISO 14971 - Medical Device Risk Management 13
Q Information for safety EN ISO 14971:2012 - Customer Risk Reduction ISO 14971 - Medical Device Risk Management 6
M Informational ISO TC 210 JWG 1 meeting in São Paulo – Revision of ISO 14971 and ISO TR 24971 – Medical Device Risk Management Medical Device and FDA Regulations and Standards News 0
S In a risk analysis, how can we tie mobile app security breach to ISO 14971? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 4
M Example ISO 14971 policy and risk criteria ISO 14971 - Medical Device Risk Management 0
D Rationale for Risk Acceptability Matrix - ISO 14971 ISO 14971 - Medical Device Risk Management 9
Y Training as a risk control for ISO 14971 ISO 14971 - Medical Device Risk Management 13
W Risk Benefit Analysis - ISO 14971:2012 Requirements ISO 14971 - Medical Device Risk Management 27
C What is the difference between "Overall Risk" and "Risk"? (ISO 14971) ISO 14971 - Medical Device Risk Management 10
S Organizing Risk Analysis and Controls for a New Medical Device (ISO 14971) ISO 14971 - Medical Device Risk Management 4
A Is Risk Management Process compliant to ISO 14971 in absence of Hazardous Situations? ISO 14971 - Medical Device Risk Management 5
N Risk Severity Estimation for Medical Devices as per ISO 14971 ISO 14971 - Medical Device Risk Management 12
Marc Are you looking for ISO 14971 - Medical Device Risk Management? Risk Management Principles and Generic Guidelines 1
J Does anyone have an example of Risk-Benefit Analysis per ISO 14971? Other ISO and International Standards and European Regulations 2
M ISO 14971:2012 - Verification of Implementation of Risk Control Measures ISO 14971 - Medical Device Risk Management 12
N ISO 14971 Risk Analysis - Sections 4.2 and 4.3 ISO 14971 - Medical Device Risk Management 2
D ISO 14971 - Risk Analysis Best Practices ISO 14971 - Medical Device Risk Management 5
A ISO 14971 Figure E.1 that starts with Hazard and ends with Risk ISO 14971 - Medical Device Risk Management 3
A Risk Acceptance Criteria in ISO 14971 ISO 14971 - Medical Device Risk Management 19
M Risk Management (ISO 14971:2007) Internal Audit Checklist ISO 14971 - Medical Device Risk Management 7
K RISK ANALYSIS SAMPLE according to Annex ZA of EN ISO-14971-2012 Other Medical Device and Orthopedic Related Topics 1
K What is the policy for Risk Acceptability per ISO 14971 ISO 13485:2016 - Medical Device Quality Management Systems 2
M The Sequence of ISO 14971 Risk Analysis Activities ISO 14971 - Medical Device Risk Management 14
Sam Lazzara ISO 14971 Clause 7 - Evaluation of Overall Residual Risk Acceptability ISO 14971 - Medical Device Risk Management 3
C Risk Analysis of a "Medical System" according to ISO 14971 ISO 14971 - Medical Device Risk Management 5
N ISO 14971:2007 vs. 2009 - Which Risk Management Standard is still accepted in the EU Other ISO and International Standards and European Regulations 2
E ISO 14971:2009 Risk Management Requirements CE Marking (Conformité Européene) / CB Scheme 2
M ISO 14971 Medical Device Risk Management FAQ ISO 14971 - Medical Device Risk Management 38
M Risk Management Plan Template - ISO 14971:2007 Compliant ISO 14971 - Medical Device Risk Management 13
M ISO 14971 Risk Analysis and use of a DFMEA (Design FMEA) ISO 14971 - Medical Device Risk Management 8
C Scope of Risk Management in ISO13485 vs. ISO 14971/EU MDD ISO 14971 - Medical Device Risk Management 2
C ISO 14971 Clause 9 Requirements - Post-Production Monitoring and Risk Management ISO 14971 - Medical Device Risk Management 7
A Where can I buy EN ISO 14971:2009 (Medical Device Risk Management)? ISO 14971 - Medical Device Risk Management 11
Q ISO 14971 Class II Medical Devices - Product Realization & Risk Management ISO 14971 - Medical Device Risk Management 5
J IECEE Guidance Document for ISO 14971 Risk Analysis - IEC EN 60601-1:2005 3rd edition IEC 60601 - Medical Electrical Equipment Safety Standards Series 2
I Medical Device Risk Assessment to ISO 14971 ISO 14971 - Medical Device Risk Management 4
B Application of Risk Management - ISO 14971 for a Tooling Manufacturer ISO 14971 - Medical Device Risk Management 18
M Risk management, ISO 13485 and ISO 14971 ISO 13485:2016 - Medical Device Quality Management Systems 10
G Risk Analysis - Templates of EN ISO 14971:2007 and others ISO 14971 - Medical Device Risk Management 8

Similar threads

Top Bottom