Universidad Autónoma Juan Misael Saracho

FACULTAD DE CIENCIAS Y TECNOLOGIA

DEPARTAMENTO DE INFORMATICA Y SISTEMAS
CARRERA DE INGENIERIA INFORMATICA

Mejoramiento de la Administración del Laboratorio Clínico del

Hospital Santa María, aplicando las TIC

GESTIÓN 2019

IDENTIFICACION DEL PROYECTO

Título del Proyecto Mejoramiento de la Administración del Laboratorio Clínico del

Hospital Santa María, aplicando las TIC
Nombre del Postulante <Nombre completo del postulante>

Celular <Número de celular de contacto>

Carrera/Unidad Departamento de Informática y Sistemas

Facultad Ciencias y Tecnología

Institución/Centro HOSPITAL SANTA MARÍA

Cooperante

Duración del Proyecto 8 meses

Área/línea de investigación DESARROLLO DE SOFTWARE

priorizada

Tarija – Bolivia
 INDICE

Titulo/subtitulo……………………………………………………………………………. #Pág.
1. Introducción 3
2. Descripción del Proyecto
2.1. Antecedentes 3
2.2. Justificación del Proyecto 5
2.3. Planteamiento del problema 6
2.4. Objetivos
2.4.1. Objetivo General 6
2.4.2. Objetivos Específicos 6
2.5. Metodología de Desarrollo
2.6. Resultados esperados 10
2.7. Beneficiarios del Proyecto
2.7.1. Beneficiarios Directos 10
2.7.2. Beneficiarios Indirectos 10

3. Cronograma de actividades 11
4. Referencias bibliográficas 14
5. Presupuesto general 14
 3

1. Introducción
La gestión adecuada de un Laboratorio Clínico es muy importante para brindar calidad y confianza a los
pacientes. El buen flujo de trabajo, la buena comunicación entre el personal, la exactitud de la información
y la oportunidad son vitales para garantizar la buena salud en los pacientes.

En el Laboratorio del Hospital Santa María existen las siguientes áreas: Hematología, Coagulación,
Inmunología, Endocrinología, Microbiología, Química Clínica, Coprología y Orina. Cada una de las áreas,
realiza una lista de análisis específicos que más adelante serán detallados. El Laboratorio realiza análisis a
pacientes externos o ambulatorios e internos.
Los pacientes externos o ambulatorios deben sacar turno para ser atendidos. El volumen de análisis
realizados por día en promedio asciende a 300, cifra que demuestra la importancia de contar con una
administración adecuada para responder a la demanda de una manera satisfactoria, así como a los médicos
y pacientes que interactúan con esta área. La estructura orgánica del Laboratorio está conformada por un
Jefe, Subjefes de cada una de las áreas mencionadas arriba, 3 técnicos por cada área, una secretaria, un
Jefe de Almacenes y un portero. Todos ellos dependen del Director del hospital.
El presente proyecto tiene como objetivo mejorar la administración del Laboratorio desde el punto de vista
administrativo y contempla los siguientes elementos:
Solicitud de exámenes, recolección de muestras y transporte, recepción de muestras, procedimientos pre
analíticos, proceso de muestras, reporte y validación de resultados, impresión de muestras, entrega de
resultados y estadísticas.

El presente proyecto de investigación aplicada, está centrado en el desarrollo de un Sistema Informático

para el Laboratorio del Hospital Santa María, aplicando la metodología SCRUM, la norma IEEE830 con el
detalle de requerimientos funcionales y no funcionales para la Especificación de Requerimientos de
Software, un Manual de funciones y un Manual de Procedimientos para garantizar calidad y sostenibilidad.

2. Descripción del Proyecto

2.1 Antecedentes
La informática ha sido una herramienta de gestión determinante en la calidad de la salud. Existen innumerables
sistemas de apoyo a la medicina, esto dio lugar al desarrollo de la Informática Medica y a la Telemedicina
entre otras disciplinas. Desde el punto de vista de los análisis clínicos, existen equipos y maquinarias
sofisticadas que permiten realizar los análisis de manera ágil, segura y un grado alto de confiabilidad, así
mismo la introducción de sistemas de gestión de laboratorios que involucren el pre análisis, análisis y gestión
de los mismos están disponibles en el mercado. La calidad y capacidad de los equipos, técnicos que operan
estos sistemas, estrategias organizativas, calibración de equipos y administración del flujo de información,
aportan la calidad en esta área.

