Pokala HealthIntel: A No-PHI Public-Source Healthcare Evidence Review Workspace

Resumo Técnico: Pokala HealthIntel

Definição do Problema
Conjuntos de dados de saúde de fontes públicas (ex: openFDA, ClinicalTrials.gov) oferecem recursos valiosos para revisões regulatórias, de segurança, de provedores e de contexto de mercado. No entanto, existe uma lacuna crítica no fluxo de trabalho de revisão subsequente: as alegações derivadas desses artefatos públicos frequentemente se desprendem de seu contexto essencial. Revisores podem encontrar notas de segurança ou sinais de mercado sem acesso imediato à identidade da fonte de suporte, à escala dos dados (contagem de linhas), ao frescor do snapshot ou às limitações específicas que restringem a interpretação. Na informática em saúde, essa separação cria um risco onde os resultados de revisões de fontes públicas podem ser interpretados erroneamente como evidência clínica, inferências ao nível do paciente ou suporte à decisão validado, apesar de carecerem das fronteiras de evidência necessárias.

Metodologia e Design do Sistema
O artigo apresenta o Pokala HealthIntel, um espaço de trabalho de revisão de evidências de saúde de fonte pública sem PHI (Informação de Saúde Protegida), projetado para manter o vínculo entre as alegações de revisão e os metadados explícitos da evidência.

• Arquitetura: O sistema utiliza um modelo de artefato orientado a snapshots. Ele ingere entradas de fontes públicas pré-processadas e as organiza em "registros de evidência vinculados a alegações". A implantação consiste em um frontend React/Vite e uma superfície de rota de Cloudflare Worker, com os dados gerenciados via Cloudflare D1 (um banco de dados SQLite serverless).
• Esquema Central: A unidade fundamental de design não é um card de dashboard, mas sim um registro de evidência estruturado contendo cinco campos obrigatórios:
  1. Alegação/Título: A observação sumarizada.
  2. Fonte: A categoria ou artefato que sustenta a alegação.
  3. Contagem de Linhas: O contexto de escala do artefato.
  4. Frescor: O contexto de recência ou do snapshot.
  5. Limitação/Fronteira: Declarações explícitas sobre o que a alegação não deve ser usada para inferir.
• Protocolo de Avaliação: O estudo é uma demonstração de sistema e uma avaliação de nível de implementação. Não avaliou segurança clínica, desfechos de pacientes ou precisão diagnóstica. Em vez disso, a avaliação focou em:
  • Build & Deployment: Instalação de dependências e sucesso do build do frontend.
  • Disponibilidade de Rota: 20 requisições por rota pública para verificar as taxas de resposta 2xx e latência.
  • Cobertura de Evidência: Inspeção dos registros de evidência de alto nível para a presença dos cinco campos de metadados exigidos.
  • Linhagem & Fronteiras: Verificação de linhagem canônica, varredura de frases de linguagem pública proibidas (para garantir que não haja excessos de alegações clínicas) e verificação do status do manifesto da fonte.

Principais Resultados
A avaliação gerou os seguintes resultados:

• Build & Deployment: A instalação de dependências e o build do frontend passaram com sucesso.
• Desempenho de Endpoint: Seis rotas públicas verificadas retornaram 100% de respostas 2xx ao longo de 20 requisições cada. As latências medianas variaram de 119,87 ms a 136,61 ms, com latências p95 entre 144,96 ms e 542,31 ms.
• Metadados de Evidência: Os metadados do snapshot reportaram 172.228 linhas de evidência através de quatro fontes. Todos os quatro registros de evidência de alto nível selecionados continham 100% dos campos exigidos (alegação/título, fonte, contagem de linhas, frescor e limitação/fronteira).
• Linhagem & Fronteiras: O verificador de linhagem canônica passou, confirmando a consistência entre as contagens de linhas/fonte reportadas e os metadados. A varredura de linguagem pública não encontrou frases proibidas, e o status do manifesto da fonte foi incluído.
• Status de Ferramental: Um script local de validação de artefato foi sinalizado como um item de manutenção após mudanças no layout da fonte, mas isso não impactou as alegações principais do sistema.

Principais Contribuições e Significância
O artigo posiciona o Pokala HealthIntel não como um sistema de suporte à decisão clínica, modelo diagnóstico ou motor de recomendação de tratamento, mas como uma demonstração de sistemas de informática em saúde.

• Padrão Auditável: A principal contribuição é um padrão modesto e auditável para revisão de evidências de fonte pública. Demonstra que alegações de revisão selecionadas podem permanecer estruturalmente vinculadas à fonte, escala, frescor e metadados de limitação dentro de um espaço de trabalho implantado.
• Comunicação de Fronteiras: O sistema impõe explicitamente uma fronteira de "sem PHI" e "não clínico". Ao incorporar campos de limitação diretamente no esquema do registro de evidência, o design visa evitar a interpretação errônea de artefatos públicos como inferência ao nível do paciente ou validação clínica.
• Proveniência e Alinhamento FAIR: Embora não seja uma certificação formal, o sistema operacionaliza os princípios de proveniência (W3C PROV) e os princípios de dados FAIR ao garantir que as alegações derivadas sejam acompanhadas pelos metadados necessários para julgar sua adequação ao uso.

Limitações e Escopo
Os autores declaram explicitamente que este trabalho é uma avaliação de nível de implementação, não um estudo de validação clínica. O sistema não fornece diagnóstico, triagem ou orientação específica para o paciente. As métricas de avaliação (latência, disponibilidade) refletem uma única execução e não constituem um acordo de nível de serviço (SLA) ou garantia de confiabilidade de produção. Além disso, embora o status do manifesto da fonte esteja incluído, trabalhos futuros são necessários para expandir isso para um manifesto upstream completo com URLs de recuperação, checksums e notas de transformação. O artigo conclui que o espaço de trabalho serve como uma prova de conceito para o uso secundário responsável de dados de saúde pública, distinto de IA clínica ou plataformas clínicas de produção.