Software in Medical Devices, by MD101 Consulting

I will not bother to explain the reason why IEC 62304 2nd edition will include MD software, as well as Health software. The consequence is that ISO 14971 is not hardlinked to IEC 63204 any more.
I'm fine with that. Some others aren't. This isn't interesting (unless you're a MDSW guru).

Software process rigor

The spec introduces the concept of Software Process Rigor.
It was actually present in the previous draft versions, that were dismissed. That Software Process Rigor replaces the Software Safety Class.

And, Tadaaa, a two-level classification has been proposed to simplify the software classification process.
Exit the software safety class and the three levels!
Bonjour a twofold system with level I and II. The equivalences pointed by the design specification are:

• Current Class A is equivalent to level I,
• Classes B and C are intended to be level II.

Consequence:

• Level I is assigned to software when [it] cannot contribute to a hazardous situation,
• Level II is assigned when software can contribute to a hazardous situation, prior to mitigation action in this software.

We see here a bottom-up approach:

• No Hazardous situation => Level I
• Otherwise => Level II

Please note that a hazardous situation can lead to a non-serious or a serious injury.

Does it mean that, when software can contribute to a non-serious injury, a software process rigor similar to the current class C shall be applied?
There are some elements of answers to this question in IEC 62304 2nd edition design spec.

• About clause 5.4: Due to the flexible nature of this requirement and the capability of tools this should be appropriate for all software rigor levels.
  • I won't elaborate on the capability of tools. This looks like wishful thinking, when you have a sw development background...
  • The draft spec also mention replacing "Detailed Design" by "Design''. This is interesting to read this in relation to the flexible nature of this requirement. That leaves the door to more or less detailed design,
  • The draft spec also mentions the need for guidance in annex B.5.4. I think this will make a lot of guidance (imagine something being of practical use for: real-time software, daemon / kernel software, PC software, GUI, gui-less software, micro-services, middleware, web apps, mobile apps, rule engines, ... ML algorithms, ... SQL databases, NoSQL databases, ... industrial PLCs, industrial IHM panels, cobot scripts ... shell scripts ... Mathlab code ... and probably a lot more). This is one again wishful thinking to elaborate a guidance appropriate for all cases,
• About clause 5.5: no changes per the discussion
  • I already see how fun it will be to document additional unit acceptance criteria with software currently in class B,
  • As well as unit test strategy equivalent to class C (unless we also have flexibility here).

I've seen almost bitwise design for some real-time safety critical software in class C (and timelines almost documenting sw behavior at every CPU clock cycle). I've also seen more than lightweight unit design for class B software. The level of flexibility of new clause 5.4 and 5.5 will be like a rubber band used in bungee jumping.

FDA guidance compatibility?

We've seen in a previous post on the FDA guidance on Content of Premarket Submissions for Device Software Functions that the twofold FDA system is:

• Enhanced Documentation Level: where a failure or flaw of any device software function(s) could present a hazardous situation with a probable risk of death or serious injury
• Basic Documentation Level: where Enhanced Documentation does not apply.

We see here a top-down approach:

• Serious Injury => Enhanced documentation level,
• Otherwise => Basic documentation level.

Here is a little table to make it clear:

Compatibility between IEC 62304 Software Process Rigor Level and FDA Documentation Level equals zero.

And IEC 81001-5-1 compatibility?

We've seen in a previous post that IEC 81001-5-1 requires to implement a software lifecycle documentation closer to class B than class A.
It implies that class A documentation, as required by IEC 62304 2015, isn't possible. For example: it is not possible to skip architectural design when applying IEC 81001-5-1 . This is anticipated in IEC 62304 2nd edition design spec, with the following comments on clause 5.3:

• a certain level of Architecture planning is appropriate for all rigor level software products, and
• This is especially true to support cybersecurity requirements that should be addressed outside of IEC 62304.

So, compatibility with IEC 81001-5-1 is expected.

Effort of documentation

Based on the elements that we've seen above, we can make a comparison on the effort of documentation required by the aforementioned documents.

Please note once again that Level II is for software that could lead to minor injury or serious injury.

Conclusion

As proposed in a previous post on IEC 81001-5-1, we have a trend to foster inflation of documentation for medical device software. Documentation is a key aspect to demonstrate the rigor of software processes throughout its lifecycle. However, that rigor shall remain proportionate to the hazardous situations resulting from software failure.

Documentation shall not be overkill, especially when software can only lead to minor injury.
IEC 62304 2nd Edition is not taking this direction.