JENNIFER POSSO HENAO

CTC COMITÉ TÉCNICO CIENTÍFICO

JENNIFER POSSO HENAO

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERIA INFORMATICA

SANTIAGO DE CALI 2008

CTC COMITÉ TÉCNICO CIENTÍFICO

JENNIFER POSSO HENAO

Pasantía para optar al título de Ingeniero Informático

Director JESÚS ANTONIO LEMOS

Ingeniero Electricista Magíster en ciencias Computacionales

UNIVERSIDAD AUTÓNOMA DE OCCIDENTE FACULTAD DE INGENIERIA

DEPARTAMENTO DE CIENCIAS DE LA INFORMACION PROGRAMA DE INGENIERIA INFORMATICA

SANTIAGO DE CALI 2008

Nota de aceptación: Aprobado por el Comité de Grado en cumplimiento de los requisitos exigidos por la Universidad Autónoma de Occidente para optar al título de Ingeniero Informático.

Ing. JESÚS ANTONIO LEMOS ___________________________ Director

Santiago de Cali, Febrero de 2008.

AGRADECIMIENTOS

Porque gracias a su cariño, guía y apoyo he llegado a realizar uno de mis anhelos más grandes de mi vida, fruto del inmenso apoyo, amor y confianza que en mi se deposito y con los cuales he logrado terminar mis estudios profesionales que constituyen el legado más grande que pudiera recibir y por los cuales les viviré eternamente agradecida. Con cariño y respeto.

CONTENIDO

Pág.

GLOSARIO 15

RESUMEN 16

INTRODUCCIÓN 17

1. PLANTEAMIENTO DEL PROBLEMA 18

2. MARCO TEÓRICO 19

2.1 LEVANTAMIENTO DE REQUISITOS 19

2.2 ANÁLISIS Y DISEÑO 20

2.3 DIAGRAMA DE CASOS DE USO 21

2.4 DIAGRAMAS DE SECUENCIA 21

2.5 IMPLEMENTACIÓN 22

2.6 LENGUAJES DE PROGRAMACIÓN 22

2.6.1 Visual basic 22

2.6.2 Visual basic .net 23

2.6.3 Sybase 24

3. ANTECEDENTES 26

4. OBJETIVOS 27

4.1 OBJETIVOS GENERAL 27

4.2 OBJETIVOS ESPECIFICOS 27

5. JUSTIFICACIÓN 28

6. METODOLOGÍA 29

7. DESARROLLO DEL PROYECTO 30

8. ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE 31

8.1 ANTECEDENTES 31

8.2 ALCANCE 31

8.3 OBJETIVO DEL PROYECTO 32

8.3.1 Objetivos específicos 32

9. DEFINICIÓN DEL SISTEMA 33

10. LISTA DE REQUISITOS FUNCIONALES 34

11. ESPECIFICACIONES SUPLEMENTARIOS (NO FUNCIONALES) 36

11.1 Seguridad 36

11.2 CONFIABILIDAD 37

11.3 USABLE 37

11.4 ADAPTABILIDAD 37

11.5 PORTABILIDAD 37

11.6 UTILIDAD 38

12. DEFINICIÓN DE ACTORES 39

12.1 ACTORES 39

13. LISTADO DE CASOS DE USO 40

13.1 DIAGRAMA DE CASOS DE USO 41

13.2 DESCRIPCIÓN DE CASOS DE USO 41

13.2.1 CU_01 Ingresar al sistema 41

13.2.2 CU_02 Crear usuario 43

13.2.3 CU_03 Modificar usuario 45

13.2.4 CU_04 Consultar usuario 48

13.2.5 CU_05 Deshabilitar/habilitar usuario 50

13.2.6 CU_06 Ingresar solicitud 52

13.2.7 CU_07 Modificar solicitud 54

13.2.8 CU_08 Consultar solicitud 57

13.2.9 CU_09 Estudio médico 60

13.2.10 CU_10 Evaluar solicitud 62

13.2.11 CU_11 Modificar estudio medico 65

13.2.12 CU_12 Ingresar medico tratante 68

13.2.13 CU_13 Ingresar ips 70

13.2.14 CU_14 Ingresar paciente 72

13.2.15 CU_15 Ingresar medicamento 74

13.2.16 CU_16 Realizar informe 76

14. MATRIZ CASOS DE USO – REQUISITOS 78

15. INTERFACES 80

16. MODELO DE ARQUITECTURA DE CASO DE USO 81

16.1 CASOS DE USO SIGNIFICATIVOS 81

16.2 DESCRIPCIÓN TEXTUAL 81

17. MODELO DE ANÁLISIS DEL SISTEMA 83

17.1 REALIZACIÓN DE CASOS DE USO 83

17.1.1 CU_01 Ingresar al sistema 83

17.1.2 CU_02 Crear usuario 85

17.1.3 CU_03 Modificar usuario 87

17.1.4 CU_04 Consular usuario 89

17.1.5 CU_05 Deshabilitar/habilitar usuario 91

17.1.6 CU_06 Ingresar solicitud 92

17.1.7 CU_07 Modificar solicitud 95

17.1.8 CU_08 Consultar solicitud 97

17.1.9 CU_09 Estudio médico 99

17.1.10 CU_10 Evaluar solicitud 101

17.1.11 CU_11 Modificar estudio medico 103

17.1.12 CU_12 Ingresar medico tratante 105

17.1.13 CU_13 Ingresar ips 107

17.1.14 CU_14 Ingresar paciente 108

17.1.15 CU_15 Ingresar medicamento 110

17.1.16 CU_16 Realizar informe 111

18. PAQUETES DE ANÁLISIS 113

19. DESCRIPCIÓN DE PAQUETES DE ANÁLISIS 116

19.1 PAQUETE: “UI PACKAGE” 116

19.2 PAQUETE: “CONTROL PACKAGE” 116

19.3 PAQUETE: “ENTITY PACKAGE” 117

20. DESCRIPCIÓN DE ARQUITECTURA 118

21. DISEÑO Y MODELO DE DATOS 121

21.1 MODELO ENTIDAD RELACIÓN MER 121

21.2 MODELO RELACIONAL DE DATOS 122

22. CONCLUSIONES 127

23. RECOMENDACIONES 128

BIBLIOGRAFIA 129

ANEXOS 130

LISTA DE TABLAS

Pág. Tabla 1. Requerimientos Funcionales del Sistema 34 Tabla 2. Requerimientos No Funcionales del Sistema 36 Tabla 3. Lista de Casos de Uso 40 Tabla 4. CU_01 Ingresar al Sistema 42 Tabla 5. CU _ 02 Crear Usuario 43 Tabla 6. CU_03 Modificar Usuario 45 Tabla 7. CU_04 Consultar Usuario 48 Tabla 8. CU_05 Deshabilitar / Habilitar Usuario 50 Tabla 9. CU_06 Ingresar Solicitud 52 Tabla 10. CU_07 Modificar Solicitud 55 Tabla 11. CU_08 Consultar Solicitud 58 Tabla 12. CU_09 Estudio Médico 60 Tabla 13. CU_10 Evaluar Solicitud 63 Tabla 14. CU_11 Modificar Estudio Medico 65 Tabla 15. CU_12 Ingresar Médico Tratante 68 Tabla 16. CU_13 Ingresar IPS 70 Tabla 17. CU_14 Ingresar Paciente 72 Tabla 18. CU_15 Ingresar Medicamentos 74 Tabla 19. CU_16 Realizar Informe 76 Tabla 20. Matriz de Requisitos 78

Tabla 21. MRD Paciente. 122 Tabla 22. MRD Médico Tratante. 122 Tabla 23. MRD Tabla Ciudad. 123 Tabla 24. MRD Departamento. 123 Tabla 25. MRD Medicamento. 123 Tabla 26. MRD Evaluación Solicitud. 124 Tabla 27. MRD Solicitud. 124 Tabla 28. MRD IPS. 124 Tabla 29. MRD Entidad Patológica. 125 Tabla 30. MRD Actas. 125 Tabla 31. MRD Presentación Medicamento. 125 Tabla 32. Unidades de Concentración. 125 Tabla 33. MRD Perfil de Usuario. 126 Tabla 34. MRD Usuario 126 Tabla 35. MRD Bitácora. 126

LISTA DE FIGURAS

Pág.

Figura 1. Diagrama de Casos de Uso 41

Figura 2. Interfaz del Sistema 80

Figura 3. Modelo de la Arquitectura 81

Figura 4. Diagrama de Clase CU_01 83

Figura 5. Diagrama de Secuencia CU_01 84









Figura 14. Diagrama de Clase CU_06. 92







Figura 21. Diagrama de Secuencia 100





Figura 26. Diagrama de Clase 105










Figura 36. Arquitectura Cliente/Servidor 118

Figura 37. Modelo de Capas 119

Figura 38. Modelo Entidad Relación. 121

LISTA DE ANEXOS

Pág.

Anexo 1. Formato Ingreso de Solicitud 130

GLOSARIO ADMINISTRADOR: es el encargado del manejo general del sistema para el Comité Técnico Científico CTC, puede ser del personal de informática o el correspondiente asignado por la empresa del Seguro Social. CASO DE USO: en ingeniería del software, un caso de uso es una técnica para la captura de requisitos potenciales de un nuevo sistema o una actualización software. Cada caso de uso proporciona uno o más escenarios que indican cómo debería interactuar el sistema con el usuario o con otro sistema para conseguir un objetivo específico. COMITÉ TÉCNICO CIENTÍFICO (CTC): el Comité Técnico Científico se ha creado para funcionar por la Superintendencia Nacional de Salud. Las entidades promotoras de Salud, EPS y demás entidades obligatorias a compensar, EOC y las administradoras del régimen subsidiado, ARS, integraron un Comité Técnico Científico CTC, que está conformado por un representante de la EPS, EOC o ARS, según corresponda, un representante de las Instituciones Prestadoras de Salud, IPS, y un representante de los usuarios. CONSULTOR: es el encargado solo y únicamente de consultar las solicitudes que se ingresan en el sistema del Comité Técnico Científico, sean estas aprobadas, negadas o aplazados por el CTC. DIGITADOR: es el encargado de digitar las solicitudes de medicamentos que se encuentran en el Comité Técnico Científico CTC. FOSYGA: es el Fondo de Solidaridad y Garantía, a la cual se envían los formatos de las solicitudes por concepto de medicamentos no incluidos en el Plan Obligatorio de Salud, Pos y fallos de tutela. IU: (User Interface) interfaz grafica de usuario MEDICO: es el encargado de la aprobación, negación o aplazo de las solicitudes de medicamentos en el Comité Técnico Científico, puede ser médico general, químico, farmacéutico o profesional de la salud, este último con experiencia comprobada en el área de farmacología de mínimo dos (2) años. SYBASE: base de datos que maneja el Seguro Social.

RESUMEN

La historia de la humanidad ha pasado por diferentes etapas de evolución de sus formas de producción y organización, correspondiendo a cada una de ellas su respectivo modo de vivir, pensar conocer, es decir, ética, razón y ciencia. En la actualidad los cambios sociales, económicos y culturales están dando pie a una nueva sociedad que se ha dado cuenta que la información es la parte principal y el activo más importante de las empresas y gracias al surgimiento de nuevas tecnologías, se ha logrado realizar sistemas que nos ayudan a administrar y acceder a ella cuando lo necesitamos, donde lo necesitemos con gran eficiencia y eficacia. Con este trabajo de grado planteó diseñar y construir un sistema de información que permita automatizar los procesos del comité Técnico Científico CTC de la Empresa Del Seguro Social, permitiendo a diferentes usuarios (digitador, medico, consultor y administrador) tener acceso a la información que el proyecto genere. Con este sistema se pretende contribuir de forma positiva en los siguientes aspectos: • Cultural: resguarda la creación de una nueva cultura en los usuarios al ofrecer un nuevo estilo sobre cómo realizar estos procesos y propicia que cada uno de los usuarios se apersone de su información y siempre este pendiente de cómo avanza el proceso, teniendo en cuenta que estos procesos son de gran importancia para el Comité Técnico Científico CTC. • Administrativo: soporta que el Comité Técnico Científico CTC administre mejor la información ya que esta se encuentra almacenadas en sistemas gestores de datos que garantizan la disponibilidad, integridad y fácil acceso a la misma.

17

INTRODUCCIÓN Lo más importante de toda empresa es llevar a cabo una gran administración de su información, para así lograr confiabilidad y mayor control a la hora de tomar decisiones contribuyendo al éxito de la misma. Actualmente las grandes Empresas ejercen sus funciones bajo sistemas que permiten almacenar toda su información, logrando una mejor eficiencia al momento de ingresar todos los datos con procesos computarizados, definiendo así, la calidad del software como la concordancia entre los requerimientos funcionales, el rendimiento explícitamente establecido, los estándares de desarrollo explícitamente documentados y las características implícitas que se espera de todo software desarrollado profesionalmente. El Instituto Seguro Social, es una de las Empresas más importante del Estado y el principal actor en el campo de la seguridad social en Colombia, con la misión de brindar aseguramiento a los trabajadores, Empresas y jubilados colombianos y a sus familias en los rubros de pensión, salud y riesgos profesionales. Hoy en día la EPS Seguro Social cuenta con el Comité Técnico Científico (CTC), que surge como respuesta a las dificultades presentadas en el manejo de solicitudes de medicamentos, las cuales son estudiadas y evaluadas de acuerdo a criterios médicos establecidos para los procedimientos, los formatos y los registros para la solicitud y aprobación de medicamentos esenciales que no están incluidos en el Plan Obligatorio de Salud (POS). El propósito de este proyecto es agilizar el ingreso de las solicitudes de medicamentos mediante procesos automatizados, de tal manera que tengan un registro confiable en el transcurso del procesamiento de esta información.

18

1. PLANTEAMIENTO DEL PROBLEMA

