The healthcare sector is a highly regulated environment in which key activities must be properly documented to minimize the risk of error and potential harm to end users – both patients and care providers. This approach imposes certain limitations and requirements on how to conduct development projects. Sii Poland experts support clients in Medical Device development and assist them in applying similar principles to Software as a Medical Device (SaMD) projects.
Due to the nature of Medical Device production, organizations worldwide have identified the need to create uniform rules and standards necessary to carry out such projects. By applying the regulations, all parties involved are committed to protecting patient safety, while still promoting medical innovation.
— Sii Poland is a consulting company that works with the client’s quality and risk management systems — says Wojciech Drescher, Senior Head of Healthcare at Sii Poland. – Currently, companies must have a working environment in which ISO 13485 (Quality Management System) and ISO 14971 (Risk Management) have been implemented, and software development for Medical Devices is performed in line with IEC 62304. If it’s not the case, Sii specialists can help the client implement the required setup — he adds.
Software Safety Classification – a must for systems in Medical Devices
For software systems in Medical Devices, one of the first steps required by IEC 62304, a functional standard that covers software design and maintenance, is the establishment of a Software Safety Classification (SSC). It is determined by a risk-based approach, and defines three safety classes for solutions:
- A: no injury or damage to health is possible,
- B: injury is possible but not serious (reversible),
- C: death or serious injury is possible.
This classification differs from the EU Medical Device Regulation (EU MDR) or the US Food and Drug Administration Medical Device Classification (FDA MDC). It is possible to still have a Class III Medical Device while having a Class A SSC.
Software Risk Determination – how to ensure process efficiency
Complex software can increase the risk of event sequences leading to hazardous situations. Risk management in the context of healthcare companies involves the effective identification of such events as well as reducing their likelihood and preventing harm.
— Sii’s team of specialists conducts a comprehensive software risk management process – says Marek Matuszak, Senior Software Engineer at Sii Poland. — The analysis is performed at the system level, taking into account not only software and intended use, but also the existing Medical Device hardware and mechanics, accessories, and foreseeable misuse — he explains.
First, Sii experts assess the risk based on a single-fault, worst-case scenario. Then, the rules defined by the IEC/TR 80002-1 document are used to select typical software fault scenarios. When it comes to network-connected devices, cybersecurity issues are also taken into account.
— As an example, consider that the software is responsible for controlling an actuator — says Marcin Lis, Compliance and Medical Software Validation Specialist at Sii Poland. — The question to be answered is what could happen if the software drove the actuator away at the least expected time and position? Or, instead of stopping, it drove the actuator further than intended? What damage could result from such an event? — he continues.
Following a detailed analysis, a list of risks is created, which is then compared with the client’s risk analysis to determine whether the risks are acceptable or not.
Impact on the development of Medical Devices
As a result of the process, there are three possible outcomes:
- All risks are acceptable and the software system is Class A.
- Some of the risks are unacceptable, but it is possible to implement external risk control measures. This includes, but is not limited to, designing hardware mitigation methods or developing other measures to reduce the effects of a software error.
- Some of the risks are unacceptable, a class B or C is assigned, depending on the severity of the possible damage. Additional software requirements can be introduced, which become Risk Control Measures. Higher SSCs, software requirements, and test results can be used as an argument to reduce incidence in the ISO 14971 analysis.
Since IEC 62304 requires all software risks factors to be considered with a probability of occurrence of “1”, the risk assessment between IEC 62304 and ISO 14971 has some points in common but should be treated as two different domains.
— Security and quality come first, without compromise — says Piotr Mazurski, Lead Auditor/Cybersecurity Consultant at Sii Poland. — The higher the SSC, the more rigor must be imposed on the software development process according to IEC 62304. The development of Class C software requires significantly more resources than Class A software. This is due to requirements that are optional for Class A.