Étiquette : CJUE

Vidéoconférence : Logiciels de santé et dispositifs médicaux

En matière de santé connectée et dispositifs médicaux, l’une des questions importante d’ordre juridique et réglementaire concerne les conditions légales, et la procédure à suivre, pour tout fabricant ou éditeur de logiciel de santé pour le développement de logiciel de santé qui peut être considéré comme un dispositif médical. Cela inclut les hôpitaux qui peuvent être considérés comme fabricants de dispositifs médicaux.

Le 4 juin 2018, j’ai eu l’honneur de présenter cette problématique au Centre de Recherche Clinique (CRC) des Hôpitaux Universitaires de Genève (HUG), présentation qui a été filmée et que vous trouverez ci-dessous. Cette présentation de 35 minutes n’est pas exhaustive et vise à apporter les bases élémentaires pour comprendre pourquoi un logiciel peut devoir être annoncé, obtenir une autorisation de Swissmedic, voire procéder à des essais cliniques après approbation d’une commission d’éthique.

Bon visionnage !

________________________________

POURQUOI CETTE CONFERENCE SUR LES LOGICIELS DE SANTE ?

L’innovation et les profonds bouleversements dans le domaine de la santé sont accélérés par la numérisation des données patients. L’essor phénoménal des nouvelles technologies de l’information et de la communication (NTIC) appliquées au domaine de la santé et les technologies avancées (intelligence artificielle, blockchain, etc.) nécessite une certaine prudence et vigilence tant pour les patients, que les professionnels de la santé et des précautions pour les acteurs de l’innovation et des assureurs.

De nombreuses et épineuses questions juridiques, éthiques, sociétales et assécurologiques se posent et requièrent une attention particulière de la part des professionnels de la santé et des experts en matière de technologies dès la conception des technologies de santé connectée (digital health et eHealth). Ainsi, l’accès au marché des applications de santé est réglementé, non seulement par les règles de droit médical, de la protection des données (LPD et RGPD), mais doit parfois passer par une procédure de certification, notamment le marquage CE et faire l’objet d’une annonce ou validation pour être distribué ou utilisé en hôpital.

J’en parlais déjà en 2016, dans mon article intitulé “La réglementation des applications médicales mobiles“, publié au sein du recueil édité par l’institut suisse de droit de la santé de Neuchâtel (IDS) et dans mon analyse de l’affaire européenne Philips et SNITEM de décembre 2017. Dans ce dernier article, j’y analyse les conséquences de la décision de la CJUE sur les logiciels d’aide à la prescription et dispensation médicale (LAP et LAD), mais également pour tous les autres logiciels de santé en Europe et en Suisse suite au procès gagné par Philips.

Pour toute question complémentaire, vous pouvez me contacter directement par e-mail.

Pour aller plus loin:

Un logiciel d’aide à la prescription médicale est un dispositif médical

Les logiciels  d’aide à la prescription médicale sont des dispositifs médicaux selon la CJUE

Le 7 décembre 2017, la Cour de Justice de l’Union Européenne (“CJUE”) a rendu un arrêt important pour les logiciels d’aide à la prescription médicale dans l’Affaire C-329/16 – SNITEM et Philips c. Premier Ministre des Affaires sociales et de la Santé. Une première jurisprudence qui suit les conclusions de l’avocat général du 28 juin 2017 et qui clarifie enfin les conditions permettant de considérer un logiciel comme dispositif médical.

Ainsi, la CJUE a considéré que la fonctionnalité d’un logiciel d’aide à la prescription médicale et qui permet “l’exploitation de données propres à un patient, aux fins, notamment, de détecter les contre-indications, les interactions médicamenteuses et les posologies excessives” est un dispositif médical (DM), cela même sans action directe dans ou sur le corps humain. Les fonctionnalités de ce logiciel qui visent un tel but sont dès lors soumises à la réglementation sur les dispositifs médicaux et doivent répondre aux exigences de la Directive 93/42/CEE. Par contre, les fonctionnalités de ce même logiciel qui ne répondraient pas à ces conditions ne pas sont soumises à la Directive.

__________________

Le marquage CE est suffisant

La Cour ajoute qu’une fois que le logiciel a obtenu l’apposition du “marquage CE“, une autorité nationale ne peut pas exiger de certification supplémentaire, puisque le marquage CE remplit déjà cette fonction.

Dans cette affaire française, un décret imposait l’obligation de certification pour les logiciels d’aide à la prescription (LAP) et à la dispensation médicale (LAD) prévue à l’article L.161-38 du code de la sécurité sociale (CSS). L’autorité française exigeait une certification spécifique, car elle considérait que les LAP et LAD n’entraient pas dans la catégorie des DM. Faux, a considéré la CJUE en balayant ce raisonnement et rappelant que la volonté de Philips de commercialiser son logiciel ICCA avait clairement une finalité médicale.

Il s’agit d’un arrêt important pour les éditeurs de logiciels actifs dans les logiciels ou les applications mobiles de santé qui souhaitent les mettre sur le marché en Europe, mais également en Suisse. En effet, si dans ses conclusions la Cour rappelle qu’il est obligatoire que le logiciel porte le marquage CE (art. 17 par. 1 de la Directive 93/42/CEE), elle précise toutefois qu’une fois fait, un tel logiciel de santé “peut être mis sur le marché et circuler librement dans l’Union sans aucune autre procédure supplémentaire, telle une nouvelle certification“.

Cet arrêt européen est un allègement qui sert l’industrie et permet de gagner du temps pour la mise sur le marché. Par cette clarification, on permet d’éviter de dépenser, dans le doute, des frais supplémentaires en vue d’une certification complémentaire pour les fonctionnalités bénéficiant déjà du marquage CE. On évite l’étape de la conformité préventive ou par précaution. D’un point de vue juridique, il faudra aussi se demander s’il est possible de se faire rembourser les frais  liés à l’obtention d’une certification inutile, voire illégale en cas d’annulation ou de modification de ce décret. En effet, cette décision est très probablement transposable à d’autres logiciels et potentiellement à d’autres Etats Membres de l’Union européenne.

__________________

Portée de cette décision

Quelle est la portée de cette décision?

D’abord, elle s’applique clairement aux logiciels d’aide à la prescription médicale. Mais pas seulement: cet arrêt clair de la CJUE s’étend potentiellement par analogie à tous les logiciels de santé ou applications mobiles de santé ayant une finalité médicale et qui produisent une action médicale, cela même si ce n’est pas dans ou sur le corps humain. Il est néanmoins nécessaire de procéder à une analyse pour chaque cas de figure.

Ensuite, cette décision s’applique aussi aux hôpitaux qui développent des logiciels ou des applications mobiles de santé, car ils sont considérés comme des fabricants de logiciels, même sans commercialisation, au même titre que le responsable de première mise sur le marché. Il sera dès lors nécessaire pour les établissements de soins qui développent des logiciels de procéder à une analyse des fonctionnalités avant d’être mis sur le marché ou déployé et, cas échéant, apposer le marquage CE.

D’un point de vue territorial, cette décision, bien qu’européenne, s’applique à la Suisse. En effet, la législation sanitaire suisse et Swissmedic renvoient aux Directives européennes et la Suisse reconnaît les logiciels mis sur le marché lorsqu’ils sont au bénéfice du marquage CE.

Enfin, cet arrêt même basé sur la Directive 93/42/CEE conserve sa validité avec l’entrée en vigueur du Règlement UE 2017/745 sur les dispositifs médicaux, qui la remplacera dès le 26 mai 2020.

Cette nouvelle fait écho à mon article de septembre 2016 sur “La réglementation des applications médicales mobiles” qui contient une analyse plus détaillée des conditions de mise sur le marché d’un logiciel de santé mobile aux USA, en Europe et en Suisse. Cette publication contient également des exemples de logiciels et applications mobiles de santé, autre que les logiciels d’aide à la prescription médicale qui peuvent être ou non des DM.

__________________

Plus en détails – Contexte du litige

En France, ce litige est né au sujet du logiciel “Intellispace Critical Care and Anesthesia” (ICCA”) développé par Philips, qui s’oriente vers les technologies de la santé. Ce programme informatique a pour but l’aide à la prescription médicale et a pour domaine d’application “l’anesthésie et la réanimation et fournit au médecin les renseignements dont il a besoin pour prescrire correctement les médicaments, notamment en ce qui concerne leurs éventuelles contre‑indications, les interactions entre les différents médicaments et les posologies excessives”.

