Is that any difficulty to do software DFMEA and PFMEA in ISO 13485?

Hi everyone,

Can somebody advice if there is any difficulty to follow DFMEA nd PFMEA for Software in ISO 13485?

Actually we developed a User Interface for medical device. Does it need to get IEC 62304 license? or General Standards (like ISO 13485) is enough ?


Elsmar Forum Sponsor


Trusted Information Resource
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.


Super Moderator
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.
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.


Trusted Information Resource
I wonder how a pFMEA for SW looks?... Is it really worth the trouble analysing SW's "production processes" separately?
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.
Thread starter Similar threads Forum Replies Date
Dazzur Difficulty in determining who should be addressing NCRs Nonconformance and Corrective Action 9
S Difficulty Finding A Notified Body for CE Marking - No Capacity Registrars and Notified Bodies 5
I Difficulty with calculated t-value for Linearity Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 7
A IMDS DIFFICULTY: Our customer requires the Wildcard portion MUST be < 0.1 % RoHS, REACH, ELV, IMDS and Restricted Substances 5
P Difficulty in Detecting Within Lot Variation when using Zbar W (Normalize) Chart Statistical Analysis Tools, Techniques and SPC 14
M Difficulty in demonstrating Compliance to Many EMC Standards specified! Other Medical Device Related Standards 9
I Difficulty in creating a Quality Manual Quality Management System (QMS) Manuals 4
C 5S - Difficulty in Standardization Lean in Manufacturing and Service Industries 11
Wes Bucey "In the middle of difficulty lies opportunity." - Einstein Career and Occupation Discussions 2
Antonio Vieira Difficulty ?passing? Quality audits - Number of Major / Minor Nonconformances Allowed General Auditing Discussions 12
S Training Evaluation Form - Evaluator feel difficulty to fill this form Training - Internal, External, Online and Distance Learning 12
J CQE Study Guide Indicative of Test Difficulty? Professional Certifications and Degrees 1
J Difficulty with cell phone reception in House with Aluminum Siding Coffee Break and Water Cooler Discussions 23
D Organisational Structure - Difficulty with a business stream approach Misc. Quality Assurance and Business Systems Related Topics 4
B Oil/water separators - Difficulty meeting state wastewater standards Miscellaneous Environmental Standards and EMS Related Discussions 4
S QOS for Tooling and Equipment - Having difficulty selecting a measurable QS-9000 - American Automotive Manufacturers Standard 2
T OTS (Off-the -Shelf) Software involved in error control and messaging US Food and Drug Administration (FDA) 1
dgrainger Informational MHRA Guidance: Crafting an intended purpose in the context of Software as a Medical Device (SaMD) UK Medical Device Regulations 0
G Compatibility Report for third-party software Medical Information Technology, Medical Software and Health Informatics 2
L Directive 2012/19/EU for medical software EU Medical Device Regulations 2
S Need guidance for Software validation Qualification and Validation (including 21 CFR Part 11) 5
C Can SaMD consist almost entirely of Software of Unknown Provenance (SOUP)? IEC 62304 - Medical Device Software Life Cycle Processes 4
Sam.F ISO9001/AS9100 Software Quality Assurance and Compliance Software Tools and Solutions 1
M Software Safety Classification and Legacy Software IEC 62304 - Medical Device Software Life Cycle Processes 4
Ron Rompen Document archiving software & hardware Document Control Systems, Procedures, Forms and Templates 0
Vader22 INTELEX software for their IATF 16949 QMS IATF 16949 - Automotive Quality Systems Standard 0
D Quality Gates for software development Software Quality Assurance 2
M Update to software after CE-certificate has expired. EU Medical Device Regulations 1
K Monitors supplied with software EU EU Medical Device Regulations 4
K Best automation presentation software Manufacturing and Related Processes 0
Paul Simpson Quality management system software development - looking for candidate organizations Quality Assurance and Compliance Software Tools and Solutions 2
N Software update after placed on the market Medical Device and FDA Regulations and Standards News 2
MaHoDie Is it possible to assign medical software to security class A (according to IEC 62304)? EU Medical Device Regulations 8
T Aircraft GAPP Software Testing Compliance Question AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 1
Q Training Matrix Software Training - Internal, External, Online and Distance Learning 2
I SaMD Software bug and issue tracking. Manufacturing and Related Processes 3
MaHoDie Where to show the Software version IEC 62304 - Medical Device Software Life Cycle Processes 2
W Looking for IATF 16949 (and ISO 17025) QMS software Suggestions Quality Tools, Improvement and Analysis 8
9 ECi M1 Software Consultants in Ohio Manufacturing and Related Processes 0
T SaMD or Software system? EU Medical Device Regulations 2
I Registration of MD software IEC 62304 - Medical Device Software Life Cycle Processes 0
Q Quality Plan for eQMS software ISO 13485:2016 - Medical Device Quality Management Systems 2
Ed Panek Validation of Signature Software (Off the shelf) US Medical Device Regulations 6
C FMEA Software Report View FMEA and Control Plans 1
jeancloude17 Advice for ISO 9001 for software Design and Development of Products and Processes 2
T Determination of Software/system end-of-life IEC 62304 - Medical Device Software Life Cycle Processes 5
D Software Bill of Materials (SBOM) preparation Other Medical Device Related Standards 6
D Software Registration GUDID 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
Sam.F Quotation software or spreadsheet Contract Review Process 2
T IVD Device Software - Risk Classification IEC 62304 - Medical Device Software Life Cycle Processes 16

Similar threads

Top Bottom