FAQ des industriels

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

On entend par "correspondant" tout professionnel de santé avec lequel un utilisateur de la solution est susceptible d’interagir. L’utilisateur de la solution se distingue du correspondant par le fait d’avoir un accès à la solution (via une authentification PS avec un MIE, PSC, etc…), contrairement au correspondant.

Pour qu'une solution soit intégralement conforme au référentiel ANN, la création de fiche correspondant doit être effectuée dans l'application à chaque fois qu'un PS est mentionné par un utilisateur, dans un dossier patient ou ailleurs, ou consulté via l'envoi de documents ou d'informations.

Les informations obligatoires du correspondant et la fréquence de rafraichissement de ces informations sont les mêmes que pour l'utilisateur.

"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 enjeux majeurs sont associés à la mise en œuvre de l’IGC-Santé :  

• assurer la sécurité des clés privées et des certificats émis par l’ANS : il faut veiller à limiter l’accès à ces clés privées et qu’elles ne puissent pas être dupliquées ni installées sur plusieurs équipements ;
• assurer la continuité de service : de nombreuses applications de santé utilisaient les certificats émis par les deux anciennes IGC-CPS, qui ne sont plus actives depuis Janvier 2021. Elles doivent prendre en compte les nouveaux certificats émis par l’IGC-Santé.

En plus, les certificats émis par l’IGC-Santé respectent les règles habituelles de sécurité (analyse de risque, politique de sécurité), les "Politiques de Certification", et ils sont conformes aux référentiels de la PGSSI-S.

L'Infrastructure de Gestion des Clés cryptographiques (IGC) opérée par l'ANS (IGC-Santé) délivre des certificats conformes au référentiel d'identification à la Politique Générale de Sécurité des Systèmes d’Information de Santé (PGSSI-S) pour l’accès aux services du numérique en santé (article L1470-1 et suivants du Code de la Santé Publique).

Les certificats émis par l'ANS permettent d'identifier les acteurs du secteur, personnes physiques et organisations. Ils attestent aussi de la qualité des pratiques de gestion des clés publiques mises en œuvre par ces autorités. Ils peuvent être révoqués en cas de défaillance.

L’ANS propose 4 offres de certificats logiciels : 

• certificat de personne morale Organisation ;
• certificat de personne morale Serveur ;
• certificat de personne physique Professionnel ;
• certificat de personne physique Professionnel de Santé .

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.

Le référentiel d'interopérabilité et de sécurité des DMN est traduit en anglais. Il est disponible sur le portail industriel de l'Agence du Numérique en Santé. Les guides de dépôt des différents parcours seront traduits prochainement.

Il n'y a pas d'obligation à être certifié conforme au référentiel de l'ANS pour commercialiser le dispositif médical numérique marqué CE. La certification est obligatoire pour prétendre à un remboursement par l'Assurance Maladie.

Vous trouverez les jeux de test de l'INS à l'adresse ci-dessous. Pour rappel, les preuves INS à fournir lors de la candidature pour la certification de conformité au référentiel des DMN sont à réaliser grâce à ce jeu de test.

Le champs « identifiant national du professionnel » doit : 

• dans le cas de l’utilisation de l’API FHIR, contenir la valeur de l’IDNPS ;
• dans le cas de l’utilisation du fichier PS_libreAcces, contenir la valeur de l’Identification nationale PP.

Pour information : Identification nationale PP/ IDNPS : préfixe « 8 » + numéro RPPS

La plateforme interop.esante.gouv.fr permet de visualiser les preuves en avance de phase, mais pour le référencement vous devez utiliser la plateforme interopsegur.esante.gouv.fr.

Si le système utilise l’API FHIR pour récupérer les données annuaire de santé, il est nécessaire d’avoir , en plus des preuves énumérées en ANN.1.1.1, une description du process es différents appels à l’API effectués (mode DELTA, FULL, unitaire) : à quel moment ces appels sont faits, à quelle fréquence le cas échéant. 

De même pour la preuve ANN.2.1.2, en plus de la vidéo montant la recherche des données annuaire dans le service, il sera nécessaire de fournir les logs des appels API nécessaires à cette recherche.

Les alertes d’hypoglycémie sévère doivent être générées en fonction d’une fréquence d’émission (c’est à dire en fonction d’un nombre d’alertes dans un temps donné) en plus d’un dépassement de seuil. 

Par exemple, il faut que le niveau d’alerte d’hypoglycémie soit dépassée 3 fois en 1 journée pour que l’alerte d’hypoglycémie sévère soit déclenchée. Ce sont ces données qui doivent pouvoir être paramétrable par le PS, l’objectif étant d’éviter les alertes non significatives.

Dans le cadre d'une candidature PCI, il est considéré comme conforme que le DMN propose de suspendre temporairement les alertes de non-transmission de données, à condition que cette suspension soit limitée à une période spécifiquement définie, qu’elle soit utilisée à des cas d’usage spécifiques et justifiés, et que la réactivation des alertes se fasse de manière automatique à l'issue de cette période.

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

Sauf cas exceptionnel, un DMN ne doit candidater que sur un seul parcours (ligne générique ou nom de marque). Par contre, dans le cas ou un DMN traite de plusieurs pathologies (dont une incluse dans les lignes génériques), l'industriel peut candidater sur les deux parcours. Les différents dossiers correspondants sont indépendants et peuvent être déposés simultanément. Dans le cas où des preuves seraient communes, merci de le signaler à l'ANS afin de pouvoir optimiser le traitement des dossiers.