DICOM: Guía Práctica de Sistemas de Imagen Médica

¿Qué es DICOM y por qué importa en la práctica clínica?

DICOM (Digital Imaging and Communications in Medicine) es el estándar internacional que permite que equipos de tomografía, resonancia magnética, ultrasonido y prácticamente cualquier modalidad de imagen médica se comuniquen entre sí, almacenen estudios y los distribuyan a estaciones de trabajo y sistemas PACS. Sin DICOM, cada fabricante hablaría un idioma diferente y los hospitales necesitarían traductores propietarios para cada par de dispositivos — un escenario que, de hecho, existía antes de los años 1990 y que generaba errores, retrasos y costes innecesarios.

Esta guía está diseñada como un recurso central — un hub — que conecta cinco artículos especializados (los spokes) donde profundizamos en cada aspecto del estándar. El material se basa en el libro Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide, de Oleg S. Pianykh (2.ª edición, Springer, 2012), una referencia obligatoria para radiólogos, físicos médicos y profesionales de TI en salud. Si trabaja en DICOM en la práctica clínica, aquí encontrará el mapa completo para dominar el estándar.

¿Por qué dedicar tiempo a entender DICOM a fondo? Porque los problemas más comunes en un departamento de radiología — imágenes que no llegan al PACS, estudios duplicados, informes asociados al paciente equivocado — casi siempre tienen su raíz en una configuración DICOM incorrecta o en un malentendido del protocolo. Dominar el estándar no es solo una cuestión técnica: es una cuestión de seguridad del paciente.

Introducción al DICOM y Datos Clínicos

DICOM no es solo un formato de imagen: es un marco completo que define cómo se estructuran, etiquetan y transportan los datos clínicos asociados a cada estudio. Comprender esta distinción es el primer paso para cualquier profesional que quiera ir más allá de «la imagen se ve bien en pantalla».

El estándar organiza la información en un Data Dictionary — un catálogo de miles de atributos (o tags) que describen desde el nombre del paciente y la fecha del estudio hasta parámetros técnicos como el espesor de corte o la dosis de radiación. Cada atributo tiene un identificador numérico (por ejemplo, (0010,0010) para el nombre del paciente) y un Value Representation (VR) que define el tipo de dato: texto corto, texto largo, fecha, número entero, secuencia, etc.

¿Por qué importa el VR? Porque determina cómo se codifica el dato en el archivo y cómo lo interpreta el receptor. Un VR incorrecto puede hacer que un nombre de paciente se lea como una cadena de bytes ininteligible, o que una fecha se interprete como un número. Estos errores son más frecuentes de lo que parece, sobre todo cuando se integran equipos de diferentes fabricantes o de diferentes generaciones tecnológicas.

Las partes I y II del libro de Pianykh dedican capítulos enteros a explicar la lógica interna del Data Dictionary, los tipos de VR y cómo se construyen los Information Object Definitions (IODs) — las plantillas que definen qué atributos debe contener cada tipo de imagen (CT, MR, CR, US, etc.). Un IOD de tomografía, por ejemplo, incluye módulos obligatorios como Patient, Study, Series y Image, cada uno con sus atributos requeridos y opcionales.

Entender los IODs es fundamental para diagnosticar problemas de conformance: cuando un equipo envía un objeto DICOM que no cumple con el IOD esperado, el receptor puede rechazarlo o almacenarlo de forma incompleta. Esto ocurre con más frecuencia de la deseable en la práctica diaria.

Profundizamos en estos conceptos, con ejemplos prácticos de lectura del Data Dictionary, en el artículo dedicado: Introducción al DICOM y Datos Clínicos.

Objetos de Comando DICOM y Ejemplos Prácticos

Los objetos de comando son el mecanismo que DICOM utiliza para que dos dispositivos se «pidan cosas» entre sí: almacenar una imagen, buscar un estudio, mover una serie a otra estación. Sin ellos, el Data Dictionary sería un catálogo muerto sin capacidad de acción.

Cada operación en DICOM se expresa como un par de mensajes: un comando (la petición) y un dataset (los datos asociados). Por ejemplo, cuando un equipo de CT envía imágenes al PACS, utiliza el servicio C-STORE: el comando indica «quiero almacenar este objeto» y el dataset contiene la imagen con todos sus atributos. El PACS responde con un mensaje de estado que confirma si la operación fue exitosa o si hubo un error.

Los comandos principales que encontrará en cualquier instalación DICOM son:

