Depuis le 2 novembre 2026, les données des professionnels de santé ne seront plus accessibles depuis le site https://service.annuaire.sante.fr

Elles sont désormais téléchargeables uniquement depuis le site suivant : https://www.data.gouv.fr/organizations/agence-du-numerique-en-sante/datasets

L'ensemble des preuves à soumettre pour démontrer la conformité à la section MSS doit impérativement provenir de la solution candidate elle-même. Exception faite des preuves MSS.02, MSS.17 & MSS.27 : les lignes de codes peuvent être reprises de l'éditeur de la solution tierce. Les identifiants des traces et des logs (…) produits lors de la validation de la conformité au référentiel socle MSSanté #2 doivent être ceux de la solution candidate au référencement TLC.

L’exigence MSS.02 est la suivante : "Le client de messageries MSSanté du Système DOIT vérifier que le certificat présenté par l’opérateur MSSanté n’est pas expiré, "conformément au référentiel socle MSSanté #2 (Clients de Messageries Sécurisées de Santé) [MSS1]." 

Pour répondre à l’exigence MSS.02, le candidat peut transmettre l’identifiant d’exécution du cas de test réalisé dans le cadre de l’exigence MSS.10.

La version v15 apporte des clarifications et un point de contrôle en moins qui est la vérification antivirus lors de upload de fichier. Selon le cas il est possible :

• soit l'ENS a déjà réalisé le test d’intrusion sur la base d’une version plus ancienne du formulaire alors l'ENS peut poursuivre sur cette base ; il n'est donc pas nécessaire de relancer un audit complet sur le nouveau formulaire. Si l'ENS a une non conformité sur le point de contrôle qui a été retiré de la nouvelle version du formulaire test d'intrusion v15, ce point n'est pas considéré comme bloquant.
• soit l' ENS n'a pas encore réalisé le test d’intrusion et il faut alors obligatoirement partir sur la nouvelle version du formulaire v15.

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.

L’exigence ETH.33 « Le Système DOIT intégrer dans son cycle de vie une démarche globale de développement durable. » concerne la société de TLC au sens large alors que l’exigence ETH.34 « Le Système DOIT mettre en œuvre des pratiques d'écoconception afin de réduire l’impact environnemental du service. » concerne le logiciel.

Au sujet de la démarche globale, il est attendu de prouver l’engagement de la société dans sa préoccupation au sujet de l’impact environnemental du numérique de la TLC. Vous devez démontrer une démarche d’évaluation, par exemple avoir un écolabel par un organisme indépendant, faire une autoévaluation, fournir un rapport annuel RSE avec description des activités, transmettre le pourcentage de salariés formés à l’écoconception. 

L’écoconception concerne la façon de coder le SI. 

Dans les deux cas, l’objectif est de réduire votre impact environnemental.

On entend par "correspondant" tout professionnel de santé avec lequel un utilisateur de la solution est susceptible d’interagir. L’utilisateur de la solution se distingue du correspondant par le fait d’avoir un accès à la solution (via une authentification PS avec un MIE, PSC, etc…), contrairement au correspondant.

Pour qu'une solution soit intégralement conforme au référentiel ANN, la création de fiche correspondant doit être effectuée dans l'application à chaque fois qu'un PS est mentionné par un utilisateur, dans un dossier patient ou ailleurs, ou consulté via l'envoi de documents ou d'informations.

Les informations obligatoires du correspondant et la fréquence de rafraichissement de ces informations sont les mêmes que pour l'utilisateur.

Pour rappel l’exigence ETH.29.1 est la suivante : « Le Système DOIT être développé en Responsive Web Design (RWD) permettant une adaptation automatique de l’affichage à la taille de l’écran du terminal qui le lit [...] ».

Le Responsive Web Design (RWD) doit permettre une adaptation automatique de l'affichage à la taille de l'écran du terminal qui le lit à la fois pour le patient mais aussi pour le professionnel médical. Si une charte impose l'utilisation d'un dispositif spécifique pour le professionnel médical, l'affichage doit être optimisé pour ce dernier. Il n'est pas imposé d'optimiser l'affichage automatique de l'écran pour les autres dispositifs.

Ces preuves avaient été mises en place dans le cadre d'une certification pour le 31/12/2023. Elles n'ont plus lieu d'être. Pour rappel, pour être conforme aux exigences pentest, il faut :

• qu’il n’y ait plus aucune non-conformité pour les points de contrôle de gravité haute,
• qu’il y ait moins de 10 non-conformités pour les points de contrôle de gravité moyenne. 

Dans ce cas, pas besoin de lettre d'engagement à effectuer les démarches correctives.

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.

Dans le cadre de l'exigence ETH.24.1 « SI les données recueillies au cours de la téléconsultation sont traitées pour servir une finalité secondaire, ALORS les données DOIVENT être traitées de façon à ne pas permettre la réidentification directe des patients ? », il est conseillé de suivre les règles de la CNIL auquel cas, il est attendu de votre système, une démonstration de sa performance à anonymiser / pseudonymiser. (échantillonnage, process d’évaluation et de qualification par exemple : score d’anonymisation). Il est recommandé de spécifier le processus de pseudomysation, de produire l’attestation du DPO, …

Dans le cas où les données sont anonymisées, il doit être impossible de réidentifier l'usager. Si les données sont pseudonymisées, la réidentification de l’usager est directement impossible, mais indirectement possible.

Vous pouvez consulter les procédés proposés par le CNIL sur leur site.

Dans le cas du critère ETH.11.1.2 « En cas de réutilisation des données issues de la téléconsultation, le Système DOIT mettre en œuvre des mécanismes permettant de garantir que les patients ont été informés de la réutilisation de leurs données pour servir des finalités secondaires, de la finalité poursuivie, de l’identité du responsable de traitement (si différent du SI de téléconsultation), et des droits RGPD des personnes, qu'ils l'ont bien compris et qu’ils y consentent », une finalité secondaire est la finalité d'un traitement qui ne sert pas directement le soin du patient.

Cela peut être par exemple d’améliorer le service, de servir la recherche, la commercialisation des données ou des résultats d’analyse des données, l’utilisation des données pour alimenter les statistiques propres à l’éditeur, etc.

Cette définition est valable également pour ETH.12 et ETH.30 

• ETH.12 : « Le Système DOIT mettre en œuvre des mécanismes permettant de distinguer le type des finalités secondaires en faisant la différence entre les finalités secondaires non essentielles servant notamment l’intérêt général et les finalités secondaires non essentielles servant un intérêt particulier, afin de permettre un consentement "à la carte" » (par ex., pouvoir consentir au traitement des données à des visées de recherche et ne pas consentir au traitement servant la production de statistiques d’usage à destination de l’éditeur).
• ETH.30 : « Le Système DOIT permettre aux patients de ne pas consentir au traitement de leurs données pour servir une finalité secondaire sans qu’il n’y ait de dégradation du service rendu par le STLC ou d’impact sur la qualité de leur prise en charge. »

On appelle Système d'Intelligence Artificielle (SIA) un logiciel, développé à l'aide d'une ou de plusieurs des techniques et approches énumérées ci-dessous, capable de calculer à partir d’éléments reçus en entrée des résultats représentant des prédictions, des recommandations ou des propositions de décisions susceptibles d'influencer des environnements, physiques ou virtuels, avec lesquels le SIA interagit. Les différents systèmes d'IA varient en fonction de leur niveau d'autonomie et de leur capacité d'adaptation après leur déploiement.

Les techniques et approches considérées sont les suivantes :

• les approches d'apprentissage automatique (AAA) encore appelé apprentissage machine, notamment les apprentissages supervisés, non supervisé ou par renforcement, pouvant utiliser une grande variété de techniques, y compris l'apprentissage profond. Les systèmes d’IA générative utilisent ce type d’approche et s'appuient sur des réseaux neuronaux numériques profonds pour générer leurs résultats. Les AAA permettent aux SIA d’identifier des motifs, des structures, ou des relations dans les données puis de les utiliser pour produire un résultat.
• les approches logiques et fondées sur les connaissances, intégrant le raisonnement (symbolique), les bases de connaissances, les moteurs d'inférence notamment déductifs, la programmation inductive (logique) et les systèmes experts.
• Les approches statistiques, l'estimation bayésienne, les méthodes de recherche et d'optimisation.

