Externalisation de la prise de rendez-vous médicaux en ligne : un pacte avec le diable ?

Ici commence un scénario totalement imaginaire (toute ressemblance avec des faits réels ne serait que pure et fortuite coïncidence) :

Trouver une solution compatible avec le DPI (elles le sont toutes avant de signer le bon de commande, mais bien moins après), « bricoler » de nouvelles interfaces venant s’ajouter au sac de nœuds existant en portant à bout de bras trois éditeurs qui n’ont pas du tout envie de travailler ensemble, le tout pour la semaine prochaine, en continuant de gérer les autres projets en cours et sans trop dépenser car ce n’était pas prévu au budget.

Comme vous n’avez ni le temps ni le budget d’investissement pour le faire, le recours à l’externalisation apparaît souvent comme l’ultime solution. De plus, DG et président de CME ont été conquis par le commercial venu les démarcher et comme la solution est déployée un peu partout, pourquoi pas chez vous ?
Faire appel à un prestataire semble donc être le moyen d’économiser un temps précieux et se faire des amis.

C’est là que pourrait bien commencer le cauchemar technico-juridique du RSSI et du DPO…
Pour continuer de plancher sur mon scénario, j’ai donc fait appel à un brillant expert en droit de la santé, M^e Omar Yahia.

CBR : Maître, selon vous, si mon prestataire de prise de rendez-vous en ligne me demande de lui donner les identités de tous les patients de mon établissement pour pouvoir me fournir ce service en ligne, est-ce conforme à la réglementation ?

OY : Comme le savent nos lecteurs assidus, l’article 5 du RGPD rappelle que tout traitement de données à caractère personnel doit satisfaire à plusieurs principes parmi lesquels la finalité et la proportionnalité des données collectées.

Si le prestataire propose un service de gestion des rendez-vous des patients, alors l’établissement ne doit lui fournir que les données nécessaires à cet effet. Compte tenu de la variété des profils de patients d’un établissement de santé, je doute que l’identité de tous les patients soit justifiée et je suis même persuadé que vous allez m’en donner immédiatement un contre-exemple.

CBR : Effectivement, prenons le cas d’un patient « de passage » pris en charge aux urgences, qui n’a jamais été admis dans un autre service auparavant et ne reviendra probablement jamais dans mon établissement car il n’est pas de la région. À aucun moment la prise de rendez-vous ne peut être considérée comme une finalité du traitement que je réalise. Puis-je malgré tout transmettre légalement son identité à mon prestataire de prise de rendez-vous en ligne ?

OY : Exemple pertinent. Pour un tel patient, la finalité du traitement « prise de rendez-vous » n’est pas conforme.

Il en irait autrement de la finalité « gestion du dossier patient » puisque, dans ce cas, tout patient pris en charge doit avoir un dossier patient dans l’établissement, qu’il y ait pris un rendez-vous ou non.

CBR : Le prestataire auquel je fais appel dispose d’un site Web et d’une application mobile pour lesquels il demande à mon patient de se créer un compte utilisateur. Ce compte pourra lui servir à prendre des rendez-vous dans mon établissement, mais également chez son médecin traitant, son dentiste ou dans un autre établissement. Il peut d’ailleurs disposer d’un compte chez ce prestataire avant même d’avoir mis les pieds dans mon établissement. Dans ces conditions, peut-on considérer que ce prestataire fait toujours office de sous-traitant pour ce traitement ou n’en serait-il pas plutôt le responsable ? Si c’est le cas, et si c’est moi qui l’incite à se créer un compte via un lien, un appel contextuel ou une « frame » que je dispose sur le site Web de mon établissement, pourrais-je alors être considéré comme coresponsable du traitement propre à mon prestataire ?

OY : Pour répondre à votre question, il y a lieu de distinguer deux traitements :

Le prestataire est responsable du traitement mis en œuvre pour créer le compte utilisateur du patient sur la plate-forme, traitement dans lequel l’établissement n’intervient pas.

En effet, il se peut qu’un patient crée un compte utilisateur après avoir consulté le site de l’établissement mais n’y prenne finalement aucun rendez-vous. Dans ce cas, l’établissement ne disposera d’aucune donnée personnelle le concernant.

En revanche, si le compte est créé par le patient pour prendre un rendez-vous dans l’établissement, alors c’est bien celui-ci qui est considéré comme responsable du traitement, le prestataire n’intervenant qu’en qualité de sous-traitant.

Selon le guide rédigé conjointement par la Cnil et l’ordre national des médecins, l’établissement de santé ou le médecin qui collecte des données personnelles pour les besoins de suivi du patient est considéré comme responsable de ce traitement.

C’est à lui qu’il appartient de vérifier que les données collectées satisfont aux principes posés par le RGPD et de s’assurer que ses sous-traitants présentent les mêmes garanties.

Ajoutons que les données collectées ne doivent être conservées que pendant la durée nécessaire à la finalité poursuivie. Dans le cas de la prise de rendez-vous en ligne, on peut s’interroger sur la pertinence de conserver la trace du rendez-vous, une fois celui-ci réalisé.

CBR : En créant un compte de test sur le site de mon prestataire, je me rends compte qu’il m’est possible d’utiliser 12345678 comme mot de passe. Je constate donc, que contrairement à la plupart des sites marchands, qui eux ne traitent pas des données de santé, il ne respecte pas la délibération n° 2017-012 du 19 janvier 2017 portant adoption d’une recommandation relative aux mots de passe. En effet, aucune complexité ne m’est demandée. Puis-je être considéré comme coresponsable de cette infraction ?

