The development of medical device software is an incredibly important part of technological advances in the healthcare industry. As with any new treatment or equipment, the safety standards for medical device software are incredibly high and primarily dictated by IEC 62304.
IEC 62304, titled ‘Medical Device Software – Software life-cycle processes’, is an internationally recognised standard for medical device software lifecycle processes, released in 2006 and harmonised by the FDA and European Union. It gives a framework for manufacturers of medical device software by outlining the necessary development and maintenance stages required to ensure safe software development, along with tests and tasks to prevent potential hazards.
This standard applies to the development and maintenance of medical device software when:
The IEC 62304 definition of medical software is quite vague, and when it comes down to specifics it can be difficult to identify whether a piece of software needs to adhere to medical device software standards.
The following functions are used to classify medical software:
IEC 62304 offers guidance on how to identify potential hazards that could be the result of medical software failures or defects, and therefore outlines how to properly classify the risk level of a medical device.
Once the risk level of a device has been decided upon, IEC 62304 covers all of the risk control measures that need to take place throughout the life cycle of that particular medical device.
When considering the risk associated with medical device software, it is very difficult to estimate how likely a piece of software is to malfunction. Therefore, levels of risk attached to different medical devices are based on how severe a hazard they would be if the software was to fail or malfunction.
There are three different safety classes for medial deceived outline in IEC 62304, which help identify which safety-related processes are required throughout the product’s development lifecycle. This is a very important classification, as it will affect the entire process that device software goes through as it is developed.
The three safety classes are based on a device’s potential to create a hazard that could injure the user, patient, or other people.
No injury or damage to health is possible from this device
Injury caused by this device is possible, but will not be serious
Death or serious injury caused by this device is possible
Verification, integration, and system testing are required on all medical device software, but the activities that need to be performed will vary depending on the safety classification of the medical device.
Once a device’s safety class has been decided upon, the IEC 62304 outlines which steps of the development and testing process are required for each. The specifics of these safety procedures are found within the IEC 62304 document itself, but an overview of each section is provided below as a guide.
The software development process outlined in this section runs from the planning of software to its release. This is the most important stage of the software lifecycle, as all the steps needed to create a new piece of software are planned out and all necessary software tests are identified.
Stages of software development included in this section:
Once the tested medical device software has been released, the next section of its lifecycle is the maintenance and refinement of the software. Here, potential issues will be identified and user feedback will also be gathered to improve how the software and device work.
Stages of software maintenance included in this section:
This section is particularly relevant to the aims of IEC 62304 standards, as it specifies the risk management procedures that will be required to reduce or remove the potential risk that the device could cause. The processes involved in this section of the software design must be meticulously recorded so that it is clear how hazards have been identified and what is being done to remove them.
Stages of software risk management included in this section:
In this section of the design process, changes in the device software are tracked and controlled as the entire software is configured.
Stages of software configuration management included in this section:
If there is any Software of Unknown Provenance (SOUP) in a device, this is the section in which the software will need to be identified and verified to ensure that it is not going to pose a risk to the entire system.
The final section of the necessary IEC 62304 procedures is to explain the processes which have been used to resolve software problems and outline how other issues will be tracked and evaluated if they arise in the future.
Stages of software problem resolution included in this section:
In order to be compliant with IEC 62304, all sections of the standard’s risk management framework that are relevant to a software’s safety class must be carried out. In short, for every hazardous outcome identified there must be an identified software item which could lead to this hazard, the potential cause of this item’s malfunction, an identified measure to control the risk, and verification that these control measures have been put in place.
The best practice for following this framework involves requirement traceability, where it is possible to trace the journey of every software requirement from creation, through the development and to implementation.
In IEC 62304, requirement traceability is needed between a device’s system requirements, software requirements, the software systems tests that are performed and the measures implemented in the software to control risk. In most cases, a Requirements Traceability Matrix is used to ensure this and keep track of all requirements and changes made during a development project.
Having clear requirement traceability is the most important aspect of showing compliance with IEC 62304 guidance, so it must be clearly documented and easy to follow.
One of the reasons why IEC 62304 is considered such a good medical device software standard is because it focuses on device and software maintenance after a product has been released. There have been many cases in the past where medical devices have malfunctioned or had to be recalled when a system update or upgrade was required, which not only endangers the patients who rely on the device but also costs development companies hundreds of thousands of pounds.
Following IEC 62304 means that a product maintenance process is also outlined in the risk control report, which will involve the monitoring of feedback from users and manufacturers so potential problems can be identified early. If a problem is identified, a problem report needs to be produced that evaluates whether a system update is needed and ensures that a new addition to the software won’t cause any more issues.
A device’s software maintenance process also needs to outline the correct problem reporting procedure to ensure that no issues are missed and any future problems are avoided as much as possible.
IEC 62304 is one of the most important standards that affect the production and maintenance of medical device software, but other frameworks interact with it.
This regulatory standard applies to the overall risk management process for medical devices, not just control measures associated with the software that runs the device. ISO 14971 provides internationally approved methods of reducing and controlling risk in every stage of the life cycle of a medical device, and will overlap with IEC 62304 control measures for a device’s software.
This regulatory standard is more general, and controls the quality management systems that will affect the production of a medical device. ISO 13485 offers guidance for how to develop a quality management system that will ensure every medical device is safe to use, by controlling the consistency of every stage of development and production.
IEC 60601 is a set of different standards that apply specifically to medical electrical equipment and ensure the safety of these. The most recent addition of these standards offers directions for creating safe medical software and methods of testing electrical equipment to monitor performance and levels of risk.
For countries inside the European Union, and the UK until May 2021, the EU Regulation on Medical Devices outlines standards that must be met before a medical device is put on the market. This mainly affects the production and distribution of medical devices but will affect some areas of the development process.
Despite the frequent life saving or life-prolonging benefits of medical devices and the software that runs them, standards for medical software were low and lacked standardisation before IEC 62304 came along. Following the procedures outlined by the standard may be time-consuming, but the level of risk management that is gained is well worth the extra effort.
If you’re looking for a recruitment partner who knows the industry inside-out and can help find people with the right skills and knowledge of these kind of safety standards then get in touch and we’d love to discuss further with you.
Chris is an award-winning recruitment consultant who has specialised in the electronics and embedded systems sector since 2008. Chris is passionate about technology and customer service.
01423 876 356
KO2 Recruitment Solutions Ltd
• Harrogate Business Centre, Hammerain House, Hookstone Avenue, Harrogate, HG2 8ER
• Raven House, 29 Linkfield Lane, Redhill, RH1 1SS
info@ko2.co.uk or contact us here
ASIC Engineer Interview Questions – What You Need to Know