0% encontró este documento útil (0 votos)
28 vistas152 páginas

Mendoza Salinas Sistema Web para Registro de Pacientes Clínica

Este documento presenta una tesis para obtener el grado de Maestría en Ingeniería de Sistemas con mención en Tecnologías de la Información. La tesis propone desarrollar un sistema modular web para mejorar el proceso de registro de pacientes en un centro médico en Iquitos. El documento incluye la dedicatoria, agradecimientos, declaración de autenticidad y presentación de la tesis.

Cargado por

El tio Marchele
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
0% encontró este documento útil (0 votos)
28 vistas152 páginas

Mendoza Salinas Sistema Web para Registro de Pacientes Clínica

Este documento presenta una tesis para obtener el grado de Maestría en Ingeniería de Sistemas con mención en Tecnologías de la Información. La tesis propone desarrollar un sistema modular web para mejorar el proceso de registro de pacientes en un centro médico en Iquitos. El documento incluye la dedicatoria, agradecimientos, declaración de autenticidad y presentación de la tesis.

Cargado por

El tio Marchele
Derechos de autor
© © All Rights Reserved
Nos tomamos en serio los derechos de los contenidos. Si sospechas que se trata de tu contenido, reclámalo aquí.
Formatos disponibles
Descarga como PDF, TXT o lee en línea desde Scribd
Está en la página 1/ 152

“Sistema modular web para mejorar el proceso de registro

de pacientes en el centro médico FDA BIOSERVICES,


Iquitos.”

TESIS PARA OBTENER EL GRADO ACADÉMICO DE:


Maestro en Ingeniería de Sistemas con Mención en Tecnologías de la
Información.

AUTORES:
Br. Lee Frank Mendoza López.
Br. Juan Carlos Salinas Ruiz.

ASESOR:
Dr. Juan Francisco Pacheco Torres.

SECCIÓN:
Ingeniería.

LÍNEA DE INVESTIGACIÓN:
Sistemas de Información y Comunicaciones.

PERU 2018
PÁGINA DEL JURADO

El presidente y los miembros del jurado evaluador que son designados por la
Escuela de Ingeniería de Sistemas.

APRUEBAN

La tesis denominada:

“SISTEMA MODULAR WEB PARA MEJORAR EL PROCESO DE REGISTRO DE


PACIENTES EN EL CENTRO MÉDICO FDA BIOSERVICES, IQUITOS”

Aprobado por:

______________________________
Dra. Rodríguez Peña Milagros Janet

_________________________ ____________________________
Dr. Espinoza Polo Francisco A. Dr. Pacheco Torres Juan Francisco

2
DEDICATORIA

A DIOS:
A nuestro padre celestial Dios
que me brinda su amor cada día
y creador de todas las cosas y
participe en todos mis proyectos.

A MI FAMILIA:
Quienes nos aconsejan, apoyan y educan
a ser personas de bien con valores y
principios, de quienes aprendimos a ser
fuertes y perseverantes hasta conseguir
todos nuestros objetivos.

A MI NOVIA:
Por su determinante paciencia en
cada momento, por brindarme su
amor puro y verdadero y sobre todo
alentándome a ser mejor cada día.

Lee Frank.

3
DEDICATORIA

A MI PADRE:
Por haberme dado la vida y la
fuerza para seguir adelante.

A MI MAMA:
Por el apoyo brindado y el ejemplo de
lucha y superación constante.

A MI FAMILIA:
Por el apoyo brindado en el largo
camino de la vida.

Juan Carlos.

4
AGRADECIMIENTO

En primer lugar, agradecer a la Universidad Cesar Vallejo, por brindarnos las


facilidades con las aulas, los docentes y asesores para realizar nuestro trabajo de
investigación aplicando lo aprendido.

Al centro médico “FDA BIOSERVICES” que mantiene un convenio con la Sociedad


de Beneficencia Pública de Iquitos, por brindarnos las facilidades, el apoyo
constante y las coordinaciones respectivas para la realización en nuestro trabajo
de investigación y a toda su plana laboral por ser serviciales y amables en todo
momento.

A nuestros amigos, colegas y colaboradores que nos empujaron al esfuerzo


constante y perseverancia para conseguir todos nuestros objetivos profesionales y
personales para contribuir a la mejora en la nuestra sociedad.

Por último, queremos agradecer enormemente a todas las personas que


participaron de forma indirecta o directamente nos brindaron su colaboración,
consultoría y consejos parar realizar el siguiente trabajo de investigación, además
también agradecer a todos docentes de la maestría por su calidad de
profesionalismo bien preparados que nos transmitieron todos sus experiencias y
conocimientos en el tiempo que compartimos en los salones de clase.

Los Autores.

5
DECLARACIÓN DE AUTENTICIDAD

Nosotros, Lee Frank Mendoza López identificado con DNI 43878184 y Juan
Carlos Salinas Ruiz identificado con DNI 80509426, estudiantes del Programa de
Maestría en Ingeniería de Sistemas con Mención en Tecnologías de la Información
de la Escuela de Posgrado de la Universidad César Vallejo de la tesis titulada como:

“SISTEMA MODULAR WEB PARA MEJORAR EL PROCESO DE REGISTRO DE


PACIENTES EN EL CENTRO MÉDICO FDA BIOSERVICES, IQUITOS”,
declaramos bajo juramento que:

1) La tesis es de nuestra autoría.


2) Hemos respetado las normas internacionales de citas y referencias para las
fuentes consultadas. Por tanto, la tesis no ha sido plagiada ni total ni
parcialmente.
3) La tesis no ha sido auto plagiada; es decir, no ha sido publicada ni presentada
anteriormente para obtener algún grado académico previo o título profesional.
4) Los datos presentados en los resultados son reales, no han sido falseados, ni
duplicados, ni copiados y por tanto los resultados que se presenten en la tesis
se constituirán en aportes a la realidad investigada.

De identificarse la falta de fraude (datos falsos), plagio (información sin citar a


autores), autoplagio (presentar como nuevo algún trabajo de investigación propio
que ya ha sido publicado), piratería (uso ilegal de información ajena) o falsificación
(representar falsamente las ideas de otros), asumo las consecuencias y sanciones
que de mi acción se deriven, sometiéndome a la normatividad vigente de la
Universidad César Vallejo
Trujillo, agosto del 2018.

Firma: ___________________ Firma: __________________


Br. Lee Frank Mendoza López. Br. Juan Carlos Salinas Ruiz.
DNI: 43878184. DNI: 80509426.

6
PRESENTACIÓN

Estimados miembros del jurado, presentamos nuestra tesis titulada “SISTEMA


MODULAR WEB PARA MEJORAR EL PROCESO DE REGISTRO DE
PACIENTES EN EL CENTRO MÉDICO FDA BIOSERVICES, IQUITOS”, en
cumplimiento del reglamento de Grados y Títulos de la Universidad Cesar Vallejo
para obtener del Grado Académico de: Maestro en Ingeniería de Sistemas con
Mención en Tecnologías de la Información.

Esperando cumplir con todos los requisitos brindados por la institución para la
aprobación respectiva.

Los Autores.

7
INDICE GENERAL
PÁGINA DEL JURADO __________________________________________________ 2
DEDICATORIA _________________________________________________________ 3
DEDICATORIA _________________________________________________________ 4
AGRADECIMIENTO _____________________________________________________ 5
DECLARACIÓN DE AUTENTICIDAD ______________________________________ 6
PRESENTACIÓN _______________________________________________________ 7
INDICE DE ILUSTRACIONES ___________________________________________ 11
RESUMEN ____________________________________________________________ 15
ABSTRACT ___________________________________________________________ 16
CAPÍTULO I: INTRODUCCIÓN __________________________________________ 17
1.1. Realidad Problemática _______________________________________________ 18
1.2. Trabajos Previos ____________________________________________________ 22
1.2.1. Internacional ____________________________________________________________ 22
1.2.2. Nacional ________________________________________________________________ 23
1.2.3. Local ___________________________________________________________________ 24
1.3. Teorías Relacionadas al Tema ________________________________________ 25
1.3.1. Según la Variable Dependiente ___________________________________________ 25
1.3.2. Según la Variable Independiente__________________________________________ 27

1.3.3. Según la Variable Interviniente _____________________________________ 35


1.4. Formulación del Problema ___________________________________________ 38
1.4.1. Problema General _______________________________________________________ 38
1.4.2. Problemas Específicos___________________________________________________ 38
1.5. Justificación de Estudio _____________________________________________ 39
1.5.1. Justificación Tecnológica ________________________________________________ 39
1.5.2. Justificación Económica _________________________________________________ 41
1.5.3. Justificación Operativa __________________________________________________ 41
1.5.4. Justificación Social ______________________________________________________ 42
1.6. Hipótesis ___________________________________________________________ 43
1.7. Objetivos ___________________________________________________________ 43
1.7.1. Objetivo General_________________________________________________________ 43
1.7.2. Objetivos Específicos ____________________________________________________ 43

CAPÍTULO II: METODO ________________________________________________ 44


2.1. Diseño de la Investigación ___________________________________________ 45
2.1.1. Tipo de diseño __________________________________________________________ 45
2.1.2. Clasificación ____________________________________________________________ 45
2.2. Variables y Operacionalización _______________________________________ 46
2.2.1. Identificación Variables __________________________________________________ 46
2.2.2. Operacionalización de las Variables ______________________________________ 47

8
2.3. Población y Muestra _________________________________________________ 51
2.3.1. Población _______________________________________________________________ 51
2.3.2. Muestra _________________________________________________________________ 51
2.3.3. Muestreo ________________________________________________________________ 51
2.3.4. Población, Muestra y Muestreo por Indicador _____________________________ 52
2.4. Técnicas e Instrumentos de Recolección de Datos, Validez y Confiabilidad
53
2.4.1. Técnicas e Instrumentos de Recolección de Datos ________________________ 53
2.4.2. Validez del Instrumento __________________________________________________ 53
2.4.1. Confiabilidad del Instrumento ____________________________________________ 54

2.5. Métodos de Análisis de Datos ________________________________________ 57


CAPÍTULO III: RESULTADOS ___________________________________________ 62
3.1. Contrastación de Hipótesis __________________________________________ 63
3.1.1. Tiempo promedio en la búsqueda de historias clínicas de los pacientes. ___ 63
3.1.2. Tiempo promedio en la generación de reportes de información de los
pacientes. ________________________________________________________________________ 65
3.1.3. Nivel de Satisfacción de los Pacientes del Centro Médico. _________________ 67
3.1.4. Prueba de Hipótesis Variable Independiente. ______________________________ 70

CAPÍTULO IV: DISCUSIÓN _____________________________________________ 72


CAPÍTULO V: CONCLUSIONES _________________________________________ 78
CAPÍTULO VI: RECOMENDACIONES ____________________________________ 80
CAPÍTULO VI: REFERENCIAS __________________________________________ 82
BIBLIOGRAFICAS _________________________________________________________ 83
ANEXOS ______________________________________________________________ 85
ANEXO 01: “Realidad Problemática” _______________________________________________ 86
Anexo 01 - 1: “Instrumento de Recolección de Datos” ______________________________ 86
Anexo 01 - 2: “Validación del Instrumento de Recolección de Datos” ________________ 87
Anexo 01 - 3: “Validez y Fiabilidad” ________________________________________________ 99
ANEXO 02: “Viabilidad Económica” _______________________________________ 101
2.1. Estudio de Factibilidad __________________________________________ 101
2.1.1. Estructura de Costos __________________________________________ 101
2.1.2. Beneficios del Proyecto _______________________________________ 105
2.1.3. Flujo de Caja__________________________________________________ 107
2.1.4. Análisis de Rentabilidad _______________________________________ 107
ANEXO 03: “Metodología de Desarrollo” __________________________________________ 112
Anexo 03 - 1: “Desarrollo de la Metodología XP” __________________________________ 112
ANEXO 04: “Resultados” ________________________________________________________ 138
Anexo 04 - 1: “Tabla de Distribución Z” ___________________________________________ 138
Anexo 04 - 2: “Tabla de Distribución T-student” ___________________________________ 139
Anexo 04 - 3: “Evaluación de la Variable Independiente” ___________________________ 140
Anexo 04 - 4: “Base de Datos de Indicadores” _____________________________________ 144
ANEXO 05: “Matriz de Consistencia del Proyecto de Investigación” ________________ 147

9
ANEXO 06: “Cartas, Solicitudes y Otros” _________________________________________ 149
Anexo 06 - 1: “Carta de Aceptación de la Empresa”________________________________ 149
Anexo 06 - 2: “Carta de Conformidad de la Empresa” ______________________________ 150
Anexo 07 - 1: “Acta de Originalidad” ______________________________________________ 151
Anexo 07 - 2: “Acta de Originalidad - Turnitin” ____________________________________ 152

10
INDICE DE ILUSTRACIONES

Ilustración 1: Proceso actual del registro de pacientes. _________________________________ 19


Ilustración 2: Sistema de Información.__________________________________________________ 29
Ilustración 3: Organización del Sistema de Administración de Pacientes. ________________ 30
Ilustración 4: Patrón de diseño HMVC. _________________________________________________ 32
Ilustración 5: Ranking de Lenguajes de Programación GitHub. __________________________ 33
Ilustración 6: Ranking de Lenguajes de Programación PYPL. ____________________________ 34
Ilustración 7: Ciclo de vida del desarrollo ágil. __________________________________________ 36
Ilustración 8: Cambio de los costos como función del tiempo transcurrido en el desarrollo.
______________________________________________________________________________________ 37
Ilustración 9: ciclo de vida de desarrollo de software clásico. ____________________________ 37
Ilustración 10: Proceso de la Programación Extrema (XP). _______________________________ 38
Ilustración 11: Clasificación de la Investigación. ________________________________________ 45
Ilustración 12: Confiabilidad del Instrumento - Vista de Datos. ___________________________ 54
Ilustración 13: Confiabilidad del Instrumento - Vista de Variables. _______________________ 55
Ilustración 14: Alfa de Cronbach. ______________________________________________________ 56
Ilustración 15: Estadístico de Diferencia Pareada. _______________________________________ 57
Ilustración 16: Estadístico de Wilcoxon. ________________________________________________ 57
Ilustración 17: Pruebas de Normalidad del Indicador 1. __________________________________ 63
Ilustración 18: Prueba de Muestras Relacionadas con el Indicador 1. ____________________ 63
Ilustración 19: Estadísticas de Muestras Relacionadas del Indicador 1. __________________ 64
Ilustración 20: Tiempo Promedio de Búsqueda de Historias Clínicas del Paciente. ________ 64
Ilustración 21: Pruebas de Normalidad del Indicador 2. __________________________________ 65
Ilustración 22: Prueba de Muestras Relacionadas Indicador 2. ___________________________ 65
Ilustración 23: Estadísticas de Muestras Relacionadas del Indicador 2. __________________ 66
Ilustración 24: Tiempo Promedio en la Generación de Reportes de Información de los
Pacientes. ____________________________________________________________________________ 66
Ilustración 25: Pruebas de Normalidad del Indicador 3. __________________________________ 67
Ilustración 26: Prueba de Rangos con Signo Wilcoxon Indicador 3. ______________________ 67
Ilustración 27: Nivel de Satisfacción de los Pacientes Pre-Test. __________________________ 68
Ilustración 28: Nivel de Satisfacción de los Pacientes Pos-Test. _________________________ 69
Ilustración 29: Encuesta Satisfacción de Pacientes. _____________________________________ 86
Ilustración 30: Validación del Instrumento de Recolección de Datos - Experto 1/1_________ 87
Ilustración 31: Validación del Instrumento de Recolección de Datos - Experto 1/2_________ 88
Ilustración 32: Validación del Instrumento de Recolección de Datos - Experto 1/3_________ 89
Ilustración 33: Validación del Instrumento de Recolección de Datos - Experto 1/4_________ 90
Ilustración 34: Validación del Instrumento de Recolección de Datos - Experto 2/1_________ 91
Ilustración 35: Validación del Instrumento de Recolección de Datos - Experto 2/2_________ 92
Ilustración 36: Validación del Instrumento de Recolección de Datos - Experto 2/3_________ 93
Ilustración 37: Validación del Instrumento de Recolección de Datos - Experto 2/4_________ 94
Ilustración 38: Validación del Instrumento de Recolección de Datos - Experto 3/1_________ 95
Ilustración 39: Validación del Instrumento de Recolección de Datos - Experto 3/2_________ 96
Ilustración 40: Validación del Instrumento de Recolección de Datos - Experto 3/3_________ 97
Ilustración 41: Validación del Instrumento de Recolección de Datos - Experto 3/4_________ 98
Ilustración 42: Flujo de Caja. __________________________________________________________ 107
Ilustración 43: Tasa Interna de Retorno. _______________________________________________ 110
Ilustración 44: Diseño del Modelo Entidad Relación (DER). _____________________________ 121
Ilustración 45: Implementación de la Base de Datos en PostgreSQL. ____________________ 122
Ilustración 46: Implementación del Modelo Relacional en PostgreSQL. __________________ 123
Ilustración 47: Diseño de la Arquitectura de Desarrollo. ________________________________ 123
Ilustración 48: Clase Database en PHP con PDO. ______________________________________ 124

11
Ilustración 49: Clase loginController en PHP. __________________________________________ 125
Ilustración 50: Código JavaScript - Autenticación de Usuario. __________________________ 125
Ilustración 51: Login del Sistema Modular Web. ________________________________________ 126
Ilustración 52: Pantalla Principal del Sistema Modular Web. ____________________________ 126
Ilustración 53: Gestión de Usuario - Listado de Usuarios Registrados. __________________ 127
Ilustración 54: Gestión de Usuario - Registrar Nuevo Usuario. __________________________ 127
Ilustración 55: Gestión de Paciente - Listado de Pacientes Registrados._________________ 128
Ilustración 56: Gestión de Paciente - Registrar Nuevo Paciente. ________________________ 128
Ilustración 57: Gestión de Médico - Listado de Médicos Registrados. ___________________ 129
Ilustración 58: Gestión de Médico - Registrar Nuevo Médico. ___________________________ 129
Ilustración 59: Gestión de Citas - Listado de Citas Registradas. _________________________ 130
Ilustración 60: Gestión de Citas - Registrar Nueva Cita. __________________________________ 130
Ilustración 61: Gestión de Triage - Listado de Citas Triage. _____________________________ 131
Ilustración 62: Gestión de Triage - Registrar Nueva Evaluación Triage. __________________ 131
Ilustración 63: Gestión de Triage - Confirmación de Registro Evaluación Triage._________ 132
Ilustración 64: Gestión de Triage - Reporte de Documento Evaluación Triage. ___________ 132
Ilustración 65: Gestión de Diagnóstico (H.C.) - Listado de Citas con Evaluación Triage. __ 133
Ilustración 66: Gestión de Diagnóstico (H.C.) - Registrar Nuevo Diagnóstico. ____________ 133
Ilustración 67: Gestión de Diagnóstico (H.C.) - Confirmación de Registro de Diagnóstico. 134
Ilustración 68: Gestión de Diagnóstico (H.C.) - Reporte de Documento Diagnóstico Clínico.
_____________________________________________________________________________________ 134
Ilustración 69: Gestión de Diagnóstico (H.C.) - Consultar Historia Clínica. _______________ 135
Ilustración 70: Gestión de Diagnóstico (H.C.) - Reporte de Historia Clínica. ______________ 135
Ilustración 71: Gestión de Receta Médica - Emitir Receta Médica. _______________________ 136
Ilustración 72: Gestión de Receta Médica - Reporte de Documento Receta Médica. ______ 136
Ilustración 73: Gestión de Reportes - Reporte de Atenciones por Médico. _______________ 137
Ilustración 74: Gestión de Reportes - Reporte de Atenciones por Especialidad. __________ 137
Ilustración 75: Tabla de Distribución Z. ________________________________________________ 138
Ilustración 76: Tabla de Distribución T-student. ________________________________________ 139
Ilustración 77: Evaluación de la Variable Independiente - Experto 1. ____________________ 140
Ilustración 78: Evaluación de la Variable Independiente - Experto 2. ____________________ 141
Ilustración 79: Evaluación de la Variable Independiente - Experto 3. ____________________ 142
Ilustración 80: Evaluación de la Variable Independiente - Experto 4. ____________________ 143
Ilustración 81: Data del Indicador N° 1. ________________________________________________ 144
Ilustración 82: Data del Indicador N° 2. ________________________________________________ 145
Ilustración 83: Data del Indicador N° 3. ________________________________________________ 146
Ilustración 84: Carta de Aceptación de la Empresa. ____________________________________ 149
Ilustración 85: Carta de Conformidad de la Empresa. ___________________________________ 150
Ilustración 86: Acta de Originalidad.___________________________________________________ 151
Ilustración 87: Acta de Originalidad - Turnitin. _________________________________________ 152

12
INDICE DE CUADROS
Cuadro 1: Los principios de los métodos ágiles. ________________________________________ 37
Cuadro 2: Operacionalización de la Variable Dependiente._______________________________ 47
Cuadro 3: Operacionalización de la Variable Independiente. _____________________________ 48
Cuadro 4: Indicadores y fórmula de cálculo. ____________________________________________ 50
Cuadro 5: Indicador 01. ________________________________________________________________ 52
Cuadro 6: Indicador 02. ________________________________________________________________ 52
Cuadro 7: Indicador 03. ________________________________________________________________ 52
Cuadro 8: Técnicas e instrumentos de recolección de datos. ____________________________ 53
Cuadro 9: Escala de valoración Alfa de Cronbach. ______________________________________ 56
Cuadro 10: Cuadro sobre Pruebas de Normalidad. ______________________________________ 57
Cuadro 11: Cuadro de Intervalos del Indicador 3. _______________________________________ 68
Cuadro 12: Categorías del Nivel de Satisfacción de los Pacientes Pre-Test. ______________ 68
Cuadro 13: Categorías del Nivel de Satisfacción de los Pacientes Pos-Test. ______________ 69
Cuadro 14: Nivel de Aprobación. _______________________________________________________ 70
Cuadro 15: Nivel de Usabilidad del Software. ___________________________________________ 71
Cuadro 16: Validez con Análisis Factorial - Prueba de KMO y Bartlett. ____________________ 99
Cuadro 17: Validez con Análisis Factorial - Varianza Total Explicada. ____________________ 99
Cuadro 18: Validez con Análisis Factorial - Matriz de Componente Rotado. _______________ 99
Cuadro 19: Fiabilidad con Alfa de Cronbach - Resumen de Procesamiento de Casos. ____ 100
Cuadro 20: Fiabilidad con Alfa de Cronbach - Estadísticas de Fiabilidad. ________________ 100
Cuadro 21: Fiabilidad de Alfa de Cronbach - Estadísticas de Total de Elemento. _________ 100
Cuadro 22: Costos de Inversión - Hardware. ___________________________________________ 101
Cuadro 23: Costos de Inversión - Software. ____________________________________________ 101
Cuadro 24: Costos de Inversión - Recursos Humanos. _________________________________ 102
Cuadro 25: Costos de Inversión - Materiales. __________________________________________ 102
Cuadro 26: Costos de Inversión - Consumo Eléctrico. __________________________________ 103
Cuadro 27: Costos de Inversión - Consumo Eléctrico Mensual. _________________________ 103
Cuadro 28: Costos de Inversión - Materiales. __________________________________________ 104
Cuadro 29: Costos de Inversión - Costos de Mantenimiento.____________________________ 104
Cuadro 30: Costos de Inversión - Costos de Depreciación. _____________________________ 104
Cuadro 31: Costos de inversión - Costos de capacitación.______________________________ 105
Cuadro 32: Tiempo de Ahorro en Horas de Trabajo Mensual. ___________________________ 105
Cuadro 33: Tiempo de Ahorro en Horas de Generación de Reportes. ____________________ 105
Cuadro 34: Ingresos Proyectados. ____________________________________________________ 106
Cuadro 35: Conclusión análisis de rentabilidad. _______________________________________ 111
Cuadro 36: Personas Relacionadas con el Sistema Informático Propuesto. ______________ 112
Cuadro 37: Resumen de Historias de Usuario. _________________________________________ 113
Cuadro 38: Plan de Duración de Iteraciones. ___________________________________________ 114
Cuadro 39: Plan de Duración de la Entrega.____________________________________________ 114
Cuadro 40: Historia de Usuario N° 1 - Autenticar Usuario. ______________________________ 115
Cuadro 41: Historia de Usuario N° 2 - Gestionar Usuario. _______________________________ 115
Cuadro 42: Historia de Usuario N° 3 - Gestionar Paciente. ______________________________ 116
Cuadro 43: Historia de Usuario N° 4 - Gestionar Medicamento. _________________________ 116
Cuadro 44: Historia de Usuario N° 5 - Gestionar Diagnóstico Actividad. _________________ 117
Cuadro 45: Historia de Usuario N° 6 - Gestionar Médico. _______________________________ 117
Cuadro 46: Historia de Usuario N° 7 - Gestionar Citas Médicas. _________________________ 118
Cuadro 47: Historia de Usuario N° 8 - Gestionar Evaluación Triage. _____________________ 118
Cuadro 48: Historia de Usuario N° 9 - Gestionar Diagnóstico (HC). ______________________ 119
Cuadro 49: Historia de Usuario N° 10 - Consultar Diagnóstico (HC). _____________________ 119
Cuadro 50: Historia de Usuario N° 11 - Gestionar Receta Médica. _______________________ 120

13
Cuadro 51: Historia de Usuario N° 12 - Generar Reporte de Atención. ___________________ 120
Cuadro 52: Matriz de Consistencia. ___________________________________________________ 148

14
RESUMEN

El objetivo principal del trabajo realizado es de mejorar el proceso de registro de


pacientes en el centro médico “FDA BIOSERVICES”, a través de la implementación
de un sistema modular web. Actualmente, el establecimiento de servicios de salud
realiza atenciones de salud de diversos indoles entre medicina general y
especialistas que bordean alrededor de 30 atenciones diarias como población y una
muestra universal que es el total de la población. Se uso la prueba de normalidad
con Shapiro-Wilk debido a que la muestra es pequeña y menor a 35, posteriormente
se utiliza la prueba de T-Student y Prueba Z como resultado del análisis de datos
realizados. La metodología de desarrollo aplicada para el sistema modular web se
utilizó el enfoque ágil XP (Programación Extrema). Para el desarrollo del software
se utilizó el lenguaje de Programación PHP y JavaScript y PostgreSQL como gestor
de almacenamiento de datos. Se llego a la conclusión: Para el primer indicador
tiempo promedio en la búsqueda de historias clínicas de los pacientes su tiempo
promedio es de 478,89 minutos con el sistema actual y de 12 minutos con el sistema
propuesto en 40 días con 30 pacientes diarios, habiendo una reducción 473.89
minutos equivalente a 99.87%, el segundo indicador tiempo promedio en la
generación de reportes de información de los pacientes su tiempo promedio es de
152,10 minutos con el sistema actual y de 0.20 minutos con el sistema propuesto
ambos realizados por día, habiendo una reducción de 151.9 minutos equivalente a
99.87%. en el estudio de factibilidad económica. El VAN generó un resultado
25,568.188 > 0, entonces podemos definir la ejecución del proyecto es aceptable.
En la relación de B/C, se generó de acuerdo que por cada S/. 1.00 invertido se
obtiene S/. 0.50 de ganancia. En el TIR se generó como resultado el 68% y es
mayor a la tasa de interés del banco del 15%, esto como resultado que el proyecto
es aceptable, teniendo como recuperación del capital en 1 año, 2meses y 12 días.

Palabra clave: registro de pacientes, sistema modular web, historia clínica, citas
médicas, agilizar registro de pacientes, agilizar búsqueda de historia clínica.

15
ABSTRACT

The main objective of the work carried out is to improve the patient registration
process in the "FDA BIOSERVICES" Medical Center, through the implementation
of a modular web system. At present, the establishment of health services carries
out health care of diverse indoles between general medicine and specialists that
border around 30 daily attentions as population and a universal sample that is the
total of the population. The test of normalcy is used with Shapiro-Wilk because the
sample is small and less than 35, then the T-Student test and Z test are used as a
result of the data analysis performed. The applied development methodology for the
Web modular system was used the agile XP approach (Extreme Programming). For
the development of the software we used the programming language PHP and
JavaScript and PostgreSQL as a data Storage manager. It came to the conclusion:
for the first indicator average time in the search for patient histories their average
time is 478.89 minutes with the current system and 12 minutes with the proposed
system in 40 days with 30 patients daily, having a reduction 473.89 minutes
equivalent to 99.87%, the second indicator average time in the generation of
information reports of patients their average time is 152.10 minutes with the current
system and 0.20 minutes with the proposed system both Made per day, having a
reduction of 151.9 minutes equivalent to 99.87%. In the economic feasibility study.
The VAN generated a result 25,568.188 > 0, then we can define the execution of
the project is acceptable. In the ratio of B/C, it was generated according to each S/.
Inverted 1.00 is obtained S/. 0.50 profit. In TIR was generated as a result 68% and
is higher than the interest rate of the bank of 15%, this as a result that the project is
acceptable, having as recovery of capital in 1 year, 2meses and 12 days.

Keyword: patient registration, Web modular system, clinical history, medical


appointments, expedite patient registration, expedite clinical history search.

16
CAPÍTULO I: INTRODUCCIÓN
1.1. Realidad Problemática
El centro médico FDA BIOSERVICES mantiene un convenio con la Sociedad
de Beneficencia Pública de Iquitos, brinda diversos servicios de salud como
consultorio médico en diferentes especialidades y laboratorio clínico
especializado, al mantener este convenio los costos son de manera
significativa para que todas las personas puedan acceder a los servicios de
salud. En el establecimiento de salud trabajan profesionales de la salud,
administrativos y practicantes que día a día desempeñan sus labores y
funciones en beneficio de los usuarios que requieran utilizar los
mencionados servicios.

Dentro del flujo de trabajo tradicional que se realiza en el centro médico es


el proceso de registro de pacientes que empieza cuando un usuario nuevo
o usuario concurrente acude o ingresa al centro médico y se dirige en
primera instancia al área de admisión para solicitar su cita médica según
corresponda, en el área admisión se evalúa el tipo de diagnóstico que va a
realizar el usuario para luego derivar al área de caja para realizar el pago de
la cita médica correspondiente, luego regresa al área de admisión con su
comprobante de pago para que después realicen la búsqueda de su historia
clínica si es un usuario frecuente o generen su historia clínica si es un usuario
nuevo, con sus datos ya registrados pasan a triage para realizar su
evaluación registrando sus datos como peso, altura, presión arterial, etc.
Después del registro de triage el paciente pasa a una sala de espera para
ser atendido en el consultorio previa llamada, la encargada de triage lleva el
historial clínico del paciente con su comprobante de triage como adjunto al
consultorio médico quien recepciona y llama personalmente al paciente para
realizar su atención, brindar los diagnósticos respectivos y emitir la receta
médica si lo requiere.

Seguidamente, se detalla cómo es el proceso de registro de pacientes


actualmente en el establecimiento de salud:

18
Ilustración 1: Proceso actual del registro de pacientes.
Fuente: Elaboración Propia.

Actualmente, toda la información procesada y registrada lo hacen en


documentos físicos para las historias clínicas, toda esta información es
almacenada en un ambiente cerrado con su respectivo folder de color azul y
su número de historia clínica según último número generado manualmente
por el área de admisión para su identificación y solo tiene acceso el personal
autorizado. Además, llevan un control del registro de historias clínicas en un
archivo Excel para verificar si existe el usuario cuando vuelva a usar el
servicio y es almacenada en una computadora local en el área de admisión.
Esto puede generar riesgos de perdida de información parcial o total, en

19
algunos casos ocasionados por factores humanos o naturales. Además,
cierta información del paciente podría no ser confiable, precisa y oportuna,
debilitando la toma de decisiones por parte del profesional de salud al
momento de realizar un diagnóstico o brindar recetas médicas con
medicamentos no propicios al paciente. El profesional de salud archiva las
atenciones que realiza a través de los comprobantes de pagos adjuntos en
las historias clínicas enviadas por el área de triage en el momento de su
atención para su control diario que luego es enviado al área de
administración para la generación de los reportes diarios de manera manual,
este reporte lo realizan al día siguiente.

Si nos enfocamos en la infraestructura tecnológica del establecimiento de


salud solo cuentan con cuatro (4) equipos de cómputos y tres (3) impresoras
a tinta, solo tienen un sistema informático para la cobranza realizado en
Visual Fox Pro con tablas DBF, en algunas ocasiones se ralentiza la
búsqueda de información generando lentitud, carecen de equipo de cómputo
de alta disponibilidad llamado “Servidor” que es capaz de brindar los
servicios para el despliegue en producción de sistemas informáticos que
soporten funcionalidad e interacción de usuarios concurrentes para
satisfacer las necesidades de la estructura de las aplicaciones informáticas
y centralización de información de manera segura.

La investigación que se realizó en el centro médico se identificó los


siguientes problemas que se encuentran en la actualidad haciendo uso de la
técnica de observación de campo nos enfocaremos en el proceso de registro
de pacientes, las mismas que son:

 Existe una demora en la búsqueda de historias clínicas cuando existe


un paciente, debido a que el personal médico busca de manera
manual toda la información en los ambientes de registros físicos, esto
genera retraso en la atención del paciente hacia al área de triage.

20
 No existe una base de datos de información del paciente, debido a
que los registros son elaborados en documentos físicos, esto podría
generar duplicidad de registros, información no legible, perdida de
información y retraso en la elaboración de informes diarios.

 Existe un retraso de atención de un paciente concurrente al área de


triage, debido a que el personal de admisión demora en la obtención
de su historia clínica por estar almacenado en documentos físicos en
un ambiente cerrado, esto genera insatisfacción al paciente.

Al identificar todos estos problemas que suscitan en el proceso de registro


de pacientes hay una demora entre 12 minutos aproximadamente cuando
existe un usuario con historia clínica y una demora de 6 horas
aproximadamente para la elaboración de los informes diarios de atención
que suscitan en el centro médico, además hay reportes que el área de
administración desearía obtener de las áreas actuales con su sistema
tradicional, pero por demandar mucho tiempo de horas hombre no se puede
realizar. Pudimos encontrar además que existe un desorden en la
generación de citas médicas con los especialistas, debido a que se
desconoce su disponibilidad, los horarios de los mismos y hasta cuando se
acude en el centro médico, esto genera insatisfacción en los usuarios lo cual
a todo esto lo definiremos como un caso exógeno.

El centro médico actualmente no dispone de un sistema informático


centralizado que ayude a agilizar, optimizar y organizar el proceso de registro
de pacientes en el área de admisión, triage y consultorio médico generando
muchas veces incomodidad o malestar a los pacientes que tienen historia
clínica y además al personal interno en los trámites pertinentes a las historias
clínicas, todo esto puede causar o generar una mala imagen o reputación
empresarial al centro médico y sobre todo a la prestación de los servicios de
salud que ofrece diariamente.

21
1.2. Trabajos Previos
1.2.1. Internacional
Título: “SISTEMA DE GESTION PARA HISTORIAS CLINICAS BAJO
LA PLATAFORMA ANDROID ORIENTADO A LOS MEDICOS DEL
CONDOMINIO DEL HOSPITAL MILLENNIUM.” (VILLARUEL Chico,
2015)

Autor: Villarruel Chico Miguel Roberto, Ambato - Ecuador 2015.

Resumen: En esta tesis realizada aborda problemas con el control,


registro y almacenamiento de los expedientes clínicos en documentos
físicos a gran volumen por la excesiva demanda de usuarios a parte
de existir duplicidad de expedientes clínicos con un mismo paciente y
errores en los registros por el factor humano en el centro hospitalario
además de no saber con exactitud las citas programadas por los
pacientes en el día solicitado. Todos estos problemas fueron
solucionados con la implementación de un aplicativo móvil utilizando
tecnología Android con una base de datos SQLite debido a que los
médicos en su gran mayoría contaban con equipos smartphones
facilitado la interactividad y rápida adaptación al uso del software.
Para este investigador en su presente tesis utilizo la metodología de
desarrollo XP el cual se adapta de acuerdo a su trabajo realizado.

Aporte: En esta tesis que se realizó, aportará a nuestra investigación


el uso de las aplicaciones móviles de tipo open source como
alternativa por no disponer con infraestructura informática para
gestionar las citas médicas y el control, registro y almacenamiento de
expedientes clínicos de los pacientes podemos mencionar que esta
solución catalogada como sistema informático ayuda a mejorar el
proceso de atención de los médicos hacia los pacientes agilizando el
flujo de trabajo de manera gradual y tomando mejores decisiones al
evaluar y diagnosticar a un determinado paciente.

22
1.2.2. Nacional
Título: “IMPLEMENTACIÓN DE UN SISTEMA DE INFORMACIÓN
PARA LA ADMINISTRACIÓN DE PACIENTES DE LA CLINICA
PRIVADA CLINIFÉ.” (LA ROSA Palhua, y otros, 2017)

Autores: La Rosa Palhua Dayana Ivonne y Mendoza Montreuil


Alexander Giovanni - Lima, Perú 2017.

Resumen: En esta tesis realizada aborda problemas con el registro y


el almacenamiento de los expedientes clínicos en documentos físicos
son llenados a mano que puedan generar deterioro del material o
perdida de información, además existe demanda de mucho esfuerzo
y tiempo en la búsqueda de los expedientes clínicos. También una
demora en la asignación de citas médicas y el registro de horario de
los médicos lo realizan de manera manual en un cuaderno de registro,
todos estos problemas se solucionaron con la implementación de un
sistema informático utilizando la tecnología Java como lenguaje
principal de desarrollo y un gestor de base de datos libre como
PostgreSQL que permitió agilizar los flujos de trabajo con relación a
las citas médicas, historias clínicas, pacientes y salvaguardando la
información completa en el centro médico. Se utilizó la metodología
de desarrollo RUP para la planificación, elaboración y construcción
del software.

Aporte: En esta tesis que se realizó, aportará a nuestra investigación


que mediante un sistema informático se mejorarán los flujos de los
procesos de registro o atención de pacientes, facilitando la
información completa en tiempo real, implementando niveles de
seguridad y centralización de la información que tiene relación con las
citas médicas, expedientes clínicos y ficha personal del paciente,
además de utilizar tecnología web open source como Java y gestor
de base de datos PostgreSQL.

23
1.2.3. Local
Título: “DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA
LA GESTIÓN DE CONSULTAS ODONTOLÓGICAS
ODONTOSYSTEM PARA EL CONSULTORIO ODONTOLÓGICO
DENTAL ABREU.” (GONZÁLES Paredes, 2011)

Autor: Marvin Gonzales Paredes - Iquitos, Perú 2011.

Resumen En esta tesis realizada hace mención de mejorar los


procesos de consultas médicas odontológicas hacia determinados
pacientes, todos estos procesos que involucra citas odontológicas,
presupuestos, e historias clínicas de pacientes entre otros se realizan
de manera manual por no disponer de un sistema informático que le
permita agilizar los procesos, es por eso que se desarrolló un sistema
informático que abarque los mencionados problemas para procesar y
guardar la información, que se pueda acceder de manera rápida y
oportuna y brindar un servicio de calidad con la información precisa
en las atenciones realizadas a los pacientes, se realizó bajo la
plataforma de Microsoft Visual Studio .NET y el gestor de base de
datos Microsoft SQL Server 2008, además el investigador utiliza la
metodología de desarrollo RUP por ser la más adaptable a su
investigación.

Aporte: En esta tesis que se realizó, aportará a nuestra investigación


que un sistema informático independiente de su plataforma mejora los
flujos de trabajo agilizando de manera gradual cada uno de los
procesos citados en esta investigación además de mejorar los
servicios de atención hacia el usuario donde de forma rápida,
oportuna y veraz se obtiene la información requerida, además de
almacenar información del paciente de manera segura con los
diagnósticos aplicados y lo tratamientos realizados puedan
visualizarse a través de un computador.

24
1.3. Teorías Relacionadas al Tema
1.3.1. Según la Variable Dependiente
1.3.1.1. Proceso
Se describe como una recopilación de acontecimientos que
agrupan materiales o recursos, que ayuden a elaborar
productos el mismo que crea un valor para un consumidor o
usuario final este concepto está bajo la premisa de (HAMMER,
y otros, 2003)

Además, otro autor (WESKE, 2007), establece que el término


de proceso es una sucesión de actividades o tareas definidas
que se rigen de entradas y salidas que puedan alcanzar un
determinado resultado.

1.3.1.2. Atención de Salud


Podemos definir que la atención de salud como servicio es
desempeñada por un profesional de salud para el
mejoramiento y restablecimiento de la salud de un paciente que
lo solicite aplicando los recursos disponibles y necesarios del
sistema de salud de acuerdo a los conocimientos y
experiencias adquiridas en su etapa de formación profesional,
este concepto lo amerita (RAMIRÉZ Hita, 2010) en su libro
“Calidad de Atención en los Servicios de Salud”.

1.3.1.3. Paciente
Según (LEY N° 30024, 2013), “un paciente o usuario de salud
es un beneficiario directo de la atención de salud”.

Según (LEY 18.335, 2008), “se entiende por paciente a toda


persona que recibe atención de la salud, o en su defecto sus
familiares, cuando su presencia y actos se vinculen a la
atención de aquélla.”

25
1.3.1.4. Historia Clínica
Se establece bajo este concepto que una historia clínica es un
documento físico en donde se detalla todos los diagnósticos y
tratamientos realizados por el profesional de salud a un
determinado paciente para su pronta rehabilitación y
restablecimiento de su salud. (LLANIO Navarro, 1991)

Otro autor como (TIERNEY Jr, y otros, 2005), define que la


historia clínica es un proceso de centralización identificado
claramente en la historia clínica y su interrelación entre médico
y paciente es fundamental, esto permite la identificación exacta
de diagnósticos y tratamientos sintetizando la información en
procesos centralizando la relación entre el médico y sus
antecedentes.”

1.3.1.5. Historia Clínica Electrónica


En un informe del (INSTITUTE OF MEDICINE (IOM), 1990),
que una historia clínica electrónica es la digitalización de la
historia clínica física en donde se detalla todos los diagnósticos
realizados por el profesional de salud a un determinado
paciente a través de medios electrónicos computacionales
aplicando niveles de seguridad para la confiabilidad y el
resguardo de la información.

1.3.1.6. Gestión Clínica


La gestión clínica es la administración controlada de todas las
actividades o tareas relacionadas entre el profesional de salud
y el paciente brindando la mejora de la salud según los
diagnósticos o recursos empleados de acuerdo a la disposición
empleada por el profesional de salud. (PÉREZ, y otros, 2002).

26
1.3.1.7. Admisión en Salud
En un informe que brinda (INSALUD, 2000), la admisión en
salud es la primera instancia a donde un usuario se dirige,
determina si un usuario es nuevo o continuador, gestiona la
información de los pacientes y brinda información de los
servicios de salud.

1.3.1.8. Triage
El triage en salud es el proceso de clasificar a un paciente de
acuerdo al tipo de urgencia según la atención que solicite. Esto
se define en un manual de procedimientos de admisión integral
(MINISTERIO DE SALUD, 2001).

1.3.1.9. Consultorio Externo


Un consultorio externo es el área encargada de propiciar
atención a todos los pacientes que soliciten diagnósticos y
tratamientos para el restablecimiento de su salud en todas las
especialidades que lo amerite. (MINISTERIO DE SALUD,
2001).

1.3.2. Según la Variable Independiente


1.3.2.1. Sistema
Un sistema está asociado directamente a los componentes o
elementos interrelacionados que como finalidad cumplen con
el objetivo deseado desde el inicio de su planificación o
elaboración definidos bajo el enfoque de (JOHANSEN
Bertoglio, 2004).

Componentes de un Sistema:

 Objetivos.
 Sinergia.
 Recursividad.

27
 Los componentes de entrada y salida.
 El proceso de conversión.
 La retroalimentación que se define como elemento de
control.
 El alcance.
 El entorno.

Todos estos componentes tienen relación con el sistema


explicados por (HURTADO Carmona, 2011).

1.3.2.2. Sistema de Información


Un sistema de información es un grupo de componentes que
están interrelacionados que permiten obtener, procesar,
guardar, recuperar y distribuir la información para el apoyo y el
control en la operatividad de una organización. (AYALA Peña,
2006).

Componentes de un Sistema de Información:

 Financieros: Están orientados al ámbito económico que


sigue el flujo mediante la adquisición, contratación y
mantenimiento de los recursos interrelacionados con el
sistema de información.

 Administrativos: Están orientados a los objetivos de


una jerarquía orgánica, procedimientos, funciones y
lineamientos organizacionales, direcciones y controles
de las tareas que suministran la construcción y el uso de
los sistemas informáticos.

 Humanos: Están orientados a la parte técnica que se


encarga de la construcción de los sistemas informáticos
y a los usuarios como parte interesada que usan y

28
manejan la información para el apoyo en el
desenvolvimiento cotidiano de sus tareas.

 Materiales: Están orientados a la parte física que


apoyan el correcto funcionamiento del sistema
informático.

 Tecnológicos: Están orientados a la construcción, el


funcionamiento y la mantenibilidad de un sistema
informático.

Ilustración 2: Sistema de Información.


Fuente: (NIÑO C. Yamith, 2012)

1.3.2.3. Sistema de Información de Registro de Historias Clínicas


La (LEY N° 30024, 2013) establece que, “Un sistema de
información que cada establecimiento de salud o servicio
médico de apoyo implementa y administra para capturar,
manejar e intercambiar la información estructurada e integrada
de las historias clínicas electrónicas en su poder.”

1.3.2.4. Sistema de Administración de Pacientes


Se define que el sistema de administración de pacientes nos
ayuda a registrar información de los pacientes, a realizar
consultas de los mismos, generar información para la toma de
decisiones del personal médico y sobre todo brindar la

29
información de manera rápido y oportuna en los diagnósticos
empleados a los pacientes. (SOMMERVILLE, 2011).

Ilustración 3: Organización del Sistema de Administración de Pacientes.


Fuente: (SOMMERVILLE, 2011)

1.3.2.5. Aplicación Web


Las nuevas generaciones de aplicaciones web generan
automáticamente los contenidos, páginas personalizadas
según el perfil del usuario o la aplicación orientados a negocios
o mercados electrónicos. Además, La arquitectura cliente
servidor está a la orden del cliente en sus fases de
implementación en ámbitos relacionados a la contabilidad,
finanzas, etc. (LUJÁN Mora, 2002).

A criterio personal una aplicación web o sistema web en la


mayoría de definiciones podemos relacionarlo al conjunto de
páginas web en la cual tienen la finalidad de generar de manera
automática contenidos de una empresa o información personal
usando los servicios de la red internet o intranet local a través
de los diferentes navegadores web existentes en el mercado
actual utilizando herramientas informáticas para su publicación
o la integración con los sistemas existentes dentro de una
organización.

30
1.3.2.6. HMVC, PHP, JAVASCRIPT y JQUERY
Para entender el patrón de diseño HMVC debemos conocer
primero que define al MVC:

 Es un patrón de diseño de software orientado a


estructurar e identificar los proceso o componentes del
negocio separándolos de la aplicación, se utilizan clases
bien definidas ligadas a la programación orientada a
objetos en donde la capa del modelo es el componente
vinculado a la abstracción de los datos, la vista viene
hacer las plantillas que tendrá la aplicación orientadas al
usuario y el controlador es la lógica del negocio
vinculados entre el modelo y la vista. (GAMMA, y otros,
2009)

Siguiendo esta premisa podemos definir que el HMVC


(Jerárquico/Modelo/Vista/Controlador) es un patrón de diseño
mejorado o evolutivo del MVC para dividir las aplicaciones en
sub aplicaciones o módulos con su propio MVC independiente
en el cual se le denomina como “widgetización” esta solución
nace debido a los problemas de escalabilidad, esto permite que
el desarrollo o construcción de las aplicaciones sean más
robustas, organizadas, reutilizadas y escalables al estar
estratificado su funcionamiento es independiente por la
reducción de dependencias en sentido de la modularización
aplicada.

31
Ilustración 4: Patrón de diseño HMVC.
Fuente: (COGAN, Barry, 2010)

PHP (acrónimo de Hypertext Pre-Processor) es un lenguaje de


programación tipado de alto nivel por lado del servidor
considerado como tecnología BACKEND, multiplataforma y es
de código libre, suele estar embebido en páginas web HTML
(Lenguaje de Marcado de Hipertexto) dinámicas en el cual son
ejecutadas en un servidor web como apache entre otros, posee
gran soporte para diferentes base de datos y tiene gran
comunidad para un curva de aprendizaje menor y rápida,
además suele emplearse sistema de plantillas como SMARTY
para separar código PHP con HTML en las vistas. (GALLEGO
Vásquez, 2003).

Algunas de sus características que lo definen:

 Tiene licencia libre.


 Tiene una enorme popularidad.
 Tiene una enorme eficiencia.
 Tiene una sencilla integración con diversas bases de
datos.
 Mantiene una gran versatilidad.
 Tiene un gran número de funciones predefinidas.

32
JavaScript por lado del cliente considerado como tecnología
Frontend y es el lenguaje universal de la web, es un lenguaje
de programación interpretado no se compila, sirve para la
construcción de páginas webs dinámicas utilizando solo los
navegadores web. Propio de este lenguaje de programación
derivan muchas librerías como JQUERY que ayudan a mejorar
el funcionamiento de una aplicación en web haciendo más
interactiva, dinámica, rápida y funcional. Tiene soporte,
documentación y respaldada por una gran cantidad de usuarios
a nivel mundial en diferentes comunidades que ayudan mejorar
los procesos de codificación. (SAWYER McFarland, 2015).

A continuación, se mostrará la demanda en el uso a nivel


mundial de los lenguajes de programación y el predominio de
tecnologías en software libre en los primeros lugares del
ranking contra los de tecnologías propietarias, se realizó en el
año 2017 según la empresa GitHub y PYPL (PopularitY of
Programming Language|):

Ilustración 5: Ranking de Lenguajes de Programación GitHub.


Fuente: (GITHUB, 2017)

33
Ilustración 6: Ranking de Lenguajes de Programación PYPL.
Fuente: (PYPL, 2017)

1.3.2.7. POSTGRESQL
Es un software que forma parte de la familia de código libre que
se encarga de la administración y el soporte de base de datos
de tipo objeto relacional, utiliza el estándar de lenguaje SQL,
orientado a manejar grandes volúmenes de información a gran
escala comparado con sistemas de base de datos de uso
comercial bajo licencia privada. (RIGGS, y otros, 2017).

Ventajas de usar PostgreSQL:

 Es de código libre y gratuito.


 Es altamente amigable con mucha documentación,
además de poder utilizar en ambientes web.
 Su fácil administración y mantiene un estándar único de
SQL además de rápido aprendizaje.
 Footprint con una memoria de baja escala, con una
configuración o personalización adecuada.
 Multiplataforma para diferentes sistemas base.
 Tiene un alto nivel de seguridad.
 Sistema de replicación de datos muy poderosa.
 Mantiene un soporte disponible a nivel empresarial.
 Diseño para administrador grandes volúmenes de datos.

34
Decidimos preferir esta tecnología y no usar MySQL que
también es una buena alternativa además de ser libre a nivel
de comunidad, para visionar el rápido crecimiento que se
tendrá con los registros y consultas de información diaria,
actualización constante en mejoras de rendimiento, soporte,
seguridad y la administración que tiene en ambientes de alto
volumen es una característica relevante de este gestor de base
datos algo que hasta ahora no lo tiene MySQL y además no
usamos base de datos comerciales debido a su alto costo.

1.3.3. Según la Variable Interviniente


1.3.3.1. Metodologías de Desarrollo de Software
Las metodologías de desarrollo de software están ligadas a un
marco de trabajo que ayudan a los equipos organizados a
planificar, elaborar y mantener un control del proceso de
construcción de sistemas informáticos bajo un modelo
adaptable cumpliendo los requisitos en cada proyecto a realizar
y que puedan garantizar un software de gran valor además de
realizar cierta documentación detallada en cada ciclo de vida
de la construcción del software. (PRESSMAN, 2010).

1.3.3.2. Metodologías Agiles vs Metodologías Tradicionales


Las metodologías tradicionales o prescriptivas se vinculan bajo
un grupo de componentes propiamente relacionados al
proceso de negocio como actividades bien definidas y
organizadas, implicancia de la ingeniería de software como
trabajo funcional, tareas, componentes de trabajo, la calidad
permanente y componentes de control articulados en la gestión
de cambio para cada proyecto determinado. Para cada
esquema de un proceso o flujo de trabajo debe estar prescrito
para determinar la forma como los componentes del proceso
se relacionan o se vinculan entre sí. (PRESSMAN, 2010).

35
Las metodologías ágiles surge de la dificultad de plasmar en un
inicio el alcance bastante definido o detallado con relación a un
proyecto a realizar, y esto está familiarizado en conseguir los
resultados esperados de acuerdo a su alcance, en una etapa
inicial no se obtendrá un porcentaje altamente considerado,
existen tipos de proyectos que esto aún es más complicado, y
es donde aborda en la etapa inicial de estos tipos de proyectos
basado en tecnologías de información donde se originó la
metodología ágil. (SOMMERVILLE, 2011).

Ilustración 7: Ciclo de vida del desarrollo ágil.


Fuente: (SOMMERVILLE, 2011)

Principio Descripción
Los clientes deben intervenir estrechamente
durante el proceso de desarrollo. Su función
Participación
consiste en ofrecer y priorizar nuevos
del cliente
requerimientos del sistema y evaluar las
iteraciones del mismo.
El software se desarrolla en incrementos y el
Entrega
cliente especifica los requerimientos que se van a
incremental
incluir en cada incremento.
Tienen que reconocerse y aprovecharse las
Personas, no
habilidades del equipo de desarrollo. Debe
procesos
permitirse a los miembros del equipo desarrollar

36
sus propias formas de trabajar sin procesos
establecidos.
Esperar a que cambien los requerimientos del
Adoptar el
sistema y, de este modo, diseñar el sistema para
cambio
adaptar dichos cambios.
Enfocarse en la simplicidad tanto en el software a
Mantener desarrollar como en el proceso de desarrollo.
simplicidad Siempre que sea posible, trabajar de manera
activa para eliminar la complejidad del sistema.
Cuadro 1: Los principios de los métodos ágiles.
Fuente: (SOMMERVILLE, 2011)

Ilustración 8: Cambio de los costos como función del tiempo transcurrido en


el desarrollo.
Fuente: (PRESSMAN, 2010)

Ilustración 9: ciclo de vida de desarrollo de software clásico.


Fuente: (PRESSMAN, 2010)

37
1.3.3.3. Elección de la Metodología de Desarrollo del Proyecto
La metodología ágil elegida para la realización de nuestro
proyecto es la XP (programación extrema), con esta
metodología el cliente podrá visualizar su producto de manera
interactiva e incremental, además de permitir la
retroalimentación continúa basados en nuevos requerimientos
propiciados por el cliente al equipo de desarrollo además de la
rápida corrección de errores que puedan dar periódicamente.

Ilustración 10: Proceso de la Programación Extrema (XP).


Fuente: (PRESSMAN, 2010)

1.4. Formulación del Problema


1.4.1. Problema General
¿De qué manera un sistema modular web mejorará el proceso de
registro de pacientes del centro médico FDA BIOSERVICES de la
ciudad de Iquitos?

1.4.2. Problemas Específicos


 ¿De qué manera un sistema modular web mejorará la búsqueda de
historias clínicas del centro médico FDA BIOSERVICES de la
ciudad de Iquitos?

38
 ¿De qué manera una base de datos permitirá la generación de
reportes y evitará la duplicidad de registro de información de
pacientes del centro médico FDA BIOSERVICES de la ciudad de
Iquitos?
 ¿La implantación del sistema modular web del centro médico FDA
BIOSERVICES de la ciudad de Iquitos mejorará el nivel de
satisfacción de los pacientes?

1.5. Justificación de Estudio


El centro médico FDA BIOSERVICES que mantiene convenio con la
Sociedad de Beneficencia Pública de Iquitos, realiza atenciones médicas de
diversos indoles diariamente a usuarios nuevos y usuarios frecuentes
propios del lugar, al mejorar el proceso de registro de pacientes desde el
área de admisión con un sistema informático donde es el cuello de botella
muchas veces, se reducirá significativamente la demora en la búsqueda de
historias clínicas, realizando consultas de manera rápida y precisa,
agilizando además la demora en las atenciones hacia el área de triage y
consecutivamente al consultorio médico. El beneficio es la satisfacción del
paciente en el rápido proceso de atención y además incrementando
gradualmente las atenciones y la parte económica, se reducirá las
deserciones que pudiera haber por usuarios nuevos en el momento de
suscitar ese problema con usuarios frecuentes, habiendo perdidas
económicas en las atenciones.
También con la elaboración de reportes administrativos que realiza de
manera manual, se agilizará su generación de forma automática en menor
tiempo. Evitando también la duplicidad de los registros, perdida de
información y retraso.

1.5.1. Justificación Tecnológica


En nuestra actualidad, la innovación, la construcción y la usabilidad
de los componentes tecnológicos en la información se incrementa de
manera rápida y paralelo con los sistemas informáticos como
herramientas disponibles al alcance de los usuarios finales, las

39
necesidades tecnológicas de las instituciones públicas o privadas se
interesen por su usabilidad debido a su mejoramiento en la prestación
de los diversos servicios haciendo su uso de manera fácil,
responsable y viable.

En tal sentido, el centro médico FDA BIOSERVICES que mantiene


convenio con la Sociedad de Beneficencia Pública de Iquitos, no
puede estar ajeno a los cambios tecnológicos y se hace necesario
disponer de un sistema modular web como aporte a la dinámica de
trabajo de profesionales de la salud, administrativos y pacientes que
facilite la interacción tecnológica y mejorar la calidad de los servicios
prestados integrándose a la era tecnológica además de mostrar una
ventaja competitiva a nivel empresarial, mejorando los servicios en
admisión en la búsqueda de historias clínicas además de su
almacenamiento en digital que consecutivamente mejora la rápida
atención de un paciente hacia triage para después pasar a consultorio
médico, todo esto mejora en la generación de reportería
administrativa. La misma que debe poseer características de rápido
acceso, amigable, seguro y actualización constante. Por consiguiente,
se detallará las soluciones informáticas que se utilizarán en el
desarrollo del proyecto mencionado:

 Tecnologías Frontend:
o HTML 5, CSS 3 y Bootstrap 3.
o JavaScript y JQuery.
 Tecnologías Backend:
o PHP 7.1.
 Gestor de Base de Datos:
o PostgreSQL 10.
 Herramienta de desarrollo:
o Visual Studio Code 1.26.
 Sistema Operativo:
o Linux Ubuntu Server 18.04.

40
1.5.2. Justificación Económica
Nuestro sistema modular web, permitirá mejorar el proceso de registro
de pacientes en el centro médico FDA BIOSERVICES, en su etapa
de implementación se reduce los tiempos en la búsqueda de historias
clínicas y el retraso que genera la atención a triage vinculados
también al consultorio médico que todo esto tiene relación a los costos
de horas hombre empleados para realizar estas actividades, entonces
englobando todos estos problemas son gastos administrativos que se
pretende mejorar e incrementar las ganancias con relación a las
atenciones diarias, habiendo además un ahorro gradual en estas
actividades y la disminución de tiempo en la generación de reportes
que también forma parte de la solución.

1.5.3. Justificación Operativa


Con el despliegue del sistema modular web se informatizará toda la
información de registro de pacientes permitiendo que los procesos de
registros de pacientes se refleje en las prestaciones de atenciones
todo esto que actualmente se realiza de manera manual, además de
generar un ahorro de tiempo al personal administrativo, profesionales
de la salud y pacientes, esto mejorará la imagen del centro de salud
como moderna e innovadora en los servicios brindados además de
beneficiar a toda la comunidad en general. Se detallan dos ventajas
dentro de esta justificación:

 Ventaja Comparativa
o Para el desarrollo del sistema modular web, se usarán
programas informáticos de software libre (Visual Studio
Code v1.26 para la creación del sistema informático y
POSTGRESQL v10.0 como sistema de gestor de base
de datos) para abaratar los costos de licenciamiento en
cero.

41
o El equipo funcional para el desarrollo del sistema
informático está conformado por dos personas
profesionales en la especialidad.
o El equipo tecnológico es propiciado por el mismo equipo
desarrollo y para el despliegue del sistema informático
la misma institución dotara de nuevos equipos
tecnológicos gradualmente.

 Ventaja Competitiva
o Estructura modular para la adición de futuros módulos
funcionales según nuevos requerimientos sin alterar el
funcionamiento de los módulos existentes.
o Rapidez en la consulta de historias clínicas por
pacientes.
o Registro de pacientes, triage, citas médicas, médicos,
especialidades, diagnóstico clínico, diagnóstico
actividad (CIE10) y medicamentos para la receta médica
en una base de datos segura y centralizada.
o Diseño interactivo, amigable y multiplataforma con
integración para VPS vía internet.
o Visualización de citas pendientes para el área de
admisión, triage y consultorio médico.
o Emisión de recetas médicas digital por el profesional de
salud hacia los pacientes.
o Emisión de documentos digitales interno como triage y
diagnostico diario como parte de la historia clínica.
o Emisión de reportes de atenciones por médico y
especialidades.

1.5.4. Justificación Social


Los usuarios que usan el sistema modular web sean los médicos y
administrativos serán los beneficiados con la implementación para
realizar los trámites respectivos de manera ágil, rápida y eficiente sea

42
registros de pacientes, historias clínicas o citas médicas entre otros
procesos además se verá reflejado como la solución informática
mejora el flujo de trabajo y se brindará una mejor atención a los
usuarios que requieren los servicios. Desde la perspectiva del
paciente al digitalizar la historia clínica se puede visualizar desde
cualquier punto con acceso internet desde otro centro de salud para
diagnosticar y brindar los tratamientos de acuerdo a su historial
registrado a través de una infraestructura permitida.

1.6. Hipótesis
Un sistema modular web mejora significativamente el proceso de registro de
pacientes en el centro médico FDA BIOSERVICES de la ciudad de Iquitos.

1.7. Objetivos
1.7.1. Objetivo General
Determinar la manera que un sistema modular web mejorará el
proceso de registro de pacientes del centro médico FDA
BIOSERVICES de la ciudad de Iquitos.

1.7.2. Objetivos Específicos


 Establecer si el sistema modular web mejora la búsqueda de
historias clínicas en el centro médico FDA BIOSERVICES de la
ciudad de Iquitos.
 Establecer si una base de datos permite la generación de reportes
y evita la duplicidad de registro de información de pacientes del
centro médico FDA BIOSERVICES de la ciudad de Iquitos.
 Evaluar el nivel de satisfacción de los pacientes antes y después
de la implantación del sistema modular web del centro médico
FDA BIOSERVICES de la ciudad de Iquitos.

43
CAPÍTULO II: METODO
2.1. Diseño de la Investigación
2.1.1. Tipo de diseño
Experimental

2.1.2. Clasificación
Pre experimental, se tendrá una única variable y su nivel de control
será menor, no aplicaremos manipulación sobre la variable
independiente, pero se administrará un estímulo y se observará las
consecuencias sobre la variable dependiente.

G:

Ilustración 11: Clasificación de la Investigación.


Fuente: Elaboración Propia.
Resumiendo:

 Se le aplicará un grupo una previa prueba (O0) al estímulo (X),


luego se le administra un estímulo para finalmente aplicar una
posterior prueba (O1) al estímulo.

Donde:

 G: Grupo Experimental.
 O0: Proceso de registro de pacientes antes del Sistema
Modular Web.
 X: Sistema Modular Web.
 O1: Proceso de registro de pacientes después del Sistema
Modular Web.

45
2.2. Variables y Operacionalización
2.2.1. Identificación Variables

 Variable Independiente (V.I)


Sistema Modular Web.

 Variable Dependiente (V.D)


Proceso de Registro de Pacientes.

46
2.2.2. Operacionalización de las Variables

DEFINICIÓN DEFINICION ESCALA DE


VARIABLE INDICADORES
CONCEPTUAL OPERACIONAL MEDICIÓN

Es el conjunto de Se registrarán la Tiempo promedio en la búsqueda


actividades información de los de historias clínicas de los
sucesivas para pacientes (citas pacientes.
brindar los servicios médicas e historias
V.D.:
de salud a un clínicas y recetas Tiempo promedio en la
Proceso de
determinado usuario médicas), esto nos generación de reportes de Razón.
Registro de
que lo requiera permitirá tener información de los pacientes.
Pacientes.
mediante información detallada
mecanismos o para la generalización
recursos brindados de reportes Nivel de satisfacción de los

por el entorno. personalizados. pacientes del centro médico.

Cuadro 2: Operacionalización de la Variable Dependiente.


Fuente: Elaboración Propia.

47
DEFINICIÓN ESCALA DE
VARIABLE DEFINICION OPERACIONAL INDICADORES
CONCEPTUAL MEDICION

Sistema modular para gestionar


Es un sistema informático
la información de los pacientes
que permitirá el registro y
(citas médicas e historias
control de la información de
V.I.: clínicas, recetas médicas y
los pacientes utilizando
Sistema entre otros formularios)
tecnología web, además de Usabilidad. Ordinal.
Modular utilizando tecnología web, esto
establecer como estructura
Web. permitirá mejorar los procesos
base para la adición de
de registro de pacientes de
nuevos módulos por
forma integrada en todo el
desarrollar.
centro médico.

Cuadro 3: Operacionalización de la Variable Independiente.


Fuente: Elaboración Propia.

48
OBJETIVO TECNICA/ FRECUENCIA
N° INDICADOR MODELO CALCULO
ESPECIFICO INSTRUMENTO EMPLEADA

=
Establecer si el sistema
Tiempo
modular web mejora la TPBHCP = Tiempo promedio de
promedio en la
búsqueda de historias Medición búsqueda de historias clínicas de los
búsqueda de
1 clínicas en el centro Tiempo / Diario pacientes.
historias
médico FDA Cronómetro TBHCP = Tiempo en la búsqueda de
clínicas de los
BIOSERVICES de la historias clínicas de los pacientes.
pacientes.
ciudad de Iquitos. n = Número de búsqueda de
historias clínicas.

Establecer si una base =
de datos permite la
Tiempo TPGRIP = Tiempo promedio en la
generación de reportes
promedio en la generación de reportes de
y evita la duplicidad de Medición
generación de información de los pacientes.
2 registro de información Tiempo / Diario
reportes de TGRIP = Tiempo para la generación
de pacientes del centro Cronómetro
información de de reportes de información de los
médico FDA
los pacientes. pacientes.
BIOSERVICES de la
n = Número de reportes de
ciudad de Iquitos.
información de pacientes.

49
= ∗

Nivel de el nivel de satisfacción PTP = Puntaje total de la pregunta.

satisfacción de de los pacientes del FP = Frecuencia de la pregunta.


Encuesta/
3 los pacientes centro médico FDA Diario PA = Peso de aprobación.
Cuestionario
del centro BIOSERVICES de la =
médico. ciudad de Iquitos.
PPTP = Promedio de puntaje total de
la pregunta.
n = Número usuarios encuestados.
Cuadro 4: Indicadores y fórmula de cálculo.
Fuente: Elaboración Propia.

50
2.3. Población y Muestra
2.3.1. Población
Para la presente investigación nuestra población es de 30
atenciones diarias a pacientes concurrentes con historia clínica
desde el área de admisión pasando por triage y consultorio médico
que son atendidos de lunes a viernes en el turno de mañana y tarde
(7:00 am - 8:00 pm)

2.3.2. Muestra
En este trabajo realizado se utilizó por conveniencia del interés del
investigador por considerar una población pequeña donde la
muestra es el total de la población o muestra universal de 30
atenciones diarias del centro médico FDA BIOSERVICES que
mantiene convenio con la Sociedad de Beneficencia Pública de
Iquitos.

2.3.3. Muestreo
Para el presente trabajo de investigación, se utilizará el muestreo no
probabilístico, el cual, se utilizará la muestra obtenida del total de
población, la misma que, nos permitirá la generalización a toda la
población.

51
2.3.4. Población, Muestra y Muestreo por Indicador
 Indicador 01: Tiempo promedio en la búsqueda de historias
clínicas de los pacientes.
INDICADOR POBLACIÓN MUESTRA MUESTREO
Tiempo promedio
en la búsqueda de
Muestreo no
historias clínicas de 30 = 30
probabilístico.
los pacientes
(diario).
Cuadro 5: Indicador 01.
Fuente: Elaboración Propia.

 Indicador 02: Tiempo promedio en la generación de reportes de


información de los pacientes.
INDICADOR POBLACIÓN MUESTRA MUESTREO
Tiempo promedio
en la generación de
Muestreo no
reportes de 30 = 30
probabilístico.
información de los
pacientes (diario).
Cuadro 6: Indicador 02.
Fuente: Elaboración Propia.

 Indicador 03: Nivel de satisfacción de los usuarios del centro


médico.
INDICADOR POBLACIÓN MUESTRA MUESTREO
Nivel de
satisfacción de los
Muestreo no
pacientes del 30 = 30
probabilístico.
centro médico
(encuesta).
Cuadro 7: Indicador 03.
Fuente: Elaboración Propia.

52
2.4. Técnicas e Instrumentos de Recolección de Datos, Validez y
Confiabilidad
2.4.1. Técnicas e Instrumentos de Recolección de Datos

TÉCNICA INSTRUMENTO FUENTE INFORMANTE


Pacientes del
establecimiento de
Encuesta Cuestionario servicios de salud Pacientes
denominado FDA
BIOSERVICES.
Tiempo en la
búsqueda de
historias clínicas de
los pacientes. Usuarios del
Medición
Cronómetro Tiempo en la sistema
del tiempo
generación de modular web.
reportes de
información de los
pacientes.
Cuadro 8: Técnicas e instrumentos de recolección de datos.
Fuente: Elaboración Propia.

2.4.2. Validez del Instrumento


La presente encuesta tuvo que ser evaluada y aceptada por un
experto, el cual después de haber revisado minuciosamente la
presente encuesta dio el visto bueno y procedieron a la aprobación
del instrumento.

Para lo cual después de la aprobación se procedió a encuestar a los


pacientes del centro médico FDA BIOSERVICES que mantiene
convenio con la Sociedad de Beneficencia Pública de Iquitos.

53
2.4.1. Confiabilidad del Instrumento

Ilustración 12: Confiabilidad del Instrumento - Vista de Datos.


Fuente: Elaboración Propia.

En la Ilustración 12 se muestran los valores obtenidos por cada ítem de la encuesta realizada a los pacientes
concurrentes al establecimiento de servicios de salud FDA BIOSERVICES (ANEXO 01 - 1) se optará por la escala
de Likert (1-3), se utilizará para tal fin el software IBM SPSS Statistics v25 el mismo que nos servirá para analizar
los datos obtenidos de la encuesta realizada.

54
Ilustración 13: Confiabilidad del Instrumento - Vista de Variables.
Fuente: Elaboración Propia.

En la Ilustración 13 se resalta la confiabilidad del instrumento en donde se visualiza el lado de la vista de variables
en donde se distingue los distintos campos como el Nombre va la numero de ítem de la encuesta que se realizó a
los pacientes y en el campo Etiqueta se muestra la pregunta que se realizó en la determinada encuesta.

Seguidamente se mostrará el Alfa de Cronbach generado:

55
Ilustración 14: Alfa de Cronbach.
Fuente: Elaboración Propia.

En la ilustración 14 se muestran las estadísticas de fiabilidad de la


encuesta que se ejecuta para el presente trabajo de investigación,
donde es un valor de 0.891 en el Alfa de Cronbach y comparando con
sus resultados de valores (Cuadro 9), la apreciación de confiabilidad
del instrumento es Muy Buena.

VALOR APRECIACIÓN
[ 0.95 a * > Muy Elevada o Excelente
[ 0.90 - 0.95 > Elevada
[ 0.85 - 0.90 > Muy Buena
[ 0.80 - 0.85 > Buena
[ 0.75 - 0.80 > Muy Respetable
[ 0.70 - 0.75 > Respetable
[ 0.65 - 0.70 > Mínimamente Respetable
[ 0.40 - 0.65 > Moderada
[ 0.00 - 0.40 > Inaceptable
Cuadro 9: Escala de valoración Alfa de Cronbach.
Fuente: Elaboración Propia.

56
2.5. Métodos de Análisis de Datos
2.5.1. Prueba de Normalidad:
Para el análisis de datos en nuestro proyecto de investigación se
utilizará la prueba de normalidad de Shapiro-Wilk debido a que
nuestra muestra es de 30 atenciones diarias de pacientes con historia
clínica.

Kolmogorov-Smirnov Shapiro-Wilk
Para determinar muestras Para determinar muestras
grandes (n>=35) pequeñas (n<=35)
Cuadro 10: Cuadro sobre Pruebas de Normalidad.
Fuente: (MALHOTRA, 2008)

2.5.2. Pruebas Paramétricas


Se utilizará la prueba T-Student con distribución normal debido a que
nuestro análisis de datos en los dos primeros indicadores el p > 0.05.

Ilustración 15: Estadístico de Diferencia Pareada.


Fuente: Elaboración Propia.

2.5.3. Pruebas No Paramétricas


Se utilizará la prueba de los rangos con signos de wilcoxon porque
nuestra muestra no sigue una distribución normal o los datos no son
normales debido a que nuestro análisis de datos en el último indicador
el p < 0.05.

Ilustración 16: Estadístico de Wilcoxon.


Fuente: Elaboración Propia.

57
2.5.4. Hipótesis Estadística.
Determinamos la comprobación de la hipótesis general,
seguidamente se comprobará las hipótesis especificas:
 Hipótesis Nula

: − ≤0

Esto define que el sistema actual es mejor que la solución


propuesta.

 Hipótesis Alternativa

: − >0

Esto define que la solución propuesta es mejor que el sistema


actual.

 Hipótesis Específicas
 Hipótesis H1:
Un sistema modular web mejora la búsqueda de historias
clínicas de los pacientes en el centro médico FDA
BIOSERVICES de la ciudad de Iquitos.

TPBHCPsa = Tiempo promedio de búsqueda de historias


clínicas de los pacientes con el sistema actual.

TPBHCPsp = Tiempo promedio de búsqueda de historias


clínicas de los pacientes con el sistema propuesto.

Ho: El sistema modular web no mejora la búsqueda de


historias clínicas de los pacientes en el centro médico
FDA BIOSERVICES de la ciudad de Iquitos (minutos).

58
" = #$% &$'( − #$% &$') ≤ 0

Ha: El sistema modular web mejora la búsqueda de


historias clínicas de los pacientes en el centro médico
FDA BIOSERVICES de la ciudad de Iquitos (minutos).

* = #$% &$'( − #$% &$') > 0

 Nivel de Significancia
El nivel de significancia (α) escogido para la prueba de la
hipótesis es del 5%. Siendo α = 0.05 (nivel de
significancia) y n -1= 29 grados de libertad, se tiene el
valor crítico de T-Student (Anexo 04 - 2):

Valor Crítico: +, -.-/ = − 1.6991

Como α = 0.05 y n-1 = 30-1 = 29 grados de libertad, la


región de rechazo consiste en aquellos valores de t
menores que -t0.05 = - 1.6991 .

 Hipótesis H2:
Una base de datos permite la generación de reportes y
evita la duplicidad de registro de información de pacientes
del centro médico FDA BIOSERVICES de la ciudad de
Iquitos.

TPGRIPsa = Tiempo promedio en la generación de


reportes de información de los pacientes con el sistema
actual.

TPGRIPsp = Tiempo promedio en la generación de


reportes de información de los pacientes con el sistema
propuesto.

59
Ho: La base de datos no permite generar los reportes y
tampoco evita la duplicidad de registro de información de
pacientes del centro médico FDA BIOSERVICES de la
ciudad de Iquitos (minutos).

" = #$345$6* − #$345$67 ≤ 0

Ha: La base de datos permite generar los reportes y evita


la duplicidad de registro de información de pacientes del
centro médico FDA BIOSERVICES de la ciudad de Iquitos
(minutos).

* = #$345$6* − #$345$67 > 0

 Nivel de Significancia
El nivel de significancia (α) escogido para la prueba de la
hipótesis es del 5%. Siendo α = 0.05 (nivel de
significancia) y n -1= 29 grados de libertad, se tiene el
valor crítico de T-Student (Anexo 04 - 2):

Valor Crítico: +, -.-/ = − 1.6991

Como α = 0.05 y n-1 = 30-1 = 29 grados de libertad, la


región de rechazo consiste en aquellos valores de t
menores que -t0.05 = - 1.6991 .

 Hipótesis H3:
Un sistema modular web en producción del centro médico
FDA BIOSERVICES de la ciudad de Iquitos mejora el
nivel de satisfacción de los pacientes.

60
NSPCMAISsa = Nivel de Satisfacción del Paciente del
Centro Médico Antes de la Implantación del sistema.

NSPCMDISsp = Nivel de Satisfacción del Paciente del


Centro Médico Después de la Implantación del sistema.

Ho: El Nivel de Satisfacción de los Pacientes del Centro


Médico con respecto al Proceso de Registro de Pacientes
Antes de la Implantación del Sistema Modular Web es
mayor o igual que el Nivel de Satisfacción de los
Pacientes del Centro Médico con respecto al Proceso de
Registro de Pacientes Posterior a la Implantación del
Sistema de Modular Web.

" = 89$&:;59'( − 89$&:<59') ≤ 0

Ha: El Nivel de Satisfacción de los Pacientes con respecto


al Proceso de Registro de Pacientes Antes de la
Implantación del Sistema Modular Web es menor que el
Nivel de Satisfacción de los Pacientes con respecto al
Proceso de Registro de Pacientes Posterior a la
Implantación del Sistema Modular Web.

* = 89$&:;59'( − 89$&:<59') ≤ 0

 Nivel de Significancia
Se define el margen de error, confiabilidad 95%. Usando
un nivel de significancia ( = 0.05) del 5%. Por lo tanto, el
nivel de confianza (1 -  = 0.95) será del 95%. ver Anexo
04 - 1: Tabla de distribución Z encontramos Zα = 1.645.
Entonces la región critica de la prueba es Zc = < 1.645 >.

61
CAPÍTULO III: RESULTADOS
3.1. Contrastación de Hipótesis
3.1.1. Tiempo promedio en la búsqueda de historias clínicas de los
pacientes.

Se trabajará con una muestra universal del total de población de 30


pacientes frecuentes con historia clínica. Se consideró el estudio en
2 meses junio y julio, por 8 semanas y solo los días de lunes a
viernes desglosando un total de 40 días.

Prueba de Normalidad:

Ilustración 17: Pruebas de Normalidad del Indicador 1.


Fuente: Aplicación SPSS.

En esta ilustración podemos observar que el (p > 0.05) con relación


al Sig. de 0,135 porque los datos cumplen una distribución normal,
entonces se recomienda usar la prueba T-Student. Se utilizará
Shapiro-Wilk por tener una muestra pequeña de 30 según la
ilustración 15. Estadístico a usar:

Ilustración 18: Prueba de Muestras Relacionadas con el Indicador 1.


Fuente: Aplicación SPSS.

Según los datos generados, observamos que la T-Student es mayor


a 2.1 de cualquier tabla teórica y el (p < 0.05) con relación al Sig.

63
entonces se rechaza la hipótesis nula y se acepta la hipótesis de
investigación: El sistema modular web mejora significativamente
la búsqueda de historias clínicas de los pacientes en el centro
médico FDA BIOSERVICES de la ciudad de Iquitos.

Ilustración 19: Estadísticas de Muestras Relacionadas del Indicador 1.


Fuente: Aplicación SPSS.

TIEMPO PROMEDIO DE BUSQUEDA DE HISTORIAS CLINICAS DEL PACIENTE

100% 98.75%

500.00

450.00

400.00

350.00

300.00
MINUTOS

479.89 473.89
250.00

200.00

150.00

100.00
1.25%
50.00 6.00
0.00
Tiempo promedio de búsqueda Tiempo promedio de búsqueda Decremento
de historias clínicas de los de historias clínicas de los
pacientes con el sistema actual pacientes con el sistema
(TPBHCPsa) propuesto (TPBHCPsp)

Ilustración 20: Tiempo Promedio de Búsqueda de Historias Clínicas del Paciente.


Fuente: Elaboración Propia.

Determinamos que el tiempo promedio de búsqueda de historias


clínicas de pacientes frecuentes con una muestra de 30 en 40 días
con el sistema actual es de 479.89 minutos aproximadamente y con
el sistema propuesto es de 6 minutos aproximadamente, que
representa un decremento de 98.75% dando fundamento válido que
se mejora significativamente.

64
3.1.2. Tiempo promedio en la generación de reportes de información
de los pacientes.

Se trabajará con una muestra de 30 días con 2 reportes diarios para


ver la el tiempo de generación de los reportes antes y después.

Prueba de Normalidad:

Ilustración 21: Pruebas de Normalidad del Indicador 2.


Fuente: Aplicación SPSS.

En esta ilustración podemos observar que el (p > 0.05) con relación


al Sig. de 0,109 porque los datos cumplen una distribución normal,
entonces se recomienda usar la prueba T-Student. Se utilizará
Shapiro-Wilk por tener una muestra pequeña de 30 según la
ilustración 15. Estadístico a usar:

Ilustración 22: Prueba de Muestras Relacionadas Indicador 2.


Fuente: Aplicación SPSS.

Según los datos generados, observamos en la ilustración 22 que la


T-Student es mayor 2.1 de cualquier tabla teórica y el (p < 0.05) con
relación al Sig. se rechaza la hipótesis nula y se acepta la hipótesis
de investigación: La base de datos permite generar
significativamente los reportes y evita la duplicidad de registro

65
de información de pacientes del centro médico FDA
BIOSERVICES de la ciudad de Iquitos.

Ilustración 23: Estadísticas de Muestras Relacionadas del Indicador 2.


Fuente: Aplicación SPSS.

TIEMPO PROMEDIO EN LA GENERACION DE REPORTES DE INFORMACIÓN DE LOS PACIENTES

100% 99.87%

160.00

140.00

120.00

100.00
MINUTOS

80.00 152.10 151.90

60.00

40.00
0.13%

20.00
0.20
0.00
Tiempo promedio en la Tiempo promedio en la Decremento
generación de reportes de generación de reportes de
información de los pacientes información de los pacientes
con el sistema actual con el sistema propuesto
(TPGRIPsa) (TPGRIPsp)

Ilustración 24: Tiempo Promedio en la Generación de Reportes de Información de


los Pacientes.
Fuente: Elaboración Propia.

Determinamos que una base de datos permite generar reportes de


información de los pacientes con una muestra a 30 días con 2
reportes diarios con el sistema actual es de 152.10 minutos
aproximadamente y con el sistema propuesto es de 0.20 minutos
aproximadamente, que representa un decremento de 99.87% dando
fundamento válido que permite generar significativamente.

66
3.1.3. Nivel de Satisfacción de los Pacientes del Centro Médico.

Para este indicador se empleó una serie de 15 preguntas a 30


pacientes frecuentes antes y después de la implantación del sistema
modular web (ver Anexo 01 - “Cuestionario”). se procesaron los
datos a la aplicación del SPSS en donde se definieron los rangos del
nivel de satisfacción antes y después de la implantación del sistema
modular.

Prueba de Normalidad:

Ilustración 25: Pruebas de Normalidad del Indicador 3.


Fuente: Aplicación SPSS.

En esta ilustración podemos observar que el (p < 0.05) con relación


al Sig. de 0,018 porque los datos no cumplen una distribución
normal, entonces se recomienda usar la prueba Z. Se utilizará
Shapiro-Wilk por tener una muestra pequeña de 30 según la
ilustración 16. Estadístico a usar:

Ilustración 26: Prueba de Rangos con Signo Wilcoxon Indicador 3.


Fuente: Aplicación SPSS.

Según los datos generados, observamos en la ilustración 26 que Z


es mayor 1.645 de cualquier tabla teórica y el (p < 0.05) con relación
al Sig. se rechaza la hipótesis nula y se acepta la hipótesis de

67
investigación: El Nivel de Satisfacción de los Pacientes con respecto
al Proceso de Registro de Pacientes Antes de la Implantación del
Sistema Modular Web es menor que el Nivel de Satisfacción de los
Pacientes con respecto al Proceso de Registro de Pacientes
Posterior a la Implantación del Sistema Modular Web.

Indicador Categorías Intervalos


Malo [0 - 10>
Nivel de satisfacción de los pacientes
Regular [10,1 - 20>
del centro médico.
Bueno [20,01 - 30]
Cuadro 11: Cuadro de Intervalos del Indicador 3.
Fuente: Elaboración Propia.

Se procesaron los datos a la aplicación del SPSS en donde se


definieron los rangos del nivel de satisfacción antes y después de la
implantación del sistema modular. Para evaluar este indicador se
categorizo bajo los siguientes intervalos según el cuadro 11.

PRETEST

Categorías de Nivel de Satisfacción de los Pacientes


Porcentaje Porcentaje
Frecuencia Porcentaje
válido acumulado
Malo 22 73,3 73,3 73,3
Regular 4 13,3 13,3 86,7
Válido
Bueno 4 13,3 13,3 100,0
Total 30 100,0 100,0
Cuadro 12: Categorías del Nivel de Satisfacción de los Pacientes Pre-Test.
Fuente: Aplicación SPSS.

Ilustración 27: Nivel de Satisfacción de los Pacientes Pre-Test.


Fuente: Aplicación SPSS.

68
Interpretación: El predominio del nivel de satisfacción de los
pacientes antes de la implantación del sistema modular web es de la
categoría de Malo con un 73,3% y en menor predominio de Regular
y Bueno en 13,3%.

POS-TEST
Categorías de Nivel de Satisfacción de los Pacientes
Porcentaje Porcentaje
Frecuencia Porcentaje
válido acumulado
Regular 4 13,3 13,3 13,3
Válido Bueno 26 86,7 86,7 100,0
Total 30 100,0 100,0
Cuadro 13: Categorías del Nivel de Satisfacción de los Pacientes Pos-Test.
Fuente: Aplicación SPSS.

Ilustración 28: Nivel de Satisfacción de los Pacientes Pos-Test.


Fuente: Aplicación SPSS.

Interpretación: El predominio del nivel de satisfacción de los


pacientes después de la implantación del sistema modular web es de
categoría de Bueno con un 86,7% y en menor predominio de Regular
de 13,3%.

69
3.1.4. Prueba de Hipótesis Variable Independiente.

A. Nivel de usabilidad del sistema modular web, cumpliendo


métricas y arquitectura de software.
Se empleó una encuesta con una serie de preguntas a 04
Ingenieros de sistemas expertos en el desarrollo de software, se
procesaron los datos de acuerdo con los valores del cuadro 14
donde se especifica los rangos del nivel de aprobación del
sistema con respecto a la usabilidad.

Rango Nivel de Aprobación Peso


MB Muy Bueno 5
B Bueno 4
R Regular 3
D Deficiente 2
MD Muy Deficiente 1
Cuadro 14: Nivel de Aprobación.
Fuente: Elaboración Propia.

Por cada ítem de cada pregunta se realiza la contabilización


según su frecuencia de ocurrencia para cada respuesta (5) por
cada encuestado (04 Expertos) se especifica en el Anexo 04 - 3,
para posteriormente determinar su puntaje.

Para realizar el cálculo se procederá de la siguiente manera:

 Se realiza la multiplicación según la cantidad de expertos


por el peso según rango de funcionalidad de su respuesta,
seguidamente se realiza la sumatoria de los resultados
obtenidos para posteriormente tener el puntaje total, luego
se realiza la división entre la cantidad de expertos
encuestados obteniendo como resultado el puntaje
promedio.

70
M M
B R M Punt. Punt.
N° Pregunta B M
Total Prom.
5 4 3 2 1
¿Cómo califica
usted, el nivel de
1 3 1 0 0 0 19 4.75
facilidad en el uso
del software?
¿Cómo califica
usted, el nivel de
2 2 2 0 0 0 19 4.75
aprendizaje en el
uso del software?
¿Cómo califica
usted, la
3 4 0 0 0 0 18 5.0
operabilidad del
software?
¿Cómo califica
usted, la
4 3 1 0 0 0 18 4.75
presentación del
software?
Total 19.25
Cuadro 15: Nivel de Usabilidad del Software.
Fuente: Elaboración Propia.

Después de haber sido revisado el sistema informático por los


expertos en el desarrollo de software, determinaron que el nivel
de usabilidad del software cumple las expectativas según la
ISO/IEC 9126 donde detalla la medición de la usabilidad del
software a través de su nivel de aprendizaje, nivel de
entendimiento y la manera de uso de forma fácil, además de ser
amigable en la presentación de las vistas hacia el usuario. Se
visualiza en el cuadro 15 después de la contabilización de los
resultados nos arroja un puntaje de 19.25 puntos, y según el
cuadro 14 para ver el nivel de aprobación se realiza el cálculo de
dividir el resultado obtenido entre la cantidad de ítems (04
Preguntas) que se realizó, obteniendo un puntaje de 4.81, siendo
el nivel de aprobación BUENO cumpliendo con el indicador
propuesto.

71
CAPÍTULO IV: DISCUSIÓN

72
Se realizó en una primera parte el estudio de determinar su problemática vinculados
al registro de información de los pacientes en el centro médico FDA BIOSERVICES
en donde carecen de sistemas informáticos que ayuden a dinamizar o agilizar sus
procesos, habiendo demora en los flujos de trabajos.

La iniciativa de usar la tecnología para mejorar los procesos es a través de un


sistema modular web, enfocarnos útilmente en solucionar esos problemas
relacionados a la búsqueda de historias clínicas con su almacenamiento evitando
duplicidad de información, elaboración tardía de reportes de información diaria y
tener un orden en los registros y almacenamiento. se detalla seguidamente como
el sistema modular web mejora el proceso de registros de pacientes abordando la
realidad actual en el centro médico FDA BIOSERVICES.

En la realización de la investigación se utilizó a nivel de software la metodología


ágil con enfoque XP (Programación Extrema) el mismo que se eligió porque el
cliente en este caso el centro médico FDA BIOSERVICES podrá visualizar su
producto de manera interactiva e incremental ante cualquier cambio que requiera
además de dinamizar la rapidez en la corrección de errores que se puedan
presentar.

Se determina el análisis de los requerimientos a nivel funcional que está vinculados


a los procesos del negocio además de su nivel de infraestructura para dar soporte
al sistema informático presentado. Existe también requerimientos no funcionales
que juzgan la operación o el flujo de trabajo de un sistema en donde se detalla al
lenguaje de programación PHP con patrón HMVC y a PostgreSQL como gestor de
base de datos a ser utilizados en el presente desarrollo del sistema informático,
ambas tecnologías están vinculadas al software libre, tienen un soporte amplio y
grandes comunidades virtuales con relación a las licencias son a costo cero, no se
realiza un pago por su uso, son multiplataformas preparados para trabajar bajo
cualquier sistema base (Sistema Operativo).

En la Fase I del Anexo 03: Metodología de Desarrollo; que vincula a la Exploración


como primera instancia, se determinó las personas relacionadas con el sistema

73
informático (Admisión, Triage, Medico, Administración) que están inmersos en los
procesos actuales y además de la interacción con el software respectivo. Se
procedió con las coordinaciones respectivas con el centro médico para brindarnos
las facilidades en el acceso al ambiente y acceso a la información pertinente con
los procesos a investigar. Se realizó las reuniones pertinentes para informar el
avance del desarrollo del software según sus necesidades por cada prueba
presentada, además de la capacitación al personal encargado para la operatividad
en el uso del software, realizando en cada fase del desarrollo la supervisión
constante con relación a la metodología aplicada y brindar el soporte adecuado a
las correcciones en cada prueba debidamente presentada. En el trabajo previo de
(VILLARUEL Chico, 2015) detalla esta fase como la parte inicial del desarrollo de
software relacionados a los análisis de los procedimientos del negocio.

En la Fase II, comprende a la Planificación, en donde se detalla todas las historias


de usuarios que deben priorizarse para su implementación y vinculadas a las
entregas a realizarse según calendarización, además de su duración por cada
iteración estimada para el desarrollo del software según las necesidades
propiciadas por el centro médico en cada reunión establecida en donde se
realizaron 12 historias de usuarios agrupados en 2 iteraciones además se detalla
los requerimientos de software que se utilizarán como el lenguaje de programación
PHP y PostgreSQL como base de datos. En el trabajo previo de (LA ROSA Palhua,
y otros, 2017) utilizan la base datos PostgreSQL para el almacenamiento de sus
datos además de ser libre sin costo alguno, tendencia a crecer al mayor volumen
de información que se pueda procesar y la alta concurrencia por usuarios.

En la Fase III, comprende al Diseño, en donde se tiene las consideraciones de


diseño que fueron priorizados en la etapa inicial y se pusieron en práctica según la
metodología aplicada. Se realizo el diseño del modelo entidad relación (DER), en
donde se definen las entidades con sus respectivas relaciones, sus atributos
correspondientes a cada entidad y sus tipos de datos según las reglas de negocio.
Se detalla las siguientes entidades: paciente, medico, movespecialidadmedico,
citas, triage, historiaclinica, movhistoriaclinica, recetamedica, movrecetamedica,
medicamento, diagnosticoactvidad, persona, dirección, usuario (Anexo 03 - 1,

74
Ilustración N° 45). Se realiza además la codificación con respecto a la
implementación de la base de datos según el modelo entidad relación (DER)
diseñado, se utilizó la herramienta PgAdmin 4 como administración de la base de
datos PostgreSQL. Posteriormente se realizó además la codificación de la
aplicación utilizando la herramienta Visual Studio Code con el lenguaje de
programación PHP usando el patrón de diseño de software HMVC, se especifica la
clase Database para la conexión a la base de datos PostgreSQL (Anexo 03 - 1,
Ilustración N° 48) y además la clase loginController (Anexo 03 - 1, Ilustración N° 49)
como carga de inicio de la aplicación y el código JavaScript (Anexo 03 - 1,
Ilustración N° 49). En el trabajo previo de (GONZÁLES Paredes, 2011), utiliza
tecnología propietaria (MICROSOFT) que incurre costos de licenciamiento, además
estar limitado en un entorno Windows para el trabajo de manera local y ligado a un
solo sistema operativo.

En la última de la metodología de desarrollo con XP, Fase IV que compre a


Pruebas, se realizó con el equipo de trabajo para determinar que cada prueba se
realice satisfactoriamente convirtiéndose en lanzamientos definidos y validados por
el cliente (centro médico FDA BIOSERVICES) según Anexo 03 - 1, desde la
Ilustración N° 51 - Ilustración N° 74. En cada prueba presentada se detalla su
funcionamiento para el uso correcto que debe realizar cada personal relacionado a
su determinado proceso. Además, según el trabajo de (VILLARUEL Chico, 2015)
se relaciona de igual manera a la presentación y descripción de cada prueba como
resultado final para su uso.

Con respecto a la Viabilidad económica se muestra en la ilustración N° 42 “Flujo de


caja”, está comprendido en 3 años, después de realizar el análisis de rentabilidad
se obtuvo como resultado el VAN es 25568.188 > 0, por lo tanto, la inversión
realizada generará ganancias y posteriormente el proyecto debe aceptarse, en la
TIR salió 68% siendo mayor que la tasa de interés del banco 15% por lo cual el
proyecto es viable, y el tiempo de recuperación del capital será de 1 año 2 meses
y 12 días haciendo el análisis se tiene por aceptado su proyecto. Comparando con
el trabajo previo de (LA ROSA Palhua, y otros, 2017) según su análisis obtuvieron

75
una TIR de 16% mayor al 10% proporcionada por la SBS (Superintendencia de
Banca y Seguros) terminando por aceptar su proyecto.

Después de realizar el análisis de los resultados vinculados al indicador 01 tiempo


promedio en la búsqueda de historias clínicas de los pacientes se llegó a la
conclusión que el tiempo promedio es de 478,89 minutos con su sistema actual y
de 6 minutos con el sistema propuesto en un horizonte de 40 días con una muestra
de 30 atenciones diarias, habiendo una reducción de 473,89 minutos (Ilustración
N° 20) debido a que con el sistema actual hay una demora en la búsqueda de
historias clínica que a su vez retrasa la atención en el área de triage de un promedio
de 12 minutos por paciente con historia clínica. Por este motivo, queda demostrado
que el sistema modular web implementado mejora significativamente la búsqueda
de historias clínicas de los pacientes en el centro médico FDA BIOSERVICES de
la ciudad de Iquitos. Comparando con el trabajo previo de (LA ROSA Palhua, y
otros, 2017), su tiempo promedio es de 0,2 segundos y del presente trabajo es de
0,15 segundos por paciente con una diferencia 0,05, quedando demostrado en
menor tiempo con relación al indicador 01.

Después de realizar el análisis de los resultados vinculados al indicador 02 tiempo


promedio en la generación de reportes de información de los pacientes se llegó a
la conclusión que el tiempo promedio que se demoran en generar reportes diarios
de información con el sistema actual era de 152,10 minutos por día y de 0.20
minutos que equivale a 12 segundos por día con el sistema implementado en un
horizonte de 30 días con 2 reportes diarios, habiendo una reducción de 151,9
minutos (Ilustración N° 24) debido a que no existe una base de datos de información
de pacientes que permita a través del sistema informático generar los reportes
diarios que se necesitan. Por este motivo queda demostrado que la base de datos
permite generar significativamente los reportes y evita la duplicidad de registro de
información de pacientes del centro médico FDA BIOSERVICES de la ciudad de
Iquitos.

Después de realizar el análisis de los resultados vinculados al indicador 03 nivel de


satisfacción de los pacientes se llegó a la conclusión que existe un predominio con

76
la categorización de “Malo” en el proceso de registro de pacientes de un 73,3% y
en menor predominio de la categorización de “Regular” y “Bueno” en un 13,3%
(Ilustración N° 27) esto es antes de la implantación del sistema modular web, y
después de la implantación de sistema modular web existe un predominio del nivel
de satisfacción de los pacientes en la categorización de “Bueno” en el proceso de
registro de pacientes de un 86,7% y en menor predominio de la categorización de
“Regular” con un 13,3% (Ilustración N° 28). Por este motivo queda demostrado que
el nivel de satisfacción de los pacientes con respecto al proceso de registro de
pacientes antes de la implantación del sistema modular web es menor que el nivel
de satisfacción de los pacientes con respecto al proceso de registro de pacientes
posterior a la implantación del sistema modular web.

Con respecto a la usabilidad del software, el sistema informático presentado cumple


con la norma ISO/IEC 9126 de manera positiva en el proceso de registro de
pacientes, esto queda demostrado que la implementación de la tecnología mejora
y reduce los tiempos de atención en los flujos de trabajo (Cuadro N° 15).

Finalmente, con los resultados obtenido se puede fundamentar como válido la


hipótesis del trabajo de investigación: Un sistema modular web mejora
significativamente el proceso de registro de pacientes en el Centro Médico FDA
BIOSERVICES de la ciudad de Iquitos. Esto es aceptable, porque hay una
diferencia significativa entre el sistema anterior y el sistema implementado en
relación a los tiempos y satisfacción de los pacientes.

77
CAPÍTULO V: CONCLUSIONES

78
Se logró mejorar el registro de pacientes del centro médico FDA BIOSERVICES a
través del cumplimiento de los siguientes logros:

 Se logró disminuir el tiempo promedio en la búsqueda de historias clínicas de


los pacientes con historia clínica en un 98,75%, con una reducción del tiempo
en 473,89 minutos.

 Se logró disminuir el tiempo promedio en la generación de reportes de


información de los pacientes en un 99,87%, con una reducción del tiempo en
151.90 minutos.

 Se logró mejorar el nivel de satisfacción de los pacientes en un 86,7% después


de la implantación del sistema modular web.

 Se concluye que el presente proyecto y su desarrollo es factible


económicamente por los siguientes motivos:

 El valor de VAN es 25,568.188 > 0, entonces podemos plantear que la


inversión que se realizará con la implementación del sistema informático
generará ganancias y el proyecto por si, debe aceptarse.

 La relación de Beneficio / Costo es que por cada S/. 1.00 que se invierte se
obtiene S/. 0.50 de ganancia.

 El proyecto es aceptable, puesto que el TIR (68%) es mayor que la tasa de


interés del banco (15%).

 El tiempo de recuperación del capital es de 1 año, 2 meses y 12 días.

 Un sistema modular web mejora significativamente el registro de información


de los pacientes del centro médico disminuyendo el tiempo en la búsqueda de
historias clínicas, generación de reportes y mejorando el nivel de satisfacción
de los pacientes después de la implantación del sistema informático.

79
CAPÍTULO VI: RECOMENDACIONES

80
Se recomienda:

 Crear una aplicación móvil para el registro de citas en línea con pagos
electrónicos en diferentes plataformas móviles disponibles en el mercado
tecnológico para la interacción entre los pacientes y el centro de salud, conocer
la disponibilidad de los profesionales de salud y su horario respectivo.

 Para futuros módulos a implementar, utilizar la misma estructura base del


sistema modular web ya que permite agregar varios módulos sin afectar su
funcionamiento por estar bajo el patrón de diseño de software HMVC con PHP.

 Compartir la información de las historias clínicas con otros establecimientos de


salud para determinar un mejor diagnóstico y tratamiento a los pacientes debido
a que la aplicación esta desarrollado en plataforma web y permite su despliegue
través de internet.

 Que el siguiente trabajo de investigación sirva de referencia para futuras


investigaciones que se puedan mejorar los aspectos que no se llegó a
considerar por tema de tiempo.

81
CAPÍTULO VI: REFERENCIAS

82
BIBLIOGRAFICAS

AYALA Peña, Alejandro. 2006. Ingeniería de Software: Una Guía para Crear Sistemas de
Información. México D.F. : INSTITUTO POLITÉCNICO NACIONAL., 2006. ISBN: 9709479709.

COGAN, Barry. 2010. evantotutsplus. evantotutsplus. [En línea] evantotutsplus, 18 de Mayo de


2010. [Citado el: 12 de Mayo de 2018.] https://code.tutsplus.com/tutorials/hmvc-an-introduction-
and-application--net-11850.

GALLEGO Vásquez, Jose Antonio. 2003. Desarrollo Web con PHP y MySQL. Madrid, España. : Anaya
Multimedia., 2003. ISBN: 8441515255.

GAMMA, Erich, y otros. 2009. Design Patterns: Elements of Reusable Object-Oriented-Software.


Westford, Massachusetts, EE.UU. : Addison-Wesley Professional Computing Series., 2009. ISBN:
0201633612.

GITHUB. 2017. GitHub Octoverse 2017. GitHub Octoverse 2017. [En línea] GitHub, 31 de Diciembre
de 2017. [Citado el: 25 de Mayo de 2018.] https://octoverse.github.com/.

GONZÁLES Paredes, Marvin. 2011. Desarrollo de Uu Sistema de Información para la Gestión de


Consultas Odontológicas “OdontoSystem” para el Consultorio Odontológico Dental Abreu. Iquitos,
Perú. : s.n., 2011.

HAMMER, Michael y CHAMPY, James. 2003. Reenginneering The Corporation. New York, USA. :
HarperCollinsPublishers., 2003. ISBN: 0066621127.

HURTADO Carmona, Dougglas. 2011. Teoría General de Sistemas: Un Enfoque hacia la Ingeniería
de Sistemas. Barranquilla, Colombia. : Editorial Lulu.com, 2011. ISBN: 9781257781935.

INSALUD. 2000. Guía de Gestión de los Servicios de Admisión y Documentación Clínica. Madrid,
España. : Instituto Nacional de la Salud., 2000.

INSTITUTE OF MEDICINE (IOM). 1990. Informe sobre HCE. EE.UU : IOM, 1990.

JOHANSEN Bertoglio, Oscar. 2004. Introducción a la Teoría General de Sistemas. México D.F. :
Editorial LIMUSA, S.A., 2004. ISBN: 968181567X.

LA ROSA Palhua, Dayana Ivonne y MENDOZA Montreuil, Alexander Giovanni. 2017.


Implementación de un Sistema de Información para la Administración de Pacientes de La Clínica
Privada Clinifé. Lima, Perú : s.n., 2017.

LEY 18.335. 2008. Ley 18.335 - Derecho y Obligaciones de los Pacientes y de los Usuarios de los
Servicios de Salud. Uruguay : Senado y la Camara de Representantes de la República Oriental del
Uruguay., 2008.

LEY N° 30024. 2013. Ley N° 30024 - Ley que Crea el Registro Nacional de Historias Clínicas
Electrónicas. Lima, Perú : Congreso de la República del Perú., 2013.

LLANIO Navarro, Raimundo. 1991. Propedeutica Clínica Y Fisiopatología, Tomo II. La Habana,
Cuba. : Editorial Pueblo y Educación., 1991. ISBN: B005ZVM2LO.

LUJÁN Mora, Sergio. 2002. Programación de Aplicaciones Web: Historia, Principios Básicos y
Clientes Web. San Vicente, España. : Editorial Club Universitario., 2002. ISBN: 9788484542063.

83
MALHOTRA, Naresh K. 2008. Investigación de Mercados. México. : Pearson Educación. 5ta Edición.,
2008. ISBN: 9789702611851.

MINISTERIO DE SALUD. 2001. Manual de Procedmientos de Admisión Integral: En Establecimientos


de Primer Nivel de Atención. Lima, Perú : Stickcom S.A, 2001. ISBN: 9972878066.

NIÑO C. Yamith. 2012. slideshare. Sistemas de Información. [En línea] slideshare, 2 de Febrero de
2012. [Citado el: 31 de Mayo de 2018.] https://es.slideshare.net/adrysilvav/sistema-de-
informacion-11386704.

PÉREZ, Juan José, GARCÍA, Javier y TEJEDOR, Martín. 2002. Gestión Clínica: Conceptos y
Metodología de Implantación. Andalucía. : Rev Calidad Asistencial., 2002.

PRESSMAN, Roger S. 2010. Ingeniería de Software: Un Enfoque Práctico. Mexico D.F. : McGraw-Hill,
7ta Edición., 2010. ISBN: 9786071503145.

PYPL. 2017. PYPL PopularitY of Programming Language. PYPL PopularitY of Programming Language.
[En línea] PYPL, 31 de Diciembre de 2017. [Citado el: 25 de Mayo de 2018.]
http://pypl.github.io/PYPL.html.

RAMIRÉZ Hita, Susana. 2010. Calidad de Atención en Salud: Prácticas y Representaciones Sociales
en las Poblaciones Quechua y Aymara del Altiplano Boliviano. 2da Edición. La Paz, Bolivia. : Sistemas
Gráficos Color., 2010. ISBN: 9789995474225.

RIGGS, Simon y GIOLLI, Gianni. 2017. PostgreSQL 10 Administration Cookbook. Birmingham, Reino
Unido. : Packt Publishing., 2017. ISBN: 9781788474924.

SAWYER McFarland, David. 2015. Programación JavaScript y jQuery. Madrid, España. : Anaya
Multimedia, 3era Edición., 2015. ISBN: 9788441537453.

SOMMERVILLE, Ian. 2011. Ingeniería de Software. Naucalpan de Juárez, México. : Pearson


Educación, 9na Edición., 2011. ISBN: 9786073206037.

TIERNEY Jr, Lawrence M. y HENDERSON, Mark C. 2005. Historia Clínica del Paciente - Método
Basado en Evidencias. Mexido D.F : McGraw-Hill Interamericana Editores S.A., 2005. ISBN:
0071402608.

VILLARUEL Chico, Miguel Roberto. 2015. Sistema de Gestión para Historias Clínicas bajo la
Plataforma Android Orientado a los Médicos del Condominio del Hospital Millennium. Ambato,
Ecuador : s.n., 2015.

WESKE, Mathias. 2007. Business Process Management: Concepts, Languages, Architectures. Berlín,
Germany. : Springer., 2007. ISBN: 9783540735212.

84
ANEXOS

85
ANEXO 01: “Realidad Problemática”

Anexo 01 - 1: “Instrumento de Recolección de Datos”

Ilustración 29: Encuesta Satisfacción de Pacientes.


Fuente: Elaboración Propia.

86
Anexo 01 - 2: “Validación del Instrumento de Recolección de Datos”

a. Validación del Instrumento - Experto 1.

Ilustración 30: Validación del Instrumento de Recolección de Datos - Experto 1/1


Fuente: Elaboración Propia.

87
Ilustración 31: Validación del Instrumento de Recolección de Datos - Experto 1/2
Fuente: Elaboración Propia.

88
Ilustración 32: Validación del Instrumento de Recolección de Datos - Experto 1/3
Fuente: Elaboración Propia.

89
Ilustración 33: Validación del Instrumento de Recolección de Datos - Experto 1/4
Fuente: Elaboración Propia.

90
b. Validación del Instrumento - Experto 2.

Ilustración 34: Validación del Instrumento de Recolección de Datos - Experto 2/1


Fuente: Elaboración Propia.

91
Ilustración 35: Validación del Instrumento de Recolección de Datos - Experto 2/2
Fuente: Elaboración Propia.

92
Ilustración 36: Validación del Instrumento de Recolección de Datos - Experto 2/3
Fuente: Elaboración Propia.

93
Ilustración 37: Validación del Instrumento de Recolección de Datos - Experto 2/4
Fuente: Elaboración Propia.

94
c. Validación del Instrumento - Experto 3.

Ilustración 38: Validación del Instrumento de Recolección de Datos - Experto 3/1


Fuente: Elaboración Propia.

95
Ilustración 39: Validación del Instrumento de Recolección de Datos - Experto 3/2
Fuente: Elaboración Propia.

96
Ilustración 40: Validación del Instrumento de Recolección de Datos - Experto 3/3
Fuente: Elaboración Propia.

97
Ilustración 41: Validación del Instrumento de Recolección de Datos - Experto 3/4
Fuente: Elaboración Propia.

98
Anexo 01 - 3: “Validez y Fiabilidad”

a. Validez con análisis factorial del Proceso de registro de pacientes.

PRUEBA DE KMO Y BARTLETT


Medida Kaiser-Meyer-Olkin de adecuación de muestreo ,587
Aprox. Chi-cuadrado 231,152
Prueba de esfericidad de
gl 105
Bartlett Sig. ,000
Cuadro 16: Validez con Análisis Factorial - Prueba de KMO y Bartlett.
Fuente: Aplicación SPSS.

VARIANZA TOTAL EXPLICADA


Sumas de cargas al cuadrado Sumas de cargas al cuadrado
Autovalores iniciales
de la extracción de la rotación
Componente
% de % % de % % de %
Total Total Total
varianza acumulado varianza acumulado varianza acumulado
1 6,023 40,152 40,152 6,023 40,152 40,152 3,192 21,282 21,282
2 1,713 11,419 51,572 1,713 11,419 51,572 2,966 19,775 41,057
3 1,338 8,918 60,490 1,338 8,918 60,490 2,915 19,433 60,490
4 1,200 7,998 68,487
5 ,969 6,457 74,944
6 ,867 5,780 80,724
7 ,641 4,274 84,999
8 ,526 3,505 88,503
9 ,467 3,115 91,618
10 ,396 2,643 94,261
11 ,320 2,131 96,392
12 ,241 1,608 98,000
13 ,151 1,008 99,008
14 ,105 ,701 99,709
15 ,044 ,291 100,000
Método de extracción: análisis de componentes principales.
Cuadro 17: Validez con Análisis Factorial - Varianza Total Explicada.
Fuente: Aplicación SPSS.

MATRIZ DE COMPONENTE ROTADOa


Componente
Admisión Triage Consultorio Médico
i15 ,784
i13 ,751
i2 ,736
i11 ,617
i8 ,526
i7 ,804
i5 ,794
i10 ,739
i14 ,686
i12 ,739
i6 ,707
i4 ,690
i3 ,608
i1 ,568
i9 ,536
Método de extracción: análisis de componentes principales.
Método de rotación: Varimax con normalización Kaiser.
a. La rotación ha convergido en 6 iteraciones.
Cuadro 18: Validez con Análisis Factorial - Matriz de Componente Rotado.
Fuente: Aplicación SPSS.

99
b. Fiabilidad con Alfa de Cronbach del instrumento de proceso de registro de
pacientes.

RESUMEN DE PROCESAMIENTO DE CASOS


N %
Válido 30 100,0
Casos Excluidoa 0 ,0
Total 30 100,0
a. La eliminación por lista se basa en todas las variables del procedimiento.
Cuadro 19: Fiabilidad con Alfa de Cronbach - Resumen de Procesamiento de Casos.
Fuente: Aplicación SPSS.

ESTADÍSTICAS DE FIABILIDAD
Alfa de Cronbach basada en
Alfa de Cronbach N de elementos
elementos estandarizados
,891 ,891 15
Cuadro 20: Fiabilidad con Alfa de Cronbach - Estadísticas de Fiabilidad.
Fuente: Aplicación SPSS.

ESTADÍSTICAS DE TOTAL DE ELEMENTO


Varianza de
Media de escala Correlación total Correlación Alfa de Cronbach
escala si el
si el elemento se de elementos múltiple al si el elemento se
elemento se ha
ha suprimido corregida cuadrado ha suprimido
suprimido
i1 9,37 31,826 ,798 ,875 ,873
i2 9,63 34,102 ,600 ,850 ,882
i3 9,53 34,809 ,532 ,673 ,885
i4 9,77 36,185 ,396 ,735 ,890
i5 9,43 34,323 ,540 ,622 ,885
i6 9,80 35,338 ,526 ,592 ,886
i7 9,63 34,792 ,507 ,667 ,886
i8 9,70 35,528 ,500 ,628 ,886
i9 9,67 32,989 ,688 ,643 ,878
i10 9,43 33,633 ,542 ,631 ,885
i11 9,93 35,306 ,559 ,792 ,885
i12 9,20 34,786 ,487 ,822 ,887
i13 9,40 34,524 ,584 ,742 ,883
i14 9,70 34,631 ,572 ,728 ,884
i15 9,53 33,913 ,555 ,687 ,884
Cuadro 21: Fiabilidad de Alfa de Cronbach - Estadísticas de Total de Elemento.
Fuente: Aplicación SPSS.

100
ANEXO 02: “Viabilidad Económica”
2.1. Estudio de Factibilidad
2.1.1. Estructura de Costos
A. Costos de Inversión
 Hardware
RECURSO CANTIDAD PRECIO UNITARIO (S/.) TOTAL (S/.)
Computadora 5 2,000.00 10,000.00
Servidor de Datos 1 7,800.00 7,800.00
Impresora 5 865.00 4,325.00
COSTO TOTAL 22,125.00
Cuadro 22: Costos de Inversión - Hardware.
Fuente: Elaboración Propia.

 Software

LICENCIAS NOMBRE VERSIÓN TOTAL (S/.)


Lenguaje de Programación PHP 7.1 2018 0.00
Gestor de Base de Datos PostgreSQL 10 2018 0.00
Libre Office 2018 0.00
Ofimática
Office 2016 2016 865.00
Linux Ubuntu 18.04 2018 0.00
Sistema Operativo
Windows 10 Enterprise 2018 987.00
COSTO TOTAL 1,852.00
Cuadro 23: Costos de Inversión - Software.
Fuente: Elaboración Propia.

101
 Recursos Humanos

PERSONAL FUNCIÓN PAGO MENSUAL (S/.) N° MESES TOTAL (S/.)


Lee Frank Mendoza López Tesista 125.00 4 500.00
Juan Carlos Salinas Ruiz Tesista 125.00 4 500.00
TOTAL 1,000.00
Cuadro 24: Costos de Inversión - Recursos Humanos.
Fuente: Elaboración Propia.

 Materiales

MATERIAL UNIDAD DE MEDIDA CANTIDAD PRECIO UNITARIO (S/.) TOTAL (S/.)


Papelería Paquete 2 22.00 44.00
Lapiceros Unidad 10 1.50 15.00
Corrector Unidad 4 1.50 6.00
Folder Manila Unidad 10 1.00 10.00
Cartucho negro HP Unidad 4 35.00 140.00
Cartucho color HP Unidad 4 45.00 180.00
DVD Unidad 20 3.00 60.00
Útiles de escritorio Otros 1 15.00 15.00
TOTAL 470.00
Cuadro 25: Costos de Inversión - Materiales.
Fuente: Elaboración Propia.

102
 Consumo Eléctrico
Para el consumo eléctrico tomaremos en cuenta las 960 horas de desarrollo del proyecto y 30 horas uso de
impresora.
POTENCIA FRECUENCIA CONSUMO COSTO (S/.) IGV
EQUIPO CANTIDAD TOTAL (S/.)
WATTS KW HORAS KW/H KW/H (19%)
Computadora 1 400 0.40 960 384 0.5357 0.00 205.7088
Impresora 1 150 0.45 30 13.5 0.5357 0.00 28,9278
TOTAL 234.64
Cuadro 26: Costos de Inversión - Consumo Eléctrico.
Fuente: Datos de potencia y costo x Electro Oriente.

B. Costos de Operación
El Sistema será por el personal de admisión, triage, y el personal médico las cuales están distribuidos en 4
consultorios habilitados.

 Consumo Eléctrico Mensual


POTENCIA FRECUENCIA CONSUMO COSTO (S/.)
IGV
EQUIPO CANTIDAD HORAS DÍAS AL TOTAL (S/.)
WATTS KW KW/H KW/H (19%)
DIARIAS MES
Computadora 5 400 0.40 8 30 96.00 0.5357 0.00 257.136
Servidor de Datos 1 450 0.45 8 30 108.00 0.5357 0.00 57.856
Impresora 5 150 0.15 8 30 36.00 0.5357 0.00 96.426
TOTAL 411.418
Cuadro 27: Costos de Inversión - Consumo Eléctrico Mensual.
Fuente: Datos de potencia y costo: Electro Oriente.

103
 Costo Materiales.

DESCRIPCIÓN UNIDAD CANTIDAD PRECIO UNITARIO (S/.) SUBTOTAL MES (S/.)


Papel Bond A4 Millar 1 18.50 18.50
Tinta de Impresora Cartucho 2 45.00 90.00
CD's Unidad 5 1.00 5.00
TOTAL 113.50
Cuadro 28: Costos de Inversión - Materiales.
Fuente: Elaboración Propia.

 Costos de Mantenimiento

DESCRIPCIÓN Nº DE VECES COSTO UNITARIO (S/. ) TOTAL (S/.)


Computadora 2 30.00 60.00
Servidor 1 100.00 100.00
Impresora 2 30.00 60.00
TOTAL 220.00
Cuadro 29: Costos de Inversión - Costos de Mantenimiento.
Fuente: Elaboración Propia.

 Costos de Depreciación

DESCRIPCIÓN COSTO INICIAL (S/.) PORCENTAJE DE DEPRECIACIÓN TOTAL (S/.)


Computadora 10,000.00 20% 2,000.00
Servidor 7,800.00 20% 1,560.00
Impresora 4,325.00 20% 865.00
TOTAL 4,425.00
Cuadro 30: Costos de Inversión - Costos de Depreciación.
Fuente: Elaboración Propia.

104
 Costos de Capacitación.

DESCRIPCIÓN HORAS COSTO X HORA TOTAL (S/.)


Capacitación 2 50.00 100.00
TOTAL 100.00
Cuadro 31: Costos de inversión - Costos de capacitación.
Fuente: Elaboración Propia.

2.1.2. Beneficios del Proyecto


A. Proyección de Beneficios Tangibles
 Tiempo de Ahorro en Horas de Trabajo Mensual

TIEMPO AHORRADO
DESCRIPCIÓN SUELDO HORA (S/.) MONTO AHORRADO (S/.)
ESTIMADO MENSUALES (HORAS)
Proceso 1 3.50 190 665.00
Proceso 2 3.50 190 665.00
TOTAL 1,330.00
Cuadro 32: Tiempo de Ahorro en Horas de Trabajo Mensual.
Fuente: Elaboración Propia.

TIEMPO AHORRADO
DESCRIPCIÓN SUELDO HORA (S/.) MONTO AHORRADO (S/.)
ESTIMADO MENSUALES (HORAS)
Proceso 3 12.35 90.00 1,111.50
TOTAL 1,111.50
Cuadro 33: Tiempo de Ahorro en Horas de Generación de Reportes.
Fuente: Elaboración Propia.

105
 Ingresos Proyectados
Como consecuencia de la implementación del Sistema propuesto se proyecta mejorar los ingresos de la
empresa de la siguiente manera:

AÑO INGRESO PROYECTADO (S/.) PORCENTAJE DE AUMENTO EN INGRESOS BENEFICIOS PROYECTADOS (S/.)
2019 86,000.00 3.48% 3,005.00
2020 90,000.00 4.7% 4,300.00
2021 100,000.00 5.2% 5,200.00
Cuadro 34: Ingresos Proyectados.
Fuente: Elaboración Propia.

106
2.1.3. Flujo de Caja

Ilustración 42: Flujo de Caja.


Fuente: Elaboración Propia.

2.1.4. Análisis de Rentabilidad


A. VAN (Valor Anual Neto)
Criterio de Evaluación:

 VAN < 0  No conviene ejecutar el proyecto. El valor


actual de costos supera a los beneficios; por lo que el
capital invertido no rinde los beneficios suficientes para
hacer frente a sus costos financieros.
 VAN > 0  Conviene ejecutar el proyecto.
 VAN = 0  Es indiferente la oportunidad de inversión.

La Tasa mínima aceptable de rendimiento:

 Tasa (TMAR) = 15% - Fuente: Banco de Crédito.

107
Formula:
?@ ?@ ?@
=;8 = −5 + ABC
+ ABC D
+ ABC E
…………… G. -

Dónde:
 : Inversión inicial o flujo de caja en el periodo 0.
-
 B = Total de beneficios tangibles.
 C = Total de costos operaciones.
 N = Número de años (periodo).

Reemplazamos los beneficios y costos totales obtenidos en el


flujo de caja en la fórmula 3.10

NO,N N. ?A ,PQQ. O
H I = −19,424.73 + AB .AR
+
NN,RST. ?A ,PQQ. O NQ,QPT. ?A ,PQQ. O
AB .AR D + AB .AR E

VAN = -25,681.64+(32,303-10,944.02) /1.15+(33,598-


10,944.02) /1.3225+(34498-10944.02) /1.530875
VAN = -25,621.64
+21,358.98/1.15+22,654/1.3225+23553.98/1.520875
VAN = -25621.64+18573.026+17,129.66+15487.124188
H I = U/, /VW. WW
Interpretación: Al ser el VAN un valor mayor a cero, se puede
afirmar es conveniente ejecutar el proyecto.

B. Relación Beneficio/Costo (B/C)


La relación costo beneficio toma los ingresos y egresos presentes
netos del estado de resultado, para determinar cuáles son los
beneficios por cada nuevo sol que se invierte en el proyecto.

Formula:
X
= … … … … … G.
@ X @

108
Dónde:
 VAB: Valor Actual de Beneficios.
 VAC: Valor Actual de Costos.

Fórmula para Hallar VAB:


=;% = + + …………… G. U
ABC ABC D ABC E

Reemplazamos los beneficios obtenidos en el flujo de caja


en la fórmula 3.12

NO.N N. NN,RPT. NQ,QPT.


=;% = AB .AR
+
AB .AR D
+
AB .AR E

VAC = 28,089.5652 + 25,404.91493 + 22,682.9949


H = YV, YY. ZY/-G

Fórmula para Hallar VAC:


@ @ @
=;& = 5 + ABC
+ ABC D
+ AB E
…………… G. G

Reemplazamos los beneficios obtenidos en el flujo de caja


en la fórmula 3.13

A ,PQQ. O A .PQQ. O A .PQQ. O


=;& = 25,681.64 + AB .AR
+ AB .AR D
+ AB .AR E

VAC = 25,681.64 + 9516.539 + 8,275.25 + 7,195.8707


H = /-, VV]. U]

Reemplazamos los valores de VAB y VAC en la fórmula 3.11


YV, YY.ZY/-G
/ =
/-,VV].U]

= . /-

109
Interpretación: Por cada 1 sol que se invierte, obtendremos
una ganancia de S/. 0.50.

C. TIR (Tasa interna de retorno)


La tasa interna de retorno o tasa interna de rentabilidad (TIR) de
una inversión, está definida como la tasa de interés con la cual el
valor actual neto o valor presente neto (VAN o VPN) es igual a
cero. El VAN o VPN es calculado a partir del flujo de caja anual,
trasladando todas las cantidades futuras al presente. Es un
indicador de la rentabilidad de un proyecto, a mayor TIR, mayor
rentabilidad.

?@ ?@ ?@
0 = −5 + + + …………… G. Z
ABC ABC D ABC E

Usando la fórmula de Excel obtenemos el siguiente resultado:

Ilustración 43: Tasa Interna de Retorno.


Fuente: Elaboración Propia.

TIR = 68%
Interpretación: Debido a que TIR es mayor (40%) que la TMAR
(15%), asumimos que el proyecto es más rentable.

D. Tiempo de Recuperación de Capital


Esto indicador nos permitirá conocer el tiempo en el cual
recuperaremos la inversión (años / meses / días).

110
Fórmula:
= ?
-
… … … … … G. /

Dónde:
 Io: Capital Invertido.
 B: Beneficios generados por el proyecto.
 C: Costos Generados por el proyecto.

Reemplazando los datos en la fórmula 3.15, obtenemos el


siguiente resultado:

U/,VW .VZ
= … … … … … G. V
U ,G/W.]/

TR = 1.20
Interpretación: La TR es igual a (1.20) representa que el capital
invertido en el presente proyecto se recuperara en:

1 año
0.20 * 12 = 2.4, es decir 2 meses
0.4 * 30= 12, es decir 12 días

Conclusión:

CONCLUSIÓN ANÁLISIS DE RENTABILIDAD


VAN (Valor Actual Neto) S/ 25,568.188
B/C (Beneficio Costo) 1.50
TIR (Tasa interna de Retorno) 68%
Tiempo de recuperación de
1 año 2 meses y 12 días
capital
Cuadro 35: Conclusión análisis de rentabilidad.
Fuente: Elaboración Propia.

111
ANEXO 03: “Metodología de Desarrollo”

Anexo 03 - 1: “Desarrollo de la Metodología XP”


a. Descripción y Construcción de la Solución Propuesta.
Para la construcción de la solución del sistema informático propuesto se
utilizó la metodología ágil XP, debido a que permitió desarrollar la solución
en base a pruebas y errores, incentivando a la programación ordenada y a
las necesidades del cliente (centro médico FDA BIOSERVICES). Se define
más adelante las fases a desarrollar con la metodología elegida.

b. Personas Relacionadas con el Sistema Informático Propuesto.


Es toda aquella persona o usuario que se relaciona con el sistema para
interactuar con el mismo y están involucradas en los procesos. Se muestra
el siguiente cuadro N° 36:

Persona Vinculada con el Sistema Justificación


Es la primera instancia para el
Personal de Admisión registro de pacientes o asignar
citas médicas.
Es el encargado de realizar la
Personal de Triage evaluación al paciente antes de
pasar al consultorio médico.
Es el encargado de diagnosticar y
Personal Medico brindar los tratamientos al
paciente.
Es el encargado de acceder a
Personal de Administración todas las funciones del sistema y
generar los reportes necesarios.
Cuadro 36: Personas Relacionadas con el Sistema Informático Propuesto.
Fuente: Elaboración Propia.

1. FASE I: Exploración
En esta primera fase se considera el inicio para el desarrollo de sistema
informático propuesto, se realizó las respectivas coordinaciones con el cliente
(centro médico FDA BIOSERVICES), en donde nos dieron las facilidades para
el acceso al ambiente y la habilitación para acceder a la información requerida,
de esta manera no se impida el acceso al equipo de trabajo.

112
Se realizó las reuniones respectivas para informar el avance del desarrollo del
sistema informático propuesto con la finalidad de adaptarlo a las necesidades
del cliente en cada una de las pruebas presentadas. El equipo de trabajo realizó
la capacitación al personal del centro médico para lograr la operatividad en el
uso del software, realizando además la supervisión constante en el
cumplimiento de todas las fases de la metodología aplicada en el presente
trabajo de investigación para mantener el soporte adecuado a las correcciones
debidas en cada una las pruebas presentadas en el desarrollo del software.

2. FASE II: Planificación


Se detalla las historias de usuario que deben ordenarse para su
implementación que están vinculadas con las entregas. Acá se definen las
reuniones o grupos para el plan de entregas.

Además, los requerimientos de software que se utilizarán en el desarrollo de


software son: PHP como lenguaje de programación y PostgreSQL como base
de datos. Todas estas tecnologías están consideradas como software libre.

2.1. Resumen de Historias de Usuario


Se observa la planificación del sistema informático propuesto en el siguiente
cuadro N° 37:

N° Nombre H.U. Prioridad Riesgo Esfuerzo Iteración


1 Autenticar Usuario Alta Media 1 1
2 Gestionar Usuario Alta Media 2 1
3 Gestionar Paciente Alta Alta 3 1
4 Gestionar Medicamento Baja Medio 1 1
5 Gestionar Diagnóstico Actividad Baja Medio 2 1
6 Gestionar Medico Alta Alta 2 1
7 Gestionar Citas Médicas Alta Alta 2 2
8 Gestionar Evaluación (Triage) Alta Alta 2 2
9 Gestionar Diagnóstico (H.C.) Alta Alta 2 2
10 Consultar Diagnóstico (H.C.) Alta Alta 2 2
11 Gestionar Receta Médica Medio Medio 1 2
12 Generar Reporte de Atención Medio Medio 1 2
Cuadro 37: Resumen de Historias de Usuario.
Fuente: Elaboración Propia.

113
2.2. Fase de Interacciones
Se detalla las prioridades con relación al desarrollo del sistema informático
propuesto según las historias de usuarios por cada iteración y orden además
de la duración estimada para el desarrollo del software según necesidades del
cliente propiciadas en cada reunión establecida.

Iteración Descripción de la Iteración Orden de las H.U Duración

En esta iteración se realizará la


implementación de las historias de
usuarios de mayor prioridad y se
1 describirán las funcionalidades en 1, 2, 3, 4, 5, 6 2 semanas
cada una de las historias de
usuarios según el orden
establecido de 1 al 6.

En esta iteración se van a


implementar las historias de
usuarios restantes del 7 al 12, con
2 7, 8, 9, 10, 11, 12 2 semanas
esta parte se concluye la versión
final del sistema informático
propuesto.
Cuadro 38: Plan de Duración de Iteraciones.
Fuente: Elaboración Propia.

2.3. Plan de Entrega


Se detalla el cronograma de entregas que están definidas en las historias de
usuarios que serán agrupadas para conformar las entregas establecidas y
según su orden de cada historia de usuario asignadas por iteración.

Iteración Iteración 1 Iteración 2

Final 1era Iteración 2da semana de Final 2da Iteración 4ta semana de
Entrega
Mayo (2018) Mayo (2018)
Cuadro 39: Plan de Duración de la Entrega.
Fuente: Elaboración Propia.

114
2.4. Primera Iteración
HISTORIA DE USUARIO
Número: 1 Usuario: Administrador, Admisión, Triage,
Consultorio Médico.
Nombre de Historia: Autenticar Usuario.
Prioridad en Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 1 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar sesión al sistema informático mediante un usuario
y clave para verificar el registro en la base de datos y determinar el perfil
asignado por cada usuario que utilizará el sistema informático.
Observaciones: Esta historia de usuario está vinculado al acceso principal al
sistema informático que contiene los módulos respectivos según los perfiles
asignados a cada usuario registrado, esto ayudará al modelamiento y la
implementación de la base de datos, construcción de las clases e interfaces
respectivamente.
Cuadro 40: Historia de Usuario N° 1 - Autenticar Usuario.
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 2 Usuario: Administrador.

Nombre de Historia: Gestionar Usuario.


Prioridad en Negocio: Alta Riesgo en Desarrollo: Media
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 1 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el administrador realice el mantenimiento
de usuarios que ingresarán al sistema informático asignando su perfil respectivo
con sus acciones y reestablecer clave, debe crear, modificar y eliminar un
usuario o usuario existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de usuarios,
esto ayudará al modelamiento y la implementación de la base de datos,
construcción de las clases e interfaces respectivamente.
Cuadro 41: Historia de Usuario N° 2 - Gestionar Usuario.
Fuente: Elaboración Propia.

115
HISTORIA DE USUARIO
Número: 3 Usuario: Admisión.

Nombre de Historia: Gestionar Paciente.


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el área de admisión realice el
mantenimiento de pacientes con todos sus datos personales, dirección y generar
automáticamente su número de historia clínica, debe crear, modificar y eliminar
un paciente o paciente existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de
pacientes, esto ayudará al modelamiento y la implementación de la base de
datos, construcción de las clases e interfaces respectivamente.
Cuadro 42: Historia de Usuario N° 3 - Gestionar Paciente.
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 4 Usuario: Consultorio Médico.

Nombre de Historia: Gestionar Medicamento.


Prioridad en Negocio: Baja Riesgo en Desarrollo: Medio
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico realice el
mantenimiento de medicamentos con sus respectivos movimientos según tipo
de presentación, cantidad y tipo de unidades, además de generar el listado de
medicamentos registrados, debe crear, modificar y eliminar un medicamento o
medicamento existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de
medicamentos, esto ayudará al modelamiento y la implementación de la base de
datos, construcción de las clases e interfaces respectivamente.
Cuadro 43: Historia de Usuario N° 4 - Gestionar Medicamento.
Fuente: Elaboración Propia.

116
HISTORIA DE USUARIO
Número: 5 Usuario: Consultorio Médico.

Nombre de Historia: Gestionar Diagnóstico Actividad.


Prioridad en Negocio: Baja Riesgo en Desarrollo: Medio
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico realice el
mantenimiento de diagnóstico actividad relacionado al CIE10 con su código
respectivo o asignar un código ya existente como padre a un nuevo diagnóstico
actividad, debe crear, modificar y eliminar un diagnóstico actividad o diagnóstico
actividad existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de
diagnóstico actividad (CIE10), esto ayudará al modelamiento y la
implementación de la base de datos, construcción de las clases e interfaces
respectivamente.
Cuadro 44: Historia de Usuario N° 5 - Gestionar Diagnóstico Actividad.
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 6 Usuario: Admisión.

Nombre de Historia: Gestionar Médico.


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 1
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el área de admisión realice el
mantenimiento de médicos con su respectiva especialidad, debe crear, modificar
y eliminar un médico o médico existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de médicos
por especialidad, esto ayudará al modelamiento y la implementación de la base
de datos, construcción de las clases e interfaces respectivamente.
Cuadro 45: Historia de Usuario N° 6 - Gestionar Médico.
Fuente: Elaboración Propia.

117
2.5. Segunda Iteración
HISTORIA DE USUARIO
Número: 7 Usuario: Admisión.

Nombre de Historia: Gestionar Citas Médicas.


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el área de admisión realice el
mantenimiento de citas por cada paciente asignando el médico respectivo para
visualizar en el módulo de triage, debe crear, modificar y eliminar una cita médica
o cita médica existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de citas
médicas, esto ayudará al modelamiento y la implementación de la base de datos,
construcción de las clases e interfaces respectivamente.
Cuadro 46: Historia de Usuario N° 7 - Gestionar Citas Médicas.
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 8 Usuario: Triage.

Nombre de Historia: Gestionar Evaluación (Triage).


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el área de triage realice el mantenimiento
de evaluación por cada paciente que realizó el área de admisión al registrar la
cita médica, emisión de su documento triage para visualizar en el módulo de
consultorio médico y relacionarlo con su historial clínico, debe crear, modificar y
eliminar una evaluación triage o evaluación triage existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de
evaluación triage, esto ayudará al modelamiento y la implementación de la base
de datos, construcción de las clases e interfaces respectivamente.
Cuadro 47: Historia de Usuario N° 8 - Gestionar Evaluación Triage.
Fuente: Elaboración Propia.

118
HISTORIA DE USUARIO
Número: 9 Usuario: Consultorio Médico.

Nombre de Historia: Gestionar Diagnóstico (Historia Clínica).


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico visualice el listado de
pacientes por orden de llegada atendidos en triage y consultar su evaluación
triage realizado además de su historial clínico y emisión del documento
diagnóstico respectivo, debe crear, modificar y eliminar un diagnóstico (HC) o
diagnóstico (HC) existente.
Observaciones: Esta historia de usuario está vinculado a la gestión de
diagnósticos (Historia Clínica), esto ayudará al modelamiento y la
implementación de la base de datos, construcción de las clases e interfaces
respectivamente.
Cuadro 48: Historia de Usuario N° 9 - Gestionar Diagnóstico (HC).
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 10 Usuario: Consultorio Médico.

Nombre de Historia: Consultar Diagnóstico (Historia Clínica).


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico visualice el listado de
pacientes orden de llegada atendidos en triage y consultar su historial clínico
completo con documento de evaluación triage y recetas médicas registradas
según sea el caso.
Observaciones: Esta historia de usuario está vinculado a la consulta de
diagnóstico completo de cada paciente (Historia Clínica), esto está vinculado con
el registro de historia clínica, evaluación triage y receta médica ya existentes en
la base de datos.
Cuadro 49: Historia de Usuario N° 10 - Consultar Diagnóstico (HC).
Fuente: Elaboración Propia.

119
HISTORIA DE USUARIO
Número: 11 Usuario: Consultorio Médico.

Nombre de Historia: Gestionar Receta Médica.


Prioridad en Negocio: Alta Riesgo en Desarrollo: Alta
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 3 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico ya realizó el registro
del diagnóstico respectivo por paciente atendido, debe emitir la receta médica y
vincularlo por diagnóstico realizado, además de agregarlo a su historial clínico,
debe crear, modificar y eliminar una receta médica o receta médica existente.

Observaciones: Esta historia de usuario está vinculado a la gestión de recetas


médicas, esto ayudará al modelamiento y la implementación de la base de datos,
construcción de las clases e interfaces respectivamente.
Cuadro 50: Historia de Usuario N° 11 - Gestionar Receta Médica.
Fuente: Elaboración Propia.

HISTORIA DE USUARIO
Número: 12 Usuario: Administrador.

Nombre de Historia: Generar Reporte de Atención.


Prioridad en Negocio: Medio Riesgo en Desarrollo: Medio
(Alta, Media, Baja) (Alta, Media, Baja)
Puntos Estimados: 2 Iteración Asignada: 2
Programador Responsable: Lee Frank Mendoza López, Juan Carlos Salinas
Ruiz.
Descripción: Se debe iniciar cuando el consultorio médico ya realizó el registro
del diagnóstico respectivo por paciente atendido, debe seleccionar el tipo de
reporte por médico o por especialidad y el rango de fechas que desea visualizar,
se detalla la cantidad de atenciones según el tipo de reporte (por médico y por
especialidad) y rango de fechas seleccionadas.
Observaciones: Esta historia de usuario está vinculado a la generación de
reportes de atención, esto está vinculado siempre y cuando se realicen
atenciones en los consultorios médicos.
Cuadro 51: Historia de Usuario N° 12 - Generar Reporte de Atención.
Fuente: Elaboración Propia.

120
3. FASE III: Diseño
Se detalla las consideraciones de diseño que fueron priorizados inicialmente y
se plasmaron en práctica por la metodología elegida para el desarrollo del
sistema informático propuesto.

3.1. Diseño del Modelo Entidad Relación (DER)


Se define las entidades (objetos del mundo real) con sus respectivas
relaciones, además de sus atributos con su tipo de datos definidos por cada
regla de negocio para el correcto almacenamiento de la información, es el
modelo principal para la implementación de la base de datos que tendrá nuestro
sistema informático propuesto.

Ilustración 44: Diseño del Modelo Entidad Relación (DER).


Fuente: Elaboración Propia.

121
3.2. Codificación
a. Implementación de la base de datos
Se detallará como se deben de crear las respectivas tablas, las
columnas con sus respectivos tipos de datos, las llaves primarias y
foráneas y otras características propias del sistema de gestor de base
datos PostgreSQL que utilizará el sistema informático propuesto para
el centro médico FDA BIOSERVICES.

Se utilizó la herramienta libre PgAdmin 4 para la implementación de


la base de datos relacional denominado “dbappcentromedico” que
viene vinculado a la base de datos PostgreSQL, cada tabla creada
usa una secuencia independiente para la generación de
autoincremento en los campos con llave primaria, esto varia por tipo
de gestor de base de datos que se deba utilizar, se muestra
seguidamente en la ilustración N° 45:

Ilustración 45: Implementación de la Base de Datos en PostgreSQL.


Fuente: Elaboración Propia.

122
La siguiente ilustración N° 46 detalla la tabla “paciente” con la
herramienta PgAdmin 4, en donde muestra las columnas con sus
respectivos tipos de datos y restricciones con algunas tablas
relacionadas, además del código SQL generado por la misma
herramienta de manera automática.

Ilustración 46: Implementación del Modelo Relacional en PostgreSQL.


Fuente: Elaboración Propia.

b. Diseño de la Arquitectura de Desarrollo


Para el diseño de la arquitectura propuesta, se utilizó el patrón de
diseño de software HMVC (Modelo-Vista-Controlador-Jerárquico),
esta arquitectura permite agregar MVC independientes para cada
módulo a construir sin afectar la facilidad del mantenimiento además
de ser escalable a futuros módulos a construir, además de utilizar en
el desarrollo del software el lenguaje de programación PHP. Se
muestra en la siguiente ilustración N° 47:

Ilustración 47: Diseño de la Arquitectura de Desarrollo.


Fuente: Elaboración Propia.

123
En la siguiente ilustración N° 48, se muestra la clase Database en
PHP para la conexión a la base de datos PostgreSQL (pgsql)
utilizando la librería PDO que nos permite además de acceder a
diferentes tipos de base de datos, evita ataques por inyección SQL
utilizando el método “prepare” en las consultas preparadas definidas
como sentencias SQL precompiladas.

Ilustración 48: Clase Database en PHP con PDO.


Fuente: Elaboración Propia.

124
En la siguiente ilustración N° 49, se muestra la clase del controlador
loginController en PHP con los respectivos modelos, en donde el
método index carga como pantalla principal el login de la aplicación
en la vista para acceder a través de un usuario y clave registrados en
la base de datos cuando se inicia el sistema informático propuesto
desde un navegador web. Seguidamente en la ilustración N° 50 se
muestra el código JavaScript para realizar el proceso de autenticación
de usuario del sistema informático.

Ilustración 49: Clase loginController en PHP.


Fuente: Elaboración Propia.

Ilustración 50: Código JavaScript - Autenticación de Usuario.


Fuente: Elaboración Propia.

125
4. FASE IV: Pruebas
Se detalla las pruebas realizadas por todo el equipo de trabajo que
satisfactoriamente se convirtieron en lanzamientos. Seguidamente se muestran
las ilustraciones del sistema informático propuesto como parte de la
implementación:

En la ilustración N° 51 se visualiza el login del sistema para acceder a través


de un usuario y contraseña registrados en la base de datos. Seguidamente en
la ilustración N° 52 se visualiza la pantalla principal cuando el usuario y su
contraseña son validados con su respectivo perfil asignado.

Ilustración 51: Login del Sistema Modular Web.


Fuente: Elaboración Propia.

Ilustración 52: Pantalla Principal del Sistema Modular Web.


Fuente: Elaboración Propia.

126
En la ilustración N° 53, se visualiza el listado de usuarios registrados en la base
de datos con sus respectivas acciones para realizar el mantenimiento
respectivo. Seguidamente en la ilustración N° 54, se visualiza el formulario de
registro de un nuevo usuario con sus respectivos datos que son necesarios
para acceder al sistema informático.

Ilustración 53: Gestión de Usuario - Listado de Usuarios Registrados.


Fuente: Elaboración Propia.

Ilustración 54: Gestión de Usuario - Registrar Nuevo Usuario.


Fuente: Elaboración Propia.

127
En la ilustración N° 55, se visualiza el listado de pacientes registrados en la
base de datos con sus respectivas acciones para realizar el mantenimiento
respectivo. Seguidamente en la ilustración N° 56, se visualiza el formulario de
registro de un nuevo paciente con sus respectivos datos que son necesarios
para generar su número de historia clínica automáticamente.

Ilustración 55: Gestión de Paciente - Listado de Pacientes Registrados.


Fuente: Elaboración Propia.

Ilustración 56: Gestión de Paciente - Registrar Nuevo Paciente.


Fuente: Elaboración Propia.

128
En la ilustración N° 57, se visualiza el listado de médicos registrados en la base
de datos con sus respectivas acciones para realizar el mantenimiento
respectivo. Seguidamente en la ilustración N° 58, se visualiza el formulario de
registro de un nuevo medico con sus respectivos datos además de asignar la
especialidad correspondiente que tuviera el médico.

Ilustración 57: Gestión de Médico - Listado de Médicos Registrados.


Fuente: Elaboración Propia.

Ilustración 58: Gestión de Médico - Registrar Nuevo Médico.


Fuente: Elaboración Propia.

129
En la ilustración N° 59, se visualiza el listado de citas médicas registradas en la
base de datos con sus respectivas acciones para realizar el mantenimiento
respectivo. Seguidamente en la ilustración N° 60, se visualiza el formulario de
registro de una nueva cita médica con sus respectivos datos para visualizarse
en el área de triage.

Ilustración 59: Gestión de Citas - Listado de Citas Registradas.


Fuente: Elaboración Propia.

Ilustración 60: Gestión de Citas - Registrar Nueva Cita.


Fuente: Elaboración Propia.

130
En la ilustración N° 61, se visualiza el listado de citas médicas para triage
registradas en la base de datos con sus respectivas acciones para realizar el
mantenimiento respectivo. Seguidamente en la ilustración N° 62, se visualiza el
formulario de registro de una nueva evaluación triage por paciente según cita
con sus respectivos datos para visualizarse en el consultorio médico.

Ilustración 61: Gestión de Triage - Listado de Citas Triage.


Fuente: Elaboración Propia.

Ilustración 62: Gestión de Triage - Registrar Nueva Evaluación Triage.


Fuente: Elaboración Propia.

131
En la ilustración N° 63, se visualiza la confirmación del registro de la nueva
evaluación triage generando su número de documento triage automáticamente.
Seguidamente en la ilustración N° 64, se visualiza el reporte del documento
triage generado para ser adjuntado a su historial clínico y verificado por el
especialista de salud en el consultorio médico para ser atendido.

Ilustración 63: Gestión de Triage - Confirmación de Registro Evaluación Triage.


Fuente: Elaboración Propia.

Ilustración 64: Gestión de Triage - Reporte de Documento Evaluación Triage.


Fuente: Elaboración Propia.

132
En la ilustración N° 65, se visualiza el listado de citas médicas para consultorio
médico con atención de triage registradas en la base de datos con sus
respectivas acciones para realizar el mantenimiento respectivo. Seguidamente
en la ilustración N° 66, se visualiza el formulario de registro de un nuevo
diagnóstico con evaluación triage por paciente según cita con sus respectivos
datos además de visualizar su historia clínica completa si tuviera registros.

Ilustración 65: Gestión de Diagnóstico (H.C.) - Listado de Citas con Evaluación Triage.
Fuente: Elaboración Propia.

Ilustración 66: Gestión de Diagnóstico (H.C.) - Registrar Nuevo Diagnóstico.


Fuente: Elaboración Propia.

133
En la ilustración N° 67, se visualiza la confirmación del registro del diagnóstico
realizado por el especialista de salud a un determinado paciente según cita
médica. Seguidamente en la ilustración N° 68, se visualiza el reporte del
documento de diagnóstico realizado para ser adjuntado a su historial clínico
actualizando su situación como atendido y respectivamente emitir su receta
médica según caso si fuera necesario.

Ilustración 67: Gestión de Diagnóstico (H.C.) - Confirmación de Registro de Diagnóstico.


Fuente: Elaboración Propia.

Ilustración 68: Gestión de Diagnóstico (H.C.) - Reporte de Documento Diagnóstico Clínico.


Fuente: Elaboración Propia.

134
En la ilustración N° 69 se visualiza el modal para la consulta de historia clínica
de un determinado paciente seleccionado en el listado de citas con evaluación
triage atendido en el consultorio médico. Seguidamente en la ilustración N° 70,
se visualiza su historia clínica completa con receta médica si hubiera registros.

Ilustración 69: Gestión de Diagnóstico (H.C.) - Consultar Historia Clínica.


Fuente: Elaboración Propia.

Ilustración 70: Gestión de Diagnóstico (H.C.) - Reporte de Historia Clínica.


Fuente: Elaboración Propia.

135
En la ilustración N° 71, se visualiza el formulario de emisión de una nueva
receta médica después de realizar el diagnóstico respectivo a un determinado
paciente con todos los datos respectivos. Seguidamente en la ilustración N° 72,
se visualiza el reporte del documento de receta médica realizado para ser
adjuntado a su historial clínico y brindar al paciente atendido.

Ilustración 71: Gestión de Receta Médica - Emitir Receta Médica.


Fuente: Elaboración Propia.

Ilustración 72: Gestión de Receta Médica - Reporte de Documento Receta Médica.


Fuente: Elaboración Propia.

136
En la ilustración N° 73, se visualiza el formulario de reportes de atenciones por
rango de fechas según médico. Seguidamente en la ilustración N° 74, se
visualiza el reporte por tipo de especialidad.

Ilustración 73: Gestión de Reportes - Reporte de Atenciones por Médico.


Fuente: Elaboración Propia.

Ilustración 74: Gestión de Reportes - Reporte de Atenciones por Especialidad.


Fuente: Elaboración Propia.

137
ANEXO 04: “Resultados”

Anexo 04 - 1: “Tabla de Distribución Z”

Ilustración 75: Tabla de Distribución Z.


Fuente: (MELLADO Bosque, 2010).

138
Anexo 04 - 2: “Tabla de Distribución T-student”

Ilustración 76: Tabla de Distribución T-student.


Fuente: (MELLADO Bosque, 2010).

139
Anexo 04 - 3: “Evaluación de la Variable Independiente”
a. Usabilidad del Sistema - Experto 1.

Ilustración 77: Evaluación de la Variable Independiente - Experto 1.


Fuente: Elaboración Propia.

140
b. Usabilidad del Sistema - Experto 2.

Ilustración 78: Evaluación de la Variable Independiente - Experto 2.


Fuente: Elaboración Propia.

141
c. Usabilidad del Sistema - Experto 3.

Ilustración 79: Evaluación de la Variable Independiente - Experto 3.


Fuente: Elaboración Propia.

142
d. Usabilidad del Sistema - Experto 4.

Ilustración 80: Evaluación de la Variable Independiente - Experto 4.


Fuente: Elaboración Propia.

143
Anexo 04 - 4: “Base de Datos de Indicadores”
a. Data del Indicador N° 1.

Ilustración 81: Data del Indicador N° 1.


Fuente: Elaboración Propia.

144
b. Data del Indicador N° 2.

Ilustración 82: Data del Indicador N° 2.


Fuente: Elaboración Propia.

145
c. Data del Indicador N° 3.

Ilustración 83: Data del Indicador N° 3.


Fuente: Elaboración Propia.

146
ANEXO 05: “Matriz de Consistencia del Proyecto de Investigación”
Título: Sistema Modular Web para Mejorar el Proceso de Registro de Pacientes del Centro Médico FDA BIOSERVICES, Iquitos.
FORMULACION DEL
HIPOTESIS OBJETIVOS VARIABLES MARCO TEORICO DIMENSIONES METODOS
PROBLEMA

Problema General Hipótesis General Objetivo General Proceso, Atención, Diseño:


¿De qué manera un Un sistema modular Determinar la manera V1. Atención de Salud, Experimental
sistema modular web web mejora que un sistema modular Paciente, Historia Pre
mejorará el proceso de significativamente el web mejorará el proceso Proceso de Clínica, Historia Dimensión de experimental.
registro de pacientes proceso de registro de de registro de pacientes Registro de Clínica Electrónica, Registro de G O1 X O2
del centro médico FDA pacientes en el Centro del centro médico FDA Pacientes. Gestión Clínica, Pacientes.
BIOSERVICES de la Médico FDA BIOSERVICES de la Admisión en Salud, Población:
ciudad de Iquitos? BIOSERVICES de la ciudad de Iquitos. Triage, Consultorio 30 atenciones
ciudad de Iquitos. Médico. de pacientes
Problema Especifico Hipótesis Especifica Objetivo Especifico Sistema, Sistema concurrentes
1. ¿De qué manera un H1: Un sistema Establecer si un sistema V2. de Información, con historia
sistema modular web modular web mejora la modular web mejorará la Sistema de clínica por día.
mejorará la búsqueda búsqueda de historias búsqueda de historias Sistema Información de Desarrollo del
de historias clínicas clínicas de los clínicas en el centro Modular Registro de Sistema Muestra: Total
del centro médico FDA pacientes en el centro médico FDA Web. Historias Clínicas, Modular Web. de la población.
BIOSERVICES de la médico FDA BIOSERVICES de la Sistema de
ciudad de Iquitos? BIOSERVICES de la ciudad de Iquitos. Administración de Técnicas:
ciudad de Iquitos. Pacientes, Encuestas,

147
2. ¿De qué manera H2: Una base de datos Establecer si una base Aplicación Web, Focus group.
una base de datos permite la generación de datos permite la HMVC, PHP,
permitirá la generación de reportes y evita la generación de reportes y JAVASCRIPT y Instrumentos:
de reportes y evitará la duplicidad de registro evita la duplicidad de JQUERY, Cuestionarios,
duplicidad de registro de información de registro de información POSTGRESQL. observación
de información de pacientes del centro de pacientes del centro y formatos de
pacientes del centro médico FDA médico FDA reportes.
médico FDA BIOSERVICES de la BIOSERVICES de la
BIOSERVICES de la ciudad de Iquitos. ciudad de Iquitos. Métodos de
ciudad de Iquitos? Análisis de
3. ¿La implantación H3: Un sistema Evaluar el nivel de Investigación:
del sistema modular modular web en satisfacción de los Estadística
web del centro médico producción del centro pacientes antes y descriptiva e
FDA BIOSERVICES médico FDA después de la inferencial; y el
de la ciudad de Iquitos BIOSERVICES de la implantación del sistema paquete
mejorará el nivel de ciudad de Iquitos modular web del centro estadístico
satisfacción de los mejora el nivel de médico FDA SPSS.
pacientes? satisfacción de los BIOSERVICES.
pacientes.
Cuadro 52: Matriz de Consistencia.
Fuente: Elaboración Propia.

148
ANEXO 06: “Cartas, Solicitudes y Otros”
Anexo 06 - 1: “Carta de Aceptación de la Empresa”

Ilustración 84: Carta de Aceptación de la Empresa.


Fuente: Elaboración Propia.

149
Anexo 06 - 2: “Carta de Conformidad de la Empresa”

Ilustración 85: Carta de Conformidad de la Empresa.


Fuente: Elaboración Propia.

150
Anexo 07 - 1: “Acta de Originalidad”

Ilustración 86: Acta de Originalidad.


Fuente: Elaboración Propia.

151
Anexo 07 - 2: “Acta de Originalidad - Turnitin”

Ilustración 87: Acta de Originalidad - Turnitin.


Fuente: Elaboración Propia.

152

También podría gustarte