Menu
Menu
IEC 62304 is an essential standard if you are working with the development of medical device software. In this article, you will get an overview of the scope of this standard, along with the configuration management process which will help you keep track of information, changes, and source code.
If you’d like to know more about the IEC 62304 standard and risk management in medical software development, take a look at this short course.
IEC 62304 is a process standard with a list of requirements and activities you should carry out throughout your development cycle. There are no requirements in the standard forcing you to apply a specific development method. You can use whatever method you want, as long as you acknowledge the process approach and perform the required activities in the standard.
Some key elements in the standard are development, risk management, configuration management, problem resolution, and maintenance. Each of the processes is divided into activities where the development process has the most activities.
The number of activities you need to do depends on how harmful your product can be – which is decided with the help of software safety classification. The flow through the standard is the same but the rigour is different depending on your classification.
This graphical overview visualizes the scope of the standard. Blue boxes are in scope and grey are out of scope.
In the standard, there is a clause speaking of software requirement content but there is nothing about how you document your requirements. You can capture requirements in any way you want: tickets, stories, wiki pages, or advanced requirement management tools. But, there are a couple of formal requirements you need to consider.
In your system verification, you must reference a specific set of requirements, this would be called a baseline. Requirements shall also be reviewed and approved and your project setup needs to be able to support you in this work. Traceability is also a requirement, so ideally, your choice of requirement management also supports you with traceability to verification.
You also need to plan for content, purpose, and how to deliver each release. The expectations are most likely different if you are releasing for a usability test, clinical study, or final release for production or upload to the app store.
To develop safe software you need input about hazardous situations to understand what you must avoid. Very often, this input also includes risk-related requirements, for example, to display a detailed warning when high blood pressure is detected.
The risk management process helps you to develop safe software. The configuration management process supports you in keeping track of information, changes, and source code. And last but not least, the problem resolution process manages issues with your software.
However, it is unlikely that your development work will happen exactly like this. Your development method should allow you to be adaptive as your knowledge evolves over time.
A software project usually has more configurations items to control then all documents together in a full development project. If you look at the definition of a configuration item, it says, “entity that can be uniquely identified at a given reference point”.
In the software domain, a given reference point can be down to hours even minutes. This is very different if you compare with documents that are typically released with the help of signatures and at a much slower pace.
A configuration item can be many things. It can be precompiled libraries, build files, source code, compiler settings – basically any piece of information needed to create your deliverable, including documentation.
One example of configuration management is version control systems which can support you with traceability. Correctly implemented, configuration management can support the process aspects of your development work.
Scrum development principles embrace changes, but you might feel that there is a mismatch between the waterfall approach in the standard compared to working with agile methods. Let us compare the two ways of working with an example from the standard relating to a requirement to verify the quality of your requirements.
If you review a Scrum story before it gets implemented, you do it by “taking one bite at a time”. You do not want any contradictions or ambiguity in your stories. In other words, you verify software requirements on a story-based level instead of verifying your complete backlog of requirements.
You can compare this with a waterfall approach where you typically aim to have nearly a full set of requirements and then go for a review. You will not verify as frequently as you do in Scrum, but you will spend more time in every review.
You can also work with Agile principles and meet the requirements of the standard. It is only a question of how you have chosen to meet the requirements.
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.
