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.