La docrine des pouvoirs publics

Les pouvoirs publics, une doctrine, vraiment ?

Ceux qui comme moi ont suivi de près, et depuis l’origine, les mésaventures du projet DMP peuvent douter de la capacité des « pouvoirs publics » à définir une « doctrine », ou plus simplement une orientation, concernant l’évolution souhaitable de l’informatique de santé. L’expression « pouvoirs publics » est un cache-misère pour un ensemble disparate de centres de décision (DGOS, ASIP-Santé, CNAM) dans les couloirs desquels on entend trop souvent des énormités révélatrices d’une incompétence ou d’une incurie qui laissent rêveur.

Cela dit, une décision importante a été prise juste avant les élections d’avril-mai 2017 : le décret du 27 mars 2017 met fin à plus de vingt ans de tergiversations en modifiant le code de la santé publique afin de rendre applicable la loi qui prévoit l’utilisation du NIR (autrement dit du numéro de Sécurité Sociale) pour l’identification des patients. Rappelons que dans la période précédente c’était interdit. Mine de rien, c’est une petite révolution. J’aime à penser que mon ancien camarade AL y est sans doute pour quelque chose…

Le décret du 27 mars 2017

Voici le lien : https://www.legifrance.gouv.fr/eli/decret/2017/3/27/AFSZ1630941D/jo/texte.

La mise en application effective d’une telle décision prendra du temps : « Les professionnels, établissements, services et organismes […] sont tenus de se mettre en conformité […] avant le 1er janvier 2020 ».

Que faire d’ici là ? Les pouvoirs publics ont-ils émis des recommandations de bonnes pratiques ? – La réponse est oui.

Le Guide méthodologique pour les GHT

Sur le sujet qui nous intéresse (la problématique de l’identification des patients dans un contexte multi-établissements, sans attendre l’adaptation des systèmes d’information en vue de l’utilisation du NIR), il y a un texte de référence qui tient la route. Pour être plus précis, il y a dans un texte de référence qui porte sur un sujet plus vaste (les GHT), des passages qui portent sur le sujet qui nous intéresse, et qui méritent qu’on en tienne compte.

Voici le lien : http://social-sante.gouv.fr/IMG/pdf/dgos_guide_systeme_information_convergent.pdf

Le passage qui nous intéresse est la fiche 2.3.2 : « Opérer le rapprochement et la fusion des identités patients en amont de tout rapprochement fonctionnel ».

Inutile de paraphraser ce texte qui est déjà synthétique, et qui est relativement bien rédigé. Lisez-le avant de passer à la suite.

Notion se serveur de rapprochement

« Le serveur de rapprochement est un outil de l’identitovigilance. Des serveurs de rapprochement d’identités sont disponibles sur le marché. […] Son rôle est de fiabiliser l’identification des patients dans les SI et lors des échanges. »

« La fonctionnalité de recherche s’effectue par une requête multicritère comportant l’un des IPP du patient et le domaine correspondant. La recherche transmet la liste des identités rapprochées provenant des différents domaines. »

Mine de rien, cela met fin à plusieurs idées fausses qui ont embrouillé bien des initiatives dans les périodes précédentes :
• On ne reste pas en attente de l’identifiant national qui sera effectivement utilisable… un jour.
• On ne tombe pas non plus dans le piège d’un « identifiant régional » (ou emprunté au CHU, ou spécifique au GHT) qui serait utilisable « tout de suite »… sans qu’on sache comment l’intégrer dans les SI existants.

Au lieu de cela, on ajoute dans le paysage de l’existant un nouvel outil, le serveur de rapprochement, dont le déploiement ne « casse » pas les systèmes existants, et dont les fonctionnalités facilitent la mise en oeuvre de scénarios d’échanges et de partage de données de santé, au seul coût de développement d’interfaces aussi simples que possible.

Idéalement, les API des serveurs de rapprochement devraient être standardisées. Cela permettrait :
• Aux éditeurs de logiciel de développer une seule version de leurs interfaces.
• Aux maîtrises d’ouvrage de pouvoir éventuellement changer de serveur de rapprochement sans obliger les éditeurs de logiciels à déployer des mises à jour.

La bonne nouvelle, c’est que non seulement les standards existent, mais aussi et surtout ils sont maintenant explicitement cités dans le texte de référence des pouvoirs publics.

Les standards référencés

Profils « identité » IHE :
• PAM : diffusion d’identités et de mouvements
• PIX : rapprochement entre identités
• PDQ : recherche d’identités.

Voyons cela de plus près : http://www.ihe.net/uploadedFiles/Documents/ITI/IHE_ITI_TF_Vol1.pdf

Patient Administration Management (PAM) concerne les systems that need to be able to provide current information regarding a patient’s encounter status and location. Autrement dit, PAM met le focus sur les « mouvements », plus que sur l’identité proprement dite.

Patient Identifier Cross-referencing (PIX) supports the cross-referencing of patient identifiers from multiple Patient Identifier Domains. Autrement dit, PIX semble être exactement ce dont nous avons besoin.

Patient Demographics Query (PDQ) provides ways for multiple distributed applications to query a patient information server for a list of patients, based on user-defined search criteria. Autrement dit, PDQ aide à récupérer un identifiant quand on n’en a aucun, alors que dans les scénarios qui nous intéressent on a généralement déjà un identifiant, celui qui est utilisé dans l’organisation où on est.

Je ne dis pas qu’il ne fallait pas référencer PAM ni PDQ. Ces deux profils sont pertinents dans de nombreux cas d’utilisation où on cherche à résoudre certains problèmes d’identification patient. D’ailleurs en tant qu’informaticien j’ai des raisons de penser qu’on pourrait sans doute reconstruire les fonctionnalités de PIX en faisant une utilisation un peu poussée des possibilités de PAM et/ou de PDQ. Mais pourquoi chercher midi à quatorze heure ? – C’est PIX qu’il nous faut.

Les buts recherchés

Dans la fiche 2.3.2 du Guide méthodologique, sont précisés les mécanismes de rapprochement et les indicateurs qualité.

Cela implique de mettre de l’intelligence non seulement dans le serveur de rapprochement, mais encore dans les solutions qui s’interfacent avec le serveur de rapprochement. Mettre en œuvre IHE PIX rend cela possible, mais ne suffit évidemment pas – c’est une condition nécessaire et non suffisante. A vue de nez, le développement d’interfaces PIX représente moins de 10 % du travail de développement.

J’aime assez les indicateurs qualité :
• Taux de doublons créés.
• Nombre de fusions.
• Taux de modifications d’identités.
• Nombre de collisions détectées.

Et le NIR dans tout ça ?

Le NIR identifie essentiellement une personne, et pas spécifiquement un patient. Dans les système d’information existants, le NIR ne va pas simplement remplacer l’IPP. Les identifiant locaux vont persister longtemps, ne serait-ce que pour gérer l’historique, et les structures des bases de données vont devoir être modifiées pour y ajouter le support du NIR.

Comment gérer la transition ? Comment accompagner la « nirisation » des applications ?

J’ai décidé d’essayer de contribuer à la construction de réponses pragmatiques à ces questions. Prochaines étapes :
• Durant l’été 2017 j’aurai quelques entretiens approfondis avec différents acteurs clés à l’échelle régionale, en Normandie ou ailleurs.
• Mercredi 6 septembre 2017 je participerai la deuxième réunion du groupe de travail Interop’Santé FHIR GT1 / Gestion administrative du patient.