Novedades del sitio | News

VNA – Vendor Neutral Archive

 
Simulador TTE
VNA – Vendor Neutral Archive
de Administrador TTE - viernes, 10 de marzo de 2017, 16:22
 

VNA – Vendor Neutral Archive

por Sergio García Prado

¿PACS único o departamental?

La digitalización del departamento de Radiología es un hecho en casi la totalidad de Hospitales. El que más o el que menos tiene un PACS para radiología.

 

Los siguientes pasos lógicos son digitalizar el resto de imagen médica que, al margen de radiología, no es poca cosa lo que falta. Por citar algunos ejemplos tenemos que contar con Medicina Nuclear, Radioterapia, Oftalmología, Ginecología, Dermatología, Cirugía Estética, Cardiología, Anatomía Patológica (que daría para una buena serie de posts), etc.

Todos estos servicios trabajan con imagen. Y dicha imagen en muchos casos no es DICOM.

¿Qué hacemos con esas imágenes? La respuesta es obvia: almacenarlas ordenadamente.

¿Dónde las almacenamos? En un repositorio de información ordenado, o lo que es lo mismo, un PACS (aunque existen otras opciones).

¿En qué formato? Tenemos dos opciones fundamentales: 1) En su formato origen, lo cual puede complicar su distribución al resto de profesionales del área sanitaria, ó 2) Tratando, en la medida de lo posible, de estandarizar el formato, y en este caso el más común es DICOM.

Con cualquiera de las dos opciones las imágenes pueden ser almacenadas en un PACS y, en especial, si optamos por la dicomización previa de la imagen. Podemos aprovechar además la interfaz HL7 que suele ir ligada a los PACS para alimentar de información a la Historia Clínica Electrónica.

 

Ante este escenario, ¿es mejor tener un único PACS en el centro sanitario o un PACS por cada departamento? Esta pregunta no tiene una respuesta verdadera o falsa al 100%. De todas formas cabe suponer que será más sencillo de integrar en una HCE si existe un único “punto de contacto”  entre ésta y el repositorio de imágenes. Si a eso le sumamos la posible existencia de un Visor Médico Universal como del que os hablaba en una entrada anterior, la elección se acabaría decantando por un PACS central.

… también podríamos hablar de un PACS (o repositorio de información, por ejemplo estilo XDS) a nivel extra-Hospitalario (a un nivel superior, por ejemplo de Comunidad Autónoma), pero eso lo hablaremos en otro momento…

Gestionando imágenes NO-DICOM

Una vez que la mayoría de servicios de radiología ya han digitalizado sus imágenes y se utilizan sistemas PACS en todo centro diagnóstico que cuente con radiología, radioterapia, medicina nuclear y servicios afines (generalmente con maquinaria nativamente

DICOM), el siguiente paso es abordar la digitalización de la imagen no radiológica, o mejor dicho, NO-DICOM.

Centrados en este punto de la gestión de la imagen NO-DICOM a continuación explicaré en este post (y sucesivos) las diferentes estrategias que se pueden plantear y mis ideas personales al respecto como mejor estrategia para abordar este asunto. Este primer post es una introducción al asunto, que abordaré en posts sucesivos en mayor profundidad.

Partimos por tanto de imágenes de todo tipo de fuentes: cámaras fotográficas (ver esta solución al respecto), vídeos de todo tipo, formato y longitud generados en quirófano, análisis del movimiento, análisis del sueño, etc., imágenes de oftalmología, endoscopias, anatomía patológica (ver entrada al respecto), y un sin fin de servicios que manejan imagen médica y que en muchos casos no se está almacenando convenientemente ni incorporando a (ni distribuyendo a través de) la Historia Clínica Electrónica (o Intranet en su defecto).

En este escenario se observan dos alternativas claras:

  • Conversión de todas esas imágenes a formato DICOM y almacenaje en un sistema PACS más o menos convencional (compartido con radiología y servicios afines o específico para este uso – ver esta entrada -).
  • Uso de un VNA.

No voy a explicar lo que es un PACS por que es algo ya muy común en los Centros Sanitarios y cualquiera ya ha interactuado de una forma u otra con uno. Aquí la entrada en la Wikipedia.

Sin embargo sí voy a detenerme un poco en explicar que se entiende por VNA.

VNA – Vendor Neutral Archive

La traducción del término a castellano podría ser la de archivo no vinculado a ningún proveedor.

A partir de esa definición se puede entender un VNA como un PACS que almacena los objetos DICOM en un formato estándar 100%, sin modificar éstos y convertirlos en propietarios de algún proveedor. Casi cualquier proveedor dispone de un PACS con estas características. En algunos documentos este tipo de PACS es denominado PNA (PACS Neutral Archive).

Sin embargo el término VNA va un poco más allá… o al menos eso se dice, por que no está claro el alcance del término. Está bastante extendido que un VNA implementa todas o algunas de las siguientes características:

  • Almacena tanto imágenes DICOM como imágenes NO-DICOM en su formato original. En el término imágenes incluimos vídeos.
  • Almacena objetos que no son imágenes (informes – radiológicos o no – incluso en formato CDA, resultados de laboratorio, todo tipo de documentos adjuntados a un episodio clínico, audio, etc.)
  • Implementa el perfil IHE xds-i (Cross Enterprise Document Sharing for Imaging).
  • Implementa WADO (Web Access to DICOM Objects). (PowerPoint de nema.org sobre Wado, aquí).
  • Un VNA es capaz de transformar los datos entrantes, comunicándose con la infraestructura xds-i (repositorio xds, registro xds y PIX – Patient Identifier Cross-Referencing -) y obteniendo información adicional del paciente o de la prueba.
  • Un VNA actúa de fachada ante una federación de sistemas de almacenamiento distribuidos (PACS o de otro tipo) posibilitando el intercambio de información entre distintos Hospitales o empresas.
  • Tiene independencia del motor de base de datos, pudiendo éste ser variado.
  • Genera auditoría de accesos.

Como veis, no está clara la definición de un VNA o al menos ésta no es exacta.

Lidiando con la imagen no radiológica…

Una vez centrados en qué es un VNA (vale, más o menos), ¿cuál es la estrategia correcta para la gestión de la imagen no radiológica (o mejor dicho, NO DICOM)?

Principales cuestiones sobre la gestión de la imagen NO-DICOM:

  • Identificación y asociación con el paciente y episodio clínico correcto.
  • Envío y almacenamiento seguro.
  • Distribución de dicha imagen.
  • Otros temas: reaprovechamiento de infraestructuras, portabilidad, facilidad de cambio de proveedor, etc.

Identificación y asociación

La principal cuestión desde mi punto de vista reside en la asociación de las imágenes (y otro tipo de documentos) con un episodio clínico y por tanto con un paciente concreto. Una imagen o un vídeo no dicen nada sin asociarse a un paciente y una dolencia.

El formato DICOM soluciona este problema de forma intrínseca dado que cada objeto (generalmente imagen) lleva asociada una meta información que de forma explicita aporta ese conocimiento necesario.
Da igual de donde se recupere un objeto DICOM, siempre se sabrá de qué paciente es, cuando se ha generado, que prueba es la realizada, en qué máquina, etc.

En el caso de archivado en un VNA la meta información deberá viajar siempre en paralelo con el objeto es cuestión.

Si contamos con fuentes de imagen nativas DICOM la meta información la obtenemos directamente de la lista de trabajo (Worklist DICOM) o en su defecto mediante la introducción manual en la modalidad diagnóstica.

Cuando la modalidad diagnóstica fuente no dispone de servicios DICOM se debe pasar obligatoriamente por un proceso de aportación de dicha meta información. Para ese proceso existen multitud de soluciones para la captura de la imagen que son a su vez clientes de lista de trabajo lo que facilita el proceso y en determinadas situaciones se puede hasta automatizar (evitando así la intervención manual). Estas soluciones permiten además en algunos casos obtener la imagen directamente de la propia modalidad conectándose directamente a ésta (framegrabbers y similares).
Una vez obtenidos los datos de la Worklist DICOM, la creación de objetos DICOM es fácil y sencilla.

Para incluir una imagen en un VNA no hay una interfaz estándar (como el DICOM) que solucione este paso. Por tanto será necesario contar con soluciones no estándares como por ejemplo el uso de Web Services, ficheros XML, etc., para dotar de la meta información necesaria al objeto.

 

Envío y almacenamiento seguro

En el caso de los objetos DICOM (imagen + meta información), la transmisión a un PACS se realiza por protocolo estándar DICOM 3.0. A su vez el PACS, (específico para este tipo de imágenes o común con radiología y otros servicios análogos), transmitirá la información recibida siguiendo flujos de trabajo análogos a los empleados para radiología hacia la Historia Clínica Electrónica del paciente (generalmente por HL7).

Cuando hablamos de enviar imágenes u objetos a un VNA, para la transferencia del propio objeto tampoco hay un método común: carpetas compartidas, FTP, CIFS, sockets, etc. Cualquiera de estos métodos serán poco portables entre distintos proveedores de VNA, por lo que la neutralidad queda cuanto menos en entredicho.

Cierto que existe un método estándar para la transmisión de información a un VNA, implementar el perfil IHE XDS-I, lo cual para empezar requiere tener una infraestructura XDS operativa (repositorio, registro, PIX – Patient Identifier Cross-referencing – ó EMPI – Enterprise Master Patient Index – ) con la que no se cuenta en la mayoría de centros sanitarios en España en 2016.

Además hay que tener en cuenta que de las modalidades fuente de imágenes (u otro tipo de documentos), a día de hoy, ¿cuáles implementan dicho perfil?

En el tema seguridad de la información no hay grandes diferencias entre una y otra alternativa y depende más de la infraestructura TI sobre la que se implemente y las soluciones de Alta Disponibilidad adoptadas que del sistema en sí mismo.

 

Distribución de la imagen almacenada (u otros objetos)

Una vez que hemos insertado la imagen NO-DICOM en un PACS o en un VNA y que éstos han devuelto la información al RIS/HIS/HCE/Intranet o sistema de información sanitario del que se disponga, el siguiente paso es que un usuario pueda ver esas imágenes desde su puesto de trabajo.

Para un uso diagnóstico generalmente se cuenta con estaciones de trabajo específicas con un Software que aporta herramientas particulares para el tipo de imagen u objeto a revisar. Estas estaciones están presentes en los servicios que han generado la información en un número limitado.

Para un uso clínico (a lo largo de todo el Hospital o Centro Sanitario – incluyendo en muchos casos Atención Primaria u otros servicios dependientes -) se suele utilizar un visor Web asociado al RIS/HIS/HCE/Intranet de turno. Si el proceso seguido se ha basado en la conversión a DICOM y envío a un PACS el propio visor Web ya desplegado para radiología soportará la presentación de la imagen no radiológica sin mayor intervención.

En el caso de haber introducido esta imagen a un VNA y dado que éste almacena la imagen en formato original (jpg, tiff, bmp, mp3, mp4, mov, wma, etc.) se deberá contar con un visor universal que posibilite la visualización de este tipo de objetos tengan el formato que tengan y estén generados con cualquier códec de compresión. Un visor de este tipo, ver aquí un ejemplo, tiene un coste de adquisición muy importante y debe ser considerado. En caso de no contar con este tipo de visores el intentar abordar presentar este tipo de objetos en los equipos cliente se puede convertir en una auténtica pesadilla (“no puedo abrir este tipo de formato“, “me falta <x> códec”, etc.)

 

XDS: Cross-Enterprise Document Sharing

Si nos salimos de lo que aporta DICOM a la hora de estandarizar el formato y las comunicaciones (a través del protocolo del mismo nombre) nos encontramos en que la única solución estandarizada para la gestión de documentos y objetos médicos es XDS y su versión específica para imagen XDS-I.

XDS y XDS-I establecen un modelo de información, formas para interrogar, recuperar y almacenar objetos. Por contra esta tecnología no está muy difundida aún. XDS y XDS-I aceptan multitud de formatos de los archivos origen (incluyendo el DICOM). El uso de una infraestructura XDS implica la existencia de un EMPI (Enterprise Master Patient Index) que ya he mencionado anteriormente y establece que los protocolos de comunicación se basan en Web Services.

Los repositorios de datos, fuentes de datos, consumidores de datos (imagen u otros documentos) pueden intercambiar objetos DICOM y NO-DICOM en formato nativo si cada uno de ellos implementan XDS/XDS-I. Y ese es el problema, que muy pocas fuentes de datos y consumidores de información actualmente lo soportan.

También se debe tener en cuenta que adquirir dispositivos fuente o PACS que implementen XDS/XDS-I puede tener un sobrecoste importante con respecto a soluciones que no lo implementen, encareciendo por tanto toda la solución.

Otros temas

Reviso aquí otros temas a considerar:

Reaprovechamiento de infraestructuras

Cada Hospital o Centro Sanitario dispone ya de un sistema PACS y de un distribuidor Web que soporte el formato DICOM de las imágenes. La opción de la conversión a DICOM de las imágenes no radiológicas permite aprovechar infraestructuras tanto Software (el PACS ya existente así como el distribuidor Web), como hardware (potencia de cálculo, almacenamiento, sistemas de alta disponibilidad, backup, etc.). También se aprovecharían los flujos de información (específicamente la mensajería HL7) con muy pocos cambios para la recepción de información de la DICOM Worklist así como para la devolución de actividad.

En el caso de optar por el archivo en un VNA éste debe ser montado, con su propio almacenamiento y posiblemente sin prescindir del PACS existente. También se necesitarían nuevos mecanismos para la visualización de imagen en su formato original. La parte de mensajería debería ser modificada/desarrollada en profundidad. No se aprovecharía prácticamente nada de lo ya existente.

Portabilidad de imágenes/objetos

Un objeto DICOM nativo es compatible con cualquier visor que soporte dicho formato. Cualquier Hospital tiene un visor diagnóstico y un distribuidor Web que acepta este formato ya que es el más común en la medicina y casi el único en el caso de imágenes radiológicas.

Un objeto NO-DICOM en su formato nativo puede ser no entendido por un sistema externo. Empezando por que puede estar generado en un formato propietario y por tanto imposible de portar a otro sistema distinto.

Facilidad de cambio de proveedor

Un PACS (PNA = PACS Neutral Archive) que almacena imágenes en disco DICOM 100% estándar es relativamente fácil de migrar: tanto accediendo a las imágenes y reconstruyendo la indexación de la BD en base a la información DICOM de las mismas como migrando los Path de las mismas de BD a BD si esto fuese posible ya que la estructura suele ser muy similar (estudios/series/imágenes)

Un VNA no tiene una estandarización ni de cómo almacenar los objetos, ni de cómo indexarlos. Esto complica enormemente la tarea de migrar un VNA de un proveedor a otro. Se debería por tanto recuperar tanto los objetos como la meta información vía repositorio XDS-I o con las APIs que el VNA en cuestión proporcione para ser interrogado. La tarea no es obvia.

Conclusiones

Del citado análisis se pueden sacar estas conclusiones a favor de la conversión a formato DICOM y envío a un PACS:

  • DICOM proporciona un formato de archivo estándar. Comprensible por multitud de visores.
  • DICOM proporciona un modelo de información estándar. Así mismo genera BD estándar que son fácilmente consultables.
  • DICOM proporciona un protocolo de comunicaciones estándar y ampliamente utilizado en todo el mundo.
  • DICOM, usado para almacenar objetos en formato no propietario (PNA = PACS Neutral Archive), garantiza la portabilidad entre sistemas y proveedores al poder todos entender tanto la estructura como los propios objetos DICOM almcenados.

Por conta, VNA se anuncia como el sistema que nunca más vas a tener que migrar. Bajo mi punto de vista es completamente falso, salvo que nunca pretendas cambiar de proveedor:

  • El almacenamiento se vuelve obsoleto, por lo que como mínimo tendrás que migrar los objetos de un almacenamiento a otro.
  • El modelo de información interno es distinto de un proveedor a otro. La migración se complica.
  • Las integraciones con las fuentes de imagen (identificación y asociación de imágenes y envío al VNA) son generalmente propietarias, tocará volver a realizarlas (salvo utilización de perfiles IHE como XDS-I, poco extendidos en la realidad del año 2016).
  • La integración de distintos visores multi-formato con VNAs de distintos proveedores es cuanto menos complicada.

Dado que DICOM es el estándar predominante para la gestión de imagen médica estructurada parece razonable elegir DICOM también para el resto de imagen médica.

 

Hay que tener también en cuenta el factor coste:

  • Un VNA no es un PACS, y dependiendo de las características del primero es posible que se necesite de todos modos un PACS “en la sombra” que aporte, entre otras cosas, una interfaz WADO (Web Access to DICOM Objects).
  • Los sistemas que implementan XDS/XDS-I son por lo general sensiblemente más caros que los que no lo hacen.
  • Un VNA necesita la implantación de una infraestructura XDS (repositorio, registro y PIX/EMPI), lo cual tampoco es trivial.

He oído más de una vez lo siguiente:

“El PACS es de radiología, el resto de imagen tiene que ir a otro sitio”

No hay aseveración más falsa que esa por dos motivos:

  • En ningún sitio está definido que el PACS deba ser exclusivo para radiología. El propio acrónimo Picture Archive and Communications System indica de su traducción literal que es un sistema de archivado de imágenes (médicas) y transmisión de las mismas. ¿Por qué se debe circunscribir únicamente a Radiología?
  • Si no se desea “mezclar” la imagen radiológica con la no radiológica, se pueden instalar distintos PACS, tal como se mencionaba en ¿PACS único o departamental?

Conclusiones personales

A mi entender y a fecha de hoy (2016) la solución más lógica y más práctica para la gestión de imagen NO-DICOM, es la conversión a DICOM, ya que permite aprovechar al máximo las infraestructuras ya disponibles y tiene un menor impacto para el Hospital o Centro Médico.

Un VNA es el futuro, aún algo lejano, y no tiene sentido sin la implementación de una red XDS en el Hospital o Centro Médico. A día de hoy es poco justificable la inversión que requiere en términos económicos y en cuanto al trabajo necesario para su implantación.

Link: https://informaticasanidad.wordpress.com