FAQs about Software as a Medical Device (SaMD)

Medical-purpose software development is a rapidly growing industry. As with other medical devices, medical-use software offers potential benefits to patients. SaMD can save lives by improving diagnostic capacities, monitoring treatment efficacy, and guiding critical-care decisions. Review the online GMP compliance course for SaMD designers, medical-use software manufacturers and mHealth industry employees.

But SaMD also poses risks. These software risks must be managed through a robust quality management system (QMS). In this article, we’ll explore some of the safety concerns about medical-purpose software (SaMD: Software as a Medical Device) – including SaMD recalls – in the rapidly expanding ‘medical-use software development’ sector.

We’ll also introduce regulatory requirements for software-based medical devices (SaMD) from the IMDRF and GMP compliance guidance from Regulatory Authorities such as the TGA, FDA, EU-EMA, MHRA (UK), and more.

SamD: Software as medicine classifications and regulations FDA TGA EMA


FAQ #1: How rapidly is the SaMD / mHealth app market growing?

SaMD and mHealth market growth rates: healthcare software and medical-use software/apps including digital technologies and wearable tech

Medical-use software technology, and healthcare-focused apps, are expanding rapidly in both capacity and use. With advancing technologies and portable computing devices, SaMD is increasingly being adopted by physicians and patient alike.

New developments in the medical-software product sector are also growing exponentially.

  • There are well over 350,000 mHealth apps available; of which an estimated 15% (or higher) are for designated medical-purposes vs general fitness apps (like FitBit apps and other wearable technologies)
  • Over 80,000 software app publishers have entered the mHealth app sector, and some software publishers are not overly familiar with regulatory standards / GMP compliance requirements for safety, quality and efficacy when it comes to medical-purpose software products and medical-use apps (software as medical devices)

So what are the potential issues with SaMD products – and what are the risks to patients?

Medical-use software now plays a much larger role in aiding physicians and/or hospital teams to diagnose medical conditions and/or to prescribe, modify or direct a patient’s treatment regimen (e.g., according to software algorithms and various inputs from sensors, sophisticated feedback systems and manually-entered data).

This is even the case when it comes to life-threatening events and critical medical-care decision-making. Regulators across the globe have recognised the need to provide additional guidance – as well as updated IMDRF and GMP compliance guidelines (currently being implemented) – to accommodate the massive expansion of SaMD functionality, product types, and mHealth apps.

In terms of how rapidly the mHealth industry and SaMD market sectors are growing, these industries are expanding SO rapidly that keeping pace with actual growth rates – yet alone the latest medical-use software technologies being delivered – has also proven challenging.

That noted, a snapshot of the SaMD and mHealth sector is as follows:

  • The global mHealth industry is currently worth an estimated $30 billion (USD); depending on how you calculate the growth and if health and fitness apps are included or excluded
  • The mHealth app industry growth rate is expected to exceed 15% (CAGR) and to be worth from $50 to $111 billion (USD) in just a few years’ time

Industry growth is being driven by ever-expanding mobile phone use, high-speed internet access, and portable device accessibility including wearable sensors, other wearable tracking technologies, and new medical-capacity software capacities (computer ‘intelligence’/algorithms).

  • There are well over 350,000 software programs/apps relating to healthcare delivery, personal health, and/or medical-use functionality (e.g. with diagnostic functionality and/or chronic condition management capacity enhancement)
  • Over 60% of individuals with smartphones have downloaded at least one mHealth app and/or looked up healthcare data on the web
  • Depending on the resources of a doctor or hospital, it is believed that a significant majority of medical practitioners (at least 6 in 10) now rely heavily on digital information sources (including medical-use apps and other software) to perform their roles in healthcare delivery and chronic condition monitoring
  • There are so many new products, and new manufacturers, entering this industry space that regulators are having to adapt and update their regulations for Medical Devices and, in particular, SaMD products that may pose high risks to patients when quality is low (and unfortunately, recalls of software products used in medical care are very common, and indicate a high-risk to patients when there are gaps in the manufacturer’s quality management systems and/or SAE reporting procedures and other GMP compliance measures)

