Informe de analisis proyecto sigs

2

PROYECTO SISTEMA INFORMÁTICO DE GESTIÓN EN SALUD (SIGS)

CARLOS ENRIQUE NAVIA TORRES

DANNY PASTOR URBANO BANGUERA

SERVICIO NACIONAL DE APRENDIZAJE (SENA)

CENTRO AGROINDUSTRIAL Y PESQUERO DE LA COSTA PACIFICA

TUMACO 2009

3

PROYECTO SISTEMA DE INFORMÁTICO DE GESTIÓN EN SALUD (SIGS)

CARLOS ENRIQUE NAVIA TORRES


PROYECTO FORMATIVO:

TECNOLOGO ANÁLISIS Y DESARROLLO DE SISTEMAS DE INFORMACION

INSTRUCTOR

ING.EDINSON BANGUERA MAIRONGO

SERVICIO NACIONAL DE APRENDIZAJE (SENA)

CENTRO AGROINDUSTRIAL Y PESQUERO DE LA COSTA PACIFICA

TUMACO 2009

TABLA DE CONTENIDO

1 DESCRIPCIÓN DEL PROYECTO FORMATIVO 5

1.1 NOMBRE DEL PROYECTO: PROYECTO SISTEMA DE INFORMÁTICO DE GESTIÓN EN SALUD (SIGS) 5 1.2 DESCRIPCIÓN DEL PROBLEMA 5 1.3 JUSTIFICACIÓN DEL PROYECTO 5 1.4 OBJETIVOS 6

1.4.1 General 6 1.4.2 Específicos 6

1.5 IMPACTO (SOCIAL, ECONÓMICO, AMBIENTAL, TECNOLÓGICO) 6 1.6 RESTRICCIONES O RIESGOS ASOCIADOS 6 1.7 PRODUCTOS O RESULTADOS DEL PROYECTO 6 1.8 PERSONAL RESPONSABLE 7 1.9 PRESUPUESTO REQUERIDO 7 1.10 CRONOGRAMA DE ACTIVIDADES 7

2 DEFINIR LOS REQUERIMIENTOS DEL SISTEMA DE INFORMACIÓN 14

2.1 TÉCNICAS E INSTRUMENTOS DE RECOLECCIÓN DE LA INFORMACIÓN 14 2.2 MAPA DE PROCESOS 14 2.3 PLATAFORMA TECNOLÓGICA DE LA EMPRESA 16

3 ANALIZAR LOS REQUERIMIENTOS DEL SISTEMA DE INFORMACIÓN 16

3.1 CICLOS DE VIDA DEL SOFTWARE 16 3.2 ESPECIFICACIONES DE REQUERIMIENTOS DE SOFTWARE 18 3.3 DIAGRAMAS DE CASOS DE USO 22

3.3.1 Especificaciones de Casos de Uso 23 3.4 DIAGRAMA DE INTERACCIÓN 31

3.4.1 Diagrama de secuencia 31 3.4.2 Diagrama de colaboración 39

3.5 DIAGRAMA DE CLASES 44 3.6 BASE DE DATOS 45

3.6.1 Diccionario de Datos - Mini especificaciones 45

4 DISEÑAR EL SISTEMA DE ACUERDO CON LOS REQUERIMIENTOS 58

5 DESARROLLAR EL SISTEMA DE INFORMACIÓN 59

6 IMPLANTAR LA SOLUCIÓN DEL SISTEMA DE INFORMACIÓN 60

7 PARTICIPAR EN EL PROCESO DE NEGOCIACIÓN DE TECNOLOGÍA INFORMÁTICA 61

8 APLICAR PRÁCTICAS DE CALIDAD EN EL PROCESO DE DESARROLLO DE SOFTWARE 62

9 CONCLUSIONES 63

10 BIBLIOGRAFIA 64

ANEXOS 65

1 DESCRIPCIÓN DEL PROYECTO FORMATIVO 1.1 Nombre del Proyecto: Proyecto sistema de informático de gestión en

salud (SIGS)

1.2 Descripción del Problema El proyecto se plantea basado en la necesidad de un sistema de información que le permita a los usuarios, verificar la información de los pacientes (historias clínicas), verificar la EPS o ARS a la que están afiliados en forma activa y sin necesidad de recurrir a un software externo, ya que toda la información estará disponible en este sistema, así mismo para que el personal encargado de facturar estos eventos tenga la información necesaria en el momento exacto y así agilizar la atención, por otro lado los médicos contaran con un sistema de fácil entendimiento, con la codificación necesaria y de paso muy útil para hacer la atención mas rápida, eficiente y cómoda para el paciente; además se contará con una aplicación que permitirá al usuario mantener y obtener su registro de vacunación, y así saber cuántas vacunas se ha aplicado hasta el momento, los refuerzos de las mismas, como también cuantas y cuales le hacen falta, pero lo mejor de este aplicativo es que como muchas veces necesitamos de este reporte y en ocasiones el usuario no se encuentra en la ciudad tendrá un aplicativo web que cumplirá con la misma función. Además contara con un aplicativo móvil que ayudara a las vacunadoras en sus barridos de vacunación en la zona rural donde no se puede tener acceso a la tecnología del internet este será operado por medio de celulares, terminales móviles o PDA. 1.3 Justificación del proyecto El municipio de Tumaco cuenta con diferentes entidades prestadoras de servicios de salud, cada una de ellas cuenta con un sistema de información propio de la empresa, pero se ha notado que necesitan tener abiertos muchos programas para llevar a cabo las actividades que allí se presentan, por tal razón se creara SGIS software por medio del cual se realizaran todas estas actividades sin necesidad de recurrir a programas externos, otra de las ventajas de SGIS es que al ver la necesidad de tener un registro de vacunación vigente y que por algún motivo no se tiene a la mano y es de suma importancia para desempeñar alguna labor entonces se implementa un aplicativo para vacunación semejante o mejor que el manejado por el PAI, el cual brindara esta información no solo en las entidades prestadoras de salud, sino también desde la comodidad del hogar por contar el mismo con una plataforma web.

6

1.4 Objetivos 1.4.1 General Ser el software más versátil del Mercado, brindando agilidad y eficiencia a los usuarios y a los funcionarios que lo operen y además ecológico por lo que con este sistemas se disminuirá el uso excesivo del papel. 1.4.2 Específicos Cumplir con más funciones que el software utilizado actualmente, brindar agilidad en la prestación de servicios, proveer de la información necesaria a todos los usuarios del sistema. 1.5 Impacto (social, económico, ambiental, tecnológico)

1. Social: el SGIS al ser un sistema compacto, mejoraría la atención de usuarios, siendo este el factor que más impacto tendrá y por ende le dará un estatus a la entidad en la sociedad

2. Económico: al ser versátil, reducirá los costos de operación, agilizara los procesos y generara los ingresos que por no tener un software rápido y eficaz muchas entidades prestadoras de servicios en salud pierden.

3. Ambiental: se eliminara el excesivo gasto de papelería, lo cual contribuirá en gran medida al medio ambiente

