sábado, diciembre 30, 2006

JPIP: JPEG 2000 Interactive Protocol


En este artículo vamos a intentar adentrarnos ligeramente en el estándar de imágenes JPEG2000 y más específicamente en su Parte 9. Esta parte habla de la arquitectura JPIP (JPEG 2000 Interactive Protocol) que provee de una potencia asombrosa al tratamiento y transmisión de imágenes por las redes.

Su aplicación en el ámbito de la transmisión de imágenes médicas es muy grande puesto que cada vez se utiliza más el envío de imágenes por internet a destinos remotos sin la necesidad de que las imágenes sean DICOM.


Panorama Actual
Actualmente, un sistema PACS se puede parecer bastante, en filosofía, al de esquema:














Tenemos un sistema PACS que recibe las imágenes DICOM, que las sirve a los visores diagnósticos y que las envía a su caché web para que se compriman y se sirvan a los usuarios externos que las piden vía HTTP. Las imágenes se comprimen con una determinada calidad y se almacena un puntero a dicha imagen. En estos sistemas, tenemos bastantes copias de una sola imagen, dependiendo de la calidad y de la zona de interés que se haya extraído.

Por otro lado, el envío de las imágenes se realiza de una vez, hasta que no se recibe todo el stream de imagen no se pinta en la pantalla. Dado que las imágenes médicas son cada vez más pesadas y se demanda una mayor calidad (y un control de la calidad) en las imágenes enviadas por internet, el panorama se vuelve cada vez más complicado. A su vez, el informado de imágenes de forma remota y externa a los centros productores es cada vez más común en muchos lugares del mundo, por lo que el tráfico de imágenes será cada vez mayor.

Con esta perspectiva, vamos a ver qué nos ofrece JPIP.


¿Qué nos ofrece JPIP?
Con JPIP podemos implementar sistemas de transmisión de imágenes mucho más eficientes y orientados a la transmisión gradual. JPIP se basa en una arquitectura de servidor que recibe las peticiones de los clientes de diferentes maneras. Lo que más nos interesa en este artículo, es que puede recibir las peticiones y encapsular los mensajes en HTTP. Las ventajas más significativas que nos ofrece JPIP son:

  • Envío progresivo de datos autocontenidos de la imagen que se pueden mostrar mientras se reciben el resto. Esto permite el envío de imágenes de mucho peso de forma progresiva.
  • Acceso por parte del cliente a metadatos de la imagen, permitiendo personalizar dinámicamente lo que se quiere obtener y cómo se quiere obtener (roi, calidad, sesión, canal, tipo de envío, etc.)
  • Estandarización en la arquitectura y las peticiones, permitiendo crear servidores y/o clientes independientes del fabricante.
  • Posibilidad de eliminación de copias de la imagen, puesto que las imágenes comprimidas, las miniaturas, las ROI, se generan dinámicamente en base a la petición recibida por el cliente.

¿Cómo funciona JPIP?
JPIP utiliza dos modos de streaming: JPT-stream y JPP-stream. En los dos modos, la imagen JPEG2000 del servidor es particionada en elementos pequeños llamados "databins". Una imagen JPEG2000 puede ser completamente dividida en "databins" y luego reconstruida en el cliente. Cada "databin" se identifica de manera unívoca y tiene un lugar específico en la imagen.

El cliente JPIP recibe "databins" parciales o completos en respesta a peticiones al servidor JPIP. El decodificador JPEG2000 reconstruirá cada "databin" y se podrá pintar en la interfaz de usuario en su ubicación asignada, mientras se reciben datos del servidor.

El esquema siguiente muestra una arquitectura básica de servidor y cliente JPIP:











Las peticiones llegan al servidor, que busca las imágenes, las procesa según los parámetros recibidos por el usuario y va enviando la información al cliente. El cliente guardará la imagen en su caché local (en caso que la tenga), decodificará la información enviada por el servidor y la mostrará de manera conveniente al usuario.

