contenido - 148.206.53.84148.206.53.84/tesiuami/uami14448.pdf · 2.5.1.8 srs (documento de ... el...

Contenido 1 Introducción...........................................................................................................................................5

1.1 Descripción del problema...............................................................................................................6 1.2 Descripción de la solución propuesta.............................................................................................6

1.2.1 Sistema de Almacenamiento...................................................................................................6 1.2.1.1 Objetivo general:.............................................................................................................6 1.2.1.2 Objetivos específicos:.....................................................................................................6 1.2.1.3 Metodología:...................................................................................................................6

1.2.2 Estructura del documento.......................................................................................................7 2 Antecedentes..........................................................................................................................................8

2.1 PACS..............................................................................................................................................8 2.1.1 Tamaño de PACS...................................................................................................................9

2.1.1.1 Pequeño...........................................................................................................................9 2.1.1.2 Mediano........................................................................................................................10 2.1.1.3 Grande...........................................................................................................................11

2.2 DICOM.........................................................................................................................................12 2.2.1 Partes DICOM......................................................................................................................13 2.2.2 Formato de Datos DICOM...................................................................................................14 2.2.3 Niveles de Información.........................................................................................................14

2.2.3.1 Nivel de paciente...........................................................................................................15 2.2.3.2 Nivel de estudio............................................................................................................15 2.2.3.3 Nivel de serie................................................................................................................15 2.2.3.4 Nivel de imagen............................................................................................................16

2.2.4 Servicios DICOM.................................................................................................................16 2.2.5 Características.......................................................................................................................17 2.2.6 Comunicación.......................................................................................................................17 2.2.7 Roles: Service Class User (SCU) y Service Class Provider (SCP)......................................17 2.2.8 Servicios de Red de DICOM................................................................................................18 2.2.9 Definición de una Consulta (Query/Retrieve)......................................................................18

2.3 Clases SOP (service-object pair class )........................................................................................19 2.3.1 DICOM y PIXELMED.........................................................................................................19

2.4 PIXELMED..................................................................................................................................20 2.4.1 Almacenamiento...................................................................................................................21

2.5 Metodología..................................................................................................................................23 2.5.1 Metodología de Desarrollo...................................................................................................23

2.5.1.1 Modelado de Negocio...................................................................................................25 2.5.1.1.1 Modelo de Casos de Uso de Negocio....................................................................25 2.5.1.1.2 Modelo del Objeto de Negocio.............................................................................25

2.5.1.2 Visión del Proyecto.......................................................................................................25 2.5.1.3 Plan de Proyecto...........................................................................................................25 2.5.1.4 Lista de Riesgos............................................................................................................25 2.5.1.5 Glosario.........................................................................................................................26 2.5.1.6 Descripción de la Arquitectura.....................................................................................26 2.5.1.7 Modelo de Caso de Uso Inicial.....................................................................................26 2.5.1.8 SRS (Documento de requerimiento).............................................................................26 2.5.1.9 Pruebas de Aceptación..................................................................................................26 2.5.1.10 Modelo de Caso de Uso Detallado..............................................................................26

2.5.1.11 Diagrama de Clases.....................................................................................................26 2.5.1.12 Arquitectura Ejecutable a Elaborar.............................................................................26 2.5.1.13 Diagramas de Robustez...............................................................................................27 2.5.1.14 Pruebas Unitarias........................................................................................................27 2.5.1.15 Integración del sistema...............................................................................................27 2.5.1.16 Pruebas del Sistema....................................................................................................27

2.5.2 Artefactos Utilizados y Obtenidos........................................................................................27 3 Resultados............................................................................................................................................29

3.1 RUP..............................................................................................................................................29 3.1.1 Concepción...........................................................................................................................29

3.1.1.1 Modelado de negocio....................................................................................................29 3.1.1.1.1 Modelado de Casos de Uso de Negocio................................................................29 3.1.1.1.2 Modelado de Objeto de Negocio...........................................................................36

3.1.1.2 Documento de visión (Almacenamiento).....................................................................41 3.1.1.3 Lista de Riesgos............................................................................................................44 3.1.1.4 Descripción de la Arquitectura.....................................................................................45 3.1.1.5 Modelo de Caso de Uso Inicial.....................................................................................46

3.1.2 Elaboración...........................................................................................................................47 3.1.2.1 Documento de Especificación de Requerimientos de la Estación de Almacenamiento (SRS)..........................................................................................................................................47 3.1.2.2 Detalle de Casos de Uso...............................................................................................48

3.1.2.2.1 BUSDAT - 1 Buscar datos....................................................................................48 3.1.2.2.2 RECDAT – 2 Recuperar datos..............................................................................50 3.1.2.2.3 ALMDAT – 3 Almacenar datos............................................................................52

3.1.2.3 Modelo de Casos de Uso Detallado..............................................................................54 3.1.2.4 Diagrama de Clases.......................................................................................................55 3.1.2.5 Arquitectura Ejecutable................................................................................................56

3.1.3 Construcción.........................................................................................................................57 3.1.3.1 Diagrama de Robustez..................................................................................................57

3.1.4 Transición entre la metodología de desarrolla y las pruebas con Pixelmed.........................59 3.1.5 Implementación del Almacenamiento Pixelmed..................................................................59

4 Conclusiones........................................................................................................................................64 4.1 GLOSARIO..................................................................................................................................65

5 Apéndice..............................................................................................................................................67 5.1 Definiciones de SCP Y SCU........................................................................................................67

5.1.1 ECHO-SCP...........................................................................................................................67 5.1.2 STORAGE-SCP...................................................................................................................67 5.1.3 STORAGE-SCU...................................................................................................................67 5.1.4 FIND-SCU............................................................................................................................67 5.1.5 MOVE-SCU.........................................................................................................................67 5.1.6 QUERY-SCP........................................................................................................................67 5.1.7 RETRIEVE-SCP..................................................................................................................67

5.2 Documento de Visión (general del PACS)...................................................................................68 5.2.1.1 Documento de Especificación de Requerimientos (SRS) del PACS............................72

5.3 Descripcion de la arquitectura......................................................................................................74 5.4 Zeroconf.......................................................................................................................................75 5.5 Bonjour.........................................................................................................................................75 5.6 Paquete com.pixelmed.network ..................................................................................................76

5.6.1 Clase NetworkConfigurationFromMulticastDNS................................................................76

5.6.1.1 Métodos de la clase.......................................................................................................76 5.6.1.1.1 void activateDiscovery ( int refreshInterval)........................................................76 5.6.1.1.2 void deActivateDiscovery ().................................................................................76 5.6.1.1.3 void registerDicomService (String calledApplicationEntityTitle, int port, String primaryDeviceType).............................................................................................................76 5.6.1.1.4 void registerWADOService(String instanceName, int port, String path).............76

5.6.1.2 Constructor NetworkConfigurationFromMulticastDNS(int debugLevel) ...................76 5.7 Archivos Jar..................................................................................................................................77 5.8 Archivo Properties sistema de Visualización...............................................................................77 5.9 Archivo Properties Almacenamiento...........................................................................................77

6 Bibliografía..........................................................................................................................................78

1 Introducción

Hoy en día los estudios radiológicos son de suma importancia para el diagnóstico clínico, entre estos estudios tenemos ultrasonidos, tomografías, resonancias magnéticas, densitometrías óseas y rayos X. Los resultados de estos estudios generan imágenes que son impresas en placas radiográficas las cuales formaran parte del expediente médico de un paciente.

El manejo de estos expedientes puede convertirse en un problema debido al espacio de almacenamiento requerido y se puede suscitar la pérdida de los expedientes lo cual ocasionaría la repetición de los estudios. Esto nos da como resultado poca eficiencia en el servicio, con lo que se brinda una pobre atención al paciente (puede llegar a afectar al paciente a largo plazo la toma excesiva de estos estudios radiológicos) y los costos se elevarían.

La propagación de la tecnología digital en el campo médico se ha acelerado en los últimos años. En este campo, y en especial en el área de radiología por lo que una solución para esta clase de problemas seria la aplicación de tecnología digital mediante la implementación de un sistema de archivos y comunicación de las imágenes por medio de una red de imagenología mejor conocido como PACS (Picture Archiving and Communication System). Esta tecnología consiste de dispositivos de adquisición de imágenes, unidades de almacenamiento, estaciones de despliegue, procesadores y bases de datos.

Este sistema nos permitiría la comunicación entre los principales equipos electromédicos, con la información obtenida crearíamos expedientes digitales de los pacientes, los resultados ya no serian en placas sino en forma digital, con lo cual tendríamos una mejor asistencia en el diagnóstico médico, generando diagnósticos de una mayor calidad.

Figura 1: Comparación entre método tradicional de almacenamiento y la implementación de un PACS

Este proyecto forma parte de un proyecto mas grande dividido en dos sistemas (Almacenamiento y Visualización). Aquí se trabajo con el sistema de Almacenamiento el cual consta de un servidor de almacenamiento que provee una base de datos con soporte de búsqueda y recuperación.

Debido a que esta dividido en dos partes, el contenido de los dos reportes en ciertas partes es el mismo, principalmente en la sección de Antecedentes. Esto se debe a que la investigación previa se realizo en conjunto y para el mismo proyecto (PACS).

1.1 Descripción del problema

La administración de los expedientes de los pacientes y los resultados de sus estudios asociados, así como la visualización de los mismos, generan gastos innecesarios, debido al almacenamiento e impresión de los resultados, afectando a los médicos, y principalmente a los pacientes, ya que se les ofrece una atención médica deficiente.

1.2 Descripción de la solución propuesta

La implementación de un sistema que permita tener toda la información en un mismo lugar (Sistema de almacenamiento) y de forma digital, para que la administración de los expedientes sea de forma mas eficiente, así como la visualización de los estudios realizados a los pacientes (Sistema de visualización). El sistema de visualización se trata en la otra parte del proyecto general.

1.2.1 Sistema de AlmacenamientoA continuación se presentan los objetivos generales y específicos del sistema

1.2.1.1 Objetivo general:1) Implementar un sistema para el almacenamiento de expedientes médicos

1.2.1.2 Objetivos específicos:1) El sistema debe de proveer una base de datos para el almacenamiento

2) Debe soportar la consulta/recuperación (query/retrieve) de archivos DICOM

1.2.1.3 Metodología:Basados en Ingeniería de Software para comprender todos los aspectos de la producción de software desde las etapas iniciales de la especificación del sistema, hasta el mantenimiento de este después de que se utiliza. Ademas apoyándonos en el Proceso Unificado Rational (RUP), ya que nos proporciona un conjunto fundamental de filosofías y prácticas para un desarrollo de software exitoso. Mas adelante se describirá este proceso.

1.2.2 Estructura del documento

La primera parte de este documento es una pequeña introducción al problema general a tratar, esto dentro de los antecedentes de estudios e investigación realizados para la implementación de este sistema de Almacenamiento. En la primera sección se presentan varias subsecciones, empezando por la descripción del concepto de PACS, sus características y tamaños. Cabe mencionar que este trabajo esta basado en el concepto de PACS pequeño y su Sistema de Almacenamiento.

Posteriormente se presenta una una amplia descripción del protocolo de comunicación que utilizan estos sistema, llamado DICOM. Se mencionan las partes que conforman este protocolo, niveles de información, así como los servicios que brinda y características generales.

Se presenta una pequeña comparación entre DICOM y PIXELMED, para después dar una explicación la herramienta PIXELMED así como los paquetes (packages) y las clases que nos provee para el desarrollo de PACS y mas específicamente las clase que son utilizadas por el Sistema de Almacenamiento.

Para finalizar esta sección se hace una descripción de la metodología utilizada (RUP) para la implementación del sistema en cuestión y los pasos a seguir para tener éxito en el desarrollo del sistema.

La segunda sección presenta los resultados obtenidos en cada fase de desarrollo. Estos resultados están basados la metodología antes mencionada. Esta también está dividida en varias subsecciones empezando por los resultados y documentos obtenidos en la fase de Concepción, después se presenta la fase de Elaboración y finalmente la fase de Construcción que es la ultima que se describe en este documento.

