Tesis Final

FACULTAD DE INGENIERÍA Y ARQUITECTURA
ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS
AUTOMATIZACIÓN DEL PROCESO DE CONTROL DE TERAPIAS

PARA LA DISTRIBUCIÓN DE PACIENTES EN AGENTES DE
TRATAMIENTOS EN EL ÁREA DE MEDICINA FÍSICA DE LA
CLÍNICA SAN JUDAS TADEO
PARA OPTAR
EL GRADO ACADEMICO DE BACHILLER EN INGENIERÍA DE COMPUTACIÓN
Y SISTEMAS
PRESENTADA POR
BAZALAR CONTRERAS, HECTOR MARTIN
ASTOCONDOR FARRO, HUGO ISMAEL
ASESOR(ES):
ING. RUBÉN GARCIA FARJE
MG. VICTOR ZAMBRANO
LIMA, PERÚ
2019
1
Agradecimientos
Agradezco a Dios ante todo por tantas bendiciones. A mis padres, por el apoyo
continuo e incondicional que me brindan y por ser mi inspiración para seguir
adelante.
Bazalar Contreras, Hector Martin
Agradezco a Dios por cada detalle y momento durante la realización de la tesis,

llenando mi camino de sabiduría y bendición. A mis padres, por sentirse
orgulloso de mi como persona y ser mi motivación para cada día salir adelante.
Astocóndor Farro, Hugo Ismael
2
ÍNDICE
RESUMEN.............................................................................................................................................8
CAPITULO I. PLANTEAMIENTO DEL PROBLEMA.......................................................................9
1.1 Descripción de la situación problemática...............................................................................9
1.2 Formulación del problema....................................................................................................12
1.3 Objetivos de la investigación................................................................................................13
1.4 Justificación de la investigación...........................................................................................14
1.5. Limitaciones del estudio.......................................................................................................19
CAPITULO II. MARCO TEORICO....................................................................................................20
2.1 Antecedentes de la Investigación..........................................................................................20
2.2 Bases teóricas.......................................................................................................................22
2.3 Definición de términos básicos.............................................................................................31
CAPITULO III. METODOLOGIA......................................................................................................33
3.1 Diseño metodológico............................................................................................................33
CAPITULO IV. DESARROLLO.........................................................................................................38
4.1 Desarrollo metodológico......................................................................................................38
4.2 Requerimientos – Historias de usuarios................................................................................46
4.3 Diseño y Desarrollo técnico..................................................................................................98
4.4. Plan de Pruebas...................................................................................................................104
CAPITULO V. RESULTADOS........................................................................................................108
5.1 Cronograma........................................................................................................................113
CAPITULO VI. DISCUSIÓN............................................................................................................114
CONCLUSIONES..............................................................................................................................115
RECOMENDACIONES....................................................................................................................116
REFERENCIAS BIBLIOGRAFICAS...............................................................................................117
ANEXOS...........................................................................................................................................122
Índice de Figuras
3
Figura 1. Fases del Desarrollo Metodológico SCRUM...........................................................33
Figura 2. Tablero o Dashboard (Project Charter) - IceScrum..................................................38
Figura 3. Equipo - IceScrum....................................................................................................39
Figura 4. Características - IceScrum........................................................................................40
Figura 5. Product Backlog – IceScrum (Parte 1).....................................................................41
Figura 6. Product Backlog – IceScrum (Parte 2).....................................................................42
Figura 7. Sprint 1 (IceScrum)..................................................................................................43
Figura 10. Sprint 4 (IceScrum)................................................................................................45
Figura 11. Diagrama de Casos de Uso: Seguridad..................................................................48
Figura 12. Historia de Usuario (IceScrum) - Iniciar Sesión....................................................49
Figura 13. Prototipo HU Iniciar Sesión...................................................................................50
Figura 14. Historia de Usuario (IceScrum) - Buscar Perfil.....................................................50
Figura 15.Historia de Usuario (IceScrum) - Mantener Perfil..................................................51
Figura 16. Prototipo HU Mantener Perfil................................................................................52
Figura 17. Historia de Usuario (IceScrum) - Buscar Usuario..................................................52
Figura 18. Historia de Usuario (IceScrum) - Mantener Usuario.............................................53
Figura 19. Prototipo HU Mantener Usuario............................................................................54
Figura 20. Prototipo HU Mantener Usuario - Agregar............................................................54
Figura 21. Prototipo HU Mantener Usuario - Editar...............................................................54
Figura 22. Diagrama de Casos de Uso: Mantenimiento..........................................................55
Figura 23. Historia de Usuario (IceScrum) - Mantener Terapias............................................56
Figura 24. Prototipo HU Mantener Terapias...........................................................................57
Figura 25. Prototipo HU Mantener Terapias - Agregar...........................................................57
Figura 26. Historia de Usuario (IceScrum) - Buscar Agente de Tratamiento.........................58
Figura 27. Historia de Usuario (IceScrum) - Mantener Agente de Tratamiento.....................59
Figura 28. Prototipo HU Mantener Agente de Tratamiento....................................................60
Figura 29.Prototipo HU Mantener Agente de Tratamiento - Agregar.....................................60
Figura 30. Historia de Usuario (IceScrum) - Buscar Zona de Tratamiento.............................61
Figura 31. Historia de Usuario (IceScrum) - Mantener Zona de Tratamiento........................62
Figura 32. Prototipo HU Mantener Zona de Tratamiento.......................................................63
Figura 33. Prototipo HU Mantener Zona de Tratamiento - Agregar.......................................63
Figura 34. Historia de Usuario (IceScrum) - Buscar Consultorio...........................................64
Figura 35. Historia de Usuario (IceScrum) - Mantener Consultorio.......................................65
Figura 36. Prototipo HU Mantener Consultorios.....................................................................66
Figura 37. Prototipo HU Mantener Consultorio - Agregar......................................................66
Figura 38. Historia de Usuario (IceScrum) - Buscar Diagnostico CIE10...............................67
Figura 39. Historia de Usuario (IceScrum) - Mantener Diagnósticos CIE-10........................68
Figura 40. Prototipo HU Mantener Diagnostico CIE-10.........................................................69
Figura 41. Historia de Usuario (IceScrum) - Buscar Pacientes...............................................69
Figura 42. Historia de Usuario (IceScrum) - Mantener Pacientes...........................................70
Figura 43. Prototipo HU Mantener Paciente...........................................................................71
Figura 44. Prototipo HU Mantener Paciente – Agregar..........................................................71
Figura 45. Historia de Usuario (IceScrum) - Buscar Terapista...............................................72
Figura 46. Historia de Usuario (IceScrum) - Buscar Doctores................................................73
Figura 47. Historia de Usuario (IceScrum) - Buscar Personal................................................74
4
Figura 48. Historia de Usuario (IceScrum) - Mantener Personal............................................75
Figura 49. Prototipo HU Mantener Personal...........................................................................76
Figura 50. Prototipo HU Mantener Personal – Agregar..........................................................77
Figura 51. Diagrama de Casos de Uso: Reporte de Terapias..................................................77
Figura 52. Historia de Usuario (IceScrum) - Reportar Ingresos en el Área............................78
Figura 53. Prototipo HU Reportar Ingresos en el Área...........................................................79
Figura 54. Historia de Usuario (IceScrum) - Listar Cronograma de Atención a Terapias......79
Figura 55. Requerimiento Funcional -H23 (“Listar Cronograma de Atención a Terapias”). .80
Figura 56. Historia de Usuario (IceScrum) - Reportar Atenciones en el Área........................80
Figura 57. Prototipo HU Reportar Atenciones en el Área.......................................................81
Figura 58. Diagrama de Casos de Uso: Atender Paciente.......................................................81
Figura 59. Historia de Usuario (IceScrum) - Reservar Cita....................................................82
Figura 60. Prototipo HU Reservar Cita...................................................................................83
Figura 61. Prototipo HU Reservar Cita - Nueva Cita..............................................................83
Figura 62. Historia de Usuario (IceScrum) - Pagar Atención..................................................84
Figura 63. Prototipo HU Pagar Cita.........................................................................................85
Figura 64. Historia de Usuario (IceScrum) - Registrar Horarios de Atención........................86
Figura 65. Prototipo HU Registrar Horarios de Atención.......................................................87
Figura 66. Historia de Usuario (IceScrum) - Visualizar Antecedentes en el Área..................87
Figura 67. Diagrama de Casos de Uso: Gestión Terapias.......................................................88
Figura 68. Historia de Usuario (IceScrum) – Atender Pacientes.............................................89
Figura 69. Prototipo HU Atender Pacientes............................................................................90
Figura 70. Prototipo HU Atender Paciente - Registrar Atención a Terapias del Paciente......90
Figura 71. Historia de Usuario (IceScrum) - Registrar Historia Clínica.................................91
Figura 72.Prototipo HU Registrar Historia Clínica.................................................................92
Figura 73. Diagrama de Casos de Uso: Control de Terapias...................................................92
Figura 74. Historia de Usuario (IceScrum) - Asignar Zonas de Tratamiento..........................93
Figura 75. Prototipo HU Asignar Zona de Tratamiento..........................................................94
Figura 76. Historia de Usuario (IceScrum) - Generar Cronograma de Atención....................95
Figura 77. Diagrama de Casos de Uso: Evaluación de Terapias.............................................96
Figura 78. Historia de Usuario (IceScrum) - Tratar al Paciente..............................................96
Figura 79. Flujo de Trabajo de las Historias (IceScrum).........................................................98
Figura 80. Eventos en SCRUM (Jerónimo Palacios Associates)............................................99
Figura 81. CPANEL..............................................................................................................100
Figura 82. Arquitectura CPNEL............................................................................................101
Figura 83. Base de Datos de la Clínica..................................................................................102
Figura 84. Producto Mínimo Viable......................................................................................103
Figura 85. Introducción del Plan de Pruebas.........................................................................104
Figura 86. Plan de Pruebas - Pruebas de Funcionalidad........................................................105
Figura 87. Plan de Pruebas - Pruebas de interfaz de Usuario................................................105
Figura 88. Plan de Pruebas - Pruebas de base de datos y de rendimiento.............................106
Figura 89. Plan de Pruebas – Pruebas de Carga, recuperación ante fallos, seguridad y control
de accesos................................................................................................................................106
Figura 90. Plan de Pruebas - Pruebas de Configuración........................................................107
Figura 91. Encuesta 1.............................................................................................................108
Figura 92. Encuesta 2.............................................................................................................109
Figura 93. Encuesta 3.............................................................................................................109
5
Figura 94. Encuesta 4.............................................................................................................110
Figura 95. Encuesta 5.............................................................................................................110
Figura 96. Encuesta 6.............................................................................................................111
Figura 97. Encuesta 7.............................................................................................................111
Figura 98. Cronograma del Proyecto.....................................................................................113
Figura 99. Cartón Azul para Terapias – Parte 1....................................................................123
Figura 100. Cartón Azul para Terapias - Parte 2...................................................................124
Figura 101. Cronograma de Atención por Agente de Tratamiento.......................................125
Figura 102. Compromiso de Pago de Terapias......................................................................126
Figura 103. Análisis de Involucrados....................................................................................127
Figura 104. Árbol de Problemas............................................................................................128
Figura 105. Árbol de Objetivos.............................................................................................129
Figura 106. Ishikawa..............................................................................................................130
Figura 107. Proceso de Negocio AS – IS..............................................................................131
Figura 108. Ficha de Proceso de Negocio.............................................................................132
Figura 109. CANVAS............................................................................................................133
Figura 110. Proceso Propuesto TO – BE...............................................................................134
Figura 111. Módulo de Gestión de Terapias TO – BE..........................................................135
Figura 112. Módulo de Control de Terapias TO – BE..........................................................136
Figura 113. Módulo de Evaluación de Terapias TO – BE.....................................................137
Figura 114. Proceso de Atención al Paciente TO – BE.........................................................138
Figura 115. Elementos de Notación.......................................................................................139
Figura 116. Relación de Actores del Sistema........................................................................140
Figura 117. Diagrama de Casos de Uso Estructurado del Sistema........................................141
Figura 118. Elaboración del Backlog Inicial.........................................................................142
Figura 119. Priorización de Casos de Uso del Sistema.........................................................143
Figura 120. Pruebas Unitarias................................................................................................144
Índice de Tablas
6
Tabla 1. Detalle y Costo de Hardware.....................................................................................15
Tabla 2. Detalle de Software....................................................................................................16
Tabla 3. Costo de Recursos Humanos.....................................................................................17
Tabla 4. Costo de horas hombre...............................................................................................18
Tabla 5. Costo de Servicio de Terceros...................................................................................18
Tabla 6. Ingreso anual del servicio de atención.......................................................................18
Tabla 7. Roles de SCRUM del proyecto..................................................................................34
Tabla 8. Requerimientos No Funcionales del Sistema............................................................46
Tabla 9. Requerimientos Funcionales - H1 ("Iniciar Sesión").................................................49
Tabla 10. Requerimiento Funcional -H2 (“Buscar Perfil”).....................................................50
Tabla 11. Requerimiento Funcional -H3 (“Mantener Perfil”).................................................51
Tabla 12.Requerimiento Funcional -H4 (“Buscar Usuario”)...................................................52
Tabla 13. Requerimiento Funcional -H5 (“Mantener Usuario”).............................................53
Tabla 14. Requerimiento Funcional -H6 (“Mantener Terapias”)............................................56
Tabla 15. Requerimiento Funcional –H7 (“Buscar Agente de Tratamiento”).........................58
Tabla 16. Requerimiento Funcional -H8 (“Mantener Agente de Tratamiento”).....................59
Tabla 17. Requerimiento Funcional –H9 (“Buscar Zona de Tratamiento”)............................61
Tabla 18. Requerimiento Funcional –H10 (“Mantener Zona de Tratamiento”)......................62
Tabla 19. Requerimiento Funcional –H11 (“Buscar Consultorio”).........................................64
Tabla 20. Requerimiento Funcional –H12 (“Mantener Consultorio”)....................................65
Tabla 21. Requerimiento Funcional -H13 (“Buscar Diagnostico CIE-10”)............................67
Tabla 22. Requerimiento Funcional -H14 (“Mantener Diagnostico CIE-10”)........................68
Tabla 23. Requerimiento Funcional -H14 (“Buscar Pacientes”).............................................69
Tabla 24. Requerimiento Funcional -H16 (“Mantener Pacientes”).........................................70
Tabla 25. Requerimiento Funcional -H17 (“Buscar Terapistas”)............................................72
Tabla 26.Requerimiento Funcional -H18 (“Buscar Doctores”)...............................................73
Tabla 27.Requerimiento Funcional -H19 (“Buscar Personal”)...............................................74
Tabla 28.Requerimiento Funcional –H20 (“Generar Historia Clínica al Paciente”)...............75
Tabla 29. Requerimiento Funcional -H21 (“Mantener Personal”)..........................................76
Tabla 30. Requerimiento Funcional -H22 (“Reportar Ingresos en el Área”)..........................78
Tabla 31. Requerimiento Funcional -H24 (“Reportar Atenciones en el Área”)......................80
Tabla 32. Requerimiento Funcional -H25 (“Reservar Cita”)..................................................82
Tabla 33. Requerimiento Funcional -H26 (“Pagar Atención”)................................................84
Tabla 34. Requerimiento Funcional -H27 (“Registrar Horarios de Atención”)......................86
Tabla 35. Requerimiento Funcional -H28 (“Registrar Horarios de Atención”)......................88
Tabla 36. Requerimiento Funcional –H29 (“Atender Pacientes”)...........................................89
Tabla 37. Requerimiento Funcional –H30 (“Registrar Historia Clínica al Paciente”)............91
Tabla 38. Requerimiento Funcional –H31 (“Asignar Zonas de Tratamiento”).......................93
Tabla 39. Requerimiento Funcional -H26 (“Generar Cronograma de Atención a Terapias”) 95
Tabla 40. Requerimiento Funcional -H26 (“Tratar al Paciente”)............................................97
7
RESUMEN
La investigación de esta tesis va desde el análisis, diseño e implementación de un
sistema que realice los procesos de gestión de citas y control de terapias de los pacientes del
área de medicina física y rehabilitación. En la actualidad el área de medicina física y
rehabilitación no cuenta con un sistema que pueda optimizar la gestión de los procesos de
citas y terapias que se realizan en esta área, la realización del proceso conlleva a la
elaboración de cronogramas para la atención de las terapias programadas en cierto horario
respectivo según el tratamiento que se le indique.
La finalidad de un Sistema de Información de Salud es gestionar de una manera
eficiente los recursos, funcionales, materiales y personales, con los que cuentan los centros
médicos y, sobre todo, tratar de manera eficiente y precisa la información que se genera en el
ámbito hospitalario. El manejo de información médica automatizada puede mejorar
significativamente la asistencia al paciente, reduciendo errores al acelerar el flujo de órdenes
y resultados, y haciendo disponible una información más completa para la toma de decisiones.
8
CAPITULO I.
PLANTEAMIENTO DEL PROBLEMA
1.1 Descripción de la situación problemática
La labor de la clínica es “Satisfacer con eficiencia, calidad y alto nivel
profesional a las necesidades en el ámbito de la salud de todas aquellas personas que
requieran atención médica.” (Clínica San Judas Tadeo, s.f.).
Según Ramos y Espadín (2018, p.2) nos menciona que, “Los trastornos
muscoesqueléticos (TME) suponen un 45% de las lesiones profesionales”. Por ello, es
considerado como el trastorno con mayor registro de atención.
Asimismo, Zambrano, V. (2017, p.16) nos comenta que “Tomando en cuenta
que la apreciación que tenga el paciente de la calidad del servicio va a influir para sus
expectativas, este proceso debe tener un constante seguimiento y modificación de la
calidad que (…) ofrece”. Debido a que una buena atención se traduce en la
satisfacción del paciente.
El Instituto Nacional de Estadística e Informática ([INEI], 2018, p.9) argumenta
que “Una de las principales razones por las que el 23,4% de pacientes no acude a un
establecimiento de salud es la distancia de este y demora en la atención.”. Siendo la
demora en la atención uno de los principales factores que afecta el servicio del
paciente, es necesario evaluar este proceso y examinar que factores dilatan en la
Clínica San Judas Tadeo.
Gracias a la tesis de Grandez Aguilar, J.C. (2017, p.4), entendemos lo siguiente
“Las personas constantemente suelen quejarse por el tiempo que llevan haciendo cola
en los establecimientos de salud, esto se ocasiona en el área de admisión al momento
9
de realizar la búsqueda y apertura de una historia clínica ya que no todos los
establecimientos cuentan con una herramienta que les facilite dicho procedimiento y
por ello lo realizan de forma manual.” De esta manera, evidenciamos que el tiempo de
espera es dilatado en el proceso que inicia en el área de admisión desde la apertura de
la historia clínica hasta la atención de los pacientes en sus diferentes agentes de
tratamientos, lo cual afecta la calidad atención brindada al paciente.
El tener la documentación manualmente perjudica y aumenta el tiempo de
espera tanto a los pacientes como los trabajadores del área dentro del área de
Medicina Física y Rehabilitación donde se muestran las evidencias (Anexos 1,2,3,4).
Según Herrera Trujillo, L (2018) en su tesis nos dice que, en la empresa de su caso de
estudio se pudo observar un deficiente trabajo en equipo, además de una deficiente
comunicación entre áreas, muchas veces generado por un bajo compromiso con los
objetivos de la empresa y por no tener procesos estandarizados que les den soporte a
(…) la empresa. (p.1).
Asimismo, “las consecuencias que este problema trae para la administración de
pacientes son los siguientes: duplicación de historias clínicas con la misma
identificación de pacientes, riesgos de pérdida de información (historias clínicas),
atraso en la búsqueda, etc.” (La Rosa y Mendoza, 2017, p.12)
Referido a la Historia Clínica Electrónica, según Alvarado Mendoza, M (2017,
p.9), “(…), se reducen los costos de los hospitales por lo tanto reduce los costos para
los pacientes y se pierde menos tiempo en las consultas y seguimiento de los
pacientes, beneficiando tanto al personal de salud como a los pacientes.” Esto quiere
decir que, a menor material o recursos utilizados, como el papel, menor será el costo
para la atención del paciente y para el centro de salud. Según el Instituto Nacional de
10
Estadística e Informática ([INEI], 2018b, p.24) “la fabricación de papel y cartón
ondulado y de envases de papel y cartón aumentó en 17,86%, por producción de
sacos, cajas de cartón, papel corrugado y diversos cartones para el mercado interno.”
No obstante, “Esto podría evitarse con el uso de computadoras para lograr una
mejor efectividad en el rendimiento de los trabajadores del área respecto al
diagnóstico, seguimiento y tratamiento de los pacientes”. (Alvarado Mendoza,
M.C,2017, p.2).
La realización de la documentación manual previamente mencionada, también
se traduce en un inconcluso seguimiento digital en el servicio de terapias, demorando
el proceso y generando un riesgo de pérdida de datos o documentos. Según Veliz
Prudencio, L. J. (2017, p.23) nos comenta en su tesis que, su proceso comienza al
generar la relación de los pacientes. Luego, se ha de buscar la historia indicada, lo
cual tomará un tiempo indeterminado de búsqueda. Debido a que existe la posibilidad
de que la historia no esté en su lugar. De no ser encontrada generará un problema
tanto para el paciente como para el centro de salud, pues se habrá perdido el historial
con el registro de todas sus citas previas.
11
1.2 Formulación del problema
Actualmente la excesiva documentación en el proceso es tedioso. Además, las
demoras en las atenciones causan la necesidad de agilizar las labores del área. Para
esto el problema consiste en la deficiencia del proceso de control de terapias de los
pacientes del área de medicina física de la Clínica San Judas Tadeo.
1.2.1. Problema General
¿Cómo mitigar las dificultades encontradas en la gestión de distribución
de pacientes en el área de medicina física y rehabilitación de la Clínica San
Judas Tadeo?
1.2.2. Problemas Específicos
a) ¿Cómo se identificarán las principales dificultades en el proceso de control
de terapias del área de Medicina Física y Rehabilitación?
b) ¿De qué manera se espera optimizar el proceso de control de terapias del
área de Medicina Física y Rehabilitación?
c) ¿Cuál es la importancia de optimizar el proceso de control de terapias del
área de Medicina Física y Rehabilitación?
d) ¿Cuál es el nivel de participación de la secretaria en el proceso de control
de terapias en el área de medicina física y rehabilitación de la clínica san
judas Tadeo?
e) ¿De qué manera corroborar el progreso del proceso de control de terapias?
12
1.3 Objetivos de la investigación
1.3.1. Objetivo General
El objetivo de la investigación es mejorar el proceso de control de terapias
de los pacientes de medicina física y rehabilitación de la Clínica San Judas
Tadeo para la distribución en los diferentes agentes de tratamientos que se
realizan en el área.
1.3.2. Objetivos Específicos
 Analizar el actual proceso de control de terapias del área.
 Automatizar el actual proceso de control de terapias del área.
 Reducir el tiempo en la atención del paciente para la distribución en su
agente de tratamiento a realizarse.
 Incrementar la comunicación con la secretaria durante el proceso de control
de terapias.
 Realizar y documentar el nuevo proceso automatizado de la metodología
SCRUM para el desarrollo del sistema web.
13
1.4 Justificación de la investigación
1.4.1. Importancia de la investigación
El desarrollo de este proyecto está orientado a la automatización de las
actividades manuales del control de terapias, puesto que disminuir las quejas
de los pacientes por la demora en las atenciones para los tratamientos de las
terapias y errores en los cronogramas de los pacientes en el área de medicina
física son de vital importancia, así mismo la elaboración de cronogramas de
terapias de los pacientes, se realizan en cuadernos y el control de las sesiones
de los pacientes toman tiempo en obtener la información, con esto.
El desarrollo del proyecto obtendrá varios beneficios como la
disminución de consumo de papel ayudando la mejora del medio ambiente, la
inexistencia de duplicidad y la obtención de información de los pacientes de
una manera rápida y de manera eficaz, gracias a esto nos ayudará a recibir más
pacientes en menos tiempo. En la presente investigación se definirá la
metodología SCRUM como herramienta para el desarrollo ágil en la
implementación del desarrollo software, teniendo como apoyo la norma
técnica peruana 29110 para tener calidad en el desarrollo y gestión del
proyecto; además de las distintas herramientas de software que ayudaran a la
realización de los sistemas requeridos para la automatización del proceso
propuesto.
14
1.4.2. Viabilidad de la investigación
1.4.2.1. Viabilidad técnica
Para el desarrollo del proyecto, en el enfoque técnico, se cuenta con
los recursos tecnológicos (Hardware) nos ayudará para que el desarrollo
sea el adecuado, se presentará a continuación en la siguiente tabla:
Tabla 1. Detalle y Costo de Hardware
Herramientas Descripción Detalles Cantidad

Procesador Intel® Core™ Equipo compatible para el
i7-6500U CPU @ 2.50 desarrollo de la aplicación
Laptop ASUS GHz. 16 GB de RAM. 2GB y realización de pruebas. 1
de Video. Disco duro de También, como repositorio
1000 GB. Windows 10 pro. de la documentación.
Procesador Intel® Core™ Equipos virtualizados que
i5-3200U CPU @ 2.50 serán utilizados como
Servidor de
GHz. 16 GB de RAM. 2GB servidores de aplicaciones 1
Aplicaciones
de Video. Disco duro de tanto en testing y
1000 GB. Windows 10 pro. producción.
Procesador Intel® Core™ Equipos virtualizados que
i5-3200U CPU @ 2.50 serán utilizados como
Servidor de Base de
GHz. 16 GB de RAM. 2GB servidores de base de datos 1
Datos
de Video. Disco duro de tanto en testing y
1000 GB. Windows 10 pro. producción.
Elaboración: Los autores
A nivel de desarrollo del sistema la empresa CLINICA SAN
JUDAS TADEO nos otorga los siguientes softwares los cuales son
manejados por el área de Sistemas.
También se requiere el uso de algunos softwares para el desarrollo
del proyecto como muestra la siguiente tabla:
15
Tabla 2. Detalle de Software
Herramientas Descripción
Frameworks
Framework CSS basado en el diseño responsiva.
Bootstrap
Framework de PHP diseñado para desarrolladores que necesitan un kit de

CodeIgniterherramientas simple y elegante para crear aplicaciones web con todas las
funciones. Nos detalla la arquitectura MVC.
Motor de Base de Datos donde almacenaremos y tomaremos toda la
Microsoft
información de los datos maestros y datos secundarios del sistema
SQL Server
principal.
MySQL Motor de Base de Datos donde almacenaremos toda la información de los
Workbench datos maestros y datos secundarios del sistema.
Herramienta donde se realizará la automatización de los procesos de
SublimeText
gestión de citas y control de terapias.
Bizagi
Herramienta donde se realizará el proceso del negocio y propuesto.
Modeler
Es un servidor web HTTP de código abierto, para plataformas Unix,
Apache
Microsoft Windows, Macintosh y otras.
Paquete de software libre, que consiste principalmente en el sistema de
XAMP gestión de bases de datos MySQL, el servidor web Apache y los intérpretes
para lenguajes de script PHP y Perl.
IBM-
RATIONAL Esta herramienta nos ayudara a modelar las diferentes actividades que
SOFTWARE realizaran los actores del sistema con los diferentes módulos, así
ARCHITECT obteniendo graficas que describan el proceso en sí.
(RSA)
PHP, HTML,
CSS, Frameworks de ayuda en programación orientada a objetos, listas,
JAVASCRIPT, interacciones entre las páginas web que nos ayudaran a hacerlas más
JQUERY, dinámicas, más rápidas y del agrado del usuario.
AJAX, JSON
Es una herramienta web que nos ayuda a poder realizar la gestión de
SMARTSHEETproyecto ayudándonos a colaborar entre los usuarios registrados
elaborando diagramas de GANT y más.
Herramienta web que nos ayudara en la gestión del proyecto de manera
ICE-SCRUM
ágil y según la metodología de desarrollo SCRUM.
16
1.4.2.2. Viabilidad operativa
Para realizar este proyecto se cuenta con la disponibilidad de tiempo
de las personas involucradas en el desarrollo de este.
Para el desarrollo del proyecto, actualmente se contará con el
siguiente recurso principal, el cual se va a encargar de la gestión y
desarrollo del proyecto.
 Astocóndor Farro, Hugo
 Bazalar Contreras, Héctor
Tabla 3. Costo de Recursos Humanos
RECURSOS HUMANOS
Equipo de Salario S/. % de Mese
Responsable Total
Trabajo Mensual Part. s
Team Scrum -
Bazalar Contreras, Hector S/. 1,000 50% 12 S/.6,000
Analista
Team Scrum -
Programador
Team Scrum -
DBA
Team Scrum -
Astocóndor Farro, Hugo S/. 1,000 50% 12 S/.6,000
Analista
Team Scrum -
Astocóndor Farro, Hugo S/. 1,000 50% 12 S/.6,000
Programador
Scrum Master -
Líder del Mestas, Mario S/. 4,000 20% 12 S/.9,600
Proyecto
S/.28,80
TOTAL
0
1.4.2.3. Viabilidad Económica
Para estimar un costo referencial del sistema, este proyecto se
realizará en las instalaciones de la empresa con equipos de la empresa y
utilizando software de licencia gratuita, no se requerirá de inversión inicial,
solo de recursos humanos antes mencionados, también se toman en cuenta
factores como servicios a terceros y salarios de los involucrados.

17
Tabla 4. Costo de horas hombre
COSTO X COSTO POR SALDO SALDO

ROL TIEMPO
TIEMPO DIA MENSUAL ANUAL
DOCTOR 5H S/ 20.00 S/ 100.00 S/3,000.00 S/36,000.00

SECRETARIA 8H S/ 4.17 S/ 33.33 S/1,000.00 S/12,000.00
TERAPISTA 6H S/ 2.50 S/ 15.00 S/1,500.00 S/18,000.00
TOTAL S/66,000.00
Tabla 5. Costo de Servicio de Terceros
COSTO X COSTO COSTO

SERVICIO COSTO X DIA
PROCESO MENSUAL ANUAL
ENERGIA
S/ 2.00 S/ 56.00 S/ 1,456.00 S/17,412.00
ELECTRICA
INTERNET S/ 4.00 S/ 97.07 S/ 2,912.00 S/34,944.00
IMPRESIÓN S/ 0.50 S/ 14.00 S/ 364.00 S/ 4,368.00
TOTAL S/56,724.00
Tabla 6. Ingreso anual del servicio de atención
GANANCIAS
COSTO X MENSUAL (1200
SERVICIO DIARIAS (40 ANUAL (14,400)
SERVICIO ATENCIONES)
ATENCIONES)
ATENCION DE
S/ 35.00 S/ 700.00 S/ 21,000.00 S/ 252,000.00
CITAS
ATENCION DE
TERAPIAS (12 S/ 120.00 S/ 2,400.00 S/ 72,000.00 S/ 864,000.00
SESIONES)
TOTAL S/ 1,116,000.00
18
A partir de la implementación del proyecto se busca que la cantidad
de atenciones en el área se incremente entre un 40% a 50%
aproximadamente en un año, para ello la cantidad de citas debe aumentar
1680 y 1800 que, calculando con el precio promedio, estaríamos hablando
de un ingreso de S/. 280,000 para el año 1.
1.5. Limitaciones del estudio
Las limitaciones identificadas para el desarrollo del proyecto son las
siguientes:
 Actualmente el proceso no se encuentra adecuadamente documentado,
pero aun así se lleva a cabo de forma diaria.
 La disponibilidad de la información de los pacientes que se atienden en
el área de medicina física depende del área de archivos, es decir, la
información del área de archivos se circunscribe a la que se recibe en el
área de medicina física de la Clínica San Judas Tadeo.
 Solo podrán entrar las personas que están involucradas directamente
con el área de medicina física y rehabilitación.
 Tiempo de Desarrollo.
19
CAPITULO II.
MARCO TEORICO
2.1 Antecedentes de la Investigación
Según Loreto Vergara B. (2010, p.282), nos dice en su artículo que “La
especialidad de Medicina Física y rehabilitación, como la conocemos actualmente,
tiene su origen en Estados Unidos, a comienzos del siglo XX, con la figura del médico
Dr. Frank Crucen, graduado en la Jefferson Medical Collage en Filadelfia en 1921.”,
por consiguiente, a lo largo de los años se vio afectado el proceso nos solo por el
cambio tecnológico sino por el crecimiento de los procesos en dicha área.
2.1.1. Antecedentes Nacionales
Según Gutarra C. &Quiroga, R. (2014) en su tesis “Implementación de
un sistema de historias clínicas electrónicas para el centro de salud Perú 3ra
zona” el cual nos relata sobre su investigación que con la implementación del
sistema mejora la calidad de atención del paciente, satisfaciéndolos.
Estandarizando y almacenando información de los pacientes de forma
estructurada evitando duplicidad de información y mejorando la gestión de las
historias clínicas.
Carrión, V. (2015) en su tesis “Desarrollo de una aplicación web basada
en el modelo vista controlador para la gestión de las historias clínicas de los
pacientes en el centro de salud de San Jerónimo” nos cuenta sobre su
investigación que con la implementación del sistema de gestión de historia
20
clínica optimiza la gestión de las HC de los pacientes y reduce el tiempo de
búsqueda de los expedientes médicos de los pacientes.
Ruiz, G. (2017) en su tesis “Desarrollo e implementación de proceso de
cajas en Clínica Belen-Sanna “nos relata que la implementación del proceso
ayudó a regularizar las cajas, disminuyendo los errores y que ya no se generen
pérdidas de dinero.
2.1.2. Antecedentes Internacionales
Según Albán, J & Fuentes, Y. (2018) en su tesis “Desarrollo de
aplicación web para la gestión de historial médico de pacientes de la clínica
San Miguel”, esta tesis se realizó con el objetivo de sistematizar los datos de
los pacientes que se encuentran en papelas, archivos y reducir la cantidad de
reclamos generados por los pacientes. El sistema tiene una interfaz de rápido
acceso, facilitando la gestión administrativa, obteniendo información confiable
cuando se necesite generar cuadros estadísticos, ayudando en la toma de
decisiones para la mejora de la atención clínica en beneficio de la comunidad.
Pairazaman, L. & Vigo, E. (2017) en su tesis “Sistema de información
web para el mejor control y acceso a las historias clínicas de los pacientes del
centro de salud Jequetepeque” nos cuenta sobre los resultados de la
investigación, el uso del sistema web agiliza los procesos de atención a los
pacientes, obteniendo información actualizada, realiza el registro de HC,
reportes y consultas con mayor rapidez utilizando menor tiempo de respuesta
en el registro de HC.
21
2.2 Bases teóricas
2.2.1. Medicina Física y Rehabilitación
Según la Unión Europea de Médicos Especialistas (UEMS) nos relata
que la Medicina Física y Rehabilitación es una especialidad médica consciente
de la prevención, diagnóstico, tratamiento y manejo rehabilitador de las
personas con condiciones médicas discapacitantes y comorbilidad (Barca
Fernández, I, 2018, p.24)
2.2.2. Fisioterapia
Según Castillo, C. (2017) “La fisioterapia, también conocida como
rehabilitación funcional, es un programa diseñado para ayudar al paciente a
mejorar o mantener sus capacidades funcionales (por ejemplo, actividades de
la vida diaria). La fisioterapia incluye el desarrollo de la fuerza, flexibilidad y
resistencia, así como el aprendizaje de la biomecánica apropiada (por ejemplo,
la postura) para lograr la estabilidad de la columna y prevenir las lesiones.”
(p.15)
2.2.3. Historia Clínica
Según Villaruel (2015). La historia clínica es un documento con
información médica que se usa para enjuiciar la relación médico - paciente,
aquí se recoge datos importantes para una óptima atención. La información
que contiene la historia clínica puede ser de: tipo asistencial, información
obtenida por medio de exámenes físicos luego de inspeccionar al paciente; de
22
tipo comentada, preguntando al paciente enfermedades familiares, problemas
de salud anteriores datos de talla y peso; información complementaria como
exámenes de sangre, exámenes de orina, test de alergias de medicinas y
alimentos”. (Chiquilín & Vásquez, 2018, p.41)
2.2.4. Historia Clínica Electrónica
Según Espinoza Ñaña, J (2015) no comenta que la HCE “Es la historia
clínica cuyo registro unificado y personal, multimedia, se encuentra contenido
en una base de datos electrónica, registrada mediante programas de
computación y refrendada con firma digital del profesional tratante.” (p.09)
2.2.5. CIE-10
Según Anso Borda, I. “La CIE-10 es la clasificación de referencia de
todos los países para la notificación de causas de defunción. Son varios los
países que han realizado modificaciones clínicas de la CIE-10 para cubrir sus
respectivas necesidades de información clínico asistencial.” (p.11)
2.2.6. Servicios Web
Según Barzanallana (2012), “Una aplicación web es básicamente una
manera de facilitar el logro de una tarea específica... en la web, a diferencia de
un sitio web estático que es más bien una herramienta, no menos importante,
para la comunicación… La aplicación web por lo tanto permite al usuario
interactuar directamente contigo y tus datos, todo en forma personalizada, para
llevar a cabo esa tarea específica” (Arias Muñoz, M, 2018, p.28)
2.2.7. PHP
Como lo menciona Arce, A (2018) “PHP es un lenguaje diseñado para
crear contenido HTML. PHP puede ser ejecutado de tres formas: en un
23
servidor web, a través de la línea de comandos, o mediante un cliente GUI. El
lenguaje puede ejecutarse en prácticamente todos los sistemas operativos
actuales y en múltiples servidores web. Este también soporta una amplia
variedad de bases de datos y cuenta con múltiples librerías para ejecutar
procesos comunes” (p.3)
2.2.8. Microsoft SQL Server
Según Quintanilla, V (2017) SQL Server “Es un sistema para la gestión
de bases de datos producido por Microsoft basado en el modelo relacional. Sus
lenguajes para consultas son T-SQL y ANSI SQL. Microsoft SQL Server
constituye la alternativa de Microsoft a otros potentes sistemas gestores de
bases de datos como son Oracle, PostgreSQL o MySQL.” (p.21)
2.2.9. Framework CodeIgniter
Como lo menciona Álvarez, M (s.f) “Es un programa o aplicación web
desarrollada en PHP para la creación de cualquier tipo de aplicación web bajo
PHP. Es un producto de código libre, libre de uso para cualquier aplicación.
Como cualquier otro framework, CodeIgniter contiene una serie de librerías
que sirven para el desarrollo de aplicaciones web y además propone una
manera de desarrollarlas que debemos seguir para obtener provecho de la
aplicación.” (p.2)
2.2.10. Metodologías Agiles
Según Vergara, R (2015) “El desarrollo ágil de software enfatiza la
colaboración cercana entre el equipo de desarrollo y los expertos del negocio,
comunicación directa y en persona (face to face) 43 evitando la documentación

24
escrita, entrega de avances desplegables con valor de negocio, equipos
pequeños y organizados, y formas para elaborar el código de tal manera que la
inevitable dependencia y cohesión de los requerimientos no sea un problema.
El término ágil aplicado al desarrollo de software tiene como objetivo esbozar
los valores y principios que deberían permitir a los equipos un desarrollo y la
rápida respuesta a los cambios que pueden surgir a lo largo del proyecto
mucho más veloz que con algún proceso de desarrollo tradicional que están
caracterizados por su rigidez y dirigidos a la documentación que se genera al
finalizar cada actividad desarrollada.” (p.43)
2.2.11. SCRUM
Según la investigación (Figueroa et al., 2008) “Sobre Metodologías
Tradicionales vs. Metodologías Ágiles”, Scrum es un proceso ágil y liviano
que sirve para administrar y controlar el desarrollo de software. El desarrollo
se realiza en forma iterativa e incremental (una iteración es un ciclo corto de
construcción repetitivo). Cada ciclo o iteración termina con una pieza de
software ejecutable que incorpora nueva funcionalidad. Las iteraciones, en
general, tienen una duración entre 2 y 4 semanas. Scrum se utiliza como marco
para otras prácticas de ingeniería de software como RUP o Extreme
Programming. Scrum se focaliza en priorizar el trabajo en función del valor
que tenga para el negocio, maximizando la utilidad de lo que se construye y el
retorno de inversión.” (Babilón, L & Zamorano, C, 2016, p.26)
25
2.2.12. Elementos del SCRUM
2.2.12.1. Sprint
Según Shojaee, H (s.f.) “El producto se construye de forma incremental
en base a períodos de tiempo cortos, denominados Sprints. Los Sprints
tienen una duración fija y determinada, entre 1 y 4 semanas; mejor cuanto
más cortas, es decir mejor 1 semana que 4. Todos los Sprints tienen la
misma duración a lo largo del proyecto, porque se rigen según el principio
de “timeboxing”: cada elemento tiene un tiempo asignado que termina
cuando acaba este tiempo.” (p.6)
2.2.12.2. Definición de Hecho
Según Shojaee, H (s.f.) “El equipo de trabajo tiene que encontrar una
definición para el concepto de "hecho" -Done-. Cada incremento del
producto debe cumplir dicha definición de "hecho" para darlo por
finalizado, y poder ser entregado. La definición de "hecho" puede aplicar a
requisitos, sprints, releases, entornos... es decir, en cualquier elemento sobre
el que se pueda plantear la cuestión de "¿está finalizado y puede continuar
al paso siguiente del proyecto? “Son las condiciones para considerar el
elemento terminado con éxito”. (p.7)
2.2.12.3. Ciclo de Scrum
Según Shojaee, H (s.f.) “El proyecto se ejecuta en base a sprints, de
duración fija, que se planifican al arrancar cada sprint, con las Daily cada
26
24 horas. En cada sprint se resuelve o construye el Sprint backlog, que se
integra al final del sprint con el resultado de sprints anteriores,
conformando un producto entregable.” (p.7)
2.2.12.4. Productos
Según Shojaee, H (s.f.) “Incremento de producto: un subconjunto del
producto que puede ser entregado, con componentes integrados, que
funciona. Backlog de producto: la lista de requisitos del producto,
ordenadas por su prioridad. Backlog del Sprint: el plan detallado para el
desarrollo durante el sprint siguiente.” (p.8)
2.2.12.5. Pilares Básicos
Según Shojaee, H (s.f.) “Transparencia: los interesados comparten un
entendimiento común del proyecto, de la visión, y de lo que significa
"hecho". Inspección: a través de los artefactos o entregables (incremento de
producto, backlog de producto y backlog del sprint). Adaptación: a través de
las reuniones en Scrum”. (p.8)
2.2.12.6. Reunión Daily Scrum
Según Shojaee, H (s.f.) “Es una reunión con un timebox de 15 minutos,
donde el equipo de trabajo sincroniza sus actividades y crea el plan para las
siguientes 24 horas. En esta reunión, cada miembro del equipo de trabajo
debe responder a 3 preguntas: ¿Qué hice ayer? ¿Qué haré hoy? ¿Hay algún
impedimento que me evite conseguir mis objetivos hasta mañana?” (p.9)
27
2.2.12.7. Reunión Sprint Review
Según Shojaee, H (s.f.) “Es la reunión que se mantiene al final de cada
Sprint para inspeccionar el Incremento de Producto, y adaptar el Backlog
del producto si es necesario. Durante el Sprint Review, el equipo de trabajo
muestra al resto de interesados qué se ha conseguido en el sprint” (p.9)
2.2.12.8. Reunión Retrospectiva del Sprint
Según Shojaee, H (s.f.) “Se inspecciona cómo ha ido el sprint, en lo
referente a las personas, sus relaciones, el proceso, y las herramientas. Se
identifican y ordenan los asuntos más importantes, tanto los que fueron
bien, como los que suponen una mejora potencial. Se crea un plan para
implementar las posibles mejores detectadas” (p.9)
2.2.13. Roles del SCRUM
Según Trigas, G (s.f)
“Son las personas que están comprometidas con el proyecto y el proceso
de Scrum.
• Product Owner: Es la persona que toma las decisiones, y es la que
realmente conoce el negocio del cliente y su visión del producto. Se encarga
de escribir las ideas del cliente, las ordena por prioridad y las coloca en el
Product Backlog.
• ScrumMaster: Es el encargado de comprobar que el modelo y la
metodología funciona. Eliminará todos los inconvenientes que hagan que el
proceso no fluya e interactuará con el cliente y con los gestores.
28
• Equipo De Desarrollo: suele ser un equipo pequeño de unas 5-9
personas y tienen autoridad para organizar y tomar decisiones para conseguir
su objetivo. Está involucrado en la estimación del esfuerzo de las tareas del
Backlog.
Aunque no son parte del proceso de Scrum, es necesario que parte de la
retroalimentación dé la salida del proceso y así poder revisar y planear cada
sprint.
• Usuarios: Es el destinatario final del producto.
• Stakeholders: Las personas a las que el proyecto les producirá un
beneficio. Participan durante las revisiones del Sprint.
• Managers: Toma las decisiones finales participando en la selección de
los objetivos y de los requisitos.” (p.36)
2.2.14. Artefactos Scrum
Según Palacio, J (2015)
“Pila del producto: (product backlog) lista de requisitos de usuario, que a
partir de la visión inicial del producto crece y evoluciona durante el desarrollo.
Pila del sprint: (sprint backlog) lista de los trabajos que debe realizar el
equipo durante el sprint para generar el incremento previsto.
Incremento: resultado de cada sprint.” (p.22)
2.2.15. Project Charter
Según Oviedo, L (2016)
“El acta de constitución de proyecto o Project Charter es un documento que
formalmente autoriza un proyecto o fase. El acta de constitución define la
29
razón del proyecto y asigna un gerente de proyectos y su nivel de autoridad
para el proyecto.” (p. 33)
2.2.16. IceScrum
Según Instituto Tecnológico Superior de Lerdo ([ITSL] ,2019)
“iceScrum es una plataforma tecnológica de manejo y gestión de proyectos en
línea que ofrece un conjunto de herramientas al equipo, integrando
digitalmente los artefactos scrum y la gestión de eventos.” (p.192)
2.2.17. UML
Según Ferré G & Sánchez M (s.f) “UML (Unified Modeling Language)
es un lenguaje que permite modelar, construir y documentar los elementos que
forman un sistema software orientado a objetos” (p.01)
2.2.18. JQUERY
Según Álvarez M (2011) jQuery es uno de los complementos más
esenciales para el desarrollo web, usado en millones de sitios en toda la web,
ya que nos facilita mucho el desarrollo de aplicaciones enriquecidas del lado
del cliente, en Javascript, compatibles con todos los navegadores. Para los que
se inician, conviene aclarar que jQuery no es un lenguaje, sino una serie de
funciones y métodos de Javascript. (p.02)
2.2.19. JSON
Según Peñas J & Reyero L (2012) JSON es un formato ligero para
intercambio de datos que surge como alternativa a XML en AJAX. Se emplea
habitualmente en entornos donde el tamaño del flujo de datos entre cliente y
servidor es de vital importancia, cuando la fuente de datos es explícitamente
30
de confianza y donde no es importante el no disponer de procesamiento XSLT
para manipular los datos en el cliente. (p.07)
2.2.20. AJAX
Según Eguíluz J (2008) “AJAX permite mejorar completamente la
interacción del usuario con la aplicación, evitando las recargas constantes de la
página, ya que el intercambio de información con el servidor se produce en un
segundo plano.” (p.06)
2.2.21. WeekCalendar de jQuery
Según Monie, R (2013) El complemento jquery-week-calendar
proporciona una forma simple y flexible de incluir un calendario semanal en
su aplicación. Está construido sobre jquery y jquery ui y está inspirado en
otros calendarios semanales en línea como el calendario de google.
2.3 Definición de términos básicos
2.3.1. Optimizar Procesos Médicos.
Según Neumann, (2014) La optimización de procesos se logra a través
de la investigación del uso adecuado de los recursos tanto humanos como
materiales. Para ello primero se detectan los procesos “core” en que se
destinan el grueso de los recursos, para luego trazar metas con fin de mejorar
de manera significativa el rendimiento de dichos procesos. Controlar el uso de
los recursos y mejorar el rendimiento de las personas es posible con la
optimización de procesos, finalmente se tiene el objetivo de mejorar el
rendimiento, reducir costos para poder tener procesos más eficientes y
eficaces. (Muro, F. 2015, p.18)
31
2.3.2. Importancia de la Rehabilitación Médica.
La rehabilitación médica es importante para reducir el nivel de
discapacidad y refuerza las oportunidades para las personas discapacitadas.
Según la Unión Europea de Médicos Especialistas ([UEMS],2009) “Tratar las
consecuencias de la enfermedad y de los traumatismos, tales como la
espasticidad tras un daño cerebral o medular, significa que no sólo mejorará la
vida de los pacientes, sino que también existirá un beneficio a nivel
económico, mediante la reducción de los gastos debido al tratamiento de
dichas complicaciones. Ello tendrá un efecto directo en el cuidado, en la vida
laboral y en las pensiones “(p.10)
2.3.3. Cronograma de Atenciones Médicas.
Según el Director del Hospital Central FAP, en su sitio web podrán
acceder al cronograma de citas médicas, reserva de citas online, historial de
citas médicas, anulación de citas y obtener resultados de exámenes de
laboratorio para el titular e hijos menores de 18 años; así mismo diariamente al
interior de nuestro recinto hospitalario les ofrecemos servicios asistenciales de
endoscopias, anatomía patológica, consultoría en nutrición y dietética,
consultoría en planificación familiar, banco de sangre, laboratorio clínico,
medicina nuclear, radiología, ecografía, radiología, resonancia magnética y
tomografía axial computarizada así como asesoría con nuestro personal de
Servicio Social.
32
2.3.4. Informática Médica.
Según Suarez, O & Ordoñez A (2012) “La Informática Médica
(IM) estudia la intersección entre la tecnología computacional, la medicina y la
influencia del uso de la historia clínica electrónica y los sistemas inteligentes
de apoyo diagnóstico en la toma de decisiones clínicas” (p.199)
CAPITULO III.
METODOLOGIA
Figura 1. Fases del Desarrollo Metodológico SCRUM
33
3.1 Diseño metodológico
La metodología de desarrollo ágil seleccionada para la implementación de los
procesos de gestión de citas y control de terapias, la cual identificara las verdaderas
necesidades de los Stakeholders, realizar una correcta estimación de los tiempos,
lograr una participación del equipo de trabajo, revisar lo construido contrastando con
el objetivo del sprint para entregar una versión del producto hasta finalmente obtener
lo esperado.
Las fases del desarrollo metodológico ágil SCRUM son:
3.1.1. Fase de inicio
Fase de preparación del proyecto conocida como el sprint 0, es la fase
inicial en la que se intenta comprender el caso de negocio con la finalidad de
tomar decisiones que agreguen valor al producto, identificar los roles claves y
formar equipos.
Tabla 7. Roles de SCRUM del proyecto
Roles Descripción Profesional

Las personas a las que el proyecto les producirá
Stakeholder Doctor, Secretaria, Terapista
un beneficio.
Es la Persona que toma decisiones, y es la que
Product Owner Analistas del Proyecto
realmente conoce el negocio del cliente.
Es el encargado de comprobar que el modelo y la
Scrum Master Jefe del área de Sistemas
metodología funcionen.
Tienen la autoridad para organizar y tomar Personas encargadas del desarrollo y
Scrum Team
decisiones para conseguir su objetivo desarrollo de los Sprint
Fuentes: Elaboración propia
Las tareas por realizar en el Sprint 0 son:
 Definir el proyecto.
 Definir la tarea como terminada.
 Definición del Backlog Inicial.
34
 Definición de Entregables.
3.1.2. Fase de planificación y estimación
Tiene como finalidad realizar una reunión, en la que participaran el
Product Owner, el Scrum Master y el equipo, con la intención de seleccionar
la lista Backlog del producto las funcionalidades sobre la que se va a trabajar,
y que darán valor al producto.
El Product Owner tendrá que preparar el Backlog para así poder discutir
en las reuniones donde se dividen en dos partes de 2 horas:
3.1.2.1. Primera parte de la reunión
 El equipo selecciona los ítems para transformarlos en
entregables.
 El equipo hace sugerencias, el Product Owner decidirá si
forma parte del sprint.
 El equipo seleccionara el elemento a implementar, de los
seleccionados por el P.O. para ese Sprint.
3.1.2.2. Segunda parte de la reunión
 El equipo hace preguntas necesarias que tengan que ver
sobre el Product backlog al Product Owner.
 El equipo deberá encontrar la solución adecuada para
transformar la parte adecuada de una funcionalidad
entregable.
35
A continuación, se detallará el paso a paso para realizar las reuniones por
Scrum:
3.1.2.3. Planificación del Backlog
 Se definirá el documento en el que se reflejan los requisitos
del sistema por prioridades.
 En esta fase se definirá también la planificación del Sprint
0, en el que se decidirá cuáles van a ser los objetivos y
trabajos por realizar para la iteración.
 Además, se obtendrá un sprint Backlog en esta reunión, que
es la lista de tareas y objetivo más importante del Sprint.
3.1.2.4. Seguimiento del Sprint
En esta fase se hacen las reuniones diarias en las que se cuestionan
con 3 preguntas principales para la evaluación de las tareas:
 ¿Qué trabajo se realizó desde la reunión anterior?
 ¿Qué trabajo se hará hasta una nueva reunión?
 ¿Qué inconvenientes han surgido y que hay que solucionar
para poder continuar?
3.1.2.5. Revisión del Sprint
Finalizado el Sprint, se procederá con la revisión del incremento
generado. Presentándose los resultados finales y una demo o versión para
la mejora del feedback con el cliente.
36
3.1.3. Fase de implementación del Sprint
El Desarrollo del Sprint, en esta fase el equipo trabaja para conseguir
un aumento en el producto final, que será productivo para el Product Owner y
los Stakeholders, además se pueden entregar con el menor esfuerzo al
Stakeholders cuando lo solicite.
La duración de un Sprint es más conveniente que dure entre 2 a 4
semana, a lo mucho un mes. Estos intervalos de tiempos son los que se
consideran más apropiados para que el Stakeholders no pierda el interés.
Las reuniones durante la ejecución del Sprint son:
 Reunión de Planificación.
 Reunión Diaria.
 Reunión Revisión del Sprint.
3.1.4. Fase de revisión y retrospectiva
Después del Sprint el equipo de desarrollo debatirá temas relacionados
con el Sprint recientemente finalizado y los cambios que se podrían hacer para
mejorar el próximo sprint y que sea más productivo. Se lleva a cabo el último
día del Sprint y tiene dos partes:
 Revisión (Demostración): El equipo presenta al Stakeholder los
requisitos completados del Sprint, en forma de un aumento del
producto preparado para ser entregado con el mismo esfuerzo
posible. Dependiendo del Resultado mostrado, el cliente realiza
adaptaciones necesarias de manera objetiva, a partir del primer
Sprint, reprogramando el proyecto.
37
 Retrospectiva: El equipo analiza cómo ha sido su forma de
trabajar y cuáles son los problemas que podrían impedirles
progresar adecuadamente, mejo9rando continuamente su
productividad.
3.1.5. Fase de Lanzamiento
En esta fase se encuentran las típicas actividades de fin de proyecto
como, hacer una versión distribuible, testear, marketing, etc.
CAPITULO IV.
DESARROLLO
4.1 Desarrollo metodológico
Para la realización del desarrollo de la solución hemos utilizado diferentes
herramientas que nos ayudaron a organizarnos y así poder entender mejor lo que se
implementara, usamos UML para la poder detallar con mejor claridad a los actores
involucrados en el proceso de control de terapias del área de Medicina Física y
Rehabilitación de la Clínica San Judas Tadeo.
4.1.1. IceScrum:
Herramienta de gestión de proyectos Scrum.
4.1.1.1. Project Charter – IceScrum
Puesto que en este documento se detalla todo lo relacionado a los
aspectos importantes de todo el proyecto, usando la herramienta IceScrum,
38
pudimos detallar de manera más específica los objetivos, la visión,
indicadores, procedimientos, equipo, materiales e historial de avances,
Figura 2. Tablero o Dashboard (Project Charter) - IceScrum
4.1.1.2. Miembros del Equipo
El equipo gracias a la herramienta de IceScrum pudimos conformarlo
de manera más simplificada utilizado por los estudiantes del curso
(Owners) y el Jefe de Área de Sistemas (ScrumMaster), para el
desarrollo del proyecto de investigación.
39
Figura 3. Equipo - IceScrum
4.1.1.3. Backlog Inicial
Nuestro equipo para poder armar el Backlog realizamos las siguientes
actividades con la herramienta IceScrum, lo que consta de armar lo
que se va a hacer o realizar en las diferentes partes del backlog,
recabamos las características más importantes guiándonos de lo
analizado a lo largo de la investigación:
 Primero las Características(Épicas):
IceScrum nos dice que “aquí se crean funciones para definir
un desglose de alto nivel para el producto”. En la cual se
pueden asociar varias Historias de Usuario (H.U). Este es el
primer paso para poder observar algo más detallado y en
conjunto de lo que se trata el desarrollo y los diferentes
objetivos a cumplir. (Ver Anexo)
Figura 4. Características - IceScrum
 Segundo Realizar Reuniones:
40
En esta sección lo que queremos en poder planificar, sugerir o
aceptar las diferentes funciones que puede tener el proyecto,
para ello se realizan las reuniones para discutir cuales sería la
mejor opción a elegir y dar cada uno su punto de vista.
 Tercer Armar el Backlog Inicial
El backlog inicial está sujeto a cambios y el que se encarga de
aprobar lo que se realizara es el ScrumMaster acompañado de
los Owners para tener en cuenta cual será la mejor manera de
darle solución a los requerimientos de los involucrados. (Ver
Anexo 20).
4.1.1.4. Product Backlog
Las reuniones son fundamentales para poder cumplir con el
backlog ya que marcan el inicio de lo que quiere el Stakeholder, así
mismo dar inicio al backlog en conocido como el SPRINT 0 ya que
aquí debemos dejar en claro los objetivos de lo que se busca
solucionar, en el IceScrum es conocido como caja de arena donde se
sugieren ideas, esperando ser discutidas y trasladadas a una caja
“relevante” conocida como product backlog.
41
Figura 5. Product Backlog – IceScrum (Parte 1)
A partir de cómo se fue avanzando se va ir actualizando el
backlog según lo que se requiera, el IceScrum nos facilita mostrar una
historia de usuario “Técnica” y otra “Funcional”, las dos se diferencias
por sus propios nombres algo técnico es que se documentara a partir de
cómo va a funcionar el proyecto y el otro de que es lo que va ser el
proyecto.
Cuando una historia es suficientemente detallada, el Scrum
Master del proyecto lo evalúa y si se cree que una historia aporta valor,
lo acepta como una historia, lo que lo moverá a la vista del Backlog.
42
Después toca estimar y dar valor a las historias la cual ayudara en
la planificación del lanzamiento del proyecto, lo que significa que son
candidatas para la planificación y ya estará lista para colocarlo en algún
Sprint.
Figura 6. Product Backlog – IceScrum (Parte 2)
4.1.1.5. Sprint Backlog
Una vez que se crean las versiones de los sprints y se estima y
prioriza el trabajo acumulado, se puede hacer la planificación. Con
IceScrum, la planificación de lanzamiento se puede hacer de forma
manual o automática (iceScrum tiene en cuenta la velocidad y la
prioridad para la planificación automática). Como la velocidad no se
mide al principio, es mejor hacer una planificación manual.
43
Figura 7. Sprint 1 (IceScrum)
Durante las reuniones de planificación de sprints, durante las
cuales los miembros del equipo identifican las tareas, es posible crear
tareas recurrentes que se pueden copiar sobre los sprints y tareas
urgentes que no pertenecen a una historia.
Cuando se crean todas las tareas, con su tiempo restante eventual y
una persona designada como responsable, el sprint se puede activar para
materializar el compromiso acordado en la reunión.
44
45
46
4.2 Requerimientos – Historias de usuarios
Los Requerimientos Funcionales y No Funcionales del sistema se contribuyen a
partir de las Historias de Usuario, según lo que se relató en la planificación de los
Sprints según el marco de trabajo SCRUM, puesto que utilizamos la Herramienta
IceScrum cada Historia de Usuario se pertenece a un Sprint.
4.2.1. Especificaciones no Funcionales
Tabla 8. Requerimientos No Funcionales del Sistema

Tipo de Nombre Código Descripción
Requisito
Tiempo de RNF-01 El tiempo de respuesta del
respuesta sistema para operaciones de
ingreso o registro de
información deberá ser como
Rendimiento máximo 10 segundos de espera
Tiempo de RNF-02 El tiempo promedio al realizar
Transacción los registros de un problema con
el hardware debe ser de forma
instantánea al guardar los datos
en la base de datos y poderse
comunicar con el personal de
sistemas y validarlos
RNF-03 A cada persona que interactúe
Ingresar al con el sistema se le asignará un
sistema usuario del sistema y una clave,
los cuales permitirán el ingreso
de acuerdo con un perfil
Confiabilidad seleccionado.
Cumplimiento RNF-04 El sistema soportará fallas
de
confiabilidad
Precisión RNF-05 El sistema debe mostrar la fecha
y hora de las operaciones
realizadas por los usuarios.
Disponibilidad RNF-06 El sistema estará disponible 24
diaria Activa horas al día, 7 días a la semana.
Disponibilidad Disponibilidad RNF-07 El sistema estará disponible las

24 horas 24 horas del día para cualquier
consulta que requieran realizar
los usuarios.
Usuario seguro RNF-08 Cada usuario tendrá una
contraseña única para que pueda
entrar al sistema.
47
Seguridad Back-up RNF-09 El sistema tendrá un Back-up
(copia de datos) de todo el
contenido histórico de las
operaciones.
Sistema RNF-10 El Sistema no puede permitir el
estable cierre de una operación hasta
que todos sus procesos,
subprocesos y tareas hayan
concluido satisfactoriamente.
Portabilidad Portabilidad RNF-11 El sistema deberá considerar
para su desarrollo la arquitectura
MVC.
Servicio en la RNF-12 El sistema estará en la nube lo
nube que permite transferirse de un
lugar a otro.
Interfaz RNF-13 El sistema debe poseer una
gráfica interfaz gráfica uniforme a
uniforme través de este incluyendo
pantallas, menús y opciones,
tamaño de las pantallas, color y
tipo de letra.
Diseño RNF-14 El diseño debe realizarse guiado
Mantenibilidad Organizaciona por las características generales,
l en cuanto a colores
organizacional recomendados
por el usuario y disposición de
contenidos, encontradas en el
sitio web de la Entidad.
Idioma RNF-15 Las interfaces deben realizarse
en idioma castellano; sin
perjuicio de lo cual debe evitar
traducirse la terminología
técnica específica que no posee
una traducción precisa al
castellano.
Facilitar uso RNF-16 El Sistema debe ser de fácil uso,
muy comprensible en cuanto al
diseño visual del sistema.
Usabilidad Manejar y RNF-17 El Sistema debe presentar
comunicar mensaje de error que permitan al
errores usuario identificar el tipo de
error y comunicarse con el
administrador del sistema.
48
4.2.2. Especificaciones Funcionales del Sistema
Para especificar mejor esta parte partiremos desde la creación de la
historia de usuario con los requerimientos del cliente y las
funcionalidades del sistema, además de los prototipos e interfaces que
usa el proyecto. También detallaremos los escenarios hechos en UML
para dividirlos por módulos y dar mejor entendimiento de lo que se ha
realizado.
4.2.2.1. Módulo de Seguridad
Figura 11. Diagrama de Casos de Uso: Seguridad
49
4.2.2.1.1. Historia de Usuario 1 – Iniciar Sesión
Figura 12. Historia de Usuario (IceScrum) - Iniciar Sesión
Tabla 9. Requerimientos Funcionales - H1 ("Iniciar Sesión")
HU - 01 Iniciar Sesión
Descripción La historia de usuario permite al usuario validar su
identidad ante el sistema.
Actor(es) Usuario
RF1 El sistema validará los datos ingresados.
RF2 El sistema creará una sesión única para el usuario.
RF3 El sistema iniciará sesión.
Elaboración: Los Autores
50
Figura 13. Prototipo HU Iniciar Sesión
4.2.2.1.2. Historia de Usuario 2 – Buscar Perfil
Figura 14. Historia de Usuario (IceScrum) - Buscar Perfil
Tabla 10. Requerimiento Funcional -H2 (“Buscar Perfil”)

HU - 02 Buscar Perfil
Descripción La historia de usuario permite buscar un perfil.
Actor(es) Administrador
RF4 El sistema buscará el perfil según los datos ingresados.
RF5 El sistema listará los perfiles según el criterio de búsqueda.
51
4.2.2.1.3. Historia de Usuario 3 – Mantener Perfil
Figura 15.Historia de Usuario (IceScrum) - Mantener Perfil
Tabla 11. Requerimiento Funcional -H3 (“Mantener Perfil”)

HU - 03 Mantener Perfil
Descripción La historia de usuario permite al Administrador buscar,
agregar, modificar y eliminar el perfil del usuario.
RF6 El sistema listará los datos de los perfiles.
RF7 El sistema validará los datos.
RF8 El sistema agregará un nuevo perfil.
RF9 El sistema modificará el perfil.
RF10 El sistema eliminará el perfil.
52
Figura 16. Prototipo HU Mantener Perfil.
4.2.2.1.4. Historia de Usuario 4 – Buscar Usuario
Figura 17. Historia de Usuario (IceScrum) - Buscar Usuario
Tabla 12.Requerimiento Funcional -H4 (“Buscar Usuario”)

HU - 04 Buscar Usuario
Descripción La historia de usuario permite buscar un usuario.
RF11 El sistema buscará al usuario según los datos ingresados.
RF12 El sistema listará los usuarios según el criterio de búsqueda.
53
4.2.2.1.5. Historia de Usuario 5 – Mantener Usuario
Figura 18. Historia de Usuario (IceScrum) - Mantener Usuario
Tabla 13. Requerimiento Funcional -H5 (“Mantener Usuario”)

HU - 05 Mantener Usuario
agregar, modificar y eliminar al usuario.
RF13 El sistema listará a los usuarios.
RF14 El sistema validará los datos de los usuarios.
RF15 El sistema agregará un nuevo usuario.
RF16 El sistema modificará al usuario.
RF17 El sistema eliminará al usuario.
54
Figura 19. Prototipo HU Mantener Usuario.
Figura 20. Prototipo HU Mantener Usuario - Agregar.
Figura 21. Prototipo HU Mantener Usuario - Editar.
55
4.2.2.2. Módulo de Mantenimiento
Figura 22. Diagrama de Casos de Uso: Mantenimiento
56
4.2.2.2.1. Historia de Usuario 6 – Mantener Terapias
Figura 23. Historia de Usuario (IceScrum) - Mantener Terapias
Tabla 14. Requerimiento Funcional -H6 (“Mantener Terapias”)

HU - 06 Mantener Terapias
agregar, modificar y eliminar el registro de terapia
asignada.
RF18 El sistema listará el registro de terapias asignado.
RF19 El sistema validará el registro de terapias.
RF20 El sistema agregará un nuevo registro de terapia.
RF21 El sistema modificará el registro de terapia.
RF22 El sistema eliminará el registro de terapia.
57
Figura 24. Prototipo HU Mantener Terapias
Figura 25. Prototipo HU Mantener Terapias - Agregar.
58
4.2.2.2.2. Historia de Usuario 7 – Buscar Agente de
Tratamiento
Figura 26. Historia de Usuario (IceScrum) - Buscar Agente de Tratamiento
Tabla 15. Requerimiento Funcional –H7 (“Buscar Agente de Tratamiento”)

HU - 07 Buscar Agentes de Tratamiento
Descripción La historia de usuario permite buscar un agente de
tratamiento.
RF23 El sistema buscará los agentes de tratamiento según los
datos ingresados.
RF24 El sistema listará el registro de agentes de tratamiento según
el criterio de búsqueda.
59
4.2.2.2.3. Historia de Usuario 8 – Mantener Agente de
Tratamiento
Figura 27. Historia de Usuario (IceScrum) - Mantener Agente de Tratamiento
Tabla 16. Requerimiento Funcional -H8 (“Mantener Agente de Tratamiento”)

HU - 08 Mantener Agentes de Tratamiento
agregar, modificar y eliminar el registro de terapia
asignada.
RF25 El sistema listará el registro de agentes de tratamiento.
RF26 El sistema buscará una zona de tratamiento.
RF27 El sistema agregará los datos de la zona de tratamiento a la
grilla.
RF28 El sistema generará un número para el agente de
RF29 tratamiento.
RF30 El sistema validará los datos ingresados por el
administrador
RF31 El sistema agregará un nuevo registro de agentes de
RF32 tratamiento.
El sistema modificará el registro de agentes de tratamiento.
El sistema eliminará el registro de agentes de tratamiento.
60
Figura 28. Prototipo HU Mantener Agente de Tratamiento
Figura 29.Prototipo HU Mantener Agente de Tratamiento - Agregar.
61
4.2.2.2.4. Historia de Usuario 9 – Buscar Zona de Tratamiento
Figura 30. Historia de Usuario (IceScrum) - Buscar Zona de Tratamiento
Tabla 17. Requerimiento Funcional –H9 (“Buscar Zona de Tratamiento”)

HU - 09 Buscar Zona de Tratamiento
Descripción La historia de usuario permite buscar una zona de
tratamiento.
RF33 El sistema buscará las zonas de tratamiento según los datos
ingresados.
RF34 El sistema listará el registro de zonas de tratamiento según
el criterio de búsqueda.
62
4.2.2.2.5. Historia de Usuario 10 – Mantener Zona de
Tratamiento
Figura 31. Historia de Usuario (IceScrum) - Mantener Zona de Tratamiento
Tabla 18. Requerimiento Funcional –H10 (“Mantener Zona de Tratamiento”)

HU - 10 Mantener Zona de Tratamiento
Descripción La historia de usuario permite al Administrador
buscar, agregar, modificar y eliminar las zonas de
tratamiento.
RF35 El sistema listará las zonas de tratamiento.
RF36 El sistema validará las zonas de tratamiento.
RF37 El sistema agregará una nueva zona de tratamiento.
RF38 El sistema modificará la zona de tratamiento.
RF39 El sistema eliminará la zona de tratamiento.
63
Figura 32. Prototipo HU Mantener Zona de Tratamiento.
Figura 33. Prototipo HU Mantener Zona de Tratamiento - Agregar.
64
4.2.2.2.6. Historia de Usuario 11 – Buscar Consultorio
Figura 34. Historia de Usuario (IceScrum) - Buscar Consultorio
Tabla 19. Requerimiento Funcional –H11 (“Buscar Consultorio”)

HU - 11 Buscar Consultorio
Descripción La historia de usuario permite buscar consultorio.
RF40 El sistema buscará los consultorios según los datos
ingresados.
RF41 El sistema listará el registro de consultorios según el criterio
de búsqueda.
65
4.2.2.2.7. Historia de Usuario 12 – Mantener Consultorio
Figura 35. Historia de Usuario (IceScrum) - Mantener Consultorio
Tabla 20. Requerimiento Funcional –H12 (“Mantener Consultorio”)

HU - 12 Mantener Consultorio
buscar, agregar, modificar y eliminar los consultorios.
RF42 El sistema listará los consultorios.
RF43 El sistema validará el consultorio.
RF44 El sistema agregará un nuevo consultorio.
RF45 El sistema modificará el consultorio.
RF46 El sistema eliminará el consultorio.
66
Figura 36. Prototipo HU Mantener Consultorios
Figura 37. Prototipo HU Mantener Consultorio - Agregar.
67
4.2.2.2.8. Historia de Usuario 13 – Buscar Diagnostico CIE10
Figura 38. Historia de Usuario (IceScrum) - Buscar Diagnostico CIE10
Tabla 21. Requerimiento Funcional -H13 (“Buscar Diagnostico CIE-10”)

HU - 13 Buscar Diagnósticos CIE10
Descripción La historia de usuario permite buscar un diagnóstico.
RF47 El sistema buscará los diagnósticos según los datos
ingresados.
RF48 El sistema listará el registro de diagnósticos según el criterio
de búsqueda.
68
4.2.2.2.9. Historia de Usuario 14 – Mantener Diagnostico CIE
10
Figura 39. Historia de Usuario (IceScrum) - Mantener Diagnósticos CIE-10
Tabla 22. Requerimiento Funcional -H14 (“Mantener Diagnostico CIE-10”)

HU - 14 Mantener Diagnósticos CIE10
buscar, agregar, modificar y eliminar los diagnósticos.
RF49 El sistema listará los diagnósticos.
69
Figura 40. Prototipo HU Mantener Diagnostico CIE-10
4.2.2.2.10. Historia de Usuario 15 – Buscar Pacientes
Figura 41. Historia de Usuario (IceScrum) - Buscar Pacientes
Tabla 23. Requerimiento Funcional -H14 (“Buscar Pacientes”)

HU - 15 Buscar Pacientes
Descripción La historia de usuario permite buscar un paciente.
RF50 El sistema buscará a los pacientes según los datos
RF51 ingresados.
El sistema listará el registro de los pacientes según el criterio
de búsqueda.
70
4.2.2.2.11. Historia de Usuario 16 – Mantener Pacientes
Figura 42. Historia de Usuario (IceScrum) - Mantener Pacientes
Tabla 24. Requerimiento Funcional -H16 (“Mantener Pacientes”)

HU - 16 Mantener Pacientes
buscar, agregar, modificar y eliminar el registro de los
pacientes de la clínica SJT.
RF52 El sistema listará el registro de los pacientes.
RF53 El sistema validará los datos registrados.
RF54 El sistema agregará un nuevo registro.
RF55 El sistema validará la Historia Clínica del paciente.
RF56 El sistema modificará el registro del paciente.
RF57 El sistema eliminará el registro del paciente.
71
Figura 43. Prototipo HU Mantener Paciente
Figura 44. Prototipo HU Mantener Paciente – Agregar
72
4.2.2.2.12. Historia de Usuario 17 – Buscar Terapista
Figura 45. Historia de Usuario (IceScrum) - Buscar Terapista
Tabla 25. Requerimiento Funcional -H17 (“Buscar Terapistas”)

HU - 17 Buscar Terapista
Descripción La historia de usuario permite buscar un personal con perfil
“Terapista”.
RF58 El sistema buscará a los terapistas según los datos
RF59 ingresados.
El sistema listará el registro de los terapistas según el
criterio de búsqueda.
73
4.2.2.2.13. Historia de Usuario 18 – Buscar Doctores
Figura 46. Historia de Usuario (IceScrum) - Buscar Doctores
Tabla 26.Requerimiento Funcional -H18 (“Buscar Doctores”)

HU - 18 Buscar Doctores
Descripción La historia de usuario permite buscar un personal con perfil
“Doctor”.
RF60 El sistema buscará a los doctores según los datos ingresados.
RF61 El sistema listará el registro de los doctores según el criterio
de búsqueda.
74
4.2.2.2.14. Historia de Usuario 19 – Buscar Personal
Figura 47. Historia de Usuario (IceScrum) - Buscar Personal
Tabla 27.Requerimiento Funcional -H19 (“Buscar Personal”)

HU - 19 Buscar Personal
Descripción La historia de usuario permite buscar al personal.
RF62 El sistema buscará al personal según los datos ingresados.
RF63 El sistema listará el registro del personal según el criterio de
búsqueda.
75
4.2.2.2.15. Historia de Usuario 20 – Generar Historia Clínica al
Paciente
Tabla 28.Requerimiento Funcional –H20 (“Generar Historia Clínica al Paciente”)

HU - 20 Generar Historia Clínica al Paciente
Descripción La historia de usuario permite al Usuario generar una
nueva historia clínica para el paciente
Actor(es) Secretaria y Doctor
RF64 El sistema generará el número de historia clínica que le
corresponde al paciente.
4.2.2.2.16. Historia de Usuario 21 – Mantener Personal
Figura 48. Historia de Usuario (IceScrum) - Mantener Personal
Tabla 29. Requerimiento Funcional -H21 (“Mantener Personal”)
76
HU - 21 Mantener Personal
agregar, modificar y eliminar el registro del personal de la
Clínica SJT.
RF65 El sistema listará a los personales registrados.
RF66 El sistema validará los datos del personal.
RF67 El sistema agregará un nuevo personal.
RF68 El sistema modificará el registro del personal.
RF69 El sistema eliminará el registro del personal.
Figura 49. Prototipo HU Mantener Personal
77
Figura 50. Prototipo HU Mantener Personal – Agregar
4.2.2.3. Modulo Reporte de Terapias
Figura 51. Diagrama de Casos de Uso: Reporte de Terapias
78
4.2.2.3.1. Historia de Usuario 22 – Reportar Ingresos en el Área
Figura 52. Historia de Usuario (IceScrum) - Reportar Ingresos en el Área
Tabla 30. Requerimiento Funcional -H22 (“Reportar Ingresos en el Área”)

HU - 22 Reportar Ingresos en el Área
Descripción La historia de usuario permite a la Secretaria visualizar y
hacer reportes sobre los ingresos en el área.
Actor(es) Secretaria
RF70 El sistema filtrará por un rango de fecha los ingresos en el
área
RF71 El sistema calculará las ganancias totales de las consultas
tratadas en el área.
RF72 El sistema calculará las ganancias totales de las terapias
tratadas en el área.
RF73 El sistema mostrará una gráfica de pastel informando las
cantidades totales por tipos de operaciones tratadas en el
área “Consultas y terapias”.
RF74 Mostrará una lista de los ingresos recientes en el área.
79
Figura 53. Prototipo HU Reportar Ingresos en el Área
4.2.2.3.2. Historia de Usuario 23 – Listar Cronograma de

Atención a Terapias
Figura 54. Historia de Usuario (IceScrum) - Listar Cronograma de Atención a Terapias
Figura 55. Requerimiento Funcional -H23 (“Listar Cronograma de Atención a Terapias”)

HU - 23 Listar Cronograma de Atención a Terapias
Descripción La historia de usuario permite al Usuario listar el
80
cronograma de atención de terapias de los pacientes.
Actor(es) Secretaria y Terapista
RF75 El sistema buscará un agente de tratamiento
RF76 El sistema mostrará el cronograma de atención la lista de
agentes de tratamientos seleccionados.
4.2.2.3.3. Historia de Usuario 24 – Reportar Atenciones en el

Área
Figura 56. Historia de Usuario (IceScrum) - Reportar Atenciones en el Área
Tabla 31. Requerimiento Funcional -H24 (“Reportar Atenciones en el Área”)

HU - 24 Reportar Atenciones en el Área
Descripción La historia de usuario permite a la Secretaria reportar
atenciones en el área de medicina física y rehabilitación.
RF77 El sistema filtrará por fecha
RF78 El sistema mostrará el reporte de atenciones del área de
medicina física.
81
Figura 57. Prototipo HU Reportar Atenciones en el Área
4.2.2.4. Modulo Atender Paciente
Figura 58. Diagrama de Casos de Uso: Atender Paciente
82
4.2.2.4.1. Historia de Usuario 25 – Reservar Cita
Figura 59. Historia de Usuario (IceScrum) - Reservar Cita
Tabla 32. Requerimiento Funcional -H25 (“Reservar Cita”)

HU - 25 Reservar Cita
Descripción La historia de usuario permite a la Secretaria reservar la
cita generada por el paciente.
RF79 El sistema listará a los pacientes por semana.
RF80 El sistema buscará al paciente.
RF81 El sistema buscará al doctor.
RF82 El sistema validará los datos de la cita.
RF83 El sistema generará un número de cita
RF84 El sistema registrará la cita.
83
Figura 60. Prototipo HU Reservar Cita
Figura 61. Prototipo HU Reservar Cita - Nueva Cita
84
4.2.2.4.2. Historia de Usuario 26 – Pagar Atención
Figura 62. Historia de Usuario (IceScrum) - Pagar Atención
Tabla 33. Requerimiento Funcional -H26 (“Pagar Atención”)

HU - 26 Pagar Atención
Descripción La historia de usuario permite a la Secretaria visualizar el
monto de la consulta a pagar del paciente
RF85 El sistema calculará el monto de pago.
RF86 El sistema generará un número de pago.
RF87 El sistema registrará el de pago según el tipo de consulta.
RF88 El sistema registrará el número de pago con el número de
reserva correspondiente.
RF89 El sistema generará un documento pdf con la información
de pago.
85
Figura 63. Prototipo HU Pagar Cita
86
4.2.2.4.3. Historia de Usuario 27 – Registrar Horarios de
Atención
Figura 64. Historia de Usuario (IceScrum) - Registrar Horarios de Atención
Tabla 34. Requerimiento Funcional -H27 (“Registrar Horarios de Atención”)

HU - 27 Registrar Horarios de Atención
Descripción La historia de usuario permite al Administrador registrar
los horarios de atención.
RF90 El sistema buscará un doctor.
RF91 El sistema buscará un consultorio.
RF92 El sistema mostrará un calendario para seleccionar los días
de atención.
RF93 El sistema mostrará un rango de hora de inicio y fin para
registrar el día de atención.
RF94 El sistema registrará el horario de atención.
RF95 El sistema mostrará una lista de horarios registrados.
RF96 El sistema modificará los horarios de atención.
RF97 El sistema eliminará los horarios de atención.
87
Figura 65. Prototipo HU Registrar Horarios de Atención
4.2.2.4.4. Historia de Usuario 28 – Visualizar Antecedentes en

el Área
Figura 66. Historia de Usuario (IceScrum) - Visualizar Antecedentes en el Área
Tabla 35. Requerimiento Funcional -H28 (“Registrar Horarios de Atención”)

HU – 28 Visualizar Antecedentes en el Área
Descripción La historia de usuario permite al Usuario visualizar las
88
terapias del paciente
RF98 El sistema buscará al paciente por DNI o nombre y
apellidos.
RF99 El sistema mostrará una lista de consultas asociadas al
paciente
RF100 El sistema mostrará una lista de terapias asociadas al
paciente
4.2.2.5. Modulo Gestión de Terapias
Figura 67. Diagrama de Casos de Uso: Gestión Terapias
89
4.2.2.5.1. Historia de Usuario 29 – Atender Pacientes
Figura 68. Historia de Usuario (IceScrum) – Atender Pacientes
Tabla 36. Requerimiento Funcional –H29 (“Atender Pacientes”)

HU – 29 Atender Pacientes
Descripción La historia de usuario permite al Doctor generar atención al
paciente.
Actor(es) Doctor
RF101 El sistema mostrará una lista de los pacientes con estado de
pago “Cancelado” según el día de atención.
RF102 El sistema listará un histórico de consulta según el paciente
seleccionado.
RF103 El sistema buscará diagnósticos.
RF104 El sistema agregará los datos del diagnóstico a la grilla.
RF105 El sistema agregara los datos de región a tratar a la grilla.
RF106 El sistema agregará la región a tratar a la atención.
RF107 El sistema validará datos ingresados del paciente.
RF108 El sistema generará un número de atención a terapias del
paciente.
RF109 El sistema registrará la atención a terapias de los pacientes.
90
Figura 69. Prototipo HU Atender Pacientes
Figura 70. Prototipo HU Atender Paciente - Registrar Atención a Terapias del Paciente
91
4.2.2.5.2. Historia de Usuario 30 – Registrar Historia Clínica al
Paciente
Figura 71. Historia de Usuario (IceScrum) - Registrar Historia Clínica
Tabla 37. Requerimiento Funcional –H30 (“Registrar Historia Clínica al Paciente”)

HU – 30 Registrar Historia Clínica al Paciente
Descripción La historia de usuario permite registrar la historia clínica
del paciente.
Actor(es) Doctor
RF110 El sistema calculará la masa corporal del paciente.
RF111 El sistema validará la historia clínica del paciente.
92
Figura 72.Prototipo HU Registrar Historia Clínica
4.2.2.6. Modulo Control de Terapias
Figura 73. Diagrama de Casos de Uso: Control de Terapias
93
4.2.2.6.1. Historia de Usuario 31 – Asignar Zonas de
Tratamiento
Figura 74. Historia de Usuario (IceScrum) - Asignar Zonas de Tratamiento
Tabla 38. Requerimiento Funcional –H31 (“Asignar Zonas de Tratamiento”)

HU - 31 Asignar Zonas de Tratamiento
Descripción La historia de usuario permite a la Secretara registrar las
zonas de tratamiento.
RF112 El sistema buscará a un personal con perfil “Terapista”
RF113 El sistema buscará un agente de tratamiento
RF114 El sistema mostrará las zonas disponibles según el agente de
tratamiento seleccionado.
RF115 El sistema asignará las zonas de tratamiento a la terapista.
RF116 El sistema validará los horarios seleccionados de atención
RF117 El sistema registrará la zona asignada de tratamiento
RF118 El sistema mostrará una lista de zonas asignadas
RF119 El sistema modificará la zona asignada de tratamiento
RF120 seleccionado.
El sistema eliminará la zona asignada de tratamiento
seleccionado.
94
Figura 75. Prototipo HU Asignar Zona de Tratamiento
4.2.2.6.2. Historia de Usuario 32 – Generar Cronograma de

Atención a Terapias
95
Figura 76. Historia de Usuario (IceScrum) - Generar Cronograma de Atención
Tabla 39. Requerimiento Funcional -H26 (“Generar Cronograma de Atención a Terapias”)

HU - 32 Generar Cronograma de Atención a Terapias
Descripción La historia de usuario permite al Usuario generar el
cronograma de atención de los pacientes.
RF121 El sistema listará a los pacientes que requieran de atención a
terapias en estado “Pendiente”.
RF122 El sistema buscará un agente de tratamiento.
RF123 El sistema mostrará un Pop-Up de la atención previa de
paciente
RF124 El sistema validará los datos de la atención a terapias.
RF125 El sistema generará número de atención a terapias.
RF126 El sistema registrará el cronograma de atención a terapias.
RF127 El sistema generará un documento pdf con la terapia del
paciente.
4.2.2.7. Modulo Evaluación de Terapias
Figura 77. Diagrama de Casos de Uso: Evaluación de Terapias
96
4.2.2.7.1. Historia de Usuario 33 – Tratar al Paciente
Figura 78. Historia de Usuario (IceScrum) - Tratar al Paciente
Tabla 40. Requerimiento Funcional -H26 (“Tratar al Paciente”)

HU - 33 Tratar al Paciente
Descripción La historia de usuario permite al Terapista visualizar el tipo
de tratamiento que requiere el paciente.
Actor(es) Terapista
RF128 El sistema filtrará la lista de los pacientes que van a tratarse
por día.
RF129 El sistema mostrará la información detallada del
tratamiento al paciente.
RF130 El sistema registrará la atención del paciente en estado
“Atendido”.
97
4.3 Diseño y Desarrollo técnico
4.3.1. Etapas de la metodología SCRUM en los Sprints.
Figura 79. Flujo de Trabajo de las Historias (IceScrum)
El flujo de trabajo de la historia IceScrum se compone de 8
estados. Por defecto, dos de ellos están deshabilitados: "Congelado" y
"En revisión. El siguiente diagrama muestra los estados, la ubicación de
la historia en cada estado y los roles necesarios para pasar de un estado a
otro. Para realizar la planeación de los Sprints deberíamos ya haber
aceptado y estimado las historias, en esa etapa de planeación empezamos
98
a ir en progreso con la presentación del proyecto para así dar una idea
clara de lo que se ido avanzando y como se ha ido cumpliendo.
4.3.1.1. Eventos en Scrum
Todo lo descrito anterior mente en esto documento respecto a la
metodología que estamos usando y como estamos desarrollando gracias a la
utilización de los Sprints que pueden servir de desarrollo iterativo e
incremental, también se define como un meta evento que contiene a más
eventos:
 El sprint Planning al comienzo del Sprint
 Daily Scrums para actualizar el Sprint Backlog e identificar
impedimentos
 Un Sprint Review al final del Sprint para inspeccionar el
Incremento
 Justo después, la retrospectiva para hacer transparentes e
inspeccionar posibles problemas en la forma de trabajar o de
hacer Scrum.
99
Figura 80. Eventos en SCRUM (Jerónimo Palacios Associates)
La mentalidad de un proyecto por Sprint es uno de los cambios más difíciles de
asumir en la mentalidad de organizaciones que están haciendo una transición ágil
Scrum en una herramienta excelente para la gestión de proyectos. Todas las tareas
necesarias para llevar el proyecto a cabo se realizan durante el mismo Sprint. Así, el
diseño, la planificación o el testing son actividades que se realizan dentro de un sólo
Sprint, siempre orientado a generar el máximo valor.
4.3.2. Modelamiento de Procesos
En esta etapa se realizó la documentación de los
procesos a mejorar en los cuales se detallan que es lo que se
debería cambiar en el proceso AS-IS, para ello se utilizó la
herramienta de modelamiento de procesos Bizagi Process
Modeler, que nos ayudó a maquetarlo en los Anexos del 12 al
16.
100
4.3.3. Arquitectura
Figura 81. CPANEL
Es un Panel de Control basado en Linux, administra servidores web
dedicados al alojamiento de páginas. Actualmente es el panel de control más
utilizado a nivel mundial. CPanel cuenta con varias opciones como, por ejemplo:
 Archivos
 Base de Datos
 Dominios
 Correo Electrónico
 Métrica
 Seguridad
 Software
101
Figura 82. Arquitectura CPNEL
cPanel y WHM 11 es la mejor opción a la hora de automatizar la administración
de un servicio de alojamiento web. Posee herramientas de seguridad, de provisión y
transferencia de cuentas de servidor a servidor, auto instalación de aplicaciones y
además desde el panel WHM, puede proveer cuentas, configurar opciones de
seguridad, instalar software adicional y más. Esta interface provee acceso al corazón
de cPanel y WHM.
4.3.4. Diseño de BD
A continuación, se mostrará el modelo físico de la base de datos de la Clínica
San Judas Tadeo.
102
Figura 83. Base de Datos de la Clínica
4.3.5. Diseño de Casos de Uso
Para el diseño del Diagrama de Casos de uso
estructurado utilizamos UML para poder realizar la
interpretación visual de lo que está sucediendo con el sistema
a proponer para la solución del proyecto, así mismo en el
Anexo 19 podemos visualizarlo.
103
4.3.6. Producto Mínimo Viable
Figura 84. Producto Mínimo Viable
4.4. Plan de Pruebas
Para la realización del Plan de Pruebas definimos el propósito, entorno y
alcance para definir lo que se realizara en las pruebas.
104
Figura 85. Introducción del Plan de Pruebas
El alcance que definimos es el que respectivamente se describirá a continuación,
puesto que eso demuestra las pruebas necesarias que se deben de realizar al presente
proyecto, así mismo se busca realizar las definiciones exactas, herramientas a utilizar,
alojamientos webs y más. A continuación, presentamos las pruebas realizadas:
105
Figura 86. Plan de Pruebas - Pruebas de Funcionalidad
Figura 87. Plan de Pruebas - Pruebas de interfaz de Usuario
106
Figura 88. Plan de Pruebas - Pruebas de base de datos y de rendimiento
Figura 89. Plan de Pruebas – Pruebas de Carga, recuperación ante fallos, seguridad y control
de accesos
107
Figura 90. Plan de Pruebas - Pruebas de Configuración
108
CAPITULO V.
RESULTADOS
Respecto a los objetivos específicos realizados en este proyecto, se obtuvieron
los resultados para la solución de los problemas mediante un gráfico pastel de
respuestas de los doctores, terapistas y secretaria que laboran en el área de medicina
física y rehabilitación de la Clínica San Judas Tadeo.
La automatización del proceso de medicina física y rehabilitación tiene como
fin, poder lograr un mejor control de los datos que se manejan en el área de forma
segura y rápida para el control de terapias.
A continuación, se procederá con las siguientes preguntas a tratar dentro de la
clínica respecto a las historias de usuario implementadas en área para poder demostrar
si fue útil la implementación de dicho sistema.
Figura 91. Encuesta 1
109
El jefe del área de sistemas afirma que efectivamente se puede agregar pacientes
de una manera rápida y segura, tan solo pidiéndole e ingresando los datos
correspondientes en los campos incompletos.
La secretaria confirma que al momento que se busque los datos del paciente, es
más sencillo y rápido de encontrar que buscar la información del paciente mediante
files.
110
El terapista está conforme y mediante esto puede visualizar las observaciones
del doctor y proceder con las sesiones correspondientes al paciente de una manera
más rápida.
Se confirma que es de manera rápida y confiable asignar a los trabajadores sus
horarios de atención.
111
Al principio les costaba adaptarse al sistema, ya que les parecían que iban a
demorar más. Transcurso el tiempo la mayoría sabe cómo usarla y estás súper
satisfechas.
Tan solo ingresando la cantidad de sesiones que van a cancelar los pacientes, el
sistema automáticamente generará el monto a pagar y facilitará a la secretaria.
112
En el reporte se puede visualizar tanto las cantidades de consultas realizadas
durante el mes como las cantidades de terapias. Por otro lado, también se puede
visualizar las atenciones brindadas en el área de medicina física y rehabilitación.
113
5.1 Cronograma
114
Figura 98. Cronograma del Proyecto
Fuente: Elaboración Propia (Smartsheet)
115
CAPITULO VI.
DISCUSIÓN
En base a los objetivos, el primero “Analizar el actual proceso de control de terapias
del área.” Se obtuvo los resultados y se llegó a una conclusión de que dicho proceso
afectaba tanto a la secretaria, doctores y terapistas como los que iban a ser atendidos
en el área de medicina física. Al automatizar el proceso actual, facilitó a los
trabajadores del área y realizando un ingreso de data de manera rápida y asignación a
los pacientes en la zona que se debe tratar.
116
CONCLUSIONES
El desarrollo de la automatización para la Clínica San Judas Tadeo aumentó la
eficacia y velocidad en el proceso de control de terapias ingresando información del
usuario y pacientes con una mayor rapidez. Esto también favoreció a la atención de
los clientes ya que disminuyó la innecesaria dilatación de tiempo de 40 a 20 minutos.
Asu vez, se generó un mejor control de los doctores, terapistas y los lugares en las
cuales se van a asignar las terapias o consultas.
Los 3 autores, secretaria, doctor y terapista gracias a la automatización de la clínica
ahora tienen una comunicación más eficaz debido al manejo de información
compartido que les brinda este sistema, permitiéndoles registrar datos relevantes en la
historia clínica del paciente.
Por otro lado, el doctor y el terapista tienen un trabajo más colectivo gracias a la
fluida comunicación generada a través del sistema, en el cual el doctor puede hacer
observaciones importantes en la historia del paciente para que el terapista realice el
mejor servicio de terapias.
En adicción, los autores tienen la oportunidad de acceder a un reporte sobre las
consultas y numero de terapias del mes. Esto también genera un mejor control sobre el
número de servicios y los pagos realizados.
Otros beneficios relevantes de la automatización es la disminución del consumo de
papel promoviendo el cuidado del medio ambiente brindado así una imagen
ecoamigable de la empresa y también la pérdida y duplicidad de información de los
pacientes, lo cual sucedía con frecuencia y generaba incomodidad en los mismos.
117
RECOMENDACIONES
 Se le recomienda seguir usando el sistema para una mejor distribución tanto
los usuarios como el control de pacientes atendidos en la clínica.
 Buscar estudiar las probabilidades de aplicar el mismo sistema en otras áreas.
 Utilizar la automatización en el área de terapias para ejercer control sobre los
pagos y cantidad de servicios realizados.
 Buscar lograr la disminución del consumo de papel mediante la
automatización también en otras áreas, para apoyar al cuidado del medio
ambiente y continuar con el perfil ecoamigable logrado.
 Incitar al trabajo colectivo entre doctor y el terapista mediante el uso del nuevo
sistema automatizado.
118
REFERENCIAS BIBLIOGRAFICAS
Clínica San Judas Tadeo. (s.f.). Recuperado de

http://www.clinicasanjudastadeo.com.pe/nosotros
Ramos, H & Espadín, S (2018) Factores de riesgo en el desarrollo de trastornos

muscoesqueléticos de obreros de una empresa de transporte de Lima – Huacho,
Marzo 2018. Universidad Peruana Cayetano Heredia. Lima, Perú. Recuperado de
http://repositorio.upch.edu.pe/bitstream/handle/upch/3685/Factores_RamosRojas
_Helen.pdf?sequence=1&isAllowed=y
Zambrano, V (2017) Grado de calidad de la atención que recibe el paciente por parte del
terapeuta físico en el hospital Pablo Arturo Suarez en diciembre del 2016. Pontificia
Universidad Católica del Ecuador. Quito, Ecuador. Recuperado de
http://repositorio.puce.edu.ec/bitstream/handle/22000/13718/tesis%20final
%20pdf.pdf?sequence=1&isAllowed=y
Instituto Nacional de Estadística e Informática (2018), Situación de la Población Adulta

Mayor. Recuperado de https://www.inei.gob.pe/media/MenuRecursivo/boletines/01-
informe-tecnico-n01_adulto-oct-nov-dic2018.pdf
Grandez Aguilar, J.C. (2017) Sistema informático web para el control de historias clínicas
electrónicas de la red de salud Tupac Amaru. Universidad Cesar Vallejo. Lima, Perú.
Recuperado de
http://repositorio.ucv.edu.pe/bitstream/handle/UCV/1495/Grandez_AJC.pdf?
sequence=1&isAllowed=y
Herrera Trujillo, L.A. (2018) Propuesta de modelo de gestión por procesos para el
cumplimiento oportuno de los pagos a los proveedores de la empresa Robert Bosch
S.A.C. Universidad Ricardo Palma. Lima, Perú. Recuperado de
http://repositorio.urp.edu.pe/bitstream/handle/URP/1659/Tesis-Luis%20Herrera
%206.pdf?sequence=1&isAllowed=y
La Rosa, D & Mendoza, A. (2017). Implementación de un sistema de información para la
administración de pacientes de la Clínica Privada Cínife. Universidad de Ciencias y
Humanidades, Lima, Perú. Recuperado de
http://repositorio.uch.edu.pe/bitstream/handle/uch/97/CD-TISI-019-2017.pdf?
Alvarado Mendoza, M. (2017) percepción de los alumnos de pregrado de la historia clínica
electrónica del sistema de gestión clínica docente de la facultad de estomatología de
la Universidad Peruana Cayetano Heredia, Lima-Perú, 2017. Universidad Peruana
Cayetano Heredia, Lima, Perú. Recuperado de
http://repositorio.upch.edu.pe/bitstream/handle/upch/839/Percepcion_AlvaradoMendo
za_Maria.pdf?sequence=3&isAllowed=y
Instituto Nacional de Estadística e Informática (2018b), Producción Nacional. Recuperado de
https://www.inei.gob.pe/media/MenuRecursivo/boletines/informe-tecnico-de-
produccion.pdf
119
Veliz Prudencio, L. J. (2017) Propuesta de un sistema informático para mejorar la
organización de historias clínicas en el centro de salud Ganimedes de SJL, 2016.
Universidad Privada Norbert Wiener. Lima, Perú. Recuperado de
http://repositorio.uwiener.edu.pe/bitstream/handle/123456789/483/Tesis_VelizPru
dencio_LuisJavier.pdf?sequence=1&isAllowed=y
Antecedentes:
Vergara, L (2010) Desarrollo de la Medicina Física y Rehabilitación como especialidad
médica. Revista Hospital Clínico Universidad de Chile, Chile. Recuperado de
http://repositoriocdpd.net:8080/bitstream/handle/123456789/80/Art_LoretoVergar
aB_DesarrolloMedicinaFisica_2010.pdf?sequence=1
Gutarra, C & Quiroga, R. (2014) Implementación de un sistema de historias clínicas

electrónicas para el centro de salud Perú 3ra Zona. Universidad San Marín de
Porres, Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/1463/3/gutarra_mcr_c
ompleta.pdf
Carrión Abollaneda, V. (2015) Desarrollo de una aplicación web basada en el modelo vista
controlador para la gestión de las historias clínicas de los pacientes en el centro de
salud de San Jerónimo. Universidad Nacional José María Arguedas, Andahuaylas,
Perú. Recuperado de
http://repositorio.unajma.edu.pe/bitstream/handle/123456789/177/10-2015-EPIS-
%20Carrion%20Abollaneda%20Victor-desarrollo%20de%20una%20apliccacion
%20web%20modelo%20vista.pdf?sequence=1&isAllowed=y
Ruíz Yovera, G. (2017) Desarrollo e implementación de proceso de cajas en Clínica Belén-
Sanna. Universidad de Piura. Piura, Perú. Recuperado de
https://pirhua.udep.edu.pe/bitstream/handle/11042/3203/TSP_CyA_011.pdf?
Albán, J &Fuentes Y. (2018) Desarrollo de aplicación web para la gestión de historial

médico de pacientes de la clínica. Universidad Politécnica Salesiana, Guayaquil,
Ecuador. Recuperado de
https://dspace.ups.edu.ec/bitstream/123456789/15744/1/UPS-GT002204.pdf
Pairazaman, L & Vigo, E. (2017) Sistema de información web para el mejor control y acceso
a las historias clínicas de los pacientes del centro de salud Jequetepeque.
Universidad Nacional de Trujillo, Trujillo, Perú. Recuperado de
http://dspace.unitru.edu.pe/bitstream/handle/UNITRU/9588/PAIRAZAMAN
%20ESTEVES%20Luis%20Alfredo%3b%20VIGO%20ESCALANTE%20Erick
%20Anthony.pdf?sequence=1&isAllowed=y
Bases Teóricas:
Barca Fernández, I. (2018) Impacto de la medicina física y rehabilitación en el pronóstico
funcional de los pacientes con tumor cerebral primario glial. Universidad
120
Complutense de Madrid, Madrid, España. Recuperado de
https://eprints.ucm.es/47024/1/T39776.pdf
Castillo Hernández, C. (2017) Propuesta de implementación del área de fisioterapia en el
hospital “Dr, Jorge Vides Molina”, estudio realizado en el Hospital Nacional de
Huehuetenango, Guatemala. Universidad Rafael Landívar. Quetzaltenango,
Guatemala. Recuperado de
http://recursosbiblio.url.edu.gt/tesisjcem/2017/09/01/Castillo-Cinthia.pdf
Chuquilin, S &Vásquez H. (2018) Historia clínica electrónica como herramienta de mejora

en calidad de atención en la consulta externa hospital Ocatvio Mongrut, 2015.
Universidad Privada Antonio Guillermo Urrelo, Cajamarca, Perú. Recuperado de
http://repositorio.upagu.edu.pe/bitstream/handle/UPAGU/663/Informe%20Final
%20de%20Tesis.pdf?sequence=1&isAllowed=y
Espinoza Ñaña, J. (2015) Impacto de la medicina física y rehabilitación en el pronóstico
funcional de los pacientes con tumor cerebral primario glial. Universidad San Martin
de Porres, Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/2079/1/espinoza_jc.pd
f
Anso Borda, I (2018). Manual de codificación CIE-10-ES diagnósticos. Edición 2018.
Recuperado de
https://www.mscbs.gob.es/estadEstudios/estadisticas/normalizacion/CIE10/CIE10ES
_2018_norm_MANUAL_CODIF_DIAG_.pdf
Arias Muñoz, M. (2018) Desarrollo de una aplicación web para la mejora del control de
asistencia de personal en la Escuela Tecnológica Superior de la Universidad
Nacional de Piura. Universidad Inca Garcilaso de la Vega, Lima, Perú. Recuperado
de http://repositorio.uigv.edu.pe/bitstream/handle/20.500.11818/2930/TESIS-
MARCO%20ANTONIO%20ARIAS%20MU%C3%91OZ.pdf?
Arce, A. (2018) Programación PHP. Recuperado de
https://buildmedia.readthedocs.org/media/pdf/programacion-php/latest/programacion-
php.pdf
Quintanilla Callañaupa, V. (2017) Sistema de gestión de historial clínico para el área de
salud ocupacional de la clínica S.O Tu Salud S.A.C. Universidad Andina del Cusco,
Cusco, Perú. Recuperado de http://repositorio.uandina.edu.pe/bitstream/UAC/999/3/V
%C3%ADctor_Tesis_bachiller_2017.pdf
Álvarez, M. (s.f) Manual de CodeIgniter. Recuperado de
http://roa.ult.edu.cu/bitstream/123456789/3771/1/manual-codeigniter.pdf
Vergara Pérez, R. (2015) Desarrollo de una aplicación móvil para apoyar las supervisiones a
entidades prestadoras de servicio de salud. Universidad Nacional Mayor de San
Marcos, Lima, Perú. Recuperado de
http://cybertesis.unmsm.edu.pe/bitstream/handle/cybertesis/5302/Vergara_pr.pdf?
Babilón, L & Zamorano C. (2016) Diseño de un aplicativo móvil para el seguimiento del
cuidado y desarrollo de los niños en una guardería. Universidad San Martin de
121
Porres, Lima, Perú. Recuperado de
http://www.repositorioacademico.usmp.edu.pe/bitstream/usmp/2440/1/babilon_z
amorano.pdf
Shojaee, H (s.f.). Metodología Agile y Scrum. Recuperado de

https://agile.structuralia.com/files/Documentacion.pdf
Trigas Gallego, M (s.f.) Metodología Scrum. Recuperado de

http://openaccess.uoc.edu/webapps/o2/bitstream/10609/17885/1/mtrigasTFC0612me
moria.pdf
Palacio, J (2015) Scrum Manager I. Recuperado de
https://www.scrummanager.net/files/scrum_I.pdf
Oviedo Ochoa, L (2016) Modelo de iniciación y planeación de proyectos para la empresa
Chemtreat. Universidad Industrial de Santander, Santander, Colombia. Recuperado de
http://tangara.uis.edu.co/biblioweb/tesis/2016/165182.pdf
Instituto Tecnológico Superior de Lerdo (2019) Ciencia, Ingeniería y Desarrollo Tec Lerdo.
Recuperado de
http://revistacid.itslerdo.edu.mx/coninci2019/CONINCI2019.pdf
Ferré, X & Sánchez M (s.f) Desarrollo orientado a objetos con UML. Universidad Pontificia
de México. CDMX, México. Recuperado de
https://www.uv.mx/personal/maymendez/files/2011/05/umlTotal.pdf
Álvarez M (2011) Manual del JQuery. Recuperado de

https://www.lawebdelprogramador.com/pdf/14230-Manual-de-JQuery.html
Peñas, J & Reyero L (2012) JLOP (Json Language Oriented Processing). Universidad
Computlense Madrid. Madrid, España. Recuperado de
https://eprints.ucm.es/16693/1/Memoria_JLOPfinal.pdf
Eguíluz Pérez, J (2008) Introducción a AJAX. Recuperado de

https://www.jesusda.com/docs/ebooks/introduccion_ajax.pdf
Monie, R (2013) En GitHub. Recuperado de https://github.com/robmonie/jquery-week-

calendar/wiki
Muro Giurfa, F. (2015) Optimización en el proceso de consulta externa mediante un sistema

web y web móvil de atención medica dinámica con cálculo de riesgo cardiovascular
empleando la formula Framingham. Universidad Ricardo Palma, Lima, Perú.
Recuperado de http://cybertesis.urp.edu.pe/bitstream/urp/1130/1/muro_f.pdf
UEMS (2009) Libro blanco de medicina física y rehabilitación en Europa. España.
Recuperado de http://www.whitebookprm.eu/wp-
content/uploads/2017/01/SPANISH-VERSION-PRM-WHITE-BOOK-.pdf
Adrianzén Ronceros, E (s.f.) En Hospital Central FAP. Recuperado de

https://hospi.fap.mil.pe/
122
Suárez, F & Ordóñez A (2012) Aspectos éticos de la información médica: principios de uso y
usuario apropiado de sistemas computacionales en la atención clínica. Instituto de
Genética Humana. Facultad de Medicina. Bogotá, Colombia. Recuperado de
https://scielo.conicyt.cl/pdf/abioeth/v18n2/art08.pdf
Smartsheet (2019) Proyecto CSJT-CP con diagrama de Gantt. Recuperado de

https://app.smartsheet.com/sheets/CWwrpX8QvXVqh9c8QrwM75mrg24jHRP27vM
97FJ1
123
ANEXOS
En esta sección se encuentran anexos que sirven de información
complementaria para los diversos temas tocados en los capítulos anteriores.
124
ANEXO 1:
Evidencia 1 - Parte 1
Elaboración: Clínica San Judas Tadeo
Figura 99. Cartón Azul para Terapias – Parte 1
125
ANEXO 2:
Evidencia 1 – Parte 2
Figura 100. Cartón Azul para Terapias - Parte 2
126
ANEXO 3:
Evidencia 2
Figura 101. Cronograma de Atención por Agente de Tratamiento
127
ANEXO 4:
Evidencia 3
Figura 102. Compromiso de Pago de Terapias
128
ANEXO 5:
Análisis de Involucrados
Elaboración: Autores
Figura 103. Análisis de Involucrados
129
ANEXO 6:
130
Árbol de Problemas
131
Figura 104. Árbol de Problemas
ANEXO 7:
132
Árbol de Objetivos
133
Figura 105. Árbol de Objetivos
ANEXO 8:
134
Ishikawa
Figura 106. Ishikawa
135
136
ANEXO 9:
Proceso de Negocio AS – IS
Elaboración: Autores Bizagi Modeler
Figura 107. Proceso de Negocio AS – IS
137
ANEXO 10:
Ficha de Proceso de Negocio
Figura 108. Ficha de Proceso de Negocio
ANEXO 11:
138
Modelo de Negocio
Figura 109. CANVAS
139
ANEXO 12:
Proceso Propuesto TO-BE
140
Figura 110. Proceso Propuesto TO – BE
141
ANEXO 13:
Proceso TO-BE Modulo de Gestión de Terapias
Figura 111. Módulo de Gestión de Terapias TO – BE
142
ANEXO 14:
Proceso TO-BE Modulo de Control de Terapias
Figura 112. Módulo de Control de Terapias TO – BE
ANEXO 15:
143
Proceso TO-BE Modulo de Evaluación de Terapias
Elaboración: Autores usando Bizagi Modeler
Figura 113. Módulo de Evaluación de Terapias TO – BE
ANEXO 16:
Proceso TO-BE Proceso de Atención al Paciente
144
Elaboración: Autores usando Bizagi Modeler
Figura 114. Proceso de Atención al Paciente TO – BE
ANEXO 17:
Elementos de Notación
145
Elab
oración: Autores
Figura 115. Elementos de Notación
ANEXO 18:
Relación de Actores
146
Elaboración: Autores utilizando IBM-RSA
Figura 116. Relación de Actores del Sistema
147
ANEXO 19:
Diagrama de Casos de Uso Estructurado
Elaboración: Autores utilizando IBM-RSA

Figura 117. Diagrama de Casos de Uso Estructurado del Sistema
148
ANEXO 20:
Elaboración Del Backlog Inicial – Sujeto a Cambios
Elaboración: Autores utilizando la herramienta de iceScrum

Figura 118. Elaboración del Backlog Inicial
149
ANEXO 21:
Priorización de casos de uso del sistema
PRIORIZACION
PRIORIZACIONDE
DE CASOS
CASOS DE
DE USO
USODEL
DEL SISTEMA
SISTEMA
AUTOMATIZACIÓN
AUTOMATIZACIÓNDEL
DELPROCESO
PROCESO DE
DE CONTROL
CONTROLDE
DE TERAPIAS
TERAPIAS PARA PARA LALA DISTRIBUCIÓN
DISTRIBUCIÓNDE DE PACIENTES
PACIENTES EN
ENAGENTES
AGENTES DE
DE TRATAMIENTOS
TRATAMIENTOS EN
ENELELÁREA
ÁREA DE
DE MEDICINA
MEDICINA
FÍSICA
FÍSICA DEDE LA
LA CLÍNICA
CLÍNICA SAN SANJUDAS
JUDAS TADEO
TADEO
0.4
0.4 0.3
0.3 0.2
0.2 0.1
0.1
ACTOR
ACTOR CASO
CASO DE DE USO
USO IMPORTANCIA
IMPORTANCIA COMPLEJIDAD
COMPLEJIDAD RIESGO
RIESGO IMPACTO
IMPACTO TOTAL
TOTAL
11 DOCTOR
DOCTOR Atender
Atender Pacientes
Pacientes 10
10 10
10 99 99 9.7
9.7
22 SECRETARIA,TERAPISTA
SECRETARIA,TERAPISTA Generar
GenerarCronograma
Cronograma de de Atencion
Atencion 10
10 10
10 99 88 9.6
9.6
33 SECRETARIA
SECRETARIA Reservar
Reservar Cita
Cita 10
10 99 99 77 9.2
9.2
44 SECRETARIA,DOCTOR(EXCLUDE)
SECRETARIA,DOCTOR(EXCLUDE) Generar
GenerarHistoria
Historia Clinica
Clinica 10
10 88 99 88 9.0
9.0
55 DOCTOR(INCLUDE)
DOCTOR(INCLUDE) Registrar
Registrar Historia
Historia Clinica
Clinica dede Paciente
Paciente 99 88 99 88 8.6
8.6
66 SECRETARIA(EXCLUDE)
SECRETARIA(EXCLUDE) Pagar
Pagar Atencion
Atencion 99 88 77 88 8.2
8.2
77 TERAPISTA
TERAPISTA Tratar
Tratar al
al Paciente
Paciente 88 77 77 88 7.5
7.5
88 ADMINISTRADOR
ADMINISTRADOR Registrar
Registrar Horarios
Horariosde de Atencion
Atencion 88 77 77 66 7.3
7.3
SECRETARIA,TERAPISTA Visualizar
Visualizar Antecedentes
Antecedentesen en el
el Área
Área 77 77 77 10
10 7.3
7.3
10
10 SECRETARIA
SECRETARIA Reportar
Reportar Atenciones
Atencionesen enel el Área
Área 99 66 77 55 7.3
7.3
11
11 SECRETARIA
SECRETARIA Asignar
AsignarZonas
Zonasde de Tratamiento
Tratamiento 99 66 77 44 7.2
7.2
12
SECRETARIA,TERAPISTA Listar
Listar Cronograma
Cronograma de de Atencion
Atencion aa Terapias
Terapias 88 77 66 66 7.1
7.1
13
13 SECRETARIA
SECRETARIA Reportar
Reportar Ingresos
Ingresosenenelel Área
Área 77 88 66 66 7.0
7.0
14
14 ADMINISTRADOR
ADMINISTRADOR Mantener
Mantener Personal
Personal 77 77 66 66 6.7
6.7
15
15 ADMINISTRADOR,SECRETARIA(INCLUDE)
ADMINISTRADOR,SECRETARIA(INCLUDE) Buscar
Buscar Personal
Personal 66 77 66 99 6.6
6.6
16
16 SECRETARIA(INCLUDE)
SECRETARIA(INCLUDE) Buscar
Buscar Doctores
Doctores 66 77 66 99 6.6
6.6
17
17 SECRETARIA(INCLUDE)
SECRETARIA(INCLUDE) Buscar
Buscar Terapista
Terapista 66 77 66 99 6.6
6.6
18
18 ADMINISTRADOR
ADMINISTRADOR Mantener Pacientes
Mantener Pacientes 88 66 55 55 6.5
6.5
19
19 ADMINISTRADOR,SECRETARIA,DOCTOR(INCLUDE)
ADMINISTRADOR,SECRETARIA,DOCTOR(INCLUDE) Buscar Pacientes
Buscar Pacientes 88 66 55 44 6.4
6.4
20
20 ADMINISTRADOR
ADMINISTRADOR Mantener Diagnosticos
Mantener Diagnosticos CIE10CIE10 88 66 55 44 6.4
6.4
21
21 ADMINISTRADOR,DOCTOR(INCLUDE)
ADMINISTRADOR,DOCTOR(INCLUDE) Buscar Diagnosticos CIE10
Buscar Diagnosticos CIE10 77 77 55 44 6.3
6.3
22
22 ADMINISTRADOR
ADMINISTRADOR Mantener Consultorio
Mantener Consultorio 77 77 55 44 6.3
6.3
23
23 ADMINISTRADOR(INCLUDE)
ADMINISTRADOR(INCLUDE) Buscar Consultorio
Buscar Consultorio 77 66 55 66 6.2
6.2
24
24 ADMINISTRADOR
ADMINISTRADOR Mantener Zona de Tratamiento
Mantener Zona de Tratamiento 77 66 55 55 6.1
6.1
25
ADMINISTRADOR(INCLUDE) Buscar Zona de Tratamiento
Buscar Zona de Tratamiento 77 66 55 55 6.1
6.1
26
26 ADMINISTRADOR
ADMINISTRADOR Mantener Agente de Tratamiento
Mantener Agente de Tratamiento 77 55 55 77 6.0
6.0
27
ADMINISTRADOR(INCLUDE) Buscar Agente de Tratamiento
Buscar Agente de Tratamiento 77 55 55 66 5.9
5.9
28
28 ADMINISTRADOR
ADMINISTRADOR Mantener Terapias
Mantener Terapias 77 55 55 55 5.8
5.8
29
29 ADMINISTRADOR
ADMINISTRADOR Mantener Usuario
Mantener Usuario 77 55 55 44 5.7
5.7
30
ADMINISTRADOR(INCLUDE) Buscar Usuario
Buscar Usuario 77 55 55 44 5.7
5.7
31
31 ADMINISTRADOR
ADMINISTRADOR Mantener Perfil
Mantener Perfil 77 55 44 44 5.5
5.5
32
ADMINISTRADOR(INCLUDE) Buscar Perfil
Buscar Perfil 77 44 55 44 5.4
5.4
33
33 USUARIO
USUARIO Iniciar Sesion
Iniciar Sesion 66 55 33 66 5.1
5.1
Figura 119. Priorización de Casos de Uso del Sistema
150
ANEXO 22:
Pruebas Unitarias
Elaboración: Autores con Herramienta IceScrum

Figura 120. Pruebas Unitarias
151
ANEXO 23:
Pruebas Unitarias

152
ANEXO 24:
Pruebas Unitarias

153
ANEXO 25:
Pruebas Unitarias

154

Tesis Final

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

Tesis Final

Cargado por

Copyright:

Formatos disponibles

FACULTAD DE INGENIERÍA Y ARQUITECTURA

ESCUELA PROFESIONAL DE INGENIERÍA DE COMPUTACIÓN Y SISTEMAS

AUTOMATIZACIÓN DEL PROCESO DE CONTROL DE TERAPIAS

Agradezco a Dios por cada detalle y momento durante la realización de la tesis,

La investigación de esta tesis va desde el análisis, diseño e implementación de un

área de medicina física y rehabilitación. En la actualidad el área de medicina física y

elaboración de cronogramas para la atención de las terapias programadas en cierto horario

respectivo según el tratamiento que se le indique.

La finalidad de un Sistema de Información de Salud es gestionar de una manera

ámbito hospitalario. El manejo de información médica automatizada puede mejorar

significativamente la asistencia al paciente, reduciendo errores al acelerar el flujo de órdenes

PLANTEAMIENTO DEL PROBLEMA

1.1 Descripción de la situación problemática

La labor de la clínica es “Satisfacer con eficiencia, calidad y alto nivel

profesional a las necesidades en el ámbito de la salud de todas aquellas personas que

requieran atención médica.” (Clínica San Judas Tadeo, s.f.).

muscoesqueléticos (TME) suponen un 45% de las lesiones profesionales”. Por ello, es

considerado como el trastorno con mayor registro de atención.

Asimismo, Zambrano, V. (2017, p.16) nos comenta que “Tomando en cuenta

expectativas, este proceso debe tener un constante seguimiento y modificación de la

satisfacción del paciente.

El Instituto Nacional de Estadística e Informática ([INEI], 2018, p.9) argumenta

establecimiento de salud es la distancia de este y demora en la atención.”. Siendo la

paciente, es necesario evaluar este proceso y examinar que factores dilatan en la

Clínica San Judas Tadeo.

Gracias a la tesis de Grandez Aguilar, J.C. (2017, p.4), entendemos lo siguiente

en los establecimientos de salud, esto se ocasiona en el área de admisión al momento

espera es dilatado en el proceso que inicia en el área de admisión desde la apertura de

la historia clínica hasta la atención de los pacientes en sus diferentes agentes de

tratamientos, lo cual afecta la calidad atención brindada al paciente.

El tener la documentación manualmente perjudica y aumenta el tiempo de

Medicina Física y Rehabilitación donde se muestran las evidencias (Anexos 1,2,3,4).

estudio se pudo observar un deficiente trabajo en equipo, además de una deficiente

(…) la empresa. (p.1).

Asimismo, “las consecuencias que este problema trae para la administración de

pacientes son los siguientes: duplicación de historias clínicas con la misma

identificación de pacientes, riesgos de pérdida de información (historias clínicas),

atraso en la búsqueda, etc.” (La Rosa y Mendoza, 2017, p.12)

Referido a la Historia Clínica Electrónica, según Alvarado Mendoza, M (2017,

los pacientes y se pierde menos tiempo en las consultas y seguimiento de los

ondulado y de envases de papel y cartón aumentó en 17,86%, por producción de

mejor efectividad en el rendimiento de los trabajadores del área respecto al

diagnóstico, seguimiento y tratamiento de los pacientes”. (Alvarado Mendoza,

La realización de la documentación manual previamente mencionada, también

se traduce en un inconcluso seguimiento digital en el servicio de terapias, demorando

el proceso y generando un riesgo de pérdida de datos o documentos. Según Veliz

Prudencio, L. J. (2017, p.23) nos comenta en su tesis que, su proceso comienza al

generar la relación de los pacientes. Luego, se ha de buscar la historia indicada, lo

cual tomará un tiempo indeterminado de búsqueda. Debido a que existe la posibilidad

de que la historia no esté en su lugar. De no ser encontrada generará un problema

con el registro de todas sus citas previas.

Actualmente la excesiva documentación en el proceso es tedioso. Además, las

demoras en las atenciones causan la necesidad de agilizar las labores del área. Para

esto el problema consiste en la deficiencia del proceso de control de terapias de los

pacientes del área de medicina física de la Clínica San Judas Tadeo.

1.2.1. Problema General

¿Cómo mitigar las dificultades encontradas en la gestión de distribución

de pacientes en el área de medicina física y rehabilitación de la Clínica San

1.2.2. Problemas Específicos

a) ¿Cómo se identificarán las principales dificultades en el proceso de control

de terapias del área de Medicina Física y Rehabilitación?

b) ¿De qué manera se espera optimizar el proceso de control de terapias del

área de Medicina Física y Rehabilitación?