SOP Class DICOM: qué es y por qué decide si abres una imagen

1. Qué es una SOP Class, en una frase

Una SOP Class —del inglés Service-Object Pair Class— es la definición que el estándar DICOM hace de cada tipo concreto de estudio o interacción: qué campos son obligatorios, qué formato tienen los píxeles, qué combinaciones de metadatos deben acompañar a la imagen. No es un rasgo del archivo: es una clase a la que ese archivo pertenece, en el sentido informático de la palabra. Un archivo DICOM declara siempre a qué SOP Class corresponde, y el visor decide en función de esa declaración si sabe abrirlo o no.

1.1. Una etiqueta y su contrato

La SOP Class es a la vez una etiqueta —«esto es un corte de OCT», «esto es una imagen radiográfica»— y un contrato: si un archivo dice que es de una SOP Class concreta, el estándar exige que lleve determinados campos rellenos y que los datos de píxel estén codificados de una manera específica. Cuando el software rechaza un estudio válido con un mensaje del tipo «SOP Class no soportada», lo que está diciendo es que reconoce la etiqueta pero no ha implementado ese contrato.

1.2. Por qué su nombre suena a jerga

«Service-Object Pair» es una expresión ingenieril: el objeto es el estudio (una imagen, una serie), y el servicio es lo que se puede hacer con él (guardarlo, consultarlo, mostrarlo). La SOP Class combina las dos cosas para poder decir con precisión, en el mismo término, no solo qué prueba es sino qué operación se está pidiendo sobre ella. Es una distinción que importa mucho en un hospital, y mucho menos en una consulta pequeña — pero es la razón de que el nombre parezca innecesariamente técnico para lo que acaba resolviendo.

2. Por qué existe: el problema que resuelve

Sin SOP Class un visor tendría que abrir cada archivo DICOM «a la buena de dios», intentar interpretar sus datos y confiar en que estén donde se espera. Es exactamente lo que pasaba con los formatos propietarios anteriores al estándar: un archivo abría o no según el humor del programa que lo intentaba. El estándar decide que la responsabilidad la tenga el archivo —tiene que declararse— y que la responsabilidad del visor sea implementar el contrato que corresponda.

2.1. Un contrato por tipo de prueba

Una radiografía convencional, un corte de OCT y un vídeo de endoscopia son estudios muy distintos: la radiografía es una imagen bidimensional en escala de grises con unos datos técnicos concretos; el OCT es una serie de cortes en profundidad con una escala física real; el vídeo de endoscopia es una secuencia temporal en color. Meter los tres en el mismo cajón sería imposible. Cada uno tiene su SOP Class propia, con sus campos obligatorios propios, y cuando un archivo llega, el visor ya sabe qué esperar.

2.2. Y también un contrato por interacción

Guardar un estudio en un archivo no es lo mismo que consultarlo desde otro sistema, ni tampoco es lo mismo que mostrarlo por pantalla remota. Cada una de esas operaciones tiene su propia SOP Class: Storage para el envío de archivos, Query/Retrieve para las consultas al archivo y Print para la impresión en película o en pantalla remota. En una consulta pequeña, la que interesa casi siempre es Storage. Las otras son de infraestructura hospitalaria.

2.3. Por qué esto importa antes de firmar nada

Si tu software declara que «soporta DICOM» sin decir qué SOP Classes concretas soporta, esa afirmación es demasiado amplia para ser útil. El equivalente sería un ordenador que dice que «lee documentos» pero no aclara si lee PDF, Word o solo texto plano. La lista de SOP Classes soportadas —el Conformance Statement— es un documento público que todo fabricante serio publica, y una pregunta razonable antes de contratar.

3. Qué información lleva: UID y nombre humano

El UID no cambia, aunque el nombre humano evolucione entre versiones del estandar.