La última sección de este documento es la conclusión, en la cual se plasma la experiencia y comentarios sobre el proyecto.

Anexo a este documento se presenta la parte de Apendeice y Glosario.

2 Antecedentes

2.1 PACS

En los últimos 100 años, las placas han sido el medio exclusivo para capturar, almacenar y mostrar imágenes radiológicas. La placa es relativamente un medio fijo, generalmente con solo un grupo de imágenes disponibles. La tecnología de los PACS permite un proceso de placas con toda la flexibilidad de un sistema digital. Esto eliminaría todos los costos asociados con las placas y liberaría espacio valioso usado para almacenaje.

Un PACS es un sistema que adquiere, transmite, almacena, recupera y despliega imágenes digitales y la información de un paciente relacionada con una variedad de imágenes (obtenidas de estudios) y comunica la información sobre una red. Permiten qué imágenes, como rayos x y exploraciones, sean almacenadas electrónicamente y vistas en pantallas, de modo que doctores y otros especialistas puedan acceder a la información y compararla con imágenes previas.

Los PACS han sido desarrollados con el propósito de proveer un almacenamiento económico, una rápida recuperación de imágenes, acceso a imágenes adquiridas con múltiples modalidades, y acceso simultaneo en varios sitios.

La entrada de un PACS puede venir de una fuente digital o análoga. La estructura de los PACS consiste primariamente de un dispositivo de adquisición de imagen, un sistema administrador de datos, dispositivos de almacenado de imágenes, una red de transmisión, estaciones de visualización y dispositivos para producir imágenes en placas.

Los PACS traen cambios en cualquier lugar donde se utilizan imágenes medicas, ya que no solo se manejaran imagines de radiografías, sino que se ocupara de una amplia gama de las especialidades medicas, incluyendo la radioterapia, CT, MRI, medicina nuclear , angiografía, cardiología, fluoroscopia, ultrasonido, mamografía sintomática, resonancias magnéticas, tomografías, endoscopía, etc.

La arquitectura de un PACS consta principalmente de un servidor el cual en almacena una base de datos donde se tienen las imágenes y estaciones de visualización. En general los PACS se pueden dividir en tres tamaños (pequeño, mediano y grande).

2.1.1 Tamaño de PACSComo se mencionó anteriormente, los PACS pueden ser de tres tamaños. Estos difieren en la cantidad de elementos que los conforman. A continuación se explicara brevemente cada uno de los tamaños antes mencionados.

2.1.1.1 PequeñoEste tipo de PACS consta de la modalidad (para realizar la adquisición de la imagen tal como los RX y los ultrasonidos), de una estación de visualización (Sistema de visualización) y un sistema de almacenamiento.

Los PACS pequeños se utilizan principalmente en consultorios particulares.

Figura 2: PACS Pequeño

2.1.1.2 MedianoLos PACS medianos son mas completos que los anteriormente descritos, ya que ademas de las partes mencionadas, tenemos un servidor de almacenamiento y el sistema de almacenamiento, con esto obtenemos un servicio mas eficiente de imágenes y la fácil recuperación de archivos. Este tipo de PACS soporta el uso de modalidades mas complejas, por ejemplo, tomógrafos, equipo para resonancias magnéticas.

Figura 3: PACS Mediano

2.1.1.3 GrandeLos PACS grandes cuentan con la misma estructura que los PACS medianos, pero añaden nuevos componentes, se tiene un administrador de procesos, una descripción radiológico, incluye un servidor WEB, el cual permite tener acceso remoto a redes de PACS y así poder recuperar y visualizar archivos y expedientes médicos en cualquier lugar del mundo.

Figura 4: PACS Grande

2.2 DICOM

DICOM es el estándar en Imagen Digital y Comunicaciones en Medicina, que describe detalladamente los medios y mecanismos para dar formato e intercambiar imágenes e información entre diferentes dispositivos.

Surge para promover la comunicación entre imágenes digitales independientemente del fabricante que las hizo, para ofrecer mayor flexibilidad a los sistemas de almacenamiento y comunicación de imágenes y para facilitar la creación y consulta a sistemas de diagnostico por diferentes dispositivos y en diversos lugares locales o remotos.

Se ve entonces, la gran importancia de este estándar, ya que da la posibilidad de interconectar sistemas informáticos de diferentes fabricantes y hace posible que se comuniquen entre sí, lo que en un hospital, donde los aparatos médicos son de muchas marcas diferentes, debido a la especialización, es tremendamente interesante y necesario.

La estandarización de archivos médicos hace posible que, mediante una transmisión segura, los datos de los pacientes puedan viajar de departamento en departamento, de hospital en hospital, lo que hace que esa información pueda ser vista remotamente de la zona de adquisición de las imágenes. Esto permite que los médicos puedan diagnosticar desde su casa, buscar diferentes opiniones de otros médicos expertos de una forma sencilla y rápida, dar un orden y estructura a los datos más efectivo y seguro, y muchos otros tipos de ventajas.

Figura 5: Comunicación entre distintos dispositivos mediante el protocolo DICOM

2.2.1 Partes DICOM

El estándar DICOM está dividido en varias partes, cada una de ellas describiendo una cuestión importante tal como las Clases de Servicio, los IODs, temas relacionados con Network y Media, etc. En la siguiente figura se ve una visión general de la relación entre las diferentes partes.

Las partes en las que se divide DICOM son:

1. Introducción y resumen

2. Conformidad (conformance)

3. Definición de objetos de información(Information Object Definitions)

4. Especificaciones de las clases de servicio(Services class Specification)

5. Estructura de datos y codificación(Data Structure and encoding)

6. Diccionario de datos(Data Dictionary)

7. Intercambio de mensajes(Message Exchange)

8. Soporte de Comunicación de Red para intercambio de mensajes(Network Communication Support for Message Exchange)

9. Almacenado de los medios y formato del archivo para el intercambio de los datos(Media Storage and File Format for Data Interchange)

10. Media Storage Application Profiles

11. Funciones del almacenaje y formatos de los medios para el intercambio de los datos (Storage Functions and Media Formats for Data Interchange)

12. Grayscale Standard Display Function

13. Perfiles de administración del sistema y seguridad(Security and System Management Profiles)

14. Content Mapping Resource

15. Explanatory Information

16. Acceso Web a los objetos persistentes de DICOM (Web Access to DICOM Persistent Objects)

2.2.2 Formato de Datos DICOM

Un objeto de datos DICOM consiste en un número de atributos, tales como, nombre, ID, etc, y un atributo especial, que contiene datos del pixel de la imagen. Un objeto DICOM puede únicamente contener una imagen, pero la imagen puede ser multiframes, para permitir el almacenamiento de “cine loops” u otro dato multiframe.

Los datos de la imagen pueden ser comprimidos usando una variedad de estándares, estos incluyen: JPEG, JPEG Lossless (sin perdida), JPEG 2000 y RLE.

2.2.3 Niveles de Información

El modelo de información de imagen DICOM es un modelo que representa la información de una forma estructurada, en pocas palabras, es un modelo de información. Son cuatro niveles de este modelo: paciente, estudio, serie e imagen.

Figura 6: Partes del Protocolo DICOM

2.2.3.1 Nivel de pacienteEl nivel de paciente contiene la identificación e información que pertenece al paciente. Este nivel es el más alto debido a que puede existir más de un estudio. Sin embargo, es normal usar el nivel del estudio para recoger la información manejada por varios sistemas para una única respuesta a este estudio.

2.2.3.2 Nivel de estudioEl nivel de estudio es el nivel más importante en el modelo de información. Un estudio es el resultado de una contestación a un cierto tipo de examen médico. Todas las actividades en un departamento de radiología se centran en el manejo correcto del estudio. En un estudio, la información de identificación se guarda y puede contener referencias a información relacionada al mismo estudio.

En general, una respuesta puede envolver procedimientos de diferentes máquinas. Esto da lugar a una serie de una o más imágenes, dependiendo del protocolo definido por el examen realizado. Todos los datos son recogidos juntos en el mismo estudio principal. Un paciente puede tener muchos estudios como resultado de haberse realizados otros anteriormente. Después del nivel de estudio todas las imágenes se recogen y almacenan.

2.2.3.3 Nivel de serieEl nivel de serie identifica el tipo de aparato que crea las imágenes, la fecha y el tiempo de creación de la serie y los detalles del tipo de examen realizado y del equipo usado. Las series siempre son una colección de imágenes que provienen de una único aparato. La forma en que las imágenes están agrupadas en series depende del uso médico que se les va a dar.

Otro criterio para agrupar imágenes puede ser tomar los datos de una parte específica del cuerpo, hecho durante un estudio completo. Por ejemplo, cuando un aparato produce un número de imágenes de alguna parte de un paciente desde diferentes posiciones y momentos, las imágenes pueden ser agrupadas en una serie. También, en una serie, una imagen de referencia puede ser incluida como una descripción de la posición espacial de las partes individuales.

Figura 7: Los cuatro niveles de información

2.2.3.4 Nivel de imagenEl nivel más bajo del modelo de información es el nivel de imagen. Cada imagen contiene la información de adquisición y posicionamiento al igual que los datos propios de la imagen. Dependiendo del tipo de aparato, el nivel de imagen contiene datos para una sólo imagen, dos imágenes o una colección de imágenes tomadas en un corto espacio de tiempo (multiframe).

2.2.4 Servicios DICOM• Almacén(Store)

• Almacenado(Storage commitment)

• Consulta/Recuperación(Query/Retrieve)

• Modalidades (Modality Worklist)

• Modality Performed Procedure Step

• Impresión (Printing)

• Medios Off-line(Archivos DICOM)

Figura 8: Descripción de la posición espacial de las partes individuales

2.2.5 Características• Intercambiabilidad de objetos en redes de comunicación y en medios de almacenamiento a

través de protocolos y servicios, manteniendo independencia de la red y del almacenamiento.

• Especificación de diferentes niveles de compatibilidad..

• Información explícita de Objetos a través de estructuras de datos, que facilitan su manipulación como entidades autocontenidas.

• Identidad de objetos en forma única

• Flexibilidad al definir nuevos servicios.

• Interoperabilidad entre servicios y aplicaciones a través de una configuración definida por el estándar, manteniendo una comunicación eficiente entre el usuario de servicios y el proveedor de los mismos.

2.2.6 Comunicación• DICOM utiliza el modelo de capas para representar conexiones virtuales entre diferentes

plataformas de cómputo, utilizando protocolos de comunicación.

• Para establecer una conexión virtual, los dispositivos que se quieren comunicar deben utilizar los mismos protocolos en cada capa.

• DICOM permite la conexión en red utilizando como base los protocolos TCP/IP (Transmission Control Protocol/Internet Protocol) y los propuestos por ISO/OSI (International Standards Organization/Open Systems Interconnection).

• De esta forma se aprovechan los protocolos definidos en las capas inferiores tanto de TCP/IP como de ISO/OSI y define los protocolos necesarios en las capas superiores para soportar la comunicación entre aplicaciones en forma eficiente.

• En el caso de ISO/OSI, aprovecha los servicios de las primeras 6 capas. Para el caso de TCP/IP, especifica un protocolo de capa superior DUL (DICOM Upper Layer). Para ambos casos se definen un protocolo para aplicaciones DICOM, que permite la portabilidad entre ambos ambientes sin afectar las aplicaciones ya realizadas.

2.2.7 Roles: Service Class User (SCU) y Service Class Provider (SCP)Para comprender que es un SCU y un SCP, pensemos en DICOM como un modelo cliente-servidor, el cliente seria SCU y el servidor SCP, por lo que SCU solicitaría algún servicio de SCP y este se lo proveería. Los roles SCP y SCU se refieren a los servicios específicos que existen en el momento y no en la arquitectura general.

Una entidad DICOM comúnmente puede actuar en varios roles de servicios de clases, ya sea como usuario o proveedor, y muy frecuentemente como los 2. A continuación se explicaremos como interactuan la SCP y la SCU en cada clase de servicio:

