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.

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

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.

Gráfico VNA

Fuente: http://www.carestream.com (Click aquí para acceder a la entrada correspondiente)

VNA – Vendor Neutral Archive

¿Entonces qué es un VNA? 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)?

En las siguientes entradas iré desgranando mi punto de vista sobre cuál es la mejor forma de gestionar este tipo de imagen y los motivos/argumentos que me llevan a posicionarme de tal forma. Aquí está la segunda entrada con el análisis de alternativas.

 

 

PhotoDICOM – Captura y almacenamiento de imagen fotográfica médica (III)

Recientemente os he venido hablando de Photo DICOM, una solución para la captura y almacenamiento de imagen fotográfica médica en un sistema PACS.

Aquí tenéis la primera y la segunda entrada al respecto.

PhotoDICOM

En esta ocasión os dejo el Brochure del producto que acabamos de sacar al mercado y que ya hemos presentado en algunos congresos con muy buena acogida.

Brochure IRE PhotoDICOM (PDF)

 

PhotoDICOM – Captura y almacenamiento de imagen fotográfica médica (II)

En esta anterior entrada: click aquí, hablaba sobre el proyecto PHOTO DICOM que da solución a los servicios que utilizan cámaras fotográficas para automatizar el proceso de conversión a formato DICOM y transmisión vía el protocolo del mismo nombre a sistemas PACS existentes en los Hospitales, independientemente del PACS disponible.

A continuación disponen de una pequeña presentación del proyecto:

 

Brochure” del producto aquí.

PhotoDICOM – Captura y almacenamiento de imagen fotográfica médica

La imagen médica se lleva digitalizando y almacenando en sistemas PACS desde hace más de dos décadas de forma generalizada en los países del primer mundo. Para poner de acuerdo a fabricantes e instituciones sanitarias se desarrolló el protocolo DICOM por la propia industria, que terminó de definirse en su versión 3.0 en 1993. Dicho protocolo posibilita la comunicación de imágenes generadoras de imagen, sistemas de almacenamiento PACS, clientes visores de imágenes y cualquier otro actor relacionado con la imagen médica.

El protocolo DICOM, lejos de ser óptimo en cuanto a su estructura, optimización de las transmisiones (es un protocolo “muy pesado” y poco ágil) y con importantes limitaciones, se adoptó como estándar de facto por la industria y especialmente por la industria radiológica.

A día de hoy prácticamente todos los Hospitales del mundo desarrollado disponen de uno o varios sistemas PACS donde almacenan las imágenes procedentes de las distintas modalidades diagnósticas a través del protocolo DICOM 3.0 en sistemas de almacenamiento seguros y replicados.

Así como dicho protocolo ha sido adquirido como estándar en el ámbito de la radiología, radioterapia, medicina nuclear y servicios afines, su adopción en otros ámbitos de la imagen médica no ha sido tan rápida ni tan generalizada.

Una vez solucionado el almacenaje y distribución de las imágenes de los servicios anteriormente citados, (y a su vez obtenido un retorno de rentabilidad al lograr hacer desaparecer la película radiográfica – de importante costo), los diferentes organismos sanitarios se están planteando reutilizar las infraestructuras ya existentes para dar una solución  similar al almacenaje (seguro) y distribución de la imagen no radiológica de los servicios generadores de imagen médica que no han adoptado (aún) DICOM como base de funcionamiento, como por ejemplo la imagen procedente de oftalmología, dermatología, cirugía plástica, las gráficas procedentes de los electrocardiógrafos, digitalización de las muestras de anatomía patológica, etc.

Parte de esos servicios utilizan máquinas específicas (como por ejemplo en anatomía patológica) que son las que deben implementar el protocolo DICOM para sumarse a los sistemas pre-existentes en los Hospitales. Otra serie de servicios generan imágenes médicas vía cámaras de fotos más o menos estándar y por tanto con formatos de imagen no médicos (jpeg y similar).

En la actualidad las imágenes obtenidas con cámaras fotográficas se están almacenando, de forma general, sin orden ni concierto en discos duros de computadoras locales a los servicios, sin ninguna seguridad (ante fallo por ejemplo de un disco duro), ni con posibilidad de distribuir dichas imágenes a otros servicios que pudiesen necesitar su consulta.

En el mejor de los casos, una vez descargadas las fotos desde la cámara a un PC, un usuario se dedica a la conversión de dichas imágenes a formato DICOM, casación de cada grupo de imágenes con el correspondiente paciente y finalmente envío al sistema PACS del Hospital, siendo éste un proceso lento y tedioso.

PhotoDICOM da solución a los servicios que utilizan cámaras fotográficas para automatizar el proceso de conversión a formato DICOM y transmisión vía el protocolo del mismo nombre.

Logo.png

Para ello se sugiere adoptar cámaras fotográficas con sistema operativo Android que permitan la instalación de aplicaciones que faciliten las anteriormente citadas tareas.

