Implementación de un software web basado en Arquitectura Orientada a Servicios para mejorar el monitoreo de pacientes
afiliados en un Centro Hospitalario de Lima
Jose Eduardo Quispe Garcia
Facultad de Ingeniería de Sistemas e Informática
Universidad Tecnológica del Perú
Lima, Perú
u17203442@utp.edu.pe
Abstract— En este trabajo presentamos la implementación
de un software web basado en arquitectura orientada a
servicios para mejorar el monitoreo de paciente en un centro
hospitalario de Lima.
Debido a que algunos centros de salud implementan nuevas
arquitecturas en sus sistemas sin analizar el alcance o
limitaciones que podrían conllevar, es así que al no ser
conscientes utilizan arquitectura para que sus sistemas sean
independientes, esto ocasiona que no se pueda compartir
informacion como es el caso del historial clínico. Este software
utilizó la metodología RUP ya que es la que más se ajusta a la
actual investigación debido a que aborda proyectos de gran
escala, cuenta con una mejor documentación lo cual permitirá
el desarrollo de la investigación. es practico y presenta un
enfoque para el entorno médico que estamos abordando
Palabras Claves — SOA, Arquitectura Orientada a Servicios,
Monitoreo, Salud, Historia Clínica
I. INTRODUCCIÓN
Actualmente los avances en la medicina han ampliado la
esperanza de vida en la sociedad, lo que ocasiona a que una
persona pueda sufrir diversos cuadros de atención medica
durante su existencia. A diario los servicios de salud generan
una gran cantidad de información de manera fragmentada,
debido a que estas instituciones operan de manera aislada
con sus propios sistemas de informacion para distribución de
los datos del paciente atendidos por ellos[1]. Esto ocasiona
que no se pueda intercambiar el historial clínico del paciente
a las demás instituciones, debido a que no se cuentan con los
sistemas interoperables para poder acceder al registro de los
pacientes de manera inmediata para el tratamiento,
seguimiento, control y actuación.
Asimismo, los centros de salud cuentan con la
integración de arquitecturas monolíticas, es decir, estas
aplicaciones utilizan funcionalidades y códigos que están en
un solo proceso. Al contar con las diversas funcionalidades
en un mismo código fuente, generar que la ejecución
comparta recursos como memoria, bases de datos y
archivos, lo que conlleva a una lenta transferencia de
informacion en su proceso generando cuellos de botellas.
Por ende, las instituciones prestadoras de salud buscan
soluciones para apoyar a los médicos a brindar una atención
eficiente, que les permita tener un conocimiento preciso
acerca del historial clínico del paciente.
Por este motivo, se propone la integración de SOA por el
motivo de que permite reutilizar servicios e integrar diversos
sistemas informáticos que cuentan los centros de salud con
el objetivo de compartir datos clínicos para el monitoreo de
los pacientes.
XXX-X-XXXX-XXXX-X/XX/$XX.00 ©20XX IEEE
David Alvarez Segovia
Facultad de Ingeniería de Sistemas e Informática
Universidad Tecnológica del Perú
Lima, Perú
1521421@utp.edu.pe
II. METODOLOGIA
A. Seleccion de la metodogolia
De acuerdo con lo explicado dentro del marco teórico, se
ha tenido como tentativa 3 posibles metodologías que se
adecuan al desarrollo de la investigación. Por lo cual, se
realiza una comparación cualitativa para poder contrastar
aspectos como las principales características, las principales
actividades que aplican cada metodología, el ámbito de
aplicación en el que se puede trabajar así como las
principales ventajas que implican; es así, que se hace uso de
la información que IBM[2] presenta en la metodología RUP,
continuando con la metodología BPM elaborada por
Dumas[3] y por último se toma la información que expone
SCRUM Study[4] sobre la metodología SCRUM.
Para la elección de la metodología se pueden seleccionar
varios criterios para tomar una decisión sobre que
metodología utilizar, sin embargo, para tener una mayor
claridad es necesario tomar puntos de referencia que se
puedan comparar para tener una mejor adecuación a la
investigación. 
TABLA 1: CUADRO COMPARATIVO DE RUP VS SCRUM
Finalmente, luego del análisis y la comparación hecha en
las tablas anteriores, se concluye que RUP es la metodología
que más se ajusta a la actual investigación debido a que es
de aborda proyectos de gran escala, siendo parte de los
criterios de selección la presencia que tienen en internet, los
entregables en base a la documentación ya que la
metodología RUP cuenta con una mejor documentación lo
cual permitirá el desarrollo de la investigación. A pesar de
que la diferencia es minina consideramos en base a
investigaciones del estado del arte seleccionamos la
metodología RUP, ya que es más eficiente en el entorno de
salud que vamos a implementar el proyecto. 

