En Este Artículo
Qué Es DICOM y Por Qué Sigue Dominando la Imagen Médica
DICOM no es solo un formato de archivo. Esa sigue siendo la confusión más persistente entre los profesionales que ingresan al mundo digital de la radiología. En realidad, el estándar Digital Imaging and Communications in Medicine es un protocolo integral de transferencia, almacenamiento y visualización de datos diseñado para cubrir prácticamente todos los aspectos funcionales de la medicina digital contemporánea.
Concebido en 1983 por un comité conjunto entre el American College of Radiology (ACR) y la National Electrical Manufacturers Association (NEMA), el estándar evolucionó desde una especificación simple de grabación en cinta magnética hasta un ecosistema que sustenta toda la cadena de imágenes médicas. Hoy, todos los equipos digitales de adquisición — tomógrafos, resonancias, ecógrafos — producen imágenes DICOM y se comunican a través de redes DICOM. Para una visión integral de cómo este estándar se integra en la práctica clínica, consulte nuestra guía completa sobre DICOM en la práctica clínica e integración de sistemas de imagen.
¿Qué hace al DICOM insustituible? Tres pilares: calidad diagnóstica excepcional (soporte de hasta 65.536 niveles de gris, contra 256 del JPEG convencional), codificación completa de metadatos clínicos mediante más de 2.000 atributos estandarizados, y definición precisa de funcionalidades de dispositivos a través de las Conformance Statements.
Modelo de Información DICOM: Cómo Se Estructuran los Datos Clínicos
DICOM ve las entidades del mundo real — pacientes, estudios, dispositivos — como objetos descritos por atributos. Estas definiciones se formalizan en las Information Object Definitions (IODs). Un paciente, por ejemplo, se representa mediante atributos como nombre, ID, sexo, edad y peso, capturando toda la información clínicamente relevante.
Este enfoque orientado a objetos puede parecer abstracto, pero resuelve un problema concreto: cuando un tomógrafo envía una imagen al archivo PACS, ambos dispositivos necesitan acordar qué constituye “un examen de TC” — qué campos son obligatorios, cómo formatear fechas, cómo identificar unívocamente cada serie. Las IODs proporcionan ese contrato.
Jerarquía de Información
Los datos DICOM siguen una jerarquía de cuatro niveles: Paciente → Estudio → Serie → Imagen. Cada nivel posee un identificador único (UID) que garantiza la trazabilidad. En la práctica, los Patient IDs duplicados o UIDs de estudio conflictivos se encuentran entre las causas más frecuentes de imágenes “perdidas” o fusionadas erróneamente en el PACS.
Las IODs se componen de Modules (bloques de datos reutilizables) que se agrupan en Information Entities (IEs). Esta arquitectura modular permite que diferentes modalidades compartan módulos comunes — como el Patient Module — mientras agregan módulos específicos para datos de CT, MR o ecografía.
VRs y Diccionario de Datos: La Gramática del DICOM
Si las IODs definen qué almacenar, las Value Representations (VRs) definen cómo almacenarlo. DICOM especifica 27 tipos de VR que funcionan como la gramática del estándar. Existen VRs para textos cortos (SH, LO), textos largos (ST, LT, UT), fechas y horarios (DA, TM, DT), números en formato texto (IS, DS), números binarios (SS, US, SL, UL, FL, FD), nombres de personas (PN), identificadores de entidades (AE) e identificadores únicos (UI).
Cada VR tiene reglas específicas de longitud y codificación de caracteres. Un campo tipo AE (Application Entity Title), por ejemplo, acepta un máximo de 16 caracteres — una limitación que, sorprendentemente, todavía causa problemas cuando los administradores intentan configurar nombres demasiado descriptivos en los dispositivos.
Diccionarios de Datos Estándar y Privados
El DICOM Data Dictionary cataloga todos los atributos estandarizados con sus tags (grupo, elemento), VRs, multiplicidad y descripción. Pero los fabricantes frecuentemente necesitan almacenar datos propietarios — y para eso existe el mecanismo de Private Data Dictionaries. Tags con números de grupo impares están reservados para uso privado, permitiendo que cada fabricante extienda el estándar sin conflictos con los atributos oficiales.
Codificación de Objetos DICOM
En la práctica, un objeto DICOM es una secuencia ordenada de Data Elements, cada uno compuesto por un tag (identificador numérico de 4 bytes), el VR, la longitud del valor y el valor propiamente dicho. Los elementos pueden anidarse mediante el tipo SQ (Sequence), habilitando estructuras jerárquicas complejas — como una lista de procedimientos programados dentro de una worklist.
Comunicaciones DICOM: SOPs, DIMSE y Asociaciones
Los dispositivos en la red DICOM se denominan Application Entities (AEs), identificados por un AE Title, dirección IP y puerto. Toda comunicación sigue el modelo Service-Object Pair (SOP): un servicio asociado al tipo de dato que procesa.
DICOM define roles claros: quien solicita un servicio es el Service Class User (SCU), y quien lo provee es el Service Class Provider (SCP). Un tomógrafo almacenando imágenes en el PACS actúa como CT Storage SCU, mientras que el archivo actúa como CT Storage SCP. El mismo dispositivo puede cambiar de rol — cuando el archivo necesita imprimir, se convierte en Print SCU frente a la impresora DICOM.
Servicios DIMSE Fundamentales
Los servicios se implementan a través del protocolo DIMSE (DICOM Message Service Element), que ofrece operaciones como:
- C-Echo: el “ping” DICOM — verifica la conectividad entre dos AEs
- C-Store: transfiere objetos (imágenes, informes) para almacenamiento
- C-Find: consulta el catálogo de estudios/pacientes en el archivo
- C-Move / C-Get: recupera imágenes almacenadas en el PACS
- MWL (Modality Worklist): sincroniza la lista de trabajo del RIS con la modalidad
La diferencia entre C-Move y C-Get es una fuente frecuente de confusión. C-Get transfiere imágenes directamente al solicitante, mientras que C-Move instruye al servidor a enviar las imágenes a un tercer AE — útil cuando la estación de visualización no es la misma que realizó la consulta.
Establecimiento de Asociación
Antes de cualquier intercambio de datos, dos AEs deben negociar una asociación. En esta fase de “handshake”, intercambian Presentation Contexts — combinaciones de Abstract Syntax (el SOP a utilizar) y Transfer Syntax (cómo se codificarán los datos: Little Endian, Big Endian, comprimido). Si no se encuentra un contexto compatible, la asociación es rechazada.
En mi experiencia, la mayoría de las fallas de conectividad DICOM se resuelven verificando tres elementos: AE Title correcto, puerto abierto en el firewall y Transfer Syntax compatible en ambos lados.
Medios DICOM: Archivos, DICOMDIR y Seguridad
El formato de archivo DICOM sigue una estructura específica: un preámbulo de 128 bytes, el prefijo “DICM”, un grupo de meta-información (Group 0002) con la Transfer Syntax del archivo y finalmente el objeto de datos. Este formato permite que cualquier software identifique inequívocamente un archivo DICOM.
El DICOMDIR funciona como un índice jerárquico para medios removibles (CDs, DVDs, pendrives). Mapea pacientes, estudios, series e imágenes en una estructura navegable sin requerir base de datos. Aunque pueda parecer anticuado en la era del cloud, el DICOMDIR sigue siendo esencial para la transferencia de exámenes entre instituciones que no poseen conectividad de red directa.
Almacenamiento en PACS
El PACS puede almacenar datos DICOM de tres formas: file-based (archivos en el filesystem), database-based (datos binarios en la base de datos), o modelos mixtos (metadatos en la base de datos, píxeles en archivo). Cada enfoque tiene compensaciones de rendimiento versus simplicidad de respaldo que deben evaluarse según el volumen de la institución.
Seguridad y Anonimización
La seguridad DICOM es, históricamente, un punto débil del estándar. Las redes DICOM tradicionales operan sin cifrado, y el protocolo fue diseñado antes de las preocupaciones modernas de privacidad. La anonimización de datos DICOM — eliminación o sustitución de atributos identificables (nombre, fecha de nacimiento, IDs) — está regulada por la parte PS3.15 y el Supplement 142, pero en la práctica requiere atención a detalles como datos “burned-in” en las imágenes (anotaciones renderizadas en los píxeles).
El estándar soporta TLS para comunicaciones de red y formatos de archivo seguro con cifrado, pero la adopción sigue siendo limitada. Las instituciones que manejan telerradiología o investigación multicéntrica deben priorizar VPNs y procesos rigurosos de des-identificación.
Errores Comunes y Limitaciones del DICOM
Tras años trabajando con integración DICOM, ciertos patrones de error se repiten con impresionante consistencia. Reconocerlos puede ahorrar semanas de troubleshooting.
| Error | Causa Típica | Solución |
|---|---|---|
| Imágenes no llegan al PACS | AE Title incorrecto o puerto bloqueado | Verificar Conformance Statement y configuración de red |
| Estudios fusionados erróneamente | Patient ID duplicado entre pacientes | Implementar MPI o reconciliación de IDs |
| Imagen “corrupta” en visualización | Transfer Syntax no soportada por el viewer | Verificar compresión (JPEG2000 vs JPEG Lossless) |
| Worklist vacía en la modalidad | Falla en la integración HL7/MWL | Validar mapeo de campos entre RIS y modalidad |
Cuándo DICOM No Es Suficiente
A pesar de su robustez, DICOM tiene limitaciones reales. El estándar no gestiona nativamente el workflow clínico (para eso existe IHE), no sustituye la integración HL7/FHIR entre HIS/RIS, y su modelo de seguridad nativo es insuficiente para entornos expuestos a internet. Dispositivos etiquetados como “DICOM-Ready” frecuentemente significan que la funcionalidad DICOM es una opción paga aparte — un detalle que puede sorprender a administradores desprevenidos.
Micro Caso de Estudio: Migración de PACS
Una clínica de diagnóstico por imagen con 3 tomógrafos, 2 resonancias y 15 estaciones decidió migrar de un PACS legacy (10 años) a una solución moderna. El inventario DICOM reveló que uno de los tomógrafos soportaba únicamente JPEG Lossless como Transfer Syntax de compresión, mientras que el nuevo PACS esperaba JPEG 2000. Resultado: el 40% de las imágenes históricas necesitaron transcodificación — un proceso que llevó 3 semanas para un archivo de 18 TB. La lección: validar las Transfer Syntax compatibles antes de firmar el contrato de migración.
