Introduction
Être référentiel d’identité ou ne pas l’être ? Telle est la question. Elle est sur les lèvres de beaucoup d’industriels aujourd’hui quand il s’agit de définir la stratégie de mise en conformité avec le référentiel d’intéroperabilité de l’ANS. Ce choix est primordial, il impacte toutes les strates des solutions numériques :
- Roadmap : 30 exigences à rajouter soit près de 30% du référentiel
- Backend : ajout de logique pour gérer les INSq
- Produit : ajout d’une étape de validation pour chaque patient
Il n’existe pas une règle absolue qui réponde à cette question, la décision doit se faire au cas par cas. Mais alors, comment savoir quelle stratégie adopter ? Cet article vous propose, sur la base des projets que nous avons fait chez Hokla, des pistes de pensée pour y répondre.
Le référentiel d’identité, c’est quoi ?
Comme présenté dans cet article sur l’accès à la prise en charge de droit commun ou anticipée (PECAN), l’obtention de la certification de conformité avec le référentiel d’intéropérabilité de l’ANS est une étape obligatoire pour accéder au remboursement de votre solution numérique. Une des plus grosses briques à mettre en place pour cela est l’identité nationale de santé (INS) des patients.
Pour résumer l’INS en quelques mots, c’est un identifiant accolé à chaque patient qui permet de l’identifier de manière unique sur chacune des plateformes numériques en France. Comme expliqué dans cet article, il permet par exemple d’identifier le patient dans l’envoi de data dans le DMP.
Il est composé du matricule INS (son numéro de sécurité sociale la majeure partie du temps), son nom de naissance, son prénom de naissance, sa date de naissance et son lieu de naissance. La question qui se pose le plus souvent pour les industriels est : comment récupère-t-on cet INS ? Doit-on le créer ? Comment ?
Pour être utilisé dans les applications de santé, l’INS doit être qualifié, c’est à dire qu’il doit être récupéré dans les bases de données nationales de la CNAM et que l’identité du patient doit être validée à l’aide d’un document d’identité (CNI, Passeport, Permis, etc …). Concrètement, c’est ce que vous faîtes quand vous vous enregistrez à l’hôpital : le secretariat rentre vos informations puis vérifie votre identité avec une pièce d’identité. Cette validation permet de s’assurer que le patient est correctement enregistré, cela évite toute erreur liée à un mauvais remplissage des informations par le médecin par exemple. Mais est-ce pertinent de refaire cette opération pour chaque solution numérique utilisée par les médecins ?
C’est tout l’enjeu du concept de référentiel d’identité, ne pas demander à chaque solution d’effectuer ce travail administratif tout en s’assurant de la véracité des INS utilisés dans les solutions. Ainsi, les solutions référentiels d’identité sont les seules tenues de réaliser ces vérifications, ce sont également les seules habilitées à diffuser les INS. Les solutions qui ne le sont pas doivent consommer les INS produits par lesdits référentiels d’identités. Pour la liste exhaustive des solutions référentiels d’identité, elle sont disponibles ici.
Comment savoir si votre solution doit être référentiel d’identité ou pas ?
Être référentiel d’identité peut être très embêtant pour les logiciels de santé. En effet, la qualification de l’INS demande au professionnel de santé de téléverser un document prouvant l’identité du patient via sa carte d’identité ou son passeport. Pourtant, le plus souvent, l’enjeu de ces solutions est de lui faire gagner du temps dans sa prise en charge or cette étape de validation d’identité est très chronophage et met en péril la rétention des utilisateurs professionnel de santé. De plus, les solutions référentiel d’identité doivent respecter une trentaine d’exigence en plus ce qui alourdit des roadmaps déjà pleines.
Dans ce contexte, qui peut éviter d’être référentiel d’identité ? Et quand on ne peut pas l’éviter, comment réduire cette charge pour l’utilisateur prescripteur ?
Les solutions qui doivent être référentiel d’identité
Deux types de solutions ont vocation à être référentiel d’identité :
- Les fournisseurs de solutions de Gestion Administrative des Malades (GAM/GAP), outils qui facilitent et optimisent la gestion administrative liée aux patients;
- Les fournisseurs de solutions de Dossier Patient Informatisé (DPI) maîtresses de l’identité patient pour le Système d’Information Hospitalier (SIH), outils qui gèrent de manière centralisée l'identité des patients dans les systèmes d'information de santé.
Ainsi, tout autre type de solution (DTx, Télésurveillance ..) n’ont pas vocation à générer de nouvelles identités et doivent plutôt se placer comme consommateur d’INS via des services externes qui sont RI. Néanmoins, récupérer l’identité de ces patients via des services externes multiples et aux contraintes spécifiques parfois lourdes, peut ressembler à un vrai parcours du combattant, heureusement il existe des solutions pour s’abstraire d’une partie de ce travail
Comment récupérer les INS ?
Dans l’expérience de nos projets, nous avons souvent eu à répondre à cette question. Globalement, trois types de fonctionnement semble se démarquer:
- Si votre solution est déployée dans quelques structures de santé, vous pouvez choisir de consommer les INS depuis chaque SI de ces structures en leur laissant la charge administrative qui est, de facto, déjà dans leurs processus d’onboarding;
- Si votre solution est déployée dans beaucoup de structures de santé, intégrer toutes les interactions est souvent très fastidieux, vous pouvez alors vous tourner vers une solution comme Lifen qui vous permet de récupérer de manière agnostique (via un seul endpoint) les informations patient présentes dans tous les SI;
- Si vos utilisateurs recoupent ceux d’une autre solution de santé partenaire, elle-même certifiée RI, vous pouvez consommer les INS depuis ladite solution
Si votre solution ne rentre dans aucun de ces use cases, pas de panique ! Il existe une dernière solution qui permettra d’intégrer les INS qualifiés de vos patients sans gêner l’expérience utilisateur des professionnels de santé.
Qualifier l’INS: comment ne pas répugner les utilisateurs ?
L’exigence INS 25 nous dit: “Le Système DOIT attribuer le statut "identité qualifiée" à toute identité pour laquelle l'identité de l'usager a été vérifiée sur la base d'un dispositif à haut degré de confiance et a été créée/mise à jour sur la base du retour d'INSi, conformément à la règle n°20 du guide d'implémentation”, mais que veut dire un dispositif à haut degrés de confiance ?
Le référentiel national d’identitovigilance décrit un dispositif à haut degrés de confiance comme étant: “[…] les titres d’identité suivants : le passeport, la carte nationale d’identité (pour les ressortissants de l’UE), le livret de famille ou un d’extrait d’acte de naissance […] On range également dans cette catégorie les dispositifs d’identification électroniques apportant un niveau de garantie « substantielle » selon la norme eIDAS.”
Ainsi, un INS peut être qualifié en utilisant France Connect pour le compte patient. Cette manière n’apporte aucune charge supplémentaire pour le professionnel de santé et permet au patient d’utiliser une authentification nationale pour se connecter à votre solution.
👉 Vous avez des questions pour votre solution ? Hokla vous accompagne dans la mise en conformité avec le cadre d’interopérabilité de l’ANS (CI-SIS), pour qu'elle soit prise en charge par l’Assurance Maladie dès 2023.
.png)
.jpg)