Have you ever felt that you are having trouble with finding a way how to actually apply the requirements of IEC 62304 within your organization?
The good news is, you are not alone. This is a very common issue since the standard does not require implementing any specific development process.
The following video, which is a part of our online course on Software for Medical Devices, tries to explain and help you understand how to manage your choice of the development process and documenting compliance with IEC 62304.
The purpose of this article is to clarify the basic notions within the topic, but if you are interested in learning about this in-depth, register for this one and our other online courses here.
IEC 62304 – not practically applicable?
This is a claim you can often hear; we dare to say it is not true.
Clearly, there will always be challenges, but with the right strategy, overcoming them should be fairly easy.
The first thing you should be aware of is that, while it is true that the standard does not require a specific process, it does not mean you can just choose a random development process and claim compliance to IEC 62304. On the contrary: you have to show how you meet the requirements of the standard.
- Where can it get tricky?
The biggest challenge with compliance is meeting people outside of your organization, e.g., during an audit. From an audit perspective, it is not much easier because you never know what you will be presented with.
- How to solve it?
You should have a checklist to justify the claimed compliance with a specific standard. Checklists make things easier, both in audits and in describing the requirements behind a development process.
How to make a checklist
There is one rule to follow: don’t make it too complicated. List the requirements in the standard, followed by a description of your process or activities meeting each specific requirement and where to find evidence that the activities have been carried out.
Software development approaches
You can choose the approach that works best for your organization, and there is no right or wrong choice. Some commonly used approaches are:
- Agile development principles
IEC 62304 is often, incorrectly, understood in such a way that you must apply a traditional process such as the waterfall process. But, if you take a closer look at the intent of the activities outlined by the standard and what is happening in a Scrum cycle, you will find that both approaches aim for a structured way of working.
In the first three activities of the standard, we have:
- software development planning
- software requirement analysis, and
- software architectural design.
There are many similarities with what is called product backlog, sprint backlog, and planning in Scrum.
The next part contains actual coding work and confirmation that implementation meets defined requirements. Again, the words and terminology are different, but the purpose and goal are very similar.
Lastly, there is the software release. Depending on the system you are working with this can be a full product release, it can also be a software release that will be integrated with other systems, such as hardware.
Checklists – what do we put in them?
To go back to checklists, you will see for yourself how much easier they make the process when demonstrating compliance. The best thing about them is that they work with any approach to meet the standard requirements. Let’s work through an example based on IEC 62304, §5.2.6.
In the Scrum approach, to simplify things, you verify software requirements on a story-based level instead of verifying your complete backlog of requirements.
The requirements are kept through stories in a tool called Jira. Records from sprint planning are stored in a wiki tool called Confluence, and the audit trail for stories reveals who conducted the review. You may have already noticed that here, no information is kept on paper.
If you choose waterfall, you typically aim for having nearly a full set of requirements and reviews.
For the waterfall approach, SOP (standard operating procedure) is referenced, as well as a work instruction on how to conduct verification of requirements.
Be aware that the more you move away from the linear structure of the standard, the more you will benefit from a maintained checklist. With regards to the choice of development method, it is ultimately your choice to see what is appropriate for your organization.
If you liked this article and want to read more, you can find them all here.
Would you like to learn more about Medical Software Development?
Get instant access to our online Software for Medical Devices and IEC 62304 course right here. In 15-25 hours, you can learn how to be effective in medical device software development according to the IEC 62304 standard. The course is suitable for anyone working with software development, such as R&D engineers, quality assurance department and auditors of software development. The course does not cover actual coding.
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 IEC 62304 and also actively participated in the creation of IEC 82304-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.