• Verificación (Verifcation Service Class): Es una forma de determinar si una entidad DICOM esta activa y puede ser comunicada en la red. La SCU realiza esta verificación y la SCP, si esta activa, provee una respuesta.

• Almacenamiento (Storage Service Class): Cada clase SOP de almacenamiento maneja

solamente un tipo de imagen en particular. Cuando la SCU solicita que una imagen sea almacenada, realmente solo solicita que la SCP reciba la imagen. La SCP no garantiza alguna duración o seguridad de almacenamiento, solamente acepta la imagen del remitente.

• Query/Retrieve (Query/Retrieve Service Class): Provee dos distintos servicios: FIND y MOVE. FIND, SCU solicita información (ID estudio, etc) sobre imágenes que el proveedor tiene disponible. SCP responde con la información solicitada. Se puede dar el caso de que SCU solicite la imagen para una tercera entidad. MOVE en SCP también puede ser un SCU de almacenamiento (SSC) para enviar la imagen al destino.

2.2.8 Servicios de Red de DICOMDebe soportar SCU y SCP con sus funciones:

• SCHO SCU

• Query/Retrive SCU

• Storage SCU

• Storage SCP

2.2.9 Definición de una Consulta (Query/Retrieve)Query/Retrieve (Consulta/Recuperación) es el proceso por el cual los dispositivos DICOM solicitan información de una Base de Datos y recupera datos e imágenes que solicite para formar una asociación, el Query/Retrieve local SCU se conecta con un Query/Retrieve SCP remoto.

Esto funciona básicamente es de la siguiente forma:

El cliente SCU realiza un Query/Retrieve, enviando una solicitud ( de manera remota) al proveedor SCP, el cual responde mandando una lista de pacientes. El cliente selecciona el paciente requerido (el paciente tiene un ID único). De esta forma el proveedor SCP responde la solicitud y envía el dato solicitado al almacenamiento local para ser usado por el SCU.

Figura 9: Flujo de datos en una operación Query/Retrieve

Antes de realizar una operación query/retrieve se necesita decirle al dispositivo SCP donde serán enviados los archivos.

2.3 Clases SOP (service-object pair class )

El objeto de información y la clase de servicio son dos componentes fundamentales de DICOM. Los objetos de información definen el contenido del núcleo de la imagen medica, y las clases de servicio definen que se va a hacer con ese contenido.

Las clases de servicio y los objetos de información se combinan para formar unidades funcionales de DICOM. Esta combinación es llamada service-object pair (SOP), y como DICOM es un estándar orientado a objetos esta combinación es llamada actualmente service-object pair class (SOP class) ademas de que es la unidad fundamental de DICOM.

Combinar un servicio y un objeto de información es directo, por ejemplo, DICOM define una serie de clases SOP de almacenamiento (CT image storage SOP class, MR image storage SOP class). La definición objeto de información CT y la clase de servicio de almacenamiento (storage service class) son combinadas para formar la clase SOP CT image storage, de forma similar otras clases SOP de almacenamiento son formadas.

2.3.1 DICOM y PIXELMED

Como ya se ha explicado anteriormente, DICOM es un estándar utilizado en equipo médico para facilitar las comunicaciones. Este protocolo no es de fuente libre y es muy caro, por esta razón se busco una herramienta que fuera mas accesible económicamente.

La solución a este problema fue PIXELMED, que es una librería open source que nos provee una implementación de DICOM. Por ser open source la implementación de esta herramienta es económica ya que los costos se pueden elevar demasiado implementando DICOM.

2.4 PIXELMEDEs una librería de fuente libre, la cual esta basada en las partes de DICOM. Pixelmed tiene varias clases divididas en packages de acuerdo a la función que realizan, éstas nos ayudan a hacer entre otras cosas al almacenamiento de imágenes y consultas de las mismas en una base de datos. También nos brinda una implementación para la parte de visualización así como de comunicación remota, esto permite la interacción entre fuente y destino de las imágenes. Parte de las implementaciones hechas en Pixelmed son:

Package Descripcióncom.pixelmed.database Abstracciones de algunos fundamentos de bases de datos para

aplicaciones que usan DICOM y necesitan acceso para almacenamiento persistente de entidades en el modelo de información DICOM

com.pixelmed.dicom Contiene clases para construir, escribir, leer y manipular objetos DICOM.

com.pixelmed.display Contiene clases para hacer el despliegue de objetos DICOM.

com.pixelmed.display.event Contiene clases relacionadas con el despliegue y navegación a través de imágenes.

com.pixelmed.displaywave Contiene clases para desplegar ondas ECG “waveforms”, incluyendo DICOM y SCP-ECG file.

com.pixelmed.event

com.pixelmed.geometry Contiene clases para hacer manipulación geométrica de imágenes.

com.pixelmed.network Contiene clases para hacer la comunicación a través de la red de trabajo.

com.pixelmed.query Contiene interfaces y clases que encapsulan los query/retrieve que soportan la consulta con la base de datos que contiene objetos DICOM.

com.pixelmed.scpecg Contiene clases para hacer lectura de archivos SCP-ESG.

com.pixelmed.server Contiene una clase que provee acceso Web a objetos DICOM.

com.pixelmed.transfermonitor Contiene clases que heredan de InputStream, OutputStream, FilterOutputStream para seguir estadísticas en las transferencias.

com.pixelmed.utils Implementa clases con métodos principalmente.

com.pixelmed.validate Un paquete para validar casos compuestos contra el DICOM correspondiente IOD estándar.

com.pixelmed.web Implementa acceso Web a objetos DICOM como se define en DICOM PS 3.18 (ISO 17432).

Para este proyecto la investigación se basara solo en las siguientes partes:

Adquisición

Visualización

Almacenamiento

Solo se hablará de los concernientes a la parte del Almacenamiento de imágenes.

2.4.1 AlmacenamientoPara el almacenamiento en Pixelmed se usa el package com.pixelmed.database que soporta aplicaciones DICOM y necesidades de acceso para persistir el almacenamiento de entidades en el modelo de información de DICOM. La clase principal de este package es DatabaseInformationModel que es una clase abstracta. Esta clase contiene el núcleo funcional para el almacenamiento, acceso y mantiene la persistencia de los objetos, esto es, crear tablas, insertar, modificar y eliminar, mantiene una representación persistente de los atributos de los objetos, además de almacenarlos en tablas.

A continuación se describen las clases pertenecientes a este package:

Clases DescripciónDatabaseApplicationProperties Esta clase provee acceso común a las aplicaciones que requieren

propiedades relacionadas a los servicios de las BD.

DatabaseInformationModel Es una clase abstracta que contiene el núcleo funcional para el almacenamiento, accesando y manteniendo una representación persistente de los atributos seleccionados de los objetos compuestos.

DatabaseMediaImporter

DatabaseTreeBrowser Implementa una interfaz gráfica Swing para desplegar el contenido de DatabaseInformationModel

DatabaseTreeModel Implementa un TreeModel para abstraer el contenido de una base de datos como en un árbol en orden para proveer soporte para un DataBaseTreeBrowser

DatabaseTreeRecord Las instancias de esta clase representan nodos en un árbol de la clase DatabaseTreeModel, la cual es usada por la clase DatabaseTreeBrowser

DateTimeRangeMatch

DicomDatabaseInformationModel Es una clase abstracta que especializa el DatabaseInformationModel añadiendo métodos específicos a un objeto compuesto DICOM del modelo de información.

DicomDictionaryForPatientStudySeriesConcatenationInstanceModel

Soporta un simple modelo DICOM Patient/Study/Series/Concatenation/Instance

DicomDictionaryForStudySeriesInstanceModel

Soporta un mínimo modelo DICOM Study/Series/Instance

MapTableBrowser Hereda de un Jtable para buscar una lista de atributos y sus valores como una fila de tabla con columnas encabezadas por la descripción de atributos o sus nombres

PatientStudySeriesConcatenationInstanceModel

Soporta un modelo DICOM Patient/Study/Series/Concatenation/Instance.

RebuildDatabaseFromInstanceFiles Permite la reconstrucción de la base de datos desde las instancias de de los archivos almacenados, por ejemplo cuando el esquema de la BD ha sido cambiado.

StudySeriesInstanceModel Soporta un modelo DICOM mínimo Study/Series/Instance.

StudySeriesInstanceSelectiveMatchModel Soporta un modelo DICOM mínimo Study/Series/Instance

Con este paquete no se trabajo ya que las clases implementadas aquí son utilizadas por la clase que implementa el servidor de almacenamiento DicomAndWebStorageServer del paquete com.pixelmed.server que nos permite hacer las conexiones locales y remotas entre el almacenamiento y el visualizador.

DicomAndWebStorageServer Implementa un servidor de almacenamiento DICOM, provee una base de datos, consulta y recuperación DICOM (query/retrieve) así como un servidor http que responde a peticiones web incluyendo WADO. Es invocado para ejecutar el DICOM Storage SCP.

Almacena los archivos en un directorio especifico.

2.5 MetodologíaPara tener un mejor desarrollo de cualquier sistema en un proyecto se emplean metodologías de desarrollo, que es un conjunto de métodos nos nos indica la forma y en ocasiones el tiempo para un sistema de software.

2.5.1 Metodología de DesarrolloEl modelo de desarrollo utilizado para elaborar este sistema es RUP (Rational Unified Process). Esta metodología (proceso de desarrollo) se divide en fases y en cada una de esas faces hay disciplinas en las cuales se realizan distintas actividades, las cuales producen distintos artefactos (documentos).

A continuación se describen las fases de este modelo y una breve descripción:

• Concepción: Se definen claramente los alcances del proyecto.

• Elaboración: Se establece una arquitectura para el sistema.

• Construcción: Se desarrolla el sistema sobre la arquitectura.

• Transición: Se realiza la transferencia del sistema a usuarios finales.

A lo largo de las fases se realizan un cierto número de disciplinas listadas a continuación:

• Modelado de negocio

• Requerimientos

• Análisis y diseño

• Implementación

• Pruebas

• Administración de configuración y cambios

Figura 10: El proceso unificado Rational (RUP)

• Administración del proyecto

Y a su vez cada una de estas disciplinas arroja ciertos artefactos, que no siempre son los mismos debido a que las necesidades de documentación varían a medida que se avanza en el desarrollo del proyecto.

Los artefactos principales de la fase de Concepción son, por dar un ejemplo:

• Modelo de negocio

• Visión del proyecto

• Plan del proyecto

• Lista de riesgos

• Descripción de la arquitectura

• Glosario

• Modelo de casos de uso inicial

Los artefactos principales de la fase de Elaboración son:

• SRS (Documento de requerimiento)

• Modelo de casos de uso detallado

• Pruebas de aceptación

• Diagrama de clases

• Arquitectura ejecutable

• Implementación de pruebas de desarrollo

Los artefactos principales de la fase de Construcción son:

• Realizar diagramas de robustez

• Pruebas unitarias para cada caso de uso

• Integración del sistema

• Pruebas del sistema

Los artefactos principales de la fase de Transición son:

• Entrega del software

• Pruebas del sistema realizadas por usuarios finales

A continuación se explicara algunos de los documentos que se obtiene en cada una de las fases, empezando por el Modelado de Negocio, siendo este documento muy importante debido a que este nos permite obtener una visión clara de el funcionamiento de una empresa y tener éxito al generar el sistema.

2.5.1.1 Modelado de Negocio

Los Modelos de Negocio permiten visualizar la forma de operar de una empresa así como las necesidades de los usuarios del sistema a desarrollar. Al no aplicar este modelo en la primera etapa del desarrollo de un sistema de software se corre el riesgo de no tener la calidad requerida por el cliente debido a que no se tiene el suficiente conocimiento del negocio en el cual se va a utilizar el sistema.

El Modelo de Negocio puede ser definido como la abstracción de los elementos de organización y las relaciones entre ellos. Esto es muy importante en la medida de que se podría hacer una transición entre el modelo de negocio y el modelo de caso de uso, lo podríamos ver como una introducción al análisis de requerimientos y para desarrollar un sistema de software.

Este modelo consta de dos partes importantes, Modelado de Caso de Uso del Negocio y Modelo de Objeto de Negocio.

2.5.1.1.1 Modelo de Casos de Uso de NegocioEn esta parte del modelado, se representa el QUE hace el negocio. Para este modelo se empieza por hacer un diagrama de Casos de Uso, el cual sirve para entender totalmente el propósito del negocio. Se usan al igual que en el diagrama de casos de uso para actores de software y sus correspondientes casos de uso, que en este caso los actores serias las personas externas al negocio que interactuan con una parte de el y los casos de uso serian del la empresa en general. En estos casos de uso de negocio solo se pondrán los flujos relacionados con los actores de negocio (personas externas). Para representar el flujo que se da en cada caso de uso se utiliza un diagrama de actividad.

2.5.1.1.2 Modelo del Objeto de NegocioA diferencia del modelo de casos del negocio que nos dice QUE hace el negocio, en este modelo nos dice COMO se hace el negocio. Se hace con ayuda del diagrama de robustez, en este caso se modelan las personas internas del negocio llamadas WORKERS y su interacción con las entidades del negocio.

Posteriormente se hará nuevamente una representación de los flujos de trabajo de este diagrama con ayuda nuevamente de diagrama de actividad.

2.5.1.2 Visión del ProyectoEs el documento donde se plantean las expectativas de los involucrados sobre el sistema, de tal manera que no existan confusiones en el desarrollo del mismo. Especificado en términos de necesidades y características.

2.5.1.3 Plan de ProyectoEste artefacto recopila toda la información requerida para manejar el proyecto en forma calendarizada, principalmente sirva para tener una estimación del tiempo que se llevara la elaboración de cada una de las partes del proyecto, hablando de cada fase y los artefactos arrogados en cada una de ellas.

2.5.1.4 Lista de RiesgosEs una lista sobre los riesgos en el proyecto, clasifica en orden de importancia y asociados acciones específicas de la mitigación o de la contingencia de los riesgos.

2.5.1.5 GlosarioEs documento es importante debido a que especifica los términos que son usados en el proyecto. Estos términos son especificados con la colaboración de personal involucrados y miembros de equipo de desarrollo.

2.5.1.6 Descripción de la ArquitecturaEste documento se refiere a dar un pequeño esbozo de la arquitectura.

2.5.1.7 Modelo de Caso de Uso InicialRepresenta los comportamientos de alto nivel que el sistema debe cubrir. El sistema de casos de uso muestra las relaciones entre actores y casos de uso del sistema, permite tener una representación visual del sistema, funcionalidades y sus interacciones.

Para la fase de elaboración:

2.5.1.8 SRS (Documento de requerimiento)La documentación de los requerimientos es una actividad fundamental ya que de ella dependerá la calidad del sistema. Se propone que se realice en varias iteraciones que inician en la concepción y se prolongan hasta la construcción, pero es en la elaboración donde es documentado de una manera mas amplia y con detalle para cada uno de los casos de uso, esto es porque se da una explicación de cada uno de ellos.

2.5.1.9 Pruebas de AceptaciónSon las instrucciones que validan individualmente el funcionamiento del software según las especificaciones.

2.5.1.10 Modelo de Caso de Uso DetalladoAlgunos de los casos de uso obtenidos de los requerimientos representan varios casos de uso de forma simultanea, por lo que en el modelo de casos de uso inicial no es posible describir los diversos flujos en el flujo principal, por lo que es necesario introducir nuevos casos de uso que separen los flujos. Para realizar este modelo se debe de cuidar de no realizar varias separaciones ademas de evitar la aparición de nuevas asociaciones.

2.5.1.11 Diagrama de ClasesEste diagrama sirve para realizar el modelo de dominio del problema, ya que nos permite representar clases, sus miembros y las relaciones que existen entre clases (o asociaciones) dándonos una vista estática del problema.

2.5.1.12 Arquitectura Ejecutable a ElaborarEn la fase de elaboración se debe contar con una arquitectura ejecutable, esto es que tenga los casos de uso básico para que la arquitectura se funcional, aunque el sistema no tenga la funcionalidad necesaria.

En la parte de Construcción

2.5.1.13 Diagramas de RobustezEsto son diagramas que representan los caso de uso de manera mas detalla, así como su funcionalidad de una manera gráfica. En este diagrama identificamos los objetos de frontera (interfaz) y de servicio (control). Estos diagramas muestran los objetos y mensajes que se intercambian de forma secuencial.

2.5.1.14 Pruebas UnitariasForman parte de las actividades de verificación y validación que se utilizan para comprobar que el sistema esta acorde con su especificación y no presenta defectos, esto se hace solo a cada caso de uso por separado.

2.5.1.15 Integración del sistemaEsto se hace cuando al sistema se le ha aplicado las pruebas a cada uno de los casos de usos.

2.5.1.16 Pruebas del SistemaEstas se realizan sobre el sistema ya integrado y son realizadas generalmente por los usuarios finales. Estas pruebas suelen ser menos rigurosas que las pruebas unitarias.

2.5.2 Artefactos Utilizados y Obtenidos

Los artefactos obtenidos y utilizados en este proyecto fueron:

Fase de Concepción

• Modelo del negocio

• Documento de visión

• Plan del Proyecto (Pendiente)

• Lista de riesgos

• Descripción de la arquitectura

• Glosario

• Modelo de casos de uso inicial

Fase de Elaboración:

• SRS (Documento de requerimiento)

• Modelo de casos de uso detallado

• Diagrama de clases

• Pruebas de aceptación

• Arquitectura ejecutable

Fase de Construcción son:

• Diagramas de robustez

• Integración del sistema

• Pruebas del sistema

3 ResultadosLos primeros resultados obtenidos son sobre la metodología de desarrollo, debido a que es el primer paso para obtener información sobre cualquier tipo de negocio.

3.1 RUPEn modelado es donde se describe la relación entre el sistema y los usuarios finales, como se mencionó antes. Los resultados obtenidos en sus diferentes fases fueron los siguientes:

3.1.1 ConcepciónEn esta fase se elaboró el documento de visión que cuenta con el siguiente contenido:

3.1.1.1 Modelado de negocioComo anteriormente se planteo, lo primero que se tiene que hacer es el modelado de casos de uso de negocio.

3.1.1.1.1 Modelado de Casos de Uso de NegocioSe realiza un diagrama de casos de uso (Figura 12) donde se muestra la estructura de un hospital vista del lado del paciente que es la parte externa del negocio. En este diagrama se muestra dicha interacción:

Figura 11: Modelo de Casos de Uso de Negocio

System

Paciente

Atender al paciente

Realizar estudios (modalidades)

Dar de alta al paciente

Obtener expediente del paciente

Atender y canalizar al paciente para estudio

Dar tratamiento a paciente

Asignar cita para consulta al paciente

Esto quiere decir, que se deben de realizar los siguientes pasos:

1) El paciente debe de ser dado de alta en el hospital

2) Se le debe de asignar cita, para que se le realice la consulta

3) Se debe atender al paciente, para asignarle un estudio, respecto a su diagnostico. Para esto se debe obtener su expediente, canalizarlo a su estudio.

4) Realizar estudios en la modalidad correspondiente

5) Dar tratamiento, en base a sus estudios

Este modelo nos da una visión general del negocio, por lo que se realiza un nuevo modelo de casos de uso del negocio pero refinado (Figura 13), el cual muestra con mas detalle y de una forma mas especifica la estructura de un hospital:

Figura 12: Modelado de Casos de Uso Refinado. Este esta figura nos muestra la interacción de actor externo y el negocio.

De cada caso de uso se realizó un diagrama de actividad, siguiendo el Modelado de Negocio. Estos diagramas se hacen solo con los actores externos al negocio, dando como resultado los siguientes diagramas:

DarAltaPaciente: La Recepcionista (o personal encargado de esta labor) obtiene los datos del Paciente para crear su expediente clínico (HIS) y le da una cita para consulta con algún médico (Figura 14)

Figura 13: Caso de uso DarAltaPaciente

AtenderCanalizarPaciente: Si es por primera vez que el Paciente es atendido por algún Médico Tratante, este pregunta sobre sus hábitos y padecimiento para almacenar esta información en el expediente del Paciente. En general el Médico Tratante osculta al Paciente y determina si necesita algún estudio o no (Figura 15)

Figura 14: Caso de Uso AtenderCanalizarPaciente

Paciente

Llega con medico tratante para su consulta

Es revisado por medico tratante

Es enviado al laboratorio para realizarse un estudio

No necesita que se le realicen estudios

[ Sí necesita estudio ]

[ No necesita estudios ]

El medico solicita datos de paciente como habitos y padecimiento para almacenar la informacion en expediente[ Es primera consulta ]

[ Ya habia si atendido anteriormente ]

AsignarPaciente: La Recepcionista (o personal encargado de esta labor) da una cita para consulta al Paciente con el Médico Tratante que lo atendió la cita anterior. De no encontrarse el Médico Tratante se le asigna algún otro (Figura 16)

Figura 15: Caso de Uso de AsignarPaciente

RealizarEstudios: El Paciente llega para hacerse el estudio correspondiente (se pueden realizar distintos tipos de estudios), el cual es realizado por un Técnico. Este estudio se almacena en un PACS (Figura 17)

Figura 16: Caso de uso RealizarEstudio

Paciente

Llegar a hacerse el estudio correspondiente al laboratorio

Solicita el estudio

Le realizan el estudio solicitado

ObtenerExpediente: El Médico Tratante obtiene el expediente del Paciente mediante el ID (Figura 18)

DarTratamientoPaciente: Después de los estudios realizados el Médico Tratante da un tratamiento al Paciente basándose en el diagnóstico que haya dado el Médico Especialista. De esta forma se concluye con la parte de modelado de casos de uso de negocio (Figura 19)

La segunda parte del modelado de negocio es elaborar el Modelado de Objeto de Negocio.

Figura 17: Caso de Uso de ObtenerExpediente

Figura 18: Caso de Uso DarTratamientoPaciente

3.1.1.1.2 Modelado de Objeto de NegocioSe creo un diagrama de robustez donde se muestra la interacción de los trabajadores del negocio (worker) con las entidades del negocio (Figura 20).

Se continuo con el segundo paso del modelado del objeto de negocio, crearon diagramas de actividad de los actores del negocio interactuando con los trabajadores del negocio (actores externo e internos) para los mismos casos de uso.

En los dos casos de uso siguientes se ve la interacción entre el paciente (actor externo del negocio) y la recepcionista o el personal encargado de realizar este tipo de tramites administrativos (actor interno del negocio).

Figura 19: Modelado del Objeto de Negocio

En este caso de uso (Figura 21) se observa que la interacción entre el paciente y la recepcionista para darlo de alta, los pasos a seguir son de la siguiente forma:

1) El paciente llega por primera vez y solicita una consulta

2) La recepcionista solicita los datos del paciente

3) Elabora un expediente personal del paciente

4) Le asigna un medico al paciente

Figura 20: Caso de Uso DarAltaPaciente

En este caso de uso (Figura 22), la interacción entre la recepcionista y el paciente es para asignarle a este, cita con su medico tratante, los pasos a seguir son:

1) El paciente solicita una cita

2) La recepcionista asigna una fecha para la cita

3) Verifica que su médico, lo pueda atender

4) Si no lo puede atender, se le asigna otro médico

Figura 21: Caso de Uso AsignarCita

En este caso de uso la interacción del paciente es con el médico tratante (actor interno del negocio).

Este caso de uso nuestra la relación entre el paciente y el médico tratante al obtener su el expediente del paciente. Aquí podría existir un cambio en el actor interno del negocio o trabajador del negocio, esto porque podrá obtener el expediente del paciente la recepcionista o el médico especialista.

Figura 22: Caso de Uso AtenderCanalizar

Figura 23: Caso de Uso ObtenerExpediente

