Transferencia de imágenes médicas: guía técnica completa

El RGPD y la LOPDGDD clasifican las imágenes médicas como datos de salud de categoría especial. Una TC cardíaca pesa entre 500 MB y 2 GB; una imagen de histología de sección completa alcanza los 4 GB; un dataset de fMRI de investigación puede llegar a los 40 GB por sujeto. Elegir el método de transferencia correcto depende del tamaño del archivo, el tipo de destinatario y si el otro extremo habla DICOM de forma nativa o necesita algo que un ordenador convencional pueda abrir.

DICOM, NIFTI y qué estás moviendo exactamente

Antes de elegir el método de transferencia, identifique el formato. DICOM (Digital Imaging and Communications in Medicine) envuelve los datos de píxeles con etiquetas de metadatos: nombre del paciente en (0010,0010), UID del estudio en (0020,000D), modalidad en (0008,0060). Un estudio de RM típico es una carpeta de cientos de archivos .dcm, uno por corte. NIFTI (.nii o .nii.gz) es el formato de neuroimagen de investigación que empaqueta un volumen completo en un único archivo. Los formatos propietarios de fabricante —exportaciones de la consola de GE, archivos de Siemens syngo.via— a veces se envían como archivos .tar que el visor DICOM debe desempaquetar.

Rangos de tamaño:

• Radiografía de tórax: 10-30 MB
• TC de cabeza: 50-200 MB
• RM abdominal: 300 MB-1 GB
• RM cardíaca con cine: 500 MB-2 GB
• Histología de sección completa (.svs, .ndpi): 1-4 GB por corte
• Ejecución de tarea fMRI: 500 MB-2 GB; estudio completo: 10-40 GB

Ajuste la herramienta de transferencia al archivo más grande que vaya a enviar, no al tamaño medio.

DICOMweb: el protocolo de red moderno

DICOMweb, definido en DICOM PS3.18, reemplaza el antiguo protocolo DIMSE con HTTP. Tres servicios fundamentales:

• STOW-RS (Store Over the Web, RESTful): envía instancias DICOM mediante POST a /studies
• WADO-RS (Web Access to DICOM Objects, RESTful): recupera estudios mediante GET a /studies/{StudyInstanceUID}
• QIDO-RS (Query based on ID): busca estudios y series con parámetros de consulta

DICOMweb funciona sobre TLS 1.3 y es compatible con tokens de portador OAuth 2.0, razón por la que PACS modernos como Orthanc, dcm4chee y Ambra Health lo soportan. Si dos sistemas hospitalarios hablan DICOMweb, no necesita una herramienta de transferencia adicional, sino una pasarela configurada entre ellos.

Cuándo DICOMweb no es una opción

La mayoría de transferencias reales suceden entre sistemas que no comparten una pasarela. Un hospital comarcal envía una TC de trauma a un centro de referencia. Un paciente lleva su RM externa a un especialista. Un centro de investigación envía datos de fMRI a un centro coordinador. En estos casos:

1. SFTP (RFC 4253 con OpenSSH): fiable para transferencias programadas entre endpoints conocidos, pero débil en la experiencia de auditoría para el usuario
2. IHE XDS-I.b: el perfil de interoperabilidad para imagen entre empresas, usado por redes HIE como Carequality; costoso de desplegar
3. Subida web cifrada: la opción pragmática para transferencias puntuales o ad hoc, especialmente cuando el paciente está en el circuito
4. Soporte físico: un CD con perfil IHE PDI sigue existiendo, aunque los hospitales van eliminando las unidades ópticas

Desidentificación antes de la transferencia

Las cabeceras DICOM son densas en información identificable. El estándar DICOM PS3.15 Anexo E define el Perfil Básico para la desidentificación, que lista más de 400 etiquetas a eliminar, reemplazar o vaciar. Herramientas como DicomAnonymizer, CTP (Clinical Trial Processor) y dcmdeid de dcm4che lo implementan. Errores habituales:

• Dejar anotaciones quemadas en los datos de píxel: requieren OCR y redacción, no solo cambios de cabecera
• Olvidar las etiquetas privadas en rangos (0009,xxxx) donde los fabricantes almacenan números de serie del escáner
• Conservar el Study Instance UID, que permite la re-vinculación si el atacante tiene los datos originales

Para datos de investigación bajo el RGPD, la desidentificación más TLS más AES-256-GCM en reposo es el suelo mínimo.

Compresión, sintaxis de transferencia y ancho de banda

