Middleware Yoctobe
Middleware d'intégration d'instruments médicaux
Une passerelle unique pour tous vos automates. Elle reçoit les données de chaque instrument — HL7, ASTM, FHIR ou fichier — et les transmet au SIL sous forme structurée. Les flux déjà validés pour les automates que nous avons connectés ailleurs se déploient en quelques clics.
Pour qui
Cliniciens, responsables de laboratoire et équipes techniques
Le clinicien attend le résultat au dossier avant la visite. Le responsable de laboratoire veut une file unique, pas une dizaine d'utilitaires fournisseur, et une mise en service dans des délais maîtrisés. L'ingénieur biomédical ou l'informaticien veut voir le message, la correspondance des champs et la cause d'un blocage — sans attendre une intervention à distance du constructeur.
Le middleware Yoctobe remplit ce rôle. Il s'insère entre les instruments et le système déjà en place. Il ne remplace ni le SIL ni le DPI. Il unifie les échanges entre le plateau technique et le système d'information.
Protocoles
Chaque automate a son protocole. Le middleware traduit.
Compteur d'hématologie, ligne de biochimie, automate d'immunologie qui exporte uniquement des fichiers Excel, glucomètre de service, DPI récent exigeant le FHIR : les formats ne coïncident jamais. Multiplier les connecteurs point à point à chaque nouveau modèle devient ingérable. La passerelle reçoit chaque flux, le normalise et transmet un résultat structuré au système cible.
HL7
Standard de messagerie hospitalière. Les commandes sortent sous forme de listes de travail ; les résultats reviennent en observations. Au lit du malade, la prescription signée correspond à l'analyse réellement effectuée. Pour les équipes informatiques, c'est en général HL7 v2 sur MLLP/TCP : messages ORM/ORU (ou l'équivalent attendu par votre SIL), acquittements, identifiants patient et échantillon maintenus de bout en bout pour éviter toute confusion au dossier.
Même si votre SIL accepte déjà le HL7, la passerelle reste nécessaire. Un automate n'émet pas un message hospitalier standard tel quel : ordre des segments, codage, unités et répétitions varient selon le modèle et la version du firmware. Le middleware normalise ces données avant validation biologique.
ASTM
Protocole encore largement utilisé par les automates de laboratoire — ASTM E1381/E1394 et normes apparentées CLSI LIS1/LIS2. Liaison série, USB-série ou TCP. Trames, sommes de contrôle, téléchargement des ordonnances, remontée des résultats. Le clinicien n'interagit jamais avec l'ASTM. Le responsable de laboratoire constate que l'ancien automate peut rester en service sans un PC dédié au logiciel constructeur. L'ingénieur consulte les trames, identifie les erreurs de somme de contrôle et relance la transmission après une coupure de liaison.
ASTM en entrée et HL7 ou FHIR en sortie : configuration courante dans les laboratoires hospitaliers. C'est précisément le rôle du middleware, pas celui d'un script ponctuel.
FHIR
Lorsque la destination est un DPI ou un SIH récent : demandes (ServiceRequest), résultats (Observation), identifiants alignés sur le modèle du système cible. Le FHIR n'est pas un argument marketing : c'est le format que nous produisons quand le système clinique n'accepte pas une trame brute d'automate.
La même passerelle, une sortie adaptée au DPI. L'automate peut rester en ASTM ou HL7 ; le dossier hospitalier reçoit une ressource exploitable et affichable.
Fichiers — CSV, Excel, TXT, XML
Certains instruments ne s'ouvrent jamais en réseau. Ils déposent des fichiers dans un répertoire partagé : CSV à chaque série, export Excel, fichier texte ou paquet XML. Le middleware surveille ce répertoire, lit le fichier, fait correspondre colonnes ou balises au résultat normalisé, puis transmet au SIL. Plus de ressaisie manuelle. Plus de rupture de chaîne parce que le fichier n'a pas été déposé.
Si deux fichiers arrivent pour le même échantillon, le middleware détecte le doublon. Si une colonne change après une mise à jour logicielle, la correspondance échoue de façon explicite — et non sous la forme d'une valeur erronée au dossier.
Bibliothèque
Des flux déjà validés. Déployés en quelques clics.
Nous maintenons une bibliothèque de flux prêts pour les instruments déjà interfacés — plus de 300 automates en hématologie, biochimie, immunologie, anatomopathologie et analyse au point de soins. Si votre modèle figure dans cette bibliothèque, nous ne partons pas de zéro : nous sélectionnons le flux, l'adaptons à votre SIL et validons en parallèle. Le calendrier se raccourcit sensiblement — quelques jours, et non un projet qui dépasse la durée de vie de l'automate.
Déjà dans la bibliothèque
Modèle déjà connecté ailleurs : le flux est prêt. Déploiement en quelques clics, puis contrôles parallèles sur les données en conditions réelles avant bascule en production.
Nouveau modèle
Nous le connectons. Nous construisons le flux une fois, le validons sur votre plateau technique, puis il rejoint la bibliothèque. Le site suivant qui installe le même automate en bénéficie.
Deuxième site, même parc
Un groupe qui déploie la même ligne d'hématologie dans un autre établissement ne finance pas un second projet d'intégration. Il réutilise le flux existant. Seule la correspondance vers le SIL local reste à configurer.
Parc hétérogène
HL7 sur un poste, ASTM sur un autre, dépôt fichier en sérologie : une seule passerelle, une vue d'exploitation unifiée. Chaque instrument conserve son flux dans la bibliothèque.
Un automate complexe que nous n'avons jamais rencontré peut être mis en production en environ trois jours si le protocole est documenté et le système cible identifié. Si nous avons déjà livré cette interface, indiquez le modèle dès le premier contact : le délai doit être nettement plus court.
Exploitation
Traçabilité complète. Correction immédiate.
Un middleware qui échoue sans alerte est plus risqué qu'une absence d'interfaçage. Un résultat erroné sans piste d'audit pose un problème clinique et un problème d'accréditation. Le middleware Yoctobe est conçu pour être consulté, diagnostiqué et corrigé par vos équipes.
- Transparence — chaque message conserve une trace avant/après : données brutes de l'automate, message transmis au SIL, flux responsable du traitement. Aucune boîte noire entre le tube et le dossier.
- Observabilité — connectivité, débit, erreurs et profondeur des files d'attente sur une console unique. Le pic du matin apparaît comme une charge mesurable, et non comme des résultats manquants à 11 h.
- Diagnostic — somme de contrôle en échec, correspondance manquante, code inconnu, échantillon en double : le message est isolé en quarantaine avec le motif. Vous inspectez, corrigez la règle, relancez la transmission. L'échantillon n'est pas repris au patient.
- Rejeu — une coupure de liaison ou un redémarrage du SIL ne impose pas de refaire la série. Vous renvoyez les messages déjà reçus par la passerelle.
- Audit — journaux conformes aux exigences ISO 15189 : qui a transmis quoi, quand, depuis quel instrument, après quels contrôles.
Le biologiste demande où se trouve un résultat de potassium. L'ingénieur répond avec la trame et l'historique de traitement.
Votre situation
Les questions que posent les équipes
Voici les sujets qui reviennent en cadrage. La réponse est toujours la même architecture — une passerelle adaptée à votre contexte, et non un second SIL.
Nous avons déjà un SIL. Faut-il le remplacer ?
Non. Le middleware alimente Prolab LIS, Promed HIS ou le SIL déjà en place. La phase de cadrage porte sur ce qu'attend le système cible et quels instruments équipent le plateau technique.
Nos automates sont de marques différentes. Certains exportent uniquement des fichiers Excel.
Configuration fréquente. HL7, ASTM et dépôt fichier peuvent coexister sur la même passerelle. L'automate qui exporte en Excel n'impose pas un projet d'interface séparé.
L'hôpital exige le FHIR, mais l'automate transmet encore en ASTM.
L'entrée reste en ASTM (ou HL7). La sortie est convertie en FHIR — ou en HL7 — selon les exigences du DPI. Inutile de changer d'automate pour satisfaire le dossier patient informatisé.
Nous devons télécharger les ordonnances sur l'automate, pas seulement recevoir les résultats.
Les listes de travail sortent vers l'automate ; les résultats remontent. Le mode bidirectionnel est la configuration par défaut lorsque l'instrument le permet. Si un modèle ne transmet que les résultats, nous le précisons en phase de cadrage — nous n'annonçons pas une fonction que le firmware ne supporte pas.
Nous avons des appareils de service et d'analyse au point de soins, pas seulement le laboratoire central.
Les dispositifs de service et de clinique passent par la même passerelle vers Promed HIS ou un DPI tiers. L'infirmière n'a pas à ressaisir une glycémie.
Le pic du matin provoquait des pertes de messages.
Files d'attente, nouvelles tentatives automatiques et visibilité en temps réel. La charge devient un indicateur sur le tableau de bord, et non un trou silencieux dans la liste de validation.
Un résultat était erroné. Comment retracer ce qui s'est passé ?
Vous ouvrez le message concerné : données brutes, champs mappés, contrôles réussis ou échoués. S'il n'aurait pas dû être transmis, il aurait dû être en quarantaine. S'il a été transmis, le journal d'audit l'atteste. Cette traçabilité répond à la question du clinicien et aux exigences qualité.
Une mise à jour firmware a interrompu la liaison.
Le flux est sous notre responsabilité. Vous n'attendez pas un utilitaire constructeur cantonné à un ancien poste Windows. Nous ajustons la correspondance, nous retestons, nous relançons les messages en attente.
Ce modèle figure déjà dans votre bibliothèque.
Indiquez le modèle dès le premier contact. Nous déployons le flux existant, validons en parallèle, puis basculons en production. Ne budgétisez pas une interface à construire de zéro si nous avons déjà connecté cet automate.
Ce modèle n'est pas encore dans la bibliothèque.
Nous le connectons. Audit de protocole, environnement de test, exécution parallèle, bascule. Le flux rejoint ensuite la bibliothèque pour les prochains sites. Vous n'êtes pas un cas isolé.
Pouvons-nous commencer par un seul instrument ?
Oui. Un automate, une destination, puis extension progressive du parc sur la même passerelle. La bibliothèque accélère chaque connexion suivante.
Nous sommes un groupe avec plusieurs laboratoires.
Mêmes flux, destinations locales. L'exploitation centrale suit la connectivité par site. L'hématologie n'est pas réinventée dans chaque ville.
Nous fabriquons l'instrument et devons l'intégrer chez nos clients hospitaliers.
Le middleware est la voie d'accès validée vers les SIL et DPI hospitaliers — plus fiable qu'un projet sur mesure par établissement. Une fois le flux construit, chaque nouveau site est un déploiement, pas un nouveau développement.
Qui intervient en cas d'incident tôt le matin ?
Vos équipes, sur une console lisible : message, erreur, rejeu. Le support Yoctobe à Liverpool en renfort. Pas de boîte noire ni de ticket qui vieillit pendant que la liste du matin s'allonge.
Étude de cas
Interfaçage de données médicales en temps réel
Un laboratoire devait transformer les messages HL7 des automates en données structurées et les écrire dans le SIL dès la fin de la série. L'ancien chemin était lent, sujet aux erreurs, et nécessitait encore une intervention manuelle.
Architecture déployée
- HL7 en entrée — l'automate envoie les messages en TCP/IP (MLLP).
- Écoute du middleware — un listener TCP les reçoit à l'arrivée.
- Transformation — extraction des données patient et d'analyse en JSON structuré.
- Écriture — correspondance vers des mises à jour SQL sur la base du SIL.
- Résultat disponible — le clinicien ouvre le SIL : le compte rendu est déjà présent.
Envoyez la liste de vos instruments
Nous vous indiquerons ce qui figure déjà dans la bibliothèque — et donc les délais les plus courts — et ce qu'il reste à construire. Dans les deux cas, une seule passerelle.
Nous contacter
