Gestion des téléchargements de fichiers médicaux patients (PDF/images) en cours de conversation dans un flux de triage multi-étapes Telegram/WhatsApp

Aidez-moi à Construire mon Flux de Travail
1

Bonjour à tous,

Je développe une automatisation sans code pour un système d’accueil et de triage en tourisme de santé, et j’aimerais bien des conseils de la communauté sur la partie gestion des fichiers du flux.

CONTEXTE / CE QUI FONCTIONNE DÉJÀ :

  • Telegram Trigger reçoit les messages texte des patients.
  • Un nœud IA (Claude) analyse le message, détecte la langue, le traduit, et retourne un résultat de triage structuré en JSON (spécialité suggérée, niveau de confiance, informations manquantes).
  • Airtable stocke les Médecins / Patients / Dossiers et est utilisé pour acheminer le dossier vers le bon spécialiste.
  • Le reste du flux fait suivre la réponse du médecin au patient, et génère plus tard un code de suivi et envoie le dossier complet à un système externe via un webhook.

CE DONT J’AI BESOIN D’AIDE MAINTENANT :
Je veux étendre l’étape d’accueil pour que les patients puissent télécharger leurs dossiers médicaux et résultats de tests (PDF et images) directement dans la même conversation Telegram/WhatsApp, pas par le biais d’un formulaire séparé, pour que tout le dialogue de triage reste dans un fil de discussion continu.

Spécifiquement, je cherche des conseils sur :

  1. Meilleures pratiques pour capturer à la fois les types de messages document et photo de Telegram Trigger dans une seule branche (plutôt que de construire des chemins séparés pour message.document vs message.photo).

  2. Approche recommandée pour télécharger le fichier (file_id Telegram) dans n8n et le passer à une étape OCR ou IA capable de vision pour l’extraction de texte — faut-il utiliser un nœud OCR dédié, ou est-ce que passer directement l’image/PDF à un nœud LLM capable de vision est plus fiable pour les documents médicaux ?

  3. Comment d’autres gèrent le mélange de plusieurs types d’entrée (texte libre + pièces jointes) dans le même tour de conversation avant d’envoyer le tout au nœud d’analyse IA comme un seul payload combiné.

  4. Des conseils sur le stockage temporaire des fichiers téléchargés (par exemple, gestion des données binaires, ou envoi vers le stockage cloud) avant qu’ils ne soient attachés au dossier du patient dans Airtable.

  5. Puisque cela implique des données de santé personnelles sensibles, des motifs recommandés pour gérer le chiffrement/la conservation des fichiers téléchargés dans un flux n8n seraient très utiles.

Je fais fonctionner cela sur n8n.cloud. Je serais ravi de partager plus de détails sur la structure du flux si c’est utile. Tous les conseils, flux d’exemple ou recommandations de nœuds seraient très appréciés.

Merci d’avance !

2

Salut @Hossein_Nikounam, en attendant une réponse, voici quelques ressources qui pourraient t’aider :

Ressources suggérées

Automatiquement associé à ta question.

Documentation :

Forum :

@withabdul, @mohamed3nan, @fahmiiireza - vous avez déjà aidé avec des problèmes similaires, vous pouvez jeter un coup d’œil ?

Suggéré automatiquement par le bot communautaire de n8n. C’est un essai pilote - veuillez partager vos commentaires ici.

3
  1. Telegram envoie ces éléments sous forme de champs séparés (message.document vs message.photo), donc utilisez une expression juste après le déclencheur pour les normaliser en une seule valeur avant de brancher davantage : {{ $json.message.document?.file_id || $json.message.photo?.[$json.message.photo.length - 1]?.file_id }} (les photos sont envoyées sous forme de tableau de tailles, prenez la dernière/la plus grande). Alimentez ce file_id unique dans un seul nœud Telegram « Get File » quel que soit le type.
  2. OCR vs vision LLM : Pour les documents médicaux, je préférerais les envoyer directement à un LLM capable de vision plutôt qu’à un nœud OCR dédié. L’OCR seul vous donne du texte brut mais perd la mise en page/la structure (tableaux de valeurs de laboratoire, champs de formulaire), et un modèle de vision peut raisonner directement sur cette structure. L’OCR dédié vaut la peine d’être ajouté uniquement si vous rencontrez des problèmes de coût ou de fiabilité à grande échelle, ou si vous avez besoin d’une extraction de texte garantie et déterministe pour une étape basée sur des règles en aval.
