SiMD/SaMD: Everything you need to know

The pervasiveness of technology is evident at a glance inside any modern healthcare facility. From prognosis or diagnosis to patient monitoring and administering treatment, a wide range of software-enabled devices allows medical professionals to fulfil their respective duties timely and precisely. So, the software in a medical device (SiMD) is as critical a component as the healthcare equipment itself. Software solutions that do not reside in a medical device but are used for medical purposes are called software as a medical device (SaMD). Not surprisingly, both these marvels of technology fall under the stringent regulatory guidelines that apply to medical equipment.

Both SiMD and SaMD are subject to the medical device regulations of the country where they are used. For instance, the Food and Drug Administration (FDA) in the USA, the European Commission in Europe, and Health Science Authority (HSA) in Singapore. Nearly every country has a regulatory standard for SaMD but regulations differ according to the country’s internal circumstances and approach towards healthcare. This is why SaMD providers must adhere to the IEC 62304:2006, which is an international regulatory standard and is acceptable in many countries.

IEC 62304 applies to all life cycle processes. All SiMD developers must comply with it. IEC 62304 guidelines classify SiMD in three categories based on safety: A, B, and C:

Class-A SiMD covers that which is not hazardous to patients. Even if it does cause a hazard, the situation does not lead to unacceptable risk if the relevant risk control measures are taken, external to the software. The various COVID-19 diagnosis kits that mushroomed since the pandemic are apt examples of class-A SiMD. Even if the software that analyzed the samples malfunctioned and yielded inaccurate results, it didn’t cause any direct harm to users. It only delayed users’ attention to medication that they would have resorted to had the results been accurate.

Class-B SiMD can be hazardous in a way that causes unacceptable risk even after taking relevant risk control measures external to the software, but, the possible harm resulting from it is not a severe injury. For example, excessive exposure to X-rays is harmful to humans. However, if the software used to administer an X-ray malfunctions and emits more X-rays than intended, the harm to the patient will not lead to an immediate and severe injury.

Class-C SiMD is the most critical. It includes applications that are hazardous and lead to unacceptable risk even after all relevant risk control measures external to the software are taken. It differs from class-B in that the resulting possible harm can cause a severe injury or death. The software used to conduct MRI scans is an example of class-C SiMD. Unlike with X-rays, patients may sustain severe injury or even die if the MRI radiation exceeds the permissible level of emission due to a software glitch.

                                                                                                      Figure 1: SiMD classification flowchart

Likewise, SaMD is classified into four categories based on the state of the healthcare situation and the significance of the information that SaMD provides for healthcare decision-making. The International Medical Device Regulators Forum (IMDRF), which is an international regulatory body, classifies SaMD as I, II, III, and IV with further qualification of ‘a’ and ‘b’, as follows:

                                                                                                           Figure 2: SaMD classes

IEC 62304 and IMDRF do not interfere with the software development lifecycle. So, the development process remains the same with the following stages:

                                                                          Figure 3: Risk management layer cutting across SDLC stages

There is only one additional layer that cuts across all the stages of the SDLC, which is mandatory in the case of SaMD and SiMD development. That layer is software risk management. IEC 62304 emphasizes software risk management strongly and software companies must comply with, document, and show evidence of it. This brings us to software documentation, where it is mandatory to document certain elements based on the classification of SiMD/SaMD and the device. The necessary elements for each class are:

                                                                     Figure 4: Documentation requirement based on software classification

Complying with every aspect of IMDRF and IEC 62304 pertaining to the development and release of SiMD/SaMD can be an uphill endeavor. Companies often pick off-the-shelf software, customize it, and intend to roll it out packaged with the medical equipment that they are launching. But with this approach, they risk facing regulatory hurdles for non-compliance, which can delay the launch of the product.

Here, L&T Technology Services (LTTS), with our years of experience and proven capabilities in providing engineering services, offers specialist intervention and support. Several Fortune 500 enterprises already trust and rely upon LTTS for this purpose. We cater to the full spectrum of requirements, starting from classification reassessment to determining the category to which the concerned SiMD/SaMD belongs. Whether it is development from scratch or simply ensuring compliance with applicable standards, our solutions cover it all.

Stay on the right side of compliance and shorten your medical equipment launch TAT. Find out how and what we can do for you.