Original Message:
Sent: 28-Jun-2023 11:31
From: Daniela Mahan Soler
Subject: Software risk managment
Hi,
Just a comment on IEC TR 80002-1. Last year I made a thorough review of this TR with the SW SME and we realized that it was actually quite out of date in comparison with the new version of ISO 14971/IEC 62304. So just make sure when using this TR you are actually following the most updated version of the RM standards, not this TR when conflicting.
The amazing world of standards. But keep an eye on it in case it gets updated.
Daniela
------------------------------
Daniela Mahan Soler Esq, RAC
Quality and Regulatory Affairs Manager
Munich
Germany
Original Message:
Sent: 28-Jun-2023 09:04
From: Edwin Bills
Subject: Software risk managment
@Richard Vincins comment contains an important reference that of IEC TR 80002-1. It is important that all impacts to device benefit-risk are captured in the device Risk Management File, so you are creating some complexity with your device here that may impact the Overall Residual Risk Evaluation portion of the device risk management process. An additional question will be how do you manage the separation post-market because risk management is a complete lifecycle process? It is just not for the initial device development process but also for maintenance over the entire device lifecycle.
------------------------------
Edwin Bills
Edwin Bills Consultant
ASQ Fellow CQE, CQA, CQM/OE, RAPS RAC
elb@edwinbillsconsultant.com
Original Message:
Sent: 27-Jun-2023 04:23
From: Richard Vincins
Subject: Software risk managment
Anon,
There are not necessarily any advantages or disadvantages ... I have incorporated all of them into a software development process for organisations where they have medical software in devices, stand alone software, and software which is non-medical purpose. The ISO 12207 and 16085 standards are just a bit more broad because they cover a wider range of software types from industrial applications to research to aerospace. If looking into the finer details, the principles of the methods are generally the same, but use caution because much of the terminology between the medical device side and general software side are not consistent. I had found individuals with software experience, but not experienced in medical devices, struggled a bit understanding the documentation side because of the different documentation and terminology used. Just a final comment, do not forget about IEC/TR 80002-1 which is a guidance for risk management of software which is quite useful - medical or non-medical.
------------------------------
Richard Vincins ASQ-CQA, MTOPRA, RAC
Vice President Global Regulatory Affairs
Original Message:
Sent: 26-Jun-2023 14:06
From: Rajeswari Devanathan
Subject: Software risk managment
It's important to note that ISO 62304 and ISO 14971 are specifically tailored to medical device software and risk management in the medical device industry. They provide specific requirements and considerations unique to the medical field. Therefore, it is still necessary to comply with ISO 62304 and ISO 14971 for the medical software portion of your device to ensure regulatory compliance and patient safety.
Using ISO 12207 and ISO 16085 alongside ISO 62304 and ISO 14971 for a system that combines non-medical and medical software can provide a comprehensive and structured approach to software development and risk management. This allows you to leverage the broader software engineering standards while also adhering to the specific requirements for medical devices.
------------------------------
Raje Devanathan
Amerisource Bergen
TPIreg, Innomar Strategies
Senior Manager - Regulatory Affairs, Medical Devices
rdevanathan@tpireg.com
3470 Superior Court
Oakville ON L6L0C4
Canada
Original Message:
Sent: 26-Jun-2023 11:58
From: Anonymous Member
Subject: Software risk managment
This message was posted by a user wishing to remain anonymous
We have a device that has both non-medical and medical software in a system configuration. Is it appropriate to use ISO 12207 Systems and software engineering - Software life cycle processes along with ISO16085 "Systems and software engineering - lifecycle processes-Risk Management" for the non-medical software? Are there any advantages to applying this standard for non-medical software over just using ISO62304 and ISO14971 for the whole system?