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

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

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

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.