SBS - The best value in QMS software

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.


Staff member
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.


Quite Involved in Discussions
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
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
S DHF/DMR/MDF for a software-only, cloud-based, single-instance device Medical Information Technology, Medical Software and Health Informatics 1
H Software Validation for FFS Packaging Machine Qualification and Validation (including 21 CFR Part 11) 1
E Any sample of a full software life cycle IEC 62304 report ( any class )? IEC 62304 - Medical Device Software Life Cycle Processes 1
Q ISO 13485 7.5.6 Validation - Off the shelf Software ISO 13485:2016 - Medical Device Quality Management Systems 3
M ERP / QMS related software standards for Validation IEC 62304 - Medical Device Software Life Cycle Processes 6
J Do Software Subcontractors need to be ISO13485 compliant in the EU? EU Medical Device Regulations 3
D Safety data sheets software REACH and RoHS Conversations 2
N What are the software audit and control steps Reliability Analysis - Predictions, Testing and Standards 2
N Validating Software before getting approved as Class 2 device US Food and Drug Administration (FDA) 5
M Clinical Decision Support Software Question 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 2
P Missing 1m visual alarm signal in case of software/display failure, mitigation? ISO 14971 - Medical Device Risk Management 3
B Software service provider as critical supplier ISO 13485:2016 - Medical Device Quality Management Systems 4
S Asterisk in DOE minitab software Using Minitab Software 23
M Surgical angle measurement guide device with an application software Medical Device and FDA Regulations and Standards News 1
M Advice needed for SEH Compliance Software and ISNETWord Compatabiliy Occupational Health & Safety Management Standards 2
bruceian Software Quality Metrics Software Quality Assurance 11
optomist1 How Secure Are Our Software Systems Software Quality Assurance 7
M 'Active' device? Software/laptop with attached camera 'looking' at passive metal probe EU Medical Device Regulations 3
D Software validation team Misc. Quality Assurance and Business Systems Related Topics 3
O Any info on release date of FDA “Computer Software Assurance for Manufacturing and Quality System Software” document? 21 CFR Part 820 - US FDA Quality System Regulations (QSR) 0
L Radiology software Class I exemption Medical Device and FDA Regulations and Standards News 3
O Software for comparing text of PDF files Contract Review Process 2
J Implementing an ISO 13485 QMS Software ISO 13485:2016 - Medical Device Quality Management Systems 6
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 2
M Recurrent event analysis software (python) General Auditing Discussions 2
Y UL 1998 Standard: software classes Software Quality Assurance 0
P Need a programmer for QVI's VMS software for optical inspection machine Inspection, Prints (Drawings), Testing, Sampling and Related Topics 0
S IEC 62304 software costs and time Medical Device and FDA Regulations and Standards News 3
S IEC 62304 - Software verification cost IEC 62304 - Medical Device Software Life Cycle Processes 3
Sravan Manchikanti Software Risk Management & probability of occurrence as per IEC 62304 IEC 62304 - Medical Device Software Life Cycle Processes 8
I Form templates for software (iso9001) Document Control Systems, Procedures, Forms and Templates 0
H Software Interface Translation IVD Regulation EU Medical Device Regulations 0
C Control of Equipment, Tools, and Software Programs - Questions about the extent of control of NC programs AS9100, IAQG, NADCAP and Aerospace related Standards and Requirements 5
M IEC 62304 Software changes - Minor labeling changes on the GUI IEC 62304 - Medical Device Software Life Cycle Processes 3
silentmonkey Rationalising the level of effort and depth of software validation based on risk ISO 13485:2016 - Medical Device Quality Management Systems 10

Similar threads

Top Bottom