Guideline for rational for data storage of "unregulated" software in the medical device environment

The development of medical software (SaMD) is still a hard job and there are a lot of challenges before a software can be launched. Indeed, it is easier to actively take the path to provide “non-regulated” or “unregulated” software by getting rid of the medical purpose. Unfortunately, unregulated does not mean that there is no regulation to be?followed at all?. Imagine a healthcare software like a smartphone fitness app, which is not a medical device itself. At least for the data processed the General Data Protection Regulation (hereinafter “GDPR”) has to be considered. In addition, such software is often part of a bigger architecture and may connect software with a medical purpose behind. One of the processing principles in the GDPR is the storage limitation principle, which requires to delete personal data (age, weight, ...) as soon as the processing purpose was achieved (GDPR Art. 5.1 e). In an ideal world the personal data storage period would be assessed in the data protection impact assessment, where a rational should be given for the storage period implemented. This rational becomes now an important part and will show if one has all the things in mind in regards to medical device regulations and data protection. Following the example given above, such a rational could look like:

A) 10/15 years – rational: Personal data retention due to medical?purpose according to MDR/IVDR.?

B) XX days – rational: Purpose of processing requires to keep the data for at least that amount of time in order to act on complaints based on the processing.?

C) XX days – rational: Data is kept for this period as there may arrive requests on the invoicing. After this period data will be deleted and invoicing requests will not be answered anymore.?

If your company has unfortunately decided in the assessment that rational A is applicable according to the example,?please be aware that you do not provide a software as a medical device (SaMD). You may not rely on that rational or your software is a medical device and it has been wrongly assessed. Both, wrong rational or wrongly assessed software will have an impact to your company which may end in a data privacy fine or in preparation of a re-submission for SaMD.?

Rational B may be a suitable path to keep personal data for the defined storage period as complaint/support management is in most cases a part of the data processing agreement. XX should be a meaningful time period in such cases. Again, where you rely on 10 years of data storage due to medical complaints, it is strong hint that you have assessed your software wrongly.

Rational C can be used but is still risky as is tends to show that the data is used for another processing purpose (in this example the invoicing purpose) which must be either the primary purpose of the software in scope or the covered in another assessment of the processing activities and be referenced accordingly.

Unfortunately, such short examples cannot provide all criteria necessary to assess this kind of situations. Therefore, a case-by-case assessment is necessary and suitable rationales need to be found according to the purpose of data processing.