Blog 12 min read

Navigating The World of Medical Software

Mar 06, 2023 Navigating The World of Medical Software

Understanding SaMD, MDSW, and Device-Driving Software

As the healthcare industry becomes increasingly reliant on software technology, it’s crucial to understand the differences between various types of medical software and the regulatory requirements associated with each. Software as a Medical Device (SaMD), Medical Device Software (MDSW), and Software that drives or influences medical device use are three such categories. Each category has its own regulatory requirements that must be met to ensure safety and efficacy and understanding the distinctions between each category is crucial for manufacturers, regulatory bodies, and healthcare providers to ensure compliance and the safety of patients.

The International Medical Device Regulators Forum (IMDRF) published guidance on Software as a Medical Device (SaMD) which includes key definitions, however, this is only guidance, as the definition of Software as a Medical Device (SaMD) can vary from country to country. The IMDRF guideline states that:

“Software as a Medical Device” (SaMD) 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.” 

 However, some countries have their specific definitions, and in the EU, the term medical device software (MDSW) is used. The EU Medical Device Regulation 745 (MDR), defines the term Medical Device Software (MDSW), under Classification rules;

“Software intended to provide information which is used to take decisions with diagnosis or therapeutic purposes is classified as class IIa, except if such decisions have an impact that may cause: — death or an irreversible deterioration of a person’s state of health, in which case it is in class III; or — a serious deterioration of a person’s state of health or a surgical intervention, in which case it is classified as class IIb. Software intended to monitor physiological processes is classified as class IIa, except if it is intended for monitoring of vital physiological parameters, where the nature of variations of those parameters is such that it could result in immediate danger to the patient, in which case it is classified as class IIb. All other software is classified as class I.”

The MDCG 2019-11 guidance document on ‘Guidance on Qualification and Classification of Software in Regulation (EU) 2017/745 – MDR  and Regulation (EU) 2017/746 – IVDR‘ also helps in this regard.  Medical Device Software (MDSW) is defined as “software that is intended to be used, alone or in combination, for a purpose as specified in the definition of a medical device in the medical devices regulation or in vitro diagnostic medical devices regulation.” Other useful guidance documents include MDCG 2021-24 – Guidance on classification of medical devices, MDCG 2020-1 – Guidance on clinical evaluation and performance evaluation of medical device software, and MDCG 2019-16 – Guidance on cybersecurity for medical devices.

In the USA, Software as a Medical Device (SaMD) is software that meets:

  • the definition of a device in section 201(h) of the FD&C Act
  • is intended to be used for one or more medical purposes without being part of a hardware device

While Software in a Medical Device (SiMD) is:

  • Software that meets the definition of a device in section 201(h) of the FD&C Act
  • used to control a hardware device or is necessary for a hardware device to achieve its intended use

Typically, SiMD is embedded within or is part of a hardware device, as per Content of Premarket Submissions for Device Software Functions, Draft Guidance. Per section 201(h) of the FD&C Act(h). The term ‘‘device’’ (except when used in paragraph (n) of this section and in sections 301(i), 403(f), 502(c), and 602(c)) means an instrument, apparatus, implement, machine, contrivance, implant, in vitro reagent, or another similar or related article, including any component, part, or accessory, which is:

  • recognized in the official National Formulary, or the United States Pharmacopeia, or any supplement to them
  • intended for use in the diagnosis of disease or other conditions, or in the cure, mitigation, treatment, or prevention of disease, in man or other animals
  • intended to affect the structure or any function of the body of man or other animals, and which does not achieve its primary intended purposes through chemical action within or on the body of man or other animals and which is not dependent upon being metabolized for the achievement of its primary intended purposes.

The term ‘‘device’’ does not include software functions excluded pursuant to section 520(o).

This definition, along with the FDA guidance on Policy for Device Software Functions and Mobile Medical Applications, provides guidance on which software functions the FDA considers to be a medical device. After careful analysis of the definition of SaMD from the IMDRF and FDA, we know that software that is used to power hardware or drive a hardware device, does not meet the criteria for SaMD. This type of software is what’s known as SiMD, or “software in a medical device” and includes any software that helps to run a hardware medical device, by powering its mechanics for example.

In order for a product to be classified as SaMD, the software must operate separately from any hardware when it performs its functions. The IMDRF guidance on ‘Possible Framework for Risk Categorization and Corresponding Considerations’ adds valuable information to this point. Furthermore, MDSW does not include software that is used only to drive or influence the use of medical devices. 

As these types of software continue to play an increasingly important role in healthcare, it is important for stakeholders across the industry to understand the regulatory requirements associated with each category. By doing so, manufacturers can develop safe and effective medical software, regulatory bodies can ensure compliance with established standards, and healthcare providers can confidently use medical software to improve patient outcomes. Ultimately, by understanding these distinctions and working together to meet regulatory requirements, we can help to ensure the safety and efficacy of medical software, and improve the quality of care delivered to patients.

Stay Ahead Of The Evolving Regulatory Landscape in Medical Devices:

Unlock Market Access

Accelerate your ability to achieve, maintain & expand market access for all medical device products in global markets with C2P. C2P is your key to unlocking market access, and is trusted by more than 300 of the world’s leading brands. C2P is an enterprise SaaS platform providing everything you need in one place to achieve your business objectives by proving compliance in over 195 countries.

C2P is purpose-built to be tailored to your specific needs with comprehensive capabilities that enable enterprise-wide management of regulations, standards, requirements and evidence. Add-on packages help accelerate market access through use-case-specific solutions, global regulatory content, a global team of subject matter experts and professional services. 

  • Accelerate time-to-market for products
  • Reduce non-compliance risks that impact your ability to meet business goals and cause reputational damage
  • Enable business continuity by digitizing your compliance process and building corporate memory
  • Improve efficiency and enable your team to focus on business critical initiatives rather than manual tasks
  • Save time with access to Compliance & Risks’ extensive Knowledge Partner network

Contact us to speak to one of our team today to learn how you can simplify your compliance process. For more information, please visit www.complianceandrisks.com

Interested in knowing more about the specific solutions that C2P has to offer for your compliance needs?

Talk to us to know more.