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

Le prérequis de maturité technique (PMT) se situe en amont des tests PASSI

Lorsqu’un client dispose d’un RIS référencé Vague 2 couvrant une partie de son activité et d’un second RIS non référencé Vague 2 couvrant une autre partie de son activité, le financement de la DRIMbox peut, à titre dérogatoire, prendre en compte l’activité couverte par ce second RIS, sous réserve du respect cumulatif des conditions suivantes :

• Le client a commandé une DRIMbox dans le cadre du dispositif SONS DRIMbox Vague 2, ainsi qu’une Prestation secondaire de continuité de service associée
• Le bon de commande initial mentionne explicitement le périmètre d’activité retenu pour le calcul du financement, incluant le cas échéant l’activité couverte par le RIS non référencé Vague 2
• Le fournisseur du RIS non référencé Vague 2 s’engage formellement, auprès du client et du fournisseur de la DRIMbox, à mettre en œuvre, avant la VA DRIMbox, les fonctionnalités et flux nécessaires au partage des examens via la DRIMbox et à la consultation depuis le RIS, notamment l’ajout du lien dans le compte-rendu, l’envoi des comptes-rendus à la DRIMbox et l’appel contextuel.
• Le RIS non référencé Vague 2 est effectivement connecté à la DRIMbox au moment de la VA DRIMbox.

Le montant de financement pris en compte est celui déclaré au moment de la demande d’avance, sur la base du bon de commande signé par le client, et ne peut en aucun cas être réévalué à la hausse postérieurement à cette demande. Il demeure en tout état de cause plafonné par les barèmes applicables au dispositif.

Si, au moment de la VA DRIMbox, le RIS non référencé Vague 2 n’est pas effectivement connecté à la DRIMbox ou si les fonctionnalités attendues ne sont pas opérationnelles, le Fournisseur de la DRIMbox devra recalculer le montant de financement en excluant l’activité couverte par ce RIS non référencé vague2 de l’assiette retenue pour la demande de solde de la Prestation principale DRIMbox. Cette exclusion emporte, le cas échéant, les conséquences correspondantes sur le montant de la Prestation secondaire de continuité de service.

Tout écart entre le périmètre déclaré, le périmètre effectivement déployé et les montants demandés ou perçus est susceptible d’être détecté dans le cadre des contrôles. En cas de déclaration erronée ou de manquement avéré, le Fournisseur s’expose au reversement de tout ou partie des sommes perçues.
 

Ce test d’accrochage permet de valider concrètement un test d’authentification PSC via l’API PSC, afin de démontrer l’accès aux services socles. Il constitue ainsi un moyen de sécuriser la suite du parcours et des développements en confirmant la capacité d’accès au DMP via Pro Santé Connect.
Il n’est pas obligatoire lors de l’accès à l’espace de test du CNDA, mais il relève des bonnes pratiques recommandées.

Nous vous conseillons de voir le replay du webinaire du 4 juin 2026 sur "l'architecture logicielle" qui traite de cette question de test d'accrochage : https://esante.gouv.fr/webinaires/segur-vague-2-architecture-des-solutions-homologation-cnda-et-pro-sante-connect

Pour voir un exemple de test d'accrochage sur un environnement potsman vous pouvez regarder cette vidéo :  https://www.youtube.com/watch?v=1XMThUSO_Po

N.B. Attention lors de vos tests d'accrochage au CNDA il faudra utiliser directement le couple LPS et proxy et non un environnement postman

Des travaux de convergence sont prévus dans le cadre du développement du portefeuille européen d’identité numérique (European Digital Identity Wallet). Ce dispositif a notamment vocation à favoriser l’interopérabilité et la fédération des mécanismes d’identification et d’authentification à l’échelle européenne.

Chaque solution logicielle métier dispose de son propre certificat. Ainsi, un certificat est associé à chaque composant principal (LPS) et au proxy partagé. C'est ce certificat qui est utilisé dans le cadre des échanges avec Pro Santé Connect et les services tiers concernés.

