FAQ de l'offre : Ségur du numérique en santé

1. Quel est le changement principal ?

   Avant : Tout système proposant un mot de passe comme facteur unique d’authentification devait limiter le nombre de tentatives d’accès et appliquer des critères de construction assurant un niveau suffisamment élevé de complexité des mots de passe des PS.

   Maintenant : Cette exigence s'applique uniquement à un système configuré avec la base de compte locale. Lorsque le système ne dispose d’aucune fonctionnalité de gestion de comptes utilisateurs locaux (création, stockage ou vérification de mots de passe) et que l’authentification est entièrement déléguée à un fournisseur d’identité externe (exemple : AD), l’exigence SC.SSI/IE.36 est non applicable.

   Ce changement est lié au fait que la rédaction initiale de l’exigence ne prenait pas en compte des cas d’usage remontés durant la procédure de référencement.

    

2. Concrètement, qu'est-ce que ça implique ? 

   L'éditeur peut déposer un justificatif expliquant les particularités de développement de l’application et indiquant qu’il n’existe aucune fonctionnalité de base locale de comptes.

    

3. Quelles obligations pour l’éditeur ?

   Aucune, il s’agit d’une prise en compte de cas d’usage existants.

    

Annexe – Nouvelles versions exigences, scénarios et preuves

Nouvelle version de l’exigence SC.SSI/IE.36

LORSQUE le système propose un mot de passe comme facteur unique d'authentification, ALORS le système DOIT : 

• permettre d'implémenter les mesures de restriction d’accès et de vérification de complexité des mots de passe prévues par le Référentiel d'identification électronique (volet ASPP) ;
• être conforme à ces exigences dans sa configuration par défaut.

NB : les administrateurs techniques ou métier ne sont pas concernés par cette exigence

Le système peut généralement se baser :

• soit sur une base de compte locale
• soit sur un annuaire (exemple AD)

Cette exigence s'applique à un système configuré avec la base de compte locale.

Nouveau scénario associé à l’exigence SC.SSI/IAM.36

SC.SSI/IE.36.01 :

Vérifier que le système limite le nombre de tentatives d'accès par mot de passe.

Etapes du scénario :

1. Demander l'ouverture d'une connexion par mot de passe en tant que PS sur un compte valide
2. Entrer un mot de passe incorrect plusieurs fois consécutives
3. Montrer que le système empêche de réaliser un nombre illimité de tentatives (temporisations, blocage préventif du compte...) ou qu'il requiert la complétion d'un captcha à chaque authentification

SC.SSI/IE.36.02 :

Vérifier que le système applique les critères de construction du mot de passe du compte du PS.

Etapes du scénario :

1. Demander la modification ou la création du mot de passe d’un compte de PS   
2. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de majuscules
3. Montrer que le système refuse ce mot de passe
4. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de chiffres
5. Montrer que le système refuse ce mot de passe
6. Entrer un mot de passe de 8 caractères composé uniquement de minuscules et de caractères spéciaux
7. Montrer que le système refuse ce mot de passe
8. Entrer un mot de passe composé de 14 chiffres uniquement
9. Montrer que le système refuse ce mot de passe

Dans le cadre d'une consultation de l'environnement DMP, il est attendu que la fonction consommatrice associée à la solution DRIMBox soit en mesure de télécharger (au sens de récupérer) un ou plusieurs documents de santé.

Il peut s'agir de comptes-rendus d'imagerie, suite à une demande de visualisation de ceux-ci par l'utilisateur, ou bien de documents KOS, afin d'afficher l'intégralité des métadonnées associées à un examen d'imagerie. 

Cette action, réalisée par la solution DRIMBox, se retrouve au sein du contenu de l'exigence : "accès locaux aux documents qu'il stocke (y compris de manière temporaire)".

Par conséquent, aussi bien l'exigence, que le scénario et les preuves de test associées s'appliquent dans le cadre de l'homologation d'une solution DRIMBox.

Les captures et logs demandés en éléments de preuve doivent permettre d'attester que les accès locaux aux documents KOS récupérés sont bien tracés et que ces éléments peuvent faire l'objet d'une extraction. 

Dans le cadre de l'utilisation de l'outillage associé à la session de test Homologation SEGUR vague 2 DRIM-M, l'opérateur peut être amené à constater des résultats d'exécution contraires à ce qui est attendu. 

