In recent years the world of computing has seen many advances. With the emergence of cloud computing, immersive smartphone applications and wearable technologies, it’s not surprising that we’re seeing software driving innovations in medical applications and a rise in Software as a Medical Device (SaMD).
When something is classed as Software as a Medical Device, the ‘software’ is the medical device in its own right and is independent of any bespoke hardware.
An example of SaMD would be a system which uses a machine learning model hosted in the cloud to evaluate photographs of potentially cancerous skin growths. In this example, only the software components were designed with a medical purpose in mind – the smartphone and cloud servers were not designed specifically to accommodate software systems such as SaMD.
This contrasts with Software in a Medical Device (SiMD), the more traditional type of medical device. In SiMD, the software operates on a hardware platform specifically designed to be a medical device – in other words, the software is only part of the medical device.
Having identified the difference between SaMD and SiMD, what do you need to know about SaMD applications? As with any medical device development, SaMD is heavily regulated. This article will focus on the EU Medical Device Regulations (MDR) and highlight any important differences with the FDA’s 21 CFR 820 requirements. The UK is different again, requiring a UK CA mark. However, for SaMD applications, you can address the UK requirements by satisfying the EU MDR.
If your application isn’t considered a ‘medical device’ then your efforts to reach the market can be significantly reduced; you won’t need to prove compliance with medical regulations and standards. So how do you know if the software you are developing should be considered a medical device?
There are nuances for each region. In the EU, the definition is quite long (and very descriptive), but it can be summarised as anything which has an intentional medical function or purpose, including accessories to medical devices. As an example, if a device measures heart rate for the purposes of fitness/sports tracking this would not be considered a medical device. The MDCG has published an exceptionally useful flowchart to help determine if your application is considered a medical device or not. In brief, if the software is considered an ‘accessory’ to a medical device (e.g. a supporting app), or meets any of the definitions of a medical device, then you will need to comply with the MDR.
For region specific guidance and requirements, look to regulators or guidance organisations for more information, for example:
The MDR defines a range of legal requirements for Software as a Medical Device, in addition to the General Safety and Performance Requirements (GSPRs) for all medical devices. The key GSPRs which relate to SaMD include the need for:
The phrase ‘state of the art’ is used in the MDR in many sections and is an important definition to understand. It does not mean “the best of the best”, or even “novel”. In essence, it means “the industry accepted norms” and allows the development environment to continuously improve without re-writing the regulations. Regarding SaMD, international standards can help to understand what the state of the art is. There are two key standards:
The FDA now accepts IEC 62304 as a relevant lifecycle standard but has some discrepancies in its documentation expectations, which will be discussed next.
A key component of IEC 62304 and the FDA requirements for software is the different classes of software which are based on the potential harms which the software can cause to patients or users. The FDA has a slightly different terminology and refers to “level of documentation” in much of its guidance.
You can see from the descriptions in the table above that the software safety classes are related to the severity of harm associated with a potential failure. This increase in software classification directly relates to the level of documentation and rigor which will be expected by the regulators.
It’s important to note that if you are submitting within the FDA, regardless of the safety classification you will need to produce detailed design documentation, normally associated with Class C software. However, it is worth noting this is not normally required as part of the design history file submission. Additionally, as the FDA only has two levels of documentation, there is no distinction between the documentation submitted for review for Class A or Class B software items.
A word of warning about the document types which you have to produce for each software safety class: the level of detail in these documents takes a significant amount of time, particularly producing detailed design descriptions of your software units.
It’s also important to note that if your software is considered software as an in vitro diagnostic (IVD) and is being developed under the IVD regulations (IVDR), your safety class is defined by the device’s assay and its inherent risk. As a rule of thumb, the software safety class aligns with the IVDR assay class.
We have mentioned SOUP/OTS items in passing here. For the purposes of this discussion you need to be aware that if you use SOUP, you need to evaluate it against technical and quality requirements. We have a series of more detailed articles to help understand SOUP evaluation.
It’s exceptionally unlikely that your Software as a Medical Device application will be isolated from cybersecurity threats. It may be running on a smartphone, a PC, or on a remote server. Each of these environments provide external networking capability and will store data locally. There are a few important things to do in order to keep your SaMD cyber secure:
Cybersecurity management is a continuous process. Once your software is released, you need to monitor for emerging threats for any platform changes.
It’s important to note that the USA has a zero-tolerance approach with cybersecurity vulnerabilities. If you identify a vulnerability in your system, you must remove the vulnerability even if it has alternative means of protection. New requirements for US submission are defined in the 2022 PATCH Act.
Risk evaluation and management is a key component of SaMD development. In brief, the aim is to examine how the software can lead to a hazardous situation which would affect the patient or operator. We need to demonstrate that we have followed a state-of-the-art process for identifying and mitigating risks in Software as a Medical Device applications, which can be done by showing compliance with ISO 14971.
When evaluating software risks, we need to remember that software is simply a series of instructions which process data. Therefore, any failures in the software are “baked in” – given the right conditions, the failures will occur. This is different to a traditional device failure, where the development team can investigate the probability of a given failure mode.
It’s for this reason that, when evaluating software risks, we assume that the failure will happen at some point and identify mitigations which eliminate the risk. By taking this approach, software developers can work to eliminate software risks, rather than assuming that they will never happen.
For more guidance, it is useful to look through TR 80002-1, a technical note which helps you to understand how to apply ISO 14971 to software. It identifies common software hazards and applicable mitigations for them. You can use tools to help detect common faults, for example the use of static analysis tools to detect common run-time errors. Some common errors to consider are:
A key concept within IEC 62304 is the need to identify your software development lifecycle. This is essentially the way you plan to tackle software development. You will need to identify the phases of your software lifecycle, the activities you will perform and the deliverables from each development phase.
Your lifecycle needs to identify when you will perform the activities described in IEC 62304: planning, requirements capture, architecture design, detailed design, unit implementation, verification and release. Bear in mind that your development lifecycle should be structured around your team and the way you develop software in practice. It’s not best practice to define a lifecycle which you will never follow.
Here are a few examples of software development lifecycles and their relative strengths and weaknesses:
This is the traditional way of delivering software projects, particularly in the medical space. In this lifecycle, you transition linearly between development phases. It aligns well with the V-model for verification. In well understood software programs, Waterfall presents a logical way to develop the software, ensuring control at all stages.
However, in cases where the software is not well defined at the project outset, the approach presents some challenges. A change to requirements will involve having to return through the requirements phase and complete all subsequent phases again. It can become slow to adapt.
Agile is an incremental lifecycle type where all project aspects progress in an evolutionary manner. To explain this: the requirements, design and code for a given feature can be recorded in the same increment. This allows developers to focus on the needs of the specific feature.
The downside of this “pure” incremental approach is that development teams may not consider all features within the architecture, which can lead to features integrating poorly within your software. This can be resolved by re-implementing the software. The basis of an agile lifecycle is that the software develops in an evolutionary manner.
At Team Consulting, we work around the issues of both Agile and Waterfall methodologies by following the lifecycle method described in TR-45. The early stages of a project progress in a linear manner, but do not fully define the software.
For example, in the requirements phase, we will capture the functional and key performance requirements, but will not exhaustively list the risk mitigations. Similarly, the architecture phase will identify the key components and their interactions, but will not be fully defined until the implementation phase when the development team is able to implement and adapt the architecture.
This hybrid approach allows the development team to define the software to a high level before starting to implement it.
We’ve now comprehensively discussed the regulatory requirements for developing Software as a Medical Device, but what are the best practices which really help us to show that we’re developing software to the state of the art?
For developers, a well-defined (and applied) coding standard helps to improve the quality of the code we write. During code reviews, it helps us to focus on the function of the software, rather than trying to interpret what another developer has implemented. This helps with spotting errors and areas for improvement. Having better clarity of the code also reduces the number of bugs which make it into the codebase, preventing unexpected hazards from arising.
Code coverage tools help us to identify areas of code which have not been fully tested. This has several benefits in SaMD. Firstly, it acts as a reminder to produce tests which assess the performance of the code. It can also help us to identify unreachable code, which can pose risks to patients and users if it is triggered due to software errors. Unreachable code should be removed wherever possible.
In brief, this is software which is testing software. Automated testing allows you to quickly and repeatably assess the behaviour and performance of your software. It is particularly useful for regression tests where you are looking for a drop in performance after a software change. Automated testing isn’t a requirement for SaMD development but is one of the most helpful tools for your development team.
For the purpose of this blog, we’ll stick to Machine Learning (ML) as a concept, rather than Artificial Intelligence (AI), as “true” AI examples are rather limited. At a very high-level, ML involves the use of a “trained” statistical model which will be used to interpret data and return some form of analysis. The ML model is developed by providing a labelled training data set and validate it by using a test data set.
It is critical that your training and testing data sets are well defined, have a statistically significant number of samples and have been checked for bias, amongst other things. Critically, you need to confirm that the requirements for the ML model are well defined, so that you can confirm it is functioning as you expect it to. Ensure to use a large enough data set so to confirm that there is no unintended behaviour.
Given that AI and ML are “hot topics”, you should also be aware of emerging regulations which affect AI and ML. In 2023, the AI act came into force in the EU, with potentially far reaching consequences for medical applications which fall in the definition of an AI application.
For a wider discussion on the topic, read our other articles on AI and ML.
Having developed, verified and validated your SaMD application, you will need to submit your product’s technical file to a partner notified body in the EU. In the US, you submit your design history file to the FDA as part of a pre-market submission.
The technical file contains the latest versions of all documents associated with the medical device design, development process, and testing. It encompasses the latest versions of all documents and is used to show compliance with the MDR. Under the MDR this technical file submission needs to be clear and easily searchable.
The design history file, as submitted to the FDA, is subtly different. In addition to the technical file documents it also encompasses the full history of the device development. This design history file allows the FDA to confirm that your development process was under control throughout the development process. The phrase under control essentially means that you were meeting your QA requirements throughout the product development cycle.
Hopefully this article has given you an overview of the things you need to consider when developing Software as a Medical Device applications. Try to remember a few key things:
Looking for industry insights? Click below to get our opinions and thoughts into the world of medical devices and healthcare.
