Only recently, the medical device industry has initiated the development of software-based products entirely independent of hardware devices. Software as a Medical Device (SaMD), although vastly different from traditional medical devices, holds just as much promise in enhancing the quality of life for patients worldwide. There has been a remarkable surge in innovation within the realm of medical devices. The advent of the Internet of Things (IoT), coupled with advancements in cloud computing and artificial intelligence, has propelled this acceleration significantly.
Notably, the Software as a Medical Device (SaMD) market is poised for substantial growth, projected to reach $86,451.62 million by 2027.
Remarkably, regulatory bodies worldwide still classify SaMD as medical devices. In this guide, we will demystify these devices and provide you with valuable insights into their regulation and what you can anticipate as you embark on the journey to create one.
Defining Software as a Medical Device (SaMD)
Before embarking on the development of Software as a Medical Device (SaMD), it is essential to ensure complete clarity regarding whether the medical device you are building or planning to build indeed qualifies as SaMD. The International Medical Device Regulators Forum (IMDRF), a global consortium of regulatory authorities focused on harmonizing regulations for medical products, including SaMDs, provides us with a precise definition of SaMD:
The term "Software as a Medical Device" (SaMD) is defined as software intended for one or more medical purposes, capable of achieving these purposes without being part of a hardware medical device.
In essence, there are two primary categories of medical device software:
Software as a Medical Device (SaMD):
In this scenario, the software itself functions as a medical product.
Software in a Medical Device (SiMD):
Here, the software operates as a component within a larger medical device.
While additional categories of medical device software, such as accessory products to medical devices, exist, we will not delve further into these specific types in this context.
The Key Advantages of SaMD Solutions
SaMD solutions offer two fundamental advantages that deserve recognition:
Data Utilization for Enhanced Patient Health
Versatile Software Deployment Over Hardware
SaMD solutions revolutionize data collection, surpassing the efficiency and speed of traditional health improvement methods. Additionally, as these solutions adhere to stringent regulations, the quality of the collected data is consistently high. Consequently, SaMDs empower the healthcare sector to develop patient-centric solutions capable of significantly enhancing patient well-being.
SaMDs primarily exist in the cloud, presenting substantial advantages in terms of speed and versatility. This applies not only to the development of such solutions but also to their updates and adaptability. Leveraging cutting-edge technologies, connected medical devices can be created, built, and maintained with greater ease compared to traditional hardware-based health improvement solutions.
Ivanna
Client Manager
Contact us, and we will share our case studies related to healthcare software development
Get a Free ConsultationKey Elements of SaMD
There are four fundamental elements present in nearly every SaMD solution:
SaMD Inputs
These encompass the data inputs necessary for the SaMD to operate effectively. Inputs can include patient data, laboratory results, image data, physiological states, symptoms, and more.
SaMD Algorithm
At the heart of every SaMD, the algorithm plays a pivotal role. It often houses the intellectual property (IP) of the solution, containing the set of instructions and logic required for the SaMD to perform its task, generating medical-related outputs.
SaMD Outputs
Following the entry of inputs into the SaMD and the algorithm's processing, various outputs are generated. These outputs inform, guide, diagnose, or treat the SaMD user.
Clinical Evaluation
The outputs of the SaMD undergo clinical evaluation, a challenging and critical phase for every SaMD. For detailed information on successfully navigating this stage, refer to our in-depth blog post.
Categorization of SaMD Solutions
The categorization of SaMD solutions varies between the European Union (EU) and the United States (US) regulated markets.
EU SaMD (MDSW) Categorization
In the EU, the official term used is "Medical Device Software" or "MDSW." The EU's Medical Device Regulation (MDR) defines four classes: I, IIa, IIb, and III, aligning to a significant extent with the classification established by the International Medical Device Regulators Forum (IMDRF). These classes are determined based on the intended purpose of the medical device and associated risks.
Risk assessment in the EU relies on the harmonized ISO 62304 standard. To launch a SaMD in the EU, obtaining a certificate of conformance from a notified test body for this standard is essential.
US SaMD Categorization
In the US, the Food and Drug Administration (FDA) determines SaMD classes based on impact and functionality controls required to establish safety and effectiveness. The FDA classifies SaMD into three categories: Class I, Class II, and Class III. Risk classification of the Software as a Medical Device by the FDA also draws from the ISO 62304 standard, albeit with some distinct terminology.
How to Determine if Your Product Qualifies as SaMD
Both the FDA in the Software as a Medical Device and IMDRF provide definitions that exhibit structural similarities. According to both sets of definitions, two key criteria must be met for software to be categorized as SaMD.
First and foremost, you need to ascertain whether the software can be classified as a medical device at all. The IMDRF states that it must be "intended for one or more medical purposes," while the FDA specifically references the definition of a device in section 201(h) of the FD&C Act, which stipulates that a device is:
An instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or other similar or related article, including a part or accessory, which is:
- Recognized in the official National Formulary, the United States Pharmacopoeia, or any supplement to them.
- Intended for use in the diagnosis of disease or other conditions, or the cure, mitigation, treatment, or prevention of disease, in humans or other animals.
- Intended to affect the structure or any function of the human body or other animals' bodies and does not achieve its primary intended purposes through chemical action within or on the human body or other animals.
- Not dependent upon being metabolized for the achievement of its primary intended purposes.
It's important to appropriately define your product's intended use and indications for use using these criteria:
- Intended use represents the purpose of your device, explaining what your device will be used for.
- Indications for use describe the diseases or conditions that your device will diagnose, treat, prevent, cure, or mitigate. They specify who your device will be used on and why.
Once you have clarified these uses, the second and third points in the FDA's definition of a SaMD should help you determine whether your product falls under medical device regulation.
If you plan to market your software product in the United States, we strongly recommend carefully reviewing the FDA's guidance on "Policy for Device Software Functions and Mobile Medical Applications." This guidance provides clear guidance on software functions that the FDA considers SaMD, those that are not considered medical devices, and those it does not regulate as such.
However, if you still have doubts about whether your product qualifies as a medical device, it is advisable to contact the FDA directly for further clarification.
Is Your Software Considered SaMD or SiMD?
Once you've established that your product aligns with the definition of a medical device, it's crucial to delve into the second part of the SaMD definitions provided by the IMDRF and FDA.
The IMDRF definition specifies that the software must fulfill its intended purposes "without being part of a hardware medical device."
Likewise, the FDA SaMD definition "is intended to be used for one or more medical purposes without being part of a hardware device."
This distinction narrows the scope of SaMD considerably. Software designed to operate or drive a hardware medical device does not meet the criteria for SaMD. Instead, such software falls under the classification of SiMD, or "software in a medical device."
In simpler terms, any software that contributes to the functioning of a hardware medical device, be it by controlling its mechanical aspects or generating a graphical interface, is categorized as software in a medical device. Some examples encompass:
- Software governing the inflation or deflation of a blood pressure cuff.
- Software controlling the insulin delivery mechanism of an insulin pump.
- Software involved in the closed-loop control of a pacemaker.
These types of software are sometimes referred to as "embedded software," "firmware," or "micro-code." If you come across these terms, understand that they pertain to SiMD, not SaMD.
To classify a product as SaMD, the software must operate independently of any hardware while performing functions that define it as a medical device. IMDRF guidance on the "Possible Framework for Risk Categorization and Corresponding Considerations" offers further clarification on the SaMD definition:
- SaMD qualifies as a medical device and includes in-vitro diagnostic (IVD) medical devices.
- It can run on general-purpose (non-medical) computing platforms.
- "Without being part of" denotes software that is not essential for a hardware medical device to fulfill its intended medical purpose.
- Software intended to drive a hardware medical device does not fall within the definition of SaMD.
- SaMD can be utilized in combination with other products, including medical devices.
- It can interface with various medical devices, including hardware medical devices, other SaMD software, and general-purpose software.
- Mobile apps meeting the criteria mentioned above are categorized as SaMD.
Note: While distinguishing between SaMD and SiMD is essential, both types of software adhere to many of the same standards for development, such as IEC 62304, the international standard governing software lifecycle processes. Even if your software qualifies as SiMD, you'll find numerous guidance documents and standards in this guide that remain relevant and useful.
Regulation of SaMD (Software as a Medical Device) Worldwide
Global SaMD regulation varies by market, with a focus on the US and EU as major players in medical devices.
SaMD is classified as a medical device, requiring adherence to regulations. In the US, compliance is with the FDA's Quality System Regulations (QSR), which has specific guidance for SaMD, particularly in premarket submissions. There are two key FDA guidance documents. One from 2005 categorizes SaMD into Minor, Moderate, and Major levels of concern, impacting documentation requirements. A 2021 draft guidance simplifies this to Basic and Enhanced Documentation, although the final guidance remains uncertain. It's wise to indicate both the level of concern and documentation type until the new guidance is finalized.
In the EU, SaMD is regulated akin to traditional medical devices under the EU Medical Device Regulation (MDR) or In Vitro Diagnostic Regulation (IVDR) for in vitro diagnostic devices. The EU refers to it as "Medical Device Software" or MDSW. The European Commission offers various guidance documents addressing SaMD, including classification, clinical evaluation, cybersecurity, and qualification and classification of software.
Understanding these US and EU regulations is essential for SaMD manufacturers navigating global compliance and market access.
Classification of Software Safety According to IEC 62304
IEC 62304, the international standard governing software lifecycle processes, provides a classification system for software safety.
The IEC 62304 classification system comprises three levels, each determined by the severity of injury that could result from a software failure:
- Class A - No injury
- Class B - Non-serious injury
- Class C - Serious injury or death
It's crucial to understand that software safety classification does not assess the inherent safety of your software. Instead, it serves as the basis for determining the level of rigor required in your software development processes.
The actual safety of your device is contingent on the effectiveness of your design and development processes, not solely on its safety classification. Therefore, the safety classification helps define the necessary procedures and precautions during development.
Importantly, your safety classification under IEC 62304 does not have a direct one-to-one correspondence with risk classification under US or EU regulations. However, it shares a strong correlation with risk class, which is an essential consideration when navigating regulatory requirements.
For instance, if your safety classification is Class C, there's a high likelihood that your device will fall into Class III (for either US or EU regulations). Nevertheless, it is possible to encounter situations where a device has a safety classification of Class C but falls into a lower-risk class.
In summary, the IEC 62304 classification system primarily pertains to safety considerations during software development. While it provides valuable guidance for development rigor, it is not an absolute indicator of risk classification, and it doesn’t directly reflect the overall safety of a completed SaMD product.
Our Experience
HospApp
Our client sought to develop a novel mobile system designed to facilitate seamless communication among all employees within groups associated with specific patients. This system enabled individualized communication, file sharing, prescription management, and task execution for patients within the respective groups. It emphasized the utmost security of patient information, ensuring it remained within the confines of the hospital.
To address needs, we developed a demo Android application featuring key functionalities for hospital staff. The Stfalcon team provided comprehensive services, including user interface design, Android development, manual testing, quality assurance, and successful implementation.
Read the full case study
IsDocIn
The project's objective was to develop a mobile application that simplifies the process of scheduling appointments with healthcare professionals. Doctors were given the capability to establish profiles and receive notifications when patients booked appointments with them.
Read the full case study
Our contributions to this project included:
- Crafting an intuitive user interface (UI) for the mobile app intended for patient use.
- Designing versions of the app tailored for both iOS and Android platforms.
- Developing native applications for iOS and Android, adhering to the design specifications.
Bottom Line
The realm of Software as a Medical Device (SaMD) is both intricate and continually evolving.
Within the realm of SaMD, there remain areas of uncertainty within regulations and guidelines that will necessitate attention in the years ahead. Persistent challenges, such as cybersecurity, demand ongoing efforts. Moreover, the transition for software developers entering the medical device domain, and vice versa, presents a steep learning curve.
However, it's crucial to recognize the abundant opportunities and excitement that this space offers. Equipped with the right tools and expert guidance, Stfalcon’s dedicated team can create top-tier SaMD solutions that enhance the lives of countless patients. If you are interested in the development of the SaMD project, contact us, a complimentary consultation is available.