• C-STORE: Almacena un objeto (imagen, informe estructurado, etc.) en un destino.
• C-FIND: Busca estudios o pacientes en una base de datos DICOM (el query del mundo radiológico).
• C-MOVE: Solicita que un nodo envíe estudios a otro nodo (frecuente en flujos de pre-fetching).
• C-GET: Similar a C-MOVE, pero la respuesta se envía directamente al solicitante.
• C-ECHO: El «ping» de DICOM — verifica que la conexión entre dos nodos está activa.

Más allá de los servicios estándar, muchos fabricantes definen elementos privados en el Data Dictionary. Estos atributos privados — con tags en rangos impares como (0009,xxxx) — almacenan información propietaria que solo el software del fabricante sabe interpretar. Aunque son legítimos según el estándar, pueden causar problemas de interoperabilidad: un visor genérico no sabrá qué hacer con un atributo privado de Siemens o GE.

El libro de Pianykh dedica un capítulo particularmente útil a la construcción manual de mensajes DICOM y a la interpretación de logs de comunicación. Cuando un C-STORE falla con un estado 0xA700 (out of resources), saber leer ese código de error puede ahorrar horas de diagnóstico.

La conformance — es decir, el grado en que un dispositivo cumple con el estándar — es otro tema central. Un equipo puede soportar C-STORE como SCP (servidor) pero no como SCU (cliente), o puede soportar solo ciertos Transfer Syntaxes. Conocer estas limitaciones antes de la integración evita sorpresas desagradables.

Exploramos cada comando con capturas de tráfico real y ejemplos de configuración en: Objetos de Comando DICOM y Ejemplos Prácticos.

Comunicaciones DICOM y Protocolos de Red

DICOM funciona sobre TCP/IP, pero añade su propia capa de negociación — la asociación — que determina qué servicios y codificaciones se usarán antes de transmitir un solo byte de imagen. Este mecanismo es potente, pero también es la fuente de la mayoría de los problemas de conectividad.

Cuando dos nodos DICOM quieren comunicarse, el proceso sigue estas etapas:

1. Solicitud de asociación (A-ASSOCIATE-RQ): El nodo que inicia la conexión (SCU) envía una propuesta que incluye su AE Title, el AE Title del destino, y una lista de Presentation Contexts — combinaciones de SOP Class (qué tipo de objeto) y Transfer Syntax (cómo se codifica).
2. Respuesta de asociación (A-ASSOCIATE-AC o A-ASSOCIATE-RJ): El servidor (SCP) acepta, rechaza o modifica la propuesta. Si la acepta, selecciona un Transfer Syntax para cada Presentation Context.
3. Intercambio de datos: Una vez establecida la asociación, los nodos intercambian mensajes DIMSE (los comandos que vimos en la sección anterior).
4. Liberación (A-RELEASE): Cuando la comunicación termina, cualquiera de los dos nodos puede solicitar la liberación ordenada de la asociación.

El AE Title (Application Entity Title) es el identificador lógico de cada nodo DICOM en la red. No confunda el AE Title con la dirección IP: un mismo servidor puede tener múltiples AE Titles (uno para el PACS, otro para el RIS, otro para un servicio de impresión). La mayoría de los problemas de «no me conecta» se deben a un AE Title mal configurado o no registrado en el nodo remoto.

Los Transfer Syntaxes definen cómo se codifican los datos en el nivel binario. Las más comunes son:

• Implicit VR Little Endian (1.2.840.10008.1.2) — el «mínimo común denominador» que todo dispositivo DICOM debe soportar.
• Explicit VR Little Endian (1.2.840.10008.1.2.1) — más robusto, incluye el tipo de dato en cada atributo.
• JPEG Lossless, JPEG 2000, RLE — Transfer Syntaxes con compresión, esenciales para optimizar el ancho de banda en redes hospitalarias.

La Parte III del libro de Pianykh es especialmente valiosa porque explica estos conceptos con diagramas de flujo y capturas de paquetes reales. Si alguna vez ha tenido que usar dcmdump o Wireshark para diagnosticar un problema DICOM, apreciará la claridad con que el autor descompone cada campo del protocolo.

DICOM también soporta comunicaciones más modernas. DICOMweb — un conjunto de servicios RESTful que permiten acceder a estudios DICOM vía HTTP/HTTPS — está ganando terreno rápidamente, especialmente en arquitecturas cloud y en visores web. Los servicios principales de DICOMweb son WADO-RS (recuperar objetos), STOW-RS (almacenar) y QIDO-RS (buscar). Aunque el libro de Pianykh se centra en el protocolo DIMSE tradicional, los principios de IODs y Transfer Syntaxes se aplican igualmente a DICOMweb.

Desglosamos la negociación de asociaciones paso a paso, con ejemplos de configuración de AE Titles y resolución de errores de red, en: Comunicaciones DICOM y Protocolos de Red.

Integración con Registros Médicos e Identificación de Pacientes

DICOM no opera en el vacío: los estudios de imagen deben vincularse correctamente al paciente en el sistema de historia clínica (HIS/RIS), y esa vinculación depende de estándares complementarios como HL7. Los errores de identificación son una de las causas más graves de incidentes en radiología.

La identificación del paciente en DICOM se basa en atributos como Patient ID (0010,0020), Patient Name (0010,0010), Accession Number (0008,0050) y Study Instance UID (0020,000D). En un mundo ideal, estos datos se rellenan automáticamente desde el RIS a través de una Modality Worklist (MWL), que es un servicio DICOM (C-FIND sobre la SOP Class de Worklist) que entrega al equipo de imagen la lista de pacientes programados con todos sus datos demográficos y de estudio.

El problema surge cuando la MWL no está disponible, cuando el técnico selecciona el paciente equivocado, o cuando el Patient ID del RIS no coincide con el del HIS. En estos casos, las imágenes llegan al PACS con datos incorrectos, y la reconciliación posterior consume tiempo y crea riesgos de error.

HL7 (Health Level 7) es el estándar de mensajería que conecta los sistemas administrativos del hospital con los clínicos. Mientras DICOM se encarga del transporte de imágenes, HL7 se encarga de los mensajes ADT (admisión, alta, transferencia), ORM (órdenes) y ORU (resultados). La integración DICOM-HL7 es lo que permite que cuando un médico solicita una radiografía en el HIS, la orden aparezca automáticamente en la Modality Worklist del equipo de rayos X.

La Parte IV del libro de Pianykh aborda esta integración con una perspectiva práctica: cómo mapear campos HL7 a atributos DICOM, qué ocurre cuando los account numbers no coinciden, y cómo diseñar un flujo de reconciliación que minimice los errores. Es una lectura especialmente recomendada para quienes gestionan la interfaz entre el PACS y el HIS/RIS.

Un aspecto que merece atención especial es la gestión de pacientes de emergencia. Cuando un paciente llega inconsciente a urgencias, el técnico debe crear un registro temporal. El flujo correcto es: crear un ID temporal en el HIS, enviar la orden a la MWL con ese ID temporal, realizar el estudio, y posteriormente reconciliar el ID temporal con el definitivo cuando se identifique al paciente. Cada paso de este proceso involucra tanto mensajes HL7 como atributos DICOM, y una falla en cualquiera de ellos puede resultar en imágenes «huérfanas».

Analizamos los flujos de identificación, la integración HL7-DICOM y las mejores prácticas de reconciliación en: Integración con Registros Médicos e Identificación de Pacientes.

Flujos de Trabajo Clínicos e Interoperabilidad

La interoperabilidad real no se logra solo con DICOM y HL7: requiere perfiles de integración como los de IHE que definen cómo deben usarse estos estándares en escenarios clínicos concretos. Sin IHE, dos sistemas pueden ser «conformes con DICOM» y aun así no funcionar juntos.

IHE (Integrating the Healthcare Enterprise) es una iniciativa que reúne a profesionales de salud y fabricantes para desarrollar Integration Profiles — documentos que describen, paso a paso, cómo deben interactuar los sistemas en un flujo de trabajo específico. El perfil más conocido en radiología es SWF (Scheduled Workflow), que define el flujo completo desde la solicitud del estudio hasta la distribución del informe.

Otros perfiles IHE relevantes incluyen:

• PIR (Patient Information Reconciliation): Define cómo reconciliar datos de pacientes temporales con los definitivos — exactamente el problema que describimos en la sección anterior.
• CPI (Consistent Presentation of Images): Asegura que las imágenes se visualicen de forma consistente en diferentes estaciones de trabajo, respetando los parámetros de window/level y las anotaciones.
• XDS-I (Cross-Enterprise Document Sharing for Imaging): Permite compartir estudios de imagen entre instituciones diferentes, un requisito cada vez más importante en redes de atención integrada.
• IOCM (Imaging Object Change Management): Gestiona la corrección y eliminación de objetos DICOM — esencial cuando se necesita corregir un estudio asociado al paciente equivocado.

HL7 v3 y FHIR (Fast Healthcare Interoperability Resources) representan la evolución de la mensajería en salud. Mientras HL7 v2.x usa mensajes de texto delimitados por pipes (|), HL7 v3 emplea XML y FHIR utiliza recursos RESTful en JSON o XML. La integración de DICOM con FHIR — a través de recursos como ImagingStudy — está abriendo nuevas posibilidades para acceder a datos de imagen desde aplicaciones móviles y plataformas de inteligencia artificial.

Los Transfer Syntaxes, que mencionamos en la sección de comunicaciones, juegan un papel crucial en la interoperabilidad. La elección entre compresión con pérdida (JPEG Lossy) y sin pérdida (JPEG Lossless, JPEG 2000 Lossless) tiene implicaciones clínicas directas: para diagnóstico primario, la mayoría de las guías recomiendan compresión sin pérdida, mientras que para acceso rápido vía web o para docencia, la compresión con pérdida aceptable puede ser apropiada.

El libro de Pianykh cierra con una visión pragmática de estos temas, reconociendo que el estándar DICOM, con sus más de 20 partes y miles de páginas, puede resultar abrumador. Su consejo es empezar por los fundamentos (Data Dictionary, IODs, servicios básicos) y expandir el conocimiento según las necesidades del entorno de trabajo. Es un consejo que suscribimos plenamente.

Profundizamos en perfiles IHE, FHIR y estrategias de interoperabilidad en: Flujos de Trabajo Clínicos e Interoperabilidad.

Sobre el libro de referencia

Digital Imaging and Communications in Medicine (DICOM): A Practical Introduction and Survival Guide, de Oleg S. Pianykh, es una referencia imprescindible para cualquier profesional que trabaje con imagen médica digital. Publicado por Springer en su segunda edición (2012), el libro destaca por su enfoque práctico y por la capacidad del autor — profesor de radiología en Harvard Medical School — para explicar conceptos técnicos complejos con claridad y humor.

El libro se organiza en cuatro partes:

1. Partes I-II: Fundamentos de DICOM, Data Dictionary, Value Representations, Information Object Definitions.
2. Parte III: Comunicaciones de red, servicios DIMSE, asociaciones, Transfer Syntaxes.
3. Parte IV: Integración con sistemas hospitalarios, HL7, registros médicos, flujos de trabajo.

Lo que distingue esta obra de otros textos sobre DICOM es que no se limita a reproducir el estándar: lo interpreta, lo contextualiza y lo ilustra con situaciones que cualquier profesional de radiología reconocerá. Desde el servidor PACS que rechaza imágenes «porque sí» hasta el técnico que crea pacientes con nombres como «test, test», Pianykh ha visto — y documentado — prácticamente todo lo que puede salir mal en una implementación DICOM.

Para quienes desean complementar esta lectura, recomendamos también nuestro artículo DICOM en la práctica clínica, donde aplicamos varios de los conceptos del libro a escenarios del día a día en hospitales de América Latina y la Península Ibérica.

Conclusión y próximos pasos

DICOM es mucho más que un formato de archivo: es el sistema nervioso de la imagen médica digital. Entender sus fundamentos — desde el Data Dictionary hasta las comunicaciones de red, pasando por la integración con HL7 y los perfiles IHE — es esencial para cualquier profesional que quiera diagnosticar problemas, optimizar flujos de trabajo y garantizar que las imágenes lleguen al médico correcto, del paciente correcto, en el momento correcto.

Esta guía central conecta cinco artículos especializados que profundizan en cada aspecto del estándar:

1. Introducción al DICOM y Datos Clínicos — Data Dictionary, VRs, IODs.
2. Objetos de Comando DICOM y Ejemplos Prácticos — Servicios DIMSE, atributos privados, conformance.
3. Comunicaciones DICOM y Protocolos de Red — Asociaciones, AE Titles, Transfer Syntaxes.
4. Integración con Registros Médicos e Identificación de Pacientes — HL7, Modality Worklist, reconciliación.
5. Flujos de Trabajo Clínicos e Interoperabilidad — IHE, FHIR, workflows.

Le recomendamos comenzar por el artículo que más se relacione con su rol: si es radiólogo o técnico, empiece por los spokes 1 y 4; si es ingeniero de TI o administrador PACS, los spokes 2 y 3 serán su punto de partida natural; y si trabaja en integración de sistemas o gestión de calidad, el spoke 5 le dará la visión panorámica que necesita.

El estándar DICOM sigue evolucionando — con extensiones para patología digital, oftalmología, radioterapia y más — pero sus fundamentos permanecen notablemente estables desde hace décadas. Invertir tiempo en comprenderlos hoy le ahorrará incontables horas de frustración mañana.