Journal de stage en interopérabilité

Je m’appelle Baptiste Guilbert, je suis étudiant en 4^e année d’ingénierie pour la santé à l’École Supérieure d’Ingénieurs de Rennes (ESIR) et j’effectue actuellement un stage de 4 mois au sein de l’équipe Projets interopérabilité e-santé du GCS e-Santé Bretagne.

Passionné par le numérique et le domaine de la santé, j’ai pu découvrir l’année dernière l’interopérabilité en e-santé, la sécurisation des données et le respect du RGPD lors d’un précédent stage au GCS e-Santé Bretagne. Fort de cette première expérience, j’ai donc décidé d’approfondir mes connaissances et de développer mes compétences en interopérabilité lors de ce nouveau stage sous la tutelle de Clotaire Delanchy, chef de projets interopérabilité.

Ma mission cette année ?
Contribuer à la mise en œuvre du service de partage numérique régional « Cercle de Soins » et venir en support de l’équipe sur les différentes missions de la partie « interop ».

Je vais retracer dans ce journal, les missions réalisées ici, mois par mois, jusqu’à mon départ. Une belle immersion en interopérabilité !

Mois 1

Datavizh en périnatalité
Pour répondre à la saturation des services de réanimation des établissements de santé,​ causée par la crise sanitaire il y a 2 ans, le GCS e-Santé Bretagne a mis en place Datavizh, un service de visualisation de la disponibilité des lits des structures de santé, à destination de l’ARS Bretagne et des établissements de santé en Bretagne.

À l’écoute de ses usagers et de leurs besoins sur le terrain, le GCS e-Santé Bretagne a répondu à leur demande en mettant en place un tableau de bord dédié au Réseau Périnatalité Bretagne, afin de pouvoir comparer plusieurs établissements de santé en même temps, en analysant rapidement les places dans les services d’obstétrique et de néonatalogie.

Dans un 1^er temps, j’ai dû me familiariser avec l’environnement de travail : la technologie web et la base de données utilisée pour ce projet étant Node.js et MySQL. Ensuite, il m’a fallu prendre en main le code existant : rédiger une liste de question à l’équipe, échanger avec le chef de projet en charge du Répertoire Opérationnel des Ressources (ROR)…

Une fois le code devenu plus familier, j’ai commencé les 1^ères modifications : d’abord, en améliorant la prise en compte de certains paramètres, puis en réglant un problème de communication avec le ROR. En effet, ce dernier nous renvoyait des disponibilités saisies il y a trop longtemps, en plus des nouvelles disponibilités. Ce problème entrainait des soucis d’affichage sur Datavizh et certains éléments de la cellule de périnatalité étaient non visibles ou comprenaient de mauvaises valeurs.

(Et la partie technique !)

J’ai donc ajouté une fonctionnalité paramétrable de gestion de la fraîcheur de la date, pour fixer une date de mise à jour maximale et filtrer les résultats pour n’afficher que les éléments dont la date de mise à jour était plus récente.

Enfin, j’ai effectué des ajouts supplémentaires au code, permettant à certains éléments qui n’en disposaient pas de façon correcte, de récupérer leurs capacités de lits installés et du nombre de lits disponibles.

Ainsi, nous pouvions donc comparer plusieurs établissements de santé en même temps, en analysant rapidement les places dans les services d’obstétrique et de néonatalogie sur le tableau de bord dédié au Réseau Périnatalité Bretagne sur Datavizh.

Mois 2

Service de partage numérique régional de données de santé
Le GCS e-Santé Bretagne souhaite mettre en œuvre un service de partage numérique régional du Cercle de Soins, qui repose sur le volet « gestion du Cercle de Soins » du Cadre d’Interopérabilité des Systèmes d’Informations en Santé (CI-SIS) de l’ANS.

Ce service a pour but de permettre à des professionnels de santé de créer, mettre à jour et de consulter le cercle de soins d’un usager à travers différentes applications de coordination. Le cercle de soins d’un usager peut être défini comme l’ensemble des personnes, professionnels et structures intervenant dans sa prise en charge dans le domaine sanitaire, médico-administratif, médico-social et social. Le volet du CI-SIS s’appuie sur le standard FHIR pour partager la donnée du Cercle de Soins.

Dans un 1^er temps, j’ai effectué des recherches pour savoir si notre cas correspondait à un entrepôt de données de santé, car si c’était le cas il aurait fallu respecter les exigences définies dans le référentiel “entrepôt” de la CNIL. Après avoir présenté le résultat de mes recherches et soulevé ce point avec l’équipe, nous en avons conclu que nous n’étions pas dans le cas d’un entrepôt de données de santé, mais plutôt dans le cas d’un service de partage numérique régional.

(Et la partie technique !)

