SISTEMA DICOM MULTIPLATAFORMA PARA MANEJO, PROCESAMIENTO Y AUDITORÍA DE IMÁGENES MÉDICAS EN REDES Autores: BioIng. BARRERA, O. Andrés - MOLINAS, Matías E. Castellanos 1767 (3000) Santa Fe Pcia. de Santa Fe - ARGENTINA Correo-E: roimed@infovia.com.ar Abstract. El presente trabajo, describe un sistema multiplataforma desarrollado para el manejo, procesamiento y auditoría de Imágenes de Diagnóstico Médico a través de redes (Intra o Internet). El sistema está basado en un diseño Cliente/Servidor orientado a objetos, para el cual se utilizó como lenguaje de programación JAVA1 y posteriormente JAVA1.2, y se realizó de acuerdo a la norma DICOM 3.0. Consiste en un servidor en el que reside el programa encargado de: manejar las operaciones DICOM Complejas de red con los usuarios y proveedores (equipos y/o estaciones de trabajo) generar automáticamente los reportes HTML para auditorías externas (vía Internet o link telefónico directo al servidor) encriptar la información a transmitir por la red actualizar la base de datos y el DICOMDIR y del cual se descargan los applets a las estaciones de trabajo que lo accedan, previa identificación de usuario y contraseña. 1 Objetivos del Trabajo La finalidad de este trabajo es el desarrollo de herramientas para el Diagnóstico por Imágenes que permitan: administración, procesamiento y Teleconsulta de Imágenes Médicas realización de tareas de auditoría en forma remota acceso remoto a Imágenes de diagnóstico médico e información adjunta relacionada digitalización de la gestión de imágenes médicas aseguramiento de La confidencialidad e integridad de datos de la imagen médicos en el contexto específico de redes aportar al profesional un medio para aumentar sus prestaciones, incrementando su eficiencia y optimizando sus recursos compatibilidad entre diferentes plataformas (LINUX, Windows, UNIX, etc.)
Para ello, se utilizó como lenguaje de programación JAVA 1.2 (JAVA 1 inicialmente) y la Norma DICOM 3.0 como protocolo de comunicación, formato de archivos, etc. 2 Actividades Iniciales El presente trabajo se realizó en etapas, la primera de las cuales consistió en el estudio de la situación actual de la parte técnica, médica y administrativa de instituciones de salud que brindan servicios de Diagnósticos por Imágenes o son usuarios de los servicios de las mismas (p.e. centros de terapia radiante) en las ciudades de Paraná (Entre Ríos), Santa Fe (Santa Fe) y Tres Arroyos (Buenos Aires). En forma simultánea, se estudiaron casos reportados en distintas partes del mundo (Reino Unido, EEUU, Alemania, etc.) para conocer las tendencias que se manejan en países desarrollados, y de ese modo acortar algunos caminos. Asimismo se realizaron consultas continuas con personal de la FUESMEN, cuyas inmediatas respuestas resultaron de suma utilidad. En forma paralela se estudió la norma DICOM 3.0, base fundamental de este trabajo, así como herramientas de desarrollo software, bases de datos, protocolos de comunicación y lenguajes de programación (JAVA). De esta primer etapa sólo se expondrán las conclusiones extraídas, que representan la justificación del proyecto: contribuye a disminuir la cantidad de material fílmico impreso, disminuyendo costos, tiempo de personal, etc. contribuye a aprovechar mejor el tiempo de trabajo de los expertos en una institución, que muchas veces se encuentran ocupados parcialmente por falta de casos de estudios de la propia cínica, mediante la teleconsulta de profesionales de otras instituciones posibilita brindar servicios a distancia centraliza las imágenes de toda la institución, ahorrando tiempos de acceso y búsqueda, y aumentando la facilidad y comodidad del manejo y utilización de las mismas permite implementar una política eficaz de copias de seguridad y registro de todos los estudios de imágenes realizados
3 Descripción Del Sistema 3.1 Descripción General Fig. 1. Descripción general El centro del sistema de la Fig. 1. es el servidor, que se comunica mediante el protocolo DICOM con los equipos de Imágenes medicas, obtiene los estudios de imágenes de los mismos y los almacena permitiendo de este modo que cualquier maquina con un navegador web y con maquina virtual de Java pueda accederlos. El equipo de imágenes médicas puede estar dentro de una red TCP/IP propia (una intranet), o bien en internet. De este modo el servidor puede obtener estudios de cualquier equipo de imágenes sin importar su ubicación geográfica, permitiendo que el sistema pueda trabajar con dispositivos que no están disponibles en la institución donde esta implementado. El estudio, una vez movido al servidor, es almacenado en la base de datos, y desde ese momento controlado su acceso y edición, de manera que solo puedan hacer aquellas personas que correspondan. Desde ese momento también quedará almacenado y podrá ser recuperado en cualquier momento. Esto permitirá una posterior consulta, para completar el diagnostico del mismo o para realizar un seguimiento del paciente a lo largo de su historia. La tarea de recuperación de consulta del estudio es sencilla ya que el servidor cuenta con un motor de búsqueda. Y debido a una correcta política de almacenamiento y seguridad, la integridad de los datos del estudio esta asegurada. El motor de búsqueda permite también realizar búsquedas de estudios por parámetros generales (como sexo, edad del paciente, fecha del estudio, diagnostico, etc....), y en el caso de que sea para su difusión publica oculta el nombre del paciente y el de la institución en que se realizo el estudio. El acceso a los estudios del servidor para su consulta y procesamiento se realiza desde cualquier computadora, independientemente de su plataforma que tenga un navegador web, con máquina virtual de Java (como el Netscape Navigator, o el Internet Explorer). Esta máquina puede estar dentro de la institución, puede ser externa y acceder en forma remota a la red de la institución o, en el caso en que el servidor esté en internet, cualquier máquina podría accederlo desde la Web. Asimismo, un mó dulo, también desarrollado en JAVA, permite al servidor responder a un llamado telefónico y establecer un link directo a través del módem. En cualquiera de los casos es necesario estar registrado como usuario, y tener una clave de acceso propia.
Esto permitiría: a un especialista, acceder a los estudios desde cualquier ubicación geográfica y dar su opinión, realizar estudios clínicos sobre los resultados de las búsquedas en la base de datos, prestar un servicio de teleconsulta y telemedicina en Diagnostico por Imágenes Medicas. Por otro lado, un auditor de una obra social puede acceder al historial de estudios de una Institución o de un paciente en particular para autorizar de manera inmediata un nuevo estudio, verificando la correcta realización de los estudios anteriores. 4 Bases DICOM de la Implementación A continuación se detallará el funcionamiento y los criterios de diseño del sistema y el software desarrollado para tal fin. Se repite la gráfica para tener presentes las distintas partes de la misma durante el análisis. El estándar DICOM contempla tanto el protocolo de comunicación para estudios de diagnóstico médico, como la codificación en archivo de la información de los mismos. 4.1 Red DICOM contempla tres posibilidades o protocolos para la comunicación en red: Full Duplex (OSI), Upper Layer Protocol aumentado TCP/IP y DICOM point-to-point - 50-pins. En la presente solución se utiliza TCP/IP. 4.2 Servidor Es el componente principal de la red. Aquí es donde reside el programa Java principal (y único, según se verá más adelante) encargado del manejo de la directivas DICOM. Administra archivos y objetos conformados con la información de los estudios. A partir de la conexión con el servidor, los usuarios cargan el applet del programa con las funciones implementadas y se comunican con el proveedor por una conexión socket. 4.3 Java DICOM Server Java DICOM Server es la implementación en lenguaje Java de todas las funciones de red y archivos DICOM que se desarrollaron. Es la clase DICOMClientServer la encargada del manejo de todas las operaciones para el manejo en red. Esta clase define los métodos tanto para el servidor como para los clientes de la red. 4.3.1 Modo Sincrónico DICOM contempla dos modos de comunicación entre Usuario y Proveedor: Sincrónico y Asincrónico. El primero de los casos implica que al establecerse la conexión entre ambas partes, cada operación debe llegar a su finalización para iniciar una próxima. En cambio, para el modo asincrónico, puede haber más de una operación cliente/servidor en proceso. En este sistema fue implementado el primero de los casos, ya que es el que la norma establece por defecto. 4.3.2 Asociaciones: Antes de poder lograr el intercambio de información entre dos clases SOP(Service Object Pair), debe establecerse entre ellas una Asociación (Association en DICOM), donde se negocia para establecer las posibilidades de trabajo de cada una parte.
Una vez establecida la asociación, si esta fue satisfactoria puede establecerse el intercambio de mensajes a través de los DIMSE- DICOM Service Element- (DIMSE-C en este caso, que soporta operaciones con Instancias Compuestas SOP). 4.3.3 Mensajes Los mensajes entre dos aplicaciones DICOM deben tener una estructura como la que se muestra en la Fig. 2. DICOM Message Command Set Data Set (defined in Part 5) Command Element Tag Length Value Fig. 2. Estructura del mensaje DICOM La norma establece que la estructura del mensaje y set de comandos sea por defecto: - Tags en orden Creciente, - Little Endian, -VR Implícito Aquí se detallará la estructura utilizada por DICOM para codificar la información, ya que es relevante para la comprensión de lo anterior y los conceptos que se tratarán a continuación. La transferencia de mensajes entre aplicaciones DICOM se establece mediante el flujo de Data y Command Elements ordenados según el Tag y codificados como se ve a continuación. 4.3.4 Estructura Basada en TAGs A partir del esquema mostrado en la Fig. 3., se irán incrementando los detalles para la comprensión de la estructura de codificación establecida por la norma DICOM. Es importante conocer este aspecto, ya que es el modo en que se codifican los mensajes para transferir los estudios y la información de un equipo a otro. Tanto el Command Set como el Data Set son colas de Command Elements 1 o Data Elements 2 respectivamente. En ambos casos, la estructura del elemento es la misma, difiriendo simplemente en el número de grupo y en algunos casos en el VR, como se verá a continuación. 4.3.4.1Campos del Data Element 1 Elementos de Comandos DICOM (Store, Find, etc.) 2 Codificación de datos (Fecha de Estudio, Modalidad de Estudio, etc.)
Fig. 3. Data Element Data Element Tag: Es un par ordenado de números de 16 bits codificados en hexadecimal. El primero de ellos hace referencia al Grupo, mientras el segundo se refiere al Elemento, y son leídos como enteros sin signo. Value Representation: (o VR) Es una cadena de dos caracteres que, segú n la cual se especifica el tipo de dato que se leerá en el Value Field. En la Part6 de la norma se especifica el tipo de dato (cadena de caracteres de hasta 16 bytes, cadena de caracteres de 4 bytes, etc.) correspondiente a cada sigla (AE, AS, etc.) Value Length:Entero sin signo de 16 o 32 bits(según sea VR Explícito o Implícito). Contiene un número par que indica la extensión del campo Value Field, donde se hallan contenidos los datos propiamente dichos. O bien 32 bits con (FFFFFFFFH) si el VR es SQ (Secuencia de Items) Para VR= OW o OB, depende de la Sintaxis de Transferencia de negociación. Value Field: Aquí se encuentra un número par de elementos conteniendo el/los valor/es. Es el dato propiamente dicho, cuya índole está determinada por los campos anteriores. El programa implementado se vale de una clase denominada ParseVR para la decodificación de los data/command Elementos, mediante un bucle en el que va leyendo e interpretando los distintos campos. En el caso de trabajar en modo Implícito (no figura el VR), hace uso de otra clase (RTC) en la que se halla el diccionario para los Tags y UIDs. 4.3.5 Instrucciones Implementadas En el estándar se consideran dos sets de instrucciones según el tipo de IOD s con el que estemos trabajando: ya sean IOD-C (Complejos) o IOD-N (Normalizados), y un tercero para el trabajo en Media. Dado que la presente implementación centra su atención en los primeros, se implementaron las directivas de red para los Objetos de Información Complejos. C-Echo: Este comando es para realizar una verificación end-to-end, En otras palabras un equipo envía un llamado a otro, y espera que este le conteste. C-Find: Un DSU solicita a otro una serie de cadenas (strings) de atributos, en lugar de los atributos del set de Instancias SOP del DSU 3. Retorna para cada punto solicitado una lista de atributos y sus respectivos valores. 3 DSU = DICOM Service User. Servicios DICOM para el sistema cliente.
C-Move: Un DSU (A) solicita a otro mover la información de una o más instancias SOP desde otro DSU (B) hacia un tercero (C). C-Get: Un DSU pretende atraer la información de una o más instancias SOP desde otra DSU, basada en atributos aportados por la DSU solicitante. C-Store: Un DSU solicita a otro que almacene una instancia de un SOP compuesto. 4.3.6 Equipos Los equipos que vayan a ser conectados a la red deben cumplir con DICOM. La norma no es estricta en las partes de la misma que deben ser implementadas. En lugar de ello permite a los desarrolladores y fabricantes implementar las partes que deseen pero los obliga a una completa documentación cuya estructura está ya estipulada 4. Por esta razón debe consultarse la documentación de los diferentes equipos para corroborar que se encuentren implementadas los comandos de red que sean de interés de los usuarios. Sin embargo, dado que en esta implementación consideramos las operaciones por defecto, muy probablemente no existan inconveniente con la mayoría de los equipos apegados al estándar. 4.3.7 Formato de los Archivos En un archivo apegado a la norma, existe (puede existir) información diversa: Datos de Imagen, la cual puede estar intacta o comprimida 5. Identificación y demografía del paciente Información técnica del examen, series y cortes. Información de la Institución y autores del estudio. Otros Para la extracción de la información de la imagen encontramos en general 3 tipos diferentes de o familias de formatos más usualmente utilizadas: Formato fijo, donde la salida es idéntica para cualquier archivo Formato en bloques, donde el encabezado posee punteros de información Formato basado en TAG, donde cada ítem contiene su propia longitud. El tercer caso es el utilizado por ACR/NEMA y DICOM (y por lo tanto el que se implementó). Los tags son descriptivos de sí mismos: cada uno es AutoDescriptivo y AutoContenido y contienen su propia longitud. Y en el caso de que no se pueda descifrar alguno (por no tener el diccionario apropiado ver Part 6) se lo puede saltear y continuar con los siguientes. Puede intuirse que sus diseñadores lo hicieron pensando en expansiones futuras. El estándar especifica un formato en el que contempla un encabezado, un identificador ( DICM ), y el listado de los Data Elements. Dado que esta configuración resultó de adaptar versiones anteriores, son comunes archivos de estudios sin el encabezado e identificador, que aunque no se apegan totalmente a la norma, por su uso corriente, se han considerado y pueden también manejarse por este sistema. En esta implementación se pueden manejar, visualizar y procesar archivos con las siguientes características: Formato Dicom (Part10), ACR-NEMA y Papyrus (con y sin encabezado) VR Little Endian Implícito y Explícito Imágenes de 8 a 16 bits de profundidad Imágenes sin compresión 4 DICOM v3.0 Part2 ACR-NEMA 5 Con o sin Pérdida y con diferentes grados de compresión.
Imágenes de Tomografía Computada (TC), Radiología computada (RC), Resonancia Magnética Nuclear (RMN), Ultrasonido (US), Otras modalidades (OT). Dada la estructura de objetos con la que se realizó el programa, es sencillo aumentar el alcance del mismo a series de imágenes, imágenes con compresión, sintaxis de modo explícito, etc. 4.4 Estaciones de Trabajo Es aquí donde se puede interactuar con el sistema. Dada la naturaleza multiplataforma de esta implementación, el sistema operativo y la plataforma de las estaciones de trabajo utilizadas pueden ser diversos (Windows, Linux, etc.), con lo que se amplían notablemente las posibilidades del sistema, y a la vez permite utilizar el hardware disponible en la institución que implemente esta solución. Como mencionamos anteriormente, se carga en cualquiera de las estaciones de trabajo un applet desde el servidor en un navegador (Internet Explorer o Netscape Navigator p.e.). Aquí será requerido un nombre de usuario y una clave de usuario para poder acceder al sistema, y según sea la prioridad del usuario, se le conceden permisos para realizar diferentes operaciones. Las operaciones de manejo en red disponibles son: Buscar un estudio en la Base de Datos (implementación de C-Find) Mover un estudio de un equipo/estación de trabajo/servidor a otro (C-Move) Bajar a la estación de trabajo un estudio determinado (impl. de C-Get) Guardar un estudio (implementación de C-Store) Modo Servidor (implementación del Server) La implementación de las mismas fue explicada en 4.3.5 Instrucciones Implementadas. Según la operación seleccionada, la máquina cliente genera SOP correspondiente y se inicia la comunicación con el servidor. Todos estos procesos son invisibles al usuario, simplemente se le pueden solicitar algunos parámetros, como por ejemplo los campos de búsqueda. Se incluyeron además algunas herramientas para el procesamiento de las imágenes. Para determinar las de mayor uso por parte de los profesionales de la salud, además de la observación de diversos programas comerciales, se consultó con médicos especialistas de nuestro y otras localidades. Las herramientas son las siguientes: Zoom (o Magnificación), Zoom Activo, Modo Inverso, Filtros, Ventaneo, Detección de Bordes, Histograma, Brillo y Contraste.
5 Descripción Técnica del Sistema 5.1 Arquitectura del sistema Fig. 4. Arquitectura del sistema El sistema a sido implementado en Java debido a que esta tecnología permite al sistema trabajar sobre cualquier plataforma. Esto es importante dado que la mayoría de los equipos de imágenes medicas utilizan UNIX como sistema operativo, mientras que las máquinas clientes puede utilizan Windows, MacOS, Linux, etc. Esto permite además que el servidor pueda ser escalado de una plataforma como NT o Linux a una mas potente como AIX o Solaris. Java permite también por JDBC (Controlador de Bases de Datos de JAVA) utilizar cualquier base de datos relacional con SQL estándar, por lo que la base de datos que utiliza el servidor también es escalable de Access o Postgres, a una base de datos mas potente como Oracle, o SQL Server. La base de datos utilizada para una implantación en Windows NT es entonces Access, SQL server, u Oracle. En Linux utiliza Postgres, u Oracle. Como servidor Http bajo NT se utiliza IIS (Internet Information Server) y sobre Linux el servidor Apache, (ver sistemas mas potentes como AIX). El servidor Http es utilizado como el sitio web donde esta implementada la interfase del sistema (el visor), que es descargado por los navegadores web, al navegarlo. Debido al considerable volumen de los estudios, estos no se almacenan en la base de datos, si no que se implementa un directorio como servidor de archivos, que solo puede ser accedido por el servidor Dicom. El Servidor Dicom esta implementado en Java y por lo tanto es necesario contar con una maquina virtual Java, son preferibles aquellas que lo compilan a código nativo que aquellas que lo interpretan para obtener una mayor performance. Finalmente el visor esta implementado como un applet Java e incrustado en una pagina web, de modo que cualquier navegador web con maquina virtual Java pueda ejecutarlo al navegarlo. Este visor provee herramientas de visualización y procesamiento de los estudios que pueden ser utilizados desde cualquier plataforma.
5.1.1 Detalle del sistema Fig. 5. Detalle del sistema 5.1.2 Base de datos La solución diseñada para el almacenamiento de los estudios de imágenes medicas es la siguiente: se utilizaran dos discos SCSI para obtener una unidad espejada (RAID1) para no perder datos en casos de una falla en uno de los discos y para permitir el continuo funcionamiento del sistema aunque ocurra una falla de este tipo. Cabe aquí hacer una descripción de cómo funciona internamente el servidor DICOM implementado. - Ante una consulta para obtener un estudio se devuelven los estudios correspondientes pero formados solo por un set seleccionado de sus registros que es almacenado en la base de datos, el set de registros de cada estudio que se almacena en la base de datos a sido criteriosamente seleccionado para permitir contar con un satisfactorio criterio de búsqueda y permitir que el sistema pueda ser implementada en una red 10Mb. o a través de una conexión telefónica o de internet. (En este set de registros no se han incluido las imágenes por ser de volumen crítico). Una vez que la búsqueda es satisfactoria, se obtiene el estudio completo desde un directorio del servidor, funcionando entonces el mismo como servidor de archivos. La integridad entre la base de datos y los archivos de estudios esta asegurada por el servidor DICOM. Sólo este y de modo interno es quién la maneja. Una mejor implementación (pero mas onerosa) es la de considerar tres servidores una para el servidor DICOM, otro como servidor de base de datos, y un tercero como servidor de archivos. El directorio con los estudios completos es salvado (BackUp) cada trimestre, pero ante una consulta posterior se seguiría obteniendo un resumen del mismo desde la base de datos, aunque el estudio completo no se estará disponible. Se ha implementado un mecanismo para que previendo una recuperación del estudio desde el backup a un directorio temporal, el servidor en caso de constatar que corresponde a una fecha ya almacenada lo busque en el mismo previendo esta situación. En este directorio temporal permanecerán los estudios recuperados por un periodo de 5 días y luego se eliminaran del mismo. De esta manera el sistema permite el acceso a un archivo histórico que va desde el día de la implantación del sistema. 5.1.3 Servidor Este servidor a sido desarrollado en Java, en base a una implementaron publica en C++, esta implementaron es la del Centro Medico Davis de la Universidad de California (USA). Siguiendo la filosofía utilizada por esa Institución, se implementaron las principales clases utilizadas por el servidor. Las clases principales son las siguientes:
DICOMClientServer que es una interfaz de alto nivel. RTC que implementa el DICOM Data Dictionary. DICOMObject para la manipulación de alto nivel de los objetos Dicom. DICOMUtil que contiene métodos útiles para la implementaron de la base de datos. DICOM para manejar constantes Dicom SOP para las implementaciones de las SOP class (C-Echo, C-Store, C-Find, y C-Move). PDUType CRequest para la funcionalidad DIMSE-C de bajo nivel. Buffer para la funcionalidad de entrada/salida de bajo nivel. Finalmente para explicar la filosofía de trabajo del servidor cabe decir que una instancia del mismo esta permanentemente escuchando en el puerto 104, y que ante una petición de un cliente configura una nueva instancia de si mismo de modo que pueda atender la petición y la ejecuta como una hebra para que esta nueva instancia maneje la petición y la instancia inicial continua atenta a nuevas peticiones en el puerto 104. 5.1.4 DICOMDesktop Esta clase hereda de JApplet y permite implementar una sesión en el sistema desde un explorador web con maquina virtual de Java. Esta basada en las JFC (Java Foundation Classes) de Java2, en las librerías DICOM desarrolladas para el servidor Dicom, en las IPC (Imaging Processing Classes) desarrolladas para proporcionar herramientas para el procesamiento digital de imágenes y en el DMO (Data Management Object). Su finalidad es el manejo del acceso a base de datos a través de la JDBC, por lo que realmente es un escritorio con los métodos necesarios para el manejo de imágenes Dicom, el procesamiento de imágenes, el acceso a base de datos, y tiene la capacidad de ejecutar en su interior cualquier aplicación que este desarrollada partiendo de un JFrame de la JFC. En nuestro caso las aplicaciones desarrolladas a partir de la clase Jframe son DICOMSight que permite la consulta y procesamiento de estudios de imágenes medicas, DICOMFind que es una interface para realizar búsquedas basadas en el protocolo Dicom, y una pequeña aplicación de charla y otra de correo electrónico. Fig. 6. Esquema de las clases en la parte cliente del sistema
Del esquema las clases describiremos con un poco mas de detalle son las IPC, ya que las JFC son parte de Java 2, el DMO esta basado en la JDBC de Java, y sobre las clases DICOM se ha dado una breve descripción. Dentro de la IPC tenemos Clases de procesamiento puntual (la imagen de salida del procesamiento no tiene ninguna modificación geométrica respecto a la imagen de entrada), enumeradas en el último párrafo de 4.4 Estaciones de Trabajo. 6 Conclusiones Para finalizar, se puede concluir que se cumplieron con todos los objetivos planteados al iniciar este proyecto. Inclusive, dadas las características del programa implementado, es fácilmente ampliable. Por ejemplo ya se trabaja en la inclusión de Módulos Normalizados DICOM, el modo de transferencia Explicit VR Big Endian Transfer Syntax, y ya se agregó Explicit VR Little Endian Transfer Syntax. Asimismo, se estudia la inclusión de herramientas de teleconferencia, chat y correo desarrolladas por empresas como Netscape y Microsoft para aumentar las posibilidades del sistema. También es propicio aclarar en este punto que críticas recibidas de los evaluadores de esta tesis, así como de los médicos especialistas consultados han sido muy buenas, cumpliendo la implementación con las expectativas de funcionalidad y entorno. 7 Bibliografía Afergan M. : JAVA -Soluciones Instantáneas- : Prentice-Hall : Ispanoamericana : 1997. Bourdette, J. : JAVA desde cero : MP Ediciones : mayo de 1998. Castiglione, D.: Construyendo Intranets: MP Ediciones S.A.: mayo 1998. Cátedra Imágenes en Medicina: Apuntes : UNER, Facultad de Ingeniería, Bioingeniería. Cátedras Varias: Apuntes: UNL, Facultad de Ingeniería, Ingeniería en Sistemas. Doherty, D., Manning M. M.: Jbuilder 2 in 21 Days-: Sams Publishing: 1998. Flanagan D.: JAVA Examples in a Nutshell: O REILLY septiembre de 1997. Ferrer-Roca, O. y Sosa-Iudicissa, M.: Handbook of Telemedicine: Ed. IOS Press OHMSHA: 1998. NEMA Standard Publications: DICOM v3.0. OSIRIS User Manual V 3.0: UIN/HCUG: Hospital Universitario de Ginebra: División Informática Médica: Unidad de Ingeniería Numérica: 1995-1996 Philips Medical Systems Netherland B.V.: DICOM Cook Book: 1996,1997 Revista PC User : Nº 25, 26 : MP Ediciones S.A Revista Sólo Programadores : Nº18, 19,: Tower Communications. The Regency Corporation Limited en Colaboración con UIT (Unión Internacional de Telecomunicaciones): Telecomunicaciones y Salud University of California, Davis: DICOM Network Transport Protocol: Rev. 11.22.1995.0001 Beta