Vous êtes dans : Accueil > Tribunes libres >

Détournement juridique du décret d’hébergement de données de santé. Conclusion : un autre regard

François Kaag, président Afhads,, LUNDI 05 SEPTEMBRE 2016

La série d’articles de Cédric Cartau a bien mis en évidence la fragilité conceptuelle du modèle actuel de l’hébergement de données de santé. Puisqu’il est en cours de refonte, il me semble intéressant de creuser un peu plus sur les origines de cette faiblesse afin de s’assurer qu’elle ne sera pas reconduite.

En 2002, la notion d’agrément Hébergeur apparaît dans la loi Kouchner et fait suite notamment aux travaux de la Cnil largement décrits dans son rapport d’activité de l’an 2000.

À cette époque, la distinction entre l’offreur de services et l’hébergeur est loin d’être aussi claire qu’aujourd’hui, les quelques sites existants sont auto-hébergés. Le texte, dont le but est de protéger les établissements contre une réutilisation abusive de leurs données, privilégie le terme d’hébergement, probablement parce que celui-ci est plus facile à qualifier en droit que la mise en œuvre du traitement.

Dans le décret d’application de 2006, cet amalgame est toujours présent. On demande à l’hébergeur de présenter un certain nombre de mesures qui relèvent clairement de l’opérateur du service applicatif, par exemple s’assurer :

  • de l’existence du consentement de l’intéressé à l’hébergement des données le concernant ;
  • des modalités retenues pour que l’accès aux données de santé n’ait lieu qu’avec l’accord des personnes concernées ;
  • des conditions de prise en compte des demandes de rectification des données ;
  • des modalités de vérification du registre des personnes habilitées à accéder aux données hébergées.

L’exigence d’avoir dans l’organisation de l’hébergeur un médecin suit la même logique. Elle n’est pertinente que dans la mesure où l’hébergeur assurerait une intervention sur les données.

En 2009, lorsque le référentiel d’agrément paraît et que les premiers dossiers d’agrément sont déposés, le paysage technique a totalement changé. Les datacenters se multiplient, et les fournisseurs de service se déchargent totalement de l’aspect infrastructure sur les hébergeurs.

Du coup, les dossiers remis se structurent en deux catégories :

  • les offreurs de services, par exemple les éditeurs en mode SaaS, dont le dossier couvre tout le périmètre technique et applicatif. Ils font le plus souvent appel à des hébergeurs tiers, qu’ils font apparaître dans leur dossier en tant que sous-traitants ;
  • Les hébergeurs ouverts, qui reportent sur leurs clients (établissements ou offreurs de services) certaines obligations auxquelles ils ne peuvent répondre faute d’avoir la maîtrise de l’application hébergée ou de son contexte d’utilisation.

Les établissements ou GCS de moyens ayant obtenu un agrément sont dans une position intermédiaire. Objectivement, ce sont des offreurs de services, mais ils ne peuvent repasser un agrément à chaque évolution de leur parc applicatif, ce qui peut les conduire à définir des règles génériques d’intégration comme un hébergeur ouvert.

Au fil du temps, la notion d’hébergeur ouvert s’est de plus en plus étendue. Les premiers assuraient autant que possible la conformité technique des applications hébergées, ne reportant des exigences que sur la relation au patient et l’usage des applications. Sont venus ensuite des reports d’exigences techniques, comme la mise en œuvre de moyens d’authentification forte, pour en aboutir finalement aux agréments de salles blanches avec un report d’exigences quasi intégral. Le comité d’agrément s’était inquiété dès 2012 de l’absence de contrôle effectif de ces obligations reportées, mais la pratique ultérieure ne s’en est pas moins relâchée.

Pourtant, le fait de faire porter sur les hébergeurs une obligation de sécurisation des applications hébergées, s’il n’est pas conforme à l’acception générale du terme d’hébergeur, n’est pas dénué de vertu. Il permet de mutualiser des compétences rares, qu’il s’agisse de sécurité générale ou des règles spécifiques applicables à la donnée de santé. Avec la démocratisation des outils de développement Web, bon nombre d’applications pertinentes sont produites par des start-up, des développeurs amateurs ou des utilisateurs finaux. Sans cet accompagnement qu’ils sont contraints de prendre, des failles de sécurité ou des écarts majeurs à la législation seraient inévitables.

La position de l’Afhads, telle que présentée notamment dans son livre blanc[1] de 2014, a toujours été de défendre et de mettre en valeur ce rôle des hébergeurs de données de santé. C’est aussi à ce titre que nous avons publié en décembre 2014 un avis[2] sur l’erreur que constituait l’attribution de l’agrément à des salles blanches.

Les contraintes organisationnelles et budgétaires font qu’à la procédure actuelle d’agrément par instruction de dossier va se substituer une certification. Puisqu’on ne peut se satisfaire de la situation actuelle, mais qu’il serait déloyal envers les hébergeurs actuellement agréés sur un périmètre de salle blanche de revenir à une définition plus restrictive, on s’achemine vers deux niveaux de certification :

  • une certification d’hébergeur de données de santé, incluant les processus de vérification et de maintien de la conformité des applications hébergées aux référentiels opposables de la PGSSI-S (identification et authentification des professionnels, identification et authentification des patients, imputabilité) ;
  • une certification d’hébergeur d’infrastructure, couvrant les services de mise à disposition d’une salle blanche, voire de fourniture de serveurs physiques. On peut la considérer comme une offre d’immobilier spécialisé, dont les clients ne pourront être que des établissements de santé ou des titulaires d’une certification HDS.

Les hébergeurs actuels pourront choisir le positionnement qui leur convient le mieux. Contrairement à l’agrément actuel, la certification attestera de la capacité du titulaire à mettre en œuvre des solutions de sécurité appropriées pour les applications qu’il héberge, et non de la validité d’une solution particulière pour un besoin particulier. Ce sera donc également bien plus approprié pour les établissements qui offrent des services à d’autres structures, notamment les établissements supports des GHT.

Alors, certes, on n’apporte pas de réponse à d’éventuelles faiblesses au sein d’un établissement ou dans ses recours à des sous-traitants. Gageons toutefois que le référentiel de certification HDS représentera dans un premier temps au moins un état de l’art directement exploitable. Et, à terme, la certification commune de la HAS pour les établissements d’un GHT (obligatoire à partir de 2020) et la certification HDS de l’établissement support pourraient fort bien fusionner, l’établissement support étant alors pilote de la mise en conformité des membres du GHT.

François Kaag, président de l’Afhads (avec la collaboration de Cédric Cartau)

[1] http://www.dsih.fr/livres-blancs-sih/AFHADS.php

[2] https:/www.afhads.fr/?p=989

#données de santé#cédric cartau#hébergeurs#sécurité#agrément#hébergeur#périmètre


Les plus lus