Ideas que todavía condicionan la forma en que entendemos la gestión de imágenes médicas
El PACS forma parte de la operación cotidiana de prácticamente cualquier institución que trabaja con diagnóstico por imágenes. Sin embargo, alrededor de él se han construido conceptos que, de tanto repetirse, han terminado aceptándose como verdades.
Algunos provienen de una época en que la tecnología era diferente. Otros nacen de confundir infraestructura, software, archivo, visualización e integración como si fueran una misma cosa.
Podría parecer una discusión meramente técnica, pero no lo es.
La manera en que una institución entiende su PACS puede determinar su capacidad para integrar nuevas modalidades, cambiar de tecnología, compartir información con médicos y pacientes, preservar su archivo histórico e incluso mantener su independencia frente a un determinado fabricante.
Por eso vale la pena revisar algunos de los mitos más frecuentes.
Mito 1: El PACS es un hardware
Durante años ha sido común escuchar expresiones como “el servidor PACS”, “el equipo PACS” o “la caja donde están guardadas las imágenes”.
Esto puede llevar a una primera confusión:
El PACS no es un hardware.
PACS significa Picture Archiving and Communication System. Es una plataforma de software destinada a recibir, gestionar, almacenar, recuperar, distribuir y comunicar imágenes médicas y la información relacionada con ellas.
Naturalmente, necesita infraestructura para funcionar. Puede operar sobre servidores físicos, máquinas virtuales, centros de datos, infraestructura en la nube o arquitecturas híbridas.
Pero esa infraestructura no es el PACS.
Un servidor puede reemplazarse, ampliarse o migrarse sin que por ello cambie necesariamente el sistema de gestión de imágenes. De la misma manera, una institución puede evolucionar su PACS sin que necesariamente tenga que sustituir toda su infraestructura.
Por eso, cuando se evalúa una solución, la pregunta no debería limitarse a:
¿Qué servidor incluye?
También deberíamos preguntarnos:
¿Qué tan bien administra, protege, integra y comunica nuestra información clínica?
El PACS no es la caja; es lo que hace posible que la información fluya.
Mito 2: RIS y PACS deben vivir separados
RIS y PACS cumplen funciones diferentes.
El RIS participa en la gestión del proceso radiológico: órdenes, pacientes, agenda, flujo de trabajo, estados, informes y otros elementos administrativos y clínicos.
El PACS gestiona fundamentalmente las imágenes y su información asociada.
Que sean conceptos diferentes no significa que deban convertirse en dos mundos separados.
Cuando existe una barrera entre ellos aparecen duplicaciones, búsquedas manuales, inconsistencias de información y pasos innecesarios para técnicos, radiólogos y personal administrativo.
La tecnología debería hacer exactamente lo contrario: eliminar esas barreras.
Desde la perspectiva del paciente existe un solo episodio de atención. Desde la perspectiva del personal que lo atiende, el proceso también debería sentirse continuo.
El paciente vive un solo proceso; sus sistemas también deberían vivirlo como uno solo.
RIS y PACS pueden tener responsabilidades distintas, pero deben intercambiar información de manera fluida para construir un único flujo de trabajo.
La integración no debería ser un lujo adicional. Debería formar parte de la arquitectura.
Mito 3: El PACS debe ser de la misma marca que la modalidad
Un centro de diagnóstico puede tener un tomógrafo de un fabricante, un resonador de otro, equipos de rayos X de una tercera marca y ultrasonidos de diferentes proveedores.
Eso es completamente normal.
Lo que no debería ser normal es pensar que cada uno necesita permanecer dentro de un ecosistema cerrado.
Uno de los grandes aportes de estándares como DICOM ha sido precisamente facilitar el intercambio de información entre equipos y sistemas de imágenes médicas. La compatibilidad real siempre debe verificarse entre las implementaciones concretas de los sistemas involucrados, pero el principio es claro:
La arquitectura debe favorecer la interoperabilidad.
La decisión sobre qué PACS utilizar debería responder a las necesidades clínicas, operativas y tecnológicas de la institución, no a la marca escrita en la parte frontal de un tomógrafo.
La información clínica no debería depender de la marca del equipo que la produjo.
La modalidad genera el estudio. No debería determinar el destino de la información para siempre.
Mito 4: El archivo pertenece al PACS
Este probablemente sea uno de los conceptos más importantes.
Las imágenes no deberían quedar cautivas de una plataforma.
Forman parte del patrimonio de información clínica de la institución y están vinculadas a la historia asistencial del paciente.
Por eso creemos que:
El archivo clínico de imágenes debe ser vendor-neutral, independientemente del PACS o visor que se utilice.
El concepto de Vendor Neutral Archive —VNA— busca precisamente reducir la dependencia del archivo respecto de una aplicación o fabricante determinado.
Esto adquiere especial importancia cuando una institución quiere incorporar nuevas tecnologías, utilizar diferentes sistemas, cambiar de PACS o conservar estudios durante muchos años.
Una infraestructura verdaderamente abierta debería permitir que la evolución de un componente no obligue a reconstruir toda la arquitectura.
Las imágenes forman parte de la historia clínica del paciente; no deberían quedar cautivas de una plataforma.
La independencia tecnológica comienza por la independencia de la información.
Mito 5: El visor es el PACS
Es fácil entender de dónde nace esta confusión.
El visor es la parte que vemos.
Es donde aparecen las imágenes, donde se navega por las series y donde el profesional utiliza diferentes herramientas para examinarlas.
Pero la parte visible no es necesariamente el sistema completo.
El PACS recibe estudios, administra información, organiza, almacena, recupera, distribuye y comunica. El visor es una de las herramientas utilizadas para acceder a esa información.
Una analogía sencilla puede ayudar:
El visor es una ventana. El PACS es mucho más que la ventana.
Separar ambos conceptos tiene una consecuencia importante: permite entender que el archivo de imágenes no debería depender obligatoriamente de una única herramienta de visualización.
Mito 6: Solo debe existir un visor
Si el visor y el archivo son conceptos distintos, aparece naturalmente otra posibilidad:
Una institución puede utilizar diferentes visores para diferentes necesidades.
El radiólogo puede requerir herramientas avanzadas para interpretación diagnóstica.
Otro especialista puede necesitar consultar determinadas imágenes dentro de su flujo clínico.
El médico referente puede requerir acceso rápido al estudio y al informe.
El paciente puede necesitar una forma sencilla de recibir o consultar sus imágenes.
Incluso determinadas especialidades pueden necesitar herramientas de visualización particulares.
No existe razón para convertir al visor en una nueva forma de dependencia tecnológica.
La arquitectura debería permitir seleccionar las herramientas apropiadas para cada función.
La independencia del archivo permite elegir la mejor herramienta para cada necesidad.
Cambiar o incorporar un visor no debería significar cambiar el archivo clínico.
Mito 7: Todo visor sirve para diagnóstico
Aquí conviene hacer una distinción especialmente importante.
Ver una imagen y utilizarla para realizar un diagnóstico no son necesariamente la misma cosa.
Existen visores preparados para trabajar con información DICOM y con las herramientas necesarias para el trabajo clínico y diagnóstico. Cuando el visor se utiliza con fines diagnósticos también deben considerarse las características técnicas, el entorno de visualización y las autorizaciones o requisitos regulatorios que correspondan.
Por otro lado, existen visores ligeros —que podemos denominar LITE— cuyo objetivo puede ser facilitar la consulta o compartir imágenes de referencia con pacientes y otros usuarios.
Por ejemplo, pueden utilizar imágenes derivadas en JPG para hacer más sencilla su distribución y visualización.
Son herramientas muy útiles.
Pero su propósito no es sustituir a una estación o visor destinado al diagnóstico.
Ver una imagen no es lo mismo que diagnosticar con ella.
No se trata de decidir cuál visor es “mejor”. Se trata de utilizar la herramienta correcta para cada propósito.
Mito 8: La función principal del PACS es almacenar imágenes
El almacenamiento es fundamental.
Pero reducir un PACS a un gran depósito digital es desaprovechar buena parte de su verdadero valor.
La propia letra C de PACS corresponde a Communication.
La comunicación no es un accesorio del concepto. Forma parte de él.
Las imágenes deben llegar al radiólogo, pero el proceso no termina allí.
El informe y las imágenes pueden necesitar llegar al médico referente, integrarse con el expediente clínico, quedar disponibles para otros profesionales autorizados y, cuando corresponda, ser entregados al paciente.
Por eso adquieren importancia los portales de entrega, las integraciones con sistemas clínicos y otras herramientas de distribución segura de información.
Una buena arquitectura no se pregunta solamente dónde está almacenado el estudio.
También se pregunta:
¿Quién necesita esa información y cómo debe llegar hasta él?
El valor del PACS no termina cuando guarda el estudio; comienza a materializarse cuando ese estudio puede ser encontrado, interpretado, compartido e integrado al proceso clínico.
Una imagen perfectamente almacenada pero difícil de encontrar, compartir o integrar pierde buena parte de su utilidad dentro del proceso asistencial.
Mito 9: El PACS termina en radiología
Durante mucho tiempo los sistemas de imágenes fueron concebidos principalmente alrededor del departamento de radiología.
Pero el paciente no termina su recorrido cuando abandona ese departamento.
El resultado de un estudio normalmente forma parte de una decisión clínica posterior.
El médico que lo solicitó necesita conocer el resultado. Otros profesionales pueden necesitar acceder a él. El expediente médico puede requerir incorporar el informe y facilitar el acceso a las imágenes. Y el propio paciente puede necesitar recibirlas.
Por eso el PACS no debería convertirse en una isla.
Debería formar parte de un ecosistema de información clínica capaz de comunicarse con RIS, sistemas hospitalarios, expedientes médicos, portales y otras plataformas autorizadas.
Esto también cambia nuestra manera de pensar en el médico referente.
Para un centro de diagnóstico, el médico que refiere al paciente es parte fundamental del servicio. Facilitarle acceso oportuno a información e imágenes no es solamente una función tecnológica: forma parte de la calidad de atención que el centro proporciona.
La imagen no debería quedarse dentro del departamento de radiología.
Debe acompañar al proceso clínico allí donde genere valor para la atención del paciente.
Una forma diferente de entender el PACS
Después de revisar estos mitos aparece una conclusión.
Un PACS moderno no debería concebirse simplemente como un servidor, un visor o un lugar donde se almacenan estudios.
Debería formar parte de una arquitectura mucho más amplia.
Una arquitectura capaz de recibir imágenes de diferentes modalidades, integrarse con el flujo clínico, preservar un archivo independiente, permitir diferentes formas de visualización y comunicar la información a quienes participan legítimamente en la atención del paciente.
En otras palabras, debe permitir que la tecnología evolucione sin convertir la información en rehén de esa evolución.
En GT-IT Medical creemos que las mejores arquitecturas son aquellas que conectan sin crear dependencias innecesarias.
Por eso resumimos nuestra filosofía en una idea:
Integrar sin encerrar.
Integrar modalidades, sistemas, profesionales e información.
Pero preservar al mismo tiempo la capacidad de cada institución para decidir cómo quiere crecer, qué tecnologías quiere incorporar y cómo desea administrar el activo más importante de todo este ecosistema:
Su información clínica.
Esta conversación continúa
Hay otro mito que merece su propio espacio:
“El PACS nunca se cae.”
Todo sistema tecnológico puede enfrentar una interrupción. Y cuando eso ocurre aparecen preguntas diferentes: ¿tenemos respaldo?, ¿podemos continuar operando?, ¿cuánto tardamos en recuperarnos?, ¿backup y continuidad son realmente lo mismo?
Ese será el tema de nuestra próxima entrega de esta serie:
Cuando el PACS se cae
Continuidad, respaldo y recuperación no son lo mismo.