Skip to main content

Objetos DICOM y Codificación de Datos: Lo Que Todo Profesional Necesita Saber

Si trabajas con imágenes médicas, seguramente te has encontrado con situaciones donde un examen simplemente «no abre» o aparece corrupto en otro sistema. En la mayoría de los casos, el problema radica en cómo los datos DICOM están codificados y estructurados internamente. Comprender cómo funcionan los objetos DICOM no es mera curiosidad técnica — es la habilidad que marca la diferencia entre el profesional que resuelve problemas y el que solo los reporta.

En este artículo, profundizaremos en la anatomía de los objetos DICOM: cómo se codifican los elementos de datos, la diferencia entre codificación implícita y explícita, el funcionamiento de las secuencias SQ y la jerarquía Patient-Study-Series-Image. Para una visión general completa del estándar DICOM, consulta nuestra guía práctica completa de DICOM para sistemas de imagen médica.

Diccionario de Datos Privados y Comandos DICOM

Tabla comparativa de codificación implícita y explícita de elementos de datos DICOM con ejemplos binarios
Codificación implícita vs. explícita de VR en DICOM

El Diccionario de Datos DICOM (PS3.6) mapea cada atributo del mundo real a una etiqueta numérica en formato (Grupo, Elemento). Pero, ¿qué sucede cuando un fabricante necesita almacenar información propietaria que no existe en el diccionario estándar?

La respuesta está en los grupos privados — grupos con numeración impar reservados exclusivamente para datos propietarios del fabricante. Por ejemplo, TeraRecon utiliza el grupo 0077 en su sistema Aquarius para almacenar atributos como (0077,0010) para UIDs originales de series y (0077,0020) para nombres de datos binarios. Cada fabricante elige su propio grupo impar, garantizando que sus datos propietarios no colisionen con el estándar.

Los comandos DICOM — como Print, Store, Move y Get — se codifican en el grupo reservado 0000. El elemento (0000,0100) identifica el tipo de comando, mientras que (0000,0110) almacena el ID del mensaje. A diferencia de los elementos de datos, DICOM no permite atributos de comando propietarios, lo que limita la flexibilidad del protocolo para escenarios modernos como la telerradiología.

Limitaciones del Sistema de Comandos Actual

El conjunto de comandos DICOM fue diseñado para arquitecturas PACS locales que resultan cada vez más obsoletas. Los proyectos modernos de imagen digital — telerradiología, integración en la nube, flujos de trabajo con IA — demandan estructuras de comando más flexibles. La imposibilidad de crear etiquetas propietarias en comandos sigue siendo un tema de debate activo en la comunidad DICOM. Para comprender cómo operan los comandos en la práctica, nuestro artículo sobre fundamentos DICOM: objetos y comunicaciones explora los servicios DIMSE en detalle.

Codificación Implícita vs. Explícita: Cómo DICOM Escribe los Datos

Toda la información en DICOM se convierte en secuencias de bytes mediante dos métodos fundamentales de codificación: implícita y explícita. La elección entre ambos afecta directamente cómo tus sistemas interpretan los datos.

Codificación Implícita (VR Implícito)

Con la codificación implícita — el estándar por defecto en DICOM —, cada elemento de datos sigue esta estructura:

  • Tag: 4 bytes (2 para Grupo + 2 para Elemento)
  • Longitud del valor: 4 bytes (entero de 32 bits)
  • Valor: $L$ bytes de datos

Consideremos el nombre del paciente «Smith^Joe»: el elemento (0010,0010) se codifica en 18 bytes. Los primeros 4 bytes representan la etiqueta en Little Endian (10 00 10 00), los siguientes 4 bytes indican la longitud $L = 10$ (0A 00 00 00), y los últimos 10 bytes contienen la cadena «Smith^Joe » con un espacio de relleno para mantener la longitud par.

