Software in Medical Devices, by MD101 Consulting

To the surprise of the reader, IEC/TR 60601-4-5 is removed from the draft list of harmonized standards.
This changes a lot, and at the same time, this changes nothing. Let's see why.

Changes a lot

This standard won't be harmonized. Thus, it won't be mandatory. That sound consistent with the fact that this is not a standard, but a Technical Report (TR) without any normative part.
It was probably the result of a mistake, to include this TR in the draft list. Actually a draft list for at least one good reason!

The consequence is the possibility to disregard its content as mandatory requirements (hum, not mandatory, but presumption of conformity, same old story):

• So Notified Bodies (NB) shouldn't take this TR as presumption of conformity to General Safety and Performance Requirements (GSPR) on cybersecurity (GSPR 17.2 and 17.4 to be specific).
• So, you shouldn't have to present some kind of traceability matrix of your device's requirements with IEC/TR 60601-4-5 requirements.
• So, the NB Technical File reviewer shouldn't be obliged to make a disastrous hilarious fastidious comprehensive review of this traceability matrix with dozens of remarks.
• So, you shouldn't have to answer to all these remarks.
• Bonus: so NB's shouldn't have to train their reviewers to this standard (not sure, see below).

This is a big change!

Changes nothing

Anyway, the TR is referenced 4 times in notes of the normative part of IEC 81001-5-1, which stays in the list.
In clause 5.2.1 HEALTH SOFTWARE SECURITY requirements, the Note 1 reads:
IEC TR 60601-4-5 gives guidance on the specification of SECURITY CAPABILITIES and their documentation in the ACCOMPANYING DOCUMENTATION and provides a method of determining requirements from the SECURITY CAPABILITY level.

You'd better be prepared to justify it, if you choose another method of determining your security requirements!


More, in clause 6.1.1 Timely delivery of SECURITY updates, the standard references in the body text (and not in a note) IEC 60601-4-5 as additional guidance.

You'd better be prepared to justify it, if you choose policy different from IEC 60601-4-5 for delivering security updates!


As an alternative, you could use FDA guidances on cybersecurity, like Appendix 1 of the new draft FDA guidance on cybersecurity framework. At first sight, this could be a good option. The FDA cybersecurity framework is more mature. However it presents a drawback:

• Cherry-picking in the FDA guidance is not an option, you have to justify why you don't apply the rest of the guidance,
• FDA guidances cover both regulatory considerations, like MDCG 2019-16 and technical considerations like harmonized standards.
  

It means that you'll still have to apply MGCG 2019-16, putting apart the regulatory considerations of FDA guidances, in your CE mark technical file. That's a kind of balancing act between two regulations.


So, we're a bit stuck to IEC/TR 60601-4-5 even though it cannot be harmonised.

That changes nothing!


So, we do our homework and take IEC 81001-5-1 and IEC 60601-4-5 in our list of standards and guidance, part of our design input.
No escapes.