What are the key regulatory challenges of Software as a Medical Device (SaMD)?

Reading time 15 mins

1. Each country has its own regulatory body, and many of them classify SaMD differently – creating a lack of harmonisation for users and developers
2. Lack of harmonisation creates difficulties for innovators who need to navigate diverse requirements across multiple territories
3. Regions such as the UK and EU have planned reforms to overhaul outdated frameworks but haven’t implemented them, making it difficult for businesses to achieve and demonstrate compliance
4. How is software developed by third parties, i.e. software of unknown providence (SOUP), off-the-shelf software (OTS software), or commercial off-the-shelf software (COTS software) regulated?
5. Software often requires regular updates. How will this affect compliance?
6. SaMD cannot be physically labelled with a Unique Device Identifier. Regulators and industry need to agree on a global device identification and coding standard to identify and track SaMD throughout its life cycle
7. Cybersecurity vulnerabilities
8. The Internet is dynamic and constantly evolving – security concerns are impossible to eliminate entirely. How can developers create adaptable and compliant software that doesn’t put users’ data at risk, either?

What is SaMD, and who regulates it?

The International Medical Device Regulators Forum (IMDRF) defines SaMD as ‘software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device.’

• Can run on general purpose, i.e. non-medical computing platforms
• Software is not SaMD if its intended purpose is to drive a hardware medical device
• It may be used in combination with other products and medical devices
• It may be interfaced with other medical devices, including other SaMD, and general-purpose software
• Mobile apps that meet the definition are SaMD

That the software performs a medical purpose is critical, as this is what differentiates SaMD from software used for general healthcare and wellness purposes ^[4]. Medical purposes include diagnostics, treatment, prevention, monitoring and alleviation of disease. SaMD also includes disease management, contraception, in-vitro diagnostics, and sterilisation.

For example, a smartphone app that uses a microphone to monitor sleep apnea ( a potentially severe sleep disorder) and sounds the alarm to wake the user up when it detects an irregular breathing pattern is SaMD. However, a mobile app that tracks healthy people’s sleep patterns is not SaMD.

That the SaMD software be standalone is also key. Medical Device SoftWare (MDSW) that is embedded as part of the hardware of a medical device and is not necessary for the device to achieve its intended purpose (e.g. smart inhalers for people with asthma) is not SaMD. The distinction here is important as it changes the regulatory scope.

Once developers have classified that their product is, in fact an SaMD, they then need to identify the category it fits in ^[4]:

• Category 1 (low risk): Collects data (e.g. ECG rate, heart rate walking speed for a patient in rehabilitation under medical supervision)
• Category 2 (low-medium risk): Software that analyses multiple tests and provides recommendations for diagnosis
• Category 3 (medium-high risk): Sounds an alarm when an anomaly is detected (e.g. sleep apnea), software that’s part of a treatment planning system (e.g. provides parameters to treat tumours), illness monitoring and diagnosis
• Category 4 (high risk): Software used in life-and-death scenarios and are time critical (e.g. meningitis in children, acute stroke)

Although the IMDRF has published guidelines on SaMD, it’s important to note that this agency primarily consists of voluntary medical device regulators whose policies – although adopted by many countries – are not binding. This, in turn, has led to countries and regions classifying and regulating software as a medical devices differently.

How do different countries regulate SaMD?

Great Britain’s SaMD regulations are being reformed to align closely with IMDRF guidelines and nomenclature. These devices are regulated by the Medicines and Healthcare products Regulatory Agency (MHRA). The current medical device regulations contain few provisions explicitly aimed at regulating SaMD.

The EU does not use the term SaMD. Instead, they use MDSW classification, which implies a different scope for software in the medical field than the IMDRF. Governed by the European Medical Device Regulation (EU MDR), a key difference here is that software can be used alone or in combination with other medical devices. In addition, it uses a rules-based framework (based on the significance of the information provided by the software to the healthcare decision/situation or the patient’s condition) to classify devices ^[5]:

• Class IIa: Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes – except if such decisions have an impact that may cause risk classes III and IIb below
• Class III: Death or an irreversible deterioration of a person’s health
• Class IIb: Serious deterioration of a person’s health or surgical intervention
• Class IIa: Software intended to monitor physiological processes (e.g. for routine checkups)
• Class IIb: Software designed to monitor vital parameters where variations could result in immediate danger to the patient (e.g. devices used to monitor a patient under anaesthesia)
• Class 1: All other software

The USA’s SaMD regulations are governed by the Food & Drug Administration (FDA). The risk categories and terminology differ from those used by the EU MDR and MHRA. Great Britain distinguishes between SaMD and MDSW; the EU makes no distinction; the US differentiates SaMD from software that supports the function of medical hardware (SiMD). However, SaMD is categorised into four groups similar to those outlined by the IMDRF ^[6]:

• Category I: Used in the lowest threat level of health issues, e.g. software used to collect medical data
• Category II: Involved in serious conditions (e.g. blood test analysis) but not life-threatening ones
• Category III: Software deals with life-and-death situations, but the data or information isn’t time critical
• Category IV: Have the highest impact on patients and deal with life-and-death situations

Can the regulatory challenges of Software as a Medical Device be resolved?

We recently looked at some of the key differences between UK and EU MDR and the importance of international standards for medical device compliance. For developers, medical device engineers, and manufacturers, navigating this regulatory landscape is challenging, especially for products intended for global markets.