La EPS Seguro Social, sede Bellavista en Cali, en su obligación de prestar un servicio oportuno a sus afiliados, en cuanto a las solicitudes de medicamentos que no están incluidos dentro del Plan obligatorio de Salud (POS), crea la oficina Comité Técnico Científico (CTC), encargada de recepcionar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, prórroga y/o negación de la solicitud de medicamentos y, así mismo, de enviar a la oficina de recobros las solicitudes aprobadas por el Comité Técnico Científico(CTC), en el respectivo formato establecido, para luego ser enviadas al Fondo de Solidaridad y Garantía (FOSYGA), y hacer su respectivo cobro. Debido al elevado crecimiento de las solicitudes de medicamentos y a la necesidad de brindar una respuesta oportuna, fiable y estadística al afiliado, se crea un software para tal fin, el cual está presentando inconvenientes. A partir de este problema se redefinen cuáles son las necesidades que requiere el software para lograr un óptimo desempeño, ya que a partir de esas necesidades se da a conocer cuál es la importancia y las funciones que debe realizar la aplicación, de no ser así, se ocasionan diversos problemas, como los de diseño e implementación, al punto de convertirse en la necesidad de desarrollar un nuevo software aplicativo que resuelva los inconvenientes que actualmente está presentando.

19

2. MARCO TEÓRICO Este proyecto tiene la finalidad de analizar, diseñar e implementar un software aplicativo haciendo uso de la ingeniería de software, y del lenguaje unificado UML para: visualizar, especificar, construir y documentar la aplicación a desarrollar, ofreciendo un estándar para describir correctamente el sistema que se va a establecer. Los objetivos de la ingeniería de software son: • Mejorar la calidad de los productos software.

• Facilitar el control del proceso de desarrollo de software. • Suministrar a los desarrolladores las bases para construir software de alta calidad de una forma eficiente. • Definir una disciplina que garantice la producción y el mantenimiento de los productos de software desarrollados en el plazo fijado y dentro del costo estimado. A continuación se ilustran las fases del desarrollo aplicadas a contexto del Proyecto. 2.1 LEVANTAMIENTO DE REQUISITOS El levantamiento de requisitos son aquellas descripciones de los servicios proporcionados por el sistema y sus restricciones operativas donde se reflejan las necesidades de los interesados, que ayuda a resolver algún problema. Este proceso establece los servicios que el cliente requiere de su sistema y los limites bajo los cuales opera y se desarrolla. La necesidad de establecer requisitos es fundamental en el momento de realizar el proyecto, ya que estos requerimientos especifican las prioridades de las funcionalidades y los niveles de operaciones que requiere el software. Durante el levantamiento de requerimientos se tendrá en cuenta el análisis previo del funcionamiento que realiza el aplicativo para el almacenamiento de datos e igualmente, ir definiendo poco a poco los requerimientos funcionales y no funcionales.

20

Para el presente proyecto se debe realizar un sistema de información administrativa destinada al almacenamiento de las solicitudes de medicamentos al sistema, además de permitir modificar ciertos datos únicamente bajo criterios médicos, permitiendo hacer consultas de las solicitudes ingresadas anteriormente. Este sistema debe guardar automáticamente los datos ingresados por el digitador de manera que el usuario pueda registrar un nuevo proceso. Como otros requerimientos para el sistema, hay que asegurar que el tiempo de respuesta del sistema sea el apropiado dentro de las factibilidades técnicas y de las necesidades del usuario. El sistema debe operar, ordenar y estandarizar datos y reportes de los distintos procesos que requiera el Comité Técnico Científico (CTC), para que genere su respectivo formato y facilite la interpretación de los datos que contenga. En el proceso de levantamiento de requerimientos, el sistema debe generar ciertas actividades que durante el proceso de esta primera etapa se definirán de acuerdo a las solicitudes que el cliente requiera. La definición de los requisitos se llevara a cabo mediante la participación de comités, los cuales se organizarán en convenio con el Comité Técnico Científico (CTC). 2.2 ANÁLISIS Y DISEÑO

Durante el análisis y el diseño del proyecto, se analizan los requisitos que se describieron en la anterior etapa, refinándolos y estructurándolos con el objetivo de conseguir una comprensión más precisa de los requisitos y una descripción de los mismos, para que sea fácil mantener y estructurar el sistema entero en el cual se va a trabajar. La descripción se hace en tres pasos: Identificación de artefactos, roles y actividades. Para la identificación de artefactos a desarrollar, se debe tener en cuenta los recursos que maneja el Comité Técnico Científico (CTC) para su respectiva documentación y, así, poder construir adecuadamente el software a implementar; los roles que participan, son las relaciones de usuarios que hacen uso directamente de esta aplicación y las actividades que se desarrollan, es decir, son las funciones principales que maneja el Comité Técnico Científico (CTC). Con el análisis nos enfocamos a estructurar los requisitos de un modo que facilita su compresión, su preparación, su modificación y en general su mantenimiento para considerar una primera aproximación al Diseño. El diseño del sistema describe la forma en cómo el sistema cumplirá con los requisitos identificados. El

21

diseñador realiza esquemas, describe estructuras de archivos, identifica datos de entrada y salida, y los representa mediante diagramas, tablas y símbolos. Para la etapa de diseño se hace referencia a la integración de los Diagramas de Casos de Uso y los Diagramas de Secuencia, la información detallada en esta fase se proporciona al equipo de programación para comenzar con la fase de desarrollo y, así llevar a cabo una estructura detallada del sistema, para seguir al paso de implementación. 2.3 DIAGRAMA DE CASOS DE USO En un diagrama de casos de uso se representa gráficamente parte o el total de las personas involucradas y casos de uso, es decir, acciones que realiza el software incluyendo sus interacciones, donde se ve el entorno del sistema a realizar y su funcionalidad principal. Durante el desarrollo del los casos de uso del proyecto “CTC Comité Técnico Científico” se especificará cada actividad y función que debe realizar el software y las personas involucradas, haciendo una descripción detallada de las actividades correspondientes a realizar en el software aplicativo. Estas descripciones ayudarán en la formación adecuada de un buen desarrollo, especificando paso a paso lo que se debe hacer y cómo se desempeña cada actividad, es decir, si la actividad a realizar es el ingreso de una nueva solicitud, el diagrama de caso de uso me especificara gradualmente como se hace el respectivo ingreso de la solicitud. Se tendrá en cuenta para la realización de cada Caso de Uso los prerrequisitos, antecedentes y post- condiciones que abarca cada una de las actividades a desarrollar. En el diagrama de casos de uso se mostrara, por tanto, los distintos requisitos funcionales que se establecieron en la primera etapa de levantamiento de requisitos, en el que se aplican todas las exigencias que cumple el Comité Técnico Científico (CTC) para el funcionamiento adecuado del aplicativo software a realizar. 2.4 DIAGRAMAS DE SECUENCIA

El Diagrama de Secuencia es uno de los diagramas más efectivos para modelar interacción entre objetos que realiza el proyecto, este diagrama se modela para cada caso de uso, en donde el diagrama de secuencia contiene los detalles de

22

implementación del escenario, incluyendo los objetos y clases que se usan para implementar, y mensajes pasados entre los objetos. En esta etapa, las clases tienen ya definidas las operaciones que debe realizar el software requerido por el Comité Técnico Científico (CTC), estas clases se definen durante el proceso de construcción de los diagramas de secuencia para cada respectivo caso de uso y así poder realizar la implementación necesaria en la siguiente etapa. Propiamente se evalúa la descripción de un caso de uso para determinar qué objetos son necesarios para la implementación del escenario. Al terminar la etapa de diseño, hemos refinado suficientemente los Diagrama de Casos de Uso, Diagramas de Secuencia y las relaciones entre estas. También conocemos mejor los mensajes que se intercambian los objetos para realizar las tareas necesarias. Durante la siguiente etapa nuevamente entraremos en otro ciclo para mejorar algunos detalles que se hacen visibles sólo al momento de la implementación. 2.5 IMPLEMENTACIÓN

La implementación del proyecto tiene como significado el análisis lógico, para así mismo efectuar la implementación física, donde se lleva a cabo la forma cómo se va a desarrollar el sistema y cómo es capaz de responder a las peticiones descritas por el conjunto de requerimientos, análisis e interfaces a las que proporciona su realización. Para realizar la implementación del sistema software se tendrá en cuenta bajo que lenguaje de programación se va a realizar, operando sobre las herramientas que trabaja el Seguro Social. Dentro de los lenguajes de programación más utilizados en la Empresa, la cual maneja la mayor parte de sus aplicaciones bajo las siguientes herramientas de programación: 2.6 LENGUAJES DE PROGRAMACIÓN

2.6.1 Visual Basic . “Visual Basic es una herramienta de diseño de aplicaciones para Windows, en la que se desarrollan en una gran parte, a partir del diseño de una interfaz grafica. En una aplicación visual Basic, el programa está formado por

23

una parte de código puro, y otras partes asociadas a los objetos que forman la interfaz grafica”1. Es un lenguaje de fácil aprendizaje pensado, guiado por eventos, y centrado en un motor de formularios que facilita el rápido desarrollo de aplicaciones graficas. No requiere de manejo de punteros y posee un manejo muy sencillo de cadenas de caracteres, permitiendo varias bibliotecas para maneo de bases de datos, es por tanto un término medio entre la programación Visual Basic es una herramienta de diseño de aplicaciones para Windows, en la que se desarrollan en una gran parte, a partir del diseño de una interfaz grafica. En una aplicación visual Basic, el programa está formado por una parte de código puro, y otras partes asociadas a los objetos que forman la interfaz grafica. Es un lenguaje de fácil aprendizaje pensado, guiado por eventos, y centrado en un motor de formularios que facilita el rápido desarrollo de aplicaciones graficas. No requiere de manejo de punteros y posee un manejo muy sencillo de cadenas de caracteres, permitiendo varias bibliotecas para maneo de bases de datos, es por tanto un término medio entre la programación tradicional, formada por una sucesión lineal de código estructurado, y la programación orientada a objetos, combinando ambas tendencias. Este lenguaje es utilizado principalmente para aplicaciones de gestión de Empresas, debido a la rapidez con la que puede hacerse un programa que utilice una base de datos sencilla. El Seguro social trabaja Visual Basic por ser una herramienta de fácil manejo a la hora de creación de programación que maneja formularios, lo cual Visual Basic permite: Creación de una interfaz de usuario. Definición de las propiedades de los controles – objetos. Generación del código asociado a los eventos que ocurran a los objetos, que se generan de acuerdo a las necesidades del programa. Generación del código del programa 2.6.2 Visual Basic .NET . “Cada vez más organizaciones de todos los tamaños, con programadores de Visual Basic de todos los niveles de conocimiento, están reconociendo el amplio conjunto de características y los nuevos niveles de

1 Wikipedia. Enciclopedia Libre [en línea].Florida: Microsoft Visual Basic, 2007. [Consultado 05 de noviembre, 2007]. Disponible en internet: http://es.wikipedia.org/wiki/Visual_Basic

24

productividad que ofrece Visual Basic .NET, y están implementando sus aplicaciones cruciales utilizando esta lenguaje de programación”2. Actualmente Visual Basic .NET, ofrece capacidades de diseño completamente orientado a objetos y acceso directo a Microsoft .NET, Framework, entorno que proporciona un amplio conjunto de interfaces de programación de aplicaciones para Windows e Internet. Visual Basic .NET proporciona una mejora en la seguridad, administración de la memoria, control de las versiones y compatibilidad con la implementación a desarrollar. Otras de sus características más importantes son:

• Diseño de controles de usuario para aplicaciones Windows y Web. • Programación de bibliotecas de clase. • Envió de datos vía documentos XML. • Generación de reportes basados en Crystal Reports a partir de información obtenida de orígenes de datos. Por razón de este lenguaje de programación nos enfocamos a realizar el presente proyecto para el Comité Técnico Científico (CTC) del Seguro social.

2.6.3 Sybase . “La toma intuitiva de decisiones requiere de un extra en el mundo competitivo de hoy. Responder a la demanda de la inteligencia de negocio, análisis avanzado de datos, modelamiento predictivo, regulaciones estrictas y extremadamente rápida generación de reportes, requiere más de lo que un sistema tradicional de gestión de datos puede manejar”3. Sybase es una compañía líder en el desarrollo y expansión de tecnología innovadora para la movilización de información, Sybase se ha ganado la confianza de muchas de las compañías más importantes del mundo por su habilidad en la gestión de información. Con una base global y leal de clientes y una fuerte presencia en mercados verticales clave, como servicios financieros, telecomunicaciones, salud y gobierno, Sybase ha permitido materializar, a clientes de todos los tamaños. Sus soluciones abiertas y multiplataforma entregan la información de manera segura, en cualquier momento y lugar, permitiendo que los clientes creen una ventaja de información, con las soluciones de software Sybase, los clientes pueden optimizar y mejorar

2 Ibíd.., Disponible en Internet: http://es.wikipedia.org/wiki/Visual_Basic 3 MTBase Sybase de Colombia [en línea]. Colombia: Sybase de Colombia. [Consultado 10 de noviembre, 2007]. Disponible en Internet http://www.mtbase.com/productos/gestionbasesdedatos

25

sus inversiones, relacionar sus recursos de información y extender el alcance de sus aplicaciones de negocio. Sybase es un motor de bases de datos altamente optimizado para inteligencia empresarial, utilizado por el instituto Seguro social. Diseñado específicamente para entregar resultados más rápidos en soluciones de inteligencia empresarial analítica de misión crítica, almacenamiento de datos y generación de reportes.

26