Nota Técnica: DICOM utiliza Little Endian por defecto, es decir, en números multi-byte, el byte menos significativo se escribe primero. El número 0010 aparece como 10 00 en la secuencia binaria.

Codificación Explícita (VR Explícito)

La codificación explícita agrega el tipo VR al elemento y se divide en dos variantes:

Para VRs estándar (excepto OB, OW, OF, SQ, UT, UN): el campo de 4 bytes de longitud se reemplaza por 2 bytes de tipo VR + 2 bytes de longitud. Para el mismo «Smith^Joe», veríamos: 10 00 10 00 50 4E 0A 00 53 6D... — donde 50 4E son los caracteres ASCII «PN» que indican Person Name.

Para VRs especiales (OB, OW, OF, SQ, UT, UN): después de los 2 bytes de VR, hay 2 bytes reservados (siempre 0000) seguidos de 4 bytes para la longitud. Esta variante acomoda elementos con datos potencialmente muy grandes, como búferes de píxeles.

¿Cuándo Usar Cada Método?

No es posible mezclar codificación implícita y explícita en el mismo objeto DICOM. Esta decisión se negocia entre las aplicaciones antes de cualquier intercambio de datos, mediante los Transfer Syntaxes. En mi experiencia, la codificación explícita es preferible en escenarios de interoperabilidad porque lleva la información de tipo junto a los datos, reduciendo errores de decodificación — especialmente con atributos propietarios ausentes del diccionario estándar.

Objetos DICOM y Secuencias SQ: Estructuras Anidadas

Diagrama de codificación SQ mostrando anidamiento de objetos DICOM con elementos de datos en múltiples niveles
Estructura de anidamiento de objetos DICOM con SQ

Un objeto DICOM es, en esencia, una colección ordenada de elementos de datos. Cada imagen médica, comando o informe se encapsula en este formato. Los elementos dentro de un objeto se organizan en orden ascendente de etiquetas — esta ordenación no es solo una convención, sino una herramienta de validación: si un elemento con una etiqueta menor aparece después de uno mayor, el objeto está corrupto.

La verdadera complejidad surge con el tipo VR SQ (Sequence). Los elementos SQ no contienen datos simples — encapsulan secuencias de otros objetos DICOM, creando una estructura tipo árbol. Piensa en un libro: los capítulos contienen secciones, que a su vez contienen subsecciones. De igual manera, un objeto DICOM puede contener objetos anidados en múltiples niveles.

Codificación de Secuencias SQ

Cada objeto dentro de una secuencia SQ está precedido por la etiqueta de delimitación (FFFE,E000), seguida por:

  • Longitud explícita: un valor numérico que indica cuántos bytes ocupa el objeto
  • Longitud indefinida: el valor FFFFFFFF, donde el final del objeto se marca con la etiqueta (FFFE,E00D)

La secuencia SQ completa también puede tener longitud explícita o indefinida. En el segundo caso, el final se marca con (FFFE,E0DD). Este enfoque con delimitadores es análogo a las etiquetas XML de apertura y cierre — y en la práctica, resulta más confiable que la longitud explícita.

Consejo Práctico: Si implementas software DICOM, prefiere delimitadores de longitud indefinida al escribir secuencias SQ. Son más simples de implementar y menos susceptibles a errores de cálculo. Sin embargo, tu aplicación debe ser capaz de leer ambos formatos, ya que otros fabricantes pueden usar longitud explícita.

Ejemplo Práctico: Referenced Series Sequence

Un caso real de anidamiento SQ es el atributo (0008,1115) — Referenced Series Sequence. En el nivel 0, tenemos el SQ; en el nivel 1, aparece el Series Instance UID (0020,000E) junto con otra secuencia (0008,114A); y en el nivel 2, encontramos los UIDs de referencia (0008,1150) y (0008,1155). Si programas codificación SQ, implementarla con recursión es algo natural — como cualquier estructura de datos tipo árbol.

Jerarquía de Información DICOM: Patient-Study-Series-Image

