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

1. Problématique
La preuve demandée pour l’exigence INS/va1.53 n’est pas adaptée pour le REM LGC, car elle repose sur la fourniture d’un flux HL7 v2, ce qui a du sens dans un contexte hospitalier.
 

2. Objectif de l’exigence
Vérifier la non transmission sous format informatisé du matricule INS et de son OID lorsque l’identité du patient n’est pas qualifiée.
Nous complétons le scénario et les preuves avec la possibilité d’utiliser une arche IHE_XDM
 

3. Scénario applicable
Objectif : Vérifier la non-utilisation du matricule INS (et de l’OID) pour une identité non qualifiée.

Étapes :

1. Disposer d’une identité au statut « identité récupérée ».
2. Produire un document de santé destiné à un échange informatisé ou un message d’interopérabilité IHE PAM contenant une INS non qualifiée.
3. Vérifier que le matricule INS et l’OID ne sont pas utilisés pour référencer le document ou le message.

4. Preuves attendues

Preuve 1 : Démonstration (capture d’écran, vidéo, etc.) montrant l’identité (et son statut) et la donnée de santé produite.

Preuve 2 : Mise à disposition d’une archive IHE_XDM contenant le document de santé ou un message IHE PAM avec une INS non qualifiée.
 

1. Quel est le changement ?
Dans le cadre de l’exigence SC.MSS/UX.01, l’étape 3 du scénario doit être supprimée pour les RIS. Cette étape indiquait la création automatique d’un flux HL7 vers le DPI après dézippage de l’archive.
 

2. Pourquoi cette étape est-elle supprimée ?
L’exigence SC.MSS/UX.01 porte uniquement sur la capacité du système à identifier les courriels MSSanté contenant une archive IHE XDM. La création d’un flux HL7 ne fait pas partie du périmètre attendu et ne doit pas être prise en compte lors des vérifications de preuves.
 

3. Consignes pour les éditeurs et les vérifications
• Ne pas présenter de preuve liée à la création d’un flux HL7 vers le DPI.
• Les preuves doivent uniquement démontrer l’identification des courriels MSSanté contenant une archive IHE XDM.
 

4. Rappel du scénario applicable (sans l’étape 3)
Prérequis :
Un message contenant une archive zip au format IHE XDM en pièce jointe a été reçu.

Objectif :
Vérifier qu’il est possible d’identifier les courriels reçus via MSSanté avec archive zip au format IHE XDM en pièce jointe.

Étapes du scénario :
1. Montrer le respect du prérequis : réception d’un message MSSanté avec archive IHE XDM.
2. Montrer comment le système identifie les courriels reçus via MSSanté contenant une archive IHE XDM en pièce jointe.
 

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

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

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

La dernière version de ce document est disponible sur la page dédiée du dispositif concerné ainsi que via son lien de téléchargement direct : 

La date de la version publiée est par ailleurs indiquée sur le lien de téléchargement du document.

Pour votre information, voici un historique des versions publiées : 

Les liens sont disponibles pour téléchargement sur Convergence dans les éditos associés aux scénarios IA.83.01 et IAM.80.01

Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.