Questions fréquentes

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

Oui, il s'agit de l’exigence EDC/PSC.101.01 qui s’appuie sur le référentiel de Pro Santé Connect "Espace Communautaire" :

• L'éditeur doit fournir ses CGU, même partiellement rédigées, intégrant au minimum le paragraphe relatif à Pro Santé Connect.
• L'opérateur doit fournir ses CGU définitives.

L'exigence IEPS.08 "SI le Système propose son propre dispositif d'authentification ET SI il autorise une identification électronique à un seul facteur succédant à une identification électronique à deux facteurs, ALORS le Système DOIT imposer un délai maximal paramétrable entre ces deux identifications électroniques et vérifier que le simple facteur utilisé fait partie du dispositif d'authentification à deux facteurs utilisé initialement." est considérée "Non Applicable" dans le cas où votre système propose exclusivement l'authentification à deux facteurs (2FA). Une déclaration sur l'honneur justifiée, datée et signée par le responsable légal de l'entreprise, devra être fournie en preuve. Cette déclaration doit préciser que le système ne permet à aucun moment l’utilisation d’un seul facteur d’authentification après une authentification à deux facteurs.

L'expression fait référence aux cas où le système intègre un mécanisme d'authentification interne propre à la plateforme permettant aux utilisateurs professionnels de santé de s’identifier (exemple : identification par login / mot de passe). Dans ce cas, les exigences IEPS 05, IEPS 06 et IEPS 08 sont applicables. 

Si l’éditeur ne gère pas lui-même l’authentification et utilise uniquement un service externe ou une fédération d’identité (exemples : Pro Santé Connect, FranceConnect…), alors le système ne met pas en œuvre son "propre dispositif d’authentification". Dans ce cas, les exigences IEPS.05, IEPS.06 et IEPS.08 sont "Non Applicables". Une déclaration sur l'honneur justifiée, datée et signée par le responsable légal de l'entreprise, devra être fournie en preuve.

Non, vous n'êtes pas éligible à la certification de conformité au référentiel d'interopérabilité, de sécurité et d'éthique des SI de téléconsultation. Il est néanmoins exigé à minima de se tenir conforme aux référentiels INS et PGSSI-S de la doctrine du numérique en Santé. 

Pour plus d'informations, consultez notre page dédiée à la Doctrine du numérique en santé.

Les distributeurs doivent s'enrôler auprès de l'ASP pour pouvoir faire des demandes de financement pour les commandes qu'ils signeront. 

Pour qu'un distributeur puisse s'enrôler à l'ASP :

• il doit avoir été déclaré par l'éditeur dans le formulaire d'éligibilité dans l'outil Convergence.
• il doit disposer d'un mandat de distribution conclu avec l'éditeur.

Par ailleurs, si la solution est installée et opérée par l'éditeur et non par le distributeur revendeur pur, l'éditeur doit autoriser le distributeur à disposer de son habilitation Opérateur PSC (habilitation exigée pour faire des demandes de financement) explicitement dans le mandat, via la formulation suivante par exemple :
"Dans la mesure où l’Editeur opère la Solution en production, l’Editeur autorise le Distributeur à disposer, dans le cadre des demandes d’avance SONS-IMG-DB-va2, de l'habilitation « Opérateur de service utilisateur » de l’Espace de confiance Pro Santé Connect (EDC PSC), obtenue par l'Editeur pour la Solution."
 

Afin de tester l'intégralité des mécanismes de contrôle implémentés par les solutions DRIMBox candidates au référencement SEGUR DRIM-M, certaines situations "non-passantes" sont intégrées au sein des scénarios de test définis dans ce contexte. Ces cas d'erreur peuvent résulter de l'exploitation de jeux de données volontairement corrompus ou d'interaction entre la solution DRIMBox et un simulateur présentant un défaut de configuration intentionnel. Il est donc cohérent que pour ces situations l'utilisateur constate un résultat d'exécution non-passant au sein de l'interface du simulateur/validateur.