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

Le renouvellement d'un certificat ne peut se faire que si le certificat actuel est encore actif. S'il est arrivé à échéance, l'administrateur devra générer un nouveau certificat.

Pour effectuer le renouvellement de votre certificat, vous devez vous connecter sur IGC Santé, puis sélectionner la demande de produit "le certificat" et valider son renouvellement. Il vous suffit ensuite de télécharger le nouveau certificat et de l'installer à la place de l'ancien. 

Pour plus d'informations, vous pouvez vous référer au replay du webinaire "Anticipez le renouvellement des certificats IGC-Santé"

Un certificat délivré par l'ANS a une durée de validité de 3 ans à compter de son obtention.

Son renouvellement n'est pas automatique. Une notification automatique est envoyée à l'administrateur technique 60 jours avant la fin de validité du certificat qui devra effectuer un renouvellement avant la fin de validité.

Les alertes relatives aux péremptions de certificats sont envoyées automatiquement aux administrateurs techniques depuis l'adresse : noreply@pfc.eservices.esante.gouv.fr.

Si l'adresse associée au certificat n'est plus valide ou consultée, la notification rappelant la fin du certificat n'est jamais reçue, il est donc important de renseigner une ou plusieurs adresses pérennes  : une adresse mail partagée ou générique sans CAPTCHA.

Pour le RIS, la prestation secondaire a pour objectif de monitorer et de garantir dans la durée la performance de la Solution logicielle en termes d’alimentation de Mon espace santé, comme précisé dans l'appel à financement correspondant.

Oui, le RIS doit obligatoirement pouvoir alimenter le DMP par API Pro Santé Connectée

Après certification, le CNDA remet à l’éditeur :

• L'attestation de conformité ;
• La lettre de référencement.

L’éditeur utilise ensuite l’attestation de conformité comme preuve de certification auprès de l’ANS.

Vous trouverez ci-dessous un exemple d'attestation de conformité :

Image

Scénarios des exigences concernées :

• MSS/CONF.01.01
• MSS/CONF.03.01
• MSS/CONF.05.01
• MSS/CONF.06.01
• MSS/CONF.07.01
• MSS/CONF.11.01
• MSS/CONF.12.01
• MSS/CONF.14.01
• MSS/CONF.15.01
• MSS/CONF.16.01
• MSS/CONF.21.01
   

Les scénarios des exigences MSS/CONF.xx.01 sont complétés afin de mentionner explicitement le job MOTCO.

Tous les tests des exigences MSS.CONF peuvent être validés avec le job global ou ils peuvent être validés exigence par exigence avec un test unitaire. Ces tests sont décrits dans le Manuel d'utilisation de l'outil de test MSSanté MOTCO2 [MOTCO]

1. Quel est le changement ?
Dans le cadre de l’exigence SC.MSS/UX.01, l’étape 3 du scénario doit être supprimée pour les RIS. Cette étape indiquait la création automatique d’un flux HL7 vers le DPI après dézippage de l’archive.
 

2. Pourquoi cette étape est-elle supprimée ?
L’exigence SC.MSS/UX.01 porte uniquement sur la capacité du système à identifier les courriels MSSanté contenant une archive IHE XDM. La création d’un flux HL7 ne fait pas partie du périmètre attendu et ne doit pas être prise en compte lors des vérifications de preuves.
 

3. Consignes pour les éditeurs et les vérifications
• Ne pas présenter de preuve liée à la création d’un flux HL7 vers le DPI.
• Les preuves doivent uniquement démontrer l’identification des courriels MSSanté contenant une archive IHE XDM.
 

4. Rappel du scénario applicable (sans l’étape 3)
Prérequis :
Un message contenant une archive zip au format IHE XDM en pièce jointe a été reçu.

Objectif :
Vérifier qu’il est possible d’identifier les courriels reçus via MSSanté avec archive zip au format IHE XDM en pièce jointe.

Étapes du scénario :
1. Montrer le respect du prérequis : réception d’un message MSSanté avec archive IHE XDM.
2. Montrer comment le système identifie les courriels reçus via MSSanté contenant une archive IHE XDM en pièce jointe.
 

Conformément aux exigences prévues au chapitre 4 des DSR et à la section 4.3 de l’Appel à financement, pour les solutions logicielles pour lesquelles vous souhaitez mobiliser des financements Ségur, la déclaration de l’ensemble des versions techniques ayant fait l’objet d’une information publique auprès de vos clients concernant un arrêt de maintenance et/ou un arrêt de commercialisation est obligatoire.

À cet effet, le fichier modèle de déclaration des versions obsolètes, disponible dans le formulaire d’éligibilité, doit être complété. Dans le cas où aucune version obsolète n’est à déclarer, cette situation devra être explicitement mentionnée dans le fichier dédié. 

Cette démarche est un prérequis obligatoire à l’obtention du financement Ségur vague 2.

Les preuves sont analysées une fois que l'ensemble du chapitre est complet et soumis.

Oui, un composant "EAI/librairie" non autonome intégré dans le proxy doit passer son agrément au CDNA pour obtenir sa propre homologation.