.png)
Why authorities will soon be paying closer attention to software – and what SaMD manufacturers should be doing now.
Quite a few things will change in the next few years for manufacturers of medical software. The market for IT solutions in the healthcare sector is booming. Between 2017 and 2022 alone, revenue projections have almost quadrupled from $41 billion to $158 billion. This is first and foremost good news but is not without its drawbacks: the enormous growth is sparking regulatory authorities into action. New regulations are springing up like mushrooms, and existing regulations are being monitored ever more closely.
It is time to take a closer look at the legal regulations governing healthcare software and how to avoid the most common mistakes.
How strictly software is regulated depends, first of all, on whether or not it actually qualifies as a medical device. This depends on the intended purpose: if software fulfils a medical purpose, it is generally a medical device.
However, software as a medical device (SaMD) should not be confused with what is known as “health software”. While SaMD is strictly regulated, health software is more of a wellness tool and, therefore, has to comply with lower requirements.
Example: software that analyses cardiac arrhythmias
Example: fitness app that tracks exercise progress
At this point, we are only interested in software as a medical device, since the strict rules that apply to medical devices also apply here.
Such medical software can be subdivided into two variants:
While SiMD is treated as part of the physical medical device, SaMD is an independent medical device.
Software as a medical device differs significantly from ‘conventional’ software. SaMD and SiMD all over the world are subject to strict safety and performance requirements. Manufacturers should not underestimate the extra work and costs involved. This means they should also plan more time for development.
The following features of SaMD and SiMD are particularly worth noting:
You must comply with the legal regulations that apply in the market you want to sell your device in. In Europe, that would be the “Medical Device Regulation” (MDR), and in the USA, the “Guidance for the Content of Premarket Submissions for Software Contained in Medical Devices”.
Both the MDR and FDA have established strict requirements for software that is a medical device. You should make sure you familiarise yourself with them.
Manufacturers must also align their market strategy with these requirements. Before starting development, decide which market you want to place your device on. Otherwise, you will have to adapt the software to the legal requirements afterwards, and that costs time and a lot of money.
The SaMD or SiMD development process as a whole differs from that of conventional software.
The documentation requirements for medical devices are very extensive.
You must set up a process model as per IEC 62304. But be careful! IEC 62304 does not specify exactly what this should look like. Manufacturers have to decide on its specific design themselves.
You must demonstrate the clinical benefit of your medical software. This requires either a clinical study or a clinical evaluation.
After placing their devices on the market, SaMD and SiMD manufacturers must establish post-market surveillance and, if necessary, react to any problems with their software.
A lot of medical software manufacturers are not sure exactly what the requirements that apply to their devices are. With tighter controls, they could soon run into nasty surprises. You can avoid the most common mistakes by following the tips below:
The scope is derived from factors including the software security classification.
If the ‘scope of the software’ file does not meet the regulatory requirements, this will be noticed, at the latest, during the next audit. This means that you will have to create the documentation later, which will involve considerable additional time and cost.
Design your software so that the specifications are testable. The system must be specified from a black box perspective. A status that is not visible from the outside has no business being in system or software specifications. (e.g. insulin pump software specifies the pump must go into standby mode when insulin levels are too high, but the status of the insulin pump is not visible to a software tester, nor is a switch to standby mode testable. It would be better for the software to specify that ‘if the insulin level is above a defined value visible on the user interface, no more insulin may be delivered’)
If the software architecture is not easy to understand and not consistent, you will not be able to maintain and troubleshoot your software. This is particularly critical in the medical sector, where people's health is at stake. In the worst case, your device will no longer be usable. Therefore, keep the architecture as consistent and understandable as possible.
Just as you do for your hardware, you should create a bill of materials for your software. Software bills of materials (SBOMs) list all software components in a piece of software. This allows you, as a manufacturer, to ensure that the components are up to date and to react quickly to new vulnerabilities.
Make sure you fill all the roles in your development plan correctly. Software developers should not be responsible for preparing the failure modes and effects analysis (FMEA). That involves evaluating risks! That is not the developer's job. Their job is to spot software errors.
There are currently a lot of misunderstandings regarding the exact requirements for medical software. This is mainly because existing sources are not known well enough or are being misinterpreted. This results in common errors that have often gone unnoticed until now. But SaMD and SiMD manufacturers can no longer rely on inaccuracies continuing to fly under the radar.
The boom in the medical software market is leading to stricter regulations and the authorities being more alert. That in turn can lead to nasty surprises when entering the European or US market, if not before. In the worst case, the device will no longer be usable.
To ensure this does not happen to you, you should find out what the exact requirements are and, if you have any doubts, consult medical software experts.
______________________
The HealthTech Activator is hosting an online tutorial, Regulations and QMS for Software as a Medical Device, on March 29, 2022. You can register here.
.png)