3. ANTECEDENTES Como quiera que la aplicación a desarrollar para el Comité Técnico Científico (CTC) se caracterice por ser un sistema que va dirigido, en particular a la persona que maneja el ingreso de las solicitudes de medicamentos de los afiliados al Seguro Social; no existe en el mercado un producto que, de manera genérica, pueda ser aplicado a este proceso. En la actualidad, el Seguro Social trabaja con un aplicativo generado por un contratista que implementó sin un previo análisis y diseño referente a las funciones del Comité Técnico Científico (CTC), que, a medida que crezcan las solicitudes de medicamentos y sus aplicaciones, no satisfará los requisitos concordantes, generando así, un nuevo levantamientos de la información que permita visualizar el proceso en curso. Del mismo modo, cabe apuntar, que el aplicativo en mención no es considerado, hoy, por el Seguro Social como “Crítico” para su funcionamiento, en tanto que existen actividades más importantes que requieren soluciones de mayor prioridad, presentando, también, inconvenientes cuando de generar los informes y llenar las solicitudes correspondientes a los medicamentos de los afiliados se trate, por esta razón se busca encontrar una solución optima al problema.

27

4. OBJETIVOS

4.1 OBJETIVOS GENERAL El presente documento tiene como objetivo analizar, diseñar y desarrollar un aplicativo software para el Comité Técnico Científico CTC, encargado de llevar a cabo el manejo de solicitudes de medicamentos no incluidos dentro del Plan Obligatorio de Salud (POS) para los afiliados al Seguro Social. 4.2 OBJETIVOS ESPECIFICOS • Estudiar y entender el proceso de solicitudes de medicamentos de acuerdo con criterios médicos. • Comprender el funcionamiento del sistema software que utiliza actualmente el Comité Técnico Científico (CTC). • Obtener información en tiempo real al servicio del Comité Técnico Científico (CTC). • Realizar el análisis y diseño del sistema que permita visualizar el proceso de una manera estandarizada. • Diseñar un aplicativo software integrado que dé soluciones eficaces y eficientes a los problemas actuales. • Desarrollar módulos dentro de la aplicación que generen informes estadísticos de gestión. • Evaluar el desempeño del sistema de información del Comité Técnico Científico • Implantar la solución en la órbita del Comité Técnico Científico (CTC) del Seguro Social.

28

5. JUSTIFICACIÓN El seguimiento de procesos bien definidos permite a toda organización tener un mejor control del capital humano como de las actividades y dispositivos que están involucrados en sus proyectos (personas, tiempos, documentación, responsabilidades, costos, entre otros) solucionando las disconformidades que se presentan. La realización de este proyecto es de vital importancia para la Empresa Instituto Seguro Social, por cuanto fortalece cualitativamente a la organización mediante la metodología planteada, un efectivo control y manejo de las solicitudes de medicamentos de sus afiliados con criterios médicos, mejorando la calidad y eficiencia en la prestación del servicio y una respuesta oportuna. Este proyecto apunta a unificar los formatos de solicitudes hechas por el Comité Técnico Científico (CTC), permitiendo mantener al día el registro de solicitudes de medicamentos del Plan Obligatorio de Salud (POS).

29

6. METODOLOGÍA

El proceso de desarrollo de software requiere de un conjunto de conceptos, una metodología y un lenguaje propio, denominado su “ciclo de vida”, y comprende cuatro grandes fases: concepción, elaboración, construcción y transición. La concepción define el alcance del proyecto y desarrolla un caso de negocio; la elaboración, el plan del proyecto y especifica las características y fundamenta la arquitectura; la construcción, crea el producto; y la transición, transfiere el producto a los usuarios. Para la realización del presente Proyecto, se seguirá la metodología estándar propia de la Ingeniería Informática, la cual es mundialmente reconocida como herramienta de la Ingeniería de Software. En su desarrollo utilizaremos el “Modelo en Cascada” que ordena, en forma secuencial, las etapas del ciclo de vida del proyecto, de tal modo que el inicio de cada una debe esperar la finalización inmediata de la anterior, como se anuncia a continuación: Paso uno: Análisis de requisitos Paso dos: Diseño del Sistema Paso tres: Diseño del Programa Paso cuatro: Implementación Paso quinto: Pruebas Paso sexto: Implantación

De suerte que cualquier error de diseño detectado en las etapas conduce, necesariamente, al rediseño de las anteriores y de las que siguen.

30

7. DESARROLLO DEL PROYECTO Para el presente proyecto se utilizó el Modelo Cascada, la cual esta está basada en el ciclo convencional de una ingeniería, abarcando las actividades para la realización y desarrollo del proyecto. Esta adaptación fue realizada en mutuo acuerdo entre los encargados del proyecto en el Comité Técnico científico CTC y dio origen a la metodología utilizada en el proyecto. Debido a la cantidad de procesos, al tamaño del sistema y su naturaleza Web se decidió utilizar el paradigma de desarrollo incremental, ya que este modelo es el que más se ajustó a las necesidades y es el más utilizado para el desarrollo Web. Para modelar los componentes y la iteración su utilizo el Lenguaje Unificado de Modelado (UML), y se modelaron los siguientes diagramas por cada modulo del sistema: • Diagramas de Casos de Uso. • Diagramas de Clases. • Diagramas de Secuencia. • Diagrama de Paquetes.

31

8. ESPECIFICACIÓN DE REQUERIMIENTOS DEL SOFTWARE 8.1 ANTECEDENTES

La Empresa Instituto Seguro Social sede administrativa Bellavista, tienen como actividad controlar el ingreso de solicitudes de medicamentos que no están incluidos dentro del Plan obligatorio de Salud (POS), la EPS cuenta con el Comité Técnico Científico (CTC), que surge como respuesta a las dificultades presentadas en el manejo de solicitudes de medicamentos, encargada de recepcionar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, aplazamiento y/o negación de la solicitud de medicamentos de los afiliados. Para este propósito se debe implementar un software que permita controlar las diferentes actividades que el Comité Técnico Científico (CTC) requiera para manejar las diferentes funciones más importantes y así tener un mayor control en el manejo de ingreso de solicitudes de medicamentos dando una solución optima para la Empresa.

8.2 ALCANCE La Empresa Instituto Seguro Social, entre sus servicios presta aseguramiento a los trabajadores, empresas y pensionados colombianos y sus familias en salud, pensiones, riesgos profesionales y otros seguros de protección social, orientados por los principios de universalidad, sostenibilidad, calidad y eficiencia. El Seguro Social maneja la oficina del Comité Técnico Científico (CTC), la cual es encargada de autorizar las solicitudes de medicamentos no incluidos en el Plan obligatorio de Salud (POS) de sus afiliados. El sistema permitirá manejar varios perfiles para el manejo de cada una de las actividades que se deseen realizar, esto se controlará dependiendo el nivel de seguridad que se asigne a cada perfil. El sistema se enfoca en el registro de las solicitudes de medicamentos no incluidos en el Plan Obligatorio de Salud (POS) diligenciadas de acuerdo a criterios médicos.

32

8.3 OBJETIVO DEL PROYECTO El objetivo del proyecto es desarrollar una aplicación software que permita ingresar, estudiar y evaluar de acuerdo a criterios médicos, la aprobación, prórroga y/o negación de la solicitud de medicamentos, asegurando el desarrollo y correcto desempeño de la aplicación. 8.3.1 Objetivos Específicos • Utilizar los procesos de ingeniería de software para lograr la correcta transformación de los requisitos del usuario en el sistema software. • Utilizar la disciplina de requisitos para delimitar la funcionalidad del sistema. • Asegurar la especificación y elaboración oportuna de los diferentes requisitos establecidos. • Determinar la importancia y complejidad de los diferentes procesos ejecutados en la empresa.

• Documentar y organizar la información para realizar la implementación

33

9. DEFINICIÓN DEL SISTEMA El usuario de este software debe, por lo menos, haber manejado programas básicos de office y tener conocimiento de cómo se debe diligenciar un formato de solicitud de medicamento que manejo el Comité Técnico Científico CTC. El sistema va dirigido básicamente a cinco usuarios finales: El Administrador: es el encargado de manejar el aplicativo en forma generar, es decir, puede realizar todas las funciones que realiza el software. El Digitador: es el encargado realizar el ingreso y modificación de las solicitudes antes de ser evaluadas bajo criterios médicos. El Médico: es el encargado de aprobar, aplazar y/o negar la solicitud ingresada por el digitador. El Consultor: es el encargado de consultar las solicitudes ingresadas al sistema e imprimirlas para enviarla a Fosyga o para entregar la solicitud al paciente. La impresora: es la encargada de imprimir las solicitudes y los reportes generados por el software. El software permitirá varias opciones, entre ellas se encuentran principalmente: Ingreso de solicitudes, Modificación de las solicitudes, la modificación de las solicitudes se realizara de acuerdo a criterios médicos, la solicitud ingresada solo pude ser modificada por el encargado con su respectivo perfil. Consultar solicitudes, La consulta de solicitudes se realiza cada vez que el usuario desee saber que solicitud es aprobada, aplazado y/o negada por el Médico del Comité Técnico Científico.

34

10. LISTA DE REQUISITOS FUNCIONALES A continuación en la tabla No.1 se presentan los requisitos funcionales que requiere el sistema: Tabla 1. Requerimientos Funcionales del Sistema

Requisitos Funcionales

RF1 El software debe permitir validar la fecha del sistema

RF2 El software debe permitir pedir login y password para ingresar al sistema

RF3 El software debe permitir crear usuario

RF4 El software debe permitir modificar usuario

RF5 El software debe permitir consultar usuario

RF6 El software debe permitir deshabilitar/habilitar usuario

RF7 El software debe permitir crear perfil

RF8 El software debe permitir modificar perfil

RF9 El software debe permitir deshabilitar/habilitar perfil de usuario

RF10 El software debe permitir ingresar solicitud

RF11 El software debe permitir consultar solicitudes para los perfiles asignados al aplicativo

RF12 El software debe permitir modificar solicitud para los perfiles asignados al aplicativo

RF13 El software debe permitir ingresar Medicamentos

RF14 El software debe permitir ingresar IPS

RF15 El software debe permitir ingresar Medico Tratante

35

Continuación Tabla 1. Requerimientos Funcionales del Sistema

RF16 El software debe permitir ingresar Paciente

RF17 El software debe permitir registro de usuario

RF18 El software debe permitir registro de formato de recobro enviado a Fosyga

RF19 El software debe permitir registro de formato de respuesta a solicitud de medicamentos entregado a paciente

RF20 El software debe permitir realizar informe de formato de recobro

RF21 El software debe permitir realizar informe de formato de solicitud de medicamentos

RF22 El software debe permitir ingresar datos de cotizante en caso que el cotizante del paciente no se encuentre en el sistema

RF23 El software debe permitir modificar la evaluación médica solo cuando el médico lo requiera antes de ser entregada o impresa al paciente

RF24 El software debe permitir imprimir reportes

RF25 El software debe permitir imprimir formato de recobro a Fosyga

RF26 El software debe permitir imprimir formato de solicitud de medicamento a paciente

RF27 El software debe permitir evaluar solicitudes, es decir, el médico tiene la opción de aprobar, negar y/o aplazar una solicitud de medicamento

RF28 El software debe permitir estudiar las solicitudes médicas, es decir el médico tiene la opción de mirar si la solicitud es correcta para luego ser evaluada.

RF29 El software debe permitir al médico modificar el estudio médico de una solicitud de medicamento

36

11. ESPECIFICACIONES SUPLEMENTARIOS (NO FUNCIONALES ) A continuación la tabla No.2 muestra los requerimientos no funcionales del sistema Tabla 2. Requerimientos No Funcionales del Sistema Requisitos No Funcionales.

RN1 El software no debe interferir en la ejecución de otros programas.

RN2 Validar que no haya duplicidad de usuarios.

RN3 Los colores de la aplicación deben ser acordes con el emblema de la empresa

RN4 El software debe validar la fecha del sistema

RN5 El software debe validar los campos correspondientes a cada formulario

RN6 Multiplataforma

RN7 Validar seguridad de perfiles

RN8 Los reportes deben tener la fecha correspondiente al día y el nombre del usuario que la realizo.

11.1 SEGURIDAD El sistema debe ser completamente seguro, es decir debe tener restricción de usuarios ya que no todas las personas que trabajen en la empresa tendrán acceso al aplicativo. El uso de los perfiles permitirá tener un control sobre las acciones realizadas por los usuarios sobre el sistema.

37

11.2 CONFIABILIDAD El sistema debe ser veraz y objetivo, es decir evitar adulteraciones a los datos del sistema y brindar la información precisa. El sistema debe de ser confiable ya que el software maneja una información muy importante. 11.3 USABLE

• Capacidad para ser entendido: cabe apuntar que el sistema se desempeñará con todos los requerimientos mediante un conjunto de herramientas que le permitirá al usuario un manejo simple y adecuado • Capacidad para ser aprendido: - El software brindara información relevante sobre su funcionamiento y operación de las actividades correspondientes. • Capacidad para ser operado: - El software debe permitir una buena interacción entre el usuario y la aplicación.

• Capacidad de atracción: - El software debe tener una apariencia visual llamativa al usuario.

11.4 ADAPTABILIDAD El sistema debe ser adaptable a todo tipo de cambio que ocurra en la empresa, desde cambio de clientes hasta el cambio de una maquina, en general a cualquier cambio que se presente. 11.5 PORTABILIDAD El software permita ser llevado a diferentes plataformas, de forma tal que su configuración en los diferentes entornos no genere cambios significativos en la aplicación.

38

11.6 UTILIDAD

Entendimiento básico en las solicitudes de medicamentos: el software será utilizado por personas con un entendimiento básico en el ingreso de solicitudes de medicamentos.

39

12. DEFINICIÓN DE ACTORES El sistema se enfocara principalmente en los siguientes actores: • Administrador. • Digitador. • Medico. • Consultor. • Impresora. 12.1 ACTORES Administrador: el administrador tiene todos los privilegios sobre el sistema, es decir, es el único que puede realizar operaciones de inserción, modificación o eliminación lógica sobre las actividades que realiza el software y la base de datos del sistema. Digitador: el digitador es el encargado de ingresar todas las solicitudes médicas, este podrá modificar las solicitudes antes de ser evaluadas por el médico. Médico: el médico es el encargado de estudiar las solicitudes médicas, es decir es el encargado de aprobar, negar y/o aplazar las solicitudes medicas con su respectiva descripción. Consultor: el consultor es el encargado de consultar que las solicitudes estén en correcto orden, éste también es el encargado de imprimir los formatos correspondientes. Impresora: la impresora es utilizada para la impresión de solicitudes y reportes generados por el sistema.

40

13. LISTADO DE CASOS DE USO A continuación se muestra el listado de casos de uso que maneja el sistema: Tabla 3. Lista de Casos de Uso

Casos de Uso Descripción CU CU_01 Ingresar al Sistema CU_02 Crear Usuario CU_03 Modificar Usuario CU_04 Consultar Usuario CU_05 Deshabilitar/Habilitar Usuario CU_06 Ingresar Solicitud CU_07 Modificar Solicitud CU_08 Consultar Solicitud CU_09 Estudio Medico CU_10 Evaluar Solicitud CU_11 Modificar Estudio Medico CU_12 Ingresar Medico Tratante CU_13 Ingresar IPS CU_14 Ingresar Paciente CU_15 Ingresar Medicamentos CU_16 Realizar Informe

(Ver Figura 1. Diagrama de Casos de uso en la página siguiente).

41

13.1 DIAGRAMA DE CASOS DE USO Figura 1. Diagrama de Casos de Uso

13.2 DESCRIPCIÓN DE CASOS DE USO 13.2.1 CU_01 Ingresar al Sistema Número: 001 Nombre de Caso de Uso: “Ingresar al Sistema” Actor(es): Administrador, Digitador, Médico, Consultor Descripción: Este caso de uso describe como el usuario ingresa al sistema

42

Tabla 4. CU_01 Ingresar al Sistema

FLUJO DE EVENTOS

CURSO NORMAL ALTERNATIVAS

1. El caso de uso inicia cuando el usuario administrador, digitador, médico o consultor selecciona el icono que activa la aplicación.

2. El sistema solicita al usuario ingresar los datos login y password.

3. El usuario ingresa login y password.

4. El usuario selecciona la opción Aceptar.

4.1. El usuario selecciona la opción Cancelar. 4.2. Flujo normal punto 10.

5. El sistema verifica la integridad de los datos. Verifica que los campos no estén vacíos.

5.1. Si el campo del login está vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3). 5.2. Si el campo del password está vacío este muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).

6. El sistema verifica que los datos de login y password sean correctos.

6.1. Si el login no se encuentra registrado en el sistema o el password no coincide para el login registrado el sistema envía un mensaje indicando este hecho (Flujo normal 3).

7. El sistema guarda el registro del usuario ingresado

8. El sistema muestra un mensaje de Bienvenida al usuario.

9. El sistema muestra un menú con las opciones: Usuarios, Solicitudes, Informes.

10. Finaliza CU_01 Pre-Condiciones Debe haber usuarios registrados al sistema. Post-Condiciones Un usuario accede al sistema Puntos de Extensión N/A

43

13.2.2 CU_02 Crear Usuario Número: 002 Nombre de Caso de Uso: “Crear Usuario” Actor(es): Administrador Descripción: Este Caso de Uso permite al administrador del sistema ingresar la información (datos personales) asociadas a un usuario. Tabla 5. CU _ 02 Crear Usuario

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador selecciona la opción Ingresar Usuario, que se encuentra en la interfaz principal.

2. El sistema muestra una interfaz solicitando al administrador que ingrese los datos del Usuario.

Datos - Identificación - Nombre(es) - Apellido(s) - Dirección - Teléfono - Login - Password - E-mail

- Perfil de usuario

3. El administrador ingresa la información del usuario: identificación, nombre (es), apellido(s), dirección, teléfono, login, password, e-mail, y perfil de usuario

4. El administrador selecciona la opción Aceptar.

4.1. El Administrador Cancela la operación. 4.2. Flujo normal punto 8.

44

Continuación Tabla 5. CU_02 Crear Usuario

5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos, que el usuario no esté en la base de datos y que el número de identificación y teléfono sean positivos.

5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).

5.2. Si el número de identificación del usuario ya está registrado en la base de datos, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).

5.3. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).

6. Los datos son ingresados a la base de datos.

7. El sistema muestra un mensaje de confirmación al administrador que la operación ha sido exitosa.

8. Finaliza CU_02

Pre-Condiciones El usuario NO debe existir en la base de datos Post-Condiciones Los datos del usuario quedan almacenados en el sistema. Puntos de Extensión N/A

45

13.2.3 CU_03 Modificar Usuario Número: 003 Nombre de Caso de Uso: “Modificar Usuario” Actor(es): Administrador Descripción: Este Caso de Uso le permite al usuario modificar información (datos personales) asociada a un usuario inscrito en la base de datos. Tabla 6. CU_03 Modificar Usuario

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador selecciona la opción Modificar Usuario que se encuentra en la interfaz principal.

2. El sistema le solicita al administrador que ingrese el número de identificación del usuario.

3. El administrador ingresa el número de identificación del usuario.

4. El administrador selecciona la opción Aceptar

4.1. El administrador Cancela la operación

4.2. Flujo normal punto 12.

46

Continuación Tabla 6. CU_03 Modificar Usuario

5. El sistema valida la integridad de los datos. Verifica que la casilla no esté vacía, que el cliente este registrado en la base de datos y que el número de identificación sea positivo.

5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3)

5.2. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3)

5.3. Si el número de identificación no se encuentra en el sistema, el sistema mostrará un mensaje indicando que el usuario no existe (Flujo normal punto 3).

6. Se muestra en pantalla el formulario de los datos personales asociados al usuario a modificar. (La información del usuario se obtiene del caso de uso CU_02)

7. El administrador modifica la información asociada al usuario. El administrador solo podrá modificar: - Dirección - Teléfono - e-mail - Perfil de usuario

7.1. El Administrador no cambia los datos cancelando la operación de modificación.

7.2. Flujo normal punto 12

47

Continuación Tabla 6. CU_03 Modificar Usuario

8. El sistema valida la información modificada del usuario. Verifica que la casilla no esté vacía y que el número de identificación sea positivo.

8.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 7)


9. El administrador escoge la opción Aceptar.

9.1. El administrador escoge la opción Cancelar.


10. El sistema guarda los cambios en la base de datos.

11. El sistema muestra un mensaje indicando que los datos han sido modificados satisfactoriamente.

12. Finaliza el CU_03

Pre-Condiciones Debe existir un Usuario en la base de datos Post-Condiciones Las modificaciones realizadas a los datos del usuario deben quedar almacenadas en la base de datos Puntos de Extensión CU_02

48

13.2.4 CU_04 Consultar Usuario Número: 004 Nombre de Caso de Uso: “Consultar Usuario” Actor(es): Administrador Descripción: Este Caso de Uso le permite al administrador mirar la información (datos personales) de un usuario registrado en la base de datos. Tabla 7. CU_04 Consultar Usuario

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador seleccionan la opción Consultar Usuario que se encuentra en la interfaz principal.

2. El sistema pide el número de identificación del usuario.

3. El administrador ingresa el número de identificación del usuario.


4.1. El administrador Cancela la operación.


49

Continuación Tabla 7. CU_04 Consultar Usuario

5. El sistema verifica la integridad de los datos. Verifica que la casilla no esté vacía, que el número de identificación sea positivo y que el número de identificación se encuentre en la base de datos.

5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal 3).


5.3. Si el número de identificación ingresado no es válido este muestra un mensaje indicando el error. (Flujo normal punto 3).

6. El sistema muestra en pantalla la

información asociada al usuario (La información asociada al usuario se obtiene del CU_02)


Pre-Condiciones Los datos del usuario deben estar almacenados en la base de datos Post-Condiciones N/A Puntos de Extensión CU_02

50

13.2.5 CU_05 Deshabilitar/Habilitar Usuario Número: 005 Nombre de Caso de Uso: “Deshabilitar/Habilitar Usua rio” Actor(es): Administrador. Descripción: Este Caso de Uso permite al administrador eliminar lógicamente a un usuario del sistema o habilitar usuarios que han sido deshabilitados por el administrador. Tabla 8. CU_05 Deshabilitar / Habilitar Usuario

FLUJO DE EVENTOS


1. El Caso de Uso inicia cuando el administrador selecciona la opción Deshabilitar/Habilitar Usuario que se encuentra en la interfaz principal

2. El sistema muestra en pantalla si desea deshabilitar/Habilitar Usuarios.

3. El administrador selecciona la opción Aceptar

3.1. El administrador Cancela la operación.


51

Pre-Condiciones Los datos del usuario deben estar almacenados en la base de datos Post-Condiciones Los datos del usuario deshabilitado no estarán disponibles nuevamente hasta que el administrador lo decida Los datos del usuario habilitado estarán disponibles nuevamente. Puntos de Extensión N/A

Continuación Tabla 8. CU_05 Deshabilitar / Habilitar Usuario

4. El sistema muestra los usuarios que se encuentran actualmente habilitados y deshabilitados

5. El administrador selecciona el usuario a cambiar de estado de la lista. Habilitado - Deshabilitado y Deshabilitado - Habilitado.

5.1. El administrador cancela la operación



6.1. El administrador selecciona la opción cancelar.


7. El Sistema deshabilita o habilita los clientes mostrados en pantalla.

8. Finaliza CU_05

52

13.2.6 CU_06 Ingresar Solicitud Número: 006 Nombre de Caso de Uso: “Ingresar Solicitud” Actor(es): Digitador Descripción: El Caso de Uso permite al usuario ingresar una nueva solicitud de medicamento al sistema Tabla 9. CU_06 Ingresar Solicitud

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador o el digitador selecciona la opción Ingresar Solicitud que se encuentra en la interfaz principal.

2. El sistema pide al usuario generar acta

3. El usuario selecciona la opción Aceptar

3.1. El usuario Cancela la operación (flujo normal punto 4, sigue con la secuencia anterior de actas)

4. El sistema muestra al usuario el

formato para el ingreso de solicitud.

53

Continuación Tabla 9. CU_06 Ingresar Solicitud

5. El Usuario digita los datos relacionados al formato de solicitud.

Datos: o Anexo No.1

5.1. Si el Médico tratante no se encuentra en el sistema, el usuario tiene la opción de Ingresar Médico Tratante (CU_12).

5.2. Si la IPS no se encuentra en el sistema, el usuario tiene la opción de Ingresar IPS (CU_13).

5.3. Si el Paciente no se encuentra en el sistema, el usuario tiene la opción de Ingresar Paciente (CU_14).

5.4. Si el Medicamento no se encuentra en el sistema, el usuario tiene la opción de Ingresar Medicamento (CU_15).


6.1. El usuario Cancela la operación 6.2. Flujo normal punto 8.

7. El sistema valida la integridad de los datos. Verifica que las casillas no estén vacías, que el número de identificación del paciente sea un número positivo, que el número de teléfono sea un número positivo, que el formato de la fecha sea válido y que el formato de comprobación de derechos sea positivo.

7.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).

7.2. Si el número de identificación del usuario es un número invalido, el sistema muestra un mensaje indicando el error y le dice que lo vuelva a intentar. (Flujo normal punto 3).

7.3. Si el formato de la fecha es invalido, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).

7.4. Si el teléfono es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 3).

7.5. Si el número de comprobación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).

54

Continuación Tabla 9. CU_06 Ingresar Solicitud

8. El sistema guarda los datos de la solicitud en la base de datos.

9. El sistema muestra un mensaje de confirmación al usuario que la operación ha sido exitosa.


Pre-Condiciones La solicitud NO debe existir en la base de datos Post-Condiciones El usuario ha ingresado una solicitud Puntos de Extensión CU_12, CU_13, CU_14, CU_15 13.2.7 CU_07 Modificar Solicitud Número: 007 Nombre de Caso de Uso: “Modificar Solicitud” Actor(es): Digitador Descripción: El Caso de Uso permite al usuario modificar una solicitud de medicamento que se encuentra en el sistema. La solicitud sólo puede ser modificada antes que el médico haga el estudio médico referente a la solicitud. (Ver Tabla 10. CU_07 Modificar Solicitud página siguiente).

55

Tabla 10. CU_07 Modificar Solicitud

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador o el digitador selecciona la opción Modificar Solicitud que se encuentra en la interfaz principal.

2. El sistema pide al usuario: Nombre del Paciente y Número de Identificación del paciente.

3. El usuario ingresa el nombre completo del paciente y Numero de Identificación del paciente.


4.1. El usuario Cancela la operación 4.2. Flujo normal punto 13

5. El sistema valida la integridad de los datos. Verifica que la casilla no esté vacía y que el número de identificación sea un número positivo.

5.1. Si el campo de texto se encuentra vacío el sistema muestra un mensaje indicando el error y le pide al usuario que lo vuelva a intentar. (Flujo normal punto 3).

5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).

56

Continuación Tabla 10. CU_07 Modificar Solicitud

6. El sistema verifica que el Nombre del paciente y el Número de Identificación sean correctos.

6.1. Si el nombre del paciente no se encuentra registrado en el sistema o el número de identificación no coincide para el número de identificación registrado en el sistema envía un mensaje indicando el error. (Flujo normal 3).

7. El sistema muestra la información

asociada al formato de solicitud. (Los datos se obtienen del caso de uso CU_06).

8. El usuario modifica los datos correspondientes a la solicitud.

8.1. El usuario Cancela la operación 8.2. Flujo normal punto 13


9.1. El usuario no cambia los datos de la solicitud Cancelando la operación


10. El sistema valida la integridad de los datos. Verifica que las casillas no estén vacías, que el número de identificación del paciente y del cotizante sea un número positivo, que el número de teléfono sea un número positivo y que el formato de la fecha sea válido.

10.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).

10.2. Si el número de identificación del usuario o cotizante es un numero invalido, el sistema muestra un mensaje indicando el error y le dice que lo vuelva a intentar. (Flujo normal punto 8).

10.3. Si el formato de la fecha es invalido, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).

10.4. Si el teléfono es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal punto 8).

57

Continuación Tabla 10. CU_07 Modificar Solicitud

11. El sistema guarda los cambios de la solicitud en la base de datos.



Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario ha modificado una solicitud Puntos de Extensión CU_06 13.2.8 CU_08 Consultar Solicitud Número: 008 Nombre de Caso de Uso: “Consultar Solicitud” Actor(es): Administrador, Digitador, Médico, Consultor e Impresora. Descripción: El Caso de Uso permite al usuario consultar una solicitud de medicamento que se encuentra en el sistema. (Ver Tabla 11. CU_08 Consultar Solicitud página siguiente).

58

Tabla 11. CU_08 Consultar Solicitud

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador, digitador, médico o consultor seleccionan la opción Consultar Solicitud que se encuentra en la interfaz principal.

2. El sistema pide el Número de Identificación del paciente o el Nombre completo del paciente al cual se desea consultar la solicitud.

3. El usuario ingresa el Número de identificación del paciente o Nombre completo del paciente.


4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 9

5. l sistema verifica la integridad de los datos. Verifica que la casilla no esté vacía o que el número de identificación sea positivo.

5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).


59

Continuación Tabla 11. CU_07 Consultar Solicitud

6. El sistema verifica que el Nombre del paciente o el Número de Identificación sean correctos.


7. El sistema muestra en pantalla la información asociada al paciente.

8. El usuario tiene la opción de imprimir la solicitud.

8.1. Si la solicitud es aprobada el sistema muestra la carta y el acta correspondiente a la aprobación de la solicitud

8.2. Si la solicitud es negada, el sistema muestra el acta correspondiente a la negación de la solicitud.

8.3. Si la solicitud es aplazada, el sistema muestra el acta correspondiente al aplazo de la solicitud

9. Finaliza el CU_08 Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario consulta una solicitud Puntos de Extensión N/A

60

13.2.9 CU_09 Estudio Médico Número: 009 Nombre de Caso de Uso: “Estudio Medico” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario realizar usuario la aprobación, aplazo y/o negación de la solicitud de medicamento. Tabla 12. CU_09 Estudio Médico

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el Médico seleccionan la opción Estudio Medico que se encuentra en la interfaz principal.

2. El sistema pide el Número de Identificación o Nombre completo del paciente al cual se le va a evaluar la solicitud

3. El Médico Ingresa el Número de Identificación del paciente o Nombre completo del paciente al cual se le va a evaluar la solicitud

4. El Médico selecciona la opción Aceptar

4.1. El Médico Cancela la operación


61

Continuación Tabla 12. CU_09 Estudio Médico

5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos y que el número de identificación sea un número positivo.

5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).

5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).



7. El sistema muestra los datos de

la solicitud. (Los datos se obtienen del caso de uso CU_06)

8. El Médico selecciona la opción Evaluar Solicitud. Se ejecuta caso de uso CU_10.



9. El sistema asocia la información de la solicitud con la evaluación medica




62

Continuación Tabla 12. CU_09 Estudio Médico

11. El sistema guarda los datos en la base de datos.

12. El sistema muestra un mensaje de confirmación al Medico que la operación ha sido exitosa.


Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario evalúa una solicitud Puntos de Extensión CU_06 y CU_10 13.2.10 CU_10 Evaluar Solicitud Número: 010 Nombre de Caso de Uso: “Evaluar Solicitud” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario realizar la aprobación, aplazo y/o negación de la solicitud de medicamento. (Ver Tabla 13. CU_10 Evaluar Solicitud página siguiente)

63

Tabla 13. CU_10 Evaluar Solicitud

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el Médico seleccionan la opción Evaluar Solicitud que se encuentra en la interfaz de Estudio Medico.

2. El sistema muestra en pantalla la interfaz con los datos a ingresar • Evalúo de Solicitud

o Solicitud Aprobada o Solicitud Negada o Solicitud Aplazada

• Descripción • Justificación • Criterios de autorización

3. El Médico ingresa los datos correspondientes a la interfaz. • Evaluó de Solicitud

o Solicitud Aprobada o Solicitud Negada o Solicitud Aplazada

• Descripción • Justificación • Criterios de autorización

3.1. Si el Médico selecciona la opción Solicitud Aprobada, el sistema habilitara los campos asociada a Solicitud Aprobada: Tiempo Autorizado, Cantidad Autorizada, Dosis Autorizada. (Flujo normal punto 3)

3.2. Si el Médico selecciona la opción Solicitud Negada, el sistema habilitara los campos asociados a Solicitud Negada: Causa Negación. (Flujo normal punto 3).

3.3. Si el Médico selecciona la opción Solicitud Aplazada, el sistema habilitara los campos asociados a Solicitud Aplazada: Motivo Aplazo. (Flujo normal punto 3).

3.4. Si el Médico no realiza la evaluación médica cancelando la operación. (Flujo normal punto 10.

64

Continuación Tabla 13. CU_10 Evaluar Solicitud


4.1. El Médico Cancela la operación 4.2. Flujo normal punto 10

5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos

5.1. Si el campo de texto se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al Médico que lo vuelva a intentar. (Flujo normal 3).

6. El sistema asocia la información de la solicitud con la evaluación médica.

7. El Médico selecciona la opción Aceptar 7.1. El Médico Cancela la operación 7.2. Flujo normal punto 10

8. El sistema guarda los datos en la base de datos.


10. Finaliza el CU_10 Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario evalúa una solicitud Puntos de Extensión N/A

65

13.2.11 CU_11 Modificar Estudio Medico Número: 011 Nombre de Caso de Uso: “Modificar Estudio Medico” Actor(es): Médico. Descripción: El Caso de Uso permite al usuario modificar la aprobación, aplazo y/o negación de la solicitud de medicamento Tabla 14. CU_11 Modificar Estudio Medico

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el Médico seleccionan la opción Modificar Estudio Medico que se encuentra en la interfaz principal.

2. El sistema pide el Número de Identificación o Nombre completo del paciente al cual se le va a Modificar la solicitud

3. El usuario ingresa el Número de Identificación o Nombre completo del paciente al cual se le va a Modificar la solicitud.


4.1. El usuario Cancela la operación


66

Continuación Tabla 14. CU_11 Modificar Estudio Medico

5. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos y que el número de identificación sea un número positivo y que el número de identificación se encuentre en la base de datos.

5.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al médico que lo vuelva a intentar. (Flujo normal 3).

5.2. Si el número de identificación es un número negativo, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar. (Flujo normal 3).



7. El sistema muestra los datos de la solicitud. (Los datos se obtienen del caso de uso CU_06)

8. El Médico modifica los campos de la solicitud. Sólo podrá modificar los siguientes campos:

• Entidad patológica o Diagnostico o Código CIE o Resumen de la Historia Clínica

• Descripción del Medicamento o Tipo de Medicamento (POS, No POS) o Nombre genérico o Concentración y forma farmacéutica o Dosis o Cantidad o Duración del tratamiento (en días) o Homologo en el POS (nombre

genérico) o Indicación Terapéutica o Tipo de solicitud (Primera vez,

renovación o Fallo de Tutela).

67

Continuación Tabla 14. CU_11 Modificar Estudio Medico

9. El Médico selecciona la opción Evaluar Solicitud. Se ejecuta caso de uso CU_10.



10. El sistema asocia la información de la solicitud con la evaluación medica

11. El Médico selecciona la opción Aceptar.



12. El sistema valida la integridad de los datos, verifica que los campos no estén vacíos

12.1. Si los campos de texto se encuentran vacíos, el sistema muestra un mensaje indicando el error y le dice al médico que lo vuelva a intentar. (Flujo normal 8).

13. El sistema guarda los cambios en la base de datos.



Pre-Condiciones La solicitud debe existir en la base de datos Post-Condiciones El usuario modifica una solicitud Puntos de Extensión CU_06, CU_10

68

13.2.12 CU_12 Ingresar Medico Tratante Número: 012 Nombre de Caso de Uso: “Ingresar Medico Tratante” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario un Médico Tratante que no se encuentre en el sistema. Tabla 15. CU_12 Ingresar Médico Tratante

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el

digitador selecciona la opción Ingresar Medico Tratante, que se encuentra en la interfaz Ingresar Solicitud.

2. El sistema muestra una interfaz

solicitando al usuario que ingrese los datos del Médico Tratante.

Datos - Nombre(es) y Apellido (s) del

Médico Tratante - Especialidad

3. El usuario ingresa la información del usuario: Nombre(es) y Apellido (s) del Médico Tratante y Especialidad

69

Continuación Tabla 15. CU_12 Ingresar Medico Tratante



5. El sistema verifica la integridad de los datos. Verifica que los campos propios a la interfaz no estén vacíos.

5.1. Si alguno de los campos se

encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).

6. Los datos son ingresados a la base

de datos.

7. El sistema muestra un mensaje de

confirmación al usuario que la operación ha sido exitosa.

8. Finaliza CU_12

Pre-Condiciones El Médico Tratante NO debe existir en la base de datos Post-Condiciones El usuario ingresa un medico tratante Puntos de Extensión N/A

70

13.2.13 CU_13 Ingresar IPS Número: 013 Nombre de Caso de Uso: “Ingresar IPS” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario Ingresar una IPS que no se encuentre en el sistema. Tabla 16. CU_13 Ingresar IPS

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el administrador selecciona la opción Ingresar IPS, que se encuentra en la interfaz Ingresar Solicitud.

2. El sistema muestra una interfaz solicitando al usuario que ingrese los datos de la IPS

Datos - Nombre de la unidad

Asistencial - Empresa Social del Estado - Ciudad o Municipio

3. El usuario ingresa la información de la IPS: Nombre de la unidad Asistencial, Empresa Social del Estado y Ciudad o Municipio

71

Continuación Tabla 16. CU_13 Ingresar IPS


4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8.


5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al administrador que lo vuelva a intentar (Flujo normal punto 3).



8. Finaliza CU_13

Pre-Condiciones La IPS NO debe existir en la base de datos Post-Condiciones El usuario ingresa una IPS Puntos de Extensión N/A

72

13.2.14 CU_14 Ingresar Paciente Número: 014 Nombre de Caso de Uso: “Ingresar Paciente” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario ingresar un Paciente que no se encuentre en el sistema. Tabla 17. CU_14 Ingresar Paciente

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el usuario selecciona la opción Ingresar Paciente, que se encuentra en la interfaz Ingresar Solicitud.

2. El sistema muestra una interfaz solicitando al usuario que ingrese los datos del Paciente.

Datos - Tipo de Identificación - Identificación - Nombre(es) - Apellido(s) - Edad - Tipo de Vinculación - Dirección - Teléfono - Nombre del Cotizante - Apellido del Cotizante - Tipo de identificación del Cotizante - Número de identificación del

Cotizante

73

Continuación Tabla 17. CU_ Ingresar Paciente

3. El usuario ingresa la información del usuario: Tipo de Identificación, Identificación, Nombre(es), Apellido(s), Edad, Tipo de Vinculación, Dirección, Teléfono, Nombre del Cotizante, Tipo de identificación del Cotizante y Numero de identificación del Cotizante


4.1. El usuario Cancela la operación. 4.2. Flujo normal punto 8.

5. El sistema verifica la integridad de los datos. Verifica que las campos propios a la interfaz no estén vacíos, que el usuario no esté en la base de datos y que el número de identificación del paciente y cotizante sean positivos y teléfono sean positivos.

5.1. Si alguno de los campos se encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).

5.2. Si el número de identificación del usuario ya está registrado en la base de datos, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).

5.3. Si el número de identificación es un número negativo, el sistema mostrará un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal punto 3).

6. Los datos son ingresados a la base de

datos.


8. Finaliza CU_14

Pre-Condiciones El Paciente NO debe figurar en la base de datos Post-Condiciones El usuario ingresa un paciente Puntos de Extensión N/A

74

13.2.15 CU_15 Ingresar Medicamento Número: 015 Nombre de Caso de Uso: “Ingresar Medicamento” Actor(es): Digitador. Descripción: El Caso de Uso permite al usuario ingresar un Medicamento e en el caso que el paciente que no se encuentre en el sistema. Tabla 18. CU_15 Ingresar Medicamentos

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el usuario

selecciona la opción Ingresar Medicamento, que se encuentra en la interfaz Ingresar Solicitud.

2. El sistema muestra una interfaz

solicitando al usuario que ingrese los datos del Medicamento.

Datos - Tipo de Medicamento (POS

Prescrito, POS, No POS) - Nombre del medicamento - Concentración y Forma

Farmacéutica

75

3. El usuario ingresa la información del

medicamento: Tipo de Medicamento (POS Prescrito, POS, No POS), Nombre del medicamento, Concentración y Forma Farmacéutica

Continuación Tabla 18. CU_15 Ingresar Medicamento




5.1. Si alguno de los campos se

encuentra vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar (Flujo normal punto 3).



8. Finaliza CU_15

Pre-Condiciones El Paciente NO debe existir en la base de datos Post-Condiciones El usuario ingresa un medicamento Puntos de Extensión N/A

76

13.2.16 CU_16 Realizar Informe Número: 016 Nombre de Caso de Uso: “Realizar Informe” Actor(es): Administrador, Digitador, Medico e Impresora Descripción: El Caso de Uso permite al usuario generar un informe para la oficina de recobros e informe para respuesta de solicitud de medicamento. Tabla 19. CU_16 Realizar Informe

FLUJO DE EVENTOS


1. El caso de uso inicia cuando el usuario selecciona la opción Generar Informe que se encuentra en la interfaz principal

