FAQ des industriels

Oui, il est en effet recommandé que la récupération de l'INS soit seulement effectuée par le référentiel d'identité mais il n’est pas interdit que d’autres logiciels appelle le téléservice INSi et récupère l'INS. Dans le cas où celle-ci est récupérée par le RI, elle peut ensuite être véhiculée aux autres logiciels via un connecteur d'interopérabilité.

Oui, l'INS doit être qualifiée pour être transférée vers un autre logiciel. Pour un statut d'identité récupérée, les traits du téléservice INSi doivent écraser les traits locaux.Plus précisément, il est mentionné que la vérification de la cohérence de l’INS avec les traits d’identité à la réception de données de santé est une exigence, sauf si l’INS a déjà été récupérée ou vérifiée par le téléservice INS chez le récepteur des données de santé. Cela implique que l’INS doit avoir le statut « Identité récupérée » ou « Identité qualifiée » pour être utilisée de manière fiable dans les échanges de données entre systèmes, y compris les logiciels "esclaves".

Non, vous ne pouvez pas déposer toutes vos preuves dans un même dossier ZIP. Selon le document de spécifications de référencement de la vague 2 du Ségur numérique, chaque preuve de conformité doit être déposée individuellement et en respectant les chapitres spécifiques sur la plateforme Convergence.

Lé dépôt des preuves de conformité doit se faire par Chapitre sur la plateforme Convergence. Voici les points clés concernant le dépôt des preuves de conformité. Chaque preuve demandée dans Convergence est obligatoire et doit être déposée telle quelle, sans être regroupée dans un fichier ZIP global.

S'agissant des montées versions Ségur, le logiciel utilisé pour produire les preuves de conformité aux exigences du Ségur doit être disponible à la commercialisation. La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser les montées de version logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La montée de version de ce logiciel étant engagée suite au référencement.
 

Oui, il est possible de répondre aux exigences du référentiel grâce à une solution tierce. En effet, par exemple, l'homologation CNDA pour l'appel au téléservice INSi peut être obtenue par une application tierce complémentaire à votre dispositif médical numérique.

