Is that any difficulty to do software DFMEA and PFMEA in ISO 13485?
- Thread starter qazxsw
- Start date
I could write quite a bit on this topic, but I will restrict this post to a few specific problem area when trying to apply FMEA concepts to risk management for software. Others are sure to chime in about the differences between standards briefly referenced as 13485, 14971, 60601-1, and 62304. I hope to convince you in a rather direct method why you should be strongly considering applying the concepts of 62304 when software is an element of your medical device.
1) Sidestepping the point that FMEA address failure modes and not hazards: Software itself does not represent a hazard. Software does not not inflict injury. Software is not a biological infectious agent. It is not possible to expose someone (patient, user, other stakeholder) to software. At least not until we are all robots.
2) When software fails, it does not fail like hardware does. Just because one gear is worn in a medical device it does not mean that the same gear in all the other medical devices of the same design are worn.
These 2 general differences between software and other elements of medical devices invite an industry-accepted development methodology commensurate with the risks of using software as a design solution within medical devices. 62304 is the consensus standard in this area.
I generally agree with the criticism that 62304 occasionally steps away from being a 'process' standard (which it is excellent at, IMO) into the realm of a 'product' standard (which it is not very good at, IMO) but despite any perceived flaws it is the consensus standard and medical device manufacturers who incorporate software in their devices have no good reason to avoid aligning with it.
1) Sidestepping the point that FMEA address failure modes and not hazards: Software itself does not represent a hazard. Software does not not inflict injury. Software is not a biological infectious agent. It is not possible to expose someone (patient, user, other stakeholder) to software. At least not until we are all robots.
2) When software fails, it does not fail like hardware does. Just because one gear is worn in a medical device it does not mean that the same gear in all the other medical devices of the same design are worn.
These 2 general differences between software and other elements of medical devices invite an industry-accepted development methodology commensurate with the risks of using software as a design solution within medical devices. 62304 is the consensus standard in this area.
I generally agree with the criticism that 62304 occasionally steps away from being a 'process' standard (which it is excellent at, IMO) into the realm of a 'product' standard (which it is not very good at, IMO) but despite any perceived flaws it is the consensus standard and medical device manufacturers who incorporate software in their devices have no good reason to avoid aligning with it.
Looks like there may be a bit of confusion on the standards.
ISO 13485 is a quality system standard for which you can apply and get your quality system registered. It does not speak directly to software. It does call out 14971 for risk management so there's an expectation that your quality system incorporate a risk management process. So 13485 is at the company level and your quality system would likely incorporate the 62304 aspects as part of your quality system approach.
62304 is strictly a software development lifecycle standard. As far as I know, a company cannot get "licensed" for it. 62304 is a recognized consensus standard in the US and a harmonized standard in the EU so compliance to it will give you a presumption of conformity to the relevant requirements for products in those jurisdictions. It also calls out 14971 so risk management for software is necessary. 14971 does not require FMEA for risk management (of software or anything else); however, that's probably the most common approach - although it's generally a separate FMEA (a software-specific FMEA). 62304 does call out some specific aspects to consider as part of your (software) risk management. (And if you have an electro-mechanical system that gets assessed for safety under 60601-1 and your software is considered "PEMS" [Programmable Electronic Medical Systems] then there are some additional considerations for software risk management.)
I don't see any particular difficulty in applying FMEA concepts to software. As noted above, there are drivers (62304 and 60601-1) that you should consider in your FMEA.
As your attachment points out, 62366 should also be considered if your software provides a user interface. That standard also calls out 14971 and has expectations for identifying risks associated with use (generally incorporated in a use-specific FMEA).
You should have a comprehensive risk management process that incorporates approaches to risk management for software and use as well as for design (DFMEA) and manufacturing (PFMEA).
On another note, pretty much everywhere you would want to market is requiring a cybersecurity assessment. There are standards and guidance docs for this as well and you should absolutely address this to ensure successful regulatory clearance.
ISO 13485 is a quality system standard for which you can apply and get your quality system registered. It does not speak directly to software. It does call out 14971 for risk management so there's an expectation that your quality system incorporate a risk management process. So 13485 is at the company level and your quality system would likely incorporate the 62304 aspects as part of your quality system approach.
62304 is strictly a software development lifecycle standard. As far as I know, a company cannot get "licensed" for it. 62304 is a recognized consensus standard in the US and a harmonized standard in the EU so compliance to it will give you a presumption of conformity to the relevant requirements for products in those jurisdictions. It also calls out 14971 so risk management for software is necessary. 14971 does not require FMEA for risk management (of software or anything else); however, that's probably the most common approach - although it's generally a separate FMEA (a software-specific FMEA). 62304 does call out some specific aspects to consider as part of your (software) risk management. (And if you have an electro-mechanical system that gets assessed for safety under 60601-1 and your software is considered "PEMS" [Programmable Electronic Medical Systems] then there are some additional considerations for software risk management.)
I don't see any particular difficulty in applying FMEA concepts to software. As noted above, there are drivers (62304 and 60601-1) that you should consider in your FMEA.
As your attachment points out, 62366 should also be considered if your software provides a user interface. That standard also calls out 14971 and has expectations for identifying risks associated with use (generally incorporated in a use-specific FMEA).
You should have a comprehensive risk management process that incorporates approaches to risk management for software and use as well as for design (DFMEA) and manufacturing (PFMEA).
On another note, pretty much everywhere you would want to market is requiring a cybersecurity assessment. There are standards and guidance docs for this as well and you should absolutely address this to ensure successful regulatory clearance.
indubioush
Ah ha!
Like Yodon mentioned above, FMEAs are not required to comply with ISO 14971. Depending on your software level of concern and the device risk classification, it may be going overboard to do a separate PFMEA, DFMEA, UFMEA, and hazard analysis. You will still be compliant with ISO 14971 if you are able to capture all requirements for risk analysis, control, etc. in one hazard analysis document in which you can easily extract softare-related risks.
There are some strange ideas about software in the related areas of development and risk controls. In this thread, I don't want to believe that @yodon was specifically advising the use of a pFMEA to analyze medical device software risks. I took his reference to pFMEA to be nothing more than a reference to another possible element of a more comprehensive approach to risk management. The original title of the thread certainly appears confused, and I think yodon did a good job trying to clear that up.
One of the oddest things I've seen in the area of risk controls related to software is a concept from ISO/IEC Guide 63 in reference to the process of developing software. In that document there is a new category of risk control for software that implies (paraphrasing by me) "if you have a rigorous development process you can control systemic risks" (4.6.2). This ("establishing a rigorous process"), along with some advice from GAMP 5 in the area of performing risk assessments and identifying risk controls, is something I have seen teams try to use as a rationalization for controlling risks relating to software in a 14971-compliant approach to risk management. I believe that following a rigorous development process can effectively control risks, but I don't believe that just having such a process is a risk control.
Similar threads
