REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE CASO DE …

REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE – CASO DE PRUEBA

SOFTWARE OPEN EMR

CARLOS ALBERTO OSORIO JARAMILLO

Asesor:

Carlos Arturo Castro Castro

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

FACULTAD DE INGENIERÍAS

MEDELLIN

2014

RESUMEN:

El siguiente trabajo plantea una manera de realizar reingeniería sobre un software

Open Source por medio de un método que ayude a realizar una apertura de código,

con el fin de analizar, estudiar y modificar el software a beneficio de las necesidades

del usuario, respetando de esta forma la arquitectura del software y evitando generar

posibles huecos de seguridad en la misma.

PALABRAS CLAVES:

Reingeniería del Software, Software Open Source, Open Emr.

GRUPO INVESTIGACION: Semillero de Investigación en Ingeniería del Software USB

Medellín.

LINEA INVESTIGACION: Ingeniería de Software – SisUSBMed.

AREA: Ingeniería de Software.

TEMA: Reingeniería sobre Software Open Source – Caso de Prueba Software Open

Emr.

REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE – CASO DE PRUEBA

SOFTWARE OPEN EMR

CARLOS ALBERTO OSORIO JARAMILLO

Proyecto presentado para optar al título de ingeniero de sistemas

Asesor:

Carlos Arturo Castro Castro

UNIVERSIDAD DE SAN BUENAVENTURA SECCIONAL MEDELLÍN

FACULTAD DE INGENIERÍAS

INGENIERIA DE SISTEMAS

MEDELLIN

2014

Nota de aceptación

__________________________

__________________________

__________________________

__________________________

__________________________

__________________________

__________________________

Firma del jurado

__________________________

Firma del jurado

Medellín, 18 de Noviembre de 2014

DEDICATORIA

Dedico esta tesis principalmente a Dios todo poderoso, por guiarme siempre por el buen

camino, darme fuerzas cuando sentía que no las tenía y sobre todo por darme sabiduría para

afrontar con valentía y perseverancia todos los obstáculos que se cruzaron en el camino.

Para mis padres por todo el apoyo, consejos, amor, ayuda en los momentos difíciles y por todo

el esfuerzo que hicieron para que yo pudiera estudiar.

A mis hermanas por estar siempre presentes apoyándome incondicionalmente en todas las

decisiones que tomaba en la carrera.

A mi hijo, por ser ese motor que me impulsa a salir adelante, querer superarme siempre y ser

cada día una mejor persona.

AGRADECIMIENTOS

Agradezco a Dios por tantas bendiciones que derramo en mi carrera, quien junto a mi familia,

sembraron una semilla de aliento en mi corazón que permitió encontrar fuerzas en los

momentos más difíciles en mi carrera.

Al Ingeniero Carlos Castro, por ser mi tutor tanto en el proyecto de grado como en el semillero

de investigación, quien a pesar de sus obligaciones siempre tuvo un espacio de tiempo para

encaminar y apoyar mis ideas.

Agradezco a la Universidad de San Buenaventura seccional Medellín y a sus profesores que en

el transcurso de la carrera me ayudaron crecer en sabiduría, en lo personal y con unos

excelentes valores éticos a nivel profesional.

A todas aquellas personas que de una forma u otra colaboraron en conocimiento, empeño y

apoyo para la realización de este trabajo. Muchas gracias

Tabla de contenido 1. JUSTIFICACIÓN ................................................................................................................10

2. PLANTEAMIENTO DEL PROBLEMA ................................................................................11

3. OBJETIVO GENERAL .......................................................................................................12

4. OBJETIVOS ESPECÍFICOS ..............................................................................................13

5. MARCO REFERENCIAL ....................................................................................................14

5.1 Que es Open Source .......................................................................................................14

5.2 Licenciamiento Open Source ...........................................................................................14

5.3 Re-ingeniería de Software ...............................................................................................15

5.3.1 Métodos y modelos de la reingeniería ..........................................................................16

5.3.1.1 Análisis de Opciones para Reingeniería (OAR) ......................................................16

5.3.1.2 El Modelo Herradura ..............................................................................................19

5.3.1.3 Modelo Cíclico de reingeniería ...............................................................................20

5.3.2 Ciclo de vida de RUP ....................................................................................................22

5.3.2.1 Fases del ciclo de vida ...........................................................................................23

5.4 Software OpenEMR .........................................................................................................24

5.5 Doxygen ..........................................................................................................................24

5.6 MySQL WorkBench .........................................................................................................25

5.7 Pencil ..............................................................................................................................25

6. DISEÑO METODOLÓGICO PRELIMINAR ........................................................................26

7. CRONOGRAMA ................................................................................................................29

8. REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE – CASO DE PRUEBA SOFTWARE

OPEN EMR ...............................................................................................................................30

8.1. Ingeniería de requerimientos ..........................................................................................30

8.1.1 Reuniones con Usuarios ...........................................................................................30

8.1.2 Modelado del negocio ...............................................................................................32

8.1.3 Definición de actores .................................................................................................33

8.1.4 Requerimientos funcionales y no funcionales ............................................................34

8.1.5 Análisis de inventario ................................................................................................35

8.1.6 Reestructuración de Documentos .............................................................................36

8.1.7 Ingeniería inversa ......................................................................................................37

8.2. Análisis y diseño .............................................................................................................41

8.2.1.1 Diagramas de Casos de uso y sus definiciones (Representación de casos de uso,

esto está diciendo lo que tiene que hacer el sistema y como). ...........................................41

8.2.1.2 Diagramas de clases ..............................................................................................63

8.2.1.3 Diagramas de secuencia ........................................................................................64

8.2.1.4 Diagrama de despliegue ........................................................................................66

8.2.2 Diseño de la arquitectura del sistema ........................................................................67

8.2.3 Modelamiento Base de Datos ...................................................................................68

Modelo Entidad- Relación. .................................................................................................74

Implementación en motor de base de datos .......................................................................75

8.2.4 Diseño interfaz Gráfica ..............................................................................................76

8.3. Desarrollo .......................................................................................................................86

8.3.1. Reestructuración de Datos .......................................................................................86

8.3.2. Reestructuración de Código .....................................................................................95

8.3.3. Parametrización de la Herramienta Open Emr .........................................................99

8.4 Pruebas y despliegue .................................................................................................... 101

8.4.1 Pruebas de aceptación............................................................................................ 101

9. CONCLUSIONES ............................................................................................................ 116

10. REFERENCIAS BIBLIOGRÁFICAS ............................................................................. 117

11. TABLA DE IMÁGENES ................................................................................................ 118

12. TABLA DE ANEXOS .................................................................................................... 120

1. JUSTIFICACIÓN

Un software Open Source es aquel que puede ser usado libremente, modificado y compartido por

cualquier individuo, su código se encuentra al alcance de cualquier persona sin importar su lugar de

origen, raza o condición. Ofreciendo un mundo de posibilidades como estudio o modificación a criterio de

quien lo necesite para un fin específico, con la única condición de mantener el software bajo la licencia

que cobija el código Open Source [1].

Según la compañía internacional Qindel la tendencia de código Open Source ha tomado mucha fuerza a

nivel internacional en los últimos años, dando como fruto cientos de soluciones para una misma

necesidad, cambiando el pensamiento sobre el valor del Software como un todo, contra el valor de

prestar un servicio sobre lo creado [2], dejando a un lado el verdadero potencial de un Software Open

Source que es la posibilidad de tomar algo ya creado, estudiarlo, modificarlo e innovarlo de acuerdo a las

necesidades del cliente. Esto quiere decir que normalmente la mente maestra tras el software es quien

realiza re-ingeniera para mejorar el producto y no la comunidad que tiene acceso total al código.

Desde el semillero de investigación SisUSBMed se crea el actual proyecto con la finalidad de ayudar a

mitigar la necesidad en la Universidad de San Buenaventura seccional Medellín, en implementar

diferentes soluciones Open Source que ayuden a mejorar los procesos internos, dándole un valor

agregado a los servicios prestados hacia los estudiantes y mejorando el conocimiento sobre patrones de

diseño de re-ingeniería de software. Actualmente se encuentra como caso de estudio y prueba el

software para historias clínicas Open EMR, sobre el cual ya se ha realizado cierta investigación en el

proyecto de grado “Sistema de información Open Source para el Manejo de Historias Clínicas

Electrónicas Universidad de San Buenaventura Medellín [5] que será aprovechado para realizar un

correcto proceso de reingeniería respetando los principios que comprenden un software Open Source.

Este proyecto pretende sacar el máximo provecho a los ítems de la licencia Open Source, con el fin de

realizar un proceso de apertura, estudio y modificación del software Open Emr, evitando de esta manera

tanto re-proceso sobre una solución ya planteada, centrándonos en mejorar e innovar para darle un valor

agregado al software y poder cubrir una necesidad que la Universidad de San Buenaventura tiene

actualmente para el manejo de las historias clínicas.

2. PLANTEAMIENTO DEL PROBLEMA

En estos momentos se podría decir que el software Open Source está en su pleno apogeo, ya que ha

logrado reunir grandes comunidades de desarrolladores a nivel internacional, con el fin crear todo tipo de

soluciones bajo la filosofía de compartir el conocimiento, un pensamiento muy interesante pero a la vez

desperdiciado.

Actualmente se generan o crean cientos de desarrollos bajo licenciamiento Open Source que no tienen

ningún precedente sino que son desarrollados y liberados desde cero, muchas de estas soluciones no

logran sobrepasar su primera versión, ya sea por falta de apoyo, de inspiración o por la triste realidad de

intentar crear lo que ya está creado, mas no intentar mejorar o innovar sobre lo que ya está inventado.

Esto deja a su paso un abismo que genera temor al momento de aplicar un proceso de reingeniería, ya

sea por la falta de conocimiento o metodología que ayude a generar un valor agregado sobre el producto

Open Source.

Este tipo de problemas se presenta en muchos aplicativos, en un caso particular, la necesidad que

presenta actualmente la Universidad de San Buenaventura, la cual consiste en manejar las historias

clínicas de manera electrónica en las diferentes áreas que prestan servicios médicos, psicológicos, entre

otros., debido a lo establecido en la ley 1438 del 2011 que entró en vigencia el 31 de diciembre del 2013,

en la cual establece que la Historia Clínica Única Electrónica será de obligatoria aplicación [6], dicho

problema servirá de experimento en este proyecto.

3. OBJETIVO GENERAL

