Ingestion directe de documents mobiles vers OpenClaw : Flux de travail santé iOS vers Raspberry Pi

Un développeur sur r/openclaw a documenté un modèle expérimental pour envoyer directement des documents depuis un client mobile iOS vers une instance locale d'OpenClaw fonctionnant sur un Raspberry Pi. L'objectif est de numériser des documents comme des résultats de laboratoire ou des ordonnances sur un téléphone et de les faire arriver dans OpenClaw pour un traitement en aval, sans intermédiaires cloud ni téléchargements manuels.

Vue d'ensemble de l'architecture

Le système utilise une approche à deux couches : le téléphone agit comme couche de capture, et OpenClaw sert de couche de traitement. Le client mobile est conçu pour être entièrement local et respectueux de la vie privée, sans dépendance au cloud et sans services d'IA externes. Il utilise la reconnaissance optique de caractères d'Apple (Vision) et l'intelligence embarquée pour l'extraction et la recherche, en conservant les documents bruts et le contenu extrait sur l'appareil, sauf s'ils sont explicitement envoyés vers OpenClaw.

Appairage et configuration

Un flux d'appairage par QR code évite une configuration manuelle. La charge utile du QR code est un objet JSON encodé en base64 généré sur la machine OpenClaw avec cette structure :

{ "url": "wss://", "bootstrapToken": "", "hooksToken": "", "agentId": "", "hookPath": "/hooks/rkive" }

Le hooksToken est stocké dans le trousseau iOS, la configuration non sensible est dans le stockage local, et l'URL wss:// est convertie en https:// pour les requêtes d'envoi.

Flux de données

Le client mobile iPhone envoie une requête POST à /hooks/rkive avec un jeton Bearer ({hooksToken}) et une charge utile JSON contenant un PDF encodé en base64. Cela arrive sur l'instance OpenClaw (Raspberry Pi, sur le réseau local ou VPN), qui exécute un script de transformation ingest_rkive.py. Ce script enregistre le PDF original dans health-records/originals/, met à jour ou insère un enregistrement d'index dans health-records/index.jsonl, et gère l'assemblage par morceaux et le nettoyage en cas d'interruption. Un agent de santé dédié gère ensuite le traitement en aval : reconnaissance optique de caractères → validation → sortie structurée.

Décisions de conception clés

• Agent dédié dans OpenClaw : Une configuration multi-agents inclut un agent de santé dédié responsable de l'ingestion des documents, de la validation et de la structuration en aval, en isolant les flux de travail liés à la santé.
• Point de terminaison dédié : L'utilisation d'un point de terminaison fixe comme /hooks/rkive au lieu d'un routage dynamique via agentId garantit un routage déterministe, évite une mauvaise classification accidentelle et simplifie la logique côté serveur.

Flux de travail en aval et questions ouvertes

Le flux de travail en aval est en cours de développement. Comme la reconnaissance optique de caractères d'Apple n'est pas considérée comme fiable à 100 %, le plan prévoit de réextraire le texte en markdown propre dans OpenClaw en utilisant le flux de travail d'IA de confiance de l'utilisateur, suivi d'une étape de validation humaine pour la vérification du contenu, l'extraction structurée en ressources de type FHIR, l'ajout à un ensemble de données longitudinal et la fourniture d'informations sur la santé.

L'auteur pose deux questions ouvertes pour les retours de la communauté : 1) Si ce modèle semble utile en pratique pour un usage régulier ou s'il est trop contraignant, et 2) Ce que les gens voudraient qu'OpenClaw fasse avec les dossiers de santé personnels une fois ingérés, en suggérant des idées comme des chronologies d'événements longitudinales, la détection de lacunes (par exemple, des suivis manqués) et des résumés périodiques.