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.

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.

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:

• El Ciclo de Vida de las Imágenes
• Almacenamientos de Imágenes

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.

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.

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.

Diseño de una Worklist Dicom

En esta entrada vamos a ahondar en uno de los elementos más importantes dentro de la arquitectura de los sistemas PACS, la Lista de Trabajo. Su función principal es la de unir el sistema de información radiológico con el sistema de almacenamiento de imágenes, posibilitando la correcta asociación entre paciente e imagen.

Los apartados que trataremos son:

• Visión Global de la Funcionalidad
• Utilidad de la WorkList
• Posibles Arquitectura de la Lista de Trabajo
• La Mensajería MPPS y la Lista de Trabajo
  

Visión Global de la Funcionalidad
Como hemos comentado, la función principal de la Lista de Trabajo es conseguir que las imágenes generadas en las modalidades se asocien de forma correcta al paciente del que son. Desde el punto de vista de los técnicos de rayos, la lista de trabajo permite que en las consolas de sus modalidades aparezcan aquellos pacientes citados para el día de forma que ellos los puedan seleccionar y hacerles el estudio correspondientes. Desde el punto de vista informático, el proceso es ligeramente más complejo. En el siguiente diagrama vemos cuál es el flujo básico de la información:













El proceso completo es el siguiente:

1. El paciente es citado en la aplicación RIS.
2. A cada uno de los estudios que se le vayan a realizar al paciente se le asigna un número único llamado "Accession Number". Éste será el dato que conseguirá el enlace entre el RIS y el PACS.
3. Las citas generadas, ya sea en el momento o con algún proceso programado, se envían utilizando mensajería HL7 a la Lista de Trabajo.
4. Al recibir las citas, la lista de trabajo almacenará esa información en su estructura de datos para su posterior consulta. Los datos normales a recibir en un mensaje de cita son:

• Accession Number
  
• Nombre del Paciente
  
• Prueba a realizar
• Sala donde se realizará
• Fecha del estudio
• Hora del estudio
• NHC (Número de Historia Clínica)
• Unidad Peticionaria
• Médico Solicitante

5. Cuando el técnico de rayos quiera la información de los pacientes que tiene citados para el día, realizará una petición FIND de Worklist.
6. La Lista de Trabajo devolverá aquellos datos correspondientes a la máquina que realizó la petición. Al realizar la petición, la modalidad dice quién es o para quién pregunta los pacientes. La Lista de Trabajo debe ser capaz de asociar salas con modalidades para enviar la información correcta.
7. Cuando se le realiza el estudio al paciente, en la cabecera de las imágenes viaja el "Accession Number" que le asignó el RIS. Estas imágenes se envían al PACS que almacena esa información.

Finalmente, hemos conseguido que el PACS tenga almacenado para cada estudio su Accession Number.


Utilidad de la WorkList
Una vez que tenemos implementado un entorno de Lista de Trabajo, obtenemos varias ventajas evidentes y varios inconvenientes asociados. Las ventajas son:

1. Al no tener que introducir manualmente los datos de los pacientes en las consolas de las modalidades, se evitan muchos fallos en la información. La información llega directamente del sistema RIS, que vendrá del HIS o de algún sistema corporativo.
2. Desde el RIS podremos tener acceso a las imágenes de cada paciente mediante la integración con algún visor dicom. Al tener el Accession Number, se pueden realizar consultas dicom directamente al PACS. Esto permite que el RIS se convierta en fachada del PACS, otorgándole inteligencia.

En cuanto a los inconvenientes:

1. Se introduce un elemento más dentro del servicio de rayos que modifica el flujo de trabajo normal del personal. Esto obliga a variar el comportamiento habitual.
2. En los pacientes de urgencias, el uso de la Lista de Trabajo suele ser complicado puesto que al tener que generar una cita en el RIS, que se envíe vía HL7 a la Worklist y llegue a la modalidad, el tiempo que se pierde es grande. Existen configuraciones que veremos más adelante que permiten paliar este tiempo.

En este esquema mostramos el flujo normal para la petición de imágenes desde el RIS al PACS.


Consideraciones de Funcionalidad de la Lista de Trabajo
A la hora de implementar una Lista de Trabajo hemos de tener en cuenta los siguientes aspectos y prepararnos para que nuestro sistema pueda responder ante ellos:

1. La lista de trabajo debe estar preparada para recibir mensajes de creación, modificación y eliminación de citas.
2. El formato de los mensajes HL7 puede variar de un RIS a otro, por lo que el sistema debe estar preparado para ser configurable en este aspecto.
3. El RIS no debe saber nada de DICOM y las modalidades nada de Salas. Esta labor de unión la debe hacer la Lista de Trabajo. En este aspecto, debe ser totalmente configurable, sabiendo qué modalidad lleva las citas de qué salas.
4. Hay momentos en los que una modalidad se rompe por algún motivo. En estos casos, la lista de trabajo debe ser capaz de mover fácilmente las citas de esa modalidad a otra modalidad.
5. La lista de trabajo debe tener un administrador visual que permita al administrador configurar todos estos aspectos, realizar consultas o cualquier otro tipo de acción.

Estas son unas cuantas consideraciones, sin embargo, a la hora de implementar una lista de trabajo se deberá realizar un estudio mucho más profundo de las funcionalidades.


Posibles Arquitecturas de Lista de Trabajo:
Existen varias formas posibles de implementar una Lista de Trabajo, cada cual con sus seguidores y detractores. No hay ninguna mejor que otra, cada una tiene unas características diferentes:

1. Lista de Trabajo independiente: se puede implementar como un módulo completamente independiente del RIS y del PACS. De esta manera, la portabilidad y la adaptabilidad es mayor que en las otras soluciones. Sin embargo, hay que implementar mayor cantidad de servicios para obtener los mismos resultados que en los otros (MPPS).
   
2. Lista de Trabajo dentro del RIS: de esta manera nos evitamos la utilización de mensajería HL7 que es siempre muy engorrosa, lenta y poco fiable muchas veces. Las citas se mandan directamente en datasets dicom a las modalidades. Tendremos que implementar MPPS para sabert cuando se han realizado las pruebas. No es reutilizable con otros RIS.
   
3. Lista de Trabajo dentro del PACS: tenemos el problema de la mensajería HL7 pero, al estar dentro del PACS, sabemos cuando se han realizado las pruebas porque recibimos las imágenes.

La Mensajería MPPS y la Lista de Trabajo:
Uno de los grandes problemas de las Listas de Trabajo es que no son capaces de saber cuando se han realizado los estudios y siempre mandan las mismas citas a las modalidades. Para evitar esta situación, el estándar DICOM provee de la mensajería MPPS (Modality Performed Procedure Step) cuya misión es ir informando a una entidad dicom del estado del estudio en curso.

Cuando se le inicia un estudio a un paciente, la modalidad empieza a enviar mensajería a la Lista de Trabajo notificándole de este hecho. Irá enviando información del estado del estudio y cuando lo envíe lo notificará también. En el caso que falle el estudio o se cancele, también se notificará. Por otro lado, el PACS notificará a la Lista de Trabajo cuando se ha recibido la totalidad del estudio. Con esta información, la Lista de Trabajo será capaz de:

1. Marcar la cita como realizada (o cancelada si es su caso)
2. Enviar un mensaje HL7 al RIS indicándole la finalización del estudio.

Con este intercambio de información, el ciclo de la Lista de Trabajo se cierra.
























Con esto cerramos este artículo dedicado a la Lista de Trabajo Dicom o Dicom Modality WorkList. Espero que os haya servido o gustado.

Entornos de Replicación en SQL Server

La replicación de base de datos es una herramienta muy potente en el mundo de las aplicaciones distribuidas. Sus aplicaciones en el mundo real son muy variadas. Sin embargo, para que se pueda utilizar de forma correcta y funcione como esperamos es importante conocer realmente cómo funciona y las diferentes opciones que nos ofrece. En principio este artículo está orientado a la replicación sobre bases de datos SQL Server 2000/2005 aunque la teoría es extrapolable a otros gestores del mercado.

En este artículo entenderemos la replicación y veremos cómo planificar una replicación:

• Beneficios de la Replicación
• Elementos que influyen en la Replicación
• ¿Qué Replicación se adecua mejor a mi entorno?
• ¿Qué tipo de suscripción debo utilizar?
• ¿Qué artículos debo publicar?
  

Beneficios de la Replicación
Los beneficios o los entornos donde es aplicable la replicación de bases de datos son los siguientes:

• Usuarios trabajando en ubicaciones geográficamente alejados trabajando con sus propias copias locales de la base de datos.
• Entornos en los que se replica la base de datos principal en una secundaria como copia de seguridad. En el caso que la primaria caiga, la secundaria toma el control.
• En entornos en los que la carga de usuarios sea muy grande para un sólo gestor, se pueden replicar las bases de datos en varios servidores asignando a cada usuario un servidor. Balanceando de esta manera la carga podremos aliviar a los gestores.