Parámetros del Cliente:
Una de las características más potentes de JPIP, es la capacidad de enviar en las peticiones GET o POST, parámetros que el servidor intermedio JPIP procesa. Estos parámetros se dividen en 9 grupos:

  • Campos de identificación del objetivo: donde elegimos la imagen o imágenes que queremos pedir al servidor.
  • Campos de manejo de la sesión y el canal: donde definimos cómo va a ser la transmisión, el protocolo, las características de la sesión y los canales. También podremos enviar mensajes de cierre de canal.
  • Campos de petición de la ventana de imagen: Acceso a una porción de la imagen JPEG2000, en base a la cuadrícula. Se le pasarán parámetros como size, offset,... que determinen con exactitud la parte de la imagen a la que queremos acceder. En este grupo también se definirá la velocidad de transmisión de los datos, las capas que se desean visualizar, las ROIs (acceso por nombre a una zona), etc.
  • Campos de metadatos: acceso a metadatos definidos para la imagen.
  • Campos de limitación de datos: en este grupo se especificarán cuantos datos se desean recibir del servidor para la petición especificando dos parámetros: calidad y el tamaño máximo de respuesta.
  • Campos de control del servidor: se detallarán parámetros del tipo de imagen a recibir (JPP, JPT o raw), si el servidor debe esperar a terminar un mensaje para enviar otro, ...
  • Campos de manejo de la caché: parámetros relacionados con el manejo del cache-model del servidor dependiendo del modo en que gestiona el estado de las sesiones.
  • Campos de Upload de imágenes: cuando un cliente realiza un upload de una imagen o metadato, utilizará estos campos, especificando el tipo de envío.
  • Campos de capacidades del cliente y preferencias: Se especificarán en estos campos las capacidades funcionales del cliente y las preferencias a la hora de la recepción de la información.
Conclusión
El potencial que nos ofrece JPIP para el manejo y transmisión de imágenes por internet es muy grande. En este artículo hemos visto un pequeño esbozo de lo que podemos llegar a conseguir, pero las posibilidades son grandísimas. El lado negativo es que aumenta la complejidad de nuestros sistemas y la forma de desarrollarlos, pero el premio, creo que merece la pena.

Algunos enlaces relacionados con JPIP y de los que he sacado la información son:

Página Oficial de JPEG: JPEG2000 Parte 9
Documento Oficial de JPIP: JPIP: Interactivity Tools, APIs and Protocols.
Servidor JPIP de Demo de Pegasus Imaging Corporation: Demo

Espero que os haya gustado el artículo sobre JPIP ya que el tema es muy interesante y, como he dicho, abre un mundo de posibilidades en la transmisión de imágenes médicas (y no médicas) por internet.

jueves, diciembre 21, 2006

La seguridad en el estándar DICOM


Una de las partes menos implementadas y conocidas dentro del estándar DICOM es el tema de la seguridad. Sin embargo, la parte 15 del estándar está dedicada al completo a este aspecto. En este artículo intentaremos dar una primera visión de los aspectos de seguridad que se pueden implementar y que hay que tener en cuenta en nuestro sistema de imagen digital.

Introducción
En España tenemos la Ley Orgánica 15/1999 como garante legal y obligación en el tema de la protección de datos en el ámbito de la salud. En dicha ley se obliga a proteger los datos personales y evitar que se obtengan de forma ilícita. Esto obliga a implementar sistemas de seguridad, auditorías de accesos y encriptación de los datos y comunicaciones. No podemos permitir que un usuario malintencionado tenga acceso a la información personal de un paciente y en caso que pueda ganar acceso a nuestros sistemas, garantizar que la información que obtenga no tenga datos personales que puedan identificar al paciente.

Las imágenes DICOM tienen la peculiaridad de que son objetos autocontenidos, es decir, que incluyen en su cabecera toda la información del paciente, por lo que si un usuario malintencionado consigue obtener una imagen, tendrá toda la información del paciente junto con su imagen. Otro de los aspectos importantes es que, inicialmente, el estándar DICOM no se pensó en términos de seguridad.

Con estas premisas, pasamos a ver cuáles son los aspectos de seguridad que podemos implementar en nuestro sistema de imagen digital.

Perfiles de Seguridad
La parte 15 del estándar define 8 perfiles de seguridad sobre los que se puede actuar. No es necesario implementarlos todos, se pueden acometer por separado:

  • Perfiles de Uso: Trata sobre el uso de atributos y temas de seguridad en el uso de maneras específicas.
  • Perfiles de Conexiones: en este apartado, se trata cómo se negocian las comunicaciones, los mecanismos de autentificación de entidades, la encriptación del canal y el chequeo de la integridad.
  • Perfiles de Firma Digital: cómo incluir firma digital en el dataset de las imágenes y el propósito de la misma.
  • Perfiles de Seguridad en el Almacenamiento: indica cómo se encapsularán y protegerán las imágenes en el almacenamiento.
  • Perfiles de Confidencialidad en los Atributos: indica cómo encriptar los datos de la cabecera las imágenes.
  • Perfiles de Manejo de Direccionamiento: explica cómo manejar situaciones con servidores DHCP y DNS.
  • Perfiles de Sincronización de Tiempos: explica cómo manejar situaciones con el protocolo NTP para la sincronización de tiempos.
  • Perfiles de Administración de Configuración de Aplicaciones: explica cómo se debe guardar la información en un servidor LDAP, qué campos y con qué formato.
En este artículo no tenemos espacio para tratarlos todos, así que trataremos solamente el perfil de confidencialidad de atributos. Muchos de estos perfiles son complicados de usar porque precisan que ambas partes (cliente y servidor) lo utilicen. Sin embargo, algunos de ellos se pueden abordar unilateralmente dando más seguridad a nuestro sistema. Este es el caso de la encriptación de datos de cabecera.

Perfil de Confidencialidad en los Atributos
El objetivo de este perfil es que si un hacker o usuario malintencionado obtiene acceso a nuestro repositorio de imágenes, no sea capaz de identificar los datos del paciente que se encuentran en la cabecera. Aunque tenga acceso a la imagen radiológica, no compromete la privacidad del paciente.

La situación ideal sería esta:














La imagen es generada y encriptada en la modalidad. El envío hacia el PACS se realiza con la imagen encriptada, el cual la desencripta para leer la información y la vuelve a encriptar para guardarla en el almacenamiento. Cuando un visor pide la imagen, ésta es enviada de forma encriptada y se desencripta en el cliente.

Para poder llevar a cabo esta situación, es imprescindible que todos los elementos involucrados sean capaces de encriptar/desencriptar la información de cabecera, algo prácticamente imposible hoy en día. Sin embargo, se puede ir hacia un modelo alternativo en el que nuestro sistema encripte la información que le llega y la desencripte cuando se la pidan. Las imágenes permanecen seguras en el almacenamiento aunque no en las comunicaciones. Obtenemos una seguridad parcial pero no dependemos de terceros para implementarlo:














En este caso, un atacante podría interceptar las imágenes, pero en el almacenamiento estarían seguras.

Datos Encriptados
Los datos de cabecera encriptados se quitarán del dataset o se reemplazarán por un valor distinto y se encriptarán en el atributo (0400,0550). Los atributos a encriptar proporcionados por el estándar son los siguientes, aunque es responsabilidad del fabricante encriptar más si contienen información sensible:























Conformance Statement
El Conformance Statement para este perfil de seguridad requiere que se detallen los siguientes aspectos:

  • Qué atributos son quitados durante la protección
  • Qué atributos han sido reemplazados por valores "dummy" y cómo estos valores son generados.
  • Qué atributos se incluyen en la parte encriptada y cómo son seleccionadas las claves para su codificación.
  • Si la aplicación es capaz de asegurar la integridad de los datos "dummy".
  • Qué atributos y valores de atributos son insertados durante la protección de un SOP Instance.
  • Qué Transfer Syntax son soportados para la encriptación/desencriptación de datos.
  • Qué esquemas de confidenciales son soportados
  • Cualquier restricción adicional.

Conclusión
La seguridad es algo muy importante y muy olvidado dentro del mundo de la imagen digital, muchas veces por desconocimiento. Sin embargo, el estándar contempla todos estos aspectos y da soluciones para crear sistemas seguros y que cumplan con la ley. Muchas veces dependemos de terceros para crear entornos seguros, pero hay partes que se pueden aplicar unilateralmente como ésta que hemos visto en este artículo.

Como siempre, espero que os haya gustado este artículo y en siguientes intentaré tratar otros perfiles de seguridad del estándar DICOM.

viernes, diciembre 15, 2006

El Almacenamiento Offline

En artículos anteriores introdujimos el concepto del ciclo de vida de las imágenes, explicando los estados por los que pasa una imagen desde que llega al sistema hasta que es almacenada en su última ubicación. Seguidamente vimos formas de plantear el almacenamiento de las imágenes en ubicaciones de disco mientras eran demandadas por los usuarios. Ahora vamos a abordar la problemática de plantear el sistema de almacenamiento offline de las imágenes. Recomendamos leer primero los otros dos artículos antes de empezar con este:


Introducción
A la hora de plantear el sistema de copia de seguridad de un sistema PACS tenemos que pensar en varios aspectos que definirán nuestro modelo. Las alternativas variarán en función de la complejidad que queramos introducir y la capacidad de recuperación del mismo:

  • Conectado/Desconectado: tendremos que decidir si el sistema de copia de seguridad notifica al PACS cuando realiza la copia de las imágenes. En los sistemas conectados, el dispositivo de backup estará en comunicación con el PACS, sabiendo éste último qué imágenes se han grabado y cuáles no. De esta manera, se podrá controlar el estado de las imágenes y si se pueden borrar de otras ubicaciones o no. En los sistemas desconectados, no existirá esta comunicación, siendo responsabilidad del sistema de backup la realización de las copias de seguridad y el PACS no tendrá conocimiento del estado de las imágenes.

  • Recuperación Automática: Un aspecto muy importante del almacenamiento offline, es la capacidad de poder recuperar las imágenes. No sirve para mucho unas copias de seguridad de las que no podamos recuperar las imágenes. En sistemas PACS grandes, el tamaño de imágenes a salvaguardar es muy grande (Terabytes), por lo que es importante implementar una estrategia de recuperación. Imagínense un sistema de cintas, con 300 cintas grabadas y un usuario que demanda una imagen de hace 6 años. Si no tenemos un sistema de recuperación, será imposible recuperar la imagen y será como si la hubiésemos perdido. Se suelen implementar catalogadores de contenido que relacionen la imagen con el dispositivo donde se haya grabado para poder recuperarla. Una vez que se haya implementado el catalogador, el sistema de almacenamiento debe ser capaz de comunicarse con el dispositivo de copia de seguridad para que recupere automáticamente la imagen sin necesidad de que un administrador tenga que intervenir.

  • Abstracción del Medio: Un sistema de almacenamiento offline ocultará el dispositivo físico que se encarga realmente de hacer la copia, mostrando al sistema de almacenamiento del PACS un volumen más. Al abstraer el medio, el sistema offline se convierte en una ubicación más, con características especiales, pero una ubicación donde almacenar y recuperar. El sistema offline se encargará de traducir las peticiones que le hagan al lenguaje (normalmente SCSI) que entienda el dispositivo físico. Una funcionalidad muy potente es la de implementar varios traductores de comandos para diferentes dispositivos (librerias de cintas, robots de DVDs, etc) de forma que se le ofrezca al cliente la posibilidad de almacenar sus imágenes en el dispositivo con el que se sienta más cómodo.