Ilustración 1: Metodologia RUP
III. METODOLOGIA RUP
A. Fase de Inicio
Consiste en lograr la coincidencia entre los involucrados
y hacer cumplir los objetivos establecidos en el ciclo de vida
del proyecto. Esta fase es de suma importancia porque
permite lograr el desarrollo, donde se hallan esenciales
riesgos e incidencias empresariales y condiciones que se
plantean antes de continuar con el proyecto. Las perfecciones
que presenta un sistema existente que comprende actividades
compuesta por flujo y procesos llevado a cabo en forma
diaria en el Centro Hospitalario de Lima, la Fase de Inicio es
reducida, pero se enfoca y asegura que el proyecto resulte
rentable en su desarrollo.
Actividad 1: Modelado de casos de usos
Consiste en documentar los procesos del negocio
identificando las actividades de los casos de uso de negocio.
Permite ofrecer un lenguaje frecuente integrada por
especialistas Analistas de sistemas, Arquitecto de Software y
Diseñador de pruebas de negocios al efectuar los
inconvenientes que comprometen a la organización de la
Salud del Centro Hospitalario de Lima.
Actividad 2: Determinación de los requerimientos del
Sistema
Se fundamenta en la elaboración de los requerimientos
del sistema llevado a cabo por desarrolladores y clientes en
acorde al beneficio final del producto obtenido, es decir las
especificaciones de los casos de uso que se realiza por
medio de diagramas ofrece una especificación textual y
detallada, donde los requerimientos funcionales muestra
características que el usuario identifica y los requerimientos
no funcionales son características que debe responder
internamente el sistema. En tal sentido, los responsables de
la mencionada actividad son integrada por el Analista de
Sistemas y el Diseñador de pruebas. Por medio de los
requerimientos permite identificar con mayor exigencia los
impedimentos y plantear soluciones al sistema de monitoreo
de pacientes del centro hospitalario de Lima.
TABLA 2: REQUERIMIENTOS FUNCIONALES
Actividad 3: Gestión de Riesgo
La importancia de la planificación del riesgo es garantizar
el éxito del proyecto. Por ello, se debe controlar los riesgos
potenciales el cual se debe identificar las posibles amenazas
en todas las fases, mitigar o evitar inconvenientes. El auditor
de Sistemas admite que la gestión de riesgos es de
importancia, porque permite adquirir los objetivos de un
proyecto. 
TABLA 4: LISTA DE RIESGOS
B. Fase de Elaboración
Consiste en establecer un buen soporte en la línea de la
arquitectura del sistema a fin de proveer una base consistente
para realizar mayor trabajo en el diseño e implementación.
Es decir. La fase de elaboración consiste en una serie de
iteraciones que culminan en el hito de la arquitectura del
ciclo de vida.
Actividad 1: Funcionamiento de los procesos actuales (AS
- IS)
Se recolecto información AS IS, de los procesos
existentes del modelado que deben ser aplicadas como
entrevistas o reuniones y descripción de las tareas de esta
forma se ha elaborado cuestionarios para poder comprender
las necesidades de la organización en vista a las
observaciones halladas, asimismo se ha empleado la
herramienta de Software Business Process Management
(Bizagi) para realizar los diagramas de procesos a los
servicios relacionados que evidencian el flujo de trabajo
actual del Centro Hospitalario de Lima, antes de la
implementación del sistema web. En tal sentido, ha
permitido evidenciar la forma tradicional del trabajo que se
ha mantenido en la organización. Procesos que corresponden
a reservas de atenciones médicas, registro de pacientes y
búsqueda de historias clínicas, los mencionados procesos
han sido llevados a cabo de modo manual con la precisión
de realizar cambios a nivel de procesos y reestructurar las
amplitudes de los integrantes de la organización; con el
propósito de contribuir con la mejora de los servicios que se
les brinda a los pacientes.

Ilustración 2: Desarrollo de asignación de reserva de atenciones,
previo a la implementación
Con relación a la figura se especifica la modalidad
característica del desarrollo de asignación de reserva de
atenciones médicas llevado a cabo antes del funcionamiento
del sistema web.
Actividad 1: Modelo lógico de la base datos
La actividad implicar actualizar el modelo lógico de base
de datos con el fin de ya comenzar a desarrollar el software,
para ello fue necesario recolectar información de las fases
anteriores, analizar a los actores e identificar los procesos
para entregar una versión finalizada.
Actividad 2: Interacciones finales
Esta actividad consiste en representar a través de un
diagrama las interacciones del usuario con el propio sistema,
a fin de entender el proceso del servicio que está utilizando.
Actividad 3: Maquetado del sistema
Esta actividad consiste en la estructura de las interfaces
mediante bocetos que será elaborador previo al desarrollo
del software para maquetar el posicionamiento de cada
servicio y dar una prioridad al momento de desarrollar el
sistema. Como prototipo de la Página de inicio, registro de
pacientes, login del usuario, portal administrativo, entre
otros.

Actividad 2: Funcionamiento del diseño de la situación

deseada (TO-BE)
Consiste en lograr en lograr de forma eficaz los nuevos
objetivos de la organización por medio de los diagramas de
procesos TOBE. Es decir, se buscar reconstruir los procesos
utilizando el modelado BPM diagramas han sido elaborados
con la herramienta Bizagi, a fin de demostrar el flujo de
trabajo del Centro Hospitalario de Lima y reevaluar las
acciones del negocio con una mejor perspectiva a futuro.
Donde los mapas de procesos deben estar alineado con la
planificación estratégica de la organización
Ilustración 4: Prototipo principal del medico

D. Fase de Transporte
Tiene como objetivo que el usuario sea independiente,
para ello es necesario implementar el software o producto a
los usuarios finales, realizar pruebas con el fin de desarrollar
nuevas actualizaciones, entregar la documentación final para
que pueda manejarlo el usuario en producción.
Actividad 1: Actualización de la cartera de servicios
TABLA 3: CARTERA DE SERVICIOS

Ilustración 3: Desarrollo de asignación de reserva de atenciones

post implementación del software web

Actividad 3: Modelado del sistema de negocio

En esta fase se centraliza las precisiones del sistema es la
acción del sistema desde la perspectiva del usuario. En el
marco del proceso de la implementación. Es decir, consiste
en determinar acuerdos entre el cliente y los desarrolladores
sobre las limitaciones y eventualidades requisitos que debe
concretar el sistema. Actividad 2: Desarrollo del sistema
C. Fase de Construcción Cuando el medico ingrese al sistema podra observar
Tiene como objetivo de entregar la primera versión información general de la cantidad de pacientes afiliados al
funcional del software que sea aceptable para la entrega al centro de salud, y el promedio de pacientes atendidos
usuario, para ello debe realizar diversas interacciones, durante el mes.
finalizar la base de datos, realizar pruebas de funcionamiento
con el fin de que cuando se entregue el software recibir un
feedback de la primera versión y comenzar a realizar
actualización, con la mira en la siguiente fase.
 Ilustración 5: Pagina principal del medico
Por el lado del paciente, podrá generar citas médicas, y
dentro de la plataforma podrá administrar el historial clínico
de los diversos tratamientos recibidos por el centro de salud.
Ilustración 6: Pagina principal del paciente
RESULTADOS
Tiempo promedio de respuesta del intercambio de
historiales clínicos: Antes de la implementación el promedio
de intercambio clínicos era de 4.90 minutos. Sin embargo,
luego de la implementación que se realizó con respecto al
monitoreo de pacientes se obtuvo un promedio del 3.03
minutos de respuesta de intercambio clínicos, obteniendo una
reducción de 1.87 minutos.
Calidad de registro de las historias clínicas: Antes de
implementar el software de monitoreo de pacientes el
promedio de registros de historias clínicas era de 85.56% en
un mes en relación con la calidad de historias clínicas
auditadas. Sin embargo, luego de la implementación paso a
mejorar la calidad en un promedio del 93.22% entorno a un
mes obteniendo un incremento del 7.56%.
El resultado obtenido demuestra que el 34.1% de los
encuestados respondieron que están muy de acuerdo con la
importancia de los historiales clínicos en relación con el
tratamiento de la salud, con el fin de brinda un buen servicio
al paciente.
Contrastación de las hipótesis
HG1: El software web basado en Arquitectura orientada a
servicios influye de manera significativa en el monitoreo de
pacientes afiliados en un Centro Hospitalario de Lima
HG0: El software web basado en Arquitectura orientada a
servicios no influye de manera significativa en el monitoreo
de pacientes afiliados en un Centro Hospitalario de Lima
TABLA 4: CONSTRATACIÓN DE LA HIPOTESIS GENERAL
El nivel de significancia es de 0.0 es menor a 0.01, se
rechaza la hipótesis general nula y se acepta la hipótesis
general alternativa. El coeficiente de Rho Spearman es 0.526,
existe una correlación positiva moderada
CONCLUSIONES
Existe una correlación positiva moderada entre las dos
variables, en base a ello el software web basado en
Arquitectura orientada a servicios influye de manera
significativa en el monitoreo de pacientes afiliados en un
Centro Hospitalario de Lima
Existe una correlación positiva moderada entre la variable
independiente y la dimensión “Vigilancia”, en base a ello el
software web basado en Arquitectura orientada a servicios
influye de manera significativa en el seguimiento de
pacientes afiliados en un Centro Hospitalario de Lima
Existe una correlación positiva alta entre la variable
independiente y la dimensión “Control”, en base a ello el
software web basado en Arquitectura orientada a servicios
influye de manera significativa en el seguimiento de
pacientes afiliados en un Centro Hospitalario de Lima
Existe una correlación positiva moderada entre la variable
independiente y la dimensión “Seguimiento”, en base a ello
el software web basado en Arquitectura orientada a servicios
influye de manera significativa en el seguimiento de
pacientes afiliados en un Centro Hospitalario de Lima
Existe una correlación positiva moderada entre la variable
independiente y la dimensión “Actuación”, en base a ello el
software web basado en Arquitectura orientada a servicios
influye de manera significativa en el seguimiento de
pacientes afiliados en un Centro Hospitalario de Lima
REFERENCES
[1] Arévalo, J. G., Gonzales, A., & Arévalo, L. (2019). Model for the
interoperability between health service providers (IPS), based on the
electronic clinical information standard (HL7) and architecture to
design and develop distributed systems (SOA). IOP Conference
Series: Materials Science and Engineering, 519.
[2] IBM(2007) IBM Rational Unified Process for System z Cécile Péraire
RUP for System z includes a succinct end-to-end process for z
practitioners RUP for System z.
[3] Dumas, M., Marcello, ·, Rosa, L., Mendling, J., & Reijers, H. A.
(2018). Fundamentals of Business Process Management.
[4] SCRUMstudy. (2013). A guide to the Scrum Body of knowledge
(SBOK Guide).