Medical apps: the Data Protection Authority’s instructions for GDPR compliance


In July 2022, the Italian Data Protection Authority (DPA) issued a €45,000 fine against the US company Senseonics Inc. for breach of the GDPR. More precisely, the company, which markets a glucose monitoring system for patients suffering from diabetes, sent an information email to approximately 2,000 recipients (Italian patients) mistakenly entering them in the CC field, instead of the BCC field. As a result, it decided to report the data breach to the Italian DPA under Article 33 GDPR: this report led to the opening of an investigation and the application of a sanction.

The fact itself (CC’ing recipients instead of using BCC) is not particularly noteworthy (apart from the fact that it would be interesting to know exactly how much training had been given to the employee who made the mistake).

What is really interesting is the development of the investigation and the many elements emerging from it with the consequent directions of the Data Protection Authority.

In fact, the investigation opened a 'Pandora's Box' by bringing to light numerous other violations of the GDPR in addition to the data breach. This resulted in a sort of guide by the DPA indicating what would have been the correct behaviour.

This is a topical subject, considering the proliferation of health-related apps ranging from wellness apps to drug digital support to digital therapeutics.



The legal basis for processing

Pursuant to Article 5 (a) and (b) of the GDPR, data may only be processed if there is an appropriate legal basis; if there is more than one purpose, each purpose must have its own legal basis.

In the present case (and this is unfortunately not uncommon) the patient, after downloading the application, was asked to accept with a single click on the “accept” button both the terms of the End-User Licence Agreement (EULA) and the privacy policy. Moreover, the user was agreeing to Senseonics' privacy policy and terms of use, and concurrently authorising the retention, transmission and use of the data, including its unlimited storage in the UK and transmission to the US for limited purposes (e.g. engineering and customer service) in accordance with the terms of the EULA and the privacy policy.

On this aspect, the Data Protection Authority specified that in apps

  • the page and acceptance of T&Cs must be placed on a separate page from the privacy policy
  • the legal bases of the processing operations must be separate.


The principle of transparency

Art. 5(a) also establishes the principle of transparency: i.e. the data subject must be informed of what data are collected and for what purpose in a concise and transparent form (Recital 39 and Art. 12 GDPR).

This is even more the case when, as happens with apps, large amounts of data are collected. Moreover, where the purposes and legal basis are unclear, or it is unclear whether such data will also be re-used by third parties for other purposes, any consents obtained may not be considered valid (WP29 - Opinion 2/2013 on smart device apps).

In this specific case, the information on the data - apart from being 'mixed' with the company policy on minors, the copyright policy, the disclaimer of warranty and limitations of liability - did not clearly state the purposes for processing (which had to be looked for elsewhere in the app), did not indicate the legal basis nor the retention time, and even indicated that the data could be retained for 'prudential' reasons.

Finally, the possibility of revoking consent was not foreseen, the rights of the data subjects were not indicated, nor was the possibility of lodging a complaint with the Data Protection Authority.

Instead, the DPA's indications are that all the requirements of the GDPR are to be expressed with the utmost clarity, completeness and accessibility.

The appointment of a representative established in the EU

Article 27 of the Regulation provides that, where the controller is established outside the EU and processes data of EU subjects, the controller must designate in writing a representative in the EU. This representative must be established in one of the Member States where the data subjects are located and act as an interface for the supervisory authorities and the data subjects in relation to all matters concerning the processing.

In the present case (and this is also quite common), no such representative had been appointed.



The Senseonics case presents data breach aspects that are present in many health-related apps. It is therefore worth making a brief summary of the most relevant aspects to be taken into account:

  • all information on data processing must be on separate pages from other information and must be easily accessible;
  • keeping the section on the processing of personal data and other sections (e.g. 'Company Policy'; 'Copyright, Trademarks and Use'; 'Disclaimer of Warranties Limitations of Liability') in one single document violates the GDPR. Furthermore, where the app is a medical device, the information supplied by the Manufacturer (Annex I point 23 of EU Reg. 2017/745) must be separated from all other information;
  • the purposes of the processing must be clear and the legal basis must be indicated for each purpose;
  • The DPA also points out that where there is a marketing purpose, for which not only email but also other means of communication are to be used, such processing must be based on a specific legal basis. On this point, it should be noted that Article 130 of the Italian Privacy Code requires the acquisition of specific consent from the data subjects where the use of call communication systems without the intervention of an operator is envisaged for the sending of advertising or direct sales material or commercial communications;
  • the privacy policy must specify the rights of the data subject pursuant to Articles 15 to 22 of the GDPR;
  • where the data controller is based outside the EU, a representative must be appointed.



One final consideration.

When we talk about 'digital health' we are referring to a transformation, which is already underway, from medicine delivered through traditional approaches to medicine that also uses (in whole or in part) technology-based tools.

This implies that, nearly always, the data controller is the healthcare facility that is transforming its healthcare delivery methods, and almost always the technology provider (of devices or apps) is considered a data processor under Art. 28, at least for the purposes of diagnosis and treatment.

It follows that under Art. 28 GDPR the healthcare facility is required to choose suppliers that are GDPR-compliant, given also that, in the event of damages, the data controller and data processor will be jointly and severally liable (Art. 82).

Now, as the issues raised by the DPA at Senseonics are far from uncommon, it is critical for healthcare facilities, especially in this somewhat turbulent transformation, to assess their suppliers from a data protection perspective.

Controls to be carried out before the supply contract is signed, not after.