FAQ de l'offre : Conformité (labels, référencements et certifications)

Pour rappel l’exigence ETH.26 est la suivante : "Si les données recueillies avant, pendant, après la téléconsultation sont partagées avec d'autres acteurs, notamment des sous-traitants, ALORS le Système DOIT garantir la bonne compréhension par le patient de l’existence de ce partage et de sa finalité." 

Pour répondre à l’exigence ETH.26, l’information relative au partage des données du patient doit être formulée de manière claire, explicite et accessible. Le patient doit comprendre que ses données peuvent être partagées, avec quels acteurs ou sous-traitants, et dans quel objectif précis (hébergement, maintenance technique, analyse statistique, etc.). 

Les destinataires des données doivent être clairement identifiés, au moyen d’une liste transparente et facilement accessible, intégrée notamment dans la politique de confidentialité, les Conditions Générales d’Utilisation ou tout autre document porté à la connaissance du patient. 

En complément, le système doit prévoir un mécanisme de reconnaissance explicite attestant que le patient a pris connaissance de cette information et la comprend (case à cocher, formulaire de consentement, ou dispositif équivalent), afin d’en garantir la traçabilité et de permettre au patient d’exercer pleinement ses droits en matière de protection des données.

Pour rappel, les exigences ETH.13 et ETH.14 sont les suivantes : "S’il existe un lien d’intérêt entre la société éditrice du système et des acteurs de l’écosystème de la santé, le système doit garantir, d’une part, la bonne compréhension de ce lien par le professionnel de santé utilisateur et, d’autre part, l’information et la bonne compréhension du patient." 

Le lien d’intérêt désigne l’ensemble des relations ou intérêts, directs ou indirects, actuels ou passés, qu’une société peut entretenir avec un tiers, dès lors que ces relations sont en lien avec l’objet de son activité. Dans le cadre d’un système de téléconsultation, cela concerne notamment les partenariats entretenus avec des établissements de santé, mutuelles, laboratoires, entreprises technologiques, prestataires techniques, éditeurs de logiciels ou tout autre acteur économique. L’objectif de ces exigences est d’assurer une transparence totale sur les partenariats et liens d'intérêt susceptibles d’influencer l’usage du système ou les décisions de prise en charge, afin de prévenir tout risque de conflit d’intérêts et de maintenir la confiance des professionnels de santé et des patients. 

Pour répondre à ces exigences, il est attendu de la société éditrice qu’elle mette à disposition des documents clairs, accessibles et explicites décrivant l’ensemble des liens d’intérêt existants, en précisant la nature des relations, qu’elles soient contractuelles, financières, techniques ou stratégiques, sans ambiguïté. Ces informations doivent permettre au professionnel de santé de comprendre précisément le cadre de ces relations et au patient d’être correctement informé de leur existence et de leur nature. Elles doivent figurer dans des documents officiels tels que les Conditions Générales d’Utilisation, la politique de confidentialité ou tout autre support contractuel mis à disposition des utilisateurs, et être tenues à jour.

Les exigences IEU 5 et IEPS 6 "Le Système DOIT permettre d'imposer le renouvellement d'un Moyen d'Identification électronique (MIE) à une fréquence paramétrable selon le type de MIE." portent principalement sur le paramétrage d’une fréquence de renouvellement des MIE.

Aucun délai n'étant imposé par la réglementation, il est possible de proposer une fréquence par défaut en adéquation avec le contexte d'intervention de la solution. Il peut ainsi être accepté que la fréquence de renouvellement soit paramétrée dans un délai plus long.

L'exigence IEU 1 : "Le Système DOIT imposer la vérification des attributs d'identité de l'Usager au moment de la création du compte par l'Utilisateur" s'applique pleinement même sans accès aux professionnels de santé.
Lorsqu'il n'y a pas d'accès aux professionnels de santé, il n'y a pas de vérification de l'identité du patient.
Toutefois, il ne s'agit pas d'une vérification de l'identité du patient, mais de la vérification des attributs du patient nécessaires à la création de son moyen d'identification électronique (MIE).
Un processus doit être mis en place dans le but d'inviter le patient à confirmer l'exactitude des attributs renseignés.