Une candidature « Éditeur de solution logicielle » doit être déposée pour chaque composant principal (LPS). Par ailleurs, une candidature unique doit être déposée pour le Proxy e-santé partagé.

Ainsi, le cas d’une architecture comportant deux composants principaux et un Proxy e-santé partagé, trois candidatures doivent être déposées au total : deux candidatures « Éditeur de solution logicielle » et une candidature « Éditeur de Proxy e-santé ».

Un site géographique est identifié :

• Soit par son numéro FINESS géographique
• Soit par son SIRET

Le Proxy e-Santé est utilisé pour sécuriser et standardiser les échanges entre le logiciel métier (Composant Principal LPS) et les API Pro Santé Connectées (DMP, INSi, Ordonnance Numérique, etc.).

Il gère les mécanismes d’authentification et de sécurité (mTLS, OAuth2, OpenID), facilite l’intégration technique, et permet de mutualiser certains développements.

Même si cela ajoute de la complexité, le Proxy e-Santé est obligatoire pour répondre aux exigences réglementaires et garantir la conformité des accès.​

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidatez.

Toutefois, si votre solution est éligible au mécanisme d’équivalence des preuves, vous pourrez être exempté du dépôt de certaines preuves communes au dispositif candidat (par exemple : Médico-social DUI, Sage-femme / Paramédical), dès lors que vous avez déjà obtenu un référencement Vague 2 sur un autre dispositif comportant ces mêmes exigences. Pour cela, vous pouvez consulter la matrice d'équivalence correspondant à votre couloir candidat sur le site de l'ANS. 

Pour un utilisateur, la gestion de l'envoi de documents vers le Dossier Médical Partagé (DMP) et la Messagerie Sécurisée de Santé (MSS) depuis un logiciel s'effectue par une interface conçue pour être à la fois automatisée et personnalisable. L'objectif est de simplifier au maximum le processus tout en respectant les obligations légales et les situations spécifiques des patients.

Envoi de documents au DMP
L'envoi automatisé d'un document au DMP est défini dans l'onglet "Liste des documents Ségur" du Référentiel d'Exigences (REM) de votre dispositif et le document est visible par le patient.
Cette configuration par défaut est non modifiable de façon globale par l'utilisateur, ce qui garantit le respect de l'obligation légale d'alimentation du DMP (Article L. 1111-15 du Code de la santé publique précisé par l’arrêté du 23 mai 2024).

Toutefois, le professionnel de santé dispose de deux options pour gérer l'envoi et la visibilité d'un document au cas par cas :

• Ne pas envoyer un document : L'utilisateur a la possibilité de ne pas envoyer un document au DMP si le patient s'y oppose pour un motif légitime (motif légitime ne nécessitant pas de traçabilité et laissé à l’appréciation du professionnel)
• Modifier la visibilité : Le professionnel peut rendre un document invisible au patient (dans l'attente d'une consultation d'annonce pour un diagnostic grave) ou à ses représentants légaux (Le respect du secret médical pour un mineur ne souhaitant pas que ses parents soient informés de certains soins.)
• Cas particulier « Modèles de documents »
  • Pour optimiser le processus de production documentaire, le professionnel pourrait pré-paramétrer des modèles de documents et leurs conditions de visibilité. Par exemple, un professionnel peut créer un modèle de « compte-rendu d'expertise judiciaire » et le configurer pour que son envoi au DMP soit désactivé par défaut.

Envoi de documents par MSS professionnelle
l'envoi des "documents Ségur" vers la MSS professionnelle est également défini dans l'onglet "Liste des documents Ségur" du REM. Ces documents sont systématiquement transmis, à minima, au Médecin Traitant (MT) et au professionnel adresseur.
Le professionnel de santé peut modifier ou amender la liste des destinataires ou les paramètres d'envoi si besoin.