The market for software as a medical device (SaMD) is growing rapidly as more companies see the possibilities inherent in leveraging their software development expertise for the good of patients around the world.
And right now, regulatory agencies like the Food and Drug Administration (FDA) in the US are working to update their regulations and guidelines to stay relevant with the pace of growth. They recognize that the use of SaMD will only continue to increase as available technology becomes more sophisticated.
The FDA defines SaMD as “software intended to be used for one or more medical purposes without being part of a hardware medical device.” That last phrase—without being part of a hardware medical device—is key to understanding the growth of SaMD and the way regulators like the FDA are adapting to it.
Many companies with expertise in software development, but not in medical device manufacturing, have begun to enter the medical device space. So, if you’re trying to figure out how the FDA views your SaMD and the applicable requirements your company will need to follow for compliance, then you’re not alone. Here’s what you need to know:
When it comes to the regulatory landscape, the most important thing to understand about SaMD is that it is considered a medical device in the eyes of regulators. Software developers often don’t think of themselves as medical device “manufacturers,” but from the perspective of the FDA and other regulatory bodies, that’s exactly what they are.
And that means the 21 CFR Part 820 quality system regulation (QSR) for medical devices still very much applies. It’s essential that you document and control your design and development activities into release and post market according to the applicable requirements from 21 CFR Part 820.
And if you have any intention of marketing your product outside of the US, your quality system should also be compliant with ISO 13485:2016, the international QMS standard for medical devices. However, while SaMD is covered under the same regulations for traditional medical devices, there are also standards and guidance documents specific to SaMD.
For instance, the IEC 62304 standard for medical device software has been widely adopted by regulators around the world. IEC 62304 defines the framework for processes throughout the lifecycle of the software, including planning, development, and postmarket surveillance. The FDA recognizes this standard and it is expected that SaMD marketed in the US will soon be required to meet these requirements.
However, there are also FDA requirements that correspond with IEC 62304, such as those for premarket submissions (which we’ll discuss in the next section). As a general rule, you’ll be best served by working toward satisfying all applicable IEC 62304 requirements first, and then following any remaining FDA requirements.
On top of all that, the International Medical Device Regulators Forum (IMDRF) has also issued guidance on SaMD. Now, keep in mind that the FDA is a key member of this group, even chairing the SaMD Working Group (WG) that IMDRF established to develop guiding principles for global regulators.
So, even though the IMDRF guidance is not prescriptive and is intended only to offer considerations for the industry and the FDA staff, it would still behoove you to familiarize yourself with these documents.
Though a pre-submission for your SaMD is not strictly required, it is highly recommended.
That’s because a pre-submission gets you in front of the FDA relatively early in the development cycle, providing an opportunity to start a dialogue with regulators about the SaMD you want to bring to market.
The benefits of this type of submission can be enormous. For one thing, this is a chance to receive formal feedback from the FDA and get their stance on various issues in writing. This will eliminate a lot of guesswork moving forward, as you can refer back to their feedback when making decisions about your product.
A pre-submission also familiarizes the FDA with your SaMD. If you skip it, the first time anyone at the FDA will have heard of your company or your device is when you file your premarket submission request.
That’s not the optimal way to get your SaMD submission request accepted. It’s far better for the FDA reviewers to understand your device, its intended use, and any risks inherent in it before your submission comes across their desk.
The FDA has issued guidance on what should be included in a premarket submission for SaMD. However, while the guidance is fairly straightforward, there is plenty of nuance to what the FDA is looking for in a premarket submission.
For a deeper dive into what should be included with your submission, read our blog post on the 7 Documentation Musts for All Software Device Presubmissions.
Risk management serves an integral role throughout the lifecycle of a medical device. Estimating, evaluating, and controlling risk is paramount to bringing the safest SaMD possible to market and keeping it there for the long-term.
Unfortunately, some SaMD companies neglect to conduct risk analysis because they don’t consider it applicable to their device. I can’t stress enough how important it is for SaMD companies to follow the same risk management best practices that apply to traditional medical device manufacturers—and understand the standards and regulations that govern the industry.
ISO 14971:2019 is the global standard for medical device risk management, offering thorough explanations and guidance into industry terms, concepts, and processes. It’s also the risk standard endorsed by the FDA, which uses a risk-based approach when reviewing device submissions and conducting inspections.
The sooner you can establish a formal risk management system, the better. And remember, this isn’t a one-time activity. Risk management should be an ongoing process that is built into every stage of your SaMD lifecycle.
Given everything we’ve just covered, the prospect of meeting the FDA’s requirements for SaMD may seem a little daunting.
At Greenlight Guru, we understand the unique dynamics of software development in the medical device industry. Our QMS acts as a bridge between your development work and regulatory requirements, providing the necessary guardrails to ensure compliance without stifling innovation.
With medical device-specific FDA and ISO best practices woven into the fabric of our software, you can keep pace with your development cycles, ensuring that compliance is built into the process from the start.
Wade Schroeder is a Medical Device Guru at Greenlight Guru with a noticeable enjoyment of medical device product development processes. As an electrical engineer by trade, he began his career developing medical exam procedure chairs and later designing IVD devices. He has been a risk management enthusiast since the...