Autorizada la entrega del proyecto al alumno: FRANCISCO JOSÉ VALDIVIESO RUIZ EL DIRECTOR DEL PROYECTO ALBERTO GARCÍA PAÑOSO. Fecha:... /... /...

Transcripción

1 Autorizada la entrega del proyecto al alumno: FRANCISCO JOSÉ VALDIVIESO RUIZ EL DIRECTOR DEL PROYECTO ALBERTO GARCÍA PAÑOSO Fdo:... Fecha:... /... /... Vº Bº del Coordinador de Proyectos EDUARDO ALCALDE LANCHARRO Fdo:... Fecha:... /... /...

2 UNIVERSIDAD PONTIFICIA COMILLAS ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA (ICAI) INGENIERO TÉCNICO EN INFORMÁTICA DE GESTIÓN PROYECTO FIN DE CARRERA AUTOMATIZACIÓN, OPTIMIZACIÓN E IMPLEMENTACIÓN DE SISTEMAS DE DIAGNÓSTICO HOSPITALARIOS AUTOR: FRANCISCO JOSÉ VALDIVIESO RUIZ MADRID, SEPTIEMBRE DE 2009

3 Agradecimientos En especial, quiero agradecer a mi padre, mi madre y mis hermanos el apoyo que he recibido por su parte, durante este largo camino. De la misma forma, me gustaría hacer mención a todo el equipo de trabajo de SATEC, en especial a Alberto, ya que sin él, este proyecto no hubiese sido posible, agradeciéndole toda la ayuda y lo aprendido de su trabajo. I

4 Resumen El proyecto que se presenta a continuación, acomete de una forma simplificada todos los procesos necesarios en la automatización y optimización de un tratamiento oncológico. Estos tratamientos son procesos muy complejos que requieren una unificación de diversos y distintos factores, que deben trabajar de una forma conjunta para su correcto funcionamiento. Por ello, se considera necesaria la creación de un sistema que ayude a gestionar todo este modelo de trabajo y que sirva de herramienta de apoyo para todo este conjunto de personas y sistemas que forman parte de él. Este proyecto abordará no sólo la creación e identificación de estos procesos, sino que concluirá con la automatización de estos. De esta forma se conseguirá un sistema que automáticamente genere y trate la información del proceso de radioterapia, prestando un servicio nuevo y coordinado a todos sus usuarios. El núcleo del sistema son procesos de negocio (en este caso el negocio es el tratamiento oncológico), que se diseñarán y ejecutarán con una Suite BPM de libre distribución. Puesto que el uso de estos procesos desde los interfaces que proporciona el fabricante del producto puede ser incómodo para el usuario final, se decide crear un interfaz Web que facilite dicho uso. Por tanto, el sistema se plantea como una aplicación Web que reside en un servidor y que, a través de servicios Web, utilizará los procesos de negocio previamente creados. Debido a la complejidad del entorno, será necesario simular ciertos subsistemas. En un caso real, un hospital ya contaría con su sistema hospitalario, pero en este caso se simulará mediante una comunicación basada en el estándar HL7, que facilitará esta comunicación entre cualquier sistema clínico y este desarrollo. II

5 Otro problema se plantea en los dispositivos con los que cuenta la unidad de oncología de un hospital real. Puesto que no se dispone de esos dispositivos se tendrán que simular de una forma sencilla. Dado que todo el proceso esta basado en un tratamiento oncológico, se requiere un sistema capaz de visualizar las distintas imágenes necesarias para su correcto diagnóstico. Para ello, se utilizará una aplicación basada en un applet Java que permitirá visualizar tanto las imágenes como los datos asociados a cada una de estas imágenes. Esta aplicación estará accesible en cualquier punto a lo largo del proceso ya que la funcionalidad de este visualizador se considera necesaria en cualquiera de los pasos del proceso. Finalmente, se desarrollará un monitor que permitirá el seguimiento de cada uno de los tratamientos a través de registros creados en base a los pasos que se irán realizando en cada tarea. De esta forma se podrá controlar, de una forma sencilla, en que punto se encuentra cada uno de los tratamientos generados. III

6 Abstract The project to be presented below, undertake from a simplified way, all the necessary processes in the automation and optimization of a cancer treatment. These treatments are very complex processes that require the unification of several and diferents factors, which must work all jointly, for the correct functioning. Therefore, it is considered necessary to create a system that helps to manage all this model of work and to serve as tool of support for all the entire set of people and systems that are part of it. This project will deal with not only the creation and identification of these processes, by the same way it will conclude with the automation of them. By this way, will be achieved a system that automatically generate and discuss the information of the process of radiation, providing a new service coordinated with all its users. Since the use of these processes from the interfaces that provides the product manufacturer, can be uncomfortable for the end user, the decision is to create a Web interface to facilitate such use. Therefore, the system arises as a Web application that resides in a server, and that, through Web services, will use the business processes previously created. Because of the complexity of the environment, it will be necessary simulate certain subsystems. In a real case, a hospital already would have its hospital system, but in this case is simulated in a communication based on the standard HL7, which will facilitate this communication between any clinical system and this development. Given that the entire process is based on a cancer treatment, requires a system capable of displaying the different images necessary for its proper diagnosis. To that end, will be used an application based on a Java applet that will allow display both images as the data associated with each of these images. This application will be IV

7 accessible at any point along the process since the functionality of this display is considered necessary. Finally, develop a monitor that will allow the follow-up to each of the treatments through records created on the basis of steps that will be carried out in each task. In this way, it can control, in a simple way, in which point is each one of the treatments generated. V

8 ÍNDICE DE CONTENIDO 1.INTRODUCCIÓN MOTIVACIÓN DEL PROYECTO METODOLOGÍA DE DESARROLLO EXPLICACIÓN DEL DOCUMENTO IDENTIFICACIÓN DE NECESIDADES OBJETIVOS DEL SISTEMA ALCANCE DEL SISTEMA TIPOLOGÍA DE USUARIOS Oncólogo Dosimetrista Radioterapeuta Paciente Administrador Administrador HIS ORGANIZACIÓN EMPRESARIAL ANALISIS DE REQUISITOS LISTA DE REQUISITOS MODELO DE CASOS DE USO Modelo de Dominio Modelo de Casos de Uso de Sistema Modelo de Diseño ESTUDIO DE ARQUITECTURA ESPECIFICACIÓN DE LA ALTERNATIVA Necesidades de Software Necesidades de Hardware Necesidades de Comunicaciones ESPECIFICACIÓN DE LA ALTERNATIVA VI

9 4.2.1.Necesidades de Software Necesidades de Hardware Necesidades de Comunicaciones EVALUACIÓN OPERATIVA, TÉCNICA Y ESTRATÉGICA Matriz de Evaluación Operativa Matriz de Evaluación Técnica Matriz de Evaluación Estratégica EVALUACIÓN ECONÓMICA Costes de Implantación Costes de Adquisición de Tecnología Costes Operacionales SELECCIÓN DE LA ALTERNATIVA DISEÑO ENTORNO OPERATIVO DEL SISTEMA Entrada, salida y recogida de datos Generación de informes y formularios Control de información y seguridad del sistema CONFIGURACIÓN HARDWARE/SOFTWARE DESARROLLO DE LOS PROCESOS DE NEGOCIO Proceso de Radioterapia Evaluación Inicial Localización Plan de Irradiación Simulación Aplicación del Tratamiento MANUAL DE USUARIO Introducción Descripción General de RO Information System Acceso al Sistema Funcionalidades del Sistema de Radioterapia Funcionalidades del Sistema de Monitorización Funcionalidades del Visualizador DICOM Planificación Temporal Conclusiones Bibliografía 109 VII

10 Apéndice A. Introducción a BPMN 111 Apéndice B. Servicios Web 122 Apéndice C. XSL (Extensible StyleSheet Language) 134 Apéndice D. Listado de Acrónimos 137 VIII

11 ÍNDICE DE TABLAS Tabla 1: Lista de requisitos...16 Tabla 2: Requisito "Perfiles de Usuario"...17 Tabla 3: Requisito "Imagen Asociativa"...17 Tabla 4: Requisito "Seguridad de Acceso a cada perfil"...17 Tabla 5: Requisito "Menú de Tareas"...18 Tabla 6: Requisito "Carga de Formularios"...18 Tabla 7: Requisito "Firma de Formularios"...18 Tabla 8: Requisito "Monitorización de Procesos"...19 Tabla 9: Requisito "Seguridad de Acceso a monitorización"...19 Tabla 10: Requisito "Datos Monitorizados"...19 Tabla 11: Requisito "Visualización del estado de dispositivos"...20 Tabla 12: Requisito "Historial Clínico del paciente"...20 Tabla 13: Requisito "Visualización de imágenes DICOM"...20 Tabla 14: Requisito "Subproceso de Evaluación Inicial"...21 Tabla 15: Requisito "Informe de Evaluación Inicial"...21 Tabla 16: Requisito "Informe de Decisión Terapéutica"...21 Tabla 17: Requisito "Subproceso Localización"...22 Tabla 18: Requisito "Informe de Localización"...22 Tabla 19: Requisito "Subproceso Plan Irradiación...22 Tabla 20: Requisito "Informe Dosimétrico"...23 Tabla 21: Requisito "Subproceso Simulación"...23 Tabla 22: Requisito "Informe de Colocación Simulada"...23 IX

12 Tabla 23: Requisito "Informe Verificación Simulada"...24 Tabla 24: Requisito "Informe de Resultado de Simulación"...24 Tabla 25: Requisito "Subproceso Aplicación...24 Tabla 26: Requisito "Informe Colocación Aplicada"...25 Tabla 27: Requisito "Informe Verificación Aplicada"...25 Tabla 28: Requisito "Informe Resultado Aplicación"...25 Tabla 29: Requisito "Procesos de Negocio basados en BPM"...26 Tabla 30: Requisito "Uso de herramienta OpenSource "...26 Tabla 31: Requisito "Versión Mobile "...26 Tabla 32: Requisito "Comunicación HL7"...27 Tabla 33: Requisito "Campos de Datos de Paciente bajo HL7"...27 Tabla 34: Requisito "Comunicación entre subprocesos (WSDL)"...27 Tabla 35: Casos de Uso: Generación de Cita...31 Tabla 36: Casos de Uso: Monitorización Registros Tratamientos...31 Tabla 37: Casos de Uso: Completar Evaluación Inicial...31 Tabla 38: Casos de Uso: Realizar Decisión Terapéutica...32 Tabla 39: Casos de Uso: Firmar Decisión Terapéutica...32 Tabla 40: Casos de Uso: Completar Informe Localización...32 Tabla 41: Casos de Uso: Completar Informe Dosimétrico...33 Tabla 42: Casos de Uso: Firmar Informe Dosimétrico...33 Tabla 43: Casos de Uso: Simular Colocación...33 Tabla 44: Casos de Uso: Simular Verificación...34 Tabla 45: Casos de Uso: Completar Informe Simulación...34 Tabla 46: Casos de Uso: Firmar Informe Simulación...34 Tabla 47: Casos de Uso: Aplicar Colocación...35 Tabla 48: Casos de Uso: Aplicar Verificación...35 X

13 Tabla 49: Casos de Uso: Completar Informe Aplicación...35 Tabla 50: Casos de Uso: Aceptar Informe Aplicación...36 Tabla 51: Casos de Uso: Visualizar Imágenes...36 Tabla 52: Características de Hardware Alternativa Tabla 53: Características de Hardware Alternativa Tabla 54: Matriz de Evaluación Operativa...46 Tabla 55: Matriz de Evaluación Técnica...46 Tabla 56: Matriz de Evaluación Estratégica...47 Tabla 57: Costes de Implantación...48 Tabla 58: Costes de Adquisición de Tecnología...48 Tabla 59: Costes Operacionales...49 XI

14 ÍNDICE DE ILUSTRACIONES Ilustración 1: Organigrama de un hospital...11 Ilustración 2: Organigrama. Departamentos implicados...11 Ilustración 3: Modelo de Dominio...29 Ilustración 4: Modelo de Casos de Uso de Sistema...30 Ilustración 5: Modelo de Diseño...37 Ilustración 6: Intalio...39 Ilustración 7: Eclipse...39 Ilustración 8: Geronimo...40 Ilustración 9: PostGreSQL...40 Ilustración 10: Dell PowerEdge 2970 server...41 Ilustración 11: JBPM...42 Ilustración 12: MySQL...43 Ilustración 13: Dell R805 server...44 Ilustración 14: Gráfico de Valoración de Alternativas...47 Ilustración 15: Coste Total...49 Ilustración 16: Configuración Hardware/Software...56 Ilustración 17: Proceso de Radioterapia 1/ Ilustración 18: Proceso de Radioterapia 2/ Ilustración 19: Proceso de Radioterapia 3/ Ilustración 20: Subproceso Evaluación Inicial 1/ Ilustración 21: Subproceso Evaluación Inicial 2/ Ilustración 22: Subproceso Evaluación Inicial 3/ XII

