Depuis le 2 novembre 2026, les données des professionnels de santé ne seront plus accessibles depuis le site https://service.annuaire.sante.fr

Elles sont désormais téléchargeables uniquement depuis le site suivant : https://www.data.gouv.fr/organizations/agence-du-numerique-en-sante/datasets

L’obligation de disposer d’un agrément ou d’un certificat de conformité mentionnée à l’article L.1111-8 du code de la santé publique s’applique à toute entité qui propose un service d’hébergement :

• portant sur des données de santé à caractère personnel recueillies à l'occasion d'activités de prévention, de diagnostic, de soins ou de suivi social et médico-social ;
• pour le compte du patient ou pour le compte des professionnels de santé, des établissements et services de santé et tout autre organisme réalisant des missions de prévention, de soins, de suivi médico-social et social à l’origine de ces données.

Dans le cas d'un dispositif médical numérique dont les établissements de santé, le client de l'exploitant du DMN héberge lui-même les données de santé à caractère personnel et n'est pas obligé d'avoir un certificat hébergeur de données de santé. (voir : question 2 Explicitation du champ d’application du cadre juridique de l’hébergement de données de santé par le ministère chargé de la Santé, représenté par la Délégation à la stratégie des systèmes d’information de santé.

Oui, Pro Santé Connect utilise l'Annuaire Santé pour les professionnels de santé utilisateur du DMN. L'Annuaire Santé permet d'accéder à l'ensemble des professionnels des secteurs santé et médico-social.  PSC est un moyen d'authentification sécurisé et doit permettre l'accès  seulement aux professionnels de santé avec un numéro RPPS valide et vérifié.

Oui, json peut être considéré comme un format d'export valide pour la portabilité.
Pour rappel, il n'est pas demandé un dump de la base de données, mais bien un export des données sous un format quelconque (json, csv, xml …). Le DMN doit permettre l'export des données à tout moment.

Comme noté à la page 14 du référentiel 1.2.2 : « Le Référentiel d’Interopérabilité et de Sécurité des Dispositifs Médicaux Numériques (DMN) exige une méthode d’authentification des usagers à 2 facteurs. Le Système doit donc implémenter cette méthode d’authentification (exigence IEU 9.1). » Le développement de la double authentification est donc obligatoire pour un DMN s'il y a un accès patient, et c’est une exigence qui sera vérifiée par l’ANS.

Par contre, il est également indiqué : « Pour tenir compte du cas où l’activation de l’authentification des usagers à 2 facteurs diminue l’usage de la solution et entraîne une perte de chance pour l’usager, le fabricant du DMN peut sous sa responsabilité ne pas activer systématiquement l’authentification à deux facteurs. ». Cela signifie que l’activation du double facteur peut ne pas être systématique pour l’ensemble des patients. Ce point est de la responsabilité de l'entreprise du numérique en santé développant le DMN.

Enfin, il est précisé dans le scénario IEU 9.1 : « L'accès du patient à une interface de déclaration simple dans le cadre d'un parcours de télésurveillance n'est pas soumis à ce scenario de conformité et ne nécessite pas d'authentification à deux facteurs systématique. » . Cela signifie que dans le cadre d’une déclaration simple, c’est-à-dire dans le cas où un patient accède à un simple formulaire de saisie de données (hors du DMN),  il n’est pas soumis au développement du double facteur.

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

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.

C’est en effet l’ANS qui fournit les cartes CPx et certificats logiciel pour le téléservice INSi. Ils sont à commander directement auprès de l’ANS.

Voici ci-dessous les informations pour obtenir ces éléments :

• Pour les cartes de test CPS/CPE, la demande est à orienter vers le formulaire suivant
  Téléchargez le formulaire
• Pour les certificats logiciels, nous vous invitons à lire cette page qui vous donnera la procédure
  Consultez la page dédiée aux certificats 

L'exigence IEU 1 : "Le Système DOIT imposer la vérification des attributs d'identité de l'Usager au moment de la création du compte par l'Utilisateur" s'applique pleinement même sans accès aux professionnels de santé.
Lorsqu'il n'y a pas d'accès aux professionnels de santé, il n'y a pas de vérification de l'identité du patient.
Toutefois, il ne s'agit pas d'une vérification de l'identité du patient, mais de la vérification des attributs du patient nécessaires à la création de son moyen d'identification électronique (MIE).
Un processus doit être mis en place dans le but d'inviter le patient à confirmer l'exactitude des attributs renseignés.

Par exemple : Une déclaration de l’exactitude des attributs renseignés (ex : par une case à cocher) ou une étape de validation des attributs renseignés.

De même pour l'exigence IEU 2 :  "Le Système DOIT n'autoriser la modification de ses attributs d'identité par un Usager qu'avec des informations obtenues par une vérification d'identité aussi fiable que lors de l'enregistrement initial". 
Un processus doit être mis en place dans le but d'inviter le patient à confirmer l'exactitude des attributs modifiés.

Par exemple : Une déclaration de l’exactitude des attributs renseignés (ex : par une case à cocher) ou une étape de validation des attributs renseignés.
 

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

Les exigences IEU 5 et IEPS 6 "Le Système DOIT permettre d'imposer le renouvellement d'un Moyen d'Identification électronique (MIE) à une fréquence paramétrable selon le type de MIE." portent principalement sur le paramétrage d’une fréquence de renouvellement des MIE.

Aucun délai n'étant imposé par la réglementation, il est possible de proposer une fréquence par défaut en adéquation avec le contexte d'intervention de la solution. Il peut ainsi être accepté que la fréquence de renouvellement soit paramétrée dans un délai plus long.

Oui, si la fiche patient dans laquelle est indiqué le médecin traitant est stockée sur le Système en cours dévaluation. En effet, dans ce cas, le médecin traitant associé au patient est bien un correspondant. Ce médecin traitant doit être créé sur le système : soit en tant que correspondant, soit en tant qu'usager. L’essentiel est qu’il soit identifié avec son n°RPPS ET associé au patient. Les exigences ANN 3 et ANN 5 sont applicables et doivent être respectées.

Un document type est demandé dans le cadre de la certification, dès la première étape de recevabilité.

Le système doit permettre la mise à disposition de l’ensemble des données de santé ainsi que les informations des correspondants qu’il traite. Le format du ou des fichiers mis à disposition doit être lisible, exhaustif, exploitable, et documenté par l’industriel. 

La portabilité concerne les données patient mais ne concerne pas le paramétrage.

Pour rappel, l'exigence IEU 6 : "Le Système DOIT permettre à un Usager de révoquer l'accès par l'un de ses MIE", comporte 2 scénarios de conformité :

SC1 - Révoquer un MIE sans se connecter au système

Le système doit répondre au scénario de conformité en proposant un moyen de révocation pour chaque MIE mis à disposition, sans se connecter au système.

Exemples (non exhaustif) :

• Si le mot de passe est compromis : proposer un lien "mot de passe oublié" afin de permettre à l'usager de réinitialiser son mot de passe.
• Si le téléphone est perdu : l'usager peut orienter l'envoi de l'OTP sur son email enregistré au préalable. Une fois connecté, il pourra changer le numéro de téléphone.
• Si l'accès à l'email est perdu : l'usager peut orienter l'envoi de l'OTP sur son numéro de téléphone enregistré au préalable. Une fois connecté, il pourra modifier l'adresse email.

Remarque : Ce scénario est applicable par défaut pour chaque MIE. Exception pour les MIE utilisant un service externe ou une fédération d’identité (exemple : FranceConnect), ce scénario n’est pas applicable.

SC2 - Révoquer un second MIE une fois connecté au système

Le système doit répondre au scénario de conformité en proposant un moyen de révocation pour chacun de ses MIE en se connectant par un de ses autres MIE non compromis.

Exemple : 

• Mon système propose l’utilisation de clés FIDO comme MIE, une clé nominale et une clé de secours. Dans le cas de la perte/vol de la clé FIDO à usage nominal, la clé FIDO de secours doit permettre de se connecter et ainsi de révoquer la clé FIDO perdue.

Les scénarios applicables dépendent donc du nombre de MIE proposés par le système :

• Dans le cas où le système ne dispose que d'un seul MIE, seul le scénario 1 est applicable car l'accès au compte devient impossible dès lors que le MIE est compromis.
• Dans le cas où le système dispose d'au moins 2 MIE, les scénarios 1 et 2 sont applicables.