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 selfmanagement 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 patientmonitoring 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. 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.

1. 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

3. 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

5. v
TRIBUNAL
Presidente:
Vocal:
Secretario:
FECHA DE DEFENSA:
CALIFICACIÓN:
PRESIDENTE VOCAL SECRETARIO
Fdo.: Fdo.: Fdo.:

7. 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.

9. 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.

11. 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

12. 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

13. 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

15. 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

16. 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

17. 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

18. 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

19. 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

21. 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

23. 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

24. xxiv

25. 1 INTRODUCCION

27. 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.

28. 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

29. 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

30. 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.

31. 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

32. 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.

33. 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

34. 1. Introducción
10

35. 2 OBJETIVOS

37. 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.

38. 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

39. 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

40. 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

41. 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

42. 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

43. 3 ESTADO DEL ARTE

45. 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

46. 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 asistenciaTipo 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.

47. 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

48. 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)

49. 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

50. 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.

51. 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

52. 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

53. 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

54. 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.

55. 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.

56. 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.

57. 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.

58. 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

59. 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.

60. 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

61. 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

62. 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

63. 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

64. 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.

65. 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

66. 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/

67. 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

68. 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 animalLípidos
Lípidos de origen vegetal
Patatas y otras raíces feculentas Patatas y otras raíces feculentas

69. 3. Estado del arte
45
Legumbres Legumbres
Frutos secos Frutos secos
Vegetales frescosVegetales
Vegetales procesados
Frutas frescasFruta
Frutas procesadas
Zumo de frutasZumos de fruta y de vegetales
Zumo de vegetales
AzúcaresAzú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

70. 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

71. 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

72. 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

73. 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

74. 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.

75. 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