Mastering ISO 13485 certification as an agile medtech start-up
Are you a tech company developing software for the medical field? Awesome! You have most likely set up a great technical architecture and used open-source tools to help you along the way. The product is working perfectly and now the last part missing is the medical CE marking (for the European Union). Accustomed to the extent of available documentation on product development, you realize the lack of guides or tutorials on such certification processes. Lucky, you just found this article!
We want to share our experience with fellow medtech start-ups to avert certain pitfalls in order to focus on the development of medical device software. In this article we will go through one of the most crucial aspects of getting a medical product certified: the quality management system (QMS) according to ISO 13485.
Importantly, a QMS affects the whole company and is not product specific. It forms the basis for getting your product through the CE marking process.
Short background
Biome Diagnostics GmbH is an Austrian medtech start-up utilizing the genetic information of the microbiome and AI to develop medical diagnostic software for doctors. Our products utilize technologies such as next-generation sequencing, pipeline architectures and microservices. With our lifestyle product myBioma we give every European the possibility to learn more about one’s gut microbiome and improve lifestyle and diet. Furthermore, the product enables us to optimize our technical development flow. Since 2020, we are worldwide the very first company in the microbiome field that is certified according to ISO 13485 and ISO 9001.
As a European company this article focuses mainly on the legislation of the European Union but many aspects are ISO related and are applicable all around the globe.
What is a QMS and why do you need it?
As a passionate and tech-driven company we loved the idea of building a software that positively impacts patients’ lives, however, we were unaware of the regulatory horrors to come. During our first exchanges with other medtech start-ups the phrases “QMS” and “ISO 13485” were often used without us fully grasping the importance of such a system. Clearly quality is always of the highest priority for a start-up — what else could there be to understand?
Maybe you have heard of this famous story:
In the year 1982, some great scientists and hard working programmers invented the Therac-25, a computer-controlled radiation therapy machine. Its job: to treat cancer by using a high-energy electron beam destroying malignant cells. After years of work and previous units such as Therac-6 and Therac-20 the scientists were confident this would be an international breakthrough. Jump forward to the year 1985, the first cases came to light where patients reported massive overdoses of radiation. As a consequence, patients died. As it turned out some patients got radiation doses that were 100x greater than standard limits.
But why? Race conditions occurred as the machine had to measure and radiate at the same time. This type of multitasking had not been programmed and tested extensively. These accidents highlighted the dangers of software control of safety-critical systems in healthcare settings. Additionally, the lack of proper resolution of reported software bugs are highlighted as an extreme case where the engineers’ overconfidence in their initial work and failure to believe the end users’ claims caused drastic repercussions.
What followed were numerous acts and directives that required medical device manufacturers to have a QMS in place. Even though nowadays many of the mistakes of Therac-25 seem impossible, the risks are no less imminent especially since software becomes more complex and constantly interacts with new technical environments. A QMS is used to mitigate these risks by setting some ground rules, and it is the reason why an existing QMS is required by many regulatory authorities, e.g. EU, Great Britain, Canada, partially USA, etc..
The European directive states that all manufacturers should have a quality management system as well as a post-market surveillance system in place which should be proportionate to the risk class and the type of the device in question.
— §32 Medical Device Regulation
A QMS is at its base a simple collection of many different types of documents fulfilling requirements by an international standard such as ISO 13485 (manufacturing of medical products) — but it can be so much more. As an agile start-up you can and should integrate the QMS into your sprint and project management. Only then, a dead or zombie QMS that is never touched can be avoided (see below).
From a founder’s perspective, setting up a QMS might feel overwhelming at first, but in the end it can help you scale and advance your company. It forces you to think about setting up the right structures and rules to ensure high quality standards throughout the whole company. Moreover, it makes you start documenting each process which enables transparency and efficiency.
Specifically, in the beginning of a development process for medical software one might not think about documentation and integrated standards. How do you review code? How do you plan integration tests? Who has which responsibilities? How is a new feature validated? Where is the validation documented? What risks are associated with the product and how high is the probability of occurrence? How do you version your machine learning model so it’s compliant? How do you handle unique device identification in a microservice environment?
And this is just scratching the surface … let’s dive into it!
1. Identify your medical product and its intended purpose
Before setting up all necessary documents for the certification you should identify your medical product. A medical device can be hardware, software or both and vary depending on the jurisdictions of different countries.
Start off writing a short description focusing on what the device is intended to be used for. This can be two to three sentences long. Additionally, you can add patient (contra-)indications and medical conditions to be diagnosed, treated or monitored.
Based on these statements you should be able to go through Article 2 Definitions of Medical Device Regulation (MDR) / In Vitro Diagnostic Regulation (IVDR) and in theory verify if your software is a medical device. Generally, if the software intends to be used for medically related purposes it most likely is a medical device. Next, try to figure out whether your device falls under the legislation of MDR (e.g. catheters, implants) or IVDR (e.g. monitoring devices such as heart rate monitors) based on the definitions.
This is important as the risk classes and other clinical specifics differ. There are three to four different types of classes depending on the expected impact to patient’s health. The more risks are involved the higher the device class:
Class I (MDR) / A (IVDR) — low risk
Class IIa + IIb / B + C — medium risk
Class III / D — high risk
Check the Classification Rules in Annex VIII of MDR / IVDR and try to identify your software’s risk class based on the given ruleset.
2. Get in touch with a notified body
A notified body is simply an independent external company that has been authorized and trusted by the European Commission to audit your work. They will come to your office to check your processes and documentation as well as to verify your production steps. If everything works fine and there are no major deviations you will receive a successful audit report and the ISO certificates.
We would encourage you to get in touch with a notified body very early. Usually, they are helpful and can already assist in identifying your product’s risk class. Additionally, such companies are mostly overbooked and need at least a six months notice prior to an audit.
Example for notified bodies in the German speaking area are TÜV Süd and medical device certification GmbH.
3. Read the standards
Just like reading this article, an amazing cure of insomnia is included when buying the necessary standards. But let’s get serious, every ISO is just a standard that sets some ground rules and requirements for your QMS. ISO 13485 is the only standard you need for medical CE marking. However, depending on your product and business you will most likely also need to cover ISO 14971 for risk management, ISO 27001 for information security and IEC 62304 for software development.
Johner Institute has great blog articles and they also offer consulting. Importantly for software start-ups, they have an open-access repository with guidelines for AI products and IT security.
If you still have not been cured of insomnia, I can only recommend you to read the MDR or applicable IVDR . This should do the trick!
4. Decide on and set up an eQMS
As an agile company we realized we didn’t want to have a zombie QMS that brings more overhead to the company than it actually eases processes by having them defined. We didn’t want to have a documentation in place that is setup once and only adapted in some night sessions shortly before the audit. This is why we decided to use an electronic quality management system (eQMS) to integrate in our sprint management.
There are mainly two options for eQMS on the market:
- The first one covers systems that offer the complete eQMS solution as a golden cage. All tools and functionalities work fluently within the system’s environment but at the expense of a higher price.
- The second option includes more a do-it-yourself (DIY) approach using existing content creation systems and populating them with your own SOPs, templates, etc.
Both options are totally valid, however, none fitted our requirements perfectly. Specifically, we were mostly confronted with the following problems:
- lack of integrations
- terrible usability (Win95 style)
- too complex usage
- lack of exportability
Finally, there is a third hybrid option that combines the best of both worlds: quality-related tools working together efficiently as well as leaving enough room for customizations, integrations and endless export possibilities. Specifically, we evaluated Atlassian and Microsoft DIY environments as potential candidates for our eQMS.
We chose Atlassian’s Jira and Confluence as we were using them beforehand already. The advantage of the system is that we can use it for quality-related purposes and also for handling all other processes and documentation within the company, which helped creating an eQMS that is operated on a daily basis. Moreover, such an integrated eQMS reduces the number of tools adopted by the team, making it easier to get everyone familiar with its usage.
Jira covers the sprint management containing medical user needs (=epics) and software requirements (=tasks). It is widely used in agile software development and can excellently be integrated with popular version control systems such as Bitbucket, GitHub and GitLab where code development and versioning are depicted. With the help of external plugins you are able to even build a risk matrix in Jira mitigating risks by linking them to Jira issues.
Confluence acts as the document management system where all your standard operating procedures (SOPs) and templates are defined. With the help of companies like SoftComply, which offer quality-related Atlassian plugins, you are able to build a compliant system that includes approval workflows. The advantage is that you can write your technical documentation in Confluence and easily include requirements from Jira into Confluence pages. The linked pages are then also shown within the Jira issues.
Documentation structure
Basically, the QMS is a set of documents with a specific hierarchy. The most important sheet is the quality policy which is a brief statement that aligns with your organization’s purpose and strategic direction, provides a framework for quality objectives and includes a commitment to meet applicable requirements (e.g. ISO 13485, ISO 9001, customer or regulatory).
The quality manual is the main document that describes the QMS for your team as well as external people. The manual should give an overview of your system and is a great guide for the auditor — hence it has to be clearly structured. The chapters should orientate according to the ones of the standard it is based on. The manual should not contain any company sensitive information.
Finally, all processes such as software development, packaging, manufacturing and management reviews are described in SOPs. These documents contain information about the responsible person, the scope of the work, the procedure itself and any other relevant information. As the SOP is only for internal purposes it can include sensitive information. Templates are used to record certain events, such as trainings, change requests or non-conformities.
All documents are versioned, approved by the quality manager and published within the Atlassian ecosystem and can be exported to PDF anytime.
5. Rock the audit(s)
Do you have all your documents prepared? Great — the auditor will most likely want to see them beforehand. Either you grant him access to your eQMS or upload all your PDF documents to the cloud of the notified body.
Two successful audits are necessary to be ISO certified. In stage 1 the auditor reviews all documented information, evaluates your site-specific conditions, interviews personnel and determines if the company is ready to move on to stage 2. The stage 1 audit mostly takes one day onsite.
In stage 2 the implementation and effectiveness of your company’s QMS is evaluated. Specifically, the ability to carry out processes as defined will be tested. Also the correctness of internal audits and management reviews will be verified. If any requirements are not fulfilled they may be reported as non-conformities that will need to be corrected before the certification can be issued. The duration of the second audit depends on the company size and takes roughly 2–3 days in smaller teams.
If the audit goes well and there are no major deviations you will receive a successful audit report and the ISO certificates.
Are you ISO certified yet? Now, your medical product development can get off a good start and you can prepare the CE marking of your product. Define the user needs of patients or doctors, identify potential risks associated with the product and start writing your code and technical documentation. Oh yeah, and don’t forget to clinically evaluate your product with a performance study, if necessary.
Even though it is tempting, don’t start building the product yet without thinking about regulatory requirements and the certification process ahead. Stay up-to-date for more to come!
If you like the article make sure to recommend, share or comment. Follow us on LinkedIn or signup for our newsletter.
