Oui. L'exigence SC.SSI/IE.38.01 prévoit que « le système DOIT permettre au professionnel de fermer sa session ». Dès lors qu'un professionnel de santé peut accéder à la solution via plusieurs interfaces distinctes nécessitant une authentification, cette exigence doit être satisfaite sur chacune de ces interfaces.

Ainsi, toute interface authentifiée donnant accès à la solution doit permettre au professionnel de santé de se déconnecter et conduire à la fermeture effective de sa session.

Bonne pratique sécurité

Cette exigence vise explicitement les accès des professionnels de santé. Elle ne s'applique donc pas formellement aux interfaces destinées aux patients.

Toutefois, lorsque la solution propose également des interfaces accessibles aux patients après authentification, il est recommandé d'appliquer le même principe de sécurité en permettant au patient de fermer sa session et en garantissant la fermeture effective de celle-ci. Cette approche constitue une bonne pratique de sécurité visant à limiter les risques d'accès non autorisés, notamment en cas d'utilisation de postes ou d'équipements partagés.

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

Non, un distributeur n'a aucune action à réaliser pour le référencement de la solution. Le référencement de la solution est pris en charge par l'éditeur de la solution. Ce dernier doit déclarer ses distributeurs dans le dossier administratif du référencement Ségur. Un mandat de distribution devra également être fourni à l'ASP par le distributeur au moment de l'enrôlement au guichet ASP.

Suite à la publication du décret du 8 octobre 2019, l’utilisation de l’Identité Nationale de Santé (INS) pour référencer les données de santé est obligatoire depuis le 1er janvier 2021 pour tous les logiciels, systèmes PACS compris.
Au sein du référentiel INS, l'ANS précise donc que, d'après les articles R. 1111-8-1 à R. 1111-8-7 du Code de la Santé Publique,  le numéro d'inscription au répertoire national d'identification des personnes physiques (dit « NIR » ou numéro de sécurité sociale) constitue désormais l'identifiant national dans les champs de la santé et du médico-social.
Les systèmes PACS doivent donc être en mesure de récupérer, de stocker et de transmettre le matricule INS au travers des échanges de données d'imagerie auxquels ils participent, en plus des autres traits stricts d'identités constituant l'Identité Nationale de Santé, le matricule seul n'étant pas suffisant pour différencier l'identité :
* Nom de naissance
* Premier prénom de naissance
* Date de naissance
* Sexe
* Code INSEE du lieu de naissance
Par ailleurs, il est également nécessaire de prendre en compte les traits d'identité complémentaires afin que le système PACS puisse se conformer au référentiel d'identitovigilance :
* Nom utilisé : nom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du nom de naissance
* Prénom utilisé : prénom utilisé par l’usager dans la vie courante, enregistré obligatoirement lorsque différent du premier prénom de naissance
Il est à noter que les interactions entre la DRIMbox et le(s) PACS, les requêtes ne sont pas basées sur l'INS mais sur le StudyInstanceUID, cela permet à la DRIMbox d'être déployée même si le PACS n'est pas encore INS compatible

Dans le cadre du processus de consultation de documents KOS par la fonction consommatrice d'un logiciel DRIMBox, tel que défini au sein de la spécification projet DRIMBox, le premier acteur impliqué est le LPS initiant une requête d’appel contextuel. Dans ce cadre, le LPS est responsable de la qualification de l’intégralité des traits INS en amont de la construction de la requête d’appel contextuel émise à destination du logiciel DRIMBox. Ainsi, les traits d'identité INS qui sont réceptionnés par le logiciel DRIMBox peuvent être considérés comme « fiables ». 
A partir du contenu associé à la requête d'appel contextuel reçue, la fonction consommatrice du logiciel DRIMBox est en mesure d’interroger l'environnement DMP afin de déterminer quels documents d’intérêt doivent être présentés à l’utilisateur au sein de son IHM (Cf. transaction TD3.1 définie au sein du Guide d'Intégration DMP). 
A l'issue de cette première interaction avec l'environnement DMP, le logiciel DRIMBox récupère un certain nombre de métadonnées associées au contexte de publication du document d’intérêt. C’est uniquement à partir de cette étape que l'interface de consultation du logiciel DRIMBox peut être constituée (pour plus de précisions, se référer à l'exigence DB.CO.54 de la spécification projet DRIMBox). 
Les métadonnées récupérées par la fonction consommatrice du logiciel DRIMBox auprès de l'environnement DMP peuvent elles-mêmes être considérées comme « fiables » car résultant d’un contexte de publication du document KOS construit à partir de l’analyse d’un compte-rendu d’imagerie, lui-même issu d’une demande d’acte d’imagerie remplie par un professionnel de santé.
Ainsi, l’ensemble du processus aboutissant à l’affichage des informations au sein de l’IHM de la DRIMBox consommatrice permet de conserver une cohérence avec celles saisies initialement lors de la planification de l’examen d’imagerie du patient.

Dans le cadre d'une demande de consultation d'un document KOS par un professionnel de santé depuis l'interface du logiciel DRIMBox, ce dernier doit tout d'abord contrôler le consentement du patient à une telle opération (information véhiculée au travers du paramètre "InformationEtConsentement" mentionné au sein de la requête d'appel contextuel provenant du LPS). Ensuite, le logiciel DRIMBox doit initier une transaction permettant d'effectuer un test d'existence du DMP et de récupérer les conditions d'accès à celui-ci (transaction TD0.2 mentionnée au sein du Guide d'Intégration DMP). Enfin, et si cela s'avère nécessaire, le logiciel DRIMBox doit ajouter une autorisation du professionnel de santé pour la consultation de ce DMP (pour plus de précisions à ce sujet, se référer à la transaction TD0.3 définie au sein du Guide d'Intégration DMP).

Les sociétés d’exercice doivent commander un certificat avec le numéro de SIRET. Il s’agit du numéro sur lequel la société facture ses feuilles de soins électroniques.
Les cabinets individuels et les cabinets de groupe  doivent commander un certificat sur le numéro RPPS RANG.

Le guide ci-après propose aux éditeurs et acteurs territoriaux les prérequis et les procédures nécessaires à l'obtention des certificats :  https://esante.gouv.fr/sites/default/files/media_entity/documents/segur-numerique-radiologie-guide-certificats.pdf

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

Consultez l'annuaire santé et vérifiez quelle est la structure de vos clients. Selon la structure indiquée dans l'annuaire, vous pourrez déterminer à quelle procédure de commande de certificats se fier. Pour plus d'informations, nous vous invitons à consulter le guide suivant : 
https://esante.gouv.fr/sites/default/files/media_entity/documents/segur-numerique-radiologie-guide-certificats.pdf

Par ailleurs, le formulaire 413 n'est pas uniquement pour les SCM et les sociétés d'exercice. 

Pour DRIMBOX, la plaquette commerciale ou tout autre document décrivant le périmètre fonctionnel que couvre votre solution logicielle est recevable. L'objectif étant de vérifier que votre solution logicielle répond au périmètre fonctionnel du dispositif choisi.

Oui, en cas de changement ou de renouvellement de la carte CPA les habilitations de l'administrateur technique sont automatiquement reportées sur la nouvelle carte.

Le représentant légal de la structure concernée par le certificat peut déléguer tout ou une partie de la gestion de ses certificats à un tiers, via le portail meshabilitation. La délégation de la commande et l'installation des certificats au fournisseur sont comprises dans les prestations Ségur.

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 la DRIMBox, la prestation secondaire a pour objectif de monitorer et de garantir dans la durée la performance de la Solution logicielle en termes de disponibilité de service, comme précisé dans l'appel à financement correspondant.