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

La liste des éléments et mentions obligatoires à faire figurer dans la facture sont détaillés au chapitre 12 du document "SONS-Modeles_de_documents-BDC-MOM-VA.pdf" disponible en cliquant ici

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.

• Dans le cas d'un CDAR2N1, le PDF à mettre en pièce jointe doit être identique à celui encapsulé dans le CDA.
• Dans le cas d'un CDAR2N3, "Le document de santé au format PDF doit afficher tous les éléments de l’entête du document CDA ainsi que les zones textuelles des différentes sections du corps du document CDA."

Vous devez faire un groupement d'éditeurs pour répondre à tout le périmètre des exigences, il faut cocher "OUI".

A noter qu'un composant additionnel ne doit pas faire l’objet d’un coût supplémentaire pour le client. 

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.

L’utilisation d’un composant tiers déjà homologué par le CNDA ne dispense pas systématiquement de réaliser une demande dans le cadre de la mise en conformité de votre solution logicielle. Dans la majorité des cas, une démarche reste nécessaire, cela dépend du type de composant tiers et de son mode d’intégration.

Afin de clarifier les règles applicables, plusieurs situations doivent être distinguées :

Premier cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel non autonome

Un composant additionnel non autonome est appelé au CNDA "application EAI" dans le cas du DMP ou "moteur à IHM" masquée dans le cas de l'INSi.

Dans ce cas :

• Chaque application EAI ou chaque moteur à IHM masquée doit passer une homologation au CNDA.
• Chaque composant principal d'une solution logicielle qui intègre une application EAI / moteur à IHM masquée doit passer une homologation au CNDA.

A noter que l'homologation est complète mais plus rapide car les applications EAI/moteur à IHM masquée ont déjà validé une partie des tests à repasser.

Deuxième cas de figure : le composant principal de la solution logicielle PS utilise un composant additionnel autonome

Un composant additionnel autonome est une application (tierce) à part entière avec des IHM autonomes et visibles. Au CNDA, il s'agit d'une application autonome. Le composant principal d'une solution logicielle PS s'interface avec l'application autonome (tierce) via un appel contextuel. L'opérateur de la solution logicielle PS peut opérer une instance dédiée de la solution autonome (tierce) ou peut utiliser une instance mutualisée opérée par l'éditeur de la solution autonome tierce.

Dans ce cas :

• Chacune de ces applications autonomes tierces doit passer une homologation au CNDA.
• Dans le cas du composant principal de la solution logicielle PS :
  • Si l'opérateur du composant principal de la solution logicielle PS opère aussi une instance dédiée de l'application autonome (tierce) alors le composant principal de la solution logicielle PS doit passer une homologation d'interfaçage avec l'application autonome (tierce) dans le cadre de la conformité DMP.
  • Pour l’INSi et l’Ordonnance Numérique les éditeurs intégrant des composants tierces (moteur coté CNDA) doivent déposer une demande de conformité en mode apparent.
    • Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » et/ou « Ordonnance Numérique » en mode IHM apparente, l’éditeur n’a pas à constituer de dossier de preuves de tests, il peut passer directement à l’étape d’examen de conformité indiquée à l’Article 5.3 : Etape d’examen.
      Dans le cas où le logiciel intègre un composant déjà autorisé « INSi » en mode IHM masquée (ou semi masquée), l’éditeur doit réaliser toute les phases de la procédure de conformité.

Le CIBA est prévu dans la vague 2 du Ségur en tant que profil optionnel. En cas de client lourd, l'éditeur doit proposer les deux solutions (code flow et CIBA) en lien avec les exigences SC.PSC.01 et SC.PSC.13. Le profil est obligatoire lorsque l’éditeur a choisi d’implémenter dans sa solution logicielle l’authentification ProSanté Connect par le protocole CIBA (§3.1 du DSR DPI).

Cette phase a pour finalité d'échanger sur le rapport du test d'intrusion, notamment si des manquements aux règles de sécurité sont détectées. L'auditeur devra communiquer les résultats du test d'intrusion à l'éditeur en clarifiant les points suivants :

• Les détails techniques des vulnérabilités identifiées ;
• L'impact potentiel des non-conformités aux règles de sécurité et le niveau de risque associé ;
• Les solutions concrètes permettant de corriger les potentielles failles ;
• La définition des prochaines étapes (définition d’une date permettant d’évaluer de nouveau les vulnérabilités recensées).