adpas. adaptable domestic patient assistance system. sistema adaptable de asistencia domiciliaria al...
TRANSCRIPT
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA
INGENIERÍA EN INFORMÁTICA
PROYECTO FIN DE CARRERA
ADPAS (Adaptable Domestic Patient Assistance System): Sistema Adaptable de Asistencia Domiciliaria
al Paciente
Alejandro Alberca Manzaneque
Septiembre, 2012
UNIVERSIDAD DE CASTILLA-LA MANCHA ESCUELA SUPERIOR DE INFORMÁTICA
Departamento de Informática
PROYECTO FIN DE CARRERA
ADPAS (Adaptable Domestic Patient Assistance System): Sistema Adaptable de Asistencia Domiciliaria
al Paciente
Autor: Alejandro Alberca Manzaneque Director: Ramón Hervás Lucas
Septiembre, 2012
v
TRIBUNAL Presidente: Vocal: Secretario: FECHA DE DEFENSA: CALIFICACIÓN: PRESIDENTE VOCAL SECRETARIO Fdo.: Fdo.: Fdo.:
vii
RESUMEN
En el contexto sanitario actual caracterizado por las restricciones
presupuestarias y el déficit de profesionales, la telemedicina podría ser una
opción. La mayor parte del coste sanitario se produce debido a las enfermedades
crónicas. Dos modos de mitigar los efectos negativos de las enfermedades
crónicas son las iniciativas de autocuidado de pacientes y los sistemas de
telemonitorización de pacientes. Las iniciativas de autocuidado mejoran la
calidad de vida de los pacientes y los sistemas de telemonitorización de pacientes
pueden reducir costes al sistema sanitario debido a que evitan las visitas rutinarias
al médico.
El presente proyecto tiene como objetivo el desarrollo de un sistema de
telemonitorización y autocuidado domiciliario de pacientes que permitirá a los
médicos el seguimiento del estado de salud del paciente así como dará soporte a
los pacientes en la toma de decisiones que afecten a su estado de salud.
ABSTRACT
Telemedicine may be an option to face present health context characterised
by budgetary constraints and the scarcity of medical professionals. Most health
care bucket is spent on patients with chronic diseases. There are several ways to
mitigate the negative effects of chronic diseases. Two of them are self-
management initiatives and patient-monitoring systems. Self-management
initivatives improve the living conditions of patients whereas self-monitoring
systems can reduce health care costs by avoiding regular visits to the doctor.
Present work aims to develop an in-home self-management patient-
monitoring system which will allow doctors to monitor the patient health status
and will provide support to patients on their decision-making which affects their
health conditions.
ix
DEDICATORIA
A mi familia, por estar siempre ahí.
A los amigos, por hacer la vida más llevadera.
A Ramón y Vladimir por su apoyo, consejo y guía en la elaboración de este
proyecto.
Muchas gracias a todos.
xi
ÍNDICE
1 INTRODUCCION .................................................................................................... 1 1.1 Introducción al tema .......................................................................................... 3 1.2 Propuesta............................................................................................................ 5 1.3 Ciclo de vida del sistema ADPAS ..................................................................... 7 1.4 Estructura del documento .................................................................................. 9
2 OBJETIVOS............................................................................................................ 11
2.1 Objetivos generales.......................................................................................... 13 2.2 Objetivos específicos ....................................................................................... 13 2.3 Limitaciones y consideraciones ....................................................................... 16 2.4 Marco tecnológico de trabajo .......................................................................... 17
3 ESTADO DEL ARTE............................................................................................. 19
3.1 Telemedicina.................................................................................................... 21 3.1.1 Concepto ................................................................................................. 21 3.1.2 Clasificación de los sistemas de telemedicina ........................................ 22 3.1.3 Telemonitorización ................................................................................. 23
3.2 Trabajos relacionados ...................................................................................... 23 3.2.1 Puntos fuertes de los trabajos presentados con respecto al presente ...... 26 3.2.2 Puntos fuertes del presente trabajo con respecto a los trabajos presentados....................................................................................................... 27
3.3 Enfermedades crónicas .................................................................................... 28 3.3.1 Introducción ............................................................................................ 28 3.3.2 Características comunes.......................................................................... 29 3.3.3 Ejemplos de enfermedades crónicas ....................................................... 29 3.3.4 Modelos de gestión de pacientes crónicos.............................................. 30
3.4 Sistemas de clasificación usados en el proyecto.............................................. 41 3.4.1 Sistema de clasificación de enfermedades ICD-10................................. 41 3.4.2 Sistema de clasificación de fármacos ATC ............................................ 42 3.4.3 Sistema de clasificación de alimentos DAFNE ...................................... 44
3.5 Android ............................................................................................................ 45 3.5.1 Introducción ............................................................................................ 45 3.5.2 Arquitectura ............................................................................................ 46
3.6 Tecnologías usadas en el desarrollo de la aplicación web............................... 47 3.6.1 Java EE ................................................................................................... 47 3.6.2 Struts ....................................................................................................... 49 3.6.3 Maven ..................................................................................................... 51 3.6.4 Pool de conexiones C3P0 ....................................................................... 52 3.6.5 DisplayTag.............................................................................................. 53 3.6.6 JFreeChart............................................................................................... 54
3.7 Tecnologías usadas en el servicio web ............................................................ 55 3.7.1 Servicios web.......................................................................................... 55 3.7.2 Jersey ...................................................................................................... 56 3.7.3 Simple XML Serialization Framework................................................... 56
3.8 Bluetooth.......................................................................................................... 57 3.8.1 Perfiles Bluetooth ................................................................................... 58 3.8.2 Protocolo de Descubrimiento de Servicios............................................. 58
xii
3.8.3 Dirección MAC de un dispositivo Bluetooth..........................................58 4 METODO DE TRABAJO......................................................................................59
4.1 Proceso Unificado de Desarrollo......................................................................61 4.1.1 Características del PUD ..........................................................................61 4.1.2 Estructura del PUD..................................................................................62
4.2 Patrones de diseño............................................................................................64 4.2.1 Patrones utilizados...................................................................................64
5 RESULTADOS........................................................................................................67
5.1 Requisitos .........................................................................................................69 5.1.1 Especificación de requisitos ....................................................................69 5.1.2 Casos de uso ............................................................................................72 5.1.3 Diagramas de Casos de Uso ....................................................................75
5.2 Análisis.............................................................................................................77 5.2.1 Priorización de los casos de uso..............................................................77 5.2.2 Descripción de los casos de uso más representativos .............................81 5.2.3 Escenarios. Diagramas de secuencia más representativos ......................94
5.3 Diseño.............................................................................................................105 5.3.1 Decisiones tomadas de diseño...............................................................105 5.3.2 Componentes del sistema ......................................................................105 5.3.3 Modelo de datos ....................................................................................107 5.3.4 Diagramas de clase................................................................................112
5.4 Implementación..............................................................................................126 5.4.1 Aplicación web......................................................................................126 5.4.2 Servicio web..........................................................................................133 5.4.3 Aplicación móvil ...................................................................................135
5.5 Pruebas ...........................................................................................................146 5.5.1 Pruebas unitarias ...................................................................................146 5.5.2 Encuesta de usabilidad ..........................................................................151
5.6 Despliegue......................................................................................................153 6 CONCLUSIONES Y PROPUESTAS..................................................................157
6.1 Conclusiones ..................................................................................................159 6.2 Propuestas.......................................................................................................161
REFERENCIAS ..........................................................................................................163 Anexo A. Abreviaturas y Acrónimos.........................................................................171 Anexo B. Descripción de los casos de uso..................................................................175
Descripción de los casos de uso de la aplicación móvil..........................................177 Descripción de los casos de uso de la aplicación web ............................................192 Descripción de los casos de uso del servicio web...................................................199
Anexo C. Manual de Usuario de la aplicación web..................................................203
Autenticación de usuario.........................................................................................205 Menú lateral izquierdo ............................................................................................205 Nuevo paciente........................................................................................................206 Seleccionar paciente................................................................................................208
xiii
Actualizar datos paciente ........................................................................................ 209 Enfermedades paciente ........................................................................................... 209 Ver actividad del paciente....................................................................................... 212
Anexo D. Manual de Usuario de la aplicación móvil............................................... 215
Campos comunes .................................................................................................... 217 Campos de texto autocompletado .................................................................. 217 Campos de fecha............................................................................................ 218 Campos de hora ............................................................................................. 219 Campos de barra de desplazamiento.............................................................. 220
Ventanas de recomendaciones ................................................................................ 220 Apartados de la aplicación...................................................................................... 221
Menú principal ............................................................................................... 221 Medición ........................................................................................................ 223 Alimentación.................................................................................................. 225 Actividades .................................................................................................... 227 Medicamentos................................................................................................ 228 Síntomas......................................................................................................... 229 Sincronizar ..................................................................................................... 230 Histórico......................................................................................................... 231
Anexo E. Configuración previa de la aplicación móvil ........................................... 233
Carga inicial de datos.............................................................................................. 235 Obtener datos del paciente...................................................................................... 237
xv
ÍNDICE DE FIGURAS Figura 1. Previsión de la evolución de la diabetes a nivel mundial. Porcentaje de
población afectada por la diabetes entre 20 y 79 años.............................................. 4
Figura 2. Esquema del sistema ADPAS ........................................................................... 5
Figura 3. Esquema del sistema de monitorización de pacientes expuesto en (Logan, A.
et al., 2007) ............................................................................................................. 24
Figura 4. Arquitectura del sistema SPA.......................................................................... 25
Figura 5. Esquema del sistema de telemonitorización de pacientes propuesto en
(Belgacem, N. et al., 2011) ..................................................................................... 26
Figura 6. Modelo CCM (Chronic Care Model) .............................................................. 31
Figura 7. Esquema del marco ICCC ............................................................................... 33
Figura 8. Niveles de un sistema sanitario global según ICCC........................................ 34
Figura 9. Esquema y elementos del marco ICCC........................................................... 39
Figura 10. Pirámide de Kaiser ........................................................................................ 40
Figura 11. Arquitectura de Android................................................................................ 46
Figura 12. Patrón MVC en una aplicación Java EE. ...................................................... 49
Figura 13. Ejemplos de tablas formadas por la librería DisplayTag .............................. 54
Figura 14. Gráfico de ejemplo de JFreeChart................................................................. 55
Figura 15. Estructura del PUD........................................................................................ 63
Figura 16. Pasos del MVC.............................................................................................. 65
Figura 17. Diagrama de casos de uso de la aplicación móvil ......................................... 76
Figura 18. Diagrama de casos de uso de la aplicación web............................................ 77
Figura 19. Diagrama de casos de uso del servicio web .................................................. 77
Figura 20. Diagrama de secuencia de análisis de la introducción de una medición....... 95
Figura 21. Diagrama de secuencia de análisis de la introducción de un medicamento.. 97
Figura 22. Diagrama de secuencia de análisis de la sincronización de datos ............... 100
Figura 23. Diagrama de secuencia de análisis de selección de un paciente ................. 102
Figura 24. Diagrama de secuencia de análisis de la obtención de la información de
seguimiento de un paciente................................................................................... 104
Figura 25. Diagrama de componentes del sistema ....................................................... 106
Figura 26. Tablas de pacientes y médicos .................................................................... 108
Figura 27. Tablas de catálogos ..................................................................................... 109
Figura 28. Tablas de mediciones de los pacientes ........................................................ 110
xvi
Figura 29. Tablas de datos de seguimiento de los pacientes.........................................111
Figura 30. Tablas de recomendaciones asociadas a las mediciones .............................111
Figura 31. Tablas de recomendaciones asociadas a los datos de seguimiento de los
pacientes ................................................................................................................112
Figura 32. Simplificación del diagrama de clases del modelo......................................113
Figura 33. Simplificación del diagrama de clases de las clases DAO de adpas_db .....114
Figura 34. Simplificación del diagrama de clases de las clases DAO del módulo
adpas_droid ...........................................................................................................115
Figura 35. Diagrama de clases del framework de sensores...........................................117
Figura 36. Diagrama de clases del framework de sensores con las clases usadas por el
tensiómetro IEM Stabil-O-Graph..........................................................................118
Figura 37. Diagrama de clases del caso de uso CU-05 Obtener medición manualmente
...............................................................................................................................119
Figura 38. Diagrama de clases del caso de uso CU-08 Introducir medicación.............120
Figura 39. Diagrama de clases del caso de uso CU-10 Sincronizar información con el
servidor remoto .....................................................................................................121
Figura 40. Diagrama de clases del caso de uso CU-22 Registrar nuevo paciente ........123
Figura 41. Diagrama de clases del caso de uso CU-23 Seleccionar paciente ...............124
Figura 42. Diagrama de clases del caso de uso CU-25 Ver información de seguimiento
del paciente............................................................................................................125
Figura 43. Pantalla de acotación del caso de uso CU-25 Ver información del paciente
...............................................................................................................................126
Figura 44. Pantalla de visualización de los datos de seguimiento del caso de uso CU-25
Ver información de seguimiento del paciente.......................................................127
Figura 45. Pantalla del apartado de 'Medicamentos' de la aplicación móvil.................136
Figura 46. Pantalla de medición mediante sensor de la aplicación móvil.....................139
Figura 47. Pantalla del apartado de 'Sincronizar' de la aplicación móvil......................143
Figura 48. Resultado de las pruebas unitarias del módulo adpas_db............................147
Figura 49. Resultado de las pruebas unitarias del módulo adpas_ws ...........................147
Figura 50. Resultado de las pruebas unitarias del módulo adpas_web .........................148
Figura 51. Resultado de las pruebas unitarias del módulo adpas_droid .......................148
Figura 52. Informe de cobertura global del módulo adpas_db .....................................149
Figura 53. Detalle de la cobertura del paquete de clases DAO del módulo adpas_db..149
xvii
Figura 54. Detalle de cobertura de un método de la clase FoodDafneClass del módulo
adpas_db ............................................................................................................... 150
Figura 55. Informe de cobertura global del módulo adpas_ws..................................... 150
Figura 56. Informe de cobertura global del módulo adpas_web .................................. 151
Figura 57. Gráfico del resultado de la encuesta de usabilidad por agrupación de
características de usabilidad.................................................................................. 153
Figura 58. Diagrama de despliegue del sistema ........................................................... 155
Figura 59. Pantalla de autenticación de usuario ........................................................... 205
Figura 60. Menú lateral izquierdo de la aplicación web............................................... 206
Figura 61. Pantalla del apartado de Nuevo Paciente .................................................... 207
Figura 62. Ejemplos de mensajes de validación en los apartados de datos del paciente
.............................................................................................................................. 207
Figura 63. Pantalla del apartado de Seleccionar Paciente ............................................ 208
Figura 64. Pantalla del apartado de Actualizar datos de paciente ................................ 209
Figura 65. Pantalla del apartado de Enfermedades del paciente................................... 210
Figura 66. Pantalla del asistente de selección de enfermedades................................... 211
Figura 67. Selección de una enfermedad en el apartado de Enfermedades del paciente
.............................................................................................................................. 212
Figura 68. Pantalla del apartado de Ver la actividad del paciente ................................ 212
Figura 69. Pantalla de visualización de la información de seguimiento en un día
determinado .......................................................................................................... 213
Figura 70. Pantalla de visualización del gráfico del tipo de medición seleccionado
durante la semana.................................................................................................. 214
Figura 71. Ejemplo de campo de texto autocompletado con listado desplegable de
valores................................................................................................................... 217
Figura 72. Ejemplo de validación de campo de texto autocompletado ........................ 218
Figura 73. Imagen del calendario de los campos de fecha ........................................... 218
Figura 74. Asistente para especificar fechas................................................................. 218
Figura 75. Mensaje de validación en caso de fecha vacía o inválida ........................... 219
Figura 76. Imagen del reloj de pared asociada a los campos de hora........................... 219
Figura 77. Asistente pare especificar la hora................................................................ 219
Figura 78. Mensaje de validación en caso de hora vacía o inválida............................. 219
Figura 79. Campo de barra de desplazamiento con valor asociado a la derecha.......... 220
xviii
Figura 80. Pantalla de ejemplo de recomendaciones (Paciente con insuficiencia renal y
habiendo tomado cerveza).....................................................................................221
Figura 81. Pantalla de confirmación después de mostrarse la ventana de
recomendaciones ...................................................................................................221
Figura 82. Menú principal de la aplicación móvil ........................................................222
Figura 83. Pantalla de selección del tipo de medición ..................................................223
Figura 84. Pantalla de introducción manual de presión arterial ....................................224
Figura 85. Pantalla de medición mediante sensor .........................................................225
Figura 86. Mensaje de espera de la medición del sensor ..............................................225
Figura 87. Mensaje de medición recibida desde el sensor ............................................225
Figura 88. Pantalla de introducción de alimentos .........................................................226
Figura 89. Mensaje de introducción del alimento con éxito .........................................226
Figura 90. Pantalla de introducción de actividades.......................................................227
Figura 91. Mensaje de introducción de la actividad con éxito......................................227
Figura 92. Pantalla de introducción de medicación ......................................................228
Figura 93. Mensaje de introducción del medicamento con éxito..................................229
Figura 94. Pantalla de introducción de síntomas...........................................................229
Figura 95. Mensaje de introducción del síntoma con éxito...........................................230
Figura 96. Pantalla de sincronización de datos .............................................................231
Figura 97. Mensaje de espera al sincronizar los datos ..................................................231
Figura 98. Mensaje de sincronización llevada con éxito ..............................................231
Figura 99. Pantalla de histórico de datos de seguimiento .............................................232
Figura 100. Pantalla inicial de la aplicación móvil recién instalada .............................235
Figura 101. Pantalla del apartado de la carga inicial de datos de la aplicación móvil ..236
Figura 102. Mensaje del proceso de carga inicial de datos en la aplicación móvil ......236
Figura 103. Pantalla de la carga de datos inicial una vez ha concluido con éxito ........237
Figura 104. Pantalla del menú de configuración previa de la aplicación móvil una vez se
han cargado los datos iniciales ..............................................................................237
Figura 105. Pantalla de la asignación del paciente a la aplicación móvil .....................238
Figura 106. Pantalla con pacientes asociados a un médico en la aplicación web .........238
Figura 107. Mensaje de búsqueda del paciente especificado en el apartado de asignación
del paciente a la aplicación móvil .........................................................................238
Figura 108. Mensaje de confirmación de paciente especificado en el apartado de
asignación de paciente a la aplicación móvil ........................................................239
xix
Figura 109. Asignación del paciente a la aplicación móvil confirmada y concluida ... 239
Figura 110. Menú de la configuración previa de la aplicación una vez ha concluido.. 239
xxi
ÍNDICE DE TABLAS Tabla 1. Clasificación de los sistemas de telemedicina según (Vicent et al., 2007)....... 22
Tabla 2. Componentes del modelo CCM........................................................................ 32
Tabla 3. Problemas identificados por el marco ICCC en la mayoría de los sistemas
sanitarios clasificados por sus niveles estratificados .............................................. 37
Tabla 4. Elementos del marco ICCC .............................................................................. 38
Tabla 5. Clases de enfermedades en ICD-10.................................................................. 42
Tabla 6. Ejemplos de enfermedades crónicas clasificadas por el estándar ICD-10 ....... 42
Tabla 7. Desglose de los campos del código ATC de la aspirina (B01AC06) ............... 44
Tabla 8. Sistema de clasificación de alimentos DAFNE ................................................ 45
Tabla 9. Propiedades de configuración del Pool de Conexiones C3P0 .......................... 53
Tabla 10. Anotaciones usadas por Jersey ....................................................................... 56
Tabla 11. Anotaciones usadas en Simple XML.............................................................. 57
Tabla 12. Requisitos funcionales de la aplicación móvil................................................ 70
Tabla 13. Requisitos funcionales de la aplicación web .................................................. 71
Tabla 14. Requisitos funcionales del servicio web......................................................... 71
Tabla 15. Casos de uso de la aplicación móvil ............................................................... 73
Tabla 16. Casos de uso de la aplicación web.................................................................. 74
Tabla 17. Casos de uso del servicio web ........................................................................ 75
Tabla 18. Priorización de los casos de uso ..................................................................... 78
Tabla 19. Componentes del sistema desarrollado......................................................... 106
Tabla 20. Agrupaciones de tablas del modelo de datos del sistema ............................. 108
Tabla 21. Tablas de pacientes y médicos...................................................................... 108
Tabla 22. Tablas de catálogos....................................................................................... 109
Tabla 23. Tablas de mediciones de los pacientes ......................................................... 110
Tabla 24. Tablas de datos de seguimiento de los pacientes.......................................... 110
Tabla 25. Tablas de recomendaciones asociadas a las mediciones .............................. 111
Tabla 26. Tablas de recomendaciones asociadas a los datos de seguimiento de los
pacientes................................................................................................................ 112
Tabla 27. Encuesta de usabilidad realizada .................................................................. 151
Tabla 28. Resultados de la encuesta de usabilidad ....................................................... 152
Tabla 29. Objetivos propuestos .................................................................................... 160
xxiii
ÍNDICE DE FRAGMENTOS DE CÓDIGO Fragmento de código 1. Métodos para obtener la información de seguimiento del
paciente de la clase ShowPatientTrackingDataAction ......................................... 130
Fragmento de código 2. Método selectTrackingData de la clase PatientFoodDAO .... 131
Fragmento de código 3. Método obtainChart de la clase
ShowPatientBloodPressureAction para generar la gráfica de las mediciones de la
tensión arterial....................................................................................................... 132
Fragmento de código 4. Fragmento de la clase
ReceiveApplicationDataForAddingResource del módulo adpas_ws ................... 134
Fragmento de código 5. Método retrieveSensorsToAdd de la clase SensorDAO........ 135
Fragmento de código 6. Método acceptMedicine de la clase AddMedicineActivity ... 137
Fragmento de código 7. Método obtainSuggestionMessages de la clase MedicineHelper
.............................................................................................................................. 138
Fragmento de código 8. Método isConditionSatisfied de la clase MessageConditionsUtil
.............................................................................................................................. 139
Fragmento de código 9. Método startReadingFromSensor de la clase
ReadFromSensorActivity...................................................................................... 141
Fragmento de código 10. Método obtainMeasurements de la clase
IemTensiometerSensor ......................................................................................... 141
Fragmento de código 11. Constructor y método run de la clase
DefaultServerSensorThread.................................................................................. 143
Fragmento de código 12. Método synchronizeData de la clase SendDataActivity...... 145
Fragmento de código 13. Métodos receivePatientProfile y
receiveApplicationDataForAdding de la clase AdpasWebService ...................... 146
xxiv
1 INTRODUCCION
1. Introducción
3
1.1 Introducción al tema
La mayoría de los sistemas sanitarios actuales están principalmente orientados a
curar enfermedades agudas (WHO, 2002). Particularmente, uno de los mayores desafíos
a los que se enfrentan los sistemas sanitarios actuales son las enfermedades crónicas
(Singh, 2008).
Actualmente, las enfermedades crónicas afectan a más población que las
enfermedades infecciosas y son la principal causa de muerte en Europa (WHO, 2005) y
en Estados Unidos (Hoffman, 2008). Se estima que en el mundo, la proporción de
muertes debido a enfermedades crónicas aumente del 59% en el 2002 al 69% en 2030
(Mathers, 2005). En términos económicos, las enfermedades crónicas consumen del 50
al 80% del gasto sanitario global (Singh, 2008).
Otro factor agravante de las enfermedades crónicas es su prevalencia, es decir, la
proporción de personas de una población que tienen enfermedades crónicas en un
periodo determinado. Gracias a los avances en medicina ha aumentado
considerablemente la esperanza de vida. La edad junto con otras causas como la mala
alimentación, la falta de actividad física, el estrés y el consumo de tabaco y alcohol
favorecen la aparición de enfermedades crónicas. Esto conlleva que las enfermedades
crónicas estén cada vez más extendidas (WHO, 2002), es decir, el porcentaje de
población mundial con enfermedades crónicas va en aumento. Un ejemplo de esto se
puede apreciar en la Figura 1 (IDF, 2007 referenciada en Osakidetza, 2010). En ella se
muestra el porcentaje de población mundial afectada por la diabetes en el año 2007 y la
previsión de la evolución de la enfermedad para el año 2025.
1. Introducción
4
Figura 1. Previsión de la evolución de la diabetes a nivel mundial. Porcentaje de población
afectada por la diabetes entre 20 y 79 años
Debido a todo lo anteriormente expuesto, si no se gestionan adecuadamente las
enfermedades crónicas, los problemas actuales se agravarán en el futuro.
Existen varios modelos de gestión de enfermos crónicos, algunos de los cuales
se expondrán en el apartado del Estado del Arte. Los más famosos son:
• “Modelo de Atención a Crónicos” The Chronic Care Model (CCM).
Desarrollado por Ed Wagner y por colaboradores del MacColl Institute
for Healthcare Innovation de Seattle, en EE.UU.
• “Modelo de Atención Innovador para Condiciones Crónicas” The
Innovative Care for Chronic Conditions Framework (ICCC). Es una
adaptación del CCM propuesta por la Organización Mundial de la Salud
(OMS).
• “Pirámide de Kaiser” Kaiser Pyramid. Desarrollada por el consorcio
sanitario Kaiser Permanente1 en Estados Unidos.
Una característica común de la mayoría de los modelos de gestión de enfermos
crónicos es que promueven el autocuidado del paciente en su domicilio. Estas
iniciativas mejoran la calidad de vida de los pacientes (Ghosh et al., 1998; Taitel et al.,
1 Kaiser Permanente. https://www.kaiserpermanente.org
1. Introducción
5
1995; Lorig et al., 1993; Lorig et al., 1999). Los enfermos y sus cuidadores (familia y/o
asistentes sociales) toman un rol activo en el tratamiento de la enfermedad frente al rol
pasivo tradicional debido a que la gestión de ésta se hará principalmente desde el
domicilio del enfermo crónico. Se les proporcionan medios para:
• Formarse sobre la enfermedad, sus síntomas, conocer su estado de salud
y las acciones que han de tomarse según las circunstancias.
• Adecuar su estilo de vida y sus costumbres para mejorar su calidad de
vida con respecto a la enfermedad crónica.
Entre estos medios también se consideran el equipamiento médico (jeringuillas,
botiquines, etc.), la medicación y los sensores biométricos para conocer sus parámetros
vitales (glucómetros, tensiómetros, oxímetros, etc.).
1.2 Propuesta
El sistema que se pretende desarrollar en este proyecto permitirá, por un lado, al
enfermo crónico gestionar su enfermedad desde una aplicación móvil en su domicilio, y
por otro, permitirá a su médico ver la progresión de sus enfermos asignados desde una
aplicación web situada en su centro de trabajo.
Figura 2. Esquema del sistema ADPAS
El paciente podrá introducir mediciones de parámetros vitales (tensión arterial,
temperatura y glucosa en sangre) en el dispositivo móvil. Las mediciones podrán
introducirse de dos formas: de forma manual o mediante sensor. La forma manual
1. Introducción
6
implica que el paciente ha de introducir los valores de las mediciones manualmente en
el dispositivo móvil. La forma mediante sensor consiste en el sensor envía directamente
al dispositivo móvil el resultado de la medición que ha realizado el paciente mediante
comunicación Bluetooth.
El paciente podrá también introducir en el dispositivo móvil datos que puedan
ser significativos para evaluar su estado de salud y la evolución de sus enfermedades.
Entre estos datos se incluyen: alimentación, medicación, síntomas experimentados y
acciones cotidianas comunes (andar, correr, ver la tele, nadar, etc.).
El dispositivo móvil mostrará recomendaciones al paciente cuando éste
introduzca datos en él. Estas recomendaciones guiarán al paciente sobre la idoneidad de
la acción que va a realizar (medicación, alimentación, etc.) basándose en su estado de
salud (mediciones introducidas) y en los datos que hubiera introducido anteriormente
(alimentación, medicación, síntomas experimentados y acciones cotidianas comunes).
Es decir, el dispositivo móvil asistirá al paciente en las decisiones que vaya a tomar.
El dispositivo móvil enviará los datos introducidos por el paciente a un servidor
y se almacenarán en una base de datos.
El servidor enviará al dispositivo móvil los datos que hayan sido actualizados en
la base de datos de forma que los datos internos que use el dispositivo móvil
(medicamentos, alimentos, síntomas, etc.) estén sincronizados con la base de datos que
usa el servidor.
El médico desde un PC de su centro de trabajo podrá consultar los valores de las
mediciones así como el resto de datos que hubieran sido introducidos por sus pacientes.
De forma que podrá evaluar la evolución de sus enfermedades y establecer
correspondencias entre las acciones introducidas por los pacientes y los resultados de
sus mediciones.
1. Introducción
7
1.3 Ciclo de vida del sistema ADPAS
Se exponen en este apartado los pasos que se podrían producir desde que un
paciente acude a la consulta de atención primaria y se da de alta en el sistema ADPAS,
hasta que el paciente se da de baja en el sistema.
1. El paciente acudiría al centro de atención primaria y el médico le
diagnosticaría una enfermedad crónica.
2. El paciente encajaría en el perfil para recibir asistencia domiciliaria. Es
decir, el paciente tendría enfermedades de poco riesgo para su salud o
con posibilidad de riesgo para salud pero sin estar tan desarrolladas como
para representar riesgos. El paciente tampoco necesitaría de
intervenciones específicas que tuvieran que darse en un hospital.
3. El médico daría de alta al paciente en el sistema introduciendo sus datos
personales, de contacto y los referentes a su estado de salud. Estos datos
podrán ser modificados por el médico según las circunstancias de salud
del paciente (se le diagnostican nuevas enfermedades o se cura de
alguna), o bien por petición expresa del paciente (por ejemplo, si el
paciente cambia de domicilio o de teléfono). El paciente y el médico
podrían siempre estar en contacto mediante llamadas telefónicas, correo
electrónico, etc. sin necesidad de que el paciente acuda al centro de
atención primaria.
4. Al paciente se le entregarían los siguientes medios para tratar su
enfermedad desde su domicilio:
a. Un dispositivo móvil. Este dispositivo móvil se usaría para que
el paciente introduzca los datos de mediciones biométricas y los
referentes a acciones o eventos significativos en su estado de
salud que realiza u ocurren en su día a día (alimentación,
medicación, síntomas experimentados y acciones cotidianas).
Estos datos podrán ser consultados y evaluados posteriormente
1. Introducción
8
por su médico. El dispositivo móvil se entregaría configurado y
preparado para su uso. El paciente no tendría que introducir datos
personales ninguno en el dispositivo móvil. Cada dispositivo
móvil estaría asociado a un único paciente.
b. Sensores biométricos. Los sensores biométricos se usarían para
que el paciente pueda conocer sus parámetros vitales. Estos
sensores biométricos podrán enviar sus mediciones al dispositivo
móvil mediante comunicación Bluetooth.
c. Medicación. Al paciente se le suministrarían los medicamentos
correspondientes a su enfermedad.
d. Equipamiento médico específico para la enfermedad. Como
ejemplos de equipamiento médico se podrían considerar
botiquines, vendas, jeringuillas (para diabéticos por ejemplo), etc.
e. Guías informativas de cómo tratar la enfermedad que le ha
sido diagnosticada y cómo adecuar su estilo de vida a ella. Uno
de los objetivos de las iniciativas de autocuidado consiste en que
el paciente tome un rol activo en el tratamiento de su enfermedad
de forma que tenga el conocimiento necesario como para hacerse
responsable de su estado de salud. Esto consiste en que el
paciente ha de conocer aquellos hábitos de vida saludables que le
ayuden a mitigar los efectos negativos de su enfermedad así como
aquellos que empeoran su estado de salud.
5. El paciente realizaría su vida cotidiana en su domicilio. Éste realizaría
mediciones biométricas cada cierto tiempo y especificaría aquellas
acciones y datos que considerase significativos en su estado de salud
(alimentación, medicación tomada, síntomas experimentados y acciones
cotidianas comunes). Esto le serviría por un lado para recibir
recomendaciones al introducir estos datos; y por otro, para darle
información a su médico en el seguimiento de su enfermedad y en la
asociación de estos datos a los cambios que se produzcan en su estado de
salud.
1. Introducción
9
6. Si el médico mediante la información proporcionada por el paciente
detectase que alguno de sus hábitos empeora su estado de salud podría
comunicárselo por teléfono para que el paciente evite dicho hábito.
7. Si el paciente tuviera condiciones especiales que impidieran el
tratamiento de su enfermedad en su domicilio entonces se podría dar de
baja el paciente en el sistema.
1.4 Estructura del documento
El presente documento se encuentra organizado en los siguientes apartados:
Capítulo 1. Introducción. Es el presente capítulo.
Capítulo 2. Objetivos. En este capítulo se exponen los objetivos que se
pretenden conseguir y las limitaciones que podrían tener las aplicaciones
desarrolladas.
Capítulo 3. Estado del Arte. En este tercer capítulo se presenta lo que es la
telemedicina, la telemonitorización, la problemática de la gestión de los
pacientes crónicos y una breve introducción a las tecnologías usadas en el
desarrollo de las aplicaciones del proyecto.
Capítulo 4. Método de trabajo. En este capítulo se presenta la metodología
de desarrollo utilizada en el proyecto.
Capítulo 5. Resultados. En el quinto capítulo se presenta cómo se han
realizado los desarrollos aplicando lo especificado en el capítulo anterior.
Capítulo 6. Conclusiones y Propuestas. En el sexto capítulo se presentan las
conclusiones obtenidas de los desarrollos así como posibles propuestas y
futuras mejoras que podrían aplicarse sobre las aplicaciones del sistema
desarrollado.
Referencias. En este apartado se proporciona un listado con las referencias
expuestas en la memoria del proyecto. Anexo A. Abreviaturas y Acrónimos
Anexo B. Descripción de los casos de uso
Anexo C. Manual de Usuario de la aplicación web
Anexo D. Manual de Usuario de la aplicación móvil
Anexo E. Configuración previa de la aplicación móvil
1. Introducción
10
2 OBJETIVOS
2. Objetivos
13
2.1 Objetivos generales
El principal objetivo del proyecto es desarrollar un sistema que conecte
dispositivos móviles y dispositivos biométricos mediante Bluetooth y que permita
la monitorización y el seguimiento de la salud de un paciente.
El sistema consistirá en tres aplicaciones: una aplicación móvil, una aplicación
web y un servicio web que realizará la función de interlocutor entre la aplicación móvil
y la base de datos del sistema.
El paciente desde su domicilio en la aplicación móvil introducirá datos
significativos de su estado salud (parámetros vitales, actividad, síntomas, alimentación y
medicación) y ésta mostrará recomendaciones según su estado de salud y lo que hubiera
introducido anteriormente. El dispositivo móvil recibirá los parámetros vitales del
paciente mediante introducción manual o desde un sensor biométrico mediante
comunicación Bluetooth.
Todo lo introducido en la aplicación móvil podrá ser enviado al servicio web
para que lo almacene en la base de datos del sistema. El servicio web también mandará
a la aplicación móvil aquellos datos que hayan sido actualizados en la base de datos de
forma que los datos internos de la aplicación móvil se encuentren sincronizados con los
de la base de datos del sistema.
El médico mediante la aplicación web podrá consultar los datos enviados por el
paciente para ver su progresión desde un PC situado en su centro de trabajo.
2.2 Objetivos específicos
Se enuncian a continuación los objetivos específicos que se tendrán en cuenta en
el desarrollo del sistema:
• OE1: Desarrollar una aplicación móvil para el sistema operativo Android
que será usada por pacientes.
2. Objetivos
14
• OE2: Desarrollar una aplicación web mediante la arquitectura Java EE
que será usada por médicos.
• OE3: Leer las señales vitales de un dispositivo biométrico mediante
Bluetooth desde la aplicación móvil. Se usará el tensiómetro IEM Stabil-
O-Graph1.
• OE4: Implementar un sistema de comunicación a través de servicios
Web. La aplicación móvil enviará y recibirá información en el sistema a
través de un servicio web. Es decir, existirá un servicio web que realizará
la función de interlocutor entre la aplicación móvil y la base de datos del
sistema.
• OE5: Leer las señales vitales de la tensión arterial, el nivel de glucosa en
sangre y la temperatura corporal de un paciente desde la aplicación móvil
para ser mostradas al médico en la aplicación web.
• OE6: Permitir especificar los datos que puedan ser significativos en el
estado de salud de un paciente desde la aplicación móvil. Estos datos
podrán ser consultados por el médico desde la aplicación web. Como
datos significativos para el estado de salud de un paciente se
considerarán:
o Las actividades cotidianas que realiza el paciente. Por ejemplo,
andar, correr, ver la tele, etc.
o La medicación que toma el paciente.
o Los alimentos que ingiere el paciente.
o Los síntomas que experimenta el paciente.
• OE7: Actualizar los datos internos de catálogos de la aplicación móvil si
se actualizan los datos de la base de datos central. Esto se realizará
mediante llamadas de la aplicación móvil a operaciones del servicio web.
1 Tensiómetro marca IEM modelo Stabil-O-Graph. http://www.iem.de/stabil_o_graph
2. Objetivos
15
De este objetivo específico procede el adjetivo de 'adaptable' al nombre
del sistema. Las tablas de catálogo tendrán dos campos en los que se
almacenarán la fecha de creación y la fecha de modificación de cada
registro. La aplicación móvil tendrá un apartado para sincronizar datos
con la base de datos central, de forma que, al sincronizarse la aplicación
móvil con el sistema, se producen los siguientes procesos de
sincronización de datos de catálogos:
o Creación de datos nuevos en la aplicación móvil: si un registro
en la base de datos central tiene una fecha de creación posterior a
la última fecha de sincronización de la aplicación móvil, ese
registro se creará en la aplicación móvil.
o Actualización de datos ya existentes en la aplicación móvil: si
un registro de catálogos de la base de datos central tiene una
fecha de modificación posterior a la última fecha de
sincronización de la aplicación móvil y además la fecha de
creación es anterior a la última fecha de sincronización de la
aplicación móvil, entonces, ese registro se actualizará en la
aplicación móvil.
• OE8: Usar el estándar de clasificación de medicamentos ATC
(Anatomical, Therapeutic, Chemical classification system) para catalogar
los medicamentos del sistema.
• OE9: Usar el estándar de clasificación de enfermedades CIE-10
(Clasificación Internacional de Enfermedades versión 10) para catalogar
las enfermedades del sistema.
• OE10: Usar el sistema de clasificación de alimentos DAFNE (DAta Food
NEtworking) para catalogar los alimentos en el sistema.
• OE11: Mostrar recomendaciones al paciente según la información
suministrada por éste en la aplicación móvil de forma que dichas
recomendaciones le asistan en la toma de sus decisiones. Las
2. Objetivos
16
recomendaciones que podrá ver el paciente desde la aplicación móvil
estarán catalogadas por un lado por el tipo de evento que pueda
mostrarlas así como la condición que ha de cumplirse para que
finalmente se muestren. Los tipos de eventos son la especificación de una
medición, un alimento, un medicamento, una actividad cotidiana
realizada o un síntoma por parte del paciente. La condición que ha de
cumplirse será una sentencia SQL que contabilizará el número de
elementos que se encuentran en un determinado estado. Si ese número de
elementos es positivo, esa recomendación se mostrará al usuario.
2.3 Limitaciones y consideraciones
Se debe tener en cuenta que este proyecto es un prototipo que pretende mostrar
lo que podría ser un sistema para el autocuidado y monitorización de pacientes en el
domicilio. Un sistema real necesitaría funcionalidades adicionales, mayor
parametrización de algunos catálogos, revisión de ciertos datos por parte de
profesionales médicos, etc. para poder ser usado por usuarios reales.
A continuación se detallan las principales limitaciones consideradas en el
desarrollo del proyecto:
• No se ha tenido en cuenta la seguridad de los datos. No se ha aplicado
ningún protocolo de seguridad en ninguna de las aplicaciones que forman
el sistema. El sistema trabaja con datos de salud de los pacientes que son
considerados como altamente protegidos por la L.O.P.D. (Ley Orgánica
de Protección de Datos). Por lo que para poder usar las aplicaciones del
sistema con usuarios reales habría que implementar protocolos de
seguridad entre éstas.
• No se han seguido los estándares para intercambio electrónico de
información clínica conocidos como Health Level Seven1 (HL7). Se ha
1 Health Level Seven. http://www.hl7.org
2. Objetivos
17
optado por omitirlo ya que su principal función es la integración de
sistemas heterogéneos. En el caso de que el prototipo presentado en este
PFC fuera integrado en el sistema sanitario actual, sería necesario tener
en cuenta las especificaciones HL7.
• La aplicación móvil es capaz de leer las mediciones del tensiómetro IEM
Stabil-O-Graph mediante Bluetooth. Sería deseable poder leer de más
dispositivos biométricos.
• Sólo se han tenido en cuenta algunos elementos a la hora de especificar
las recomendaciones del sistema. Se deberían especificar
recomendaciones para todos los elementos susceptibles de tenerlas.
• Se deberían parametrizar más elementos de algunos catálogos:
o Síntomas
o Alimentos
o Actividades cotidianas
o etc.
• Algunos datos utilizados por la aplicación deberían ser validados por
personal cualificado:
o Alimentos: nutricionista
o Recomendaciones sobre ciertos eventos: médico
2.4 Marco tecnológico de trabajo
Se detallan los recursos hardware y software usados en el desarrollo del
proyecto:
• Recursos hardware:
o Terminal móvil con sistema operativo Android1. Se usó
principalmente el modelo HTC Wildfire con la versión Froyo de
Android (2.2).
1 Google. Android. http://www.android.com
2. Objetivos
18
o Tensiómetro Bluetooth marca IEM modelo Stabil-O-Graph1
• Recursos software:
o Java 1.62 como lenguaje de programación
o Eclipse Indigo3 como IDE.
o Maven 34 para el empaquetado de la aplicación web y del servicio
web.
o MySQL 55 como gestor de la base de datos.
o Tomcat 66 como servidor de aplicaciones Java EE.
o C3P07 como librería para gestionar el pool de conexiones de la
base de datos en la aplicación web y en el servicio web.
o Jersey8 como paquete de implementación de Servicios Web.
o JFreeChart9 para la generación de gráficas mediante Java.
o DisplayTag10 para la generación dinámica de tablas en Java EE.
o Simple XML11 como librería de anotaciones XML.
o StarUML12 y la versión gratuita del plugin de Eclipse eUML213
como aplicaciones para el modelado de los diagramas en UML.
1 IEM. Stabil-O-Graph. http://www.iem.de/stabil_o_graph
2 Oracle. Java. http://www.oracle.com/technetwork/java/index.html
3 Eclipse Foundation. Eclipse Indigo. http://www.eclipse.org/indigo
4 Apache. Maven. http://maven.apache.org/index.html
5 Oracle. MySql. http://www.mysql.com
6 Apache. Tomcat. http://tomcat.apache.org
7 Waldman, Steve. C3P0. http://sourceforge.net/projects/c3p0
8 Java.net. Jersey. http://jersey.java.net
9 Object Refinery Limited. JFreeChart. http://www.jfree.org/jfreechart
10 The DisplayTag team. DisplayTag. http://www.displaytag.org
11 Simple XML Serialization http://simple.sourceforge.net
12 StarUML http://staruml.sourceforge.net
13 eUML2 http://www.soyatec.com/euml2
3 ESTADO DEL ARTE
3. Estado del arte
21
3.1 Telemedicina
3.1.1 Concepto
Existen numerosas definiciones sobre el concepto de telemedicina. Algunas de
las ellas son:
“El suministro de servicios de atención sanitaria, en los que la
distancia constituye un factor crítico, por profesionales que apelan a las
tecnologías de la información y de la comunicación con objeto de
intercambiar datos para hacer diagnósticos, preconizar tratamientos y
prevenir enfermedades y heridas, así como para la formación permanente
de los profesionales de atención de salud y en actividades de investigación y
evaluación, con el fin de mejorar la salud de las personas y de las
comunidades en que viven” (OMS).
“La utilización de las tecnologías de la información y de las
comunicaciones como un medio de proveer servicios médicos,
independientemente de la localización tanto de los que ofrecen el servicio,
los pacientes que lo reciben y la información necesaria para la actividad
asistencial” (INSALUD, 2000).
“El uso de las tecnologías de la información y las telecomunicaciones
para proporcionar servicios sanitarios, formación e información a
profesionales de la salud y consumidores” (Wooton y Craig, 2006).
“Cualquier sistema de tratamiento médico en el que el doctor y el
paciente se encuentran en diferentes localizaciones” (Rudowski, 2003).
El término de telemedicina tiene a confundirse con el término más genérico de e-
Health o e-Salud. e-Salud es “el uso de la tecnología emergente de la información y
comunicaciones, especialmente Internet, para mejorar o posibilitar la salud o la
asistencia sanitaria” (Eng, 2001). La diferencia consiste en que la telemedicina
3. Estado del arte
22
“implica un profesional de la salud en uno o ambos extremos de la comunicación”
(Wyatt y Sullivan, 2005).
3.1.2 Clasificación de los sistemas de telemedicina
En la Tabla 1 se expone una clasificación de los sistemas de telemedicina
mostrada en (Vicent et al., 2007).
Urgencia de la asistencia Tipo de interacción Localización de la
autoridad médica
controladora
Emergente (Sólo
tiempo real)
No emergente
(Tiempo real y
almacenamiento y
retransmisión)
Cercana Consulta en el
departamento de
Urgencias
Consulta en un
especialista
Proveedor con paciente
a proveedor
Lejana Consulta en el
departamento de
Urgencias mediante
extensiones del
proveedor
Consulta en atención
primaria mediante
extensiones del
proveedor
Paciente a proveedor
mediante un dispositivo
(Monitorización
remota)
Lejana Telemonitorización,
etc.
Telemonitorización,
etc.
Paciente a proveedor
(Teleasistencia)
Lejana Teleasistencia, etc. Teleasistencia, etc.
Servicios de
diagnósticos
N/A Teleradiología,
telepatología, etc.
Teleradiología,
telepatología, etc.
Proveedor a proveedor
sin pacientes
(Educación)
N/A Educación médica
continua
Tabla 1. Clasificación de los sistemas de telemedicina según (Vicent et al., 2007)
El presente proyecto sería un sistema de telemonitorización.
3. Estado del arte
23
3.1.3 Telemonitorización
La telemonitorización o monitorización remota consiste en la obtención y
almacenamiento a distancia de los parámetros de salud de uno o varios pacientes. Según
(IOM1, 1996) la telemonitorización consiste en “el uso de audio, video y otras
tecnologías de telecomunicaciones y de procesamiento de información para monitorizar
el estado de un paciente a distancia”.
Según (Trueman, P., 2009) la telemonitorización tiene varias ventajas para la
gestión de pacientes con enfermedades crónicas:
• Reduce las visitas rutinarias al médico.
• Permite realizar un seguimiento más intensivo y continuo de cada paciente
particular evitando el agravamiento de su enfermedad.
• Puede que sea más cómodo para un paciente estar telemonitorizado en su
propia casa que tener que ir repetidamente a la consulta del médico.
3.2 Trabajos relacionados
Se presentan en este apartado algunos trabajos, artículos y sistemas relacionados
con la telemonitorización de pacientes.
En (Morón, M. et al., 2005) se propone un prototipo de sistema de seguimiento
para pacientes que necesiten observación continua. El sistema está formado por
sensores Bluetooth, PDA’s, y un servidor central. Cada paciente lleva incorporados
varios sensores biométricos Bluetooth y una PDA. La PDA se encarga de recopilar los
datos biométricos suministrados por los sensores, enviar estos datos al servidor central y
de mantener localizado al paciente en caso de emergencia. Este prototipo tiene como
principales limitaciones la autonomía (un máximo de tres horas y cuarenta y cinco
minutos) y la capacidad de procesamiento (realizar una conexión con más de dos
sensores implicaba perder las conexiones establecidas) de las PDA’s.
1 IOM (Institute of Medicine of the National Academies) http://www.iom.edu
3. Estado del arte
24
En (Logan, A. et al., 2007) se expone un sistema de monitorización de pacientes
formado por tensiómetros Bluetooth, dispositivos móviles, un servidor central y faxes.
Cada paciente lleva asociados un tensiómetro Bluetooth y un dispositivo móvil. En el
centro médico se encuentra el servidor central y los faxes. El paciente se realiza
mediciones de tensión arterial que el tensiómetro Bluetooth envía al dispositivo móvil y
éste a su vez al servidor central. Desde el servidor central los médicos pueden consultar
las mediciones, asignar rangos de valores de las mediciones a cada paciente y establecer
el número de mediciones que ha de realizar cada paciente por semana. Según los valores
de las mediciones el sistema puede enviar mensajes de alerta, recordatorios, mensajes
de acción y alertas críticas. Los mensajes de alerta se muestran en el dispositivo móvil
del paciente y sirven para avisar si se ha recibido una medición algo elevada o algo baja.
Los recordatorios se envían cuando el paciente no ha enviado las mediciones que le
correspondían en una determinada semana. Los mensajes de acción se envían si la
tensión permanece baja o alta durante un período prolongado de tiempo e indican al
paciente alguna acción a realizar como por ejemplo visitar al médico. Las alertas críticas
se envían por fax al médico si las mediciones son especialmente elevadas o bajas
durante un período determinado de tiempo.
Figura 3. Esquema del sistema de monitorización de pacientes expuesto en (Logan, A. et al.,
2007)
3. Estado del arte
25
En (Sha, K. et al., 2008) se presenta el sistema SPA para el autocuidado de
pacientes crónicos. El sistema SPA usa sensores biométricos, dispositivos móviles y un
servidor de datos. El paciente lleva los sensores puestos de forma que estos envíen datos
en tiempo real al dispositivo móvil y éste a vez al servidor de datos. El servidor de datos
realiza las siguientes funciones: almacena los datos, los publica en un servidor web,
ejecuta procesos de minería de datos para encontrar relaciones en los datos, manda
cuestionarios a los pacientes y envía alertas a los profesionales sanitarios en caso de
recibir valores potencialmente peligrosos para la salud de algún paciente.
Figura 4. Arquitectura del sistema SPA
En (Sagahyroon, A. et al., 2011) se expone un prototipo de sistema de
monitorización de pacientes para hospitales. El sistema usa ZigBee como tecnología de
comunicación inalámbrica en los sensores biométricos. Cada paciente tiene incorporado
una serie de sensores biométricos que mandan sus mediciones a un dispositivo ZigBee
coordinador que es llevado por enfermeras o médicos del hospital. Desde este
dispositivo ZigBee coordinador se envían los valores de las mediciones a un servidor
central donde se serán almacenados en una base de datos. Si desde el servidor se detecta
alguna situación potencialmente problemática en los resultados de las mediciones de
algún paciente se envía un SMS a la enfermera o médico encargado de ese paciente.
En (Belgacem, N. et al., 2011) se propone un sistema de monitorización de
pacientes orientado a las enfermedades cardiovasculares. Se parte de la premisa de que
3. Estado del arte
26
en un ataque cardíaco las primeras horas son críticas para la salud del paciente. El
sistema tiene como objetivo detectar los ataques al corazón para que el paciente reciba
atención sanitaria lo antes posible de forma que se aumenten las probabilidades de que
el paciente sobreviva. El paciente lo único que deberá llevar es un sensor ECG
Bluetooth así como un dispositivo móvil con conectividad Bluetooth. Si se detecta una
situación peligrosa para el paciente el dispositivo móvil envía la descripción de la
situación así como la localización del paciente.
Figura 5. Esquema del sistema de telemonitorización de pacientes propuesto en (Belgacem, N.
et al., 2011)
3.2.1 Puntos fuertes de los trabajos presentados con respecto al presente
En general, los puntos fuertes de los trabajos expuestos en este apartado con
respecto al presente trabajo son:
• Monitorización periódica sin necesidad de la intervención del
paciente. Los trabajos expuestos usan sensores biométricos que realizan
las mediciones automática y periódicamente de forma que el paciente lo
único que necesita es llevar el sensor puesto (tensiómetro de pulsera,
etc.). El presente trabajo usa un tensiómetro que necesita la intervención
del usuario y éste además ha de especificar el momento en el que va a
realizar la medición en la aplicación móvil desarrollada. Es decir, las
mediciones no se capturan de forma completamente automática.
3. Estado del arte
27
• Localización del paciente. La mayoría de los trabajos expuestos tienen
alguna funcionalidad para localizar el paciente. Por norma general, se
usan tarjetas RFID en localizaciones internas (hospitales) o tecnología
GPS en localizaciones externas. El presente trabajo no tiene ninguna
funcionalidad para localizar al paciente.
• Gestión de alertas y situaciones potencialmente peligrosas. Los
trabajos expuestos incluyen alguna funcionalidad para notificar al
personal sanitario o a un asistente social en caso de producirse una
situación de emergencia (vía SMS, fax, alarma en el servidor central,
etc.). El presente trabajo muestra mensajes de recomendación al paciente
indicándole que llame al médico, ambulancia, etc. si detecta alguna
situación potencialmente peligrosa, pero necesita la intervención activa
del paciente. Los trabajos expuestos realizan alguna funcionalidad de
gestión de alertas sin necesidad de la intervención del usuario.
3.2.2 Puntos fuertes del presente trabajo con respecto a los trabajos presentados
Los puntos fuertes del presente trabajo con respecto a los trabajos presentados
son:
• Gestión de más tipos de datos de seguimiento. Los sistemas expuestos
básicamente usan como datos de seguimiento las mediciones de los
pacientes. El sistema desarrollado permite también gestionar su
alimentación, sus actividades cotidianas, su medicación y sus síntomas.
Con ello, el personal sanitario puede extraer conclusiones sobre los
posibles orígenes de los síntomas y de los valores de las mediciones de los
pacientes.
• Asistencia en la toma de decisiones del paciente. Ninguno de los trabajos
expuestos asiste al paciente en la toma de decisiones que afectan a su
estado de salud. El presente trabajo muestra recomendaciones acerca de la
idoneidad de lo que especifique el paciente en base a las mediciones y a lo
que hubiera especificado anteriormente. Algunos ejemplos que
provocarían mensajes de avisos en la aplicación móvil: si el paciente va a
3. Estado del arte
28
tomar un medicamento que interacciona perjudicialmente con alguna
comida u otro medicamento anteriormente tomado, si el paciente va a
realizar una actividad física intensa y las mediciones le desaconsejan que
no la realice, si va a sobrepasar la dosis de una determinada sustancia (sal,
grasas, medicamento, etc.). Con el modelo de datos diseñado se pueden
parametrizar situaciones muy particulares y específicas.
• Adaptable. El sistema desarrollado es adaptable. Adaptable en el sentido de
que una vez se le ha suministrado al paciente el dispositivo móvil, se
pueden incorporar nuevos alimentos, medicamentos, mensajes de
recomendación, etc. sin necesidad de reinstalar la aplicación en el
dispositivo móvil. Simplemente el paciente al enviar los datos al servidor
central, éste manda los datos nuevos y actualizados para que se empiecen a
usar en la aplicación móvil.
• Bajo consumo de batería del dispositivo móvil. El dispositivo móvil no
tiene por qué estar conectado a Internet indefinidamente. Sólo cuando va a
enviar los datos al servidor. Es decir, no depende de una red móvil
permanente. Lo mismo aplica para la conectividad Bluetooth. El
dispositivo no tiene por qué tener la conectividad Bluetooth activada
permanentemente. La aplicación móvil la activa automáticamente cuando
la va a necesitar y la desactiva cuando ya no la necesita. Ambas
características ayudan a reducir el consumo de batería del dispositivo
móvil.
3.3 Enfermedades crónicas
3.3.1 Introducción
Existen varias definiciones para sobre lo que es una enfermedad crónica.
Algunas de ellas son:
• “enfermedades de larga duración y generalmente de progresión lenta”
(WHO1).
1 WHO. Chronic diseases. http://www.who.int/topics/chronic_diseases/en
3. Estado del arte
29
• “enfermedades de duración prolongada que no se resuelven
espontáneamente y que rara vez se curan completamente” (AIHW, 2002).
• “Las condiciones que no se curan una vez adquiridas... son consideradas
crónicas” (National Center for Health Statistics, 2011).
3.3.2 Características comunes
Las características más significativas de las enfermedades crónicas son su larga
duración y su difícil curación completa.
Se exponen en este apartado algunas de las características comunes que suelen
tener las enfermedades crónicas.
• Tienen causas múltiples y complejas (AIHW, 2006; Osakidetza, 2010).
• Pueden emerger en cualquier momento de la vida, aunque son más
prevalentes en las edades más avanzadas (WHO, 2002; Osakidetza,
2010).
• Pueden llegar a comprometer la calidad de vida a través de
limitaciones funcionales y discapacidad (WHO, 2002; AIHW, 2006;
Osakidetza, 2010).
• Pueden derivan en un deterioro gradual de la salud (WHO, 2002;
AIHW, 2006; Osakidetza, 2010).
• No son la amenaza más inmediata para la vida pero sí son la causa
más común de mortalidad prematura (WHO, 2002; AIHW, 2006;
Osakidetza, 2010).
• La inmensa mayoría de las enfermedades crónicas son no contagiosas,
aunque recientemente se han incluido enfermedades contagiosas
como el sida (Osakidetza, 2010).
3.3.3 Ejemplos de enfermedades crónicas
Se enuncian algunas enfermedades que están consideradas como crónicas
organizadas por la clase de enfermedad:
• Enfermedades endocrinas, nutricionales y metabólicas:
o Diabetes mellitus
3. Estado del arte
30
o Obesidad mórbida (índice de masa corporal igual o superior a 40)
• Enfermedades parasitarias:
o VIH (Virus de la Inmunodeficiencia Humana)
o Hepatitis B y C
• Enfermedades del aparato genitourinario:
o Insuficiencia renal crónica
• Enfermedades respiratorias:
o Asma
o EPOC (Enfermedad Pulmonar Obstructiva Crónica)
o Bronquitis crónica
• Enfermedades cardiovasculares:
o Cardiopatía esquémica
o Insuficiencia cardíaca
• Enfermedades neurológicas:
o Epilepsia
o Esclerosis múltiple
o Enfermedad de Parkinson
• Enfermedades mentales:
o Depresión
o Psicosis
o Demencia
3.3.4 Modelos de gestión de pacientes crónicos
Se exponen en este apartado los modelos de gestión de pacientes crónicos más
conocidos.
3.3.4.1 Modelo de Atención a Crónicos (The Chronic Care Model CCM)
El modelo CCM fue desarrollado por Ed Wagner en 1999.
En el modelo CCM, la mejora en la gestión de pacientes crónicos es la
consecuencia de interacciones productivas entre pacientes activados e informados y
equipos sanitarios proactivos y preparados.
3. Estado del arte
31
El modelo CCM se encuentra desglosado en varios componentes mostrados en la
Figura 6 (Wagner, 1999). En la Tabla 2 (Wagner, 1999) se muestra un resumen de los
componentes del modelo.
Figura 6. Modelo CCM (Chronic Care Model)
Componente Descripción Ejemplos
Sistema de salud. Órganización
sanitaria
Programa de planificación que
incluya objetivos medibles para la
mejora del cuidado de las
enfermedades crónicas.
• Apoyo manifiesto a las
mejoras proporcionadas
por los altos dirigentes.
• Incentivos a los prestadores
de asistencia.
Soporte al autocuidado Énfasis en la importancia del papel
fundamental que desempeñan los
pacientes al gestionar por sí mismos
sus enfermedades crónicas
• Recursos, formación,
prácticas y apoyo
psicológico a los pacientes
que gestionan sus
enfermedades.
Soporte a la toma de decisiones Integración de las directrices
basadas en la evidencia en la
práctica clínica diaria.
• Amplia difusión de las
directrices prácticas.
• Formación y soporte a los
equipos sanitarios.
3. Estado del arte
32
Diseño del sistema de prestación Enfoque en el trabajo en equipo y en
las prácticas extendidas para dar
atención a los enfermos crónicos.
• Visitas planificadas y
seguimiento sostenido del
paciente.
• Definición clara de los roles
de los equipos sanitarios.
Sistemas de información clínica Desarrollo de sistemas de
información basados en las
poblaciones de pacientes para
proporcionar información relevante.
• Sistema de control que
proporcione alertas,
recordatorios e
información de
seguimiento
• Identificación de subgrupos
relevantes de pacientes
que requieran cuidados
proactivos.
Comunidad. Recursos y políticas. Desarrollar asociaciones con las
organizaciones comunitarias que
cubran y den soporte a las
necesidades de los pacientes.
• Identificar programas
efectivos que insten a la
participación.
• Remisión a los servicios de
la comunidad relevantes.
Tabla 2. Componentes del modelo CCM
3.3.4.2 Modelo de Atención Innovadora a Condiciones Crónicas (The Innovative Care for Chronic Conditions Framework ICCC)
El modelo de Atención Innovadora a Condiciones Crónicas (ICCC) (WHO,
2002) es una adaptación del modelo CCM propuesta por la OMS.
En la Figura 7 (WHO, 2002) se muestra un esquema del marco ICCC.
3. Estado del arte
33
Figura 7. Esquema del marco ICCC
3.3.4.2.1 Niveles estratificados de un sistema sanitario
Desde el marco ICCC se advierte que los sistemas sanitarios actuales tienen un
carácter reactivo en el sentido de que los ciudadanos sólo reciben asistencia cuando
acceden a ellos de forma episódica. Este enfoque es bueno para el tratamiento de
enfermedades agudas, pero no es el adecuado para tratar enfermedades crónicas. Esto se
debe a la propia naturaleza de las condiciones crónicas. Las enfermedades crónicas son
de larga duración, persistentes, muy prevalentes en edades avanzadas y si no se tratan
adecuadamente pueden desencadenar en episodios agudos. Si no se gestionan
adecuadamente estos estados agudos pueden requerir atención especializada,
hospitalizaciones que podrían haberse evitado y derivar en última instancia en la muerte
prematura del enfermo crónico.
El marco ICCC propone estratificar los sistemas sanitarios en tres niveles
(Figura 8):
1. Nivel Micro. Nivel en el que se producen las interacciones del
personal sanitario con los pacientes.
3. Estado del arte
34
2. Nivel Meso. Nivel de las organizaciones de asistencia sanitaria y sus
enlaces con la comunidad.
3. Nivel Macro. Nivel de las políticas sanitarias.
Figura 8. Niveles de un sistema sanitario global según ICCC
3.3.4.2.2 Problemas generales de un sistema sanitario
El marco ICCC identifica de forma general problemas en los sistemas sanitarios
para cada uno de los niveles. Los problemas identificados para cada nivel se exponen en
la Tabla 3.
Nivel Problema Descripción
No se le otorga autonomía a los
pacientes
Los pacientes crónicos han de
modificar sus estilos de vida
para gestionar mejor sus
condiciones. No deben ser
simples receptores pasivos de los
servicios sanitarios. Llevar un
estilo de vida saludable influye
más en el estado de salud que las
intervenciones médicas puras.
Micro
No se valoran las interacciones
con los pacientes
El personal sanitario debe
asegurarse que los pacientes
crónicos tengan la formación y
las aptitudes necesarias para
controlar sus condiciones
3. Estado del arte
35
crónicas. Los pacientes crónicos
necesitan un ambiente y un
contexto en el que se apoyen sus
comportamientos de autogestión
y autocuidado de sus
condiciones crónicas.
Falta de organización en la
atención de las condiciones
crónicas
Los sistemas sanitarios actuales
están diseñados para ser
reactivos a los problemas de los
pacientes. La atención sanitaria
debería ser preventiva para
evitar males mayores y ahorrar
costes evitando hospitalizaciones
e intervenciones innecesarias al
ser prevenidas.
El personal de atención de salud
carece de herramientas y pericia
El tratamiento de enfermedades
crónicas requiere de unos
conocimientos y herramientas
que el personal sanitario solo
dispone en áreas especializadas.
Este conocimiento y
herramientas deberían estar
también disponibles en la
atención primaria.
No se informa sobre la
prevención
La mayoría de las condiciones
crónicas son prevenibles
mediante hábitos de vida
saludables. Los pacientes
deberían ser formados y
motivados a llevar estos hábitos.
Meso
Los sistemas de información no
están instrumentados
Deben desarrollarse sistemas de
información que permitan
obtener información sobre
tendencias de salud, posibles
futuros problemas, etc. También
debe monitorizarse el estado de
salud de algunos pacientes
crónicos para prevenir futuros
problemas de salud que puedan
desarrollar.
3. Estado del arte
36
Falta de conexión con los
recursos de la comunidad
Las organizaciones de atención
sanitaria deben integrar los
recursos de la comunidad en la
asistencia a los pacientes con
condiciones crónicas.
Falta de un marco legislativo Deben existir leyes que definan
los derechos de las personas a
ser atendidas y que promuevan
la protección de los derechos
humanos para los pacientes.
Las políticas de salud y sus
planes respectivos son
anticuados
Los sistemas sanitarios deben
complementarse con modelos de
atención a condiciones crónicas.
Esto permitiría ahorrar costes en
visitas al médico rutinarias,
hospitalizaciones evitables
debido al mayor énfasis en la
prevención, etc.
Los gobiernos no invierten con
sabiduría
Esto se debe a muchas y
múltiples causas. Una de ellas es
la influencia de la industria
privada y de algunos grupos de
profesionales.
Los sistemas financieros están
fragmentados
En muchos sistemas de atención
sanitarios el financiamiento se
fragmenta en varias líneas
presupuestarias. Esto dificulta la
atención coordinada y uniforme
a los problemas crónicos.
Falta educación continua Se deberían habilitar
mecanismos para que los
profesionales sanitarios
participen en actividades
educacionales después de
finalizar la capacitación formal.
Macro
Se ignoran los enlaces
intersectoriales
La calidad de los servicios de
atención a crónicos no será
óptima si no hay una integración
adecuada entre los diversos
sectores de la sociedad
3. Estado del arte
37
(organizaciones no
gubernamentales, grupos de
comunidades, sectores
gubernamentales, etc.).
Tabla 3. Problemas identificados por el marco ICCC en la mayoría de los sistemas sanitarios
clasificados por sus niveles estratificados
3.3.4.2.3 Principios orientadores del marco ICCC
El marco del modelo ICCC está basado en un conjunto de principios
orientadores que rigen los niveles micro, meso y macro de un sistema sanitario. Estos
principios son:
• La toma de decisiones basada en evidencia. La evidencia debe ser la
base para todas las decisiones correspondientes a políticas, servicios y
atención de las condiciones crónicas.
• Enfoque en la población. Los sistemas sanitarios han de estratificar los
servicios según las necesidades de cada paciente.
• Enfoque en la prevención. Dado que la mayoría de las enfermedades
crónicas se pueden prevenir, se debe apoyar la prevención y fomentar los
hábitos de vida saludables. A largo plazo, puede reducirse la carga de
trabajo del sistema sanitario y mejorar la calidad de la atención sanitaria.
• Enfoque en la calidad. La calidad de la atención ha de gestionarse y ha
de asegurarse que los recursos se usan adecuadamente.
• Integración. La integración es el núcleo del marco ICCC. Los tres
niveles de un sistema sanitario han de estar integrados.
• Flexibilidad/adaptabilidad. Los sistemas sanitarios han de estar
preparados para adaptarse a las situaciones cambiantes. Se han de
integrar en los sistemas sanitarios procesos de evaluación de datos para
adaptarse a las situaciones cambiantes.
3.3.4.2.4 Elementos del marco ICCC
En la Tabla 4 y en la Figura 9 (Osakidetza, 2010 adaptada de WHO, 2002) se
muestran los elementos del marco ICCC de gestión de pacientes crónicos. Todos los
3. Estado del arte
38
elementos aplicados tienen como consecuencia la obtención de mejores resultados para
los enfermos crónicos.
Nivel Destinatario Elemento del marco ICCC
Pacientes y familiares Pacientes y familiares motivados,
preparados e informados
Equipos de Asistencia
sanitaria
Equipos de asistencia sanitaria
motivados, preparados e informados
Micro
Agentes de la comunidad Quienes apoyan a la comunidad
preparados, informados y motivados
Fomento de la continuidad y
coordinación
Promoción de la calidad a través del
liderazgo y de incentivos
Organización y dotación de los
equipos de asistencia sanitaria
Utilización de sistemas de
información
Organización Sanitaria
Apoyo al autocuidado y a la
prevención
Sensibilización y reducción del
estima
Impulso de mejores resultados a
través de apoyo y liderazgo
Meso
Comunidad
Movilización y coordinación de
recursos
Fortalecimiento de alianzas
Desarrollo y asignación de recursos
humanos
Integración de políticas
Apoyo de marcos legislativos
Financiación adecuada
Macro Marco de Políticas Positivas
Liderazgo y apoyo
Tabla 4. Elementos del marco ICCC
3. Estado del arte
39
Figura 9. Esquema y elementos del marco ICCC
3.3.4.3 Pirámide de Kaiser
El modelo de la Pirámide de Kaiser fue desarrollado por el consorcio
sanitario Kaiser Permanente1 en Estados Unidos. El modelo consiste en la clasificación
de los ciudadanos en varios niveles según la probabilidad de contraer enfermedades y el
nivel de atención sanitaria que puedan necesitar. En la Figura 10 se muestra un esquema
del modelo.
1 Kaiser Permanente. https://www.kaiserpermanente.org
3. Estado del arte
40
Figura 10. Pirámide de Kaiser
En la cúspide de la pirámide se encuentran los pacientes que han desarrollado
varias condiciones complejas con frecuente comorbilidad. A estos pacientes se les
asignan planes de atención orientados a reducir el uso de la atención especializada y a
evitar los ingresos hospitalarios en la medida de lo posible.
En el nivel central de la pirámide se encuentran los pacientes de alto riesgo pero
de menor complejidad y comorbilidad que los situados en la cúspide. A estos pacientes
se les gestiona la enfermedad combinando cuidados profesionales con apoyo al
autocuidado.
En la base de la pirámide se encuentran la mayoría de los pacientes crónicos que
han desarrollado alguna condición crónica y que no tienen un riesgo inminente para su
salud. A estos pacientes se les ofrece soporte para su autocuidado.
En un nivel inferior a la pirámide se considera a la población general que aún no
ha desarrollado ninguna condición crónica. Se prioriza la prevención y un diagnóstico
prematuro.
3. Estado del arte
41
3.4 Sistemas de clasificación usados en el proyecto
3.4.1 Sistema de clasificación de enfermedades ICD-10
La Clasificación Internacional de Enfermedades1 (CIE en castellano, ICD en
inglés e internacionalmente) es un listado clasificado de enfermedades realizado por la
OMS. Actualmente se encuentra en su versión 10, por lo que es nombrado como ICD-
10.
Se muestra en la Tabla 5 las clases de enfermedades que tiene el estándar ICD
versión 10 junto con el rango de códigos de enfermedad que comprende cada clase.
Código de la
clase de
enfermedad
Bloques de códigos
de enfermedades
Clase de enfermedades
I A00-B99 Ciertas enfermedades infecciosas y parasitarias
II C00-D48 Neoplasias
III D50-D89 Enfermedades de la sangre y de los órganos
hematopoyéticos y otros trastornos que afectan el
mecanismo de la inmunidad
IV E00-E90 Enfermedades endocrinas, nutricionales y metabólicas
V F00-F99 Trastornos mentales y del comportamiento
VI G00-G99 Enfermedades del sistema nervioso
VII H00-H59 Enfermedades del ojo y sus anexos
VIII H60-H95 Enfermedades del oído y de la apófisis mastoides
IX I00-I99 Enfermedades del sistema circulatorio
X J00-J99 Enfermedades del sistema respiratorio
XI K00-K93 Enfermedades del aparato digestivo
XII L00-L99 Enfermedades de la piel y el tejido subcutáneo
XIII M00-M99 Enfermedades del sistema osteomuscular y del tejido
conectivo
XIV N00-N99 Enfermedades del aparato genitourinario
XV O00-O99 Embarazo, parto y puerperio
XVI P00-P96 Ciertas afecciones originadas en el periodo perinatal
XVII Q00-Q99 Malformaciones congénitas, deformidades y anomalías
cromosómicas
1 WHO. International Classification of Diseases (ICD). http://www.who.int/classifications/icd/en
3. Estado del arte
42
XVIII R00-R99 Síntomas, signos y hallazgos anormales clínicos y de
laboratorio, no clasificados en otra parte
XIX S00-T98 Traumatismos, envenenamientos y algunas otras
consecuencias de causa externa
XX V01-Y98 Causas extremas de morbilidad y de mortalidad
XXI Z00-Z99 Factores que influyen en el estado de salud y contacto
con los servicios de salud
XXII U00-U99 Códigos para situaciones especiales
Tabla 5. Clases de enfermedades en ICD-10
Se muestra en la Tabla 6 algunos ejemplos de enfermedades crónicas
clasificadas por el estándar ICD-10.
Código de
Enfermedad
Enfermedad Código de
Clase
Clase de Enfermedad
E10 Diabetes mellitus
insulinodependiente
IV Enfermedades endocrinas, nutricionales y
metabólicas
B16 Hepatitis B I Ciertas enfermedades infecciosas y parasitarias
J45 Asma X Enfermedades del sistema respiratorio
G40 Epilepsia VI Enfermedades del sistema nervioso
Tabla 6. Ejemplos de enfermedades crónicas clasificadas por el estándar ICD-10
3.4.2 Sistema de clasificación de fármacos ATC
El sistema de clasificación de fármacos ATC1 (Anatomical, Therapeutic,
Chemical classification system) es un sistema de clasificación de sustancias
farmacológicas y medicamentos instituido por la OMS.
El código ATC está compuesto de cinco campos. Cada uno de los campos
concatenado con los anteriores forma una agrupación. La agrupación de los cinco
campos clasifica unívocamente al medicamento o a la sustancia farmacológica. Los
campos de los que está compuesto el código ATC son:
• Sistema u órgano sobre el que actúa. Está formado por una letra de las
siguientes:
1 WHO. The Anatomical Therapeutic Chemical Classification System with Defined Daily Doses
(ATC/DDD). http://www.who.int/classifications/atcddd/en/
3. Estado del arte
43
o A: Sistema digestivo y metabolismo
o B: Sangre y órganos hematopoyéticos
o C: Sistema cardiovascular
o D: Medicamentos dermatológicos
o G: Aparato Genitourinario y hormonas sexuales
o H: Preparados hormonales sistémicos excluyendo hormonas
sexuales.
o J: Antiinfecciosos en general para uso sistémico.
o L: Agentes antineoplásicos e inmunomodulares
o M: Sistema musculoesquelético
o N: Sistema nervioso
o P: Productos antiparasitarios, insecticidas y repelentes
o R: Sistema respiratorio
o S: Órganos de los sentidos
o V: Varios
• Subgrupo terapéutico. Está identificado por un número de dos cifras.
• Subgrupo terapéutico o farmacológico. Identificado por una letra del
alfabeto.
• Subgrupo terapéutico, farmacológico o químico. Identificado por una
letra del alfabeto.
• Nombre del principio activo o de la asociación farmacológica.
Identificado por un número de dos cifras.
Se muestra en la Tabla 7 el desglose de los campos del código ATC de la
aspirina (B01AC06).
Campo ATC Valor del
campo Valor de la agrupación
Descripción de la agrupación
Sistema u órgano sobre el que actúa
B B Sangre y órganos hematopoyéticos
Subgrupo terapéutico 01 B01 Agentes antitrombóticos
Subgrupo terapéutico o farmacológico
A B01A Agentes antitrombóticos
Subgrupo terapéutico, farmacológico o químico
C B01AC Inhibidores de la agregación plaquetaria excluyendo a la heparina
Nombre del principio 06 B01AC06 Ácido acetilsalicílico
3. Estado del arte
44
activo o de la asociación farmacológica
Tabla 7. Desglose de los campos del código ATC de la aspirina (B01AC06)
3.4.3 Sistema de clasificación de alimentos DAFNE
El sistema de clasificación de alimentos DAFNE procede de la iniciativa DAFNE
(DAta Food NEtworking). La iniciativa DAFNE fue concebida en 1980 y tiene como
objetivo la evaluación de los hábitos alimentarios en Europa a través de datos obtenidos
mediante encuestas de presupuestos familiares.
Se muestra en la Tabla 8 el sistema de clasificación de alimentos DAFNE.
Clase de alimento Subclase de alimento Pan y panecillos
Productos de panadería (excluyendo pan y
panecillos)
Arroz y cereales
Harina
Cereales y productos a base de cereales
Pasta
Carne roja
Despojos
Aves de corral
Carne enlatada
Carne
Platos de carne
Pescado
Marisco
Pescado
Platos de pescado
Leches
Quesos
Lácteos
Productos lácteos (excluyendo el queso)
Huevos Huevos
Lípidos de origen animal Lípidos
Lípidos de origen vegetal
Patatas y otras raíces feculentas Patatas y otras raíces feculentas
3. Estado del arte
45
Legumbres Legumbres
Frutos secos Frutos secos
Vegetales frescos Vegetales
Vegetales procesados
Frutas frescas Fruta
Frutas procesadas
Zumo de frutas Zumos de fruta y de vegetales
Zumo de vegetales
Azúcares Azúcares y productos derivados del azúcar
Productos derivados del azúcar
Estimulantes
Agua mineral
Bebidas no alcohólicas
Refrescos
Vino
Cerveza
Bebidas alcohólicas
Bebidas espirituosas
Tabla 8. Sistema de clasificación de alimentos DAFNE
3.5 Android
3.5.1 Introducción
Android1 es un conjunto de software de código abierto basado en el núcleo de
Linux que incluye un sistema operativo, un middleware y un conjunto de aplicaciones.
Está pensado para ser usado en teléfonos inteligentes (smartphones) y tabletas.
Se distribuye bajo una licencia Apache versión 2, una licencia libre que permite
su integración con soluciones de código propietario.
El proyecto Android está liderado por Google y un conglomerado de otras
empresas tecnológicas agrupadas bajo el nombre de Open Handset Alliance2 (OHA). El
principal objetivo de esta alianza es el desarrollo de estándares abiertos para la telefonía
móvil para incentivar su desarrollo y mejorar la experiencia de usuario.
1 Google. Android. www.android.com
2 Open Handset Alliance. http://www.openhandsetalliance.com
3. Estado del arte
46
Las aplicaciones para Android se programan en lenguaje Java y son ejecutadas
en una máquina virtual especialmente diseñada para esta plataforma, que ha sido
bautizada como Dalvik. Se empaquetan con el formato APK (Application Package
File), el cual es una variante del formato JAR utilizado para empaquetar aplicaciones
Java. Existe un SDK gratuito para el desarrollo de aplicaciones en Android así como el
plug-in ADT (Android Development Tools) para el IDE Eclipse.
3.5.2 Arquitectura
Android es una plataforma diseñada para dispositivos móviles que contiene un
conjunto de software donde se incluye un sistema operativo, librerías middleware y
aplicaciones básicas para el usuario.
Figura 11. Arquitectura de Android
En la arquitectura de Android mostrada en la Figura 111 están incluidos entre
otros los siguientes componentes:
1 Android Open Source Project http://source.android.com
3. Estado del arte
47
• Máquina virtual de Java propia, Dalvik1, especialmente diseñada para
dispositivos móviles.
• Localización GSM
• Soporte para diversos elementos hardware, siempre y cuando el
dispositivo móvil disponga del elemento hardware: Wi-Fi, Cámara
fotográfica, Cámara de video, GPS, Acelerómetro, Bluetooth, Infrarrojos,
USB, etc.
• Motor de bases de datos incluido (SQLite2)
• Navegador web integrado basado en el motor WebKit3.
• Soporte para diversos formatos multimedia4
• Gráficos optimizados alimentados por una librería gráfica 2D propia y
3D con OpenGL.
• Un completo entorno de desarrollo que incluye un emulador de
dispositivos, herramientas para depurar y un plug-in para el IDE Eclipse.
3.6 Tecnologías usadas en el desarrollo de la aplicación web
3.6.1 Java EE
3.6.1.1 Introducción
Java EE (Java Platform, Enterprise Edition) es una plataforma de programación
en Java para desarrollar aplicaciones software en una arquitectura de varias capas
distribuidas y apoyadas en componentes software modulares ejecutándose sobre un
servidor de aplicaciones.
Uno de los beneficios de la plataforma Java EE es su bajo coste debido a que
hay muchos componentes y entornos de desarrollo de código abierto disponibles para
extender la plataforma y simplificar el desarrollo. 1 Dalvik Virtual Machine http://www.dalvikvm.com
2 SQLite http://www.sqlite.org
3 The WebKit Open Source Project http://www.webkit.org
4 Android Supported Media Formats http://developer.android.com/guide/appendix/media-formats.html
3. Estado del arte
48
La plataforma Java EE está muy extendida en el desarrollo de aplicaciones
basadas en la web.
3.6.1.2 El patrón Modelo-Vista-Controlador en una aplicación Java EE
El patrón MVC se encuentra descrito en el apartado de Patrones utilizados. Se
producen los siguientes pasos mostrados en la Figura 121 cuando un usuario realiza una
petición HTTP sobre una aplicación web Java EE:
1. El evento (petición HTTP) es interceptado por el controlador.
2. El controlador evalúa el evento y lo redirige al elemento de la capa de
Modelo encargado de procesar dicho evento.
3. El elemento del Modelo realiza las acciones que tuviera que realizar y
devuelve los resultados de dichas acciones al Controlador.
4. El Controlador determina el elemento de la Vista apropiado para mostrar
dichos resultados y hace que la aplicación muestre ese elemento de la Vista.
5. El elemento de la Vista al cargarse puede que necesite datos del modelo para
mostrarlos en el resultado.
6. La vista es mostrada finalmente al usuario.
1 Gustavo Prieto. Manual Básico de Struts. Disponible en:
http://www.programacion.com/articulo/manual_basico_de_struts_156
3. Estado del arte
49
Figura 12. Patrón MVC en una aplicación Java EE.
3.6.2 Struts
3.6.2.1 Introducción
Struts1 es un framework de desarrollo de aplicaciones web basado en el patrón
MVC (Modelo-Vista-Controlador) para la plataforma Java EE (Java Enterprise Edition)
desarrollado por Apache2.
Struts tiene las siguientes características:
• Manejo de formularios. Para ello las clases que representen a un
formulario han de extender de la clase ActionForm. Representan el
estado del lado del servidor de los campos de entrada de un formulario.
Struts tiene un marco de trabajo que permite la validación de los campos
de un formulario tanto en el lado del cliente como del servidor.
• Incorpora el marco de trabajo Apache Tiles. Apache Tiles es un marco de
trabajo para la composición de plantillas que pueden montarse en una
página completa en tiempo de ejecución. Estas plantillas pueden
especificarse unas dentro de otras para permitir la reutilización de código
y evitar duplicarlo. Por ejemplo, si se tienen definidas las partes que
conforman la estructura de un determinado sitio web y hubiera que 1 Apache Software Foundation, Struts. http://struts.apache.org
2 Apache Software Foundation. http://www.apache.org
3. Estado del arte
50
modificar la localización de cada parte del sitio web, con Tiles sólo
habría que modificar la página encargada de colocar las partes. Las
páginas que forman las partes no tendrían por qué ser modificadas.
• Struts tiene unas librerías de etiquetas propias que tienen entre otras
funcionalidades:
o La creación de elementos HTML: campos de tipo texto, de tipo
contraseña, botones de radio, botones checkbox, listas
desplegables, etc.
o Implementación de funciones lógicas. Por ejemplo, si se cumple
una determinada condición se ha de mostrar unos resultados
determinados, etc.
3.6.2.2 El patrón MVC en una aplicación Struts
Un usuario al realizar una petición HTTP sobre una aplicación Struts se
producen los siguientes pasos:
1. El evento (petición HTTP) es interceptado por el servlet Controlador de
Struts. Este Servlet ha de ser especificado en el fichero de configuración
de la aplicación Java EE (web.xml).
2. El controlador evalúa el evento y lo redirige a la clase Action
correspondiente. La clase Action recibirá el objeto ActionFom
correspondiente a ese evento. En Struts las clases Action (las clases que
heredan de la clase Action), son las encargadas de ejecutar las acciones
correspondientes a cada petición HTTP. Las clases ActionForm (las
clases que heredan de la clase ActionForm) son aquellas encargadas de
encapsular los datos de los formularios enviados en las peticiones HTTP.
Cada petición HTTP puede tener asociada una clase Action y una clase
ActionForm. No tienen por qué tenerlas asociadas.
3. Estado del arte
51
3. La clase Action ejecuta las acciones que tuviera especificadas. y
establece los resultados de su ejecución en los datos de la clase
ActionForm que tuviera asociada.
4. El Controlador determina el JSP apropiado para mostrar los resultados.
5. El JSP al cargarse puede que necesite datos del formulario (del objeto de
la clase ActionForm) para mostrarlos en el resultado.
6. La vista es mostrada finalmente al usuario. Se muestra la respuesta de la
petición HTTP en el navegador.
3.6.3 Maven
Maven1 es una herramienta de software basada en línea de comandos para la
gestión y construcción de proyectos Java creada por Jason van Zyl en 2002. Maven
tiene las siguientes características:
• Tiene licencia Apache 2.0 por lo que es software libre.
• Da soluciones a tareas que abarcan desde la compilación de un proyecto
hasta su distribución, despliegue y documentación.
• Configuración del proyecto en un fichero XML llamado POM (Project
Object Model). En el POM se pueden especificar entre otros, los
siguientes elementos:
o Versión del compilador y opciones de compilación.
o Las rutas del código fuente
o Los patrones que han de cumplir los ficheros que se tendrán en
cuenta para la compilación y el empaquetado de los ficheros de
salida.
o Los informes que se han de generar al construir el proyecto:
JavaDoc
Informes asociados a analizador estáticos de código
fuente: 1 Apache Software Foundation, Maven. http://maven.apache.org/index.html
3. Estado del arte
52
• Checkstyle
• PMD
• Jdepend
o Las Dependencias del proyecto y las versiones de éstas.
• Permite una sencilla gestión simultánea de varios proyectos.
• Dispone de un enorme repositorio de librerías y plugins de código abierto
en constante actualización. Se pueden desarrollar plugins propios en el
caso de que se necesitase una funcionalidad a medida.
• Integración con ANT (Apache ANT), una herramienta desarrollada en
Java mediante línea de comandos que permite la automatización de
tareas mediante ficheros XML.
• Permite la generación de un portal Web en el cual se muestran los
informes generados por Maven.
• Gestión de versiones y publicación. Maven se integra con sistemas de
gestión de versiones como Subversion y CVS y gestiona la publicación
de versiones.
3.6.4 Pool de conexiones C3P0
C3P01 es una librería para aumentar la funcionalidad de los driver JDBC
tradicionales mediante funcionalidad definida en la especificación jdbc3 y en las
extensiones opcionales de jdbc2.
Algunas de las propiedades que pueden usarse para configurar un pool de
conexiones C3P0 se muestran en la Tabla 9.
Nombre Descripción Valor por
defecto acquireRetryAttempts Define cuántas veces C3P0 intentará adquirir una
nueva conexión de la base de datos antes de dejar de intentarlo. Si este valor es menor o igual a cero, C3P0 intentará obtener una conexión de la base de datos de forma indefinida hasta obtenerla.
30
autoCommitOnClose Por defecto al cerrarse una conexión de la base de datos se produce un rollback. Especificando este atributo con valor true se fuerza a que cada vez que se cierre una conexión se realice un commit de
false
1 Waldman, Steve. C3P0. http://sourceforge.net/projects/c3p0
3. Estado del arte
53
los datos que estuvieran pendientes de confirmar en la base de datos.
checkoutTimeout El número de milisegundos que un cliente que quiera obtener una conexión esperará antes de conseguirla. Un valor de 0 implicará una espera indefinida, un valor mayor de 0 implicará una SQLException si no se obtiene una conexión antes del tiempo especificado.
0
idleConnectionTestPeriod El periodo en milisegundos en el que C3P0 realizará una comprobación de las conexiones ociosas. Especificando 0 o un número por debajo de 0 no se realiza esta comprobación.
0
initialPoolSize El número de conexiones que C3P0 intentará adquirir al arrancar. Este número debería estar comprendido entre los valores especificados en minPoolSize y maxPoolSize.
3
maxConnectionAge Segundos de vida de una conexión. Las conexiones más antiguas de lo especificado en este atributo serán destruidas y eliminadas del pool de conexiones. Un valor de 0 evita que se eliminen las conexiones por antigüedad.
0
maxPoolSize Número máximo de conexiones que un pool de conexiones puede mantener.
15
minPoolSize Número mínimo de conexiones que un pool puede mantener.
3
password Contraseña que se usará para la fuente de datos (DataSource).
null
user Usuario que se usará para la fuente de datos (DataSource).
null
Tabla 9. Propiedades de configuración del Pool de Conexiones C3P0
3.6.5 DisplayTag
DisplayTag1 es una librería de etiquetas JSP de código abierto que permite
representar tablas de datos permitiendo el uso de patrones de diseño. DisplayTag, dado
un listado de objetos, permite mostrar una tabla con ellos en la que se pueden ordenar,
paginar, agrupar y decorar los valores de la tabla de forma personalizada y sencilla.
También permite exportar las tablas a otros formatos como PDF, Excel, CSV y XML.
1 The DisplayTag team, DisplayTag. http://www.displaytag.org
3. Estado del arte
54
Figura 13. Ejemplos de tablas formadas por la librería DisplayTag
3.6.6 JFreeChart
JFreeChart1 es una librería de código abierto escrita en Java que permite generar
gráficos en las aplicaciones. Tiene las siguientes características:
• Un API consistente y bien documentado
• Soporta un gran número de tipos de gráficos.
• Tiene un diseño flexible que es fácil de extender.
• Soporta muchos tipos de salida incluyendo
o Componentes Swing
o Ficheros de imágenes: JPEG, PNG, etc.
o Formatos de imágenes vectoriales incluyendo PDF, EPS y SVG.
• Se distribuye bajo licencia LGPL (GNU Lesser General Public Licence).
1 Object Refinery Limited, JFreeChart. http://www.jfree.org/jfreechart
3. Estado del arte
55
En la Figura 14 se muestra un ejemplo de gráfico desarrollado mediante
JFreeChart.
Figura 14. Gráfico de ejemplo de JFreeChart
3.7 Tecnologías usadas en el servicio web
3.7.1 Servicios web
Según (Alonso et al., 2004) una definición precisa de servicio web sería la
emitida por el W3C:
“una aplicación software identificada por una URI, cuyas interfaces
y vinculaciones son capaces de ser definidas, descritas y descubiertas como
artefactos XML. Un SW soporta la interacción con otros agentes software
mediante el intercambio de mensajes basado en XML a través de protocolos
basados en Internet”.
3. Estado del arte
56
3.7.2 Jersey
3.7.2.1 Introducción
Jersey1 es una implementación de código abierto del API JAX-RS (JSR 311)
(JCP, JAX-RS: The JavaTM API for RESTful Web Services) para la construcción de
Web Services.
Jersey permite la construcción de servicios web mediante anotaciones.
JAX-RS proporciona algunas anotaciones para establecer las correspondencias
entre las clase Java y las operaciones que ejecutan del servicio web. Es decir, algunos
métodos de la clase Java se corresponderán con las operaciones que se podrán ejecutar
del servicio web.
En la Tabla 10 se describen algunas de estas anotaciones.
Anotación Descripción @Path Especifica la ruta relativa del recurso web asociado a una clase del servicio web. @GET, @PUT, @POST, @DELETE y @HEAD
Especifica el tipo de petición HTTP de un recurso.
@Produces Especifica el tipo de respuesta MIME que produce el recurso web asociado a la clase del servicio web.
@Consumes Especifica el tipo de objeto MIME que recibe el recurso web asociado a la clase del servicio web.
Tabla 10. Anotaciones usadas por Jersey
3.7.3 Simple XML Serialization Framework
Simple XML2 es un framework para gestionar XML desde Java. Su objetivo es
proporcionar un framework que permita un rápido desarrollo de sistemas de
configuración y comunicación mediante XML. Permite serializar objetos Java en
ficheros XML y deserializar ficheros XML en objetos Java.
1 Java.net, Jersey. http://jersey.java.net/
2 Simple XML Serialization http://simple.sourceforge.net
3. Estado del arte
57
Simple XML funciona especificando anotaciones en los ficheros Java. Algunas
de las anotaciones que usa se encuentran en la Tabla 11.
Anotación Descripción @Root
Especifica el elemento raíz del fichero XML.
@Element
Especifica un elemento (un nodo) en el fichero XML.
@Attribute
Especifica un atributo en el nodo en el fichero XML.
@ElementArray Especifica un conjunto de elementos en el fichero XML que en el fichero Java estarán implementados mediante un array.
Tabla 11. Anotaciones usadas en Simple XML
3.8 Bluetooth
Bluetooth1 es una tecnología para las comunicaciones inalámbricas a corta
distancia. Tiene por objetivo reemplazar el cableado para conectar dispositivos a corta
distancia manteniendo la seguridad del cableado.
Tres de las ventajas de la comunicación de dispositivos mediante Bluetooth
frente a otras alternativas de comunicación inalámbrica son el bajo consumo, el bajo
coste y la ausencia de necesitar la misma línea visual entre los componentes que se
comunican.
Existe una gran variedad de dispositivos que pueden comunicarse mediante
Bluetooth: dispositivos móviles, dispositivos médicos, escáneres, impresoras, cámaras
digitales, etc.
La comunicación Bluetooth se realiza a través de una banda de frecuencia que
abarca desde 2.4 GHz hasta 2.485 GHz. Esta banda de frecuencia está libre y no
necesita licencia en la mayoría de los países.
1 Bluetooth SIG, Inc. http://www.bluetooth.com
3. Estado del arte
58
3.8.1 Perfiles Bluetooth
Para garantizar la interoperabilidad entre dispositivos la asociación Bluetooth
SIG (Bluetooth Special Interest Group) definió varios perfiles de Bluetooth. Un perfil
de Bluetooh es un conjunto de características funcionales que comparten todos los
dispositivos que disponen de ese perfil. Un dispositivo Bluetooth puede tener uno o
varios perfiles Bluetooth disponibles, pero para comunicarse varios dispositivos entre sí
han de hacerlo todos mediante el mismo perfil Bluetooth.
3.8.2 Protocolo de Descubrimiento de Servicios
El Protocolo de Descubrimiento de Servicios (SDP Service Discover Protocol)
le permite conocer a un dispositivo los servicios ofrecidos por el resto de dispositivos.
Cada servicio está identificado por una secuencia de bits llamada UUID (Universally
Unique IDentifier). Un UUID se puede definir mediante 16 bits (versión corta del
UUID) o mediante 128 bits (versión larga del UUID).
3.8.3 Dirección MAC de un dispositivo Bluetooth
La dirección MAC es una secuencia de 48 bits que identifica unívocamente a un
dispositivo. Las direcciones MAC se utilizan en varias tecnologías como Wi-Fi y
Bluetooth para identificar de forma unívoca a un dispositivo.
4 METODO DE TRABAJO
4. Método de trabajo
61
En el este capítulo se describe la metodología empleada en el análisis, diseño e
implementación de las aplicaciones desarrolladas en el presente proyecto.
Al utilizarse el paradigma de Orientación a Objetos, se ha empleado en el
proceso de desarrollo de las aplicaciones la metodología del Proceso Unificado de
Desarrollo (PUD) (Jacobson et al., 1999) así como el Lenguaje Unificado de Modelado
(UML) (Booch, 1998). También se han empleado varios patrones de diseño software.
4.1 Proceso Unificado de Desarrollo
Un proceso de desarrollo de software consiste en un conjunto de actividades que
trasforman los requisitos de un usuario en un sistema software. El PUD (Jacobson et al.,
2000) es más que un simple proceso de desarrollo software, conforma un marco de
trabajo genérico aplicable para una gran variedad de sistemas software (sistemas
software de diferentes áreas de aplicación, tamaños, aptitudes, organizaciones, etc.).
El objetivo principal del Proceso Unificado de Desarrollo es facilitar la creación
de software de la mayor calidad posible y que satisfaga las necesidades de los usuarios,
siempre dentro de los planes establecidos (Booch et al., 1999).
El PUD usa el lenguaje UML para preparar todos los esquemas de los sistemas
software (Jacobson et al., 1999).
4.1.1 Características del PUD
El PUD se caracteriza por estar dirigido por casos de uso, centrado en la
arquitectura y por ser iterativo e incremental. Se detallan a continuación cada una de
estas características.
Dirigido por casos de uso: los requisitos en el PUD se especifican en los casos
de uso. Un caso de uso es un fragmento de funcionalidad del sistema que proporciona al
usuario un resultado importante. Los casos de uso modelan los requisitos funcionales
4. Método de trabajo
62
del sistema. Todos los casos de uso juntos constituyen el modelo de casos de uso. Este
modelo no sólo se utiliza para la elaboración de la especificación de requisitos sino que
también es usado como fuente para el diseño, implementación y pruebas del sistema
software que se está desarrollando. De ahí la procedencia de la expresión "dirigido por
casos de uso".
Centrado en la arquitectura: El concepto de arquitectura software incluye los
aspectos estáticos y dinámicos más significativos del sistema. La arquitectura del
sistema surge de las necesidades de la organización, tal y como las perciben los usuarios
y resto de personal a nivel funcional. Pero la arquitectura también se ve influenciada por
otros factores ajenos a los requisitos funcionales. El PUD asume que no existe un
modelo único que pueda cubrir todas las necesidades del sistema. Por ello existen
múltiples modelos y vistas que definen la arquitectura de software de un sistema.
Iterativo e incremental: Para facilitar el desarrollo y la gestión de un proyecto
software es práctico dividirlo en subproyectos más pequeños. Se divide el desarrollo de
un proyecto software en "iteraciones". En cada una de estas iteraciones se llevan a cabo
tareas de análisis de requisitos, diseño, implementación y pruebas, de forma que,
acabada la iteración, se obtiene un sistema ejecutable probado e integrado con los
sistemas desarrollados en las iteraciones anteriores. Este sistema ejecutable resultante de
la finalización de una iteración se considera un una nueva versión, un "incremento" del
sistema software final que se ha de desarrollar.
4.1.2 Estructura del PUD
El PUD se compone de cuatro fases: Comienzo, Elaboración, Construcción y
Transición.
Comienzo: Se planifica el proyecto. Se establece el ámbito, los recursos
necesarios, una arquitectura provisional y un modelo de casos de uso simplificado con
los casos de uso más críticos. También se identifican y priorizan los riesgos más
importantes.
4. Método de trabajo
63
Elaboración: Se detallan la mayoría de los casos de uso y se diseña la línea base
de la arquitectura. Al finalizar la fase, el responsable del proyecto está en condiciones
de estimar los recursos necesarios y planificar los hitos del proyecto.
Construcción: Se desarrolla el producto. Al finalizar la fase, el producto tiene
implementados todos los casos de uso.
Transición: Se garantiza que el producto software esté listo para ser entregado
al cliente. El producto se convierte en versión beta. Un número reducido de usuarios lo
prueba e informa de defectos y deficiencias. Se corrigen los defectos del producto y se
proporciona una línea de ayuda y asistencia al cliente.
Cada una de estas cuatro fases se estructura a su vez en una serie de disciplinas
que recuerdan a las definidas en el ciclo de vida clásico o en cascada: Elicitación de
Requisitos, Análisis de Requisitos, Diseño, Implementación y Pruebas. Aunque todas
las iteraciones del proceso de desarrollo suelen incluir trabajo en casi todas las
disciplinas; el grado de esfuerzo de cada una de ellas varía a lo largo del proyecto
dependiendo del número de iteración y de la fase en la que se encuentre el proceso. Tal
situación queda ilustrada en la Figura 15.
Figura 15. Estructura del PUD
4. Método de trabajo
64
4.2 Patrones de diseño
Un patrón de diseño software es una solución reutilizable, comprobada y eficaz a
un problema común de diseño software.
Los patrones de diseño según (Gamma et al., 1995) se clasifican en:
• Patrones de creación: abstraen el proceso de creación de instancias.
• Patrones estructurales: permiten describir cómo combinar las
estructuras y los objetos para formar estructuras más grandes.
• Patrones de comportamiento: describen la comunicación entre varios
objetos.
4.2.1 Patrones utilizados
Se describen a continuación los patrones de diseño utilizados en el desarrollo del
proyecto:
• MVC (Modelo-Vista-Controlador). MVC es un patrón de desarrollo
software que consiste en separar el software en tres capas: modelo (datos
y lógica de negocio), vista (interfaz de usuario) y controlador (lógica
correspondiente a las acciones que se han desencadenar dependiendo de
los eventos que se produzcan sobre la interfaz de usuario). La principal
ventaja del MVC consiste en que se separan los datos y la lógica de
negocio de la capa de vista. El MVC fue creado en 1979 por Trygve
Reenskaug para Smalltalk (Reenskaug, T., 1979). Las pasos que se
producen en el MVC son (Ver Figura 16):
1. El usuario interacciona con la interfaz de la aplicación (la capa
de Vista).
2. La interfaz de usuario manda un evento al Controlador.
3. El Controlador dependiendo del evento recibido manda una
acción determinada a la capa de modelo en respuesta a ese
evento.
4. En la capa de modelo se ejecuta la lógica de negocio de la
aplicación según la acción mandada por el Controlador. Se
4. Método de trabajo
65
puede producir un cambio en el estado del modelo (un cambio
en los datos del modelo).
5. La capa de modelo notifica el cambio de su estado al
Controlador.
6. Se actualiza la vista con los cambios producidos en el modelo.
Puede que se genere una nueva vista. La interfaz de usuario
quedaría a la espera de una próxima interacción del usuario
repitiéndose este ciclo.
Figura 16. Pasos del MVC
• DAO (Data Access Object): Los Objetos de Acceso a Datos se encargan
de las operaciones de persistencia de los objetos de negocio. Tienen la
ventaja de que los objetos de negocio no requieren conocimiento directo
del destino final de la información que manipulan.
• Singleton (instancia única): Consiste en que en una determinada clase
sólo se va a instanciar un único objeto. Sirve para garantizar que una
clase sólo tenga una sola instancia y proporcionar un punto de acceso
global a ella.
• Locator: Las clases Locator permiten acceder a determinados recursos
de manera uniforme y recuperarlos listos para utilizar. En el proyecto se
4. Método de trabajo
66
usan para recuperar el DAO asociado a un determinado objeto de
negocio.
• Alta cohesión: La cohesión en una clase es la medida de cuán
relacionadas y enfocadas están las responsabilidades de esa clase. Una
alta cohesión provoca que las clases con responsabilidad estrechamente
relacionadas no realicen un trabajo enorme (Larman, 2002).
• Bajo acoplamiento: El acoplamiento de una clase es la medida que
indica el grado de dependencia de esa clase con respecto al resto. Una
clase con bajo acoplamiento no depende de muchas otras. Si el
acoplamiento es alto, la clase recurrirá a muchas otras clases para
cumplir su propósito (Larman, 2002).
5 RESULTADOS
5. Resultados
69
5.1 Requisitos
5.1.1 Especificación de requisitos
La aplicación móvil tendrá como objetivos la toma de datos del paciente
(mediciones de signos vitales, alimentación, actividades desarrolladas y medicación
tomada), la transmisión de estos datos al servicio web y la visualización de
recomendaciones para el usuario paciente según los datos suministrados por el paciente
que procese la aplicación.
El servicio web realizará la función de interlocutor entre la aplicación móvil y la
base de datos que usará el sistema. Es decir, realizará la función de servidor remoto de
la base de datos para la aplicación móvil.
La aplicación web permitirá a los médicos registrar nuevos pacientes, modificar
los datos de los pacientes introducidos y ver la información de seguimiento almacenada
de sus pacientes.
5.1.1.1 Requisitos funcionales de la aplicación móvil
En la Tabla 12 se presenta la lista de requisitos funcionales de la aplicación
móvil.
Código Requisito Funcional Descripción RF01 Asociar paciente a la aplicación móvil El objetivo de este requisito
funcional consiste en la asociación de un paciente en la aplicación móvil registrado en el sistema. Nota: se registran nuevos pacientes en el sistema desde la aplicación web.
RF02 Carga de datos del sistema. Este requisito funcional consiste en la carga inicial de datos de catálogos del sistema dentro de la aplicación móvil.
RF03 Obtención de las mediciones El objetivo de este requisito funcional consiste en la obtención de los valores de las mediciones realizadas por el paciente suministradas por los
5. Resultados
70
sensores biométricos que use el usuario paciente o bien las que especifique el usuario paciente manualmente.
RF04 Introducción de los datos relativos a la vida del paciente que influyan en su salud.
Los objetivos de este requisito funcional son permitir introducir en la aplicación: - Las actividades que realiza
el paciente (andar, correr, ver la tele)
- La medicación que está tomando el paciente
- La alimentación que está ingiriendo el paciente.
- Los síntomas que esté experimentando el paciente
RF05 Sincronización de la información con el servidor remoto La aplicación puede almacenar temporalmente información que transmitirá al servidor remoto cuando tenga oportunidad de hacerlo. Si la aplicación móvil no tuviera en algún momento acceso a Internet la información ha de almacenarse temporalmente para que cuando sí tenga acceso pueda ser transmitida al servidor remoto. La aplicación también permitirá actualizar sus datos internos con respecto a la última versión que exista en la base de datos del servidor remoto.
RF06 Visualización de recomendaciones al paciente La aplicación mostrará recomendaciones al usuario paciente según los datos que éste introduzca en el sistema (mediciones, actividades, medicación, síntomas, etc.).
RF07 Visualización de últimos datos introducidos La aplicación mostrará al paciente los últimos datos introducidos en la aplicación con una antigüedad de una semana.
Tabla 12. Requisitos funcionales de la aplicación móvil
5.1.1.2 Requisitos funcionales de la aplicación web
En la Tabla 13 se presenta el listado de requisitos funcionales de la aplicación
web.
5. Resultados
71
Código Requisito Funcional Descripción RF21 Autenticación del usuario correspondiente al rol médico El objetivo de este requisito
funcional consiste en que la aplicación debe permitir autenticar al usuario con perfil médico.
RF22 Registro de un nuevo paciente Mediante este requisito funcional se podrán registrar nuevos pacientes en el sistema.
RF23 Modificación de los datos de un paciente registrado Mediante este requisito funcional se podrán modificar los datos de un paciente ya registrado en el sistema.
RF24 Selección del paciente. El objetivo de este requisito funcional consiste en la selección de un paciente asociado al médico logado en la aplicación mediante criterios de búsqueda y posterior selección de uno de los resultados asociados a esos criterios de búsqueda.
RF25 Ver datos de paciente El médico podrá ver la información que existe en el sistema del paciente seleccionado así como gráficas obtenidas a partir de esa información.
RF26 Asignación/Desasignación de enfermedades al paciente Mediante este requisito funcional se le podrán asignar y desasignar enfermedades a un paciente
Tabla 13. Requisitos funcionales de la aplicación web
5.1.1.3 Requisitos funcionales del servicio web
En la Tabla 14 se presentan los requisitos funcionales del servicio web.
Código Requisito Funcional Descripción RF41 Añadir datos recibidos procedentes de la aplicación
móvil El objetivo de este requisito funcional consiste en que el servicio web debe añadir los datos recibidos de la aplicación móvil a la base de datos
RF42 Recuperar datos solicitados por la aplicación móvil El objetivo de este requisito funcional consiste en que el servicio web debe recuperar los datos de la base de datos central que le solicite la aplicación móvil para posteriormente enviárselos.
Tabla 14. Requisitos funcionales del servicio web
5. Resultados
72
5.1.2 Casos de uso
Se describe a continuación la funcionalidad de cada uno de los requisitos
funcionales así como la relación entre los requisitos funcionales y los casos de uso que
formarán parte de cada aplicación. De esta forma, se puede conocer qué casos de uso
realizan las funcionalidades descritas por los requisitos funcionales.
5.1.2.1 Casos de uso de la aplicación móvil
Se muestran los casos de uso correspondientes a los requisitos funcionales de la
aplicación móvil en la Tabla 15.
Requisito Funcional Caso de Uso Breve descripción del Caso de
Uso RF01 (Asociar paciente a la
aplicación móvil) CU-01 Asociar paciente a la aplicación móvil
Mediante este caso de uso se podrá asociar un paciente previamente registrado en el sistema a la aplicación móvil.
RF02 (Carga de datos del sistema)
CU-02 Carga de datos del sistema
Mediante este caso de uso se cargarán los datos del sistema en la aplicación móvil
CU-03 Introducir medición Este caso de uso se encarga de introducir las mediciones de las señales biométricas del paciente en el sistema.
CU-04 Obtener medición mediante sensor biométrico
Este caso de uso se encarga de obtener las mediciones proporcionadas por los sensores biométricos mediante comunicación Bluetooth.
RF03 (Obtención de las mediciones)
CU-05 Obtener medición manualmente
Este caso de uso se encarga de leer las mediciones especificadas de forma manual por el propio paciente
CU-06 Introducir alimentación Este caso de uso permite la introducción de los alimentos que está ingiriendo el paciente.
CU-07 Introducir actividad Mediante este caso de uso el paciente puede introducir en la aplicación móvil las actividades que está realizando que él considere representativas para el seguimiento de su salud.
RF04 (Introducción de los datos relativos a la vida del paciente
que influyan en su salud)
CU-08 Introducir medicación Por medio de este caso de uso el paciente puede indicar en la aplicación móvil la medicación que está tomando.
5. Resultados
73
CU-09 Introducir síntoma Por medio de este caso de uso el paciente puede indicar en la aplicación móvil los síntomas que está experimentando.
RF05 (Sincronización de la información con el servidor)
CU-10 Sincronizar información con el servidor remoto
Este caso de uso permite la sincronización de la información de la aplicación móvil con el servidor remoto.
RF06 (Visualización de recomendaciones al paciente)
CU-11 Mostrar recomendaciones al usuario
Este caso de uso se encarga de mostrar recomendaciones al usuario según los datos que éste introduzca o haya introducido en el sistema
RF07 (Visualización de últimos datos introducidos)
CU-12 Mostrar histórico Mediante este caso de uso el usuario paciente puede ver los últimos datos introducidos en la aplicación móvil con una antigüedad menor a una semana.
Tabla 15. Casos de uso de la aplicación móvil
5.1.2.2 Casos de uso de la aplicación web
Se muestran los casos de uso correspondientes a los requisitos funcionales de la
aplicación móvil en la Tabla 16.
Requisito Funcional Caso de Uso Breve descripción del Caso de
Uso RF21 (Autenticación del usuario correspondiente al rol médico)
CU-21 Autenticar usuario Este caso de uso se encarga de pedir credenciales al usuario con rol de médico para autentificarlo con respecto al sistema.
RF22 (Registro de un nuevo paciente)
CU-22 Registrar nuevo paciente Este caso de uso se encarga de registrar un nuevo paciente en el sistema.
RF23 (Selección del paciente) CU-23 Seleccionar paciente Mediante este caso de uso el usuario con perfil de médico puede seleccionar un paciente de entre todos los que tenga utilizando criterios de acotación para ser luego utilizado en el resto de casos de uso de la aplicación web.
5. Resultados
74
RF24 (Modificación de los datos personales de un paciente
registrado)
CU-24 Actualizar datos personales del paciente
Este caso de uso se encarga de actualizar los datos personales de un paciente ya registrado que hubieran cambiado con respecto a los que se encuentran en el sistema. Por ejemplo, que el paciente hubiera cambiado de domicilio, número de teléfono, etc.
RF25 (Ver datos del paciente) CU-25 Ver información de seguimiento del paciente
Este caso de uso se encarga por un lado de mostrar en una gráfica las mediciones del paciente en una determinada semana como de mostrar la información relativa (medicaciones tomadas, alimentación y actividad realizada) al paciente en un determinado día de esa semana seleccionado por el usuario.
RF26 (Asignación/Desasignación de
enfermedades al paciente)
CU-26 Asignar/Desasignar enfermedades a paciente
Mediante este caso de uso se podrán asignar y desasignar enfermedades al paciente.
Tabla 16. Casos de uso de la aplicación web
5.1.2.3 Casos de uso del servicio web
Se muestran los casos de uso correspondientes a los requisitos funcionales del
servicio web en la Tabla 17.
5. Resultados
75
Requisito Funcional Caso de Uso Breve descripción del Caso de Uso
RF41 (Añadir datos recibidos procedentes de la aplicación
móvil)
CU-41 Añadir datos de seguimiento del paciente
Este caso de uso se encarga de insertar los datos del paciente enviados por aplicación móvil al servicio web.
CU-42 Recibir datos nuevos o actualizados de catálogos del sistema
Este caso de uso se encarga de enviar a la aplicación móvil los datos de catálogos que hayan sido modificados o creados de la base de datos central.
RF42 (Recuperar datos solicitados por la aplicación
móvil)
CU-43 Obtener datos personales del paciente
Este caso se encarga de enviar a la aplicación móvil los datos de un paciente de la base de datos central.
Tabla 17. Casos de uso del servicio web
5.1.3 Diagramas de Casos de Uso
El sistema a desarrollar está formado por tres aplicaciones: aplicación móvil,
aplicación web y servicio web. Se muestran los diagramas de Casos de Uso de cada una
de las aplicaciones en la Figura 17 (aplicación móvil), la Figura 18 (aplicación web) y la
Figura 19 (servicio web).
En los diagramas también pueden verse los actores que se van a usar el sistema.
Un actor es una entidad externa (de fuera del sistema) que interacciona con el sistema
participando en el caso de uso y normalmente iniciándolo.
Los actores identificados son los siguientes:
• Paciente: interactúa con la aplicación móvil. Introducen las mediciones,
síntomas experimentados, medicación tomada, etc. en la aplicación móvil
y la envían al sistema a través de ésta.
• Médico: interactúa con la aplicación web. Registran nuevos pacientes en
el sistema, actualizan sus datos y revisan la información que mandan los
pacientes para seguir sus enfermedades.
• Técnico: se encarga de la instalación, la carga de datos y la asignación
del usuario paciente en la aplicación móvil con el objetivo de que la
5. Resultados
76
aplicación esté lista para ser usada por los usuarios pacientes. Estas
tareas son muy técnicas para un usuario paciente.
• Aplicación móvil: la aplicación móvil interactúa con el servicio web. La
aplicación móvil no tiene acceso a la base de datos central del sistema,
por lo que ha de delegar la inserción y recuperación de datos de la base
de datos central en el servicio web. La aplicación móvil es una entidad
que forma parte del sistema, pero a su vez es una entidad externa al
subsistema formado por el servicio web, por lo que sería considerado un
actor para obtener sus casos de uso.
Figura 17. Diagrama de casos de uso de la aplicación móvil
5. Resultados
77
Figura 18. Diagrama de casos de uso de la aplicación web
Figura 19. Diagrama de casos de uso del servicio web
5.2 Análisis
5.2.1 Priorización de los casos de uso
Una vez identificados todos los casos de uso que forman parte del sistema, se
priorizan asignando cada uno de ellos a una iteración (Tabla 18).
Aplicación Caso de Uso Iteración
Aplicación web CU-21 Autenticar usuario 1
Aplicación web CU-22 Registrar nuevo paciente 1 Servicio web CU-43 Obtener datos personales del paciente 1
Aplicación móvil CU-02 Carga de datos del sistema 1 Aplicación móvil CU-01 Asociar paciente a la aplicación móvil 1 Aplicación web CU-23 Seleccionar paciente 2 Aplicación web CU-24 Actualizar datos personales del paciente 2
5. Resultados
78
Aplicación móvil CU-03 Introducir medición 2 Aplicación móvil CU-04 Obtener medición mediante sensor biométrico 2 Aplicación móvil CU-05 Obtener medición manualmente 2 Aplicación móvil CU-06 Introducir alimentación 3 Aplicación móvil CU-07 Introducir actividad 3 Aplicación móvil CU-08 Introducir medicación 3 Aplicación móvil CU-09 Introducir síntoma 3
Servicio web CU-41 Añadir datos de seguimiento del paciente 4 Servicio web CU-42 Recibir datos nuevos o actualizados de catálogos
del sistema 4
Aplicación móvil CU-10 Sincronizar información con el servidor remoto 4 Aplicación web CU-25 Ver información de seguimiento del paciente 5
Aplicación móvil CU-11 Mostrar recomendaciones al usuario 6 Aplicación móvil CU-12 Mostrar histórico 7
Tabla 18. Priorización de los casos de uso
En la primera iteración se consideran los casos de uso correspondientes a las
primeras acciones en las aplicaciones móvil y web:
• CU-21 Autenticar usuario: La autenticación de usuarios en la
aplicación web para que quede asignado el médico en la aplicación.
• CU-22 Registrar nuevo paciente: El registro del nuevo paciente en el
sistema. Cada nuevo paciente que vaya a usar el sistema ha de
registrarse mediante la funcionalidad de este caso de uso.
• CU-43 Obtener datos personales del paciente: La obtención de los
datos personales del paciente en el servicio web. Este caso de uso es
usado por el caso de uso ‘CU-01 Asociar paciente a la aplicación móvil’
de la aplicación móvil para comprobar que los datos del paciente son los
correctos.
• CU-02 Carga de datos del sistema: La carga de datos del sistema en la
aplicación móvil. Al instalarse la aplicación móvil, no tiene ningún dato
de catálogos (alimentos seleccionables, medicamentos, sensores
biométricos, etc.) cargado en la aplicación. Mediante la funcionalidad
5. Resultados
79
descrita en este caso de uso, la aplicación móvil carga los datos de
catálogos del sistema.
• CU-01 Asociar paciente a la aplicación móvil: La asignación del
paciente en la aplicación móvil. La aplicación móvil sólo gestiona un
solo paciente. Este caso de uso se encarga de asociar el paciente asociado
a la instancia de la aplicación en el móvil.
En la segunda iteración se consideran los casos de uso para modificar los datos
personales del paciente en la aplicación web y los casos de uso para introducir
mediciones en la aplicación móvil:
• CU-23 Seleccionar paciente: Este caso de uso permite seleccionar un
paciente de entre los que tenga asociado el médico para trabajar con él.
Este caso de uso es previo a los casos de uso ‘CU-24 Actualizar datos
personales del paciente’ y ‘CU-25 Ver información de seguimiento del
paciente’ porque para poder modificar los datos personales de un
paciente y para ver la información de seguimiento de un paciente ha de
seleccionarse uno antes.
• CU-24 Actualizar datos personales de un paciente: Este caso de uso
permite modificar los datos personales de un paciente en el sistema.
• CU-03 Introducir medición: Este caso de uso permite seleccionar el
tipo de medición que el usuario va a introducir en la aplicación móvil.
• CU-04 Obtener medición mediante sensor biométrico: Este caso de
uso permite recibir una medición mediante un sensor biométrico que se
encuentre parametrizado en el sistema.
• CU-05 Obtener medición manualmente: La funcionalidad
correspondiente a este caso de uso permite introducir una medición en la
5. Resultados
80
aplicación directamente. Es decir, especificando manualmente el valor de
la medición en la aplicación.
En la tercera iteración se implementan los casos de uso de la aplicación móvil
que permiten al usuario paciente introducir información de seguimiento: CU-06
Introducir alimentación, CU-07 Introducir actividad, CU-08 Introducir
medicación y CU-09 Introducir síntoma.
En la cuarta iteración se implementan los casos de uso del servicio web y de la
aplicación móvil correspondientes a la sincronización de los datos entre la aplicación
móvil y la base de datos central del sistema. Esta base de datos es accesible a la
aplicación móvil mediante el servicio web. Es decir, la aplicación móvil añade y
recupera datos de la base de datos central del sistema a través del servicio web:
• CU-41 Añadir datos de seguimiento del paciente: Mediante la
funcionalidad de este caso de uso el servicio web puede insertar los datos
de seguimiento que recibe de la aplicación móvil.
• CU-42 Recibir datos nuevos o actualizados de catálogos del sistema:
El servicio web le manda los datos de catálogos que necesita insertar y
actualizar la aplicación móvil en sus datos de catálogos internos.
• CU-10 Sincronizar información con el servidor remoto: Esta es la
funcionalidad por la que la aplicación móvil envía los datos de
seguimiento del paciente que tuviera pendientes de enviar al servicio web
y además, recibe los datos de catálogos que tuviera que crear y actualizar
en sus datos internos.
En la quinta iteración se implementa el caso de uso ‘CU-25 Ver información
de seguimiento del paciente’. Mediante este caso de uso el médico puede ver los datos
de seguimiento que el paciente ha especificado en la aplicación móvil. También puede
ver gráficas asociadas a las mediciones de los parámetros vitales del paciente.
5. Resultados
81
En la sexta iteración se implementa el caso de uso ‘CU-11 Mostrar
recomendaciones al usuario’. Mediante este caso de uso el usuario puede recibir
recomendaciones al especificar alguna medición, alimento, medicamento, síntoma, etc.
en la aplicación móvil.
En la séptima y última iteración se implementa el caso de uso ‘CU-12 Mostrar
histórico’ encargado de mostrar los datos de seguimiento que se ha introducido el
paciente en la aplicación móvil en la última semana.
5.2.2 Descripción de los casos de uso más representativos
En este apartado se muestran los casos de uso más representativos del sistema.
El listado completo de todos los casos de uso se encuentra en el Anexo B. Descripción
de los casos de uso.
5.2.2.1 Descripción de los casos de uso más representativos de la aplicación móvil
• CU-03 Introducir medición Caso de Uso: CU-03 Introducir medición Breve descripción: Este caso de uso se encarga de introducir los valores de la medición en la aplicación. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medición’ en el menú principal de la aplicación. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de lista desplegable ‘Tipo de medida’ con los valores ‘Tensión arterial’, ‘Temperatura corporal’ y ‘Glucosa en sangre’. El desplegable no tendrá un valor vacío y tendrá el valor por defecto ‘Tensión arterial’.
• Campo de lista desplegable ‘Modo de obtención’ con los valores ‘Manual’ y ‘Mediante sensor’. El desplegable no tendrá un primer valor por defecto vacío y tendrá el valor por defecto
5. Resultados
82
‘Manual’. • Botón ‘Aceptar’. Para aceptar los valores especificados en los campos de listas desplegables. • Botón ‘Atrás’. Para volver al menú principal de la aplicación.
2.- El usuario selecciona valores en las listas desplegables dejando especificado el valor ‘Manual’ en el campo ‘Modo de obtención’ y pulsa el botón ‘Aceptar’. 3.- Comienza la ejecución del caso de uso CU-05 Obtener medición manualmente. Postcondiciones: 1.- Queda especificados el tipo de medida y el modo de obtenerla. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ habiendo especificado el valor ‘Mediante sensor’ en el desplegable ‘Modo de obtención’.
2.1.- Comienza la ejecución del caso de uso CU-04 Obtener medición mediante sensor biométrico.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- Se accede al menú principal de la aplicación.
• CU-04 Obtener medición mediante sensor biométrico Caso de Uso: CU-04 Obtener medición mediante sensor biométrico Breve descripción: Este caso de uso se encarga de recoger los valores de la medición en la aplicación mediante un sensor biométrico (tensiómetro, glucómetro, termómetro, etc.). Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medición’ en el menú principal de la aplicación. 4.- El usuario ha de haber seleccionado el valor ‘Mediante sensor’ en el campo desplegable ‘Modo de obtención’ en la ejecución del caso de uso CU-03 Introducir medición. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de lista desplegable ‘Sensor’ con los sensores que haya disponibles en la aplicación para el tipo de medición que hubiera especificado el usuario en la ejecución del caso de uso CU-03 Introducir medición.
• Botón ‘Aceptar’. • Botón ‘Atrás’.
5. Resultados
83
2.- El usuario selecciona un sensor y pulsa el botón ‘Aceptar’. 3.- Aparece una ventana emergente bloqueante indicando que la aplicación está a la espera de recibir la medición. 4.- El usuario realiza la medición con el sensor biométrico. 5.- La aplicación lee los valores de la medición enviados por el sensor biométrico y almacenan el/los valor/es de la medición. Finalizaría la ejecución de este caso de uso y comenzaría la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones: 1.- Los valores de la medición quedan almacenados en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ sin seleccionar ningún valor en el listado desplegable de sensores.
2.1.- La aplicación muestra un mensaje indicando que se ha de seleccionar un sensor. Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- La aplicación finalizaría la ejecución de este caso de uso y del caso de uso CU-02 Introducir medición. Se mostraría el menú principal de la aplicación.
Flujo alternativo 3: 4.- El usuario durante un tiempo prudencial no realiza ninguna medición con el sensor que ha especificado.
4.1.- La aplicación muestra un mensaje indicando que no se ha recibido ninguna medición del sensor especificado.
• CU-05 Obtener medición manualmente Caso de Uso: CU-05 Obtener medición manualmente Breve descripción: Este caso de uso se encarga de recoger del usuario los valores de la medición que ha obtenido el paciente de un sensor biométrico que no puede comunicarse con la aplicación. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medición’ en el menú principal de la aplicación. 4.- El usuario ha de haber seleccionado el valor ‘Manual’ en el campo desplegable ‘Modo de obtención’
5. Resultados
84
en la ejecución del caso de uso CU-03 Introducir medición. Flujo principal: 1.- La aplicación muestra los siguientes elementos dependiendo del valor seleccionado en el campo desplegable ‘Tipo de medida’ de la ejecución del caso de uso CU-03 Introducir medición:
• Campos asociados al tipo de medida seleccionado por el usuario en el caso de uso CU-03 Introducir medición. Según el valor se mostrarán unos campos u otros. Estos campos son obligatorios de cumplimentar por el usuario. Se valores especificados en los campos se validarán para evitar que se especifiquen tanto valores inválidos como valores imposibles (Ejemplos: una presión arterial negativa, una temperatura de 10 ºC, etc.) Casos posibles:
o Valor ‘Tensión arterial’: Campo de texto ‘Presión diastólica’. Campo de texto ‘Presión sistólica’.
o Valor ‘Temperatura corporal’ Campo de texto ‘Temperatura corporal’
o Valor ‘Glucosa en sangre’: Campo de texto ‘Glucosa en sangre’.
• Botón ‘Aceptar’. Para almacenar en la aplicación los valores de la medición y comenzar el caso de uso CU-11 Mostrar recomendaciones al usuario.
• Botón ‘Atrás’. Para finalizar la ejecución de este caso de uso y comenzar la ejecución del caso de uso CU-03 Introducir medición.
Todos los campos de texto son obligatorios de cumplimentar. 2.- El usuario especifica valores en los campos de texto y pulsa el botón ‘Aceptar’. 3.- Se almacenan el/los valor/es de la medida, finalizaría la ejecución de este caso de uso y comenzaría la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones: 1.- La medición queda almacenada en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ sin seleccionar especificar un valor en alguno de los campos de texto.
2.1.- La aplicación muestra un mensaje indicando que los campos son obligatorios. Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- La aplicación finaliza la ejecución de este caso de uso y la del CU-02 Introducir medición. Se mostraría el menú principal de la aplicación.
Flujo alternativo 3: 2.- El usuario especifica un valor inválido en alguno de los campos y pulsa el botón ‘Aceptar’.
2.1.- La aplicación muestra un mensaje indicando la situación inválida.
• CU-08 Introducir medicación Caso de Uso: CU-08 Introducir medicación Breve descripción: En este caso de uso el paciente introduce en el sistema la medicación que está tomando. Precondiciones:
5. Resultados
85
1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medicamentos’ en el menú principal de la aplicación. Flujo principal: 1.-Aparecerá una pantalla en la que se encontrarán los siguientes elementos: - Campo autocompletado ‘Medicamento’: en este campo se podrá introducir el medicamento. La aplicación completará texto del medicamento en el campo introduciendo varios caracteres en él. - Campo ‘Hora’. En este campo se introducirá la hora de la toma del medicamento con el formato HH:MM, siendo HH la hora en modo AM y MM los minutos de 00 a 59. - Botón con imagen de reloj al lado derecho del campo ‘Hora’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una hora en el campo ‘Hora’. - Campo ‘Día’. En este campo se introducirá la fecha (día, mes y año) en la que se produjo la toma del medicamento con el formato DD-MM-YYYY (siendo DD el día de 1 a 31, MM el mes de 1 al 12 e YYYY el año con cuatro dígitos). - Botón con imagen de un calendario al lado derecho del campo ‘Día’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una fecha para el campo ‘Día’. - Campo de barra deslizante ‘Dosis’. En este campo se introducirá las dosis tomadas del medicamento. Los valores de la barra deslizante empezarán en una dosis y terminarán en diez dosis. El valor seleccionado por defecto en la barra será una dosis. - Botón ‘Introducir medicamento’. Almacena el medicamento. - Botón ‘Atrás’. Pulsándolo se accede al menú principal de la aplicación. 2.- El usuario pulsa el botón ‘Introducir medicamento’. 3.- Se almacena el medicamento, si el día y la hora especificados por el usuario son posteriores a la hora del sistema más 10 minutos finaliza la ejecución de este caso de uso y se accede al menú principal. Si el día y la hora especificados por el usuario son anteriores a la hora del sistema más diez minutos finaliza la ejecución del caso de uso y comienza la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones:
1. El medicamento introducido queda almacenado. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 2.- El usuario introduce un valor inválido en el campo ‘Día’ y pulsa el botón ‘Introducir medicamento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Día’. Flujo alternativo 3: 2.- El usuario introduce un valor inválido en el campo ‘Hora’ y pulsa el botón ‘Introducir medicamento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Hora’.
Flujo alternativo 5: 2.- El usuario introduce pulsa el botón ‘Introducir medicamento’ estando alguno de estos campos sin cumplimentar: ‘Día’, ‘Hora’, ‘Medicamento’.
5. Resultados
86
2.1.- Se muestra un mensaje indicando que los campos ‘Medicamento’, ‘Día’ y ‘Hora’ son campos obligatorios.
• CU-10 Sincronizar información con el servidor remoto Caso de Uso: CU-10 Sincronizar información con el servidor remoto Breve descripción: Este caso de uso permite la sincronización de la información de la aplicación móvil con el servidor remoto. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- Se debe haber seleccionado la opción ‘Sincronizar’ desde el menú principal. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Botón ‘Sincronizar datos’. Para comenzar el proceso de sincronización. • Botón ‘Atrás’. Para volver al menú principal de la aplicación.
2.- El usuario pulsa el botón ‘Sincronizar datos’. 3.- La aplicación detecta que existe conexión a Internet disponible. Muestra una ventana emergente bloqueante con una imagen animada de espera (indicando que la aplicación está procesando datos) y con el mensaje ‘Enviando los datos y actualizando los datos internos de la aplicación. Por favor, espere...’. La aplicación realiza las siguientes operaciones:
• Establece conexión con el servidor remoto. • Envía los datos de seguimiento del paciente que no hayan sido enviados (mediciones,
actividades, alimentos, medicación y síntomas). Los que ya se hubieran enviado, no se envían.
• Elimina los datos que ha enviado al servidor remoto y tienen más de una semana de antigüedad.
• Recupera los datos de catálogos que hayan sido creados o modificados en el servidor remoto después de la última sincronización. Es decir, se recuperan los datos de catálogos que hayan sido creados o modificados en el servidor remoto pero no hayan sido creados en la aplicación móvil, o se encuentren creados pero tengan valores desactualizados.
• Actualiza los datos recuperados en la operación anterior. • Recupera los datos que hayan sido creados en el servidor remoto y no existan en la
aplicación. • Crea los datos recuperados en la operación anterior. • Hace desaparecer la ventana emergente bloqueante con la imagen animada de espera. • Muestra el mensaje ‘Datos enviados con éxito. Aplicación actualizada con éxito’
indicando que la operación de sincronización se ha realizado correctamente. Los datos correspondientes al seguimiento del paciente que se enviarán al servicio web corresponden a:
5. Resultados
87
o Valores de mediciones Tensión arterial Temperatura corporal Glucosa en sangre
o Actividades realizadas o Alimentos ingeridos o Medicamentos tomados o Síntomas experimentados
Los catálogos de los que se comprobará si se han creado o modificado registros desde la última fecha de sincronización de la aplicación móvil son: o Sensores o Tipos de sensores o Enfermedades o Clases de enfermedades o Mensajes de recomendación asociados a rangos de medición de temperatura corporal o Mensajes de recomendación asociados a rangos de medición de tensión arterial o Mensajes de recomendación asociados a rangos de medición de glucosa en sangre o Síntomas o Mensajes de recomendación asociados a síntomas o Actividades o Mensajes de recomendación asociados a actividades o Medicamentos o Mensajes de recomendación asociados a medicamentos o Alimentos o Clases de alimentos o Subclases de alimentos o Mensajes de recomendación asociados a alimentos
4.- El usuario pulsa el botón ‘Atrás’. 5.- Finaliza la ejecución del caso de uso y se muestra el menú principal de la aplicación. Postcondiciones: 1.- La aplicación envía los datos al servidor remoto que tuviera pendientes de envío. 2.- La aplicación actualiza los datos que tuviera desactualizados con respecto a los del servidor remoto. 3.- La aplicación crea los datos que existieran en el servidor remoto y no estuvieran en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’. 2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 3.- La aplicación detecta que no existe conectividad con Internet. 3.1.- Se muestra el mensaje al usuario indicando que no existe conectividad con Internet con lo que no puede sincronizarse la información con el servidor remoto. Flujo alternativo 3: 3- La aplicación detecta que se ha producido un error en la sincronización de datos.
3.1.- Se muestra un mensaje al usuario indicando el error.
• CU-11 Mostrar recomendaciones al usuario
5. Resultados
88
Caso de Uso: CU-11 Mostrar recomendaciones al usuario Breve descripción: Este caso de uso se encarga de mostrar recomendaciones al usuario según los datos que éste introduzca en el sistema. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha introducido un elemento en la aplicación mediante alguno de estos casos de uso: CU-04 Obtener medición mediante sensor biométrico, CU-05 Obtener medición manualmente, CU-06 Introducir alimentación, CU-07 Introducir actividad, CU-08 Introducir medicación, CU-09 Introducir síntoma. Flujo principal: 1.- La aplicación muestra una ventana emergente bloqueante con una imagen animada de espera (significando que la aplicación está procesando datos) y con el mensaje ‘Obteniendo recomendaciones. Por favor, espere…’. 2.- La aplicación busca recomendaciones atendiendo a los siguientes criterios:
o El tipo de dato que se ha introducido: alimento, medicación, síntoma, actividad, medición. o El tipo de medición, en el caso de que se hubiera introducido una medición. o El rango de valores en el que se encuentre el valor introducido en el caso de que lo que se
hubiera introducido hubiera sido una medición. o A la clase o categoría de elemento al que pertenezca el elemento introducido si aplicase
alguna (clase y tipo de alimento, código ATC del medicamento, etc.). Una vez se han recuperado las recomendaciones que están asociadas al elemento que ha introducido el usuario, para cada una de las recomendaciones recuperadas se comprueba que tiene sentido ser mostrada teniendo en cuenta los siguientes factores:
o Los datos personales del paciente: enfermedades, altura, peso, si es fumador, etc. o Los datos que se hubieran introducido anteriormente.
Estos factores que indican si una recomendación tiene sentido ser mostrada se especificarán mediante una sentencia SQL que puede tener asociada la recomendación. Esta sentencia SQL siempre recuperará el número de elementos que se encuentran en un determinado estado en un momento particular. Si la recomendación no tiene asociada ninguna sentencia SQL entonces se muestra la recomendación directamente. Si la recomendación tiene asociada una sentencia SQL entonces para que se muestre la recomendación la sentencia SQL ha de recuperar un número positivo de elementos. La aplicación muestra en una ventana emergente las recomendaciones que se hubieran recuperado para ese elemento y tienen sentido ser mostradas según el contexto del paciente (sus datos personales y los datos que hubiera introducido en la aplicación). 3.- El usuario quita la ventana emergente (mediante por ejemplo el botón ‘Atrás’ del dispositivo móvil) 4.- Si el elemento introducido por el usuario en las precondiciones es un actividad, un alimento o una medicación y la hora y el día especificados por usuario se corresponden a menos de diez minutos antes de la fecha y hora del propio dispositivo móvil se muestra una ventana emergente preguntando al usuario si en base a las recomendaciones mostradas va a realizar finalmente esa acción especificada. En otro
5. Resultados
89
caso, no se muestra la ventana emergente. El objetivo de la ventana emergente preguntando al usuario si va a realizar la acción especificada es representar la situación de que el usuario puede recibir recomendaciones en las que se le aconseja que no realice la acción recién especificada. En esos casos, se le permite al usuario decidir si va a realizar esa acción (tomar un medicamento, alimento, etc.) y dejarla almacenarla en la aplicación, o bien, no va a realizarla y la aplicación borraría la acción recién especificada. Los síntomas experimentados o las mediciones al ser sucesos que el usuario no puede evitar la aplicación no muestra la ventana emergente que pregunta al usuario si va a realizar finalmente la acción especificada. Si se introduce una acción en la aplicación y un día y una fecha anteriores a 10 minutos antes de la fecha y de la hora del propio dispositivo móvil, entonces se interpreta que el usuario ya realizó esa acción en el pasado. Al haber sucedido ya esa acción, no tiene sentido preguntarle al usuario si va a realizar algo que ya realizó. La ventana emergente de confirmación de la realización de la acción tendrá dos botones:
- Botón ‘Sí’. Finaliza la ejecución del caso de uso. - Botón ‘No’. Borra la acción recién especificada por el usuario y finaliza la ejecución del caso de
uso. 5.- El usuario pulsa el botón ‘Sí’ y finaliza la ejecución del caso de uso. Postcondiciones: 1.- Al finalizar la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste (CU-04 Obtener medición mediante sensor biométrico, CU-05 Obtener medición manualmente, CU-06 Introducir alimentación, CU-07 Introducir actividad, CU-08 Introducir medicación, CU-09 Introducir síntoma). Flujo alternativo 1: 5.- El usuario pulsa el botón ‘No’.
5.1.- La aplicación borra la acción recién introducida por el usuario (medicación, alimento, síntoma, etc.). Es decir, si el usuario ha leído las recomendaciones y ha decidido no llevar a cabo esa acción entonces se considera que el usuario no la llevó a cabo y se borra de la aplicación.
5.2.- Finaliza la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste.
Flujo alternativo 2: 3.- La aplicación no encuentra ninguna recomendación adecuada a lo recién especificado con respecto al contexto actual (datos personales del paciente y datos introducidos anteriormente en la aplicación).
3.1.- La aplicación muestra el mensaje de que no se han encontrado recomendaciones para la acción especificada.
3.2.- Finaliza la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste.
5. Resultados
90
5.2.2.2 Descripción de los casos de uso más representativos de la aplicación web
• CU-21 Autenticar usuario
Caso de Uso: CU-21 Autenticar usuario Breve descripción: Este caso de uso se encarga de pedir identificación al usuario con rol de médico para autenticarlo con respecto al sistema. Precondiciones: 1.- Se ha accedido a la aplicación web sin estar autentificado en ella. Flujo principal: 1.- Se muestra una ventana en la que se solicita el nombre de usuario y la contraseña. Se muestra un botón ‘Entrar’ debajo de los campos. 2.- El usuario introduce su nombre de usuario y su contraseña en la ventana y pulsa el botón ‘Entrar’. 3.- La aplicación verifica que el nombre del usuario y su contraseña son correctos y se accede a la pantalla de inicio de la aplicación. Postcondiciones: 1.- Si el usuario escribió el nombre de usuario y la contraseña asociada a él correctamente se accede a la pantalla de inicio de la aplicación. Flujo alternativo 1: 3.- La aplicación verifica que el nombre de usuario no existe o que existe pero la contraseña para ese usuario es incorrecta.
3.1.- Aparece el mensaje de error ‘Usuario y/o contraseña inválido/s’.
• CU-22 Registrar nuevo paciente Caso de Uso: CU-22 Registrar nuevo usuario Breve descripción: Este caso de uso se encarga de recoger datos del paciente para registrarlo en el sistema. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación. 2.- Se ha seleccionado la opción del menú ‘Nuevo Paciente’ Flujo principal: 1.- Se muestra en la pantalla los siguientes elementos (Todos los campos de texto son obligatorios de cumplimentar):
• Campo de texto ‘Nombre’. • Campo de texto ‘Primer apellido’. • Campo de texto ‘Segundo apellido’.
5. Resultados
91
• Campo de texto ‘Dirección’. • Campo de texto ‘Teléfono móvil’. • Campo de texto ‘Teléfono fijo’. • Campo de texto ‘Teléfono de contacto de un familiar’. • Campo de texto ‘E-mail’. Este campo de texto tendrá que tener un formato de e-mail válido. • Campo de texto ‘NSS’. Número de la Seguridad Social. • Campo de texto ‘Número de identificación’. • Campo de fecha ‘Fecha de nacimiento’. Este campo ha de tener una fecha con formato válido. • Botón con icono de un calendario al lado del campo de fecha ‘Fecha de nacimiento’. Pulsando
sobre él se mostrará una ventana en la que se podrá seleccionar una fecha. Seleccionando una fecha se mostrará automáticamente en el campo de fecha ‘Fecha de nacimiento’.
• Casilla de selección con valores auto-excluyentes ‘Sexo’ con los valores ‘Varón’ y ‘Mujer’. • Campo de texto ‘Altura’. Este campo de texto se validará de que se especifique en él un número
válido y un valor válido (no se aceptarán alturas negativas ni superiores a tres metros). • Campo de texto ‘Peso’. Este campo de texto validará de que se especifique en él un número
válido. • Casilla de verificación ‘Consumidor regular de alcohol’. • Casilla de verificación ‘Fumador de tabaco’. • Casilla de verificación ‘Consumidor regular de cafeína’. • Botón ‘Limpiar’. Borra los valores especificados. • Botón ‘Salvar’. Guarda los datos del paciente introducido.
2.- El usuario especifica valores en los campos y pulsa el botón ‘Salvar’. 3.- Se validan todos los campos como válidos. Se almacenan los datos del paciente. Postcondiciones: 1.- Los datos del paciente quedan almacenados en el sistema (base de datos). Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Salvar’ estando sin cumplimentar algún campo de texto.
2.1.- La aplicación muestra un mensaje sobre el campo de texto que no se ha especificado.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Salvar’ habiendo especificado algún valor inválido en alguno de los campos de texto (e-mail, teléfono, altura, peso, etc.).
2.1.- La aplicación muestra un mensaje de error de validación sobre el campo en el que se hubiera especificado algún valor inválido.
• CU-23 Seleccionar paciente Caso de Uso: CU-23 Seleccionar paciente Breve descripción: Mediante este caso de uso el usuario puede seleccionar un paciente de entre todos los que estén asignados a él utilizando criterios de acotación. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación. 2.- El usuario ha seleccionado la opción del menú ‘Seleccionar paciente’ o bien ha seleccionado alguna de las opciones del menú ‘Ver mediciones del paciente’ o ‘Ver actividad del paciente’ sin haber
5. Resultados
92
seleccionado un paciente previamente. Flujo principal: 1.- La aplicación muestra una pantalla en la que aparecen los siguientes campos de acotación más los siguientes elementos: - Nombre. Campo de acotación. Filtra por el nombre del paciente. - Primer apellido. Campo de acotación. Selecciona por el primer apellido del paciente. - Segundo apellido. Campo de acotación. Filtra por el segundo apellido del paciente. - Número Seguridad Social. Campo de acotación. Acota por el número de la seguridad social del
paciente. - Número identificación. Campo de acotación. Filtra por el número de identificación (DNI, Tarjeta de
residencia, Tarjeta Consultar, et.) del paciente - Teléfono: Campo de acotación. Selecciona los pacientes que tengan asociado ese número de
teléfono. - Botón ‘Cuantificar’. Al pulsarlo se muestra por pantalla el número de pacientes que cumplen con
los criterios de búsqueda especificados. - Botón ‘Buscar’. Al pulsarlo se muestra el listado de pacientes que cumplen los criterios de
búsqueda. - Botón ‘Limpiar’: Al usarlo se quitan los valores establecidos en los campos de acotación.
2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Buscar’. 3.- La aplicación muestra el listado de pacientes que cumplen con los criterios de selección. El listado incluirá los mismos campos que los de acotación. Es decir: - Nombre. Nombre del paciente. - Primer apellido. Primer apellido del paciente. - Segundo apellido. Segundo apellido del paciente. - Número Seguridad Social. Número de la seguridad social del paciente. - Número identificación. Número de identificación (DNI, Tarjeta de residencia, Tarjeta Consultar,
et.) del paciente - Fecha de Nacimiento. Fecha de nacimiento del paciente.
En el listado de pacientes se mostrará una casilla de selección autoexcluyente asociada a cada paciente y un botón ‘Seleccionar’. 4.- El usuario selecciona un paciente usando la casilla de selección asociada a él y pulsa el botón ‘Seleccionar’. 5.- La aplicación almacena en la sesión del usuario el paciente seleccionado. Postcondiciones: 1.- El paciente seleccionado queda registrado en la sesión del usuario. Flujo alternativo 1: 2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Cuantificar’. 2.1.- La aplicación muestra el número de pacientes que cumplen con los criterios de acotación del usuario. Flujo alternativo 2: 2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Limpiar’. 2.1.- La aplicación deshace los cambios introducidos por el usuario en los criterios de acotación. Flujo alternativo 3: 4.- El usuario pulsa el botón ‘Seleccionar’ sin haber marcado la casilla de selección de ningún paciente. 4.1.- La aplicación muestra un mensaje indicando que no se ha de seleccionado el paciente.
5. Resultados
93
• CU-25 Ver información de seguimiento del paciente Caso de Uso: CU-25 Ver información de seguimiento del paciente Breve descripción: Este caso de uso se encarga de mostrar en gráficas las mediciones del paciente en una determinada semana, así como el resto de datos introducidos (medicación, alimentación, acciones y síntomas) por el usuario de cada uno de los días de esa semana. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación 2.- El usuario ha de haber seleccionado un paciente mediante el caso de uso CU-22 Seleccionar paciente. 3.- El usuario ha seleccionado la opción del menú ‘Ver actividad del paciente’. Flujo principal: 1.- La aplicación muestra un apartado ‘Campos de acotación’ en el que se muestra un campo de fecha ‘Semana de seguimiento’ y un botón ‘Buscar’. 2.- El usuario cumplimenta un valor sobre el campo de fecha ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 3.- La aplicación muestra debajo del apartado ‘Campos de acotación’ un nuevo apartado ‘Criterios de visualización de datos’ en el que se muestran los siguientes campos: - Medición. Listado desplegable en el que los valores son los tipos de mediciones: la presión arterial,
temperatura y glucosa en sangre. Seleccionando un valor del listado desplegable se muestra una gráfica con la evolución del tipo de medición asignado al valor seleccionado del listado desplegable.
- Día de la semana del seguimiento. Listado desplegable en el que los valores son los días de la semana: lunes, martes, miércoles, jueves, viernes, sábado y domingo. Se mostrará una tabla con los datos introducidos por el paciente de mediciones, alimentación, actividades realizadas y síntomas experimentados. Esta tabla tendrá dos columnas: ‘Hora’ y ‘Acción’. En la columna ‘Hora’ se mostrará la hora en la que el paciente especificó que realizó esa acción y en la columna ‘Acción’ se mostrará la acción que especificó: el medicamento que tomó, el alimento que ingirió, la actividad que realizó o el síntoma que experimentó.
Postcondiciones: 1.- Ninguna Flujo alternativo 1: 2.- El usuario especifica un valor inválido en el campo ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 2.1.- La aplicación muestra un mensaje indicando que el campo ‘Semana de seguimiento’ tiene un valor inválido. Flujo alternativo 2: 2.- El usuario no especifica ningún valor en el campo ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 2.1.- La aplicación muestra un mensaje indicando que el campo ‘Semana de seguimiento’ es obligatorio de cumplimentar.
5. Resultados
94
5.2.3 Escenarios. Diagramas de secuencia más representativos
Se exponen en este apartado los escenarios más representativos de las
aplicaciones del sistema mediante diagramas de secuencia.
5.2.3.1 Aplicación móvil
• Introducción de una medición (CU-04 Obtener medición mediante sensor
biométrico y CU-05 Obtener medición manualmente)
El escenario expuesto de la introducción de una medición mostrado en la Figura
20 comprende desde que la aplicación ha recibido una medición (ya sea mediante sensor
biométrico o mediante introducción manual) hasta que el usuario ha leído las
recomendaciones asociadas a esa medición.
5. Resultados
95
Figura 20. Diagrama de secuencia de análisis de la introducción de una medición
Los pasos que se producen de forma resumida son:
o El usuario introduce la medición.
o Se comprueba que el valor de la medición se encuentra dentro de un rango
válido (esta comprobación sólo se realiza si el valor de la medición se
introdujo de forma manual).
o Se introduce la medición en la base de datos de la aplicación móvil.
o Se recuperan las recomendaciones que corresponden a ese tipo de medición
y al rango de valores en el que está comprendido el valor de la medición.
o Para cada una de las recomendaciones encontradas hay que evaluar su
condición de visualización en el caso de que la tenga. Si no la tiene, la
5. Resultados
96
recomendación se mostrará. Si la tiene, hay que evaluar la condición de
visualización. La condición de visualización está representada mediante una
sentencia SQL que siempre devuelve el número de elementos que se
encuentra en un determinado estado. Si ese número de elementos devueltos
es un entero positivo entonces esa recomendación se mostrará. En otro caso,
la recomendación no se mostrará.
o Se muestra una ventana emergente con las recomendaciones recuperadas que
o bien tenían condición de visualización y la han cumplido o bien no tenían
asociada condición de visualización.
o El usuario cierra la ventana emergente de las recomendaciones.
• Introducción de un medicamento (CU-08 Introducir medicación)
El escenario mostrado en la Figura 21 de la introducción de un medicamento
comprende desde que el usuario ha introducido un medicamento en la aplicación hasta
que el usuario ha decidido no tomarlo después de leer las recomendaciones asociadas al
medicamento que ha introducido.
5. Resultados
97
Figura 21. Diagrama de secuencia de análisis de la introducción de un medicamento
El escenario es muy parecido al de introducción de mediciones salvo por las
siguientes dos diferencias:
• Un medicamento introducido puede cancelarse, las mediciones no. Si el
usuario después de introducir el medicamento, lee alguna recomendación
que le aconseja no tomarlo, puede decidir no tomarlo finalmente y por
tanto especificar que no se almacene en la aplicación.
5. Resultados
98
• Al introducir un medicamento (al igual que al introducir una actividad,
un síntoma, o un alimento) puede especificarse el día y la hora a la cual
se produjo la toma del medicamento. En las mediciones siempre se
considera la fecha y la hora actual del dispositivo móvil.
Los pasos que se producen en el escenario de forma concisa son:
o El usuario introduce el medicamento y el día y la hora a la que lo va a tomar
o lo ha tomado.
o Se comprueba que el medicamento introducido está en el sistema y que la
fecha y la hora introducidas son válidas.
o Se introduce la toma del medicamento en la base de datos de la aplicación
móvil.
o Se recuperan las recomendaciones que corresponden a los medicamentos con
el código ATC del medicamento especificado.
o Para cada una de las recomendaciones encontradas hay que evaluar su
condición de visualización en el caso de que la tenga. Si no la tiene, la
recomendación se mostrará. Si la tiene, hay que evaluar la condición de
visualización. La condición de visualización está representada mediante una
sentencia SQL que siempre devuelve el número de elementos que se
encuentra en un determinado estado. Si ese número de elementos devueltos
es un entero positivo entonces esa recomendación se mostrará. En otro caso,
la recomendación no se mostrará.
o Se muestra una ventana emergente con las recomendaciones recuperadas que
o bien tenían condición de visualización y la han cumplido o bien no tenían
asociada condición de visualización.
o El usuario cierra la ventana emergente de las recomendaciones.
o Como el usuario en base a las recomendaciones leídas puede decidir no
tomar finalmente el medicamento, se muestra una ventana de confirmación.
o El usuario en base a lo leído a las recomendaciones decide no tomar el
medicamento especificado y así lo especifica en la ventana de confirmación.
o La aplicación elimina el medicamento recién introducido por el usuario de la
base de datos del dispositivo móvil.
5. Resultados
99
• Sincronización de datos (CU-10 Sincronizar información con el servidor
remoto)
El escenario de sincronización de datos mostrado en la Figura 22 comprende
desde que el usuario ha especificado que desea sincronizar los datos de la aplicación
móvil hasta que los datos quedan sincronizados.
5. Resultados
100
Figura 22. Diagrama de secuencia de análisis de la sincronización de datos
Los pasos que se producen en el escenario de modo resumido son:
• El usuario especifica que los datos de la aplicación móvil se sincronicen
con los de la base de datos central.
• Se comprueba que en el dispositivo móvil existe disponible alguna
conexión a Internet.
5. Resultados
101
• Se realiza una llamada al servicio web para recuperar los datos
personales del paciente (peso, altura, enfermedades, etc.) que hubiera en
la base de datos central.
• Se actualizan los datos personales del paciente en la base de datos de la
aplicación móvil.
• Se actualizan las enfermedades que estén asignadas al paciente en la base
de datos de la aplicación móvil.
• Se realiza una llamada al servicio web para recuperar los datos que hayan
sido actualizados en la base de datos central desde la última vez que la
aplicación móvil realizó la operación de sincronizar los datos.
• Se actualizan los datos desactualizados en la base de datos de la
aplicación móvil.
• Se realiza una llamada al servicio web para recuperar los datos que
hubieran sido creados en la base de datos central desde la última vez que
la aplicación móvil realizó la operación de sincronizar los datos.
• Se insertan los datos nuevos en la base de datos de la aplicación móvil.
• Se recuperan de la base de datos de la aplicación móvil aquellos datos de
seguimiento que aún no hayan sido enviados a la base de datos central
mediante el servicio web.
• Se realiza una llamada al servicio web para enviar los datos de
seguimiento recuperados en el paso anterior (los que aún no han sido
enviados).
5.2.3.2 Aplicación web • Selección de un paciente (CU-23 Seleccionar paciente)
El escenario de seleccionar un paciente mostrado en la Figura 23 comprende
desde que el usuario ha introducido criterios de búsqueda y ha pulsado el botón de
buscar hasta que marca un paciente como seleccionado y pulsa el botón para
seleccionarlo.
5. Resultados
102
Figura 23. Diagrama de secuencia de análisis de selección de un paciente
Los pasos que se producen en el escenario de modo resumido son:
• El usuario especifica criterios para buscar el paciente y pulsa el botón de
búsqueda.
• Se validan los criterios de búsqueda.
• Se realiza la búsqueda de pacientes en base a los criterios especificados
por el usuario.
• Se listan los pacientes encontrados por la búsqueda.
• El usuario (médico) selecciona uno de los pacientes encontrados y pulsa
el botón para seleccionarlo.
• Se establece el paciente seleccionado en sesión para que pueda ser usado
en algunos apartados de la aplicación web (Modificar datos personales
5. Resultados
103
del paciente, Asignar/Desasignar enfermedades, Ver información de
seguimiento del paciente, etc.).
• Obtener información de seguimiento de un paciente (CU-25 Ver información
de seguimiento del paciente)
El escenario de la obtención de la información de seguimiento de un paciente
mostrado en la Figura 24 comprende desde que el usuario solicita la información de
seguimiento de un paciente para una determinada semana hasta que se muestra en la
pantalla.
5. Resultados
104
Figura 24. Diagrama de secuencia de análisis de la obtención de la información de seguimiento
de un paciente
Los pasos que se producen en el escenario de modo de resumen son:
• El usuario (médico) especifica la semana de la cual desea ver la
información del paciente seleccionado en sesión y pulsa el botón para
verla.
• Se valida que la semana especificada es válida.
• Se obtienen los datos para mostrar la información de seguimiento
(mediciones, alimentación, medicación, actividades realizadas y síntomas
experimentados)
• Se agrupan los datos recuperados para clasificarlos por día de la semana.
• Se generan las gráficas para las mediciones.
5. Resultados
105
• Se muestra la información procesada por la pantalla.
5.3 Diseño
5.3.1 Decisiones tomadas de diseño
Se especifican en este apartado las decisiones que se tomaron en el diseño de las
aplicaciones del sistema.
Se decide desarrollar componentes comunes reutilizables para las tres
aplicaciones a desarrollar (aplicación móvil, aplicación web y servicio web) debido a
que éstas van a compartir muchas clases comunes. Con estos componentes comunes se
evita la duplicación de código y se simplifica en gran parte el mantenimiento.
Se utilizará el patrón de diseño Modelo-Vista-Controlador para independizar el
código de la lógica de negocio con respecto al código encargado de la visualización de
los datos y de las interacciones con el usuario.
Se decide usar tecnologías de código abierto en el desarrollo del sistema para
evitar en la medida de lo posible el antipatrón Vendor Lock-In expuesto en (Brown, W.
et al., 2000).
Para el diseño de las clases de persistencia de la aplicación se usará el patrón
DAO y se usará una clase DAO para cada tabla del modelo de datos.
5.3.2 Componentes del sistema
El sistema se divide en los componentes especificados en la Tabla 19.
5. Resultados
106
Nombre del
componente
Aplicación que
implementa
Descripción Componentes
de los que
depende
adpas_common Componente que incluye las clases
comunes de modelo y de utilidades que
se utilizan en todas las aplicaciones
adpas_db Componente encargado de los accesos
a la base de datos central del sistema
adpas_common
adpas_ws Servicio web Servicio web que realiza la función de
interlocutor entre la aplicación móvil y
la base de datos central del sistema
adpas_common
y adpas_db
adpas_web Aplicación web Aplicación web que utilizarán los
usuarios con perfil médico para evaluar
el seguimiento de sus pacientes
asignados.
adpas_common
y adpas_db
adpas_droid Aplicación móvil Aplicación móvil que usarán los
pacientes para introducir mediciones y
datos de seguimiento para poder ser
consultados posteriormente por su
médico.
adpas_common
Tabla 19. Componentes del sistema desarrollado
Se muestra en la Figura 25 el Diagrama de Componentes del sistema en UML.
Figura 25. Diagrama de componentes del sistema
5. Resultados
107
5.3.3 Modelo de datos
Se presenta en este apartado una introducción al modelo de datos usado en el
sistema.
Se divide el modelo de datos en las agrupaciones mostradas en la Tabla 20 para
su mejor comprensión.
Agrupación Descripción Tablas incluidas
Pacientes y médicos Tablas correspondientes a los
datos personales de pacientes y
médicos.
adpas_patient_profile,
adpas_patient_diseases,
adpas_c_doctors y
adpas_doctor_patients
Catálogos (excluyendo las
tablas de catálogo de
recomendaciones)
Tablas de catálogos usadas en el
sistema.
adpas_c_sensor_types,
adpas_c_sensors,
adpas_c_class_disease,
adpas_c_diseases,
adpas_c_medicines,
adpas_c_duration,
adpas_c_activities,
adpas_c_food_dafne_class,
adpas_c_food_dafne_subclass,
adpas_c_food y
adpas_c_symptoms
Mediciones de los pacientes Tablas en las que se almacenan
los valores de las mediciones
que se realizan los pacientes.
adpas_patient_blood_pressure,
adpas_patient_temperature y
adpas_patient_glucose
Datos de seguimiento del
paciente (excluyendo las de
mediciones del paciente)
Tablas en las que se almacenan
los datos se seguimiento del
paciente que no son mediciones
(actividades realizadas,
medicación, alimentación y
síntomas experimentados).
adpas_patient_activities,
adpas_patient_medicines,
adpas_patient_diet y
adpas_patient_symptoms
Recomendaciones asociadas a
las mediciones
Tablas de catálogo en las que se
almacenan las recomendaciones
asociadas los rangos de valores
de los tipos de medición.
adpas_c_blood_pressure_messages,
adpas_c_temperature_messages y
adpas_c_glucose_messages
Recomendaciones asociadas a Tablas de catálogo en las que se adpas_c_medicine_messages,
5. Resultados
108
los datos de seguimiento del
paciente (excluyendo las
mediciones)
almacenan las recomendaciones
asociadas a los datos de
seguimiento del paciente.
adpas_c_activity_messages,
adpas_c_food_messages y
adpas_c_symptom_messages
Tabla 20. Agrupaciones de tablas del modelo de datos del sistema
5.3.3.1 Tablas de pacientes y médicos
Se muestra en la Figura 26 una vista de las tablas de pacientes y médicos así
como en la Tabla 21 las descripciones de las tablas.
Nombre de la tabla Descripción
adpas_patient_profile Datos personales del paciente
adpas_patient_diseases Enfermedades del paciente
adpas_c_doctors Médicos
adpas_doctor_patients Pacientes asociados a cada médico
Tabla 21. Tablas de pacientes y médicos
Figura 26. Tablas de pacientes y médicos
5.3.3.2 Tablas de catálogos
Se muestra en la Figura 27 una vista de las tablas de catálogos así como en la
Tabla 22 las descripciones de las tablas comprendidas.
5. Resultados
109
Nombre de la tabla Descripción
adpas_c_sensor_types Tipos de sensores
adpas_c_sensors Sensores biométricos
adpas_c_class_disease Clases de enfermedades
adpas_c_diseases Enfermedades
adpas_c_medicines Medicamentos
adpas_c_duration Duraciones que pueden tener las actividades
realizadas por el paciente.
adpas_c_activities Actividades que pueden especificar los pacientes
adpas_c_food_dafne_class Clases de alimentos
adpas_c_food_dafne_subclass Subclases de alimentos
adpas_c_food Alimentos
adpas_c_symptoms Síntomas
Tabla 22. Tablas de catálogos
Figura 27. Tablas de catálogos
5. Resultados
110
5.3.3.3 Tablas de mediciones de los pacientes
Se muestra en la Tabla 23 las descripciones de las tablas de mediciones de
pacientes así como en la Figura 28 una vista de éstas.
Nombre de la tabla Descripción
adpas_patient_blood_pressure Mediciones de tensión arterial
adpas_patient_temperature Mediciones de temperatura corporal
adpas_patient_glucose Mediciones de glucosa en sangre
Tabla 23. Tablas de mediciones de los pacientes
Figura 28. Tablas de mediciones de los pacientes
5.3.3.4 Tablas de datos de seguimiento de los pacientes
Se muestra en la Tabla 24 las descripciones de las tablas de mediciones de
pacientes así como en la Figura 29 una vista de éstas.
Nombre de la tabla Descripción
adpas_patient_activities Actividades realizadas por el paciente
adpas_patient_medicines Medicamentos tomados por el paciente
adpas_patient_symptoms Síntomas experimentados por el paciente
adpas_patient_diet Alimentos ingeridos por el paciente
Tabla 24. Tablas de datos de seguimiento de los pacientes
5. Resultados
111
Figura 29. Tablas de datos de seguimiento de los pacientes
5.3.3.5 Tablas de recomendaciones asociadas a las mediciones
Se muestra en la Figura 30 una vista de las tablas de recomendaciones asociadas
a las mediciones así como en la Tabla 25 las descripciones de las tablas.
Nombre de la tabla Descripción
adpas_c_blood_pressure_messages Recomendaciones asociadas a los rangos de
mediciones de tensión arterial
adpas_c_temperature_messages Recomendaciones asociadas a los valores de
mediciones de temperatura corporal
adpas_c_glucose_messages Recomendaciones asociadas a los rangos de
mediciones de la glucosa en sangre
Tabla 25. Tablas de recomendaciones asociadas a las mediciones
Figura 30. Tablas de recomendaciones asociadas a las mediciones
5. Resultados
112
5.3.3.6 Tablas de recomendaciones asociadas a los datos de seguimiento de los pacientes
Se muestra en la Figura 31 una vista de las tablas de recomendaciones asociadas
a las mediciones así como en la Tabla 26 las descripciones de las tablas.
Nombre de la tabla Descripción
adpas_c_medicine_messages Recomendaciones asociadas a los medicamentos
adpas_c_activity_messages Recomendaciones asociadas a las actividades
adpas_c_food_messages Recomendaciones asociadas a los alimentos
adpas_c_symptom_messages
Recomendaciones asociadas a los síntomas
Tabla 26. Tablas de recomendaciones asociadas a los datos de seguimiento de los pacientes
Figura 31. Tablas de recomendaciones asociadas a los datos de seguimiento de los pacientes
5.3.4 Diagramas de clase
5.3.4.1 Diagramas de clase de apartados representativos
5.3.4.1.1 Clases de modelo del módulo adpas_common
En la Figura 32 se muestra una simplificación del Diagrama de clases del
modelo. Las clases de catálogo heredan todas de la clase CatalogBean, mientras las
clases de modelo de mediciones y del resto de datos de seguimiento del paciente
heredan de la clase TimeableBean.
5. Resultados
113
Figura 32. Simplificación del diagrama de clases del modelo
En la clase CatalogBean se encuentran los campos en los que se almacena la
fecha de alta y de modificación de un elemento. Estos campos se usan para determinar
los elementos de catálogos que hay que actualizar en la aplicación móvil cuando se
sincroniza con el servidor central.
En la clase TimeableBean se encuentra un método abstracto getTime() que
devuelve la fecha y la hora en la que se produjo el dato de seguimiento (medición,
alimento, medicamento, síntoma, etc.). En esta clase se encuentran los campos
description y additionalDescription usados para mostrar los datos de seguimiento de
forma uniforme en los casos de uso CU-12 Mostrar Histórico de la aplicación móvil y
CU-25 Ver información de seguimiento del paciente de la aplicación web.
5. Resultados
114
5.3.4.1.2 Clases DAO del módulo adpas_db
En la Figura 33 se muestra una simplificación de las clases DAO del módulo
adpas_db. Todas clases DAO heredan de la clase BaseDAO. La clase DAOLocator se
encarga de gestionar cada una de las instancias de cada clase DAO. Se usa para
recuperar la instancia correspondiente de cada clase DAO mediante la invocación de su
método getDAO. De esta forma en tiempo de ejecución sólo existe una única instancia
de cada clase DAO. La primera vez que se solicita la instanciación de una clase DAO lo
que hace la clase DAOLocator es instanciarla y guardar la instancia creada en una tabla
hash. Las siguientes veces que una clase solicite la instancia de esa clase DAO mediante
el método getDAO de la clase DAOLocator se envía la instancia guardada de esa clase
DAO en la tabla hash.
Figura 33. Simplificación del diagrama de clases de las clases DAO de adpas_db
En las clases DAO de catálogos como BloodPressureMessageDAO o
MedicineDAO tienen métodos retrieve…ToAdd() y retrieve…ToUpdate(). Esos métodos
se usan para recuperar los datos de catálogos que han sido añadidos y han sido
modificados respectivamente desde una determinada fecha que se pasa como parámetro
en los métodos.
Las clases DAO de datos de seguimiento del paciente tienen un método
insert…() para insertar los datos de seguimiento en la base de datos y métodos
retrieve…OnDateInterval() y selectTrackingData() para recuperar los datos de
seguimiento.
5. Resultados
115
5.3.4.1.3 Clases DAO del módulo adpas_droid
En la Figura 34 se muestra un simplificación de las clases del módulo
adpas_droid (aplicación móvil).
Figura 34. Simplificación del diagrama de clases de las clases DAO del módulo adpas_droid
La estructura es análoga a la usada en las clases DAO usadas en el módulo
adpas_db. Al ser clases DAO de aplicaciones distintas tienen responsabilidades también
diferentes.
La clase BaseDAO de la cual heredan todas las clases DAO del módulo
adpas_droid tiene el método abstracto creationStatements. Dicho método devuelve la
sentencia SQL para crear la tabla asociada a esa clase DAO. En Android la base de
datos asociada a una aplicación no se crea al instalar la aplicación, se crea en el
momento en que se usa la base de datos por primera vez. Es decir, la primera vez que se
usa la base de datos, se recorren todas las clases DAO para ejecutar las sentencias SQL
de su método creationStatements. De esta forma se crean todas las tablas en la base de
datos de la aplicación móvil.
El funcionamiento de la clase DAOLocator es el mismo que en el módulo
adpas_db.
Las clases DAO de catálogos (FoodDAO y FoodMessagesDAO en la Figura 34)
tienen los métodos insert…(), update…(), select…() para insertar, actualizar y obtener
los elementos de esa tabla.
5. Resultados
116
Las clases DAO correspondientes a datos de seguimiento del paciente tienen los
métodos adicionales deleteOldSentRegisters(), updateSentDate(), deleteLast…() y
selectHistoricalData().
El método deleteOldSentRegisters() borra de la base de datos aquellos datos de
seguimiento que hayan sido enviados al servidor central y tengan más de una semana de
antigüedad.
El método updateSentDate() actualiza la fecha de envío en los datos de
seguimiento. Se invoca al mandar los datos de seguimiento al servidor central.
El método deleteLast…() sirve para borrar el último elemento insertado. Se
utiliza cuando el usuario después de leer las recomendaciones asociadas a ese elemento
decide no llevarlo a cabo (no comer ese alimento, no tomar ese medicamento, etc.).
Entonces en ese caso se ha de borrar el elemento que se había insertado.
El método selectHistoricalData() se obtiene los datos de seguimiento de ese tipo
de elemento de la última semana. Este método se usa en la ejecución del caso CU-12
Mostrar histórico.
5.3.4.1.4 Clases del framework de sensores
En la realización del caso de uso CU-04 Obtener medición mediante sensor
biométrico se realizó un framework de gestión de sensores biométricos con el objetivo
de simplificar la futura incorporación de nuevos sensores biométricos.
La incorporación de un nuevo sensor biométrico implica añadir la clase que se
encargue de la lectura de la medición que suministre el sensor y la inserción de un
nuevo registro en la tabla apdas_c_sensors.
En la Figura 35 se muestra el diagrama de clases del framework de sensores
diseñado.
5. Resultados
117
Figura 35. Diagrama de clases del framework de sensores
Todos los sensores deben heredar de la clase abstracta AbstractSensor que
representa un sensor abstracto. Los sensores han de implementar los métodos
obtainMeasurements() para obtener las mediciones y stopObtainingMeasurements()
para parar la lectura de mediciones.
La interfaz ISensorObserver realiza la función de observador de la ejecución del
sensor. Tiene el método onTaskFinished() para indicar que se ha finalizado la lectura de
las mediciones del sensor y el método sendMessage() para enviar mensajes acerca de la
ejecución de la lectura de las mediciones.
En la interfaz IBluetoothSocketManager realiza la función de gestionar el Socket
Bluetooth del sensor una vez el dispositivo móvil ha establecido la conexión Bluetooth
con el sensor. Tiene el método manageConnectedSocket() en el que cual se han de
especificar las acciones que se deben realizar para leer las mediciones una vez el
dispositivo móvil se ha conectado mediante Bluetooth al sensor biométrico.
La lectura de las mediciones de un sensor se realiza en la ejecución de un
Thread. Existen definidas dos clases Thread dependiendo de si el dispositivo móvil se
comporta como un servidor (DefaultServerSensorThread) o como un cliente
(DefaultClientSensorThread) con respecto al sensor. Ambas clases heredan de la clase
abstracta AbstractSensorThread. Para leer las mediciones del tensiómetro IEM Stabil-
O-Graph el dispositivo móvil ha de comportarse como un servidor y el sensor como un
cliente.
5. Resultados
118
Se muestra en la Figura 36 el diagrama de clases del framework de sensores
junto con las clases utilizadas para leer las mediciones del tensiómetro IEM Stabil-O-
Graph. Las clases usadas para la lectura de las mediciones del tensiómetro IEM Stabil-
O-Graph son IemTensiometerSensor e IemTensiometerSocketManager.
Figura 36. Diagrama de clases del framework de sensores con las clases usadas por el tensiómetro IEM Stabil-O-Graph
La clase IemTensiometerSensor se encarga de realizar la conexión Bluetooth con
el tensiómetro mientras que la clase IemTensiometerSocketManager se encarga de leer
las mediciones del tensiómetro una vez se ha establecido la conexión.
5.3.4.2 Diagramas de clase más representativos de los casos de uso
5.3.4.2.1 Aplicación móvil • CU-05 Obtener medición manualmente
Se muestra en la Figura 37 el diagrama de clases del caso de uso CU-05 Obtener
medición manualmente. Mediante este caso de uso el usuario puede introducir las
mediciones de forma manual.
5. Resultados
119
Figura 37. Diagrama de clases del caso de uso CU-05 Obtener medición manualmente
Las clases implicadas son:
o SetMeditionResultActivity: Clase controladora de los eventos producidos
por las interacciones con el usuario.
o BloodPressureHelper: Clase encargada de insertar las mediciones de
tensión arterial y obtener las recomendaciones asociadas a éstas.
o GlucoseHelper: Clase encargada de insertar las mediciones de glucosa en
sangre y obtener las recomendaciones asociadas a éstas.
o TemperatureHelper: Clase encargada de insertar las mediciones de
temperatura corporal y obtener las recomendaciones asociadas a éstas.
o BloodPressureMessagesDAO: Clase DAO responsable de las búsquedas de
recomendaciones asociadas a los valores de las mediciones de tensión
arterial.
o PatientBloodPressureDAO: Clase DAO responsable de las operaciones de
persistencia de los valores de las mediciones de tensión arterial del paciente.
o GlucoseMessagesDAO: Clase DAO responsable de las búsquedas de
recomendaciones asociadas a los valores de las mediciones de glucosa en
sangre.
o PatientGlucoseDAO: Clase DAO responsable de las operaciones de
persistencia de los valores de las mediciones de glucosa en sangre del
paciente.
o PatientTemperatureDAO: Clase DAO responsable de las operaciones de
persistencia de los valores de las mediciones de temperatura corporal del
paciente.
5. Resultados
120
o TemperatureMessagesDAO: Clase DAO responsable de las búsquedas de
recomendaciones asociadas a los valores de las mediciones de temperatura
corporal.
• CU-08 Introducir medicación
Se muestra en la Figura 38 el diagrama de clases del caso de uso CU-08
Introducir medicación. Mediante este caso de uso el usuario puede introducir en la
aplicación los medicamentos que toma.
Figura 38. Diagrama de clases del caso de uso CU-08 Introducir medicación
Las clases implicadas son:
o AddMedicineActivity: Clase controladora de los eventos producidos por las
interacciones con el usuario.
o MedicineHelper: Clase encargada de insertar los medicamentos
especificados por el usuario y de obtener las recomendaciones asociadas a
éstos.
o MedicineDAO: Clase DAO responsable de las operaciones de persistencia
de los medicamentos tomados por el usuario paciente.
5. Resultados
121
o MedicineMessagesDAO: Clase DAO encargada de las búsquedas de
recomendaciones asociadas a los medicamentos especificados por el usuario
paciente.
• CU-10 Sincronizar información con el servidor remoto
Se muestra en la Figura 39 el diagrama de clases del caso de uso CU-10
Sincronizar información con el servidor remoto. Mediante este caso de uso la aplicación
móvil envía los datos de seguimiento especificados por el paciente así como se
sincronizan los datos de catálogos que se hubieran modificado en la base de datos
central.
Figura 39. Diagrama de clases del caso de uso CU-10 Sincronizar información con el servidor remoto
Las clases implicadas son:
o SendDataActivity: Clase controladora de los eventos producidos por las
interacciones con el usuario.
o SynchronizeDataHelper: Clase encargada de enviar los datos de
seguimiento del paciente y de sincronizar los datos de la base de datos de la
aplicación móvil con los datos de la base de datos central. Desde esta clase
se invocarán los métodos de la clase AdpasWebService para realizar las
llamadas a las operaciones del servicio web.
o AdpasWebService: Clase encargada de realizar las llamadas a las
operaciones del servicio web con los argumentos proporcionados por la clase
5. Resultados
122
SynchronizeDataHelper. La clase AdpasWebService realizaría la función
de “Fachada” del servicio web para la aplicación móvil. Las operaciones del
servicio web invocadas por esta clase se encargarán de enviar los datos de
seguimiento pendientes de enviar y de obtener los datos de la aplicación
móvil a sincronizar.
o Clases DAO: Este caso de uso utiliza todas las clases DAO de la aplicación
móvil. Se especifican algunas clases DAO en el diagrama como ejemplo.
5.3.4.2.2 Aplicación web
• CU-22 Registrar nuevo paciente
Se muestra en la Figura 40 el diagrama de clases del caso de uso CU-22
Registrar nuevo paciente. Mediante este caso de uso se registran nuevos pacientes en el
sistema desde la aplicación web.
Las clases implicadas son:
o SaveNewPatientAction: Clase de acción en Struts (como respuesta al
evento de la interacción del usuario) para salvar los datos del nuevo paciente.
o PatientProfileBean: Clase de modelo en la que se representan los datos
personales del paciente.
o NewPatientForm: Clase de formulario en Struts para representar los datos
que se usan en la pantalla para registrar un nuevo paciente.
o PatientProfileDAO: Clase DAO con las operaciones de persistencia
asociadas a los pacientes.
5. Resultados
123
Figura 40. Diagrama de clases del caso de uso CU-22 Registrar nuevo paciente
• CU-23 Seleccionar paciente
Se muestra en la Figura 41 el diagrama de clases del caso de uso CU-23
Seleccionar paciente. El usuario médico puede seleccionar uno de sus pacientes
mediante este caso de uso. El usuario médico busca al paciente mediante unos criterios
de acotación y selecciona al paciente de los resultados. Esta selección sirve para
posteriormente ver los datos de seguimiento del paciente seleccionado y para asignar y
desasignarle enfermedades.
5. Resultados
124
Figura 41. Diagrama de clases del caso de uso CU-23 Seleccionar paciente
Las clases implicadas en el caso de uso son:
o SelectPatientSearchAction: Clase de acción en Struts para realizar la
búsqueda de los pacientes del médico utilizando los criterios de acotación.
o PatientProfileBean: Clase de modelo en la que se representan los datos
personales del paciente.
o SelectPatientForm: Clase de formulario en Struts para representar los datos
que se usan en la pantalla para los criterios de búsqueda del paciente a
seleccionar.
o SelectPatientSearchAJAX: Clase de AJAX con el método para contabilizar
el número de resultados que devolverá la búsqueda.
o SelectPatientSelectionAction: Clase de acción en Struts para seleccionar un
paciente de entre los que cumplieron los criterios de búsqueda especificados
por el usuario médico.
o PatientProfileDAO: Clase DAO con las operaciones de búsqueda y
contabilización de pacientes.
5. Resultados
125
• CU-25 Ver información de seguimiento del paciente
Se muestra en la Figura 42 diagrama de clases del caso de uso CU-25 Ver
información de seguimiento del paciente. Mediante este caso de uso el usuario médico
puede ver los datos de seguimiento del paciente clasificados por el día de la semana que
hubiera seleccionado mediante el caso de uso CU-23 Seleccionar paciente. También se
pueden ver gráficas asociadas a los tipos de medición por semana.
Figura 42. Diagrama de clases del caso de uso CU-25 Ver información de seguimiento del paciente
Las clases implicadas en el caso de uso son:
o ShowPatientTrackingDataAction: Clase de acción en Struts para realizar
la obtener los datos de seguimiento del paciente.
o TrackingDataPatientForm: Clase de formulario en Struts para representar
los datos que se usan en la pantalla de los datos de seguimiento.
o ShowPatientTemperatureChartAction: Clase para mostrar el gráfico de
los valores de las temperaturas del paciente.
o ShowPatientGlucoseChartAction: Clase para mostrar el gráfico de los
valores de la glucosa en sangre del paciente.
o ShowPatientBloodPressureChartAction: Clase para mostrar el gráfico de
los valores de la tensión arterial del paciente.
5. Resultados
126
o Clases DAO: Clases DAO correspondientes a elementos de datos de
seguimiento (mediciones, medicamentos, síntomas, etc.).
5.4 Implementación
En el apartado 5.3 Diseño se ha explicado la estructura de las aplicaciones
mediante diagramas de clase. En este apartado se va a mostrar cierto detalle de la
implementación de las aplicaciones (fragmentos de código).
5.4.1 Aplicación web
5.4.1.1 CU-25 Ver información de seguimiento del paciente
Mediante este caso de uso el usuario médico puede ver la información de
seguimiento del paciente previamente seleccionado mediante el caso de uso CU-23
Seleccionar paciente. El usuario especifica la fecha de la semana en la cual desea ver la
información de seguimiento del paciente, pulsa el botón ‘Buscar’ (Ver Figura 43) y se
muestran gráficos de las mediciones y toda la información de seguimiento del paciente
para cada día de la semana (Ver Figura 44).
Figura 43. Pantalla de acotación del caso de uso CU-25 Ver información del paciente
5. Resultados
127
Figura 44. Pantalla de visualización de los datos de seguimiento del caso de uso CU-25 Ver
información de seguimiento del paciente
En el Fragmento de código 1 se muestran los métodos para obtener la
información de seguimiento del paciente. El método principal es
establishTrackingData, que establece en el objeto formulario la información de
seguimiento del paciente de esa semana clasificada por sus días. Dentro del método
establishTrackingData se ejecuta el método obtainTrackingData que se encarga de
obtener la información de seguimiento del paciente para la franja de tiempo
especificada. Estos datos de seguimiento se ordenan por el instante (día y hora) en que
se produce cada dato de seguimiento.
/** * Establish patient's tracking data in a week * @param request request object * @param idPatient identifier of the patient * @param trackingDataPatientForm form of patient's tracking data * @param firstDayOfWeek first day of the week from which patient's tracking data * will be shown * @throws DAONotFoundException exception which occurs when a DAO class does not * exists
5. Resultados
128
* @throws DAOException exception for dao classes */ private void establishTrackingData(HttpServletRequest request, Long idPatient, TrackingDataPatientForm trackingDataPatientForm, java.util.Date firstDayOfWeek) throws DAONotFoundException, DAOException { java.util.Date dateMonday = firstDayOfWeek; java.util.Date dateTuesday = DateUtil.utilDateAddDays(firstDayOfWeek, 1); java.util.Date dateWednesday = DateUtil.utilDateAddDays(firstDayOfWeek, 2); java.util.Date dateThursday = DateUtil.utilDateAddDays(firstDayOfWeek, 3); java.util.Date dateFriday = DateUtil.utilDateAddDays(firstDayOfWeek, 4); java.util.Date dateSaturday = DateUtil.utilDateAddDays(firstDayOfWeek, 5); java.util.Date dateSunday = DateUtil.utilDateAddDays(firstDayOfWeek, 6); trackingDataPatientForm.setListTrackingDataMonday(this.obtainTrackingData(request, idPatient, dateMonday, dateMonday)); trackingDataPatientForm.setListTrackingDataTuesday(this.obtainTrackingData(request, idPatient, dateTuesday, dateTuesday)); trackingDataPatientForm.setListTrackingDataWednesday(this.obtainTrackingData(request, idPatient, dateWednesday, dateWednesday)); trackingDataPatientForm.setListTrackingDataThursday(this.obtainTrackingData(request, idPatient, dateThursday, dateThursday)); trackingDataPatientForm.setListTrackingDataFriday(this.obtainTrackingData(request, idPatient, dateFriday, dateFriday)); trackingDataPatientForm.setListTrackingDataSaturday(this.obtainTrackingData(request, idPatient, dateSaturday, dateSaturday)); trackingDataPatientForm.setListTrackingDataSunday(this.obtainTrackingData(request, idPatient, dateSunday, dateSunday)); } /** * Obtains a list with patient's tracking data between dates specified by parameters * @param request request object * @param idPatient identifier of the patient * @param beginningDate the date from which patient's tracking data is considered * @param endingDate the date until which patient's tracking data is considered * @return a list with patient's tracking data between dates specified by parameters * @throws DAONotFoundException exception which occurs when a DAO class does not * exists * @throws DAOException exception for dao classes */ private List<TimeableBean> obtainTrackingData(HttpServletRequest request, Long idPatient, java.util.Date beginningDate, java.util.Date endingDate) throws DAONotFoundException, DAOException { List<TimeableBean> listResult = null; Connection con = this.getConnection(); // Obtain the database connection // Obtain the DAO instances PatientFoodDAO patientFoodDAO = (PatientFoodDAO) DAOLocator.getDAO( DAONames.PATIENT_FOOD); MedicinePatientDAO patientMedicineDAO = (MedicinePatientDAO) DAOLocator.getDAO( DAONames.MEDICINE_PATIENT); SymptomPatientDAO patientSymptomDAO = (SymptomPatientDAO) DAOLocator.getDAO( DAONames.SYMPTOM_PATIENT); ActivityPatientDAO patientActivityDAO = (ActivityPatientDAO) DAOLocator.getDAO( DAONames.ACTIVITY_PATIENT); BloodPressurePatientDAO patientBloodPressureDAO = (BloodPressurePatientDAO) DAOLocator.getDAO(DAONames.BLOOD_PRESSURE_PATIENT); TemperaturePatientDAO patientTemperatureDAO = (TemperaturePatientDAO) DAOLocator.getDAO(DAONames.TEMPERATURE_PATIENT); GlucosePatientDAO patientGlucoseDAO = (GlucosePatientDAO) DAOLocator.getDAO( DAONames.GLUCOSE_PATIENT); // Obtain patient's tracking data List<TimeableBean> listPatientFood = patientFoodDAO.selectTrackingData(con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientMedicine = patientMedicineDAO.selectTrackingData(
5. Resultados
129
con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientSymptom = patientSymptomDAO.selectTrackingData(con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientActivities = patientActivityDAO.selectTrackingData(con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientBloodPressure = patientBloodPressureDAO.selectTrackingData( con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientTemperature = patientTemperatureDAO.selectTrackingData( con, idPatient, beginningDate, endingDate); List<TimeableBean> listPatientGlucose = patientGlucoseDAO.selectTrackingData( con, idPatient, beginningDate, endingDate); // All patient's tracking data are wrapped in TimeableBean objects. listResult = new ArrayList<TimeableBean>(); for (int i = 0; i < listPatientFood.size(); i++) { TimeableBean timeableBeanI = listPatientFood.get(i); timeableBeanI.setAdditionalDescription(DietUtil .obtainMessageRationsFromNumber(request, Double.valueOf(timeableBeanI.getAdditionalDescription()) .doubleValue())); listResult.add(timeableBeanI); } // Messages for meditions of blood pressure String strSystolicBloodPressure = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.bloodPressure.systolic"); String strDiastolicBloodPressure = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.bloodPressure.diastolic"); String strUnitBloodPressure = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.bloodPressure.unit"); for (int i = 0; i < listPatientBloodPressure.size(); i++) { TimeableBean timeableBeanI = listPatientBloodPressure.get(i); timeableBeanI.setDescription(strSystolicBloodPressure + ": " + timeableBeanI.getDescription() + " " + strUnitBloodPressure + " "+ strDiastolicBloodPressure + ": " + timeableBeanI.getAdditionalDescription() + " " + strUnitBloodPressure); timeableBeanI.setAdditionalDescription(""); listResult.add(timeableBeanI); } // Messages for meditions of body temperature String strTemperatureMedition = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.temperature.measure"); String strTemperatureUnit = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.temperature.unit"); for (int i = 0; i < listPatientTemperature.size(); i++) { TimeableBean timeableBeanI = listPatientTemperature.get(i); timeableBeanI.setDescription(strTemperatureMedition + ": " + timeableBeanI.getDescription() + " " + strTemperatureUnit); listResult.add(timeableBeanI); } // Messages for meditions of glucose String strGlucoseMedition = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.glucose.measure"); String strGlucoseUnit = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medition.glucose.unit"); for (int i = 0; i < listPatientGlucose.size(); i++) { TimeableBean timeableBeanI = listPatientGlucose.get(i); timeableBeanI.setDescription(strGlucoseMedition + ": " + timeableBeanI.getDescription() + " " + strGlucoseUnit); listResult.add(timeableBeanI); } String strDoses = MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.medicine.doses"); for (int i = 0; i < listPatientMedicine.size(); i++) { TimeableBean timeableBeanI = listPatientMedicine.get(i);
5. Resultados
130
timeableBeanI.setAdditionalDescription(timeableBeanI .getAdditionalDescription() + " " + strDoses); listResult.add(timeableBeanI); } listResult.addAll(listPatientSymptom); listResult.addAll(listPatientActivities); // All patient's tracking data are sort by time Collections.sort((List<TimeableBean>) listResult); return listResult; }
Fragmento de código 1. Métodos para obtener la información de seguimiento del paciente de la
clase ShowPatientTrackingDataAction
Para cada uno de los tipos de datos de seguimiento existe en la clase DAO
correspondiente un método llamado selectTrackingData encargado de recuperar los
datos de seguimiento para ese tipo de dato. En el Fragmento de código 2 se muestra el
método selectTrackingData de la clase DAO PatientFoodDAO.
/** * Obtains a list with the foods the patient has eaten in the period of time * specified in parameters * @param con database connection * @param idpatient identifier of the patient * @param beginningDate the date from which patient's eaten foods are considered * @param endingDate the date until which patient's eaten foods are considered * @return a list with the food the patient has eaten in the period of time * specified in parameters * @throws DAOException exception for dao classes */ public List<TimeableBean> selectTrackingData(Connection con, Long idpatient, java.util.Date beginningDate, java.util.Date endingDate) throws DAOException { PreparedStatement stmt = null; ResultSet rs = null; try { String strSql = " select patient.idpatient, patient.eating_time, " + " patient.idfood, " + " food.dsfood as description, " + " patient.rations as additionalDescription " + " from " + " adpas_patient_diet patient " + " inner join adpas_c_food food " + " on patient.idfood = food.idfood " + " where " + " patient.idpatient = ? " + " and patient.eating_time >= ? " + " and patient.eating_time < date_add(?, interval 1 DAY) "; logger.debug("SQL: " + strSql); stmt = con.prepareStatement(strSql); int p = 1; stmt.setLong(p++, idpatient.longValue()); stmt.setTimestamp(p++, new Timestamp(beginningDate.getTime())); stmt.setTimestamp(p++, new Timestamp(endingDate.getTime())); rs = stmt.executeQuery(); List<TimeableBean> listTimeable = new ArrayList<TimeableBean>(); while (rs.next()) { PatientFoodBean patientFoodBean = new PatientFoodBean(); patientFoodBean.setIdPatient(Long.valueOf(rs .getLong("idpatient"))); patientFoodBean.setEatingTime(Long.valueOf(rs .getTimestamp("eating_time").getTime()));
5. Resultados
131
patientFoodBean.setIdFood(Integer.valueOf(rs .getInt("idfood"))); patientFoodBean.setDescription(rs.getString("description")); patientFoodBean.setAdditionalDescription( rs.getString("additionalDescription")); listTimeable.add(patientFoodBean); } return listTimeable; } catch (Exception e) { logger.debug("Error: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { logger.debug("Error closing ResultSet: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { logger.debug("Error closing PreparedStatement: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } } } } Fragmento de código 2. Método selectTrackingData de la clase PatientFoodDAO
En el caso particular de las mediciones se genera también una gráfica por cada
tipo de medición. Se muestra en el Fragmento de código 3 el método obtainChart para
generar la gráfica de la medición de la tensión arterial.
/** * Obtain a chart from blood pressure meditions of the patient * specified by parameter * @param request request object * @param idPatient identifier of the patient * @param startingDate the date from which patient's blood pressure * measurements are considered * @param endingDate the date until which patient's blood pressure * measurements are considered * @return a chart from blood pressure meditions of the patient * specified by parameter * @throws DAONotFoundException exception which occurs when a DAO class * does not exists * @throws DAOException exception for dao classes */ private JFreeChart obtainChart(HttpServletRequest request, Long idPatient, java.util.Date startingDate, java.util.Date endingDate) throws DAONotFoundException, DAOException { Connection con = this.getConnection(); BloodPressurePatientDAO patientBloodPressureDAO = (BloodPressurePatientDAO) DAOLocator .getDAO(DAONames.BLOOD_PRESSURE_PATIENT);
5. Resultados
132
List<PatientBloodPressureBean> listBloodPressurePatient = patientBloodPressureDAO .retrieveBloodPressurePatientOnDateInterval(con, idPatient, startingDate, endingDate); TimeSeries timeSeriesSystolic = new TimeSeries( MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.charts.bloodPressure.systolic"), Minute.class); TimeSeries timeSeriesDiastolic = new TimeSeries( MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.charts.bloodPressure.diastolic"), Minute.class); int listSize = listBloodPressurePatient.size(); for (int i = 0; i < listSize; i++) { PatientBloodPressureBean patientBloodPressureI = listBloodPressurePatient.get(i); java.util.Date meditionDate = new java.util.Date( patientBloodPressureI.getMeasurementTime() .longValue()); timeSeriesSystolic.addOrUpdate( new Minute(DateUtil.utilDateGetMinute(meditionDate), DateUtil.utilDateGetHour(meditionDate), DateUtil.utilDateGetDayOfMonth(meditionDate), DateUtil.utilDateGetMonth(meditionDate), DateUtil.utilDateGetYear(meditionDate)), patientBloodPressureI.getSystolicBloodPressure() .doubleValue()); timeSeriesDiastolic.addOrUpdate( new Minute( DateUtil.utilDateGetMinute(meditionDate), DateUtil.utilDateGetHour(meditionDate), DateUtil.utilDateGetDayOfMonth(meditionDate), DateUtil.utilDateGetMonth(meditionDate), DateUtil.utilDateGetYear(meditionDate)), patientBloodPressureI.getDiastolicBloodPressure() .doubleValue()); } TimeSeriesCollection dataset = new TimeSeriesCollection(); dataset.addSeries(timeSeriesSystolic); dataset.addSeries(timeSeriesDiastolic); JFreeChart chart = ChartFactory .createTimeSeriesChart( MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.charts.bloodPressure.measure"), MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.charts.bloodPressure.date"), MessageUtil.getMessageString(request, "adpas_web.trackingPatientData.charts.bloodPressure.unit"), dataset, true, true, false); chart.setBackgroundPaint(Color.white); XYPlot plot = chart.getXYPlot(); plot.setBackgroundPaint(Color.lightGray); plot.setDomainGridlinePaint(Color.white); plot.setRangeGridlinePaint(Color.white); plot.setDomainCrosshairVisible(true); plot.setRangeCrosshairVisible(true); return chart; } Fragmento de código 3. Método obtainChart de la clase ShowPatientBloodPressureAction para
generar la gráfica de las mediciones de la tensión arterial
5. Resultados
133
5.4.2 Servicio web
5.4.2.1 CU-42 Recibir datos nuevos o actualizados de catálogos del sistema
En este caso de uso la aplicación móvil recibe del servicio web los datos nuevos
o que han sido actualizados de los catálogos de la base de datos central del sistema. En
el Fragmento de código 4 se muestra el método receiveApplicationDataForAdding de la
clase ReceiveApplicationDataForAddingResource. Este método se usa para recuperar
los datos de catálogos que se han creado nuevos desde la última vez que se
sincronizaron los datos con la base de datos central. También se muestra el método
establishSensors usado para establecer los sensores que se han creado nuevos en el
mensaje que enviará el servicio web.
En el Fragmento de código 5 se muestra el método retrieveSensorsToAdd de la
clase DAO SensorDAO para obtener los sensores que se han creado nuevos en la base
de datos centralizada desde la última vez que se sincronizó la aplicación móvil.
@Path("/receiveApplicationDataForAdding/{strLongDate}") public class ReceiveApplicationDataForAddingResource { /** Logger. */ private static Logger logger = Logger.getLogger(ReceiveApplicationDataForAddingResource.class); @GET @Produces({MediaType.APPLICATION_XML}) public ApplicationDataMessage receiveApplicationDataForAdding(@PathParam("strLongDate") String strLongDate) { logger.debug("[BEGIN] receiveApplicationDataForAdding [" + strLongDate + "]" ); ApplicationDataMessage applicationDataMessage = new ApplicationDataMessage(); Connection con = null; try { con = ConnectionManager.getManager().getConnection(); Long longDate = Long.valueOf(strLongDate); java.util.Date date = new java.util.Date(longDate); establishSensors(con, applicationDataMessage, date); establishSensorTypes(con, applicationDataMessage, date); establishSymptoms(con, applicationDataMessage, date); establishSymptomMessages(con, applicationDataMessage, date); establishTemperatureMessages(con, applicationDataMessage, date); establishActivities(con, applicationDataMessage, date); establishActivityMessages(con, applicationDataMessage, date); establishBloodPressureMessages(con, applicationDataMessage, date); establishDiseases(con, applicationDataMessage, date); establishDiseaseClasses(con, applicationDataMessage, date); establishDiseaseTrainingMessages(con, applicationDataMessage, date); establishDurations(con, applicationDataMessage, date); establishFoods(con, applicationDataMessage, date); establishFoodDafneClasses(con, applicationDataMessage, date);
5. Resultados
134
establishFoodDafneSubclasses(con, applicationDataMessage, date); establishFoodMessages(con, applicationDataMessage, date); establishGlucoseMessages(con, applicationDataMessage, date); establishMedicines(con, applicationDataMessage, date); establishMedicineMessages(con, applicationDataMessage, date); } catch(Exception e) { logger.error(e.getMessage(), e); throw new RuntimeException(e.getMessage(), e); } finally { if (con != null) { try { con.close(); } catch (Exception e) { logger.error( "Error in closing DB Connnection in " + " receiveApplicationDataForAdding [" + strLongDate + "]" ); } } } logger.debug("[END] receiveApplicationDataForAdding [" + strLongDate + "]" ); return applicationDataMessage; } private void establishSensors(Connection con, ApplicationDataMessage message, java.util.Date date) throws DAONotFoundException, DAOException { SensorDAO dao = (SensorDAO) DAOLocator .getDAO(DAONames.SENSOR); List<SensorBean> listSensors = dao.retrieveSensorsToAdd(con, date); if (listSensors != null && listSensors.size() > 0) { SensorBean[] arraySensors = new SensorBean[listSensors.size()]; for (int i = 0; i < arraySensors.length; i++) { arraySensors[i] = listSensors.get(i); } message.setSensors(arraySensors); } }
Fragmento de código 4. Fragmento de la clase ReceiveApplicationDataForAddingResource del
módulo adpas_ws /** * retrieve the sensors to add. * @param con the database connection * @param lastUpdateDate the date where the mobile application was updated for the * last time * @return the sensors to add * @throws DAOException exception in DAO classes */ public List<SensorBean> retrieveSensorsToAdd(Connection con, java.util.Date lastUpdateDate)throws DAOException { PreparedStatement stmt = null; ResultSet rs = null; try { String strSql = " select idsensor, cdsensortype, product_name, " + " short_product_name, UUID, connection_class, " + " communication_class, MAC_adress, creationDate, " + " modificationDate from adpas_c_sensors where creationDate > ? "; logger.debug("SQL: " + strSql); stmt = con.prepareStatement(strSql); // create a statement int p = 1; stmt.setTimestamp(p++, new Timestamp(lastUpdateDate .getTime())); rs = stmt.executeQuery(); List<SensorBean> listSensors = new ArrayList<SensorBean>(); while (rs.next()) { SensorBean sensorBean = new SensorBean(); sensorBean.setIdSensor(Integer.valueOf(rs.getInt("idsensor")));
5. Resultados
135
sensorBean.setCdSensorType(Character.valueOf( rs.getString("cdsensortype").charAt(0))); sensorBean.setProductName(rs.getString("product_name")); sensorBean.setShortProductName(rs.getString("short_product_name")); sensorBean.setUuid(rs.getString("UUID")); sensorBean.setConnectionClass(rs.getString("connection_class")); sensorBean.setCommunicationClass(rs.getString("communication_class")); sensorBean.setMacAddress(rs.getString("MAC_adress")); sensorBean.setCreationDate(Long.valueOf(rs.getTimestamp( "creationDate").getTime())); sensorBean.setModificationDate(Long.valueOf(rs.getTimestamp( "modificationDate").getTime())); listSensors.add(sensorBean); } return listSensors; } catch (Exception e) { logger.debug("Error: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } finally { if (rs != null) { try { rs.close(); } catch (SQLException e) { logger.debug("Error closing ResultSet: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } } if (stmt != null) { try { stmt.close(); } catch (SQLException e) { logger.debug("Error closing PreparedStatement: " + e.getMessage()); throw new DAOException(e.getMessage(), e); } } } }
Fragmento de código 5. Método retrieveSensorsToAdd de la clase SensorDAO
5.4.3 Aplicación móvil
5.4.3.1 CU-08 Introducir medicación
En este caso de uso el usuario paciente puede introducir los medicamentos que
toma en la aplicación móvil. En la Figura 45 se muestra la pantalla de este apartado de
la aplicación móvil.
5. Resultados
136
Figura 45. Pantalla del apartado de 'Medicamentos' de la aplicación móvil
En el Fragmento de código 6 se muestra el método acceptMedicine de la clase
AddMedicineActivity que se ejecuta al pulsar el botón ‘Introducir medicamento’ de la
interfaz de usuario. En un hilo diferente al usado en la interfaz de usuario se inserta el
medicamento introducido y se buscan las recomendaciones asociadas a él. /** * actions executed when the user pulses the accept button */ private void acceptMedicine() { TaskHandler taskHandler = new TaskHandler() { protected void handleNotifyTaskResultEstablished() { resetUserFields(); this.getProgressDialog().dismiss(); showSuccessOperationMessage(MessageUtil.getMessage( this.getContext(), R.string.label_medicine_add_medicine_success)); if (this.getObjectResult() != null && ((String[]) this.getObjectResult()).length > 0) { showSuggestionsDialog((String[]) this.getObjectResult()); } else if (this.getObjectResult() != null && ((String[]) this.getObjectResult()).length == 0) { showAlertMessage(MessageUtil.getMessage( this.getContext(), R.string.label_medicine_message_no_suggestions_medicine_already_taken)); } else if (this.getObjectResult() == null) { showAlertMessage(MessageUtil.getMessage( this.getContext(), R.string.label_medicine_message_no_suggestions)); } } }; ProgressDialog progressDialog = ProgressDialog.show( AddMedicineActivity.this, "", MessageUtil.getMessage(this, R.string .global_dialog_obtaining_suggestions_please_wait), true);
5. Resultados
137
taskHandler.setContext(this); taskHandler.setProgressDialog(progressDialog); taskHandler.setTextView(mTextViewResultMessage); TaskThread taskThread = new TaskThread(taskHandler, this) { @Override public void run() { MedicineBean medicineSelected = obtainMedicineSelected(); Long timeSpecifiedByUser = obtainTimeSpecifiedByUser(); Long idPatient = AdpasPreferencesUtil.getIdPatient( this.getContext()); String atcCodeMedicineSelected = medicineSelected.getAtcCode(); MedicineHelper.insertMedicine(this.getContext(), this.getTaskHandler(), idPatient, medicineSelected.getIdMedicine(), Integer.valueOf(getDosesSelected()), timeSpecifiedByUser); String[] strArraySuggestions = null; // the time the action will be considered already done long longTimeActionDone = System.currentTimeMillis() - (AdpasConstants.ADPAS__MINUTES_ACTION_DONE_ALREADY * 60000); if (timeSpecifiedByUser.longValue() >= longTimeActionDone) { strArraySuggestions = MedicineHelper.obtainSuggestionMessages( this.getContext(), this.getTaskHandler(), idPatient, atcCodeMedicineSelected, timeSpecifiedByUser); } else { strArraySuggestions = new String[0]; } this.getTaskHandler().notifyTaskResultEstablished( strArraySuggestions); } }; taskThread.start(); }
Fragmento de código 6. Método acceptMedicine de la clase AddMedicineActivity
En el Fragmento de código 7 se muestra el método obtainSuggestionMessages
de la clase MedicineHelper. Este método es usado para obtener los mensajes de
recomendaciones asociados al medicamento introducido. En el Fragmento de código 8
se muestra el método isConditionSatisfied de la clase MessageConditionsUtil usado
para comprobar si se cumple la condición asociada a un mensaje de recomendación
determinado. /** * obtain suggestion messages from the medicine inserted * @param context Android context object * @param taskHandler taskHandler object * @param idPatient identifier of the patient * @param atcCode ATC Code of the medicine inserted * @param longSuggestionTime the time when the medicine was taken * @return the suggestion messages from the medicine inserted */ public static String[] obtainSuggestionMessages(Context context, TaskHandler taskHandler, Long idPatient, String atcCode, Long longSuggestionTime) { String[] arraySuggestionsMessages = null;
5. Resultados
138
SQLiteDatabase db = null; try { DatabaseManager.initilizeDatabaseManager(context); db = DatabaseManager.getReadableDatabase(); MedicineMessagesDAO patientMedicineDAO = (MedicineMessagesDAO) DAOLocator .getDAO(DAONames.MEDICINE_MESSAGE); List<MedicineMessageBean> listMessages = patientMedicineDAO .selectMedicineMessages(db, atcCode); List<String> listStrMessages = new ArrayList<String>(); int sizeListMessages = listMessages.size(); for (int i = 0; i < sizeListMessages; i++) { MedicineMessageBean beanI = listMessages.get(i); // If there is a sql condition in the message then // the condition will have to be checked if (StringUtils.isNotEmpty(beanI.getSqlCodeCondition())) { if (MessageConditionsUtil.isConditionSatisfied(db, idPatient, longSuggestionTime, beanI.getSqlCodeCondition())) { listStrMessages.add(beanI.getMessage()); } } else { listStrMessages.add(beanI.getMessage()); } } if (listStrMessages != null && listStrMessages.size() > 0) { arraySuggestionsMessages = new String[listStrMessages.size()]; for (int i = 0; i < arraySuggestionsMessages.length; i++) { arraySuggestionsMessages[i] = listStrMessages.get(i); } } } catch (Exception e) { taskHandler.dismissProgressDialog(); String errorMessage = "Error obtaining Messages from Medicine: " + e.getMessage(); Log.e(LOG_TAG, errorMessage, e); throw new RuntimeException(errorMessage, e); } return arraySuggestionsMessages; } Fragmento de código 7. Método obtainSuggestionMessages de la clase MedicineHelper
/** * Determines whether the condition specified in the SQL query specified in * parameter 'strSQLQuery' * is satisfied. A condition is satisfied if the SQL query returns results and * the integer result which returns is above zero * @param db the database * @param idPatient the identifier of the patient * @param longDate the date represented in a Long variable * @param strSQLQuery the string of the SQL query * @return whether the condition specified in the SQL query specified in * parameter 'strSQLQuery' is satisfied */ public static boolean isConditionSatisfied(SQLiteDatabase db, Long idPatient, Long longDate, String strSQLQuery) { boolean booleanResult = false; try { Log.d(LOG_TAG, "Query: " + strSQLQuery + " IdPatient: " + idPatient.toString() + " longDate: " + longDate.toString() + " date: " + (new java.util.Date( longDate)).toString()); // The number of interrogation marks (parameteres of the query) // is determined int numberInterrogationMarks = StringUtils.countOccurrencesOf(strSQLQuery, "?");
5. Resultados
139
SQLiteStatement statement = null; statement = db.compileStatement(strSQLQuery); statement.bindLong(1, idPatient.longValue()); for (int i = 2; i <= numberInterrogationMarks; i++) { statement.bindLong(i, longDate.longValue()); } long result = 0; result = statement.simpleQueryForLong(); Log.d(LOG_TAG, "Result query: " + result); if (result > 0) { booleanResult = true; } statement.close(); } catch (Exception e) { Log.e(LOG_TAG, "Error in \'isConditionSatisfied\'. Query [" + strSQLQuery + "] " + "Error: " + e.getMessage(), e); } return booleanResult; } Fragmento de código 8. Método isConditionSatisfied de la clase MessageConditionsUtil
5.4.3.2 CU-04 Introducir medición mediante sensor biométrico
Mediante este caso de uso la aplicación móvil lee la medición realizada por el
usuario desde un sensor biométrico. Se muestra en la Figura 46 un pantallazo de este
apartado de la aplicación móvil. En el Fragmento de código 9 se muestra el código
asociado al comienzo de la lectura del sensor.
Figura 46. Pantalla de medición mediante sensor de la aplicación móvil
private void startReadingFromSensor() { int posSelectedSensor = this.spinnerSensors.getSelectedItemPosition(); SensorBean fieldsSensorSelected = this.listSensors.get(posSelectedSensor); this.sensor = null; this.listMeditions = null; this.glucose = null; this.temperature = null; this.systolicBloodPressure = null; this.diastolicBloodPressure = null;
5. Resultados
140
try { if (!bluetoothAdapter.isEnabled()) { bluetoothAdapter.enable(); } String strClassNameSensor = fieldsSensorSelected.getCommunicationClass(); String strClassNameConnection = fieldsSensorSelected.getConnectionClass(); // Instantiation of the sensor this.sensor = (AbstractSensor) Class.forName(strClassNameSensor).newInstance(); AbstractSensorThread sensorThread = (AbstractSensorThread) Class.forName( strClassNameConnection).newInstance(); this.sensor.setSensorThread(sensorThread); if (fieldsSensorSelected.getUuid().length() >= AdpasConstants .ANDROID_DEFAULT_UUID_LENGTH) { this.sensor.setUuid(UUID.fromString( fieldsSensorSelected.getUuid())); } else if (fieldsSensorSelected.getUuid().startsWith( AdpasConstants.PREFIX_UUID_16BITS)) { Integer integUUID = Integer.valueOf(fieldsSensorSelected.getUuid() .substring(2), 16); this.sensor.setUuid(UUIDHelper.fromUUID16( integUUID.intValue())); } this.sensor.setSensorObserver(this); if (StringUtils.isNotEmpty(fieldsSensorSelected.getMacAddress())) { this.sensor.setBluetoothServerAddress( fieldsSensorSelected.getMacAddress()); } this.progressDialog = null; this.progressDialog = ProgressDialog.show( ReadFromSensorActivity.this, "", MessageUtil.getMessage(this, R.string .label_medition_sensor_readingMedition), true); this.progressDialog.setCancelable(true); this.progressDialog.setOnCancelListener(new OnCancelListener() { @Override public void onCancel(DialogInterface dialogInterface) { stopObtainingMeasuresFromSensor(); } }); try { this.sensor.obtainMeasurements(); } catch (Exception ioe) { this.sensor.stopObtainingMeasurements(); if (this.bluetoothAdapter != null) { this.bluetoothAdapter.cancelDiscovery(); if (!this.wasBluetoothEnabled) { this.bluetoothAdapter.disable(); } } ToastUtil.showValidationMessage(this, MessageUtil.getMessage(this, R.string.validation_medition_sensor_temporaryBluetoothFailure)); }
} catch (Exception e) { String message = "Exception. Error in establishing sensor parameters: " + e.getMessage(); Log.e(LOG_TAG, message); throw new RuntimeException(message, e);
5. Resultados
141
} } Fragmento de código 9. Método startReadingFromSensor de la clase ReadFromSensorActivity
En el Fragmento de código 10 se muestra el código del método
obtainMeasurements de la clase IemTensiometerSensor. Este código se ejecutaría en la
instrucción ‘this.sensor.obtainMeasurements();’ del Fragmento de código 9. En el
Fragmento de código 11 se muestra el constructor de la clase
DefaultServerSensorThread y el método run del hilo. El constructor de la clase
IemTensiometerSocketManager está vacío.
/** * Obtain measurements. This method should be invoked to connect to the medical * device (sensor) for connecting and accessing it to obtain the measurements it * has realized. * * @see es.uclm.mami.adpas.sensor.AbstractSensor#obtainMeasurements() */ @Override public void obtainMeasurements() { this.bluetoothSocketManager = new IemTensiometerSocketManager(); this.sensorThread = new DefaultServerSensorThread(uuid, this.getSensorObserver(), bluetoothSocketManager); sensorThread.start(); } Fragmento de código 10. Método obtainMeasurements de la clase IemTensiometerSensor
/** * Instantiates a new default server sensor thread. * * @param uuid the UUID * @param observer the observer * @param bluetoothSocketManager the Bluetooth socket manager */ public DefaultServerSensorThread(UUID uuid, ISensorObserver observer, IBluetoothSocketManager bluetoothSocketManager) { this.observer = observer; this.uuid = uuid; this.bluetoothSocketManager = bluetoothSocketManager; this.listMeasurements = null; // Use a temporary object that is later assigned to mmServerSocket, // because mmServerSocket is final BluetoothServerSocket tmp = null; try { mBluetoothAdapter = BluetoothAdapter.getDefaultAdapter(); tmp = mBluetoothAdapter.listenUsingRfcommWithServiceRecord(NAME, this.uuid); } catch (IOException e) { Log.e(TAG, "IOException BluetoothServerThread constructor: " + e.getMessage(), e); throw new RuntimeException( "IOException BluetoothServerThread constructor: " + e.getMessage(), e); } mmServerSocket = tmp; } /** * Run. Method used to run the thread responsible for accessing and communicating * with the sensor (medical device)
5. Resultados
142
* * @see java.lang.Runnable#run() */ @Override public void run() { try { Looper.prepare(); BluetoothSocket socket = null; // Keep listening until exception occurs or a socket is returned boolean meditionsObtained = false; int totalBytes = 0; while (!meditionsObtained && !this.isInterrupted()) { try { socket = mmServerSocket.accept(); Log.i(TAG, "mmServerSocket.accept() SUCCEED"); } catch (IOException e) { Log.e(TAG, "IOException mmServerSocket.accept(): " + e.getMessage(), e); try { if (socket != null) { socket.close(); socket = null; } } catch (Exception ex) { this.observer.sendMessage("Exception socket.close()"); throw new RuntimeException("Exception socket.close(): " + ex.getMessage(), ex); } } catch (Exception e) { Log.e(TAG, "Exception mmServerSocket.accept(): " + e.getMessage(), e); try { if (socket != null) { socket.close(); this.observer.sendMessage( "Accepting Socket CLOSED SUCCEED"); socket = null; } } catch (Exception ex) { this.observer.sendMessage("Exception socket.close()"); throw new RuntimeException("Exception socket.close(): " + ex.getMessage(), ex); } } finally { // If a connection was accepted if (socket != null) { // Do work to manage the connection (in a separate thread) this.listMeasurements = this.bluetoothSocketManager .manageConnectedSocket(socket); if (this.listMeasurements == null) { this.observer.sendMessage("List of Measurements IS NULL"); } else if (this.listMeasurements.size() == 0) { this.observer.sendMessage("No measurement received"); } else { this.observer.sendMessage("Received " + this.listMeasurements.size() + " measurements"); } Log.i(TAG, "mmServerSocket.close() SUCCEED:"); try { mmServerSocket.close(); mmServerSocket = null; // The listening is canceled to make more calls to method // mBluetoothAdapter.listenUsingRfcommWithServiceRecord mBluetoothAdapter.cancelDiscovery(); meditionsObtained = true; this.observer.onTaskFinished(); } catch (Exception e) {
5. Resultados
143
this.observer.sendMessage("Exception socket.close()"); throw new RuntimeException( "EXCEPTION mmServerSocket.close(): " + e.getMessage(), e); } } } } Log.i(TAG, "Background Thread is finished........."); Looper.loop(); } catch(Exception e) { Log.e(TAG, "ERROR: " + e.getMessage(), e); e.printStackTrace(); } }
Fragmento de código 11. Constructor y método run de la clase DefaultServerSensorThread
5.4.3.3 CU-10 Sincronizar información con el servidor remoto
La aplicación móvil en este caso de uso envía los datos de seguimiento del
paciente al servidor remoto (servicio web) y recibe de éste los datos que ha de crear y
actualizar en su propia base de datos. En la Figura 47 se muestra una pantalla de este
apartado en la aplicación móvil.
Figura 47. Pantalla del apartado de 'Sincronizar' de la aplicación móvil
En el Fragmento de código 12 se muestra el método synchronizeData de la clase
SendDataActivity que se ejecuta al pulsar el botón ‘Sincronizar datos’ del apartado (Ver
Figura 47).
private void synchronizeData() { TextViewUtil.clearMessageOnTextView(textView);
5. Resultados
144
if (InternetConnectionUtil.isInternetConnectionAvailable(this)) { synchronizeDataInternetAvailable(); } else { TextViewUtil.setErrorMessageOnTextView(textView, MessageUtil.getMessage(this, R.string .validation_send_data_no_internet_connection_available)); } } private void synchronizeDataInternetAvailable() { TaskHandler taskHandler = new TaskHandler() { protected void handleTaskFinished() { this.getProgressDialog().dismiss(); this.setSuccessfulOperationMessageOnTextView(MessageUtil.getMessage( this.getContext(), R.string.message_send_data_success)); } }; ProgressDialog progressDialog = ProgressDialog.show( SendDataActivity.this, "", MessageUtil.getMessage(this, R.string .dialog_send_data_synchronize_data_please_wait), true); progressDialog.setCancelable(false); taskHandler.setContext(this); taskHandler.setProgressDialog(progressDialog); taskHandler.setTextView(this.textView); TaskThread taskThread = new TaskThread(taskHandler, this) { @Override public void run() { try { Long longLastUpdateTime = AdpasPreferencesUtil.getLastUpdateTime( this.getTaskHandler().getContext()); Long idPatient = AdpasPreferencesUtil.getIdPatient(this.getContext()); PatientProfileMessage patientProfileMessage = AdpasWebService .receivePatientProfile(this.getContext(), idPatient.toString()); updatePatientProfile(idPatient, patientProfileMessage); ApplicationDataMessage applicationNewDataMessage = AdpasWebService .receiveApplicationDataForAdding(this.getContext(), longLastUpdateTime.toString()); addNewApplicationData(applicationNewDataMessage); ApplicationDataMessage applicationUpdateDataMessage = AdpasWebService .receiveApplicationDataForUpdating(this.getContext(), longLastUpdateTime.toString()); updateObsoleteApplicationData( applicationUpdateDataMessage); PatientDataMessage patientDataMessage = obtainNotSentPatientData(); AdpasWebService.sendPatientData(this.getContext(), patientDataMessage); establishSentDateOnSentPatientData(); AdpasPreferencesUtil.setLastUpdateTime( this.getTaskHandler().getContext(), Long.valueOf( System.currentTimeMillis())); this.getTaskHandler().getProgressDialog().dismiss(); this.getTaskHandler().notifyTaskFinished();
5. Resultados
145
} catch(HttpClientErrorException hcee) { Log.e(LOG_TAG, "HttpClientErrorException. Error in synchronize " + "application: " + hcee.getMessage()); if (hcee.getMessage().contains( AdpasWebServiceConstants.HTTP_ERROR_NOT_FOUND)) { this.getTaskHandler().setErrorMessageOnTextView( MessageUtil.getMessage( this.getContext(), R.string.error_send_data_server_not_found)); } else { this.getTaskHandler().setErrorMessageOnTextView( MessageUtil.getMessage( this.getContext(), R.string.error_send_data_generic_client_error)); } } catch (HttpServerErrorException hsee) { if (hsee.getMessage().contains(AdpasWebServiceConstants .HTTP_INTERNAL_SERVER_ERROR)) { this.getTaskHandler().setErrorMessageOnTextView( MessageUtil.getMessage( this.getContext(), R.string.error_send_data_internal_server_error)); } else { this.getTaskHandler().setErrorMessageOnTextView( MessageUtil.getMessage( this.getContext(), R.string.error_send_data_generic_server_error)); } } catch (Exception e) { Log.e(LOG_TAG, "Exception. Error in synchronize + "application: " + e.getMessage()); this.getTaskHandler().setErrorMessageOnTextView( MessageUtil.getMessage( this.getContext(), R.string.error_send_data_generic_message_error)); } finally { this.getTaskHandler().getProgressDialog().dismiss(); } } }; taskThread.start(); }
Fragmento de código 12. Método synchronizeData de la clase SendDataActivity
En el Fragmento de código 13 se muestran los métodos receivePatientProfile y
receiveApplicationDataForAdding de la clase AdpasWebService de la aplicación móvil.
El método receivePatientProfile se encarga de invocar la operación del servicio web
para recuperar los datos del paciente. El método receiveApplicationDataForAdding se
encarga de invocar la operación del servicio web para recuperar los datos que se han de
crear nuevos en la base de datos de la aplicación móvil.
public static PatientProfileMessage receivePatientProfile(Context context, String idPatient) { RestTemplate restTemplate = new RestTemplate(); String url = obtainAdpasWebServiceUrl(context)
5. Resultados
146
+ AdpasWebServiceConstants.OPERATION_RECEIVE_PATIENT_PROFILE + "/" + idPatient; PatientProfileMessage patientProfileMessage = restTemplate.getForObject(url, PatientProfileMessage.class); return patientProfileMessage; } public static ApplicationDataMessage receiveApplicationDataForAdding( Context context, String strLongDate) { RestTemplate restTemplate = new RestTemplate(); String url = obtainAdpasWebServiceUrl(context) + AdpasWebServiceConstants.OPERATION_RECEIVE_APP_DATA_FOR_ADDING + "/" + strLongDate; ApplicationDataMessage applicationDataMessage = restTemplate.getForObject(url, ApplicationDataMessage.class); return applicationDataMessage; }
Fragmento de código 13. Métodos receivePatientProfile y receiveApplicationDataForAdding de
la clase AdpasWebService
5.5 Pruebas
Durante la construcción del sistema implementado se realizaron pruebas
funcionales para verificar y validar el mismo.
Se realizaron baterías de pruebas unitarias utilizando el framework JUnit1.
Se realizaron pruebas de integración entre todas las aplicaciones que forman el
sistema para verificar la comunicación entre ellas.
Se realizó también una encuesta de usabilidad para aplicaciones móviles basada
en la propuesta por (Vuolle et al., 2008) sobre la aplicación móvil del sistema.
5.5.1 Pruebas unitarias
5.5.1.1 Resultados
Se exponen los resultados de las pruebas unitarias para cada uno de los módulos
probados.
1 http://www.junit.org
5. Resultados
147
• adpas_db
Figura 48. Resultado de las pruebas unitarias del módulo adpas_db
• adpas_ws
Figura 49. Resultado de las pruebas unitarias del módulo adpas_ws
• adpas_web
5. Resultados
148
Figura 50. Resultado de las pruebas unitarias del módulo adpas_web
• adpas_droid
Figura 51. Resultado de las pruebas unitarias del módulo adpas_droid
5.5.1.2 Informes de cobertura
Para medir la calidad de las pruebas unitarias realizadas se generaron informes
sobre su cobertura. El grado de cobertura de las pruebas unitarias indica el porcentaje de
código que ha sido probado. A mayor grado de cobertura mayor cantidad de código ha
sido probado por las pruebas unitarias.
5. Resultados
149
• adpas_db
Se muestra en la Figura 52 el informe de cobertura generado para el módulo
adpas_db, en la Figura 53 el detalle del informe de cobertura para el paquete de las
clases DAO y en la Figura 54 un fragmento del código de la clase DAO
FoodDafneClass en el que se muestran en verde las líneas de código por las que pasan
las pruebas y en rojo las líneas por las que no han pasado.
Figura 52. Informe de cobertura global del módulo adpas_db
Figura 53. Detalle de la cobertura del paquete de clases DAO del módulo adpas_db
5. Resultados
150
Figura 54. Detalle de cobertura de un método de la clase FoodDafneClass del módulo
adpas_db
• adpas_ws
Se muestra en la Figura 55 el informe de cobertura generado para las pruebas
unitarias realizadas sobre el módulo adpas_ws.
Figura 55. Informe de cobertura global del módulo adpas_ws
• adpas_web
Se muestra en la Figura 56 el informe de cobertura generado para las pruebas
unitarias realizadas sobre el módulo adpas_web.
5. Resultados
151
Figura 56. Informe de cobertura global del módulo adpas_web
5.5.2 Encuesta de usabilidad
Para comprobar la usabilidad de la aplicación móvil desarrollada se realizó una
encuesta de usabilidad para aplicaciones móviles a doce personas basada en la
propuesta en (Vuolle et al., 2008). La mayoría de las personas encuestadas tenían de
veinte a cuarenta años (nueve personas) y eran hombres (ocho personas). Las personas
que tenían más de cuarenta años (tres personas) no eran usuarios habituales de
tecnologías móviles. Se muestra la encuesta realizada en la Tabla 27.
Agrupación Característica 1 2 3 4 5
Facilidad de aprendizaje Facilidad de dominar la aplicación
Confiabilidad Adecuado para usar en movimiento
Ausencia de errores Suficientemente ágil
Facilidad de navegación Bajo esfuerzo para empezar a usar
Funciones fáciles de usar y entender
Usabilidad percibida
Baja concentración necesaria para su uso Facilidad de uso con el dispositivo
Tamaño de la pantalla Entrada de información
Uso del dispositivo con una mano Aspectos ambientales (poca luminosidad, reflejos, ruido)
Facilidad de uso en movimiento
Adecuación de las capacidades del dispositivo
Facilidad de uso con prisas
Ayuda a la toma de decisiones
Satisfacción en la eficacia en realizar tareas
Ayuda a encontrar información adecuada
Productividad percibida en las
tareas
Uso mejora la fluidez en la realización de tareas
Tabla 27. Encuesta de usabilidad realizada
En la hoja de la encuesta se realizaron las siguientes indicaciones:
• se especificó que los valores iban desde 1 “Nada de acuerdo” hasta 5
“Completamente de acuerdo”,
5. Resultados
152
• se indicó que al terminarla había que darle la vuelta a la hoja para hacerla
anónima,
• y también se mostraron los valores de los tipos de datos de seguimiento que
muestran mensajes de recomendaciones.
Se muestran los resultados de la encuesta en la Tabla 28.
Agrupación Característica Total Media
sobre 5 Media
sobre 100 Facilidad de aprendizaje 51 4,25 85,00
Facilidad de dominar la aplicación 51 4,25 85,00 Confiabilidad 47 3,92 78,33
Adecuado para usar en movimiento 39 3,25 65,00 Ausencia de errores 50 4,17 83,33 Suficientemente ágil 49 4,08 81,67
Facilidad de navegación 49 4,08 81,67 Bajo esfuerzo para empezar a usar 49 4,08 81,67
Funciones fáciles de usar y entender 49 4,08 81,67
Usabilidad percibida
Baja concentración necesaria para su uso 45 3,75 75,00 Facilidad de uso con el dispositivo 49 4,08 81,67
Tamaño de la pantalla 44 3,67 73,33 Entrada de información 47 3,92 78,33
Uso del dispositivo con una mano 44 3,67 73,33 Aspectos ambientales (poca luminosidad,
reflejos, ruido) 48 4,00 80,00 Facilidad de uso en movimiento 41 3,42 68,33
Adecuación de las capacidades del dispositivo
Facilidad de uso con prisas 41 3,42 68,33
Ayuda a la toma de decisiones 52 4,33 86,67
Satisfacción en la eficacia en realizar tareas 50 4,17 83,33 Ayuda a encontrar información adecuada 47 3,92 78,33
Productividad percibida en las
tareas
Uso mejora la fluidez en la realización de tareas 44 3,67 73,33
Tabla 28. Resultados de la encuesta de usabilidad
Se muestra en la Figura 57 el resultado global de la encuesta por agrupación de
características de usabilidad.
5. Resultados
153
Figura 57. Gráfico del resultado de la encuesta de usabilidad por agrupación de características
de usabilidad
Una vez realizada la encuesta y analizados los resultados se extraen los puntos
fuertes y mejorables como conclusiones de la encuesta. Los puntos fuertes de la
usabilidad de la aplicación móvil son que ayuda a la toma de decisiones y que es fácil
de entender y de aprender a usar. Los aspectos mejorables de la usabilidad son el
manejo en movimiento, con prisas y con una sola mano.
5.6 Despliegue
Se muestra en la Figura 58 el diagrama de despliegue del sistema en UML.
Se distinguen tres nodos en el despliegue del sistema: el servidor web, el
servidor de la base de datos y el dispositivo móvil.
En el servidor web se ubica la aplicación web y el servicio web (artefactos de
software adpas_web.war1y adpas_ws.war respectivamente). Como servidor de
aplicaciones Java EE se utiliza Tomcat 6.
En el servidor de la base de datos se ubica el sistema gestor de la base de datos.
Se ha usado como sistema gestor de la base de datos MySQL 5.
1 Las aplicaciones Java EE pueden empaquetarse mediante el formato de archivo war.
5. Resultados
154
En el dispositivo móvil se encuentra la aplicación móvil (artefacto de software
adpas_droid.apk1).
1 Los ficheros de empaquetado de las aplicaciones Android tienen la extensión apk.
5. Resultados
155
Figura 58. Diagrama de despliegue del sistema
6 CONCLUSIONES Y PROPUESTAS
6. Conclusiones y propuestas
Se presentan en este capítulo las conclusiones extraídas de la realización del
presente proyecto así como sus posibles líneas futuras de trabajo.
6.1 Conclusiones
La principal conclusión obtenida es que se han cumplido todos los objetivos
propuestos (Ver Tabla 29) y se han desarrollado todos los requisitos funcionales de cada
aplicación (Ver Tabla 12, Tabla 13 y Tabla 14).
Código Descripción Justificación consecución OE1 Desarrollar una aplicación móvil para
el sistema operativo Android que será
usada por pacientes.
Se ha desarrollado.
OE2 Desarrollar una aplicación web
mediante la arquitectura Java EE que
será usada por médicos.
Se ha desarrollado.
OE3 Leer las señales vitales de un
dispositivo biométrico mediante
Bluetooth desde la aplicación móvil. Se
usará el tensiómetro IEM Stabil-O-
Graph.
Desde la aplicación móvil se pueden leer las
mediciones de tensión arterial enviadas desde el
tensiómetro IEM Stabil-O-Graph.
OE4 Implementar un sistema de
comunicación a través de servicios
Web. La aplicación móvil enviará y
recibirá información en el sistema a
través de un servicio web.
Se ha desarrollado un servicio web de forma que
la aplicación móvil se comunica con la base de
datos centralizada del sistema a través de éste.
OE5 Leer las señales vitales de la tensión
arterial, el nivel de glucosa en sangre y
la temperatura corporal de un paciente
desde la aplicación móvil para ser
mostradas al médico en la aplicación
web
Desde la aplicación móvil se permiten
especificar de forma manual las mediciones de
tensión arterial, glucosa en sangre y temperatura.
Desde la aplicación web pueden consultarse
dichas mediciones.
OE6 Permitir especificar los datos que
puedan ser significativos en el estado
de salud de un paciente desde la
aplicación móvil.
Se permiten especificar como datos
significativos en el estado de salud de un
paciente su alimentación, su medicación, sus
síntomas experimentados así como sus
6. Conclusiones y propuestas
160
actividades cotidianas comunes.
OE7 Actualizar los datos internos de
catálogos de la aplicación móvil si se
actualizan los datos de la base de datos
central.
Los datos internos de catálogos de la aplicación
móvil pueden actualizarse modificando los de la
base de datos central.
OE8 Usar el estándar de clasificación de
medicamentos ATC (Anatomical,
Therapeutic, Chemical classification
system) para catalogar los
medicamentos del sistema
Se ha usado el estándar ATC para catalogar los
medicamentos del sistema.
OE9 Usar el estándar de clasificación de
enfermedades CIE-10 (Clasificación
Internacional de Enfermedades versión
10) para catalogar las enfermedades del
sistema
Se ha usado el estándar CIE-10 para catalogar
las enfermedades del sistema.
OE10 Usar el sistema de clasificación de
alimentos DAFNE (DAta Food
NEtworking) para catalogar los
alimentos en el sistema
Se ha usado el sistema de clasificación de
alimentos DAFNE para catalogar los alimentos
del sistema.
OE11 Mostrar recomendaciones al paciente
según la información suministrada por
éste en la aplicación móvil de forma
que dichas recomendaciones le asistan
en la toma de sus decisiones
Cada vez que el paciente introduce un dato
nuevo en la aplicación móvil se realiza una
búsqueda de recomendaciones que apliquen para
ese dato introducido y para ese contexto (los
datos introducidos anteriormente). Una vez
realizada esa búsqueda se muestran al paciente
las recomendaciones correspondientes al dato
introducido y al contexto de ese momento.
Tabla 29. Objetivos propuestos
La realización del presente trabajo ha requerido investigar tecnologías tan
diversas como el sistema Android, los servicios web Jersey o la comunicación
inalámbrica Bluetooth. El resultado final es un sistema prototipo que puede usarse como
base o como inspiración para el desarrollo de un sistema real de telemonitorización
doméstica de pacientes.
6. Conclusiones y propuestas
Para finalizar destacar la gran experiencia y el aprendizaje que ha supuesto el
desarrollo del presente proyecto. No sólo a nivel técnico sino también a nivel cultural
(gestión de enfermedades crónicas, sistemas de telemedicina, sistemas sanitarios, etc.).
6.2 Propuestas
Se presentan algunas propuestas como posibles futuras líneas de trabajo para el
sistema desarrollado:
• Seguridad en el sistema. Los datos intercambiados entre la aplicación
móvil y el servicio web deberían ir cifrados mediante el uso de
protocolos seguros como HTTPS o SSL. También se debería incluir
autenticación de usuario en el servicio web. Actualmente el sistema no
podría ser implantable debido a que al no cifrarse los datos relativos a la
salud de pacientes se incumpliría la Ley Orgánica de Protección de
Datos.
• Formación de pacientes. Uno de los objetivos de las iniciativas de
autocuidado de pacientes es formar a los pacientes en su enfermedad. Se
podría incluir en la aplicación móvil un apartado en el cual cada vez que
se accediese se mostrase un mensaje aleatorio de formación
correspondiente a una de las enfermedades que tuviera el paciente.
• Gestión de alergias. En el sistema desarrollado no se tienen en cuenta
las alergias particulares de cada paciente. Dependiendo de ellas existirán
medicamentos y alimentos que no se podrán tomar. Se podría desarrollar
un apartado en la aplicación web desde la cual el médico gestionara las
alergias del paciente. Si el paciente tomase algún alimento o alguna
medicación con alguna sustancia alérgica para él, se mostraría un
mensaje de recomendación indicándolo.
• Servicio en segundo plano que leyera mediciones. Se podría
desarrollar en la aplicación móvil un servicio que se encargase de leer
mediciones procedentes de sensores biométricos Bluetooth que se
ejecutase en segundo plano. Este servicio arrancaría nada más
encenderse el dispositivo móvil. Con este servicio y con el uso de
sensores biométricos automáticos y periódicos el paciente sólo tendría
que responsabilizarse de llevar puestos los sensores y el dispositivo
6. Conclusiones y propuestas
162
móvil, es decir, no tendría que preocuparse de realizarse mediciones.
Este servicio tendría el inconveniente de que supondría más gasto de
batería en el dispositivo móvil porque la conectividad Bluetooth tendría
que estar permanentemente conectada.
• Servicio en segundo plano que enviase los datos de seguimiento del
paciente al servidor central. En el sistema desarrollado el usuario
paciente ha de usar un apartado para enviar sus datos de seguimiento del
paciente (mediciones, medicación, alimentación, etc.). Se podría
desarrollar un servicio que sincronizase la información con el servidor
central de forma periódica que se ejecutase en segundo plano. Este
servicio también se arrancaría nada más encenderse el dispositivo móvil.
El servicio, al igual que el descrito en el punto anterior, supondría un
gasto adicional de batería debido a que necesitaría que el dispositivo
móvil estuviera conectado permanentemente a Internet.
• Gestión de situaciones potencialmente peligrosas. Se podría usar el
servicio explicado en la propuesta anterior (envío periódico de datos de
seguimiento del paciente al servidor central) para detectar situaciones
potencialmente peligrosas de forma automática (sin necesidad de la
intervención del paciente). Al enviarse los datos de seguimiento del
paciente si se detectase alguna situación potencialmente peligrosa para
éste, el servidor central podría enviar por ejemplo un SMS a su médico o
a su cuidador, asistente social, etc.
En Ciudad Real, a 28 de agosto del 2012
Fdo: Alejandro Alberca Manzaneque
REFERENCIAS
Referencias
165
Alonso, G., Casati, F., Kuno, H. y Machiraju, V. (2004). Web Services. Concepts,
Architectures and Applications. Berlin: Springer.
Australian Institute of Health and Welfare (2002). Chronic diseases and associated risk
factors in Australia 2001, Canberra: AIHW, página 2.
Australian Institute of Health and Welfare (2006). Chronic diseases and associated risk
factors in Australia 2006, Canberra: AIHW, página 2.
Belgacem, N. y Bereksi-Reguig, F. (2011). Bluetooth portable device for ECG and
patient motion monitoring. Nature and Technology, 4, 19–23.
Bodenheimer, T., Lorig, K., Holman, H., Grumbach, K. (2002). Patient self-
management of chronic disease in primary care. The Journal of the American Medical
Association, 288 (19), 2469-2475.
Booch, G., Rumbaugh, J. y Jacobson, I. (1999). El Lenguaje Unificado de Modelado.
Madrid: Addison Wesley.
Brown, W., Malveau, R., McCormick, R., Thomas, S. y Hudson, T. (2000). Anti-
Patterns in Project Management. Nueva York: John Wiley & Sons
DAta Food NEtworking. The DAFNE Food Classification System. Disponible en
http://ec.europa.eu/health/archive/ph_projects/2002/monitoring/dafne_code_en.pdf.
Accedido el 29 de mayo de 2012.
Eng, T. (2001). The eHealth landscape: a terrain map of emerging information and
communication technologies in health and health care. Princeton, NJ: The Robert
Wood Johnson Foundation
Gamma, E., Helm, R., Johnson, R. y Vlissides, J. (1995). Design Patterns: Elements of
Reusable Object-Oriented Software: Addison-Wesley
Referencias
166
Ghosh, C.S., Ravindran y P., Joshi, M. (2008). Reductions in hospital use from self
management training for chronic asthmatics. Social Science & Medicine, 46 (8), 1086-
1093.
Hoffman, D. (2008). An Urgent Reality: The Need to Prevent and Control Chronic
Disease. Atlanta: National Association of Chronic Disease Directors.
INSALUD (2000). Plan de Telemedicina del INSALUD. Disponible en
www.ingesa.msc.es/estadEstudios/documPublica/pdf/telemedicina.pdf. Accedido el 15
de julio de 2012.
International Diabetes Federation (2007). Diabetes Atlas. Third Edition. Disponible en
http://archive.diabetesatlas.org/sites/default/files/IDF%20Diabetes%20Atlas-
2007%20%283rd%20edition%29.pdf
IOM (1996). Telemedicine: a guide to assessing telecommunications in health care.
Washington, D.C., Estados Unidos: National Academy Press
Jacobson, I., Booch, G. y Rumbaugh, J. (1999). The Unified Development Process.
Boston: Addison-Wesley.
Jacobson, I., Booch, G. y Rumbaugh, J. (2000). El Proceso Unificado de Desarrollo de
Software. Nueva York: Addison-Wesley.
Kennet, T. (2009). Chronic disease management and prevention in the US: The missing
links in health care reform. Eurohealth, 15 (1), 5-7.
Larman, C. (2002). Applying Uml and Patterns: An Introduction to Object-
orientedAnalysis and Design and the Unified Process. Prentice Hall.
Logan, A., McIsaac, W., Tisler, A., Irvine, M., Saunders, A., Dunai, A., Rizo, C., Feig,
D. y Hamill, M. (2007). Mobile Phone–Based Remote Patient Monitoring System for
Referencias
167
Management of Hypertension in Diabetic Patients. American journal of hypertension,
20 (9), 942-948.
Lorig, K. R., Sobel, D. S., Stewart, A. L., Brown B. W. Jr., Bandura, A., Ritter, P.,
Gonzalez, V. M., Laurent, D. D. y Holman. H. R. (1999). Evidence suggesting that a
chronic disease self-management program can improve health status while reducing
hospitalization: a randomized trial. Medical Care, 37 (1), 5-14.
Mathers, C. D. y Loncar, D. (2006). Projections of Global Mortality and Burden of
Disease from 2002 to 2030. PLoS Med 3 (11).
Morón J., Luque R., Casilari, E. y Díaz, A. (2005). Monitorización Inteligente de
Pacientes Mediante Tecnologías Inalámbricas. Simposio de Computación Ubicua e
Inteligencia Ambiental (UCAmI 2005). Granada, España: Ed. Thompson.
National Center for Health Statistics (2011). Health, United States, 2011: With Special
Feature on Socioeconomic Status and Health. Hyattsville, MD. Disponible en
http://www.ncbi.nlm.nih.gov/books/NBK98752/pdf/TOC.pdf. Accedido el 22 de julio
de 2012.
Osakidetza, 2010. Estrategia para afrontar el reto de la cronicidad en Euskadi.
Disponible en http://cronicidad.euskadi.net/descargas/plan/EstrategiaCronicidad.pdf.
Accedido el 11 de julio de 2012.
Reenskaug, T. (1979). MVC XEROX PARC 1978-79. Disponible en
http://heim.ifi.uio.no/~trygver/themes/mvc/mvc-index.html. Accedido el 14 de julio de
2012.
Rudowski, R. (2003). Telemedicine in the Context of Different Medical Specialities.
The Polish Perspective. Pol J Pathol, 54 (3), 219-221. Disponible en
http://www.poljpathol.cm-uj.krakow.pl/03_3/RUD.pdf. Accedido el 15 de julio de
2012.
Referencias
168
Sagahyroon, A., Aloul, F., Al-Ali, A. R., Bahrololoum, M. S., Makhsoos, F. y Hussein,
N. (2011). Monitoring Patients’ Signs Wirelessly. J. Med. Imaging Health Inf. 1, 252-
255.
Sha, K., Zhan, G., Shi, W, Lumleyz, M., Wiholm, C. y Arnetz, B. (2008). SPA: a smart
phone assisted chronic illness self-management system with participatory sensing.
Proceedings of the 2nd International Workshop on Systems and Networking Support for
Health Care and Assisted Living Environments (HealthNet '08). Nueva York, Estados
Unidos: ACM.
Singh, D. (2008). How can chronic disease management programmes operate accross
care settings and providers? Disponible en
http://www.euro.who.int/__data/assets/pdf_file/0009/75474/E93416.pdf . Accedido el
17 de junio de 2012.
Suhrcke, M., Nugent, A., Stuckler, D. y Rocco, L. (2006). Chronic disease: an
economic perspective: Oxford Health Alliance.
Taitel, M., Kotses, H., Bernstein, I. L., Bernstein, D. J. y Creer, T. (1995). A Self-
Management Program for Adult Asthma. The Journal of Allergy and Clinical
Immunology, 25 (2), 529-540.
Trueman, P. (2009). Economic considerations of remote monitoring in chronic
conditions, Eurohealth, 15 (1), 10-12
WHO (2005). Preventing chronic disease: a vital investment. WHO global report,
Geneva. Disponible en http://www.who.int/chp/chronic_disease_report/en. Accedido el
24 de junio de 2012.
WHO (2002). Innovative care for chronic conditions: building blocks for action.
Disponible en http://www.who.int/chp/knowledge/publications/icccreport/en . Accedido
el 24 de junio de 2012.
Referencias
169
WHO. International Classification of Diseases (ICD). Disponible en
http://www.who.int/classifications/icd/en/. Accedido el 29 de junio de 2012.
WHO. The Anatomical Therapeutic Chemical Classification System with Defined Daily
Doses (ATC/DDD). Disponible en http://www.who.int/classifications/atcddd/en/ .
Accedido el 29 de junio de 2012.
Wooton, R., Craig, J. y Patterson, V. (2006). Introduction to Telemedicine: RSM Press,
2nd Edition. Disponible en
http://www.itg.be/tempupload/uploadfolder/Telemedicine/Introduction%20to%20Telem
edicine.pdf. Accedido el 15 de julio de 2012.
Wyatt, J. y Sullivan, F. (2005). ABC of health informatics: eHealth and the future:
Promise or peril? British medical journal, 331 (7529), 1391-1393
ANEXO A. ABREVIATURAS Y ACRÓNIMOS
ANEXO A. Abreviaturas y acrónimos
173
AAR: Axis Archive
AIHW: Australian Institute of Health and Welfare
APK: Application Package File
ATC: Anatomical, Therapeutic, Chemical classification system
Bluetooth SIG: Bluetooth Special Interest Group
CIE: Clasificación Internacional de Enfermedades (la traducción al castellano de ICD)
CVS: Concurrent Version System
DAFNE: DAta Food NEtworking
EPOC: Enfermedad Pulmonar Obstructiva Crónica
GSM: Global System for Mobile Communications
HL7: Health Level Seven
HTML: HyperText Markup Language
HTTP: HyperText Transfer Protocol
ICD: International Classification of Diseases (en castellano es CIE)
IDE: Integrated Development Environment
IDF: International Diabetes Federation
JAR: Java Archive
JCP: Java Community Process
Java EE: Java Enterprise Edition
LGPL: GNU Lesser General Public License
LOPD: Ley Orgánica de Protección de Datos
MAC: Media Access Control
MVC: Modelo-Vista-Controlador
OHA: Open Handset Alliance
OMS: Organización Mundial de la Salud (la traducción al castellano de WHO)
OpenGL: Open Graphics Library
PDA: Personal Digital Assistant
RFID: Radio Frequency IDentification
SDK: Software Development Kit
SDP: Service Discovery Protocol
UUID: Universally Unique IDentifier
VIH: Virus de la Inmunodeficiencia Humana
W3C: World Wide Web Consortium
ANEXO A. Abreviaturas y acrónimos
174
WAR: Web Application ARchive
WHO: World Health Organization (en castellano es la OMS)
XML: eXtensible Markup Language
ANEXO B. DESCRIPCIÓN DE LOS CASOS DE USO
ANEXO B. Descripción de los casos de uso
177
Se exponen en este capítulo de anexo la descripción de todos los casos de uso de
las aplicaciones que forman el sistema mostrado en el presente proyecto.
Descripción de los casos de uso de la aplicación móvil
• CU-01 Asociar paciente a la aplicación móvil Caso de Uso: CU-01 Asociar paciente a la aplicación móvil Breve descripción: Este caso de uso se encarga de asociar el paciente que usará la aplicación móvil con ésta. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso CU-02 Carga de datos del sistema. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de texto ‘ID del paciente’. • Botón ‘Comprobar paciente’. • Botón ‘Atrás’.
2.- El usuario especifica el ID del paciente en el campo de texto y pulsa el botón ‘Comprobar paciente’. 3.- La aplicación comprueba si existe algún paciente en el sistema con ese ID. Si existe se muestra una ventana emergente con el mensaje ‘Verifique los datos del paciente’, los datos personales del paciente( nombre, identificación y fecha de nacimiento), un mensaje debajo ‘El paciente seleccionado, ¿es el correcto?’ y finalmente dos botones:
• Botón ‘Sí’. Se asigna el paciente seleccionado al sistema. • Botón ‘No’. Se muestra un mensaje emergente temporal indicando que se ha de especificar de
nuevo el ID del paciente para encontrar al paciente correcto. 4.- El usuario pulsa el botón ‘Sí’. 5.- La aplicación asigna el paciente al sistema. Postcondiciones: 1.- El paciente queda asignado a la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Comprobar paciente’ sin especificar ningún ID o valor textual en el campo.
2.1.- La aplicación muestra el mensaje de error ‘El ID del paciente especificado es inválido. Ha de ser un número’.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Comprobar paciente’ especificando un valor válido en el campo ‘ID del paciente’ pero no hay ninguna conexión de Internet disponible en la aplicación móvil.
2.1.- La aplicación muestra el mensaje de error ‘No se puede buscar el paciente debido a que no
ANEXO B. Descripción de los casos de uso
178
existe ninguna conexión a Internet disponible’. Flujo alternativo 3: 2.- El usuario pulsa el botón ‘Comprobar paciente’ especificando un valor válido en el campo ‘ID del paciente’ pero no existe ningún paciente con ese ID en el sistema.
2.1.- La aplicación muestra el mensaje de error ‘No existe ningún paciente con el ID especificado’.
Flujo alternativo 4: 4.- El usuario pulsa el botón ‘No’.
4.1.- La ejecución del caso de uso volvería al paso 2. Flujo alternativo 5: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- Se muestra el menú inicial de configuración y finaliza la ejecución del caso de uso.
• CU-02 Carga de datos del sistema Caso de Uso: CU-02 Carga de datos del sistema Breve descripción: Este caso de uso se encarga de cargar los datos del sistema en la aplicación móvil. Precondiciones: 1.- Los datos del sistema no han sido cargados. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de texto ‘Ruta del Script de carga’. en él se especifica la ruta en la cual se encuentra almacenado el script de carga de datos del sistema.
• Botón ‘Cargar datos’. Realiza la carga de datos. • Botón ‘Atrás’. Vuelve al menú inicial de configuración de la aplicación.
2.- El usuario especifica la ruta donde se encuentra situado el fichero de script de carga de datos en el campo de texto ‘Ruta del Script de carga’ y pulsa el botón ‘Cargar datos’. 3.- La aplicación muestra una ventana emergente bloqueante con el texto ‘Cargando datos… (Puede llevar algunos minutos)’ en la que se ve puede ver el progreso de carga de los datos. Una vez finaliza la carga de los datos desaparece la ventana emergente y se muestra el texto ‘Datos cargados con éxito’. El botón ‘Cargar datos’ se inhabilita. 4.- El usuario pulsa el botón ‘Atrás’. 5.- La aplicación muestra el menú inicial de configuración y finaliza la ejecución del caso de uso. Postcondiciones: 1.- Quedan cargados los datos del sistema en la aplicación móvil. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- La aplicación muestra el menú inicial de configuración y finaliza la ejecución del caso de uso.
Flujo alternativo 2: 2.- El usuario especifica una ruta de un fichero que no existe.
2.1.- La aplicación muestra el mensaje de error ‘No se ha encontrado el fichero: ‘, junto con la ruta especificada por el usuario.
ANEXO B. Descripción de los casos de uso
179
Flujo alternativo 3: 2.- El usuario especifica una ruta de un fichero que no se corresponde a la ruta del script de carga de datos.
2.1.- La aplicación muestra el mensaje de error ‘Se ha producido un error al cargar los datos: ‘, junto con el mensaje de error específico que se haya producido.
• CU-03 Introducir medición Caso de Uso: CU-03 Introducir medición Breve descripción: Este caso de uso se encarga de introducir los valores de la medición en la aplicación. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de haber seleccionar la opción ‘Medición’ en el menú principal de la aplicación. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de lista desplegable ‘Tipo de medida’ con los valores ‘Tensión arterial’, ‘Temperatura corporal’ y ‘Glucosa en sangre’. El desplegable no tendrá un valor vacío y tendrá el valor por defecto ‘Tensión arterial’.
• Campo de lista desplegable ‘Modo de obtención’ con los valores ‘Manual’ y ‘Mediante sensor’. El desplegable no tendrá un primer valor por defecto vacío y tendrá el valor por defecto ‘Manual’.
• Botón ‘Aceptar’. Para aceptar los valores especificados en los campos de listas desplegables. • Botón ‘Atrás’. Para volver al menú principal de la aplicación.
2.- El usuario selecciona valores en las listas desplegables dejando especificado el valor ‘Manual’ en el campo ‘Modo de obtención’ y pulsa el botón ‘Aceptar’. 3.- Comienza la ejecución del caso de uso ‘CU-05 Obtener medición manualmente’. Postcondiciones: 1.- Queda especificados el tipo de medida y el modo de obtenerla. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ habiendo especificado el valor ‘Mediante sensor’ en el desplegable ‘Modo de obtención’.
2.1.- Comienza la ejecución del caso de uso ‘CU-04 Obtener medición mediante sensor biométrico’.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
ANEXO B. Descripción de los casos de uso
180
2.1.- Se accede al menú principal de la aplicación.
• CU-04 Obtener medición mediante sensor biométrico Caso de Uso: CU-04 Obtener medición mediante sensor biométrico Breve descripción: Este caso de uso se encarga de recoger los valores de la medición en la aplicación mediante un sensor biométrico (tensiómetro, glucómetro, termómetro, etc.). Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medición’ en el menú principal de la aplicación. 4.- El usuario ha de haber seleccionado el valor ‘Mediante sensor’ en el campo desplegable ‘Modo de obtención’ en la ejecución del caso de uso CU-03 Introducir medición. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Campo de lista desplegable ‘Sensor’ con los sensores que haya disponibles en la aplicación para el tipo de medición que hubiera especificado el usuario en la ejecución del caso de uso CU-03 Introducir medición.
• Botón ‘Aceptar’. • Botón ‘Atrás’.
2.- El usuario selecciona un sensor y pulsa el botón ‘Aceptar’. 3.- Aparece una ventana emergente bloqueante indicando que la aplicación está a la espera de recibir la medición. 4.- El usuario realiza la medición con el sensor biométrico. 5.- La aplicación lee los valores de la medición enviados por el sensor biométrico y almacenan el/los valor/es de la medición. Finalizaría la ejecución de este caso de uso y comenzaría la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones: 1.- Los valores de la medición quedan almacenados en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ sin seleccionar ningún valor en el listado desplegable de sensores.
2.1.- La aplicación muestra un mensaje indicando que se ha de seleccionar un sensor. Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
ANEXO B. Descripción de los casos de uso
181
2.1.- La aplicación finalizaría la ejecución de este caso de uso y del caso de uso CU-02 Introducir medición. Se mostraría el menú principal de la aplicación.
Flujo alternativo 3: 4.- El usuario durante un tiempo prudencial no realiza ninguna medición con el sensor que ha especificado.
4.1.- La aplicación muestra un mensaje indicando que no se ha recibido ninguna medición del sensor especificado.
• CU-05 Obtener medición manualmente Caso de Uso: CU-05 Obtener medición manualmente Breve descripción: Este caso de uso se encarga de recoger del usuario los valores de la medición que ha obtenido el paciente de un sensor biométrico que no puede comunicarse con la aplicación. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medición’ en el menú principal de la aplicación. 4.- El usuario ha de haber seleccionado el valor ‘Manual’ en el campo desplegable ‘Modo de obtención’ en la ejecución del caso de uso CU-03 Introducir medición. Flujo principal: 1.- La aplicación muestra los siguientes elementos dependiendo del valor seleccionado en el campo desplegable ‘Tipo de medida’ de la ejecución del caso de uso CU-03 Introducir medición:
• Campos asociados al tipo de medida seleccionado por el usuario en el caso de uso CU-03 Introducir medición. Según el valor se mostrarán unos campos u otros. Estos campos son obligatorios de cumplimentar por el usuario. Se valores especificados en los campos se validarán para evitar que se especifiquen tanto valores inválidos como valores imposibles (Ejemplos: una presión arterial negativa, una temperatura de 10 º C, etc.) Casos posibles:
o Valor ‘Tensión arterial’: Campo de texto ‘Presión diastólica’. Campo de texto ‘Presión sistólica’.
o Valor ‘Temperatura corporal’ Campo de texto ‘Temperatura corporal’
o Valor ‘Glucosa en sangre’: Campo de texto ‘Glucosa en sangre’.
• Botón ‘Aceptar’. Para almacenar en la aplicación los valores de la medición y comenzar el caso de uso ‘CU-11 Mostrar recomendaciones al usuario’.
• Botón ‘Atrás’. Para finalizar la ejecución de este caso de uso y comenzar la ejecución del caso de
ANEXO B. Descripción de los casos de uso
182
uso CU-03 Introducir medición.
Todos los campos de texto son obligatorios de cumplimentar. 2.- El usuario especifica valores en los campos de texto y pulsa el botón ‘Aceptar’. 3.- Se almacenan el/los valor/es de la medida, finalizaría la ejecución de este caso de uso y comenzaría la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones: 1.- La medición queda almacenada en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Aceptar’ sin seleccionar especificar un valor en alguno de los campos de texto.
2.1.- La aplicación muestra un mensaje indicando que los campos son obligatorios. Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- La aplicación finaliza la ejecución de este caso de uso y la del CU-02 Introducir medición. Se mostraría el menú principal de la aplicación.
Flujo alternativo 3: 2.- El usuario especifica un valor inválido en alguno de los campos y pulsa el botón ‘Aceptar’.
2.1.- La aplicación muestra un mensaje indicando la situación inválida.
• CU-06 Introducir alimentación Caso de Uso: CU-06 Introducir alimentación Breve descripción: En este caso de uso el paciente introduce la alimentación que toma. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medicamentos’ en el menú principal de la aplicación. Flujo principal: 1.-Aparecerá una pantalla en la que se encontrarán los siguientes elementos: - Campo autocompletado ‘Alimento’: en este campo se podrá introducir el alimento. La aplicación completará texto del alimento en el campo introduciendo varios caracteres en él. - Campo ‘Hora’. En este campo se introducirá la hora de la toma del medicamento con el formato HH:MM, siendo HH la hora en modo AM y MM los minutos de 00 a 59. - Botón con imagen de reloj al lado derecho del campo ‘Hora’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una hora en el campo ‘Hora’.
ANEXO B. Descripción de los casos de uso
183
- Campo ‘Día’. En este campo se introducirá la fecha (día, mes y año) en la que se produjo la ingesta del alimento con el formato DD-MM-YYYY (siendo DD el día de 1 a 31, MM el mes de 1 al 12 e YYYY el año con cuatro dígitos). - Botón con imagen de un calendario al lado derecho del campo ‘Día’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una fecha para el campo ‘Día’. - Campo de barra deslizante ‘Raciones’. En este campo se introducirán las raciones del alimento que se hubieran ingerido. Los valores de la barra deslizante empezarán en media ración y terminarán en tres raciones. El valor seleccionado por defecto en la barra será una ración. Los valores posibles serán: ‘media ración’, ‘una ración’, ‘una ración y media’, ‘dos raciones’, ‘dos raciones y media’ y ‘tres raciones’. - Botón ‘Introducir medicamento’. Almacena el medicamento. - Botón ‘Atrás’. Pulsándolo se accede al menú principal de la aplicación. 2.- El usuario pulsa el botón ‘Introducir alimento’. 3.- Se almacena el medicamento, si el día y la hora especificados por el usuario son posteriores a la hora del sistema más 10 minutos finaliza la ejecución de este caso de uso y se accede al menú principal. Si el día y la hora especificados por el usuario son anteriores a la hora del sistema más diez minutos finaliza la ejecución del caso de uso y comienza la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones:
1. El alimento introducido queda almacenado. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 2.- El usuario introduce un valor inválido en el campo ‘Día’ y pulsa el botón ‘Introducir alimento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Día’. Flujo alternativo 3: 2.- El usuario introduce un valor inválido en el campo ‘Hora’ y pulsa el botón ‘Introducir alimento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Hora’.
Flujo alternativo 5: 2.- El usuario introduce pulsa el botón ‘Introducir alimento’ estando alguno de estos campos sin cumplimentar: ‘Día’, ‘Hora’, ‘Alimento’.
2.1.- Se muestra un mensaje indicando que los campos ‘Alimento’, ‘Día’ y ‘Hora’ son campos obligatorios.
• CU-07 Introducir actividad Caso de Uso: CU-07 Introducir actividad Breve descripción: En este caso de uso el paciente introduce la una actividad cotidiana que ha realizado. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
ANEXO B. Descripción de los casos de uso
184
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Actividades’ en el menú principal de la aplicación. Flujo principal: 1.-Aparecerá una pantalla en la que se encontrarán los siguientes elementos: - Campo autocompletado ‘Actividad’: en este campo se podrá introducir la actividad cotidiana. La aplicación completará texto de la actividad en el campo introduciendo varios caracteres en él. - Campo ‘Hora’. En este campo se introducirá la hora de la realización de la actividad con el formato HH:MM, siendo HH la hora en modo AM y MM los minutos de 00 a 59. - Botón con imagen de reloj al lado derecho del campo ‘Hora’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una hora en el campo ‘Hora’. - Campo ‘Día’. En este campo se introducirá la fecha (día, mes y año) en la que se produjo la realización de la actividad con el formato DD-MM-YYYY (siendo DD el día de 1 a 31, MM el mes de 1 al 12 e YYYY el año con cuatro dígitos). - Botón con imagen de un calendario al lado derecho del campo ‘Día’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una fecha para el campo ‘Día’. - Campo de barra deslizante ‘Duración’. En este campo se introducirá la duración de la actividad realizada. Los valores de la barra deslizante empezarán en cuarto de hora y terminarán en cuatro horas. El valor seleccionado por defecto en la barra será un cuarto de hora. Los valores posibles serán: ‘cuarto de hora’, ‘media hora’, ‘cuarenta y cinco minutos’, ‘una hora’, ‘una hora y media’, ‘dos horas’, ‘dos horas y media’, ‘tres horas’, ‘tres horas y media’ y ‘cuatro horas’. - Botón ‘Introducir actividad’. Almacena la actividad. - Botón ‘Atrás’. Pulsándolo se accede al menú principal de la aplicación. 2.- El usuario pulsa el botón ‘Introducir actividad’. 3.- Se almacena la actividad, si el día y la hora especificados por el usuario son posteriores a la hora del sistema más 10 minutos finaliza la ejecución de este caso de uso y se accede al menú principal. Si el día y la hora especificados por el usuario son anteriores a la hora del sistema más diez minutos finaliza la ejecución del caso de uso y comienza la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones:
2. La actividad introducida queda almacenada. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’.
2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 2.- El usuario introduce un valor inválido en el campo ‘Día’ y pulsa el botón ‘Introducir actividad’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Día’. Flujo alternativo 3: 2.- El usuario introduce un valor inválido en el campo ‘Hora’ y pulsa el botón ‘Introducir actividad’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Hora’.
Flujo alternativo 5: 2.- El usuario introduce pulsa el botón ‘Introducir actividad’ estando alguno de estos campos sin
ANEXO B. Descripción de los casos de uso
185
cumplimentar: ‘Día’, ‘Hora’, ‘Actividad’. 2.1.- Se muestra un mensaje indicando que los campos ‘Actividad’, ‘Día’ y ‘Hora’ son campos obligatorios.
• CU-08 Introducir medicación Caso de Uso: CU-08 Introducir medicación Breve descripción: En este caso de uso el paciente introduce en el sistema la medicación que está tomando. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Medicamentos’ en el menú principal de la aplicación. Flujo principal: 1.-Aparecerá una pantalla en la que se encontrarán los siguientes elementos: - Campo autocompletado ‘Medicamento’: en este campo se podrá introducir el medicamento. La aplicación completará texto del medicamento en el campo introduciendo varios caracteres en él. - Campo ‘Hora’. En este campo se introducirá la hora de la toma del medicamento con el formato HH:MM, siendo HH la hora en modo AM y MM los minutos de 00 a 59. - Botón con imagen de reloj al lado derecho del campo ‘Hora’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una hora en el campo ‘Hora’. - Campo ‘Día’. En este campo se introducirá la fecha (día, mes y año) en la que se produjo la toma del medicamento con el formato DD-MM-YYYY (siendo DD el día de 1 a 31, MM el mes de 1 al 12 e YYYY el año con cuatro dígitos). - Botón con imagen de un calendario al lado derecho del campo ‘Día’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una fecha para el campo ‘Día’. - Campo de barra deslizante ‘Dosis’. En este campo se introducirá las dosis tomadas del medicamento. Los valores de la barra deslizante empezarán en una dosis y terminarán en diez dosis. El valor seleccionado por defecto en la barra será una dosis. - Botón ‘Introducir medicamento’. Almacena el medicamento. - Botón ‘Atrás’. Pulsándolo se accede al menú principal de la aplicación. 2.- El usuario pulsa el botón ‘Introducir medicamento’. 3.- Se almacena el medicamento, si el día y la hora especificados por el usuario son posteriores a la hora del sistema más 10 minutos finaliza la ejecución de este caso de uso y se accede al menú principal. Si el día y la hora especificados por el usuario son anteriores a la hora del sistema más diez minutos finaliza la ejecución del caso de uso y comienza la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones:
3. El medicamento introducido queda almacenado. Flujo alternativo 1:
ANEXO B. Descripción de los casos de uso
186
2.- El usuario pulsa el botón ‘Atrás’. 2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación.
Flujo alternativo 2: 2.- El usuario introduce un valor inválido en el campo ‘Día’ y pulsa el botón ‘Introducir medicamento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Día’. Flujo alternativo 3: 2.- El usuario introduce un valor inválido en el campo ‘Hora’ y pulsa el botón ‘Introducir medicamento’.
2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Hora’.
Flujo alternativo 5: 2.- El usuario introduce pulsa el botón ‘Introducir medicamento’ estando alguno de estos campos sin cumplimentar: ‘Día’, ‘Hora’, ‘Medicamento’.
2.1.- Se muestra un mensaje indicando que los campos ‘Medicamento’, ‘Día’ y ‘Hora’ son campos obligatorios.
• CU-09 Introducir síntoma Caso de Uso: CU-09 Introducir síntoma Breve descripción: En este caso de uso el paciente introduce en el sistema los síntomas que esté experimentando. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha de seleccionar la opción ‘Síntomas’ en el menú principal de la aplicación. Flujo principal: 1.-Aparecerá una pantalla en la que se encontrarán los siguientes elementos: - Campo autocompletado ‘Síntoma’: en este campo se podrá introducir el síntoma. La aplicación completará texto del síntoma en el campo introduciendo varios caracteres en él. - Campo ‘Hora’. En este campo se introducirá la hora a la que se experimentó el síntoma con el formato HH:MM, siendo HH la hora en modo AM y MM los minutos de 00 a 59. - Botón con imagen de reloj al lado derecho del campo ‘Hora’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una hora en el campo ‘Hora’. - Campo ‘Día’. En este campo se introducirá la fecha (día, mes y año) en la que se produjo la toma del medicamento con el formato DD-MM-YYYY (siendo DD el día de 1 a 31, MM el mes de 1 al 12 e YYYY el año con cuatro dígitos). - Botón con imagen de un calendario al lado derecho del campo ‘Día’. Pulsando sobre este botón se mostrará una ventana que obtendrá el foco de la aplicación en la que se podrá seleccionar una fecha para el campo ‘Día’. - Botón ‘Introducir síntoma’. Almacena el síntoma. - Botón ‘Atrás’. Pulsándolo se accede al menú principal de la aplicación.
ANEXO B. Descripción de los casos de uso
187
2.- El usuario pulsa el botón ‘Introducir síntoma’. 3.- Se almacena el síntoma y comienza la ejecución del caso de uso CU-11 Mostrar recomendaciones al usuario. Postcondiciones:
1. El síntoma introducido queda almacenado. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’. 2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 2.- El usuario introduce un valor inválido en el campo ‘Día’ y pulsa el botón ‘Introducir síntoma’. 2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Día’. Flujo alternativo 3: 2.- El usuario introduce un valor inválido en el campo ‘Hora’ y pulsa el botón ‘Introducir síntoma’. 2.1.- Se muestra un mensaje indicando que se ha de introducir un valor válido en el campo ‘Hora’. Flujo alternativo 5: 2.- El usuario introduce pulsa el botón ‘Introducir síntoma’estando alguno de estos campos sin cumplimentar: ‘Día’, ‘Hora’, ‘Síntoma’. 2.1.- Se muestra un mensaje indicando que los campos ‘Síntoma’, ‘Día’ y ‘Hora’ son campos obligatorios.
• CU-10 Sincronizar información con el servidor remoto Caso de Uso: CU-10 Sincronizar información con el servidor remoto Breve descripción: Este caso de uso permite la sincronización de la información de la aplicación móvil con el servidor remoto. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- Se debe haber seleccionado la opción ‘Sincronizar’ desde el menú principal. Flujo principal: 1.- La aplicación muestra los siguientes elementos:
• Botón ‘Sincronizar datos’. Para comenzar el proceso de sincronización. • Botón ‘Atrás’. Para volver al menú principal de la aplicación.
2.- El usuario pulsa el botón ‘Sincronizar datos’.
ANEXO B. Descripción de los casos de uso
188
3.- La aplicación detecta que existe conexión a Internet disponible. Muestra una ventana emergente bloqueante con una imagen animada de espera (indicando que la aplicación está procesando datos) y con el mensaje ‘Enviando los datos y actualizando los datos internos de la aplicación. Por favor, espere...’. La aplicación realiza las siguientes operaciones:
• Establece conexión con el servidor remoto. • Envía los datos de seguimiento del paciente que no hayan sido enviados (mediciones,
actividades, alimentos, medicación y síntomas). Los que ya se hubieran enviado, no se envían.
• Elimina los datos que ha enviado al servidor remoto y tienen más de una semana de antigüedad.
• Recupera los datos de catálogos que hayan sido creados o modificados en el servidor remoto después de la última sincronización. Es decir, se recuperan los datos de catálogos que hayan sido creados o modificados en el servidor remoto pero no hayan sido creados en la aplicación móvil, o se encuentren creados pero tengan valores desactualizados.
• Actualiza los datos recuperados en la operación anterior. • Recupera los datos que hayan sido creados en el servidor remoto y no existan en la
aplicación. • Crea los datos recuperados en la operación anterior. • Hace desaparecer la ventana emergente bloqueante con la imagen animada de espera. • Muestra el mensaje ‘Datos enviados con éxito. Aplicación actualizada con éxito’
indicando que la operación de sincronización se ha realizado correctamente. Los datos correspondientes al seguimiento del paciente que se enviarán al servicio web corresponden a: o Valores de mediciones
Tensión arterial Temperatura corporal Glucosa en sangre
o Actividades realizadas o Alimentos ingeridos o Medicamentos tomados o Síntomas experimentados
Los catálogos de los que se comprobará si se han creado o modificado registros desde la última fecha de sincronización de la aplicación móvil son: o Sensores o Tipos de sensores o Enfermedades o Clases de enfermedades o Mensajes de recomendación asociados a rangos de medición de temperatura corporal o Mensajes de recomendación asociados a rangos de medición de tensión arterial o Mensajes de recomendación asociados a rangos de medición de glucosa en sangre o Síntomas o Mensajes de recomendación asociados a síntomas o Actividades o Mensajes de recomendación asociados a actividades o Medicamentos o Mensajes de recomendación asociados a medicamentos o Alimentos o Clases de alimentos o Subclases de alimentos o Mensajes de recomendación asociados a alimentos
4.- El usuario pulsa el botón ‘Atrás’. 5.- Finaliza la ejecución del caso de uso y se muestra el menú principal de la aplicación.
ANEXO B. Descripción de los casos de uso
189
Postcondiciones: 1.- La aplicación envía los datos al servidor remoto que tuviera pendientes de envío. 2.- La aplicación actualiza los datos que tuviera desactualizados con respecto a los del servidor remoto. 3.- La aplicación crea los datos que existieran en el servidor remoto y no estuvieran en la aplicación. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Atrás’. 2.1.- Finalizaría la ejecución del caso de uso y se accedería al menú principal de la aplicación. Flujo alternativo 2: 3.- La aplicación detecta que no existe conectividad con Internet. 3.1.- Se muestra el mensaje al usuario indicando que no existe conectividad con Internet con lo que no puede sincronizarse la información con el servidor remoto. Flujo alternativo 3: 3- La aplicación detecta que se ha producido un error en la sincronización de datos.
3.1.- Se muestra un mensaje al usuario indicando el error.
• CU-11 Mostrar recomendaciones al usuario Caso de Uso: CU-11 Mostrar recomendaciones al usuario Breve descripción: Este caso de uso se encarga de mostrar recomendaciones al usuario según los datos que éste introduzca en el sistema. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- El usuario ha introducido un elemento en la aplicación mediante alguno de estos casos de uso: CU-04 Obtener medición mediante sensor biométrico, CU-05 Obtener medición manualmente, CU-06 Introducir alimentación, CU-07 Introducir actividad, CU-08 Introducir medicación, CU-09 Introducir síntoma. Flujo principal: 1.- La aplicación muestra una ventana emergente bloqueante con una imagen animada de espera (significando que la aplicación está procesando datos) y con el mensaje ‘Obteniendo recomendaciones. Por favor, espere…’. 2.- La aplicación busca recomendaciones atendiendo a los siguientes criterios:
o El tipo de dato que se ha introducido: alimento, medicación, síntoma, actividad, medición. o El tipo de medición, en el caso de que se hubiera introducido una medición. o El rango de valores en el que se encuentre el valor introducido en el caso de que lo que se
hubiera introducido hubiera sido una medición.
ANEXO B. Descripción de los casos de uso
190
o A la clase o categoría de elemento al que pertenezca el elemento introducido si aplicase alguna (clase y tipo de alimento, código ATC del medicamento, etc.).
Una vez se han recuperado las recomendaciones que están asociadas al elemento que ha introducido el usuario, para cada una de las recomendaciones recuperadas se comprueba que tiene sentido ser mostrada teniendo en cuenta los siguientes factores:
o Los datos personales del paciente: enfermedades, altura, peso, si es fumador, etc. o Los datos que se hubieran introducido anteriormente.
Estos factores que indican si una recomendación tiene sentido ser mostrada se especificarán mediante una sentencia SQL que puede tener asociada la recomendación. Esta sentencia SQL siempre recuperará el número de elementos que se encuentran en un determinado estado en un momento particular. Si la recomendación no tiene asociada ninguna sentencia SQL entonces se muestra la recomendación directamente. Si la recomendación tiene asociada una sentencia SQL entonces para que se muestre la recomendación la sentencia SQL ha de recuperar un número positivo de elementos. La aplicación muestra en una ventana emergente las recomendaciones que se hubieran recuperado para ese elemento y tienen sentido ser mostradas según el contexto del paciente (sus datos personales y los datos que hubiera introducido en la aplicación). 3.- El usuario quita la ventana emergente (mediante por ejemplo el botón ‘Atrás’ del dispositivo móvil) 4.- Si el elemento introducido por el usuario en las precondiciones es un actividad, un alimento o una medicación y la hora y el día especificados por usuario se corresponden a menos de diez minutos antes de la fecha y hora del propio dispositivo móvil se muestra una ventana emergente preguntando al usuario si en base a las recomendaciones mostradas va a realizar finalmente esa acción especificada. En otro caso, no se muestra la ventana emergente. El objetivo de la ventana emergente preguntando al usuario si va a realizar la acción especificada es representar la situación de que el usuario puede recibir recomendaciones en las que se le aconseja que no realice la acción recién especificada. En esos casos, se le permite al usuario decidir si va a realizar esa acción (tomar un medicamento, alimento, etc.) y dejarla almacenarla en la aplicación, o bien, no va a realizarla y la aplicación borraría la acción recién especificada. Los síntomas experimentados o las mediciones al ser sucesos que el usuario no puede evitar la aplicación no muestra la ventana emergente que pregunta al usuario si va a realizar finalmente la acción especificada. Si se introduce una acción en la aplicación y un día y una fecha anteriores a 10 minutos antes de la fecha y de la hora del propio dispositivo móvil, entonces se interpreta que el usuario ya realizó esa acción en el pasado. Al haber sucedido ya esa acción, no tiene sentido preguntarle al usuario si va a realizar algo que ya realizó. La ventana emergente de confirmación de la realización de la acción tendrá dos botones:
- Botón ‘Sí’. Finaliza la ejecución del caso de uso. - Botón ‘No’. Borra la acción recién especificada por el usuario y finaliza la ejecución del caso de
uso. 5.- El usuario pulsa el botón ‘Sí’ y finaliza la ejecución del caso de uso. Postcondiciones: 1.- Al finalizar la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste (CU-04 Obtener medición mediante sensor biométrico, CU-05 Obtener medición manualmente, CU-06 Introducir alimentación, CU-07 Introducir actividad, CU-08 Introducir medicación, CU-09 Introducir síntoma). Flujo alternativo 1: 5.- El usuario pulsa el botón ‘No’.
5.1.- La aplicación borra la acción recién introducida por el usuario (medicación, alimento,
ANEXO B. Descripción de los casos de uso
191
síntoma, etc.). Es decir, si el usuario ha leído las recomendaciones y ha decidido no llevar a cabo esa acción entonces se considera que el usuario no la llevó a cabo y se borra de la aplicación.
5.2.- Finaliza la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste.
Flujo alternativo 2: 3.- La aplicación no encuentra ninguna recomendación adecuada a lo recién especificado con respecto al contexto actual (datos personales del paciente y datos introducidos anteriormente en la aplicación).
3.1.- La aplicación muestra el mensaje de que no se han encontrado recomendaciones para la acción especificada.
3.2.- Finaliza la ejecución del caso de uso y continúa la ejecución del caso de uso que precedió a éste.
• CU-12 Mostrar recomendaciones al usuario Caso de Uso: CU-12 Mostrar histórico Breve descripción: Este caso de uso se encarga de mostrar al paciente los datos de seguimiento que ha introducido en los últimos siete días. Precondiciones: 1.- Se han de haber cargado los datos del sistema en la aplicación mediante la ejecución del caso de uso
CU-02 Carga de datos del sistema. La acción de la carga inicial de los datos del sistema sólo se realiza una vez.
2.- Se ha haber asociado el paciente a la aplicación móvil mediante la ejecución del caso de uso CU-01
Asociar paciente a la aplicación móvil. La acción de asociar el paciente al móvil sólo se realiza una sola vez. Es decir, una vez se asocie el paciente al móvil, ya quedaría asociado en las siguientes veces que se arranque la aplicación.
3.- Se debe haber seleccionado la opción ‘Histórico’ desde el menú principal. Flujo principal: 1.- La aplicación muestra el listado de los elementos de seguimiento del paciente ordenados cronológicamente por la fecha en la que el paciente especificó que ocurrió el suceso, mostrándose primero los sucesos más recientes.
Los sucesos del seguimiento del paciente que se mostrarán podrán ser de los siguientes tipos: o Mediciones realizadas o Actividades realizadas o Medicamentos tomados o Alimentos ingeridos o Síntomas experimentados
Se muestra para cada suceso: o La fecha en la que especificó el paciente que ocurrió. o La hora en la que especificó el paciente que ocurrió. o La descripción del suceso:
El tipo de medición y el/los valor/es de las mediciones (caso de mediciones). El nombre del medicamento (caso de medicamentos que tomó el paciente).
ANEXO B. Descripción de los casos de uso
192
El nombre del alimento (caso de alimentos ingeridos por el paciente). La descripción de la actividad realizada (caso de actividades). El nombre del síntoma (caso de síntomas).
o Información adicional del suceso: Dosis tomadas del medicamento (caso de medicamentos que tomó el paciente). Raciones tomadas del alimento (caso de alimentos ingeridos por el paciente). Duración de la actividad realizada (caso de actividades)
Postcondiciones: 1.- Ninguna.
Descripción de los casos de uso de la aplicación web
• CU-21 Autenticar usuario
Caso de Uso: CU-21 Autenticar usuario Breve descripción: Este caso de uso se encarga de pedir identificación al usuario con rol de médico para autenticarlo con respecto al sistema. Precondiciones: 1.- Se ha accedido a la aplicación web sin estar autentificado en ella. Flujo principal: 1.- Se muestra una ventana en la que se solicita el nombre de usuario y la contraseña. Se muestra un botón ‘Entrar’ debajo de los campos. 2.- El usuario introduce su nombre de usuario y su contraseña en la ventana y pulsa el botón ‘Entrar’. 3.- La aplicación verifica que el nombre del usuario y su contraseña son correctos y se accede a la pantalla de inicio de la aplicación. Postcondiciones: 1.- Si el usuario escribió el nombre de usuario y la contraseña asociada a él correctamente se accede a la pantalla de inicio de la aplicación. Flujo alternativo 1: 3.- La aplicación verifica que el nombre de usuario no existe o que existe pero la contraseña para ese usuario es incorrecta.
3.1.- Aparece el mensaje de error ‘Usuario y/o contraseña inválido/s’.
• CU-22 Registrar nuevo paciente Caso de Uso: CU-22 Registrar nuevo usuario Breve descripción:
ANEXO B. Descripción de los casos de uso
193
Este caso de uso se encarga de recoger datos del paciente para registrarlo en el sistema. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación. 2.- Se ha seleccionado la opción del menú ‘Nuevo Paciente’ Flujo principal: 1.- Se muestra en la pantalla los siguientes elementos (Todos los campos de texto son obligatorios de cumplimentar):
• Campo de texto ‘Nombre’. • Campo de texto ‘Primer apellido’. • Campo de texto ‘Segundo apellido’. • Campo de texto ‘Dirección’. • Campo de texto ‘Teléfono móvil’. • Campo de texto ‘Teléfono fijo’. • Campo de texto ‘Teléfono de contacto de un familiar’. • Campo de texto ‘E-mail’. Este campo de texto tendrá que tener un formato de e-mail válido. • Campo de texto ‘NSS’. Número de la Seguridad Social. • Campo de texto ‘Número de identificación’. • Campo de fecha ‘Fecha de nacimiento’. Este campo ha de tener una fecha con formato válido. • Botón con icono de un calendario al lado del campo de fecha ‘Fecha de nacimiento’. Pulsando
sobre él se mostrará una ventana en la que se podrá seleccionar una fecha. Seleccionando una fecha se mostrará automáticamente en el campo de fecha ‘Fecha de nacimiento’.
• Casilla de selección con valores auto-excluyentes ‘Sexo’ con los valores ‘Varón’ y ‘Mujer’. • Campo de texto ‘Altura’. Este campo de texto se validará de que se especifique en él un número
válido y un valor válido (no se aceptarán alturas negativas ni superiores a tres metros). • Campo de texto ‘Peso’. Este campo de texto validará de que se especifique en él un número
válido. • Casilla de verificación ‘Consumidor regular de alcohol’. • Casilla de verificación ‘Fumador de tabaco’. • Casilla de verificación ‘Consumidor regular de cafeína’. • Botón ‘Limpiar’. Borra los valores especificados. • Botón ‘Salvar’. Guarda los datos del paciente introducido.
2.- El usuario especifica valores en los campos y pulsa el botón ‘Salvar’. 3.- Se validan todos los campos como válidos. Se almacenan los datos del paciente. Postcondiciones: 1.- Los datos del paciente quedan almacenados en el sistema (base de datos). Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Salvar’ estando sin cumplimentar algún campo de texto.
2.1.- La aplicación muestra un mensaje sobre el campo de texto que no se ha especificado.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Salvar’ habiendo especificado algún valor inválido en alguno de los campos de texto (e-mail, teléfono, altura, peso, etc.).
2.1.- La aplicación muestra un mensaje de error de validación sobre el campo en el que se hubiera especificado algún valor inválido.
ANEXO B. Descripción de los casos de uso
194
• CU-23 Seleccionar paciente Caso de Uso: CU-23 Seleccionar paciente Breve descripción: Mediante este caso de uso el usuario puede seleccionar un paciente de entre todos los que estén asignados a él utilizando criterios de acotación. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación. 2.- El usuario ha seleccionado la opción del menú ‘Seleccionar paciente’ o bien ha seleccionado alguna de las opciones del menú ‘Ver mediciones del paciente’ o ‘Ver actividad del paciente’ sin haber seleccionado un paciente previamente. Flujo principal: 1.- La aplicación muestra una pantalla en la que aparecen los siguientes campos de acotación más los siguientes botones: - Nombre. Campo de acotación. Filtra por el nombre del paciente. - Primer apellido. Campo de acotación. Selecciona por el primer apellido del paciente. - Segundo apellido. Campo de acotación. Filtra por el segundo apellido del paciente. - Número Seguridad Social. Campo de acotación. Acota por el número de la seguridad social del
paciente. - Número identificación. Campo de acotación. Filtra por el número de identificación (DNI, Tarjeta de
residencia, Tarjeta Consultar, et.) del paciente - Teléfono: Campo de acotación. Selecciona los pacientes que tengan asociado ese número de
teléfono. - Botón ‘Cuantificar’. Al pulsarlo se muestra por pantalla el número de pacientes que cumplen con
los criterios de búsqueda especificados. - Botón ‘Buscar’. Al pulsarlo se muestra el listado de pacientes que cumplen los criterios de
búsqueda. - Botón ‘Limpiar’: Al usarlo se quitan los valores establecidos en los campos de acotación.
2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Buscar’. 3.- La aplicación muestra el listado de pacientes que cumplen con los criterios de selección. El listado incluirá los mismos campos que los de acotación. Es decir: - Nombre. Nombre del paciente. - Primer apellido. Primer apellido del paciente. - Segundo apellido. Segundo apellido del paciente. - Número Seguridad Social. Número de la seguridad social del paciente. - Número identificación. Número de identificación (DNI, Tarjeta de residencia, Tarjeta Consultar,
et.) del paciente - Fecha de Nacimiento. Fecha de nacimiento del paciente.
En el listado de pacientes se mostrará una casilla de selección autoexcluyente asociada a cada paciente y un botón ‘Seleccionar’. 4.- El usuario selecciona un paciente usando la casilla de selección asociada a él y pulsa el botón ‘Seleccionar’. 5.- La aplicación almacena en la sesión del usuario el paciente seleccionado. Postcondiciones: 1.- El paciente seleccionado queda registrado en la sesión del usuario. Flujo alternativo 1:
ANEXO B. Descripción de los casos de uso
195
2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Cuantificar’. 2.1.- La aplicación muestra el número de pacientes que cumplen con los criterios de acotación del usuario. Flujo alternativo 2: 2.- El usuario establece varios criterios de acotación y pulsa el botón ‘Limpiar’. 2.1.- La aplicación deshace los cambios introducidos por el usuario en los criterios de acotación. Flujo alternativo 3: 4.- El usuario pulsa el botón ‘Seleccionar’ sin haber marcado la casilla de selección de ningún paciente. 4.1.- La aplicación muestra un mensaje indicando que no se ha de seleccionado el paciente.
• CU-24 Actualizar datos personales del paciente Caso de Uso: CU-24 Actualizar datos personales del paciente Breve descripción: Este caso de uso se encarga de actualizar los datos personales del paciente que hubiesen cambiado con el tiempo (si el paciente deja de fumar, cambia su peso, de número de teléfono, domicilio, etc.). Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación. 2.- Se ha seleccionado la opción del menú ‘Actualizar Datos del Paciente’ Flujo principal: 1.- Se muestra en la pantalla los siguientes elementos:
• Campo de texto ‘Nombre’. • Campo de texto ‘Primer apellido’. • Campo de texto ‘Segundo apellido’. • Campo de texto ‘Dirección’. • Campo de texto ‘Teléfono móvil’. • Campo de texto ‘Teléfono fijo’. • Campo de texto ‘Teléfono de contacto de un familiar’. • Campo de texto ‘E-mail’. Este campo de texto tendrá que tener un formato de e-mail válido. • Campo de texto ‘NSS’. Número de la Seguridad Social. • Campo de texto ‘Número de identificación’. • Campo de fecha ‘Fecha de nacimiento’. Este campo ha de tener una fecha con formato válido. • Botón con icono de un calendario al lado del campo de fecha ‘Fecha de nacimiento’. Pulsando
sobre él se mostrará una ventana en la que se podrá seleccionar una fecha. Seleccionando una fecha se mostrará automáticamente en el campo de fecha ‘Fecha de nacimiento’. Este campo también es obligatorio.
• Casilla de selección con valores auto-excluyentes ‘Sexo’ con los valores ‘Varón’ y ‘Mujer’. • Campo de texto ‘Altura’. Este campo de texto se validará de que se especifique en él un número
válido y un valor válido (no se aceptarán alturas negativas ni superiores a tres metros). • Campo de texto ‘Peso’. Este campo de texto validará de que se especifique en él un número
válido. • Casilla de verificación ‘Consumidor regular de alcohol’. • Casilla de verificación ‘Fumador de tabaco’. • Casilla de verificación ‘Consumidor regular de cafeína’. • Botón ‘Actualizar datos’. Actualiza los datos del paciente.
2.- El usuario especifica valores en los campos y pulsa el botón ‘Actualizar datos’.
ANEXO B. Descripción de los casos de uso
196
3.- Se validan todos los campos como válidos. Se actualizan los datos del paciente. Postcondiciones: 1.- Los datos del paciente han sido actualizados. Flujo alternativo 1: 2.- El usuario pulsa el botón ‘Actualizar datos’ estando sin cumplimentar algún campo de texto.
2.1.- La aplicación muestra un mensaje sobre el campo de texto que no se ha especificado.
Flujo alternativo 2: 2.- El usuario pulsa el botón ‘Actualizar datos’ habiendo especificado algún valor inválido en alguno de los campos de texto (e-mail, teléfono, altura, peso, etc.).
2.1.- La aplicación muestra un mensaje de error de validación sobre el campo en el que se hubiera especificado algún valor inválido.
• CU-25 Ver información de seguimiento del paciente Caso de Uso: CU-25 Ver información de seguimiento del paciente Breve descripción: Este caso de uso se encarga de mostrar en gráficas las mediciones del paciente en una determinada semana, así como el resto de datos introducidos (medicación, alimentación, acciones y síntomas) por el usuario de cada uno de los días de esa semana. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación 2.- El usuario ha de haber seleccionado un paciente mediante el caso de uso CU-22 Seleccionar paciente. 3.- El usuario ha seleccionado la opción del menú ‘Ver actividad del paciente’. Flujo principal: 1.- La aplicación muestra un apartado ‘Campos de acotación’ en el que se muestra un campo de fecha ‘Semana de seguimiento’ y un botón ‘Buscar’. 2.- El usuario cumplimenta un valor sobre el campo de fecha ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 3.- La aplicación muestra debajo del apartado ‘Campos de acotación’ un nuevo apartado ‘Criterios de visualización de datos’ en el que se muestran los siguientes campos: - Medición. Listado desplegable en el que los valores son los tipos de mediciones: la presión arterial,
temperatura y glucosa en sangre. Seleccionando un valor del listado desplegable se muestra una gráfica con la evolución del tipo de medición asignado al valor seleccionado del listado desplegable.
- Día de la semana del seguimiento. Listado desplegable en el que los valores son los días de la semana: lunes, martes, miércoles, jueves, viernes, sábado y domingo. Se mostrará una tabla con los datos introducidos por el paciente de mediciones, alimentación, actividades realizadas y síntomas experimentados. Esta tabla tendrá dos columnas: ‘Hora’ y ‘Acción’. En la columna ‘Hora’ se mostrará la hora en la que el paciente especificó que realizó esa acción y en la columna ‘Acción’ se mostrará la acción que especificó: el medicamento que tomó, el alimento que ingirió, la actividad que realizó o el síntoma que experimentó.
ANEXO B. Descripción de los casos de uso
197
Postcondiciones: 1.- Ninguna Flujo alternativo 1: 2.- El usuario especifica un valor inválido en el campo ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 2.1.- La aplicación muestra un mensaje indicando que el campo ‘Semana de seguimiento’ tiene un valor inválido. Flujo alternativo 2: 2.- El usuario no especifica ningún valor en el campo ‘Semana de seguimiento’ y pulsa el botón ‘Buscar’. 2.1.- La aplicación muestra un mensaje indicando que el campo ‘Semana de seguimiento’ es obligatorio de cumplimentar.
• CU-26 Asignar/Desasignar enfermedades a paciente Caso de Uso: CU-26 Asignar/Desasignar enfermedades a paciente Breve descripción: Mediante este caso de uso se le pueden asignar y desasignar enfermedades a un paciente. Precondiciones: 1.- El usuario ha de estar autenticado en la aplicación 2.- El usuario ha de haber seleccionado un paciente mediante el caso de uso CU-22 Seleccionar paciente. 3.- El usuario ha seleccionado la opción del menú ‘Enfermedades Paciente’ Flujo principal: 1.- La aplicación muestra una pantalla con los siguientes apartados:
Datos del paciente seleccionado. Se muestran los siguientes campos del paciente seleccionado: o Nombre completo: nombre y apellidos del paciente. o Identificación: número de identificación del paciente. o NSS: Número de la Seguridad Social. o Teléfono: Número de teléfono fijo. o Móvil: Número de teléfono móvil.
Enfermedades del paciente. Tabla con las enfermedades que tiene asignadas actualmente el paciente. La tabla tiene las columnas:
o Botón de selección de la fila de la tabla. Al pulsar sobre este botón, se trasladarán los valores de la enfermedad seleccionada a los campos del apartado posterior ‘Enfermedad del paciente’.
o Enfermedad: enfermedad del paciente o Fecha de inicio: fecha en la que se tiene constancia que comenzó la enfermedad en el
paciente. o Fecha de fin: fecha en la que el paciente se curó de esa enfermedad.
ANEXO B. Descripción de los casos de uso
198
Enfermedad del paciente. Desde este apartado se pueden editar los valores de la tabla de enfermedades, seleccionando la fila que se pretende editar mediante el botón de selección de esa fila. También se podrán asignar enfermedades nuevas así como borrar las existentes. El apartado tendrá los siguientes elementos: o Campo asistente ‘Enfermedad’: enfermedad del paciente. Este campo tendrá una imagen de
lupa que si se pulsa se mostrará una ventana emergente con un buscador desde el cual se podrá seleccionar una enfermedad filtrándola por su clase de enfermedad y por el texto de su descripción.
o Campo de fecha ‘Fecha de inicio’: fecha en la que se tiene constancia que comenzó la enfermedad en el paciente. El campo tendrá una imagen de un calendario que si se pulsa se mostrará un calendario desde el cual se podrá especificar la fecha del campo.
o Campo de fecha ‘Fecha de fin’: fecha en la que el paciente se curó de esa enfermedad. El campo tendrá una imagen de un calendario que si se pulsa se mostrará un calendario desde el cual se podrá especificar la fecha del campo.
o Botón ‘Limpiar’. Borra los valores de los campos ‘Enfermedad’, ‘Fecha de inicio’ y ‘Fecha de fin’.
o Botón ‘Guardar’. Guarda una nueva enfermedad en el paciente o actualiza la enfermedad seleccionada, en el caso de que se hubiera seleccionado una de la tabla de enfermedades del paciente.
o Botón ‘Eliminar’. Elimina la enfermedad seleccionada del paciente.
2.- El usuario especifica valores sobre los campos del apartado ‘Enfermedad del paciente’ y pulsa el botón ‘Guardar’. 3.- Se guarda la nueva enfermedad especificada en el paciente. Postcondiciones: 1.- Se almacenan los cambios especificados por el usuario (alta, modificación y eliminación de enfermedades del paciente). Flujo alternativo 1: 2.- El usuario selecciona una enfermedad en la tabla de enfermedades del paciente, modifica los valores de los campos del apartado ‘Enfermedad del paciente’ y pulsa el botón ‘Guardar’. 2.1.- La aplicación actualiza los datos introducidos en el paso anterior y muestran las modificaciones en la tabla de enfermedades del paciente. Flujo alternativo 2: 2.- El usuario selecciona una enfermedad en la tabla de enfermedades del paciente y pulsa el botón ‘Eliminar’. 2.1.- La aplicación elimina la enfermedad seleccionada y en la tabla de enfermedades del paciente desaparece la fila que se hubiera seleccionado. Flujo alternativo 3: 2.- El usuario pulsa el botón ‘Eliminar’ sin haber seleccionado previamente una fila de la tabla de enfermedades del paciente. 2.1.- La aplicación muestra un mensaje de error indicando que no se ha especificado la enfermedad que se ha de eliminar. Flujo alternativo 4: 2.- El usuario pulsa el botón ‘Guardar’ sin haber especificado un valor en los campos ‘Enfermedad’ y ‘Fecha de inicio’. 2.1.- La aplicación muestra un mensaje de error indicando que los campos ‘Enfermedad’ y ‘Fecha de
ANEXO B. Descripción de los casos de uso
199
inicio’ son obligatorios. Flujo alternativo 5: 2.- El usuario especifica valores en los campos ‘Enfermedad’, ‘Fecha de inicio’ y ‘Fecha de fin’. La fecha especificada en el campo ‘Fecha de inicio’ es posterior a la especificada en el campo ‘Fecha de fin’. 2.1.- La aplicación muestra un mensaje de error indicando que la fecha de fin ha de ser posterior a la fecha de fin.
Descripción de los casos de uso del servicio web Caso de Uso: CU-41 Añadir datos de seguimiento del paciente Breve descripción: Este caso de uso se encarga de almacenar los datos de seguimiento del paciente que reciba el servicio web de la aplicación móvil. Precondiciones: 1.- Desde la aplicación móvil se ejecuta el apartado de sincronizar datos (CU-10 Sincronizar información con el servidor remoto). Desde este apartado se ejecuta esta operación del servicio web. Flujo principal: 1.- Se almacenan los siguientes elementos en la base de datos:
o Mediciones Tensión arterial Temperatura corporal Glucosa en sangre
o Actividades realizadas o Medicamentos tomados o Alimentos ingeridos o Síntomas experimentados
Postcondiciones: 1.- Los datos recibidos procedentes de la aplicación móvil quedan almacenados en la base de datos. Caso de Uso: CU-42 Recibir datos nuevos o actualizados de catálogos del sistema Breve descripción: Este caso de uso se encarga de recuperar aquellos datos que hayan sido creados o actualizados con respecto a la fecha de la última sincronización de la aplicación móvil. Precondiciones: 1.- Desde la aplicación móvil se ejecuta el apartado de sincronizar datos (CU-10 Sincronizar información con el servidor remoto). Desde este apartado se ejecuta esta operación del servicio web. Flujo principal: 1.- Dada la última fecha de sincronización de la aplicación móvil, se recuperan de los siguientes catálogos
ANEXO B. Descripción de los casos de uso
200
o Sensores o Tipos de sensores o Enfermedades o Clases de enfermedades o Mensajes de recomendación asociados a rangos de medición de temperatura corporal o Mensajes de recomendación asociados a rangos de medición de tensión arterial o Mensajes de recomendación asociados a rangos de medición de glucosa en sangre o Síntomas o Mensajes de recomendación asociados a síntomas o Actividades o Mensajes de recomendación asociados a actividades o Medicamentos o Mensajes de recomendación asociados a medicamentos o Alimentos o Clases de alimentos o Subclases de alimentos o Mensajes de recomendación asociados a alimentos
aquellos registros que fueron creados o actualizados después de la última fecha de sincronización proporcionada por la aplicación móvil. Postcondiciones: 1.- Los datos recuperados son enviados a la aplicación móvil. Caso de Uso: CU-43 Obtener datos personales del paciente Breve descripción: Este caso de uso se encarga de recuperar los datos personales del paciente que se encuentren en la base de datos del sistema. Precondiciones: 1.- Desde la aplicación móvil se ejecuta el apartado de sincronizar datos (CU-10 Sincronizar información con el servidor remoto) o el apartado de asociar el paciente a la aplicación móvil (CU-01 Asociar paciente a la aplicación móvil). Desde estos dos apartados se puede ejecutar esta operación del servicio web. Flujo principal: 1.- Se recuperan los datos personales del paciente
o Datos de identificación del paciente Nombre y apellidos Número de identificación NSS (Número de la seguridad social) Etc.
o Datos fisiológicos del paciente Peso Altura Sexo
o Hábitos del paciente Fumador Bebedor regular de alcohol Consumidor regular de cafeína.
o Enfermedades del paciente Postcondiciones:
ANEXO B. Descripción de los casos de uso
201
1.- Los datos recuperados son enviados a la aplicación móvil.
ANEXO C. MANUAL DE USUARIO DE LA APLICACIÓN WEB
ANEXO C. Manual de usuario de la aplicación web
205
Se expone en este apartado el manual de usuario de la aplicación web. Esta
aplicación será usada por usuarios con perfil profesional sanitario (médicos, enfermeras,
etc).
La aplicación requiere autenticación de usuario por lo que si se intenta acceder a
un apartado de la aplicación sin estar el usuario autenticado se mostrará la pantalla de
autenticación de usuario mostrada en la Figura 59.
Autenticación de usuario
Para acceder a la aplicación web el usuario ha de autenticarse en la pantalla
mostrada en la Figura 59. Se ha de especificar el identificador de usuario y la contraseña
a asociada.
Figura 59. Pantalla de autenticación de usuario
Menú lateral izquierdo
En la aplicación web se muestra un menú lateral izquierdo (Ver Figura 60) con
accesos a todas las funcionalidades disponibles. Este menú se muestra en todas las
pantallas de todos los apartados salvo en la pantalla de autenticación de usuario.
ANEXO C. Manual de usuario de la aplicación web
206
Figura 60. Menú lateral izquierdo de la aplicación web
Las opciones de este menú lateral izquierdo son:
o Nuevo Paciente: registra un paciente nuevo en el sistema.
o Seleccionar Paciente: selecciona un paciente de entre los asociados al
usuario médico para ser usado en otros apartados de la aplicación
(Actualizar Datos del Paciente, Enfermedades Paciente o Ver Actividad
del paciente).
o Actualizar Datos Paciente: desde este apartado se pueden actualizar los
datos personales de un paciente registrado en la aplicación.
o Enfermedades Paciente: para asignar y desasignar enfermedades a un
paciente.
o Ver actividad del paciente: desde este apartado se pueden ver toda la
información de seguimiento del paciente seleccionado.
o Cerrar sesión: cierra la sesión actual del usuario y muestra de nuevo la
pantalla de autenticación del usuario (Ver Figura 59).
Nuevo paciente
En este apartado se permite registrar nuevos pacientes en el sistema (Ver Figura
61).
ANEXO C. Manual de usuario de la aplicación web
207
Figura 61. Pantalla del apartado de Nuevo Paciente
Para registrar un paciente nuevo hay que cumplimentar los campos y pulsar el
botón ‘Salvar’. Si alguno de los campos fuera obligatorio o tuviera un valor inválido se
mostrará un mensaje de error a la derecha del campo (Ver Figura 62)
Figura 62. Ejemplos de mensajes de validación en los apartados de datos del paciente
Pulsando el botón ‘Limpiar’ se borran todos los valores especificados en los
campos.
ANEXO C. Manual de usuario de la aplicación web
208
Seleccionar paciente
En el apartado de Seleccionar paciente se escoge un paciente del conjunto de
pacientes del usuario médico para ser usado en los apartados de Ver actividad del
paciente, enfermedades paciente y Actualizar datos del paciente.
Se pueden especificar varios criterios de búsqueda para reducir el listado de
pacientes que se mostrarán (Ver Figura 63). Se ha de pulsar el botón ‘Buscar’ para
mostrar el listado de pacientes asociados al usuario médico acotado por los criterios de
búsqueda que se especifiquen. Después, se ha de seleccionar el paciente que se va a
utilizar pulsando sobre la casilla de selección del primer campo de la tabla. Finalmente
se ha de pulsar el botón ‘Seleccionar paciente’ para seleccionarlo.
Figura 63. Pantalla del apartado de Seleccionar Paciente
El botón ‘Limpiar’ borra los criterios de acotación.
El botón ‘Cuantificar’ muestra el número de pacientes que cumplen con los
criterios de búsqueda especificados.
El listado de pacientes mostrados puede ordenarse pulsando sobre el título del
campo por el que se desea ordenar.
ANEXO C. Manual de usuario de la aplicación web
209
Actualizar datos paciente
Los datos personales del paciente pueden modificarse utilizando la funcionalidad
de este apartado.
Antes de acceder a este apartado ha de haberse seleccionado un paciente
mediante la funcionalidad de ‘Seleccionar paciente’ explicada en el apartado
Seleccionar paciente.
Se han de modificar los datos que se desean actualizar (Ver Figura 64) y se ha de
pulsar el botón ‘Actualizar datos’.
Figura 64. Pantalla del apartado de Actualizar datos de paciente
Enfermedades paciente
Este apartado sirve para asignar y desasignar enfermedades a un paciente.
ANEXO C. Manual de usuario de la aplicación web
210
Antes de acceder a este apartado ha de haberse seleccionado un paciente
mediante la funcionalidad de ‘Seleccionar paciente’ explicada en el apartado
Seleccionar paciente.
Inicialmente se muestra un listado con todas las enfermedades del paciente y un
apartado debajo llamado ‘Enfermedad del paciente’ desde el que se puede asignar una
enfermedad nueva al paciente (Ver Figura 65).
Figura 65. Pantalla del apartado de Enfermedades del paciente
Para asignar una enfermedad nueva en el paciente hay que especificar la
enfermedad usando el asistente de enfermedades (Ver Figura 66), especificar su fecha
de comienzo y pulsar el botón ‘Guardar’. Los campos ‘Enfermedad’ y ‘Fecha de
comienzo’ son obligatorios.
Para acceder al asistente de enfermedades hay que pulsar la imagen de lupa
situada a la derecha del campo ‘Enfermedad’.
ANEXO C. Manual de usuario de la aplicación web
211
Figura 66. Pantalla del asistente de selección de enfermedades
Para modificar o eliminar una enfermedad asignada, ha de seleccionarse la
enfermedad pulsando la casilla de selección del primer campo de la tabla de
enfermedades del paciente. Se cargarán automáticamente los datos de la enfermedad
seleccionada en los campos del apartado ‘Enfermedad del paciente’ (Ver Figura 67).
Para desasignar la enfermedad del paciente se usa el botón ‘Eliminar’. Para actualizar
los valores de la enfermedad se usa el botón ‘Guardar’.
ANEXO C. Manual de usuario de la aplicación web
212
Figura 67. Selección de una enfermedad en el apartado de Enfermedades del paciente
Ver actividad del paciente
Este apartado sirve para ver los datos de seguimiento del paciente.
Antes de acceder a este apartado ha de haberse seleccionado un paciente
mediante la funcionalidad de ‘Seleccionar paciente’ explicada en el apartado
Seleccionar paciente.
Se ha de especificar una fecha correspondiente a la semana en la que se desea
hacer el seguimiento del paciente. Después se ha de pulsar el botón ‘Buscar’.
Figura 68. Pantalla del apartado de Ver la actividad del paciente
ANEXO C. Manual de usuario de la aplicación web
213
Una vez pulsado el botón ‘Buscar’ se muestra un apartado llamado ‘Criterios de
Visualización de datos’ (Ver Figura 69) desde el que se pueden mostrar gráficos de cada
uno de los tipos de mediciones para la semana especificada y los datos de seguimiento
para un día de esa semana.
Mediante el listado desplegable ‘Medición’ se permite mostrar el gráfico
asociada al tipo de medición seleccionado para la semana especificada (Ver Figura 70).
Seleccionando un valor en el listado desplegable ‘Día de la semana del
seguimiento’ se muestran todos la información de seguimiento de ese paciente para ese
día (Ver Figura 69).
Figura 69. Pantalla de visualización de la información de seguimiento en un día
determinado
ANEXO C. Manual de usuario de la aplicación web
214
Figura 70. Pantalla de visualización del gráfico del tipo de medición seleccionado durante
la semana
ANEXO D. MANUAL DE USUARIO DE LA APLICACIÓN MÓVIL
ANEXO D. Manual de usuario de la aplicación móvil
217
Se muestra en este apartado el manual de usuario de la aplicación móvil
correspondiente a un usuario con perfil paciente. Para que la aplicación muestre el menú
principal han de cargarse los datos iniciales y establecer el paciente en ella. Estas tareas
las realizaría un usuario con perfil técnico y se explican en el Anexo E. Configuración
previa de la aplicación móvil.
Campos comunes
Existen varios tipos de campos en la aplicación que funcionan de forma
homogénea en toda la aplicación.
Campos de texto autocompletado
En algunos apartados hay campos de texto autocompletado. Especificando una
secuencia de tres o más caracteres de la palabra o las palabras que se desean especificar
se mostrará debajo de ella un listado desplegable con todas las opciones seleccionables
posibles que contengan la secuencia de caracteres especificada (Ver Figura 71). En
estos campos se han de especificar valores catalogados, es decir, no son campos de
texto libre. Si se especifican valores no catalogados se mostrará un mensaje de
validación (Ver Figura 72).
Figura 71. Ejemplo de campo de texto autocompletado con listado desplegable de valores
ANEXO D. Manual de usuario de la aplicación móvil
218
Figura 72. Ejemplo de validación de campo de texto autocompletado
Campos de fecha
Los campos de fecha están asociados al campo ‘Día’ de algunos apartados.
Tienen a la derecha la imagen de un calendario (Ver Figura 73). Pulsando sobre la
imagen del calendario se puede seleccionar la fecha desde un asistente (Ver Figura 74).
Si se especifica un valor vacío o inválido se mostrará un mensaje de validación (Ver
Figura 75).
Figura 73. Imagen del calendario de los campos de fecha
Figura 74. Asistente para especificar fechas
ANEXO D. Manual de usuario de la aplicación móvil
219
Figura 75. Mensaje de validación en caso de fecha vacía o inválida
Campos de hora
Los campos de fecha están asociados al campo ‘Hora’ de algunos apartados.
Tienen a la derecha la imagen de un reloj de pared (Ver Figura 76). Pulsando sobre la
imagen del calendario se puede seleccionar la fecha desde un asistente (Ver Figura 77).
Si se especifica un valor vacío o inválido se mostrará un mensaje de validación (Ver
Figura 78).
Figura 76. Imagen del reloj de pared asociada a los campos de hora.
Figura 77. Asistente pare especificar la hora
Figura 78. Mensaje de validación en caso de hora vacía o inválida
ANEXO D. Manual de usuario de la aplicación móvil
220
Campos de barra de desplazamiento
Los campos de barra de desplazamiento permiten especificar varios valores
según la posición que se especifique en la barra de desplazamiento. Para modificar la
posición de la barra de desplazamiento hay que arrastrar el dedo sobre ella. El valor
asignado se mostrará a la derecha de la barra de desplazamiento (Ver Figura 79).
Figura 79. Campo de barra de desplazamiento con valor asociado a la derecha
Ventanas de recomendaciones
Al introducir datos de seguimiento en la aplicación, dependiendo del dato
introducido y del contexto del paciente (datos introducidos anteriormente y de sus
enfermedades) puede que se muestre un listado de recomendaciones asociadas al dato
de seguimiento que se va a especificar (Ver Figura 80). Si el dato de seguimiento se
introduce en una fecha y en una hora posterior a diez minutos antes de la fecha y hora
del dispositivo móvil, después del listado de recomendaciones se mostrará una ventana
para confirmar el dato de seguimiento introducido (Ver Figura 81). Esta ventana de
confirmación no se mostrará en los apartados de Mediciones y Síntomas. Esto se debe
a que las mediciones y los síntomas no son sucesos que el usuario pueda controlar como
el que podría ser tomar o no un determinado medicamento.
ANEXO D. Manual de usuario de la aplicación móvil
221
Figura 80. Pantalla de ejemplo de recomendaciones (Paciente con insuficiencia renal y habiendo tomado cerveza)
Figura 81. Pantalla de confirmación después de mostrarse la ventana de recomendaciones
Apartados de la aplicación
Menú principal
Se muestra en la Figura 82 el menú principal de la aplicación.
ANEXO D. Manual de usuario de la aplicación móvil
222
Figura 82. Menú principal de la aplicación móvil
Desde el menú principal de la aplicación se puede acceder a los siguientes
apartados:
o Medición: sirve para realizar mediciones de forma manual o mediante
sensor. Las medicines mediante sensor necesitan que el dispositivo móvil
permita conectividad Bluetooth.
o Alimentación: desde este apartado se introducen los alimentos ingeridos.
o Actividades: se pueden introducir las actividades que se realizan (andar,
correr, ver la tele, etc.).
o Medicamentos: para introducir los medicamentos tomados.
o Síntomas: esta opción sirve para introducir los síntomas experimentados.
o Sincronizar: desde este apartado se envían los datos de seguimiento del
paciente así como se actualizan los datos internos de la aplicación móvil con
respecto a la base de datos central. El dispositivo móvil ha de tener conexión
a Internet disponible para poder ejecutar la funcionalidad de este apartado.
o Histórico: se pueden ver los datos de seguimiento introducidos en la
aplicación con una semana de antigüedad.
ANEXO D. Manual de usuario de la aplicación móvil
223
Medición
El apartado de Medición sirve para introducir mediciones de forma manual o
mediante sensor. Se muestra en la Figura 83 la pantalla de la selección del tipo de
medición.
Figura 83. Pantalla de selección del tipo de medición
Desde el listado desplegable ‘Tipo de Medida’ se permite seleccionar el tipo de
medida que se va a realizar. Los valores posibles son: tensión arterial, temperatura
corporal y glucosa en sangre.
Con el listado desplegable ‘Modo de obtención’ se especifica si la medición va a
introducirse de forma manual (escribiendo los valores de la medición directamente) o
mediante sensor (los valores de la medición son leídos de un sensor biométrico
Bluetooth).
Una vez se han especificado los valores deseados para introducir la medición se
pulsa el botón ‘Aceptar’. Si se desea volver al menú principal se pulsaría el botón
‘Atrás’.
ANEXO D. Manual de usuario de la aplicación móvil
224
Pulsando el botón ‘Aceptar’ sobre la pantalla mostrada en la Figura 83 se
mostraría la pantalla de medición manual de la presión arterial mostrada en la Figura 84.
Para introducir una medición manual simplemente hay que especificar los valores y
pulsar el botón ‘Aceptar’.
Figura 84. Pantalla de introducción manual de presión arterial
Si se seleccionase en el campo ‘Modo de obtención’ la opción ‘Mediante sensor’
se mostraría la pantalla mostrada en la Figura 85. Se selecciona el sensor biométrico
Bluetooth que se desea usar y se pulsa el botón ‘Aceptar’. Se mostrará el mensaje de
espera de la medición mostrado en la Figura 86. Una vez lea la aplicación móvil la
medición recibida del sensor se mostrará una ventana emergente con un mensaje como
el de la Figura 87.
ANEXO D. Manual de usuario de la aplicación móvil
225
Figura 85. Pantalla de medición mediante sensor
Figura 86. Mensaje de espera de la medición del sensor
Figura 87. Mensaje de medición recibida desde el sensor
Alimentación
Mediante el apartado de Alimentación (Figura 88) el paciente puede introducir
los alimentos ingeridos.
ANEXO D. Manual de usuario de la aplicación móvil
226
Figura 88. Pantalla de introducción de alimentos
Para introducir un nuevo alimento, se ha de especificar el alimento, el día, la
hora, las raciones y pulsar el botón ‘Introducir alimento’. Los campos de ‘Día’ y ‘Hora’
están por defecto cumplimentados con la fecha y hora del dispositivo móvil. Si se desea
especificar un día y una hora distinto se pueden editar los campos manualmente o usar
los botones de la derecha para usar los asistentes del calendario y del reloj (Ver apartado
de Campos comunes).
Una vez se introduzca el alimento se mostrará un mensaje como el de la Figura
89.
Figura 89. Mensaje de introducción del alimento con éxito
Si el alimento tiene asociada alguna recomendación dependiendo del contexto
del usuario (otros datos de seguimiento introducidos anteriormente) se mostrará un
listado de recomendaciones (Ver apartado Ventanas de recomendaciones).
ANEXO D. Manual de usuario de la aplicación móvil
227
Actividades
Mediante el apartado de Actividades (Figura 90) el paciente puede introducir las
actividades realizadas.
Figura 90. Pantalla de introducción de actividades
Para introducir una actividad realizada, se ha de especificar la actividad, el día,
la hora, la duración de la actividad y pulsar el botón ‘Introducir actividad’. Los campos
de ‘Día’ y ‘Hora’ están por defecto cumplimentados con la fecha y hora del dispositivo
móvil. Si se desea especificar un día y una hora distinto se pueden editar los campos
manualmente o usar los botones de la derecha para usar los asistentes del calendario y
del reloj (Ver apartado de Campos comunes).
Una vez se introduzca la actividad se mostrará un mensaje como el de la Figura
91.
Figura 91. Mensaje de introducción de la actividad con éxito
ANEXO D. Manual de usuario de la aplicación móvil
228
Si la actividad tiene asociada alguna recomendación dependiendo del contexto
del usuario (otros datos de seguimiento introducidos anteriormente o sus enfermedades)
se mostrará un listado de recomendaciones (Ver apartado Ventanas de
recomendaciones).
Medicamentos
Mediante el apartado de Medicamentos (Figura 92) el paciente puede introducir
la medicación tomada.
Figura 92. Pantalla de introducción de medicación
Para introducir un medicamento, se ha de especificar el medicamento, el día, la
hora, la dosis tomada del medicamento y pulsar el botón ‘Introducir medicamento’. Los
campos de ‘Día’ y ‘Hora’ están por defecto cumplimentados con la fecha y hora del
dispositivo móvil. Si se desea especificar un día y una hora distinto se pueden editar los
campos manualmente o usar los botones de la derecha para usar los asistentes del
calendario y del reloj (Ver apartado de Campos comunes).
Una vez se introduzca el medicamento se mostrará un mensaje como el de la
Figura 93.
ANEXO D. Manual de usuario de la aplicación móvil
229
Figura 93. Mensaje de introducción del medicamento con éxito
Si el medicamento tiene asociado alguna recomendación dependiendo del
contexto del usuario (otros datos de seguimiento introducidos anteriormente) se
mostrará un listado de recomendaciones (Ver apartado Ventanas de
recomendaciones).
Síntomas
Mediante el apartado de Síntomas (Ver Figura 94) el paciente puede introducir
los síntomas experimentados.
Figura 94. Pantalla de introducción de síntomas
ANEXO D. Manual de usuario de la aplicación móvil
230
Se ha de introducir el síntoma, el día, la hora y pulsar el botón ‘Introducir
síntoma’. Los campos de ‘Día’ y ‘Hora’ están por defecto cumplimentados con la fecha
y hora del dispositivo móvil. Si se desea especificar un día y una hora distinto se pueden
editar los campos manualmente o usar los botones de la derecha para usar los asistentes
del calendario y del reloj (Ver apartado de Campos comunes).
Una vez se introduzca el síntoma se mostrará un mensaje como el de la Figura
95.
Figura 95. Mensaje de introducción del síntoma con éxito
Si el síntoma tiene asociado alguna recomendación dependiendo del contexto del
usuario (otros datos de seguimiento introducidos anteriormente) se mostrará un listado
de recomendaciones (Ver apartado Ventanas de recomendaciones).
Sincronizar
Desde el apartado de Sincronizar (Figura 96) el paciente puede enviar sus datos
de seguimiento así como actualizar los datos internos de la aplicación.
El usuario simplemente ha de tener alguna conexión a Internet disponible y
pulsar el botón ‘Sincronizar’. Para volver al menú principal ha de pulsar el botón
‘Atrás’.
ANEXO D. Manual de usuario de la aplicación móvil
231
Figura 96. Pantalla de sincronización de datos
Una vez pulsado el botón de Sincronizar datos se mostrará una ventana emergente
con un mensaje de espera indicando que la aplicación está procesando datos (Ver Figura
97).
Figura 97. Mensaje de espera al sincronizar los datos
Al finalizar la sincronización se mostrará un mensaje indicándolo (Ver Figura 98).
Figura 98. Mensaje de sincronización llevada con éxito
Histórico
Desde el apartado de Histórico el usuario puede ver todos los datos de
seguimiento introducidos que tengan menos de una semana de antigüedad (Ver Figura
99).
ANEXO D. Manual de usuario de la aplicación móvil
232
Figura 99. Pantalla de histórico de datos de seguimiento
ANEXO E. CONFIGURACIÓN PREVIA DE LA APLICACIÓN MÓVIL
ANEXO E. Configuración previa de la aplicación móvil
235
Para que un paciente haga uso de la aplicación móvil primero hay que realizar
sobre ella una breve configuración para que esté preparada para su uso. Esta breve
configuración simplemente implica a la aplicación móvil cargarle los datos iniciales y
asignarle el usuario paciente.
La primera pantalla que muestra la aplicación móvil recién instalada es la
mostrada en la Figura 100. Se muestran los dos apartados de configuración. El apartado
de ‘Obtener datos del paciente’ se deshabilita inicialmente. Se habilita al cargar los
datos iniciales de la aplicación.
Figura 100. Pantalla inicial de la aplicación móvil recién instalada
Carga inicial de datos
Desde este apartado se cargan los datos iniciales de la aplicación móvil (Ver
Figura 101).
ANEXO E. Configuración previa de la aplicación móvil
236
Figura 101. Pantalla del apartado de la carga inicial de datos de la aplicación móvil
Se ha de especificar en el campo ‘Ruta del script de carga’ la ruta en el
dispositivo móvil donde se encuentre el fichero del script con la carga de los datos
iniciales. Después se ha de pulsar el botón ‘Cargar datos’.
Una vez pulsado el botón ‘Cargar datos’ se mostrará en la pantalla una ventana
emergente en la aparecerá una barra de progreso indicando que el dispositivo móvil está
ocupado (Ver Figura 102). Este proceso de carga no puede cancelarse. En el móvil que
se usó para probar la aplicación (HTC Wildfire) tarda alrededor de cuarenta segundos.
Figura 102. Mensaje del proceso de carga inicial de datos en la aplicación móvil
Finalizada la carga de datos se muestra un mensaje indicándolo y se deshabilita
el botón ‘Cargar datos’ (Ver Figura 103).
ANEXO E. Configuración previa de la aplicación móvil
237
Figura 103. Pantalla de la carga de datos inicial una vez ha concluido con éxito
Al pulsar el botón ‘Atrás’ se accede al menú de la configuración previa de la
aplicación móvil (Ver Figura 104). Al cargarse los datos se deshabilita el botón de
‘Carga inicial de datos’ y se habilita el de ‘Obtener datos del paciente’.
Figura 104. Pantalla del menú de configuración previa de la aplicación móvil una vez se han
cargado los datos iniciales
Obtener datos del paciente
En este apartado se asigna el paciente a la aplicación móvil (Ver Figura 105).
Hay que asignar el ID del paciente que se muestra en la aplicación web (Ver Figura
106).
ANEXO E. Configuración previa de la aplicación móvil
238
Figura 105. Pantalla de la asignación del paciente a la aplicación móvil
Figura 106. Pantalla con pacientes asociados a un médico en la aplicación web
Se ha de especificar el ID del paciente en el campo ‘ID del paciente’ y pulsar el
botón ‘Comprobar paciente’. La aplicación móvil consultará los datos del paciente de
ese ID al servicio web (Ver Figura 107). Se mostrarán los datos del paciente con ese ID
y se pedirá confirmación al usuario de si es éste el paciente que le ha de corresponder a
esa instancia de la aplicación móvil (Ver Figura 108). Se recuerda que este apartado lo
ha de ejecutar personal técnico y no el paciente por lo que no se violaría la
confidencialidad del resto de pacientes.
Figura 107. Mensaje de búsqueda del paciente especificado en el apartado de asignación del
paciente a la aplicación móvil
ANEXO E. Configuración previa de la aplicación móvil
239
Figura 108. Mensaje de confirmación de paciente especificado en el apartado de asignación de
paciente a la aplicación móvil
Una vez confirmado el paciente se deshabilita el botón ‘Comprobar paciente’
(Ver Figura 109). Al pulsar el botón ‘Atrás’ se mostrará el menú de configuración
previa con el único botón disponible de ‘Salir’ (Ver Figura 110), indicando al usuario
con perfil técnico que la configuración previa de la aplicación móvil ha concluido.
Figura 109. Asignación del paciente a la aplicación móvil confirmada y concluida
Figura 110. Menú de la configuración previa de la aplicación una vez ha concluido
ANEXO E. Configuración previa de la aplicación móvil
240
La siguiente vez que se inicie la aplicación se mostrará el menú principal de esta
mostrado en la Figura 82. La aplicación ya está lista para ser usada por el paciente
asignado.