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

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 : 

1. Quel est le changement principal ?

Avant : le système devait informer uniquement si un document avait une nouvelle version ou avait été supprimé du DMP.
Maintenant : le système doit informer si un document a une nouvelle version ou s’il n’est plus accessible (supprimé, masqué, non habilité).
Ce changement est lié au fait que le DMP ne renvoie pas toujours explicitement l’information « supprimé ».

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

• Nouvelle version : informer, permettre la visualisation et l’intégration, en gardant les anciennes versions.
• Non accessible : informer, proposer la suppression dans le dossier patient, uniquement sur action de l’utilisateur.

3. Quand la vérification est-elle faite ?

À l’ouverture du dossier patient (pas en continu).

4. Quelles obligations pour l’éditeur ?

Développements et tests obligatoires avant l’homologation DMP Compatibilité (CNDA).

Annexe – Nouvelle version exigence, scénarios et preuves

Nouvelle version de l’exigence

CDA.DD.05 : Lorsque l'utilisateur accède au dossier du patient, ALORS sans action supplémentaire de sa part et sans bloquer l'interface utilisateur, pour un document déjà intégré dans le dossier du patient depuis le DMP, le système DOIT l'informer :
* qu'il existe une version plus récente de ce document dans le DMP et le cas échéant permettre à l'utilisateur de visualiser cette nouvelle version et de l'intégrer au dossier du patient en conservant les versions antérieures
ou
* que ce document n’est pas ou plus accessible à l’utilisateur (supprimé, masqué, non habilité) et le cas échéant permettre à l'utilisateur de supprimer ce document dans le dossier du patient.

Nouveau scénario – cas de mise à jour du document

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été mis à jour dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système informe l’utilisateur que le document a été mis à jour du DMP, et lui propose de visualiser la nouvelle version du document ainsi que de l’intégrer dans le dossier patient, la version antérieure étant toujours accessible de l’utilisateur au sein du dossier patient.

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système.
2. Accéder à un dossier patient : le système informe l’utilisateur que le document a été mis à jour du DMP.
3. Montrer que le système propose à l'utilisateur de visualiser le document dans le dossier du patient.
4. Confirmer l’intégration du document dans le dossier du patient.
5. Montrer/vérifier que le document existe toujours dans sa version antérieure.

Nouveau scénario – cas où le document n’est plus accessible

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été supprimé dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système indique à l’utilisateur (à côté du document) que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système et que le document a été supprimé dans le DMP du patient.
2. Accéder au dossier patient : le système indique à l’utilisateur que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).
3. Sur la demande de l'utilisateur, montrer la suppression du document dans le dossier du patient.

1. Quel est le changement principal ?

Avant : le système devait informer uniquement si un document avait une nouvelle version ou avait été supprimé du DMP.
Maintenant : le système doit informer si un document a une nouvelle version ou s’il n’est plus accessible (supprimé, masqué, non habilité).
Ce changement est lié au fait que le DMP ne renvoie pas toujours explicitement l’information « supprimé ».

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

• Nouvelle version : informer, permettre la visualisation et l’intégration, en gardant les anciennes versions.
• Non accessible : informer, proposer la suppression dans le dossier patient, uniquement sur action de l’utilisateur.

3. Quand la vérification est-elle faite ?

À l’ouverture du dossier patient (pas en continu).

4. Quelles obligations pour l’éditeur ?

Développements et tests obligatoires avant l’homologation DMP Compatibilité (CNDA).

Annexe – Nouvelle version exigence, scénarios et preuves

Nouvelle version de l’exigence

CDA.DD.05 : LORSQUE l'utilisateur accède au dossier du patient, ALORS sans action supplémentaire de sa part et sans bloquer l'interface utilisateur, pour un document déjà intégré dans le dossier du patient depuis le DMP, le système DOIT l'informer :
* qu'il existe une version plus récente de ce document dans le DMP et le cas échéant permettre à l'utilisateur de visualiser cette nouvelle version et de l'intégrer au dossier du patient en conservant les versions antérieures
ou
* que ce document n’est pas ou plus accessible à l’utilisateur (supprimé, masqué, non habilité) et le cas échéant permettre à l'utilisateur de supprimer ce document dans le dossier du patient.

Nouveau scénario – cas de mise à jour du document

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été mis à jour dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système informe l’utilisateur que le document a été mis à jour du DMP, et lui propose de visualiser la nouvelle version du document ainsi que de l’intégrer dans le dossier patient, la version antérieure étant toujours accessible de l’utilisateur au sein du dossier patient.

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système.
2. Accéder à un dossier patient : le système informe l’utilisateur que le document a été mis à jour du DMP.
3. Montrer que le système propose à l'utilisateur de visualiser le document dans le dossier du patient.
4. Confirmer l’intégration du document dans le dossier du patient.
5. Montrer/vérifier que le document existe toujours dans sa version antérieure.