No se tienen registros oficiales de sistemas informáticos aplicados al área de Análisis de Laboratorios en el

sistema nacional de salud, sin embargo cabe destacar el Sistema Nacional de Información en Salud - Vigilancia
Epidemiológica, en esta unidad se provee al país y al sector salud de datos e información para la gerencia y
la vigilancia epidemiológica que permitan tomar decisiones adecuadas y oportunas en la planificación,
ejecución y evaluación de políticas públicas en el ámbito de la salud. Proporciona información sectorial y
extrasectorial de los recursos existentes en la red de servicios en los diferentes niveles del sistema de salud,
que permita el análisis contextual de las condicionantes y determinantes de la situación de salud. Los sistemas
de información como parte de sus procedimientos, contemplan el análisis y utilización de la información. En el
caso del Sector Salud y tomando en cuenta los ajustes permanentes y la toma de decisiones en los diferentes
niveles, es necesario dotar al personal de una metodología de análisis e interpretación de la información, la
misma que sin entrar en un plano de rigidez, contemple la estandarización de ciertos aspectos que permitan
su comparabilidad y medición. (1)

En nuestro medio, se han visitado laboratorios que en su mayoría cuentan con uno de los siguientes sistemas:
 4

AREA-LIMS Software de gestión integral de laboratorios de análisis clínicos:

AREA-LIMS (A-LIMS) es un sistema de gestión integral de laboratorios de análisis clínicos privados
(Laboratory Information Management System) formado por distintos módulos en red de área local y en entorno
web. El núcleo principal de A-LIMS permite gestionar las muestras de análisis clínicos desde la entrada de la
petición de servicio hasta la publicación o entrega de los resultados. Complementando el núcleo principal, A-
LIMS dispone de una serie de módulos adicionales que facilitan otras tareas como el módulo de facturación,
las conexiones con analizadores, el módulo de intercambio de datos con sistemas externos o con otros LIMS,
el módulo de publicación de informes de resultados en web GateLab y el módulo de estadísticas.

Fig. 1: Software AREA-LIMS – Diagrama general de conexiones y enlaces

PYMELAB SOFTWARE BIOQUIMICO:

PYMELAB SOFTWARE BIOQUIMICO es un software de administración indispensable para todo

laboratorio cuyos instrumentos de análisis están destinados a la bioquímica en general. Los estudios e
informes relacionados con aspectos como citología, hormonas y orina son creables y gestionables mediante
dicho programa.

Cualquier laboratorio de bioquímica suele tratar diariamente con multitud de documentos, desde las fichas
de pacientes hasta la evolución gráfica de los mismos. Es por ello que resulta esencial tenerlos bien
organizados con PYMELAB SOFTWARE BIOQUIMICO, un sistema que también te permite crearlos
introduciendo los datos de cada campo informativo: edad, médico, diagnóstico, tratamiento, etcétera.

Haciendo uso del programa se puede elaborar las facturas teniendo en cuenta los diversos aspectos de la
visita del paciente en cuestión.
 5

La gran cantidad de información que se genera en las organizaciones de salud, y la necesidad de agregarla,
compartirla y facilitar su acceso para conseguir una asistencia de calidad, representa un reto alcanzable hoy
día con las herramientas adecuadas. La disponibilidad de información bien estructurada, compartida y
agregada, es el punto de partida esencial en todos los procesos de gestión y reorganización de procesos
clínicos y administrativos, con miras a implementar acciones de mejora continua de la calidad del servicio.
Dedalus Healthcare Suite® (DHS) resuelve estas necesidades mediante una solución integral que incluye
todos los sistemas de información necesarios para una gestión global del proceso asistencial, clínico y
administrativo, y para que la gestión de la información de todas las áreas de la organización de salud, implique
a todos los actores. De este modo, garantizamos la continuidad del proceso asistencial. Incluye: • HIS y HCE,
Primaria y Especializada • Gestión de Farmacia • Gestión del área Quirúrgica • Gestión integral de Programas
de Prevención • Gestión de Urgencias • Sistema ERP • Movilidad, sistemas multidispositivo.

