Tags Privados DICOM Explicados: Cómo Leerlos y Por Qué Importan

Introducción: La Mitad Oculta de los Metadatos DICOM

Cada archivo DICOM en un entorno radiológico lleva dos conjuntos paralelos de metadatos. El primero es el diccionario público estándar — tags como Patient Name (0010,0010), Study Instance UID (0020,000D) o Pixel Spacing (0028,0030). Están definidos por el estándar DICOM y se comportan de forma consistente entre fabricantes. El segundo conjunto es el mundo de los tags privados: elementos específicos del fabricante que no aparecen en el Data Dictionary público y que los fabricantes añaden para codificar información propietaria que el estándar no cubre.

Los tags privados están en todas partes. Casi cada imagen TC, RM, ultrasonido o fluoroscopia que sale de una modalidad moderna los incluye. Almacenan parámetros de reconstrucción, identificadores de protocolo específicos del fabricante, resultados de inferencia de IA y a veces — problemáticamente — identificadores de paciente y nombres de operador que el estándar coloca en otros sitios. Como los tags privados están por definición fuera del estándar, son también la fuente más común de fallos de de-identificación y dolores de cabeza en migraciones.

Este artículo explica qué son los tags privados, cómo leerlos con seguridad, por qué existe el mecanismo de private creator y cómo manejarlos al limpiar PHI o transferir estudios entre archivos. Puedes seguir el flujo inspeccionando cualquier archivo DICOM con nuestro Visor de Tags DICOM o explorando el data dictionary en el Explorador de Tags DICOM. Para el modelo mental fundamental, empieza por nuestra referencia sobre estructura de tags DICOM para TI radiológica.

¿Qué Hace que un Tag DICOM Sea “Privado”?

Cada tag DICOM se identifica por un par de números hexadecimales de 16 bits (GGGG,EEEE): número de grupo y número de elemento. El estándar define una regla simple: los tags cuyo número de grupo es impar son privados. Así que (0019,1010), (0029,0010) y (7053,1003) son todos privados. Los tags públicos usan grupos pares: (0008,xxxx), (0010,xxxx), (0028,xxxx).

Dentro de un grupo impar, los elementos 0010 a 00FF están reservados para identificadores de private creator. Son cadenas cortas de texto que nombran al “dueño” de un bloque de elementos privados. Una vez que un creator ha reservado un bloque, los datos privados reales viven en elementos entre xx00 y xxFF, donde xx son los dos dígitos hex que coinciden con el slot de reserva del creator.

El mecanismo existe para que dos fabricantes distintos puedan almacenar sus propios datos en el grupo impar 0019 sin colisionar. El Fabricante A puede reservar el bloque 10 con la cadena “SIEMENS MR HEADER”, mientras el Fabricante B reserva el bloque 11 con “GEMS_PARM_01”. Sus elementos privados viven entonces en rangos no superpuestos ((0019,1000)–(0019,10FF) y (0019,1100)–(0019,11FF) respectivamente).

Leer un Tag Privado en la Práctica

Así se ve un bloque privado típico en un archivo MR de Siemens cuando ves los metadatos:

(0019,0010) LO  "SIEMENS MR HEADER"
(0019,1008) CS  "IMAGE NUM 4"
(0019,1009) LO  "1.0"
(0019,100B) DS  "112.5"
(0019,100C) IS  "256"

Para interpretar estos elementos correctamente, un visor DICOM sigue tres pasos:

1. Lee el private creator en (0019,0010). El valor es “SIEMENS MR HEADER”.
2. El creator reservó el bloque 10, así que los elementos privados viven entre (0019,1000) y (0019,10FF).
3. Busca cada elemento en el diccionario privado del fabricante para encontrar un nombre legible. (0019,100B) en este bloque es, según la documentación de Siemens, “Slice Position”.

Sin la cadena del creator, todo lo que ves es hex opaco. Con la cadena del creator y el diccionario privado del fabricante, puedes decodificar el significado. Por eso los tags privados no son portables entre visores que no tengan los diccionarios correctos.

Fuentes Comunes de Tags Privados

Distintos fabricantes usan tags privados para distintos fines. Algunos patrones recurrentes:

• Parámetros de reconstrucción: Los fabricantes de TC y RM almacenan selecciones de kernel, fases de gating y coeficientes de filtro de reconstrucción en bloques privados porque el estándar no define elementos explícitos para cada parámetro.
• Identificadores de protocolo: Nombres de protocolo específicos del centro, números de serie del modelo del escáner e identificadores de build del software que pueden ayudar al troubleshooting pero no forman parte del diccionario público.
• Salida de IA / CAD: Los sistemas modernos de inferencia de IA a menudo escriben mapas de probabilidad, bounding boxes de lesiones o cadenas de versión del modelo en tags privados para que viajen con el estudio.
• Notas de operador y workflow: Algunas modalidades legacy embeben el nombre del operador, un identificador de estación o un comentario de workstation en tags privados en lugar de los campos estándar.
• Identificadores duplicados: Menos comúnmente, un fabricante puede almacenar un duplicado de demografía del paciente en tags privados “por conveniencia”. Es el peor caso para privacidad porque los scripts de de-identificación que solo apuntan a tags públicos los pasarán por alto.

Por Qué los Tags Privados Rompen la De-Identificación

El hecho operacionalmente más importante sobre tags privados es este: los scripts de de-identificación que solo apuntan a campos PHI estándar no son seguros. El propio perfil de de-identificación del estándar DICOM (PS3.15 Anexo E) recomienda explícitamente eliminar todos los tags privados por defecto a menos que los tags de un creator específico hayan sido revisados y puestos en lista blanca. Hay varias razones:

