Besoin d’aide ? Toutes les réponses et ressources utiles pour les ENS

Un médecin aura autant de numéro d'AM que de lieux d'exercice dans lequel il exerce.

Attention : Un numéro d'AM ne doit figurer que sur une seule et unique commande pour un même dispositif.

L'Appel à Financement précise l'Unicité du financement au chapitre 4.2 Conditions portant sur les Clients (extrait ci-dessous) :

"...toute commande comprenant au moins un n°AM d’activité radiologique, et/ou un n°AM d’activité de médecine nucléaire et/ou un n°FINESS géographique d’activité radiologique et/ou un n°FINESS géographique d’activité de médecine nucléaire apparaissant dans une commande déjà financée au titre du présent dispositif, ne pourra faire l’objet d’un financement valorisant les n°AM et/ou n°FINESS géographiques concernés."
 

Comme indiqué dans le DSR, l'habilitation EDC PSC est obligatoire et constitue un pré requis à votre référencement Ségur.

Dans le cas où vous n'obtenez pas l’habilitation Editeur de logiciel utilisateur ou l’habilitation Editeur de Proxy e-santé de l’EDC PSC à échéance de la date 2 du guichet Ségur (date limite de dépôt d'un dossier complet), vous devez transmettre une capture d’écran de l’étape "Dépôt de preuves" sur le guichet EDC PSC devant obligatoirement afficher :

• Le numéro unique de référencement (NRU),
• Le nom de la solution,
• et l'ensemble des chapitres soumis au moins une fois

Image

Vous pouvez poser vos questions via la messagerie de la plateforme Convergence ou contacter le Support Ségur depuis votre espace authentifié.

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. 

Le partage de données d'imagerie entre deux solutions DRIMBox (fonction consommatrice interrogeant une fonction source) implique la mise en œuvre d'une connexion mTLS entre les deux entités. La description des certificats à exposer dans ce cadre peut être résumée de la manière suivante :

• Fonction source : Conformément au contenu de l'exigence DB.SO.90 issu de la spécification projet DRIMBox, la fonction source présente un certificat IGC-Santé rattaché au FQDN atteint par la fonction consommatrice tierce.
• Fonction consommatrice : La fonction consommatrice présente le certificat IGC-Santé correspondant au FQDN déployé au sein de la fonction source qui lui est associée. Dans le cas où la fonction source qui lui est associée expose plusieurs FQDN (donc de facto possède plusieurs certificats), le choix du certificat à présenter est libre. 

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, ...). 

La spécification projet DRIMBox mentionne un ensemble de traces d'audit devant être collectées par les solutions DRIMBox lorsque celles-ci sont impliqués dans une action d'alimentation et/ou de consultation. Cependant, certains cas d'erreur peuvent empêcher ladite action d'aller à son terme et l'intégralité des champs relatifs à la trace d'audit associée peuvent ne pas être connus.

Par exemple, la section 4.5.12.3 de la spécification projet DRIMBox définit une trace d'audit à générer par la fonction source d'une solution DRIMBox lorsque celle-ci réceptionne et traite une requête WADO-RS ciblant la récupération d'images médicales. Cette trace d'audit comporte un champ "UserID" censé contenir l'identifiant RPPS du professionnel à l'origine de la demande d'accès aux images. Cette information ne peut être connue de la DRIMBox qu'après la phase d'introspection ProSantéConnect impliquant le jeton mentionné au sein de la requête WADO-RS. Or, si un cas d'erreur intervient avant la mise en oeuvre de l'introspection (échec de la connexion mTLS par exemple), l'identifiant RPPS ne peut être connu.

Dans ce cas de figure, et pour toutes les situations d'erreur qui empêcheraient la solution DRIMBox de connaître l'intégralité des informations à mentionner au sein d'une trace d'audit, une chaîne de caractère fixe, type "false", peut être renseignée. De cette manière, la trace d'audit exhaustive pourra tout de même être générée, tout en traduisant la situation d'erreur rencontrée.