Implementar un proceso de reingeniería del software sobre Open Emr para obtener un sistema

que permita el manejo de Historias Clínicas en la Universidad de San Buenaventura.

4. OBJETIVOS ESPECÍFICOS

● Especificar requisitos funcionales y no funcionales en el marco de un proceso de

reingeniería del software.

● Analizar y diseñar diagramas correspondientes al sistema de información Open Emr con

el fin de identificar posibles cambios en el proceso.

● Implementar las modificaciones sobre el sistema de información Open Emr con base al

análisis y diseño construido a partir de los requerimientos del usuario.

● Diseñar y aplicar pruebas de aceptación sobre el sistema de información obtenido a

partir del proceso de reingeniería.

5. MARCO REFERENCIAL

5.1 Que es Open Source

Open Source es un software que puede ser usado libremente, cambiado y compartido por cualquier

persona (incluyendo las modificaciones). Open Source es un software creado y distribuido por muchas

personas bajo la licencia que comprende un código Open Source [1].

5.2 Licenciamiento Open Source

El código abierto no sólo significa el acceso al código fuente. Los términos de distribución de software de

código Open Source deben cumplir con los siguientes criterios:

I. Libre distribución: La licencia no debe restringir a un tercero el vender o entregar el programa como

parte de una distribución mayor que contiene programas de diferentes fuentes. La licencia no debe

requerir una regalía y otras comisiones para esta venta.

II. Código Fuente: El programa debe incluir el código fuente, y debe permitir la distribución en código

fuente y en forma compilada. No se permite código fuente deliberadamente ofuscado.

III. Trabajos derivados: La licencia debe permitir modificaciones y trabajos derivados, también debe

permitir que estos se distribuyan bajo los mismos terminas que la licencia del software original.

IV. Integridad del código fuente del autor: La licencia puede requerir que las modificaciones sean

redistribuidas sólo como parches.

V. Sin discriminación de personas o grupos: La licencia no debe discriminar a ninguna persona o grupo

de personas.

VI. Sin discriminación de áreas de iniciativa: La licencia no debe restringir a nadie hacer uno del

programa en un campo específico de actividad.

VII. Distribución de la licencia: Los derechos asociados al programa deben aplicarse a los todos aquellos

a quienes se redistribuye el programa.

VIII. La licencia no debe ser específica de un producto: Los derechos asociados al programa no deben

depender de que el programa forme parte de una distribución de software en particular. Si el programa

se extrae de esa distribución, usado o distribuido dentro de los términos de la licencia del programa,

todas las partes a las que se redistribuye el programa deben tener los mismos derechos que los que se

otorgan en relación con la distribución de software original.

IX. La licencia no debe Restringir Otro Software: La licencia no debe poner restricciones sobre otros

programas que se distribuyan junto con el programa licenciado. Por ejemplo, la licencia no puede insistir

que todos los demás programas distribuidos sobre el mismo medio deben ser software de código abierto.

X. La licencia debe ser tecnológicamente neutral: No debe requerirse la aceptación de la licencia por

medio de un acceso por clic de ratón o de otra forma específica del medio de soporte del software [1].

5.3 Re-ingeniería de Software

“Modificación de un producto software, o de ciertos componentes, usando para el análisis del sistema

existente técnica de Ingeniería Inversa y, para la etapa de reconstrucción, herramientas de Ingeniería

Directa, de tal manera que se oriente este cambio hacia mayores niveles de facilidad en cuanto a

mantenimiento, reutilización, comprensión o evaluación”[3].

A medida que pasa el tiempo, surge la prioridad de moldear el software ya existente a las necesidades

actuales, teniendo esto como consecuencia una serie de parches adicionales sobre el software que bien

o mal realizados, pueden generar una inestabilidad del sistema. Se llegara a un punto en el cual la mejor

forma es realizar el proceso de reingeniería para poder integrar de una manera segura los nuevos

componentes [3].

5.3.1 Métodos y modelos de la reingeniería

Existen varios métodos y modelos que son actualmente utilizados para realizar un proceso de

reingeniería satisfactorio, los cuales se describen brevemente a continuación:

5.3.1.1 Análisis de Opciones para Reingeniería (OAR)

OAR es un método sistemático, de arquitectura central y de toma de decisiones para la identificación y

extracción de componentes dentro de grandes y complejos sistemas de software. La extracción envuelve

rehabilitación de partes de un sistema viejo para su reúso. OAR identifica componentes de arquitectura

potencialmente relevantes y analiza los cambios requeridos para usarlos en una línea de producción de

software o nuevas arquitecturas de software.

En esencia, OAR proporciona un conjunto de opciones de extracción junto con estimación de costos,

esfuerzo y riesgos asociados con estas opciones. El método OAR consiste de cinco actividades

principales con tareas escalables. Esas tareas son representadas en la Figura 1 [7].

Figura 1. Actividades del método OAR [7]

Establecimiento de contexto de extracción (ECE)

En esta fase del modelo se realizan o aplican las diferentes técnicas de extracción de

información a los usuarios, con el fin de obtener los nuevos requerimientos del sistema y otra

información relevante para el desarrollo del proyecto.

Inventario de Componentes (IC)

Luego de llevar a cabo ECE, el equipo debe identificar los componentes del sistema que

potencialmente pueden ser extraídos para ser usados en la nueva arquitectura de software, el

resultado de esta actividad es un inventario de los componentes candidatos. Esta actividad

comprende seis tareas:

1. Identificar características de los componentes necesarios:

● Determinar las características requeridas de los potenciales componentes.

2. Identificar las características satisfactorias de los componentes:

● Crear una tabla de componentes.

● Filtrar los componentes que no cumplen las características

.

3. Comparar las necesidades de los componentes:

● Comparar los componentes.

4. Inventario de los componentes candidatos:

● Actualizar la tabla de componentes.

5. Producir tópicos de extracción:

● Revisar cualquier tópico de extracción.

6. Revisión del calendario OAR:

● Actualizar el calendario de OAR.

Análisis de componentes candidatos (ACC)

Consiste básicamente en analizar el conjunto de componentes que fueron candidatos para

extraer los tipos de cambios que son requeridos. Esta actividad tiene seis tareas:

1. Selección de componentes deseables.

2. Identificar los componentes (Tal como están y de caja negra).

3. Identificar componentes de caja blanca.

4. Determinar cambios requeridos.

5. Producción de tópicos de extracción.

6. Revisar el calendario.

Plan de opciones de extracción (POE).

En esta fase, el equipo debe filtrar nuevamente los componentes que fueron candidatos y

analizar el impacto de agregación de los diferentes componentes. Esta fase tiene siete tareas:

1. Seleccionar componentes favorables.

2. Ejecución de intercambio de componentes.

3. Forma opciones de componentes.

4. Determinar costos comparativos y esfuerzos.

5. Analizar dificultad o riesgo.

6. Producción de tópicos de extracción.

7. Revisar el calendario OAR.

Selección de opciones de extracción (SOE).

Finalmente, los miembros del grupo deben seleccionar la mejor opción para la extracción o

combinación de las opciones para programar y consideraciones técnicas, ellos deben preparar

un informe donde se justifique sus elecciones. SOE tiene cinco actividades:

1. Elegir la mejor opción.

2. Verificar las opciones.

3. Identificar los componentes necesarios satisfechos.

4. Presentación de descubrimientos.

5. Producción de resumen.

Tareas Especializadas

Cada fase también tiene un conjunto de actividades especializadas para direccionar

circunstancias que pueden intervenir en el no cumplimiento de la actividad. Estas tareas pueden

aplicarse bajo las siguientes condiciones:

● El criterio existente.

● Más trabajo puede ser requerido para que la actividad sea razonablemente.

● Se requiere datos adicionales para completar una tarea particular.

5.3.1.2 El Modelo Herradura

Los tres procesos básicos: análisis de un sistema existente, transformación lógica y desarrollo de un

nuevo sistema, forman la base del modelo de herradura. Como puede observarse en la Figura 2, el

primer proceso sube el extremo izquierdo de la herradura, el segundo cruza la parte superior y el tercero

baja por el extremo derecho de la herradura. La riqueza del modelo de herradura son los tres niveles de

abstracción que pueden ser adoptados para las descripciones lógicas. Conceptualmente, este puede ser

a través de un conjunto de herraduras anidadas. Las descripciones lógicas pueden ser artefactos tan

concretos y simples como el código fuente del sistema o tan complejos y abstractos como la arquitectura

del sistema. El propósito de la metáfora visual es para integrar las vistas de reingeniería a nivel de

código y arquitectónico del mundo [11].

Figura 2. El Modelo Herradura [11]

5.3.1.3 Modelo Cíclico de reingeniería

Este modelo de reingeniería define 6 actividades que ayudan a obtener un conocimiento adecuado sobre

la arquitectura de un sistema, en algunos casos estas actividades ocurren en una secuencia lineal, pero

esto no siempre sucede en forma lineal. El paradigma de la reingeniería ilustrado en la Figura 3 es un

modelo cíclico, por lo tanto cada una de las actividades que componen el modelo o secuencia pueden

volver a visitarse, empezar en una actividad diferente a la inicial y terminar en cualquier otra actividad,

todo dependiendo del caso. A continuación se describen las diferentes actividades que componen este

modelo.

Figura 3. Modelo Cíclico [8]

Análisis de inventario: Por organización y mantenimiento, todas las empresas de software deberían de

tener un inventario que abarque todas sus aplicaciones, sin importar que la información de dicho

inventario esté plasmado en una hoja de cálculo. Se debe tener información detallada de todas las

aplicaciones activas, por ejemplo: tamaño, edad, serial, importancia para el negocio, entre otros. Los

candidatos a la reingeniería sobresalen cuando dicha información es organizada en función de su

importancia para el negocio, longevidad, mantenibilidad actual y otros criterios de suma importancia para

la empresa. Luego podremos asignar recursos a las aplicaciones candidatas para realizar el trabajo de

reingeniería [8]. Es de suma importancia resaltar que dicho inventario debe ser revisado con regularidad,

ya que el estado de las aplicaciones puede cambiar con el transcurso del tiempo y, como consecuencia,

cambiarán también las prioridades de la reingeniería.

Reestructuración de documentos: Muchos de los sistemas heredados padecen de una documentación

débil, entonces, ¿Qué podemos hacer al respecto? La creación de los documento consume mucho

tiempo y más cuando no se tienen los recursos necesarios. Es casi imposible volver a crear la

documentación para los miles de programas que tienen cierto tiempo en el mercado y sufren de esta