15 Ilustración 23: Subproceso Localización...67 Ilustración 24: Subproceso Plan de Irradiación...69 Ilustración 25: Subproceso Simulación 1/ Ilustración 26: Subproceso Simulación 2/ Ilustración 27: Subproceso Aplicación del Tratamiento 1/ Ilustración 28: Subproceso Aplicación del Tratamiento 2/ Ilustración 29: Subproceso Aplicación del Tratamiento 3/ Ilustración 30: RT: Pantalla de Acceso...80 Ilustración 31: RT: Pantalla de Acceso "Mobile"...81 Ilustración 32: RT: Pantalla de Acceso Monitor...82 Ilustración 33: RT: Pantalla Principal...82 Ilustración 34: RT: Evaluación Inicial 1/ Ilustración 35: RT: Evaluación Inicial 2/ Ilustración 36: RT: Decisión Terapéutica 1/ Ilustración 37: RT: Decisión Terapéutica 2/ Ilustración 38: RT: Aceptación del tratamiento por parte del paciente...89 Ilustración 39: RT: Informe de Localización 1/ Ilustración 40: RT: Informe de Localización 2/ Ilustración 41: RT: Informe Dosimétrico 1/ Ilustración 42: RT: Informe Dosimétrico 2/ Ilustración 43: RT: Aceptación del Oncólogo...93 Ilustración 44: RT: Simulación - Colocación...95 Ilustración 45: RT: Simulación - Verificación de parámetros...96 Ilustración 46: RT: Informe de Simulación...97 Ilustración 47: RT: Aceptación de la Simulación...97 Ilustración 48: RT: Inicio de Aplicación...99 XIII

16 Ilustración 49: RT: Aplicación - Colocación Ilustración 50: RT: Aplicación - Verificación de parámetros Ilustración 51: RT: Informe de Aplicación Ilustración 52: RT: Monitor del Sistema Ilustración 53: Radscaper Ilustración 54: Radscaper Ilustración 55: Diagrama sencillo BPM Ilustración 56: Eventos I Ilustración 57: Eventos II Ilustración 58: Actividades I Ilustración 59: Actividades II Ilustración 60: GateWays I Ilustración 61: GateWays II Ilustración 62: GateWays III Ilustración 63: GateWays IV Ilustración 64: Pools Ilustración 65: Conectors I Ilustración 66: Conectors II Ilustración 67: Conectors III Ilustración 68: Conectors VI Ilustración 69: Conectors V Ilustración 70: Conectors VI Ilustración 71: Conectors VII Ilustración 72: Flujos de Secuencia Ilustración 73: Flujos de Mensajes Ilustración 74: Arquitectura de comunicaciones de los servicios Web XIV

17 Ilustración 75: Estructura Mensaje SOAP XV

18 1. INTRODUCCIÓN 1.1. MOTIVACIÓN DEL PROYECTO Actualmente se vive en un entorno en el que la tecnología forma parte de la propia vida. De la misma forma, uno de los aspectos fundamentales de este día a día es la salud. Por ello, la investigación y desarrollo de productos que integren estos dos factores, tecnología y salud, siempre supondrá un avance y a su vez, un acierto. De esta forma y gracias a la idea impulsada por SATEC, empresa que propuso el proyecto y propuso su realización, se plantea una idea innovadora enfocada hacia la automatización de los procesos necesarios en un tratamiento oncológico. Desde el primer momento en el que este proyecto comenzó a tomar forma, fue latente la verdadera proyección que un proyecto de esta envergadura puede llegar a alcanzar. 1

19 La gestión de los procesos sanitarios es un proceso realmente complejo, pero que a su vez, supone un gran reto que no solo implica su desarrollo, sino que también trata su optimización METODOLOGÍA DE DESARROLLO Tras evaluar de una forma general el proyecto y habiendo analizado posteriormente las distintas alternativas que la Ingeniería de Software ofrece, se ha elegido para el análisis, elaboración y construcción de dicho proyecto el Proceso Unificado de Desarrollo de Software como modelo a seguir en este trabajo. El Proceso Unificado es un marco de desarrollo iterativo e incremental caracterizado por estar dirigido por casos de uso y centrado en la arquitectura. Una vez desarrollada la primara fase, utilizando el Proceso Unificado, se pasará a seguir las fases de alternativas y diseño de la arquitectura que especifica el Proceso Estructurado de análisis de procesos EXPLICACIÓN DEL DOCUMENTO El presente documento se ha estructurado en una serie de capítulos principales y varios apéndices considerados de interés y utilidad. A continuación se explica cada uno de ellos: Este primer capítulo, Introducción, contiene la motivación del proyecto y un pequeño resumen de la metodología a utilizar a lo largo del proyecto. El segundo capítulo, Identificación de necesidades, presenta los diferentes objetivos que se abordarán, el alcance del sistema, que ayudará a delimitar las 2

20 funcionalidades, una clasificación y tipología de usuarios y, por último, los diagramas correspondientes a la organización empresarial, que identificarán los departamentos que englobará el sistema. El tercer capítulo, Análisis de requisitos, contiene la lista de requisitos necesarios dada por el cliente y el modelo de casos de uso, que ayudará a diseñar, de una forma gráfica, los primeros pasos del sistema. En el cuarto capítulo, Estudio de arquitectura, se plantean las posibles alternativas, tanto a nivel software como a nivel hardware. Una vez definidas se realizarán los estudios operativos, técnicos y estratégicos y, junto con la evaluación económica de cada una de ellas, se completará este capítulo con la selección de la mejor alternativa. El quinto capítulo, Diseño, describe el diseño que se ha seguido en el desarrollo del proyecto. En primer lugar, se describe la visión general de la aplicación y su arquitectura, después, se describe detalladamente el diseño de la aplicación mediante diagramas BPM con sus correspondientes comentarios. En el capítulo sexto, Manual de usuario, se describen de forma detallada, todos los pasos necesarios para la utilización del sistema, así como el uso de todas las funcionalidades previamente descritas. En el capítulo séptimo, Planificación Temporal, describe de forma gráfica, el desarrollo que ha tenido el proyecto y la duración de cada una de las etapas a lo largo del año. En el capítulo octavo, Conclusiones, realiza un breve análisis de todos los resultados obtenidos a raíz del estudio realizado. 3

21 El último capítulo, Bibliografía, contiene toda la bibliografía utilizada para la realización del presente proyecto. En el primer apéndice, Introducción a BPMN, se realiza una breve explicación y documentación de esta metodología, utilizada en el desarrollo del proyecto. En el segundo apéndice, Servicios Web, se definen las características de estos elementos utilizados en la comunicación entre procesos. El tercer apéndice, XSL (Extensible StyleSheet Language), describe las transformaciones de documentos XML y su presentación, desarrollados por el W3C. Y por último, Listado de acrónimos, se recopilan todos los acrónimos, junto con su significado, usados en el presente documento. 4

22 2. IDENTIFICACIÓN DE NECESIDADES Esta etapa es el primer acercamiento a las necesidades generales del cliente y al contexto en el que se desarrollará el sistema propuesto. El objetivo de esta etapa es, por tanto, recopilar información para definir los Objetivos que se plantea el cliente con el desarrollo de este sistema, su Alcance, la Tipología de Usuarios del sistema y la Organización Empresarial del cliente. Con el fin de alcanzar un conocimiento real y lo más preciso posible, se utilizará como principal herramienta, en esta etapa, entrevistas a personas claves como médicos especialistas en oncología radioterápica u operadores de la unidad de tratamiento de la organización OBJETIVOS DEL SISTEMA Como organizaciones complejas que son, los hospitales, debido a su propia actividad, deben manejar una gran cantidad de información. Un punto importante es el requerimiento de un profundo análisis de los sistemas de información de un hospital, ya que todos los elementos que interactúan necesitan ser reunidos, 5

23 procesados y suplementados para dar una completa información a las diferentes actividades del hospital. El objetivo principal del estudio se centrará en el análisis de los distintos procesos necesarios en la gestión del hospital, focalizándolo en las tareas necesarias para la realización de un diagnóstico y posterior tratamiento oncológico. Se estudiarán todas las fases de diagnóstico, desde el alta de paciente hasta el seguimiento del tratamiento establecido por el especialista, integrándolo junto a los diferentes servicios hospitalarios anteriormente mencionados. En más detalle, los objetivos principales que se persiguen se podrían resumir en los siguientes puntos: Integración y comunicación, mediante los estándares de intercambio electrónico de información médica definidos por HL7, del sistema y el Sistema de Información Hospitalaria (HIS), también llamado Sistema de Información Clínica (CIS), que es un sistema de información integrado diseñado para manejar los aspectos administrativos, financieros y clínicos de un hospital. Utilización del estándar Integrating the Healthcare Enterprise (IHE), que especificará las mejores prácticas de integración de los sistemas de información necesarios en la atención al paciente. Estudio de la viabilidad de la implantación de un sistema de procesos (BPM), que permita la automatización de los procesos típicos necesarios en el ámbito oncológico. 6

24 Estudio de la posible integración del sistema BPM con herramientas de terceros, como por ejemplo, los sistemas de almacenamiento de imágenes DICOM ALCANCE DEL SISTEMA Como establece el primer objetivo indicado en el punto anterior, el sistema que se desarrollará, tendrá como punto de entrada una petición recibida del HIS del hospital, por ello se puede decir que el sistema cubrirá el proceso de diagnóstico oncológico desde esta petición. Por ello, no se contempla ninguno de los procesos necesarios para la generación de la cita previa del paciente, y de la misma forma, no se contemplarán ni desarrollarán los procesos intermedios necesarios en otros departamentos para la comunicación con el sistema (Radiología o Laboratorios Clínicos). Partiendo de estas premisas, las funcionalidades del sistema serán: Automatización del tratamiento oncológico, consiguiendo así una optimización de proceso de diagnóstico. Acceso a la información, obtenida por los distintos departamentos, desde cualquier equipo de la red y en cualquier fase de dicho tratamiento. Posibilidad de consultar y comparar imágenes en formato DICOM de manera remota. Comunicación unificada de los distintos sistemas de información que componen el proceso, independientemente de su marca o modelo. 7

25 Visualización, en forma de lista, de tareas diarias. Utilización del estándar de información clínica HL7, para una mayor integración en cualquier sistema TIPOLOGÍA DE USUARIOS Los usuarios o actores implicados en el sistema serán: Oncólogo Médico especialista en Oncología Radioterápica, cuyas funciones principales son las siguientes: Evaluar al paciente y determinar cuál es el tratamiento adecuado. Decidir el área a tratar y la radiación a suministrar a partir de los datos obtenidos tanto de la localización como del plan de irradiación. Elaborar y prescribir el plan de tratamiento para cada paciente, y se asegura de que éste se administre correctamente. Monitorizar la evolución del paciente y modificar el tratamiento para que los pacientes reciban atención de alta calidad durante el tratamiento. Identificar y tratar los efectos secundarios de la radioterapia Dosimetrista Médico especialista que establece y determina la dosis correcta de radiación para un tratamiento, cuyas funciones principales son las siguientes: 8

26 Realizar una propuesta terapéutica en base a la enfermedad, el estado del paciente y medios disponibles, para conseguir un tratamiento acorde con el caso. Calcular cuidadosamente la dosis de radiación necesaria para un tumor. Elaborar planes de tratamiento para destruir lo más eficazmente posible el tumor, al mismo tiempo que se protegen los tejidos normales. Colaborar con el oncólogo y el radiofísico para elegir el plan de tratamiento indicado para cada paciente Radioterapeuta Profesional de la salud encargado de la administración del tratamiento de radioterapia establecido, cuyas funciones principales son las siguientes: Suministrar los tratamientos diarios a los pacientes, previa prescripción y supervisión del oncólogo. Mantener el registro diario y revisar las máquinas periódicamente para cerciorarse de que funcionan bien Paciente Persona que necesita de un tratamiento de radioterapia. Su papel dentro del sistema se limitará a firmar la aceptación del Informe Dosimétrico establecido para su caso. 9

27 Administrador Usuario del sistema que tendrá la posibilidad de monitorizar el estado concreto en el que se encuentra un determinado tratamiento de un paciente Administrador HIS Usuario ajeno al sistema, que será el encargado del inicio del proceso de radioterapia, generando una cita con el especialista desde el sistema gestor del hospital. 10

28 2.4. ORGANIZACIÓN EMPRESARIAL Ilustración 1: Organigrama de un hospital Ilustración 2: Organigrama. Departamentos implicados 11

29 Dentro de la Ilustración 1: Organigrama de un hospital, se puede observar, marcados en rojo, los departamentos que formarán parte del sistema, y de la misma forma, lo delimitarán. Marcado en naranja, el departamento de Imagenología, que únicamente servirá de apoyo a el sistema, pero no intercediendo en el proceso de negocio. La Ilustración 2: Organigrama. Departamentos implicados, ayuda a entender de una forma más precisa, donde están ubicados exactamente los actores principales, que formarán parte del proceso de negocio, dentro del organigrama empresarial. 12

30 3. ANALISIS DE REQUISITOS En esta etapa se busca un conocimiento en profundidad del problema planteado. Para ello, es necesario conocer y describir con rigor los requisitos de los usuarios. Será necesario, por tanto, tener contacto con los usuarios finales del sistema y obtener conocimiento de sus experiencias anteriores con sistemas similares para poder aportar mejoras. La recopilación de toda esta información quedará plasmada mediante: Lista de Requisitos Modelo de Casos de Uso Modelo de Dominio Modelo de Casos de Usos del Sistema Modelo de Diseño 13

31 3.1. LISTA DE REQUISITOS En este apartado se presentan una serie de tablas que recogen los requisitos acordados en las reuniones con los futuros usuarios del sistema. En primer lugar, se muestra una tabla que recoge todos los requisitos del sistema, sus códigos y el tipo de requisito, para facilitar una consulta rápida. Las tablas que siguen a la lista de requisitos son las fichas de cada uno de los requisitos, que analizan con más detalle cada uno de ellos. Cada requisito está referenciado con un código único que aporta información sobre el mismo. Dicho código presenta el siguiente formato: R.[Secuencia].[Subsecuencia].[Tipo] [Tipo] puede tomar los siguientes valores dependiendo del tipo de requisito al que haga referencia: F: Funcional O: Operativo S: Seguridad [Secuencia] se refiere a la numeración de los requisitos principales. [Subsecuencia] serie de valores que enumerará los requisitos dependientes de los principales. 14

32 Código Nombre Tipo R F Perfiles de Usuario Funcional R F Imagen Asociativa a cada perfil Funcional R S Seguridad de Acceso a cada perfil Seguridad R F Menú de Tareas Funcional R F Carga de Formularios Funcional R S Firma de Formularios Seguridad R F Monitorización de procesos Funcional R S Seguridad de Acceso a monitorización Seguridad R F Datos Monitorizados Funcional R F Visualización del estado de dispositivos Funcional R F Historial Clínico del paciente Funcional R F Visualización de imágenes DICOM Funcional R F Subproceso Evaluación Inicial Funcional R F Informe de Evaluación Inicial Funcional R F Informe de Decisión Terapéutica Funcional R F Subproceso Localización Funcional 15

33 R F Informe de Localización Funcional R F Subproceso Plan Irradiación Funcional R F Informe Dosimétrico Funcional R F Subproceso Simulación Funcional R F Informe Colocación Simulada Funcional R F Informe Verificación Simulada Funcional R F Informe de Resultado Simulación Funcional R F Subproceso Aplicación Funcional R F Informe Colocación Aplicada Funcional R F Informe Verificación Aplicada Funcional R F Informe Resultado Aplicación Funcional R O Procesos de Negocio basados en BPM Operativo R O Uso de herramienta OpenSource Operativo R O Versión Mobile Operativo R O Comunicación HL7 Operativo R O Campos de Datos de Paciente bajo HL7 Operativo R O Comunicación entre subprocesos (WSDL) Operativo Tabla 1: Lista de requisitos 16

34 Código Tipo R F Funcional Nombre Perfiles de Usuario Descripción Se establecerán tres tipos de usuarios diferentes: oncólogo, radioterapeuta y dosimetrista; cada uno de ellos con funcionalidades distintas. Tabla 2: Requisito "Perfiles de Usuario" Código Tipo R F Funcional Nombre Imagen Asociativa a cada perfil Descripción Cada uno de los perfiles tendrá asociado una imagen, que será mostrada al iniciar su sesión, en la parte superior derecha. Tabla 3: Requisito "Imagen Asociativa" Código Tipo R S Seguridad Nombre Seguridad de Acceso a cada perfil Descripción El acceso de cada uno de los usuarios se establecerá mediante un nombre de usuario y contraseña, que deberá de introducirse siempre que se intente comenzar una sesión. Tabla 4: Requisito "Seguridad de Acceso a cada perfil" 17

35 Código Tipo R F Funcional Nombre Menú de Tareas Descripción Dentro de cada sesión, existirá un menú que deberá ser colocado en la parte izquierda de la pantalla y contener los apartados de procesos, notificaciones y tareas pendientes. Tabla 5: Requisito "Menú de Tareas" Código Tipo R F Funcional Nombre Carga de Formularios Descripción Cada uno de los formularios que la aplicación cargará, serán mostrados en la parte derecha de la pantalla. Tabla 6: Requisito "Carga de Formularios" Código Tipo R S Seguridad Nombre Firma de Formularios Descripción En esta primera versión, la firma de formularios, tanto por el paciente como por el oncólogo, será realizada mediante un selectbox, dejando para un posterior desarrollo la firma de documentos mediante firma electrónica. Tabla 7: Requisito "Firma de Formularios" 18

36 Código Tipo R F Funcional Nombre Monitorización de Procesos Descripción Se deberá implementar un sistema de monitorización, solo accesible por el usuario Administrador, que mostrará los pasos completados en cada uno de los niveles del proceso de negocio, en este caso dicho proceso se corresponde con el tratamiento. Tabla 8: Requisito "Monitorización de Procesos" Código Tipo R S Seguridad Nombre Seguridad de Acceso a monitorización Descripción El acceso se establecerá mediante un número de tratamiento que deberá introducirse siempre que se intente visualizar dicho tratamiento. Tabla 9: Requisito "Seguridad de Acceso a monitorización" Código Tipo R F Funcional Nombre Datos Monitorizados Descripción Los datos mínimos a monitorizar serán: Nombre de la tarea, especialista que la realiza, descripción y fecha de realización. Tabla 10: Requisito "Datos Monitorizados" 19

37 Código Tipo R F Funcional Nombre Visualización del estado de dispositivos Descripción Dentro de esta monitorización de registros se incluirá una visualización del estado actual de los dispositivos de radioterapia, tanto del PPS (Patient Positioning System) como del TDD (Treatment Delivery Device). Tabla 11: Requisito "Visualización del estado de dispositivos" Código Tipo R F Funcional Nombre Historial Clínico del paciente Descripción Posibilidad del acceso al Historial Clínico del paciente desde el formulario de la Evaluación Inicial. Tabla 12: Requisito "Historial Clínico del paciente" Código Tipo R F Funcional Nombre Visualización de imágenes DICOM Descripción Posibilidad de acceso a las imágenes de diagnóstico en formato DICOM, desde cualquiera de los formularios. Tabla 13: Requisito "Visualización de imágenes DICOM" 20

38 Código Tipo R F Funcional Nombre Subproceso de Evaluación Inicial Descripción Subproceso que incluirá la primera valoración del paciente, a la vez que la decisión sobre el tratamiento adecuado en su caso. Tabla 14: Requisito "Subproceso de Evaluación Inicial" Código Tipo R F Funcional Nombre Informe de Evaluación Inicial Descripción Contendrá los datos del paciente y su Historial Clínico. Deberá completarse con los datos de la primera toma de contacto del paciente con el oncólogo. Tabla 15: Requisito "Informe de Evaluación Inicial" Código Tipo R F Funcional Nombre Informe de Decisión Terapéutica Descripción Bajo la primera evaluación y los datos recogidos por las pruebas requeridas (imágenes, análisis), se tomará una decisión sobre el tratamiento más adecuado para el paciente, que posteriormente deberá firmar con su consentimiento. Tabla 16: Requisito "Informe de Decisión Terapéutica" 21

39 Código Tipo R F Funcional Nombre Subproceso Localización Descripción Subproceso que establecerá, una vez aceptado el tratamiento del paciente, el lugar especifico donde el tratamiento debe de ser suministrado. Tabla 17: Requisito "Subproceso Localización" Código Tipo R F Funcional Nombre Informe de Localización Descripción Informe que indicará los parámetros donde el tratamiento deberá ser irradiado. Tabla 18: Requisito "Informe de Localización" Código Tipo R F Funcional Nombre Subproceso Plan Irradiación Descripción Subproceso que, una vez limitado el lugar de irradiación en el subproceso de localización, proporcionará las dosis necesarias en el tratamiento de radioterapia. Tabla 19: Requisito "Subproceso Plan Irradiación 22

40 Código Tipo R F Funcional Nombre Informe Dosimétrico Descripción Informe que fijará las proporciones de las dosis necesarias a irradiar en el tratamiento de radioterapia que, posteriormente, deberá de ser aceptado y firmado por el oncólogo. Tabla 20: Requisito "Informe Dosimétrico" Código Tipo R F Funcional Nombre Subproceso Simulación Descripción Con todos los datos adquiridos en los subprocesos de localización e irradiación, se realizará una simulación previa del tratamiento para su verificación por el departamento de radioterapia. Tabla 21: Requisito "Subproceso Simulación" Código Tipo R F Funcional Nombre Informe de Colocación Simulada Descripción Simulación de los datos recibidos en el informe de localización. Tabla 22: Requisito "Informe de Colocación Simulada" 23

41 Código Tipo R F Funcional Nombre Informe Verificación Simulada Descripción Simulación de los datos recibidos en el informe dosimétrico. Tabla 23: Requisito "Informe Verificación Simulada" Código Tipo R F Funcional Nombre Informe de Resultado de Simulación Descripción Informe que incluirá los datos resultantes de la simulación. Posteriormente deberá de ser aceptada por el oncólogo. En caso de ser rechazada se volverá a realizar los subprocesos de localización e irradiación. Tabla 24: Requisito "Informe de Resultado de Simulación" Código Tipo R F Funcional Nombre Subproceso Aplicación Descripción Una vez simulado correctamente el tratamiento, se procederá a la aplicación del mismo al paciente. Tabla 25: Requisito "Subproceso Aplicación 24

42 Código Tipo R F Funcional Nombre Informe Colocación Aplicada Descripción Aplicación de los datos recibidos en el informe de localización y aceptados en el subproceso de simulación. Tabla 26: Requisito "Informe Colocación Aplicada" Código Tipo R F Funcional Nombre Informe Verificación Aplicada Descripción Aplicación de los datos recibidos en el informe dosimétrico y aceptados en el subproceso de simulación. Tabla 27: Requisito "Informe Verificación Aplicada" Código Tipo R F Funcional Nombre Informe Resultado Aplicación Descripción Informe que incluirá los datos resultantes de la sesión de tratamiento. Posteriormente deberá de ser enviada al oncólogo Tabla 28: Requisito "Informe Resultado Aplicación" 25

43 Código Tipo R O Operativo Nombre Procesos de Negocio basados en BPM Descripción El diseño de los procesos deberá realizarse bajo la notación BPMN, utilizando sus diagramas de negocio Tabla 29: Requisito "Procesos de Negocio basados en BPM" Código Tipo R O Operativo Nombre Uso de herramienta OpenSource Descripción Utilización de una herramienta de Software Libre. Tabla 30: Requisito "Uso de herramienta OpenSource " Código Tipo R O Operativo Nombre Versión Mobile Descripción Realización de una versión Mobile,para su implantación en dispositivos móviles Tabla 31: Requisito "Versión Mobile " 26

44 Código Tipo R O Operativo Nombre Comunicación HL7 Descripción Integración y comunicación, mediante los estándares de intercambio electrónico de información médica definidos por HL7 Tabla 32: Requisito "Comunicación HL7" Código Tipo R O Operativo Nombre Campos de Datos de Paciente bajo HL7 Descripción La información mínima bajo el estándar HL7 será toda la referente a los datos personales del paciente, para así, permitir una mejor interoperabilidad con el HIS. Tabla 33: Requisito "Campos de Datos de Paciente bajo HL7" Código Tipo R O Operativo Nombre Comunicación entre subprocesos (WSDL) Descripción La invocación de los subprocesos, así como de cada uno de los pasos de los mismos, debe de ser posible a través de servicios Web, pudiéndose proporcionar un WSDL si así se requiera. Tabla 34: Requisito "Comunicación entre subprocesos (WSDL)" 27

45 3.2. MODELO DE CASOS DE USO En la elaboración del análisis previo del sistema se utilizarán los pasos previos definidos por el Modelo de Casos de Uso. Primeramente el análisis se centrará en un Modelo de Dominio que proporcionará una imagen conceptual muy general de cómo opera el negocio. Una vez finalizado este Modelo de Dominio, es necesario moverse entre los distintos Casos de Uso del sistema, que facilitarán de una forma esquemática las interacciones posibles que el usuario tiene con el sistema, para alcanzar resultados. Finalmente se pasará a la elaboración del Modelo de Diseño, cuyo propósito es el de describir la combinación de la información del Modelo de Dominio y el comportamiento de los Casos de Uso, con el objetivo de visualizar con mayor facilidad los objetos que el sistema contendrá y las funcionalidades que el sistema va a automatizar. 28

46 Modelo de Dominio Ilustración 3: Modelo de Dominio En este diagrama se puede ver una representación visual de las clases conceptuales u objetos que forman parte del sistema. Se puede entender a través de este diagrama como un el HIS generará una cita asociada a un paciente. Dicha cita será asociada a un tratamiento. Este tratamiento utilizará los sistemas necesarios para su aplicación y a su vez podrá acceder a las imágenes del paciente almacenadas en el PACS. Todos estos movimientos serán almacenados en una base de datos mediante los registros creados en cada uno de los niveles del proceso de negocio. 29

47 Modelo de Casos de Uso de Sistema Ilustración 4: Modelo de Casos de Uso de Sistema 30

48 Nombre: Generación de Cita Actores: Administrador HIS Tipo: Primario Descripción: El sistema gestor del hospital (HIS), manejado por, en este caso, el Administrador HIS, genera una cita con el oncólogo en el sistema. Tabla 35: Casos de Uso: Generación de Cita Nombre: Monitorización Registros Tratamientos Actores: Administrador Tipo: Primario Descripción: El Administrador del sistema de monitorización selecciona un tratamiento a visualizar y el sistema le presenta el detalle de dicho tratamiento. Tabla 36: Casos de Uso: Monitorización Registros Tratamientos Nombre: Completar Evaluación Inicial Actores: Oncólogo Tipo: Primario Descripción: El oncólogo completará este informe, donde se recogerán las primeras valoraciones para un posterior estudio del tratamiento más adecuado. Tabla 37: Casos de Uso: Completar Evaluación Inicial 31

49 Nombre: Realizar Decisión Terapéutica Actores: Oncólogo Tipo: Primario Descripción: Con todos los datos recogidos en la evaluación inicial (análisis, imágenes...), se completará el informe para establecer un pretratamiento para el paciente. Tabla 38: Casos de Uso: Realizar Decisión Terapéutica Nombre: Firmar Decisión Terapéutica Actores: Oncólogo, Paciente Tipo: Primario Descripción: Tras la decisión terapéutica, el oncólogo comunicará la decisión al paciente, que a su vez firmará la aceptación del tratamiento. Tabla 39: Casos de Uso: Firmar Decisión Terapéutica Nombre: Completar Informe Localización Actores: Oncólogo Tipo: Primario Descripción: Con los datos generados por las imágenes realizadas al paciente, se realizará un estudio para especificar las zonas implicadas en el tratamiento reflejadas en este informe. Tabla 40: Casos de Uso: Completar Informe Localización 32

50 Nombre: Completar Informe Dosimétrico Actores: Dosimetrista Tipo: Primario Descripción: El dosimetrista, una vez recibido el informe de localización y con los datos previos del tratamiento, completará el informe que indicará las dosis exactas a irradiar en el paciente. Tabla 41: Casos de Uso: Completar Informe Dosimétrico Nombre: Firmar Informe Dosimétrico Actores: Oncólogo Tipo: Primario Descripción: El oncólogo deberá firmar este informe, que una vez aceptado, dará paso a la simulación y posterior aplicación. Tabla 42: Casos de Uso: Firmar Informe Dosimétrico Nombre: Simular Colocación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará la simulación de la colocación del paciente en función a los datos recibidos en los informes de localización. Tabla 43: Casos de Uso: Simular Colocación 33

51 Nombre: Simular Verificación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará la simulación de la verificación de los dispositivos, en función de los datos recibidos en los informes dosimétricos. Tabla 44: Casos de Uso: Simular Verificación Nombre: Completar Informe Simulación Actores: Radioterapeuta Tipo: Primario Descripción: Una vez simulado todo el proceso de la sesión, el radioterapeuta completará un informe para el oncólogo, con los resultados obtenidos. Tabla 45: Casos de Uso: Completar Informe Simulación Nombre: Firmar Informe Simulación Actores: Oncólogo Tipo: Primario Descripción: El oncólogo deberá firmar el resultado de la simulación, y en caso afirmativo se procederá a la aplicación de dicho tratamiento. Tabla 46: Casos de Uso: Firmar Informe Simulación 34

52 Nombre: Aplicar Colocación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta colocará al paciente mediante los sistemas de posicionamiento, en las posiciones acordadas y aceptadas en el proceso de simulación. Tabla 47: Casos de Uso: Aplicar Colocación Nombre: Aplicar Verificación Actores: Radioterapeuta Tipo: Primario Descripción: El radioterapeuta realizará el tratamiento mediante los sistemas de aplicación del mismo. Tabla 48: Casos de Uso: Aplicar Verificación Nombre: Completar Informe Aplicación Actores: Radioterapeuta Tipo: Primario Descripción: Una vez simulado todo el proceso de la sesión, el radioterapeuta completará un informe para el oncólogo, con los resultados obtenidos. Tabla 49: Casos de Uso: Completar Informe Aplicación 35

53 Nombre: Aceptar Informe Aplicación Actores: Radioterapeuta Tipo: Primario Descripción: El oncólogo deberá recibirá un informe con cada una de las sesiones realizadas al paciente. Tabla 50: Casos de Uso: Aceptar Informe Aplicación Nombre: Visualizar Imágenes Actores: Oncólogo, Dosimetrista, Radioterapeuta Tipo: Subfunción Descripción: Durante todo el procesos, cada uno de estos actores podrá acceder a las imágenes del paciente, para poder realizar las correspondientes fases de la planificación del tratamiento. Tabla 51: Casos de Uso: Visualizar Imágenes 36

54 Modelo de Diseño Ilustración 5: Modelo de Diseño Este Modelo de Diseño, cuyo propósito es el de describir la combinación de la información del Modelo de Dominio y el comportamiento de los Casos de Uso, permite visualizar con mayor facilidad los objetos que el sistema contendrá y las funcionalidades que el sistema va a automatizar. 37

55 4. ESTUDIO DE ARQUITECTURA En esta etapa se pretende, atendiendo tanto a los requisitos del usuario como a las restricciones de diseño, definir la posible solución de arquitectura para todos los ámbitos de desarrollo. Por tanto, la realización de esta etapa consiste básicamente en las siguientes actividades: Especificación de las Alternativas. Evaluación Operativa, Técnica y Estratégica. Evaluación Económica. 38

56 4.1. ESPECIFICACIÓN DE LA ALTERNATIVA 1 Las restricciones dadas por el cliente son claras y delimitan en gran medida las opciones a la hora de tomar una decisión en cuanto a una alternativa especifica. La primera restricción a tener en cuenta es la apuesta del cliente por tecnología de Software Libre y a su vez un desarrollo de los procesos de negocio basados en BPM, logrando de esta forma un mejor entendimiento del negocio a la vez que un desarrollo claro y eficiente enfocado hacia futuras versiones Necesidades de Software La alternativa de software que se presenta será la combinación de distintas herramientas, que ayudarán en el desarrollo a lo largo de todas las etapas del proceso. Estas etapas serán las siguientes: Desarrollo de procesos de negocio BPM y formularios: En esta primera etapa se utilizará Intalio, software Open Source basado en Java-J2EE, que utiliza la Ilustración 6: Intalio notación BPMN para diseñar procesos de negocio. Los componentes que componen esta herramienta son: Una herramienta para el diseño de los procesos de negocio, basada en Eclipse, que a su vez se integra con una herramienta para el desarrollo de formularios, que formarán parte de este proceso, basados en Ilustración 7: Eclipse Orbeon Xforms. 39

57 Un Servidor de Aplicaciones donde residirán los servicios de procesos de negocio que se desplegarán, basado en Apache Geronimo. Ilustración 8: Geronimo Utilización de Web Services en los procesos de negocio: Utilizando los procesos y subprocesos realizados, se utilizará Axis2 para desarrollar los Web Services necesarios para la comunicación entre estos. Base de Datos: Una vez desarrollado todo el modelo de negocio, se incluirá la base de datos necesaria para la creación y monitorización de los registros creados por la aplicación, basada en PostgreSQL. Ilustración 9: PostGreSQL Portal de aplicaciones: Utilizando Eclipse, para su desarrollo, y Apache Tomcat, como servidor de aplicaciones Necesidades de Hardware El equipo hardware que elegido tendrá un soporte para 100 usuarios simultáneos. La aplicación formará parte de un departamento con un máximo de 4 oncólogos y puede atender como máximo unos 20 pacientes diarios, por tanto, será más que suficiente. 40

58 Para desplegar el sistema se ha elegido en este caso el Dell PowerEdge 2970 server con las siguientes características: Ilustración 10: Dell PowerEdge 2970 server Componente Procesador Dual-Core AMD OpteronTM Chipset Broadcom HT-2100 and HT-1000 Server I/O Controllers Instalado 2GB. Ampliable hasta 64GB (8 DIMM slots):2gb/4gb/8gb ECC DDR2 Memoria Sistema Operativo Almacenamiento Red Capacidad Gáfica Ubuntu 9.04 Server Edition 3.5" Nearline SAS (7.2k rpm): 500GB Dual Embedded Broadcom NetXtreme II 5708 Gigabit Ethernet NIC Embedded ATI ES1000 with 16MB memory Tabla 52: Características de Hardware Alternativa 1 41

59 Necesidades de Comunicaciones Dado que este sistema será implantado en una red hospitalaria, se supone que todo el sistema de comunicaciones esta integrado de forma adecuada según haya considerado oportuno el administrador de la red ESPECIFICACIÓN DE LA ALTERNATIVA 2 Siguiendo las restricciones especificadas anteriormente por el cliente, se construye esta alternativa, que cumple de la misma forma que la anterior los puntos principales; apuesta del cliente por la tecnología de Software Libre y desarrollo de los procesos de negocio basados en BPM Necesidades de Software Desarrollo de procesos de negocio BPM y formularios: En esta etapa de desarrollo se utilizará el JBPM de JBoss, suite de desarrollo, que a diferencia de otras herramientas, cumple con el estándar JPDL (JBoss PDL), estándar asociado a WorkFlows. Ilustración 11: JBPM Se debe mencionar que jbpm no utiliza la nomenclatura de desarrollo de BPMN, utilizando una propia. Los componentes que componen esta herramienta son: jbpm-server, un servidor de aplicación jboss preconfigurado. jbpm-designer, el plugin eclipse para crear procesos jbpm en forma gráfica. 42

60 jbpm-db, el paquete de compatibilidad de la base de datos jbpm. En el desarrollo de formularios asociados al proceso de negocio se generan automáticamente en JSF con Facelets, permitiendo trabajar con mayor libertad. El paquete de compatibilidad permite trabajar con cualquier base de datos, casi el 100% de las mas usadas empresarialmente, como, Sybase, Oracle, SQL Server, y no tan empresariales como MySQL. Utilización de Web Services en los procesos de negocio: Al igual que en la primera alternativa, se utilizará Axis2 para desarrollar los Web Services necesarios para la comunicación entre los procesos y subprocesos. Base de Datos: En este caso se utilizará MySQL para el desarrollo de la base de datos necesaria para la creación y monitorización de los registros creados por la Ilustración 12: MySQL aplicación. Portal de aplicaciones: Utilizando Eclipse, para su desarrollo y Apache Tomcat, como servidor de aplicaciones Necesidades de Hardware Para desplegar el sistema se ha elegido en este caso el Dell R805 server con las siguientes caracteristicas: 43

61 Ilustración 13: Dell R805 server Componente Procesador 2x Quad Core AMD Opteron 2344HE, 55W, 1.7GHz, 1Ghz HyperTransport Chipset Broadcom HT-2100 and HT-1000 Server I/O Controllers Memoria 8GB Memory, 4x2GB, 667MHz, Dual Ranked DIMMs Sistema Operativo Almacenamiento Red Ubuntu 9.04 Server Edition 146GB, SAS, 2.5-inch, 10K RPM Hard Drive 4x Broadcom NetXtreme II GbE Capacidad Gáfica Embedded ATI ES1000 with 16MB memory Tabla 53: Características de Hardware Alternativa Necesidades de Comunicaciones Dado que el sistema será implantado en una red hospitalaria, se supone que todo el sistema de comunicaciones esta integrado de forma adecuada según haya considerado oportunos el administrador de la red. 44

62 4.3. EVALUACIÓN OPERATIVA, TÉCNICA Y ESTRATÉGICA Definidas las soluciones, se evaluará el impacto de las alternativas en la organización. Para ello se considerarán diferentes aspectos, que actuarán como parámetros de baremo. Este estudio se centrará en tres aspectos concretos, como son: aspectos operativos, técnicos y estratégicos. El nivel operativo, se centrará en conocer la importancia de puntos como la reducción de gastos de mantenimiento o la fiabilidad de los datos. A nivel técnico se establecerá un baremo que ayudará a conocer las características y facilidades desde el punto de vista tecnológico, de la alternativa elegida. Y finalmente el nivel estratégico ayudará a resolver puntos como el aumento de productividad o la mejora de atención a la demanda. Todos estos factores se plasmarán sobre una matriz, que contendrá los pesos asignados a cada factor y la valoración obtenida a la alternativa elegida. Estos pesos oscilarán del 1 al 3, (3=imprescindible, 2=importante, 1=conveniente), dependiendo de la importancia del factor dentro del negocio. Posteriormente se valorarán cada uno de esos factores (PT) (3=cumple totalmente, 2=cumple en gran parte, 1=cumple un mínimo, 0=no cumple) De la misma forma se obtendrá una valoración (VA) como resultado de multiplicar el peso del factor en concreto, con la puntuación recibida. 45

63 Matriz de Evaluación Operativa Alternativa 1 Factores Operativos (36%) 2 Peso PT VA PT VA Reducción de gastos de mantenimiento Reducción de tareas manuales Fiabilidad de los datos Facilidad de uso y manejo Agilidad de la aplicación Seguridad Puntuación Total Tabla 54: Matriz de Evaluación Operativa Matriz de Evaluación Técnica Alternativa Factores Técnicos (28%) Peso PT VA PT VA Requisitos software Requisitos hardware Independencia con sistemas actuales Facilidad de implantación Integración de diagramas BPM Puntuación Total Tabla 55: Matriz de Evaluación Técnica 46

64 Matriz de Evaluación Estratégica Alternativa 1 Factores Estratégicos (36%) 2 Peso PT VA PT VA Mejorar la imagen de la compañía Mejorar la atención de la demanda Mejorar el control de la gestión Optimización de la gestión Aumentar la productividad Puntuación Total Tabla 56: Matriz de Evaluación Estratégica Alternativa 1 20 Alternativa Operativos Técnicos Estratégicos Ilustración 14: Gráfico de Valoración de Alternativas 4.4. EVALUACIÓN ECONÓMICA Un estudio detallado del factor económico se realiza en base al llamado Análisis de Coste/Beneficio. En él se marcan los costes del proyecto y se contrastan 47

65 con los beneficios que aportará al sistema. Esto sería necesario para cuantificar la recuperación de la inversión (ROI) y de este modo poder conocer si el esfuerzo económico tiene sentido. Sin embargo, desde el punto de vista de valoración de posibles soluciones, se considera suficiente una valoración de costes tangibles, que estarán directamente asociados al desarrollo del proyecto. Estos costes estarán resumidos en costes de implantación, costes de adquisición de tecnología y costes operacionales Costes de Implantación Costes de Implantación Alternativa 1 Alternativa 2 Costes de desarrollo , ,00 Costes de puesta en marcha 2.500, ,00 650,00 470, , ,00 Costes de formación Coste Total Tabla 57: Costes de Implantación Costes de Adquisición de Tecnología Costes de Adquisición de Tecnología Alternativa 1 Alternativa 2 Costes de Hardware 1.816, ,00 Costes de Software 0,00 0,00 Costes de Comunicaciones 0,00 0, , ,00 Coste Total Tabla 58: Costes de Adquisición de Tecnología 48

66 Costes Operacionales Costes Operacionales Alternativa 1 Alternativa 2 Costes de Mantenimiento y Mejora 154,00 267,00 Coste Total 154,00 267,00 Tabla 59: Costes Operacionales Costes Totales Alternativa 1 Alternativa 2 Ilustración 15: Coste Total 4.5. SELECCIÓN DE LA ALTERNATIVA Con los datos recogidos en la especificación de cada alternativa, las matrices de evaluación y las matrices de evaluación de costes, se selecciona la alternativa más conveniente a desarrollar. En este caso, claramente se optará por la alternativa 1, ya que obtuvo una mayor puntuación. 49

67 Pero no sólo se deberá centrar en las puntuaciones obtenidas, sino que además la alternativa no cumple de una forma óptima un requisito importante dado por el cliente, como es la integración de diagramas BPM, ya que JBPM utiliza su propio estándar en cuanto a la notación de diagramas, concepto que a la larga y en desarrollos de futuras versiones podría generar complicaciones. Además, se debe señalar que el coste completo del desarrollo de la Alternativa 1 es ya menor que los costes de implantación de la Alternativa 2, por ello es otro factor a tener en cuenta sobre la elección de la Alternativa 1. 50

68 5. DISEÑO 5.1. ENTORNO OPERATIVO DEL SISTEMA Entrada, salida y recogida de datos En este apartado se especificarán los diferentes tipos de entradas y salidas de datos, a fin de poder diseñar interfaces con otros sistemas que dialogan con éste. Por otro lado, se especificará como van a llevarse a cabo las posibles tomas de datos para la entrada al sistema: quiénes van a realizarlas y qué información se va a introducir. Tal y como se especifica en R F, existirán 3 perfiles principales, encargados de la interacción fundamental con el sistema: oncólogo, dosimetrista y radioterapeuta. Existen a su vez, otros actores como son el administrador del sistema, que no interactúa con el sistema de una forma directa, pero si consume información, controlando los registros generados por cada uno de los procesos del negocio. Finalmente se hará referencia al paciente por un lado, que únicamente formará parte del proceso en la aceptación del tratamiento propuesto, y el 51

69 administrador del HIS, que será en encargado de comenzar el proceso a través de la generación de una cita con el oncólogo. De este pequeño análisis se deduce que el sistema recibe datos de 3 entidades externas que se detallarán a continuación para cada perfil en concreto: Oncólogo Según el modelo de casos de uso (ver 3.2.2), el oncólogo generará informes de evaluación inicial, decisión terapéutica e informe de localización. Estas entradas se definen con detalle en R F, R F y R F, respectivamente. Además completará la firma de los formularios de informe dosimétrico y informe de simulación definidos en detalle en R F y R F, respectivamente. Sus funcionalidades principales serán: Evaluar al paciente y determinar cuál es el tratamiento adecuado. Decidir el área a tratar y la radiación a suministrar a partir de los datos obtenidos tanto de la localización como del plan de irradiación. Elaborar y prescribir el plan de tratamiento para cada paciente, y asegurarse de que éste se administre correctamente. Monitorizar la evolución del paciente y modificar el tratamiento para que los pacientes reciban atención de alta calidad durante el tratamiento. Identificar y tratar los efectos secundarios de la radioterapia. 52

70 Dosimetrista Según el modelo de casos de uso (ver 3.2.2), el dosimetrista generará el informe dosimétrico definido en R F. Las entradas recibidas, en este caso, serán los datos recogidos de el informe de localización y decisión terapéutica definidos en R F y R F, respectivamente. Sus funcionalidades principales serán: Realizar una propuesta terapéutica en base a la enfermedad, el estado del paciente y medios disponibles, para conseguir un tratamiento acorde con el caso. Calcular cuidadosamente la dosis de radiación necesaria para un tumor. Elaborar planes de tratamiento para destruir lo más eficazmente el posible tumor, al mismo tiempo que proteger los tejidos normales. Colaborar con el oncólogo y el radiofísico para elegir el plan de tratamiento indicado para cada paciente. Radioterapeuta Según el modelo de casos de uso (ver 3.2.2), el radioterapeuta será el encargado de proveer al sistema de los subprocesos de simulación y aplicación, completando todos los informes que estos subprocesos requieren. Las entradas recibidas, en este caso, serán los datos recogidos tras la firma del informe dosimétrico definido por R F. Sus funcionalidades principales serán: 53

71 Suministrar los tratamientos diarios a los pacientes previa prescripción y supervisión del oncólogo. Mantener el registro diario y revisar las máquinas periódicamente para cerciorarse de que funcionan bien. Administrador Según el modelo de casos de uso (ver 3.2.2), el administrador del sistema será el responsable de la monitorización del sistema, definido por R F y todos los requisitos que pertenecen a éste. De la misma forma, se especifican en este apartado los sistemas externos que forman parte del proceso: HIS (Hospital Information System) Se trata del sistema que maneja y gestiona toda la información del hospital, como por ejemplo, información general de los pacientes, información de los empleados, control de citas, etc. La comunicación del sistema con el HIS será utilizando el protocolo HL7 utilizando codificación XML y transporte mediante Web Services. Puesto que los HIS suelen ser productos comerciales, se simularán aquellas operaciones que se necesiten mediante Web Services. RT Information System Se trata del sistema asociado al departamento de radioterapia. Dicho sistema almacenará aquella información asociada a un paciente y relativa al campo de la radioterapia. 54

72 PACS Sistema donde se almacenan imágenes de los pacientes. La comunicación con el PACS será mediante el protocolo DICOM a través de un visor de imágenes Generación de informes y formularios La herramienta que se utilizará, según la alternativa elegida, será Intalio. Esta suite de desarrollo, no solo permite el diseño de los diagramas BPM, sino que además se completa con una pequeña herramienta de diseño de formularios que podrán ser posteriormente incluidos en los procesos de negocio desarrollados bajo el diagrama BPM. Esta herramienta de diseño de formularios esta basada en Xforms, nuevo estándar XML que define interfaces de usuario, principalmente formularios Web. Estos formularios Web, están definidos de tal forma que su desarrollo se realiza sin preocuparse de la vista, simplemente se preocuparán de los datos asociados y posteriormente se decidirá si su visualización se realiza mediante formularios Web u otra tecnología (SWT por ejemplo) Control de información y seguridad del sistema El acceso al sistema estará restringido para los diferentes usuarios. En este momento de desarrollo, existe un mecanismo de autenticación/autorización basado en un fichero con los usuarios autorizados, pero en futuros desarrollos existe la prioridad de adaptarlo hacia otra fuente de datos (LDAP, BD, etc.). 55

73 5.2. CONFIGURACIÓN HARDWARE/SOFTWARE Ilustración 16: Configuración Hardware/Software Según se puede observar en la Ilustración 16, los usuarios del sistema podrán conectarse al sistema a través de sus dispositivos habituales de trabajo. El HIS, generando las citas, mediante HL7, el oncólogo, desde su consulta accediendo al sistema, el dosimetrista, desde los equipos habituales del laboratorio y el radioterapeuta, desde el laboratorio de tratamientos y siempre desde un UMPC que le posibilite una mayor movilidad. Para el acceso al sistema simplemente se necesita un navegador Web (IE, Firefox, ). A pesar de su compatibilidad con todos los modelos de navegadores existentes, el sistema ha sido realizado para ejecutarse de manera óptima sobre Mozilla Firefox. 56

74 5.3. DESARROLLO DE LOS PROCESOS DE NEGOCIO Para el desarrollo de los procesos de negocio del sistema, basados en BPMN, se utilizará la herramienta de Intalio, orientada a tal efecto. BPMN está diseñado para cubrir varios tipos de modelado y permite la creación tanto de segmentos de proceso como procesos de negocio de comienzo a fin, y en diferentes niveles de reprensentatividad. Cada uno de los diagramas esta dividido en pools, de los cuales, solo uno de ellos será el pool ejecutable, y el resto, los encargados de representar los distintos actores que forman parte del proceso. Normalmente, los actores físicos implicados, se presentarán en la parte superior del diagrama, y los actores que representan sistemas externos, en la parte inferior, separados por el pool ejecutable. En este caso, el pool ejecutable, tendrá el nombre del proceso que represente. De esta forma, se puede decir que el proceso de negocio, a partir de este momento, proceso de radioterapia, estará dividido en los siguientes subprocesos: Evaluación Inicial Simulación Localización Aplicación Plan de Irradiación 57

75 Proceso de Radioterapia Diagramas Ilustración 17: Proceso de Radioterapia 1/3 58

76 Ilustración 18: Proceso de Radioterapia 2/3 59

77 Ilustración 19: Proceso de Radioterapia 3/3 60

78 Descripción El proceso comienza desde el administrador del HIS, encargado de generar la cita correspondiente al paciente que será tratado para obtener su tratamiento. Esta cita generará unos valores como son: un ID de paciente, una fecha y una hora. Una vez obtenidos estos datos, el sistema los recibirá y consultará mediante un Web Service los datos del paciente a través del ID de paciente recibido. Tanto la petición como la respuesta de este Web Service será en formato HL7, simulando de esta manera la comunicación con un HIS real. Una vez que los datos del paciente viajan en el flujo del proceso, se procederá a una petición mediante Web Services, para autogenerar un ID de tratamiento (necesario para su identificación posterior y almacenamiento en el historial del paciente) y una consulta a su historial clínico. Todos estos datos se mapearán con las variables del proceso, para no perder estos datos a lo largo de su desarrollo y posteriormente se crearán los registros, que se almacenarán en la base de datos, de Inicio de Proceso y Generación de Cita. A partir de este momento se invocará a través de un Web Service al subproceso de Evaluación Inicial, que devolverá una variable que se evaluará una vez completado este subproceso. Esta variable indicará, si el tratamiento ha sido firmado por el paciente, en caso negativo, el tratamiento será cancelado, en caso afirmativo, se procederá a invocar al subproceso de Localización. Una vez realizado este subproceso, se pasará a la realización del Plan de Irradiación que será realizado tantas veces como sea necesario hasta que el oncólogo acepte el plan desarrollado y una vez aceptado se concluirá con la Simulación de este tratamiento, que de la misma forma, no avanzará en el proceso hasta que no sea satisfactorio. 61

79 Una vez que la simulación sea aceptada, se pasará a la fase final de Aplicación del Tratamiento, en la que en este caso se ha supuesto una sola sesión, en caso de ser más de una, se someterá a un subproceso que se repetirá N veces hasta su finalización. Una vez concluido, se generará un informe final con los datos obtenidos en el tratamiento que será entregado al oncólogo y posteriormente y una vez recibido, almacenado en el historial y registrador en su monitor de procesos. 62

80 Evaluación Inicial Diagramas Ilustración 20: Subproceso Evaluación Inicial 1/3 63

81 Ilustración 21: Subproceso Evaluación Inicial 2/3 64

82 Ilustración 22: Subproceso Evaluación Inicial 3/3 65

83 Descripción Una vez lanzado el subproceso, el primer formulario lanzado por la aplicación que deberá de ser completado por el oncólogo, será el de Evaluación Inicial que una vez completado se registrará en la base de datos. Posteriormente se evaluará la petición de nuevas imágenes y una vez realizadas, y nunca antes de que esas imágenes sean recibidas, se comenzará la Decisión Terapéutica, generando su posterior registro. En el caso de que exista una nueva petición de imágenes desde la Decisión Terapéutica, realizándose la misma petición y no continuando con el subproceso hasta su recepción en el sistema. Posteriormente, el sistema generará el formulario con las dos etapas para que el oncólogo realice la comunicación al paciente y éste acepte o decline esta Decisión Terapéutica, evaluando su decisión posteriormente en el proceso de radioterapia. 66

84 Localización Diagramas Ilustración 23: Subproceso Localización 67

85 Descripción En este subproceso se procederá a la localización exacta de la zona a irradiar. Para ello el sistema cargará un formulario con los datos necesarios a completar en esta etapa por el oncólogo. Una vez completado, su registro será almacenado a través de un Web Service en la base de datos. 68

86 Plan de Irradiación Diagramas Ilustración 24: Subproceso Plan de Irradiación 69

87 Descripción Este subproceso será repetido hasta que el oncólogo decida que el Plan Dosimétrico es el adecuado. En primer lugar el dosimetrista recibirá un formulario que deberá completar con los datos necesarios en cuanto a las dosis necesarias en la irradiación. Una vez completado será registrado en la base de datos y comunicado al oncólogo. Este tratamiento especifico será evaluado y en caso de rechazo volverá a generarse en la pantalla del dosimetrista una tarea pendiente de informe de Dosimetría. En caso de aceptación se procederá con la simulación de este tratamiento. 70

88 Simulación Diagramas Ilustración 25: Subproceso Simulación 1/2 71

89 Ilustración 26: Subproceso Simulación 2/2 72

90 Descripción Este subproceso está definido para que el radioterapeuta no tenga que ir avanzando de forma manual en las tareas de muestra de formularios, sino que, a diferencia del resto de subprocesos, éstas se mostrarán de forma automática una vez sean completadas. En primer lugar se generará el formulario de colocación del paciente y una vez verificados todos los parámetros, se registrará en la base de datos y se pasará a la tarea de verificación de parámetros en la dosis, que de la misma forma que la tarea anterior, deberá de ser correctamente completada para finalmente pasar a su informe de resultado, en el que el radioterapeuta informará de una forma concisa todo lo referente a los resultados finales de la simulación. Estos resultados serán enviados al oncólogo que aceptará o declinará este informe y en función de su decisión, se volverá a repetir el subproceso, o pasará definitivamente al subproceso de aplicación. 73

91 Aplicación del Tratamiento Diagramas Ilustración 27: Subproceso Aplicación del Tratamiento 1/3 74

92 Ilustración 28: Subproceso Aplicación del Tratamiento 2/3 75

93 Ilustración 29: Subproceso Aplicación del Tratamiento 3/3 76

94 Descripción Este subproceso está definido para que el radioterapeuta no tenga que ir avanzando de forma manual en las tareas de muestra de formularios, sino que, a diferencia del resto de subprocesos, éstas se mostrarán de forma automática una vez sean completadas. Su ejecución será muy parecida al subproceso de Simulación, con algunas diferencias. En primer lugar, se registrará la acción de Recepción de Cita, y posteriormente, se mostrará un formulario al radioterapeuta con el informe general del tratamiento. Una vez mostrados estos datos se continuará con la tarea de colocación del paciente en el lugar adecuado, para que el tratamiento a recibir sea el correcto. Para ello, el radioterapeuta tendrá que verificar y aceptar todos los parámetros recibidos en el formularios de Colocación y una vez completado se pasará a la verificación de los datos de irradiación. Antes de verificar los datos de irradiación, el sistema comprobará el funcionamiento y estado del PPS, que una vez aceptados todos los parámetros de posicionamiento, se moverá hasta las coordenadas exactas. Mientras se realiza esta operación, a través del sistema de monitorización, se podrá comprobar su estado de actividad, generando a su vez un registro de estado. Una vez concluida esta fase, el proceso mostrará el formulario de Verificación de Parámetros. De una forma similar el proceso de Verificación de Parámetros deberá de ser completado, comprobando su estado y aceptándolos, para poder continuar con el tratamiento. Y de la misma forma que el PPS, el TDD, será registrado y monitorizado, mientras se coloca en su posición, pudiendo ver su estado, antes de pasar al formulario de Informe Resultado. 77

95 En este informe el radioterapeuta, completará un informe, que será enviado al oncólogo, sobre el resultado de la sesión de tratamiento, generando a su vez el registro correspondiente. Finalmente este informe será almacenado en el historial del paciente, para futuras comprobaciones. 78

96 6. MANUAL DE USUARIO A continuación se detallarán todos los pasos necesarios para un buen manejo de la aplicación. Estas especificaciones están basadas bajo la versión actual, pero a medida que se vaya contemplando o modificando el contenido, debe indicarse la versión de la guía y mantener el registro de cambio por versiones. Esta guía se espera que sirva como referencia tanto a usuarios que quieran dar sus primeros pasos en la aplicación, como a los procesos de formación necesarios para su manejo Introducción Dentro de las diferentes técnicas de radioterapia existentes, el sistema se centrará en la radioterapia por haz externo. El proceso objeto de estudio abarca desde que el paciente visita al oncólogo hasta que se le aplica el tratamiento apropiado. Queda fuera del ámbito de dicho proceso tanto la gestión de citas (tanto la cita inicial como las citas intermedias) como el diagnóstico previo realizado al 79

97 paciente (consulta con el médico de cabecera, pruebas radiológicas como TAC o radiografías, etc.) Descripción General de RO Information System Como cualquier aplicación Web, el acceso a la aplicación deberá de realizarse a través de un navegador Web. El sistema ha sido orientado a un perfecto funcionamiento bajo el entorno de Mozilla Firefox, aunque se debe decir, que de la misma forma, ha sido diseñado para su ejecución en cualquier otro navegador Acceso al Sistema El acceso al sistema se puede realizar de diferentes formas, dependiendo del objetivo que se persiga, detalladas a continuación: Versión PC: Adaptada para la ejecución en PC con una resolución de 1280x800 o superior. Será la indicada para el oncólogo y el dosimetrista. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: Ilustración 30: RT: Pantalla de Acceso 80

98 Version Mobile : Adaptada para una ejecución bajo un dispositivo portátil de una resolución no superior a 1024x600. Las pruebas ejecutadas bajo esta versión, han sido realizadas con el UMPC Q1 Ultra de Samsung. Esta versión está orientada al uso del radioterapeuta en el laboratorio de tratamientos. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: Ilustración 31: RT: Pantalla de Acceso "Mobile" Monitor del Sistema: Sistema de monitorización de registro de cada uno de los tratamientos. Únicamente accesible para el administrador. El acceso a la aplicación se realizará introduciendo la siguiente dirección en su navegador: 81

99 Ilustración 32: RT: Pantalla de Acceso Monitor Tanto para la versión PC, como para la versión Mobile, se solicitará un usuario y contraseña para poder acceder de manera segura al sistema. Por el contrario, para la visualización del monitor, únicamente será requerido en número de proceso, necesario para identificar un tratamiento concreto. Una vez dentro del sistema, la pantalla principal, tendrá el aspecto detallado en la Ilustración 33. Ilustración 33: RT: Pantalla Principal 82

100 En esta pantalla principal se puede observar a la izquierda el menú donde, de forma automática, se irán cargando las tareas pendientes en cada caso. De la misma forma, sobre la parte derecha se cargarán los formularios necesarios para llevar a cabo el proceso y finalmente, sobre la parte superior derecha se visualizará un botón de desconexión y un icono representativo de cada uno de los tipos de especialistas que podrán acceder al sistema: Oncólogo ( ). Dosimetrista ( Radioterapeuta( ). ) Funcionalidades del Sistema de Radioterapia Para facilitar el estudio se divide el proceso en una serie de subprocesos que se realizan de forma secuencial. Para cada subproceso se detalla la siguiente información: Definición. Objetivo. Responsable del subproceso completo. Procedimientos a realizar, indicando la persona encargada de cada procedimiento, así como, las pantallas del sistema en ejecución. Dentro de cada uno de los formularios a completar a lo largo del proceso, muchos de los campos serán necesarios para la integridad del tratamiento, por ello, han sido marcados ( ) para informar de su necesidad. No será posible avanzar en el proceso hasta que todos los campos marcados sean completados. 83

101 De la misma forma, un elemento presente en todos los formularios es la opción de Visualizar Imágenes ( ), que facilitará el acceso a la aplicación de visualización de imágenes DICOM, tomadas y asociadas al paciente desde cualquier punto del proceso. Evaluación Inicial Definición Etapa clínica en la que el médico especialista en Oncología Radioterápica, valora el estado del paciente, tipo y extensión de la enfermedad y posibilidades terapéuticas aplicables. A partir de ese informe se realizará el documento de Decisión Terapéutica que seleccionará, entre las modalidades de tratamiento posibles, aquella cuyos objetivos, metodología y desarrollo se adapten mejor a las necesidades y deseos del paciente. Objetivo Obtener los datos que permitan ofrecer la mejor opción terapéutica y decidir la decisión terapéutica óptima para cada situación clínica, necesidades y deseos del paciente con relación a los medios disponibles. Responsable Oncólogo. 84

102 Procedimientos Cuando el oncólogo entra al sistema se le mostrará una lista de las tareas pendientes dentro del menú de la derecha con los siguientes datos: Tarea: Las tareas que aplican en este punto serán del tipo Evaluación inicial. Paciente: El paciente a evaluar. Hora: La hora teórica a la que se debería atender al paciente. Una vez que el paciente llegue a la consulta del oncólogo, éste seleccionará la entrada correspondiente del listado anterior. En este momento, el sistema obtendrá la información detallada del paciente. La información que se le presentará al oncólogo será la siguiente: Datos del paciente. Datos de pruebas complementarias. Con esta información el oncólogo deberá rellenar los siguientes datos: Anamnesis. Exploración Física. Diagnóstico Nosopatológico. Diagnóstico de Extensión de la Enfermedad. Evaluación de factores de riesgo (otros tratamientos y patología asociada). 85

103 Petición de Pruebas complementarias (en caso de ser necesarias). Ilustración 34: RT: Evaluación Inicial 1/2 Ilustración 35: RT: Evaluación Inicial 2/2 86

104 Una vez completada toda la información relativa a la exploración inicial del paciente, su caso será analizado para poder proponer un tratamiento lo más ajustado a sus necesidades. Este análisis, será completado con los datos siguientes: Selección del objetivo del tratamiento (curativo, paliativo, etc.). Elección de la modalidad de tratamiento. Definición del Volumen tumoral y vías de diseminación. Definición de tejidos a irradiar con fines preventivos. Identificación de los tejidos u órganos sensibles o críticos. Ilustración 36: RT: Decisión Terapéutica 1/2 87

105 Ilustración 37: RT: Decisión Terapéutica 2/2 Una vez completada la decisión terapéutica el oncólogo tendrá una tarea pendiente en su listado de tareas que se corresponderá con la presentación del tratamiento al paciente. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 con la salvedad de que la tarea será de tipo Comunicación y Aceptación. Una vez que el paciente llega a la consulta del oncólogo, éste selecciona la entrada correspondiente del listado anterior, y procederá a la presentación del tratamiento previsto al paciente. El paciente en este momento deberá dar su conformidad mediante su firma. El mecanismo de firma podría ser el DNI electrónico, pero por simplificar se asume que el paciente firmará mediante el formulario impreso en papel. 88

106 Ilustración 38: RT: Aceptación del tratamiento por parte del paciente En el caso de que el paciente no acepte el tratamiento, el proceso de radioterapia habrá finalizado. En el caso en que lo acepte, se continuará con el subproceso siguiente. Localización Definición Etapa clínico-técnica en la que el Oncólogo delimita el tejido tumoral y los órganos críticos para la planificación del tratamiento. Objetivo Definir y delimitar los volúmenes de tejido a irradiar y proteger. Responsable Oncólogo. 89

107 Procedimientos Cuando el oncólogo entre al sistema se le presentará la lista de las tareas pendientes que tiene para el día actual. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 aunque en este caso las tareas serán de tipo Localización. Como resultado del subproceso anterior, el oncólogo tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el radiofísico selecciona la tarea en cuestión, visualizará la decisión terapéutica propuesta, así como las imágenes almacenadas en el PACS a través del enlace a la aplicación de visualización de imágenes (imágenes tomadas previamente al proceso de radioterapia). Ilustración 39: RT: Informe de Localización 1/2 90

108 Ilustración 40: RT: Informe de Localización 2/2 A partir del informe dosimétrico y de las imágenes que se podrán visualizar mediante el visor DICOM, el oncólogo deberá completar el formulario de localización, que servirá como referencia tanto para el dosimetrista, como para el radioterapeuta en el plan de irradiación y simulación respectivamente. Plan de Irradiación Definición Etapa clínico-técnica en la que se hace una propuesta terapéutica en cuanto a las dosis necesarias en el tratamiento, en base a la enfermedad, el estado del paciente, los medios disponibles y la experiencia. Objetivo Obtener el plan de tratamiento óptimo para cada situación y paciente. Responsable Dosimetrista 91

109 Procedimientos Cuando el dosimetrista entre al sistema se le presentará la lista de las tareas pendientes que tiene para el día actual. El listado será similar al mostrado en la Ilustración 34: RT: Evaluación Inicial 1/2 aunque en este caso las tareas serán de tipo Preparación informe dosimétrico. Como resultado del subproceso anterior, el dosimetrista tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el dosimetrista selecciona la tarea en cuestión podrá visualizar los datos del paciente, así como la localización definida en el subproceso anterior, y podrá establecer las dosis adecuadas. Ilustración 41: RT: Informe Dosimétrico 1/2 92

110 Ilustración 42: RT: Informe Dosimétrico 2/2 Una vez que el dosimetrista haya finalizado el informe se enviará al oncólogo para su supervisión. Por tanto, en este punto, el oncólogo tendrá una tarea pendiente de Comunicación y Aceptación. Una vez que el oncólogo seleccione la tarea en cuestión visualizará toda la información relativa al paciente, así como el informe de localización y el plan de irradiación, y podrá aceptar o denegar el tratamiento. Ilustración 43: RT: Aceptación del Oncólogo 93