In brief, there are 2 primary types of software that can aid (or hinder) patient healthcare outcomes.

These types are health-focused (such as fitness apps and motivational healthcare programs on smartphones) or those with medical-purpose capacity (used for diagnostic, treatment management or monitoring purposes).

 

mHealth apps growth rate statistics 350,000


FAQ #2: What software programs (and/or mHealth apps) qualify as ‘a medical device’ (SaMD) and are thereby subjected to regulatory compliance inspections?

It is the intended use (intended purpose) of the software product that determines if a particular software product is considered “SaMD: Software as a Medical Device”. Intended use for medical purposes, and classifications of SaMD products according to risk levels, is discussed in further detail in the SaMD training course (online).

SaMD products are subject to regulatory compliance inspections by a Regulatory Authority (such as the FDA, TGA, EMA, MHRA, and BfArM) and must comply with relevant guidelines including GMP guidelines and SaMD regulations.

Note: updated regulatory compliance guidelines for SaMD are being implemented in 2020, 2021 and 2022 in several regions including in Europe, the UK, the USA and Australia.

Intended use is the primary factor considered for SaMD classifications and regulations.

The software category is based upon (and regulated on) risk assessments. Medical Device Category I of IV is the lowest risk per the IMDRF. Alternatively, the FDA currently classifies medical devices (including SaMD) into 3 classes: Class I-III, with Class III being the highest product risk category requiring stricter regulatory compliance measures (and more likely to fail a Regulatory GMP compliance inspection or ‘audit’ by the TGA, FDA or other regulatory authority).

recalls of medical use software recall rates

But other factors may influence HOW ‘medical device software’ is regulated.

For example, Regulatory Authorities in different countries often distinguish between embedded software (in a medical device) – which is regulated as a single device or unit – and SaMD, which is stand-alone software that is not dependent on a specific device.

SaMD products are those products which are designated as having medical-purpose capacity/capacities in their own accord; and which are not reliant upon (nor embedded in) a specific medical device.

Known as “SaMD” (Software as a Medical Device), these software programs have diverse functions in medical-care settings. They operate, and are regulated by the Authorities, as stand-alone medical-purpose software.

SaMD Regulation snapshot: The primary distinctions regulatory authorities make for Software as a Medical Device (SaMD) revolve around intended use (purpose) and stand-alone capacity.

Classifications of medical use software can vary depending on the country and regulatory guidance documents used by the Regulators. In general, however, the following guidelines tend to apply (regardless of jurisdiction).

  • Software functionality (and potential impact on the patient’s wellbeing) must be risk-assessed (and monitored)
  • Risk levels (low-medium-high-or-very-high risks) will inform GMP quality assurance measures and QRM requirements
  • Adverse event recordkeeping must follow GMP and GCP regulations

As with all other medical devices, regulations for Software used in medical settings will focus on the implementation of a robust quality management system (QMS) including ongoing testing and SAE reporting.

The QMS must be based on quality risk management (QRM) principles including ongoing safety, quality and efficacy monitoring – and continuous improvement processes.

FDA SamD: Software as medicine classifications and regulations

Quality management for Software as a Medical Device relies on quality risk management principles

The more critical the healthcare software is for ensuring a patient’s wellbeing and healthcare treatment outcomes; and/or the more critical the app functions become for preserving a patient’s health, organ functions and/or the patient’s life (itself); then the higher the risks, and:

  • The higher the risks to patients, the more robust the QMS/QRM approach must be.
  • The more intense the regulatory compliance measures that manufacturers (and/or medical device Sponsors and SaMD Importers).

FAQ #3: Is SaMD regulated the same in every country?

