Actualités e-santé

APPLIS DE SANTÉ : La HAS s'empare du réglement européen

La Haute Autorité de Santé (HAS) a élaboré, avec l’aide de la CNIL, un référentiel de bonnes pratiques visant à aider les concepteurs d’applications et d’objets connectés de santé à respecter les réglementations en vigueur. L’analyse de ce référentiel traduit une volonté d’anticiper l’application du Règlement européen sur la protection des données personnelles, prévue pour mai 2018.

Le marché de la santé mobile est en plein essor. Le nombre d’applications mobiles de santé disponibles ne cesse de croître. Et pour cause, la santé connectée présente de nombreux avantages, que ce soit en termes de progrès médical grâce à l’exploitation du Big Data ou de médecine préventive grâce au rôle actif du patient dans sa prise en charge.

L’image d’un individu acteur de sa santé entre cependant encore trop souvent en conflit avec celle d’un individu acteur de la protection de ses données personnelles.

En effet, que l’ « appli santé » ait une finalité médicale déclarée ou qu’elle se dise simplement « de bien être », elle conduira très certainement à la collecte de données renseignant directement ou indirectement sur l’état de santé de l’utilisateur. Face à l’hétérogénéité des applications disponibles, il n’est alors pas étonnant que l’utilisateur s’interroge sur leur qualité, leur fiabilité et l’existence de risques pour la confidentialité et la sécurité de leurs données.

Cette méfiance est légitime, dès lors qu’aucune règlementation spécifique ne vient encadrer le développement des applications, et que les dispositions légales et règlementaires existantes en matière de dispositifs médicaux, de protection des données personnelles et d’hébergement de données de santé ne suffisent pas à traiter toutes les problématiques soulevées par les « applis santé ».

Consciente de ce problème, la Haute Autorité de Santé (HAS) s’est donné pour objectif de proposer un guide technique à destination des industriels et des évaluateurs, afin de garantir ainsi la conception et la mise sur le marché d’applications et d’objets connectés (OC) de santé fiables, performants, sécurisés et ergonomiques.

Ce référentiel de bonnes pratiques 1, fruit d’une étroite collaboration de la HAS, de la CNIL et de l’ANSSI 2, a vu le jour en octobre 2016. Il concerne les seules applications et OC n’ayant pas de finalité médicale déclarée, et non ceux soumis au régime du marquage CE en tant que dispositifs médicaux.

Non-contraignant, ce référentiel n’a pas vocation à se substituer à la règlementation existante, mais plutôt à proposer des clés concrètes pour une application correcte des dispositions légales en vigueur.

En matière de données personnelles, la HAS, poussée par la CNIL, va encore plus loin : elle anticipe l’entrée en vigueur du Règlement sur la protection des données personnelles du 27 avril 2016 3, en édictant des bonnes pratiques s’inspirant directement des nouveaux principes consacrés par ce texte.
 

L’ANALYSE D’IMPACT


La HAS recommande aux concepteurs de réaliser en amont du développement de l’application ou de l’OC, une analyse de la menace pesant sur le produit, en termes de sécurité. Cette analyse - du type EBIOS 4 - permettrait d’identifier les données sensibles manipulées par le produit et les mesures de sécurité propres à couvrir les risques pesant sur leur confidentialité, leur intégrité et leur disponibilité, afin « d’ajuster le curseur sécurité au bon niveau ».

En édictant cette bonne pratique, la HAS fait manifestement écho à la pratique de l’ « Etude d’Impact sur la Vie Privée » (EIVP) récemment consacrée par le Règlement européen. Cette nouvelle pratique – qui aurait dans certains cas vocation à se substituer aux formalités déclaratives existantes – impose en effet au responsable de traitement projetant la réalisation d’un traitement à risque, d’effectuer, préalablement à la mise en oeuvre du traitement, une auto-évaluation des risques que présente son projet sur la vie privée des individus.


LA MINIMISATION DES DONNÉES


La HAS rappelle que les données collectées par l’application ou l’OC ne peuvent excéder celles nécessaires à la destination d’usage du produit, c’est à dire indispensables à la réalisation des finalités préalablement déterminées. Certes, les principes de pertinence, de proportionnalité et de finalité existent déjà dans la Loi Informatique et Libertés 5, mais la HAS fait ici explicitement référence au principe de minimisation des données, consacré par le Règlement européen, en vertu duquel le responsable de traitement ne doit pas collecter plus de données que nécessaires.


LE CONSENTEMENT EXPLICITE


Le référentiel de bonnes pratiques s’inspire de la nouvelle définition du consentement donnée par le Règlement européen en imposant le recueil du consentement préalable explicite de l’utilisateur de l’application ou de l’OC, pour l’utilisation de ses données. L’influence du Règlement est encore perceptible à travers l’obligation faite au concepteur de mettre l’utilisateur en mesure de modifier et retirer son consentement à tout moment.
D’un point de vue pratique, la HAS affirme que le consentement exprimé via l’acceptation de Conditions Générales d’Utilisation (CGUs) ne permet pas la mise en oeuvre concrète de ces droits de l’utilisateur, dans la mesure où cette acceptation n’intervient que lors de la première utilisation. La mise en oeuvre d’éléments de réglages modifiables doit donc être favorisée.
 

LE DROIT A L’OUBLI


Le principe phare du Règlement européen, le droit à l’oubli, n’est pas en reste. La HAS anticipe son application en invitant le concepteur d’une part à préciser la durée de conservation nécessaire à l’accomplissement des finalités et à ne pas la dépasser ; et d’autre part à mettre l’utilisateur en mesure – via un élément de réglage – d’exercer son droit de corriger et d’effacer ses données à tout moment, même si la durée de conservation n’est pas écoulée.


LE PRIVACY BY DESIGN


Sur l’autel de la sécurité et de la confidentialité, la HAS sacrifie l’appli santé ou l’objet « hyper connecté ».

La HAS relève que certains produits peuvent avoir accès à des fonctionnalités du smartphone contenant une quantité importante de données personnelles. Nombreuses sont en effet les applications qui demandent, pour fonctionner de manière optimale, un accès aux e-mails, carnet d’adresses, calendriers, historiques de navigations, photographies et films stockés, préférences du système, géolocalisation, microphone, caméras, etc. Similairement, la HAS envisage le cas – fréquent – où l’application ou l’OC prévoit de partager les données qu’il gère avec d’autres applications ou OC, ou sur des réseaux sociaux.

Or, le principe de loyauté en matière de protection des données personnelles suppose que l’utilisateur soit en mesure de donner son consentement éclairé, après avoir reçu une information explicite, à l’accès ou au partage par l’application ou l’OC d’informations sensibles.

Pour la HAS, applications et OC doivent donc être conçus d’une manière telle que ces accès et partages soient par défaut impossibles, et que leur mise en oeuvre soit subordonnée à une autorisation expresse de l’utilisateur. L’application ou l’OC pourrait ainsi proposer à l’utilisateur d’approuver une notification ou d’effectuer un réglage spécifique avant l’utilisation par le produit concerné de la caméra, de la géolocalisation ou tout autre contenu de son smartphone. De même, s’agissant du partage des données, l’application ou l’OC pourrait prévoir une zone de réglage permettant à l’utilisateur de sélectionner les applications et réseaux sociaux pour lesquels il accepte la diffusion de ses données.

La HAS précise en outre que le concepteur doit prendre en compte les droits de l’utilisateur de modifier son consentement et de corriger et d’effacer ses données personnelles à tout moment, en prévoyant des éléments de réglage lui permettant de gérer son consentement et ses données.

Au final, la HAS recommande donc aux concepteurs d’application et d’OC d’intégrer, dès la conception du produit (built-in) et avant sa mise en circulation, des fonctionnalités permettant le respect des principes clés de la protection des données personnelles et notamment des principes d’information, de consentement exprès, explicite et révisable à tout moment, et de droit à l’oubli.

Ce faisant, la HAS procède à une application anticipée des principes de Privacy by Design et de Privacy by Default consacrés par le Règlement européen qui imposent de prendre en compte le respect de la vie privée et de la protection des données dès les premières phases de conception des technologies et de paramétrer ces technologies de manière à garantir par défaut le plus haut niveau de protection des données.

La référence au principe du Privacy By Design est d’ailleurs explicite. La HAS souligne en effet la criticité de son respect par les développeurs, notamment afin d’assurer la loyauté de l’application.
 

LA SÉCURITÉ RENFORCÉE


Pour la HAS, le Privacy by Design s’applique aussi aux mesures de sécurité, qui doivent être prises en compte dans les spécifications même de l’application ou de l’OC afin de protéger la confidentialité et l’intégrité des données.

La conception de l’application ou de l’OC devrait ainsi intégrer des « fonctions de sécurité » telles que l’authentification des utilisateurs (en cas d’échanges de données entre l’application et des services distants), la pseudonymisation (qui consiste à masquer l’identité réelle de l’utilisateur en y associant un pseudonyme) ou encore l’anonymisation (obligatoire en cas de transmission de données de santé à des fins de statistiques).

