implantación de openmrs para el cuidado de la hipertensión
TRANSCRIPT
Trabajo de Final de Grado:
Implantación de OpenMRS para el cuidado de
la hipertensión en Hospital de Gambo, Etiopía
Hectór Luís Rodríguez
Director: Carme Martin
Especialización: Sistemas de Información
2017-2018
Agradecimientos
Gracias a Carme Martin Escofet por ser mi tutora, dedicada y con atención y
guiarme desde el principio del desarrollo hasta el final del proyecto.
Gracias al grupo BLOPUP por permitirme ser parte de este proyecto, por la
labor que estáis haciendo y por la amabilidad con la que siempre me habéis
tratado.
Gracias a Montse Garcia Alzina que siempre ha estado dispuesta a echarme
una mano delante cualquier dificultad que tuviera, aun estando ocupada con
la nueva incorporación a la familia.
Gracias a Federico por tener paciencia y enseñarme en los inicios del
proyecto.
Gracias a mi familia, por su apoyo incondicional, en los buenos y malos
momentos. Si ellos no seria quien soy ahora.
Finalmente dar gracias a la comunidad de OpenMRS por la labor humanitaria
que hace el día a día, muchas personas ahora disponen de atención
sanitaria gracias a su trabajo.
Índice
Introducción............................................................................................................................9
1.Contexto............................................................................................................................10
1.1 Hipertensión.................................................................................................................10
1.2 Situación sanitaria en Etiopía, y el deseo del cliente...................................................10
1.3 OpenMRS.....................................................................................................................13
1.4 Actores..........................................................................................................................15
1. 5 Estado del Arte............................................................................................................17
1.5.1 Estudio de mercado............................................................................................17
1.5.2 Solución Escogida...............................................................................................18
1.6 Problema y Alcance......................................................................................................20
1.7 Metodología y Herramientas........................................................................................21
1.8 Sistema de validación..................................................................................................23
1.9 Posibles Obstáculos.....................................................................................................24
2. Plan de Proyecto..............................................................................................................25
2.1 Planificación y Programación Inicial.............................................................................25
2.2 Descripción de Procesos.............................................................................................25
2.2.1 Familiarizar-se con el entorno OpenMRS...........................................................25
2.2.2 Configuración de OpenMRS acorde al proyecto................................................26
2.2.3 Implementación de funcionalidades especificas.................................................28
2.2.4 Plan de Mantenimiento y documentación...........................................................28
2.3 Equipamiento y Herramientas......................................................................................29
2.4 Estimación del tiempo..................................................................................................30
2.5 Diagrama de Gantt.......................................................................................................31
2.6 Plan de control y acción...............................................................................................32
3. Costes..............................................................................................................................34
3.1 Coste de Recursos Humanos......................................................................................34
3.2 Costes del Hardware....................................................................................................36
3.3 Costes del software......................................................................................................37
3.4 Costes Indirectos..........................................................................................................38
3.5 Fondo para Imprevistos................................................................................................38
3.6 Coste Total del Proyecto..............................................................................................39
3.7 Plan de control y acción...............................................................................................39
4. Desviaciones de la Planificación.....................................................................................41
4.1 Actualización de Descripción de Tareas.......................................................................41
4.1.1 Familiarizar-se con el entorno OpenMRS y Android...........................................42
4.1.2 Mejorar asistencia sanitaria offline......................................................................42
4.1.3 Automatizar la toma de datos..............................................................................43
4.1.4 Añadir atributos...................................................................................................43
4.1.5 Búsqueda de pacientes por Localidad................................................................43
4.1.6 Generar aviso de tratamiento..............................................................................43
4.1.7 Redistribución de la Aplicación...........................................................................44
4.1.8 Documentación...................................................................................................44
4.2 Costes de la Desviación...............................................................................................45
5. Sostenibilidad...................................................................................................................46
5.1 Sostenibilidad Ambiental..............................................................................................46
5.2 Sostenibilidad Económica............................................................................................47
5.3 Sostenibilidad Social....................................................................................................48
6. Estructura de OpenMRS..................................................................................................49
7. Elección de la distribución Reference Application y OpenMRS Android Client...............53
8. Arquitectura de OpenMRS Android Client.......................................................................56
8.1 Capa de Android:..........................................................................................................57
8.2 Capa de Servicios:.......................................................................................................58
8.3 Capa de Datos:............................................................................................................60
9. Objetivos y Especificación...............................................................................................62
10. Identificación de Formularios.........................................................................................66
11. Configuración de OpenMRS..........................................................................................73
11.1 Creación/Modificación de Usuarios............................................................................74
11.2 Creación de Localizaciones.......................................................................................76
11.3 Creación de Conceptos..............................................................................................78
11.4 Creación de Tipos de Encuentro................................................................................80
11.5 Creación de Formularios............................................................................................82
12. Distribución de pantallas................................................................................................93
13. Casos de uso.................................................................................................................94
13.1 Casos de uso para la asistencia sanitaria sin red:....................................................94
13.2 Casos de uso para automatizar la toma de datos:..................................................106
13.3 Casos de uso para Añadir Atributos de Paciente:....................................................110
13.4 Casos de uso para Buscar Paciente por Localidad:................................................113
13.5 Casos de uso para generar un aviso de tratamiento:..............................................115
14. Implementación............................................................................................................116
14.1 Implementación de la asistencia sanitaria sin red:..................................................116
14.2 Implementación toma de datos automatizada:........................................................128
14.3 Implementación de Atributos de Paciente:...............................................................131
14.4 Implementación de Buscar Paciente por Localidad:................................................134
14.5 Implementar aviso de tratamiento:...........................................................................136
15. Integración de Conocimientos.....................................................................................137
16. Justificación de las Competencias Técnicas...............................................................138
17. Leyes y Regulaciones..................................................................................................139
Conclusiones y opinión personal.......................................................................................141
Referencias........................................................................................................................143
Bibliografía.........................................................................................................................146
Índice de Tablas
Tabla 1: Horas estimadas por etapa....................................................................................30
Tabla 2: costes recursos humanos......................................................................................34
Tabla 3: Horas por Etapa.....................................................................................................35
Tabla 4: coste del hardware.................................................................................................36
Tabla 5: costes del software.................................................................................................37
Tabla 6: costes indirectos.....................................................................................................38
Tabla 7: Fondo para Imprevistos..........................................................................................38
Tabla 8: Coste Total del Proyecto........................................................................................39
Tabla 9: Fondo para Imprevistos..........................................................................................39
Tabla 10: Horas Estimadas por Etapa de la desviación......................................................44
Tabla 11: matriz de sostenibilidad........................................................................................46
Índice de Figuras
Figura 1: Implementaciones de OpenMRS por África.........................................................14
Figura 2: Diagrama de Gantt...............................................................................................31
Figura 3: Diagrama de Gantt Después de la desviación.....................................................45
Figura 4: Arquitectura General Android Client.....................................................................56
Figura 5: Capa de Android...................................................................................................57
Figura 6: Capa de Servicios.................................................................................................59
Figura 7: Capa de Datos......................................................................................................60
Figura 8: Esquema Entidad-Relacion de la Base de Datos................................................61
Figura 9: Esquema del Funcionamiento de la Aplicación....................................................65
Figura 10: Formulario con datos de registro estándar.........................................................66
Figura 11: Formulario de registro con datos especiales......................................................67
Figura 12: Formulario de Antecedentes...............................................................................68
Figura 13: Formulario de Control Vital.................................................................................69
Figura 14: Formulario de Factores de Riesgo.....................................................................70
Figura 15: Informe de Seguimiento.....................................................................................71
Figura 16: Pantalla de Administración Avanzada................................................................73
Figura 17: Administración de Usuarios................................................................................74
Figura 18: Pantalla Agregar/Modificar Usuario....................................................................75
Figura 19: Pantalla de inició de sesión................................................................................76
Figura 20: Pantalla de Administración de Localidad............................................................77
Figura 21: Pantalla de Creación de Localidad.....................................................................77
Figura 22: Pantalla de Mantenimiento del Diccionario de Conceptos.................................78
Figura 23: Pantalla de Creación/Modificación de Concepto...............................................79
Figura 24: Pantalla de Administración de Tipos de Encuentro............................................80
Figura 25: Pantalla de Creación de Tipo de Encuentro.......................................................81
Figura 26: Pantalla de Administración de Formularios........................................................82
Figura 27: Pantalla de Creación de Formularios.................................................................83
Figura 28: Estructura de un formulario JSON......................................................................85
Figura 29: Campos de entrada de selección (selection y radio).........................................87
Figura 30: Atributo answers.................................................................................................88
Figura 31: Rendering de Entrada Libre (text, numeric con intervalo y sin intervalo)..........89
Figura 32: Guardar JSON de un Formulario........................................................................90
Figura 33: Diseño de la implementación de la respuesta de texto......................................91
Figura 34: Implementación del método createAndAttachTextQuestionEditText.................92
Figura 35: Diseño de Descargar Pacientes.........................................................................96
Figura 36: Diseño de Sincronizar Paciente.........................................................................98
Figura 37: Diseño de Listar Encuentros............................................................................100
Figura 38: Diseño de Ver Encuentro..................................................................................102
Figura 39: Diseño Ver Informe...........................................................................................104
Figura 40: Diseño de GPS.................................................................................................108
Figura 41: Diseño Ver Atributos Especiales del Paciente..................................................114
Figura 42: Diseño de Buscar Paciente..............................................................................115
Figura 43: LastViewedPatientsRecycleViewAdapter downloadPatient.............................120
Figura 44: visitAPI syncBPUPEncounters.........................................................................121
Figura 45: RestApi getEncounters.....................................................................................121
Figura 46: EncounterDAO syncBPUPEncounters.............................................................123
Figura 47: PatientDashboardPresenter synchronizaPatient.............................................124
Figura 48: PatientDashboardEncountersPresenter subscribe()........................................125
Figura 49: Patient getEncountercreates............................................................................126
Figura 50: EncounterDAO findEncountersByPatientID.....................................................127
Figura 51: PatientsEncounterRecycleViewAdapter onBindViewHolder............................128
Figura 52: FormViewPresenter setAdapter.......................................................................129
Figura 53: EncounterData class.........................................................................................132
Figura 54: PatientChartsFragment populateList................................................................133
Figura 55: EncounterMethods interfaz...............................................................................134
Figura 56: ObservationMethods interfaz............................................................................134
Figura 57: GPS Listeners...................................................................................................135
Figura 58: FormDisplayPageFragment Inicialización Gps................................................136
Figura 59: FormDisplayPageFragment updateBMI...........................................................138
Figura 60: PatientStaticEncounterPresenter loadLastEncounterFromDB........................139
Figura 61: PatientStaticEncounterFragment showStaticEncounter..................................140
Figura 62: PatientStaticEncounterPresenter getLatestEncountercreate...........................140
Figura 63: EncounterDAO getStaticFormEncounter1.......................................................141
Figura 64: RestAPI getPatientsByCity...............................................................................142
Figura 65: LastViewedPatientsPresenter findPatiens.......................................................143
Figura 66: FormDisplayPageFragment notifyTreatment...................................................144
Introducción
La utilización de un registro médico electrónico (EMR) en países
desarrollados ha resultado ser una herramienta importante para ofrecer
una mayor calidad en el cuidado de la salud. Permiten ofrecer una mejor
calidad en el diagnostico y tratamiento, reducen los fallos médicos y
mejoran las investigaciones [1][2]. La experiencia en uso de sistemas
EMR de países en desarrollo es limitada, pero si que existe un interés
considerable en sistemas de información médicos para dar soporte a
tratamientos de enfermedades específicas [3].
El trabajo de final de grado presentado a continuación consiste en la
implantación de un software de sistema de registros médicos en
OpenMRS realizado para el hospital de Gambo, Etiopía con el fin de
mejorar el diagnostico y control de la hipertensión1 de la población de los
alrededores.
1 Presión excesivamente alta de la sangre sobre la pared de las arterias.
9
1.Contexto
1.1 Hipertensión
La hipertensión es un problema creciente que afecta a nivel mundial. Se
estima que 1 billón de personas sufre de presión sanguínea alta, y de estos,
más de 9 millones derivan en muerte. La hipertensión es la causa de por lo
menos el 45% de las muertes por cardiopatías, y el 51% de las muertes por
accidente cerebro-vascular. Según la Organización Mundial de la Salud (OMS)
es la principal causa de morbilidad y mortalidad en el mundo [4]. En 2008, se
habían diagnosticado de hipertensión aproximadamente el 40% de los adultos
mayores de 25 años, el número de personas afectadas aumentó de 600
millones a 1000 millones entre 1980 y 2008, y sigue creciendo. El mayor
numero de casos de hipertensión se registra en la Región de África, con un
46% de los adultos mayores de 25 años afectados por la patología. Se ha
detectado que en países de ingresos considerados bajos, la enfermedad es
más prevalente y común. La hipertensión a menudo es asintomática, medios de
diagnóstico básicos para la hipertensión incluyen dispositivos que permitan
medir con precisión la tensión arterial como un tensiómetro [5]. La OMS
recomienda que para reducir las afectaciones por esta enfermedad se deben
crear programas integrados de control de la hipertensión en la esfera de la
atención primaria. En la mayoría de los países, este es el nivel más débil del
sistema de salud [6].
1.2 Situación sanitaria en Etiopía, y el deseo del cliente
Etiopía es uno de los países de África que cuenta con una de las situaciones
sanitarias más precarias del mundo. La salud en Etiopía es pobre, incluso
cuando se compara con otros países con pocos recursos económicos, incluidos
10
los del África subsahariana [7]. Es un país que depende fuertemente del sector
agrario, que constituye el 40% de su PIB. Addis Abeba la capital, hoy en día es
una ciudad moderna, con acceso a infraestructuras, el PIB crece a un ritmo de
más del 10% anual y se ha multiplicado casi por ocho, pasando de 7.350
millones de euros en el año 2000 a 54.860 millones en 2015. Sin embargo, el
39% de la población etíope sobrevive con menos de 1,90 dólares al día y está
entre los 20 países más pobres del mundo según el Banco Mundial. Hay una
fuerte centralización de los servicios y la cobertura sanitaria no es una
excepción. Al salir de la capital cuando nos adentramos en la Etiopía rural, la
realidad es mucho más cruda [8], hay muchas personas sin acceso a sanidad,
escolarización, y agua potable. En el ultimo censo del 2015 se estima que tiene
una población de 99.391.000 habitantes [7], de los cuales el 80% siguen
viviendo en zonas rurales según el estudio del data world bank en 2016 [9]. El
gobierno Etíope ya ha tomado medidas para descentralizar la sanidad como el
Programa de Extensión Sanitaria, que se ha llevado uno de los mayores
aplausos de la comunidad internacional [8].
La investigación llevada a cabo por el cliente presenta un paradigma, en los
últimos años ha habido un gran avance en el tratamiento de cardiopatias. Este
avance es responsable de prolongar la media de vida 6 años, pero se esta
haciendo a un precio insostenible y más en el tercer mundo. La hipótesis del
cliente, cita que con una mejor motorización de la hipertensión y un tratamiento
temprano se puede reducir el numero de afectaciones de la enfermedad a un
precio mucho más sostenible. Como se ha mencionado anteriormente la
hipertensión es la mayor causa de cardiopatias, y esta, en la gran mayoría de
casos no presenta síntomas, de ahí el nombre “asesina silenciosa”. Según
investigaciones del cliente, esta demostrado que normalizando los números de
la presión arterial, sin tener en cuenta los valores iniciales anteriores a un
tratamiento, produce un descenso en mortalidad cardiovascular. Actualmente el
daño vascular se relaciona con las figuras de presión arterial y los años de
11
desarrollo, y no con el registro clínico. En los últimos años organizaciones
como WHO y MDGs han hecho énfasis en enfermedades infecciosas, y han
dejado de lado la hipertensión. Esto crea que haya poca concienciación de la
patología y poca adherencia al tratamiento. El cliente propone un modelo
sostenible para el cuidado de la salud que ofrece una solución ante la lucha
contra la hipertensión en países pobres. La propuesta se basara en una prueba
realizada en Etiopia apoyada de un sistema telemático.
La petición del cliente es implantar un sistema de registro medico
(OpenMRS) para dar soporte a esta iniciativa en el hospital rural de Gambo, y
mejorar el tratamiento de la hipertensión mediante una mayor concienciación
de la población y una mayor adherencia al tratamiento. El proyecto nace con la
cooperación del cliente y Joan Pere Riu profesor de la UPC. El hospital de
Gambo es un centro sanitario de 150 camas de la Iglesia Católica Etíope. Se
encuentra en la provincia de West-Arsi, a 245 Kms. al sudeste de la capital del
país, Addis Abeba, y a 18 Kms. de la ciudad más cercana a través de una pista
forestal. La ubicación del Hospital General Rural de Gambo contribuye a
disminuir en cierto modo la centralización sanitaria que sufre Etiopía, lo cual
permite salvar un mayor número de vidas en el medio rural. Gran parte de la
población de estas zonas no puede permitirse el desplazamiento a las grandes
urbes por falta de medios y, además, el mal estado de las carreteras impide
que la asistencia sanitaria llegue a tiempo [10]. Por otra parte el cliente
pretende utilizar los datos recogidos por la plataforma para realizar
investigaciones sobre la hipertensión.
12
1.3 OpenMRS
OpenMRS es una plataforma software y una aplicación de referencia libre
que permite diseñar sistemas de registro médico sin la necesidad de
conocimientos de programación, aunque si requiere conocimiento medico y de
análisis de sistemas. Se basa en una arquitectura cliente servidor, que consta
de una aplicación web y/o una aplicación móvil para android y Iphone, ambas
funcionan sobre Java y spring framework. Tiene un diccionario de conceptos
como modelo de datos, que consta de una API para ayudar a desarrolladores a
programar de manera más sencilla. La comunidad de OpenMRS ha creado
más de 100 módulos que extienden la funcionalidad base del sistema. Para
poner una distribución de OpenMRS en marcha se necesita una base de datos
relacional sql, independientemente de cual sea mysql, posgreSQL… y un
servidor apache como tomcat.
Más que un software, OpenMRS es la colaboración que surge para dar
soporte a los programas de sanidad en países en desarrollo donde
enfermedades como la malaria, el VIH y la tuberculosis entre otras causan
estragos en la población. Estos programas por falta de recursos acaban
gestionando su información en documentos de papel, o bases de datos mal
diseñadas lo que se traduce en mayores esfuerzos para peores resultados.
OpenMRS pretende dar las herramientas de gestión para mejorar la la atención
sanitaria.
OpenMRS comenzó en una sola clínica en el oeste de Kenia hace 10 años.
Desde entonces se ha convertido en una solución de TI de salud global con
implementaciones en más de 80 países y traducciones en múltiples idiomas.
Basado en informes documentados, OpenMRS está actualmente en uso en
1.845 ubicaciones en todo el mundo. Los proveedores locales de servicios de
13
salud han aprovechado OpenMRS para mejorar la atención médica para más
de 6,3 millones de pacientes [11].
OpenMRS debe su origen a la colaboración de (BWM & PGB) que en su
trabajo como consultores en 2004 se les pidió escalar un sistema basado en
Acces en Kenia. Su respuesta fue crear AMPATH Medical Record System
(AMRS). Un año más tarde trabajando con AMRS en colaboración con
Regenstrief Institute y Partners In Health (PIH), vieron que sus enfoques en
modelos de datos eran similares. Decidieron embarcarse en un proyecto y
crear una fundación para juntar esfuerzos y así incentivar más colaboración en
países en desarrollo. El nombre del proyecto se conoce hoy como OpenMRS
[12].
14
Figura 1: Implementaciones de OpenMRS por África
1.4 Actores
• Desarrollador: En este caso yo mismo, seré el responsable de
implementar, documentar y cumplir con los objetivos del trabajo antes de una
fecha final de entrega. Contaré con el apoyo del director para que me guie
durante la realización de este.
• Director del trabajo: Carme Martin Escofet del departamento de
ingeniería de servicios y sistemas de información de la UPC, sera la
responsable de llevar el seguimiento de mi trabajo. Sera quién me ayude a
evitar que cometa errores en cuanto a la planificación y ejecución del trabajo, y
a quien acudiré cuando necesite consejo.
• Cliente: Persona que ha pedido el sistema de registro médico
electrónico. Es quien se ha encargado de transmitir los requisitos que debe
cumplir y las funcionalidades que ha de tener el sistema.
• Pos-desarrolladora: Va a ser la persona que tome la continuidad del
proyecto una vez haya pasado la fecha final de entrega y servirá de ayuda al
desarrollador si a este le aparece alguna duda.
• Director del Proyecto: El trabajo que se trata en este documento
formara parte de un proyecto que engloba más aspectos. El encargado de
llevar este proyecto y su director es Pere Joan Riu del departamento de
electrónica en la Universidad Politécnica de Catalunya. También es el mediador
entre el cliente y el desarrollador, el es quien me comunicara las necesidades
del cliente y quien conseguirá financiación para el trabajo.
15
• Usuarios: Los operarios del hospital que utilizaran el sistema como
apoyo del trabajo que realizan diariamente, consiguiendo así dar una mejor
cobertura sanitaria.
• Grupo BLOPUP: La colaboración de personas que participan en el
proyecto. Entre ellas se encuentra el director.
• Beneficiarios: Consideramos que los habitantes de la zonas
involucradas que reciban una mejor cobertura sanitaria como beneficiarios. Por
otra parte todo sale de una idea solidaria, este proyecto podrá ser compartido
para llevar a cabo fines similares. También habrá personas que les interese la
información que guarde el sistema y que la podrá utilizar para llevar a cabo
investigaciones.
16
1. 5 Estado del Arte
1.5.1 Estudio de mercado
Aunque el cliente haya pedido explícitamente que el sistema debe estar
basado en OpenMRS, es recomendable analizar las alternativas por si se
puede proponer una solución más adecuada. Existen cientos de sistemas de
información sanitarios MRS en el mercado, teniendo en cuenta las necesidades
del proyecto, vamos a filtrarlos por aquellos que sean de código abierto y
gratuitos, estén basados en web y que dispongan de aplicación móvil.
• vistA: Creado por los estados unidos para ofrecer un mejor
cuidado a sus veteranos ahora es de código abierto. vistA es el MRS
más completo del mercado. Es una herramienta multiplataforma que
busca aumentar la eficiencia clínica y adaptación del sistema
sanitario imperante. Tiene un gran potencial en su capacidad de
almacenar la información de la Historia Clínica Electrónica de los
pacientes. Aunque al ser antiguo mantener el sistema es difícil, y la
interfaz esta muy cargada y es poco intuitiva. [13]
• openEMR: Es una herramienta basada en web para la
administración de práctica médica, registro de historias clínicas,
prescripciones médicas y facturación. Es una de las aplicaciones de
Gestión de Registros Médicos Electrónicos (historias clínicas) de
software libre con más uso tanto en países desarrollados como en
vías de desarrollo. Es parecida en muchos sentidos a OpenMRS,
pero tiene una interfaz de usuario más antigua y la aplicación móvil
esta en modo beta. [14]
17
• One Touch EMR: Ofrece una versión lite gratuita, es un software
que ofrece sus servicios desde la nube, incluye prescripción
electrónica, integración de laboratorio y una herramienta de dibujo
para hacer anotaciones. Desde la aplicación móvil se pueden añadir
fotos, tiene una interfaz muy amigable y esta muy bien documentado
para implementadores. La pega es que necesitas conexión a la red
para acceder al sistema. [15]
• Software a medida: La principal ventaja de un software a medida
es que se adapta perfectamente a las necesidades del proyecto. Por
contrapartida es la opción más cara, tanto a nivel monetario como
temporal.
1.5.2 Solución Escogida
Después del análisis de mercado coincidimos con el cliente. Las
motivos de la elección son los siguiente:
• Es de software libre, por lo que no tiene ningún coste asociado a la
licencia.
• OpenMRS es muy flexible pudiendo adaptarse y cubrir las
necesidades del proyecto. Su arquitectura basada en módulos
permite la creación de nuevas funcionalidades. En
wiki.openMRS.org hay un listado de los módulos creados por la
comunidad, así como una guiá para crearlos. Tiene módulos que nos
son de utilidad como el “patient image module” permite guardar
imágenes en los perfiles de los pacientes. Esto podría ser una
solución a la falta de documentos de identidad. También existe el
“idgen module” para crear códigos de identificación de pacientes y el
“id card module” que es similar al idgen, pero añade la posibilidad de
18
imprimir los códigos de identificación como código de barras para la
creación de tarjetas físicas, estos dos últimos por poca costumbre de
utilización de documentos de identificación, creemos que no seria
una solución adecuada al problema.
• No hace falta conocimiento en programación para configurar el
sistema, OpenMRS ofrece herramientas web que permiten mantener
y manejar el sistema sin tener un perfil técnico.
• Tiene una app móvil que se comunica con el sistema central
permitiendo visitas a distancia.
• Existe una gran comunidad de desarrolladores que están
trabajando en situaciones similares. Las principales organizaciones
que participan en implementaciones en OpenMRS de manera activa
són: Millenium Villages Project, Jembi Health Systems y Partners in
Health [16]. Como podemos ver en la figura 1 estas son algunas
implementaciones de OpenMRS en África .
19
1.6 Problema y Alcance
Este proyecto tiene como objetivo reducir la tasa de enfermos hipertensos
mediante la implementación del software OpenMRS como herramienta de
soporte para el personal medico del hospital de Gambo en Etiopía. Agilizando
los procesos de gestión de los pacientes permitiendo ofrecer una atención
sanitaria de mayor calidad a través de un sistema integral de salud. Que se
consiga ofrecer una mejor diagnosis de la patología, aumentar la adherencia al
tratamiento y en definitiva disminuir la tasa de morbilidad y mortalidad de las
localidades involucradas. Que cumpla con las necesidades económicas (bajo
coste) ,que sea fácil de mantener y sea escalable.
Debido a la situación socio-económica del entorno del hospital, existen
ciertos aspectos a los que habrá que dirigirse en cuanto al diseño del sistema,
estos han sido cedidos por el cliente. Uno de los puntos más críticos es que ha
de ser lo más económico posible debido al entorno al que va dirigido. Otro
punto importante es que se necesita un sistema móvil que puedan utilizar los
operarios del hospital cuando realizan visitas en zonas remotas, la mayoría no
disponen de conexión a la red, por lo que el sistema debe poder operar sin
conexión. Por desgracia, por falta de personal cualificado estos operarios no
tienen conocimientos médicos por lo que la toma de constantes vitales debe
ser lo más sencilla posible. Por ultimo se debe tener en cuenta que muchos de
los pacientes no disponen de ningún documento de identificación personal, por
lo que se tendrá que idear un método de identificación. Este es un grave
problema ya que los médicos no pueden asegurar que atienden al paciente
indicado. El hospital tiene conexión a Internet y un router.
20
1.7 Metodología y Herramientas
Metodología inicial
Teniendo en cuenta que se dispone de un tiempo de desarrollo relativamente
corto y las pocas personas implicadas en el proyecto, hemos establecido una
metodología de trabajo personalizada, basada en una metodología ágil.
El trabajo se dividirá en tareas que se desarrollaran de manera iterativa.
Cada tarea proporcionara un resultado completo que se le podrá presentar al
cliente. Esto permitirá una mayor implicación por parte del cliente durante la
construcción del sistema. Lo que mejorara la comunicación cliente-
desarrollador agilizando la rectificación de cualquier malentendido.
Como herramientas de soporte de la metodología explicada en el punto
anterior, utilizaremos trello y Github. Trello es una plataforma en linea que
simula el tablero que se utiliza en una metodología ágil, esto nos permitirá
llevar un control de los objetivos alcanzados y por alcanzar. Github es una forja
(plataforma de desarrollo colaborativo) para alojar proyectos utilizando el
sistema de control de versiones Git, el conjunto de estas dos herramientas
facilitara monitorizar la evolución del proyecto.
Metodología Final
La metodología que se propuso al iniciar el proyecto ha cambiado.
Actualmente se esta utilizando GitHub como forja (plataforma de desarrollo
colaborativo) para alojar proyectos utilizando el sistema de control de versiones
Git, como repositorio en linea que ayuda a la monitorización de la evolución del
proyecto, como se propuso inicialmente,.
21
El primer paso ha sido llegar a un acuerdo con el cliente, donde nos ha
expresado las necesidades y funcionalidades que ha de tener el producto final.
A partir de aquí el desarrollador es libre de implementar estas funcionalidades
como el desee. Para asegurar un mejor producto, el desarrollador tendrá como
apoyo a la pos-desarrolladora que ante alguna duda de aspecto técnico le ira
guiando a través de este proyecto.
El proyecto se estructura en evolutivos [33] que se desarrollan de manera
iterativa. Cada tarea proporciona un resultado completo, que corresponde a
una funcionalidad especifica. Con este método se consigue una mayor
independencia entre tareas, consiguiendo una mejor visión del estado de
avance del proyecto y facilitar el proceso de test una vez implementadas.
El seguimiento del trabajo desarrollado consistirá en una reunión semanal
entre el desarrollador y la directora con el objetivo de informar a la directora del
trabajo que ha ido realizando durante la semana.
Al ser un proyecto de pocos participantes, herramientas propuestas para
ayudar al seguimiento y control del trabajo no eran realmente necesarias y no
se han acabado utilizando (como trello).
22
1.8 Sistema de validación
Para comprobar que el sistema funciona correctamente, a medida que se
vayan añadiendo nuevas funcionalidades, se hará una entrada de datos a
modo de prueba. Los datos se entraran simulando los procesos que seguiría un
operario del hospital. Una vez entrados los datos, se comprobará que el
sistema los almacena de manera correcta. La entrada de datos consistirá en:
1.Creación de pacientes, añadiendo su información.
2.Crear visitas para los paciente.
3.Entrar formularios de las visitas.
4.Comprobar que los datos se sincronizan entre la aplicación móvil
y el sistema central.
5. El cliente realizara una prueba en terreno.
23
1.9 Posibles Obstáculos
• Configuración de la plataforma: Encontrar la configuración ideal no es
algo trivial. El añadir más funcionalidades a un sistema hace que este a su vez
se haga más complicado de utilizar. Por lo que encontrar un equilibrio puede
ser una tarea compleja. Para encontrar ese equilibrio se probaran diferentes
versiones del sistema con diferentes estructuras.
• Rechazo del proyecto: Va muy ligado al punto anterior. Existe una
resistencia al cambio cuando se pretenden cambiar la rutina de trabajo a las
personas. La curva de aprendizaje inicial de un sistema de información, puede
hacer que al principio ralentice algunos de los procesos. Si no se supera, hace
que se abandone el intento de utilizar-lo. Para prevenir que pase crearemos
una plataforma con una estructura intuitiva y simple.
• Tiempo: Una mala gestión del tiempo, puede provocar que no se cumplan
los objetivos propuestos para el día de la entrega. Para evitar este problema,
se seguirá un calendario estricto pero conservador para poder hacer frente a
los posibles contratiempos.
24
2. Plan de Proyecto
Este apartado contiene la programación de las diferentes actividades que
aseguraran la finalización del proyecto acorde al tiempo disponible. A
continuación se presenta una planificación dinámica que se ajusta al carácter
del proyecto, que, durante su desarrollo puede sufrir cambios imprevistos.
2.1 Planificación y Programación Inicial
El proyecto tendrá una duración de 3 meses y medio. La fecha de inicio del
proyecto es el domingo, 1 de Octubre de 2017 y finalizará el viernes, 26 de
Enero de 2018 día de su presentación.
La fecha de finalización entra dentro del plan establecido inicialmente, este
puede estar sujeto a cambios, por lo que la fecha final podría ser aplazada.
2.2 Descripción de Procesos
A continuación se presentaran las diferentes etapas/fases del desarrollo del
proyecto. Estas se dividirán en tareas, que consistirán en iteraciones que
proporcionen un resultado completo. Anteriormente ya se ha recogido
información básica para una configuración inicial de los formularios
correspondientes al tratamiento de la hipertensión. Durante todo el proyecto se
ira creando documentación en paralelo al trabajo realizado.
2.2.1 Familiarizar-se con el entorno OpenMRS
25
Esta fase es una fase de aprendizaje, donde la tarea principal será analizar
el funcionamiento y estructura de OpenMRS, para adquirir experiencia de
desarrollo con la plataforma. Esta fase se dividirá en las siguientes tareas:
• Creación del entorno de trabajo, instalar el sistema en un servidor
local, y crear un árbol de versiones en un repositorio en linea como GIT.
Eso permitirá tener más control de los avances del trabajo y tener un
modo de recuperación frente a cualquier error.
• Adquisición de conocimiento como implementador de la plataforma.
En esta tarea realizaré pruebas de creación de campos de la base de
datos, cambio a formularios y entrada de datos de pacientes a modo de
ejemplo. Así como la creación de perfiles de usuarios. En esta tarea se
usara la documentación proporcionada por la comunidad de OpenMRS
que se puede encontrar en https://wiki.openmrs.org/display/docs/Home.
• Una vez, completado el punto anterior, habré adquirido conocimiento
suficiente de la plataforma. Se procederá a re-analizar las herramientas y
módulos que se van a utilizar.
2.2.2 Configuración de OpenMRS acorde al proyecto
La parte más critica del proyecto. Esta configuración tendrá que ir acorde a
los deseos del cliente en el control de la hipertensión y los procesos del
hospital. Una vez terminada se hará servir como versión piloto, donde el cliente
podrá revisar la funcionalidad y dar re-alimentación hasta que se consiga una
versión definitiva. Esta fase se dividirá en las siguiente tareas:
• Diseño de la configuración de la plataforma. Esta tarea empieza con
la recopilación de datos de los campos y conceptos que se guardaran en
26
la base de datos. Así como la información a plasmar en los formularios
electrónicos para el cuidado de la hipertensión. Toda la información
necesaria sera cedida por el cliente quien posee conocimiento medico y
de los procesos del hospital.
• Implementación del diseño de la tarea anterior. Con los
requerimientos obtenidos, hacer la configuración en OpenMRS. Durante
la implementación se buscara que la estructura de programa sea clara y
se utilice el lenguaje adecuado.
• Creación de los diferentes perfiles de usuario. El sistema será
utilizado por diferentes usuarios que requieren permisos distintos. Se
analizara cuantos usuarios distintos debe tener la plataforma y que
permisos tendrá cada uno.
• Pruebas de la implementación. Esta tarea servirá a modo de
identificación y corrección de los posibles errores que hayan ido surgiendo
durante la implementación. Estas pruebas se repetirán hasta que se haya
encontrado una versión estable para poder utilizar como versión piloto.
• Creación de Scripts de despliegue, se crearan scripts de despliegue y
un manual de instalación para facilitar la instalación por personal no
técnico del hospital.
• Revisión de versiones. Empieza una vez terminada la versión piloto,
la cual contendrá una configuración básica pero suficiente para que el
sistema sea usable. A medida que se vayan utilizando diferentes
versiones aparecerán cambios necesarios que afectaran al diseño actual
del momento por lo que se repetirán todas las tareas hasta encontrar una
versión estable.
27
2.2.3 Implementación de funcionalidades especificas
El sistema se debe adaptar al entorno social al que va dirigido. Para eso
sera necesario que se añadan funcionalidades especificas a la plataforma.
• Permitir el funcionamiento sin conexión a la red de la aplicación móvil.
La aplicación móvil en su estado inicial puede operar sobre objetos ya
existentes, y cuando recobra la conexión se sincroniza automáticamente.
Pero no puede crear nuevos objetos, por ejemplo la creación de una visita
no es posible. Para añadir esta funcionalidad se cambiara el código fuente
de la aplicación móvil, con especial cuidado en la conservación de la
integridad de los datos del sistema.
• Creación de un método de identificación de los pacientes. Esta tarea
consistirá en: añadir un modulo que permita guardar la imagen del
paciente en su ficha electrónica, crear una política de renovación de esta
imagen acorde con el cliente y adaptar la programación del modulo para
que siga la política de cambio de la imagen.
2.2.4 Plan de Mantenimiento y documentación
Para finalizar y con el objetivo de dar continuidad al proyecto, se creara un
documento con los perfiles técnicos necesarios para mantener y seguir
adaptando el sistema. Toda la documentación creada se recopilara, y se creara
un documento único para presentarlo como memoria.
28
2.3 Equipamiento y Herramientas
Para que el método de trabajo se pueda realizar correctamente, son
necesarios los siguientes materiales:
• Un ordenador al que se le instalara OpenMRS al que se le realizaran la
pruebas que cumpla con los requisitos mínimos destinados a guardar
centenares de pacientes: un procesador de 1GHz, 256MB de memoria y
40GB de espacio. Este debe tener instalado: Java, mySQL para crear y
gestionar la base de datos, y un servidor apache Tomcat.
• Para la aplicación móvil un teléfono Android con wifi y GPS.
• Entornos de desarrollo como un navegador web compatible y un editor
Android como Android Studio.
• Tensiómetro bluetooth Thomson TLS 808.
29
2.4 Estimación del tiempo
En la tabla 1 podemos ver la estimación horas para cada etapa y tarea.
30
Tabla 1: Horas estimadas por etapa
2.5 Diagrama de Gantt
En la figura 1 podemos ver como están programadas las tareas según el
calendario mediante un diagrama de Gantt. Se ha considerado un trabajo de
entre 5 y 6 horas diarias de lunes a viernes, teniendo en cuenta que hay tareas
que se solapan.
31
Figura 2:
Diagrama de Gantt
2.6 Plan de control y acción
El objetivo es seguir la planificación establecida del proyecto. Por eso se ha
creado una programación que a partir de la versión piloto tiene un carácter más
dinámico. La versión piloto es un punto critico para cumplir con los objetivos del
proyecto a tiempo. Es necesaria para que el cliente y los operarios del hospital
puedan probar el sistema y nosotros podamos obtener feedback lo más pronto
posible. También es necesaria para que podamos probar el funcionamiento de
las funcionalidades especificas una vez implementadas. Se ha tenido en cuenta
que el feedback no va a llegar de manera lineal en el tiempo, sino que va a
crear picos de trabajo. Con la estructura de trabajo creada nos permitirá la
flexibilidad de seguir avanzando en una tarea dependiendo del estado del
proyecto en ese momento.
Como norma general, y esta incluido en las horas de trabajo. Se deberá
organizar las reuniones con el cliente con suficiente antelación. En todo
momento será necesario obtener suficiente información como para no
quedarnos estancados en la implementación por falta de datos.
Las reuniones semanales con la directora permitirán detectar cualquier tipo
de inconveniente a tiempo, y encontrar una solución para seguir con la
programación prevista. Aun así es conveniente tener presente que es lo que
puede suceder. Uno de los posibles problemas seria que la versión piloto o una
cercana fuera la versión definitiva, o si el trabajo avanzara más rápido de lo
previsto. En ese caso se emplearía las horas sobrantes para implementar otra
funcionalidad de utilidad, después de implementar las funcionalidades ya
planeadas. Por el contrario si por complicaciones no cumpliéramos con el
plazo. Se dejaría una versión más básica y se crearía un documento con las
posibles mejoras a realizar.
32
Después de estimar el tiempo, se ha calculado 420 horas de trabajo total
durante 15 semanas, antes de que empiecen las presentaciones. Eso hace una
media de 28 horas de trabajo semanales.
33
3. Costes
En esta sección se analizaran los costes asociados al proyecto. Aunque sea
de carácter solidario y sin animo de lucro, los costes asociados a la creación
del proyecto, nos ayudaran a profundizar y estimar el impacto socio-económico
general asociado a el.
Como el proyecto esta basado en una colaboración altruista, sin animo de
lucro, su viabilidad no debe verse desde un punto de vista monetario. La
viabilidad dependerá del impacto social estimado por el coste total del
proyecto.
3.1 Coste de Recursos Humanos
Durante el desarrollo del proyecto, tendré que asumir diferentes roles: el de
analista, programador, jefe de proyecto y tester. Se puede diferenciar el tiempo
invertido de cada rol de las 420 horas inicialmente estimadas. En la siguiente
tabla encontramos el precio por hora (consultado en la web pagepersonnel) y
las horas totales de participación como cada rol, que conforma el coste total de
recursos humanos.
34
Tabla 2: costes recursos humanos
Las horas se han repartido según la función que desempeña cada rol en el
proyecto. Como líder organizare todo el trabajo, y decidiré como implemento
los diferentes requerimientos que me pida el cliente. Como analista me
encargaré de llevar a cabo el diseño y configuración de la aplicación así como
especificar el trabajo que haré como programador. De programador me
encargare de escribir el código necesario y de tester comprobare que no hayan
errores en la funcionalidad del sistema.
35
Tabla 3: Horas por Etapa
3.2 Costes del Hardware
OpenMRS no es un software muy exigente, pero aun así sera necesario
hardware especifico para tener el sistema en funcionamiento y poder realizar la
configuración requerida por el cliente (precios obtenidos de la web
pccomponentes, estos pueden haber sido modificados con el tiempo).
En la tabla 4 se muestra el coste del hardware necesario, considerando su
vida útil y la amortización del equipo. La amortización se ha calculado mediante
la formula Amortización = (Precio – Valor residual ) / vida útil.
36
Tabla 4: coste del hardware
3.3 Costes del software.
Por requerimiento el software utilizado debe tener el menor coste posible.
Por eso se opta a utilizar herramientas gratuitas, por lo que el coste total es
cero.
En la tabla 5 se muestra el coste del software necesario, considerando su
vida útil y la amortización del equipo.
37
Tabla 5: costes del software
3.4 Costes Indirectos
En la siguiente tabla se muestran los costes que afectan al proceso de
desarrollo productivo del proyecto (precios consultados en la web datoluzhora y
rastreator).
3.5 Fondo para Imprevistos
Aunque no haya un riesgo específico reconocido, es muy posible que no se
cumpla con el tiempo de desarrollo inicialmente establecido. Frente este caso
se guardara una partida correspondiente al 15% total de las horas destinadas
de cada rol como fondo de reserva. Que solo se utilizara para cubrir los gastos
ocasionados por un retraso en el desarrollo del proyecto.
38
Tabla 7: Fondo para Imprevistos
Tabla 6: costes indirectos
3.6 Coste Total del Proyecto
Sumando todos los costes de los apartados anteriores podemos conseguir el
coste total del proyecto.
La tabla 6 muestra lo que cuesta el desarrollo del proyecto.
3.7 Plan de control y acción
La estimación del coste del proyecto inicial puede estar sujeta a cambios,
dependiendo de las necesidades durante el desarrollo del proyecto. Un primer
paso es analizar los riesgos que puedan afectar e esta y tener un plan para
afrontarlos. En la siguiente tabla se muestra la exposición al riesgo teniendo en
cuenta el coste máximo que esta puede tener.
39
Tabla 8: Coste Total del Proyecto
Tabla 9: Fondo para Imprevistos
Como hemos visto antes los costes asociados all hardware y software
utilizados en el proyecto difícilmente van a sufrir un cambio. El proyecto solo
utiliza herramientas software gratuitas y el hardware listado anteriormente es
suficiente para el desarrollo. Solo seria necesario un cambio en el hardware si
apareciese un requerimiento muy específico y eso es muy poco probable, o se
estropeara algún componente.
Por otro lado los costes de recursos humanos van ligados a la planificación
temporal, y esta si que es probable que cambié durante el desarrollo. Para
controlar estos posibles cambios se creara una hoja de calculo de Google para
que se puedan imputar las horas dedicadas a cada tarea. Con esto y las
reuniones semanales se podrá hacer un seguimiento de cumplimiento de
objetivos, y frente a cambios, volver a analizar la desviación de costes de cada
tarea.
Para poder cuantificar estas posibles desviaciones haremos uso de los
siguientes indicadores.:
Desviación de coste por tarea : (coste estimado – coste real) * coste real
Desviación de tiempo consumido por tarea: (coste estimado – coste real) * coste real
horas
Desviación de coste total por tarea: (coste total estimado – coste total real)
Estos indicadores nos ayudaran a controlar la desviación en el coste de las
tareas, su coste en horas y el coste de realización total. Con el fondo destinado
a imprevistos, podremos hacer frente a cualquier desviación que pueda ocurrir.
40
4. Desviaciones de la Planificación
La planificación del proyecto ha cambiado, se ha ampliado el plazo de
entrega. Ha pasado del 26 de Enero a 27 de Abril.
La falta de información del software OpenMRS hace que elementos
aparentemente triviales consuman más tiempo de lo previsto. Por otra parte
una de las funcionalidades de la aplicación, crear visita mediante el modulo
Rest no funciona correctamente. El primer enfoque para solucionar la captura
de información offline hacia uso de esta funcionalidad, por lo que hubo un coste
temporal significativo. Ahora se a enfocado el problema de forma distinta, que
ofrece un resultado similar. Por otra parte me faltaba conocimientos en Android,
que he ido adquiriendo poco a poco, y no he podido emplear el tiempo diario
que había estimado. Al ampliar la entrega se han vuelto a definir las diferentes
tareas del proyecto, que con más conocimiento de OpenMRS y los
requerimientos del cliente, ha habido un re-diseño al problema mucho más
enfocado a modificaciones de la aplicación móvil.
Cabe destacar que al inicio de esta segunda fase hubo un desvió. A primeros
de Febrero, el servidor se estropeo y retrasó el inicio 2 semanas, no solo eso
sino que también también hubo que re-configurar la nueva instalación del
servidor.
4.1 Actualización de Descripción de Tareas
A continuación se presentaran las diferentes tareas del desarrollo del
proyecto. Anteriormente ya se ha recogido información básica para una
configuración inicial de los formularios correspondientes al tratamiento de la
hipertensión.
41
4.1.1 Familiarizar-se con el entorno OpenMRS y Android
Esta fase es una fase de aprendizaje, donde la tarea principal será analizar
el funcionamiento y estructura de OpenMRS, para adquirir experiencia de
desarrollo con la plataforma. Esta fase se dividirá en las siguientes etapas:
• Adquirir conocimientos en desarrollo de Android.
• Crear los formularios básicos, para poder empezar el desarrollo en la
aplicación.
• Hacer la ingeniería inversa del código de la aplicación Android para
entender su funcionamiento.
4.1.2 Mejorar asistencia sanitaria offline
Debido a la situación en la que se encuentra el entorno del hospital, una de
las mayores necesidades es mejorar las funcionalidades offline de la aplicación
móvil, para que pueda funcionar de manera autónoma en cuanto a la captura
de información del paciente. Para esto sera necesario añadir las siguientes
funcionalidades a la app:
• Capturar la información de los formularios, y sincronizarlos con el servidor
central.
• Visualizar los formularios de los pacientes anteriormente cargado y creados
offline.
• Permitir al usuario liberar el espacio de los usuarios precargados en el
móvil.
42
4.1.3 Automatizar la toma de datos
Para evitar errores humanos habrán datos que se introducirán en la
aplicación automáticamente:
• Mediante un tensiómetro bluetooth, se harán la medidas de presión arterial.
• Mediante el GPS del móvil se guardaran las coordenadas, y se guardaran
como atributos de un paciente.
• En los formularios se calculara automáticamente el indice de masa corporal
(BMI) a partir de los campos entrados por el usuario.
4.1.4 Añadir atributos
El sistema incorpora los atributos más comunes para un paciente, como la
edad, la dirección o el contacto. Pero será necesario capturar información
adicional.
4.1.5 Búsqueda de pacientes por Localidad
Será necesario realizar una búsqueda por atributos específicos como la
Localidad para encontrar los pacientes del sistema. De momento solo es
posible realizar la búsqueda por nombre y identificador del paciente.
4.1.6 Generar aviso de tratamiento
Un punto a tener en cuenta es que la persona encargada de tomar las
constantes vitales a un paciente no siempre tendrá conocimiento médico. Por
tanto es conveniente que para facilitar la detección de un paciente que requiere
tratamiento, la aplicación genere un aviso de forma automática, dependiendo
de los datos entrados por formulario.
43
4.1.7 Redistribución de la Aplicación
El cliente no le dará el uso a parte de las funcionalidades que ofrece la
aplicación de serie, por lo que se hará un re-diseño de la interfaz para que el
uso sea más simple.
4.1.8 Documentación
Todo el trabajo realizado durante el proyecto se ira documentando para
presentar como memoria.
Tabla 10: Horas Estimadas por Etapa de la desviación
En la tabla 10 se ha estimado las horas de desarrollo posterior a la desviación,
teniendo en cuenta la experiencia adquirida.
44
4.2 Costes de la Desviación
Podemos suponer que la desviación ha incrementado los costes del
proyecto. Considero que de las horas diarias estimadas en una primera
instancia he podido emplear el 60%. De las 420 horas iniciales he podido
dedicar 252 horas. Las horas dedicadas más las horas de la nueva
planificación son total de 450 horas. Hay 30 horas que no se han contemplado
en el plan inicial, teniendo en cuenta que el coste medio por hora de recursos
humanos es de 32,5 euros. Esta desviación cuesta 975€, que se pueden cubrir
con los 1875 euros de imprevistos de recursos humanos.
45
Figura 3: Diagrama de Gantt Después de la desviación
5. Sostenibilidad
En esta sección se analizara el impacto social, ambiental y económico que
puede tener el proyecto en el entorno donde se enmarca.
5.1 Sostenibilidad Ambiental
La huella ecológica durante el desarrollo viene de la consumición de energía
que produce el hardware mientras se hace funcionar el sistema. La mayoría del
tiempo para poder desarrollar se necesitara el móvil, ordenador y router
encendidos. Estos consumen una media de 50W, 300W y 20W
respectivamente, por lo que si lo multiplicamos por las 420h de desarrollo nos
da 155,4kWh, esta es la energía que se consumirá durante el desarrollo.
Una vez implantado el sistema durante la vida útil del proyecto, el registro
medico físico se sustituirá por uno electrónico. Esto requerirá que el sistema
46
Tabla 11: matriz de sostenibilidad
este en marcha todo el día consumiendo un total de unos 370W. Aunque es
una cantidad bastante elevada no hay forma de reducirla.
5.2 Sostenibilidad Económica
En este documento se puede encontrar el estudio de los recursos humanos
y materiales destinados al desarrollo del proyecto.
Como ya se ha comentado uno de los principales objetivos del proyecto es
hacer la implementación del sistema lo más barata posible, esa es la razón por
la que solo se utiliza software libre. El hardware utilizado es económico, pero
sus especificaciones no comprometen el rendimiento. Se ha tenido en cuenta
los módulos existentes para OpenMRS creados por otras organizaciones.
Para el hospital de Gambo implementar el sistema no supondrá costes
adicionales, ya que disponen de todo el hardware requerido y supondrá un
ahorro en material de oficina: Papel, bolígrafos, carpetas, archivadores… y una
mejor gestión del tiempo.
Durante la vida útil del proyecto se necesitará una persona encargada de
administrar el sistema y mantenerlo, pero no necesariamente ha de tener
conocimientos de programación. OpenMRS permite llevar la gestión con una
interfaz gráfica. El hospital dispone de hardware suficiente para tratar con el
numero de pacientes que tiene habitualmente y más, pero si crecieran de golpe
y fuera necesaria una renovación, OpenMRS escala fácilmente. Por otra parte
la identificación precoz de la hipertensión permite aplicar un tratamiento no
farmacológico que es más barato.
47
5.3 Sostenibilidad Social
A nivel personal este proyecto me aporta conocimientos en software de
gestión, a tratar con el cliente, funcionamiento de Api Rest, Android y de
arquitectura software. Pero también me permite llevar a cabo un trabajo
solidario con el objetivo de ayudar de manera desinteresada a incrementar el
bienestar y el desarrollo social de aquellas poblaciones con pocos recursos.
El proyecto va a mejorar la gestión que se hace en el hospital de Gambo
para tratar la hipertensión, ya que el sistema mejorara los procesos de
seguimiento y control mediante un historial clínico. Entre los beneficiarios está
el personal sanitario del hospital, que utilizará esta herramienta como apoyo
para poder ofrecer un mejor servicio sanitario. La población de Gambo en
general, que gracias a un mejor bienestar tendrá un mayor desarrollo social.
Por otra parte creara nuevos puestos de trabajo, ya que personal no
cualificado podrá realizar mediciones de constantes vitales gracias a la
automatización del proceso desde la aplicación. También será necesario un
administrador para mantener el sistema.
El sistema se podrá descargar desde un repositorio público, para poder ser
implementado en más sitios.
48
6. Estructura de OpenMRS
OpenMRS es una herramienta pensada y diseñada para entornos que
disponen de pocos recursos, los cuales presentan necesidades muy dispares
entre ellos. Por eso la herramienta presenta una estructura dinámica que
permite adaptar el sistema para ofrecer una solución configurada para tratar el
problema en cuestión.
El servidor web OpenMRS sigue una arquitectura modular [17], es decir se
estructura de una base común llamada núcleo y diferentes aplicaciones
funcionales llamadas módulos. Los módulos trabajan encima del núcleo y le
añaden funcionalidades de manera independiente, por lo que si un módulo
falla, este no implica el fallo del resto. A la configuración del núcleo y los
diferentes módulos se le llama distribución. Cabe destacar que para poder
traspasar información entre módulos estos deben cumplir el formato estándar
HL72.
Cada implementación de OpenMRS tiene como corazón el diccionario de
conceptos, un componente fundamental que define los conceptos médicos
(preguntas y respuestas) utilizados como bloques de construcción para los
formularios, informes y resúmenes clínicos. De forma similar a un diccionario
que define la función, el significado y las relaciones de las palabras, el
diccionario de conceptos define el nombre, el código y los atributos apropiados
para cualquier observación o información recopilada.
2 (Health Level Seven) es un conjunto de estándares que dictan el formato en
el que se intercambia la información electrónica entre sistemas sanitarios
desvinculados.
49
La aplicación utiliza los recursos descargados de la base de datos del
servidor, por lo que es esencial conocer los elementos básicos de esta.
- Conceptos: Son los elementos básicos que estructuran la información que
almacena OpenMRS, los elementos de información individual recolectados de
una población de pacientes y aportan flexibilidad a la implementación para
poder adaptar-se a cada proyecto. De los atributo de un concepto cabe
destacar:
Tipo: El tipo define como sera la respuesta al concepto, puede ser de
tipo: numérico, texto, N/A, documento, fecha, booleano y estructurado.
Clase: La clase es la categoría que encontramos que forma parte de la
definición de cada concepto por ejemplo si es una medición, síntoma,
pregunta, dosis…
Grupo: Los conceptos pueden ser un concepto grupo, o pertenecer a un
grupo. Por ejemplo dentro del concepto “mediciones para la hipertensión”
podríamos encontrar la presión arterial, el pulso, el peso ..
- Encuentros: Representan una única interacción entre personal médico
(proveedor) y un paciente. Se representan normalmente como un formulario y
tiene como atributos la fecha, una ubicación, la descripción, el proveedor y la
localización del mismo.
Tipo de Encuentro: Define a que se debe el encuentro, como por
ejemplo recogida de constantes vitales, administración de suero, receta de
medicamento.
50
- Observaciones: Cualquier instancia medida o observada dentro de un
encuentro. Se representa típicamente como el conjunto formado entre un
concepto y su respuesta.
- Formularios: Documento estructurado donde se recogen las observaciones
de un encuentro.
- Persona: Objeto que se utiliza para guardar los datos de identificación de una
persona (nombre, apellido, fecha de nacimiento) y los demográficos
(población, dirección). Se genera un identificador único para cada persona.
- Paciente: Persona que es atendida por personal hospitalario, tiene al menos
un encuentro.
- Usuario: Persona que utiliza de forma directa el sistema. Los usuarios tienen
privilegios, permisos que definen lo que pueden o no pueden hacer dentro del
sistema. Se pueden crear conjuntos de privilegios llamados roles, que son
típicamente la función que desempeña el usuario dentro del centro medico
(enfermero, medico, administrador). Hay tres categorías principales de usuarios
en toda implementación OpenMRS.
Desarrolladores: Programan nuevas funcionalidades para la aplicación
y actualizar e implementar mejoras para que este software libre tenga viabilidad
en el futuro. Es el perfil más técnico y su función es principalmente programar.
Administradores: Utilizan las herramientas del sistema para crear
usuarios, formularios, instalar módulos etc.. Se encargan de que la
configuración del sistema este actualizada con la situación actual del centro
sanitario.
51
Proveedores (Personal Medico): Son los usuarios que proveen al
paciente de servicio sanitario a través del sistema de salud.
- Localizaciones: Diferentes ubicaciones donde se ejerce atención sanitaria
como: centros hospitalarios, ambulatorios etc.
- Metadatos: Describen el contenido informativo de los recursos
personalizados. Establecen el esqueleto de OpenMRS para su posterior
almacenamiento de datos.
- Observaciones: Cualquier instancia medida o observada dentro de un
encuentro. Se representa típicamente como el conjunto formado entre un
concepto y su respuesta dentro de un formulario.
- Visitas: Periodo de atención sanitaria esperada que se compone de
diferentes encuentros. Las visitas cuentan con un tipo de visita, por ejemplo
una visita a domicilio, hospitalaria, de urgencias etc..
Todos los objetos generados en la base de datos de OpenMRS obtienen un
UUID3, este se utiliza para poder sincronizar información entre otros sistemas
OpenMRS utilizando el modulo sync [18].
3 Código de identificación único formado de 16 bytes, utilizado en base de
datos. Asegura con un 99,99% de probabilidad de que el código generado es
único en el mundo.
52
7. Elección de la distribución Reference
Application y OpenMRS Android Client
En el apartado ‘1.5.1 estudio de mercado’ justificamos porque se utiliza
OpenMRS como herramienta principal para el proyecto. Como se ha
mencionado antes, la comunidad de OpenMRS ofrece diferentes
configuraciones de core y módulos llamadas distribuciones.
Nosotros hemos partido de la distribución Reference Application encontrada
en OpenMRS.org y recomendada como punto de partida por la comunidad de
OpenMRS, es la versión estándar, la más portable, y es la única que aseguran
que funciona con la aplicación móvil OpenMRS Android Client.
Existen varias aplicaciones para Android en el mercado, que se pueden
comunicar con un servidor OpenMRS, de todas las opciones hay cuatro que se
ajustan a las necesidades principales del proyecto, que son: la recolección de
datos mediante formularios, consulta del historial de un paciente y posibilidad
de funcionar sin conexión a la red. Estas son:
Open Data Kit (ODK): Puede descargar los formularios y pacientes de
OpenMRS. Para la sincronización de los formularios utiliza el modulo Xforms.
Permite rellenar formularios y acceder a informes generados automáticamente
de los pacientes. Necesita conexión a la red. [19]
OpenMRS-JR: Permite al usuario descargar pacientes a través del
modulo de cohortes, y sincronizar los formularios hechos con Xforms, también
permite la creación de nuevos pacientes a través del modulo REST. Necesita
conexión a la red. [20]
53
MOpenMRS: Es una aplicación móvil destinada al cuidado especifico de
la tuberculosis. Permite la entrada de datos mediante formularios creados con
el modulo Xforms, la descarga de pacientes mediante el modulo de la cohorte y
la creación de pacientes mediante el modulo REST. Puede operar sin red. La
aplicación, aun y ser de código libre, no esta documentada, y para poder
descargar los pacientes al móvil es necesaria una configuración especifica de
estos en el modulo de la cohorte. [21]
OpenMRS Android Client: El objetivo de esta aplicación es que tenga la
misma funcionalidad para un proveedor que cuando accede a OpenMRS desde
un navegador web (registrar pacientes, introducir formularios, capturar
información, crear visitas…) con y sin conexión a la red. Utiliza el modulo
REST para comunicar-se con el servidor y sincronizar los datos. Es un proyecto
que aun esta en desarrollo y algunas de las funcionalidades no están
implementadas. [22]
. Open Data Kit y OpenMRS-JR se han descartado por no tener soporte al
funcionamiento sin conexión a la red, aspecto fundamental del proyecto. Se ha
descartado MOpenMRS, porque no hay documentación y es una aplicación
muy orientada al tratamiento de tuberculosis. Nos hemos decantado por
continuar el proyecto con OpenMRS Android Client, aunque la documentación
es escasa, después de hacer pruebas con la aplicación, hemos podido
comprobar que cumple con las siguiente funcionalidades:
Permite:
- Entrada a la aplicación con un usuario y una contraseña específicos
(Con el usuario y contraseña del servidor).
- Descargar pacientes del servidor, sus visitas y encuentros.
- Registrar un paciente desde la aplicación, con y sin conexión a la red.
- Entrar los datos de un formulario, pero no sincroniza bien los datos.
54
- Visualizar las ultimas vitales del paciente, funciona solo con conexión a la
red.
- Ver las estadísticas de las constantes vitales del paciente, funciona solo
con conexión a la red.
- Visualizar las visitas de un paciente descargado en el móvil.
- Descargar el diccionario de conceptos.
No permite:
- Empezar una visita desde la aplicación, hay una interfaz de usuario
destinada a esta funcionalidad, pero da error.
55
8. Arquitectura de OpenMRS Android Client
En este apartado se hará el análisis de la arquitectura software de
OpenMRS Android Client. Como partimos de un software existente, este
estudio nos permitirá entender el contenido y la estructura de la aplicación que
vamos a modificar. El propósito del análisis de este apartado es obtener una
visión general de la arquitectura del programa, no es un análisis hecho de
manera exhaustiva y al detalle.
Figura 4: Arquitectura General Android Client
OpenMRS Android Client esta programado en lenguaje Java[23], un
lenguaje orientado a objetos, por lo que el diseño software de la aplicación es
orientado a objetos. Como se puede observar en la figura 4 podemos dividir la
arquitectura en tres capas: la de Android que contiene el código de la interfaz
con la que interactuá el usuario, la de servicios responsable de intercambiar
56
información con otros sistemas software y la de datos que dota de persistencia
a la aplicación.
El proyecto esta estructurado en paquetes. Un paquete contiene un conjunto
de clases relacionadas bien por finalidad, por ámbito o por herencia y resuelven
el problema del conflicto entre los nombres de las clases.
Cabe destacar que en el paquete “models” están todas las clases de objeto
que sirven de instancia para representar la información que trata la aplicación.
Por ejemplo la clase Patient.java que representa un paciente o la clase
Encounter.java que representa un encuentro.
8.1 Capa de Android:
El código correspondiente a la capa de Android se puede encontrar en el
paquete “activities”. Como su nombre indica esta es la encargada de crear
todas las actividades de Android, que son los componentes de la aplicación
crean la pantalla con la que los usuarios pueden interactuar para realizar una
acción.
57
Figura 5: Capa de Android
La capa de Android sigue el patrón model-view-presenter.
model: Clase responsable de gestionar los datos de la aplicación.
view: Clase responsable de presentar los datos que ha obtenido del
presenter.
presenter: El presenter es el encargado de la lógica entre el model y la
view. El presenter obtiene los datos del model y hace las
transformaciones necesarias para que la view las presente al usuario.
interfaz contract: Se utiliza una clase contract que contiene interfaces
con los métodos que implementan el presenter y la view. [24]
La clase Activity de Android utiliza las librerías internas que ofrece Android
para crear los elementos interactivos que vemos por pantalla, como un botón o
un campo de texto.
8.2 Capa de Servicios:
La capa de servicios contiene las clases que se comunican con el modulo
REST del servidor OpenMRS. El módulo expone la API de OpenMRS como
servicios web REST, para que, otros programas (y lenguajes de programación),
puedan conectarse para consultar y enviar cierta información de la base de
datos del servidor OpenMRS [25]. El código correspondiente esta en el paquete
“api”.
58
Se utiliza la librería retrofit2 que sirve para convertir la API HTTP definida en
la clase RestServiceBuilder, en la interficie JAVA RestAPI que se ve en la figura
6. Esta sirve para definir las funciones de petición al servidor que luego
implementan las clase API y SERVICE. Existen cuatro tipos de petición:
GET: Petición para obtener recursos del servidor
POST: Petición para enviar recursos al servidor
UPDATE: Petición para modificar recursos del servidor.
DELETE: Petición para eliminar recursos del servidor
Las clases API implementan las funciones que requieren una petición al
servidor y en las clases SERVICE se encuentran las funciones llamadas
cuando la aplicación Android recupera conexión con el servidor. El código que
detecta cuando se ha recuperado la conexión con el servidor y inicia la
59
Figura 6: Capa de Servicios
sincronización de datos entre la aplicación y el servidor esta en la clase
SyncStateReceiver la cual implementa la función onReceive de la clase
BroadcastReceiver de Android. El servidor recibe y envía datos mediante
archivos JSON4.
8.3 Capa de Datos:
La capa de datos es la encargada de dar persistencia a los datos de la
Aplicación.
La aplicación utiliza una base de datos relacional sql [26], en la figura 8 esta
el diseño obtenido de realizar ingeniera inversa del código de las tablas de la
clases TABLE. Las clases que forman la capa de datos las encontramos en el
paquete dao y el paquete database. El paquete “dao” contiene las clases DAO
(data acces object), estas clases están formadas por los métodos que lanzan
consultas a la base de datos. El paquete “database” esta formado por las
4 (Java Script Object Notation) formato de texto estructurado para representar
un objeto de JavaScript. Utilizado para el intercambio de datos.
60
Figura 7: Capa de Datos
clases TABLE, que son las definiciones de las tablas en modelo entidad-
relacion [27] que utiliza la aplicación, y las clases que construyen la base de
datos. Las clases que construyen la base de datos extienden la clase de
Android SQLiteOpenHelper [28].
Los objetos Obscreate y Encountercreate corresponden a encuentros que no
están sincronizados con el servidor, y debido a que es el servidor quien asigna
el atributo uuid, no se pueden guardar en la base de datos ya que no cumplen
con la restricción no nulo de la columna uuid. Estos objetos se guardan en
forma de archivo JSON, y se identifican por el atributo encounters de la tabla
PATIENT que contiene sus identificadores. La base de datos no tiene
restricciones de llave foránea explicitas, se han incluido para facilitar la
identificación de relaciones entre tablas.
61
Figura 8: Esquema Entidad-Relacion de la Base de Datos
9. Objetivos y Especificación
El objetivo de este trabajo es implementar un sistema en openMRS que sirva
de herramienta de soporte para el personal medico del hospital de Gambo en
Etiopía. Agilizando los procesos de gestión de los pacientes y permitiendo
ofrecer una atención sanitaria de mayor calidad a través de un sistema integral
de salud. De manera que se consiga disminuir la tasa de morbilidad y
mortalidad del las localidades involucradas.
Para cumplir con los objetivos, el sistema deberá abordar los siguientes
puntos :
1. Mejorar la evaluación del tratamiento.
2. Ofrecer mayor cobertura sanitaria.
3. Facilitar la identificación y diagnosis de la hipertensión.
4. La aplicación debe funcionar de manera autónoma, sin conexión
a la red.
Objetivos 4, 2
Especificación Capacidad de trabajo sin conexión al servidor.
Justificación Las zonas remotas a las que se quiere proveer de atención
sanitaria, no tienen conexión a la red. La aplicación móvil
debe mantener las funcionalidades para ofrecer el cuidado
aun sin tener conexión al servidor.
62
Objetivos 3, 4
Especificación Sincronización con el servidor
Justificación Para permitir que la aplicación funcione de forma autónoma
sin necesidad de tener conexión al servidor. Esta ha de
poder sincronizar todos los datos recogidos cuando recobra
la conexión y ha de poder descargar los datos que se
encuentren en el servidor introducidos por otros sistemas.
Objetivos 2, 3
Especificación Obtención de datos mediante tensiómetro bluetooth
Justificación Esto permite que usuarios sin conocimientos médicos
puedan entrar datos al sistema de la presión arterial de un
paciente. Esto permite que hayan más operarios que cubran
más zonas.
Objetivos 3
Especificación Aviso automático de tratamiento
Justificación Esto permite que usuarios sin conocimientos médicos
puedan entrar datos al sistema de la presión arterial de un
paciente. Esto permite que hayan más operarios atendiendo
pacientes.
63
Objetivos 2
Especificación Mejorar la identificación de pacientes
Justificación Muchas personas de los alrededores de Gambo no disponen
de identificación personal, el personal medico muchas veces
ha de confiar de la palabra del paciente. La foto del perfil es
un método para asegurar de que se trata a la persona
adecuada que ya incluye la aplicación.
.
Objetivos 2
Especificación Historial de encuentros del paciente
Justificación El historial permite consultar información pasada de un
paciente. Para ofrecer un mejor diagnostico.
Objetivos 2
Especificación Informe del Paciente
Justificación La aplicación muestra un informe con gráficos de la
evolución del paciente, para mejorar el seguimiento de la
patología, así se puede determinar si la tratamiento esta
funcionando, y evaluar la efectividad del tratamiento.
Objetivos 2
Especificación El sistema ha de ser portátil
Justificación Para que la atención sanitaria pueda llegar a sitios remotos,
el sistema ha de ser portable. Por eso se utiliza tecnología
móvil.
64
.
65
Figura 9: Esquema del Funcionamiento de la Aplicación
10. Identificación de Formularios
El paso previo a la configuración del servidor ha sido identificar y clasificar
los diferentes formularios de la información que quiere capturar el cliente. Se ha
tenido en cuenta que, los formularios, por una parte han de ser lo suficiente
simples para que el personal del hospital de Gambo adopte el sistema como su
método principal para el control de la hipertensión, y por otra parte han de
contener suficiente información para poder ofrecer un diagnostico valido, y, que
a posterior, se pueda realizar un estudio valido sobre la efectividad del sistema
de cuidado creado en este proyecto y la situación de hipertensión en la Etiopía
rural.
El diseño de los formularios que se muestra a continuación se ha extraído de
un documento cedido por nuestro cliente, quien ha simplificado al máximo la
toma de información necesaria para poder llevar el seguimiento del control de
la hipertensión de un paciente.
66
Figura 10: Formulario con datos de registro estándar
La figura 10 muestra los datos que ya captura OpenMRS al crear un
paciente. Los datos que aparecen en este formulario no los tendremos que
entrar porque están de forma innata en la aplicación.
En la figura 11 aparece el formulario con los datos que extienden el registro
que aparece en la figura 10. Por lo general estos datos solo se tendrán que
capturar una vez, en el registro de un paciente. Se ha de tener en cuenta que
este formulario captura información de la religión, etnia y raza de un paciente,
considerada información sensible. Estos datos pueden ayudar a determinar
factores que describan la afectación de la hipertensión en una población. En
este formulario aparece la localización GPS, si el móvil dispone de GPS la
captura de estos datos se hará de forma automática.
67
Figura 11: Formulario de registro con datos especiales
En la figura 12 aparece el formulario de Antecedentes del paciente. Con este
formulario se detecta las posibles afectaciones que ha podido sufrir el paciente
anteriores al control de la hipertensión seguido con la aplicación, y que tienen
como fin principal, facilitar la asistencia sanitaria dejando constancia de todos
aquellos datos que, bajo criterio médico, permitan el conocimiento veraz y
actualizado del estado de salud del paciente.
68
Figura 12: Formulario de Antecedentes
En la figura 13 aparece el formulario de Control Vital. Este es el formulario
que recopila los datos, necesitados para diagnosticar a un paciente. Este
formulario utilizara el tensiómetro bluetooth para medir la tensión arterial del
paciente.
69
Figura 13: Formulario de Control Vital
En la figura 14 aparece el formulario de Factores de Riesgo. Este formulario
tiene un uso similar al formulario de la figura 12 (antecedentes). Captura la
información sobre aquellos hábitos de vida del paciente que pueden influir
directamente en los niveles de presión arterial.
70
Figura 14: Formulario de Factores de Riesgo
En la figura 15 aparece un informe de la evolución de un paciente. Este
informe se genera a partir de los datos recogidos repetidamente del formulario
de la figura 13.
Con la identificación de los formularios anteriores los podemos clasificar en
tres grupos:
Formularios con datos que varían entre encuentros: Estos
formularios se caracterizan por tratar con datos que suelen variar de un
encuentro a otro, y que los datos de encuentros pasados son importantes. Por
lo que sera necesario que la aplicación al descargar el paciente del servidor
descargue también el histórico de este tipo de formularios. El formulario de la
figura 13 “Control Vital” entra en este grupo
Formularios con datos que no varían entre encuentros: Estos
formularios se caracterizan por tratar con datos que no suelen variar de un
encuentro a otro, o que solo los datos del encuentro más reciente son
relevantes para el diagnostico. La aplicación solo descargara los datos de los
formularios más recientes que sean de este tipo. Los formularios de las figuras
11,12 y 14 (Registro de Datos Especiales, Antecedentes y Factores de Riesgo
respectivamente) entran en este grupo.
71
Figura 15: Informe de Seguimiento
Informes: Este es el caso de la figura 15. Este formulario o mejor dicho
cuadro de mando es una recopilación de los datos de otros formularios que
permite monitorizar de forma más clara la evolución de un paciente.
*Los formularios entrados en la aplicación estarán traducidos al ingles, para
mayor entendimiento del personal de Gambo.
72
11. Configuración de OpenMRS
Cuando se accede a un servidor OpenMRS recién instalado, requiere de una
fase de entrada de datos y adaptación al entorno al que va dirigido. En este
apartado se explica el proceso seguido durante la configuración del servidor.
73
Figura 16: Pantalla de Administración Avanzada
Para acceder a la pantalla de la figura 16 “Administración avanzada” es
necesario estar conectado con un usuario con rol de administrador y seguir la
ruta:
Inicio >> Administración >> Administración Avanzada.
11.1 Creación/Modificación de Usuarios
Todas aquellas personas que vayan a utilizar la aplicación deberán
conectarse mediante un usuario y contraseña proporcionados por el
administrador del sistema. Este usuario les permitirá autentificar-se y
conectarse a la aplicación. Si bien se puede crear un usuario general para que
puedan conectarse diferentes operarios, se recomienda crear un usuario
especifico para cada persona, ya que al rellenar un formulario el sistema
guarda en el registro con que usuario se ha entrado el formulario, facilitando el
seguimiento de los pacientes que ha atendido. Para poder crear un usuario
primero debemos acceder a la pantalla de administración de usuarios. Para
acceder, una vez en la pantalla de administración avanzada, debajo de
usuarios seleccionaremos “administrar usuarios”.
Figura 17: Administración de Usuarios
En la figura 17 aparece la pantalla de administración de usuarios. Desde
esta pantalla podemos crear un usuario nuevo, o buscar un usuario por su
74
nombre para modificar sus datos, esta búsqueda se puede filtrar por rol. Tanto
si queremos crear un usuario como si queremos modificarlo la navegación es a
la misma pantalla (figura 18).
En la figura 18 aparece la pantalla donde introduciremos o modificaremos
información del usuario. La entrada de datos en esta pantalla es auto-
explicativa, a excepción de los roles. Como todos los usuarios de la aplicación
van a ofrecer atención sanitaria (entrada de datos de un paciente). Estos se
deberán crear como proveedores (asignando el rol de proveedor y marcando la
casilla “Create a Provider account for this user”.
75
Figura 18: Pantalla Agregar/Modificar Usuario
11.2 Creación de Localizaciones
Las localizaciones sirven para identificar los diferentes centros donde se
atienden a los pacientes. Cuando un usuario inicia sesión, debe introducir el
nombre de usuario, su contraseña y la localización donde se encuentra. El
sistema asigna automáticamente la localización escogida a toda la atención
sanitaria suministrada por el usuario durante la sesión.
*OpenMRS a las Localizaciones les llama localidades y viceversa.
Figura 19: Pantalla de inició de sesión
Para crear una nueva localización desde la pantalla de administración
avanzada, seleccionaremos “administrar localidades”.
76
Una vez en la Pantalla de Administración de Localidad, para crear una
Localidad nueva seleccionaremos Agregar Localidad.
Para crear una localización nueva solo es necesario assignar-le un nombre.
OpenMRS tiene la funcionalidad de crear un árbol de localizaciones, en la
pantalla de creación (figura 21) se puede asignar la localización padre. Esta
estructura es útil para identificar localizaciones con nombres genéricos por
ejemplo: localización hija “quirofano”, localización padre “hospital de San
Pedro”.
77
Figura 20: Pantalla de Administración de Localidad
Figura 21: Pantalla de Creación de Localidad
11.3 Creación de Conceptos
Los conceptos son los elementos básicos que aportan flexibilidad a la
herramienta OpenMRS. Cualquier termino medico, ya sea para el diagnostico,
una pregunta, su respuesta o una medida, se traduce a un concepto. Todos los
concepto tienen una ID única dentro del sistema. Existen conceptos
predefinidos, como el peso, altura, pulso… estos hacen referencia a los
términos más comunes. La ID solo es única para un sistema OpenMRS, para la
sincronización de conceptos con otros sistemas se utiliza la uuid. Para poder
crear un formulario, previamente se han de crear los conceptos que lo
construyen. Dicho de otra manera, se precisa un concepto por cada dato de
entrada. Para crear un concepto, seleccionamos la opción “Vista de diccionario
de conceptos” de la pantalla de Administración Avanzada.
Desde la pantalla mostrada en la figura 22, podemos agregar un nuevo
Concepto, o buscar un concepto por nombre o ID para modificarlo. También se
puede descargar el diccionario de conceptos en formato .csv, esto es útil para
hacer una copia de seguridad o para importar los datos a otro servidor
OpenMRS.
78
Figura 22: Pantalla de Mantenimiento del Diccionario de Conceptos
Como se puede ver en la figura 23, la creación o modificación de un
concepto es simple. El mismo concepto puede estar definido en varios idiomas.
Para los tipo de dato coded, numeric y complex se han de entrar datos
adicionales. Para conceptos numéricos, podemos definir un máximo y mínimo,
si la respuesta tiene decimales, y si tiene, cual es la precisión. Para los
conceptos de tipo coded o si marcamos la casilla “es grupo” (los concepto
grupo sirven para clasificar conceptos que están relacionados), sale un
recuadro donde añadimos otros conceptos como respuestas o miembros del
grupo. Por ultimo el tipo complex sirven para la entrada de datos complejos, por
ejemplo una radiografía, para que el servidor pueda procesar el tipo de dato
pide que le especifiques un controlador.
79
Figura 23: Pantalla de Creación/Modificación de Concepto
11.4 Creación de Tipos de Encuentro
Cada vez que se rellena un formulario y se envía al sistema, para guardar el
resultado, se genera un encuentro y le añade las observaciones
correspondientes a los datos entrados en el formulario. El tipo de encuentro
nos da información adicional sobre ese encuentro, típicamente se utiliza para
saber el contexto de la recogida de datos, en nuestro caso lo utilizamos para
identificar el formulario con el que se han recogido los datos. Por ejemplo
cuando se genera un encuentro del tipo VITALES sabemos que es porque se
han recogido datos de las constantes vitales del paciente mediante el
formulario Control Vital (figura 13). Para la creación de un tipo de encuentro
desde la pantalla de Administración Avanzada seleccionamos la opción
administrar tipos de encuentro.
Desde la pantalla de Administración podemos crear un tipo de encuentro
seleccionando agregar tipo de encuentro o modificar uno existente
seleccionando el tipo de encuentro deseado.
80
Figura 24: Pantalla de Administración de Tipos de Encuentro
La creación de un tipo de encuentro consiste en darle un nombre, una
descripción y asignar privilegios al tipo de encuentro. La asignación de
privilegios, restringe la posibilidad de crear un encuentro del tipo en cuestión a
un usuario que no disponga de ellos
81
Figura 25: Pantalla de Creación de Tipo de Encuentro
11.5 Creación de Formularios
En OpenMRS los formularios son la herramienta de recolecta de información
básica. Un documento en el cual el usuario introduce datos de manera
estructurada para ser guardados y posteriormente procesados. Para crear un
formulario, partiendo de la pantalla Administración Avanzada seleccionaremos
la opción administrar formularios.
Existen dos manera de agregar un formulario, creando un formulario nuevo o
duplicando la estructura de un formulario existente. En nuestro caso siempre
escogeremos la primera opción. Para modificar un formulario existente solo
tenemos que seleccionar el formulario deseado de la lista, para crear o duplicar
un formulario seccionaremos agregar Formulario o mediante el desplegable
elegiremos el formulario que queramos duplicar y pulsaremos duplicar. (figura
26).
82
Figura 26: Pantalla de Administración de Formularios
En la figura 27 podemos ver la pantalla de creación de un formulario, para
crear un formulario el sistema pide el nombre, versión y tipo de encuentro.
Opcionalmente podemos entrar una descripción, y marcar si esta retirado o
publicado. Un formulario retirado no podrá utilizarse pero queda almacenado en
el sistema, publicar un formulario va en relación con el modulo Form Entry, a
partir de este modulo se puede entrar datos de un formulario desde un
navegador web. Este modulo solo utiliza aquellos formularios que han sido
publicados. Una vez creamos un formulario, a no ser que lo hayamos duplicado
este esta vacío, y carece de una estructura de datos. OpenMRS ofrece
diferentes maneras para dar forma a un formulario.
83
Figura 27: Pantalla de Creación de Formularios
El primer paso a realizar en el proceso de la implementación del formulario
es evaluar las formas principales de hacerlo, existen varias formas.
HTML Form Entry: Este módulo permite programar el formulario a
través del lenguaje HTML, CSS y javascript los formularios creados con
este modulo no son accesibles por software externo al servidor. [29]
XForms: El módulo XForms convierte un formulario OpenMRS en
un XForm. Es la evolución de HTML Form Entry, confiriendo al
diseñador la funcionalidad de crear los formularios sin prácticamente
programar y de forma muy visual e interactiva, enlazado en todo
momento con las características estructurales de OpenMRS. [30]
Rest: La contribución de Avijit Ghosh, añade una nueva
funcionalidad a la aplicación Android Client, esta ahora puede crear
una interfaz dinámica de un formulario a partir de un archivo JSON que
se puede descargar mediante el modulo Rest del Servidor, y sincroniza
el resultado como un encuentro. [31]
La opción escogida ha sido, la de aprovechar la contribución de
desarrollador Avijit Ghosh. Aunque la generación del formulario mediante el
archivo JSON sea simple y no ofrezca muchas opciones, para nuestro proyecto
es suficiente. Tanto HTML Form entry como XForms ofrecen una solución más
completa, pero después de hacer pruebas, ambos son incompatibles con las
versiones más nuevas de la aplicación. El desarrollo para comunicar los
formularios hechos mediante XForms con OpenMRS Android Client se ha
abandonado por parte del equipo de OpenMRS [32]. Existen otras aplicaciones
que permiten la comunicación con el modulo Xforms, la posibilidad de
implementar o incorporar la funcionalidad existe, pero por falta de tiempo y
documentación se ha descartado.
84
Estructura de un formulario
Antes de entrar en detalle en la estructura de un formulario JSON.
Mencionar que para encontrar el uuid de un objeto, solo tenemos que ir a su
pantalla de administración, buscar o seleccionar el objeto de la lista, y en la
pantalla de modificación encontraremos el atributo uuid sombreado en gris.
85
Figura 28: Estructura de un formulario JSON
En la figura 28 aparece la estructura que sigue un archivo JSON. La
composición del archivo es la siguiente
1- Formulario: Es el nodo principal, representa toda la información del
formulario, tiene cuatro atributos: el nombre con el que aparecerá el
formulario en la aplicación móvil, el uuid del tipo de encuentro, el
procesador de formularios que siempre sera “EncounterFormProcessor” y
una lista de paginas (page).
2- Página: Representa una página del formulario o pantalla en la
aplicación, el atributo label sirve para darle titulo a la pagina. Una página
esta dividida en diferentes secciones (section).
3- Seccion: Las secciones de una pagina sirven para agrupar preguntas
o grupos de preguntas que comparten una relación o semejanza, en la
aplicación ajunta las preguntas dentro de un mismo recuadro. Una
sección esta formada por el atributo label para darle titulo y un grupo
(group) de preguntas.
4- Grupo: El grupo representa un concepto grupo de OpenMRS. Tiene
como atributos un tipo (type) que su valor siempre sera “grupo”, un label
para darle un titulo dentro de la sección las opciones de pregunta
(question options) que contienen el atributo rendering que en este caso
siempre sera “group” y el concepto (concept) que su valor es el uuid del
concepto grupo y una lista de preguntas (question).
5- Pregunta: Las preguntas son utilizada para generar observaciones, en
la aplicación se muestra como la frase que genera la pregunta y el campo
donde responde el usuario. El atributo label define la pregunta, las
opciones de pregunta (question options) la observacion y finalmente los
86
atributos type y validators siempre tendrán los valores obs y [] (campo
vacío) respectivamente. Mediante las opciones de pregunta (question
options) se escoge el campo de entrada de datos que aparecerá por
pantalla mediante el atributo rendering, y liga esta respuesta con un
concepto mediante el atributo concept, que es el uuid del concepto en
cuestión.
El atributo rendering puede generar campos de entrada distintos
dependiendo del tipo de respuesta a un concepto. Se distinguen dos
grupos:
Selección: El usuario escoge una respuesta de un conjunto.
Para crear una pregunta de formato selección, el valor del
atributo rendering toma el valor “selection” o “radio”. La
diferencia entre ambos es que selection crea un desplegable
como opción con una de las respuestas ya entradas, y radio
expone las respuestas para que el usuario escoja una. Por
tanto cuando hay una respuesta genérica utilizaremos
selection, y radio cuando no la hay. La selección no permite
una respuesta múltiple, ya que una observación solo permite
una respuesta.
87
Figura 29: Campos de entrada de selección (selection y radio)
Las preguntas con rendering de selección requieren de otro
atributo en el JSON donde se especifican las respuestas
(answers). Este atributo se compone de una lista con los
conceptos que podremos seleccionar como respuesta, cada
respuesta consta de dos atributos: label para dar el titulo y
concept la uuid del concepto respuesta (figura 30).
88
Figura 30: Atributo answers
Entrada Libre: El usuario entra a mano mediante el teclado
virtual la respuesta. Para crear una pregunta de formato de
entrada libre el valor del atributo rendering tomara el valor “text”
o “numeric”, el primero siendo para entrar una respuesta texto y
el segundo una respuesta numérica. En ambos casos se crea
un cuadro de texto para entrar los datos. La respuesta
numérica permite definir un intervalo, añadiendo los atributo
max para el maximo y min para el minimo a las opciones de
pregunta. Esto genera una barra de desplazamiento con la que
podemos escoger la respuesta. Esta ultima opción a no ser que
hayan pocos valores entre el valor máximo y mínimo, es poco
precisa y lenta de utilizar.
89
Figura 31: Rendering de Entrada Libre (text, numeric con intervalo y sin intervalo)
Una vez creados los formularios para guardarlos en el servidor y que se
sincronicen en la aplicación, tenemos que:
1. Acceder a la pantalla de modificación de un formulario.
2. Seleccionar “Gestionar Recursos”.
3. Seleccionar “Agregar Recurso” del tipo de dato texto libre.
4. Seleccionar el handler de UI por defecto.
5. Introducir en nombre json en minúsculas en el campo nombre,
y el valor del JSON en el campo Valor de Recursos y guardar.
Finalmente para que aparezca como opción seleccionable en la aplicación
debemos modificar el código y añadir el nombre del formulario en la lista
loadableEncounterList encontrada en FormListPresenter.java.
90
Figura 32: Guardar JSON de un Formulario
Implementación de entrada de dato tipo texto.
La opción de añadir una respuesta de texto se ha
implementado para este proyecto. La actividad
FormDisplayActivity, es la que de un archivo JSON construye
un formulario.
Para implementar esta funcionalidad se ha añadido al Contract
el método createAndAttachTextQuestionEditText que
implementa la clase FormDisplayFragment. La clase
FormDisplayPagePresenter tiene un método llamado
addQuestion que llama a nuestro método cuando rendering
tiene valor “text”. Se utiliza el recurso LinearLayout de Android.
91
Figura 33: Diseño de la implementación de la respuesta de texto
92
Figura 34: Implementación del método createAndAttachTextQuestionEditText
12. Distribución de pantallas
Muchas de las funcionalidades que la aplicación tenia inicialmente ya no son
necesarias, por eso se ha redistribuido las pantallas, para una mejor
navegabilidad. Se puede encontrar la navegación del nuevo diseño de
pantallas en el anexo 1.
93
13. Casos de uso
En esta sección se listan y explican los casos de uso que se han creado o
modificado para añadir las nuevas funcionalidades al sistema. En los siguiente
casos de uso cuando nos referimos al usuario, nos referimos a un empleado o
colaborador del hospital de Gambo. Todos los casos tienen como precondición
que el usuario debe haber iniciado sesión en la aplicación. En este apartado se
utilizan tecnicismos de Android.
En la clase ApplicationConstants podemos definir la variable
DEFAULT_OPEN_MRS_URL con la url de nuestro servidor para que en la
pantalla de inicio de sesión se conecte por defecto.
13.1 Casos de uso para la asistencia sanitaria sin red:
La aplicación de base, utiliza las visitas como método de organización de la
información sanitaria de un paciente. El problema es, que la aplicación da error
cuando intenta crear una visita mediante el modulo REST. Como segunda
opción decidimos realizar la sincronización mediante encuentros. Para poder
implementar esta funcionalidad, como se vera en los siguientes casos de uso,
se ha tenido que cambiar la forma en que sincronizan y organizan los datos la
aplicación.
94
Descargar Pacientes:
Actor principal: Usuario de la aplicación
Precondiciones: Hay conexión con el servidor
Disparador: El usuario quiere descargar un paciente
Escenario principal de éxito:
1. El usuario pulsa el botón “+”.
2. El usuario introduce el nombre del paciente o de la localidad del paciente.
3. El sistema muestra una lista de pacientes con el mismo nombre o localidad
[Buscar Paciente].
5. El usuario escoge el paciente que quiere descargar.
6. El sistema introduce los datos del paciente en la base de datos.
7. El sistema descarga los encuentros del paciente.
8. El sistema notifica al usuario que el paciente ha sido descargado
correctamente.
Extensiones del caso de uso:
* El usuario cancela la entrada de datos (presiona el botón de atrás de Android
en cualquiera de los pasos antes de descargar el paciente en el punto 5).
1a. Si no hay conexión con el servidor, el botón “+” esta inactivo, y no se
ejecuta el caso de uso.
5a. El usuario realiza una pulsación larga y marca varios o todos los pacientes
a descargar.
5a.1. El usuario pulsa el botón “download”.
5a.2. Por cada usuario marcado, el sistema repite los puntos 6 y 7.
5*. Ha habido un error de descarga, el sistema notifica al usuario.
8a. El usuario escoge otro paciente de la lista a descargar, vuelve al punto 6.
5. Si el dispositivo móvil tiene conexión a la red. El sistema sincroniza la
información con el servidor [Sincronizar Encuentro].
95
La funcionalidad de descargar pacientes ya estaba implementada. Solo se
ha necesitado añadir la sincronización de los encuentros de un paciente
cuando este se descarga al sistema. La actividad para descargar pacientes la
encontramos dentro del paquete lastviewedpatients. Esta actividad utiliza un
recyclerView para listar los pacientes que pueden ser descargados por el
usuario. Cuando el usuario pulsa descargar, se llama al método
downloadSelectedPatients que descarga todos los pacientes seleccionados por
el usuario. Este método crea un PatientApi y llama a la función
downloadPatientByUuid, que descarga el paciente y lo guarda en la base de
datos del móvil. Este método implementa un CallbackListener. Cuando
creamos el CallbackListener y reescribimos el metodo onSucces, este crea un
VisitAPI y llama el método syncBPUPEncounters que se encarga de descargar
y guardar los encuentros del paciente.
96
Figura 35: Diseño de Descargar Pacientes
Sincronizar Paciente:
Actor principal: Sistema.
Precondiciones: El móvil tiene conexión con el servidor.
Disparador: El usuario accede al dashboard de un paciente
Escenario principal de éxito:
1. El usuario escoge un paciente de la lista de la pantalla principal.
2. El sistema descarga todos los encuentros del paciente.
3. El sistema sincroniza los encuentros descargados con los guardados en el
sistema.
5. El sistema muestra el dashboard del paciente.
Extensiones del caso de uso
97
Cuando se accede al dashboard del paciente (PatientDashboardActivity). La
pestaña abierta por defecto es la de details. PatientDashboardDetailsPresenter
es la clase encargada de cargar la información de los detalles del paciente y
sincronizar el paciente con el servidor. El método syncEncounters si hay
conexión crea un objeto visitAPI que llama al método syncBPUPEncounters.
Este descarga todos los encuentros del paciente y los guarda en la base de
datos mediante el objeto EncounterDAO (guarda los nuevos y reemplaza los
existentes).
98
Figura 36: Diseño de Sincronizar Paciente
Listar Encuentros:
Actor principal: Usuario de la aplicación.
Precondiciones: El usuario esta en el dashboard de un paciente.
Disparador: El usuario quiere ver la lista de encuentros del paciente.
Escenario principal de éxito:
1. El usuario escoge la opción Forms.
2. El sistema muestra la lista de encuentros ordenados por fecha.
Se muestra la fecha del encuentro.
El tipo de encuentro.
Localidad donde se ha realizado el encuentro.
Extensiones del caso de uso:
2a. Si el encuentro no esta sincronizado muestra un punto rojo en el objeto de
la lista.
99
Para implementar la lista de encuentros, se ha utilizado un recyclerView. Se
ha creado un Fragment que incluirá la actividad PatientDashboard. El
PatientDashboardEncounterPresenter es el encargado de cargar los
encuentros y Encountercreates de la base de datos (para cargar los
Encountercreates se ha añadido la función getEncountercreates a la clase
Patient). Los encuentros se cargan mediante el EncounterDAO, con la función
findEncountersByPatientUuid que devuelve una lista de Encounters ordenados
de manera descendente por fecha. Si hay conexión a la red, antes de acceder
a la base de datos sincroniza los encuentros. Una vez cargados los encuentros
se pasan al PatientEncountersRecyclerViewAdapter que los guarda en una lista
de objetos. Este se encarga de listar los Encounter y los Encountercreates.
Cuando lista los objetos si es un Encountercreate le añade un circulo rojo para
indicar que no esta sincronizado. Se utiliza instanceof de Java para diferenciar
entre los objetos Encounter y Encountercreates de la lista y crear los
viewHolder (EncounterViewHolder).
100
Figura 37: Diseño de Listar Encuentros
Se considero crear una interfaz ViewHolder para crear dos tipos de
EncounterViewHolder, uno que recibiera un Encounter como parametro y el
otro un Encountercreate, pero se considero que era más sencillo utilizar la
función instanceof.
101
Ver Encuentro:
Actor principal: Usuario de la aplicación.
Precondiciones: El usuario esta visualizando la lista de encuentros de un
paciente.
Disparador: El usuario quiere ver la información de un encuentro.
Escenario principal de éxito:
1. El usuario selecciona un encuentro
2. El sistema muestra la información del encuentro.
Extensiones del caso de uso
2a. Si el encuentro tiene la observación de BMI, muestra el resultado de
diferente color dependiendo del valor.
102
Figura 38: Diseño de Ver Encuentro
Para la visualización de datos de un encuentro se utiliza un recyclerView,
tenemos la particularidad que las observaciones pueden venir de un objeto
Encounter o un objeto Encountercreate. Cuando se crea la actividad
FormViewActivity, esta recibe mediante el Bundle: el id del encuentro a mostrar
y un booleano para indicar si es un Encounter o Encountercreate (que indica si
esta sincronizado). El FormViewPagePresenter se encarga de cargar de la
base de datos la lista de observaciones del encuentro. Como la lista de
observaciones puede ser de objetos Observation o Obscreate, la clase
EncounterAdapter tiene dos constructores y dos formas de crear el objeto
EncounterData. El método textOptions de EncounterData es el encargado de
mostrar el resultado del concepto BMI por código de colores.
Ver Informe:
Actor principal: Usuario de la aplicación.
Precondiciones: El usuario esta en el dashboard de un paciente.
Disparador: El usuario quiere ver el informe de un paciente.
Escenario principal de éxito:
1. El usuario selecciona la opción “charts”
2. El sistema muestra el historial de los valores cardiovasculares recolectados
del paciente.
Extensiones del caso de uso
103
El PatientChartsFragment crea un gráfico con las observaciones que recibe
en el método populateList. Inicialmente populateList tenia como parámetro de
entrada una lista de visitas. Para poder adaptar esta funcionalidad a el
proyecto, la clase PatientDashboardChartsPresenter ahora carga todos los
encuentros en una sola lista de EncounterMethods. EncounterMethods es una
interfaz que implementan la clase Encounter y Encountercreate, y que contiene
los métodos comunes entre las dos clases, así gracias al polimorfismo de
JAVA, se pueden tratar como un solo objeto. También se ha creado la interfaz
ObservationMethods, para las clases Observation y Obscreate con la misma
finalidad. Solo se pueden crear gráficos de observaciones con resultado
numérico, para nuestro proyecto cargamos las observaciones de los conceptos
SystolicBP, DiastolicBP, Pulse(rate/min) y BMI.
104
Figura 39: Diseño Ver Informe
Crear Encuentro:
Actor principal: Usuario de la aplicación
Precondiciones: Se han descargado los formularios. El usuario se encuentra
en el dashboard del paciente.
Disparador: El usuario quiere recoger datos del paciente.
Escenario principal de éxito:
1. El usuario pulsa en Form Entry.
2. El sistema muestra la lista de formularios.
2.1 El usuario escoge un formulario de la lista.
4. El sistema muestra la pantalla de entrada de datos para el formulario.
5. El usuario entra los datos del paciente.
6. El usuario aprieta el botón submit*
7. El sistema guarda la respuesta del formulario como un encountercreate.
8. El sistema añade el encountercreate a la cola de sincronización
Extensiones del caso de uso:
* El usuario cancela la entrada de datos (presiona el botón de atrás de Android
en cualquiera de los pasos antes de darle al submit en el paso 6).
7a. El usuario no ha entrado ningún dato, el sistema lanza un aviso, vuelve al
punto 5.
9. Si el dispositivo móvil tiene conexión a la red. El sistema sincroniza la
información con el servidor.
Cuando la aplicación intentaba sincronizar un Encountercreate sin que este
estuviera relacionado a una visita. La aplicación intentaba generar una visita
en el servidor para el encountercreate. Simplemente se ha comentado el
código del método startNewVisitForEncounter de la clase EncounterService
que creaba objetos visita vacíos en el servidor.
105
13.2 Casos de uso para automatizar la toma de datos:
En este apartado de explican los casos de uso que automatizan ciertos
aspectos de la entrada de datos.
GPS:
Actor principal: Sistema
Precondiciones: El GPS esta conectado o hay conexión WIFI.
Disparador: Se esta rellenando el formulario registro con datos
especiales
Escenario principal de éxito:
1. El sistema calcula la localización
2. El sistema rellena los campos de Latitude y Longitude.
Extensiones del caso de uso
106
Para automatizar la entrada de los conceptos Latitud y Longitud, se ha
creado una clase de utilidad que aprovecha los sensores del dispositivo móvil
para obtener la geolocalización. La clase GPS utiliza la librería Android
LocationManager y implementa la interfaz LocationListener. Para la creación de
un objeto GPS se ha de introducir un GPSListener como parámetro.
GPSListener llama al método onGPSResult, cuando el móvil realiza una lectura
de geolocalización. En la clase FormDisplayPageFragment se crea un objeto
Gps donde el método onGPSResult actualiza los conceptos Latitud y Longitud
de un formulario. El objeto Gps solo realiza una lectura del sensor, y requiere
los permisos ACCESS_FINE_LOCATION y ACCES_COARSE_LOCATION.
107
Figura 40: Diseño de GPS
Tensiómetro Bluetooth
Actor principal: Sistema
Precondiciones: El tensiómetro bluetooth esta emparejado.
Disparador: Se esta rellenando el formulario de vitales
Escenario principal de éxito:
1. El sistema hace 3 mediciones al paciente.
2. El sistema calcula la media de la mediciones.
3. El sistema rellena los campos de Systolic BP, Dyastolic BP y
Pulse(Rate/Minute).
Extensiones del caso de uso
Esta funcionalidad no ha sido implementada por el desarrollador, el
código es de un colaborador del proyecto. Para añadir esta funcionalidad
ha añadido el paquete Bluetooth. Utiliza las librerias BluetoothGatt y
BluetoothDevice de Android. En la clase FormDisplayPageFragment
(clase que construye la vista por pantalla de un formulario), se crea un
boton que al pulsarlo crea un objeto bleWrapper que implementa la
interfaz BleWrapperUiCallbacks. Este objeto recibe las lecturas del
tensiómetro, y mediante el método uiNewValuePressForCharacteristic
guarda las tres primeras lecturas de tensión arterial del paciente, de estas
3 lecturas se hace la media y se guarda como resultado. Para
implementar esta funcionalidad fue necesario el diagrama de tramas
bluetooth del tensiómetro.
108
BMI:
Actor principal: Sistema
Precondiciones:
Disparador: Se esta rellenando el formulario de vitales
Escenario principal de éxito:
1. El usuario ha rellenado los campos Weight(kg) y Height(cm)
2. El sistema calcula BMI (BMI = Weight(kg)*10000/(Height(cm)*Height(cm)).
2. El sistema rellena el campo BMI, dependiendo del valor muestra el resultado
de diferente color..
Extensiones del caso de uso
Para añadir esta funcionalidad se ha añadido el método updateBMI en la
clase FormDisplayPagePresenter. El método
createAndAttachNumericQuestionEditText de FormDisplayPageFragment, crea
un EditText por cada entrada de dato numérico (sin mínimo y máximo
definidos) de un formulario. Cuando se crean los EditText para los conceptos
weight(kg) y height(cm), les añadimos un onTextChangedListener, que detecta
cuando se han entrado datos. Se ha sobrescrito el método afterTextChanged
del Listener para que llame updateBMI, y haga el calculo. La entrada de datos
del concepto BMI esta desactivada, solo se puede entrar datos al concepto
BMI a través de weight(kg) y height(cm).
109
13.3 Casos de uso para Añadir Atributos de Paciente:
El formulario interno de OpenMRS que se usa para registrar un paciente es
insuficiente para el proyecto. Existe la posibilidad de cambiar el formulario de la
aplicación para incluir los nuevos campos. Pero se ha optado por crear un
formulario aparte, ya que aporta más flexibilidad y no requiere cambiar código
del servidor.
CrearPaciente:
Actor principal: Usuario de la aplicación.
Precondiciones: -.
Disparador: El usuario quiere crear un paciente, se encuentra en la pantalla
principal.
Escenario principal de éxito:
1. El usuario escoge la opción register patient.
2. El sistema muestra el formulario de creación de paciente.
3. El usuario entra los datos y pulsa “register patient”.
5. El sistema muestra el formulario de registro con datos especiales
[Crear Encuentro > punto 4]
Extensiones del caso de uso:
* El usuario cancela la entrada de datos (presiona el botón de atrás de Android
en cualquiera de los pasos antes de registrar el paciente en el punto 3).
3a. El usuario ha entrado un país inexistente, o no ha entrado todos los datos
obligatorios
3a.1. El sistema vuelve al punto 2 con los campos erróneos marcados
en rojo y con los datos correctos ya entrados.
110
Este caso de uso ya estaba implementado solo se ha modificado el método
goToPatientDashboardActivity de la clase AddEditPatientFragment. Ahora
cambia a la actividad FormDisplayActivity para que el usuario rellene un
formulario de registro especial, antes de acabar el registro simple del paciente.
Ver Atributos Especiales del Paciente:
Actor principal: Usuario de la aplicación.
Precondiciones: El usuario esta en el dashboard de un paciente.
Disparador: El usuario quiere ver los últimos valores del ultimo encuentro de
factores de riesgo o campos de registro especiales.
Escenario principal de éxito:
1. El usuario escoge la opción “+ INFO” o “RISK”.
2. El sistema muestra la información del ultimo encuentro del tipo indicado.
(+INFO para campos de registro especiales, RISK para factores de
riesgo
Extensiones del caso de uso:
2a. Si aun no ha tenido un encuentro del tipo indicado, aparece “none” por
pantalla.
111
El constructor de PatientStaticEncounterFragment recibe como parámetro el
tipo de encuentro a mostrar. La clase PatientStaticEncounterPresenter carga de
base de datos el encuentro más reciente del tipo de encuentro especificado en
el constructor de PatientStaticEncounterFragment (primero se busca en los
Encountercreate mediante el método getLatestEncountercreate, y si no ha
encontrado ninguno busca en la tabla de Encounters mediante el método
LoadLastEncounterFromDB). Una vez cargado el encuentro se muestra por
pantalla con el método showStaticEncounter que recibe por parámetro un
EncounterMethod.
112
Figura 41: Diseño Ver Atributos Especiales del Paciente
13.4 Casos de uso para Buscar Paciente por Localidad:
Cuando un usuario va a una aldea de los alrededores, necesita descargar
los pacientes de esa aldea al sistema para tener su historial. La aplicación
incluye la búsqueda de pacientes del servidor por nombre. Para no tener que
descargar los pacientes uno a uno, se incluye la búsqueda de pacientes por
ciudad.
Buscar Paciente:
Actor principal: Usuario de la aplicación.
Precondiciones: La aplicación tiene conexión con el servidor
Disparador: El usuario ha introducido texto para buscar pacientes
Escenario principal de éxito:
1. El sistema descarga los pacientes cuyo nombre contiene el texto o localidad
contiene el texto
Extensiones del caso de uso
113Figura 42: Diseño de Buscar Paciente
Para implementar esta funcionalidad se ha añadido la llamada
getPatientByCity en el interfaz RestAPI. La actividad lastViewedPatient tiene un
recycleView para listar los pacientes que se pueden descargar. El método
findPatients de la clase lastViewedPatientsPresenter es el encargado de poblar
la lista de pacientes de la clase LastViewedPatientRecycleViewAdapter. El
método findPatients hace dos llamadas al servidor: una para descargar los
usuarios cuyo nombre es parecido al parámetro de entrada, y otra para
descargar los usuarios que viven en una ciudad cuyo nombre es parecido al
parámetro de entrada del usuario, luego inserta el resultado de la primera
llamada a la segunda para eliminar repetidos. De momento no se puede hacer
uso de esta funcionalidad porque descargar los pacientes por localidad no
funciona por parte del servidor, confirmado por la comunidad de OpenMRS.
Aun así, una vez actualicen el modulo Rest debería funcionar.
114
13.5 Casos de uso para generar un aviso de tratamiento:
Cuando un usuario de la aplicación sin conocimiento medico, tiene un
encuentro donde se mide la presión arterial del paciente, este no le puede
diagnosticar un tratamiento. Cuando la aplicación detecte la presión
cardiovascular alta enviara una notificación para que el usuario le comunique al
paciente si necesita tratamiento.
Generar Aviso:
Actor principal: Sistema
Precondiciones:
Disparador: Ha acabado el caso de uso [TENSIOMETRO BLUETOOTH]
Escenario principal de éxito:
1. La lectura del tensiómetro indica que el paciente requiere tratamiento.
2. El sistema informa al usuario que el paciente requiere tratamiento.
Extensiones del caso de uso
Para añadir esta funcionalidad se a añadido el método notifyTreatment en la
clase FormDisplayFragment. El método
createAndAttachNumericQuestionEditText de FormDisplayPagePresenter, crea
un EditText por cada entrada de dato numérico (sin mínimo y máximo
definidos) de un formulario. Cuando se crean los EditText para los conceptos
systolicBP y diastolicBP les añadimos un onTextChangedListener, que detecta
cuando se han entrado datos. Se ha sobrescrito el método afterTextChanged
del Listener para que llame a needsTreatment. El método needsTreatment
provisionalmente lanza una notificación si la tensión sistólica es igual o superior
a 140 mm Hg y/o la tensión diastólica es igual o superior a 90 mm Hg.
115
14. Implementación
En este apartado se muestra el código más relevante para implementar los
diferentes casos de uso.
14.1 Implementación de la asistencia sanitaria sin red:
Descargar Pacientes:
Cuando se selecciona los pacientes a descargar, se llama a
downloadPatients. Este método itera por cada paciente seleccionado y llama al
116
Figura 43: LastViewedPatientsRecycleViewAdapter downloadPatient
método downloadPatient. Por cada paciente descargado se descargan sus
encuentros. El método syncBPUPEncounters implementa las llamadas de
RestAPI para descargar los encuentros de los pacientes, si la respuesta del
servidor no es errónea, se ejecuta el método syncBPUPEncounters de
EncounterDAO.
(Llamada para descarga formularios)
117
Figura 45: RestApi getEncounters
Figura 44: visitAPI syncBPUPEncounters
El método syncBPUPEncounters de EncounterDAO, guarda los encuentros
descargados en base de datos reemplazando aquellos que ya existían.
118
Figura 46: EncounterDAO syncBPUPEncounters
Sincronizar Paciente:
Cuando se accede a PatientDashboardActivity,
PatienDashboardDetailsPresenter llama al método synchronizePatient.
Si hay conexión se llama al método syncEncounters que ejecuta el método
syncBPUPEncounters de visitAPI (figura 44).
119
Figura 47: PatientDashboardPresenter synchronizaPatient
Listar Encuentros:
Cuando se crea la clase PatientDashboardEncounters, su método de
actividad onResume llama a subscribe. Subscribe inicializa el
PatientEncountersRecycleViewAdapter con el método setEncountersToDisplay,
el PatientEncountersRecycleViewAdapter lista los encuentros de un paciente.
120
Figura 48: PatientDashboardEncountersPresenter subscribe()
Los Encountercreates se cargan desde la clase Patient con el método
getEncountercreates.
121
Figura 49: Patient getEncountercreates
Los encuentros se cargan mediante el método findEncountersByPatientUuid
de la clase EncounterDAO.
122
Figura 50: EncounterDAO findEncountersByPatientID
El método onBindViewHolder de PatientsEncounterRecycleViewAdapter, es
el encargado de listar los diferentes objetos. Utiliza instanceof para diferenciar
entre objetos Encounter y Encountercreates.
123
Figura 51: PatientsEncounterRecycleViewAdapter onBindViewHolder
Ver Encuentro:
FormViewActivity es la actividad que lista la información de un encuentro. La
lista se forma a partir de un recycleView. La particularidad de la actividad es
que puede listar las observaciones de un encuentro independientemente si es
Encounter o Encountercreate. El método setAdapter de FormViewPresenter
recibe un booleano que indica si el encuentro es un Encounter o un
Encountercreate, y crea el Adapter (EncounterAdapter) en base a esa
información.
Como se puede observar el EncounterAdapter tiene un constructor con dos
parametros: uno corresponde a la lista de Observations de un Encounter y el
otro a la lista de Obscreate de un Encountercreate.
124
Figura 52: FormViewPresenter setAdapter
Para el ViewHolder (EncounterData), también se ha creado dos
constructores que diferencian el tipo de objeto Observation / Obscreate.
125
Figura 53: EncounterData class
Ver Informe:
Para visualizar el informe se ha aprovechado código del fragmento
PatientChartsFragment que construía un gráfico lineal a partir de las
observaciones de las visitas del tipo VITALS. Se ha aprovechado en concreto el
código del método populateList, este extrae una lista de observaciones y
fechas con las que la clase VitalsListAdapter construye el gráfico.
126
Figura 54: PatientChartsFragment populateList
En el método de la figura 54, para tratar a un Encounter y un
Encountercreate como un solo objeto (son muy parecidos), se ha creado una
interfaz que ambas clases implementan con métodos comunes para ambas.
Se ha aplicado el mismo diseño para las clases Observation y Obscreate.
127
Figura 55: EncounterMethods interfaz
Figura 56: ObservationMethods interfaz
14.2 Implementación toma de datos automatizada:
GPS:
Para la captura de datos de geolocalización se ha creado una clase auxiliar
(Gps). Esta clase implementa la librería LocationManager que utiliza los
sensores del móvil. Para crear un objeto Gps es necesario pasar por
parámetro un GPSListener, el método onGPSResult del GPSListener se llama
cuando se realiza una lectura de los sensores.
128
Figura 57: GPS Listeners
En la figura 58 aparece la inicialización de un objeto Gps.
129
Figura 58: FormDisplayPageFragment Inicialización Gps
BMI:
Para calcular el BMI se ha añadido un textChangedListener a los conceptos
Height(cm): y Weight (Kg): y cuando estos cambian de valor se actualiza el
valor del concepto BMI.
130
Figura 59: FormDisplayPageFragment updateBMI
14.3 Implementación de Atributos de Paciente:
Ver Atributos Especiales del Paciente:
Para ver un encuentro creado de un formulario no variante, se busca en
base de datos el encuentro del tipo indicado más reciente.
PatientStaticEncounterFragment es el fragmento de PatientDashboard que se
encarga de mostrar este tipo de formulario por pantalla. El método de
PatientStaticEncounterPresenter, loadLastEncounterFromDB primero intenta
cargar el Encountercreate más reciente, y si no existe, intenta cargar el
Encounter más reciente.
Una vez cargado se muestra por pantalla.
131
Figura 60: PatientStaticEncounterPresenter loadLastEncounterFromDB
Método para cargar el Encountercreate más reciente.
132
Figura 62: PatientStaticEncounterPresenter getLatestEncountercreate
Figura 61: PatientStaticEncounterFragment showStaticEncounter
Método para cargar el Encounter más reciente.
133
Figura 63: EncounterDAO getStaticFormEncounter1
14.4 Implementación de Buscar Paciente por Localidad:
Buscar Paciente:
Para buscar paciente por ciudad se ha añadido una nueva llamada a
RestAPI.
El método findPatients (figura 65) se lanza cuando el usuario quiere
descargar pacientes del servidor. Descarga aquellos pacientes con nombre
igual al campo entrado o que viven en la ciudad con nombre igual al campo
entrado
134
Figura 64: RestAPI getPatientsByCity
135
Figura 65: LastViewedPatientsPresenter findPatiens
14.5 Implementar aviso de tratamiento:
Generar Aviso:
Para generar un aviso se ha añadido un textChangedListener a los
conceptos SystolicBP y DyastolicBP en la clase FormDiplayFragment,
encargada de mostrar el formulario por pantalla. Cuando estos cambian de
valor, si SystolicBP es igual o superior a 140 mm Hg y/o DyastolicBP es igual o
superior a 90 mm Hg se lanza el método notifyTreatment.
136
Figura 66: FormDisplayPageFragment notifyTreatment
15. Integración de Conocimientos
Para la realización del proyecto los conocimientos necesarios han sido:
1. Análisis de requisitos: Los primeros pasos antes de desarrollar ha sido
capturar los requisitos y funcionalidades que debe cumplir la aplicación.
2. Identificación de procesos de negocio: Para avanzar en el proyecto ha
sido necesario identificar como estructura los procesos OpenMRS, y
como están formados, por ejemplo: el proceso de crear un encuentro o
visita.
3. Diseño de sistemas de información: Tener nociones en diseño de
sistemas de información me ha permitido hacer la ingeniería inversa de
la aplicación para después modificar esta.
4. Programación Android: La aplicación esta basada en Android, por lo que
para modificar-la he tenido que aprender Android.
5. APIrest: El servidor utiliza una APIrest para comunicar objetos con
servicios externos, en nuestro caso con la aplicación.
6. Bases de datos: La aplicación funciona sobre una base de datos
relacional. Ha sido necesarios los conocimientos para hacer consultas
adicionales y extraer datos necesarios.
7. Diseño del software: He aplicado conocimientos en diseño del software
para definir los casos de uso, y ayudarme a implementar las
funcionalidades.
137
16. Justificación de las Competencias Técnicas
CSI2.2: Concebir, desplegar, organizar y gestionar sistemas y servicios
informáticos, en contextos empresariales o institucionales, para mejorar los
procesos de negocio; responsabilizarse y liderar su puesta en marcha y la
mejora continua; valorar su impacto económico y social.
La idea de implementar OpenMRS es para mejorar los procesos en el
cuidado de la hipertensión y así evitar posibles futuras complicaciones.
Reduciendo el numero de victimas de cardiopatias y otras enfermedades
derivadas. El sistema móvil permite actuar sobre problemas sociales como la
falta de identificación y falta de medios de transporte.
CSI2.5: Demostrar conocimiento y capacidad de aplicación de los sistemas
de información empresarial (ERP, CRM, SCM, etc.).
En el proyecto estoy aplicando un sistema de información, en este caso un
sistema de registro medico electrónico. Con el objetivo de mejorar la asistencia
sanitaria.
CSI4.2: Participar activamente en el diseño, la implementación y el
mantenimiento los sistemas de información y de comunicación.
En el proyecto parto de una sistema de información real y es necesario
modificarlo para que se ajuste a los requerimientos del cliente.
138
17. Leyes y Regulaciones
Se ha de tener en cuenta que los datos tratados en este proyecto son de
carácter personal (información concerniente a personas físicas identificadas o
identificables incluidos los que sirvan a fines exclusivamente estadísticos), y
estos estarán sujetos a la legislación vigente de protección de datos de Etiopía.
Etiopía no se encuentra entre los países con autoridad de protección de
datos, por lo que no se podrán exportar los datos a dichos países sin haber
llegado a un previo acuerdo con las autoridades competentes. En este
apartado se expondrán las leyes según el reglamento Español la Ley Orgánica
15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal
(LOPD) que cumple con el futuro Reglamento General de Protección de Datos
(GDPR) que entrara en vigor el 25 de mayo, 2018. [35]
En referencia al reglamento exigido por la LOPD el sistema tiene en cuenta
varios puntos:
1. Debe informarse a todos los pacientes que dispongan de registro de salud
o historia clínica que los datos personales y clínicos de los que se disponen se
van a almacenar, y el uso que se le dará ha dichos datos asimismo del derecho
que tiene sobre esos datos (oposición, acceso, rectificación o
cancelación ). [36][37]
El sistema guardara información de carácter personal y ante cualquier deseo
de un paciente, esta podrá ser accedida, rectificada o borrada.
2. Los datos de carácter personal objeto de tratamiento no podrán usarse
para finalidades incompatibles con aquellas para las que los datos hubieran
sido recogidos. No se considerará incompatible el tratamiento posterior de
139
éstos con fines históricos, estadísticos o científicos pero es aconsejable
comunicárselo al paciente. [36][37]
En la aplicación solo se guardaran aquellos datos que sean relevantes para
el tratamiento y diagnostico de la hipertensión.
3. Todos los datos personales y clínicos que se recojan deben ser de la
mayor calidad, debiendo almacenarse aquellos de mayor relevancia para poder
llevar a cabo una adecuada labor médica y administrativa en la clínica. [36][37]
En la aplicación a medida de simplificar formularios, solo recogerá la
información estrictamente necesaria para el diagnostico y tratamiento de la
hipertensión.
4. Los datos deben estar guardados de manera segura. [36][37]
El sistema cuenta con una identificación de usuario y contraseña para
acceder a la plataforma, y la comunicación vía APIrest con token [38].
5. Sólo con el consentimiento expreso y por escrito del afectado podrán ser
objeto de tratamiento los datos de carácter personal que revelen la ideología,
afiliación sindical, religión y creencias. Esta prohibido crear ficheros que solo
contengan información del carácter discutido en este punto. [36][37]
La aplicación guardara datos de la raza, etnia y religión de los pacientes.
Estos son relevantes e irán guardados con información general de los
pacientes.
140
Conclusiones y opinión personal
El uso del sistema desarrollado en este proyecto, supondría una gran mejora
en cuanto al cuidado de la hipertensión en Gambo frente a la situación actual.
La aplicación se probo en terreno en un estado inicial donde la aplicación móvil
servia como herramienta de recolecta de datos, para después visualizarlos
desde el servidor. El cliente no obtuvo el resultado esperado, pero sirvió para
concretar con las funciones que debía cumplir el sistema, que esta segunda
versión cumple.
En sitios sin cobertura de red y poco accesibles la flexibilidad de utilizar
tecnología móvil frente a un sistema fijo abre un abanico de oportunidades.
Como sistema autónomo la aplicación desarrollada es capaz de capturar todos
los datos necesarios para que un medico calificado pueda ofrecer un
diagnostico. Ademas esta ofrece una serie de ventajas como la portabilidad, los
sensores y la comunicación con dispositivos de medición portátiles.
En nuestro caso la automatización de procesos, como comprobar los niveles
de tensión arterial, ofrece mejoras a nivel no solo de prevención de error
humano, sino que habilita a personas sin conocimientos médicos a poder
ofrecer un servicio sanitario para el hospital.
Aunque hay poca documentación del sistema OpenMRS. Es un sistema muy
utilizado y tiene una comunidad activa. Como medida de sincronizarse en
cualquier sistema OpenMRS la aplicación podría utilizar el modulo Rest para
crear los formularios automáticamente en un futuro.
Creo que la utilización de tecnologías móviles, para el tratamiento de
enfermedades especificas en países con pocos recursos es un primer paso
para augmentar cobertura sanitaria.
141
La realización de este proyecto a mi personalmente me ha servido para
colaborar en un proyecto solidario donde se realiza la labor humanitaria de
mejorar la calidad de vida de personas, utilizando nuevas tecnologías para
ofrecer un mejor cuidado de la hipertensión y ampliando la cobertura sanitaria
mediante un sistema de atención sanitaria electrónico del que a día de hoy ya
me siento orgulloso.
142
Referencias
[1]: Nir Menachemi, Taleah H Collum “Benefits and drawbacks of electronic
health record systems” Risk Manag Healthc Policy.2011;4: 47–55.
[2]: Bates DW, Cohen M, Leape LL, Overhage MJ, Shabot MM, Sheridan,
“Reducing the Frequency of Errors in Medicine Using Information Technology.
Journal of the American Medical Informatics Association” 2001;8(4):299–308. ,.
[3] Klaus A. Kuhn, James R. Warren(Ph.D.), Tze-Yun Leong “Medinfo
2007:Proceedings of the 12th World Congress on Health” 2007, 382-383
[4] Las 10 principales causas de defunción, enero 2017, url:
http://www.who.int/mediacentre/factsheets/fs310/es/
[5] OMS, “Información general sobre la hipertensión en el mundo
Una enfermedad que mata en silencio, una crisis de salud pública mundial”
2013, 17-21
[6] Hypertension: the silent killer spreading across Africa
julio 23, 2017, url: https://theconversation.com/hypertension-the-silent-killer-spreading-across-africa-80290
[7] WHO African Region: Ethiopia url:
http://www.who.int/countries/eth/coop_strategy/en/index1.html
[8] Xaume Olleros, “La batalla por la salud en Etiopía” Octubre 3, 2016, url:
https://elpais.com/elpais/2016/09/30/planeta_futuro/1475244224_123846.html
143
[9] Data World Bank Statistics: Rural population (% of total population), 2016
url: https://data.worldbank.org/indicator/SP.RUR.TOTL.ZS
[10] Hospital Gambo, Acerca De, url: https://www.gambohospital.org/acercade/
[11] OpenMRS, “About OpenMRS”, url: http://openmrs.org/about/
[12] Burke W. Mamlin, M.D., Paul G. Biondich, M.D., M.S., Ben A. Wolfe, Hamish Fraser, M.B. Ch.B., M.Sc.,Darius Jazayeri, Christian Allen, Justin Miranda, and William M. Tierney, M.D., “Cooking Up An Open Source EMR For Developing Countries: OpenMRS – A Recipe For Successful Collaboration” 2006 , 529-533
[13] vistA, “About vistA” http://worldvista.org/AboutVistA
[14] openEMR, “OpenEMR Wiki Home Page ” url:http://www.open-emr.org/wiki/index.php/OpenEMR_Wiki_Home_Page
[15] oneTouchEMR, url: https://www.onetouchemr.com/
[16] Peter Groen, OpenMRS Installations & Users in Africa, Agosto18, 2013
url:http://www.openhealthnews.com/hotnews/openmrs-installations-users-africa
[19] “OpenDataKit” ”url: https://opendatakit.org/
[20] Michael Downey, “ OpenMRS-jr”, Marzo 15, 2014
url: https://wiki.openmrs.org/display/docs/OpenMRS-jr
[21] OpenMRSWIki, Tensin Zonkyi, Encero 1, 2015 url:
https://wiki.openmrs.org/display/docs/Mobile?
preview=/3345795/12681219/openmrs-midlet.jad
144
[22] Kamil Kalfas, Yusum Karim, “OpenMRS 2.x Android Client”, Enero 15,
2017,
url:https://wiki.openmrs.org/display/projects/OpenMRS+2.x+Android+Client
[24]https://medium.com/@cervonefrancesco/model-view-presenter-android-
guidelines-94970b430ddf
[25]Fawwaz Yuhzran, Diciembre 16, 2017 url:
https://wiki.openmrs.org/display/docs/REST+Module
[29] Fawwaz Yuzran, Diciembre 16, 2017 url:
https://wiki.openmrs.org/display/docs/HTML+Form+Entry+Module
[30] Fawwaz Yuzran, Diciembre 16, 2017 url:
https://wiki.openmrs.org/display/docs/XForms+Module
[35] AEPD, url:
http://www.agpd.es/portalwebAGPD/internacional/Proteccion_datos_mundo/ind
ex-ides-idphp.php
145
Bibliografía
[17] iitgweb, “ Ingenieria del Software, Ingenieria en Sistemas
Computacionales”
Mayo 29,2016 url: https://ittgweb.wordpress.com/2016/05/29/descomposicion-
modular/
[18] OpenMRS, sync module, Diciembre 15, 2017
url: https://wiki.openmrs.org/display/docs/Sync+Module
[23] https://es.wikipedia.org/wiki/Java_(lenguaje_de_programaci%C3%B3n)
[26]”Bases de Datos Relacionales”, url:
https://www.ibm.com/support/knowledgecenter/es/SSEPGG_8.2.0/com.ibm.db2
.udb.doc/admin/c0004099.htm
[27] “Modelo Entidad Relacion” Octubre 6, 2011 url:
https://es.wikipedia.org/wiki/Modelo_entidad-relaci%C3%B3n
[28] Android Developers, “SQLiteOPenHelper”, url:
https://developer.android.com/reference/android/database/sqlite/SQLiteOpenHe
lper.html
[31] Avijit Ghosh, url: https://issues.openmrs.org/browse/AC-181
[32] https://talk.openmrs.org/t/weighing-mobile-options-form-entry-
offlinecaching/12109
[33] Ing. Del Software,Modelo Evolutivo,
url:”https://ingsoftware.weebly.com/modelo-evolutivo.html”
146
[34] Avijit Ghosh, https://developer.android.com/training/material/lists-
cards.html?hl=es-419
[36] «BOE»núm.298, de 14/12/1999, url: “https://www.boe.es/buscar/act.php?id=BOE-A-1999-23750”
[37] LOPD,proteccion de datos por profesionales de la salud, url: “https://ayudaleyprotecciondatos.es/2016/07/25/cesion-de-datos-entre-profesionales-de-la-salud/” [38] Seguridad en APIs móviles: método de autenticación de acceso básica
HTTP y OAuth 2.0 url:”https://bbvaopen4u.com/es/actualidad/seguridad-en-
apis-moviles-metodo-de-autenticacion-de-acceso-basica-http-y-oauth-20”
147
Anexo 1
148
149
150
151
152