Software in Medical Devices, by MD101 Consulting

The date of adoption of these standards is set to May 2024 in this standardization request, which contains the list of harmonized standards for the MDR and IVDR.
I put deliberately apart the IEC 80001-1, it deals with network security. In this post we focus on the two other standards, which deal with software design and maintenance.

Standardization request with draft standards, this sounds far from being applicable. But if you’re a manufacturer of AIMD or electromedical devices, the lifecycle of your devices streches on several years. MD design can take ages! Thus, it’s worth having a look at these drafts, to see what the Notified Bodies’ expectations will be in 2024. So, for the next generation of your devices being currently designed.

Given the design cycle of a MD, it is recommended that manufacturers designing connected devices look closely at these two standards, even if IEC 81001-5-1 is in draft status. Furthermore, there is no doubt that these standards will be recognized by the FDA. The secretary of the working group is in the US, suggesting that the FDA is in the loop.

Impact on the design process of connected MDs

IEC 81001-1-5: its title and structure are borrowed from IEC 62304. It is made for ease of reading by teams experienced in MD software design, but with poor or no experience in secure software lifecycle. IEC 81001-5-1 complements IEC 62304 with tasks related to cyber security.


IEC/TR 60601-4-5 defines a list of security requirements to be injected in your Hardware Requirement Specification (HRS), Software Requirement Specification (SRS), and accompanying documents.
Here is an example of security requirements:

These two standards work together. The first one defines secure software processes (the “how to”), the second the software security requirements (the “what”).

Where do these two standards come from?

Cybersecurity has been a concern for a long time is other industries, which were subject to digitization and interconnection earlier than healthcare. In our case, these two standards are a transposition of two standards named IEC 62443-4-1 and IEC 62443-4-2 for Industrial Automation and Control Systems (IACS).

Why standards from IACS and not ISO 2700X, or other references coming from banking and finance (a sector where cybersecurity is a high concern)?
Because IACS networks and HIS networks have strong similarities.

Here is a copy of a diagram from IEC/TR 60601-4-5:
We have an industrial firm with:

• Headquarters or administration offices,
• Production plants,
• production lines with machines and PLCs

Similarly, we can have a similar structure in an healthcare center, where we find:

• Administration managing patients ins & outs and patients’ data,
• Patients rooms with near-bed medical devices, some of which may be life-critical,
• Intensive care rooms and Operating rooms with life-critical medical devices.

This similarity in the structure advocates for transposing the IACS cybersecurity standards to the medical device sector. It is worth noting that the FDA has the same approach, hence IEC 62443-4-1 is a FDA recognized standard.

Industries have to protect their personnel from injury with industrial machinery, their data from theft, their IT systems from breakdown and their production lines from costly production stops. Likewise, healthcare centers have to protect their patients, their personnel, patient data, their HIS from life-threatening hazards, and their healthcare services from costly shutoff.

Note: ISO 2700X family remains relevant for datacenters storing data (especially health data) and containing data management services.

Content of IEC 81001-5-1

The table of contents IEC 81001-5-1 is copied from the one of IEC 62304, organized in processes. The 6 processes of IEC 62304 are illustrated in the diagram below.
Likewise, IEC 81001-5-1 defines security processes throughout the software lifecycle.

No software safety class

It’s worth noting that there is no equivalent of software safety class in IEC 81001-5-1. It means that, contrary to IEC 62304, all requirements of IEC 81001-5-1 are applicable for any software whatsoever.
E.g.: requirements on detailed design present in IEC 81001-5-1 are applicable even if your software is in class A with IEC 62304.

Fortunately, even if documentation of detailed design is required by IEC 81001-5-1, it doesn't go as deep as IEC 62304 where all software units shall be 100% documented. IEC 81001-5-1 only requires documenting secure design and secure interfaces. That can be reduced to a subset of all software units.
So, the effort of software design documentation with IEC 81001-5-1 is higher than simple IEC 62304 class A software, but not so different from what is required for IEC 62304 class B.

Instead of software safety class, IEC 81001-5-1 recommends using the concepts of security level (SL) and security capabilities (SC) found in IEC/TR 60601-4-5, and discussed below.

Origin of weaknesses

A principle of secure software lifecycle is that security weaknesses can be introduced in every step of the software lifecycle:

• specifications: wrong behavior specified,
• architecture: unsecured architecture,
• detailed design: unsecured interface detailed design,
• coding: language traps or wrong coding patterns,
• make / build: unsecured generated binary or bytecode,
• install, configure: wrong installation or configuration.

This is why IEC 81001-5-1 requires to document all the steps of the secure SDLC, disregarding the concept of software safety class. This is also why it covers the full software lifecycle, like IEC 62304.

Content of IEC/TR 60601-4-5

I don't know what effect it has on you, but when I see a standard number with 60601 in it, I frown!
Does it mean that we'll need a certificate from a security lab? Fortunately not! Because this standard is named with TR, which stands for Technical Report.
However, we see some offers on cybersecurity testing blossoming from IEC 60601-1 accredited test labs. So, a TR is not a standard, but we could come up to a situation where, despite the TR, a test report from accredited test labs may be requested by the notified bodies or the FDA.

IEC 60601 series is not applicable to standalone software. But in this technical report, the introduction mentions that: MEDICAL DEVICE SOFTWARE, although not in the scope of IEC 60601 (all parts), can also make use of this document. Thus, this technical report can be applied to standalone software! No, software editors, you can't escape like that!

Definition of safety requirements for connected MDs

The IEC/TR 60601-4-5 is based on the requirements of the IACS IEC 62443 family of standards, which is very engineering-intensive for its implementation.

This guide defines Security Levels (SL) and Security Capabilities (SC), which depend on the impact of a security breach on the system. SL and SC are borrowed from the IEC 62443 family.
The SLs are on a scale of 0 to 4 - Definition (IEC 62443-1-1):

• SL 0 - No prevention.
• SL 1 - Prevent the unauthorized disclosure of information via eavesdropping or casual exposure.
• SL 2 - Prevent the unauthorized disclosure of information to an entity actively searching for it using simple means with low resources, generic skills and low motivation.
• SL 3 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with moderate resources, medical device specific skills and moderate motivation.
• SL 4 - Prevent the unauthorized disclosure of information to an entity actively searching for it using sophisticated means with extended resources, medical device specific skills and high motivation.

Like IEC 62304 subsystems with different security classes, security zones can be defined with different SL. It means that a medical device can have more than one security zone, with different SL.
This could be the case for a home-use device, with two security zones:

• one connected to the internet in SL3,
• and one with life-critical functions in SL1, isolated from the first.

Of course, like IEC 62034, the security zones shall be segregated. And of course, like IEC 62304, IEC/TR 60601-4-5 doesn't define the kind of technical measures required for an effective segregation!

Foundational requirements

IEC/TR 60601-4-5 defines a total of 7 Foundational Requirements (FRs), borrowed from the IEC 62443-1-1:

• Identification and authentication control (IAC)
• Use Control (UC)
• System Integrity (SI)
• Data Confidentiality (DC)
• Restricted Data Flow (RDF)
• Timely Response to Events (TRE)

These 7 FR are refined in 123 requirements. That's a lot of requirements!
But not all requirements are always applicable. The 123 requirements are only applicable to software in SL4. It can be easily seen that SL3 and SL4 are the SL with a higher overhead. For software in SL1, "only" 50 requirements are applicable.

These security requirements found in IEC/TR 60601-4-5 can be seen a "reservoir" of secure product requirements to be refined in HRS and in a Secure SRS document or a security section in the SRS.

SL Vector

IEC/TR 60601-4-5 § A.6 allows to define different SL, according to the types of foundational requirements applicable. For example, for a device that does not handle confidential data, the SL for data confidentiality (DC) will be set to 0, whereas the SL for the system is 4.
This "SL vector" approach (the term used in the standard) is possible for any system. This is a way to make a lighter list of security requirements applicable to your device.

IEC 81001-5-1 and IEC/TR 60601-4-5 work together

IEC 81001-5-1 and IEC/TR 60601-4-5 work in combination, the former defining a secure software development process, the latter feeding this process with security requirements.
This is illustrated in the following diagram, where IEC 81001-5-1 defines the secure SDLC, and IEC/TR 60601-4-5 "injects" security requirement at system level (above the horizontal dotted line) and at software level:

Conclusion

Draft standards in a standardization request, the state-of-the-art is being constructed. IEC 81001-5-1 and IEC/TR 60601-4-5 are clearly paving the way to future conformity to cybersecurity requirements. In EU and in the US. We can take the bets that their approved version will be soon recognized by the FDA and harmonized in 2024 as planned in the EU.

Edit 2021/07/15: unofficial information, IEC 81001-5-1 should be published by the end of 2021 or early 2022.