Immersion en interopérabilité

Je m’appelle Ismaël FOURGEOT, je suis étudiant en 2^e année de Bachelor Universitaire de Technologie (BUT) en informatique et j’effectue actuellement un stage au sein du département technique du GCS e-Santé Bretagne.       
Durant ces 10 semaines, j’ai effectué des missions variées. Je vous emmène avec moi pour découvrir les trois principales !

Le changement d’architecture technique du ROR

La technique

Le Répertoire Opérationnel des Ressources (ROR) est un référentiel contenant toutes les informations sur les établissements de santé de Bretagne (adresses, responsables, services, contacts…). Le ROR regroupe l’offre de santé d’un territoire donné. Il est possible de récupérer et modifier ces données pour les utiliser dans d’autres services d’e-santé afin d’avoir une offre de santé à jour. L’architecture actuelle du ROR a besoin d’améliorations, notamment depuis la mise en place de ses dernières versions. Cela permettra de répondre aux enjeux de l’interopérabilité mais également à ceux du déploiement du ROR. En effet, l’objectif est de modifier l’architecture pour apporter plus de contrôle et de sécurisation sur l’accès aux informations du ROR, tout en tenant compte des contraintes techniques demandées par la Direction Générale de l’Offre de Soins (DGOS) et l’Agence du Numérique en Santé (ANS).

Ma contribution

Une solution avait été envisagée avant mon arrivée pour changer l’architecture du ROR : utiliser un reverse-proxy pour améliorer la sécurité des échanges avec le ROR. Un reverse-proxy est l’équivalent d’un réceptionniste dans un hôtel qui prend les demandes des clients et les transmet au personnel approprié, assurant ainsi un service efficace et sécurisé.
Ainsi, la première étape était de prendre en main le logiciel Traefik (le reverse-proxy utilisé par le GCS e-Santé Bretagne) afin de pouvoir construire l’architecture voulue avec la bonne configuration.

Pour ce faire, j’ai créé un environnement fictif sur mon ordinateur afin de reproduire à plus petite échelle la configuration finale : le reverse-proxy qui renverra les demandes venant des applications externes (les clients, comme les autres ROR ou le ROR national) vers les deux API du ROR (interne et interopérabilité). Néanmoins pour effectuer ces tests il est nécessaire de posséder un document que l’on ne peut obtenir qu’avec une Carte Professionnel de Santé (CPS) fournie par l’ANS : le certificat IGC Santé qui doit être présenté sur le ROR, qui est la pièce d’identité du ROR. Une fois la carte reçue, j’ai continué les tests jusqu’à obtenir le résultat souhaité. J’ai transmis les tests à mon équipe, qui prend le relais pour la phase de production.

Automatisation et tests des flux d’envoi de disponibilité en lits

La technique

Dans le ROR, la disponibilité des lits de chaque établissement est renseignée. C’est une donnée cruciale car elle permet de savoir rapidement dans quel établissement transférer des patients. Certains établissements communiquent les disponibilités des lits par messagerie sécurisée de santé, vers l’EAI du GCS e-Santé Bretagne (application qui va traiter les messages reçus pour les transmettre au ROR).

Actuellement, le GCS e-Santé Bretagne migre ses flux d’envois automatisés de disponibilité en lit d’un ancien EAI vers un nouveau. Il est important de vérifier que toutes les fonctionnalités restent inchangées lors de la migration. Pour ce faire, il faut réaliser des tests sur l’ancienne version puis les reproduire sur la nouvelle et vérifier que les résultats sont concordants. La réalisation de ces tests est une étape indispensable mais chronophage.

Ma contribution

J’ai commencé par lister les cas à tester pour chaque fonctionnalité que j’ai enregistré dans un cahier de tests. Il doit contenir tous les cas possibles, y compris (et surtout) les cas aux limites : ceux qui fonctionnent (un établissement avec un FINESS qui est valide, envoie des disponibilités en lits qui sont légitimes). Mais aussi tous ceux qui ne fonctionnent pas (établissement avec un FINESS invalide, disponibilité en lits négative, le service qui possède des lits qui n’existe pas dans le ROR, etc.). Pour chacun des cas de tests, j’ai créé les différents messages correspondants : ce sont des fichiers XML qui sont envoyés au travers de la Messagerie Sécurisée de Santé (MSS) par les établissements à l’EAI du GCS e-Santé Bretagne, pour que celui-ci les traite. J’ai ensuite commencé à réaliser une brique qui automatise l’envoi des fichiers de tests, pour ne pas réaliser ces opérations à la main, et ainsi gagner du temps, puis pour pouvoir les rejouer autant de fois que nécessaire.

Guichet unique d’appel des services du GCS e-Santé Bretagne par des applications tierces

La technique

Le GCS e-Santé Bretagne a pour projet de partager certains de ses services comme l’Annuaire (liste de tous les professionnels et établissements de santé de Bretagne) avec d’autres acteurs ; seulement l’architecture actuelle du réseau ne permet pas de le faire facilement. Du moins, pas d’une manière sécurisée conforme aux dernières exigences de la Politique Générale de Sécurisation des Systèmes d’Information de Santé (PGSSI-S)

Voici l’ancienne architecture :

• Les services utilisés sont directement ouverts sur Internet, ce qui augmente la surface d’attaque ;
• Chaque service possède ses propres méthodes de sécurité. Certains demandent une authentification utilisateurs, d’autres demandent de présenter un certificat (une pièce d’identité virtuelle), etc.

L’objectif serait de mettre en place un reverse-proxy : un tampon entre Internet et les services, qui servirait aussi d’aiguilleur. Les services seront donc tous accessibles à la même adresse et auront la même base de sécurisation. Ce qui permettra de simplifier le partage des informations et services avec nos partenaires externes (mise à disposition d’API pour des applications tierces), tout en centralisant et simplifiant la configuration pour le GCS e-Santé Bretagne.

• Les accès aux services se font part un intermédiaire : ils ne sont donc pas directement exposés sur Internet
• Le reverse proxy gère l’identification client pour tout le monde, les paramètres sont donc centralisés.

Ma contribution

Un reverse-proxy (encore !) avait déjà été déployé par le GCS e-Santé Bretagne. Ma mission était de renforcer la sécurité sur l’accès à ce reverse-proxy. Ce renforcement s’est fait en intégrant une obligation pour les applications tierces : présenter un certificat pour accéder aux services (en conformité avec les exigences de la PGSSI-S). Si l’application tierce ainsi que le certificat associé sont bien présents dans une liste d’applications autorisées, alors l’accès aux services du GCS e-Santé Bretagne est accepté.

Durant un peu plus d’une semaine, j’ai modifié l’ancienne configuration jusqu’à ce que les vérifications voulues puissent être réalisées sur chaque service. J’ai également rédigé une documentation expliquant comment se connecter, ajouter des noms à la liste d’applications autorisées et modifier des paramètres de configuration. Les tests sur le reverse-proxy, qui sert de guichet unique, ont été réalisés, laissant place à la production.

Ces trois principales missions ont rythmé mon stage au sein du GCS e-Santé Bretagne. En les réalisant, j’ai pu apporter ma pierre à l’édifice et tester mes compétences avec les équipes.