Skip to content
IEC 62304 is the international standard which describes best practice in the development and verification of medical device software – that is, stand-alone Software as a Medical Device (SaMD) and software developed to be incorporated into Medical Devices (SiMD). Compliance to IEC 62304 is not determined through certification against the standard itself, but is effectively mandatory for medical devices in the EU, UK and USA.
Meeting the requirements of IEC 62304 is a structured and clear way to demonstrate that your medical device software is effectively planned and tested, and many of your technical file documents should reflect compliance with the standard.
When implementing documentation and processes which meet the needs of IEC 62304 it can be easy to overlook some key details within the standard and end up with gaps in your system, which can open you up to compliance issues and safety risks.
We’ve outlined some of the common areas that organisations miss or don’t fully implement below:
What do you need to do?
1. Understanding device safety classification
Application of IEC 62304 requirements is underpinned by a risk-based approach, which requires that you determine the safety classification of your software (or part of software) and apply at least the relevant level of control.
There is a flowchart in Section 4 of the standard which outlines the key decision-making process needed to determine this classification (Class A, B or C) based on the risks associated with the failure of the software, but this does not tie perfectly with regulatory software classifications (e.g. I, IIa, IIb, III) in the EU MDR. Because the two methods of classification do not tie directly to one another, it’s important to consider both as inputs to your software design plans and requirements.
To help prevent falling into this potential gap, make sure that you do both a regulatory review of your product, based on its functionality and purpose, and assign a software safety classification based on the impact of software failure. It can be helpful to have an understanding of risk management concepts found in ISO 14971 and related standards to make this assessment most effective.
Need help defining your Regulatory Strategy?
2. SOUP
Software of Unknown Provenance or SOUP is defined in the standard as software items that are either generally available but not developed with the intent of incorporation into a medical device, or software items which do not have adequate records relating to their development. It’s common to implement SOUP into many SaMD products; this includes code libraries from reputable sources, plugins or other tools that you incorporate into your product whole cloth. SOUP may also include software units that have been written by AI coding agents with minimal oversight. While it’s absolutely acceptable to use SOUP and build your product using chunks of code not made by your organisation, it’s also mandatory to control and document their use carefully.
When drawing up your software documentation, it’s best practice to maintain a SOUP list, which contains a record of all your relevant SOUP units. This list should contain information about the external software, what its purpose is, how it’s used within the product and an assessment of risk related to using it. Along with the risk assessment should be information about any relevant risk mitigations for the item. Commonly, this may include only using the most recent versions and checking for vulnerabilities periodically.
3. Types of Verification
IEC 62304 clearly defines two levels of software complexity, which must both be scoped out with requirements and tested (verified) separately. These are Software Units and Software Systems.
A software unit is a chunk of software or code which cannot usefully be divided further, whereas a Software System is a collection of multiple units integrated into a single entity which meet one or more overall software requirements. Verification tests should be run at both levels, and to test the integration of units into system blocks.
Under the standard, it is mandatory to plan, document and perform verification on all levels of the software infrastructure. Commonly referred to as “System Testing”, “Unit Testing” and “Integration Testing”, the verification may take different forms depending on the case. While the exact nature of verification is up to you, it may be helpful to consider the following when planning:
Unit verification
Consider whether the code implements relevant risk control measures and think about documenting a code review process to make sure that the code itself meets your organisation’s standards.
System and Integration Testing
This might include manual or automated tests using one or more of the user-facing systems to ensure that functionality is as expected. These tests can be combined if its deemed appropriate to do so.
4. Development Planning
While all organisations will likely be doing some level of development planning to understand resource requirements and potential hurdles during a development project, IEC 62304 is clear that there must be documented evidence of this. A development plan should be written which outlines the goals and procedures for the development with the aim to reduce risks related to software.
Where organisations may slip up is that development planning should be an iterative process and the development plan should be revisited routinely during the development process. As the project progresses, it is common for the scope of the work to change, or for requirements to become more clearly defined which may ultimately adjust goals or procedure. On-going risk management activities may also update the safety classification of your device and the development plan should be updated to account for any new controls which should be in place. Initial creation and subsequent reviews of a software development plan at well-defined milestones during development will help prevent your final documentation not reflecting your objectives and make sure you’re applying the correct level of control.
Need help educating your Development Team?
5. Traceability
There should be a clear and understandable through-line which links your software requirements, regardless of their source, ultimately to your verification and validation activities before product release. This means you can trace hazards and risks to mitigations for those risks, and it means you can trace the origin of any given requirement through to how it was implemented and tested in the final product. While many organisations do a good job of analysing requirements or at effectively reviewing risks and proposing proportional mitigations, the interface between these processes and systems isn’t always clear.
Traceability can be done in many different ways. For small-scale projects or sets of activities, even a simple spreadsheet will aid compliance. Often this is called a “Traceability Matrix” which is essentially a large table or sheet that shows the relationship between each step of the process i.e. which hazards link to which requirements, which requirements link to which verification record and which records link to which product release version. This should be reviewed and kept up-to-date as the development progresses to make sure everything has been covered. For more complex software systems, it might be helpful to implement automations such as with a requirements tracking system, or a ticketing system which generates unique IDs for every activity. Regardless of approach, traceability should be at the core of your processes.
What should I do now?
With this in mind, it’s always good to review your software development lifecycle and documented procedures to make sure you don’t fall into any of the common gaps that auditors see. Having a well-maintained management system to underpin your software development is the best way to keep ahead of changing requirements and inputs from your customers, regulators and other stakeholders.
Looking for a Regulatory Partner?
Work with us to help register your Medical Device. shape your Technical Documentation and ensure compliance with IEC 62304 – without drowning you in complex or technical jargon.