Le litige opposait le SNITEM (syndicat national de l’industrie des technologies médicales) et Philips d’une part, au Premier Ministre des Affaires sociales et de la Santé d’autre part.  Philips soutenait  que son logiciel, déjà au bénéfice du marquage CE n’avait pas besoin, contrairement à ce que prétendait l’autorité française, de faire l’objet d’une certification supplémentaire spécifique aux logiciels d’aide à la prescription médicale, tel que le prévoit un décret français. Philips soutenait que le marquage CE était suffisant, et que d’imposer une certification supplémentaire constituerait une “mesure d’effet équivalent à une restriction quantitative à l’importation“. L’autorité française, de son côté, soutenait que le logiciel: (a) n’était pas un dispositif médical, (b) ne pouvait pas être commercialisé sans l’autorisation des autorités nationales et enfin (c) ne peut pas être mis en vente libre sur la base du seul marquage CE.

En clair, Philips considérait que son logiciel est un dispositif médical et que s’il obtient le marquage CE, il peut être commercialisé sans devoir se conformer à d’autres exigences supplémentaires. Philips obtiendra gain de cause sur cette question.

__________________

Enjeux de cette affaire et  premier précédent

La question centrale de cette affaire posée à la CJUE, n’était pas celle de la certification, mais celle de savoir si, au regard de la Directive 93/42/CEE sur les dispositifs médicaux, le logiciel ICCA doit être qualifié de dispositif médical ou non. La question juridique posée à la CJUE peut paraître un peu banale, mais elle ne l’est en fait pas du tout. En effet, les obligations et les contraintes pour les fabricants de logiciels sont très différentes si le logiciel est qualifié de dispositif médical ou non. Alors que la CJUE ne l’avait fait qu’indirectement dans l’affaire allemande Brain Products GmbH c/ BioSemi VOF e.a., la CJUE se prononce enfin sur les critères permettant de qualifier un logiciel de DM. Dans l’affaire précitée, la CJUE avait seulement mentionné que les logiciels de bien-être sportif ou de fitness ne répondaient probablement pas à la qualification de dispositifs médicaux, tandis que le logiciel permettant d’enregistrer l’activité cérébrale humaine oui.

Cet arrêt rappelle également le renvoi au lignes directrices MEDDEV 2.1/6 de l’UE en matière de logiciels de santé qui font office de base pour déterminer si son logiciel de santé doit faire l’objet de la réglementation européenne sur les DM avant la mise sur le marché, comme l’a rappelé l’avocat général dans ses recommandations du 28 juin 2017.

__________________

CONDITIONS ET EXEMPLES 

Deux conditions cumulatives, rappelle la Cour, doivent être réunies pour qu’un logiciel soit considéré comme un dispositif médical.

1. Condition de la finalité: le logiciel doit être destiné par le fabricant à être utilisé chez l’homme à des fins, notamment, de diagnostic, de prévention, de contrôle, de traitement ou d’atténuation d’une maladie, ainsi que de diagnostic, de contrôle, de traitement, d’atténuation ou de compensation d’une blessure ou d’un handicap;

2. Condition de l’action produite: le logiciel doit produire un effet sur l’être humain, mais il importe peu que, pour être qualifiés de dispositif médical, le logiciel agisse directement ou non sur le corps humain, l’essentiel étant que sa finalité soit spécifiquement l’une de celles visées au chiffre 1.

Il est intéressant de relever que la CJUE précise que la condition de l’action produite  n’est pas déterminante. Au contraire, exiger que l’action produite ait un effet dans ou sur le corps humain pour qualifier un logiciel de dispositif médical, aurait pour effet que les logiciels n’ayant pas cet effet, mais étant destiné à des fins médicales par le fabricant ne seraient pas soumis à la réglementation sur les dispositifs médicaux, ce qui serait contraire à la volonté du législateur.

EXEMPLES SOUMIS OU NON A LA DIRECTIVE:

  • EST UN DM : un logiciel qui procède au recoupement des données propres du patient avec les médicaments que le médecin envisage de prescrire et est, ainsi, capable de lui fournir, de manière automatisée, une analyse visant à détecter, notamment, les éventuelles contre‑indications, interactions médicamenteuses et posologies excessives, est utilisé à des fins de prévention, de contrôle, de traitement ou d’atténuation d’une maladie et poursuit en conséquence une finalité spécifiquement médicale;
  • PAS UN DM : un logiciel qui, tout en ayant vocation à être utilisé dans un contexte médical, a pour finalité unique d’archiver, de collecter et de transmettre des données, comme un logiciel de stockage des données médicales du patient, un logiciel dont la fonction est limitée à indiquer au médecin traitant le nom du médicament générique associé à celui qu’il envisage de prescrire;
  • PAS UN DM : un logiciel destiné à faire état des contre-indications mentionnées par le fabricant de ce médicament dans sa notice d’utilisation;
  • PAS UN DM: un logiciel à usage général utilisé dans un environnement médical

Dans ce cas précis de logiciels d’aide à la prescription médicale, la CJUE précise encore qu’un tel logiciel “qui procède au recoupement des données propres du patient avec les médicaments que le médecin envisage de prescrire et est, ainsi, capable de lui fournir, de manière automatisée, une analyse visant à détecter, notamment, les éventuelles contre‑indications, interactions médicamenteuses et posologies excessives, est utilisé à des fins de prévention, de contrôle, de traitement ou d’atténuation d’une maladie et poursuit en conséquence une finalité spécifiquement médicale“.

__________________

CE QU’IL FAUT RETENIR

Trois grands principes sont à retenir de cet arrêt SNITEM et Philips c. Ministre des Affaires sociales et de la Santé du 7 décembre 2017:

  • Premièrement, la réglementation sur les dispositifs médicaux s’applique aux logiciels de santé pour les fonctionnalités qui répondent à deux conditions cumulatives que sont la finalité poursuivie, car destinées par le fabriquant à être utilisées comme telle et (2) l’action médicale produite par le logiciel;
  • Deuxièmement, seules les fonctionnalités du logiciel répondant à ces critères sont soumises aux règles sur les dispositifs médicaux, et non le code entier du logiciel;
  • Troisièmement, lorsque le marquage CE a été apposé, le logiciel peut librement circuler au sein de l’Union européenne [et donc en Suisse également] et peut être mis sur le marché sans nécessiter de certification supplémentaire.

__________________

Autres conséquences si un logiciel est un dispositif médical?

Si un logiciel est qualifié de DM, il devra respecter le devoir d’annonce pour les DM de classe I. Pour les DM à risque moyen à élevé (IIa, IIb et III) les obligations envers les autorités sanitaires (autorités nationales européenes ou Swissmedic en Suisse) sont plus strictes.

Suivant les conditions applicables, l’observation des produits (suivi des risques liés au dispositif durant tout son cycle de vie) et  la matériovigilence (notification des incidents graves survenus en Suisse ainsi que les mesures de précaution qui ont été prises) sera également nécessaire par le fabricant de logiciel, tout comme le respect d’exigences supplémentaires en matière de sécurité des produits et de contrôle de la qualité. Pour les produits provenant de l’UE, ceux-ci doivent avoir l’apposition du marquage CE, s’ils veulent bénéficier de la libre circulation et ne pas devoir demander d’autorisation de mise sur le marché.

L’ensemble des normes qui régit les DM établit les exigences nécessaires, selon le degré de risque du logiciel, pour autoriser leur mise sur le marché, cela afin de garantir la libre circulation de ces biens en tant que produits sûrs, garantissant la sécurité et la santé des patients. Cette réglementation européenne est applicable en Suisse, puisque la législation sanitaire (dont notamment la LPTh, ODim, OMéd et LRH) ainsi que Swissmedic s’y réfèrent expressément.

Pour aller plus loin:

__________________

Gabriel Avigdor | NTIC.ch

Safe harbour - Ntic

Invalidation du Safe Harbor (Schrems c/ Facebook): Recommandations pour la Suisse

I.  Introduction

Dans une décision datée du 6 octobre 2015, (Décision C-362/14 – Affaire Max Schrems c/ Facebook ou “Schrems I”) la Cour de Justice de l’Union Européenne (CJUE) a invalidé la décision 2000/520/CE qui considérait le “Safe Harbor” comme une base suffisante pour le transfert de données personnelles aux États-Unis. Depuis cette décision, les 4’500 entreprises qui ont transféré des données personnelles vers les USA sur la base du Safe Harbor doivent vérifier que leur politique de protection des données est conforme au droit européen.

Comment en est-on arrivé là, quelles sont les répercutions pour les entreprises et pour les données des individus ? Un début de réponse dans les recommandations du Groupe de l’Article 29 et dans celles du Préposé Fédéral à la Protection des Données et à la Transparence (PFPDT).

II.  Résumé de l’affaire

