Una migración de PACS es uno de los pocos proyectos de TI donde "parece que ha funcionado" no es una conclusión aceptable. El archivo guarda registros diagnósticos en los que los clínicos se apoyarán durante años y que la organización está legalmente obligada a conservar. Si una migración pierde atributos en silencio, rompe la jerarquía de estudios o transcodifica imágenes, el daño puede no aflorar hasta que un radiólogo no encuentre un estudio previo durante una sesión de informe.
La validación tiene que ser por tanto probatoria y no impresionista. Una comparación a nivel de etiqueta entre los objetos de origen y de destino es la forma más rápida de producir esa evidencia, pero solo si sabes qué diferencias son defectos y cuáles son esperables. Este artículo cubre ambas.
Qué estás comparando en realidad
Un archivo DICOM es un conjunto de datos de atributos, cada uno identificado por una etiqueta escrita como grupo y elemento: (0010,0010) para el nombre del paciente, (0020,000D) para el Study Instance UID. Cada atributo lleva una Value Representation, un código de tipo de dos letras como PN, DA, UI o SQ, que determina cómo se interpretan sus bytes.
Esta estructura es la razón por la que una comparación de archivos a nivel de byte resulta casi inútil para el control de calidad de una migración. Dos archivos con contenido clínico idéntico diferirán en bytes siempre que difiera la sintaxis de transferencia, el orden de los atributos o el relleno. Lo que necesitas es una comparación que empareje atributos por etiqueta y compare los valores decodificados: un diff semántico, no binario.
Diferencias esperables
Empieza catalogando lo que tu migración debe cambiar. Nada de esta lista es un defecto cuando aparece en el diff:
- Metainformación del archivo. Implementation Class UID (0002,0012) e Implementation Version Name (0002,0013) identifican el software que escribe. El objeto de destino lo escribió otro archivo, así que difieren por definición.
- Sintaxis de transferencia. Los archivos de destino suelen almacenar con otra sintaxis de transferencia; el caso habitual es VR explícito frente a implícito. Si tu comparación trabaja sobre valores decodificados y no sobre bytes crudos, esto no produce ninguna diferencia a nivel de atributo.
- Identificadores coercionados. La mayoría de los archivos están configurados para coercionar Patient ID (0010,0020), Accession Number (0008,0050) o Study ID (0020,0010) contra el índice maestro de pacientes de la institución receptora. Es deliberado, y verificar que ocurrió correctamente forma parte de la validación en lugar de ser un hallazgo en su contra.
- Marcas de tiempo del archivo. Instance Creation Date and Time, y cualquier atributo privado que registre la recepción, diferirán por diseño.
Escribe esta lista antes de empezar. Una validación que no ha definido de antemano sus diferencias esperables tiende a racionalizar los hallazgos a posteriori, que es precisamente lo que hace indefendible un registro de calidad.
Diferencias que sí son defectos
Todo lo demás merece escrutinio, y tres categorías lo merecen más que ninguna.
Los UID y la jerarquía de estudios
Study Instance UID, Series Instance UID y SOP Instance UID forman la jerarquía que permite a un archivo ensamblar instancias sueltas en un estudio coherente. En una migración directa deben conservarse exactamente. Un SOP Instance UID cambiado no significa que un objeto se haya movido: significa que se ha creado un objeto nuevo y la identidad original ha desaparecido. Las consecuencias aguas abajo incluyen estudios duplicados, enlaces rotos a estudios previos e informes que referencian instancias que el archivo ya no puede resolver.
Esta es la comprobación de mayor valor en la validación de una migración, y por eso merece la pena filtrar el diff por atributos con VR UI en primer lugar. Si todos los atributos UI son idénticos, la capa de identidad ha sobrevivido.
Atributos que describen el píxel
Rows (0028,0010), Columns (0028,0011), Bits Allocated (0028,0100), Bits Stored (0028,0101), High Bit (0028,0102), Pixel Representation (0028,0103) y Photometric Interpretation (0028,0004) describen cómo interpretar los datos de píxel. Un cambio aquí significa que la propia imagen ha sido alterada o recodificada. Rescale Slope e Intercept (0028,1053 y 0028,1052) importan igual en modalidades como el TC, donde convierten los valores almacenados en unidades Hounsfield: un intercept cambiado desplaza en silencio cada medida de densidad que tome un clínico.
Geometría
Image Position Patient (0020,0032), Image Orientation Patient (0020,0037), Pixel Spacing (0028,0030) y Slice Thickness (0018,0050) determinan cómo se reconstruye una serie en tres dimensiones. Una corrupción aquí produce reconstrucciones multiplanares sutilmente incorrectas en lugar de evidentemente rotas, lo que la hace especialmente peligrosa: nada parece un error hasta que se toma una medida sobre ello.
Secuencias: la parte que las herramientas simples se saltan
Un atributo con VR SQ contiene una lista ordenada de elementos, cada uno de los cuales es un conjunto de datos anidado completo que puede contener más secuencias. Scheduled Procedure Step Sequence (0040,0100), Referenced Image Sequence (0008,1140), Request Attributes Sequence (0040,0275) y todo el árbol de contenido de un DICOM Structured Report viven dentro de secuencias.
Muchas herramientas de comparación omiten las secuencias o las reducen a una única fila de resumen del tipo "secuencia con 2 elementos". Eso no basta para el control de calidad de una migración. Los informes estructurados llevan los propios hallazgos clínicos dentro de elementos de contenido anidados; los planes de radioterapia llevan allí las prescripciones de dosis. Un diff que informe de "2 elementos" en ambos lados mientras difiere el médico solicitante o la dosis prescrita dentro de esos elementos no te ha dicho nada mientras aparenta haber comprobado.
Una comparación correcta desciende a cada secuencia, empareja los elementos por índice —el orden es significativo dentro de una secuencia— e informa de cada atributo anidado con su ruta completa, para que veas exactamente en qué punto del árbol vive una diferencia.
Usar un diff para verificar la anonimización
La misma comparación sirve para un segundo propósito. Cuando el archivo B pretende ser una copia anonimizada del archivo A, el diff se convierte en un informe de verificación y la expectativa se invierte: todos los atributos de la lista de PHI deberían haber cambiado, y los atributos clínicos no.
Filtrar por atributos PHI te da esa vista directamente. Cualquier atributo PHI que siga apareciendo como idéntico es una posible fuga: un nombre de paciente, una fecha de nacimiento, un nombre de institución, un médico solicitante o un número de acceso que sobrevivió a la cadena de proceso. El anexo E de DICOM PS3.15 define los perfiles de confidencialidad que especifican qué atributos deben tratarse y cómo; el diff es la forma de contrastar una cadena real contra esa especificación sobre archivos reales.
Fíjate en que aquí la regla de los UID se invierte. En una migración, los UID deben conservarse. En anonimización, los UID por lo general deben sustituirse, porque un Study Instance UID conservado enlaza la copia anonimizada directamente con el estudio original del archivo de origen. Ejecutar el filtro de UID responde a la pregunta correcta en ambos casos; lo único que cambia es la respuesta esperada.
Comprueba también la dirección inversa. Si un atributo clínicamente relevante aparece como cambiado cuando no debería, el perfil de anonimización es más agresivo de lo previsto. Una sobreanonimización que elimine parámetros de adquisición o geometría puede destruir en silencio el valor de investigación de un conjunto de datos, y es mucho más difícil de detectar que una fuga porque nada en ella parece un fallo.
Un flujo de validación práctico
- Selecciona una muestra representativa. Cubre cada modalidad del archivo, más los casos incómodos: objetos multiframe, informes estructurados, estados de presentación y cualquier estudio con juegos de caracteres inusuales o nombres de paciente no latinos.
- Define primero las diferencias esperables. Anota las reglas de coerción y los atributos de implementación antes de mirar ninguna salida.
- Ejecuta el filtro de UID. Confirma que la capa de identidad se comportó como exige la operación: conservada en una migración, regenerada en una anonimización.
- Pasa a la vista de solo diferencias. Lee todas las filas si el recuento es pequeño. Si es grande, barre por VR: DA y TM para fechas, PN para nombres, CS para valores codificados, DS para los atributos numéricos de geometría.
- Comprueba explícitamente los atributos de píxel y geometría. Son aquellos cuya corrupción resulta invisible en un visor.
- Exporta el informe. Un CSV adjunto al ticket de migración es lo que hace auditable la validación meses después.
- Intercambia y vuelve a leer. Ver la comparación desde la otra dirección detecta atributos presentes solo en el destino, fáciles de pasar por alto cuando estás pensando en lo que se ha perdido.
Lo que un diff de cabecera no puede decirte
Tener claro el alcance es lo que hace utilizable como evidencia la salida de una herramienta de calidad. Un diff a nivel de etiqueta compara cabeceras y metadatos. Confirmará que Rows, Columns y Bits Allocated coinciden —un indicio sólido de que los datos de píxel están estructuralmente intactos—, pero no decodifica ni compara los píxeles en sí. Una migración que conservara todos los atributos de cabecera mientras transcodifica o corrompe los datos de imagen produciría un diff limpio.
Tampoco valida la conformidad. Un objeto puede no diferir de su origen en ningún atributo y aun así violar el IOD al que dice ajustarse, si el origen ya era no conforme. La comprobación de conformidad es un ejercicio aparte contra PS3.3.
Un diff de cabecera pertenece por tanto a una batería de validación junto a una comparación a nivel de píxel y una revisión visual de una muestra representativa. Es la forma más rápida de encontrar todas las diferencias que una cabecera puede expresar, y guarda silencio deliberadamente sobre las que no puede.
Por qué aquí importa que sea en el navegador
Los archivos DICOM contienen habitualmente información sanitaria protegida. Subirlos a un servicio web de terceros para ejecutar una comparación es una comunicación de datos y, en la mayoría de las organizaciones, una que no ha sido autorizada; por eso tantos ingenieros clínicos recurren a la línea de comandos incluso cuando una herramienta web sería más rápida.
Una herramienta que analiza ambos archivos localmente en el navegador elimina ese dilema. No se transmite nada, así que no hay comunicación que autorizar, y funciona en una estación clínica bloqueada donde instalar DCMTK no es una opción.
Pruébalo
Nuestro comparador DICOM implementa el flujo anterior: un veredicto de tres vías por atributo, recorrido de secuencias con rutas completas, filtros de PHI y UID que usan las mismas definiciones que nuestro anonimizador, acotado por VR, búsqueda y exportación CSV con orden de columnas estable. Ambos archivos se analizan íntegramente en tu navegador.
Para inspeccionar los atributos de un único archivo en lugar de comparar dos, el visor de etiquetas DICOM es mejor punto de partida. Si eres quien produce la copia anonimizada, el anonimizador DICOM aplica los perfiles de confidencialidad de PS3.15, y el diff es la forma de demostrar que hizo lo que esperabas.