Como observamos, los entornos son variados y comunes en muchos casos. El problema reside en la configuración y la elección correcta del tipo de replicación.

Modelo de Replicación
Antes de empezar, vamos a clarificar los conceptos y términos que se utilizan cuando hablamos de la replicación. Los elementos que componen la replicación son los siguientes:

• Publicador: es la instancia que pone sus datos a disposición de otras localizaciones mediante la replicación. El Publicador puede tener varias publicaciones configuradas cada una relacionada con un conjuntos lógico de objetos y datos.
• Distribuidor: es la base de datos destinada a almacenar la información específica asociada a la replicación de uno o más publicadores. Cada publicador es asociado con una base de datos (conocida como la base de datos de distribución) en el Distribuidor. La base de datos de distribución guarda el estado de la replicación, metadatos y en algunos casos hace de cola de distribución entre el publicador y el suscriptor. En la mayoría de los casos, la misma base de datos actúa como Publicador y Distribuidor. Cuando el Publicador y el Distribuidor se encuentran en servidores separados, el Distribuidor es conocido como "Distribuidor Remoto".
• Suscriptores: es una base de datos configurada para recibir datos replicados. Un suscriptor puede recibir datos de múltiples Publicadores y publicaciones. Dependiendo del tipo de replicación elegida, el suscriptor también puede pasarle datos al Publicador.
• Artículo: un artículo identifica un objeto de base de datos que es incluido en la publicación. Una publicación puede tener varios tipos de artículos: procedimientos almacenados, vistas, tablas y otro tipo de objetos. Cuando las tablas son publicadas, se pueden establecer filtros para restringir los datos y/o columnas que se envían al suscriptor.
• Publicación: es una colección de no o más artículos de una base de datos. La agrupación de artículos en una publicación hace más fácil especificar el conjunto de datos asociados en la replicación como una sola unidad.
• Suscripción: es una petición para que una copia de la publicación sea enviada al suscriptor. La suscripción define qué publicación será recibida, cuando y donde. Hay dos tipos de suscripción: de inserción y de extracción.
• Agentes: son los encargados de gestionar la comunicación y el envío de los datos entre los suscriptores y los publicadores.
  

Una vez aclarados los conceptos, vemos un diagrama del flujo simplificado de los datos y de los elementos que intervienen en una replicación:




















Tipos de Replicación
Una vez claros los conceptos, tenemos que decidir qué tipo de replicación se adecua de mejor manera a nuestro entorno de servidores. Lógicamente, independientemente de la replicación elegida, la aplicación sobre la que trabajemos debe estar preparada para funcionar en este tipo de entornos. Los tipos de replicación existentes son los siguientes:

Replicación Transaccional: también es conocida como replicación dinámica. En la replicación transaccional, las modificaciones en la publicación son propagadas a los suscriptores de forma incremental. Las características de este tipo de replicación son:

• El publicador y el suscriptor siempre están sincronizados.

• El entorno de transacción es respetado, si una transacción involucra a 5 registros, se replican estos 5 registros o ninguno.

• El publicador y el suscriptor deben estar siempre conectados.

Las situaciones en las que se aplica este tipo de replicación son las siguientes:

• Los suscriptores siempre necesitan estar al día en la información.
• Mantener las transacciones es importante.
  

Replicación de Mezcla: la replicación de mezcla provee de ventajas sobre la replicación de instantánea y la transaccional. La instantánea inicial es aplicada al suscriptor y desde ese momento SQL Server gestiona los cambios de datos al nivel de suscriptor y publicador. Los datos son sincronizadas o bajo demanda o sobre una planificación. Como los cambios de datos se producen tanto en el suscriptor como en el publicador, los conflictos durante la replicación son comunes. Para solucionarlos, se define un resolutor de conflictos, que es aquel que dicta en un conflicto qué dato es el que se guarda. Las características de esta replicación son:

• Los cambios de datos se realizan tanto en el suscriptor como en el publicador.

• Los datos se mezclan según una planificación o bajo demanda.

• Permite a los usuarios trabajar offline y sincronizarse en el momento que quieran.

Las situaciones en las que está replicación es la mejor son:

• La autonomía de las diferentes localizaciones es crítica.
• Múltiples suscriptores necesitan actualizar datos al mismo o diferente tiempo en el publicador.
  

Replicación de Instantánea: también es conocida como replicación estática. Este tipo de replicación copia los datos y objetos de la publicación exactamente como se encuentran en el publicador y los distribuye a los suscriptores. Cada suscriptor será una copia exacta del publicador. Las características de esta replicación son:

• Los suscriptores son actualizados con todos los datos modificados no por transacciones individuales.
• La propagación de cambios hacia el suscriptor lleva más tiempo, siendo un proceso que se ejecuta pocas veces al día y de forma programada.

Los entornos en los que se debe utilizar este tipo de replicación son:

• Los objetos de base de datos no se modifican frecuentemente.
• La cantidad de información a replicar no es grande.
• Los usuarios suelen trabajar de manera desconectada no siendo importante el que trabajen con la información actualizada.

Tipos de Suscripción
Una vez que tenemos decidido el tipo de replicación a utilizar y que mejor se adapta a nuestro entorno, tendremos que decidir qué tipo de suscripción vamos a configurar. Existen dos tipos:

• Suscripción de Inserción: el agente es gestionado por el publicador. Según las planificaciones realizadas, el agente se conectará al suscriptor que tenga configurado y le insertará la información. En el caso que los cambios se propaguen desde el suscriptor al publicador, este agente se encargará también de esta tarea.
• Suscripción de Extracción: en este caso, cada suscriptor tendrá su propio agente que se conectará al distribuidor para obtener la información de la replicación.

En el tema de las suscripciones, el resultado es el mismo en una como en otra. Las consideraciones que hay que tener son de rendimiento. En el caso de las suscripciones de inserción, la administración se centraliza en un único servidor pero la carga de trabajo crece. Si tenemos demasiados suscriptores es posible que el rendimiento se vea gravemente afectado. En el caso de la suscripción de extracción no tendremos el problema del rendimiento pero serán más difíciles de administrar.

Artículos de la Publicación
Una vez que tengamos definidos toda la replicación tendremos que decidir qué artículos replicar. Este estudio es importante puesto que será la información que se transmita entre los suscriptores y publicadores. No hay que incluir en la replicación elementos extras que no influyan en ella.

El administrador de cada aplicación le orientará en este aspecto.

Conclusión
La replicación es, sin lugar a dudas, una herramienta muy importante en entornos distribuidos de trabajo. Sin embargo, mal utilizada puede llevar a pérdidas de información y desestabilizaciones de sistemas. La replicación como tal no es un sustituto real del balanceo de carga de servidores de bases de datos (Oracle RAC), pero usada correctamente nos puede permitir una movilidad de trabajo muy grande.

Teoría sobre un Sistema PACS de Imagen Digital (I)

Actualmente, los sistemas de imagen médica digital están muy de moda. Los hospitales y las clínicas se dan cuenta cada vez más que el futuro pasa por digitalizar sus radiografías en sistemas PACS para poder tanto clasificar como compartir esta información con otros médicos. Sin embargo, no hay mucha gente que sepa realmente que conlleva o cómo es un sistema de almacenamiento de imágenes médicas. Iremos paso a paso:

PACS (Picture Archiving and Communication System)
O en español, Sistema de Comunicación y Archivado de Imágenes. Formalmente, un sistema PACS se define como un grupo de equipos y redes dedicados al almacenamiento, recuperación, ditribución y presentación de imágenes médicas. Realmente lo que se considera como PACS es la parte servidor, la aplicación que provee de la lógica necesaria para el almacenamiento, la recuperación y la distribución de las imágenes. La parte de presentación la llevan los visores tanto diagnósticos como clínicos y no se suelen meter dentro de la definición del PACS. El funcionamiento básico de un PACS es el siguiente:

• Una máquina creadora de imágenes (CT, Ecografo, Rayos, Resonancia, etc.), llamada "modalidad", genera una imagen, introduce la información de la prueba y del paciente en la cabecera y la envía al PACS.
• El PACS recibe la imagen, extrae la información de la cabecera, almacena parte de esa información y archiva la imagen en alguna ubicación por él conocida.
• Cuando un médico desee ver esa imagen, se conectará al PACS mediante un visor de imágenes, realizará una consulta y pedirá la/s imágenes deseadas.

El funcionamiento en sí es muy simple, sin embargo, existen muchos elementos a tener en cuenta. El primero es que existen muchísimos fabricantes de modalidades en el mundo (General Electric, Kodak, Agfa, Fuji, etc.) y muchos tipos de modalidades distintas (Tomografía Axial Computerizada, Ecografía, Radiofluoroscopia, Mamografía, Resonancia Magnética, etc.) cada una de ellas con sus peculiaridades. El PACS por lo tanto debe ser capaz de recibir todos los tipos de imágenes de cualquier fabricante, saber leer y extraer la información de la cabecera de forma correcta y tratar a cada una de ellas de una manera específica. Por otro lado, existen también múltiples visores de imágenes médicas en el mercado, tanto gratuitos como de pago, mejores y peores y el PACS debe ser capaz de hablar con ellos, dar respuesta a sus peticiones y enviarles las imágenes deseadas. Realmente parece que es una tarea imposible, pero para dar coherencia a este mundo existe el estándar DICOM.

DICOM (Digital Imaging and Communications in Medicine)
DICOM es un grupo de estándares para manejar, almacenar, imprimir y transmitir información de imagen médica digital. Incluye una definición de los formatos de ficheros y un protocolo de comunicación en red. El protocolo de comunicación es un protocolo de aplicación que utiliza TCP/IP para comunicarse entre sistemas. Los ficheros DICOM se pueden intercambiar entre dos entidades que sean capaces de recibir datos de imagen y paciente en formato DICOM.

DICOM permite la integración de escáneres, servidores, estaciones de trabajo, impresoras y electrónica de red de múltiples fabricantes dentro de un sistema PACS. Los diferentes elementos involucrados en el sistema deberán publicar su Dicom Conformance Statement para saber qué servicios soporta cada uno.

Los servicios generales que ofrece DICOM son:

• Store: este servicio es usado para enviar imágenes o otros objetos persistentes (structured reports,...) hacia un PACS o una estación de trabajo.
• Storage Commitment: este servicio se encarga de dar conformidad cuando una imagen ha sido correctamente almacenada en el PACS. Al enviar la respuesta a la modalidad, ésta puede, en su caso, eliminar la imagen.
• Query/Retrieve: permite a las estaciones de trabajos consultar y obtener imágenes u objetos del PACS.
• Modality Worklist: Permite a las modalidades obtener la lista de pacientes citados, evitando que el técnico tenga que teclear los datos. Este servicio es muy importante puesto que es el nexo de unión entre el RIS (Radiological Information System) y el PACS. En capítulos posteriores hablaremos de la Worklist.
• Modality Performed Procedure Step: es un servicio complementario a la Modality Worklist y permite a la modalidad enviar información sobre el estado de los exámenes, información de la dosis, etc.
• Printing: este servicio permite enviar las imágenes a la impresora de placas. Existe un estándar de calibración (definido en la Parte 14 del estándar) que permite que las imágenes se impriman de igual manera en diferentes dispositivos.
• Off-line Media (DICOM Files): define la creación de DICOMDIR

Visión Global de un Sistema PACS:
Este esquema define, de forma básica las operaciones y elementos involucrados en un sistema PACS.
















Enlaces de Interés:

Estándar DICOM
Wikipedia DICOM
Wikipedia PACS

En próximos artículos se irán desarrollando los diferentes servicios y posibles arquitecturas sobre las que se puede implementar un sistema PACS.

Consideraciones para crear un Cluster de Servidores

Los cluster de servidores permite dotar a las aplicaciones y/o servicios que se ejecuten en un grupo de servidores de alta disponibilidad. El funcionamiento básico de los clusteres es el siguiente:

• Una aplicación se ejecuta en uno de los nodos del cluster
• En el momento en que este nodo cae, el cluster toma la aplicación y la levanta en otro de los nodos.

Los usuarios normalmente no notan nada, sin embargo, existe un corte de x segundos hasta que el cluster es capaz de levantar de nuevo la aplicación en otro nodo. Cuando se trabajo con aplicaciones que mantienen conexiones abiertas, éstas se pierden.

¿Cómo funciona un cluster?
Los clusteres se basan en la publicación de sus servicios mediante IPs virtuales. Cuando un administrador da de alta una aplicación, con sus correspondientes recursos (luego veremos cómo), aparece en la red un nuevo servidor, con un IP, un nombre de red y los recursos que le hemos asignado. El mantenimiento de esta estructura la realiza el cluster en sí. Cuando un usuario realiza una petición al servidor virtual, el cluster redireccionará al servidor físico que realmente esté ejecutando la aplicación. En el caso que se caiga este servidor físico, las peticiones hacia la IP virtual serán redirigidas por el cluster hacia el nuevo servidor que haya empezado a ejecutar la aplicación. En el siguiente esquema se ve el funcionamiento:

Aspectos Técnicos a tener en cuenta:

