Ce billet est la version écrite de l’intervention que j’ai réalisée le 26 juin dernier au colloque « Applis smartphones et santé : promesses et menaces » organisé par l’Institut Droit & Santé. Certains points sont traités rapidement, ayant été étudiés par les précédents intervenants, et notamment M. Thierry Sirdey de l’ANSM.
Les freins et leviers pouvant être rencontrés dans le cadre d’un projet de mHealth sont de plusieurs ordres : juridique, économique, politique, technique, mais surtout socio-culturel.
La mHealth ne se développera pas sans la confiance des utilisateurs.
En matière de santé, la confiance passe systématiquement par des mécanismes juridiques. Citons pêle-mêle l’obligation d’assurance des professionnels et établissements de santé (art. L1142-2 CSP), la responsabilité sans faute du fait des vaccinations obligatoires (art. L3111-9 CSP), l’autorisation de mise sur le marché des médicaments (art. L5121-1 CSP) et le marquage CE des dispositifs médicaux (art. R5211-12 CSP).
Tous ces dispositifs ont vocation à garantir la confiance des usagers du système de santé, les uns en amont, les autres en aval.
Tous ces dispositifs traduisent un refus du risque en matière de santé.
Et des risques, dans la mHealth, il y en a. Nombreux, divers et variés, numériques et corporels. Mais plutôt que de les identifier – ou plutôt tenter de les identifier – un à un, focalisons-nous sur l’hypothèse d’un dommage causé à l’utilisateur et tournons-nous vers les responsables. Qui sont-ils ? Comment les actionne-t-on ? Quelles sont les chances de succès et d’obtention d’une indemnisation ?
I) – La responsabilité de l’éditeur d’application de santé mobile
Le régime de responsabilité de l’éditeur ne varie pas énormément en fonction de la qualification juridique de l’application. En revanche, la faute devrait être appréciée de façon radicalement différente selon qu’il s’agit ou non d’un produit de santé. Avant de mettre une application sur le marché, tout éditeur doit donc se demander : Constitue-t-elle un dispositif médical logiciel, au sens de l’article L5211-1 du Code de la Santé Publique ou non ?
A) – L’application comme dispositif médical
Au même titre que les professionnels et établissements de santé, les fabricants de produits de santé sont légalement tenus de souscrire une assurance responsabilité civile (art. L1142-2 CSP). Mais dans sa hâte, le législateur a omis de leur étendre le dispositif de l’article L1142-1 du Code de la Santé Publique. La responsabilité des fabricants de dispositifs médicaux doit donc être envisagée sous l’angle du droit commun, mais en tenant compte de l’obligation de sécurité pesant sur les produits de santé.
La responsabilité du fait des produits défectueux paraît alors le fondement le plus opportun. C’est en tout cas le cas pour les défauts dus à un dispositif médical matériel. Mais ce régime de faveur trouve-t-il à s’appliquer aux éditeurs d’applications de santé mobile ? La réponse est à l’évidence négative. En effet, les articles 1386-1 et suivants du Code Civil ne trouvent à s’appliquer qu’aux biens meubles et, par exception, à l’électricité. Sauf à considérer qu’un logiciel n’est jamais qu’un amas d’électricité, ce fondement doit donc être exclu.
Reste alors la responsabilité civile classique. Par hypothèse contractuelle, évidemment. Et sur ce point, inutile de préciser que les clauses destinées à écarter le caractère spécifiquement médical de l’application ou à limiter, voire exclure, la responsabilité de l’éditeur seront très vraisemblablement écartées par le juge. Le montant de l’indemnité due à la victime sera ici fonction de la gravité du préjudice.
Mais un autre texte ne pourrait-il pas s’appliquer ? Imaginons une application qui serait un peu trop indiscrète ou un peu trop bavarde. Ne pourrait-elle pas porter atteinte à la vie privée de l’utilisateur ? Le cas échéant, c’est sur le fondement de l’article 9 du Code Civil qu’il faudrait alors agir. Les probabilités de succès des poursuites sont alors élevées. L’atteinte à la vie privée résulterait en effet d’un manquement à l’obligation de confidentialité des données personnelles, constitutive d’une obligation de moyens renforcée (Crim., 30 octobre 2001, n° 99-82136). La preuve de la faute serait donc aisée à rapporter. Mieux, aucun préjudice n’aurait alors à être démontré. Car on le sait, la seule publication des informations suffit à caractériser le préjudice (Civ. 1ère, 28 avril 2011, n° 10-17909). Les chances de succès d’une telle action sont donc sérieux. Cependant, sauf à être une personnalité, le montant de l’indemnisation ne devrait pas être faramineux. Heureusement pour l’éditeur, car même assuré, il y a peu de chance que sa police « RCP obligatoire » couvre ce type de dommage.
B) – L’application n’est pas un dispositif médical
Si l’application ne constitue pas un dispositif médical, l’éditeur peut voir sa responsabilité engagée sur les deux mêmes fondements. La différence ici tiendra à la nature de la faute, le juge ne devant logiquement pas avoir le même niveau d’exigence pour un gadget que pour un dispositif médical logiciel.
Différentes formes sont envisageables :
– défaut de validation médicale ;
– erreur dans les conseils délivrés ;
– absence de sécurité logique : quid si l’installation d’un autre logiciel modifie un fichier essentiel à une application de mesure de la tension artérielle et en fausse les résultats ? Ce risque existe, pensez à ce virus informatique écrit pour une centrale nucléaire iranienne qui a planté tous nos ordinateurs.
La typologie des fautes pouvant être reprochées à un éditeur témoigne du risque pesant sur lui en cas de dommage. De dommage potentiellement corporel et économique. Car là aussi, il n’est pas inutile de rappeler que le numérique peut tuer un malade, comme ce fut le cas d’une patiente d’un Centre Hospitalier d’Ile-de-France en 2012.
Ce risque est-il assuré ? Dans l’immense majorité des cas, non. On parle d’un domaine qui s’ouvre aux pure players majeurs depuis quelques semaines seulement. L’écosystème est pour l’heure majoritairement composé de start-up, d’autoentrepreneurs et de développeurs amateurs qui ont économisé sur les frais d’assurance.
C) – Et au pénal ?
La victime d’une application de santé mobile ou ses ayants droit pourraient naturellement tenter une action pour homicide ou violences involontaires. Dans cette hypothèse, le juge répressif s’interrogerait certainement sur la qualification juridique de l’application. Et peu de doutes qu’il se montrerait sévère vis-à-vis de l’éditeur, dans cette hypothèse, lui faisant ainsi encourir des condamnations supplémentaires, notamment pour avoir mis sur le marché un dispositif médical non certifié.
Mais une autre question se pose. L’éditeur pourrait-il être poursuivi pour exercice illégal de la médecine ? Tout dépend ici du niveau d’autonomie de l’application, mais dans un cas comme dans l’autre, l’éditeur risque d’être le perdant. Autonome, l’application est un dispositif médical : Responsabilité pénale de l’éditeur s’il ne s’est pas conformé aux obligations pesant sur tout fabricant de DM. Dépendante, l’application est un outil d’aide à la décision : L’éditeur ou son sous-traitant sont passibles de poursuites pour exercice illégal.
II) – La responsabilité de l’utilisateur
Les applications de mHealth peuvent être destinées aux professionnels de santé comme aux malades. L’un et l’autre peuvent commettre une faute susceptible d’engager leur responsabilité ou de constituer une cause exonératoire.
Mais n’y a-t-il pas un autre utilisateur ? Ou plutôt un réutilisateur des données collectées par les applications ?
A) – L’utilisateur professionnel de santé
Les professionnels de santé bénéficient d’un régime de responsabilité du fait des matériels utilisés qui leur est en principe favorable, depuis un arrêt CHU de Besançon de la CJUE (CJUE, 21 décembre 2011, n° C-495/10). Ils ne sont tenus que des dommages consécutifs à une faute ou lorsqu’il est impossible d’identifier le fournisseur.
Mais c’est là que le bât blesse. Identifier l’éditeur d’une application de santé mobile est bien plus délicat que pour un outil matériel. En règle générale, pas de marquage CE, pas de notice, pas d’emballage. Et les mentions légales imposées par la LCEN ne s’appliquent pas aux applications de santé mobile. Le furent-elles que cela n’aurait rien changé, cette obligation étant rarement respectée. En cas de dommage causé par l’utilisation ou le fonctionnement d’une appli de santé mobile, le professionnel de santé risque donc de se retrouver en première ligne, au contentieux.
Mais la responsabilité pour faute n’est pas en reste. En effet, n’est-ce pas une faute d’utiliser un outil qualifiable de DM mais n’ayant pas été certifié ? De recourir à un outil dont les Conditions Générales d’Utilisation précisent, comme c’est souvent le cas, que la fiabilité du résultat n’est pas garantie ? De recommander à un patient l’utilisation d’une application qui n’a fait l’objet d’aucune validation technique et scientifique ? La réponse est manifestement positive. De même que le professionnel de santé doit s’assurer de l’innocuité du traitement qu’il prescrit ou des soins qu’il dispense, la mHealth va faire peser sur lui une obligation de vigilance quant aux outils numériques qu’il utilise.
B) – Le malade utilisateur
Envisager le patient comme responsable, mais pourquoi donc ? Tout simplement parce qu’en cas de mésusage de l’application, le professionnel de santé ou l’éditeur actionné pourrait alors exciper d’une cause exonératoire. Ce serait certes délicat, eu égard à l’étendue de l’obligation d’information pesant sur ces deux derniers protagonistes. Mais ce n’est pas forcément un cas d’école si l’on raisonne par analogie avec la cause exonératoire en matière d’infection nosocomiale.
Bientôt, lors de l’anamnèse, les professionnels de santé pourraient ainsi demander : « prenez-vous un traitement ou utilisez-vous une appli de santé mobile, en ce moment ? »
C) – L’utilisateur chercheur
La mHealth permet de collecter un volume impressionnant de données. Et la tentation de réutiliser ces données est forte. Certains éditeurs ont déjà cédé, d’autres ont même construit leur modèle économique sur cette réutilisation. Et le phénomène n’est pas forcément aussi néfaste que certains veulent bien le dire. Fréquemment, la réutilisation est proposée à des fins de recherche. Car Bigdata et opendata recèlent en effet des promesses alléchantes en la matière.
Mais n’est-ce pas un risque que d’utiliser des données collectées par des applications dont la fiabilité n’est ni testée, ni garantie ? Quelle responsabilité pour les produits et services qui seraient développés sur les bases d’études établies à partir de telles informations ? Quelle responsabilité pour les autorités validant un dispositif, un produit ou un service sur la base d’études cliniques réalisées à partir de telles données ?
III) – La responsabilité des tiers
L’application de santé mobile s’installe, par hypothèse, sur un smartphone. C’est-à-dire dans un système d’information non contrôlé par l’utilisateur. Or, les stores d’applications mobiles croulent déjà sous le nombre de jeux gratuits qui volent les données de l’utilisateur. La mHealth expose donc tout utilisateur à une divulgation de ses données à caractère personnel.
Quelle responsabilité pour les éditeurs de tels spywares ? Ici, on peut envisager aussi bien une action sur les articles 9 ou 1382 du Code Civil que sur le fondement du Code Pénal pour atteinte à la vie privée et captation illicite de l’image, voir pour maintien dans un Système de Traitement Automatique de Données (STAD).
Mais tant au pénal qu’au civil, l’action a peu de chance d’aboutir. C’est donc à l’utilisateur de prendre ses précautions et à l’éditeur de renforcer la sécurité des données stockées localement sur le terminal.
* *
*
Les risques sont multiples et viennent d’azimuts très différents. Mais en pratique, ils se résument toutefois à un simple triptyque : sécurité logicielle, sûreté sanitaire et confidentialité.
Chacun de ces risques peut se traduire pour l’éditeur d’une application de santé mobile par une action en responsabilité.
Comment s’en prémunir ? La solution idéale consiste à faire labelliser les logiciels de mHealth. Déjà, la CNIL y réfléchit pour l’aspect confidentialité, le CNOM pour la sûreté sanitaire. Les plus au fait de l’actualité de la Food & Drug Administration américaine rétorqueront que justement, la FDA a récemment annoncé qu’elle ne souhaitait pas une généralisation de la certification en mHealth. Certes, mais outre le fait que ce revirement n’est que partiel, il faut noter que le système juridique américain est très différent, ne serait-ce que parce qu’il permet la class action en matière sanitaire, et qu’il accepte le risque. A l’inverse, les récents scandales « médicamenteux » montrent que la France veut un « risque 0 ». Et objectivement, il n’y a aucune raison que ce désir de sécurité sanitaire ne se transpose pas à la mHealth.
Dans l’attente de la mise en place d’un mécanisme de certification – que l’on espère mis en place au niveau communautaire, la m-santé ne pouvant échapper au marché unique – il faut promouvoir l’éducation numérique auprès des utilisateurs mais aussi des éditeurs. Leur attention doit être attirée sur les risques encourus afin qu’ils puissent adopter les mesures techniques et juridiques garantissant l’innocuité de leurs appli, la confidentialité des données et, peut-être, l’éthique du dispositif.