Agente de IA para Integração de Dados de Laboratório

18 de December de 2025 • Tempo de leitura: 5 min

Como criar um agente de IA que consolida resultados de exames de laboratório com prontuários eletrônicos.

1. Propósito e Escopo

Este documento define todos os prompts, configurações de memória, transição entre estados e demais requisitos funcionais para o Fluxo de Agentes "Integração de Dados de Laboratório", uma solução de automação projetada para consolidar resultados de exames de laboratório com prontuários eletrônicos. Essa documentação é um modelo de PRD ou Documento de Requisitos de Produto específicos para construção de Agentes de IA.

O objetivo principal é integrar automaticamente os resultados de exames laboratoriais aos prontuários eletrônicos dos pacientes, facilitando a visualização integrada dos dados para apoiar decisões clínicas.

2. Contexto e Problema

Cenário Atual

Atualmente, os dados laboratoriais e os prontuários eletrônicos dos pacientes são geridos separadamente, o que pode levar a problemas como:

  • Dificuldade na consolidação eficiente de resultados de exames de laboratório com os prontuários eletrônicos dos pacientes.
  • Dificuldade no acesso a dados integrados para apoiar decisões clínicas.
  • Erros e duplicidade de registros na gestão de dados laboratoriais.

Problemas Identificados

  • Consolidação Ineficiente: A integração manual de dados de laboratório com prontuários eletrônicos é propensa a erros e consome tempo.
  • Decisões Clínicas Prejudicadas: A falta de visualização integrada dos dados dificulta a tomada de decisões clínicas precisas.
  • Erros e Duplicidade: A gestão manual de dados pode resultar em duplicidade de registros, comprometendo a precisão dos dados.

3. Impactos Esperados

A implementação deste agente de IA visa alcançar os seguintes resultados:

  • Melhoria na Consolidação de Dados: Automatizar a integração de dados laboratoriais com prontuários eletrônicos.
  • Facilitação de Acesso: Prover uma interface que permita aos médicos acessar facilmente os dados integrados.
  • Redução de Erros: Garantir a precisão e consistência dos dados integrados para apoiar decisões clínicas.

4. Visão Geral da Solução

O agente de IA para integração de dados de laboratório consolida resultados de exames com prontuários eletrônicos, facilitando a visualização integrada dos dados do paciente. A seguir são detalhadas todas as regras de negócio e especificações funcionais necessárias para que esse agente atue como um assistente útil e autônomo na consolidação de dados laboratoriais.

A solução consiste em um fluxo de automação composto por 4 agentes de IA. O processo inicia com a conciliação de identidade do paciente e termina com a geração de um modelo de visualização para médicos.

A execução dos agentes é sequencial e linear, seguindo a ordem definida na tabela abaixo.

Agentes Função Principal
Agente de Conciliação de Identidade do Paciente (RF 1) Conciliar e vincular resultados laboratoriais ao paciente correto no prontuário eletrônico.
Agente de Padronização e Deduplicação de Resultados de Exames (RF 2) Padronizar códigos e unidades de exames, validar consistência de valores e remover duplicidades.
Agente de Consolidação Clínica no Prontuário (RF 3) Integrar os exames normalizados à linha do tempo do EHR e produzir interpretações clínicas.
Agente de Geração de Modelo de Visualização para Médicos (RF 4) Produzir um modelo de visualização pronto para interface clínica.

5. Protótipos

Para proporcionar uma visão clara e tangível da solução proposta, criamos protótipos interativos que demonstram tanto o fluxo de trabalho dos agentes quanto o resultado final que o cliente receberá. Explore os links abaixo para entender melhor a solução em ação.

6. Requisitos Funcionais

RF 1. Agente de Conciliação de Identidade do Paciente

1.1 Tarefa do Agente

Conciliar e vincular resultados laboratoriais ao paciente correto no prontuário eletrônico (EHR), definindo uma chave única de paciente para o fluxo.

1.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados de resultados laboratoriais e prontuários eletrônicos. Este input contém informações detalhadas sobre pacientes e exames realizados.

# 2. Objetivo
Conciliar e vincular resultados laboratoriais ao paciente correto no prontuário eletrônico (EHR), definindo uma chave única de paciente para o fluxo.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra 1 (chaves determinísticas): se mrn e data_nascimento coincidirem exatamente entre lab_results e ehr_pacientes, defina patient_match_status = matched e matched_patient_id = ehr.patient_id correspondente.
- Regra 2 (fallbacks): se mrn ausente, use combinação cpf + data_nascimento; se cpf ausente, use nome normalizado (remover acentos, espaços duplicados, caixa baixa) + data_nascimento. Empates múltiplos causam patient_match_status = ambiguous e retorno de até 5 candidate_patient_ids ordenados por similaridade do nome.
- Regra 3 (integridade de data): datas inválidas ou futuras provocam issues com type = dados_incompletos e impedem matched.
- Regra 4 (desempate): preferir registros EHR ativos (status = ativo) e mais recentes (data_atualizacao mais nova). Em empate total, definir ambiguous.
- Regra 5 (saída mínima): se not_found, matched_patient_id = null e candidate_patient_ids = [].