Flujo de Información
Una vez que hayamos decidido la complejidad de nuestro sistema de almacenamiento offline, pasaremos a implementarlo teniendo claro cuál es el flujo de información. En los siguiente esquemas se muestran los diferentes flujos de información para un sistema conectado, con catalogación, recuperación automática y múltiples traductores de comandos.

Copia de una imagen



















Recuperación de una imagen


















Lógicamente, existirá un momento en que el elemento donde se haya grabado la imagen no se encuentre dentro del dispositivo (por su antigüedad), por lo que, en ciertas ocasiones, será necesaria la mano humana.

Con este artículo, se cierra la serie del ciclo de vida de las imágenes DICOM a nivel de almacenamientos. Hemos visto tanto los almacenamientos a corto, medio, largo plazo y offline.

Como siempre, espero que os haya gustado y que os sirva esta información.

jueves, diciembre 07, 2006

Almacenamientos de Imágenes


En el último artículo se abordó la temática del ciclo de vida de las imágenes DICOM. En dicho artículo nos acercamos bastante a los almacenamientos puesto que eran parte fundamental del ciclo de vida de las imágenes. Ahora vamos a ver cuáles son las claves para plantear un almacenamiento de imágenes médicas que sea robusto y esté preparado para el crecimiento futuro.

A la hora de plantear un sistema de almacenamiento tenemos que conocer cómo funciona el hardware sobre el que residirá. No es viable intentar montar una gestión de almacenamiento conociendo solamente como funciona el disco del PC de nuestra casa. Una vez que sepamos las características del hardware, tendremos que tener en cuenta los siguientes puntos:

  • Con el tiempo, la cantidad de información almacenada en nuestro sistema crecerá y sobrepasará con creces el terabyte de información.
  • El número de imágenes almacenadas será, con el tiempo, de millones.
  • El tamaño de las imágenes crece con el tiempo, siendo actualmente, la media de varios megabytes y estando la mamografía digital en decenas de megabytes.
  • La velocidad de recuperación es un factor importante.
  • El rendimiento no puede caer.
En base a estos puntos tendremos que desarrollar nuestro sistema de almacenamiento de imágenes. Iremos yendo punto por punto analizando las diferentes problemáticas que nos podemos encontrar y posibles soluciones.

Punto 1: Capacidad de Almacenamiento
La capacidad y cantidad de almacenamiento es el punto más importante ya que una mala arquitectura en este punto puede hacer que nuestro sistema se pare. Si hemos gestionado mal este punto, es posible que el sistema llegue un momento en que no sea capaz de gestionar los volúmenes de almacenamiento. Aquí es donde tendremos que conocer el hardware sobre el que vamos a trabajar, las cabinas de almacenamiento empresariales. Existen muchos tipos de cabinas, diferenciadas básicamente en el número de controladoras, el tipo de discos con el que trabajan, la velocidad de transferencia y la capacidad de gestión de tamaño. Lo que tenemos que tener claro son las limitaciones en tamaño y el funcionamiento de los RAIDs de discos.

Tradicionalmente, cuando se gestionaba una cabina de discos, el administrador introducía los discos pertinentes e iba configurando los RAIDs a los discos de la manera: disco1 y disco2 en RAID1, disco3, disco4 y disco5 en RAID5 y así sucesivamente. Los discos tenían que ser del mismo tamaño para que los RAIDs funcionasen. Actualmente, la configuración de la redundancia entre discos se ha virtualizado, de forma que un administrador no tiene que decir sobre qué discos físicos monta un RAID sino que la controladora de la cabina realiza lo que se llama "Leveling" y pone los datos sobre todos los discos, gestionando ella los RAIDs. En el siguiente esquema se ve con mayor claridad este concepto:
