Cada SOP Class se identifica por un UID —un identificador único, una cadena larga de números separados por puntos, del tipo 1.2.840.10008.5.1.4.1.1.7— y por un nombre legible —«Secondary Capture Image Storage», en este caso—. El UID es lo que se pega dentro del archivo, en un campo llamado SOPClassUID; el nombre humano existe para que un técnico pueda leer una lista de SOP Classes sin traducir números mentalmente.

3.1. Un UID que nunca cambia

Los UID de las SOP Classes son estables durante décadas: una vez que el estándar asigna un identificador a una clase concreta, ese identificador ya no se reutiliza. Es la razón de que un archivo guardado hace quince años se abra hoy en un visor moderno sin ninguna traducción: la etiqueta que lleva dentro sigue diciendo lo mismo, y el visor sigue sabiendo qué contrato aplicar. Esto lo diferencia de los formatos comerciales, donde una versión nueva puede dejar de leer archivos antiguos sin previo aviso.

3.2. Dónde vive dentro del archivo

El SOPClassUID se guarda en la cabecera del archivo, en la parte estructurada de metadatos que precede a los datos de píxel. Junto a él suele viajar el SOPInstanceUID, que es el identificador único de esa imagen concreta, no del tipo. Los dos, leídos juntos, dan la pareja completa: «qué tipo de prueba es» y «qué instancia concreta dentro del historial del paciente». Cualquier visor decente los lee antes de intentar abrir la imagen.

3.3. Los nombres varían, los UID no

Los nombres humanos de las SOP Classes se han ido puliendo con las versiones del estándar; los UID se mantienen. Esto significa que en la documentación de un software puedes encontrar «CT Image Storage» y en otro «Computed Tomography Image Storage», refiriéndose al mismo 1.2.840.10008.5.1.4.1.1.2. Cuando dos listas de compatibilidad no cuadran, se comparan los UID, no los nombres.

4. Las familias de SOP Classes que se ven en una consulta

El estándar define cientos de SOP Classes, pero una consulta oftalmológica u ORL trabaja habitualmente con un subconjunto pequeño. Merece la pena conocerlas por familia, porque agrupan pruebas cuya cabecera es parecida y cuyas trampas también.

4.1. La familia oftalmológica

Comprende Ophthalmic Photography 8/16 Bit Image Storage —para retinografías—, Ophthalmic Tomography Image Storage —para los cortes del OCT—, Ophthalmic Visual Field Static Perimetry Measurements Storage —para campos visuales— y Ophthalmic Axial Measurements Storage —para biometrías—. Cada una tiene sus campos específicos, así que un visor pensado solo para radiología no sabe qué hacer con un corte de OCT aunque el archivo esté perfectamente formado.

4.2. La familia radiológica clásica

Es la más veterana del estándar: CT Image Storage para la tomografía computarizada, MR Image Storage para la resonancia magnética, US Image Storage para ecografías y Digital X-Ray Image Storage — For Presentation para radiografías digitales. La mayoría de los visores «generalistas» las soportan todas; muchos visores oftalmológicos solo las abren de forma limitada.

4.3. Las familias que confunden

Existen dos cajones que suelen dar sustos. Uno es Secondary Capture Image Storage, un contenedor genérico donde un equipo mete una imagen que no encaja en ninguna otra clase concreta: sirve para todo pero no lleva los campos específicos de nadie. El otro es Encapsulated PDF Storage, que envuelve un PDF entero dentro de un archivo DICOM. Los dos son válidos, pero un visor puede saber leer los cortes de OCT y no saber qué hacer con un Secondary Capture — o al revés—.

5. Storage frente a Query/Retrieve: no toda SOP Class hace lo mismo

Hasta aquí hemos hablado como si SOP Class y «tipo de imagen» fueran lo mismo. Casi lo son, pero no del todo: el estándar diferencia entre las SOP Classes que describen un estudio y las que describen una operación que se hace con estudios. Distinguirlas evita pedirle a un software algo que su categoría no le permite hacer.

5.1. Storage: la que casi siempre es la clave

Las SOP Classes de Storage son las que definen «cómo se guarda» una imagen de un tipo concreto. Cuando el fabricante dice «este equipo exporta en DICOM», lo que está diciendo es que guarda archivos en una o varias SOP Classes de Storage. Y cuando el software del centro «soporta DICOM», lo mínimo que se le pide es que abra las SOP Classes de Storage de los equipos que hay en el pasillo — no todas las de la lista completa.

5.2. Query/Retrieve: cuando el archivo vive en otro sitio

Existe en un entorno con un PACS central: el software local no tiene los archivos, los pide al PACS por red usando estas SOP Classes. En una consulta pequeña sin PACS, no hacen falta. Cuando aparecen en un pliego técnico y el centro no tiene PACS, o bien sobran, o bien alguien ha copiado el pliego de un hospital sin adaptar.

5.3. Print y Storage Commitment: infraestructura hospitalaria

Print manda imágenes a una impresora de película DICOM, un dispositivo que hoy es raro fuera de radiología hospitalaria. Storage Commitment sirve para que un equipo pida al archivo que «se comprometa» a guardar un estudio antes de borrarlo del propio equipo. Son útiles cuando existen; su ausencia en una consulta ambulatoria no es un problema real.

6. Cómo saber qué SOP Class trae un archivo, sin abrir el equipo

Cuando el visor no lo lee, la ficha del estudio hay que consultarla desde otra herramienta.

Cuando un estudio no se abre o se abre torcido, la primera pregunta útil es qué SOP Class declara ese archivo. La respuesta se puede obtener de tres maneras, según lo que haya a mano.

6.1. Con un visor con «propiedades» o «info»

La mayoría de los visores decentes muestran un panel con los metadatos de la cabecera. Ahí aparece el SOPClassUID —el UID largo— y, si el visor es cortés, el nombre humano. Es la ruta rápida cuando el archivo se abre a medias pero al menos se lee la cabecera. Un visor que no muestra esta información en ningún sitio es, honestamente, un mal síntoma.

6.2. Con una herramienta de línea de comandos

Existen utilidades gratuitas —del proyecto DCMTK, por ejemplo— que dumpean toda la cabecera de un archivo DICOM en texto plano. Es la vía cuando el visor no abre el archivo ni siquiera lo suficiente para leer los metadatos. Sirve además para comparar la cabecera de dos archivos y ver qué campo no cuadra.

6.3. Preguntando al fabricante del equipo

El manual del equipo debe declarar qué SOP Classes exporta —y en qué versión del estándar—. Es información pública y disponible en el Conformance Statement del fabricante. Cuando el centro no encuentra ese documento en la web, pedirlo por escrito antes de comprar es una cortesía razonable — y una señal útil sobre el proveedor.

7. Qué debe cumplir tu software con las SOP Classes

Aunque cada centro trabaja con equipos distintos, hay tres criterios que separan un software honesto de uno que simplemente marca «DICOM» en su ficha de producto sin haberse mirado el estándar.

7.1. Declara qué SOP Classes soporta, con su UID

No basta con decir «soporta DICOM». Un software serio publica la lista concreta de SOP Classes que abre, cada una con su UID, para que se pueda cruzar con lo que exportan los equipos del centro. Si esa lista no existe o «depende del cliente», el riesgo se descubre el día de la puesta en marcha con un estudio que no se abre.

7.2. Rechaza con un mensaje claro, no con un error genérico

Cuando llega un archivo cuya SOP Class no está soportada, el sistema debería avisar en esos términos: «SOP Class X no está soportada; el archivo es válido pero no se puede abrir aquí». Un «error al abrir el fichero» genérico obliga al centro a sospechar del archivo cuando el que falla es el visor, y desperdicia horas persiguiendo al equipo equivocado.

7.3. No inventa metadatos que faltan

Si una SOP Class exige un campo obligatorio y ese campo no está, la respuesta correcta es advertir, no rellenar el campo con un valor por defecto para «poder seguir». Los defaults silenciosos son la fuente más frecuente de estudios que se vinculan al paciente equivocado — el error de imagen médica que más caro sale, según la documentación sobre protección del dato de salud visual.

Y un cuarto criterio, más comercial que técnico. Si tu equipo genera un tipo de estudio que tu software no abre —una biometría con una SOP Class específica, un vídeo de endoscopia—, el software honesto lo dice antes de la venta y ofrece una vía —conversión, visor externo integrado— en lugar de dejar el archivo en un limbo. Esperar a que el estudio no se abra el primer día es mala política.

8. Errores frecuentes al hablar de SOP Class

• «Soporta DICOM, así que abrirá cualquier estudio DICOM». Soportar el estándar significa entender la sintaxis, no todas las SOP Classes. Hay software que abre radiografías perfectamente y no sabe qué hacer con un corte de OCT.
• «Si el archivo es válido, cualquier visor lo abre». Un archivo puede ser válido y aun así usar una SOP Class que el visor concreto no ha implementado. La validez es del archivo; la compatibilidad es del par archivo-visor.
• Confundir la modalidad y la SOP Class. La modalidad —el campo Modality— dice qué tipo de equipo generó la imagen; la SOP Class dice qué contrato sigue el archivo. Un mismo equipo puede exportar en varias SOP Classes distintas.
• Fiarse solo del nombre humano. Los nombres cambian entre versiones del estándar y entre fabricantes; los UID no. Cuando dos listas de compatibilidad no cuadran, se comparan los UID.

8.1. El error que más caro sale: dar por buena una lista genérica

Un fabricante que dice «compatibilidad DICOM» sin publicar su Conformance Statement deja al centro apostando a ciegas. Si los equipos exportan en una SOP Class oftalmológica específica y el visor solo abre las clásicas radiológicas, la incompatibilidad no aparece hasta que llega la primera prueba de un paciente real — y entonces ya está firmado.

8.2. Creer que la nueva versión del estándar deja obsoleto lo anterior

El estándar añade SOP Classes con el tiempo, pero no retira las antiguas: el mismo CT Image Storage de hace veinte años sigue siendo válido. Cambiar de software o de PACS no obliga a migrar archivos a versiones nuevas — otra cosa es que el proveedor lo aproveche para venderlo.

8.3. Suponer que dos equipos con la misma SOP Class se entienden solos

La SOP Class define qué campos son obligatorios, pero cada fabricante puede rellenar de más y de menos dentro de lo permitido. Dos ecógrafos que exportan en US Image Storage generan archivos válidos y no idénticos: casi siempre hay un ajuste antes de que el segundo visor los muestre con la misma escala que el primero.

9. Qué aporta obeliOmed con esto

9.1. El estudio se abre dentro de la historia

obeliOmed incluye un visor DICOM integrado en el expediente del paciente: cuando el archivo entra, se lee su SOP Class, se comprueba que corresponde a uno de los tipos soportados y se muestra en la ficha sin cambiar de programa. Si el archivo declara una SOP Class no soportada, el sistema lo dice en esos términos —«esta SOP Class no está soportada aquí»— en lugar de rechazar el archivo como si estuviera corrupto.

9.2. La cabecera importa antes de vincular

Antes de asociar un estudio a un paciente, el software comprueba el identificador de paciente de la cabecera contra el paciente al que se está subiendo. Cuando la SOP Class exige campos que el archivo no trae, la respuesta es avisar, no rellenar por defecto: se prefiere que el centro lo sepa a que se guarde un dato inventado. Es lo mismo que se pide en las pautas de la interoperabilidad de imagen médica.

9.3. Lo que no hace, dicho antes de que lo preguntes

obeliOmed no funciona como archivo centralizado al que las modalidades envían estudios por red al terminar la adquisición. Para una consulta o clínica de tamaño pequeño o mediano eso rara vez es un límite real; cuando lo es, lo honesto es decirlo antes de firmar. Las vías reales de traspaso —carpeta vigilada, worklist y acceso a la base de datos del equipo— dependen del fabricante y se presupuestan por equipo.