.png)
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.
.png)