En la virtualización de discos, la controladora interpone una capa que oculta los discos físicos al administrador y le ofrece el tamaño de que dispone. La controladora almacenará los datos donde estime oportuno. Esto permite unas configuraciones mucho más flexibles de los volúmenes de discos a mostrar a los servidores.

Las cabinas, actualmente, limitan el tamaño máximo de los volúmenes a 2 Terabytes. Esto, en un principio puede parecer un tamaño grandísimo, pero en un sistema de almacenamiento dicom, se queda en muy poco. En los servidores se pueden realizar configuraciones de discos dinámicos, pero en determinadas configuraciones de clusteres, los discos dinámicos no son aceptados. Entonces, ¿qué pasa si el volumen donde guardamos las imágenes se llena?, nuestro sistema tendrá que tener previsto esto e implementará alguna estrategia de conmutación. Existen diferentes modelos para implementar esto:

  • Conmutación manual: Es la más obvia y mucha gente no realiza nada en este aspecto. El administrador se encarga de cambiar los parámetros de la aplicación cuando llega el momento.
  • Conmutación simple: nuestra aplicación es capaz de detectar cuando un volumen está lleno y cambia al siguiente que tenga configurado.
  • Abstracción de volúmenes: esta es la más compleja ocultando los volúmenes al resto del sistema y mostrando una sola ubicación lógica. Internamente gestionará mediante conmutación simple los cambios, detectará fallos de escritura y cambiará, etc.

























De esta manera, gestionaremos el espacio en disco e iremos creciendo en volúmenes cuanto como queramos. Nuestro sistema tendrá que proveer de herramientas para incrementar el número de volumenes que se acogen bajo los presentados a la aplicación, o la creación de nuevos grupos de volúmenes, etc.

Punto 2: Número de imágenes
Este es también un factor importante, cada día que vaya pasando el número de ficheros y de registros en base de datos irá creciendo y no disminuirá. Con el tiempo tendremos millones de imágenes. Esto obliga a dos cosas:

  • Una buena estructura e indexación de base de datos que permita realizar búsquedas cómodamente, sin tumbar el servidor.
  • Una buena estructura de almacenar los ficheros dicom en disco.
La estructura de tablas que define DICOM es buena (Paciente --> Estudio --> Serie --> Imagen), estando en la tabla imagen un puntero al fichero de imágenes. Dependiendo de como hagamos las búsquedas indexaremos unos campos u otros. Lo normal es que las búsquedas se realicen sobre PatientID, PatientName, Modality, StudyDate. Una vez seleccionado el estudio a visualizar, la recuperación se suele hacer por lo UID de los respectivos niveles definidos por DICOM. Por lo tanto, se indexarán estos campos para obtener un rendimiento mejor. Durante el tiempo, los DBA deberán obtener estadísticas para actualizar los índices en caso que hiciese falta.

Con respecto al almacenamiento en disco, es importante que se subdivida y catalogue en diferentes subcarpetas para no tener millones de ficheros dentro de una carpeta. Como en todo, existen diferentes sistemas y estrategias a seguir en este punto:

  • Almacenar por los UIDs de la imagen, creando una estructura del tipo PatientID / StudyUID / SeriesUID / y dentro de éste las imágenes, nombradas como ImageUID.dcm.
  • Crear una estructura por fecha de estudio, teniendo directorios del tipo año / mes / día y dentro las imágenes
  • Crear su propio sistema de almacenamiento.
Personalmente, el que prefiero es el primero, aunque cada uno puede implementar el que más le interese. Una vez decidido nuestra estrategia de almacenamiento en disco, pasamos al tercer punto a tener en cuenta.

