• Le Parcours Éditeur est destiné au fournisseur du logiciel. Il est limité au bac à sable (BAS) pour développer, tester et constituer le dossier d’homologation (Espace de Confiance Pro Santé Connect).
  La solution pourra être déployée en production via le parcours opérateur.
• Le Parcours Opérateur est destiné à l’établissement ou au prestataire exploitant une solution déjà homologuée. Il permet :
  • de s’appuyer sur l'habilitation EDC PSC de l’éditeur ;
  • de demander directement l’accès à la production ;
  • de ne pas repasser par le Bac à Sable.

Oui. À compter de la délivrance de la conformité des prérequis CNDA, les tests doivent être engagés dans un délai de 3 mois, a minima sur le volet authentification.

En revanche, ce délai ne conditionne pas la finalisation de l’homologation, pour laquelle des délais supplémentaires peuvent être nécessaires.

Oui. Dans le cas d'un logiciel SaaS dont le numéro de version évolue entre le début du référencement et la fin du déploiement, il est possible de candidater sur une version N, d'obtenir le référencement sur une version N+1, puis de déployer une version N+2, à condition que cette dernière respecte les exigences de la version pour laquelle le référencement a été obtenu.

Toutefois, il est demandé à l'éditeur de déclarer tout changement de version auprès de l'équipe de référencement.

En règle générale, la compatibilité ascendante peut être considérée comme respectée en cas de changement de version mineure. En revanche, un changement de version majeure nécessite une analyse spécifique, notamment en raison des impacts potentiels sur certains contrôles, tels que les tests d'intrusion réalisés dans le cadre de l'Espace de Confiance Pro Santé Connect (EDC PSC).

Oui, l’ensemble des collaborateurs disposant d’un accès à la candidature ainsi qu’au produit rattaché à celle-ci peuvent consulter les échanges et les retours des référents de référencement.

Aucune action spécifique n’est nécessaire pour leur donner accès, en dehors du rattachement préalable au produit concerné. Des précisions sur cette configuration sont disponibles dans le guide utilisateur Convergence, notamment dans la dernière section dédiée à ce sujet : https://convergence.esante.gouv.fr/pictures/publish/22.

La réception des notifications par email dépend toutefois des préférences définies par chaque utilisateur, qui peut choisir d’activer ou non ce type d’alertes.

En cas de difficulté ou d’anomalie, les utilisateurs sont invités à contacter directement le support via la plateforme Convergence.

La messagerie de Convergence est dédiée au échanges concernant des dépôts de preuves produits en réponse aux exigences et scénarios du dispositif visé. Elle permet d’échanger directement avec les équipes en charge de la vérification des candidatures lorsqu’un complément d’information, une clarification ou un échange est nécessaire dans le cadre du dépôt et de l’instruction des preuves de référencement.

Le formulaire de demande disponible sur l’Espace Authentifié permet quant à lui de contacter le support Ségur. Les demandes sont prises en charge par le niveau 1 du support, qui les traite directement ou les oriente vers les experts compétents lorsque cela est nécessaire.

Ces deux canaux sont donc complémentaires : la messagerie Convergence est dédiée au suivi d’une candidature en cours, tandis que le formulaire de l’Espace Authentifié permet de solliciter le support Ségur sur des questions plus générales relatives aux dispositifs de référencement.

Oui, le référencement peut tout à fait être prononcé avant la Date 3. Les dates mentionnées dans les documents officiels (DSR et AF) correspondent à des dates butoirs pour les différents jalons du dispositif.

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.

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

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

Vous devez demander le raccordement à Pro Santé Connect en remplissant le formulaire dédié, disponible ici.

Une fois les PV validés, l'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme précisé dans l'article 6.3 de l'appel à financement correspondant). Le fournisseur peut alors demander le paiement du solde pour les prestations réalisées pour ces établissements ainsi que pour l'ensemble des Prestations Ségur réalisées.
 

Le processus de réalisation et de validation des PV pilotes par l'ANS comprend plusieurs étapes :

- Etablissement des PV -  Pour chaque établissement pilote, un PV post-installation est établi. Ce PV doit être signé par le client, attestant de la bonne réalisation de la prestation Ségur et de la stabilité de la solution logicielle, comme notifié dans le chapitre 6.3 de l'appel à financement correspondant

- Transmission des PV et vérification - Les PV signés sont transmis à l'ASP pour vérification de conformité (chapitre 6.3 de l'appel à financement - insérer le lien). L'ASP examine ensuite les PV pour s'assurer que toutes les exigences et critères de conformité ont été respectés.

- Validation des PV et publication des résultats - Si les PV sont conformes, l'ASP informe le fournisseur de la validation des installations pilotes. L'ANS publie l'information sur son site internet, confirmant que la solution logicielle a fait l'objet de premières installations réussies (comme notifié dans le chapitre 6.3 de l'appel à financement)

Le périmètre pilote désigne un ensemble de trois établissements de santé sélectionnés par le fournisseur pour valider la stabilité et la conformité de la solution logicielle avant de généraliser la transmission des demandes de solde, comme spécifié dans le chapitre 6.3 de l'appel à financement correspondant. 

Les demandes de financement et de paiement de l’avance doivent avoir été déposées par le Fournisseur, et validées par l’ASP pour les 3 Clients concernés. Pour justifier du bon déroulé d'une prestation pilote, le fournisseur établit un PV (procès verbal) d'installation pilote qui doit ensuite être transmis à l'ANS qui vérifie sa conformité et informe le fournisseur du résultat de ces contrôles (chapitre 6.3 de l'appel à financement). 

En cas de conformité, l'ANS publiera sur son site internet l'information selon laquelle la Solution logicielle a bien fait l'objet de premières installations réussies.