2.2 Justificación del Proyecto

El proceso de realización de Análisis en el Laboratorio del Hospital Virgen María se compone de una lista de
actividades que se desarrollan de manera ordenada y en diferentes secciones del Laboratorio. Los flujos de
información y el registro de operaciones están definidos, sin embargo es importante eliminar errores, datos
duplicados, información incompleta, retardo en algunas actividades e inexistencia de información de respaldo.
En algunas situaciones, los turnos otorgados tienen errores, lo que ocasiona que los pacientes no sean
atendidos. También ha sucedido en algunas oportunidades que la recepción de muestras tienen errores, lo
que ocasiona que el paciente no sea atendido o la obtención de resultados se demora.
La utilización de materiales y reactivos no se registra adecuadamente, esto ocasiona que dichos materiales
no estén disponibles oportunamente y la demora en la realización del análisis y posterior entrega de resultados.
El registro de entrega de resultados (en pacientes ambulatorios e internos) no está actualizado, esto ocasiona
retardo en la entrega de Resultados o en algunas ocasiones extravío del Resultado.
El Registro de resultados de análisis en ocasiones presenta errores debido a la alta volumen de información
a procesar.
Las estadísticas están desactualizadas debido a que en ocasiones el registro de resultados tiene errores, es
incompleto y los resultados no están correctamente registrados. No se cuenta con información estadística
oportuna y completa.
Debido al alto volumen de información a procesar, el inventario está desactualizado ya que no siempre se
registran los materiales y reactivos que se utilizan en la realización del análisis.
No existe un historial de análisis realizados por paciente debido a que el registro se realiza de manera manual
y no está clasificado.

Justificación Tecnológica:
Existe la tecnología necesaria para resolver el problema descrito, aplicaremos una red de computadoras que
conectara a todas las estaciones de trabajo del Laboratorio. El sistema será desarrollado bajo tecnología Web.
Contaremos con un sistema integrado y distribuido con alta seguridad y velocidad de respuesta, será confiable
y robusto. Cumplirá los requerimientos que se mencionan en la norma ERS IEEE830 del anexo. Actualmente
el Hospital cuenta con un dominio, servidores, espacio suficiente, seguridad y administradores del Centro de
Cómputos del Hospital Santa María lo que facilitan la implementación de nuestra propuesta.

Justificación Económica
Además de mejorar la calidad e imagen del Hospital Virgen María, se prevé un ahorro significativo al eliminar
análisis duplicados, lo que reduce el tiempo del personal, ahorro de materiales, reactivos y tiempo de entrega
de resultados. El financiamiento para desarrollo del sistema está garantizado puesto que está registrado en el
POA de la institución y se enmarca en el Plan de Desarrollo Institucional, capítulo II: Modernización de la
Gestión Administrativa del Hospital, Objetivo 6: desarrollo de un sistema Informático para el laboratorio de
análisis clínico.
 6

Justificación Social:
El presente proyecto es de impacto social, aproximadamente 500 pacientes por mes se verán beneficiados y
podrán contar con atención médica de calidad.

2.3 Planteamiento del problema

Los constantes errores que se tiene en el registro, el tiempo que se tarda para realizar informes gerenciales,
han dado lugar a plantear el problema como:

“La administración del Laboratorio del Hospital Santa María no es adecuada”

2.4 Objetivos

2.4.1 Objetivo General

Administración adecuada del Laboratorio del Hospital Santa María aplicando las TIC

2.4.2 Objetivos Específicos

1. Desarrollar el Sistema Informático SYSLAB aplicando la Metodología RUP
2. Diseñar procedimientos a seguir en el Laboratorio del Hospital Santa María
3. Diseñar las funciones dl personal del Laboratorio
4. Realizar capacitación en el uso del Sistema Informático LABSYS

2.5 Metodología de desarrollo del proyecto (detallar las etapas, métodos, técnicas y otros)