2. El sistema pide el tipo de informe que desea realizar: • Informe para Recobros • Informe para Respuesta Solicitud

Medicamento

3. El sistema pide al usuario elegir el rango de fecha que desea realizar el informe: Día, Mes y Año

77

Continuación Tabla 19. CU_16 Realizar Informe

4. El usuario selecciona los datos solicitados


5.1. El usuario selecciona la opción Cancelar.


6. El sistema verifica la integridad de los datos. Verifica que los campos no estén vacíos.

6.1. Si el campo está vacío, el sistema muestra un mensaje indicando el error y le dice al usuario que lo vuelva a intentar. (Flujo normal 3).

7. El sistema busca en la base de datos

las solicitudes de medicamentos ingresadas al sistema.

8. El sistema muestra en pantalla el listado de las solicitudes

9. El usuario tiene la opción de imprimir el reporte

10. Finaliza CU_16

Pre-Condiciones Deben existir datos almacenados de solicitudes diarias Post-Condiciones N/A Puntos de Extensión N/A

78

14. MATRIZ CASOS DE USO – REQUISITOS A continuación la tabla No. 20 presenta la matriz de requisitos con sus respectivos casos de uso. Tabla 20. Matriz de Requisitos CU_01 CU_02 CU_03 CU_04 CU_05 CU_06 CU_07 CU_08 CU_09 CU_10 CU_11 CU_12 CU_13 CU_14 CU_15 CU_16

RF1 x x RF2 x RF3 x RF4 x RF5 x RF6 x RF7 x RF8 x RF9 x RF10 x RF11 x RF12 x RF13 x RF14 x RF15 x RF16 x RF17 x RF18 x RF19 x RF20 x

79

RF21 x RF22 x RF23 x RF24 x RF25 x RF26 x RF27 x RF28 x RF29 x

80

15. INTERFACES En la figura No. 2 se muestra el esquema de la interfaz del sistema: Figura 2. Interfaz del Sistema

Login: Administrador/Medico/ Digitador/Consultor Password: *****

Ventana Principal

Generar

Informes

Deshabilitar/Habilitar

Modificar

Consultar

Crear

Usuario

Estudio Medico

Modificar Solicitud

Consultar Solicitud

Ingresar IPS Ingresar Medicamento

Ingresar Medico Tratante

Ingresar Paciente

Ingresar Solicitud

Solicitudes

81

16. MODELO DE ARQUITECTURA DE CASO DE USO

16.1 CASOS DE USO SIGNIFICATIVOS En la figura 3 se representan los cosos de uso más significativos que maneja el sistema para el Comité Técnico Científico: Figura 3. Modelo de la Arquitectura

16.2 DESCRIPCIÓN TEXTUAL Después de realizar una reunión del grupo de trabajo en la cual se plantearon las primeras aproximaciones acerca de cuáles serian las funcionalidades primordiales con las cuales el sistema debía ser soportado, se tomo la decisión de centrar la arquitectura del sistema en cuatro casos de uso de interés colectivo para llevar a buen término la ejecución del proyecto.

82

A continuación se proporcionará una breve explicación del porque de esta determinación. CU_06 Ingresar Solicitud Mediante esta operación el caso de uso permitirá al usuario ingresar solicitudes la cual es de vital importancia debido a que si no se cuenta con un modulo para ingresar solicitudes no se tendría control alguno sobre los mismos para operaciones tan importantes para el Comité Técnico Científico como son el de Estudio Medico y Evaluar Solicitud. Este caso de uso ingresará la información perteneciente a la solicitud de medicamento. CU_08 Consultar Solicitud Este caso de uso permitirá al usuario hacer consultas de solicitudes medicamentos ya sean aprobadas, negadas y/o aplazadas por el Comité Técnico Científico, mediante esta operación el caso de uso es de mayor importancia debido a que este modulo permite el control para operaciones importantes para el Comité Técnico Científico como son el de Realizar Informe Recobro y Realizar Informe Respuesta Solicitud Medicamento. CU_09 Estudio Medico Mediante este caso de uso permitirá al usuario realizar el Estudio Medico Correspondiente a la solicitud de medicamento, esta operación es de vital importancia debido a que si no se cuenta con un modulo para realizar el Estudio Medico no se podría tener un mayor control sobre las solicitudes ingresadas al sistema y no se tendría control sobre operaciones importantes para el Comité Técnico Científico como son el de Evaluar Solicitud y Modificar Estudio Medico. CU_10 Evaluar Solicitud Tanto para el Comité Técnico Científico como para el sistema es muy importante contar con el modulo de Evaluar Solicitud debido a que mediante este modulo se realiza la aprobación, negación y/o aplazo de las solicitudes medicas ingresadas al sistema, este caso de uso permite el control de operaciones para el Comité Técnico Científico tales como el realizar informes.

83

17. MODELO DE ANÁLISIS DEL SISTEMA 17.1 REALIZACIÓN DE CASOS DE USO Una Realización de caso de uso – análisis es una colaboración dentro del Modelo de Análisis que describe cómo se lleva a cabo y se ejecuta un caso de uso determinado en términos de las clases de análisis. Por lo tanto hay una realización de caso de uso – análisis para cada caso de uso expresado en el Software Requirement Specification (SRS). Para cada caso de uso se desarrolla la realización de Caso de Uso-Análisis con el formato que se presenta a continuación: 17.1.1 CU_01 Ingresar al Sistema � Número: 001 � Nombre de Caso de Uso-Análisis: “Ingresar al Sistema” � Diagrama de Clase Figura 4. Diagrama de Clase CU_01

84

� Diagrama de Secuencia Figura 5. Diagrama de Secuencia CU_01

Descripción: El usuario inicia el caso de uso cuando da clic del evento Ingresar al Sistema, el cual solicitara los datos correspondientes al ingreso de la aplicación: login y Password, para el ingreso al sistema se hace una validación de los datos ingresados, si los datos son ingresados erróneamente el sistema enviará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, la interfaz se comunica con el control Usuario enviándole los datos para que realice la respectiva consulta, el control Usuario se comunica con el Ente Usuario haciendo el llamado a consultar para que se haga la respectiva consulta del Login y el Password, el ente Usuario valida la existencia del usuario enviando luego al control Usuario los datos correspondientes y se activa la interfaz Principal.

85

17.1.2 CU_02 Crear Usuario

� Número: 002 � Nombre de Caso de Uso-Análisis: “Crear Usuario” � Diagrama de Clase Figura 6. Diagrama de Clase CU_02

� Diagrama de Secuencia (Ver Figura 7 Diagrama de Secuencia CU_02 página siguiente).

86

Figura 7. Diagrama de Secuencia CU_02

Descripción: Este caso de uso permite al administrador y al encargado del sistema ingresar un nuevo usuario. El administrador inicia el caso de uso cuando selecciona la opción Crear Usuario que se encuentra en la interfaz Principal, al seleccionar se mostrará en pantalla un formulario en el cual se ingresaron los datos del nuevo usuario: cedula, nombre(s), apellido(s), dirección, teléfono, login, password y e-mail, para la creación del usuario se hace una validación de los datos ingresados, si los datos son ingresados erróneamente el sistema enviará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, la interfaz se comunica con el control Usuario enviándole los datos para que realice la respectiva consulta, este control activa el ente Usuario haciendo el llamado a consultar para que se haga la respectiva consulta de los datos ingresados, el ente valida la existencia del usuario, si el usuario ya existe en el sistema el sistema mostrará un mensaje indicando que el usuario ya existe, si no el control envía los datos correspondientes al ente y los datos son guardados, luego el sistema muestra un mansaje en pantalla de confirmación que el usuario ha sido creado.

87

17.1.3 CU_03 Modificar Usuario

� Número: 003 � Nombre de Caso de Uso-Análisis: “Modificar Usuario” � Diagrama de Clase Figura 8. Diagrama de Clase CU_03

88


:a Actor :UI Ingresar _ID :C Usuario

Selecciona opcion

ingresa id_usuario(id)

Aceptar()

x=valida_vacios()

x=false error

y=valida_negativos()

y=false error

y=true Activa

Activa

consultar(datos)

z=consultar()

Activa

Muestra Interfaz

:E Usuario :Ui Modificar

z=false

z=true datos()

muestra interfaz datos()

datos:

Cedula

Nombre

Apellido

Direccion

Telefono

Login

Password

email

modificar datos(direccion,telefono,email)

aceptar()

x=valida_vacios()

:UI Principal

z=false

z=false y=valida_negativos()

y=true

insertar()

msg "Usuario Modificado"

activa()

pasa datos()

msg "usuario no existe"

Descripción: El caso de uso inicia cuando el administrador selecciona la opción Modificar Usuario que se encuentra en la interfaz Principal, después de seleccionar la opción se muestra la interfaz Ingresar Id el cual el administrador digita el id del usuario a modificar, para realizar la modificación del usuario se hace una validación del dato ingresado, si el dato está mal ingresado el sistema muestra nuevamente la interfaz ingresar id hasta que el administrador ingrese correctamente el dato, si el id es digitado educadamente la interfaz se comunica con el control Usuario enviándole el dato correspondiente para que realice la consulta, el control se comunica con el ente Usuario haciendo el llamado a consultar para realizar la respectiva consulta del id ingresado, el ente consulta el id del usuario, si el id del usuario no se encuentra en la base de datos el sistema mostrará un mensaje indicando el error, si el usuario se encuentra registrado el control envía los datos correspondientes y muestra la interfaz Modificar Usuario

89

con los datos del usuario registrado, el administrador sólo podrá modificar los siguientes datos: dirección, teléfono y e-mail, el sistema realiza las respectivas validaciones de los datos modificados, si estos se encuentran erróneamente el sistema mostrará un mensaje de error haciendo la notificación de que ha ocurrido un error ingresando los datos, si los datos son digitados correctamente el control envía los datos al ente y estos son guardados, luego el sistema muestra un mensaje de confirmación notificando que el usuario ha sido modificado. 17.1.4 CU_04 Consultar Usuario � Número: 004 � Nombre de Caso de Uso-Análisis: “Consultar Usuario” � Diagrama de Clase Figura 10. Diagrama de Clase CU_04

90


Descripción Este caso de uso permite al administrador mirar la información (datos personales) de un usuario registrado en la base de datos. El caso de uso inicia cuando el administrador selecciona la opción Consultar Usuario que se encuentra en la interfaz principal, esta interfaz pide al usuario ingresar el id del usuario que desea consultar, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Usuario enviándole el dato correspondiente para que realice la consulta, el control se comunica con el ente Usuario haciendo el llamado a consultar para realizar la respectiva consulta del id ingresado, el ente consulta el id del usuario, si el usuario se encuentra registrado el control envía los datos correspondientes y muestra la interfaz con los datos, si el usuario no se encuentra en el sistema mostrará un mensaje indicando que el usuario no existe, si el usuario se encuentra en la base de datos el ente pasa los datos al control para luego ser mostrados en la interfaz consultar, luego se muestran los datos al actor. Termina caso de uso.

91

17.1.5 CU_05 Deshabilitar/Habilitar Usuario � Número: 005 � Nombre de Caso de Uso-Análisis: “Deshabilitar/Habilitar Usuario” � Diagrama de Clase Figura 12. Diagrama de Clase CU_05


92

Descripción: El administrador inicia el caso de uso cuando selecciona la opción Deshabilitar/Habilitar Usuario, para deshabilitar y habilitar usuarios se muestra en pantalla si se desea realizar deshabilitar y habilitar, la interfaz se comunica con el control Usuario el cual envía al ente Usuario la sentencia a buscar los usuarios que se encuentran deshabilitados y habilitados del sistema, el ente pasa los datos correspondientes al control y luego son mostrados en pantalla, el administrador cambia el estado del usuario de Habilitado - Deshabilitado y Deshabilitado – Habilitado, luego los cambios son guardados en el ente Usuario. Termina la ejecución. 17.1.6 CU_06 Ingresar Solicitud � Número: 006 � Nombre de Caso de Uso-Análisis: “Ingresar Solicitud” � Diagrama de Clase Figura 14. Diagrama de Clase CU_06.

93


:A Actor :UI Principal :UI Acta :UI Solicitud :C Solicitud :E Solicitud

Selecciona

Activa

Aceptar()

Activa

Muestra Interfaz

Ingresa Datos (idpacie,nombrepaci,fecha,ciudad)

Aceptar()

x=valida_vacios()


x=false error

y=false error

y=true

Activa

consultar()

z=consultar()

z=false error

z=truePasa datos (paciente)

muestra interfaz

Ingresa Datos()

datos:

Medico tratante

Ips

Medicamento

Entidad_Patologica

Aceptar()

x=valida_vacios()

x=false error

x=true

buscar()

p=buscar

z=false error

z=true

mgs "ingrese datos"

pasa datos()

insertar()

msg Solicitud creada

msg "paciente no existe"

94

Descripción: El caso de uso se ejecuta cuando el digitador selecciona la opción ingresar solicitud que se encuentra en la interfaz principal, al realizar el ingreso de la solicitud, el sistema pide al usuario si desea generar acta, esta acta el sistema la genera con un consecutivo, si el usuario no desea generar acta se seguirá con el consecutivo que tenía anteriormente, el usuario ingresa los datos correspondientes al formato de la solicitud, estos datos son el id del paciente, nombre del paciente, la fecha y la ciudad, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Solicitud enviándole el dato del id y el nombre del paciente correspondiente para que realice la consulta, el control se comunica con el ente Solicitud haciendo el llamado a consultar para realizar la respectiva consulta del id y nombre ingresado, el ente consulta el id y nombre del paciente, si el paciente no se encuentra en el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra registrado el control envía los datos correspondientes y muestra la interfaz con los datos, el usuario ingresa los demás datos del formato de solicitud, estos datos son: medico tratante, IPS, medicamento y entidad patológica, el sistema realiza la verificación de los datos, la interfaz se comunica con el control solicitud y luego con el ente solicitud haciendo el llamado de buscar, si los datos no se encuentran en la base de datos, el sistema indicara el error de ingresar los datos del médico tratante, la IPS y el medicamento, la interfaz se comunica con el control solicitud pasando los datos que se han ingresado en el formato del ingreso de solicitud de medicamento, el control se comunica con el ente solicitud para realizar la respectiva inserción de los datos en la base de datos, los datos son asociados y luego se muestra en pantalla indicando que la solicitud fue ingresada

