The use of Software as a medical device (SaMD) is on the rise, and it’s plain to see why. From screening and diagnosing illness, to managing critical conditions, SaMD products are improving patient outcomes across the board.
So it’s not surprising that the SaMD market is poised to grow by 38.39% over the next 5 years — clinicians are clamoring for these products. But before embarking on a SaMD project, there are 4 factors you should consider. The purpose of this post is to take you through each of these factors, so you’re well positioned to bring SaMD products to market.
Meet the right standards
First, and perhaps most importantly, every business needs to understand the regulatory landscape. SaMD products are considered medical devices in the eyes of regulators. In the US, they are subject to 21 CFR, the Food and Drug Administration’s Quality System Regulation (QSR) for medical devices. Outside the US, products need to be compliant with ISO 13485:2016, the international Quality Management System (QMS) for medical devices. As you set about designing and building your SaMD products, your software developers should be mindful of these regulations.
Define your purpose
Secondly, you need to have a clear idea about what you’re trying to achieve — medical device development can be a complex undertaking. It’s vital to define the purpose of your product with a succinct statement at the start of a project. Even small changes to an intended purpose can have a big impact on how the product goes through the certification process. In a worse-case scenario, your team may need to go through the whole process again.
So, what exactly constitutes an intended purpose? As specified by the EU Medical Device Regulation (MDR), an ‘intended purpose’ means, “The use for which a device is intended according to the data supplied by the manufacturer on the label, in the instructions for use or in promotional or sales materials or statements and as specified by the manufacturer in the clinical evaluation.”
Putting in place an intended purpose document can help clarify your goal. Plus, it can act as a blueprint for defining your design control and product development.
If your product is to have a long shelf life, it has to be completely safe. There’s no place for risk in the development of devices — clinicians and patients need to be sure that the products they are using have been rigorously tested. ISO 1497 provides a framework to help medical device manufacturers manage risks. Familiarizing yourself with this standard will help you to identify hazards and take corrective action. But ideally, risk management should inform every part of your device product development lifecycle from start to finish.
Plan for product changes
Finally, you should factor in the possibility that you may need to modify your product in the future. For example, you might discover that your product has some software defects that need to be fixed. Or you may want to improve aspects of your product after getting customer feedback.
To avoid re-certifying products, you should determine whether an upgrade will involve a non-significant or a significant change. With a significant change — which might involve a whole new product release — you will probably have to repeat the clinical evaluation process. But with a non-significant change, you should be able to avoid this.
Managing SaMD upgrades is something our HealthTech technology consulting team has a huge amount of experience in. Whether you’re just embarking on a SaMD project, or want to release a new version of an existing product, Star technology consulting can help. With the support of our multidisciplinary team of strategists, engineers and designers, you can craft well-designed SaMD products and get them to market fast.
Have you read?
Uplift at NEARCON 2022 – Taking Web3 To the Next Level by Irina Berezina.
The Only Happy Investor in the Room by Michael Peres (Mikey Peres).
Run a Medical Business? Patient Experience Should Be Your Highest Priority by Dr. Khuong Nguyen.
The Importance of Being a Wise and Mindful Leader by Dr. Ronald Alexander.