Tout système d’information sanitaire finit par devoir communiquer avec un autre : une master facility list nationale, un échange d’informations de santé, un dossier médical électronique, une plateforme de reporting gérée par un autre partenaire. Historiquement, cela signifiait une intégration sur mesure pour chaque paire de systèmes, avec son propre format, ses propres particularités et sa propre charge de maintenance.
Les unités d’organisation de IASO, c’est-à-dire les établissements de santé, districts et zones administratives qui structurent chaque jeu de données dans IASO, sont désormais accessibles via une API conforme FHIR R4. FHIR (Fast Healthcare Interoperability Resources) est le standard d’interopérabilité de plus en plus adopté dans l’écosystème des données de santé, des dossiers médicaux électroniques aux échanges d’informations de santé, jusqu’aux registres numériques de santé nationaux. FHIR définit de nombreux types de ressources au-delà des données de localisation (patients, consultations, organisations, observations), et l’implémentation de IASO se concentre, pour l’instant, sur la ressource la plus pertinente pour un géoregistre : Location.
Concrètement, tout système compatible FHIR peut interroger la structure organisationnelle de IASO sous forme de ressources FHIR Location standard. Il peut effectuer une recherche par nom, statut, identifiant ou type d’unité d’organisation ; parcourir les unités enfants d’un établissement dans la hiérarchie ; et récupérer les coordonnées GPS, le statut de validation et les métadonnées de source, dans un format prévisible et standardisé, sans avoir besoin de comprendre au préalable le modèle de données interne de IASO. L’API est en lecture seule et nécessite une authentification : elle ne permet ni de créer, ni de modifier, ni de supprimer des données.
Concrètement, cela signifie qu’un échange national d’informations de santé ou une instance DHIS2 Suite pourrait interroger directement la liste des établissements de IASO via cette interface standard, plutôt que via un connecteur développé spécifiquement pour IASO.
Il s’agit d’une première étape centrée spécifiquement sur les données de structure organisationnelle : un accès en lecture aux unités d’organisation sous forme de Locations. C’est une base sur laquelle s’appuyer à mesure que davantage de données de IASO deviendront accessibles selon la même approche standardisée.
FHIR n’est pas apparu par hasard. Il répond à un problème que tout écosystème national de données de santé finit par rencontrer : plusieurs systèmes, chacun ayant une raison légitime de détenir des données d’établissements et d’administration, qui finissent par diverger faute d’un langage commun pour les décrire. Les deux dimensions ci-dessous expliquent pourquoi FHIR résout ce problème, et la place qu’occupe un facility registry dans l’architecture plus large construite autour de lui.
FHIR a été développé par HL7 pour donner aux systèmes de santé un langage commun et lisible par des machines pour échanger des données. Sa version R4, celle qu’implémente IASO, a atteint le statut normatif en 2019. Ce vocabulaire partagé change la nature du travail d’intégration : plutôt que chaque nouvelle connexion réinvente sa propre façon de décrire un établissement de santé (son nom, son niveau administratif, sa zone parente, sa position GPS), chaque système compatible FHIR s’accorde déjà sur la forme de ces données. Le travail d’intégration passe alors de la négociation d’un format à une simple connexion à un endpoint.
Cela compte surtout pour les organisations qui utilisent IASO aux côtés d’autres systèmes devant rester synchronisés sur la localisation des choses : une master facility list nationale, une instance DHIS2 Suite, un échange d’informations de santé plus large construit sur l’architecture OpenHIE. Dans cette architecture, le facility registry est un composant distinct que les autres systèmes interrogent plutôt que de dupliquer. Une API FHIR positionne IASO pour jouer ce rôle : une source de référence pour les données d’établissements et d’administration, que les autres systèmes peuvent consulter directement, au lieu que chaque partenaire maintienne sa propre copie.
L’API FHIR de IASO ne remplace pas les capacités de géoregistre dont les utilisateurs de IASO disposent déjà. Elle les complète.
Le géoregistre de IASO assure le suivi des versions de chaque unité d’organisation et propose des circuits de validation des demandes de modification configurables, afin que les mises à jour de la master facility list passent par une étape de validation plutôt que par une modification directe.
Les géographies sanitaires évoluent avec le temps. IASO peut maintenir plusieurs versions d’une liste d’établissements en parallèle, l’une des fonctionnalités du géoregistre aux côtés du suivi des versions et des circuits de validation des demandes de modification.
Combinées à la nouvelle API FHIR, ces capacités font de IASO une option open source solide de géoregistre pour les organisations qui ont besoin à la fois d’un contrôle rigoureux des versions de leurs données d’établissements et d’un moyen standardisé d’exposer ces données à d’autres systèmes.
Pour les équipes qui utilisent déjà IASO, cette mise à jour n’entraîne aucun changement dans l’usage quotidien. Ce qui change, c’est ce que ces données rendent désormais possible : les équipes HIS nationales peuvent désormais connecter les données d’établissements de IASO à un échange d’informations de santé ou à un autre registre compatible FHIR, sans devoir d’abord construire une couche de traduction sur mesure.
C’est aussi une première étape. L’accès en lecture aux unités d’organisation sous forme de Locations FHIR constitue une base sur laquelle s’appuyer, à mesure que davantage de données de IASO deviendront accessibles selon la même approche standardisée.
Si votre organisation construit ou étend un écosystème national de données de santé et a besoin d’un géoregistre qui parle FHIR, vous pouvez vous lancer sur IASO ou nous contacter pour plus d’informations.
