I am an agile Team Leader, Project Manager, and testing advocate supporting other developers. Having optimization and scalability in mind, I have led software teams for over 11 years in the end-to-end project development lifecycle, e.g., architecture design, code, and documentation review. I specialize in creating eHealthcare solutions that meet HIPPA requirements. 

Szymon Kieloch

For the past years, innovations in and around [medical devices have increased](https://www.getconvey.com/resource/medical-device-statistics/). Thanks to the Internet of Things and developments in cloud computing and artificial intelligence, the acceleration was especially [visible](https://svn.bmj.com/content/2/4/230). The Software as a Medical Device market is expected to reach [$86,451.62 million in 2027 from $14,488.00 million in 2019](https://www.globenewswire.com/news-release/2020/05/12/2031716/0/en/Insights-into-the-Worldwide-Software-as-a-Medical-Device-Industry-to-2027-Featuring-Velentium-Tietronix-Software-S3-Connected-Health-Among-Others.html). The rise of smartphones’ popularity also changed the way we live and, therefore, the way we handle health care. Telemedicine has accelerated during the ongoing pandemic and become a necessity almost overnight.

Businesses recognize the **benefits of SaMD** solutions and are gaining interest in developing one of their own. Are you looking to build a SaMD solution yourself? Will it be an application tracking fitness progress? Or one analyzing heart rate and blood pressure? Are you wondering what are the benefits of building one? How to make sure your product is a SaMD solution? What are the regulations you have to meet and possible challenges? This article will provide you with in-depth knowledge on the topic of Software as a Medical Device as well as with answers to those questions.

\[TOC\]

## Software as a Medical Device - the definition

Software as a Medical Device (SaMD) is defined as **a class of medical software** built to carry out one or more medical functions without the need to be interfaced with other medical devices. It is any software that is developed to be used for medical purposes without being integrated into an actual device. The [international medical device regulators forum](http://www.imdrf.org/workitems/wi-samd.asp) describes SaMD as a type of software that can work on general-purpose computing platforms or with combination with other products like medical devices.

Software as a Medical Devices is a relatively new category in software development. It is a revolution in digital health technology as it can perform complex medical functions like diagnose conditions, suggest treatments and handle clinical management.

We can generally classify medical device software into [four subclasses](https://orthogonal.io/insights/software-as-a-medical-device-samd-basics/):

1. Software as a Medical Device (SaMD) which is a standalone software that serves as a medical product
2. Software in a Medical Device (SiaMD) which is software that is implemented into a medical product
3. Software as an accessory to a medical device
4. General-purpose software that is not a medical product

Because there is no hardware involved in SaMD there are fewer constraints to fast feedback loops. It brings new opportunities and challenges for both device manufacturers and regulators.

## Is your software a SaMD?

It is crucial to remember that SaMD is not software that supports the functioning of medical device hardware. If you want to determine whether your software can be classified as SaMD ask yourself a question of whether there is a medical benefit to using your software and think about if your software can work independently from other devices.

Here are some **examples of SaMD**:

* an application that calculates insulin dosage based on glucose levels
* software using AI to analyze MRI images and identify anomalies
* software that makes use of data from other digital devices to calculate the risk of epileptic seizures
* software using a smartphone microphone to detect interrupted breathing during sleep
* software performing image processing to detect cancer

We can divide [the examples](https://appinventiv.com/blog/software-as-a-medical-device-regulation/) of SaMD into four categories (I, II, III, IV). Those categories are based on the levels of the impact on the patient or public health. The information provided by the SaMD used to treat, diagnose or inform clinical management is vital to avoid death, long-term disability or other serious deterioration of health. They are as follow:

![](https://s3.amazonaws.com/a.storyblok.com/f/86602/720x459/3ce1975c72/categories-of-samd.png)

**Category IV**

* software that can perform diagnostic image analysis
* software calculating fractal dimension of a lesion in order to create a structural map with possible growth patterns
* software combining provided data searching for mutable pathogens

**Category III**

* software detecting interrupted breathing through a smartphone’s microphone
* software monitoring growth or other data that can be used in diagnosis a skin lesion

**Category II**

* software analyzing heart rate
* software analyzing health data to predict the risk of heart diseases
* software integrating and analyzing tests to propose a diagnosis

**Category I**

* software gathering data from symptom diaries to calculate the possibility of occurrence of an asthma episode
* software analyzing images and eye movement for diagnosis of astigmatism
* software which stores blood pressure information for further review
* software aiding in self-assessment of hearing loss

<Baner name={healthcare} />

There are a few key ‘rules’ of Software as a Medical Device that can help you qualify your software to one category or the other. They are as follows:

1. there is a medical benefit to the usage of your software
2. if misused or it malfunctions there is patient risk
3. your software can be used to inform, prevent, diagnose and treat diseases
4. it is able to provide patient data as well as inform healthcare providers about options for diagnosing, treating and preventing diseases
5. it can be used as a standalone device

SaMD software has to be clinically evaluated and therefore, is divided into two key software application dimensions:

**Significance of information** - including devices that are directly used in treatment or diagnosis. They are expected to have higher clinical evidence standards and need to have both analytical and scientific validity.

**State of disease** - when the software is used as an intervention for a critical disease, it must go through more rigorous tests.

## Benefits of SaMD

SaMD platforms enhance the administration and delivery of healthcare while reducing costs and improving health care outcomes. The information provided by the software can help diagnose and treat patients as well as inform and drive clinical management or personnel. [Software as a Medical Device improve](https://orthogonal.io/insights/software-as-a-medical-device-samd-basics/)s:

1. **Screening and diagnosis** - software programs can predict the risk of chronic diseases using complex algorithms. SaMD can help to deliver personalized treatment plans for patients and reduce the time from diagnosis to treatment. It gives medical practitioners an insight into a patient's medical condition.
2. **Monitoring and alerting** - SaMD systems can be built to be used by wearable sensors in order to collect vital signs. This allows patients to better monitor their conditions, identify triggers, and get informed on recommendations like drug dosage or physical activity.
3. **Chronic condition and disease management** - the software allows to track health data and adjust treatments accordingly. Patients get ownership of treatment decisions while physicians are able to design a more personalized treatment. It is especially useful in treating diabetes.
4. **Digital therapeutics** - SaMD plays a role in the treatment or mitigation of critical illnesses. It is often used in treating chronic diseases like sleep apnea. The software can use the microphone of a smart device and detect interrupted breathing.

## SaMD regulations

Regulatory requirements for medical devices are risk based. The level of inspection is dependent on the level of risk a product represents. Depending on the type and intended purpose of the SaMD the risk is low, medium or high however, as for now, many of them are classified as [low risk](https://www.tga.gov.au/regulation-software-medical-device).

### International regulations

In 2013, the International Medical Device Regulators Forum (IMDRF) established a group dedicated to Software as a Medical Device. They are working on the challenges associated with this type of software. Appropriate documentation is available on the IMDRF Documents site under the [Technical documents section](http://www.imdrf.org/documents/documents.asp#technical).

### U.S. Food and Drug Administration (FDA)

FDA has been working to create a regulatory framework for medical devices and medical device software:

* In 2011 a [Case for Quality](https://www.fda.gov/medical-devices/quality-and-compliance-medical-devices/case-quality) program started in order to promote device manufacturing best practices.
* In 2017 [Software Precertification](https://www.fda.gov/MedicalDevices/DigitalHealth/DigitalHealthPreCertProgram/default.htm) program started which expanded the Case for Quality program and is applied to medical device software, including SaMD. It is focused on innovation as well as patient safety.
* [Digital Health Innovation Action Plan](https://www.fda.gov/downloads/MedicalDevices/DigitalHealth/UCM568735.pdf) from 2017 aims to improve the federal agency’s digital health review process in order to provide more timely access to effective and safe medical technologies.
* In 2018 FDA went through a reorganization of pre and post-market review process to address the total product lifecycle ([TPLC](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfTPLC/tplc.cfm)), which facilitated information sharing, ensured process and policy consistency and provided more straightforward and streamlined integrations.
* The alignment of U.S. medical device regulations from [FDA 21 CFR Part 820](https://www.accessdata.fda.gov/scripts/cdrh/cfdocs/cfcfr/CFRSearch.cfm?CFRPart=820) to ISO [13485:2016](https://www.iso.org/standard/59752.html) emphasizes the FDA’s focus on risk management and is recognized by international medical device market.

Because of the enormous potential of software to increase healthcare quality and effectiveness, the FDA developed a Software Precertification Program.

It helps to address the following issues:

* How to apply the faster and more iterative design process used in software development in SaMD?
* How to capture health data inside and outside a hospital?
* How to improve product performance?
* How to create an agile regulatory model, which enhances the innovation rate?

The Precertification Program helped expand the FDA’s Digital Health Unit, provided clarity of scope and approach to digital technology and allowed the development of a more efficient regulatory framework. Apart from that, it gives patients faster access to technologies.

When discussing the topic of SaMD regulations, we also have to mention [IEC 62304](https://www.perforce.com/blog/qac/what-iec-62304). It is a functional safety standard that applies to the development and maintenance of medical software. It provides processes, activities and tasks to ensure safety.

There are nine parts of the functional safety standard:

**Part 1:** Scope.

**Part 2:** Normative references.

**Part 3:** Terms and definitions.

**Part 4:** General requirements.

**Part 5:** Software development process.

**Part 6:** Software maintenance process.

**Part 7:** Software risk management process.

**Part 8:** Software configuration management process.

**Part 9:** Software problem resolution process.

Software safety classification in the standard **determines the safety-related processes** the software developers have to use. It has a great impact on the entire software development lifecycle. There are three software safety classes:

**Class A:** No injury or damage to health is possible.

**Class B:** Injury is possible, but not severe.

**Class C:** Death or serious injury is possible.

Complying to those safety standards is crucial for medical device software development.

Apart from the FDA’s and IEC 62304 regulations, there are also other regulatory standards for medical devices like:

* [ISO 13485](https://www.iso.org/iso-13485-medical-devices.html) — quality management
* [ISO 14971](https://www.iso.org/obp/ui#iso:std:iso:14971:ed-3:v1:en) — risk management
* [EU Medical Device Regulation](https://ec.europa.eu/health/md_sector/overview_en) — EU standard which replaces Medical Devices Directive in 2020

## Challenges in SaMD development

There are some underlying fundamental challenges to Software as a Medical Device development. The biggest ones involve patient safety and regulatory compliance.

For the FDA, the primary concern is to ensure patient safety while preserving clinical effectiveness. There are no universal rules to follow then it comes to the development of SaMD, but starting off with pilot programs while implementing best practices and making use of fast feedback loops is usually the preferred approach.

## Conclusions

Software as a Medical Device provided features that extend beyond traditional medical devices or hardware. It leverages technology and connectivity to devices in order to **continuously monitor safety, effectiveness and performance.**

In the European Union, the software can be categorized as a medical device if it is ‘active’, which is if it depends on a source of energy other than generated by the human body.

According to the Food and Drug Administration in the United States, the software is considered a medical device if used for one or more than one medical purposes and performs these purposes without being a part of any hardware.

As the ‘internet of everything’ will continue to grow and affect all areas of our lives, the development of SaMD will also continue to evolve. It is for companies to decide whether they want to engage in developing such solutions.

Do you want to build such a solution and are looking for a development partner? [Contact our experts](https://selleo.com/software-development-team/healthcare) and let’s build something great together.

What is software as a medical device (SaMD)? This article defines SaMD, provides examples of SaMD, and the benefits of using them.

Read our articles on Selleo Blog

Business

Technology

What Is Software As A Medical Device (SaMD)?

Tell us about your project