Nous avons décidé de réaliser un PoC (Proof of Concept) de ce service de partage du Cercle de Soins, avec un serveur FHIR open-source  connu avant de le mettre sur notre infrastructure de tests dédiée. Ce serveur HAPI FHIR nous permettra donc de réaliser des essais techniques et d’anticiper les éventuels problèmes auxquels nous aurons à faire face lors du développement du service de partage dans sa version finale.

Je suis donc en train de réaliser et de documenter les différentes étapes nécessaires à la mise en place d’un serveur HAPI FHIR, comme la prise en compte des ressources du Cercle de Soins (patient, cercle de soins, praticien, organisation…), ou encore la mise en place de validateurs pour vérifier que les données que l’on enregistrera dans le service de partage seront bien conformes au volet du CI-SIS correspondant.

Mois 3

J’ai continué à documenter les différentes étapes nécessaires à la mise en place d’un serveur HAPI FHIR, et me suis plus particulièrement penché sur l’ajout des validateurs.
Pour comprendre le fonctionnement d’un validateur, il est bon de savoir que dans le cadre du volet « Gestion du Cercle de Soins » des ressources FHIR (comme les ressources patient, cercle de soins, praticien, organisation…) ont été profilées pour le contexte français par l’ANS et Interop’Santé.
En effet, elles peuvent avoir des différences avec celles utilisées à l’international : en France par exemple, il est désormais obligatoire que chaque personne dispose d’une INS (Identité Nationale de Santé), ainsi la ressource patient devra obligatoirement contenir un champ dédié.

Comme énoncé plus haut, le validateur va donc vérifier que les données que l’on envoie sur le service de partage sont bien conformes aux profils français définis dans les spécifications techniques du volet « Gestion du Cercle de Soins ».

Cette partie fût plus longue et compliquée que prévue ! La documentation n’étant pas suffisamment détaillée et les exemples trouvés en ligne ne correspondant pas toujours à notre situation, je n’arrivais pas à une solution fonctionnelle.

Nous avons décidé de nous former de façon plus approfondie auprès de Luc Chatty (expert FHIR) qui nous a épaulé pour mieux comprendre les subtilités et les étapes nécessaires pour déployer un serveur HAPI FHIR.

Une première version des validateurs a ainsi pu être ajoutée.
Pour être capable de vérifier la conformité des données, il était nécessaire de charger les profils (patient avec spécificités françaises, etc.) au sein des validateurs, pour que ceux-ci puissent savoir à quels concepts se référer lors de la validation.
Au départ, ces profils étaient chargés un à un, ce qui obligeait à écrire plusieurs fois le même bout de code pour chaque ressource, et à les remodifier si changements. J’ai donc implémenté une fonctionnalité d’ajout automatique permettant de les charger depuis un unique dossier.

(Et la partie technique !)

Pour vérifier le bon fonctionnement des validateurs, j’ai utilisé l’outil Postman qui permet d’envoyer des requêtes HTTP afin de tester une API, ici notre service de partage numérique.
Nous y avons donc créé, avec ma collègue Céline Gach, une collection de requêtes HTTP de tests pour l’ensemble des flux (création, modification, recherche et consultation). Ces tests permettent par exemple de vérifier que la création d’un patient ou d’un praticien se fait de façon correcte (avec tous les champs nécessaires), permettant ensuite de les réunir au sein d’un cercle de soins, etc.

Cette collection de requêtes correspond aux tests du projectathon technique ANS effectués en mars 2022 pour le Cercle de Soins, ainsi qu’à des requêtes supplémentaires pour tester notre service de partage numérique dans son ensemble.

En parallèle, nous avons également effectué des modifications au script de notre serveur HAPI FHIR pour avoir la capacité de valider l’ensemble des tests, et optimisé ces ajouts par la suite.

J’ai également optimisé l’exécution des tests sur Postman, car dans une première version il était nécessaire d’envoyer les requêtes une à une et dans un ordre précis pour récupérer « manuellement » une valeur (comme l’identifiant d’un patient par exemple) pour la réutiliser dans une ou plusieurs requêtes suivantes (pour indiquer que tel praticien s’occupe de tel patient par exemple), ce qui est très chronophage !

J’ai donc configuré les requêtes pour récupérer et stocker ces valeurs de manière automatique… un vrai gain de temps. J’ai ensuite configuré l’exécution automatique de toutes ces requêtes dans un ordre précis, nous permettant de tester rapidement le bon fonctionnement des modifications apportées à notre serveur HAPI FHIR.

Ces modifications ont permis de réduire le temps passé à l’exécution des tests, en passant de plus de 5 minutes à une 1 minute 30.

Nous disposons maintenant d’un serveur HAPI FHIR de gestion du Cercle de Soins fonctionnel, avec les validateurs en place, et de quoi tester son fonctionnement de façon automatisée, ce qui correspond aux contours du PoC attendu.

Il me reste désormais à rédiger les spécifications techniques de notre service numérique de partage au niveau régional, pour qu’elles servent de base de développement lors de la mise en production.

Mois 4 (et le dernier…)

(Et déjà la partie technique !)

La rédaction des spécifications techniques a pour objectif de présenter un cas d’usage d’interopérabilité entre les services de coordination et le service de partage numérique Cercle de Soins et de fournir l’ensemble des éléments permettant sa mise en œuvre au sein de l’environnement numérique du GCS.

Le PoC précédemment réalisé m’a donc été utile et m’a permis de renseigner plusieurs parties de ces spécifications. Cependant le service Cercle de Soins qui sera mis en place à la suite du PoC a des contraintes supplémentaires, que ne possédait pas ce dernier. Comme l’authentification des applications tierces qui utiliseront le service numérique, la sécurisation des flux, ou encore des informations concernant la protection des données (durée de conservation et purge des données, etc.).

Ces spécifications seront utiles en interne pour comprendre de façon explicite les besoins et contraintes liées au projet, et pour les éditeurs et développeurs, afin de l’implémenter conformément aux caractéristiques attendues.
J’y ai ainsi renseigné, entre autres, les prérequis avant déploiement, l’outillage utilisé, les documentations de références, les données d’intérêt et la gestion des requêtes HL7 FHIR, ainsi que des informations concernant la validation des données et des profils.

J’ai pu également décrire de façon détaillée l’architecture générale du service Cercle de Soins à l’aide de diagrammes de séquences (représentation graphique des interactions entre les acteurs) et de tableaux descriptifs des flux, afin de préparer le cahier de tests et d’être sûr de n’oublier aucun cas problématique lors du développement.

Exemple concernant la consultation d’un Cercle de Soins

J’ai ensuite échangé avec le DPO (délégué à la protection des données) du GCS e-Santé Bretagne (Gilles Larroche), concernant la supervision et la purge de gestion de données du service Cercle de Soins.

Les données seront donc conservées pendant la durée prévue par les dispositions légales et règlementaires applicables à la conservation des dossiers médicaux, à savoir :

• 20 ans à compter de la fin du suivi de coordination
• 10 ans à compter de la date du décès de l’usager
• jusqu’au 28 ans de l’usager, si la durée de conservation des données de l’usager mineur s’achève avant

Nous avons également soulevé des pistes de réflexion quant au mécanisme automatique de suppression des données.

Un élément important de réflexion dans ces spécifications techniques porte sur la cohérence des données des professionnels et structures enregistrées dans le Cercle de Soins avec celles connues de nos autres référentiels régionaux (Annuaire Régional, ROR) et au niveau national (Annuaire Santé).

En effet, nous pensons utiliser l’Annuaire Santé pour vérifier l’existence des professionnels de santé et avoir des informations à jour avec le national au sein de notre Cercle de Soins. Je me suis intéressé à cette partie plus particulièrement, pour bien comprendre son fonctionnement.

L’annuaire Santé

L’ANS (Agence Nationale de Santé), vient récemment de déployer IRIS-DP, un nouveau service permettant au grand public de consulter les données en accès libre de l’Annuaire Santé au format JSON, structurées selon le standard d’interopérabilité FHIR.

J’ai donc regardé comment il fonctionnait en utilisant l’outil Postman, en lui envoyant différentes requêtes HTTP et en regardant en détail les données reçues. Ce service nous permet d’obtenir des informations sur le professionnel de santé et sur son organisation, comme son nom et prénom, sa profession, sa spécialité, sa structure d’exercice actuelle, etc.

Il sera donc utile pour notre service Cercle de Soins, en récupérant toutes ces données, qui compareront et écraseront celles contenues dans les informations du professionnel de santé du cercle de soins créé, ce qui assurera leur bonne conformité.

Et c’est la fin, déjà…

Pour clôturer mon stage, j’ai présenté une synthèse des missions effectuées et échangé avec mes collègues, pour m’assurer de la bonne transmission de ces informations à mon départ.

Je souhaite remercier Romain Lemoine, directeur du GCS e-Santé Bretagne, pour m’avoir accueilli durant mes 4 mois de stage. Je témoigne également toute ma reconnaissance à mon tuteur de stage Clotaire Delanchy, chef de projets e-santé interopérabilité, pour ses conseils, son accompagnement et pour m’avoir accordé sa confiance sur l’ensemble des missions qui m’ont été attribuées. Et enfin, je remercie ma collègue Céline Gach, cheffe de projets e-santé interopérabilité, ainsi que toute l’équipe pour leur professionnalisme et leur accueil.

Cette immersion au sein de l’équipe interop’ fut une expérience très enrichissante et pleine d’intérêts, qui m’a permis de conforter mon futur projet professionnel d’ingénieur dans le domaine de la santé et plus particulièrement dans l’interopérabilité.