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

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.

Il s'agit du cas d'un Proxy e-Santé tiers qui embarque des Composants Additionnels Non Autonomes (ou logiciels EAI).​

Dans le parcours Ségur, l'éditeur de la Solution Logicielle déclare qu'il utilise un Proxy e-Santé tiers et des Composants Additionnels Non Autonomes.​

Dans le parcours d'habilitation EDC PSC, l'éditeur ELU déclare qu'il utilise un Proxy e-Santé tiers.

Dans le parcours d'homologation au CNDA, l'éditeur de la Solution Logicielle déclare qu'il utilise des Composants Additionnels Non Autonomes (EAI) intégrés au Proxy e-Santé et celui-ci bénéficiera d'un plan de test adapté.

Si une Solution Logicielle fait appel à plusieurs téléservices (INSi, DMP, Ordonnance Numérique, MSSanté, etc.), elle doit disposer d’une architecture conforme aux exigences de l’Espace de Confiance Pro Santé Connect (EDC PSC), comprenant au minimum un composant principal (LPS) et un Proxy e-Santé.

Chaque composant de cette architecture doit être déclaré et faire l’objet des habilitations EDC PSC appropriées. L’éditeur de chaque composant est responsable de sa conformité et de sa sécurité, ainsi que de celles des composants intégrés ou interfacés avec celui-ci, conformément aux exigences de Pro Santé Connect et du CNDA.

Par ailleurs, si une même solution consomme plusieurs téléservices, elle suit un parcours d’habilitation EDC PSC unique pour son architecture déclarée, mais doit obtenir autant d’homologations CNDA que de téléservices concernés. Par exemple, une solution utilisant l’INS, le DMP et l’Ordonnance Numérique devra disposer d’une architecture habilitée EDC PSC et réaliser les homologations CNDA correspondantes pour chacun de ces téléservices.

Conformément au DSR, vous devez transmettre l’attestation d’homologation délivrée par le CNDA.

À défaut, il est possible de déposer au plus tard au jalon de la Date 2 de votre couloir (date de dépôt du dossier complet de preuves de conformité) un justificatif attestant du dépôt complet du dossier d’homologation auprès du CNDA pour l’homologation concernée.

Ce justificatif peut par exemple prendre la forme d’une copie d’écran de votre espace personnel CNDA montrant l’état d’avancement ou le pré-examen du dossier.

Image

Dans un contexte de consommation entre une solution DRIMBox et l'environnement DMP, il est pertinent d'afficher le statut associé aux objets KOS et aux CR d'imagerie récupérés. 

Cette nécessité d'afficher le statut des documents obtenus est d’ailleurs portée dans le Guide d’Intégration DMP afin de garantir une cohérence fonctionnelle avec les autres logiciels homologués.

Même si le statut "Approved" est le plus fréquemment rencontré, il reste important de proposer cet affichage au Professionnel de Santé utilisateur de la solution DRIMbox. Cela lui permet de visualiser l’historique des documents précédemment publiés dans le DMP, de comprendre les raisons ayant conduit à la publication de nouvelles versions, et d’identifier à quel moment et par quel acteur ces mises à jour ont été réalisées.

Il est également précisé dans le Guide d’intégration DMP que la récupération et l’affichage des documents comportant un statut "Archived" ou "Deprecated" peut être proposé via une case à cocher. Ce mécanisme permet de préserver un affichage nominal clair en évitant toute confusion pour l’utilisateur (référence EX_3.1‑1030).