Nouveau scénario – cas où le document n’est plus accessible

Prérequis :
Un document issu du DMP a été intégré dans le dossier patient du système. Ce document a depuis été supprimé dans le DMP du patient. Vérifier que lorsqu’un utilisateur accède au dossier d’un patient, le système indique à l’utilisateur (à côté du document) que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).

Étapes du scénario :
1. Montrer le respect du prérequis du scénario : Un document issu du DMP a été intégré dans le dossier patient du système et que le document a été supprimé dans le DMP du patient.
2. Accéder au dossier patient : le système indique à l’utilisateur que le document n’est pas ou plus accessible (supprimé, masqué, non habilité).
3. Sur la demande de l'utilisateur, montrer la suppression du document dans le dossier du patient.

Les points de contrôle W16, T21 et D15 du formulaire de test d’intrusion du couloir Hôpital mentionnent que "(...) la configuration doit être complétée par d'autres entêtes, comme X-XSS-Protection ou X-Frame-Options pour la prise en charge de la CSP sur des navigateurs anciens". 
Toutefois, depuis le 4 juillet 2025, l’entête X-XSS-Protection a été déprécié suite à la découverte d’une vulnérabilité liée.

Dans le cadre du référencement Ségur, l'utilisation de l'entête X-XSS-Protection est tolérée et ne remet pas en cause la conformité au référentiel car la découverte de la vulnérabilité est postérieure à l'ouverture des guichets pour le couloir Hôpital.

Cela dit, nous recommandons vivement aux éditeurs qui continueraient à l'utiliser de suivre les dernières recommandations de l'OWASP à ce sujet :

The HTTP X-XSS-Protection response header is a feature of Internet Explorer, Chrome, and Safari that stops pages from loading when they detect reflected cross-site scripting (XSS) attacks.
WARNING: Even though this header can protect users of older web browsers that don't yet support CSP, in some cases, this header can create XSS vulnerabilities in otherwise safe websites source.
Recommendation
Use a Content Security Policy (CSP) that disables the use of inline JavaScript.
Do not set this header or explicitly turn it off.
X-XSS-Protection: 0
Please see Mozilla X-XSS-Protection for details.

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

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

En accord avec la section 4.6.1 de la spécification projet DRIMBox, le mécanisme permettant à un utilisateur d'accéder à l'interface de la fonction consommatrice du logiciel DRIMBox est le suivant : Dans le cadre de la consultation d'un dossier patient au sein d'un LPS, l'utilisateur effectue une action déclenchant l'émission d'une requête d'appel contextuel à destination du logiciel DRIMBox. Suite à la réception de cette requête et à son traitement, le logiciel DRIMBox retourne une réponse HTTP 302 ou HTTP 303 mentionnant un lien de redirection vers son interface. Le LPS appelant réceptionne alors ce message de réponse et effectue la redirection indiquée.

Un ensemble d'informations complémentaires peuvent être précisées concernant le processus de traitement de la requête d'appel contextuel par la solution DRIMBox ainsi que la création d'une URL de redirection. Il est attendu que la réception d'une requête d'appel contextuel par le backend du logiciel DRIMBox entraîne la création d'une instance unique de frontend DRIMBox, associée aux informations issues du message reçu. L'accès à cette instance unique de frontend est rendue possible au travers d'une URL intégrant un UUID permettant de l'identifier. Cette URL d'accès est alors transmise au LPS appelant via le lien de redirection mentionné au sein du message de réponse HTTP 302/303. La robustesse du mécanisme de génération des UUID permettant d'identifier les différentes sessions créées par la solution DRIMBox peut être optimisée en y associant un timestamp.  

Il est à souligner que l'utilisation d'un cookie de session ne nous paraît pas indispensable afin d'assurer l'accès du LPS appelant au frontend de la solution DRIMBox. Dans le cas où un tel mécanisme est envisagé et que celui-ci échoue en raison d'un défaut d'utilisation du cookie de session, l'accès au frontend du logiciel DRIMBox doit tout de même être rendu possible. 
 