SaMD manufacturers and Sponsors must comply with the latest GMP guidelines and adverse event reporting requirements (Pharmacovigilance).

Regulations for medical devices can vary from country to country. First, not all countries are using PIC/S GMP 009-14 (the latest PIC/S GMP guideline); some countries rely on PIC/S GMP (009-13) and others are still using PIC/S GMP (009-08).

There is, however, some consistency via the harmonisation efforts of the IMDRF (International Medical Device Regulators’ Forum); and PIC/S GMP guides.


For more on SaMD regulatory compliance requirements and examples based on FDA, TGA, EMA, MHRA regulations and more – consider completing the online SaMD regulation training course by PharmOut (newly released – October 2020).


FAQ #4: What are the benefits vs risks of medical-use software (such as radiotherapy treatment planning software or “TPS”)?

These software programs (and mHealth apps) have the capacity to benefit patient outcomes by:

  • Improving diagnostic capacities of medical professionals
  • Aiding health condition monitoring (including treatment efficacy) over time
  • Informing healthcare treatment decisions or designating optimal treatment parameters, such as when used for radiotherapy treatment planning (radiotherapy dosing and target locations), via Treatment Planning Software (TPS)

But along with clear benefits of Software as a Medical Device, SaMD does bring risks to patient healthcare outcomes (such as what can happen when something doesn’t go to plan).

tps-radiotherapy-software-medical

In the event of an error (either input based, processing-based/coding errors, or data corruption or data integrity breaches), the following harms might result from SaMD products and other medical-device software programs/apps:

  • Incorrect dosing and/or medication titration for a patient with a chronic condition
  • Catastrophic failure of the data (data loss or corruption) and/or software functionality (e.g. via data breaches, duplicate record issues, input errors, or ransomware attacks of medical data servers and eHealth records/patient records)
  • Incorrect targeting of radiotherapy beams that may damage surrounding tissues or fail to reach and treat the tumour location

FAQ #5: How many SaMD recalls are there (medical software recall statistics)

Medical-use software can save lives, but it can also harm them when things go wrong. Recalls of SaMD products are sadly common including in Australia, Europe and the USA.

This is, in part, why regulations are changing (with key SaMD regulatory updates being implemented in 2019, 2020, 2021 and 2022).

Recalls are believed to relate primarily to a lack of adequate quality management measures taken by manufacturers. Many of whom are new to the field of medical device development, and not yet familiar with the safety regulations and compliance requirements for their products (including clinician input, robust quality testing, and continuous quality/safety monitoring, as well as recordkeeping requirements to demonstrate compliance with IMDRF guidelines, GMP guidelines for medical devices, and other SaMD regulations).


Reasons medical-use software has been recalled – a snapshot

A number of mHealth apps and medical-purpose software systems are being recalled due to issues of quality and efficacy. Studies show numerous recalls of medical-use software due to potential safety issues including:

  • input errors
  • coding errors / program faults
  • alarm failures
  • data corruptions
  • inadequate algorithms or quality management strategies (QRM deficiencies)
  • power failures or system crashes
  • patient medical data privacy (security breaches, malware, ransomware, etc)

Summary of Software as a Medical Device (overview)

Additionally, the capacity of these apps – as well as their increasing use in medical care settings (from radiotherapy treatment parameters for cancer patients to emergency care settings such as the ER and trauma surgery rooms), is growing at a pace that few hospitals, doctors, patients (and Regulators) can keep up with.

End-user involvement in the product design, along with adequate end-user training (and clearly-written technical documentation) can help reduce risks to patients and doctors relying on the accuracy of these software programs for critical healthcare information.

Recommended further learning – the SaMD training course for medical software designers, medical personnel and medical device manufacturing personnel

Complete the online SaMD training course for employees and manufacturers working in, or with, software products used in medical settings and/or for patient healthcare purposes.ย  The course is a Certificate Course available online.

Last updated on October 7th, 2021 at 06:56 am

Similar Posts