Ingestão Direta de Documentos Móveis para OpenClaw: Fluxo de Trabalho de Saúde de iOS para Raspberry Pi

Um desenvolvedor no r/openclaw documentou um padrão experimental para enviar documentos diretamente de um cliente móvel iOS para uma instância local do OpenClaw em execução em um Raspberry Pi. O objetivo é escanear documentos como resultados de exames ou receitas médicas no telefone e fazê-los chegar ao OpenClaw para processamento subsequente, sem intermediários na nuvem ou uploads manuais.

Visão Geral da Arquitetura

O sistema usa uma abordagem de duas camadas: o telefone atua como camada de captura e o OpenClaw serve como camada de processamento. O cliente móvel foi projetado para ser totalmente local e preservar a privacidade, sem dependência de nuvem e sem serviços externos de IA. Ele usa OCR da Apple (Vision) e inteligência no dispositivo para extração e busca, mantendo documentos brutos e conteúdo extraído no dispositivo, a menos que sejam explicitamente enviados para o OpenClaw.

Emparelhamento e Configuração

Um fluxo de emparelhamento baseado em QR evita configuração manual. A carga útil do QR é um blob JSON codificado em base64 gerado na máquina OpenClaw com esta estrutura:

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

O hooksToken é armazenado no Keychain do iOS, configurações não sensíveis ficam no armazenamento local e a URL wss:// é convertida para https:// para solicitações de envio.

Fluxo de Dados

O cliente móvel iPhone envia uma solicitação POST para /hooks/rkive com um token Bearer ({hooksToken}) e uma carga útil JSON contendo um PDF codificado em base64. Isso chega à instância do OpenClaw (Raspberry Pi, na rede local ou VPN), que executa um script de transformação ingest_rkive.py. Este script salva o PDF original em health-records/originals/, atualiza um registro de índice em health-records/index.jsonl e lida com montagem em partes e limpeza de abortos. Um agente de saúde dedicado então gerencia o processamento subsequente: OCR → validação → saída estruturada.

Principais Decisões de Design

• Agente Dedicado no OpenClaw: Uma configuração multiagente inclui um agente de saúde dedicado responsável pela ingestão de documentos, validação e estruturação subsequente, mantendo fluxos de trabalho relacionados à saúde isolados.
• Endpoint Dedicado: Usar um endpoint fixo como /hooks/rkive em vez de roteamento dinâmico via agentId garante roteamento determinístico, evita classificação incorreta acidental e simplifica a lógica do servidor.

Fluxo de Trabalho Subsequente e Questões em Aberto

O fluxo de trabalho subsequente está em andamento. Como o OCR da Apple não é considerado 100% confiável, o plano envolve reextrair o texto em markdown limpo no OpenClaw usando o fluxo de trabalho de IA confiável do usuário, seguido por uma etapa de validação humana para verificação de conteúdo, extração estruturada em recursos no estilo FHIR, anexação em um conjunto de dados longitudinal e fornecimento de insights de saúde.

O autor apresenta duas questões em aberto para feedback da comunidade: 1) Se esse padrão parece útil na prática para uso regular versus ser muito complicado, e 2) O que as pessoas gostariam que o OpenClaw fizesse com registros de saúde pessoais após a ingestão, sugerindo ideias como cronogramas de eventos longitudinais, detecção de lacunas (por exemplo, acompanhamentos perdidos) e resumos periódicos.