Sistema de Registro de Atención Médica para Un Centro de Salud de Nivel I-3 de Complejidad

FACULTAD DE INGENIERA
CARRERA DE INGENIERA DE SOFTWARE
Sistema de registro de atencin mdica para un centro

de salud de nivel I-3 de complejidad
MEMORIA DE PROYECTO
Para optar por el Ttulo de:
INGENIERO DE SOFTWARE
AUTORES:
Farroay Rivero, Karen Ivone
Trujillo Mochcco, Alex Javier
ASESOR:
Amanda Snchez
LIMA PER
2013
DEDICATORIA
A nuestros padres que depositan da a da su confianza en nosotros y

apoyan las decisiones que tomamos.
TABLA DE CONTENIDO
RESUMEN EJECUTIVO ............................................................................................................................ 8

ABSTRACT ............................................................................................................................................ 10
INTRODUCCIN ................................................................................................................................... 12
CAPTULO 1. DESCRIPCIN DEL PROYECTO .......................................................................................... 14
INTRODUCCIN .......................................................................................................................................... 14
OBJETO DE ESTUDIO.................................................................................................................................... 14
DOMINIO DEL PROBLEMA ............................................................................................................................. 16
Anlisis del Problema ........................................................................................................................ 17
Soluciones Existentes ........................................................................................................................ 18
PLANTEAMIENTO DE LA SOLUCIN ................................................................................................................. 20
Alcance del Proyecto ......................................................................................................................... 21
Metodologa de Desarrollo ............................................................................................................... 23
Tecnologas de Desarrollo ................................................................................................................. 23
OBJETIVOS DEL PROYECTO ............................................................................................................................ 25
Objetivos Generales .......................................................................................................................... 25
Objetivos Especficos ......................................................................................................................... 26
INDICADORES DE LOGRO .............................................................................................................................. 26
CAPTULO 2. MARCO TERICO ............................................................................................................. 29
INTRODUCCIN .......................................................................................................................................... 29
MARCO TERICO........................................................................................................................................ 29
Ministerio de Salud - MINSA ............................................................................................................. 29
Modelo de Atencin Integral de Salud - MAIS .................................................................................. 29
Categoras de Establecimientos del Sector Salud .............................................................................. 30
Centros de Salud de Categora I-3 ..................................................................................................... 33
Historia Clnica. ................................................................................................................................. 35
Rational Unified Proccess (RUP) ........................................................................................................ 41
Service Oriented Architecture (SOA) ................................................................................................. 48
Disposiciones del Ministerio de Salud ............................................................................................... 52
CAPTULO 3. REQUERIMIENTOS DEL SOFTWARE .................................................................................. 53
INTRODUCCIN .......................................................................................................................................... 53
REQUERIMIENTOS FUNCIONALES ................................................................................................................... 53
Procesos del Negocio ........................................................................................................................ 53

Requerimientos Funcionales ............................................................................................................. 61
Actores del Sistema ........................................................................................................................... 65
Casos de Uso del Sistema .................................................................................................................. 67
Casos de Uso Vs. Proceso .................................................................................................................. 86
REQUERIMIENTOS NO FUNCIONALES............................................................................................................... 88
Usabilidad ......................................................................................................................................... 88
Confiabilidad ..................................................................................................................................... 89
Performance...................................................................................................................................... 90
Soporte .............................................................................................................................................. 91
Restricciones de Diseo ..................................................................................................................... 92
Requerimientos de la Documentacin en Lnea del Usuario y del Sistema de Ayuda ....................... 93
Componentes Comprados ................................................................................................................. 94
Interfaces .......................................................................................................................................... 94
Requerimientos de Recursos ............................................................................................................. 94
CAPTULO 4. DISEO ARQUITECTNICO .............................................................................................. 98
INTRODUCCIN .......................................................................................................................................... 98
FUNDAMENTOS PARA LA ARQUITECTURA ......................................................................................................... 98
Metas y Restricciones Arquitectnicas.............................................................................................. 98
SNTESIS GENERAL DE LA ARQUITECTURA ........................................................................................................ 99
ORGANIZACIN EN CAPAS .......................................................................................................................... 103
Sistemas Operacionales .................................................................................................................. 103
Componentes Empresariales ........................................................................................................... 105
Servicios .......................................................................................................................................... 108
Composicin y coreografa de procesos de negocio........................................................................ 115
Presentacin o Acceso..................................................................................................................... 119
Integracin ...................................................................................................................................... 120
Presentacin o Acceso..................................................................................................................... 121
Despliegue de la Solucin................................................................................................................ 122
Temas y decisiones de desempeo ................................................................................................. 124
CAPTULO 5. DISEO DETALLADO ...................................................................................................... 125
INTRODUCCIN ........................................................................................................................................ 125
DISEO DE LA BASE DE DATOS ..................................................................................................................... 125
Diseo Fsico .................................................................................................................................... 125
DICCIONARIO DE DATOS............................................................................................................................. 127
Tablas .............................................................................................................................................. 127
Detalle de Tablas............................................................................................................................. 129
DESCRIPCIN DEL COMPONENTE ................................................................................................................. 140

Identificacin tcnica del componente / ECS .................................................................................. 140
Requerimientos de Operacin ......................................................................................................... 144
Interface de Aplicacin .................................................................................................................... 146
Estructura Interna ........................................................................................................................... 157
PATRONES DE DISEO ............................................................................................................................... 160
Singletone ....................................................................................................................................... 160
DAO ................................................................................................................................................. 160
DTO ................................................................................................................................................. 160
Iterator ............................................................................................................................................ 161
MVC................................................................................................................................................. 161
CAPTULO 6. CONSTRUCCIN ............................................................................................................ 163
INTRODUCCIN ........................................................................................................................................ 163
MAPEO DEL DISEO A LA IMPLEMENTACIN .................................................................................................. 163
ESTNDAR DE CODIFICACIN - JAVA ............................................................................................................. 164
Definicin de Clases ........................................................................................................................ 165
Definicin de Atributos.................................................................................................................... 165
Definicin de Operaciones / Mtodos ............................................................................................. 166
Variables ......................................................................................................................................... 166
Paquetes ......................................................................................................................................... 166
ESTNDAR DE CODIFICACIN DE BASE DE DATOS ............................................................................................ 167
Definicin de Tablas ........................................................................................................................ 167
Definicin de Campos de las Tablas ................................................................................................ 167
Definicin de ndices ....................................................................................................................... 169
Definicin de Variables ................................................................................................................... 169
Definicin de Procedimientos Almacenados (Stored Procedures) ................................................... 170
Definicin de Funciones .................................................................................................................. 170
Definicin de Disparadores (Triggers) ............................................................................................. 170
Definicin de Vistas ......................................................................................................................... 171
Definicin de Backups ..................................................................................................................... 171
CAPACITACIN DE RECURSOS ...................................................................................................................... 171
DEPURACIN DE LA APLICACIN................................................................................................................... 172
CAPTULO 7. ASEGURAMIENTO DE LA CALIDAD ................................................................................. 173
INTRODUCCIN ........................................................................................................................................ 173
PRUEBAS UNITARIAS .................................................................................................................................. 173
ObtenerUnaCategoriaAdultoMayor. .............................................................................................. 174
ObtenerCategoriasAdultoMayor..................................................................................................... 174
RegistraEncuentroMedicogeneral (Mtodo que guarda los datos comnes para los diferentes
formatos de atencin). .................................................................................................................... 175
RegistrarEncuentroMedicoGeneral (Nio) ...................................................................................... 175
RegistrarEncuentroMedicoGeneral (Adolescente) .......................................................................... 175
RegistrarEncuentroMedicoGeneral (Adulto) ................................................................................... 176
RegistrarEncuentroMedicoGeneral (Adulto Mayor) ....................................................................... 176
ObtenerEncuentrosXEpisodio .......................................................................................................... 176
ObtenerEpisodiosMedicosGenralesEntrefechas ............................................................................. 177
ObtenerEncuentroNino ................................................................................................................... 177
ObtenerEncuentroAdultoMayor...................................................................................................... 177
ObtenerEncuentroAdulto ................................................................................................................ 178
ObtenerEncuentroAdolescente ....................................................................................................... 178
ObtenerEpisodiosMdicosgeneralesxPaciente ............................................................................... 178
RegistrarEpisodioMedicoGeneral .................................................................................................... 179
RegistrarRecetaMedica ................................................................................................................... 179
ObtenerDetalleRM (Receta Mdica) ............................................................................................... 179
ObtenerUnaRecetaMedica.............................................................................................................. 180
ObtenerSignosPeligroxEtapaNino ................................................................................................... 180
ListarEstadosxParmetro ................................................................................................................ 180
ListarTiempos. ................................................................................................................................. 181
RegistrarOrdenEM (Examen Mdico) ............................................................................................. 181
ObtenerUnExamenMedico .............................................................................................................. 181
ObtenerExamenesMedicosxTipo ..................................................................................................... 181
ObtenerUnaLineaEM....................................................................................................................... 182
ObtenerLineasEM ............................................................................................................................ 182
ObtenerUnaOrdenEM ..................................................................................................................... 182
ObtenerUnTipoEM .......................................................................................................................... 183
ObtenerTiposEMxLineaEM .............................................................................................................. 183
ObtenerUnEstadoExamenMedico ................................................................................................... 183
ObtenerDetalleOrdenEM ................................................................................................................ 183
ObtenerResultadoEMxKDetalleOrdenEM ....................................................................................... 184
ObtenerDetalleOrdenxOrdenEMxEstadoDetalle ............................................................................. 184
INSPECCIN ARTEFACTOS/DOCUMENTOS ...................................................................................................... 188
VALIDACIN DEL SISTEMA .......................................................................................................................... 189
CAPTULO 8. GESTIN DEL PROYECTO ............................................................................................... 191
INTRODUCCIN ........................................................................................................................................ 191
EQUIPO DEL PROYECTO .............................................................................................................................. 191
ROLES Y RESPONSABILIDADES ...................................................................................................................... 193

CRONOGRAMA DEL PROYECTO .................................................................................................................... 194
Fase 1 - Concepcin ......................................................................................................................... 194
Elaboracin ..................................................................................................................................... 196
Construccin.................................................................................................................................... 198
Transicin ........................................................................................................................................ 202
ESTIMACIN DE ESFUERZO Y TIEMPO DE DESARROLLO ..................................................................................... 202
RIESGOS DEL PROYECTO ............................................................................................................................. 203
Tabla de Probabilidad ..................................................................................................................... 203
Tabla de Severidad .......................................................................................................................... 204
Tabla de Probabilidad vs. Severidad ............................................................................................... 205
Tabla de Criticidad .......................................................................................................................... 205
Riesgos Identificados....................................................................................................................... 205
Impacto del Riesgo .......................................................................................................................... 207
Tabla de Estrategias ante los Riegos............................................................................................... 208
Acuerdos entre proyectos ............................................................................................................... 210
CAPTULO 9. TRANSICIN .................................................................................................................. 211
INTRODUCCIN ........................................................................................................................................ 211
DESENLACE DEL PROYECTO ......................................................................................................................... 211
INSTALADORES ......................................................................................................................................... 212
MANUALES.............................................................................................................................................. 212
Manuales de Usuario ...................................................................................................................... 212
Manual de Instalacin .................................................................................................................... 213
PUBLICIDAD ............................................................................................................................................. 213
Afiche .............................................................................................................................................. 213
Caja Contenedora ........................................................................................................................... 215
Diapositivas para Presentacin ....................................................................................................... 215
Demos ............................................................................................................................................. 215
CONCLUSIONES .................................................................................................................................. 216
RECOMENDACIONES .......................................................................................................................... 218
BIBLIOGRAFA .................................................................................................................................... 222
ANEXOS ............................................................................................................................................. 224
RESUMEN EJECUTIVO
En el ao 2008, la Facultad de Computacin de la Universidad Peruana de Ciencias
Aplicadas establece la empresa virtual Salud-able cuyo giro de negocio es elaborar
tecnologas de informacin para entidades de salud. La empresa se dedic, en primer
lugar, al estudio de los procesos de centros de salud de nivel I-3 del Ministerio de Salud
del Per. Se identificaron 3 procesos macro, los cules son: estratgicos, asistenciales y
de apoyo.
Como proyecto inicial se ejecut el Modelamiento de Procesos Empresariales para una
Entidad Mdica de Nivel I-3 de Complejidad que investig los procesos asistenciales
de un centro de salud I-3 y como resultado se defini una cartera de proyectos de
software para la automatizacin de estos procesos. Adems, se realiz el proyecto
Arquitectura de Negocios de un Centro de Salud de Nivel I-3 que investig los
procesos estratgicos y de apoyo de las entidades de salud.
Como consecuencia de la definicin de la cartera de proyectos se iniciaron, en paralelo,

los proyectos Diseo de una Arquitectura Orientada a Servicios para un
Establecimiento de Salud de Nivel I-3 de Complejidad y Diseo de una Arquitectura
de Datos para Salud de Nivel I-3. La primera investig las diferentes tecnologas
actuales del mercado de software, las evalu y concluy que los sistemas a realizarse
deberan estar orientados a servicios (SOA) y hacer uso de herramientas libres para su
implementacin. El segundo proyecto establece la arquitectura de datos segn el anlisis
de las entidades de negocio identificadas en los procesos del centro de salud.
El presente proyecto tiene como objetivo general la implementacin de un sistema que

automatice los procesos asistenciales de Atencin de Servicios Clnicos y Control de
Exmenes Mdicos en una entidad de salud de Nivel I-3 de complejidad para solucionar
el principal problema de gestin de la informacin del paciente.
Teniendo como base los proyectos anteriores en donde se definieron los procesos de
negocio del centro de salud y la arquitectura tanto del software como de datos se puede
iniciar la ejecucin de las actividades para la implementacin del sistema. Sin embargo,
debido al tiempo transcurrido desde la entrega del resultado del primer proyecto y, en
aras de mitigar el riesgo de haberse modificado los procesos dentro del centro de salud,
se decidi, como parte del plan del proyecto, realizar actividades de reevaluacin de las
fases de conceptualizacin del problema de los centros de salud y de elaboracin de las
arquitecturas tanto de software como de datos. Esto conllev a asistir a por lo menos 2
entidades de salud y establecer reuniones con los actores de los procesos en estudio,
solicitar documentacin de los mismos y consultar normas tcnicas del estado peruano
as como resoluciones ministeriales.
Para una buena gestin del ciclo de vida del software, y al tratarse de un proyecto
acadmico, se opt por el uso de una metodologa de desarrollo estandarizada. Esta fue
la metodologa RUP (Rational Unified Process) debido a que es un modelo iterativo que
se adapta de manera natural al proyecto, pero por sobretodo, debido a que los proyectos
base usaron la metodologa EUP que es la extensin de RUP.
ABSTRACT
In 2008, the Faculty of Computer Science of the Universidad Peruana de Ciencias
Aplicadas (UPC) established the virtual company Salud-able which line of business is
to elaborate information technologies for health entities. At the beginning, the company
had been dedicated to the study of the processes of level I-3 health centers of the
Ministry of Health of Peru. There were identified three macro processes: strategic,
support and assistential.
The first project was Modelamiento de Procesos Empresariales para una Entidad
Mdica de Nivel I-3 de Complejidad that investigated the assistential processes of level
I-3 health centers as a result defined a software portfolio for the processes
automatization. In addition, it performed the project Arquitectura de Negocios de un
Centro de Salud de Nivel I-3 that investigated the assistencial and support processes of
the health entities.
As a consequence of the project portfolio the projects Diseo de una Arquitectura
Orientada a Servicios para un Establecimiento de Salud de Nivel I-3 de Complejidad
and Diseo de una Arquitectura de Datos para Salud de Nivel I-3 were initiated in
parallel. The first investigated the different current technologies of the software market,
they were evaluated and it concluded that the different systems should be develop with a
software oriented architecture (SOA) and make use of free tools for their
implementation. The second, established the data architecture of the business entities
identified in the health center processes.
The general object for the present project is the implementation of a system that
automate the assistential processes Atencin de Servicios Clnicos and Control de
Exmenes Mdicos of a level I-3 health center in order to solve the information
management problem of the patients.
Having as a base the previous projects in which the business processes of the health
center were defined and the architecture both software and data, can begin the execution
of the implementation activities of the project. However, because of the time elapsed
since from the first project and in order to mitigate the risk of the changes of the
processes of the health centers, we decided, as a part of the project plan, realize
reevaluation activities of conceptualization phases of the health center problems and the
development of the software and data architecture. This led to attend at least 2 health
institutions and set up meetings with the stakeholders of the studied processes, request
their documentation, consult the technique norms of the Peruvian state and ministerial
resolutions.
For the good management of the software lifecycle, and to be an academic project, we
chose to use a standard development methodology. This was the RUP (Rational Unified
Process), because it is an iterative model that adapts naturally to the project, but above
all, because it is the extension of the EUP, which has been adopted in the pre-inspection
of the projects mentioned above.
INTRODUCCIN
A continuacin, se mostrar un resumen de la organizacin del presente documento, el

cual se ha dividido en ocho captulos:
El Captulo 1 explica la descripcin del proyecto. En este acpite se detallarn las

necesidades identificadas dentro de los centros de salud de nivel I-3 en lo que respecta
al proceso de Prestacin de Servicios Clnicos y Control de Exmenes Mdicos.
Adems, se presentar el objetivo general del proyecto y se puntualizarn los objetivos
especficos del mismo en pos de dar solucin a los problemas encontrados. Se indican
tambin los indicadores de xito establecidos en el proyecto.
El Captulo 2 detalla el marco terico del proyecto. Se realiza una breve descripcin de
los conceptos utilizados y el impacto que han tenido sobre el proyecto tanto para la
gestin de las actividades, como la definicin de la arquitectura de procesos del negocio
y del software.
El Captulo 3 detalla los requerimientos del sistema, tanto funcionales como no
funcionales, identificados luego de realizar una serie de anlisis a los proyectos
anteriores, tomados como base, y; las reuniones establecidas con miembros de centros
de salud que intervienen en los procesos involucrados en el alcance del proyecto.
Asimismo, se presentarn los actores del sistema, los cuales son las personas ms
interesadas en la produccin del mismo. Adems, se presenta la interaccin que el
sistema resultado del proyecto realizar con otras aplicaciones software del Sistema
Integral de Salud.
El Captulo 4 explica las decisiones arquitectnicas tomadas en base a los
requerimientos tanto funcionales como no funcionales presentados en el captulo 3. El
resultado de este captulo es un anlisis de la propuesta del Proyecto Diseo de una
Arquitectura Orientada a Servicios para un Centro de Salud de nivel I-3 que se ha
realizado bajo el modelo de referencia SOMA, la investigacin y pruebas de concepto
realizadas en pos de establecer los patrones arquitectnicos, objetivos de los servicios
identificados y las herramientas tecnolgicas a usar para construir el sistema

SISREGAME.
El Captulo 5 explica el diseo detallado del sistema, el cual comprende los diseos de
casos de uso, los componentes de la capa de presentacin, lgica del negocio, acceso a
datos y el diseo de la base de datos.
En el Captulo 6 se describe el plan que se ha realizado para llevar a cabo la
construccin del sistema. Asimismo, se detallarn las reglas y recursos definidos para la
puesta en marcha de las actividades de desarrollo. De esta manera, se presentarn las
actividades definidas por los jefes de proyecto y desarrollo, los estndares de
programacin a seguir para los desarrolladores y administradores de la base de datos, as
como las herramientas y recursos necesarios para la produccin del sistema.
El Captulo 7 detalla los procedimientos utilizados para garantizar la calidad del
presente documento, tales como las pruebas unitarias, inspeccin de documentos y la
validacin del sistema.
El Captulo 8 trata de la gestin del proyecto, en este captulo se dar a conocer al

equipo responsable de realizar el proyecto, el proceso establecido para la administracin
del mismo y el planteamiento de las estimaciones respectivas. Adems, se detallar la
gestin de riesgos del proyecto.
El Captulo 9 describe el plan establecido para la ejecucin de las actividades de la fase
de transicin del proyecto, en el presente captulo se explica la implantacin del sistema
mediante la creacin de instaladores, manuales de usuario, manuales de desarrollo y la
publicidad que fue utilizada al finalizar el proyecto.
A continuacin, se presentan las conclusiones y recomendaciones que se identificaron al
finalizar el proyecto en el periodo 2011-01. Seguido de los anexos que se utilizaron
como referencia a lo largo del proyecto. Finalmente, se expone la bibliografa utilizada
como referencia en pos de encaminar el proyecto bajo un marco conceptual confiable y
que dan soporte a las decisiones tomadas a lo largo del ciclo de vida del proyecto.
CAPTULO 1. DESCRIPCIN DEL PROYECTO
Este captulo permite conocer el objeto de estudio y la problemtica que poseen los
centros de salud I-3 para la cual se plantear una solucin tentativa.
Introduccin
El propsito de este captulo es dar a conocer el objeto de estudio del presente proyecto,
un centro de salud de nivel I-3 de complejidad del Ministerio de Salud del Per MINSA. Brevemente se analizar el problema y se mencionarn las soluciones
desarrolladas con anterioridad para cubrir los procesos de una entidad de salud.
Asimismo, se proceder a describir la propuesta del proyecto, considerando el objetivo
general, los objetivos especficos, la metodologa que se usar y las herramientas
tecnolgicas necesarias para cumplir con los objetivos.
Objeto de Estudio
En los ltimos aos se ha podido percibir la gran influencia y aceptacin que han tenido
las tecnologas de informacin (TI) en los procesos de las organizaciones tanto privadas
como pblicas. Uno de los factores que permiten el xito de las empresas y que sus
procesos sean de calidad, es la manera eficiente de administrar uno de los activos ms
importantes, la informacin. Actualmente, esta gestin se realiza mediante el uso de
aplicaciones software que permitan acceder, procesar y analizar de manera rpida y
oportuna la informacin. De este modo, las decisiones crticas en pos del mejoramiento
de los procesos y del posicionamiento de la empresa en su mercado de accin sern
menos complejas.
El rea de la medicina humana es uno de los medios que maneja gran flujo de
informacin y las decisiones que se toman son cruciales para el tratamiento o
mejoramiento de las enfermedades de las personas. Sin embargo; en los centros de salud
del Per no existen o son obsoletos los sistemas de gestin de informacin clnica.
El Ministerio de Salud del Per o MINSA es el sector del poder ejecutivo encargado de
promover la organizacin de la oferta de los servicios de salud, facilitando el acceso
oportuno y adecuado a la poblacin1. Sin embargo, debido al crecimiento progresivo de
la poblacin peruana y su extensin a diferentes puntos del territorio nacional, el
MINSA ha ejecutado la construccin de un conjunto de establecimientos pblicos de
salud a tal nivel que el control de los mismos se ha vuelvo insostenible, al igual que la
informacin manejada en cada uno de ellos.
En el ao 2004, el MINSA estableci la Norma Tcnica de Categoras de
Establecimiento del Sector Salud (0021- MINSA). La norma tcnica determina los tipos
de establecimientos para abordar las demandas de salud de la poblacin, tomando en
cuenta las definiciones, funciones generales y unidades productoras de servicios.
Adems, la realizacin de esta categorizacin tuvo como objetivos principal
estandarizar los nombres de los establecimientos de salud en funcin de los servicios
que brinda y posicionarlos geogrficamente de acuerdo a los requerimientos de la
poblacin2.
En el ao 2008, como parte de un cambio en el plan curricular de la Facultad de
Ingeniera de Software y Sistemas de Informacin de la Universidad Peruana de
Ciencias Aplicadas UPC, surge la empresa de lnea Salud-able. Esta es una empresa
virtual que tiene como objetivo principal de negocio la investigacin, anlisis, diseo e
implementacin de soluciones innovadoras de Tecnologas de Informacin para el
sector salud en el Per. De esta manera, surge la idea de realizar una investigacin a los
procesos de un centro de salud de nivel I-3 de complejidad. Como resultado de dos aos
de investigaciones se obtuvo el modelo de negocio y los procesos asistenciales, de
apoyo y estratgicos o administrativos del centro de salud.
Cfr. MINSA 2010
Cfr. NT N0021- MINSA: 6
Figura 1.1 Mapa de Procesos

Fuente: Memoria - Arquitectura de Negocios de un Centro de Salud de Nivel I-3|
Igualmente, se obtuvo el portafolio de proyectos para poder realizar un sistema integral

para el centro de salud, as como la propuesta de una arquitectura de datos y software
basados en estndares internacionales de salud como HIPAA3. Toda esta informacin
ser considerada para la ejecucin del presente proyecto.
Dominio del Problema

Este punto tiene como objetivo analizar el problema mostrando las soluciones existentes
en el rea de salud. En base al anlisis realizado se dar una solucin que se adapte a las
necesidades del mercado peruano, los cuales cubrirn de manera efectiva la
problemtica encontrada.
The Health Insurance Portability and Accountability Estndares establecidas por el congreso de los Estados
Unidos en 1996 que definen las reglas de seguridad y privacidad para la informacin de los pacientes en un
sistema electrnico.
Anlisis del Problema

El resultado de la investigacin realizada por la empresa Salud-able acerca de los
procesos asistenciales de un centro de salud de nivel I-3 del MINSA identific seis
procesos crticos, que son los siguientes:
a) Control de Informacin de Pacientes.
b) Prestacin de Servicios Clnicos.
c) Prestacin de Servicios de Atencin de Paciente.
d) Control de Exmenes Mdicos.
e) Control de Medicamentos.
f) Prestacin de Servicios Promocin y Prevencin Comunitaria.
De los procesos crticos mencionados anteriormente el presente proyecto se enfocar en
la Prestacin de Servicios Clnicos y el Control de Exmenes Mdicos. El primero
comprende la llegada de un paciente, ya sea por primera vez o por seguimiento de un
tratamiento mdico, a una cita de consulta externa general en el centro de salud.
Adems, comprende la actualizacin del historial clnico del paciente con rdenes
mdicas. El segundo proceso comprende desde la llegada del paciente a una cita de
examen mdico hasta el registro de los resultados de exmenes de laboratorio.
Se ha detectado que en su gran mayora, los establecimientos de salud no cuentan con
sistemas informticos que permitan apoyar en la gestin de la informacin, es ms, an
se sigue llevando el control de los pacientes mediante documentos fsicos los cuales
afrontan los riesgos de prdida parcial o total debido a fenmenos naturales o errores
humanos. La informacin del historial clnico de los pacientes no es confiable, precisa,
completa, oportuna, ni est disponible para una correcta toma de decisiones por parte
del mdico. Si el mdico no cuenta con el historial clnico actualizado del paciente no
podra dar un buen diagnstico para el mejoramiento o control de las enfermedades del
paciente; peor an, al no tener en cuenta los medicamentos a los cuales el paciente es
alrgico, se podran tener resultados dainos o mortales.
El acceso al historial clnico de los pacientes, dado a que se encuentran en documentos

fsicos, toma un tiempo significativo lo que minimiza la calidad del proceso de atencin
del paciente en el centro de salud.
Es con respecto a los problemas detectados en los procesos de Prestacin de Servicios
Clnicos y Control de Exmenes Mdicos que se ha establecido al proyecto Sistema
de Registro de Atencin Mdica para un Centro de Salud de nivel I-3 de complejidad
como parte del portafolio de proyectos de la empresa Salud-able. El sistema ser
desarrollado con herramientas de cdigo libre con la finalidad de que pueda ser
accesible por las diferentes entidades de salud del Per, sin costo de licenciamiento.
Soluciones Existentes
Las investigaciones realizadas dentro de la empresa Salud-able identificaron que los

sistemas informticos y de comunicaciones para el soporte del proceso de atencin de
servicios clnicos de los establecimientos de Salud del MINSA de nivel I-3 de
complejidad, son insuficientes, obsoletos, desarticulados o inexistentes.
Cabe destacar tambin que las soluciones existentes, en su mayora, no apuntan
directamente al problema de los procesos dentro del establecimiento de salud sino tan
slo abarcan el rea administrativa de la entidad.
En adicin, existen soluciones desarrolladas por diferentes organizaciones en pos de
automatizar los procesos clnicos de la entidad de salud como por ejemplo:
Proyecto ngel4:
Sistema Integral de Administracin de la Salud gratuita, basado en entidades de
salud argentinas. Este es un sistema hospitalario, es decir, abarca todas ramas de
salud establecidas por la cartera de salud de argentina. Hoy tambin est
interactuando en la Repblica de Colombia.
Proyecto ngel: http://www.proyectoangel.net/
Tcnicamente es un sistema cliente servidor que requiere su instalacin en

cada mquina que har uso del mismo. Hoy en da la tendencia es usar
aplicaciones web debido a su facilidad de acceso y menos complejidad de
instalacin. La ventaja del proyecto ANGEL es que permite al paciente tener un
dispositivo que permitir almacenar toda la informacin de su historia clnica de
forma encriptada. Sin embargo, para tener xito con este proyecto, todas las
entidades de salud deberan tener instalada este sistema o se debera estandarizar
la encriptacin del mismo. Su lenguaje de programacin es JAVA y la base de
datos utilizada es MySql Server.
Hospital OS5:
Sistema Open Source de Informacin Hospitalaria desarrollado y financiado por
Thailand Research Fund. De igual manera este es un sistema Cliente Servidor
desarrollado en JAVA y tiene como base de datos PostgreSQL.
OpenELIS6:
Sistema Open Source de Gestin de Informacin de Laboratorio diseado y
desarrollado por Public Health Laboratories. Este sistema al igual que los dos
anteriores est desarrollado en lenguaje JAVA. La diferencia es que este
proyecto es basado en Web (No es Cliente - Servidor) lo cual facilita su acceso
por parte de los usuario.
OpenEMR7:
Sistema Open Source de Administracin de Historias Clnicas Electrnicas. Este
es un completo sistema desarrollado en JAVA y basado en Web que ha sido
certificado por Certified HIT Product List (CHPL) que es un ente coordinador y
regulador de Estados Unidos.
Hospital OS: http://www.hospital-os.com/en/
OpenELIS: http://openelis.uhl.uiowa.edu/
OpernEMR: http://www.oemr.org/
Como se puede notar, estos cuatro proyectos han tenido como objetivo colaborar con su
comunidad y, de esta manera, han desarrollado un sistema de cdigo abierto que
permita a cualquier entidad que desee gestionar la informacin de la salud de un
paciente a travs de las TI (Tecnologas de Informacin) poder contar con ella de
manera gratuita.
Estos proyectos han influenciado en que el actual proyecto decida desarrollarse con
cdigo abierto en lenguaje JAVA y gestionar la informacin mediante la base de datos
MySQL5.1. Otro factor influyente es la tendencia actual de realizar proyectos basados
en Web para permitir a los usuarios un acceso fcil y flexible para la instalacin del
sistema.
El valor agregado que se le ha dado al proyecto es de realizar un proyecto escalable y

que los mdulos sean basados en web pero a la vez manejados a travs de la tecnologa
Portlets que permite una fcil adaptacin de nuevos contenidos a travs de un
administrador de contenidos que para el proyecto actual es Liferay 5.3.2. Es decir, que
en un futuro este proyecto que es parte del Sistema Integral de Salud de la Facultad de
Ingeniera de la UPC, pueda tener ms mdulos sin la necesidad de tener que modificar
el cdigo fuente total del sistema.
Cabe resaltar que durante la investigacin realizada en el ciclo 2010-02 a los centros de
salud de nivel I-3, no se han encontrado sistemas de informacin que ayuden al registro
del historial clnico del paciente.
Planteamiento de la Solucin
En base a la problemtica descrita anteriormente se propone la solucin de un proyecto

software que permita el manejo rpido de la informacin del paciente. A continuacin
se darn a conocer los objetivos generales y especficos, los indicadores de logro, el
alcance del presente proyecto, la metodologa seleccionada y las tecnologas de
desarrollo del mismo.
Alcance del Proyecto
En un centro de salud de nivel I-3 de complejidad existen dos tipos de consulta

