Why Your Software as a Medical Device (SaMD) Development Should Take a Quality by Design Approach 

by Marco Franzoni, MD Compliance Specialist @PQE Group

Although the use of software in healthcare has existed since the ‘90s to assist medical practitioners in key areas such as diagnostics and patient monitoring, it wasn’t until the 2010s that Software as a Medical Device (SaMD) became a standardized industry term, formalized by the International Medical Device Regulators Forum (IMDRF), with development expectations established through international standards and regulatory guidance. 

Despite the proximity and common terminology, Software as a Medical Device (SaMD) should not be confused with Software in a Medical Device (SiMD). Unlike SiMD, which is embedded in traditional medical devices and controls the hardware’s functionality, SaMD performs its medical purpose without being part of or controlling a hardware medical device. It may still run on general-purpose platforms (e.g., smartphones, servers) and process data coming from medical equipment. 

BANNER-Why Your Software as a Medical Device (SaMD) Development Should Take a Quality by Design Approach _1_1_1

Software as a Medical Device (SaMD) should therefore not be confused with well-being apps or similar software, as its development must follow strict regulatory guidelines and adhere to quality standards to keep patients safe and contribute to their well-being. Due to its unique role in today’s medical technology field and its growing importance in life-critical contexts, SaMD development should begin with quality and patient safety in mind, not only to avoid costly and time-consuming redesigns and regulatory delays, but also to prevent potential harm to patients’ health and overall well-being.  

Although good code is key to a well-functioning final product, having good code alone does not translate to regulatory compliance, as SaMD developers, on top of the features we have already highlighted, should also ensure traceability and build their products from a risk-based, lifecycle-driven approach.. From a business perspective, the most effective and rapid way to bring a SaMD product to market is to integrate quality and regulatory considerations from the very beginning, ensuring compliance is built in rather than addressed later. 

 

Why Design Control Should Be a Part of Your SaMD Development Process 

Developing software for use in the life sciences as SaMD is more than just writing code. The process, which must follow a structured, risk-based lifecycle approach (per IEC 62304, ISO 13485, and ISO 14971), must also be complemented by usability engineering (IEC 62366-1) and product-level health software requirements (IEC 82304-1). Like everything else in the life sciences industry, any software development project should start with planning and defining the scope of the software and the medical needs it will meet. 

At this early phase, your team should already have an idea of the SaMD regulatory requirements your SaMD product must adhere to and must factor in these regulations at each stage of development to ensure patient safety, usability, and security. To avoid common regulatory pitfalls in SaMD, life sciences companies that are involved in the development of such software should prioritize familiarizing themselves with design and development controls, as they are a core requirement in both the US and the EU. 

As the backbone of SaMD development, design control adds the much-needed transparency to the life sciences by clearly mapping out the purpose of the software, how it is built, and its effectiveness in meeting its medical purpose. Design inputs and outputs must be documented with full traceability, and verification must demonstrate that outputs meet inputs; these activities are executed according to a planned, risk-based verification and validation strategy rather than ad hoc checks at each stage. 

 In addition to this structured approach, reviews and checks, which are also key elements of design control, are necessary to identify potential issues early and allow development teams to implement system improvements that help ensure the entire system performs as intended in the real environment where it will be used.  

 

Quality by Design and Risk Management in SaMD Security 

With lives at stake, there is no room for error when it comes to SaMD development, and this means that from the word go, quality, safety, and compliance should be the cornerstones of each software project rather than treated as mere checkpoints after the project is complete.  

Taking a risk-based and Quality by Design mindset is the best way life sciences companies can anticipate potential risks, user challenges, and SaMD regulatory requirements earlier on before the first line of code is even written. With this approach, SaMD developers have the chance of making informed decisions as they are able to collect key input from experts in relevant fields such as engineering, cybersecurity, and healthcare, which they can use to ensure risk management, usability, and security are built in, and not bolted on.  

Risk management, which is often thought of as a standalone approach, is one of the most important elements of this lifecycle framework. It requires developers to identify hazards, estimate and evaluate risks, implement control measures, and verify their effectiveness. Proactive risk management reduces the likelihood of adverse events and system failures that could compromise patient safety.  

Regulatory approval or clearance is not the end of the process.Once software is on the market, you, as a manufacturer, must continue monitoring the software's performance and its impact on patients while collecting feedback, implementing fixes and patches where necessary, and reporting them to regulators as required by law. This is formalized through Post-Market Surveillance and complaint-handling obligations, as well as vigilance reporting under MDR and US FDA medical device regulations. 

As a SaMD developer in the US or EU, which are two of the biggest life sciences markets, in addition to implementing software updates to address concerns and security risks, you are also required to communicate clearly and effectively using an evidence-based approach to inform the user how to use the software correctly as intended by you, the manufacturer. . This includes maintaining Instructions for Use (IFU) and product-level documentation 

There is no secret formula or shortcut to building a successful SaMD product. Behind every successful SaMD project is a solid plan that takes into consideration the purpose of the software, the regulatory requirements, and usability of the product from the beginning. Taking a risk-based lifecycle approach is a guaranteed way of ensuring your software meets regulatory requirements at each stage of development rather than waiting for the software development to be complete to find compliance gaps. Nowhere is the statement "prevention is better than cure" truer than in SaMD development. Avoiding shortcuts and prioritizing regulatory compliance just as you would for any pharmaceutical product is the foundation for building successful and compliant software products that make patients' lives better.  

 

More on the Regulatory scope for Medical Devices?

One of PQE Group's unique features, is its global presence, with a dedicated local touch. We'll support you at 'home', providing your business with a rich experience from all over the world.  

Learn more about our compliance support for Medical Device 

 

Contact us