An increasing number of pacemakers, insulin pumps and other medical devices incorporate software and can also connect to the Internet, hospital networks or smartphones. In this way, diagnostic data can be transmitted and evaluated in real time using for instance artificial intelligence (AI), thus allowing anomalies to be detected at an early stage and precise statements to be made about treatment effectiveness. Connectivity also serves to monitor performance of a device or equipment, enabling medical staff to respond quickly in case of failure or malfunction.

However, the increasing use of connected medical devices is fraught with significant cyber-risks. Cybercriminals are interested in confidential information, such as patients’ names and addresses or health data, including existing illnesses, prescribed medication and treatments, and insurance information. In a worst-case scenario, hackers exploit vulnerabilities to gain control of medical devices and manipulate their clinical performance, which may result in severe health damage. In 2017, for example, the FDA ordered the recall of 465,000 pacemakers from the market over a vulnerability which would have allowed unauthorized access by third parties.[1]

The Legal Framework in Europe and the U.S.

Annex I to the Medical Device Regulation (EU) 2017/745 lists general safety and performance requirements. The Annex also includes six explicit cybersecurity requirements. These cybersecurity requirements of the regulation are described in far greater detail in the guidance document “MDCG 2019-16 Guidance on Cybersecurity for medical devices,” published by the Medical Device Coordination Group. In the U.S., the FDA has also published several guidance documents since 2014, the most recent entitled “Cybersecurity in Medical Devices: Quality System Considerations and Content of Premarket Submissions” (currently still in the draft stage). On top of that, there is the U.S. Cybersecurity Framework from the National Institute of Standards and Technology (NIST).

There is rising public awareness that increasing cyberthreats are calling for practice-focused protection measures. The introduction of Technical Report IEC TR 60601-4-5, setting out technical cybersecurity requirements that are widely accepted by the industry, is further proof of this. However, no general consensus has been reached to date on an approach that would cover the entire life cycle of health software from its development to post-market activities after being placed on the market.

New IEC Standard Explicitly Addresses Cybersecurity

The International Electrotechnical Commission (IEC) has now addressed this issue. After three years of extensive discussion and debate, it published its security life cycle standard for health software in late 2021: IEC 81001-5-1 “Health software and health IT systems safety, effectiveness and security – Part 5-1: Security – Activities in the product life cycle.” The standard addresses the challenges of software-related cybersecurity in medical devices, complementing the software life-cycle standard IEC 62304 “Medical device software – Software life cycle processes”.

IEC 81001-5-1 generally addresses all developers and manufacturers or vendors of health software. Health software in this context may present in the form of fitness, yoga, nutrition and diet apps, software to be embedded in medical devices or systems, or software as a medical device (SaMD). For the first time, IEC 81001-5-1 also addresses the relationship between healthcare delivery organizations (HDOs) and manufacturers or vendors, which share responsibility for maintaining cybersecurity. Shared responsibility is designed to ensure that manufacturers or vendors provide operators with sufficient information about the safe and secure operation of the devices, to enable operators to inform them in a timely manner in case of problems.

Helpful “Best Practices”

Comprising roughly 60 pages, the standard gives manufacturers or vendors and developers an extensive overview of the necessary activities, precautions, documentation and requirements. The latter are explicitly phrased and thus clearly outlined, qualifying the document as a roadmap for the implementation of software-related cybersecurity. In addition to general requirements, such as introduction of a quality-management system and a security risk-management system, the standard defines the specific activities that manufacturers or vendors and developers must implement throughout the lifecycle. This concerns issues such as software development and maintenance, management of security risks, software configuration and problem-solving.

The Annexes to the standard also include information about best practices for secure coding. Annex B provides instructions on how to implement the activities described above to ensure secure lifecycle of health software. Annex C includes a detailed description of approaches for developing threat scenarios and of how systematic security analysis helps to identify hazards more easily and take prioritized actions. Software manufacturers or vendors can thus draw helpful examples and information for their product development from the standard itself. And the support provided by testing, inspection and certification (TIC) companies specializing in this field can be helpful for testing cybersecurity in practice.

An increasing number of medical devices and software will be connected in the future, resulting in a growing attack vector. Ensuring effective protection is thus all the more important. Given this, the EU Commission is expected to recognize the IEC 81001-5-1 standard by May 2024 at the latest. In the U.S., classification of the standard as “Recognized Consensus Standard” is expected shortly. Regardless of when this takes place and in which jurisdiction, manufacturers, vendors and developers that design their products for compliance with the new standard and the state of the art today will be on the safe side tomorrow, and fit for the future.

Reference:

[1] blogs.cisco.com/healthcare/fda-announces-first-ever-recall-of-a-medical-device-due-to-cyber-risk