Sistema informático para la gestión de las historias clínicas en los estudios de imagen médicas

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas

SISTEMA INFORMÁTICO PARA LA GESTIÓN DE LAS HISTORIAS CLÍNICAS EN LOS ESTUDIOS DE IMAGEN MÉDICAS DEL LABORATORIO CLÍNICO CEDYLABE EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSACHILAS DURANTE EL PERÍODO 2017-2018.

Trabajo de Titulación previa a la obtención del título de Ingenieros de Sistemas y Computación

Línea de Investigación: Estudio, Diseño e Implementación de Software

Autores: ALEJANDRO JOSÉ GONZÁLEZ ALCOLADO JUAN PABLO CRESPO OBACO

Director: Mg. RODOLFO SIRILO CÓRDOVA GÁLVEZ

Santo Domingo – Ecuador Enero, 2018

PONTIFICIA UNIVERSIDAD CATÓLICA DEL ECUADOR SEDE SANTO DOMINGO

Dirección Académica - Escuela de Sistemas HOJA DE APROBACIÓN

SISTEMA INFORMÁTICO PARA LA GESTIÓN DE LAS HISTORIAS CLÍNICAS EN LOS ESTUDIOS DE IMAGEN MÉDICAS DEL LABORATORIO CLÍNICO CEDYLABE EN LA PROVINCIA DE SANTO DOMINGO DE LOS TSACHILAS DURANTE EL PERÍODO 2017-2018.

Línea de Investigación: Estudio, Diseño e Implementación de Software Autores: ALEJANDRO JOSÉ GONZÁLEZ ALCOLADO JUAN PABLO CRESPO OBACO Rodolfo Sirilo Córdova Gálvez, Mg.

f.

DIRECTOR DEL TRABAJO DE TITULACIÓN Fausto Ernesto Orozco Iguasnia, Mg.

f.

CALIFICADOR Jon Azcona Esteban, Mg.

f.

CALIFICADOR Luis Javier Ulloa Meneses, Mg.

f.

DIRECTOR DE LA ESCUELA DE SISTEMAS Santo Domingo – Ecuador Enero, 2018

iii

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Alejandro José González Alcolado portador de la cédula de ciudadanía Nº 1724894256 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Alejandro José González Alcolado CI 1724894256

iv

DECLARACIÓN DE AUTENTICIDAD Y RESPONSABILIDAD

Yo, Juan Pablo Crespo Obaco portador de la cédula de ciudadanía N° 1900402155 declaro que los resultados obtenidos en la investigación que presento como informe final, previo a la obtención del Grado de Ingeniero de Sistemas y Computación son absolutamente originales, auténticos y personales.

En tal virtud, declaro que el contenido, las conclusiones y los efectos legales y académicos que se desprenden del trabajo propuesto de investigación y luego de la redacción de este documento son y serán de mi sola y exclusiva responsabilidad legal y académica.

Juan Pablo Crespo Obaco CI 1900402155

v

AGRADECIMIENTO Expreso mi agradecimiento a Dios por las bendiciones vertidas sobre mi familia y mi persona, al apoyo incondicional de mi madre quien ha sido el pilar fundamental en mi camino, ahora ya culminando mi recorrido universitario puedo decir, gracias mamá por lo que soy, de igual forma agradezco a mis hermanos quienes me han sabido aconsejar y motivarme para jamás desfallecer en esta meta cumplida.

A los docentes en todo el transcurso de mi formación, en especial a los profesores de la universidad, gracias a sus enseñanzas y amistad he podido seguir con este un sueño cumplido agradezco a todo ellos por sus enseñanzas y conocimientos impartidos.

Juan Crespo

Agradezco a mis padres por permitirme estudiar esta carrera y por haberme brindado todas las facilidades necesarias para cruzarla. De la misma forma agradezco a mi tía que me ha apoyado durante todo el transcurso de mi formación académica al igual que a toda mi familia por haberme dado motivación y apoyo emocional.

Alejandro González

vi

DEDICATORIA

Dedico el siguiente trabajo de disertación de grado a mi madre por permitirme el estudio de tercer nivel, por ser lo más importante en mi vida y un ejemplo para mí, a mis hermanos quienes siempre han estado presentes para apoyarme y a todas las personas con las que he podido compartir todo este camino universitario, profesores y amigos.

Juan Crespo

A mi familia.

Alejandro González

vii

RESUMEN El presente proyecto de disertación de grado comprende la gestión de historias clínicas en el laboratorio clínico Cedylabe de Santo Domingo de los Tsáchilas mediante el desarrollo e implementación de un sistema informático con arquitectura cliente servidor.

Dicho sistema está elaborado con la finalidad de reducir los tiempos empleados en el manejo de registros clínicos para los nuevos clientes y para la actualización de los datos de aquellos que ya consten en los registros, además el sistema es importante para prevenir la pérdida de información y facilitar el proceso de las comparaciones históricas entre los registros equivalentes. La presente investigación se realizó de forma secuencial, paso a paso, utilizando la metodología de desarrollo de software XP como guía, la cual fue la escogida de acuerdo a análisis comparativos entre metodologías. Utiliza una arquitectura Modelo Vista Controlador, Django como framework web para el desarrollo ágil, Bootstrap y Javascript como herramienta de programación frontend, Postgresql para la gestión de la bases de datos, Nginx y Gunicorn para el soporte del servicio, además de otras librerías específicas para detalles de la aplicación, con el fin de corresponder al cliente con un sistema agradable a la vista y de fácil utilización para los usuarios.

Palabras claves: Información médica, software de código abierto, automatización.

viii

ABSTRACT The present project of degree dissertation includes the management of clinical histories in the clinical laboratory Cedylabe of Santo Domingo de los Tsรกchilas through the development and implementation of a computer system with client server architecture. This system is designed to decrease the time spent in the management of clinical records for new clients and to update data from those already included in the records, in addition the system is important to prevent the loss of information and facilitate the process of historical comparisons between equivalent records. The present research was carried out in sequence, step by step, using the XP software development methodology as a guide, which was chosen according to comparative analysis between methodologies. It uses a Model View Controller architecture, Django as a web framework for agile development, Bootstrap and Javascript as a frontend programming tool, Postgresql for database management, Nginx and Gunicorn for the support of the service as well as other specific libraries for details of the application, in order to match to the client with a pleasant system in sight and easy to use for users.

Keywords: Medical information, open source software, automatization.

ix

ÍNDICE DE CONTENIDOS 1.

INTRODUCCIÓN…………………………..…………………………………………1

2.

PLANTEAMIENTO DEL PROBLEMA....………..………………………………….2

2.1.

Antecedentes.................................................................................................................. 2

2.2.

Problema de investigación ............................................................................................. 5

2.3.

Justificación de la investigación .................................................................................... 5

2.4.

Objetivos de investigación ............................................................................................ 7

2.4.1. Objetivo General. .......................................................................................................... 7 2.4.2. Objetivos Específicos.................................................................................................... 7 3.

MARCO REFERENCIAL……….……………………………………………………8

3.1.

Esquema de Contenidos ............................................................................................... 8

3.2.

Revisión de la literatura o fundamentos teóricos ......................................................... 9

3.2.1. Software. ....................................................................................................................... 9 3.2.1.1. Software Libre. ............................................................................................................. 9 3.2.1.2. Ingeniería de software. ................................................................................................ 10 3.2.1.3. Lenguaje unificado de modelado uml ......................................................................... 10 3.2.1.4. Arquitectura mvc. ....................................................................................................... 11 3.2.1.5. Patrones de diseño....................................................................................................... 11 3.2.1.6. Lenguajes de programación. ....................................................................................... 13 3.2.2. Base de datos............................................................................................................... 15 3.2.2.1. Base de datos relacionales. ......................................................................................... 15 3.2.3. Herramientas para el desarrollo e implementación. .................................................... 18 3.2.3.1. Django……………………………………………………………………………….18 3.2.3.2. Servidor..…………………………………………………………………………….19 3.2.3.3. Herramientas para el desarrollo. ................................................................................. 20 3.2.4

Metodologías de Desarrollo de Software. ................................................................... 22

3.2.4.1. Metodologías tradicionales. ........................................................................................ 22 3.2.4.2. Metodologías ágiles. ................................................................................................... 22 3.2.4.3. Diferencias entre las metodologías tradicionales y las metodologías ágiles. ............. 24 3.2.4.4. Metodología scrum. .................................................................................................... 25 3.2.4.5. Comparativa de metodologías ágiles. ......................................................................... 26 3.2.5. Manejo de Historias Clínicas. ..................................................................................... 27 3.2.5.1. Historia clínica. ........................................................................................................... 27

x

3.2.5.2. Hce…………………………………………………………………………………..29 4.

METODOLOGÍA DE LA INVESTIGACIÓN…………………………….………..30

4.1.

Enfoque / Tipo de investigación .................................................................................. 30

4.2.

Población / Muestra ..................................................................................................... 30

4.3.

Técnicas e Instrumentos de recogida de datos ............................................................ 31

4.4.

Técnicas de Análisis de Datos ..................................................................................... 31

5.

RESULTADOS……………………………………………………………………..32

5.1.

Discusión y Análisis de los resultados ....................................................................... 32

5.1.1. Entrevista discusión, encuesta discusión. ................................................................... 32 5.1.2. Encuesta realizada a los miembros de la muestra ....................................................... 34 5.1.3. Diagrama de procesos. ................................................................................................ 43 5.2.

Propuesta de intervención........................................................................................... 43

5.2.1. Desarrollo del producto de software. .......................................................................... 43 5.2.2. Roles para el proceso de desarrollo del software en la comunidad del trabajo. ......... 43 5.2.3. Fases primordiales para el desarrollo en función a la metodología. ........................... 44 5.2.3.1. Fase i: exploración. ..................................................................................................... 44 5.2.3.2. Fase ii: planificación de entrega. ................................................................................ 48 5.2.3.3. Fase iii: iteraciones. .................................................................................................... 52 5.2.3.4. Fase IV: Pruebas ......................................................................................................... 70 5.3.

Evaluación de impacto del proyecto............................................................................ 75

5.3.1. Impacto tecnológico. .................................................................................................... 76 5.3.2. Impacto social. ............................................................................................................. 77 5.3.3. Impacto Económico. .................................................................................................... 78 5.3.4. Impacto general. ........................................................................................................... 78 5.4.

Conclusiones................................................................................................................. 80

5.5.

Recomendaciones ......................................................................................................... 82 GLOSARIO ................................................................................................................. 88 ANEXOS ..................................................................................................................... 90

xi

ÍNDICE DE TABLAS Tabla 1 Comparativa Metodología Tradicional y Ágil ............................................................ 24 Tabla 2 Comparativa Métodos Ágiles ..................................................................................... 26 Tabla 3 Resultados de la encuesta pregunta 1 ......................................................................... 34 Tabla 4 Resultados de la encuesta pregunta 2 ......................................................................... 35 Tabla 5 Resultados de la encuesta pregunta 3 ......................................................................... 36 Tabla 6 Resultados de la encuesta pregunta 4 ......................................................................... 37 Tabla 7 Resultados de la encuesta pregunta 5 ......................................................................... 38 Tabla 8 Resultados de la encuesta pregunta 6. ........................................................................ 39 Tabla 9 Resultados de la encuesta pregunta 7. ........................................................................ 40 Tabla 10 Resultados de la encuesta pregunta 8. ...................................................................... 41 Tabla 11 Resultados de la encuesta pregunta 9. ...................................................................... 42 Tabla 12 Historia de Usuario –Administración de pacientes................................................... 45 Tabla 13 Historia de Usuario – Creación de médico solicitante .............................................. 46 Tabla 14 Historia de Usuario – Administración de historias clínicas ...................................... 47 Tabla 15 Calendario de trabajo ................................................................................................ 49 Tabla 16 Esfuerzo de desarrollo .............................................................................................. 49 Tabla 17 Plan de Entregas........................................................................................................ 50 Tabla 18 Plan de Iteraciones .................................................................................................... 51 Tabla 19 Prueba de funcionalidad – Modulo de pacientes. ..................................................... 70 Tabla 20 Prueba de funcionalidad – Médico solicitante .......................................................... 71 Tabla 21 Prueba de funcionalidad – Módulos de Historias clínicas ........................................ 72 Tabla 22 Prueba de funcionalidad – Operación final para obtener Reportes .......................... 73 Tabla 23 Prueba de funcionalidad – Operación final para Administrar .................................. 74 Tabla 24 Prueba de funcionalidad – Operación final para Acceso de usuarios. ...................... 75 Tabla 25 Descripción de los valores asignados a cada nivel de impacto................................. 76 Tabla 26 Impacto según el ámbito tecnológico ....................................................................... 76 Tabla 27 Impacto según el ámbito social ................................................................................. 77 Tabla 28 Impacto según el ámbito económico ........................................................................ 78 Tabla 29 Resultado de impacto ................................................................................................ 78

xii

ÍNDICE DE FIGURAS Figura 1. Esquema de contenidos – variable independiente. ..................................................... 8 Figura 2. Esquema de contenidos - variable dependiente. ......................................................... 9 Figura 3. Clasificación de los patrones. ................................................................................... 12 Figura 4. Gráfico de resultados a la pregunta 1. ...................................................................... 34 Figura 5. Gráfico de resultados a la pregunta 2. ...................................................................... 35 Figura 6. Gráfico de resultados a la pregunta 3. ...................................................................... 36 Figura 7. Gráfico de resultados a la pregunta 4. ...................................................................... 37 Figura 8. Gráfico de resultados a la pregunta 5. ...................................................................... 38 Figura 9. Gráfico de resultados a la pregunta 6. ...................................................................... 39 Figura: 10. Gráfico de resultados a la pregunta 7. ................................................................... 40 Figura 11. Gráfico de resultados a la pregunta 8. ................................................................... 41 Figura 12. Gráfico de resultados a la pregunta 9. .................................................................... 42 Figura 13. Diagrama de procesos............................................................................................. 43 Figura 14. Modelo de datos.. ................................................................................................... 53 Figura 15. Modelo físico de datos............................................................................................ 53 Figura 16. Modelo de casos de usos.. ...................................................................................... 54 Figura 17. Registro de pacientes. ............................................................................................. 55 Figura 18. Tabla general de pacientes...................................................................................... 55 Figura 19. Creación de médicos solicitantes............................................................................ 56 Figura 20. Registro de pedidos de historias clínicas.. ............................................................. 56 Figura 21. Consulta de historia clínica.. .................................................................................. 57 Figura 22. Modificación de historias clínicas. ......................................................................... 57 Figura 23. Impresión de historia clínica. ................................................................................. 58 Figura 24. Reportes - selección de fechas y opciones. ............................................................ 58 Figura 25. Reporte – selección tipo de placas.......................................................................... 59 Figura 26. Reporte - cortesías últimas pacientes.. ................................................................... 59 Figura 27. Reporte - tipos de estudios.. ................................................................................... 60 Figura 28. Reporte – médicos. ................................................................................................. 60 Figura 29. Reporte - placas desechadas. .................................................................................. 61 Figura 30. Administración del sitio.. ....................................................................................... 61 Figura 31. Lista de usuarios. .................................................................................................... 62 Figura 32. Agregar usuario. ..................................................................................................... 62

xiii

Figura 33. Modificación de usuario. ........................................................................................ 63 Figura 34. Selección de permisos de usuario. .......................................................................... 63 Figura 35. Ingreso de fechas importantes. .............................................................................. 64 Figura 36. Login del súper-usuario. ......................................................................................... 64 Figura 37. Login de usuario. .................................................................................................... 64 Figura 38. Diseño de clases. .................................................................................................... 65 Figura 39. Diseño de clases- interfaz administración. ............................................................. 66 Figura 40. Código fuente de prueba unitaria automática. ........................................................ 67 Figura 41. Ejecución de prueba unitaria automática. ............................................................... 67 Figura 42. Estructura jerárquica de los controladores. ............................................................ 69

xiv

ร NDICE DE ANEXOS Anexo 1: Acta de entrega-recepciรณn del proyecto ................................................................... 90 Anexo 2: Carta de impacto ...................................................................................................... 91 Anexo 3: Historias de usuario .................................................................................................. 92 Anexo 4: Diccionario de datos ............................................................................................... 100 Anexo 5: Manual de instalaciรณn ............................................................................................ 102 Anexo 6: Manual de usuario .................................................................................................. 111

1

1. INTRODUCCIÓN El Centro de Diagnóstico Médico y Laboratorio Clínico Cedylabe se encuentra ubicado en la calle Machala y Av. Tsáchilas, cuenta con un total de 8 trabajadores entre ellos médicos radiólogos y laboratoristas. Esta clínica está obligada a llevar control de historias clínicas de la mayoría de sus clientes; estos procesos son actualmente realizados de una forma manual y mecanizada, en virtud de lo cual esta institución ha decidido adoptar un sistema automatizado para mejorar sus procesos.

En esta investigación se desarrolló un sistema informático utilizando tecnologías de software libre, el cual permitió el correcto manejo y desempeño automatizado de los procesos relacionados con la gestión de historias clínicas en el centro de diagnóstico y laboratorio clínico Cedylabe, el cual permite la optimización del tiempo delegado hacia el personal de la empresa, para los procesos que involucren el manejo de historias clínicas, además genera seguridad y confiabilidad en este tipo de gestión. Para el desarrollo se minimizaron los costos de producción del sistema utilizando herramientas open Source que son compatibles al sistema actual e infraestructura que en la actualidad se utiliza en la empresa.

Todo lo investigado en este documento fue extraído de fuentes bibliográficas y lincográficas. El lugar de recopilación de datos fue la biblioteca de la PUCE SD que con su amplia colección de libros de investigación nos permitió recoger los datos necesarios para profundizar en cada tema comprendido de esta unidad. Al igual que el uso de la internet que nos facilitó información adicional para este material escrito como; artículos científicos, libros virtuales, entre otros.

A continuación se realiza una descripción sintética del contenido de este documento.

1. Introducción.- se realiza un preámbulo del tema en general emprendido por el trabajo de titulación.

2. Planteamiento del Problema.- está compuesta por 4 partes; los antecedentes del problema el cual presenta la temática a ser investigada y utilizada para ubicar el problema específico. El problema de investigación donde se definen las preguntas directrices para la guía del trabajo. La justificación en la cual se argumenta la necesidad de dar solución al problema, y se relaciona la investigación con los objetivos del Plan Nacional del Buen Vivir.

2

Por último se plantean los objetivos los cuales responden al propósito del trabajo.

3. El marco referencial.- es la sección donde se determinan y se plantean las ideas y teorías existen con relación al tema de investigación mediante la consulta realizada a fuentes de información bibliográficas, artículos científicos y revistas. La información en este apartado clasifica el contenido con relación a la variable independiente y a la variable dependiente respectivamente.

4. La metodología de investigación.- en esta parte se justifica la utilización del enfoque mixto y la investigación aplicada como parte del enfoque y el tipo de investigación empleada respectivamente. Además se define la población y la muestra de la cual se recogen los datos. También se describen y justifican las técnicas y los instrumentos para la recogida de datos los cuales son la entrevista y la encuesta. Por último se resume como serán analizados los datos para ser convertidos en soluciones al problema.

5. Resultados.- se presenta información sobre los resultados del trabajo en base a los objetivos planteados. Se muestra el resultado del análisis situacional del problema mediante la aplicación de los instrumentos de recogida de datos empleados. También se muestra la propuesta de intervención la cual consiste en demostrar el uso de una metodología para el desarrollo del producto de software para la intervención. Se realiza una evaluación del impacto logrado gracias al desarrollo del proyecto. Al finalizar se redactan las conclusiones y recomendaciones relacionadas con los objetivos del trabajo.

2. PLANTEAMIENTO DEL PROBLEMA 2.1. Antecedentes El laboratorio clínico Cedylabe fue consolidado como empresa el 18 de junio de 2011, se encuentra ubicado en la calle Machala y Ave. Tsáchila y tiene como misión prestar servicios de apoyo realizando exámenes de ecografía, rayos x, radiología intervencionista, laboratorio para el diagnóstico, pronóstico y monitoreo del tratamiento clínico, ofreciendo a sus usuarios un servicio diferencial en términos de seguridad, atención, rapidez y de calidad de resultados, empleando tecnología de punta y un personal comprometido. Su visión es ser el Centro de diagnóstico líder del país, con la más amplia diversidad de exámenes, que permita satisfacer las crecientes necesidades de las diversas especialidades médicas.

3

Por su condición el centro requiere almacenar y gestionar las historias clínicas de sus clientes, las cuales se manejan de forma manual en plantillas creadas en el procesador de texto, guardadas como documentos que dificultan la gestión de estos registros.

Los registros médicos según Martínez (2015) son uno de los documentos más importantes que existen en el proceso de diagnóstico de un paciente, es importante que el médico tenga una visión global y muy puntual de los antecedentes de su paciente para poder realizar un plan de manejo acertado (p. 370).

En la actualidad cuentan con una búsqueda ineficaz de archivos en los ficheros de la computadora, lo que produce un retraso en el tiempo de apertura y modificación de los archivos almacenados en directorios del computador. Por ende dicha forma de almacenamiento forja muy pocas alternativas para encontrar los registros, puesto que no existe la posibilidad de filtrar la información de búsqueda más allá de recurrir al nombre y el apellido del paciente, el cual es a su vez es el nombre del archivo almacenado en disco.

Otro inconveniente al que se enfrenta la empresa es el no disponer de un procedimiento automatizado o simplemente una política para crear copias de los directorios que contienen, los documentos que almacenan la información de historia clínica de los clientes. Esto conlleva a la posibilidad de pérdida de información por equivocaciones del usuario al guardar o al realizar alguna otra operación que podría comprometer la consistencia del sistema en el cual se trabaja ya que estos errores se encuentran a menudo en el acto de realizar las operaciones de manera manual.

Además la inexistente validación de los datos ingresados por el usuario encargado de la operación, puede generar datos erróneos e inconsistentes, lo que podría generar más de un inconveniente a la hora de ser utilizado posteriormente por el usuario u otra persona ajena al registro.

Asimismo no existe un sistema o una forma de poder realizar comparaciones históricas en los datos de las historias clínicas de manera eficiente, lo cual trae como inconveniente la ilegibilidad, confusión y el retraso a la hora de comparar la información almacenada a través del tiempo, esto quiere decir que en el momento de realizar una búsqueda sobre las historias clínicas de un paciente es muy demoroso por este mismo motivo, la falta de automatizar la información.

4

Es así que el ineficiente desempeño para el manejo de información de las historias clínicas en el laboratorio Cedylabe es producido por el proceso mecanizado que lleva la empresa. Llevar la información en ficheros, en la actualidad se encuentra obsoleto, las mejoras en el ámbito informático y la sistematización hace que los servicios sean más eficientes.

A nivel mundial se han desarrollados soluciones similares a las que busca este proyecto. Una de ellas es la Integración de un programa informático de prescripción de nutrición artificial hospitalaria con la historia clínica electrónica desarrollada en España. Esta aplicación permite la prescripción de nutrición parenteral mediante plantillas prediseñadas y se integra con las historias clínicas utilizadas por el hospital (Alfaro, López, Hernández & Gonzalvo, Botella, 2013) En Cuba se realizó un sistema de gestión de información de historia clínica electrónica que permite la interoperabilidad de información de las historias clínicas con los resultados de tratamientos de terapias alternativas (Beltrán et al., 2016).

A nivel nacional también existen proyectos relacionados con el manejo de historias clínicas electrónicas. Uno de ellos es denominado “Diseño e implementación de una aplicación web basada en la metodología MDA para la administración del historial clínico y farmacéutico de la clínica Ambato”. Éste trabajo tiene como objetivo poner la información médica a disposición de los clientes para mejorar el servicio de atención hacia estos (Espín, 2015).

En la ciudad de Ibarra se implementó un sistema informático basado en la historia clínica única para la aplicación y evaluación de consultorios privados. Mediante este trabajo se optimizo la eficiencia y la calidad asistencial en el servicio de salud para varios consultorios privados de la región (Vaca, 2015).

A nivel local se ha implementado un sistema informático denominado SiSalud, el cual tiene como finalidad automatizar la gestión tanto asistencial como administrativa, en los establecimientos del Ministerio de Salud Pública. El sistema permite manejar módulos donde se registra y consulta toda la información de los pacientes, la cual es accesible a escala nacional en todos los niveles de atención de los establecimientos (Redacción Sociedad, 2015).

5

2.2. Problema de Investigación Dada la anterior problemática la pregunta que definirá el problema de investigación será: ¿Se puede mejorar el desempeño en la gestión de las historias clínicas en el laboratorio clínico Cedylabe a través de la implementación de un sistema informático?

Con esta interrogante planteada se abre el camino a las siguientes preguntas directrices que guiarán la investigación de manera más específica. ¿Cuáles son las actividades y procesos que se realiza en el departamento de imágenes médicas con respecto al manejo de historias clínicas? ¿Cuáles son las metodologías y herramientas de desarrollo de software que se aplican en la actualidad y se ajustan a las necesidades del proyecto? ¿Cuál es la arquitectura a utilizar para el desarrollo del sistema informático?

2.3. Justificación de la Investigación Mediante esta investigación se pretende solucionar los retrasos en la búsqueda de algún dato, pérdida de información, almacenamiento de datos errados, entre otros. Cedylabe no cuenta con algún tipo de sistema para la buena gestión de esta información, por lo cual se pretende implementar un sistema siguiendo las buenas prácticas para la realización de software de calidad. Hoy en día la gran mayoría de los centros médicos manejan los datos de sus pacientes utilizando las tecnologías de la información, muchos de ellos cuentan con aplicaciones realizadas a la medida que se adaptan perfectamente a las características y la lógica de negocio de la institución.

Para el proceso de registro, con respecto a la información de los pacientes que se realizan estudios médicos, los encargados de realizar estos procesos cuentan con una plantilla elaborada en Microsoft Word. Ellos deben reemplazar la información que se encuentra en cada parte de la plantilla, para así crear una nueva historia clínica o bien actualizar los datos de una plantilla existente, generando mucha documentación y posiblemente a futuro perdida de la misma.

6

El proyecto tiene como alcance la utilización de un sistema informático para la gestión de historias clínicas por parte de los trabajadores de Cedylabe, para mejorar el actual sistema manual que maneja las historias clínicas dentro de la institución y mejorar los tiempos y la precisión que se requiere para la creación, consulta, o actualización de estos registros médicos. Para su desarrollo e implementación se contará con un periodo de aproximadamente 6 meses y durará al menos 5 años sin necesidad de crear grandes cambios.

Dada la naturaleza del proyecto se considera que es factible su realización, a consecuencia de que el centro de diagnóstico cuenta con los recursos tanto tecnológicos como humanos, para asistir al cumplimiento de las finalidades de este proyecto, así como con el tiempo previsto y los resultados esperados en relación al alcance anteriormente planteado.

Por último el número de beneficiarios directos por el proyecto es de 4 personas, mientras que el grupo de beneficiarios indirectos está compuesto por todos los trabajadores y clientes de la institución puesto que la institución en general se evitará problemas relacionados con la seguridad, pérdida de información, optimización del tiempo y los recursos humanos que se emplean para el trabajo con estos documentos. Por otra parte de manera indirecta los clientes serán beneficiados puesto que la atención será más rápida. Estas ventajas hacen que el proyecto sea relevante y de gran interés para el administrador y el personal de la institución.

La investigación se alinea con el objetivo 11 del Plan Nacional del Buen Vivir el cual indica: “Asegurar la soberanía y eficiencia de los sectores estratégicos para la transformación industrial y tecnológica”. Además en el objetivo 11 del plan del buen vivir se expresa lo siguiente “....convertir la gestión de los sectores estratégicos en la punta de lanza de la transformación tecnológica e industrial del país, constituye un elemento central de ruptura con el pasado” (SENPLADES, 2017, p. 313). Este objetivo incita al desarrollo de Tecnologías de la Información y de la Comunicación, en las diferentes entidades públicas y privadas para alcanzar la calidad y seguridad de la Información, garantizando la gestión eficiente de los procesos informáticos.

7

2.4. Objetivos de Investigación 2.4.1. Objetivo General.

Implementar un sistema informático para la gestión de las historias clínicas en los estudios de imagen médicas del laboratorio clínico Cedylabe en el período 2016-2017.

2.4.2. Objetivos Específicos.  Determinar los procesos que se realizan en el departamento de imágenes médicas con relación al manejo de historias clínicas.  Definir la metodología de desarrollo de software que mejor se ajuste a este proyecto.  Establecer la arquitectura a utilizar en el desarrollo del sistema informático.  Desarrollar el producto de software siguiendo los parámetros anteriormente establecidos.

8

3. MARCO REFERENCIAL 3.1. Esquema de Contenidos

Ingeniería de SW

UML

Arquitectura se Software Software Patrones de diseño

Factory Method

Javascript

DESARROLLO DE APLICACIÓN INFORMÁTICA

Lenguajes de programación Python

Base de datos

Relacionales

Postgress

Scrum Metodologias de desarrollo

Metodologías agiles Programación Extrema Django Nginx Servidor Gunicorn Sublime text

Python-docx

Herramientas para el desarrollo de implementación

Datatables

Alertify.js

Chart.js

Github

Bootstrap

Figura 1. Esquema de contenidos – variable independiente. Fuente: Datos obtenidos de la investigación de campo

MANEJO DE LAS HISTORIAS CLÍNICAS

9

Historias clínicas

HCE(EMR)

Figura 2. Esquema de contenidos - variable dependiente. Fuente: Datos obtenidos de la investigación de campo

3.2. Revisión de la Literatura o Fundamentos Teóricos 3.2.1. Software.

Muchos estudiados del tema tienen sus propias definiciones acerca de lo que significa software pero todos tienen relación “Es un término general que se aplica a las diversas clases de programas (conjuntos de instrucciones) que dirigen a una computadora y a sus dispositivos relacionados para llevar a cabo una tarea específica; eventualmente, esta definición se puede ampliar para incluir a la documentación relativa al funcionamiento y uso de tales programas” (Toledo, Vega y Molina, 2007).

3.2.1.1. Software libre.

Internet nació en base al desarrollo compartido y distribuido y, quizá lo más sorprendente, fue gestionado por la propia comunidad internauta, según Córdova (2008) el software libre representa el 70% de los servidores web del mundo utilizando sistemas operativos Linux en la mayoría de los casos, el 90% de los servidores DNS3 y además constituye un amplio sector de los servicios de red.

Gracias al software libre se puede fomentar la filosofía de compartir conocimientos y reutilizar los buenos desarrollos de terceros lo cual es clave para el desarrollo ágil y eficiente de la tecnología y de la industria en un sentido amplio (Córdova, 2008)

10

3.2.1.2. Ingeniería de software.

Ingeniería de software es la disciplina formada por un el conjunto de métodos, herramientas y técnicas que se utilizan en el desarrollo de los programas informáticos. Esta disciplina engloba a la actividad de programación, que es el pilar fundamental a la hora de crear una aplicación. El ingeniero de software es la persona encargada de la gestión del proyecto para que éste se pueda desarrollar en un plazo determinado y con el presupuesto previsto (Gardey, 2012).

Principalmente la ingeniería de software, tiene como alcance el análisis previo de la situación, el diseño del proyecto, el desarrollo del software, las pruebas necesarias para confirmar su correcto funcionamiento y la implementación del sistema.

3.2.1.3. Lenguaje unificado de modelado UML. El UML (Lenguaje Unificado de Modelado) se ha definido como un lenguaje gráfico para visualizar, especificar, construir y documentar los elementos de un sistema con gran cantidad de software según Fernández (2014) la evolución natural del UML ha llevado al desarrollo de nuevas metodologías de desarrollo de software.

Una de las aplicaciones de UML más importantes son los diagramas de clase. Estos son un tipo particular de diagramas donde se muestra la estructura del sistema en términos de clases, interfaces, colaboraciones y relaciones, el diagrama de clases es un grafo, donde los nodos son elementos del tipo clasificador y las líneas son las distintas relaciones estáticas que existen entre elementos. En este diagrama se especifican los elementos del sistema, que serán referenciados por el resto de los diagramas, lo cual lo convierte en el diagrama central de un modelo (Fernández, 2014).

En las clases se define la estructura de atributos y métodos de los objetos que la instancian. La relación más básica entre clases es asociación, representada por una línea. El caso más común es una asociación binaria, pero se permite la modulación de relaciones entre N clases (Fernández, 2014).

La relación de herencia (Especialización/Generalización) [

] indica que una

subclase hereda los métodos y atributos detallados por una SuperClase, por lo tanto la Subclase tiene sus propios métodos y atributos, además de poseer las características que les

11

son heredado de la Superclase (Fernández, 2014).

3.2.1.4. Arquitectura MVC. Arquitectura en tres capas. Es aquella donde la estructura del programa es fraccionada desde el punto de vista lógico en Presentación, Lógica de Negocio y Datos.

La Capa de Presentación es la que muestra gráficamente el sistema al usuario, le comunica la información y captura la información del usuario, se comunica únicamente con la capa de negocio (Paderni, Aguilar, Cabrera y Delgado, 2014).

La Capa de Negocio es donde se almacenan la lógica de operación y se establecen todas las reglas que deben cumplirse. Esta capa se comunica con la capa de presentación, para recibir las solicitudes y presentar los resultados, también se conecta con la capa de datos, para realizar operaciones con el gestor de base de datos como almacenar o recuperar datos de este (Paderni et al., 2014).

La Capa de Datos es donde se abstraen y se almacenan los mismos, está formada por uno o más gestores de bases de datos que realizan todo el almacenamiento de datos, reciben solicitudes de almacenamiento o recuperación de información desde la capa de negocio (Paderni et al., 2014).

3.2.1.5. Patrones de diseño.

El diseño orientado a objetos es difícil y el diseño de software orientado a objetos reutilizable lo es aún más. Los diseñadores expertos no resuelven los problemas desde un principio si no que reutilizan soluciones que han funcionado en el pasado (Gamma, Helm, Johnson & Vlissides, 1995).

Para normalizar estas soluciones existen los patrones de clases y objetos de comunicación los cuales son bastante recurrentes en muchos sistemas orientados a objetos.

Estos patrones resuelven problemas de diseño específicos y hacen el diseño flexible y reusable.

Cada patrón describe un problema que ocurre una y otra vez en nuestro entorno y describe también el centro de la solución que se busca, de manera que se puede utilizar muchísimas veces sin tener que hacer dos veces lo mismo (Gamma et al., 1995).

12

Además un patrón de diseño es una descripción de las clases y los objetos que se comunican entre sí adaptándose para resolver un problema de diseño general en un contexto particular.

Ventajas:  Permite capturar la experiencia actual  Busca ayudar a la comunidad de desarrolladores de software a resolver problemas comunes, creando un cuerpo literario de base.  Crea un lenguaje común para comunicar ideas y experiencia acerca de los problemas y sus soluciones.  El uso de patrones ayuda a obtener un software de calidad (reutilización y extensibilidad).

Figura 3. Clasificación de los patrones. Adaptado de “Design Patterns” por E. Gamma, R. Helm, R. Johnson, y J. Vlissides, 1995. Indianapolis, Addison Wesley.

3.2.1.5.1. Patron factory method.

A veces, un objeto de aplicación sólo puede saber a qué es lo que necesita acceder dentro de una clase que tiene jerarquía, pero no sabe exactamente a cuál clase entre el conjunto de subclases de la clase padre se debe escoger. El programador puede elegir manualmente pero esta elección podría no ser la más adecuada (Sellarès, s.f.).

El patrón Factory Method define una interfaz para crear un objeto, pero permite a las subclases decidir cuál clase instanciar. Este patrón permite diferir la instanciación de una

13

clase hacia las subclases (Sellarès, s.f.).

El patrón Factory recomienda encapsular la funcionalidad requerida para seleccionar e instanciar una clase apropiada dentro de un método designado llamado el Método Fabrica (Factory Method). El principio de diseño utilizado aquí consiste en encapsular lo que varía.

Se encapsula la creación de objetos (Sellarès, s.f.).

Este patrón permite la escritura de los métodos que pueden instanciar objetos diferentes y también puede heredar para instanciar nuevos objetos desarrollados, todo esto sin tener que modificar el método con el propósito final (Sellarès, s.f.).

Ventajas:  Centralización de la creación de objetos  Facilita la escalabilidad del sistema  El usuario se abstrae de la instancia a crear.

3.2.1.6. Lenguajes de programación.

Un lenguaje de programación es un lenguaje diseñado para describir los pasos necesarios que debe realizar un equipo (Ccm, 2015). Un lenguaje de programación es una solución efectuada para hacer que los equipos informáticos actúen como su programador lo requiere.

Un lenguaje de programación no es ambiguo por lo que solo tiene una forma de ser interpretado. Cada línea de código representa una o varias acciones que serán desempeñadas por el hardware del computador. El lenguaje utilizado por el procesador a nivel lógico se denomina lenguaje máquina y solo se expresa con 0 y 1 (Ccm, 2015).

El lenguaje máquina, es muy complejo de escribir y entender para los seres humanos, razón por la cual se han desarrollado lenguajes intermediarios con un mayor nivel de abstracción para el hombre. El código escrito en estos lenguajes es transformado en código máquina para luego ser procesado por el CPU (Ccm, 2015).

Un lenguaje de programación tiene como ventaja que es fácil de comprender. A medida que el lenguaje de programación tiene un nivel mayor de abstracción es más difícil

14

para el computador procesarlo, pero es más legible y más fácil de programarlo. Estas características de lenguaje de alto nivel son las encontradas en Python el lenguaje que ha sido escogido para programar el servidor en este proyecto, teniendo en cuenta la necesidad de desarrollar el software en el menor tiempo posible, puesto que es una característica del lenguaje ser utilizado para rápido desarrollo, tener una baja curva de aprendizaje y además ser un lenguaje de programación dominado por los programadores del actual trabajo.

3.2.1.6.1. Python.

Python es un lenguaje de programación poderoso y fácil de aprender. Cuenta con estructuras de datos eficientes y de alto nivel y un enfoque simple pero efectivo a la programación orientada a objetos. La elegante sintaxis de Python y su tipado dinámico, junto con su naturaleza interpretada, hacen de éste un lenguaje ideal para scripting y desarrollo rápido de aplicaciones en diversas áreas y sobre la mayoría de las plataformas (The Python Software Foundation, 2017).

El intérprete de Python y la extensa biblioteca estándar están a libre disposición en forma binaria y de código fuente para las principales plataformas desde el sitio web de Python y puede distribuirse libremente. Este sitio además contiene distribuciones y enlaces de muchos módulos y librerías libres de Python de terceros, programas y herramientas, y documentación adicional (The Python Software Foundation, 2017).

El intérprete de Python puede extenderse fácilmente con nuevas funcionalidades y tipos de datos implementados en C o C++ (u otros lenguajes accesibles desde C). Python también puede usarse como un lenguaje de extensiones para aplicaciones personalizables (The Python Software Foundation, 2017).

3.2.1.6.2. Javascript.

JavaScript es un lenguaje ligero e interpretado, orientado a objetos con funciones de primera clase, más conocido como el lenguaje de script para páginas web, pero también es usado en varios entornos sin navegador. Es un lenguaje script multi-paradigma, basado en prototipos, dinámico, soporta estilos de programación funcional, orientada a objetos e imperativa (Mozilla Developer Network, 2017).

JavaScript es un lenguaje interpretado línea a línea por el navegador, mientras se carga la página, que solamente es capaz de realizar las acciones programadas en el entorno de

15

esa página HTML donde reside. Sólo es posible utilizarlo con otro programa que sea capaz de interpretarlo, como los navegadores web (Desarrolloweb, s.f.).

En este sistema Javascript será utilizado para crear pequeños programas para mejorar la presentación dinámica que poseerá la web, también puede ser usado en programas más grandes, orientados a objetos mucho más complejos. Con las librerías Javascript disponibles en la red podemos crear diferentes efectos e interactuar con nuestros usuarios de manera más intuitiva (Desarrolloweb, s.f.).

3.2.2. Base de Datos.

Las bases de datos según Rubinos y Nuevo (2011) “son una serie de datos organizados y relacionados entre sí, los cuales son recolectados y explotados por los sistemas de información de una empresa o negocio en particular” (p.84).

En cada base de datos se especifican las tablas. Las tablas están formadas por filas y por columnas. Las columnas guardan información o valores específicos para todos los elementos de la tabla, cada fila de la tabla conforma un registro. Los sistemas de base de datos son de gran uso, el cual va desde el uso de bases de datos ligeras, bases de datos en tiempo real en algunas ocasiones obtenido a partir de la optimización de bases de datos relacionales y bases de datos relacionales con potentes aplicaciones gestoras que proveen el servicio (Rubinos y Nuevo, 2011).

3.2.2.1. Base de datos relacionales.

Las bases de datos relacionales son el tipo de base de datos que procura representar los datos en forma de tablas y relaciones, es uno de los modelos más utilizados y populares, creado por Edgar Frank Codd a finales de los años 60. Según Méndez y Aponte (2016) las bases de datos relacionales consisten en un conjunto de tablas, a las cuales se les asigna un nombre exclusivo que representa típicamente el contenido a almacenar. Se utilizan los términos matemáticos relación y tupla en lugar de los términos tabla y fila. Una variable tupla es una variable que representa a una fila. Una relación es el vínculo que existe entre una tabla y otra (Méndez y Aponte, 2016).

Teniendo en cuenta que no hay asignado ningún presupuesto para el desarrollo, este proyecto necesita de una base de datos libre (sin costo) y que tenga un buen estado de

16

madurez y robustez. Las tecnologías más usadas que satisfacen los requerimientos anteriormente mencionado son MySQL y PostgreSQL. Dado que el presente proyecto no requiere de características especiales y avanzadas de una base de datos, ambas funcionarán perfectamente sin ningún inconveniente. Se decidió escoger PostgreSQL pues es el gestor que mayor soporte tiene para las funcionalidades del framework web Django en caso de que se requiera de una futura funcionalidad avanzada. Además es también el gestor que mayor madurez tiene. La última razón por la cual fue escogido esta tecnología fue porque el centro donde se implementará el sistema lo utiliza y se le hará más fácil la administración de este gestor en particular.

3.2.2.1.1. Postgresql.

PostgreSQL es un sistema de gestión de bases de datos objeto-relacional, distribuido bajo licencia BSD y con su código fuente libre. Es el sistema de gestión de bases de datos de código abierto más potente del mercado en cuanto a funcionalidades (Zea, Molina y Redrován, 2017).

PostgreSql es probablemente el más avanzado SGBD de código abierto en el mundo, ya que soporta la gran mayoría de las transacciones SQL, control concurrente, ofrece modernas características como consultas complejas, disparadores, vistas, integridad transaccional y permite agregar extensiones de tipo de datos, funciones, operadores y lenguajes procedurales. (Vázquez, Mesa y Castillo, 2011; The PostgreSQL Global Development Group, 2011).

"PostgreSQL utiliza un modelo cliente/servidor para la distribución y usa multiprocesos en vez de multihílos para garantizar la estabilidad del sistema. Un fallo en uno de los procesos no afectará el resto y el sistema continuará funcionando (Zea et al., 2017).

Según el sitio oficial de PostgreSQL las características que definen a esta base de datos se detallan a continuación:  Es una base de datos 100% ACID  Integridad referencial  Tablespaces  Nested transactions (savepoints)

17

 Replicación asincrónica/slncrónica / Streaming replication - Hot Standby  Two-phase commit  PITR - point in time recovery  Copias de seguridad en caliente (Online/hot backups)  Unicode  Juegos de caracteres internacionales  Regionalización por columna  Multi-Version Concurrency Control (MVCC)  Múltiples métodos de autentificación  Acceso encriptado vía SSL  Actualización in-situ integrada (pg_upgrade)  SE-postgres  Completa documentación  Licencia BSD Disponible para Linux y UNIX en todas sus variantes (AIX, BSD, HP-UX, SGI IRIX, Mac OS X, Solaris, Tru64) y Windows 32/64bit (Postgresql, s.f.).

Otro punto a detallar es que Postgresql es un sistema de base de datos de tipo relacional es un sistema lo que permite la manipulación de acuerdo con las reglas del álgebra relacional. Los datos se almacenan en tablas de columnas y renglones. Con el uso de llaves, esas tablas se pueden relacionar unas con otras (Zea et al., 2017).

18

3.2.3. Herramientas Para el Desarrollo e Implementación.

3.2.3.1. Django.

Django es un framework web Python de alto nivel que fomenta el desarrollo rápido y el diseño limpio y pragmático. Desarrollado por desarrolladores experimentados, se encarga de gran parte de las complicaciones del desarrollo web, atacando a los problemas recurrentes en esta, por lo que el desarrollador puede concentrarse en escribir la aplicación sin necesidad de reinventar la rueda. Es gratis y de código abierto (Django Software Foundation, 2017).

Debido a que Django se desarrolló en un entorno acelerado, fue diseñado para hacer que las tareas comunes de desarrollo web sean rápidas y fáciles. Django fue diseñado para ayudar a los desarrolladores a llevar las aplicaciones desde su concepción hasta su finalización lo más rápido posible por lo cual es muy adecuado para el prototipado (Django Software Foundation, 2017).

Django incluye docenas de funciones extras que se pueden usar para manejar tareas comunes de desarrollo web. Django se encarga de la autenticación de usuarios, la administración de contenidos, los mapas del sitio, los canales RSS y muchas más tareas desde el primer momento (Django Software Foundation, 2017).

Django toma en serio la seguridad y ayuda a los desarrolladores a evitar muchos de los errores comunes de seguridad, como la inyección de SQL, cross-site scripting (XSS), cross-site request forgery (CSRF) y el Clickjacking. Su sistema de autenticación de usuarios proporciona una forma segura de administrar cuentas de usuario y contraseñas (Django Software Foundation, 2017).

Django es el framework web escogido sobre el cual serán realizadas las funcionalidades fundamentales del sistema informático. Las razones principales para esta elección incluye: programación pragmática, rápido desarrollo, plana curva de aprendizaje, seguridad incrustada y amplia disponibilidad de módulos que cubren la mayor parte de las necesidades en el desarrollo web. Estas cualidades influirán directamente en el tiempo de desarrollo y la calidad necesaria para el producto final.

19

3.2.3.2. Servidor.

Un servidor es un programa o un equipo encargado de servir o dar respuestas a las solicitudes generadas por el cliente. Para el despliegue y el alojamiento del presente sistema se utilizará un servidor HTTP el cual será el delegado para responder a las peticiones de las computadoras finales desde las cuales se accederá y manejará la aplicación. Además se utilizará otro servidor web para servir las peticiones de archivos estáticos y servirá para en un futuro poder acceder a las peticiones que lleguen por el puerto 80 proveniente de internet.

Los servidores más utilizados para ejecutar estas acciones programadas en el lenguaje de programación Python son Nginx y Gunicorn. A pesar de que Apache Http es el líder mundial Nginx ofrece la misma funcionalidad con una configuración más simple e incluso puede alcanzar mejor rendimiento y eficiencia cuando se utiliza con lenguajes como Python ya que está diseñado especialmente para este (Reese, 2008).

3.2.3.2.1. Nginx.

Nginx es un servidor HTTP y de reverse proxy gratis y open-source, con alto rendimiento como también es servidor de proxies IMAP/POP3. Nginx es conocido por su alto rendimiento, estabilidad, conjunto rico de características, configuración simple y bajo consumo de recursos de hardware (Nginx, s.f.).

A diferencia de los servidores tradicionales, NGINX no se basa en la utilización de hilos para manejar las solicitudes. En su lugar, utiliza una arquitectura asincrónica basada en eventos mucho más escalable que la división en sub-procesos. Esta arquitectura utiliza cantidades pequeñas, pero más significativas y predecibles de memoria bajo carga. También permite beneficiarse de un alto rendimiento si no se espera manejar miles de solicitudes simultáneas, además de disfrutar de la pequeña huella de memoria de Nginx. Este servidor también escala en todas las direcciones: desde el más pequeño VPS hasta grandes grupos de servidores utilizando balanceador de carga (Nginx, s.f.).

3.2.3.2.2. Gunicorn.

Gunicorn, es un servidor WSGI HTTP para Python. Es un pre-fork del proyecto Unicorn de Ruby. Gunicorn es el servidor WSGI más común para proyectos que utilizan frameworks Python, consume pocos recursos en ejecución y es bastante rápido (Gunicorn, s.f.).

20

Gunicorn nos permite administrar muchas peticiones simultáneas que lleguen a nuestro sistema dependiendo de los recursos que tenga disponible. De esta forma sirve el contenido dinámico para las aplicaciones que tenga instaladas. El número de peticiones simultáneas que este servidor puede procesar se define mediante el atributo workers. Los workers se calculan con la formula “(números de CPU * 2) + 1” (Gunicorn, s.f.).

3.2.3.3. Herramientas para el desarrollo.

3.2.3.3.1. Sublime text.

Sublime Text es editor de texto para código, en la actualidad es muy usado por las funcionalidades que presta al momento de escribir código. Es una herramienta gratuita disponible para OS X, Windows y Linux, además de contar con plugins facilitadores a la hora de redactar código evitando la escritura continua del mismo código, esto hace de sublime text una herramienta muy completa.

3.2.3.3.2. Python-docx.

Python-docx es una librería python para crear y actualizar documentos de Microsoft Word (.docx). Esta librería se encuentra alojada en PyPI, por lo que su instalación es relativamente sencilla a través del administrador de paquetes pip. Actualmente se encuentra en la versión 0.8.6 lo que significa que aún no ha alcanzado un estado de madurez ideal, pero debido a la escasez de librerías multiplataforma para este propósito, se ha decidido utilizar esta alternativa para la manipulación de archivos de Word en el sistema (Readthedocs).

3.2.3.3.3. Chart.js.

Chart.js es una librería Javascript que permite a los diseñadores y desarrolladores dibujar todo tipo de gráficos utilizando los elementos canvas de HTML5. Chart.js ofrece una gran variedad de gráficos simples y limpios que incluyen versiones animadas e interactivas.

Es una manera fácil de incluir gráficos hermosos y atractivos en su sitio web de forma gratuita (sourceforge).

3.2.3.3.4. Data tables.

DataTables es un plug-in para la librería Jquery de Javascript. Es una herramienta altamente flexible, basada en los fundamentos de la mejora progresiva, y que añadirá controles avanzados de interacción con el usuario hacia cualquier tabla HTML. (datatables).

21

Sus funcionalidades más importantes para este proyecto incluyen:  La organización de menor a mayor y de mayor a menor de cada uno de los campos en los registros de la tabla.  La búsqueda o filtrado dinámico de información en todos los campos.  La paginación de los registros de acuerdo a la preferencia del usuario.

3.2.3.3.5. Alertify.js.

Alertify.js es una librería Javascript para desarrollar atractivos diálogos de buscadores y notificaciones. Esta librería permite emplear Jquery y Bootstrap para crear elementos visuales prediseñados y fáciles de configurar para el programador, obteniendo consigo unas notificaciones muy bonitas utilizando las tendencias de diseño más actuales (alertifyjs).

3.2.3.3.6. Bootstrap.

Boostrap es la mejor herramienta encontrada para realizar un diseño amigable a la vista del usuario fina. Boostrap es muy fácil de utilizar y gracias a sus librerías es compatible con los lenguajes de programación además del mejor constructor de diseño web.

3.2.3.3.7. Git. Git, es un software de control de versiones diseñado por Linus Torvalds. Se define como control de versiones a la gestión de los diversos cambios que se realizan sobre los elementos de algún producto o una configuración del mismo, en otras palabras, la gestión de los varios cambios realizados sobre los elementos de algún producto o configuración (gitscm, s.f.).

Git está pensado en la eficiencia y la confiabilidad del mantenimiento de versiones de aplicaciones cuando éstas tienen un gran número de archivos de código fuente. Git proporciona las herramientas para desarrollar un trabajo en equipo de manera inteligente, esto suministra a su vez una correcta técnica en el manejo de código fuente y de configuración (git-scm, s.f.).

Git será utilizado para controlar los archivos y las versiones de código del programa, permitirá el trabajo simultáneo y la colaboración en equipo desde locaciones y terminales remotos.

22

3.2.4. Metodologías de Desarrollo de Software.

3.2.4.1. Metodologías tradicionales.

Las buenas prácticas para desarrollo de software con el pasar del tiempo fueron mejorando, tanto así que se crearon las metodologías.

Estas metodologías tradicionales comprenden un orden estricto y a su vez un gran peso por parte de la documentación, esto quiere decir que dichas metodologías se preocupan por los procesos que se van desarrollando a la hora de crear software de calidad, sin embargo cuentan con ciclos limitados y no son muy buenos a la hora de algún cambio propuesto o cualquier mejora al programa que se genere en el momento del desarrollo, estas metodologías tienen resistencia a cambios por motivos de la documentación y el estricto orden en los procesos.

En síntesis las metodologías tradicionales son aceptadas para proyectos grandes y de larga duración en tiempo, poniendo énfasis en la documentación y así obligando a que el cliente desde el principio debe dar a conocer lo que necesita, para que el desarrollador proponga la solución y el gerente o encargado adoptar una idea de la posible medida que se le propone, esto por dos motivos, uno es que el cliente no participa en todas las etapas del proyecto, las únicas veces se muestra en reuniones ya planificadas para dar un seguimiento al producto, y otro motivo es que las metodologías tradicionales son muy complejas en documentación y difícil hacerle algún cambio requerido de último momento, ya que todo está definido desde un principio, por etapas.

3.2.4.2. Metodologías ágiles.

Godoy (2015), señala que la palabra Método Ágil es un concepto que surgió de las reuniones de diferentes críticos, para así llegar aparecer el segundo concepto que se reflejo fue el Manifiesto Ágil, el cual lo presentaron en cuatro postulados, individuos e iteraciones, software funcionando sobre documentación extensiva, colaboración del cliente y respuesta ante cambios.

Pues como su nombre lo dice, son metodologías rápidas de fácil ejecución, a diferencia de las tradicionales, en la metodología ágil no se pone mucho énfasis en la documentación, estas metodologías se crean por la necesidad de reducir el desarrollo del

23

software en términos de tiempo pero claro sin perder la calidad del software. Las metodologías agiles son importantes de seguir para poder generar software de calidad, estas metodologías son adaptables a las peticiones del cliente, es decir se pueden ingresar cambios en cualquier circunstancia del proyecto, el mejor termino de estas metodologías es el ser adaptables a cambios.

Los métodos agiles son procesos no tan controlados pero bien ejecutados, con un muy bajo tamaño en documentación y haciendo énfasis en las personas que integran el grupo de desarrollo, es por ello que el cliente es tomado como parte del equipo de trabajo, a diferencia de las tradicionales donde el cliente solo se requiere de acuerdo a lo planificado en reuniones.

Las metodologías Agiles también llamadas ligeras son diseñadas para pocos equipos de trabajos, esto hace que las actividades o roles destinados para cada miembro sean muy reducidos haciendo que el tiempo de desarrollo del software sea más rápido, es importante recalcar la flexibilidad de estas metodologías, porque gracias a esto como se mencionó el tiempo es muy corto, la documentación muy ligera, el costo es bastante apegado a la realidad del trabajo y los compromisos junto con el cliente se van sobreponiendo a medida que se va avanzando en la creación de software (pp. 37-38).

Según criterios mencionados de las metodologías Ágiles y Tradicionales, se realizará el siguiente cuadro comparativo entre las dos, esta comparación se llevará a cabo tomando en cuentas las principales características de cada una para así poder llegar a una conclusión, y elegir entonces la metodología de desarrollo.

24

3.2.4.3. Diferencias entre las Metodologías Tradicionales y las Metodologías Ágiles.

Tabla 1 Comparativa Metodología Tradicional y Ágil METODOLOGÍAS ÁGILES

METODOLOGÍAS TRADICIONALES

Desarrollo rápido gracias al cumplimiento de las

Desarrollo lento debido al estricto cumplimiento de

características del manifiesto ágil.

los procesos descritos.

El equipo de trabajo puede intercambiar roles en

El equipo de trabajo sigue una estricta serie de

cualquier momento y transferir conocimiento de

procesos sin posibilidad de saltarse hacia otros roles

manera colectiva.

y responsabilidades.

Grupos grandes y distribuidos.

Grupos pequeños y trabajando en el mismo sitio.

El cliente es parte del equipo de desarrollo.

El cliente interactúa con el equipo de desarrollo

Constantemente

pocas veces.

El contrato puede estar sujeto a cambios a lo largo del desarrollo.

El contrato es totalmente fijo e inmodificable.

Nota: Adaptado de Pressman, R. (2010). Ingeniería del software, Un enfoque práctico. México: Mc GrawHill

Según Cortizo, Expósito y Ruiz (2016) refiere que en la metodología XP el proceso de desarrollo se va realizando en forma continua, esto facilita que al final la integración de todo el trabajo sea exitoso, se realiza una codificación limpia y más simple para reducir el número de errores, esto va de la mano con lo llamado programación en parejas “pair programming”, realizando un software de calidad aplicando las buenas prácticas de programación. Un punto fundamental de esta metodología es la disipación de trabajo respecto al tiempo, trabajando 40 horas a la semana sin exceso de labor, XP es una metodología donde la comunicación de los miembros del equipo es continua haciendo que el producto final sea de calidad y cumpliendo con los requisitos establecidos por parte del encargado de la empresa o institución (pp. 1213).

La metodología XP es la correcta para este tipo de investigación, porque está dedicada a proyectos pequeños y a corto plazo, destinados a la cantidad de integrantes en el equipo, en este caso, dos personas, además XP no demanda con rigurosidad el seguimiento al pie de la letra la utilización de sus características a la hora de realizar el proyecto, es decir, los desarrolladores pueden tomar esta metodología como principios prácticos a seguir.

25

Según Navarrete (2013) XP basa el éxito de un proyecto en cuatro valores fundamentales: 1. Comunicación. Comunicación permanente entre todas las partes interesadas incluyendo al cliente, desarrolladores y a los coordinadores.

2. Simplicidad. XP exige simplicidad en el diseño, en el código, en los procesos, etc. Con la finalidad de que todos puedan comprender y mejorar el trabajo.

3. Retroalimentación. La retroalimentación es fundamental para que se puedan ajustar las funcionalidades a las necesidades reales, además esta característica permite hallar posible errores de una manera más rápida.

4. Coraje. Se refiere a la habilidad para tomar decisiones duras, lo que implica que no importa el tiempo que pueda tomar una actividad, si es necesaria se realizará.

3.2.4.4. Metodología scrum.

Scrum es parte de las familias de metodologías ágiles, es por eso que consta del conocido ágil manifiesto, pero con la característica de que no está enfocado en el desarrollo del proyecto, más bien se enfoca en la administración del proyecto, los equipos básicos de Scrum se componen de el propietario del producto, el equipo de desarrollo y un Scrum master, este equipo de trabajo es auto-organizado, es decir, no tienen un guía quien les dice que hacer, el equipo mismo en reuniones se organiza de la mejor manera y busca decisiones que lleven a la realización del proyecto.

Scrum está diseñado para crear proyectos pequeños, medianos y grandes siguiendo el mecanismo de abstracción orientado a objetos en la parte de creación y codificación, para esto Scrum en su organización dice que no se estima los lugares para desarrollar, en otras palabras Scrum no limita el entorno de trabajo, los desarrolladores pueden realizar sus actividades desde cualquier parte, para esto se menciona que al final del trabajo los desarrolladores se reúnen para integrar todo el trabajo y tomar decisiones de desarrollo y búsqueda de errores, en esta parte es muy complicado porque se deben seguir parámetros muy rígidos por parte de los desarrolladores para que al final en el momento de la integración del código no existan o se localicen la menor cantidad de errores posibles.

26

3.2.4.5. Comparativa de metodologías ágiles.

Para el siguiente cuadro comparativo, se toma en cuenta características de las metodologías agiles Xp y Scrum que se ajustan a las necesidades en esta investigación. Los valores se estimaran por parte de los integrantes donde 2 es la cantidad mayor equivalente al cumplimiento de lo especificado, 1 la cantidad intermedia donde alguna metodología hace uso de esa característica pero solo en cierta parte no por completo y 0 la cantidad menor equivalente a que no cumple con nada de los propuesto en las características Tabla 2 Comparativa Métodos Ágiles CARAC.

XP

VALOR

SCRUM

VALOR

Ágil manifiesto

Si

2

Si

2

Enfoque a lo largo del desarrollo del proyecto.

Basada en la programación y creación del producto.

2

Basada en la administración del proyecto

0

Tamaño de los proyectos (pequeño)

Pequeños y medianos proyectos

2

Pequeños, medianos y grandes

2

Mecanismos de abstracción

Orientado a Objetos

2

Orientado a Objetos

2

Entorno físico

En un solo sitio con equipos centralizado.

1

Integración del código.

Se trabaja siempre con la última versión del código.

2

Total

Se planifica y da libertad de poder desarrollar desde cualquier parte.

El código es desarrollado individualmente e integrado al final del sprint.

11/12 90%

2

0 8/12 70%

Nota: CARAC = características. Fuente: Datos obtenidos de la investigación de campo

De las características mencionadas en las metodologías ágiles que tienen relación con el proyecto, se concluye que la mejor decisión a la hora de llegar al propósito de esta investigación es la metodología ágil XP, porque es la que mejor cumple las necesidades requeridas para este proyecto, las cuales en su mayoría están relacionadas al factor tiempo debido a que por el corto plazo disponible para entregar el producto, es este el elemento principal para decidir. Como esta metodología no encaja completa y perfectamente con las condiciones reales del equipo de trabajo, se ha optado por usar sus principios fundamentales y no seguir la metodología estrictamente.

27

3.2.5. Manejo de Historias Clínicas.

3.2.5.1. Historia clínica.

Según Martínez (2015) “La historia clínica es uno de los documentos más importantes que existen en el proceso de diagnóstico de un paciente” (p. 365), es importante que el médico tenga una perspectiva general en cuanto a los antecedentes de su paciente se trata. De esta manera podrá realizar un plan de manejo acertado. Todos los médicos saben las dificultades que poseen las historias clínicas tradicionales escritas a papel o en procesadores digitales, los pacientes son las más grandes víctimas de estas conocidas deficiencias. En el caso del médico no logra el mejor tratamiento porque faltan datos o antecedentes y el paciente sufre porque su salud no mejora con la prontitud deseada, todas estas dificultades pueden sino eliminarse, al menos disminuirse en un alto grado con una historia clínica electrónica (Martínez, 2015).

La historia clínica tradicional tiene una serie de inconvenientes, que se han venido acentuando, dadas las grandes cantidades de usuarios que los hospitales o clínicas tienen.

Según Martínez (2015) “entre los inconvenientes tenemos, la ilegibilidad” (p. 370), ya que su contenido suele ser desordenado y des formateado, además la imposibilidad para acceder a ellas de manera inmediata; dependiendo de la entidad, la velocidad de acceso puede variar de entre unos minutos a horas y lo más importante, las inconsistencias. Cada entidad tiene la historia clínica de cada paciente, no siempre conforman la misma información en ambas partes, tampoco hay cruce de datos entre ellas, funcionan como islas y esto ayuda a que exámenes sean repetidos en varias ocasiones con el respectivo derroche de recursos. A lo anterior podemos adicionar los tiempos de la búsqueda y la consulta, y la seguridad de la información ante eventos de robos o pérdida de los archivos por eventos fortuitos, debido a factores climatológicos, incendios, errores humanos, etc (Martínez, 2015).

Acceder a tiempo a la historia clínica para la atención rápida a un paciente, en algunos casos, puede ser la diferencia entre la vida y la muerte puesto que estas suelen contener información como las alergias que padece el individuo. Una de las variables del sistema de atención, es la información que contiene tal historia en ella están albergadas no solamente sus patologías, sino los medicamentos que está ingiriendo, las dosis del mismo, las alergias y los profesionales que lo están atendiendo. En una emergencia médica esta información puede llegar a ser vital, el poder acceder al historial médico de un paciente de manera ágil puede

28

hacer la diferencia (Martínez, 2015).

Como ventaja los inconvenientes de las historias clínicas tradicionales se rectifican gracias a la modalidad electrónica. Una de las ventajas es la durabilidad de la información; en el formato electrónico de datos, es común aplicar políticas para realizar copias o backups, salvaguardando los datos. Con una típica conexión a internet se tiene la posibilidad de acceder desde cualquier sitio y ver la información del paciente e incluso consultarla de manera simultánea desde varios sitios. La información es centralizada y se eliminarían varios documentos en distintas entidades para un mismo paciente. El otro aspecto que se subsana es la integridad de la información ya que cada transacción queda plenamente identificada y puede ser utilizado como un documento legal. Igualmente se mejora la legibilidad del documento por ser elaborado digitalmente con formatos de presentación definidos. (Martínez, 2015).

En el marco legal de los profesionales de la salud, la Historia Clínica es el documento en donde se refleja las pasadas prácticas médicas así como también el cumplimiento de los deberes del personal en salud respecto al paciente. Esta característica convierte a las historias clínicas en una herramienta que es capaz de evaluar el nivel de la calidad técnico científica, humana, ética y la responsabilidad del profesional en salud. Es una herramienta infaltable en la práctica de los profesionales de la salud. Puede definirse como un documento que contiene la narración escrita, clara, precisa, detallada y ordenada de todos los datos y conocimientos, tanto personales como familiares, que se refieren a un paciente y que sirven de base para el juicio definitivo de su enfermedad actual o de su estado de salud (Serna, 2011).

El profesional registrar en una historia clínica concretada toda la información procedente de su práctica clínica, relativa a un enfermo, y sintetizar en ella todos los procesos a que ha sido sometido, tanto para guardar la memoria de su actuación como para facilitar el posible seguimiento por parte de otros colegas. El profesional debe ofrecer extremo rigor de su contenido, es decir en la historia clínica debe registrarse lo que se pensó, dijo o se hizo acerca del paciente. “La fidelidad es, por lo tanto, un criterio de diseño fundamental” (Serna, 2011, p.15).

Una pregunta presente a la hora de diseñar un sistema de HCE es: cómo diseñar mejor los registros de salud electrónicos para mejorar el funcionamiento de los métodos de los médicos y la calidad de la atención. Aunque la documentación clínica desempeña un papel

29

muy importante también ocupa una proporción sustancial del tiempo de los médicos, las prácticas de documentación han sido dictadas en gran medida por la facturación y los requisitos legales. Sin embargo, el papel primordial de la documentación debe ser describir y comunicar claramente lo que está sucediendo con el paciente (Serna, 2011).

Una parte fundamental de la prestación de una buena atención médica es obtener el diagnóstico correcto. Desafortunadamente, los errores diagnósticos son comunes, superando la medicación y los errores quirúrgicos como causas de reclamos por negligencia ambulatoria. Los EHR ofrecen múltiples beneficios, pero uno de sus puntos clave es su potencial para prevenir, minimizar o mitigar errores de diagnóstico. No existe evidencia que apoya la existencia de este beneficio, muchos médicos, argumentan que la documentación electrónica en su actual encarnación electrónica lleva mucho tiempo y puede degradar el pensamiento diagnóstico distrayendo a los médicos, desalentar la recopilación y evaluación de datos independientes y efectuar errores (Gordon, 2011).

La documentación electrónica ayudará a que el proceso de diagnóstico sea confiable.

Los desarrolladores de sistemas y los clínicos deberán re conceptualizar el flujo de trabajo de documentación para la próxima generación de EHRs (Gordon, 2011).

Según Gordon (2011) “El problema de tener demasiada información supera ahora el de tener muy poco, y será cada vez más difícil revisar toda la información del paciente que esté disponible electrónicamente”. Sin embargo, una virtud de los sistemas computarizados es que pueden mostrar información grabada en varios formatos. Los diseñadores necesitarán aprovechar las capacidades de visualización de los documentos para la agregación de juicios rápidos.

3.2.5.2. HCE.

De acuerdo con la International Organization for Standardization (ISO), una HCE es un repositorio de datos de un paciente en un formato digital, almacenados de una manera segura y accesibles a usuarios autorizados, pero más que eso, es una nueva manera de almacenar y organizar la información del paciente, que junto con la interconectividad de las redes informáticas, permite que sea accesible desde cualquier espacio y en cualquier momento por los actores autorizados (pacientes, profesionales de la salud y técnicos vinculados al sector Salud), con observancia de las leyes de reserva, protección de datos personales y seguridad de acceso (Herrera, Cedamanos y Rojas, 2015).

30

Una HCE es la información histórica de la vida médica de una persona la cual reposa en medios digitales, con el objetivo de soportar y supervisar los cambios en el cuidado médico, la educación y la investigación, asegurando la confidencialidad y disponibilidad de su contenido en todo momento (Pacheco, 2008).

4.

METODOLOGÍA DE LA INVESTIGACIÓN

4.1. Enfoque / Tipo de Investigación La presente investigación es de carácter mixto puesto que las técnicas para recolectar y analizar los datos provinieron de métodos cuantitativos y cualitativos. Como dice Hernández (2014) los métodos mixtos son la agrupación de procesos metódicos y experimentales en los cuales se recolectan y analizan datos cuantitativos y cualitativos (p.

534). El instrumento de recolección de datos “Encuesta” brinda datos cuantificables útiles para sustentar el problema de investigación, mientras que a través de la técnica “Entrevista” se obtiene información cualitativa necesaria para desarrollar la solución propuesta.

La investigación aplicada es el tipo de investigación que se emplea en el desarrollo de este trabajo puesto que según Borda (2013) esta se basa en utilizar una sólida base teórica que es utilizada por el investigador para obtener los resultados. Este tipo de investigación es el adecuado para el desarrollo de software y para la ingeniería en general ya que como ingenieros utilizamos la investigación pura, los descubrimientos y avances científicos, y los aplicamos para el bien de la sociedad.

4.2. Población / Muestra “La población es el número total de elementos que comparten características similares de los cuales se necesita información específica para desarrollar una investigación” (Bernal, 2010, p. 160).

Para la presente investigación, la población está conformada por el personal que labora en el departamento de recepción y de Rayos X en donde es manipulada la información.

El total de personas que interactúan con el sistema es de 4, las cuales constituyen la población.

31

La muestra es un subgrupo representativo de la población del cual se recolectarán los datos. Según López (2004) una recomendación es tomar la mayor muestra posible ya que mientras más grande y representativa sea la muestra, menor será el error de la muestra. Pese a que la población es pequeña y de acuerdo con lo que indica Posso (2009), no es necesario determinar muestra cuando la población es menor a 30 individuos, entonces los instrumentos se aplican a toda la población. Es por esto que se escogió a las 4 personas como muestra.

4.3. Técnicas e Instrumentos de Recogida de Datos “La entrevista es un proceso de comunicación que se realiza normalmente entre dos personas; en este proceso el entrevistado obtiene información del entrevistador de forma directa” (Peláez, Rodríguez, Ramírez, Pérez, Vázquez, y González, s.f.).

Para el desarrollo de este proyecto de manejo de historias clínicas las técnicas de recolección de datos utilizadas fueron las entrevistas y las encuestas. La encuesta fue aplicada a la muestra de este proyecto para sustentar la problemática inicial. La entrevista fue aplicada al personal que mayor interacción tiene con el proceso de manejo de historias clínicas. A continuación se detalla el uso de: Entrevista: La entrevista permitió obtener de manera detallada los requerimientos indispensables para la elaboración del sistema, de esta forma se logrará obtener una orientación clara para cubrir las necesidades por parte de la entidad interesada.

Encuesta: abarca preguntas relacionadas con la problemática. Pretende recolectar información cuantitativa para determinar si la población realmente tiene inconvenientes y si está apta para utilizar la solución propuesta por este proyecto.

El instrumento utilizado para la recogida de datos fue definido mediante la metodología de desarrollo de software empleada, su nombre es “Historia de usuario”, un instrumento que se asemeja al conocido cuestionario. El cuestionario según García (2002) es un sistema de preguntas que se responde de forma escrita en un lenguaje sencillo y comprensible.

4.4. Técnicas de Análisis de Datos Para el análisis de los datos recopilados con las encuestas se hizo uso de la técnica de tabulación de los datos y por medio de estadísticas se representó la información en gráficos

32

de pastel para una mejor identificación de los resultados.

Las técnicas de análisis de datos que se utilizó en esta investigación incluye la interpretación de los requerimientos propuestos por los participantes de la muestra. Mediante el análisis y la interpretación de los datos recopilados se buscó las mejores alternativas para que los datos en bruto se materialicen en soluciones informáticas que cubran las necesidades de los usuarios.

5. RESULTADOS 5.1. Discusión y Análisis de los Resultados 5.1.1. Entrevista Discusión, Encuesta Discusión.

El funcionamiento del laboratorio clínico Cedylabe es parecido al de cualquier otra entidad con el mismo fin. Los pacientes al momento de ingresar a las instalaciones cancelan el valor del estudio a realizarse para luego esperar en una sala por su turno. Una vez que llega su turno pasan a una nueva habitación donde son atendidos por un auxiliar encargado de tomar los datos del paciente y llenarlo en un documento de Word.

Mediante una entrevista realizada a la secretaria asistente del médico radiólogo se pudo recabar la información necesaria sobre los procesos. Para entender las actividades involucradas en el área de imágenes médicas, se realizaron las siguientes preguntas: ¿Una vez en la nueva habitación qué se realiza con los datos del paciente?

Se le pregunta al paciente si ya tiene una historia clínica en la institución realizada anteriormente. ¿Qué pasa si el paciente no tiene una historia abierta?

Si la respuesta es “no” entonces se le abre una nueva historia clínica en donde se llenan todos los datos personales del paciente y los datos del pedido de la actual atención médica. ¿Qué herramientas utilizan para crear una nueva historia clínica?

Para crear una nueva historia clínica se utilizan plantillas prediseñadas en hojas de

33

Word, las cuales contienen la información que debe ser reemplazada con los datos reales del paciente que se atiende. ¿Cómo almacenan las plantillas?

Las plantillas son almacenadas en una carpeta e identificadas por el nombre del estudio. ¿Y en caso de que el paciente ya se haya atendido antes?

Si se ha atendido antes el responsable solo toma la información que cree necesaria para actualizarla posteriormente en la historia del paciente. “Diagnóstico presuntivo” y “Nombre del médico” son los campos más propensos a ser llenados aquí. ¿Que se realiza una vez llenada la plantilla?

Se imprimen y se almacenan en directorios clasificados por nombre de estudio y dentro subcarpetas con las iniciales de los apellidos de los pacientes.

Las historias son guardadas con la estructura: “Apellido Paterno Apellido Materno Primer Nombre Segundo Nombre” en la carpeta que tiene como nombre la inicial del primer apellido. ¿Qué actividad se realiza con las historias almacenadas?

Ya almacenadas las historias pueden ser requeridas por el médico radiólogo al momento de querer dar un diagnóstico. Estos evalúan las condiciones anteriores del paciente y las relacionan con las actuales posibilitando así ampliar la veracidad y la calidad del diagnóstico, además de poder hacer observaciones que le puedan ser útiles a los doctores especialistas que son los que envían al paciente a realizar estos estudios. ¿Cuál sería el principal inconveniente para realizar estos procesos?

La dificultad más grande se da a la hora de realizar estadísticas y también a la hora de comparar los resultados de las historias anteriores, ¡se dificulta mucho el proceso!

De acuerdo a lo recabado en la anterior entrevista se concluye que los procesos realizados por la empresa utilizan métodos poco automatizados y eficientes. Estos procesos pueden ser fácilmente mejorados mediante la implementación de un software a la medida.

34

5.1.2. Encuesta Realizada a los Miembros de la Muestra.

1. ¿Ha utilizado usted algún sistema informático orientado a la web?

Tabla 3 Resultados de la encuesta pregunta 1 OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 1

0%

100%

SI

NO

Figura 4. Gráfico de resultados a la pregunta 1. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Según los datos recabados, la población en su totalidad afirman que si han utilizado algún tipo de sistema orientado a la web. Es decir tienen conocimientos respecto a los sistemas que se manejan según la plataforma web.

35

2. Teniendo en cuenta conceptos básicos de computación ¿cree usted que se encuentra apto para usar un sistema informático?

Tabla 4 Resultados de la encuesta pregunta 2 OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 2

0%

100%

SI

NO

Figura 5. Gráfico de resultados a la pregunta 2. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Según la información recabad a de la encuesta, la población afirma que si tienen conocimientos básicos de computación, esto facilitara la comprensión respecto a la hora de utilizar algún sistema.

36

3. ¿Considera usted que la utilización de las historias clínicas es importante para mejorar la calidad del servicio prestado por la institución?

Tabla 5 Resultados de la encuesta pregunta 3 OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 3

0%

100%

SI

NO

Figura 6. Gráfico de resultados a la pregunta 3. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Tomando en cuenta la información recabada de la encuesta, la totalidad de la población considera que las historias clínicas son de mucha importancia para la mejora de la calidad de los servicios que presta la institución.

37

4. ¿Está usted de acuerdo en la forma en que se manejan las historias clínicas actualmente?

Tabla 6 Resultados de la encuesta pregunta 4 OPCIÓN

CANTIDAD

PORCENTAJE

Si

1

25 %

No

3

75 %

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 4

25%

75%

SI

NO

Figura 7. Gráfico de resultados a la pregunta 4. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Según la información recabada en esta encuesta, el 75% de la población está de acuerdo en que la actual forma de recabar los datos de las historias clínicas es muy tediosa y tan solo el 25% le parece q si está bien, esto porque esa parte de la población no maneja de manera directa las historias clínicas como el resto.

38

5. ¿Ha tenido usted inconvenientes para manejar la información perteneciente a las historias clínicas?

Tabla 7 Resultados de la encuesta pregunta 5 OPCIÓN

CANTIDAD

PORCENTAJE

Si

3

75 %

No

1

25 %

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 5

25%

75%

SI

NO

Figura 8. Gráfico de resultados a la pregunta 5. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Según lo recabado en la encuesta, el 75% de la población menciona que si ha tenido inconvenientes a la hora de manejar las historias clínicas, esto tal vez porque las realizan de manera manual en hojas de papel, por otra parte el 25% de la población dice que no ha tenido inconvenientes, esto porque no está ligada al manejo directo de las historias clínicas.

39

6. ¿Considera usted que el proceso de gestionar las historias clínicas mediante archivos de Word es un método anticuado que conlleva a cometer errores de ingreso de información?

Tabla 8 Resultados de la encuesta pregunta 6.

OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 6

0%

100%

SI

NO

Figura 9. Gráfico de resultados a la pregunta 6. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Tomando en cuenta los datos adquiridos a través de los resultados de esta pregunta se determina que el proceso actualmente empleado para gestionar la información de historias clínicas en la empresa está desactualizado y no permite prevenir errores de ingreso de información

40

7. ¿Cree usted que un sistema informático mejoraría el proceso de manejo y control de historias clínicas en la institución?

Tabla 9 Resultados de la encuesta pregunta 7.

OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 7

0%

100%

SI

NO

Figura: 10. Gráfico de resultados a la pregunta 7. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: Según los datos obtenidos de la encuesta se puede afirmar que efectivamente toda la población considera que un sistema informático puede mejorar aspectos relacionados con el proceso de manejo de las historias clínicas. La población es consciente de que los sistemas informáticos dedicados son mejores que las herramientas multiusos para la gran mayoría de los casos

41

8. ¿Cree usted que se debería recoger datos estadísticos de las historias clínicas para que sirvan de apoyo a la toma de decisiones en la administración?

Tabla 10 Resultados de la encuesta pregunta 8.

OPCIÓN

CANTIDAD

PORCENTAJE

Si

3

75 %

No

1

25 %

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 8

25%

75%

SI

NO

Figura 11. Gráfico de resultados a la pregunta 8. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: De acuerdo a los datos recabados en las encuestas se determina que el 75% de la muestra consideran que se deberían recoger información de las historias clínicas para el apoyo a la toma de decisiones por parte de la administración de la empresa. El 25% restante no estuvo de acuerdo con esta iniciativa. En base al análisis la mayor parte de la población considera que esta característica será útil para la empresa.

42

9. ¿Considera que debería existir un mecanismo que permita asegurar la integridad y la seguridad de la información de las historias clínicas?

Tabla 11 Resultados de la encuesta pregunta 9.

OPCIÓN

CANTIDAD

PORCENTAJE

Si

4

100 %

No

0

0%

Total

4

100 %

Nota: 4 personas son el total de la población. Fuente: Encuesta realizada a los miembros de la muestra

Pregunta 9

0%

100%

SI

NO

Figura 12. Gráfico de resultados a la pregunta 9. Fuente: Encuesta realizada a los miembros de la muestra

Análisis: De acuerdo con la información brindada por las encuestas se puede determinar que el 100% de las personas que estarán involucradas con el sistema consideran que la integridad y seguridad de la información manejada por la aplicación son características importantes y por lo tanto deben ser aseguradas.

43

5.1.3. Diagrama de Procesos.

Figura 13. Diagrama de procesos. Fuente: Datos obtenidos de la investigación de campo.

5.2. Propuesta de Intervención 5.2.1. Desarrollo del Producto de Software.

En esta sección se desarrolla el cuarto objetivo de la investigación en base al análisis, realizado en los capítulos anteriores. Se utilizará la metodología de desarrollo Programación Extrema (eXtreme Programming) como base para el ciclo de vida del sistema. Como se podrá observar en los siguientes segmentos se describen los puntos claves en la implementación de la metodología tomando como base la bibliografía.

5.2.2. Roles para el Proceso de Desarrollo del Software en la Comunidad del Trabajo.

Mediante a un análisis se establecieron los roles de los participantes del equipo de desarrollo. La programación en pareja es una regla únicamente de la metodología XP y está pensada para ser aplicada en equipos de profesionales contratados con mismo perfil técnico.

44

Tomando en cuenta que el presente equipo es de solo dos personas no se vio factible aplicar la regla que predica la programación en parejas, las razones incluyen: diferentes conocimientos técnicos de tecnologías de desarrollo en los participantes, diferentes experiencias en roles distintos y por último la más importante es la poca disponibilidad de tiempo para adaptarse a este modo de trabajo, como dice Wells (1999) “toma tiempo acostumbrarse a la programación en parejas” para adaptarse a esta forma de trabajo, además Wells (1999) indica que “es contra intuitivo que dos personas trabajando juntas vayan a desarrollar tantas funcionalidades como dos personas separadas, a menos que tenga más calidad”, por lo tanto tomando en cuenta esta idea se decidió sacrificar a esta actividad para poder así cumplir con el plazo establecido.

Con lo anterior aclarado, se definieron los roles de esta manera: Manager, tracker, programador frontend: Juan Crespo Tester, tracker, programador backend: Alejandro González 5.2.3. Fases Primordiales para el Desarrollo en Función a la Metodología.

Las metodologías en si constan de procesos, los cuales se manifiestan de forma ordenada, esto hace que una metodología sea el aspecto fundamental a seguir como un camino, en función de conseguir un fin, el cual es en este caso es, desarrollar un sistemas informático para la gestión de las historias clínicas en los laboratorios Cedylabe. La metodología XP, la cual es tomada como guía para el desarrollo del sistema, consta de varias fases, y en este documento se argumentan empezando desde la primera en la cual se realizan las historias de usuario las cuales son propuestas por el cliente en la primera reunión, además es donde se presenta las funcionalidades que el cliente desea en el sistema a desarrollar.

5.2.3.1. Fase i: exploración.

En el primer paso se realiza la interacción con el cliente, ya que según las características de la metodología XP lo primero que se necesita son las historias de usuario.

Las historias de usuario son la base para el desarrollo de todo el proyecto por lo cual es conveniente definirlas todas al principio ya que así da un aspecto general de todas las operaciones que deberá realizar el sistema. En esta fase no se pudieron definir absolutamente todas, pero sí muchas de estas, además es importante resaltar que poco a poco, fueron siendo

45

modificadas para perfeccionarlas y así lograr un sistema robusto que sea capaz de satisfacer los requerimientos del cliente.

Mediante las entrevistas y las citas programadas, se pudo recabar la información necesaria para la elaboración de estas historias. Las personas cuestionadas fueron los posibles usuarios del sistema, el manager, la doctora y su secretaria.

5.2.3.1.1. Historias de usuario.

A continuación se presentan 3 ejemplos de historias de usuario realizadas en la fase de exploración.

Tabla 12 Historia de Usuario –Administración de pacientes

HISTORIA DE USUARIO

Número: 1

Usuario: Médicos

Nombre historia: Administración de pacientes Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 4|

Iteración asignada: 1

Programador responsable: Alejandro González, Juan Crespo

Descripción: Como usuario se tiene la necesidad de registrar y/o modificar a los pacientes llenando un formulario, además se necesita de alguna tabla en donde se puede visualizar los últimos registros realizados.

Observaciones: El sistema permite un acceso inmediato a la modificación de algún paciente si es que se lo requiere, esto por motivos de algún dato erróneo en el ingreso.

Nota: Ver todas las historias en anexos 3. Fuente: Datos obtenidos de la investigación de campo

Escenario 1: Si se dejan campos vacíos el sistema debe mostrar un mensaje de alerta indicando los campos incompletos. También el sistema muestra incoherencias en el registro de la cedula si se está ingresando alguna cedula incorrecta.

46

Escenario 2: El sistema deberá ir mostrando los resultados conforme se vayan registrando los caracteres en la parte de búsqueda, dando solución más rápida a la hora de encontrar algún paciente.

Escenario 3: En caso que se requiera alguna modificación de los datos de los pacientes, el sistema deberá dar la posibilidad de modificar esta información referente al paciente que se seleccione.

Escenario 4: El sistema deberá informar si en algún caso se esté ingresando un paciente ya registrado.

Tabla 13 Historia de Usuario – Creación de médico solicitante HISTORIA DE USUARIO Número: 2

Usuario: Médico / secretario

Nombre historia: Creación de médico solicitante Prioridad en negocio: Alta

Riesgo en desarrollo: Baja

Puntos estimados: 1

Iteración asignada: 1

Programador responsable: Alejandro González, Juan Crespo Descripción: Se debe poder realizar agregar médicos solicitantes para que puedan ser posteriormente utilizados en la creación de nuevos pedidos.

Observaciones: Nota: Ver todas las historias en anexos 3. Fuente: Datos obtenidos de la investigación de campo

Escenario 1: El sistema debe presentar un formulario amigable al usuario para el registro de médicos solicitantes y a su vez una tabla donde se pueda visualizar los últimos médicos registrados.

47

Escenario 2: El sistema informara si se está dejando campos del formulario de registro incompletos.

Tabla 14 Historia de Usuario – Administración de historias clínicas HISTORIA DE USUARIO Número: 3

Usuario: Médico

Nombre historia: Administración de historias clínicas Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 1

Iteración asignada: 7

Programador responsable: Alejandro González, Juan Crespo Descripción: Como usuario debo registrar las historias clínicas de acuerdo a los pedidos de los médicos solicitantes. Debo poder visualizar estas historias y debo poder modificar en caso de que alguna información esté mal ingresada. Debe haber una tabla informativa que muestre información de los últimos pedidos. Debe existir la opción de ver las historias que un paciente se ha realizado anteriormente para poder realizar una comparación histórica entre historias del mismo paciente y el mismo tipo de examen.

Observaciones: Al momento de realizar una historia clínica se debe tener la posibilidad de escoger el tipo de estudio por su categoría y subcategoría, y además la posibilidad de ingresar el nombre de estudio directamente.

Nota: Ver todas las historias en anexos 3. Fuente: Datos obtenidos de la investigación de campo

Escenario 1: El sistema debe presentar de forma ordenada un formulario de registro de pedidos, donde se llene información y también se seleccionen los estudios que se deseen realizar.

Escenario 2: En el caso que no esté el paciente o médico registrado, el sistema debe facilitar la posibilidad de ingresar pacientes y médicos desde el mismo formulario de registro de pedidos.

48

Escenario 3: Para escoger el tipo de estudio el sistema proporcionara la posibilidad de selección, por su categoría, subcategoría y tipo de estudio que se desee realizar ese pedido.

Escenario 4: El sistema facilita la posibilidad de registrar si ese pedido es cortesía, seleccionando la casilla si es el caso, de lo contrario se la dejara vacía.

Escenario 5: El sistema deber mostrar los últimos pedidos en una tabla junto al registro.

Escenario 6: El sistema irá almacenando de forma ordenada en una tabla de historias clínicas, donde se podrá filtrar la información dependiendo del campo que se desee así como un recuadro de búsquedas avanzadas para encontrar de forma inmediata lo que desee el usuario.

Escenario 7: El sistema deberá proporcionar la posibilidad de modificar alguna historia, esto por medio de un botón que re direccionara a una ventana donde se podrá modificar un campo y su conclusión, pudiendo así actualizar datos si es que lo requiera.

Para conocer todas las historias de usuario ver Anexo 3.

5.2.3.2. Fase ii: planificación de entrega.

Una vez realizada la evaluación del cliente a las historias de usuario y la valoración requerida para la estimación del esfuerzo, se presenta a continuación la tabla donde se especifica el plan de entrega.

En la siguiente tabla se describe el calendario de trabajo el cual servirá de referencia para calcular el punto de esfuerzo.

49 Tabla 15 Calendario de trabajo CALENDARIO DE TRABAJO

MES

SEMANA

DÍAS

HORAS

2

8

42

168

Nota: Solo días laborables. Fuente: Datos obtenidos de la investigación de campo

El esfuerzo de desarrollo consiste en el tiempo que se estima que se utilizará para la funcionalidad, se detalla a continuación Tabla 16 Esfuerzo de desarrollo

1 PTO ESFUERZO DESARROLLO

PERSONAS

DÍA

HORA

2

1

4

Nota: PTO = punto. Fuente: Datos obtenidos de la investigación de campo

Un punto de esfuerzo equivale a 2 personas trabajando 4 horas en un 1 día.

El plan de entrega se detalla a continuación y describe los atributos para cada iteración del proyecto.

50

5.2.3.2.1. Plan de entrega.

Tabla 17 Plan de Entregas

MÓDULO

HISTORIAS DE USUARIOS

TIEMPO ESTIMADO SEMANAS

PRI. DE NEG.

RIE. DE DES.

Módulo Pacientes

Administración de pacientes

1 semana

Alta

Medio

Módulo Médico Solicitante

Creación de médico solicitante

1 semana

Alta

Baja

Alta

Alta

Alta

Alta

Alta

Alta

Medio

Medio

Bajo

Bajo

Bajo

Bajo

Medio

Medio

Medio

Bajo

Alta

Alta

Administración de historias clínicas Módulo Historias Clínicas

Impresión de historias clínicas

2 semana

Crear nuevos estudios con plantillas word prediseñadas Generar reportes e imprimirlos Módulo de Reportes

Administrar cortesías

1 semana

Registrar placas usadas Módulo de Administración Módulo de Acceso de usuario

Creación de grupos de usuarios y asignación de privilegios

1 semana

Interfaz para administración 2 semana Acceso de usuario

Nota: PRI= prioridad, NEG= negocios, RIE= riesgo, DES= desarrollo. Fuente: Datos obtenidos de la investigación de campo

5.2.3.2.2. Plan de iteración.

A continuación se presenta la tabla de los planes de iteración la que muestra en que iteración se desarrollará cada historia de usuario y cuanto esfuerzo tomará realizar la iteración.

51 Tabla 18 Plan de Iteraciones TIEMPO ESTIMADO

ITERACIONES MÓDULO

HISTORIAS DE USUARIOS 1

2

3

4

5

H

D

S

Módulo Pacientes

Administración de pacientes

x

20

5

1

Módulo Médico Solicitante

Creación de médico solicitante

x

20

5

1

Administración de historias clínicas

x

16

5

x

8

2

x

20

5

x

8

2

Administrar cortesías

x

8

2

Registrar placas usadas

x

4

1

Módulo Historias Clínicas

Impresión de historias clínicas Crear nuevos estudios con plantillas word prediseñadas Generar reportes e imprimirlos

Módulo de Reportes

Módulo de Administración Módulo de Acceso de usuario

Creación de grupos de usuarios y asignación de privilegios

x

20

5

Acceso de usuario

x

20

5

20

5

2

1

1

2 Interfaz para administración

x

Nota: H= horas, D= días, S= semanas. Fuente: Datos obtenidos de la investigación de campo

En la primera iteración se desarrollan las funcionalidades del software que permiten seguir el flujo de trabajo actualmente empleado en la empresa, esto posibilita que la primera entrega sea completamente funcional.

En la segunda iteración se desarrollan las características del sistema que le añaden funcionalidades operativas, fundamentalmente de segunda prioridad.

En la tercera iteración se manejan funcionalidades alternas de baja prioridad pero con mucha utilidad para el administrador. Estas funcionalidades son básicamente para el control administrativo.

La cuarta iteración hace referencia a las funcionalidades para el control y acceso a los usuarios del sistema. Cubre aspectos como la creación de usuarios y los permisos que tendrá para operar en el sistema.

Por ultimo en la quinta iteración se desarrolla la última historia la cual está destinada a que el administrador posea una interfaz amplia en funcionalidad, desde la cual pueda

52

controlar todos los modelos de datos que utiliza el sistema, sin restricción de acceso alguno.

5.2.3.3. Fase iii: iteraciones.

En esta sección se documentan las partes más relevantes del proceso iterativo.

Utilizando diagramas UML se expondrá los resultados de la estructura y organización del código fuente conjunto de sus funcionalidades.

5.2.3.3.1. Diseño.

5.2.3.3.1.1 Modelo de datos.

El siguiente modelo de datos fue desarrollado de acuerdo a los requerimientos planteados en la primera, segunda y tercera iteración. De estas iteraciones se construyó un diagrama entidad relación donde se planteó una estructura provisional para los modelos la cual fue codificada al inicio del proyecto. Luego cuando era la hora de desarrollar una iteración se iba comprobando que la funcionalidad de esta encajara al modelo provisional, si no era así se iban deduciendo nuevos modelos con sus atributos y sus relaciones.

Para realizar cambios concebidos por errores de conceptualización, tanto en las relaciones como en los atributos de los modelos de datos, se modificaba el archivo de modelos y se creaba una migración. Una migración consiste en un archivo que almacena los cambios surgidos desde un estado de la base de datos hacia el estado actual. Luego se corregían los errores de integridad cuando existían, entonces se aplicaba la migración para que el archivo de base de datos fuera modificado con las consultas pertinentes creadas por el ORM.

53

Figura 14. Modelo de datos. Fuente: Datos obtenidos de la investigación de campo.

En la siguiente figura se muestra el modelo físico de los datos necesarios para realizar las iteraciones cuatro y cinco del sistema. Este modelo está escrito previamente para la aplicación Django Auth, la cual provee de interfaces y controladores para el manejo de usuarios. Gracias al principio Dont Repeat Yourself (DRY) se pudo implementar de manera satisfactoria los requerimientos de las últimas dos iteraciones.

Figura 15. Modelo físico de datos. Fuente: Datos obtenidos de la investigación de campo.

54

5.2.3.3.1.2 Modelo de casos de uso.

Figura 16. Modelo de casos de usos. Fuente: Datos obtenidos de la investigación de campo.

5.2.3.3.1.3 Diseño de interfaces gráficas.

Para el desarrollo de interfaces gráficas se ha utilizado un enfoque de diseño minimalista lo que significa que no se ha cargado de elementos innecesarios o de una gama extensa de colores en la interfaz.

Los elementos HTML son adornados con los estilos del framework Bootstrap lo cual le da una apariencia parecida a la normativa de diseño Material Design de Google.

A través de las pruebas de aceptación se pudo corregir algunos aspectos relacionados con el color y la posición de los elementos gráficos. Estos inconvenientes fueron planteados como sugerencias por parte del cliente por lo cual no se realizó una nueva planeación de iteración sino que se acumuló en una lista para ser modificada al final de la última iteración.

A continuación se presentan las imágenes del resultado de diseño final del sistema agrupados por módulos de funcionamiento.

55

a) Mรณdulo pacientes

Figura 17. Registro de pacientes. Fuente: Interfaz del sistema Hcapp

Figura 18. Tabla general de pacientes. Fuente: Interfaz del sistema Hcapp.

56

b) Módulo médicos solicitantes

Figura 19. Creación de médicos solicitantes. Fuente: Interfaz del sistema Hcapp.

c) Módulo de historias clínicas

Figura 20. Registro de pedidos de historias clínicas. Fuente: Interfaz del sistema Hcapp.

57

Figura 21. Consulta de historia clínica. Fuente: Interfaz del sistema Hcapp.

Figura 22. Modificación de historias clínicas. Fuente: Interfaz del sistema Hcapp.

58

Figura 23. Impresión de historia clínica. Fuente: Interfaz del sistema Hcapp.

d) Módulo de reportes

Figura 24. Reportes - selección de fechas y opciones. Fuente: Interfaz del sistema Hcapp.

59

Figura 25. Reporte – selección tipo de placas. Fuente: Interfaz del sistema Hcapp.

Figura 26. Reporte - cortesías últimas pacientes. Fuente: Interfaz del sistema Hcapp.

60

Figura 27. Reporte - tipos de estudios. Fuente: Interfaz del sistema Hcapp.

Figura 28. Reporte – mÊdicos. Fuente: Interfaz del sistema Hcapp.

61

Figura 29. Reporte - placas desechadas. Fuente: Interfaz del sistema Hcapp.

e) Mรณdulo de administraciรณn

Figura 30. Administraciรณn del sitio. Fuente: Interfaz del sistema Hcapp.

62

f) Mรณdulo de acceso de usuario

Figura 31. Lista de usuarios. Fuente: Interfaz del sistema Hcapp.

Figura 32. Agregar usuario. Fuente: Interfaz del sistema Hcapp.

63

Figura 33. Modificaciรณn de usuario. Fuente: Interfaz del sistema Hcapp.

Figura 34. Selecciรณn de permisos de usuario. Fuente: Interfaz del sistema Hcapp.

64

Figura 35. Ingreso de fechas importantes. Fuente: Interfaz del sistema Hcapp.

Figura 36. Login del sĂşper-usuario. Fuente: Interfaz del sistema Hcapp.

Figura 37. Login de usuario. Fuente: Interfaz del sistema Hcapp.

65

5.2.3.3.2. Diseño de clases.

Las tarjetas CRC no fueron herramientas utilizadas en este proyecto para el diseño de clases debido a que se trabajó bajo un framework que posee una sólida estructura de clases ya diseñada e implementada y con el respaldo de una gigantesca comunidad de colaboradores expertos. La mayor parte de los controladores fueron subclases que heredan características de las librerías instaladas. Además debido a que el desarrollo de las clases recayó solamente en una persona la utilidad de las tarjetas CRC fue abismalmente reducida ya que éstas, están pensadas para la distribución de tareas (clases) entre los programadores del equipo.

En dos ocasiones fue necesario definir una estructura de clases para optimizar el código, adaptarse al diseño orientado a objetos y seguir la filosofía de simplicidad propuesta por XP. Para esta actividad se utilizó el tradicional diagrama de clases definido por UML a continuación se presentan dichas soluciones: Para la creación de una clase “Reportes” en común que comparta sus atributos y funcionalidades a otras clases con características específicas.

Figura 38. Diseño de clases. Fuente: Datos obtenidos de la investigación de campo.

66

Para compartir la configuración de las funcionalidades y restricciones que tendrán los modelos en la interfaz de administración:

Figura 39. Diseño de clases- interfaz administración. Fuente: Datos obtenidos de la investigación de campo.

5.2.3.3.3. Codificación.

Para el proceso de programación se utilizó la herramienta de control de versiones Git con Github como servicio de repositorio. Mediante esta herramienta los programadores fueron capaces de trabajar colaborativa y simultáneamente. Además facilitó el trabajo individual y el proceso de integración de código al proyecto.

Python fue utilizado como lenguaje de programación, Django como framework web y otros productos de software descritos en el marco referencial, para lograr pequeñas pero importantes finalidades.

Se realizaron pruebas unitarias al finalizar cada actividad verificando en el servidor de desarrollo que los datos requeridos y archivos estáticos eran servidos y eran correctamente renderizados en el navegador web. Para las tareas que necesitaron de largas cadenas de consultas a las base de datos, se utilizó el intérprete interactivo de Django, el cual permitió probar los modelos antes de utilizarlos, hacer consultas y analizar sus resultados para comprobar que son los deseados. De esta manera se redujo la incertidumbre para las

67

funcionalidades más extensas y probablemente también se ahorró tiempo destinado a corregir errores de operaciones con los datos.

A continuación se presenta un ejemplo de prueba unitaria realizada con el framework de ejecución de pruebas de Django en el cual se puede comprobar el correcto funcionamiento de la función “reemplaza()” la cual utiliza datos de casi todos los modelos desarrollados para la aplicación.

Figura 40. Código fuente de prueba unitaria automática. Fuente: Sistema Hcapp.

Figura 41. Ejecución de prueba unitaria automática. Fuente: Sistema Hcapp.

Durante la codificación se definieron y utilizaron estándares de codificación los cuales prescribían aspectos como: Formatos de identificadores para variables, constantes, atributos, campos de formulario, objetos de base de datos, variables de contextos, funciones, clases etc.  Estructura de serialización de datos.  Jerarquía de templates (plantillas HTML)  Patrones de identificadores de expresiones regulares en las url.  Organización de archivos estáticos.

68

De esta manera se mantuvo consistente y fácil el proceso leer, escribir y refactorizar el código para el equipo de desarrollo.

Para la organización del código se utilizó la convención planteada por Django la cual consiste en dividir los archivos de configuración de todo el proyecto de los archivos de las aplicaciones. El directorio de la aplicación separa los archivos que la componen siguiendo la arquitectura MVC. Con esta forma de trabajo las características de la aplicación son divididas en:  Templates (plantillas HTML)  Views (controladores)  Urls (rutas de accesos)  Models (acceso a datos)  Forms (fábrica de formularios)  Migraciones (cambios históricos en la estructura del modelo de datos)  Tests (pruebas unitarias)  Admin (representaciones de modelos en interfaz de administrador)  Statics (archivos estáticos o assets) A continuación se presenta una serie de figuras que describe la estructura jerárquica de los controladores (views). Utilizando lenguaje UML se demostrará la estructura del código principal sin necesidad de presentar largas filas de código fuente.

69

Figura 42. Estructura jerรกrquica de los controladores.

70

5.2.3.4. Fase IV: pruebas.

5.2.3.4.1. Pruebas de aceptación.

El plan de pruebas esta realizado de acuerdo a las historias de usuarios, respetando y verificando las funcionalidades que el sistema debe presentar y realizar sin ningún percance, estas pruebas se establecen de forma más conjunta, es decir, se realizaron agrupando las funcionalidades por iteración, ya que en una iteración se encuentran varias funcionalidades que tienen que cumplirse y a su vez están relacionadas.

Tabla 19 Prueba de funcionalidad – Modulo de pacientes.

PRUEBA 01 Nombre caso de prueba: Administración de Pacientes Módulo/sección a evaluar: Módulo Administración de pacientes.

Historia de usuario asociada: N° 1

Descripción: Se procede a llevar el control de los pacientes, previo debe haber un registro de los mismos en el sistema, si este ya fue registrado procedemos a buscar y llenar con nuevos datos si es el caso.

Pre-condiciones  El usuario debe estar logeado.

Pasos y condiciones de ejecución  El usuario ingresa al sistema referente a su rol en la empresa.  Dirigirse al área de pacientes y registro donde también podrá buscar los que ya estén constando en el sistema.  El sistema deberá en el caso de búsqueda, brindar una rápida aparición de acuerdo a los datos ingresados para encontrar el paciente.

Resultado esperado.  El sistema verifica si tiene el usuario el permiso correspondiente y lo deja ingresar previo al ingreso de usuario y contraseña  El sistema muestra de manera inmediata los pacientes que tengan concordancia con el dato que se registra en la búsqueda.  El sistema encuentra el paciente y muestra esta información. Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno Acción final: Los datos para registro y búsqueda se realizan de manera inmediata.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

71 Tabla 20 Prueba de funcionalidad – Médico solicitante PRUEBA 02 Nombre caso de prueba: Administración de Médicos solicitantes Módulo/sección a evaluar: Módulo de Administración para médicos solicitantes.

Historia de usuario asociada: N° 2

Descripción: En esta sección los médicos pueden registrarse o si en caso ya lo esta se podrá actualizar algún dato. (Nombre, Apellido y teléfono) Pre-condiciones  El usuario debe ingresar al sistema (usuario y contraseña)

Pasos y condiciones de ejecución  El usuario tiene acceso según su rol y cargo en la institución  El usuario debe ingresar al sistema (usuario y contraseña)  Dirigirse en el menú en la parte de crear médico  Llenar el formulario.

Resultado esperado.  El sistema despliega el formulario de actualización o registro para los médicos.

Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno

Acción final: Los médicos quedan registrados.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

72 Tabla 21 Prueba de funcionalidad – Módulos de Historias clínicas PRUEBA 03 Nombre caso de prueba: Administración de las historias clínicas.

Módulo/sección a evaluar: Módulo de administración de historias clínicas.

Historia de usuario asociada: N° 3, 4 y 5

Descripción: Para esta parte los pacientes deben estar registrados y se procede a mostrar las historias de cada paciente según se busque el mismo en la tabla donde están todos.

Luego se podrá extraer la historia del paciente.

Pre-condiciones  El usuario debe ser médico  El usuario debe ingresar al sistema (usuario y contraseña)

Pasos y condiciones de ejecución  El usuario debe ingresar al sistema (usuario y contraseña)  Buscar el paciente en la tabla de historias clínicas.  Escoger el que desea y descargar su historia.

Resultado esperado.  El sistema después de una búsqueda rápida por caracteres según el ingreso, nos muestra al paciente donde se puede seleccionar para ver su historia al mismo tiempo que podemos descargarla. Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno Acción final: Estas plantillas sus campos internos son modificados por el médico si en caso lo desee, y se pueden descargar en formato Word.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

73 Tabla 22 Prueba de funcionalidad – Operación final para obtener Reportes PRUEBA 04 Nombre caso de prueba: Administración de reportes

Módulo/sección a evaluar: Módulo de reportes.

Historia de usuario asociada: N° 6, 7 y 8

Descripción: El sistema debe dar de forma inmediata los datos que se requieran, estos se podrán seleccionar de acuerdo a la fecha deseada.

Pre-condiciones  El usuario debe ingresar al sistema (usuario y contraseña)

Pasos y condiciones de ejecución  Dirigirse a la sección de reportes.  Seleccionar una fecha de inicio y fin.  Seleccionar el tipo de reporte que desea de acuerdo a las opciones solicitadas en las historias.

Resultado esperado.  El sistema muestra el reporte con la fecha que se escribió con anterioridad.  El sistema refleja un gráfico para un fácil entendimiento.  El sistema da la opción de imprimir de manera rápida. Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno

Acción final: Se obtiene un documento con lo solicitado.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

74 Tabla 23 Prueba de funcionalidad – Operación final para Administrar PRUEBA 05 Nombre caso de prueba: Administración.

Módulo/sección a evaluar: Módulo de administración.

Historia de usuario asociada: N° 9 y 10

Descripción: El sistema debe proporcionar a la administración un control global del sistema.

Pre-condiciones  El usuario debe ingresar al sistema (usuario y contraseña)

Pasos y condiciones de ejecución  Ingresar al sistema con el usuario administrador y contraseña

Resultado esperado.  El sistema muestra la administración del sitio  El sistema da el control total del sistema para registro de usuarios. (asignación de privilegios), ingresa de información y modificación del mismo. Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno

Acción final: Podrá dar los roles a los usuarios y registrar información.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

75 Tabla 24 Prueba de funcionalidad – Operación final para Acceso de usuarios.

PRUEBA 06

Nombre caso de prueba: Administración de acceso de usuarios.

Módulo/sección a evaluar: Módulo de acceso de usuarios.

Historia de usuario asociada: N° 11

Descripción: El sistema debe facilitar con un pequeño formulario el acceso al usuario, previo al ingreso de sus datos.

Pre-condiciones  El usuario debe tener un rol que el administrador le accedió con anterioridad.

Pasos y condiciones de ejecución  Dirigirse al login  Ingresar al sistema con el usuario y contraseña

Resultado esperado.  El sistema da acceso según el privilegio del usuario.

Éxito

Falló

Si

No

Estado de prueba

Errores asociados: Ninguno

Acción final: El usuario podrá trabajar según su rol accediendo a donde se le está permitido.

Nota: N° = número. Fuente: Datos obtenidos de la investigación de campo

5.3. Evaluación de Impacto del Proyecto Para comprender mejor los impactos generados en el proyecto, se presenta una tabla, donde se especifican los niveles he indicadores numéricos de cada uno de ellos.

Para el cálculo de los niveles de impacto se procederá de la siguiente forma: Nivel de impacto = total sumatorio ∑ dividido para la cantidad de indicadores (NI = ∑ / N°)

76 Tabla 25 DescripciĂłn de los valores asignados a cada nivel de impacto

NIVEL

DESCRIPCIĂ“N

-3

Impacto de alto nivel negativo

-2

Impacto de medio nivel negativo

-1

Impacto de bajo nivel negativo

0

No hay impacto

1

Impacto de bajo nivel positivo

2

Impacto de medio nivel positivo

3

Impacto de alto nivel positivo

Nota: Adoptado de “MetodologĂ­a para el trabajo de gradoâ€?, por M. A. Posso, 2009. Tesis y Proyectos Cuarta ed.

Ibarra: NINA Comunicaciones.

5.3.1. Impacto TecnolĂłgico.

Tabla 26 Impacto segĂşn el ĂĄmbito tecnolĂłgico

Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Desarrollo tecnolĂłgico

X

Integridad de la informaciĂłn

x

Total

-

Sumatoria ∑ Total

∑=3+2=5

Resultado de FĂłrmula Resultado

-

-

-

đ?‘ đ??ź =

-

2

3

5 = 2.5 2

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: Datos obtenidos de la investigaciĂłn de campo

AnĂĄlisis ďƒź Genera un desarrollo tecnolĂłgico mediante el uso de nuevas tendencias de desarrollo de software, ya que hace uso de las nuevas tecnologĂ­as de la informaciĂłn aplicadas a los procesos realizados por la empresa. ďƒź La responsabilidad del laboratorio al momento de manejar datos de los pacientes es primordial, con el sistema se garantiza la integridad de la informaciĂłn y fĂĄcil manejo de las historias clĂ­nicas.

77

5.3.2. Impacto Social.

Tabla 27 Impacto segĂşn el ĂĄmbito social

Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores

SistematizaciĂłn de procesos

X

Disponibilidad de historias clĂ­nicas

X

Condiciones de trabajo Total

x -

Sumatoria ∑ Total Resultado de FĂłrmula Resultado

-

-

-

-

2

6

∑=2+6=8 đ?‘ đ??ź =

8 = 2.66 3

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: Datos obtenidos de la investigaciĂłn de campo

AnĂĄlisis ďƒź Como impacto social tenemos el ahorro de tiempo en la SistematizaciĂłn de los procesos, significando un ahorro considerable en la gestiĂłn de la empresa. ďƒź El sistema mejora la accesibilidad y disponibilidad de las historias clĂ­nicas desde cualquier dispositivo que estĂŠ conectado a la red interna de la empresa. ďƒź El sistema proporciona comodidad mejorando la condiciĂłn laboral, evitando la incomodidad de recorrer las instalaciones en busca de alguna historia clĂ­nica.

78

5.3.3. Impacto EconĂłmico.

Tabla 28 Impacto segĂşn el ĂĄmbito econĂłmico

Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Apoyo a la gestiĂłn

x

Productividad del personal Total

x -

-

-

-

Sumatoria ∑ Total

1

-

6

∑=1+6=7

Resultado de FĂłrmula

đ?‘ đ??ź =

Resultado

7 = 2.33 3

Impacto de medio nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: Datos obtenidos de la investigaciĂłn de campo

AnĂĄlisis ďƒź Permite a largo plazo reducir el tiempo dedicado a la realizaciĂłn de informaciĂłn estadĂ­stica que a su vez mejora el control de la empresa y maximiza las ganancias. ďƒź El personal es mĂĄs productivo, ya que el factor tecnolĂłgico agilita los procesos logrando eficiencia en cuestiĂłn laboral por parte de los trabajadores de la empresa.

5.3.4. Impacto General.

Tabla 29 Resultado de impacto

Nivel de impacto

-3

-2

-1

0

1

2

3

Indicadores Impacto TecnolĂłgico

X

Impacto Social

X

Impacto EconĂłmico Total Sumatoria ∑ Total Resultado de FĂłrmula Resultado

x -

-

-

-

-

2

∑=2+6=8 đ?‘ đ??ź =

8 = 2.66 3

Impacto de alto nivel positivo

Nota: ∑= sĂ­mbolo para operaciones de suma. Fuente: Datos obtenidos de la investigaciĂłn de campo

6

79

Análisis  El sistema encargado de la gestión de historias clínicas en el laboratorio clínico Cedylabe muestra un impacto de alto nivel positivo, lo cual demuestra la viabilidad del proyecto en este laboratorio. La automatización de la gestión de las historias clínicas hace que el recurso que no se puede recuperar que es el tiempo sea más aprovechado, consultado de manera inmediata las historias de sus pacientes, además de reducir inversiones económicas en compra de ficheros y papel para almacenar dichas historias.

80

5.4. Conclusiones  A través de la implantación del sistema informático se logró mejorar la calidad y seguridad de la información y los procesos relacionados con los registros clínicos en el área de imágenes, gracias a la digitalización y automatización de aquellas actividades que eran realizadas de forma asistemáticas. Además la utilización del sistema permitió generar información adicional útil para la gestión administrativa de la institución.  Mediante la utilización del instrumento de recolección de datos; entrevista y cuestionario (historia de usuario) se determinaron las actividades que llevaba el personal de la empresa para el manejo de las historias clínicas. De esta manera se comprendieron los problemas incurridos en el proceso, los cuales fueron utilizados posteriormente para modelar de mejor forma los requerimientos del sistema.  La metodología de desarrollo seleccionada XP, permitió guiar el desarrollo del software a través de todas las fases definidas por esta. Brindó versatilidad para realizar cambios necesarios que surgieron a lo largo del proceso de desarrollo y de esta forma se plantearon los requerimientos especificados por los clientes y fueron procesados para convertirse en un producto de software exitoso.  Por medio de la arquitectura MVC se logró realizar un proyecto con una organización de código fuente altamente legible, mantenible y escalable.

Gracias a sus características se facilitó el uso de URLs amigables, así como el trabajo en los archivos de modelos, controladores y plantillas HTML.  El producto de software fue exitosamente desarrollado siguiendo la mayor parte de las reglas planteadas por la metodología seleccionada. La tecnología principal de desarrollo de software Django gracias a su naturaleza y su excelente documentación, brindó agilidad, seguridad y escalabilidad al producto.

81

 La implantación requirió de conocimientos un poco más avanzados de los que son requeridos por otras tecnologías cuando implantan sistemas pequeños, no obstante esta exhaustiva configuración permite una seguridad adicional, una gran robustez y facilidad de escalado.

82

5.5. Recomendaciones  Seleccionar la metodología de desarrollo que mejor se adapte a las características del proyecto y a las condiciones de los participantes. Utilizar solo aquellas reglas, valores y filosofías de la metodología que aporten ventajas al proceso de desarrollo y no aquellas que por alguna razón son complicadas o casi imposible de aplicar.  Incluir al cliente en el proceso de desarrollo la mayor parte del tiempo, posibilita la entrega a tiempo de las funcionalidades planeadas, puesto que se evitan retrasos incididos por modificaciones menores no especificadas en los documentos de requerimientos.  Reunir las características más importantes tanto de hardware como de software del dispositivo donde se instalará el sistema. Luego reproducir dichas características utilizando una máquina virtual en donde se pueda instalar el sistema a modo de prueba. De esta forma la persona se preparará frente a posibles adversidades en el proceso de despliegue en el sistema de producción oficial.  Se le recomienda al administrador de sistemas ajustar los parámetros de configuración del servidor a las necesidades reales del entorno de la empresa, guiándose por el manual de instalación. De igual manera para los nuevos usuarios se sugiere la lectura del manual de usuario para evitar contratiempos.

83

Lista de Referencias López, Pedro Luis. (2004). Población muestra y muestreo. Punto Cero, 09(08), 69-74.

Recuperado

en

22

de

mayo

de

2017,

de

http://www.scielo.org.bo/scielo.php?script=sci_arttext&pid=S181502762004000100012&lng=es&tlng=es.

Alfaro Martínez, J., & López Díaz, M., & Hernández López, A., & Gonzalvo Díaz, C., & Botella Romero, F. (2013). Integración de un programa informático de prescripción de nutrición artificial hospitalaria con la historia clínica electrónica. Nutrición Hospitalaria, 28 (5), 1696-1701.

Beltrán Gómez, A., & Bojacá Bazurto, A., & Martínez Rueda, R., & Duarte Acosta, N., & García Torres, M., & Saavedra Pardo, I. (2016). Sistema de gestión de información de historia clínica electrónica en terapias alternativas. Revista Cubana de Información en Ciencias de la Salud, 27 (3), 311-326.

Bernal, C. A. (2010). Metodología de la investigación. Colombia: Pearson Educación, S.A. Borda Pérez, M. (2013). El proceso de Investigación: Visión general de su desarrollo.

Barranquilla, Colombia: Universidad del Norte.

Ccm.net. (2016). Lenguajes de Programación. Obtenido de http://es.ccm.net/contents/304lenguajes-de-programacion Córdova Hernández, J A; (2008). Software libre en el sector salud. Horizonte Sanitario, 7(2) Recuperado de http://www.redalyc.org/articulo.oa?id=457845129004 Cortizo, J. P., Expósito, D., y Ruiz, L. (2016). eXtreme Programming. Recuperado de http://www.josek.net/publicaciones/xp.pdf Desarrolloweb.com. (s.f.). Desarrolloweb.com. Recuperado el 12 de 05 de 2017, de https://desarrolloweb.com/javascript/ Django

Software

Foundation.

(2017).

djangoproject.com.

Recuperado

de

https://www.djangoproject.com/start/overview/ Design Patterns Gamma, E., Helm, R., Johnson, R., & Vlissides, J. (1995). Indianapolis:

84

Addison Wesley.

Godoy, D. A. (2015). Diseño de un Simulador Dinámico de Proyectos de Desarrollo de Software que utilizan Metodología Scrum (tesis de maestría). Universidad Nacional de La

Plata,

Buenos

Aires,

Argentina.

Recuperado

de

http://sedici.unlp.edu.ar/handle/10915/44915.

Espín, A. F. (2015). Diseño e implementación de una aplicación web basada en la metodología MDA para la administración del historial clínico y farmacéutico de la clínica Ambato (tesis de grado). Pontificia Universidad Católica Del Ecuador Sede Ambato.

Recuperado

de

http://repositorio.pucesa.edu.ec/bitstream/123456789/1332/1/76010.pdf Fernández, J D; (2014). A framework for consistences in association relations between classes

in

UML.

Dyna,

81()

126-131.

Recuperado

de

http://www.redalyc.org/articulo.oa?id=49631663017 Gardey, J. P. (12 de 4 de 2012). Definición. Obtenido de http://definicion.de/ingenieria-desoftware/ Godoy, D. A. (2015). Diseño de un Simulador Dinámico de Proyectos de Desarrollo de Software que utilizan Metodología Scrum (tesis de maestría). Universidad Nacional de La

Plata,

Buenos

Aires,

Argentina.

Recuperado

de

http://sedici.unlp.edu.ar/handle/10915/44915.

Gordon Schiff, M. D. (2011). Can Electronic Clinical Documentation Help Prevent Diagnostic Errors? The new England journal of medicine, 362() 1066-1069.

Recuperado de http://www.nejm.org/doi/full/10.1056/NEJMp0911734#t=article Git-scm.com.

(s.f.).

Recuperado

el

13

de

05

de

2017,

de

https://git-

scm.com/book/es/v1/Empezando-Acerca-del-control-de-versiones gunicorn.org. (s.f.). Recuperado el 14 de 05 de 2017, de http://docs.gunicorn.org/en/stable Méndez, J. y Aponte, J. (2016). Desarrollo de un prototipo de software tipo case soportado en el modelo seudomatemático para el diseño de bases de datos relacionales. (grado).

Universidad Distrital Francisco José de Caldas Bogotá.

85

Mozilla

Developer

Network.

(2017).

mozilla.org/.

Obtenido

de

https://developer.mozilla.org/es/docs/Web/JavaScript nginx.com. (s.f.). Recuperado el 17 de 05 de 2017, de https://www.nginx.com/resources/wiki/ Pacheco, J; Villegas, A; Lugo, E; Villegas, H; (2008). Diseño de un software para la interpretación de historias clínicas electrónicas basadas en HL7/CDA aplicado en servicios de telemedicina. Revista INGENIERÍA UC, 15(1) 31-40. Recuperado de http://www.redalyc.org/articulo.oa?id=70712715005 Paderni, M C. Aguilar, I. Cabrera, M y Delgado, A. (2014). Bases de datos distribuidas para aplicaciones médicas en el Sistema Nacional de Salud. Revista Cubana de Informática

Médica,

6(2),

227-235.

Recuperado

de:

http://scielo.sld.cu/scielo.php?script=sci_arttext&pid=S168418592014000200011&lng=es&tlng=es Peláez, A., Rodríguez, J., Ramírez, S., Pérez, L., Vázquez, A., & González, L. (s.f.). uam.es.

Obtenido

de

https://www.uam.es/personal_pdi/stmaria/jmurillo/InvestigacionEE/Presentaciones/C urso_10/Entrevista_trabajo.pdf Posso, M. (2009). Metodología para el trabajo de grado (tesis y proyectos). Ibarra: Cámara Ecuatoriana del Libro – Núcleo de Pichincha.

Redacción Sociedad (1 de noviembre de 2015). La historia clínica ahora es electrónica en los

establecimientos

públicos

del

MSP.

El

Telégrafo.

Recuperado

de:

http://www.eltelegrafo.com.ec/noticias/salud/38/la-historia-clinica-ahora-eselectronica-en-los-establecimientos-publicos-del-msp Reese, W. (1 de 07 de 2008). linuxjournal.com. Recuperado el 17 de 05 de 2017, de http://www.linuxjournal.com/article/10108 Rubinos Carvajal, A M; Nuevo León, H A; (2011). Seguridad en bases de datos. Revista Cubana

de

Ciencias

Informáticas,

5(2)

Recuperado

de

http://www.redalyc.org/articulo.oa?id=378343671005 Secretaría Nacional de Planificación y Desarrollo. (2013). Plan Nacional para el Buen Vivir.

86

Quito.

Sellarès,

T.

(s.f.).

ima.udg.edu.

Recuperado

el

12

de

05

de

2017,

de

http://ima.udg.edu/~sellares/EINF-ES1/FactoryToni.pdf Serna, A. (2011). Ventajas y desventajas de la historia clínica electrónica. UNAD, 14-17.

Solarte Martínez, G R; (2015). Historia clínica electrónica desde un dispositivo móvil.

Scientia

Et

Technica,

20(1)

370-376.

Recuperado

de

http://www.redalyc.org/articulo.oa?id=84946834008 The Python Software Foundation . (2017). The Python Tutorial. Recuperado de python.org: https://docs.python.org/3/tutorial/index.html Toledo Molano, S; Vega Alvarado, E; Molina Vilchis, M A; (2007). Licencias de Software: Antecedentes.

Polibits,

(1)

35-37.

Recuperado

de

http://www.redalyc.org/articulo.oa?id=402640448007 UNESCO. (2013). sistema regional de información educativa de los estudiantes con discapacidad-SIRIED.

santiago

:

Oreal.

Recuperado

de

:

http://datateca.unad.edu.co/contenidos/15001/Lecturas/Articulo__Ventajas_y_desventajas_de_la_historia_clinica_electronica.pdf Vaca, S. L. (2015). Desarrollo de un sistema informático basado en la historia clínica odontológica única (MSP) para la aplicación y evaluación en consultorios privados de las parroquias El Sagrario y San Francisco del cantón Ibarra (tesis de grado).

Universidad Central Del Ecuador Facultad de Odontología, Quito, Ecuador.

Recuperado de http://www.dspace.uce.edu.ec/bitstream/25000/3553/1/T-UCE-0015113.pdf Vargas Herrera, J; Cedamanos Medina, C A; Rojas Mezarina, L; (2015). Registro nacional de historias clínicas electrónicas en perú. Revista Peruana de Medicina Experimental y

Salud

Pública,

32(1)

395-396.

Recuperado

de

http://www.redalyc.org/articulo.oa?id=36341083029 Vazquez Ortíz, Y., Mesa Reyes, Y., & Castillo Martínez, g. (2012). Comunidad técnica cubana de PostgreSQL: Arma para la migración del país a tecnologías de bases de

87

datos de cรณdigo. Uciencia.

Zea, O. Molina, J. Redrovรกn, F. (2017). Administraciรณn de base de datos con PostgreSql. Machala Ecuador: 3Ciencias.

88

GLOSARIO ACID Es un grupo de cuatro propiedades (Atomicidad, Consistencia, aislamiento y Durabilidad) que garantizan que las transacciones en las bases de datos se realicen de forma confiable.

Factory Method Consiste en utilizar una clase constructora con unos cuantos métodos definidos es dedicado a la construcción de objetos de un subtipo de un tipo determinado, es decir según usemos una u otra hija de esta clase abstracta, tendremos uno u otro comportamiento.

Framework Es una estructura conceptual y tecnológica de asistencia definida, normalmente, con artefactos o módulos concretos de software, que puede servir de base para la organización y desarrollo de software.

HCE (EMR) Es también llamada historia de salud electrónica o La Historia Clínica Electrónica. Es el conjunto global y estructurado de información relacionado con los procesos asistenciales de un paciente, soportado por una plataforma informática.

(EMR) Un sistema de récord médico electrónico es un sistema de información donde el profesional de la salud registra información detallada de las consultas y eventos de salud de sus pacientes. Está orientado al profesional de la salud.

HCE También denominada historia clínica informatizada (HCI), es el registro mecanizado de los datos sociales, preventivos y médicos de un paciente, obtenidos de forma directa o indirecta y constantemente puestos al día.

HTTP Abreviatura de la forma inglesa Hypertext Transfer Protocol, que significa protocolo de transferencia de hipertextos, se utiliza en algunas direcciones de internet.

89

MVC Es un estilo de arquitectura de software que separa los datos de una aplicación, la interfaz de usuario, y la lógica de control en tres componentes distintos, significa en español Modelo Vista Controladores.

SGBD Significa sistema gestor de base de datos. Es un conjunto de programas que permiten el almacenamiento, modificación y extracción de la información en una base de datos, además de proporcionar herramientas para añadir, borrar, modificar y analizar los datos.

Software, SW Es la parte lógica del computador, representada por todos los componentes lógicos necesarios que hacen posible la realización de tareas, en términos resumidos es todos los programas, aplicaciones de un computador.

UML Según sus siglas en inglés, Unified Modeling Language que significa lenguaje unificado de modelado, es el lenguaje de modelado de sistemas de software, es el lenguaje en el que está descrito el modelo.

WSGI Es una interface simple y universal entre los servidores web y las aplicaciones web o frameworks.

90

ANEXOS Anexo 1: Acta de entrega-recepciรณn del proyecto

91

Anexo 2: Carta de impacto

92

Anexo 3: Historias de usuario Historia de Usuario Número: 1

Usuario: Médicos

Nombre historia: Administración de pacientes Prioridad en negocio: Alta

Riesgo en desarrollo: Medio

Puntos estimados: 5

Iteración asignada: 1

Programador responsable: Alejandro González, Juan Crespo Descripción: Como usuario se tiene la necesidad de registrar y/o modificar a los pacientes llenando un formulario, además se necesita de alguna tabla en donde se puede visualizar los últimos registros realizados.

Observaciones: El sistema permite un acceso inmediato a la modificación de algún paciente si es que se lo requiere, esto por motivos de algún dato erróneo en el ingreso.

Escenario 1: 

Si se dejan campos vacíos el sistema debe mostrar un mensaje de alerta indicando los campos incompletos. También el sistema muestra incoherencias en el registro de la cedula si se está ingresando alguna cedula incorrecta.

Escenario 2: 

El sistema deberá ir mostrando los resultados conforme se vayan registrando los caracteres en la parte de búsqueda, dando solución más rápida a la hora de encontrar algún paciente.

Escenario 3: 

En caso que se requiera alguna modificación de los datos de los pacientes, el sistema deberá dar la posibilidad de modificar esta información referente al paciente que se seleccione.

Escenario 4: 

El sistema deberá informar si en algún caso se esté ingresando un paciente ya registrado.

93

Historia de Usuario Número: 2

Usuario: Médico / secretario

Nombre historia: Creación de médico solicitante Prioridad en negocio: Alta

Riesgo en desarrollo: Baja

Puntos estimados: 1

Iteración asignada: 1

Programador responsable: Alejandro González, Juan Crespo Descripción: Necesitamos de forma ordenada el registro de médicos solicitantes, para que puedan ser posteriormente utilizados en la creación de nuevos pedidos.

Observaciones: El registro se realizara por medio de formularios.

Escenario 1: 

El sistema debe presentar un formulario amigable al usuario para el registro de médicos solicitantes y a su vez una tabla donde se pueda visualizar los últimos médicos registrados.

Escenario 2: 

El sistema informara si se está dejando campos del formulario de registro incompletos.

Historia de Usuario

Número: 3

Usuario: Médico

Nombre historia: Administración de historias clínicas Prioridad en negocio: Alta

Riesgo en desarrollo: Alta

Puntos estimados: 10

Iteración asignada: 1

Programador responsable: Alejandro González, Juan Crespo Descripción: Como usuario debo registrar las historias clínicas de acuerdo a los pedidos de los médicos solicitantes. Debo poder visualizar estas historias y debo poder modificar en caso de que alguna información esté mal ingresada. Debe haber una tabla

94

informativa que muestre información de los últimos pedidos. Debe existir la opción de ver las historias que un paciente se ha realizado anteriormente para poder realizar una comparación histórica entre historias del mismo paciente y el mismo tipo de examen.

Observaciones: Al momento de realizar una historia clínica se debe tener la posibilidad de escoger el tipo de estudio por su categoría y subcategoría, y además la posibilidad de ingresar el nombre de estudio directamente.

Escenario 1: 

El sistema debe presentar de forma ordenada un formulario de registro de pedidos, donde se llene información y también se seleccionen los estudios que se deseen realizar.

Escenario 2: 

En el caso que no esté el paciente o médico registrado, el sistema debe facilitar la posibilidad de ingresar pacientes y médicos desde el mismo formulario de registro de pedidos.

Escenario 3: 

Para escoger el tipo de estudio el sistema proporcionara la posibilidad de selección, por su categoría, subcategoría y tipo de estudio que se desee realizar ese pedido.

Escenario 4: 

El sistema facilita la posibilidad de registrar si ese pedido es cortesía, seleccionando la casilla si es el caso, de lo contrario se la dejara vacía.

Escenario 5: 

El sistema deber mostrar los últimos pedidos en una tabla junto al registro.

Escenario 6: 

El sistema irá almacenando de forma ordenada en una tabla de historias clínicas, donde se podrá filtrar la información dependiendo del campo que se desee así como

95

un recuadro de búsquedas avanzadas para encontrar de forma inmediata lo que desee el usuario.

Escenario 7: 

El sistema deberá proporcionar la posibilidad de modificar alguna historia, esto por medio de un botón que re direccionara a una ventana donde se podrá modificar un campo y su conclusión, pudiendo así actualizar datos si es que lo requiera.

Historia de Usuario

Número: 4

Usuario: Médicos

Nombre historia: Impresión de historias clínicas Prioridad en negocio: Alto

Riesgo en desarrollo: Alto

Puntos estimados: 5

Iteración asignada: 2

Programador responsable: Alejandro González, Juan Crespo Descripción: Se debe poder acceder a las historias clínicas e imprimirlas en el formato de Word establecido.

Observaciones: El formato de impresión debe ser de plantillas de Word para cada tipo de estudio. Será necesario descargarse la historia con los datos en formato docx.

Escenario 1: 

En caso se requiera imprimir el documento de la historia clínica del paciente seleccionado el sistema debe presentar de manera inmediata el mecanismo de descarga e impresión del documento donde conste la historia clínica del paciente.

Historia de Usuario Número: 5

Usuario: Médico

Nombre historia: Crear nuevos estudios con plantillas word prediseñadas Prioridad en negocio: Alta

Riesgo en desarrollo: Alto

Puntos estimados: 5

Iteración asignada: 2

96

Programador responsable: Alejandro González Descripción: Se debe tener la posibilidad de agregar las plantillas de word de cada tipo de estudio para así poder crear nuevos tipos de estudios, los cuales serán utilizados posteriormente en los pedidos.

Observaciones: Las plantillas para crear nuevos estudios están en formato de Word (.docx)

Escenario 1: 

El sistema facilitara la agregación de documentos de Word, estas serán las plantillas ya prediseñadas, si en caso se agregó una plantilla con algún campo incorrecto y se desea substituir, el sistema acepta que se suba una plantilla nueva con el mismo nombre del documento a remplazar y este se remplazara de forma automática.

Historia de Usuario Número: 6

Usuario: Administrador

Nombre historia: Generar reportes e imprimirlos Prioridad en negocio: Medio

Riesgo en desarrollo: Medio

Puntos estimados: 6

Iteración asignada: 3

Programador responsable: Alejandro González, Juan Crespo Descripción: Con el fin de sacar conclusiones por periodos de tiempo, se requiere de alguna forma la generación de reportes, respecto a: 

Cortesías (Nombre del paciente y fecha de pedido)



Estudios (Tipo de estudio y cantidad)



Médicos (Nombres de los médicos y los estudios realizados)



Pacientes (Por edad de los pacientes y la cantidad de cada una de estas edades)



Placas desechadas (Tipo de placa y la cantidad)

Observaciones: Para una mejor selección de los reportes, se pondrá un seleccionador de fecha inicio y fecha final para la generación del mismo.

97

Escenario 1: 

El sistema debe facilitar la opción de selección de la fecha de inicio y fecha final del reporte que se desee.

Escenario 2: 

El sistema muestra la información del reporte con una tabla y gráficos, para su fácil comprensión, además de poder enviar a imprimir el documento de manera inmediata.

Historia de Usuario Número: 7

Usuario: Todos

Nombre historia: Administrar cortesías Prioridad en negocio: Baja

Riesgo en desarrollo: Baja

Puntos estimados: 2

Iteración asignada: 3

Programador responsable: Alejandro González, Juan Crespo Descripción: En la sección de pedidos, se requiere registrar si el pedido será realizado como cortesía.

Observaciones: Ninguna.

Escenario 1: 

El sistema facilita la posibilidad de registrar si algún pedido es cortesía, seleccionando la casilla si es el caso, de lo contrario se la dejara vacía.

Historia de Usuario Número: 8

Usuario: Secretario/ Médico

Nombre historia: Registrar placas usadas Prioridad en negocio: Bajo

Riesgo en desarrollo: Bajo

Puntos estimados: 2

Iteración asignada: 3

98

Programador responsable: Alejandro González, Juan Crespo Descripción: Necesito registrar las placas que por alguna razón han tenido que ser desechadas. Se debe registrar el tipo de placa.

Observaciones: Ninguna

Escenario 1: 

El sistema muestra una lista de placas ingresadas, donde le facilitara la selección de alguna de ellas para que se registre como placa desechada.

Historia de Usuario Número: 9

Usuario: Administrador

Nombre historia: Creación de grupos de usuarios y asignación de privilegios Prioridad en negocio: Media

Riesgo en desarrollo: Medio

Puntos estimados: 6

Iteración asignada: 4

Programador responsable: Alejandro González Descripción: En función de administrador debo poder administrar los usuarios del sistema (crear, modificar, eliminar y visualizar) además asignarle un grupo de acceso al sistema que contendrá los privilegios dependiendo del cargo que ocupen en la institución.

Observaciones: Ninguna.

Escenario 1: 

El sistema presentara al administrador, la posibilidad de crear grupos de usuarios y asignarles a cada uno de ellos el privilegio según lo requieran.

Escenario 2: 

El sistema proporcionara la posibilidad de modificar algún campo del usuario si en caso se requiera, además de poder eliminar algún usuario que desee.

99

Historia de Usuario Número: 10

Usuario: Todos

Nombre historia: Acceso de usuario Prioridad en negocio: Media

Riesgo en desarrollo: baja

Puntos estimados: 4

Iteración asignada: 4

Programador responsable: Alejandro González, Juan Crespo Descripción: Se requiere una sección de login para que cada usuario pueda ingresar al sistema Observaciones: Ninguna

Escenario 1: 

El sistema presenta un interface de ingreso al sistema, donde se ingresaran los campos solicitados.

Escenario 2: 

Si se dejan campos vacíos el sistema informara que se deben llenar todos los campos.

Historia de Usuario Número: 11

Usuario: Administrador

Nombre historia: Interfaz para administración Prioridad en negocio: Alta

Riesgo en desarrollo: Alto

Puntos estimados: 10

Iteración asignada: 5

Programador responsable: Alejandro González, Juan Crespo Descripción: Como administrador necesito tener una interfaz que me permita observar todos la información contenida por el sistema. Además poder configurar los valores por defecto que utiliza el programa.

Observaciones: Ninguna.

Escenario 1: 

El sistema presentara un interface de administración completo y fácil de usar, donde podrá observar las historias según acontecimientos de los diferentes campos del sistema.

Escenario 2: 

El sistema proporciona acceso total al sistema, donde el administrador podrá agregar, modificar y eliminar campos que requiera necesarios.

100

Anexo 4: Diccionario de datos Entidad: hcapp_categoria Campo Id Nombre

Descripción: Categoria de los tipos de estudios Tamaño

255

Tipo de dato INTEGER VARCHAR

Descripción Identificador único Identificador de la categoría

Entidad: Descripción: Subcategoria de los tipos de estudios hcapp_subcategoria Campo Tamaño Tipo de Descripción dato INTEGER Identificador único Id 255 VARCHAR Identificador de la subcategoría Nombre INTEGER Categoría a la que pertenece Categoria_id

Entidad: hcapp_tipoestudio Campo Id Nombre Fecha_creacion Subcategoria_id

Entidad: hcapp_historia Campo Id TipoEstudio Fecha_creacion Campo Conclusión Pedido_id

Descripción: Tipo de estudio de las historias clínicas Tamaño

255

Tipo de dato INTEGER VARCHAR DATE INTEGER

Descripción Identificador único Identificador del tipo de estudio Fecha en la que se creó el tipo de estudio Subcategoría a la que pertenece

Descripción: Historia clínica que almacena descripciones de los resultados de los estudios médicos realizados Tamaño Tipo de Descripción dato INTEGER Identificador único 255 VARCHAR El tipo de estudio que es la historia clínica DATE Fecha de creación 255 VARCHAR Contenido alfanumérico de la historia clínica 200 VARCHAR Conclusion INTEGER Pedido al cual pertenece la historia clínica

Entidad: hcapp_placa

Descripción: Registro de placas que se desechan

Campo Id Tipo Fecha

Tamaño

Entidad: hcapp_plantilla Campo Id

Descripción: Plantilla que guarda la estructura e información prediseñada para ser modificada en cada historia clínica Tamaño Tipo de dato Descripción INTEGER Identificador único

255 128

Tipo de dato INTEGER VARCHAR DATE

Descripción Identificador único Formato de la placa Fecha de la placa

101 TEXT

Campo Conclusion NombreDoc

128

DATE INTEGER

Fecha_cracion TipoEstudio_id

Entidad: hcapp_paciente Campo Id Cedula Nombre Apellido Telefono Fecha_nacimiento Fecha_ingreso

VARCHAR INTEGER

Contenido de referencia para la historia clínica.

Conclusión Identificador del archivo que almacena la plantilla Fecha de creación Tipo de estudio al que pertenece la plantilla

Descripción: Paciente al cual se le realizan los estudios Tamaño

128 128

Tipo de dato INTEGER INTEGER VARCHAR VARCHAR INTEGER DATE DATE

Descripción Identificador único Cedula del paciente Nombre del paciente Apellido del paciente Teléfono del paciente Fecha de nacimiento del paciente Fecha en la que se registró en el sistema

Entidad: hcapp_medicosolicitante Campo Id Nombre Apellido Telefono Fecha

Descripción: Médico que solicita que se realice uno o varios estudios Tamaño Tipo de dato Descripción INTEGER Identificador único 128 VARCHAR Nombre 128 VARCHAR Apellido INTEGER Telefono DATE Fecha en la que se registró el médico solicitante

Entidad: hcapp_pedido

Descripción: Pedidos a los cuales pertenecen las historias clínicas Tamaño Tipo de dato Descripción INTEGER Identificador único 255 VARCHAR Diagnostico presuntivo que da el médico que pide el o los estudios BOOL Identificador si el pedido será cobrado como cortesía INTEGER Identificador del médico que solicita el o los estudios INTEGER Identificador del paciente al cual se le realiza el estudio DATE Fecha en la que el médico solicitante creó la orden para crear el o los estudios DATE Fecha en la que se creó el pedido

Campo Id Diagnostico_presuntivo Cortecia Medico_id Paciente_id Fecha_pedido

Fecha

102

Anexo 5: Manual de instalación

Índice A. Requisitos para la implantación del sistema………..……………………………………1022 B. Pasos para la instalación .................................................................................................. 1033 Actualizar el sistema ........................................................................................................ 1033 Instalación de postgresql .................................................................................................. 1033 Creación de usuario y una nueva base de datos para el proyecto. ................................... 1033 Creación de usuario linux ................................................................................................ 1033 Instalar virtualenv y crear un entorno virtual para la aplicación ..................................... 1044 Activar el entorno virtual ................................................................................................. 1044 Instalar las dependencias de la aplicación ....................................................................... 1055 Configurar postgresql para trabajar con django ............................................................... 1055 Configurar la base de datos .............................................................................................. 1066 Sincronizar la base de datos ............................................................................................. 1066 Instalación de servidor http gunicorn ............................................................................... 1066 Configurar servicio .......................................................................................................... 1077 Configurar nginx para servir a gunicorn ........................................................................ 10808 C. Programar respaldos de base de datos ........................................................................... 10909

a. Requisitos para la implantación del sistema 

Sistema operativo: Linux o Unix



Hardware: Dependiendo la carga necesaria para servir a los clientes.



Hardware mínimo estimado: CPU x86 @1 Ghz, RAM 400 MB, HDD 500 MB libres, Conexión LAN Ethernet 10/100

Este manual está realizado y enfocado de acuerdo a las características del sistema actual que dispone la empresa Cedylabe para la instalación del sistema el cual se detalla a continuación: 

CPU: Intel Xeon e3-1220v3



RAM: 16GB



HDD: 5000 GB



NIC: LAN Ethernet Gigabit

103 

b.

SO: Ubuntu 16.02 x64 usuario con privilegios

Pasos para la instalación

A continuación se muestra la serie de pasos a realizar para el despliegue de la aplicación Django en el sistema operativo del servidor. Se proporcionan los comandos para facilitar el copiado y pegado en el terminal y a su vez las capturas de pantalla para que el encargado del despliegue observe las interfaces y las carpetas que son usadas al momento de aplicar los comandos.

Actualizar el sistema sudo apt-get update sudo apt-get upgrade

Instalación de PostgreSQL sudo apt-get install postgresql postgresql-contrib

Creación de usuario y una nueva base de datos para el proyecto.

Creación de usuario Linux Crear un nuevo usuario Linux para limitar los recursos del servidor a la aplicación. Se crea el grupo webapps, se crea el usuario pyuser y se asigna al grupo:

$ sudo groupadd --system webapps $

sudo

useradd

--system

/webapps/hello_django pyuser

--gid

webapps

--shell

/bin/bash

--home

104

Instalar virtualenv y crear un entorno virtual para la aplicación

sudo apt-get install python-virtualenv

Crear un directorio y asignarle el usuario como propietario del mismo.

$ sudo mkdir -p /webapps/proyecto/ $ sudo chown hello /webapps/proyecto/

Crear un entorno virtualenv siendo el usuario Linux anteriormente creado:

$sudo su – pyuser $cd /webapps/proyecto/ virtualenv env

El comando anterior especifica que el entorno virtual se cree utilizando Python 3.5 la versión actual del sistema operativo, recuerde que el sistema trabaja con Python en la versión 3.

Activar el entorno virtual

source env/bin/activate

105

Ahora el entorno está activado y se puede proceder a instalar todas las librerías necesarias para correr la aplicación. Se puede proceder a instalar las librerías mediante el archivo requirements.txt.

Pegar los directorios de los archivos del sistema web en la carpeta de trabajo de la manera que le resulte más fácil.

Instalar las dependencias de la aplicación Mediante pip utilizando el archivo requirements.txt o instalándolas una por una con el comando pip install:

Se puede comprobar que los pasos anteriores fueron correctos si al ejecutar la aplicación en el servidor de desarrollo de Django todo va bien, pruebe el siguiente comando:

Configurar PostgreSQL para trabajar con Django

106 Se debe instalar psycopg2 el cual es el conector de Python con PostgreSQL:

pip install psycopg2

Configurar la base de datos En el archivo settings.py de la aplicaciรณn Django:

DATABASES = { 'default': { 'ENGINE': 'django.db.backends.postgresql_psycopg2', 'NAME': '', 'USER': '', 'PASSWORD': '', 'HOST': 'localhost', 'PORT': '',

# Set to empty string for default.

} }

Sincronizar la base de datos Sincronizar (migrar) la base de datos actual en sqlite hacia la base de datos anteriormente creada en PostgreSQL

python manage.py migrate

Instalaciรณn de servidor HTTP Gunicorn Lo primero serรก instalar gunicorn en el entorno virtual con la herramienta pip:

107

pip install gunicorn

Puede comprobar que gunicorn funciona correctamente con la orden:

gunicorn Proyecto.wsgi:application --bind example.com:8000

Gunicorn estรก ahora instalado y listo para servir su aplicaciรณn.

Configurar servicio

Crea y abre un archivo systemd .service para Gunicorn con privilegios sudo:

sudo nano /etc/systemd/system/gunicorn.service

Configure de acuerdo a los parรกmetros siguientes, dejando www-data como grupo de usuario, ya que este es el grupo en el cual se instalarรก Nginx posteriormente:

gunicorn.conf [Unit] Description= Servicio gunicorn para aplicaciรณn HCAPP After=network.target [Service] User=pyuser Group=www-data WorkingDirectory=/webapps/proyectos/Disertacion/Proyecto

108

ExecStart=/webapps/proyectos/env/bin/gunicorn --access-logfile - --workers 3 --bind unix=/webapps/proyectos/Disertacion/Proyecto/proyecto.sock Proyecto.wsgi:application [Install] WantedBy=multi-user.target

Correr el servicio Gunicorn:

sudo systemctl start gunicorn sudo systemctl enable gunicorn

Chequea si no hay errores en el servicio: sudo systemctl status gunicorn

Si todo estรก bien chequea si se ha creado el archivo .sock en el directorio configurado anteriormente: ls /webapps/proyectos/Disertacion/Proyecto/

Si se realiza alguna modificaciรณn al archivo del servicio .service este debe ser reiniciado: sudo systemctl daemon-reload sudo systemctl restart gunicorn

Configurar Nginx para servir a Gunicorn Crear y abrir un nuevo bloque de servidor en el directorio de sitios disponibles de Nginx:

109

sudo nano /etc/nginx/sites-available/hcapp

Crear un nuevo bloque de servidor:

server { listen 80; server_name dominio_o_IP; location /static/ { root /webapps/proyecto/Disertacion/Proyecto; } location / { include proxy_params; proxy_pass http://unix/webapps/proyecto/Disertacion/Proyecto/proyecto.sock; } }

Guarde y cierre el archivo. Ahora, se habilita el archivo vinculándolo al directorio “sites-enabled”:

sudo ln -s /etc/nginx/sites-available/hcapp /etc/nginx/sites-enabled

Pruebe su configuración de Nginx para detectar errores de sintaxis escribiendo:

sudo nginx -t

Si no se informan errores, reinicie Nginx escribiendo:

sudo systemctl restart nginx

Finalmente puede permitir todos los puertos utilizados:

sudo ufw allow 'Nginx Full'

c.

Programar respaldos de base de datos

Desde el usuario postgres crear un bash para crear copias de seguridad de la base de datos:

110

$ sudo su – postgres ~/resp.bash # respaldar base de datos pg_dump hcappDB > respaldoDB.sql

Modificar el administrador de procesos Crontab y programar una tarea con el siguiente formato de programación.

$ Crontab –e * * * * * /bin/bash /var/lib/postgresql/resp.bash

111

Anexo 6: Manual de usuario

Manual del Usuario Versión 1.0

Sistema informático para la gestión de las historias clínicas en los estudios de imagen médicas del laboratorio clínico Cedylabe.

112

Índice del Manual de Usuario A.Objeto del documento………………………………………...…………………..…….1133 B.Objetivo…………………………………………………………………………………1133 1.Manual de Usuario………………………………………………………………………1133 1.1.Pantalla de inicio……………………………………………….……………………...1133 1.1.1. Área de Ingreso al sistema, para usuarios……………………………………………………………………………...……..1144 1.1.2. Menú principal del sistema……………………………………………………………………………………..1144 1.1.2.1. Inicio ....................................................................................................................... 1144 1.1.2.2. Paciente ................................................................................................................... 1144 1.1.2.2.1. Todos los pacientes .............................................................................................. 1155 1.1.2.3. Pedido ..................................................................................................................... 1165 1.1.2.3.1. Registro de médicos solicitantes. ....................................................................... 11616 Pasos para realizar un pedido. ............................................................................................ 11717 1.1.2.4. Historias medicas ................................................................................................. 11717 1.1.2.4.1. Acceso a las historias: ........................................................................................ 11818 1.1.2.5. Reportes ................................................................................................................ 11919 1.1.2.5.1. Registro de placas ............................................................................................. 11919 1.1.2.6. Subir documento de Word. (historias clinicas) .................................................... 12019 1.1.2.7. Ingreso para la administración de la aplicación web ............................................. 1200 1.1.2.7.1. Administración del sistema .................................................................................. 1200 1.1.2.7.2. Administración de Autenticación y Autorización................................................ 1211 Grupos……………………………………………………………………..………………1211 Usuarios ……………………………………………………………………………..…….1222 Categorías ……………………………………………………………………………..…..1244 Historia ……………………………………………………………………………………1244 Médico solicitante ................................................................................................................ 1255 Pacientes ……………………………………………………………………………..……1255 Pedidos ……………………………………………………………….…………...………..126 Placas …………………………………………………………….……………….…..….12626 Plantillas ……………………………………………………….………………...………12727 Subcategorías ..................................................................................................................... 12827 Tipos de estudio ................................................................................................................. 12828

113

C. Observaciones…………………………………………………………………...……12828 D. Glosario de términos………………………………………………………………….12928

A. Objeto del documento.

El presente documento está destinado al usuario, para encaminarlo al mejor funcionamiento del sistema informático para la gestión de las historias clínicas en los estudios de imagen médicas del laboratorio clínico Cedylabe.

B. Objetivo Pretender mostrar de una manera clara, el funcionamiento del Sistema informático para la gestión de las historias clínicas en los estudios de imagen médicas del laboratorio clínico Cedylabe.

1. Manual de Usuario

1.1. Pantalla de inicio La pantalla de inicio del sistema web muestra una imagen del laboratorio, como bienvenida al usuario, además ofrece las alternativas que se irán mostrando cada una de ellas con sus respectivas funciones.

114

1.1.1. Área de Ingreso al sistema, para usuarios.

En la parte superior en el recuerdo negro, a la derecha inferior, está el ingreso al sistema.

En esta parte de ingresar, se debe ingresar el nombre de usuario y contraseña que se le haya asignado.

1.1.2. Menú principal del sistema Está compuesto de siete partes (botones):

1.1.2.1. Inicio Dando clic izquierdo en este botón, se re direccionara de manera inmediata a la pantalla de inicio.

1.1.2.2. Paciente Si damos clic en el botón

nos llevara al formulario de registro para los pacientes,

además de mostrarnos una tabla con los registros de pacientes más recientes.

115

Para ingresar un paciente al sistema se debe llenar los campos y presionar el botón de crear. 

En la tabla tenemos un botón de modificar , si en caso se ingresó algún dato del paciente de manera incorrecta podemos modificar dando clic en este botón, para que se despliegue el formulario de modificación, en donde ya saldrán algunos datos del paciente seleccionado, procedemos modificar algún campo y damos clic en crear.

1.1.2.2.1.

Todos los pacientes

Si acercamos el cursor al botón pacientes, se despliega otro botón que contiene una tabla general de todos los pacientes: Nota: Si en caso olvido el nombre completo se puede ingresar alguna letra y la tabla ira mostrando todas las referencias acerca de esa letra ingresada.

116 

Se cuenta en la parte superior izquierda, un recuadro de selección, donde podrá escoger la cantidad de registros que dese ver en la tabla.



En la parte inferior derecha se encuentra el recorrido de las páginas si en caso se tienen varias.



En la parte derecha superior esta un recuadro de búsqueda

,

aquí se puede ingresar algún dato del paciente a buscar y la tabla lo mostrara. 

En la tabla tenemos un botón de modificar

, (ver punto 1.1.2.2 registros de pacientes).

1.1.2.3. Pedido En esta parte se muestra el formulario para registrar los pedidos junto con una tabla de los últimos pedidos realizados.

1.1.2.3.1.

Registro de médicos solicitantes.

Se debe llenar el formulario con los datos que pide y presionar en aceptar para ingresar el médico solicitante al sistema.

117

Pasos para realizar un pedido.



Se debe ingresar el nombre del paciente al cual se le va a realizar un pedido, si en caso no se encuentra registrado en el sistema, damos clic en el botón

(símbolo

más), el cual despliega el formulario de registro de pacientes, para que sea registrado. (ver punto 1.1.2.2 registros de pacientes). 

Se debe ingresar el nombre del médico solicitante, el cual va a realizar el pedido, si en caso no se encuentra registrado en el sistema, damos clic en el botón (símbolo más), (ver punto 1.1.2.3.1 registro de médico solicitante)



En la parte de tipos de estudio, según las categorías se debe seleccionar, de igual forma en las sub

categorías y estudio. 

Se debe ingresar el diagnostico.



Si el pedido es una cortesía, deberá marcarse:

, caso contrario se dejara como

esta: 

Ya lleno el formulario se presiona el botón enviar y se almacenara el registro.

1.1.2.4. Historias medicas En el botón Historias se muestra una tabla general de todos los pacientes y sus historias.

118



Se cuenta en la parte superior izquierda, un recuadro de selección, donde podrá escoger la cantidad de registros que dese ver en la tabla.



En la parte inferior derecha se encuentra el recorrido de las páginas si en caso se tienen varias.



En la parte derecha superior esta un recuadro de búsqueda

,

aquí se puede ingresar algún dato del paciente a buscar y la tabla lo mostrara. 

En la tabla tenemos un botón de modificar conclusión de una historia clínica.

1.1.2.4.1. 

Acceso a las historias:

De la tabla seleccionamos un paciente,

, esto para poder modificar el campo o la

119 

Cada paciente tiene al inicio, en su fila h1, h10, h11, h12, h2…… estas son las historias de cada paciente.



Damos clic en la historia del paciente seleccionado. Nos mostrara los campos de dicha historia clínica.



El sistema genera un documento de Word de dicha historia, el cual podemos descargarlo para imprimir. (botón imprimir)

1.1.2.5. Reportes 

En el botón reportes encontramos un pequeño formulario donde ingresamos la fecha desde y hasta donde quiero el reporte.



Luego seleccionamos el tipo de reporte, dando clic en los botones de cortesías, estudios, médicos, pacientes y placas.

1.1.2.5.1.

Registro de placas

Esta parte es para registrar las placas que han sido desechadas, obsoletas.

120

Seleccionamos de la lista de placas

y le damos en el

botón registrar.

1.1.2.6.

Subir documento de Word. (historias clinicas)

En la sexta opción del menú tenemos el botón para subir archivos o los documentos de las historias.

Seleccionamos el archivo de nuestro computador y lo subimos al sistema.

Nota: Si en caso agregamos el archivo mal o con un error, este puede ser remplazado subiendo el archivo correcto con el mismo nombre del archivo antiguo.

1.1.2.7.

Ingreso para la administración de la aplicación web

La última opción es para ingresar al sistema como administrador. El sistema solicitara los permisos de usuario y contraseña para poder ingresar.

1.1.2.7.1.

Administración del sistema

Esta es la ventana principal del administrador.

121

1.1.2.7.2.

Administraci贸n de Autenticaci贸n y Autorizaci贸n

Grupos Si seleccionamos la palabra grupos nos lleva a ver todos los grupos registrados, con opci贸n a modificarlos.

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

122

Ya escrito el nombre tenemos las opciones de guardar y agregar otro, guardar y seguir editando y solo guardar Usuarios Si seleccionamos la palabra usuario nos lleva a ver todos los usuarios registrados, con opción a modificarlos.

Si seleccionamos un usuario podemos ver todo lo relacionado a este: 

Ver el Historial y Modificar los datos del usuario



Modificar la contraseña



Modificar su información personal



Los permisos activos para este usuario



Si pertenece algún grupo de usuarios



Fecha del ultimo ingreso



Fecha de creación de este usuario

123 

Eliminar o guardar algún cambio realizado

Si le damos a agregar contraseña para este nuevo usuario.

nos despliega el formulario, donde se escribe el nombre y

124

En la sección de HCAPP nos muestra:

Categorías Si seleccionamos la palabra categoría podemos ver las existentes, modificar alguna y agregar otra.

Podemos agregar categorías de los estudios que se realizan, escribiendo su nombre

Historias Si seleccionamos la palabra historia, podemos ver las historias creadas, agregar una nueva y modificar alguna ya existente.

125

Médico solicitante Si damos en médico solicitante, podemos ver todos los médicos, además de modificar alguno y crear algún nuevo.

Si le damos a agregar

nos despliega el formulario, donde se escribe la información

requerida para agregar un médico.

Pacientes Si seleccionamos pacientes, nos muestra todos los pacientes en el sistema, donde podemos buscar alguno, modificar o agregar uno nuevo.

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

126

Pedidos Si seleccionamos pedidos podemos ver todos los pedidos realizados, además de modificar alguna historia de algún pedido o agregar uno nuevo.

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

Placas Si le damos en la palabra placas, nos muestran las que ya están registradas, si seleccionamos una podemos eliminarla o modificarla. También nos da la opción de ingresar una nueva.

127

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

Plantillas Si damos en plantillas, podemos ver las que ya estรกn en el sistema ademรกs de poder eliminar alguna modificarla o crear una nueva.

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

128 Subcategorías Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre, se debe

tener en cuenta que primero seleccionamos la categoría a la que pertencese.

Tipos de estudio Si damos en tipo de estudio podemos ver los que en el sistema ya están, modificarlos, eliminar alguno y agregar nuevos tipos de estudios.

Si le damos a agregar

nos despliega el formulario, donde se escribe el nombre y se

seleccionan los permisos disponibles en el sistema.

En la parte superior derecha encontramos el usuario administrador que está ingresado, ver el sitio, cambiar la contraseña y cerrar sesión.

C. Observaciones El sistema, en la parte de administración, en cualquier ingreso, sobre la parte superior derecha, estará un botón encuentra.

, si le damos clic, nos mostrara el historial referente al área en la que se

129

Estos tres botones significan, modificar, agregar y eliminar.

D. Glosario de términos.

Hcapp.- Historia clínica aplicación Staff.- Indica si el usuario puede ingresar a este sitio de administración.