Welcome to a plain language guide on the practical aspects of Software as a Medical Device (SaMD). This guide will break down the regulatory terms and help you understand SaMD and the IEC 82304-1 standard.
What’s exciting about SaMD?
The solutions you build could play big roles in healthcare, from diagnosing diseases to predicting critical events, even steering complicated surgeries.
To make these happen, you need to walk through a maze of regulations and standards. Implementing standards is a way to meet regulatory requirements and is often more practical and straightforward than reading regulations.
This guide focuses on the product standard IEC 82304-1 applicable to SaMD and serves as a starting point when identifying high-level requirements for SaMD. For the actual development work, IEC 82304-1 refers to the life cycle standard IEC 62304, which defines requirements on “how to work” when developing software.
As a SaMD developer, you are likely tempted to use modern software development methods and technologies such as:
- Artificial intelligence (AI) and machine learning (ML)
- Continuous integration and continuous deployment (CI/CD)
- Agile methods
This article will shed some light on the two first bullet points and suggest do’s and don’ts. If you are interested in Agile, check out The illustrated guide to medical device software development and IEC 62304.
Deciphering the differences: SaMD vs traditional medical devices
Software as a medical device, SaMD, is a popular buzzword frequently used by experts and regulators. You might even think SaMD has nothing in common with traditional medical devices. But is this the case?
Let’s first understand what SaMD is, then look at what’s similar and different. By the end, you’ll be able to form your own opinion.
What is the definition of SaMD?
SaMD is defined by the International Medical Device Regulators Forum (IMDRF) as:
software intended to be used for one or more medical purposes without being part of a hardware medical device
The term SaMD is commonly used in the medical device community, but no specific regulations apply to SaMD. Nevertheless, particular guidance and standards are relevant to SaMD, and one such standard is IEC 82304-1.
How does SaMD fit into medical device regulations?
Software has existed in medical devices for several decades and has been subject to regulatory oversight for a long time. Perhaps one could argue that SaMD is new, but in the end, it is still software but without being part of a tangible medical device.
Medical device regulations disregard your choice of technology and focus on your responsibility to demonstrate that your product is safe and effective. Thus, SaMD does fit into existing medical device regulations.
Still, many perceive SaMD as a new challenge when working with medical devices – why is that?
Common misconceptions about SaMD
A common misconception is that SaMD must be managed differently from other devices to achieve regulatory compliance. One explanation is that many are used to establish regulatory evidence based on physical properties, such as weight, current, temperature, etc.
In contrast, SaMD doesn’t come with physical properties but offers other properties, for instance:
- Calculation accuracy
- Data processing times
- Image resolutions
- Data integrity protection
- Response times
SaMD properties aren’t tangible, and if you struggle to put SaMD in a regulatory context, try simplifying it by using a black-box approach. Put your SaMD inside the box, forget about the technology, and ask yourself: What has to be done to demonstrate that the device is safe?
You might be surprised by the answers because they shouldn’t be different to more traditional medical devices. Your black box device must meet regulatory expectations, such as:
- Demonstrating clinical relevance
- Complying with privacy and data protection laws and standards
- Working with risk management throughout the life cycle
- Conducting testing to demonstrate applicable requirements are met
In short, regardless of technology, you have to ensure that your product is safe and beneficial to the patient. Arguably, each type of medical device, including SaMD, has unique challenges.
For instance, devices powered by electricity have electrical safety challenges, and devices subject to sterilisation have different challenges.
What are the key distinctions between SaMD and other types of medical devices?
The development methods used to develop software, especially SaMD, are often different from other engineering fields. Hence, traditional approaches to medical device development might be challenged, for instance:
- Implementing changes and updates can be much faster in software than in traditional devices. This can cause friction between slow-paced regulatory workflows and software development teams.
- Modern software development strategies, such as Scrum or CI/CD, align poorly with traditional design control approaches, often contributing to frustration and challenges. (But they are perfectly fine to use.)
In addition to development mindsets, SaMD has capabilities not commonly seen with traditional medical devices, such as:
- SaMD can provide healthcare services remotely, accommodating patients in distant areas or with mobility issues while traditional medical devices require physical interaction.
- SaMD can be used on multiple platforms and devices, including tablets, mobile phones, computers, and the cloud, making it highly accessible and flexible.
- SaMD can be easily updated or modified to keep up with new medical research and advancements, while traditional medical devices might require substantial redesign or complete replacement.
To help overcome specific SaMD challenges, the product standard IEC 82304-1 outlines requirements for developing software that runs on general computing platforms. This makes the standard a good starting point on your path to regulatory compliance.
What is the purpose of IEC 82304-1 in relation to SaMD?
The standard IEC 82304-1 applies to health software products designed to operate on general computing platforms and are intended to be placed on the market without dedicated hardware.
IEC 82304-1 defines health software as:
software intended to be used specifically for managing, maintaining, or improving health of individual persons, or the delivery of care
Software as a medical device, SaMD, is in the scope of the health software definition and part of the lower left box in the image below.
The purpose of the IEC 82304-1 standard is to identify product requirements for health software manufacturers, such as requirements on:
- Risk management
- Product validation
- Installation instructions
- Instructions for use
Most medical devices need to meet more than one standard. This isn’t because we love standards but because each standard serves a different purpose. Some are broad, covering any type of medical device, and some are very specific.
In the image below, the standards on the left-hand side are applicable to most SaMD products and should be conformed to.
On the right-hand side, there is a list of resources you might want to pull in depending on the technology used and the specific purpose of your product.
Exploring IEC 82304-1: The standard for health software
The creation of IEC 82304-1 was fundamentally driven by the growing importance and usage of software in healthcare.
IEC 82304-1 is a product standard that complements the process standard IEC 62304 when working with health software. The difference between product and process standards is illustrated below.
When considering implementing IEC 82304-1 in your organisation, reviewing your existing quality management system is a good starting point because many requirements are likely already met. This is because IEC 82304-1 has several similar requirements to ISO 13485, for instance, on:
- Design validation
- Establishing requirements based on the intended use
The overlap between the standards exists as health software encompasses medical devices and non-medical device software. ISO 13485 and ISO 14971 are not required for non-medical device manufacturers, and they are therefore unlikely to implement them.
That is why IEC 82304-1 includes basic requirements similar to requirements already found in ISO 14971 and especially ISO 13485.
What are the benefits of the IEC 82304-1 standard?
The primary benefit of implementing the standard is in section 7: “Health software product identification and accompanying documents”.
At first glance, some might perceive the content as overwhelming and too granular with many details. But the devil is in the details, so don’t be discouraged.
If you invest time in identifying applicable IEC 82304-1 documentation requirements, you will likely find yourself in a convenient situation when it is time to prepare submission documentation. Meeting the requirements of IEC 82304-1 will help satisfy many requirements found in:
- Annex I of the MDR and IVDR – General Safety and Performance Requirements (GSPR)
- FDA guidance documents for 510(k) submission
To give you some ideas about what to expect in IEC 82304-1, the requirements on instructions for use are illustrated in the figure below.
In summary, the instructions for use shall address necessary activities throughout the life cycle.
How do you develop SaMD following IEC 82304-1?
The standard IEC 82304-1 does not have specific requirements for software development; it references the standard IEC 62304, a life cycle standard for developing medical device software.
In the IEC 62304, there are no requirements on development methods, but you will find several requirements on the development process, for instance:
- Defining what development methodology you use,
- Establishing requirements, and
- Working with software risk management
Continuous integration and deployment is a popular approach to modern software development. While continuous integration can be considered a good practice when working with SaMD, a word of caution is justified when considering continuous deployment.
Fully implemented, continuous deployment can be automated to push new software releases into operation daily or hourly. While in operation, monitoring ensures that problems are detected, quickly fed back to development, and promptly fixed in the next deployment. The concept is excellent, but in a medical device context, it might not always be desirable because:
- Documentation must match
Any release to the end-user must be documented as a product release, including updated documentation, such as instructions for use and applicable installation documentation. - The end-user is not a guinea pig
Fixing software problems promptly is excellent. However, fixing problems is not the priority in medical device development – there should be no problems in the first place! So, even if a solid CI/CD aims to create high-quality software by being responsive, this doesn’t suffice for medical devices where safety should be proactive.
You might want to consider continuous delivery as an alternative to continuous deployment.
Continuous delivery is automatically building and preparing code changes for deployment, but not necessarily deploying them automatically. Continuous delivery allows for more manual control over the release process and can involve testing code in a staging environment before releasing it to production.
Does design transfer apply to SaMD?
Whether design transfer applies to software and SaMD, in particular, can be debatable. Neither IEC 82304-1 nor IEC 62304 mentions anything about design transfer, but it is an important activity of ISO 13485 (clause 7.3.8):
The organization shall document procedures for transfer of design and development outputs to manufacturing. These procedures shall ensure that design and development outputs are verified manufacturing. These procedures shall ensure that design and development outputs are verified as suitable for manufacturing before becoming final production specifications and that production capability can meet product requirements.
Design transfer applies to software because you should confirm that the software you have verified and validated meets the product requirements once installed in its operating environment.
There is no blueprint for the perfect SaMD design transfer, but a few examples are illustrated below.
Artificial intelligence
With the growth of computational power, artificial intelligence (AI) has become a viable design solution for many applications, including medical devices. Although AI can be implemented in any medical device software, SaMD applications are predominant, as seen in the number of FDA submissions over the past few years.
In 2019, the FDA received over 200 submissions for AI/ML-based SaMD.
When discussing AI and machine learning (ML) in medical devices, it is key to understand the difference between locked systems and adaptive systems. As of today, all medical device systems implementing any type of AI technology are locked systems, meaning they cannot change after release.
It is reasonable to assume that AI-based medical devices will remain locked systems for the foreseeable future. Imagine the challenges of a medical device that changes its characteristics on its own after release. How should you, for instance, ensure:
- Clinical performance
- Safety
- Security
Regulators acknowledge the need to update AI-based applications and eventually re-train based on new data – without requiring new submissions. However, such updates are still expected to happen under controlled circumstances and are not supposed to be autonomously initiated by the device.
Several regulators are working on a risk and evidence-based approach to managing changes for machine learning-enabled devices. This approach is referred to as predetermined change control plans.
How does machine learning play a role in SaMD?
There are different potential use cases of AI in SaMD development. In the following sections, you will find a few examples of how AI could be used when working with SaMD.
AI, your digital development assistant
It is no secret that software engineers occasionally use search engines to solve coding problems. With the introduction of new large language models (LLM), like ChatGPT, digital assistants will probably become very common. Imagine having an LLM as a peer reviewer of software code.
Using AI to assist with regulatory challenges
This area is still relatively new, but LLMs are popping up, assisting in phrasing design input requirements and relevant design verification test cases.
Some LLMs assist in reviewing public information, for instance, regulations and associated guidance documents.
Generating test data
Using simulation when developing and testing software is a well-established way of working. For instance, a unit test framework with a predefined stimulus should result in predictable behaviour. Some applications might benefit from the power of machine learning to generate new test patterns, which otherwise would be hard to establish.
Using AI in a device
AI and ML algorithms are often used in SaMD to analyse large amounts of data quickly and accurately. For instance, they can be used to detect patterns or anomalies in medical images, predict patient outcomes based on historical data, or even recommend treatment options.
How do you document the use of AI and ML in SaMD?
The use of AI and ML in SaMD presents certain challenges. These technologies are complex, and their decision-making processes can be difficult to understand, even for experts. This can make it challenging to ensure that SaMD is safe and effective.
Since AI algorithms often provide a significant part of the intended use, it is a good idea to use clinical relevance in the design of your test strategy and identify relevant acceptance criteria.
As it happens, the International Medical Device Regulators Forum (IMDRF) has issued guidance on SaMD clinical evaluation, which also has been adopted as an FDA guidance. In the EU, the IMDRF guide has influenced the establishment of MDCG 2020-1.
In summary, the IMDRF guidance focuses on the following three areas:
- Valid clinical association
- Analytical validation
- Clinical validation
A practical approach to documenting information relevant to a clinical evaluation is to leverage the standards IEC 82304-1 and IEC 62304, as illustrated in the image below.
As a product standard, IEC 82304-1 should assist you in answering questions related to valid clinical associations and clinical validation. The standard requires identifying the following information, giving you a good starting point for establishing a valid clinical association.
- Product requirements
- Intended use
- Intended user profile
Furthermore, clinical validation is supported by IEC 82304-1 by requiring you to identify the following:
- Validation methods
- Acceptance criteria
- Validation activities
Documentation for the analytical validation is likely to be an output of applying the IEC 62304 standard focusing on the following three steps:
1. Software requirements
IEC 62304 requires you to establish software requirements, and they should preferably detail the functional and capability requirements of your AI/ML features.
2. Software testing
Tests shall be established, including input stimuli, and expected outcomes. Furthermore, the test strategies shall be evaluated for adequacy; for instance, are your test stimuli representative of the intended user profile?
3. How was the algorithm developed?
Documenting how algorithms are trained and especially the data used to train and validate algorithms is vital. Not only for future maintenance but you will also likely be asked about such information in regulatory submissions.
What is the future of SaMD?
The medical device market is continuously growing and SaMD is a big contributor to this trend.
By 2025, the global market for SaMD is projected to reach $86.5 billion.
With increased computational power, software applications become increasingly advanced and sophisticated.
Any sufficiently advanced technology is equivalent to magic.Arthur C. Clarke
In the context of medical devices, software will not only help offer better care but can also result in significant cost savings.
AI and ML are expected to contribute $150 billion in annual savings for the healthcare industry by 2026.
While artificial intelligence has a lot to offer, it is hungry for data. Relevant data is key to train AI to become awesome products. To train future algorithms there will be an increasing demand in patient cases, and eventually patient records.
This demand for data will likely trigger challenging discussions concerning confidentiality and integrity versus the value of developing even better medical devices – a new kind benefit-risk evaluation.
Over the years, regulations have been updated with new requirements. In the EU, there has been many significant changes with the introduction of several regulations relevant to SaMD:
- MDR
- IVDR
- Cybersecurity
- AI act (in progress)
Similarly, regulatory requirements are rapidly being updated also in other regions. For instance, the FDA is continuously raising the bar on both cybersecurity and AI.
In summary, the future for SaMD is promising but SaMD applicable regulatory requirements are not likely to become easier.