Este diagrama muestra la interacción entre el paciente y el técnico al realizar el estudio correspondiente.

Este caso de uso nuestra la interacción del paciente con el médico tratante el otro caso de uso.

Se puede observar que el Médico Especialista no tiene ningún tipo de interacción con el paciente.

De esta forma se termino con el modelado de negocio del un hospital.

Figura 25: Caso de Uso DarTratamientoPaciente

Figura 24: Caso de Uso RealizarEstudio

3.1.1.2 Documento de visión (Almacenamiento)El documento de visión presentado a continuación es solo sobre el sistema de almacenamiento. Se genero un documento de visión del proyecto en general (PACS), el cual se encuentra en el Apéndice y tiene una visión general del proyecto incluyendo los dos sistema involucrados en él.

1.- IntroducciónSe desea implementar un sistema para el almacenamiento de expedientes médicos de pacientes, estos expedientes cuentan con información del paciente, resultados de estudios (imágenes de los estudios) y sus respectivos diagnósticos. Este sistema debe ser capaz de proveernos una base de datos y consulta/recuperación (query/retrieve) de archivos DICOM.

2.- Posicionamiento

El problema de

Almacenamiento de estudios (imágenes) y expedientes médicos de pacientes de manera física lo cual ocasiona perdida de tiempo y espacio.Visualización, manipulación de imágenes, y recuperación de estudios

Afecta A los médicos y pacientesEl impacto es Al ocupar espacio físico para el almacenamiento de estudios y expedientes médicos

de pacientes. Esto ocasiona un gran problema debido a que ocurren perdidas de expediente y estudios, al igual que una gran perdida de tiempo porque se hace la impresión de estos documentos de cada paciente.Al no tener un sistema de despliegue y manipulación de imágenes, el medico no puede realizar un diagnóstico fiable, si se imprimieran las placas regresaríamos al problema original del costo de espacio y de material de impresión, se perdería tiempo en realizar el diagnostico al no tener un sistema que nos permita la correcta recuperación de estudios , y el servicio ofrecido al paciente seria de baja calidad

Una solución exitosa seria

La implementan de un sistema que ofrezca el servicio de almacenamiento de estudios y expedientes médicos de forma digital, de esta forma se reducirían tiempos y costos.La implementación de un sistema que ofrezca el servicio de visualización y manipulación de imágenes, y la recuperación (query/retrieve) de estudios, para obtener una mayor eficiencia en el servicio, reducir los costos y ofrecer un servicio y un diagnostico de mayor calidad al paciente

Para Hospital (Consultorio)Quien Necesita una solución para el almacenamiento de estudios y expedientes médicos

de pacientes.Necesita una solución para la recuperación de estudios y la visualización y manipulación de imágenes

Almacenamiento Es un sistema de almacenamiento de estudios y expedientes medicas para hospitales y consultorios.Es un sistema de visualización, manipulación de imágenes y recuperación de estudios para hospitales y consultorios

Que Permite la consulta de estudios y expedientes médicos.Permite visualizar imágenes en una PC y manipularla, ademas de poder consultar estudios que han sido ya almacenados

A diferencia de De la forma tradicional de almacenamiento físico que tienen los hospitales y consultorios.De los visualizadores que proveen las grandes empresas, que implementan escasamente el protocolo de comunicación, monopolizando la venta

Nuestro Producto

Permite el almacenamiento de forma digital de los estudios y expedientes médicos estos en formato DICOM (protocolo).Permite proveer las funciones requeridas (visualización, manipulación y recuperación) ademas de que son compatibles con cualquier sistema que cuente con el mismo protocolo de comunicación, ya implementa el protocolo completamente

3.- Descripción de involucrados

Nombre Descripción ResponsabilidadMedico tratante Usuario del sistema Encargado de almacenar datos del paciente, así como anotar

observaciones, el tratamiento correspondiente y avance del paciente.

Técnico Usuario del sistema Encargado realizar estudios (modalidad) al paciente y de almacenarlos en su correspondiente expediente.

Medico especialista Usuario del sistema Encargado hacer diagnostico basándose en estudios realizados y almacenar en expediente del paciente.

Entorno del usuarioMedico tratante: Trabaja sobre una PC conectada a una red local que transmite bajo el protocolo DICOM para hacer la transferencia de datos.

Técnico: Trabaja con las diferentes modalidades para realizar los estudios correspondientes a los pacientes.

Medico especialista: Trabaja con un visualizados de imágenes el cual trabaja bajo el protocolo DICOM y permite el almacenamiento de estas y del diagnostico correspondiente.

DependenciasEl sistema debe correr en una máquina de reciente fabricación (Dual Core a 1.7 GHz con 1024 MB de memoria en RAM en adelante y tarjeta de video mayor o igual a 256MB) que cuente con sistema operativo Windows y JVM (Java Virtual Machine) versión 6

4.- Vista general del producto

Perspectiva del producto

El sistema no es independiente ya que se integrara con un sistema de visualización para poder realizar la consulta de estudios. También es de bajo costo debido a que se utiliza herramienta de fuente libre (PIXELMED entre otras).

Suposiciones y dependencias Para poder implementar el sistema se debe contar con un sistema operativo Windows XP, debe tener un protocolo de comunicación.

Alternativas y competencia Alternativa seria usar la competencia pero es una alternativa costosa ya que este tipo de almacenamiento lo ese. Se podría optar por quedarse con el mismo sistema de visualización (placas) lo cual seguiría generando altos costos conforme crecen el numero de estudios, u optar por un visualizador comercial el cual nos proveería los mismos servicios, pero con la desventaja de que no implementaría en su totalidad el protocolo de comunicaciones.

3.1.1.3 Lista de Riesgos

Esta lista de riesgo es modificada en cada fase de acuerdo a los riesgos que vaya presentando, así con los riesgos que se vayan mitigando. En esta primera fase fase los riesgos que teníamos fueron estos:

3.1.1.4 Descripción de la ArquitecturaLa arquitectura del sistema de almacenamiento es la llamada n-tercios. Estos tipos de arquitectura son una forma general de la arquitectura cliente servidor y se distribuyen a través de varias máquinas. En este modelo el cliente envía una petición a un servidor, pero para poder atenderla, el servidor, debe a su vez, fungir como cliente de otro servidor. Un ejemplo de este tipo de arquitectura es 3-tercios, en donde se tiene:

– Un tercio de presentación: Se encarga de la interacción con los clientes

– Un tercio de negocio(control): Contiene la lógica de negocio

– Un tercio de datos: Contiene el almacén donde se guardan los datos persistentes

El tipo de arquitectura de el sistema de almacenamiento es 2-tercios, solo cuenta con el tercio de negocios que esta basado en la librería pixelmed, y el tercio de datos, que sera accedido por el tercio de negocios.

Figura 26: Arquitectura del sistema de Almacenamiento

3.1.1.5 Modelo de Caso de Uso InicialEste es un modelo obtenido del documento de visión del Sistema de Almacenamiento, por lo tanto es un modelo de inicial, ya que en este documento no se detallan casos de uso.

Este sistema solo interactua con otros sistemas, teniéndolos como actores. No interactua con ningún actor humano, porque siempre que se necesita hacer alguna recuperación o almacenamiento de datos o imágenes se hace a través del visualizador o la modalidad.

Figura 27: Modelo de Caso de Uso Inicial del Sistema de Almacenamiento

System

Almacenamiento

VisualizadorBuscar datos

Almacenar datos

Recuperar datos

Modalidad

3.1.2 ElaboraciónEn esta fase se realizan varios documentos que detalla mejor los casos de uso, de tal forma que se puede, en cierto punto empezar a desarrollar código del sistema de almacenamiento.

Uno de los documentos mas importantes de esta fase es el SRS o Documento de Especificación de Requerimientos.

3.1.2.1 Documento de Especificación de Requerimientos de la Estación de Almacenamiento (SRS)IntroducciónEste documento describe los requerimientos de un sistema de almacenamiento, el cual permitirá realizar búsqueda, recuperación y almacenamiento de imágenes y expedientes médicos de pacientes.

Contexto del sistemaEl sistema de almacenamiento será consultado por distintas estaciones de trabajo, entre ellas está la estación de visualización. También se podrá hacer consultas de expedientes en cualquier PC que tenga plataforma Windows XP o superiores.

Actores

Nombre Descripción Responsabilidades

Visualizador Sistema encargado de mostrar los resultados obtenidos de la búsqueda realizada por el sistema o estación de almacenamiento

Mostrar las imágenes obtenidas de la estación de almacenamiento

Modalidad Es una estación de obtención de imágenes medicas

Encargada de almacenar la imagen obtenida como resultado de algún estudio realizado

Requerimientos funcionales

No ID Nombre del caso de uso

Descripción Hoja de

detalle

Release inicial

1 BUSDAT-1 Buscar datos Este caso de uso permite hacer búsqueda de un determinado expediente o imagen médica de algún paciente.

Detalle 1.0

2 RECDAT-2 Recuperar datos

Este caso de uso permite hacer recuperación de expedientes o imágenes médicas de algún paciente (en formato DICOM).

Detalle 1.0

https://www.humbertocervantes.net/cursos/ingsoft/wiki/doku.php?id=ingsoft:equipo2:srs:clie-1


No ID Nombre del caso de uso

Descripción Hoja de

detalle

Release inicial

3 ALMDAT-3 Almacenar datos

Este caso de uso permite hacer el almacenamiento en alguna base de datos de expedientes o imágenes médicas (formato DICOM) de algún paciente.

Detalle 1.0

Requerimientos no-funcionales generales

ID Descripción Release Inicial

RNF1 La búsqueda de datos no debe de tomar mas de 10 segundos. 1.0

RNF2 La recuperación de datos no debe tomar de 5 segundos. 1.0

RNF3 El almacenamiento de un expediente no debe tardar mas de 2 segundos. 1.0

3.1.2.2 Detalle de Casos de Uso

3.1.2.2.1 BUSDAT - 1 Buscar datos

Descripción:Este caso de uso permite hacer búsquedas de un determinado expediente o imagen médica (objeto DICOM) de algún paciente.

Disparador:El caso de uso se lanza cuando el visualizador solicita hacer una búsqueda en la base de datos.

Actores:Visualizador

Pre-condiciones:El sistema se encuentra en espera de alguna petición del visualizador.

Post-condiciones:El sistema manda mensaje de que el proceso fue concluido.


Flujo Principal:1.- El sistema solicita la información necesaria para realizar la búsqueda por el número de expediente.

2.- El visualizador envía el número de expediente para que se efectué la búsqueda.

3.- El sistema realiza la búsqueda en la base de Datos.

4.- El sistema manda un mensaje de éxito al encontrar el expediente solicitado.

Flujos Alternativos:En 3, si el sistema no encuentra el número de expediente, envía un mensaje de que el expediente no existe en la base de datos. Y termina el caso de uso.

Requerimientos funcionales asociados:


BUSDAT 1.1 El número de expediente debe contener 8 caracteres

BUSDAT 1.1.1 El número de expediente debe contener caracteres alfanuméricos

Requerimientos No-funcionales


RNF1 El caso de uso no debe tomar mas 10 segundos en realizar la búsquedas

Pruebas de Aceptación

ID Precondiciones Entrada Resultados Esperados

BUSDAT -TC1

- El visualizador hace una petición de buscar datos. - El paciente “prueba” está dado de alta en el sistema.

- El visualizador ingresa los datos del expediente del paciente “prueba” que serán buscados.

- El sistema envía mensaje de éxito.

BUSDAT -TC2

- El visualizador hace una petición de buscar datos.- El paciente “prueba” no está dado de alta en el sistema.

- El visualizador ingresa los datos del expediente del paciente “prueba” que serán buscados.

- El sistema envía un mensaje de que el paciente “prueba” no esta dado de alta en la base de datos.

3.1.2.2.2 RECDAT – 2 Recuperar datos

Descripción:Este caso de uso permite hacer la recuperación de un expediente o imagen médica (objeto DICOM) de algún paciente directamente de la base de datos o mediante una búsqueda previa.

Disparador:El caso de uso se lanza cuando el visualizador solicita hacer una recuperación de la base de datos.




Flujo Principal:1.- El sistema solicita la información necesaria para realizar la recuperación de datos por medio del número de expediente.

2.- El visualizador envía el número de expediente para que se efectué la búsqueda.

3.- El sistema realiza la recuperación de la Base de Datos.

4.- El sistema envía los datos solicitados.

Flujos Alternativos:1.- En 1, si previamente se hizo una búsqueda, el sistema solicita la aceptación de la recuperación y pasa al paso 3.

2.- En 3, si el sistema no encuentra el número de expediente, envía un mensaje de que el expediente no existe en la base de datos. Y termina el caso de uso.



RECDAT 1.1 El número de expediente debe contener 8 caracteres

RECDAT 1.1.1 El número de expediente debe contener caracteres alfanuméricos

Requerimientos No-funcionales:


RNF1 El caso de uso no debe tomar mas 10 segundos en realizar la recuperación en caso de que no se haya hecho una búsqueda previamente

RNF2 El caso de uso no debe tomar mas de 5 segundos si previamente se realizo una búsqueda

Pruebas de Aceptación:


RECDAT -TC1

- El visualizador hace una petición de recuperar datos. - El paciente “prueba” está dado de alta en el sistema.

- El visualizador ingresa los datos del expediente del paciente “prueba” para ser recuperados los datos requeridos.

- El sistema envía los datos solicitados.

RECDAT -TC2

- El visualizador hace una petición de recuperar datos. - El paciente “prueba” no está dado de alta en el sistema.

- El visualizador ingresa los datos del expediente del paciente “prueba” para ser recuperados.

- El sistema envía un mensaje de que el paciente “prueba” no esta dado de alta en el sistema.

RECDAT - TC3

- El visualizador hace una petición de recuperar datos.

- El paciente “prueba” esta dado de alta en el sistema.

- El paciente “prueba” fue buscado previamente.

- El visualizador solicita la recuperación del expediente del paciente “prueba” que previamente se buscó.

- El sistema envía los datos solicitados.

3.1.2.2.3 ALMDAT – 3 Almacenar datos

Descripción:Este caso de uso permite hacer el almacenamiento en alguna base de datos que soporte objetos DICOM (expedientes e imágenes médicas).

Disparador:El caso de uso se lanza cuando el visualizador o la modalidad solicitan almacenar algún tipo de objeto DICOM en la base de datos.


Modalidad



Flujo Principal:1.- El sistema externo solicita almacenar algún objeto DICOM en el expediente en uso.

2.- El sistema verifica que el dato sea DICOM.

3.- El sistema envía una verificación del dato.

4.- El sistema externo confirma almacenamiento.

5.- El sistema almacena los datos correctamente en la base de datos.

6.- El sistema envía un mensaje de éxito al sistema externo.

Flujos Alternativos:1.- En 2, si el dato que se desea almacenar no es de tipo DICOM manda un mensaje de ERROR al sistema externo y termina el caso de uso.

2.- En 5, si el dato no se puede almacenar correctamente se envía un mensaje al sistema externo de que no se pudo guardar el dato en la base de datos y regresa al paso 1.



ALMDAT 1.1 El número de expediente debe contener 8 caracteres

ALMDAT 1.1.1

El número de expediente debe contener caracteres alfanuméricos

Requerimientos No-funcionales


RNF1 El caso de uso no debe tomar mas 10 segundos en realizar el almacenamiento en la base de datos

Pruebas de Aceptación


ALMDAT -TC1

- El sistema externo hace la petición de almacenar datos. - El paciente “prueba” está dado de alta en el sistema.

- El sistema externo envía una solicitud de almacenamiento de los datos del expediente del paciente “prueba”.

- El sistema solicita la confirmación de almacenamiento.

- El sistema envía un mensaje de éxito al sistema externo.

ALMDAT -TC2

- El sistema externo hace la petición de almacenar datos.- El paciente “prueba” no está dado de alta en el sistema, pero se va a dar de alta.

- El sistema externo envía una solicitud de almacenamiento de los datos del expediente del paciente “prueba”.

- El sistema externo envía el numero nuevo numero de expediente.

- El sistema solicita datos para almacenar el nuevo expediente.

- El sistema envía un mensaje de éxito al sistema externo.

ALMDAT - TC3

- El sistema externo hace la petición de almacenar datos.- El paciente “prueba” no está dado de alta en el sistema, pero no se va a dar de alta.

- El sistema externo envía una solicitud de cancelación almacenamiento de los datos del expediente del paciente “prueba”.

- El sistema envía un mensaje de cancelación de almacenamiento al sistema externo.

3.1.2.3 Modelo de Casos de Uso Detallado

Este es el modelo de casos de uso detalla obtenido posteriormente del análisis del documento de especificación de requerimientos (SRS).

Este modelo nuestra la relación que existe entre los actores y los casos de uso del sistema. En este caso se puede observar que los actores de este sistema son otros sistema, debido a que no hay actores humanos que tengan interacción con este sistema.

Figura 28: Modelo de casos de uso detallado

3.1.2.4 Diagrama de ClasesEl resultado de este diagrama es el siguiente:

Se obtuvieron tres clases, que se toman como las clases principales para este sistema y sus correspondientes atributos y métodos.

Figura 29: Diagrama de clases

3.1.2.5 Arquitectura Ejecutable

Como se mencionó anteriormente, se presenta un avance de código en el cual se implementa los casos de uso básicos para la arquitectura ejecutable.

Figura 30: Arquitectura Ejecutable para la fase de Elaboración

Sistema Visualizacion (PC)

Sistema Almacenamiento (PC)

Control Visualizador

Control Almacenamiento

Presentacion Visualizador

Pixelmed

Datos Almacenamiento

Pixelmed

<<DICOM>>

3.1.3 Construcción

En esta fase se empieza la codificación de los casos de uso restantes, esto permite que el sistema empiece a tener la funcionalidad requerida para terminar esta fase con el sistema casi al 100%.

Se empieza con la construcción de los diagramas de robustez de los casos de uso.

3.1.3.1 Diagrama de Robustez

Se puede observar paso a paso el proceso para realizar cada caso de uso, así como las entidades que se crean o se utilizan al realizar este proceso.

Aquí se muestra como el Sistema de Visualización busca algún dato en el Sistema de Almacenamiento y como se crea una instancia de un objeto llamado Expediente, que como se mostró anteriormente es una de las clases que se implementan en este sistema.

Figura 31: Diagrama de robustez del caso de uso BuscarDatos

Este diagrama nos muestra como el mismo Sistema de Visualización realiza ciertos pasos para hacer la recuperación del expediente solicitado a la Sistema de Almacenamiento.

Este diagrama nos muestra como se almacenan los datos.

Figura 32: Diagrama de robustez del caso de uso RecuperarDatos

Figura 33: Diagrama de Robustez del caso de uso AlmacenarDatos

3.1.4 Transición entre la metodología de desarrolla y las pruebas con Pixelmed

Al estar aplicando la metodología de desarrollo, se realizaron prototipos a partir de las clases utilitarias que provee Pixelmed, sin embargo, conforme avanzo la familiarización con la librería para profundizar sobre la manera en que se tenia que trabajar con ella, se observo que esta provee una implementación de un servidor de almacenamiento con las funcionalidades requeridas para este proyecto y que trabaja justamente con la clase que contiene el núcleo de función de la base de datos. De esta forma se llego a la conclusión de que era mejor ponerlo en ejecución y entender en detalle su funcionamiento a través del estudio de su código

De esta forma se presenta a continuación los resultados obtenidos al poner en ejecución la implementación de Pixelmed como servidor de almacenamiento, esto en conjunto con el sistema de visualización.

3.1.5 Implementación del Almacenamiento Pixelmed

Los resultados expuestos el esta parte del documento muestran la inicialización del sistema de almacenamiento, configurado a partir del archivo de propiedades llamado testserver.properties, el cual es cargado en el momento en que se ejecuta la aplicación. En este archivo se configura el servidor de almacenamiento, donde guarda los datos enviados por el sistema de visualización, así como la configuración de puertos.

En realidad la implementación que se ejecuta es el servidor de almacenamiento, que a su vez trabaja íntimamente con la clase DatabaseInformationModel que es una clase abstracta que contiene el núcleo funcional para el almacenamiento, accesando y manteniendo una representación persistente de los objetos DICOM. Esto gracias a que trabaja con llaves

Una vez iniciado el servidor de almacenamiento, estará en espera de conexiones de algún sistema local o remoto. Esto lo hace gracias a la StorageSOPClassSCPDispatcher, el cual espera por conexiones entrantes.

En la siguiente figura se muestra como el servidor de almacenamiento se queda en espera de nuevas conexiones.

En este caso se va a conectar un sistema remoto (Visualizador).

Se muestra como se ha recibido la petición de conexión realizada por una consulta del Sistema de Visualización.

El Sistema queda en espera de alguna petición por parte del Sistema de Visualización.

Cuando el Sistema de Visualización hace la petición de Retrive o recuperación de imagen el Sistema de Almacenamiento envía el dato solicitado. En la figura se puede observar (lineas azules) el nombre del sistema que hace la petición, en este caso es el Visualizador (muestra también los datos que se encuentran almacenados en su archivo de propiedades).

También se observa (linea azul) el número de imagen solicitada por el Visualizador (esta imagen se encuentra localizada en la base de datos del Sistema de Almacenamiento)

Cabe mencionar que los datos solicitados por el Visualizador son cargados solo hasta que son requerido, esto es, se manda la estructura del directorio pero solo hasta que se solicita ver las imágenes se carga el archivo.

Cuando el Visualizador envía una imagen para ser almacenada, el Sistema de Almacenamiento la recibe en el directorio donde se encuentra la base de datos (el lugar donde se almacenaran los datos en el Sistema de Almacenamiento se dan en el archivo de propiedades de este sistema).

Se puede observar como el numero de imagen enviado es el:1.3.12.2.1107.5.3.3.4117.2001111920222164.10060000

que es el mismo almacenado el la dirección indicada por el archivo de propiedades.

4 ConclusionesPara terminar este documento se presentan las conclusiones obtenidas de este proyecto.

Se puede decir que la implementación de un sistema de almacenamiento para un PACS es de suma importancia debido a que esa es la parte en que se encuentran localizados todos los datos del paciente junto con estudios. Es muy importante que este sistema cuente con una arquitectura correcta para que las consultas y recuperaciones no se vean retardadas por este aspecto.

El servidor de almacenamiento es una parte del sistema muy importante, ya que este es el encargado de hacer un correcto manejo de los datos y los conduce al lugar deseado, gracias al archivo de configuración o properties.

Todo lo descubierto sobre la implementación de este sistema se hizo en conjunto con la implementación del sistema de visualización trabajado a la par de este sistema. Al igual como se trabajó con este sistema de almacenamiento se trabajo con el sistema de visualización que también cuenta con un documento anexo a este.

4.1 GLOSARIOAE: Entidad de aplicación

Cine loop: Es el continuo despliegue de un conjunto de imágenes o frames que dan del efecto de movimiento. Es considerado una útil herramienta de diagnostico

Clases de servicio: Son nombres dados a a un grupo de clases SOP por conveniencia. Estas describen la informacion y las operaciones

Clase de objeto de información: Una descripción formal de un objeto de información con una descripción de su propósito y los atributos que posee.

Clases SOP: Service-object pair class. Combinación de clases de servicio y los objetos de información. Esto es, objetos de información definen el contenido del núcleo de la imagen medica, y las clases de servicio definen que se va a hacer con ese contenido. Definen la funcionalidad de DICOM.

CT: Tomografía axial computarizada.

DICOM: Digital Imaging and Communications in Medicine. Estándar para la comunicación y almacenamiento de imágenes y sus datos asociados

DUL: DICOM Upper Layer

