Parte I Introducción. Capítulo 1 Justificación Capítulo 2 Metodología

Transcripción

1 Parte I Introducción Capítulo 1 Justificación Capítulo 2 Metodología 1

2 2

3 Capítulo 1 - Justificación Resumen El propósito de este proyecto es el de implementar una infraestructura robusta para la gestión de historiales médicos e imágenes procedentes de aparatos de diagnóstico. La base de esta infraestructura será un servidor en el que se desplegarán los dos nodos principales de la instalación: una aplicación web para la gestión de datos de pacientes, accesible desde cualquier terminal con un navegador, y un gestor de documentos capaz de sincronizarse con dispositivos móviles. Esta capacidad de sincronización entre el gestor documental y los dispositivos móviles es clave para la instalación, ya que dará también la posibilidad de trabajar offline: será posible capturar imágenes de aparatos de diagnóstico, asociarles las observaciones oportunas, y sincronizar el dispositivo con el gestor en cuanto haya una conexión disponible. De este modo, datos relativos a un historial clínico obtenidos desde fuentes heterogéneas, están integrados en un único punto, accesible a través de la aplicación de gestión. The purpose of this project is to deploy a strong infrastructure to manage medical records and images from diagnostic devices. The basis of this infrastructure will be a server in wich will be deployed the two main nodes of the system: a web application for managing patient data, accessible from any computer with a browser and a document 3

4 manager capable of synchronizing with devices phones. This ability of synchronization between document management and mobile devices is key for installation, and will also provide the ability to work offline: will be possible to capture images of diagnostic devices, associate them the appropriate observations, and synchronize the device with the manager when a connection is available. Thus, data related to a clinical history obtained from heterogeneous sources, are integrated into a single point, accessible via the management application Contexto El campo de la medicina combina en su práctica tanto la ciencia como el arte al no disponer de fórmulas exactas para su aplicación, más allá de los esquemas de diagnóstico y el conocimiento propio de cada médico. A partir de la anamnesis, el facultativo sigue como guía los protocolos de diagnóstico conocidos hasta determinar la patología que afecta al paciente. Este procedimiento es de naturaleza cíclica: el plan de acción de cada iteración se establece a partir de la observación y análisis de los resultados obtenidos en la iteración anterior. Todo el proceso queda registrado en el historial clínico del paciente, documento de valor legal y en el que consta toda la información referente al proceder del médico. Dada la importancia de este histórico, y a la más que probable necesidad de acceder al mismo por distintos especialistas médicos, es imprescindible mantener la integridad de esta información y garantizar su disponibilidad en diversos lugares. Este es el objetivo principal del presente proyecto. Para cumplir dicho objetivo en el mayor grado posible, este proyecto extiende su alcance en distintos ámbitos complementarios entre sí, que necesitan soluciones de naturaleza heterogénea. El desarrollo de dichas soluciones se basará en la infraestructura de integración de las aplicaciones heredadas 1, esto es, el legacy, que servirá de conductor para determinar los requisitos que debe cumplir el proyecto. Por tanto, el contexto del 1 Esta infraestructura es presentada en el proyecto [Citar proyecto de Javi], desarrollado por el alumno Javier Val Lista. En él se discute la integración de diversas aplicaciones heterogéneas en un entorno distribuido mediante el uso de soluciones comerciales. 4

5 mismo se afrontará desde tres enfoques: el de los procedimientos clínicos, centrados en la gestión del historial médico de los pacientes, el de los procedimientos de movilidad, cuyo objetivo es la integración de imágenes procedentes de aparatos de diagnóstico, y el de la evolución de los protocolos de diagnóstico, que aborda el modo de dar soporte a los procedimientos seguidos por el facultativo para establecer un diagnóstico Enfoque de procedimientos clínicos Los procedimientos clínicos dan soporte a la gestión de los datos y los historiales médicos de los pacientes. Esta información debe estar disponible y ser única, es decir, no puede estar duplicada en distintos nodos del sistema. Por ello, cualquier solución propuesta en este ámbito debe soportar la integración de la información procedente de fuentes heterogéneas, así como permitir el acceso a dicha información. Los datos gestionados en este ámbito incluyen las patologías diagnosticadas, las exploraciones realizadas y los tratamientos recetados. Dado que la información clínica estará integrada en un único punto para evitar duplicidad e inconsistencia, también se dará soporte aquí a los procedimientos de facturación, ya que dependen directamente de las pruebas realizadas al paciente Enfoque de procedimientos de movilidad Debido a su coste económico, es probable que los recursos de diagnóstico a los que tiene acceso un facultativo estén distantes entre sí, posiblemente en distintos puntos geográficos. Esto presenta la problemática de mantener asociadas a los historiales las imágenes obtenidas de las exploraciones realizadas y conduce a la disgregación de los datos clínicos de los pacientes. Por ello, es necesario un modo de capturar los resultados que ofrece un aparato de diagnóstico e integrarlos en el historial clínico, que como se ha indicado en el punto anterior, será único y estará centralizado. Además, esta solución debe permitir trabajar 5

6 offline, puesto que no se puede garantizar la disponibilidad de conexión Enfoque de procedimientos de evolución de protocolos diagnósticos Para aumentar la agilidad y precisión de los diagnósticos emitidos por el facultativo, es imperativo disponer de procedimientos de apoyo a las decisiones. Estos procedimientos deben basarse en información histórica y estadística contra la que se puedan evaluar los datos obtenidos siguiendo los protocolos de diagnóstico. A partir del resultado de esta correlación, se le ofrecerán al médico diversas opciones para continuar con la secuencia de diagnóstico. El facultativo tendrá siempre la opción de obviar dicha secuencia, ya que el sistema pretende dar apoyo y agilizar las labores de diagnóstico, nunca sustituir el conocimiento heurístico. Los opciones disponibles se organizarán por aparatos (respiratorio, circulatorio, digestivo, motor etc.), permitiendo acotar las referencias sobre las que se valorarán las conclusiones. Esto servirá también para establecer un balance riesgo/beneficio para cada prueba en un paciente concreto, algo fundamental en el caso de exploraciones intrusivas Alcance Con objeto de demostrar la viabilidad del proyecto, se desarrollarán varios prototipos en distinto grado de profundidad y funcionalidad según la relevancia y complejidad de los casos de uso a los que cada prototipo dé cobertura. Al igual que el contexto, el alcance del proyecto se tratará en tres puntos Enfoque de procedimientos clínicos En este ámbito se afrontará el desarrollo de una aplicación web para la gestión de 6

7 historiales. Esta aplicación dará soporte al registro de exploraciones y diagnósticos, además de permitir la generación de recetas e informes. Constará también de un módulo de facturación y otro de gestión de citas. Al estar desplegada en un entorno web, esta aplicación puede ser accedida desde cualquier terminal con conexión a la red, permitiendo así almacenar la información clínica de los pacientes en un único punto y dando solución, por tanto, a la principal problemática presente en este ámbito Enfoque de procedimientos de movilidad Como solución a los problemas asociados a la dispersión geográfica de los recursos médicos se optará por el empleo de terminales móviles que permitan capturar los resultados de las pruebas médicas y sincronizarlos posteriormente con el repositorio central de historiales. Esta funcionalidad será implementada mediante el uso de Evernote, una solución comercial que dispone de versiones tanto para terminales móviles como para escritorio, y que permite el sincronismo entre ambas. Una vez demostrada la funcionalidad de la propuesta, quedaría planteado como desarrollo futuro la codificación de una aplicación específica e integrada con el resto del despliegue Enfoque de procedimientos de evolución de protocolos diagnósticos El sistema de apoyo a los protocolos diagnósticos será esbozado mediante el uso de un prototipo desarrollado a partir de formularios web. Los protocolos de diagnóstico son, a grandes rasgos, diagramas de flujo basados en estructuras alternativas en los que se indican las condiciones de entrada en cada fase del procedimiento. 7

8 La aplicación mapeará estos diagramas a un flujo de formularios, cuya navegación vendrá definida por los valores que los facultativos introduzcan en el formulario de cada fase del protocolo. El sistema también permitirá la agregación de nuevos protocolos de diagnóstico por parte de los usuarios, de forma que la biblioteca de procedimientos soportados podrá ser adaptada a la especialidad de cada facultativo. 8

9 Capítulo 2 - Metodología Este proyecto se afrontará con un enfoque basado en un desarrollo ágil y ligero, con el objetivo de obtener un despliegue funcional en el mínimo tiempo posible que permita obtener feedback en fases tempranas del desarrollo. Para las tareas de modelado del dominio se emplearán diagramas UML, concretamente, diagramas de clases, secuencia, casos de uso, actividad y despliegue. En cuanto a la estructuración de la aplicación de gestión de historiales, está se articulará siguiendo la arquitectura hexagonal 2 propuesta por Alistair Cockburn. El desarrollo de las funcionalidades de movilidad no requerirá un proceso de diseño como el seguido para la aplicación de gestión, ya que en su mayor parte supone una tarea de configuración e integración de soluciones ya implementadas. Por este motivo, no se hará referencia a este ámbito del proyecto en este capítulo Método El desarrollo del proyecto seguirá un ciclo de vida incremental, llevando a cabo procesos periódicos de refactorización de código para adaptarse a los cambios y mejoras surgidas de los resultados obtenidos en iteraciones anteriores. En general, se seguirá una filosofía de diseño guiada por el dominio (Domain Driven Design) tal y como propone Eric Evans [referencia]

10 La filosofía de diseño guiado por el dominio trata de poner la atención en el corazón de la aplicación, centrándose en la complejidad inherente al dominio de negocio en sí mismo. También distingue el dominio principal (único para el negocio) de los subdominios de apoyo (por lo general de carácter genérico, como el dinero o el tiempo), y establece la mayor parte del esfuerzo de diseño en el núcleo de dicho dominio. A partir de este planteamiento y con objeto de establecer un punto de inicio para la primera iteración, se realizará un estudio de las funcionalidades necesarias en el sistema, expresándolas en términos de casos de uso. A continuación, tomando dichas funcionalidades como guía, se obtendrá un primer esbozo del modelo del dominio mediante el uso de clases coloreadas. Este primer modelo servirá de base para comenzar la implementación de una primera versión del sistema que, aunque incompleta, permitirá refinar el modelo y corregir errores de concepto no detectados en la primera aproximación de diseño. El proceso continuará durante varias iteraciones cortas hasta obtener un modelo del dominio preciso y ajustado a las necesidades del sistema Herramientas de modelado UML (Lenguaje Unificado de Modelado) es una especificación de notación orientada a objetos, aunque dada su flexibilidad, puede ser utilizada con otros paradigmas de programación. Se basa en las especificaciones de Booch, Rumbaugh y Jacobson [1]. Es un lenguaje de modelado visual que se usa para especificar, visualizar, construir y documentar un sistema de software. Divide cada proyecto en un número de diagramas que representan las diferentes vistas del proyecto. Estos diagramas juntos son los que representa la arquitectura del proyecto. UML capta la información sobre la estructura estática y el comportamiento dinámico de un sistema. El lenguaje de modelado pretende unificar la experiencia pasada sobre técnicas de modelado e incorporar las mejores prácticas actuales en un acercamiento estándar. No 10

11 obstante, no es ni está ligado a ningún lenguaje de programación Diagramas de casos de uso Los casos de uso documentan el comportamiento del sistema desde el punto de vista del usuario. En este caso, por usuario se entiende cualquier cosa que se desarrolla, ajena al sistema, que interactúa con el mismo. Un usuario podría ser una persona, otro sistema de información, un dispositivo hardware, etc. El modelado de los casos de uso ayuda con tres de los aspectos más difíciles del desarrollo: La captura de requisitos. La planificación de las iteraciones del desarrollo. La validación de los sistemas. Un diagrama de casos de uso es relativamente fácil de comprender de forma intuitiva, incluso sin conocer la notación. Esto es una ventaja importante, ya que el modelo de casos de uso se puede tratar de forma coherente con un cliente que no necesita estar familiarizado con UML [2]. Un actor representa un rol que alguien tiene que cumplir, en vez de representar a un individuo en particular. Normalmente es señalado mediante el símbolo de un muñeco. Hay una línea que conecta un actor con un caso de uso si el actor puede interactuar con el sistema para realizar parte de la tarea. Esta relación, no obstante, no significa que necesariamente alguien de ese rol tenga que estar implicado en la ejecución de una tarea. Un caso de uso engloba un conjunto de requisitos del sistema, posiblemente complejo, que surge durante la captura de requisitos iniciales y que se refinará durante el desarrollo del sistema Diagramas de clases 11