# 4. Exemplo de Output que você deve produzir
{
  "patient_match_status": "matched|ambiguous|not_found",
  "matched_patient_id": "string|null",
  "candidate_patient_ids": ["string"],
  "linkage_map": [{"lab_patient_key": "", "ehr_patient_id": "string"}],
  "issues": [{"type": "dados_incompletos|conflito", "detail": "string"}]
} 
1.3 Configurações do Agente

1.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente é o ponto de partida do fluxo e deve ser acionado pelo envio de dados laboratoriais e prontuários eletrônicos via API. Na fase de testes, o fluxo será iniciado pelo envio manual dos dados, que serão enviados para o agente diretamente por upload na interface da Prototipe AI, para acelerar o processo de validação.
  • Tipo do input: O input inicial para o fluxo é um conjunto de dados estruturados contendo informações de pacientes e resultados laboratoriais.
  • Formatos Suportados: Esse agente deve ser capaz de receber dados nos formatos: .json, .csv.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 100.000 caracteres.

1.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado que representa o estado de conciliação dos pacientes.
  • Exemplo de Estrutura de Output:
     {
      "patient_match_status": "matched",
      "matched_patient_id": "12345",
      "candidate_patient_ids": [],
      "linkage_map": [{"lab_patient_key": "mrn123", "ehr_patient_id": "12345"}],
      "issues": []
    } 
  • Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 2.500 caracteres.

1.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

1.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

1.3.5 Memória

1.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Padronização e Deduplicação de Resultados de Exames (RF 2).

RF 2. Agente de Padronização e Deduplicação de Resultados de Exames

2.1 Tarefa do Agente

Padronizar códigos e unidades de exames, validar consistência de valores e remover duplicidades antes da integração ao EHR.

2.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo resultados laboratoriais que precisam ser padronizados e deduplicados para integração ao EHR.

# 2. Objetivo
Padronizar códigos e unidades de exames, validar consistência de valores e remover duplicidades antes da integração ao EHR.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra 1 (prontuário válido): só processe se patient_match.patient_match_status = matched; caso contrário, retorne lab_results_normalizados = [] e um alerta_normalizacao do tipo "paciente_nao_conciliado" por exame.
- Regra 2 (códigos): preencher loinc a partir de tabela de mapeamento recebida no input (se houver) ou preservar test_code_origem; sempre incluir test_code_origem.
- Regra 3 (unidades): converter unit para unidade UCUM de destino quando houver regra conhecida (ex.: mg/dL -> mmol/L conforme fator do analito). Se fator de conversão desconhecido, mantenha unit_ucum = null e registre alerta tipo unidade_nao_mapeada.
- Regra 4 (valores): tentar parse numérico; quando não possível (ex.: "positivo", "negativo", "reagente"), setar value_text e deixar value_num = null.
- Regra 5 (faixas de referência): priorizar ref_low/ref_high do laudo; se ausentes, deixar null e registrar alerta faixa_referencia_ausente.
- Regra 6 (deduplicação): considerar duplicata quando patient_id, loinc (ou test_code_origem se loinc ausente), specimen, collected_at e accession_number coincidirem. Em múltiplas versões, manter status_finalidade com prioridade final > corrigido > preliminar; em empate, manter resulted_at mais recente.
- Regra 7 (integridade temporal): resulted_at não pode ser anterior a collected_at; se ocorrer, ajustar ordem apenas na validação (não corrija valor) e adicionar alerta tipo "inconsistencia_temporal".

# 4. Exemplo de Output que você deve produzir
{
  "lab_results_normalizados": [{"patient_id": "string", "loinc": "string", "test_code_origem": "string", "value_num": "number|null", "value_text": "string|null", "unit_ucum": "string|null", "ref_interval": {"low": "number|null", "high": "number|null"}, "specimen": "string", "status_finalidade": "final|preliminar|corrigido", "collected_at": "ISO-8601", "resulted_at": "ISO-8601", "accession_number": "string", "proveniencia": {"sistema": "string", "fonte": "LIS"}}], "duplicatas_descartadas": [{"accession_number": "string", "motivo": "duplicata_mesmo_conteudo|substituido_por_versao_final"}], "alertas_normalizacao": [{"tipo": "unidade_nao_mapeada|valor_nao_numerico|faixa_referencia_ausente", "detail": "string", "test_code": "string"}] }
} 
2.3 Configurações do Agente

2.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 1).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON estruturado contendo resultados laboratoriais e o estado de conciliação de pacientes.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 60.000 caracteres.

2.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado que representa os resultados laboratoriais padronizados e deduplicados.
  • Exemplo de Estrutura de Output:
     {
      "lab_results_normalizados": [{"patient_id": "12345", "loinc": "1234-5", "test_code_origem": "test123", "value_num": 5.6, "value_text": null, "unit_ucum": "mg/dL", "ref_interval": {"low": 4.0, "high": 6.0}, "specimen": "sangue", "status_finalidade": "final", "collected_at": "2025-12-01T10:00:00Z", "resulted_at": "2025-12-02T10:00:00Z", "accession_number": "acc123", "proveniencia": {"sistema": "LIS", "fonte": "LIS"}}], "duplicatas_descartadas": [{"accession_number": "acc124", "motivo": "duplicata_mesmo_conteudo"}], "alertas_normalizacao": [{"tipo": "unidade_nao_mapeada", "detail": "Unidade desconhecida para test_code test124", "test_code": "test124"}] }
    } 
  • Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 5.000 caracteres.

2.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

2.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

2.3.5 Memória

2.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Consolidação Clínica no Prontuário (RF 3).

RF 3. Agente de Consolidação Clínica no Prontuário

3.1 Tarefa do Agente

Integrar os exames normalizados à linha do tempo do EHR, associando a encontros/episódios e produzindo interpretações e sinalizações clínicas.

3.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo exames laboratoriais normalizados e o contexto clínico do EHR para integrar os dados à linha do tempo do prontuário.

# 2. Objetivo
Integrar os exames normalizados à linha do tempo do EHR, associando a encontros/episódios e produzindo interpretações e sinalizações clínicas.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra 1 (associação a encontros): vincular cada exame ao encounter cujo intervalo [inicio, fim] contenha collected_at; se nenhum contiver, associar ao encounter mais próximo por inicio dentro de janela de ±48h; se ainda assim ausente, deixar vinculo_encounter_id = null.
- Regra 2 (interpretação): se ref_interval disponível e valor numérico, classificar: valor < low => baixo; valor > high => alto; valores com protocolo crítico conhecido (ex.: K+ ≥ 6.5 mmol/L) marcar interpretacao = critico além de alto. Se sem faixa, interpretacao = na.
- Regra 3 (flags clínicas): marcar possivel_interacao_medicação quando o exame for sensível à medicação ativa na data (ex.: INR e anticoagulantes); regra simples: se substância contém termo relacionado ao analito, adicionar flag.
- Regra 4 (idempotência): para cada accession_number + loinc + patient_id, tratar como upsert; se já integrado e sem mudança de status/valor, contabilizar como skip.
- Regra 5 (proveniência): sempre preservar source (sistema) e accession_number no exame integrado.
- Regra 6 (contabilidade): preencher consistencia.upserts, consistencia.skips e listar erros com motivo quando algum exame não puder ser integrado.

# 4. Exemplo de Output que você deve produzir
{
  "dados_integrados": {"prontuario": {"patient_id": "12345", "encounters": [...]}, "exames": [{"loinc": "1234-5", "valor": {"num": 5.6, "texto": null}, "unit_ucum": "mg/dL", "interpretacao": "normal", "ref_interval": {"low": 4.0, "high": 6.0}, "vinculo_encounter_id": "enc123", "collected_at": "2025-12-01T10:00:00Z", "resulted_at": "2025-12-02T10:00:00Z", "flags": ["novo"], "proveniencia": {"sistema": "LIS", "accession_number": "acc123"}}] }, "consistencia": {"upserts": 1, "skips": 0, "erros": []} }
} 
3.3 Configurações do Agente

3.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 2).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON estruturado contendo exames laboratoriais normalizados e o contexto clínico do EHR.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 80.000 caracteres.

3.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado que representa a integração dos exames na linha do tempo do EHR.
  • Exemplo de Estrutura de Output:
     {
      "dados_integrados": {"prontuario": {"patient_id": "12345", "encounters": [...]}, "exames": [{"loinc": "1234-5", "valor": {"num": 5.6, "texto": null}, "unit_ucum": "mg/dL", "interpretacao": "normal", "ref_interval": {"low": 4.0, "high": 6.0}, "vinculo_encounter_id": "enc123", "collected_at": "2025-12-01T10:00:00Z", "resulted_at": "2025-12-02T10:00:00Z", "flags": ["novo"], "proveniencia": {"sistema": "LIS", "accession_number": "acc123"}}] }, "consistencia": {"upserts": 1, "skips": 0, "erros": []} }
    } 
  • Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 6.000 caracteres.

3.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

3.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Não se conecta a sistemas externos.

3.3.5 Memória

3.3.6 Regras de Orquestração e Transição

Ao concluir sua execução, esse agente aciona o Agente de Geração de Modelo de Visualização para Médicos (RF 4).

RF 4. Agente de Geração de Modelo de Visualização para Médicos

4.1 Tarefa do Agente

Produzir um modelo de visualização pronto para interface clínica, com resumos, destaques e séries temporais por analito.

4.2 Prompt ou Instruções do Agente
 # 1. Contexto e explicações sobre inputs iniciais
Você está recebendo dados integrados e normalizados de exames laboratoriais para criar um modelo de visualização para médicos.

# 2. Objetivo
Produzir um modelo de visualização pronto para interface clínica, com resumos, destaques e séries temporais por analito.

# 3. Regras que você deve seguir para gerar sua resposta
- Regra 1 (destaques): incluir até 10 itens, priorizando na ordem: critico > alto > baixo > novo (últimas 24h). Cada destaque deve conter loinc, descrição curta e resulted_at.
- Regra 2 (séries): agrupar por loinc; ordenar pontos por t ascendente; limitar a 180 dias mais recentes, se houver mais, truncar mantendo últimos 200 pontos.
- Regra 3 (paineis): mapear loinc para painéis conhecidos; se desconhecido, classificar como outros.
- Regra 4 (consistência de unidades): exibir unit e ref_low/ref_high coerentes com a unidade final normalizada; se ausentes, mostrar null sem inferir.
- Regra 5 (acessibilidade): os textos devem ser autocontidos, sem jargões excessivos; usar nomes canônicos de exames quando disponíveis (por ex., "Potássio sérico").

# 4. Exemplo de Output que você deve produzir
{
  "view_model": {"resumo_paciente": {"patient_id": "12345", "ultimos_exames_data": "2025-12-02T10:00:00Z"}, "destaques": [{"tipo": "critico", "descricao": "Potássio alto", "loinc": "1234-5", "resulted_at": "2025-12-02T10:00:00Z"}], "series_temporais": [{"loinc": "1234-5", "nome_exame": "Potássio sérico", "pontos": [{"t": "2025-12-01T10:00:00Z", "v": 5.6}], "unit": "mg/dL", "ref_low": 4.0, "ref_high": 6.0}], "organizacao_por_paineis": [{"painel": "bioquimica", "itens": ["1234-5"]}] }
} 
4.3 Configurações do Agente

4.3.1 Especificação do Input

  • Mecanismo de Acionamento: Este agente deve ser acionado automaticamente após a conclusão bem-sucedida do agente anterior (RF 3).
  • Tipo do input: Este agente deve ser apto a receber como input um JSON estruturado contendo dados integrados e normalizados de exames laboratoriais.
  • Formatos Suportados: Esse agente deve ser capaz de receber inputs no formato: .json.
  • Número de caracteres esperado: Este agente deve ter capacidade para processar um input de texto com até 40.000 caracteres.

4.3.2 Especificação do Output

  • Formato de output: O output deve ser um JSON estruturado que representa o modelo de visualização para interface clínica.
  • Exemplo de Estrutura de Output:
     {
      "view_model": {"resumo_paciente": {"patient_id": "12345", "ultimos_exames_data": "2025-12-02T10:00:00Z"}, "destaques": [{"tipo": "critico", "descricao": "Potássio alto", "loinc": "1234-5", "resulted_at": "2025-12-02T10:00:00Z"}], "series_temporais": [{"loinc": "1234-5", "nome_exame": "Potássio sérico", "pontos": [{"t": "2025-12-01T10:00:00Z", "v": 5.6}], "unit": "mg/dL", "ref_low": 4.0, "ref_high": 6.0}], "organizacao_por_paineis": [{"painel": "bioquimica", "itens": ["1234-5"]}] }
    } 
  • Número de caracteres esperado: O JSON gerado deve ser claro e direto, com um tamanho estimado em 4.000 caracteres.

4.3.3 Parâmetros de Geração

  • Modelo: GPT-5
  • Temperatura: 0.6

4.3.4 Ferramentas do Agente

  • Documentos: Não consulta documentos externos.
  • Calculadora: Não utiliza.
  • Busca Online: Não utiliza.
  • Sistemas Externos: Após gerar o view_model, enviar o payload final para o sistema de prontuário eletrônico configurado para apresentação clínica.

4.3.5 Memória

  • Visibilidade das Instruções (Prompt): As instruções deste agente não devem ser visíveis para nenhum agente.
  • Visibilidade da Resposta: A resposta gerada por este agente é o entregável final para o sistema de prontuário eletrônico.

4.3.6 Regras de Orquestração e Transição

A execução deste agente finaliza o fluxo. O view_model gerado é o resultado que deve ser disponibilizado ao usuário.

© 2025 prototipe.ai. Todos os direitos reservados.