Interoperabilidade

HL7

Health Level Seven

Revisado porDr. Natan Paraíso RibeiroCRM-SP 192770
Radiologia e Diagnóstico por Imagem·Laudos.AI — Encarregado de Proteção de Dados (DPO)
Última revisão clínica:

HL7 continua essencial em ambientes legados; a integração precisa ser tratada como projeto operacional.

Definição

HL7 (Health Level Seven) é um conjunto de padrões internacionais para a troca, integração e recuperação de informações eletrônicas de saúde entre sistemas. É a 'língua franca' que permite que RIS, HIS, PACS e ferramentas de laudagem conversem entre si.

Na radiologia, o HL7 v2 é amplamente usado por meio de mensagens como ORM (ordem de exame) e ORU (resultado/laudo observado). Em ambientes mais modernos, o FHIR (Fast Healthcare Interoperability Resources) oferece uma abordagem baseada em recursos e APIs REST. Ambos coexistem em muitos hospitais.

HL7 continua essencial em ambientes legados. Por isso, integrar uma camada de laudo ao ecossistema HL7 precisa ser tratado como projeto operacional — com mapeamento por evento, fallback e documentação para a equipe de TI — e não como uma configuração de autoatendimento.

O nome 'Health Level Seven' remete à camada 7 (aplicação) do modelo OSI: o HL7 padroniza o conteúdo e a semântica das mensagens, não o transporte físico. No HL7 v2, isso se traduz em mensagens organizadas em segmentos (linhas como MSH, PID, OBR, OBX) separados por delimitadores; o tipo de mensagem (por exemplo ORM ou ORU) diz qual evento aconteceu. Saber que o significado mora nos segmentos, e não no canal, é o que permite mapear um ORU de laudo para o evento certo no fluxo sem depender do meio de transporte.

Quando faz sentido

  • Quando o serviço troca ordens e resultados via mensagens ORM/ORU em ambiente legado.
  • Para sincronizar status e resultados entre RIS, HIS e a ferramenta de laudagem.
  • Em hospitais com legado HL7 v2, onde a interoperabilidade já é o padrão de troca.
  • Quando há um motor de integração (interface engine) intermediando as mensagens entre sistemas — cenário comum em hospitais — e a camada de laudo precisa se encaixar nesse barramento, não contorná-lo.
  • Em projetos novos ou portais de paciente que adotam FHIR, em que recursos como DiagnosticReport e ImagingStudy passam a ser o ponto de troca do laudo.

Como o Laudos.AI usa

Contexto assistivo: o médico revisa, edita e assina. A IA acelera a estrutura do laudo, não toma a decisão clínica (Resolução CFM 2.454/2026; LGPD/ANPD).

  • Mapeamento por evento: cada tipo de mensagem (ORM, ORU) é mapeado para o evento correspondente no fluxo de laudo.
  • Fallback: a integração prevê comportamento de contingência em caso de falha, sem perder a rastreabilidade.
  • Documentação para TI: cada integração entrega documentação técnica para a equipe da instituição, escopada por engenheiro dedicado.
  • Aderência ao barramento existente: quando há interface engine, a integração se conecta a ele e respeita os mapeamentos já em produção, em vez de criar um canal paralelo.

HL7 v2 vs. FHIR — qual usar

Os dois padrões pertencem à família HL7 e atendem objetivos parecidos por caminhos diferentes:

HL7 v2 (ORM/ORU)

Mensageria baseada em segmentos, dominante em ambientes legados; ORM transporta ordens e ORU transporta resultados/laudos.

FHIR (R4)

Padrão moderno baseado em recursos e APIs REST/JSON (ex.: ImagingStudy, DiagnosticReport), facilitando integrações novas.

DICOM-SR

Structured Report DICOM — carrega o laudo estruturado dentro do próprio ecossistema de imagem.

Padronização clínica preservando critério médico

A avaliação precisa cobrir estrutura, negativos pertinentes, medidas, comparação e conclusão — não apenas a saída da IA. Estrutura só ajuda quando preserva critério médico.

Estrutura

Técnica, achados, comparação e impressão precisam manter legibilidade em exames normais e alterados.

