Qué es un PACS: definición, para qué sirve y cuándo hace falta uno de verdad

1. Qué es un PACS, en una frase

PACS (Picture Archiving and Communication System) es un sistema de archivo y distribución de imagen médica que recibe estudios en formato DICOM desde varias modalidades de diagnóstico, los almacena de forma centralizada y los sirve a quien los pide —una estación de trabajo, un visor, otro centro— sin que nadie tenga que mover el archivo a mano. Ver qué es una modalidad DICOM y su papel en el catálogo del centro.

1.1. La pieza clave: recibe sin intervención humana

Lo que define a un PACS no es solo «guardar imágenes»: es hacerlo como destino de red al que las modalidades envían el estudio automáticamente en el momento en que termina la adquisición, mediante un mecanismo de transmisión que el propio estándar DICOM define. Un almacén de archivos al que alguien sube manualmente los estudios no es, técnicamente, un PACS.

1.2. Quién usa un PACS en la práctica

Hospitales con servicio de radiología, grandes grupos con varios centros de imagen, y cualquier organización donde el volumen de estudios diarios hace inviable moverlos a mano. En oftalmología, un centro con varios OCT, topógrafos y biómetros funcionando en paralelo empieza a acercarse a ese perfil.

2. De dónde viene la necesidad de un PACS

Antes de que existiera esta infraestructura, cada sala de imagen guardaba sus estudios en el propio equipo o en un ordenador local, y llevar una placa o un estudio de una sala a otra significaba copiarlo a un soporte físico. Un PACS nació para resolver, a escala de hospital, tres problemas concretos.

2.1. El archivo disperso

Sin un sistema central, cada equipo es su propia isla de almacenamiento, con su propia capacidad limitada y su propio riesgo de pérdida si el equipo falla.

2.2. El acceso simultáneo

Varios profesionales necesitan ver el mismo estudio a la vez, desde puestos distintos, sin esperar a que alguien libere un ordenador o copie un archivo.

2.3. La distribución hacia fuera

Enviar un estudio a un especialista externo, a otro centro o a un sistema regional de salud exige un protocolo de transmisión fiable, no un archivo adjunto a un correo.

3. Las tres piezas de un PACS completo

El archivo central, la red de recepción y las estaciones de visualización son piezas distintas dentro de un mismo sistema PACS.

3.1. El servidor de archivo

Donde se guardan físicamente los estudios, con su propia gestión de capacidad, redundancia y copias de seguridad — a esa escala, casi siempre infraestructura dedicada.

3.2. El motor de recepción y comunicación

El componente que escucha la red, acepta las conexiones de las modalidades y gestiona el protocolo de transmisión DICOM (la operación de recepción se llama, en la jerga del estándar, C-STORE).

3.3. Las estaciones de visualización

Los puestos desde los que un profesional consulta el archivo central: pueden ser programas dedicados de diagnóstico o visores más ligeros integrados en el software clínico.

4. PACS frente a visor DICOM: la diferencia que importa

Esta es la confusión más rentable para quien vende software, y la más cara para quien lo compra sin comprobarla.

4.1. Lo que hace un visor DICOM

Abre, muestra, mide y permite comparar archivos DICOM que ya están dentro del expediente del paciente. No necesita escuchar la red ni recibir estudios automáticamente: trabaja con lo que ya se ha subido o traído al sistema.

4.2. Lo que añade un PACS por encima de eso

La recepción automática por red, el archivo centralizado a gran escala y la distribución a estaciones externas. Es una capa de infraestructura completa, no una función que se activa con un interruptor.

4.3. Por qué el matiz importa al comparar software

Un proveedor puede decir «compatible con PACS» porque su visor sabe leer archivos DICOM exportados por un PACS ajeno, sin que eso signifique que el propio software incluya un servidor PACS. Ambas cosas son legítimas, pero no son lo mismo, y solo una responde a la pregunta «¿me llega el estudio solo, sin que nadie lo suba?».

5. Cuándo hace falta un PACS de verdad

• Cuando el volumen diario de estudios hace inviable subirlos uno a uno a mano.
• Cuando varias salas o varios centros necesitan compartir el mismo archivo en tiempo real.
• Cuando hay que distribuir estudios de forma sistemática a especialistas externos o a un sistema regional de salud.
• Cuando la organización ya opera a escala hospitalaria, con radiología como servicio central.

5.1. El umbral no es el número de equipos, es el trabajo manual

La pregunta útil no es cuántas máquinas tienes, sino cuánto tiempo de alguien se va cada semana en mover archivos de un sitio a otro. Dos equipos con mucha actividad generan más carga manual que cinco que se usan de vez en cuando. Mide una semana real —quién sube los estudios, cuántos minutos le lleva, cuántos se quedan sin subir— y tendrás la respuesta sin necesidad de que te la dé un comercial.

5.2. El otro umbral: cuántas manos y cuántas sedes

Un archivo central se justifica cuando varias personas necesitan el mismo estudio a la vez y desde sitios distintos. Con una sola consulta y un único profesional revisando, la simultaneidad no existe como problema. Con tres sedes que se derivan pacientes entre sí, aparece todas las semanas, y cada vez que aparece alguien acaba enviando un archivo por un canal que no debería usar para datos de salud.

5.3. La señal que casi nadie mide: los estudios que faltan

Antes de decidir nada, cuenta cuántas pruebas hechas el mes pasado no están hoy en la ficha del paciente. Ese número, y no la potencia del servidor, es el que dice si el flujo actual aguanta. Si es cero, no necesitas infraestructura nueva. Si no lo es, ya sabes cuánto te está costando el sistema que tienes, aunque no aparezca en ninguna factura.

6. Cuándo NO hace falta, y qué basta en su lugar

Una consulta o clínica con un número limitado de equipos de imagen y un volumen de estudios que una persona puede gestionar sin ahogarse no necesita, casi nunca, la infraestructura y el coste de un PACS completo.

6.1. Lo que suele bastar

Un visor DICOM integrado en el software clínico, junto con un mecanismo de traspaso —manual, por carpeta vigilada o por worklist según lo que soporte cada equipo— cubre el mismo objetivo final (tener el estudio en el expediente del paciente) sin la carga de mantener un servidor dedicado.

6.2. La señal de que ya te está quedando pequeño

Si el número de estudios diarios empieza a hacer que subirlos a mano consuma un tiempo de personal notable, o si varios centros necesitan compartir el mismo archivo constantemente, ese es el momento de evaluar un PACS específico, normalmente como proyecto aparte del software de gestión clínica.

7. Qué comprobar antes de creer que un software «tiene PACS»

Antes de decidir en función de esa palabra, conviene pedir respuesta concreta a estos cuatro puntos:

• ¿El estudio llega automáticamente por red, sin que nadie lo suba, o hay un paso manual o semiautomático de por medio?
• ¿Cuántas modalidades a la vez puede recibir el sistema sin degradarse?
• ¿Quién gestiona el almacenamiento y sus copias de seguridad, y con qué capacidad?
• ¿El sistema puede distribuir estudios a estaciones externas, o solo los muestra dentro de su propia interfaz?

Si la respuesta al primero es «hay un paso intermedio», lo que tienes delante es un visor con un mecanismo de carga, no un PACS — y eso puede ser exactamente lo que tu clínica necesita, siempre que se llame por su nombre.

7.1. La prueba que zanja la discusión en diez minutos

Pide una demostración con un equipo real: que alguien haga una prueba y que nadie toque nada después. O el estudio aparece solo en la ficha del paciente, o no. Ninguna hoja de características resiste esa comprobación, y no hace falta entender el protocolo de red para interpretarla. Es además la conversación más honesta que puedes tener con un proveedor, porque le obliga a enseñar el flujo entero en vez de una pantalla.

7.2. Quién responde cuando el archivo crece

Las imágenes médicas crecen mucho más rápido que el texto de una historia clínica, y el crecimiento no es lineal: llega con el equipo nuevo, con la campaña de revisiones, con el cambio de protocolo que dobla el número de cortes. Pregunta qué pasa cuando el volumen se multiplique, quién asume ese coste y con cuánta antelación te van a avisar. Si nadie tiene esa respuesta preparada, el problema no desaparece: solo aparecerá más tarde.

7.3. Y qué pasa el día que te vas

La portabilidad se comprueba antes de contratar, no al terminar. Pregunta en qué formato podrías sacar todos tus estudios, cuánto tarda esa exportación, si incluye los datos que identifican cada prueba y si tiene coste. Un archivo del que no puedes salir con tus propios datos no es un archivo, es una dependencia — y en imagen médica esa dependencia se mide en años de historial clínico.

8. El coste real de un PACS: no es solo la licencia

Un PACS completo implica servidor dedicado (propio o en la nube), su mantenimiento, su copia de seguridad a un volumen de datos que crece rápido —las imágenes médicas pesan mucho más que el texto de una historia clínica— y personal técnico capaz de sostenerlo. Para una clínica pequeña, ese coste suele superar con margen el beneficio frente a un visor bien integrado.

8.1. Lo que se paga una vez y lo que se paga siempre

La licencia se negocia una vez y se recuerda para siempre; el almacenamiento, en cambio, se paga cada mes y crece solo. A la hora de comparar, separa las dos columnas y proyéctalas a cinco años con el volumen que esperas tener, no con el de hoy. Muchas decisiones que parecen caras el primer año resultan baratas al cuarto, y al revés — pero eso no se ve si todo va mezclado en una única cifra.

8.2. El coste que no aparece en el presupuesto: quién lo cuida

Una infraestructura de archivo necesita a alguien que vigile el espacio libre, revise que las copias se están haciendo, aplique actualizaciones y responda cuando un puesto deja de ver el archivo. En un hospital eso es un puesto de trabajo; en una clínica pequeña suele ser «el que más sabe de ordenadores», que además tiene otro trabajo. Ese es el punto donde estos proyectos se degradan, y casi nunca está escrito en ninguna oferta.

8.3. La alternativa razonable, dicha con sus límites

Para la mayoría de las consultas, un visor integrado en el historial más un mecanismo de traspaso acordado equipo por equipo cubre el objetivo real —que el estudio esté en la ficha del paciente— con una fracción del coste. No es lo mismo que un PACS y no conviene venderlo como tal: no recibe de cualquier modalidad por red ni distribuye a estaciones externas. Simplemente, en ese tamaño de centro, casi nunca hace falta que lo haga.

9. Qué aporta obeliOmed con esto

9.1. Lo que sí hace

obeliOmed ofrece un visor DICOM integrado en el expediente del paciente, de forma que el estudio se consulta donde está el resto de la historia y no en el ordenador de una sala concreta. Como vías de traspaso desde el equipo hay carpeta vigilada, worklist y acceso a la base de datos del propio equipo, por su API o de forma directa, según lo que permita cada fabricante.

9.2. Lo que no hace, y por qué se dice

obeliOmed no es un servidor PACS ni se anuncia como tal: no recibe estudios por red de forma automática desde cualquier equipo. Decirlo con claridad ahorra la conversación incómoda del tercer mes, cuando alguien descubre que lo que compró no era lo que entendió. Para una consulta o clínica de tamaño pequeño o mediano, lo anterior suele cubrir la necesidad real sin el coste de mantener infraestructura de archivo.

9.3. Y cuándo te diríamos que necesitas otra cosa

Si tu centro ya opera con radiología como servicio, varias sedes compartiendo archivo y distribución sistemática a terceros, lo que necesitas es un PACS específico, normalmente como proyecto aparte del software de gestión clínica. Que el historial siga siendo el sitio donde vive el resto del caso no cambia esa conclusión: son dos capas distintas y cada una resuelve un problema distinto.