4. Tecnológico: se implementara el uso de las TIC`s, brindando así lo ultimo en tecnología para el almacenamiento, análisis y procesamiento de información.

1.6 Restricciones o Riesgos asociados

1) cambios en la normatividad sobre software destinados a la atención en salud

1.7 Productos o resultados del proyecto 1) Sistema de Información de fácil uso 2) facturación más eficiente. 3) Generación de reportes de manera oportuna y eficaz. 4) Información sobre los ingresos obtenidos durante el ejercicio, más claros

y precisos. 5) tener un control de los insumos de la institución. 6) Pertinencia en los reportes de vacunación. 7) Seguridad y disponibilidad de datos en la web para el registro de carnet

de vacunación 8) Distribución y control de los insumos de vacunación y afines

7

1.8 Personal Responsable

EQUIPO QUE PARTICIPO EN LA FORMULACION DEL PROYECTO

NOMBRE ESPECIALIDAD


Tecnólogo en Análisis y Desarrollo de Sistemas de Información

CARLOS ENRIQUE NAVIA Tecnólogo en Análisis y Desarrollo de Sistemas de Información

EDINSON BANGUERA MAIRONGO

Instructor ING. SISTEMAS.

1.9 Presupuesto Requerido

RECURSOS VALOR

Equipos $ 18.170.000

Herramientas

Talento Humano $ 9.800.000

Transporte $ 500.000

Materiales de Formación $ 5.430.000

Otros Insumos

TOTAL $ 33.900.000

Es el presupuesto requerido hasta el momento. 1.10 Cronograma de Actividades

Planeación

FASES DEL PROYECTO

ACTIVIDADES DEL PROYECTO

RESULTADOS DE

APRENDIZAJE

COMPETENCIA ASOCIADA

IDENTIFICACION DE LAS NECESIDADES DEL CLIENTE

Recolección de la información necesaria mediante entrevista y encuestas realizadas a la entidad o entidades que utilizaran el software

Conocer las necesidades de la entidad.

usa las herramientas de recolección de información para identificar las necesidades del cliente

8

Recolección de información por parte de los usuarios de las entidades prestadoras de servicios de salud, que han sido atendidos mediante el software utilizado por la misma.

Conocer las necesidades de los usuarios, saber que les gustaría que mejorara en el actual sistema de información y que les gustaría que se implementara.

Métodos de recolección de información (Encuestas, Entrevistas, Observación).

ANALISIS DE SISTEMAS DE INFORMACION

Procesamiento de la información obtenida durante el ejercicio de recolección de información realizado a ejecutivos, empleados y usuarios de la entidad prestadora de salud.

Elaborar una base de datos con la información recogida.

maneja y Elabora propuestas de trabajo, de acuerdo con la interpretación de las necesidades tecnológicas, expuestas en el informe de requerimientos

Análisis de los requerimientos adicionales (solicitados por los usuarios), y búsqueda de vías para implementarlos en el sistema de información, como valor agregado.

Una vez recogida la información se procede a analizarla y dependiendo de los resultados obtenidos, se procede a la toma de decisiones,

Procesamiento y análisis de la información obtenida en el proceso recolección de información.

desarrollar un anteproyecto utilizando el lenguaje unificado de modelado UML el cual nos indicara el comportamiento de las actividades

Elaborar diagramas de casos de uso. • Elaborar diagramas de clases. • Elaborar diagramas de transición de

Utiliza herramientas CASE para elaborar diagramas de casos de uso, que representen el estado actual de los componentes del sistema, apoyado en el Análisis del informe de

9

del sistemas para futuras correcciones

estado. • Elaborar diagramas de secuencias. • Realizar el modelo conceptual de la solución propuesta

requerimientos. Elabora los diagramas UML, de acuerdo con las características de cada uno de Ellos, basado en los requerimientos del cliente, utilizando herramientas CASE.

DISEÑO DEL SISTEMA DE INFORMACION

Tomando como referencia los datos obtenidos en la investigación previa, se procede al diseño del sistema de información.

Desarrollo del sistema haciendo uso de las TIC`s.

usa las herramientas de desarrollo de diseño de interfaces y base de datos

Se tiene en cuenta los requerimientos tanto de los ejecutivos como de los usuarios y se procede al desarrollo del sistema de información.

Implementación de los conocimientos adquiridos a lo largo del proceso de aprendizaje tanto dentro como fuera de la institución.

Habilidades en el manejo de las TIC`s, innovación, creatividad, capacidad para hacer de un producto existente una oportunidad de mejoramiento.

crear una base de datos donde la información del esquema de vacunación no se pierde

Construir la base de datos, a partir del modelo de datos determinado en el diseño del sistema, utilizando sistemas de gestión de base de datos,

Modela la base de datos, a partir de la valoración de la información obtenida en el diccionario de datos y el análisis de los procesos, de acuerdo con las Necesidades del sistema de información requerido.

Una vez analizado y realizado el diseño del sistema de información, se procede a la

Construcción de la base de datos de la empresa. Construcción base de datos de los usuarios.

Implementación del diseño del sistema de información, haciendo uso de las nuevas tecnologías, realizando las pruebas pertinentes antes de su instalación

10

CONSTRUCCION DE SOFTWARE

construcción del mismo, teniendo en cuenta los requerimientos del cliente, y los valores agregados que se le puede dar al sistema de información aplicados a las necesidades de los usuarios (comunidad en general), las cuales se obtuvieron utilizando las técnicas de recolección de información.

Construir y habilitar los diferentes tipos de contratos establecidos por las empresas con las EPS`s, IPS`s y ARS`s. Habilitar los diferentes niveles de Atención así como los servicios prestados en cada uno de ellos y su codificación. Verificación del sistema en busca de errores.

final.

Diseñar la solución informática donde se pueda consultar en internet y crear software para recolección de esta información en dispositivos móviles y en PC de escritorio para finalmente sincronizarla y actualizar a la base de datos central.

Interpretar el informe técnico de diseño, para determinar el plan de trabajo durante la fase de construcción del software. Construir la interfaz de usuario, apoyado en la evaluación del prototipo, determinando las entradas y salidas requeridas en el diseño y definiéndolos lineamientos para la navegación, de acuerdo con las necesidades del usuario.

Construye la interfaz del aplicativo, siguiendo los parámetros establecidos en el diseño que cumpla con las necesidades del usuario final

diseñar bases de Construir la base Crea la base de datos en

11

datos que puedan ser manejadas fácilmente por el administrador del software

de datos, a partir del modelo de datos determinado en el diseño del sistema, utilizando sistemas de gestión de base de datos,

el motor de base de datos seleccionado, siguiendo especificaciones técnicas del informe

IMPLANTACION DEL SISTEMA DE INFORMACION

Instalación del aplicativo en la web; los programas de escritorios y móviles para poder recoger la información por parte de los funcionarios.

Construir el programa de instalación del aplicativo, utilizando las herramientas de desarrollo disponibles en el mercado, según las características de la arquitectura de la solución.

Elabora el programa de instalación del aplicativo, de acuerdo con las características y la arquitectura de la aplicación, utilizando herramientas tecnológicas, según normas y protocolos de la organización.

Una vez construido el software, se procede a implementarlo en la empresa realizando las pruebas necesarias.

analizar el sistema aplicándolo en la empresa.

realizar las pruebas pertinentes junto a las personas interesadas en el software.

en caso de no haber errores en el sistema se realiza una instalación total y se genera un reporte de funcionamiento, así como un manual de usuario para su fácil manejo. mostrar el software ya

Capacitar al personal que utilizara el sistema de información en el funcionamiento del mismo, así como enseñarles el manual de usuario y de esta forma explorará el sistema más a fondo.

hacerles entrega de un manual de usuario. tener presente realizar actualizaciones periódicas del sistema de información.

12

instalado, dejar que el cliente lo trabaje y esperar comentarios.

NEGOCIACION DE TECNOLOGIA PARA IMPLEMENTACION DEL SISTEMA

contactar a las empresas de tecnologías para negociarla y así hacer que nuestro software opere de la mejor manera

Interpretar el diagnóstico de necesidades informáticas, para determinar las tecnológicas requeridas en el manejo de la información, de acuerdo con las normas y protocolos establecidos por la empresa.

Interpretar diagnósticos de soluciones informáticas.

Solicitar las licencias concernientes al servidor web así como del software utilizado en la creación del aplicativo

Implementar el servidor web que mejor se adapte a los equipos que tiene la empresa al mismo tiempo que se tendrá la licencia del mismo y del software utilizado para así obtener un mejor rendimiento del aplicativo.

Permanecer al tanto de las actualizaciones y sobre todo tener acceso a ellas gracias a la legalidad del software utilizado.

CALIDAD DEL SOFTWARE

implementación del software y pruebas al mismo demostrando los alcances de este y sobre todo la estabilidad del mismo

Realizar la instalación del software y dar a conocer a los interesados que se puede hacer con el mismo y sobre todo la legalidad del mismo

Al comprar la licencia de los programas utilizados en la elaboración del software se tendrá la posibilidad de implementar actualizaciones de seguridad lo cual dará mayor estabilidad así como eficiencia al mismo.

determinar en el transcurso de la prueba del software las

Identificar puntos críticos dentro de los procesos para adoptar acciones

Identifica los puntos críticos de los procesos involucrados en el desarrollo de

13

debilidades del sistema que pueda tener algunos de sus procesos de sistematización

a seguir. software, para establecer acciones de control, siguiendo los estándares de calidad y las políticas de la organización

Evaluar los procesos involucrados en el desarrollo de software, aplicando técnicas de evaluación de procesos con el fin de desarrollar con calidad estos procedimientos.

• Evaluar los procesos del desarrollo de software, frente a un modelo de calidad.

Evalúa los procesos involucrados en el desarrollo de software, aplicando técnicas de evaluación de procesos, de acuerdo con los referentes de un modelo de calidad, para determinar su nivel de capacidad o madurez

2 DEFINIR LOS REQUERIMIENTOS DEL SISTEMA DE INFORMACIÓN

2.1 Técnicas e Instrumentos de Recolección de la Información Para recolectar información se contara con las técnicas de:

Encuestas

Entrevistas

Observación 2.2 Mapa de Procesos Mapa de procesos del SIGS

mapa de proceso hospital

facturacion

consulta externa

laboratorio

urgencias

p y p

vacunacion

15

Mapa de procesos de vacunación

Mapa de procesos de facturación

atencion al cliente

anamnecy (interrogatorio)

datos pesonales

historial medico

llenar formato de vacunacion

iniciar dosis correpondiente a

la edad

dar informacion

cita proxima vacunas

proceso de facturacion y cartera

atencion al usuario.

pedir documentos

revisar las bases de datos

archivo clinico.

legalizar la consulta

en el area que desea resivir la atencion

enviar cuenta de cobro a la otra entidad de

salud

enviar cuenta de cobro a la otra entidad de salud con farmacia

16

2.3 Plataforma Tecnológica de la Empresa Lo que tiene la empresa Computadores Impresoras Cd USB. Lo que requiere el software Dispositivos móviles: como terminales móviles o PDA. Computadores Sistema operativo Windows XP o vista. Servidor web.

3 ANALIZAR LOS REQUERIMIENTOS DEL SISTEMA DE INFORMACIÓN 3.1 Ciclos de vida del Software

CUADRO COMPARATIVO DE LOS MODELOS DE CICLO DE VIDA DEL SOFTWARE

nombre del modelo Ventajas Desventajas

Modelo Build and Fix

• Requiere de un modelo del ciclo de vida

– Planificación – Faces – Metas

– No especificaciones – No diseño • Totalmente

insatisfactorio

Cascada

– Documentación

– Más fácil mantenimiento

Documentos pueden ser ambiguos

Retroalimentación tardía

Requerimientos mal entendidos

• Modelo lineal • “Rápido” • Garantizar entendimiento de

requerimientos desde el inicio

– Puede crear la impresión de que el producto final puede generarse tan rápido como el prototipo – El equipo puede tener la

17

Prototipo Rápido

tentación de reusar el prototipo (código y diseño de baja calidad)

Modelo incremental

• Dividir el proyecto en builds • Menos traumático • Rápido retorno de la

inversión • Requiere de una arquitectura

abierta, se puedan integrar las porciones que se van generando a pesar de requerimientos no estáticos.

• Se usan variaciones de este ciclo de vida en los ciclos orientados a objetos.

– Peligro de caer en construir y corregir (Build-and-fix)

– Si no se tiene una arquitectura definida desde un inicio problemas para integrar y de mantenimiento

Modelo de espiral

• Forma simplificada – Modelo de cascada más

análisis de riesgo • A cada fase le precede

– Búsqueda de alternativas – Análisis de resign

• Despise de cada fase: – Evaluación – Planeación de la

siguietne fase

• Si los riesgos no pueden resolverse el proyecto termina inmediatamente

Modelo evolutivo

Menor probabilidad de que el proyecto falle.

Mayor productividad.

Mitigación de riesgos en iteraciones tempranas.

Progreso visible en un corto tiempo.

Retroalimentación oportuna.

En cada iteración se genera conocimiento que permitirá mejorar las subsecuentes iteraciones.

• El proceso no es visible (por la rapidez no es rentable documentar)

• Produce sistemas

pobremente estructurados (debido a los cambios continuos)

• Se requieren habilidades

especiales (en • herramientas para

prototipos rápidos)

18

Con el ciclo de vida que vamos a trabajar es el con del cascada por lo que con este ciclo podemos trabajar desde cero y es mas fácil de aplicar para nuestro proyecto. 3.2 Especificaciones de requerimientos de Software

Proyecto sistema de informático de gestión en salud (SIGS)

Introducción El municipio de Tumaco cuenta con diferentes entidades prestadoras de servicios de salud, cada una de ellas cuenta con un sistema de información propio de la empresa, pero se ha notado que necesitan tener abiertos muchos programas para llevar a cabo las actividades lo cual hace mas lenta la atención el cliente lo que hace insuficiente el servicio. Propósito El presente documento tiene como propósito definir los requerimientos de software del que allí se presentan, por tal razón se creara SGIS software por medio del cual se realizaran todas estas actividades sin necesidad de recurrir a programas externos. El público esperado por la presente especificación de requerimientos corresponde al cliente que encarga el proyecto y el equipo de desarrollo. Alcance El proyecto será conocido ahora en adelante como: “SIGS”, por lo tanto a partir de ahora al hacer referencia al software, producto de software, “SIGS”; nos Referiremos a lo mismo. El SIGS deberá permitir tener un registro de facturación y de sistematización de los procesos de citas, consulta externa, farmacia, odontología, urgencia, promoción y prevención y de vacunación vigente y que por algún motivo no se tiene a la mano y es de suma importancia para desempeñar alguna labor entonces se implementa un aplicativo para vacunación semejante o mejor que el manejado por el PAI, el cual brindara esta información no solo en las entidades prestadoras de salud, sino también desde la comodidad del hogar por contar el mismo con una plataforma web como también ayudará a la entidades para reportar e inventariar sus vacunas. Definiciones, acrónimos y abreviaciones SIGS: sistema informático en gestión en salud. Referencias Los siguientes documentos se han consultado para la confección de la actual especificación de requerimientos: IEEE-Std-830-1998: IEEE Recommended Practice for Software Requirements Specifications.

19

Como también investigación por nuestra parte a los profesionales idóneos en el tema que nos han asesorado para poder llevar a feliz termino y que nuestro software sea el mas eficiente y completo del mercado en el ámbito de la salud. Acerca El documento se encuentra organizado respetando la estructura propuesta en el estándar IEEE-830 Descripción general Se dispondrá de una aplicación de escritorio que operara baja la plataforma de Windows, un software para dispositivos móviles como terminales móviles o PDA la cual operara bajo plataforma java y un servidor Apache con soporte de PHP y un motor de base de datos. Los detalles de estos serán dados más adelante. El equipo que ejecutará los servidores será accesible desde Internet en el caso de los usuarios para averiguar el estado de vacunas. Las características del equipo y el acceso a internet dependerán en gran medida de la cantidad de usuarios que visiten la página web a la vez. Perspectivas del producto El SIGS estará alojado en un sistema mayor y será accedido por varios sistemas, Por lo que se necesita mantener el respeto de los distintos estándares asociados a la web y en particular con la aplicación. Se debe tener cuidado con respecto a una correcta visualización en los navegadores más extendidos en el mercado: Internet Explorer, Mozilla Firefox, Opera, Safari, Konqueror, etc. La comunicación entre el servidor de páginas web y el servidor de bases de datos podrá ser local o remota, es decir se pueden encontrar instalados en una misma máquina o en distintas maquinas. Esto en el caso de la plataforma web del sistema. En el caso de la aplicación de escritorio manejar la plataforma Windows ya que esta es el estándar en el mercado. En el caso de los dispositivos móviles el sistema trabajara con plataforma java. Interfaces de sistema Conexión entre Apache y MySQL: Provista por módulos de PHP, por lo que debe estar instalado el modulo php_mysql.dll y cargado en el archivo de configuraciones de PHP. Que las aplicaciones se sincronicen para poder trasladar información de una a otra aplicación ya que esto es esencial para las el personal de la zona rural y los que hacen barridos en las calles por lo que evitan la transcripción.

20

Conexión entre el SIGS y el sistema que lo aloja: Será provista por el servidor Apache. Interfaces de usuario Las interfaces de usuario serán provistas vía HTML por lo que las restricciones son las relativas a este lenguaje de marcas. Las interfaces de usuario deberán tener colores y que sean agradables al administrador del sistema. Las distintas secciones y opciones deben ser operados desde un menú principal. Interfaces de hardware El SIGS (sistema informático de gestión en salud) hará uso de los siguientes recursos de hardware:

Puerto USB la cual nos servirá para sincronizar esta información con los demás programas.

Puerto TCP 80: Usado para el acceso por parte del visitante vía navegador. Puerto de acceso al motor de base de datos: Dependerá del motor de base datos. Interfaces de software El sistema no tendrá interfaces con otro software.

Interfaces de comunicaciones Protocolo TCP. Restricciones de memoria Las restricciones de memoria dependerán de la cantidad de usuarios que visiten el sitio, por lo tanto se deberá especificar cuando se determine el tamaño total del sitio, como de la aplicación de escritorio y del dispositivo móvil. Operación El sistema deberá soportar el respaldo de las configuraciones y los datos publicados por los usuarios. Requisitos Funcionales Requisito funcional 1: Debe existir un modulo que permite la administración de usuarios y sus permisos. Requisito funcional 2: Debe existir un modulo que permita el ingreso y edición de la información referente al cliente dependiendo la atención, como también de los datos de inventarios de las vacunas y los reportes de vacunas aplicadas a los usuarios del sistema. Requisito funcional 3: Debe existir un modulo que permita el manejar los reportes de facturación de procedimiento y vacunación de la entidad. Requisito funcional 4: Debe existir un modulo que permita sincronizar la información de cada dispositivo del software móvil al de escritorio y web y del escritorio al web.

21

Requisito funcional 5: Debe existir un modulo que permita modificar y adicionar los campos al sistemas. Requisito funcional 6: Debe existir un modulo que permita generar los reportes de tanto de facturación como de los procedimientos médicos y de vacunación, estado de vacunación de los usuarios y reporte que se presentan a la eps, secretaria y ministerio de salud nacional Requisitos No Funcionales Requisito de rendimiento Hasta el momento no se ha especificado la cantidad estimada de usuarios a ingresar por parte de este sistema además los tiempos de respuestas dependerán directamente de los motores a utilizarse (web y de base de datos), este tema es materia de continuo estudio por parte del desarrollador del sistema a cargo dejando dicha responsabilidad al equipo que esté a cargo del software. Seguridad El sistema contempla un sistema de cuentas con diferentes niveles de permisos para lo que manipulación de información se refiere. El sistema no debe permitir la edición de los registros a menos que se tenga explícitamente los permisos Fiabilidad El sistema al ser un sistema controlado por el administrador para modificación de datos que solo maneja personal administrativo en su funcionamiento, la fiabilidad en el presente sistema pasa por el aspecto recién mencionado. Los tiempos de respuesta ante fallas tanto en la información como del funcionamiento dependen directamente de la política de la empresa debido a que estos aspectos son de carácter administrativo y operativo del software. Disponibilidad La disponibilidad dependerá directamente de la política de la empresa, los sistemas web soportan una disponibilidad de 24/7 (24 hrs al día 7 días a la semana), con esto queremos decir que teóricamente el sistema puede estar siempre online pero dependerá del hardware utilizado en la implementación como el que opera en el computador de escritorio o dispositivo móvil los cuales su disponibilidad depende a los criterios de la empresa. Mantenibilidad El sistema está diseñado en módulos permitiendo que el sistema sufra modificaciones sobre todo de interface de usuario. La base de datos debe ser respaldada vaciada del servidor periódicamente quedando a criterio del desarrollador la continuidad de dicho trabajo.

22

Portabilidad El sistema no presenta dependencia con respecto a un sistema operativo definido permitiendo esto que pueda utilizarse en diferentes entornos mientras en ellos se esté corriendo un servidor web con soporte PHP y con un servidor de base de datos, en el diseño del presente sistema contemplamos como motor de base de datos MySQL. En resumen la portabilidad depende de la disponibilidad de los motores en los diferentes sistemas operativos. La aplicación corre completamente desde el servidor siendo la página vista en los clientes el resultado del procesamiento del contenido hecho en el servidor en el caso de la web. En los entornos de escritorio y móvil el sistema dependerá de una plataforma para el de escritorio el estándar del mercado que es Windows y para el dispositivo móvil que este software se ejecute en una plataforma java. 3.3 Diagramas de Casos de Uso Aquí se muestra el comportamiento del sistema en base de las actividades del hospital.

