SISTEMA DE INFORMACIÓN COMPUTARIZADO PARA EL MANEJO DE LA INFORMACIÓN CLÍNICA Y CONTABLE DE LA E.S.E. HOSPITAL LOCAL ARJONA. VIRGILIO JOSÉ POSADA CASTRO OSCAR ENRIQUE PÁJARO CASTRO UNIVERSIDAD TECNOLÓGICA DE BOLÍVAR PROGRAMA DE INGENIERIA DE SISTEMAS CARTAGENA DE INDIAS, D. C Y T. 2004 SISTEMA DE INFORMACIÓN COMPUTARIZADO PARA EL MANEJO DE LA INFORMACIÓN CLÍNICA Y CONTABLE DE LA E.S.E. HOSPITAL LOCAL ARJONA. VIRGILIO JOSÉ POSADA CASTRO OSCAR ENRIQUE PÁJARO CASTRO Monografía para optar el título de Ingeniero de Sistemas Director Ing. ISAAC ZUÑIGA UNIVERSIDAD TECNOLÓGICA DE BOLÍVAR PROGRAMA DE INGENIERIA DE SISTEMAS CARTAGENA DE INDIAS, D. C Y T. 2004 Cartagena, Julio 9 del 2004 Comité de Facultad Universidad Tecnológica de Bolívar L. C. Respetados Señores: Atentamente nos permitimos presentar el siguiente proyecto de Tesis de Grado titulado “Sistema de información computarizado para el manejo de la información clínica y contable de la E.S.E. Hospital Local Arjona.”, el cual se llevará a cabo a través de un equipo interdisciplinario, observando todas las especificaciones técnicas necesarias para su elaboración. La elaboración de dicho proyecto se presenta como requisito para obtener el título de “Ingeniero de Sistemas”. Esperando su apoyo y colaboración Cordialmente, Virgilio José Posada Castro Oscar Enrique Pájaro Castro Cod. 9605044 Cod. 9505536 Cartagena de Indias, Julio 9 del 2004 Señores UNIVERSIDAD TECNOLÓGICA DE BOLÍVAR Atn: Comité de evaluación de Proyectos Facultad de Ingeniería de Sistemas La Ciudad Respetados Señores, Por medio de la presente me permito informarles que he dirigido a los estudiantes VIRGILIO JOSÉ POSADA CASTRO Y OSCAR ENRIQUE PÁJARO CASTRO, en el proyecto de grado titulado: “Sistema de información computarizado para el manejo de la información clínica y contable de la E.S.E. Hospital Local Arjona.”, Presentado como requisito parcial para optar el título de Ingeniero de Sistemas. Agradeciendo la atención prestada. Atentamente, ISAAC ZUÑIGA Ingeniero de Sistemas AUTORIZACIÓN Nosotros, Virgilio José Posada Castro y Oscar Enrrique pájaro Castro identificados con cc. 73560367 y cc. 73558532 de Arjona, respectivamente, Autorizamos a la Universidad Tecnológica de Bolívar para hacer uso de nuestro trabajo de grado y publicarlo en los catálogos ON LINE de la biblioteca. Virgilio José Posada Castro Oscar Enrique Pájaro Castro Cartagena de Indias D. T. y C Julio 9 del 2004 Nota de Aceptación _________________________________ _________________________________ _________________________________ _________________________________ Presidente de Jurado _________________________________ Jurado _________________________________ Jurado Ciudad y Fecha (día, mes, año) A DIOS nuestro señor, por su creación y presencia en mi vida. A Oscar y Vilmaida mis padres, por confiar a ciegas en este sueño y nunca decaer por grande que fuera el obstáculo. A mis hermanos Edwin, Ronald Y Viviana por su compañía y colaboración en los momentos más difíciles. A Mi abuela Mercedes (Q. P. D.) que siempre quiso verme convertido en lo que soy, un profesional Oscar Enrique Pájaro Castro. v A DIOS por darme la oportunidad de ser una persona de bien para la sociedad. A mis padres Virgilio Posada T., y Rafaela L. Castro M., por brindarme su incondicional apoyo y confiar en mi para alcanzar su sueño de tener un hijo profesional. A mis hermanos María A, Francisco J, y Miguel A, por su compañía y apoyo. A la luz de mis ojos, mi hija Delia María por quien no pienso desfallecer para llevarla al punto en que hoy me permitieron llegar mis padres. Virgilio José Posada Castro. vi AGRADECIMIENTOS Los autores expresan sus agradecimientos a: Nuestros Padres. Isaac Zúñiga, Ingeniero de Sistemas y Director de la Investigación, porque nunca tuvo un pero para con la investigación, y dio lo mejor de él para que este fuese un éxito. Gonzalo Garzón, Ingeniero de Sistemas y Director de la facultad, por estar siempre presto a colaborarnos hasta donde su apretada agenda lo permitió. Dr. Alfredo González Hurtado, Dr. Orlando Cogollo Torres, Gerente y Exgerente del Hospital Local Arjona respectivamente, por brindarnos la oportunidad y el apoyo en la realización del proyecto. A todo el personal que labora en la planta física del Hospital por su colaboración e incentivo incondicional en todos los momentos del proceso. vii CONTENIDO Pág. INTRODUCCIÓN 1 1. EL LENGUAJE UNIFICADO DE MODELADO UML 3 1.1. UNIFIELD MODELING LANGUAJE 3 1.2. BLOQUES DE CONSTRUCCION DE UML 4 1.3. ELEMENTOS DE UML 5 1.3.1. Elementos estructurales 6 1.3.1.1. Clases 6 1.3.1.2. Interfaz 6 1.3.1.3. Colaboración 7 1.3.1.4. Caso de uso 7 1.3.1.5. Clase activa 8 1.3.1.6. Componente 8 1.3.1.7. Nodo 9 1.3.2. Elementos de comportamientos 9 1.3.2.1. Interacción 10 1.3.2.2. Máquina de estados 10 1.3.3. Elementos de agrupación 11 1.3.3.1. Paquetes 11 1.3.4. Elementos de anotación 11 1.3.4.1. La Nota. 12 1.4. TIPOS DE RELACIÓN 12 1.4.1. Relación de dependencia. 12 1.4.2. Relación de asociación. 13 1.4.2.1. Nombre 13 1.4.2.2. Rol. 13 1.4.2.3. Multiplicidad. 13 1.4.2.4. Agregación 14 1.4.2.5. Relación de generalización. 15 1.4.2.6. Relación de realización 15 1.5. DIAGRAMAS DE UML 15 1.5.1. Diagrama de clases 16 1.5.2. Diagrama de objetos 17 1.5.3. Diagrama de casos de uso 18 1.5.4. Diagramas de secuencia 19 1.5.5. Diagramas de colaboración 20 1.5.6. Diagramas de estado (STATECHART) 21 1.5.6.1. Estado. 22 1.5.7. Diagrama de actividades 23 1.5.7.1. Bifurcación. 25 1.5.7.2. División y unión 25 1.5.8. Diagrama de componentes 26 1.5.9. Diagrama de despliegue 27 1.6. REGLAS DE UML. 27 1.7. MECANISMOS COMUNES DE UML. 28 1.7.1. Especificaciones. 28 1.7.2. Adornos. 29 1.7.3. Divisiones comunes. 30 1.7.4. Mecanismos de extensibilidad. 31 2. ANÁLISIS DEL SISTEMA DE INFORMACIÓN 33 2.1. RECOLECCIÓN Y TECNICAS DE INFORMACIÓN 33 2.1.1. Fuentes primarias 33 2.1.1.1. Elaboración de entrevistas para el personal de planta del 33 H.L.A 2.1.1.2. Elaboración de entrevistas a pacientes del H.L.A. 34 2.1.1.3. Análisis de entrevistas. 34 2.1.2. Fuentes secundarias. 34 2.2. Consideración de posibles soluciones 35 2.2.1. Modelo de base de datos en Access 35 2.2.2. Modelo de base de datos en MYSQL 36 2.2.3. Modelo de base de datos en POSTGRE SQL 37 2.2.4. Interfase gráfica en Visual Basic 6.0. 38 2.2.5. Interfase gráfica en Delphi 39 2.2.6. Interfase gráfica en Visual C++ 40 2.3. SELECCIÓN Y JUSTIFICACIÓN DE LA SOLUCIÓN 41 3. MODELAMIENTO DEL SISTEMA PROPUESTO PARA EL H.L.A. 42 3.1. DIAGRAMA DE CLASES 43 3.2. DIAGRAMA DE OBJETOS 44 3.3. DIAGRAMA DE CASOS DE USO 1 45 3.4. DIAGRAMA DE CASOS DE USO 2 46 3.5. DIAGRAMAS DE SECUENCIAS 1 47 3.6. DIAGRAMAS DE SECUENCIAS 2 48 3.7. DIAGRAMA DE COLABORACIÓN 49 3.8. DIAGRAMAS DE ESTADOS 1 50 3.9. DIAGRAMAS DE ESTADOS 2 51 3.10. DIAGRAMAS DE ACTIVIDADES “ADMISIÓN” 52 3.11. DIAGRAMAS DE ACTIVIDADES “FACTURACIÓN” 53 3.12. DIAGRAMAS DE ACTIVIDADES “TESORERIA” 54 3.13. DIAGRAMAS DE ACTIVIDADES “CONTABILIDAD” 55 3.14. DIAGRAMAS DE ACTIVIDADES “PRESUPUESTO” 56 3.15. DIAGRAMAS DE ACTIVIDADES “PACIENTES” 57 3.16. DIAGRAMA DE COMPONENTES. 58 3.17. DIAGRAMA DE DESPLIEGUE. 59 4. DISEÑO DE SISTEMA PARA EL H.L.A. 60 4.1. DISEÑO DE SALIDAS 60 4.2. DISEÑO DE ENTRADAS 65 4.3. DISEÑO DE LAS INTERFASES DE USUARIO 67 4.4. DISEÑO DE LA BASE DE DATOS 68 5. IMPLANTACIÓN DEL SISTEMA PARA EL H.L.A. 78 5.1. CONSTRUCCIÓN DEL SISTEMA PARA EL H.L.A. 78 5.2. INSTALACIÓN Y PRUEBA DEL SISTEMA H.L.A. 79 6. SOPORTE DEL SISTEMA 83 6.1. MANTENIMIENTO DEL SISTEMA Y CORRECCIÓN DE 83 ERRORES 6.2. ASISTENCIA AL USUARIO FINAL 85 6.3. MEJORAS Y REINGENIERÍA DEL SISTEMA 86 CONCLUSIONES 87 RECOMENDACIONES 90 BIBLIOGRAFÍA 92 ANEXOS 96 LISTADO DE FIGURAS PÁG. Figura 1. Clase 6 Figura 2. IOrtografía 7 Figura 3. Colaboración 7 Figura 4. Caso de uso. 8 Figura 5. Clase activa. 8 Figura 6. Componente 9 Figura 7. Servidor 9 Figura 8. Interacción 10 Figura 9. Maquina de estado 10 Figura 10. Paquete 11 Figura 11. Nota. 12 Figura 12. Relación de dependencia 12 Figura 13. Multiplicidad 14 Figura 14. Agregación 14 Figura 15. Relación de generalización 15 Figura 16. Relación de realización 15 Figura 17. Diagrama de Clases 17 Figura 18 Diagrama de Objetos 18 Figura 19. Diagrama de casos de Uso 19 Figura 20. Diagrama de secuencia 20 Figura 21 Diagrama de colaboración 21 Figura 22 Diagrama de estado. 23 Figura 23 Diagrama de actividades 24 Figura 24. Diagrama de componentes 26 Figura 25. Diagrama de despliegue 27 Figura 26 Restricciones 32 Figura 27. Diagrama propuesto de clases 43 Figura 28. Diagrama propuesto de objetos 44 Figura 29. Diagrama propuesto de casos de uso 1. 45 Figura 30. Diagrama propuesto de casos de uso 2. 46 Figura 31. Diagrama propuesto de secuencias 1. 47 Figura 32. Diagrama propuesto de secuencias 2. 48 Figura 33. Diagrama propuesto de colaboración 1. 49 Figura 34. Diagrama propuesto de estado 1. 50 Figura 35. Diagrama propuesto de estado 2. 51 Figura 36 Diagrama propuesto de actividades “Admisión”. 52 Figura 37. Diagrama propuesto de actividades “Facturación”. 53 Figura 38. Diagrama propuesto de actividades “Tesorería”. 54 Figura 39. Diagrama propuesto de actividades “Contabilidad”. 55 Figura 40. Diagrama propuesto de actividades “Presupuesto”. 56 Figura 41. Diagrama propuesto de actividades “Pacientes”. 57 Figura 42. Diagrama propuesto de componentes. 58 Figura 43. Diagrama propuesto de despliegue. 59 Figura 44. Diseño de l informe de facturas por turno 62 Figura 45. Informe detallado de ingresos por conceptos 63 Figura 46. Informe de cuentas por cobrar a empresas 64 Figura 47. Informe general de cuentas por cobrar 65 LISTADO DE CUADROS PÁG. Cuadro 1. Usuario 68 Cuadro 2. Utensilios 69 Cuadro 3. Proveedores 70 Cuadro 4. Personal 71 Cuadro 5. Paciente 72 Cuadro 6. Historial 74 Cuadro 7. Servicios 75 Cuadro 8. Cuentas por cobrar 76 Cuadro 9. Cuentas por pagar 77 RESUMEN El Hospital Local Arjona es una Empresa Social del Estado, que presta sus servicios a la comunidad en general desde el año 1972, fecha en la cual fue fundado. En la actualidad, el Hospital cuenta con os servicios de medicina general y especializada, odontología, laboratorio clínico, sala de parto, cirugía, vacunación, control prenatal y fisioterapia, entre otros. Actualmente, El H.L.A. está conformado estructuralmente por las dependencias de Admisión, Facturación, Servicios, Tesorería, Contabilidad, Presupuesto y Gerencia, entre otras, Siendo las aquí mencionadas, objeto de estudio para nuestro proyecto. El sistema comienza a recibir información a partir de instante en que una persona llegue a la dependencia de admisiones solicitando un servicio, si el paciente es admitido, se procede a enviar la información al departamento de facturación, donde el paciente o acompañante debe cancelar el valor correspondiente; simultáneamente, se presta el o los servicios al paciente y la información de facturación llega a tesorería, de donde posteriormente se hace llegar al viii departamento de presupuesto el cual realiza la correspondiente descarga al presupuesto anual. Al final de la jornada administrativa, el asistente de tesorería recibe por parte de departamento de facturación, las respectivas copias de los recibos emitidos durante la actual jornada, y el dinero correspondiente para luego ser consignado y hacer llegar copia de la consignación a contabilidad para realizar los asientos respectivos. Por su parte, la gerencia recibirá reportes periódicamente, o cronológicos en caso de que se requieran, ya que la información se encuentra registrada en la base de datos. Los reportes serán elaborados en el departamento de facturación los días 1 y 15 de cada mes, y por petición de la gerencia en el momento en que se requiera. El software consta básicamente de 5 módulos con usuarios registrados, los cuales podrán acceder única y exclusivamente al módulo para el cual se encuentran autorizados, y para ello deberán identificarse con su login y password. En el capitulo inicial se hace un breve pero sustancioso resumen acerca de el Lenguaje Unificado de Modelado (U.M.L.), especificando los elementos, relaciones ix y diagramas con los cuales se realizan los modelamientos que anteceden al diseño de sistemas de información. En la segunda sección se especifican las técnicas de recolección de información así como las fuentes y formatos a través de los cuales se obtuvo la información. Esto, seguido del análisis de las entrevistas y su respectiva lluvia de ideas, las cuales generan un pequeño listado de posibles soluciones las cuales son analizadas con detenimiento, para finalizar en la selección y sustentación de la solución más adecuada. La tercera unidad está dedicada al modelamiento del sistema propuesto, siendo el modelamiento del sistema actual un anexo en el CD adjunto a este documento. U.M.L. trabaja con 9 diferentes diagramas, los cuales se encargan de ampliar un poco más los tradicionales modelamientos de datos, procesos y redes, siendo mas eficiente el modelamiento generado. Basados en las unidades anteriores, procedemos a realizar los diseños de salidas, entradas, interfaces con los usuarios y base de datos, los cuales están especificados con detenimiento en la cuarta unidad. El capitulo quinto esta dedicado a la construcción, instalación, entorno de prueba y puesta en marcha de sistema desarrollado. Para finalizar este documento, se creó x una sexta unidad denominada soporte del sistema, en la cual se tiene en cuenta algunos aspectos poco usuales pero que nunca dejan de presentarse en un sistema de información como lo es presencia y corrección de errores, y consejos para aprovechar al máximo el sistema. Todo esto acompañado de pequeños consejos que podrían ser muy útiles al momento de implementar reingeniería. xi INTRODUCCIÓN Actualmente las empresas cualquiera que fuese su tamaño, realizan operaciones computacionales a cada momento, esto implica tener a su alcance un equipo computacional que reúna las condiciones necesarias para realizar dicha tarea y junto a esto un software que realice en forma eficiente las tareas encomendadas. De aquí la importancia del desarrollo de Software de alta calidad y junto a esto la formación de unos excelentes Ingenieros de Sistemas. Este problema no se limita únicamente a realizar programas de computador, es todo un proceso de desarrollo de proyectos de información, con manejo de presupuestos, tiempo y etapas por cumplir. Por eso aprovechamos la confianza que depositaron en nosotros la E.S.E. HOSPITAL LOCAL ARJONA para demostrar todas nuestras fortalezas en el Análisis y Desarrollo de Sistemas de Información con Calidad. El proceso de realizar Sistemas de Calidad no es fácil, primero se debe cambiar la mentalidad de que para programar hay que sentarse frente a un computador y empezar a escribir código, por la de pensar en tomar papel y lápiz e invertir mucho más tiempo en realizar un buen diseño, y gastar menos tiempo en la etapa de desarrollo. Quisimos resumir en este documento lo más importante del Proyecto de Software que realizamos, para que sirva como ejemplo para futuros Proyectos de Software. Esperamos que sea de su total interés y que llene todas las expectativas planteadas para con él. 2 1. EL LENGUAJE UNIFICADO DE MODELADO 1.1. UNIFIELD MODELING LANGUAJE El Lenguaje de Modelado Unificado (UML) es la sucesión de una serie de métodos de análisis y diseño orientadas a objetos que aparecen a fines de los 80's y principios de los 90s. Directamente unifica los métodos de Booch, Rumbaugh (OMT), y Jacobs, y algo más. UML es llamado un lenguaje de modelado, no un método. Los métodos consisten de un lenguaje de modelado y de un p roceso.* El lenguaje de modelado es la notación (principalmente gráfica) para visualizar, especificar y documentar cada una de las partes que comprende el desarrollo de software. UML entrega una forma de modelar cosas conceptuales como lo son procesos de negocio y funciones de sistema, además de cosas concretas como lo so*Lne negsucarjeib Uirn icfilcaasdeo sd ee Mn oudnel aldeon gUuMaLj e determinado, esquemas de base de datos y Booch, Grady. Rumbauch, James co mMapdornide nEtsepsa ñad, e2 00s0o.f t wAaddreis onre Wuessalbeyle Esd. itio nL a estandarización de un lenguaje de modelado es invaluable, ya que es la parte principal de comunicación. Si se quiere discutir un diseño con alguien más, ambos deben conocer el lenguaje de modelado y no así el proceso que se siguió para obtenerlo. Para comprender UML, se necesita adquirir un modelo conceptual del lenguaje, y esto requiere aprender tres elementos principales: Los bloques básicos de construcción de UML, las reglas que dictan como se pueden combinar estos bloques básicos y algunos mecanismos comunes que se aplican a través de UML. Una vez comprendas estas ideas, se pueden leer los modelos UML y crear algunos modelos básicos. Conforme se pueden leer modelos UML y crear algunos modelos básicos. Se gana más experiencia en la aplicación de UML, se puede edificar sobre este modelo conceptual, utilizando características mas avanzadas del lenguaje. 1.2. BLOQUES DE CONSTRUCCIÓN DE UML. En UML, un bloque de construcción es un diagrama que muestra los diferentes tipos de elementos que participan del modelo, con sus respectivas relaciones. El vocabulario UML inc luye tres clases de bloques de construcción: Ø Elementos. Ø Relaciones. Ø Diagramas. Los elementos son abstracciones que son ciudadanos de primera clase en un modelo; las relaciones ligan estos elementos entre sí; los diagramas agrupan colecciones interesantes de elementos. 1.3. ELEMENTOS DE UML Hay cuatro tipos de elementos en UML: 1. Elementos estructurales. 2. Elementos de comportamiento. 3. Elementos de agrupación. 4. Elementos de anotación. Estos elementos son los bloques básicos de construcción orientados a objetos de UML. Se utilizan para escribir modelos bien formados. 1.3.1. Elementos estructurales Son los nombres de los modelos UML. En su mayoría son las partes estáticas de un modelo, y representan cosas que son conceptuales o materiales. En total, existen siete tipos. 1.3.1.1. Clase: Es una descripción de un grupo de objetos que comparten los mismos atributos, operaciones, relaciones y semántica. Una clase se representa como un rectángulo que normal mente incluye su nombre, atributos y operaciones. Ventana Nombre Origen tamaño Atributos Abrir () Cerrar () Mover () Operaciones Dibujar () Res ponsab ilidad Fig 1. Clase 1.3.1.2. Interfaz: Es una colección de operaciones que especifican un servicio de una clase o componente. Por lo tanto, una interfaz describe el comportamiento visible externamente de ese elemento. También puede representar el comportamiento de una clase o componente o solo una parte de ese comportamiento. Una interfaz define un conjunto de especificaciones de operaciones (o sea, sus signaturas), pero nunca un conjunto de implementaciones de operaciones. Gráficamente se representa como un círculo junto a su nombre. Fig 2: IOrtografía 1.3.1.3. Colaboración: Define una interacción y es una sociedad de roles y otros elementos que colaboran para proporcionar un comportamiento cooperativo mayor que la suma de los comportamientos de sus elementos Gráficamente se representa como una elipse de borde discontinuo, incluyendo normalmente sólo su nombre. Cadena de responsabilidad Fig 3. Colaboración 1.3.1.4. Caso de uso: Es una descripción de un conjunto de secuencias de acciones que un sistema ejecuta y que produce un resultado observable de interés para un actor particular. Un caso de uso se utiliza para estructurar los aspectos de comportamiento en un modelo, Gráficamente se representa por una elipse de borde continuo, incluyendo normalmente sólo su nombre. Realizar pedido Fig 4. Caso de uso 1.3.1.5. Clase activa: Es una clase cuyos objetos tienen uno o más procesos o hilos de ejecución y por lo tanto pueden dar origen a actividades de control. Una clase activa es igual a una clase, excepto que sus objetos representan elementos cuyo comportamiento es concurrente con otros elementos. Gráficamente, se representa como una clase, pero con líneas más gruesas. Gestor Eventos Suspender () VaciarCola () Fig 5. Clase activa 1.3.1.6. Componente: Es una parte física irreemplazable de un sistema que conforma con un conjunto de interfaces y proporciona la implementación de dicho conjunto Gráficamente, un componente se representa como un rectángulo con pestañas, incluyendo normalmente sólo su nombre. Ordenform . java Fig 6. Componente 1.3.1.7. Nodo: Es un elemento físico que existe en tiempo de ejecución y representa un recurso computacional, que por lo general dispone de algo de memoria y, con frecuencia, capacidad de procesamiento. Gráficamente se representa como un cubo incluyendo normalmente su nombre. Servidor Fig 7. Servidor 1.3.2. Elementos de comportamiento Son las partes dinámicas de los modelos UML. Estos son los verbos de un modelo y representan comportamiento en el tiempo y el espacio. Estos elementos son: 1.3.2.1. Interacción: Involucra muchos otros elementos, incluyendo mensajes, secuencias de acción y enlaces. Gráficamente se muestra como una línea dirigida incluyendo casi siempre el nombre de su operación. Dibujar Fig 8. Interacción 1.3.2.2. Máquina de estados: El comportamiento de una clase individual o una colaboración de clases puede especificarse como una máquina de estados. Una máquina de estado involucra a otros elementos, incluyendo estados, transiciones, eventos, y actividades. Gráficamente, se representa como un rectángulo de esquinas redondeadas, incluyendo normalmente su nombre y sus subestados, si los tiene. Esperando Fig 9. Maquina de estado 1.3.3. Elementos de agrupación Es la parte organizativa de los modelos UML. Estos son las cajas en las que puede descomponerse un modelo. 1.3.3.1. Paquetes: Es un mecanismo de propósito general para organizar elementos en grupos. Los elementos estructurales, los elementos de comportamiento, e incluso otros elementos de agrupación pueden incluirse en un paquete. Gráficamente un paquete se visualiza como una carpeta, incluyendo normalmente sólo su nombre y, a veces, su contenido. Reglas del negocio Fig 10. Paquete 1.3.4. Elementos de anotación Son las partes explicativas de los modelos. Son comentarios que se pueden aplicar para describir, clarificar, y hacer observaciones sobre cualquier elemento de un modelo. 1.3.4.1. La Nota: Es simplemente un símbolo para mostrar restricciones y comentarios junto a un elemento o una colección de elementos. Una nota se representa como un rectángulo con una esquina doblada junto con un comentario textual o gráfico. Devuelve una copia del objeto receptor Fig 11. Nota 1.4. TIPOS DE RELACIONES. 1.4.1. Relación de dependencia: Es una relación semántica entre dos elementos, en la cual un cambio a un elemento puede afectar la semántica del otro elemento. Se representa como una línea discontinua posiblemente dirigida. Fig 12. Relación de dependencia 1.4.2. Relación de asociación: Es una relación estructural que describe un conjunto de enlaces los cuales son conexiones entre objetos. La agregación es un tipo especial de asociaciones que representa como una línea continua, posiblemente dirigida, que incluye una etiqueta, y a menudo incluye otros adornos, como la multiplicidad y los nombres de rol. 1.4.2.1. Nombre. Una asociación puede tener un nombre, que se utiliza para describir la naturaleza de la relación. Para que no halla ambigüedad en su significado. 1.4.2.2. Rol. Cuando una clase participa en una asociación, tiene un rol específico que juega en la asociación; un roles simplemente la cara que la clase de un extremo de la asociación presenta a la clase del otro extremo. 1.4.2.3. Multiplicidad. Una asociación representa una relación estructural entre bjetos en muchas situaciones del modelo, es importante señalar cuántos objetos pueden conectarse a través de una instancia en una asociación. Éste “cuántos” se denomina multiplicidad del rol de la asociación, y se escribe como una expresión que se evalúa a un rango de valores o a un valor explícito. Multiplicidad 0..1 * Empresa Persona Patrón Empleado Rol Asociación Fig 13. Multiplicidad 1.4.2.4. Agregación. Una asociación normal entre dos clases representa una relación estructural entre iguales, es decir, ambas clases están conceptualmente en el mismo nivel, sin ser ninguna más importante que la otra. A veces, se desea modelar una relación “todo/ parte”, en la cuál una clase representa una cosa grande (el “todo”), que consta de elementos más pequeños (las “partes”). Este tipo de relación se denomina agregación, la cuál representa una relación del tipo”tiene-un”, o sea, un objeto del todo tiene objetos de la parte. Empresa Todo Agregación Parte Departamento Fig 14. Agregación 1.4.2.5. Relación de generalización: Es una relación de especialización/ generalización en la cuál los elementos del objeto especializado (el hijo) pueden sustituir los objetos del elemento general (el padre). Se representa como una línea continua con una punta de flecha vacía apuntando al padre. Fig 15. Relación de generalización 1.4.2.6. Relación de realización: Es una relación semántica entre clasificadores, en donde uno especifica un contrato, y el otro garantiza que cumplirá Fig 16. Relación de realización 1.5. DIAGRAMAS DE UML. Un diagrama es la representación gráfica de un conjunto de elementos. Visualizando la mayoría de las veces como un grafo conexo de nodos (elementos) y arcos (relaciones). Los diagramas se dibujan para visualizar un sistema desde diferentes perspectivas, de forma que un diagrama es una proyección de un sistema. En teoría, un diagrama puede contener cualquier combinación de elementos y relaciones. En la práctica, sin embargo, sólo surge un pequeño número de combinaciones, las cuales son consistentes en las cinco vistas más útiles que comprenden la arquitectura de un sistema con gran cantidad de software. Por esta razón, UML incluye nueve de estos diagramas: diagrama de clases, diagrama de objetos, diagrama de casos de uso, diagrama de secuencia, diagrama de colaboración, diagrama de estados (statechart), diagrama de actividades, diagrama de componentes y diagrama de despliegue. 1.5.1. Diagrama de clases: Muestra un conjunto de clases, interfaces y colaboraciones, así como sus relaciones. Estos diagramas cubren la vista de diseño estática de un sistema. Los diagramas de clases que incluyen clases activas cubren la vista de procesos estática del sistema.(Ver fig.17.) Ejemplo: Empresa Agregación 1 Clase * 1..* Multiplicidad Nombre 1..* Departamento Oficina Nombre: Ubicación Dirección: Nom bre String 0..1 Teléfono: {Subconjunto} Restricció rol n Asociación Generalización Miembro 1..* 1 director Persona Atributos Oficina nombre: Nombre Operaciones principal idEmpleado: Integer InformaciónDeCont Cargo: String acto Dirección: String obtener (p:Foto) obtenerVoz() Obtenerinformacióndecontacto() Interfaz Registro Personal Obtener registrospersonales() idtasas Historia empleos dependencia Salario linformaciónsegura Fig.17. Diagrama de clases. 1.5.2. Diagrama de objetos: Muestra un conjunto de objetos y sus relaciones. Los diagramas de objetos cubren la vista de diseño estática o la vista de procesos estática de un sistema como lo hacen los diagramas de clases, pero desde la perspectiva de casos reales o prototípicos. Ejemplo: C: Compañía D1: Departamento D2: Departamento Nombre = “Ventas” Nombre = “I+D” enlace Valor del atributo D3: Departamento Objeto Nombre = “Ventas en USA” Objeto anónimo P: Persona :InformaciónDeContado Nombre = “Francisco” Dirección”C/ de la Ermita, 2” Id _ empleado =4362 Cargo =”Vcte de Venta” Fig.18: Diagrama de objeto. 1.5.3. Diagramas de casos de uso: Muestran un conjunto de casos de uso y actores (un tipo especial de clases) y sus relaciones. Estos diagramas son especialmente importantes en el modelado y organización del comportamiento de un sistema.(ver Fig.19.). Ejemplo: Realizar llamada << extend >> Realizar llamada telefónica de conferencia Red Telefónica Relación de extensión Recibir llamada << extend >> Recibir llamada telefónica adicional actor Caso de uso Frontera del sistema Usar agenda asociación Teléfono Movil Usuario Fig.19. Diagrama de casos de uso 1.5.4. Diagrama de secuencia: muestra la interacción de un conjunto de objetos en una aplicación a través del tiempo. Esta descripción es importante porque puede dar detalle a los casos de uso, aclarándolos al nivel de mensajes de los objetos existentes, como también muestra el uso de los mensajes de las clases diseñadas en el contexto de una operación. Ejemplo: objeto c: cliente (Transient) p: ProxyODBC : Transacción Mensaje Establecer acciones(a,d,o) Establecer valores(d, 3, 4) Establecer valores (a, “CO”) Éxito DIAGRAMA DE SECUENCIA Fig.20. Diagrama de secuencias 1.5.5. Diagrama de colaboración: Puede especificar un contrato entre objetos, parte esencial para la descripción de un patrón de diseño. Este diagrama contiene todos los elementos citados de un diagrama de colaboración, dejando libres posiblemente los tipos exactos de algunos objetos o con nombres genéricos para los mensajes. Una "instanciación" del patrón se representa como una elipse unida mediante flechas punteadas a los objetos o clases que participan realmente en el patrón. Estas flechas pueden tener roles, indicando cuál es el papel de cada elemento dentro del patrón. (ver Fig.21). Ejemplo: c: Cliente 1: <> Enlac 2: establecer Acciones (a,d, o) 3: <> Mensaje << Local>> << global>> Transacción p: ProxyODBC {Transient} Objeto 2.1: establecerValores(d, 3, 4) 2.2: establecerValores(a, “CO”) Fig.21.Diagrama de colaboración 1.5.6. Diagrama de estados (statechart): Muestra una maquina de estados, que consta de estados, transiciones, eventos y actividades. Estos cubren la vista dinámica de un sistema. Son especialmente importantes en el modelado del comportamiento de una interfaz, una clase o una colaboración y resaltan el comportamiento dirigido por eventos de un objeto.(ver Fig.22.). 1.5.6.1. Estado: Identifica un periodo de tiempo del objeto (no instantáneo) en el cual el objeto esta esperando alguna operación, tiene cierto estado característico o puede recibir cierto tipo de estímulos. Se representa mediante un rectángulo con los bordes redondeados, que puede tener tres compartimientos: uno para el nombre, otro para el valor característico de los atributos del objeto en ese estado y otro para las acciones que se realizan al entrar, salir o estar en un estado (entry, exit o do, respectivamente). En el caso del ejemplo anterior, se tienen cuatro estados (En Funcionamiento, Sin Cambio, Sin Ingredientes, Mal Funcionamiento) , en los cuales se desarrollan ciertas acciones al entrar; por ejemplo, al entrar al estado Sin Ingredientes se debe realizar la acción "Indicador Sin Ingredientes en On". Se marcan también los estados iniciales y finales mediante los símbolos y , respectivamente. Ejemplo: Estado inicial transición sonando Estado anidado Recibiendo Transición sin Cabecera Inactivo disparador Ok. Conectado Procesando enviarFax( ) VerificacionOcolgar k. Limpiando evento Transmisión Entry / descolgar Error / Imprimir acción evento error Exit / desconectar acción Estado Estado compuesto Fig.22 Diagrama de estado. 1.5.7. Diagrama de actividades: Es un caso especial de un diagrama de estados en el cual casi todos los estados son estados de acción (identifican que acción se ejecuta al estar en él) y casi todas las transiciones son enviadas al terminar la acción ejecutada en el estado anterior. Puede dar detalle a un caso de uso, un objeto o un mensaje en un objeto. Sirven para representar transiciones internas, sin hacer mucho énfasis en transiciones o eventos externos. Se presenta a continuación un ejemplo de diagrama de actividades para un mensaje de un objeto. Generalmente modelan los pasos de un algoritmo.(ver Fig.23). Ejemplo: Estado inicial Elegir sitio Contratar arquitecto Estado de acción Desarrollar plano Ofertar plano [no aceptado] Bifurcación secuencial [en otro caso] División concurrente Estado de Actividad con Realizar trabajo en el terreno Hacer trabajo comercial submaquinas :CertificadoDeVivienda Terminar construcción [terminado] Estado final Flujo de objeto Fig.23 Diagrama de actividades Un diagrama de actividades es un tipo especial de diagrama y comparte las propiedades comunes al resto de los diagramas (un nombre y un contenido gráfico que es una proyección de un modelo). Los diagramas de actividades pueden contener objetos especiales como lo son: 1.5.7.1. Bifurcación: Las transiciones secuénciales son frecuentes, pero no son el único tipo de camino que se necesita para modelar un flujo de control. Como en los diagramas de flujo, se puede incluir una bifurcación, que especifica caminos alternativos, elegidos según el valor de alguna expresión booleana. Como se muestra a continuación: Recoger parte de trabajo Expresión de guarda bifurcación [Materiales no disponibles] Volver a planificar [Materiales disponibles] Asignar tareas Expresión de guarda Bifurcación 1.5.7.2. División y unión. Las transiciones secuénciales y las bifurcaciones son los caminos más utilizados en los diagramas de actividades. Sin embargo, también es posible encontrar flujos concurrentes, especialmente cuando se modelan flujos de trabajo de procesos de negocios. En UML se utiliza la barra de sincronización para especificar la división y unión de estos flujos de control paralelos. Una barra de sincronización se representa como una línea horizontal o vertical ancha como se observa en el diagrama de actividades. 1.5.8. Diagrama de componentes: Muestra la organización y las dependencias entre un conjunto de componentes. Los diagrames de componentes cobren la vista de implementación estática de un sistema. Se relacionan con los diagramas de clases en que un componente se corresponde, por lo común, con una o más clases, interfaces o colaboraciones.(ver Fig.24). Ejemplo: Fig.24. Diagrama de componentes. 1.5.9. Diagrama de despliegue: Muestra la configuración de nodos de procesamiento en tiempo de ejecución y los componentes que residen en ellos. (ver Fig.25). Ejemplo: MODEM Internet nodo << procesador>> << procesador>> conexión servidor servidor de caché de caché nodo <> red local <> or>> or>> or>> servidor servidor servidor servidor principal Fig.25. Diagrama de despliegue. 1.6. Reglas de UML. Los bloques de construcción de UML no pueden simplemente combinarse de cualquier manera. Como cualquier lenguaje, UML tiene un número de reglas que especifican a qué debe parecerse un modelo bien formado, para ello, UML tiene reglas semánticas para: •Nombres è Cómo llamar a los elementos, relaciones y diagramas. •Alcance è El contexto que da un significado específico a un nombre. •Visibilidad è Como se pueden ver y utilizar esos nombres por otros. •Integridad è Cómo se relacionan apropiada y consistentemente unos Elementos con otros. •Ejecución è Qué significa ejecutar o simular un modelo dinámico. 1.7. MECANISMOS COMUNES DE UML Existen cuatro mecanismos comunes que se aplican de forma consistente a través de todo el lenguaje: Especificaciones, .adornos, divisiones comunes, mecanismos de extensibilidad. 1.7.1. Especificaciones. Detrás de la notación gráfica hay una especificación que proporciona una explicación textual de la sintaxis y semántica de cada bloque de construcción. La especificación de UML se utiliza para enunciar los detalles del sistema. Hecha esta división, es posible construir un modelo de forma incremental dibujando primero diagramas y añadiendo después semántica a las especificaciones del modelo. Las especificaciones de UML proporcionan una base semántica Que incluye a todas los elementos de todos los modelos de un sistema, y cada elemento está relacionado con otros de manera consistente. Los diagramas de UML son así simples proyecciones visuales de esa base, y cada diagrama revela un aspecto específico inversamente del sistema. 1.7.2. Adornos. La mayoría de los elementos de UML tienen una única y clara notación gráfica que proporciona una representación visual de los aspectos más importantes del elemento. Por ejemplo, la anotación para una clase se ha diseñado intencionalmente de forma que sea fácil de dibujar, porque las clases son los elementos que aparecen con mas frecuencia al modelar sistemas orientados a objetos. La notación de la clase también revela los aspectos más importantes de una clase, a saber: su nombre, atributos y operaciones. Muchos de estos detalles se pueden incluir como adornos gráficos o textuales en la notación rectangular básica de la clase. A continuación se muestra una clase con adornos que indican que es una clase abstracta con dos operaciones públicas, una protegida y la otra privada. Transacción + ejecutar () + rollbac () # prioridad - marca de tiempo () 1.7.3. Divisiones comunes. En primer lugar, está la división entre clases y objetos. Casi todos los bloques de construcción de UML el mismo tipo de dicotomía clase/ objeto. Por ejemplo, se pueden tener casos de uso e instancias de casos de uso, componentes e instancias de componentes, nodos e instancias de nodos, etc. Gráficamente, UML distingue un objeto utilizando el mismo símbolo de la clase y subrayando el nombre del objeto. En segundo lugar, tenemos la separación entre interfaz e implementación. Una interfaz decla ra un contrato, y una implementación representa una realización concreta de ese contrato, responsable de hacer efectiva de forma fidedigna la semántica completa de la interfaz. En UML se pueden modelar las interfaces y sus implementaciones. Cliente Juan: cliente Nombre Dirección teléfono : cliente Elisa 1.7.4. Mecanismos de extensibilidad. UML proporciona un lenguaje estándar para escribir planos software, pero no es posible que el lenguaje cerrado sea siempre suficiente para expresar todos los matices posibles de todos los modelos en todos los dominios y en todos los momentos. Por esta razón, UML es abierto – cerrado, siendo posible extender el lenguaje de manera controlada. Los mecanismos de extensión de UML incluyen: Ø Estereotipos. Ø Valores etiquetados. Ø Restricciones. Un estereotipo extiende el vocabulario de UML, permitiendo crear nuevos tipos de bloques de construcción que deriven de los existentes pero sean específicos a un problema. Un valor etiquetado extiende las propiedades de un bloque de construcción de UML, permitiendo añadir nueva información en la especificación de ese elemento. Una restricción extiende la semántica de un bloque de construcción de UML, permitiendo añadir nuevas reglas o modificar las existentes. Con las restricciones se puede añadir nueva semántica o modificar las reglas existentes. (ver Fig.26) Restricción simple Empresa {segura} Restricción entre múltiples elementos Cuenta bancaria {or} Persona Sexo: {hombre, mujer} Fig.26 Restricciones 2. ANÁLISIS DEL SISTEMA DE INFORMACIÓN. 2.1. RECOLECCIÓN Y TÉCNICAS DE INFORMACIÓN. 2.1.1. Fuentes Primarias. El personal que labora y se sirve de la planta física del Hospital local de Arjona fue nuestra principal fuente de información, debido a que ellos conocen todos y cada uno de los procesos por los cuales fluye la información que en el se genera. Por otra parte, nos fue de gran utilidad la guía y consejos recibidos por parte de nuestro director Ing. Isaac Zúñiga S., y los Doctores Alfredo González Hurtado y Orlando Cogollo Torres, gerente y exgerente de la E.S.E H. L. A. . 2.1.1.1. Elaboración de Entrevista para el personal de planta del H. L. A. Conociendo el volumen de información que se maneja en un Hospital, fue necesario el desarrollo de entrevistas abiertas, planteando interrogantes que brindaran la oportunidad a los entrevistando de entregar en forma confiable la información requerida para el análisis del sistema actual y el desarrollo del sistema propuesto. Este proceso se realizo mediante un formato que se encuentra anexo a este documento Ver anexo 1. 2.1.1.2. Elaboración de Entrevista a pacientes. De igual manera que con el personal del hospital, a los usuarios o pacientes se le realizaron preguntas abiertas y se le practico una pequeña encuesta escrita para corroborar datos recogidos directamente. El formato utilizado para la encuesta se encuentra anexo a este documento. Ver anexo 2. 2.1.1.3. Análisis de las Entrevistas y Lluvia de Ideas. De acuerdo a los resultados obtenidos en las entrevistas se pudo notar un total acuerdo en la utilización de sistemas computacionales que agilicen los procesos internos del hospital. De igual forma se pudo notar que la atención a los pacientes debe ser prioritaria. Una vez recopilada toda la información nos reunimos con nuestro director de proyecto y algunos profesionales de sistemas computacionales y se plantearon las siguientes soluciones: 2.1.1.4. Fuentes Secundarias. La información aquí recopilada es básicamente el resultado de consultas en INTERNET, bibliografías de referencias, así como también de estudios anteriormente realizados. 2.2. CONSIDERACIÓN DE POSIBLES SOLUCIONES 2.2.1. Modelo de base de datos en Access Microsoft Access para los sistemas operativos Windows proporciona la eficacia de las bases de datos relacionales para facilitar la información que necesita para tomar mejores decisiones. Integra datos de hojas de cálculo y otras bases de datos, y constituye una forma fácil de buscar respuestas, compartir información en redes internas (Intranet) y en Internet, y construir soluciones de negocios más rápidas. Access permite generar, analizar y crear informes sin horas de esfuerzo. Es fácil de utilizar desde la entrada de datos hasta la impresión en HTML. Ventajas v Tanto si es un usuario nuevo como si tiene conocimientos avanzados, esta base de datos relacional es eficaz y, a la vez, fácil de utilizar. Características como el Asistente para Ayuda facilitan la búsqueda de respuestas a preguntas acerca de la utilización de Access, y ayuda a los usuarios a aprovechar al máximo sus herramientas de software. v Comparta periódicamente información con su entorno de trabajo o con el mundo. Access tiene varias características que integran las características de red, redes internas e Internet; además, permite producir informes profesionales en papel, en línea o en HTML. v Access es escalable. Desde los negocios personales hasta las corporaciones, es la única base de datos que crecerá conforme lo haga su negocio. 2.2.2. Modelo de base de datos en MYSQL Su principal objetivo de diseño fue la velocidad. Se sacrificaron algunas características esenciales en sistemas más "serios" con este fin. Otra característica importante es que consume muy pocos recursos, tanto de CPU como de memoria. • Ventajas: o Mayor rendimiento. Mayor velocidad tanto al conectar con el servidor como al servir selects y demás. o Mejores utilidades de administración (backup, recuperación de errores, etc). o Aunque se cuelgue, no suele perder información ni corromper los datos. o Mejor integración con PHP. o No hay límites en el tamaño de los registros. o Mejor control de acceso, en el sentido de qué usuarios tienen acceso a qué tablas y con qué permisos. • Inconvenientes: o No soporta transacciones, "roll-backs" ni subselects. o No considera las claves ajenas. Ignora la integridad referencial, dejándola en manos del programador de la aplicación. 2.2.3. Modelo de base de datos en POSTGRE SQL Postgres intenta ser un sistema de bases de datos de mayor nivel que MySQL, a la altura de Oracle, Sybase o Interbase. • Ventajas: o Por su arquitectura de diseño, escala muy bien al aumentar el número de CPUs y la cantidad de RAM. o Soporta transacciones y desde la versión 7.0, claves ajenas (con comprobaciones de integridad referencial). o Tiene mejor soporte para triggers y procedimientos en el servidor. o Tiene ciertas características orientadas a objetos. • Inconvenientes: o Consume bastantes recursos y carga demasiado el sistema. o Límite del tamaño de cada fila de las tablas a 8k!!! (se puede ampliar a 32k recompilando, pero con un coste añadido en el rendimiento). o Es de 2 a 3 veces más lenta que MySQL. 2.2.4. Interfase gráfica en Visual Basic 6.0. Visual Basic es muy fácil de aprender y de utilizar, no solamente porque el lenguaje de programación no es OOP y es fácil de aprender y codificar, sino también porque el IDE es simple y cómodo de usar, y los objetos de base de datos que vienen con Visual Basic son más fáciles de utilizar que sus contrapartes de Delphi, aunque claro que no son tan potentes. Visual Basic hace muchas cosas por el programador. Por ejemplo, los objetos cuentan con referencias y esto significa que por ejemplo si creamos un objeto asignándolo a una variable local, el objeto será liberado automáticamente cuando la función o el procedimiento finalice (a menos que lo asignamos a una variable no local). Visual Basic tiene un sistema de administración sofisticado de memoria y utiliza un "colector de basura" (garbage colector) así que es rápido liberando memoria. En cuanto al acceso a bases de datos, en Visual Basic es más simple. Se usa un solo componente que abre el Recordset, ofrece interfaz visual de navegador y se enlaza con los controles de datos, mientras que en Delphi hay que usar tres componentes para ello. La gran ventaja de los Recordsets de Visual Basic sobre los Datasets de Delphi es que los primeros manejan consultas actualizables automáticamente: se puede tener una consulta de dos tablas y que sea "viva", mientras que en Delp hi tenemos que utilizar actualizaciones cacheadas y un componente UpdateSQL con las respectivas consultas SQL para insertar, actualizar o eliminar un registro. Además, cuando uno actúa contra un servidor de base de datos en Delphi tiene que utilizar un componente Transaction, mientras que esto no es necesario en Visual Basic. Visto desde la perspectiva de un programador Visual Basic, el acceso a datos de Delphi resulta ser demasiada molestia cuando se lo compara con los Recordsets y el Control de Datos de Visual Basic que simplifican notoriamente esta cuestión. 2.2.5. Interfase gráfica en Delphi Delphi es más difícil de aprender que Visual Basic, pero no para quienes están familiarizados por ejemplo con Turbo Pascal, FreePascal, o incluso C/C++. Delphi es más difícil de usar, pero tiene sus ventajas. Por ejemplo, los objetos generalmente no cuentan referencias y esto significa que el programador tiene que encargarse de liberar los objetos no usados creados por un procedimiento o una función cuando ese procedimiento o función termina. La ventaja es que tenemos más libertad en la manipulación del objeto y podemos liberarlo cuando no lo necesitemos más, sin importar cuántas variables apunten a él. En cuanto a la administración de memoria, Delphi no tiene un colector de basura como Visual Basic, pero tiene su propio sistema de administración de memoria, el que está optimizado para bloques pequeños de datos. El acceso a base de datos puede resultar algo incómodo al principio para quienes están acostumbrados a Visual Basic, pero es muy potente, flexible y extensible. 2.2.6. Interfase gráfica en Visual C++ Es muy rápido en proceso y gráfico, se labora orientado a objetos (aunque uno puede eludir fácilmente esto), excelente manejo de cadenas (strings) porque se trabaja directamente sobre posiciones en memoria, en el lado negativo, el código tiene multitud de instrucciones generadas por los "wizards" que se mezclan con código propio y hace difícil el mantenimiento y el manejo de eventos que es "puro Windows" dificulta entender e l programa. 2.3. SELECCIÓN Y JUSTIFICACIÓN DE LA SOLUCIÓN Luego de haber tenido en cuenta tres diferentes manejadores de base de datos e igual número de lenguajes para la creación de la interfase con el usuario, se decidió que la combinación más adecuada para el trabajo a realizar es la de MYSQL para la creación y administración de la base de datos, con Visual Basic para la creación de las interfaces de usuario. Debido a que el Hospital necesita de tiempos de respuesta lo suficientemente cortos al ejecutar las diferentes órdenes o peticiones de servicios. Aunque existen inconvenientes como lo son las licencias para ambos software, el Hospital realizarían los respectivos estudios de presupuesto para la adquisición de estas, vale la pena recalcar que MYSQL y PostgreSQL son herramientas totalmente gratis. 3. MODELAMIENTO DEL SISTEMA PROPUESTO. Si nos remitimos a las figuras 3.1. – 3.17., se podrá apreciar el sistema propuesto, en donde se plantea la solución más apropiada para la optimización del funcionamiento de la E.S.E. Hospital Local Arjona, teniendo en cuenta su actual estructura administrativa y capacidad económica. 3.1. Diagrama de Clases. INTERFAZ. Petición de acceso a la Departamento información Paciente 1 Gerencia Admisión Gerente: nombre Nombre: Nombre 1 Facturación Tesorería Régimen: Nombre Encargado: Nombre. - Toma de C.C. : entero 1..*1..2 Tesorero: Nombre. decisiones Dirección: cadena Idencargado: entero. Facturador: Nombre Idtesorero: entero. 1..* 1 Edad: entero 1..* 1 Obtener datos - Facturar los servicios y 1 Entrando. paciente. - Consignar dinero. medicamentos Saliendo. suministrados - Emitir CxC. - Recibir efectivo. - Enviar recibos de 1..* 1..* - Entregar factura consignación a contabilidad. 1 Servicios 1..* Medico: nombre Idmedico: entero Presupuesto Contabili dad Reportar en Encargado: papel el serv. Encargado: Prestado. Nombre. Nombre. Prestar Idencargedo: IdencInargaredos:o e ndter o. - Elaborar el consignación al presupuesto sistema. 1..* Causar CxP. anual de la Ingreso de gastos, empresa. compras, y demás - Hacer las Hacer retefuente. descargas al 1..* Actualizar información financiera. Fig 48. D. P. de Clases 86 3.2. DIAGRAMA DE OBJETOS H:H.L.A G: Departamento A: Departamento T: Departamento F: Departamento NOMBRE: NOMBRE: ADMISION NOMBRE: TESORERIA M.E. Pa: Paciente P: Departamento C: Departamento NOMBRE: Fig 49. D. P Objetos M.E. :MUTUA EXCLUSIÓN 87 3.3.1. Diagrama de casos de uso Fig 50 D. P Casos de Uso 1. SERVICIO RECIBE EL SERVICIO ADMISION EFECTUA COBRO ENVIA INFORM. A LA BASE DE DATOS BASE DE DATOS H.L.A. EXTRAE INFORM. PERMITIDA DE LA TOMA LOS DATOS B.D. PACIENTE FACTURACION TOMA DE INFORMACION AL PACIENTE 88 3.3.2. Diagrama de casos de uso Fig 51 D. P Casos de Uso 2. GERENCIA ENVIA DINERO RECAUDADO EXTRAE INFORME DE EXTRAE INFORME INGRESOS NEC ESARIO TESORERIA FACTURACION ENVIA DATOS DE ENVIA COPIA DE INGRESOS A LA B.D. CONSIGNACIONES BASE DE DATOS EXTRAE INFORME DE H .L.A. INGRESOS Gral. EXTRAE INFORME DETALLADO DE CUENTAS PRESUPUESTO CONTABILIDAD 89 3.4.1. Diagrama de secuencias P: PACIENTE A: DEPARTAMENTO S: SERVICIO F: DEPARTAMENTO Solicita Admisión Admitir paciente o Serv. Particular. Solicitar Servicio. Notificar servicio Notificar servicio Solicitar pago Realizar Pago Emitir factura Brindar Servicio. Enviar informe sobre Servicio prestado Fig 52 D. P Secuencias 1. 90 3.4.2. Diagrama de secuencias. F: DEPARTAMENTO T: DEPARTAMENTO C: DEPARTAMENTO P: DEPARTAMENTO G: DEPARTAMENTO Entrega factura y dinero diario Envía Información financiera Envía información financiera Generar reportes Generar reportes Fig 53 D. P Secuencias 2. 91 3.3.5. Diagrama de colaboración 4:Requiere(Informe) GERENCIA FACTURACIÓN TESORERÍA 5: Recibe (Informe) 3: Envía (Efectivo, Informe) Fig 54 D. P Colaboración 1. PACIENTE 2: Realiza (Pago) 1: Elabora( Factura) 92 3.6.1. Diagrama de estados Esperando Atendiendo pacientes pacientes Ingreso de da tos Efectuando del paciente y facturación Admitiendo servicio Efectuando pacientes cobro Rechazando Prestando pacientes servicios Despidiendo pacientes Fig 55 D. P Estados. 93 3.6.2. Diagrama de estados Esperando Recibiendo Información información Almacenando información en la base de datos Ingresando información al sistema Canalizando información a puestos de trabajo Saliendo del sistema P rocesamiento de la información Fig 56 D. P Estados 2 94 3.7.1. Diagrama de actividades “Admisión “ ESPERA LA LLEGADA DE PACIENTES RECIBE PACIENTES ( NO ADMITIDO) ADMITIDO O SERV PARTICULAR CAPTURA DATOS DE PACIENTES RED LOCAL ENVIAR DATOS A ENVIAR DATOS A SERVICIOS FACTURACIÓN Fig. 57. D. P. Actividades “Admisión” 3.7.2. Diagrama de actividades “Facturación “ ESPERA EL INFORME DE SERVICIO O ADMISIONES EN LA RED. RECIBIR DATOS DE SERVICIO O ADMISIONESPOR LA RED. REGISTRA DATOS SUMINISTRADOS POR SERVICIOS O ADMISIONES EFECTUAR COBRO DE SERVICIO. RECIBE EL PAGO DEL PACIENTE ENTREGA UNA COPIA DE LA FACTURA AL PACIENTE SE ENVIA INFORME A TESORERIA POR LA RED. ENVIAR DINERO A TESORERIA. Fig 58. D. P. Actividades “Facturación” 3.7.3. Diagrama de actividades “Tesorería” SE ESPERA EL REPORTE DE FACTURACIÓN SE RECIBE LA INFORMACIÓN DE LA RED. SE RECIBE Y CONSIGNA EL DINERO EN BANCO SE LE ENVIA A SE LE ENVIA A CONTABILIDAD LA COPIA PRESUPUESTO EL VALOR DE LA CONSIGNACIÓN DE LA FACTURACION DEL JUNTO CON LAS C x C DIA Fig 59. D. P. Actividades “Tesorería” 3.7.4. Diagrama de actividades “Contabilidad” SE ESPERA EL REPORTE DE TESORERIA SE RECIBE EL REPORTE SE REGISTRAN LAS SE REGISTRAN LOS SE REGISTRAN CxC INGRESOS GASTOS Y EGRESOS SE ENVIA UN INFORME A GERENCIA SI LO REQUIERE Fig 60. D. P. de actividades “Contabilidad” 3.7.5. Diagrama de actividades “Paciente” NECESITAR SERVICIO MEDICO LLEGAR AL HOSPITAL LLEGAR A ADMISION (CASO CONTRARIO) SERV. PARTICULAR (ADMITIDO) NINGÚN SERVICIO RECIBIR COBRO CANCELAR EFECTIVO RECIBIR SERVICIO SALIR DEL H.L.A. Fig. 62. D. P. A ctividades “Paciente” 3.3.8. DIAGRAMA DE COMPONENTE PETICIÓN. EXE VERIFICACIÓN. EXE BASE Departamento DE DATOS Fig. 63. D. de Componentes 101 3.3.9. DIAGRAMA DE DESPLIEGUE CLIENTE O PACIENTE FACTURACIÓN BASE DE DATOS RED LOCAL TESORERÍA PRESUPUEST CONTABILIDAD GERENCIA O Fig. 64. D. de Despliegue. 102 4. DISEÑO DE SISTEMA PARA EL H.L.A. Para la realización del diseño del sistema de información se utilizo el lenguaje unificado de modelado UML, y sus respectivos representaciones graficas fueron realizados en procesadores de textos como Microsoft Word 2000 4.1. DISEÑO DE SALIDAS En todo sistema computacional la presentación final de la información juega un papel importante, tanto para el software como para el creador en particular.* Para el sistema de información del H.L.A. se tuvieron en cuenta factores de vital importancia como son por ejemplo, el periodo comprendido entre cada salida, y la frecuencia con la que se solicita la información. Otro factor que se mantuvo siempre presente fue el departamento que lo produce y el que lo requiere. El sistema HLA tiene dos tipos de salidas que las asociamos a los términos de salidas impresas en papel y por pantalla. *ANÁLISIS Y DISEÑO DE SISTEMAS Tercera Edición KENDALL & KENDALL Prentice may Las salidas por pantalla se diseñaron según las herramientas presentadas por el visor de Vbasic. Estas se encuentran plasmadas en el CD adjunto a este documento. Las salidas impresas en papel se dividen en FACTURAS e INFORMES. Las facturas son documentos impresos que se elaboraran cada vez que un paciente llegue al Hospital y se le preste un servicio o grupo de servicios. Esta tendrá 3 copias que se distribuirán de acuerdo al proceso contable de la entidad. Los Informe serán resultados de peticiones hechas al servidor a través de ordenes directas. Podremos encontrar los siguientes: • Informe de facturas hechas en un turno. • Informe de facturas por conceptos. • Informe de cuentas por cobrar. - Informe de cuentas por cobrar por empresa. - Informe de cuentas por cobrar general. Para los INFORMES DE FACTURAS POR TURNO serán realizados para llevar un control contable de la entrada monetaria en cada turno y posteriormente evaluación de resultados. Ver Figura 44. Figura 44. Diseño del Informe de Facturas por turnos. El INFORME DE FACTURAS POR CONCEPTOS se realizara quincenalmente ( dos veces al mes). Contendrá la siguiente información: Periodo tomado para la verificación, es decir las fechas inicial y final para a realización. Los conceptos, que son todos y cada uno de los servicios que presta el hospital, Valores ingresados por la prestación de los conceptos, y un valor general que será el total ingresado por todos. Ver figura 45. Figura.45. Informe detallado de ingresos por conceptos. Las cuentas por cobrar se requieren cada fin de mes y en forma detallada. Para este informe se tiene en cuenta que se deben realizar dos copias. Las cuentas por cobrar a una empresa en particular tiene la siguiente información: Nombre de la empresa que nos adeuda, los conceptos, totales por cada concepto. Al final del informe se muestra un total general de la deuda que la empresa tiene para con nosotros. Ver figura 46. Figura. 46. Informe de Cuentas por Cobrar a Empresas. El informe GENERAL DE CUENTAS POR COBRAR, se realizara al final de un periodo contable o en caso extraordinario de solicitud de gerencia u otro departamento. Contiene la fecha de realización, la información de las empresas que nos adeudan, los valores correspondiente a las deudas de cada empresa tiene con nosotros, y un valor general de la deuda que tienen con nuestra institución por la prestación de nuestro servicio. Ver Figura 47. Figura 47. Informe General de Cuentas por Cobrar. 4.2. DISEÑO DE ENTRADAS El sistema consta básicamente de tres grupos de entradas, las cuales son necesarias para ingresar al sistema, registrar pacientes y /o usuarios y para generar reportes. En el caso del ingreso al sistema, el usuario deberá introducir un login y un password los cuales serán digitados por el usuario para obtener el ingreso respectivo, estos datos serán enviados al servidor mientras se le informa al usuario a través de una ventana de dialogo si su petición fue o no aceptada. Para registrar pacientes o usuarios, se bebe ingresar sus datos personales en el primer caso, y agregar un login, un password y el cargo que desempeña en el H.L.A. para el segundo caso en mención. Estos al igual que los anteriores ingresaran al sistema a través del teclado, y deben cumplir los parámetros establecidos en la base de datos. Para la captura de estos datos se contará con ventanas de diálogos secuénciales que irán verificando la información a medida que esta es ingresada. Entre los métodos utilizados para la verificación y validación de las entradas se puede mencionar la comparación numérica de variables. La generación de reportes se realizará dependiendo del tipo de reporte requerido para los cuales se tomaran como entrada datos relevantes como es el caso de las fechas, Nit de la empresa contratante, entre otros. El usuario dispondrá de interfaces que le permitirán orientarse al momento del ingreso de los datos. Su verificación se realizará mediante métodos matemáticos. Para observar cada una de las ventanas de entrada de datos, usted deberá consultar el CD anexo a este documento. 4.3. DISEÑO DE LAS INTERFASES DE USUARIO El sistema de información para la E.S.E. HOSPITAL LOCAL ARJONA esta diseñado bajo normas de diseño de software hospitalario y de acuerdo a la ley 100 de la Constitución Política de Colombia. Las interfases con el usuario se concentran en la adquisición y muestreos de los datos digitados por el usuario a través del teclado y procesados por medio de los módulos que conforman el sistema completo. Si desea observar todas y cada una de las interfases que utiliza el sistema consulte el CD anexo a este documento. Vale la pena recordarles que el diseño y programación de las interfases se realizo en Microsoft VisualBasic 6.0. 4.4. DISEÑO DE LA BASE DE DATOS Base de Datos centralizada HLA. Tabla de Usuarios: En esta tabla (ver cuadro 1) estará almacenada la información correspondiente a los usuarios directos del sistema a implementar Cuadro 1. Usuarios USUARIOS Campos Tipo Tamaño Descripción Nombre_empleado Carácter 35 Nombre completo del usuario del sistema Cedula Carácter 10 Cedula o documento de identificación del usuario Cargo Carácter 30 Cargo desempeñado dentro del Hospital Fecha_creacion Fecha Fecha en la que se crea o se modifican los datos del usuario LOGIN Carácter 10 Login que identificara a cada usuario dentro del sistema. PASSWORD Carácter 10 Clave personal de acceso al sistema Tabla de Utensilios: En ella (ver cuadro 2), se almacenara toda la información correspondientes a los utensilios y aparatos en general con que cuenta la planta física del hospital. Cuadro 2. Utensilios UTENSILIOS Campos Tipo Tamaño Descripción Código Carácter 10 Código de identificación de inventario para cada utensilio Descripción Carácter 20 Nombre completo del utensilio Cantidad Numérico Cantidad existente del utensilio en el inventario Medida Carácter 15 Medida en la cual se debe compra o se almacena el utensilio. Fecha_compra Fecha Fecha en que se adquirió dicho utensilio Fecha_exp Fecha Fecha en la que el utensilio caduca. Tabla de Proveedores. En esta tabla (ver cuadro 3) se almacena toda la información correspondiente a cada uno de los proveedores que le suministran los utensilios y todo aquello con lo que se trabaja en la planta física del hospital. Cuadro 3. Proveedores PROVEEDORES Campos Tipo Tamaño Descripción NIT Carácter 15 Numero de identificación del proveedor Nombre Carácter 30 Nombre completo del proveedor Actividad Carácter 30 Actividad comercial de la empresa. Dirección Carácter 20 Dirección del Proveedor Teléfono Carácter 15 Teléfono del proveedor Representante Carácter 30 Nombre de la persona que realiza las transacciones con el hospital. Tabla de Personal. Se utiliza para almacenar toda la información correspondiente a la planta de empleados del hospital (ver cuadro 4). Cuadro 4. Personal PERSONAL Campos Tipo Tamaño Descripción Cedula Carácter 10 Cedula o código del empleado Nombre Carácter 40 Nombre completo del empleado Dirección Carácter 30 Dirección residencial del empleado Teléfono Carácter 15 Teléfono del empleado Fecha_nac fecha Fecha de nacimiento del empleado Fecha_ing fecha Fecha de ingreso a la planta de personal del hospital Cargo Carácter 20 Cargo en el que se desempeña dentro del hospital Tabla de Paciente : (ver cuadro 5). Contendrá la información correspondiente a los datos personales de los pacientes o usuarios de los servicios prestados en el área médica del hospital Cuadro 5. Paciente PACIENTE Campos Tipo Tamaño Descripción Documento Carácter 15 Documento de identificación del paciente (cedula, TI) Carnet Carácter 15 Numero de identificación del Carnet expedido por la empresa aseguradora. Nombre Carácter 40 Nombre completo del paciente. Fecha_nac Fecha Fecha de nacimiento del paciente. Dirección Carácter 40 Dirección residencial del paciente ( incluye el municipio en caso necesario) Teléfono Carácter 12 Numero telefónico del paciente. Tipo_reg Carácter 20 Régimen al cual pertenece el usuario. Empresa Carácter 30 Empresa a la cual se encuentra afiliado el usuario. G_sangre Carácter 3 Grupo sanguíneo del paciente, incluye el factor RH. Tabla de historial. En ella se llevará un registro de cada una de los servicios prestados al paciente, así como también su respectivo diagnóstico. También reposaran las fechas de atención a dicho paciente. (ver cuadro 6) Cuadro 6. Historial HISTORIAL Campos Tipo Tamaño Descripción Documento Carácter 12 Documento de identidad del paciente Carnet Carácter 15 Numero de identificación del Carnet expedido por la empresa aseguradora. Fecha_ent Fecha Fecha de ingreso del paciente. Fecha_sal Fecha Fecha de salida del paciente. Código Numérico Código del servicio. Diagnóstico Carácter 50 Diagnostico emitido por el médico en turno. Médico Carácter 40 Nombre del médico en turno. Tabla de servicios. Contiene la información de todos y cada uno de los servicios que se prestan en el hospital con sus respectivos valores. (ver cuadro 7) Cuadro 7. Servicios. SERVICIOS Campos Tipo Tamaño Descripción Nombre Carácter 40 Nombre de los servicio que se prestan en el Hospital. Valor Moneda Costo del servicio Código Numérico Código del servicio Tabla de cuentas por cobrar. Poseerá la información pertinente a los cobros que el Hospital debe realizar por los conceptos de servicios prestados. (ver cuadro 8) Cuadro 8. Cuentas por cobrar. CUENTAS POR COBRAR Campos Tipo Tamaño Descripción Nombre Carácter 40 Entidad deudora. Código Numérico Código del servicio. Valor Moneda Valor adeudado por la empresa. Fecha Fecha Fecha en que se incurrió en la deuda. Tabla de Cuentas por pagar. Poseerá la información concerniente a los pagos que el Hospital debe realizar por los conceptos de servicios recibidos. (ver cuadro.9) Cuadro 9. Cuentas por pagar. CUENTAS POR PAGAR Campos Tipo Tamaño Descripción NIT Carácter 15 Numero de identificación del proveedor. Concepto Carácter 50 Nombre del servicio recibido. Valor Moneda Valor adeudado por la empresa. Fecha Fecha Fecha en que se incurrió en la deuda. 5. IMPLANTACIÓN DEL SISTEMA PARA EL H.L.A. 5.1. CONSTRUCCIÓN DEL SISTEMA Para la construcción de un sistema de información es necesaria la utilización de herramientas computacionales, así como es de vital importancia el conocimiento previo de dicha herramienta. En la actualidad existen innumerables herramientas creadas para tal fin y como ya se dijo anteriormente, el presente proyecto fue desarrollado en Visual Basic 6.0 para la creación de las interfases y todo lo relacionado con el manejo y muestreo de la información. En cuanto al diseño, creación y manejo de la Base de Datos se utilizó MySQL 4.1.0.2. Y no sin antes crear el origen de datos de usuario para lo que fue necesaria la herramienta administrativa ODBC El desarrollo de todo el sistema, así como el código fuente de todos y cada uno de los módulos que lo conforman se encuentran especificados en el CD anexo a este documento. Además encontrará otra información relacionada con la elaboración de este paquete en el manual de usuario, el cual también es un documento adjunto a este. 5.2. INSTALACIÓN Y PRUEBA DEL SISTEMA La instalación de un sistema de información computarizado comprende diversos campos que van desde la configuración individual de los equipos hasta la configuración de la red, en caso de que se vaya a utilizar una. Para la instalación de este paquete es necesario conocer su arquitectura, requerimientos y todos aquellos factores que en cualquier momento podrían hacer deficiente el desempeño del proyecto. Todos estos factores están plasmados en el manual de usuario del proyecto, por eso lo invitamos a mirar el capitulo 1 de ese material, en donde encontrará las respuestas a todas la interrogantes que se le presenten durante el proceso en mención. Una vez realizado satisfactoriamente todo lo relacionado con la instalación y configuración se procede a realizar pruebas al sistema. En principio, surgieron inconvenientes de todo tipo como es de esperarse para un sistema nuevo, dichos inconvenientes se dieron debido a que no se tuvo en cuenta que se haría una reestructuración administrativa y con ello, cambios en el modus operandi de la E.S.E. Hospital Local Arjona. El nuevo sistema dejaba por fuera pequeñas cosas que para la nueva administración tenían algo de importancia, fue entonces necesario reevaluar la nueva forma de trabajo de nuestro proyecto. El producto final de nuestro trabajo, fue puesto a prueba durante cinco días en la E.S.E Hospital Local Arjona, trabajando de forma paralela con el sistema que anterior al proyecto se utilizaba, esto con el fin de proteger la integridad de la información que se estaba manejando, y a la vez poder evaluar el funcionamiento de nuestro nuevo sistema. Además de esto, se puso a prueba con valores claves los cuales nos permitieron verificar que habíamos tenido en cuenta hasta el último detalle en la etapa de desarrollo. ENTORNO DE PRUEBA Para la implementación del entorno de Prueba fue necesaria la utilización de una base de datos ficticia pero de acuerdo a la información que la E.S.E Hospital Local Arjona nos suministró. Además se utilizaron los equipos computacionales con los que cuenta la institución y algunos otros implementos con que contamos. Primeramente se montó la red de acuerdo a nuestro diseño, posteriormente se instaló el software tanto en el servidor como en los equipos que servirían de terminales inteligentes, incluyendo la base de datos de prueba y finalmente de se inició la respectiva inclusión de datos nuevos, tales como el registro de los usuarios y prestación de servicios, entre otros. Una vez realizado el proceso antes mencionado se procedió a realizar pruebas al nuevo sistema, y se presentaron anomalías o problemas que a continuación mencionaremos: v El acceso simultaneo de varios usuarios a un mismo módulo generaba inconsistencia de datos y el tiempo de respuesta disminuía, para ello fue necesario emplear variables extras que evitaran a mas de un usuario del mismo departamento o sección utilizar simultáneamente la información, aplicando el principio de la mutua exclusión. v El servidor no era lo suficientemente potente para soportar las peticiones simultáneas que se le hacían desde las diversas terminales. Este problema se pudo disminuir quitándole algunos procesos al servidor asignándolos a las respectivas terminales a través de su modulo de programa activo en ese momento. Problemas como este son difíciles de solucionar en instituciones gubernamentales pues la carencia de recursos financieros para adquirir una maquina mas potente son el principal obstáculo que se presenta. v Existen algunos equipos utilizados como terminales que no soportaban el “bombardeo“ de Información del servidor hacia este equipo, presentándose de esta forma perdida de información al momento de su muestreo o procesamiento por parte de la estación. Para el mejoramiento del rendimiento se realizo un estudio extra de las características técnicas de cada equipo y posteriormente se realizo un sondeo de la cantidad de información que iba a manejar cada uno, para finalmente reubicar los equipos acuerdo a su utilidad dentro del proyecto. v Como se dijo anteriormente el sistema original sufrió cambios considerables en casi todos sus módulos por lo cual retraso su puesta en marcha y con ello errores corregidos anteriormente hicieron su aparición nuevamente pero que no son de mucha importancia y que van siendo corregidos con el transcurso de la puesta en marcha total del proyecto. CONCLUSIONES El sistema de información en una empresa independientemente de su tamaño es el pilar central en la manera como ésta realiza sus actividades diarias. Ahora dependiendo del estudio realizado anteriormente de las necesidades de la empresa y del buen diseño del sistema así será su rendimiento. Para agilizar esta tarea se han realizado estudios creando herramientas que le permiten al analista perfeccionar su desempeño. El UML es una de esas herramientas creada para suplir la vacante de un estándar en el proceso de modelado de los sistemas de información. El lenguaje unificado de modelado nos permite como analistas crear nuestros propios modelos basados en los elementos, relaciones, diagramas y reglas que este tiene definido. Todo esto partiendo del principio de que es un lenguaje abierto al analista en donde lo que vale es la estructura y sentido del diagrama más que su forma. Esta herramienta además de lo que nos brinda para trabajar, es apropiado para aquellos analistas visionarios que captan lo que muchos no pueden a simple vista, como por ejemplo, situaciones que no se amoldan a los diagramas o estructuras ya creadas sino que vienen a surgir en el momento en que se fusionan dos o mas diagramas o por el contrario se crea otro partiendo de las reglas y comportamientos propios del lenguaje. Llegado el momento de la conversión del sistema diseñado a un prototipo computacional, la tarea se torna un poco mas fácil, partiendo de la claridad del diseño debido a su enfoque orientado a objetos, eso se convierte en otra de las muchas ventajas que colocan al UML a la cabeza de las herramientas modernas y que poco a poco se va tomando un mercado tan exigente en donde lo primordial es solucionar un problema en el menor tiempo posible pero de una manera eficiente y eficaz. El registro sistemático de pacientes se hace más eficiente cuando se tiene a la mano una herramienta de tipo computacional que nos permita mantener y actualizar los datos e historias clínicas, de manera que no es necesario solicitar nuevamente la información de las personas que hayan ingresado al sistema. De esta forma se agilizan los procesos de admisión atención a os pacientes. Cuando la toma de decisiones se realiza en base a informes eficientes, se puede garantizar que las personas encargadas de decidir, conocen a cabalidad la situación periódica y actual de la empresa. La circulación de información entre departamentos debe ser coordinada para garantizar la seguridad e integridad de su contenido, es por eso que cada usuario registrado, solamente debe tener acceso a la información que corresponda a su departamento. Los usuarios directos del sistema deben ser capacitados para garantizar que entienden a cabalidad el completo funcionamiento del sistema, esto es una forma de agilizar el proceso de atención al público. RECOMENDACIONES v Cuando se nos presenten situaciones en las que no es suficiente un diagrama para mostrar todo el movimiento de la información es necesario realizar dicho diagrama por cada una de las dependencias que intervengan en el proceso. Esto se presenta con mucha frecuencia en los diagramas de actividades. v En sistemas computacionales como el implantado con este proyecto es necesario la verificación de los usuarios antes de asignarles login y password individuales para no incurrir en la duplicidad de estos. v Asignarle las contraseñas acordes a la función y/o petición del usuario. v No tratar de utilizar un mismo equipo con dos o más módulos al tiempo. Es mejor cerrar una sesión e iniciar la deseada. v No utilizar equipos con especificación técnicas por debajo de las mínimas recomendadas. v No utilizar el equipo asignado para el servidor como terminal de trabajo. v NO dejar una sesión iniciada al momento de finalizar el turno de cada usuario. BIBLIOGRAFÍA • FUNDAMENTOS DE BASES DE DATOS, Tercera Edición KORTH, Henry F – SILBERSCHATZ, Abraham Mc Graw Hill • ANÁLISIS Y DISEÑO DE SISTEMAS Tercera Edición KENDALL & KENDALL Prentice may • ANÁLISIS Y DISEÑO DE SISTEMAS DE INFORMACIÓN Tercera Edición WHITTEN, Whitten Mc Graw Hill • INGENIERÍA DE SOFTWARE Tercera Edición PRESSMAN Roger Mc Graw Hill • COMUNICACIONES Y REDES DE COMPUTADORES Sexta Edición STALLING, William Prentice Hall • LENGUAJE UNIFICADO DE MODELADO. BOOCH, Grady. RUMBAUCH, james Madrid España, 2000. Addison Wesley edition • APRENDIENDO UML EN 24 HORAS SCHMULLER, Joseph Pearson Educación México 2000 Prentice hall. • VISUAL BASIC 6.0 MANUAL DE REFERENCIA Segunda edición España, 2001 Mc Graw Hill • BRAVO TOLEDO, Rafael. Importancia de la documentación e información científica en la toma de decisiones clínicas. Madrid España, Noviembre 16 de 15 < http://www.infodoctor.org/rafavravo/jornadas.htm.> • HURTADO, Samir. Conversatorio de análisis de sistemas computacionales Octubre 22 de 2001. Actualización 2003 www.icesi.edu.co/es/publicaciones/contenidos/sistemas_telematicos/1/ shurtado_repres-uml.pdf. • MYSQL DATABASE SERVER. F_actuaizacion: Febrero de 2004 http://descargas.terra.es/informacion_extendida.phtml?n_id=10322&plat=4 • DESCARGAS GRATUITAS http:// Mysql.bannerlandia.com.ar mysql-4.1.1a-alpha.win.zip http://dev.mysql.com/get/download/MYSQL-4.1/mysql-4.1.2-alpha- win.zip/from/pick. • Online Healthcare Databases (Bases de datos de Sanidad en Línea) http://www.atheneum.doyma.es/Socios/sala_1/lec14pub.htm. • Enciclopedia Autodidáctica. Tomo V. Madrid España. Lexus Editores. 2001. Revisión Mayo 2003 • Curso Online Redes de Computadores www.inf.uct.cl/~amellado/archivos/redes3.pdf • Journal of technology education online: Virginia Polytechnic Institute and State University. 2001. Open Database Connectivity. 2001. , www2.flemaker.fr/spain/products/dbc_backgrounder.html Encuesta a trabajadores de la empresa social del estado Hospital Local Arjona. El siguiente cuestionario tiene la finalidad de recopilar información que nos permita evaluar, que tan importante e indispensable es un sistema de información computarizado, para el manejo de la información generada el la E.S.E. Hospital Local Arjona. CUESTIONARIO 1. ¿Qué cargo desempeña usted en el H.L.A.?________________________ ______________________________________________________________ 2. ¿Qué información necesita su departamento?, y ¿de donde la obtiene? _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ 3. ¿Qué información genera su departamento?, ¿y qué departamentos se benefician de ella?_____________________________________________ _______________________________________________________________ _______________________________________________________________ 4. ¿Qué tan eficiente es el intercambio de información entre los departamentos?_______________________________________________ ____________________________________________________________ ____________________________________________________________ 5. ¿De qué forma mejoraría un sistema de información computarizado el proceso de atención al cliente?___________________________________ _______________________________________________________________ _______________________________________________________________ ANEXO #1: Formato de entrevista a Personal de Planta. Encuesta a usuarios de la empresa social del estado Hospital Local Arjona. El siguiente cuestionario tiene la finalidad de recopilar información que nos permita evaluar, que tan importante e indispensable es un sistema de información computarizado, para el manejo de la información generada el la E.S.E. Hospital Local Arjona. CUESTIONARIO 1. ¿Con qué frecuencia utiliza usted los servicios del H.L.A.?______________ _______________________________________________________________ 2. ¿Cómo es la atención al cliente en el H.L.A.?________________________ _______________________________________________________________ _______________________________________________________________ 3. ¿Cómo calificaría usted los servicios que presta el H.L.A.?______________ _______________________________________________________________ _______________________________________________________________ 4. ¿Qué deficiencias encuentra usted en la atención al cliente?____________ _______________________________________________________________ _______________________________________________________________ _______________________________________________________________ 5. ¿De que forma cree usted que se podría mejorar la atención al cliente en el H.L.A.?_________________________________________________________ _______________________________________________________________ _______________________________________________________________ ___________________________________________________ ¿A que régimen pertenece usted?_________________________________ ANEXO #2. Formato de encuestas a Pacientes y/o Usuarios del H.L.A. MODELAMIENTO DEL SISTEMA ACTUAL. H.L.A Departamento Gerencia 1 Paciente 1 Gerente: 1 Tesorería Admisión Facturació1n Nombre: Nombre Tesorero: Nombre. - Toma de Régimen: Nombre Encargado: Facturador: Nombre Idtesorero: entero. decisiones C.C. : entero Nombre. 1..* 1..* Dirección: cadena 1..* 1 Idencargado: entero. - Facturar los - Consignar dinero. Edad: entero Admitir paciente. servicios y - Emitir CxC. 1 No admitir paciente. medicamentos - Enviar recibos de Entrando. suministrados consignación a Saliendo. - Recibir efectivo. contabilidad. - Entregar factura Servicios 1 1 1 Medico: nombre Idmedico: entero Presupuest o Contabi1l idad Encargado: Nombre. Prestar servicio Encargado: Idencargado: entero. Reportar en Nombre. papel el Idencargedo: entero. Ingreso de serv. - Elaborar el consignación al presupuesto sistema. Causar CxP. anual de la Ingreso de gastos, compras, y empresa. Hacer retefuente. - Hacer las Actualizar información descargas al financiera. ANEXO #3: DIAGRAMA DE CLASES ACTUAL 99 H:H.L.A G: Departamento A: Departamento F: Departamento T: Departamento NOMBRE: GERENCIA NOMBRE: ADMISION NOMBRE: FACTURACION NOMBRE: TESORERIA Pa: Paciente P: Departamento C: Departamento NOMBRE: PRESUPUESTO NOMBRE: CONTABILIDAD ANEXO #4 : DIAGRAMA DE OBJETOS ACTUAL. 100 1.1. Es Solicitar Entregar orden admitid Servicios de servicio o 1.8. Servicio 1.2. 2.2.2. 1.7. Admisión Pagar Realizar Servicios cobros 1.9. 1.3. 1.5. 1.6 1.4. No es Evalúa si toma Salida del Paciente admitido servicio sistema Facturación 2.1 particular 2.2.1 ANEXO #5: DIAGRAMA DE CASOS DE USO (Admisión, Facturación) 101 ENVIA INFORME REALIZAR DE INGRESOS INFORME DE TESORERIA REALIZA INFORME ENVIA INFORME FACTURACIO DE CUENTAS DE CUENTAS Generar reportes cuando PRESUPUES sean necesarios CONTABILID GERENCIA ANEXO #6: DIAGRAMA DE CASOS DE USO 2. 102 P:PACIENTE A: DEPARTAMENTO S: SERVICIO F: DEPARTAMENTO Solicita Admisión Admitir paciente o Serv. Particular. Solicitar Servicio. Notificar servicio Notificar servicio Solicitar pago Realizar Pago Emitir factura Brindar Servicio. Enviar informe sobre Servicio prestado ANEXO #7: DIAGRAMA ACTUAL DE SECUENCIAS 1 103 F: T: C: P: G: DEPARTAMENTO DEPARTAMENTO DEPARTAMENTO DEPARTAMENTO DEPARTAMENTO Entrega factura y dinero diario Envía Información financiera Envía información financiera Generar reportes Generar reportes ANEXO #8: DIAGRAMA ACTUAL DE SECUENCIAS (continuación) 104 3: Envía (efectivo, informe) FACTURACIÓN TESORERÍA 1:Elabora (Factura) 2:Realiza( pago) PACIENTE ANEXO #9: Diagrama de colaboración actual “Facturación” 5: Realiza (Pago) PACIENTE FACTURACIÓN 4: Entrega(factura) 1: Solicita ( admisión) 6: Envía paciente 2:Responde (SI/NO) 3:Envía (Paciente) ADMISIÓN SERVICIOS ANEXO # 10: DIAGRAMA DE COLABORACIÓN “Paciente” 2: Envía (Ingresos) TESORERÍA PRESUPUESTO 1:Envía (Estado de Efectivo, Cuentas en Gral) 3:Envía( Estado de Cuenta) CONTABILIDAD GERENCIA 4: Envía( Informe de cuentas) ANEXO #11: DIAGRAMA DE COLABORACIÓN “Tesorería” 5: Envía ( Inf. Presupuestal) Esperando Atendiendo pacientes pacientes Efectuando facturación Admitiendo pacientes Efectuando cobro Rechazando Prestando pacientes servicios Despidiendo pacientes ANEXO #12: DIAGRAMA ACTUAL DE ESTADOS 108 ESPERA LA LLEGADA DE PACIENTES RECIBE PACIENTES CAPTURA DATOS DE PACIENTES ( NO ADMITIDO) ADMITIDO O SERV PARTICULAR ENVIAR DATOS A ENVIAR DATOS A SERVICIOS FACTURACIÓN ANEXO #13: DIAGRAMA DE ACTIVIDADES “Admisiones” ESPERA LA LLEGADA DE PACIENTES RECIBE PACIENTES CON FACTURA O POR URGENCIA SE LE PRESTA EL SERVICIO SE REGISTRA EL SERVICIO PRESTADO (EN CASO DE URGENCIAS). SE ENVIA EL INFORME A FACTURACIÓN (EN CASO DE URGENCIAS). ANEXO #14: DIAGRAMA DE ACTIVIDADES “Servicios “ ESPERA EL INFORME DE SERVICIO O ADMISIONES RECIBE DATOS DE SERVICIO O ADMISIONES REGISTRA DATOS SUMINISTRADOS POR SERVICIOS O ADMISIONES IMPRIME 2 COPIAS DE LA FACTURA ENTREGA UNA COPIA AL PACIENTE RECIBE EL PAGO DEL PACIENTE SE ARCHIVA LA COPIA DE LA FACTURA JUNTO CON EL DINERO SE ENVIA INFORME A TESORERIA ANEXO #15: DIAGRAMA DE ACTIVIDADES “Facturación “ SE ESPERA EL REPORTE DE FACTURACIÓN SE RECIBE EL REPORTE Y EL DINERO SE CONSIGNA EL DINERO EN BANCO SE LE ENVIA A SE LE ENVIA A CONTABILIDAD LA COPIA PRESUPUESTO EL DE LA CONSIGNACIÓN VALOR DE LA JUNTO CON LAS CxC FACTURACION DEL DIA ANEXO #16: DIAGRAMA DE ACTIVIDADES “Tesorería “ SE ESPERA EL REPORTE DE TESORERIA SE RECIBE EL REPORTE SE REGISTRAN SE REGISTRAN SE REGISTRAN LAS CxC LOS INGRESOS GASTOS Y EGRESOS SE ENVIA UN INFORME A GERENCIA SI LO REQUIERE ANEXO #17: DIAGRAMA DE ACTIVIDADES “Contabilidad” ESPERA INFORME DE TESORERIA SE RECIBE EL INFORME SE REALIZAN LOS DESCARGOS NECESARIOS AL PRESUÚESTO SE ENVIA UN INFORME A GERENCIA SI ESTE LO REQUIERE ANEXO #18: DIAGRAMA DE ACTIVIDADES “Presupuesto“ NECESITAR SERVICIO MEDICO LLEGAR AL HOSPITAL LLEGAR A ADMISION (CASO CONTRARIO) (ADMITIDO) NINGÚN SERVIC IO RECIBIR COBRO CANCELAR EFECTIVO RECIBIR SERVICIO SALIR DEL H.L.A. ANEXO #19: DIAGRAMA DE ACTIVIDADES “Paciente” CLIENTE FACTURACIÓN INFORME EN PAPEL TESORERÍA INFORME EN PAPEL INFORME EN PAPEL CONTABILIDAD PRESUPUESTO INFORME EN PAPEL INFORME EN PAPEL GERENCIA ANEXO #20: DIAGRAMA DE DESPLIEGUE DIAGRAMAS TRADICIONALES DEL SISTEMA PROPUESTO Contabilidad Gerencia Tesorería Presupuesto Admisión Facturación Servicios Paciente ANEXO # 27. DIAGRAMA DE CONEXIÓN DE PUESTOS 1:M Cobra 0:M Servicios 1:M Solici ta 1:M 1:M Servi cios x 1:M Paciente admisión Admisión Cobrar Facturación 0:M Paga 0:M Servicios 1:M Paga 1:M Servicios 1:M Recibe 1:M Servicios orden 0:1 Inf. De serv. 0:1 Dinero+comp Tesorería Prestados /D de consing. Presupuesto 0:1 Contabilidad 0:1 Emite Gerencia reporte ANEXO # 22. DIAGRAMA DE ENTIDAD RELACIÓN 8 Contabilidad 10 Tesorería 4 9 11 7 Presupuesto 1 3 5 Paciente Admisión Facturación Servicios 2 6 12 Gerencia Salida 1. Solicitud de Admisión 2. Admisión o rechazo 3. Envío de información para cobro 4. Pago de servicios 5. Emisión de orden de servicios 6. Prestación de servicios 7. Envío de información de transacción 8. Envío de información contable y transacciones 9. Reporte de ingresos totales por servicios prestados 10. Reporte a Gerencia 11. Reporte a Gerencia 12. Salida del sistema ANEXO # 23. DIAGRAMA DE CONTEXTO Paciente Solicitud de Admisión Paciente servicios Esperar x servicios Cobro x servicios Solicitud de Servi cios Datos Es o no Facturación admitido Orden de salida Salida ANEXO # 24. DIAGRAMA PRIMIGENIO DE FLUJO DE DATOS Solicitud de Admisión Es o no Facturación servicios admitido Solicitud denegada Salida ANEXO # 25. DIAGRAMA PRIMIGENIO DE FLUJO DE DATOS Tesorería Servicios Orden de Facturación Servicios solicitados servicio Emisión de cobro Pago de servicios Paciente ANEXO # 26. DIAGRAMA PRIMIGENIO DE FLUJO DE DATOS DIAGRAMAS TRADICIONALES DEL SISTEMA PROPUESTO Entidad Paciente Admisión Servicios Facturación Tesorería Contabilidad Presupuesto Paciente Solicita ser Recibe uno o Cancela admitido mas servicios prestados Admisión Admite o no Emite lista de servicios por cobrar Servicios Presta 1 ó Recibe mas orden de servicios servicios Facturación Cobra por Recibe lista Envía copia servicios y de servicios de facturas y emite factura sugeridos recibo de consignación de efectivo Tesorería Recibe copia Emite Emite de facturas y informe informe de recibo de financiero presupuesto consignación de efectivo Contabilidad Recibe informe financiero Presupuesto Recibe informe de presupuesto ANEXO # 21: MATRIZ DE RELACIONES