ONLINE GUIDE
All you need to know about IEC 62304 compliant software development
Building and releasing medical device software is hard, very hard. Here at Extra Horizon we have had a lot of experience in successfully building, launching and scaling digital health products that are IEC 62304 compliant. We often get lots of questions regarding the IEC 62304 standard, as it is not the easiest of standards to follow.
There are a lot of concepts and terms that you need to familiarise yourself with, which can often seem quite daunting. That’s why we took it upon ourselves to write this
guide through IEC 62304
with the main purpose of navigating you, the reader, through the most important concepts of the standard.
Before you start reading
Like you, we have also read ebooks and online guides before. Sometimes you just want to skim the content and read about the guiding principles of what you’re reading about, so we made that part a bit easier for you!
Throughout the guide you’ll come across different coloured pop-ups that show you what’s really important:
Rather read the pdf version?
Table of contents (click on title to navigate)
- First of all, what is IEC 62304?
- Versions of IEC 62304
- Harmonisation of IEC 62304
- Is IEC 62304 mandatory?
- What are the steps for becoming IEC 62304 compliant?
- The scope
- Normative references
- Terms and definitions
- General requirements
- Software Development Process
- Software Maintenance Process
- Software Risk Management Process
- Software Configuration Management Process
- Software Problem Resolution Process
- To summarise
- Attachments
First of all, what is IEC 62304?
IEC 62304 is an international standard for medical device software which defines the framework for software lifecycle processes. It was first released in 2006, and an amendment was released in 2015.
IEC 62304 covers the safe design and maintenance of software, and ensures product safety from the very start of development. It applies if the software itself is a medical device, or if the software is an embedded part of the medical device.
Versions of IEC 62304
In this ebook, we will focus on the original 2006 version of IEC 62304. However, in 2015, an amendment was released. There are some differences between the original version and the 2015 amendment. We will be sure to tell you when something important has been changed or added in the 2015 amendment.
You can always subscribe to our newsletter to know about the bigger updates fresh from the press (scroll down to the footer)!
Harmonisation
IEC 62304:2006 is harmonised internationally, being recognised by regulatory authorities worldwide, including the European Commission, the FDA in the U.S., Health Canada, and many more.
Is IEC 62304 mandatory?
Being certified to IEC 62304 is
not mandatory,
and it is also possible to be compliant without being certified.
However, companies adhering to IEC 62304 are more likely to have an easier path to obtaining regulatory clearance. Thus, it is
highly recommended
that companies who produce medical device software follow its requirements.
This is not only because it helps
ensure the highest safety standards
for the products, but also because many regulatory organisations participate in the writing of the standards, and many of the regulations are based on industry standards.
Additionally, the MDR (Medical Device Regulation) and the IVDR (In Vitro Diagnostic Regulation) explicitly state that using harmonised standards should be a means for manufacturers to demonstrate conformity with the general safety and performance requirements and other legal requirements.
Although the use of harmonised standards remains voluntary, and manufacturers are free to choose another means of demonstrating compliance to the mandatory legal requirements, using them still puts manufacturers at a significant advantage. IEC 62304 needs to be applied in conjunction with ISO 13485 and ISO 14971.
In practice, you will almost certainly be looking to implement IEC 62304.
What are the steps to becoming IEC 62304 compliant?
There are 9 chapters to IEC 62304. We go over these in the order that they appear in the official IEC 62304 standard, as this makes the most sense.
We will cover the first three chapters in a more brief manner, as these are more or less introductory chapters to the standard, that yield little to no practical information. It is, however, important that you take note of these chapters before reading the other chapters.
The remaining 6 chapters, we’ll dive a bit deeper into. Especially chapter 5, which is about the
Software Development Process.
If you would like a visual overview,
please check
attachment 1 at the bottom of this page.
There are 9 chapters to IEC 62304. We’ll go over each one of them, some more in-depth than others, depending on their importance.
- The scope
- Normative references
- Terms and definitions
- General requirements
- Software Development Process
- Software Maintenance Process
- Software Risk Management Process
- Software Configuration Management Process
- Software Problem Resolution Process
In chapter 1 of the IEC 62304 standard, the scope of the standard itself is discussed. It is here, for example, that the standard is telling us that it applies to
companies that develop or maintain medical device software,
regardless of whether the software itself is a medical device, or if the software is an embedded part of the medical device.
Another important element is compliance: if you want to be
compliant
with this standard, you will need to implement all of the processes, activities and tasks that are identified throughout the standard in accordance with the
corresponding software safety class.
You can read more about software safety classes on our
MDR pillar page.
This section lists all of the referenced documents.
The only normative reference in IEC 62304 is to ISO 14971.
It is important to note that IEC 62304 does not cover the validation and final release of the medical device, even if the medical device consists of medical software only. More information on the difference between these two terms can be found on the next page.
The validation stage is part of other standards, such as ISO 13485 and IEC 82304-1.
This chapter lists all of the terms and definitions that apply to IEC 62304. You should always refer to these definitions when dealing with matters relating to IEC 62304.
Two very important definitions to remember here are
medical device vs. medical device software.
It is very important that you are aware of the difference between the two definitions. The differences are shown in the figure on the right.
This is of high importance, as the IEC 62304 standard only addresses medical device software.
medical device
/ˈmɛdɪk(ə)l/ /dɪˈvʌɪs/
“Any instrument, apparatus, implement, machine, appliance, implant, in vitro reagent or calibrator, software, material or other similar or related article, intended by the MANUFACTURER to be used, alone or in combination, for human beings for one or more of the specific purpose(s) of: diagnosis, prevention, monitoring, treatment or alleviation of a disease or injury; investigation, replacement, modification, or support of the anatomy or of a physiological process; supporting or sustaining life; control of conception; disinfection of medical devices; providing information for medical purposes by means of in vitro examination of specimens derived from the human body.”
manufacturer
/ˌmanjʊˈfaktʃ(ə)rə/
“Natural or legal person with responsibility for designing, manufacturing, packaging, or labelling a MEDICAL DEVICE; assembling a SYSTEM; or adapting a MEDICAL DEVICE before it is placed on the market and/or put into service, regardless of whether these operations are carried out by that person or by a third party on that person’s behalf.”
medical device software
/ˈmɛdɪk(ə)l/ /dɪˈvʌɪs/ /ˈsɒf(t)wɛː/
“Medical device software refers to a software system that has been developed for the purpose of being incorporated into the medical device being developed, or that is intended for use as a medical device in its own right.”
In order to be compliant with the IEC 62304 standard, there are 3 general requirements that you will need to adhere to.
- You will need a QMS (Quality Management System). A good way of demonstrating that you have an effective QMS is to implement and be audited for ISO 13485, which is a standard that specifies requirements for quality management systems. ISO 13485 is a company-wide requirement. However, it is not essential to be certified for ISO 13485 in order to be compliant with IEC 62304. Please note that it is the entire company that works according to a QMS - it is not just the software development team. Read more about the importance of having a good QMS at our blog post here.
- You will also need to perform risk management with regards to patient safety. This is where you evaluate what can go wrong with your product, and assess whether it’s still safe to bring it to the market. Specifically, your risk management needs to adhere to ISO 14971.
- You must
assign a software safety class
to your product.
4.1 QMS (Quality Management System)
It is essential to have a Quality Management System (QMS) in order for a device to be compliant with IEC 62304. Having a good QMS is proof that your company is quality-oriented, and therefore indicates that your product can be trusted in situations which may entail a risk to patients and/or users.
A company can demonstrate this ability by using a quality management system that complies with ISO 13485, a national quality management system standard, or a quality management system required by national regulation.
What is a QMS exactly?
A quality management system (QMS) is a formalised system that documents the relevant processes, procedures and responsibilities for meeting the regulatory and customer requirements related to a product.
A good QMS helps a company ensure that continuous improvements are made to their products, provides a baseline for training staff, and enables correction action to take place for any problems that arise.
What are the risks of not having a QMS?
If you do not have a QMS in place, you increase the risk of your employees using the wrong requirements documents, outdated test plans, and unvalidated tools. Having a QMS is also a requirement under article 10 of the MDR, which means you must have a QMS in order to receive a CE marking. Read more about MDR requirements here.
This can lead to serious problems further down the line, such as decreased productivity, increase development costs, damage to brand reputation, and even being denied entrance to market.
Ultimately, not having a QMS will have a negative impact on the quality of your software solution.
4.2 Risk Management
The manufacturer of the medical product must apply a risk management process that complies with ISO 14971.
The goal of risk management in IEC 62304 is to reduce harm to patients or users of the medical device. A risk can be defined as a combination of the probability of harm and the severity of that harm. Typically, a risk is the result of a harmful situation that needs some kind of risk control measure to be resolved or contained. In this case, the risk is caused by the software. Traceability is another important part of risk management, as it’s important to understand how risks originated.
Risk management does not only incorporate software. It can also include risk controls for things like hardware, or user error.
The ISO 14971 standard is a document that describes the terminology, principles and processes for the risk management of medical devices. Also including, importantly, software as a medical device and IVD medical devices.
4.3 Software Safety Class
The manufacturer must assign a software safety class to their product. These safety classes are according to possible side effects on the patient, resulting from a hazard that the software system can contribute to.
The three safety classes under IEC 62304 are:
- Class A: No unacceptable risk to health
- Class B: Injury is possible but not serious
- Class C: Death or serious injury is possible
When a hazard can arise from the failure of your software system, you must assume the probability of the failure to be 100%.
Therefore, you must always assume the worst-case scenario. If you cannot 100% guarantee that your software cannot cause serious injury or death, your software will be either class B or class C.
Information regarding the software safety class of each software system must be documented in your risk management file. A risk management file (RMF) is a file where you keep records of all of your risk management activities, including all documents, files and records produced during the risk management process.
The higher the safety class of your product, the more of the IEC 62304 criteria you will need to comply with. For example, for software class C, you need to document the design with enough detail to allow the correct implementation of each software unit. However, this is not a requirement for class A or class B.
Figure: how to assign the correct safety classification
You can use the figure below to learn how to classify software correctly in accordance with the IEC 62304 standard. For a more detailed overview of the requirements for each safety class, see our page about the MDR.
In this stage, we will tackle all of your software development planning. This section may seem intimidating, with 8 subchapters, but we are going to break it down into easy-to-understand chunks for you. You can click any of them on the right to navigate directly to the specific subchapter.
Important background information
IEC 62304 describes industry best practices. Although it is not necessary to include all of these processes for Class A or Class B medical device software, implementing these processes will increase the quality of the end product. It is also possible that extra requirements could be added in future revisions of IEC 62304. For example, the amended 2015 version of IEC 62304 added extra requirements for both Class A and Class B medical devices.
5.1 Software Development Planning
First, you must produce your software development plan. Your software development plan is a document containing highly-detailed descriptions of all of the processes used in order to create your medical device software. It is also allowed, and even recommended, to have multiple development plans for different systems in the medical device.
It is important that you create an initial software development plan before you develop any software.
If you do not have an initial development plan in place, regulators will not be convinced that you have considered factors such as risks, and the environment in which the software will be ran. Having a plan in place shows you have considered these things.
Another consequence of not having an initial development plan ready at the beginning of development is that you risk developing software that is not in line with the processes in your software development plan. This puts you at risk of failing audits, which would mean that you would have to go back to square one and redevelop your software.
Remember, it is important to keep your software development plan updated as development proceeds.
5.2 Software Requirements Analysis
The software requirements analysis is very important in terms of traceability, and also offers significant benefits to your company.
Clear traceability means that errors are spotted early on. The earlier an error is discovered, the cheaper it is to fix it. This can save your company significant time and money. Performing software requirements analysis activities is also helpful in terms of disaster recovery.
As errors can be easily traced back to the requirements, this means that it will be easier to determine why something went wrong, how you can improve this, and how the product can be fixed.
This traceability element also comes in useful when your software is subject to audits. Auditors are focused on the risk to patients, and which requirements influence the risk to patients. As the software requirements analysis shows a clear trace of software items and requirements, this means that you can easily show auditors where in the software system that the risk originates, and how you make sure that the software doesn’t make these errors. This will make passing audits a lot easier.
For each software system of your medical device, you must define and document the software system requirements. These requirements should be re-evaluated and updated as appropriate.
5.3 Software architectural design
Please note that this step is not required for Class A devices.
First of all, what do we mean by ‘software architecture’?
In the IEC62304 standard itself, software architecture refers to: "the organisation and structure of your software system. It encompasses all of the fundamental components of your software, how they all interact with each other, how they were designed, and the environment in which they operate."
Manufacturers must take the requirements for their medical device software and transform these into a thoroughly-documented software architecture.
In this software architecture, you must also document the interfaces between different software items, and between software items and any external components.
If a software item is classified as SOUP, you must specify the functional and performance requirements that are necessary for the intended use of the product. You must also specify the system hardware and software needed to support the operation of the SOUP item.
What is SOUP?
SOUP stands for Software of Unknown Provenance. It is defined in the IEC 62304 documentation as follows:
SOUP
/suːp/
“Software item that is already developed and generally available and that has not been developed for the purpose of being incorporated into the Medical Device (also known as “off-the-shelf software”) or software previously developed for which adequate records of the development PROCESSES are not available.”
An example of SOUP is any kind of third-party software that has already been developed and was not initially designed for use in medical applications. Examples include operating systems (e.g. Windows, MacOS, Android etc…), hardware drivers (e.g. Bluetooth drivers), software libraries (e.g. Tensorflow etc…), and more.
How to visualise software architecture?
Software architecture is typically represented by diagrams. These help show the relationships between different software components clearly.
Why are we required to list SOUPs?
Not listing SOUP items can lead to dangerous and even fatal situations. If sufficient documentation is not produced for a SOUP item, this can mean critical issues can be missed by your development team.
An example of this is the Therac-25 disaster1. Therac-25 was a computer-controlled radiation therapy machine that was used to treat cancer in patients. Unlike previous Therac machines, such as Therac-20, which primarily relied on hardware locks as safety measures, Therac-25 relied primarily on software. Software from Therac-20 had been re-used for Therac-25. However, due to insufficient documentation, the development team were not aware that Therac-20 had hardware locks in place, which were able to prevent radiation exposure if the software malfunctioned.
Without these hardware locks in place, some patients received massive overdoses of radiation from Therac-25 machines, resulting in 4 deaths and 2 patients left with permanent damage.
If sufficient documentation had been created for Therac-20, the development team would have noticed the missing hardware locks, which could have prevented these deaths and permanent physical damage. It is for this reason that listing and documenting SOUP items is essential.
As was the case in the previous chapter about the Software Development Planning, it is again the responsibility of the manufacturer to implement certain verifications. The full list of verifications can be found in chapter 5.3.6 of the IEC 62304 standard.
5.4 Software Detailed Design
Please note: for this section, there are more requirements for software Class C than there are for Class A and Class B.
Now, the manufacturer must refine their software architecture so that it is represented by software units. The design of each software unit should be properly documented.
Another thing that must be documented is the design of any interfaces between the software units and any external components (e.g. hardware or software) and also between other software units.
A software unit is a software item that is not subdivided into other items.
To summarise, your documentation must verify that your software detailed design (as stated in the IEC 62304 standard itself):
- implements the software architecture;
- is free from contradiction with the software architecture.
What is an interface?
An interface is a declaration of how two components will communicate. The interface documents how the communication will happen. These interactions can be between two pieces of software, or between software and external components.
5.5 Software unit implementation and verification
Now, it’s time to ensure your software units are successfully implemented and verified. As a manufacturer, you are responsible for developing strategies, methods and procedures for verifying each of your software units. These methods can include things like source code reviews and unit tests.
In cases where verification is achieved through testing, all test procedures should be evaluated for correctness.
As usual, all of these things must also be thoroughly documented!
Setting out acceptance criteria
You are also responsible for setting out acceptance criteria for your software units. The acceptance criteria is the set of conditions that a software unit must meet in order to be accepted by the user. The acceptance criteria must be met before a product is considered “finished”.
Here are 3 examples of acceptance criteria that are provided in the IEC 62304 standard itself.
- Does the software code implement the desired requirements, including risk control measures?
- Is the software code free from contradiction with the interfaces documented in the detailed design of the software unit?
- Does the software code conform to programming procedures or coding standards?
Additionally, you must add additional acceptance criteria if any of these features are present in your software design, as stated in the IEC 62304 standard, chapter 5.5.4:
- Proper event sequence
- Planned resource allocation
- Data and control flow
- Fault handling
- Self-diagnostics
- Proper event sequence
- Initialisation of variables
- Memory management and memory overflows
- Boundary conditions
Finally, you must perform the software unit verification to make sure that there is sufficient evidence that your software units comply with the acceptance criteria. This evidence must be thoroughly documented.
Having thoroughly documented software unit implementation and verification has many advantages, including:
- Fewer bugs, which means your software is less likely to suffer from unexpected, potentially patient-harming problems.
- It helps software engineers to follow processes, as the documentation acts as a useful guidance tool for engineers.
- It helps you to create better documentation, because having clearly documented procedures means that it makes it easier for engineers to create the level of documentation needed for your product.
5.6 Software integration and integration testing
Next up, you will need to take the software units that you implemented and verified in the last step, and integrate these into your integration plan.
What’s an integration plan?
Your integration plan describes the process of integrating your software units into the larger software system. It ensures that all of your software units work together properly.
Your integration plan must verify that (as taken directly from the IEC 62304 standard, chapter 5.6.2):
- The software units have been integrated into software items and the software system
- The hardware items, software items, and support for manual operations (e.g., human-equipment interface, on-line help menus, speech recognition, voice control) of the system have been integrated into the system. (This point has been removed in the amended 2015 version of the IEC 62304 standard)
Testing your integrated software items
When you go on to test your integrated software items, you will need to conduct this testing according to the integration plan, and document the results. The purpose of this testing process is to ensure that the software items perform properly. Here are a few examples of what to consider during the testing stage, taken directly from the standard itself, in chapter 5.6.4:
- The required functionality of the software
- Specified timing and other behaviour
- Implementation of risk control measures
- Specified functioning of internal and external
- interfaces
- Testing under abnormal conditions including
- foreseeable misuse
Regression testing
Just like in the last step, your testing procedures must be evaluated to ensure they are correct. You must also conduct another form of testing called regression testing.
Testing can never prove the absence of bugs. It can only prove that your test works. It does not make sure that no bugs were introduced. If the regression testing identifies any anomalies during the software integration and integration testing stage, you must put these anomalies into a software resolution process - something which we will explain later on in section 9.
Regression testing is the retesting to detect faults introduced by a modification. It ensures that the software still works as intended after changes are made.
5.7 Software system testing
Now, we move on to the software system testing stage. This stage is vital, as it helps you to prove that all software requirements are covered.
You must establish and perform a set of software system tests, which take into account the following factors:
- Input stimuli
- Expected outcomes
- Pass/fail criteria and procedures
The goal of performing software system testing is to test the software system without external components. For software system testing, it is allowed to mock external devices. For example, if the software needs to display a graph, but the server containing the graph is still being developed, it is fine to create data yourself and use that data as input in place of the final data.
Any anomalies identified during the software system testing process must also be entered into the
software problem resolution process,
which was previously mentioned in step 5.6.
It is incredibly important that retesting takes place when changes are made, in order to make sure the changes were effective.
Furthermore, it is not only important to retest your software, but also to verify your testing procedures.
And last but not least, you must keep thorough
software system test records.
5.8 Software release
Before your software is officially released, it is very important to make sure that all software verification has been completed and that the results have been evaluated. Any problems must have been documented properly, and these must be assessed to make sure that they do not contribute to an unacceptable risk.
Archive requirements
There are certain things that you as a manufacturer will be required to archive. Under the IEC 62304 requirements, you must archive the following:
- The software
product
(in the 2015 amended version, software product is removed and the term is replaced with
medical device software)
and configuration items
- The documentation
How long
these archives will need to be kept depends on factors such as the lifetime of your device, and regulatory requirements.
What you must do when releasing your device software
- Document the version of the software that is being released.
- Document the procedures and environment used to make the software.
- Ensure all activities and tasks are complete, including the associated documentation.
There are also other things that will need to be considered when releasing your product into the market. You will need to make sure you have
procedures
in place to ensure that your product can be delivered to the user without any corruption or unauthorised changes.
The first step of the software maintenance process is to establish your software maintenance plan, which contains plans for the maintenance process of your software.
There are several requirements that your software maintenance plan should adhere to, which are listed in chapter 6.1 of the IEC 62304 standard itself.
These range from procedures for documenting and resolving issues that occur after the release of the software, to procedures that evaluate and implement upgrades, bug fixes and patches.
Now, we move onto the problem and modification analysis.
Problem and modification analysis
At this stage, we monitor any feedback received about the released software product. This feedback may come from users, or from within your own organisation.
All feedback must be documented properly, and evaluated to determine whether there is a problem or not. If a problem is identified, this must be recorded in the form of a problem report.
Problem reports should also be
evaluated
to determine whether the problem affects the safety of your product or not, and therefore whether a change needs to be made to your released product to fix the issue. When evaluating problem reports, you should use the
software problem resolution process.
Problem reports should contain the following information:
- Actual or potential adverse events
- Any deviations from specifications
Change requests
If it is determined that a change is needed to address the problem, then a change request will be made. Change requests are strongly linked to the change control element of ISO 13485:2016.
What’s a change request?
A change request is a documented specification of what changes need to be made to a software product in order to address an existing or potential problem with the product.
If the medical device software is released with the intent of use, these change requests need to be analysed. This is to determine the potential effects of such changes on the organisation, the released software product, and to any systems which have interfaces with the released product.
Based on this analysis, manufacturers will need to approve or reject the change request. If approved, you must inform the users of the consequences of unchanged use e.g. not updating the software to a new version.
You also have some obligations as the “manufacturer” of the medical device software. According to the IEC 62304 standard, in chapter 6.5.2, you need to inform the users of your device and regulators about:
- Any problems in released software products and the consequences of continued unchanged use
- The nature of any available changes to released software products and how to obtain and install the changes
Now, you must make the modifications as indicated in your change request. Your software maintenance process can help you identify which activities need to be done to implement the change, and what activities can be skipped.
After the necessary modifications have been made, your software must be re-released. This can either be a full re-release of your software product, or in the form of a modification kit, containing the changed software items and the tools needed to install the changes into the existing software system.
When building a software product, the importance of risk management should never be underestimated. In order to protect users and reduce harm, manufacturers must identify any potential hazardous situations and manage these accordingly.
Identifying a hazardous situation
First of all, the potential causes of software items contributing to a hazardous situation must be identified.
You should consider potential causes (taken directly from the standard itself):
- Incorrect or incomplete specification of functionality;
- software defects in the identified software item functionality;
- failure or unexpected results from SOUP;
- hardware failures or other software defects that could result in unpredictable software operation; and
- reasonably foreseeable misuse.
Verify and document risk control measures
You must also verify your risk control measures, and document this properly.
When a risk control measure is implemented as a software item, you must evaluate the risk control measure in order to identify any possible new sequences of events that could lead to a hazardous situation. These events should be documented in your risk management file.
You must also document the traceability of any software hazards.
It also applies to your SOUP items
You must also apply this same process to any SOUP items you may have used.
If a hazardous situation is identified to be caused by SOUP, you must then evaluate the anomaly list published by the SOUP item supplier to determine whether any anomalies have led to a chain of events that has resulted in a hazardous situation. You must make sure that the anomaly list corresponds to the correct software version of the SOUP item.
Any potential cause of a software item contributing to a hazardous situation, as well as the sequence of events (see below) that can lead to the hazardous situation, must be documented in your risk management file.
The sequence of events is removed from the 2015 amended version.
Consider your risk control measures
After identifying and documenting the potential causes and events that can lead to a hazardous situation, you must now consider your risk control measures.
First of all, you must define and document your risk control measures. This should be done for each potential cause of a hazardous situation.
If a risk control measure is then implemented as part of the functions of a software item, you are obliged to do the following:
- Include the risk control measure in the software requirements
- Assign a software safety class to the software item based on the possible effects of the hazard that the risk control measure is controlling (see below)
- Develop the software item in accordance with Clause 5 of the standard
In the 2015 amended version, there is an update to this requirement.
Perform risk management procedures
Now, you must perform risk management procedures for the software changes. For any change to your medical device software, you must perform an analysis to determine if:
- additional potential causes are introduced contributing to a hazardous situation; and
- additional software risk control measures are required
You must also assess the impact of any software change on your existing risk control measures, including any change to SOUP. This will help you determine if the change interferes with your current risk control measures or not.
You should do an initial risk assessment at the beginning, and then each time you make a change, you should do a risk assessment of the change.
As a manufacturer, you will need to establish a scheme for the unique identification of configuration items, as well as controlling their versions.
What’s a configuration item?
A change request is a documented specification of what changes need to be made to a software product in order to address an existing or potential problem with the product.
When it comes to SOUP, each configuration item being used must have the following information documented:
- the title
- the manufacturer
- the unique SOUP designator
Configuration items and their versions are parts of the software system configuration. It is important that all of this information is properly documented.
Change control
Configuration items must only be changed in response to an approved change request. The change should be made exactly as specified in the change request, and this may include performing activities that need to be repeated as part of the change.
This can include things such as changes to the software safety classification of software systems and software items.
Controlling your changes
Changes must then be verified. You must also repeat any verifications that have been invalidated by the change.
With changes, there must always be traceability. You must produce an audit trail for any changes, including the following information:
- change request
- relevant problem report
- approval of the change request
As a manufacturer, you must also keep records of the history of controlled configuration items, including the system configuration.
Now we’ve reached the final section - the software problem resolution process. This is where you address any problems identified in your medical device software. This is an extremely important step, and if it is not handled properly, you could miss something that could cause harm to users of your medical device software. This would also have a negative effect on your product’s reputation.
What is a problem report?
A problem report is a record of actual or potential behaviour of a software product that a user or other interested person believes to be unsafe, inappropriate for the intended use, or contrary to specification.
For each problem identified, you must prepare a problem report. Problem reports should be classified (see below) according to:
- Type
- Scope
- Criticality
Before you tackle the problem itself, the problem needs to be properly investigated, and if possible, the causes need to be identified.
Please note: the classification is no longer required in the 2015 amended version, so be mindful of this.
Then, using your software risk management process, you must
evaluate the problem’s relevance in terms of safety.
The outcome of this investigation and evaluation must be thoroughly documented. (Read further in the column on the right, you might have to scroll up a bit).
After this has been done, the next step is to create
a change request
for actions needed to fix the problem. If it is decided that no action will be taken, you must document the rationale for taking no action.
It is essential that relevant parties are informed about the problem with the software.
Taking into account the change control process, you must approve and implement all change requests.
You must keep detailed records of the resolution and verification of all problem reports and their solutions, and update your risk management file as appropriate.
These records should be analysed to detect any possible trends in problem reports.
Now that the change requests have been implemented, you must determine whether (from the standard itself):
- The problem has been resolved and the problem report has been closed
- Adverse trends have been reversed
- Change requests have been implemented in the appropriate software products and activities
- Additional problems have been introduced
Finally, you must pay close attention to the
contents of your test documentation.
When you perform testing, retesting, or regression testing of your software items and systems after a change, you must make sure that all elements provided in chapter 9.8 of the standard are included in your test documentation.
Why is it important to adhere to IEC 62304?
IEC 62304 is the gold standard for medical software development, covering the safe design and maintenance of medical device software. Being IEC 62304 certified helps you gain the trust of your customers, as it reassures them that your product meets the highest safety standards - something that is extremely important in the medical device software field.
The stringent QMS requirements of IEC 62304 also reassure customers that you are committed to making continuous improvements to your products, and that any problems will be dealt with quickly. Likewise, the risk management aspect of IEC 62304 reassures users that any risks are dealt with in a timely manner.
Also, as
IEC 62304 is harmonised internationally,
it means your product will be recognised by regulatory authorities worldwide. This vastly improves the overall marketability of your medical device software product, and makes it easier to enter international markets.
Attachments
Attachment 1: figure 1
In this figure, you can see exactly how chapter 5 until 9 can be visualised for your understanding. Although the figure below visualises the activities in a waterfall model, there is no strict requirement that states you need to perform the activities in a particular order. As long as the activities are sufficiently documented and you can show it will result in a quality product, you can perform the activities in any order you like.
Attachment 2: table 1
In this table, you can find an overview of all the IEC 62304 requirements, according to the amended 2015 version, for each of the 3 software safety classes.
Solutions
BY USE CASE
BY CAPABILITY
BY STAGE
Getting Started
AS A DEVELOPER
AS A PARTNER
© 2023 Extra Horizon, All rights reserved
Kempische Steenweg 303, 3500, Hasselt, BE
— Hasselt, Belgium