Dicom Tools

DICOM Value Representations (VR): Referencia Completa

Introducción: Por Qué las Value Representations Son la Gramática de DICOM

Si un tag DICOM es un sustantivo — el nombre de una pieza de metadatos — entonces la Value Representation, o VR, es la gramática que te dice cómo leerlo. La VR es un código de dos letras adjunto a cada elemento DICOM estándar que define el tipo de dato, las reglas de codificación y las restricciones de longitud del valor que sigue. Sin conocer la VR, no puedes interpretar de forma fiable el contenido de un tag. Con la VR, sabes si tratar los bytes como texto ASCII, enteros con signo, fechas ISO 8601 o una secuencia anidada de items.

Para los ingenieros de TI radiológica, las VRs aparecen constantemente: cuando un nombre se muestra como “DOE^JOHN^A” en lugar de “John A. Doe”, cuando una fecha se renderiza como “19650715” en lugar de un formato localizado, cuando las herramientas de migración se quejan de “valor demasiado largo para la VR” o cuando un elemento privado se niega a parsearse porque la VR es incorrecta. Este artículo es una referencia práctica de las VRs DICOM más comunes que encontrarás, las reglas de formato que cada una aplica y los gotchas que pillan a los equipos por sorpresa.

Puedes inspeccionar las VRs de cualquier archivo DICOM con nuestro Visor de Tags DICOM. Para fundamentos sobre la estructura del tag, consulta nuestra referencia para TI radiológica. Para el problema relacionado de tags específicos del fabricante, consulta nuestra explicación de tags privados DICOM.

Cómo Se Almacenan las VRs: Implícita vs Explícita

DICOM define dos convenciones de transfer syntax que afectan a dónde vive la VR en el archivo:

  • VR Implícita: La VR no se almacena en el archivo. Cada elemento es solo (grupo, elemento, longitud, valor). El lector busca la VR en el data dictionary público según el tag. Es más antigua y menos robusta porque no maneja tags privados cuyas VRs son desconocidas para el lector.
  • VR Explícita: La VR de dos letras se almacena en el archivo directamente después del tag, antes de la longitud del valor. Es el default moderno y lo que producen la mayoría de modalidades y PACS hoy.

Cuando el parseo falla en un tag privado, la causa suele ser que el archivo usa VR implícita y el lector no tiene entrada para el tag privado en su diccionario. Cambiar a transfer syntax con VR explícita en la exportación normalmente lo resuelve.

VRs de Cadena: Las Categorías Más Comunes

La mayoría de tags DICOM llevan datos de texto, codificados en ASCII o, desde que el estándar añadió soporte de Specific Character Set, en sets ISO_IR y Unicode. Aquí las VRs de cadena que más verás en metadatos radiológicos:

LO — Long String (máx 64 caracteres)

Cadena de texto libre hasta 64 caracteres. Usada para identificadores legibles como Manufacturer (0008,0070), Manufacturer’s Model Name (0008,1090) y Series Description (0008,103E). Los espacios solo son significativos dentro de la cadena — los espacios al inicio y al final normalmente se eliminan al leer.

SH — Short String (máx 16 caracteres)

Misma idea que LO pero limitada a 16 caracteres. Usada para códigos e identificadores cortos como Accession Number (0008,0050) y Station Name (0008,1010). El límite de 16 caracteres pilla a equipos que intentan poner identificadores largos de sistemas externos en números de accession; valores más largos de 16 son no conformantes.

LT — Long Text (máx 10240 caracteres)

Texto libre para campos largos como Image Comments (0020,4000) o Study Comments (0032,4000). Permite saltos de línea y la mayoría de caracteres imprimibles. Suele ser donde acaba el PHI en texto libre si los técnicos teclean contexto clínico en campos de comentario.

ST — Short Text (máx 1024 caracteres)

Como LT pero más corto. Usado para Institution Address (0008,0081) y campos descriptivos de longitud media similares.

UT — Unlimited Text

Sin límite de longitud. Usado para campos descriptivos muy largos, como Pixel Data Provider URL (0028,7FE0) en algunos escenarios. La longitud de UT es de 4 bytes en lugar de 2.

CS — Code String (máx 16 caracteres)

Código enumerado tomado de un set definido de valores, p.ej., Modality (0008,0060) con valores como “CT”, “MR”, “US”, “XA”, “CR”. Los valores CS están en mayúsculas, no pueden tener espacios al inicio ni al final, y se limitan a un alfabeto pequeño (mayúsculas, dígitos, espacio, guion bajo). Es una de las VRs validadas más estrictamente.

UI — Unique Identifier (máx 64 caracteres)

Identificador estilo OID con notación punto-decimal. Usado para cada UID en DICOM: Study Instance UID, Series Instance UID, SOP Instance UID, SOP Class UID, Transfer Syntax UID. Los valores UI consisten solo en dígitos y puntos, no deben tener ceros a la izquierda en componentes y deben ser globalmente únicos.

VR de Nombre: PN

La VR PN codifica nombres de personas estructurados. Los componentes están separados por carets en este orden: apellido^nombre^segundo^prefijo^sufijo. Múltiples variantes — alfabética, ideográfica, fonética — se separan por signos de igual.

Ejemplos:

  • DOE^JUAN^A — apellido DOE, nombre JUAN, segundo A
  • SMITH^JANE^^DR — apellido SMITH, nombre JANE, sin segundo, prefijo DR
  • YAMADA^TARO=山田^太郎 — representación alfabética = ideográfica

PN es una de las fuentes más comunes de bugs. Las capas de display deben quitar los carets para renderizar “Doe, Juan A.” preservando la forma canónica para emparejado. Los scripts de migración que recortan o reformatean nombres ingenuamente rompen los matches del worklist.

VRs de Fecha y Hora: DA, TM, DT

DA — Date (8 caracteres)

Formato: YYYYMMDD. Ejemplo: 19650715 es 15 de julio de 1965. Usado para Patient’s Birth Date (0010,0030), Study Date (0008,0020) y similares. Sin separador y sin zona horaria; la fecha se interpreta en la zona del sitio originador.

TM — Time (máx 16 caracteres)

Formato: HHMMSS.FFFFFF con segundos fraccionarios opcionales. Ejemplo: 143000 es 14:30:00. Sistemas antiguos pueden emitir 14:30:00 con dos puntos; el DICOM conformante no usa separadores.

DT — DateTime (máx 26 caracteres)

Formato combinado: YYYYMMDDHHMMSS.FFFFFF&ZZXX, donde el sufijo opcional &ZZXX codifica el offset UTC (+0500, -0800, etc.). DT se usa para campos como Acquisition DateTime (0008,002A) donde la precisión sub-segundo y la zona horaria importan para sincronizar entre modalidades.

VRs Numéricas: DS, IS, US, SS, UL, SL, FL, FD

  • DS — Decimal String: Número almacenado como texto ASCII, p.ej., "112.5". Usado para Pixel Spacing, Slice Thickness y muchos campos de medida. Fácil de leer pero permite múltiples representaciones textuales del mismo valor ("1.0" vs "1" vs "1.00").
  • IS — Integer String: Entero almacenado como texto ASCII, p.ej., "256". Usado para Series Number, Instance Number, Number of Frames.
  • US — Unsigned Short (16 bits): Entero binario sin signo de 16 bits. Usado para Rows (0028,0010), Columns (0028,0011) y Bits Allocated (0028,0100).
  • SS — Signed Short (16 bits): Entero binario con signo de 16 bits. Menos común; aparece en algunos campos relacionados con pixel data.
  • UL — Unsigned Long (32 bits): Entero binario sin signo de 32 bits. Usado para longitud de Pixel Data y contadores grandes.
  • SL — Signed Long (32 bits): Entero binario con signo de 32 bits.
  • FL — Floating Point Single (32 bits IEEE 754): Usado para algunos campos de calibración y orientación.
  • FD — Floating Point Double (64 bits IEEE 754): Usado para campos float de alta precisión como volúmenes de ROI o timing detallado.

La distinción entre numéricos codificados como cadena (DS, IS) y numéricos binarios (US, UL, FL, FD) importa porque las reglas de codificación y los cálculos de longitud difieren. DS e IS soportan elementos multi-valor separados por backslash \\; los numéricos binarios usan arrays de bytes crudos.

VRs Binarias: OB, OW, OF, OD, OL

Estas VRs llevan blobs binarios cuya interpretación depende del contexto:

  • OB — Other Byte: Stream de bytes. Usado para pixel data comprimido, ciertos blobs privados y el elemento Pixel Data (7FE0,0010) cuando se almacena como bytes.
  • OW — Other Word (16 bits): Stream de words de 16 bits. Usado para Pixel Data cuando cada píxel se almacena como valor de 16 bits.
  • OF — Other Float (32 bits): Stream de floats de 32 bits.
  • OD — Other Double (64 bits): Stream de doubles de 64 bits.
  • OL — Other Long (32 bits): Stream de enteros sin signo de 32 bits.

SQ — Sequence: la VR Recursiva

La VR Sequence es una de las más importantes y más malentendidas. SQ contiene una lista de cero o más items, donde cada item es a su vez un dataset completo de tags. Las secuencias aparecen por todo DICOM — en Referenced Image Sequence, Coding Scheme Identification Sequence, Procedure Code Sequence y muchas otras.

Esquemáticamente:

(0040,0260) SQ  Performed Protocol Code Sequence
Item 1
(0008,0100) SH Code Value "CT-ABD-CON"
(0008,0102) SH Coding Scheme "LOCAL"
(0008,0104) LO Code Meaning "TC Abdomen con Contraste"
Item 2
(0008,0100) SH Code Value "CT-ABD-NOC"
...

Leer SQ correctamente requiere parseo recursivo: el parser entra en cada item, lee sus elementos hijos como si fueran un dataset top-level, y luego sale. Las herramientas que aplanan secuencias en una sola lista pierden la estructura y pueden producir reportes engañosos.

Otras VRs Útiles

  • AS — Age String (4 caracteres): Formato nnnD, nnnW, nnnM o nnnY para días, semanas, meses o años. Usado para Patient’s Age (0010,1010).
  • AE — Application Entity (máx 16 caracteres): Un AE Title usado en asociaciones de red DICOM. Sensible a mayúsculas/minúsculas.
  • AT — Attribute Tag: Un valor de tag usado como dato, útil en campos tag-pointer.
  • UC — Unlimited Characters: Como SH/LO pero sin límite de longitud; introducida más recientemente.
  • UR — URI/URL: Un URI RFC 3986, usado en campos que referencian recursos externos.

Pitfalls Comunes con VR en la Práctica

  • Valores SH truncados: Poner un número de accession de 20 caracteres en el límite SH de 16 lleva a truncamiento o rechazo. O acorta el identificador origen o muévelo a un campo LO.
  • Valores CS en minúsculas: Algunos sistemas legacy emiten valores CS en minúsculas como “ct”. Lectores estrictamente conformantes pueden rechazarlos. Normaliza a mayúsculas antes de transmitir.
  • Drift de formato de fecha: Sistemas antiguos pueden emitir DA como 1965-07-15 con separadores. PACS modernos esperan 19650715 crudo.
  • Orden de componentes PN: Mezclar apellido y nombre al separar PN con carets produce nombres que aparecen invertidos en visores.
  • Redondeo DS: Decimal Strings pueden codificar valores con muchos dígitos; ir y volver entre binary float y DS puede causar drift de precisión.
  • VR implícita con tags privados: Si un archivo usa transfer syntax de VR implícita y contiene tags privados desconocidos para el lector, esos valores pueden renderizarse como bytes crudos o saltarse por completo.

Mejores Prácticas al Trabajar con VRs

  • Siempre inspecciona la VR junto al valor al depurar. Un valor “raro” suele tener una VR perfectamente correcta que lo explica.
  • Prefiere transfer syntax con VR explícita para exportación, especialmente cuando hay tags privados involucrados.
  • Valida longitudes de cadena contra los límites de la VR antes de escribir o transmitir. Muchos bugs se cazan aquí.
  • Usa el data dictionary público del estándar como única fuente de verdad para VRs de tags públicos. No infieras.
  • Para campos SQ, preserva el orden de los items durante el procesamiento; los consumidores downstream pueden depender de él.
  • Al manejar valores DA / TM / DT, almacénalos en forma canónica internamente y solo formatea para mostrar.

Conclusión

Las Value Representations son la gramática que convierte un mar de bytes hex en datos tipados e interpretables. Dominar las VRs comunes — LO, SH, CS, UI, PN, DA, TM, DS, IS, US, OB, SQ — y sus restricciones es esencial para cualquiera que depure DICOM, construya integraciones o migre archivos. Usa un visor que exponga la VR junto al valor, valida inputs contra las reglas de VR y trata los límites de longitud y los separadores de componentes con respeto. Continúa con nuestros artículos compañeros sobre tags privados DICOM y codificación de tags DICOM en disco, y la referencia de campos de tag para el contexto más amplio.

← Volver al Blog