El proyecto está compuesto por los siguientes elementos: desarrollo de software, elaboración de Manual de
Funciones y elaboración de un Manual de procedimientos que garantice la calidad del servicio del Laboratorio.
Para el Desarrollo del Sistema Informático, se realizará la especificación de requerimientos de software
tomando en cuenta los funcionales y no funcionales según la norma IEEE830. Para garantizar la calidad del
producto se aplicará la norma RAMAL en todas sus dimensiones. Para el proceso de desarrollo del software,
se aplicará el paradigma de Prototipos tomando como base la metodología SCRUM, (2) dado que permite un
desarrollo ágil y altamente participativo. La etapa de pruebas se desarrollará como parte de una actividad de
Garantía de Calidad del Sistema así como la elaboración de manuales de usuario, de operación e
implementación.

SCRUM
Scrum se ha fundado sobre una teoría empírica de control de procesos, que también se conoce como
empirismo. Lo que afirma esta teoría es que el conocimiento se basa en la toma de decisiones y en la
experiencia de los factores conocidos.
Por tanto, Scrum busca cómo optimizar la predictibilidad y controlar el riesgo utilizando un método Iterativo e
Incremental. Para que esto suceda, hay tres pilares que se deben implementar. Estos son la Transparencia,
la Inspección y la Adaptación.

Rol: Dueño del Producto

El Dueño del Producto es un único individuo responsable por lograr el mayor valor posible del producto para
una fecha deseada. Esto lo logra gestionando el flujo del trabajo del equipo, seleccionando y refinando los
elementos del Backlog del Producto. El Dueño del Producto mantiene el Backlog del Producto y se asegura
que todos conozcan lo que está ahí y las prioridades. El Dueño del Producto puede recibir ayuda de otras
personas, pero debe ser una sola persona.
El Dueño del Producto, como elige en qué va a trabajar el Equipo de Desarrollo a continuación, es quien toma
las decisiones de alcance vs. fechas para lograr el mejor producto posible.
 7

Rol: Miembro del Equipo de Desarrollo

El Equipo de Desarrollo está compuesto de profesionales que realizan el trabajo de entregar Incrementos del
Producto. Se auto-organizan para lograr este trabajo. Se espera que los miembros del Equipo de Desarrollo
estén disponibles durante todo el proyecto a tiempo completo.

Rol: ScrumMaster
El ScrumMaster es un "líder servicial", que ayuda al resto del Equipo de Scrum a seguir el proceso. El
ScrumMaster necesita tener una buena comprensión del marco de Scrum, y debe tener la habilidad de
entrenar a otras personas en los detalles de Scrum.

Artefacto: Backlog del Producto

El Backlog del producto es un artefacto esencial en Scrum. El Backlog del Producto es una lista ordenada de
ideas para el producto, en el orden que esperamos deban terminarse. Es un lugar único en donde fluyen todos
los requerimientos. Esto significa que todo el trabajo que hace el Equipo de Desarrollo proviene del Backlog
del Producto. Cada idea, cada característica, cada mejora, cada bug, cada requerimiento de documentación -
todo el trabajo que sea hace - está derivado de algún elemento del Backlog del Producto. Cada elemento del
Backlog del Producto incluye una descripción y una estimación.

Actividad: Refinamiento del Backlog del Producto

Como los elementos del Backlog del Producto suelen ser grandes y generales, y como las ideas van y vienen
y las prioridades cambian, el Refinamiento del Backlog del Producto es una actividad que ocurre durante todo
el proyecto de Scrum. Esta actividad incluye (pero no está limitada a):
• mantener ordenado el Backlog del Producto
• eliminar ideas que ya no son importantes
• agregar o promover elementos que surgen o se vuelven importantes
• dividir elementos en elementos más pequeños
• unir elementos en elementos más grandes
• estimar elementos

Actividad: Planificación del Sprint

Cada Sprint comienza con una reunión acotada en tiempo llamada Planificación del Sprint. En esta reunión el
Equipo de Scrum colabora para seleccionar y comprender el trabajo a realizar en el Sprint que comienza.
En Scrum, la reunión de Planificación del Sprint tiene 2 partes:
1. Determinar qué trabajo se completará en el Sprint.
2. Determinar cómo se realizará este trabajo.

Parte 1: ¿qué trabajo se realizará?

