Sistema de información para la unidad de Podología de la UMA

1 2 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DE LA SALUD Sistema de Información para la Unidad de Podología de la UMA. Information System for the Podiatry Unit of UMA. Realizado por: Maria José Muñoz González. Tutorizado por: Jose Manuel Jerez Aragonés. Co-tutorizado por: Julio Montes Torres. Departamento Lenguaje y Ciencias de la Computación UNIVERSIDAD DE MÁLAGA MÁLAGA, Junio de 2018 3 4 Resumen La recolección de datos de la Unidad Asistencial de Podología (UAP) de la Universidad de Málaga aún se hace a mano. Esto es un trabajo pesado y que incluye un gasto de tiempo, el cual podría emplearse en exploración del paciente. La aplicación web del proyecto “PodoApp” intenta sustituir esa manera actual de trabajo para poder tener una clínica digitalizada. De manera, que se recogen los datos y se almacenan directamente en una base de datos sin necesidad de archivar los historiales clínicos de los pacientes de manera física. PodoApp está implementado en ASP.NET y es parte de un gran proyecto. Este proyecto consistirá en dotar a la página web de total funcionalidad. Aparte de la digitalización, lo que se busca es poder integrar a la podología en el campo de la investigación mediante técnicas de minería de datos, las cuales permitirán realizar estudios sobre ciertas variables de interés para los podólogos. Palabras claves UAP, PodoApp, ASP.NET, Digitalización, Minería de datos. 5 Abstract The collection of data from the Podiatry Care Unit (UAP) of the University of Malaga is still done by hand. This is laborious work and involves spending a lot of time on the task, which could be focused on patient exploration. The web application of the “PodoApp” project tries to replace the current way of working in order to create a digitalized clinic. In this way, the data would be collected and stored directly in a database without the need to archive the clinical records of patients in a physical format. PodoApp is implemented in ASP.NET and is a part of a larger project. This project will provide the website with full functionality. Apart from digitalization, it is intended to integrate podiatry in the field of research using data mining techniques, which will allow studies of certain variables of interest to podiatrists. Keywords UAP, PodoApp, ASP.NET, Digitalization, Data mining. 6 Dedicado a mi familia y a todas las personas que me han ayudado y acompañado a lo largo de estos cuatro años. Solo puedo daros las gracias y deciros que de todos he aprendido algo. 7 Índice 1 Introducción 9 1.1 Motivación ........................................ 9 1.2 Estado de la cuestión ................................... 9 1.3 Metodología ........................................ 10 1.4 Objetivos ......................................... 11 1.5 Estructura de la memoria ................................ 12 2 Análisis 13 2.1 Requisitos ......................................... 13 2.2 Casos de uso ....................................... 14 3 Diseño e Implementación 24 3.1 Tecnologías usadas .................................... 24 3.1.1 ASP.NET ..................................... 24 3.1.2 MVC ....................................... 25 3.1.3 SQL Server .................................... 25 3.2 Diseño ........................................... 26 3.2.1 Diseño de la Base de datos ........................... 26 3.2.2 Diseño de la Aplicación Web .......................... 29 4 Pruebas 42 5 Conclusiones 42 5.1 Futuras líneas de trabajo ................................ 42 6 Bibliografía 43 Anexo I 1 Anexo II 8 8 1 Introducción 1.1 Motivación Este proyecto surge ante la petición de la facultad de Ciencias de la Salud de la Universidad de Málaga de crear una Aplicación Web que les permitiese, entre otras cosas, la gestión de sus pacientes. Cuando acudimos a la Unidad de Podología de la Universidad de Málaga observamos que los profesionales o estudiantes en prácticas recojen los datos de los pacientes a mano. Éstos rellenan una serie de informes a medida que se va desarrollando la consulta. Posteriormente, los informes son guardados en archivadores hasta la próxima consulta del paciente. Lo que se pretende es sustituir todo el proceso manual de recolección de datos, rellenando así un formulario a través de Internet y pudiendo almacenar las respuestas. Por otro lado, cuando el paciente acudiese nuevamente a la consulta, bastaría con buscar los datos correspondientes para así poder acceder a todos los informes disponibles del mismo. 1.2 Estado de la cuestión Encontramos diversas empresas que se encargan de producir software que está destinado a la gestión de clínicas, consultas y hospitales: •Aquar Software [1]. Se trata de una aplicación de escritorio que permite el acceso desde distintos sistemas operativos (iOS, Windows). Está orientada a la gestión de datos de los pacientes mediante citas, agendas e historial clínico. •DASI Clinic [2]. Se trata de una aplicación de escritorio dividida en tres grandes partes. Por un lado, la gestión de la agenda. Por otro lado, la gestión de pacientes y datos clínicos. Y, por último, gestión económica y administración. A diferencia de la anterior, ésta si permite la obtención de estadísticas a partir de los cuestionarios que rellenan los pacientes. •Apclinic [3]. Se trata de una aplicación web muy orientada a la gestión de citas/agenda, la gestión de pacientes y la gestión administrativa. A diferencia de las anteriores ofrece la posibilidad de gestionar mutuas, pero nada acerca de obtención de estadísticas. •NetClinicas [4]. Se trata de una aplicación de escritorio que, al igual que las mencionadas anteriormente, trata la gestión de pacientes, agenda y administración. Incluye la obtención de estadísticas pero se trata de un estudio básico. •Qclinicas [5]. Se trata de una aplicación de escritorio que está centrada en la gestión de citas y en la gestión de pacientes. La mayoría de estas aplicaciones son software genérico que se adapta a las posteriores peticiones de los clientes, en este caso, podólogos. Todas ellas tienen en común que están destinadas a la gestión de los datos de los pacientes, pero no están destinadas a la explotación de dichos datos. Es cierto que algunas presentan la opción de realizar estadísticas, pero se trata de estadísticas orientadas a los gastos de la consulta o de estadísticas básicas respecto a los pacientes. Con la creación de nuestra aplicación se pretende poder realizar investigación. De modo que tendría doble utilidad. Por un lado, gestionar los pacientes y, por 9 Caso de uso Título RF3.2. El usuario puede editar los datos personales de un paciente. RF3.4. El usuario puede editar los datos clínicos de un paciente. Descripción El usuario una vez que ha iniciado sesión puede editar los datos de un paciente. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar datos personales. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. Los datos del paciente han sido editados. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar datos personales. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. El sistema muestra los datos que no poseen el formato correcto o los datos que son obligatorios de añadir. 8. El usuario corrige los campos erróneos. 9. El usuario pulsa el botón de Modificar. 10. El sistema valida los datos. 11. Los datos del paciente han sido editados. Clases de análisis PacienteController, FormPaciente y Edit. 16 Caso de uso Título RF4. El usuario puede añadir los antecedentes de un nuevo paciente. Descripción El usuario una vez que ha iniciado sesión puede añadir los antecedentes de un paciente si estos no estaban previamente añadidos. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Añadir antecedentes. 4. El usuario rellena los campos necesarios. 5. El usuario pulsa el botón de Añadir. 6. El sistema valida los datos. 7. Los antecedentes de dicho paciente han sido creados. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Añadir antecedentes. 4. El usuario rellena los campos necesarios. 5. El usuario pulsa el botón de Añadir. 6. El sistema valida los datos. 7. El sistema muestra los datos que no poseen el formato correcto o los datos que son obligatorios de añadir. 8. El usuario corrige los campos erróneos. 9. El usuario pulsa el botón de Añadir. 10. El sistema valida los datos. 11. Los antecedentes de dicho paciente han sido creados. Clases de análisis AntecedentesController, FormAntecedentes y Create. 17 Caso de uso Título RF5. El usuario puede editar los antecedentes de un paciente. Descripción El usuario una vez que ha iniciado sesión puede editar los antecedentes de un paciente si este ya tenía antecedentes añadidos. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar Antecedentes. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. Los antecedentes han sido modificados. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar antecedentes. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. El sistema muestra los datos que no poseen el formato correcto o los datos que son obligatorios de añadir. 8. El usuario corrige los campos erróneos. 9. El usuario pulsa el botón de Modificar. 10. El sistema valida los datos. 11. Los antecedentes han sido modificados. Clases de análisis AntecedentesController, FormAntecedentes y Edit. 18 Caso de uso Título RF6. El usuario puede editar la primera visita de un paciente. Descripción El usuario puede editar la primera visita de un paciente. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar primera visita. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. La primera visita ha sido creada. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. El usuario pulsa sobre el botón de Editar primera visita. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa el botón de Modificar. 6. El sistema valida los datos. 7. El sistema muestra los datos que no poseen el formato correcto o los datos que son obligatorios de añadir. 8. El usuario corrige los campos erróneos. 9. El usuario pulsa el botón de Modificar. 10. El sistema valida los datos. 11. La primera visita ha sido creada. Clases de análisis PrimeraVisitaController, FormPrimeraVisita y Edit. 19 Caso de uso Título RF7. El usuario puede añadir el diágnostico de un paciente. RF9. El usuario puede añadir el tratamiento de un paciente. Descripción El sistema ofrece la posibilidad de añadir un diagnóstico y un tratamiento al paciente que se le esté realizando la consulta. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado el usuario pulsa sobre el botón de Añadir diagnóstico y tratamiento. 4. El usuario rellena los campos necesarios. 5. El usuario pulsa sobre el botón Añadir. 6. El diagnóstico y el tratamiento son añadidos en la base de datos. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado el usuario pulsa sobre el botón de Añadir diagnóstico y tratamiento. 4. El usuario rellena algunos campos. 5. El usuario pulsa sobre el botón Añadir. 6. El sistema muestra los campos erróneos. 7. El usuario corrige los campos. 8. El usuario pulsa sobre el botón Añadir. 9. El diagnóstico y el tratamiento son añadidos en la base de datos. Clases de análisis DiagnosticoTratamientoController, FormDiagnosticoTratamiento y Create. 20 Caso de uso Título RF8. El usuario puede editar el diágnostico de un paciente. RF10. El usuario puede editar el tratamiento de un paciente. Descripción El sistema ofrece la posibilidad de editar el diagnóstico y el tratamiento del paciente al que se le esté realizando la consulta. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado el usuario pulsa sobre el botón de Editar diagnóstico y tratamiento. 4. El usuario modifica los campos necesarios. 5. El usuario pulsa sobre el botón Modificar. 6. El diagnóstico y el tratamiento son añadidos en la base de datos. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado el usuario pulsa sobre el botón de Editar diagnóstico y tratamiento. 4. El usuario modifica algunos campos. 5. El usuario pulsa sobre el botón Modificar. 6. El sistema muestra los campos erróneos. 7. El usuario corrige los campos. 8. El usuario pulsa sobre el botón Modificar. 9. El diagnóstico y el tratamiento son modificados en la base de datos. Clases de análisis DiagnosticoTratamientoController, FormDiagnosticoTratamiento y Edit. 21 Caso de uso Título RF11. El usuario puede crear una nueva consulta de un paciente. Descripción El sistema ofrece la posibilidad de crear una nueva consulta para un paciente. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado pulsa sobre el botón de Añadir consulta. 4. El usuario añade los campos necesarios. 5. El usuario pulsa sobre el botón Añadir. 6. La consulta se añade en la base de datos. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado el usuario pulsa sobre el botón de Añadir consulta. 4. El usuario modifica algunos campos. 5. El usuario pulsa sobre el botón Añadir. 6. El sistema muestra los campos erróneos. 7. El usuario corrige los campos. 8. El usuario pulsa sobre el botón Añadir. 9. La consulta se añade en la base de datos. Clases de análisis ConsultaController, FormConsulta y Create. 22 Caso de uso Título RF12. El usuario puede editar una consulta de un paciente. Descripción El sistema ofrece la posibilidad de editar una consulta de un paciente. Pre-condición Post-condición Prioridad Alta. Autor Maria José Muñoz González. Control de cambios Escenario principal 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado pulsa sobre el botón de Consultas. 4. El sistema muestra una lista con las consultas previas, en caso de que existan. 5. El usuario pulsa sobre el botón de Editar en la consulta que necesite. 6. El usuario modifica los campos necesarios. 7. El usuario pulsa sobre el botón Modificar. 8. La consulta se modifica en la base de datos. Escenario alternativo 1. El usuario ha iniciado sesión satisfactoriamente en la página web. 2. El usuario pulsa sobre el botón de Lista de pacientes. 3. En el paciente desado pulsa sobre el botón de Consultas. 4. El sistema muestra una lista con las consultas previas, en caso de que existan. 5. El usuario pulsa sobre el botón de Editar en la consulta que necesite. 6. El usuario modifica algunos campos. 7. El usuario pulsa sobre el botón Modificar. 8. El sistema muestra los campos erróneos. 9. El usuario corrige los campos. 10. El usuario pulsa sobre el botón Modificar. 11. La consulta se modifica en la base de datos. Clases de análisis ConsultaController, FormConsulta y Edit. 23 3 Diseño e Implementación En esta sección nos centraremos en varios puntos importantes. Abordaremos las diferentes tecnologías utilizadas, el diseño de la base de datos y el diseño de la aplicación web. 3.1 Tecnologías usadas El entorno de desarrollo utilizado es Visual Studio 2017, ya que nos permite escribir código en C#, entre otros varios lenguajes que permite este IDE. Para el desarrollo, nos vamos a ayudar de ASP.NET y vamos a utilizar el patrón de Modelo-VistaControlador (MVC). Como sistema gestor de base de datos utilizaremos SQL Server 2012. Además, aunque principalmente esta aplicación va a ser utilizada en tablets, se ha decidido que para realizar la interfaz nos vamos a apoyar en Bootstrap. De esta manera, si en algún momento es necesario utilizar un ordenador o un dispositivo móvil, se adaptaría sin ningún problema. 3.1.1 ASP.NET ASP.NET [9] es un entorno para aplicaciones web, desarrollado y comercializado por Microsoft. Se usa para construir sitios web dinámicos, aplicaciones web y servicios web XML. ASP.NET es el sucesor de ASP (Active Server Pages). Además, está construido sobre el Common Language Runtime (CLR) que es un entorno de ejecución para los códigos de los programas que corren sobre la plataforma Microsoft .NET. Estar construido sobre CLR permite escribir código ASP.NET usando cualquier lenguaje admitido por el .NET Framework (algunos de estos son: C#, Visual Basic .NET, F#, etc.) ASP.NET [10] ofrece tres marcos de trabajo para crear aplicaciones web: páginas Web de ASP.NET, formularios Web Forms y ASP.NET MVC. En este caso, vamos a usar ASP.NET MVC. 24 3.1.2 MVC Figura 2. Esquema del patrón MVC. Los componentes de MVC [11] se podrían definir tal que: •Modelo. Contiene una representación de la información que maneja el sistema, su lógica de negocio y los mecanismos de persistencia. Es el que se encarga de acceder a la capa de almacenamiento de los datos y de definir la lógica de negocio (los privilegios de acceso que se hayan descrito en las especificaciones de la aplicación). Por tanto, lo que hace es enviar a la Vista aquella parte de la información que en cada momento se le solicita para que sea mostrada al usuario. •Vista, también llamada interfaz de usuario. Es la que presenta el Modelo, es decir, la información y la lógica de negocio en un formato adecuado para interactuar con el usuario. Por tanto, requiere de dicho Modelo la información que debe representar como salida. •Controlador. Es el intermediario entre el Modelo y la Vista, de manera que responde a acciones del usuario (eventos en los que se hace alguna solicitud de información) mediante la invocación de peticiones al Modelo. 3.1.3 SQL Server Se trata de un sistema de gestión de base de datos relacionales [12]. Esto significa que nos permite crear, actualizar y administrar una base de datos relacional. Siendo una base de datos relacional una colección de elementos de datos organizados en tablas. 25 @p4, . . . )" , nuevoID , thi s . Nombre , this .PrimerApellido , this . SegundoApellido , this . FechaNacimiento , . . . ) ; . . . tr .Commit ( ) ; } catch ( Exception ) { tr . Rollback ( ) ; throw ; } } } A través de podologiaEntities accedemos a la base de datos. Es necesario la creación de nuevos identificadores, para que así cada vez que introduzcamos un paciente nuevo, éste posea un identificador diferente. Debemos hacer una sentencia INSERT INTO para cada tabla en la que queramos insertar datos. Aquí tenemos valores de la tabla Paciente, Persona, HistorialClinico y creamos el identificador de la PrimeraVisita. La estructura del INSERT es la que se muestra arriba. Es importante que los campos escritos coincidan con los campos de las tablas de la base de datos creada. También es importante asegurarnos de que el campo @px, siendo x un número cualquiera, está haciendo referencia al campo correspondiente y se le asigna el valor deseado mediante this.valor, siendo valor el nombre de la propiedad. Otro elemento importante, es hacer Commit, para guardar/confirmar los cambios realizados en la base de datos de forma permanente. Por último, hemos creado el método GuardarEn(). Este lo que nos permite es poder realizar cambios en los elementos ya insertados en la base de datos. De este modo: public void GuardarEn( podologiaEntities podo ) { paciente paciente = podo . paciente . Where( p => p . idPaciente == this . IdPaciente ) . FirstOrDefault ( ) ; persona persona = paciente . persona ; using ( var tr = podo . Database . BeginTransaction ()) { try { Debug . Assert ( 32 thi s . IdPaciente == paciente . idPaciente ) ; Debug . Assert ( thi s . IdPodologo == paciente . id_podologo ) ; int ret = podo . Database . ExecuteSqlCommand( @"UPDATE [ paciente ] SET [ medicacionHabitual ] = @p1, . . . WHERE [ idPaciente ] = @p0 " , paciente . idPaciente , this . MedicacionHabitual , . . . ) ; tr .Commit ( ) ; } catch ( Exception ) { tr . Rollback ( ) ; throw ; } } } A través de podologiaEntities accedemos a la base de datos. A partir del identificador del paciente seleccionado, extraemos la información para las tablas paciente y persona. El siguiente paso sería comprobar que los identificadores se corresponden con los identificadores de las tablas que hemos recuperado. Y posteriormente, hacemos las sentencias UPDATE. Ahora, sólo se van a modificar las tablas Persona y Paciente, ni la tabla HistorialClinico, ni la tabla PrimeraVisita, ya que de estas dos últimas, dichos valores no podemos modificarlos. Por otro lado, debemos tener en cuenta las mismas cuestiones que para los INSERTS, es decir, hacer Commit, escribir adecuadamente los nombres de los campos de las tablas, etc. •FormAntecedentes. Para FormAntecedentes debemos declarar todos los campos de las diferentes tablas de antecedentes como son los antecedentes familiares, podológicos, patológicos y fisiológicos. En este caso, cuando hacemos el INSERT INTO a parte de insertar en las cuatro tablas de antecedentes debemos hacer un UPDATE de la tabla HistorialClinico. Hacemos UPDATE porque esa tabla ya se había creado anteriormente en FormPaciente y ahora solamente aprovechamos para añadir las claves ajenas (FK) de los distintos antecedentes. Por otro lado, en el método GuardarEn() hacemos un UPDATE para las tablas de antecedentes y no lo hacemos para la tabla HistorialClinico pues estos valores no se modifican, ya que el número del historial clínico sólo se inserta una vez y no puede ser modificado, y las FK no se modifican. 33 •FormPrimeraVisita. En este Form tenemos información acerca de las tablas PrimeraVisita yCalzadoHabitual. Una peculiaridad es que la tabla PrimeraVisita ya fue creada cuando hicimos FormPaciente. Por ello, se ha decidido no hacer un método InsertarEn() y hacer un GuardarEn() directamente. De modo que hacemos un UPDATE para la tabla PrimeraVisita mientras que para la tabla CalzadoHabitual comprobamos si el calzado es nulo, es decir, no existe. En caso de que no exista hacemos un INSERT de dicha tabla, y en caso de que exista hacemos un UPDATE de dicha tabla. Lo mismo pasaría con el método Rellenar(). Hay que comprobar si la tabla CalzadoHabitual está rellena. En caso de que no sea nulo si que rellenamos los campos con los valores correspondientes. •FormDiagnosticoTratamiento. En este Form abarcamos información de las tablas Diagnostico,Tratamiento y MaterialSoportePlantar. El principal detalle es la forma de hacer las sentencias de INSERT en la base de datos, ya que en MaterialSoportePlantar hay FK de tratamiento y en Diagnostico hay FK de tratamiento también. Por lo que primero insertamos Tratamiento, después hemos decidido insertar MaterialSoportePlantar y, por último, Diagnostico. En el caso del UPDATE no hay problema puesto que no necesitamos modificar las FK. •FormConsulta. Para FormConsulta no hay ninguna peculiaridad, basta con declarar las propiedades y crear los métodos Rellenar(),InsertarEn() yGuardarEn(). Controlador •PagesController. Aquí debemos contemplar tres opciones: registrarse, hacer LogIn y hacer LogOut. En general, cada método tiene dos peticiones, una petición tipo GET y otra petición tipo POST. Con GET lo que hacemos es recuperar información del servidor, en este caso recuperamos los datos de nuestra base de datos. Mientras que con POST lo que hacemos es enviar información desde el lado del cliente para que sea procesada y actualizada o agregada en la base de datos. •PacienteController. En el controlador disponemos de una serie de funciones como son Create yEdit. Como sus nombres indican una es para Crear el nuevo paciente y la otra es para Editar los datos de un paciente creado. 34 –Create ∗GET. Simplemente devolvemos una vista vacía, ya que no hay nada que queramos recuperar de la base de datos, porque lo que pretendemos hacer es insertar un nuevo paciente. ∗POST. Aquí debemos llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes insercciones en la base de datos. –Edit ∗GET. A partir de un identificador de un paciente lo que hacemos es recuperar y rellenar los campos del formulario. Esto se hace mediante el método Rellenar creado en el modelo. ∗POST. En esta petición lo que hacemos es llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes actualizaciones en la base de datos. •AntecedentesController. –Create ∗GET. Devolvemos una vista vacía, ya que no hay nada que queramos recuperar de la base de datos, porque lo que pretendemos hacer es insertar los antecedentes de un paciente. ∗POST. Debemos llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes insercciones en la base de datos (InsertarEn()). –Edit ∗GET. A partir de un identificador de un paciente lo que hacemos es recuperar y rellenar los campos del formulario. Esto se hace mediante el método Rellenar() creado en el modelo. ∗POST. Llamamos al método creado anteriormente en el modelo para así poder hacer las correspondientes actualizaciones en la base de datos (GuardarEn()). •PrimeraVisitaController. –Create ∗GET. Devolvemos una vista vacía, ya que no hay nada que queramos recuperar de la base de datos, porque lo que pretendemos hacer es insertar la primera visita de un paciente. ∗POST. Aquí debemos llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes insercciones en la base de datos. 35 –Edit ∗GET. A partir de un identificador de una visita lo que hacemos es recuperar y rellenar los campos del formulario. Esto se hace mediante el método Rellenar() creado en el modelo. ∗POST. En esta petición lo que hacemos es llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes actualizaciones en la base de datos. •DiagnosticoTratamientoController. –Create ∗GET. En esta petición devolvemos una vista vacía, ya que no hay nada que queramos recuperar de la base de datos, porque lo que pretendemos hacer es insertar el diágnostico y el tratamiento de un paciente. ∗POST. Aquí debemos llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes insercciones en la base de datos. –Edit ∗GET. A partir de un identificador de un diagnóstico lo que hacemos es recuperar y rellenar los campos del formulario. Esto se hace mediante el método Rellenar() creado en el modelo. ∗POST. Llamamos al método creado en el modelo para así poder hacer las correspondientes actualizaciones en la base de datos. •ConsultaController. –Create ∗GET. Devolvemos una vista vacía, ya que no hay nada que queramos recuperar de la base de datos, porque lo que pretendemos hacer es insertar una nueva consulta de un paciente. ∗POST. Llamamos al método creado en el modelo para así poder hacer las correspondientes insercciones en la base de datos. –Edit ∗GET. A partir de un identificador de un paciente lo que hacemos es recuperar y rellenar los campos del formulario. Esto se hace mediante el método Rellenar() creado en el modelo. ∗POST. En esta petición lo que hacemos es llamar al método creado anteriormente en el modelo para así poder hacer las correspondientes actualizaciones en la base de datos. 36 Vista2 Para el diseño de la interfaz la idea era la siguiente: Figura 4. Primera versión del diseño de la aplicación web. La idea era crear pantallas sencillas. De modo que en la primera pantalla se viese el logo y el nombre de la aplicación y estuviera el login. Una vez iniciada la sesión se muestra un menú lateral en el que se pudiera ver la lista de pacientes y en la barra superior tenemos un botón para cerrar la sesión. Si en el menú lateral hacemos click en el Listado de pacientes, se muestra una tabla y podemos añadir/editar la información que deseemos. Para cada modelo y controlador hay diferentes vistas. Al menos una por cada conjunto de peticiones GET/POST. A continuación se va a proceder a mostrar los resultados obtenidos para algunas vistas. En todo momento se ha pretendido que sea una interfaz sencilla y manejable por los usuarios. Para ello, se ha intentado que sea intuitiva y también se ha tenido en cuenta que probablemente se acceda a esta página web mediante un dispositivo móvil, como por ejemplo una tablet, ya que esto permite al podólogo un mayor acercamiento al paciente mientras se realiza la toma de datos. 2Para más detalle de las vistas consultar el Manual de Usuario. 37 •Registrar Vemos una vista en la que se nos pide introducir el nombre de usuario y la contraseña. Sólo el usuario administrador tiene acceso a esta vista, de manera que el administrador es el responsable de registrar a un nuevo usuario en la aplicación. Figura 4.1. Interfaz de Registro de la aplicación. •LogIn / LogOut Si el usuario está debidamente registrado, cuando acceda a la URL de la página web podrá rellenar esta vista tras la inserción de su nombre de usuario y su contraseña. Figura 4.2. Interfaz del Inicio de Sesión. 38 Para cerrar sesión disponemos de un icono accesible desde cualquier punto de la aplicación. Tras pulsarlo volveremos a la vista de iniciar sesión. Figura 4.3. Icono de cerrar sesión. •Paciente. –Create View. Figura 4.4. Interfaz de Añadir los datos de un paciente. Vemos una vista sencilla en la que podemos rellenar los campos de Datos del Paciente yDatos Clínicos. En caso de que no se hayan introducido todos los datos obligatorios, o bien, en el formato adecuado, se muestra un mensaje bajo la caja de texto a la que se esté refiriendo. 39 Figura 4.5. Interfaz de Añadir los datos de un paciente con errores. Cuando todo está correcto y el paciente se ha insertado en la base de datos, volvemos a la tabla principal en la que se muestra la lista de los pacientes. –Edit View. También disponemos de una vista de edición del formulario anteriormente relleno. En caso de error o necesidad de modifcar algunos parámetros podemos ir al botón de Editar y podemos hacer los cambios necesarios. Por lo general, los formularios de edición tienen el mismo formato que el formulario de creación, para que así resulte más fácil a los usuarios de la aplicación. •Listado de Pacientes. Vemos una tabla con todos los pacientes que están registrados en el sistema. Si acabamos de resgitrar a un paciente y queremos añadir los datos, hacemos click sobre las distintas columnas de la tabla para llegar a los distintos cuestionarios y poder completarlos. En caso de querer editar los datos, hacemos el mismo proceso pero pulsando sobre editar. 40 Figura 4.6. Interfaz de la tabla con el listado de los pacientes. •Listado de Consultas. Vemos una tabla con todos las consultas de un paciente concreto. Si queremos editar una visita en concreto pulsamos sobre el botón de Editar Consulta, de manera que nos lleva al formulario de editar la consulta y podemos hacer los cambios pertinentes. Figura 4.7. Interfaz de la tabla con el listado de consultas de un paciente. 41 Figura 8. Interfaz de Añadir la Primera Visita (I). Uno de los detalles de esta vista es que posee un desplegable para poder seleccionar el podólogo que realiza la consulta. En segundo lugar, se pregunta acerca del calzado: Figura 9. Interfaz de Añadir la Primera Visita (II). Una vez rellenos los campos necesarios, pulsamos sobre el botón de Añadir. Si todo esta correcto volveremos a la página de Listado de pacientes. El siguiente paso es crear el diagnóstico y el tratamiento del paciente. Para ello, en su columna pulsamos sobre el botón Añadir. A continuación se nos mostrará la siguiente pantalla: 5 Figura 9. Interfaz de Añadir el Diagnóstico y el Tratamiento. Una vez rellenos los datos pulsamos sobre Añadir y volvemos a la página del Listado de Pacientes. Si por algún motivo nos hemos equivocado escribiendo o se nos ha olvidado algún campo importante, podemos pulsar sobre Editar. Se nos volverá a mostrar el mismo formulario con las respuestas que habíamos puesto y podemos hacer los cambios pertinentes. Figura 10. Interfaz de Editar el Diagnóstico y el Tratamiento. 6 Tras las modificaciones pulsamos Modificar. Para todos los formularios, si no queremos hacer la adicción o la edición podemos pulsar sobre Volver atrás en cualquier momento. Por último, el paciente tendrá visitas posteiores. Para ello en el apartado Consultas disponemos de dos botones. En primer lugar, encontramos el botón de Añadir para añadir una nueva consulta. Figura 11. Interfaz de Añadir una nueva Consulta. En segundo lugar, encontramos el botón de Consultas. Si pulsamos en él nos encontramos con un listado de todas las consultas que ha ido teniendo el paciente. Figura 12. Interfaz del listado de consultas de un paciente. En caso de querer editar algunas de las consultas anteriores bastaría con pulsar sobre el botón de Editar de la consulta que deseemos. 7 ANEXO II Casos de Prueba A continuación se detallan algunas de las funcionalidades de la web mediante los casos de prueba. Título CP01. Acceso a la web. Propósito Comprobar que el sistema realiza el inicio de sesión Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Insertar usuario y contraseña 2. Hacer click en Entrar Redirección a la página principal Redirección a la página principal Título CP02. Registrar un nuevo paciente. Propósito Comprobar que se guarda el nuevo paciente registrado Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Añadir nuevo paciente Redirección al formulario de crear paciente Redirección al formulario de crear paciente 2. El usuario rellena los datos y hace click en Añadir El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes Título CP03. Añadir los Antecedentes del paciente nuevo. Propósito Comprobar que se guardan los antecedentes del nuevo paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Añadir antecedentes Redirección al formulario de crear antecedentes Redirección al formulario de crear antecedentes 2. El usuario rellena los datos y hace click en Añadir El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes 3. El usuario ve en listado de pacientes Editar en la columna Antecedentes El sistema muestra Editar antecedentes porque ya están añadidos El sistema muestra Editar antecedentes porque ya están añadidos 8 Título CP04. Editar la Primera Visita del paciente nuevo. Propósito Comprobar que se guardan los datos de la primera visita del nuevo paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Editar Primera Visita Redirección al formulario de crear primera visita Redirección al formulario de crear primera visita 2. El usuario rellena los datos y hace click en Añadir El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes Título CP05. Añadir el Diagnóstico y Tratamiento del paciente nuevo. Propósito Comprobar que se guarda el Diagnóstico y Tratamiento del nuevo paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Añadir Diágnostico y Tratamiento Redirección al formulario de crear diagnóstico y tratamiento Redirección al formulario de crear diagnóstico y tratamiento 2. El usuario rellena los datos y hace click en Añadir El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes 3. El usuario ve en listado de pacientes Editar en la columna Disgnóstico y Tratamiento El sistema muestra Editar diagnóstico y tratamiento porque ya están añadidos El sistema muestra Editar diagnóstico y tratamiento porque ya están añadidos Título CP06. Añadir una consulta de un paciente. Propósito Comprobar que se guarda la nueva consulta del paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Añadir Consulta Redirección al formulario de crear consulta Redirección al formulario de crear consulta 2. El usuario rellena los datos y hace click en Añadir El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes 9 Título CP07. Consultar el listado de consultas de un paciente. Propósito Comprobar que el sistema muestra correctamente el listado de consultas del paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Consultas Redirección a un listado de conusltas anteriores Redirección a un listado de conusltas anteriores Título CP08. Editar un paciente. Propósito Comprobar que se guarda el paciente cuyos datos han sido modificados Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Editar datos personales Redirección al formulario de editar paciente Redirección al formulario de editar paciente 2. El usuario modifica los datos y hace click en Editar El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes Título CP09. Añadir los Antecedentes del paciente nuevo. Propósito Comprobar que se editan los antecedentes del nuevo paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Editar Antecedentes Redirección al formulario de editar antecedentes Redirección al formulario de editar antecedentes 2. El usuario rellena los datos y hace click en Modificar El sistema guarda los datos en la base de datos y se redirige al listado de pacientes El sistema guarda los datos en la base de datos y se redirige al listado de pacientes 3. El usuario ve en listado de pacientes Editar en la columna Antecedentes El sistema muestra Editar antecedentes porque se pueden volver a editar El sistema muestra Editar antecedentes porque se pueden volver a editar 10 Título CP10. Editar el Diagnóstico y Tratamiento del paciente nuevo. Propósito Comprobar que se guarda el Diagnóstico y Tratamiento del nuevo paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Editar Diágnostico y Tratamiento Redirección al formulario de editar diagnóstico y tratamiento Redirección al formulario de editar diagnóstico y tratamiento 2. El usuario modifica los datos y hace click en Editar El sistema actualiza los datos en la base de datos y se redirige al listado de pacientes El sistema actualiza los datos en la base de datos y se redirige al listado de pacientes 3. El usuario ve en listado de pacientes Editar en la columna Disgnóstico y Tratamiento El sistema muestra Editar diagnóstico y tratamiento porque se pueden volver a editar El sistema muestra Editar diagnóstico y tratamiento porque se pueden volver a editar Título CP11. Editar la consulta de un paciente. Propósito Comprobar que se puede editar las consultas de un paciente Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click en Consultas Redirección a un listado de conusltas anteriores Redirección a un listado de conusltas anteriores 2. Hacer click en Editar de la consulta deseada Redirección al formulario de edición de dicha consulta Redirección al formulario de edición de dicha consulta 3. El usuario modifica los campos necesarios y hace click en Modificar El sistema actualiza los datos en la base de datos y se redirige al listado de pacientes El sistema actualiza los datos en la base de datos y se redirige al listado de pacientes Título CP12. Desconectarse de la web. Propósito Comprobar que el sistema realiza el cierre de sesión Autor Maria José Muñoz González Pasos Resultados Esperados Resultados Reales 1. Hacer click sobre el icono de cerrar sesión El sistema nos redirije a la pantalla de inicio de sesión El sistema nos redirije a la pantalla de inicio de sesión 11