← Retour au blog
Innovations & SIH

Construire des Intégrations santé avec le standard FHIR et des Serverless functions.

Lifen a développé une solution basée sur une IA afin de fluidifier les échanges de documents médicaux.

Temps de lecture :
4
minutes

Lifen a développé une solution basée sur une Intelligence Artificielle afin de fluidifier les échanges de documents médicaux entre les hôpitaux, les professionnels de santé et les patients.

Nous nous sommes connectés à de nombreux systèmes de santé (DPI/DMP, GAM), en déployant progressivement notre solution au sein des hôpitaux français, afin de recevoir de la donnée sur notre plateforme.

Mais avec un volume de données en constante augmentation et de nouvelles logiques à gérer chaque semaine, le besoin de protéger notre API contre la saturation devenait nécessaire.

Pour y faire face nous avons dissocié d'une part notre capacité à recevoir un volume important de données brutes et d'autre part notre logique de transformation de la donnée et de mapping en FHIR grâce à un système de fil d'attente asynchrone.

C'est notamment l'un des rôles des solutions d'intégration ou des EAI (Entreprise Application Interface) : ce sont des middleware, présents dans chaque système de santé, qui gèrent l'intégration des flux de données de santé entre les différentes applications.

De nombreuses entreprises ou Openprojects proposent des solutions d'EAI. Pourtant, il n'est pas forcément évident pour une start-up de choisir entre créer sa propre solution ou en acheter une :

  • Nous n’avons aucune idée du nombre potentiel d'intégrations dont nous aurons besoin
  • Ces solutions sont souvent basées sur une technologie ou un langage obsolète ;
  • Elles peuvent être complexes à déployer et à maintenir ;
  • Elles ne sont pas forcément compatibles avec les standards et profils français et sont rarement personnalisables (par exemple, nos processus de NLP et d'IA sont difficilement compatibles avec des solutions d'EAI).

De ce fait, lors de notre première intégration à un SIH, nous avons décidé de commencer avec des logiques développées en interne et de les connecter directement à une architecture Simple Queue Service.

Comme nous avions déjà créé une plateforme performante basée sur un serveur FHIR pour notre produit initial, nous avons décidé de construire nous-même une EAI cloud-based par dessus notre logique FHIR. Notre implémentation se compose de trois éléments principaux :

  • Des Serverless functions nécessaires pour nos critical business functions ;
  • La Device resource qui représente la sollicitation d'un Software externe ;
  • Un event messaging system afin de tout connecter ensemble avec une architecture scalable.

Pas à pas, nous avons ajouté des librairies afin de gérer les protocoles HL7 V2 et MLLP et d'autres formats datés qui sont encore largement utilisés au sein des systèmes de santé. Mais la nécessité d'automatiser, contrôler et structurer nos connecteurs devenait de plus en plus urgente alors même que nous étions déjà connectés à plus d'une centaine d'établissements de santé.

La magie des Serverless functions (alias Lambdas)

En règle générale, les Serverless functions n'ont qu'un seul but : héberger des fonctions programmées dans une infrastructure dédiée. Face au manque d'infrastructures certifiées en France, nous avons construit notre propre serverless Framework en NodeJs. À chaque fois qu'une ressource FHIR est créée ou mise à jour, un event est envoyé afin de déclencher l'exécution des Lambda functions. Elles peuvent capter, transformer, filtrer ou envoyer des messages à d'autres applications.

Facile à construire : La particularité d'une intégration au système de santé réside dans le nombre de différences de fonctionnement de chaque système. Avec ce type de code, il est facile d'adapter un Lambda et de le déployer en quelques secondes.

Les hôpitaux peuvent envoyer des milliers et des milliers de messages HL7 V2 : Il est presque impossible de les gérer en même temps. Nous utilisons donc notre serveur FHIR comme mémoire tampon des messages bruts envoyés. Notre système d'event messaging nous permet de démarrer le processus si et seulement si notre système est disponible.

Cela nous permet de garder les messages dans le bon ordre et de nous assurer d'une bonne délivrabilité. Dans le cas où notre serveur est occupé, une relance est automatiquement gérée par notre système d'event messaging.

Un des bénéfices des serverless functions est qu'elles sont « scalables ». Chaque fonction est entièrement autonome et indépendante. Avec une bonne solution d'alertes, il est assez facile de détecter le moment où une lambda commence à être en difficulté afin de déployer plus d'instances.

Lifen au coeur de l'interopérabilité entre les différents acteurs de la santé

Découvrez le projet Soigner Ensemble

Comment mapper des objets avec FHIR ?

Nous utilisions la Device Resource pour représenter un connecteur à un software avec l'hôpital et ses paramètres. On configure le format de la source et du destinataire et les réglages du protocole et du réseau. On définit aussi les filtres et les traitements dont nous avons besoin.

Par exemple, nous avons un Device qui nous permet d'intégrer un document au sein d'un EHR avec un format HL7 MDM via un channel SFTP :

  • Nous envoyons (avec une Communication) un DocumentReference avec un Device comme destinataire ;
  • Une Lambda function (représentée par un cercle) est déclenchée ce qui permet de transformer l'objet FHIR en un message HL7 DMD ;
  • Une autre Lambda prend le message HL7 et écrit le dossier en un dossier SFTP.

Workflow de l'envoi de message HL7 dans un EHR

https://gist.github.com/JulieDu/3e1154661aa22954901c67c029fc97c2#file-ehr-device-sample

Dans le cas où nous avons à présent une multitude de Devices, voici un autre exemple , où un type Device est dédié à la capture de HL7 V2 ADT (Admit, transfer, discharge notification) :

Un Workflow pour recevoir un message HL7 depuis un EHR

  • Tout d'abord, une lambda function écoute le socket et crée un message brut sur notre serveur (Binary et MessageHeader) ;
  • Ensuite, une autre lambda est déclenché pour extraire les informations de ce message, les mapper à FHIR et créer des ressources dans le serveur ;
  • Une fois le traitement terminé, l'état du MessageHeader est mis à jour et un accusé de réception est envoyé au fournisseur de données.

Aujourd'hui, nous sommes encore au début de cette aventure. Pourtant, nous pouvons déjà ressentir la puissance de cette architecture et nous serions ravis d'échanger avec vous si vous souhaitez partager vos expériences sur ce sujet.

Les ressources en lien:

Article originel, traduit par Luc Hébrard: https://medium.com/lifen-engineering/building-scalable-healthcare-integrations-with-fhir-and-serverless-functions-fbbe4a24aaf1

Julie Dumons

Interoperability Product Manager @Lifen. Julie est spécialiste sur les sujets d'interopérabilité et anime la communauté FHIR France.

Découvrez nos autres articles

Essayez Lifen dès maintenant

Inscription

Renseignez vos informations en 2 minutes.

Installation

Installez Lifen en moins de 5 minutes.

Votre compte est validé

Commencez à utiliser les différentes solutions Lifen.