.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 :
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 :
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é.
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.
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 :
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) :
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