Par exemple : Une déclaration de l’exactitude des attributs renseignés (ex : par une case à cocher) ou une étape de validation des attributs renseignés.

De même pour l'exigence IEU 2 :  "Le Système DOIT n'autoriser la modification de ses attributs d'identité par un Usager qu'avec des informations obtenues par une vérification d'identité aussi fiable que lors de l'enregistrement initial". 
Un processus doit être mis en place dans le but d'inviter le patient à confirmer l'exactitude des attributs modifiés.

Par exemple : Une déclaration de l’exactitude des attributs renseignés (ex : par une case à cocher) ou une étape de validation des attributs renseignés.
 

Pour rappel, l'exigence IEU 6 : "Le Système DOIT permettre à un Usager de révoquer l'accès par l'un de ses MIE", comporte 2 scénarios de conformité :

SC1 - Révoquer un MIE sans se connecter au système

Le système doit répondre au scénario de conformité en proposant un moyen de révocation pour chaque MIE mis à disposition, sans se connecter au système.

Exemples (non exhaustif) :

• Si le mot de passe est compromis : proposer un lien "mot de passe oublié" afin de permettre à l'usager de réinitialiser son mot de passe.
• Si le téléphone est perdu : l'usager peut orienter l'envoi de l'OTP sur son email enregistré au préalable. Une fois connecté, il pourra changer le numéro de téléphone.
• Si l'accès à l'email est perdu : l'usager peut orienter l'envoi de l'OTP sur son numéro de téléphone enregistré au préalable. Une fois connecté, il pourra modifier l'adresse email.

Remarque : Ce scénario est applicable par défaut pour chaque MIE. Exception pour les MIE utilisant un service externe ou une fédération d’identité (exemple : FranceConnect), ce scénario n’est pas applicable.

SC2 - Révoquer un second MIE une fois connecté au système

Le système doit répondre au scénario de conformité en proposant un moyen de révocation pour chacun de ses MIE en se connectant par un de ses autres MIE non compromis.

Exemple : 

• Mon système propose l’utilisation de clés FIDO comme MIE, une clé nominale et une clé de secours. Dans le cas de la perte/vol de la clé FIDO à usage nominal, la clé FIDO de secours doit permettre de se connecter et ainsi de révoquer la clé FIDO perdue.

Les scénarios applicables dépendent donc du nombre de MIE proposés par le système :

• Dans le cas où le système ne dispose que d'un seul MIE, seul le scénario 1 est applicable car l'accès au compte devient impossible dès lors que le MIE est compromis.
• Dans le cas où le système dispose d'au moins 2 MIE, les scénarios 1 et 2 sont applicables.
   

En accord avec l’exigence ETH 32 « Le Système DOIT être évalué à l'aune de l'impact environnemental de son utilisation au moyen de la méthode d'écoscore fournie par la DNS et l'ANS », il est attendu de réaliser le calcul de l'écoscore développé par la DNS et mis à disposition sur le site Ecoscore des applications de santé en cliquant sur « Calculer l’écoscore de son service numérique », en vous connectant sur votre compte iSC et en sélectionnant les services de téléconsultation. Pour vous aider au calcul de votre écoscore vous pouvez sollicité l’accompagnement par Greenspector via le Chat.

Evaluation des applications de téléconsultation

L'évaluation des applications de téléconsultation suit la même méthodologie que ce qui a été expliqué précédemment. Il existe cependant certaines adaptations :

• l’application côté patient (ou site web) est testée en parallèle de l’application côté professionnel de santé (ou site web), cela permet d'évaluer une téléconsultation dans des conditions proches de la réalité ; 
• les deux applications (ou les deux sites web) sont évaluées dans les mêmes conditions (en particulier avec la même plateforme matérielle) ; 
• les écoscore des deux applications (ou des deux sites web) sont mesurés indépendamment, un écoscore pour chacune d’elles, selon la méthodologie présentée précédemment ; 
• l'écoscore de la téléconsultation qui est produit est la moyenne des deux écoscore (l'écoscore « côté patient » et l’écoscore « côté professionnel de santé ») ; 
• les métriques de l'étape de téléconsultation sont basées sur une mesure d’une durée de 30 secondes pour une sollicitation raisonnée du banc de mesure. Cependant les indicateurs présentés dans l’analyse des ressources et de l’empreinte environnementale sont ensuite projetés sur une durée de téléconsultation moyenne, à savoir 15 minutes.
   