Punto 3: Tamaño de las imágenes
¿Por qué es importante este aspecto? No es por el almacenamiento, que ya hemos resuelto, sino por los lenguajes de programación y la memoria de los servidores. Un sistema de almacenamiento tendrá una actividad grande de entrada y salida de imágenes y cuanto más sea utilizado mayor. La actividad se traduce en movimiento de imágenes, montaje en memoria de las mismas y copia en archivo. Esto con múltiples hilos de ejecución a la vez. Lo que significa es que el servidor necesitará una cantidad de memoria grande, pero lo más importante es que necesitaremos un lenguaje de programación que sea capaz de gestionar esa memoria. Los lenguajes de programación, cuanto de más bajo nivel sean, mejor gestionarán este aspecto. Java o C# pueden tener complicaciones al poner muchas capas de abstracción, máquinas virtuales, servidores de aplicación, elementos que consumen recursos. C o C++ serán mucho más ágiles aunque tendremos el problema de que cuanto más bajamos más nos atamos a la plataforma. Estará en manos del responsable del desarrollo el sopesar los pros y contras de cada lenguaje y tomar un camino.

Punto 4: La velocidad
En todos los sistemas de almacenamiento dicom, la velocidad es un factor muy importante y suele ser uno de los baremos por los que se miden. Si nuestra arquitectura es buena, nuestra política de almacenamiento es buena, tenemos bien indexada la base de datos y el lenguaje de programación responde velozmente, entonces no tendremos problemas con este aspecto. Si tenemos problemas con la velocidad tendremos que revisar los puntos anteriores y si no es el caso, veamos el punto siguiente.

Punto 5: El rendimiento
Los sistemas de almacenamiento suelen ir creciendo en usuarios y la demanda se incrementa con el tiempo. Sin embargo, el rendimiento no puede decaer, por lo que tenemos que tener esto en cuenta al diseñar nuestra arquitectura. Existen varios tipos de arquitectura que se pueden aplicar a la hora de diseñar un sistema de almacenamiento de imágenes dicom:

  • Sistema en cluster: diseñamos nuestro sistema para que se pueda clusterizar, haciendo que el sistema operativo controle su operatividad. En estos entornos, nuestra solución será activa - pasiva. Esto realmente no incrementa nuestro rendimiento, sino nuestra disponibilidad. Sin embardo, si programamos de manera que podamos distribuir en el cluster nuestro sistema en módulos separados, podremos realizar un balanceo manual de las funcionalidades.
  • Sistema balanceado: esta es la mejor opción porque podemos tener nuestro sistema corriendo de manera simultánea en varios servidores de manera activa-activa, multiplicando el rendimiento por el número de servidores. Es más complejo puesto que tenemos que lo tenemos que tener en cuenta a la hora de programar.
  • Sistema simple: no implementamos ninguna estrategia y le ponemos más recursos a los servidores.
















Con esto tendremos nuestro sistema de almacenamiento en disco completo. Como siempre, espero que os gusten los artículos. En próximas entregas profundizaremos en el backup de las imágenes, que al fin y al cabo es otro sistema de almacenamiento.

lunes, diciembre 04, 2006

El Ciclo de Vida de las Imágenes DICOM

En este artículo vamos a tratar uno de los aspectos más importantes dentro del mundo de la imagen digital: el ciclo de vida de las imágenes o los estados por los que pasa una imagen. La definición de este ciclo de vida determinará la configuración de nuestro sistema de almacenamiento de imágenes y la distribución de los volúmenes de información. Una mala elección o poca previsión a la hora de estudiar este aspecto puede llevar a un mal PACS o a un PACS poco escalable y adaptable a las necesidades (un mal PACS). Este tema es uno de los más abstractos y filosóficos del mundo de la imagen digital y no se le suele prestar demasiada atención. Esta es la razón por la que muchas soluciones de almacenamiento de imágenes médicas fracasan en determinadas circunstancias (por supuesto, existan otras causas).