debilidad, por esta razón si el programa funciona y es relativamente estático, este llegara al final de su

vida útil, y no es probable que experimente muchos cambios. Podemos encontrar casos en donde solo

sea necesario actualizar la información, pero de igual forma consume muchos recursos y tiempo, lo

recomendable es documentar lo que actualmente genera cambios en el sistema. Ahora, si el sistema es

fundamental para el negocio, y es necesario volver a documentarlo por completo, una buena

recomendación consiste en reducir la documentación al mínimo necesario.

Ingeniería inversa: La ingeniería inversa del software es el proceso de análisis y estudio de un

programa con la finalidad de crear un nivel de abstracción del programa mucho más elevado que el

código fuente. La ingeniería inversa extraerá del programa existente información como el diseño de

arquitectura, de procesos e incluso información de los datos.

Reestructuración del código: Realizar esta actividad requiere un trabajo de análisis del código fuente

empleando una herramienta de reestructuración, indicando las violaciones de las estructuras de

programación estructurada y luego se reestructura el código de forma manual o automática. El nuevo

código deberá ser revisado y comprobado para asegurar que no se hayan introducido anomalías. Se

deberá actualizar la documentación interna del código.

Reestructuración de datos: Esta es una actividad de reingeniería a gran escala. En la mayoría de los

casos, dicha actividad empieza con una actividad de ingeniería inversa. La nueva arquitectura de datos

debe ser analizada detalladamente para poder definir los modelos de datos necesarios, identificar los

objetivos de datos y sus atributos, posteriormente se debe revisar la calidad de las estructuras de datos

existentes. Cuando la estructura de datos es débil (se implementan archivos planos, cuando un enfoque

relacional simplificaría muchísimo el procesamiento, entre otros), se aplica una reingeniería de datos.

Dado que la arquitectura de datos tiene una gran influencia sobre la arquitectura del programa y también

sobre sus algoritmos, los distintos cambios en datos dan como consecuencia a cambios de arquitectura

o de código.

Ingeniería directa: La ingeniería directa, que se denomina también renovación o reclamación [8], no

solamente sirve para recuperar la información del diseño de un software, sino que, además, usa dicha

información con el fin de mejorar su calidad global. En la mayoría de los casos, el software resultante de

una reingeniería vuelve a implementar la funcionalidad del sistema existente, pero añadiendo además

nuevas funcionalidades que ayuden a mejorar el rendimiento global.

5.3.2 Ciclo de vida de RUP

El ciclo de vida de RUP se divide en cuatro fases secuenciales, concluyendo cada uno con un producto

intermedio, en donde se realizan varias iteraciones en número variable según el proyecto y sobre las

cuales se hace un mayor o menor hincapié en las distintas disciplinas a realizar en cada fase del

proyecto. Se realizar una evaluación al culminar cada fase con el fin de verificar el cumplimiento o no de

los objetivos de la misma. Las fases son: inicio, elaboración, construcción y transición [9].

Figura 4. Estructura del ciclo de vida RUP [9].

5.3.2.1 Fases del ciclo de vida

Inicio: Esta fase tiene como objetivo general, establecer un acuerdo entre ambas partes o interesados

acerca de los objetivos del proyecto. Esta fase es significativamente primaria para el desarrollo de un

nuevo software, ya que permite la identificación de los riesgos relacionados con el negocio y los

requerimientos. Para los casos de mejora sobre un software existente, esta fase es más corta y es

centrada en asegurar la rentabilidad y posibilidad de desarrollar el proyecto.

Elaboración: En esta fase se define la arquitectura base del sistema, con el fin de proveer bases

estables para el esfuerzo de diseño e implementación de la siguiente fase. Dicha arquitectura debe

abarcar las consideraciones de gran o mayor importancia de los requerimientos y una evaluación del

riesgo.

Construcción: El objetivo de esta fase es poder completar la funcionalidad del sistema, para llegar a

este punto se debe clarificar los requerimientos faltantes, administrar los cambios de acuerdo a las

evaluaciones realizados por los usuarios y completar las mejoras del sistema basados en la arquitectura

base definida en la fase anterior.

Transición: El objetivo principal de esta fase es asegurar la disponibilidad del software a los usuarios

finales, realizar ajustes de posibles errores y defectos encontrados en las pruebas de aceptación. En

este punto, los usuarios deben centrar su atención en la ejecución del producto, las configuraciones,

instalación y manejo del producto. Por último se debe verificar que el producto cumpla con las

especificaciones entregadas por las personas involucradas en el proyecto.

Disciplinas RUP

Una disciplina es un agrupamiento o colección de actividades que se encuentran relacionadas con un

área dentro de todo el proyecto. La principal idea del conjunto de actividades que encontramos dentro de

una disciplina es ser un apoyo para entender el proyecto desde la perspectiva clásica de cascada. A

continuación se describirán las disciplinas.

Modelado de negocio: En esta disciplina se define un modelo con el fin de documentar los

procesos del negocio por medio de los casos de uso de este. Estos casos de uso deben ser

analizados para entender cómo la empresa debe apoyar los procesos de negocio. Muchos

proyectos pueden decidir por no realizar modelos de negocios.

Requerimientos: Esta disciplina tiene como fin el establecer y mantener un acuerdo con los

clientes sobre lo que debe hacer el sistema y definir los límites de este.

Análisis y diseño: La idea del análisis y diseño es poder transformar los requerimientos a

diseños del sistema, con el fin de desarrollar una arquitectura, luego adaptar el diseño para

hacerlo corresponder con el ambiente de implementación y poder ajustarla para un desempeño

esperado.

Implementación: Detalla las distintas actividades con el fin de asegurar que el producto de

software sea asequible para los usuarios finales.

Pruebas: Esta disciplina se enfoca principalmente a la evaluación y aseguramiento de la calidad

del producto.

5.4 Software OpenEMR

OpenEMR es un software libre y de código abierto para el registro electrónico de salud y aplicación de

gestión de la práctica médica que se puede ejecutar en Windows, Linux, Mac OS X, y muchas otras

plataformas. OpenEMR es ONC Complete Ambulatory EHR certified y es uno de los registros

electrónicos de código abierto más populares de medicina hoy en día OpenEMR es apoyado por una

fuerte comunidad de voluntarios y profesionales con el objetivo común de hacer de OpenEMR una

alternativa superior a sus contrapartes propietarias. La comunidad OpenEMR se dedica a la protección

de la condición de OpenEMR como una solución de software de código libre y abierto para las prácticas

médicas y se dedica a mantener un espíritu de apertura, amabilidad y cooperación [1].

5.5 Doxygen

Doxygen es una herramienta estándar para la generación de documentos a partir del código fuente de

los sistemas de información. Esta herramienta soporta una variedad de lenguajes de programación como

lo son: C, Objective, C #, PHP, Java, Python, entre otros. Es una herramienta muy ágil y sencilla de

utilizar, que puede ser combinada con herramientas para diseño gráfico como Graphviz con el fin de

generar diagramas de dependencia, de herencia, entre otros [4].

Por medio de Doxygen se puede realizar lo siguiente:

➢ Se puede generar un documento con archivos HTML, en formato RTF o PDF con hipervínculos a

partir del código fuente del sistema de información.

➢ Se puede configurar Doxygen para que extraiga el código fuente del aplicativo. Esto es muy útil

para desplazarse rápidamente entre los archivos que contienen el código fuente.

5.6 MySQL WorkBench

MySQL WorkBench es una herramienta visual para el modelamiento, desarrollo y administración de

bases de datos, proporciona además herramientas completas de administración sobre la configuración

de servidores, la administración de usuarios, copia de seguridad, entre otros. Este software se encuentra

disponible para las plataformas Windows, Linux y Mac OS X [9].

5.7 Pencil

Pencil es una herramienta libre y de código abierto utilizada para crear maquetas en plataformas de

escritorio de una forma muy sencilla. Pencil soporta sistemas operativos como Linux y Windows [10].

6. DISEÑO METODOLÓGICO PRELIMINAR

Se hará referencia a los flujos de trabajo que se tendrán en cuenta para el desarrollo del proyecto, flujos

de trabajo que están apoyados bajo la integración de la metodología de ingeniería de software RUP y el

modelo cíclico de reingeniería.

El estudio realizado sobre las actividades el Modelo Cíclico nos deja a su paso la necesidad de

implementar junto a dicho modelo una metodología de ingeniería de software como RUP que de apoyo a

las diferentes actividades de la reingeniería con el fin de realizar un análisis y estudio del aplicativo por

medio de la reingeniería para luego ejecutar un proceso de modificación siguiendo en parte el ciclo de

creación de un sistema de información, en donde podemos por medio de los requerimientos obtenidos

por los diferentes medios de captura de información y especificar los módulos que harán parte de la

reingeniería. La integración de las actividades de la metodología RUP y el modelo Cíclico de reingeniería

fue realizada de tal forma que las actividades se puedan apoyar una entre ellas mismas. En el desarrollo

de este documento se podrá observar la forma en que las diferentes actividades están integradas y la

aplicación del resultado obtenido sobre el caso de prueba sobre el sistema de información Open Emr.

● El ciclo de vida de RUP se divide en cuatro fases secuenciales, concluyendo cada uno con un

producto intermedio, en donde se realizan varias iteraciones en número variable según el

proyecto y sobre las cuales se hace un mayor o menor hincapié en las distintas disciplinas a

realizar en cada fase del proyecto. Se realizará una evaluación al culminar cada fase con el fin

de verificar el cumplimiento o no, de los objetivos de la misma. Las fases son: inicio, elaboración,

construcción y transición

● El Modelo Cíclico de reingeniería de software, que es un proceso iterativo de ingeniería del

software que se divide en seis actividades, las cuales permiten conocer y estudiar de forma

organizada, rápida y precisa la estructura del sistema. Dentro del proceso de reingeniería, cabe

destacar que se realizan dos actividades de suma importancia como lo son: la ingeniería inversa

y la ingeniería directa, cuando aplicamos ingeniería inversa se recupera la información necesaria

para conocer y adaptar el sistema, mientras que al aplicar la ingeniería directa, se modela e

implementa la nueva arquitectura.

Flujos de trabajo o fases del proyecto

Fase I - Ingeniería de requerimientos

❏ Levantamiento de requerimientos.

❏ Modelamiento del negocio.

❏ Definición de actores.

❏ Requerimientos (Funcionales y No Funcionales).

❏ Análisis de inventario.

