C-STORE en DICOM: qué es y qué debe hacer tu software con él

1. Qué es esta operación, en una frase

Dentro del estándar DICOM, la operación que aquí nos ocupa es el mensaje con el que un sistema envía por red un estudio de imagen completo a otro sistema para que lo archive. El equipo que acaba de generar la prueba se pone en contacto con un destino de red, le pregunta si sabe recibir ese tipo de estudio y, si la respuesta es afirmativa, le manda el archivo entero por la red local o por internet.

1.1. Un mensaje, no un formato

Es importante no confundir el mensaje con el archivo. El archivo es una pieza de datos —el estudio con su cabecera, su píxel y sus metadatos—; el mensaje es una operación por red que hace una cosa concreta con ese archivo: enviarlo. Un mismo archivo puede llegar a un archivo central por muchas vías —una memoria física, una carpeta compartida, un buzón vigilado— y solo cuando llega por este protocolo del estándar hablamos de esta operación.

1.2. Por qué su nombre suena tan concreto

El estándar necesita nombres precisos para poder documentar qué habla cada equipo. La C inicial indica que la operación viene del núcleo Composite del estándar —la parte que trata estudios completos, no piezas sueltas—; el resto describe la acción: «guardar en el otro extremo». Es una jerga incómoda de leer al principio, pero razonable en su ámbito: sin nombres estables no hay compatibilidad comprobable entre fabricantes distintos.

2. Por qué existe: el problema que resuelve

Antes de que existiera un protocolo estándar de envío por red, cada centro tenía que resolver a mano el traslado de las imágenes desde el equipo hasta el sistema que las archivaba. Una radiografía se imprimía o se copiaba a un CD; una ecografía se sacaba a un vídeo. El estándar decidió que ese envío debía ser una operación por red normalizada, para que cualquier equipo de cualquier fabricante pudiera hablarse con cualquier archivo central que también respetara el estándar.

2.1. El problema de los CD y los pendrives

El traslado físico de imágenes era el modelo por defecto en los años noventa: cada estudio salía del equipo a un soporte físico y alguien lo llevaba, físicamente, al archivo. Los soportes se degradan, se pierden y se etiquetan mal. El estándar quiso eliminar ese paso siempre que el equipo y la red permitieran una alternativa por cable, y este mensaje es la pieza que lo hace posible.

2.2. El problema del acoplamiento de fabricantes

Sin protocolo estándar, cada equipo dependía del sistema del mismo fabricante para archivar sus imágenes; y cambiar de proveedor de archivo obligaba a cambiar también los equipos. El estándar rompe ese acoplamiento: un equipo que habla el protocolo puede enviar a un archivo de otra marca, siempre que ese archivo también lo hable. Esto es lo que hace posible que un hospital combine equipos de fabricantes distintos con un mismo archivo central.

2.3. El problema de la trazabilidad de la copia

Cuando el envío se hace por red con este protocolo, queda constancia técnica del intercambio: el archivo puede confirmar la recepción, avisar de errores y devolver un identificador del estudio recibido. Esa contabilidad es imposible con un CD o un USB. Para un centro que necesita saber que cada prueba que se hace acaba archivada, esa trazabilidad no es un lujo.

3. Cómo funciona: el diálogo entre dos sistemas

Antes de mandar el estudio, los dos sistemas se saludan y acuerdan que se puede enviar.

La operación no es un simple «volcado»: es un diálogo por red con un guion definido, y entender ese guion aclara la mayoría de los problemas que aparecen cuando algo no funciona.

3.1. Primero se saludan: el establecimiento de la asociación

Antes de mandar nada, los dos sistemas se saludan por la red: el que envía pregunta al que recibe qué tipos de estudio sabe archivar —qué SOP Classes tiene implementadas—, con qué formatos de compresión y en qué versión del estándar. El destino responde con lo que soporta. Si no hay intersección entre lo que el emisor quiere mandar y lo que el receptor sabe recibir, no se manda nada. Este saludo se llama asociación y es una fuente clásica de fallos silenciosos.

3.2. Después se envía la imagen

Con la asociación establecida, el emisor envía el estudio en un paquete estructurado que incluye la cabecera y los datos de píxel del archivo, todo por la misma conexión. El receptor lo lee, lo guarda y responde con un código que indica si el archivo se ha aceptado, si se ha aceptado con reservas o si se ha rechazado. Ese código de respuesta es el que un centro debería poder consultar cuando quiere saber por qué un estudio no aparece en el archivo esperado.

3.3. Finalmente se despiden: el cierre de la asociación

Cuando se han enviado todos los estudios de la sesión, los dos sistemas se despiden y liberan la conexión. Esto no es un adorno: una asociación que se corta a mitad, sin cierre limpio, puede dejar el archivo en un estado indefinido con el estudio a medio guardar. Un centro que ve «estudios en tránsito» que nunca aparecen suele tener un problema en este paso, no en el envío en sí.

4. Quién envía y quién recibe: los dos papeles

El estándar diferencia dos papeles con nombres propios, y la confusión entre los dos es la fuente más frecuente de expectativas mal puestas.

4.1. El emisor: el equipo o el nodo que envía

El emisor es normalmente el equipo que ha generado la prueba: el ecógrafo, el OCT, el TAC. Pero también puede ser un sistema intermedio —una estación de reenvío— que actúa como pasarela entre varios equipos y el archivo central. El emisor tiene su propia identidad de red —un AE Title, el equivalente a un nombre en el diálogo— y decide, por configuración, a qué destinos manda cada tipo de estudio.

4.2. El receptor: el archivo central

El receptor es un servidor especializado que sabe escuchar en la red, aceptar asociaciones desde emisores autorizados, guardar los archivos que le llegan en su almacén interno y responderles con el resultado. Esa pieza es un archivo central de imagen médica completo: no basta con «tener un servidor» ni con «tener disco»; hay que implementar el protocolo entero por el lado receptor.

4.3. Un software de consulta no siempre es un receptor

Un software clínico puede ser muy útil para leer, mostrar y guardar estudios DICOM dentro del expediente del paciente sin ser, en el sentido del estándar, un receptor por red. La diferencia es la que separa un visor de un archivo central. Un visor abre lo que le llega por otra vía; un archivo central escucha la red y acepta lo que un equipo le envía. Confundir los dos papeles es lo que produce los pliegos técnicos con incongruencias.

5. No es lo mismo que «abrir archivos DICOM»

Es la confusión más frecuente, y merece la pena separarla con detalle porque cambia lo que se puede pedir a un software.

5.1. Abrir archivos: es cosa del visor

Cuando un software abre un estudio DICOM que ha llegado a una carpeta —copiado a mano, exportado desde el equipo, subido desde una memoria— lo que hace es leer el archivo del disco y mostrarlo. Es una operación local, contra el sistema de ficheros. Puede ser perfectamente útil en una consulta pequeña y no exige implementar ninguna operación por red del estándar.

5.2. Recibir por red: es cosa del archivo central

Que un software escuche la red y acepte un estudio que le manda un equipo requiere implementar la parte por red del estándar: negociar la asociación, aceptar el envío, responder con el código correcto, guardar el archivo asociado a un identificador estable. Es infraestructura pensada para hospitales con muchas modalidades. Que un software haga lo primero no implica nada sobre lo segundo, aunque los dos usen la palabra «DICOM».

5.3. Y por qué las dos afirmaciones se venden como si fueran la misma

Porque «soporta DICOM» es una expresión ambigua que cabe en las dos. Un software que solo lee archivos del disco puede decirlo, y un archivo central que además escucha la red puede decirlo también. La pregunta útil, antes de contratar, no es «¿soporta DICOM?» sino «¿escucha la red y acepta envíos automáticos, o abre lo que le pongan en una carpeta?». Son dos productos distintos, con dos precios distintos y con dos usos distintos.

6. Cuándo no hace falta en una consulta

En una consulta pequena, muchas veces la carpeta vigilada resuelve mejor que montar un archivo central.

La operación por red que hemos descrito es una pieza de infraestructura hospitalaria, y no todos los centros la necesitan. Merece la pena ser explícito, porque a veces se compra por defecto y no se usa nunca.

6.1. Cuando la consulta tiene pocos equipos y poco volumen

Una consulta con dos o tres equipos que exportan a una carpeta compartida, que un software clínico recoge para asociarla al paciente, no gana casi nada configurando envíos por red. La complejidad de mantener las direcciones de nodo, la clave criptográfica de cada enlace TLS y las reglas del cortafuegos no compensa. La carpeta vigilada es más simple y hace el mismo trabajo con menos piezas.

6.2. Cuando la agenda ya se lee desde el equipo

Cuando el equipo puede leer la agenda del centro con la lista de pacientes citados —lo que el estándar llama worklist—, el nombre del paciente ya llega bien tecleado a la cabecera del estudio, y el archivo que sale del equipo es coherente sin que nadie tenga que renombrarlo. Con eso, muchas consultas resuelven el problema principal —la vinculación al paciente correcto— sin necesidad de envíos automatizados por red.

6.3. Cuando el centro puede leer directamente del equipo

Hay equipos cuya base de datos interna es accesible por API o directamente, y el software del centro puede traerse los datos concretos del estudio sin esperar a que el equipo los mande. Este tercer camino depende de cada fabricante y de cada modelo, y no se puede prometer en abstracto; cuando se puede, ahorra montar toda una infraestructura por red por un puñado de estudios semanales.

7. Qué debe cumplir tu software si lo necesitas

Si tu centro sí necesita recibir por red —porque hay varias modalidades, mucho volumen y varios profesionales que consultan a la vez—, hay criterios verificables que separan un archivo central serio de una promesa de folleto.

7.1. Publica su Conformance Statement con detalle

Debe decir qué SOP Classes acepta, con qué sintaxis de transferencia, con qué límites de tamaño y qué códigos de respuesta emite en cada caso. Si «depende del cliente», el riesgo se descubre el día en que un equipo empieza a rechazar envíos y nadie sabe por qué. Un archivo central sin este documento público no es un producto acabado.

7.2. Registra cada asociación, no solo los éxitos

Cada intento de envío —el que funciona y el que no— debe quedar registrado con su hora, el nodo emisor, el estudio y el resultado. Este registro no es opcional: es lo que permite saber, cuando un estudio no aparece, si el equipo lo envió y el archivo lo rechazó, o si el equipo no llegó a mandarlo. Sin ese registro, cualquier incidencia se investiga a ciegas.

7.3. Confirma la recepción antes de que el equipo borre

Hay una operación complementaria del estándar por la que el equipo pide al archivo que se comprometa formalmente a conservar el estudio antes de borrarlo de su propia memoria interna. Un archivo central que implementa esa confirmación evita el peor escenario: un equipo que borra un estudio porque cree haberlo enviado, cuando en realidad el archivo lo rechazó y nadie lo detectó a tiempo.

Y un cuarto criterio, comercial y no técnico. Si tu software declara que «recibe estudios por red», que lo diga con qué SOP Classes, con qué caducidad de asociación y con qué mecanismo de aviso cuando el envío falla. Cambiar la afirmación abstracta por una lista concreta separa la publicidad del producto real, y ese ejercicio lo debería hacer el proveedor antes de la reunión de venta, no el cliente después.

8. Errores frecuentes cuando se habla de este mensaje

• «Mi software recibe estudios DICOM». Puede que solo abra archivos DICOM que llegan a una carpeta. La primera vía es abrir; la segunda es escuchar la red y aceptar envíos. Son dos cosas distintas.
• «Si el estándar es abierto, todos los emisores hablan con todos los receptores». No exactamente. Cada emisor y cada receptor implementan un subconjunto del estándar y una lista de SOP Classes. La compatibilidad se comprueba pareja a pareja.
• Confundir el envío por red con la conversión de formato. Un archivo bien enviado sigue siendo el mismo archivo DICOM: nadie ha convertido nada. El envío es transporte, no transformación.
• Suponer que «tener servidor» equivale a «tener archivo central». Un servidor cualquiera puede alojar archivos DICOM en su disco; solo un archivo central implementa el protocolo por red que este mensaje requiere.

8.1. El error que más caro sale: no revisar el registro de asociaciones

Muchos centros descubren que un archivo lleva meses rechazando estudios de un equipo cuando ya han pasado seis meses y el estudio original ya no está en la memoria del equipo. La cabecera que causaba el rechazo era corregible en dos minutos; no revisarlo a tiempo lo hizo caro. Poner una revisión mínima del registro en la rutina semanal evita esta clase de sorpresas.

8.2. Confundir «asociación aceptada» con «estudio guardado»

El destino puede aceptar la asociación —esto es, decir «sí, hablo tu idioma»— y después rechazar el estudio concreto porque le falta un campo o porque su almacén interno está lleno. Un estudio que no se guarda no es una asociación fallida: es un envío rechazado a mitad del diálogo, y el mensaje de rechazo es específico.

8.3. Pedir esta operación a un software que no la ofrece, y culpar al equipo

Cuando un equipo intenta enviar y el software del centro no responde por la red, la primera intuición del técnico es apuntar al equipo. Antes de eso, conviene verificar si el software del centro implementa realmente la parte receptora del protocolo o si lo que hace es leer una carpeta. Un software honesto lo dice claro en su documentación pública.

9. Qué aporta obeliOmed con esto

9.1. Un visor integrado, no un archivo central

obeliOmed no funciona como archivo central al que las modalidades envían estudios por red al terminar la adquisición. Incluye un visor DICOM integrado en el expediente del paciente, para que el estudio se abra y se mida dentro de la misma ficha desde la que se lee el caso. Para una consulta o clínica pequeña o mediana esto suele ser suficiente; cuando no lo es, lo honesto es decirlo antes de firmar.

9.2. Las tres vías reales de traspaso

Las alternativas al envío por red que sí funcionan hoy en obeliOmed son tres: carpeta vigilada, donde el equipo exporta a una carpeta que el software revisa y recoge; worklist, donde el equipo lee la agenda del centro para no teclear el paciente a mano; y acceso a la base de datos del equipo, por su API o directamente, para traer datos específicos. Cada una depende del equipo y del fabricante, y por eso se presupuesta por equipo, no por catálogo.

9.3. Y cuando el centro sí necesita infraestructura hospitalaria

Cuando un centro tiene muchas modalidades, mucho volumen y varios profesionales consultando estudios en paralelo, la solución razonable no es forzar un software de consulta clínica a hacer de archivo central: es tener uno de verdad y que dialogue con la historia clínica. La comparación entre las dos piezas —qué hace cada una y cuándo hace falta cada cual— está en la nota sobre interoperabilidad de imagen médica.