Visor de Etiquetas DICOM vs PACS: Discrepancias

Introducción: El mismo estudio, dos verdades distintas

Abre un archivo DICOM en un visor independiente y lee (0010,0020) ID del Paciente como 00451234. Luego abre el mismo estudio en el PACS y el ID del Paciente muestra 451234. La misma imagen, el mismo SOP Instance UID, dos valores diferentes. Para un profesional de TI en radiología este es uno de los escenarios de diagnóstico más comunes — y más desconcertantes — porque ambos sistemas muestran “la verdad”, solo que en etapas distintas del ciclo de vida del dato.

La respuesta breve es que los bytes en disco no son el único lugar donde vive el valor de una etiqueta. Entre el equipo y la pantalla, un valor puede ser coercionado, normalizado, almacenado en caché, recodificado o sobrescrito por un registro de base de datos que ya no coincide con el objeto original. Entender dónde puede divergir cada capa es la clave para resolver la discrepancia con rapidez. Puede inspeccionar el objeto sin procesar con nuestro Visor de Etiquetas DICOM en línea y comparar elemento por elemento con el Explorador de Etiquetas DICOM.

Causa 1: Coerción del PACS en el Storage SCP

La causa más común de una discrepancia entre el visor y el PACS es la coerción de atributos. Cuando un equipo envía un objeto mediante C-STORE, el Storage SCP receptor está autorizado —según el estándar DICOM, PS3.4 Anexo B.4.1 (comportamiento de la Storage Service Class)— a modificar ciertos atributos para reforzar la consistencia con el Objeto de Información que ya posee. En la práctica, los archivos PACS coercionan los atributos de identidad y agrupación para que los objetos entrantes coincidan con los datos demográficos resueltos desde el RIS a través de la Modality Worklist.

Los atributos coercionados con más frecuencia son (0010,0010) Nombre del Paciente, (0010,0020) ID del Paciente, (0020,000D) Study Instance UID y (0008,0050) Número de Acceso. Cuando el SCP reescribe un atributo coercionado, el estándar recomienda registrar el valor original en la Original Attributes Sequence, etiqueta (0400,0561), con el sistema modificador y el motivo capturados en los elementos anidados (0400,0563) Modifying System y (0400,0565) Reason for the Attribute Modification. Así que cuando su visor muestra el valor que envió el equipo y el PACS muestra el valor coercionado, el objeto sin procesar que exportó puede ser la copia previa a la coerción, o el PACS puede estar mostrando su registro de base de datos en lugar de la cabecera de los píxeles almacenados.

Cómo confirmarlo: exporte el objeto directamente desde el PACS (un C-MOVE o la función de “exportar original” del PACS) y busque (0400,0561). Si la Original Attributes Sequence está presente y lista el valor de su visor como el original, la coerción es la causa y el valor del PACS es el autoritativo.

Causa 2: Tag morphing a lo largo de la cadena de enrutamiento

Muchas organizaciones enrutan las imágenes a través de un router DICOM, un motor de integración o un archivo neutral de proveedor (VNA) antes del PACS. Cada salto puede aplicar un conjunto de reglas de mapeo de etiquetas —denominado informalmente tag morphing— que reescribe atributos para normalizar entre proveedores. Un router puede eliminar ceros iniciales del ID del Paciente, poner en mayúsculas los componentes del Nombre del Paciente, reformatear (0008,0020) Fecha del Estudio o inyectar un emisor en (0010,0021) Issuer of Patient ID.

Si capturó el archivo antes del router (por ejemplo, desde un registro de envío del equipo) y el PACS conserva la versión posterior al morphing, todos los atributos transformados diferirán. La solución es identificar el nodo exacto que aplicó el cambio. La mayoría de los routers registran una auditoría por objeto; correlacione por SOP Instance UID (0008,0018), que las reglas de morphing nunca deberían alterar. Si el SOP Instance UID coincide pero las etiquetas de identidad difieren, una regla de morphing es la responsable, y debería revisar si esa regla es la pretendida.

Causa 3: Diferencias de juego de caracteres y codificación

Un valor puede ser idéntico byte a byte en disco y, sin embargo, renderizarse de forma diferente porque el visor y el PACS interpretan (0008,0005) Specific Character Set de manera distinta. DICOM PS3.5 Sección 6.1 rige el manejo del juego de caracteres. Si un archivo omite Specific Character Set, el repertorio por defecto es ISO-IR 6 (el subconjunto DICOM de ASCII). Un nombre de paciente con caracteres acentuados —común en nombres en español, francés o alemán— almacenado bajo ISO-IR 100 (Latin-1) mostrará los acentos correctos en un visor conforme, pero puede aparecer con caracteres alterados o sustituidos en un PACS que asume otra página de códigos, o viceversa.

Esta es una verdadera discrepancia de renderizado, no de valor almacenado: los bytes subyacentes coinciden, pero los glifos mostrados difieren. Confírmelo examinando el hex crudo del valor PN y el juego de caracteres declarado. Si (0008,0005) falta o es inconsistente con el contenido real de bytes, el sistema que muestra está adivinando, y tiene un fallo de conformidad de codificación en lugar de un problema de integridad de datos.

Causa 4: Caché obsoleta de la base de datos del PACS