23

3.3.1 Especificaciones de Casos de Uso Aquí es donde se documenta los respectivos casos de usos diseñados inicialmente, con el fin de tener mas claridad en el desarrollo del sistema; además nos sirve para documentar aun mas nuestro proyecto y es aquí donde se muestra el proceso realizado normalmente en la entidad o tema a sistematizar y el como lo hará el sistemas.

Nombre caso de uso: CITAS MEDICA ID única: usuario .cc

Área: Atención y procedimientos

Actor(es): cliente, facturador

Descripción: permite al facturador recopilar o verificar los datos de ley como para que atención asiste

Activar evento: el administrador del software verifica la información del paciente y se remite al procedimiento solicitado, se da información al paciente a los procedimientos que puede acceder de acuerdo a su edad.

Tipo de señal: externa temporal

Pasos desempeñados (ruta principal)

Información para los pasos

Petición de documentos Llenar formularios con datos de ley

Atención que desea recibir Seleccionar la opción de la atención a recibir

recomendaciones Procedimientos de acuerdo a la edad del paciente

Precondiciones: pacientes que no están en sistema ingresarlos

Pos condiciones: el administrador ha guardado la información exitosamente

Suposiciones: paciente no presenta ningún documento o no recuerda el número de identificación.

Reunir requerimientos: solicitar documentos y recopilar la información pertinente a los pacientes.

Aspectos sobresalientes: restringir el número de veces que asiste un paciente a los servicios prestados por la entidad.

Prioridad: media

Riesgo: media

Nombre caso de uso: CONSULTA EXTERNA ID única: C.externa .cc

Área: realización de los procedimientos

Actor(es): cliente, medico general

Descripción: es donde se realiza la atención al cliente y se le hacen los chequeos respectivos para tratar de conseguir la afección.

Activar evento: el administrador del software verifica la información del paciente en cuestión de historial medico mirando los antecedentes de enfermedades que tiene el paciente y describe en el historial la nueva

24

enfermedad que presenta el paciente.




El medico verifica los datos del paciente

Llenar formularios con datos de ley

El medico hace los chequeos respectivos para diagnosticar la afección del paciente

En el formato coloca el código del diagnostico

Receta los medicamentos o envía exámenes

En el formulario describe la receta medica o describe el tipo de examen a realizar

Precondiciones: el paciente ya saco la cita para esta atención

Pos condiciones: el medico ha guardado la información de diagnostico y receta medica o examen laboratorio exitosamente

Suposiciones: ninguna.

Reunir requerimientos: recopilar la información pertinente a del paciente en cuestión de historia clínica.

Aspectos sobresalientes: la atención es por un solo problema de salud no se permite mas.

Prioridad: ALTA

Riesgo: ALTA

NOMBRE CASO DE USO: LABORATORIO ID única: Laboratorio .cc

Área: realización y análisis de muestras de medicas

Actor(es): cliente, bacteriólogo.

Descripción: Es donde se realizan al paciente todos los exámenes que envía el medico, previa facturación de los mismos.

Activar evento: el administrador del software verifica la información del paciente en cuestión, se verifica que los exámenes enviados por el medico estén previamente facturados y se procede a la toma de los mismos.




El auxiliar de laboratorio verifica los datos del paciente


El auxiliar realiza la toma de los respectivos exámenes.

En el formato se coloca el resultado de los exámenes y se envían al medico.

Precondiciones: el paciente debe ser remitido por un medico para la toma de exámenes.

Pos condiciones: el auxiliar de laboratorio ha guardado y enviado la información de los resultados de los exámenes de laboratorio.

25

Suposiciones: En ocasiones no hay reactivos por lo tanto algunos exámenes quedaran pendientes.

Reunir requerimientos: los exámenes deben ser enviados únicamente por un medico de lo contrario se hará caso omiso.

Aspectos sobresalientes: la atención es por un solo problema de salud no se permite mas.

Prioridad: ALTA

Riesgo: ALTA

Nombre caso de uso: URGENCIA ID única: Urgencias .cc

Área: Atención de urgencias

Actor(es): cliente, enfermeras, auxiliar de laboratorio, regente, medico general

Descripción: es donde se realizan los procedimientos de extrema urgencia los cuales no dan espera para ser tratados en consulta externa.

Activar evento: Se realiza Triage al paciente para corroborar que la consulta debe ser atendida como una urgencia, luego se solicitan documentos, pasa el paciente al área de facturación donde se verifican los datos y se le hace la admisión, el paciente pasa donde el medico quien le brinda la atención pertinente, el medico a su vez le envía una serie de exámenes para poder entregar un diagnostico acertado y poder suministrarle el tratamiento que el paciente requiere durante la consulta de urgencias, luego el medico remite al paciente a controles en consulta externa para tratar mas a fondo la enfermedad.




La enfermera jefe realiza Triage al paciente

Se toman los signos vitales del paciente y se llena un formulario el cual pasa al área de facturación y posteriormente al medico de turno.

El medico hace los chequeos respectivos para diagnosticar la afección del paciente , se le envía exámenes al mismo

En el formato el medico coloca el diagnostico de ingreso del paciente así mismo como los exámenes y procedimientos que se van a realizar durante la atención.

Se reciben resultados de exámenes de laboratorio

Se verifican los resultados de los exámenes de laboratorio, de esta forma el medico puede diagnosticar mejor al paciente y tomar las medidas correspondientes al caso.

Se le da salida al paciente Ya con los resultados el medico le da salida al paciente suministrándole los medicamentos necesarios para el

26

tratamiento de la urgencia medica y de paso hacerle recomendaciones a los pacientes sobre el cuidado de su salud.

Precondiciones: el paciente debe presentar las condiciones mínimas para ser atendido por urgencias.

Pos condiciones: el medico ha guardado la información de diagnostico y receta medica o examen laboratorio exitosamente

Suposiciones: Si el caso no se puede tratar adecuadamente en la institución se le da al paciente remisión a otro nivel de seguridad.

Reunir requerimientos: recopilar la información pertinente a del paciente en cuestión de historia clínica.

Aspectos sobresalientes: la atención es por problemas de salud de extrema urgencia

Prioridad: ALTA

Riesgo: ALTA

Nombre caso de uso: PROMOCION Y PREVENCION

ID única: PyP .cc

Área: capacitación.

Actor(es): cliente, enfermera, medico general, odontólogos.

Descripción: es donde se realizan los procedimientos concernientes a la promoción y prevención, se realizan de acuerdo a las edades y sexo de los pacientes y a su frecuencia.

Activar evento: el administrador del software verifica la información del paciente en cuestión de historial medico mirando los antecedentes de enfermedades que tiene el paciente así como los controles a los que ha asistido y a los que debe asistir en ese periodo.




El profesional en salud verifica los datos del paciente


El profesional de la salud realiza los procedimientos de PyP respectivos dependiendo de la edad y sexo de los pacientes.

En el formato coloca el avance del paciente de acuerdo a los controles a los que a asistido, siendo de mucha importancia la edad y el sexo del

27

paciente.

Se brinda charla educativa y se hacen recomendaciones a los pacientes.

