SolidQ Summit Alicante 2018 – Training SolidQ

Estamos barajando acudir a este evento de 3 dias en Alicante. Conocemos a SolidQ y hemos trabajado con ellos en el pasado.

Parece una buena oportunidad de profundizar e intercambiar conocimientos en torno al SQL Server… Que es el SGDB principal para todas las soluciones IT de la empresa.

¿Algún lector va a asistir o ha asistido en anteriores años?

https://training.solidq.com/es/solidq-summit-madrid/

Anuncios

IRE Info Channel… perdiendo la “R” del RIS

IRE Info Channel - Sistema de Gestión de Imagen Médica

IRE Info Channel es la denominación comercial del RIS (Radiology Information Systems) de IRE Rayos X.

Inicialmente se diseñó para funcionar como un RIS típico y por tanto gestionar los flujos de trabajo habituales del departamento de Radiología con base al catálogo de exploraciones establecido por la SERAM.

IRE Info Channel - Sistema de Gestión de Imagen Médica

Con el tiempo se han ido añadiendo funcionalidades que abarcan más allá del departamento de Radiología pasando a ser un Software destinado a la gestión integral de la imagen médica digital.

Al RIS Radiológico germen se han incorporado funciones específicas para las siguientes especialidades médicas:

  • Medicina Nuclear: primera variante del Software. Se gestiona el registro, confección y trazabilidad del radiofármaco, así como de la actividad del mismo. Igualmente el catálogo utilizado es el de la SEMNIM en vez del SERAM.
  • Screening de Mama: modificaciones específicas para los procesos de cribado de mamografía, con doble lectura ciega, consenso automático, tercera opinión (de desempate), utilización de códigos Bi-Rads, registro de la densidad de la mama, control de tiempo de informado contínuo, carga automática de pruebas previas y complementarias, etc.
  • Gestión de imagen no radiológica DICOM: generando lista de trabajo DICOM para aquellas modalidades y departamentos que sin gestionar imagen radiológica si disponen de modalidades (o interfaces/gateways), que permiten trabajar con el formato DICOM y su almacenaje en un PACS, dotando por tanto a estos servicios de la mensajería HL7 y del resto de elementos de comunicación necesarios para incorporar las imágenes médicas a la Historia Clínica Electrónica del Paciente.
  • Screening de Retinopatía Diabética (Oftalmología): generando lista de trabajo DICOM para los retinógrafos, y permitiendo una doble lectura por Óptico y Oftalmólogo. Asimismo se incorporan las imágenes más representativas de cada ojo al informe y se transmiten los resultados como objetos CDA.
  • Dermatología: permite junto con la aplicación Photo DICOM, la gestión sencilla de la toma de muestras fotográficas y su archivado en el PACS, así como de incorporación de los resultados a la HCE del Paciente. Utilizamos como catálogo de pruebas el subconjunto específico de CIE-10.

RIS

Como se puede apreciar el RIS cada vez es menos “R”adiology y de ahí el título de esta entrada. Es evidente que el producto evoluciona y se adapta a nuevas necesidades con facilidad y celeridad.

En un futuro nuevas especializaciones se incorporarán. La más inmediata será que el propio sistema se convierta en Portal del Paciente en el ámbito de RIS (Radiológico) en clínicas privadas, para que los propios pacientes puedan acceder a su Historial Radiológico (tanto informes como imágenes) así como a su descarga en formato DICOM junto con un visor compatible mediante protocolos de comunicación seguros.

Preparando una “remesa” de Photo DICOM

En estos días y ante la entrega inminente de 4 Samsung Galaxy S8 con Photo DICOM incorporado para el servicio de Dermatología de un importante cliente, he aprovechado para revisar el proyecto e incorporar varias mejoras…

Logo Photo DICOM

Cito algunas de ellas:

  • Compilación con API 26 (Android 8 – Oreo).
  • Adaptación a permisos estilo API 23 ( Android 6 – Marshmallow).
  • Se añade sistema de licenciamiento, que permite sustituir una dispositivo por otro conservando la licencia.
  • Dado que la aplicación no se distribuye por el Google Play, se ha creado un sistema de auto-actualización desde los servidores de IRE Rayos X o desde los propios del cliente, según el caso.
  • Nuevas pantallas de configuración y cambios introducidos.
  • Reescritura de rutinas obsoletas y de llamada a la cámara del sistema.
  • Se añade la posibilidad de eliminar automáticamente las imágenes del dispositivo ya subidas al PACS para reforzar la seguridad y privacidad (LOPD/GDPR).
  • Selección de Agenda / Médico Responsable por defecto.
  • Selección de Diagnóstico o Procedimiento desde la app con actualización en RIS/PACS/Lista de trabajo DICOM e información local de la app.

Como se puede apreciar en la siguiente foto la conjunción de los Galaxy S8 con Photo DICOM resulta como “anillo al dedo”:

Samsung Galaxy S8 ejecutando Photo DICOM

Podéis encontrar más información sobre Photo DICOM en los siguientes enlaces:

Photo DICOM (III) – Brochure

Photo DICOM (II) – Presentación del Proyecto

Photo DICOM (I) – Captura y almacenamiento de imagen médica fotográfica

RSNA 2017

Otro año más estamos en la RSNA, en Chicago, manteniendo contacto con clientes, proveedores y en busca de nuevos productos y tendencias del mercado para ofrecer a todos nuestros clientes.

Imagen de cómo están los pasillos del McCormick Place a estas horas:

En caso de que también asistáis al evento, me podéis localizar en el móvil. También consulto esporádicamente el E-Mail.

En estos días la diferencia horaria con España es de -7 Horas. Para cualquier cuestión contactar directamente con nuestras oficinas centrales de San Sebastián de los Reyes, en el teléfono 916531131 y correo: irerayosx@irerayosx.com

Acabando el año…

Este año no me he prodigado mucho en el blog, hace meses que lo tengo un poco abandonado.

Prometo, no obstante, retomar una actividad más frecuente en el 2017.

Aprovecho de igual forna para desearos una feliz entrada de año y un 2017 lleno de salud y éxitos profesionales.

¡Feliz 2017!

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

En las dos entradas anteriores nos hemos situado en el escenario (click aquí para ir) y hemos analizado las alternativas (click aquí para ir) en la gestión de la imagen no radiológica o NO-DICOM.

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.

Imagen médica

Imagen de Freedigitalphotos.net

 

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 este post: ¿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.

Abro el debate, ¿qué opináis vosotros?

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.

A %d blogueros les gusta esto: