3 Lessons learnt by a medical device software company adopting ISO 13485:2016

Last week, we looked at the importance of setting up a Quality Management System. (You can read it here if you have missed it out.) It is clear that doing so brings many benefits. However, it is not as easy as it sounds.

This week, we spoke with Mr. Encey Yao, the Management Representative at Qritive Pte. Ltd., a medical device software company that recently completed its certification for ISO 13485:2016. He shared with us some insights to challenges faced, that would be shared by similar software companies.

 

What was the biggest challenge with implementing your Quality Management System?

The ISO 13485:2016 standard does not seem to obviously apply to software devices. It seems very abstract and unrelatable to the work done by software medical device companies, as development to the product is continuous and dynamic.

In the cases of hardware medical devices, it is very clear when a product has been designed or when it is complete and ready for validation, or installation to be checked, and distribution to be made. This is not quite so for software products. The product design is constantly being improved on, even while user needs remain unchanged. As such, it was hard to gain clarification on how the requirements of the ISO 13485 standard could be met.

Some of the additional factors software medical device companies need to consider include: At which point does Design Transfer occur? When do I consider a system update as a new version of my product or servicing of the existing product? How might I handle a product recall?

It was not easy for my team to define the points for tests and checks to be done, so as to ensure that risks have been addressed as much as possible. The definition of these points is likely to differ for various companies and products, due to the nature and purpose of the medical device.

What is useful and important to note when embarking on ISO 13485 certification?

A major consideration of the ISO 13485 standard is that of traceability and risks. Given the importance of patient safety, attention to risk assessment and risk management cannot be spared.

The IEC 62304 standard is a guideline specific to software medical devices. It is helpful in clarifying stages of the product lifecycle and processes related to them, and has been used as a guide for software medical device companies implementing the ISO 13485 standard.

It is essential to clearly distinguish between the design, manufacturing, and distribution stages of your medical device. This is best done from the start, so that the issue of traceability and risk management can be properly addressed. We were rather advanced in our product development by the time we looked into getting ISO 13485 certified. When we realised at that time about the stages to be distinguished, it was very difficult to manage the transition to work processes and a system that can better support traceability and risk management.

What is your key takeaway for other fellow software medical device companies going through the same path?

A takeaway from our experience of setting our QMS in place is that we should have started the design process based on the  guidelines in the IEC 62304 standard, and built on it with the ISO 13485 framework. There are apparent overlaps between the ISO 13485:2016 and IEC 62304:2006 standards, so it is important to clearly define processes and identify if they might be integrated or kept separate to be in line with the standards.

With our product at the heart of our business, our processes naturally revolve around its development. Focusing first on the system of processes for the product’s design and development, it would be less complicated to fit it within the framework of the ISO 13485 standard after. We spent quite a bit of time laying out all the clauses to analyse where our every business practice fits in, to make sure that we have our grounds covered with meeting the requirements of both standards.

If the IEC 62304 guidelines were noted early on in the design process, we could have more easily allowed for work processes to factor in the need for traceability and risk management. This would have included the selection of appropriate tools and platforms for our product development team to best fulfill requirements per the standards.

Still, making adjustments to our work processes was manageable once our team properly defined the stages of development for our product. Clarifying and being aware of the key junctures of possible risk helped our team avoid confusion and assign appropriate efforts to the various tasks required.

 

We thank Mr. Encey Yao for his observations and hope that his sharing is valuable to other software medical device companies. We will continue to provide insights on QMS implementation in our upcoming articles.

In the meantime, you can read more about the ISO 13485 standard here: