EDEVITALZH : : entorno clínico virtual para ayuda al diagnóstico temprano de la enfermedad de Alzheimer y otras demencias. Uso en Telemedicina

PROYECTO DE FIN DE CARRERA INGENIER´ IA EN INFORM´ ATICA EDEVITALZH: Entorno Cl´ınico Virtual para Ayuda al Diagn´ostico Temprano de la Enfermedad de Alzheimer y otras Demencias. Uso en Telemedicina. Alumno: Miguel ´ Angel P´erez del Pino Tutores: Prof. Dra. Carmen Paz Su´arez Araujo Prof. Dr. Patricio Garc´ıa B´aez Fecha: 2 de octubre de 2015 D˜na. Carmen Paz Su´ arez Araujo Catedr´atica de Universidad Escuela de Ingenier´ıa Inform´atica Universidad de Las Palmas de Gran Canaria y D. Patricio Garc ´ ıa B´ aez Profesor Contratado-Doctor Departamento de Ingenier´ıa Inform´atica y de Sistemas Universidad de La Laguna CERTIFICAN: Que la memoria titulada “EDEVITALZH: Entorno Cl´ınico Virtual para Ayuda al Diagn´ostico Temprano de la Enfermedad de Alzheimer y otras Demencias. Uso en Telemedicina.” ha sido realizada por D. Miguel ´ Angel P´ erez del Pino bajo nuestra direcci´on y constituye su Proyecto de Final de Carrera de Ingenier´ıa Superior en Inform´atica. En Las Palmas de Gran Canaria, a 2 de octubre de 2015. D˜na. Carmen Paz Su´arez Araujo D. Patricio Garc´ıa B´aez Resumen: La importancia sociol´ogica de la poblaci´on anciana ha crecido de manera significativa, debido a la elevada prevalencia de patolog´ıas cr´onicas. Estas enfermedades suponen el 80 % de las consultas de Atenci´on Primaria, el 60 % de los ingresos hospitalarios y el 70 % del gasto sanitario total. De entre ellas, cabe destacar el Deterioro Cognitivo Leve (DCL), la Enfermedad de Alzheimer (EA) y otras demencias corticales. En este momento, el conocimiento que se tiene sobre la demencia, especialmente sobre estrategias preventivas, la precisi´on diagn´ostica ante-mortem y la accesibilidad generalizada al diagn´ostico, es bajo. Esto hace que sean urgentes investigaciones y nuevos desarrollos en estos aspectos. El diagn´ostico ante-mortem de EA probable se confirma post-mortem en 80 %-90 % de los casos si el diagn´ostico ha sido realizado en centros especializados. Se estima la existencia de un alto grado de infradiagn´ostico, llegando al 95 % de los casos en condiciones normales. Esta precisi´on diagn´ostica es a´un menor cuando se valora a los pacientes en entornos de Atenci´on Primaria (AP), donde no existen especialistas ni la infraestructura apropiada para atender adecuadamente al paciente que sufre estas patolog´ıas neurodegenerativas. Esto es especialmente destacable cuando se trata de ´areas rurales o alejadas de los principales nucleos de poblaci´on. En el momento en el que un paciente es diagnosticado con la EA, la enfermedad ha avanzado durante varios a˜nos. La no existencia de marcadores biol´ogicos para la EA, el no conocimiento exacto del curso temporal de la enfermedad, la no existencia de un conjunto espec´ıfico de criterios cl´ınicos para el diagnostico de cada tipo de demencia, la falta de estandarizaci´on de ´estos, as´ı como la necesidad del acceso universal al diagn´ostico, hace obligatoria la b´usqueda de nuevos procedimientos e instrumentos diagn´osticos para la detecci´on temprana de demencias, especialmente de la EA y el DCL. El proceso asistencial del paciente se ve ralentizado como consecuencia del arduo trabajo de buscar en archivos cl´ınicos mal estructurados. A´un en la actualidad gran parte del trabajo de recogida de datos en las consultas sigue realiz´andose en papel, habitualmente como anotaciones o formularios textuales ad-hoc a la historia del paciente, o en bases de datos individuales sin ning´un tipo de estandarizaci´on. La normalizaci´on de indicadores, criterios, herramientas y procedimientos cl´ınicos dentro del marco de un protocolo cl´ınico es parte del camino para conseguir mejorar el nivel de certeza y de fiabilidad en el diagn´ostico diferencial de estas neuropatolog´ıas, y el uso de las TICs ser´a lo que nos permitir´a mejorar el proceso asistencial as´ı como el acceso universal al diagn´ostico, a trav´es de soluciones de e-Salud. Este Proyecto de Fin de Carrera presenta una soluci´on global, innovadora y web, capaz de integrar sistemas inteligentes de ayuda al diagn´ostico (SIAD) y herramientas computacionales inteligentes (HCI): EDEVITALZH. Este entorno est´a espec´ıficamente dise˜nado 4 para guiar y asistir al facultativo en su flujo habitual de trabajo, es decir, en la observaci´on y la valoraci´on del paciente. Con fuerte fundamento de Historia Cl´ınica Electr´onica, el entorno desarrollado implementa tanto funciones de gesti´on asistencial como de estaci´on cl´ınica, incorporando un amplio conjunto de instrumentos diagn´osticos validados por expertos cl´ınicos. Gracias a la interoperabilidad de EDEVITALZH con los SIAD y HCI, basados en computaci´on neuronal y fusi´on de datos, el sistema desarrollado puede considerarse una Estaci´on Cl´ınica inteligente. La caracter´ıstica m´as relevante de EDEVITALZH es que asegura que ning´un paciente con DCL, EA u otra demencia, se quedar´a sin la asistencia sanitaria que precise, sin un diagn´ostico fiable y/o sin el tratamiento adecuado para aliviar su dolencia, por no disponer de un especialista o de los recursos cl´ınicos necesarios. Esta memoria describe los procesos de an´alisis, dise˜no, construcci´on y testing de EDEVITALZH y est´a estructurada de la siguiente forma: En el Cap´ıtulo 1, primero se contextualiza el problema a abordar, para posteriormente realizar un an´alisis del estado del arte en el ´ambito de la inform´atica medica, y m´as concretamente, en las aplicaciones de telemedicina. A continuaci´on, se detallan los objetivos de este proyecto, as´ı como la metodolog´ıa y recursos utilizados. En el Cap´ıtulo 2, se hace un recorrido por la Ingenier´ıa de Requisitos, en busca de los requerimientos funcionales y no funcionales del proyecto. A continuaci´on, se describe el modelo de negocio que identifica la realidad a representar y que el sistema resultante deber´a poder gestionar. Posteriormente, se presentan los actores, los subsistemas y los casos de uso del proyecto, agrupados en el modelo conceptual. Para finalizar, se introduce al lector en la descripci´on funcional de los Sistemas Inteligentes de Ayuda al Diagn´ostico. En el Cap´ıtulo 3, se describen los procesos de dise˜no llevados a cabo en este proyecto. Inicialmente, se analiza qu´e aporta la idea de protocolo cl´ınico a este proyecto y se especifica qu´e debe tener un protocolo concretamente adaptado a las necesidades del problema que trata de abordar, como es el Protocolo Cl´ınico Global de Demencias. A continuaci´on, se presentan los dise˜nos que dar´an cuerpo a EDEVITALZH: •Primeramente, se describe Modelo L´ogico de Datos, al que acompa˜nan los diagramas Entidad—Interrelaci´on del ap´endice A.1. •A continuaci´on, se propone el Modelo de Aplicaci´on, con claro v´ınculo al modelo de aplicaciones web y un claro enfoque a la construcci´on r´apida de aplicaciones RIA. Miguel ´ Angel P´erez del Pino 5 •Para finalizar el cap´ıtulo, se detalla el Modelo L´ogico de Sistemas, donde se eval´uan las soluciones HTC consideradas para este PFC y se expone qu´e arquitectura y qu´e estructura se implementar´an para dar soporte a EDEVITALZH. En el Cap´ıtulo 4, se detallan los procesos de instalaci´on, configuraci´on, desarrollo y puesta en producci´on de las diferentes partes del sistema a construir: •Inicialmente, se presenta la instalaci´on y configuraci´on de los servidores y estaciones, recursos del proyecto. •A continuaci´on, se aborda la instalaci´on del cluster HTC con Open Grid Engine. •Seguidamente, se describe la instalaci´on del servidor web Apache, el servicio de monitorizaci´on del cl´uster y el servidor de bases de datos MySQL, en este orden. •Luego, se relata el proceso de implementaci´on del modelo fisico de datos, apoy´andose en las sentencias DDL, los diagramas y las tablas descritos en el ap´endice A. •En la siguiente secci´on, se detalla el proceso de instalaci´on del CMS Joomla para, a continuaci´on, adentrarnos de lleno en el desarrollo de la aplicaci´on web asistencial. •Como pen´ultima secci´on, se presenta el modelo de integraci´on flexible con los SIAD. •Para finalizar el cap´ıtulo, se comenta el testing realizado y c´omo se ha llevado a cabo la validaci´on de funcionalidad del entorno cl´ınico web desarrollado. En el Cap´ıtulo 5, se presentan las conclusiones de este trabajo de final de carrera, as´ı como posibles trabajos futuros que ha abierto el mismo. 2 de octubre de 2015 Lista de palabras clave: Aplicaci´on Web, Demencia, Deterioro Cognitivo Leve, Diagn´ostico, Enfermedad de Alzheimer, Sistema de Informaci´on Cl´ınica, Sistemas Inteligentes, Telemedicina 7 A mis padres, quienes tanto esfuerzo han realizado para que sus hijos tengan una vida mejor que la suya. Por ser el pilar fundamental en todo lo que soy, por su incondicional apoyo a trav´es del tiempo. A mis abuelos, est´en donde est´en, porque estar´an felices de saber que su nieto logr´o su objetivo. 9 Agradecimientos Debo agradecer, de coraz´on, a la Dra. Carmen Paz Su´arez Araujo por diversos motivos. Y lo voy a hacer dando las gracias sin cansarme, porque ’Es de bien nacido ser agradecido’, que me dir´ıa ella. Gracias por haberme aceptado como su alumno all´a por el a˜no 2003. Y cuando digo alumno, no me refiero como alumno universitario. Me refiero como alumno del trabajo, del esfuerzo y del tes´on que ella impregna en todo lo que se propone. Gracias por su paciencia, su tremenda paciencia de la cual doy fe. Gracias por haberme enriquecido siempre, en todo trabajo que hemos realizado, en toda opini´on que me ha transmitido, en todo consejo que me ha dado. Gracias por haber fomentado en mi una forma de ver la vida, no s´olo la acad´emica, sino tambi´en la profesional. Gracias por estar siempre disponible cuando se le necesita, a cualquier hora y en cualquier lugar. Gracias, Carmen Paz. Al Dr. Patricio Garc´ıa B´aez quiero agradecerle el haberme transmitido su pasi´on por la computaci´on neuronal. Recuerdo aquellos a˜nos en los que una estaci´on de trabajo Sun era el mejor icono para representar a Patricio. ¡Grandes a˜nos! A˜nos en los que he tenido oportunidad de compartir con ´el ideas y proyectos. Gracias por haber estado siempre ah´ı, Patricio. Para mi compa˜nero y amigo Pablo Fern´andez L´opez s´olo tengo palabras de aprecio y agradecimiento. Porque aunque localizarle a veces resulta complicado, ..., ¡siempre est´a cuando se le necesita!. Porque ha sido un grand´ısimo apoyo en la elaboraci´on de este proyecto. Porque nadie mejor que ´el para proponer proyectos, para discutir ideas, para darle un sentido matem´atico y anal´ıtico a la vida. Gracias Pablo. Muchas gracias. vi ´ INDICE GENERAL A.2.8. Tabla ’diagnosis.CI’ ...........................149 A.2.9. Tabla ’diagnosis.DEMENTIA’ ......................149 A.2.10.Tabla ’diagnosis’ .............................149 A.2.11.Tabla ’employeetsatus’ ..........................150 A.2.12.Tabla ’exitus’ ...............................150 A.2.13.Tabla ’exploration.type’ .........................151 A.2.14.Tabla ’explorations’ ...........................151 A.2.15.Tabla ’gender’ ..............................152 A.2.16.Tabla ’habits’ ...............................152 A.2.17.Tabla ’incoming.rate’ ...........................152 A.2.18.Tabla ’institution’ ............................153 A.2.19.Tabla ’maritalstatus’ ...........................153 A.2.20.Tabla ’mcity’ ...............................153 A.2.21.Tabla ’mcomaut’ .............................154 A.2.22.Tabla ’mcountry’ .............................154 A.2.23.Tabla ’mstate’ ..............................155 A.2.24.Tabla ’patient.aacc.analytics’ ......................155 A.2.25.Tabla ’patient.aacc.prescription’ ....................155 A.2.26.Tabla ’patient.aacc.symptoms’ .....................156 A.2.27.Tabla ’patient.aacc.tests’ ........................157 A.2.28.Tabla ’patient.diseases’ .........................158 A.2.29.Tabla ’patient.habits’ ..........................158 A.2.30.Tabla ’patient’ ..............................159 A.2.31.Tabla ’physicians’ ............................161 A.2.32.Tabla ’physicians.tasks’ .........................161 A.2.33.Tabla ’prescription.drugs.type’ .....................162 A.2.34.Tabla ’profession’ .............................162 A.2.35.Tabla ’scholarship’ ............................162 Miguel ´ Angel P´erez del Pino ´ INDICE GENERAL vii A.2.36.Tabla ’status’ ...............................163 A.2.37.Tabla ’symptoms’ ............................163 A.2.38.Tabla ’tasks’ ...............................163 A.2.39.Tabla ’tests’ ................................164 A.2.40.Tabla ’ussual.diseases’ ..........................164 A.3. Diagramas de Relaci´on ..............................166 A.4. Listado de Tablas Generadas ..........................173 A.5. Listado de Claves Primarias y Ajenas Generados ...............175 A.6. Listado de Vistas .................................178 2 de octubre de 2015 viii ´ INDICE GENERAL Miguel ´ Angel P´erez del Pino ix ´ Indice de figuras 2.1. Diagrama de Alto Nivel de Joint Application Development/Design. . . . . . 10 2.2. Grado de Implicaci´on de los Usuarios Funcionales y T´ecnicos a lo largo del Ciclo de Vida del Proyecto seg´un JAD. ..................... 11 2.3. Grado de Implantaci´on de las Redes DSL, 3G y 4G en el territorio espa˜nol seg´un la CNMC en el a˜no 2013. ......................... 14 2.4. Diagrama de Casos de Uso, Subsistema Asistencial, actor ’Facultativo’. . . 23 2.5. Diagrama de Casos de Uso, Subsistema Asistencial, actor ’Facultativo’. . . 25 2.6. Diagrama de Casos de Uso, Subsistema Asistencial, acciones de exploraci´on para los actores ’Facultativo AP’ y ’Facultativo AE’. ............. 27 2.7. Diagrama de Casos de Uso, Subsistema Asistencial, acciones de test para los actores ’Facultativo AP’ y ’Facultativo AE’. ................ 28 2.8. Diagrama de Casos de Uso, Subsistema de Gesti´on, actor ’Administrador’. . 31 2.9. Diagrama B´asico de Estructura de un SIAD gen´erico. ............ 34 3.1. Diagrama del patr´on Modelo-Vista-Controlador. ............... 42 3.2. Aplicaci´on del patr´on Modelo-Vista-Controlador sobre Joomla, incorporando elementos del modelo de sistemas. ...................... 43 3.3. Arquitectura Gen´erica de OGE. ......................... 48 3.4. Modelo de Sistemas Propuesto. ......................... 54 4.1. Imagen del Rack que almacena las m´aquinas de EDEVITALZH. ...... 60 4.2. Diagrama Conceptual del Cl´uster a Implementar sobre OGE. ........ 65 x´ INDICE DE FIGURAS 4.3. Captura de pantalla del navegador accediendo a index.html en el servidor ’sinapsis’. ..................................... 72 4.4. Captura de pantalla del navegador accediendo a index.html v´ıa ’https’ en ’sinapsis’. ..................................... 72 4.5. Capura de Pantalla del Front-End de Ganglia sobre EDEVITALZH. . . . . 73 4.6. Paso 1 de la instalaci´on de Joomla. ....................... 78 4.7. Paso 2 de la instalaci´on de Joomla. ....................... 78 4.8. Paso 3 de la instalaci´on de Joomla. ....................... 79 4.9. Paso 4 de la instalaci´on de Joomla. ....................... 79 4.10. Paso 5 de la instalaci´on de Joomla. ....................... 80 4.11. Paso 6 de la instalaci´on de Joomla. ....................... 80 4.12. Paso 7 de la instalaci´on de Joomla. ....................... 81 4.13. Subsistema 1 de Joomla. Aplicaci´on Web. ................... 81 4.14. Subsistema 2 de Joomla. Aplicaci´on de Administraci´on. ........... 82 4.15. Captura de Pantalla Anonimizada de Siemens Selene Clinic. ......... 84 4.16. Diagrama de UI propuesto para EDEVITALZH. ............... 85 4.17. Gr´afica del Seguimiento del DCL de un paciente utilizando Plotalot. . . . . 91 4.18. P´agina: Inicio. .................................. 91 4.19. P´agina: B´usqueda de Pacientes. ......................... 92 4.20. P´agina: Ver o Editar Datos Demogr´aficos del Paciente. ............ 93 4.21. P´agina: Ver o Editar Datos Demogr´aficos del Paciente (II). ......... 93 4.22. P´agina: Registrar Nuevo Paciente. ....................... 94 4.23. P´agina: Historia Cl´ınica — Actividad Asistencial del Paciente. ....... 95 4.24. P´agina: Historia Cl´ınica — Actividad Asistencial del Paciente. ....... 96 4.25. P´agina: Crear Nueva Consulta. ......................... 97 4.26. P´agina: Historia Cl´ınica de Consulta — Protocolo Cl´ınico. .......... 98 4.27. P´agina: Historia Cl´ınica de Consulta — Protocolo Cl´ınico (II). ....... 99 4.28. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva. ...........100 Miguel ´ Angel P´erez del Pino ´ INDICE DE FIGURAS xi 4.29. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva (II). .........101 4.30. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test Informador. 101 4.31. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test Minimental. 102 4.32. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test MEC. . . . . 102 4.33. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test Pfeiffer. . . 103 4.34. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test del Reloj. . 103 4.35. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva. .........104 4.36. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 4. ..........................................105 4.37. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 10. .........................................105 4.38. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 15. .........................................106 4.39. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 30. .........................................106 4.40. P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test NPI. . . 107 4.41. P´agina: Protocolo Cl´ınico — Exploraci´on Funcional. .............108 4.42. P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Barthel. . . . . 109 4.43. P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Fast. ......109 4.44. P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Katz. . . . . . 110 4.45. P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test de Lawton-Brody.110 4.46. P´agina: Protocolo Cl´ınico — Exploraci´on Neurol´ogica. ............111 4.47. P´agina: Protocolo Cl´ınico — Exploraci´on F´ısica. ...............112 4.48. P´agina: Protocolo Cl´ınico — H´abitos del Paciente. ..............113 4.49. P´agina: Protocolo Cl´ınico — Patolog´ıas Intercurrentes del Paciente. . . . . 114 4.50. P´agina: Protocolo Cl´ınico — Patolog´ıas Intercurrentes del Paciente (II). . . 115 4.51. P´agina: Protocolo Cl´ınico — Pruebas Complementarias. ...........116 4.52. P´agina: Protocolo Cl´ınico — Pruebas Complementarias (II). .........117 4.53. P´agina: Protocolo Cl´ınico — Pruebas Complementarias (III). ........118 2 de octubre de 2015 xii ´ INDICE DE FIGURAS 4.54. P´agina: Protocolo Cl´ınico — Prescripci´on Farmacol´ogica del Paciente. . . . 119 4.55. P´agina: Protocolo Cl´ınico — Diagn´osticos del Paciente. ...........120 4.56. P´agina: Protocolo Cl´ınico — Diagn´osticos del Paciente. ...........121 4.57. P´agina: Diagn´ostico — Diagn´ostico Facultativo. ................122 4.58. P´agina: Diagn´ostico — Diagn´ostico Facultativo. ................123 4.59. P´agina: Interconsulta — Solicitud. .......................124 4.60. P´agina: Interconsulta — Recepci´on. ......................125 4.61. Diagrama de Alto Nivel de Integraci´on de un SIAD gen´erico en EDEVITALZH. .......................................127 4.62. Integraci´on de M´ultiples SIAD en EDEVITALZH. ..............128 4.63. Visualizaci´on de EDEVITALZH desde iPhone 6 (iOS), utilizando navegador Safari, y desde Huawei P6 (Android), utilizando navegador Chrome. . . . . 129 4.64. Visualizaci´on de EDEVITALZH desde iPhone 6 (iOS), utilizando navegador Safari — Actividad Asistencial del Paciente ..................130 4.65. Visualizaci´on de EDEVITALZH desde iPhone 6 (iOS), utilizando navegador Safari — Listado de Consultas del Paciente. ..................130 4.66. Visualizaci´on de EDEVITALZH desde iPhone 6 (iOS), utilizando navegador Safari — Gr´afica de Evoluci´on del DCL. ....................131 A.1. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, G´enero, Estado Civil, Escolaridad e Instituci´on. ......................139 A.2. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Localidad, Comunidad Aut´onoma y Pa´ıs. ..........................140 A.3. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, H´abito y Patolog´ıa Intercurrente. ...............................140 A.4. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Profesi´on, Situaci´on Laboral y Nivel Salarial. .......................140 A.5. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Episodio, Facultativo y Tipo de Actividad. .........................141 A.6. Diagrama de Entidad/Interrelaci´on de las entidades Exploraci´on y Tipo de Exploraci´on. ....................................141 Miguel ´ Angel P´erez del Pino ´ INDICE DE FIGURAS xiii A.7. Diagrama de Entidad/Interrelaci´on de las entidades Episodio, Facultativo, Exploraci´on, Prueba Complementaria y Prescripci´on Farmacol´ogica. . . . . 141 A.8. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Facultativo, Exploraci´on, Prueba Complementaria y Prescripci´on Farmacol´ogica. . . . . 142 A.9. Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Facultativo, Episodio y Exploraci´on. .............................142 A.10.Diagrama de Entidad/Interrelaci´on de las entidades S´ıntoma, Tipo de Exploraci´on y Test. .................................142 A.11.Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Episodio, S´ıntoma y Test. ..................................143 A.12.Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Episodio, Prueba Complementaria, Tipo de Prueba Complementaria y Par´ametro. . . 143 A.13.Diagrama de Entidad/Interrelaci´on de las entidades Diagn´ostico, Tipo de Patolog´ıa y Grado de Deterioro. .........................143 A.14.Diagrama de Entidad/Interrelaci´on de las entidades Paciente, Episodio y Diagn´ostico. ....................................144 A.15.Diagrama de Entidad/Interrelaci´on de las entidades Episodio, Diagn´ostico, Facultativo y Sistema Computacional de Diagn´ostico. ............144 A.16.Relaci´on de las Tablas: patient, mcity, mstate, mcountry. ..........166 A.17.Relaci´on de las Tablas: patient, gender, institution, maritalstatus, scholarship.166 A.18.Relaci´on de las Tablas: patient, employeestatus, incoming rate, maritalstatus, profession. ..................................167 A.19.Relaci´on de las Tablas: patient, patient diseases, codigo cie, habits y patient habits.. ......................................167 A.20.Relaci´on de las Tablas: aacc (episodios), activity type y physicians. . . . . . 168 A.21.Relaci´on de las Tablas: explorations y exploration types. ...........168 A.22.Relaci´on de las Tablas: patient, aacc, physicians, analytics, complementarytests, complementary-tests-types, status, patient-aacc-analytics. .......168 A.23.Relaci´on de las Tablas: patient, aacc, physicians, explorations, explorationtypes, tests, patient-aacc-tests, patient-aacc-symptoms. ............169 A.24.Relaci´on de las Tablas: patient, aacc, physicians, prescription-drugs-type y patient-aacc-prescription. ............................169 2 de octubre de 2015 xiv ´ INDICE DE FIGURAS A.25.Relaci´on de las Tablas: aacc, patient-aacc-symptoms, patient-aacc-tests, patient-aacc-analytics y patient-aacc-prescription. ...............170 A.26.Relaci´on de las Tablas: patient, aacc, physicians, patient-aacc-tests y patientaacc-symptoms. ..................................170 A.27.Relaci´on de las Tablas: exploration-type, symptoms y tests. .........171 A.28.Relaci´on de las Tablas: complementary-tests, complementary-tests-type y patient-aacc-analytics. ..............................171 A.29.Relaci´on de las Tablas: patient, aacc, physicians, analytics, status y patientaacc-analytics. ..................................171 A.30.Relaci´on de las Tablas: diagnosis, diagnosis-CI, diagnosis-DEMENTIA y status. .......................................172 A.31.Relaci´on de las Tablas: patient, physicians, aacc, diagnosis, interconsultation y status. ...................................172 Miguel ´ Angel P´erez del Pino xv ´ Indice de cuadros 4.1. Lista de M´aquinas del Proyecto EDEVITALZH. ................ 59 4.2. ´ Indices M´ax y Min. de Ejecuci´on de LINPACK (GFlops) en cada una de las m´aquinas. ................................... 61 6 CAP´ ITULO 1. INTRODUCCI´ ON tencia sanitaria a zonas de dif´ıcil acceso, alejadas de los hospitales, dotadas de un n´umero insuficiente de especialistas, o con escasez de recursos. Existen algunos proyectos en este sentido llevados a cabo en Sudam´erica, la India o Australia, entre otros, donde existe un alto ´ındice de poblaci´on que vive en ciudades no capitalinas. En este ´ultimo, se ha llevado a cabo un estudio de los beneficios que el uso de la telemedicina ha proporcionado a las zonas rurales australianas [50]. En esta misma l´ınea, existen otros proyectos en el ´ambito de la telepsiquiatr´ıa aplicados a ni˜nos y j´ovenes que viven alejados de n´ucleos urbanos y precisan de asistencia psicol´ogica y psiqui´atrica, empleando para ello todo el potencial de la videoconferencia [64,80]. El uso de esta herramienta combinada con realidad virtual mediante salas de telepresencia, donde el usuario no s´olo tiene la sensaci´on de estar f´ısicamente en un mundo virtual, sino que adem´as puede interactuar con ´el, hace posible llevar a cabo sesiones de psicoterapia remotas, permitiendo el tratamiento de diferentes enfermedades psicol´ogicas como ansiedad, trastornos alimenticios, agorafobia, p´anicos, etc. [4,24]. Hasta ahora, la telemedicina como herramienta de ayuda en el diagn´ostico de la EA ha resultado fiable cuando se ha realizado mediante videoconferencia [81]. Un estudio mostr´o una sensibilidad del 90 % y una especificidad del 100 % para el diagn´ostico de demencia realizado a trav´es de videoconferencia [45]. Otro trabajo mostr´o que no exist´ıan diferencias entre el diagn´ostico basado en una entrevista cl´ınica presencial y el diagn´ostico realizado mediante telemedicina [70]. En programas basados en videoconferencia con entrevistas cara a cara, tanto para el diagn´ostico como para la rehabilitaci´on cognitiva de estos pacientes, se obtuvieron resultados similares [76,72]. Tambi´en se han desarrollado programas de telemedicina, aplicados a las demencias, dirigidos a ofrecer asesoramiento sobre el manejo de los pacientes al personal de enfermer´ıa o para dar soporte en l´ınea mediante informaci´on a los cuidadores, que tambi´en dieron buenos resultados [30,51]. Las estrategias de telemedicina desarrolladas en Espa˜na se han orientado principalmente hacia ofrecer y mejorar la asistencia especializada en zonas distantes o aisladas y/o soporte en situaciones de emergencia, buscando posibles canales de comunicaci´on entre AP y los especialistas en estas patolog´ıas. Sin embargo, adolecen en la forma en que comparten la informaci´on cl´ınica de las historias de los pacientes. La interoperabilidad entre sistemas heterog´eneos y distribuidos sigue siendo uno de los mayores h´andicaps de la eSalud. Un caso caracter´ıstico es el del Servicio Navarro de Salud, que realiza an´alisis y recomendaciones al respecto [57]. Miguel ´ Angel P´erez del Pino 1.3. OBJETIVOS 7 1.3. Objetivos Este Proyecto de Fin de Carrera (PFC) pretende cubrir el vac´ıo existente en el campo de los sistemas de HCE con EC, concretamente en los ´ambitos cl´ınicos de la Geriatr´ıa y la Neurolog´ıa. Se hace necesario modelos de salud innovadores y flexibles que permitan asistir eficientemente en el contexto planteado. Para ello, la propuesta de este PFC es un entorno cl´ınico virtual que alcance los siguientes objetivos: Dise˜nar e implementaci´on de una EC para uso en telemedicina, basada en el modelo de aplicaciones web, que recoja los indicadores cl´ınico-asistenciales necesarios para el diagn´ostico de la EA, el DCL y otras demencias y asista en el proceso de diagn´ostico de las demencias. Implementar herramientas e instrumentos diagn´osticos neurol´ogicos y geriatras de manera electr´onica, que sean de utilidad para los facultativos en el proceso de valoraci´on diagn´ostica y posterior decisi´on terap´eutica de los pacientes. Que el sistema a desarrollar implemente la capacidad de cooperaci´on en telemedicina, es decir, que disponga de la posibilidad de comunicar a los facultativos entre s´ı, propiciando que puedan compartir y valorar la historia cl´ınica de un paciente de manera ´agil. Dotar a la EC de capacidad de integraci´on con Sistemas Inteligentes de Ayuda al Diagn´ostico, lo que permitir´a disponer de una EC Inteligente que facilite y asista al facultativo en la toma de decisiones. Todo ello representar´a un alto grado de innovaci´on en el ´ambito socio-sanitario, potenciando el diagn´ostico, la adecuada ayuda a la toma de decisiones facultativas y la aplicaci´on de los correspondientes procedimientos terap´euticos de manera temprana, mediante una plataforma de e-Health con fundamentos de EC inteligente. 1.4. Metodolog´ıa y Recursos En este proyecto, se aborda los objetivos desde una perspectiva multidisciplinar, que incluye m´etodos de Ingenier´ıa del Software, la Infraestructura de Sistemas y las Bases de Datos. As´ı pues: En lo referente a Ingenier´ıa del Software, se ha hecho de uso de diferentes m´etodos y herramientas. Para la captura de requisitos, dise˜no y testing del sistema, se ha empleado metodolog´ıa JAD [36,38], integrando en el proceso de construcci´on a un 2 de octubre de 2015 8 CAP´ ITULO 1. INTRODUCCI´ ON grupo de expertos cl´ınicos que han colaborado a lo largo de todo el ciclo de desarrollo. Dado el fundamento web del sistema a desarrollar, durante la etapa de dise˜no se hizo enfoque en el modelo de aplicaciones web y, espec´ıficamente, de las aplicaciones modulares RIA (Rich Internet Application). Como patr´on de dise˜no, se ha empleado el patr´on MVC. En lo relativo a la implementaci´on, se ha utilizado una plataforma modular y extensible de gesti´on de contenidos fundamentada sobre MVC, Joomla [39,40], que ha permitido desarrollar una aplicaci´on web rica en funcionalidades aprovechando la reutilizaci´on de c´odigo y los componentes y extensiones que ´esta ofrece. Las secciones de c´odigo desarrollado han sido escritas en lenguaje PHP. En lo que respecta a las Bases de Datos, se realiz´o un estudio centrado en la idea de ’protocolo cl´ınico’ como herramienta ´optima para la organizaci´on y estandarizaci´on de indicadores sanitarios. El an´alisis y dise˜no del modelo de datos fue realizado empleando el Modelo de Entidad-Interrelaci´on y su implementaci´on se desarroll´o utilizando sentencias DDL en lenguaje SQL sobre un servidor de bases de datos MySQL. Se dise˜naron y desarrollaron procedimientos almacenados de carga y transformaci´on de datos (ETL) para incorporar historias cl´ınicas reales al sistema con la intenci´on de validarlo fehacientemente. En cuanto a Infraestructura de Sistemas, se dispuso de 6 servidores de arquitecturas heterog´eneas y diferentes ´epocas de fabricaci´on, 2 estaciones de trabajo, un router 3COM tipo WAN y 2 UPS para la implementaci´on de la infraestructura f´ısica del sistema. Se dise˜n´o una estructura basada en Computaci´on de Alta Productividad (HTC) sobre Open Grid Engine como soluci´on a la necesidad de una pol´ıtica de planificaci´on y ejecuci´on de trabajos bajo demanda, motivada por la integraci´on de Sistemas Inteligentes de Ayuda al Diagn´ostico. Todas las m´aquinas empleadas corren sistema operativo Linux. En cuanto a los servicios middleware, se implant´o un servidor web Apache, un servidor de bases de datos MySQL, un servidor NFS para la compartici´on de datos y un servidor NIS para unificar los ficheros maestros del cl´uster HTC. Para la edici´on de esta memoria, se ha utilizado LaTeX como sistema de composici´on del texto. Miguel ´ Angel P´erez del Pino 9 Cap´ıtulo 2 Ingenier´ıa de Requisitos 2.1. Introducci´on La Ingenier´ıa de Requisitos comprende el descubrimiento de necesidades y limitaciones, y el establecimiento de objetivos, medidas y restricciones para conseguir un sistema ´agil, ´util y fiable para el usuario final, minimizando los costes de desarrollo, puesta en producci´on y mantenimiento posterior, en cualquiera de sus niveles (correctivo, evolutivo, adaptativo y perfectivo) [33,34]. Abarca dos vertientes principales: La exploraci´on en busca necesidades, solicitudes y expectativas de los futuros usuarios finales en cuanto al nuevo sistema se refiere; es decir, funcionalidades, agrupadas como ’requisitos funcionales’. El an´alisis contextual y tecnol´ogico, para la adopci´on de metodolog´ıas, normativas y directrices de construcci´on, y el establecimiento de restricciones y l´ımites, todo ello agrupado como ’requisitos no funcionales’. Se busca desarrollar software de calidad, ajustado a las necesidades del usuario final, minimizando posibles situaciones inconsistentes y conflictos que pudieren surgir en el ciclo de vida del sistema a desarrollar. La identificaci´on de requisitos de EDEVITALZH se ha llevado a cabo empleando la metodolog´ıa JAD (Joint Application Design). JAD pretende optimizar la construcci´on de nuevos sistemas de informaci´on potenciando la colaboraci´on entre dos grupos de expertos. El primer grupo es el denominado org´anico/funcional, en el que participa un reducido conjunto de expertos en el negocio sobre el que el nuevo sistema de informaci´on operar´a, aportando su conocimiento y experiencia. JAD propone mejoras en el concepto de entrevistas durante la fase de descubrimiento de requisitos [33], y hace part´ıcipes y 10 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS Figura 2.1: Diagrama de Alto Nivel de Joint Application Development/Design. responsables a los usuarios funcionales de determinadas operaciones a lo largo del ciclo de vida del sistema, m´as all´a de la mera descripci´on de necesidades, entre ellas, su aportaci´on al dise˜no funcional y la validaci´on intensiva [34]. Se demuestra que la participaci´on de un grupo de trabajo experto en el negocio desde el comienzo del proyecto mejora la calidad de las especificaciones y agiliza la construcci´on de la soluci´on, reduciendo gran parte de las posibles desviaciones temporales y presupuestarias derivadas de inconsistencias en la identificaci´on de requisitos [33,34,36,38]. Concretamente, el grupo funcional tiene una mayor implicaci´on en las fases tempranas y tard´ıas de proyecto (Fig. 2.2): toma de requisitos (TR), dise˜no funcional (DRf), testing y validaci´on (T). El grupo de usuarios funcionales de EDEVITALZH ha estado compuesto por facultativos cl´ınicos expertos en los campos de la Geriatr´ıa y la Neurolog´ıa. El segundo grupo es el t´ecnico, en el que los especialistas en Tecnolog´ıas de la Informaci´on definen las bases sobre las que ser´a construido el nuevo sistema, en funci´on de las necesidades y metas planteadas por el grupo funcional. El ´ambito t´ecnico se desarrolla con mayor ´enfasis durante las fases intermedias y tard´ıas de proyecto (Fig. 2.2): an´alisis y dise˜no de requisitos no funcionales (DRnf ), implementaci´on (IMP) y puesta en producci´on y mantenimiento post-producci´on (PM). El grupo t´ecnico de EDEVITALZH ha estado compuesto por los directores de este Proyecto de Fin de Carrera y el propio autor del mismo. Para la construcci´on de EDEVITALZH, se ha llevado a cabo 3 tipos de sesiones de trabajo propuestas por JAD. El primer tipo utilizado, las scripted sessions oreuniones con gui´on, en las que los directores de este proyecto y su autor han mantenido entrevistas con el personal cl´ınico involucrado de manera individual, ha permitido analizar sus neceMiguel ´ Angel P´erez del Pino 2.1. INTRODUCCI´ ON 11 Figura 2.2: Grado de Implicaci´on de los Usuarios Funcionales y T´ecnicos a lo largo del Ciclo de Vida del Proyecto seg´un JAD. sidades y demandas, y evaluando posibles deficiencias encontradas en el flujo de trabajo de ´estos en el momento de las entrevistas; deficiencias que deber´ıan ser mejoradas en el nuevo sistema. El segundo tipo de reuniones ha sido los brainstorms, grupales, en los que se ha buscando aportar nuevas ideas y conceptos que incrementasen las bondades de las funcionalidades a desarrollar en el sistema. El tercer tipo, enfocado al desarrollo t´ecnico, han sido las reuniones de tiempo limitado, entre los directores de este proyecto y su autor, con momentos de inicio y fin definidos. Se trata de reuniones acotadas en el tiempo en las que se debate, con prioridad, los temas identificados como obligatorios, mientras que si hay extra de tiempo, se puede abordar otros, etiquetados como secundarios en ese instante de proyecto. Los temas van cambiando de un estado al otro hasta ser resueltos, conforme se avanza en el ciclo de vida del proyecto. Los procesos aplicados durante la ingenier´ıa de requisitos han dado como resultado el contenido de los pr´oximos apartados de este cap´ıtulo: El apartado 2.2 aborda la identificaci´on de Requisitos Funcionales. El apartado 2.3 describe la identificaci´on de Requisitos No Funcionales. El apartado 2.4 detalla el Modelo de Negocio y sus entidades a implementar. El apartado 2.5 desarrolla el an´alisis de actores, subsistemas, casos de uso y clases UML. El apartado 2.6 describe los fundamentos de los Sistemas Inteligentes de Ayuda al Diagn´ostico, con los que EDEVITALZH asistir´a a los facultativos en la toma de decisiones diagn´osticas y terap´euticas. 2 de octubre de 2015 12 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS 2.2. Requisitos Funcionales Siguiendo los m´etodos de la metodolog´ıa JAD comentados anteriormente, se identific´o, junto al personal funcional participante en este Proyecto de Fin de Carrera (PFC), los siguientes requisitos de alto nivel para el nuevo sistema a construir. En definitiva, este PFC pretende: Cubrir el vac´ıo de informatizaci´on existente en los ´ambitos de la Geriatr´ıa y la Neurolog´ıa, que potencie la toma decisiones facultativas para el diagn´ostico, terapia, seguimiento e investigaci´on de la EA, el DCL y otras demencias. Que se aproveche el amplio nivel de implantaci´on tecnol´ogico existente (equipamiento,software ycomunicaciones) en la sanidad a nivel mundial, y m´as concretamente, en la espa˜nola, potenciando su uso en tanto en Atenci´on Primaria como en Especializada, incluso en centros con reducido nivel de recursos tecnol´ogicos. Que el sistema permita ser utilizado ’en cualquier lugar y en cualquier momento’. Que el nuevo sistema implemente los criterios fundamentales de la HCE, GP yEC, que van m´as all´a de la mera recopilaci´on de datos socio-demogr´aficos y administrativos de los pacientes en un ordenador con mayor o menor capacidad de explotaci´on de datos. Que el sistema, a trav´es de su fundamento de EC, gu´ıe al usuario en su trabajo a trav´es de asistentes, formularios y procedimientos automatizados, haciendo sencillo e intuitivo el proceso de recogida, b´usqueda y an´alisis de los datos que conforman las historias cl´ınicas, favoreciendo al mismo tiempo la dedicaci´on a los pacientes. Que potencie el trabajo colaborativo, permitiendo la asistencia entre diferentes profesionales sanitarios mediante el acceso compartido de historias cl´ınicas, enriqueciendo as´ı la calidad del proceso asistencial de los pacientes con sus aportaciones, su diagn´ostico y su tratamiento. Que permita la explotaci´on de los datos recabados, ayudando as´ı a enriquecer el conocimiento disponible sobre los pacientes, sus patolog´ıas y su evoluci´on. Que provea de herramientas inform´aticas que permitan evaluar la evoluci´on patol´ogica de los pacientes, enfocadas al estudio de demencias, y en especial, de la EA. Que el sistema mantenga una normalizaci´on de identidad visual, no cambiando de aspecto seg´un donde sea visualizado. Se debe evitar generar dudas de uso a los usuarios finales por cambios, por m´ınimos que sean, en la interfaz de usuario. Miguel ´ Angel P´erez del Pino 2.3. REQUISITOS NO-FUNCIONALES 13 Que ayude al facultativo en la toma de decisiones, apoyado por Sistemas Inteligentes de Ayuda al Diagn´ostico (SIAD) integrables en el sistema de manera modular, transparente e intuitiva para el usuario. Que respete los criterios exigidos por la legislaci´on vigente en Espa˜na y la mayor´ıa de pa´ıses de la Eurozona en cuanto a tratamiento de datos de car´acter personal y sociedad de la informaci´on. 2.3. Requisitos No-Funcionales 2.3.1. Arquitectura El sistema debe ser accesible utilizando la red Internet. Se debe aprovechar la amplia implantaci´on de comunicaciones en los centros sanitarios a trav´es de ADSL, Fibra ´ Optica, 3G y/o 4G. Este modelo se ajusta a los requisitos de usabilidad ’en cualquier lugar y en cualquier momento’. Seg´un datos de 2013 de la Comisi´on Nacional de los Mercado y la Competencia del Gobierno de Espa˜na, el 97,9 % del territorio nacional dispon´ıa ya de ADSL y red 3G, mientras que el 60 % dispon´ıa de red 4G [12], (Fig. 2.3). EDEVITALZH ser´a implementado siguiendo el modelo de aplicaciones web. Esto permitir´a una ´unica interfaz de usuario multi-plataforma, utilizando exclusivamente un navegador web. La aplicaci´on web se basar´a, principalmente, en un conjunto de formularios para la recogida y visualizaci´on de datos. Los datos de la aplicaci´on deber´an estar almacenados en un sistema gestor de bases de datos, sobre el cual puedan realizarse futuros estudios e investigaci´on. El dise˜no y la implementaci´on del sistema se realizar´a aplicando Desarrollo R´apido de Aplicaciones (RAD, del ingl´es Rapid Application Development), metodolog´ıa que aporta agilidad y rapidez en la construcci´on, a la vez que se minimiza el tiempo de entrega. Se respetar´a ´ıntegramente la Ingenier´ıa de Requisitos. Para corregir posibles desviaciones, se mostrar´a la evoluci´on del desarrollo de manera peri´odica, centr´andose el mantenimiento correctivo y perfectivo del producto web en iteraciones de desarrollo acotadas seg´un volumen de trabajo (limitando el n´umero de cambios por iteraci´on). El arquitectura propuesta deber´a buscar mejorar la productividad del sistema, entendi´endose con ello que debe atenderse a m´ultiples usuarios de manera simult´anea y en tiempos de respuesta aceptables. 2 de octubre de 2015 14 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS Figura 2.3: Grado de Implantaci´on de las Redes DSL, 3G y 4G en el territorio espa˜nol seg´un la CNMC en el a˜no 2013. Ante el crecimiento de la demanda de recursos (CPU, memoria f´ısica, memoria de almacenamiento, actividad de red, etc.), habitualmente propiciado por un crecimiento en el volumen de usuarios, la arquitectura propuesta debe tener la posibilidad de crecer en prestaciones de manera transparente al servicio, a fin de mejorar la calidad del mismo. 2.3.2. Interfaz de Usuario El sistema debe tener una ´unica identidad visual y de producto. Colores, formas y ubicaci´on de las principales herramientas deben ser normalizados. La aplicaci´on web a desarrollar deber´a tener una estructura clara, ordenando el contenido y las funciones implementadas en pesta˜nas o apartados que abarquen todas las funcionalidades disponibles. Evidentemente, debe ser atractiva al uso y de f´acil manejo. Ser´ıa deseable disponer de peticiones as´ıncronas en AJAX que mejoren la experiencia del usuario final, evitando recargas de p´agina innecesarias (p.e. en la verificaci´on de formularios, previa a los env´ıos al servidor), pero con el compromiso de ’no sobrecargar’ en solicitud de recursos a los servidores de aplicaci´on y de bases de datos que soportan EDEVITALZH. La aplicaci´on web deber´a facilitar la recogida de datos complejos, demogr´aficos y cl´ınicos, implement´andose formularios con la mayor cantidad posible de campos de selecci´on (combos, checkboxes, radioboxes) y no de escritura (textboxes). Esto ayuMiguel ´ Angel P´erez del Pino 2.3. REQUISITOS NO-FUNCIONALES 15 dar´a a la estandarizaci´on en la terminolog´ıa y en la normalizaci´on de los datos almacenados. Ser´ıa deseable el uso de tablas y grids que mejoren la lectura y la navegabilidad. En respuesta al requisito funcional que solicita herramientas inform´aticas que permitan evaluar la evoluci´on patol´ogica de los pacientes, enfocadas al estudio de demencias, se propone la representaci´on de gr´aficos de evoluci´on, simples y sencillos, en donde el facultativo disponga de una visi´on resumida de par´ametros de inter´es de los episodios del paciente. 2.3.3. Desarrollo, Reutilizaci´on, Escalabilidad, Mantenimiento Las licencias de software de la plataforma y con las que se implemente la aplicaci´on web deben ser lo menos restrictivas posible, preferentemente opt´andose por software de c´odigo abierto. La aplicaci´on web a desarrollar deber´a cumplir con las normas de accesibilidad para aplicaciones web (WAI 2.0) definidas por el W3C [82], debiendo cumplir al menos con el nivel A. Ser´ıa deseable seleccionar una tecnolog´ıa de desarrollo que potencie: •La escalabilidad de funcionalidades del producto, permitiendo adoptar mejoras y nuevos requisitos de manera ligera. •La modularidad, mediante el uso de componentes que encapsulen o ayuden a implementar funcionalidades individuales, que ser´an respuesta a los requisitos planteados a lo largo de este cap´ıtulo. •Un f´acil mantenimiento del producto desarrollado, que permita correctivos y/o actualizaciones en caliente, afectando ´unicamente al servicio de las funcionalidades afectadas, no al sistema completo. Esto permitir´a evitar p´erdidas de servicio general ante la mayor´ıa de operaciones de mantenimiento del sistema. 2.3.4. Sistemas Inteligentes de Ayuda al Diagn´ostico Todo SIAD debe estar compuesto por una estructura standalone, fichero compilado o interpretado en alg´un lenguaje espec´ıfico (perl, python, bash, batch, etc.), de forma que pueda ser ejecutado en una ´unica llamada a la orden que lo representa. Se debe dotar a todo SIAD de mecanismos para la recepci´on y lectura de aquellos par´ametros de inter´es de la HCE del paciente para las tareas de ayuda a la toma de decisi´on en el proceso de diagn´ostico. 2 de octubre de 2015 22 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS 2.5.3.1. Acci´on ’Iniciar Sesi´on en Subsistema Asistencial’ Actor/es: Facultativos. Pre-Condici´on: No estar autentificado en el sistema. Post-Condici´on: Se autentifica al usuario en el sistema. Descripci´on: Si el usuario es reconocido como autorizado, mediante su login y su contrase˜na, acceder´a a la p´agina principal, que contiene el listado de pacientes. En caso contrario, se le denegar´a el acceso, volviendo a solicitar su login y su contrase˜na. 2.5.3.2. Acci´on ’Finalizar Sesi´on en Subsistema Asistencial’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario deja de estar autentificado. Descripci´on: El usuario ser´a expulsado de la aplicaci´on, llev´andole de nuevo a la p´agina de inicio, donde podr´a volver a autentificarse e iniciar sesi´on si as´ı lo desea. 2.5.3.3. Acci´on ’B´usqueda de Pacientes’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: Se visualiza el listado de pacientes. Descripci´on: El usuario acceder´a a la pesta˜na de b´usqueda de pacientes, donde tendr´a acceso al listado tabulado de los pacientes registrados en el sistema y podr´a: 1. Navegar de manera manual a trav´es de todo el listado de pacientes ordenados alfab´eticamente por los campos ’Apellidos’ y ’Nombre’ de manera ascendente. 2. Buscar una cadena de texto en todos los campos, localizando aquellos pacientes que cumplan la condici´on. 3. Buscar una cadena de texto en un campo concreto, localizando aquellos pacientes que cumplan la condici´on. 2.5.3.4. Acci´on ’Registrar Nuevo Paciente’ Actor/es: Facultativos. Miguel ´ Angel P´erez del Pino 2.5. MODELO CONCEPTUAL 23 Figura 2.4: Diagrama de Casos de Uso, Subsistema Asistencial, actor ’Facultativo’. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: Se registra un nuevo paciente, asoci´andole autom´aticamente el sistema un n´umero secuencial de historia cl´ınica (NHC) y almacen´andose sus datos demogr´aficos en base de datos. Descripci´on: El usuario acceder´a a la pesta˜na ’Registrar Nuevo Paciente’, en donde encontrar´a un formulario simple que le solicitar´a los datos demogr´aficos del nuevo paciente. Una vez completados, pulsar´a el bot´on de ’Registrar’, que registrar´a al nuevo paciente en el sistema. 2.5.3.5. Acci´on ’Acceder a los Datos Demogr´aficos de un Paciente’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario accede a los datos demogr´aficos del paciente en cuesti´on. Descripci´on: Una vez localizado el paciente en una b´usqueda de pacientes, el usuario pulsar´a en la opci´on ’M´as Datos’, que le permitir´a acceder a los datos demogr´aficos registrados del paciente en cuesti´on. 2.5.3.6. Acci´on ’Actualizar los Datos Demogr´aficos de un Paciente’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario actualiza los datos demogr´aficos que estime para el paciente en cuesti´on. 2 de octubre de 2015 24 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS Descripci´on: Una vez accedidos los datos demogr´aficos del paciente en cuesti´on, el usuario podr´a modificar aquellos que estime oportunos, a excepci´on de aquellos generados autom´aticamente por el sistema (como el NHC). Pulsar´a el bot´on ’Actualizar’, que almacenar´a los nuevos datos en la base de datos. 2.5.3.7. Acci´on ’Acceder a la Historia Cl´ınica de un Paciente’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario accede a la Historia Cl´ınica (HC) del paciente. Descripci´on: Una vez localizado el paciente en una b´usqueda de pacientes, el usuario pulsar´a en la opci´on ’Ver Historia’, que le permitir´a acceder al proceso asistencial del paciente en cuesti´on. Desde esta vista, podr´a: •Acceder al ’Informe de Historia Cl´ınica’, que resume toda la HC del paciente e imprimirlo desde la acci´on ’Imprimir’ presente en el mismo, descrita en el apartado 2.5.3.20. •Acceder, de manera independiente, al resumen de cada una de las subsecciones de la HC del paciente. Podr´a imprimir cada resumen desde la acci´on ’Imprimir’ presente en cada subsecci´on, descrita en el apartado 2.5.3.20. 2.5.3.8. Acci´on ’Crear Nueva Consulta’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario registrada un nuevo episodio cl´ınico para el paciente en cuesti´on. Descripci´on: Ante una visita a consulta (primera o sucesiva), el usuario facultativo registrar´a una nueva consulta pulsando sobre la opci´on ’Crear Nueva Consulta’ disponible en la HC del paciente. Podr´a especificar los siguientes datos: •Tipo de Actividad: Si la visita corresponde a AP, AE u OA (Sociosanitaria, Hospitalizaci´on a Domicilio u otras). •Fecha: Fecha de la consulta. Permite el registro de visitas pasadas (hist´orico). Miguel ´ Angel P´erez del Pino 2.5. MODELO CONCEPTUAL 25 •Facultativo: Puede asociarse a s´ı mismo (por defecto), o asociarse a otro facultativo (p.e. debido a que la HC es hist´orica (por ejemplo, en papel) y era responsabilidad de otro facultativo). La aplicaci´on permitir´a asociar el episodio a otro facultativo autorizado en el sistema. •Observaciones: Un campo libre para indicar comentarios de inter´es relativos al episodio. 2.5.3.9. Acci´on ’B´usqueda de Consultas de un Paciente’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: Se visualiza el listado de consultas asociadas a un paciente. Descripci´on: Tras acceder a la vista de ’Historia Cl´ınica del Paciente’, descrita en 2.5.3.7 (Acci´on ’Acceder a la Historia Cl´ınica de un Paciente’), el facultativo dispondr´a en dicha vista de la secci´on ’Listado de Consultas del Paciente’, en donde se mostrar´a la lista de episodios de dicho paciente, identificadas mediante los siguientes datos: •El identificador de consulta (num´erico). •La fecha de realizaci´on de la consulta. •El nivel asistencial donde fue realizada la consulta: AP, AE, OA. •El facultativo responsable de la consulta. La consulta de fecha m´as reciente debe aparecer la primera de la lista; es decir, ordenadas descendentemente. 2.5.3.10. Acci´on ’Acceder a la Actividad Asistencial de una Consulta’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: El usuario puede acceder a las diferentes secciones de la historia cl´ınica (informaci´on del proceso asistencial) que se recoger´an o se recogieron (si la consulta es hist´orica) durante la mencionada consulta. Descripci´on: Una vez localizada la consulta de inter´es en la vista ’Listado de Consultas del Paciente’, el facultativo seleccionar la opci´on ’Ver Historia de la Consulta’. Desde esta vista, el facultativo tendr´a acceso a: 2 de octubre de 2015 26 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS Figura 2.5: Diagrama de Casos de Uso, Subsistema Asistencial, actor ’Facultativo’. •El protocolo cl´ınico, realizado o a realizar, de la consulta en cuesti´on. •El resumen de exploraciones y sintomatolog´ıas observadas del paciente en dicha consulta, si lo hubiere. •El resumen de tests realizados al paciente en dicha consulta y sus scores asociados, si los hubiere. 2.5.3.11. Acci´on ’Registrar Actividad Asistencial de Consulta’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido al proceso asistencial de una consulta determinada, descrito en el apartado 2.5.3.10. Post-Condici´on: Se almacena o actualiza informaci´on cl´ınica asociada a la consulta seleccionada. Descripci´on: El facultativo puede registrar las siguientes exploraciones, prescripciones y/o diagn´osticos del paciente en cuesti´on desde la vista descrita en 2.5.3.10 (Acci´on ’Acceder a la Actividad Asistencial de una Consulta’), enumeradas a continuaci´on por orden alfab´etico: •Diagn´osticos. •H´abitos. •Exploraci´on F´ısica. •Exploraci´on Funcional. •Exploraci´on Neurol´ogica. •Patolog´ıas Intercurrentes. Miguel ´ Angel P´erez del Pino 2.5. MODELO CONCEPTUAL 27 •Prescripci´on Farmacol´ogica. •Solicitud y Resultados de Pruebas Complementarias. •Sintomatolog´ıa Cognitiva. •Sintomatolog´ıa No Cognitiva. 2.5.3.12. Acci´on ’Realizar Exploraci´on’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido al proceso asistencial de una consulta determinada, descrito en el apartado 2.5.3.10. Post-Condici´on: Se realiza, registra y almacena informaci´on relativa a la exploraci´on o sintomatolog´ıa observada por el facultativo para el paciente en cuesti´on en la consulta actual. Descripci´on: El facultativo puede realizar, en funci´on de su nivel asistencial (AP, AE), cualquier exploraci´on de las listadas a continuaci´on, en una consulta determinada (actual o hist´orica), recogiendo sus datos correspondientes: •Exploraci´on F´ısica. •Exploraci´on Funcional. •Exploraci´on Neurol´ogica. •Sintomatolog´ıa Cognitiva. •Sintomatolog´ıa No Cognitiva. 2.5.3.13. Acci´on ’Realizar Test’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido al proceso asistencial de una consulta determinada, descrito en el apartado 2.5.3.10.. Post-Condici´on: Se realiza, registra y almacena informaci´on relativa al test ejecutado por el facultativo para el paciente en cuesti´on en la consulta actual, visualiz´andose el score obtenido. Descripci´on: El facultativo puede realizar, dependiendo de su nivel asistencial (AP, AE), los tests asociados a cada una de las secciones de sintomatolog´ıas yexploraciones mencionadas en el apartado 2.5.3.11 (Acci´on ’Registrar Actividad Asistencial 2 de octubre de 2015 28 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS Figura 2.6: Diagrama de Casos de Uso, Subsistema Asistencial, acciones de exploraci´on para los actores ’Facultativo AP’ y ’Facultativo AE’. de Consulta’). Para ello, tendr´a disponible la operaci´on ’Realizar Test’ + ’Nombre del Test’ (p.e. ’Realizar Test Barthel’) para cada test implementado. 2.5.3.14. Acci´on ’Solicitar Prueba Complementaria’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido al proceso asistencial de una consulta determinada, descrito en el apartado 2.5.3.10. Post-Condici´on: Se realiza solicitud de una nueva prueba complementaria al paciente en la consulta seleccionada. Descripci´on: El facultativo puede solicitar de entre un listado de pruebas complementarias, listadas a continuaci´on en orden alfab´etico: •Bioqu´ımica •Diagn´ostico por Imagen (TAC, MRI, etc.) •Hematolog´ıa •Serolog´ıa y Orina •Resumen de Valoraci´on Facultativa, orientado a los especialistas que han realizado una prueba (radi´ologos, anatom´ıa patol´ogica, laboratorios, etc.), para que puedan expresar su valoraci´on. Adem´as, a efectos de poder registrar consultas hist´oricas, se permite al facultativo indicar una fecha de solicitud y un facultativo responsable diferente a s´ı mismo, si Miguel ´ Angel P´erez del Pino 2.5. MODELO CONCEPTUAL 29 Figura 2.7: Diagrama de Casos de Uso, Subsistema Asistencial, acciones de test para los actores ’Facultativo AP’ y ’Facultativo AE’. fuese necesario. Una vez recibidos los resultados, el facultativo puede rellenar los datos recibidos desde el grid ’Listado de Pruebas Complementarias Pendientes de Resultados’, disponible en la misma vista de solicitud. 2.5.3.15. Acci´on ’Realizar Prescripci´on Farmacol´ogica’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido al proceso asistencial de una consulta determinada, descrito en el apartado 2.5.3.10. Post-Condici´on: Se registra la informaci´on relativa a la farmacolog´ıa prescrita al paciente por el facultativo en la consulta actual. Descripci´on: El facultativo puede prescribir al paciente, de forma sencilla, seleccionando el tipo de f´armaco y especificando su nombre o principio activo y dosis. Igualmente, en la misma vista, el facultativo dispondr´a de los f´armacos previamente recetados al paciente, la consulta donde se le recet´o, qu´e facultativo fue el responsable de dicha receta, y cualquier otra informaci´on relevante para la prescripci´on. 2 de octubre de 2015 30 CAP´ ITULO 2. INGENIER´ IA DE REQUISITOS 2.5.3.16. Acci´on ’Realizar Diagn´ostico Facultativo’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido a la HC de una consulta determinada. Post-Condici´on: Se registra un nuevo diagn´ostico facultativo del paciente para la consulta actual. Descripci´on: El facultativo puede realizar un diagn´ostico facultativo desde la secci´on ’Diagn´ostico’ mencionada en el apartado 2.5.3.11 (Acci´on ’Registrar Actividad Asistencial de Consulta’). Para ello, tendr´a disponible la operaci´on ’Realizar Diagn´ostico Facultativo’ en dicha secci´on. 2.5.3.17. Acci´on ’Solicitar Diagn´ostico Computacional’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber accedido a la HC de una consulta determinada. Post-Condici´on: Se realiza una solicitud de diagn´ostico computacional a un Sistema Inteligente de Ayuda al Diagn´ostico determinado por parte del facultativo. Descripci´on: El facultativo puede solicitar ayuda al diagn´ostico, mediante diagn´ostico computacional, asistido por un Sistema Inteligente de Ayuda al Diagn´ostico, desde la secci´on ’Diagn´ostico’ mencionada en el apartado 2.5.3.11 (Acci´on ’Registrar Actividad Asistencial de Consulta’). En dicha vista, tendr´a disponible una operaci´on ’Solicitar Diagn´ostico Computacional’ diferente para cada tipo de diagn´ostico computacional integrado en el sistema. Los diagn´osticos computacionales que deber´an estar habilitados en la aplicaci´on web para este PFC son los siguientes: •Diagn´ostico Computacional del DCL. •Diagn´ostico Computacional del Nivel de Severidad. •Diagn´ostico Computacional Diferencial de Demencias. 2.5.3.18. Acci´on ’Crear Solicitud de Interconsulta’ Actor/es: Facultativos. Miguel ´ Angel P´erez del Pino 2.5. MODELO CONCEPTUAL 31 Figura 2.8: Diagrama de Casos de Uso, Subsistema de Gesti´on, actor ’Administrador’. Pre-Condici´on: Estar autentificado en el sistema. Post-Condici´on: Se env´ıa una solicitud de interconsulta al facultativo seleccionado. Descripci´on: El facultativo puede solicitar una opini´on experta a otro usuario facultativo autorizado en el sistema. Para ello, dispone de la vista ’Buz´on de Interconsultas’, donde reside la operaci´on ’Crear Solicitud de Interconsulta’, desde donde puede generar la interconsulta especificando: •El facultativo a quien realizar la consulta, que deber´a ser seleccionado de un desplegable que muestre los usuarios facultativos del sistema para f´acil b´usqueda y selecci´on. •El motivo de la interconsulta, en donde deber´a adjuntar aquella informaci´on del paciente a evaluar, y cuantas anotaciones desee transmitir a su colega. 2.5.3.19. Acci´on ’Responder a Solicitud de Interconsulta’ Actor/es: Facultativos. Pre-Condici´on: Estar autentificado en el sistema. Haber recibido una solicitud de interconsulta por parte de otro usuario del sistema. Post-Condici´on: Se responde a la solicitud de interconsulta del facultativo peticionario. Descripci´on: El facultativo puede valorar al paciente y comentarlo con su colega. Para ello, dispone de la vista ’Buz´on de Entrada’ de interconsultas, donde reside la operaci´on ’Responder a Interconsulta’, donde puede incorporar cuantas valoraciones, anotaciones y opiniones desee transmitir a su colega. 2.5.3.20. Acci´on ’Imprimir’ Actor/es: Facultativos. 2 de octubre de 2015 38 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO tratamiento adecuado y una ´optima gesti´on de los recursos sociosanitarios. En el plano investigador, el PCGD ser´a de utilidad a la investigaci´on de demencias, permitiendo analizar y explotar los datos recopilados con el claro objetivo de descubrir nuevo conocimiento. La propuesta de este PFC al respecto es el ’Protocolo Cl´ınico Global de Demencias’ (PCGD), un conjunto detallado de procedimientos y tests cl´ınicos, y criterios diagn´osticos validados por expertos cl´ınicos en los campos de la Geriatr´ıa y la Neurolog´ıa (grupo funcional del proyecto, descrito en el Cap´ıtulo 2) que correlaciona par´ametros cl´ınicos y terap´euticos con ´enfasis en el diagn´ostico de la EA, el DCL y otras demencias [13,14]. El PCGD refleja de manera esquem´atica los datos a recoger, enlazando aquellos par´ametros cl´ınicos y terap´euticos de inter´es para enriquecer el proceso de diagn´ostico. El PCGD lo conforman las mismas entidades que describe el MN en el apartado 2.4 de este trabajo, de manera extendida a los ´ambitos Geri´atrico y Neurol´ogico. En los apartados a continuaci´on, se detalla cada una de las entidades en funci´on de la informaci´on requerida, los instrumentos diagn´osticos cl´ınicos y terap´euticos, y cualquier otra peculiaridad que se considere relevante para diagn´ostico de los mencionados trastornos. 3.2.1. Paciente El PCGD respeta ´ıntegramente lo expresado en el apartado 2.4.1. En l´ınea con ello, se extiende que, en los ´ambitos de Geriatr´ıa y Neurolog´ıa, los datos sociales de un paciente deben incluir, al menos: Nivel de Escolaridad Profesi´on del Paciente Estado Civil Situaci´on Laboral Retribuci´on Salarial Nivel de Institucionalizaci´on 3.2.2. Exploraci´on El PCGD respeta ´ıntegramente lo expresado en el apartado 2.4.4. En l´ınea con ello, se extiende que, en los ´ambitos geri´atrico y neurol´ogico, se define 6 grupos/tipos de exploraciones principales: Exploraci´on Neurol´ogica Miguel ´ Angel P´erez del Pino 3.2. PROTOCOLO CL´ INICO GLOBAL DE DEMENCIAS 39 Exploraci´on Cognitiva Exploraci´on No Cognitiva Exploraci´on Funcional Exploraci´on F´ısica Otras exploraciones 3.2.3. Test El PCGD respeta ´ıntegramente lo expresado en el apartado 2.4.5. En l´ınea con ello, se propone los siguientes 14 tests, organizados en funci´on del tipo de exploraci´on para el diagn´ostico de demencias en los ´ambitos geri´atrico y neurol´ogico: Exploraci´on Funcional •Test de Barthel •Test de Fast •Test de Katz •Test de Lawton-Brody Exploraci´on de Sintomatolog´ıa Cognitiva •Test Informador •Test MEC •Test Minimental •Test de Pfeiffer •Test del Reloj Exploraci´on de Sintomatolog´ıa No Cognitiva •Test Yesavage 4 •Test Yesavage 10 •Test Yesavage 15 •Test Yesavage 30 •Test NPI 2 de octubre de 2015 40 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO 3.2.4. Diagn´ostico El PCGD respeta ´ıntegramente lo expresado en el apartado 2.4.8. En el contexto de este protocolo, un diagn´ostico queda definido por una tupla de dos par´ametros: Tipo de Demencia:Sano,Alzheimer,Vascular,Otras corticales,Otras subcorticales,Mixta oSin identificar. Grado de Deterioro Cognitivo:Sano,Leve,Moderado oSevero. 3.2.5. Resto de Entidades Las entidades Facultativo,Episodio,S´ıntoma,Prueba Complementaria eInterconsulta respetan ´ıntegramente lo expresado en el MN, en la secci´on 2.4. 3.3. Modelo L´ogico de Datos En l´ınea con lo expresado en la introducci´on de este cap´ıtulo, se define ’Modelo de Datos’ como un conjunto de herramientas conceptuales para describir una realidad, conformada por entidades. Cualquiera de las herramientas conceptuales a las que se ha hecho referencia debe proveer de cuatro caracter´ısticas b´asicas: Expresividad, disponiendo de conceptos que reflejen adecuadamente la realidad. Minimalidad, identificando con precisi´on el significado de cada concepto. Simplicidad, permitiendo c´omodo entendimiento y comprensi´on c´omodos. Formalidad, dando una interpretaci´on ´unica, precisa y bien definida a cada concepto. Sin embargo, adem´as de los conceptos, es necesario un detalle preciso de sus relaciones, sus dependencias y de aquellas restricciones de consistencia que provean al esquema de la solidez requerida. De esta manera, se conseguir´a una descripci´on de alto nivel de la realidad a representar. La realidad a representar en este PFC es el PCGD, descrito en el apartado 3.2, bas´andose en el MN general que se analiz´o durante la ingenier´ıa de requisitos extendido al contexto de la EA, el DCL y otras demencias. El estudio de las relaciones existentes entre las diferentes entidades del PCGD ha permitido modelar las necesidades de los profesionales sanitarios en los procesos de registro, b´usqueda, acceso y an´alisis de la informaci´on referente a los pacientes. El Modelo de Datos propuesto es fruto de observar el flujo de trabajo de los usuarios finales y de estudiar relaciones y patrones en la informaci´on que manejan. En la secci´on Miguel ´ Angel P´erez del Pino 3.4. MODELO DE APLICACI´ ON 41 A.1 del ap´endice de esta memoria, se presentan los diagramas de entidad—interrelaci´on realizados durante la fase de dise˜no del modelo. 3.4. Modelo de Aplicaci´on Los m´etodos de ingenier´ıa del software web dirigidos por modelos han mejorado tanto la calidad y la eficiencia a la hora de construir aplicaciones de este tipo. La ventaja m´as destacada de esta aproximaci´on es que a partir de estos modelos, ampliamente validados en entornos industriales, es factible la generaci´on sistem´atica del c´odigo que implementa una aplicaci´on web. En esta secci´on, parte del cap´ıtulo de Dise˜no, se describe lo siguiente: En el apartado 3.4.1, se aborda el patr´on de dise˜no que se utilizar´a para construir la aplicaci´on web que da soporte al subsistema asistencial de EDEVITALZH, descrito en la secci´on 2.5.2 de la Ingenier´ıa de Requisitos. En el apartado 3.4.2, se propone el entorno sobre el cual se desarrollar´a la citada aplicaci´on web, evalu´andose sus bondades. 3.4.1. Patr´on de Dise˜no A efectos de dise˜nar y posteriormente construir la soluci´on EDEVITALZH, se utilizar´a el patr´on de dise˜no MVC (Modelo-Vista-Controlador), que organiza la aplicaci´on a construir en tres partes bien diferenciadas y d´ebilmente acopladas entre s´ı. As´ı, los correctivos, evolutivos, perfectivos e incluso adaptativos que se produzcan en una de las partes tienen m´ınimo impacto sobre las otras. En resumen, el patr´on MVC describe (Fig. 3.1): El Modelo, donde se detalla todo lo relativo al modelo de negocio y a su l´ogica asociada. LaVista, que se encarga de representar el resultado de los procesos de la aplicaci´on. En el caso de las aplicaciones web, est´a intr´ınsecamente relacionado a la interfaz web. El Controlador, que implementa la l´ogica de control de la aplicaci´on. En el flujo de trabajo de MVC, el controlador recibe la orden de entrada y la procesa, utilizando si es preciso, los servicios que el modelo puede proporcionarle para ello. Una vez realizada la operativa anterior, el controlador entrega los datos crudos a la vista, quien 2 de octubre de 2015 42 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO Figura 3.1: Diagrama del patr´on Modelo-Vista-Controlador. se encargar´a de presentarlos adecuadamente. La caracter´ıstica m´as importante de esta soluci´on es que la vista nunca interacciona directamente con el modelo. De manera general, las aplicaciones web se plantean seg´un este patr´on de dise˜no, de forma que el controlador recibe una petici´on HTTP y la procesa; a continuaci´on, haciendo uso del modelo, calcula los datos de salida y los entrega a la vista, que se encarga de construir una respuesta HTTP con las cabeceras adecuadas y un cuerpo, que suele ser c´odigo HTML, XML o JSON. Originalmente, el cliente enviaba una solicitud al controlador (enlace, formulario, etc.) y, tras ser procesada, recib´ıa una respuesta completa (p´agina, fichero, etc.) para ser visualizada en el cliente. Esto significa que la mayor parte de los componentes del patr´on resid´ıa en el servidor: el modelo, el controlador y parte de la vista. En la actualidad, la forma en que est´an distribuidas las funciones entre el cliente y el servidor en el patr´on MVC ha cambiado, permitiendo que ciertas partes del mismo se ejecuten parcial o totalmente en el cliente, motivado principalmente por el desarrollo de la tecnolog´ıa as´ıncrona AJAX. 3.4.2. Plataforma de Desarrollo En el mercado, existe multitud de frameworks y sistemas de gesti´on de contenidos (del ingl´es, Content Management System, CMS) comerciales y de licencia libre, para el desarrollo de aplicaciones web que implementan este patr´on [55]. Entre ellos, cabe destacar Joomla [39], un sistema de gesti´on de contenidos desarrollado sobre PHP siguiendo el modelo MVC [40] que permite construir aplicaciones web din´amicas de manera modular (Fig. 3.2). Joomla es software de c´odigo abierto y se distribuye con licencia p´ublica general GNU (GPL). Miguel ´ Angel P´erez del Pino 3.4. MODELO DE APLICACI´ ON 43 Figura 3.2: Aplicaci´on del patr´on Modelo-Vista-Controlador sobre Joomla, incorporando elementos del modelo de sistemas. De entre sus caracter´ısticas, cabe destacar que permite: Desarrollar aplicaciones web que pueden visualizarse correctamente en diferentes tipos de dispositivos, entre ellos, estaciones de trabajo, m´oviles y tabletas. Un gran nivel de personalizaci´on de la vista, actuando sobre el desarrollo y modificaci´on de ’templates’ o plantillas de visualizaci´on. Desarrollar nuevas extensiones que ampl´ıan la funcionalidad de la plataforma: componentes, m´odulos, plugins, plantillas. Tambi´en se puede disponer de m´as de 8.000 funcionalidades ya desarrolladas y testadas por la comunidad Joomla. Gestionar el sistema desde un subsistema de administraci´on propio, que incorpora todas las funciones necesarias para un correcto control a nivel administrativo: gesti´on de usuarios, grupos, contenidos, componentes, m´odulos, plugins, permisos, etc. El mantenimiento en caliente, permitiendo realizar cambios sin detener el servicio. Los dos motivos principales tenidos en cuenta para la elecci´on de Joomla han sido: Primero, el contar con generadores autom´aticos de formularios, lo cual permitir´a implementar de manera r´apida el PCGD, descrito en la secci´on 3.2, sobre la aplicaci´on web. Segundo, disponer de un entorno de administraci´on estable, testado por miles de usuarios, que respeta las condiciones de seguridad exigidas por este proyecto, y que 2 de octubre de 2015 44 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO aporta las herramientas necesarias para la gesti´on administrativa del mismo. Es decir, implementa el subsistema de gesti´on requerido para EDEVITALZH, de serie. De esta manera, quedar´ıa cubierto el desarrollo de los dos subsistemas de EDEVITALZH mencionados en la secci´on 2.5.2. 3.5. Modelo L´ogico de Sistemas El objetivo de esta secci´on del trabajo es analizar, dise˜nar y proponer el modelo de sistemas que de soporte a los requisitos del proyecto, descritos a lo largo del Cap´ıtulo 2 de esta memoria. De ellos, aquellos requisitos que tienen alg´un impacto sobre la decisi´on del modelo de sistemas de este PFC, se mencionan estructurados en los cuatro grupos a continuaci´on: El primer grupo de requerimientos, referente a la productividad y la escalabilidad del sistema: •La arquitectura propuesta deber´a manifestar una alta productividad, debiendo atender a m´ultiples usuarios de manera simult´anea y en tiempos de respuesta aceptables. •Ante el crecimiento de la demanda de recursos (CPU, memoria f´ısica, memoria de almacenamiento, actividad de red, etc.), habitualmente propiciado por un crecimiento en el volumen de usuarios, la arquitectura propuesta debe tener la posibilidad de crecer en prestaciones de manera transparente al servicio, a fin de mejorar la calidad del mismo. El segundo grupo de requerimientos, referente a c´omo satisfacer los requisitos de desarrollo web para el subsistema asistencial: •El sistema ser´a implementado siguiendo el modelo de aplicaciones web, siendo utilizado por los usuarios exclusivamente mediante un navegador web. •El sistema debe permitir ser utilizado ’en cualquier lugar y en cualquier momento’, a trav´es de la red Internet. •Los datos de la aplicaci´on deber´an estar almacenados en un sistema gestor de bases de datos. El tercer grupo de requerimientos, referente a la integraci´on de Sistemas de Ayuda Inteligente al Diagn´ostico (SIAD): Miguel ´ Angel P´erez del Pino 3.5. MODELO L´ OGICO DE SISTEMAS 45 •El sistema permitir´a a los facultativos realizar solicitudes de ayuda a la toma de decisiones, apoyado por SIAD integrables en la plataforma de manera modular. •El sistema debe atender a m´ultiples usuarios de manera simult´anea y en tiempos de respuesta aceptables. El ´ultimo grupo de requerimientos, referente a las licencias de los productos que dar´an soporte a la plataforma EDEVITALZH: •Las licencias de software de la plataforma y con las que se implemente la aplicaci´on web deben ser lo menos restrictivas posible, preferentemente opt´andose por software de c´odigo abierto. De todo lo anterior, se extrae que: Se necesita un sistema que permita disponer de diferentes servicios y aplicativos. Se necesita un sistema escalable, que permita a˜nadir nuevos recursos si es necesario; por ejemplo, incrementando el n´umero de CPUs, el volumen de almacenamiento y/o mejorando las condiciones de red, entre otros. A fin de gestionar correctamente el uso de los recursos disponibles para atender adecuadamente todas las solicitudes de ayuda al diagn´ostico realizadas por los facultativos, se necesita una pol´ıtica de planificaci´on/ejecuci´on de solicitudes que permita gestionar las solicitudes canalizadas y sus prioridades, y retener aquellas pendientes en tanto en cuanto los recursos necesarios est´en ocupados o no disponibles, atendi´endolas a la mayor brevedad. El sistema debe ser monitorizable, permitiendo conocer su estado, nivel de carga y su capacidad de respuesta en cada momento. En el proceso evolutivo de las Ciencias de la Computaci´on, han surgido diferentes modelos: computaci´on paralela,computaci´on cooperativa,computaci´on vectorial, etc. La soluci´on tradicional que se ha utilizado para la ejecuci´on de aplicaciones cl´ınico-asistenciales ha sido un modelo centralizado de altas prestaciones [27], basado en un servidor central, al que se conectan los usuarios para ejecutar sus aplicaciones. Estas m´aquinas multiprocesador suponen una gran inversi´on econ´omica y adolecen en escalabilidad; adem´as, la mayor parte del tiempo desaprovechan ciclos de reloj, ya que la demanda de potencia suele ser puntual. Una alternativa a este modelo es la computaci´on distribuida, que ofrece un buen ratio coste/prestaciones para la ejecuci´on de aplicaciones en paralelo. De la computaci´on distribuida, es destacable: La posibilidad de compartici´on de recursos f´ısicos y l´ogicos. 2 de octubre de 2015 46 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO Provisi´on de servicios mediante middleware (servidores de aplicaci´on, servidores de bases de datos, buses de mensajes, etc.) F´acil conexi´on de redes locales a Internet mediante routers de bajo coste. Mejoras en la seguridad de la infraestructura mediante ’firewalling’. Optimizaci´on de acceso a Internet mediante cach´es y proxies. F´acil escalabilidad, pudiendo a˜nadir m´as recursos f´ısicos de manera transparente al servicio. Mayor tolerancia a fallos, gracias a la posibilidad de replicaci´on de recursos. Este modelo se ve impulsado por la reducci´on en el precio de estaciones de trabajo, de los servidores de baja gama y de las redes de datos, en especial, de conexi´on a Internet, lo cual incide en menor inversi´on y amplias prestaciones. Una extensi´on al modelo distribuido de computaci´on es la ’planificaci´on de trabajos’ (’job scheduling’). Esta estrategia, com´unmente conocida como ’Computaci´on de Alta Productividad’ (en ingl´es, High Throughput Computing’) (HTC), permite la interconexi´on v´ıa red y el uso de los equipos de una organizaci´on para la ejecuci´on de trabajos secuenciales o paralelos por medio de una herramienta de planificaci´on, despache y control de la carga. Por tanto, permite la ejecuci´on de tareas en los recursos integrados disponibles, para aprovechar los ciclos ociosos de los procesadores. De esta manera, se consigue aumentar la productividad. As´ı mismo, emplea m´as eficientemente los recursos inform´aticos que forman parte del cl´uster y facilita la escalabilidad de la plataforma, al permitir a˜nadir nuevas m´aquinas al sistema de forma sencilla. As´ı pues, el modelo HTC puede ser considerado como un servicio para la compartici´on de potencia computacional y de capacidad de almacenamiento. Dados los requisitos planteados en este PFC, este modelo de computaci´on resulta el m´as ajustado a las necesidades. Los siguientes apartados de esta secci´on del trabajo se estructuran como sigue: El apartado 3.5.1 presenta un an´alisis de las soluciones de HTC estudiadas para este PFC. El apartado 3.5.2 analiza herramientas para la monitorizaci´on de recursos, carga y estado a nivel de m´aquina y a nivel de cl´uster. El apartado 3.5.3 resume el modelo de sistemas propuesto para este PFC. Miguel ´ Angel P´erez del Pino 3.5. MODELO L´ OGICO DE SISTEMAS 47 3.5.1. Evaluaci´on de Soluciones HTC Existe bastante software dedicado a la filosof´ıa HTC como m´etodo de computaci´on, entre ellos productos como Open Grid Engine [59], HTCondor [7] o Nimrod [58]. Sin embargo, la comunidad usuaria de este tipo de tecnologias (especialmente la cient´ıfica) parece decantarse por dos opciones de manera mayoritaria: Open Grid Engine yHTCondor. En los pr´oximos apartados, se realiza un an´alisis de ventajas e inconvenientes de ambos software con la intenci´on de seleccionar de ambos cu´al es el que mejor se adapta a los requisitos de EDEVITALZH. 3.5.1.1. Open Grid Engine Open Grid Engine (OGE) es un software multiplataforma con licencia SISSL (reconocida como gratuita y de c´odigo abierto por la Free Software Foundation y la Open Source Initiative), cuya funci´on principal es la gesti´on de recursos computacionales y/o procesos distribuidos en ambientes heterog´eneos. Originalmente desarrollado por Sun Microsystems y posteriormente continuado por Oracle, desde Diciembre de 2010 se encuentra mantenido por el proyecto ’Open Grid Scheduler’ [59]. Sus caracter´ısticas principales son [61,62]: Gesti´on de conjuntos de trabajos y sus interdependencias. Verificaci´on de env´ıo de trabajos en el lado del cliente y en el lado del servidor. Planificaci´on de trabajos a nivel de nodo. Reserva avanzada de recursos. Control de quota de recursos basada en reglas. Ejecuci´on remota mejorada, sin necesidad de hacer uso de rshd, rlogind o sshd. Capacidad de salvar el estado, interrumpir temporalmente y reiniciar trabajos (job checkpointing), potenciando la tolerancia a fallos. Soporte pty para procesos interactivos. F´acilmente escalable a˜nadiendo nuevas m´aquinas al sistema. Soporte API multilenguaje: C/C++, Java, Perl, Python, Ruby. F´acilmente gestionable mediante interfaz gr´afica sobre X11 (Qmon). Integraci´on con Hadoop y Amazon EC2. ’make’ paralelo (qmake). 2 de octubre de 2015 54 CAP´ ITULO 3. DISE˜ NO Y MODELADO L´ OGICO Figura 3.4: Modelo de Sistemas Propuesto. Miguel ´ Angel P´erez del Pino 55 Cap´ıtulo 4 Implementaci´on 4.1. Introducci´on La insaciable demanda de recursos computacionales para m´ultiples fines (banca, investigaci´on cient´ıfica, medicina, militares, etc.) ha provocado en los ´ultimos 40 a˜nos un crecimiento exponencial en la potencia de c´omputo de nuestros ordenadores. La capacidad de almacenamiento se dobla aproximadamente cada 12 meses; el ancho de banda de las comunicaciones, aproximadamente cada 9. En lo que respecta al rendimiento de los procesadores, ´este se duplica aproximadamente cada 18 meses. La ficticia continuidad de la Ley de Moore [42,43] es pieza clave de este incremento, que involucra al volumen de transistores integrables y en la disminuci´on, tambi´en cada 18 meses, del coste de fabricaci´on. Esta situaci´on propicia una demanda que impulsa el ’crecimiento de necesidades’. Cabe destacar que, en 1971, el procesador 4004 de Intel conten´ıa 2300 transistores, frente a los 5.5 billones de transistores del Intel Xeon Haswell-EP de 18 n´ucleos en 2015 [43]. A modo ilustrativo, la industria de los semiconductores produjo en el a˜no 2004 m´as transistores (y a un costo m´as bajo) que la producci´on mundial de granos de arroz [1]. Al igual que en el resto de disciplinas, en la Medicina Cl´ınica tanto Primaria como Especializada, los sistemas de informaci´on han evolucionado utiliz´andose nuevos paradigmas para su construcci´on. Sin embargo, en las ´ultimas cuatro d´ecadas, el modelo de ejecuci´on de aplicaciones cl´ınico-asistenciales ha sido muy conservador, promoviendo soluciones cliente-servidor de altas prestaciones y gran inversi´on. Durante la segunda mitad de la d´ecada de los 2000 hasta la actualidad, ha irrumpido en el sector el desarrollo de sistemas de informaci´on basados en modelos web. Particularmente en Espa˜na, la migraci´on de sistemas basados en modelo cliente-servidor al nuevo paradigma web se est´a realizando lentamente. Los motivos son variados: 56 CAP´ ITULO 4. IMPLEMENTACI ´ ON Desde el punto de vista econ´omico, se realizaron inversiones durante los primeros a˜nos de la d´ecada de los 2000 en sistemas de informaci´on que a d´ıa de hoy a´un no han sido completamente amortizados. La seguridad de la informaci´on se ha convertido en un aspecto crucial en la actualidad, siendo mucho m´as cr´ıtico este asunto cuando se trata de sistemas de informaci´on cl´ınicos. En aquellos casos en los que la migraci´on se ha llevado o se est´a llevando a cabo, cabe destacar que: •Existe una necesidad de mejorar las redes de comunicaciones y los sistemas que sirven las p´aginas y los datos, lo cual requiere de una inversi´on no s´olo a nivel de clientes (terminales), sino a nivel de centros de proceso de datos. •La formaci´on/adaptaci´on de los usuarios al nuevo modelo resulta ardua, m´as si tenemos en cuenta que el usuario com´un reclama funcionalidades que ten´ıa en su anterior aplicaci´on y ahora se ven truncadas por utilizar la web. La interfaz de usuario se basa en c´odigo XHTML y esto reduce su potencialidad frente a las aplicaciones de escritorio. La adaptaci´on a las nuevas UI, entendidas como aquellas que utilizan iconos y un dispositivo de apunte, habitualmente un teclado, un rat´on o actualmente, el propio dedo, son uno de los causantes de la ralentizaci´on de la implantaci´on de la tecnolog´ıa web en la sanidad. Las UI han sufrido refinamientos constantes a lo largo de los ´ultimos 40 a˜nos; desde la ’Memex’ de Vannevar Bush en 1945 [47] hasta la tecnolog´ıa t´actil de fabricantes como Apple en la d´ecada de 2000. Ha habido grandes consecuciones tecnol´ogicas en este ´ambito, realiz´andose mejoras sustanciales a esta manera de interacci´on, pero lo cierto es que ha habido pocos saltos significativos en el ´area: seguimos utilizando los mismos esquemas organizativos, muchos de ellos basados en c´omo aprende el ser humano en la edad infantil. Douglas Engelbart propuso el concepto de ’Inteligencia Aumentada’ a principios de la d´ecada de los 60, donde hac´ıa menci´on a ’un incremento de las habilidades del hombre para enfrentarse a situaciones complejas, ganar comprensi´on que se ajustase a sus necesidades particulares y derivar soluciones a los problemas’ [19]; un ensayo que iniciaba la investigaci´on de las interfaces, del c´omo mejorar los resultados del humano al utilizar m´aquinas de computaci´on. En su trabajo, Engelbart describ´ıa ’un incremento de las capacidades’ como ’una mezcla de comprensi´on m´as r´apida y mejor; ganar un nivel ´util de comprensi´on en una situaci´on que previamente hab´ıa resultado muy compleja; derivar soluciones m´as r´apidas y mejores, y la posibilidad de encontrar soluciones a los problemas de cient´ıficos, bi´ologos, f´ısicos e ingenieros, sea cual fuere el tiempo de duraci´on de la situaci´on’. Miguel ´ Angel P´erez del Pino 4.1. INTRODUCCI´ ON 57 Diversos autores consideran que es adecuado aprovechar la experiencia del usuario en el manejo de estructuras y procesos que le resulten familiares; es decir, intentar no modificar la forma en la que se ejerce la navegaci´on, para evitar que ´esta afecte a la usabilidad y a la funcionalidad del software. Un caso representativo se plantea a finales del a˜no 2006, cuando Microsoft decidi´o cambiar la UI de su producto ofim´atico, Microsoft Office 2007, e implementar controles basados en ’cinta’. La intenci´on del fabricante no fue otra que mejorar el acceso a las funciones m´as com´unmente utilizadas. Una encuesta realizada online revel´o que un 80 % de los usuarios consultados comentaban que les causaba ’enfado y frustraci´on’ y ’un mayor esfuerzo reflejado en el tiempo, en la formaci´on y en el coste’. Los usuarios expresaron que ’les llevaba mucho tiempo y paciencia aprender a utilizar la nueva herramienta’. En consecuencia, se midi´o la productividad de usuarios expertos en la herramienta anterior utilizando la nueva y se observ´o una p´erdida de rendimiento personal alrededor de un 35 % respecto a la situaci´on anterior. Sin embargo, con la expansi´on de la red Internet, el paradigma de aplicaciones web vuelve a revolucionar la forma en la que se desarrolla el software, y por tanto, la interacci´on humano-m´aquina. Ya no es necesario un cliente espec´ıfico, sino una aplicaci´on determinada: el navegador web. Las ventajas que este modelo de aplicaciones provee tambi´en son sustanciosas: Los costes de instalaci´on y mantenimiento son mucho m´as reducidos. Se puede aprovechar los recursos disponibles pr´acticamente sin inversi´on; basta con disponer de un navegador web. Cualquier plataforma o sistema operativo resulta v´alido. Se ahorra tiempo, puesto que no se requiere la descarga o instalaci´on de software adicional. Las actualizaciones del software, ante nuevos requisitos, cambios o incluso errores en el dise˜no/desarrollo los gestiona el propio desarrollador. Adem´as, se realizan sobre un ´unico lugar, donde se sirven las p´aginas, lo cual minimiza ampliamente los tiempos de instalaci´on de actualizaciones. La ocupaci´on de recursos en los terminales es m´ınima. Gran parte de la l´ogica de negocio se realiza en los servidores, con lo cual el consumo de recursos es bajo. Adem´as, se reducen las necesidades de espacio de almacenamiento, puesto que las p´aginas residen en los servidores, no en los terminales cliente. La disponibilidad puede asegurarse 24x7, teniendo sistemas redundantes para dar calidad al servicio ante una ca´ıda eventual de los recursos principales. Se potencia la colaboraci´on y compartici´on de datos entre los usuarios del servicio. El Sistema Nacional de Salud de Espa˜na apoya este paradigma, disponiendo de m´as de un 40 % de sus hospitales y estando en proceso de implantaci´on otro 30 % comarcales y de 2 de octubre de 2015 58 CAP´ ITULO 4. IMPLEMENTACI ´ ON referencia funcionando mediante sistemas de informaci´on cl´ınicos basados en plataforma web [53]. Si nos centramos en la Comunidad Aut´onoma de Canarias, todos sus hospitales (8 centros, 3 de ellos complejos hospitalarios universitarios de m´as de 1000 camas de hospitalizaci´on) se encuentran informatizados mediante plataforma web [69]. Este cap´ıtulo aborda la construcci´on del sistema EDEVITALZH, estructurado de la siguiente forma: En la secci´on 4.2, se analizan las m´aquinas disponibles para configurar la infraestructura que dar´a soporte al proyecto. En la secci´on 4.3, se describe la instalaci´on y la configuraci´on del cl´uster de Alta Productividad sobre Open Grid Engine. En las secciones 4.4,4.5 y4.6 se detalla la instalaci´on y la configuraci´on de los servidores web, de monitorizaci´on del cl´uster y de base de datos, respectivamente. En la secci´on 4.7, se presenta el modelo f´ısico de datos implementado sobre SQL. En la secci´on 4.8, se aborda la instalaci´on del CMS Joomla, para posteriormente entrar de lleno en el desarrollo de la aplicaci´on web asistencial en la secci´on 4.9. En la secci´on 4.10, se analiza el modelo de integraci´on de datos entre los SIAD y la aplicaci´on web asistencial. Para finalizar, la secci´on 4.11 comenta el testing realizado y c´omo se ha validado la aplicaci´on. 4.2. Instalaci´on y Configuraci´on de M´aquinas Se dispone de un conjunto de 8 m´aquinas para implantar los servicios y aplicaciones que dar´an soporte a la plataforma EDEVITALZH. Todas aquellas m´aquinas en formato ’blade’ han sido enracadas en armario (Fig. 4.1). Para dar cobertura a fallos en la alimentaci´on el´ectrica, se dispone de 2 UPS de 2500VA. La Tabla 4.2 muestra datos b´asicos de las m´aquinas instaladas. Todas las m´aquinas han sido instaladas siguiendo las directrices mostradas a continuaci´on: Sistema Operativo Linux 2.6 (longterm kernel) Distribuci´on Linux CentOS Sistema de Ficheros Base ext4 Miguel ´ Angel P´erez del Pino 4.2. INSTALACI ´ ON Y CONFIGURACI´ ON DE M´ AQUINAS 59 Nombre Tipo M´aquina Arquitectura CPUs Cores CLK (Mhz) amigdala Workstation x86 1 1 3.000 axon Blade 1U x86 2 2 2.800 cortex Blade 3U x86 64 2 8 3.200 hipocampo Blade 2U x86 64 2 8 2.800 mitocondria Workstation x86 2 2 3.200 nucleo Blade 2U x86 64 2 8 2.500 sinapsis Blade 1U x86 64 2 4 2.000 soma Blade 1U x86 2 2 2.800 Tabla 4.1: Lista de M´aquinas del Proyecto EDEVITALZH. Instalaci´on m´ınima de paquetes con soporte de red Sin entorno de ventanas X11 La configuraci´on propuesta pretende reducir el n´umero de servicios en ejecuci´on en las m´aquinas de manera general. Es necesario decidir qu´e servicios y aplicaciones correr´a cada m´aquina en el conjunto del sistema. Dependiendo de las funciones y servicios que se decida otorgar a cada m´aquina, se instalar´a los paquetes necesarios exclusivamente en ese host. El primer criterio evaluado ha sido medir el rendimiento de cada una de las m´aquinas para diferenciar las que tienen una mayor potencia de c´omputo. Aunque habr´ıa sido de inter´es para el autor de esta memoria utilizar como benchmark SPEC CPU2006 [75], debido al coste econ´omico, se decidi´o utilizar LINPACK [31] para medir la potencia de c´omputo. LINPACK describe el rendimiento mediante la resoluci´on de problemas de ecuaciones lineales densas Ax =b, de tres niveles de tama˜no, optimizando por etapas diferentes partes del c´odigo implementado: problemas de 100 ∗100 (optimizaci´on del bucle interno), problemas de 1000 ∗1000 (optimizaci´on de tres bucles; esto es, el programa entero) y un problema paralelo escalable (especialmente dise˜nado para buscar los beneficios de los multiprocesadores). Estas matrices son generadas usando un generador de n´umeros aleatorios, pero forzando los n´umeros para que pueda ejecutarse un pivoteo parcial con eliminaci´on gaussiana. Principalmente, ejecuta dos rutinas b´asicas: una que descompone la matriz y otra que resuelve el sistema de ecuaciones bas´andose en la descomposici´on de la primera matriz. Para una matriz de n∗nelementos, la primera rutina lleva n3operaciones de coma flotante, mientras que la segunda ejecuta n2operaciones de coma flotante. Las rutinas involucradas hacen uso de algoritmos orientados a columnas. Esto es, los programas generalmente referencian a los elementos de los arrays bidimensionales secuencialmente hacia abajo por una columna, en lugar de hacerlo por filas. Esta orientaci´on era importante por la forma en que el lenguaje FORTRAN almacena los arrays. La caracter´ıstica principal de LINPACK es que hace un uso muy intensivo de las operaciones de coma flotante, por 2 de octubre de 2015 60 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.1: Imagen del Rack que almacena las m´aquinas de EDEVITALZH. lo que sus resultados son muy dependientes de la capacidad de la FPU que tenga el sistema. Adem´as, pasa la mayor parte del tiempo ejecutando unas rutinas llamadas BLAS (Basic Linear Algebra Subroutines o Subrutinas de ´ Algebra Lineal B´asica). Dispone de dos tipos de estas bibliotecas (una desarrollada en ensamblador y otra en FORTRAN). Por tanto, el resultado depender´a mucho de cu´al de las dos bibliotecas est´e en ejecuci´on. Someramente, cabe decir que el mayor tiempo de ejecuci´on se consume en la rutina DAXPY de la biblioteca BLAS (casi el 90 %) [32]. DAXPY realiza el siguiente c´alculo: y(i) = y(i) + a∗x(i). Por otra parte, al realizar esencialmente c´alculos con matrices, es un test f´acilmente paralelizable y se puede utilizar para medir la eficiencia de sistemas multiprocesador. Los resultados de la ejecuci´on de LINPACK en cada m´aquina se muestran en la Tabla 4.2. Se puede observar como sistemas de aparente igual constituci´on a nivel de CPU (’nucleo’e’hipocampo’) ofrecen diferente potencia de c´omputo. ’hipocampo’ es una m´aquina dise˜nada y ensamblada espec´ıficamente para mejorar el rendimiento de E/S (orientada al almacenamiento masivo), mientras que ’nucleo’ ofrece mejores prestaciones en la memoria y sus accesos. A partir de los datos obtenidos, se tomaron las siguientes decisiones: Miguel ´ Angel P´erez del Pino 4.2. INSTALACI ´ ON Y CONFIGURACI´ ON DE M´ AQUINAS 61 Nombre Arq. CPUs Cores CLK (Mhz) LNP Kmin LNP Kmax amigdala x86 1 1 2.993 0.2109 1.8682 axon x86 2 2 2.791 0.2535 4.1106 cortex x86 64 2 8 3.191 20.7802 41.241 hipocampo x86 64 2 8 2.660 16.4393 20.2175 mitocondria x86 2 2 3.192 0.0414 3.6816 nucleo x86 64 2 8 2.494 31.2284 70.8108 sinapsis x86 64 2 4 1.994 18.7492 27.8162 soma x86 2 2 2.791 0.2624 4.3343 Tabla 4.2: ´ Indices M´ax y Min. de Ejecuci´on de LINPACK (GFlops) en cada una de las m´aquinas. En lo referente a servicios b´asicos de la l´ogica de red: •Dado su rendimiento medio, configurar ’sinapsis’ como m´aquina administrativa, que implemente el servicio NIS. As´ı, los ficheros maestros group,hosts, netid,passwd,protocols,rpc,services,shadow yypservers deber´an ser modificados siempre desde ’sinapsis’ y propagados mediante la orden ’make’ al resto de m´aquinas. En concreto, es importante destacar el fichero ’/etc/hosts’, que indicar´a las direcciones IP y nombres de las m´aquinas a todos los componentes del cl´uster (Fichero 4.1). Fichero 4.1: Fichero ’/etc/hosts’ del Cl´uster. 1127.0.0.1 localhost localhost 2 3192.168.1.1 router router . comciencia 4192.168.1.2 switch - snmp switch -snmp. comciencia 5192.168.1.3 switch - dell switch -dell. comciencia 6 7192.168.1.10 sinapsis sinapsis . comciencia 8192.168.1.11 sinapsis2 sinapsis2 . comciencia 9 10 192.168.1.12 hipocampo hipocampo . comciencia 11 192.168.1.13 hipocampo hipocampo2 . comciencia 12 192.168.1.14 hipocampo hipocampo3 . comciencia 13 192.168.1.15 hipocampo hipocampo4 . comciencia 14 15 192.168.1.16 axon axon . comciencia 16 192.168.1.17 axon axon2 . comciencia 17 18 192.168.1.18 soma soma . comciencia 2 de octubre de 2015 62 CAP´ ITULO 4. IMPLEMENTACI ´ ON 19 192.168.1.19 soma soma2 . comciencia 20 21 192.168.1.20 nucleo nucleo . comciencia 22 192.168.1.21 nucleo nucleo2 . comciencia 23 24 192.168.1.24 cortex cortex . comciencia 25 192.168.1.25 cortex cortex2 . comciencia 26 27 192.168.1.41 amigdala amigdala . comciencia 28 192.168.1.42 mitocondria mitocondria . comciencia •Dada su fundamento orientado al almacenamiento masivo, ’hipocampo’ prestar´a el servicio NFS. Ser´a en esta m´aquina donde resida el directorio ’home’ de los usuarios y los repositorios de datos que se requiera manejar, entre ellos, el que contiene los fuentes de OGE. Estos directorios se exportar´an v´ıa NFS al resto de m´aquinas donde los usuarios tengan acceso. El fichero 4.2 muestra la configuraci´on de exportaci´on v´ıa NFS desde hipocampo. Fichero 4.2: Fichero ’/etc/exports’ para el servicio NFS. 1/ home 192.168.1.10( rw , sync , no_root_squash ) 192.168.1.11( rw , sync , no_root_squash ) 192.168.1.13( rw , sync,no_root_squash) 192.168.1.14(rw,sync,no_root_squash ) 192.168.1.15( rw ,sync , no_root_squash ) 192.168.1.16( rw , sync,no_root_squash) 192.168.1.17(rw,sync,no_root_squash ) 192.168.1.18( rw ,sync , no_root_squash ) 192.168.1.19( rw , sync,no_root_squash) 192.168.1.20(rw,sync,no_root_squash ) 192.168.1.21( rw ,sync , no_root_squash ) 192.168.1.22( rw , sync,no_root_squash) 192.168.1.23(rw,sync,no_root_squash ) 192.168.1.24( rw ,sync , no_root_squash ) 192.168.1.25( rw , sync,no_root_squash) 192.168.1.41(rw,sync,no_root_squash ) 192.168.1.42(rw,sync,no_root_squash) 2 3/ gridware /sge 192.168.1.10( rw , sync , no_root_squash ) 192.168.1.11( rw , sync , no_root_squash ) 192.168.1.13( rw , sync,no_root_squash) 192.168.1.14(rw,sync,no_root_squash ) 192.168.1.15( rw ,sync , no_root_squash ) 192.168.1.16( rw , sync,no_root_squash) 192.168.1.17(rw,sync,no_root_squash ) 192.168.1.18( rw ,sync , no_root_squash ) 192.168.1.19( rw , sync,no_root_squash) 192.168.1.20(rw,sync,no_root_squash ) 192.168.1.21( rw ,sync , no_root_squash ) 192.168.1.22( rw , sync,no_root_squash) 192.168.1.23(rw,sync,no_root_squash ) 192.168.1.24( rw ,sync , no_root_squash ) 192.168.1.25( rw , Miguel ´ Angel P´erez del Pino 4.2. INSTALACI ´ ON Y CONFIGURACI´ ON DE M´ AQUINAS 63 sync,no_root_squash) 192.168.1.41(rw,sync,no_root_squash ) 192.168.1.42(rw,sync,no_root_squash) 4 5/nfs 192.168.1.10( rw , sync , no_root_squash ) 192.168.1.11( rw , sync , no_root_squash ) 192.168.1.13( rw ,sync , no_root_squash) 192.168.1.14(rw,sync,no_root_squash) 192.168.1.15( rw , sync , no_root_squash ) 192.168.1.16( rw , sync,no_root_squash) 192.168.1.17(rw,sync,no_root_squash ) 192.168.1.18( rw ,sync , no_root_squash ) 192.168.1.19( rw , sync,no_root_squash) 192.168.1.20(rw,sync,no_root_squash ) 192.168.1.21( rw ,sync , no_root_squash ) 192.168.1.22( rw , sync,no_root_squash) 192.168.1.23(rw,sync,no_root_squash ) 192.168.1.24( rw ,sync , no_root_squash ) 192.168.1.25( rw , sync,no_root_squash) 192.168.1.41(rw,sync,no_root_squash ) 192.168.1.42(rw,sync,no_root_squash) •Configurar ’nucleo’ como m´aquina de usuarios, donde se permitir´a el acceso local v´ıa terminal y remoto v´ıa SSH a trav´es del firewall. En lo referente a servicios espec´ıficos para el subsistema asistencial (aplicaci´on web): •Configurar ’sinapsis’ como servidor web, instalando y configurando los paquetes que conforman Apache HTTP Server [2]. •Configurar ’axon’ como instancia de base de datos, instalando y configurando los paquetes que conforman MySQL [56]. •Configurar el router de salida del cl´uster utilizando NAT para dar visibilidad exterior a los puertos 80 (http) contra ’sinapsis’, 443 (https) contra ’sinapsis’ y 3306 (MySQL) contra ’axon’. En lo referente a m´aquinas dedicadas a la gesti´on del cl´uster: •Configurar ’sinapsis’ como host maestro, de env´ıo de trabajos y administrativo (MH, SH, AH). •Configurar ’n´ucleo’ como host autorizado al env´ıo de procesos (SH). 2 de octubre de 2015 70 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.3.5.2. Grupos y Usuarios Se cre´o el grupo ’edevitalzh users’. As´ı mismo, se cre´o al usuario ’edevitalzh’ y se agreg´o a dicho grupo. Este usuario, con permisos b´asicos, puede enviar trabajos al cl´uster a la cola ’edevitalzh.q’. La orden ’qconf -su edevitalzh users’ muestra que se trata de una lista de control de accesos (ACL) y que el´unico usuario autorizado es el usuario ’edevitalzh’, (fichero 4.10). Fichero 4.10: Comprobaci´on Usuarios y Permisos para EDEVITALZH. 1[ iceman@sinapsis ~]$ qconf -su edevitalzh_users 2name edevitalzh_users 3type ACL 4fshare 0 5oticket 0 6entries edevitalzh 4.3.5.3. Comprobaci´on de Estado Se realiza una comprobaci´on de esta de las colas y m´aquinas configuradas en el cl´uster mediante la orden ’qstat -f ’. El resultado obtenido es correcto; se muestra a continuaci´on. Fichero 4.11: Comprobaci´on de Colas y M´aquinas del Cl´uster. 1[ iceman@sinapsis ~]$ qstat -f 2queuename type r/u/t load arch states 3----------------------------------------------------------- 4edevitalzh . q@amigdala BIP 0/0/1 -NA - lx24 - x86 au 5----------------------------------------------------------- 6edevitalzh . q@axon BIP 0/0/1 -NA - lx24 - x86 au 7----------------------------------------------------------- 8edevitalzh . q@cortex BIP 0/0/1 -NA - lx24 - amd64 au 9----------------------------------------------------------- 10 edevitalzh . q@hipocampo BIP 0/0/1 -NA - lx24 - amd64 au 11 ----------------------------------------------------------- 12 edevitalzh . q@mitocondria BIP 0/0/1 2.73 lx24 - x86 13 ----------------------------------------------------------- 14 edevitalzh . q@nucleo BIP 0/0/1 -NA - lx24 - amd64 au 15 ----------------------------------------------------------- 16 edevitalzh . q@soma BIP 0/0/1 -NA - lx24 - x86 au Miguel ´ Angel P´erez del Pino 4.4. INSTALACI ´ ON Y CONFIGURACI´ ON DE APACHE HTTP SERVER 71 4.4. Instalaci´on y Configuraci´on de Apache HTTP Server Para la instalaci´on del servidor web Apache, se ha hecho uso del gestor de paquetes de CentOS, ’yum’. En la m´aquina ’sinapsis’, se ha instalado los siguientes paquetes mediante la orden ’yum install’: httpd-devel.x86 64: Distribuci´on principal de Apache HTTPd. mod ssl.x86 64: M´odulo SSL para Apache HTTPd. Una vez instalados los paquetes y sus dependencias: Se ha editado el fichero de configuraci´on de Apache, localizado en ’/etc/httpd/- conf/httpd.conf ’. El fichero 4.12 muestra las modificaciones realizadas sobre dicho fichero. Fichero 4.12: Comprobaci´on de Colas y M´aquinas del Cl´uster. 1 2ServerName comciencia . dis . ulpgc .es :80 3DocumentRoot "/ var /www/ html " 4 5 6LoadModule php5_module modules / libphp5 . so 7LoadModule php5_module /usr / lib64 / httpd / modules / libphp5 . so 8AddHandler php5 - script php 9 10 11 LoadModule ssl_module modules / mod_ssl . so 12 Listen 443 13 14 <VirtualHost _default_ :443 > 15 DocumentRoot "/ var / www / https " 16 ServerName comciencia . dis . ulpgc .es :443 17 SSLCertificateFile / etc / httpd / conf / edevitalzh . crt 18 </VirtualHost > Se ha creado una p´agina HTML b´asica para probar el servicio. Se guarda con el nombre ’index.html’ en la ruta especificada como DocumentRoot, ’/var/www/html/ ’. 2 de octubre de 2015 72 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.3: Captura de pantalla del navegador accediendo a index.html en el servidor ’sinapsis’. Se ha levantado el servicio mediante la orden ’service httpd start’’, como muestra el fichero 4.13. Se comprueba que el servidor web est´a mostrando p´aginas sin ning´un problema (Fig. 4.3). Fichero 4.13: Inicio del servicio httpd sobre sinapsis. 1[ root@sinapsis ~]# service httpd start 2Iniciando httpd: [Sun Ago 23 12 :35:20 2015] [ OK ] Para verificar el funcionamiento del virtual host https configurado, se ha copiado la p´agina HTML creada anteriormente en la ruta ’/var/www/https/ ’ y se ha modificado el texto que incluye, especificando el motivo SSL para diferenciarla de la no-https. Se comprueba que el servidor web est´a escuchando en el puerto 443, mostrando p´aginas sin ning´un problema (Fig. 4.4). Figura 4.4: Captura de pantalla del navegador accediendo a index.html v´ıa ’https’ en ’sinapsis’. Miguel ´ Angel P´erez del Pino 4.5. INSTALACI ´ ON Y CONFIGURACI´ ON DE GANGLIA 73 Figura 4.5: Capura de Pantalla del Front-End de Ganglia sobre EDEVITALZH. 4.5. Instalaci´on y Configuraci´on de Ganglia La instalaci´on y configuraci´on de Ganglia es muy sencilla. Ofrece gran cantidad de posibilidades de monitorizaci´on y visualizaci´on de las m´aquinas en el cl´uster inspeccionado. En CentOS, resulta de gran utilidad el gestor de paquetes ’yum’, a trav´es del cual se puede instalar los paquetes ganglia,ganglia-gmetad,ganglia-gmond yganglia-gmond-python. Para la instalaci´on del frontend, se debe descargar los fuentes disponibles en [26]. Debe descomprimirse directamente sobre el DocumentRoot del servidor web, es decir, ’/var/www/html’. Dentro de dicho directorio, se ha creado el directorio ’cluster/’. Una vez realizado esto, se comprueba que el servicio es accesible. La figura 4.5 muestra el front-end de Ganglia con datos del cl´uster BRAIN. Para mejorar la visualizaci´on de Ganglia en EDEVITALZH, se realizaron algunas modificaciones sobre el c´odigo de su front-end, entre ellas: Se tradujo al espa˜nol todo el contenido del template original. 2 de octubre de 2015 74 CAP´ ITULO 4. IMPLEMENTACI ´ ON Se modific´o el generador de im´agenes MRTG para que las im´agenes producidas con los datos de la monitorizaci´on tambi´en adaptasen su texto y dimensiones al espa˜nol. Se incorpor´o los logotipos del proyecto, el grupo de investigaci´on COMCIENCIA y la ULPGC en la cabecera de todas las p´aginas generadas por Ganglia. 4.6. Instalaci´on y Configuraci´on de MySQL En la distribuci´on CentOS, utilizada en todas las m´aquinas empleadas en este PFC, MySQL puede ser instalado desde su gestor de paquetes ’yum’. El paquete que se debe instalar es ’mysql-server.x86 64’. El gestor de paquetes se encargar´a de instalar las dependencias necesarias. La m´aquina donde se ha instalado el servidor de bases de datos MySQL es ’axon’. Desde este momento, el servidor MySQL se encuentra instalado. La instalaci´on por defecto no habilita scripts de inicio y parada en el proceso init del servidor Linux. Se requiere que el servicio MySQLd corra sobre la m´aquina con el usuario ’edevitalzh’, puesto que es ´este el usuario autorizado en el cl´uster a enviar trabajos a los SH. Para ello, se editar´a el script de inicio y se agregar´a a la l´ınea donde aparezca el ejecutable ’mysqld’ la siguiente opci´on: ’–user=edevitalzh’. Para ejecutar el servicio, como ’root’ a trav´es de la shell del sistema, se ejecut´o ’chkconfig mysqld on’. El demonio debe iniciarse a mano por primera vez, para evitar reiniciar innecesariamente, mediante la orden ’service mysqld start’. El primer contacto con MySQL no lleva password asociado al usuario ’root’. La orden ’/usr/bin/mysql -u root -p’ permite acceder al prompt de MySQL identificado como administrador, como muestra la captura 4.14. Fichero 4.14: Captura de la toma de contacto con MySQL. 1[ root@axon ~] # mysql -u root -p 2Welcome to the MySQL monitor . Commands end with ; or \g. 3Your MySQL connection id is 102752 4Server version : 5.0.95 Source distribution 5 6Copyright (c) 2000 , 2011 , Oracle and/or its affiliates . All rights reserved. 7 8Oracle is a registered trademark of Oracle Corporation and /or its 9affiliates . Other names may be trademarks of their respective 10 owners. Miguel ´ Angel P´erez del Pino 4.6. INSTALACI ´ ON Y CONFIGURACI´ ON DE MYSQL 75 11 12 Type ’help ;’ or ’\h’ for help . Type ’\c’ to clear the current input statement . 13 14 mysql> El siguiente paso de la configuraci´on es establecer la contrase˜na de administrador. Mediante la orden ’mysqladmin’ se estableci´o la contrase˜na del usuario ’root’ (Captura 4.15). Fichero 4.15: Captura del cambio de contrase˜na del administrador. 1[ root@axon ~] # / usr /bin/ mysqladmin -u root password ’contrasena ’ 2[ root@axon ~] # Se di´o permiso exclusivamente a utilizar el usuario ’root’ desde las direcciones internas de la red de comciencia (’localhost’ y ’axon’) mediante la orden DCL ’GRANT’, evitando que un usuario externo pueda autentificarse como ’root’ (Captura 4.16). Fichero 4.16: Captura del permiso ’host’ del usuario ’root’. 1mysql > select user , password , host from mysql .user; 2+----------+------------+------------------------------------+ 3| User | Host | Password | 4+----------+------------+------------------------------------+ 5| root | localhost | *2470 C0C06DEE42FD1618BDCA2EC9D1E19 | 6| root | axon | *2470 C0C06DEE42FD1618BDCA2EC9D1E19 | 7| root | 127.0.0.1 | *2470 C0C06DEE42FD1618BDCA2EC9D1E19 | 8+----------+------------+------------------------------------+ 93 rows in set (0.00 sec) 10 11 mysql> Una vez el usuario ’root’ fue configurado, se procedi´o a crear la base de datos ’edevitalzh’, esquema donde se albergar´a el modelo f´ısico de datos del sistema (Captura 4.17). Fichero 4.17: Captura de la creaci´on de la base de datos ’edevitalzh’. 1mysql > create database edevitalzh ; 2Query OK , 1 row affected (0.01 sec) 3 4mysql > show databases ; 5+--------------------+ 6| Database | 2 de octubre de 2015 76 CAP´ ITULO 4. IMPLEMENTACI ´ ON 7+--------------------+ 8| information_schema | 9| edevitalzh | 10 | mysql | 11 +--------------------+ 12 3 rows in set (0.00 sec) Posteriormente, se cre´o el usuario de base de datos ’edevitalzh’, al que se dio privilegios DML de SELECT, INSERT y UPDATE sobre el esquema ’edevitalzh’ en l´ınea con los requisitos de seguridad. La captura 4.18 muestra esta ´ultima operaci´on. Fichero 4.18: Creaci´on y permisos del usuario ’edevitalzh’. 1mysql > create user ’edevitalzh ’@’ %’ identified by ’password -edev ’; 2Query OK , 0 rows affected (0.03 sec) 3 4mysql > grant all privileges on edevitalzh .* to edevitalzh ; 5Query OK , 0 rows affected (0.00 sec) A partir de este instante, la base de datos est´a preparada para construir en ella el modelo de datos. Para ello, se utilizar´a la herramienta libre de gesti´on de datos Toad for MySQL [77], que permite trabajar desde interfaz gr´afica con SQL directamente contra la base de datos. 4.7. Desarrollo del Modelo F´ısico de Datos El Modelo F´ısico de Datos de EDEVITALZH corresponde a la implementaci´on en SQL del PCGD, descrito funcionalmente en la secci´on 3.2 de esta memoria. Su implantaci´on permitir´a la aceleraci´on, y la automatizaci´on en algunos casos, de los procesos de tratamiento de informaci´on cl´ınica por parte de los facultativos en los ´ambitos de la Neurolog´ıa y la Geriatr´ıa. La recopilaci´on unificada de informaci´on en un mismo entorno que correlaciona los datos de manera cl´ınico-asistencial va a potenciar la investigaci´on m´edica, y por ende el descubrimiento de nuevo conocimiento, mejorando as´ı en corto espacio temporal la fiabilidad de los diagn´osticos de la EA, el DCL y otras demencias. En el Ap´endice A, se describen extensamente el dise˜no y la implementaci´on del modelo de datos sobre MySQL, conforme a la siguiente estructura: En la secci´on A.1, se presenta el conjunto de diagramas de entidad—interrelaci´on representativos del modelo. Miguel ´ Angel P´erez del Pino 4.8. INSTALACI ´ ON Y CONFIGURACI´ ON DE JOOMLA 77 En la secci´on A.2, se detalla la implementaci´on del modelo de datos en lenguaje SQL. En la secci´on A.3, se especifican los diagramas de relaci´on tras la implementaci´on SQL. Para finalizar, en las secciones A.4,A.5 yA.6, se lista el conjunto de tablas, claves y vistas de datos implementadas sobre el esquema de base de datos resutante, ’edevitalzh’. 4.8. Instalaci´on y Configuraci´on de Joomla La instalaci´on de Joomla es de f´acil realizaci´on. La versi´on de producto instalada ha sido la 2.5, por ser la versi´on estable y con mayor soporte en el momento de la implantaci´on para este PFC. Para instalar Joomla, se requiere un servidor web Apache con soporte PHP5 y un servidor MySQL v5. Ambos requisitos se cumplen, pues han sido instalados conforme a lo descrito en las secciones 4.4 y4.6 de esta memoria. El procedimiento de instalaci´on seguido se detalla a continuaci´on: Inicialmente, se ha descargado los fuentes de Joomla disponibles en [41]. Se trata de un fichero Zip de 7.6 MB de tama˜no. Se ha creado el directorio ’edevitalzh’ sobre el DocumentRoot del virtual host configurado; es decir, el directorio ra´ız de Joomla ser´a ’/var/www/https/edevitalzh/ ’. Se ha descomprimido los fuentes sobre el directorio ra´ız de Joomla. Para proceder con la instalaci´on, es necesario tener a mano los siguientes par´ametros: •Host que alberga la base de datos. Para desacoplar las direcciones internas, se utilizar´a la direcci´on IP p´ublica ’193.145.147.13 ’, cuyo puerto 3306 (MySQL) est´a vinculado a trav´es de NAT al mismo puerto en la m´aquina ’axon’, que ejecuta el MySQL instalado en la secci´on 4.6. •Usuario y contrase˜na de base de datos. La instalaci´on debe hacerse con un usuario con permisos administradores, por lo que se utilizar´a el ’root’ de la base de datos. •Nombre para el esquema de la base de datos de Joomla, que ser´a ’joomla25’. Llegados a este punto, desde el navegador, se accedi´o a la URL de Joomla a trav´es del servidor web. El instalador de Joomla consta de 7 pasos: 2 de octubre de 2015 78 CAP´ ITULO 4. IMPLEMENTACI ´ ON •Primero, se selecciona el idioma que se usar´a durante la instalaci´on (Fig. 4.6). Figura 4.6: Paso 1 de la instalaci´on de Joomla. •Segundo, Joomla realiza una serie de comprobaciones previas a proceder con la instalaci´on; condiciones que se cumplen para el caso de este PFC (Fig. 4.7). Figura 4.7: Paso 2 de la instalaci´on de Joomla. •Tercero, Joomla muestra su licencia y la aceptaci´on de la misma si se contin´ua en el proceso (Fig. 4.8). Miguel ´ Angel P´erez del Pino 4.8. INSTALACI ´ ON Y CONFIGURACI´ ON DE JOOMLA 79 Figura 4.8: Paso 3 de la instalaci´on de Joomla. •Cuarto, Joomla solicita la configuraci´on para la base de datos (Fig. 4.9). Figura 4.9: Paso 4 de la instalaci´on de Joomla. •Quinto, Joomla solicita la configuraci´on para utilizar FTP (Fig. 4.10). Este caso est´a orientado a hosting y no es necesario en este PFC. Se omite y se contin´ua el proceso. 2 de octubre de 2015 86 CAP´ ITULO 4. IMPLEMENTACI ´ ON un m´etodo organizativo curioso: s´olo se muestra la informaci´on contenida en la pesta˜na actual, ocult´andose el resto al usuario hasta su solicitud. El usuario solicita claridad en la pantalla, en su espacio de trabajo, y una de las propuestas m´as demandadas es la desaparici´on del exceso de botones. Si se tiene en cuenta que este tipo de aplicaciones son dedicadas a la recopilaci´on de datos y a su posterior b´usqueda/an´alisis, los botones resultan un componente de poca utilidad, sustituible por hiperv´ınculos que ejecuten las funciones necesarias y ocupen menos espacio visual. El usuario desea un aspecto visual es mucho m´as abierto; obs´ervese la saturaci´on de datos de Selene Clinic (Fig. 4.15). En definitiva, el usuario no quiere aglomeraci´on de informaci´on en su espacio de trabajo digital. La propuesta de este PFC es un UI ligero, que emule al papel (al folio cl´ınico), y que contenga exclusivamente aquello que es relevante seg´un el PCGD. El diagrama 4.16 muestra la organziaci´on de la pantalla y su fundamento. Se propone dividir la pantalla en dos zonas visuales: la primera, de aproximadamente un 60 % de la pantalla, comenzando de izquierda a derecha, que alberga el ´ Area de Trabajo Principal (ATP); la segunda, una zona m´as reducida, del 40 % que est´a situada a la derecha. En la zona superior, se identifica una barra de botones o pesta˜nas, acompa˜nadas por el logo de la aplicaci´on, que debe ser muy escueto y sencillo. No debe distraer la atenci´on hacia ´el. En el ATP, se implementar´a ’un folio’; un ´area vertical con fondo blanco bien diferenciado, sobre el cual trabajar´a el usuario. En este ´area, se incorporar´a, verticalmente desde arriba hacia abajo, lo siguiente: •Una zona donde se identifique al paciente actual, su episodio / consulta, y la fecha de la consulta (enfocado al trabajo sobre hist´oricos), identificado como 1 en nuestro diagrama de UI (Fig 4.16). •A continuaci´on, una franja de reducido espacio que permita al usuario identificar ’d´onde est´a trabajando’, identificado como 2en nuestro diagrama de UI (Fig 4.16). Se indicar´a en qu´e secci´on de la aplicaci´on o p´agina se encuentra. •Seguidamente, se incorporar´a con un men´u de iconos atractivos, identificado como 3en nuestro diagrama de UI (Fig 4.16), donde se hayan las operaciones que el usuario puede llevar a cabo desde esa p´agina o secci´on de la aplicaci´on. Debe ir sobre el fondo blanco del ’folio’, es parte de ´el. Son ’las herramientas de trabajo’. •Debajo, surge el espacio ’real’ de trabajo, donde realmente habr´a que enfocar al usuario a centrarse y navegar. Para iniciarle en el camino, se le puede mostrar Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 87 un resumen que pueda darle una visi´on del paciente en ese ´ambito (identificado como 4en nuestro diagrama de UI (Fig 4.16)) y, justo a continuaci´on, en el ´ Area de Recogida y Visualizaci´on de Datos (ARVD), identificado como 5el diagrama, se incorporar´an tablas, formularios y cualquier otro instrumento inform´atico que pueda ser de utilidad. En el ´area derecha de la pantalla, que abarcar´a un 40 %, se podr´an incorporar componentes con una intenci´on de alerta y/o notificaci´on, o herramientas que deban ser comunes para toda la aplicaci´on pero ’sin ser parte expl´ıcita del paciente y de la consulta’. Por ejemplo, visualizar las interconsultas que se demandan o la medicaci´on espec´ıfica de un paciente, pueden ser componentes aptos para ser implementados en este ´area visual. Para la implementaci´on del UI, se ha utilizado el framework JA T3 de JoomlArt [37], que permite la r´apida personalizaci´on de la vista generando las correspondientes hojas de estilo CSS. Este framework tiene como ventaja el potente c´odigo CSS que genera para ser reutilizado: sensible a todos los navegadores. Es un c´odigo muy bien estructurado y comentado, que permite una r´apida lectura y adaptaci´on a las necesidades de la aplicaci´on a desarrollar. 4.9.2. Componentes Utilizados Para el desarrollo, se ha utilizado los componentes de Joomla listados a continuaci´on: GridJX: Este componente representa tablas en pantalla a partir de los datos provenientes de una fuente de datos integrada (conjunto CSV,conjunto JSON,consulta SQL, etc.), a partir de los cuales muestra las correspondientes columnas y, como filas, el conjunto de datos aportado. Resulta muy vers´atil y r´apido, entre otros motivos, por su uso de AJAX para los eventos de visualizaci´on de la tabla. GridX se utiliza en la aplicaci´on web para representar informaci´on tabulada: la b´usqueda de pacientes,la b´usqueda de consultas oel listado de tests realizados a un paciente, entre otros. A nivel de base de datos, para cada p´agina donde se utilice el componente, se ha dise˜nado e implementado una vista de datos. Se ha implementado un total de 39 vistas de datos, (listadas en el Ap´endice A, secci´on A.6). Las capturas 4.19 y4.20 muestran a modo de ejemplo las vistas de datos para la explotaci´on de episodios cl´ınicos del paciente y tests realizados en un episodio concreto, respectivamente. Fichero 4.19: Vista de Episodios Cl´ınicos del Paciente. 2 de octubre de 2015 88 CAP´ ITULO 4. IMPLEMENTACI ´ ON 1CREATE ALGORITHM =‘ edevitalzhv1 ‘ DEFINER =‘ edevitalzh ‘@‘ %‘ SQL SECURITY DEFINER VIEW ‘VIEW_EDV_CONSULTAS ‘ AS 2select 3‘a‘.‘ medicalrecord ‘ AS ‘MEDICALRECORD ‘, 4‘a‘.‘id ‘ AS ‘ID ‘, 5‘act ‘.‘ code ‘ AS ‘TIPO_CONSULTA ‘, 6date_format (‘a ‘. ‘ creation_date ‘, 7_latin1 ’ %d/ %m/ %Y’) AS ‘FECHA ‘, 8concat (‘p ‘.‘ name ‘, 9concat ( _utf8 ’ ’ ,‘p ‘. ‘ surname ‘) ) AS ‘ FACULTATIVO ‘, 10 ‘a‘.‘ finished ‘ AS ‘CERRADA ‘, 11 _latin1 ’Ver Historia Consulta ’ AS ‘DETALLES ‘, 12 concat ( _latin1 ’? AACC =’,concat (‘a ‘. ‘id ‘, concat ( _latin1 ’& s_f = AACC ’, concat ( _latin1 ’& MEDICALRECORD = ’,concat (‘a ‘.‘ medicalrecord ‘, concat ( _latin1 ’& data_search = ’, concat (‘a ‘.‘id ‘, _latin1 ’& aso = exact ’))))))) AS ‘URL ‘ 13 from 14 ((‘ aacc ‘ ‘a‘ join ‘physicians ‘ ‘p ‘) join ‘activity_type ‘ ‘act ‘) 15 where 16 ((‘a‘.‘id_physician ‘ = ‘p‘.‘id_physician ‘) 17 and (‘a ‘.‘ id_activity_type ‘ = ‘act ‘.‘id ‘)) 18 order by 19 ‘a‘.‘creation_date ‘; Fichero 4.20: Vista de Tests por Episodio Cl´ınico. 1CREATE ALGORITHM =‘ edevitalzhv1 ‘ DEFINER =‘ edevitalzh ‘@‘ %‘ SQL SECURITY DEFINER VIEW ‘RESUMEN_AACC_TESTS ‘ AS 2select 3‘pat ‘.‘ medicalrecord ‘ AS ‘ MEDICALRECORD ‘, 4‘pat ‘.‘ id_aacc ‘ AS ‘AACC ‘, 5date_format (‘a ‘.‘ creation_date ‘, _latin1 ’ %d/ %m/ %Y’) AS ‘ FECHA‘, 6‘pat ‘.‘id ‘ AS ‘ID_TEST ‘, 7‘et ‘.‘ description ‘ AS ‘ TIPO_EXPLORACION ‘, 8‘t‘.‘ description ‘ AS ‘TEST ‘, 9‘pat ‘.‘ score ‘ AS ‘SCORE ‘ 10 from 11 (((‘ patient_aacc_tests ‘ ‘pat ‘ join ‘tests ‘ ‘t ‘) join ‘ exploration_type ‘ ‘et ‘) join ‘aacc ‘ ‘a ‘) 12 where Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 89 13 ((‘ pat ‘.‘ id_type ‘ = ‘et ‘. ‘id ‘) 14 and (‘t ‘.‘ id_type ‘ = ‘et ‘. ‘id ‘) 15 and (‘pat ‘.‘ id_test_type ‘ = ‘t ‘. ‘id ‘) 16 and (‘pat ‘.‘ id_aacc ‘ = ‘a ‘. ‘id ‘)) 17 order by 18 ‘pat ‘.‘ id_aacc ‘, 19 ‘et ‘.‘ description ‘, 20 ‘t‘.‘ description ‘; RSForms, en su versi´on gratuita. RSForms permite dise˜nar formularios ricos en componentes de manera gr´afica. Los componentes que requiera el formulario, escogidos por el programador, conformar´an la vista. RSForms extiende las funcionalidades del controlador gen´erico de Joomla (JController) gracias a la programaci´on en PHP de las operaciones pre-carga y post-env´ıo sobre el mismo componente. Esto permite al programador potenciar las funciones de tratamiento y preparaci´on de los datos de manera espec´ıfica a los formularios desarrollados y al modelo. En cuanto al modelo, la implementaci´on de las operaciones DML se realizan utilizando la clase JDatabase. En general, si la aplicaci´on a desarrollar requiere de gran n´umero de conexiones a bases de datos, la conexi´on suele realizarse de modo persistente. No es el caso de EDEVITALZH. En cada acceso a una p´agina, se establecer´a una conexi´on puntual de base de datos que extraer´a los datos y los pasar´a al controlador, que los tratar´a y preparar´a para llamar a la vista y mostrarlos al usuario, o procesarlos para entregarlos al modelo. Para enviar las consultas SQL pertinentes al servidor de bases de datos, la clase JDatabase de Joomla proporciona el m´etodo setQuery(). Las capturas 4.21 y4.22 muestran operaciones contra la base de datos de EDEVITALZH utilizando JDatabase (conexi´on y SELECT sobre una vista de datos). Fichero 4.21: Conexi´on a Base de Datos. 1// PARAMETROS DE BASE DE DATOS 2// ARRAY $OPTION 3// 4$option = array (); // Prevenimos problemas ... 5$option [’driver ’] = ’mysql ’; // Driver de BD 6$option [’host ’] = ’192.168.1.16 ’; // Hostde BD 7$option [’user ’] = ’edevitalzh ’; // Usuario 8$option [’password ’] = ’********** ’; // Password 9$option [’database ’] = ’edevitalzh ’; // Esquema de BD 10 $option [’prefix ’] = ’’; // Prefijo de BD 2 de octubre de 2015 90 CAP´ ITULO 4. IMPLEMENTACI ´ ON 11 12 // CONEXION A SERVIDOR 13 // 14 $db = & JDatabase :: getInstance ( $option ); 15 $jAp = JFactory :: getApplication (); Fichero 4.22: SELECT sobre una Vista de Datos. 1$myQuery = " SELECT \* FROM VIEW_EDV \ _EDITAR \ _PACIENTE WHERE medicalrecord = " . $myvar ; 2$db -\> setQuery ( $myQuery ) or die ("NO SE PUDO EJECUTAR LA QUERY ") ; 3$patient = $db -\> loadAssoc () ; 4 5 6// MANEJO DE CASOS NULOS , QUE NO DEBERIAN SURGIR 7// 8if ( is_null ( $posts =$db -\> loadRowList ())) { $jAp -\ > enqueueMessage ( nl2br ($db -\ > getErrorMsg () ),’ error ’); return ;} 9 10 return $patient ; Plotalot: Se trata de una extensi´on gratuita que permite, a partir de un array de datos resultado de una consulta SQL, representar diferentes tipos de gr´aficas en pantalla. Utiliza Google Visualization API e incorpora diversas opciones que lo hacen de f´acil implantaci´on sobre el entorno web. Este componente ofrece potencialidad para explotar informaci´on gr´aficamente. Plotalot ha sido utilizado para representar gr´aficas sobre EDEVITALZH como la mostrada en la Fig. 4.17, correspondiente a la evoluci´on del DCL de un paciente. 4.9.3. Navegaci´on La navegabilidad define el flujo de comunicaci´on entre las p´aginas que componen una aplicaci´on web. La forma de enlazar las p´aginas est´a intr´ınsecamente relacionada con los casos de uso, sus inclusiones y sus extensiones. En los pr´oximos apartados, se realiza un recorrido por el conjunto de p´aginas que conforman el subsistema asistencial de EDEVITALZH, vinculando las operaciones que cada una de ellas permite con los respectivos casos de uso que fueron especificados a lo largo de la fase de ingenier´ıa de requisitos. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 91 Figura 4.17: Gr´afica del Seguimiento del DCL de un paciente utilizando Plotalot. 4.9.3.1. P´agina de Inicio Figura 4.18: P´agina: Inicio. En esta p´agina de inicio (Fig. 4.18), el p´ublico en general visualiza en la ATP una marquesina de im´agenes que van cambiando, mostrando im´agenes relacionadas con la EA, el DCL y otras demencias. Un usuario puede iniciar sesi´on utilizando su login y su contrase˜na. Si sus credenciales son v´alidas, podr´a acceder a la B´usqueda de Pacientes. En caso contrario, no podr´a acceder y continuar´a en la zona exterior de la aplicaci´on. 2 de octubre de 2015 92 CAP´ ITULO 4. IMPLEMENTACI ´ ON Se implementa en esta p´agina el caso de uso 2.5.3.1. 4.9.3.2. B´usqueda de Pacientes Figura 4.19: P´agina: B´usqueda de Pacientes. Una vez autentificado, el usuario se encuentra en su ´area de trabajo (Fig. 4.19). Lo primero que se le muestra es la B´usqueda de Pacientes, que le permite buscar a un paciente por cualquiera de los campos sociodemogr´aficos identificativos. Tambi´en puede ver y/o actualizar los datos sociodemogr´aficos del pacientes (en el grid, columna ’PACIENTE’, pulsando en ’M´as Datos...’) o acceder a su historia cl´ınica desde la columna ’HIST. CLINICA’, pulsando en Ver Historia sobre el paciente deseado. En la zona flotante de la derecha, dispone de dos elementos. El primero, el que le identifica como facultativo del sistema y le permite cerrar la sesi´on. El segundo, el Buz´on de Interconsultas, donde puede ver las interconsultas que le han solicitado, las que ha cursado y, como no, crear una nueva solicitud de interconsulta a un colega. Se implementa en esta p´agina los casos de uso 2.5.3.2,2.5.3.3,2.5.3.5,2.5.3.7,2.5.3.18 y2.5.3.19. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 93 4.9.3.3. Ver o Editar Datos del Paciente Figura 4.20: P´agina: Ver o Editar Datos Demogr´aficos del Paciente. A trav´es de esta p´agina (Fig. 4.20), el facultativo puede ver´ıntegramente todos los datos demogr´aficos del paciente, y si lo desea, puede modificar todos a excepci´on del N´umero de Historia Cl´ınica, que es autogenerado por el sistema mediante una secuencia en base de datos. Si no desea hacer nada, puede optar por buscar otro paciente, registrar uno nuevo, realizar una solicitud de interconsulta o cerrar la sesi´on. En caso de querer modificar alg´un dato, deber´a pulsar el bot´on verde ’Actualizar Datos del Paciente’, mostrado en la Fig. 4.21. Se implementa en esta p´agina los casos de uso 2.5.3.5 y2.5.3.6. Figura 4.21: P´agina: Ver o Editar Datos Demogr´aficos del Paciente (II). 2 de octubre de 2015 94 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.4. Registrar Nuevo Paciente Figura 4.22: P´agina: Registrar Nuevo Paciente. Esta p´agina incorpora un formulario para a˜nadir nuevos pacientes a la base de datos (Fig. 4.22). Es un formulario simple, que recopila los datos demogr´aficos del paciente. Los campos identificados con el identificativo lateral al campo (**) son obligatorios y ser´an autocomprobados con AJAX antes de que el usuario pulse el bot´on, se˜nalando en rojo aquellos que deben ser revisados. El NHC ser´a asignado autom´aticamente por la aplicaci´on y no ser´a modificable. Se implementa en esta p´agina el caso de uso 2.5.3.4. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 95 4.9.3.5. Actividad Asistencial del Paciente Figura 4.23: P´agina: Historia Cl´ınica — Actividad Asistencial del Paciente. La Actividad Asistencial del Paciente muestra los siguientes componentes: Primero, la identificaci´on del paciente y su NHC. A continuaci´on, se encuentra el men´u de iconos para navegar por la historia cl´ınica, de manera global. En este componente, se puede acceder a (Fig. 4.23): Crear una Nueva Consulta al paciente ante una nueva visita o una visita hist´orica que se quiere registrar a posteriori. El Informe de la Sintomatolog´ıa Cognitiva de la historia del paciente. El Informe de la Sintomatolog´ıa No Cognitiva de la historia del paciente. El Informe de la Exploraci´on Funcional de la historia del paciente. El Informe de las Pruebas Complementarias realizadas a lo largo de la historia del paciente. El Informe de los Diagn´osticos realizados al paciente a lo largo de su historia. El Informe de los H´abitos del paciente. El Informe de las Patolog´ıas Intercurrentes del paciente. El Informe de Prescripci´on Farmacol´ogica del paciente. 2 de octubre de 2015 102 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.31: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test Minimental. Figura 4.32: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test MEC. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 103 Figura 4.33: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test Pfeiffer. Figura 4.34: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa Cognitiva — Test del Reloj. 2 de octubre de 2015 104 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.9. Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva Figura 4.35: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva. La p´agina de exploraci´on de Sintomatolog´ıa No Cognitiva (Fig. 4.35) implementa un formulario basado en comboboxes con los s´ıntomas relativos a anomal´ıas no cognitivas habituales. Adem´as, aporta la posibilidad de realizar los tests de este tipo de exploraciones, tal y como se describe en 3.2: Yesavage 4 (Fig. 4.36) Yesavage 10 (Fig. 4.37) Yesavage 15 (Fig. 4.38) Yesavage 30 (Fig. 4.39) NPI (Fig. 4.40) Se implementa en esta p´agina el caso de uso 2.5.3.12 y se vincula con la extensi´on del caso de uso 2.5.3.13 para los tests de la Sintomatolog´ıa No Cognitiva. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 105 Figura 4.36: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 4. Figura 4.37: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 10. 2 de octubre de 2015 106 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.38: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 15. Figura 4.39: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test Yesavage 30. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 107 Figura 4.40: P´agina: Protocolo Cl´ınico — Sintomatolog´ıa No Cognitiva — Test NPI. 2 de octubre de 2015 108 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.10. Protocolo Cl´ınico — Exploraci´on Funcional Figura 4.41: P´agina: Protocolo Cl´ınico — Exploraci´on Funcional. La p´agina de Exploraci´on Funcional (Fig. 4.41) incorpora los 4 tests implementados seg´un las especificaciones del PCGD descritas en la secci´on 3.2: Barthel (Fig. 4.42) Fast (Fig. 4.43) Katz (Fig. 4.44) Lawton-Brody (Fig. 4.45) Se implementa en esta p´agina el caso de uso 2.5.3.12 y se vincula con la extensi´on del caso de uso 2.5.3.13 para los tests de la Exploraci´on Funcional. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 109 Figura 4.42: P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Barthel. Figura 4.43: P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Fast. 2 de octubre de 2015 110 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.44: P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test Katz. Figura 4.45: P´agina: Protocolo Cl´ınico — Exploraci´on Funcional — Test de Lawton-Brody. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 111 4.9.3.11. Protocolo Cl´ınico — Exploraci´on Neurol´ogica Figura 4.46: P´agina: Protocolo Cl´ınico — Exploraci´on Neurol´ogica. La p´agina de Exploraci´on Neurol´ogica (Fig. 4.46) implementa un formulario basado en comboboxes con el listado de s´ıntomas relacionados con anomal´ıas neurol´ogicas habituales, recogidos en el PCGD. Se implementa en esta p´agina el caso de uso 2.5.3.12 2 de octubre de 2015 118 CAP´ ITULO 4. IMPLEMENTACI ´ ON Figura 4.53: P´agina: Protocolo Cl´ınico — Pruebas Complementarias (III). Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 119 4.9.3.16. Protocolo Cl´ınico — Prescripci´on Farmacol´ogica Figura 4.54: P´agina: Protocolo Cl´ınico — Prescripci´on Farmacol´ogica del Paciente. Esta p´agina implementa el formulario de receta farmacol´ogica del paciente, (Fig. 4.54). Est´a formado por un combobox, contenedor de los grupos medicamentosos disponibles para la terapia asociada a demencias, y un textbox para incorporar el principio activo recetado y la dosis. Esta p´agina, adem´as, muestra el hist´orico de recetas realizadas al paciente, con su facultativo responsable, cu´ando se realiz´o dicha prescripci´on, el f´armaco y su dosis. Se implementa en esta p´agina el caso de uso 2.5.3.11. 2 de octubre de 2015 120 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.17. Protocolo Cl´ınico — Diagn´ostico Figura 4.55: P´agina: Protocolo Cl´ınico — Diagn´osticos del Paciente. La p´agina de Diagn´osticos tiene la siguiente estructura (Figs. 4.55 y4.56): Dispone de un componente de iconos, desde donde se puede realizar y/o solicitar ayuda al diagn´ostico. A continuaci´on, en color vainilla, muestra un resumen de los diagn´osticos realizados por facultativos al paciente y muestra sus valoraciones. Seguidamente, en color verde, muestra el resumen de solicitudes de ayuda al diagn´ostico cuyos resultados ya han llegado al sistema desde los SIAD. Para finalizar, en color rojo, muestra el resumen de solicitudes inteligentes de ayuda al diagn´ostico realizadas pero pendientes de recibir su resultado desde los SIAD. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 121 Figura 4.56: P´agina: Protocolo Cl´ınico — Diagn´osticos del Paciente. Se implementa en esta p´agina v´ınculos al caso de uso 2.5.3.16 y a las extensiones del caso de uso 2.5.3.17 para cada SIAD integrado. 2 de octubre de 2015 122 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.18. Diagn´ostico — Diagn´ostico Facultativo Figura 4.57: P´agina: Diagn´ostico — Diagn´ostico Facultativo. La p´agina de Diagn´ostico Facultativo implementa las funciones necesarias para que el profesional sanitario pueda valorar a su paciente y registrarlo en la historia cl´ınica de ´este. Esta p´agina implementa un formulario con 3 campos, de los cuales dos son obligatorios: el nivel de DCL y el tipo de demencia valorada, (Fig. 4.57). El tercer campo permite al facultativo hacer anotaciones cortas en cuanto a su diagn´ostico. Se implementa en esta p´agina el caso de uso 2.5.3.16. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 123 4.9.3.19. Diagn´ostico — Solicitud de Ayuda al Diagn´ostico Figura 4.58: P´agina: Diagn´ostico — Diagn´ostico Facultativo. La p´agina de Solicitud de Ayuda al Diagn´ostico implementa las funciones necesarias para que el profesional sanitario pueda realizar una petici´on de ayuda al diagn´ostico a un SIAD. Esta p´agina implementa un formulario dependiente de la definici´on del vector de entrada de cada SIAD. En el caso representado en la figura. 4.58, el formulario consta de 3 campos que se cargar´an autom´aticamente de la base de datos. En caso de no haberse registrado los datos necesarios, el sistema alertar´a al usuario para que los rellene antes de continuar. Una vez se solicita el diagn´ostico, el sistema pondr´a en ejecuci´on el SIAD correspondiente siguiendo los procedimientos implementados durante la integraci´on con los SIAD y que se describen en la secci´on 4.10 de esta memoria. Se implementa en esta p´agina el caso de uso extendido 2.5.3.17 para cada SIAD integrado en EDEVITALZH. 2 de octubre de 2015 124 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.9.3.20. Interconsulta — Solicitud Figura 4.59: P´agina: Interconsulta — Solicitud. Esta p´agina, accesible desde cualquier punto de la aplicaci´on, permite la solicitud de valoraci´on de un paciente a un colega. Funcionando como el m´etodo IC en papel, se seleccionar´a el facultativo de destino y se le especificar´a aquello que se considere de inter´es para que el receptor de la interconsulta disponga de la informaci´on precisa, (Fig. 4.59). Se implementa en esta p´agina el caso de uso 2.5.3.18. Miguel ´ Angel P´erez del Pino 4.9. DESARROLLO DE LA APLICACI´ ON WEB 125 4.9.3.21. Interconsulta — Respuesta Figura 4.60: P´agina: Interconsulta — Recepci´on. Esta p´agina implementa el Buz´on de Interconsultas (Fig. 4.60), donde se almacenan y gestionan las interconsultas recibidas y respondidas por el facultativo. Dispone de una interfaz similar al de un sistema de mensajer´ıa. Se implementa en esta p´agina el caso de uso 2.5.3.19. 2 de octubre de 2015 126 CAP´ ITULO 4. IMPLEMENTACI ´ ON 4.10. Integraci´on de los SIAD Para realizar la integraci´on de cualquier SIAD con EDEVITALZH, se debe tomar en consideraci´on que: En EDEVITALZH, cada SIAD tendr´a un identificador ´unico con el que ser´a referenciado (id diagnoser). Cada SIAD dispone ´unicamente de visibilidad de sus diagn´osticos (WHERE id diagnoser = Z) mediante una vista en base de datos, que le permite realizar exclusivamente operaciones de SELECT y UPDATE. Cada SIAD tiene asociado un usuario de base de datos (’SIAD’ + id diagnoser), ´unicamente con permisos de SELECT y UPDATE sobre su vista de datos, mencionada previamente. Esto minimiza las posibilidades de error e incrementa los criterios de seguridad frente a la posibilidad de modificar e inyectar datos no autorizados desde un SIAD hacia otro. Los datos de inter´es de la HCE del paciente para efectuar el diagn´ostico computacional ser´an extra´ıdos y codificados por un procedimiento almacenado en Base de Datos, que ser´a ejecutado para un paciente concreto en una consulta concreta. Estos datos ser´an empaquetados en un fichero XML, que tendr´a la siguiente estructura, (Fichero 4.23): •La cabecera propia de fichero XML. •Una etiqueta ra´ız, ’diagnosis’, que contendr´a los par´ametros de inter´es estructurados en: ◦’medicalrecord’, compuesto por los campos ’nhc’ (N´umero de Historia Cl´ınica del paciente) y ’aacc’ (identificador de la consulta a evaluar). ◦’ddata’, que especificar´a los datos requeridos por el SIAD en cuesti´on para realizar el diagn´ostico computacional (p.e. el score de un test determinado, el nivel de escolaridad, la edad del paciente, etc.). Fichero 4.23: Entrada para Diagn´ostico Computacional. 1<? xml version =" 1.0 " encoding =" utf -8"?> 2<diagnosis > 3<! -- ID PACIENTE Y CONSULTA EN EDEVITALZH --> 4<medicalrecord > 5<nhc >265 </nhc > 6<aacc >371 </aacc > 7</ medicalrecord > Miguel ´ Angel P´erez del Pino 4.10. INTEGRACI´ ON DE LOS SIAD 127 Figura 4.61: Diagrama de Alto Nivel de Integraci´on de un SIAD gen´erico en EDEVITALZH. 8 9<! -- DATOS PARA EL DIAGNOSTICO COMPUTACIONAL --> 10 <ddata > 11 <scholarship >4</ scholarship > 12 <mec >65</ mec > 13 <barthel >60</ barthel > 14 </ ddata > 15 </ diagnosis > Ante una solicitud de ayuda al diagn´ostico, se realizan 2 acciones: •La primera, preparar y tratar los datos del paciente necesarios para exportarlos al formato XML requerido. Este fichero se almacenar´a en la ruta del SIAD. •La segunda, ante la inserci´on en la tabla ’diagnosis’ del registro de solicitud de diagn´ostico, realizado despu´es de haberse generado el fichero XML, un trigger que aprovecha la bondad de MySQL UDF, lanzar´a a ejecuci´on en el cl´uster el batch del SIAD (mediante la orden ’qsub’) con sus ficheros asociados (input, config, etc.). Una vez disponibles todos los recursos necesarios, el cl´uster pasar´a a ejecuci´on el SIAD y ´este devolver´a su valoraci´on. Debe incorporarse al ejecutable de la RNA dos capas (integrables preferiblemente en un batch) (Fig. 4.61): 2 de octubre de 2015