reingenierÍa sobre software open source caso de …
TRANSCRIPT
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.
Levantamiento de requerimientos de forma individual.
Individual 01/07/2014 Oficina Director Psicológico
Jefe área Servicio Psicológico.
Levantamiento de requerimientos de forma individual.
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
como base el formato estándar de la Universidad de San Buenaventura llamado “Historia Clínica
Información Socio familiar” [5].
❏ Gestión de información (crear, modificar y eliminar) en el módulo Historial del Paciente tomando
como base el formato estándar de la Universidad de San Buenaventura llamado “Historia Clínica
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
Objetivos Asociados OBJ - 02
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
Objetivos Asociados OBJ - 01
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”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá almacenar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.
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.
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.
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
4 3 SEGUNDOS
4 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-02 Modificación de información en el módulo Datos Demográficos referenciado al formato “Historia Clínica Identificación”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá almacenar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.
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.
5. UDA selecciona Editar para Modificar información sobre los Datos Demográficos del paciente seleccionado.
6. UDA selecciona Guardar.
7. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
7 3 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-03 Eliminación de información en el módulo Datos Demográficos referenciado al formato “Historia Clínica Identificación”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá eliminar información en el módulo Datos Demográficos referente al formato “Historia Clínica Identificación”.
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.
5. UDA selecciona Editar para Eliminar información sobre los Datos Demográficos del paciente seleccionado.
6. UDA selecciona Guardar.
7. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
7 3 SEGUNDOS
Frecuencia 10 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-03-01 Ingreso de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá almacenar información en el módulo Historial del Paciente referente al formato “Historia Anamnesis”.
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.
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.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 80 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-03-02 Modificación de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá modificar la información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.
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.
5. UDA selecciona Historial
6. El sistema muestra información sobre el Historial del paciente seleccionado.
7. UDA selecciona Editar para Modificar información en los respectivos
campos del formulario Historial sobre el paciente seleccionado.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 40 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-03-03 Eliminación de información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá eliminar información en el módulo Historial del Paciente referenciado al formato “Historia Anamnesis”.
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.
5. UDA selecciona Historial
6. El sistema muestra información sobre el Historial del paciente seleccionado.
7. UDA selecciona Editar para Eliminar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 10 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-04-01 Ingreso de información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá almacenar información en el módulo Historial del Paciente referente al formato “Información Socio familiar”.
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.
5. UDA selecciona Historial
6. El sistema muestra información sobre el Historial del paciente seleccionado.
7. UDA selecciona Editar para Ingresar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 80 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
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
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá modificar la información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.
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.
5. UDA selecciona Historial
6. El sistema muestra información sobre el Historial del paciente seleccionado.
7. UDA selecciona Editar para Modificar información de los respectivos campos del formulario
Historial sobre el paciente seleccionado.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 40 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-04-03 Eliminación de información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.
Caso de Uso Asociado Gestionar Paciente
Objetivos Asociados OBJ - 01
Requisitos Asociados RI-01-01
Descripción El sistema deberá eliminar información en el módulo Historial del Paciente referenciado al formato “Información Socio familiar”.
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.
5. UDA selecciona Historial
6. El sistema muestra información sobre el Historial del paciente seleccionado.
7. UDA selecciona Editar para Eliminar información de los respectivos campos del formulario Historial sobre el paciente seleccionado.
8. UDA selecciona Guardar.
9. El sistema guarda la información ingresada.
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
4 3 SEGUNDOS
6 3 SEGUNDOS
9 3 SEGUNDOS
Frecuencia 10 diarias
Comentarios El caso de uso solo fue alterado en el número de campos que capturan la información.
RF-05-01 Generar informe de Rips basado en la información existente en la base de datos.
Caso de Uso Asociado Generar Informes
Objetivos Asociados OBJ - 02
Requisitos Asociados RI-02-01
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
Objetivos Asociados OBJ - 02
Requisitos Asociados RI-02-01
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
Figura 36. Módulo Datos Demográficos 02
Figura 37. Módulo Datos Demográficos 03
Figura 38. Módulo Datos Demográficos 04
Figura 39. Módulo Datos Demográficos 05
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_fEdad2
history_other_fCivi2
history_other_fProf2
history_other_fNom3
history_other_fEdad3
history_other_fCivi3
history_other_fProf3
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
Figura 41. Módulo Historial del Paciente 02
Figura 42. Módulo Historial del Paciente 03
Figura 43. Módulo Historial del Paciente 04
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
Figura 53. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 2
Figura 54. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 3
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
Figura 56. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” # 2
Figura 57. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” # 3
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.
Figura 61. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 2.
Figura 62. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 3.
Figura 63. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 4.
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
Información Socio Familiar # 1.
Figura 65. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 2.
Figura 66. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 3.
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/
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 36. Módulo Datos Demográficos 02................................................................................... Página 79
Figura 37. Módulo Datos Demográficos 03................................................................................... Página 80
Figura 38. Módulo Datos Demográficos 04................................................................................... Página 80
Figura 39. Módulo Datos Demográficos 05................................................................................... Página 81
Figura 40. Módulo Historial del Paciente 01.................................................................................. Página 85
Figura 41. Módulo Historial del Paciente 02.................................................................................. Página 85
Figura 42. Módulo Historial del Paciente 03.................................................................................. Página 86
Figura 43. Módulo Historial del Paciente 04.................................................................................. Página 86
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 53. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 2...Página 95
Figura 54. Ingreso datos Demográficos paciente - Formato “Historia Clínica Identificación” # 3...Página 96
Figura 55. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” #
1............................................................................................................................................ Página 96
Figura 56. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” #
2............................................................................................................................................ Página 97
Figura 57. Visualización de datos Demográficos paciente - Formato “Historia Clínica Identificación” #
3............................................................................................................................................ Página 97
Figura 58. Tabla Patient_Data - Resultados.............................................................................. Página 98
Figura 59. Lista de pacientes registrados................................................................................ Página 99
Figura 60. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 1. ............................................................................................ Página 100
Figura 61. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 2. ............................................................................................ Página 100
Figura 62. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 3. ............................................................................................ Página 101
Figura 63. Ingreso Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 4. ........................................................................................... Página 101
Figura 64. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 1. ........................................................................................... Página 102
Figura 65. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 2. ........................................................................................... Página 102
Figura 66. Visualización Historial del paciente - Formatos “Historia Clínica Anamnesis” e “Historia Clínica
Información Socio Familiar # 3. ............................................................................................ Página 103
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.