• Algunos fabricantes duplican el nombre del paciente, MRN o número de accession en elementos privados.
• Las notas de operador embebidas pueden incluir iniciales del paciente, motivos de exploración o detalles del médico solicitante.
• Los campos de descripción de protocolo en texto libre pueden contener contexto clínico manuscrito que incluye PHI.
• Algunos tags privados incluyen el número de serie de la modalidad más un timestamp, que juntos pueden actuar como cuasi-identificador cuando se combinan con metadatos públicos del estudio.

Para equipos de TI radiológica que preparan datos para exportación a investigación, entrenamiento de IA o publicación, el camino más seguro es eliminar cada elemento privado por defecto, y luego retener selectivamente solo los necesarios para procesamiento downstream. Las herramientas que visualizan tags privados con claridad — mostrando el creator, el bloque y el valor crudo — son esenciales para esta revisión.

Cómo Coexisten Público y Privado en el Mismo Grupo

Una sutileza que vale la pena entender: un único grupo impar puede contener elementos de múltiples private creators. Por ejemplo, en el grupo impar 0029, podrías encontrar:

(0029,0010) LO  "SIEMENS CSA HEADER"
(0029,0011) LO  "SIEMENS MEDCOM HEADER"
(0029,0012) LO  "SIEMENS MEDCOM HEADER2"
(0029,1010) OB  <datos binarios CSA>
(0029,1110) OB  <datos binarios MEDCOM>
(0029,1210) OB  <datos binarios MEDCOM2>

Tres creators reservaron cada uno un bloque. Sus elementos privados viven en (0029,10xx), (0029,11xx) y (0029,12xx) respectivamente. Un visor correcto debe asociar cada elemento privado con su creator, no solo adivinar basándose en el número de grupo.

Workflow Práctico: Inspeccionar Tags Privados

Cuando abres un archivo DICOM desconocido y quieres entender su contenido privado, sigue esta rutina:

1. Abre el archivo en un visor de metadatos. Filtra por números de grupo impares para aislar el contenido privado.
2. Para cada grupo impar, lista los creators leyendo los elementos 0010–00FF.
3. Para cada creator, localiza el bloque privado correspondiente y revisa cada valor de elemento.
4. Cruza referencias de números de elemento desconocidos con la conformance statement pública del fabricante, si está disponible. Muchos fabricantes publican diccionarios privados.
5. Marca cualquier elemento cuyo valor parezca PHI (nombres, fechas, identificadores, texto libre) para de-identificación.

Puedes hacer todo esto con nuestro Visor de Tags DICOM, que destaca los private creators y los agrupa visualmente con sus elementos.

Tags Privados y Migración: un Coste Oculto

Al migrar estudios entre fabricantes de PACS o moviendo datos a un archivo vendor-neutral, los tags privados son a menudo la causa silenciosa de fallos. Problemas comunes:

• Diccionarios perdidos: El sistema destino puede no tener el diccionario privado del fabricante origen, así que aunque los tags privados sobrevivan byte a byte, aparecen como blobs no decodificados en el nuevo visor.
• Discrepancias de codificación: Algunos elementos privados de fabricante usan Value Representations no estándar o almacenan datos binarios estructurados que requieren SDKs del fabricante para parsearlos. Las herramientas genéricas pueden no preservarlos correctamente.
• Truncamiento: Las herramientas de migración que aplican conformidad DICOM estricta pueden descartar elementos privados que no coinciden con longitudes o VRs esperadas, perdiendo silenciosamente parámetros de reconstrucción o salida de IA.
• Fallo de hanging-protocol: Algunos PACS usan tags privados para dirigir hanging protocols por defecto. Si esos tags se pierden, los layouts en el destino pueden caer a disposiciones menos útiles.

La mitigación es inventariar los tags privados antes de la migración: lista cada par grupo-impar y creator presente en una muestra representativa, decide si cada uno se necesita downstream, y confirma que el archivo destino puede preservarlos.

Mejores Prácticas al Trabajar con Tags Privados

• Lee siempre el creator primero. Nunca interpretes un elemento privado sin confirmar la cadena del creator en el slot 00xx correspondiente.
• Por defecto, elimina al de-identificar. Borra todos los tags privados a menos que hayas puesto explícitamente en lista blanca creators y elementos.
• Mantén un inventario de diccionarios privados. Documenta qué diccionarios privados de fabricantes están cargados en cada sistema de tu entorno.
• Audita periódicamente. Muestrea estudios de cada modalidad y revisa el contenido privado. Las actualizaciones de software nuevas pueden introducir nuevos elementos privados sin previo aviso.
• Preserva los creators durante el procesamiento. Cuando los pipelines reescriban o filtren DICOM, asegúrate de que los slots de creator se mantengan consistentes con los elementos que poseen. Eliminar un creator dejando su bloque deja elementos huérfanos que ningún visor decodificará correctamente.

Conclusión

Los tags privados son la parte de DICOM que los fabricantes usan para expresar lo que el estándar no expresa. Son esenciales para la fidelidad clínica pero también la fuente única más grande de riesgo de de-identificación y fricción de migración. Entender la regla del grupo impar, el mecanismo de reserva de creator y la relación entre creators y sus elementos convierte los tags privados de hex opaco en metadatos accionables. Para cada workflow DICOM que toque privacidad o portabilidad, trata los tags privados como una preocupación de primera clase. Continúa tu lectura con nuestra referencia de Value Representations DICOM y codificación de tags DICOM en disco.