Europe’s healthcare standard – why it matters to the IoT market

By Jill Britton, Director of Compliance, Perforce 

This is the first standard to address the specific requirements of healthcare software with respect to security. It supplements existing standards such as IEC 82301-1 and IEC 62304, which are more about the general requirements of the software lifecycle and its safety. The harmonisation means that the EU will allow the standard to be used for conformance with certain areas of EU law.   There are a few essential aspects to know about IEC 81001-5. First, the recent standard applies to many more organisations involved in IoT medical and healthcare systems, as it not only covers software in medical devices and software as part of hardware intended for health use but also software-only products for health use. 

In practice, this means the standard covers equipment and systems that might be found in hospitals and other professional healthcare environments, plus consumer electronics, including smartwatches and apps. So, many more organisations will need to get up to speed if they need to comply with IEC 81001-5-1, including those unfamiliar with standards compliance. Communications with manufacturers and healthcare delivery organisations (HDOs) will ultimately be part of the standard, as both provide services that use the software in question. 

Time to act

With IEC 81001-5-1’s harmonisation in the EU expected during May 2024, organisations are already working on its adoption, as the deriving and implementing the necessary processes can take months. That said, organisations that already comply with existing standards and directives, for instance, the aforementioned Medical Device Regulation (MDR) 2017/745, IEC 62443-4-1 and ISO 14971, will already have relevant experience and hence a head-start on adoption. 

Indeed, the foundation of IEC 81001-5-1’s structure is based on IEC 62304, but focusing on security instead of safety, although the latter’s safety classes – which concern the risks – will not apply. However, IEC 81001-5-1’s scope goes broader and more profound, involving a greater range of software and looking at foreseeable unauthorised access and not just the intended use. Hence, even for organisations with established compliance processes, there is still quite some effort and time involved in achieving IEC 81001-5. 

Practical steps

Once IEC 81001-5-1 is harmonised in the EU, it can be used for conformity to EU law.  However, before that, since the published standard is already available, organisations can already be understanding and implementing the processes required. These encompass security throughout the software lifecycle, including development and maintenance, configuration, security risk management and resolution of problems. 

To comply with the standard, manufacturers will be required to instigate secure coding standards, and Appendix A of the standard provides best practices. These include removing backdoors and protecting debug information from unauthorised access. IEC 81001-5-1 requires identification of which coding standards are being used, how they are being enforced, and agreed mitigation actions. 

Other best practices include avoiding any development and design patterns known to potentially introduce security vulnerabilities, banned functions (of which public lists are available), and code that involves undefined and unspecified behaviour.  

Published coding standards

IEC 81001-5-1 recommends using a published coding standard to support these best practices and includes a reference to ISO/IEC TR 24773, MISRA-C, SEI CERT C, and SEI CERT C++. In addition, IEC 81001-5-1 advises automated tools, such as static analysis tools, to enforce secure coding standards. These automatically check code as it is being written and raise alerts should it detect any vulnerabilities or non-compliant actions. Consequently, developers do not have to spend time manually verifying code (a coding standard might have hundreds of rules), and the risk of human error is dramatically reduced.

Checks can also be repeated after every code change across the entire software lifecycle, including maintenance phases, so that regulatory bodies and software users can be alerted to any vulnerabilities detected and provided with a resolution, such as a software patch. 

Beyond published coding standards, other valuable resources include databases like the Common Weaknesses Enumeration (CWE), giving developers access to known issues so that these can be incorporated into code inspection and testing strategies. Apart from tools and processes, it is essential to encourage a ‘security first’ culture, with cyber security being considered at every step of the health software lifecycle, internally and in any third-party organisation. 

Given concerns around the security of health and medical systems, which if hacked could potentially have an adverse effect on humans, the harmonisation in the EU of this standard should be welcomed. Since IEC 81001-5-1 compliance will mean some additional workload, so it makes sense to start planning to minimise the impact so that any IoT firm involved in healthcare is ready, giving its customers confidence that security is being prioritised.