Par exemple, dans le cas où un résultat de validation "Failed" est obtenu à l'issue d'un processus impliquant un ou plusieurs fichiers entrants à priori passants.

Si cette situation est rencontrée par l'opérateur et que celui-ci estime que l'écart entre le résultat d'exécution obtenu et celui attendu n'est pas de son fait (dysfonctionnement de l’outillage de test, incohérence d'un scénario, ou autre), le lien permanent correspondant à l'exécution de l'outil peut tout de même être transmis dans le cadre du déroulement des scénarios associés à la session de test Homologation SEGUR vague 2 DRIM-M. 

Le moniteur analysera alors la situation afin d'estimer la suite à donner et une discussion entre l'opérateur et le moniteur pourra se mettre en place si nécessaire.

Dans le cadre d'une solution logicielle DRIMBox, les trois éléments relevés ne sont effectivement pas véhiculés au sein de la requête d'appel contextuel émise par le RIS/DPI. Cela correspond à un arbitrage historique pris dans le cadre des travaux menés au sein du projet DRIM-M.

Cependant, il est à noter que le "workflow de démarrage" de la fonction consommatrice associé à la solution DRIMBox a été défini en tenant compte de cet aspect, pour rappel :
 

1. Mise en oeuvre d'une transaction d'appel contextuel, initiée par le RIS/DPI à destination de la fonction consommatrice DRIMBox.
2. Authentification de l'utilisateur via PSC (peut être transparente selon le cas de figure).
3. Interaction TD3.1 entre la DRIMBox et le DMP permettant de récupérer les métadonnées XDS associées aux documents publiés sur le DMP. Cela s'applique implicitement en considérant l'exigence DB.CO.54 mentionnée au sein de la spécification projet DRIMBox.
4. Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.

Au sein du workflow présenté ci-dessus, l'étape n°3 permet notamment de traiter la récupération des traits INS stricts du patient. En effet, les métadonnées "sourcePatientId" et "sourcePatientInfo" mentionnent l'intégralité des traits INS requis pour l'affichage au sein de l'interface DRIMBox (certains étant redondants avec les éléments mentionnés dans la requête d'appel contextuel). Cette transaction étant réalisée en amont de l'ouverture de l'interface utilisateur, l'ensemble des traits INS du patient pourront y figurer.

Il est à noter que la spécification projet DRIMBox (section 4.6.1) définit la requête d'appel contextuel "nominale" applicable dans le cadre du processus d'homologation SEGUR vague 2 DRIM-M. Suite à cette étape, lors du déploiement de solutions DRIMBox en production, il est tout à fait envisageable d'étendre les requêtes d'appel contextuel générées par la DRIMBox en y ajoutant un ou plusieurs headers répondant à un contexte ou une architecture donnée. 

En revanche, le contenu de la requête d'appel contextuel ne pourra être réduit (au sens de suppression de certains headers définis en section 4.6.1 de la spécification projet DRIMBox) entre les phases d'homologation et de production.

Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.

À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié. 

Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur vague 2.

Oui, l’API FHIR de l’Annuaire Santé est prévue pour être interrogée à la demande lors de la rédaction du mail.

Aucun champ supplémentaire n’est exigé.
Vous pouvez toutefois proposer des critères additionnels, mais ceux cités dans l’exigence doivent être présents à minima.

L’interface doit obligatoirement proposer tous les critères suivants : RPPS, nom d’exercice, prénom d’exercice, profession, spécialité, raison sociale, voie/rue, code postal, ville, adresse email MSSanté.

Le corpus documentaire associé au projet DRIM-M comporte deux éléments définissant l'affichage de l'intégralité des traits stricts INS au sein de l'interface DRIMBox consommatrice : l'exigence INS/va1.36 issue du REM DRIM-M ainsi que la section 4.6.2 de la spécification projet DRIMBox.

Ainsi, l'utilisateur doit être en mesure de consulter les données d'identification patient suivantes au démarrage de la DRIMBox :

• Nom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Premier prénom de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Date de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Sexe : affichage par défaut au lancement de l'interface utilisateur.
• Lieu de naissance : affichage par défaut au lancement de l'interface utilisateur.
• Matricule INS : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nature du matricule INS (OID) : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Liste des prénoms de naissance : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Prénom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)
• Nom utilisé : affichage possible via paramétrage de l'utilisateur. (existence du champ obligatoire)

En considérant le workflow global de consultation de données de santé associé à la fonction consommatrice DRIMBox, deux flux permettent à cette dernière d'avoir connaissance de l'intégralité des traits stricts INS du patient ciblé :

• Transaction d'appel contextuel initiée par un système LPS à destination de la solution DRIMBox (Cf. section 4.6.1 de la spécification projet DRIMBox). Dans le cadre de cette interaction, le LPS transmet les traits INS suivants à la solution DRIMBox : Nom de naissance ; Premier prénom de naissance ; Date de naissance ; Sexe ; Lieu de naissance ; Matricule INS ; Nature du matricule INS (OID).
• Transaction TD3.1 initiée par la solution DRIMBox vers l'environnement DMP afin de récupérer les lots de soumission associés aux documents publiés sur ce dernier. Suite à cette interaction, la solution DRIMBox récupère l'intégralité des traits INS associés au patient ciblé (au travers des métadonnées "sourcePatientId" et "sourcePatientInfo").

Ainsi, parmi l'exhaustivité des traits stricts INS, trois d'entre eux ne peuvent être connus de la fonction consommatrice DRIMBox qu'à la suite d'une transaction TD3.1 vers le DMP : Liste des prénoms de naissance ; Prénom utilisé ; Nom utilisé.

Par conséquent, le workflow associé au lancement de la fonction consommatrice DRIMBox a été défini afin de tenir compte de ces aspects, pour rappel :

1. Mise en oeuvre d'une transaction d'appel contextuel, initiée par un système LPS à destination de la fonction consommatrice DRIMBox.
2. Authentification de l'utilisateur via ProSantéConnect.
3. Interaction TD3.1 entre la solution DRIMBox et l'environnement DMP permettant de récupérer les métadonnées XDS associées aux documents d'intérêt publiés sur le DMP.
4. Ouverture de l'interface DRIMBox (fonction consommatrice) présentant les résultats de la transaction TD3.1.

Au sein du workflow présenté ci-dessus, la combinaison entre les étapes n°1 et n°3 implique que l'intégralité des traits stricts INS du patient soient connus de la solution DRIMBox au démarrage de son interface.

Cette exigence a pu donner lieu à des interprétations différentes quant à son périmètre d’application, notamment en ce qui concerne le moment d’affichage et le niveau auquel la confirmation « j’ai compris » doit être demandée.

Cette confirmation est destinée à l’utilisateur (professionnel de santé) et doit être affichée à la première connexion, puis de manière périodique selon une fréquence paramétrable (par exemple tous les 180 jours). Elle n’a pas vocation à être affichée au niveau du patient ou du dossier patient.

• Quel est l’objectif de l’exigence ?

L’exigence SC.DMP/CONF.21 impose que le système informe chaque professionnel de santé (PS) que son RPPS est utilisé pour la traçabilité nationale et pour le contrôle d’accès au DMP/MES. L’objectif est d’assurer la transparence et de sensibiliser les utilisateurs au bon usage du DMP.

• Quelle information doit obligatoirement être affichée ?

Deux textes doivent apparaître :

• Texte d’information générale :
  « Le logiciel peut effectuer des requêtes de recherche de document au nom de l'utilisateur sur les DMP/MES et permet d'en consulter, sur action manuelle, les documents d'intérêt. Ces interactions sont tracées avec l'identifiant national de l'utilisateur et le patient est notifié de ces interactions. »
• Texte du bouton « j’ai compris » :
  « Toute consultation de ma part d'un DMP/MES pour lequel le patient (ou son représentant légal) n'a pas donné son consentement m'expose à des poursuites. »
   
• À quelle fréquence cette information doit-elle être affichée ?

À la première connexion de l’utilisateur après la mise à jour Ségur, puis à intervalle régulier paramétrable (valeur par défaut : 180 jours).

• Cette demande concerne-t-elle chaque patient ?

Non. Le clic « j’ai compris » ne doit pas être demandé pour chaque patient. La validation est réalisée une seule fois par utilisateur, à la fréquence programmée.

• Obligations pour l’éditeur
  • Afficher le texte obligatoire sans modification
  • Garantir une fréquence paramétrable (défaut : 180 jours)
  • Affichage une seule fois par utilisateur, pas par patient