95

17.1.7 CU_07 Modificar Solicitud � Número: 007 � Nombre de Caso de Uso-Análisis: “Modificar Solicitud”

� Diagrama de Clase Figura 16. Diagrama de Clase CU_07

+aceptar()

+cancelar()

+valida_fecha()

+valida_vacios()

+valida_negativos()

-fecha

-cuidad

-id_paciente

-tipo_id

-nombre_paciente

-edad_paciente

-direccion

-tipo_vinculacion

-nombre_mt

-especialidad

-tipo_unidad

-nombre_unidad

-nombre_medica

-tipo_medicamento

-aceptar

-cancelar

:UI Solicitud

+consultar()

+insertar()

:C Solitud

+Eventos()

+Salir()

-Menu

-Salir

:UI Principal

+getfecha()

+getCiudad()

+getId_paciente()

+gettipo_id()

+getNombre_paciente()

+getedad()

+getdireccion()

+gettipo_vinculacion()

+getnombre:mt()

+getespecialidad()

+gettipo_unidad()

+getnombre_unidad()

+getnombre_medica()

+gettipo_medicamento()

+consultar()

+insertar()

-fecha

-cuidad

-id_paciente

-tipo_id

-nombre_paciente

-edad_paciente

-direccion

-tipo_vinculacion

-nombre_mt

-especialidad

-tipo_unidad

-nombre_unidad

-nombre_medica

-tipo_medicamento

-aceptar

-cancelar

:E Solicitud

+valida_vacios()

+valida_negativos()

+aceptar()

+cancelar()

-id_pac

-nombre_pac

-aceptar

-cancelar

:UI Ingresar_ID+getid_paciente()

+getnombre_paciente()

+consultar()

-id_paciente

-nombre_paciente

:E Paciente

96


:A Actor :UI Principal :UI Ingresar_ID :C Solicitud :E Paciente :E Solicitud

selecciona

activa()

Muestra interfaz

ingresa (idpac,nombrepac)

Aceptar()

x=valida_vacios()x=false error

y=false error y=valida_negativos()

y=true activa()

consultar (idpac,nombrepac)

z=consultar()

z=false error

z=false error

y=true activa()

z=consultar()

z=true


activa()

:UI Solicitud

pasa datos(solicitud)

Muestra interfaz

modifica datos()

Aceptar

x=valida_vacios()x=false error

y=false error y=valida_negativos()

y=true

insertar()

msg "solicitud modificada"

msg "el paciente no tiene solicitud asociada"

Descripción: El caso de uso se ejecuta cuando el usuario selecciona la opción Modificar Solicitud que se encuentra en la interfaz principal, el sistema pide al usuario ingresar el id o nombre del paciente al cual se le desea modificar la solicitud, el sistema realiza la verificación de los datos validando campos vacios y negativos, si los datos son ingresados incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si los datos son ingresados correctamente la interfaz se comunica con el control Solicitud el cual se comunica con el Ente Paciente haciendo el llamado consultar

97

para realizar la consulta del id o nombre ingresado, el ente paciente realiza la búsqueda de los datos ingresados, si el paciente no se encuentra en la base de datos, el sistema mostrará un mensaje indicando el error ,si el dato del paciente se encuentra en la base de datos, el ente paciente se comunica con el ente Solicitud haciendo el llamado consultar al ente solicitud, el ente realiza la respectiva consulta, si los datos se encuentran relacionados a una solicitud de medicamento, si el paciente no tiene ingresada una solicitud el sistema mostrara un mensaje indicando el erro, si el paciente tiene asociada la solicitud el control Solicitud activa la interfaz Solicitud relacionando los datos a la respectiva interfaz, el usuario modifica los datos correspondientes, el sistema realiza la verificación de los datos, si los datos son inválidos, el sistema mostrara un mensaje indicando el error, si los datos son validos, la interfaz se comunica con el control solicitud, éste se comunica con el ente solicitud con el llamado insertar, insertando los datos modificados. Luego se muestra en pantalla indicando que la solicitud fue modificada. Termina ejecución. 17.1.8. CU_08 Consultar Solicitud � Número: 008 � Nombre de Caso de Uso-Análisis: “Consultar Solicitud” � Diagrama de Clase Figura 18. Diagrama de Clase CU_08

98


Descripción: El usuario inicia el caso de uso cuando selecciona la opción consultar Solicitud que se encuentra en la interfaz principal, el sistema pide al usuario ingresar el id o nombre del paciente, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que el administrador digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Solicitud, el control solicitud se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el usuario no existe, si el paciente se encuentra, el ente paciente se comunica con el ente solicitud haciendo el llamado buscar, si no se encuentra ninguna solicitud relacionada al paciente, se mostrara un mensaje indicando el error, si hay una solicitud relacionada al paciente el ente solicitud pasa los datos al control para luego ser asociados y mostrados en pantalla. El usuario tiene la opción de imprimir. Termina ejecución.

99

17.1.9 CU_09 Estudio Medico � Número: 009 � Nombre de Caso de Uso-Análisis: “Estudio Medico” � Diagrama de Clase Figura 20. Diagrama de Clase CU_09

100

� Diagrama de Secuencia Figura 21. Diagrama de Secuencia

:a Actor :UI Principal :Ui Ingresar-ID :C Paciente :E Paciente :E Solicitud :C Estudio :UI Estudio

Selecciona

activa

Muestra Interfaz

ingresa datos(idpac,nombre,pac)

x=valida_vacios()


x=false error

y=false error

y=true

Activa()

buscar(idpac,nombrpac)

z=buscar()

z=false error

z=true


pasa datos()

z=Buscar()

z=false error

z=true

activa()

muestra interfaz

Evaluar solicitud

aceptar()

msg "estudio realizado"

pasa datos()

insertar()

aceptar()

Descripción: El usuario inicia el caso de uso cuando el usuario selecciona la opción Estudio Solicitud que se encuentra en la interfaz principal, la interfaz se comunica con la interfaz ingresar_id el cual el sistema pide al usuario ingresar el id o nombre del paciente, el sistema realiza la verificación de los datos, si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Paciente para luego el control se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra en el sistema, el ente Paciente se comunica con el ente Solicitud haciendo el llamado a buscar, el ente busca la solicitud referente a los

101

datos ingresados, luego el ente Solicitud pasa los datos relacionados al control Estudio, el control estudio activa la interfaz Estudio la cual asocia los datos de la solicitud, el médico realiza el estudio médico correspondiente seleccionando la opción Evaluar Solicitud (se ejecuta el caso de uso CU-10), los datos se pasan al control para luego ser insertados en el ente solicitud. Se muestra un mensaje en pantalla indicando que el estudio fue realizado. Termina ejecución. 17.1.10 CU_010 Evaluar Solicitud � Número: 0010 � Nombre de Caso de Uso-Análisis: “Evaluar Solicitud” � Diagrama de Clase Figura 22. Diagrama de Clase CU_10

102


Descripción: El caso de uso se ejecuta cuando el médico selecciona la opción Evaluar Solicitud que se encuentra en la interfaz de estudio Médico, el usuario ingresa los datos relacionados a la interfaz, el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Evaluar Solicitud, el control se comunica con el ente Evaluar Solicitud mediante el llamado insertar, el cual inserta los datos ingresados, luego el control muestra los datos asociados en la interfaz Estudio Medico, termina caso de uso.

103

17.1.11 CU_011 Modificar Estudio Medico

� Número: 0011 � Nombre de Caso de Uso-Análisis: “Modificar Estudio Medico” � Diagrama de Clase Figura 24. Diagrama de Clase CU_11

104


Descripción: La ejecución del caso de uso inicial seleccionar la opción Modificar Estudio Medico, el sistema pide al usuario que ingrese el id o nombre del paciente al cual desea modificar, al ser ingresados los datos el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si el dato es ingresado correctamente la interfaz se comunica con el control Paciente para luego el control se comunica con el ente paciente con el llamado consultar enviándole el dato correspondiente para que realice la consulta, el ente realiza la consulta, si el paciente no se encuentra el sistema el sistema mostrará un mensaje indicando que el paciente no existe, si el paciente se encuentra en el sistema, el ente Paciente se comunica con el ente Solicitud haciendo el llamado a buscar, el ente busca la solicitud referente a los datos ingresados, luego el ente Solicitud pasa los datos relacionados al control Estudio, el control estudio activa la interfaz

105

Estudio la cual asocia los datos de la solicitud, el médico realiza la modificación de los datos, si el médico desea modificar la evaluación de la solicitud selecciona la opción Evaluar Solicitud (se ejecuta caso de uso 10), el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos correspondientes, si los datos son ingresados correctamente la interfaz se comunica con el control Estudio para luego comunicarse con el ente Solicitud mediante el llamada Insertar, la cual inserta los datos modificados, luego el control muestra un mensaje indicando que la solicitud ha sido modificada. Termina ejecución del caso de uso. 17.1.12 CU_012 Ingresar Medico Tratante � Número: 0012 � Nombre de Caso de Uso-Análisis: “Ingresar Medico Tratante” � Diagrama de Clase Figura 26. Diagrama de Clase

106


Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Medico Tratante, al seleccionar la opción se mostrara en pantalla la interfaz de Medico Tratante la cual se ingresaran los datos correspondientes al médico, el sistema realiza la verificación de los datos si el dato es ingresado incorrectamente el sistema mostrara la interfaz hasta que se digite bien los datos convenientes, si los datos son validos la interfaz se comunica con el control Medico_Tratante el cual se comunica con el ente Medico_Tratante mediante el llamado consultar, si el médico se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el médico ya existe, si el médico tratante no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Medico_Tratante mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el médico ha sido ingresado.

107

17.1.13 CU_013 Ingresar IPS � Número: 0013 � Nombre de Caso de Uso-Análisis: “Ingresar IPS” � Diagrama se Clase Figura 28. Diagrama de Clase CU_13


108

Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar IPS, al seleccionar la opción se mostrara en pantalla la interfaz de IPS, la cual se ingresaran los datos correspondientes a la IPS, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos convenientes, si los datos son validos la interfaz se comunica con el control IPS el cual se comunica con el ente IPS mediante el llamado consultar, si la IPS se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que la IPS ya existe, si la IPS no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente IPS mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que la IPS ha sido ingresada. 17.1.14 CU_014 Ingresar Paciente � Número: 0014 � Nombre de Caso de Uso-Análisis: “Ingresar Paciente” � Diagrama de Clase Figura 30. Diagrama de Clase CU_14

109


Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Paciente, al seleccionar la opción se mostrara en pantalla la interfaz de Ingresar Paciente, la cual se ingresaran los datos correspondientes al paciente, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos correctos, si los datos son validos la interfaz se comunica con el control Paciente el cual se comunica con el ente Paciente mediante el llamado consultar, si el Paciente se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el paciente ya existe, si el paciente no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Paciente mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el paciente ha sido ingresado.

110

17.1.15 CU_015 Ingresar Medicamento � Número: 0015 � Nombre de Caso de Uso-Análisis: “Ingresar Medicamento” � Diagrama de Clase Figura 32. Diagrama de Clase CU_15


111

Descripción: El caso de uso se ejecuta al seleccionar la opción Ingresar Medicamento que se encuentra en la interfaz Solicitud, al seleccionar la opción se mostrara en pantalla la interfaz de Ingresar Medicamento, la cual se ingresaran los datos correspondientes al medicamento, el sistema realiza la verificación de los datos, si los datos son ingresados incorrectamente el sistema mostrara un mensaje indicando el error hasta que se digite bien los datos correctos, si los datos son validos la interfaz se comunica con el control Medicamento el cual se comunica con el ente Medicamento mediante el llamado consultar, si el medicamento se encuentra en la base de datos el sistema mostrara en pantalla un mensaje indicando que el medicamento ya existe, si el medicamento no se encuentra en la base de datos, la interfaz se comunica con el control pasándole los datos ingresados anteriormente, el control se comunica con el ente Medicamento mediante el llamado insertar la cual se insertaran los datos ingresados, el sistema muestra un mensaje indicando que el medicamento ha sido ingresado. Termina ejecución del caso de uso. 17.1.16 CU_016 Realizar Informe � Número: 0016 � Nombre de Caso de Uso-Análisis: “Realizar Informe” � Diagrama de Clase Figura 34. Diagrama de Clase CU_16

112


Descripción: El usuario inicia el caso de uso cuando da clic del evento Generar Informe que se encuentra en la interfaz principal, el sistema muestra la interfaz indicándole al usuario el tipo de informe que desea realizar, la interfaz se comunica con la interfaz Rango_Fecha la cual pide al usuario elegir la fecha del cual desea realizar el reporte, el sistema realiza la verificación de los datos, si el rango de la fecha no es válido el sistema vuelve a pedir al usuario que seleccione el tipo de informe, si el rango de la fecha es válido la interfaz se comunica en el control Solicitud, este se comunica con el ente solicitud mediante el llamado consultar para hacer las consultas respectivas, el ente solicitud retorna las solicitudes al control para luego ser mostradas en la interfaz reporte, el usuario tiene la opción de imprimir el reporte. Termina ejecución.

113

18. PAQUETES DE ANÁLISIS En la figura 36 se muestra el paquete UI Package el cual contiene todas las clases de interfaz del sistema:

Figura No. 36 UI_Package

En la figura No. 37 se muestra el paquete Control Package el cual contiene todas las clases de control del sistema:

