Famous railroad executive Alfred Perlman once wrote, “After you’ve done a thing the same way for two years, look it over carefully. After five years, look at it with suspicion.  And after ten years, throw it away and start all over.” Though perhaps uttered in hyperbole, Perlman’s words speak directly to the heart of evolution in any industry. Change is always happening, and those organizations that evolve alongside their industry will never miss a beat. 

This generalization is especially suitable for software as a medical device (SaMD, a term generally used outside the EU) and medical device software (MDSW, a European Union term), an industry that is still finding its footing at the cutting edge of MedTech development. As these MedTech specializations evolve, their regulatory guidelines shape and reshape themselves in response to the very latest innovations. 

So, what defines successful SaMD/MDSW development? It actually takes three definitions — three definitions individually established during the three simple steps of MedTech software development. 

1. Defining Your Product

SaMD/MDSW is considered “uncharted territory” in the MedTech industry, and its precise definition is still taking shape. Most of the specialization’s worldwide standards are set forth by the International Medical Device Regulators Forum (IMDRF), a global working group established in 2011. Formed only 12 years ago, the IMDRF did not make its first official recommendations until two years later with updates on machine learning and in vitro diagnostics as recent as 2021 and 2022. In the European Union, the Medical Device Coordination Group (MDCG) sets the standards for MedTech development by providing advice and guidance. 

Such an evolving landscape — with an essential definition still in flux — would be challenging for any specialization, but SaMD/MDSW attracts many software developers from outside the clinical research industry. This makes the absence of more tested and established guidelines potentially problematic given that some of the most promising innovations will involve organizations with little experience in achieving regulatory compliance and shepherding products to market

As such, the first question any organization needs to ask when considering software development is, “Where does my product fall on the software spectrum?” SaMD/MDSW is most closely related to software in a medical device (SiMD), but it also shares some similarities with software that serves as a medical accessory and general-purpose software operating in a medical capacity. Determining your product’s place on the software spectrum is the very first step to success, and what you discover has big implications on risk classification and data collection. 

For more detailed guidance on defining your product, consult our white paper on successful market access for SaMD and MDSW. 

2. Defining Your Risk

Identifying the risk classification of your SaMD/MDSW is a much more nuanced consideration than simply defining its role as a medical product. Many regulatory bodies take a “waterfall” approach to the process with a series of progressive questions resulting in a final determination. Given each risk associated with SaMD/MDSW must be decided on — and given the discrepancies between the United States and the European Union — these determinations can be tricky even for those with extensive clinical research experience

So, in a broader sense, how can risk classification be pre-determined for SaMD and MDSW? It all hinges on two questions: 

  1. How significant is the information provided by the medical device to the healthcare decision? 
  2. What is the status of the healthcare situation or condition itself? 

These two metrics come together to determine the exact data requirements of your SaMD/MDSW prior to regulatory approval. For the FDA, these classifications proceed from class I to class IV, while EU regulation uses two separate classification nomenclatures for CE marking — one for medical devices and the other for in vitro diagnostics. Under Medical Device Regulation (MDR), EU classifications progress from class I to class III, while In Vitro Diagnostic Regulation (IVDR) proceeds from class A to class D. 

state of healthcare situation or condition significance of information provided by samd or mdsw to healthcare decision treat or diagnose drive clinical management inform clinical management critical iv class 3 class c or d 3 class 2b class b 2 class 1 or class 2a class a serious 3 class 2b class b 2 class 1 or 2a class a 1 class 1 or 2a class a non-serious 2 class 1 or 2a class a 1 class 1 or 2a class a 1 class 1 or 2a class a

These systems share many similarities, but not enough for any organization to get by on blanket considerations. With options for self-certification and sizable differences in pre-market and post-market requirements, it is essential for an organization to understand the country-to-country data demands of SaMD development. 

3. Defining Its Data

Much like everything else in SaMD/MDSW development, the precise data needs associated with each classification is still being processed by much of the industry. Even with a well-defined product and an accurate understanding of the associated risks, it can be difficult for organizations without direct experience to capture the right data at the right time. This industry-wide uncertainty is reflected in governmental programs hoping to support more iterative development, such as the FDA’s Digital Health Software Pre-Certification Pilot Program. Though still struggling to find success, these programs display a willingness and understanding from regulatory bodies in accommodating the unique evolution of software development.  

So, how can an organization gain more certainty? An organization’s standards for clinical evaluation often form the foundation for its SaMD/MDSW development. Thanks to the combined efforts of the IMDRF and MDCG, clinical evaluations around the world are designed to weigh the risks and benefits of your SaMD/MDSW as part of a universal 3-stage process: 

1. VALID CLINICAL ASSOCIATION
Is there a valid link between the software’s output and the clinical condition? 

2. ANALYTICAL VALIDATION
Is the software’s output data accurate, reliable, and precise? 

3. CLINICAL VALIDATION
Is the software’s intended purpose achieved in the context of clinical care? 

Organizations with a robust clinical evaluation process — one that considers the evolving needs of SaMD/MDSW — can navigate the industry with greater confidence. Their development is naturally iterative, and their guidance comes from leading experts in the highly specialized field of medical software. 

A Look Into the Future

Artificial intelligence (AI) and machine learning (ML) are bringing even bigger changes to the SaMD/MDSW landscape. These cutting-edge diagnostic tools have already impressed much of the MedTech industry with what is possible. Still, their unique position as such fast-moving, highly iterative technologies means they can’t succeed without novel strategies, such as the ability to iterate on locked versions of each use of AI or ML. These sorts of progressive strategies can prevent a host of complications prior to market access, but they are only available to those organizations that stay one step ahead of innovation.  

Your MedTech software needs to navigate a market that is still evolving. The Avania team is supported by innovative experts with direct experience and documented success in SaMD/MDSW development. When you need to move your product forward, It Takes Avania

Back to Blog

Your product is important, and your trial deserves the team that has what it takes. It takes knowledge. It takes passion. It takes commitment. It Takes Avania.

Let’s Talk