4
  1. Mélanger du texte et des fichiers en un seul tour : N’essayez pas de tout forcer dans un seul appel IA par message Telegram. Conservez un buffer par cas (une ligne de tableau de données ou un enregistrement « Case » Airtable indexé par chat_id) qui accumule le texte et les références de fichiers au fur et à mesure de leur arrivée, et déclenchez le nœud d’analyse IA une seule fois explicitement (par exemple, le patient envoie « done » / un délai d’attente / un nombre fixe d’entrées attendues).
    1. Stockage temporaire : Les données binaires d’n8n ne persistent que pendant la durée d’une seule exécution, elles ne se conservent pas entre les événements de déclenchement distincts dans une conversation. Téléchargez via Get File, puis envoyez immédiatement vers un vrai stockage cloud (S3/GCS/Azure Blob) et conservez simplement l’URL/la référence dans votre enregistrement de cas Airtable, ne tentez pas de maintenir les données binaires dans n8n entre les tours.
1 « J'aime »
5
  1. Chiffrement/rétention des données de santé protégées : C’est celui-ci que je signalerai comme étant plus important qu’une simple question de conception de flux, vous transmettez des données de santé via Telegram/WhatsApp, ce qui soulève de véritables questions de conformité adjacentes à la HIPAA/RGPD (accords de traitement des données, limites de rétention, si les propres conditions de Telegram/WhatsApp permettent même la transmission de données de santé protégées) qui sont des décisions juridiques/conformité, et non une configuration n8n. Techniquement : activez le chiffrement côté serveur sur votre bucket de stockage, définissez des politiques explicites de cycle de vie/rétention, et vérifiez les paramètres de journalisation de n8n pour que les données binaires/informations personnelles identifiables ne soient pas conservées dans les journaux d’exécution plus longtemps que nécessaire. Je vous recommande véritablement de faire intervenir un conseiller en conformité avant que cela ne soit déployé avec de vrais patients, pas seulement de sécuriser les canaux.
1 « J'aime »
6

Bonjour @Hossein_Nikounam Bienvenue !

Trois points pratiques qui posent problème spécifiquement avec les documents médicaux via Telegram.

Les téléchargements de bot sont limités à 20 Mo par getFile. Les dossiers numérisés et les PDF multipages dépassent cette limite plus souvent que vous ne le penseriez, et il n’y a rien que vous puissiez faire du côté n8n. Cela vaut la peine de décider d’avance si vous indiquez aux patients la limite ou si vous leur proposez un lien de téléchargement alternatif pour les fichiers plus volumineux.

Si un patient envoie un rapport de laboratoire sous forme de photo, Telegram le recompresse et le petit texte dans les tableaux devient illisible. Même l’entrée la plus grande dans message.photo est compressée. Pour tout ce qui contient des chiffres, vous voulez qu’ils l’envoient sous forme de fichier à la place, qui arrive en tant que message.document intact. Cela compte probablement plus pour la précision de votre modèle de vision que le modèle que vous choisissez.

Et si quelqu’un envoie plusieurs images à la fois, Telegram les livre comme des mises à jour séparées partageant un media_group_id, vous obtenez une exécution par image plutôt qu’une pour le lot. Une autre raison du buffer que Sergey a mentionné, et l’utilisation de media_group_id comme clé vous permet de les recoudre ensemble.

7

C’est un schéma résolvable — voici comment j’aborderais la partie gestion des fichiers.

**Recevoir des fichiers binaires de Telegram au cours d’une conversation**

Quand un patient envoie un document ou une photo à votre bot Telegram, le déclencheur se déclenche avec un objet `document` ou `photo` contenant un `file_id`. Vous avez besoin d’une extraction en deux étapes :

1. **Obtenir le chemin du fichier :** Nœud Requête HTTP → `GET https://api.telegram.org/bot{TOKEN}/getFile?file_id={file_id}\` → retourne `result.file_path`

2. **Télécharger le fichier :** Nœud Requête HTTP → `GET https://api.telegram.org/file/bot{TOKEN}/{file_path}\` → définir le format de réponse sur **Fichier** (binaire)

Après l’étape 2, vous avez un élément binaire dans n8n que vous pouvez diriger directement vers Google Drive ou convertir pour Airtable.

**Stocker le fichier**

- **Google Drive :** Utilisez le nœud Drive → Télécharger, en passant le binaire. Vous obtenez en retour un ID de fichier que vous pouvez stocker dans votre mémoire de session ou un enregistrement Airtable.

- **Pièce jointe Airtable :** Airtable attend un tableau d’objets `{url: “…”}` dans les champs de pièces jointes. Téléchargez d’abord vers Drive (ou tout stockage accessible publiquement), puis passez l’URL à Airtable. Vous ne pouvez pas pousser directement du binaire brut dans les pièces jointes Airtable.

**Maintenir l’état de la conversation entre les messages**

Puisque chaque message Telegram déclenche une nouvelle exécution de workflow, vous avez besoin d’un état externe. Le schéma courant :

- Utilisez Airtable ou une simple base de clés-valeurs (Redis, même une Feuille Google) indexée par `chat_id`

- À chaque déclenchement, recherchez l’enregistrement existant pour ce `chat_id`, fusionnez la nouvelle référence de fichier, mettez à jour l’enregistrement

- Votre étape LLM/triage lit l’enregistrement complet (y compris toutes les références de fichiers) avant de décider de l’action suivante

**Remarque HIPAA :** S’il s’agit de données réelles de patients, n8n.cloud stocke les données de workflow sur son infrastructure. Cela vaut la peine de vérifier si cela s’aligne avec vos exigences de conformité — n8n auto-hébergé vous donne un contrôle complet de la localité des données.

Je serais heureux d’approfondir l’une de ces étapes.

8

La mécanique ci-dessus est correcte, donc ceci n’est que la partie qui change parce que les fichiers sont des dossiers médicaux.

L’URL de téléchargement Telegram porte votre jeton de bot dans le chemin : api.telegram.org/file/bot/<file_path>. Quiconque détient cette URL détient le jeton, et le jeton contrôle complètement le bot. Donc stocker cette URL, ou la transmettre à Airtable comme source de pièce jointe, envoie votre jeton de bot à un tiers et dans tous les journaux et sauvegardes qu’il conserve. Téléchargez le fichier à l’intérieur de n8n, chargez les octets vers votre propre stockage, et laissez l’URL Telegram expirer avec l’exécution.

Le même raisonnement, un pas plus loin. Une URL de pièce jointe qui s’ouvre sans identifiant est une copie du document plutôt qu’un pointeur vers celui-ci. Pour les dossiers de patients, le modèle qui résiste à l’examen est un stockage d’objets privé avec une URL signée générée au moment de la consultation et une courte expiration, de sorte que l’accès devient un événement que vous pouvez enregistrer et révoquer.

Un détail de Cloud qui est facile à oublier : vos exécutions sont une deuxième copie de tout. Les références binaires, le texte extrait et l’entrée du nœud IA se trouvent tous dans les données d’exécution, de sorte que la liste des exécutions devient un stockage de documents de patients. Dans les Paramètres du flux de travail, ne sauvegardez rien pour les exécutions de production réussies et conservez les exécutions d’erreur uniquement aussi longtemps que vous en avez réellement besoin.

Sur la question de conformité que Sergey a soulevée, d’accord c’est l’élément plus important. Cela vaut la peine de vérifier dès le départ si les conditions de Telegram et WhatsApp Business permettent cette catégorie de données dans votre juridiction, car cette réponse peut changer le canal d’intake, et le changer maintenant coûte moins cher qu’après le premier vrai patient.