114

Figura No. 37 Control_Package

En la figura No. 38 se muestra el paquete Entity Package el cual contiene todas las entidades del sistema: Figura No. 38 Entity_Package

En la figura No. 38 se muestra el paquete de análisis relacionado el cual contiene la unión de todos los paquetes del sistema:

115

Figura No. 39 Paquete de Análisis Relacionado

116

19. DESCRIPCIÓN DE PAQUETES DE ANÁLISIS A partir de la arquitectura de los casos de uso, siguiendo el modelo de casos de uso y requisitos suplementarios obtenemos los siguientes paquetes: 19.1 PAQUETE: “UI PACKAGE” Descripción: Contiene las clases de interfaz de ingresos, modificaciones, evaluaciones y reportes de la solicitud de medicamentos del Comité Técnico Científico CTC. Todas son interfaces de usuario adoptadas de los casos de uso identificados en el levantamiento de requerimientos. Objetivo: Las clases de interfaz de usuario son independientes y se agrupan todas en el paquete UI Package para seguir el patrón MVC (Model View Controller). 19.2 PAQUETE: “CONTROL PACKAGE” Descripción: Contiene las clases de control Usuario, control Solicitud, control Paciente, control Estudio, control Avaluar, control Medico_Tratante, control IPS, control Medicamento, encargadas de administrar los procesos del sistema. Objetivo: Agrupar todas las clases que hacen posible controlar y ejecutar los procesos que un usuario puede realizar en el sistema. Contiene la clase control Usuario la cual maneja los perfiles de todos los usuarios que puedan ingresar al sistema; Solicitud, que gestiona los datos de la solicitud respectiva de cada medicamento por paciente; Paciente, encargada de acceder a los datos principales del paciente; Estudio, llevará a cabo el proceso de realizar el estudio médico correspondiente a las solicitudes ingresadas; Evaluar, administrará la aceptación, negación o prorroga de las solicitudes de medicamento; Medico_Tratante, gestiona los datos de los médicos; IPS, gestiona los datos de las Ips ingresadas al sistema, Medicamento, gestiona los datos de los medicamentos de la solicitud.

117

19.3 PAQUETE: “ENTITY PACKAGE” Descripción: Contiene las clases necesarias para el almacenamiento y lectura de la información obtenida de la captura de los datos ingresados y comunicación al sistema hardware. Objetivo: Agrupar las entidades del sistema, en este caso las entidades: Usuario, Solicitud, Paciente, Evaluar, Medico_Tratante, IPS, Medicamento.

118

20. DESCRIPCIÓN DE ARQUITECTURA Para el desarrollo del producto software Comité Técnico Científico (CTC) se han tomado ciertas decisiones acerca de las herramientas de desarrollo que se van a utilizar en la implementación de dicho producto. Debido a la especificación del cliente y a cómo interactúan los actores con el sistema la arquitectura que mejor se acomoda a la aplicación es Cliente/Servidor de tres capas con clientes delgados, que consiste en una capa de Presentación, otra capa de la lógica de la aplicación y otra capa de la base de datos, donde: Presentación: son los formularios e inclusive código fuente que valida la entrada de datos en los formularios. Lógica: esta la parte más compleja e incluye todo lo que el programa debe hacer, aquí se arman las consultas SQL para acceder a datos que es enviada a la siguiente capa (Acceso a datos). Acceso a datos: esta parte es la encargada de acceder a los datos de la base de datos, realizando cualquier operación contra esta misma como ser Insertar, Modificar y Eliminar. La forma más correcta es agrupar cada capa en un directorio aparte. Es decir existirán 3 directorios principales, Presentación, Lógica, Acceso a datos. Se decidió una arquitectura de tres capas, donde la interfaz se encuentra situada en la primera capa, aparte de la lógica del negocio que se encuentra en la segunda capa y de los datos situados en la tercera capa, brindando la posibilidad de modificar cualquiera de las tres capas de manera independiente. Figura 36. Arquitectura Cliente/Servidor

119

Esta arquitectura se estableció debido a que durante la realización del presente proyecto se requiere de mucho procesamiento de datos en la aplicación, en las aplicaciones las funcionalidades están en constante cambio, aislar la tecnología de la base de datos para que sea fácil de cambiar, facilitar separar el código del cliente para que se facilite el mantenimiento y adecuada para utilizar programación orientada a objetos. Para el almacenamiento de datos se eligió el gestor de base de datos Sybase ya que es el que actualmente utiliza la Empresa Seguro Social y además poseen las licencias respectivas del uso de la misma. El gestor de bases de datos Sybase se opto como una solución para el análisis de la información y generación de informes en tiempo real, a partir de grandes volúmenes de datos, con menor costo de almacenamientos y administración. Su arquitectura permite procesar grandes volúmenes de datos con eficiencia, para facilitar a los usuarios la obtención de datos concretos en el momento preciso. Con respecto al lenguaje de programación se propuso realizar el proyecto en Visual Basic, en requerimientos con el Comité Técnico Científico CTC se planteó realizar el proyecto en Visual Studio .NET el cual permite a los programadores generar con rapidez aplicaciones para Internet de próxima generación orientadas a cualquier dispositivo y que se integran en cualquier plataforma. De esta forma el departamento podría continuar dando soporte al sistema después de que este sea construido y puesto en funcionamiento. A continuación se mostrara una imagen que ilustra el modelo de capas que componen los elementos que serán utilizados para llevar a cabo el desarrollo del sistema. Figura 37. Modelo de Capas

120

A continuación se presenta como se definió cada una de las partes de la arquitectura del sistema y especificando las razones para la elección de un método u otro: Componentes de interfaz de usuario (IU): la mayor parte de las soluciones necesitan ofrecer al usuario un modo de interactuar con la aplicación. Para el comité Técnico Científico CTC, un sitio Web permite al usuario realizar las operaciones correspondientes basadas en el entorno operativo Microsoft Windows, la cual permite hacer todo tipo de ingresos, modificación e inserción de datos. Las interfaces de usuario se implementan utilizando páginas Microsoft ASP.NET, controles u otro tipo de tecnología que permita procesar y dar formato a los datos de los usuarios, así como son los ingresos y validaciones de los datos entrantes procedentes de éstos. Interfaces de servicios : para exponer lógica empresarial como un servicio, es necesario crear interfaces de servicios que admitan las transacciones de comunicación; comunicación basada en mensajes, formatos, protocolos, seguridad y excepciones, entre otros que requieren los usuarios. En la interfaz de servicio se definen y coordinan los procesos de varios pasos de la ejecución del programa, los cuales se deben organizar y llevar a cabo en un orden determinado, se opera el manejo de sesiones, el manejo de errores y la ADOdb que maneja la lógica del sistema. Componentes lógicos de acceso a datos: la mayoría de las aplicaciones y servicios necesitan obtener acceso a un almacén de datos en un momento determinado del proceso. En los componentes lógicos de acceso se manejan las funcionalidades de acceso a datos es decir los SQL respectivos para obtener acceso a los datos en una capa independiente. Orígenes de datos: se encuentran todas las tablas donde se almacena la información donde están definidos procedimientos que se encargan de acceder a los datos cuando se necesita realizar algún tipo de operación intermedia de la lógica del negocio.

121

21. DISEÑO Y MODELO DE DATOS Descripción de entes del sistema. 21.1 MODELO ENTIDAD RELACIÓN MER

A continuación la figura No. 38 muestra el modelo entidad relación para el sistema: Figura 38. Modelo Entidad Relación.

122

21.2 MODELO RELACIONAL DE DATOS El modelo relacional de datos presenta en detalle cada una de las tablas del modelo entidad relación con sus tipos de datos, las restricciones, llaves primarias y foráneas dentro de las tablas. Tabla 21. MRD Paciente.

Campo Id Tipo_id Nombre Apellido Fecha

Nacimiento Dirección Teléfono

Tipo_Vinculación

Tipo y longitud bigin

t nchar(10) nvarchar(50) nvarchar(50) datetime nvarchar(MAX) numeric(18,0)

nvarchar(MAX)

Tipo clave PK Obligatoriedad NN NN NN NN NN NN Dominio y Restricción >0 >0

Tabla 22. MRD Médico Tratante. Campo Id Nombre Apellido Especialidad Tipo y Longitud int nvarchar(50) nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0

123

Tabla 23. MRD Tabla Ciudad. campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0

Tabla 24. MRD Departamento. Campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0

Tabla 25. MRD Medicamento. Campo Código Nombre Tipo_Medicamento Detalle_Medicamento Tipo y longitud int nchar(50) nchar(10) nvarchar(MAX) Tipo clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0

124

Tabla 26. MRD Evaluación Solicitud.

Campo Código Tipo

_Evaluación Duración Cantidad_

Tratamiento Dosis_

Tratamiento Tipo y longitud int nvarchar(50) nchar(10) nchar(10) nchar(10) Tipo clave PK Obligatoriedad NN NN NN NN NN Dominio y restricción >0 >0 >0 >0

Tabla 27. MRD Solicitud. Campo Código Fecha Tipo_Unidad Historia_Clínica Tipo y longitud int datetime nvarchar(50) nvarchar(MAX) Tipo clave PK Obligatoriedad NN,U1 NN NN NN Dominio y Restricción >0

Tabla 28. MRD IPS. Campo Código Nombre Dirección Teléfono Tipo y Longitud int nvarchar(50) nvarchar(MAX) numeric (18,0) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0 >0

125

Tabla 29. MRD Entidad Patológica. Campo Código_CIE Diagnostico Tipo y Longitud nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción

Tabla 30. MRD Actas. Campo Código Fecha_Inicial Fecha_Final Tipo y Longitud int datetime datetime Tipo Clave PK Obligatoriedad NN NN NN Dominio y Restricción >0

Tabla 31. MRD Presentación Medicamento. Campo Código Nombre Tipo_Dosis Detalle_Unidades Tipo y Longitud int nvarchar(MAX) nchar(10) nvarchar(50) Tipo Clave PK Obligatoriedad NN NN NN NN Dominio y Restricción >0 >0

Tabla 32. MRD Unidades de Concentración. Campo Código Nombre Tipo y Longitud int nvarchar(50) Tipo Clave PK Obligatoriedad NN NN Dominio y Restricción >0

126

Tabla 33. MRD Perfil de Usuario. Campo Código Cargo Descripción Tipo y Longitud int nvarchar(50) nvarchar(MAX) Tipo Clave PK Obligatoriedad NN NN NN Dominio y Restricción >0

Tabla 34. MRD Usuario

Tabla 35. MRD Bitácora. Campo Fecha Hora Tipo y Longitud datetime datetime Tipo Clave Obligatoriedad NN NN Dominio y Restricción >0

Campo Id Nombre Apellido Login Password Dirección Teléfono email

Tipo y longitud bigint nvarchar(50) nvarchar(50) nchar(10) nchar(10) nvarchar(MAX) nchar(10) nvarchar(MAX)

Tipo clave PK Obligatoriedad NN NN NN NN NN NN NN NN

Dominio y Restricción >0 >0

127

22. CONCLUSIONES

El desarrollo del proyecto Comité Técnico Científico CTC, es un avance importante para la EPS Seguro Social, sede Bellavista en Cali, ya que e s un sistema de información integrado para esta misma. Inicialmente con el proceso de desarrollo se abarcaron los procedimientos correspondientes a la ingeniería de software ya que la realización de este trabajo brindo la posibilidad de diseñar un sistema con funcionalidades que permiten la interacción del usuario con el proceso en particular permitiendo así una automatización para la oficina del Comité Técnico Científico CTC al momento de realizar los requisitos correspondientes por la aplicación. Además brinda un valor positivo de desarrollo ya que existen muy pocos antecedentes en este tipo de información. La realización de esta aplicación es una solución importante para el comité Técnico Científico CTC, ya que el sistema de información es indispensable para la empresa, es por eso que se llevo a cabo el desarrollo de este presente proyecto en modalidad de pasantía.

128

23. RECOMENDACIONES

Durante el desarrollo del proyecto para el Comité Técnico Científico CTC, se desarrollo hasta el documento de análisis y diseño para la EPS Seguro Social, sede en Bellavista en Cali, para esto al momento de implementar el sistema se recomienda realizar una equivalencia entre los diagramas de casos de uso, diagramas de clases, diagramas de secuencia y tablas donde se especifican los componentes de las interfaces que conforman los casos de uso y las respectivas tablas que se consulta en la base de dato, para lograr una coherente relación entre el diseño y la implementación de la aplicación. El trabajo futuro se debe diseñar la implementación acorde al Comité Técnico Científico CTC ya que este no se encuentra incluido en el documento de diseño.

129

BIBLIOGRAFIA

MTBase Sybase de Colombia [en línea]. Colombia: Sybase de Colombia. [Consultado 10 de noviembre, 2007]. Disponible en Internet: http://www.mtbase.com/productos/gestionbasesdedatos PRESSMAN, Roger S. Ingeniería del Software: Un enfoque práctico. 6 ed. México D.F.: McGraw-Hill, 1998. 581 p. Seguro Social [en línea]. Colombia: ISS, 2007. [Consultado en noviembre de 2007]. Disponible en Internet: http://www.iss.gov.co/ SOMERVILLE, Ian. Ingeniería del Software. 6 ed. México: Addison Wesley, 2001. 299 p. UML, Object Management Group, Unified Modeling Language UML [en línea]. Estados Unidos: UML, 2007. [Consultado 15 de agosto, 2007]. Disponible en internet: http://www.uml.org/ Wikipedia. Enciclopedia Libre [en línea]. Florida: Microsoft Visual Basic, 2007. [Consultado 05 de noviembre, 2007]. Disponible en Internet: http://es.wikipedia.org/wiki/Visual_Basic

130

ANEXOS

Anexo 1. Formato Ingreso de Solicitud

Documents

JENNIFER POSSO HENAO