Mi Proyecto de Bachiller - Edgar Cruz - Informe Completo
-
Upload
edgar-cruz -
Category
Documents
-
view
3.943 -
download
1
description
Transcript of Mi Proyecto de Bachiller - Edgar Cruz - Informe Completo
UNIVERSIDAD NACIONAL DEL SANTA FACULTAD DE INGENIERÍA
Escuela Académico Profesional de Ingeniería de Sistemas e
Informática
“DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN
PEDRO - CHIMBOTE”
INFORME DE PRÁCTICAS PRE-PROFESIONALES
PARA OPTAR EL GRADO DE BACHILLER DE SISTEMAS E INFORMÁTICA
ALUMNO: EDGAR ALEXANDER CRUZ HUAMAN ASESOR: Ing. DIANA CECILIA MUÑOZ CASANOVA
NUEVO CHIMBOTE –PERÚ 2005
UNIVERSIDAD NACIONAL DEL SANTA FACULTAD DE INGENIERÍA
Escuela Académico Profesional de Ingeniería de Sistemas e
Informática “DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA
ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN PEDRO - CHIMBOTE”
INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO DE BACHILLER DE
SISTEMAS E INFORMÁTICA Revisada y Aprobada por:
Ing. Diana C. Muñoz Casanova
UNIVERSIDAD NACIONAL DEL SANTA FACULTAD DE INGENIERÍA
Escuela Académico Profesional de Ingeniería de Sistemas e
Informática “DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA
ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN PEDRO - CHIMBOTE”
INFORME DE PRÁCTICAS PRE-PROFESIONALES PARA OPTAR EL GRADO DE BACHILLER DE
SISTEMAS E INFORMÁTICA
Sustentada y Aprobada por el siguiente jurado:
Ing. Sisto Díaz Tello Presidente
Ing. Hugo Caselli GuismondiSecretario
Ing. Carlos Guerra Flores Integrante
Dedicatoria
A Dios, que siempre me ilumina, me protege y cuida; dándome fuerzas para seguir adelante, conservando la fe y esperanza.
A ¡Mi Madre!!! Sra. Maria Esther Huaman Bacón.
Quien me ha dado su amor y apoyo para seguir adelante.
Y a ¡Mi Padre!!! Sr. Casimiro Cruz
Francisco. Quien me ha inculcado el deseo de superación
bajo cualquier circunstancia así como su amor y apoyo incondicional.
A mis hermanas: Devora Nevenga Cruz Huaman e Ivon Vanesa Cruz Huaman. Por su apoyo. A mi sobrino Aron Chávez Cruz, quien me alegra con su compañía. A mi primo Heli Morillo, quien ha sido un verdadero amigo en las buenas y en las malas.
A mis Amigos y Compañeros: Andrei, Willy, Benicia, Mónica, Deysi, Cesar, Aland, Juan Carlos, Erison, José
Norberto, Javier, Omar, Agusto, Luciano, Richard, Clever, Angélica, Roxana y a todos, quienes nunca dejaron de confiar en mi y por
siempre estar cuando los necesitaba.
i
Agradecimiento
A Dios, Por haberme dado la Vida así como la Sabiduría y las Fuerzas necesarias para alcanzar las metas que me he propuesto,para así proponerme otras.
A mis padres y hermanas, Por su apoyo moral y económico,
comprensión y confianza. Por su esfuerzo y sacrificio diario,
siendo los impulsadores en mí desarrollo y formación profesional. ¡Gracias!!!
A los Docentes: Del Colegio Nacional República Peruana, Academia Euclides, Universidad Nacional del Santa. Quienes me han brindado sus conocimientos para que así yo pueda superarme en la vida, gracias por saber escuchar y ser más que docentes y convertirse en amigos.
A la doctora Margarita Mendo Lagos así comoal personal del Puesto de Salud “San Pedro”, por haberme dado la oportunidad de realizar
mis practicas pre-profesionales en suestablecimiento de Salud así como su apoyo
incondicional.
A Clever Pinedo, un gran amigo y compañero de trabajo. ¡Gracias!!! Por tus consejos y apoyo incondicional.
A Andrei Miranda Bartolomé y Willy Díaz
Valqui. ¡Gracias!!!. Por ser mis mejores amigos y por estar siempre conmigo en las
buenas y las malas. ¡Gracias!!!
ii
Presentación
Señores miembros del jurado:
Haciendo uso del Reglamento General de Grados y Títulos de la Universidad Nacional
del Santa, me permito presentar ante Ustedes el Informe de Prácticas Pre-Profesionales
titulado:
“DESARROLLO DE UN SISTEMA DE INFORMACIÓN PARA LA
ATENCIÓN DE PACIENTES EN EL PUESTO DE SALUD SAN
PEDRO - CHIMBOTE”
Con la finalidad de optar el grado de Bachiller de Sistemas e Informática.
Este trabajo tiene como lugar de aplicación el Puesto de Salud San Pedro, la cual por su
naturaleza, función, antigüedad y tamaño de información (pacientes y sus datos) que
maneja, se ha visto en la necesidad de adquirir un aplicación que le ayude, facilite la
información necesaria en el más mínimo tiempo posible para poder tomar decisiones
adecuadas.
EL AUTOR.
iii
RESÚMEN
“Desarrollo de un Sistema de Información para la atención de pacientes en el
Puesto de Salud San Pedro - Chimbote”
Autor:
CRUZ HUAMAN, Edgar Alexander.
El presente trabajo implicó el Desarrollo de un Sistema para la Atención de Pacientes en
el Puesto de Salud San Pedro, el cual va a contribuir al apoyo del manejo de la
información sobre los pacientes.
El Sistema será aplicado en el área de Admisión del dicho establecimiento de salud. El
Sistema cubre los principales procesos de admisión, los cuales son registrar, modificar,
buscar, realizar consultas para la toma de decisiones en la atención médica.
Para efectos de desarrollo del Sistema se utilizó la Metodología eXtreme Programing
(XP), como desarrollador de aplicaciones se utilizó el lenguaje de programación Power
Builder así como el sistema gestor de base de datos SQL Anywhere.
Como resultado de este trabajo, se llegó a comprobar la veracidad de la hipótesis
planteada, al lograr la aceptación de la automatización por parte del directorio del
Puesto de Salud, dado que cumple con sus fines de controlar, acelerar la información,
así como apoyo el la toma de decisiones.
iv
ABSTRACT
“Development of an Information System in order to attend of patients in the
St. Peter Health Center - Chimbote”
Author:
CRUZ HUAMAN, Edgar Alexander.
The present work implies the Development of a System in order to Pacients' Attention
in the St. Peter Health Center, which goes to contribute to the support of the handling of
the information on the patients.
The System will be applied in Admission's area of the Health Center .The System
covers up the main things admission processes, them as they are to search, to modify, to
search, to accomplish consultations in order to the decision makings in the medical
attention.
In order to develop properties of the System , it was used the eXtreme Programming
Methodology ( XP ), as developer of applications it was used the programming
language Power Builder as well as the managing data system base SQL Anywhere.
This work's result, the hypothesis's veracity presented, gets to check itself to the
achieving the acceptance of the automatization for part of the Health Center's directory,
granted that it complies with its ends of controlling, accelerating the information, as
well as support the decision makings.
v
ÍNDICE GENERAL
CONTENIDO PAG.
DEDICATORIA i
AGRADECIMIENTO ii
PRESENTACIÓN iii
RESUMEN iv
ABSTRACT v
CAPÍTULO I: LA EMPRESA
1.1 Naturaleza 1
1.1.1 Nombre o Razón Social 1
1.1.2 Finalidad 1
1.1.3 Objetivos 1
1.2 Descripción de la Organización 2
1.2.1 Reseña Histórica 2
1.2.2 Base Legal 3
1.2.3 Ubicación Geográfica 3
1.2.4 Estructura Orgánica 4
1.2.5 Organigrama 5
1.2.6 Funciones 6
1.3 Misión 8
1.4 Visión 8
vi
CAPÍTULO II: PLANTEAMIENTO DE LA INVESTIGACIÓN
2.1 Problema 9
2.1.1 Realidad Problemática 9
2.1.2 Análisis de la Realidad Problemática 10
2.1.3 Formulación del Problema 11
2.2 Antecedentes 11
2.3 Justificación 12
2.4 Hipótesis 12
2.5 Objetivos 12
2.5.1 Objetivo General 12
2.5.2 Objetivos Específicos 13
CAPÍTULO III: FUNDAMENTO TEÓRICO
3.1 Marco Conceptual 14
3.1.1 Aplicación 14
3.1.2 Contraseña 14
3.1.3 Formularios 14
3.1.4 Servidor 14
3.2 Marco Teórico 15
3.2.1 Sistemas de Información 15
3.2.2 Arquitectura 16
3.2.3 Metodología Empleada 19
3.2.4 Herramientas Utilizadas 36
vii
CAPÍTULO IV: METODOLOGÍA
4.1 Procedimiento 57
4.1.1 Fases de la Metodología 57
4.2 Tipo de Investigación 60
4.3 Método de Investigación 60
4.4 Diseño de Investigación 61
4.4.1 Variables 61
4.5 Diseño Experimental 62
4.6 Cobertura de Estudio 63
4.6.1 Población 63
4.6.2 Muestra 64
4.7 Técnicas e Instrumentos 64
CAPÍTULO V: DESARROLLO DEL SISTEMA DE ADMISIÓN
5.1 Versiones del Software 65
5.2 Capacitación de Usuarios 66
5.3 Diseño de la Base de Datos 67
5.3.1 Diagrama Entidad Relación Actual 67
5.3.2 Diagrama Entidad Relación a usar 68
5.3.3 Modelo Relacional Actual 69
5.3.4 Modelo Relacional a usar 70
5.4 Diseño del Sistema 71
5.4.1 Prototipo del Sistema 71
5.4.2 Sistema Principal 72
5.4.3 Sistema de Admisión 79
viii
CAPÍTULO VI: RESULTADOS Y DISCUCIÓN
6.1 Demostración de la Hipótesis 96
6.2 Discusión 98
CONCLUSIONES 104
RECOMENDACIONES 105
REFERENCIAS BIBLIOGRÁFICAS 116
ANEXOS 109
ix
ÍNDICE DE FIGURAS
Figura 01: Organigrama del Puesto de Salud “San Pedro” 5
Figura 02: Coste del Cambio Actual 23
Figura 03: Coste del Cambio Propuesto 24
Figura 04: Comparación de Metodologías Tradicionales con XP 35
Figura 05: Servidor de Base de Datos Personal 44
Figura 06: Servidor de Base de Datos de Red 45
Figura 07: Diagrama ER Actual 67
Figura 08: Diagrama ER a Usar 68
Figura 09: Modelo Relacional Actual 69
Figura 10: Modelo Relacional a Usar 70
Figura 11: Prototipo del Sistema 71
Figura 12: Mensaje de Bienvenida 72
Figura 13: Autentificación de Usuario 72
Figura 14: Menú Principal 73
Figura 15: Cambio de Usuario 73
Figura 16: Datos de Usuario 74
Figura 17: Registrar Usuario 74
Figura 18: Cambiar Contraseña 75
Figura 19: Copias de Seguridad 75
Figura 20: Manual de Usuario General 76
Figura 21: Ayuda y Soporte Técnico 77
Figura 22: Accesorios 77
Figura 23: Acerca del Desarrollador 78
x
Figura 24: Ventana Familia 79
Figura 25: Registrar Familia 80
Figura 26: Modificar Datos de Familia 80
Figura 27: Borra Familia 81
Figura 28: Buscar Integrantes de Familia 81
Figura 29: Ventana Pacientes 82
Figura 30: Registrar Nuevo Paciente 83
Figura 31: Modificar Datos del Paciente 84
Figura 32: Borrar Paciente 85
Figura 33: Historia Clínica del Paciente 86
Figura 34: Numero de Personas por Pueblo Agrupadas por Sexo 87
Figura 35: Numero de Personas por Sector Agrupadas pos sexo 88
Figura 36: Pacientes por Fecha de Nacimiento o Defunción 89
Figura 37: Número de Integrantes por Familia según Pueblo 90
Figura 38: Mujeres Gestantes según Fecha 91
Figura 39: Numero de Familias por Pueblo y Sector 92
Figura 40: Relación de Pacientes Asegurados 93
Figura 41: Manual del desarrollador 94
Figura 42: Manual de Usuario – Admisión 95
Figura 43: Número de Respuestas por alternativa 100
xi
INTRODUCCIÓN
La vorágine en el avance tecnológico de la Informática y la necesidad de toda
Institución de contar con Sistemas de Información, que le puedan facilitar el acceso a
los datos en tiempos pequeños, así como mantener un control adecuado de la data para
la toma de decisiones y a la vez permitir la optimización de sus ingresos económicos al
reducir el personal y tiempo en los procesos manuales, a llevado a las organizaciones
empresariales e instituciones de cualquier índole a adquirir sistemas de información.
En la actualidad dentro de toda organización, existe una tendencia a pensar que el uso
de un sistema de información es necesario, suponiendo una innovación en la
administración de la información. Esto no deja de se cierto.
A medida que la Ingeniería del Software evoluciona, junto con ella su producto el
Software asume tareas más complejas, con metodologías en análisis, diseño y desarrollo
cada vez más sencillos; en la perspectiva del desarrollo del software.
Se ofrecen mejores interfaces para el usuario, cada vez atractivos a la vista y fáciles de
manipular haciendo buen uso del sistema informático, ofreciendo gran apoyo en la toma
de decisiones por parte de la directiva, siendo cada vez efectivas y oportunas.
El informe “Desarrollo de un Sistema de Información para la atención de pacientes en el
Puesto de Salud San Pedro - Chimbote”, es la respuesta al estudio de la problemática
actual de dicha organización, que se presenta por la imperiosa necesidad de reducir los
tiempos muertos en la búsqueda de Historias Clínicas pudiendo así generar más
xii
ingresos económicos al poder atender a mas pacientes, controlar el número de Historias
Clínicas, así también ayudar a la toma de decisiones de manera oportuna y segura.
El Capítulo I, detalla los datos Generales de la Institución Médica tales como su razón
social, su ubicación, finalidad, objetivos, estructura y otros puntos.
El Capítulo II, describe el Plan de Proyecto, especificando la Realidad Problemática,
Análisis de la Realidad Problemática, Formulación del Problema, Antecedentes,
Justificación, Hipótesis así como el Objetivo General y Objetivos Específicos.
El Capítulo III, describe el Fundamento Teórico; el cual está dividido en: Marco
Conceptual y Marco Teórico; el Marco Conceptual contiene conceptos básicos sobre
Informática, el Marco Teórico contiene teoría sobre los Sistemas de Información,
Arquitectura, la metodología empleada así como el lenguaje de programación y gestor
de base de datos que se utilizó.
EL Capítulo IV, describe la Metodología, en el se incluyen lo que se hizo en cada Fase
de la Metodología XP, el Tipo, Método y Diseño de Investigación, el Diseño
Experimental, la cobertura de estudio y las Técnicas e Instrumentos utilizados.
EL Capítulo V, describe el desarrollo del Sistema de Admisión, en el cual se incluyen
las versiones del software (que se hizo en cada versión y el tiempo que llevo hacerlas),
la capacitación a los usuarios, los diagramas de Entidad Relación y el Modelo
Relacional del sistema, así como las pantallas del sistema.
xiii
El Capítulo VI, describe los Resultados y Discusión, en el este capítulo se verá la
demostración de la hipótesis así como la respectiva discusión.
Finalmente se hace mención de las conclusiones y recomendaciones que surgen del
presente informe de Prácticas Pre-Profesionales.
Para respaldo de este informe, se agrego en la parte final los anexos correspondientes;
en el cual se hace mención: a las características de software y hardware, cuestionarios
para medir la optimización, cuestionarios para pruebas de software, el estudio de
factibilidad y por ultimo algunos reportes que proporciona el Sistema de Admisión.
xiv
“Sistema de Información para la
atención de Pacientes”
Capítulo I.
LA EMPRESA
Sistema de Información para la Atención de Pacientes UNS
LA EMPRESA
1.1 NATURALEZA
1.1.1 Nombre o Razón Social
Puesto de Salud “San Pedro”
1.1.2 Finalidad
Realizar actividades preventivas promocionales.
1.1.3 Objetivos
1.1.3.1 Objetivo General
Favorecer acciones integradoras que contribuyan al desarrollo de la
institución y garantizar una atención médica de calidad, eficiencia, y
eficacia con un bajo presupuesto de atención para la población.
1.1.3.2 Objetivos Específicos
1. Innovar el planeamiento estratégico.
2. Adquirir nuevos equipos y materiales médico - hospitalarios.
3. Crear nuevas fuentes de ingresos económicos.
4. Capacitar al personal para una mayor competitividad y brindar un
mejor servicio al paciente.
5. Obtener el apoyo de los medios de Comunicación social en las
medidas de prevención y educación.
6. Proporcionar a la instalación de los estándares comunitarios y/o
Materno Infantil, normas, manual de procedimientos, etc.; para el
mejor desempeño del personal de Enfermería y de los Asistentes
de Salud.
Edgar Alexander Cruz Huaman 1
Sistema de Información para la Atención de Pacientes UNS
7. Implantar un sistema de vigilancia y evaluación que nos garantice
que las actividades, normas y demás se están cumpliendo.
8. Elaborar un plan de acción a seguir para resolver los problemas
y/o conflictos que se puedan presentar.
9. Constituir un Comité de Garantía de Calidad para la implantación
y seguimiento del proyecto en el Departamento de Enfermería y
posteriormente en todos los departamentos de la institución.
1.2 DESCRIPCIÓN DE LA ORGANIZACIÓN
1.2.1 Reseña Histórica
El puesto de Salud “San Pedro” fue creada gracias al Dr. Alan García
Pérez, en su gobierno de 1980 – 1985, ya que fue el mismo el que
promulgó el Decreto Legislativo N° 351 y a la vez se promulgó el decreto
supremo 12-86 en la que se daba a conocer la creación de los puestos de
salud a nivel nacional.
Las autoridades de salud de la localidad de Chimbote, viendo la necesidad
urgente de la comunidad del Asentamiento Humano “San Pedro”
decidieron instalar un Puesto de Salud para el beneficio de las personas de
bajos recursos económicos.
Es así como se creó el Puesto de Salud “San Pedro” un 26 de enero de
1986, según Resolución Directoral N° 2430585, estando como Ministro de
Salud el Dr. David Tejada de Rivero, dependiendo este puesto de salud del
Hospital de Apoyo “La Caleta”, siendo el director Dr. Oswaldo Pérez
Edgar Alexander Cruz Huaman 2
Sistema de Información para la Atención de Pacientes UNS
Gamboa.
El Puesto de Salud empezó a funcionar el 25 de febrero de 1986 con un
médico, la Dra. Margarita Mendo Lagos y un personal auxiliar.
1.2.2 Base Legal
Constitución Política del Perú.
Directiva N° 005-82 INAP/DNR, Art. 29 D.S. N° 013-2002-SA.
Directiva Nº 01-95-RCH-CTAR/ORPP-OER Norma para la formulación,
aprobación y actualización de los MOF.
Ley 27657- Ley del MINSA, Directiva N° 007-MINSA/OGPE-V. 01
"Directiva para la formulación de documentos normativos de gestión
institucional" aprobado con R. M. N° 371-SA/DM.
R. M. N° 606-2002-SA/DM que aprueba el modelo de ROF de los
hospitales del sector a nivel nacional.
R. E. R. Nº 0289-2Q04- Región Ancash/PRE que aprueba el ROF del
Hospital “La Caleta” - Chimbote.
1.2.3 Ubicación Geográfica
El Puesto de Salud “San Pedro” se encuentra ubicado:
Departamento : Ancash
Provincia : Santa
Distrito : Chimbote
AA.HH. : San Pedro
Calle : Los Ángeles Mz 31
Edgar Alexander Cruz Huaman 3
Sistema de Información para la Atención de Pacientes UNS
1.2.4 Estructura Orgánica
El Puesto de Salud “San Pedro” tiene la siguiente estructura orgánica:
1.2.4.1 Órgano de dirección
Jefatura posta de salud “san pedro”
1.2.4.2 Órgano de línea final
Servicio de medicina
Servicio de obstetricia
1.2.4.3 Órgano de línea intermedia
Servicio de enfermería
- Área de tópico
Servicio de farmacia
1.2.4.4 Órgano de apoyo
Área de estadística
Área de contabilidad
Área logística
Área personal
Área servicios generales
Área saneamiento ambiental
Edgar Alexander Cruz Huaman 4
Sistema de Información para la Atención de Pacientes UNS
1.2.5 Organigrama
Figura 01. Organigrama del Puesto de Salud “San Pedro”
JEFATURA P S S P
AREA SERVICIOS
GENERALES
AREA ESTADISTICA
AREA ECONOMIA
AREA LOGISTICA
AREA PERSONAL
AREA SANEAMIENTO
AMBIENTAL
ENFERMERIA
TÓPICO
SERVICIO MEDICINA
OBSTETRICIA FARMACIA
DIRECCIÓN HOSPITAL “LA CALETA”
Edgar Alexander Cruz Huaman 5
Sistema de Información para la Atención de Pacientes UNS
1.2.6 Funciones
El Puesto de Salud “San Pedro” tiene las siguientes funciones:
1.2.6.1 Órgano de Dirección
Jefatura Posta de Salud “San Pedro”
Dirigir, organizar, asesorar, supervisar y evaluar el funcionamiento
de los servicios de salud.
1.2.6.2 Órgano de Línea Final
Servicio de Medicina
Coordinar con los servicios existentes, para brindar una atención
integral al paciente, familia y comunidad.
Servicio de Obstetricia
Brindar atención obstétrica (Dx. precoz del embarazo, selección
del gestante de alto y bajo riesgo, control prenatal, control
puerperio y R.N.)
1.2.6.3 Órgano de Línea Intermedia
Servicio De Enfermería
Organizar, dirigir, supervisar, evaluar el servicio de enfermería a
su cargo.
Área De Tópico
Brindar atención de salud elemental (cirugía menor, inyectables,
curaciones, control de funciones vitales)
Edgar Alexander Cruz Huaman 6
Sistema de Información para la Atención de Pacientes UNS
Servicio de Farmacia
Administrar la farmacia SIS MED promoviendo el uso racional
de medicamentos.
1.2.6.4 Órgano de Apoyo
Área de Estadística
Digitar información HIS-MIS, SIEN.
Área de Contabilidad
Organizar, coordinar el sistema de cobranza por servicios de salud
prestado a la comunidad.
Área Logística
Controlar y hacer efectivo el pago por adquisiciones de bienes
necesarios para el establecimiento.
Área Personal
Organizar el sistema de control y asistencia del personal y la
elaboración del informe correspondiente.
Área Servicios Generales
Velar por la integridad del edificio, mobiliario, equipos y
materiales del puesto de salud.
Área Saneamiento Ambiental
Realizar actividades de visita domiciliarias en los diferentes
programas: dengue, malaria, cólera y saneamiento ambiental.
Edgar Alexander Cruz Huaman 7
Sistema de Información para la Atención de Pacientes UNS
1.3 MISIÓN
Realizar actividades preventivas promociónales mediante información,
educación y comunicación, atención rápida y oportuna empleando fármacos y
tecnología en constante innovación, además de contar con personal calificado
para garantizar la salud y mejora de la calidad de vida de la población.
1.4 VISIÓN
Contribuir al acceso universal y equitativo de la población a los servicios de
salud, descentralizando y modernizando la gestión en el primer nivel de
atención.
Edgar Alexander Cruz Huaman 8
“Sistema de Información para la
atención de Pacientes”
Capítulo II.
PLAN DE PROYECTO
Sistema de Información para la Atención de Pacientes UNS
PLAN DE PROYECTO
2.1 PROBLEMA
2.1.1 Realidad Problemática
El Puesto de Salud “San Pedro”, es una institución Médica del Estado, que se
dedica a prevenir los diferentes tipos de enfermedades, así como a
promocionar la Salud; el Puesto de Salud en sus inicios tuvo como
jurisdicción al AA.HH “San Pedro” con una capacidad poblacional de 2,000
habitantes, con el transcurrir de los años, la población fue creciendo y fueron
surgiendo otros AA.HHs y Pueblos Jóvenes.
Hoy en día el Puesto de Salud “San Pedro” tiene bajo su Jurisdicción a los
AA.HHs “San Pedro”, “Esperanza Alta”, “Manuel Gonzáles Prada” así como
a los Pueblos Jóvenes “Nueva Generación”, “Villa los Jardines” y “OTROS”;
con un aproximado de 15,000 habitantes.
El puesto de Salud a diario atiende a un promedio de 50 pacientes, dejando
muchos sin atender, esto se debe al gran problema que tiene el personal
médico para encontrar las Historias Clínicas, desperdiciando un tiempo
considerable en dicha búsqueda, así como también el problema que existen
muchos números repetidos de Historias Clínicas y además de no contar con
reportes para la toma de decisiones.
Los AA.HHs y Pueblos Jóvenes, se encuentran divididos en uno o más
sectores y en cada sector se encuentran los paquetes de las familias, en cada
paquete se encuentran los integrantes de dicha familia (Historia Clínica de los
Pacientes).
El proceso de atención es el Siguiente:
Edgar Alexander Cruz Huaman 9
Sistema de Información para la Atención de Pacientes UNS
El paciente llega al área de admisión solicita un ticket para su atención en las
diferentes servicios de salud (medicina, obstetricia, crecimiento y desarrollo
del niño, laboratorio, farmacia y tópico), el encargado de Admisión, solicita
los datos del paciente, entre estos datos se piden el nombre completo del
paciente, el nombre de la familia, el pueblo y su dirección, para
posteriormente entregarle un ticket. Una vez obtenidos estos datos el
encargado u otro personal busca en el mapa la dirección del paciente para
saber en que sector se encuentra dicho paciente, una vez identificado el sector
el encargado pasa a Historial (lugar donde se encuentran todas las historias
clínicas de los pacientes, las cuales están agrupadas por sector del 1 al 20),
una vez obtenida la historia clínica se le entrega al paciente, este pasa a
Tópico para chequeo de sus funciones vitales y finalmente pasa a consultorio
(medicina, obstetricia, enfermería).
2.1.2 Análisis de la Realidad Problemática
Con el actual proceso que se lleva a cabo en el Puesto de Salud “San Pedro”, el
cual se realiza de forma tradicional para búsqueda de historias clínicas y así la
atención a los pacientes; nos damos cuenta de que el establecimiento de salud
esta perdiendo dinero debido a que no se pueden atender a más pacientes por la
demora en la búsqueda de historias clínicas.
También se puede observar el gran conflicto que se genera al encontrar números
repetidos de historias clínicas, el establecimiento de salud cobra al Seguro
Integral de Salud por la atención de los pacientes asegurados, pero este no le
paga cuando encuentra a pacientes con el mismo número de historia clínica.
Edgar Alexander Cruz Huaman 10
Sistema de Información para la Atención de Pacientes UNS
Se observa la impotencia que tiene la Dirección así como el personal de dicho
establecimiento de salud al no poder realizar decisiones en cuanto a la salud sin
una ayuda que les respalde.
2.1.3 Formulación del Problema
¿De qué manera la implementación de un Sistema de Información podrá
mejorar el control de historias clínicas, optimizar sus ingresos económicos y
ayudar a la toma de decisiones del Puesto de Salud San Pedro?
2.2 ANTECEDENTES
Dentro de las Instituciones médicas que han implementado un Sistema de
Información para el área de Admisión, podemos mencionar:
• Hospital La Caleta
Ubicación: La Caleta SN.
Descripción: Este Sistema fue hecho en el lenguaje de programación Fox Pro,
este sistema, solo permite registrar a sus pacientes. No brinda ninguna clase de
reportes.
• Policlínico Belén
Ubicación: Av. José Gálvez 1258 - El Progreso
Descripción: Este Sistema fue hecho en el lenguaje de programación Visual
Basic, al igual que el sistema anterior, solo permite registrar a pacientes.
Edgar Alexander Cruz Huaman 11
Sistema de Información para la Atención de Pacientes UNS
2.3 JUSTIFICACIÓN
• El Desarrollo de un Sistema de Información permitirá controlar el número de
Historias Clínicas de los pacientes del Puesto de Salud San Pedro – Chimbote.
• Permitirá reducir el tiempo muerto que se desperdicia en la búsqueda de historias
clínicas.
• Permitirá generar más ingresos económicos al atender a más pacientes debido a la
velocidad que brindará el Sistema.
• Permitirá tener respaldo en la toma de decisiones a causa de los reportes y
consultas que brinde el Sistema.
• Brindará satisfacción al Paciente al ser atendido más rápido.
2.4 HIPÓTESIS
El Desarrollo de un Sistema de Información mejorará el control de historias
clínicas, optimizará sus ingresos económicos y ayudará a la toma de decisiones
del Puesto de Salud San Pedro.
2.5 OBJETIVOS
2.5.1 Objetivo General
• Desarrollar un Sistema de Información en el Puesto de Salud San Pedro
para un mejor control y toma de decisiones adecuada así como optimizar
sus ingresos económicos.
Edgar Alexander Cruz Huaman 12
Sistema de Información para la Atención de Pacientes UNS
2.5.2 Objetivos Específicos
• Recopilar toda la información posible, para el desarrollo del Sistema de
Admisión.
• Analizar la situación actual así como los procesos que se desarrollan en el
Puesto de Salud.
• Seleccionar la Plataforma bajo la cual se trabajara así como el Lenguaje de
Programación.
• Implementar la Base de Datos Relacional, en el Gestor de Base de Datos
Adecuado al equipo con el que cuenta.
• Desarrollar la metodología XP(eXtreme Programing) para el desarrollo del
software.
• Diseñar y Codificar el Sistema de Admisión.
• Instalación de las Primeras Versiones del Sistema de Información.
• Comprobar el funcionamiento del Sistema de Información a través de
pruebas constantes y reales.
• Instalación Final del Sistema de Admisión.
• Capacitación del Manejo del Sistema al personal encargado de usarlo.
Edgar Alexander Cruz Huaman 13
“Sistema de Información para la
atención de Pacientes”
Capítulo III.
FUNDAMENTO TEÓRICO
Sistema de Información para la Atención de Pacientes UNS
FUNDAMENTO TEÓRICO
3.1 MARCO CONCEPTUAL
3.1.1 Aplicación.- Programa o conjunto de programas diseñados para realizar
funciones directamente para el usuario. Las aplicaciones necesitan de un
sistema operativo para poder funcionar. Existen varios tipos de aplicaciones:
procesadores de texto, base de datos, hojas de cálculo, correo electrónico, etc.
3.1.2 Contraseña.- Combinación secreta de caracteres que permiten al usuario
acceder a un determinado archivo, computadora, programa, pagina Web, o
servicio de línea. El objetivo de la contraseña es evitar el acceso a usuarios no
autorizados.
3.1.3 Formularios.- Conjunto de campos (espacios) para introducir datos en una
aplicación. Un formulario permite a los usuarios escribir información. La cual
va a ser almacenada y procesada para obtener resultados.
3.1.4 Servidor.- Computadora, dispositivo o programa que distribuye los recursos
dentro de una red proveyendo la información requerida por los usuarios.
Edgar Alexander Cruz Huaman 14
Sistema de Información para la Atención de Pacientes UNS
3.2 MARCO TEÓRICO
3.2.1 Sistemas de Información
3.2.1.1 Ciclo de Vida de los Sistemas de información
El concepto de ciclo de vida de un sistema información es medular en
las investigaciones de sistemas. Durante su desarrollo, cada sistema se
mueve a través de varias fases de un ciclo de vida, después del cual
sólo funciona por varios años con un mínimo mantenimiento. El
sistema se deteriora gradualmente hasta el punto en que cesa de
funcionar por completo y se comienza un nuevo ciclo de vida con el
desarrollo de un nuevo sistema. Los autores sobre sistema de
información ilustran el ciclo de vida con diferentes números de fases.
Los ciclos de vida de los sistemas varían en gran manera en términos
de longitud, pero por lo regular el ciclo de vida de un sistema de
información está en el rango 3 a 8 años.
3.2.1.2 Tipos y Usos de los Sistemas de Información
Los sistemas de información cumplen tres objetivos básicos:
Automatizar los procesos operativos.
Proporcionar información que sirva como apoyo al proceso de
toma de decisiones organizacionales.
Lograr ventajas competitivas a través de su implantación y uso.
Los sistemas de información que logran la automatización de procesos
operativos dentro de una organización, son llamados frecuentemente
Sistemas Transaccionales, ya que su función primordial consiste en
procesar transacciones tales como pagos, cobros, entradas, salidas y
Edgar Alexander Cruz Huaman 15
Sistema de Información para la Atención de Pacientes UNS
sus controles. Por otra parte, los sistemas de información que apoyan
el proceso de toma de decisiones son llamados Sistemas de Soporte a
la Toma de Decisiones.
El tercer tipo de sistemas, de acuerdo con su uso y objetivo, es el de
los Sistemas Estratégicos, los cuales se desarrollan en las
organizaciones con el fin de lograr ventajas competitivas, a través del
uso de la tecnología de información. Por último se considera un cuarto
tipo de Sistemas de Información denominado Sistemas Personales de
Información, enfocado a incrementar la productividad de los
usuarios.
3.2.1.3 Metodología para el Desarrollo de Sistemas
La metodología del desarrollo de sistemas es el camino que siguen los
analistas de sistemas para realizar su trabajo. Se emplea el término
genérico de analista de sistemas para describir a la persona que tiene la
responsabilidad principal de conjuntar los componentes estructurales,
dándoles forma y sustancia en conformidad con las fuerza del diseño
para construir sistemas de información exitosos.
3.2.2 Arquitectura
3.2.2.1 ¿Qué es una Arquitectura?
Una arquitectura es un conjunto de componentes funcionales que
aprovechando diferentes estándares, convenciones, reglas y procesos,
permite integrar una amplia gama, de productos y servicios
Edgar Alexander Cruz Huaman 16
Sistema de Información para la Atención de Pacientes UNS
informáticos, de manera que pueden ser utilizados, eficazmente dentro
de la organización.
3.2.2.2 Arquitectura Cliente/Servidor
Es la tecnología que proporciona al usuario final el acceso
transparente, a las aplicaciones, datos, servicios de cómputo, o
cualquier otro recurso del grupo de trabajo y/o, a través de la
organización, en múltiples plataformas. El modelo soporta un medio
ambiente distribuido en el cual los requerimientos de servicio hechos
por estaciones de trabajo inteligentes o “clientes” resultan en un
trabajo realizado por otros computadores llamados servidores.
Cliente/Servidor son entidades lógicas independientes que operan en
conjunto a través de una red para realizar una tarea. Los sistemas
cliente/servidor poseen las siguientes características distintivas.
Servicio: Cliente/Servidor es fundamentalmente una relación entre
procesos ejecutados entre apartados distintivos.
Recursos compartidos: Un servidor puede atender a muchos clientes
al mismo tiempo y regular su acceso a recursos compartidos.
Protocolos asimétricos entre cliente y servidor: Se establece una
relación de muchos a uno, son siempre los clientes los que inician el
dialogo al solicitar un servidor.
Edgar Alexander Cruz Huaman 17
Sistema de Información para la Atención de Pacientes UNS
Transparencia de ubicación: El servidor es un proceso que puede
residir en el mismo apartado que el cliente o un apartado distinto a lo
largo de la red.
Mezcla e igualdad: El software ideal del cliente/servidor es
independiente del hardware o de las plataformas de software del
Sistema Operativo.
Intercambios basados en mensajes: Clientes y servidores son
sistemas holgadamente acoplados que interactúan a través de un
mecanismo de transmisión de mensajes.
Integridad: El código del servidor y los datos del servidor se
concentran centralmente lo que resulta un mantenimiento de menor
costo y en la protección de la integridad de los datos compartidos.
Edgar Alexander Cruz Huaman 18
Sistema de Información para la Atención de Pacientes UNS
3.2.3 Metodología Empleada
3.2.3.1 Introducción a Extreme Programing (XP)
La Mayoría de los programadores habla solo de: lenguajes de
programación, técnicas de programación, entornos de desarrollo,
editores de recursos.
Pero se les pasa por alto cuestiones sumamente importantes como es la
INGENIRÍA DEL SOFTWARE, que es la manera en que debemos de
hacer nuestro software.
Actualmente todas aquellas empresas que desarrollan software han de
moverse en un entorno altamente competitivo habiéndose visto
obligados a reducir el “Time-to-Market” de sus aplicaciones
manteniéndose las mismas exigencias de calidad por parte de sus
clientes. Este panorama parece estar ceñido con los procesos o normas
de calidad implantados en las empresas que en muchas ocasiones, se
acaba retrasando la salida al mercado del producto final.
Por este motivo muchas empresas relegan fases relacionadas con la
calidad del software al plano meramente administrativo o incluso
lleguen a obviarlas, apremiadas por las presiones del cliente o del
mercado.
Frente a esta situación, surge: la metodología eXtreme Programing
(XP), la cual pretende que el desarrollo de un proyecto de software,
sea un desarrollo ágil, aunque disciplinado, y aporte soluciones
Edgar Alexander Cruz Huaman 19
Sistema de Información para la Atención de Pacientes UNS
sencillas. XP tiene un enfoque adaptativo, en que la planificación del
proyecto progresa a medida que surgen cambios.
3.2.3.2 Problemas del Desarrollo del Software
Son los siguientes:
Retraso en la Planificación: Llegada la fecha de entrega el
software no esta disponible.
Sistemas deteriorados: El software se a creado pero después de
unos años el coste de su mantenimiento es tan complicado que
definitivamente se abandona su producción,
Tasa de defectos: El software se pone en producción pero los
defectos son tantos que nadie lo usa.
Requisitos mal comprendidos: El software no resuelve los
requisitos planificados inicialmente.
Cambios de negocio: El problema que resolvía nuestro software
ha cambia y nuestro software no se ha adaptado.
Falsa riqueza: El software hace muchas cosas técnicamente
interesantes y divertidas, pero no resuelve el problema de nuestro
cliente ni hace que este gane más dinero.
Cambios de personal: Después de unos años de trabajo, los
programadores empiezan a odiar el proyecto y lo abandonan.
XP trata de evitar estos riesgos en el desarrollo del software
Edgar Alexander Cruz Huaman 20
Sistema de Información para la Atención de Pacientes UNS
3.2.3.3 ¿Qué es la Metodología XP?
eXtreme Programing, nace como una disciplina de desarrollo de
software hace aproximadamente 8 años.
Su autor es Kent Beck, programador que ha trabajado en muchas
empresas y que actualmente se encuentra como programador en una
prestigiosa empresa automovilística DaimlerChrysler.
XP, se basa en la SIMPLICIDAD, LA COMUNICACIÓN y EL
RECICLADO CONTINUO DE CÓDIGO, para algunos no es más que
aplicar una pura lógica.
XP, es una nueva disciplina para el desarrollo del Software, que ha
irrumpido recientemente en el maremágnum de métodos, técnicas y
metodologías existentes. Se trata de una metodología “ligera“ en
contraposición con las metodologías “pesadas” como Métrica.
3.2.3.4 Metodología XP
XP se basa en observar que es lo que hace que el desarrollo de un
programa sea rápido o lento.
XP es una Metodología impórtate por dos razones:
Primero y Principal, porque constituye un método de control para
las actividades de desarrollo de software. Que se han convertido en
métodos operativos estándares.
Segundo, es una de las pocas y nuevas metodologías ligeras
desarrolladas para reducir el coste del software
Edgar Alexander Cruz Huaman 21
Sistema de Información para la Atención de Pacientes UNS
3.2.3.5 Objetivos de XP
La Satisfacción del Cliente
Esta metodología trata de dar al Cliente el Software que necesita y
cuando lo necesita. Por lo que se debe de responder muy rápido a
las necesidades del cliente, incluso cuando los cambios sean al final
de la programación.
Potenciar al Máximo el Trabajo en Grupo
Tanto los Jefes de Proyecto, los Clientes y Desarrolladores, son
parte del Equipo y están involucrados en el Desarrollo del Software.
3.2.3.6 Principios de XP
Los principios claves a través de los cuales se fundamenta la
metodología XP son:
Acortar los Ciclos de Desarrollo.
Involucrar al Cliente desde el principio hasta el final de cada Ciclo.
Las técnicas de trabajo que proporciona XP consiguen minimizar el
impacto que los cambios suponen en un proyecto de desarrollo del
software.
Acortar los ciclos de desarrollo y reforzar la comunicación con el
cliente permiten:
Centrarse cada vez en un muy problema concreto y en el momento
justo.
Edgar Alexander Cruz Huaman 22
Sistema de Información para la Atención de Pacientes UNS
Solucionarlo de manera consensuada, inmediata, y no arrastrarlo a
lo largo del proyecto.
Comenzar cada nuevo ciclo de desarrollo sobre una versión
intermedia contrastada, verificada y aceptada por el cliente.
3.2.3.7 Las Cuatro Variables
XP define cuatro variables para proyectos de software: coste, tiempo,
calidad y ámbito.
Beck propone que solo tres puedan ser establecidas por las fuerzas
externas (Jefe de Proyecto y Cliente), mientras la cuarta les compete a
los programadores, la cual debe estar en función de las tres primeras.
3.2.3.8 El Coste del Cambio
Una de las suposiciones en la industria del software es que el coste de
los cambios en un programa crece exponencialmente con el tiempo.
Figura N° 02 Coste del Cambio Actual
Edgar Alexander Cruz Huaman 23
Sistema de Información para la Atención de Pacientes UNS
XP, propone que si el sistema que empleas hace que el coste del
software aumente con el tiempo, se debe de actuar de forma diferente
a como lo hacemos.
XP, pretende que esta curva sea la contraria a través de la combinación
de buenas prácticas de programación (simplicidad del código y test
continuos de evaluación) y tecnología adecuada.
Figura N° 03 Coste del Cambio Propuesto
La programación Orientada a Objetos (POO), es una tecnología clave
para el mantenimiento del software. Esto no quiere decir no se pueda
tener flexibilidad sin programar orientado a objetos.
Programar Orientado a Objetos reduce el Coste del Cambio.
3.2.3.9 Los Cuatro Valores
Una de las cosas que los programadores deben tener muy claro es que
en el ciclo de vida del desarrollo de un proyecto de software los
cambios van a aparecer, tal así que cambiaran los requisitos, las reglas
del negocio, el personal, la tecnología, etc. Por lo tanto el problema no
Edgar Alexander Cruz Huaman 24
Sistema de Información para la Atención de Pacientes UNS
es el cambio en si, si no la incapacidad de enfrentarnos a estos
cambios.
XP presenta estos cuatro valores:
Comunicación
La mayoría de los equipos de desarrollo de software han tenido
problemas por falta de comunicación, por no comentar un cambio
critico en el diseño, por no comentar lo que se piensa al Cliente y
por muchos otros factores.
XP ayuda mediante sus prácticas a fomentar la comunicaron.
Sencillez
Todo Desarrollador siempre debería de hacerse esta pregunta.
¿Qué es lo más simple que pueda funcionar?
La sencillez no es fácil, requiere de tiempo y esfuerzo.
XP, nos propone a hacer mas de lo que debemos: “Ya que estoy
tocando esta clase voy a añadirle un par de métodos mas para poder
visualizar los mensajes en colores”.
XP, nos dice que cuando algo no esta en los requisitos, puede que
mañana los necesite.
XP nos enseña a apostar, apuesta por hacer una cosa más sencilla
hoy y pagar mas mañana, si es necesario, que hacer cosas
complicadas hoy y no utilizarlas después.
Edgar Alexander Cruz Huaman 25
Sistema de Información para la Atención de Pacientes UNS
La sencillez y la comunicación se complementan, cuando mas
simple es tu sistema, menos tienes que comunicar de el.
Retroalimentación
XP nos propone decir la siguiente frase:
“No me preguntes a mi, pregúntale al Sistema”, la cual es la primera
clave de la retroalimentación, por medio de pruebas funcionales a
nuestro software este nos mantendrá informado del grado de
fiabilidad de nuestro Sistema.
Los Clientes y las Personas que escriben pruebas tienen una
retroalimentación real del Sistema.
La retroalimentación actúa junto con la sencillez y la comunicación,
cuanto mayor retroalimentación más fácil es la comunicación.
Cuanto mas simple un Sistema mas fácil de probar.
Valentía
XP nos dice que debemos de asumir retos, ser valientes ante los
problemas y afrontarlos.
3.2.3.10 Las Cuatro Actividades Básicas
¿Qué tareas debemos de llevar a cabo para desarrollar un buen
software?
Codificar
La codificación es la única actividad de la que no se puede
prescindir. Sin código fuente no hay programa.
Edgar Alexander Cruz Huaman 26
Sistema de Información para la Atención de Pacientes UNS
En una programación XP, el código expresa tu interpretación del
problema, así podemos utilizar el código para comunicar, para hacer
mías las ideas de los demás, y por tanto para aprender y mejorar.
Hacer Pruebas
XP nos dice que las características del software que no puedan ser
demostradas mediante pruebas simplemente no existen.
Las Pruebas permiten saber si lo que implementamos es realmente
lo que pensábamos que implementamos.
Las Pruebas nos indican que nuestro trabajo funciona.
Cuando no se puede pensar en ninguna prueba que pudiese originar
un fallo en nuestro sistema entonces se podrá decir que hemos
acabado por completo.
XP nos enseña a no hacer una prueba ver que funcione y salir
corriendo, nos enseña a que debemos de pensar todas las posibles
pruebas para nuestro código.
XP nos dice que las pruebas deben de ser sensatas y valientes.
Escuchar
Se debe de tener en cuenta que los Programadores no lo conocen
todo, y sobre todo muchas cosas que las personas del negocio
piensan que son interesantes.
XP nos enseña a escuchar a nuestros clientes cuales son los
problemas de su negocio, debemos de tener escucha activa
explicando lo que es fácil y difícil de obtener.
Edgar Alexander Cruz Huaman 27
Sistema de Información para la Atención de Pacientes UNS
Diseñar
El Diseño crea una estructura que organiza la lógica del Sistema.
XP, nos dice que los diseños deben de ser sencillos y que si alguna
parte del sistema es de desarrollo compleja debemos de dividirla en
varias partes.
Conclusión: Tenemos que codificar porque sin código no hay
programas, tenemos que hacer pruebas porque sin pruebas no sabes si
lo que hemos implementado es lo correcto, tenemos que escuchar,
porque si no escuchamos no sabemos que codificar ni probar y
tenemos que diseñar para poder codificar, probar y escuchar
indefinidamente.
3.2.3.11 Fases de La Metodología XP
Las normas básicas de XP giran en torno a las cuatro fases
principales del desarrollo: planificación, diseño, programación y
comprobación. En todas estas fases, XP insiste en que un
representante del cliente debe formar parte del equipo de desarrollo a
tiempo completo. Eso no significa que el representante del cliente
tenga que trabajar todo el tiempo con el equipo, pero en lo que XP es
inflexible es en que algún representante del cliente esté en todas las
reuniones del equipo (en las ocasiones en que no es físicamente
posible, tendrá que asignarse a alguien del equipo el cometido de
apoderado del cliente). En XP, a un equipo competente, motivado y
equilibrado se le denomina equipo completo. La integración y la
Edgar Alexander Cruz Huaman 28
Sistema de Información para la Atención de Pacientes UNS
interacción del equipo completo es clave en prácticamente todos los
aspectos de XP.
A) Planificación. La planificación de un proyecto XP se centra en
las historias de usuario, que son la versión de XP de lo que solían
llamarse requisitos. En el auténtico estilo XP, la verborrea se
intercambia por definiciones concisas y sin rodeos sobre lo que se
tiene que hacer. Las historias de usuario son cortas (de entre 25 y
50 palabras), dan un objetivo principal al proyecto, proporcionan
metas y sientan las bases para hacer estimaciones (con una
participación muy importante del representante del cliente).
Utilizando una estrategia del tipo "divide y vencerás", XP razona
que si una historia de usuario (especificación) no puede
describirse en 50 palabras, es demasiado larga y ha de convertirse
en más de una. Las historias de usuario también sirven para crear
pruebas de aceptación. Tras determinar qué hay que hacer, XP
obliga a que, antes de ponerse a escribir código, se determinen los
indicadores que nos servirán para determinar el éxito (¡definidos
por todo el equipo!) de esa historia de usuario. Descubrirá que
XP también utiliza el concepto de éxito cuantificable de otras
formas.
Las historias de usuario dividen el proyecto en iteraciones. A
partir de estas iteraciones se harán versiones bien acotadas y
frecuentes del proyecto. A diferencia del modelo en cascada, al
proceso se le darán muchas vueltas de manivela ya que cada vez
Edgar Alexander Cruz Huaman 29
Sistema de Información para la Atención de Pacientes UNS
que se crea una historia de usuario nueva, el proceso vuelve a
empezar.
Aunque no se menciona explícitamente, uno de los objetivos de
las historias de usuario y de las pruebas de aceptación es "no
llevarse sorpresas". El equipo de desarrollo y el representante del
cliente incorporado en el equipo están implicados tanto en la
planificación como en la determinación de los medios para saber
cuándo se ha entregado lo que se había previsto. Es muy sutil,
pero al facultar al cliente para que escriba tanto las historias de
usuario como las pruebas de aceptación, está eliminando, o por lo
menos minimizando, la posibilidad de que el cliente le cuele
como quien no quiere la cosa unas cuantas especificaciones
nuevas. (Si la mayoría de los programadores consiguieran tener
claro esto antes de escribir una sola línea de código, iríamos por
delante en el partido).
B. Diseño. Uno de los valores principales del diseño de XP es
"conservar la simplicidad". Un proyecto conducido por esta
metodología se lleva a cabo a base de iteraciones a lo largo de
todo el ciclo del proyecto. Por lo tanto, una forma de simplificar
las cosas es posponiendo la complejidad. En el modelo de
cascada, los diseñadores del proyecto estaban obligados a
planificar cualquier contingencia por adelantado (los ciclos
iterativos no formaban parte del modelo en cascada). En XP, se
sugiere que se diseñe e instale solamente lo que es necesario para
Edgar Alexander Cruz Huaman 30
Sistema de Información para la Atención de Pacientes UNS
hacer avanzar la jugada y posponer tanta complejidad como se
pueda a otra iteración. Insistir en la simplicidad no significa que
lo que haga no sea inherentemente complejo; es simplemente que
la intención de XP es seleccionar la forma más sencilla de hacer
el trabajo.
En la mayoría de los proyectos de programación, al equipo de
programación se le encargan desafíos con los que no están
totalmente familiarizados. Para evitar que desafíos interminables
desbaraten el proyecto, XP ofrece un pico para esas
circunstancias. Un pico sería parecido a lo que solemos llamar
"prueba de concepto" donde un grupo de programadores hace
frente a una parte especialmente problemática o desconocida del
proyecto, mientras los demás miembros del equipo siguen
trabajando en el resto del proyecto.
Otro concepto importante de XP es la "refactorización" del
código. La "refactorización" del código es el proceso de depurar
u optimizar el código sin cambiar su comportamiento. La
"refactorización" nos obliga a examinar el código después de que
funcione (realmente no necesita dos subrutinas, o leer el archivo
dos veces, ni esas variables intermedias, ¿a qué no?). XP nos
hace aplicar la "refactorización" obstinadamente dónde y siempre
que se pueda; forma parte de los procesos que hacen que las
cosas sean más sencillas.
Edgar Alexander Cruz Huaman 31
Sistema de Información para la Atención de Pacientes UNS
C) Programación. XP tiene varias rutinas de programación, algunas
de las cuales son muy predecibles. Por ejemplo, utilizar
estándares previamente acordados y posponer la optimización (es
decir, primero hacer el trabajo y luego hacerlo funcionar deprisa)
no son ideas demasiado revolucionarias. Pero XP incide de una
forma especialmente extrema en ello. XP obliga a programar por
parejas. Esta rutina no solo significa la revisión del código por un
compañero; frente a cada ordenador debe haber dos sillas,
ocupadas por un "piloto" y un "navegante". ¡Siempre! Con
frecuencia se cambian las funciones, así como de compañero.
Este es quizás uno de los aspectos más difíciles de cumplir de XP
para la mayoría de los departamentos de informática. Pero Beck
insiste en que dos programadores en un solo ordenador son tan
productivos como dos programadores en dos ordenadores... y que
los niveles de calidad y productividad son mucho mayores.
XP también obliga a escribir pruebas de unidad antes que el
código, lo que refleja la propensión de XP a crear indicadores en
el sistema. Aunque se utilizan pruebas en la fase de
comprobación, se escriben antes (o al mismo tiempo) que el
código que se va a comprobar. Las pruebas de unidad se escriben
como parte integral del proyecto y se ejecutan en cada ciclo
iterativo conforme se añaden más funciones. No se puede
continuar hasta que se pasan todas las pruebas. Las pruebas de
unidad sin duda ayudan a garantizar la calidad del código, pero
también ayudan a impedir que se cuelen sigilosamente otras
Edgar Alexander Cruz Huaman 32
Sistema de Información para la Atención de Pacientes UNS
funciones; al escribir la prueba antes que el código, éste se
escribe para superar la prueba y no para incluir otra virguería que
se le acaba de ocurrir.
XP es dogmático por lo que hace a la regla de que el equipo de
programación no haga horas extras. XP afirma que las horas
extras consumen la vida de la gente y que si para llevar adelante
un proyecto se necesitan horas extras, de todas formas se
entregará tarde, de modo que las horas extras no son la solución
del problema.
D) Comprobación. XP demanda pruebas de unidad para todo el
código y que éste supere todas esas pruebas. No hay sustitutos ni
atajos. En los lenguajes Java y .NET existen bibliotecas y
productos pensados para desarrollar pruebas de unidad. Para ILE
RPG y RPG/400 no debería ser demasiado difícil crear las suyas
propias. Naturalmente, el gran obstáculo para esta intrépida
estrategia de comprobación son los plazos de entrega que se
vislumbran en el horizonte. Sin embargo, no sea corto de miras y
piense en la comprobación solamente como un molesto trabajo
monótono. Durante la duración del proyecto, las comprobaciones
automáticas son los mejores indicadores para encontrar y
eliminar errores de programación. XP justifica unas
comprobaciones tan rigurosas aún con más vehemencia: "cuanto
más difícil es escribir una comprobación, más necesaria es,
puesto que mayores serán sus beneficios". Además, recuerde que
Edgar Alexander Cruz Huaman 33
Sistema de Información para la Atención de Pacientes UNS
esta comprobación no es uno de los últimos pasos del proyecto;
es un paso que se ha de dar constantemente a lo largo de todas las
versiones del proyecto.
3.2.3.12 Críticas:
XP tiene muchas criticas, por parte de aquellos programadores
apegados al código, piensan que ellos son los mejores conocedores
de las herramientas y lenguajes que utilizan y que si no lo entiendes
es por que no sabes lo suficiente.
Dicen que XP, solo puede funcionar con programadores muy
buenos, que puedan hacer un buen diseño, sencillo y fácilmente
extensible.
XP es mas una filosofía de trabajo que una metodología.
XP esta diseñado para grupos de pequeños programadores.
3.2.3.13 Comparación con Metodologías Tradicionales
XP ha causado gran revuelo en la comunidad de la Ingeniería del
Software.
Las metodologías tradicionales imponen un proceso disciplinario
para tratar de hacer el trabajo predecible, eficiente y planificado.
Estos están orientados a documentos y se vuelven demasiado
burocráticos e ineficientes.
Edgar Alexander Cruz Huaman 34
Sistema de Información para la Atención de Pacientes UNS
Figura N° 04 Comparación de Metodologías Tradicionales con XP
XP es más liviana y ágil y están orientadas más a las personas que a
los procesos.
XP supone:
Las personas son claves en los procesos de desarrollo.
Los programadores son profesionales no necesitan supervisión.
Los procesos se aceptan y se adecuan, no se imponen.
Desarrolladores y gerentes, comparten el liderazgo del proyecto.
El trabajo de los desarrolladores con las personas que conocen el
negocio es regular, no puntual.
3.2.3.14 Respaldo:
XP tiene aproximadamente 8 años de vida pero cuenta con un gran
respaldo por parte de grandes empresas como: Ford,
DaimlerChrysler, First Union National Bank -USA-, etc. Que lo
que buscan en definitiva es la reducción de coste.
Edgar Alexander Cruz Huaman 35
Sistema de Información para la Atención de Pacientes UNS
3.2.4 Herramientas Utilizadas
3.2.4.1 Power Builder
Introducción
Power Builder es un tipo de programación orientada a objetos. El
ambiente de desarrollo que trabaja el Power Builder es grafica.
Power Builder proporciona todas las herramientas que se necesita
para construir aplicaciones empresariales, como la entrada de datos,
contabilidad y los sistemas industriales.
Aplicaciones Multiusuario
Las aplicaciones de Power Builder pueden ser aplicaciones de
multiusuario o de Cliente/Servidor que se trabaja en forma grafica y
que pueden acceder a las bases de datos del servidor. Una
aplicación cliente/servidor tradicional es una colección de ventanas
que contienen mandos con que los usuarios puedan actuar
recíprocamente.
También se puede construir aplicaciones multiusuario con Power
Builder. Una aplicación multiusuario (distribuido) posee
normalmente una aplicación de cliente, que hará uso de los servicios
de una aplicación del servidor.
Las Aplicaciones de Internet
Se puede utilizar aplicaciones Web Based en Power Builder. Una
aplicación Web-Based puede crearse originalmente para Internet o
Edgar Alexander Cruz Huaman 36
Sistema de Información para la Atención de Pacientes UNS
puede realizarse en una aplicación de Power Builder existente que
va hacer extendida a la Internet.
El desarrollo de la Cross-Platform (Plataforma de Cruz)
Power Builder apoya el desarrollo en Cross-Platform y su
despliegue. Se puede desarrollar una paliación que usa Power
Builder bajo Windows y puede desplegar la misma aplicación sin
ningún cambio en UNIX. Se puede tener un equipo de Cross-
Platform de diseñadores, incluso, algunos que usan Windows y
algunos usando UNIX, desarrollando la misma aplicación al mismo
tiempo. Ellos pueden compartir objetos de Power Builder usados en
la aplicación libremente, porque los objetos son los mismos por las
plataformas de la informática diferentes, que son apoyados por el
Power Builder.
Las aplicaciones
En Power Builder se trabaja siempre en el contexto de una
aplicación. Cuando se crea una aplicación, se nombra el objeto de la
aplicación y se especifica una biblioteca de la aplicación para el
objeto y los otros objetos que creara.
Los Objetos
La aplicación es una colección de objetos de Power Builder.
Conforme se trabaja el la aplicación podrá ir creando nuevos
objetos y abrir los existentes para seguir trabajando.
Edgar Alexander Cruz Huaman 37
Sistema de Información para la Atención de Pacientes UNS
Painters
Usted construye los objetos en su aplicación que usa editores del
objeto llamados painters. Power Builder mantiene al painter cada
tipo de objeto.
Usted construye una ventana en el painter de la Ventana. Allí se
define las propiedades de la ventana, agrega los mandos como los
botones y luego revisa los mandos y codifica la ventana y sus
mandos para trabajar como su aplicación lo requiere
Las Bibliotecas
Los objetos que se crean se guardan en una o más bibliotecas
(Archivo PBL) asociado con la aplicación. Cuando se ejecuta la
aplicación, Power Builder recupera los objetos de la Biblioteca.
Power Script
PowerScript, es el idioma de Power Builder. Las escrituras
consisten en órdenes de PowerScript, funciones, y declaraciones
que realizan el proceso en la contestación a un evento.
PowerScript proporciona un surtido rico de funciones incorporadas
que pueden actuar en varios componentes de la aplicación.
Power Builder 10.0
La más nueva versión de la herramienta de desarrollo del favorito
4GL RAD de los markets. Permite a los desarrolladores construir
rápidamente y fácilmente los usos conducidos, los datos que los
Edgar Alexander Cruz Huaman 38
Sistema de Información para la Atención de Pacientes UNS
negocios necesitan para conseguir el trabajo hecho. La versión más
última se embala por completo de nuevas características para
construir los tipos de usos que los negocios necesiten hoy.
Ventajas:
• Costes reducidos - Simplifica grandemente el desarrollo y
el despliegue de los usos conducidos de los datos del nivel
de la empresa. Permite conseguir sus proyectos hechos
más rápidamente.
• Versátil – Permite construir la tela, el tablero del
escritorio y los usos donde quiera que se encuentren sus
usuarios. La herramienta proporciona datos conducidos, la
solución para el tablero del escritorio, tela del desarrollo
del uso, y distribución a usuarios.
• Alta productividad – Permite conseguir el trabajo hecho,
rápido. Construcción de los usos intensivos de los datos
para que funcione su negocio sobre solamente horas o
días, con la codificación mínima.
• Reducción al mínimo del riesgo - La tecnología ha sido
probada, por centenares de millares de desarrolladores,
ellos se asegura de que usted está trabajando con un
producto tan solidó como la roca.
• Desarrollo de las velocidades - El RAD 4GL IDE con
centenares de funciones y de características incorporadas
reduce la cantidad de codificación requerida.
Edgar Alexander Cruz Huaman 39
Sistema de Información para la Atención de Pacientes UNS
• Alza el funcionamiento de su empresa - Con la ayuda
para el NET y la integración con las plataformas de JÈE,
PowerBuilder es la única herramienta que consigue el
trabajo hecho más rápidamente que cualquier otro.
Características de las Ediciones de PowerBuilder
La tabla siguiente identifica las características principales
disponibles en la empresa, el profesional, y las ediciones de
escritorio de PowerBuilder 10
Edgar Alexander Cruz Huaman 40
Sistema de Información para la Atención de Pacientes UNS
Tabla N° 01 Características de PowerBuilder
PowerBuilderFeature Empresa Profesional Tablero del escritorio
Plug-in de PowerDesigner sí no no Kit nativo del desarrollo del software del interfaz de PowerBuilder
sí no no
Desarrollo de la blanco de JSP sí no no Desarrollo de la blanco de la tela sí no no Desarrollo de cliente de EJB sí no no Servicios de la tela para los clientes de PowerScript
sí no no
Servicios de la tela para los clientes de JSP
sí no no
Servicios de XML (modelo del objeto del documento de PowerBuilder)
sí no no
Tela DataWindow sí no no Desarrollo y despliegue componentes de EAServer
sí no no
Desarrollo componente y despliegue de COM/COM+
sí no no
Interfaz del SCC para el control de la fuente
sí sí no
Utilidad de OrcaScript sí sí sí Ayuda de ODBC Acceso
Completo Acceso
Completo Bases de datos De escritorio Solamente
Ayuda de XML en el DataWindow sí sí sí DataWindow ahorra como pdf sí sí sí Servidor adaptante dondequiera para el desarrollo
sí sí sí
Del Servidor Edición Runtime De escritorio Adaptante Dondequiera
sí sí sí
Ayuda almacenada del procedimiento sí sí no Ayuda de ADO.NET sí no no Ayuda de JDBC sí no no Ayuda OLE del DB sí no no Conductores nativos del DBMS sí no no InfoMaker sí no no Caja de herramientas De la Traducción
sí no no
Embalador Runtime sí no no Biblioteca de PBCryptography sí no no Monitor Del Recurso sí sí sí
Edgar Alexander Cruz Huaman 41
Sistema de Información para la Atención de Pacientes UNS
3.2.4.2 SQL Anywhere
Introducción
SQL Anywhere Studio es un completo paquete que provee manejo
de datos y sincronización empresarial para permitir el rápido
desarrollo y despliegue de soluciones e-Business distribuidas.
Optimizado para grupos de trabajo, laptops y dispositivos
"handheld", SQL Anywhere Studio extiende el alcance de la
información del e-Business corporativo hacia cualquier lugar donde
ocurran transacciones del negocio.
SyBase es el editor de SQL Anywhere Studio, un gestor de datos
que aporta una solución de sincronización adaptada a las pequeñas y
medianas empresas, de tal manera que uno pueda acceder desde
cualquier lugar y momento a toda la información corporativa que
necesite, con soporte para un gran número de estándares y
plataformas y, especialmente indicado en el caso de las bases de
datos móviles, embebidas y las aplicaciones basadas en Web; la
solución para usuarios móviles.
SQL Anywhere Studio es un exhaustivo paquete de herramientas de
gestión de datos para la empresa, con avanzadas opciones de
sincronización y administración adaptados al desarrollo de
soluciones en un entorno móvil y distribuido, como por ejemplo su
soporte XML, servicios Web, servidor de sincronización, tecnología
.NET, funcionalidades SQLX, servidor http y soporte SOAP, etc.
Optimizado para grandes bases de datos, ofrece un rendimiento
óptimo, con la posibilidad de realizar peticiones complejas con
Edgar Alexander Cruz Huaman 42
Sistema de Información para la Atención de Pacientes UNS
mayor seguridad. A nivel de usuabilidad, ofrece un entorno de
desarrollo sencillo, que facilita su manejo y cubre las necesidades
de toda clase de negocios. En definitiva, SQL Anywhere Studio es
una solución de difusión de información empresarial a dispositivos
móviles e inalámbricos de la más completa, flexible y robusta
actualmente disponible.
Diferencias entre el Servidor Personal y el Servidor de Red de
Adaptive Server Anywhere
Las bases de datos de Adaptive Server Anywhere (ASA) se
almacenan en archivos de disco. El servidor de bases de datos ASA
es la pieza de software que maneja la base de datos. Hay dos
versiones del servidor de base de datos: el Servidor de Bases de
Datos Personal (o Personal Database Server) y el Servidor de Bases
de Datos de Red (o Network Database Server). Ambas versiones
comparten funcionalidad común de base de datos pero ofrecen
distintas capacidades en sus servicios de red. También, ambas
versiones pueden participar en un sistema de replicación de ASA en
el cual las modificaciones a los datos son aplicadas a los datos
correspondientes en otras bases de datos. Cabe anotar que las
aplicaciones desarrolladas sobre el servidor personal trabajan sin
modificaciones sobre el servidor de red, haciendo que el servidor
personal sea ideal para ambientes de desarrollo.
Edgar Alexander Cruz Huaman 43
Sistema de Información para la Atención de Pacientes UNS
El motor de procesamiento de requerimientos es idéntico en los dos
servidores: cada uno soporta exactamente el mismo SQL y
exactamente las mismas características de base de datos.
El Servidor de Bases de Datos Personal (Personal Database
Server)
El servidor personal se provee para uso monousuario, en una
misma máquina. El servidor personal opera como una tarea del
sistema operativo en un computador de usuario y soporta hasta
10 conexiones concurrentes y puede recibir requerimientos para
recuperación, actualización, y otras operaciones desde
aplicaciones cliente en la misma máquina, como se muestra en
el siguiente diagrama:
Figura N° 05 Servidor de Base de Datos Personal
El servidor personal es invocado usando los siguientes
Ejecutables:
Plataformas Windows (95/98/XP/Me/NT/2000): dbeng8.exe
Edgar Alexander Cruz Huaman 44
Sistema de Información para la Atención de Pacientes UNS
Plataformas basadas en UNIX: dbeng8
El Servidor de Bases de Datos de Red (Network Dabase Server)
El servidor de red está orientado a uso multiusuario y soporta
comunicaciones cliente-servidor a través de una red. Recibe
requerimientos para recuperación, actualización y otras
operaciones a través de una red desde aplicaciones cliente, como
se muestra en el siguiente diagrama:
Figura N° 06 Servidor de Base de Datos de Red
Las aplicaciones cliente pueden residir en máquinas distintas a
la máquina en la que reside el servidor de red. El número de
clientes que se pueden conectar a un servidor de red está
determinado por las licencias de ASA, así como de la capacidad
disponible de su red y de su hardware servidor. Una vez un
cliente está conectado al servidor de bases de datos, se le
permite un número ilimitado de conexiones a la base de datos.
Edgar Alexander Cruz Huaman 45
Sistema de Información para la Atención de Pacientes UNS
El servidor de red se invoca usando los siguientes ejecutables:
Plataformas Windows (95/98/XP/Me/NT/2000): dbsrv8.exe
Plataformas basadas en UNIX: dbsrv8
Novell NetWare: dbsrv8.nlm
Las bases de datos personal y de red tienen el mismo motor de
procesamiento de requerimientos. Las diferencias entre los dos
servidores son en la parte de red, licenciamiento y opciones de
configuración, y pueden ser resumidas así:
Edgar Alexander Cruz Huaman 46
Sistema de Información para la Atención de Pacientes UNS
Tabla N° 02 Diferencias entre las Bases de Datos Personal y de Red
Personal Server Network Server
Soporte al protocolo de red No Si
Número máximo de conexiones 10 Determinado por el
licenciamiento
Número máximo de CPUs 2 Ilimitado
Opción –ga: descargar base de datos después de la última desconexión
La base de datos se descarga y el servidor se baja después de la última desconexión
La base de datos se descarga después de la última desconexión
Opción -gd: permiso requerido para arrancar la base de datos
Definida en ALL por defecto
Definida en DBA por defecto
Opción -gk: permiso requerido para parar la base de datos usando el utilitario DBSTOP
Definida en ALL por defecto
Definida en DBA por defecto
Opción -gl: permiso requerido para cargar datos usando LOAD TABLE o para bajar datos usando UNLOAD TABLE o UNLOAD
Definida en ALL por defecto para plataformas diferentes a UNIX
Definida en DBA para plataformas UNIX
Definida en DBA por defecto
Opción -gn: Número de requerimientos que la base de datos puede manejar a la vez
10 por defecto 20 por defecto
Edgar Alexander Cruz Huaman 47
Sistema de Información para la Atención de Pacientes UNS
Consideraciones para Ejecutar Backups y Validaciones en
Adaptive Server Anywhere
Dentro de las nuevas posibilidades administrativas que Adaptive
Server Anywhere (ASA) incluye desde la versión 7.0, las utilidades
DbBackup y DbValid pueden ser ejecutadas mientras ASA está
corriendo.
Utilidad de Validación - DbValid
Con la utilidad de validación desde línea de comando DbValid, se
pueden validar los índices y las llaves sobre algunas o todas las
tablas de una base de datos. Esta utilidad verifica la tabla
completa, y confirma que cada una de las filas se encuentra en los
índices asociados. Esta utilidad es equivalente a la instrucción
vlidate table sobre cada tabla.
Sintaxis:
dbvalid [ opciones ] [ nombre-objeto,... ]
Edgar Alexander Cruz Huaman 48
Sistema de Información para la Atención de Pacientes UNS
Tabla N° 03 Validación de la Base de Datos
nombre-objeto :
El nombre de una tabla ó el nombre de un índice (si la opción -i es usada) que desea ser validado
opciones : -c "keyword=value; ..." : Parámetros de conexión a la base de datos
-o nombre-archivo: Archivo de log de la ejecución de la validación
-f : Valida tablas haciendo un chequeo total (full check)
-fd :Valida la data de las tablas (data check)
-fi : Valida los índices de las tablas (index check)
-I : Cada nombre-objeto es un índice
-q : Modo silencioso — no imprime mensajes
-t : Cada nombre-objecto es una tabla
Ejemplo:
La siguiente instrucción valida la base de datos de ejemplo
asademo.db, conectándose a ASA con el usuario DBA y
contraseña SQL:
D:\> dbvalid -c "uid=DBA;pwd=SQL;dbf=
c:\asa\asademo.db"
Utilidad de Backup - DbBackup
DbBackup permite generar copias de respaldo para una base
de datos en ASA. Se manejan copias de respaldo totales ó
copias del log de transacciones (backup incremental).
Antes de tomar un backup con DbBackup es importante saber
que cuando una base de datos ASA se cierra (shutdown), los
Edgar Alexander Cruz Huaman 49
Sistema de Información para la Atención de Pacientes UNS
archivos de la misma mantienen un copia actual y completa de
todos los datos existentes en la base de datos. Cuando una base
de datos está en ejecución, los archivos generalmente no
reflejan el estado actual inmediato de los movimientos que
sobre ella se efectúan. El único momento en el que se puede
garantizar que la base en ejecución está completa y
actualizada es cuando un checkpoint toma lugar en la base de
datos. Al momento de un checkpoint, la información contenida
en el caché de la base de datos se escribe a disco. El servidor
ASA efectúa un checkpoint en alguna de las siguientes
condiciones:
• Como parte de la operación de shutdown de la base de datos.
• Cuando la cantidad de tiempo transcurrido desde el último
checkpoint excede el valor configurado en la variable
CHECKPOINT_TIME
• Cuando desde una conexión se invoca explícitamente la
instrucción checkpoint.
Sintáxis:
dbbackup [ opciones ] [ directorio ] archivo
Edgar Alexander Cruz Huaman 50
Sistema de Información para la Atención de Pacientes UNS
Tabla N° 04 Backup de la Base de Datos
opciones : -c "keyword=value; ..." : Parámetros de conexión a la base.
-d : Efectúa backup únicamente del archivo main de la base de datos.
-l nombre_archivo : (Live Backup) Backup en caliente del log de transacciones.
-n : Cambia el nombre al backup del log de transacciones.
-o nombre_archivo: Escribe un archivo de salida con el log de la operación.
-q : Modo Silencioso: no imprime mensajes.
-r : Renombra e inicializar un nuevo archivo de log de transacciones para la base de datos a la que se le efectúa el backup.
-t : Hace backup únicamente del log de transacciones.
-w : Hace backup únicamente del write file.
-x : Borra y reinicializa el log de transacciones.
-xo : Borra y reinicializa el log de transacciones sin hacer backup.
-y : Reemplaza archivos sin efectuar confirmación.
Edgar Alexander Cruz Huaman 51
Sistema de Información para la Atención de Pacientes UNS
Si no se utilizan ninguna de las opciones -d, -t, -w, todos los
archivos de bases de datos son respaldados.
La opción Live backup (-l) se desarrolló con el fin de habilitar
un ambiente secundario que puede ser puesto en marcha
rápidamente en el evento de una caída o falla del servidor. Un
live backup se mantiene en ejecución mientras el servidor de
base de datos también lo haga. Cuando el servidor tiene un
problema y cae, el live backup acaba, dejando un backup del
log de transacciones intacto para poder ser usado en un
ambiente secundario en corto tiempo.
Ejemplo:
Un archivo por lotes que puede implementar para efectuar una
copia de respaldo. Dicho ejemplo valida y hace el backup de la
base, si ocurre un error el proceso se detiene.
@echo off
cls
rem if %1. == . goto usage
echo Validando Base de Datos
dbvalid -f -q -c "eng=mydb;dbn=mydb_db;uid=dba;pwd=sql"
if errorlevel 0 goto backupdb
echo ===============================
echo Error Code - %errorlevel%
Edgar Alexander Cruz Huaman 52
Sistema de Información para la Atención de Pacientes UNS
echo Error en la validación - no se completó el backup
echo ===============================
goto stayopen
:backupdb
echo Creando Backup
dbbackup -x -y -q -c
"eng=mydb;dbn=mydb_db;uid=dba;pwd=sql"
"d:\backupfiles\mydb”
if errorlevel 0 goto done
echo ===============================
echo Error Code - %errorlevel%
echo Error in DB backup - no backup completed
echo ===============================
goto stayopen :done
exit
:usage
echo -
echo usage:
echo backit {backup directory}
echo -
:stayopen
Edgar Alexander Cruz Huaman 53
Sistema de Información para la Atención de Pacientes UNS
Migración de las Aplicaciones de Microsoft Access a Sql
Anywhere sin sacrificar la interfaz de usuario de la Aplicación
Muchas veces existen problemas con las constantes reparaciones a
los datos y dificultades al conectar múltiples usuarios a Microsoft
Access, usted puede pasarse a SQL Anywhere Studio para obtener
el rendimiento y funcionalidad que le hace falta, sin tener que
rescribir sus aplicaciones Access.
A medida que su grupo de trabajo crece, usted necesita un
repositorio de datos que pueda acomodar los crecientes
requerimientos de confiabilidad y accesibilidad de los datos. SQL
Anywhere Studio provee las más poderosas características
disponibles en un DBMS escalable, de bajo consumo de recursos, y
verdaderamente cliente/servidor. Además, ya que nuestra base de
datos, líder en la industria, corre tras las escenas de su aplicación,
sus usuarios podrán mantener la interfaz a la cual están
acostumbrados.
El Utilitario de Migración de SQL Anywhere para MS Access (SQL
Anywhere for MS Access Utility) es un programa que migra
bases de datos con tecnología Microsoft JET a bases de datos
Adaptive Server Anywhere, incluido en SQL Anywhere Studio.
Edgar Alexander Cruz Huaman 54
Sistema de Información para la Atención de Pacientes UNS
Levantamiento de Múltiples bases de datos con Adaptive Server
Anywhere
Arrancando el Servidor de Bases de Datos
Cuando arranca el servidor de bases de datos, se debe incluir todos
los nombres de los archivos de bases de datos en la línea de
comandos. También debe especificar explícitamente el nombre de
motor de bases de datos con la opción –n.
La sintaxis general de la línea de comandos del servidor es la
siguiente:
ejecutable [ opciones-de-servidor ] [ archivo-base-de-datos [
opciones-base-de-datos ], ... ]
Ejemplos:
1. Usando el servidor personal:
DBENG8.EXE -n mi_servidor c:\path\data1.db -n db1
c:\path\data2.db -n db2
2. Usando el servidor de red:
DBSRV8.EXE -n mi_servidor c:\path\data1.db -n db1
c:\path\data2.db -n db2
Estos comandos arrancan el servidor de bases de datos con el
nombre mi_servidor. A las bases de datos c:\path\data1.db y
Edgar Alexander Cruz Huaman 55
Sistema de Información para la Atención de Pacientes UNS
c:\path\data2.db se les asignan los alias db1 y db2,
respectivamente.
Arrancando el Servidor de Bases de Datos con un Archivo de
Parámetros
También se puede crear un archivo que contenga los parámetros que
desea pasar al ejecutable del servidor de bases de datos. Por
ejemplo, usted podría crear el archivo mi_servidor.cfg con las
siguientes líneas:
c:\path\data1.db -n db1
c:\path\data2.db -n db2
Luego se podría arrancar el servidor de bases de datos usando la
siguiente sintaxis:
DBSRV8.EXE -n mi_servidor @mi_servidor.cfg
Usar un archivo de parámetros puede ser particularmente útil al
cargar el NLM de Adaptive Server Anywhere bajo sistema
operativo Novell Netware.
Edgar Alexander Cruz Huaman 56
“Sistema de Información para la
atención de Pacientes”
Capitulo IV.
METODOLOGÍA
Sistema de Información para la Atención de Pacientes UNS
METODOLOGÍA
4.1 PROCEDIMIENTO
4.1.1 Fases de la Metodología:
4.1.1.1 Planificación:
• Historias de Usuario
- Controlar el Número de Historias Clínicas, evitando que halla
pacientes con el mismo número de historia.
- Reducir el tiempo de Búsqueda de Historias Clínicas, pues de
esta manera se reduciría los tiempos muertos y podría atender a
más pacientes.
- Apoyar a la toma de decisiones, el sistema debe de brindar
reportes estadísticos para poder tomar decisiones correctas así
como poder realizar consultas que puedan surgir.
- Facilidad de uso del Sistema, de tal manera que sean pocos los
pasos que deba realizar el cliente para poder manejar el sistema,
así como también la estética de la aplicación debe ser la más
adecuada.
- Uso de accesorios, que el sistema debe de brindar para mayor
comodidad.
- Registrar, Eliminar, Actualizar, Buscar, la data.
- Capacitación sobre el uso del Sistema a los usuarios.
Edgar Alexander Cruz Huaman 57
Sistema de Información para la Atención de Pacientes UNS
• Release Planning
Tabla N° 05 Release Planing Prioridad Historia de Usuario Versión Tiempo
(Fecha) 1 Diseño de la Base de
Datos, Pantallas para ingreso y salida de la data. (*)
1 al 6 13/07/05 al
30/07/05
2 Registrar, Eliminar, Actualizar, Buscar, la data.
6 al14 13/07/05 al
31/08/05 3 Controlar el Número de
Historias Clínicas. 6 al 14 01/08/05
al 31/08/05
4 Reducir el tiempo de Búsqueda de Historias Clínicas.
6 al 14 01/08/05 al
31/08/05 5 Apoyar a la toma de
decisiones. 15 al 17 01/09/05
al 10/09/05
6 Uso de accesorios, así como la facilidad de uso del Sistema
18 12/09/05 al
14/09/05 7 Capacitación sobre el
uso del Sistema a los usuarios.
1al 20 16/07/05 al
21/09/05
Otro de los parámetros que se toma en cuenta en el “Release
Planing”, es el número de desarrolladores que se encargaran de
realizar cada historia de usuario; en nuestro caso debido a que el
sistema es pequeño lo realizan el desarrollador conjuntamente con
el representante de la Institución Médica.
(*) No forma parte de las historias de usuario.
Edgar Alexander Cruz Huaman 58
Sistema de Información para la Atención de Pacientes UNS
4.1.1.2 Diseño:
Para el Diseño, se pidió las opiniones de los usuarios para así poder
hacer un diseño lo mas sencillo posible, de tal manera que los usuarios
se familiaricen en menos de 5 minutos con el sistema.
También se recurrió a tomar los diseños de algunos proyectos hechos,
los cuales se encuentran en el Internet.
Juntando: las sugerencias del los usuarios, diseños de proyectos
hechos y la experiencia y aportación del desarrollador se realizaron las
pantallas con una gran originalidad, de tal manera que los usuarios
pudieran acceder a la información que necesitaban desde cualquier
punto de la Aplicación.
4.1.1.3 Programación:
Se hace referencia a la programación en pareja, la cual estuvo
conformada por el Desarrollador y el Representante del
Establecimiento, pues mientras el desarrollador implementaba las
historias de usuario (requerimientos) el Representante iba haciendo las
sugerencias respectivas así como aportaciones para mejorar el sistema.
Se realizaron Pruebas de Unidad antes que el mismo código, para
garantizar la calidad del coligó.
4.1.1.4 Comprobación:
En esta parte se verificó que nuestro código superara todas las pruebas
de unidad, y de esta manera poder los errores de programación. Esta
Edgar Alexander Cruz Huaman 59
Sistema de Información para la Atención de Pacientes UNS
comprobación se hizo constantemente a lo largo de todas las versiones
del proyecto.
4.2 TIPO DE INVESTIGACIÓN
Aplicada y Experimental.
4.3 MÉTODO DE INVESTIGACIÓN
Inductivo – Deductivo.
El método en que me basare para llegar a la veracidad de la hipótesis será a través
de encuestas, entrevista personal y observación (Método Inductivo - Deductivo);
dichas encuestas estarán conformadas por preguntas de cómo se realiza el proceso
de atención a los pacientes en el Puesto de Salud San Pedro. Esta encuesta estará
aplicada al área de admisión así como a las áreas de atención médica (medicina,
obstetricia y enfermería) antes de la aplicación del Sistema de Admisión.
Posteriormente se realizara cuestionarios con preguntas acerca del desenvolvimiento
del software. Estos cuestionarios serán aplicados a las diferentes áreas del Puesto de
Salud después de la instalación del Sistema.
Estos cuestionarios servirán para medir la automatización que se logrará con el uso
del Sistema de Admisión, como también servirán para ver si la interfaz del sistema
es amigable.
Se debe de tener en cuenta que como se esta trabajando bajo la Metodología XP,
estas entrevistas serán constantemente, pues el personal del puesto de salud forma
parte del equipo de desarrollo.
Edgar Alexander Cruz Huaman 60
Sistema de Información para la Atención de Pacientes UNS
Una vez que se hayan aplicado las encuestas y los cuestionarios, se podrá evaluar
los resultados obtenidos antes y después de la aplicación del Sistema de Admisión y
verificar si la hipótesis formulada se cumple.
4.4 DISEÑO DE INVESTIGACIÓN
4.4.1 Variables
Dada la naturaleza del problema la variable dependiente tendrá que ser
caracterizada, para lo cual se realiza la operacionalización de la hipótesis de
investigación, tal como se muestra a continuación.
4.1.1.1 Variable Independiente (X):
X = Desarrollo de un Sistema de Información.
4.1.1.2Variables Dependientes (Y, W, Z):
• Y = Control de Historias Clínicas.
Indicadores:
y1 = Reducción de los tiempos muertos en la búsqueda de historias
clínicas.
y2 = Evitar la redundancia del número de Historias Clínicas.
y3 = Reducción del espacio utilizado para almacenar historias
clínicas impresas. [1]
• W = Optimización de Ingresos Económicos.
Indicadores:
w1 = Mas atenciones.
Edgar Alexander Cruz Huaman 61
Sistema de Información para la Atención de Pacientes UNS
w2 = Reducción de gastos en la compra de papel para la impresión.
[1]
• Z = Ayuda a la Toma de Decisiones.
Indicadores:
z1 = Confiabilidad en las decisiones a tomar.
[1] Estos indicadores se demostrar en un futuro pues el establecimiento a un no
cuenta con más PCs
4.5 DISEÑO EXPERIMENTAL
De la Hipótesis se establece que para mejorar el control de historias clínicas,
optimizar los ingresos económicos y ayudar a la toma de decisiones en el Puesto de
Salud San Pedro, se debe de demostrar que:
• Se reducirá el tiempo muerto que se origina el la búsqueda de historias
clínicas.
• Evitara la duplicación del número de historias clínicas.
• Se atenderá a más pacientes debido al ahorro de tiempo.
Donde:
X : Variable Independiente.
Y, W, Z : Variables Dependientes.
Y (y1, y2) X W (w1) Z (z1)
Edgar Alexander Cruz Huaman 62
Sistema de Información para la Atención de Pacientes UNS
y1, y2 : Indicadores de Y.
w1 : Indicador de W.
z1 : Indicador de Z.
Dada la naturaleza de la hipótesis, el diseño a aplicar al proyecto es: Series
Cronológicas de un solo Grupo.
Este grupo estará conformado por usuarios de las áreas de: Jefatura, Atención
Medica, Admisión.
A estas áreas se le aplicaran varias Pre-Pruebas, después se le aplica el tratamiento
experimental y finalmente varias Post-Pruebas. El diseño podría diagramarse de la
siguiente manera.
D
4.6 COBERTU
4.6.1 Poblac
Puesto
Edgar Alexander
G O1 O2 O3 X O4 O5 O6
onde:
G : Grupos
O1, O2, O3 : Pre-Pruebas.
X : Variable Independiente.
O4, O5, O6 : Post-Pruebas.
RA DE ESTUDIO
ión:
de Salud San Pedro - Chimbote
Cruz Huaman 63
Sistema de Información para la Atención de Pacientes UNS
4.6.2 Muestra:
Para medir los indicadores de las variables dependientes se utiliza un
cuestionario (Ver Anexo B), aplicándolo a la muestra selectiva de los grupos
seleccionados (Personal de Admisión, Tópico y Jefatura).
4.7 TÉCNICAS E INSTRUMENTOS
Tabla Nº 06 TÉCNICAS INSTRUMENTOS
• Observacion. • Encuestas. • Cuestionarios. • Investigación Bibliográfica.
• Fichas de Observacion. • Fichas de Encuestas. • Fichas de Cuestionarios. • Fichas Bibliográficas.
Edgar Alexander Cruz Huaman 64
“Sistema de Información para la
atención de Pacientes”
Capitulo V.
DESARROLLO DEL SISTEMA DE ADMISIÓN
Sistema de Información para la Atención de Pacientes UNS
DESARROLLO DEL SISTEMA DE ADMISION
5.1 VERSIONES DEL SOFTWARE
El equipo de desarrollo, en las reuniones que se tuvo, se plateó y se aprobó que la
entrega de las versiones del Sistema se haría 2 veces a la semana (días de entrega
miércoles y sábado), guardando un margen de un día por cualquier inconveniente
que surgiera.
La fecha de inicio para el desarrollo del Sistema de Admisión fue: 13/07/2005,
entregándose la primera versión el 16/07/2005.
En el proceso de desarrollo de las versiones la base de datos se modifico 2 veces.
• Versiones del 1 al 5 (del 13/07/05 al 30/07/05)
Elaboración de la Base de Datos; diseño de las pantallas para registrar la data así
como para su recuperación; colores, fondos, imágenes, logos con los que debería
contar; el tamaño y tipo de letra que debería tener.
• Versiones del 6 al 14 (01/08/05 al 31/08/05)
Proporciona solo el ingreso de la data (registro de los pueblos y asentamientos
humanos con sus respectivos sectores, así como de las familias y sus
integrantes), ofreciendo también las modificaciones (actualización) y
eliminación de la data correspondiente.
• Versiones del 15 al 17 (del 01/09/05 al 10/09/05)
Nos brinda la posibilidad de hacer consultas así como proporciona los reportes
que se requerían para una buena toma de decisiones.
Edgar Alexander Cruz Huaman 65
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 66
• Versión 18 (del 12/09/05 al 14/09/05)
Aquí se agregó los accesorios, así como el mejoramiento de las pantallas, para
que el usuario tenga mayor facilidad al ingresar la data así como al hacer las
consultas y brindar los reportes requeridos.
• Versiones del 19 al 20 (del 15/09/05 al 21/09/05)
En estas últimas versiones se trato de mejorar el código.
En cada versión se aplicaron pruebas correspondientes, estas pruebas fueron hechas
con datos reales y en presencia de todos los miembros del equipo de desarrollo.
5.2 CAPACITACIÓN DE USUARIOS:
El equipo de desarrollo el cual estaba formado por:
• Desarrollador (Edgar. Alexander Cruz Huaman)
• Jefe de admisión (Cléver Pinedo Orue)
• Apoyo (Jefe del Puesto de Salud, Encargada de Tópico)
Estuvo en constante interacción con el Sistema, tal es así que en cada versión se le capacitaba.
Sistema de Información para la Atención de Pacientes UNS
5.3 DISEÑO DE LA BASE DE DATOS
5.3.1) Diagrama Entidad Relación (ER) actual
NO ASEGURADOASEGURADO
PACIENTE cod_paciente cod_familia nombres_paciente apellido_paterno apellido_materno sexo fecha_nacimiento tipo parentesco fecha_inscrip_paciestado
Figura N° 07 Diagrama ER Actual
FAMILIA
cod_familia cod_sector nombre_familia fecha_inscripcion jiron_calle mz lte
SECTOR
c cod_pu
od_sectoreblo
nombre_sector
PUEBLO
c nombre_p
od_sectorueblo
( 1 , n )
PERTENECE
VIVE ( 1 , n )
PERTENECE ( 1 , n )
( 1 , 1 )
( 1 , 1 )
( 1 , 1 )
Edgar Alexander Cruz Huaman 67
Sistema de Información para la Atención de Pacientes UNS
5.3.2) Diagrama Entidad Relación (ER) a usar
NO ASEGURADOASEGURADO
PACIENTE cod_paciente cod_familia nombres_paciente apellido_paterno apellido_materno sexo fecha_nacimiento tipo parentesco fecha_inscrip_paciestado
FAMILIA
cod_familia cod_sector nombre_familia fecha_inscripcion jiron_calle mz lte
PUEBLO
nombre_
cod_sector pueblo
PERTENECE
VIVE
PERTENECE
( 1 , n )
( 1 , 1 )
( 1 , 1 )
( 1 , n )
( 1 , 1 )
( 1 , n )
ATENCION
cod_atencion cod_paciente fecha_atencion pa fr peso temp talla diagnostico fecha_cita observaciones
VACUNA
cod_vacuna nombre_vacuna cod_paciente
cod_vacuna fecha_vacuna num_dosis observacion num_dias_llega
RECIBE
( 1 , n ) ( 1 , n )
( 1 , n )
APLICA SECTOR
c cod_pu
od_sectoreblo
nombre_sector
Figura N° 08 Diagrama ER a Usar
( 1 , 1 )
Edgar Alexander Cruz Huaman 68
Sistema de Información para la Atención de Pacientes UNS
6.3.3) Modelo Relacional Actual
Figura Nº 09 Modelo Relacional Actual
Edgar Alexander Cruz Huaman 69
Sistema de Información para la Atención de Pacientes UNS
5.3.4) Modelo Relacional a Usar
Figura N° 10 Modelo Relacional a Usar
Edgar Alexander Cruz Huaman 70
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 71
Figura N° 11 Prototipo del Sistema
5.4.1 Prototipo del Sistema
5.4 DISEÑO
Sistema de Información para la Atención de Pacientes UNS
5.4.2 Sistema Principal
Figura N° 12 Mensaje de Bienvenida
Figura N° 13 Autentificación de Usuario
Edgar Alexander Cruz Huaman 72
Sistema de Información para la Atención de Pacientes UNS
Figura N° 14 Menú Principal
Figura N° 15 Cambio de Usuario
Edgar Alexander Cruz Huaman 73
Sistema de Información para la Atención de Pacientes UNS
Figura N° 16 Datos de Usuario
Figura N° Cambio de Contraseña de Usuario
Figura N° 17 Registrar Usuario
Edgar Alexander Cruz Huaman 74
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 75
Figura N° 19 Copias de Seguridad
Figura N° 18 Cambiar Contraseña
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 76
Figura N° 20 Manual de Usuario General
Sistema de Información para la Atención de Pacientes UNS
Figura N° 21 Ayuda y Soporte Técnico
Figura N° Acerca del Desarrollador
Figura N° 22 Accesorios
Edgar Alexander Cruz Huaman 77
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 78
Figura N° 23 Acerca del Desarrollador
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 79
Figura N° 24 Ventana Familia
5.4.3 Sistema de Admisión
Sistema de Información para la Atención de Pacientes UNS
Figura N° 25 Registrar Familia
Figura N° 26 Modificar Datos de Familia
Edgar Alexander Cruz Huaman 80
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 81
Figura N° 28 Buscar Integrantes de Familia
Figura N° 27 Borrar Familia
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 82
Figura N°29 Ventana Pacientes
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 83
Figura N° 30 Registrar Nuevo Paciente
Sistema de Información para la Atención de Pacientes UNS
Edgar Alexander Cruz Huaman 84
Modificar Datos del Paciente
Figura N° 31 Modificar Datos del Paciente
Sistema de Información para la Atención de Pacientes UNS
Figura N° 32 Borrar Paciente
Edgar Alexander Cruz Huaman 85
Sistema de Información para la Atención de Pacientes UNS
Figura N° 33 Historia Clínica del Paciente
Edgar Alexander Cruz Huaman 86
Sistema de Información para la Atención de Pacientes UNS
Figura N° 34 Número de Personas por Pueblo agrupadas por sexo
Edgar Alexander Cruz Huaman 87
Sistema de Información para la Atención de Pacientes UNS
Figura N° 35 Número de Personas por Sector agrupadas por sexo
Edgar Alexander Cruz Huaman 88
Sistema de Información para la Atención de Pacientes UNS
Figura N° 36 Pacientes por Fecha de Nacimiento o Defunción
Edgar Alexander Cruz Huaman 89
Sistema de Información para la Atención de Pacientes UNS
Figura N° 37 Número de Integrantes por Familia según Pueblo
Edgar Alexander Cruz Huaman 90
Sistema de Información para la Atención de Pacientes UNS
Figura N° 38 Mujeres Gestantes según Fecha
Edgar Alexander Cruz Huaman 91
Sistema de Información para la Atención de Pacientes UNS
Figura N° 39 Número de Familias por Pueblo y Sector
Edgar Alexander Cruz Huaman 92
Sistema de Información para la Atención de Pacientes UNS
Figura N° 40 Relación de Pacientes Asegurados
Edgar Alexander Cruz Huaman 93
Sistema de Información para la Atención de Pacientes UNS
Figura N° 41 Manual del Desarrollador
Edgar Alexander Cruz Huaman 94
Sistema de Información para la Atención de Pacientes UNS
Figura N° 42 Manual de Usuario - Admisión
Edgar Alexander Cruz Huaman 95
“Sistema de Información para la
atención de Pacientes”
Capitulo VI.
RESULTADOS Y DISCUSIÓN
Sistema de Información para la Atención de Pacientes UNS
RESULTADOS Y DISCUSIÓN
6.1 DEMOSTRACIÓN DE LA HIPÓTESIS:
Para medir los indicadores de las variables dependientes obtenidos anteriormente
(Ver Capitulo IV), se utilizo un cuestionario (Ver Anexo B), aplicándolo a la
muestra de usuarios seleccionados.
El resultado de la aplicación del cuestionario se muestra a continuación.
Tabla N° 07: Resultados de la Aplicación del Cuestionario.
PREGUNTAS AREA
P1 P2 P3 P4 P5 P6 P7
PJE
ADMISIÓN 3 3 2 3 2 3 2 18
MEDICINA 3 2 2 2 1 3 2 15
ENFERMERÍA 3 3 2 2 1 1 1 13
PROMEDIO 15.3
El rango de puntuaciones se muestra a continuación
10.5 Promedio 15.3
Automatización
21
+
0
-
Edgar Alexander Cruz Huaman 96
Sistema de Información para la Atención de Pacientes UNS
El promedio de las repuestas obtenidas es de 15.3 y nos indica un buen nivel de
automatización teniendo en cuenta que el sistema recién empieza a trabajar, con el pasar
del tiempo el nivel de automatización aumentará y por ende se tiene la aceptación en los
usuarios; pero el promedio por si solo no es suficiente, se debe probar que es
estadísticamente significativo. Esto se logrará a través de la prueba t de Student, tal y
como sigue a continuación:
Prueba de Hipótesis Estadística para probar la significancia del Promedio.
1) Planteamiento:
H0 : µ <= 10.5; El Sistema no automatiza los principales procesos de admisión.
Ha : µ > 10.5; El Sistema si automatiza los principales procesos de admisión.
2) Nivel de Confianza (95%)
α = 5% (margen de error)
3) Regiones de aceptación y de rechazo
Si t0 <= t(0.95,3) entonces H0 se acepta. Para esto t0 <= 2.353. En caso contrario
H0 se rechaza y se acepta Ha es decir t0 > 2.353.
4) Cálculos:
N = 3; X = 15.3; µ = 10.5
Edgar Alexander Cruz Huaman 97
Sistema de Información para la Atención de Pacientes UNS
Calculamos la desviación típica. S = 2.51
Entonces t0 = 3.3265
5) Conclusión:
Como t0 > 2.353 H0 se rechaza y se acepta Ha; por lo tanto el sistema si logra
mejorar el control de historias clínicas, ayudando a la toma de decisiones y con
el transcurrir del tiempo mejorará sus ingresos económicos. Esta afirmación
tiene un margen de error del 5%.
La prueba de hipotesis, usando la distribución t de Stundent, ha demostrado que
el promedio de puntuación encontrado es estadisticamente significativo, con lo
cual se ha demostrado que la hipotesis de investigación es válida.
6.2 DISCUSIÓN:
El problema que el presente trabajo de investigación pretende solucionar es el
siguiente: “¿En que medida a través de la Implementación de un Sistema de
Información se mejorará el control de historias clínicas, optimizará sus ingresos
económicos y ayudará a la toma de decisiones del Puesto de Salud San Pedro?”,
para dar solución al problema se planteó la siguiente hipótesis:
El Desarrollo de un Sistema de Información mejorará el control de historias
clínicas, optimizará sus ingresos económicos y ayudará a la toma de decisiones
del Puesto de Salud San Pedro.
Edgar Alexander Cruz Huaman 98
Sistema de Información para la Atención de Pacientes UNS
Para poder demostrar la hipótesis se caracterizó a las variables dependientes de
acuerdo a lo siguiente:
Y = Control de Historias Clínicas.
Indicadores:
y1 = Reducción de los tiempos muertos en la búsqueda de historias
clínicas.
y2 = Evitar la duplicación del número de Historias Clínicas.
y3 = Reducción del espacio utilizado para almacenar historias clínicas
impresas. [1]
W = Optimización de Ingresos Económicos.
Indicadores:
w1 = Más atenciones.
w2 = Reducción de gastos en la compra de papel para la impresión. [1]
Z = Ayuda a la Toma de Decisiones.
z1 = Confiabilidad en las decisiones a tomar.
Luego de aplicar el cuestionario (Ver Anexo B) para determinar el nivel de
aceptación de los indicadores se obtuvo el siguiente resultado tal como los muestra
el gráfico siguiente:
Edgar Alexander Cruz Huaman 99
Sistema de Información para la Atención de Pacientes UNS
Numero de Respuestas por Alternativa
0
0.5
1
1.5
2
2.5
3
3.5
1 2 3 4 5 6 7
Preguntas
N°
de U
suar
ios
Alt1(0) Alt2(1) Alt3(2) Alt4(3)
Figura N° 43 Total de respuestas por alternativa
En todas las preguntas se obtuvo respuestas de aceptación significante es decir las
respuestas están distribuidas entre las Alternativas “4”, “3” y “2”, no tenemos
ninguna respuesta negativa y sabiendo que estas restas respuestas mejorarán con el
transcurrir del tiempo, pues aún se esta registrando a los pacientes.
Para lograr un nivel de aceptación en los resultados generales de la encuesta la
puntuación general oscila entre un mínimo de 0 y un máximo de 21, obteniendo los
siguientes intervalos.
[0 - 7] : No hay aceptación
[8 - 14] : Aceptación Regular
[15 - 21] : Alta Aceptación.
Edgar Alexander Cruz Huaman 100
Sistema de Información para la Atención de Pacientes UNS
El resultado es 15.3, el cual se encuentra en un rango de valores de alta aceptación,
sin embargo la medida de estos rangos es 10.5 (se obtiene de (30+0)/2).
De la aplicación del cuestionario podemos afirmar lo siguiente:
Pregunta 1:
El Sistema demuestra que en cuanto a la velocidad de búsqueda de historias clínicas
de pacientes ha mejorado notablemente en cuanto a la forma manual que se estaba
realizando (La reducción ha ido de los (5 – 30 min.) a los (5 – 15 seg.)).
Pregunta 2:
Se puede observar que la disponibilidad de las historias clínicas es a tiempo,
disminuyendo así el tiempo muerto que se tenía anteriormente, la disponibilidad
será en su totalidad al instante cuando el sistema empiece a trabajar en red
(Cliente/Servidor).
Pregunta 3:
En cuanto a la velocidad de obtener información acerca de un paciente es rápida,
pues el sistema brinda la posibilidad de obtener la información desde cualquier parte
donde se encuentre en el mismo sistema, pues el manejo del mismo tiene muchas
opciones con tan solo pocas ventanas.
Pregunta 4:
Se observa que la duplicación de historias clínicas se ha eliminado, pues es este
punto uno de los más importantes o más solicitados por el establecimiento de salud
ya que el central de quienes dependen se les solicitó que eliminaran las historias
clínicas duplicadas.
Edgar Alexander Cruz Huaman 101
Sistema de Información para la Atención de Pacientes UNS
Pregunta 5:
En cuanto al número de atenciones por el momento se ha mantenido y esto es
debido a que el sistema aún no esta trabajando al 100% porque aun se esta pasando
la información de los archivos al sistema, con el transcurrir de los días el número de
atenciones se pronostica que aumentará.
Pregunta 6:
Uno de los puntos fuertes que tiene el sistema son sus reportes y consultas pues
podemos ver de la encuesta que la seguridad en cuanto a la toma de decisiones ha
mejorado notablemente pues se cuenta con el respaldo estadístico que brinda el
sistema.
Pregunta 7:
En cuanto a la satisfacción del paciente recién empieza a aumentar pues con las
3000 historias clínicas que se han registrado hasta la fecha les a permito que su
atención de alguna manera sea más rápida.
Con estos resultados obtenidos de la aplicación del cuestionario (anexo B), se puede
observar que los indicadores son favorables en cuanto al proceso que se realiza en
admisión en la actualidad.
• Reducción de los tiempos muertos en la búsqueda de historias clínica.
Esto es debido a la velocidad que brinda una computadora
• Eliminación de la duplicación del número de historias clínicas.
Esto es debido a que el Sistema es quien asigna y controla este número no
dejando oportunidad a la duplicación.
Edgar Alexander Cruz Huaman 102
Sistema de Información para la Atención de Pacientes UNS
• Más atenciones.
Este poco a poco se esta dando hasta que se tengan a todos los pacientes
registrados.
• Confiabilidad en las decisiones a tomar.
Pues cuenta con el respaldo estadístico que brinda el sistema pudiendo hacer
las consultas que se necesiten de una manera sencilla y rápida.
Con estos resultados obtenidos y con la demostración de la veracidad de la
hipótesis realizada mediante una prueba de t de Student, podemos afirmar que
nuestra hipótesis de investigación es valida.
Edgar Alexander Cruz Huaman 103
“Sistema de Información para la
atención de Pacientes”
CONCLUSIONES Y RECOMENDACIONES
Sistema de Información para la Atención de Pacientes UNS
CONCLUSIONES
1. Se logró definir la situación problemática de los procesos involucrados en el
área de admisión y por ende en las áreas de atención medica.
2. Se logró identificar los principales procesos que se realizan en el área de
admisión.
3. Se auditó al equipo con que contaba y bajo este se selecciono la plataforma así
como el lenguaje de programación sobre el cual se trabajaría y el sistema gestor
de base de datos que utilizaría.
4. Se aplicó la Metodología XP para el desarrollo del proyecto, la cual facilito el
trabajo pudiéndose concluir en el tiempo previsto.
5. Se pudo desarrollar el Sistema de Admisión de manera satisfactoria.
6. Se realizó las pruebas al Sistema, aplicándose los cuestionarios que se indica en
el anexo B y C obteniéndose resultados satisfactorios.
7. Se demostró a través de la prueba estadística que el Sistema cumple su objetivo
de controlar las historias clínicas, apoyar a la toma de decisiones y en su futuro
al incremento de ingresos económicos del Puesto de Salud San Pedro.
8. Se capacitó a personal que utilizaría el sistema, quedando este conforme con las
facilidades que brindaba el sistema.
Edgar Alexander Cruz Huaman 104
Sistema de Información para la Atención de Pacientes UNS
RECOMENDACIONES
1. Se recomienda adquirir más equipo hardware para que la automatización sea la
más eficiente, pudiendo así ahorrar en archivadores, papel, etc. Y haciendo más
óptimo el flujo de información. Pues esta PCs trabajarían en Red.
2. Como se esta trabajando bajo la metodología XP, el Sistema puede crecer y se
recomienda una capacitación constante a los usuarios para evitar los posibles
errores.
3. La instalación de un equipo UPS en caso de cortes de energía, ya que el Sistema
depende de esto.
4. Se recomienda leer los manuales ante cualquier duda que se presente.
Edgar Alexander Cruz Huaman 105
Sistema de Información para la Atención de Pacientes UNS
BIBLIOGRAFÍA
Libros:
• Roger S. Presuman, “Ingeniería del Software – Un enfoque practico”, Quinta
Edición - Madrid 2001. Editorial Mc. Graw Hill.
• Silberschatz – Korth – Sudarshan, “Fundamentos de Bases de Datos”, Cuarta
Edición.
• Juan José Castañeda León, “Power Builder 9.0 Fulla DataBase”, Editorial
Megabyte.
• Luís Eduardo Ramírez, “Desarrollando con Power Builder 8.0”, Editorial
Macro
Publicaciones Electrónicas
Gestores de Bases de Datos, más conocidas:
• http://www.pcm.gob.pe/portal_pngei/publicaciones/tecnicas/lib5017/msoft09.htm
El Analista de Sistemas: Grupo de Estudios AS –
• http://members.xoom.com/analista/portada.htm
Power Designer
• http://www.sybase.com/products/powerdesigner
• http://translate.google.com/translate?hl=es&sl=en&u=http://www.sybase.com/pro
ducts/developmentintegration/powerbuilder&prev=/search%3Fq%3Dpower%2Bb
uilder%26hl%3Des%26lr%3D
Edgar Alexander Cruz Huaman 106
Sistema de Información para la Atención de Pacientes UNS
• http://powerbuilder.codeXchange.sybase.com.
SYBASE
• www.sybase.com.
• http://sybooks.sybase.com/pb.html.
Metodología XP
• http://www.programacionextrema.org/cgi-bin/wiki.pl?ProgramacionExtrema
Algunas referencias importantes en inglés:
• WardCunningham http://c2.com/cgi/wiki?ExtremeProgramming.
• http://www.extremeprogramming.org/
• http://www.xprogramming.com/
• http://xp123.com/
• http://www.industriallogic.com/xp/index.html
• http://groups.yahoo.com/group/extremeprogramming
• http://www.jera.com/techinfo/xpfaq.html
• http://www.objectmentor.com/home
• http://ootips.org/xp.html
Sitios en Europa
• http://www.xp.be/
• http://www.ot2003.org/
• http://www.agilemovement.it/
Edgar Alexander Cruz Huaman 107
Sistema de Información para la Atención de Pacientes UNS
Sitios en Ibero América
• http://www.programacionextrema.org/
• http://www.xispe.com.br/
• http://www.agile-spain.com/
• http://www.programacion.com/
• http://www.agile-paraguay.org/
Eventos internacionales importantes:
• http://www.xp2006.org/
• http://www.xpuniverse.com/home
• http://www.xispe.com.br/evento2004/index.html
• http://www.angelfire.com/dc/marcodorantes
Otras direcciones:
• http://www.extremeprogramming.org/
• http://www.xprogramming.com/xpmag/whatisxp.htm
• http://www.xprogramming.com/what_is_xp.htm
• http://oness.sourceforge.net/docbook/resources.html#AgileManifesto
• http://www.informatizate.net/articulos/metodologias_de_desarrollo_de_software_
07062004.html
• http://es.tldp.org/Presentaciones/200211hispalinux/ferrer/robles-ferrer-ponencia-
hispalinux-2002.pdf
• http://www.programacion.com/blogs/84_metricas_web/archive/526_fundamentos
_de_extreme_programming_parte_ii.html
• http://punto-informatico.it/servizi/ps.asp?i=31526&r=PI
Edgar Alexander Cruz Huaman 108
“Sistema de Información para la
atención de Pacientes”
ANEXOS
Sistema de Información para la Atención de Pacientes UNS
ANEXO A
CARACTERISTICAS DEL HARDWARE Y SOFWARE
Para realizar la auditoria de la PC se utilizo el Software Berlarc Advisor 5.0. A) Hardware
System Model
VIA Technologies, Inc. VT82C694X
Processor a
Main Circuit Board
1000 megahertz Intel Pentium III 32 kilobyte primary memory cache 256 kilobyte secondary memory cache
Board: 694X-686A Bus Clock: 133 megahertz BIOS: Award Software International, Inc. 6.00 PG 02/12/2001
Drives
Memory Modules
128 Megabytes Installed Memory 128 Megabyte Module Size - 1 Installed 3 Memory Sockets are Empty
Local Drive Volumen
c: (on drive 0) 20.01 GB 8.52 GB free d: (on drive 0) 20.00 GB 16.41 GB free
Network Drives
40.01 Gigabytes Usable Hard Drive Capacity 24.93 Gigabytes Hard Drive Free Space CREATIVE CD5233E-N [CD-ROM drive] 3.5" format removeable media [Floppy drive] MAXTOR 4K040H2 (40.04 GB) [Hard drive] -- drive 0
Controllers
Printers
N one detected Display
Canal IDE principal [Controller] Canal IDE secundario [Controller] Controladora IDE principal de bus VIA [Controller] SiS 5598/6326 [Display adapter]
SiS 5598/6326 [Display adapter] Bus Adapters Multimedia
None detected Audio WDM Crystal SoundFusion(TM) CS4281
Communications
Other Devices
Minipuerto WAN (IP) Minipuerto WAN (IP) - Minipuerto del administrador de paquetes Minipuerto WAN (L2TP) Minipuerto WAN (PPPOE) Minipuerto WAN (PPTP)
Concentrador raíz USB Concentrador raíz USB Controlador de host universal USB VIA Rev 5 o posterior Controlador de host universal USB VIA Rev 5 o posterior
Edgar Alexander Cruz Huaman 109
Sistema de Información para la Atención de Pacientes UNS
B) Software
Operating System
Windows XP Professional, Service Pack 2
Software Licenses
Microsoft - Internet Explorer 55274-649-9930016-23675 Microsoft - Office Professional Edition 2003 73961-640-0000106-57286 Microsoft - Windows XP Professional 55274-649-9930016-23675
Software Versions
A0000330 * Adobe Acrobat Reader Version 5.0.0.0* Ahead Software AG Karlsbad Germany Phone: ++49-7248-911-800 Fax: ++49-7248-911-888 e-mail: [email protected] - LANGUAGE_English2 Version 5, 5, 9, 9* Ahead Software AG - InfoTool Application Version 1, 2, 0, 0* ahead software gmbh, karlsbad - Cover Designer Version 2, 2, 1, 6* Belarc Advisor and BelLive - Belarc's Content Personalization with Privacy Version 5.0m* Cinematronics - 3D Pinball Version 5.1.2600.2180* Desinstalar PER Antivirus Version 9.3.01* Erik Deppe - DriveSpeed Application Version 1, 5, 0, 0* Erik Deppe - Nero CD Speed Application Version 1, 0, 0, 0* iAnywhere Solutions, Inc. - Adaptive Server Anywhere Version 9.0.1.1873* Instituto Nacional de Salud - Sistema Informatico del Estado Nutricional Version 1.00* Microsoft - PDMan98 Version 6.00.8169* Microsoft Clip Organizer Version 11.0.5510* Microsoft Corporation - Dependency Walker Version 1.0* Microsoft Corporation - Messenger Version 4.7.3000* Microsoft Corporation - Office Source Engine Version 11.0.5525* Microsoft Corporation - OLEViewer Version 2.1* Microsoft Corporation - VB 6 API Declaration Loader Version 6.00.8169* Microsoft Corporation - Windows Movie Maker Version 2.1.4026.0* Microsoft Corporation - Windows® NetMeeting® Version 3.01* Microsoft Corporation - Zone.com Version 1.2.626.1* Microsoft Object Linking and Embedding Client Test for Windows Version 1.01.000* Microsoft Object Linking and Embedding Server Test for Windows Version 1.01.000* Microsoft Office 2003 Version 11.0.5510* Microsoft Office 2003 Version 11.0.5529* Microsoft Office 2003 Version 11.0.5604* Microsoft Office 2003 Version 11.0.5612* Microsoft Office 2003 Version 11.0.5614* Microsoft Office Document Imaging Version 11.0.1897.0* Microsoft Office InfoPath Version 11.0.5510* Microsoft® Developer Studio Version 6.0.000* Ministerio de Salud - Aplicativo Funciones Obstétricas y Neonatales Version 1.01* Módulo de usuarios Version 2000.0.0* Módulo exportación Version 2000.0.0* Módulo Integridad Version 2.0.0* Módulo Utilitarios Version 2000.0.0* Nullsoft - Winamp Version 2.77* PER Antivirus Version 9, 4, 0, 0* Reproductor de Windows Media de Microsoft(R) Version 9.00.00.3250* Servicios Internet de Microsoft® Version 6.1.33.0* SIP2000 (intranets) Version 2000.0.1405* Sistema operativo Microsoft(R) Windows (R) 2000 Version 5.50.4134.600*
Edgar Alexander Cruz Huaman 110
Sistema de Información para la Atención de Pacientes UNS
Sistema operativo Microsoft® Windows® Version 5.1.2600.2180* Sistema operativo Microsoft® Windows® Version 6.00.2900.2180* Sybase - StandAlone Translation Toolkit Version 10,0,0,4510* Sybase - Translation Toolkit Version 10,0,0,4510* Sybase Central Version 4.3.0.2244* Sybase Inc. - InfoMaker * Sybase Inc. - PowerBuilder * Sybase Inc. - PowerBuilder/InfoMaker * Sybase, Inc. - PowerBuilder Enterprise Series Version 1,0,0,1* WinampAgent * WinRAR
Edgar Alexander Cruz Huaman 111
Sistema de Información para la Atención de Pacientes UNS
ANEXO B
DISEÑO DEL CUESTIONARIO PARA MEDIR LA
AUTOMATIZACIÓN
1. La velocidad en la Búsqueda de Historias Clínicas se ha:
0) Reducido 1) Mantenido
2) Aumentado 3) Mejorado Notablemente
2. La disponibilidad de las Historia Clínicas es:
0) Muy Lenta 1) Con retrazo
2) A Tiempo 3) Al Instante.
3. La Velocidad de obtener información acerca de una persona es:
0) Muy Lenta 1) Lenta
2) Rápida 3) Muy Rápida
4. La duplicación de Historias Clínicas ha:
0) Aumentado 1) Mantenido
2) Reducido 3) Eliminado
5. El numero de atenciones ha:
0) Reducido 1) Mantenido
2) Aumentado 3) Mejorado Notablemente
Edgar Alexander Cruz Huaman 112
Sistema de Información para la Atención de Pacientes UNS
6. La seguridad en cuanto a la toma de decisiones se ha:
0) Reducido 1) Mantenido
2) Aumentado 3) Mejorado Notablemente
7. La satisfacción del paciente al ser atendido mas rápido ha:
0) Reducido 1) Mantenido
2) Aumentado 3) Aumentado Notablemente
Edgar Alexander Cruz Huaman 113
Sistema de Información para la Atención de Pacientes UNS
ANEXO C
DISEÑO DEL CUESTIONARIO PARA PRUEBAS DEL
SOFTWARE
1. El manejo de las opciones del sistema es:
0) Muy Difícil 1) Difícil
2) Entendible 3) Muy Fácil
2. El manejo de la ventana de registro, búsqueda, modificacion y eliminacion es:
0) Muy Difícil 1) Difícil
2) Entendible 3) Muy Fácil
3. La información mostrada en la ventana registro es:
0) Faltan Datos 1) A medias
2) Necesaria 3) Completa
4. La búsqueda de los pacientes y sus datos es:
0) Muy lenta 1) Lenta
2) Rápida 3) Muy Rápida
5. La modificacion de los datos de los pacientes causa:
0) Muchos Problemas 1) Pocos Problemas
3) No Causa Problemas
6. El ingreso de usuarios al Sistema es:
Edgar Alexander Cruz Huaman 114
Sistema de Información para la Atención de Pacientes UNS
0) Pésimo 1) Regular
2) Bueno 3) Excelente
7. Los accesorios que brinda el sistema tienen una utilidad de:
0) 0 – 5 1) 6 - 10
2) 11 - 15 3) 16 – 20
8. Las consultas son:
0) Muy Difícil 1) Difícil
2) Entendible 3) Muy Fácil
9. Los Reportes que brinda el sistema son:
0) Insuficientes 1) No se Entienden
1) Necesarios 3) Completos
10. Que calificación merece el sistema según su desempeño:
0) 0 – 5 1) 6 - 10
2) 11 - 15 3) 16 – 20
Edgar Alexander Cruz Huaman 115
Sistema de Información para la Atención de Pacientes UNS
ANEXO D
ESTUDIO DE FACTIBILIDAD
A) Factibilidad Operativa:
Es evaluada tomando los siguientes criterios:
Existe el respaldo necesario por parte del personal que labora en el Puesto de
Salud, para que este proyecto se lleve a cabo; y durante el desarrollo de cada una
de las etapas, se me brindo la información requerida, así mismo su confianza y
apoyo de forma incondicional que fueron sustanciales al momento de la
realización de este proyecto.
El Sistema de Información que se propone, ayudará a tener un mejor control de
la información requerida por parte de los trabajadores del puesto de salud,
controlará el número de historia clínica y número de familia evitando que se
repitan, agilizará el proceso de búsqueda de historias clínicas y por ende podrá
optimizar los ingresos económicos al poder a tender a más pacientes, apoyará a
la toma de decisiones por parte de la dirección del puesto de salud y además de
satisfacción tanto del personal que labora y los pacientes al ser atendidos de una
manera más rápida.
En cuanto a la disponibilidad de tiempo para realizar las actividades del proyecto
que se dan a diario se cuenta con lo suficiente, facilitando así la labor que se esta
realizando.
También es factible la capacitación del personal, pues forma parte del equipo de
desarrollo y esta constantemente interactuando con cada una de las versiones
instaladas.
Edgar Alexander Cruz Huaman 116
Sistema de Información para la Atención de Pacientes UNS
Concluyendo de esta manera que el proyecto es factible operacionalmente.
B) Factibilidad Técnica
Para la elaboración de este proyecto, se requiere de medios técnicos: por lo cual
se utilizó los siguientes equipos de hardware y herramientas de software.
Hardware Requerido Descripción Mínima 1 Computadora Como mínimo debe de contar con las
siguientes características: • Procesador Pentium III 600 Hhz. • Memoria 128 MB. • Disco Duro 20 GB.
1 Impresora Matricial o inyección (opcional) Observación:
- Se cuenta con una computadora, con características mayores a las indicadas en la celda anterior.
- Con una impresora Matricial platillera. Software
Requerido Versión del
Software Descripción
Microsoft Windows
XP, 2000 o 2003
Es un software que se ejecuta en un equipo y controla los programas y hardware de la PC. Herramienta necesaria para la ejecución de los demás sw. Disponible por el Desarrollador.
Power Builder 9.0 o 10.0 Lenguaje de programación visual y orientado a objetos, necesario para construir el sistema propuesto y que estuvo disponible por el Desarrollador.
SQL Anywhere 8.0 o 9.0 Gestor de Base de Datos, herramienta necesaria para construir para construir la base de datos disponible por parte del Desarrollador.
Observación: Con la utilización de estos software y con las técnicas y herramientas de ingeniería del software se ha desarrollado el Sistema propuesto.
Debido a que el Puesto de Salud cuenta con el equipo hardware que sobre pasa a
los requerimientos mínimos para soportar la aplicación. Por tanto luego de
realizar este análisis, se concluye que el proyecto es factible técnicamente.
Edgar Alexander Cruz Huaman 117
Sistema de Información para la Atención de Pacientes UNS
C) Factibilidad Económica
Comprende los costos asociados al Sistema de Información para la atención de
pacientes del Puesto de Salud San Pedro – Chimbote y los beneficios tangibles e
intangibles que se obtendrán.
C.1 Costos:
C.1.1 Costos del Software
Estos son los costos asociados al desarrollo del software y se clasifican
en:
1. Hardware
2. Software
3. Recursos Humanos
4. Servicios
5. Materiales
1. Hardware
Para llevar a cabo el desarrollo del sistema se requiere el uso de
una computadora.
Cálculo Total de Horas Uso de la PC.
Costos de Hardware: 61 (días) * 8 (horas) * 1 (persona) = 488
Tabla Nº 03 COSTOS DE HARDWARE Costo de Energía Eléctrica S/. 181.58
488 horas * 0.3721 Costo Total Hardware S/. 181.58
Edgar Alexander Cruz Huaman 118
Sistema de Información para la Atención de Pacientes UNS
2. Software
Así mismo, para llevar a cabo el desarrollo del proyecto, se
requiere las siguientes herramientas de software:
Tabla Nº 03 COSTO DE SOFTWARE Microsoft Windows XP $ 560.00 S/. 1803.20Power Builder y SQL Anywhere (Paquete)
$ 5000.00 S/. 16100.00
Microsoft Office XP $309.63 S/. 995.95SUB - TOTAL $1219.63 S/. 18899.15
3. Recursos Humanos
Tabla Nº 04 COSTOS DE RECURSOS HUMANOS Un Desarrollador de Software por las 12 horas de trabajo al día.
S/. 2400.00
1200 * 2 mesesSUB - TOTAL S/. 2400.00
Cabe recalcar que el sueldo promedio de un desarrollador de
software en Chimbote es de S/. 800 nuevos soles al mes por 8
horas de trabajo diarias de trabajo.
Se tomo como tipo de cambio del dólar el valor de S/.3.22
4. Servicios
Tabla Nº 05 COSTOS DE SERVICIOS Movilidad S/. 0.00Internet S/. 10.00Fotocopias S/. 1.00Mantenimiento de la PC S/. 50.00
SUB - TOTAL S/. 61.00
Edgar Alexander Cruz Huaman 119
Sistema de Información para la Atención de Pacientes UNS
5. Materiales
Tabla Nº 06 COSTOS DE MATERIALES 1 Millar de papel Boon (*) S/. 0.002 Lapiceros (*) S/. 0.001 Caja de Disquetes 2hb IBM (*) S/. 0.001 CD-RW 80 min/700mb – 4x S/. 5.001 Cinta para impresora S/. 15.00
SUB - TOTAL S/. 20.00
(*) Tienen valor cero, debido a que el establecimiento de salud
contaba con estos materiales y los proporciono gratuitamente.
Tabla Nº 07 CONSOLIDADO DE COSTOS Costos de Hardware S/. 181.58Costos de Software S/. 18899.15Costos de Recursos Humanos S/. 2400.00Costos de Servicios S/. 61.00Costos de Materiales S/. 20.00
SUB - TOTAL S/. 21561.73
C.2 Beneficios del Sistema Propuesto:
Los beneficios obtenidos con el Sistema de Información, responden sobre todo a
la necesidad que tiene el Puesto de Salud San Pedro de controlar el numero de
historias clínicas, reducción en el tiempo de búsqueda de historias, apoyo a la
toma de decisiones, atención a más pacientes lo cual conllevaría a optimizar su
fuente de ingreso.
C.2.1 Beneficios Tangibles
La siguiente lista es un resumen de los beneficios tangibles que se
obtendrán con la realización del proyecto.
Edgar Alexander Cruz Huaman 120
Sistema de Información para la Atención de Pacientes UNS
- Tiempo
El tiempo que dedican los trabajadores de admisión y del puesto de
salud en general a buscar las historias clínicas de los pacientes, se vera
reducido al mínimo ya que la computadora lo buscara por el
Ahorro de tiempo para la toma de decisiones pues podrán hacerlo de
una manera más rápida y segura.
- Eficiencia
Los datos de los pacientes serán actualizables y modificables.
C.2.2 Beneficios Intangibles
- Mejora la atención de los usuarios.
- Ayuda a cumplir con los objetivos y metas propuestas con eficiencia y
efectividad.
- Permite tener un oportuno acceso a la información.
- Aumenta la Imagen Institucional del Puesto de Salud San Pedro –
Chimbote.
C.3 Recuperación del Costo:
C.3.1 Manifestación de la Dirección del Puesto de Salud
El señor Cléver Pinedo Orue, manifiesta que:
• El Puesto de Salud deja de atender a un promedio de 5 pacientes al día,
debido a las causas que se mencionaron anteriormente.
• La consulta normal cuesta S/. 2.50.
• Se estima que por los pacientes que no se atienden, se pierde dinero
adicional a la consulta, pues estos pacientes también requieren otros
Edgar Alexander Cruz Huaman 121
Sistema de Información para la Atención de Pacientes UNS
servicios como: medicina, laboratorio, etc. Este monto haciende a un
promedio de S/. 500.00 al año.
De lo anterior se concluye:
• Pérdida en Consulta al año: S/. 2.50 * 5 pacientes * 300 días.
Pérdida en Consulta al año = S/. 3 750.00
• Pérdida en otros servicios al año: S/. 500.00
• Pérdida Total al Año: S/. 4 250.00
Por lo tanto, si el Puesto de Salud compra las licencias de software y los
gastos que conllevo realizar el Sistema de Admisión, recuperaría sus gastos
en el periodo de:
.0733.500.2504./73.56121./ años
SS
PérdidadeCostolicenciasdeCostosAñosdeNúmero ===
La dirección del Puesto de Salud ha manifestado que es imposible que se
compre las licencias de software, así que optará por no comprarlas, pero si
puede cubrir los demás gastos. Entonces la nueva recuperación de sus
gastos sería en el periodo de:
.6264.000.2504./58.6622./ años
SS
PérdidadeCostolicenciasSinCostosAñosdeNúmero ===
Lo que implica que el Puesto de Salud recuperaría los gastos en menos de 8
meses.
Conclusión:
Por tanto luego de realizar este análisis, se concluye que el proyecto es
factible económicamente.
Edgar Alexander Cruz Huaman 122