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

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

Cette exigence est présente dans le REM DPI avec le "profil CIBA". Il convient de bien sélectionner ce profil au niveau de votre formulaire d'éligibilité pour la voir dans l'espace de preuves.

L’exigence SSI/IE.31 porte sur la vérification des coordonnées utilisées pour l'authentification lors de la création du compte ou la modification d'une coordonnée, que ce soit par un administrateur pour un tiers ou par l'utilisateur de son propre chef.
A noter que dans le cas où un administrateur crée ou modifie un compte pour un tiers, cette mécanique de vérification des coordonnées mail et téléphone pour cet utilisateur tiers permet aussi de s’assurer que la personne concernée est consentante et qu'il n'y a pas eu d'erreur dans la saisie des coordonnées, ce qui est d'autant plus probable dans ce cas.

La définition du périmètre des tests d’intrusion relève de la responsabilité de l’éditeur, en fonction des cas d’usage et de l’architecture de la solution. Le processus générique est le suivant :

1. L'éditeur prend connaissance du périmètre du REM et candidate pour une solution dont il donne le nom et la version.
    
2. L’éditeur a la responsabilité de présenter à l’auditeur le périmètre concerné par le test d’intrusion, en s’appuyant sur sa connaissance de la solution et en se portant garant de la justification apportée.
    
3. L'auditeur doit mentionner dans le rapport de pentest le nom/version de l'application concernée.
    
4. Le guichet conformité vérifie que le nom et la version de l’application concernée correspondent à ceux déclarés par l'éditeur, et que le rapport est conforme aux exigences.

Oui, il est possible de combiner certains critères, selon leur pertinence. Il n’est pas obligatoire de pouvoir interroger individuellement tous les critères listés dans l’exigence.

Ces exigences SC.SSI/IAM.91 et SC.SSI/IAM.92 définissent la manière dont le système doit tracer certaines opérations et gérer la robustesse des mots de passe administrateurs.

Avant, le système devait conserver les traces de l’ensemble des opérations mentionnées (SC.SSI/IAM.91) et permettre à la structure de santé de mettre en place une politique de mots de passe robuste s’il gérait des comptes d’administration dans sa base de compte propre (SC.SSI/IAM.92).

Maintenant, le système doit uniquement conserver les traces des opérations mentionnées qu’il gère localement (SC.SSI/IAM.91) et peut utiliser un MIE sans mot de passe s’il garantit un niveau de sécurité équivalent ou supérieur, par exemple une clé FIDO (SC.SSI/IAM.92).

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

Concrètement :

• Dans la nouvelle version de l'exigence SC.SSI/IAM.91 : possibilité pour chaque scénario de déposer un justificatif expliquant le fonctionnement de l’application et indiquant que l’action n’est pas gérée localement.
• Dans la nouvelle version de l'exigence version SC.SSI/IAM.92 : possibilité de montrer l’authentification au système d’un administrateur pour justifier de l’utilisation d’un MIE sans mot de passe (NB : les codes PIN sont proscrits).

A noter qu'il n'y a aucune obligation pour l'éditeur, il s’agit d’une prise en compte de cas d’usage existants.

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

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

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.

Ce n'est pas exigé dans les fonctionnalités Ségur : c'est au SGL du laboratoire producteur du CR de réaliser cet envoi. Un établissement de santé reste cependant libre d'organiser les flux internes à son SIH selon sa stratégie.