Los archivos DICOM pueden almacenarse sin comprimir (Implicit VR Little Endian, Transfer Syntax UID 1.2.840.10008.1.2) o con JPEG 2000 sin pérdida (1.2.840.10008.1.2.4.90), JPEG-LS o RLE. La compresión sin pérdida en datos de TC suele ahorrar entre el 50 y el 60 %. La compresión con pérdida es un campo minado médico-legal; muchos servicios de radiología la prohíben completamente para uso diagnóstico.

Para histología de sección completa, JPEG 2000 o el tiling del Suplemento DICOM 145 reduce drásticamente el tamaño de transferencia. Para fMRI, gzip sobre NIFTI (.nii.gz) es estándar y comprime los archivos 3-5 veces.

En un enlace simétrico de 100 Mbps, una RM cardíaca de 2 GB tarda unos 3 minutos a velocidad de línea. Con una subida de 10 Mbps, son 30 minutos. Planifique en consecuencia —o use un servicio de transferencia que reanude en caso de desconexión.

Transferencias controladas por el paciente

Un flujo creciente: el paciente acude a la consulta del especialista con un USB o las credenciales de su portal de salud, y el especialista importa las imágenes. El derecho de portabilidad del artículo 20 del RGPD y el European Health Data Space (EHDS) respaldan este acceso.

Para este flujo, necesita un método de transferencia que un paciente no técnico pueda usar. Un formulario web donde suba archivos, cifre en el lado del cliente con una frase de contraseña, y envíe la contraseña a la clínica por canal separado funciona. Sin cuenta, sin ticket de soporte. HexaTransfer encaja en este patrón: AES-256-GCM en el lado del cliente, enlace compartible, frase de contraseña fuera de banda. Pruébelo en https://hexatransfer.com — sin cuenta, hasta 10 GB, gratuito.

Cadena de custodia para teleradiología

Los servicios de teleradiología dependen de canales de transferencia que los auditores puedan rastrear hora a hora. Los elementos esenciales:

• Hash SHA-256 registrado en el PACS emisor y verificado en la estación de lectura
• Registro de eventos con marca temporal que incluye número de acceso e ID del radiólogo lector
• Retención de registros de transferencia durante el período especificado por la normativa española de historia clínica —habitualmente 5 años desde el último acto asistencial, más para registros pediátricos
• Purga automática del área de staging de transferencia tras confirmar la recepción, para que el servidor de staging no se convierta en un archivo en la sombra

Gestionar el límite de 10 GB en transferencias web

La mayoría de servicios de transferencia web tienen un límite de 2-10 GB por transferencia individual. Para transferencias por encima de ese umbral, las opciones son:

• Dividir en lotes lógicos: una visita, una modalidad, una serie por transferencia
• Envío físico: un disco duro cifrado con LUKS o VeraCrypt en mensajería urgente para casos ad hoc
• Enlace dedicado: VPN hospitalaria o conexión directa para flujos de alto volumen recurrentes

Conozca su límite antes de prometer un plazo al destinatario.

Integración con PACS sin interrumpir las lecturas

La regla fundamental: no rompa la lista de trabajo del radiólogo. Si su flujo de transferencia toca el PACS, enrute a través de un nodo de staging (Orthanc o dcm4chee como enrutador DICOM funciona bien) para que el PACS de producción solo reciba estudios validados. Etiquete las transferencias entrantes con un AE title distintivo para que aparezcan en una lista de trabajo separada hasta que un técnico las valide mediante control de calidad.

Para transferencias salientes, una acción "Enviar a externo" con un solo clic en el PACS que enrute a su herramienta de transferencia mantiene al radiólogo fuera del flujo de cifrado —que es exactamente lo que quieren. Sueltan el estudio, la herramienta cifra y el clínico del otro extremo recibe un enlace.

Verificación y entrega

Tras cada transferencia, verifique:

1. El recuento de archivos coincide (número de archivos .dcm o volúmenes NIFTI)
2. El SHA-256 del archivo coincide entre remitente y receptor
3. Al menos una imagen se abre en el visor receptor
4. Los metadatos no se han corrompido: nombre del paciente, fecha del estudio y número de acceso son legibles

Registre la verificación en el expediente de transferencia. "Lo enviamos" no es una defensa suficiente; "lo enviamos y confirmamos la integridad byte a byte" sí lo es. La transferencia de imagen médica no es solo mover bytes: es mover un registro diagnóstico del que depende la atención de alguien, a veces en cuestión de minutos.