Menu
Menu
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:
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.
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.
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.
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?
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:
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:
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.
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:
In addition to development mindsets, SaMD has capabilities not commonly seen with traditional medical devices, such as:
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.
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:
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.
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:
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.
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:
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.
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:
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:
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.
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.
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:
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.
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.
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.
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.
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.
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.
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:
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.
Furthermore, clinical validation is supported by IEC 82304-1 by requiring you to identify the following:
Documentation for the analytical validation is likely to be an output of applying the IEC 62304 standard focusing on the following three steps:
IEC 62304 requires you to establish software requirements, and they should preferably detail the functional and capability requirements of your AI/ML features.
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?
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.
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.
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:
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.
To stay updated, please sign up to our newsletter below or subscribe to our social media channels YouTube and LinkedIn and we will keep you updated.
With our medical device software course selection, you can choose between Software for Medical devices and IEC 62304 and SaMD, IEC 62304 and IEC 82304-1 depending on your interest and need.
The courses are suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The courses do not cover actual coding.
Or if you’re looking for a tailored training to align with your company’s specific needs – contact us for inhouse training options.
Christian Kaestner is a consultant and entrepreneur with a wealth of knowledge about the medical device industry. He is an expert member of the project team authoring IEC62304 and also actively participated in the creation of IEC82304-1.
He has extensive experience of medical device development and, as a software developer, a strong dedication to software development. In the software domain he has worked in many roles such as software developer, project manager, auditing and quality management.
Receive FREE templates and quarterly updates on upcoming courses that can help you in your career! Subscribe to our newsletter now.
When you submit this form, you will be sending personal information to medicaldevicehq.com. To comply with GDPR requirements, we need your consent to store and use the personal data you submit. Take a look at our Privacy policy for more details.
Special launch offer: 349 299 EUR for the online plan & 449 349 EUR for the online lifetime plan.