Se educa al paciente con respecto al cuidado de su salud, de los avances que ha tenido durante el control el cual debe ser seguido por un medico, auxiliar de enfermería, u odontólogo.

Precondiciones: el paciente debe encontrarse en la edad y sexo respectivo para recibir a atención.

Pos condiciones: el encargado en la atención y capacitación desde registrar al personal asistente a la charla

Suposiciones: el paciente no se encuentra en las edades y sexo respectivos.

Reunir requerimientos: el paciente debe estar en el centro asistencial y estar en espera a su atención medica.

Aspectos sobresalientes: se debe captar al paciente y hacerle darle un a charla sobre el problema que manifiesta como recomendaciones para mejorar su vida.

Prioridad: media

Riesgo: media

NOMBRE CASO DE USO: VACUNACION ID única: vacunación .cc

Área: control de patologías.

Actor(es): cliente, enfermera.

Descripción: es donde se realizan los procedimientos concernientes a la aplicación de vacunas de acuerdo a la edad; control de las vacunas que llegan desde el departamento de salud, para su posterior inventario y distribución a los diferentes sedes del hospital o eps.

Activar evento: el administrador del software verifica la información referente a la cantidad de vacunas que hay cuantas le envía a las sucursales; como también el control del registro de vacunación del paciente fijándose en el historial de vacunación anterior para actualizarla.




El profesional en salud verifica los datos del paciente


El profesional de la salud realiza los procedimientos de verificación de las vacunas aplicadas y llena los registros de la próxima vacuna y aplica la vacuna que le toca en la cita actual.

Se llena el formulario con las vacunas aplicadas al paciente y se les deja pendiente las próximas a hacer aplicadas

Se determina en el. Inventario cuantas vacunas sean aplicado y cuantas les falta por aplicar en el

En alguna parte del software debe existir una opción que mantenga al tanto al personal como la jefe de la

28

establecimiento. dependencia del reporte de estas vacunas y que paso con ellas.

Debe llevar un registro digital del historial de vacunación

Se debe actualizar la información tanto en la base de datos de la aplicación como en internet

Precondiciones: el paciente debe tener su carnet o certificado de registros de vacunación.

Pos condiciones: el profesional en salud debe actualizarle el certificado de vacunación y actualizar los registros en internet.

Suposiciones: en caso de no tener un carnet de vacunación se le realiza uno nuevo.

Reunir requerimientos: el paciente debe tener su carnet o certificado de vacunación

Aspectos sobresalientes: en caso de barrido se debe llevar una versión portable para móviles para poder hacer el registro de la información

Prioridad: media

Riesgo: media

NOMBRE CASO DE USO: FACTURACION ID única: vacunación .cc

Área: control de patologías.

Actor(es): cliente, facturador

Descripción: es donde se realizan los procedimientos concernientes a la aplicación de vacunas de acuerdo a la edad; control de las vacunas que llegan desde el departamento de salud, para su posterior inventario y distribución a los diferentes sedes del hospital o eps.

Activar evento: el administrador del software verifica la información del paciente la atención que recibió y los medicamentos o exámenes que el medico le recetó como el valor de estos para su posterior envío a la eps en la que esta afiliado el usuario.




El facturador verifica los datos del paciente


El facturador realiza los procedimientos de verificación de los servicios recibidos y su posterior.

Se llena el formulario con las atenciones y procedimientos realizados, medicamentos y exámenes y se agrega el valor por cada procedimiento

Se envía un reporte de todas las actividades de cobranza al jefe de facturación para que este lo revise y pasa la cuenta de cobro a cada eps.

En alguna parte del software debe existir una opción que permita imprimir un reporte con toda la información referente a los servicios prestados con su respectivo valor a pagar por la eps.

29

Precondiciones: el paciente debe haber recibido una atención médica para hacerle cobro.

Pos condiciones: el facturador debe guardar esta información y enviarla al jefe de facturación.

Suposiciones: ninguna.

Reunir requerimientos: el paciente debe haber recibido la atención medica por la que fue facturado

Aspectos sobresalientes: ninguno

Prioridad: media

Riesgo: media

NOMBRE CASO DE USO: COPAGO ID única: COP .cc

Área: Pago por servicios

Actor(es): cliente, facturador, trabajador social

Descripción: es donde se realizan los procedimientos de cobro al paciente de un porcentaje cuando este no esta afiliado a una eps el cual tiene que ser valorado por el trabajador social quien decidirá si el cliente debe pagar o no.

Activar evento: el administrador del software verifica la información del paciente los procedimientos que le fueron realizados el valor de cada uno de estos y la eps a la que esta afiliado.




El facturador verifica los datos del paciente y realiza el cobro por los servicios prestados.

Verificar datos del paciente, si este no presenta carnet de salud realizar cobro por los servicios prestados al paciente.

Si el paciente no puede o no tiene el dinero cobrado por los servicios se lo remite donde el profesional de trabajo social

Si el paciente no presenta carnet de salud se le hace el cobro total por los servicios prestados. Si el paciente asume no tener el total del valor a pagar el facturador lo remite donde el profesional en trabajo social. El profesional en trabajo social hará un estudio socio-económico al cliente para con ello asignarle una nueva tarifa a pagar la cual será soportada con un recibo con firma y sello del profesional en trabajo social.

Se realiza el cobro de los servicios esta vez con los valores asignados por el profesional en trabajo social en un recibo con firma y sello del mismo.

Se solicita recibo con descuento por parte del profesional en trabajo social. Se hace l cobro respectivo de los servicios prestados con el descuento y se le anexa el recibo de trabajo social.

30

se educa al cliente Una vez realizado el proceso de facturación se educa al paciente para que acuda a la secretaria de salud y realice las diligencias con el fin de obtener un carnet de salud y se evite estar pagando por este tipo de servicios.

Precondiciones: El paciente no presenta carnet de salud

Pos condiciones: El facturador debe cobrar al cliente los servicios prestados

Suposiciones: en caso de no tener dinero suficiente para pagar el cliente debe remitirse a trabajo social.

Reunir requerimientos: el paciente no debe tener carnet de salud.

Aspectos sobresalientes:

Prioridad: media

Riesgo: media

NOMBRE CASO DE USO: REPORTE DE FACTURACION

ID única: Reporte .cc

Área: Pago por servicios

Actor(es): jefe de facturación, EPS, IDSN

Descripción: Es donde el jefe de facturación una vez cumplido el mes hace un compilado de todas las actividades realizadas por la institución y las separa por EPS para luego realizar el cobro respectivo.

Activar evento: el administrador del software recopila la información generada por el área de facturación y realiza un informe detallado sobre cada EPS para así generar los cobros respectivos.




El jefe de facturación hace la recolección de la información generada en el área de facturación.

Los facturadores deben tener la información al día para que el jefe de área realice la recolección de la misma en el momento indicado por la empresa.

Se clasifica la información y se la separa por empresas

La información se clasifica por tipo de atención y por EPS de esta forma se tendrá total control a la hora de cobrar los servicios.

Se verifica la información para solucionar algunos errores que no hayan sido detectados durante el proceso de facturación.

Una vez clasificada la información se verifica por medio de un filtro los posibles errores que se hayan cometido durante el proceso de facturación, esto con el fin de no tener glosas y cumplir con las metas estipuladas por cada una de las EPS.

31

3.4 Diagrama de Interacción 3.4.1 Diagrama de secuencia En estos diagramas se muestran el comportamiento del flujo de información de cada caso de uso, entre los objetos que participan en el sistema para posterior análisis y aquí se tiene una idea clara sobre lo que va hacer el sistema. Además con estos diagramas se puede ver el tiempo de vida de cada objeto que participa en este interacción.

Se compila la información mediante archivos planos los cuales a su vez deberán enviarse junto a los archivos físicos a cada una de las EPS

Una vez realizadas las correcciones pertinentes el jefe de facturación deberá hacer copias de los archivos generados mediante el validador de servicios y pasarlos a archivos planos los cuales pasaran a su vez al jefe de facturación de las EPS vinculadas a la empresa para así poder hacer el cobro respectivo por los servicios prestados.

Precondiciones: los servicios facturados deben estar al día

Pos condiciones: El jefe de facturación hace el cobro a las EPS por los servicios prestados

Suposiciones: en caso de cumplir con las metas propuestas deberá realizar plan de contingencia para lograr su cumplimiento.

Reunir requerimientos: La información no debe presentar errores de ninguna índole.

Aspectos sobresalientes: se tendrá la información en el momento indicado con los estándares de calidad exigidos y se obtendrán las ganancias esperadas.

Prioridad: alta

Riesgo: alto

32

Diagrama de secuencia de el caso sacar citas

33

Diagrama consulta externa

Diagrama laboratorio

34

Diagrama PyP

35

Diagrama de urgencias

36

Diagrama de vacunación

37

Diagrama de facturación

Diagrama de copago

38

Diagrama reporte de facturación

39

3.4.2 Diagrama de colaboración Con estos diagramas se muestra el flujo de información mas detallado entre los objetos que interactúan directamente aquí no se mide el ciclo de vida del objeto sino interacción directa entre los objetos participantes.

Diagrama de citas medicas

Diagrama consulta externa

40

Diagrama laboratorio

Diagrama PyP

41

Diagrama de urgencias

42

Diagrama de vacunación

Diagrama de facturación

43

Diagrama de copago

Diagrama reporte de facturación

44

3.5 Diagrama de Clases En este diagrama se comienza a diseñar los diferentes campos o tributos que tendrá las clases del sistema de información para poderse diseñar en un gestor de base datos y posteriormente en un lenguaje de programación en este diagrama se especifica las carteristicas básica que tendrá cada clase y sus atributos para que nuestro sistema pueda funcionar eficientemente.

45

3.6 Base de datos MAPA CONCEPTUAL DE LOS FUNDAMENTOS DE LA BASE DE DATOS en este diagrama esta todo lo relacionado con la teoría de base datos.

3.6.1 Diccionario de Datos - Mini especificaciones

En esta parte del análisis de sistemas se plasman los atributos y de las clases del sistema mas detalladamente mirando el desde el nombre del atributo hasta la longitud que va a tener en el sistema como otras descripciones que harán que sea mas detallado para la posterior creación de la base de datos en un gestor de base de datos y creación del software.

FACTURACIÓN, PROCEDIMIENTOS MÉDICOS Y VACUNACION.

Nombre: Funcionario

Alias: N/A

Descripción: Es donde se consigna la información del personal de salud del hospital.

Atributo Tipo de dato Visibilidad Valor inicial Tamaño -longitud

Apellido Cadena Publico 30

Nombre Cadena Publico 30

Tipo de documento

Cadena Publico

Numero de doc. integer Publico 10

Fecha de Date Publico dd/mm/aaaa 10

46

nacimiento

Sexo Carácter Publico M 1

Teléfono Integer Publico 10

Profesión Cadena Publico 60

Nº tarjeta Prof. Integer Publico

División de atención

Cadena Publico 80

Dirección Alfanumérico Publico 80

Nombre: Prestadoras

Alias: N/A

Descripción: Es donde se consigna la información de las entidades de salud

Atributo Tipo de dato

Visibilidad Valor inicial Tamaño -longitud

Nombre prestador

Cadena Publico 60

Nit/cc Integer Publico

Tipo de documento

Cadena Publico NI 2

Numero de doc. integer Publico 20

Numero factura Integer Publico 20

Fecha expedición factura

Date Publico dd/mm/aaaa 10

Fecha inicio Date Publico dd/mm/aaaa 10

Fecha final Date Publico /mm/aaaa 10

Código entidad admón.

Integer Publico 6

Nombre entidad admón.

Cadena Publico 30

Numero de contrato

Integer Publico 15

Plan beneficios Cadena Publico 30

Numero de póliza

Integer publico 10

Valor total del pago compartido (copago)

Real Publico 0.0 15

Valor de la comisión

Real Publico 0.0 15

Valor total descuentos

Real Publico 0.0 15

Valor neto a Real Publico 0.0 15

47

pagar

Nombre: Datos Usuario

Alias: N/A

Descripción: Es donde se consigna la información del personal de salud del hospital.


Tipo de identificación del usuario

Cadena Publico CC 2

Numero de identificación del usuario en el sist.

Entero Publico 20

Código entidad admón.

Entero Publico 6

Tipo usuario Entero Publico 1

Primer Apellido Cadena Publico 30

Segundo apellido

Cadena Publico 30

Primer nombre Cadena Publico 20

Segundo nombre

Cadena Publico 20

Edad Entero Publico 3

Unidad de medida de edad

Carácter Publico 1

Sexo Carácter Publico 1

Código de municipio

Entero Publico 2

Código de municipio residencia habitual

Entero Publico 3

Zona residencia Carácter Publico 1

Fecha de nacimiento

Date Publico /mm/aaaa 10

Teléfono Integer Publico

Nombre: Datos consulta externa

Alias: N/A

Descripción: Es donde se consigna la información del paciente y del proceso de

48

consulta.


Numero de la factura.

Entero Publico 20

Código prestador servicio

Entero Publico 10


Cadena Publico CC 2


Entero Publico 20

Fecha de la consulta

Fecha Publico /mm/aaaa

10

Número de autorización

Entero Publico 15

Código de consulta

Entero Publico 8

Finalidad consulta

Entero Publico 2

Causa externa Entero Publico 2

Código del diagnóstico principal

Entero Publico 4

Código del diagnóstico relacionado No. 1

Entero Publico 4


Entero Publico 4


Entero Publico 4

Tipo de diagnóstico principal

1

49

Valor de la consulta

0.0 15

Valor de la cuota moderadora

0.0 15

Valor neto a pagar

Real Publico 0.0 15

Nombre: Datos consulta externa

Alias: N/A

Descripción: Es donde se consigna la información del paciente y del proceso de consulta.



Entero Publico 20


Entero Publico 10


Cadena Publico CC 2


Entero Publico 20

Fecha de la consulta


10


Entero Publico 15

Código de consulta

Entero Publico 8

Finalidad consulta

Entero Publico 2

Causa externa Entero Publico 2


Entero Publico 4


Entero Publico 4

50


Entero Publico 4


Entero Publico 4

Tipo de diagnóstico principal

1

Valor de la consulta

0.0 15

Valor de la cuota moderadora

0.0 15

Valor neto a pagar

Real Publico 0.0 15

Nombre: Datos procedimiento.

