Risk acceptability alignment between ISO 14971 and IEC 62304

PaulG

Starting to get Involved
I'm working on a risk management process for medical device software development and have a question re risk acceptability. In clause 4.3 of IEC 62304:2006 AMD1:2015, software is classified as B or C if it results in "unacceptable risk." It doesn't state that the unacceptable risk must be mitigated as long as the category B or C is used in the development process. However, under ISO 14971, if we analyze the same software risks as in our safety classification, using the same criteria for risk acceptability, then any unacceptable risk must be mitigated through risk controls or redesign. So, how in practice could any software be left at a B or C safety class if the "unacceptable" risk must be mitigated under ISO 14971 requirements? It seems like a bit of a conundrum.
 

blah01

Involved In Discussions
Depends on the effect of the risk controls you implement. When talking about risks (i.e. harm to the user) you need to identify the probability of the harm occurring and the severity of the harm. If you are able to reduce the severity of the harm through risk controls then yes you could potentially change the safety class of that risk factor, but not all risk controls result in reducing the severity of the risk. Note that IEC 62304 4.3.a does state "which results in unacceptable RISK after consideration of RISK CONTROL measures". Therefore it's the residual risk (per ISO 14971) that then determines the safety class of the identified risk.

That's my interpretation anyhow and how I've implemented it.
 

PaulG

Starting to get Involved
Thanks Marc, I appreciate these insights. What is your usual approach to the sequence of safety classification vs software risk analysis activities? My interpretation would be to perform the software safety classification before ISO 14971 software risk analysis, because safety class (per clause 7 of IEC 62304) determines the level of risk management activities required. For example, safety class A software does not require any of the risk management activities.
 

Tidge

Trusted Information Resource
What is your usual approach to the sequence of safety classification vs software risk analysis activities? My interpretation would be to perform the software safety classification before ISO 14971 software risk analysis, because safety class (per clause 7 of IEC 62304) determines the level of risk management activities required.

My development projects that include software with ME devices start with a Hazard Analysis to see if the software can either contribute to unacceptable risks or will be allocate some element of controlling unacceptable risks. This is done before trying to evaluate the effectiveness of any non-software risk controls. So we don't do this before starting our 14971 process, but rather as part of the process.

Sidebar: The 'sub-process' step in the diagram of 4.3 is IMO deceptive, because it implies that a rather complete evaluation of all non-software risk control measures is to be done before entering the medical software development process. Except for the circumstance where the initial design has a clear allocation and segregation of risks arising (between hardware and software) from the device (the first decision diamond in 4.3) , this isn't practical: modern ME devices with software generally have parallel development between hardware and software elements. A further complication is that the FDA guidance requires determination of the "Level of Concern" prior to the implementation of risk controls; it would be disadvantageous to have to generate a different set of deliverables for an FDA submission and European registration.

With a preliminary Hazard Analysis (an early step in our 14971 process), the determination of classification is possible.

For example, safety class A software does not require any of the risk management activities.

I don't think it is precisely correct to say this. It is true that there are fewer required development deliverables for class A, but unless there literally is no "P1" for a software failure the only way you could claim that Class A software doesn't result in unacceptable risk would be to do the RM activities to support this conclusion.
 

PaulG

Starting to get Involved
Great. Thanks again for the input. These are fairly abstract concepts so it's really valuable to hear examples of how they are applied in practice.
 

blah01

Involved In Discussions
So we don't do this before starting our 14971 process, but rather as part of the process.
Agreed. For me doing risk assessment per ISO 14971 comes first keeping in mind that during the development phase of a product that the evaluation of effectiveness of risk controls can be an iterative process. In regards to the diagram in 4.3 of 62304 I simply see this as a high-level summary of 14971 actually with the resulting output being the classification of software system(s) in your product.

I don't think it is precisely correct to say this. It is true that there are fewer required development deliverables for class A, but unless there literally is no "P1" for a software failure the only way you could claim that Class A software doesn't result in unacceptable risk would be to do the RM activities to support this conclusion.
Agreed once again. One thing to note is that 14971 4.1 requires that results of the risk analysis be recorded in the risk management file; should that analysis conclude that no foreseeable hazards exist, that in itself needs to be recorded, and in effect, is part of RM activities.

Hope this helps.
 
Top Bottom