FAQ des industriels

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA sauf dans le cas d'une homologation EAI, les LPS intégrant un moteur doivent obtenir une homogation auprés du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement. 

Dès l'entame de votre parcours de référencement Ségur, il est nécessaire d'avoir débuté les démarches d'homologations auprès du CNDA. Votre inscription auprès du CNDA vous permettra d'obtenir des éléments nécessaires à la complétion de votre dossier administratif de votre candidature Ségur.

Les éléments attendues, à obtenir auprès du CNDA, dans le cadre du dépôt de votre dossier administratif, au sein de l'étape 2 "Eligibilité" de votre parcours Convergence sont les suivants :
- Numéro NIE / NIL (Numéro d'Identification Editeur et Numéro d'Identification Logiciel).
- Une preuve de dépôt d'une demande d'obtention des labellisations CNDA.

Pour cette dernière, vous avez la possibilité de fournir à l'ANS une copie d'écran de votre espace personnel CNDA indiquant que votre demande de conformité est au minimum au statut "Pré-examen" (exemple ci-dessous). 
 

Image

• IEU 2 : "Le Système DOIT n'autoriser la modification des attributs d'identité d'un Usager qu'avec des informations obtenues par une vérification d'identité aussi fiable que lors de l'enregistrement initial." 
• IEU 7 : "Le Système DOIT supporter le matricule INS comme identifiant d'un Usager." 
• IEU 8 : "Le Système DOIT rechercher le matricule INS de l'Usager lorsque l'identification électronique ne fournit qu'un identifiant privé, par appel du téléservice ou par intégration de l'identité INS en provenance de son domaine d'identification." 

Dans le cas d'une candidature pour un DMN pour lequel l'implémentation de l'Identité Nationale de Santé est non applicable, la conformité aux exigences IEU 2, IEU 7 et IEU 8 n'est pas obligatoire. Ces trois exigences sont donc "Non applicables". En cas de non applicabilité, une déclaration sur l'honneur justifiée devra être fournie à la place de la preuve attendue.

"IEPS 8 - Le Système DOIT garantir l'unicité des identifiants de ses utilisateurs"

Scénario - vérification de l'unicité des identifiants utilisateur : 

1. Création d'un compte utilisateur ; 
2. Création d'un second compte utilisateur avec les mêmes traits d'identité utilisateur afin de déclencher une alerte de risque de doublon ; 
3. Afficher à l'utilisateur, l'alerte de risque de doublon »

Il est accepté de fournir une preuve plus adaptée à votre cas d’usage dès lors qu’elle prouve bien que l’unicité des identifiants utilisateurs est garantie.

A titre d’exemple :

Votre solution propose un numéro d’identification spécifique à votre solution.
Vous êtes conforme à l’exigence si l’attribution de ce numéro d’identification est unique à chaque compte.

Deux références sont indispensables pour ouvrir votre dossier de référencement :Le NIE et le NIL. Ces deux références sont fournies lors de l'ouverture de votrre dossier au CNDA. Concernant le NIL, il s'agit d'un identifiant fourni lorsque vous “créez votre logiciel au CNDA”. Cet élément est alors renseigné sur la convention de Référencement ANS. Au cas où vous ne disposez pas de cette information, vous pouvez contacter la gestion Relation Client CNDA depuis votre espace personnel CNDA

Les engagements de service sont exposés sur la page dédiée.

La liste des services raccordés est sur notre site.

Deux moyens de contact vous sont proposés :

Retrouvez les dernières informations sur l'authentification mTLS et le planning prévisionnel de sa mise en œuvre sur notre documentation technique.

La solution doit obtenir l’agrément du CNDA conformément à l'addendum 8 du cahier des charges SESAM-Vitale [APCV1] ​

Vous pouvez commander un certificat mTLS via la PFCNG. La procédure est détaillée au chapitre Authentification mTLS de la documentation technique. Le processus de commande détaillé est en train d’être mise à jour sur la page Certificats.

Pour Pro Santé Connect il faut que le certificat contienne le client_id dans le champ "CN" du certificat. Sur la plateforme de commande de certificats logiciels, le client_id doit être renseigné dans le champ "service applicatif". C'est ce dernier qui alimentera le champ "CN" du certificat. Il faut donc un certificat spécifique à Pro Santé Connect.

Pas de documentation ANS, l'implémentation d'un serveur intermédiaire est du ressort du fournisseur de service, il peut donc l'implémenter de la manière qu'il le souhaite.

Si le raccordement à Pro Santé Connect a déjà été réalisé en flux CIBA dans un service, il fonctionnera en e-CPS par défaut. 

Pour ajouter la possibilité à l'utilisateur de s'authentifier à l'aide de sa CPx, il faut ajouter un paramètre optionnel « channel » (documenté dans la documentation technique) pour spécifier le type de MIE à utiliser.

Le client_secret ne doit jamais être présent sur le poste client, il doit impérativement être stocké sur le serveur intermédiaire. Nous recommandons, dans la mesure du possible, de conserver également le client_id et les jetons d’accès (access_token, id_token, et refresh_token) sur le serveur intermédiaire.

Non pas forcément, il est possible d'utiliser CPS-Gestion et la carte CPx sur un poste Windows, ou macOS (à venir). Mais en usage full mobile, l’utilisateur aura accès uniquement à sa e-CPS.

L'équipe Pro Santé Connect étudie la possibilité de mettre cela en place, aucune date de mise à disposition ni de langage utilisé ne peut être annoncée à ce stade.

Si vous effectuez un montage (utilisation d’une solution tierce déjà certifiée), vous n’avez pas à effectuer de demande de certification auprès du CNDA. Vous pouvez communiquer à l'ANS le NIL de cette solution tierce lors de votre demande de référencement.

Non, l'exigence PGSSI-S IEU 2 n'est pas applicable lorsque la solution est esclave de l'identité.

Il doit être possible de voir la création ou le résultat de la création d’un patient dans la solution avec son identifiant privé et ses 5 attributs. Il doit être possible aussi de visualiser que ce patient est associé à son INS, même si peut être les étapes du scénario de conformité sont faites en même temps.

Il faudrait donc, s’il n’est pas possible de visualiser la création d’un patient via la GAP, avoir le flux de création permettant de créer le patient et celui pour associer l’INS dans la solution (si différent), puis d’avoir une copie écran d’un compte usager associé à son matricule INS.

NB : Attention à ne pas confondre  la création de l'identité (au niveau de la GAP) et la création du compte dans le DMN. Si la solution ne permet pas l'accès à la GAP, cela signifie qu'il ne peut récupérer l'identité.