Software as a Medical Device (SaMD) is a booming tech segment expected to skyrocket in the near future. Experts expect the global SaMD market to grow from $596.3 million to over $7.36 billion between 2021 and 2027, an astonishing 38.4% compound annual growth rate.

Software developers understandably want in on the action—not only to profit, but to provide solutions that save lives and improve the quality of life for millions of healthcare consumers. But even software developers who have worked in regulated industries have not necessarily prepared themselves for the unique challenges of developing SaMD.

What Is SaMD?

The term Software as a Medical Device (SaMD) harkens back to the more popular and widely-known classification SaaS—”software as a service.” In the case of SaaS, as the name implies, the software is the service, not a means to an end to providing the service. It’s a form of consumer-facing Cloud services wherein the software is the product consumed by the end-buyer.

SaMD is a different kind of classification. It may be a Cloud service; it may not be. Again, however, the concept is aptly named. The software program is the medical device. The software performs a medical function, independent of the device it might be loaded on.

What’s the alternative? Software in a medical device (SiMD). After all, a computerized MRI machine requires software to move the magnet inside of it. But the software isn’t the medical device itself. The MRI machine as a whole is the medical device. It needs the software to work, but if you were to upload that magnet-controlling code onto an iPhone, the software would be useless.

Now consider an app that uses a device microphone to monitor a patient’s breathing during their sleep cycle. Theoretically, it doesn’t matter whether that app is operating on a PC, tablet, smartphone, or smart watch. As long as the device has a microphone, the device itself doesn’t matter—because the software itself is the medical device.

Here, Orthogonal lays out the specific criteria for what makes a device considered SaMD in greater detail.

Let’s look at five tips for software developers and entrepreneurs wading into the fascinating and potentially lucrative world of SaMD. 

1. Analyze Your Market

The SaMD industry may be primed for big growth, but that doesn’t mean you should neglect due diligence. As with any software solution, market research is critical before you write a line of code. 

Does your SaMD idea fulfill an unmet need in medicine? Does it assist with early diagnosis of a serious condition or help patients more easily manage a chronic condition? Does it ease a patient’s adherence to a treatment regimen? 

There must be a gap between the demand for your SaMD solution and the availability of other solutions on the market. If other solutions already exist, what can your SaMD do better?

Once you identify your solution’s potential niche, craft a short, punchy, one-sentence statement of the value your solution offers. Survey potential users to see if they resonate with the message or if it needs work. Potential user feedback could even help you identify market gaps you never knew existed.

2. Understand the FDA Regulations

Some software developers have experience crafting software for regulated industries, but that doesn’t mean they are ready for the US Food and Drug Administration. 

The FDA is one of the most stringent governing bodies in the world, and for good reason—public health and safety is decidedly on the line with every new drug, medical device, or food product that comes on the market. People put their lives in the hands of the drugs and medical devices they consume. 

As such, anyone who wants to get into SaMD needs to understand what it takes to get a medical device—even software as a medical device—approved to market by the FDA.

The regulatory standard applicable to medical devices is ISO 13485. Steps in the compliance validation to prepare for include: 

• Analytical validation, including “objective evidence” of sound development processes for any SaMD.

• Clinical validation, including evidence of a “clinically meaningful,” measurable increase in positive outcomes for users of your SaMD solution in clinical trials.

3. Understand Device Classification

Entering the realm of medical devices means that you need to pay attention to medical device classification. Understanding the classification of your device will make a big difference in obtaining FDA approval for your SaMD solution.

A medical device classification is an assessment of its risk to the patient. Here’s the breakdown:

• Class I Medical Device. These are the lowest-risk medical devices. They include simple devices like tongue depressors, wheelchairs, and bandages.

• Class II Medical Device. These moderate-risk devices might be minimally-to-moderately invasive and present some risk in their use with patients. Examples include syringe needles, catheters, and contact lenses.

• Class III Medical Device. These high-risk devices might be maximally invasive and present serious health and safety risks if they malfunction. Examples include pacemakers and coronary stents.

4. Document your Process at Every Turn

Scrupulous documentation is a good practice to implement for any software development, but it becomes especially critical when we’re talking about a SaMD solution that must undergo clinical trials and pass muster with the FDA. 

The goal is to set up systems of documentation and accountability within the development process so that every stage of the development process is documented. This documentation will be critical in meeting the quality assurance standards needed to both validate compliance and achieve public trust in your solution. 

5. Schedule Review Sessions

Compliant SaMD development must be monitored at regular intervals. The last thing you want is to make it to the end of a grueling development process, only to discover that an early mistake has ballooned into a roadblock to FDA approval. 

ISO 13485 stipulates reviews at set intervals with documentation of the findings of those review sessions. Schedule these sessions, formalize them, and assign a member of the development team as the point person in charge of those review sessions. 

Conclusion

SaMD is a software niche that can be both lucrative and beneficial for enterprising software developers. With medical responsibility comes extra challenges to overcome and hurdles to clear, but in a booming industry with such grand potential for the public good, developers should not shy away from that calling.