12 Los diagramas de clases se utilizan para documentar la estructura estática del sistema; esto es, que clases hay y como están relacionadas, pero no como interactúan entre ellas para alcanzar un determinado comportamiento [2]. La construcción de un modelo de clases incluye la identificación de las clases que deberían existir en nuestro sistema: esta es una parte fundamental del trabajo de diseñar un sistema orientado a objetos. Es probable que el conjunto de clases de un determinado modelo varíe en mayor o menor medida a lo largo de las iteraciones del proceso de desarrollo Diagramas de clases coloreadas Esta técnica, propuesta por Peter Coad [referencia], emplea arquetipos que simplifican enormemente obtener las clases de un sistema, así como mantener el acoplamiento entre estas a niveles mínimos. Los diagramas de clases coloreadas se basan en el concepto de Componente Neutral al Dominio (DNC, Domain Neutral Component). Esto significa que, independientemente de lo que se pretenda modelar, los arquetipos siempre se relacionan entre ellos del mismo modo. Existen cuatro arquetipos, cada uno representado con un color en el diagrama de clases: Momentos Intervalos (clases rosa) Roles (clases amarillas) Personas, cosas y lugares (clases verdes) Descripciones (clases azules) En un principio, las clases se relacionan siguiendo la secuencia de colores rosa, amarillo, verde y azul; es decir, en un momento o intervalo de tiempo actúan unos roles 12

13 determinados, que son jugados por personas, cosas o lugares con una descripción. Es fácil ver que este patrón de colores mantiene un bajo acoplamiento: una determinada persona, cosa o lugar (una clase verde) se implementa totalmente ajena a los momento intervalo en los que va a intervenir, ya que lo hace a través de clases rol. Del mismo modo, las clases momento intervalo solo saben que hay ciertos actores relacionados con ellas, pero no tienen conocimiento de quienes son, y realmente tampoco necesitan tenerlo. Es importante tener en cuenta que el modelado mediante colores evoluciona de forma contraria al modelado tradicional. Esta técnica se basa en el principio de que la perfección se alcanza, no cuando no hay nada más que añadir, sino cuando no queda nada más que quitar 3, o dicho de otro modo menos filosófico, se comienza mapeando el dominio en términos del DNC, para después retirar las clases que se consideren redundantes hasta encontrar un equilibrio entre acoplamiento y complejidad Diagramas de secuencia Los diagramas de secuencia muestran la interacción de un conjunto de objetos en una aplicación a través del tiempo y se modela para cada caso de uso. El diagrama de secuencia contiene detalles de implementación del escenario, incluyendo los objetos y clases que se usan para implementar el escenario, y mensajes pasados entre los objetos La Ley de Demeter Esta regla fue formulada en la Northeastern University en 1987 por el equipo involucrado en el proyecto Demeter: Karl Lieberherr, Ian Holland y Arthur Riel. Garantiza, durante un desarrollo orientado a objetos, una buena escalabilidad, depuración de errores y mantenimiento, ya que ayuda a maximizar la encapsulación, lo que desemboca en un bajo nivel de acoplamiento. 3 Antoine de Saint-Exupéry 13

14 A menudo, esta ley se abrevia con una única frase: Habla sólo con tus amigos. Explicado un poco más a fondo y más formalmente, esto significa que un método m de un objeto o solo deberían invocar métodos de los siguientes objetos: El propio objeto o Los parámetros que recibe el propio método m Cualquier objeto que instancie el propio método m Cualquier atributo de o Esto hace que para la programación de cada método solo sea necesario un conocimiento del entorno inmediato de dicho método. Si para el funcionamiento del sistema fuese necesario invocar un método más lejano, no se haría directamente, sino que cada método invocaría a otro de su entorno cercano hasta llegar al que debe invocarse en último extremo Diagramas de actividad Los diagramas de actividad describen cómo se coordinan las tareas realizadas por el sistema. Estos diagramas son particularmente útiles para mostrar las dependencias entre las tareas realizadas, estableciendo los paralelismos y sincronismos de los flujos de trabajo del dominio. Se emplean en un ámbito de mayor abstracción que los diagramas de secuencia, empleados para modelar las interacciones ordenadas entre objetos, más cercanas a la implementación Diagramas de despliegue Un diagrama de despliegue muestra los enlaces de comunicación física entre elementos hardware y las relaciones entre estos elementos y los procesos software, es decir, qué se ejecuta dónde. El sistema físico está formado por nodos asociados entre sí, capaz cada uno de ellos de ejecutar componentes software. 14

15 2.3 - Arquitectura Tradicionalmente, las aplicaciones web se estructuran en capas, distribuyendo entre éstas las distintas responsabilidades funcionales del sistema. A continuación se hará un breve repaso por la evolución de los patrones arquitectónicos con objeto de justificar la estructura elegida para este proyecto Patrón MVC La arquitectura más simple, que sirve de base para evoluciones más complejas, es el patrón MVC (Model-View-Controller), una estructura de tres capas: Modelo: Contiene las entidades del dominio y la infraestructura necesaria para su gestión. Vista: Es la interfaz de usuario y presenta la información del modelo de forma comprensible. Controlador: Se encarga de comunicar las capas de Vista y Modelo, capturando las acciones ejecutadas por el usuario sobre la primera y traduciéndolas en operaciones sobre objetos del segundo. Esta arquitectura, aunque adecuada como base conceptual, presenta como defecto principal el condensar en una única capa el modelo y las clases de infraestructura necesarias para la aplicación, como pueden ser las clases de acceso a datos, que no pertenecen al dominio propiamente dicho. Este hecho provocó el salto a la siguiente arquitectura Arquitectura de 4 capas Esta estructuración implica un desdoblamiento de la capa de Modelo del patrón 15