Alias: N/A





Entero Publico 20


Entero Publico 10


Cadena Publico CC 2


Entero Publico 20

Fecha del procedimiento


10


Entero Publico 15

Código de procedimiento

Entero Publico 8

51

Ámbito de realización del procedimiento

Carácter Publico 1

Finalidad procedimiento

Carácter Publico 1

Personal que atiende

Carácter Publico 1


Entero Publico 4

Código del diagnóstico relacionado

Entero Publico 4

complicación Entero Publico 4

Forma de realización del acto quirúrgico

carácter Publico 1

valor del procedimiento

Entero Publico 0.0 15

Nombre: Datos Urgencia.

Alias: N/A





Entero Publico 20


Entero Publico 10


Cadena Publico CC 2


Entero Publico 20

Fecha de ingreso del usuario a observación


10

Hora de ingreso del usuario a

Fecha Hh : mm 5

52

Nombre: Departamento

Alias: N/A

Descripción: Es donde se consigna la información del departamento

Atributo Tipo de dato Visibilidad Valor inicial

Tamaño -longitud

Código departamento

Cadena Publico 2

Nombre departamento

Cadena publico 30

Nombre: Información municipio

observación


Entero Publico 15

Causa externa Cadena Publico 2

Diagnóstico a la salida

Cadena Publico 4

Diagnóstico relacionado No. 1, a la salida

Cadena Publico 4

Diagnóstico relacionado Nro. 2, a la salida

cadena Publico 4

Diagnóstico relacionado Nro. 3, a la salida

cadena Publico 4

Destino del usuario a la salida de observación

carácter Publico 1

Estado a la salida Carácter Publico 1

Causa básica de muerte en urgencias

entero publico 4

Fecha de salida del usuario de observación

fecha Publico dd/mm/aaaa

10

Hora de salida del usuario de observación

fecha Publico Hh : mm 5

53

Alias: N/A

Descripción: Es donde se consigna la información de las vacunas y nuevas vacunas para nuevas enfermedades


Tamaño -longitud

Código departamento

Cadena Publico 2

Nombre departamento

Cadena publico 30

Nombre: Usuario vacunación

Alias: N/A

Descripción: Es donde se recolecta todos los datos del paciente


Tamaño -longitud

Nombre Cadena Publico 30

Apellido Cadena Publico 30

Fecha de nacimiento

Date Publico /mm/aaaa 10

Dirección Cadena Publico 40

Aseguradora Cadena Publico 40

Sexo Carácter Publico M – F 1

Numero de afiliación

Integer Publico

Tipo identificación

cadena publico CC 2

Numero de ident.

Integer Publico

Grupo sanguíneo

Carácter Publico 1

RH Carácter Publico 1

Nombre: Carnet de vacunación

Alias: N/A

Descripción: Es donde se consigna la información que tiene que ver con las vacunas aplicadas a los usuarios.



biológico Cadena Publico 30

fecha date Publico /mm/aaaa 10

Próxima cita Date Publico /mm/aaaa 10

Laboratorio cadena Publico 30

Centro de salud Cadena Publico 40

54

Lote Integer Publico 30

Vacunador Cadena Publico 60

Observaciones Cadena Publico 255

Nombre: Esquema único de vacunación

Alias: N/A

Descripción: Es donde se consigna la información de las vacunas y nuevas vacunas para nuevas enfermedades


Tamaño -longitud

enfermedad Cadena Publico 30

vacuna cadena Publico 30

dosis Integer Publico

Numero dosis Integer Publico

Vía y sitio de aplicación

Cadena Publico 90

refuerzos cadena Publico 30

Nombre: Datos recién nacido

Alias: N/A

Descripción: Es donde se consigna la información que tiene que ver el estado de talla y peso del recién nacido para aplicarles las vacunas.


Tamaño -longitud

Peso al nacer Integer Publico

Peso al alta integer Publico

talla integer Publico

Perímetro cefálico

integer Publico

55

BASE DE DATOS REALIZADA EN ACCESS

Figura de las tablas de la base de datos(vista relaciones)

Desarrollo de base de datos con MYSQL vista de base y tablas de forma arbórea

56

INSTRUCCIONES SQL

El lenguaje de consulta estructurado (SQL) es un lenguaje de base de datos normalizado, utilizado por el motor de base de datos de Microsoft Jet. SQL se utiliza para crear objetos QueryDef, como el argumento de origen del método OpenRecordSet y como la propiedad RecordSource del control de datos. También se puede utilizar con el método Execute para crear y manipular directamente las bases de datos Jet y crear consultas SQL de paso a través para manipular bases de datos remotas cliente - servidor. Algunos ejemplos de este lenguaje son: Ejemplo1 Crear base de datos CREATE DATABASE sigs ; Ejemplo 2 Creación de una tabla

CREATE TABLE funcionario (Nombre TEXT (25) , Apellidos TEXT (50), identificación INTEGER CONSTRAINT);

Ejemplo 3 Introducir datos a una tabla

INSERT INTO funcionario (Nombre, Apellido, Cargo) VALUES ('Luis', 'Sánchez', 'Becario');

Ejemplo4 Ejemplo para consultar datos de un tabla de una base de datos. SELECT nombre, apellido FROM funcionario; Ejemplo 5 Para eliminar campos DELETE apellido FROM funcionario;

57

Ejemplo 6 Para eliminar tablas DROP TABLE funcionario;

58

4 DISEÑAR EL SISTEMA DE ACUERDO CON LOS REQUERIMIENTOS

5 DESARROLLAR EL SISTEMA DE INFORMACIÓN

6 IMPLANTAR LA SOLUCIÓN DEL SISTEMA DE INFORMACIÓN

7 PARTICIPAR EN EL PROCESO DE NEGOCIACIÓN DE TECNOLOGÍA

INFORMÁTICA

8 APLICAR PRÁCTICAS DE CALIDAD EN EL PROCESO DE DESARROLLO DE SOFTWARE

9 CONCLUSIONES Con este proyecto lo que se busca es impulsar la cultura de la utilización de las tic y los sistemas de información en nuestro procesos productivos para optimizar nuestros servicios y la gestión de la información. Con lo que nos hemos impulsado a la realización de este magno proyecto que tiene como finalidad sistematizar el proceso productivo de un hospital teniendo una alcance en las áreas de vacunación, procedimientos médicos hospitalarios y facturación como el control del personal que labora en la entidad esta iniciativa lleva consigo el soporte de las tecnología de la programación y el internet.

10 BIBLIOGRAFIA http://www.minproteccionsocial.gov.co/VBeContent/home.asp http://www.saludcolombia.com/actual/ultimas.htm http://www.noticieroficial.com/leyes/LEY100-1993.htm LEY 100 DE 1993 (diciembre 23) DECRETO 4747 DECRETO 3990 RESOLUCIÓN NÚMERO 003047 DE 2008 RESOLUCION 3374 DE 2000 (RIPS, EPICRISIS)

http://www.minproteccionsocial.gov.co/VBeContent/home.asp

http://www.saludcolombia.com/actual/ultimas.htm

http://www.noticieroficial.com/leyes/LEY100-1993.htm

ANEXOS

Informe de analisis proyecto sigs

Health & Medicine

Transcript of Informe de analisis proyecto sigs