Gestionando imágenes NO-DICOM. ¿VNA o conversión a DICOM (PACS)? (Parte II – Alternativas)

En la entrada anterior nos hemos “situado” en el problema a tratar: la gestión de 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.

Identificacion paciente

Imagen de Freedigitalphotos.net

 

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.

Transmisión información

Imagen de Freedigitalphotos.net

 

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.)

Compartir información

Imagen de Freedigitalphotos.net

 

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.

En esta tercera entrada expongo mis conclusiones sobre lo aquí expuesto.

Anuncios

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: