Software in Medical Devices, by MD101 Consulting

Impact of the standard

IEC 81001-5-1 requires to unroll a full set of cyber activities throughout the software life cycle and more precisely the software development lifecycle. This can represent quite an overhead, on top of existing IEC 62304 provisions.

Cyber design

Firstly, at design, the steps required by IEC 81001-5-1 supplement those of IEC 62304:

A short list of artifacts includes (but not limited to…):

• A bunch of new documents or document sections on architecture, detailed design (or new sections in existing documents)
• New design review criteria,
• A cybersecurity risk management file (cyber risk management plan and cyber risk assessment report),
• A software development platform (or a toolchain, name it as you prefer) with specific tools, which can lead to heavy license costs:
  • Static source code analysis,
  • software composition analysis,
  • fuzzers (e.g.: DICOM fuzzers for medical imaging),
  • black box common vulnerability scanning,
  • Dynamic Application Security Testing tools,
  • and some other specific to your software technology…
• The need to perform pen tests with an independent organization. That means paying for the services of such a gang of security consultants,

Cyber maintenance

After software release, it adds the need to monitor cyber issues in post-market phase. And update the cybersecurity risk management file.

It also requires to have people qualified in security: Security Advisor(s). A person, who takes this role, shall have appropriate evidence of qualification.

This list is only a subset of IEC 81001-5-1 provisions. Just to demonstrate the magnitude of the overhead. Practically speaking, IEC 81001-5-1 can be seen as a “second IEC 62304” in terms on work effort.

Do you remember the effort it took to implement IEC 62304 for the first time in your processes?
IEC 81001-5-1 will represent the same level of effort!

FDA risk-based approach

If we look at the US side, IEC 81001-5-1 is a recognized standard. It is also quoted as a possible Secure Product Development Framework (SPDF) in the FDA guidance on cybersecurity premarket documentation. More, this guidance describes activities and documentation deliverables very similar to IEC 81001-5-1 provisions.
Thus, at first sight, IEC 81001-5-1 shall also be fully applied to generate cyber documents shipped in a 510(k) submission.

However, the FDA accepts to apply a risk-based approach. If you can assert that your device:

1. Has a low cyber risk profile, and
2. Cyber risk don’t lead to unacceptable safety risks,

Then it is possible to reduce the documentation to an acceptable minimum.

This shall be backed with:

1. A documented threat model,
2. And, traceability between security risks and safety risks,

Giving evidence that your device has actually a low cyber risk profile.

That minimum set of documentation should include:

• A threat model,
• A security risk management plan,
• A security risk assessment report, with traceability to safety risks, when needed,
• Secure software requirement specifications (including security risk control measures),
• Test plans and reports with test cases covering these secure software requirements,
• Independent pen test plan and report,
• A Software Bill of Materials (SBOM),
• Warnings on secure software use in the Instructions for use,
• Secure operations guidelines in accompanying documentation (targeting end-users or people with a more technical background),
• A post-production surveillance on SOUPS, and security issues coming from the field.

The diagram below sums-up this course of action:

Note that the above list is a return on experience on 510(k)’s submitted the last few years. But FDA thinking may change on these matters in the near future. Don’t blame this blog if this doesn’t work with your device! And rub twice your threat model to the latest threat landscape in healthcare!

By the way, FDA's approach doesn't pop out of nowhere. FD&C Act SEC. 524B says that [Manufacturers shall] design, develop, and maintain processes and procedures to provide a reasonable assurance that the device and related systems are cybersecure (emphasis by me).

Transitional Health software

It is worth noting that the FDA low risk profile approach described above is close to the Transitional Health software approach found in annex F of IEC 81001-5-1.
This is depicted in the diagram below:

Transitional Health Software is a kind of IEC-62304-class-A-ish secure SDLC. Tasks at architectural and detailed design are skipped. However, some architecture-level documentation, like Data Flow Diagrams, are helpers for a sound threat model. But not the whole architecture, required by the full IEC 81001-5-1.

A major difference with FDA risk-based approach, however: transitional health software requires to implement the full secure software testing strategy found in 5.7 of IEC 81001-5-1. This testing strategy is per se quite an overhead!
And a second difference: “transitional” means that you shall have plans to be fully compliant to IEC 81001-5-1 in a further release of your software.

EU Notified Body binary approach

Today, IEC 81001-5-1 is not harmonized. Yet, it is considered as state-of-the-art (see IG NB questionnaires on cybersecurity (fortunately in English) and TEAM-NB position paper on cybersecurity).

But:
NB auditors are still at the bottom of a steep Everest-like learning curve. Being able to audit a QMS implementing IEC 81001-5-1 processes or evaluating cyber sections of technical files is still out of reach of (most of) NB personnel.
That will change in the near future. For sure.

That should (shall?) be the case in 2028, when IEC 81001-5-1 is harmonized.

So, to sum-up Notified Body thinking:

• Today: Manufacturer, thou shalt apply MDCG 2019-16 and give me a bare minimum (anyway, I don’t have qualified personnel to audit more than that),
• 2028: Manufacturer, thou shalt apply IEC 81001-5-1. From Genesis to Apocalypse. Otherwise, you’re non-compliant to The Cyber Writings and I'll put you a major non-conformity.

More: IEC 81001-5-1 quotes IEC/TR 60601-4-5 is its body text. For those of you who have experience with Notified Bodies, you know how it can be hard to disregard a document (be it a Tech Report), if it is quoted in a standard!
Thus, be prepared to have a traceability matrix between IEC 60601-4-5 high-level requirements and your secure software requirements. An additional overhead, compared to the FDA approach. Btw, IEC 60601-4-5 isn't recognized.

That will be the binary (stubborn, not risk-based, still regulatory oriented …) approach of Notified Bodies. Thus, you shall be fully compliant to IEC 81001-5-1 by 2028. Or your QMS and possibly your devices will be at regulatory risk.

That will probably be the last epic of the MDR – IVDR transition for medical device software.

Is IEC 81001-5-1 asking to much for?

No matter the risk profile of your device (the security level, if you follow the recommendations of IEC 60601-4-5), IEC 81001-5-1 is fully applicable.

The working group had in mind the following goals, when writing this standard:

• Weaknesses and vulnerabilities can be introduced at every step of the software lifecycle, and especially in the SDLC,
• Thus, every step of this lifecycle shall contain provisions to identify, evaluate, and track to closure weaknesses and vulnerabilities,
• This legitimate goal leads to a heavy secure SDLC, and more general to a heavy secure software lifecycle.

However, it can be called into question: is it necessary to apply all provisions for a low cyber risk profile device? Or is it possible to alleviate the burden in case of low cyber risk profile? And still claiming that we do our best effort, proportionate to the cyber risk profile?

State-of-the-art says that software development rigor shall be commensurate to the software risk profile. That's why we have:

• Software safety class in IEC 62304,
• Documentation levels (which replaced level of concern) in FDA guidance on premarket documentation for device software function,
• And, not official but practical, a risk-based approach accepted by the FDA provided that manufacturers's cyber documents give a reasonable assurance that the device is secure.

Yet, cybersecurity cannot be something only tested at the end, being ignored during design.

Proposition to update IEC 81001-5-1

This state-of-the-art advocates for such risk-based approach applied in IEC 81001-5-1 normative clauses.

Proposition: To add to IEC 81001-5-1 a system similar to IEC 62304 software safety class, based on the Capability Security Level (SL-C) claimed by the manufacturer, from the Intended Context of Use.
With:

• For SL-C 1 and 2: a lighter secure SDLC similar to the Transitional Health Software annex:
  • SDLC clauses 5.1, 5.2, 5.7.1, 5.7.2, 5.7.4 and 5.8 are applicable,
  • Clauses 4.1.1, 4.1.2, 4.1.3, 4.1.4, 4.1.5, 4.1.7, 4.2, 6, 7, 8, and 9 are applicable,
  • Other clauses aren't applicable.
• For SL-C 3 and 4:
  • The full text.

This would lead to an approach similar to IEC 62304 class B, or FDA Basic Documentation Level, for software in SL-C 1 or SL-C 2.


Hope it helps...