Maximilian Schrems, un utilisateur de Facebook en Autriche, considère que Facebook ne respecte pas les principes de la protection des données lorsqu’elles sont transférées par Facebook aux Etat-Unis. En effet, ces données peuvent être accessibles par les autorités américaines sans que la personne concernée ne puisse s’y opposer. Comme beaucoup d’entreprises actives dans le domaine de l’informatique, le siège européen de Facebook est situé en Irlande qui sert de pont avec les USA; dans notre cas pour le rapatriement des données personnelles.

Cet utilisateur de Facebook dépose donc une plainte auprès de la Commissaire irlandaise à la protection des données pour interdire à Facebook le transfert de ses données aux USA. La Commissaire refuse d’entrer en matière puisque, selon elle, il découle de la décision 2000/520/CE instituant le Safe Harbor que les Etats-Unis disposent d’une niveau de protection adéquat pour garantir le respect des principes de la protection des données des individus européens.

Après cet échec, Max Schrems porte l’affaire devant la High Court of Justice of Ireland, qui renvoie l’affaire à la CJUE pour lui poser une question à titre préjudiciel. La Cour irlandaise demande alors si les autorités nationales disposent de la compétence de se saisir d’une plainte d’un individu alors que la décision 2000/520/CE garantit déjà, au niveau européen, que les Etats-Unis sont considérés comme un pays sûr concernant la protection des données.

La CJUE répond de manière claire et sans appel que le Safe Harbor ne permet plus, au vu des méthodes de surveillance massives américaines, de garantir aux citoyens européens une protection adéquate de leurs données lorsqu’elles sont transférées aux Etats-Unis. Elle donne donc raison à M. Schrems et juge que la décision 2000/520/CE est invalidée.

Il appartiendra dès lors à la Commissaire irlandaise à la protection des données d’examiner, dans le cas concret, si les mesures de sécurité mises en place par Facebook sont suffisantes pour garantir un niveau de protection adéquat des données des utilisateurs.

III.  Conséquences en Europe

Suites de l’affaire Snowden

Cette décision de la CJUE est une conséquence directe des révélations de l’Affaire Snowden sur les programmes de surveillance PRISM/US-984XN et  XKeyscore. Sans ces révélations, il est probable que la CJUE ne soit jamais parvenue à décréter que cet accord cadre n’était plus suffisant. Les quelques 4’500 entreprises qui se sont basées sur le Safe Harbor pour transférer leurs données aux USA sont placées dans un flou juridique.

Depuis le 6 octobre 2015, tout transfert de données aux Etats-Unis par des entreprises ayant basé ce transfert sur le Safe Harbor est illégal. Actuellement, les entreprises peuvent poursuivre le transfert des données aux Etats-Unis si :

  • des conventions intra-groupe intégrant des “clauses contractuelles types” reconnues par l’Union européenne sont mises en places
  • en ‘intégrant de “Binding Corporate Rules” (BCR), dont les lignes directrices peuvent être consultées ici
  • lorsque les conditions pour déroger aux conditions légales sont réunies (consentement préalable explicite de l’utilisateur, transfert des données en respect d’une obligation contractuelle, etc.).
  • Il existe également des modèles de conventions pour le transfert de données garantissant le respect des principes légaux (“Transborder Data Flow Agreement”).

Réactions au niveau européen

Après l’arrêt Schrems c. Facebook, les autorités européennes de protection des données n’ont pas tardé à réagir. Dans un communiqué du 16 octobre 2015, le Groupe de travail de l’Article 29 (le G29 est institué par l’article 29 de la directive européenne sur la protection des données personnelles – Directive 95/46/CE) a émis des recommandations dans lesquelles il impartit un délai de 3 mois aux institutions européennes et aux gouvernements pour renégocier un Safe Harbor compatible avec les principes européens de la protection des données. Les autorités nationales, dont notamment la CNIL, sont prêtes à se coordonner pour entreprendre des actions répressives concertées (par exemple exiger la suspension de tout transfert de données aux Etats-Unis) si un accord n’est pas trouvé d’ici au 31 janvier 2016 !

IV.  Recommandations du Préposé en Suisse

Recommandations aux entreprises

Comme on peut le lire dans sa dernière communication datée du 22 octobre 2015, le Préposé Fédéral à la Protection des Données et à la Transparence (PFPDT) se calque sur la décision européenne et considère que l’équivalent suisse du Safe Harbor européen (le US-Swiss Safe Harbor Framework) n’est plus une base légale suffisante tant que la Suisse n’aura pas renégocié un accord suffisant avec les Etats-Unis.

