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

Le principe de compatibilité ascendante implique que le logiciel, dans sa version candidate au référencement Ségur et souhaitant bénéficier du principe d’équivalence des preuves avec une solution racine référencée (qui peut être soit exactement le même logiciel, soit le même logiciel sous un nom commercial différent, soit un logiciel dont le composant principal est identique à celui du logiciel candidat), doit respecter plusieurs règles :

• la version candidate doit être égale ou supérieure à la version de la solution racine ;
• la version candidate du logiciel doit maintenir la conformité aux exigences Ségur obtenue pour la version de la solution racine.

Par ailleurs, l’article 10 de la convention de référencement précise la responsabilité de l’éditeur de notifier l’Agence du Numérique en Santé si des modifications apportées au logiciel référencé sont susceptibles de le rendre non conforme aux exigences Ségur.

La compatibilité ascendante est également formalisée par la soumission d’une attestation sur l’honneur, fournie selon un modèle ANS disponible sur les pages des dispositifs de la vague 2. Dans cette attestation, l’éditeur déclare que la version candidate respecte les exigences Ségur obtenues lors du référencement de la solution racine

Oui. L’équivalence des preuves s’applique également aux habilitations EDC PSC, sous réserve du respect de la compatibilité ascendante, de la cohérence entre LPS, Proxy e-santé et périmètre déclaré. Les preuves déjà validées ne sont pas redemandées, sauf en cas de modification du périmètre concerné.

L'ENS doit déposer sur la plateforme Convergence au moins une fois son dossier avant le jalon de fin de dépôt du dossier administratif (Date 1). 

L’ANS procède ensuite à l’analyse de l’éligibilité de la solution logicielle de l’ENS au dispositif. Et une fois que sa solution logicielle est déclarée éligible, l’ENS procède aux dépôts des preuves. Une fois cette étape franchie ou après ce jalon (Date 1) si un dossier a bien été déposé dans les temps, l'ENS peut demander à modifier son dossier administratif afférent à son dispositif, que ce soit par exemple au niveau du Proxy ou au niveau des composants additionnels. 

L’ANS se charge de rouvrir les étapes correspondantes, soit la Candidature administrative, soit l’Eligibilité. Un point d’attention : ces changements à l’étape Candidature administrative, ou à l’étape Eligibilité ou aux deux étapes, peuvent entrainer des modifications sur les preuves à déposer ensuite.

Non. S'il y a plusieurs noms commerciaux pour une même solution logicielle, l'auditeur peut :

• Soit faire apparaitre l'ensemble des noms commerciaux sur le rapport de test d'intrusion ;
• Soit proposer un rapport de test d'intrusion par nom commercial, chacun correspondant à une copie d'un même rapport sur laquelle un nom différent est mentionné.

Il est de la responsabilité de l'éditeur d'expliquer à son auditeur à quoi correspond chacun des noms commerciaux ET il est de la responsabilité de l'auditeur de s'assurer qu'aucun écart d'un nom commercial à un autre ne justifie de tests complémentaires. 

Oui. Le candidat devra déposer toutes les preuves du REM-MS-Va2 associées au(x) profil(x) sur le(s)quel(s) il est candidat en Vague 2 et qu'il n'avait pas présentés en Vague 1.

Non. Le composant principal doit être strictement identique pour que l'équivalence des preuves s'applique.

Les composants additionnels étant différents, il s'agit d'une nouvelle Solution logicielle. Vous devez faire une candidature distincte et pouvez bénéficier de l'équivalence des preuves pour les chapitres non impactés par le composant additionnel (cas 3B issu de la notice).

Oui. Vous pourrez dans ce cas saisir les trois numéros de référencement obtenus en vague 1.

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