Si votre chatbot est uniquement destiné à des fonctions d’assistance générale (par exemple, navigation sur le site ou recherche dans la FAQ, se repérer ou résoudre un problème technique) et ne participe en aucune manière au parcours de téléconsultation (aidant à l'établissement d'un diagnostic ou d’une prise en charge thérapeutique), vous n’êtes pas concerné par ces exigences.

Toutefois, il est recommandé, par souci de transparence, de faire mention que le chatbot repose sur un fonctionnement par intelligence artificielle si c’est le cas.
 

L’exigence ETH.01 « Le Système DOIT être intuitif, c’est-à-dire simple d’usage pour tous les publics, facilement compréhensible et ne demandant aucune formation particulière » signifie que le SI de TLC doit être aussi intuitif, simple d’usage et facilement compréhensible pour choisir une TLC sans frais supplémentaires que pour choisir une TLC avec frais pour services optionnels. Les parcours patient doivent être dans les deux cas de simplicité comparable, sans favoriser l'accès aux TLC avec frais optionnels.

Pour évaluer cela, on pourrait comparer les navigations conduisant à un RDV de TLC AVEC et SANS frais optionnels pour le même motif de TLC et aux mêmes horaires, en vérifiant que le nombre de clics nécessaires pour un utilisateur sans formation préalable est identique. Lorsqu'une TLC inclut des frais optionnels, le patient doit en être informé avant la présentation du devis. Il ne doit pas découvrir ces frais non remboursables au dernier moment. Le patient doit pouvoir à tout moment choisir une TLC SANS frais optionnels.

En résumé, il est nécessaire d’évaluer sur un panel représentatif des utilisateurs de la plateforme de TLC que les usagers sont bien en capacité d’une part de prendre facilement un RDV de TLC et d’autre part de choisir au moment de la navigation une TLC SANS frais supplémentaires ou AVEC des frais liés aux services optionnels. Le manque de transparence peut engendrer un manque de confiance. Découvrir le devis au dernier moment peut conduire à un renoncement à la TLC et accentuer les inégalités d'accès aux soins.

"IEPS 8 - Le Système DOIT garantir l'unicité des identifiants de ses utilisateurs"

Scénario - vérification de l'unicité des identifiants utilisateur : 

1. Création d'un compte utilisateur ; 
2. Création d'un second compte utilisateur avec les mêmes traits d'identité utilisateur afin de déclencher une alerte de risque de doublon ; 
3. Afficher à l'utilisateur, l'alerte de risque de doublon »

Il est accepté de fournir une preuve plus adaptée à votre cas d’usage dès lors qu’elle prouve bien que l’unicité des identifiants utilisateurs est garantie.

A titre d’exemple :

Votre solution propose un numéro d’identification spécifique à votre solution.
Vous êtes conforme à l’exigence si l’attribution de ce numéro d’identification est unique à chaque compte.

Pour être conforme à l'exigence ETH.08, il est suffisant que le système offre la possibilité au patient de sélectionner le type de lieu où il se situe lors de la téléconsultation. Cela peut inclure des options comme le domicile, une officine, un EPHAD, ou tout autre lieu approprié. L'exigence ne nécessite pas que le patient fournisse son adresse exacte. L'objectif principal de cette exigence est de garantir que le système permette d'identifier le lieu général de la consultation pour des raisons de traçabilité et de sécurité, sans imposer la saisie d'une adresse précise. 

Par contre, l’exigence ETHT.02 impose que le patient puisse saisir l'adresse précise du lieu de la téléconsultation : « Le Système DOIT afficher une interface de saisie du lieu où se situe le patient (adresse, code postal, géolocalisation, ...)… ».