Software as a medical device (SaMD) represents an opportunity to successfully build and launch patient-centric digital health products and platforms. In this article, we'll take you through the fundamentals: what is (and isn't) a SaMD, how federal and international agencies classify and regulate SaMD, and how you can get your digital health product to market faster.
What is vs. is not a SaMD?
Often, organizations interchangeably use the terms, “software medical device,” “medical device software,” and “mobile medical application,” to refer to software as a medical device (SaMD). But what exactly is SaMD?
Regulators generally agree that a software application intended for a medical purpose—without being embedded in (or a part of) a hardware medical device—is a SaMD.
However, federal and international agencies differ in how they define and operationalize medical purposes. What is regulated as a SaMD in one region may be exempt from (or subject to more stringent) SaMD regulations in another. How you design, build, test, validate, and implement SaMD will vary across geo-political boundaries, medical specialties, market segments, and patient populations.
For example, these are not SaMD:
- Customer relationship management (CRM) systems
- Electronic medical or health records
- Patient portals
- Computer-assisted coding
- Patient scheduling automation tools
- Hospital information systems
A brief overview of SaMD classification
Regulators classify SaMD according to the level of risk posed to patients. A SaMD has a medical device classification and a software safety/risk classification. Listed below are classifications we frequently work with.
Medical device classifications by the IMDRF, MDR, IVDR, and FDA.
| Lowest | → | → | Highest | |
|---|---|---|---|---|
| International (IMDRF) | I | II | III | IV |
| EU (MDR) | I | IIa | IIb | III |
| EU (IVDR) | A | B | C | D |
| USA (FDA) | I | II | III |
Safety/risk classifications (IEC 62304 & FDA)
| Lowest | → | Highest | |
|---|---|---|---|
| International (IEC 62304) | A | B | C |
| USA (FDA) | Minor | Moderate | Major |
A software system consists of software units. Individual software units can have disparate safety classifications. The software unit with the highest safety classification determines the safety classification of the overall software system.
In our experience, bringing compliance requirements into the software development process from the start enables teams to build and release faster. Furthermore, insulating disparate features might lessen the burden of documentation and review throughout the development cycle, potentially disencumbering regulatory approval processes when changing software post-market launch.
The classification of your SaMD determines the level of rigour regulators expect in software documentation and development, the quality management system, risk management processes, the clinical evidence supporting its safety and effectiveness before you can market your product, and post-market surveillance and support.
Which classification is best for you?
Targeting the wrong SaMD classification (or failing to identify a target classification early in design and development) can have disastrous consequences.
Here are some ways to identify the appropriate classification for your SaMD and avoid common pitfalls:
- Assess at an organizational level which classifications the company is prepared and mature enough to obtain.
One way to avoid ballooning budgets and multi-year release cycles is to forego features warranting rigour that your organization is unprepared for. You can start by identifying which SaMD classifications are feasible (e.g., given your organizational maturity, resources, timelines), and work backwards to determine feature specifications. - Consider how quickly you need to get to market.
If you need to launch quickly to gain a competitive advantage, you may want to reduce regulatory burden and aim for a less stringent classification (or to be exempt from SaMD regulations).
For example, if you are developing a mobile app that helps parents monitor infant language development, it may be advantageous for you to ensure that your app is not classified as a SaMD and is exempt from SaMD regulations.
With a blue ocean strategy, you may be better positioned to pursue a lengthier pathway to obtain a more stringent SaMD classification. - Understand how your product fits in the market and leverage your competitive edge.
Use the Jobs to be Done framework to understand your customers’ needs, motivations, habits, and behavioural patterns. - Balance customer ROI with feasibility and funding considerations.
Higher SaMD classifications require more rigorous documentation, validation, and QMS that warrant expertise, extraordinary financial resources, and a clear market opportunity.
For example, if you are developing a mobile app that helps patients with diabetes mellitus better manage their condition, SaMD classification may be absolutely necessary to market your device.
Taken together, companies often get caught in multi-year release cycles, miss their window of opportunity to go to market, or finish developing software but fail to obtain regulatory approval and launch their product to market. Strategically design software to obtain the appropriate SaMD classification for your organization to get your product to market.
General wellness products
The US FDA exempts, from SaMD regulatory requirements, products that are intended for only general wellness use, are neither invasive nor implantable, and do not pose a risk to the safety of users and other persons. For instance, products that are intended to promote, track, or encourage a healthy lifestyle may not be regulated as a medical device by the US FDA; a general wellness product may make reference to chronic disease or conditions where it is well supported by empirical evidence and generally accepted.
In contrast, the Council of the European Union has not, to date, issued specific guidance on products intended for general wellness use.
Therefore, a software product that encourages a healthy lifestyle may not be regulated as a SaMD by the US FDA, but be regulated as a Class I SaMD by the Council of the European Union.
Patient support program (PSP) and companion apps
Pharmaceutical companies commonly build patient support programs and companion apps (e.g., to educate patients, increase medication adherence).
In 2021, the Council of the European Union began enforcing Rule 11 (from EU MDR 2017/745), which broadens the scope of SaMD and as a result might require SaMD classification of apps that previously did not need to be qualified.
Furthermore, Rule 11 classifies any application providing information for a diagnostic or therapeutic purpose or monitoring physiological processes as a class IIa, IIb, or III SaMD.
Most PSP and companion apps are now regulated as class IIa, IIb, or III in the EU, increasing the stakes for organizations to understand and be capable of building compliant SaMD.
Why are most SaMD launches delayed?
Many healthcare organizations make the mistake of conceptualizing SaMD as projects. They often consider compliance requirements and processes too late in the product design and development process.
On the surface, this sequential way of planning and managing projects makes sense: the first step of creating a new product is to understand what your customers want, build it, complete the necessary regulatory compliance checks, and then launch. Teams establish and document software requirements and specifications upfront.
However, this method delays the project from the very start of the planning phase: all functional and non-functional requirements must be determined, and artifacts and master test suites built; various approval flows slow each step. A draft of soon-to-be stale documentation marks the end of the planning phase.
The documentation, at this point, reflects an ideal version of the SaMD; in reality, no one fully understands how it'll work. The team does not have an opportunity to prototype, test, or validate pieces of what's about to be built.
As the product team starts building the product, the requirements and specifications change. The documentation they had created at the beginning is incongruent with what they built. They retroactively amend the documentation, but no one remembers 100% of what was changed.
What follows are very expensive cycles of preparing, submitting, waiting, revising, and resubmitting technical files to a notified body. These costly cycles of rework and reviews, combined with notified bodies' immovable submission deadlines, are how SaMD launches are delayed by 2+ years.
Compliance by Design is our approach to building digital products in highly regulated contexts.
To successfully launch a SaMD, you need a compliant product and documentation supporting compliance approved by the appropriate regulator(s).
In essence, our approach to SaMD combines:
- DevOps with compliance & risk management built-in
- Agile quality management system (QMS)
- Agile software development and design (e.g., the American National Standards Institute's consensus statement, which is recognized by the US FDA)
- Lean governance
Compliance by Design has enabled our clients to reduce regulatory rework, obtain regulatory approvals, and launch digital products ~60% faster.
Shift quality left
Shifting quality to the left is a practice of testing earlier to find and prevent defects as soon as possible in the software delivery process.
What does shifting quality left look like in practice for SaMD? Rather than converting documentation into user stories, user stories become specifications. A product owner writes the product backlog; quality assurance and solution architects contribute rigour and compliance coverage to the high-level software architecture.
The product is built and tested incrementally with every sprint—software item, unit, integration, and system tests are run in every sprint. Validation and verification are also completed using the SDLC V-model with each release. As we build and update stories, the product backlog holds all the stories, which are all tagged to higher order documents.
Alongside the built product are artifacts that accurately document the end state, so the product backlog can be exported as documentation.
Building a test case suite at the end is easier when you have documented test case passes, and live regression over time with traceability. The quality assurance team's role shifts from command and control support to strategy execution, benefiting both the organization and the product with reduced handovers, rework, documentation, costs, and time-to-market.
Why is building a SaMD worth the challenge?
In a way, “software as a medical device” is a misnomer; it delimits SaMD to the confines of medical devices. For years, companies have supplanted hardware medical devices with SaMD.
Software as a medical device represents a much broader and richer opportunity to reimagine and engineer how we experience healthcare—as patients, practitioners, providers, and more—beyond the limitations of traditional medical devices.
For example, how can you improve drug compliance by gamifying chronic disease management, or monitor and prevent chronic diseases by harnessing population-based data? With SaMD, companies can explore new offerings and experiment without disrupting existing business lines.
Although SaMD regulations make launching new products more challenging, patients and practitioners are excited for SaMD products. The SaMD market is estimated to nearly double in size in the next 3.5 years, growing at a compound annual growth rate of 22% between 2020 and 2027.
To learn more about SaMD, check out our hub and subscribe to upcoming articles and events.