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

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.

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.

Rappel de l'exigence : Lors de la visualisation d’un document au format HL7 CDA R2, le Système DOIT le rendre lisible par un humain (l'entête et le corps) avec la feuille de style envoyée par le producteur si elle existe, sinon avec la feuille de style du consommateur (un lien pour obtenir une feuille de style d'exemple est fournie dans le scénario).

Scénario - Vérifier la lisibilité par l'utilisateur des données d'un document au format HL7 CDA R2 N1
Prérequis : Un document au format HL7 CDA R2 N1 est reçu par le système.
Etapes du scénario : 

• intégrer un document H7 CDA R2 niv 1 ;
• afficher les données de l'en-tête d'un document au format CDA R2 N1.

Il est recommandé au consommateur de vérifier et de nettoyer la feuille de style du producteur afin de se prémunir des attaques de type injection, Cross Site Scripting, déni de service...etc. Si la feuille de style du producteur présente un quelconque risque de sécurité, le système doit utiliser sa propre feuille de style pour afficher le document.

"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, ...)… ».

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.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.