❏ Reestructuración de documentos.

❏ Ingeniería inversa.

Al finalizar esta fase se tendrá un documento donde se especifique las necesidades del usuario y el

alcance mismo del proyecto, se obtendrán las bases para realizar los procesos de reingeniería con el fin

de cumplir con el objetivo general del proyecto.

Fase II - Análisis y Diseño (Transformación de requisitos en un diseño del sistema).

❏ Diagrama de casos de uso y sus especificaciones

❏ Diagrama de clases (Muestra el conjunto de clases, interfaces y relaciones)

❏ Diagramas de secuencia (Muestra la iteración de los objetos que componen un sistema)

❏ Diagrama de despliegue (Implementación del sistema)

❏ Diseño de arquitectura (Arquitectura del sistema)

❏ Base de datos conceptual (Descripción de la información de la base de datos)

❏ Base de datos lógico (Descripción de la estructura de la base de datos)

❏ Base de datos físico (Implementación del modelo de base de datos lógico)

❏ Diseño de interfaces gráficas (Prototipo no funcional sobre diseño de una interface)

Al finalizar esta fase se obtendrá el diseño a satisfacción de las necesidades según análisis y desarrollo

de diagramas con la ayuda de algunos procesos de reingeniería.

Fase III - Desarrollo (Integrar el análisis y modelado arquitectónico de datos con un prototipo de

sistema de información, como valor agregado del proyecto).

❏ Reestructuración de datos (Cambios de estructura en la base de datos)

❏ Versión 1 (Contiene modificación del módulo Datos Demográficos)

❏ Versión 1.1 (Contiene modificación del módulo Historial del paciente)

❏ Reestructuración del código (Cambios o migración de código fuente)

❏ Versión 2 (Contiene la creación del nuevo módulo de Rips)

❏ Versión 2.1 (Parametrización de variables globales y actualización de listas desplegables)

Al finalizar esta fase se tendrá la implementación de los procesos de reingeniería en el sistema Open

Emr.

Fase IV - Pruebas y Despliegues (Pruebas que miden el cumplimiento de los requisitos).

❏ Pruebas de aceptación (Verificación de cumplimiento de requisitos)

❏ Entrega Oficial del Software Open Emr

❏ Entrega de Manual de Usuario

Al finalizar esta fase se tendrá la certificación del sistema de información por parte del usuario.

7. CRONOGRAMA

8. REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE – CASO DE

PRUEBA SOFTWARE OPEN EMR

Para el desarrollo de este proyecto, fue necesario estudiar los diferentes métodos de reingeniería

existentes, con el fin de escoger uno que se acoplara a las necesidades.

Sabiendo que la reingeniería viene muy de la mano con un proceso de ingeniera normal sobre el ciclo de

vida de un software, se realizó una integración entre la Metodología RUP y el Modelo de Reingeniería

Cíclico de tal forma que las actividades se apoyarán una tras de otra y así poder analizar, estudiar y

modificar el código del sistema de información Open Emr de acuerdo a los requerimientos.

8.1. Ingeniería de requerimientos

En esta primera etapa del proyecto, se requiere un trabajo laborioso en la captura de los requerimientos.

Para obtenerlos se es necesario aplicar diferentes métodos de recolección de información con el fin de

crear una lista de requerimientos que será utilizada como punto de partida para la identificación de los

módulos que participarán en el proceso de reingeniería.

A continuación se detallan cada uno de los pasos realizados en la Ingeniería de requerimientos.

8.1.1 Reuniones con Usuarios

En las reuniones con los usuarios se realizaron las siguientes acciones:

● Recolección de información: Para la recolección de información se utilizaron diferentes métodos

como las entrevistas individuales y reuniones grupales, organizando el flujo de trabajo de la

siguiente manera.

Se realizó una reunión grupal en donde se mostró el software en funcionamiento, explicando los

pasos para realizar la captura de una historia clínica. Posteriormente se planificaron reuniones

individuales con las diferentes áreas con el fin de realizar el levantamiento de requerimientos por

cada usuario, como resultado se obtuvo un listado de requerimientos en común que fueron

homologados y presentados en una nueva reunión grupal su aprobación. En el anexo 1 podrá

evidenciar las actas.

Tipo de reunión Fecha Lugar Asistentes Tema tratado

Grupal 23/06/2014 Sala de juntas Asistieron los jefes de las siguientes áreas: CPP, CIAF, Servicio Médico, Neuropsicología y Servicio Psicológico.

Se mostró el funcionamiento del software Open Emr para realizar la captura de una Historia Clínica.

Individual 25/06/2014 Oficina Director CPP

Jefe área CPP Levantamiento de requerimientos de forma individual.

Individual 26/06/2014 Oficina Director CIAF

Jefe área CIAF Levantamiento de requerimientos de forma individual.

Individual 27/06/2014 Oficina Director Servicio Médico

Jefe área Servicio Médico.

Levantamiento de requerimientos de forma individual.

Individual 30/06/2014 Oficina Director Neuropsicología

Jefe área Neuropsicología.


Individual 01/07/2014 Oficina Director Psicológico

Jefe área Servicio Psicológico.


Grupal 03/07/2014 Sala de juntas Asistieron los jefes de las siguientes áreas: CPP, CIAF, Servicio Médico, Neuropsicología y Servicio Psicológico.

Presentación de listados de los requerimientos obtenidos y homologados, aceptación de los mismos.

8.1.2 Modelado del negocio

En la Figura 5 se visualiza el modelo del negocio, siguiendo paso a paso el flujo por el cual un usuario

pide una cita, se valida la existencia de este en el sistema y se captura o no la información de los datos

básicos del usuario para proseguir con la asignación de la cita.

Figura 5. Diagrama - Proceso de Asignación de Cita

8.1.3 Definición de actores

Captura de requisitos como casos de uso: Identificación y definición de actores.

Esta actividad consiste en identificar lo que se debe construir y representarlo en un lenguaje entendible

para el usuario final, con el fin de llegar a un acuerdo. Para esto utilizaremos el lenguaje de modelado

UML como herramienta para modelar los casos de uso.

Identificación de los actores: Un actor es una entidad que realiza el papel de un usuario del sistema. En

pocas palabras, Es todo aquello que no hace parte del sistema pero tiene iteración con este. Cabe

aclarar que los actores no representan a personas físicas o un sistema, sino el papel que desarrolla.

Los usuario son: CPP, CIAF, Servicio Médico, Neuropsicología y Servicio Psicológico. Los cuáles serán

unificados en un solo actor ya que todos los usuarios tienen acceso a los mismos permisos dentro del

sistema Open Emr para la captura de información de historias clínicas. Este usuario genérico será

referenciado como Usuario UDA (Unificación de Áreas).

Tabla 1. Lista de actores

Actor Descripción

UDA Es el encargado del ingreso, modificación y eliminación de los datos que componen una historia clínica para un paciente. Entendiendo como Historia Clínica la captura de información de Datos Demográficos e Historial del paciente como: Historia familiar, información de la pareja, estilo de vida, entre otros.

Administrador El administrador puede realizar el proceso de ingreso, modificación y eliminación de los datos que componen una historia clínica para un paciente. Entendiendo como Historia Clínica la captura de información de Datos Demográficos e Historial del paciente como: Historia familiar, información de la pareja, estilo de vida, entre otros.

8.1.4 Requerimientos funcionales y no funcionales

En el proyecto “Sistema de información Open Source para el Manejo de Historias Clínicas” [5], se

identificaron varios requerimientos funcionales y no funcionales, alguno de ellos serán expresados a

continuación con los nuevos requerimientos extraídos por medio de entrevistas y reuniones grupales con

los clientes. Los requerimientos serán listados con el fin de tomar un punto de partida para la

modificación de los módulos correspondientes de acuerdo a las necesidades y limitaciones que surjan en

el desarrollo del proyecto. A continuación se describen los requisitos encontrados:

Requisitos funcionales.

❏ Gestión de información (crear, modificar y eliminar) en el módulo Datos Demográficos tomando

como base el formato estándar de la Universidad de San Buenaventura llamado “Historia Clínica

Identificación” [5].

❏ Gestión de información (crear, modificar y eliminar) en el módulo Historial del Paciente tomando


Información Socio familiar” [5].

❏ Gestión de información (crear, modificar y eliminar) en el módulo Historial del Paciente tomando


Anamnesis” [5].

❏ Crear un nuevo módulo llamado “Informe Rips”, con el fin de obtener un resumen de las citas

realizadas en un mes específico.

❏ Visualizar información del paciente.

Requisitos no funcionales

❏ Parametrizar las distintas variables del sistema que permita modificaciones como: Título de la

aplicación, color de fondo y de menús, idioma por defecto, asociar el Usuario a las clínicas,

configuraciones del calendario y seguridad en las sesiones del usuario.

❏ Actualizar o crear de ser necesario, listas de despliegue en el sistema ya que este viene con un

grupo de listas estandarizadas para el país de Estados Unidos.

Se especificarán requerimientos necesarios para el desarrollo en software como:

Requerimientos de software

Sistema Operativo Windows o Linux (Ubuntu server, Debian, Centos)

Navegador Web Mozilla Firefox Versión 32.0.

Lenguaje de script PHP Versión 5.4 o superior.

Manejador de bases de datos MySQL.

Apache Web Server Versión 2.4.7., o superior.

Editor de desarrollo Sublime Text.

Doxygen.

WorkBench.

Microsoft Visio 2010.

Requerimientos no funcionales para el software desarrollado

Navegador web (acceso interno a la red de la USB seccional Medellín)

8.1.5 Análisis de inventario

Esta información se compone con los datos básicos de un sistema de información. Toda organización

debe disponer de un inventario ya sea detallado o no, por cada aplicación disponible. Los candidatos a la

reingeniería sobresalen cuando la información es organizada en función de su importancia para la

empresa, la mantenibilidad actual, longevidad y otros criterios relevantes para la empresa.

Es de suprema importancia que esta información esté y sea actualizada al momento de realizar algún

cambio que comprometa la arquitectura del software.

En el inventario datos, para este proyecto, comprende los siguientes datos:

Nombre de la aplicación

Año en que se creó

Tipo de licencia

Lenguaje de programación

Motor de base de datos

Documentación

Calidad de la Documentación

Número estimado de cambios

Tiempo estimado de los cambios

Ítem Descripción

Nombre de la aplicación Open Emr

Año en que se creó 2009

Tipo de licencia Open Source

Lenguaje de programación PHP, JavaScript.

Motor de base de datos MySQL

Documentación Abundante

Calidad de la Documentación Excelente

Número estimado de cambios 6 aproximadamente

Tiempo estimado de los cambios 4 meses

8.1.6 Reestructuración de Documentos

Cuando hablamos de una reestructuración de documentos se debe tener en cuenta si el sistema de

información sufre de una documentación débil o no. Esto debido al poco tiempo y los recursos

disponibles para el desarrollo del proyecto. De ser necesario la reconstrucción de la documentación del

sistema por completo, se aconseja reducir la documentación al mínimo necesario, de lo contrario es

recomendable actualizar la documentación referente a las modificaciones realizadas.

Teniendo en cuenta que el sistema de información Open Emr se encuentra respaldado por una buena

documentación gracias a su comunidad de desarrollo, se procederá actualizar específicamente las

modificaciones realizadas, como también los nuevos módulos generados.

8.1.7 Ingeniería inversa

La reingeniería inversa es un proceso con el cual podemos recuperar el diseño de un sistema. Las

herramientas para ingeniería inversa pueden extraer información referente a los datos, arquitectura y

diseño de los procedimientos de un programa ya existente.

En este proceso se aplicó lo siguiente:

❏ A nivel de código fuente: Se utilizó la herramienta Doxygen [4] con el fin de extraer un

documento que contenga la estructura de los archivos, variables y funciones que componen el

sistema de información Open Emr, de esta forma poder analizar de una manera más sencilla y

ágil el funcionamiento y relación entre los archivos. En la siguiente imagen se visualiza una

captura sobre el documento generado por medio de la herramienta Doxygen.

Figura 6. Imagen Doxygen

En el anexo 2 podrá visualizar la documentación generada por Doxygen.

Específicamente se trabajó sobre los archivos que tienen relación con los requerimientos de los

usuarios, estos son listados a continuación:

Datos Demográficos.

➢ Interface/patient_file/summary/demographics.php: Es el encargado de mostrar

en la interfaz la información referente a los datos demográficos del paciente.

➢ Interface/patient_file/summary/demographics_full.php: Es el encargado de

mostrar en la interfaz los formularios necesarios para actualización de los datos

demográficos del paciente.

➢ Interface/patient_file/summary/demographics_save.php: Es el encargado de

guardar los cambios realizados sobre los datos demográficos del paciente.

Datos Historial Paciente.

➢ Interface/patient_file/history/history.php: Es el encargado de mostrar en la

interfaz la información referente a historial del paciente.

➢ Interface/patient_file/history/history_full.php: Es el encargado de mostrar en la

interfaz los formularios necesarios para actualización del historial del paciente.

➢ Interface/patient_file/history/history_save.php: Es el encargado de guardar los

cambios realizados sobre los datos del historial del paciente.

En las Figuras 7 y 8 podemos visualizar los módulos que serán intervenidos.

Figura 7. Datos Demográficos - Módulo Gestionar Paciente

Figura 8. Historial - Módulo Gestionar Paciente

❏ A nivel de base de datos: Con la ayuda del estudio del código fuente realizado en el paso

anterior, se pudo identificar que los formularios que serán intervenidos para la modificación

respecto a los requerimientos de los usuarios, son generados dinámicamente por medio de unas

consultas dirigidas a la base de datos Open Emr.

A través de la herramienta WorkBench [9] se pudo extraer el modelo de datos del sistema de

información Open Emr como se visualiza una parte en la Figura 9, el cual contiene 171 tablas, en

el anexo 3 podrá visualizar el modelo completo.

Figura 9. Modelo de datos del sistema Open Emr

8.2. Análisis y diseño

El propósito final de esta fase es generar un modelo lógico sobre las modificaciones que serán

realizadas en el sistema de información, es decir, un diseño base de la reingeniería. Teniendo en cuenta

los requisitos no funcionales, los limitantes impuestos por el lenguaje de programación usado por el

sistema, el tipo de interfaz respetando los lineamientos del sistema, entre otros y como punto de partida

para la implementación de las modificaciones, basado en los requisitos identificados en la fase de

requerimientos.

8.2.1.1 Diagramas de Casos de uso y sus definiciones (Representación de casos de

uso, esto está diciendo lo que tiene que hacer el sistema y como).

Figura 10. Diagrama de casos de uso de alto nivel.

Figura 11. Diagrama de caso de uso extendido Gestionar Paciente

Figura 12. Diagrama de caso de uso extendido Gestionar Informes

Figura 13. Relación entre objetos, requisitos de informes y funcionales.

Módulo - Objetos del Sistema

En el módulo Gestionar paciente, se agregaron una serie de campos en los submódulos Datos

Demográficos e Historial Paciente, con el fin de capturar información requerida por la Universidad de San

Buenaventura. En la Figura 6, se visualiza el submódulo Datos Demográficos y en la Figura 7 se

visualiza el submódulo Historial del Paciente, ambos en sus versiones originales.

OBJ - 01 Gestionar paciente

Descripción El sistema deberá gestionar la información (crear, modificar y eliminar) referente al paciente.

Comentarios Todo usuario con acceso al módulo de paciente pueden visualizar la información de datos demográficos e historial del paciente.

OBJ - 02 Gestionar informe

Descripción El sistema deberá gestionar el informe de Rips (consultar y exportar).

Comentarios Cualquier usuario del sistema puede generar el informe.

Requerimientos de información

RI-01-01 Información del paciente.

Objetivos Asociados OBJ - 01

Requisitos Asociados RF-01-01, RF-02-01, RF-02-02, RF-02-03, RF-03-01, RF-03-02, RF-03-03, RF-04-01, RF-04-02, RF-04-03.

Descripción El sistema deberá almacenar información en el módulo Datos Demográficos e Historia del Paciente referente a los formatos “Historia Clínica Identificación”, “Historia

Comentarios No existen comentarios.

RI-02-01 Información de citas


Requisitos Asociados RF-04-01, RF-04-02.

Descripción El sistema deberá generar reportes a partir de los datos guardados en la base de datos.

Comentarios No existen comentarios.

Requerimientos funcionales especificados en casos de uso

RF-01-01 Visualizar Paciente

Caso de Uso Asociado Gestionar Paciente


Requisitos Asociados RI-01-01

Descripción El sistema deberá permitir visualizar información referente al paciente.

Precondición El paciente debe de existir.

Secuencia Normal

ACTOR SISTEMA

1. El caso de uso comienza cuando UDA selecciona la opción Pacientes.

2. El sistema despliega los pacientes existentes en la base de datos, mostrando sus nombres, apellidos, entre otros.

3. UDA selecciona un paciente de la lista.

4. El sistema muestra información sobre los Datos Demográficos del paciente seleccionado.

Postcondición El sistema guarda la información ingresada por UDA.

Excepciones Si el sistema detecta la ausencia de información en algún campo obligatorio, el caso de uso aborta.

Rendimiento

PASO TIEMPO

2 2 SEGUNDOS

Frecuencia 80 diarias

Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.

RF-02-01 Ingreso de información en el módulo Datos Demográficos referenciado al formato “Historia Clínica Identificación”.




Descripción El sistema deberá almacenar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.


Secuencia Normal

ACTOR SISTEMA





5. UDA

selecciona Editar para ingresar información sobre los Datos Demográficos del paciente seleccionado.

6. UDA selecciona Guardar.

7. El sistema guarda la información ingresada.



Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

4 2 SEGUNDOS



RF-02-02 Modificación de información en el módulo Datos Demográficos referenciado al formato “Historia Clínica Identificación”.




Descripción El sistema deberá almacenar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.


Secuencia Normal

ACTOR SISTEMA





5. UDA selecciona Editar para Modificar información sobre los Datos Demográficos del paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

7 3 SEGUNDOS



RF-02-03 Eliminación de información en el módulo Datos Demográficos referenciado al formato “Historia Clínica Identificación”.




Descripción El sistema deberá eliminar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.


Secuencia Normal

ACTOR SISTEMA





5. UDA selecciona Editar para Eliminar información sobre los Datos Demográficos del paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

7 3 SEGUNDOS



RF-03-01 Ingreso de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.




Descripción El sistema deberá almacenar información en el módulo Historial del Paciente referente al formato “Historia Anamnesis”.


Secuencia Normal

ACTOR SISTEMA




4. El sistema muestra información sobre los Datos

Demográficos del paciente seleccionado.

5. UDA selecciona Historial

6. El sistema muestra información sobre el Historial del paciente seleccionado.

7. UDA selecciona Editar para Ingresar información en los respectivos campos del formulario Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-03-02 Modificación de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.




Descripción El sistema deberá modificar la información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.


Secuencia Normal

ACTOR SISTEMA







7. UDA selecciona Editar para Modificar información en los respectivos

campos del formulario Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-03-03 Eliminación de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.




Descripción El sistema deberá eliminar información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.


Secuencia Normal

ACTOR SISTEMA







7. UDA selecciona Editar para Eliminar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-04-01 Ingreso de información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.




Descripción El sistema deberá almacenar información en el módulo Historial del Paciente referente al formato “Información Socio familiar”.


Secuencia Normal

ACTOR SISTEMA







7. UDA selecciona Editar para Ingresar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-04-02 Modificación de información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.

Caso de Uso Asociado



Descripción El sistema deberá modificar la información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.


Secuencia Normal

ACTOR SISTEMA







7. UDA selecciona Editar para Modificar información de los respectivos campos del formulario

Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-04-03 Eliminación de información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.




Descripción El sistema deberá eliminar información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.


Secuencia Normal

ACTOR SISTEMA







7. UDA selecciona Editar para Eliminar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.





Rendimiento

PASO TIEMPO

4 3 SEGUNDOS

6 3 SEGUNDOS

9 3 SEGUNDOS



RF-05-01 Generar informe de Rips basado en la información existente en la base de datos.

Caso de Uso Asociado Generar Informes



Descripción El sistema deberá generar el informe de Rips basado en la información existente en la bases de datos de un periodo específico.

Precondición Debe de existir información en la base de datos

Secuencia Normal

ACTOR SISTEMA

1. El caso de uso comienza cuando UDA selecciona la opción Informes.

2. El sistema muestra los informes disponibles.

3. UDA selecciona Informe Rips.

4. El sistema muestra el encabezado con los filtros para generar el informe de Rips.

5. UDA selecciona los filtros necesarios y da clic en generar.

6. El sistema genera el informe por pantalla con la información correspondiente.

Postcondición El sistema muestra la información correspondiente en la interfaz.

Excepciones Si el sistema detecta la falta de información para generar el reporte, el caso de uso aborta.

Rendimiento

PASO TIEMPO

2 1 SEGUNDOS

4 2 SEGUNDOS

6 3 SEGUNDOS

Frecuencia 3 mensual

Comentarios No existen

RF-05-02 Exportar informe de Rips basado en la información existente en la base de datos.

Caso de Uso Asociado Generar Informes



Descripción El sistema deberá exportar el informe de Rips basado en la información existente en la bases de datos de un periodo específico.

Precondición Debe de existir información en la base de datos

Secuencia Normal

ACTOR SISTEMA

1. El caso de uso comienza cuando UDA

2. El sistema muestra los informes

selecciona la opción Informes.

disponibles.

3. UDA selecciona Informe Rips.

4. El sistema muestra el encabezado con los filtros para generar el informe de Rips.

5. UDA selecciona los filtros necesarios y da clic en generar.

6. El sistema genera el informe por pantalla con la información correspondiente.

7. UDA selecciona exportar informe.

8. El sistema exporta el archivo, mostrando una ventana para guardarlo.

9. UDA guardar el archivo localmente.

Postcondición El sistema muestra la información correspondiente en la interfaz.

Excepciones Si el sistema detecta la falta de información para generar el reporte, el caso de uso aborta.

Rendimiento

PASO TIEMPO

2 1 SEGUNDOS

4 2 SEGUNDOS

6 3 SEGUNDOS

8 3 SEGUNDOS

Frecuencia 3 mensual

Comentarios No existen

8.2.1.2 Diagramas de clases

En el siguiente diagrama de clases se pretende visualizar las relaciones que existen entre las clases que

componen el sistema, las cuales pueden ser asociativas, de herencia, de uso y de contenimiento. Cabe

aclarar que el siguiente diagrama fue generado en el proyecto “Sistema de información Open Source

para el Manejo de Historias Clínicas” [5], el cual fue aprovechado para beneficio del actual proyecto.

Figura 14. Diagrama de Clases Open Emr [5].

8.2.1.3 Diagramas de secuencia

Figura 15. Diagrama de secuencia Paciente

Figura 16. Diagrama de secuencia Informe Rips

8.2.1.4 Diagrama de despliegue

En el siguiente diagrama de despliegue se muestra la arquitectura del sistema desde el punto de vista

del despliegue (distribución) sobre los artefactos del software en los destinos de despliegue. Este

diagrama fue generado en el proyecto “Sistema de información Open Source para el Manejo de Historias

Clínicas” [5], para beneficio del actual proyecto.

Figura 17. Diagrama de despliegue [5].

8.2.2 Diseño de la arquitectura del sistema

En el figura 6 se visualiza el diagrama de la arquitectura del sistema Open Emr en la Universidad de San

Buenaventura seccional Medellín, donde se ilustra la interacción entre los diferentes componentes del

sistema, incluyendo los usuarios.

Figura 18. Arquitectura del Sistema

Los usuarios de las diferentes áreas (Servicio Médico, Servicio Psicológico, Neuropsicología, CPP y

CIAF) acceden a los recursos proporcionados por el sistema de información Open Emr, que se

encuentra alojado en un servidor Linux proporcionado por la Universidad de San Buenaventura.

8.2.3 Modelamiento Base de Datos

8.2.3.1 Base de datos conceptual (Describir la información de la base de datos).

Este flujo de actividades describe la información que se administrará en la Base de Datos. La

información se define como entidades que tienen características descriptivas llamadas atributos.

Definición de Entidades.

Las entidades se registran de cosas que pueden representarse mediante una tabla.

● History_Data

● Patient_Data

● Layout_Options

● List_Options

● User

Definición de Atributos por Entidad:

Debido a la cantidad de los atributos de las Entidades History_data, Patient_Data,

Layout_Options, List_Options y User, solo se mostraran los 10 primeros atributos. En el anexo 5

podrá visualizar sus atributos en totalidad.

Tabla Atributo

History_Data

id

coffee

tobacco

alcohol

sleep_patterns

exercise_patterns

seatbelt_use

counseling

hazardous_activities

recreational_drugs

Tabla Atributo

Patient_Data

id

title

language

financial

fname

lname

mname

DOB

street

postal_code

Tabla Atributo

User

id

username

password

authorized

info

source

fname

mname

lname

federaltaxid

Tabla Atributo

Layout_Options

form_id

field_id

group_name

title

seq

data_type

uor

fld_length

max_length

list_id

Tabla Atributo

List_Options

list_id

option_id

title

Seq

is_default

option_valu

Mapping

Notes

codes

8.2.3.2 Diseño lógico Base de Datos.

El diseño lógico se utiliza para transformar el diseño conceptual en el modelo interno de un

sistema de administración de base de datos.

Definición de entidades y relaciones:

Nombre de Tabla Patient_Data

Descripción Esta tabla contiene todos los datos básicos de un paciente como los datos demográficos.

Campo/Tipo ID/PK

Tabla relación N/A

Campo/Tipo N/A

Nombre de Tabla History_Data

Descripción Esta tabla guarda los datos referente al Historia del paciente,

información sobre la familia, la pareja, los hijos, entre otros.

Campo/Tipo Id/FK

Tabla relación Patient_Data

Campo/Tipo ID/PK

Nombre de Tabla Layout_Options

Descripción Esta tabla se encarga de guardar los atributos de los

formularios que aparecen en el sistema, por ejemplo.

Los formularios de datos Demográficos y sobre el

Historial del paciente.

form_id hace referencia al formulario que pertenece el

campo, por ejemplo. form_id = 'DEM' hace referencia

que el campo pertenece al formulario demográficos.

Campo/Tipo field_id: Este guarda el nombre del campo al que

pertenecen los atributos

Tabla relación Patient_Data

Campo/Tipo Se relaciona con el nombre de cada columna.

Tabla relación List_Options

Campo/Tipo List_id/FK: Si el campo es de tipo desplegable, guarda

el id de la lista, de no serlo será nulo.

Nombre de Tabla List_Options

Descripción Esta tabla almacena todas las listas desplegables que

se muestran en el sistema.

Campo/Tipo list_id/PK

Tabla relación N/A

Campo/Tipo N/A

Nombre de Tabla Users

Descripción Esta tabla almacena los datos básicos de los

usuarios del sistema

Campo/Tipo id/PK

Tabla relación N/A

Campo/Tipo N/A

Modelo Entidad- Relación.

El modelo entidad relación se puede definir como: “la asociación, vinculación o correspondencia

entre entidades.

Figura 19. Modelo Entidad Relación entre las tablas identificadas para el proceso de reingeniería.

Modelo relacional

El modelo relacional se ocupa de tres aspectos principales de la información: la estructura de datos, la manipulación de datos, y la integridad de los datos.” Para hacer una revisión de un modelo relacional es una buena práctica implementar las formas

normales para el diseño de base de datos. Las formas normales se definen como:

Primera forma normal:

Una entidad está en 1FN si cada atributo que la constituye, y que no participa como identificador

de ella, es dependiente fundamental de dicho indicador.

Segunda forma normal:

Una entidad está en 2FN si ya está en 1FN y además si todos los atributos que la constituyen, y

que no participan como identificador, son dependientes fundamentales de la totalidad del

indicador y no de una sola parte de este.

Tercera forma normal:

Una entidad está en 3FN si está en 2FN y si todos los atributos que la componen, y que no

constituyen el identificador, son independientes fundamentales entre sí.

Implementación en motor de base de datos

Se implementa la estructura de la base de datos en el motor de base de datos MySQL por la

conexión eficiente en servidor apache y programación en lenguaje web PHP.

Figura 20. Imagen phpMyAdmin y Apache

En esta imagen se quiere representar la base de datos a utilizar en una implementación bajo la

plataforma phpMyAdmin y motor de base de datos MySQL.

8.2.4 Diseño interfaz Gráfica

La interfaz gráfica es el puente entre el usuario o agente externo y el sistema de información, por lo tanto

esta debe ser lo más flexible y amigable posible, ya que al estar muy saturada de información o de ser

muy complicada de utilizar, no será de agrado para el usuario final. Por estas razones se hace necesaria

la creación de una interfaz que capture la confianza del usuario a través de un sencillo manejo sobre el

sistema, que le permita agilizar sus deberes diarios.

Para el modelado de los diseños de las interfaces se utilizará la herramienta Pencil [10]. Primero se

mostrará una imagen sobre el formulario original, posteriormente se mostrar el prototipo del nuevo

diseño.

Cabe aclarar que se utilizará el diseño de los formularios como se encuentran originalmente, su tipo de

letra, tamaño, color, diseño de pestañas, entre otros., por lo tanto el prototipo no representa un nuevo

diseño, sino la organización de los nuevos campos en las nuevas pestañas necesarias para completar el

proceso de reingeniería.

8.2.4.1 Prototipo Modulo Datos Demográficos

El formulario Datos Demográficos será modificado por la necesidad de capturar información

relevante para la universidad sobre el paciente, el formato base para la homologación es

“Historia Clínica Identificación”. A continuación se visualiza el formulario actual contra el

prototipo.

Figura 21. Formulario Original Pestaña Quién - Datos Demográficos

Figura 22. Formulario Prototipo Pestaña Quién - Datos Demográficos

Figura 23. Formulario Original Pestaña Contacto - Datos Demográficos

Figura 24. Formulario Prototipo Pestaña Contacto - Datos Demográficos

En la Figura 25 podemos visualizar una nueva pestaña llamada “Remitente” a petición del

usuario para una mejor organización de los datos.

Figura 25. Formulario Prototipo Pestaña Remitente - Datos Demográficos

Figura 26. Formulario Original Pestaña Empresa - Datos Demográficos

Figura 27. Formulario Prototipo Pestaña Empresa - Datos Demográficos

En la Figura 28 podemos visualizar una nueva pestaña llamada “Datos Clínicos” a petición del

usuario para una mejor organización de los datos.

Figura 28. Formulario Prototipo Pestaña Empresa - Datos Demográficos

8.2.4.2 Prototipo Modulo Historial Paciente

El formulario Historial del paciente será modificado por la necesidad de capturar información

relevante para la universidad sobre el paciente, los formatos bases para la homologación son

“Historia Clínica Información Socio familiar” y “Historia Clínica Anamnesis”. A continuación se

visualiza el formulario actual contra el prototipo. A continuación se visualiza el formulario actual

contra el prototipo.

En la Figura 29 podemos visualizar una nueva pestaña llamada “Pareja” donde se captura

información sobre la pareja del paciente.

Figura 29. Formulario Prototipo Pestaña Pareja - Historia del Paciente

En la Figura 30 podemos visualizar una nueva pestaña llamada “Hijos” donde se captura información

básica sobre los hijos.

Figura 30. Formulario Prototipo Pestaña Hijos - Historia del Paciente

Figura 31. Formulario Original Pestaña Historia Familiar - Historia del Paciente

Figura 32. Formulario Prototipo Pestaña Historia Familiar - Historia del Paciente

En la Figura 33 podemos visualizar una nueva pestaña llamada “Otros Familiares” donde se

captura información básica sobre familiares.

Figura 33. Formulario Prototipo Pestaña Otros Familiares - Historia del Paciente

8.2.4.3 Modulo Informe Rips

El Informe de Rips es un reporte el cual genera información resumida sobre las citas realizadas

en una fecha específica, tiene la facilidad de filtrar dicha información por medio del centro donde

fue realizada la cita, como también por el profesional u usuario existente en el sistema. En la

Figura 33 se visualiza el formulario prototipo para implementar en el sistema de información

Open Emr.

Figura 34. Formulario Prototipo Informe Rips

8.3. Desarrollo

En esta etapa del proyecto es donde podremos ver los resultados de acuerdo a los requerimientos

obtenidos por medio de diferentes técnicas de recolección de información.

8.3.1. Reestructuración de Datos

En el desarrollo de esta actividad, se analizó la estructura de las tablas que fueron identificadas

para realizar el proceso de reingeniería, sobre estas tablas sólo se modificó su estructura en la

forma de añadir más campos para el proceso de captura de información basado en los formatos

de Historias Clínicas que la Universidad de San Buenaventura utiliza hasta el momento.

Los formularios de Datos Demográficos e Historial Paciente, son creados a partir de unas tablas

en la base de datos, esta información fue obtenida gracias a la reingeniería aplicada, pudiendo

de esta forma analizar y estudiar el código del sistema de información Open Emr.

Debido a la cantidad de campos por tabla, solo se listaran los nuevos campos agregados en

cada tabla, posterior a esto imágenes donde se visualicen los campos en el formulario.

Tabla Atributos Nuevos

Patient_Data

tipodoc

mname

barrio

estrato

nombreremitente

ocupacion

motivoremision

em_horario

escolaridad

vinculado_usb

programa_usb

mot_consulta

mot_consl_actual

mot_consul_ante

metas_terapeu

logros_paciente

phone_cont_relation

em_horario2

A continuación se puede visualizar el módulo de Datos Demográficos con los nuevos campos

que hacen referencia a los formatos establecidos por la Universidad de San Buenaventura.

Figura 35. Módulo Datos Demográficos 01





Tabla Atributos Nuevos

History_Data

history_padre_edad

history_madre_edad

history_padre_ocupa

history_madre_ocupa

history_padre_estado

history_madre_estado

history_hermano_lugar

history_other_fNom1

history_other_fEdad1

history_other_fCivi1

history_other_fProf1

history_other_fNom2




history_other_fNom3




pareja_nombre

pareja_edad

pareja_estado

pareja_hijos

pareja_ocupacion

pareja_vive

pareja_tiempo

pareja_tipo

hijo_edad1

hijo_civi1

hijo_prof1

hijo_nombre1

hijo_hijos

hijo_edad2

hijo_civi2

hijo_prof2

hijo_nombre2

hijo_hijos2

hijo_edad3

hijo_civi3

hijo_prof3

hijo_nombre3

hijo_hijos3

history_bro_name1

history_bro_edad1

history_bro_estado1

history_bro_ocupa1

history_bro_hijos1

history_bro_name2

history_bro_edad2

history_bro_estado2

history_bro_ocupa2

history_bro_hijos2

history_bro_name3

history_bro_edad3

history_bro_estado3

history_bro_ocupa3

history_bro_hijos3

history_bro_name4

history_bro_edad4

history_bro_estado4

history_bro_ocupa4

history_bro_hijos4

actividades_tiempos

trata_psicologicos

trata_actual

En las siguientes imágenes podrá visualizar el módulo de Historial del Paciente con los nuevos campos

que hacen referencia a los formatos establecidos por la Universidad de San Buenaventura.

Figura 40. Módulo Historial del Paciente 01




8.3.2. Reestructuración de Código

En esta fase del proyecto no es necesario implementar una reestructuración del código

específicamente, sino realizar un análisis y estudio del código fuente con la ayuda de la

documentación generada por Doxygen con el fin de poder realizar modificaciones sobre el

código sin afectar u ocasionar huecos de seguridad en la aplicación, respetando de esta forma la

estructura del sistema de información Open Emr. Todo esto fue necesario realizarlo con el

propósito de suplir el requerimiento del usuario sobre un Informe de Rips, el cual debe generar

un resumen sobre las distintas citas realizadas en un rango de fecha específico. Dicho lo

anterior, se tomó como plantilla el código del informe Citas ubicado en el menú como

Informes/Visitas/Visitas, con el fin de resguardar las distintas validaciones y poder mantener la

integridad del código fuente. A continuación se detalla con imágenes los cambios realizados.

- En la Figura 43 se puede visualizar resaltado en la línea 1319, una nueva opción en el

menú de informes llamada Rips. Esta modificación fue realizada sobre el archivo

left_nav.php, ubicado en la dirección interface/main/left_nav.php.

Figura 44. Archivo left_nav.php - Reporte Rips

- En la Figura 44, se puede visualizar el nuevo archivo en la carpeta de reports

llamado rips_report.php. Como se mencionó al principio de esta fase, el archivo

rips_report.php es una plantilla modificada del archivo encounters_report.php

correspondiente al reporte de encuentros del menú informes, con el fin de guardar la

integridad del código y obtener la información deseada. De igual manera se puede

visualizar la cabecera de la tabla con las columnas “Profesional/Usuario - Date -

Paciente - ID del paciente - Resumen Encuentro - Incidencias”, columnas que fueron

alteradas con el fin de generar la información necesaria.

Figura 45. Archivo rips_report.php - Reporte Rips

- En la Figura 46, podemos visualizar el cuerpo del informe, el cual también fue alterado

para obtener la estructura que se muestra en la imagen, y así poder generar la

información de una manera ordenada.

Figura 46. Cuerpo de Informe - Reporte Rips

- En la figura 47 se puede visualizar las modificaciones realizadas sobre el Query del

informe con el fin de obtener las incidencias relacionadas con el paciente y poder ser

mostradas en el informe de Rips generado.

Figura 47. Query - Reporte Rips

- En la Figura 48 podemos visualizar el resultado final sobre el informe de Rips en el

Sistema de Información Open Emr.

Figura 48. Informe Rips en Open Emr

8.3.3. Parametrización de la Herramienta Open Emr

Por políticas de la Universidad de San Buenaventura, es necesario modificar algunos atributos

del sistema de información Open Emr, con el fin de estandarizar la herramienta con el título, logo

de la universidad y estilo de la plantilla.

Por petición de los jefes de área, se escogió el estilo “Style_purple.cc” ofrecido por la

herramienta Open Emr como el estilo principal, por su combinación de colores y tamaño de letras

que este maneja, acoplado en partes con los colores que la Universidad de San Buenaventura

maneja como lo son el Gris y Blanco.

En la Figura 49, se visualiza el sistema de información Open Emr, con el Título y el estilo CSS

aplicado.

Figura 49. Título y Estilo del Sistema de Información Open Emr

En la Figura 50, se visualiza la modificación del formulario de login para el Open Emr, donde se

le agrego el logo de la Universidad de San Buenaventura. Esta modificación fue apoya en el

proceso de reingeniería inversa realizada anteriormente, donde se pudo identificar la ubicación

del logotipo de la aplicación Open Emr, posteriormente se agregó el nuevo logotipo.

Figura 50. Formulario login con logotipo de la Universidad de San Buenaventura

8.4 Pruebas y despliegue

En esta fase se diseñaron pruebas funcionales sobre las modificaciones realizadas en las fases

anteriores, con el fin verificar la satisfacción del cliente con respecto a sus necesidades expresadas al

principio del actual proyecto. Estas pruebas corresponden a un paso a paso sobre el caso de uso,

detallando con evidencias los resultados obtenidos al momento de su ejecución.

8.4.1 Pruebas de aceptación

Las siguientes pruebas fueron realizadas por la Psicóloga Lina María Morales, en representación de las

áreas CPP, CIAF, Servicio Médico y Neuropsicología, con la finalidad de asegurar el cumplimiento de los

requisitos expuestos por el cliente sobre el sistema de información Open Emr.

Estas pruebas están enfocadas a cumplir con los requisitos funcionales especificados en los casos de

uso, los cuales van ligados a los Módulos de Datos Demográficos, Historial Paciente e Informes, por lo

tanto esta fase será partida en tres pruebas donde se detalla paso a paso el comportamiento del sistema

en los módulos anteriormente mencionados, acompañados de imagen como evidencia de las pruebas.

Adicional a esto se mostrará en lo posible los datos ingresados en la base de datos para ratificar las

pruebas realizadas por el usuario.

❏ Módulo Datos Demográficos

En esta prueba se pretende seleccionar un paciente existente en el sistema, con la finalidad de ingresar

sus datos referente al formato “Historia clínica identificación”, el cual se encuentra homologado en el

Módulo Datos Demográficos. Posterior a esto verificar el ingreso en la base de datos para certificar el

almacenamiento de los datos.

1. El usuario UDA da clic en pacientes y visualizar los pacientes registrados en el sistema, como se

visualiza en la siguiente figura.

Figura 51. Lista de pacientes registrados

2. El usuario UDA selecciona el paciente Álvarez, Juan para ingresar información referente a los

formatos “Historia Clínica Identificación”.

Figura 52. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 1



En las siguientes imágenes se visualiza la información ya almacenada en el sistema.

Figura 55. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” # 1



3. A continuación se realizó una búsqueda del paciente al cual se le ingreso la información en el

módulo Datos Demográficos sobre la tabla “Patient_Data”, la sentencia SQL es la siguiente:

SELECT * FROM `Patient_Data` where id = 1

Figura 58. Tabla Patient_Data - Resultados

❏ Módulo Historial Paciente

En el módulo Historial Paciente se realizó la homologación de los formatos “Historia clínica anamnesis” e

“Historia clínica información socio familiar”, por lo tanto en la prueba el Usuario debe seleccionar un

paciente del sistema, dar clic en Historial y posterior ingresar los datos necesarios en los campos

correspondientes. Luego del ingreso de la información, se verifica por medio de la base de datos el

almacenamiento de los datos.

1. El usuario UDA da clic en pacientes y visualizar los pacientes registrados en el sistema, como se

visualiza en la siguiente figura.

Figura 59. Lista de pacientes registrados

2. El usuario UDA selecciona el paciente Robledo, Carlos para ingresar información referente a los

formatos “Historia Clínica Información Socio Familiar” e “Historia Clínica Anamnesis”, esta

información es ingresada en el módulo Historial del Paciente.

Figura 60. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica

Información Socio Familiar # 1.







En las siguientes imágenes se visualiza la información ya almacenada en el sistema.

Figura 64. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica






3. A continuación se realizó una búsqueda del paciente al cual se le ingreso la información en el

módulo Datos Demográficos sobre la tabla “Patient_Data”, la sentencia SQL es la siguiente:

SELECT * FROM `History_Data` WHERE (`history_data`.`id` = 21).

Por la cantidad de campos que se maneja en la tabla History_Data, se mostrarán imágenes

donde se pueda visualizar información que haga referente a la mostrada en las imágenes

anteriores.

Figura 67. Tabla History_Data - Resultados # 1

Figura 68. Tabla History_Data - Resultados # 2

❏ Módulo Informes

En el módulo Informes, se realizó una prueba sobre el nuevo Informe creado llamado “Rips”. Este

informe debe arrojar información resumida sobre las citas atendidas en un rango de fechas determinado.

A Continuación se hacen dos pruebas funcionales, una que genera el informe por pantalla y otro que lo

exporta.

1. El usuario UDA da clic en la opción Informes/Visitas/Rips, posteriormente genera un informe en

un rango de fecha de un mes.

Figura 69. Pantalla principal - Informe Rips

Figura 70. Pantalla principal con información generada - Informe Rips

3. A continuación el usuario exporta el documento y es guardado localmente.

Figura 71. Exportación - Informe Rips

Figura 72. Documento generado - Informe Rips

9. CONCLUSIONES

● El software Open Source es un gran apoyo para el desarrollo de empresas de diferentes

tamaños, evitando invertir grandes cantidades de dineros en un software licenciado, pero

aprovechando la posibilidad de intervenir y modificar un software Open Source de tal manera

que pueda suplir sus necesidades.

● Una de las grandes ventajas de aplicar una reingeniería es el no volver a inventar la rueda sino

innovar sobre lo ya creado pero hacerlo de una manera más eficiente.

● La ejecución de este tipo de proyecto dan un valor agregado a los distintos servicios que la

universidad presta, aprovechando la retroalimentación que existe entre el estudiante y la

universidad, para evitar gastos injustificados en soluciones Open Source y poder invertir

en el beneficio de sus trabajadores y estudiantes.

● Al implementar el software Open EMR en la Universidad de San Buenaventura, muestra el

compromiso que tiene la Universidad por cumplir las leyes establecidas por el gobierno.

10. REFERENCIAS BIBLIOGRÁFICAS

[1] La Open Source Initiative [online], Open source Initiative., Disponible en: http://opensource.org

[2] El éxito del Open Source en la última década [online], Qindel Group., Sede

central, Madrid (España), 2013 Disponible en: http://www.qindel.com/el-exito-del-open-source-

en-la-ultima-decada/

[3] M. Á, Sicilia y V. De la Morena, ¿de Qué es Reingeniería del Software? [online], 10 de

septiembre 2008 Disponible en: http://cnx.org/content/m17438/latest/

[4] Generar la documentación desde el código fuente [online], Doxygen., Disponible en:

http://www.stack.nl/~dimitri/doxygen/

[5] Vanegas, Y (2013). Sistema de información Open Source para el Manejo de Historias Clínicas

Electrónicas Universidad de San Buenaventura Medellín. Proyecto Final de Carrera. Medellín:

Universidad de San Buenaventura Medellín.

[6] Por medio de la cual se reforma el Sistema General de Seguridad Social en Salud y se

dictan otras disposiciones. LEY 1438, 2011.

[7] Bergey, J.1999. “Option Analysis for Reengineering (OAR): Issues and Conceptual Approach”. Pa.:

Software Engineering Institute. Carnegie Mellon University. Pittsburgh.

[8] Pressman. R. 2002 “Ingenieria del software. Un enfoque práctico. “Quinta edición. McGraw Hill.

[9] Gestor de base de datos MySQL [online], WorkBench., Disponible en:

http://www.mysql.com/products/workbench/

[9] Diseño de Maquetas [online], Pencil., Disponible en: http://pencil.evolus.vn/

http://opensource.org/

http://opensource.org/

http://www.qindel.com/el-exito-del-open-source-en-la-ultima-decada/



http://cnx.org/content/m17438/latest/

http://cnx.org/content/m17438/latest/







11. TABLA DE IMÁGENES

Figura 1. Actividades del método OAR.......................................................................................... Página 10

Figura 2. El Modelo Herradura...................................................................................................... Página 13

Figura 3. Modelo Cíclico................................................................................................................ Página 14

Figura 4. Estructura del ciclo de vida RUP.................................................................................... Página 16

Figura 5. Diagrama - Proceso de Asignación de Cita.................................................................... Página 26

Figura 6. Imagen Doxygen............................................................................................................ Página 31

Figura 7. Datos Demográficos - Módulo Gestionar Paciente........................................................ Página 33

Figura 8. Historial - Módulo Gestionar Paciente............................................................................ Página 33

Figura 9. Modelo de datos del sistema Open Emr........................................................................ Página 34

Figura 10. Diagrama de casos de uso de alto nivel. ..................................................................... Página 35

Figura 11. Diagrama de caso de uso extendido Gestionar Paciente............................................ Página 36

Figura 12. Diagrama de caso de uso extendido Gestionar Informes............................................ Página 36

Figura 13. Relación entre objetos, requisitos de informes y funcionales...................................... Página 37

Figura 14. Diagrama de Clases Open Emr [5]. ........................................................................... Página 55

Figura 15. Diagrama de secuencia Paciente................................................................................ Página 56

Figura 16. Diagrama de secuencia Informe Rips.......................................................................... Página 57

Figura 17. Diagrama de despliegue [5]. ....................................................................................... Página 58

Figura 18. Arquitectura del Sistema.............................................................................................. Página 59

Figura 19. Modelo Entidad Relación entre las tablas identificadas para el proceso de reingeniería.

...................................................................................................................................................... Página 66

Figura 20. Imagen phpMyAdmin y Apache................................................................................... Página 67

Figura 21. Formulario Original Pestaña Quién - Datos Demográficos.......................................... Página 68

Figura 22. Formulario Prototipo Pestaña Quién - Datos Demográficos........................................ Página 69

Figura 23. Formulario Original Pestaña Contacto - Datos Demográficos..................................... Página 69

Figura 24. Formulario Prototipo Pestaña Contacto - Datos Demográficos................................... Página 70

Figura 25. Formulario Prototipo Pestaña Remitente - Datos Demográficos................................. Página 71

Figura 26. Formulario Original Pestaña Empresa - Datos Demográficos..................................... Página 71

Figura 27. Formulario Prototipo Pestaña Empresa - Datos Demográficos................................... Página 72

Figura 28. Formulario Prototipo Pestaña Empresa - Datos Demográficos................................... Página 72

Figura 29. Formulario Prototipo Pestaña Pareja - Historia del Paciente........................................Página 73

Figura 30. Formulario Prototipo Pestaña Hijos - Historia del Paciente..........................................Página 74

Figura 31. Formulario Original Pestaña Historia Familiar - Historia del Paciente......................... Página 74

Figura 32. Formulario Prototipo Pestaña Historia Familiar - Historia del Paciente....................... Página 75

Figura 33. Formulario Prototipo Pestaña Otros Familiares - Historia del Paciente....................... Página 76

Figura 34. Formulario Prototipo Informe Rips............................................................................... Página 77

Figura 35. Módulo Datos Demográficos 01................................................................................... Página 79





Figura 40. Módulo Historial del Paciente 01.................................................................................. Página 85




Figura 44. Archivo left_nav.php - Reporte Rips............................................................................. Página 87

Figura 45. Archivo rips_report.php - Reporte Rips....................................................................... Página 88

Figura 46. Cuerpo de Informe - Reporte Rips.............................................................................. Página 89

Figura 47. Query - Reporte Rips.................................................................................................. Página 89

Figura 48. Informe Rips en Open Emr......................................................................................... Página 90

Figura 49. Título y Estilo del Sistema de Información Open Emr................................................. Página 91

Figura 50. Formulario login con logotipo de la Universidad de San Buenaventura...................... Página 92

Figura 51. Lista de pacientes registrados..................................................................................... Página 94

Figura 52. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 1...Página 95



Figura 55. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” #

1............................................................................................................................................ Página 96


2............................................................................................................................................ Página 97


3............................................................................................................................................ Página 97

Figura 58. Tabla Patient_Data - Resultados.............................................................................. Página 98

Figura 59. Lista de pacientes registrados................................................................................ Página 99


Información Socio Familiar # 1. ............................................................................................ Página 100






Información Socio Familiar # 4. ........................................................................................... Página 101







Figura 67. Tabla History_Data - Resultados # 1....................................................................... Página 103

Figura 68. Tabla History_Data - Resultados # 2....................................................................... Página 104

Figura 69. Pantalla principal - Informe Rips............................................................................ Página 105

Figura 70. Pantalla principal con información generada - Informe Rips..................................... Página 106

Figura 71. Exportación - Informe Rips................................................................................... Página 106

Figura 72. Documento generado - Informe Rips...................................................................... Página 107

12. TABLA DE ANEXOS

❏ Anexo # 1 - Actas de reuniones.

❏ Anexo # 2 - Documentación generada por medio de Doxygen.

❏ Anexo # 3 - Modelo relacional extraído de la base de datos de Open Emr.

❏ Anexo # 4 - Formato “Historia Clínica Información”.

❏ Anexo # 5 - Formato “Historia Clínica Anamnesis”.

❏ Anexo # 6 - Formato “Historia Clínica Información Socio Familiar”.

❏ Anexo # 7 - Manual de Usuario: Generar Informe Rips.

Documents

REINGENIERÍA SOBRE SOFTWARE OPEN SOURCE CASO DE …