L’interdiction et l’encadrement des traitements de données de santé par le droit de la protection des données
En matière de données de santé, l’article 9.1 du RGPD prévoit une interdiction de principe du traitement de telles données. Il en va de même des données génétiques. L’article 9.2 du même règlement prévoit cependant une liste d’exceptions limitatives, autorisant le traitement de données de santé et notamment :
le consentement explicite de l’utilisateur pour une ou plusieurs finalités spécifiques - il est par conséquent primordial de bien définir les finalités du traitement de données de santé, au moyen de conditions d’utilisations suffisamment lisibles et intelligibles, en appliquant le privacy by design dès la conception des objets connectés. De plus, s’agissant du consentement la Haute Autorité de Santé (HAS) recommande une information lorsqu’il est possible de synchroniser les données sur plusieurs équipements appartenant à un même utilisateur[10]
la nécessité du traitement pour l'exécution de certaines obligations - i.e. lorsque le traitement de données de santé est nécessaire à l’exécution d’une obligation contractuelle par exemple
le traitement est nécessaire aux fins de la médecine préventive ou du travail, de diagnostics médicaux, de la prise en charge sanitaire ou sociale, ou en vertu d'un contrat conclu avec un professionnel de la santé - tel est le cas de la télémédecine (téléexpertise, téléconsultation, télésurveillance, téléassistance). A cet égard, la CNIL et le Conseil national de l’Ordre des médecins ont publié un guide pratique avec une fiche relative à la télémédecine[11]. Le guide précise notamment les vérifications que le médecin doit réaliser dans sa relation contractuelle avec le sous-traitant qui propose un logiciel de télémédecine (traitement des données personnelles sur les instructions du médecin, engagement de confidentialité du personnel, mesures de sécurité, pas de recours à des sous-traitants ultérieurs sans autorisation, permettre l'exercice des droits des patients etc.)
Outre le respect des exceptions prévues, la Loi Informatique et Libertés comme le RGPD, prévoient que chaque traitement de données personnelles doit être réalisé en intégrant :
une finalité déterminée, explicite et légitime ;
le principe de minimisation de la collecte des données ;
une durée de conservation des données limitée ;
une obligation de sécurité ;
l’information des personnes concernées ;
le respect des droits des personnes (droit d’accès, droit à la portabilité, droit à la limitation, à l’effacement, droit d’opposition et de rectification).
Au-delà de ces obligations, tout traitement de données de santé par un objet connecté présente aussi des risques et notamment le traitement de données à l'insu de la personne concernée.
C’est l’exemple des applications de running qui permettent de suivre les performances physiques de l’utilisateur ainsi que bien souvent sa géolocalisation. L’utilisateur peut par la suite partager ses performances sur les réseaux sociaux. Dans une telle situation, il est impératif que les mentions d'informations soient claires et intelligibles, mais également que l’application ne soit pas paramétrée par défaut et surtout que l’utilisateur puisse à tout moment retirer son consentement. Là encore, la question du privacy by design joue un rôle majeur et il est impératif de se pencher sur ces questions pour les développeurs de logiciels. En effet, de telles applications mêlant géolocalisation et données de santé ou de bien-être sont au croisement des différents contrôles que la CNIL entend réaliser en 2020[12].
Une autre question primordiale en matière de données de santé concerne les destinataires des données qui ne sont pas toujours bien identifiés. Ceux-ci peuvent en outre « être établis hors de l’Union européenne. Apple avec son HealthKit, Samsung avec SAMI, Google avec Google Fit prévoient de stocker sur une plateforme une série d’informations comme le poids ou le rythme cardiaque, la tension…, transmis par le téléphone en lien avec différents objets connectés [13] » Dans une telle situation il est nécessaire que les tiers éventuellement destinataires des données de santé soient portés à la connaissance des utilisateurs, surtout si des traitements ultérieurs sont susceptibles d’être effectués. Lorsqu’un transfert se réalise vers un pays hors de l’Union européenne, il est alors nécessaire que le transfert soit réglé par des conventions inter-étatiques, par des binding corporate rules en cas de transfert intra-entreprise ou par des clauses contractuelles types, sous réserve de la décision de la CJUE à ce sujet[14].
Autre obligation essentielle à la charge du fabricant d’IoT qui recueille et traite des données de santé : la réalisation d'une analyse d’impact. En effet l’article 35 du RGPD prévoit que tous les responsables de traitement sont dans l'obligation de conduire une analyse de l'impact des opérations de traitement envisagées sur la protection des données à caractère personnel, avant de mettre en place le traitement, si celui-ci est susceptible d'engendrer un risque élevé pour les droits et libertés des personnes physiques.
Selon le RGPD, l’évaluation systématique et approfondie d'aspects personnels, fondée sur un traitement automatisé, y compris le profilage, et sur la base de laquelle sont prises des décisions produisant des effets juridiques à l'égard d'une personne physique ou l'affectant de manière significative de façon similaire. Il en va de même du traitement à grande échelle de catégories particulières de données.
Le G 29 a également fourni une liste de critères pour déterminer si un risque élevé existe pour les utilisateurs[15] et entre autres :
L’évaluation ou notation, y compris les activités de profilage et de prédiction, portant notamment sur la santé ou la localisation et les déplacements. L’exemple donné par le G 29 est celui d’une société de biotechnologie proposant des tests génétiques directement aux consommateurs afin d’évaluer et de prédire les risques de maladie/de problèmes de santé.
Les données sensibles ou données à caractère hautement personnel. A titre d’exemple, le G 29 cite les dossiers médicaux que peut conserver un hôpital général, les données liées à des activités domestiques et privées (notamment les communications électroniques dont la confidentialité doit être protégée), dans la mesure où elles ont un impact sur l’exercice d’un droit fondamental (données de localisation dont la collecte met en cause la liberté de circulation, par exemple). A cet égard, « il peut être pertinent de déterminer si les données ont déjà été rendues publiques par la personne concernée ou par des tiers. Le fait que les données à caractère personnel soient publiquement disponibles peut être pris en compte en tant que facteur dans l’analyse lorsqu’il est prévu une utilisation ultérieure des données pour certaines finalités. Ce critère peut également inclure les données telles que les documents personnels, les courriers électroniques, les agendas, les notes des liseuses équipées, de fonctions de prise de notes ainsi que les informations à caractère très personnel contenues dans les applications de life-logging » selon le G 29.
Les données traitées à grande échelle, notamment en considération du nombre de personnes concernées, soit en valeur absolue, soit en proportion de la population considérée, le volume de données, la durée de l’activité de traitement de données ou encore l’étendue géographique du traitement…
On le voit, une grande partie des objets connectés sont concernés par la réalisation d'analyses d’impacts. La CNIL a publié un guide concernant l’analyse d’impact relative aux objets connectés[16] ainsi que deux listes des types d’opérations pour lesquelles une analyse d’impact est nécessaire[17] ou non[18].
Une analyse d’impact est ainsi nécessaire, concernant certains traitements de données de santé :
dossier patients ;
algorithmes de prise de décision médicale ;
dispositifs de vigilances sanitaires et de gestion du risque ;
dispositifs de télémédecine ;
gestion du laboratoire de biologie médicale et de la pharmacie à usage intérieur, etc.
mise en œuvre d’une recherche médicale portant sur des patients et incluant le traitement de leurs données génétiques.
A l’inverse, une AIPD n’est pas nécessaire pour les traitements permettant :
la gestion des rendez-vous ;
la gestion des dossiers médicaux et l’édition des ordonnances ;
la gestion et la tenue des dossiers nécessaires au suivi du patient ;
l’établissement et la télétransmission des feuilles de soins ;
les communications entre professionnels identifiés participant à la prise en charge de la personne concernée.
Sécurité des objets connectés de santé
La sécurité des objets connectés en matière de santé est primordiale du fait du traitement régulier par ces objets de données sensibles, des coûts nécessaires pour prévenir tout type d’attaque et des risques potentiels de sanction en cas de violation des données. Les frais occasionnés par une cyber-attaque peuvent ainsi être particulièrement importants (150$ en moyenne par donnée personnelle perdue selon IBM[19]), outre les risques de réputation et d’image. Il semble ainsi que le secteur de la santé soit particulièrement exposé et que tout objet connecté commercial traitant de données de santé doit fait l’objet d’une attention très particulière.
De plus, il faut noter aussi que les organismes de santé (OMS[20], hôpitaux[21], etc.) sont des cibles privilégiées pour les hackers, les données de santé pouvant être revendues facilement sur le darknet. Récemment la société Greenbone Network a révélé que des millions d’images médicales sont en vente, par manque de sécurité des centres hospitaliers et d’imageries médicales.
L’ENISA (Agence de l’Union européenne pour la cybersécurité) a dressé la liste des principaux risques en termes de cybersécurité dans le domaine de la santé[22] :
Les actions malveillantes - dans cette catégorie se trouvent diverses menaces potentielles - les logiciels malveillants (virus, trojans, rootkits), piratage, attaques DoS, phishing, vol d'appareils, vol de données, effacement…
Les erreurs humaines - elles sont dues à des actions humaines involontaires, qui ont pour conséquence de nuire aux systèmes de santé
Défaillances du système - elles peuvent avoir différentes causes, les plus courantes étant : les défaillances de logiciels ou de microprogrammes, progiciels, les pannes d’appareils, interruption ou défaillance du réseau, maintenance insuffisante.
Défaillance de la chaîne d’approvisionnement - cette menace peut être causée par le fournisseur de service de cloud, le fournisseur de réseau, le fournisseur d'électricité ou par le fabricant de dispositifs médicaux, n’ayant pas pris les précautions nécessaires pour garantir l'intégrité de sa chaîne d’approvisionnement.
Les phénomènes naturels - il s’agit des incendies, inondations, tremblements de terre et d'autres catastrophes naturelles qui peuvent entraîner l'interruption du ou des services.
Pour étudier les objets connectés de santé, l’Agence Nationale de Santé et du Médicament distingue ainsi dans ses lignes directrices[23], les dispositifs médicaux dont l'utilisation est encadrée (v. fiche pratique sur le droit applicable aux objets connectés) des dispositifs non médicaux.
Constituent notamment des dispositifs médicaux au sens du règlement du 5 mai 2017 sur les dispositifs médicaux entrant en vigueur le 26 mai 2020[24], tout appareil, équipement ou logiciel utilisé seul on en association à des fins de diagnostic, prévention, contrôle ou prédiction d’une maladie. Est ainsi concerné tout logiciel utilisé à des fins médicales, ne serait-ce que pour mieux prévoir certaines affections des utilisateurs d'objets connectés. A ce titre, le nouveau règlement appréhende les logiciels comme des dispositifs médicaux à part entière (pouvant être utilisés seuls) tandis que la directive 93/42/CE abrogée n’envisageait les logiciels que lorsqu’ils étaient nécessaires au fonctionnement d’un appareil (utilisés en combinaison avec un appareil). De plus, un logiciel peut être qualifié de dispositif médical quel que soit son emplacement (par exemple fonctionnement en cloud, sur un ordinateur, un téléphone portable ou une fonctionnalité supplémentaire sur un appareil médical matériel).
Pour être qualifié de logiciel entrant dans la définition de dispositif médical, le logiciel doit avoir une finalité médicale en soi. Il convient de noter que l'objectif décrit par le fabricant du produit est pertinent pour la qualification et la classification de tout appareil.
Selon le « Medical Device Coordination Group »[25] chargé de conseiller la Commission européenne, constituent par exemple des dispositifs médicaux, une application de montre intelligente est destinée à envoyer des notifications d'alarme à l'utilisateur et/ou à un praticien de santé lorsqu'elle reconnaît des battements cardiaques irréguliers dans le but de détecter une arythmie cardiaque. Plus généralement, sera considéré comme un dispositif médical, tout logiciel générant des alarmes basées sur la surveillance et l'analyse des paramètres physiologiques spécifiques au patient. C’est également le cas de tout appareil portables intelligent - moniteurs de fréquence cardiaque, de niveau de transpiration, de taux d’alcoolémie. Il en va de même des systèmes d'intervention d'urgence pour réagir aux alertes.
A l’inverse, ne constituent pas des dispositifs médicaux :
Les systèmes d'information hospitaliers qui soutiennent le processus de gestion. Ils sont généralement destinés à l'admission des patients, à la prise de rendez-vous, à des fins d'assurance et de facturation
Les applications et logiciels de surveillance de condition physique, de coaching ou tout autre appareil de bien-être qui ne servent pas à prévoir ou traiter une maladie ne constituent pas des dispositifs médicaux selon le règlement et n'y sont donc par principe pas soumis. Sauf si ces applications sont utilisées en association avec une application ou un appareil de santé.
Ainsi, tout logiciel entrant dans la définition des dispositifs médicaux au sens du règlement devra respecter les normes harmonisées (ISO) et un marquage CE qui devra être mis à jour.
L’ENISA[26] a relevé d’ailleurs que plus de 25 normes ISO avaient été élaborées en informatique médicale et notamment :
ISO/DTR 22696 Health informatics — Guidance for identification and authentication for connectable personal healthcare devices
ISO/DTR 21332 Health informatics — Cloud computing considerations for health information systems security and privacy
ISO/WD 13131 Health informatics — Telehealth services — Quality planning guidelines
ISO/AWI 22697 Health informatics — Application of privacy management to personal health information
En outre, le règlement sur les dispositifs médicaux impose aux fabricants d’énoncer « les exigences minimales concernant le matériel informatique, les caractéristiques des réseaux informatiques et les mesures de sécurité informatique, y compris la protection contre l'accès non autorisé, qui sont nécessaires pour faire fonctionner le logiciel comme prévu »[27], ceci au regard de l’état de l’art en matière de cybersécurité au moment du développement et de la fabrication. Obligations qui recoupent celles du RGPD en matière de sécurité des données.
Néanmoins, même si toutes les mesures adéquates sont mises en place pour garantir la sécurité des objets connectés, tout organisme peut faire l’objet d’une violation de données au sens du RGPD, comme cela a déjà été présenté (attaques malveillantes, vol de données ou autre perte). En sus des mesures de sécurité informatique appropriées, il est important de prévoir des actions de formation du fait des risques liés aux erreurs humaines notamment. Enfin, la mise en place d'une procédure d’alerte en interne doit permettre de signaler et de faire remonter les éventuelles violations de données, afin d’en informer l’autorité compétente et les personnes concernées si la situation le justifie.
Dans ce cadre, la mise en place d’une procédure d’alerte constitue un outil pour se conformer aux articles 33 et 34 du RGPD. Une telle procédure permet en effet de guider les salariés qui connaitraient d’une violation de données, gagner du temps dans la transmission d’informations. Plus encore, cette procédure permet au responsable de traitement de s’assurer de la conformité juridique de la réponse apportée, au regard de ses obligations au titre du RGPD. Par conséquent, la mise en place d’une procédure d’alerte doit être prise en compte lors de la conception et de la commercialisation d’objets connectés de santé, procédure prévue par la directive sur les réseaux et systèmes d’information[28]. Ladite directive fait d’ailleurs expressément référence aux lignes directrices de l’ENISA relatives à la cybersécurité dans le domaine de la santé.
Une autre question essentielle pour une utilisation efficace et sûre des services est d'assurer un niveau élevé d'interopérabilité et de garantir que les informations sont transmises en toute sécurité par les objets connectés de santé. Par exemple, « le vocabulaire utilisé dans les enregistrements de santé électroniques, à savoir les terminologies, les classifications, les métadonnées ou les services de cloud entre différents fournisseurs de services de cloud, locaux ou externes, doit être basé sur des normes universellement appliquées et un cadre convenu ou sur certains protocoles/API ouverts pour l'échange d'informations et l'intégration de services sécurisés.»[29] Le manque d'interopérabilité peut affecter ainsi directement la disponibilité des données.
Enfin les garanties d’accès et d’authentification aux objets connectés de santé sont essentiels concernant la santé en ligne. En effet, le niveau de sécurité lié aux mesures d’authentification constitue une première étape clé pour permettre de valider les utilisateurs d’un objet, déterminer leur identité et l’autoriser à utiliser le système.
Une fois authentifiée, le niveau d'information que la personne est autorisée à consulter ou à partager doit aussi être défini par une politique de contrôle d’accès. A titre d’exemple, les nouvelles législations entrées en vigueur au 1er janvier 2020 en Californie et Oregon imposent ainsi aux fabricants d’IoT une authentification pour les utilisateurs d’objets connectés (v. fiche sur le droit applicable).