La solución es portable o como también se puede definir Vendor Neutral (no está ligada a un PACS concreto), siendo por tanto útil para cualquier centro sanitario que disponga de un sistema PACS, sea éste del proveedor que sea. Esto lo logramos gracias a la utilización del protocolo DICOM 3.0, estándar de facto de la industria de la imagen médica.

Su funcionamiento se basa en el uso de un dispositivo que funcione con sistema operativo Android que sea capaz de realizar fotografías. El dispositivo tipo ideal para su uso y comercialización son cámaras fotográficas con sistema operativo Android, como por ejemplo la Samsung Galaxy Camera 2, Nikon Coolpix S810c, Samsung Galaxy Camera NX, Polaroid SC1630, Polaroid iM1836, Panasonic DMC-CM1 o cualquier otra cámara que pueda aparecer en el mercado en el futuro cuyo sistema operativo sea Android, lo cual no prohíbe a cualquier otro dispositivo Android (smartphones, tablets, etc.) que dispongan de cámara de fotos integrada de utilizar esta aplicación para los mismos fines (con mayor o menor calidad de imagen según los sensores fotográficos de los que dispongan).

La aplicación que funciona sobre el dispositivo Android es cliente de lista de trabajo DICOM (Worklist DICOM) facilitando la identificación de los pacientes, evitando su introducción manual y adecuándose a los flujos de trabajo habituales ya establecidos en la mayoría de Hospitales.

La captura de las evidencias clínicas (fotografías) se realiza con el propio dispositivo y una vez finalizado el estudio o prestación médica se envían las imágenes (vía WiFi) al servidor para su conversión a formato DICOM y envío final al PACS correspondiente. De esta forma se cierra el flujo de trabajo. Si además añadimos que el correspondiente PACS cuente con mensajería HL7 y Wado, ya tenemos integrada la imagen en la correspondiente Historia Clínica Electrónica (HCE).

 Esquema Conexión PhotoDICOM

La solución por tanto se compone del dispositivo (con S.O. Android), la app ya mencionada y los servicios de servidor que facilitan las comunicaciones DICOM. (El servidor necesario es cualquier equipo con S.O. Windows y servidor Web Internet Information Services – IIS –).

Este producto ya está disponible para su comercialización. En próximas entradas hablaré más extensamente de PhotoDICOM y de las ventajas de uso en el ámbito hospitalario.

Si desea más información pueden contactar conmigo o a través de la empresa en la que trabajo, IRE Rayos X.

Disponen de una presentación del proyecto en esta segunda entrada al respecto.

Brochure” del producto aquí.

Gestión de Dosis Radiológica (II): Mapa de Incidencias en Radiología Intervencionista de RDM

Gráfico del Mapa de Incidencias

En esta anterior entrada hemos presentado el RDM (Radiation Dose Monitor), software de gestión dosimétrica para el seguimiento, análisis y optimización de la dosis suministrada al paciente al realizarle estudios radiológicos y exponerlo a radiación ionizante.

A continuación os voy a contar una de las funcionalidades más interesantes del RDM, el Mapa de Incidencias en Radiología Intervencionista:

Para los estudios de radiología intervencionista (XA y RF), (Radiation Dose Monitor) genera de forma automática un mapa de incidencias 2D que permite localizar las regiones (grupos de angulacion) que más radiación han recibido.

La identificación del punto caliente en Air Kerma es por lo tanto instantánea lo que permite tomar cualquier tipo de decisión sin ninguna demora (esto aumenta la calidad de las intervenciones médicas).
Gráfico del Mapa de Incidencias

El Mapa de Incidencias es parametrizable por:

  • Indicadores dosimétricos (Air Kerma y DAP)
  • Plano de adquisición (Frontal, Lateral, Ambos)
  • Intervalos de angulación (30º ó 40º)

Un juego de colores que va desde el blanco para las zonas con menos exposición al rojo oscuro para las zonas más sobre expuestas, permite distinguir rápidamente el reparto de la radiación así como el punto que más dosis ha recibido (punto caliente).

Un gráfico presenta igualmente los valores de Air Kerma y DAP acumulados en función del tiempo de la exposición.

También es posible ver en el tiempo como se ha realizado el estudio con una barra de desplazamiento.

 

Totalmente interactivo, haciendo clic sobre una región, es posible ver la siguiente información dosimétrica:

  • Air Kerma
  • DAP(Gy.cm²)
  • Mediana KVP(kV)
  • Distancia fuente-detector mediana
  • Número de secuencias

Esta información se calcula por tipo de secuencia: Grafía y/o Scopia.

Igualmente, la lista de secuencias por región o el punto caliente están accesibles con un simple clic sobre el mapa de incidencias.

Es posible exportar todos estos datos en formato Excel formateado, tanto el punto caliente como la región que se desee, para realizar un cálculo rápido y eficiente de la dosis a la piel.

 

Gráfico Mapa de Incidencias II

 

RDM (Radiation Dose Monitor) es un producto de Medsquare SAS (París, Francia), y distribuido en España por IRE Rayos X, S.A.
A %d blogueros les gusta esto: