Variability in Automated Sepsis Case Detection: A Systematic Analysis of Implementation Methods in Clinical Data Repositories

Esta revisão sistemática demonstra que a heterogeneidade metodológica na implementação de critérios de detecção de sepse em bancos de dados clínicos gera taxas de identificação drasticamente diferentes, sublinhando a necessidade urgente de padronização nos relatórios e publicação de códigos fonte para garantir a reprodutibilidade da pesquisa.

O essencial

Imagine que a Sepse é como um incêndio silencioso e perigoso dentro do corpo de um paciente. Detectá-la cedo é crucial para salvar vidas. Para ajudar os médicos, cientistas criaram uma "receita" oficial (chamada Sepsis-3) para identificar esses casos usando os registros eletrônicos dos hospitais, como se fosse um detector de fumaça automático.

O problema? Todos os cientistas usaram a mesma receita, mas o bolo ficou com sabores e tamanhos completamente diferentes.

Este estudo, feito por pesquisadores da Alemanha, investigou por que isso acontece. Eles olharam para centenas de estudos que usaram dois grandes bancos de dados de pacientes (MIMIC-III e eICU-CRD) e descobriram uma bagunça metodológica.

Aqui está a explicação simplificada, usando algumas analogias:

1. O Problema: A "Receita" que Ninguém Segue Igual

A definição oficial diz: "Se o paciente tem uma infecção suspeita E a função de pelo menos dois órgãos piora (medido por uma pontuação chamada SOFA), é sepse."

Parece simples, certo? Mas, na prática, os cientistas interpretaram essa receita de formas muito diferentes:

• O "Detector de Fumaça" (SOFA): Alguns cientistas olharam apenas para os dados que estavam disponíveis naquele momento. Outros tentaram adivinhar os dados que faltavam (como se o paciente estivesse "normal" se não houvesse registro).
• A "Janela de Tempo": Alguns olharam para as últimas 24 horas. Outros olharam para 48 horas. Alguns começaram a contar a partir da entrada do paciente na UTI; outros começaram a contar a partir do momento em que o antibiótico foi dado.
• O "Rastro de Fogo" (Infecção): Como saber se é infecção? Alguns usaram apenas o código do diagnóstico no computador do hospital. Outros cruzaram dados de antibióticos com exames de cultura de sangue.

O Resultado:
Em um banco de dados, a taxa de detecção de sepse variou de 3,4% a 65,2%.

• Imagine um hospital com 100 pacientes.
• O "Cientista A" diria: "Temos 3 pacientes com sepse".
• O "Cientista B" diria: "Temos 65 pacientes com sepse".
• Ambos usaram os mesmos dados brutos! Isso é como se um detector de fumaça dissesse "fogo" apenas quando a fumaça é preta, e outro dissesse "fogo" quando a fumaça é cinza ou quando o cheiro de queimado está no ar.

2. A Investigação: O Detetive de Código

Os autores não apenas leram os artigos; eles foram como detetives e olharam o código de computador (as instruções reais que os cientistas escreveram) de alguns desses estudos.

Eles descobriram que:

• Muitos segredos estão escondidos: A maioria dos artigos não explicava como os dados foram limpos ou calculados. Era como pedir uma receita de bolo que diz apenas "misture os ingredientes", sem dizer quanto de açúcar ou farinha usar.
• O efeito "Cópia e Cola": Eles viram que muitos grupos de pesquisa estavam usando o mesmo código base (como se estivessem copiando a receita de um vizinho). Se o vizinho errou a medida do açúcar, todos os outros também erraram, criando um "efeito dominó" de erros ou escolhas específicas.
• A falta de padronização: Mesmo quando os estudos diziam que usavam a mesma definição, as escolhas técnicas (como lidar com dados faltantes) eram tão diferentes que geravam resultados opostos.

3. Por que isso é importante? (A Analogia do GPS)

Pense nos modelos de inteligência artificial para prever sepse como GPSs.

• Se um GPS é treinado com dados que dizem "tem 3 pacientes doentes", ele aprende a identificar apenas casos graves.
• Se outro GPS é treinado com dados que dizem "tem 65 pacientes doentes", ele vai ficar "alucinado" e achar que todo mundo está doente.

Se os médicos usarem esses "GPSs" diferentes para tomar decisões, um pode ignorar um paciente que precisa de ajuda, e outro pode tratar um paciente que não precisa, desperdiçando recursos.

4. A Solução Proposta: O "Manual de Instruções"

Os autores concluem que não basta ter uma definição clínica bonita. Precisamos de padronização técnica. Eles sugerem:

1. Publicar o Código: Assim como um programador publica seu código no GitHub, os pesquisadores devem publicar exatamente como calcularam a sepse.
2. Relatório Obrigatório: Criar uma lista de verificação (como um checklist de decolagem de avião) onde os cientistas devem explicar cada passo: "Como lidamos com dados faltantes?", "Qual janela de tempo usamos?".
3. Código de Referência: Desenvolver um "código oficial" que todos possam usar como base, para garantir que todos estejam medindo a mesma coisa.

Resumo em uma frase

Este estudo mostra que, na ciência médica moderna, a forma como escrevemos o código de computador é tão importante quanto a teoria médica, e sem transparência total sobre como esses códigos funcionam, não podemos confiar nos resultados ou salvar vidas de forma consistente.

Resumo técnico

1. O Problema

A sepse é uma carga clínica e econômica global significativa, com mortalidade superior a 35% em unidades de terapia intensiva (UTI). A definição Sepsis-3 (2016) operacionalizou a sepse como uma infecção suspeita acompanhada de disfunção orgânica aguda, quantificada pelo aumento de pelo menos 2 pontos no escore SOFA (Sequential Organ Failure Assessment).

Apesar de existir uma definição clínica padronizada, a aplicação desta definição em conjuntos de dados idênticos (como MIMIC-III e eICU-CRD) resulta em taxas de detecção de sepse drasticamente diferentes entre estudos. A literatura previa que essa variabilidade poderia ser devida a diferenças nos dados, mas faltava uma caracterização sistemática das decisões de implementação computacional que contribuem para essa disparidade. O problema central é a falta de reprodutibilidade e a heterogeneidade metodológica oculta nos estudos de aprendizado de máquina e epidemiologia baseados em registros eletrônicos de saúde (EHR).

2. Metodologia

Os autores conduziram uma revisão sistemática guiada pelo PRISMA (período de 2016 a 2024) combinada com uma análise detalhada de código-fonte.

• Bases de Dados Analisadas:
  • MIMIC-III: Dados de 46.520 pacientes de uma única instituição (Beth Israel Deaconess Medical Center).
  • eICU-CRD: Dados de 139.367 pacientes de 208 hospitais nos EUA.
  • Nota: MIMIC-IV e AmsterdamUMCdb foram excluídos devido a sobreposição de pacientes ou volume insuficiente de publicações.
• Seleção de Estudos:
  • Foram rastreadas 396 publicações.
  • 64 estudos atenderam aos critérios de inclusão (uso de MIMIC-III ou eICU, definição baseada em SOFA, taxa de detecção rastreável).
  • 12 estudos forneceram código-fonte acessível para análise profunda.
• Estrutura de Análise (6 Domínios Metodológicos):
  A detecção de sepse foi decomposta em seis domínios críticos (D1-D6):
  1. Cobertura de Parâmetros (D1): Seleção de parâmetros clínicos e variantes de nomes.
  2. Janelas Temporais (D2): Escopo do cálculo do SOFA, tamanho da janela deslizante e pontos de referência (admissão na UTI vs. início da infecção).
  3. Estratégias de Agregação (D3): Como lidar com múltiplas medições (pior caso vs. tendência central).
  4. Tratamento de Dados Faltantes (D4): Imputação, estratégias de fallback e fórmulas.
  5. Variantes de Cálculo do SOFA (D5): Definição da linha de base (SOFA = 0 vs. dinâmica) e modificações de componentes.
  6. Métodos de Detecção de Infecção (D6): Uso de códigos ICD, correspondência temporal antibiótico-cultura, ou métodos híbridos.

3. Principais Contribuições

• Análise de Código-Fonte: Pela primeira vez, o estudo cruzou a literatura publicada com a análise direta de repositórios de código, identificando 321 decisões de implementação específicas que não eram documentadas nos textos dos artigos.
• Decomposição Metodológica: Estabeleceu um framework de 6 domínios para classificar e auditar a variabilidade na detecção de sepse.
• Identificação de Dependências: Mapeou como decisões de implementação se propagam entre grupos de pesquisa através de repositórios de código compartilhados (ex: MIT-LCP), criando clusters de estudos com resultados idênticos, mas sem documentação explícita da origem comum.
• Proposta de Padronização: Sugere a integração de relatórios de implementação de sepse em diretrizes existentes (como CONSORT, TRIPOD e STROBE) e a publicação obrigatória de código com controle de versão.

4. Resultados Chave

A. Variabilidade Extrema nas Taxas de Detecção

Mesmo usando os mesmos dados brutos, as taxas de detecção variaram enormemente:

• MIMIC-III: De 3,4% a 65,2% (Mediana: 26,4%).
• eICU-CRD: De 9,8% a 47,9% (Mediana: 18,7%).
• Variabilidade Intra-População: Estudos que usaram a mesma tabela de pacientes (ex: todos os pacientes adultos do MIMIC-III) sem filtros adicionais apresentaram taxas variando de 16,9% a 42,2%. Isso prova que a variabilidade decorre de decisões algorítmicas, não de seleção de pacientes.

B. Baixa Documentação

A maioria dos estudos não relatou detalhes cruciais:

• Apenas 53,1% relataram detalhes do cálculo do SOFA.
• Apenas 17,2% relataram como lidaram com dados faltantes.
• Apenas 42,2% detalharam os métodos de detecção de infecção.
• Em muitos casos, a aplicabilidade das etapas de pré-processamento (para cálculo de rótulos vs. desenvolvimento de modelo) era ambígua.

C. Heterogeneidade Técnica Identificada no Código

A análise de 6 repositórios principais revelou divergências fundamentais:

• Linha de Base do SOFA: Alguns códigos assumem uma linha de base de 0 (SOFA absoluto ≥ 2), enquanto outros usam uma linha de base dinâmica (menor SOFA observado).
• Janelas Temporais: Variação entre janelas centradas na infecção (48h retrospetivas/24h prospectivas) vs. centradas na admissão na UTI.
• Tratamento de Dados Faltantes: Estratégias variaram desde imputação por zero (assumindo função normal) até interpolação linear e k-vizinhos mais próximos. A imputação por zero pode subestimar a disfunção em pacientes críticos.
• Detecção de Infecção: Diferença entre o método de correspondência temporal (antibiótico + cultura) e o uso exclusivo de códigos de diagnóstico (ICD-9).

D. Propagação de Decisões

Foi observado que grupos de pesquisa distintos frequentemente produzem resultados idênticos (ex: clusters de estudos no eICU com taxas de 34,94% e 16,60%) devido ao uso de repositórios de código ou serviços de análise de dados comuns, sem que isso fosse explicitamente declarado nos artigos.

5. Significado e Implicações

• Reprodutibilidade Comprometida: A variabilidade não é aleatória, mas sistêmica. Modelos de aprendizado de máquina treinados em coortes rotuladas de forma diferente podem ter métricas de desempenho semelhantes, mas prever fenótipos clínicos distintos, inviabilizando a comparação entre estudos.
• Risco para a Prática Clínica: A implementação de sistemas de suporte à decisão clínica (CDSS) baseados nesses modelos é arriscada, pois a "verdade" sobre quem é um paciente com sepse depende de escolhas de implementação não padronizadas.
• Futuro (SOFA-2): A introdução de novas versões de escores (como o SOFA-2) sem padronização prévia de implementação tende a aumentar essa heterogeneidade.
• Recomendações Finais:
  1. Relato padronizado obrigatório de todos os 6 domínios metodológicos (D1-D6).
  2. Publicação de código-fonte com controle de versão.
  3. Desenvolvimento de implementações de referência consensuais para bancos de dados comuns.
  4. Integração desses requisitos nas diretrizes de publicação científica.

Em resumo, o estudo demonstra que a heterogeneidade computacional é o principal fator que impede a padronização real da detecção de sepse, superando a variabilidade dos dados clínicos em si, e exige uma mudança cultural na pesquisa médica baseada em dados em direção à transparência total de implementação.