16 MVC original en las capas de Aplicación, Dominio e Infraestructura, y fusiona las capas de Vista y Controlador en una única capa de Presentación. Tenemos por tanto, las siguientes capas: Ilustración 1: Arquitectura de 4 capas Presentación: Aúna las capas de Vista y Controlador del patrón MVC original. La justificación de esta decisión está en que el Controlador suele estar vinculado a las tecnologías utilizadas en la Vista, y no deja de ser un patrón Adaptador que permite invocar a las funcionalidades ofrecidas por el dominio. Aplicación: Esta capa se ocupa de coordinar las llamadas a la capa de Dominio e Infraestructura, y suele lidiar con aspectos como la transaccionalidad y la seguridad. Es importante destacar que esta capa no contiene lógica de negocio; su responsabilidad es la coordinación técnica. Siguiendo con la analogía de patrones, podría describirse como un gran Decorador que añade aspectos técnicos a la lógica de negocio pura, contenida en la capa de Dominio. Dominio: Este es el núcleo de la aplicación, donde residen las entidades y la lógica del dominio. Es la capa más importante del sistema y su responsabilidad es representar correctamente y de la forma más precisa posible el dominio de la aplicación. Se desentiende por completo de aspectos técnicos; estos son responsabilidad de las capas de Aplicación e Infraestructura. Infraestructura: Esta capa da soporte a las dos anteriores, encargándose de tareas como el acceso a datos o la comunicación con sistemas externos. Con esta nueva división se garantiza un reparto adecuado de las responsabilidades entre las distintas capas. No obstante, surge un nuevo problema, y es que esta arquitectura 16

17 sugiere una propagación descendiente de dependencias, es decir, el domino depende de la infraestructura utilizada para darle soporte. Cualquier cambio en la estructura de persistencia subyacente provocará cambios en la capa de dominio, que por definición debería ser ignorante de lo que suceda en el resto de capas de la aplicación Arquitectura hexagonal Para solucionar el problema de la propagación de dependencias originado en la arquitectura anterior, Alistair Cockburn [referencia] propuso un cambio, más conceptual que estructural, que parte de las mismas cuatro capas presentadas en el apartado anterior, pero que convierte la capa de Dominio en el núcleo de la arquitectura, anexando la capa de Aplicación al mismo, ya que es la encargada de regular las operaciones del modelo y proporciona las fachadas para las capas superiores. Este núcleo ofrece una serie de puertos a los que pueden conectarse módulos externos. Estos puertos pueden dividirse en puertos de servicios ofrecidos y consumidos, aunque en ambos casos vienen definidos por una interfaz que especifica las operaciones concretas de dicho puerto. La diferencia entre ambos tipos radica en donde reside la implementación de dichos servicios. En el caso de los servicios consumidos, el núcleo del sistema solo definirá la interfaz del servicio, de forma que las clases del dominio atacan dicha interfaz sin conocer su funcionamiento concreto, es decir, no dependen de la implementación de la misma. Aquellos módulo que ofrezcan los servicios para ese puerto, deberán implementar la interfaz correspondiente. El ejemplo más claro de esto es el acceso a la persistencia. 17

18 Ilustración 2: Arquitectura hexagonal En el caso de los servicios ofrecidos es el núcleo el que implementa dichos servicios, ofreciendo una interfaz a los módulos externos que quieran invocarlos. La interfaz de usuario es un ejemplo de este caso, en el que la capa de Presentación invoca operaciones sobre el núcleo. Esta arquitectura refuerza la importancia del dominio situándolo como núcleo de la aplicación y redirigiendo hacia él las dependencias del resto de capas. Esto permite la sustitución de elementos del sistema tales como el gestor de persistencia o la capa de presentación, o incluso la conexión de varios módulos contra un mismo puerto, dotando al núcleo de un Negociador que permita conmutar entre las distintas implementaciones. 18

19 Parte II Análisis Capítulo 3 Flujos generales de proceso Capítulo 4 Casos de uso 19

20 20

21 Capítulo 3 - Flujos generales de proceso A continuación se estudiarán los principales procesos involucrados en el funcionamiento del entorno clínico planteado. A partir de los flujos de proceso presentados aquí, se procederá a la extracción de casos de uso y funcionalidades del sistemas, que se abordarán en el capítulo siguiente. Este capítulo se dividirá en dos apartados, el primero de ellos orientado al proceso de consulta seguido por el facultativo, y el segundo orientado a la realización de exploraciones y su sincronización con el repositorio de historiales Proceso de consulta Este es el principal proceso del sistema y el origen de las necesidades que se pretenden cubrir. Cubre el flujo de trabajo seguido por el médico desde que un paciente solicita una consulta hasta que se le receta un tratamiento. El proceso comienza cuando un paciente pide cita para una consulta. Esta actividad actividad es realizada por uno de las enfermeras de la clínica, que actúan como personal administrativo. La petición de cita puede realizarse presencialmente o vía telefónica. En caso de que sea la primera vez que el paciente acude a la clínica, la enfermera dará de alta los datos personales del paciente, tales como dirección, teléfono, compañía aseguradora de tenerla, etc. 21

22 Ilustración 3: Proceso de consulta 22

23 A continuación, el flujo de proceso pasa a ser controlado por el médico, que procederá a actualizar la información de antecedentes y hábitos del paciente. Esto se hará tanto si es la primera vez que el paciente acude a la consulta como si es un paciente habitual. Una vez la información personal e histórica del paciente esté actualizada, el médico comienza con el proceso de diagnóstico propiamente dicho. Este parte de la actividad de anamnesis, que consiste en recopilar la información subjetiva que se pueda extraer del paciente de forma verbal para obtener una primera aproximación a su situación clínica. Este proceso se alargará lo necesario hasta decidir un protocolo de diagnóstico que se adecue a la situación. Tras establecer el protocolo de diagnóstico a seguir, el facultativo procederá a realizar las exploraciones pertinentes para llegar un diagnóstico concreto que le permita recetar un tratamiento al paciente. Cuando termine el proceso de diagnóstico y se haya establecido el tratamiento en caso de ser necesario, el flujo de proceso vuelve a manos de la enfermera, que procederá a generar la factura correspondiente a las pruebas realizadas. En caso de ser necesario un seguimiento del paciente, se establecerá una nueva cita. Con esto terminaría el procedimiento de consulta Proceso de exploraciones remotas Este procedimiento cubre el flujo de trabajo seguido por el médico para la realización de exploraciones en dispositivos remotos y su integración en el repositorio de historiales. El procedimiento comienza cuando el médico realiza una exploración. Debido a la heterogeneidad de las interfaces proporcionadas por los aparatos de diagnóstico, la imagen obtenida de la exploración será capturada mediante un dispositivo móvil. Una vez capturada, en caso de que se disponga de conexión con la red clínica, el dispositivo se sincronizará y volcará las imágenes con sus comentarios en el repositorio. 23

24 Ilustración 4: Proceso de exploraciones remotas 24

25 Si no se dispone de dicha conexión, las imágenes de la exploración permanecerán almacenadas en el dispositivo móvil hasta que éste vuelva a conectarse a la red. Por otra parte, la aplicación de gestión de historiales lanzará un proceso (bajo demanda o periódicamente) para comprobar si se han añadido nuevas imágenes al repositorio. En caso afirmativo, vinculará estas imágenes con el historial clínico correspondiente, de forma que sean accesibles por el resto de facultativos usuarios del sistema a través de la aplicación de gestión. 25

26 26

27 Capítulo 4 - Casos de uso A continuación se describen las principales funcionalidades que debe contemplar el sistema divididas por ámbitos. Estás funcionalidades se expresarán mediante los siguientes diagramas de casos de uso: casos de uso genéricos, casos de uso de administración, casos de uso de gestión de pacientes y casos de uso de consultas Jerarquía de actores El sistema cuenta con los siguientes actores: Usuario: Representa al usuario de la aplicación y es la base de la jerarquía. Está implicado en casos de uso genéricos no relacionados con el dominio. Médico: Es el encargado de diagnosticar al paciente y realizar las pruebas y exploraciones oportunas. Además, tiene potestad para cambiar los datos personales del paciente. Enfermera: Se encarga del alta de pacientes y de la generación de las facturas. Administrador: Este actor se encarga del mantenimiento de los catálogos de diagnósticos, fármacos y exploraciones que emplea el médico durante las consultas. Además, es el único actor que puede dar de alta a un nuevo usuario en el sistema. 27

28 Ilustración 5: Jerarquía de actores Casos de uso genéricos Los casos de uso genéricos contemplan funcionalidades de infraestructura que no están relacionadas con el dominio. Básicamente, se trata de cuestiones de registro en el sistema y actualización de los datos del usuario. Ilustración 6: Casos de uso genéricos El único elemento digno de reseña es el caso de uso de Registro de operación en BD; el sistema registrará a todas las operaciones llevadas a cabo por un usuario, de forma que queda una traza de la información accedida e insertada por un determinado usuario. 28

29 Por tanto, este caso de uso está incluido en todos los casos de uso del sistema, aunque por motivos de claridad se ha omitido en el resto de diagramas Casos de uso de administración Esta categoría de funcionalidades incluye la gestión de los catálogos de exploraciones, diagnósticos y fármacos soportados por el sistema, así como el registro de nuevos usuarios. Ilustración 7: Casos de uso de administración 29

30 Las funcionalidades contempladas en este diagrama son las siguientes: Registrar nuevo usuario: Permite dar de alta nuevos usuarios en el sistema, asignándoles un login y una contraseña por defecto, que posteriormente podrán modificar. Gestión de diagnósticos: Este caso de uso abarca las siguientes operaciones. Nuevo tipo de diagnóstico: Se añade un nuevo diagnóstico al catálogo de diagnósticos soportados por el sistema. Modificar tipo de diagnóstico: Permite editar las características de una entrada del catálogo de diagnósticos. Gestión de tipos de fármacos: Este caso de uso abarca las siguientes operaciones. Nuevo fármaco: Se añade un nuevo fármaco al catálogo de fármacos disponibles en el sistema. Modificar fármaco: Permite editar las características de una entrada del catálogo de fármacos. Eliminar fármaco: Se retira un fármaco del catálogo. Gestión de exploraciones: Este caso de uso abarca las siguientes operaciones. Nuevo tipo de exploración: Se añade un nuevo tipo de exploración al catálogo de exploraciones. Modificar tipo de exploración: Permite editar las características de una entrada del catálogo de exploraciones Casos de uso de gestión de pacientes Los casos de uso para la gestión de pacientes incluyen el alta y actualización de los datos personales de los pacientes, la actualización de sus antecedentes, tanto personales, como familiares, así como sus hábitos. Alta de paciente: Permite dar de alta un nuevo paciente introduciendo sus datos personales, tales como nombre, apellidos, dirección de contacto, fecha de nacimiento, etc. Actualizar datos: Permite modificar los datos personales de un paciente. 30

31 ción 8: Casos de uso de gestión de pacientes Ilustra Actualizar historia: Incluye las siguientes funcionalidades. Actualizar antecedentes personales: Permite añadir o modificar los antecedentes personales del paciente. Actualizar antecedentes familiares: Permite añadir o modificar los antecedentes familiares del paciente. Actualizar hábitos: Permite añadir o actualizar los hábitos personales del paciente. Buscar paciente: Este caso de uso es utilizado por el resto de casos de uso de este diagrama (a excepción de Alta de paciente) para obtener un paciente de la base de datos Casos de uso de consulta 31

32 Ilustración 9: Casos de uso de consulta 32

33 El proceso de consulta es el núcleo funcional del sistema y el que aglutina mayor número de casos de uso. Aquí se incluyen los siguientes casos de uso: Gestión de consultas: Permite gestionar las anotaciones referentes a una determinada consulta. Incluye las siguientes funcionalidades. Nueva entrada: Se añade una nueva anotación al historial clínico del paciente. Revisar consultas: Permite revisar el historial de consultas realizadas con el paciente, filtradas por diferentes criterios. Gestión de exploraciones: Permite gestionar las exploraciones realizadas a un paciente. Incluye: Realizar exploración: Se añade una nueva exploración al historial del paciente. Se incluyen los comentarios del médico, así como las imágenes adjuntas. Seleccionar aparato: Las exploraciones estarán categorizadas en base al aparato al que afecten. Revisar exploraciones: Permite revisar el historial de exploraciones realizadas a un paciente. Detalle de exploración: Permite acceder al detalle de una exploración concreta, incluyendo las imágenes adjuntas. Sincronizar exploraciones: Sincroniza la aplicación de gestión de historiales con el repositorio de exploraciones remotas para añadir al historial los posibles cambios, si los hubiera. Gestión de tratamientos: Permite gestionar los tratamientos recetados al paciente. Expedir receta: Genera un documento de receta con los fármacos indicados por el doctor. Seleccionar fármacos: El médico selecciona los medicamentos adecuados del catálogo del sistema, indicando cantidad, frecuencia, presentación y duración del tratamiento. Revisar tratamientos: Permite revisar el historial de tratamientos recetados al paciente. Consultar informe del paciente: Este caso de uso incluye Revisar consultas, Revisar exploraciones y Revisar tratamientos, y permite al usuario obtener un 33

34 resumen del historial clínico del paciente en el que se mostrarán los últimos datos. Actualizar historial clínico: Este caso de uso está incluido en Nueva entrada y Realizar exploración, y actualiza el historial en persistencia para permitir el acceso al mismo por otro usuarios. Generar factura: Se genera una factura con los conceptos correspondientes a la consulta realizada, incluyendo las exploraciones pertinentes. Los conceptos incluidos en la factura serán editables. 34

35 Parte III Desarrollo Capítulo 5 Gestión de historiales Capítulo 6 Soporte de movilidad Capítulo 7 Soporte de protocolos diagnósticos 35

36 36

37 Capítulo 5 - Gestión de historiales La aplicación de gestión de historiales es la base del sistema y la que cubre las necesidades básicas de los usuarios. En este capítulo se describirá el proceso de desarrollo seguido para la implementación de esta aplicación; para mantener la coherencia con la metodología planteada en el capítulo 2, se dividirá este capítulo en varios apartados, cada uno de los cuales describirá una iteración del desarrollo Herramientas Para el desarrollo de la aplicación se ha empleado el lenguaje Java en su versión J2EE 6, con el apoyo de varios frameworks como Hibernate, Spring y Tapestry. La persistencia se implementado mediante el sistema gestor de bases de datos MySQL 5.1, y la aplicación se ha desplegado en un servidor Apache Tomcat 6.0. Las tareas de compilación, pruebas y gestión de dependencias del proyecto han sido manejadas mediante Apache Maven. A continuación se describen estos elementos con más detalle Java EE 6 Java es un lenguaje de programación orientado a objetos creado por Sun Microsystems durante la década de los 90. Hoy en día es uno de los lenguajes de programación más extendidos debido a su amplía portabilidad, consecuencia de la 37

38 utilización de un soporte de ejecución estándar proporcionado por una máquina virtual. Para este proyecto se utilizará el entorno de ejecución (JRE) versión 6 y el kit de desarrollo (JDK) versión 1.6.0_ Hibernate ga Hibernate es un framework de mapeo objeto-relacional (ORM) para Java que facilita la sincronización entre los objetos utilizados en memoria y el modelo de datos utilizado en persistencia. Para ello, Hibernate mapea directamente los atributos de los objetos a las columnas de las tablas en base de datos, convirtiendo los tipos utilizados por Java a los tipos utilizados por SQL. Este framework proporciona también un lenguaje de consulta llamado HQL (Hibernate Query Language), similar a SQL, pero totalmente orientado a objetos y capaz de soportar conceptos como la herencia, el polimorfismo y las asociaciones. Este lenguaje es independiente del sistema gestor de bases de datos utilizado, lo que hace que la tecnología utilizada para la implementación de la persistencia sea transparente para la aplicación Spring Spring es un framework de código abierto que proporciona un modelo para la programación y configuración de aplicaciones Java, actuando como plataforma de integración para tecnologías heterogéneas. Permite abstraer los objetos del dominio de la complejidad de la gestión de componentes estructurales de la aplicación, tales como la seguridad, el control de transacciones, el acceso a datos, etc. Además proporciona un contexto de aplicación encargado del manejo del flujo de objetos y la gestión de las dependencias entre ellos, evitando la implementación manual de factorías. 38

39 Tapestry Apache Tapestry es un framework para la implementación de aplicaciones web basadas en el patrón MVC. Sigue un enfoque orientado a componentes, en contraposición a la orientación a acciones. Esto significa que cada página de la aplicación está compuesta por varios componentes con la capacidad de lanzar eventos. Está construido sobre la API estándar de servlets, lo que implica que funciona dentro de servidores de aplicaciones simples. Sigue la filosofía de convención sobre la configuración, haciendo énfasis en la simplicidad y la facilidad de uso. En aplicaciones simples es posible implementar las funcionalidades necesarias en las clases Java que manejan los eventos de los componentes. En este caso, sin embargo, dichas clases invocarán los métodos proporcionados por el modelo en sus fachadas, tal y como se explica en el capítulo MySQL 5.1 MySQL es un SGBD muy popular, con cerca de seis millones de instalaciones. Es código abierto, pero a diferencia de otros proyectos como Apache, es propiedad y está patrocinado por una empresa sin ánimo de lucro, MySQL AB, desde enero de 2008 una subsidiaria de Sun Microsystems y ésta propiedad a su vez de Oracle Corporation desde abril de MySQL puede ser utilizado por muchos lenguajes de programación, incluidos C#, C, C++, Eiffel, Java, Smalltalk, Lisp, Perl, PHP, Python, Ruby, REAL-basic y Tcl. Cualquier lenguaje que soporte la interfaz de Open database connectivity (ODBC o Conectividad Abierta de Base de Datos) debería poder utilizar también MySQL. El lenguaje nativo de MySQL es C. 39

40 Apache Tomcat Tomcat es un servidor web con soporte para sevlets y JSP desarrollado por la Apache Software Foundation. Puede funcionar como servidor web por sí mismo. Dado que fue escrito en Java, Tomcat puede funcionar en cualquier sistema con una máquina virtual Java Apache Maven Maven es una herramienta de software para la gestión y construcción de proyectos Java, similar en funcionalidad a Apache Ant. Sigue un modelo de configuración de construcción más simple, basado en un formato XML. Maven utiliza un Project Object Model (POM) para describir el proyecto de software a construir, sus dependencias de otros módulos y componentes externos, y el orden de construcción de los elementos. El motor incluido en su núcleo puede dinámicamente descargar plugins de un repositorio, que también provee acceso a muchas versiones de diferentes proyectos Open Source en Java, de Apache y otras organizaciones y desarrolladores Módulos de la aplicación La aplicación estará compuesta por varios módulos para distribuir y aislar funcionalidades, aumentando las posibilidades de reutilización y facilitando futuros cambios al poder localizarlos en un único módulo. No todos los módulos descritos entran dentro del alcance de este proyecto, pero se ha considerado adecuado incluir un comentario al respecto y plantearlos para su posible desarrollo en el futuro. 40

41 Ilustración 10: Módulos de la aplicación Los módulos planteados son los siguientes: Historiales: Es el módulo principal de la aplicación y por el que se comenzará el desarrollo. Como su nombre indica, da soporte a la gestión de pacientes e historiales. Incluirá también funcionalidades estructurales tales como el registro de los usuarios en la aplicación. Facturación: En este módulo se encapsulan las clases responsables de la generación de facturas, así como aquellas relacionadas con las sociedades médicas y los conceptos que estas cubren. Hace uso de elementos del módulo de historiales. Agenda: Aquí se dará soporte a la gestión de las citas de la clínica, permitiendo a los usuarios obtener rápidamente información de los pacientes que deben atender en la jornada y agilizar el acceso a sus historiales desde la propia agenda. Estadísticas: Este módulo permitirá la generación de estadísticas a partir de los datos almacenados en los historiales clínicos, tales como los resultados de las exploraciones realizadas o los tratamientos recetados. Generador de informes: Se trata de un módulo de utilidades de carácter totalmente estructural. Su función es encapsular la lógica de generación de informes de todo tipo, desde facturas a recetas. El resto de módulos hacen uso de las facilidades proporcionadas por éste. 41

42 Protocolos: Finalmente, este es el módulo encargado de gestionar los distintos protocolos de diagnóstico soportados por el sistema, ofreciendo posibles opciones al usuario inferidas a partir de los datos de entrada proporcionados por éste, obtenidos mediante un proceso de anamnesis. De los módulos aquí presentados, los de agenda y estadísticas están fuera del alcance del proyecto, mientras que el módulo de protocolos será objeto de una labor de prototipado tal y como se explica en el capítulo º Iteración El proceso de desarrollo de la aplicación comienza a partir del módulo de historiales, que como se explica en el apartado anterior, es el módulo principal de la aplicación. Como primer paso, a partir de los casos de uso y los flujos de proceso obtenidos durante la fase de análisis, se esboza un primer diagrama de clases de alto nivel para establecer una base de diseño a partir de la cual obtener sucesivas versiones refinadas. Como se explica en el capítulo 2, para obtener este primer diagrama se hace uso de la técnica de modelado con clases coloreadas. Esto permite obtener rápidamente una primera relación de clases. Evidentemente, estas clases surgen de la aplicación sistemática de la relación entre arquetipos planteada por la técnica utilizada, por lo que varias de las clases son redundantes o innecesarias. Antes de proceder a implementar una primera aproximación es necesario refinar este primer diagrama. Los razonamientos seguidos en este refinamiento han sido los siguientes: Se elimina la clase rol Médico, ya que se ha considerado innecesaria al no aportar nada a la funcionalidad de la aplicación. Un médico no tiene más atributos que un usuario estándar y por ello no se considerará como una entidad relevante en el dominio. 42

43 Ilustración 11: 1º Iteración - Diagrama de alto nivel del módulo de historiales Se han unido las entidades Persona y Paciente en una sóla (rol Paciente). Según el modelo de alto nivel, todo usuario del sistema era considerado de tipo Persona y 43

44 por lo tanto debía de introducir multitud de datos de registro que no eran necesarios y podían resultar incómodos, pues dichos datos sólo eran relevantes para los pacientes. Por lo tanto, se ha tomado la decisión de considerar sólo aquellas personas que sean pacientes de la clínica médica, dando como resultado el rol Paciente. Se elimina la clase descripción DescripciónPersona ya que no tiene razón de ser al desaparecer la entidad Persona. Se elimina la clase Historial, generándose el historial bajo demanda en tiempo de ejecución, mediante la composición de sus consultas, con sus correspondientes diagnósticos y exploraciones. Una vez realizados estos cambios, se dispone de un primer modelo relativamente preciso para comenzar un ciclo de codificación con el objetivo de comprobar la funcionalidad de aquel. Il ustración 12: 1º Iteración - Diagrama de clases refinado del módulo de historiales 44

