Transferência de Imagiologia Médica: Guia Técnico Completo

Uma única tomografia cardíaca pode atingir 2 GB — demasiado grande para qualquer sistema de email, demasiado sensível para uma partilha pública de ficheiros, e classificada como dado de saúde especialmente protegido pelo RGPD e pelas orientações da CNPD. A transferência de imagiologia médica move ficheiros DICOM, NIFTI e formatos proprietários de radiologia entre sistemas PACS, médicos referenciadores, especialistas e doentes — tipicamente via DICOMweb (WADO-RS, STOW-RS, QIDO-RS), IHE XDS-I, SFTP direto ou carregamento web encriptado. O método correto depende do tamanho do ficheiro, do tipo de destino e de o outro sistema comunicar nativamente em DICOM.

DICOM, NIFTI e o Que Está Efetivamente a Transferir

Antes de escolher o método de transferência, é essencial conhecer o formato. O DICOM (Digital Imaging and Communications in Medicine) agrupa dados de pixel com etiquetas de metadados — nome do doente em (0010,0010), UID do estudo em (0020,000D), modalidade em (0008,0060). Um estudo de RM típico é uma pasta com centenas de ficheiros .dcm, cada um correspondendo a um corte. O NIFTI (.nii ou .nii.gz) é o formato de neuroimagiologia para investigação que consolida um volume inteiro num único ficheiro.

Intervalos de tamanho típicos:

Radiografia torácica: 10-30 MB
TC de crânio: 50-200 MB
RM abdominal: 300 MB-1 GB
RM cardíaca com cine: 500 MB-2 GB
Imagem de patologia de lâmina inteira (.svs, .ndpi): 1-4 GB por lâmina
Série de tarefa fMRI: 500 MB-2 GB; estudo completo: 10-40 GB

Escolha a ferramenta de transferência com base no ficheiro maior que irá enviar, não no ficheiro médio.

DICOMweb: O Protocolo Moderno

O DICOMweb, definido em DICOM PS3.18, substitui o antigo protocolo DIMSE por HTTP. Os três serviços principais:

STOW-RS (Store Over the Web, RESTful) — envia instâncias DICOM para /studies via POST multipart/related
WADO-RS (Web Access to DICOM Objects, RESTful) — recupera /studies/{StudyInstanceUID} via GET
QIDO-RS (Query based on ID) — pesquisa estudos e séries com parâmetros de consulta

O DICOMweb corre sobre TLS 1.3 e é compatível com tokens OAuth 2.0, razão pela qual PACS modernos como o Orthanc, dcm4chee e Ambra Health o suportam. Se dois sistemas hospitalares comunicam ambos em DICOMweb, não é necessária uma ferramenta de transferência separada — apenas um gateway configurado corretamente.

Quando o DICOMweb Não É Uma Opção

A maioria das transferências reais acontece entre sistemas que não partilham um gateway. Um hospital distrital envia uma tomografia de trauma para um centro terciário. Um doente leva a sua RM para um especialista. Um centro de investigação envia dados de fMRI para um centro coordenador de dados. Nestes casos, as alternativas são:

SFTP (RFC 4253 com OpenSSH) — fiável para transferências programadas entre pontos conhecidos, mas fraco em auditoria orientada ao utilizador
IHE XDS-I.b — o perfil de interoperabilidade para imagiologia entre empresas, usado por HIEs como a Carequality; pesado de implementar
Carregamento web encriptado — a escolha pragmática para transferências pontuais ou ad-hoc, especialmente quando o doente está no circuito
Suporte físico — um CD gravado com o perfil IHE PDI ainda acontece, embora em declínio

Desidentificação Antes da Transferência

Os cabeçalhos DICOM são densos em dados pessoais de saúde. O DICOM Standard PS3.15 Anexo E define o Perfil Básico de desidentificação, que lista mais de 400 etiquetas a remover, substituir ou esvaziar. Erros comuns:

Deixar anotações gravadas nos dados de pixel — requerem OCR e redação, não apenas alterações de cabeçalho
Esquecer etiquetas privadas em intervalos (0009,xxxx) onde os fabricantes armazenam números de série do equipamento
Manter o UID da Instância do Estudo, o que permite a religação se o atacante tiver o original

Para dados de investigação ao abrigo do RGPD, a desidentificação mais TLS 1.3 mais AES-256-GCM em repouso é a base mínima. Os dados clínicos que circulam entre médicos que tratam o mesmo doente não requerem desidentificação, mas continuam a precisar de encriptação — e de um registo de auditoria conforme com o que a CNPD espera.