Los sistemas PACS separan el objeto almacenado (la cabecera y los datos de píxeles en disco) del registro indexado en base de datos usado para consultas rápidas y visualización de listas de trabajo. Los valores que ve en la vista de lista del PACS, el navegador de estudios y el banner del paciente provienen normalmente de la base de datos, poblada en el momento de la ingesta. Si un estudio se editó después —una fusión de pacientes, una corrección de número de acceso, una actualización del MPI— la base de datos se actualiza, pero la cabecera del objeto almacenado original puede no reescribirse.

El resultado: su visor lee la cabecera en disco (valor antiguo) mientras el PACS muestra el registro corregido de la base de datos (valor nuevo). Este es el comportamiento esperado, pero sorprende a los ingenieros que asumen que la cabecera del archivo es la fuente de verdad. El estándar DICOM no exige reescribir el objeto almacenado ante una corrección demográfica; muchos archivos conservan el objeto original de forma inmutable y aplican correcciones solo en las capas de base de datos y exportación. Confírmelo revisando la pista de auditoría del PACS en busca de un evento de fusión o edición vinculado al mismo Study Instance UID.

Un árbol de decisión rápido

• El SOP Instance UID coincide, solo difieren las etiquetas de identidad: sospeche coerción (Causa 1) o morphing (Causa 2). Revise (0400,0561).
• Los bytes coinciden pero los glifos difieren: sospeche del manejo del juego de caracteres (Causa 3). Revise (0008,0005).
• El valor de la interfaz del PACS difiere de toda copia exportada: sospeche de un registro de base de datos obsoleto o corregido (Causa 4). Revise la auditoría del PACS.
• El propio objeto exportado difiere de una captura del lado del equipo: un nodo aguas arriba lo reescribió; recorra la cadena de enrutamiento salto por salto.

Causa 5: Sintaxis de transferencia y reinterpretación de VR implícito

Cuando un archivo se almacena con VR implícito Little Endian (UID de sintaxis de transferencia 1.2.840.10008.1.2), la Representación de Valor no se escribe en el archivo; el analizador debe inferirla de un diccionario de datos. Según DICOM PS3.5 Sección 7.1.3, un visor con un diccionario incompleto o específico de proveedor puede leer mal el VR de una etiqueta privada, interpretando un número como cadena o truncando un valor, mientras que el PACS —usando un diccionario más completo— lo lee correctamente. Esto afecta sobre todo a etiquetas privadas (números de grupo impares) donde ambos sistemas discrepan sobre la disposición de los elementos del creador privado. Si el valor de una etiqueta privada parece plausible en una herramienta y ruido binario en otra, una discrepancia de inferencia de VR es la causa probable.

Causa 6: Campos multivaluados y relleno

Los valores de cadena DICOM se rellenan hasta una longitud par, y los elementos multivaluados usan la barra invertida como delimitador de valores (PS3.5 Sección 6.2). Un espacio final, un byte de relleno nulo o una barra invertida extra pueden hacer que dos valores lógicamente iguales parezcan diferentes. Un ID del Paciente almacenado como 451234\ (con relleno de espacio final) es igual, bajo las reglas de coincidencia DICOM, a 451234, pero un visor ingenuo que no recorta el relleno mostrará la diferencia. Cuando una discrepancia es un único carácter de espacio inicial o final, casi siempre se trata del manejo del relleno, y los valores son equivalentes a efectos de coincidencia según la semántica de consulta/recuperación de PS3.4 Anexo C.

Un método disciplinado de resolución

Resolver estas discrepancias de forma fiable se reduce a anclarse en el único identificador que nunca debería cambiar: el SOP Instance UID (0008,0018). Con eso fijo, trabaje hacia afuera:

• Obtenga una copia canónica. Exporte el objeto directamente desde el PACS, no desde una caché aguas abajo ni un registro previo al enrutamiento, para comparar con el objeto almacenado autoritativo del archivo.
• Compare las cabeceras. Abra ambas copias y compare elemento por elemento. El Explorador de Etiquetas DICOM facilita recorrer los grupos y detectar qué elementos divergen.
• Inspeccione (0400,0561). La Original Attributes Sequence es su evidencia más rápida de coerción y le indica quién cambió qué y por qué.
• Revise el juego de caracteres y el relleno. Descarte diferencias de solo renderizado antes de escalar a una investigación de integridad de datos.
• Recorra la cadena de enrutamiento. Si el objeto difiere de una captura del lado del equipo, encuentre el nodo y la regla responsables.

Para una base más profunda sobre qué significa cada etiqueta y cómo se formatean los valores, consulte nuestra referencia de campo, Etiquetas DICOM. Los documentos rectores a tener a mano son DICOM PS3.4 (especificaciones de Service Class, incluida la coerción y la coincidencia de consultas), DICOM PS3.5 (estructuras de datos y codificación, que cubre VR, juegos de caracteres y relleno) y DICOM PS3.6 (el diccionario de datos). Toda discrepancia que encuentre se resuelve en un comportamiento definido en una de estas tres partes.

Conclusión

Un valor de etiqueta que difiere entre su visor y el PACS rara vez es una corrupción y casi nunca es aleatorio. Es la costura visible entre las capas del flujo de imagen: los bytes que envió el equipo, los atributos que coercionó el archivo, las reglas que aplicó un router, el juego de caracteres que asumió un renderizador y el registro de base de datos que muestra la interfaz del PACS. Al anclarse en el SOP Instance UID, exportar la copia autoritativa y leer la Original Attributes Sequence, puede atribuir cualquier discrepancia a un mecanismo específico y documentado — y decidir con confianza qué valor es el correcto.