The Health Sciences Authority (HSA), Singapore’s regulating authority in the sphere of medical devices and other healthcare products, has published a guidance document dedicated to software medical devices in the context of a life cycle approach. The document provides additional clarifications regarding various regulatory matters including, inter alia, the aspects related to cybersecurity. The guidance provides non-binding recommendations to be considered by medical device manufacturers (software developers) and other parties involved to ensure compliance with the applicable regulatory requirements. However, the authority mentions that in case of any discrepancies with the respective provisions of existing legislation, the latter should prevail. 

 

Regulatory Background 

The HSA acknowledges the increasing importance of cybersecurity-related matters in the context of medical devices used in various local and global networks. Failure to ensure cybersecurity and protection against respective hazards could result in significant harm caused to patients and operations of a healthcare institution in general. Hence, cybersecurity is vitally important to ensure the safety and effectiveness of medical devices that require connection to a network when being used for the intended purpose. In this regard, medical device manufacturers (software developers) should consider cybersecurity-related matters from the very first steps of the device’s design and development process to be able to implement measures and controls necessary to address potential risks. 

The authority additionally emphasizes that the responsibility for ensuring the cybersecurity of medical devices should be actually shared among all the parties involved in manufacturing and use, and thus should not be limited to medical device manufacturers. However, the manufacturer remains to be the main responsible party as the one that can contribute the most to ensuring the continued safety of its products. 

Class I Software Medical Devices 

Class I is the lowest class under the applicable classification system and applies to the devices with the lowest risk associated thereto. Hence, the applicable regulatory controls are quite low as well. In the case of software-based medical devices, this class applies for the devices that are:

  • Intended to monitor the state or progression of a disease;
  • Providing information that does not indicate if an individual may be in danger;
  • Associated with a low public health risk. 

Class IIa Software Medical Devices 

This category applies to medical devices associated with medium risk. An example provided by the TGA describes diabetes diagnosis software that is intended to be used by a healthcare professional. Thus, such a product is a Class IIa medical device as the device provides information to a relevant health professional to inform the diagnosis of a serious disease. This category also covers risk prediction software, as well as the tools that record data from a patient monitor or images directly from an MRI scanner (provided that such software does not impact the operations of a scanner itself). 

Class IIb Software Medical Devices 

This category applies to medical devices associated with medium-high risk. For instance, such classification should be applied to a product that is intended to analyze a cardiac MRI in order to provide information used in making diagnoses of related diseases. As in the previous example, the software is intended to provide information to healthcare professionals only. As described in the guidance, Class IIb applies to medical software that is intended by the manufacturer (the software developer) to provide information to a relevant health professional to inform the diagnosis of a serious disease. Other examples of Class IIb products include tools intended to be used to diagnose an acute arterial occlusion due to the severity of potential consequences of this disease if the necessary treatment is not applied. This category also covers software products that are intended to provide recommendations for treatment or intervention on the basis of input data (e.g., a coronary angiogram). As in the previous cases, such software should be used only by healthcare professionals. Consequently, a Class IIb software-based medical device is the one that is intended to:

  • Recommend a treatment or intervention to a relevant health professional for the purposes of making a decision about the treatment or intervention; and 
  • Be used in cases when the absence of a treatment or a treatment itself could result in severe health deterioration or other adverse consequences. 

The same classification applies to wearable devices intended to collect and analyze data for screening for serious heart diseases, as well as questionnaire apps intended to analyze the information provided by a patient and provide a diagnostic output. 

Cybersecurity Considerations 

The guidance further highlights the most important aspects to be taken into consideration by medical device manufacturers (software developers) in the context of cybersecurity and addressing respective hazards. As described by the HSA, the appropriate plan should be developed and implemented. Such a plan should include, inter alia, the following elements:

  • A secure device design;
  • Having proper custom security documentation;
  • Conduct cyber risk management;
  • Conduct verification and validation testing; and 
  • Having an ongoing plan for surveillance and timely detection of emerging threats. 