Entidad de información: Es la parte de la información definida por IOD compuesto, el cual es relacionado a una clase especifica de un objeto del mundo real. Existe una correspondencia uno a uno entre las entidades de información y las entidades en el modelo de aplicación DICOM (Application Model)

Estaciones de visualización: Estación capaz de hacer la visualización de las imágenes y datos del algún expediente.

HIS: Hospital Information System (Sistema de Informacion Hospitalaria)

Imagen Multi-frame: Imagen que contiene multiples frames de 2 dimensiones.

IODs: Information object definition (Definición del Objeto de Información). a data abstraction of a class of similar Real-World Objects which defines the nature and Attributes relevant to the class of Real-World Objects represented.

ISO/OSI (interconexión de sistemas abiertos): Protocolo de Comunicación vía Internet. Para el envío de mensajes ,es un modelo por capas para la comunicación de sistemas abiertos. Las capas proporcionan varias interfaces con diferentes niveles de detalle. Consta de siete capas: física, enlace de datos, red, transporte, sesión, presentación y aplicación.

En este modelo existen dos tipos de protocolos, los orientados hacia las conexiones (antes de cualquier envío de datos se requiere una conexión virtual, que tras el envío deben finalizar) y sin conexión (no requieren una conexión virtual, y los mensajes se envían en forma de datagramas)

JPEG: Joint Photographic Experts Group. Es un algoritmo diseñado para comprimir imágenes con 24 bits de profundidad o en escala de grises. JPEG es también el formato de fichero que utiliza este algoritmo para comprimir imágenes. JPEG es un algoritmo de compresión con pérdida. Esto significa que al descomprimir la imagen no obtenemos exactamente la misma imagen que teníamos antes de la compresión

JPEG 2000: es una norma de compresión de imágenes basada en transformación de ondas. Fue creada

por el comité Joint Photographic Experts Group que anteriormente había creado el algoritmo JPEG. Su objetivo fue el de mejorar el algoritmo JPEG, basándose en una transformación discreta del coseno.

LDAP: Lightweight Directory Access Protocol. Protocolo a nivel de aplicación que permite el acceso a un servicio de directorio ordenado y distribuido para buscar diversa información en un entorno de red. LDAP también es considerado una base de datos (aunque su sistema de almacenamiento puede ser diferente) a la que pueden realizarse consultas.

LDIF: Data Interchange Format. Es un formato que se utiliza para la importación y exportación de datos independientemente del servidor LDAP que se esté utilizando.

Modalidades: Toda técnica de exploración realizada con un equipo de adquisición de datos para realizar un diagnostico.

Modelo cliente-servidor: Arquitectura de software donde una parte funge como cliente y otra parte como servidor.

Modelado del negocio: Modelo encargado del estudio profundo del negocio sobre el cual se trabaja.

Objeto de datos DICOM: Objetos basados en el protocolo DICOM (formato DICOM).

PACS: Picture Archiving and Communication System. Almacenamiento de imágenes y sistema de comunicación

PDU: Protocolo Data Unit (Unidades de Datos de Protocolo). Se utiliza para el intercambio entre unidades pares, dentro una capa del modelo OSI. Existen dos clases de PDUs:

• PDU De datos

• PDU De control

Pixelmed: Librería basada en el protocolo DICOM.

Protocolos de comunicación: Reglas y formatos para hacer transmisión de datos.

RIS: Radiology Information System (Sistema de información radiológica).

RLE: La compresión RLE o Run-length enconding es una forma muy simple de compresión de datos en la que secuencias de datos con el mismo valor son almacenadas como un único valor más su recuento. Esto es más útil en datos que contienen muchas de estas "secuencias"; por ejemplo, gráficos sencillos con áreas de color plano, como iconos y logotipos.

RM: Resonancia magnética.

RUP: Proceso Unificado Rational

Service Class Provider (SCP): Clase que provee los servicios

Service Class User (SCU): Clase que solicita servicios

TCP/IP: Protocolo de comunicación vía Internet. Nos proporciona transmisión fiable de paquetes de datos sobre redes. TCP / IP Proviene de dos protocolos, el Transmission Contorl Protocol (TCP) y el Internet Protocol (IP).

WADO: Web Acces to DICOM Object (Acceso Web a Objetos DICOM)

5 Apéndice

5.1 Definiciones de SCP Y SCU

5.1.1 ECHO-SCPECHO-SCP Espera por conexiones, aceptara asociaciones con contextos de presentacion para la clase SOP de la clase de servivio de Verificacion, respondera exitosamente a solicitudes echo.

5.1.2 STORAGE-SCPSTORAGE-SCP Espera por conexiones, aceptara asociaciones con contextos de presentacion para la clase SOP de la clase de servicio de Almacenamiento, almacenara las instancias recibidas en la base de datos local, posteriormente pueden ser listadas y vistas a traves de una interfaz de usuario.

5.1.3 STORAGE-SCUSTORAGE-SCU Es activado a traves de la interfaz de usuario cuando un usuario seleciona instancias de la base de datos local o un DICOMDIR, o la instacia actualmente desplegada, y solicita que se envie a una AE remota (seleccionada de una lista). Tambien puede ser activado por una solicitud de recuperacion hecha por RETRIEVE-SCP.

5.1.4 FIND-SCUFIND-SCU es activado por la interfaz de usuario cuando el usuario selecciona una AE remota para consulta (de una lista), es cuando se inicia la consulta. Estas consultas son ejecutadas recursivamente desde el estudio, a traves de las series y los niveles de instancias hasta todas las instancias que concuerdan han sido listadas.

5.1.5 MOVE-SCUMOVE-SCU es activado por la interfaz de usuario cuando un usuario selecciona un estudio, una series o una instancia para recuperarla. Una conexion a la AE remota se establece para iniciar y monitorear la recuperacion y la AE STORAGE-SCP recibe las instancias recuperadas.

5.1.6 QUERY-SCPQUERY -SCP espera por conexiones, aceptara asociaciones con contexto de presentacion para clases SOP de la clase de servicio de consulta (Query Service Class) , y respondera a las consultas en cada nivel de los modelos de informacion soportados.

5.1.7 RETRIEVE-SCPRETRIEVE -SCP espera por conexiones, aceptara aociaciones con contexto de presentacion para clases SOP de la clase de servicio de recuperacion (Retrieve Service Class) , y respondera a recuperaciones solicitadas en cada nivel de los modelos de informacion soportada, y enviara la instancia compuesta apropiada usando los servicios de el STORAGE-SCU, asi como el estado de los mensajes pendientes y completados.

5.2 Documento de Visión (general del PACS)1.- IntroducciónSe desea implementar un sistema para el despliegue y manipulación de imágenes. Este sistema debe soportar una base de datos local de objetos DICOM, la función de poder leer los archivos de tipo DICOMDIR y hacer consulta y recuperación (query/retrieve)de objetos a través de la red.

2.- PosicionamientoFrase del problemaEl problema de Un hospital es la administración de los expedientes de los pacientes y los resultados

de sus estudios asociados, así como la visualización de los mismos

Afecta A los pacientes y a los médicos.

El impacto es El manejo de estos expedientes puede convertirse en un problema debido al espacio de almacenamiento requerido, ya que se suscitan perdidas de expedientes lo cual ocasiona la repetición de los estudios, con lo que se tiene poca eficiencia en el servicio y resulta en un servicio de poca calidad para el paciente ya que puede llegar a afectarlo a largo plazo por la toma excesiva de estudios radiológicos y los costos se elevarían.

Una solución exitosa seria

La implementación de un sistema que permita tener toda la información en un mismo lugar (Storage) y de forma digital, para que la administración de los expedientes sea de forma mas eficiente, así como la visualización de los estudios realizados a los pacientes (Viewer).

Frase de posicionamiento del producto

Para Hospital

Quien Necesita una solución para la fácil administración de los expedientes y la visualización de los estudios realizados a pacientes

“PACSUAM” Es un sistema de administración de expedientes(texto e imágenes) para consultorios u hospitales

Que Permite la consulta de expedientes e imágenes medicas (visualización) así como su almacenamiento

A diferencia de El sistema tradicional que se utiliza en los hospitales, ya que estos tienen un almacenamiento físico y los estudios son entregados en placas

Nuestro producto

Permite que las imágenes obtenidas de los estudios sean almacenadas electrónicamente junto con su expediente, de modo que los médicos puedan consultar los expedientes y visualizar los resultados de estudios así como el diagnostico de estos, con lo que se lograra proveer un almacenamiento económico (storage-BD) y una rápida recuperación de expedientes (query/retrieve) y resultados (visualización)

3.- Descripción de involucradosResumen de involucrados

Nombre Descripción Responsabilidades

Recepcionista Usuario del sistema Encargada de generar un nuevo expediente cada que se tenga un nuevo paciente(captura de datos).

Medico Tratante Usuario del sistema Encargado de atender al paciente, de ser necesario hacer algún estudio canaliza al paciente al área correspondiente. Después de realizados los estudios el Medico Tratante da un tratamiento al Paciente. Toda la información es almacenada en el expediente del paciente.

Técnico Usuario del sistema Encargado de realizar los estudios correspondientes al paciente y almacenarlos en el sistema (en el expediente del paciente).

Medico Especialista Usuario del sistema Encargado de obtener los resultados de los estudios realizados al paciente y analizarlos para dar un diagnostico.

Desarrolladores:

Sandra Méndez Luna, Cesar Martín Yescas Rocha

Encargados de hacer el desarrollo del sistema de acuerdo al SRS

Hacer análisis de requerimiento y en base a estos hacer la implementación correspondiente.

Entorno del usuario• Recepcionista:Cuando se tiene un nuevo paciente, se encarga de capturar los datos generales del

paciente, para generar un nuevo expediente, así como programar citas y asignar un medico tratante.

• Medico Tratante:Genera un diagnostico general del paciente y si es necesario lo canaliza a un estudio(s) en particular. Después de realizado el estudio, genera el tratamiento correspondiente, viendo los resultados del diagnostico en una estación de visualización que lee archivos DICOM recuperados de las modalidades.

• Técnico: Encargado de interactuar con las modalidades para realizar los estudios solicitados. Estas modalidades son los equipos en los cuales se realizan los estudios(RX, Tomografías, etc.).

• Medico especialista: Examina los estudios realizados y genera un diagnostico de estos. Para examinar los estudios se ayuda con una estación de visualización, esta interactua con la estación de almacenamiento para obtener las imágenes de los resultados y así generar su diagnostico.

Dependencias

• El sistema debe correr en una máquina de reciente fabricación (Dual Core a 1.7 GHz con 1024 MB de memoria en RAM en adelante y tarjeta de video 256MB) que cuente con sistema operativo Windows y JVM (Java Virtual Machine) versión 6.

4.- Vista general del producto

Perspectiva del productoEl sistema es independiente y totalmente autónomo, pero podría integrarse con un sistema hospitalario HIS/RIS para obtener un sistema de mayor capacidad en el futuro.

Los sistemas interactuan de la siguiente forma, el HIS (Hospital Information System) contiene la información de los pacientes y el RIS (Radiology Information System) los protocolos para la realización de los estudios, así el PACS recuperaría la información de los pacientes y sus estudios con una estación de visualización.

Suposiciones y dependencias Para poder implementar el sistema se debe contar con un sistema operativo Windows XP, debe tener un sistema central de almacenamiento (Storage) y varias estaciones para la visualización y consulta de imágenes y expedientes, utilizando el protocolo Pixelmed para la comunicación de los dispositivos.

Alternativas y competencia • Una alternativa que se puede manejar es quedarse con su forma tradicional (i.e. Placas,

expedientes en papel, etc.). Esta alternativa no es buena puesto que el almacenamiento y la impresión de los estudios resulta costoso conforme aumentan los pacientes

• Otra alternativa es usar el Sistema comercial(nombre) de la competencia la cual resolvería algunos problemas, pero los proveedores implementan escasamente el protocolo DICOM.

Figura 34: Diseño de un PACS

Necesidades y características

Necesidad Prioridad Características Release Planeado

Aplicación de visualización