A la hora de montar un cluster, hay que tener en cuenta ciertos aspectos importantes que pueden determinar el buen funcionamiento de la solución. Los requisitos fundamentales son:

• Cabina de discos compartida donde se alojarán los datos de los servidores
• Dobles tarjetas de red para poder utilizar una entre ellos y otra para la red
• Sistema Operativo que permita la gestión de clusteres. En el caso de Microsoft, sólo los opertativos Enterprise lo permiten.

Antes de empezar a montar los servidores debemos dimensionar nuestro espacio en la cabina para que se acomode a las necesidades de las aplicaciones. Imprescindible es dejar espacio para la unidad de Quorum que es la encargada de mantener el estado de las aplicaciones y que sirve de nexo de unión entre los servidores. Para esta unidad se suelen dar 512MB de espacio (normalmente es el mínimo que permiten las cabinas). Luego, para cada aplicación que lo precise se le irá creando una o varias unidades en la cabina. Un ejemplo normal sería el siguiente:

• Quorum: 512MB
• Base de Datos: 100 GB
• Ficheros: 2TB

Es importante saber que existe una limitación en las cabinas por las que no son capaces de crear volúmenes mayores de 2TB. Además, los clusteres de Microsoft, no así los de Linux, no permiten discos dinámicos, con lo que las aplicaciones tienen que estar preparadas para ello.

Una vez que hayamos creado los volúmenes, crearemos el cluster (vamos a ir siguiendo el método de Microsoft) mediante el administrador de clusteres. Al crearlo tendremos que darle los siguientes datos:

• IP Virtual del cluster
• Nombre DNS del Cluster
• Unidad de Quorum

Con estos datos se creará el cluster que contendrá un grupo de aplicaciones para el cluster con tres recursos (IP, Nombre y Unidad) y un grupo de aplicaciones por cada volumen de la cabina que haya encontrado. Una vez creado tendremos que incluir en el cluster el resto de nodos que vayan a formar parte de él.

Una vez incluidos los nodos, tendremos que crear los grupos de aplicaciones. Esto es tan sencillo como incluir los ejecutables necesarios o los recursos necesarios (servicios, carpetas compartidas,...) en el grupo de aplicaciones. Se le dará a cada grupo de aplicaciones un nodo preferido donde se ejecute que será el que por defecto arranque la aplicación. Hay determinadas aplicaciones (p.e. SQL Server u Oracle) que al instalarlas detectan automáticamente que se encuentran en un entorno de cluster y se instalan en todos los nodos y crean sus propios grupos de aplicaciones. Para el resto de aplicaciones hay que realizar la instalación manualmente en todos los nodos y mantener exactamente la misma configuración. Lógicamente, para cada grupo de aplicaciones tendremos que dar también una IP Virtual a la que responderá y un nombre de red.

Consideraciones Finales:
Una vez que la instalación se haya completado y el cluster esté en funcionamiento, toda la administración se debe realizar desde el administrador de clusteres. El arranque o parada de los servicios, la conmutación entre nodos, los cambios de configuración no se deben hacer directamente en las aplicaciones.

Propósitos e Intenciones

Esta es la primera entrada del blog para la discusión de posibles temas tecnológicos dentro de los siguientes ámbitos:

• Imagen Médica Digital: introduciremos temas sobre el estándar DICOM y su implementación en el mundo real. La utilización de técnicas modernas dentro de este protocolo cliente/servidor.

• Técnicas de Desarrollo Software: discusiones sobre metodologías de trabajo y de desarrollo en entornos distribuidos y compartidos. Nuestra experiencia en el campo de los grandes sistemas nos ha proporcionado un buen punto de partida para artículos sobre éstos.

• Implementación de Sistemas Hardware: el gran desconocido dentro de los proyectos es el técnicos de sistemas. Su labor, sin embargo, es muy importante puesto que aporta la base tecnológica sobre la que se desarrollarán los proyectos. El almacenamiento, los servidores, la redes SAN, los switches de fibra,... todos estos son temas que merece la pena ir desarrollando en diferentes artículos.

A medida que vaya pasando el tiempo iremos publicando artículos sobre todos estos temas y esperamos que os vayan gustando. Nuestro propósito es intentar crear un entorno donde podamos transmitir aquellos conocimientos adquiridos en años de trabajo en empresas del ámbito tecnológico. De esta forma, aquellas personas que en algún momento se vean en alguna situación tecnológicamente comprometida (a todos nos ha pasado alguna vez) pueda aprovechar esos conocimientos.

El equipo de N-Idea.