Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

L'exigence IEPS.08 "SI le Système propose son propre dispositif d'authentification ET SI il autorise une identification électronique à un seul facteur succédant à une identification électronique à deux facteurs, ALORS le Système DOIT imposer un délai maximal paramétrable entre ces deux identifications électroniques et vérifier que le simple facteur utilisé fait partie du dispositif d'authentification à deux facteurs utilisé initialement." est considérée "Non Applicable" dans le cas où votre système propose exclusivement l'authentification à deux facteurs (2FA). 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. Cette déclaration doit préciser que le système ne permet à aucun moment l’utilisation d’un seul facteur d’authentification après une authentification à deux facteurs.

L'expression fait référence aux cas où le système intègre un mécanisme d'authentification interne propre à la plateforme permettant aux utilisateurs professionnels de santé de s’identifier (exemple : identification par login / mot de passe). Dans ce cas, les exigences IEPS 05, IEPS 06 et IEPS 08 sont applicables. 

Si l’éditeur ne gère pas lui-même l’authentification et utilise uniquement un service externe ou une fédération d’identité (exemples : Pro Santé Connect, FranceConnect…), alors le système ne met pas en œuvre son "propre dispositif d’authentification". Dans ce cas, les exigences IEPS.05, IEPS.06 et IEPS.08 sont "Non Applicables". 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.

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.

Il est nécessaire de :

• préciser les standards d'authentification sécurisés utilisés pour l'authentification des utilisateurs (exemple : OAuth2, SAML etc.…) ; 
• préciser les mécanismes mis en place pour authentifier les parties communicantes (exemple : certificats numériques x.509) ; 
• préciser les noms et les versions des protocoles de communication utilisés pour la transmission des flux vidéo (webRTC, RTP etc.…) et les mécanismes de protection de ces protocoles le cas échéant ; 
• préciser les mécanismes mis en place pour assurer l'intégrité des données transmises (algorithmes SHA-256, HMAC etc.…) ; 
• éventuellement, fournir un schéma d'architecture montrant comment les flux vidéo sont protégés de bout en bout, pour appuyer les éléments précédents ; 
• préciser les protocoles ne pouvant être chiffrés, le cas échéant.

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.

Cela n'est pas nécessaire. Un compteur global est acceptable, à condition que le détail par type soit accessible (au clic, survol, ou autre interaction).

• Contexte
  Les exigences SC.CDA/DD.22 et LGC.MDV.04 visent à vérifier la capacité du système à produire des documents structurés au format CDA R2 N3, conformément aux volets de contenu du CI-SIS :
  Les scénarios associés décrivent les étapes de saisie des données et de génération des documents.

   

• Problématique commune
  Dans les scénarios initiaux, certaines étapes pouvaient laisser entendre que la saisie des données devait être réalisée directement dans un document ouvert, ce qui revient à imposer un choix ergonomique aux éditeurs. Or, les LPS peuvent proposer différents parcours utilisateurs, par exemple :

  • saisie des données directement dans un document,
  • saisie des données dans le dossier patient, puis génération du document a posteriori,
  • toute autre ergonomie équivalente.

  Ces choix relèvent de l’implémentation et ne doivent pas être contraints par le scénario de conformité.

   

• Principe de clarification commun
  Pour SC.CDA/DD.22 et LGC.MDV.04, l’exigence porte exclusivement sur la capacité du système à produire un document CDA R2 N3 conforme au volet CI-SIS concerné, indépendamment de la manière dont les données ont été saisies.
  La saisie des données peut donc être effectuée :
  soit directement dans le document, soit en amont dans le LPS, avant la génération du document.
  Les deux approches sont conformes dès lors que le document généré respecte le volet CI-SIS applicable.

   

• Simplification de Scénarios 
   

  SC.CDA/DD.22.01 – Mesures de l’enfant
  Scénario :
  Vérifier que le système est capable de produire le document « Mesures de l’enfant » en CDA R2 N3, conformément au volet de contenu CSE-MDE [CI-SIS].
  Étapes :
  1.    Saisir les mesures de l’enfant
  2.    Générer le document « Mesures de l’enfant » au format CDA R2 N3, conformément au volet de contenu CI-SIS
   

  LGC.MDV.04.01.01 – Synthèse médicale
  Scénario :
  Vérifier que le système est capable de produire une synthèse médicale en CDA R2 N3, conformément au volet [CISIS16] du CI-SIS.
  Étapes :
  1.    Saisir les données d’une synthèse médicale
  2.    Générer le document « Synthèse médicale » au format CDA R2 N3, conformément au volet [CISIS16] du CI-SIS

   

• Conséquence pour les éditeurs
  Les éditeurs : 
  • NE SONT PAS TENUS d’implémenter une saisie directement dans un document ouvert,
  • PEUVENT librement définir le parcours de saisie le plus adapté à leur ergonomie,
  • DOIVENT garantir que le document généré est conforme au format CDA R2 N3 et au volet CI-SIS applicable.
    Cette clarification vise à harmoniser l’interprétation des scénarios et à éviter toute contrainte ergonomique non justifiée.
     

Le scénario LGC.DMP/UX.10.01 décrit une consultation type incluant la qualification de l’INS à partir des informations issues de l’Application Carte Vitale (ApCV), ainsi que la production et la diffusion d’une ordonnance (ON, DMP, MSSanté).
Les prérequis du scénario mentionnent actuellement un patient dont l’INS doit être qualifiée, ce qui entre en contradiction avec les étapes du scénario.

Le prérequis suivant pose problème "Patient test … " or, les étapes du scénario prévoient explicitement la recherche et la qualification de l’INS sur la base des informations issues de l’ApCV.

Exiger une INS déjà qualifiée en prérequis rend donc cette étape inutile, voire incohérente, et n’est pas compatible avec les usages attendus de la qualification de l’INS via l’Application Carte Vitale.

Dans le nouveau scénario, la mention "dont l’INS doit être qualifiée" est supprimée.

Le scénario est le suivant : 

• Prérequis :
  • Patient test :
    • disposant d'un DMP avec au moins un document
    • disposant d'un dossier local dans le logiciel avec au moins 1 document différent de celui du DMP
    • qui n'a pas bloqué l'utilisateur test
      • Utilisateur identifié via Pro Santé Connect
      • Interface réseau bridée avec une latence de 3 secondes

• Etapes du scénario :

  Utilisation du logiciel pour une consultation type :

  • Recherche et qualification de l'INS sur la base des informations issues de l'ApCV
  • Production d'une ordonnance
  • Envoi de l'ordonnance au service ON
  • Obtention du QR Code
  • Envoi de l'ordonnance dans le DMP
  • Envoi de l'ordonnance au patient via MSSanté

A minima, les requêtes aux services numériques INS et ON doivent faire l'objet d'un élément visuel permettant à l'utilisateur d'apprécier le statut de la requête (en cours, échec, réussi).

L'interface ne doit pas être bloquée par une requête en cours vers un service numérique (ie l'utilisateur doit pouvoir continuer d'utiliser l'interface graphique du logiciel sans être bloqué)

Jeu(x) de test CNDA à utiliser :
143110095083713 - CLÉRICO Côme
167100093480710 – BOUCHER François
 

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 

Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour :

• Scénario - Accusé de réception par l'opérateur destinataire
• Etapes :
  1. Préparer un courriel.
  2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
  3. Envoyer le message.
• Preuves :
  • Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
  • Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.
     

L’exigence SC.MSS/va1.15 telle que définie historiquement dans le référentiel client de messagerie MSSanté est erronée depuis sa publication. Elle décrit un mécanisme d’accusé de réception non conforme aux normes RFC. Cette anomalie est présente dans les référentiels de la vague 1 et reprise dans certains REM de la vague 2. Sur le terrain, les éditeurs ont majoritairement implémenté les accusés de réception conformément à la norme RFC.

L’exigence SC.MSS/va1.15 évolue pour s'aligner sur le mécanisme DSN normalisé afin de garantir la bonne émission et réception des accusés de réception par les solutions MSSanté.

La nouvelle version de l'exigences est la suivante : 
Le système DOIT permettre de demander un accusé de réception de type DSN lors de l'émission d'un courrier. Lors de l'envoi du message, le paramètre NOTIFY doit être positionné avec les valeurs SUCCESS,FAILURE,DELAY dans la commande SMTP "RCPT TO:"
Le mécanisme DSN est décrit dans la RFC 3461.
Exemple : RCPT TO: <adresse email> NOTIFY=SUCCESS,FAILURE,DELAY

Les nouveaux scénarios et preuves sont également mis à jour : 

Scénario - Accusé de réception par l'opérateur destinataire
Etapes :

1. Préparer un courriel.
2. Choisir l'option qui permet d'avoir un accusé de réception de type DSN.
3. Envoyer le message.

Preuves : 

• Preuve 1 : Produire des copies d’écran : du courriel envoyé afin de valider la preuve.
• Preuve 2 : Produire des copies d’écran : de l’accusé de réception reçu suite à l’envoi du courriel émis.