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

Pour MSSanté, dans le PDF, on utilise la base « code » qui est imposée par le type code et son nom. Pour le DMP, on utilise le « title », qui sera visible des PS et patients. Pour certains documents ce dernier est imposé par le CI-SIS ; pour d’autres c’est à la main de l’utilisateur, idéalement sur proposition du logiciel (et cela correspond à l’exigence du GI DMP).

Effectivement cette étape du scénario ne sera pas prise en compte dans l’étude des preuves.

Le critère voie/rue n’est pas inclus dans les points de contrôle du référencement pour cette exigence.

Pour les éditeurs ne disposant pas de PFI, la vérification de la suppression d’un document se fera à travers la vérification du flux HL7 (identique à la preuve CDA/HL7.02).

Par suppression, on entend l'accès au document qui n'existe plus : ce document n’est pas ou plus accessible à l’utilisateur car il peut avoir été supprimé, masqué, ou que le PS n'est pas habilité.

Dans tous les cas, il faut l’indiquer à l’utilisateur et celui-ci doit toujours avoir la capacité de le supprimer

Le scénario SSI/IAM.92.01 relatif aux preuves de conformité sur la gestion des mots de passe a fait l'objet d'une évolution.

Afin d’harmoniser les exigences sur l’ensemble des couloirs, le scénario modifié s’applique désormais à tous les éditeurs qui candidatent sur les guichets RIS et DRIMBox.

Qu’est-ce qui change concrètement ?

Le scénario précédent pour RIS et DRIMbox prévoyait un blocage du compte après 5 échecs de changement de mot de passe.
Désormais, conformément au scénario harmonisé, il faut :

• Réaliser une tentative de connexion erronée répétée,
• Mettre en évidence le blocage du compte après un nombre d’échecs consécutifs au plus égal à 10 (et non plus après 5 échecs de changement de mot de passe).

Le scénario attendu est le suivant : Scénario de conformité : SSI/IAM.92.01

Vérifier la mise en place d'une politique de mots de passe robuste pour les comptes à privilèges
 

Etapes du scénario :

1. Se connecter avec un compte à privilège dont la durée de validité a été dépassée
2. Mettre en évidence que le système impose à l'utilisateur un changement de son mot de passe
3. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la limite de 15 caractères
4. Mettre en évidence le refus du changement de mot de passe
5. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'une majuscule
6. Mettre en évidence le refus du changement de mot de passe
7. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un chiffre
8. Mettre en évidence le refus du changement de mot de passe
9. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe ne respectant pas la présence d'un caractère spécial
10. Mettre en évidence le refus du changement de mot de passe
11. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe précédemment utilisé
12. Mettre en évidence le refus du changement de mot de passe
13. Effectuer une tentative de changement de mot de passe à l'aide d'un mot de passe satisfaisant l'ensemble des critères
14. Mettre en évidence la réussite du changement de mot de passe
15. Effectuer une tentative de connexion au compte à l'aide d'un mot de passe erroné et répéter l'opération
16. Mettre en évidence le blocage du compte après un nombre défini d'échecs de connexion consécutifs au plus égal à 10
     

Notez que le scénario s’applique immédiatement pour tous les futurs dépôts. Le mécanisme de preuve reste inchangé (Capture vidéo montrant le bon déroulé du scénario de conformité).

Que dois-je faire si mes preuves sont déjà réalisées ou en cours de réalisation ?

• Si vos preuves n’ont pas encore été déposées, appliquez directement le scénario harmonisé.
• Si vos preuves ont déjà été déposées selon l’ancienne version, préparez une mise à jour conforme au nouveau scénario pour répondre aux demandes de modification.

Pour toute question, nous vous invitons à contacter le support Industriels Ségur : Formulaire de contact

Le Code officiel géographique (COG) utilisé est bien issu des fichiers officiels INSEE. Certains cas de tests incluent des communes supprimées pour illustrer des cas réels d’historique administratif. 

Si l’éditeur constitue une base locale des COG, il doit impérativement l’alimenter et la maintenir à jour à partir de l’ensemble des fichiers disponibles sur le site de l’INSEE (communes actuelles, événements, COG complet).

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) => SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

Oui, l'appel contextuel via PSC du web PS DMP doit obligatoirement être implémenté dans le cadre de la vague 2.

Il s'agit de proposer un service d'accès Web-PS à la consultation DMP via deux méthodes techniquement différentes. Il est donc demandé d’implémenter les deux manières.