La HAS préconise également le recours au chiffrement, que ce soit pour sécuriser les données faisant l’objet d’un transfert ou pour protéger les données stockées sur le terminal ou sur les serveurs distants. Cette technique permettant en effet de garantir la confidentialité des données en cachant leur substance : les données chiffrées n’apparaîtront sous leur forme d’origine que si elles sont déchiffrées à l’aide de la bonne clé. Le recours à des services de cryptographie robustes, connus et éprouvés devra être privilégié par le concepteur, le développement de ces fonctionnalités étant particulièrement difficile.

Ces bonnes pratiques s’inspirent directement des mesures de sécurité renforcées dont le Règlement européen préconise la mise en oeuvre.


LA NOTIFICATION DES FAILLES DE SÉCURITÉ


La HAS explique enfin, qu’en cas de survenance d’un incident de sécurité ou d’une violation des données, l’éditeur de l’application ou le concepteur de l’OC devra faire preuve de transparence et en alerter les autorités compétentes et les utilisateurs. Elle recommande alors au concepteur de mettre en place, au stade de la conception (Privacy By Design), un processus de signalement lui permettant de remplir cette obligation de notification. Une application pourrait ainsi, selon la HAS, adresser une notification à l’utilisateur pour mettre à jour l’application suite à une faille de sécurité.

L’influence du Règlement européen est ici indiscutable : la bonne pratique édictée par la HAS est une application pratique directe de l’obligation de notification des failles de sécurité instaurée par le Règlement.



Si le guide n’a pas de portée contraignante, il invite les concepteurs d’applications et d’OC à se mettre dès aujourd’hui en conformité avec le Règlement Européen qui leur sera directement applicable, sous peine de sanctions, à compter de son entrée en vigueur le 6 mai 2018.

Dans l’intervalle, le référentiel de la HAS sera complété par un code de conduite établi par la Commission Européenne destiné à aider les concepteurs d’applications de santé à respecter la législation européenne en matière de données personnelles avec des conseils et exemples concrets

Par Marion Barbezieux et Hervé Gabadou, avocats, et Agnès Morel, stagiaire chez SEA AVOCATS.


1Référentiel de bonnes pratiques sur les applications et les objets connectés en santé (Mobile Health ou mHealth) de la Haute Autorité de Santé, Octobre 2016
2 Agence Nationale de la Sécurité des Systèmes d’Information (ANSSI)
3 Règlement (UE) 2016/679 du Parlement européen et du Conseil du 27 avril 2016 relatif à la protection des personnes physiques à l'égard du traitement des données à caractère personnel et à la libre circulation de ces données, et abrogeant la directive 95/46/CE (règlement général sur la protection des données)
4 EBIOS (Expression des Besoins et Identification des Objectifs de Sécurité) est la méthode de gestion desrisques SSI de l'ANSSI.
5 Loi n° 78-17 du 6 janvier 1978 relative à l'informatique, aux fichiers et aux libertés, article 6.

Le déploiement de la télémédecine

Le groupe de travail sur la télémédecine réuni dans le cadre du Comité Stratégique de Filière Santé a rendu le 27 mars 2015, un rapport fixant des engagements visant à faciliter le déploiement de la télémédecine.


Ce groupe de travail associe les représentants des pouvoirs publics (DGOS, DSSIS, DGE, DGRI, ASIP Santé, ANAP, HAS, CNAMTS, ANSM) et des syndicats industriels (SNITEM, Syntec Numérique) et a pour objectif de permettre l’émergence d’une stratégie industrielle en matière de e-santé (projet nommé « mesure 33 »).
Les industriels se sont fixés pour objectif d’atteindre d’ici à 2017 le chiffre de 50 000 patients télésuivis puis de passer à un million en 2020. Le focus est mis sur l’insuffisance cardiaque, le diabète insulinotraité, l’hypertension artérielle sévère et l’insuffisance rénale chronique, quatre maladies chroniques jugées prioritaires. L’objectif fixé pour 2020 tendrait à une prise en charge de 30 % de patients chroniques dans les pathologies chroniques citées, ce qui permettrait notamment la création de 15 000 emplois.
L’accélération du déploiement de la télémédecine en France est un enjeu majeur à l’heure où le marché international s’ouvre et se développe à grande vitesse mais reste dominé par les Etats Unis (qui représentaient 75% des patients télésuivis dans le monde en 2012 selon une étude d’inMedica). Les industriels ont pour ambition de faire de la France un leader mondial de l’e-santé. Il s’agit donc pour les acteurs publics et privé de dépasser le stade de l’expérimentation et de généraliser la pratique de la télémédecine.

Sources :