Seul un exploitant peut candidater sur la plateforme Convergence. Un exploitant peut être le fabricant (si possède une entité en France) ou un distributeur (dans le cas ou le fabricant ne peut pas être l'exploitant, c'est à dire qu'il ne possède pas entité juridique en France). 

Si le distributeur ne peut pas obtenir de certificat, alors c'est le fabricant qui sera remboursé et le distributeur devra passer un accord de distribution avec le fabricant.

Pour rejoindre l'Espace de Confiance Pro Santé Connect, consultez l'onglet dédié à l'EdC sur le parcours de raccordement à PSC

Oui l’accès par client lourd en CIBA à Pro Santé Connect est autorisé

Le scénario attendu est le suivant :

Scénario  - application native : Accès par client lourd en CIBA
Vérifie les exigences du référentiel PSC : EX PSC 01, 03, 04, 05, 08, 09, 10, 14, 15, 20, 25, 28, 29, 30, 31
Prérequis : la vidéo doit être en plein écran :
Etapes de la vidéo de preuve :
Afficher la page des CGU du service ou un autre document que l'utilisateur peut consulter facilement avant utilisation du service ayant une page web dédiée accessible via un lien ou un contrat entre l'utilisateur et le service, par contrat peut être entendu un document que l'utilisateur valide en cochant une case
Parcourir les CGU jusqu'au paragraphe PSC
Fermer les CGU
Se rendre sur la zone d'interface utilisateur qui gère la connexion
Action de lancement de la connexion à PSC
Authentification par CPS ou eCPS valide
Affichage de la zone du logiciel indiquant que la connexion est valide
Se rendre sur la zone d'interface utilisateur qui gère la déconnexion
Action de lancement de la déconnexion
Action de lancement de la connexion à PSC 

Sur la plateforme Convergence, plusieurs preuves obligatoires vont vous être demandées selon vos profils sélectionnés pour attester de la conformité votre solution logicielle aux exigences (captures d’écrans, vidéos, fichiers, logs, homologations…). Le dépôt des preuves se fait par chapitre selon la catégorisation proposée dans Convergence et indiquée dans le REM. Vous pourrez également suivre vos dépôts de preuves chapitre par chapitre.

Le numéro de version technique du Logiciel est l'identifiant unique de la solution. 

L'éditeur doit à minima préciser les éléments suivants :

• pour quelle raison des pièces d’identité sont-elles stockées et dans quel(s) cas un accès ultérieur à ces documents est-il prévu ?
• les principes du RGPD sont-ils appliqués (protection des données stockées, information du patient, etc.) ?
• algorithme de chiffrement utilisé et taille des clés,
• modalités de gestion de la durée de conservation,
• précisions sur la "gestion des secrets" :
  • de quelle façon les clés de chiffrement sont-elles générées ?
  • de quelle façon les clés de chiffrement sont-elles protégées ?
  • qui peut y accéder ?
  • comment sont-elles gérées dans le temps ?
  • comment s’exécute le processus de déchiffrement d’un document préalablement chiffré lorsque celui-ci est nécessaire ?

Oui, il est possible de ne remplir qu’un seul formulaire pour la structure. La commande du certificat se fait avec le FINESS géographique du GIE. Pour plus d’informations, nous vous invitons à consulter le guide spécifique à la radiologie, disponible depuis le site esanté accessible via le lien suivant

Oui, le numéro de candidature est communiqué à l’éditeur dès l'inscription au référencement dans Convergence. Ce numéro de candidature sera le numéro de référencement utilisé in fine lors de l’octroi du référencement.

Oui, dans le cas où un éditeur commercialise plusieurs solutions logicielles couvrant des périmètres fonctionnels relatifs aux DSR, il peut solliciter des référencements pour chacune de ces solutions logicielles en déposant autant de candidatures que de solutions  logicelles à référencer.

Une solution logicielle est constituée d’un Composant principal, d’un Composant Proxy esanté, et éventuellement complété d’un ou plusieurs Composants additionnels intégrés dans une version majeure identifiée et référencée par l’ANS. Au sein du présent document, sauf mention spécifique, le terme Solution logicielle désigne donc l’ensemble constitué du Composant principal, du Composant Proxy e-santé, et du ou des éventuels Composants additionnels.

Une équipe est dédiée à la vérification des preuves Interopérabilité. Le suivi des preuves Interopérabilité se fait directement dans Convergence.

La convention de référencement Ségur stipule que l’éditeur doit pouvoir commercialiser le logiciel référencé au plus tard dans les 2 mois à compter de l’entrée en vigueur de la Convention. La date d’entrée en vigueur de la convention est la date de décision du référencement (voir « article 10. Commercialisation du logiciel/Distributeurs ci-dessous) ».

En conséquence, l’éditeur doit collecter les preuves de conformité au DSR à partir d’une version qui doit lui permettre de respecter ce délai maximum de commercialisation à partir de son référencement.

En pratique, les versions des logiciels à partir desquelles les preuves sont générées doivent permettre de couvrir toutes les exigences du profil général et du ou des profils conditionnels retenus par l’éditeur. Les versions doivent avoir fait l’objet de tests préalables (tests fonctionnels, tests techniques, tests de non régression sur l’ensemble du logiciel,…).

Rappel de l’Article 10. Commercialisation du Logiciel / Distributeurs de la convention : L’Editeur commercialise le Logiciel, à des conditions déterminées par ses soins, au plus tard dans les deux (2) mois à compter de l’entrée en vigueur de la Convention. L’Editeur est tenu de produire, sur simple demande de l’ANS et dans un délai de huit (8) jours à compter de cette demande, une preuve de cette commercialisation sous le format d’une documentation commerciale.

Le Numéro de version technique du logiciel est l’identifiant unique de la solution. Il présente obligatoirement les caractéristiques suivantes : 

• Le Numéro de version technique est aisément accessible à l’utilisateur dans l’IHM (Interface HommeMachine) du logiciel, 
• Le Numéro de version technique doit évoluer dès qu’un élément du code source est modifié, y compris un simple patch,
• La succession chronologique des versions techniques doit être clairement compréhensible au travers d’une numérotation alphanumérique

Vous devrez redéposer vos preuves sur chaque DSR sur lesquels vous candidater.

Pendant l’instruction du dossier, une phase d’échanges entre l’ANS et l’Editeur peut être nécessaire afin d’apporter des précisions sur les éléments de preuves fournis par l’Editeur. Dans ce cas, l’ANS peut être amenée à solliciter l‘Editeur via l’outil de gestion des candidatures.
A noter que passé 5 jours sans réponse de l’éditeur, un retard important sur l’instruction du dossier est à prévoir.