111 En el caso de que el oncólogo acepte el tratamiento el proceso continuará. En caso contrario, habrá que repetir plan de irradiación, teniendo en cuenta las observaciones que haya rellenado el oncólogo. Simulación del Tratamiento Definición Etapa clínica en la que se reproduce de forma fidedigna y documentada, las condiciones del tratamiento prescrito, que se lleva a cabo antes de iniciarlo. Objetivo Verificar que las características del tratamiento previsto se ajustan a las necesidades del paciente en cuanto a su enfermedad, anatomía y posición en la mesa de la unidad. Responsable Radioterapeuta. Procedimientos A través del dispositivo móvil elegido, el radioterapeuta entrará al sistema que le presentará la lista de las tareas pendientes, las cuales serán de tipo Simulación de tratamiento. Como resultado del subproceso anterior, el radioterapeuta tendrá una tarea por cada paciente que haya finalizado dicho subproceso. Una vez que el radioterapeuta selecciona la simulación a realizar, dicha simulación constará de dos etapas: 94

112 Colocación: Ilustración 44: RT: Simulación - Colocación En esta primera etapa de la simulación, el radioterapeuta procederá a la colocación del paciente en la mesa de tratamiento, de acuerdo con la información proporcionada por el informe de localización recibido. Una vez comprobados todos los parámetros, y realizados todos los procedimientos manuales, el sistema de posicionamiento se situará en la posición adecuada y pasará a la segunda etapa. 95

113 Verificación: Ilustración 45: RT: Simulación - Verificación de parámetros Una vez colocado el paciente de la forma acordada en la mesa de tratamiento y la mesa situada en la posición adecuada, el radioterapeuta podrá comenzar a verificar los datos de dosimetría recibidos en el informe dosimétrico. Una vez completada la simulación se presentará un formulario con los datos necesarios para la realización del informe de tratamiento simulado. 96

114 Ilustración 46: RT: Informe de Simulación Una vez que el radioterapeuta haya finalizado el informe se enviará al oncólogo para su supervisión. Por tanto, en este punto, el oncólogo tendrá una tarea pendiente de Aceptación de la simulación. Una vez que el oncólogo seleccione la tarea en cuestión visualizará el informe de simulación y podrá aceptar o denegar la misma. Ilustración 47: RT: Aceptación de la Simulación 97

115 En el caso de que el oncólogo acepte la simulación, el proceso continuará. En caso contrario, comenzará de nuevo, desde la localización, a generar un tratamiento adecuado, ya que se supone que el plan del tratamiento es incorrecto. Aplicación del Tratamiento Definición Etapa clínica en la que se lleva a cabo la irradiación terapéutica, reproduciendo en cada sesión los parámetros de irradiación y posición del paciente, que estarán contenidos en el informe dosimétrico y ficha de tratamiento. Objetivo Reproducir en cada sesión de tratamiento el plan terapéutico previsto y especificado en el informe dosimétrico y ficha de tratamiento. Responsable Radioterapeuta. Procedimientos A través del dispositivo móvil elegido, el radioterapeuta entrará al sistema que le presentará la lista de las tareas pendientes, las cuales serán de tipo Aplicación de tratamiento. Como resultado del subproceso anterior, el radioterapeuta tendrá una tarea por cada paciente que haya finalizado dicho subproceso. En primer lugar, el sistema mostrará un informe con toda la información del tratamiento a realizar. 98

116 Ilustración 48: RT: Inicio de Aplicación Con toda esta información el radioterapeuta podrá comenzar el tratamiento, avanzando a través de los formularios, que se deberán de ir cumplimentando para poder ir avanzando a lo largo del proceso de tratamiento. De esta forma se asegurará que todas las tareas son realizadas. El primer paso será asegurarse de la correcta colocación del paciente para que posteriormente el sistema de posicionamiento se sitúe correctamente. 99

117 Ilustración 49: RT: Aplicación - Colocación Una vez que el radioterapeuta haya completado todos los pasos requeridos, el sistema de posicionamiento (el PPS) se colocará automáticamente en la posición adecuada. El siguiente paso será la verificación de los parámetros relativos a la dosis a aplicar, para posteriormente aplicar dicha dosis. Ilustración 50: RT: Aplicación - Verificación de parámetros 100

118 Una vez que el radioterapeuta haya finalizado el informe se enviará al oncólogo para su supervisión. Una vez que el oncólogo seleccione la tarea en cuestión visualizará el informe de la sesión y podrá añadir las observaciones que estime convenientes, dándose por finalizado el proceso de radioterapia. Una vez que el oncólogo rellene el informe final, el tratamiento se dará por concluido. Además, el informe final será almacenado en el HIS como parte del historial clínico del paciente. Ilustración 51: RT: Informe de Aplicación Funcionalidades del Sistema de Monitorización El acceso a esta funcionalidad, será realizado a través de la pantalla de acceso (Ilustración 32: RT: Pantalla de Acceso Monitor), que solicitará el número de proceso asociado al tratamiento. El administrador del sistema será el único usuario capacitado para acceder a esta opción. Las funcionalidades concretas de la pantalla de monitorización serán: Visualización de todos los registros generados y asociados a cada uno de los pasos del procesos de tratamiento. Estos registros estarán compuestos por nombre de tarea, descripción de la tarea, usuario que la realiza, hora y fecha de finalización. 101

119 Los sistemas de posicionamiento y aplicación de tratamiento serán gráficamente monitoriazados mediante unos gráficos que indicarán el estado de funcionamiento en ese momento. Los sistemas monitorizados serán el PPS y el TDD y sus estados activo e inactivo. Ilustración 52: RT: Monitor del Sistema Funcionalidades del Visualizador DICOM El visualizador utilizado esta basado en la aplicación Radscaper, un potente applet en Java, orientado a la visualización de imágenes DICOM a través de la Web. Permitirá a cualquier usuario del sistema en cualquier momento del desarrollo del tratamiento poder acceder a las imágenes del paciente, pudiendo realizar las siguientes opciones: 102

120 Consultar información y datos del paciente incrustados en la imagen DICOM asociada. Contrastar diferentes imágenes, tomadas en diferentes periodos de tiempo, para observar su evolución. Medir distintos puntos de las imágenes para poder comparar su desarrollo. Ilustración 53: Radscaper 1 103

121 Ilustración 54: Radscaper 2 104

122 7. Planificación Temporal Se muestra el desarrollo que ha tenido el proyecto y la duración de cada una de las etapas a lo largo del año. 105

123 106

124 8. Conclusiones Una vez finalizado por completo el desarrollo del sistema, es un hecho el acierto de la elección de Intalio para el desarrollo e integración de los diagramas BPM y los formularios necesarios para la implementación del proceso. Este software de distribución libre, ha ayudado a poder integrar de una forma precisa todos los procesos necesarios, permitiendo a su vez, una fácil gestión de posibles modificaciones en futuros desarrollos. Se ha conseguido así, el objetivo de poder integrar los diferentes sistemas que rodean a esta aplicación, utilizando ésta, como una herramienta capaz de comunicar todos los elementos que componen un laboratorio oncológico, independientemente de su marca o modelo. El objetivo principal del estudio ha sido centrado en el análisis de los distintos procesos necesarios en la gestión del hospital, focalizándolo en las tareas necesarias para la realización de un diagnóstico y posterior tratamiento oncológico, y a raíz de todo el estudio realizado, se ha llegado a la conclusión de el enorme potencial que este campo puede llegar a tener en futuras aplicaciones, dada la escasa aportación al mercado, de aplicaciones de este estilo. 107

125 Por último, se considerá el resultado de este proyecto como una aproximación muy certera a las necesidades demandadas por el cliente y, a su vez, con una gran capacidad de proyección para desarrollos futuros en temas sanitarios. 108

126 9. Bibliografía [LARM02] Larman, C. (2002). UML Y PATRONES. Una introducción al análisis y diseño orientado a objetos y al proceso unificado. Madrid. Pearson Educación. [DEVE08] Deveboise, T. (2008). The Microguide to Process Modeling in BPMN. Lexinton (Virginia). Tipping Point Solutions [AREB01] Barranco de Areba, J. (2001). Metodología al análisis de estructurado de sistemas. Madrid. Universidad Pontificia Comillas de Madrid. [APAC04] The Apache Software Foundation. (2004). Apache Ant Manual. Disponible en la Web: [SKON01] Skonnard, A. (2001). Essential XML Quick Reference: A Programmer's Reference to XML, XPath, XSLT, SOAP, and More. Addison-Wesley Professional. [WEER05] Weerawarana, S. (2005). Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-Addressing, WS-BPEL, WS-Reliable Messaging, and More.Prentice Hall. 109

127 [INTA06] Intalio, PXE Confluence Wiki DashBoard, Disponible en la Web: [INTA08] Intalio, Help section. Disponible en la Web: [WHIT05] White, S. (2005). Using BPMN to Model a BPEL Process. BPTrends. [IHE05] IHE. (2005). IHE Radiology User s Handbook. Integrating the Healthcare Enterprise. 110

128 Apéndice A. Introducción a BPMN QUÉ ES BPM? BPM (Business Process Management), o BPMS (BPM Suite) es el conjunto de servicios y herramientas que facilitan la administración de procesos de negocio. Por administración de procesos se entiende: análisis, definición, ejecución, monitorización, y control de los procesos. BPM además contempla soporte para interacción humana, e integración de aplicaciones, y es aquí la diferencia fundamental con la tecnología de WorkFlow existente, que es que BPM integra en los flujos a los sistemas. En resumen, se puede decir que BPMN proporciona un lenguaje común para que las partes involucradas puedan comunicar los procesos de forma clara, completa y eficiente. De esta forma BPMN define la notación y semántica de un Diagrama de Procesos de Negocio (Business Process Diagram, BPD). 111

129 BPD es un diagrama diseñado para representar gráficamente la secuencia de todas las actividades que ocurren durante un proceso, basado en la técnica de Flow Chart, considerando además toda la información necesaria para el análisis. Las soluciones del tipo WorkFlow sólo se limitaban a definir el flujo de actividades humanas o de documentos, y con esto obtener el seguimiento de los procesos, pero en estos casos si un participante del proceso requería como parte de sus actividades ingresar datos en una aplicación, entonces debía salir del ambiente del WorkFlow, levantar la aplicación, y luego de terminada su operación volver al WorkFlow y registrar el cambio de estado, o termino de la actividad. En BPM todo está integrado en el mismo flujo, lo que es más natural para un participante. De esta forma, el participante completa su actividad dentro del flujo BPM y, tras el proceso en curso, se actualizan los sistemas oportunos. Ilustración 55: Diagrama sencillo BPM 112

130 En la práctica un flujo BPMN visualmente es muy parecido a un WorkFlow, la diferencia está en que uno puede notar que ciertas actividades son realizadas por personas, y otras son actividades sistematizadas (realizadas por sistemas), y ambas aparecen en el flujo. POR QUÉ UTILIZAR BPMN? BPMN es un estándar internacional de modelado de procesos aceptado por la comunidad. BPMN es independiente de cualquier metodología de modelado de procesos. BPMN crea un puente estandarizado para disminuir la brecha entre los procesos de negocio y la implementación de estos. BPMN permite modelar los procesos de una manera unificada y estandarizada permitiendo un entendimiento a todas las personas de una organización. En BPM el modelo del proceso se convierte en el núcleo de la implementación del proceso como solución tecnológica. El modelo del proceso de negocio (su diseño) que realiza el área de negocios de una empresa es en sí lo que se ejecuta sobre el servidor de procesos (el motor de BPM). Dicho en otras palabras: la lógica de negocio principal que antes bajo las tecnología tradicional se debía programar, y colocar sobre un servidor de aplicaciones (tradicional), ahora se reemplaza por un modelo que se sube al servidor de procesos con mucho menos intervención del área de TI (menos programación). 113

131 En la práctica una buena solución BPM debería poder ejecutar un proceso modelado por el área de negocio, sin la necesidad de que TI tenga que programar una sola línea de código, y obtener como solución algo equivalente a un WorkFlow Tradicional (sin integración de sistemas). Luego el área de TI debería tomar este workflow, e implementar los formularios de entrada (de interacción con usuarios), y los servicios (las actividades automatizadas) para completarlo en un flujo BPM. BUSINESS PROCESS MODELING NOTATION Explicación de forma gráfica de la notación utilizada dentro de este lenguaje de procesos. Eventos A) Introducción Los Eventos son sucesos que afectan a la ejecución del proceso de negocio. Todo modelo debe incluir tres tipos fundamentales: Start: Lanzará la instancia de comienzo del modelo de negocio. Intermediate: Indica cuándo un evento debe suceder durante la ejecución del modelo de Ilustración 56: Eventos I negocio. End: Indica cómo y cuándo un flujo del proceso acaba. 114

132 B) Tipos Un evento cualquiera puede ser claramente definido utilizando su símbolo adecuado. La semántica de algunos eventos puede ser interpretada en varios sentidos. Por ejemplo, un evento intermedio tipo Mensaje puede indicar que el sistema envía o recibe datos. Por ello, y con el objetivo de esclarecer este comportamiento, se han definido dos grupos principales de símbolos, que ayudarán a mostrar de una manera gráfica adecuada su significado en el modelo de procesos: Catching: Referencia a una semántica de recepción de flujos de información a través del modelo. Throwing: Referencia a una semántica de envío de flujos de información a través del modelo. Ilustración 57: Eventos II 115