A la différence de l’Europe, la Suisse n’a pas dénoncé le Safe Harbor alors que la situation est connue depuis longtemps, aucune décision judiciaire n’a été rendue et l’analyse du PFPDT n’est parue que via son site web, relève Me Sylvain Métille sur son blog. Selon le Préposé Fédéral suppléant à la protection des données, M. Jean-Philippe Walter, “La Suisse est liée par la décision d’adéquation et ne peut faire cavalier seul au risque que l’UE revoie sa décision“. De plus, il revient au Conseil Fédéral de dénoncer, cas échéant, le Safe Harbor et non au Préposé. Tout en rappelant qu’il ne s’agit que de  recommandations, le Préposé suppléant précise que cette prise de position s’adresse aux entreprises qui devraient suivre les recommandations du Préposé, soit :

  • Informer de manière claire et aussi exhaustive que possible les personnes dont les données sont transmises aux États-Unis des accès possibles des autorités, afin de leur permettre d’exercer leurs droits. Le contrat d’échange de données personnelles devrait prévoir un engagement des parties contractantes dans ce sens
  • Prévoir un engagement des Parties à mettre à la disposition des personnes concernées les outils nécessaires à une protection juridique efficace conformément à l’article 6, al. 2, let. a, LPD, à exécuter réellement les procédures correspondantes et à accepter les décisions qui en résultent.

Qu’en est-il des individus ?

En Europe, tout dépendra des résultats de l’enquête menée par la Commissaire irlandaise. Si elle constate que Facebook ne garantit pas une sécurité suffisante aux utilisateurs pour le transfert de leurs données aux USA, tout détenteur européen d’un compte pourrait requérir de Facebook l’interdiction du transfert de ses données. Une situation bien improbable. En effet, dans une telle hypothèse Facebook s’empressera de modifier ses conditions générales, informera les utilisateurs d’une potentielle atteinte à leurs droits par les autorités américaines et recueillera, le cas échéant, leur consentement pour continuer à utiliser la plateforme sociale.

En Suisse, tout individu qui se considère qu’une entreprise viole les règles de la protection des données à son égard peut s’adresser aux tribunaux civils pour faire constater, cesser ou interdire toute atteinte. Les mesures repressives qui existent en Europe n’ont pas d’équivalent en Suisse et le PFPDT ne peut qu’émettre des recommandations, sans possibilité d’agir directement. Il ne peut qu’inciter les entreprises à respecter les principes de la LPD ou les utilisateurs à agir par la voie civile.

VI.  Conclusion

Même si les entreprises suivent les recommandations émises en Europe ou en Suisse, le droit américain, notamment le FISA Act, ne sera pas pour autant modifié et on connait les difficultés concrètes permettant de changer la législation américaine tant du point de vue politique que juridique. Seuls les gouvernements pourraient avoir de l’influence dans le cadre de la mise en place du Safe Harbor 2.0 dont nous devrions avoir des nouvelles d’ici au 31 janvier 2016. Il appartiendra aux entreprises américaines de faire l’effort ou non d’améliorer les conditions de sécurité des données dans leur convention intra-groupe ou, pourquoi pas, de créer leur data center en Europe, tant on sait que le Big Data est devenu aujourd’hui le pétrole du XXIe siècle.

Il s’agit tout de même d’une victoire de principe pour les défenseurs de la vie privée sur Internet, notamment par le biais de la protection des données personnelles. Aujourd’hui, les Etats-Unis ne sont plus considérés, par l’Europe, comme un pays sûr en matière de protection des données, ce qui concrétise les révélations d’Edward Snowden du 9 juin 2013.

L’arrêt Schrems c. Facebook consacre le principe de la compétence des autorités de protection des données pour examiner une plainte d’un individu qui prétend qu’une entreprise viole la loi sur la protection des données (Voir § 47 à  57 de la décision C-362/14). Cet arrêt continuera à s’appliquer même avec un Safe Harbor 2.0 considérant à nouveau les Etats-Unis comme un pays sûr. Dans chaque cas, les citoyens européens pourront demander aux autorités de vérifier si l’entreprise respecte les principes de protections des données ou non.

Un petit pas pour l’individu et la protection des données personnelles en Europe, un tout petit pas pour la Suisse, dont les autorités de protections des données ne disposent d’aucun moyen répressif, et qui suit son homologue européen.