Dans le cadre du processus d'authentification à l'environnement DMP, préalable à la publication d'un document KOS, la fonction source de la solution DRIMbox doit utiliser un certificat ORG AUTH CLI, délivré par l’IGC-Santé et correspondant à la situation d’exercice du professionnel de santé ayant validé le compte-rendu d’imagerie associé. 
Afin de respecter la philosophie générale du projet DRIM-M, ainsi que l'ensemble des workflows définis au sein de la spécification projet DRIMBox, le choix du certificat à utiliser dans le cadre de l'authentification auprès de l'environnement DMP doit prioritairement être effectué en accord avec le segment "legalAuthenticator/assignedEntity/representedOrganization" mentionné au sein du compte-rendu d'imagerie associé à la production du document KOS à publier.
L'attribut PRT-8 mentionné au sein du message HL7v2 véhiculant le compte-rendu d'imagerie à destination de la solution DRIMBox doit théoriquement faire apparaître une information identique à celle référencée par le segment "legalAuthenticator/assignedEntity/representedOrganization" issu du document CDA. Le choix du certificat d'authentification à mettre en oeuvre auprès de l'environnement DMP peut donc également être effectué à partir de cet attribut. Cependant, nous priorisons une interprétation du contenu associé au compte-rendu d'imagerie afin de sélectionner le certificat à mettre en oeuvre. 
L'implémentation d'une vérification de cohérence systématique entre ces deux sources d'information (compte-rendu CDA / message HL7v2) par la solution DRIMBox n'est pas obligatoire, la responsabilité concernant la cohérence de ces données incombant  au système producteur du compte-rendu CDA et du message HL7v2 associé. Néanmoins, un tel contrôle peut être défini par les éditeurs de solutions DRIMBox s'ils le souhaitent . Dans ce cas, une situation non-passante (écart entre le document CDA et le message HL7v2 au niveau de la mention du professionnel de santé) doit interrompre le processus de production du document KOS et une alerte doit être remontée auprès de l'administrateur du système producteur de ces données.

Dans le cadre du déroulement des scénarios de test d'interopérabilité associés au processus d'homologation SEGUR vague 2 DRIM-M, l'intégration de documents KOS au sein d'une solution DRIMBox peut être demandé en tant que prérequis. L'objectif d'un tel processus consiste à limiter les interactions entre la solution DRIMBox et l’environnement de test DMP.

Deux situations doivent alors être distinguées en fonction du rôle joué par la solution DRIMBox au sein de laquelle le ou les documents KOS doivent être intégrés : 

• Fonction source : L'intégration d'un document KOS préalablement au déroulement d'un scénario de test permet de simuler une situation de première publication réussie de celui-ci auprès de l'environnement DMP, et ainsi de focaliser les étapes de test sur la gestion du cycle de vie du document KOS (mise à jour, dépublication) ainsi que sur la capacité de la solution DRIMBox à répondre à une requête WADO-RS (mise en œuvre des contrôles auprès de l'archive locale). 
  Sans ce prérequis d'intégration d'un document KOS au sein de la solution DRIMBox, plusieurs étapes de test supplémentaires auraient été nécessaires afin de se trouver dans les conditions permettant de réaliser le workflow demandé.  
• Fonction consommatrice : L'intégration de documents KOS préalablement au déroulement d'un scénario de test permet de pouvoir utiliser les fonctionnalités standards de la solution à son démarrage (navigation, visualisation/export des images référencées), sans qu'une transaction de consultation auprès du DMP soit nécessaire.

Afin de satisfaire aux prérequis d'intégration de documents KOS, plusieurs processus peuvent être envisagés. Ceux-ci sont également à distinguer en fonction du rôle joué par la solution DRIMBox concernée : 

• Fonction source :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au travers d'un mécanisme classique de génération, puis publication auprès de l'environnement de test DMP. A cet effet, l'ANS met à disposition un ensemble de jeux de données HL7v2, CDA, DICOM permettant de réaliser intégralement ce workflow et ainsi d'aboutir à une solution DRIMBox dont l'archive locale contient les documents KOS ciblés.
  • Le chargement de documents KOS au sein de la solution DRIMBox peut également être effectué au moyen d'un import d'archive IHE-XDM, sous réserve de ne pas activer automatiquement la fonction de resynchronisation, cf. exigence DB.SO.28 issue de la spécification projet DRIMBox. Dans ce cas, l'archive IHE-XDM doit être construite par le participant à partir des jeux de données mis à disposition par l'ANS.
  • Enfin, tel qu'envisagé au sein de la section 4.7 de la spécification projet DRIMBox, les documents KOS ciblés ainsi que les métadonnées associées peuvent être intégrés directement au sein de l'archive locale de la solution DRIMBox au moyen d'un mécanisme propriétaire. 
     
• Fonction consommatrice :
  • Le ou les documents KOS peuvent être intégrés au sein de la solution DRIMBox au moyen d'un mécanisme classique de consultation auprès de l'environnement de test DMP. Cependant, cela implique que le ou les documents KOS ainsi consultés doivent avoir préalablement été publiés au sein de l'environnement de test DMP. Implicitement, cet aspect fait donc également partie des responsabilités du participant dans le cas où le processus de consultation classique est mis en œuvre.
  • De la même manière que pour la fonction source, les documents KOS ciblés peuvent être intégrés directement au sein de l'interface de la solution DRIMBox au moyen d'un mécanisme propriétaire. Dans ce cas, l’affichage des documents KOS présentés à l’utilisateur au démarrage de la solution DRIMBox peut présenter un mode dégradé car certaines informations sont normalement issues des métadonnées XDS récupérées auprès de l'environnement DMP. 

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