Questions fréquentes

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.

Lorsqu’un Proxy e-Santé prend en charge des requêtes métier, il est considéré comme un proxy intégrant un Composant Additionnel Non Autonome (EAI).

Dans ce cas, ce Composant Additionnel Non Autonome intégré dans le Proxy e-Santé et assurant la gestion des flux DMP doit être homologué au CNDA.

• L'Éditeur de Logiciel Utilisateur développe le Composant Principal (LPS) et notamment son Interface Homme Machine (IHM) qui sera utilisée par le professionnel de santé. Le LPS gérera des règles métiers.​
• L'Editeur de Logiciel Proxy e-Santé édite le Proxy e-Santé qui est une brique technique assurant les liens techniques et de sécurité entre le LPS et les APIs des services socles, comme le DMP. Le Proxy e-Santé peut aussi gérer la création et le formatage de certaines requêtes métiers.

Sur la plateforme Convergence, lors de la phase de candidature administrative, les champs NRU éditeur de logiciel Utilisateur et NRU éditeur de logiciel Proxy e-sante ne sont pas obligatoires. 

Néanmoins, nous vous recommandons vivement de les compléter, car ces informations facilitent le rapprochement des candidatures entre les guichets Ségur et EDC PSC. 

En effet, cela nous assure que vous êtes bien engagés sur l'Espace de Confiance Pro santé Connect en vue de l'obtention de vos habilitations EDC PSC.

Au référencement Ségur, une seule candidature sera attendue au niveau de votre dispositif dans le cas où vous êtes éditeur et opérateur de votre solution candidate.

Par ailleurs, en tant qu'éditeur et opérateur de la solution logicielle, vous devez déposer deux candidatures sur l'Espace de Confiance (EDC) Pro Santé Connect (PSC) accessible via Convergence.

Vous devez candidater au guichet éditeur pour obtenir l’habilitation des composants principaux et du Proxy e-Santé de la solution logicielle pour permettre son référencement. Puis, une fois ces habilitations obtenues, vous pouvez candidater au guichet Opérateur pour obtenir l’habilitation “Opérateur de Service Utilisateur” (composants principaux) et “Opérateur de Proxy e-Santé” (Proxy e-Santé). La réalisation de ces deux étapes est indispensable pour que les clients de la Solution Logicielle bénéficient du financement prévu par le Ségur.

Pour plus de précisions sur le parcours Espaces de Confiance Pro Santé Connect, vous pouvez vous référer au guide d'utilisation EDC PSC

Il est possible de modifier les identifiants déjà associés à une solution, bien que cela ne soit pas nécessaire (l’expiration de la carte CPS n’a aucun impact sur MOTCTO2.

En revanche, si vous souhaitez associer tout de même de nouveaux identifiants à une solution, il vous faudra modifier ceux existants (bouton modifier). Il faudra patienter 24h afin que les nouvelles BAL liées aux nouveaux identifiants soient créées. Les BAL créées avec les anciens identifiants seront supprimées par la suite.

Les deux modes, Communautaire et Confiance, permettent de se connecter via Pro Santé Connect pour utiliser MOTCO 2.

Dans le cadre du processus d'homologation SEGUR vague 2 associé aux solutions DPI et RIS, un des scénarios de test à dérouler implique l'utilisation du simulateur serveur appel contextuel.

Historiquement, le service "302" exposé par cet outil de test présentait une anomalie, corrigée depuis le 15/10/2025. Ce dysfonctionnement correspondait à l'envoi de réponses HTTP 302 ne mentionnant pas de header "Location".

Une nouvelle version du simulateur, actuellement déployée au sein de la plateforme dédiée au référencement, corrige ce défaut. 

L'accès à l'interface de la fonction consommatrice associée à une solution DRIMBox n'est possible qu'à partir d'une transaction d'appel contextuel initiée par un LPS de type RIS ou DPI. Suite à l'émission de la requête d'appel contextuel par le LPS, cinq réponses possibles peuvent être émises par la solution DRIMBox interrogée :  

• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 303.
• Réponse HTTP 303 See Other mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 303.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL absolu. Dans ce cas, le LPS doit effectuer une redirection vers l'URL mentionné au sein de la réponse 302.
• Réponse HTTP 302 Found mentionnant un header "Location" associé à un URL relatif. Dans ce cas, le LPS doit effectuer une redirection vers un URL correspondant à la concaténation du hostname DRIMBox ciblé par la requête d'appel contextuel et le chemin relatif mentionné au sein de la réponse 302.
• Réponse HTTP 400 Bad Request indiquant que la requête d'appel contextuel reçu par la DRIMBox ne satisfait pas aux exigences mentionnées au sein de la spécification projet DRIMBox (problème de format, paramètre manquant, ...).