Jerarquía de información DICOM Patient-Study-Series-Image con UIDs de identificación única
Jerarquía DICOM: del paciente a la imagen individual

DICOM organiza toda la información en cuatro niveles jerárquicos que reflejan el flujo clínico real: Paciente → Estudio → Serie → Imagen.

  • Paciente: identificado por Patient ID (0010,0020)
  • Estudio: identificado por Study Instance UID (0020,000D)
  • Serie: identificada por Series Instance UID (0020,000E)
  • Imagen: identificada por SOP Instance UID (0008,0018)

Esta jerarquía existe porque en la práctica clínica, un paciente puede tener múltiples estudios (CT, RM, US), cada estudio contiene series con diferentes protocolos, y cada serie tiene una o más imágenes. Los UIDs garantizan que cada entidad sea globalmente única — formato UI con hasta 64 caracteres compuestos por dígitos y puntos, como 1.2.840.10008.1.2.

Identificadores Únicos (UIDs): ¿Por Qué Son Globales?

Imagina una imagen de rayos X copiada, anotada y enviada para lectura telerradiológica en otro país. Ahora existen varias instancias de la misma imagen original, cada una potencialmente modificada. ¿Cómo diferenciarlas? Mediante UIDs distintos para cada instancia. La estructura de un UID es <org root>.<suffix>, donde el root identifica la organización y el sufijo garantiza la unicidad dentro del alcance.

Errores Comunes en la Estructuración DICOM y Cómo Evitarlos

Tras años trabajando con integración de sistemas de imagen, ciertos problemas aparecen con frecuencia preocupante:

1. Patient ID inconsistente: Hospitales que asignan IDs diferentes al mismo paciente dependiendo de la modalidad o el destino de las imágenes. He visto casos donde el ID «W/I» (without ID) se asignaba a todos los pacientes sin registro, fusionando efectivamente decenas de pacientes en un solo registro del PACS. Si no hay ID disponible, usar iniciales con fecha de nacimiento (ej: JS19670102) es infinitamente mejor que un valor genérico.

2. Elementos obligatorios ausentes: Los digitalizadores de películas frecuentemente encapsulan imágenes en formato DICOM sin incluir todas las etiquetas obligatorias (Tipo 1). Un Patient ID en blanco puede interpretarse como comodín, fusionando pacientes diferentes en el archivo. Los objetos DICOM sin elementos requeridos se consideran ilegales según el estándar.

3. Etiquetas Group Length incorrectas: La etiqueta (gggg,0000) almacenaba la longitud total de un grupo. Aunque fue retirada desde 2008, muchas implementaciones aún la escriben incorrectamente. ¿El resultado? Software DICOM conservador puede rechazar el objeto completo. La recomendación actual: no la incluyas, pero debes saber leerla cuando esté presente.

Cuándo NO Intentar Interpretar Datos DICOM Manualmente

Existen escenarios donde intentar parsear objetos DICOM manualmente genera más problemas de los que resuelve:

  • UIDs como fuente de datos: Nunca extraigas información (fechas, IDs de paciente) a partir del UID. DICOM prohíbe explícitamente esta práctica — los UIDs pueden modificarse en cualquier momento
  • Conversión implícita a explícita con etiquetas propietarias: Si un atributo de grupo impar no existe en el diccionario estándar, la conversión a VR explícito puede fallar. Usa el tipo UN (Unknown) en estos casos
  • Objetos con SQ de múltiples niveles y longitud explícita: Un error de 1 byte en el valor de longitud hace que toda la secuencia posterior sea ilegible. Prefiere delimitadores de longitud indefinida

La comprensión profunda de la codificación DICOM es lo que permite diagnosticar problemas de interoperabilidad que las herramientas automatizadas no pueden resolver. Para dominar los conceptos fundamentales del estándar, no dejes de leer nuestra guía completa sobre DICOM en la práctica clínica.

Leave a Reply