Are there global regulations for Software as a Medical Device?

What do we talk about when we talk about SaMD?

Software as a Medical Device (SaMD) – is 1 of 3 types of software related to medical devices. The other 2 are software that is integral to a medical device (Software in a medical device) and software used in the manufacturing or maintenance of a medical device.

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." A legally binding description published in 2013.

Why is that definition important? 
Firstly, it applies to various technologies, from electronic medical records and medical device platforms to remote patient monitoring solutions and virtual networks. Secondly, IDFR makes up most of the global markets, with the members being (in alphabetical order) Australia, Brazil, Canada, China, the European Union, Japan, Russia, Singapore, South Korea, the United Kingdom, and the USA.

Similar organizations navigating healthcare software regulations in other parts of the world are the African Medical Device Forum (AMDF); the South African Health Products Regulatory Authority (SAHPRA), and the Taiwan Food and Drug Administration (TFDA).

Do I need to fulfill SaMD regulations? 

According to the IDFR definition, if your project is “intended for one or more medical purposes” and “performs these purposes without being part of a hardware medical device” - then yes.

Operating systems that do not meet the definition of SaMD are 
- solutions whose “intended purpose is to drive a hardware medical device.”
- used in combination (e.g., as a module) with other products including medical devices.

In practice, to know where you stand, you need to define your product’s intended use (purpose of the solution and what it will be used for) and indications for use (specific conditions that your app will tackle). But if you’re unsure where your healthcare software fits in these legal regulations, it’s best to contact the right institution directly. 

Depending on your location and where you want to release your solution, it would be…

Medical device regulatory authorities worldwide

…the matter of reaching out to the right medical device regulatory authority. 
In alphabetical order:

• Australia: Therapeutic Goods Administration
• Brazil: National Health Surveillance Agency (ANVISA)
• Canada: Health Canada
• China: National Medical Products Administration
• European Union: European Commission - Directorate-General for Health and Food Safety
• Japan: Pharmaceutical and Medical Devices Agency (PMDA)
• Russia: Russian Ministry of Health
• Singapore: Health Sciences Authority
• South Korea: Ministry  of  Food and Drug Safety
• United States: U.S. Food and Drug Administration (FDA)

Aiming to ensure quality standards and policy unity globally, beyond IDFR and its members, there are plenty of renowned institutions collaborating and regulating the IDFR itself. The World Health Organization (WHO); Swissmedic; Argentina, National Administration of Drugs, Food and Medical Devices have the status of Official Observers.  And “Regional harmonization initiatives”, such as APEC LSIF Regulatory Harmonization Steering Committee; Global Harmonization Working Party (GHWP); Pan American Health Organization (PAHO); and African Medical Devices Forum (AMDF) – among others. 

In practice, this means that your healthcare software needs to meet regulations of, well, two-and-a-half regulatory bodies and gives you at least three points of contact: 
- IDFR (for software as medical device global guidelines), 
- local authorities (for regulations in specific locations), 
- and external institutions overseeing both. 

Naturally, no matter the stage of your development, you can learn from other solutions that are already available on the market. Here are 2 examples that are *not* software as a medical device and 2 that are SaMD.

Examples of applications *not* classified as MSD
- Software embedded in the medical hardware device. That’s glucose meters, insulin pumps, and defibrillators, among others.

It’s the kind of software that does not act as a medical device on its own. Instead, it analyzes and monitors the performance or functioning of the medical device itself. Notifying owners, doctors or technicians about the time to service or replace the device.

- Software allowing for clinical communication and workflow. That includes . 

Again, these applications do not act as medical devices on their own. Instead, they support patients and users in reaching healthcare providers.

Examples of software that *is* classified as MSD
- Any health monitoring apps. That’s mobile applications that not only collect, but also interpret health data. Whether it’s your apple watch or any app installed on your smartphone, it’s solutions that offer you individualized recommendations, and advise on your sleep patterns to exercise routines. 

In Untitled Kingdom, we have developed FemTech (female technology) – from an app for smart menstrual cup and diagnosis device for pelvic assessment to an online endometriosis education toolset.

- Any online diagnostic tools. That’s any algorithm that analyzes health data – from medical images, (MRIs or X-rays) to offering personalized treatment options. Such as Untitled Kingdom’s software for wireless ultrasound, patient companion apps, and remote patient monitoring app for Remedee Labs.

____

And naturally, with many examples to learn from, you do not need to face these regulations alone. For starters, you can book a free online consultation and learn how to navigate the development of your medical software further.

Resources & further reading:

• FDA documents - accessed December 20, 2023 - HERE
• Is your software a medical device? - guideline issued by European Commission - accessed December 20, 2023 - HERE