Ingesta Directa de Documentos Móviles a OpenClaw: Flujo de Trabajo de Salud de iOS a Raspberry Pi

Un desarrollador en r/openclaw ha documentado un patrón experimental para enviar documentos directamente desde un cliente móvil iOS a una instancia local de OpenClaw que se ejecuta en una Raspberry Pi. El objetivo es escanear documentos como resultados de laboratorio o recetas médicas en un teléfono y que lleguen a OpenClaw para su procesamiento posterior sin intermediarios en la nube ni cargas manuales.

Descripción General de la Arquitectura

El sistema utiliza un enfoque de dos capas: el teléfono actúa como capa de captura y OpenClaw sirve como capa de procesamiento. El cliente móvil está diseñado para ser completamente local y respetuoso con la privacidad, sin dependencia de la nube ni servicios de IA externos. Utiliza OCR de Apple (Vision) e inteligencia en el dispositivo para extracción y búsqueda, manteniendo los documentos originales y el contenido extraído en el dispositivo a menos que se envíen explícitamente a OpenClaw.

Emparejamiento y Configuración

Un flujo de emparejamiento basado en códigos QR evita la configuración manual. La carga útil del código QR es un blob JSON codificado en base64 generado en la máquina OpenClaw con esta estructura:

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

El hooksToken se almacena en el llavero de iOS, la configuración no sensible está en el almacenamiento local, y la URL wss:// se convierte a https:// para las solicitudes de envío.

Flujo de Datos

El cliente móvil iPhone envía una solicitud POST a /hooks/rkive con un token Bearer ({hooksToken}) y una carga útil JSON que contiene un PDF codificado en base64. Esto llega a la instancia de OpenClaw (Raspberry Pi, en red local o VPN), que ejecuta un script de transformación ingest_rkive.py. Este script guarda el PDF original en health-records/originals/, actualiza o inserta un registro de índice en health-records/index.jsonl, y maneja el ensamblaje por fragmentos y la limpieza de abortos. Un agente de salud dedicado luego gestiona el procesamiento posterior: OCR → validación → salida estructurada.

Decisiones de Diseño Clave

• Agente Dedicado en OpenClaw: Una configuración multiagente incluye un agente de salud dedicado responsable de la ingesta de documentos, validación y estructuración posterior, manteniendo los flujos de trabajo relacionados con la salud aislados.
• Endpoint Dedicado: Usar un endpoint fijo como /hooks/rkive en lugar de enrutamiento dinámico a través de agentId asegura un enrutamiento determinista, evita clasificaciones erróneas accidentales y simplifica la lógica del servidor.

Flujo de Trabajo Posterior y Preguntas Abiertas

El flujo de trabajo posterior está en progreso. Dado que se señala que el OCR de Apple no es 100% confiable, el plan implica reextraer el texto en markdown limpio en OpenClaw usando el flujo de trabajo de IA confiable del usuario, seguido de un paso de validación humana para verificación de contenido, extracción estructurada en recursos estilo FHIR, incorporación a un conjunto de datos longitudinal y provisión de información de salud.

El autor plantea dos preguntas abiertas para la retroalimentación de la comunidad: 1) Si este patrón resulta útil en la práctica para uso regular versus ser demasiado engorroso, y 2) Qué querría la gente que OpenClaw haga con los registros de salud personales una vez ingeridos, sugiriendo ideas como líneas de tiempo de eventos longitudinales, detección de brechas (por ejemplo, seguimientos perdidos) y resúmenes periódicos.