En la primer parte de la reunión, el Dueño del Producto le presenta al Equipo de Desarrollo los elementos
ordenados del Backlog del Producto. Para decidir cuántos elementos se realizarán, el Equipo de Desarrollo
considera el estado actual del Incremento del Producto, el rendimiento anterior del equipo, la capacidad actual
del equipo, y el Backlog de Producto ordenado. El Equipo de Desarrollo es el único que decide cuánto trabajo
tomarán. Ni el Dueño del Producto ni ninguna otra agencia pueden empujarle más trabajo al Equipo de
Desarrollo.
A menudo, pero no siempre, el Sprint tiene un objetivo, que se llama Objetivo del Sprint. Esta es una práctica
recomendable que ayuda a enfocarse en la esencia de lo que necesita hacerse, y quita foco de los detalles
que pueden no ser tan importantes.

Parte 2: ¿cómo se realizará el trabajo?

En la segunda parte de la reunión, el Equipo de Desarrollo colabora para decidir cómo producir el próximo
Incremento del Producto de acuerdo con la Definición de Terminado actual. Realizan el diseño y la planificación
suficientes para estar seguros de poder terminar el trabajo durante el Sprint. El trabajo a realizar durante los
primeros días se divide en unidades más pequeñas de 1 día o menos. El trabajo a realizar más trade puede
dejarse en unidades más grandes para separar después.
Así como el Dueño del Producto es responsable por decidir qué se va a hacer, el Equipo de Desarrollo es el
responsable en determinar cómo realizar el trabajo.
El Dueño del Producto puede permanecer durante esta parte de la reunión, para responder preguntas y dudas.
En cualquier caso, siempre necesita estar disponible para el Equipo de Desarrollo.
 8

Resultado de la Planificación del Sprint

La Planificación del Sprint concluye cuando el Equipo de Scrum llega a comprender la cantidad y complejidad
de lo que se logrará durante el Sprint, y lo que espera poder terminar (dentro de algún margen racional de
circunstancias). El Equipo de Desarrollo estima la cantidad de trabajo que podrá completar y se compromete
a completarlo.
Para resumir, durante la reunión de Planificación del Sprint, el Equipo de Desarrollo:
• considera y discute los elementos del Backlog del Producto con el Dueño del Producto
• se asegura de comprender los elementos del Backlog del Producto
• selecciona una cantidad de elementos que estiman poder terminar,
• y crean un plan lo suficientemente detallado para asegurarse que puedan completar estos elementos.
La lista resultante de estos elementos a realizar es el "Backlog del Sprint".

Artefacto: Backlog del Sprint

El Backlog del Sprint es la lista de los elementos del Backlog del Producto, elegidos para ser desarrollador en
el Sprint actual, junto con el plan del equipo para lograr el trabajo. Refleja la estimación del equipo del trabajo
que puede completarse.
Con el Backlog del Sprint determinado, el Sprint comienza, y el Equipo de Desarrollo crea el nuevo Incremento
del Producto definido por el Backlog del Sprint.

Desarrollo
Durante el Sprint, el Equipo de Desarrollo se auto-gestiona para producir un Incremento del Producto de
acuerdo al Backlog del Sprint, el cual fue determinado durante la Planificación del Sprint. La auto-gestión
significa que el equipo es responsable de producir el Incremento del Producto conforme a los estándares de
la organización, conforme a la Definición de Terminado, y que el Equipo de Desarrollo determina cómo lograr
esto.

Artefacto: Incremento del Producto

El artefacto más importante de Scrum es el Incremento del Producto. Cada Sprint produce un Incremento del
Producto. El Incremento del Producto debe tener la suficiente calidad para ser entregado a los usuarios finales.
El Incremento del Producto tiene que cumplir con la Definición de Terminado del Equipo de Scrum, y cada
componente debe ser aceptado por el Dueño del Producto.

Indicadores adicionales visibles de avance

Scrum requiere que transparencia dentro y fuera del equipo. Aunque el Incremento del Producto es la forma
más importante de crear transparencia, el Equipo de Scrum creará cualquier otro artefacto que necesita para
asegurarse que se comprenda el estado del proyecto. Los gráficos de burndown y los tableros de tareas son
artefactos adicionales muy comunes.
Acuerdo: Definición de Terminado
Cuando se entrega el Incremento del Producto, necesita estar "terminado" según lo acordado que signifique
"terminado". Esta definición es diferente para cada Equipo de Scrum, y a medida que madura el equipo, la
Definición de Terminado se expandirá para ser más precisa.
La Definición de Terminado siempre debe incluir la noción de que el Incremento del Producto tiene la calidad
necesaria para que sea productivo: el Dueño del Producto debería poder elegirlo para liberarlo
inmediatamente. El Incremento del Producto incluye la funcionalidad de todos los Incrementos del Producto
anteriores, y está completamente testeado de manera que todos los elementos del Backlog del Producto
continúan funcionando juntos.

Actividad: Scrum Diario

El Equipo de Desarrollo es auto-gestionado. El Equipo de Desarrollo utiliza la reunión de Scrum Diario para
asegurarse que están en el camino indicado para lograr el Objetivo del Sprint. La reunión ocurre a la misma
hora y en el mismo lugar, todos los días. Cada miembro del Equipo de Desarrollo responde 3 preguntas:
• ¿Qué logré desde nuestro último Scrum Diario?
• ¿Qué espero lograr entre hoy y el próximo Scrum Diario?
• ¿Qué está impidiendo mi avance?
 9

Pueden ocurrir algunas preguntas breves para clarificar, pero no hay discusiones de ningún tema durante el
Scrum Diario. Sin embargo, muchos equipos se juntan justo después del Scrum Diario para trabajar en
cualquier tema que hubiera surgido.
El Scrum Diario no es un reporte para la gerencia, ni para el Dueño del Producto, ni para el ScrumMaster. Es
una reunión de comunicación dentro del Equipo de Desarrollo, para asegurar que están todos sincronizados.
Sólo los miembros del Equipo de Scrum, incluyendo el ScrumMaster y el Dueño del Producto, pueden hablar
durante esta reunión. Otras partes interesadas pueden asistir a escuchar. Basados en lo que salga durante la
reunión, el Equipo de Desarrollo reorganiza el trabajo que necesita completarse para alcanzar el Objetivo del
Sprint.
El Scrum Diario es clave para Scrum, lleva a la transparencia, genera confianza, y brinda mejor rendimiento.
Logra que los problemas se descubran rápido, y promueve la auto-gestión del equipo y la confianza. Todas
las reuniones de Scrum están acotadas en tiempo. La duración recomendada para el Scrum Diario es de no
más de 15 minutos.

Actividad: Demo del Sprint

Al final del Sprint, el Equipo de Scrum y los interesados revisan lo producido en el Sprint. Todas las reuniones
de Scrum son acotadas en tiempo. La duración recomendada para la Demo Sprint es de 1 hora por semana
de duración del Sprint.
El punto central de la discusión es el Incremento de Producto terminado durante el Sprint. Dado que los
interesados son aquellos que están "involucrados" en los resultados, generalmente resulta útil que participen
de esta reunión. Es una reunión informal, para compartir en dónde estamos y colaborar sobre cómo podemos
avanzar. Todos pueden participar de la Demo del Sprint. Naturalmente, el Dueño del Producto es quien toma
la decisión final sobre el futuro, y actualiza el Backlog del Producto de manera apropiada.
Los equipos encuentran su propia manera de hacer una Demo del Sprint. Es común hacer una demostración
del Incremento del Producto. El grupo a menudo discute lo que observaron durante el Sprint, y las ideas del
producto que aparecen. Discuten el Backlog del Producto y hablan sobre las fechas posibles para terminar, y
lo que puede hacerse sobre esas fechas.
La Demo del Sprint les brinda a todos los presentes una forma de conocer el Incremento del Producto vigente.
También, es común actualizar el Backlog del Producto como parte de la Demo del Sprint.

Actividad: Retrospectiva del Sprint

Al final de cada Sprint, el Equipo de Scrum se junta para la Retrospectiva. El propósito es revisar cómo fueron
las cosas con respecto al proceso, a las relaciones entre las personas, y a las herramientas. El equipo identifica
lo que salió bien y lo que no salió tan bien, e identifica mejoras posibles. Arman un plan para mejorar las cosas
en el futuro. Todas las reuniones de Scrum están acotadas en tiempo. La duración recomendada para la
Retrospectiva del Sprint es de 1 hora por semana de duración del Sprint.
El Equipo de Scrum mejora su propio proceso, siempre dentro del marco de trabajo de Scrum.