Esencial Permite la visualización y manipulación de imágenes así como la función de query/retrieve para la recuperación de estudios. Esta se conectaría con la aplicación de almacenamiento para lograr la recuperación.

1.0

Aplicación de almacenamiento

Esencial Permite el almacenamiento de expedientes médicos de los pacientes (incluye estudios)

1.0

5.- Otros requerimientos de producto

Requerimientos Adicionales

• El sistema debe de soportar múltiples estaciones de visualización• El sistema de almacenamiento debe soportar concurrencia para la visualización de varios

estudios• Proporcionar al cliente un manual de usuario donde explique la manera en que se desenvuelve

el sistema.

Este documento de visión es sobre el PACS, a continuación se presenta el documento de visión del Sistema de Visualización.

5.2.1.1 Documento de Especificación de Requerimientos (SRS) del PACS

IntroducciónEste documento describe los requerimientos de un PACS (PACSUAM) pequeño, el cual permitirá realizar consulta y recuperación de imágenes y expedientes médicos de pacientes.

Contexto del sistemaEl PACSUAM hará uso de distintas estaciones de trabajo, entre ellas está la estación de visualización y la estación de almacenamiento. También se podrá hacer consultas de expedientes en cualquier PC que tenga plataforma Windows XP o superiores.

Actores

Nombre Descripción ResponsabilidadesRecepcionista Usuario del sistema Encargada de generar un nuevo expediente cada que se

tenga un nuevo paciente(captura de datos).

Medico Tratante Usuario del sistema Encargado de atender al paciente, de ser necesario hacer algún estudio canaliza al paciente al área correspondiente. Después de realizados los estudios el Medico Tratante da un tratamiento al Paciente. Toda la información es almacenada en el expediente del paciente.

Técnico Usuario del sistema Encargado de realizar los estudios correspondientes al paciente y almacenarlos en el sistema (en el expediente del paciente).

Medico Especialista Usuario del sistema Encargado de obtener los resultados de los estudios realizados al paciente y analizarlos para dar un diagnostico.

Requerimientos funcionales

No ID Nombre del caso de

uso

Descripción Hoja de detalle

Release inicial

1 CLIE-1 Dar de alta cliente

Este caso de uso debe soportar el ingreso de un nuevo cliente al sistema

Detalle 1.0

2 CLIE-2 Dar de baja cliente

Este caso de uso debe soportar la eliminación de un cliente del sistema

Detalle 1.0

3 CLIE-3 Modificar cliente

Este caso de uso debe soportar la modificación de los datos de un cliente en el sistema

Detalle 1.0

4 CONC-1 Consultar cliente

Este caso de uso debe soportar la consulta de un cliente en el sistema

Detalle 1.0

Restricciones y Requerimientos no-funcionales generalesRestricciones:


RES1 El sistema debe poder ser accedido vía Web para la consulta de productos e historial crediticio por parte de los clientes

1.1

Requerimientos no funcionales: NOTA: Estos requerimientos no-funcionales se aplican a una escala general, para ver los requerimientos no-funcionales específicos a un caso de uso, consultar el detalle de requerimientos por caso de uso.


RNF1 El alta, baja y modificación de un usuario no debe tomar más de un minuto 1.0

RNF2 El alta, baja y modificación de un producto no debe tomar más de un minuto 1.0

RNF3 El alta, baja y modificación de un producto no debe tomar más de un minuto 1.0

https://www.humbertocervantes.net/cursos/ingsoft/wiki/doku.php?id=ingsoft:equipo2:srs:conc-1




5.3 Descripcion de la arquitectura

La arquitectura general del sistema es un cliente-servidor, esta aqruitectura es el modelo basico de los sistemas distribuidos. En ella, participan 2 entidades (cliente y servidor), el cliente emite peticiones y el servidor realiza un procesamiento y regresa una respuesta. Las peticiones entre el cliente y el servidor pueden ser sincrona o asincrona; en este caso es sincrona, es decir el cliente espera la respuesta del servidor. Comunmente son aplicaciones del lado del cliente, que se ejecutan en la estación de trabajo del usuario y se comunican con un almacen de datos centralizado.

Ambos deben ser capaces de emitir peticiones a los servicios disponibles. La parte que solicita los servicios es el usuario del servicio (service user), la parte equivalente es el proveedor del servicio (service provider). Ambas partes comparten el hecho de como se intercambian los datos (protocolo) y la misma interfaz lógica (formato de petición) entre si.

Mas adelante describiremos la arquitectura especifica de cada sistema.

Sistema Visualizacion (PC)

Sistema Almacenamiento (PC)

Control Visualizador

Control Almacenamiento

Presentacion Visualizador

Pixelmed

Datos Almacenamiento

Pixelmed

<<DICOM>>

5.4 Zeroconf

Zeroconf o Zero Configuration Networking es un conjunto de técnicas que permiten crear de forma automática una red IP sin configuración o servidores especiales. También conocida como Automatic Private IP Addressing or APIPA, permite a los usuarios sin conocimientos técnicos conectar ordenadores, impresoras de red y otros elementos y hacerlos funcionar. Sin Zeroconf, un usuario con conocimientos técnicos debe configurar servidores especiales, como DHCP y DNS, o bien configurar cada ordenador de forma manual. Una implementacion de Zeroconf es Bonjour

5.5 Bonjour

Bonjour es una tecnología de redes de ordenadores que utilizas paquetes estándar de DNS de una forma nueva, basandose en una tecnología que es un poco antigua: DNS sobre IP. Es un método para utilizado para descubrir servicios en una red de área local.

Ejemplos en donde se utiliza la tecnología Bonjour:

• En el Mac OS X, permitiendo a los usuarios establecer una red sin ningún tipo de configuración

• Otros sistemas operativos lo utilizan para encontrar impresoras y servidores de ficheros

• iTunes para encontrar música compartida

• iPhoto para encontrar fotos compartidas, iChat, Skype y el Proyecto Gizmo para encontrar otros usuarios de la red local

• TiVo Desktop para encontrar video grabadores digitales

• SubEthaEdit para encontrar colaboradores de documetos

• Safari para encontrar servidores web locales y páginas de configuración para dispositivos locales, y por Asterisk para notificar de servicios y parámetros de configuración para teléfonos VoIP y llamadores automáticos.

Sin una configuración especial de DNS, Bonjour solo funciona en una única subred, no da acceso extra a ningún servicio, solo los anuncia, es decir, un usuario puede explorar por una lista de ordenadores cercanos con los que puede compartir ficheros, entonces Bonjour en esos ordenadores le dice al usuario que ese servicio esta disponible, pero aun así tiene que proveer una contraseña para acceder al servicio en esas máquinas. Tambien puede funcionar en un rango más cercano, aunque los mensajes solo llegan a usuarios en la misma subred. Los servicios Bonjour están implementados sobre todo en la capa de aplicación usando llamadas estándar TCP/IP, más que a través del sistema operativo.

A continuación se describira la clase que hace el auto descubrimiento en la red.

5.6 Paquete com.pixelmed.network Este paquete contiene clases para el envio, recepción, consulta y recuperación de objetos compuestos DICOM en la red, asi como soporte a funciones de bajo nivel. La clase que se encarga del autodescubrimiento es NetworkConfigurationFromMulticastDNS.

5.6.1 Clase NetworkConfigurationFromMulticastDNSEsta clase nos provee de un registro dinámico de los parametros de red DICOM posiblemente federados de varias fuentes

Las fuentes de informacion soportadas incluyen:

• DNS Self-Discovery (Auto descubrimiento)-> Bonjour de Apple

En general esta clase, es una utilidad que activa listeners para realizar la configuración dinámica y descargar el contenido periodicamente. Y registra adicionalmente un servicio DICOM en la maquina local.

5.6.1.1 Métodos de la clase

5.6.1.1.1 void activateDiscovery ( int refreshInterval)Este método inicia el autodescubrimiento DNS (DNS Self-Discovery), si es posible.

5.6.1.1.2 void deActivateDiscovery ()Este método detiene el autodescubrimiento DNS (DNS Self-Discovery)

5.6.1.1.3 void registerDicomService (String calledApplicationEntityTitle, int port, String primaryDeviceType)Con este método se registra un servicio DICOM en el localhost

5.6.1.1.4 void registerWADOService(String instanceName, int port, String path)Registra un servicio WADO en el localhost

5.6.1.2 Constructor NetworkConfigurationFromMulticastDNS(int debugLevel) Construye una instancia capaz de manejar la informacion de una configuración dinámica pero no la inicia aun.

5.7 Archivos JarPara el correcto funcionamiento del sistema se debe de contar con los siguientes archivos jar

El sistema cuenta con el siguiente archivo jar:

• pixelmed.jar: contiene la aplicacion y las librerias DICOM

Ademas, los siguientes archivos jar, encontrados en en el directorio lib, son requeridos para el correcto funcionamiento:

• jpedal.jar: Contiene suporte para leer y renderear PDF:

• hsqldb.jar: Contiene la base de datos Hypersonic

• excalibur-bzip2-1.0.jar: Contiene soporte para el algoritmo de compresion bzip2 (necesario para una transferencia de sintaxis privada)

• vecmath1.2-1.14.jar: Contiene una implementacion de Java 3D vector math routines

• jmdns.jar: Contiene soporte para Multicast DNS (mDNS) y DNS Self Discovery (DNS-SD) usado por zeroconf network configuration (Apple's Bonjour)

• commons-codec-1.3.jar: Contiene codificacion de el nombre de la persona usando mecanismos foneticos como Soundex y Metaphone; usado para nombres de personas identicos en consultas.

Tambien el siguiente archivo jar, encontrado en l lib/xmlpack, es requerido para validacion:

• xmlpack.jar: Contiene soporte Sun y Apache XML. Incluye varios componentes extraidos de el paquete Sun Java Web Services Developer, ya que tambien contiene soporte xml y xslt

5.8 Archivo Properties sistema de Visualización

El sistema de visualización puede ser ejecutado sin el archivo properties, lo que ocasionaría que las funcionalidades de la red fueran limitadas, pero gracias a la implementación de Bonjour, se configura automáticamente usando multi-cast DNS selfdiscovery.

Para realizar una configuración apropiada es necesario editar el archivo properties .com.pixelmed.display.DicomImageViewer, este archivo debe localizarse en el directorio del usuario (C:\Documents and Settings\username\).

5.9 Archivo Properties AlmacenamientoPara ser ejecutado correctamente el sistema de almacenamiento necesita de un archivo properties. En este archivo se guarda la configuración para el correcto funcionamiento del sistema de almacenamiento, el cual es cargado cuando se ejecuta la aplicación. Este archivo debe estar localizado en el directorio en donde se encuentra la aplicación.

6 Bibliografía• Pixelmed Publishing (javadoc) http://www.pixelmed.com/

• Introduction to business modeling using the Unified Modeling Language (UML) http://www-128.ibm.com/developerworks/rational/library/360.html

• JDICOM: Java DICOM Tools http://members.chello.at/petra.kirchdorfer/jdicom/

• DICOM Conformance http://www.wwbiz.ch/digitima/adv_dico.htm

• Medical Imaging in IDL http://idlastro.gsfc.nasa.gov/idl_html_help/Medical_Imaging_in_IDL.html

• Cost and Benefits of PACS, Shawn H. Becker, Ronald L. Arenson. MD

• Intrododuction to business modeling

• Distributing Medical Images with Internet Technologies: A DICOM Web Server and a DICOM Java Viewer, Jo s e p Fernàndez- Bayó, MSc • Octavio Barb e r o, MSc • Carle s Rubie s, Msc Melcio r Sentís, MD • Lluis Dono s o, MD, PhD

• DICOM Conformance Statement

http://idlastro.gsfc.nasa.gov/idl_html_help/Medical_Imaging_in_IDL.html

http://www.wwbiz.ch/digitima/adv_dico.htm

http://members.chello.at/petra.kirchdorfer/jdicom/

http://www-128.ibm.com/developerworks/rational/library/360.html

http://www.pixelmed.com/