Head of Quality Management, TISAX Lead Implementer
At Spyrosoft, quality is the most important aspect of everything we do. In light of our new collaborations in the medical sector, today on the blog we’re discussing the quality management standards in Medtech with Marek Pałka, our Head of Quality Management.
What is the Quality Management System?
Currently, at Spyrosoft, we have a certified Integrated Management System that consists of ISO9001-Quality Management System and ISO27001 – information security Management System. This is the foundation of what we do as an organisation. They not only dictate how we provide services for our customers in a predictive and secure manner but also how we interact with our clients and within the company.
What’s crucial, our Management System based on these quality management standards serves as a kind of “umbrella” under which we further integrate and align with industry-specific standards and regulations. A good example here would be the A-SPICE framework and ISO26262 standard from the automotive industry and most recently – ISO13485 from the medical device industry. This integrated approach helps us, on one hand, to maintain the very idea of a system, process approach and continuous improvement – principles that are so common in ISO standards, and on the other to make the processes work for us, not the other way round.
What quality certificates and standards are used in the medical sector?
When we’d started analysing the quality management standards from the healthcare industry, we’ve quickly realised how similar these are to the automotive standards that we already have plenty of experience with. In the automotive industry there are strict process requirements when it comes to developing software for managing a car; in the medical sector – there are also industry-specific standards and regulations that are to ensure the proper development of medical devices. Regardless of the industry, in the end, there are people who are the end-users of cars or medical devices. Certain flaws in software used in a medical device could easily lead to the patients being diagnosed incorrectly and getting treatment that would not be suitable for them. The applicable standards and regulations are enforced in order to reduce such a probability.
Currently, we’re implementing the ISO13485 standard, which is a Quality Management System supplemented with regulatory requirements that are specifically used in healthcare. Since we’re already working in accordance with ISO 9001, so it will be a matter of filling in the gaps of the medical standard, which heavily relies on ISO9001. We have a detailed plan already in progress.
To get ISO13485 certified, among other things we also need an SW development project example from the medical sector where we will be able to show exactly the addressed requirements from the standards. Our current project activities in the medical industry include our collaboration with a Polish R&D company, Pro-PLUS where we’ve been working on a software platform for monitoring Covid-19 patients. Since our customer is already ISO13485 certified we, as a supplier, need to follow the same rules so that the solution is delivered and compliant with applicable requirements. We, as the Quality team, ensure that all process-related activities and requirements are addressed and specific products are being created at every stage of the project.
Are there any other norms from the medical sector we’re currently following?
Since medical devices can be safety-critical products, there’s a lot of risk management involved. This aspect must be covered from the very beginning of each project for both the automotive and the medical industry. For the latter sector, this is regulated with ISO 14971 standard, ‘Risk management for medical devices’. It’s a set of best industry practices that need to be followed throughout the project life cycle, so of course, we follow it.
There’s also IEC 62304 that specifies the framework for software development lifecycle in medical devices – from the initial requirements to the final verification of the product by the end-users. The lifecycle itself is similar to what we already know from other industries. Our experience in the automotive sector has been – once again – invaluable. We’ve been working with the A-SPICE and Functional Safety standards that are notoriously strict, so we already had processes and trusted methods in place. We can now use this foundation and adapt it when working on medical products. We didn’t have to start from scratch, we’ve been filling in the gaps as we’re moving along.
The most important thing when it comes to quality management is creating an environment where exceptional products and solutions can be created. The additional value for us that we get just from working with different international standards, is that we apply commonly recognised best engineering practices and as a result, we enhance our engineering skills.
Are we working on any internal processes and methods?
Each company is set in a slightly different context and environment, but I’d say that Spyrosoft follows a ‘learning organisation’ concept because we already have vast experience in working in various industries. One of the examples may be that we’re currently covering the risk management process for medical devices with already proven and verified methods.
We also have a team of specialists who have been working with A-SPICE and Functional Safety standards for years, so they’re not surprised when my team tells them about the healthcare sector requirements. What’s different is certain terms and specific requirements, so it’s a matter of adapting to a slightly different context.
Another big aspect in the medical industry are regulations and requirements for launching a product on the European or US market. So far, we’ve been handling these with support from external consultants, but we’re also planning to have such competencies internally just to keep track of frequently changing national regulations. This is very important for our consulting activities – we want to guide our clients from their very first requirements via the software development process that would be created in line with the standards, through to backing them as they introduce a new product on the market.