What is Software as a Medical Device (SaMD)?

Technology has progressed faster over the past two decades compared to any other span of time in history. Today, even software can be considered a medical device and approved by the EU and FDA. What I am referring to is a SaMD.

A SaMD (Software as a Medical Device) is defined as:

“Software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device”.

Basically put, it’s independent software that, on its own, works as a medical device. There is obviously a lot of gray area here, so the International Medical Device Regulators Forum (IMDRF) created clear guidelines on what is and what is not an SaMD. The first guideline has to do with the device’s purpose.

In addition to being a stand-alone software program, SaMDs must also be used for one of the four following medical purposes:

Disease Diagnosis, Prevention, Alleviation, Monitoring or Treatment - A few examples of SaMDs in this category would include a piece of software that performs analysis on clinical samples to assist in diagnosing diseases, or software that uses a patient’s medical data to develop a risk factor for heart attack or stroke.

Management of Disease - An example in this category would be a software that takes pictures, analyzes them, and monitors the results. This information would help supplement other information for a healthcare provider, allowing them to better monitor the growth of a disease.

Control of Conception - This category might include a piece of software that analyzes real-time medical data of a woman and provides an optimal time for conception.

In-vitro Diagnostics - This category is fairly obvious and might include a specific type of software that diagnoses disease or conditions based on specific data gathered.

If the software doesn’t fall into one of the four purposes above, it’s likely not a SaMD. One example of medical-like software not considered a SaMD is software that is embedded into a hardware device, and that hardware device is necessary to use it. This is a bit different from software which can be used alongside other hardware devices as an additional enhancement. This latter software might qualify as a SaMD.

Some other software which is not considered a SaMD are common types of mobile applications. Examples of these applications include: fitness tracking apps, sleep pattern apps, stress management apps, and diet/calorie counting apps.

SaMDs fall into four different risk categories, and it’s important that developers understand where their device sits. The categories are simply numbered from I to IV. The first category has the least impact, while the fourth has the most.

• Category IV – These devices deal with life and death situations and are time-critical. They include SaMDs that perform analysis to diagnose and make treatment decisions for situations like meningitis in children, acute stroke patients, cancer lesions, etc.
• Category III – These devices also deal with life and death situations but are not time critical. Examples include:
  • SaMDs that sound an alarm to apnea patients when they detect interrupted breathing during sleep
  • SaMDs that act as a treatment planning system and provide specific parameters to aid in the treatment of a particular tumor.
  • SaMDs that monitor and provide information to healthcare providers for the diagnosis of a malignant or a benign lesion.
• Category II – These SaMDs deal with serious but not life threatening issues. Examples include:
  • SaMDs that analyze multiple blood tests and other data and that provide recommendations for the diagnosis of health issues such as kidney function, cardiac risk, iron and anemia assessment, etc.
  • SaMDs that visualize the anatomical structure of a patient and help in the placement of a catheter or markers into the correct structure, etc.

• Category I – These SaMDs are involved in the lowest threat level health issues. Examples include:
  • SaMDs that collect data such as ECG rate, heart rate, and walking speed of a rehabilitation patient.
  • SaMDs that collect data and anticipate an occurrence of an asthma episode.
  • SaMDs that store historical blood pressure information for a healthcare provider’s later review.
  • SaMDs that allow image analysis such as performing cell counts and morphology reviews.

Each risk category is basically broken down into two main statements.

1. The significance of the information provided by the SaMD to the healthcare decision. This can be further divided into 3 assessments: Treat or diagnose, drive clinical management, or inform clinical management.
2. The state of the healthcare situation or condition. This can also be divided into 3 categories: Critical, serious, and non-serious.

The final step to an SaMD is the clinical evaluation. During the evaluation, 3 processes are examined:

1. Valid clinical association
2. Analytical validation
3. Clinical validation

These assessments are all necessary to ensure that the information from the SaMD is accurate and reliable.

As you can see, there is a lot that goes into identifying software as a medical device. The information above barely scratches the surface of all that is involved and should be treated more like a high-level outline of what software needs to be to be considered a SaMD.

If you have more questions regarding SaMDs, please reach out to our team. We have designed and developed completely custom SaMDs for large healthcare organizations across the country and would love to hear more about your project.