L'exigence ETH.17.1 « SI le Système intègre une intelligence artificielle, que ce soit pour l'aide à la décision du professionnel médical ou un chatbot interagissant avec le patient ALORS le Système DOIT informer les utilisateurs (professionnels médicaux et/ou patients) qu'ils interagissent avec une solution d'intelligence artificielle, s’assurer de leur bonne compréhension, et recueillir leur consentement. » s'applique uniquement aux solutions de téléconsultation intégrant une intelligence artificielle au cours du parcours de téléconsultation. Cette exigence est donc considérée "Non applicable" pour une solution de téléconsultation qui n’intègre pas d’intelligence artificielle, ou qui intègre une intelligence artificielle en dehors de la téléconsultation (par ex., chatbot répondant aux questions en rapport avec l’utilisation du SI de téléconsultation). Dans ce cas, une déclaration sur l'honneur justifiée, datée et signée par le responsable légal de l'entreprise, devra être fournie en preuve.

Il en est de même pour l'exigence ETH.18.1 « SI le Système met en œuvre un traitement algorithmique des données issues de la téléconsultation intégrant une intelligence artificielle ALORS le Système DOIT documenter et rendre consultable par tous, le niveau de performance et les biais algorithmiques de la solution d'intelligence artificielle. »

L'exigence ETH.11.1.2 précise qu' « en cas de réutilisation des données issues de la téléconsultation, le Système DOIT mettre en œuvre des mécanismes permettant de garantir que les patients ont été informés de la réutilisation de leurs données pour servir des finalités secondaires, de la finalité poursuivie, de l’identité du responsable de traitement (si différent du SI de téléconsultation), et des droits RGPD des personnes, qu'ils l'ont bien compris et qu’ils y consentent ». L'analyse d’un panel de patients (idéalement une trentaine, et au moins 10) pourrait répondre à l'exigence, à condition que ce soit un panel représentatif de la population d’usagers ciblées par la téléconsultation (en termes par exemple d'âge, de sexe, de handicap, de niveau de littératie, de catégorie socio professionnelle…).

La réponse ci-dessous est aussi valable pour l’ETH.12 et ETH.30.

Pour rappel l’exigence ETH.11.1.2 est la suivante : « En cas de réutilisation des données issues de la téléconsultation, le Système DOIT mettre en œuvre des mécanismes permettant de garantir que les patients ont été informés de la réutilisation de leurs données pour servir des finalités secondaires, de la finalité poursuivie, de l’identité du responsable de traitement (si différent du SI de téléconsultation), et des droits RGPD des personnes, qu'ils l'ont bien compris et qu’ils y consentent. » Le consentement au recueil des données de la téléconsultation et au traitement de ces données en rapport avec la prise en charge du patient est inclus dans le consentement à la téléconsultation. Le traitement des données servant une finalité secondaire nécessitera autant de consentements que de finalités secondaires. (consentement à la carte, la dissociation des finalités secondaires est donc requis). 

Par exemple dans le cas particulier de la recherche, il peut y avoir plusieurs recherches et dans ce cas, si la Sté de TLC a obtenu une autorisation générique recherche, un seul consentement au traitement des données pour la recherche suffira en plus du consentement à la téléconsultation qui lui sera obtenu à chaque téléconsultation. Si la Sté de TLC n’a pas obtenu d’autorisation générique recherche, il faudra autant de consentements que de finalités de recherche, en plus du consentement à la téléconsultation, à chaque téléconsultation. 

Si les données sont anonymisées, elles ne sont pas réidentifiantes et elles perdent leur statut de données à caractère personnel. Dans ce cas, la réutilisation secondaire des données anonymisées est possible après une simple information du patient. Néanmoins, l’éditeur doit se donner les moyens de vérifier que cette information a bien été comprise par les patients. 

Au contraire, si les données sont pseudonymisées (une réidentification du patient est possible), le RGPD est applicable, et d'un point de vue éthique, il est attendu que l'éditeur recueille le consentement du patient pour chaque type de réutilisation secondaire des données et qu’il s’assure de la bonne compréhension par le patient des informations qui lui sont fournies, condition d’un consentement éclairé. Aussi, il est nécessaire de savoir si les données sont anonymisées ou seulement pseudonymisées.