Quelques réflexions avant l’été

L’actualité, c’est tout d’abord cette énorme fuite de données du laboratoire Cerba. Cerba, ce n’est pas le laboratoire de quartier, si l’on en croit son site Internet, c’est le leader européen des analyses de biologie, avec pas moins de 40 000 analyses par jour et 5 000 clients dans le monde (vérifications faites, plusieurs établissements de santé par GHT en sont clients). Or, si l’on en croit la communication du groupe[1], la plateforme technique de Cerba a été victime d’une « exposition momentanée de données » par la faute (on ne sait pas laquelle) d’un de leurs prestataires d’hébergement (on ne sait pas lequel). Bon, jusque-là, que du classique, et seul celui qui n’a jamais fait d’informatique peut prétendre ne jamais avoir fauté.

Là où c’est plus étrange, c’est que la communication stipule que Cerba se considère comme responsable de traitement des analyses de biologie qui lui sont confiées. Le problème, c’est que la quasi-totalité des DPO à qui cette question a été posée a exactement l’analyse inverse : Cerba est sous-traitant (ST), en aucun cas responsable de traitement (RT). En effet, Cerba n’analyse pas un tube de sang juste pour le fun, mais parce qu’un donneur d’ordre (un client) le lui demande. En ce sens, c’est bien le client et non Cerba qui définit l’objectif, Cerba se contentant de mettre en place les automates et le système automatisé de rendu des résultats. Ce n’est d’ailleurs absolument pas incompatible avec le fait que le ST effectue la déclaration Cnil et informe les patients dont les données ont fuité, c’est juste que la qualification de RT (analyse de Cerba) exonère Cerba de rendre des comptes à ses clients : analyse du dysfonctionnement, communication sur le plan de sécurisation, etc. Mettez-vous à la place d’un patient dont l’hospitalisation a donné lieu à une analyse de sang : peu lui importe que le CH/CHU concerné sous-traite son analyse en Zambie : en termes de fuite de données, il ne connaît que le CH/CHU, et c’est bien à lui qu’il va demander des comptes.

Dernière réflexion avant la plage : les applis de niche du secteur de la santé accessibles aux patients eux-mêmes par smartphone. Je suis tombé récemment sur l’une d’entre elles, qui cible une pathologie très précise difficile à diagnostiquer, et qui propose aux patients de saisir un ensemble de données qui sera ensuite passé à une moulinette algorithmique chargée de calculer le pourcentage de probabilité de telle ou telle pathologie. L’intérêt médical est indiscutable, mais c’est après que tout se corse.

En effet, la suite logique consiste à donner l’accès de ce minidossier médical de spécialité à tel praticien afin qu’il prenne connaissance des éléments renseignés par le patient lui-même. Et, tant qu’à faire, qu’il y ajoute des commentaires, avec la possibilité de prendre connaissance de ceux de ses confrères, le tout pour une meilleure prise en charge médicale s’entend. Premier travers, ce genre d’application tend à déshabiller les DPI des établissements de santé : le DP d’un patient est en effet unique et sous la seule responsabilité de l’établissement de santé. Retrouver des éléments éparpillés sur le Web est tout simplement inenvisageable pour de simples questions de responsabilité juridique. Second travers : qui est RT de cette application ? L’éditeur vous explique que c’est lui (OK, je veux bien) et qu’il peut mettre en place une seconde base servant de dossier de spécialité pour le CH en question, seconde base dans laquelle le praticien saisira ses remarques, ses CR de consultation, etc. Mais qui est RT de cette seconde base ? Le CH ? Comment transfère-t-on des données de la première base (premier traitement) à la seconde en termes d’autorisation ? Comment s’assure-t-on des bonnes règles d’identitovigilance (si vous pensez que les patients sont à même de remplir correctement l’intégralité des cinq à sept champs obligatoires d’identité, vous vous trompez lourdement) ? Comment assure-t-on les fusions d’identité ou leur éclatement en cas d’erreur ? Comment intègre-t-on plus ou moins automatiquement les données de la seconde base dans le DPI local ? Comment gère-t-on le droit à la rectification et l’effacement au sein de trois bases, sachant que pour le DPI et la seconde base les règles ne sont absolument pas les mêmes que pour la première ? Bref, c’est la chienlit.

Bon été quand même.

[1] https://www.lab-cerba.com/sites/Cerba/home/vous-informer/news/incident-de-securite-mycerba.html