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

#1
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 ?
 

Attachments

Elsmar Forum Sponsor

Tidge

Quite Involved in Discussions
#2
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.
 

yodon

Staff member
Super Moderator
#3
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.
 

indubioush

Quite Involved in Discussions
#4
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.
 

Tidge

Quite Involved in Discussions
#6
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
K Software Updates in the Field and ISO scope ISO 13485:2016 - Medical Device Quality Management Systems 0
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 8.5.1.1 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
T Do I need a qualified compiler for class B software? IEC 62304 - Medical Device Software Life Cycle Processes 3
S Manufacturing Execution Systems Software Costs Manufacturing and Related Processes 0
E 13485:2016, Sections 4.1.6, 7.5.6 and 7.6 - Validation of Software - Need some Advice please ISO 13485:2016 - Medical Device Quality Management Systems 2
R Medical Device Software Certification IEC 62304 - Medical Device Software Life Cycle Processes 1
S HIPAA-compliant monitoring software (advice needed) Hospitals, Clinics & other Health Care Providers 0
A Software bug fixes after shipping a product EU Medical Device Regulations 3
J Medical software Patient outcome Medical Information Technology, Medical Software and Health Informatics 2
Y We are Looking for EASA LOA TYPE 1 experienced software developer Job Openings, Consulting and Employment Opportunities 0
F Grand Avenue Software, Q-Pulse or Qualio - which for a full eQMS? Medical Information Technology, Medical Software and Health Informatics 1
K SOUP (Software of Unknown Provenance) Anomaly Documentation IEC 62304 - Medical Device Software Life Cycle Processes 2
Q Storing and developing SAMD (Software as a Medical Device) in the Cloud IEC 62304 - Medical Device Software Life Cycle Processes 3
I Old Time Scatter diagrams for defect type and location- software Quality Tools, Improvement and Analysis 3
SocalSurfer AS9100 new certificate, but need QMS software, help Quality Assurance and Compliance Software Tools and Solutions 2
C Is my software an accessory? Telecommunication between HCP and patients EU Medical Device Regulations 10
K Verify Software Architecture - supporting interfaces between items IEC 62304 - Medical Device Software Life Cycle Processes 1
A What are the pros and cons of using an audit software for internal auditing? General Auditing Discussions 4
A Risk Number for each software requirement IEC 62304 - Medical Device Software Life Cycle Processes 7
R Shall a new UDI-DI be required when stand-alone software device's version is updated? EU Medical Device Regulations 1
R MSA for ATE (Automatic Test Equipment Embedded Software) Gage R&R (GR&R) and MSA (Measurement Systems Analysis) 9
S MDR GSPR Clause 17 - Software Requirements EU Medical Device Regulations 2
L Turkish Requirements - Does the Software need to be translated? CE Marking (Conformité Européene) / CB Scheme 2
MDD_QNA Medical Device Software - Is a Help Button required? IEC 62304 - Medical Device Software Life Cycle Processes 1
F Software as a Medical Device (SaMD) Technical File Requirements Manufacturing and Related Processes 1

Similar threads

Top Bottom