As we’ve seen in a previous post, non-functional safety is well covered in the medical device sector by standards such as IEC 60601-1. There are 45 standards covering active implantable medical devices alone. On top of the standards, there are numerous FDA guidance documents. Yet clear guidance on functional safety is not so easily identified.
While there are one or two positives such as the PEMS section of IEC 60601-1, clause 14 and IEC 62304 for certain aspects of software development, I’d like to argue that what the sector needs to better support risk assessment and functional safety is a dedicated standard.
We’ve seen that a key part of ensuring functional safety is a robust risk management system. Also vital is starting with the approach of safety by design. Finally, clear documentation and instructions are a must. All these aspects must be reflected.
Here, in a little more detail, are a few things I’d like to see in such a standard:
- Guidance on risk analysis, with certain techniques made mandatory according to the project type.
- Hardware defined in safety classes A to C, as in software, where A means no possibility of injury, B non-serious injury and C serious injury or death. Then specific relevant techniques should be recommended for given hardware safety classes.
- There should be additional supporting information for safety relevant software.
- Compliance stages should be defined, as should responsibilities and independence.
- Examples of how to address the activities should also be provided.
Specifically, on the subject of hardware, other key topics to include are microcontrollers and programmable logic, diagnostic coverage tips, high-integrity components, decomposition of safety classes, typical causes of failure and how to avoid them, and architecture diversity.
On the software front, software metrics for different software classes should be included, as should software tool qualification, software security and configuration, and calibration software.
There are also aspects of ISO 14971 covering safety by design that must go in too.
And finally, there should be confirmation measures, typically audits, assessments and reviews, to corroborate the achievement of functional safety.
Why is all this important? The medical device sector is an area where a lack of safety can cause harm and the patient is in general excluded from acting to reduce the harm themselves. At least in automotive, not only are development teams guided on the steps to develop safe software and hardware but the driver can choose to wear a seatbelt or helmet. There’s no equivalent in the medical device sector. So, on the most basic level, having all the appropriate guidelines in one reference document must make it easier for the manufacturer to do the right thing in a systematic way. And as I’ve said before, doing the right thing accidentally is all very well, but to prove it, be systematic about it and do it consistently, a standard is required.
If you want some more information about what functional safety is or how you can ensure best practice in the current absence of a standard please get in touch for a confidential discussion.