Y volver a repetir
El ciclo de Scrum se repite a partir de aquí, cada Sprint.
Para resumir, los miembros del Equipo de Scrum (el Dueño del Producto, el Equipo de Desarrollo, y el
ScrumMaster) colaboran para crear una serie de Incrementos del Producto, durante intervalos cortos de
duración fija, llamados Sprints. Cada incremento cumple con el criterio de aceptación del Dueño del Producto
y con la Definición de Terminado compartida por el equipo. Trabajan a partir de un Backlog del Producto. En
cada Sprint, comienzan con la Planificación del Sprint para generar el Backlog del Sprint, un plan para el Sprint.
Se auto-gestionan para realizar el Desarrollo, usando la reunión de Scrum Diario para producir el mejor
Incremento de Producto posible. Realizan un Refinamiento del Backlog del Producto para prepararse para la
próxima reunión de Planificación del Sprint. Terminan el Sprint con una Demo del Sprint y con una
Retrospectiva, revisando el producto y sus procesos.

Se realizará una capacitación al personal del Laboratorio para el uso del sistema informático SYSLAB y otra
para la aplicación y cumplimiento de los Manuales de Funciones y Procedimientos.
El desarrollo del Manual de Funciones y otro de Procedimientos, se realizará en base a la normativa vigente,
normas de calidad específicas para laboratorios siguiendo modelos estándares para la elaboración de dichos
manuales y flujogramas.
 10

2.6. Resultados esperados

1. Sistema Informático LABSYS: el sistema permitirá una gestión adecuada en los procesos del
laboratorio relativos a:
CONTROL DE PROCESO ADMINISTRATIVO
Control de Reservas y Turnos
Kardex de pacientes con:
Registro de análisis clínicos realizados de acuerdo a normativa vigente
Unidad de Salud y médico requirente de cada análisis practicado
Técnico responsable de cada análisis practicado

GENERADOR ESTADISTICO
Cuadros estadísticos por tipo de análisis practicado, por periodos de tiempo incorporando un
diagrama.
Cuadros estadísticos por criterios clínicos de un cierto tipo de análisis, por edades y tiempos,
incorporando un diagrama.

CONSULTA POR WEB

Los clientes registrados y autenticados, podrán revisar sus análisis clínicos practicados vía web.

2. Manual de Funciones en donde se identificaran las funciones, actividades y responsabilidades, de

cada uno de los puestos de trabajo en el Laboratorio.
3. Manual de Procedimientos, se especificaran los pasos a seguir para lograr cumplir cada uno de los
procesos asociados a la realización de los análisis, detallando datos de entra, procesamiento y salidas.
4. Capacitación en el uso del Sistema Informático, se realizará la capacitación a los usuarios del sistema
en distintos roles (secretaria, jefe de sección, jefe de laboratorio, encargado de almacenes, encargado
de estadísticas, etc), los métodos y medios de enseñanza serán laboratorio de computación, guías de
laboratorio y demostraciones prácticas.
5. Capacitación en la aplicación de Manual de Funciones y Manual de Procedimientos. Se realizarán las
capacitaciones utilizando casos prácticos del Laboratorio. Las capacitaciones serán con la
participación de todo el personal y haciendo énfasis en los estándares de calidad a cumplir.

2.7 Beneficiarios

2.7.1 Beneficiarios Directos

Los beneficiarios Directos son los pacientes ambulatorios e internos del Hospital Santa María que
ascienden a un número de 300 por mes. El presente proyecto, les brinda la oportunidad de mejorar la
calidad del servicio de Laboratorio que reciben.

2.7.2 Beneficiarios indirectos

Los beneficiarios indirectos son los Médicos que reciben resultados oportunos y de calidad, la sección
de la Administración del Hospital, que pueden mejorar y optimizar procedimientos, reducir costos en
la realización del Laboratorio, la sección de Estadísticas, ya que las estadísticas son oportunas y
correctas, el Director del Hospital que puede garantizar una mejora en los diagnósticos y tratamientos
que realiza el personal médico del Hospital. La población en general se encuentra beneficiado al
contar con un servicio de salud mejorado.
 11

3. Cronograma de Actividades

