Menu
Menu
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.
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.
The biggest challenge with compliance is meeting people outside of your organisation, e.g., during an audit. From an audit perspective, it is not much easier because you never know what you will be presented with.
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.
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.
You can choose the approach that works best for your organisation, and there is no right or wrong choice. Some commonly used approaches are:
1. Agile development principles
2. Waterfall
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:
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.
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 organisation.
If you liked this article and want to read more, you can find them all here.
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.
