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 often must 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. Health Care 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. The purpose of this article is to address some of the most common (and not always right) 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.
Here are 10 common misconceptions about Medical Device Software, and their respective clarification:
1. MDSW is classified as low risk under the MDR 2017/745.
False! On the contrary, 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 state of the healthcare situation or patient condition and 2) the significance of the information provided by the software to the healthcare situation related to diagnosis/therapy. After taking these factors into consideration, most MDSW is classified in higher classes, from Class IIa to Class III, which entails increased regulatory requirements.
2. Agile development practice and IEC 62304 requirements cannot co-exist because they rely on fundamentally conflicting principles.
Agile methodologies (i.e. SCRUM) are compatible with the standard for the development of Medical Device Software. Actually, there exists a Technical Information Report providing guidance on the use of Agile practices in the development of medical device software (AAMI TIR45:2012). It is up to the manufacturer to decide the Software Development Lifecycle (SDLC) of the product. However, there are multiple challenges that a manufacturer must face, especially in terms of procedures (alignment with the Quality Management System), validation of tools and documentation.
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 MDSW embedding AI must comply with applicable MDR 2017/745 requirements prior to being placed on the market. This means that the processes and the timing to access the market are not accelerated compared to other medical devices. In addition to the general regulation, there are some relevant specific considerations for the Clinical Evaluation of Medical Device Software as per MDCG 2020-1: For any MDSW (including AI-based MDSW), Clinical Evaluation should demonstrate the valid clinical association/scientific validity, technical performance, and clinical performance. This guidance on clinical evaluation of MDSW provides a framework for the determination of the appropriate level of clinical evidence required for MDSW. The provisions of this guidance document should be taken into consideration from the early stages of software development.
4. I can place my AI-based Software Medical device on the market if I have trained, tested and validated it with datasets coming from open access repositories.
It depends. It is important to verify that sufficient information is available on the origin of the clinical data. Multiple requirements might be fulfilled to ensure the validity of the protocol used to collect the data as well as the compliance of the data collection methods 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? 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. For more information, check these guiding principles for Good Machine Learning Practices.
5. If my MDSW fails to ensure personal data protection, it is not considered as harm.
According to the MDR 2017/745, all parties involved in its application 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 yields infringement penalties according to MDR2017/745 and GDPR Regulation (EU) 2016/679. Therefore, data processing, involving transmission over a network or storage needs to be properly tackled by design strategies (e.g. minimum data collection, pseudo anonymisation) and complemented with ICT techniques (encryption, Secure layers, etc.). To conduct Risk management is a “must”, and any residual risk must be mitigated as much 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. It is important to conduct an analysis of the whole lifecycle of the product and identify which processes need special attention as per the GDPR requirements.
7. If I am working with anonymised data, I do not need to comply with GDPR.
That is true if data is completely anonymised. However, most manufacturers rather work with pseudo-anonymised data, meaning that there is a “key” that can be used to link back the clinical data with the personal information of the patient. 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.
Similarly, that depends on whether the collected data is fully anonymised. If that is the case, there are no time restrictions for its storage, but if the data is pseudo-anonymised, there are restrictions. GDPR regulation does not establish specific time windows within which the storage is allowed, instead, it mentions 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 has a model 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) for vulnerability monitoring, testing tools such as Trivy, Shodan, OWASP, etc.), and monitor all processes concerning maintenance and infrastructure via health checks.
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 it. Besides, MDR also requires reducing as far as possible the risk associated with the possible negative interaction between software and the IT environment the MDSW 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, unauthorised 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, Medidee can support you with services ranging from training courses and coaching, up to completing the strategy to successfully bring your product to the market.
Contact us today to discuss your project!
This article was written by Dr Nuria Gresa, Dr Stamatia Pagoulatou and Dr Gustavo Hernandez.