Innovation plays a pivotal role in the growth of civilization, moving us forward from the Dark Ages to where we are today. It empowers us to challenge the status quo and do things differently, with a better outcome. Thanks to innovation, what once seemed impossible becomes possible. In the realm of Medical Devices, Research and Development (further called R&D) tasks are mainly regarded as drivers of innovation.
When it comes to the Medical Device market, several other factors require consideration before the product can be successfully sold. Large companies typically possess a set of procedures and experienced personnel equipped to handle regulatory aspects of the process. If you work for such a company, you can skip this section. This article is intended for Medical Device startups with a groundbreaking idea but lacking expertise in the field.
Startup companies have a distinct atmosphere. Their primary goal is to develop a proof of concept for a solution that may be unknown at the beginning. Typically, that kind of startup stage constraints in terms of available resources, including manpower and finance. Given these limitations, there is a temptation to prioritize the development of a working solution and treat everything else as a secondary objective, with a focus on achieving the results.
However, this approach leads to the accumulation of “technological debt”, which can significantly impact the startup if not managed properly. Below are 5 examples of such debt that can arise in this context.
Lack of Quality Management System
Quality Management System (further called QMS), according to ISO 13485, is the opposite of innovation. From the core R&D perspective, it imposes “unnecessary” actions. Instead of concentrating on the design itself, one is required to fill out multiple documents that consume valuable time and focus, without adding any value to the project.
Before we proceed, it is important to grasp the concept of QMS. QMS serves as a framework that Medical Device Manufacturers must adhere to and operate within. It is considered not only as a good practice but also as a legal requirement in certain countries. QMS extends beyond the responsibilities of R&D (unless the R&D is the company). The key components of QMS are shown in Fig. 1.
From the QMS standpoint, understanding the new project development (“today”) and its intended direction (“tomorrow”) is essential. There are a lot of actions related to planning, execution, V&V (verification and validation), and document archiving, all of which define the scope of work required. It is not necessary for the plans to be flawless at the beginning, they can be adjusted as the knowledge about the product improves.
As an example: before writing the software, the essential step is to establish software requirements (simplifying). If the software is part of a bigger machine, then the software requirements should be derived from the overall product requirements. Product requirements should come from user needs, which the marketing team is responsible for providing. Each should be reviewed, approved, and released before commencing work on the next phase.
Additionally, it is crucial to identify applicable laws, standards, and guidance the project must comply with, as they will also influence the requirements. When executed correctly, this process creates a comprehensive history that will be well-received the technical auditor (who will likely review your technical documentation during submission).
Of course, QMS extends beyond what is mentioned here. It includes crucial aspects such as proper personnel training (to prevent inexperienced individuals from leading the development of a risk-critical module), traceability, design control, change management, and more. Each of these elements could serve as a separate topic for an in-depth blog article.
It is important for the core team to be well-informed about all the quality requirements and environments they will be working with. They must embrace them and work accordingly. Without even a basic version of QMS in place, how can the team deliver what is expected?
Risk Management and business decisions
Risk Management is a continuous process that should accompany Medical Devices from conception, through prototype and production to decommissioning. It is not a “one-time deal”, instead, it should be an ongoing effort throughout the project. When executed correctly, this approach enables the identification and mitigation of numerous risks. Fig. 2 shows the basic flow of the Risk Management process according to ISO 14971.
The Risk Management process should not be limited only to the core project team. Engaging more people to examine the device at hand leads the more scenarios being discussed, and more mitigations could be proposed. Having at least one clinical person (the one who is working within the targeted medical environment) is crucial to gain valuable perspective. While you may be an expert in a narrow technical field, it will not be you working with the Medical Device for 8 h/day. Their input is essential to provide a practical understanding of the device’s usage and performance in real-world scenarios.
First and foremost, it is important to establish risk acceptability criteria. The manufacturer can adopt multiple criteria. A commonly used approach is the Severity vs Occurrence table of 5×5 (for reference see ISO/TR 24971), for reference see Fig. 3.
Depending on the Risk Management Policy adopted, the Manufacturer may be obliged to minimize risk to the lowest reasonable level. In essence, all risks should be within the range of green cells shown in Fig. 3. Risks located in the “not acceptable” region (red cells in Fig. 3.) will necessitate the implementation of appropriate Risk Control Measures (further referred to as RCM).
This often involves introducing additional requirements at the product level, leading to the creation of additional safeguards such as additional hardware circuitry, software requirements, or mechanical parts to enhance the design safety.
Other standards, such as IEC 60601-1, also emphasize the importance of Risk Management. You will come across numerous sentences similar to: “If a failure of a component could result in an unacceptable risk, you need to do the following test”.
Understanding the relationship between risk and design is crucial. If a business decision is made, stating that “failure of the components is still treated as an acceptable risk” (regardless of available data), the project team might overlook the implementation of necessary RCM and omit key tests. In the worst-case scenario, the market users determine if this approach was correct (and hopefully they will not be affected by Severity 5 harms in the process). Possible consequences of such a decision need to be considered before implementing it.
Documentation of the project created at the end
There are certain behavior patterns that people within the Medical Device industry must follow. One of them is “what is not documented, does not exist”. In formal documents, you cannot refer to something that has not been officially released before.
Creating project documentation at the end of the project may lead to the following issues.
Something was missed and not implemented
After testing the prototypes and preparing the first production batch for shipment to the customer, the only remaining step is to pass certification/Notified body audit for selling in the European Union market. However, during the preparation of the documents, the team realized they missed a few small details, which when combined, made the design obsolete and ineligible for a Notified Body audit.
Correcting the situation requires time and effort, including manual re-soldering of the production batch or scrapping everything and ordering a new batch. Alternatively, there is a risk of proceeding with the defect. If such an issue is associated with a high severity, then the product should not be sold to the population.
Dates from the audit point of view may be suspicious
If, by any chance, the situation described above is not present, there is one more aspect that needs to be taken into account. Suppose the development of a complex software system took 2 years. In that case, you may face a challenging question from the auditor when they observe in your documents that the entire process from planning, through source code writing, ending with testing and finalizing the documentation, took you only 1 week. Such a discrepancy may raise serious concerns and require a well-documented explanation.
Always keep in mind that every project may have hidden non-compliances. Everything may seem perfect until it isn’t, and these issues are often discovered during audits or when the product is released on the market. It is essential to be proactive in ensuring compliance and avoiding unnecessary risks.
Dynamic changes to the project’s scope
Especially concerning when this issue is connected with point 3. mentioned earlier. The lack of proper documentation can result in a huge number of non-compliances and pathologies. Imagine a situation, where the marketing team is uncertain about the exact requirements, leading to frequent changes every week, causing confusion and back and forth with the same requirements.
The software team is modifying the source code accordingly, relying solely on verbal arrangements, without any documented minutes or notes. Information may get lost resulting in the omission of crucial requirements. As a consequence, multiple releases of the software may occur without clear instructions on what to test and release, leading to the risk of delivering wrong software with bugs or lacking the essential functionality.
Additionally, such frequent changes in the project scope will inevitably impact the project time plan. With constant updates to documentation, each change at the high-level stage triggers a review and an approval process, diverting focus from more important tasks.
Software testing
While it may be obvious, it is good practice for the team that develops the software not to be the same team responsible for writing test scenarios. This is particularly critical when there are risks that could lead to severe injury or death, with RCM managed through software requirements and higher Software Safety Classification (refer to IEC 62304 for more information about Medical Software Lifecycle Processes). The software development team often becomes deeply involved in source code, potentially leading to tunnel vision where they may not see the full picture.
As a result, they might not be the best candidates to propose criteria for pass/fail during software testing since they may overlook critical aspects. The test protocol is based on the same software requirements upon which the software is built. As long as the requirements are written properly (clear, unambiguous, testable), the test protocol should be indifferent to how the implementation is carried out. Some companies opt to write test protocols concurrently with software development, following the test-driven design approach.
On the other hand, tests typically occur towards the end of the development process. At this stage, there is often high optimism that everything will work flawlessly (as it hasn’t been tested yet). However, during the sting, it may become apparent that this is not the case. The software developer might have misunderstood the requirements.
There are two possible ways to address this issue:
- Modification to the software documentation may be required depending on the level of misunderstanding (like Architecture Design and Detail Design, see IEC 62304)). This process demands time and effort, and the tests will need to be repeated. You can imagine the considerable time investment necessary for this task.
- Another option is to modify software requirements and the software test protocols. This approach can quickly resolve the issue, especially since the software has already undergone testing. In some cases, teams may choose to leverage the results from the previous tests and simply complete the necessary paperwork.
Before the Manufacturer chooses scenario B, they must thoroughly evaluate the changes in the software requirements. They were established based on input from higher sources. The evaluation process should assess whether the proposed changes, as understood by the developer, will impact the product requirements.
Additionally, it’s essential to determine whether these modifications will conflict with any other standards, that the product must adhere to or introduce new, unacceptable risks. Failing to conduct a proper evaluation may contribute to the accumulation of “technical debt”.
Summary
Creating an innovative Medical Device is undoubtedly a challenging feat. Alongside technical expertise, a strong background in regulatory and quality aspects is crucial to navigating the potential pitfalls described in this article and more.
Every Medical Device needs to be treated individually. At Sii, we take pride in our team of experienced engineers ready to assist you with comprehensive services such as risk assessment, hardware and software development, creation of documentation, tests, certifications, and more. For any business need you may have, feel free to reach us out. We are here to support your success in bringing groundbreaking Medical Devices to the market.
***
If you are interested in the Medical Device area, check out this article: Introduction to Risk Management for embedded Medical Device software (IEC 62304:2006/AMD 1:2015).
Leave a comment