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

L’ensemble de la Solution Logicielle, c’est-à-dire le Composant Principal LPS, le Proxy e-Santé et les Composants Additionnels interfacés avec le Composant Principal LPS ou le Proxy e-Santé, font partie de l’Espace de Confiance PSC.

Le Composant Principal LPS et le Proxy e-Santé doivent être habilité dans l’Espace de Confiance PSC selon son rôle.​ 

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

Si une Solution Logicielle fait appel à plusieurs téléservices, elle doit avoir une architecture conforme pour être habilitée EDC PSC, c’est à dire disposer au minimum d’un Composant Principal LPS et d’un Proxy e-Santé.

Chaque composant doit être déclaré et suivi séparément pour son habilitation EDC PSC. 

L’éditeur de chaque composant doit assurer la conformité et la sécurité de son composant ainsi que des composants intégré ou interfacé avec lui, selon les exigences CNDA et PSC.​

L’“éditeur” et l’“opérateur” sont deux rôles distincts :​

• L’éditeur est responsable du développement et de la conformité du logiciel ou du Proxy e-Santé.​
• L’opérateur est celui qui exploite la solution (logiciel ou proxy) en production.​

Seul l’opérateur (ou un fournisseur disposant de l’habilitation Opérateur de Service Utilisateur) pourra s’enrôler pour financement auprès de l’ASP.

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

Dans ce cas, chaque Composant Principal LPS doit être homologué au CNDA et habilité EDC PSC. Le Proxy e-Santé doit seulement être habilité EDC PSC, mais pas homologué CNDA.

Attention, si des Composants Additionnels Non Autonomes sont intégrés au Proxy e-Santé, ceux-ci devront être homologués au CNDA.

Non. L’EAI tiers peut être intégré de deux manières :​

• Côté LPS (Composant Principal) : dans ce cas, il est intégré au logiciel utilisateur et l’ensemble doit être homologué par le CNDA.​
• Côté Proxy e-Santé : dans ce cas, l’EAI, intégré au Proxy e-Santé, sera homologué au CNDA. Le Proxy e-Santé en tant que tel n’a pas à être homologué au CNDA.  

Dans les deux cas, l’EAI doit être homologué par le CNDA, que ce soit intégré au LPS ou au Proxy e-Santé. 

Un Editeur de Logiciel Utilisateur (ELU) devra déclarer plusieurs dossiers s'il s'interface avec plusieurs Proxy e-Santé : 1 dossier par Proxy e-Santé.

A ce jour, l'Outil De Conformité du Proxy e-Santé de l'EDC PSC n'accepte que les flux CIBA.​

Il existe aussi une collection POSTMAN pour tester la conformité du Proxy e-Santé à l'EDC PSC mais celle-ci a été implémentée pour les flux CIBA.

L'évolution de cette collection POSTMAN pour tester le flux authentification Code Flow n'est pas disponible pour le moment.​​

Oui, il est possible de modifier sa déclaration. Il est recommandé de faire ses arbitrages avant le dépôt des preuves car celles-ci pourraient être à requalifier.