OY : L’établissement de santé est le premier et seul responsable. L’article 24 du RGPD fait peser sur le responsable du traitement la charge de mettre en œuvre les mesures techniques et organisationnelles appropriées pour s’assurer et être en mesure de démontrer que le traitement est effectué conformément à la réglementation.

L’article 28 du même texte expose qu’en cas de sous-traitance le responsable du traitement doit s’assurer que le sous-traitant présente les mêmes garanties que lui sur ce point.

Dans votre hypothèse, l’établissement est donc responsable de la sécurité des données à caractère personnel qu’il met en œuvre pour la gestion des rendez-vous patients et doit veiller à ce que le prestataire auquel il recourt mette en place des mesures de sécurité suffisantes concernant la protection des données collectées, a fortiori lorsqu’il s’agit de données sensibles telles que les données de santé.

CBR : Ce prestataire héberge les données de santé de mes patients chez un ou plusieurs hébergeurs certifiés HDS, dont un d’origine américaine. Je sais que le RGPD les protège, mais je fais malgré tout courir le risque que les données de mes patients puissent être consultées par la justice américaine sans qu’ils en soient informés, ni même mon prestataire, n’est-ce pas ?

OY : C’est exact. L’hébergeur basé aux États-Unis invoque probablement le fait qu’il respecte le bouclier de protection des données (ou Privacy Shield).

Il s’agit d’un mécanisme d’autocertification des entreprises établies aux États-Unis, reconnu par la Commission européenne dès lors qu’elle estime que ces entreprises offrent un niveau de protection adéquat aux données à caractère personnel transférées par une entité européenne vers des entreprises établies aux États-Unis.

Il semblerait que ce bouclier permette à nos données d’être transférées outre-Atlantique de manière tout à fait sécurisée.

Pourtant, tel n’est pas tout à fait le cas. En effet, avec l’adoption du Clarifying Lawful Overseas Use of Data Act, aussi appelé « Cloud Act », le 26 mars 2018, les autorités de poursuite américaines se sont arrogé le droit d’accéder partout dans le monde aux données hébergées par une société américaine qui fournit des services informatiques à distance tels que, par exemple, l’hébergement dans le Cloud.

CBR : En regardant d’un peu plus près, je constate que le site Web de mon prestataire utilise le service de protection anti-déni de service de Cloudflare, là encore un opérateur américain, mais qui lui n’est pas hébergeur de données de santé.

Ce qui veut dire que Cloudflare stocke l’adresse IP publique de mon patient (donnée à caractère personnel), et dépose un cookie sur son terminal permettant potentiellement de tracer ses actions en ligne :

Idem avec l’armada de cookies Google (services non HDS) déployés sur le navigateur, avec encore une fois remontée potentielle de l’adresse IP et traçabilité des actions utilisateurs.

De plus, les URL contiennent le nom de l’établissement ou du spécialiste, ce qui permet donc à Google non HDS et Cloudflare de connaître dans plusieurs cas la pathologie de mon patient :

On ne peut pas dire que mon sous-traitant, et moi, en connaissance de cause, avons mis en place tous les moyens de protection nécessaires à la confidentialité des données des patients de mon établissement…

OY : Non, cela est certain. Non seulement l’établissement de santé ainsi que son sous-traitant font transiter des données de santé par des hébergeurs non certifiés HDS, mais votre exemple met en évidence un manquement à la confidentialité des données de santé en ce qu’il permet de faire le lien entre une personne et une pathologie.

CBR : Si je pousse le bouchon encore un peu plus loin, mon prestataire envoie des SMS et des courriels à mon patient pour lui rappeler ses rendez-vous. Ces données sont donc susceptibles d’être interceptées car non chiffrées et échangées sur des flux « en clair » dans de nombreux cas. Maître, nous sommes d’accord sur le fait qu’un rendez-vous médical avec un spécialiste est bien une donnée de santé ?

OY : Une nouvelle fois, vous visez juste.

L’article 4.15 du RGPD définit les données concernant la santé comme « les données à caractère personnel relatives à la santé physique ou mentale d’une personne physique, y compris la prestation de services de soins de santé, qui révèlent des informations sur l’état de santé de cette personne ».

Ainsi, le fait de recevoir un message de rappel d’un rendez-vous médical avec un professionnel ou un établissement de santé sur son téléphone portable correspond manifestement à une donnée de santé pouvant être lue, stockée et conservée par l’opérateur téléphonique.

Prenons l’exemple de votre patient qui prend un rendez-vous à 14 heures à l’hôpital Bichat – Claude-Bernard via la plateforme en ligne. Un simple clic sur Internet suffit pour comprendre que l’hôpital Bichat est spécialisé en cancérologie. La sécurité du traitement de cette donnée à caractère personnel me semble manifestement insuffisante.

CBR : En allant toujours un peu plus loin, l’opérateur téléphonique de mon patient connaît donc l’état de santé de mon patient, et son fournisseur de messagerie se voit donc stocker des données de santé sans être HDS. Dans ce cas, peut-on dire que mon prestataire, et moi, en tant que responsable de traitement, ne respectons pas l’article L1110-4 ni l’article R1111-8-8 du Code de la santé publique relatifs au « secret médical » et à l’hébergement de données de santé à caractère personnel ?

OY : Oui, je le crains.

Si ces données ne sont pas anonymisées ou en l’absence de chiffrement de bout en bout, votre exemple illustre le cas de données de santé transitant et stockées par des sociétés qui n’ont aucun droit à l’accès, au partage et à l’échange de ces données. Or, comme nous l’avons rappelé, c’est au responsable de traitement de s’assurer de la confidentialité des données à caractère personnel qu’il traite.

CBR : Merci Maître pour votre précieux éclairage, qui je l’espère nous permettra à tous d’y voir plus clair sur ce sujet plus complexe qu’il n’y paraît.