The latest technological advances mean that connectivity is now considered default and as a result, we are now able to freely exchange data between different devices, servers and cloud platforms. The medical industry has always been at the forefront of this movement – with its responsibility for patients’ life and health comes the question of security and quality of the developed products.
Consequently, this technological progress allowed for more advanced healthcare products and services, including software which is now not a mere addition to physical appliances but a standalone element that can support the diagnosis process, treatment and long-term rehabilitation for patients as well as for monitoring and emergency care purposes. Following this increase in medical digital products, there’s also been a growing need for the sector to be regulated.
This is how the idea behind Software as a Medical Device was born.
What is Software as a Medical Device?
Software as a Medical Device is – in words of the International Medical Device Regulators Forum which is a voluntary group of healthcare experts working towards unifying the medical device regulations around the world – ‘a software intended to be used for one or more medical purposes that perform these purposes without being part of a hardware medical device’.
In short, Software as a Medical is – by definition – software that can serve as a standalone medical device. It’s worth mentioning that software, which is a part of any medical device is a Software in Medical Device (also known as SiMD) – more on that distinction later in this article. SiMD is widely used for medical devices – in some of them, it’s employed to operate the device or allow users to interact with the device using touch screens.
For software to be classified as a medical device, it needs to serve as such, meaning to support the diagnostics or treatment process. It can also collect data, send them to the cloud and make predictions on the progress of a certain disease or a condition or visualise certain vital human organs based on this data, including images or MRI scan results.
The most comprehensive definition of Software as a Medical Device is covered by the EU Medical Device Regulation (MDR) that came into force in May 2021. Its article 2, point 1 clearly defines that a medical device is an appliance or software that can be employed for any of these medical uses: diagnostics, preventive treatment, monitoring, prediction, prognostics, treatment or compensation of illness, injury or disability. A medical device can be used in these cases without the need for pharmaceutical drugs.
What are the benefits of SaMD
Thanks to its versatility, Software as a Medical Device can be used to support and accelerate innovation in other healthcare domains such as medical treatment and medical devices. With SaMD, healthcare professionals can collect data from multiple sources at once and manually which as a result, leads to shortening the time needed to diagnose a patient or to check how they respond to a certain procedure. SaMD can be also used for identifying patterns and trends in the collected data so it’s much easier to spot any areas for improvement and any occurring events or casualties.
SaMD vs SiMD
Our Healthcare and Life Science Business Unit Director, Krzysztof Minicki puts it simply:
“If software is a standalone independent product that can be installed on any device – be it a computer or a smartphone – as an online platform or a web/mobile app, then we can safely say it’s a Software as a Medical Device. If software is a part of a device i.e. as an operating system, then it’s Software in Medical Device.’
How is Software as a Medical Device regulated?
The primary organisation regulating Software as a Medical Device is the above-mentioned International Medical Device Regulators Forum that’s also responsible for presenting the classification of SaMD and labelling it on a global level.
Another institution regulating this sector is the U.S. Food and Drug Administration that published several guidelines for manufacturers and distributors of Software as a Medical Device. According to Krzysztof Minicki, the US approach is no different from what is already defined in the EU MDR.
The most important element of each of these regulations is a risk classification framework for medical devices, including software. This risk can be considered on 3 different levels that are directly related to the MDR classification system:
- Informative level – software is used for collecting data and supporting the diagnosis and treatment processes;
- So-called drive level where software can be used to manage the device, but it doesn’t make decisions on its own
- Treatment/diagnostics with software supporting and working closely with a GP but also making decisions independently.
Check our article on MDR regulations and classification on our blog —> EU MDR: what you need to know about Medical Device Regulation in 2021
Additional regulations are also determined by the IMDRF – they’re related to risk management strategies and software development Quality Management in the process of building Software as a Medical Device.
Read more about the IEC 62304 that regulated the medical software development process –> IEC 62304:2006 – software life cycle processes explained
Where should manufacturers and software suppliers start if they want to develop SaMD
Hence, Krzysztof Minicki mentions that the very first step for any manufacturer/software supplier to start producing Software as a Medical Device is a complete and comprehensive implementation of the Quality Management systems based on the ISO 13485 regulations which for both SaMD and SiMD requires the introduction of the IEC 62304 standard as well as the medical device risk management norm, ISO 14971. The foundation of the successful SaMD development process should always be the standards that are widely recognised and equally widely used in the software development sector. In this stage, these procedures do not need to be validated by certificates as the manufacturers can obtain these as they launch their first product.
In this case, the lack of certification will mean that the aspiring SaMD development companies will need to go through two types of audits. The first one is required for verifying the software development process and the Quality management procedures, including the necessary documentation. The second audit validates how these processes and procedures are used in practice as the actual software is being developed.
Over to you
Not sure to implement the Quality Management System and following procedures? At Spyrosoft, we already have completed the certification process and we are willing to share what we know and support your company as it introduces the standards.
Please check our Healthcare and Life Science website for more information and do not hesitate to contact us should you have any questions.
About the author