Fecha Fecha
Nº Actividad Nº días M1 M2 M3 M4 M5 M6 M7 M8
inicio Finaliz.
1 Desarrollo del Sistema LABSYS
(análisis, diseño y programación)
1.1 Sprint 1 :

1. Reunión para la
planificación del Sprint.
2. Scrum diario. Trabajo de
desarrollo durante el Sprint.
3. Revisión del Sprint.
4. Retrospectiva del proyecto.
5. Retrospectiva del Proyecto

1.2 Sprint 2 :

1. Reunión para la
planificación del Sprint..
2. Scrum diario. Trabajo de
desarrollo durante el Sprint.
3. Revisión del Sprint.
4. Retrospectiva del proyecto.
5. Retrospectiva del Proyecto

1.3 Sprint 3 :

1. Reunión para la
planificación del Sprint..
2. Scrum diario. Trabajo de
desarrollo durante el Sprint.
3. Revisión del Sprint.
 12

4. Retrospectiva del proyecto.

5. Retrospectiva del Proyecto

2. Desarrollo del Manual de

Funciones
2.1 Identificación de las funciones
2.2 Identificación de las actividades
2.3 Identificación de las
responsabilidades
2.4 Identificación de los responsables
3 Desarrollo del Manual de
Procedimientos
3.1 Identificación de los
procedimientos
3.2 Identificación de las etapas de
cada procedimiento
3.3 Identificación de responsables del
procedimiento
3.4 Diseño de flujogramas
4 Capacitación
4.1 Diseño de material didáctico
4.2 Diseño de Guías de Laboratorio
4.3 Diseño del Contenido
4.4 Cronograma de desarrollo de
clases
4.5 Desarrollo de la Capacitación
5 Capacitación en Procedimientos y
Funciones
5.1 Diseño de Material Didáctico
Procedimientos
5.2 Diseño de Material Didáctico
Funciones
5.3 Plan de Clases Funciones
5.4 Plan de Clase Procedimientos
 13

5.5 Desarrollo Capacitación

Procedimientos
5.6 Desarrollo Capacitación
Funciones
 14

4. Referencias bibliográficas

(1) 2015 Ministerio de Salud SNIS VE Estado Plurinacional de Bolivia

https://snis.minsalud.gob.bo/software
(2) SINNAPS Metodología SCRUM https://www.sinnaps.com/blog-gestion-
proyectos/metodologia-scrum
(3) Elaboración del Manual de Elaboración y Funciones. Anexo I al IX Modelo de Manual
de Organización y Funciones http://bvs.minsa.gob.pe/local/MINSA/1760-2.pdf
(4) Diagrama de Flujo. Wikipedia. https://es.wikipedia.org/wiki/Diagrama_de_flujo
(5) EERS IEEE830 http://zeus.inf.ucv.cl/~bcrawford/AULA_ICI_3242/ERS_IEEE830.pdf
(6) Norma Ramal – Requisitos de la Calidad para Sistemas Informáticos y Productos de
Software La Habana - CubaSub Comité 7. Ingeniería de Software. La Habana Cuba. 2
de Febrero de 2017.
http://subcomite7.cubava.cu/2017/02/10/norma-ramal-requisitos-de-la-calidad-para-
sistemas-informaticos-y-productos-de-software/#.WudiF--FPct

5. Presupuesto general
(completar de acuerdo a su caso)

Nº RUBROS Aporte Otro Aporte TOTAL

Universidad (Bs)
1 COMPONENTE CAPACITACION, 1,000.-
ASISTENCIA TECNICA Y
ORGANIZACIÓN
Sub total componente 1,000.-
2 COMPONENTE ADMINISTRACION 1,000.-
Sub total componente 1,000.-
3 COMPONENTE CONSULTORIA 28,000.-
(Estudios. Investigación y
Construcciones)
Sub total componente 28,000.-
4 COMPONENTE INSUMOS (Materiales y 2,000.-
Suministros)
Sub total componente 2,000.-
5 COMPONENTE CONSULTORIA 3,500.-
EQUIPAMIENTO (Maquinaria, Equipo y
Vehículos)
Sub total componente 3,500.-
6 COMPONENTE OTROS ACTIVOS
REALES
Sub total rubro
35,500.-
TOTAL