Direkte mobile Dokumentenerfassung für OpenClaw: iOS zu Raspberry Pi Gesundheits-Workflow

Ein Entwickler auf r/openclaw hat ein experimentelles Muster dokumentiert, um Dokumente direkt von einem mobilen iOS-Client in eine lokale OpenClaw-Instanz zu senden, die auf einem Raspberry Pi läuft. Das Ziel ist es, Dokumente wie Laborergebnisse oder Rezepte mit dem Telefon zu scannen und sie direkt in OpenClaw für die weitere Verarbeitung zu überführen, ohne Cloud-Zwischenstationen oder manuelle Uploads.

Architektur-Überblick

Das System nutzt einen zweistufigen Ansatz: Das Telefon fungiert als Erfassungsschicht, und OpenClaw dient als Verarbeitungsschicht. Der mobile Client ist vollständig lokal und datenschutzfreundlich konzipiert, ohne Cloud-Abhängigkeit und ohne externe KI-Dienste. Es verwendet Apple OCR (Vision) und On-Device-Intelligenz für Extraktion und Suche, wobei Rohdokumente und extrahierte Inhalte auf dem Gerät verbleiben, es sei denn, sie werden explizit an OpenClaw gesendet.

Pairing und Konfiguration

Ein QR-basierter Pairing-Prozess vermeidet manuelle Konfiguration. Die QR-Nutzlast ist ein base64-kodierter JSON-Blob, der auf der OpenClaw-Maschine mit dieser Struktur generiert wird:

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

Der hooksToken wird im iOS-Keychain gespeichert, nicht-sensitive Konfigurationen im lokalen Speicher, und die wss://-URL wird für Push-Anfragen in https:// umgewandelt.

Datenfluss

Der iPhone-Client sendet eine POST-Anfrage an /hooks/rkive mit einem Bearer-Token ({hooksToken}) und einer JSON-Nutzlast, die ein base64-kodiertes PDF enthält. Dies landet auf der OpenClaw-Instanz (Raspberry Pi, im lokalen Netzwerk oder VPN), die ein ingest_rkive.py-Transformationsskript ausführt. Dieses Skript speichert das Original-PDF unter health-records/originals/, aktualisiert einen Indexeintrag in health-records/index.jsonl und kümmert sich um die Zusammenführung von Chunks sowie die Bereinigung bei Abbruch. Ein dedizierter Health-Agent übernimmt dann die weitere Verarbeitung: OCR → Validierung → strukturierte Ausgabe.

Wichtige Designentscheidungen

• Dedizierter Agent in OpenClaw: Ein Multi-Agent-Setup beinhaltet einen dedizierten Health-Agent, der für die Dokumentenaufnahme, Validierung und weitere Strukturierung verantwortlich ist, um gesundheitsbezogene Workflows isoliert zu halten.
• Dedizierter Endpunkt: Die Verwendung eines festen Endpunkts wie /hooks/rkive anstelle von dynamischem Routing via agentId gewährleistet deterministisches Routing, vermeidet versehentliche Fehlklassifizierung und vereinfacht die serverseitige Logik.

Downstream-Workflow und offene Fragen

Der Downstream-Workflow ist noch in Arbeit. Da Apple OCR als nicht 100% zuverlässig angesehen wird, ist geplant, den Text in OpenClaw mit dem vertrauenswürdigen KI-Workflow des Nutzers erneut in sauberes Markdown zu extrahieren, gefolgt von einem menschlichen Validierungsschritt zur Inhaltsüberprüfung, strukturierter Extraktion in FHIR-ähnliche Ressourcen, Einfügung in einen longitudinalen Datensatz und Bereitstellung von Gesundheitserkenntnissen.

Der Autor stellt zwei offene Fragen zur Diskussion in der Community: 1) Ob dieses Muster in der Praxis für den regelmäßigen Gebrauch nützlich erscheint oder zu umständlich ist, und 2) Was die Leute von OpenClaw erwarten würden, sobald persönliche Gesundheitsakten aufgenommen wurden, mit Ideen wie longitudinalen Ereigniszeitlinien, der Erkennung von Lücken (z.B. verpasste Nachuntersuchungen) und periodischen Zusammenfassungen.