133 Actividades Una actividad es una unidad de trabajo dentro del modelo que debe llevarse a cabo. Puede ser una tarea o un subproceso. Se representará mediante un rectángulo con esquinas redondeadas. Determinadas marcas ayudarán a especificar sus atributos. Las especificaciones de BPMN dan las siguientes definiciones: Una Tarea es una actividad atómica que se utiliza cuando el trabajo en el proceso no es descompuesto en más detalle. Es ejecutada por una persona y/o una aplicación. Ilustración 58: Actividades I Un Subproceso es una actividad compuesta que es incluida dentro de un proceso. Es compuesto dado que esta figura incluye a su vez un conjunto de actividades y una secuencia Ilustración 59: Actividades II lógica (proceso) que indica que dicha actividad puede ser analizada en más detalle. Visualmente podrá mostrarse colapsado o expandido. GateWays Son elementos del modelado que se utilizan para controlar la divergencia y la convergencia del flujo. Tipos Exclusive Data-Based Gateway XOR Actúa como un punto de decisión donde varios flujos de salida son posibles y a su vez todos ellos están bajo una serie de condiciones, que sólo uno de los flujos de salida Ilustración 60: GateWays I 116

134 será capaz de cumplir. Esa condición será evaluada basándose en el proceso de datos. A su vez, esta compuerta puede ser utilizada también para la unión de varios flujos en uno. Exclusive Event-Based Gateway XOR Es similar al Exclusive Data-Based Gateway, la única diferencia es que, en vez de evaluar un conjunto de Ilustración 61: GateWays II alternativas para determinar cual de ellas será el flujo de salida, esta compuerta comenzará una carrera entre los distintos eventos que el proceso debe recibir y el primero en ser recibido, determinara que flujo de salida será el utilizado. Inclusive Gateway XOR Se utilizará como un punto de decisión donde varios flujos de procesos son posibles, que serán elegidos en función de una serie de condiciones, que en caso de ser cierta, pasarán a ejecutarse. Ilustración 62: GateWays III Usándolo como punto de unión de varios flujos, sincronizará todas las ejecuciones de éstos, comenzando el flujo de datos siguiente, una vez finalizados todos los flujos de entrada. Parallel Gateway AND Proporciona una solución para la bifurcación y sincronización de flujos. Ilustración 63: GateWays IV 117

135 Swimlanes Muchas técnicas de modelados utilizan el concepto de swimlanes como mecanismo de organización de actividades en categorías visuales separadas para ilustrar las diferentes capacidades funcionales o responsabilidades. Tipos Pools Un Pool representa un Participante en un Proceso, actuando como contenedor gráfico para separar al grupo de actividades realizadas por un participante de otros Pools. Se utilizan generalmente en el contexto de situaciones B2B (Business To Business) y cuando los diagramas involucran a dos entidades de negocios o participantes separados. Están físicamente separados en el diagrama. Las actividades dentro de Pools separados son consideradas auto contenidas en el proceso. De esta forma, la secuencia del flujo podría no atravesar el límite del Pool. Los flujos de mensajes son los mecanismos que muestran la comunicación entre dos participantes, conectando de esta manera a dos Pools. Lane Un Lane es una partición dentro de un pool y se extiende a lo largo de todo el pool, tanto vertical como horizontalmente. Ilustración 64: Pools 118

136 Son usados para organizar y categorizar actividades y son más cercanos a los swimlanes que tradicionalmente se utilizan para modelar procesos de negocio. Separan actividades asociadas con una función específica de la organización. La secuencia de flujos podría atravesar los límites del Lane dentro de un Pool, pero podrían no usarse flujos de mensajes entre Flow Objects en Lanes del mismo Pool. Conectors BPMN define una serie de flechas para conectar las distintas tareas, eventos y demás elementos. Son utilizados para: Describir el orden en el que los diferentes pasos del proceso deben de ser ejecutados. Añadir información adicional, como por ejemplo comentarios. Describir como los mensajes deben de ser intercambiados entre los diferentes swimlanes. Ilustración 65: Conectors I Tipos Flujos de Secuencia Se utilizan para conectar elementos del flujo de procesos como tareas, eventos o compuertas para poder así especificar de una manera clara su orden de ejecución. Dentro de ese tipo de flujos se encuentran tres subcategorías: 119

137 Standard Sequence Flow: Indica que una vez que el paso actual sea finalizado, se podrá pasar al siguiente paso Ilustración 66: Conectors II indicado por su sentido. Conditional Sequence Flow: Indica que una vez que el paso actual sea finalizado, y sólo si la condición asociada a Ilustración 67: Conectors III este flujo es verdadera, se podrá pasar al siguiente paso indicado por su sentido Default Sequence Flow: Cuando un determinado paso tiene varias Conditional Sequence Flows de salida y tras Ilustración 68: Conectors VI su evaluación serán consideradas como falsas, se utilizará este flujo para la continuación del proceso. Flujos de Mensajes Se utilizan para la representación de los diferentes flujos de mensajes que son posibles de intercambiar entre Ilustración 69: Conectors V procesos. Asociaciones Utilizados para asociar información y artefactos con los distintos objetos del flujo. Ilustración 70: Conectors VI 120

138 Anotaciones de Texto Información adicional debe de ser añadida con el objetivo de documentación a través de las Anotaciones de Ilustración 71: Conectors VII Texto. Reglas de Conexión Ilustración 72: Flujos de Secuencia Ilustración 73: Flujos de Mensajes Esta dos tablas serán de gran utilidad para conocer las posibles conexiones entre los diferentes elementos de un posible diagrama BPM. 121

139 Apéndice B. Servicios Web A) DESCRIPCIÓN DE LOS SERVICIOS WEB Introducción Los servicios Web (WS) son aplicaciones que pueden ser descritas, publicadas, localizadas e invocadas a través de una red, generalmente Internet. Dicho de una manera más formal, los servicios Web son componentes de software alojados en servidores Web públicos o privados por Internet a los que se accede mediante mensajes del protocolo SOAP (también se podrían usar los mensajes XML-RPC, aunque es SOAP el protocolo más usado actualmente) codificados en formato XML a través de protocolos estándares de aplicación (HTTP, SMTP, FTP, etc.) y que proporcionan un servicio a los correspondientes clientes de software. Para hacerse una idea rápida de cómo funciona un servicio Web se puede decir que es una llamada a un procedimiento remoto (RPC) basada en HTTP/SOAP. Los servicios Web se basan en una colección de protocolos y estándares abiertos que sirven para intercambiar datos entre aplicaciones. Las organizaciones 122

140 OASIS y W3C son los responsables de la arquitectura y reglamentación de los servicios Web. Para mejorar la interoperabilidad entre distintas implementaciones de servicios Web se ha creado el organismo WS-I encargado de definir de manera más exhaustiva estos estándares. Algunas de las ventajas de los servicios Web son: Al estar basado en estándares aportan interoperabilidad entre aplicaciones de software independientemente de la plataforma, sistema operativo y lenguaje de programación. Los servicios Web fomentan los estándares y protocolos basados en texto, que hacen más fácil acceder a su contenido y entender su funcionamiento. Al apoyarse en HTTP (en el caso de que usen este protocolo como transporte), los servicios Web pueden aprovecharse de los sistemas de seguridad (firewalls) sin necesidad de cambiar las reglas de filtrado. También existen algunos inconvenientes como son: Su rendimiento es bajo si se compara con otros modelos de computación distribuida, tales como RMI, CORBA o DCOM. Es uno de los inconvenientes derivados de adoptar un formato basado en texto ya que entre los objetivos de XML no se encuentra la concisión ni la eficacia de procesamiento. Para realizar transacciones (conjunto de operaciones que se deben ejecutar como una unidad, es decir, o se hacen todas o ninguna) no puede compararse con plataformas como CORBA. La arquitectura de comunicaciones de los servicios Web (organizada por niveles y protocolos implicados) se puede ver en la siguiente figura. 123

141 Ilustración 74: Arquitectura de comunicaciones de los servicios Web En el nivel de transporte de la arquitectura están los protocolos de Internet existentes que permiten activar servicios Web. Estos protocolos se encargan de transportar los mensajes entre las aplicaciones. Los servicios Web pueden utilizar muchos protocolos de transporte, si bien es el protocolo HTTP el más usado. En el nivel de mensajería están los protocolos que indican cómo se comunican clientes y servidores y la sintaxis de los mensajes intercambiados, de modo que ambos extremos de la comunicación puedan comprenderlos. Por tanto, este nivel es el responsable de la creación, codificacióndecodificación en un formato XML y envío de los correspondientes datos. En este nivel, existen dos posibles protocolos, SOAP y XML-RPC, aunque actualmente es el protocolo SOAP el más utilizado ya que los principales entornos para desarrollar servicios Web (Axis, Apache SOAP,.NET, etc.) utilizan este protocolo. El nivel de descripción del servicio es un nivel intermedio para que los servicios Web pasen del nivel de mensajería al nivel más alto de descubrimiento y publicación. En este nivel, el lenguaje WSDL de definición de servicios Web proporciona una serie de mecanismos para que un 124

142 proveedor de servicios publique un documento WSDL con detalles sobre un servicio en particular y cómo acceder a él. El nivel de descubrimiento y publicación del servicio se utiliza para encontrar y publicar los servicios Web que proporcionan una funcionalidad determinada. El protocolo universal de descripción, descubrimiento e integración (UDDI) es una especificación de un servicio de directorio o servicio Web al que puede acceder la máquina que proporciona estos servicios. De hecho, los registros UDDI son servicios Web y se acceden a ellos a través de SOAP vía HTTP. A continuación se describen los protocolos más importantes de cada nivel: XML-RPC: XML-Remote Procedure Call XML-RPC es un protocolo para ejecutar llamadas a procedimientos remotos (RPC) que funciona sobre Internet. XML-RPC funciona mediante el intercambio de mensajes entre el cliente del servicio y el servidor, usando el protocolo HTTP para el transporte de dichos mensajes. Concretamente, XML-RPC utiliza peticiones POST de HTTP para enviar los mensajes, en formato XML, indicando: El procedimiento que se va a ejecutar en el servidor. Los parámetros que se necesitan para ejecutar dicho procedimiento. XML-RPC maneja un conjunto de tipos para el paso de parámetros, valores de retorno y errores. Estos tipos se representan mediante etiquetas XML. Existen tipos básicos y tipos compuestos: 125

143 Tipos básicos: <int> o <i4>: Enteros de 32 bits. <double>: Coma flotante de 64 bits. <boolean>: Verdadero o falso. <string>: Texto ASCII (y UNICODE). <datetime.iso8601> Fecha en formato ISO8601. <base64>: Binario codificado en base 64. Tipos compuestos: <array>: Información secuencial. <struct>: Contenido desordenado, identificable por nombre de campo. Una petición XML-RPC está formada por: Contenido XML: Contendrá el procedimiento al que se llama y los parámetros pasados en la llamada. Cabecera HTTP: Recubrimiento (wrapper) para enviar la petición por la Web. Será una cabecera de una petición HTTP POST. Una repuesta XML-RPC está formada por: Contenido XML: En caso de que la petición se haya ejecutado sin problemas contendrá un sólo parámetro, aunque este parámetro puede ser de tipo compuesto. En el caso de que haya habido problemas al ejecutar la llamada 126

144 (no se encuentra el procedimiento, no se ejecuta correctamente o no se puede devolver el resultado), en este contenido se indicará que ha habido el error y una descripción del error. Cabecera HTTP: Recubrimiento para enviar la respuesta por la Web. Será una cabecera de una respuesta HTTP. Por último, hay que indicar que al estar basado en XML, XML-RPC es independiente de plataforma y de lenguaje de programación. SOAP: Simple Object Access Protocol Al igual que XML-RPC, SOAP es un protocolo de intercambio de información que usa documentos XML. SOAP es más complejo que XML-RPC aunque también más potente. Alguna de las características de SOAP son: Es independiente de plataforma y de lenguaje de programación ya que los mensajes SOAP están escritos en XML. Permite intercambiar documentos XML y otros tipos de documentos en las peticiones y respuestas. Los mensajes SOAP utilizan espacios de nombrados (namespaces) y esquemas XML (XML Schemas). Funciona sobre HTTP, FTP, SMTP, y algunos protocolos más, aunque es HTTP el protocolo más utilizado. No mantiene el estado. 127

145 Los mensajes SOAP tienen el aspecto mostrado en la siguiente figura: Ilustración 75: Estructura Mensaje SOAP A continuación se detalla cada uno de estos elementos: Envelope (obligatorio): Cada mensaje SOAP tiene un único <Envelope>. En este elemento se definen los espacios de nombres XML a utilizar. Mediante los espacios de nombres incluidos, SOAP puede diferenciar mensajes. Actualmente hay dos versiones: SOAP 1.1 y SOAP 1.2. Header (opcional): Contiene información de cómo se procesa el mensaje, como por ejemplo: encaminamiento, autenticación e identificación de transacción. Body (obligatorio): Contiene el mensaje a enviar o procesar. Normalmente este elemento se utiliza para incluir peticiones y respuestas RPC aunque también se puede utilizar para incluir documentos XML. Fault (opcional): Se utiliza para indicar errores del nivel de protocolo. En caso de que ocurra algún error se devuelve información como: el tipo de error, un mensaje de error explicativo, la URI del nodo que envía el error, mensajes de error explicativos de la aplicación, etc. 128