The first point applies to the design of a medical device as one of the initial development stages. According to the guidance, medical device manufacturers should consider cybersecurity-related matters from the very beginning. In particular, the HSA states that manufacturers should take into account all possible cybersecurity hazards and consider design inputs that could reasonably secure the device and prevent, detect, respond, and where possible recover from foreseeable cyber risks. The examples of such considerations include the measures intended to prevent unauthorized use of a medical device (e.g., user authentication or authorization checks), the actions to be taken to detect potential cybersecurity risks (including but not limited to continuous monitoring), the way the manufacturer will respond to cybersecurity incidents (including the actions to be taken to mitigate the newly identified risks), and also recovering from cybersecurity incidents as a set of measures to be taken to recover the correct functioning of a device. 

As described by the HSA, the medical device manufacturer should duly communicate to users of the device all important information including, inter alia, the details related to cybersecurity and protection against hazards associated thereto. In particular, the authority states that medical device manufacturers could supply not only general Instructions for use (IFU) but also additional security-related documentation describing the way the cybersecurity risks could be mitigated when the device is used for its intended purpose in the appropriate use environment (e.g., clinical setting). The aspects to be considered when developing additional cybersecurity documentation should include, inter alia, the following ones:

  • It is important to ensure the information about potential risks and hazards associated with the device is duly communicated to its users. Furthermore, the manufacturer should provide additional recommendations regarding the way these risks could be mitigated. Such details could be indicated in the labeling and/or instructions for use.
  • Recommended infrastructure requirements to support the device in its intended use environment. 
  • Details about ports and interfaces, as well as their functionality and use. In this context, the manufacturer could also provide details on disabling some of the ports to prevent unauthorized access. 
  • The procedures to download and install updates from the manufacturer. 
  • Additional details regarding the device support period and risks remain upon expiration of the support period. 
  • A Software Bill of Material (SBOM) includes but is not limited to a list of commercial, open-source, and off-the-shelf software components including the version and build of the components, to enable device users (including patients and healthcare providers) to effectively manage their assets, to understand the potential impact of identified vulnerabilities to the device (and the connected system) and to deploy countermeasures to maintain the device’s safety and performance. 

The HSA additionally mentions that due to the high sensitivity of the information listed hereinabove, the manufacturer should determine a secure channel to be used to communicate this information to device users, as unauthorized disclosure of such information could result in additional cybersecurity risks. 

When describing the matters related to managing cybersecurity risks, the guidance refers to the general principles outlined in ISO 14971. The risk management plan to be developed and implemented by medical device manufacturers (software developers) should include such elements as:

  • Identify all possible cybersecurity hazards;
  • Assess the associated risk;
  • Implement mitigations or controls to reduce risks to an acceptable level; and
  • Observe and evaluate the effectiveness of mitigation measures. 

Moreover, the risk management process should be continuous – the appropriate measures should be taken within the whole life cycle of software. According to the guidance, these measures should be duly documented. As further described in the document, the risk management plan should address the following aspects:

  • The approaches and methods to be applied to identify vulnerabilities and determine the ways these vulnerabilities could be mitigated.
  • Evaluation of cybersecurity measures in the context of overall patient safety. The document provides an example of a situation when multi-factor authentication makes it difficult to use the device in case of an emergency. 
  • Implementation of an ongoing monitoring and surveillance program to identify threats and vulnerabilities. According to the guidance, the aspects to be taken into consideration when assessing the vulnerabilities include such factors as the exploitability of the vulnerability, and the severity of user/patient harm if the vulnerability were to be exploited. 

In summary, the present HSA guidance highlights the most important aspects associated with cybersecurity in the context of a life cycle approach applied to software medical devices. The document outlines the factors to be considered by medical device manufacturers to ensure the continued safety of medical devices that require connection to a local or global network. 

 

Sources:

https://www.hsa.gov.sg/docs/default-source/hprg-mdb/gudiance-documents-for-medical-devices/regulatory-guidelines-for-software-medical-devices—a-life-cycle-approach.pdf 

How Can RegDesk Help?

RegDesk is a next-generation web-based software for medical device and IVD companies. Our cutting-edge platform uses machine learning to provide regulatory intelligence, application preparation, submission, and approvals management globally. Our clients also have access to our network of over 4000 compliance experts worldwide to obtain verification on critical questions. Applications that normally take 6 months to prepare can now be prepared within 6 days using RegDesk Dash(TM). Global expansion has never been this simple.