externa que son: Consulta Externa General8 que es toda atencin que se realice a
una persona de manera ambulatoria y es realizada por un mdico general, y la
Consulta Externa Odontolgica, la cual se realiza de la misma forma (atencin
ambulatoria), pero con un mdico especialista en esa rama de la medicina.
Para el presente proyecto se cubrirn los requerimientos que conciernen al proceso
de consulta externa general. Es decir, se desarrollar un sistema que soporte las
caractersticas bsicas y comunes de una consulta externa general, de acuerdo a lo
estipulado por el Ministerio de Salud del Per y que sea flexible y adaptable,
aplicando el re uso, a la implementacin de la especializacin de cada consulta.
El Alcance del proyecto incluir:
-
La gestin de informacin en lo que respecta a consulta externa general en un

centro de salud de nivel de complejidad I-3, la misma que asegura el
cumplimiento de los siguientes casos de uso:
Administrar Cita de Examen Mdico
Administrar Cita Mdica
Consultar Diagnstico (Caso de Uso - Extendido)
Consultar Encuentro (Caso de Uso - Extendido)
Consultar Historial Clnico (Caso de Uso - Extendido)
Consultar Orden de Examen Mdico (Caso de Uso - Extendido). Esta
consulta slo considera los exmenes mdicos de laboratorio y de
diagnstico por imgenes ya que son los bsicos definidos en el
formato del MINSA.
Consultar Orden de Medicamentos (Caso de Uso - Extendido)
Consultar Orden de Traslado (Caso de Uso - Extendido)
Cfr Mazotti, Modelamiento de Procesos Empresariales para una Entidad Mdica de Nivel I-3 de Complejidad.
Consultar Prescripcin (Caso de Uso - Extendido)

Obtener Informacin del Paciente (Caso de Uso - Incluido)
Obtener Medicamentos (Caso de Uso - Incluido)
Registrar Diagnstico (Caso de Uso - Extendido)
Registrar Encuentro Mdico.
Registrar Episodio Mdico.
Registrar Orden de Examen Mdico (Caso de Uso - Extendido). El
registro de la orden slo considera los exmenes mdicos de
laboratorio y de diagnstico por imgenes ya que son los bsicos
definidos en el formato del MINSA.
Registrar Orden de Medicamentos (Caso de Uso - Extendido)
Registrar Orden de Traslado (Caso de Uso - Extendido)
Registrar Prescripcin (Caso de Uso - Extendido)
Registrar Resultado de Examen Mdico del Paciente. Slo est
considerado el registro de los exmenes mdicos de laboratorio.
La integracin con el proyecto Sistema de Registro Mdico Electrnico para un

Centro de Salud de Nivel I-3.
La integracin con el proyecto Sistema de Gestin Horaria para un Centro de

Salud de Nivel I-3.
La integracin con el proyecto Sistema de Control de Farmacia para un centro

de Salud I-3
La integracin con el proyecto Sistema de Atencin Mdica Odontolgica para

un centro de Salud I-3.
El Alcance del proyecto NO incluir:

-
El mantenimiento del administrador de contenidos.
La impresin desde el sistema. Es decir, el sistema solo exportar la

documentacin requerida a travs de un archivo en formato PDF.
El registro de los resultados de exmenes de diagnstico por imgenes.
El mantenimiento del sistema una vez desplegado en el centro de salud.
La compra del hardware necesario para la implementacin del sistema.
La compra de las licencias necesarias para la implementacin del sistema.
La gestin de informacin de otro tipo de consultas mdicas.
Metodologa de Desarrollo
La determinacin acerca de qu metodologa utilizar para la gestin de un proyecto

es crtica, ya que esta servir de referencia para definir las diferentes actividades a
realizar durante la ejecucin del proyecto, as como los diferentes artefactos a
elaborar a fin de tener evidencia del porqu de las decisiones establecidas. Para esto
los jefes de proyecto realizaron actividades de anlisis del entorno laboral.
Debido a que el sistema a realizar est dirigido al sector salud del Estado Peruano y
a que el entorno en el cual se desarrolla el proyecto es un entorno acadmico, no se
puede obviar la adopcin de una metodologa que emplee las mejores prcticas de
administracin de proyectos. Adems, el tiempo con el que se cuenta para el
desarrollo del proyecto, que es de un ao, permite que se pueda adoptar una
metodologa que proponga la realizacin de una serie de artefactos que reflejen la
conceptualizacin del proyecto, sus resultados y/o toma de decisiones ejecutadas a
lo largo del ciclo de vida del mismo.
Teniendo en cuenta los factores del prrafo anterior, se decidi que el proyecto se
desarrollara bajo el modelo Rational Unified Proccess (RUP). Esta decisin fue
reforzada ya que los proyectos previos al actual adoptaron como metodologa de
desarrollo el EUP, el cual es una metodologa de desarrollo unificada empresarial y
que, adems, es una extensin de RUP.
Tecnologas de Desarrollo
Microsoft Word 2010

Se utiliz para la elaboracin de los diferentes artefactos comprendidos en el
alcance del proyecto.
Microsoft Excel 2010

Se utiliz para la elaboracin de los clculos de estimacin del proyecto y las
diferentes tablas incluidas en los artefactos elaborados.
Microsoft PowerPoint 2010

Se utiliz para la elaboracin de la presentacin del proyecto.
Adobe Reader
Para la lectura de los documentos exportados con formato PDF, a fin de
preservar la integridad del documento.
Microsoft Project 2010

Se utiliz para el seguimiento y control del plan de tareas establecidas para el
cumplimiento del proyecto.
Tortoise SVN 1.7

Herramienta que se utiliz para el control de versiones de los diferentes
artefactos del proyecto. Gracias a esta herramienta se tuvo un repositorio
comn (el repositorio utilizado fue el brindado gratuitamente por www.xpdev.com) que permiti tener la informacin actualizada, segura y disponible las
24 horas los siente das a la semana.
StarUML9
Herramienta que se us para el modelado visual basado en UML. Sirvi para
la elaboracin de los Diagramas de Casos de Uso, diagramas de despliegue,
diagrama de entidades y clases.
NetBeans 6.7.110
Se utiliz como herramienta principal de desarrollo NetBeans 6.7.1 con
lenguaje Java, utilizando el Java Development Tool (JDK 6 Update 22). Este
IDE posee herramientas que permiten la construccin de portales web
cumpliendo con la especificacin WSRP v2.0 y Portlet v2.0.
MySql 5.111
StarUML: http://staruml.sourceforge.net/en/
10
NetBeans: http://netbeans.org/community/releases/67/
Es un sistema de gestin de bases de datos relacionales (SGBD), capaz de

poner a disposicin de muchos usuarios grandes cantidades de datos de
manera simultnea, as como de tener unas ventajas que ms abajo se
describen. Esta herramienta albergar tanto la base de datos del Sistema de
Registro de Atencin Mdica y, adems contiene la base de datos de la
herramienta de administracin de contenidos Liferay 5.2.3.
Liferay 5.2.312
Herramienta que permitir la administracin de los portlets resultado de la
construccin del proyecto.
Glassfish v2.213
Permite gestionar la calidad y seguridad de la comunicacin de los sistemas
legacy del sistema salud a travs de servicios. Permite definir los patrones
arquitectnicos para la correcta comunicacin de los sistemas.
Bizagi14
Herramienta que sirve para la elaboracin de los diagramas de flujo
concernientes a los procesos de prestacin de servicios clnicos y control de
exmenes mdicos. Mediante esta se describen las diferentes actividades,
actores y relaciones para el cumplimiento del proceso.
Objetivos del Proyecto
Objetivos Generales
Implementar un producto software que automatice:
11
MySQL: http://dev.mysql.com/downloads/mysql/
12
Liferay: http://www.liferay.com/products/liferay-portal/overview
13
Glassfish: https://open-esb.dev.java.net/Downloads.html
14
BizAgi: http://www.bizagi.com/index.php?option=com_content&view=article&id=95&Itemid=107&lang=es
1. El proceso de atencin de una consulta externa general ambulatoria, y

que se ajuste a las normas estipuladas por el Ministerio de Salud del Estado
Peruano para un centro de salud de nivel de complejidad I-3.
2. El proceso de atencin de realizacin de exmenes mdicos de
laboratorio.
Objetivos Especficos
OE1 - Elaborar una solucin software de calidad que permita:

a) Activar y finalizar la cita del paciente para su atencin mdica en consulta
externa general.
b) Activar y finalizar la cita del paciente para su atencin en la realizacin de
exmenes mdicos.
c) Gestionar episodios mdicos de acuerdo a las normas del Ministerio de
Salud15.
d) Registrar los datos de un encuentro de consulta externa general entre el
paciente y el mdico as como su evolucin (anexados en el episodio
mdico) durante el proceso de tratamiento mdico.
e) Registrar los resultados de exmenes mdicos de laboratorio.
f) Registrar una orden mdica para el paciente que puede ser de tipo: receta
mdica, orden de traslado y orden de examen de laboratorio.
g) Consultar el historial clnico del paciente.
OE2 - Establecer comunicacin con los sistemas relacionados para exponer y
solicitar datos que permita que cada uno cumpla con el flujo natural de su proceso.
OE3 - Despliegue de la aplicacin del producto software dentro del servidor de
aplicaciones que se encuentra alojada en el establecimiento de la UPC.
Indicadores de Logro
Para el presente proyecto se han definido los siguientes indicadores de logro. Estos
indicadores fueron presentados y aprobados por el comit de proyectos que dieron el
kick off del proyecto.
15
Cfr. Identificacin estndar de dato en salud N006
I1. OE1. Documento de Aprobacin por parte de la empresa QA y/o a quienes

designe el comit de proyecto sobre el correcto funcionamiento y la calidad del
producto de software.
I2. OE1. El proyecto Sistema de Registro de Atencin Mdica para un centro de
salud de nivel I-3 se encuentra culminado y comprende:
o El CD final del producto de software
o La documentacin relacionada a la solucin.
I3. OE2. El proyecto se integra correctamente con el proyecto Sistema de Registro
Mdico Electrnico para un centro de Salud de Nivel I-3
I4. OE2. El proyecto se integra correctamente con el proyecto Sistema de Gestin
Horaria para un Centro de Salud de Nivel I-3
I5. OE2. El proyecto se integra correctamente con el proyecto Sistema de control
de Farmacia para un centro de Salud I-3
I6. OE2. El proyecto se integra correctamente con el proyecto Sistema de
Atencin Mdica Odontolgica para un centro de Salud I-3
I7. OE3. Documento de Aprobacin por parte de la empresa IT Expert y/o a
quienes designe el comit de proyecto sobre el correcto despliegue del producto.
En este primer captulo, se ha realizado una introduccin del objeto de estudio del
proyecto, es decir la conceptualizacin del problema, objetivos y alcance. Previamente,
para realizar esta introduccin se tuvo que realizar un anlisis de proyectos anteriores
que investigaron acerca de los procesos que se realizan en un centro de salud de nivel I3. Se ejecutaron entrevistas con los actores que, principalmente, desempean un rol en
los procesos de Prestacin de Servicios Clnicos y Control de Exmenes Mdicos que
son los que se automatizarn y, el objetivo general del proyecto.
Dado que el resultado del proyecto estaba enfocado al lanzamiento de un producto

software que cumpla con los requerimientos de los procesos en estudio, no se pudo ser
ajeno a sistemas ya existentes que cumplan con procesos clnicos. De esta manera, se
ejecut una bsqueda de proyectos que hayan tenido los mismos objetivos y, en base
estos se lograron definir las herramientas que se utilizaron y el tipo de sistema a
desarrollar.
Por ltimo, ya definido el objeto de estudio y teniendo en claro las herramientas a

utilizar se defini la metodologa de referencia a utilizar para la administracin del
proyecto. La metodologa que por la naturaleza del proyecto se utiliz fue Rational
Unified Proccess (RUP) que ayud a la generacin de artefactos que sean evidencia de
las actividades realizadas en el proyecto y de las decisiones crticas tomadas en pos del
alcance de los objetivos del mismo.
CAPTULO 2. MARCO TERICO
Este captulo permite conocer las bases conceptuales que apoyaron la resolucin del
proyecto.
Introduccin
El propsito de este captulo es dar a conocer los conceptos utilizados para la
realizacin del proyecto que han apoyado a la culminacin exitosa del mismo.
Marco Terico
Ministerio de Salud - MINSA

El MINSA (Ministerio de Salud) es el ente gubernamental que administra la
prestacin de servicios de salud para la poblacin, el cual tiene como misin la
proteccin de la dignidad de la persona, promover la salud y la prevencin de las
enfermedades asegurando la atencin integral de salud a todas las personas del
pas.
Modelo de Atencin Integral de Salud - MAIS

El MINSA como parte del sexto lineamiento del artculo 13 del Acuerdo
Nacional Poltica Acceso Universal a los Servicios de Salud y a la Seguridad
Social ha establecido un Modelo de Atencin Integral de Salud MAIS que es el
marco conceptual de referencia que define el conjunto de polticas,
componentes, sistemas, procesos e instrumentos, que operando coherentemente,

garantizan la atencin a la persona para satisfacer sus necesidades de salud.
Categoras de Establecimientos del Sector Salud

El Modelo de Atencin Integral de Salud indica como parte de sus objetivos
principales el beneficiar a la poblacin a travs de la entrega de servicios de
salud con equidad, transparencia, calidad y calidez, eficiencia y eficacia.
Adems, se indica que se debe contar con una adecuada organizacin de la
oferta de los servicios de salud y que esta debe ser configurada en funcin de las
necesidades de salud de la persona, familia y comunidad para satisfacerla de
manera integral en trminos cualitativos y cuantitativos.
Por consiguiente, el MINSA, en aras de cumplir el modelo integral y evitar la

confusin de la poblacin con respecto de las denominaciones de los
establecimientos de salud que, adems, no permite un adecuado sistema de
referencia y contrareferencia, ha definido los procesos de desarrollo de Redes y
Microrredes, la categorizacin de establecimientos de salud y la organizacin
del sistema de referencia y contrarreferencia. Estos se encuentran definidos en la
Norma Tcnica NT N 0021 MINSA / DGSP v.01.
Categora
Tipo de establecimientos de salud que comparten funciones, caractersticas y
niveles de complejidad comunes, las cuales responden a realidades
sociosanitarias
similares
estn
diseadas
para
enfrentar
demandas
equivalentes. Es un atributo de la oferta, que debe considerar el tamao, nivel

tecnolgico, y la capacidad resolutiva cualitativa y cuantitativa de la oferta.
Nivel de Complejidad
Es el grado de diferenciacin y desarrollo de los servicios de salud, alcanzado
merced a la especializacin y tecnificacin de sus recursos. El nivel de
complejidad guarda una relacin directa con las categoras de establecimientos
de salud.
Nivel de Atencin
Conjunto de Establecimientos de Salud con niveles de complejidad necesaria
para resolver con eficacia y eficiencia necesidades de salud de diferente
magnitud y severidad. Constituye una de las formas de organizacin de los
servicios de salud, en la cual se relacionan la magnitud y severidad de las
necesidades de salud de la poblacin con la capacidad resolutiva cualitativa y
cuantitativa de la oferta. Este tipo de organizacin, se sustenta en la
comprobacin emprica de que los problemas de salud de menor severidad
tienen mayor frecuencia relativa que los ms severos, y viceversa. Es as que de
acuerdo al comportamiento de la demanda, se reconocen tres niveles de
atencin:
Nivel de Atencin I: Es el nivel de atencin ms bajo donde la

complejidad de las enfermedades es baja, no posee un gran tamao de
especializaciones. En este tipo de centro de salud principalmente
realizan actividades de promocin, proteccin especfica, diagnstico
precoz y tratamiento de enfermedades frecuentes.
Este nivel de atencin se subdivide en cuatro categoras.
I-1: Puesto de salud.

I-2: Puesto de salud con mdico.
I-3: Centro de salud sin internamiento.
I-4: Centro de salud con internamiento.
Nivel de Atencin II: Como todos los niveles, este nivel tambin se
enfoca en la promocin, proteccin especfica, diagnstico precoz y
tratamiento de enfermedades frecuentes, sin embargo, este nivel s
brinda servicios de atencin ambulatoria especfica o que requiera
hospitalizacin, estos pacientes pueden ser derivados del primer nivel
de atencin o que ingresen por emergencias.
Este nivel de atencin se subdivide en dos categoras.
II-1: Hospital I. Esta categora solo posee cuatro especialidades, la

cuales son medicina interna, ginecologa, pediatra y anestesiologa.
II-2: Hospital II. Esta categora se enfoca en la recuperacin y
rehabilitacin de los pacientes.
Nivel de Atencin III: Como todos los niveles, este nivel tambis se
enfoca en la promocin, proteccin especfica, diagnstico precoz y
tratamiento de enfermedades frecuentes, sin embargo, este nivel es a
nivel nacional y se tratan problemas patolgicos complejos.
Este nivel de atencin se subdivide en dos categoras.
III-1: Hospital III. Esta categora adems de lo que posee las

anteriores
posee la
Unidad de Cuidados
Intensivos
(UCI),
hemodilisis y diagnsticos especializados.

III-2: Instituto especializado. Esta categora se especializa segn el
rea de salud correspondiente, docencia e investigacin.
Tabla 2.1- Categorizacin de Establecimientos del MINSA
Fuente: Norma Tcnica N 021 MINSA / DGSP v.1
Centros de Salud de Categora I-3

Este tipo de centros de salud pertenecen al primer nivel de atencin en su tercer
nivel de complejidad. Para el Ministerio de Salud su denominacin es Centro
de Salud sin Internamiento. Su cobertura de accin corresponde a una
poblacin y territorio asignado y adems se le ha establecido como una entidad
referencial, y es a donde el puesto de salud con mdico hace referencia.
Pertenece a una microred de salud.
El equipo de salud que labora en estos centros de salud debe estar conformado
como mnimo de:
- Mdico Cirujano o Mdico Familiar.

- Enfermera.
- Obstetra.
- Tcnico o Auxiliar de Enfermera.
- Estomatlogo.
- Tcnico de Laboratorio.
- Tcnico de Farmacia.
- Tcnico o Auxiliar de Estadstica.
Las funciones generales que tiene este tipo de centros de salud son las siguientes
y son las mismas con las que cuenta la categora I-2:
a. Promocin de la Salud. El centro de salud debe establecer planificar y

organizar actividades en pos de la satisfaccin de las necesidades de
salud de la poblacin as como tambin de sus expectativas.
b. Prevencin de Riesgos y Daos. Debe realizar actividades de control
epidemiolgico del sector. Adems debe realizar actividades de
prevencin de enfermedades inmunoprevenibles prevalentes. Vigilar y
control de complicaciones obsttricas, mortalidad materna y perinatal.
Prevenir disfunciones familiares y violencia social.
c. Recuperacin de la Salud. Se debe atender y tratar los problemas de salud

ms concurrentes de la poblacin en el mbito jurisdiccional y
referencial. Atencin de emergencias y manejo y referencia de los
mismos segn sea el nivel de complejidad.
d. Rehabilitacin de la Salud. Identificar al grupo de personas que presentan
discapacidad en su territorio referencial y plantear programas para su
rehabilitacin.
e. En lo gerencial,
A cargo del responsable del establecimiento de salud.
Administrar la ejecucin de las actividades programadas del centro

de salud.
Ejecutar actividades de capacitacin del personal de labores del

centro de salud.
Registro, procesamiento y anlisis de los problemas de salud.
Llevar un control de la tasa de mortalidad del sector.
Implementar el sistema de referencia y contrareferencia.
Unidades Productoras de Servicios.
Salud Comunitaria y Ambiental. Actividades de tratamiento y

prevencin de enfermedades de la poblacin del territorio referencial.
Consulta Externa. Se realizan consultas con un Medico General lo

que lo convierte en una consulta ambulatoria y para esto se requiere
infraestructura oportuna para ejecutar esta actividad. Adicionalmente,
se prestan consultas externas odontolgicas para lo cual tambin se
requiere infraestructura y materiales para una atencin oportuna y de
calidad.
Farmacia/Botiqun. Sector del establecimiento donde se realiza la

dispensacin de medicamentos que debe contar con tcnicos
farmacuticos supervisados por un qumico farmacutico de la
microred.
Patologa Clnica (Laboratorio Clnico). rea funcional donde se

realiza la toma, recepcin, procesamiento o envo de las muestras de
sangre o fluidos corporales y emisin de resultados de los exmenes

o ensayos del paquete bsico correspondiente al Laboratorio Local.
Adems, de las unidades productoras de servicios descritas. El establecimiento

de salud realiza las siguientes actividades.
Atencin de Parto. Para casos de partos urgentes y atencin principal

del recin nacido.
Esterilizacin. No se cuenta con un servicio organizado pero se deben

desinfectar y esterilizar los materiales quirrgicos por mtodos
fsicos y qumicos.
Emergencia.
Nutricin y Diettica. Prevencin y promocin de actividades para

mejorar la situacin nutricional de la poblacin.
Trabajo Social.
Jefatura.
Administracin de Servicios Generales.
Historia Clnica.
Definicin
Es el documento mdico legal, que registra los datos, de identificacin y de los

procesos relacionados con la atencin del paciente, en forma ordenada,
integrada, secuencial e inmediata de la atencin que el mdico u otros
profesionales brindan al paciente.
El historial clnico y dems registros mdicos, son material de alto valor mdico
tanto gerencial, legal y acadmico. Es necesaria una oportuna gestin del mismo
ya que, de esta manera, se contribuye directamente a mejorar la calidad del
servicio de atencin de pacientes.
La correcta administracin de la historia clnica permite optimizar la gestin de

los establecimientos de salud, proteger los intereses legales del paciente, del
personal de salud y del establecimiento, as como brindar informacin con fines
de investigacin y docencia.
El ministerio de salud ha establecido la Norma Tcnica del historial clnico de

los establecimientos del sector salud N.T. N 022-MINSA/DGSP-V.02.
Los objetivos de la norma tcnica de la historia clnica son los siguientes:
1.
Establecer las normas y procedimientos para la administracin y gestin

de la Historia Clnica a nivel del sector salud.
2.
Estandarizar el contenido bsico de la Historia Clnica para garantizar un

apropiado registro de la atencin de salud.
El MINSA ha establecido un conjunto de formatos de encuentros mdicos en

funcin de la etapa de vida del paciente. Las etapas de vida se consideran en el
primer nivel de atencin y son las indicadas en el MAIS, etapa del nio,
adolescente, adulto y adulto mayor.
Formatos
Niveles
de
Atencin
Etapas de Vida
Tipo de Prestacin
Consulta Externa
Primer Nivel:
Consulta
Adulto
Externa
Hospitalizacin
Emergencia
Nio
Adolescente
Adulto
I1
I2
I3
I4
Mayor
Segundo Nivel:
II 1
II 2
Tercer Nivel:
III 1
III 2
Tabla 2.2 Formato de la historia clnica segn niveles de atencin

Fuente: N.T. N 022-MINSA/DGSP-V.02
La informacin necesaria y que ser registrada en el formato de encuentro

mdico del paciente son los siguientes:
FORMATO DE ATENCIN INTEGRAL DEL NIO
El Formato de la primera atencin, contendr como mnimo:
Fecha
N de Historia Clnica
Datos generales: apellidos y nombres, sexo, edad, fecha de nacimiento,

lugar de nacimiento, procedencia, grado de instruccin, centro educativo,
grupo sanguneo y factor Rh, nombre, edad, DNI de la madre, padre,
acompaante o cuidador.
Antecedentes
personales:
antecedentes
perinatales,
patolgicos,
alimentacin.
Antecedentes familiares
Esquema de vacunacin
Vigilancia del crecimiento y desarrollo.
Datos en el triaje: signos vitales, descarte de signos de alarma.
Anamnesis: motivo de consulta, forma de inicio, tiempo de enfermedad.
Preguntas sobre problemas frecuentes en la infancia.
Evaluacin sobre la alimentacin actual.
Examen fsico
Diagnstico, incluyendo diagnstico nutricional
Tratamiento
Exmenes auxiliares
Referencia si fuera el caso
Fecha de prxima cita
Firma, sello y colegiatura del profesional que presta la atencin
La evolucin, debe contener los siguientes puntos, que son los mismos
para todos los formatos por etapas de vida:
Fecha y hora
Edad
Motivo de consulta
Tiempo de enfermedad
Funciones biolgicas
Examen fsico
Diagnstico
Tratamiento
Exmenes auxiliares
Hoja de lista de problemas y Plan de Atencin Integral
FORMATO DE ATENCIN INTEGRAL DEL ADOLESCENTE
Fecha
Datos generales: apellidos y nombres, sexo, edad, fecha de nacimiento,

lugar de nacimiento, procedencia, grado de instruccin, centro educativo,
estado civil, ocupacin, grupo sanguneo y factor Rh, nombre, edad, DNI
de la madre, padre o acompaante o cuidador.
Antecedentes personales: perinatales, crecimiento, desarrollo, vacunas,

patolgicos
Antecedentes psicosociales
Salud sexual y reproductiva
Motivo de consulta
Funciones biolgicas
Examen fsico
Diagnstico
Tratamiento
Exmenes auxiliares
Hoja de seguimiento de factores de riesgo
FORMATO DE ATENCIN INTEGRAL DEL ADULTO
Fecha
Datos generales: apellidos y nombres, sexo, edad, DNI, fecha de

nacimiento, lugar de nacimiento, procedencia, grado de instruccin,
estado civil, ocupacin u oficio, grupo sanguneo y factor Rh, nombre,
DNI del acompaante.
Antecedentes personales
Alergia a medicamentos
Sexualidad
Motivo de consulta
Funciones biolgicas
Examen fsico
Diagnstico
Tratamiento
Exmenes auxiliares
Hoja de seguimiento de factores de riesgo: diferenciada por sexo
FORMATO DE ATENCIN INTEGRAL DEL ADULTO MAYOR
Fecha
Datos generales: apellidos y nombres, sexo, edad, DNI, fecha de

nacimiento, lugar de nacimiento, procedencia, grado de instruccin,
estado civil, ocupacin grupo sanguneo y factor Rh, nombre, edad , DNI
y parentesco del familiar o cuidador responsable.
Antecedentes personales y familiares
Alergia a medicamentos
Valoracin geritrica: valoracin funcional, estado cognitivo, estado

afectivo, estado socio-familiar.
Categoras del adulto mayor
Motivo de consulta
Funciones biolgicas
Examen fsico
Diagnstico
Tratamiento
Exmenes auxiliares
Hoja de seguimiento de factores de riesgo
Historia clnica en el Proyecto
Debido que el alcance del proyecto son los establecimientos de salud de nivel I3, la arquitectura de datos definida para el sistema contempla los formatos de
atencin integral. Se definieron en base a la edad del paciente formularios web
que permiten el ingreso de datos que sern registrados como parte del encuentro
mdico.
Cabe indicar que el proyecto base Modelamiento de una arquitectura de datos
para un centro de salud de nivel I-3 no consider estos formatos de atencin y
tenan un formato nico para todos los pacientes. Sin embargo; se tom la
decisin de modificar la arquitectura dado a que es parte de los lineamientos
establecidos por el MAIS.
Rational Unified Proccess (RUP)
Definicin
RUP es una metodologa de procesos para proyectos de software que ha sido

resultado de juntar diferentes enfoques (mejores prcticas corroboradas en
empresas exitosas) en pos de mejorar de forma regular los procesos de desarrollo.
RUP no es una metodologa rgida que obliga a seguir actividades especficas. Por
el contrario; es una metodologa adaptable a las necesidades del proyecto o

empresa que en conjuncin con el modelo de lenguaje unificado (UML)
constituye una metodologa estndar para el desarrollo de sistemas orientada a
objetos.
Esta metodologa propone un desarrollo iterativo incremental, es decir el proyecto

se divide en pequeos ciclos (iteraciones) en donde cada uno desencadena en el
lanzamiento de ejecutables que permiten el anlisis de la concordancia entre los
requerimientos, el diseo, el desarrollo y la implementacin del sistema.
RUP define 4 fases para el ciclo de vida del software que son los siguientes:
FASE DE INICIO O CONCEPCIN

En esta fase se identifican y analizan los problemas del negocio y se traducen
en requerimientos.
FASE DE ELABORACIN
Durante esta fase se ejecutan actividades de definicin, anlisis y diseo de la
arquitectura del software y datos en base a los requerimientos identificados en
la fase anterior. La arquitectura ser la base para la construccin del software.
FASE DE CONSTRUCCIN
Durante esta fase de construccin se ejecutan las actividades de construccin
del sistema. En general; en esta fase se lleva a cabo ms de una iteracin y cada
una de ellas tiene establecido el cumplimiento de una serie Casos de Uso.
FASE DE TRANSICIN
Durante esta fase de transicin se desarrollan las actividades de despliegue del
producto final y significa que el producto cumple con los requisitos de
aceptacin del usuario para la puesta en produccin del mismo.
RUP comprende 2 aspectos importantes por los cuales se establecen las

disciplinas:
Proceso: Las etapas de esta seccin son:
Modelado de negocio
Requisitos
Anlisis y Diseo
Implementacin
Pruebas
Despliegue
Soporte: Las disciplinas de este aspecto son:
Gestin del cambio y configuraciones
Gestin del proyecto
Entorno
Artefactos
Para cada fase de RUP se han propuesto una serie de artefactos que apoyan para
los miembros del equipo comprendan tanto el anlisis como el diseo del
sistema. Por ejemplo se cuenta con los siguientes artefactos:
Fase
Artefacto
Documento de Visin
Inicio o Concepcin
Especificacin de Requerimientos del

Software SRS
Elaboracin
Construccin
Tabla 2.3 Artefactos de Software
Fuente: Elaboracin Propia
Diagramas de casos de uso

Documento
Software SAD
de
Arquitectura
del
Figura 2.1 Ciclo de Vida del software

Fuente: http://www.ibm.com
RUP en el proyecto
Para elegir la metodologa de desarrollo para el proyecto actual se analizaron

diferentes aspectos que llevaron a elegir el Proceso Unificado de Rational RUP.
Los factores tomados en cuenta fueron los siguientes.
Escenario del Proyecto: En la definicin de RUP se indica que esta metodologa

se utiliza cuando las caractersticas del proyecto involucran un alto grado de
complejidad tcnica y mayor complejidad de gestin. El sistema est orientado a
una entidad de salud y debe contar con un alto rendimiento operativo. Adems, los
interesados son todos los mdicos de estos establecimientos ya que se va
administrar la informacin de los pacientes.
El proyecto fue de carcter acadmico en donde se debi poner en prctica los

conocimientos adquiridos a lo largo del sendo universitario. Por ende; este factor
es significativo a tomar en cuenta para utilizar esta metodologa.
Figura 2.2 Cuando usar RUP

Fuente: Rational Unified Proccess
Administracin de Requerimientos: Los requerimientos son las condiciones o

capacidades que el producto software debe contener. Los requerimientos deben
ser hallados, documentados, organizados y monitoreados; ya que estos son
cambiantes en el tiempo. RUP propone que en su primera fase se identifique estos
requerimientos y sean definidos, documentados y aprobados por los interesados
del sistema. Posteriormente estos requerimientos debern ser priorizados y
monitoreados para poder determinar o detectar las posibles inconsistencias que el
sistema presente.
Mediante los documentos de Casos de Uso utilizadas en RUP se realiza una

excelente forma de capturar los requerimientos funcionales y adems se asegura
que el diseo, implementacin y las pruebas se encuentran correctamente

orientados, para lograr as la satisfaccin de las necesidades del usuario.
Proyectos Previos de Salud-@ble: Las investigaciones realizadas por proyectos

anteriores en donde se analiz a profundidad los procesos dentro de los centros de
salud de nivel I-3 utilizaron la metodologa EUP (Enterprise Unified Proccess)
que es una variante extendida de la metodologa RUP; por ende el proyecto, dada
su envergadura, encaja de forma natural con esta metodologa.
Tiempo: Para el cumplimiento del plan curricular de la carrera de Ingeniera de

Software se deben completar 2 cursos que son Taller de Proyectos I y II lo cual
permiti que el proyecto se desarrolle durante la duracin de ambos cursos que
son 2 ciclos (9 meses aprox.). Tiempo adecuado para poder utilizar una
metodologa robusta como RUP.
El detalle de las fases e hitos desarrollados en el proyecto se encuentra en el

captulo de Gestin del Proyecto.
Business Proccess Management (BMP)
Definicin
El BPM o Administracin de Procesos del Negocio tiene como objetivo principal

reflejar de manera transparente las actividades que se realizan del negocio y en
base a estos proponer mejoras continuas o adaptarse a los nuevos cambios en la
empresa.
Los procesos dentro de una empresa deben pasar por diferentes etapas o fases,
estas son:
Disear: Consiste en la identificacin de los procesos que se realizan dentro de

una organizacin o los nuevos cambios que se desean ejecutar.
Modelar: En esta etapa se introduce mediante una notacin de gestin de

procesos del negoci las actividades identificadas en la fase previa.
Ejecutar: Se implementan los sistemas para cumplir con los procesos modelados
y que requieren automatizacin.
Monitorear: Consiste en seguimiento individual de los procesos para identificar

problemas como posibles cuellos de botella o deficiencias por parte del sistema
que requieren ser mejorados.
Optimizar: Esta fase consiste en optimizar o mejorar actividades deficientes o

que se ha identificado que siendo buenos se puede mejorar an ms, en pos de
bsqueda de la reduccin de costos de la empresa y aumentar sus fortalezas y
oportunidades para su mejor posicionamiento en el mercado.
BMP en el proyecto
En la empresa Salud-@ble se ejecut un proyecto denominado Modelamiento de

Procesos Empresariales para una Entidad Mdica de Nivel I-3 de Complejidad en
donde se modelaron los procesos de tipo Prestacin de Servicios Ambulatorios
de estos centros de salud y adems se estableci la cartera de proyectos en donde
el actual proyecto forma parte.
Sin embargo; en busca de la mejora continua y tomando en cuenta el tiempo

transcurrido desde la definicin del modelo del proyecto anterior, se decidi iniciar
actividades de re investigacin en lo que concierne a los proceso de Prestacin de
Servicios Clnicos y Control de Exmenes Mdicos. Como resultado de la investigacin
se obtuvo que el modelo del negocio que exista era tal cual el proceso de ese entonces y
que no fue orientada a la automatizacin de los procesos mediante un producto
software. Por ende se decidi ejecutar una correccin al proceso los cuales se ven
reflejados en el captulo de Requerimientos del Software y en base de los cuales se
dise la arquitectura del sistema a implementar. Para modelar el proceso se hizo unos
de la herramienta BizAgi Proccess Modeler que es una aplicacin que permite aplicar la
notacin para la gestin de procesos del negocio BPMN (Business Proccess
Management Notation).
Service Oriented Architecture (SOA)
Definicin
Arquitectura Orientada a Servicios es un concepto por el cual se hacen uso de

servicios web para el cumplimiento de los procesos del negocio de una
organizacin. Mediante el diseo de una arquitectura SOA se asegura la
implementacin de un producto software escalable. En adicin, SOA involucra el
concepto de orquestacin que es la organizacin de la invocacin de los servicios
web para el procesamiento de datos. De acuerdo a los cambios en los procesos se
puede variar la orquestacin de estos servicios por lo cual se sustenta la
flexibilidad de esta arquitectura.
Arquitectnicamente, SOA define nueve capas que estn diseadas para

robustecer su valor empresarial. Para cada capa se han definidos dos etapas que
enfocan 2 aspectos que son el lgico y el fsico.
El aspecto lgico, incluye todos los aspectos arquitectnicos, decisiones de

diseo, KPI (Key Process Indicator) y similares que van alineadas al negocio.
El aspecto fsico, comprende en realizar las decisiones tomadas en el aspecto

lgico utilizando las tecnologas y productos software.
Las capas de SOA establecen una interaccin pero no necesariamente la

comunicacin se realiza entre las capas inmediatas.
Figura 0.1 Capas de SOA

Fuente:IBM SOA Foundation Architecture Overview
Operational System Layer: Capa de Sistemas Operacionales. Esta capa
considera las aplicaciones que se encuentran en produccin en una organizacin
que son conocidas como sistemas Legacy. Entre estas capas se puede contar con
sistemas CRMs, ERPs, aplicaciones de inteligencia de negocios, sistemas
orientados a objetos, etc. SOA se encargar de integrarlas a travs de los servicios.
Service Components Layer: Capa de componentes. Esta capa contiene

componentes que se encargan de la funcionalidad que exponen los servicios.
Services Layer: Capa de Servicios. Aqu residen los servicios que la empresa ha
decidido exponer. Pueden ser expuestos directamente, o ser parte de una
orquestacin o de un servicio que referencia a otro (compuesto). Los servicios
exponen funcionalidades y hacen uso contratos que permiten invocar los
componentes de negocio que se encuentran en la capa anterior.
Business Procces Layer: Capa de Procesos del Negocio. En esta capa se forman
las composiciones y orquestacin de servicios que responden a los procesos del
negocio (workflows). En esta capa se usan herramientas visuales para construir
los flujos de trabajo tales como el diseador de orquestacin.
Consumer Layer: Cpar del consumidor. Esta capa es la que provee a los usuarios
las funcionalidades de IT. En general, las aplicaciones son invocadas a travs de
las capas de presentacin de aplicaciones de terceros.
Integration Layer: Capa de integracin. Esta capa provee la capacidad de

mediacin, la ruta y las solicitudes de servicio de transporte del solicitante del
servicio con el proveedor de servicio correcto a travs de un ESB (Enterprise
Service Bus).
QoS Layer: Capa de aseguramiento de la calidad. Provee las realizaciones de los

requerimientos no funcionales del negocio.
Information Architecture Layer: Capa de informacin de la arquitectura. Es la

capa que se encarga de la arquitectura de datos. Se ejecutan actividades de
anlisis, modelamiento y diseo de la data de forma tal que sea escalable en el
tiempo.
Governance Layer: Capa de gobierno. En esta capa se abarcan los aspectos de

vida operativa de gestin del ciclo de SOA. Como todo proceso se debe
monitorear, controlar y mejorar los procesos. Los indicadores apoyarn en la toma
de decisiones acerca de la arquitectura SOA y la gestin de todos los aspectos de
una solucin de SOA, incluyendo la capacidad, disponibilidad, rendimiento y
seguridad.
SOA en el proyecto
En la empresa Salud-@ble se llev a cabo el proyecto denominado Diseo de

una arquitectura orientada a servicios para un establecimiento de salud de nivel I3 de complejidad. Este se encarg de la investigacin y pruebas de concepto
acerca de la arquitectura SOA.
Se analizaron los resultados de esta investigacin y el resultado se document en

el documento SAD (Documento de arquitectura del software) propuesto por RUP.
Sin embargo, la plantilla usada fue la proporcionada por el Ing. Ilver Pupo
Anache, profesor del curso de arquitectura de software de la UPC. Este es un
documento adaptado a la arquitectura SOA.
Como parte de las decisiones tomadas por el proyecto anterior con respecto al uso
de un ESB (Bus de Servicios), se acord que era innecesario para el alcance del
proyecto debido a que no existe ningn sistema Legacy en este tipo de entidades
de salud (actualmente toda la informacin se maneja de manera manual). Todos
los proyectos de software que se ejecutaron hasta el momento en la empresa
Salud-@ble poseen un mismo lenguaje de programacin JAVA. Por ende; los
sistemas que se estaban desarrollando anteriormente se comunicaran a travs de
la exposicin de servicios y stos seran consumidos directamente.
Como consecuencia de esta decisin el servidor Tomcat sera innecesario, ya que

se propuso como solucin por la compatibilidad con el Intalio/Server el cual se
encargara de la coreografa de los servicios. El servidor seleccionado entre los
jefes de proyectos es el Glassfish a que se adapta de forma natural con el servidor
de contenidos utilizado en el proyecto.
Desde la culminacin del proyecto previo hasta la iniciacin del proyecto actual la
empresa ORACLE ejecut el proceso de compra de la empresa Sun
MicroSystems, por ende la herramienta propuesta para la implementacin del
portal web Sun GlassFish Web Space Server 10 fue descartada dado a que fue
puesta en tela de juicio el uso libre de la herramienta y se decidi el uso de la
herramienta Liferay Portal 6. Otro motivo por el cual se eligi esta herramienta
son los requerimientos mnimos en cuanto a memoria RAM, mientras que
Sun GlassFish Web Space Server 10 necesita un mnimo de 3GB, el Liferay
Portal 6 necesita 1 GB, dado ello se produce una reduccin de costos en cuanto a
la adquisicin del servidor de aplicaciones por el Ministerio de Salud.
Los servicios se implementaron en base de los procesos de negocio definidos en el

captulo de requerimientos de software que fueron modelados considerando la
automatizacin de los procesos de prestacin de servicios clnicos y control de

exmenes mdicos.
Disposiciones del Ministerio de Salud
Especificaciones Tcnicas Mnimas para Sistemas Informticos en el Ministerio de

Salud
Para la implementacin del sistema de registro de atencin mdica se investig

acerca de las disposiciones del ministerio de salud con respecto al uso de sistemas
informtico. Se tomaron en cuenta las siguientes disposiciones:
Uso de Interfaces Web para el acceso de usuarios.

En el proyecto se defini que el sistema deba ser implementado orientado
en web para la mejor mantenibilidad del mismo y reducir tiempos y costos
de instalacin.
Uso de lenguajes de programacin estndares.

Para el presente proyecto se hizo uso del lenguaje de programacin
JAVA y el uso de web services para facilitar la escalabilidad del sistema.
Uso de Sistema de Gestin de Bases de Datos para el almacenamiento

de datos.
La base de datos definida para el presente proyecto fue MySql 5.1.
Intercambio de informacin entre sistemas informticos.

Para facilitar el intercambio de informacin entre los diferentes sistemas
informticos se ha establecido utilizar Web Services en una arquitectura
SOA que ser detallado en el captulo de arquitectura de software.
CAPTULO 3. REQUERIMIENTOS DEL

SOFTWARE16
El objetivo de ste captulo es presentar los requerimientos funcionales y no

funcionales del presente proyecto.
Introduccin
La identificacin de los requerimientos es un elemento importante dentro del
desarrollo del proyecto. En el siguiente acpite se dar a conocer los
requerimientos funcionales, tal como indica su nombre, indicar las
funcionalidades que debe tener el sistema. Asimismo, se darn a conocer los
requerimientos no funcionales, es decir, aquellos requisitos que restringen el
comportamiento de la aplicacin.
Requerimientos Funcionales
A continuacin se presentarn los procesos del negocio que dieron origen a los
requerimientos funcionales los cuales, a su vez, dieron origen a los casos de uso.
Asimismo, se dar a conocer a los actores del sistema, los cuales son las
personas ms interesadas en la produccin del producto software.
Procesos del Negocio
En el proyecto Arquitectura de Negocio para un Centro de Salud de Nivel I-3

se identificaron 6 procesos, de los cuales solo se desarrollarn 2 de ellos en el
16
Ver Anexo 1. Se muestra los documentos que proporciona mayor informacin acerca de los requerimientos
del sistema.
Captulo 3: Requerimientos del Software

presente proyecto; los procesos Prestacin de Servicios de Servicios Clnicos
y Control de Exmenes Mdicos. El primero contempla desde la llegada de un
paciente a una cita mdica pactada hasta la emisin de una orden mdica. El
segundo, contempla el registro de los resultados de exmenes mdicos, donde
cabe resaltar que slo se registrarn del tipo de laboratorio debido a que el
encargado de realizar los de imagenologa no posee la facultad de emitir un
resultado.
Como parte del desarrollo del proyecto se realizaron visitas a los
establecimientos de salud de Nivel I-3 de complejidad con el fin de corroborar
que los procesos no hayan cambiado con el paso del tiempo, cabe recordar que
la pre-inspeccin se realiz hace 2 aos. Como resultado de las visitas realizadas
se detect que el proceso Prestacin de Servicios Clnicos, haba sufrido
ciertos cambios para lo cual se adapt el modelo original con el proceso
encontrado. stos son los siguientes:
1. No se tom en cuenta la solicitud del historial clnico.
2. Apertura del historial clnico, en caso que el paciente no posea uno.
3. Envo del historial clnico al consultorio.
4. El mdico se encarga de auscultar al paciente, ya no lo realiza la
enfermera.
5. Registro del episodio mdico.
6. Registro de prescripcin, receta mdica, orden de traslado, orden de
examen mdico u orden de traslado, de acuerdo a lo que necesita el
paciente.
7. Se poseen 4 tipos diferentes de formatos de atencin del paciente segn
la etapa de vida: Nio, Adolescente, Adulto y Adulto Mayor.
A continuacin se mostrar el proceso con los cambios realizados.
Sistema de Registro de Atencin Mdica
Figura 3.1 Proceso de Prestacin de Servicios Clnicos

Fuente: Adaptacin propia del proceso elaborado en el proyecto Modelamiento
de Procesos Empresariales para una Entidad Mdica I-3
El proceso en mencin posee la siguiente caracterizacin.
Entrada
A
Actividad
Salida
Comprobante de Asistir a la cita
Ingreso
cita
paciente
Paciente
Pedir
ingresado
clnico
historial Solicitud
Descripcin
Responsable
del El paciente ingresa al Paciente

centro de salud.
de La enfermera solicita al Enfermera
historial
administrador
de
clnico
informacin
de
administracin
muestre
el
que
historial
clnico.
D
Solicitud
de Existe historial S / No
historial clnico
El
clnico?
operario
ADM Operario
Informacin verifica si ADM

existe
el
historial Informacin
operario
ADM Operario
clnico
E
No
existe Aperturar
historial clnico
historial clnico
Historial
El
clnico
Informacin
apertura ADM
un historial clnico al Informacin

paciente.
F
Historial clnico Enviar historial Historial
El
/ Existe historial clnico
Informacin enva el ADM
clnico
clnico
operario
ADM Operario
historial
clnico
paciente
del Informacin
la
enfermera.
H
Historial clnico Organizar
Historial
/ Instrumental
clnico
instrumental
La enfermera organiza Enfermera

/ el instrumental que se
instrumental
utilizar en la cita.
organizado
I
Historial clnico Activar reserva Historial

/
Instrumental del paciente
La enfermera activa la Enfermera
clnico / Cita cita del paciente.
organizado
del
paciente
activada
J
Historial clnico Consultar
Historial
El
clnico
consulta
consultado
clnico del paciente
Cita
del historial clnico
paciente
mdico
el
general Mdico
historial General
activada
K
Tipo
consulta?
de Tipo
consulta?
de Consulta
externa
Se realizan distintas Mdico

/ actividades
General
Consulta
dependiendo del tipo
odontolgica
de consulta que se trata
Consulta
Efectuar
Examen
Se realiza un examen Mdico
externa
examen fsico
fsico
fsico al paciente para General
efectuado
ver el estado de sus

condiciones generales
Tabla 3.1 Caracterizacin del Proceso de Prestacin de Servicios Clnicos Parte 1

Examen fsico Auscultar

efectuado
al Paciente
paciente
El
auscultado
paciente
es Mdico
auscultado por el General

mdico
Paciente
El
episodio S / No
auscultado
es nuevo?
El mdico verifica Mdico

si el episodio es General
nuevo
El episodio es Registrar
Episodio
El mdico registra Mdico
nuevo
registrado
el
episodio
episodio General
mdico.
P
Episodio
registrado
Hubo
cita S / No
El mdico verifica Mdico
/ previa?
si hubo una cita General
Episodio
previa
antiguo
Q
Cita previa
Registrar
Evolucin
Se
registra
evolucin
registrada
evolucin
la Mdico
del General
paciente luego de
realizarle
los
procedimientos
respectivos
R
Encuentro
mdico
Dar
/ diagnstico
Registro
evolucin
Se efecta un Se
diagnstico a diagnstico
partir
en
determina
cita
de
la paciente
y
el Mdico
del General

HC
S
evolucin
Diagnstico
Registrar
Historial
Se
registra
historial
clnico
diagnostico
clnico
modificado
cliente
el Mdico
del General
modificado
T
Registro
de Accin
a Transferencia
Se determinan las Mdico
diagnstico en tomar?
Nueva posibles acciones a General
HC
consulta
/ tomar con respecto
Examen
al paciente y al
mdico
/ diagnstico
Farmacia
/ encuentro
del
Prescripcin
U
Transferencia
Registrar hoja Hoja

de
de El mdico registra Mdico
referencia
la
transferencia
hoja
referencia
de
de General
(orden
traslado)
al
paciente, se enva
al operario ADM
Informacin.

Examen
Registrar
mdico
ordenes
de examen
examen
mdico
mdico
laboratorio
Farmacia
Orden
Registrar
de El mdico registra las Mdico

rdenes
de
examen General
de mdico al paciente, se
/ enva al operario de
imagenologa
citas.
Receta mdica
El mdico registra la Mdico
receta mdica
receta
mdica
al General
paciente, se enva al
tcnico de farmacia.
X
Prescripcin
Registrar
prescripcin
Prescripcin

prescripcin
del General

paciente.
Y
Nueva Cita
Registrar
Cita nueva
orden de cita
orden para una cita General
nueva
nueva,
se
enva
al
operario de citas.

Finalmente, se mostrar el proceso Control de Exmenes Mdicos, el cual ha
sido tomado del proyecto mencionado anteriormente. Al igual que el proceso
anterior se llev a cabo una corroboracin de los procesos, como resultado
tambin se encontraron ciertas diferencias para lo cual se adapt el modelo
original con el proceso encontrado. stos son los siguientes:
1. El laboratorista, ya sea de imagen o de laboratorio, no interpreta los
resultados de los exmenes que realiza, ellos lo adjuntan al historial
clnico para que el mdico realice la interpretacin
A continuacin se mostrar el proceso de la propuesta original.
Figura 3.2 Proceso de Control de Exmenes Mdicos

1 Fuente: Adaptacin propia del proceso elaborado en el proyecto Modelamiento
2
El proceso en mencin posee la siguiente caracterizacin.

3
Entrada
A
Actividad
Comprobante de Asistir
cita
Salida
a Ingreso
Descripcin
del El paciente ingresa al Paciente
Examen Mdico paciente

en
Responsable
centro de salud.
horario
pactado
B
Paciente
Atender
ingresado
solicitud
Solicitud
de orden
examen
de La enfermera solicita la Enfermera

de orden
examen
de
examen
mdico
mdico
C
Orden
de Preparacin de Laboratorio / La enfermera verifica Laboratorista
examen mdico
equipos
y Imagenologa
materiales
si existen los equipos y de laboratorio

materiales para realizar
el examen
Laboratorio
Realiza
Muestra
extraccin
de extrada
El laboratorista extrae Laboratorista

la muestra
de laboratorio
muestra
E
Muestra
Analizar
Muestra
El laboratorista analiza Laboratorista
extrada
muestra
analizada
la muestra extrada
Muestra
Registrar
Resultado de El laboratorista registra Laboratorista
analizada
diagnstico
de la muestra
muestra
G
Imagenologa
Realizar
resultado
de
toma Imagen
realizada
la toma de la imagen
Revelado
realizada
imgenes
revelada
la imagen tomada
Resultado de la Adjuntar
Historial
El
/ resultados
Imagen revelada
de Imagen
El laboratorista realiza Laboratorista
Imagen
muestra
la de laboratorio
muestra
de imgenes
H
el
de laboratorio
al clnico
Historial Clnico modificado
de imgenes
El laboratorista revela Laboratorista

de imgenes
laboratorista Laboratorista
(laboratorio o imagen) de laboratorio

adjunta el resultado en /
el historial clnico del Laboratorista
paciente.
de imgenes
Tabla 3.4 Caracterizacin del Proceso de Control de Exmenes Mdicos

4
Requerimientos Funcionales
Como se pudo detallar en el inciso anterior los requerimientos funcionales
variaron al realizarles una revisin, mediante las entrevistas realizadas a un
mdico de consulta externa general. Estos fueron los requerimientos captados:
RF1. Se requiere que el mdico general o el tcnico o auxiliar en enfermera sea capaz
de iniciar o terminar la cita de un paciente en especfico.
El cliente requiere que el mdico auxiliar o el tcnico, tambin llamado auxiliar,
de enfermera inicien o terminen la cita del paciente que se va a atender en un
momento en especfico.
RF2. Se requiere que el mdico general sea capaz de consultar el diagnstico de un

paciente.
El cliente requiere que el mdico general sea capaz de consultar las los
diagnsticos que el paciente en consulta ha tenido en los encuentros anteriores.
RF3. Se requiere que el mdico general sea capaz de consultar los encuentros del
paciente.
El cliente requiere que el mdico general sea capaz de consultar los encuentros
del paciente en consulta, sin importar la especialidad. Debido a que se est
analizando un centro de salud de nivel I-3, las especialidades que se posee son
medicina general y estomatologa.
RF2. Se requiere que mdico general sea capaz de consultar el historial clnico de
un paciente en consulta.
El cliente requiere que el mdico general pueda consultar el historial clnico del
paciente sin importar la especialidad. Para ello, se mostrar un listado por
separado de las especialidades que el paciente en consulta ha visitado.

RF5. Se requiere que el mdico general sea capaz de consultar la orden de examen
mdico de un paciente, ya sea de laboratorio o imagenologa.
El cliente requiere que el mdico general sea capaz de consultar las los
exmenes mdicos que el paciente en consulta ha tenido en los encuentros
anteriores. Asimismo, podr ver los resultados de estos cuando se hayan
realizado.
RF6. Se requiere que el mdico general sea capaz de consultar la orden de

medicamentos de un paciente.
El cliente requiere que el mdico general sea capaz de consultar las rdenes de
medicamento que el paciente en consulta ha tenido en los encuentros anteriores.
RF7. Se requiere que el mdico general sea capaz de consultar la orden de traslado
de un paciente hacia otro centro de salud que pertenezca a la red de salud del
MINSA.
El cliente requiere que el mdico general sea capaz de consultar la orden de traslado que
el paciente posee. Debido a que es un centro de salud I-3 no posee un formato de contrareferencia para indicar que el paciente ha sido recibido, este procedimiento pertenece a
partir del siguiente nivel (I-4).
RF8. Se requiere que el mdico general sea capaz de consultar la prescripcin de

un paciente.
El cliente requiere que el mdico general sea capaz de consultar las prescripciones
mdicas que el paciente en consulta ha tenido en los encuentros anteriores.
RF9. Se requiere que el mdico general sea capaz de consultar la informacin

personal del paciente
El cliente requiere que el mdico general sea capaz de consultar la informacin personal
del paciente, tal como su nombre, sexo, antecedentes, etc.
RF10. Se requiere que el mdico general sea capaz de consultar los medicamentos
que posee el centro de salud.
El cliente requiere que el mdico general sea capaz de consultar los medicamentos que
posee el establecimiento.
RF11. Se requiere que el mdico general sea capaz de registrar el diagnstico de un

paciente.
El cliente requiere que el mdico general sea capaz de registrar el diagnstico mdico de
un paciente en consulta. El diagnstico se dar segn el cdigo CIE-10, el cual es el
cdigo internacional de enfermedades.
RF12. Se requiere que el mdico general sea capaz de registra los encuentros de
consulta general del paciente en consulta segn su etapa de vida, las cuales son:
nio, adulto, adolescente o adulto mayor.
El cliente requiere que el mdico general sea capaz de registrar los encuentros, tambin
llamado consulta, del paciente en consulta segn la etapa de vida que posea, las cuales
son: nio (0-12 aos), adolescente (12-18 aos), adulto (18-65 aos) y adulto mayor (65
- ms).
RF13. Se requiere que el mdico general sea capaz de registrar un episodio para el
paciente en consulta.
El cliente requiere que el mdico general sea capaz de registrar un episodio mdico para
el paciente, el cual permitir agrupar los diferentes encuentros, tambin llamado
consultas, que el paciente ha recibido hasta terminar el diagnstico definitivo en caso lo
hubiera. El episodio se dar como terminado al darlo como concluido o que posea 3
meses de inactividad. Asimismo, el cdigo del episodio mdico debe constar de 7
dgitos, para ello, si el episodio es el nmero 4 la codificacin ser 0000004.
RF14. Se requiere que el mdico general sea capaz de registrar la orden de examen
mdico de un paciente, ya sea de laboratorio o imagenologa.
El cliente requiere que el mdico general sea capaz de registrar la orden de examen
mdico, ya sea laboratorio o imagenologa, a un paciente en consulta.
RF15. Se requiere que el mdico general sea capaz de registrar la orden de

medicamentos de un paciente.
El cliente requiere que el mdico general sea capaz de registrar una orden de
medicamentos a un paciente en consulta. Asimismo, se debe visualizar si el
medicamento se encuentra en stock en el centro de salud para informar al paciente si
puede adquirirlo en ste o no.
RF16. Se requiere que el mdico general sea capaz de registrar la orden de

traslado de un paciente hacia otro centro de salud que pertenezca a la red de salud
del MINSA.
El cliente requiere que el mdico general sea capaz de registrar una orden de traslado a
un paciente en consulta, en caso que no pueda realizar los exmenes auxiliares o los
tratamientos adecuados para el paciente en consulta. Por ejemplo, en caso que el
paciente posea un diagnstico presuntivo de cncer al colon, este no podra descartarse
sin una colonoscopa, por ser un centro de salud de nivel I-3 no podra realizarse el
examen, por ello se le deriva (transfiere) a un centro de salud que le pueda brindar el
servicio requerido.
RF17. Se requiere que el mdico general sea capaz de registrar la prescripcin de

un paciente.
El cliente que el mdico general sea capaz de registrar la prescripcin de un paciente
que est consulta.
RF18. Se requiere que el tcnico de laboratorio sea capaz de iniciar o terminar la

cita del examen mdico de un paciente en especfico.
El cliente requiere que el tcnico de laboratorio, ya sea de imagenologa o laboratorio,
inicie o termine la cita del paciente que se va a atender en un momento en especfico.
RF19. Se requiere que el tcnico de laboratorio sea capaz de registrar los
resultados de los exmenes mdicos del paciente en consulta.
El cliente requiere que el tcnico de laboratorio sea capaz de registrar los
resultados de los exmenes realizados. Debido a que es un centro de salud de
nivel I-3 el tcnico de imagenologa no es capaz de realizar un diagnstico, por
lo que no se implement el registro de ste. Asimismo, los nicos exmenes
comprendidos en este nivel son: bioqumica-microbiologa, orina, heces,
hematologa e inmunoserologa.
Actores del Sistema

A continuacin se darn a conocer a los usuarios y a los subsistemas con los que
interacta el sistema SISREGAME. Los actores de los sistemas identificados son
los siguientes:
Figura 3.3 - Actores del Sistema


Tcnico o Auxiliar de enfermera
Este actor se encarga de consultar las citas que se deben atender o que se estn
atendiendo, de modo que estas puedan ser activadas.
Mdico General
Este actor se encarga de consultar y actualizar el historial clnico de los pacientes que
atiende. As como, prescribir las rdenes mdicas al paciente y dar por culminada la cita
del paciente.
Tcnico de Laboratorio
Este actor se encarga de registrar los resultados de los exmenes mdicos de los
pacientes.
Sistema de Gestin Horaria
El Sistema de Gestin Horaria es el encargado de brindar la informacin de las citas.
Sistema de Registro Mdico Electrnico
El Sistema de Registro Mdico Electrnico es el encargado de brindar la informacin de
los pacientes, de modo que se pueda actualizar su historial clnico.
Sistema de Control de Farmacia
El Sistema de Control de Farmacia es el encargado de brindar los medicamentos
existentes dentro del centro de salud.
Sistema de Atencin Mdica Odontolgica
El Sistema de Atencin Mdica Odontolgica es el encargado de brindar la informacin
mdica odontolgica del paciente, de modo que se pueda mostrar en el historial clnico
del paciente.
Casos de Uso del Sistema

En el presente proyecto se han identificado 18 casos de uso, los cuales
representan la funcionalidad del sistema SISREGAME. Estos casos de uso, se
encuentran agrupados dentro del paquete Sistema de Registro de Atencin
Mdica (SISREGAME).
Figura 3.4 Diagrama de Paquetes

A continuacin se mostrarn los casos de uso identificados, los cuales se

encuentran dentro del paquete antes mencionado.
Figura 3.5 Diagrama de Casos de Uso

CU1. Administrar Cita de Examen Mdico

Este caso de uso hace referencia al servicio publicado por el Sistema de Gestin
Horaria, el cual brinda las citas de examen mdico de los pacientes que an no
han sido activadas y las que se encuentran activas. En el primer caso, el tcnico
o auxiliar de enfermera puede activar una cita mdica para dar inicio al examen
mdico del paciente. En el segundo caso, el tcnico o auxiliar de enfermera
podr obtener las citas de examen mdico que estn siendo atendidas.
Figura 3.6 Citas Mdicas a Activas

69
Figura 3.7 Citas Mdicas Activadas

CU2. Administrar Cita Mdica

Este caso de uso hace referencia al servicio publicado por el Sistema de Gestin
Horaria, el cual brinda las citas de los pacientes que an no han sido activadas y
las que se encuentran activas. En el primer caso, el tcnico o auxiliar de
enfermera o el mdico general puede activar una cita mdica para dar inicio a la
consulta mdica del paciente. En el segundo caso, el tcnico o auxiliar de
enfermera o el mdico general podrn obtener las citas mdicas que estn
siendo atendidas.
Figura 3.8 Consultar Citas Pendientes de Examen Mdico

71
Figura 3.9 Consultar Citas Activas de Examen Mdico

CU3. Consultar Diagnstico (Caso de Uso - Extendido)

Este caso de uso hace referencia a la funcionalidad que brindar el Sistema de
Atencin Mdica Odontolgica.
CU4. Consultar Encuentro (Caso de Uso - Extendido)

Este caso de uso permitir la consulta de todos los encuentros mdicos (consultas
mdicas) de un episodio en especial.
Figura 3.10 Consulta de Encuentro Nio

Figura 3.11 Imprimir Encuentro Nio

73
Figura 3.12 Consulta Encuentro Adolescente

Figura 3.13 Imprimir Encuentro Adolescente

Figura 3.14 Imprimir Encuentro Adulto

Figura 3.15 Imprimir Encuentro Adulto

75
Figura 3.16 Consultar Encuentro Adulto Mayor

Figura 3.17 Imprimir Encuentro Adulto Mayor

CU5. Consultar Historial Clnico (Caso de Uso - Extendido)

Este caso de uso permitir la bsqueda de los episodios mdicos y los
encuentros de ste. Este caso de uso incluye al caso de uso Obtener Informacin
del Paciente y es extendido por el caso de uso Consultar Encuentro.
Figura 3.18 Consulta de Historial Clnico

CU6. Consultar Orden de Examen Mdico (Caso de Uso - Extendido)
77

Este caso de uso permitir al mdico general consultar la orden de examen mdico de
un paciente en un encuentro especfico, en ella se encuentra el estado del examen
mdico.
Figura 3.19 Consultar Orden de Examen Mdico

Figura 3.20 Imprimir Orden de Examen Mdico

CU7. Consultar Orden de Medicamentos (Caso de Uso - Extendido)

Este caso de uso permitir al mdico general consultar la orden de
medicamentos recetada en un encuentro mdico especfico.
Figura 3.21 Consultar Orden de Medicamentos

Figura 3.22 Imprimir Orden de Medicamentos

CU8. Consultar Orden de Traslado (Caso de Uso - Extendido)

Este caso de uso depende de la funcionalidad brindada por el Sistema de Registro
Mdico Electrnico
CU9. Consultar Prescripcin (Caso de Uso - Extendido)
Este caso de uso hace referencia a la funcionalidad que brindar el Sistema de
Atencin Mdica Odontolgica.
79

CU10. Obtener Informacin del Paciente (Caso de Uso - Incluido)
Este caso de uso hace referencia al servicio publicado por el proyecto Servicio de
Registro Mdico, el cual brinda la informacin bsica del cliente. De esta forma se
podr relacionar a la persona con el historial clnico.
CU11. Obtener Medicamentos (Caso de Uso - Incluido)
Este caso de uso hace referencia al servicio del Sistema de Control de Farmacia el
cual brindar una lista de los medicamentos existentes en el centro de salud.
CU12. Registrar Diagnstico (Caso de Uso - Extendido)
Este caso de uso depende de la funcionalidad brindada por el Sistema de Atencin
Odontolgica.
CU13. Registrar Encuentro
Este caso de uso permitir registrar el encuentro mdico, es decir, todos los sntomas
presentados por el paciente en un episodio mdico. Este encuentro puede ser de 4 tipos:
nio, adolescente, adulto y adulto mayor. Este caso de uso podr ser extendido con el
caso de uso Registrar Orden Mdica, Registrar Orden de Examen Mdico, Registrar
Prescripcin, Registrar Orden de Traslado.
Figura 3.23 Registrar Encuentro Nio

81
Figura 3.24 Registrar Encuentro Adolescente

Figura 3.25 Registrar Encuentro Adulto

Figura 3.26 Registrar Encuentro Adulto Mayor

CU14. Registrar Episodio
Este caso de uso permitir registrar el episodio mdico, es decir, la razn por la que el
paciente se ha atendido.
83

Figura 3.27 Registrar Episodio
CU15. Registrar Orden de Examen Mdico (Caso de Uso - Extendido)

Este caso de uso permitir registrar el(los) examen(es) mdico(s) que se le
brindar(n) al paciente dentro del encuentro mdico.
Figura 3.28 Registrar Orden de Examen Mdico

CU16. Registrar Orden de Medicamentos (Caso de Uso - Extendido)
Este caso de uso permitir registrar la orden de medicamentos (frmacos) que se
le brindar al paciente dentro del encuentro mdico.
Figura 3.29 Registrar Orden de Medicamentos

CU17. Registrar Orden de Traslado (Caso de Uso - Extendido)
Este caso de uso depende de la funcionalidad brindada por el Sistema de Registro
Mdico Electrnico.
CU18. Registrar Prescripcin (Caso de Uso - Extendido)
Este caso de uso depende de la funcionalidad brindada por el Sistema de Atencin
Odontolgica.
CU19. Registrar Resultado de Examen Mdico del Paciente
Este caso de uso permitir registrar el resultado del examen mdico realizado dentro del
historial clnico del paciente.
85
Figura 3.30 Registrar Resultado de Examen Mdico del Paciente

Casos de Uso Vs. Proceso

Los casos de uso mencionados en el inciso anterior responden a las actividades
de los procesos de Prestacin de Servicios Clnicos y Control de Exmenes
Mdicos los cuales, como ya fue mencionado, han sido validados. A
continuacin se mostrar la relacin entre las actividades de los procesos
validados, los casos de uso y los requerimientos funcionales.

Proceso
de
Prestacin
de
Servicios Clnicos
ID CU Nombre Caso de Uso

Administrar
Activar reserva del paciente
Cita
ID RF
de
Examen
CU2
Mdico
RF1
CU3
Consultar Diagnstico
RF2
CU4
Consultar Encuentro
RF3
CU5
Consultar Historial Clnico
RF4
CU6
Consultar Orden de Examen Mdico
RF5
CU7
Consultar Orden de Medicamento
RF6
CU8
Consultar Orden de Traslado
RF7
CU9
Consultar Prescripcin
RF8
CU10
Obtener Informacin del Paciente
RF9
CU11
Obtener Medicamento
RF10
Dar un diagnstico
CU12
Registrar diagnstico
RF11
Registrar evolucin
CU13
Registrar Encuentro
RF12
Registrar episodio
CU14
Registrar Episodio
RF13
mdico
CU15
Registrar Orden Examen Mdico
RF14
Registrar receta mdica
CU16
Registrar Orden de Medicamento
RF15
Orden de traslado
CU17
Registrar Orden de Traslado
RF16
Registrar prescripcin
CU18
Registrar Prescripcin
RF17
Consultar historial clnico
Registrar rdenes de examen
Tabla 3.5 Mapeo de Proceso Prestacin de Servicios Clnico Vs. Caso de Uso
87

Proceso
de
Control
de
Exmenes Mdicos
ID CU
Nombre Caso de Uso
ID RF
Atender solicitud de examen
CU1
Administrar Citas Mdicas
RF18
Interpretacin de resultados de
laboratorio
Registrar Resultado de Examen

CU19
Mdico del Paciente
RF19
Tabla 3.6 Mapeo de Proceso de Control de Exmenes Mdicos Vs. Caso de Uso
Requerimientos no Funcionales
Los requerimientos no funcionales son aquellos que restringirn las

caractersticas del producto software, por ejemplo, la disponibilidad (el horario
en que el usuario podr ingresar al sistema), los navegadores de internet en el
cual podr ser usado, etc. Estos requisitos proveern las caractersticas en el
comportamiento del producto complementando las funcionalidades.
Usabilidad
Caractersticas que permiten que el sistema sea de fcil uso y acceso para el
usuario.
Us01 - Presentacin
Los usuarios contarn con una interfaz diseada a fin de que sea sencilla e
intuitiva. Las opciones y funcionalidades del sistema se mostrarn al usuario de
una manera tal, que pueda navegar a travs de l y satisfacer las acciones que
desee realizar sin informacin adicional en el sistema.
El Sistema de Registro de Atencin Mdica cumplir con estndares para el
diseo de las interfaces. Se emplear el uso de botones, formularios, mensajes de

alerta y confirmacin para que el usuario pueda navegar por el sistema sin
problemas. Adems, el sistema deber mantener un estilo y combinacin de
colores para no generar stress en el usuario.
Us02 Acceso al Sistema
El sistema permitir a los usuarios acceder al mismo desde Internet a travs del
protocolo http y las pginas web estarn realizados en base al lenguaje HTML y
se har uso de javascript y derivados. El sistema hace uso de un navegador web
como interfaz de usuario.
Confiabilidad
Caractersticas del sistema que indicarn el horario en que el sistema estar

disponible, el tiempo promedio en que se deber recuperar el sistema en caso de
fallas, la persistencia de datos y la fiabilidad del acceso.
Conf01 - Disponibilidad
SISREGAME deber estar disponible para los usuarios dentro del horario de
atencin de los centro de salud (09:00 a.m 06:00 p.m). El servidor que aloja el
Sistema de Registro de Atencin Mdica debe contar con las especificaciones
tcnicas definidas por el jefe de proyecto en el documento Plan de Aceptacin.
De lo contrario, el sistema presentar problemas de lentitud de respuesta o,
indisponibilidad por sobrecarga de peticiones.
El sistema deber someterse a una prueba de carga especificado por el jefe de proyecto
y realizar las configuraciones correspondientes para procurar que el sistema est
disponible en todo momento durante la jornada laboral del centro de salud.
Conf02 Tiempo medio entre fallas (MTBF)
El sistema, desde su primer release deber ser sometido a un control de fallas. Una vez
identificadas las fallas debern ser corregidas a fin de que se pueda cumplir con el
promedio de dos o ningn error por ao.
Conf03 Persistencia
Los datos almacenados por el Sistema de Registro de Atencin Mdica debern
mantener su consistencia. Es decir, los datos no debern ser corruptos por transacciones
89

incompletas o fallidas, ni alterados de manera malintencionada por amenazas fsicas ni
tecnolgicas a lo largo del tiempo. Es importante garantizar al usuario que la
informacin que consulta y la que se le muestra son los originalmente registrados. El
sistema deber poder capturar las excepciones que ocurran en la aplicacin con respecto
al registro y modificacin en la base de datos. Adems, si se produjese un corte de
energa elctrica y existen transacciones en ejecucin, se deber cancelar cada una de
estas.
Adems el sistema debe contar con restricciones de introduccin de texto
malintencionado en los campos vulnerables para evitar problemas de Script Injection y
Sql injection.
Conf04 Fiabilidad de Acceso
El sistema deber proveer 100% de fiabilidad de acceso. Cualquier entrada errnea o
malintencionada deber ser identificada y responder al usuario con un mensaje de
error. Los usuarios que no estn autorizados no podrn tener acceso a las aplicaciones
del sistema; la informacin que se muestre a los usuarios deber corresponder a las
capacidades que tenga.
Si el sistema no permitiese el acceso a una persona autorizada, en primer lugar,
se tendr que comprobar si su usuario no ha sido bloqueado por ingresar
contraseas errneas. De no ser, se tendr que corroborar la lista de usuarios y
verificar si existe o no.
El Administrador de contenidos Liferay 5.2.3 tiene un portlet de autenticacin
que permitir la gestin de acceso de los usuarios al sistema.
Performance
Caractersticas del sistema que indicarn el tiempo mximo de espera que el sistema
debe brindar al usuario, el rendimiento y la cantidad de usuarios que debe atender en
simultneo.
Per01 Tiempo de respuesta

El Sistema de Registro de Atencin Mdica responder al usuario en no menos de 20
segundos desde el momento de la peticin de una funcionalidad. El sistema estar
autorizado a tomar ms tiempo al hacer trabajos de varios volmenes de procesamiento.
Para garantizar el tiempo de respuesta se tendrn que realizar una serie de pruebas de
carga al sistema donde se irn agregando usuarios ejecutando un nmero determinado
de transacciones.
Per02 Rendimiento
La aplicacin ser capaz de soportar diferentes usuarios trabajando a la vez y mantendr
la consistencia de la base de datos. Se realizarn pruebas de stress al sistema para
determinar su solidez en momentos de intensa carga de usuarios realizando diferentes
transacciones.
Se debe considerar que la aplicacin trabajar sobre el servidor de la universidad, por
ende, el rendimiento del sistema se ver limitado por la configuracin que se establezca
para publicar la aplicacin.
Per03 Capacidad
El sistema deber ser capaz de soportar 10 usuarios al mismo tiempo. El sistema al ser
sometido a las pruebas de carga, deber soportar de manera normal las peticiones que
realicen como mximo 10 usuarios. De igual manera, es necesario identificar cundo es
que el sistema empieza a mostrar deficiencias por las solicitudes de muchos usuarios al
mismo tiempo en la aplicacin.
Soporte
Caractersticas del sistema que indicarn los estndares de programacin, los

manuales que debern ser entregados al finalizar el proyecto, el navegador de
internet que deber ser usado para un ptimo rendimiento, la escalabilidad y la
portabilidad del sistema.
Sop01 - Estndares
91

Los estndares de codificacin y diseo de interfaces aplicados al Sistema de Registro
de Atencin mdica son los definidos por el jefe de desarrollo del Proyecto.
Sop02 Manuales
La documentacin del Sistema de Registro de Atencin Mdica tiene incluido:
El manual de instalacin y configuracin en el cual se especifican las tareas a realizar
para poder desplegar el sistema. Tendr una descripcin de cmo configurar los
componentes hardware por parte del cliente y del servidor. De esta manera se podr
tener un correcto acceso por parte de los usuarios, adems de, optimizar el rendimiento
a la respuesta de solicitudes por parte del servidor. Y por ltimo,
El manual de usuario que contendr las funcionalidades que brinda el sistema para cada
rol identificado en el Sistema de Registro de Atencin Mdica.
Sop03 Navegador de Internet
El sistema podr ser soportado por los navegadores Internet Explorer 8.0 o posterior y
Mozilla 4.0. Los desarrolladores del sistema debern realizar pruebas de compatibilidad
para los estilos y los componentes usados para la aplicacin web a fin de que los
usuarios puedan acceder a la misma de manera correcta.
Sop04 Escalabilidad
El sistema ha sido diseado, arquitectnicamente, orientado a SOA (Arquitectura
orientada a servicios). Como parte de esta arquitectura se cuenta con una capa de
servicios y una de procesos que sern capaces de soportar la adicin de nuevos
requerimientos y aplicaciones Legacy.
Sop05 Portabilidad
El sistema podr ser desplegado tanto en servidores Linux como en Windows. Para ello
se usar el servidor de aplicaciones GlassFish 2.1.1 que se encarga de albergar los
Servicios Web y el Portal de SISREGAME.
Restricciones de Diseo

Caractersticas que se debern utilizar para el desarrollo del sistema.
Rd01 Lenguajes de Programacin

Los lenguajes de programacin que deben ser usados en el proyecto Sistema de Registro
de Atencin Mdica son Java, JavaScript y Java Server Page (JSP). Adems para poder
publicar las aplicaciones web es necesario tener instalado GlassFish v2.1.1 y Liferay
5.2.3.
Rd02 Herramientas de Desarrollo
Las herramientas de desarrollo que debern ser usadas son:
NetBeans 6.7.1 Como herramienta IDE de desarrollo.
MySql 5.1. Es el gestor de base de datos que se utilizar para almacenar la informacin.
StarUML. La herramienta UML para realizar los modelos de Casos de Uso y modelo de
dominio.
Rd03 Librera de Clases

Las libreras que se usarn son las que vienen incluidas por defecto en el Netbeans 6.7.1
para desarrollar Aplicaciones web y el PortalPack que permite el soporte de portlets 2.0.
Adicionalmente, se tendrn que desarrollar nuevas libreras para la capa de acceso a
datos, lgica de negocios, interfaces y entidades del negocio.
Requerimientos de la Documentacin en Lnea del Usuario y del

Sistema de Ayuda
El software no cuenta con documentacin en lnea.
93
Componentes Comprados
En vista que SISREGAME es un proyecto acadmico de la UPC no se requiere
comprar ningn componente adicional para su uso, dado que las computadoras
de la UPC tienen instalado ya los componentes principales del proyecto.
Interfaces
Interfaces de Usuarios
Las interacciones entre usuario y el sistema se realizarn va interfaz grfica. Toda la
funcionalidad del sistema ser accesible mediante los dispositivos perifricos teclado y
ratn. La interfaz de usuario ser una interfaz amigable en color basada en web con
mens de acceso rpido de como mximo 3 niveles. Los usuarios sern capaces de
elegir cualquier opcin permitida de la interfaz y obtendrn resultados por pantalla.
Interfaces de Hardware
Para la recoleccin de datos del servidor se tendr que utilizar el protocolo TCP/IP.
Interfaces de Software
El sistema necesitar el acceso externo a una base de datos MySQL.
Interfaces de Comunicacin
El Sistema de Registro de Atencin Mdica se comunica con el Sistema de Control de
Farmacia, Sistema de Registro Mdico Electrnico, Sistema de Gestin Horario,
Sistema Mdico de Atencin Odontolgica.
Requerimientos de Recursos
Requerimientos de Hardware

Estacin
Especificaciones de Hardware
Procesador Intel Core 2 Duo 2.7 Ghz
Conexin a Red
Servidor de base de dato
Memoria RAM: 2GB

Espacio Disco Duro: 160GB
Procesador Inter Quad Core 3.5 Ghz
Conexin a Red
Servidor de Aplicaciones
Memoria RAM: 4GB

Conexin a Red
Memoria RAM: 1GB
Computadora Cliente

Procesador:
Intel
Dual
Core
Equivalente
Tabla 3.7 Requerimientos de Hardware
Requerimientos de Software
Los requerimientos de software establecidos son los siguientes:
Estacin
Especificaciones de Hardware
Servidor de base de datos
MySql 5.1
Servidor de Aplicaciones
GlassFish 2.1.1
Administrador de Contenidos
Liferay 5.2.3
Navegador
Computadora Cliente
de
internet:
Internet
Explorer 8.0 o posterior /Mozilla

Firefox 4.0
Tabla 3.8 Requerimientos de Software

Requerimientos de Documentacin
Los Requerimientos de documentacin establecidos para el proyecto Sistema
de Registro de Atencin Mdica son:
95
Resultados de las pruebas funcionales realizadas por la empresa

Quality Assurance. Este documento contendr el log del resultado de
las pruebas realizadas al sistema, as como los datos de prueba
utilizados.
Certificado de Calidad entregado por la empresa Quality Assurance.

Este documento es entregado por la empresa QA una vez aprobados
todos los artefactos del proyecto as como el resultado positivo de las
diferentes pruebas realizadas al sistema.
Estndares utilizados durante el ciclo de desarrollo del sistema. Este documento

contiene informacin importante de los estndares usados para la implementacin del
sistema a fin de que para futuros mantenimientos del mismo, por otro personal, puedan
entenderlo.
Memoria del Proyecto.
Requerimientos de Personal
Para el despliegue del sistema se requerir la presencia de personal encargado de las
tecnologas de informacin de la empresa ITIL.
Se requerir la presencia del Jefe de Proyecto como del Jefe de Desarrollo para que
puedan capturar las disconformidades como resultado de la evaluacin del Plan de
Aceptacin.
Requerimientos de Datos de Prueba
Debido a que el centro de salud no prestar datos reales para la prueba del sistema, se ha
decidido crear los datos de prueba, para ello se necesitarn los siguientes datos:
Los episodios de los pacientes.
Los encuentros del episodio de los pacientes.
Las rdenes mdicas recetadas al paciente.
Los exmenes mdicos a realizar al paciente.
Resultados de los exmenes mdicos del paciente.
El presente captulo mostr las diferencias de los requerimientos captados entre este
proyecto y el tomado como base, Arquitectura de Negocio para un Centro de Salud de
Nivel I-3. De este modo, se brindar al cliente las necesidades que poseen en la
realidad las cuales sern llevadas a cabo en la implementacin del sistema. Asimismo,

se dio una breve explicacin de los requerimientos funcionales y no funcionales, de
modo que se tenga mayor entendimiento de estos.
97
CAPTULO 4. DISEO ARQUITECTNICO17
El captulo contiene la arquitectura que presentar el sistema
Introduccin
El objetivo de este captulo es dar a conocer la arquitectura del presente proyecto,
para ello, se ha tomado como base el proyecto Diseo de una arquitectura
orientada a servicios para un establecimiento de salud de nivel I-3 de complejidad.
Dentro del presente acpite se darn a conocer las coincidencias y las diferencias
encontradas acerca de las decisiones arquitecturales de la propuesta del proyecto
mencionado anteriormente.
Los temas que se abordarn a lo largo del captulo son los fundamentos en los que
se basa la arquitectura, la sntesis y la organizacin en capas del sistema.
Fundamentos para la arquitectura
Metas y Restricciones Arquitectnicas
Metas
17
Ver Anexo 2: Se muestra el documento de arquitectura de software SAD.
Los objetivos establecidos para la arquitectura de SISREGAME son los que se presentan a
continuacin:
La arquitectura definida debe ser capaz de soportar los requerimientos tanto funcionales
como no funcionales definidos y que se encuentran detallados en el documento de SRS.
El diseo arquitectnico posea alto grado de cohesin y bajo nivel de acoplamiento entre
cada uno de los componentes definidos.
La arquitectura resultado permita el reuso de sus componentes.
Restricciones
Las restricciones arquitectnicas del sistema SISREGAME son las siguientes:
El sistema debe ser implementado mediante el uso de herramientas

tecnolgicas OpenSource. El lenguaje de desarrollo ser JAVA.
El sistema debe estar arquitectnicamente orientado a SOA. El proyecto

Diseo de una arquitectura orientada a servicios para un centro de salud
de nivel I-3 obtuvo como resultado que las aplicaciones del Sistema
Integral de Salud debern comunicarse a nivel de servicios, por ende, se
vio conveniente el uso de SOA.
Las aplicaciones que se realicen en el sistema debern ser albergadas en

un administrador de contenidos mediante el uso de la tecnologa JRS268
Portlets v2.0 siguiendo el protocolo WSRP (Web Services for Remote
Portlets).
La data deber ser gestionada mediante un motor de base de datos

relacional y la arquitectura de datos deber seguir el estndar de la
empresa Salud-able.
El modelo de datos deber tomar en cuenta el resultado del proyecto

Diseo de una arquitectura de datos para un centro de salud de nivel I3.
Sntesis General de la Arquitectura

Como se ha venido mencionando a lo largo del documento, la arquitectura
establecida para el Sistema de Registro de Atencin Mdica SISREGAME est
orientada a servicios.
99
Captulo 4: Diseo Arquitectnico
Esta es una propuesta de IBM debido al entorno de negocio que se viene dando en
el mundo, el cual involucra comunicacin o interaccin entre entidades
empresariales en aras de cumplir con sus procesos.
El Sistema Integral de Salud, que es sistema software propuesto por la empresa

Salud-able y que, actualmente, est orientado a los centros de salud de nivel I-3,
integra diferentes mdulos que requieren interactuar entre s. Uno de estos es
SISREGAME cuyo objetivo es automatizar, mediante un sistema informtico, el
proceso de prestacin de servicios clnicos de una entidad de salud. Adems, este
mdulo, por demanda del proceso, deber interactuar con el mdulo SISGEHO
(Sistema de gestin horaria), SISREGMED (Sistema de Registro Mdico
Electrnico), SAMO (Sistema de Atencin Mdica Odontolgica) y SISCOFARMA
(Sistema de Farmacia). As mismo, mediante el alcance del sistema integral de salud
vaya aumentando y abarcando niveles de complejidad superiores, se establecern
nuevos mdulos que requerirn la comunicacin con los ya existentes.
Es por esta razn que SOA se ajusta a las necesidades del negocio ya que los
procesos de un centro de salud necesitan ser orquestados.
A continuacin, se presenta el diagrama de la arquitectura SOA propuesta por IBM:
Figura 4.1 Capas de SOA

Fuente:IBM SOA Foundation Architecture Overview
A continuacin, se presenta el resumen de componentes que son parte de la arquitectura

establecida para el sistema SISREGAME en base al modelo de referencia SOA.
Bsicamente el diagrama representa las 5 primeras capas indicadas en la Fig 3.1.
En la capa de sistemas operacionales que es la base del diagrama se muestra la base

de datos dbSaludable construida en base al nivel de complejidad I-3 de un centro
de salud. En adicin se muestras
los componentes de acceso a datos
(DAConsultaExterna y DAExamenMedico) que implementan las interfaces

definidas para las mismas. En el mismo nivel se muestran los sistemas con los que
el sistema SISREGAME interacta. Esta capa ser detallada en el punto 3.4.1.
En el segundo nivel se encuentra la capa de componentes empresariales o del

negocio. Aqu se han construido los componentes BLConsultaExterna y
BLExamenMedico en los cuales se han implementado procedimientos y funciones
que permiten ejecutar de manera natural los procesos de Servicio de atencin
Mdica y de Control de Exmenes Mdicos. Estos componentes mediante las
interfaces de la capa de sistemas operacionales permiten el envo y consulta de
informacin de la base de datos. Esta capa es detallada en el punto 3.4.2.
La tercera capa que ser detallada en el punto 3.4.3 est conformada por los
servicios web implementados y que se comunican con los componentes de lgica de
negocios segn el proceso al que pertenecen.
La capa de proceso del negocio tiene los componentes de Prestacin de Servicios

Clnicos y de Control de Exmenes Mdicos. Estos son detallados en el punto 3.4.4.
Los componentes diagramas que permiten orquestar la comunicacin de los
componentes de presentacin (Portlets) y los servicios a travs de los controladores
de cada portlet.
101
Figura 4.2 Arquitectura de SISREGAME

Organizacin en Capas
Sistemas Operacionales
Dentro de esta capa se encuentra la base de datos relacional integrada del Sistema Integral
de Salud la cual albergar la data concerniente al Sistema de Registro de Atencin Mdica
y los sistemas personalizados que son parte de la aplicacin integrada. El motor de base de
datos escogido es MySQL 5.1.
Aplicaciones empaquetadas
Para el alcance de los proyectos de la empresa Salud-able para el periodo
acadmico 2011-1, no existen aplicaciones de terceros fuera de la
organizacin a tener comunicacin.
Aplicaciones personalizadas
SISREGAME pertenece al portafolio de sistemas de una solucin software
integral y no trabajar de manera independiente. Es decir, el sistema estar
comunicado con otros para obtener informacin relevante y as cumplir con
los objetivos del proyecto. La comunicacin la realizar mediante servicios
web con los siguientes sistemas:
Mdulo/Sistema
Sistema
de
Registro
Descripcin
Mdico
Electrnico
SISREGMED
Jefe de Proyecto
Admer Ral Ros Valdivieso
103
Este sistema se encarga de la administracin

de personas y pacientes involucrados con el
Centro de Salud. As mismo, se encarga de
gestionar los traslados internos y externos de
pacientes y del registro de rdenes de
referencia.
Este sistema se encarga de la gestin de
SISCOFARMA
medicamentos en sus
Jefe de Proyecto
Gestin
Jos Carlos Arroyo
medicamentos,
de
pedidos,
son
diferentes etapas.
logstica
algunas
de
venta
las
Antoni Jaime
funcionalidades de este proyecto.

Este sistema se encarga de la gestin de los
Sistema de Consulta Odontolgica
encuentros mdicos concernientes al rea de
SAMO
servicio de Consulta Externa Odontolgica.
Jefe de Proyecto
Renzo Caldern
Katherine Grijalva
Este sistema se encarga de la gestin de
SISGEHO
rdenes de citas para consulta externa y para
Jefe de Proyecto
exmenes mdicos. Adems, se encarga de
Franz Zrate
gestionar los horarios de atencin de los

mdicos segn su disponibilidad.
Tabla 4.1 Tabla de prestacin y consumo de servicios

Decisiones arquitecturales
La cantidad de aplicaciones ir aumentando en funcin del alcance del Sistema Integral de
Salud, por ende, la comunicacin con los sistemas se deber realizar en base a servicios.
Los servicios que se brinden debern ser realizados de tal manera que puedan ser reusados.
La Base de Datos deber seguir el estndar adoptado por la empresa Salud-able, lo cual
permitir que nuevo personal que interacte con la misma pueda entender de manera
sencilla la nomenclatura de tablas, atributos, funciones y procedimientos almacenados.
El motor de base de datos a utilizar es MySQL 5.1.
El acceso de las aplicaciones a la Base de Datos deber ser gestionada por el servidor de
aplicaciones mediante la creacin de un pool de conexiones.
Se utilizar una clase llamada ServiceLocator que se encarga de pedir conexiones al

servidor de aplicaciones. Esta clase deber ser llamada por la clase DataSource.
Se deber construir componentes de acceso a datos segn se requiera aplicando el patrn
DAO y DTO. Se requerir una eficiente gestin de las conexiones, por esto, se deber
aplicar el patrn Singleton a la clase DataSource que se encargar de proporcionar las
conexiones, luego de pedirlas al ServiceLocator, a los diferentes componentes DAO, de
cerrar las mismas, as como de cerrar los ResultSets y Statements creados para poder
obtener y/o registrar data en la base de datos.
Los componentes DAO debern implementar a interfaces que se encargan de la separacin
del qu y el cmo de una funcin o procedimientos. En otras palabras, de la separacin de
la firma y el mtodo de una funcin o procedimiento.
Componentes Empresariales
reas funcionales soportadas

Consulta Externa
Esta rea es soportada por el proceso Prestacin de Servicios Clnicos.

Comprende la atencin de consulta ambulatoria de un paciente en
medicina general.
Exmenes Mdicos
Esta rea es soportada por el proceso de Control de Exmenes

Mdicos. Comprende la atencin y registro de resultado de exmenes
mdicos de Laboratorio.
Aspectos de Negocio soportados

Dominio del Negocio
105
Figura 4.3 Modelo de Dominio de SISREGAME

Metas
a) Brindar un servicio de atencin de consulta externa de calidad. Al
administrar mediante un producto software la informacin del historial
clnico de los pacientes se minimizan los tiempos de espera por la
bsqueda de HC, gestionar las recetas mdicas y rdenes de traslado y
examen mdico.
b) Automatizar el registro de los resultados de exmenes mdicos y
adjuntarlos al historial clnico del paciente para la consulta del mdico
y se pueda emitir un diagnstico certero.
Procesos del Negocio
Prestacin de Servicios Clnicos
Este proceso es uno de los procesos core de un centro de salud de nivel
I-3. El proceso inicia con la llegada de un paciente a una cita para
consulta externa general. La cita es activada por la enfermera, en
consecuencia, el historial clnico es consultado por el mdico y, este,
de acuerdo a los antecedentes, sntomas del paciente y al resultado del
examen fsico, deber diagnosticar la patologa del paciente, emitir una
orden mdica y tratamiento para el paciente.
Control de Exmenes Mdicos
Este tambin es un proceso core y se inicia con la emisin de una
orden de examen mdico de laboratorio. Comprende tambin, llegada
de un paciente para realizar el examen mdico ordenado por un
profesional de la salud. Se activa el examen mdico y queda activada
la opcin para el registro de resultados del examen y ser adjuntado al
historial clnico.
La capa de componentes empresariales estar conformada solo por los
siguientes procesos:
a) Proceso Prestacin de Servicios Clnicos.
b) Proceso Control de Exmenes Mdicos.
107

Cada proceso contar con un correspondiente componente de lgica de
negocio
para que se
puedan implementar
las funciones
procedimientos que permitan el cumplimiento de los mismos.

Los componentes de Lgica de negocio deber ser capaces de
establecer un frontera entre el proceso a realizar, de los mtodos que
apoyan al cumplimiento del mismo interactuando con la base de datos.
Los componentes de Lgica de negocio debern interactuar, solamente,
con las interfaces.
Servicios
Portafolio categorizado de servicios
El portafolio de servicios que se van a utilizar estn categorizados de la siguiente
manera:
Servicio/Mdulo
Descripcin de Func - Proc
WSCECitas
ActivarCita
SISGEHO
Este procedimiento se encarga de activar una cita

pendiente.
ObtenerCitasPendientes
Esta funcin devuelve una lista de citas pendientes
de la fecha actual de la consulta.
ObtenerCitasActivadas
Esta funcin devuelve una lista de citas activadas de
la fecha actual de la consulta.
TerminarCita
Este procedimiento se encarga de terminar una cita
activa
ObtenerCitasPendientes_x_AreaServicio
Esta funcin devuelve una lista de citas pendientes
de la fecha actual de la consulta y del rea de
servicio
solicitado
(p.e.
Medicina
General,

Odontologa).
WSListarMedicamentos
ObtenerMedicamentos_x_Nombre
SISCOFARMA
Esta funcin retorna una lista de medicamentos de

acuerdo a una cadena de texto ingresada. (p.e. si se
ingresa
PANA,
retorna
PANADOL
FORTE,
PANADOL MIGRAA, etc).

ObtnerMedicamentos_x_CMedicamento
Esta funcin retorna un medicamento, de acuerdo a
un cdigo de medicamento ingresado.
WSPersonalSalud
ObtenerPersonalSaludXCorreo
SISREGAME
Esta funcin retorna un Personal de la Salud de
Externo
acuerdo al correo ingresado.

ObtenerPersonalSalud
Esta funcin retorna un Personal de la Salud de
acuerdo al cdigo ingresado
WSAreaServicio
ObtenerTodasConsultasAreaServicio
SISREGAME
Esta funcin retorna una lista de reas de Servicio
Externo
que ejecutan consultas de atencin externa. (p.e

Medicina General, Odontologa).
ObtenerAreaServicio_x_Proyecto
Esta funcin retorna el rea de servicio que ejecuta
consulta externa de acuerdo al cdigo de proyecto
interno ingresado. (p.e. si ingresamos 730 que es el
cdigo de proyecto de SISREGAME devolver el
cdigo de Medicina General que se encuentre en la
BD).
ObtenerUnAreaServicio
Esta funcin retorna un rea de servicio de acuerdo
al cdigo de rea de servicio ingresado.
WSPaciente
109
ObtenerPaciente

SISREGMED
Esta funcin retorna una entidad paciente de acuerdo

al cdigo del mismo ingresado.
WSCentroMedicoObtener
ObtenerCentroMedico
SISREGAME
Esta funcin retorna una entidad Centro Mdico de
Externo
acuerdo al cdigo del mismo ingresado. La entidad

centro mdico contiene el nombre del centro mdico
y el nombre de la red de salud a la que pertenece el
centro.
WSCitasEM
ObtenerCitasEM_Pendientes
SISGEHO
Esta funcin retorna una lista de Citas de examen

mdico pendientes de la fecha actual de la consulta.
ObtenerCitasEM_Activadas
Esta funcin retorna una lista de Citas de examen
mdico activadas de la fecha actual de la consulta.
ActivarCitaEM
Este procedimiento activa una Cita de examen
mdico pendiente.
TerminarCitaEM
Este procedimiento termina una Cita de examen
mdico activada.
WSObtenerResultadoEM
ObtenerResultadoEM_x_DetalleEM
SISREGAME
Esta funcin retorna una entidad resultado de

examen mdico de acuerdo a un cdigo de detalle de
examen mdico ingresado.
WSObtenerEncuentroGeneral
ObtenerEncuentroNino
SISREGAME
Esta funcin retorna una entidad del tipo encuentro

nio de acuerdo a un cdigo de encuentro general
ingresado.
ObtenerEncuentroAdolescente
adolescente de acuerdo a un cdigo de encuentro
general ingresado.

ObtenerEncuentroAdulto
adulto de acuerdo a un cdigo de encuentro general
ingresado.
ObtenerEncuentroAdultoMayor
adulto mayor de acuerdo a un cdigo de encuentro
general ingresado.
WSListarSignosPeligroNino
ListarSignosPeligroNino
SISREGAME
Esta funcin retorna una lista de signos de peligro

del nio de acuerdo a la edad ingresada.
WSEpisodioGeneral
RegistrarEpisodioGeneral
SISREGAME
Esta funcin registra un episodio general y retorna el

cdigo de episodio general asignado.
ObtenerEpisodio_entre_Fechas
Esta funcin retorna una lista de episodios mdicos
generales, de acuerdo a las fechas ingresadas y al
cdigo del paciente ingresado.
ObtenerEpisodiosGenerales_x_Paciente
Esta funcin retorna una lista de los 5 ltimos
episodios mdicos generales de acuerdo al cdigo
del paciente.
WSListarCategoriasAdultoMa
ListarCategoriasAdultoMayor
yor
Esta funcin retorna una lista de categoras de
SISREGAME
clasificacin
del
adulto
mayor.
(p.e.
Saludable,Geriatrico Complejo, Enfermo,etc).

WSListarEncuentrosGenerale
ListarEncuentrosGenreales_x_Episodio
Esta funcin retorna una lista de cabeceras de
111

SISREGAME
encuentros generales de acuerdo al cdigo de

episodio general ingresado.
WSRegistrarEncuentroGener
RegistrarEncuentroNino
al
Esta funcin permite registrar un encuentro de tipo
SISREGAME
nio y retorna el cdigo asignado al registro.

RegistrarEncuentroAdolescente
adolescente y retorna el cdigo asignado al registro.
RegistrarEncuentroAdulto
adulto y retorna el cdigo asignado al registro.
RegistrarEncuentroadultoMayor
adulto mayor y retorna el cdigo asignado al
registro.
WSObtenerParametrosDiagno
Listar_Estados_x_Parametro
stico
Esta funcin retorna una lista de estados de los
SISREGAME
diferentes tipos de diagnsitco de los formatos de

encuentro nio y encuentro adulto mayor.
Listar_Tiempos
Esta funcin retorna una lista de tiempos para cargar
el tiempo de enfermedad de los formatos.
WSRegistrarRecetaMedica
RegistrarRecetaMedica
SIREGAME
Este procedimiento permite registrar una orden de

receta mdica y una lista de detalle de receta mdica.
WSObtenerRecetaMedica
ObtenerOrdenRM
SIREGAME
Esta funcin retorna la cabecera de una orden de

receta mdica de acuerdo al cdigo ingresado.
ObtenerDetalleRM

Esta funcin retorna la lista de detalle de receta
mdica de acuerdo al nmero de orden de receta
mdica ingresado
WSAdmExamenMedico
ObtenerLineasEM
SISREGAME
Esta funcin retorna una lista de las lneas de
Externo
exmenes mdicos.
ObtenerTiposEM
Esta funcin Obtiene los Tipos de examen mdico
de acuerdo al cdigo de lnea de examen mdico
ingresado.
ObtenerExamenesMedicos
Esta funcin retorna una lista de exmenes mdicos
de acuerdo al cdigo de tipo de examen mdico
ingresado.
ObtenerUnTipoEM
Esta funcin retorna un Tipo de Examen Mdico de
acuerdo al cdigo de Tipo de exmen mdico
ingresado.
ObtenerUnaLineaEM
Esta funcin retorna una Lnea de Examen Mdico
de acuerdo al cdigo de Lnea de examen mdico
ingresado.
ObtenerUnEstadoEM
Esta funcin retorna un Estado de Examen Mdico
de acuerdo al cdigo de Estado de examen mdico
ingresado.
ObtenerUnExamenMedico
Esta funcin retorna un Examen Mdico de acuerdo
al cdigo de examen mdico ingresado.
WSObtenerOrdenEM
ObtenerUnaOrdenEM
SISREGAME
Esta funcin retorna la cabecera de orden de examen

mdico de acuerdo al nmero de orden de examen
mdico ingresado
113

ObtenerDetalleOrdenEM
Esta funcin retorna la lista de detalle de orden de
examen mdico de acuerdo al nmero de orden de
examen mdico ingresado
ObtenerDetallesOrden_x_OrdenCita_x_EstadoD
etalle
Esta funcin retorna la lista de detalle de orden de
examen mdico en estado pendiente de registro, en
base al nmero de orden de dita de examen mdico
ingresado.
ObtenerExamenesMedicos_x_KDetalleOrdenEx
Medicos
Esta funcin retorna un examen mdico de acuerdo

al cdigo de detalle de orden de examen mdico
ingresado.
WSRegistrarResultadoEM
RegistrarResultadoEM
SISREGAME
Este procedimiento permite registrar el resultado de

un examen mdico de laboratorio.
WSRegistrarOrdenEM
RegistrarOrdenEM
SISREGAME
Este procedimiento permite registrar una orden de

examen mdico y una lista de detalle de orden de
examen Mdico.
Tabla 4.2 Tabla de servicios

Los Servicios que han sido identificados en el punto 3.3.1 estarn disponibles de tal
manera que se puedan reutilizar.
Composicin y coreografa de procesos de negocio
Procesos de negocio en coreografa

El proceso del negocio al cual SISREGAME pretende automatizar y sistematizar
mediante una solucin software es el proceso core Prestacin de Servicios Clnicos
identificado por el proyecto Modelamiento de procesos empresariales para una entidad
mdica de nivel I-3 de complejidad. El modelo de procesos es el siguiente:
115
Figura 4.4 Proceso de Prestacin de Servicios Clnicos


Asimismo, se presenta el modelo de actividades del proceso Control de
Exmenes Mdicos.
Figura 4.5 Modelo de Procesos Control de Exmenes Mdicos

Fuente: Memoria Modelamiento de procesos empresariales para una entidad mdica de
nivel I-3 de complejidad
117
Este proceso est vinculado a los servicios descritos en el inciso 3.3.1. Los
servicios se relacionan con las diversas actividades del proceso, de la manera
siguiente:
Actividad
Asistir a consulta en el horario pactado
Servicios involucrados
WSCECitas
WSCitasEM
WSPersonalSalud
WSAreaServicio
WSPaciente
Consultar Historial Clnico (Actualizar Historial WSPersonalSalud

Clnico)
WSEpisodioGeneral
WSListarCategoriasAdultoMayor
WSListarEncuentrosGenerales
WSRegistrarEncuentroGeneral
WSObtenerParametrosDiagnostico
WSObtenerOrdenEM
Registrar Evolucin
WSPersonalSalud
WSPaciente
WSEpisodioGeneral
Dar un Diagnstico (Registrar Tratamiento, WSListarMedicamentos

Registrar Receta Mdica, Registrar Orden de
WSAreaServicio
Examen
mdico,
Registrar
Orden
de
Medicamentos)
WSPaciente

WSAdmExamenMedico
WSRegistrarOrdenEM
Transferencia (Registrar Orden de Transferencia) WSPersonalSalud
WSAreaServicio
WSPaciente
Registrar Diagnstico de Muestra
WSAdmExamenMedico
WSRegistrarResultadoEM
Revelado de imgenes (solo registro de WSAdmExamenMedico

observaciones)
Tabla 4.3 Tabla de Actividad - Servicio
Los servicios web sern desplegados en el servidor web y debern

estar disponibles para su posterior consulta.
La comunicacin a travs de servicios deber contar con un
mecanismo de seguridad que asegure la informacin, de esta
manera, se garantizar la proteccin de la informacin. Este
mecanismo no se concretar para la presente versin del sistema.
Sin embargo, se documentar datos importantes dela realizacin
del proceso de firmas digitales para garantizar la proteccin de la
informacin.
Presentacin o Acceso
Esta capa contiene a los portlets desarrollados que sern albergados en el
administrador de contenidos Liferay 5.2.3 cuyo proveedor es Liferay. Esta
herramienta contiene un administrador de roles y usuario con lo cual provee
seguridad y presentacin de aplicaciones de acuerdo a las capacidades de los
usuarios; adems, contiene una aplicacin portlet de autenticacin.
El protocolo que se utiliza para la exposicin de los porlets es WSRP v2.0
que permite que las aplicaciones se publiquen o expongan como web
services. Los portlets estarn anidados a un servlet que ser el controlador de
los eventos del java server page contenido en ellos.
Los portlets v2.0 que se realicen debern tener una interfaz diseada a fin de
que sea sencilla e intuitiva. Las opciones y funcionalidades del sistema se
mostrarn al usuario de una manera tal, que pueda navegar a travs de l y
satisfacer las acciones que desee realizar sin informacin adicional en el
sistema.
El Sistema de Registro de Atencin Mdica cumplir con estndares para
el diseo de las interfaces. Se emplear el uso de botones, formularios y
toolltips para que el usuario pueda navegar por el sistema sin problemas.
Adems, el sistema deber mantener un estilo y combinacin de colores para
119

no generar stress en el usuario.
Figura 4.6 Portlet Historial Clnico

Integracin
En consideracin que los servicios sern brindados y consumidos por sistemas
que pertenecen al Sistema Integral de Salud, el modelo de integracin no tiene
tanta complejidad.
Los servicios que se requiere para cumplir con los objetivos de SISREGAME
son los siguientes:
Sistema
Sistema
de
Registro
Servicio
Mdico ObtenerPaciente
Electrnico
Adicionalmente, aparte del servicio que brinda

este proyecto, proporcionar un portlet de registro
de orden de referencia.
ObtnerMedicamentos_x_Nombre
ObtnerMedicamentos_x_CMedicamento
Sistema de Consulta Odontolgica
Con Este proyecto se realizar la integracin por

exposicin de portlets. El portlet en comn ser

Diagnstico y Prescripcin Mdica.
ObtenerCitasEM_Pendientes
ObtenerCitasEM_Activadas
ActivarCitaEM
TerminarCitaEM
ActivarCita
ObtenerCitasPendientes
ObtenerCitasActivadas
TerminarCita
ObtnerCitasPendientes_x_AreaServicio
Tabla 4.4 Tabla de Servicio - Sistema

Consideraciones del ESB

Los sistemas que se realizan dentro de la empresa Salud-Able obedecen a un
estndar, es por ello que no se ha visto conveniente el uso del ESB; debido a
que este responde a la necesidad de integrar sistemas incompatibles.
Presentacin o Acceso
Aseguramiento de los SLA

a)
De acuerdo a la arquitectura planteada, se est asegurando un 98,00%

al periodo acadmico sin incluir cualquier falla que se presente a
nivel de hardware. Para asegurar esta propuesta se realizarn pruebas
de stress y de carga y mediante estadsticas de desempeo se
corregirn las configuraciones de software como de hardware.
b)
Las transacciones que se realicen dentro de la aplicacin debern

tomar un tiempo no mximo de 20 segundos.
Aseguramiento de los QoS
a) El uso de firmas digitales ser implementado para asegurar el no repudio
121
y la autenticidad de los mensajes que viajen por el canal.

Temas y decisiones de seguridad

a) Para el tema de la autenticacin se utilizar la aplicacin brindada por el
Liferay 5.2.3
b) La vista de aplicaciones portlet se controlar, de igual manera, con la
herramienta de administracin de contenidos Liferay 5.2.3
Limitaciones y decisiones sobre la tecnologa y estndares
a) La tecnologa a usar deber ser OpenSource.
b) El IDE de desarrollo escogido es NetBeans 6.7.1 y el lenguaje de
c)
d)
e)
f)
g)
h)
desarrollo es JAVA.
El servidor para el despliegue web es Glassfish v2.1.1
El administrador de contenidos que se utilizar es Liferay 5.2.3 Esta
herramienta brindar los medios de autenticacin para administrar las
capacidades de los usuarios del sistema.
Los estndares a utilizar en la base de datos y codificacin es la adoptada
por la empresa Salud-able.
As mismo, los requerimientos no funcionales se han realizado en
funcin del estndar de seguridad de salud brindada por la HIPAA
(Health Insurance Portability and Accountability Act ).
Para el periodo acadmico 2010-02, la empresa IT Expert solo
cumplir con las siguientes caractersticas.
Servidor con procesador QuadCore 2.5 Ghz/RAM 2Gb
Sin embargo, para el prximo periodo acadmico 2011-01 se adquirir
un servidor que cumplir con los requerimientos establecidos
Despliegue de la Solucin
Esta seccin describe los componentes que harn posibles que SISREGAME
sea desplegado con xito y que sus funcionalidades se encuentren
disponibles en la estacin de trabajo.
El sistema puede ser desplegado en una plataforma Windows Server o Linux.
Dado a que las herramientas utilizadas para el despliegue del sistema son
OpenSource, estas pueden ser instaladas en cualquiera de estas plataformas.
A continuacin se presenta la descripcin de componentes para el despliegue
del sistema:
Requerimientos de Hardware
Esta caracterstica ser para albergar tanto los servidores ESB, de Base de
Datos y Web (que representa el Liferay 5.2.3)
a) Procesador QuadCore o similar 2.5Ghz
b) Memoria RAM 4Gb
Servidor Web

Servidor dentro del cual se despliega la aplicacin, de manera que se
encuentre disponible mediante la Web.
Requerimientos de Software: Glassfish v2.1.1.
Servidor de Base de Datos

Servidor que soportar la ejecucin de las transacciones para la gestin de
datos del sistema.
Requerimientos de Software: MySQL 5.1.
Administrador de Contenidos
Es aquel que alberga los portlets desplegados y controla las capacidades de
los usuarios para la vista de las aplicaciones permitidas a los mismos.
Requerimientos de Software: Liferay 5.2.3.
PC del Usuario
Es la estacin de trabajo donde los actores del sistema ejecutarn las
funcionalidades necesarias.
Requerimientos de Software: Navegador Web (Internet Explorer 7.0 o
superior/Mozilla 4.0).
123
INTERNET
Zona Desmilitarizada
Servidor Web
Firewall
Estacin de Servidores
Estacin de Trabajo
Servidor ESB
Servidor Adm. De Contenidos
Switch
Servidor de BD
IP Conocida
Figura 4.7 Diagrama de Despliegue

Temas y decisiones de desempeo

Las transacciones que se realicen no deben tomar un tiempo mayor a 20
segundos.
El sistema deber soportar como mximo a 5 usuarios operando de manera
paralela.
El servidor que albergue el sistema deber tener como mnimo 100Gb de
disco duro, 3Gb de memoria RAM.
El sistema deber estar activo durante toda la jornada laboral del centro de
salud (09:00am 06:00pm).
CAPTULO 5. DISEO DETALLADO18
Este captulo contendr informacin del diseo de la base de datos.
Introduccin
En este captulo se presentar el diseo de la base de datos del sistema y los
diferentes componentes establecidos para el soporte de la arquitectura del sistema.
Diseo de la base de datos
Diseo Fsico
A continuacin se mostrar el diseo fsico de la base de datos. Se debe
tener en cuenta, que las tablas celestes son las que representan al sistema,
mientras que las que se encuentran de un color diferente simulan las
conexiones de estas con las tablas de los otros sistemas de la empresa SaludAble.
18
Ver Anexo 3. Se muestra el documento de diseo detallado.
Figura 5.1 Diseo Fsico de la Base de Datos

Captulo 5: Diseo Detallado
Diccionario de Datos
Tablas
Nombre Tabla
Episodio
Descripcin
Es el motivo por el cual se genera la
consulta por primera vez.
Prescripcion
Es la receta dada por el mdico que no

involucra
exmenes
frmacos.
Por
mdicos
ejemplo:
Descanso
mdico de 5 das.
recetaMedica
Almacena la fecha y la consulta en que

se le recetaron los medicamentes.
detalleRecetaMedica
Almacena los medicamentos que se

recetarn al paciente.
encuentroGeneral
Contiene la informacin comn a los

encuentros (consultas) de una consulta
general.
encuentroNino
Contiene la informacin especfica del

encuentro (consulta) del nio en una
consulta general.
encuentroAdolescente

encuentro (consulta) del adolescente
en una consulta general.
encuentroAdulto

encuentro (consulta) del adulto en una
consulta general.
encuentroAdultoMayor

encuentro (consulta) del adulto mayor
127

en una consulta general.
ordenExamenMedico
Contiene la fecha en que se realiza la

orden de examen mdico al paciente.
detalleOrdenEM
Contiene los exmenes mdicos que se

debe realizar el paciente.
resultadoEM
Contiene
los
resultados
de
los
exmenes mdicos del paciente.

estadoEM
Contiene el estado de los exmenes

mdicos.
Estado
Indica el estado nutricional del nio.
claseDiagnostico
Indica el parmetro nutricional del

nio. Este puede ser P/E (Peso para la
edad), T/E (talla para la edad), P/T
(peso para la talla).
parametroDiagnostico
Indica el estado nutricional del nio

segn la clase de diagnstico.
tipoDiagnostico
Contiene el tipo de diagnstico. Puede

ser
Reiterativo,
Presuntivo
Definitivo.
Diagnostico
Contiene el diagnstico del paciente,

es decir, las enfermedades que posee
con el CIE 10 respectivo.
EtapaVida
Indica las etapas de vida del paciente.
Signo_x_etapavida
Indica los sntomas del paciente por

etapa de vida.
SignoPeligro
Indica los sntomas del paciente.
Categora_adulto_mayor
Indica la categora del adulto mayor.

Esta puede ser saludable, enfermo,
frgil o geritrico complejo.
128
Detalle de Tablas
Areaservicio_x_centromedico
Campo
Tipo
Nulo
Llave
K_CentroMedico
int(11)
No
PK
K_AreaServicio
int(11)
No
PK
Extra
categoriaadultomayor
Campo
Tipo
Nulo
K_CategoriaAdultoMayor Int(11)
No
N_CategoriaAdultoMayor varchar(20)
Si
F_Activo
Si
binary(1)
Llave
PK
Extra
auto_increment
categoriaadultomayor
Campo
Tipo
Nulo
K_CategoriaAdultoMayor Int(11)
No
N_CategoriaAdultoMayor varchar(20)
Si
F_Activo
Si
binary(1)
Llave
PK
Extra
auto_increment
Cie10capitulo
Campo
K_cie10Capitulo
Tipo
int(11)
Nulo
No
Llave
PK
Extra
auto_increme
nt
N_Capitulo
varchar(20)
Si
T_descripcionCapitulo
varchar(50)
Si
Cie10Enfermedad
Campo
129
Tipo
Nulo
C_cie10Enfermedad
int(11)
No
K_codigoEnfermedad
int(11)
No
Llave
PK
Extra
auto_increment

N_Enfermedad
varchar(50)
Si
C_cie10Subcapitulo
int(11)
Si
FK
Cie10SubCaputulo
Campo
Tipo
Nulo
K_cie10Subcapitulo
int(11)
No
T_descripcionSubcapitulo
varchar(50)
Si
C_cie10Capitulo
int(11)
Si
Llave
PK
Extra
auto_increment
FK
ClaseDiagnostico
Campo
Tipo
Nulo
K_ClaseDiagnostico
int(11)
No
N_claseDiagnostico
varchar(20) No
Llave
PK
Extra
auto_increment
DetalleOrdenExamenMedico
Campo
Tipo
Nulo
Llave
K_DetalleOrdenEM
int(11)
No
PK
F_Muestra
binary(1)
Si
C_ExamenMedico
int(11)
Si
FK
K_OrdenEM
int(11)
No
PK
C_EstadoEM
int(11)
Si
FK
C_TipoExamenMedico
int(11)
Si
Extra
auto_increment
DetalleRecetaMedica
Campo
Tipo
Nulo
K_Medicamentos
int(11)
No
A_Cantidad
int(11)
No
T_Indicaciones
varchar(200
No
Llave
FK
Extra
auto_increment
130

K_DetalleRM
int(11)
No
PK
K_RecetaMedica
int(11)
No
PK
Diagnostico
Campo
Tipo
Nulo
No
Llave
C_Diagnostico
int(11)
PK
T_descripcionDiagnostico
varchar(400) Si
D_fechaCreacion
Date
No
K_ClaseDiagnostico
int(11)
Si
FK
K_tipoDiagnostico
int(11)
Si
FK
K_Encuentro
int(11)
Si
FK
K_Paciente
int(11)
Si
C_cie10Enfermedad
int(11)
Si
T_FactoresDet
varchar(200) Si
Extra
auto_increment
FK
Encuentroadolescente
Campo
Tipo
Nulo
Llave
C_Turno
int(11)
Si
FK
K_Encuentro
int(11)
No
PK
T_Motivo
varchar(1000
Si
)
A_TiempoEnfermedad
decimal(18,2) Si
T_EstadoAnimo
varchar(300)
Si
T_Sueo
varchar(300)
Si
T_Apetito
varchar(300)
Si
T_Orina
varchar(300)
Si
T_Sed
varchar(300)
Si
T_Deposiciones
varchar(300)
Si
A_Temperatura
decimal(18,2) Si
A_PresionArterialSistole
decimal(18,2) Si
A_FC
decimal(18,2) Si
131
Extra
auto_increment

A_FR
decimal(18,2) Si
A_Peso
decimal(18,2) Si
A_Talla
decimal(18,2) Si
T_Observaciones
varchar(1000
Si
)
A_IMC
decimal(18,2) Si
D_ProximaCita
Date
Si
K_Cita
int(11)
Si
FK
Encuentroadulto
Campo
Tipo
Nulo
Llave
C_Turno
int(11)
Si
FK
K_Encuentro
int(11)
No
PK
T_Motivo
varchar(1000) Si
A_TiempoEnfermedad
decimal(18,2) Si
T_EstadoAnimo
varchar(300)
Si
T_Sueo
varchar(300)
Si
T_Apetito
varchar(300)
Si
T_Orina
varchar(300)
Si
T_Sed
varchar(300)
Si
T_Deposiciones
varchar(300)
Si
A_Temperatura
decimal(18,2) Si
decimal(18,2) Si
A_FC
decimal(18,2) Si
A_FR
decimal(18,2) Si
A_Peso
decimal(18,2) Si
A_Talla
decimal(18,2) Si
T_Observaciones
varchar(1000) Si
A_IMC
decimal(18,2) Si
D_ProximaCita
Date
Si
K_Cita
int(11)
Si
Extra
auto_increment
FK
132

Encuentroadultomayor
Campo
Tipo
Nulo
Llave
C_Turno
int(11)
Si
FK
K_Encuentro
int(11)
No
PK
T_Motivo
varchar(1000) Si
A_TiempoEnfermedad
decimal(18,2) Si
T_EstadoAnimo
varchar(300)
Si
T_Sueo
varchar(300)
Si
T_Apetito
varchar(300)
Si
T_Orina
varchar(300)
Si
T_Sed
varchar(300)
Si
T_Deposiciones
varchar(300)
Si
A_Temperatura
decimal(18,2) Si
decimal(18,2) Si
A_FC
decimal(18,2) Si
A_FR
decimal(18,2) Si
A_Peso
decimal(18,2) Si
A_Talla
decimal(18,2) Si
T_Observaciones
varchar(1000) Si
A_IMC
decimal(18,2) Si
D_ProximaCita
Date
Si
K_Cita
int(11)
Si
Extra
auto_increment
FK
Encuentronino
Campo
Tipo
Nulo
K_Encuentro
int(11)
No
T_Motivo
varchar(1000
Si
)
A_TiempoEnfermedad
decimal(18,2) Si
A_Temperatura
decimal(18,2) Si
decimal(18,2) Si
133
Llave
PK
Extra
auto_increment

A_FC
decimal(18,2) Si
A_FR
decimal(18,2) Si
A_Peso
decimal(18,2) Si
A_Talla
decimal(18,2) Si
T_ExamenFisicoObservaciones
varchar(1000
Si
)
D_ProximaCita
Date
Si
K_Cita
int(11)
Si
D_FechaEncuentro
Date
No
K_Episodio
int(11)
Si
FK
K_Paciente
int(11)
No
PK
K_PersonalSalud
int(11)
Si
FK
D_HoraEncuentro
Time
Si
A_Edad
decimal(18,2) Si
C_SignosPeligro
varchar(200)
FK
Si
Episodio
Campo
Tipo
Nulo
K_Episodio
int(11)
No
D_Anio
year(4)
No
K_CentroMedico
int(11)
No
K_AreaServicio
int(11)
No
C_Episodio
varchar(7)
No
C_TipoEtapaVida
char(1)
No
K_Paciente
int(11)
No
Llave
PK
Extra
auto_increment
FK
Estado
Campo
Tipo
Nulo
K_Estado
int(11)
No
N_Estado
varchar(50)
Si
Llave
PK
Extra
auto_increment
134

Examenmedico
Campo
Tipo
Nulo
K_ExamenMedico
int(11)
No
N_ExamenMedico
varchar(200)
Si
A_ValorMinimoHombre
decimal(18,2) Si
A_ValorMaximoHombre
decimal(18,2) Si
A_ValorMinimoMujer
decimal(18,2) Si
V_ValorMaximoMujer
decimal(18,2) Si
A_UnidadMedida
varchar(10)
Si
C_TipoExamenMedico
int(11)
Si
Llave
PK
Extra
auto_increment
FK
Estadoexamenmedico
Campo
Tipo
Nulo
C_EstadoEM
int(11)
No
N_Estado
varchar(20)
Si
N_Abreviatura
varchar(20)
Si
Llave
Extra
Llave
Extra
PK
Etapavida
Campo
Tipo
Nulo
K_EtapaVida
int(11)
No
N_EtapaVida
varchar(200)
Si
A_EdadDesde
decimal(18,2) Si
A_EdadHasta
decimal(18,2) Si
PK
auto_increment
Lineaexamenmedico
Campo
Tipo
Nulo
K_CodLinea
int(11)
No
N_Linea
varchar(20)
Si
135
Llave
PK
Extra
auto_increment

MedicamentosxEspecialidad
Campo
Tipo
Nulo
K_Medicamentos
int(11)
No
PK
K_Especialidad
Int(11)
No
PK
Llave
Extra
Llave
Extra
Ordenexamenmedico
Campo
Tipo
Nulo
K_OrdenEM
int(11)
No
PK
D_Fecha
datetime
No
C_EmitidoPor
int(11)
Si
N_PersonalSalud
varchar(200) Si
C_EstadoEM
int(11)
Si
FK
K_Encuentro
int(11)
Si
FK
K_Paciente
int(11)
Si
C_TipoEtapaVida
char(1)
No
auto_increment
Paciente
Campo
Tipo
Nulo
K_Paciente
int(11)
No
N_Nombre
varchar(100)
Si
N_ApellidoPaterno
varchar(100)
Si
N_ApellidoMaterno
varchar(100)
Si
A_Edad
decimal(18,2) Si
C_HistoriaClinica
varchar(15)
Si
C_AfiliacionPaciente
varchar(15)
Si
C_SiS
varchar(15)
Si
Llave
PK
Extra
auto_increment
136

Parametrodiagnostico
Campo
Tipo
Nulo
Llave
K_ParametroDiagnostico
int(11)
No
PK
N_ParametroDiagnostico
varchar(50)
No
K_ClaseDiagnostico
int(11)
Si
FK
K_Estado
int(11)
Si
FK
Extra
auto_increment
Personaldesalud
Campo
Tipo
Nulo
K_PersonalSalud
int(11)
No
N_Nombre
varchar(100) Si
N_ApellidoPaterno
varchar(100) Si
N_ApellidoMaterno
varchar(100) Si
N_Abreviatura
varchar(10)
Llave
PK
Extra
auto_increment
Si
Prescripcin
Campo
Tipo
Nulo
K_Prescripcion
int(11)
No
T_Descripcion
varchar(200) Si
K_Encuentro
int(11)
Si
C_Prescripcion
varchar(11)
Si
K_Paciente
int(11)
Si
C_TipoEtapaVida
varchar(15)
Si
Llave
PK
Extra
auto_increment
FK
Recetamedica
Campo
Tipo
Nulo
Llave
K_RecetaMedica
int(11)
No
PK
K_Encuentro
int(11)
No
FK
C_RecetaMedica
varchar(7)
No
D_Fecha
Datetime
No
137
Extra
auto_increment

K_Paciente
int(11)
Si
C_TipoEtapaVida
char(1)
No
Resultadoexamenmedico
Campo
Tipo
Nulo
C_ResultadoEM
int(11)
No
A_ValorResultado
decimal(18,2) Si
T_Observaciones
varchar(500)
Si
C_DetalleOrdenEM
int(11)
Si
C_TipoExamenMedico
int(11)
Si
C_PersonalMedicoEjecutor
int(11)
Si
D_FechaRealizacion
Timestamp
Si
K_OrdenEM
int(11)
Si
Llave
Extra
Llave
Extra
Llave
Extra
PK
FK
Signo_x_etapavida
Campo
Tipo
Nulo
K_SignoPeligro
int(11)
No
PK
K_EtapaVida
int(11)
No
PK
Signopeligronino
Campo
Tipo
Nulo
K_SignoPeligro
int(11)
No
T_DescripcionSignoPeligro
varchar(400) Si
PK
auto_increment
Tipodiagnostico
Campo
Tipo
Nulo
K_tipoDiagnostico
int(11)
No
N_TipoDiagnostico
varchar(20)
No
Llave
PK
Extra
auto_increment
Tipoexamenmedico
138

Campo
Tipo
Nulo
Llave
K_TipoExamenMedico
int(11)
No
PK
C_CodLinea
int(11)
Si
FK
N_TipoExamenMedico
varchar(20)
Si
Extra
auto_increment
Turno
Campo
Tipo
Nulo
K_Turno
int(11)
No
N_Turno
varchar(20)
Si
D_HoraInicio
Date
Si
D_HoraFin
Date
Si
139
Llave
PK
Extra
auto_increment
Descripcin del Componente
A continuacin se detallar los componentes que se utilizaron a lo largo del desarrollo

del sistema. La plataforma en la que se implementaron cada uno de ellos es Java.
Identificacin tcnica del componente / ECS
USUARIOS
Arquitectura de SISREGAME
Presentacin
Lgica de
Servicios
Negocios
Interface de
Entidades del
A. a Datos
Negocio
Acceso a
Datos
MySQL 5.1
db_saludable

140
INTERNET
Zona Desmilitarizada
Servidor Web
Firewall
Estacin de Servidores
Estacin de Trabajo
Servidor ESB
Servidor Adm. De Contenidos
Switch
Servidor de BD
IP Conocida

El diagrama anterior presenta una visin general de la arquitectura del

sistema SISREGAME. El modelo de referencia arquitectural que se ha
establecido es SOA (Arquitectura Orientada a Servicios). A continuacin, se
presentar en detalle los componentes que pertenecen a cada capa
arquitectural del sistema:
CAPA DE PRESENTACIN
La tecnologa utilizada para satisfacer los requerimientos del sistema en la
capa de presentacin fue hacer uso de portlets en su versin 2.0. Los
portlets son componentes que permiten la integracin de aplicaciones a nivel
de interfaz de usuario y, un acceso personalizado. Adems, se permite
cumplir el patrn MVC (Model View Controller Modelo Vista
Controlador). La arquitectura principal de la capa de presentacin ser:
141
Portlet (.WAR)
DISPATCHER
Controlador
Lgica de
Negocio
Modelo
Vista
Portlet
Servlet
Request
Request
Response
Liferay 5.2.3
Response
JSPs
Servicios
Web
Servicios del Portal
Informacin
Recursos
de
de
Usuarios
Acceso
Persistencia

Liferay 5.2.3 es el componente que se encarga de gestionar los portlets a los

cuales el usuario tiene privilegios de acceso. Es el administrador de
contenidos que permite que el usuario personalice la vista de las aplicaciones
que tiene disponible.
La vista est compuesta por los JSPs (Java Server Pages) asociados con los
portlets y los stylesheets.
El componente controlador contiene los servlets asociados con los JSPs. El
nombre del paquete que contiene los componentes controladores en el
sistema SISREGAME es upc.saludable.sisregame.servlet. Los servlets se
encargan de atender las peticiones de la pgina y de acuerdo a las mismas se
encargar de establecer conexin con los componentes de lgica de negocio
del sistema.
142

-
CAPA DE LOGICA DEL NEGOCIO

Est compuesta por los componentes que se encargarn de definir las
funciones y procedimientos necesarios para el cumplimiento de un caso de
uso o proceso. El paquete dentro de la estructura del sistema que contiene los
componentes
de
lgica
de
negocio
se
denomina
upc.saludable.sisregame.BusinessLogic. Adems estos componentes deben

invocar a las interfaces que permiten implementar a los componentes de
Acceso a Datos para poder intercambiar datos a travs de las entidades del
negocio.
Los componentes establecidos para esta capa son:
1. BLConsultaExterna
2. BLExamenMedico
-
CAPA DE SERVICIOS
El paquete dentro de la estructura del sistema que contiene los componentes
de
servicios
se
denomina
upc.saludable.sisregame.Service.
Los
componentes que pertenecen a esta capa se encargan de exponer

procedimientos y funciones que permitirn la interaccin con las diferentes
aplicaciones que forman parte del Sistema Integral de Salud. La tecnologa
que se usa para exponer los mtodos es WEB SERVICE.
Los componentes de servicio se encuentran especificados en el documento

SISREGAME SAD. Estos componentes se comunican con los
componentes de Lgica de Negocio. Los componentes se identifican con el
prefijo WS<Nombre de Servicio>.
CAPA DE ENTIDADES DEL NEGOCIO

Los componentes que pertenecen a esta capa son aquellos que permiten el
transporte de la informacin a travs de las diferentes capas establecidas en
el sistema. El nombre del paquete que contiene estos componentes es
upc.saludable.sisregame.BusinessEntities. El rol de las entidades es definir
143

el dominio del proyecto y que los datos viajen a travs del sistema de manera
segura, organizada y encapsulada.
Las entidades del negoci pertenecientes al sistemas se encuentran en la
seccin Estructura Interna/Diagrama de Clases ER.
Todos los componentes se identifican por el prefijo BE<Nombre de
Entidad>.
CAPA DE ACCESO A DATOS

de servicios se denomina upc.saludable.sisregame.DataAccess. Los
componentes que pertenecen a este paquete gestionarn el acceso a la base
de datos del sistema para poder realizar actividades de seleccin, insercin,
actualizacin o de eliminar registros de la misma.
Dentro de esta capa existe una clase DataSource que se encarga de solicitar a
la clase ServiceLocator una conexin bridada por el servidor de aplicaciones
Glassfish establecidas con la base de datos para cualquier actividad. Esta
clase hace uso del patrn de diseo Singleton para obtener las conexiones
abiertas.
Cada clase de la capa de acceso a datos implementar una interface lo que
permitir la separacin del mtodo y firma de un procedimiento o funcin.
CAPA DE INTERFACES
de servicios se denomina upc.saludable.sisregame.Interfaces. Estos
componentes permitirn exhibir las firmas de los procedimientos y servicios
del sistema que gestionan el acceso a la informacin almacenada en la base
de datos. Permite que se separe el mtodo o el cmo se implementa el acceso
a datos del qu se desea realizar.
Requerimientos de Operacin
En general, los componentes del sistema SISREGAME para la mayora de
operaciones seguirn la misma estructura de dependencia.
144

Componentes de Presentacin (Dependencias)
1. BE (upc.saludable.sisregame.BusinessEntities)
2. WS (upc.saludable.sisregame.ServiciosWeb)
3. Listas (java.utils)
4. PortalPack Plugin (Liferay.*)
Componentes de Lgica de Negocio (Dependencias)
2. IS (upc.saludable.sisregame.Services)
3. Interfaces (upc.saludable.sisregame.Interfaces)
4. DA (upc.saludable.sisregame.DataAccess)
Componentes de Servicio (Dependencias)
2. BL (upc.saludable.sisregame.BusinessLogic)
Componentes de Interfaces (Dependencias)
Componentes de Acceso a Datos (Dependencias)
2. Componentes de Acceso a Datos (java.sql)
3. Clase DataSource
4. Clase ServiceLocator
5. Driver de Conexin (com.mysql.jdbc.Driver)
Las dependencias de operacin en cuanto a otros componentes, tanto
desarrollados para el proyecto como los que no, se encuentran en el apartado
Dependencias de Compilacin dentro de este mismo documento. En cuanto
al Software y Hardware base requeridos por la aplicacin se encuentran los
siguientes:
145

Software
Netbeans 6.71
GlassFish Server 2.1.1
Liferay 5.2.3
Mysql 5.1
Navegadores: Internet Explorer 8 o Firefox 3
Hardware (Requerimientos mnimos)
Ram: 4 Gb (para servidor de aplicaciones) 2 GB (Servidor de Base de Datos)

Procesador: Intel Quad Core 2.5 GHz (o superior)
HDD: 160 GB (o superior).
Interface de Aplicacin
Las interfaces de aplicacin para el presente proyecto se centran
principalmente, de acuerdo a la arquitectura adoptaba, en servicio web. A
continuacin se identificarn los Servicios que expone SISREGAME.
WSPersonalSalud
Este servicio fue creado, con fines de poder completar con la funcionalidad
de los casos de uso del presenta sistema. Sin embargo, este no forma parte de
los servicios propios de SISREGAME. Su funcin es retornar informacin
acerca de un trabajador del centro de salud, que en el contexto del negocio se
le conoce como personal de salud. Este involucra, por ejemplo, a un mdico
general, odontlogo, tcnico de laboratorio, etc.
Declaracin de la Firma
ObtenerPersonalSaludXCorreo
Esta funcin retorna un Personal de la Salud de acuerdo al correo
ingresado.
ObtenerPersonalSalud
Esta funcin retorna un Personal de la Salud de acuerdo al cdigo
ingresado
Excepciones Generadas
Se est haciendo uso del try{} catch{} finally{}, de modo que la solucin a
las excepciones que se encuentren se resolvern dentro del catch{} de la
aplicacin.
Punto o mecanismo de acceso
El punto de acceso para ejecutar estas funciones, est establecido en los
contratos (WSDL). De necesitar, algn sistema externo establecer conexin
146

con este servicio deber referenciar a la url del WSDL que genera una serie
de clases en la aplicacin cliente, necesarias para su correcto
funcionamiento.
WSAreaServicio
acerca de las diferentes reas de servicio registradas en un centro de salud,
tambin son conocidas como unidades productoras de servicios. Por ejemplo:
Medicina General, Odontologa, etc.
ObtenerTodasConsultasAreaServicio
Esta funcin retorna una lista de reas de Servicio que ejecutan consultas
de atencin externa. (p.e Medicina General, Odontologa).
ObtenerAreaServicio_x_Proyecto
Esta funcin retorna el rea de servicio que ejecuta consulta externa de
acuerdo al cdigo de proyecto interno ingresado. (p.e. si ingresamos 730
que es el cdigo de proyecto de SISREGAME devolver el cdigo de
Medicina General que se encuentre en la BD).
ObtenerUnAreaServicio
Esta funcin retorna un rea de servicio de acuerdo al cdigo de rea de
servicio ingresado.
aplicacin.
funcionamiento.
acerca de un centro mdico para poder mostrarla en documentos como la
orden de medicamentos y la orden de exmenes mdicos en aras de plasmar
el lugar donde se realizaron los mismos.
147

ObtenerCentroMedico
Esta funcin retorna una entidad Centro Mdico de acuerdo al cdigo
ingresado. La entidad centro mdico contiene el nombre del centro
mdico y el nombre de la red de salud a la que pertenece el centro.
aplicacin.
funcionamiento.
Esta API fue creada para obtener informacin acerca del resultado de un
examen mdico registrado en una entidad de salud.
ObtenerResultadoEM_x_DetalleEM
Esta funcin retorna una entidad resultado de examen mdico de acuerdo
a un cdigo de detalle de examen mdico ingresado.
aplicacin.
funcionamiento.
Su funcin es retornar informacin acerca de una atencin de consulta
externa registrada. La consulta tambin es conocida como encuentro mdico.
148

Esta funcin retorna una entidad del tipo encuentro nio de acuerdo a un
cdigo de encuentro general ingresado.
Esta funcin retorna una entidad del tipo encuentro adolescente de
acuerdo a un cdigo de encuentro general ingresado.
Esta funcin retorna una entidad del tipo encuentro adulto de acuerdo a
un cdigo de encuentro general ingresado.
Esta funcin retorna una entidad del tipo encuentro adulto mayor de
acuerdo a un cdigo de encuentro general ingresado.
aplicacin.
funcionamiento.
WSListarsignosPeligroNino
acerca de los signos de peligro que puede afrontar una persona en su etapa de
niez.
ListarSignosPeligroNino
Esta funcin retorna una lista de signos de peligro del nio de acuerdo a
la edad ingresada
aplicacin.
149

funcionamiento.
Su funcin es retornar informacin acerca de las diferentes categoras a las
cuales una persona, en estado adulto mayor, puede ser clasificada. Este web
servicie complementa la funcionalidad del Mostrar/Registrar Encuentro
Mdico del Adulto Mayor
ListarCategoriasAdultoMayor
Esta funcin retorna una lista de categoras de clasificacin del adulto
mayor. (p.e. Saludable,Geriatrico Complejo, Enfermo,etc).
aplicacin.
funcionamiento.
Su funcin es el ncleo de todo el sistema y se encarga de registrar
informacin acerca de un encuentro general realizado entre un paciente y el
mdico contendr informacin de la anamnesis realizada.
RegistrarEncuentroNino
Esta funcin permite registrar un encuentro de tipo nio y retorna el
cdigo asignado al registro.
RegistrarEncuentroAdolescente
Esta funcin permite registrar un encuentro de tipo adolescente y retorna
el cdigo asignado al registro.
RegistrarEncuentroAdulto
150

Esta funcin permite registrar un encuentro de tipo adulto y retorna el
cdigo asignado al registro.
RegistrarEncuentroadultoMayor
Esta funcin permite registrar un encuentro de tipo adulto mayor y
retorna el cdigo asignado al registro.
aplicacin.
funcionamiento.
WSListarEncuentrosGenerales
Su funcin es retornar informacin acerca de los diferentes encuentros
generales que pertenezcan a un episodio general.
ListarEncuentrosGenreales_x_Episodio
Esta funcin retorna una lista de cabeceras de encuentros generales de
acuerdo al cdigo de episodio general ingresado,etc).
aplicacin.
funcionamiento.
Su funcin es retornar informacin acerca de los diferentes estados o
parmetros de los diagnsticos para complementar la funcionalidad del
registro o consulta del encuentro de una persona en su etapa nio y adulto
mayor. Adicionalmente, se ha agregado la funcionalidad de poder obtener los
tiempos que sirven para complementar el registro de todos los formatos de
encuentro mdico, especficamente, para el tiempo de enfermedad del
paciente.
151

Listar_Estados_x_Parametro
Esta funcin retorna una lista de estados de los diferentes tipos de
diagnsitco de los formatos de encuentro nio y encuentro adulto mayor.
Listar_Tiempos
Esta funcin retorna una lista de tiempos para cargar el tiempo de
enfermedad de los formatos.
aplicacin.
funcionamiento.
Su funcin es registrar datos de una recete mdica, o tambin conocida como
orden de medicamentos. Esta es una de las rdenes que el mdico puede
generar despus de haber grabado el encuentro mdico.
Este procedimiento permite registrar una orden de receta mdica y una
lista de detalle de receta mdica.
aplicacin.
funcionamiento.
152

Su funcin es obtener los datos de una recete mdica, o tambin conocida
como orden de medicamentos. Esta es una de las rdenes que el mdico
puede obtener despus de haber grabado el encuentro mdico y la receta
mdica.
ObtenerOrdenRM
Esta funcin retorna la cabecera de una orden de receta mdica de
acuerdo al cdigo ingresado.
ObtenerDetalleRM
Esta funcin retorna la lista de detalle de receta mdica de acuerdo al
nmero de orden de receta mdica ingresado
aplicacin.
funcionamiento.
WSAdmExamenMedico
Su funcin es obtener informacin de los exmenes mdicos dependiendo de
su lnea o tipo de examen mdico. Adems obtiene informacin de lneas y/o
tipos de exmenes mdicos.
ObtenerLineasEM
Esta funcin retorna una lista de las lneas de exmenes mdicos.
ObtenerTiposEM
Esta funcin Obtiene los Tipos de examen mdico de acuerdo al cdigo
de lnea de examen mdico ingresado.
Esta funcin retorna una lista de exmenes mdicos de acuerdo al cdigo
de tipo de examen mdico ingresado.
ObtenerUnTipoEM
Esta funcin retorna un Tipo de Examen Mdico de acuerdo al cdigo de
Tipo de examen mdico ingresado.
153
ObtenerUnaLineaEM
Esta funcin retorna una Lnea de Examen Mdico de acuerdo al cdigo
de Lnea de examen mdico ingresado.
ObtenerUnEstadoEM
Esta funcin retorna un Estado de Examen Mdico de acuerdo al cdigo
de Estado de examen mdico ingresado.
Esta funcin retorna un Examen Mdico de acuerdo al cdigo de examen
mdico ingresado.
aplicacin.
funcionamiento.
WSAdmExamenMedico
Su funcin es obtener informacin de los exmenes mdicos dependiendo de
su lnea o tipo de examen mdico. Adems obtiene informacin de lneas y/o
tipos de exmenes mdicos.
ObtenerLineasEM
Esta funcin retorna una lista de las lneas de exmenes mdicos.
ObtenerTiposEM
Esta funcin Obtiene los Tipos de examen mdico de acuerdo al cdigo
de lnea de examen mdico ingresado.
Esta funcin retorna una lista de exmenes mdicos de acuerdo al cdigo
de tipo de examen mdico ingresado.
ObtenerUnTipoEM
Esta funcin retorna un Tipo de Examen Mdico de acuerdo al cdigo de
Tipo de examen mdico ingresado.
154
ObtenerUnaLineaEM
Esta funcin retorna una Lnea de Examen Mdico de acuerdo al cdigo
de Lnea de examen mdico ingresado.
ObtenerUnEstadoEM
Esta funcin retorna un Estado de Examen Mdico de acuerdo al cdigo
de Estado de examen mdico ingresado.
Esta funcin retorna un Examen Mdico de acuerdo al cdigo de examen
mdico ingresado.
aplicacin.
funcionamiento.
WSRegistrarOrdenEM
Su funcin es registrar datos de una orden de exmenes mdicos. Esta es una
de las rdenes que el mdico puede generar despus de haber grabado el
encuentro mdico.
RegistrarOrdenEM
Este procedimiento permite registrar una orden de examen mdico y una
lista de detalle de orden de examen Mdico.
aplicacin.
funcionamiento.
WSObtenerOrdenEM
155

Su funcin es obtener los datos de una orden de exmenes mdicos. Esta es
una de las rdenes que el mdico puede obtener despus de haber grabado el
encuentro mdico y la orden de examen mdico.
ObtenerUnaOrdenEM
Esta funcin retorna la cabecera de orden de examen mdico de acuerdo
al nmero de orden de examen mdico ingresado
Esta funcin retorna la lista de detalle de orden de examen mdico de
acuerdo al nmero de orden de examen mdico ingresado
ObtenerDetallesOrden_x_OrdenCita_x_EstadoDetalle
Esta funcin retorna la lista de detalle de orden de examen mdico en
estado pendiente de registro, en base al nmero de orden de dita de
examen mdico ingresado.
ObtenerExamenesMedicos_x_KDetalleOrdenExMedicos
Esta funcin retorna un examen mdico de acuerdo al cdigo de detalle
de orden de examen mdico ingresado.
aplicacin.
funcionamiento.
WSRegistrarresultadoEM
Su funcin es registrar datos del resultado de un examen mdico. Esta
permite concluir el flujo de control de exmenes mdicos de un centro de
salud.
RegistrarResultadoEM
Este procedimiento permite registrar el resultado de un examen mdico
de laboratorio
156

aplicacin.
funcionamiento.
Estructura Interna
Diagrama de Clases / ER
En esta seccin se mostrar un diagrama que corresponde al modelo de datos. Se
mostrar el detalle de las relaciones entre tablas, ya que en el siguiente apartado
se puede apreciar el detalle de cada uno de los campos que conforman las tablas
del sistema. El primer diagrama corresponde a las clases relacionadas con el
proceso de Prestacin de Servicios Clnicos, ms especficamente al proceso de
atencin de consulta externa. El segundo diagrama corresponde al proceso de
Control de Exmenes Mdicos.
Consulta Externa (Prestacin de Servicios Clnicos)
157
Prescripcion
+Prescripcion
+FechaEpisodio
Paciente
Farmacia
+ResgitrarPrescripcion()
Episodio
+Medicamento
+Concentracion
+Cantidad
+Indicaciones
0..*
+RegistrarEpisodio()
Encuentro
1
Enfermedades
ClaseDiagnostico
+NombreClaseDiagnostico
+CIE-10
+NombreEnfermedad
+ObtenerEnfermedades()
TipoDiagnostico
+NombreTipoDiagnostico
1..*
Cita
Diagnostico
+Descripcion
+FechaCreacion
+RegistrarDiagnostico()
Receta Medica
+RegistrarRecetaMedica()
+FechaEncuentro
+Motivo
+Tiempo
+TipoTiempo
+EstadoAnimo
+Sed
+Sueo
+Apetito
+Orina
+Deposiciones
+Temperatura
+PresionArterial
+FC
+FR
+Peso
+Talla
+IMC
+Observaciones
0..*
1
Administracion
+RegistrarEncuentro()
0..*
Examen Medico
+FechaOrden
EncuentroNinio
+RegistrarOrdenExamenMedico()
EncuentroAdolescente
EncuentroAdulto
+FiebreUltimos15Dias
+TosMas15Dias
+SecrecionLesionGenitales
+FechaUltimaRegla
EncuentroAdultoMayor
+Piel
+TCSC Edemas
+CabezayCuello
+CavidadOral
+ToraxyPulmones
+AparatoCardiovascular
+Abdomen
+AparatoGenitourinario
+EstadoPies
+TactoRectal
+SistemaNervioso
+AparatoLocomotor
Figura 5.5 Modelo de Clases Consulta Externa

158
Examen Mdico (Control de Exmenes Mdicos)

Bioquimica
+Glucosa
+Urea
+Creatinina
+AcidoUrico
+BilTotal
+BilDirecta
+BlIndirecta
+Albumina
+Globulina
+CPKT
+CPK MB
+LDH
+TGO
+TGP
+Amilasa
+Lipasa
+FAlcalina
+FAcida
+Colesterol
+HDLColesterol
+LDLColesterol
+Trigliceridos
+LipidosTotales
+Observaciones
Laboratorio
+RegistrarResultado()
+ConsultarExamen()
+Fecha
+JedeDeServicio
+ConsultarExamen()
Examen Medico
+FechaOrden
Imagenologia
+Observaciones
Examen de Orina
+Glucosa
+Bilirrubina
+Proteinas
+Urobilinogeno
+acAscorbico
+Hemoglobina
+CCetonicos
+Nitricos
+CelulasEpiteliales
+Leucocitos
+Hematies
+Bacterias
+Piocitos
+Cristales
+Hongos
+Trichimonas
+Otros
+ConsultarExamen()
Inmuserologia
+TificoO
+TificoH
+ParatificoA
+ParatificoB
+Brucella
+VDRLoRPR
+ProteinaCREactiva
+Latex
+Observaciones
+ConsultarExamen()
Hematologia
+Hematies
+Leucocitos
+Hb
+TiempoCoagulacion
+TiempoSangria
+TProtombina
+VelocidadDeSedimentacion
+Retraccion del coagulo
+Neutrofilos
+Abastonados
+Segmentados
+Eosinofilos
+Basofilos
+Monocitos
+Linfocitos
+Plaquetas
+LE
+Reticulocitos
+ConstantesCorpusculares
+VCM
+HCM
+CHCM
+GostaGruesa
+Observaciones
+ConsultarExamen()
Figura 5.6 Modelo de Clases Control de Exmenes Mdicos

159
Examen de Heces
+Moco
+Sangre
+Thevenon
+Sustenacias Reductoras
+SudanIII
+PH
+ReaccionInflamatoria
+ParasitoMuestra1
+ParasitoMuestra2
+ParasitoMuestra3
+ParasitosObservaciones
+Test de Graham
+Observaciones
+ConsultarExamen()
Patrones de Diseo
Si bien es cierto, dentro de las tecnologas que se utilizan dentro del proyecto como lo
son los portlets y los web services, llevan detrs de ellos una serie de patrones
implementados como lo son CompositeView, SessionFacade, DispatcherView, etc. A
continuacin detallaremos los patrones utilizados e implementados por el equipo de
proyecto con el fin de cumplir los objetivos del mismo.
Singletone
Este patrn permite crear una y solo una instancia de una clase a la cual otros
componentes del negocio accedern con fin de cumplir con el objetivo de su
proceso.
Para el caso de SISREGAME se hizo el uso de este patrn para implementar
la clase DATASOURCE Y SERVICELOCATOR. La primera clase se
encarga de gestionar las conexiones a la base de datos as como los
Statements y los ResultSet. La segunda se encarga de obtener un pool de
conexiones brindados por el servidor Glassfish.
DAO
Es un patrn que brinda una interfaz entre la aplicacin software y la base de
datos.
Para el caso de SISREGAME se hizo el uso de este patrn para implementar

todos los componentes de acceso a datos haciendo una transferencia de datos
entre la tabla y la clase.
DTO
Este patrn es conocido con diferentes nominaciones como Bussines Entities,
EJB, Enterprise Java Bean o el mismo DTO. Este se encarga de encapsular
los datos de los objetos del negocio identificados dentro del sistema. Adems
160

presenta una asociacin con el patrn DAO, ya que llegan los datos
encapsulados y el DAO se encarga de la transferencia de informacin.
Para el caso de SISREGAME se hizo el uso de este patrn para abstraer los
objetos del negocio dentro de los procesos de Prestacin de servicios
Clnicos y Control de Exmenes Mdicos.
Iterator
Este patrn permite hacer un recorrido dentro de una lista o un arreglo de un
objeto.
En el caso de la plataforma Java este ya se encuentra implementado y listo

para su uso.
En el caso de SISREGAME, se ha usado en varias ocasiones para poder crear

dinmicamente una tabla, un combo box, una lista de checkbox y/o radio
buttons.
MVC
Este patrn llamado Model-View-Controller (Modelo-Vista-Controlador) se
encarga de separar la lgica del negocio, la presentacin y los datos de la
aplicacin software en componentes distintos.
Este patrn viene implcito al momento de crear una aplicacin Web dentro
de la plataforma Java. En donde, la Vista es representado por los JSP de la
aplicacin, el Controlador ser representado por los servlets (o por los actions
en caso de usar struts) y el Model es representado por los componentes de
lgica del negocio.
En el caso de SISREGAME, la Vista est representada por los JSP que estn
contenidos en los portlet que a su vez estn en un administrador de contenidos
como Liferay. Los Controladores son los portlets en donde se ejecutan
procedimientos conocidos como el ProcessAction, DoView, DoEdit, DoHelp.
161

Por ltimo, el Modelo est representado por los componentes de la lgica del
negocio de los procesos Prestacin de servicios Clnicos y Control de
Exmenes Mdicos.
162
CAPTULO 6. CONSTRUCCIN
Este captulo contendr informacin componentes desarrollados y de los estndares

aplicados en la fase de construccin del sistema.
Introduccin
El presente captulo se enfoca en brindar informacin acerca de la manera en que
se realiz la transicin de la etapa de elaboracin a la de construccin. Adems,
se nombrarn las herramientas y metodologas utilizadas para el desarrollo del
sistema, las razones por las cuales se utilizaron y los estndares aplicados.
Mapeo del Diseo a la Implementacin

El sistema de registro de atencin mdica SISREGAME es una aplicacin Web
la cual es accesible desde cualquier mquina con conexin a Internet y un
navegador de internet como Internet Explorer, Mozilla Firefox, etc. Para la
construccin del portal se tuvieron que seguir los siguientes pasos previos:
Priorizacin de casos de uso. Como parte de la primera iteracin de la

fase de Concepcin se realiz un anlisis de los casos de uso. Se
estableci una valoracin de los mismos de acuerdo a tres atributos
definidos por los jefes de proyecto y desarrollo como lo son el riesgo, la
precedencia y el valor estratgico. El resultado de esta priorizacin
ayud a establecer las iteraciones e hitos de la fase de construccin.
Estandarizacin de funcionalidades. Se analizaron los servicios que se

deban implementar para cada caso de uso y se identificaron aquellos
que requeran ser invocados o usados por diferentes funcionalidades
Captulo 6: Construccin
ms de una vez. De esta manera, se le dio prioridad a estos para que los
mtodos estn disponibles y no sean un inconveniente por razones de
dependencia para el cumplir con el objetivo de una funcionalidad. De
esta manera se aplic el reso en todos los casos de uso que las
necesitaran.
Identificacin de estndares de programacin. Se establecieron

estndares de programacin en los cuales se definieron las
nomenclaturas y buenas prcticas para la implementacin del cdigo
del sistema. Los estndares de codificacin fueron definidos y
proporcionados por la empresa Software Factory.
Identificacin de estndares de base de datos. De igual manera, para la

implementacin de bases de datos es establecin un conjunto de reglas
y buenas prcticas por el DBA de la empresa Salud-able.
Implementacin de casos de uso. Se proceder al desarrollo de cada uno

de los casos de uso identificados y registrados en el diseo del
producto.
Pruebas de Software. Se deber someter a un riguroso conjunto de

pruebas para poder identificar los defectos del sistema y, de esta
manera, garantizar la calidad del mismo y que el sistema cumple
exitosamente con todas las funcionalidades especificadas. Las pruebas
sern realizadas por la empresa Quality Assurance la cual, una vez
aprobada la funcionalidad, emitir un certificado de calidad para el
sistema.
Estndar de Codificacin - Java

La codificacin se realiz con el lenguaje de programacin Java se realiz
tomando como modelo de referencia SOA (arquitectura orientada a servicios)
164

que propone implementar una arquitectura de 9 capas. Se adoptarn los
estndares de codificacin de la empresa Software Factory en donde se detalla el
manejo para palabras reservadas, tipos de datos, operadores booleanos, clases,
atributos, parmetros, variables locales, nombres de funciones y procedimientos,
propiedades, mtodos de acceso, componentes, y nombres fsicos.
continuacin se detallan los estndares de codificacin.
Definicin de Clases
Las clases que almacenen informacin de alguna entidad, es decir los objetos de
transferencia de Datos, sern nombradas con el nombre de la entidad en forma
singular y con el prefijo BE. Por ejemplo, la clase:
BEPaciente.
No se emplearn caracteres de separacin, como guiones o subguiones.

El uso de nmeros en la nomenclatura debe ser mayormente evitado.
Las clases que tengan ms de dos palabras en su nombre, sern

nombradas por la unin de las palabras que la conforman, cada palabra
deber empezar con letra mayscula.
Las tildes sern omitidas en el nombre de la clase.
Definicin de Atributos
Los atributos de las clases sern nombrados en funcin a la caracterstica o el
dato que se representa en el sistema.
165
No se emplearn caracteres de separacin, como guiones o subguiones,

excepto al inicio del nombre. El uso de nmeros en la nomenclatura debe
ser mayormente evitado.
Los atributos debern ser nombrados con letras minsculas. Por ejemplo,
codigo.
En caso de que el nombre atributo este compuesto por dos o ms

palabras. La primera palabra ser iniciada con la letra minscula, y las
siguientes palabras se iniciaran con la letra mayscula. No se utilizara
espacios, ni separadores entre palabras. P Por ejemplo, fechaEstimada.
Las atributos que contengan, en su nombre, inciales de algn tipo

mantendrn las inciales con mayscula. Por ejemplo, RUC.
Definicin de Operaciones / Mtodos
Las operaciones sern nombradas de acuerdo a las funcionalidades y

contendrn un verbo indicando la accin principal de la misma. Los
verbos sern mostrados en estado infinitivo.

Las operaciones sern escritas en minsculas. Por ejemplo, leer().
En caso de que la operacin est conformada por dos o ms palabras, el

nombre de la operacin ser la unin de todas las palabras, donde cada
palabra iniciar con la primera letra en mayscula y las dems en
minsculas. leerPaquetesDeEnvio().
Las operaciones que contengan, en su nombre, inciales de algn tipo

mantendrn las inciales con mayscula. Por ejemplo, registrarRUC().
Variables
Las variables a utilizar en las operaciones sern nombradas en funcin a la
caracterstica o el dato que desean representar.
Las variables debern ser nombradas con letras minsculas. Por ejemplo,
cadena.
En caso de que el nombre de la variable est compuesta por dos o ms

palabras, la primera palabra ser iniciada con letra minscula y la
siguiente palabra se iniciarn con la letra mayscula. No se utilizarn
espacios, ni separadores entre palabras.
Los paquetes que se desarrollen en la aplicacin debern tener la

siguiente estructura: edu.upc.saludable.sisregame.<NombrePaquete>.
La nomenclatura de los paquetes deber estar en minsculas y sin

espacios en blanco o algn carcter especial.
Paquetes
166
Estndar de Codificacin de Base de Datos

En el periodo 2010-1 la empresa, denominada en ese entonces ITIL, que es la
empresa virtual que se encarga de la administracin de los recursos de hardware
y software dentro de la UPC, desarroll un estndar de codificacin de base de
datos para Microsoft SQL Server.
Sin embargo, en el periodo acadmico 2010-2 la empresa Salud-able present su

cartera de proyectos, los cuales seran implementados utilizando una base de
datos MySql Server. En consecuencia, la empresa ITIL que para este periodo
cambi de nombre a IT-Expert solicit a la empresa Salud-able que su rea de
administracin de base de datos elaborara un estndar de base de datos, dado a
que cuando se ejecuten actividades de mantenimiento de servidores y bases de
datos puedan trabajar un riesgo minimizado de alterar o daar los datos que
contienen los mismos.
Es por esta razn que el presente proyecto, SISREGAME, ha seguido los

estndares de bases de datos aprobados por la empresa IT-Expert los cuales
sern descritos a continuacin.
Definicin de Tablas
El formato de las tablas sera el siguiente:
[nombre de la tabla]
Adems, es necesario recalcar que el nombre de la tabla debe encontrarse en

minsculas, no deben tener abreviaciones y debe ser singular.
Definicin de Campos de las Tablas
167
Los campos de las tablas debern encontrarse todos en minsculas, y, seguir el
siguiente formato:
Smbolo_[nombre de la variable]
Primero, deber colocarse el identificador de la variable en maysculas, seguido

por el smbolo de _, y finalmente el nombre de la variable en minsculas y la
primera letra en maysculas.
Smbolo
Nombre
Definicin
Nombre
Expresa datos alfabticos.
Cdigo Autogenerado
Datos alfanumricos usados para clasificar

datos de tipo autogenerado por el sistema.
Cdigo
No Datos alfanumricos usados para clasificar
Autogenerado
datos de tipo no autogenerado por el sistema.
Fecha
Datos de Fecha y Hora.
Cantidad
Expresa cantidad.
Monto / Dinero
Datos
numricos
que
expresan
cifras
monetarias.
P
Porcentaje
Ratios y factores expresados en porcentaje.
Texto
Datos alfanumricos amplios usados para

describir contenidos.
Flag
Datos limitados a dos nicos valores

posibles.
Nmero
Datos numricos cardinales u ordinales.
Tabla 6.1 Definicin de Tablas

168
Definicin de ndices
Los ndices, debern, primero, tener el prefijo: idx, luego, se les deber colocar
el nombre del campo al que viene indexado. De la siguiente manera:
idx_[nombre de Tabla]_[nombre del campo]
Por ejemplo, si se desea crear un ndice al campo edad en la tabla Paciente, el

resultado sera el siguiente: idx_Paciente_edad. Ntese que el nombre de la
columna y el prefijo idx se encuentran en minsculas.
Definicin de Variables
Las variables de los parmetros deben llevar anexado el nombre de la columna a
la cual se refieren. Y, de la misma forma que los nombres de los campos, estos
debern encontrarse en minsculas. Y, debern seguir la siguiente estructura:
_[nombre_de_la_variable]
Por ejemplo, podemos mencionar el caso de una variable que reciba un

procedimiento almacenado o una funcin y que se deba comparar con el campo
sueldo. Entonces, tendr el nombre de: _sueldo
Y, en caso sea un campo conformado por dos palabras, se debe colocar un guin
bajo: _, para separar dichas palabras. Adems, si se trata de una variable local,
como una suma o resta por ejemplo, se deber colocar un nombre que haga
referencia especficamente a la razn de ser de dicha variable.
169
Definicin de Procedimientos Almacenados (Stored Procedures)

Para el caso de los procedimientos almacenados, es necesario colocar el prefijo
sp, luego, se colocar el nombre del stored procedure al que se hace referencia.
Y, por ltimo se har referencia al nombre de la tabla en s. Siguiendo el
siguiente formato:
sp_[nombre_del_stored_procedure]_[nombre de la tabla]
Ntese que las primeras letras de las palabras se encuentran en minsculas y los
nombres podrn estar separados por un guin bajo (_). Sin embargo, en caso el
stored procedure no sea referido a ninguna tabla, el ultimo campo se puede
omitir.
Definicin de Funciones
De igual forma que los stored procedures, las funciones definidas por el usuario
deben contener el prefijo: func, luego, se deber colocar el nombre de la
funcin, y, finalmente deber colocarse la tabla al que se hace referencia en caso
sea necesario. Siguiendo la siguiente nomenclatura:
func_[nombre_de_la_funcion]_[nombre de la tabla]
Ntese que las primeras letras de las palabras se encuentran en minsculas. Sin
embargo, en caso el funcin no sea referido a ninguna tabla, el ultimo campo se
puede omitir.
Definicin de Disparadores (Triggers)
170

Los disparadores, tambin conocidos como triggers, debern, primero, tener el
prefijo: trig, luego, se deber colocar el nombre del trigger. De la siguiente
manera:
trig_[nombre_del_disparador]
Ntese que todas las letras se encuentran en minsculas.
Definicin de Vistas
Para el caso de las vistas, se deber primero colocar el prefijo: view, y, luego
se deber colocar el nombre de la vista en s de la siguiente forma:
view_[nombre_de_la_vista]
Definicin de Backups
Los Backups debern contar con el prefijo: bck, luego, se deber escribir el
nombre especfico de la base de datos sin abreviaciones y siendo lo ms
especfico posible, finalmente, deber colocar la fecha de creacin del backup de
la forma: ao, mes, da. El formato que deber seguirse para estos casos es el
siguiente:
bck_[Nombre de la Base de datos]_[ aaaa-mm-dd]
Capacitacin de Recursos
Los recursos para poder realizar la implementacin del sistema SISREGAME
fueron asignados por la empresa Software Factory, empresa con la cual
previamente se estableci un contrato en donde se indicaron la cantidad de
recursos a asignar y los conocimientos y capacidades requeridos para poder
cumplir con los objetivos del proyecto.
171
Cantidad de Recursos Requeridos: 2
Conocimientos y capacidades:
Experiencia en diseo y construccin de Pginas Web
Conocimiento y experiencia con JavaScripts y componentes Ajax
Conocimiento y experiencia en desarrollo orientado a objetos.
Conocimiento de Java IDE: NetBeans.
Conocimiento de uso de la herramienta Tortoise SVN
Conocimiento de Portlets.
Conocimiento y Experiencia de implementacin de Web Services.
Para poder reforzar el conocimiento de los recursos asignados y aplicar la

contingencia ante el desconocimiento del uso de la tecnologa de Portlets, el Jefe
de Desarrollo decidi capacitar a los recursos en el uso de los mismos. La
capacitacin dur 12 horas y el resultado de las mismas fue positivo dado a que
no se presentaron informes de retraso por desconocimiento de la tecnologa.
Depuracin de la aplicacin
Para la fase de construccin fue necesario ejecutar pruebas unitarias para
verificar el cumplimiento de los objetivos de cada mtodo implementado.
Cuando se encontraron fallas se procedi a depurar la aplicacin para identificar
y corregir la seccin del cdigo en la que estaba fallando la funcionalidad. De
esta manera se evit que las fallas se conviertan en errores encontrados durante
las pruebas funcionales o peor aun cuando el producto se encuentre en
produccin.
Debido a que estas pruebas han sido consideradas como parte del aseguramiento
de la calidad, se detallarn las mismas en el captulo siguiente.
172
CAPTULO
7.
ASEGURAMIENTO
DE
LA
CALIDAD19
Este captulo contendr informacin de los procedimientos realizados para asegurar
que se posee un sistema de calidad.
Introduccin
En todo proyecto se debe asegurar que el producto que se est construyendo es de
calidad. Para ello, el proyecto SISREGAME dar a conocer los procesos realizados
hasta el momento para asegurar la calidad del producto software.
Pruebas unitarias
Como parte de las actividades de aseguramiento de la calidad se decidi ejecutar
una serie de pruebas unitarias a las funciones y procedimientos que forman parte de
la lgica de negocio de la aplicacin software que involucra al proceso de Prestacin
de Servicios Clnicos y Control de Exmenes Mdicos.
Dentro de la fase de Construccin de la Metodologa de Desarrollo escogida es
donde se van a ejecutar las pruebas.
Para la realizacin de las pruebas previamente el personal de desarrollo ha tenido
que leer las especificaciones de caso de uso as como la especificacin de las tablas
y columnas involucradas con cada funcin y/o procedimiento implementados. A fin
de que al final de cada prueba, a pesar de obtener un resultado satisfactorio se pueda
verificar que los datos enviados y/o consultados por los mtodos muestren o
registren informacin coherente y confiable en la base de datos.
19
Ver Anexo 4. Se muestran los informes finales de QA, los cuales contienen la aprobacin de los
paquetes entregados en el ciclo 2010-02.
Captulo 7: Aseguramiento de la Calidad

El plan para realizar las pruebas, en primer lugar busc identificar los mtodos
crticos del sistema. Como resultado se obtuvieron los siguientes mtodos y
funciones:
ObtenerUnaCategoriaAdultoMayor.
Objetivo: Obtener una categora de adulto mayor de acuerdo al cdigo

ingresado.
Parmetros de entrada: Objeto del tipo BECategoraAdultoMayor
Escenario: Se enva el objeto con el cdigo de una categora de adulto
mayor.
xito: Se obtiene el objeto BECategoraAdultoMayor con la descripcin del
cdigo enviado.
Fallo: No se obtiene la entidad o se obtiene nulo.
ObtenerCategoriasAdultoMayor
Objetivo: Obtener la lista de categoras de adulto mayor activos.

Parmetros de entrada: Ninguno
Escenario: Se invoca a la funcin ObtenerCategoriasAdultoMayor.
xito: Se obtiene una lista de objetos BECategoraAdultoMayor con su
respectivo cdigo y descripcin.
Fallo: La lista no tiene objetos o es nulo.
174
RegistraEncuentroMedicogeneral (Mtodo que guarda los datos

comnes para los diferentes formatos de atencin).
Objetivo: Registrar en BD de los datos del encuentro mdico general

Parmetros de entrada: Objeto BEEncuentroMedicoGeneral
Escenario: Se registra un encuentro mdico general con todos los datos.
xito: Se registran los datos en la BD y se obtiene un cdigo de Encuentro
Mdico.
Fallo: No se obtiene el cdigo del encuentro, es 0 o se produce una
excepcin.
RegistrarEncuentroMedicoGeneral (Nio)
Objetivo: Registrar en BD los datos particulares de un encuentro mdico de

con nio.
Parmetros de entrada: Objeto BEENino
Escenario: Se registra un encuentro mdico de nio con todos los datos.
xito: Se registran los datos en la BD y se relaciona con el Encuentro Mdico
General generado en la Prueba Unitaria 7.2.3.
Fallo: Se obtiene una excepcin. No se registran los datos en la BD.
RegistrarEncuentroMedicoGeneral (Adolescente)

con un Adolescente.
Parmetros de entrada: Objeto BEEAdolescente
Escenario: Se registra un encuentro mdico de adolescente con todos los
datos.
175

RegistrarEncuentroMedicoGeneral (Adulto)

con un Adulto.
Parmetros de entrada: Objeto BEEAdulto
Escenario: Se registra un encuentro mdico de adulto con todos los datos.
RegistrarEncuentroMedicoGeneral (Adulto Mayor)

con un Adulto Mayor.
Parmetros de entrada: Objeto BEEAdultoMayor
Escenario: Se registra un encuentro mdico de adulto myor con todos los
datos.
ObtenerEncuentrosXEpisodio
176

Objetivo: Listar los encuentros mdicos relacionados con un episodio
mdico.
Parmetros de entrada: Objeto BEEpisodioMedico
Escenario: Se envan todos los datos del episodio mdico.
xito: Se obtiene la lista de todos los encuentros mdicos.
Fallo: La lista est vaca, se obtiene nulo o se obtiene una excepcin.
ObtenerEpisodiosMedicosGenralesEntrefechas
Objetivo: Obtener una lista de Episodios Mdicos en funcin al rango de

fechas ingresados
Parmetros de entrada: Fecha Inicial (Date) y Fecha Final (Date)
Escenario: Se envan las dos fechas inicial y final.
xito: Se obtiene la lista de episodios mdicos.
Fallo: Se obtiene nulo o una excepcin.
Objetivo: Obtener los datos de un encuentro mdico de un nio.

Parmetros de entrada: Objeto BEENino
Escenario: Se establece el cdigo del encuentro mdico como atributo del
objeto enviado.
xito: Se obtienen los datos del encuentro mdico del nio.
Objetivo: Obtener los datos de un encuentro mdico de un adulto mayor.

Parmetros de entrada: Objeto BEEAdultoMayor
177

objeto enviado.
xito: Se obtienen los datos del encuentro mdico del adulto mayor.
Objetivo: Obtener los datos de un encuentro mdico de un adulto.

Parmetros de entrada: Objeto BEEAdulto
objeto enviado.
xito: Se obtienen los datos del encuentro mdico del adulto.
Objetivo: Obtener los datos de un encuentro mdico de un adolescente.

Parmetros de entrada: Objeto BEEAdolescente
objeto enviado.
xito: Se obtienen los datos del encuentro mdico del adolescente.
ObtenerEpisodiosMdicosgeneralesxPaciente
Objetivo: Se obtiene una lista de episodios mdicos segn el cdigo de

paciente enviado.
Parmetros de entrada: Objeto BEPaciente
178

Escenario: Se enva el cdigo del paciente dentro del objeto enviado.
xito: Se obtiene la lista de episodios mdicos.
RegistrarEpisodioMedicoGeneral
Objetivo: Se registran los datos del episodio mdico en la BD.

Parmetros de entrada: Objeto BEEpisodioMedico
Escenario: Se envan los datos de un episodio mdico completos.
xito: Se obtiene el cdigo del nuevo episodio mdico.
Fallo: Se obtiene 0 o una excepcin.
Objetivo: Se registran los datos de una receta mdica y el detalle del mismo.
Parmetros de entrada: Objeto BERecetaMedica
Escenario: Se envan los datos completos de la receta mdico y el detalle de
los medicamentos recetados.
xito: Se obtiene el nuevo cdigo de la receta mdica.
ObtenerDetalleRM (Receta Mdica)
Objetivo: Obtener la lista de detalle de Receta Mdica

Parmetros de entrada: Objeto BEDetalleRM
Escenario: Se envan los datos completos de la receta mdica (Cabecera)
xito: Se obtiene la lista de Detalles de Receta Mdica. Por los menos se
obtiene un registro.
179

Fallo: La cantidad de Detalles de Receta mdica es 0, nula o se obtiene una
excepcin.
ObtenerUnaRecetaMedica
Objetivo: Obtener los datos de una receta mdica.

Parmetros de entrada: Objeto BERecetaMedica.
Escenario: Se enva el cdigo de la receta mdica.
xito: Se obtienen los datos de la receta mdica.
Fallo: No se obtiene informacin de la receta mdica, se obtiene nulo.
ObtenerSignosPeligroxEtapaNino
Objetivo: Obtener los signos de peligro segn la etapa del nio.

Parmetros de entrada: Cdigo de etapa de nio
Escenario: Se enva el cdigo de etapa de nio
xito: Se obtienen los signos de peligro de la etapa del nio.
Fallo: No se obtiene ningn signo o se obtiene nulo.
ListarEstadosxParmetro
Objetivo: Obtener la lista de estados segn el parmetro de diagnstico

nutricional del nio.
Parmetros de entrada: Cdigo de Parmetro Nutricional.
Escenario: Se enca el cdigo de parmetro nutricional.
xito: Se obtiene la lista de estados. Por lo menos se obtiene un estado.
Fallo: No se obtiene ningn estado. Se obtiene nulo o una excepcin.
180
ListarTiempos.
Objetivo: Se obtienen las unidades de tiempo para el tiempo de enfermedad

del paciente.
Parmetros de entrada: Ninguno
Escenario: Se invoca a la funcin.
xito: Se obtiene la lista de unidades de tiempo.
Fallo: No se obtienen ninguna unidad de medida o se obtiene una excepcin.
RegistrarOrdenEM (Examen Mdico)
Objetivo: Registrar en BD los datos de la orden de examen mdico.

Parmetros de entrada: Objeto BEOrdenEM
Escenario: Se enva los datos completos de una orden examen mdico.
xito: Se obtiene el cdigo de examen mdico generado.
Objetivo: Se obtiene la informacin de un examen mdico.

Parmetros de entrada: Objeto BEExamenMedico
Escenario: Se enva el cdigo del examen mdico.
xito: Se obtienen datos del examen mdico.
Fallo: Se obtiene nulo.
ObtenerExamenesMedicosxTipo
Objetivo: Obtener la lista de exmenes mdicos por tipo de examen mdico.

181

Parmetros de entrada: Objeto BETipoEM
Escenario: Se enva el cdigo del tipo de examen mdico.
xito: Se obtiene la lista de tipos de exmenes mdicos.
Fallo: No se obtienen ningn registro, nulo o una excepcin.
ObtenerUnaLineaEM
Objetivo: Obtener una lnea de examen mdico.

Parmetros de entrada: Objeto BELineaEM
Escenario: Se enva el cdigo de lnea de examen mdico.
xito: Se obtiene la descripcin de la lnea de examen mdico.
ObtenerLineasEM
Objetivo: Obtener todas las lneas de examen mdico vlidas.

Parmetros de entrada: Ninguno.
Escenario: Se invoca a la funcin.
xito: Se obtiene la lista de exmenes mdicos.
Fallo: No se obtiene la lista, se obtiene nulo o una excepcin.
ObtenerUnaOrdenEM
Objetivo: Obtener una orden de examen mdico

Escenario: Se enva el cdigo de orden de examen mdico.
xito: Se obtienen los datos de la orden de examen mdico.
Fallo: No se obtiene datos, se obtiene nulo o una excepcin.
182
ObtenerUnTipoEM
Objetivo: Se obtiene un tipo de examen mdico por el cdigo del tipo.

Parmetros de entrada: Objeto BETipoEM
Escenario: Se enva el cdigo del tipo de examen mdico.
xito: Se obtiene la descripcin del tipo de examen mdico.
ObtenerTiposEMxLineaEM
Objetivo: Obtener la lista de exmenes mdicos segn la lnea de examen
mdico.
Parmetros de entrada: Objeto BELineaEM
Escenario: Se enca el cdigo de lnea de examen mdico.
xito: Se obtiene la lista de tipos de exmenes mdicos.
ObtenerUnEstadoExamenMedico
Objetivo: Obtener el estado de un examen mdico, pendiente, realizado.

Parmetros de entrada: Objeto EstadoEM
Escenario: Se enva el cdigo de estado de examen mdico.
xito: Se obtiene la descripcin del estado del examen mdico.
Objetivo: Se obtiene la lista de exmenes mdicos ordenados por el mdico.

183

Escenario: Se envan los datos de una orden de examen mdico
xito: Se obtiene la lista de exmenes mdicos por el doctor
Fallo: Se obtiene nulo, no se obtiene ningn registro o se obtiene una
excepcin,
ObtenerResultadoEMxKDetalleOrdenEM
Objetivo: Obtener el resultado de un examen mdico segn el cdigo del

detalle de examen mdico.
Parmetros de entrada: Objeto BEDetalleOrdenEM
Escenario: Se envan los datos del detalle de la orden mdica.
xito: Se obtiene el resultado del examen mdico
ObtenerDetalleOrdenxOrdenEMxEstadoDetalle
Objetivo: Se obtiene la lista de exmenes mdicos segn el cdigo de estado

y el cdigo de orden de examen mdico.
Parmetros de entrada: Objeto BEOrdenEM y BEEstadoEM
Escenario: Se enva el cdigo de la orden de examen mdico y el cdigo del
estado.
xito: Se obtiene la lista de Exmenes mdicos.
Fallo: Se obtiene nulo, ningn registro o una excepcin.
El servicio de realizacin de las pruebas unitarias fue brindado por la empresa
Software Factory. Esta empresa se encarg de asignar al personal de desarrollo a los
cuales se tuvo que capacitar para que la construccin del sistema no tenga
problemas de falta de conocimiento de las tecnologas usadas. De la misma manera,
se capacit al personal para que ejecute, sin problemas, las pruebas a este.
184

Para la realizacin de las pruebas se lleg a un acuerdo con la empresa Software
Factory dndole las fuentes del sistema para que realicen las pruebas unitarias.
Como se podr observar en las imgenes siguientes, el resultado de las pruebas
unitarias, fue satisfactoria, por lo que las funcionalidades de la capa de negocio
estn bien construidas, y por lo tanto brinda los datos requeridos.
El indicador de xito de las pruebas se refleja en la entrega del certificado de
pruebas unitarias brindado por la empresa Software Factory y, que adems fue un
requisito obligatorio para poder presentar el proyecto ante el Comit de Evaluador
Proyectos.
A continuacin se muestra el log de las pruebas.
185
Figura 7.1 Pruebas Unitarias Parte I

Figura 7.2 Pruebas Unitarias Parte II

187
Inspeccin artefactos/Documentos
La revisin de los documentos fue realizada por la empresa Quality Assurance. Esta
empresa se encarga de verificar los artefactos elaborados durante las fases del
proyecto.
A continuacin se darn a conocer los paquetes establecidos por la empresa, con sus
respectivos documentos, enviados a la empresa para la inspeccin respectiva.
Paquete
Documentos
Periodo
Paquete 1
Chrter del Proyecto
2010-02
Glosario de Trminos
2010-02
SRS
2010-02
Visin del Proyecto
2010-02
Lista de Riesgos
2010-02
Plan de Aceptacin
2010-02
Plan de Desarrollo del
2010-02
Software
Plan de Gestin de la
2010-02
Configuracin
Plan de Gestin de Riesgos
2010-02
Paquete 3
Especificaciones de Casos de
2010-02
Paquete 4
Uso
SAD
2010-02
Paquete 2
Paquete 5
Actualizacin SAD
2011-01
Documento de Diseo
Detallado
Actualizacin de
Paquete 6
Documentos
Manuales
Tabla 7.1 Tabla de Documentos inspeccionados
188
2011 01

El equipo de QA designado para la inspeccin de los paquetes presentados posea un
checklist para verificar que el contenido del documento sea el correcto. Al
terminar de realizar la verificacin enviaban un log de errores donde se discutan
los errores encontrados, y, en caso que el error sea vlido era corregido
inmediatamente por los integrantes del proyecto. Este proceso se realizaba tantas
veces como fuera necesario hasta que el documento no presente errores.
La inspeccin de los documentos por parte del equipo de QA fue exitosa.

Cumpliendo uno de los requisitos para obtener el certificado de calidad de dicha
empresa.
Validacin del Sistema

La revisin que el sistema cumpla con las funcionalidades requeridas, as como, la
integracin de los dems sistemas es realizada por la empresa Quality Assurance.
A continuacin se darn a conocer los paquetes entregados para esta fase de la
revisin.
Paquete
Artefacto
Periodo
Paquete 1
Entrega de la versin Alpha
2011-01
del Sistema
Paquete 2
Paquete 3
Entrega de la versin Beta

del Sistema
Entrega de la versin final
del sistema con la respectiva
2011-01
2011.-01
integracin
Tabla 7.2 Tabla de Artefactos entregados
El equipo de QA designado para la verificacin de los artefactos presentados posea

los documentos de los casos de uso, los cuales indican el flujo que debe seguir el
sistema. Asimismo, se realizaron las pruebas de integracin con los dems sistemas.
Este proceso se realiza las veces que sea necesario hasta que el sistema est libre de
189
fallas. Al culminar, con la verificacin del sistema se enva un documento indicando

que la verificacin fue realizada de manera exitosa.
En esta oportunidad no se realizaron pruebas no funcionales debido a que la
empresa Quality Assurance no las pudo realizar debido a que el servidor en el que
estaba desplegada la aplicacin no cumpla con los requerimientos mnimos
indicados.
Al trmino de la verificacin del sistema por parte de la empresa QA dio por
satisfactorio el funcionamiento de ste. De este modo, con las pruebas exitosas tanto
de la inspeccin de documentos como la verificacin del sistema obtuvimos la
certificacin de calidad de dicha empresa.
En el presente captulo se dio a conocer que el software es de calidad, por ello como
resultado se ha obtenido tanto la certificacin de las pruebas unitarias de la Software
Factory como la certificacin de calidad de la empresa Quality Assurance.
190
CAPTULO 8. GESTIN DEL PROYECTO20
El objetivo de este captulo es dar a conocer las actividades realizadas respecto a la

gestin del presente proyecto.
Introduccin
El planeamiento del proyecto es importante dentro del desarrollo del mismo, ya
que dar a conocer el tiempo de fin estimado del presente proyecto permitiendo
el seguimiento del avance del mismo.
Dentro de esta etapa se dar a conocer el cronograma del proyecto, as como la
estimacin del esfuerzo, el tiempo de desarrollo y los riesgos que poseer, adems
de las estrategias y soluciones que se darn a los mismos.
Equipo del Proyecto

El equipo de proyecto est conformado de acuerdo a la jerarqua de la empresa,
de este modo se pretende mostrar los cargos y las personas responsables de
estos.
20
Ver Anexo 5. Se muestran los documentos relacionados al presente captulo, los cuales fueron
realizados en el primero periodo del proyecto (2010-02).
Captulo 8: Gestin del Proyecto
Gerente General
Amanda Snchez
Gerencia de Proyectos y
Recursos Humanos
Sergio Vela Camacho
Jefe de Proyecto
Karen Farroay
Arquitecto de
Jefe de Desarrollo
Analista de Sistemas
Software
Alex Trujillo
y Procesos
Alex Trujillo
Karen Farroay
Desarrolladores
Figura 8.1 Organigrama Equipo de Proyecto

192
Roles y responsabilidades
Rol
Nombres
Comit de proyecto
Gerente General
Responsabilidad
Jorge Cabrera
Ilver Anache
Mara Hilda Bermejo
Rosario Villalta
Personas encargadas de establecer el

plan estratgico, la aprobacin de las
propuestas de proyectos, decidir la
continuidad de los proyectos, aprobar
las contrataciones,
controlar
el
cumplimiento de las metas y supervisar
la
marcha
de
las
distintas
organizaciones.
Amanda Snchez
Tener comunicacin con los gerentes

generales de las empresas virtuales.
Velar por que el proyecto cumpla con
las fechas establecidos en el
planeamiento
Gerente de Proyectos y
Recursos Humanos
Sergio Vela Camacho
Velar por que se cumpla con las

capacitaciones de los colaboradores,
necesarias para el desarrollo del
proyecto.
Realizar un eficiente seguimiento del
proyecto y evaluar a los colaboradores.
Velar que los integrantes del proyecto
posean los recursos necesarios para el
desarrollo del mismo.
Jefe de Proyecto
Jefe de Desarrollo
Arquitecto de software
Analista de Sistemas y de
Procesos
21
Karen Farroay
Persona encargada de velar que el Plan

de Proyectos se cumpla y de la
coordinacin con las gerencias de
Proyectos, Recursos y Procesos.
Asimismo, reunirse con los clientes en
caso surjan dudas
durante el desarrollo
del proyecto. 21
Alex Trujillo
Persona que se encarga de asignar el

desarrollo de las funcionalidades e
integrar las mismas en la solucin final.
Alex Trujillo
Persona que decide sobre las

tecnologas que se emplearn en el
desarrollo del proyecto. Basndose en
los
modelos
arquitectnicos
empresariales de Salud-Able.
Karen Farroay
Persona que se encarga de modelar los

casos de uso del negocio. As como de
la especificacin y validacin de los
requerimientos con los clientes y los
usuarios.
Ver Anexo 6. Se muestran las actas de reuniones realizadas en las visitas del centro de salud.
Asimismo, se muestran las actas realizadas con los gerentes de QA.
193

Rol
Nombres
Programadores
Validadores y Verificadores
Responsabilidad
Cumplir con las tareas asignadas en las

fechas establecidas.
Miembros del Software Desarrollar las tareas con calidad e
Factory
iniciativa
Cumplir con los estndares de
codificacin de la empresa
Miembros de Software
Quality Assurance
Validar la calidad de los documentos

mediante las rbricas establecidas por
la empresa.
Verificar que el sistema cumpla con los
requerimientos funcionales y no
funcionales.
Tabla 8.1 Tabla de Roles y Responsabilidades

Cronograma del Proyecto

El equipo de proyecto administr el cronograma de actividades con la
herramienta MS Project, la cual permite establecer una duracin para cada
actividad que se realice. De este modo, se dar a conocer la fecha estimada de
fin tanto de las actividades como de las fases del proyecto.
Las fases del presente proyecto son las establecidas por la metodologa RUP, las
cuales son: Concepcin, Elaboracin, Construccin y Transicin. Estas su vez se
han dividido en las siguientes 6 iteraciones: Concepcin I, Elaboracin I,
Construccin I, Construccin II, Construccin III y Transicin. A continuacin
se darn a conocer las mismas.
Fase 1 - Concepcin
Iteracin 1 Concepcin I
194
Figura 8.2 Concepcin Iteracin 1 Parte I

Figura 8.3 Concepcin Iteracin 1 Parte II

Riesgos Enfrentados
En la semana 3 del proyecto el contacto del centro de salud no se encontraba
disponible, por lo que Amanda Snchez (gerente general) nos brind otro
195

contacto, sin embargo la documentacin inicial se realiz en base al proyecto
Arquitectura de Negocios de un Centro de Salud de Nivel I-3 hasta que se
encontr otro contacto ms o menos en la semana 9.
Lecciones Aprendidas
Siempre es bueno contar con ms de un contacto para la recabar los
requerimientos.
Elaboracin
Iteracin 1 Elaboracin I
196
Figura 8.4 Fase Elaboracin Iteracin 1

Riesgos Enfrentados
Entre la semana 10 y la semana 11 se visitaron los centro del salud de San Juan
de Miraflores y San Isidro. El proceso encontrado es diferente al propuesto. Se
realiz una nueva captura de requerimientos.
Entre la semana 13 y 14 se revis la arquitectura de datos y de software, stas al

cambiar el proceso tuvieron que cambiar. Se realiz una reunin con los jefes de
proyecto para realizar una nueva arquietctura que sea viable para todos los
proyectos.
197

Siempre es bueno verificar que los requerimientos encontrados en proyectos
anteriores no hayan variado en el tiempo, de modo que los sistemas se adecen a
los procesos actuales.
El sistema, el cual es integrado por varios proyectos, debe tener la misma

arquietctura para cada uno de ellos, de modo que no afecte la comunicacin
entre ellos. Esta arquitectura debe ser definida por los arquitectos y jefes de cada
proyecto.
Construccin
Iteracin 1 Construccin I
Figura 8.5 Fase Construccin Iteracin I

198

Iteracin 2 Construccin II
Figura 8.6 Fase Construccin Iteracin II

Riesgos Enfrentados
Los desarrolladores asignados por la empresa Software Factory, no conocen la
tecnologa que se va a utilizar. Se realiz capacitaciones.
La tecnologa a usar es ms compleja de lo previsto. El jefe de desarrollo
asumen el rol de desarrollador, mientras el jefe de proyecto se encarga de la
investigacin de la herramienta.
En los proyectos no es bueno subestimar los tiempos y conocer las herramientas
que se van a utilizar para el desarrollo de modo que no genere atrasos.
Iteracin 3 Construccin III
Figura 8.7 Fase Construccin Iteracin III

199
Figura 8.8 Fase Construccin Iteracin IV

Figura 8.9 Fase Construccin Iteracin V

Riesgos Enfrentados
El desarrollo del proyecto es ms lento de lo previsto por lo que el jefe de proyecto
asume el rol de desarrollador.
La empresa IT-Expert no cuenta con los conocimientos necesarios para realizar el

despliegue del sistema. Se realiz la configuracin en los servidores.
200

Demora por parte de la empresa Quality Assurance para la realizacin de pruebas. Se
capacit en el sistema al personal asignado para que las pruebas sean ms rpidas.
La empresa IT-Expert no posee los requerimientos mnimos para realizar las pruebas de
performance, se deriv el problema al gerente de proyectos, no se realizaron este tipo de
pruebas.
Demora en el despliegue final de la aplicacin, se deriv al gerente de proyectos, se

ampli el plazo en el despliegue.
En los proyectos no es bueno subestimar los tiempos y conocer las herramientas que se
van a utilizar para el desarrollo de modo que no genere atrasos.
Las empresas encargadas del despliegue de los sistemas deben contar con personal
calificado para realizar los despliegues de las aplicaciones.
Las empresas encargadas del despliegue debe contar con los recursos necesarios para
poder realizar las pruebas del sistema.
Se debe capacitar personalmente al personal de calidad sobre el sistema para que las
pruebas sean rpidas, de modo que reducen el tiempo de lectura y realicen slo la
ejecucin.
201

El atraso del tiempo en el desarrollo del proyecto y los problemas surgidos en el
despliegue de la aplicacin y en las pruebas, ocasiona que el
Transicin
Iteracin 1 - Transicin
Figura 8.10 Fase Transicin Iteracin Transicin

Estimacin de Esfuerzo y Tiempo de Desarrollo

Para la estimacin del proyecto se utiliz la metodologa Modelo Constructivo
de Costos (COCOMO, por sus siglas en ingls, Constructive Cost Model), de la
cual se obtuvo el esfuerzo, el tiempo de desarrollo y el tamao del equipo
promedio del proyecto. A continuacin, se mostrar los resultados obtenidos.
Modelo Constructivo de Costos

Esfuerzo
67.78 horas/hombre
Tiempo de Desarrollo
10.94 meses
Tamao del Equipo (promedio)
6 hombres
Tabla 8.2 Resumen de Esfuerzo, Tiempo y Tamao del equipo del Proyecto
202

Finalmente, se estableci el porcentaje de duracin por cada fase definida segn la
metodologa RUP, con el fin de obtener el esfuerzo y el tiempo que requerir cada una
de ellas.
Fase
Esfuerzo
Tiempo
Concepcin
3.39
1.09
Elaboracin
13.56
3.28
Construccin
44.06
5.47
Transicin
6.78
1.09
Tabla 8.3 Resumen de Esfuerzo, Tiempo y Tamao del equipo por Fases
Riesgos del Proyecto

Para estimar el impacto que tendr un riesgo sobre el proyecto Sistema de
Registro de Atencin Mdica, primero se deber estimar la probabilidad que el
riesgo ocurra, seguido por la severidad del mismo. Al realizar una tabla de
encuentro entre estos dos factores, se obtendr el impacto del riesgo sobre el
sistema.
Tabla de Probabilidad
Se ha establecido un puntaje segn la probabilidad que el riesgo ocurra sobre el
proyecto.
203

Nombre
Intervalo
Puntaje
Muy alta
75% - 100%
Alta
45% - 75%
10% 45%
0% 10%
0%
Probabilidad Media
Baja
Ninguna
Tabla 8.4 Probabilidad que el riego ocurra

Tabla de Severidad
Se ha establecido un puntaje segn la severidad que tendr el riesgo sobre el
proyecto.
Nombre
Descripcin
Puntaje
El riesgo causar un gran impacto en el

proyecto causando el fracaso o la
Muy alta cancelacin del mismo.
10
El riesgo impide que el cliente acepte el

producto final o que genere cambios en el
cronograma
que
no
puedan
ser
manejados, conllevando a un retraso

considerable
Severidad
Alta
en
el
desarrollo
del
proyecto.
El riesgo retrasa la ejecucin planificada

del proyecto, sin embargo puede ser
Media
controlada.
El riesgo no compromete al xito del

proyecto, slo afecta algunas variables de
Baja
poca relevancia.
Tabla 8.5 Severidad del riesgo sobre el proyecto

204
Tabla de Probabilidad vs. Severidad

El clculo se realiz multiplicando el puntaje de la probabilidad con el puntaje
de la severidad dando como resultado la siguiente tabla:
Severidad
Muy alta
Alta
Media
Baja
Muy alta
70
49
28
Alta
50
35
20
30
21
12
10
Probabilidad Media
Baja
Ninguna
Tabla 8.6 Impacto del riesgo sobre el proyecto

Tabla de Criticidad
El rango de la criticidad del riesgo ser de acuerdo a los puntajes obtenidos en la
tabla anterior.
Rango
Muy crtico
40 70
Crtico
21 40
Mediano
5 21
Leve
05
Tabla 8.7 Nivel de criticidad del riesgo

Riesgos Identificados
Los riesgos identificados para el siguiente proyecto, son los siguientes:
205

Riesgos
N
Descripcin
Demora por parte de los desarrolladores asignados por la fbrica de SW en

capacitarse en las tecnologas a usar en el desarrollo del proyecto.
No existen los recursos necesarios en las fbricas de desarrollo para la

implementacin y despliegue del sistema.
Demora por parte de los integrantes del proyecto en la entrega del sistema a la
empresa SQA para la realizacin de las pruebas.
La persona designada como contacto para la comunicacin con el centro de

salud no est disponible para aclarar cualquier duda que pueda presentarse
dentro del equipo de proyecto.
Las entidades de salud cambian sus procesos definidos durante el desarrollo del
proyecto, aumentando su nivel de complejidad.
La informacin provista por el proyecto "Diseo de la Arquitectura de

Aplicaciones para un Establecimiento de Salud de Nivel I-3 de Complejidad"
de la empresa virtual Salud-able
no posee una completa captura de
requerimientos.
7
Los servicios de los sistemas relacionados con el proyecto, no estn

debidamente definidos y probados, llevando a que la integracin sea un fracaso.
La informacin provista por el proyecto "Diseo de la Arquitectura de Datos

para un Centro de Salud de Nivel I-3 de Complejidad" no posee una correcta
definicin de la arquitectura de datos y se tiene que rehacer parte del modelo.
Tabla 8.8 Riesgos del Proyecto

206
Impacto del Riesgo

Segn los riesgos identificados se ha identificado su nivel de criticidad y el
impacto de estos sobre el proyecto
Riesgos
Calificacin
Criticidad
Crtica
Impacto
Probabilidad Severidad Puntuacin
Descripcin
Se podran asumir funcionalidades
Media
Muy Alta
30
errneas.
Crtica
Media
Muy Alta
30
Crtica
Media
Muy Alta
30
Mediana
Baja
Alta
errneas.
Retraso en la entrega de proyecto.

errneas.
El proyecto perdera funcionalidad
5
Mediana
Baja
Alta
7
El
proyecto
no
tendra
la
funcionalidad esperada por el

6
Mediana
Baja
Muy Alta
10
cliente y el tiempo de desarrollo

del proyecto estimado se ver
afectado
El proyecto perdera integracin
Mediana
Baja
Muy Alta
10
Mediana
Baja
Muy Alta
10
con los otros proyectos.

El proyecto no soportara la
Tabla 8.9 Impacto de los riesgos sobre el proyecto

207
informacin necesaria.
Tabla de Estrategias ante los Riegos

Luego de identificar el impacto de cada uno de los riesgos sobre el proyecto, se
deber analizar las estrategias a realizar sobre este.
Riesgos
N
Estrategias a Aplicar
Estrategia
Acciones a Aplicar
Responsable
El jefe de desarrollo deber capacitar a los

1
Asumir
desarrolladores. Tambin asumir el rol de Alex Trujillo

desarrollador para mitigar el retraso.
Solicitar al Gerente de Recursos, Delmer
Transferir
Espinoza, que resuelva la situacin.
Karen
Farroay
Se dar capacitar al equipo asignado para

3
Asumir
las pruebas, acerca del aplicativo con el fin
Karen
que conozcan el sistema y puedan realizar
Farroay
las pruebas con ms rapidez.

Solicitar a la Gerente General de Salud4
Transferir able, Amanda Snchez, que gestione la

comunicacin con otro contacto.
Karen
Farroay
Se deber reunir con el contacto designado

para conocer los cambios realizados. Si el
5
Mitigar
cambio es muy drstico se deber proponer

para una siguiente iteracin fuera del
Karen
Farroay
presente proyecto.
6
Asumir
para
hacer
una
nueva
captura
de
requerimientos.
Se deber reunir con los jefes de proyectos
7
Asumir
de los proyectos involucrados para llegar a

una solucin viable entre todos.
Transferir
Karen
Farroay
Karen
Farroay
Solicitar al jefe de proyectos, Sergio Vela,
Karen
que la arquitecta de datos resuelva esta
Farroay
208

situacin.
Tabla 8.10 Estrategias a Aplicar sobre los Riesgos del Proyecto
Para el presente proyecto los riesgos se convirtieron en problemas dndonos la

oportunidad de ejercer nuestro plan de mitigacin. A continuacin los riesgos que se
consolidados.
Riesgos Estrategias a Aplicar
N
Estrategia Acciones a Aplicar
Responsable
El jefe de desarrollo deber capacitar a los

1
Asumir
desarrolladores. Tambin asumir el rol de Alex Trujillo

desarrollador para mitigar el retraso.
Transferir
Solicitar al Gerente de Recursos, Delmer Karen

Espinoza, que resuelva la situacin.
Farroay
Se dar capacitar al equipo asignado para

3
Asumir
las pruebas, acerca del aplicativo con el fin Karen

que conozcan el sistema y puedan realizar Farroay
las pruebas con ms rapidez.
Solicitar a la Gerente General de Salud-
Transferir
able, Amanda Snchez, que gestione la

comunicacin con otro contacto.
Karen
Farroay

para conocer los cambios realizados. Si el
5
Mitigar
cambio es muy drstico se deber proponer

para una siguiente iteracin fuera del
presente proyecto.
209
Karen
Farroay

6
Asumir
para
hacer
una
nueva
captura
de
requerimientos.
Solicitar al jefe de proyectos, Sergio Vela,
8
Transferir
que la arquitecta de datos resuelva esta

situacin.
Karen
Farroay
Karen
Farroay
Tabla 8.11 Problemas durante el desarrollo del proyecto

Asimismo, se debe indicar que para el riesgo N 1, no solo se llev a cabo esta
estrategia, debido al poco conocimiento de la tecnologa utilizada. Para ello, se tom la
siguiente decisin:
Alex Trujillo seguira asumiendo el rol de desarrollador.
Karen Farroay ayudara a la investigacin de la tecnologa y a la resolucin de
problemas. Es por ello, que se cre una cuenta en el foro de Liferay para conseguir
ayuda de los expertos en esta. Asimismo, en caso que llegara a faltar ms tiempo
tambin asumira el rol de desarrollador.
Acuerdos entre proyectos

Debido a funcionalidades comunes entre el presente proyecto y Sistema de
Atencin Mdica Odontolgica, se lleg al acuerdo que ambas partes se
dividiran estas de modo que no impacte el tiempo de desarrollo del proyecto
(Ver Anexo 7)
210
CAPTULO 9. TRANSICIN
Este captulo describir el contenido de los entregables en la fase de transicin del

sistema.
Introduccin
El objetivo de este captulo es dar a conocer el plan de entregables para la fase de
transicin del sistema, as como las actividades realizadas para dar por culminado el
proyecto de manera satisfactoria.
Desenlace del Proyecto
Durante esta fase se procedi a elaborar los artefactos establecidos en el plan del
proyecto para cumplir con la puesta en produccin del sistema y presentar el producto
final ante los interesados del proyecto.
El hito principal de esta fase del proyecto fue la obtencin del certificado de despliegue
que fue otorgada por la empresa IT-Expert. Este certificado es el ltimo necesario para
la aprobacin del proyecto por parte de los miembros del comit de evaluacin y
significa que los manuales de instalacin y configuracin entregados a los recursos de la
empresa certificadora son correctos y que su contenido permite realizar la instalacin de
la aplicacin, servicios web y de la base de datos de manera exitosa.
Una vez obtenido el certificado se procedi a solicitar una presentacin del proyecto a
los miembros del comit evaluador. El resultado de la presentacin fue exitoso y
aprobado.
Captulo 9: Transicin
Instaladores
Dado a que el sistema SISREGAME forma parte de una solucin integral, se gestion la
creacin del instalador que contenga el compilado de todos los componentes necesarios
para el correcto funcionamiento del sistema. Debido a la tecnologa utilizada que es
JAVA se tuvo dos archivso con extensin WAR (*.war).
SISREGAME_Protlet.war
SISREFAME_WebServices.war
Estos fueron incorporados en el disco de instalacin a la empresa IT-Expert. La empresa

se encarg del despliegue de ambos compilados en el ambiente de produccin del
administrador de contenidos Liferay 5.3.2 y en el Servidor de Aplicaciones Glassfish.
Los detalles de instalacin y configuracin se encuentran los manuales que se

encuentran dentro del disco de instalacin.
Manuales
Manuales de Usuario
El Manual de Usuario tendr el siguiente contenido:
El contenido del manual est estructurado y describe las funcionalidades del

sistema de acuerdo al orden de la actividad en el proceso.
Caractersticas del sistema. La descripcin del sistema debe tener omitidos

trminos tcnicos y permitir su entendimiento al usuario sin complejidad
alguna. Para un mejor entendimiento se tendr que emplear el uso de
imgenes a fin de que el usuario comprenda cul es el contenido que debe
212

mostrar el sistema ante la ejecucin de alguna aplicacin.
Informacin de los principales errores que se pueden presentar a los usuarios

finales.
Manual de Instalacin
El Manual de Instalacin se incluy en el disco de instalacin del sistema.

El Manual de Instalacin incluye:
Directrices de instalacin del Administrador de Contenidos Liferay 5.3.2.
Directrices para la instalacin de la base de datos del sistema SISREGAME.
Gua de despliegue de la aplicacin en el administrador de contenidos.
Publicidad
Afiche
Se elabor el pster o afiche de presentacin del sistema SISREGAME en donde se
resume cual es su finalidad y las caractersticas ms resaltantes que posee.
El objetivo de la elaboracin del afiche es el de dar a conocer el producto final, as
como captar la atencin de los futuros usuarios del mismo. El afiche fue realizado en
tamao de papel A3 para que pueda ser ubicado en lugares estratgicos y llamar la
atencin de las personas que circulen por su alrededor de esta manera impulsar el inters
para la adquisicin del producto.
En la seccin superior se muestra el logo de la empresa Salud-able para destacar que es
la empresa que impuls y apoy el desarrollo del proyecto. Adicionalmente se muestra
el nombre del proyecto.
Seguidamente, se presentan capturas de pantalla de los portlets que corresponden
principalmente a los formatos establecidos por el MINSA con respecto a la atencin
mdica de un paciente en funcin de la etapa de vida en la que se encuentre.
En la seccin inferior izquierda se presenta las tecnologas utilizadas en la aplicacin. El
objetivo es presentar a los lectores las herramientas libres de pago por uso que se
utilizaron y fueron determinantes para la culminacin exitosa del proyecto.
En la seccin inferior derecha se muestra el nombre de los jefes de proyecto y
desarrollo, y el logo del establecimiento acadmico que los alberg y proporcion los
recursos necesarios, como profesores, libros e infraestructura, para que los jefes del
proyecto culminen el mismo de manera exitosa destacando la gestin para el
cumplimiento de los tiempos, presupuestos y calidad del proyecto.
213
Captulo 9: Transicin
Figura 9.1 Afiche

214

Caja Contenedora
Las cajas fueron diseadas de manera libre sin un estndar definido por la facultad de
ingeniera, tal y como se haca anteriormente. El contenido de la caja incluye un CDROM de Instalacin, Manual de Usuario y Manual de Instalacin. Tambin se incluyen
etiquetas con el logotipo del sistema.
Diapositivas para Presentacin

Se elaboraron diapositivas para mostrar en resumen el ciclo de vida del proyecto.
Demos
Como parte de la presentacin del sistema, se procedi a elaborar una demo que
permiti de manera visual poder explicar el sistema y las funcionalidades que ofrece.
Al finalizar el proyecto, se hizo entrega de los artefactos mencionados en el presente

captulo. Asimismo, se hizo entrega de lo archivo con extensin .war para que sean
desplegados en un servidor para su uso, siempre y cuando posea los requerimientos
mnimos indicados en este documento. Finalmente, se hizo entrega de dos documentos
adicionales solicitados en las reuniones con el especialista en el tema, Jorge Cabrera,
estos documentos son: el documento de auditora el cual posee las tablas y los campos
que son sensibles y que deben ser auditados; y el documento de seguridad que establece
el mtodo y la implementacin de seguridad para el presente sistema.
215
CONCLUSIONES
El modelo de proceso de negocio de Prestacin de Servicios Clnicos

establecido por el proyecto Arquitectura de Negocios de un Centro de Salud de
Nivel I-3 de Complejidad present incongruencias con respecto a la
informacin recopilada en las reuniones establecidas con miembros de dos
centros de salud de nivel I-3. Por ende, se tuvo que dedicar tiempo del plan a una
reestructuracin del modelo de procesos del negocio logrando que este se
asemeje a la realidad. Las diferencias encontradas se muestran en el punto 1.1.1
reflejada en la Figura 2.1
La arquitectura de datos, con respecto a los procesos de Prestacin de Servicios
Clnicos y de Control de Exmenes Mdicos establecida por el proyecto
Diseo de Arquitectura de Datos de un Establecimiento de Salud de Nivel I-3
no fue la correcta de acuerdo a lo conversado con los mdicos de los centros de
salud y los formatos del nio, adolescente, adulto y adulto mayor estandarizados
del MINSA establecidos para las entidades I-3, por lo que se logr redefinir
correctamente el modelo de datos para que soporte la realidad encontrada.
La arquitectura de aplicacin del software, establecida por el proyecto Diseo
de una Arquitectura orientada a servicios para un centro de nivel I-3 de
Complejidad no fue la ms adecuada, dada la homogeneidad de tecnologas a
utilizar por los diferentes mdulos del Sistema Integral de Salud por ello se
revis y se reestructur para que cumpla con los requerimientos del cliente y de
la empresa. Se seleccion la plataforma Liferay en vez de Sun Mycrosystem por
la compra de Sun por ORACLE, dado que el sistema podra dejar de ser gratuito
y porque los requerimientos mnimos son menores, por lo que reduce el costo en
la compra de servidores por parte del Ministerio de Salud. Asimismo, se
seleccion el servidor Glassfish por encima del propuesto (Tomcat) por la
compatibilidad de la base de datos seleccionada.
Durante el proceso de desarrollo del proyecto se identificaron tareas que
sufrieron un retraso debido a una subestimacin de las mismas. En
consecuencia, se tuvo que poner en accin del plan de resolucin de problemas y
se pudieron regularizar las mismas. Sin embargo, esto demand tiempo de
trabajo adicional que en la prctica real de trabajo hubiera significado un
aumento en los costos por horas extras de los recursos. Por consiguiente, la
estimacin de una tarea requiere de analizar las actividades relacionadas con la
misma, a pesar que el tiempo que requiera cada actividad aparente poca
significancia. Adems, al no usar desde un inicio una herramienta de control de
versiones demand la inversin de tiempo para realizar la homologacin de las
fuentes del sistema.
Como parte del plan de riesgos, se tuvo que capacitar a los miembros de la
fbrica Software Factory. En consecuencia el apoyo brindado por los recursos
fue efectiva durante la etapa de construccin del producto software.
216

Los artefactos elaborados en cada fase del proyecto, as como el sistema fueron
sometidos a validacin y verificacin por la empresa Quality Assurance (QA)
que fue la empresa que se encarg del aseguramiento de la calidad durante
periodo de ejecucin del proyecto. El resultado del anlisis de estos fue
satisfactorio lo que lleva a concluir que el producto realizado es de calidad y
cumple con los estndares propuestos por la metodologa RUP.
Debido a que el servidor de pruebas no contaba con los requerimientos mnimos
solicitados en el documento de arquitectura de software (SAD) y Plan de
Aceptacin, no se pudieron realizar las pruebas no funcionales al sistema.
Tanto el plan de riesgos, como el plan resolucin de problemas fueron
herramientas valiosas dado a que si no se hubiese dedicado tiempo para analizar
las amenazas y vulnerabilidades del proyecto es muy probable que el mismo no
haya un resultado exitoso.
Mediante el sistema se logr automatizar el proceso de consulta externa
ambulatoria general y el proceso de control de exmenes mdicos de laboratorio.
Adems, el sistema obtuvo las certificaciones de la empresa QA, Software
Factory e IT- Expert, que son requerimientos establecidos por los miembros del
comit para poder obtener la aprobacin del proyecto. Estos factores conllevan a
la conclusin de que se alcanzaron los objetivos del proyecto y que el resultado
fue exitoso.
Se concluye que la interaccin entre los sistemas Sistema de Registro Mdico
Electrnico, Sistema de Gestin Horaria, Sistema de control de Farmacia y
Sistema de Atencin Mdica Odontolgica para un centro de Salud I-3 es
adecuada. La empresa Quality Assurance ejecut una serie de pruebas integrales
en donde se valid el registro de un paciente, el registro de una cita mdica, su
activacin y atencin, el registro de un episodio y encuentro mdico, el registro
de una receta mdica, solicitud de exmenes mdicos, la venta de las medicinas
y el registro de los resultados de los exmenes realizados al paciente; estas se
realizaron sin inconvenientes por lo que se aprob el sistema para el pase a
produccin.
217
RECOMENDACIONES
Es importante dedicar un tiempo de evaluacin de la informacin obtenida por

fuentes externas, dado a que de lo contrario existe la probabilidad de que el
resultado de un proyecto sea errado o no satisfactorio para el cliente. Para el
presente proyecto se verific que la investigacin realizada por compaeros de
ciclos anteriores sea la correcta. Para esto se tuvo que solicitar entrevistas con
personal involucrado y experto en los procesos tratados y como resultado se
identificaron puntos que requeran un reajuste.
Para la definicin de una arquitectura de software se deben considerar los
factores econmicos, de hardware disponible o con el que se pueda contar.
Adems, se debe considerar las tendencias a futuro de las tecnologas a utilizar
para la implementacin del sistema.
En general, el establecimiento de una arquitectura de datos para la
implementacin de un sistema es crtico debido a que este debe almacenar los
datos del negocio y la omisin de un dato puede desencadenar en prdida para la
empresa. En el caso particular, de una entidad de salud es ms crtica an debido
a que la falta de un dato puede desencadenar en una mala decisin por parte del
mdico en la receta de medicamentos para un paciente sin considerar, por
ejemplo, un problema de alergias o dolencias identificadas en encuentros
mdicos pasados. La arquitectura de datos debe ser diseada en base al alcance
definido para el proyecto.
Se recomienda conocer las herramientas con las que se va a realizar el desarrollo
del sistema para no conllevar a retrasos debido al desconocimiento en la
herramienta durante la implementacin del sistema.
218

Se recomienda utilizar una herramienta de control de versiones para tener la
documentacin y fuentes del sistema actualizados conforme se avanza con el
desarrollo del proyecto. De esta manera poder identificar quin y cundo se
hicieron modificaciones a las fuentes del sistema y poder obtener una versin
anterior que apoye a obtener la versin estable del sistema.
Se recomienda que los desarrolladores de software tengan conocimiento de la
herramienta de desarrollo debido a que el tiempo en realizar capacitaciones
tcnicas es progresivo y conllevan a retrasos en la implementacin del sistema.
El jefe de proyecto debe revisar de manera peridica, el planeamiento de
proyectos, identificar a detalle las actividades a realizar en las tareas registradas
para no caer en retrasos; y reestructurar el mismo para cumplir con la fecha final
de entrega del proyecto.
El jefe de desarrollo debe establecer constante comunicacin con los
colaboradores de desarrollo dado a que se ha identificado que ante posibles
problemas tcnicos la persona busca solucionar por sus propios medios
realizando actividades de investigacin cuya inversin de tiempo puede
extenderse de manera que cause un desfase significativo con el plan de
actividades del proyecto.
Para la asignacin de tiempos para realizar un plan de trabajo, adems del uso de
las metodologas como COCOMO es necesario tener conocimiento de la
actividad a realizar o consultarlo con el arquitecto de software y con el
colaborador que son las personas que cuentan la experiencia para poder estimar
un tiempo promedio para la ejecucin de la actividad.
Es importante que los artefactos resultados de cada fase sean verificados por
profesionales que conozcan de la metodologa utilizada. Para el proyecto actual
se encontraron observaciones con respecto a la informacin de los documentos
elaborados. El objetivo de la metodologa RUP no es elaborar todos los
documentos propuestos y dejar informacin vana en cada uno de ellos. El jefe de
219

proyecto debe determinar cules de los artefactos son importantes para elaborar
que reflejen las decisiones tomadas con respecto al sistema.
Es importante que las personas que ejecuten las pruebas funcionales del
producto software sean ajenos a la construccin del mismo. Estas personas
debern informarse del alcance de la funcionalidad por los documentos de
especificacin de casos de uso en donde identificarn las pre condiciones y post
condiciones de la ejecucin de una funcionalidad.
Cuando el cliente acepta las condiciones del ambiente necesario para la
implantacin del producto final, se recomienda coordinar con el mismo para que
se gestione la adquisicin de las herramientas software y hardware necesarios.
La ausencia de los mismos o contar con un ambiente que no cumple con los
requisitos mnimos conllevan a que las pruebas sean deficientes y no poder
medir o someter a pruebas los requerimientos no funcionales. La puesta en
produccin de un software sin este tipo de pruebas puede conllevar a constantes
cadas del sistema generando malestar en los usuarios y en el flujo de
actividades del negocio, ms an cuando se trata de un ce ntro de salud que
requiere la agilidad de los procesos.
Para realizar un plan de riesgos y de resolucin de problemas se debe tener
conciencia que no solo son documentos formales para cumplir con la
metodologa de referencia. La ausencia de un plan bien estructurado o la no
consideracin de riesgos o problemas crticos para el desarrollo natural del
proyecto puede conllevar al fracaso del mismo o no cumplir con los tiempos
establecidos en el plan que causa malestar en el cliente quien puede tomar la
decisin de eliminar el proyecto o establecer penalidades para el jefe de
proyecto.
El xito del proyecto radic en la buena interaccin del equipo de trabajo y de
los procesos definidos para las diferentes fases del proyecto. El jefe de proyecto
es la persona que debe interactuar con el cliente y con las entidades terceras que
220

intervengan en el proyecto por lo que es necesario tener claridad y respeto en la
comunicacin con los mismos. Para el presente proyecto se interactu con 3
empresas virtuales que son Quality Assurance, Software Factory e IT- Expert
con quines mediante la coordinacin y la buena gestin de los participantes se
pudieron resolver problemas identificados en diferentes etapas del proyecto.
Cuando un sistema tenga que interactuar con otros es importante dejar en claro
con los responsables de cada sistema el qu y el cmo se comunicarn los
sistemas. Se debern definir mtodos y estructura de datos para que el flujo de
comunicacin de los sistemas est correctamente orquestado. Adems es
necesario definir vas de comunicacin ante posibles cambios o modificaciones
de los procesos de interaccin y no caer en problemas cuando se realicen las
pruebas integrales del sistema.
221
BIBLIOGRAFA
2010 ANGEL Sistema Integral de Administracin de Salud

(http://www.proyectoangel.net)
Sitio web oficial del sistema Sistema Integral de Administracin de Salud
donde se encuentra informacin del sistema. (consulta: 18 de
septiembre).
2010
BizAgi
(http://www.bizagi.com/index.php?option=com_content&view=article&
id=95&Itemid=107&lang=es)
Sitio web oficial del sistema BizAgi que brinda informacin detallada del
mismo. (consulta: 10 de Julio).
2009
CORONADO, Joel y ZAMUDIO, Christian

Diseo de Arquitectura de Datos de un Establecimiento de Salud de Nivel I-3
(Tesis de Ingeniera de Software).
Lima: Universidad Peruana de Ciencias Aplicadas
2010 Glassfish
Sitio web oficial de Glassfish donde se encuentran las diferentes
aplicaciones realizadas por la empresa como WebSpace Server y
OpenESB (consulta: 10 de Setoembre)
2010 HHS U.S. Department of Health and Human Services (http://www.hhs.gov)

Sitio web oficial del departamento de salud de Estados Unidos con
informacin acerca de los estndares y polticas de los pacientes de un
centro mdico. (consulta: 18 de septiembre).
2010 Hospital OS (http://www.hospital-os.com/en/)
222

Sitio web oficial del sistema que brinda informacin detallada del mismo.
(consulta: 18 de septiembre).
2010 MINISTERIO DE SALUD (MINSA) (http://www.minsa.gob.pe)

Sitio web oficial con toda la informacin acerca del MINSA. (consulta:
18 de septiembre).
2004
MINSA
Norma Tcnica. Categoras de establecimientos del sector salud. N 021
MINSA.
2010
MySQL
Sitio web oficial del gestor de la base de datos donde se encuentra
informacin acerca del software y los archivos de descarga para la
instalacin del mismo (Consulta: 3 de Setiembre)
2010
NetBeans (http://netbeans.org/community/releases/67/)
Sitio web oficial donde se encuentra informacin y los archivos de
descarga del IDE (Consulta: 30 de Agosto)
2010 OpenELIS (http://openelis.uhl.uiowa.edu/)

2010 OpenEMR (ttp://www.oemr.org/)

2009
RAMREZ, Mara y CRDENAS, Andrea

Arquitectura de Negocios de un Centro de Salud de Nivel I-3 de
Complejidad (Tesis de Ingeniera de Sistemas).
223

2009
ROMN, ngel y MARTINEZ, Nilo

Diseo de una Arquitectura orientada a servicios para un centro de nivel I-3
de Complejidad (Tesis de Ingeniera de Software).
2010 StarUML (http://staruml.sourceforge.net/en/)

Sitio web oficial de la aplicacin StarUML se encuentra la opcin de
descarga del software, as como el cdigo fuente para unirse a la
comunidad desarrolladora y contribuir con funcionalidades al mismo.
(Consulta: 10 de septiembre).
ANEXOS
Anexo 1 - Especificacin de Requerimientos

Anexo 2 - SAD
Anexo 3 - Documento de Diseo Detallado
Anexo 4 - Certificaciones (Software Factory,QA, IT-Expert), Informes de QA y
Pruebas Unitarias.
Anexo 5 - Contrato de Servicios, Especificaciones de Casos de Uso, Manuales de
usuario, Manual de Instalacin y Configuracin.
Anexo 6 - Acta de Reuniones, Formatos Mdicos.
Anexo 7 - Acuerdos con los sistemas de saludable (SISCOFARMA, SISGEHO,
SISREGMED y SAMO).
224

Sistema de Registro de Atención Médica para Un Centro de Salud de Nivel I-3 de Complejidad

Încărcat de

Informații document

Titlu original

Drepturi de autor

Formate disponibile

Partajați acest document

Partajați sau inserați document

Opțiuni de partajare

Vi se pare util acest document?

Este necorespunzător acest conținut?

Drepturi de autor:

Formate disponibile

Sistema de Registro de Atención Médica para Un Centro de Salud de Nivel I-3 de Complejidad

Încărcat de

Drepturi de autor:

Formate disponibile

FACULTAD DE INGENIERA

CARRERA DE INGENIERA DE SOFTWARE

Sistema de registro de atencin mdica para un centro

A nuestros padres que depositan da a da su confianza en nosotros y

RESUMEN EJECUTIVO ............................................................................................................................ 8

Procesos del Negocio ........................................................................................................................ 53

DESCRIPCIN DEL COMPONENTE ................................................................................................................. 140

ROLES Y RESPONSABILIDADES ...................................................................................................................... 193

Como consecuencia de la definicin de la cartera de proyectos se iniciaron, en paralelo,

El presente proyecto tiene como objetivo general la implementacin de un sistema que

A continuacin, se mostrar un resumen de la organizacin del presente documento, el

El Captulo 1 explica la descripcin del proyecto. En este acpite se detallarn las

identificados y las herramientas tecnolgicas a usar para construir el sistema

El Captulo 8 trata de la gestin del proyecto, en este captulo se dar a conocer al

CAPTULO 1. DESCRIPCIN DEL PROYECTO

Cfr. MINSA 2010

Cfr. NT N0021- MINSA: 6

Figura 1.1 Mapa de Procesos

Igualmente, se obtuvo el portafolio de proyectos para poder realizar un sistema integral

Dominio del Problema

Anlisis del Problema

El acceso al historial clnico de los pacientes, dado a que se encuentran en documentos

Las investigaciones realizadas dentro de la empresa Salud-able identificaron que los

Proyecto ngel: http://www.proyectoangel.net/

Tcnicamente es un sistema cliente servidor que requiere su instalacin en

Hospital OS: http://www.hospital-os.com/en/

El valor agregado que se le ha dado al proyecto es de realizar un proyecto escalable y

En base a la problemtica descrita anteriormente se propone la solucin de un proyecto

Alcance del Proyecto

En un centro de salud de nivel I-3 de complejidad existen dos tipos de consulta

La gestin de informacin en lo que respecta a consulta externa general en un

Consultar Prescripcin (Caso de Uso - Extendido)

La integracin con el proyecto Sistema de Registro Mdico Electrnico para un

La integracin con el proyecto Sistema de Gestin Horaria para un Centro de

La integracin con el proyecto Sistema de Control de Farmacia para un centro

La integracin con el proyecto Sistema de Atencin Mdica Odontolgica para

El Alcance del proyecto NO incluir:

El mantenimiento del administrador de contenidos.

La impresin desde el sistema. Es decir, el sistema solo exportar la

El registro de los resultados de exmenes de diagnstico por imgenes.

El mantenimiento del sistema una vez desplegado en el centro de salud.

La compra del hardware necesario para la implementacin del sistema.

La compra de las licencias necesarias para la implementacin del sistema.

La gestin de informacin de otro tipo de consultas mdicas.

La determinacin acerca de qu metodologa utilizar para la gestin de un proyecto

Microsoft Word 2010

Microsoft Excel 2010

Microsoft PowerPoint 2010

Microsoft Project 2010

Tortoise SVN 1.7

Es un sistema de gestin de bases de datos relacionales (SGBD), capaz de

Objetivos del Proyecto

Implementar un producto software que automatice:

1. El proceso de atencin de una consulta externa general ambulatoria, y

OE1 - Elaborar una solucin software de calidad que permita:

Cfr. Identificacin estndar de dato en salud N006

I1. OE1. Documento de Aprobacin por parte de la empresa QA y/o a quienes

Dado que el resultado del proyecto estaba enfocado al lanzamiento de un producto

Por ltimo, ya definido el objeto de estudio y teniendo en claro las herramientas a

CAPTULO 2. MARCO TERICO

Ministerio de Salud - MINSA

Modelo de Atencin Integral de Salud - MAIS

componentes, sistemas, procesos e instrumentos, que operando coherentemente,