An author of IEC 62304 revisits the standard after 14 years
Some of our most popular blog posts have involved discussions with Christian Kaestner, co-author of IEC 62304 and IEC 82304. He has brought us great insights into the underlying ideas of the people writing these standards and the standards' implications and interpretation throughout the industry.
You can tap into Mr. Kaestner's knowledge in his online course on medical device software and IEC 62304 in collaboration with Medical Device HQ
The full course is found here and a free short version is YouTube.
Once again, we have been fortunate enough to get a few minutes with Mr. Kaestner, who in this post elaborates on the current state of IEC 62304, 14 years after its initial release.
Q: With your extensive experience of both writing the standard and seeing how it has been used by the industry, how do today’s modern software companies approach and implement IEC 62304? Has IEC 62304 successfully stood the test of time?
A: Well, both yes and no. Yes, because after almost 15 years the standard is now well known and established in the field. No, because the software environment has changed a lot since its first release in 2006. For example, the way we today use apps, cloud-based solutions, and AI, not to mention security aspects and the shift towards using Agile methods for software development!
Q: Can we expect this to be covered by the upcoming edition 2?
A: No, not really. I would say the main goal for edition 2 is to align better with IEC 82304-1, which is a product standard for health software (including medical device software). The scope of IEC 62304 edition 2 will be broadened from medical device software to health software.
This expansion has provided some challenges such as ISO 14971 for risk management is currently a normative reference, which means you must comply with also ISO 14971 to comply with IEC 62304. This cannot be required for general health software developers while risk management still is a vital part of a medical device software development process!
Q: Many medical device software developers want to work Agile but find it difficult when reading IEC 62304, do you have any suggestions?
A: It is no secret that the standard is written very sequentially and implies a classical V-model approach, but you are free to work in any way you want! If you struggle with implementing the standard, I suggest you consider the standard as a list of requirements that you have to fulfill but you can disregard the order in which they are written.
For example, there is a requirement to “Verify software requirements” but if you find it appropriate, you can do this as part of your software release. I will not say that it is formally incorrect, but I would argue it is a risky approach since late discoveries during the verification might generate a lot of re-work.
Likewise, if you use Scrum, it might be appropriate to include the activity “Verify software requirements” in for example sprint planning and verify the requirements contained in a sprint. You could even consider verifying software requirements on a story-based level!
Figure 1: Incremental approach to verification of software requirements
Q: The IEC 62304 Software Safety Classification seems to be the most contested part of the standard. Is the industry using the Software Safety Classification the way it was intended according to you? Are there any aspects of it that you feel should receive more attention?
A: Interesting questions indeed… There have been many discussions over the past years about whether Software Safety Classification is needed or not. Some argue that Class C software development is the current state-of-the-art, and anything less than that is simply not acceptable these days. Still, Software Safety Classification will survive and remain in edition 2 (with some editorial changes).
Personally, I like the risk-based approach for two reasons; firstly, it increases the likelihood for low-risk software devices to enter the market which otherwise would have been too expensive and not make it to the market. Secondly, it increases the awareness of what parts of your software can be dangerous.
Q: Can you elaborate a bit more about your second point about awareness?
A: Early awareness of what can become harmful is a super valuable input to the architectural design because, with this information at hand, you can separate risky and non-risk functionality into different items. If this is done correctly, you can assign the appropriate classification to items and concentrate your safety efforts where it makes the most sense! And this is the essence of IEC 62304: focus your efforts on the risky parts!
Figure 2: Items in a software system can be classified differently
A final point on Software Safety Classification: note that the concept is based on injury, not harm as in ISO 14971. Harm is a much broader concept than injury and includes damage to property and environment which strictly speaking does not need to be considered when determining a Software Safety Classification.
Q: The IEC 62304 Problem Resolution chapter has received some heat regarding the (at least perceived) overly cumbersome approach. Do you think there is any substance to these claims? Are there any best practices for how to best tackle the Problem Resolution requirements of the standard?
A: Yes, the Problem Resolution is a bit strange to follow in the standard. Throughout the standard, there are requirements to use a “problem resolution process”.
However, in most cases, it does not make sense to use such a process as it is defined by clause 9 “Software problem resolution process”. For example, if a bug is discovered during a system test and the software is still not on the market, it does not make sense to “advice relevant parties”!
My approach to this is to use a scalable process and use different approaches depending on whether the problem relates to released functionality or not. Where a problem relates to a released functionality, regardless of found internally (“Internal feedback”) or externally (“Feedback”), then all parts of clause 9 apply.
For all other problems, I use selected parts of clause 9 and work with a generic software problem resolution process.
Figure 3: An approach to manage a software problem resolution process
About Christian Kaestner
Christian has recently released an online course about medical device software and IEC 62304 in collaboration with Medical Device HQ. The full course can be found here, and if you are interested in a free short version, you can find it here on YouTube.
Christian Kaestner is a freelance software medical device consultant who often worksin close collaboration with QAdvis AB in Sweden. He is a member ofthe project team authoring IEC 62304 and was also part of the project team developing IEC 82304-1.