Thankfully, regulatory bodies are well aware of the challenges that a lack of harmonisation provides to developers but also for patients who can wait up to 6 months for devices to be approved before they can benefit from them.

In response, the MHRA has reaffirmed its commitment to leading the way in regulatory innovation for SaMD and published its guidance on ‘Software and AI as a Medical Device Change Program – Roadmap‘. Most of the changes are expected to be implemented by mid 2024, with solutions to the regulatory challenges of software as a medical devices provided by Work Packages. Namely ^[7]:

• WP1 Qualification: Address the lack of clarity on what qualifies an SaMD and help manufacturers to craft an ‘intended purpose’
• WP2 Classification: Reclassify software to make the rules proportionate to the risk it poses to patients; while allowing for flexibility so the risk profile for novel devices can be addressed without needlessly restricting innovation
• WP3 Premarket Requirements: Ensure a smoother path to market for manufacturers and better protection for patients/public
• WP4 Post Market: Stronger safety signals to detect and mitigate the risk of patient safety incidents, including change management systems to facilitate software update requirements
• WP5 Cyber-Secure Medical Devices: Ensures that security is built-in to SaMD development and post-market surveillance requirements
• WP9, WP10 and WP11: Relate to AI and machine learning software which is constantly evolving. This will include best-practice guidance on how to correct bias, allow for it to be human-centred, and create guiding principles on adaptivity and change management

IEC 62304:2006 is the international standard that defines the life cycle requirements for medical device software. This is a helpful standard for developers to apply when incorporating software of unknown provenance (SOUP) and other third-party software into their SaMD. This requires them to:

• Specify the functional and performance requirements of the SOUP
• Specify the hardware and software requirements
• Identify the level of segregation necessary to mitigate risk
• Verify the software architecture to ensure the correct operation of any SOUP items

By complying with international standards such as IEC 62304 and quality management systems such as ISO13485 for medical device compliance, manufacturers could reduce the complexity of regulatory requirements by applying standards that different governing bodies will accept. This may even address the challenge of finding a global device identification system that can track software throughout its life-cycle.

The FDA is proposing another solution to the regulatory challenges of SaMD: a Software Precertification Pilot Program that will certify companies that develop SaMD rather than each new SaMD product:

• Streamlines the regulatory approach and makes it more efficient
• Eases the burden of ongoing monitoring of companies and reduces the (re) submission of content to accelerate the review/compliance process
• Allows for adaptability as it accounts for software updates while ensuring they don’t affect the functionality of the device
• It gives companies that are introducing a totally new or unique product that has no predicate examples a direct path to market

Is a global approach to medical device reform possible?

Not only is it possible, but it’s also practical and implementable. Agencies such as the Global Medical Device Nomenclature and the IMDRF are working hard to provide convergence and harmonisation between governing bodies such as the FDA, MHRA, and EU MDR. The regulatory challenges of software as a medical device are numerous. Still, proposed reforms and piloting programs are encouraging: they show a strong desire to promote innovation and assert that the priority is on protecting patients by maintaining stringent regulations.

As with most things, communication is crucial. Regulatory bodies must promote and support medical device innovation and simultaneously keep users safe. Software developers and device engineers also need to ensure that regulatory bodies are kept abreast of upcoming trends and innovations – especially regarding novel technologies and new products – to help regulators anticipate changes they need to account for. This can be tricky as developers might not want to give insider information away and potentially lose their competitive edge.

What are your thoughts? Have you experienced regulatory challenges of software as a medical device? How did you overcome them? We’re always open to finding solutions to issues that impact us collectively, especially when finding the balance between innovation and compliance. Let’s chat!

1. Digital, J. (2022, February 15). SaMD, Software as a Medical Device and its challenges in regulatory. Johari Digital Healthcare Ltd. https://www.joharidigital.com/samd-software-as-a-medical-device/
2. Marciniak-Nuqui, M., Fahy, N., & Marjanovic, S. (2022, June 10). When IT Meets Medical Innovation: Regulatory and Policy Challenges for Software as a Medical Device. The Rand Corporation. https://www.rand.org/blog/2022/06/when-it-meets-medical-innovation-regulatory-and-policy.html
3. Regulatory Challenges of Software as a Medical Device (SaMD). (2020, June 9). DIA Global Forum. https://globalforum.diaglobal.org/issue/december-2019/regulatory-challenges-of-software-as-a-medical-device-samd/
4. Lee, J. (2021, December 10). What is and what is not a Software as Medical Device (SaMD)? Kvalito. https://kvalito.ch/what-is-and-what-is-not-a-software-as-medical-device-samd/
5. MDCG 2021-24 Guidance on classification of medical devices. (n.d.). European Commission: Public Health. Retrieved December 7, 2022, from https://health.ec.europa.eu/system/files/2021-10/mdcg_2021-24_en_0.pdf
6. Bencar, J. (2022, July 14). What are the 4 Risk Categories of SaMDs? The Refinery. https://the-refinery.io/blog/what-are-the-4-risk-categories-of-samds
7. Software and AI as a Medical Device Change Programme – Roadmap. (2022, October 24). GOV.UK. https://www.gov.uk/government/publications/software-and-ai-as-a-medical-device-change-programme/software-and-ai-as-a-medical-device-change-programme-roadmap