¿Por qué es importante estudiar el ciclo de vida de las imágenes? Precisamente por lo que hemos comentado. A la hora de diseñar un sistema de almacenamiento de las imágenes, la adaptabilidad y escalabilidad de las soluciones es fundamental. No podemos realizar soluciones que respondan perfectamente a un cliente o a una arquitectura específica pero que luego no se puedan llevar a otros sitios. Cada cliente tendrá unas necesidades de tiempos de almacenamiento, criterios de almacenamiento, procesos de recuperación offline, envíos remotos distintos, por lo tanto, nuestra solución debe ser perfectamente adaptable en este sentido.

Estados de una Imagen
Típicamente, el ciclo de vida de una imagen se compone de las siguientes fases:
























1. La imagen entra en el sistema enviada por una modalidad y pasa al almacenamiento "Corto Plazo". Este puede ser una serie de volúmenes, discos, ubicaciones varias donde se alojan aquellas imágenes que más van a ser demandadas por los usuarios. En este estado, las imágenes se suelen enviar a aquellas ubicaciones remotas que precisen de autorouting o prefetching.

2. Según las políticas tomadas (tiempo de caducidad de las imágenes, espacio en los volúmenes, prioridad de estudios y/o zonas de exposición, médicos solicitantes, etc.) las imágenes se llevan al almacenamiento "Medio Plazo" y se eliminan del "Corto Plazo", dejando espacio a las nuevas imágenes. En este almacenamiento, la demanda por parte de los usuarios es mucho menor y la capacidad del mismo es mayor. En el momento en que un usuario demande una imagen de este almacenamiento, se moverá al "Corto Plazo" de nuevo.

3. Según las políticas establecidas para el almacenamiento "Medio Plazo", las imágenes se moverán al "Largo Plazo" y se quitarán del "Medio Plazo". En este almacenamiento suelen estar años y son almacenamientos muy fiables donde prima la seguridad sobre la velocidad.

4. Finalmente, las imágenes son llevadas a dispositivos de almacenamiento offline (librerías de cintas, librerías de DVDs, etc) donde permanecerán mínimo los 10 años que prescribe la ley en España.

Hay ciertas consideraciones a tener en cuenta en este ciclo de vida:

1. En cualquier momento, las imágenes pueden volver al "Corto Plazo" pero con políticas diferentes. Una típica política es mantener las imágenes recuperadas x días en el corto plazo y luego eliminarlas.

2. Cuando una imagen llega, se suelen realizar las copias a los diferentes almacenamientos en ese momento, por lo que luego sólo hay que eliminarlas. Esto permite tener varias copias de la misma imagen en diferentes ubicaciones dando seguridad a la solución.

3. Los diferentes almacenamientos suelen estar en ubicaciones físicas distantes entre sí, siendo muy típica la configuración jerárquica de almacenamientos, estando el corto en una ubicación, el medio en otra, y el largo y el offline en otra.

El esquema de los almacenamientos sería el siguiente:



















En el esquema, la gestión de las imágenes se realiza en un entorno jerárquico. Las imágenes nunca se eliminan del almacenamiento offline y nunca se elimina una imagen sin tener la seguridad de que existen más copias en otra ubicación. Los motores de decisión se encargarán de gestionar la vida de las imágenes, eliminándolas cuando corresponda, enviándolas a las ubicaciones requeridas y gestionando sus parámetros.

Aunque en este artículo hemos hablado de almacenamientos Corto, Medio, Largo y Offline, se ha hecho por mantener la nomenclatura tradicional. Las ubicaciones o almacenamientos en los que se guarden las imágenes deben poder ser configurables en el PACS, pudiendo ser cuantos quiera el cliente. Por lo tanto las políticas deben también ser configurables y permitir un control completo sobre el ciclo de vida de la imagen.

Lo importante de este artículo es remarcar que los sistemas tradicionales basados en funcionalidades rígidas no sirven en el mercado actual, siendo necesario un control completo de los estados por los que pasa la imagen y para cambiarlo en cualquier momento.

Espero que esta serie de artículos os sigan gustando y siendo útiles.