Linguagem clínica

Preservar termos da modalidade e evitar conclusões genéricas que não saem dos achados.

Revisão

O radiologista deve revisar, editar e assinar antes de concluir (Resolução CFM 2.454/2026).

Integração como projeto operacional

Tratar a integração HL7 como projeto significa mapear eventos, prever fallback, documentar para a TI e auditar mudanças, acessos, achados críticos e falhas de integração. O objetivo é encaixar no fluxo existente sem forçar troca de PACS/RIS.

ORM e ORU no ciclo de um exame

Para a laudagem, dois tipos de mensagem HL7 v2 fazem o trabalho pesado, cada um marcando uma ponta do ciclo do exame:

ORM (ordem)

Transporta o pedido de exame: paciente, procedimento, indicação clínica e o accession number. É o gatilho que coloca o exame na worklist a laudar.

ORU (resultado)

Transporta o resultado observado — o laudo — geralmente nos segmentos OBX. É por aqui que o laudo assinado retorna ao RIS/HIS e segue para entrega.

ACK (confirmação)

Cada mensagem é confirmada por um ACK. Sem tratar o ACK, uma mensagem perdida passa despercebida; com ele, a falha é detectada e reprocessada.

Por que HL7 não basta para interoperar de fato

Falar HL7 é necessário, mas não suficiente. O padrão v2 é notório por sua flexibilidade: campos opcionais, segmentos Z proprietários e convenções locais fazem com que duas instituições 'compatíveis com HL7' ainda precisem de mapeamento específico para se entenderem. Por isso a integração real depende de combinar quais campos carregam o quê (o accession number, a indicação, o status), de validar com mensagens reais do ambiente e de prever o comportamento quando um campo esperado vem vazio. É essa disciplina — e não apenas a conformidade com o padrão — que evita laudo amarrado ao exame errado e status que não fecha. Iniciativas como os perfis IHE existem justamente para reduzir essa ambiguidade, padronizando como o HL7 e o DICOM são usados em conjunto.

Termos relacionados

Perguntas frequentes

Quando HL7 para laudos radiológicos faz sentido?

Faz sentido em ambientes que já trocam ordens e resultados via ORM/ORU. Um piloto útil mede material clínico curado, qualidade de revisão, aderência de templates e fricção de integração.

O Laudos.AI usa HL7 v2 ou FHIR?

Ambos. O Laudos.AI suporta HL7 v2 (ORM/ORU), FHIR e DICOM-SR, escolhendo o caminho conforme o ambiente da instituição, com mapeamento por evento e documentação para a TI.

Qual a diferença entre ORM e ORU?

ORM transporta a ordem (o pedido de exame, com o accession number) e coloca o exame na worklist. ORU transporta o resultado observado — o laudo — de volta ao RIS/HIS, tipicamente nos segmentos OBX. Um abre o ciclo do exame; o outro o fecha.

HL7 v2 vai ser substituído por FHIR?

Na prática, os dois coexistem. O HL7 v2 segue dominante no legado hospitalar e não desaparece no curto prazo; o FHIR cresce em integrações novas, APIs e portais. Uma camada de laudo precisa falar ambos e escolher o caminho conforme o ambiente.

A Laudos.AI substitui o radiologista?

Não. A Laudos.AI estrutura e acelera o laudo, mas o médico revisa, edita e assina. O uso é assistivo, sob responsabilidade do radiologista (Resolução CFM 2.454/2026).

Precisa trocar PACS/RIS?

Não. A implantação prevista é conectar a infraestrutura existente e manter o fluxo de laudagem familiar, sem forçar mudança de infraestrutura.

Referências

  1. Health Level Seven International
  2. HL7 FHIR
  3. Integrating the Healthcare Enterprise (IHE)

Estruture seus laudos com o Laudos.AI

Ditado em português com terminologia radiológica, estruturação automática por modalidade, sinalização de achados críticos (CRIT) e integração com seu PACS/RIS atual — com o radiologista sempre no controle.

Agendar demonstração Testar agora

Você é paciente? Este é um material técnico para médicos radiologistas. A Laudos.AI não interpreta exames nem atende pacientes — entenda a quem recorrer.