HL7 para laudos radiológicos com IA
HL7 continua sendo a língua de muitos hospitais. A Laudos.AI trata a integração como projeto operacional, não como promessa vaga: mapeamento por evento, fallback e monitoramento, e documentação para a TI. Uma mensagem HL7 v2 é uma sequência de segmentos delimitados por carriage return, cada um começando por um código de três letras (MSH, PID, PV1, ORC, OBR, OBX) e dividido em campos por barra vertical (|), com componentes por circunflexo (^). O segmento MSH abre toda mensagem e declara o tipo e o trigger event — por exemplo, ORM^O01 para um pedido e ORU^R01 para um resultado — além de um Message Control ID usado para correlacionar a resposta ACK. O pedido chega no par ORC/OBR (com o número do pedido, a modalidade e o procedimento solicitado) e o laudo volta em segmentos OBX, em que cada OBX carrega um valor observado com seu tipo de dado (TX para texto, ED ou RP para um anexo/referência ao PDF ou DICOM SR). O radiologista continua revisando, editando e assinando; a integração HL7 transporta o conteúdo, não a decisão clínica.
O que é HL7
HL7 é o padrão de mensageria que muitos sistemas hospitalares (HIS, RIS, PACS) usam para trocar pedidos e resultados. Na Laudos.AI, a integração HL7 v2 consome mensagens ORM^O01 para abrir o exame com contexto (identificação do paciente no PID, encontro no PV1, pedido no ORC/OBR) e emite ORU^R01 com o laudo revisado de volta ao sistema de origem, com o status do resultado no campo apropriado do OBR/OBX (por exemplo, P para preliminar e F para final). Cada mensagem recebida é respondida com um ACK — AA quando aceita, AE/AR quando há erro de aplicação ou rejeição — para que o emissor saiba se precisa reenviar. Para ambientes mais novos, há suporte a FHIR R4 (DiagnosticReport e ImagingStudy), trocados sobre HTTP/REST com JSON em vez de pipes e segmentos. A mensageria conecta os sistemas existentes — o médico segue responsável pela revisão e assinatura.
Como conecta
A integração deve tirar trabalho administrativo, não criar outra tela. A integração boa começa pequena e auditável.
- Recebe ORM^O01 (pedido) e lê PID (paciente), PV1 (encontro) e ORC/OBR (pedido, modalidade, procedimento) para abrir o exame com contexto.
- Responde toda mensagem com ACK (AA/AE/AR) referenciando o Message Control ID, para que o emissor saiba se houve aceitação ou erro.
- Mapeamento de campos por segmento e trigger event, documentado para a equipe de TI no perfil de conformidade da interface.
- Emite ORU^R01 com o laudo revisado em segmentos OBX, status do resultado (P/F) e referência ao PDF/DICOM SR de volta ao HIS/RIS.
- Transporte por MLLP sobre TCP, com os bytes de início/fim de bloco que enquadram cada mensagem, em conexão dedicada ou VPN.
- Fila persistente com reenvio em caso de NAK ou timeout, evitando perda ou duplicação de mensagem.
Quando faz sentido
Trocar ORM/ORU em ambientes hospitalares legados que falam HL7 v2 sobre MLLP.
Sincronizar status de exame (preliminar/final) entre HIS, RIS e PACS.
Reduzir digitação administrativa e recortes manuais entre sistemas.
Migrar gradualmente para FHIR R4 mantendo a interface v2 enquanto o ambiente moderniza.
Por que Laudos.AI
- Mapeamento por segmento e trigger event, validado em ambiente de teste com mensagens reais anonimizadas.
- ACK/NAK tratados e fila persistente com reenvio para entrega confiável.
- Documentação técnica (perfil de conformidade da interface) para a TI conduzir a implantação.
- Suporte tanto a v2 (legado, pipes e segmentos) quanto a FHIR R4 (REST/JSON) sob a mesma integração.
Escopo técnico
Entrada
Mensagens ORM^O01 com MSH (tipo, trigger, control ID), PID, PV1 e ORC/OBR (pedido, modalidade, procedimento) e limites de dados confirmados.
Saída
Mensagens ORU^R01 com segmentos OBX (texto e status P/F do resultado) e referência ao laudo (PDF/DICOM SR) devolvidas ao sistema de origem.
Operação
Transporte MLLP/TCP em conexão dedicada/VPN, ACK por mensagem e ambiente de teste antes de produção.
Erros
ACK AE/AR para erro de aplicação ou rejeição, tratamento de falha de parsing de segmento e detecção de duplicata por Message Control ID.
Monitoramento
Logs por mensagem com control ID, fila persistente com reenvio em NAK/timeout e alerta de canal indisponível para a TI.
Padrões suportados
HL7 v2 ORM^O01
Pedido de exame: segmentos MSH/PID/PV1/ORC/OBR com identificação e procedimento.
HL7 v2 ORU^R01
Resultado/laudo: segmentos OBX com valor observado, tipo de dado e status (P/F).
MLLP / TCP
Minimal Lower Layer Protocol: enquadramento de bloco para transportar v2 sobre TCP.
ACK / NAK
Confirmação de aplicação (AA/AE/AR) correlacionada pelo Message Control ID.
HL7 FHIR R4
DiagnosticReport e ImagingStudy sobre REST/JSON para ambientes modernos.
DICOM SR
Referência ao laudo estruturado anexada ao OBX do resultado.
Segurança e residência de dados (Brasil)
Conformidade com a LGPD (Lei 13.709/2018), Encarregado de Proteção de Dados (DPO) designado e trilha de auditoria por usuário responsável.
- Canais HL7 sobre conexão dedicada/VPN com criptografia em trânsito (MLLP sobre TLS quando suportado).
- Residência de dados em infraestrutura no Brasil quando contratada, inclusive para o motor de integração.
- Ambiente de teste com mensagens sintéticas ou anonimizadas antes de produção; nunca dado real sem base legal.
- Conformidade LGPD com DPO designado, política de privacidade publicada e trilha de auditoria por mensagem e usuário.
Critérios de decisão
Controle médico
A ORU só sai com o laudo revisado e assinado; o status F (final) reflete a assinatura do radiologista.
Integração real
Mapeamento por segmento e trigger que encaixa na interface v2 do HIS/RIS legado.
Entrega confiável
ACK/NAK e fila com reenvio garantem que nenhum resultado se perca em silêncio.
Governança
Logs por Message Control ID e permissões auditáveis.
Produtividade mensurável
Menos digitação e status sincronizado, medidos em piloto.
Meça em 30 dias. Não compre por promessa.
Perguntas frequentes
Quando HL7 para laudos radiológicos com IA faz sentido?
Quando o hospital troca ORM/ORU em sistemas legados e quer sincronizar status sem digitação manual. A integração faz sentido após medir material clínico curado, qualidade de revisão, aderência de templates e fricção de integração em um piloto.
A Laudos.AI suporta FHIR além do HL7 v2?
Sim. Para ambientes mais novos há suporte a FHIR R4 (DiagnosticReport e ImagingStudy), trocados sobre REST/JSON. Para ambientes legados, o HL7 v2 com mensagens ORM^O01 e ORU^R01 sobre MLLP segue sendo a opção mais comum, e as duas podem coexistir durante a modernização.
Onde o laudo entra na mensagem ORU?
No corpo de segmentos OBX. Cada OBX carrega um valor observado com seu tipo de dado — TX para o texto do laudo e ED ou RP para anexar/referenciar o PDF ou o objeto DICOM SR. O status do resultado (preliminar ou final) acompanha o OBR/OBX, refletindo se o laudo já foi assinado.
O que acontece se uma mensagem chegar malformada ou em duplicidade?
A interface responde com ACK de erro (AE para erro de aplicação, AR para rejeição) referenciando o Message Control ID, e o emissor pode reenviar. Mensagens repetidas com o mesmo control ID são detectadas como duplicata e não geram exame ou laudo a mais.
Como o laudo final se distingue de um preliminar na troca HL7?
Pelo campo de status do resultado nos segmentos OBR/OBX: P indica preliminar e F indica final. A Laudos.AI só marca o resultado como final quando o radiologista revisou e assinou; antes disso, qualquer envio segue como preliminar.
Onde ficam os dados — região, criptografia e retenção?
Os dados trafegam criptografados em trânsito e em repouso, com residência em infraestrutura no Brasil quando contratada e política de retenção definida em contrato. O tratamento segue a LGPD, com Encarregado de Proteção de Dados (DPO) designado e trilha de auditoria por usuário responsável.
A Laudos.AI substitui o radiologista?
Não. A Laudos.AI estrutura e acelera o laudo, mas o médico revisa, edita e assina. A responsabilidade clínica e a assinatura permanecem sempre com o radiologista, preparado para a Resolução CFM 2.454/2026 sobre uso de inteligência artificial em medicina.
Precisa trocar PACS/RIS?
Não. A implantação prevista é conectar a infraestrutura existente e manter o fluxo de laudagem familiar. A integração começa pequena e auditável, encaixando-se no PACS, RIS e worklist que o serviço já usa.
Referências
- Health Level Seven International · 2024
- Health Level Seven International · 2023
- Insights into Imaging (Bruls & Kwee) · 2020 · DOI: 10.1186/s13244-020-00925-z
- Journal of Digital Imaging (Forsberg et al.) · 2017 · DOI: 10.1007/s10278-016-9911-z
Conecte HL7 ao Laudos.AI sem trocar de PACS/RIS
Implantação assistida por engenheiro, ambiente de teste com dados sintéticos ou anonimizados e piloto de 30 dias com métricas de tempo, retrabalho e padronização. O radiologista revisa, edita e assina.