Intégrer l'INS (Identité Nationale de Santé) dans votre application

De toutes les briques du socle français, l’INS est celle que les équipes sous-estiment le plus systématiquement. Vue de loin, c’est un identifiant national — un champ de plus dans la table patient. Vue de près, c’est un modèle de données à part entière, avec des statuts, des transitions et des obligations de traçabilité.

Ce que contient réellement une INS

L’Identité Nationale de Santé est composée de deux éléments :

• le matricule INS, qui correspond au NIR ou au NIA ;
• cinq traits d’identité : nom de naissance, prénom(s) de naissance, date de naissance, sexe, lieu de naissance.

Ces cinq traits ne sont pas des métadonnées confortables : ce sont les traits de référence. Ils ne se substituent pas au nom d’usage ni au prénom utilisé au quotidien, qu’il faut donc gérer en parallèle. Une application qui écrase le nom d’usage avec le nom de naissance dégrade l’expérience de ses utilisateurs et se met en difficulté vis-à-vis de l’identitovigilance.

La notion de qualification, et pourquoi tout en découle

L’usage de l’INS pour référencer les données de santé est obligatoire depuis le 1er janvier 2021. Mais l’obligation ne consiste pas à stocker un numéro : pour être utilisée à des fins médicales, l’INS doit être qualifiée, ce qui suppose deux conditions cumulatives :

1. une identité validée conformément au référentiel national d’identitovigilance (RNIV) ;
2. une récupération ou vérification via le téléservice INSi.

C’est cette double condition qui transforme l’INS en machine à états. Une identité peut exister sans être validée, être validée sans avoir été confrontée à INSi, ou avoir été récupérée puis devenir douteuse. Votre application doit porter ce statut, l’afficher aux professionnels, et adapter son comportement — notamment ce qu’elle autorise à transmettre vers l’extérieur.

Les conséquences concrètes sur votre application

Un modèle de données à repenser, pas à étendre

Il ne s’agit pas d’ajouter une colonne ins. Il s’agit de distinguer votre identifiant technique interne, l’identité déclarée par le patient, l’identité de référence issue de l’INS, et le statut qui relie les trois. Les applications qui ont tenté l’ajout minimal ont presque toutes dû reprendre leur modèle.

Une politique de rapprochement explicite

Que se passe-t-il quand INSi retourne une identité qui diffère de celle saisie à l’accueil ? Quand deux dossiers de votre base correspondent à la même INS ? Quand un patient est enregistré avant d’avoir pu être qualifié ? Ces cas ne sont pas des exceptions : ce sont le quotidien de l’exploitation, et ils doivent être traités dans le produit, pas dans des procédures manuelles.

Une traçabilité opposable

Les opérations de récupération et de vérification doivent être traçables. Cela signifie une journalisation dédiée, conservée, et exploitable en cas de contrôle — un sujet d’architecture, pas d’écran.

Appeler INSi suppose une autorisation, pas une clé d’API

C’est le point que les équipes techniques découvrent le plus tard, souvent après avoir développé l’intégration.

Le CNDA — Centre National de Dépôt et d’Agrément, rattaché à l’Assurance Maladie — délivre l’autorisation d’appeler le téléservice INSi. Elle est conditionnée à l’acceptation d’un contrat d’accès, demandé via la plateforme SICNDA.

S’y ajoutent les moyens nécessaires à la recette : certificats de test, pour valider votre implémentation technique, et cartes CPx de test, pour effectuer des appels de démonstration. Les uns et les autres se commandent, ce qui prend du temps.

Le parcours éditeur publié par G_NIUS se déroule en six étapes :

1. prendre connaissance de la documentation socle ;
2. mettre en place l’environnement pour les développements ;
3. développer l’appel au téléservice INSi ;
4. faire évoluer le logiciel pour être conforme au guide d’implémentation ;
5. assurer l’interopérabilité ;
6. déployer la solution et former ses clients.

Deux enseignements pratiques. D’abord, la démarche administrative — contrat d’accès, certificats, cartes de test — conditionne l’étape 2, donc tout le reste : elle se lance avant le développement, pas après. Ensuite, la formation des clients figure explicitement au parcours, ce qui n’est pas un détail : l’INS introduit des statuts d’identité et des règles de rapprochement que vos utilisateurs devront comprendre et appliquer au quotidien.

Attention enfin à ne pas confondre les guichets : le CNDA couvre les téléservices de l’Assurance Maladie, tandis que le raccordement à Pro Santé Connect relève de l’ANS. Ce sont deux démarches distinctes, à mener en parallèle.

Pourquoi c’est la brique à traiter en premier

Nous recommandons systématiquement de traiter l’INS avant Pro Santé Connect, avant MSSanté, avant tout le reste. Non parce qu’elle est plus urgente, mais parce qu’elle est la seule dont les conséquences remontent jusqu’au schéma de base de données.

Un raccordement à Pro Santé Connect ajouté tardivement coûte des semaines. Une INS ajoutée tardivement coûte une reprise de données, une migration, et la révision de tous les flux qui manipulent une identité patient — c’est-à-dire, dans une application de santé, à peu près tous.

Les référentiels à connaître

Trois documents structurent le sujet : le référentiel INS, le RNIV — décliné en quatre volets sectoriels — et le guide d’implémentation destiné aux éditeurs. Ce dernier est le plus directement utile à une équipe technique, et devrait être lu au cadrage, pas au moment de la recette.