Artificial Intelligence (AI), General Data Protection Regulation (GDPR) and Cybersecurity: 10 Misconceptions About Medical Device Software

Medical Device Software (MDSW) is a growing, fast-evolving industry. However, manufacturers must often face a regulatory framework which does not evolve at the same speed. Regulation for medical devices is restrictive, since it needs to guarantee the safety of users (e.g. professionals) and the target population (e.g. patients). Moreover, it has experienced a significant increase in requirements with the approval of the new regulation MDR 2017/745. Manufacturers of MDSW who have never placed a medical device on the market, or who did it under the former Medical Device Directive (93/42/EEC MDD) might have some misconceptions about the process. In this article, experts from Veranex will address some of the most common (and sometimes incorrect) assumptions and provide useful and truthful information about the process of  reaching the conformity assessment under MDR, for successfully placing an MDSW on the market.

10 Misconceptions About Medical Software

1. MDSW is classified as low risk under the MDR 2017/745. 

False! Only a small portion of MDSW is classified with the lowest risk class (class I) according to the new regulation (MDR2017/745 annex VIII) and related guideline (MDCG 2019-11). To classify a Medical Device Software, two main aspects must be taken into account: 1) the severity of the healthcare situation or patient condition and 2) the significance of the information provided by the software to the healthcare situation, particularly if related to diagnosis/therapy. After taking these factors into consideration, most MDSW is classified in higher classes, from Class IIa to Class III, which involves increased regulatory requirements.  

2. Agile development practice and IEC 62304 requirements cannot co-exist because they rely on fundamentally conflicting principles. 

Agile methodologies (such as Scrum and Kanban) are actually compatible with the standards (e.g., IEC 62304) for the development of Medical Device Software. However, manufacturers can face potential challenges in ensuring that agile practices, such as continuous delivery and frequent iterations, align with the regulatory expectations for documentation, risk management, and traceability outlined in IEC 62304. The key is to find a balance that allows for the benefits of agile development while meeting the regulatory requirements for medical device software. The Technical Information Report AAMI TIR45:2023 provides useful guidance on the use of Agile practices in the development of medical device software. Note that the document is focused on complying with U.S. regulations and does not specifically address European laws.    

3. I have developed a Machine Learning model that underwent thorough testing and showed excellent technical performance, so I should be able to access the market in a few months. 

All AI-enabled MDSW must comply with the applicable MDR 2017/745 requirements prior to being placed on the market. To demonstrate compliance with regulatory requirements, there are device specific requirements that must be fulfilled for (e.g., clinical evaluation of Medical Device Software as per MDCG 2020-1). For any MDSW, the manufacturer should demonstrate its valid clinical association/scientific validity, technical performance, and clinical performance. This guidance on clinical evaluation of MDSW provides a framework for determining the appropriate level of clinical evidence required. You should consider the provisions of this guidance document beginning in the early stages of software development. Lastly, market access for a device also depends on conformity assessment route. The participation of a notified body in the conformity assessment process, aimed at validating the adherence of the implemented quality management system and technical documentation to regulatory standards, cannot be expedited beyond a specific juncture. Therefore, the processes and the timing to access the market are not accelerated compared to other medical devices.  

4. I can place my AI-based medical device on the market if I have trained, tested and validated it with open access datasets.  

It depends. It is important to verify that sufficient information is available on the origin of the clinical data. Multiple requirements like the validity of the data collection protocol need to be ensured, as well as its compliance with GDPR: Was the study run according to the Good Clinical Practices and standards? Was GDPR followed? Was the data collection performed by certified professionals? etc., It is also important to adopt good machine learning practices during model training, testing and validation, (e.g., that training and testing datasets should be independent). Both the FDA’s Good Machine Learning Practices as well as the upcoming European AI Act stress the importance of validating the algorithm on previously unseen data. 

5. If my MDSW fails to ensure personal data protection, it is not considered harm. 

According to the MDR 2017/745, all parties involved the development of a medical device shall respect the confidentiality of information and data obtained. Even if the failure of the software does not result in a lesion or physical injury, disclosure of personal data yields infringement penalties according to MDR2017/745 and GDPR Regulation (EU) 2016/679. Therefore, safe and secure data processing including transmission over a network and storage needs to be properly addressed at the design stage (e.g., minimum data collection, pseudo–anonymization) and complemented with ICT techniques (encryption, secure layers, etc.). Thorough risk management is mandatory, and all residual risks must be mitigated as far as possible. 

6. If my device is not storing data, I do not need to comply with GDPR.

Even if the device does not store data, it still might be, for instance, linked to a website that collects some personal information related to the user or the practitioner. Additionally, data breaches may stem from factors beyond storage; for example, a data breach may occur when manipulating data over a communication protocol. It is important to conduct an analysis of the whole lifecycle of the product and identify which components process data and need special attention as per the GDPR requirements.   

7. If I am working with anonymized data, I do not need to comply with GDPR. 

That is true when the data is completely anonymized. However, it is not always possible to achieve full anonymization while preserving the dataset’s usefulness. Thus, many applications rely on pseudo-anonymized data, where a “key” can be used to trace the clinical data back to the patient’s personal information. In this case, the manufacturer needs to be compliant with GDPR regulations.    

8. I can keep the collected data for as long as I want.

Similar to the above question, this also depends on whether the collected data is fully anonymized. If that is the case, there are no time restrictions for its storage, but if the data is pseudo-anonymized, there are restrictions. GDPR regulation does not establish specific time windows where the storage is allowed. It states, however, that “personal data must be kept in a form that makes it possible to identify data subjects for no longer than is necessary for the purposes of the processing”.  

9. If I use a cloud server, I do not need to worry about cybersecurity because the service provider takes care of it. 

Be careful, most cloud servers are not specifically designed to host confidential data or clinical data. When choosing a cloud server for such purposes, it is good to select an ISO 27001 certified provider. That means that the provider developed a framework for establishing, implementing, operating, monitoring, reviewing, maintaining and improving an information security management system. However, be proactive! Use all relevant information sources (Common Vulnerabilities and Exposures (CVE) are commonly monitored using vulnerability testing tools such as Trivy, Shodan, etc. and comprehensive security resources like OWASP), and monitor all processes concerning maintenance and infrastructure via health checks.  Keep in mind that data breaches occur beyond storing the data. 

10. If the Software Medical Device is a standalone software intended to be used in a host, I do not need to take precautions on cybersecurity. 

False! MDR 2017/745 requires manufacturers to foresee possible threats caused by misuse of their device and to take actions to prevent them. Besides, MDR also requires manufacturers to reduce as far as possible all risks associated with the negative interaction between their software and the IT environment it operates and interacts with. So, it is important to take cybersecurity preventive measures to identify possible threats, vulnerabilities, assets and impacts. A manufacturer needs to consider security in a holistic approach as the nature of assets is diverse: hardware (including the infrastructure), software (protection against most common threats such as ransomware, malware, legacy software, software of unknown provenance, etc.), data (personal identifiable information PII, health records, systems configuration, etc), and users (considering misuse, unauthorized users, protection of sensitive functionalities, etc).

Placing MDSW on the market requires knowledge of a broad variety of topics, including regulation and related guidelines for clinical validation, GDPR, cybersecurity, risk management and quality control.  

With an extensive track record working on similar problematics, Veranex can support you with multiple services, ranging from training courses and coaching, to defining the strategy and successfully bringing your product to the market. 

Contact us today to discuss your project!