Full house at "IEC 62304 - how to make it work" seminar
There was standing room only when Mr. Robert Ginsberg, CEO of Qadvis and co-author of IEC 62304, and his team presented best practices and lessons learned at Marriott Courtyard Hotel in Zürich on March 31st.
Ginsberg's session addressed common questions arising from medical device manufacturers' attempt to implement the harmonized standard IEC 62304 "Medical Device Software".
"Even though many IEC 62304 issues are context dependent, there are a few persistent problems that I come across time and again.", says Mr. Ginsberg.
Not enough focus on Software Quality - manufacturers tend to stare themselves blind on the documentation required for IEC 62304 and subsequently lose focus on the intended goal of the standard, namely to increase software quality."
Lost traceability - we keep detecting gaps in the traceability during the audits we perform, particularly regarding how risk control measures are implemented as software requirements and how they are subsequently verified. Traceability is an immensely complex task to manage as the project evolves and I highly recommend using software support tools available to handle this activity."
No connection from the field to R&D - I can't stress this enough: post-market surveillance is one of the main focuses of the regulation. It is an incredibly important indicator on how the software is actually performing. Still, it is also one of the most neglected aspects of the software life cycle. Post-market data contains a virtual goldmine of opportunities for increased software quality and should be properly addressed."
Non-value added activities to fulfill IEC 62304 - The standard is not about producing alibi-documentation, it is about increasing software quality. In one "agile" firm I worked with, the detailed design was extracted from the existing code base after the coding was complete, using a software UML extractor. But documenting the detail design in such a matter provides no added value to the software quality whatsoever."
Too shallow risk management - Risk management is not an administrative activity to make Notified Bodies happy. It is the driver of improved software safety and quality. Therefore, to be able to improve safety, the depth of the analyses needs to increase.
Mixup of concepts - the terms 'SW validation' (as defined e.g. by AAMI:TIR 36), 'product validation', and 'product verification' do not denote the same thing and these terms can therefore not be used interchangeably. IEC 62304 is not concerned with any types of validation activities. Do be clear vis-a-vis the auditors, formally define the terms as you intend to use them, and apply them consistently within the company and in your documentation.
Too strict interpretation of segregation - There is this note in IEC 62304 that indicates that the only possible segregation of items is to execute them on separate hardware. This is not entirely true. Soft segregation on a functional and/or logical level can be entirely appropriate depending on the risk the segregated items expose. The main point is that your segregation must be well-argued, proven to be effective, and documented.
Using system-level testing as a risk control measure - testing is by most notified bodies no longer accepted as a risk control measure. An RCM should result in a new SW requirement which in turn is verified.
No metrics supporting the process - having no metrics showing how well your software performs, might lead to unconstructive arguments with your auditor about the true level of safety your software retains. It is my advice to define and use performance metrics to support your case of having developed a high-quality software and in particular, make use of the available field data."
"This is by no means an exhaustive list but, as I mentioned, I see these issues a lot and I think the effort needed to address them is relatively cost-effective. Should you have any further questions, I'd be happy to address them afterward.", Mr. Ginsberg concludes.
The Aligned team presentation, with a focus on the documentation tasks required by IEC 62304, addressed the issue of conceptually connecting the software architecture and the risk management in the development documentation.
By using a concrete example, Aligned demonstrated how a Preliminary Hazard Analysis as a risk assessment could be used in their medical device ALM software "Aligned Elements" to not only fulfill the traceability requirements of IEC 62304 but also successfully connect the software architecture with existing risk assessments.
The seminar was concluded with a host of interesting and constructive discussions among the participants at the subsequent lunch buffet supplied by Marriott.