45 En esta primera fase de codificación es necesario definir una estructura de paquetes que permita encapsular adecuadamente los componentes del modelo y permitan flexibilidad en los cambios que supondrán las iteraciones posteriores. Ilustración 13: 1º Iteración - Distribución de paquetes del módulo de historiales La distribución de paquetes elegida se ajusta a la arquitectura propuesta en el capítulo 2, manteniendo la lógica de negocio en los paquetes de Modelo y Aplicación y encapsulando los elementos relacionados con la infraestructura y la presentación en los paquetes correspondientes. Los paquetes planteados son los siguientes: interfaces: Contiene los componentes de la interfaz del usuario y de presentación en general. Abarca los siguientes sub-paquetes: web: Contiene las clases de la capa Controller del patrón MVC, encargadas de captar los eventos de la interfaz. En este proyecto se tratará de las clases Java correspondientes a las páginas.tml de Tapestry. fachada: Aquí se encapsula una fachada intermedia entre los controladores del paquete anterior y los servicios ofrecidos por el modelo. El objetivo de esto es que las clases controladoras ataquen a una única interfaz. servlets: En este paquete se encuentran servlets adicionales para labores 45

46 relacionadas con la vista, como por ejemplo la presentación de pdf's embebidos. aplicación: Este paquete contiene los servicios de la aplicación, que se encargan de articular los casos de uso a partir de las clases del modelo. Estos casos de uso se agrupan en fachadas en función de un criterio más o menos arbitrario; en este caso se han agrupado según la entidad con la que están relacionados. dto: Contiene objetos de transferencia de datos para los casos en los que las entidades del dominio no son adecuadas para transmitir datos a la interfaz, por ejemplo en los casos de listados paginados, en los que es necesario mostrar colecciones de objetos ordenadas a partir de un índice de inicio. impl: Contiene la implementación de las interfaces de servicios definidas en el paquete raíz. util: Contiene diversas clases de utilidades, como por ejemplo clases de formateo. modelo: Aquí se encuentran las entidades del dominio, así como la definición de sus clases de acceso a datos. Contiene un sub-paquete por cada entidad del modelo, por lo que es probable que el número de aquellos varíe en función de los refinamientos que sufra éste. infraestructura: Este paquete aglutina clases de carácter técnico responsables de cuestiones como la persistencia o el envío y recepción de correos. persistencia: Aquí se encuentran las clases que implementan las interfaces de acceso a datos para las entidades definidas en el modelo. mail: Contiene clases de envío y revisión de mails. util: Contiene clases de utilidades, como por ejemplo un DAO genérico y diversas excepciones. Con esta estructura de paquetes definida se procede a la codificación de una primera versión del modelo. Los errores e imprecisiones hallados en esta versión conducirán a una segunda iteración de desarrollo, en la que el modelo sufrirá algunos cambios para ajustarlo a las funcionalidades requeridas. 46

47 5.4-2º Iteración Como resultado de la iteración anterior se obtiene una primera versión de la aplicación, reducida en sus funcionalidades, pero que permite refinar el modelo inicial. Dicho modelo sufría de ciertos fallos que complicaban innecesariamente el funcionamiento de la aplicación, especialmente a nivel de interfaz de usuario. En esta iteración se prescinde de las clases coloreadas y se utiliza la notación típica de los diagramas de clases de UML, debido a que el desarrollo se encuentra en una fase de bajo nivel conceptual en la que los arquetipos dejan de ser relevantes. Las correcciones del modelo han sido las siguientes: La relación entre Consulta y Exploraciones se ha eliminado. En su lugar, las Exploraciones se relacionan directamente con el Paciente. Este se debe a que una exploración no tiene porque realizarse durante una consulta, especialmente en el caso de exploraciones remotas o derivadas a otras clínicas. Se han considerado aparte de las exploraciones las mediciones de temperatura, peso y tensión del paciente por ser pruebas rutinarias y diferenciadas de otras más invasivas y de resultados más complejos, como pueden ser las endoscopias. El considerarlas en tablas aparte facilitará la extracción de estadísticas y la generación de gráficas. Se ha añadido la entidad Receta para representar las distintas recetas expedidas al paciente y dejar constancia así de los tratamientos a los que ha sido sometido. Tras estos cambios en el diseño, se procede a realizar las pertinentes modificaciones en el código. Además del referido refinamiento del modelo, en esta iteración se añaden también componentes de carácter más técnico, siendo los siguientes los más destacables: Servicio de generación de recetas: Este servicio genera documentos en formato pdf a partir de los tratamientos introducidos por el usuario en la aplicación. Estos 47

48 pdf tiene el formato adecuado para su impresión y entrega al paciente. Sistema de embebido de pdf: A partir de un servlet y librerías auxiliares, la aplicación recupera y genera documentos pdf en tiempo real para mostrarlos al usuario. Servicio de generación de gráficas: Este servicio permite generar gráficas en tiempo real a partir de los datos almacenados en persistencia. Se utiliza para mostrar la evolución del peso y la tensión de los pacientes. Ilustración 14: 2º Iteración - Diagrama de clases refinado del módulo de historiales Obviamente, los cambios en el diseño suponen añadir sub-paquetes al paquete modelo, de forma análoga al resto de entidades. De este modo, a dicho paquete se añadirá el paquete receta, que contendrá las clases relacionadas con esta entidad. Las clases Tensión, Temperatura y Peso se añadirán al paquete consulta. 48

49 5.5-3º Iteración Una vez implementados los cambios de la segunda iteración, se tiene una versión estable y relativamente precisa de la aplicación objetivo. A pesar de que el modelo resultante seguirá siendo objeto de cambios, es momento de ampliar el alcance del mismo para añadir funcionalidades a la aplicación. Con esto en mente, se afronta el diseño del módulo de facturación, que si bien es un módulo aparte, tiene ciertas dependencias del módulo de historiales. En la primera iteración de ilustró el proceso seguido para obtener un primer modelo preliminar a partir del cual comenzar el ciclo iterativo; el mismo método será aplicado para el módulo de facturación. Para agilizar la descripción del procedimiento (y dada la relativa sencillez de esta parte del dominio), se obviará el primer modelo obtenido de la aplicación rigurosa de los arquetipos de clases coloreadas y la explicación partirá de la primer refinamiento de aquel. Ilustración 15: 3º Iteración - Diagrama de clases refinado del módulo de facturación 49