Compressão, Sintaxe de Transferência e Largura de Banda

Os ficheiros DICOM podem ser armazenados sem compressão (Implicit VR Little Endian, UID de Sintaxe de Transferência 1.2.840.10008.1.2) ou com JPEG 2000 sem perdas (1.2.840.10008.1.2.4.90), JPEG-LS ou RLE. A compressão sem perdas em dados de TC poupa tipicamente 50-60%. A compressão com perdas é um campo minado médico-legal — muitos serviços de radiologia proíbem-na inteiramente para uso diagnóstico.

Para imagens de patologia de lâmina inteira, o JPEG 2000 ou o mais recente tiling do Suplemento DICOM 145 reduz significativamente o tamanho da transferência. Para fMRI, o gzip em NIFTI (.nii.gz) é o padrão e reduz os ficheiros 3-5 vezes.

Numa ligação simétrica de 100 Mbps, uma RM cardíaca de 2 GB demora cerca de 3 minutos à velocidade máxima. Numa instalação com 10 Mbps de upload, são 30 minutos. Planifique em conformidade — ou utilize um serviço de transferência que retoma em caso de desconexão.

Transferências Controladas pelo Doente

Um fluxo de trabalho crescente: o doente chega à consulta com o especialista, entrega uma pen USB ou acede ao seu portal de doente, e o especialista importa as imagens. As regras de acesso à informação reforçadas pela legislação europeia tornam isto um direito do doente — e as normas de interoperabilidade exigem que as entidades de saúde o suportem.

Para este percurso, é necessário um método de transferência que um doente sem formação técnica consiga utilizar. Um formulário web onde coloca os ficheiros, encripta do lado do cliente com uma palavra-passe e envia o link por SMS para a clínica funciona. Sem conta, sem pedido ao departamento de informática. O HexaTransfer adapta-se a este padrão — AES-256-GCM do lado do cliente, link partilhável, palavra-passe fora de banda. Experimente em https://hexatransfer.com — gratuito, sem conta, máximo de 10 GB.

Cadeia de Custódia para Teleradiologia

Os serviços de teleradiologia dependem de pipelines de transferência que os auditores podem rastrear hora a hora. Os elementos essenciais:

Hash SHA-256 registado no PACS de envio e verificado na estação de leitura
Registo de eventos com marca temporal incluindo número de acesso e ID do radiologista leitor
Retenção dos registos de transferência pelo período especificado pelas leis de registo clínico — frequentemente 7-10 anos após o último contacto do doente
Eliminação automática da área de staging da transferência após confirmação de receção

Gestão do Limite de 10 GB nas Transferências Web

A maioria dos serviços de transferência web limita as transferências individuais a 2-10 GB. Para transferências acima do limite, as opções são:

Dividir em pacotes lógicos — uma visita, uma modalidade, uma série por transferência
Transporte físico — um dispositivo encriptado com LUKS ou VeraCrypt para situações ad-hoc de grande volume
Ligação dedicada — VPN hospitalar ou ligação point-to-point para fluxos de alto volume recorrentes

Conheça o seu limite antes de prometer um prazo de entrega.

Integração com PACS Sem Perturbar as Leituras

A regra fundamental: não interrompa a lista de trabalho do radiologista. Se o fluxo de transferência toca no PACS, encaminhe por um nó de staging (o Orthanc ou o dcm4chee como router DICOM funciona bem) para que o PACS de produção só receba estudos validados. Etiquete as transferências recebidas com um AE title distinto para que apareçam numa lista de trabalho separada até um técnico as validar.

Para transferências de saída, uma ação "Enviar para Externo" com um único clique no PACS que encaminha para a ferramenta de transferência retira o radiologista do fluxo de encriptação — que é exatamente o que ele quer.

Verificação e Entrega

Após cada transferência, verifique:

Contagem de ficheiros corresponde (número de ficheiros .dcm ou volumes NIFTI)
SHA-256 do arquivo corresponde entre remetente e destinatário
Pelo menos uma imagem abre no visualizador receptor
Os metadados não foram corrompidos — nome do doente, data do estudo e número de acesso são legíveis

Registe a verificação no registo de transferência. "Enviámos" não é uma defesa; "enviámos e confirmámos a integridade ao nível do byte" é. A transferência de imagiologia médica não é apenas mover bytes — é mover um registo diagnóstico de que o cuidado de alguém depende, por vezes em minutos.