sistema de gestión tecnologica hospitalaria v 1.0 - Computer Vision ...

Instituto Superior Politécnico “José Antonio Echeverría”
Centro de Bioingeniería
SISTEMA DE GESTIÓN TECNOLOGICA HOSPITALARIA
V 1.0
Autores:
Jose Alain Senra Gutiérrez
Elier Broche Cristo
Tutores:
Ing. María Caridad Sanchez Villar
Ing. MSc. Antonio Miguel Cruz
1999-2000
1

RESUMEN
En el presente trabajo se expone el análisis, el diseño y la programación de tres de los módulos que integran
un sistema de Gestión Tecnológica Hospitalaria para el equipamiento Biomédico.
El Sistema de Gestión Tecnológica Asistido por Computadoras en su versión 1.0. se prevé que se encuentre
insertado en un Sistema de Información Hospitalaria (HIS), siguiendo la filosofía de la norma internacional
CEN/TC 251 12967-1 propuesto por la Comunidad Económica Europea y que pueda ofrecer sus servicios a
un hospital o a un Sistema Intra-Hospitalario a través de una Red de Area Local (LAN) o una Red de Area
Global WAN. Los módulos del sistema propuesto siguen la filosofía cliente/servidor. Con la creación,
actualización y mantenimiento de sus bases de datos se sentarán las bases para la creación de Sistemas
Expertos con el objetivo de ofrecer servicios de Diagnóstico Remoto (DR) a todas las Instituciones
Hospitalarias de cualquier país. Se prevé además que este sistema se encuentre instalado, en un futuro no
lejano, en la Red Nacional de Salud INFOMED y sea utilizado por la entidad Electromedicina Nacional, que
ofrece sus servicios a todos los hospitales de CUBA.
Los módulos desarrollados son los siguientes.
SMACOR (Sistema de Mantenimiento Asistido por Computadoras orientado a riesgos, en su versión 4.0))
SGA (Sistema de gestión de Almacenes ).
SADTEC (Sistema de adquisición de nuevas tecnologías biomédicas asistido por computadoras y control de
contratos de servicios).
La ventaja principal que trae el desarrollo de estos módulos es que una vez concluidos e instalados en la red
nacional de salud, los directivos y especialistas técnicos del Ministerio de Salud Pública tendrán a su
disposición un arsenal de información, con el objetivo de implementar, comparar, estudiar diferentes
resultados de diferentes instituciones de salud y aplicarlas en sus propios beneficios. Este sistema fue
programado sobre la herramienta de desarrollo para sistemas de gestión de bases de datos: ORACLE de la
compañía del mismo nombre. Y en este trabajo se exponen los fundamentos de tal decisión.
2

1. INTRODUCCIÓN.
El desarrollo tecnológico ha alcanzado niveles nunca antes imaginados. Hace algún tiempo atrás el hombre
no pensó (jamás) que con un simple golpe de tecla de una computadora pudiera estar comunicándose con el
otro confín del planeta. La industria biomédica ha sido también, como es lógico, tocada muy de cerca con
este desarrollo vertiginoso de la computación y la electrónica.
La tecnología biomédica contribuye a la prevención de enfermedades mediante la protección o disminución
de los riesgos de ocurrencia, así como también permite limitar los impactos de las enfermedades. La
tecnología es la principal herramienta del diagnóstico a fin de obtener los signos clínicos con el propósito de
identificar la naturaleza, causa y extensión de un evento patológico. La tecnología contribuye asimismo al
tratamiento por restauración, mejoramiento o sustitución de las funciones fisiológicas y corporales, así como
previene de su deterioro o de dolor al individuo, garantizándole el disfrute de una adecuada calidad de vida.
Gracias a su empleo, la tecnología permite acortar el período de enfermedad o recuperación de los individuos
y su reincorporación a la sociedad.
Necesariamente tiene que haber productores y consumidores de esta tecnología; los primeros se esmeran
cada vez más por satisfacer las necesidades de los segundos, mediante equipos de mejores prestaciones. Los
consumidores, en cambio, tratarán, de acuerdo a sus posibilidades, de hacer la mejor selección.
La industria biomédica ha crecido vertiginosamente en los últimos años, De acuerdo a la Oficina de Control
de Drogas y Alimentos (FDA), organismo que se encarga en los Estados Unidos del registro, control y
certificación de los dispositivos médicos, en la actualidad existen más de 50 000 tipos diferentes de equipos
médicos y cada año se agregan a este arsenal 5 000 nuevos productos. Todo esto es gracias a la actual
relación entre la ingeniería y la medicina que ha dado origen, en los países industrializados, a un gran
complejo médico-industrial cuya producción alcanzó un mercado para 1990 por la cantidad de 62.5 miles de
millones de dólares. Siendo esta la industria de mayor crecimiento proporcional y la que más porcentaje de
sus ventas invierte en Investigación y Desarrollo. [53]
Ahora bien ¿es con más tecnología y hospitales que se logra un mejor servicio de salud?
Por supuesto, no son ni la tecnología ni los hospitales los que determinan el nivel de salud de la población.
Kerr Write en 1980 señaló, luego de un estudio sobre los Sistemas Sanitarios, que de cada 1 000 personas,
250 no necesitan atención, 740 sólo necesitan atención ambulatoria, 9 requerirán de un hospital general y
sólo una de un hospital especializado [52]. Otro estudio realizado en 54 países, produjo dos conclusiones
básicas:
1- El nivel de salud de la población viene determinado en un país por los siguientes factores en el orden
indicado:
a-) Educación
b-) Vivienda
c-) Nutrición
d-) Urbanización
e-) Recursos Médicos (incluida la tecnología).
3

2. Existe un óptimo en cuanto a inversiones en el sistema sanitario, a partir del cual sólo se consiguen mejoras
marginales en el nivel de salud de la población, afectando cada vez a menos habitantes las mejoras. De los
estudios realizados, en relación con el uso de la tecnología biomédica, se ha comprobado que si establecer un
diagnóstico con una probabilidad de acierto del 95 % cuesta cinco unidades, para obtener una certidumbre del
96 % es necesario invertir 500 unidades.
En el mundo desarrollado, los Sistema de Gestión Tecnológica en Hospitales han evolucionado y se han
creado atendiendo a la reducción de costos y a el aumento de la competitividad con la consecuente elevación
de la calidad del servicio. Los aspectos de Disciplina Tecnológica, tales como la Verificación y Calibración
de Equipos Médicos, se han hecho una práctica constante en los hospitales, empujados por la competencia,
las leyes y la exigencia permanente de las Compañías Aseguradoras, todo lo cual ha propiciado la sensible
disminución de riesgos por el empleo de Tecnología Biomédica en los Hospitales.
Los modernos Sistema de Gestión Tecnológica en Hospitales además de su evolución en cuanto a
metodologías desarrolladas, también se han apoyado en las nuevas tecnologías de la información, mediante
productos informáticos existentes que facilitan el trabajo de implantación de los mismos. Con respecto al
segundo aspecto es que va encaminada la realización de este trabajo de diploma.
Internacionalmente existen muchos productos informáticos diseñados para que la Implantación de los modernos
sistemas de Gestión Tecnológica Hospitalaria sea óptima y más rápida para los especialistas que se encargan de
llevarla a cabo, además de apoyarse en los sistemas globales de informatización de países completos e incluso de
naciones de diferentes regiones. Sin embargo actualmente en Cuba no existe una automatización global del
sistema Nacional de Salud, tampoco existen productos o herramientas informáticas que, integralmente
automaticen, la Gestión Tecnológica Hospitalaria en relación con lo que respecta a los equipos médicos. Sí es
justo destacar que existen productos relacionados con la Gestión del Mantenimiento de equipos médicos como
son: COMANEC (Desarrollado por Electromedicina Nacional) y otros.
Con el ánimo de desarrollar una herramienta informática integral que apoye a los especialistas que se encargan de
llevar a cabo la implantación de los modernos Sistemas de Gestión tecnológica y aumentar la competitividad de
nuestras instituciones de salud, es que va encaminado este trabajo, con los siguientes objetivos a cumplir:
• Llevar a cabo la concepción general del Sistema de Gestión Tecnológica Hospitalaria en su versión
1.0.con el análisis, diseño y programación de tres de los subsitemas que lo componen: SMACOR , SGA
, SADTEC, con vistas a que este sea insertado en un Sistema de Información Hospitalario (HIS),
siguiendo la filosofía de la norma internacional CEN/TC 251 12967-1 propuesto por la Comunidad
Económica Europea.
• Realizar el estudio sobre las potencialidades que ofrece la herramienta de desarrollo para sistemas de
Gestión de Bases de Datos ORACLE, ofreciendo los elementos para su elección.
Por último se puede decir que, con la creación, actualización y mantenimiento de sus bases de datos, se
sentarán las bases para la creación de Sistemas Expertos con el objetivo de ofrecer servicios de diagnóstico
remoto (DR) a todas las Instituciones Hospitalarias de cualquier país. Se prevé además que este sistema se
encuentre instalado en la Red Nacional de Salud INFOMED y sea utilizado por Electromedicina Nacional,
entidad que ofrece sus servicios a todos los hospitales de CUBA.
4

Para el análisis y el empleó la metodología ADESA y para los algoritmos se utilizó las metodologías
existentes pertenecientes al Sistema de Gestión Tecnológica hospitalaria desarrollado por la línea de
investigación de Ingeniería Clínica del Departamento de Bioingeniería del ISPJAE.
2. ANTECEDENTES.
El desarrollo de este trabajo de diploma está enmarcado en dos aspectos claves:
Por una parte, los autores han pertenecido durante 4 años a la línea de investigación de Ingeniería Clínica del
Departamento de Bioingeniería del ISPJAE. Esta línea de investigación se dedica al desarrollo de
metodologías relacionadas con los Sistemas de Gestión Tecnológica Hospitalaria y productos informáticos
donde se soportan estas metodologías.
Por otra parte, se desarrolló un producto informático (en los cuales los autores participaron) perteneciente al
primer módulo del Sistema de Gestión Tecnológica Hospitalaria, llamado SMACOR que se instaló, y que
actualmente se encuentra en fase de explotación, en tres instituciones de Cuba. (CIREN, Clínica Central Cira
García y Hospital Clínico Quirúrgico Hermanos Ameijeiras). Este sistema, a pesar de sus ventajas, también
presenta determinadas limitantes; la más importante en estos momentos es que no esta soportada para trabajar
en redes. Producto de la explotación del sistema y del cambio en las políticas de informatización del
Ministerio de Salud Pública cubano, han surgido nuevos requerimientos que hacen necesario la realización de
una versión superior que cumpla las expectativas.
Por las razones anteriormente expuestas y por el conocimiento en profundidad del objeto de estudio que los
autores es que se acometió la realización del Sistema de Gestión Tecnológica Hospitalaria asistido por
computadoras aumentando así el alcance del primer producto ya existente.
5

CAPÍTULO # 1 FUNDAMENTACIÓN TEÓRICA Y ELECCIÓN DE LA
HERRAMIENTA DE DESARROLLO.
1.1 LA GESTIÓN TECNOLOGÍCA HOSPITALARIA.
Definición: Es un proceso sistemático de determinación y optimización de la razón costo/beneficio,
efectividad, aseguramiento de la calidad, mantenimiento de la seguridad de la instalación y equipos médicos
y no médicos con el objetivo de satisfacer las demandas siempre crecientes de los sistemas hospitalarios
permitiéndole además ser más competitivo.[25].
1.2 TENDENCIAS ACTUALES SOBRE EL USO DE LA INFORMATICA EN EL SECTOR DE SALUD Y
EN LA ESPECIALIDAD DE INGENIERÍA CLÍNICA.
La aplicación de las tecnologías de la información en el sector de la salud es hoy una realidad, hace un
tiempo atrás, algunas organizaciones internacionales, entre ellas la Sociedad para la Gestión de Información
en Sistemas de Salud, (HIMSS) realizaba estudios sobre el impacto que tendría el uso de la informática en el
sector de la salud.
Por ejemplo la siguiente encuesta realizada en 1994 a directivos de Salud evidenció las siguientes tendencias
en las llamadas tecnologías de la información en su sector[24]
1. En un mercado evidenciado por la reducción de los costos, los factores que dirigían las fuerzas hacia la
informatización la información en el sector de la salud son:
a) Movimiento hacia la gestión de la salud (25 %)
b) Solicitud e historial de datos sobre sucesos de cualquier índole (24 %)
c) Movimiento hacia la implemetación de las redes de computadoras más potentes (17 %)
2. Los sistemas de información salud mas prioritarios en los próximos 2 años.
a) Sistemas que integran a localidades geográficamente separadas.(31 %)
b) Introducción de sistemas de registros de pacientes basados en computadoras. (19 %)
c) Integración de sistemas entre departamentos (13 %) y rediseño de sistemas enfocados a pacientes. (13
%).
3. El 56 % de los encuestados planteó que las “autopistas” mundiales de la información son esenciales para
un buen desenvolvimiento del ambiente medico hospitalario.
4. En los próximos tres años los desarrollos más significativos en materia de informativa relacionado a
pacientes y que afectarán directamente a estos será:
a) Aplicaciones que harán más dinámicos el servicio de salud a pacientes. (49 %)
b) Acceso a servicios de salud desde los domicilios. (20 %)
c) El uso de “SMART CARD” (tarjetas inteligentes). (17 %).
5. Aunque el 49 % solicitó el uso de Internet, se avizoraba su uso para:
a) Comunicación vía correo electrónico.
b) Solicitud de bases de datos de investigación clínicas .
c) Intercambio de información consumidor.
6

d) Consultas medicas en línea.
6. Ante la pregunta ¿Los médicos compartían información sobre pacientes en una red nacional para el año....
? Se respondió:
a) Para el año 2000 (39 %)
b) No ocurrirá para al menos dentro de 1º años (38 %)
c) Dentro de los próximos 3 años (14 %)
Seis años después de la realización de esta encuesta (año 2000) y en el marco de la preparación de este
proyecto, la división de Investigación Ingeniería Clínica del Centro de Bioingeniería ha acopiado un gran
cumulo de información a través de búsquedas de información en las más prestigiosas bibliotecas virtuales y
publicaciones relacionadas con el tópico de la informática medica. Aquí se publican números completos
sobre los temas de las tendencias avizoradas por los señores que participaron en la encuesta anterior.
Pero específicamente relacionado al campo de la Ingeniería Clínica el impacto de las Tecnologías de la
Información se ha demostrado en las siguientes tendencias:
• Optimización de los servicios técnicos usando las nuevas tecnologías de la información y diagnostico
remoto del equipamiento biomédico.
• Integración de funciones de departamentos de Ingeniería Clínica y de Servicios Informáticos.
1.2.1 OPTIMIZACIÓN DE LOS SERVICIOS TÉCNICOS USANDO LAS NUEVAS TECNOLOGÍAS DE LA
INFORMACIÓN Y DIAGNOSTICO REMOTO DEL EQUIPAMIENTO BIOMEDICO.
El costo de una organización que ofrece sus servicios incluido viajes y logística, está normalmente entre el
65-75 % de las ganancias o del presupuesto para el caso de los departamento de Ingeniería Clínica (IC) [8],
es por esto que se requiere de una optimización e incremento de la eficiencia de la productividad del servicio
.
Otro aspecto es que entre el 60-75 % de todas las solicitudes de servicios técnicos se requieren de accesorios,
piezas de repuesto, componentes, módulos, equipo de verificación, etc. que el ingeniero debe utilizar para
resolver un problema[8]. Es por esta razón que se necesita cada vez más de algoritmos y aplicaciones para
calcular los niveles adecuados de inventarios en almacenes, destinados a asegurar un servicio más eficiente.
Además se necesita de la creación de metodologías para realizar un seguimiento más intenso sobre el flujo de
entradas/salidas de almacenes y ubicación in cito de accesorios, piezas de repuesto, componentes y módulos.
Se necesita orientar el problema de los niveles de inventarios al mantenimiento y/o la Gestión Tecnológica,
ya que las experiencias actuales indican que aproximadamente entre el 30-40 % de todo lo que se repone
retorna a almacenes en buen estado y el 50 % del valor que se tiene en el inventario es normalmente
gestionado de manera nacional y/o regional/local. [8]. Malgastándose mucho tiempo y recursos en estas
tareas.
7

Con la reducción de los tiempos de entrega de accesorios, piezas de repuesto, componentes, módulos, equipo
de verificación, etc. para la realización de servicios técnicos se prevee un aumento de la productividad del
servicio. La figura 1 del anexo 1, muestra que, reduciendo el tiempo de entrega se puede aumentar
considerablemente el retorno de la inversión para un inventario dado. Sobre esta idea se puede plantear que
con la creación de herramientas informáticas con facilidades de reportes como los que se muestran en la
figura 1 del anexo 1 permitan hacer estudios de tendencias y establecer niveles óptimos de tiempos de
entrega.
Se desarrollan actualmente aplicaciones informáticas que integran todos los puntos anteriormente
relacionados, son los llamados: Sistemas de Gestión Integrados de Servicios Técnicos asistidos por
Computadoras (FSMS). Tienen el objetivo de llevar un control más estricto y rapidez del procesamiento de la
información, además de ofrecer en un solo paquete los siguientes módulos:
• Gestión de solicitudes de servicios.
• Proyectos de servicios técnicos y programación de tareas.
• Gestión de partes y componentes.
• Contabilidad y control financiero.
• Sistemas de gestión de bases de datos y reporte de la información de todos los módulos.
• Gestión de contratos de servicios y del ciclo de vida del equipamiento.
• Servicios de Diagnostico Remoto.
Se plantea en [8] que el 35 % de todas las adquisiciones de los FSMS desde enero 1999-2000 son usuarios
nuevos y que el 65 % restante tenderá a sustituir los Sistemas de Mantenimiento Asistido por Computadoras
existentes.
Por otra parte desde la década pasada ha existido un incremento significativo del desarrollo, aplicación y
uso de la Inteligencia Artificial (IA) y el diagnostico avanzado de la tecnología en el campo del servicio
técnico*. Investigaciones llevadas a cabo en la década de los 80 mostró que un servicio técnico orientado al
diagnostico hubiera podido eliminar entre el 30-35 % de todas las solicitudes de servicio realizadas por
usuarios [9]. Ya que este tipo de servicio puede reducir significativamente la cantidad de tiempo perdido
entre la solicitud del servicio y el cumplimiento del mismo. Además de disminuir los tiempos muertos de la
tecnología instalada**
* Entiéndase servicio técnico como el grupo de actividades que se ofrecen por entidades o departamentos que incluye: Mantenimiento correctivo
y preventivo, instalación, instrucciones de explotación y entrenamiento a usuarios.
** Entiéndase por tiempo muerto el tiempo que transcurre entre la rotura de un equipo y su restablecimiento a condiciones normales de trabajo.
8

Por diagnóstico remoto se entiende una estrategia o metodología de uso de la información para adquirir datos
e identificar, aislar y finalmente diagnosticas fallos en equipos. El objetivo final de este tipo de servicio es
mejorar los niveles de funcionamiento de la tecnología instalada y hacer el servicio más productivo. Las
razonas fundamentales por las cuales este se hace más productivo son:
• Anticipación de fallos potenciales imprevistos.
• Reducción y eliminación de solicitudes de servicio donde se encuentra la tecnología instalada.
• Uso de programas de diagnóstico cada vez más sofisticados
• Reducción de tiempos de reparación donde se encuentra la tecnología instalada.
Ahora bien ¿Cuál es el estado del arte y experiencias actuales en la aplicación y uso de las técnicas de
diagnostico remoto de tecnologías biomedicas? ¿así como el impacto del uso de esta metodología en el
campo del servicio técnico tanto para usuarios como para los que lo ofrecen?.
La tendencia actual es la de adquirir y usar la información de la tecnología instalada desde Centros de
Control en vez de asistir directamente de manera inmediata a los lugares donde se solicita el servicio.[9]. Por
tanto los métodos de adquisición y los medios de transmisión y gestión de la información es hacia donde está
enfocado hoy en día el principal esfuerzo para las organizaciones que ofrecen sus servicios a través del
Diagnóstico Remoto (DR) y la Inteligencia Artificial (IA). En este orden de información la mantenibilidad de
las bases de datos es el aspecto más crítico, por el propio uso que estas tienen como cantera para la formación
de bases de conocimiento y ofrecer sus mayores beneficios en un programa de DR fiable y seguro a la
tecnología que se encuentra instalada.
Además la filosofía del servicio a la tecnología instalada también está cambiando, esta filosofía se refiere a
ofrecer un mantenimiento predictivo o preventivo solamente cuando la tecnología instalada lo necesite,
disminuyendo costos por la realización de intervenciones innecesarias. Se impone entonces mantener a la
tecnología instalada en un estado llamado: estado de monitoreo continuo. En este estado se mantiene un
control total de los parámetros vitales de los equipos, pudiéndose intervenir solamente en caso de que estos
se encuentren críticamente deteriorados y puedan conducir a una falla potencial . Lógicamente no todos los
equipos pueden estar bajo esta condición de monitoreo continuo.
La práctica más usada de DR es mediante los llamados Centros de Asistencia Técnica (CAT). Los CATs
típicamente están compuesto un grupo de expertos que tienen acceso a la documentación técnica y a los
sistemas de diagnóstico de la tecnología instalada donde se solicitan los servicios, pudiendo ofrecer, muchas
veces en línea, una solución inmediata; que puede ser un procedimiento de operación o servicio determinado
para solucionar fallos, mantenimientos preventivos o/y predictivos, modulo o componente electrónico entre
otros aspectos.
Los CAT pueden ofrecer sus servicios en línea por que se encuentran interconectados con los llamados
sistemas de Gestión de Solicitudes de Servicios, estos modernos sistemas reciben las llamadas de servicios de
los usuarios a través de unos sistemas llamados Escritorios de Ayuda y envían estas a los CAT según sea la
naturaleza de la llamada.
Los CAT y estos sistemas Gestión de Solicitudes de Servicios lo conforman un grupo de módulos:
9

Modulo de Gestión de
Configuración:
Modulo de soluciones:
Modulo de análisis de
tendencias:
Modulo de control de
programas:
Modulo compartido
de coordinación de
recursos :
Este modulo es requerido para todas los CAT. Su función es la
de identificar y localizar en línea los programas y dispositivos
electrónicos en la tecnología que se encuentra instalada
Este módulo puede examinar información y ofrecer soluciones
de problemas desde una Red de área local (LAN),
Computadoras Personales (PC) y otros equipos a través del uso
de diagnósticos integrados.
Su función es la de realizar un seguimiento de toda la actividad
de aseguramiento para que se realice un servicio adecuado.
Identificación a largo plazo de tendencias o comportamientos
en cuento a servicios prestados y/o solicitudes realizadas.
Su función es la de controlar la realización de, y la adquisición
de nuevas versiones.
Su función es mantener un seguimiento de la solicitud del
servicio además de encargarse de la impresión de los reportes
necesarios.
En la figura # 2 del anexo 1 se ofrece esquemáticamente el funcionamiento integrado ,aún más futurista, de
los CAT y Gestión de Solicitudes de Servicios con el usuario. En la figura 2, nótese como a través de
INTERNET el usuario puede acceder a los Sistemas de Solución Problemas o puede realizar solicitudes de
servicios al sistema Gestión de Solicitudes de Servicios o al TAC directamente. Además como el ingeniero
que tiene que realizar directamente sus servicios en el sitio donde está la tecnología instalada vía moden,
INTERNET u otra, también puede acceder Sistemas de Solución Problemas que será una gran base de
conocimientos capaz de ofrecer soluciones de todo tipo y que se retroalimenta constantemente de sus
usuarios.
Esta es la filosofía y configuración que se impondrá, como primera tendencia en el siglo 21, en cuanto a la
utilización DR e IA en el campo del servicio técnico y su relación con el uso de las tecnologías de la
información.
Actualmente se usa el termino DR como sinónimo competitividad y servicio de excelencia. Los lideres en
uso del DR en el área de la tecnología de equipos médicos son: General Electric Medical, Picker
International, Mediq Engineering and Maintenance Services y Elscint. Los productos relacionados al DR que
ellos ofrecen son:
GENERAL
ELECTRIC
MEDICAL:
Ofrece DR en línea para sistemas de tomografía axial computarizada y
resonancia magnética nuclear.
El sistema incluye: microprocesador, modem bidireccional y un programa
instalado en el equipo que se encuentra en la instalación
10

El proceso ocurre de la siguiente forma: El usuario solicita servicio a GE
CARES (Reparación asistida por computadoras y servicios de ingeniería). GE
CARES avisa al técnico de servicio vía modem, este usa un programa experto
para diagnosticar el problema. En caso de tener que realizar serviocios en el
lugar el técnico vía modem ofrece procedimientos y componentes necesarios
para realizarlo.
Los tiempos de respuesta de GE CARES están en el orden de 15 minutos-1.5
horas[9]
PICKER Ofrece una herramienta informática para realizar DR a sistemas de
tomografía axial computarizada llamado EXPERT. EXPERT es un sistema
informático portable[9] que se puede comunicar con los CAT de Picker vía
modem y realizar paso a paso rutinas de diagnóstico a estos equipos. Es usado
básicamente por el grupo de ingeniería de la Picker aunque puede ser vendido
a usuarios junto al equipo de tomografía axial computarizada.
MEDIQ Es un proveedor independiente de servicios técnicos a equipos de imágenes
médicos que es parte de la compañía INNOSERV que usa su propio sistema
de DR a través de un producto llamado MEMSERV. Este producto
colecciona datos de componentes electrónicos del equipo y los analiza con el
objetivo de identificar problemas.
ELSINT Ha desarrollado un sistema Inteligente Asistido por computadoras para
equipos de imágenes para medicina nuclear, su nombre comercial es
MASTERMIND el cual identifica problemas y recomienda soluciones a
través de una PC.
Por otra parte el impacto positivo y el incremento en la productividad y eficiencia del servicio en el uso del
DR ha sido ampliamente medido y cuantificado.
Por ejemplo en una encuesta realizada a mas de 100 proveedores de servicios técnicos [9] mostró que reduce
los tiempos de entrenamiento, tiempos de respuestas, tiempos de parada, facilita una localización de medios
técnicos y recursos humanos de manera más rápida disminuyendo así costos administrativos y de
mantenimiento.
Otra encuesta realizada a más de 250 usuarios [9] mostró que el DR es para ellos un servicios más
competitivo y es sinónimo de excelencia. Las siguientes tablas muestran los por cientos de mejoramientos en
costos ahorrados por diferentes rubros gracias al uso del DR y los beneficios para proveedores y usuarios.
11

Bases de la
justificación de
costo
Ganancia
general
Captura y
retensión de
conocimiento y
especialización
Evita llamadas
de servicios
innecesarias
Reducción de
costos y
tiempos de
entrenamientos
Reducción de
tiempos medios
de reparaciones
y diagnósticos
Reducción de
no soluciones a
problemas
debido a partes
y componentes
y habilidades
técnicas
Otras (aumento
de ganacias,
valor añadido de
productos)
Automatización y
computadoras de
oficina
Telecomunic
aciones
12
Tecnología
Electrónica Medica Automatización de
edificios y equipos
de explotación
55 % 35 % 50 % 64 %
41 % 45 % 48 % 55 %
31 % 43 % 21 % 34 %
21 % 18 % 14 % 21 %
37 % 28 % 19 % 34 %
31 % 21 % 22 % 20 %
11 % 10 % 12 % 10 %
Tabla 1. Por ciento de mejoramiento del costo ahorrado y otros beneficios, basados en la historia de
diferentes proyectos de DR (Fuente: [9])

Beneficios Efectos Proveedor de
servicios
Reduce los tiempos de Reduce los costos de mano
entrenamientos del personal de obra por cada técnico
de mantenimiento
dedicado a mantenimiento
X
Reduce o elimina el esfuerzo Reduce los requerimientos
requerido para analizar datos de personal
X
X
Reduce o elimina el esfuerzo
requerido para recolección de
datos
Reduce el transcurso de
tiempo requerido para evaluar
y diagnosticar un problema
Mejora la predicción de fallos
para iniciar mantenimiento
preventivos previos a los
fallos de emergencia
Mejora los tiempos de
respuestas
Mejor servicio y
diferenciación
Mejora la asignación de
recursos
Posibilidad de ofrecer
servicios remotos en áreas
inaccesibles
Reduce los servicios
improductivos debido a ala
falta de partes de
componentes
Reduce los requerimientos
de personal
• Reduce los
requerimientos de
personal.
• Mejora la utilización
técnica de equipos.
• Reduce los
requerimientos
personal.
de
• Mejora la utilización
técnica de equipos.
Mayor satisfacción y
retención del cliente.
Potencial para ganar
nuevos mercados y mejorar
posiciones en mercados
actuales
Reduce los costos de
personal e inventario de
partes y componentes
Reduce los costos de
personal e inventario de
partes y componentes
Reduce los costos de
personal
Cliente
X X
Finalmente se prevee que para el año 2000 los gastos para el desarrollo y uso de las técnicas de DR siga
creciendo fundamentalmente en el área de la electrónica, este crecimiento será de 2.6 billones de dólares ,
este número representa un 76.9 % con respecto al año 1997.
13
X
X X
X
X
X X
X X
Tabla 2. Beneficios primarios e impacto del DR en el servicio de equipos (Fuente: [9]).

Como segunda tendencia en el siglo 21 que se plantea, en cuanto al campo del servicio técnico y su relación
con el uso de las tecnologías de la información, será la combinación de las facilidades que ofrece
INTERNET y el WWW con las aplicaciones llamadas “browsers” con el objetivos de ofrecer servicios
técnicos mediante sistemas de gestión de servicios técnicos en tiempo real. A este nuevo enfoque se le ha
llamado en la literatura Buro de Servicios Virtuales (VSB). [8]
Blumberg en [8] plantea “El VSB es el medio mediante el cual el servicio técnico, los programas de servicios
a usuarios, las tecnologías de las comunicaciones e INTERNET estarán unidas en un mismo objetivo: ofrecer
un servicio más eficiente y competitivo. Se prevee que el VSB ofrezca una potente vía para la disminución y
optimización de la razón costo/beneficio y acelerar el periodo de retorno de una inversión (ROI)”. En este
mismo trabajo se plantea que la aplicación de los VSB traerán los siguientes beneficios:
• Reducirá considerablemente los costos de operación.
• Reducirá considerablemente los costos de desarrollo e instalación de tecnologías de punta .así como el
tiempo relacionado con este proceso.
• Se mejorará las posibilidades de comunicación entre usuarios y clientes y la estación de Central de
Control de Servicios y entre esta última y los ingenieros de servicios que in cito resuelven los problemas,
ya que se prevee una mejora en las comunicaciones inalámbricas (sistemas de globales de localización,
servicios de INTERNET por teléfonos celulares, además de los habituales)
• Provee un alto nivel de confiabilidad de las comunicaciones.
• Disminuirá significativamente la necesidad de invertir recursos de programas informáticos y dispositivos
electrónicos.
El aspecto más importante a destacar, es que con la aplicación de esta tecnología las organizaciones medianas
y pequeñas que ofrecerán sus servicios técnicos, incluso los departamentos de Ingeniería Clínica (IC) que se
dirigen hacia la realización de un servicios más optimo y estratégico, podrían competir con las grandes
organizaciones de servicios.
Con el planteamiento de esta última idea significa en primer lugar, que los IC podrían sustituir cada vez mas
sus contratos de servicios con fabricantes y evaluar la opción del servicio en casa como una variante más
económica y viable. En segundo lugar un departamento de IC puede utilizar la tecnología de VSB para
reportar y solucionar problemas similares que ya hayan ocurrido en otros departamentos.
Actualmente existen sitios WEB donde se ubica un gran cumulo de información relaciona con el servio
técnico, normativas, bibliografía, estudios e indicadores de referencias. Pero distan mucho de ser un VSB, no
obstante es un buen inicio. Alguno de los más significativos son: http://www.invisionet.com,
http://www.duke2000.edu, http://www.healthcare.ecri.com.
14

• INTEGRACIÓN DE FUNCIONES DE DEPARTAMENTOS DE INGENIERÍA CLÍNICA Y DE
SERVICIOS INFORMÁTICOS.
Uno de los aspectos fundamentales tratados en el evento realizado por AAMI en 1999 [1] es la integración
de los departamentos de Ingeniería Clínica y Servicios Informáticos debido al desarrollo de las tecnologías de
las comunicaciones y su respectiva globalización. Se prevee incluso una fusión de ambos departamentos en
uno solo [2].
Un nuevo proyecto llamado TELEHEALTH, propuesto por AAMI es un modo mediante el cual ambos
departamentos interactuarán. Este proyecto va orientado a: “Las tecnologías instaladas en instituciones de
salud que provean información sobre pacientes, diagnostiquen, realicen tratamientos, etc. contribuyan cada
vez más a un cuidado del paciente adecuado aumentando la eficiencia y disminuyendo costos de la misma ”
[8] . Para la realización exitosa de este proyecto se propone un cambio desde la forma de pensar hasta de la
estructura organizativa. Es necesario que ambos departamentos no se vean mas como contrarios[1] . Con esta
nueva estructura se prevee unmejor uso de los recursos compartidos, normalización de cableados y
protocolos de comunicación, de datos, transmisión de vídeo voz e imágenes. En la figura 3 del anexo 1 se
muestra el cambio de estructura que se prevee con la implantación de este proyecto.
Otro campo en el que se preeve una integración más a fondo es la vinculación de los Sistemas de
Información Hospitalaria (HIS) y la obtención de datos clínicos a través de los sistemas de Información de
Laboratorio Clínico, Automatización de Sistemas de Monitoreo para Unidades de Cuidados Intensivos,
Salones de Operaciones y Sistemas de Almacenamiento y Transmisión de imágenes medicas usando la
Instrumentación que se encuentra en los propios equipos médicos.
Por último se necesita de la inclusión de los modernos FSMS, VSB, etc. en los HIS como parte de un eslabón
más en la plataforma integral e interdepartamental del manejo de datos e información que fluye en un
ambiente medico hospitalario.
1.3 LOS SISTEMAS DE INFORMACIÓN HOSPITALARIA (HIS)
La definición de HIS desgraciadamente no es única. La literatura donde se publican temas relacionados con
la informática, procesamiento de datos médicos, etc. está colmado de definiciones y descripciones de muchos
Sistemas Informáticos que se clasifican como HIS; sin embargo no loson. Para aclarar este concepto se cree
útil comenzar por exponer que no es un HIS.
Un HIS incorpora información de muchos departamentos dentro una institución de salud, pero un HIS no es
un sistema departamental, tales como farmacia o radiología etc, ya que estos últimos están limitados
solamente a la función especifica que realizan. Ellos están desarrollados para manejar la información
relacionada al departamento en el cual están instalados.
El papel fundamental que juegan estos sistemas dentro de un HIS es la servir, y la de proveer información
necesaria que el HIS utilizará para gestionar y manejar los datos globales de la institución de salud.
15

Un Sistema de Información Clínica tampoco es un HIS. Aunque un HIS necesita información Clínica para
cumplir su funcionalidad completa, no solo recibe información de estos. Ejemplos de sistemas de
información clínica son: Sistemas para Unidades de Cuidados Intensivos, Salones de Operaciones, Cuidados
Respiratorios, Laboratorio Clínico[24].
Las prestaciones de los sistemas departamentales y clínicos son bastante similares y tienen características
comunes:
• Requieren de bases de datos para almacenar información que de alguna manera está relacionada con los
pacientes.
• Posibilidad de interconexión hacia otros departamentos ya sea clínico o administrativo.
• Posibilidades de impresión de reportes relacionados con su función.
En definitivas ¿Cuál es la diferencia entre un HIS y estos sistemas llamados departamentales o Clínicos?
Para que un sistema se considere un HIS este debe satisfacer a necesidades globales de la institución de
salud. En este contexto si se enfoca a la institución de salud como un usuario del HIS, entonces este debe ser
capaz de brindar información integral sobre el estado de todos los departamentos los cuales forman parte del
HIS.
Por ejemplo imaginemos que se necesita saber el estado de los costos de todos los servicios que se brindan a
los pacientes. Entonces el HIS debe ser capaz de encuestar a todos los departamentos necesarios para ofrecer
la información requerida, por departamento, servicios o total.
Las funciones de un HIS están bastante claras en la literatura internacional. El tipo de relación entre los
diferentes sistemas que forman al HIS depende del tipo de norma aplicada. Las funciones según [24] son la
siguientes:
• Sistemas de gestión de bases de datos de pacientes y su integración de datos clínicos, así como de toma
de decisión.
• Adquisición de datos de pacientes.
• Admisión de pacientes/control de camas.
• Aplicaciones de evaluación, diagnostico, monitoreo y tratamiento de pacientes.
Como se puede observar no existe incluido en este modelo de HIS aplicaciones relacionadas con la gestión
tecnológica, ni gestión de recursos financieros (según los autores no era alcance de esa publicación tratar esos
tipos de aplicación [24])
Se tratará de manera resumida cada una de las funciones.
16

Sistemas de gestión de bases de datos de pacientes y su integración de datos clínicos, así como de
toma de decisión.
Las bases de datos de pacientes de los HIS deben estar diseñadas para que soporten información de todo el
historial o actividad del paciente durante su paso por la institución de salud, durante las diferentes visitas que
realice. A esto suele llamársele registros longitudinales de la información del paciente.
Antiguamente las bases de datos de los HIS fueron diseñadas en función de creación de registros por
encuentros, esto particularmente presentaba un problema, y era que si un paciente va a al hospital o
institución de salud y este encuentro puede causaba otros por la misma causa, la continuidad del es bastante
complicado ya que hay un registro por encuentro. Para seguir el historial había que realizar consultas a la
base de datos. Actualmente el concepto ha cambiado, ahora se crean registros en función de lo que suele
llamarse Episodio o Visita inicial , si este episodio inicial provoca nuevos encuentros medico-paciente se
actualiza el anterior y no se cierra hasta que no se le de alta al paciente.
Por lo expuesto en el párrafo anterior se dice que es un requerimiento de los HIS modernos las creación de
registros de Episodios por pacientes. [24])
Tradicionalmente también se tenía la información clínica de los pacientes en sistemas de diferentes
departamentos. Con este tipo de estructura resultaba fácil reportar información de datos clínicos de pacientes
por departamentos, pero no de forma global. Con la integración de las bases de datos de paciente y clínicos
como función del HIS, se puede observar en una misma consulta toda la información referente a estos, de
manera que facilita la evaluación final del paciente.
Por esto es que se dice que otro requisito de calidad de un HIS moderno es la integración de los datos de
pacientes con los registro clínicos del mismo. [24])
Hoy en día los HIS no son meramente sistemas de bases de datos que se dedican a almacenar información
sobre la actividad de los pacientes y médicos en el ambiente hospitalario, estos también son un asistente para
el cuidado y atención de pacientes. Esta última idea implica que los HIS modernos deben ser capaces de
ofrecer bases de conocimiento clínico donde se pueda consultar el conocimiento acumulado por años en el
tratamiento de enfermedades, procedimientos, prácticas más utilizadas, etc. Estas bases de conocimiento
pueden incluir alertas o disparadores para la implemetación de determinado procedimientos, prácticas
utilizadas, etc.
La anterior consideración nos lleva a plantear que un HIS moderno también debe proveer funciones para la
toma de decisión [24])
Adquisición de datos de pacientes.
La adquisición de los datos clínicos de los pacientes es un aspecto vital para que muchas de las funciones del
HIS se realicen satisfactoriamente. De manera que todos los HIS deben proveer una terminal de entrada de
datos para captarlos.
17

Será necesario entonces una interfaz común entre todos los sistemas que manejen datos clínicos y de
pacientes para adquirir y actualizar esta información. La interfaz es física y de programas. Como es lógico
pensar, la interfaz física cambia con los cambios tecnológicos, esto será un aspecto atener en cuenta cuando
se diseña e instala un HIS. El otro aspecto está en las normas de codificación y comunicación de la
información para que los diferentes sistemas puedan entenderse entre si.
Existen algunas normas en cuento a la terminología medica a utilizar, codificación de fabricantes,
proveedores, procedimientos quirúrgicos, reportes radiológicos, de comunicaciones de imágenes médicas,
etc. Pero ninguno esta establecido mundialmente. Esto realmente responde a intereses de mercado y a quien
diseña mas rápido y primero su HIS con mejores prestaciones con respecto a otro producto similar. Este
modelo de trabajo es inadmisible, y aunque se hacen esfuerzos por resolver este problema aun no lo esta del
todo.
Admisión de pacientes/control de camas.
La admisión y control de pacientes se realiza en un HIS a través de las siguientes funciones primarias:
• Adquirir de pacientes la información demográfica y financiera
• Comunicación de esta información a todos los subsistemas que componen al HIS, en caso de que el
paciente asistas a estos servicios.
• Hacer consulta y actualización si existen visitas previas relacionadas al mismo motivo o episodio para
lograr los registros longitudinales del paciente.
Para cumplimentar estos requisitos se plantea que el HIS cuente con los siguientes ficheros:
Indice Central de Pacientes (ICP): Contiene un identificador único para cada paciente y los otros campos
necesarios para captar sus datos demográficos y financieros.
Fichero Clínico Longitudinal (FCL): Registros clínicos críticos sobre episodios anteriores, alergias,
procedimientos quirúrgicos, diagnósticos y reportes radiológicos.
Aplicaciones de evaluación, diagnostico, monitoreo y tratamiento de pacientes.
El propósito de este tipo de aplicaciones es la de proveer toda la información necesaria para manejar todo el
estado del paciente en la institución de salud. Se dice que esta es la segunda función en importancia de un
HIS. Estas aplicaciones se pueden clasificar en simples o complejas.
Simples: Las aplicaciones son orientadas departamentalmente. Es decir, el especialista medico puede acceder
desde su terminal y consultar reportes de diferentes servicios independientes. Se muestra información
individual no integral.
Complejos: Las aplicaciones son orientas a integrar la información de diferentes departamentos. Es decir, el
especialista medico puede acceder desde su terminal y consultar reportes de diferentes servicios y esta se
muestra en un solo reporte. Se muestra información integral. Por ejemplo:
Estado de paciente diabético
18

Cantidad de insulina suministrada (procede de farmacología)
Nivel de glucosa en sangre (procede de laboratorio clínico )
EJEMPLO DE UNA ARQUITECTURA HIS.
Ya se había mencionado el aspecto relacionado con las normas de codificación y comunicación de la
información para que los diferentes sistemas puedan entenderse entre si. Ahora se vera un ejemplo de una
arquitectura estándar creada por la Comunidad Económica Europea (CEE) para un HIS. Está diseñada de
manera tal que no dependa de las aplicaciones. Es decir, cualquier desarrollo de una aplicación determinada
solo debe saber las capas y protocolos de comunicación además de la forma en que esta estructurada la base
de datos.
La norma en cuestión es CEN/TC 251 pr/ENV 12977-1 y se llama “Arquitectura estandar para un Sistema
de Información de Salud” y cumple con los requerimientos antes expuestos mediante las tres capas o
niveles que se explican a continuación (ver figura 4 del anexo 1):
Aplicaciones: Conjunto de aplicaciones responsables de interactuar con los usuarios. Su función es proveer
un apoyo para que se realicen todas las funciones en los diferentes sectores de una institución de salud.
“Middleware”: Provee un grupo de servicios los cuales aseguran una gestión de aquellos datos y/o
procedimientos de relevancia comunes a toda la institución.
“Bitways”: Plataforma tecnológica necesaria para que diferentes aplicaciones y sistemas operativos
interactuen entre si.
Con respecto al Middleware la norma CEN/TC 251 pr/ENV 12977-1 identifica los siguientes tipos de
servicios (Servicio Comunes de Salud (HCS)):
HCS relativos a los
servicios a pacientes:
HCS relativas a las
actividades:
Responsable de proveer los servicios de salud a pacientes,
definiendo y manejando datos personales, administrativos y
epidemiológicos y otros asuntos de cuidado, estableciendo los
casos y sus relativos contactos con los especialistas médicos.
Responsable de proveer servicio definiendo y manejando el
información relativaciclo de vida de actividades que realizó el
paciente en la organización de salud, desde la demanda de la
inicial, a la planificación, la ejecución y reporte del resultado
final.
HCS de Especificaciones: Responsable por proporcionar y manejar los datos de salud y
características sobre determinados aspectos que requieren más
atención
19

HSC relativo a los recursos:
HCS de autorización e
identificación de usuarios :
Responsable por proporcionar y manejar los datos relativos a los
recursos de la organización de salud
Responsable de proveer los servicios de identificación y
autorización a usuarios a operar con los datos, procedimientos,
etc.
HCS de conceptos Responsable por mantener servicios definiendo y manejando las
reglas y propiedades que involucran al acceso de diferentes tipos
de datos.
La ventaja fundamental que trae este tipo de arquitectura es su modularidad y apertura al desarrollo de
nuevos módulos y servicios, además otra ventaja es la independencia de las aplicaciones de los datos, ya que
estos últimos pueden ser accesados desde cualquier modulo. Ya que los datos se tratan como una base
común de información que pude ser heredada de las aplicaciones.
Ejemplo de un HIS.
La materialización de la arquitectura estándar CEN/TC 251 pr/ENV 12977-1 se realizó a través del
Ambiente Distribuido de Salud (DHE). A través del DHE la información puede ser actualizada, introducida y
recuperada a través del grupo de servicios que ofrece la arquitectura estándar expuesta anteriormente.
Mediante el DHE se puede accesar a la siguiente información:
• Datos personal, estadísticos y epidemiológicos de pacientes.
• Actividades clínicas y organizativas durante el ciclo completo de estancias de pacientes en la institución
de salud.
• Recursos de la institución de salud (medicamentos, personal, materiales, piezas de repuesto,
equipamiento, localización así como su relación con la actividad dirigida al paciente)
• Datos sobre el estado de salud de pacientes, así como los resultados de las actividades tanto individuales
como integrales realizadas por pacientes en la organización de salud; lográndose así un registro de
pacientes longitudinal.
• Clasificaciones de decisiones administrativas, clínicas y de diagnostico.
• Gestión de información relativa al presupuesto y la utilización de recursos humanos y financieros, costos
de indicadores de funcionamiento para diferentes áreas de la institución, así como para la institución
como un todo.
Cada aplicación desarrollada para UNIX o WINDOWS deben conectarse con el DHE. Los Sistemas de
Gestión de Bases de Datos preferidos son: ORACLE, INFORMIX y MICROSOFT SQL-SERVER
Por último es necesario destacar que esta arquitectura explicada aquí, así como el DHE ha sido aplicada en
más de 20 hospitales de Europa a través del grupo y proyecto HANSA, mostrando excelentes resultados[41]
20

1.4 FUNDAMENTOS DE LA ELECCIÓN DE LA HERRAMIENTA DE PROGRAMACIÓN.
Publicaciones en Internet [http://www.oracle.com/tellmemore/?198762, Gartner´s Dataquest] plantean que
Oracle es el lider No.1 de software de gestión de bases de datos en el mundo. Después de tres años de
explotación del Sistema de Bases de Datos para Internet de Oracle, Oracle8 ha tenido un crecimiento en
ventas en el mercado que alcanzó casi los $8 billones de USD en 1999.
El 4 de mayo del 2000 REDWOOD SHORES emitió un reporte (www.oracle.com/tellmemore/?198762)
Oracle Corp. (NASDAQ: ORCL), donde se evidenció que Oracle es el mayor proveedor de software para el
dominante mundo de los negocios electrónicos (e-business). Oracle ha sostenido la primacía durante los
últimos tres años, según el informe anual realizado en el 1999 por Dataquest. Dataquest, una unidad de
Grupo de Gartner, Inc. (NYSE: IT e ITB), expuso sus hallazgos, citando un 18 % de aumento de las
licencias para sistemas de bases de datos más que en 1998, debido al crecimiento de nuevas aplicaciones de
Internet y las nuevas exigencias de las aplicaciones para propósitos comerciales.
Oracle obtuvo un crecimiento en ventas de sistemas de gestión para bases de datos para UNIX y ahora
abarca el 63% en este mercado. Oracle también llevó a cabo desarrollos de sistemas de bases de datos para
Windows NT en un 40%. Las ventas de ambos alcanzaron un valor aproximado de $4.4 billones en 1999.
Además de los estudios de Dataquest realizados en 1999 sobre los resultados de ventas en el mercado,
también se obtuvieron resultados en los estudios realizados por las Corporaciones Techtel y SoundView, los
cuales indican que Oracle continuará llevando el liderazgo en el mercado de los sistemas de gestión de bases
de datos. Las conclusiones de una encuesta realizada por Corporation Techtel fueron: que para el primer
cuarto del año 2000 aumentará la demanda para todos los Sistemas de Gestión de Bases de datos de Oracle
en todas las categorías. Estos hallazgos indican que Oracle tiene más demanda que Microsoft SQL Server en
el mercado comercial. En otro estudio realizado a ejecutivos y gerentes, por SoundView, se encontró que
Oracle está sin lugar a dudas delante de todos sus más cercanos competidores, aproximadamente cinco veces.
Más de 17,000 clientes han comprado Oracle8i, convirtiéndolo en el sistema de gestión de bases de datos que
con mayor rapidez ha sido adoptado en la historia de Oracles. Desde Marzo de 1999 hasta la fecha los
miembros de Red de Tecnología de Oracle han distribuido más de 500,000 copias de Oracle8i , de estas
200,000 han sido para desarrollar aplicaciones para el sistema operativo de LINUX.
Durante la realización de la encuesta “Mundo Abierto de Oracle” en noviembre de 1999, se encuestó a 4,000
personas entre diseñadores, gerentes de tecnologías en comunicaciones y administradores de sistemas de
gestión de bases de datos para determinar los usos más populares y rasgos distintivos de Oracle8i. El 79% de
los encuestados desarrollan aplicaciones de Internet con Oracle8i y utilizan o planean adoptar, de forma
inmediata, Java y XML. Específicamente, más del 50% de usuarios inspeccionados por Oracle8i, escogieron
para su desarrollo Java, y 57% planea usar XML en el próximo año para una variedad de aplicaciones,
incluso para el desarrollo de sistemas para negocios e integración de sistemas. Globalmente, el 95% de los
encuestados ha desplegado o ha estado evaluando Oracle8i.
El 100% de los diez sitios web que más facturan en el modelo “Negocios para el consumidor” utilizan
tecnología Oracle , según una publicación llamada Collaborative Research, en Octubre de 1998
21

Nueve de los diez sitios web (90%) “top Business to Business” utilizan Oracle, con IBM como su única
excepción según una publicación llamada “Collaborative Research” en Octubre de 1998
Los clientes Oracle se encuentran entre las 20 primeras compañías del índice http://www.thestreet.com/
Siete de los diez sitios web europeos(70%) más poderosos, identificados por la Escuela de Economía de
London, utilizan el software Oracle.
Las diez primeras compañías de las naciones del área Asia-Pacífico utilizan tecnología Oracle según el
estudio realizado por la “Far Eastern Economic Review's 2000”
Sesenta y cinco empresas de las “Fortune 100” (65%) utilizan el software Oracle para manejar sus
operaciones en e-business. En industrias específicas tales como la Aerospacial, Comunicaciones, Seguros y
Químicos, Oracle demostró su liderazgo.
Comparación entre las licencias de Oracle y SQL Server
A partir de datos obtenidos en los sitios Web de Oracle y SQL server respectivamente, podemos establecer el
siguiente análisis:
Licencia Precio (USD)
Para 5 usuarios 1,399.00
conectados al servidor
Para 10 usuarios
conectados al servidor
Para 25 usuarios
conectados al servidor
1,999.00
3,999.00
Tabla 3. Licencias de SQL Server.
.
22
Licencia Precio (USD)
Por usuario (Precio por usuario)* 7
conectado a un
= 4200
Servidor Precio por usuario=600
Datos seleccionado de la
pagina web de Oracles
el día 22/06/2000
Tabla 4 Licencias de Oracle.

Licencias de Oracle
Número de Servidores = 1
Número Procesadores = 1
Número MHz = 333
Unidades de potencia = Número Servidores * Número Procesadores * Número MHz = 333
Mínimo de usuarios por Licencia = Unidades de potencia / 50 = 333 / 50 = 6,6 � 7
Sólo se tomaron las variantes más económicas de ambos. Y se decidió hacer las comparaciones entre
estos dos servidores de base de datos, por ser estos los primeros en el mercado internacional y ocupar
más del 70 % de las aplicaciones de este tipo.
Es cierto que los costos en los que se incurrirán por la decisión de Oracle es relativamente mayor con
respecto a SQL Server. Aquí se tuvieron en cuenta las estadísticas internacionales, las que indican que
para una base de datos mediana, la mejor opción es SQL Server, pero para una base de datos grande
sin dudas la elección optima es Oracle.
La base de datos del Sistema de Gestión Tecnológica está considerada como grande, pues la misma
almacena una gran cantidad de información proveniente de los tres módulos que conforman el Sistema
de Gestión Tecnológica: Sistema de Mantenimiento Orientado a Riesgo (SMACOR), Sistema de
Adquisición de Tecnología (SADTEC) y Sistema de Gestión de Almacén (SGA). El sistema almacena
y procesa información, como por ejemplo: Planificación del mantenimiento, órdenes de trabajo,
equipos médicos, grupos, genéricos, modelos, procedimientos, evaluaciones, surtidos, entre otros. Si
tomamos como ejemplo la base de datos en un hospital con 2000 equipos, tres intervenciones anuales
como promedio por equipo, una cantidad de surtidos en el almacén que puede superar los 5000
teniendo en cuenta los movimientos de inventario que esto pueda acarrear, la cantidad de
intervenciones llevadas a cabo por entidades externas, la gestión de las evaluaciones para la compra,
que puede superar las 100 en el año, entre otros aspectos y además adicionamos 5 años de explotación
del sistema en la institución, esta podría alcanzar un tamaño de unos 4 Gbytes. También se prevé que
el sistema en su totalidad se encuentre instalado en un sistema multihospitalario. Por ejemplo solo en
Cuidad de la Habana existen aproximadamente 200 instituciones de Salud, si se estima que existan por
lo menos 30 estaciones de trabajo en cada uno de los servicios de mayor importancia en cada una,
pueden existir hasta 6000 usuarios conectados accesando a un volumen de datos similar al calculado
mas arriba.
Oracle Server 8.05 presenta grandes adelantos en términos de desempeño, confiabilidad y
escalabilidad, lo que brinda a su organización múltiples oportunidades de crear soluciones de negocios
inteligentes y realistas. Las organizaciones que utilizan Oracle Server propiciaron el desarrollo de las
siguientes innovaciones, al expresar la necesidad de soluciones más simplificadas y económicas:
• Marco de trabajo para data warehouse.
• Servidor OLTP.
• Autoadministración dinámica.
• Soporte terabyte.
• Opciones de réplica.
• Tecnología objeto relacional
• Tablas organizadas por índice
• Subsistema de resguardo y recuperación extendido
• Grandes poblaciones de usuarios
23

• Nuevos tipos de disparadores, el disparador Instead of
Nuevos tipos de disparadores, el disparador Instead of
Permite actualizar vistas complejas, reemplazando las operaciones de insert, delete y update con la
lógica descrita en la propia vista. Además puede definir subconsultas dentro de consultas sin realizar
operaciones de unión y sin especificar expresiones complejas en la cláusula from.
Data warehouse.
Procesamiento de consultas estrellas mejoradas. En esta versión del servidor un nuevo método para la
ejecución de estas consultas se ha incluido, usando un algoritmo más eficiente e índices de mapa de
bits. El nuevo procesamiento de consultas estrellas provee un salto significativo en el desempeño de las
aplicaciones Data warehouse.
Debido a las innovaciones incluidas en Oracle server 8.05, la información en todos los niveles de una
organización pueden fluir, sin que esto represente altos costos. Oracle ha tenido presentes los sistemas
data warehousing al planear su más reciente versión de Oracle Server, ya que las empresas de todos los
tamaños hacen grandes inversiones en sus datos.
Marco de trabajo para data warehouse.
La nueva versión introduce esta característica. Con la misma se asegura que las soluciones para data
warehouse sean interoperables y redituables. Las herramientas para data warehouse que usted
construya y diseñe trabajarán con un conjunto de interfaces de programación incluidas en Oracle server
8.05. Además, este marco de trabajo complementa la integración del producto a través de otros
servicios, mejoras y alianzas con socios de negocio.
Servidor OLTP:
Grandes poblaciones de usuarios
Oracle soporta decenas de miles de usuarios concurrentes, vínculos compartidos de base de datos,
multiplexan muchos usuarios al servidor con una sola conexión reduciendo los requerimientos de
recursos. Automáticamente elimina conexiones físicas para usuarios inactivos y de manera inadvertida
para estos. Se reactiva cuando estos renuevan su conexión.
Subsistema de resguardo y recuperación extendido
Automáticamente controla la posición donde los ficheros son almacenados y en caso de fallos,
determina todos los pasos necesarios para que sean recuperados. Provee resguardos incrementales
multiniveles para reducir el tamaño de las salvas, debido a que solamente los bloques modificados son
guardados.
Autoadministración dinámica.
En Oracle 8.0, una característica clave llamada “Autoadministración dinámica” automatiza muchas
tareas de rutina. Con esta los recursos de memoria y bloqueo se ajustan en forma dinámica; el tamaño
de los archivos crece automáticamente, y las características de autorregulación garantizan un
24

desempeño constante bajo condiciones de carga variables. Cumple con la certificación estándar de
seguridad X.509 de autenticaciones de llaves públicas - privadas.
Desempeño, confiabilidad y escalabilidad.
Oracle toma en cuenta el costo total de propiedad que representa para las organizaciones el desarrollo
de aplicaciones, la capacitación en ellas y su administración. El está diseñado para recibir con facilidad
un mayor número de datos, transacciones y usuarios. Además, permite escalar las aplicaciones de bases
de datos, conservando la estabilidad.
Soporte en terabytes.
Con Oracle, se amplían las aplicaciones que puede usar su organización para recibir terabytes de datos
y miles de usuarios.
Tecnología objeto relacional:
Dentro de las facilidades que posee esta nueva forma de tecnología están:
• Vistas y tipos de objetos
• Llamada a procedimientos externos desde el interior de la base de datos
• Soporte de objetos para la capa cliente
• Herramientas para la modelación de objetos
• Datos multimedia
• Java
Internet, intranet y comercio electrónico
Las aplicaciones de punta que se pueden construir con él y su integración con Windows NT, UNIX,
LINUX, etc hacen de Oracle un factor vital en cualquier estrategia de Internet, intranet y de comercio
electrónico.
Oracle ofrece además herramientas de desarrollo para las aplicaciones clientes. Entre estas tenemos el
llamado Developer 2000.
Las ventajas de utilizar Developer 2000 como herramienta de desarrollo para las aplicaciones clientes
son:
• Implementa un motor de PL/SQL en el cliente. Cualquier trabajo que se haga en el cliente reduce la
carga del servidor. Esto implica que si muchos usuarios están ejecutando la aplicación
simultáneamente, pueden procesar en paralelo en sus máquinas clientes individuales sin recargar al
servidor. Un ejemplo de uso práctico de este motor lo vemos en la validación de los datos de
entrada. Esto es posible porque las aplicaciones desarrolladas con las herramientas de Oracle
instalan el motor PL/SQL, el cual se encarga del preprocesamiento de las ordenes PL/SQL y las
envía de forma minimizada y unidas al servidor.
• Evita análisis innecesarios. Cuando una orden SQL o un bloque PL/SQL se envía del cliente al
servidor, el cliente puede mantener una referencia a la orden analizada. Esta referencia es el área de
datos del cursor cuando se usa la OCI (Oracle Communication Interface) o la entrada a la caché de
cursor cuando se utilizan los precompiladores. Si la aplicación ejecuta más de una vez la misma
25

orden, sólo es necesario que se analice la primera vez. Para las siguientes ejecuciones puede
utilizarse la orden original analizada, posiblemente, con valores diferentes para las variables de
asignación. La manera más obvia para aplicar directamente esta técnica en PL/SQL es con el
paquete DBMS_SQL, en el que la interfaz es similar a la OSI de la ISO.
• La interfaz de arreglos de Oracle permite enviar a la red grandes cantidades de datos como una
unidad, en lugar de hacer varios viajes. Por ejemplo, si está recuperando 100 filas, puede hacerlo
en una extracción que obtenga las 100 filas, en lugar de hacer 100 extracciones obteniendo una fila
cada vez.
Como se ha visto, estas ventajas redundan en un menor tráfico por la red, que es un componente
fundamental para el ajuste de aplicaciones. De hecho, en la mayoría de las aplicaciones la mayor parte
del tiempo de procesamiento se invierte en transmisiones por la red.
Por todo los elementos antes expuestos se elige a Oracle como servidor de bases de datos y al
Developer 2000 como herramienta de desarrollo para las aplicaciones clientes.
26

CAPÍTULO # 2 DESCRIPCIÓN Y CONCEPCIÓN DEL SISTEMA DE GESTIÓN
TECNOLÓGICA HOSPITALARIA.
Se propuso un modelo de flujo de información relacionada a un departamento de Ingeniería Clínica. Se
tuvo en cuenta la situación más compleja posible, con el objetivo de generalizar y que los casos más
sencillos fueran casos particulares del modelo general. En concreto: el sistema será capaz de brindar
sus prestaciones en un sistema inter-hospitalario, es decir, varios hospitales, con varios departamentos
asociados a éstos. De cada servicio, los usuarios y directivos pueden solicitar información al
departamento de Ingeniería Clínica relacionado con: el asesoramiento sobre compras de equipos o
suministros, entrenamientos, servicios correctivos y preventivos, investigaciones sobre accidentes
ocurridos, pero además, solicitan comportamiento del resultado, de las actividades del personal del
departamento de Ingeniería Clínica con los equipos, resultados de evaluaciones de equipos, etc. Por su
parte, los especialistas técnicos pueden actualizar sus actividades a través de cualquier departamento.
Se han considerado tres niveles en cuanto a la interacción entre el sistema y los demandantes de
información :
• Los generadores de eventos que producen entradas el sistema; éstos pueden ser usuarios de la
tecnología, directivos o especialistas técnicos.
• El procesamiento y clasificación de información en la base de datos (procesamiento).
• Las salidas o reportes a los generadores de eventos.
En la figura 1, el modelo se muestra mediante un ejemplo (Sistema de mantenimiento). Pero que es
aplicable a todos los subsistemas.
27

Figura 1 Modelo de interrelación de eventos
Módulos que componen el sistema
El sistema estará conformado por los siguientes módulos:
SMACOR (Sistema de Mantenimiento Asistido por Computadoras Orientado a Riesgos)
Un sistema de Mantenimiento Asistido por Computadoras para equipos médicos orientado a riesgo: La
función de este sistema es automatizar el mantenimiento en una red hospitalaria o en un hospital
individual. Este será capaz de planificar el mantenimiento preventivo y las inspecciones, de manera
anual, mensual, semanal; de llevar el control del inventario de todo el equipamiento, de emitir órdenes
de trabajo preventivas y correctivas. Genera documentos tales como: procedimientos de
mantenimientos, pruebas de aceptación, entre otros; además de facilitar los tediosos cálculos de
indicadores técnico-económicos y de eficiencia de la gestión [4,5,6,7]. Tiene un algoritmo incorporado
el cual, en todo momento permite saber: el Historial de un equipo, causas de la parada, probabilidades
de supervivencia y falla, tiempos de operación entre arranque y parada, tiempos medios entre fallas,
28

fuera de servicio y disponibilidad total, parámetros de Weibull (tiempo de corrida característico «V»,
factor «K», desviación standard del tiempo medio entre fallas, razón de fallas).
El sistema esta diseñado para que trabaje según la filosofía cliente/servidor, es decir cualquier usuario,
si tiene permiso, puede, desde una estación de trabajo: actualizar información que proviene del
resultado de la realización de los trabajos de mantenimiento, solicitar reportes de servicios y consultar
los reportes sobre el estado del equipamiento.
SGA (Sistema de Gestión de Almacenes)
Existe una estrecha relación entre la gestión de mantenimiento y la gestión del almacén, ya que debe
mantenerse el control de existencias y reponerse los productos en el almacén sobre una base
máxima/mínima y controlar las salidas por órdenes de trabajo para así calcular los costos; por tanto, se
desarrolló un Sistema de Gestión y control de almacenes (SGA). Con el objetivo de llevar el control de
las cuestiones antes descritas, también está desarrollado según la filosofía cliente/servidor, es decir
cualquier usuario desde cualquier estación, si tiene permiso, tendrá posibilidades solamente de
consultar las existencias de sus productos en los almacenes , las entradas y salidas y el destino de cada
salida, entre otros aspectos.
Existe un enlace muy importante entre SMACOR y SGA: SGA consulta a SMACOR para conocer la
necesidad de stocks en el año y hacer la gestión de compras; por otra parte, SMACOR consulta SGA
para conocer el resultado de dicha gestión , las salidas de stocks que fueron en órdenes de trabajo y los
niveles de máximo/mínimo de existencias. De aquí se desprende que ambas aplicaciones pueden
comportarse como clientes/servidoras según sea el caso.
Si en el análisis que hace SMACOR de la información relacionada con un equipo, se encuentra que el
costo de mantenimiento es mucho mayor que el costo de adquisición, o existe aumento de la razón de
fallas, o aumenta la probabilidad de fallo, el usuario puede pedir que se evalúe la posibilidad de
reposición del equipo. Para la reposición de equipos, se diseñó un producto informático llamado
SADTEC (Sistema de adquisición de nuevas tecnologías asistido por computadoras) para asistir en este
proceso a los ingenieros y directivos.
SADTEC (Sistema de adquisición de nuevas tecnologías asistido por computadoras)
Este sistemas asiste a los especialistas realizando las siguientes funciones: selección del Fabricante y/o
proveedor y del producto “ ideal ”, Comportamiento de los Costos del Producto seleccionado mediante
el llamado: Costo del ciclo de vida del mismo, tomas de decisiones en cuanto a adquirir un equipo
frente a rentarlo, establecimiento de las condiciones del contrato de servicios, monitoreo de las
actividades de los servicios contratados a los fabricantes y selección frente a diferentes alternativas de
servicios a contratar. Mediante una interfaz en el servidor cliente, los usuarios podrán realizar
evaluaciones de productos y proveedores y consultar el resultado de las mismas, monitorear las
condiciones e contratos, entre otras facilidades.
Existen puntos de enlaces entre SMACOR, SADTEC y SGA siendo SADTEC el punto central entre los
restantes. Por un lado SMACOR descubre cuando no es rentable mantener a un equipo. Para eso entre
otras cosas, SMACOR consulta información en SADTEC referente al costo de ciclo de vida del
equipamiento, evaluaciones del mismo, recomendaciones, etc. Al realizar esto, le entrega a SADTEC la
necesidad de comprar un dispositivo de determinada prestaciones. SADTEC evalúa entonces y entrega
a SMACOR equipo y fabricante “ideal”, costo de ciclo de vida, tipo de servicio a elegir y si es
contratado externamente, las posibles condiciones y variables a monitorear. Similarmente ocurre entre
SGA y SADTEC
29

Esbozo de la arquitectura del sistema
En la figura 2 se ofrece un esquema que muestra la arquitectura del SGT así como las aplicaciones que
forman este paquete informático. Primeramente, se contará con una estación central donde existirá una
base de datos, la cual hará función de servidor y dónde se tendrá toda la información relacionada a:
datos generales sobre la institución de salud, equipos y piezas de repuestos, equipos genéricos,
modelos, marcas, firmas, accidentes, fallos, equipos unitarios, fabricantes, procedimientos de
mantenimientos, etc.
Luego SMACOR, SADTEC, SGA, etc. serán clientes de la información genérica que se encuentra en
esta estación o servidor, pudiéndose actualizar la base de datos central al existir un nuevo equipo y
pieza de repuesto genérico, modelo, marca, firma, accidente, fallo, etc.
Cada una de las aplicaciones independientes por su parte, son estaciones servidores, ya que, desde
cualquier estación de trabajo, se tendrá acceso a actualizar/consultar datos, pero a su vez, estas se
comportan como clientes, ya que, pueden ofrecer información de a las demás aplicaciones. Por
ejemplo, en el caso de SMACOR, es servidor, ya que desde cualquier estación de trabajo se puede
accesar la información referente al resultado de los trabajos de mantenimiento; además de consultar los
reportes sobre la gestión del mantenimiento, pero a su vez es cliente ya que consulta a SGA el resultado
de la gestión de compras de piezas de repuesto.
30

Figura 2 Esquema de SGT
En la figura 3 se observa un diagrama cero donde se muestra la interrelación de los diferentes módulos
con la base de datos que son compartidos entre ellos.
31

Sistema de
Mantenimiento
Orientado a
Riesgo
Plan
Consumo
Area
Eventos de este módulo
Cuenta
Proveedor
Unidad Medida
Surtido
Fabricante
Orden Trabajo
Genérico
Modelo
País
Sistema de
Gestión de
Almacén
Figura 3 Diagrama Cero del Sistema de Gestión Tecnológica.
32
Equipo
Eventos de este módulo
Centro Costo
Eventos de este módulo
Sistema de
Adquisición de
Tecnología
Consumo Real

CAPÍTULO # 3 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE
MANTENIMIENTO ASISTIDO POR
COMPUTADORAS ORIENTADO A RIESGO
(SMACOR).
3.1 DESCRIPCIÓN DEL OBJETO DE AUTOMATIZACIÓN
Sistema de Mantenimiento Asistido por Computadoras para equipos médicos
orientado a riesgo: La función de este sistema es automatizar el mantenimiento en
una red hospitalaria o en un hospital individual. Este será capaz de planificar el
mantenimiento preventivo y las inspecciones, de manera anual, mensual, semanal; de
llevar el control del inventario de todo el equipamiento; de emitir órdenes de trabajo
preventivas y correctivas. Genera documentos, tales como: procedimientos de
mantenimientos, y pruebas de aceptación, entre otros, además de facilitar los tediosos
cálculos de indicadores técnico - económicos y de eficiencia de la gestión. Se realiza
una llamada a la herramienta MATLAB con el objetivo de conocer: probabilidades
de supervivencia y falla, tiempos de operación entre arranque y parada, tiempos
medios entre fallas, fuera de servicio y disponibilidad total. Parámetros de Weibull
(tiempo de corrida característico «V», factor «K», desviación standard del tiempo
medio entre fallas, razón de fallas).
33

3.2 TABLA DE EVENTOS
Sistema de Mantenimiento Asistido
por Computadoras Orientado a
Riesgo (SMACOR)
No Evento Origen Destino Documento
1 Adquisición de
un equipo
médico
2 Rotura de un
Equipo
3 Fin de Orden de
Trabajo
Correctiva
34
Tabla de Eventos
Proveedor
Entrada
Ficha del Equipo
Fecha:
20/06/2000
Documento
Salida
Cliente Reporte
Avería
de
Técnico Orden de Trabajo
Correctiva
Técnico Resultados de la
Reparación
4 Nuevo Proveedor Proveedor Datos del
Proveedor
5 Nuevo Modelo Proveedor Datos del
Modelo.
6 Nuevo Genérico Departamento de
Ingeniería
Clínica
7 Nuevo Grupo Departamento de
Ingeniería
Clínica
8 Nuevo Técnico Departamento de
Ingeniería
9 Necesidad de
Conocer
Cantidad de
Intervenciones
10 Necesidad de
Conocer
Duración de las
Intervenciones
11 Necesidad de
Conocer Tiempo
Promedio de
Respuesta
12 Necesidad de
Conocer Tiempo
de Cambio
Estado Promedio
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Procedimiento.
Datos Genérico
Datos Grupo.
Procedimiento.
Datos Técnico
Cantidad
Intervenciones
Duración de las
Intervenciones
Tiempo
Promedio de
Respuesta
Tiempo de
Cambio Estado
Promedio

13 Necesidad de
Conocer
Consumo de
Surtidos
14 Necesidad de
Conocer
Cumplimiento
del Correctivo
15 Necesidad de
Conocer Horas
Totales de
Correctivo
16 Necesidad de
Conocer
Solicitudes
Verdaderas de
Correctivo
17 Necesidad de
Conocer
Cantidad de
Equipos Fuera de
Servicio
18 Necesidad de
Conocer
Utilización
Técnica del
Hospital
19 Necesidad de
Conocer
Utilización del
Parque de
Equipos
20 Necesidad de
Conocer
Utilización del
tiempo de los
técnicos
21 Necesidad de
Conocer Listado
de Proveedores
22 Necesidad de
Conocer Listado
de Equipos
23 Necesidad de
Conocer
Expediente del
equipo
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
Departamento
de Ingeniería
Clínica
35
Consumo de
Surtidos
Cumplimiento
del Correctivo
Horas Totales de
Correctivo
Solicitudes
Verdaderas de
Correctivo
Cantidad de
Equipos Fuera de
Servicio
Utilización
Técnica del
Hospital
Utilización del
Parque de
Equipos
Utilización del
tiempo de los
técnicos
Listado de
Proveedores
Listado de
Equipos
Expediente del
equipo

24 Necesidad de
Conocer Listado
del Personal
Departamento
de Ingeniería
Clínica
36
Listado del
Personal

3.3 DIAGRAMA DE CONTEXTO EXTRUCTURADO DEL SMACOR
Técnico
13
11
15
14
12 10
Departamento de Ingeniería Clinica
8
3
18
2.1
7
20
21
Gestión
Tecnológica en un
Sistema de
Información
Hospitalaria
37
22
6
17
5.1
16
8
5
7.1
4
23
2
1
9
19
24
Cliente
Proveedor

Flujos de datos:
1 Ficha del Equipo
2 Reporte de Avería
2.1 Orden de Trabajo Correctiva
3 Resultados de la Reparación
4 Datos del Proveedor
5 Datos del Modelo
5.1 Datos del Procedimiento del Modelo
6 Datos Genérico
7 Datos Grupo
7.1 Datos del Procedimiento del Grupo.
8 Datos Técnico
9 Cantidad Intervenciones
10 Duración de las Intervenciones
11 Tiempo Promedio de Respuesta
12 Tiempo de Cambio Estado Promedio
13 Consumo de Surtidos
14 Cumplimiento del Correctivo
15 Horas Totales de Correctivo
16 Solicitudes Verdaderas de Correctivo
17 Cantidad de Equipos Fuera de Servicio
18 Utilización Técnica del Hospital
19 Utilización del Parque de Equipos
20 Utilización del Parque de Equipos
21 Listado de Proveedores
22 Listado de Equipos
23 Expediente del equipo
24 Listado del Personal
38

3.4 DIAGRAMA PRELIMINAR DEL SMACOR
Ficha del equipo
Período
Análisis
Listado
Personal
Período
Análisis
Expediente
Equipos
Listado
Equipos
Período
Análisis
Listado
Proveedores
Período
Análisis
Período
Análisis
Utilización
Tiempo
Técnicos
Período
Análisis
24
23
22
21
20
Utilización
del Parque
de Equipos
Utilización
Técnica
del Hospital
Reporte de
Avería
Período
Análisis Cantidad Equipos
Fuera Servicio
Período
Análisis
Orden de Trabajo
Correctiva
Resultados
Reparación
Período
Análisis
39
Datos
Proveedor
HorasTotales
de Correctivo
Datos
Modelo
Procedimiento
1 2 3 4 5 6
19
PERSONAL
GRUPO
AVERIA
CONSUMO
PROCEDIMIENTO
Período
Análisis
Cumplimiento
Correctivo
Datos
Genérico
18 17 16 15 14 13
Solicitudes
Verdaderas
Correctivo
PROVEEDOR
OT
EQUIPO
MODELO
GENERICO
PROCEDIMIENTO GRUPO
7
8
10
Período
Análisis
9
11
Procedimiento
12
Datos Grupo
Datos Técnico
Período
Análisis
Cantidad de
Intervenciones
Período
Análisis
Duración
Intervenciones
Período
Análisis
Tiempo Promedio
Respuesta
Período
Análisis
Tiempo Cambio
Estado Promedio
Período
Análisis
Consumo
Surtidos

3.5 FACTIBILIDAD ECONÓMICA
I = CTP + Ibasicas + Cprep
Ibásica = 120 USD
HUB (100 USD)
UTP (20 USD)
Cprep = $ 300
Un curso para el jefe de ingeniería clínica del departamento de electromedicina de un
mes.
Un curso para el operador del sistema, un mes
CTP = $16540.5
I = $16540.5
I = 120 USD
La inversión del proyecto sería de 16540.5 pesos y 120 USD.
3.6 PLANIFICACIÓN DEL PROYECTO
El modo de desarrollo de este sistema, teniendo en cuenta las características
particulares de cada una de las personas que conforman el equipo de trabajo, así como
su anterior participación en el desarrollo del SMACOR: lo considero Semilibre.
ESF = 3 (MF) 1.12
F = 420 * FDS/S = 420 * 25 = 10500
MF = 10.5
ESF = 3 * (10.5) 1.12 = 41.77
CH = 2
TDES = ESF/CH = 40/2 = 20
TDES = 20
CTP = CHM * ESF
CHM = 2SP
SP = 2 * 198 = 396
CHM = 396
CTP = 396 * 41.77 = $16540.5
CTP = $16540.5
40

3.7 ANÁLISIS
3.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES NUEVO DIAGRAMA DE
CONTEXTO
Técnico
SGA
38
3
2.1
41
Departamento de Ingeniería Clinica
11
13
15
8
14 12 10 18
7
20
21
22
6
17
30
32
31
25
29
8
16
26
27
28
29
30
31
32
Gestión
Tecnológica en un
Sistema de
Información
Hospitalaria
33
Departamento de Ingeniería Clinica
41
34
35
36
37
39
5.1
7.1
2
1
4
5
40
42
23
43
9 24
19
Cliente
Proveedor
44

Flujos de datos:
1 Ficha del Equipo
2 Reporte de Avería
2.1 Orden de Trabajo Correctiva
3 Resultados de la Reparación
4 Datos del Proveedor
5 Datos del Modelo
5.1 Datos del Procedimiento del
Modelo
6 Datos Genérico
7 Datos Grupo
7.1 Datos del Procedimiento del Grupo
8 Datos Técnico
9 Cantidad Intervenciones Correctivas
10 Duración de las Intervenciones
Correctivas
11 Cumplimiento del Correctivo
12 Tiempo Promedio de Respuesta en
Correctivos
13 Tiempo de Cambio de Estado
Promedio en Correctivo
14 Costos en Correctivos
15 Consumo de Surtidos para
Correctivos
16 Horas Totales en Correctivos
17 Solicitudes Verdaderas
18 Eficiencia de Especialistas en
Correctivo
19 Cantidad de Intervenciones
Preventivas
20 Duración de Intervenciones
Preventivas
21 Cumplimiento del Plan
22 Tiempo Promedio de Respuesta en
Preventivo
23 Tiempo de Cambio de Estado
Promedio por Preventivo
24 Costos en Preventivos
25 Consumo de Surtidos en Preventivo
26 Eficiencia Especialista en
Preventivo
27 Utilización Técnica del Hospital
28 Utilización del Parque de Equipos
29 Costos Generales
30 Tiempo de Cambio Estado
Promedio General
42
31 Utilización del tiempo de los
técnicos
32 Utilización vs Eficiencia
33 Eficiencia del Departamento
34 Listado de Proveedores
35 Listado de Equipos
36 Expediente del equipo
37 Listado del Personal
38 Orden de Trabajo Preventiva
39 Plan de Intervenciones
40 Plan de Surtidos
41 Resultados de la Intervención
42 Probabilidades de Roturas
43 Niveles de Prioridades
44 Cantidad de Equipos Fuera de
Servicio

43
3.7.2 DIAGRAMA CERO
43
1
Actualización
de Datos
2
Mantenimiento
4
Indicadores
3
Listados
Proveedor
Genérico
Procedimiento
Averia
Procedimiento
Grupo
Equipo
Personal
Plan
Grupo
Modelo
OT
Consumo
Consumo
Real
1 2
2.1
3
4
5
5.1
6
7
7.1
8
38
39
40
41
42
34
35
36
37
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
44

3.7.3 DIAGRAMA UNO
8
1
1.6
Actualizar
Técnico
1.1
Actualizar
Equipo
7
1.5
Actualizar
Grupo
7.1
Personal
Equipo
44
Proveedor
Modelo
1.2
Actualizar
Proveedor
Grupo Procedimiento
Procedimiento Grupo
Genérico
4
1.4
Actualizar
Genérico
5
1.3
Actualizar
Modelo
6
5.1

3.7.4 DIAGRAMA DOS
2
3
Procedimiento
Consumo Real
Personal
2.2
Correctivo
2.1
41
OT
Avería
2.1
Preventivo
45
Equipo
38
Plan
43
42
2.3
Estado del
Mantenimiento
40
39
Modelo
Consumo

3.7.5 DIAGRAMA 2.1
2.1.1
Emitir Orden
Preventiva
Plan
Modelo
2.1.3
Obtener
Probabilidad
de Rotura
38 41
Procedimiento
Equipo
Consumo
Personal
42 43
46
2.1.2
Recibir
Resultados
de la
Intervención
OT
2.1.4
Obtener
Nivel de
Prioridad
Consumo Real
Avería

3.7.6 DIAGRAMA 2.2
Avería
2.2.2
Emitir
Orden
Correctiva
2
2.2.1
Recepcionar
Reporte de
Avería
OT
Personal
Equipo
Consumo Real
2.1 3
47
Modelo
2.2.3
Recibir
Resultados
de la
Reparación

3.7.7 DIAGRAMA 2.3
2.3.1
Planificar
Mantenimiento
Preventivo
39
Modelo
Procedimiento
Equipo
Consumo
Personal
48
Plan
OT
2.3.2
Obtener
Surtidos
Planificados
40

3.7.8 DIAGRAMA TRES
35
37
3.1
Obtener
Listado de
Equipos
3.3
Obtener
Listado de
Técnicos
Personal
Equipo
Consumo Real
49
Proveedor
Modelo
3.2
Obtener
Listado de
Proveedores
Genérico OT
34
36
3.4
Obtener
Expediente
del Equipo

50
3.7.9 DIAGRAMA CUATRO
4.1
Obtener
Informes
Preventivos
4.2
Obtener
Informes
Correctivos
4.3
Obtener
Informes
Generales
Genérico
Averia
Equipo
Personal
Plan
Modelo
OT
Consumo
Consumo
Real
19
20
21
22
23
24
25
26
18
17
16
15
14
13
12
11
10 9
44
31
32
33
27
28
29
30

3.7.10 DIAGRAMA 4.1
19 20 21
4.1.1
Emitir Informe
Cantidad de
Intervenciones
26
4.1.8
Emitir Informe
Eficiencia de
Especialista
Personal
Genérico
4.1.7
Emitir Informe
de Consumo
de Surtidos
25
Equipo
Consumo
Consumo
Real
4.1.2
Emitir Informe
Duración de
las
Intervenciones
Plan
4.1.6
Emitir Informe
de Análisis de
Costos
51
24
OT
4.1.3
Emitir Informe
Cumplimiento
del Plan
Modelo
4.1.4
Emitir Informe
Tiempo
Promedio de
Respuesta
4.1.5
Emitir Informe
Tiempo de
Cambio de
Estado
23
22

3.7.11 DIAGRAMA 4.2
9 10 11
4.2.1
Emitir Informe
Cantidad de
Intervenciones
18
4.2.10
Emitir Informe
Eficiencia de
Especialista
17
4.2.9
Emitir Informe
Solicitudes
Verdaderas
4.2.8
Emitir Informe
Horas Totales
de Correctivo
16
Personal
Equipo
Genérico
4.2.2
Emitir Informe
Duración de
las
Intervenciones
OT
4.2.7
Emitir Informe
Consumo de
Suridos
52
15
Averia
Modelo
Consumo
Real
4.2.3
Emitir Informe
Cumplimiento
del Correctivo
4.2.4
Emitir Informe
Tiempo
Promedio de
Respuesta
12
4.2.5
Emitir Informe
Tiempo
Cambio Estado
Promedio
13
4.2.6
Emitir Informe
Análisis de
Costos
14

3.7.12 DIAGRAMA 4.3
27 28 29
4.3.1
Emitir Informe
Utilización
Técnica
Hospital
44
4.3.8
Emitir Informe
Cantidad de
Equipos fuera
de servicio
Genérico
4.3.7
Emitir Análisis
de Eficiencia
del
Departamento
33
Equipo
4.3.2
Emitir Informe
Utilización del
Parque de
Equipos
Personal
53
Averia
OT
4.3.6
Emitir Análisis
de Utilización
vs Eficiencia
32
Modelo
4.3.3
Emitir Análisis
de Costos
Generales
4.3.4
Emitir Informe
Tiempo
Cambio Estado
Promedio
4.3.5
Emitir Informe
Utilización del
tiempo de los
técnicos
Consumo
Real
31
30

3.8 DISEÑO
3.8.1 GRAFO CONVERSACIONAL
7
19
12
8
11
1
20
22
9
21
13
23
10
14
24
2
15
16
25 26
54
0
17
3
32 33
27
34
28
29
5
39
40
30
18
41
42
6
31
43
35 36 37 38
4

47
70
32 33
44 45 46
71
72
73
48
40
74
0
75
51
60
76
49
77
61
68
62
55
52
69
78
63
50
39
0
64
79
34
53 55
54
56 57 59
58
80
65 66 67
81
41
0
82
83 84 85

3.8.2 ESTADOS
Número Descripción Español Estructurado
0 Estado Inicial
1 Archivo
2 Actualizar Datos
3 Mantenimiento
4 Listados
5 Indicadores
6 Ayuda
7 Cambiar Contraseña
8 Usuarios
9 Preparar Páguina
10 Salir
11 Areas del Hospital
12 Países
13 Proveedores 1.2
14 Fabricantes
15 Especialidades
16 Personal 1.6
17 Equipos
18 Tareas
19 Subdirecciones
20 Centros de Costo
21 Areas
22 Grupos 1.5
23 Genéricos 1.4
24 Fallos
25 Alimentaciones
26 Parámetros por Alimentación
27 Marca
28 Modelo 1.3
29 Unitario 1.1
30 Tipos de Tareas
31 Tareas
32 Mantenimiento Preventivo
33 Mantenimiento Correctivo
34 Ver Plan de ...
35 Listado de Equipos 3.1
36 Listado de Proveedores 3.2
37 Listado de Personal 3.3
38 Listado de Expedientes 3.4
39 Indicadores Preventivos
40 Indicadores Correctivos
41 Indicadores Generales
42 Ayuda Contenido
43 Ayuda Acerca de ...
44 Planificar 2.3.1
45 Ordenes de Trabajo
56

46 Intervenciones Pendientes
47 Generar Ordenes Preventivas 2.1.1
48 Modificar Ordenes Preventivas 2.1.2
49 Reporte de Avería 2.2.1
50 Modificar Orden Correctiva 2.2.3
51 Modificar Reporte de Avería
52 Modelos de Reporte de Avería
53 Plan de Intervenciones
54 Plan de Surtidos
55 Balance Carga Capacidad
56 Plan de Intervenciones Mensual
57 Plan de Intervenciones Anual
58 Plan de Surtidos Mensual
59 Plan de Surtidos Anual
60 Cantidad de Intervenciones Preventivas 4.1.1
61 Duración de Intervenciones Preventivas 4.1.2
62 Cumplimiento del Plan 4.1.3
63 Tiempo Promedio de Respuesta en Preventivo 4.1.4
64 Tiempo de Cambio de Estado Promedio por 4.1.5
Preventivo
65 Costos en Preventivos 4.1.6
66 Consumo de Surtidos en Preventivo 4.1.7
67 Eficiencia Especialista en Preventivo 4.1.8
68 Cantidad Intervenciones Correctivas 4.2.1
69 Duración de las Intervenciones Correctivas 4.2.2
70 Cumplimiento del Correctivo 4.2.3
71 Tiempo Promedio de Respuesta en Correctivos 4.2.4
72 Tiempo de Cambio de Estado Promedio en 4.2.5
Correctivo
73 Costos en Correctivos 4.2.6
74 Consumo de Surtidos para Correctivos 4.2.7
75 Horas Totales en Correctivos 4.2.8
76 Solicitudes Verdaderas 4.2.9
77 Eficiencia de Especialistas en Correctivo 4.2.10
78 Utilización Técnica del Hospital 4.3.1
79 Utilización del Parque de Equipos 4.3.2
80 Costos Generales 4.3.3
81 Tiempo de Cambio Estado Promedio General 4.3.4
82 Utilización del tiempo de los técnicos 4.3.5
83 Utilización vs Eficiencia 4.3.6
84 Eficiencia del Departamento 4.3.7
58 Cantidad de Equipos Fuera de Servicio 4.3.8
57

3.8.3 DISEÑO LÓGICO GLOBAL
Nombre del Descripción
Fichero Inicial
Alerta {Codigo + Nombre + Descrip + Umbral + Direcc}
Alertord {Alerta + Ot}
Aliment {Codigo + Nombre}
Alimod {Aliment + Modelo}
Aplazo {Codigo + Nombre + Descrip}
Aplazoor {Ot + Aplazo + Descrip}
Area {Codigo + Nombre + Descrip + Centcost }
Averia {Codigo + Ot + Solpor + Aprobpor + Unitario + Motivo + Horasol}
Brigada {Codigo + Nombre + Descrip}
Calific {Codigo + Nombre + Descrip}
Centcost {Codigo + Nombre + Descrip + Subdir}
Cliente {CI + Nombre + Descrip + Clasific}
Eqrelac {Unitario + Eqrelac}
Especial {Codigo + Nombre + Descrip}
Estadoeq {Codigo + Nombre}
Estplan {Unitario + Cadena + Fecha + Posicion}
Fabprov {Fabric + Proveed}
Fabrel {Fabric + Fabric1}
Fabric {Codigo + Nombre + Pais + Direcc + Telef + Fax + Email + Coment
+ Tipo}
Fallo {Codigo + Tipo + Nombre + Descrip + Especial}
Fallomod {Modelo + Fallo + Tiempo}
Generico {Codigo + Nombre + Descrip + Riesgo + Grupo }
Grupo {Codigo + Nombre + Descrip + Especial }
Interv {Codigo + Nombre + Descrip}
Intpend {Unitario + Intpend + Canthora}
Marca {Codigo + Nombre}
Modelo {Codigo + Nombre + Descrip + Generico + Marca + Inspmay +
Inspmen + Mtto + Entreint + Vida + Riesgo + Complej + Cantesp }
Modplan {Ot + Unitario + Interv + Fecha}
Optar {Ot + Tarea + Paso}
Orden {Codigo + Fechaini + Fechater + Durreal + Causa + Estadoeq +
Observ}
Ordfallo {Fallo + Ot}
Ot {Codigo + Unitario + Fechaem + Estado}
Pais {Codigo + Nombre + Descrip}
Paramali {Codigo + Nombre + Aliment}
Paramod {Paramet + Modelo + Valor}
Persbrig {CI + Brigada}
Persesp {CI + Especial}
Personal {CI + Nombre + Apellido + Calific + Foto + Curricul + Horas +
Salario + Tmcorr}
Procedim {Grupo + Tarea + Interv}
Proveed {Codigo + Nombre + Pais + Direcc + Telef + Fax + Email + Coment
+ Tipo}
58

Provrel {Proveed + Proveed}
Subdir {Codigo + Nombre + Descrip}
Surtgrup {Surtido + Grupo}
Surtmod {Surtido + Modelo + Cantmay + Cantmen}
Surtreal {Surtido + Ot + Cantidad}
Tarea {Codigo + Tipo + Descrip + Demodelo}
Tarmod {Modelo + Tarea + Interv}
Tecnord {Ot + Tecnico}
Tecnotr {Ot + Tecnico}
Tipotar {Codigo + Nombre}
Unitario Codigo + Modelo + Mtto + Entreint + Respons + Fechafab +
Fechaadq + Fechamar + Costoadq + Hwmes + Estadoeq + Priorid +
Tintme + Tintma + Serie + Basico + Cantesp + Garantia + Obligat +
Otroseq + Area + Contrat + Fabric + Proveed}
59

3.8.4 DER
Subdirección
Centro de Costo
Area
Tipo Tarea
Tarea
Intervención
Alimentación
Parámetros
Unidad Medida
Cuenta
Leyenda:
Surtido
Especialidad
Grupo
Modelo
Marca
Fallo
Relación de muchos a muchos
Relación de uno a uno
A
B
Genérico
Orden Terrminada
Orden de Trabajo
Aplazo
60
Personal
Equipo
Alerta
Relación de uno a muchos entre B y A respectivamente
Brigada
Calificación
País
Proveedor Fabricante
Avería
Cliente
Estado Equipo
Estado Orden
Plan

3.9 CONCLUSIONES
Por todo lo especificado en la documentación de este módulo y los beneficios que representa este
sistema para la gestión del mantenimiento de equipos médicos de un hospital, el mismo
constituye una importante herramienta para los directivos, usuarios(médicos, enfermeras) y
especialistas técnicos en las instituciones dedicadas a brindar servicios médicos. El sistema
brinda grandes ventajas pues se realiza toda la automatización del mantenimiento del
equipamiento médico, incluye también un sistema de reportes que permite controlar y evaluar las
actividades de mantenimiento, además de ofrecer al usuario una biblioteca con todos los
procedimientos de mantenimiento. Este sistema puede explotarse en cualquier institución de
salud que desee automatizar la gestión del mantenimiento de un departamento de
electromedicina.
61

CAPÍTULO # 4 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE
ALMACENES (SGA).
4.1 DESCRIPCIÓN DEL OBJETO DE AUTOMATIZACIÓN
Para la mayoría de las empresas, los inventarios son esenciales: se trata únicamente de saber que
cantidad mantener en el almacén. A la vista de diversas razones, políticas, financieras y
tecnológicas, que justifican el mantenimiento o no de un determinado nivel de inventario, un
sistema de dirección tiene como objetivo proporcionar a los directivos de la empresa una política
racional, que le ayudará a encontrar un equilibrio entre varios fines contradictorios. Por supuesto
que esto no significa que el sistema sustituya al dirigente. Pero en la práctica, el mecanismo debe
ser lo suficientemente flexible como para permitir a la empresa la formulación de objetivos
realistas, que tengan en cuenta las condiciones dadas en que transcurre el proceso de gestión,
incluyendo las premisas políticas, a las cuales se subordina cualquier decisión, y que, aunque no
cuantificable ni identificables a través de ninguna variable, deben ser incorporadas al sistema con
el fin de determinar la mejor alternativa en las circunstancias reales.
Así, el sistema de dirección de los inventarios debe ser capaz de hallar un equilibrio entre cierto
número de variables, por ejemplo:
Nivel de la demanda
Tamaño del pedido
Frecuencia de los pedidos
Además, debe tenerse en cuenta algunas constantes:
Capacidad máxima de almacenaje
Nivel de servicio previsto
De modo que determinados objetivos generales sean satisfechos. Esto es, el sistema:
Debe operar con recursos y gastos mínimos.
Debe garantizar la existencia en el almacén de los distintos renglones cuando estos sean
requeridos.
Debe ser controlable, auditable y confiable.
Usualmente, los objetivos del sistema de dirección se plantean en términos de la solución del
llamado problema de los inventarios. Este se formula más o menos así: Encontrar la cantidad
óptima que debe ser almacenada, de modo que no sea tan grande que ocasione gastos excesivos
de almacenamiento, ni tampoco pequeña que suponga gastos excesivos de ruptura o de
reposición. Ciertamente, la formulación del problema resulta bastante clara y sencilla, pero en
realidad, tras esta engañosa apariencia, se oculta el trabajo con un sistema altamente complejo y
dinámico, sobre todo a causa de las múltiples relaciones que se establecen en el sistema y con el
sistema.
62

LAS RELACIONES
Cuando se trata de hallar una solución racional al problema de inventario resulta imposible no
tener en cuenta las múltiples interrelaciones que se establecen dentro y fuera del sistema, y que
muchas veces son expresión de intereses dialécticamente contrapuesto.
Cada vez que entra o sale un producto del almacén se afectan de una forma u otra:
Las finanzas
La contabilidad
El cumplimiento de los planes de producción
La transportación
Los contratos de suministro
La posibilidad de que se disponga del producto adquirido
Varías áreas de la empresa enfocan con objetivos, más o menos diferentes (y a veces
contrapuestos) el trabajo con el inventario.
El área de finanzas estaría inclinada a mantener un nivel en las existencias que le garantice un
mínimo en los gastos. En cambio, el área de producción le interesaría mantener un nivel alto en
los inventarios que minimice, sobre todo, la posibilidad de escasez de materias primas y
materiales para garantizar la continuidad de la producción. Pero ni a la empresa ni a la economía
les conviene que se acumulen inventarios en exceso o que, por el contrario, se pare la producción
por falta de recursos materiales.
En un hospital, al igual que en cualquier empresa, el departamento de aseguramiento se enfrenta
con el problema de inventario, siendo éste común para todas las instituciones. Pero asumiendo
las peculiaridades que tiene una entidad de este tipo, donde lo más importante para que no se
detenga la “producción”, o sea el funcionamiento de todos los equipos y con ello el servicio
médico que brinda el centro, es tener en inventario todo lo necesario. Esto parte desde lo más
sencillo que son los víveres, y llega hasta los materiales, accesorios, piezas de repuesto,
herramientas y equipos de prueba, que son los utilizados por las actividades de mantenimiento.
Este módulo “Sistema de Gestión de Almacén” (SGA) incluye:
Controlar todos los productos que están en inventario como pueden ser: resistencias, capacitores,
circuitos integrados para equipos que registran señales bioeléctricas tales como:
electrocardiógrafos, electroencefalógrafos y electromiógrafos; herramientas de propósito general,
equipos de verificación y calibración tales como: analizadores de seguridad eléctrica, tacómetros,
analizadores de potencia de electrobisturí; entre muchos otros.
SMACOR realiza la planificación del mantenimiento preventivo y, con ello, los surtidos que
serán necesarios para llevar a cabo las intervenciones a los equipos. SGA informa al jefe de
almacén las cantidades de surtidos planificados para el mantenimiento. Posteriormente a esto, se
confeccionan los pedidos y se les entrega a los compradores. Una vez realizada la adquisición, se
entran al sistema los datos de la recepción y se informa al Jefe de Ingeniería Clínica los surtidos
pendientes.
Se gestionan las salidas de surtido del almacén hacia las actividades de mantenimiento, o sea en
que Orden de Trabajo (OT) van a ser usados. Estas ordenes de trabajo son generadas en el
módulo de mantenimiento. Luego, el sistema accede al surtido realmente utilizado en cada OT, e
63

informa periódicamente, al Jefe de almacén los surtidos que deben devolver (los técnicos), por
la no utilización en las actividades de mantenimiento.
También controla que la existencia real de surtido en el almacén esté entre un valor mínimo y
máximo, los cuales son calculados por el sistema. De estar la existencia de un surtido fuera de su
rango, se informa al Jefe de almacén para que tome decisiones al respecto. De estar por debajo
del mínimo el sistema da la posibilidad de generar los pedidos, aunque éstos pueden ser emitidos
en cualquier momento. Cuando se entra al sistema cada recepción se actualizan los estados de los
pedidos. Además se lleva un seguimiento de los ajustes de inventario, solicitudes de surtidos y
traslados intra o inter almacén.
64

4.2 TABLA DE EVENTO DEL SGA.
Sistema de Gestión de
Almacén
No Evento
1 Comprar Artículos
2 Solicitar Productos
3 Entregar Artículos
TABLA DE EVENTOS Fecha:
20/06/2000
Origen Destino
Documento
Entrada
Comprador Factura
Jefe del
Centro de
Costo
4 Ajustar Inventario Jefe de
Almacén
5 Nuevo Producto Jefe de
Almacén
6 Nueva Cuenta Jefe de
Almacén
7 Necesidad de Adquirir
Artículos
8 Obtener
Existentes
Artículos
9 Conocer
Hechas
Adquisiciones
10 Conocer Ajustes de
Inventario Realizados
11 Conocer
Hechas
Entregas
12 Obtener
Recibidas
Solicitudes
13 Obtener
Hechos
Pedidos
Jefe del
Centro de
Costo
65
Solicitud de
Productos
Documento
Salida.
Entrega de
Artículos
Ajuste
Inventario
de
Datos
producto
del
Datos
Cuenta
de la
Comprador Pedido
Artículos
de
Jefe de
Artículos
Almacén
Existentes
Jefe de
Artículos
Almacén
Comprados
Jefe de
Ajustes de
Almacén
Inventario
Jefe de
Entregas
Almacén
Hechas
Jefe de
Solicitudes
Almacén
Recibidas
Jefe de
Pedidos
Almacén
Hechos

4.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO.
66

4.4 DIAGRAMA PRELIMINAR.
67

4.5 FACTIBILIDAD ECONÓMICA
I = CTP + Ibasicas + Cprep
I = 7920 + 2000
I = $9920
I = 2000 USD
La inversión del proyecto seria de 9920 pesos y 2000 USD.
El usuario de este sistema sería el propio jefe de almacén. El precio de venta de este sistema está
definido en un contrato realizado entre el CEBIO y el CIREN. El cual consiste en la implantación
gratis del sistema a cambio de toda la colaboración necesaria por parte de ellos. Posteriormente a
la culminación del SGT, este será implantado en otros hospitales, se estima que sea en 10, como
mínimo y el precio de venta para estos hospitales seria de 25000 USD.
4.6 PLANIFICACIÓN DEL PROYECTO
El modo de desarrollo de este sistema, teniendo en cuenta las características particulares de cada
una de las personas que conforman el equipo de trabajo, así como su anterior participación en el
desarrollo del SMACOR: lo considero Semilibre.
ESF = 3 (MF) 1.12
F = 420 * FDS/S = 420 * 13 = 5460
MF = 5.46
ESF = 3 * (5.46) 1.12 = 20
CH = 2
TDES = ESF/CH = 20/2 = 10
TDES = 10
CTP = CHM * ESF
CHM = 2SP
SP = 198
CHM = 396
CTP = 396 * 20 = $7920
TDES = 10
CTP = CHM * ESF
CHM = 2SP
SP = 198
CHM = 396
CTP = 396 * 20 = $7920
68

4.7 ANÁLISIS
4.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES
NUEVO DIAGRAMA DE CONTEXTO
69

4.7.2 DIAGRAMA CERO
70

4.7.3 DIAGRAMA UNO
71

4.7.4 DIAGRAMA DOS
72

4.7.5 DIAGRAMA TRES
73

4.7.6 DIAGRAMA CUATRO
74

4.8 DISEÑO
4.8.1 GRAFO CONVERSACIONAL
1
7 8 9 10 11 12 13 14 15 16
0
22 23 24 25 26 27
28 29 30
0
2
17
3
18 19 20 21
4 5
6
33 34 35 45 36 37 38 39 40 41 42 43 44
0
0
31
4
32
5
6

4.8.2. ESTADOS
Número Descripción Español
Estructurado
0 Estado Inicial
1 Archivo
2 Actualizar Datos
3 Asistir al Mantenimiento
4 Verificar Existencias
5 Emitir Informes
6 Ayuda
7 Cambiar Contraseña
8 Usuarios
9 Personalizar
10 Preparar Página
11 Salir
12 Ubicaciones
13 Actualizar Cuenta 1.1
14 Actualizar Surtido 1.2
15 Actualizar Ajuste 1.3
16 Actualizar Recepción 1.4
17 Actualizar Traslado
18 Nomenclatura
19 Actualizar Devolución 2.2
20 Listado de Surtidos por Devolver 2.3
21 Nueva Solicitud 2.1
22 Almacenes
23 Estantes
24 Subestantes
25 Posición
26 Actualizar Causa
27 Actualizar Estado de los Pedidos
28 Actualizar Genéricos
29 Actualizar Subgenéricos
30 Actualizar Específico
31 Actualizar Consecutivo
32 Actualizar Despachos
33 Listado de Productos Fuera de Rango (mín/máx) 3.1
34 Listado de Pedidos 3.2
35 Listado de Productos Ociosos 3.3
36 Listado de Devoluciones 4.1
37 Listado de Solicitudes 4.2
38 Listado de Entregas 4.3
39 Listado de Pedidos 4.4
40 Listado de Ajustes 4.5
41 Listado de Recepciones 4.6

42 Surtidos Existentes 4.7
43 Ayuda
44 Acerca de SGA
45 Listado de Surtidos en Déficit 3.4
4.8.3 DISEÑO LÓGICO GLOBAL
Nombre del
Fichero Inicial
Descripción
Ajpos {Ajuste + Cup + Almacen + Estante + Subest + Posicion + Cant}
Ajuste {Codigo + Fecha + Cant + Cup + Causa + Respons
+ Estado}
Almacen {Codigo + Nombre + Descrip}
Asigdesp {Recepc + Despacho + Cup + Almacen + Estante + Subest + Posicion + Cant}
Causa {Codigo + Mov + Nombre + Descrip}
Compra {Recepc + Factura}
Consecut {Codigo + Nombre + Especif}
Cuenta {Codigo + Nombre + Descrip}
Despacho {Solicit + Fecha + Desppor + Recpor}
Despest {Despacho + Estado + Fecha}
Desppos {Despacho + Cup + Almacen + Estante + Subest + Posicion + Cant}
Devcup {Devoluc + Cup + Cant}
Devoluc {Codigo + Fecha + Despacho + Estado}
Devpos {Devoluc + Cup + Almacen + Estante + Subest + Posicion + Cant}
Elemento {Recepc + Cup + Cant + Precumn + Precuusd + Recmn + Recusd}
Elempos {Recepc + Cup + Almacen + Estante + Subest + Posicion + Cant + Real}
Especif {Codigo + Nombre + Descrip + Subgena}
Estado {Codigo + Nombre + Tipo}
Estante {Codigo + Almacen + Nombre}
Genera {Codigo + Nombre + Descrip }
Pedest {Cup + Fecha + Estado + Fechae}
Pedido {Fecha + Cant + Cup}
Posicion {Codigo + Almacen + Estante + Subest + Nombre}
Recepc {Codigo + Tipo + Fecha + Proveed + Fabric + Estado}
Recped {Recepc + Cup + Fecha + Cant}
Solest {Solicit + Estado + Fecha}
Solicit {Codigo + Fecha + Ot + Solpor + Aprobpor}
Subest {Codigo + Almacen + Estante + Nombre}
Subgena {Codigo + Nombre + Descrip + Genera}
Surtdesp {Despacho + Cup + Cant}
Surtido {Cup + Nombre + Descrip + Tipo + Cuenta + Um + Min + Max + Foto}
Surtsol {Cup + Solicit + Cant}
Trasdest {Traslado + Cup + Almacen + Estante + Subest + Posicion + Cant}
Traslado {Codigo + Estado + Fecha + Respons}
Traslcup {Cup + Traslado + Cant}
Trasorig {Traslado + Cup + Almacen + Estante + Subest + Posicion + Cant}
Um {Codigo + Abreviat + Nombre}

4.8.4 DER
Genérico
Subgenérico
Específico
Cuenta
Almacén
Consecutivo
Unidad Medida
Estante
Subestante
Pedido Orden
Surtido
Estado
Posición
Cliente
Ajuste
Solicitud
Proveedor Fabricante
Causa
Recepción
Compra
Despacho
Devolución
Traslado

4.8.5 CONCLUSIONES
Por todo lo especificado en la documentación de este módulo y los beneficios que representa este sistema
para la gestión de inventario en almacenes de un hospital, el mismo constituye una importante herramienta
para los directivos de abastecimiento en las instituciones dedicadas a brindar servicios médicos. El sistema
brinda grandes ventajas pues la administración de los inventarios orientadas al mantenimiento, siendo esta la
manera de preveer y tener conocimiento de cómo se comportarán las necesidades de los surtidos. Incluye
también un análisis de mínimo/máximo, realiza los pedidos para cada surtido que su existencia llegue a su
valor mínimo o menor que él. Este sistema puede explotarse en cualquier almacén, pues incluye las
cuestiones generales de administración de inventario, pero está diseñado especialmente para el almacén de
electromedicina de un hospital.

CAPÍTULO # 5 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE ADQUISICIÓN DE
TECNOLOGÍAS (SADTEC).
5.1 DESCRIPCION DEL OBJETO DE AUTOMATIZACION
Una vez que está definido de acuerdo a los intereses del hospital los nuevos equipos ques evan a adquirir, el
comité de adquisición realiza dos tareas fundamentales: evaluar el proveedor y evaluar el producto.
En la evaluación de proveedores hay que tener en cuenta la capacidad de estos para suministrar el producto
con la calidad requerida, para ello se puede obtener información mediante el cuestionario de evaluación al
proveedor que brinda los criterios necesarios al comité para evaluarlo.
Las preguntas que están comprendidas en este cuestionario se subdividen por categorías con una puntuación
máxima. El comité de Evaluación del Producto (EP) analizará a cada proveedor por separado y asignará una
puntuación a cada categoría, la cual puede ir disminuyendo según el criterio del comité de EP, de acuerdo a
las respuestas negativas encontradas al llenar el cuestionario. Esto se representa en las siguientes tablas:
Requisitos
Puntuación Preguntas del
Máxima cuestionario
1. Gestión del sistema de calidad 0.10 1 - 6
2. Control del diseño 0.10 7
3. Control de documentos 0.05 8
4. Control de materias primas y componentes 0.10 9 - 15
5. Control de procesos 0.10 16 - 20
6. Manipulación, almacenamiento, envase y entrega. 0.10 21 - 22
7. Inspección y ensayo 0.10 23 - 24
8. Calibración 0.05 25 - 26
9. Control de no conformidades 0.10 27 - 30
10. Acciones correctivas 0.10 31
11. Auditorías de calidad 0.05 32
12. Entrenamientos 0.05 33
TOTAL 1.00 33 preguntas
Tabla 5. Requisitos del fabricante
De ser posible responda: SI NO
1. Existen objetivos y responsabilidades por escrito para el personal de la empresa?
2 Ha establecido la dirección de la empresa su política de calidad? Anéxela
3. El grupo de aseguramiento de la calidad informa directamente a la dirección de la empresa?
Tiene autoridad para detener embarques o producciones más amplias de artículos rechazados?
4. Realiza la dirección de la empresa revisión de su sistema de calidad?
5. Existe un manual de calidad que describa el sistema de calidad. ? Adjúntelo
6. Están establecidos por escrito los procedimientos del sistema de calidad?
7. Se realiza la validación del diseño?
8. Los documentos de producción son recopilados y archivados? Conservados ___años____
9. Están establecidas las especificaciones de todas las materias primas y componentes?

10. Son evaluados los subcontratistas para conocer su capacidad de suministrar los productos con
la calidad requerida?
11 Existe un sistema de funcionamiento del laboratorio de materiales y el correspondiente archivo
de resultados?
12. Las inspecciones realizadas a los materiales y componentes son revisadas y firmadas por el
personal de aseguramiento de la calidad
13. Existe un sistema de retención para las materias primas y componentes?
14. En el taller, el material es marcado para su identificación a lo largo del proceso productivo,
incluso el almacén de productos terminados?
15. El material es visiblemente marcado como que se encuentra en ensayo, aprobado, rechazado?
16. Están completamente descritos los procesos de ensamble y fabricación?
Tipo de documento_________________________________
17. Existe el documento principal para indicar ?
- Puntos de control de la calidad dentro del proceso de fabricación
- Tipo de ensayo o inspección realizada
- Método de medición
- Quién ejecuta el ensayo o la inspección
- Nivel de aceptación/ rechazo (NCA)
18. Está organizado el flujo de trabajo?
19. Existen registro de mantenimiento y reparaciones disponibles del equipamiento de producción?
20. Se conoce y estudia la precisión con que pueden trabajar las máquinas instaladas?
21. ¿Existen áreas para ubicar las materias primas, productos en procesos y productos terminados?
22 ¿ Son separadas las operaciones de embalaje de las mercancías terminadas?
¿ Se realizan bajo control de supervisión?
¿ Se conservan los registros de etiquetado?
23. ¿ Las muestras de producción para ensayos de control de calidad son identificadas?
24 ¿ Existen procedimientos escritos para la ejecución de las inspecciones de entrada, proceso y
final?
¿ Son registradas?
25. ¿ Existen procedimientos para la calibración de los equipos de medición?
26. ¿ Los registros de calibración son conservados durante un período de tiempo determinado?
27. ¿ Existen procesos para la reelaboración de los productos rechazados?
De ser posible responda :
28. ¿ Los productos rechazados son retenidos en observación y pendientes de su disposición final?
29. ¿ Existe un archivo de quejas y reclamaciones?
Cada queja contiene:
- Naturaleza de la queja.
- Respuesta al cliente. Acción correctiva/preventiva
- ¿ Son revisadas periódicamente para el análisis de tendencias?
30. ¿ Los productos defectuosos son verificados mediante ensayos por parte del productor?
31 Son aplicadas y controladas las acciones correctivas/preventivas ante una inconformidad
identificada del producto, proceso, sistema de calidad?
32. ¿ Se realizan auditorías de calidad para conocer la eficacia del sistema de calidad?
33. ¿ El personal de aseguramiento de la calidad tiene adecuada educación, experiencia o
entrenamiento?
Tabla 6. Desarrollo del Cuestionario
-

Como se ve en la primera tabla hay casos en que a una misma categoría le corresponden varias
preguntas. En el caso de responder todas positivas se obtendrá el valor máximo, en caso de haber alguna
respuesta negativa se propone utilizar la regla del % para disminuir la puntuación por categoría, es decir
Categoría : Gestión de sistema de calidad 5 respuestas positivas
1 negativa
6 positivas ### 100 % puntos
5 positivas ### X %
X= 83.3 % de la puntuación máxima
Para esta categoría la puntuación máxima es de 0.10 (6 respuestas positivas)
5 respuestas positivas representan un 0.10x 0.833 = 0.0833
Este análisis se hizo partiendo de que todos los criterios dentro de una misma categoría tienen igual
importancia
Para evaluar el producto se considerarán los siguientes parámetros:
1) Seguridad mecánica y eléctrica : Se define como seguridad mecánica a aquella que se implemente
para proteger al paciente y al operador, de riesgos o daños por desperfectos mecánicos sedefine como
seguridad eléctrica a aquellos sistemas de alarmas y medidas que debe tomar el fabricante para
garantizar que el paciente y el operador no sufran choques eléctricos.
2) Características técnicas : condiciones de operación, especificaciones del fabricante, funciones y
exactitud de las mediciones que se realizan vs estándares y recomendaciones publicadas.
2.1) Condiciones de operación : Son las condiciones que el fabricante exige para que el equipo
funcione correctamente
2.2) Especificaciones del fabricante : Son las que el fabricante brinda en la documención
2.3) Normas técnicas : Dadas por el fabricante o asociadas al equipo que se va a comprar
3) Características Clínicas : Facilidad de uso, necesidad de entrenamiento, uso para las aplicaciones
destinadas.
3.1) Uso para las aplicaciones destinadas: El equipo sólo se usa en las aplicaciones que especifica el
fabricante
3.2) Facilidad de uso: Que el equipo sea de fácil manipulación y operación.
3.3) Entrenamiento en el servicio: Que el personal esté entrenado en la tecnología que se va a comprar
o que el fabricante la brinda estos entrenamientos.

4) Ingeniería - Diseño: Características físicas (peso, longitud, etc), construcción, manuales de servicio
y operación, facilidades que brinda el fabricante en cuanto a pago, soporte técnico, entrenamientos,
etc.
5) Experiencia del usuario: Se analiza la experiencia del departamento de IC, de otros usuarios o
cualquier otro hospital en el uso de la tecnología que se va a adquirir.
6) Análisis del costo del ciclo de vida: Este incluye precio inicial de adquisición, renovaciones,
instalaciones, suministros de partes y componentes, costo de operación, entrenamiento, tanto del
personal que opera el equipo como el que realiza el servicio.
7) Otros factores: Aspectos tales como la estandarización y/o factores intangibles que pueden variar
de aplicación en aplicación.
A cada uno de estos criterios dentro de cada categoría se le asigna una puntuación de uno a diez (pesos
individuales). Después se suman estos y se determina el promedio, multiplicándolos por un peso que se
brina al final de cada categoría para obtener el total. Los miembros del comité de EP deben estar de
acuerdo con todos los criterios para la evaluación final.
Los criterios por categorías y las categorías se muestran en la siguiente tabla de comparaciones
Fabricante FABRICANTE 1 FABRICANT FABRICANTE
Modelo MODELO A MODELO B MODELO C
Categorías Alcance Comentar Alcance Come Alcance Come
SEGURIDAD
Mecánica 7 4 9
Eléctrica 5 2 7
Peso (0.20)x Alcance Prom. 1.2 0.6 1.6
CARACTERISTICAS
Condiciones de operación
Controles 4 8 10
Modos de operación 6 7 9
Especificaciones del fabricante
(lista) 3 4 8
2 3 8
Normas Técnicas
(lista) 1 5 7
4 5 6
Peso (0.15) x Alcance promedio 0.5 0.8 1.2
CARACTERISTICAS CLINICAS
Uso para aplicaciones destinadas 6 10 8
Facilidades de uso 7 3 7
Entrenamiento en el servicio 5 2 9
Peso (0.25) x Alcance Promedio 1.5 1.25 2
FACTORES HUMANOS
Diseño 6 7 9
Características físicas
Dimensiones 4 6 8
Peso 7 3 7

Construcción
Seguridad en el funcionamiento 3 4 7
Mantenibilidad 1 6 8
Manuales
Manual de operación 2 5 5
Manual de servicio 4 8 9
Facilidades del Fabricante
Al usuario 5 6 7
Al servicio. 3 7 7
Peso (0.10) x Alcance Promedio 0.39 0.6 0.74
EXPERIENCIA DEL USUARIO
Departamento de IC 6 7 10
Areas Clínicas
Médicos 4 6 8
Enfermeras 7 6 7
Otros Hospitales
Médicos 5 8 9
Enfermeras 6 7 8
Especialistas en IC 7 5 7
Peso (0.10) x Alcance Promedio 0.58 0.65 0.82
COSTO
Costo de adquisición 6 4 8
Costo de operación 8 6 7
Costo de Servicio 4 2 9
Peso (0.10) x Alcance promedio 0.58 0.65 0.82
OTROS FACTORES
Normalización 2 4 9
Antecedentes con el Fabricante 3 7 6
Peso (0.05) x Alcance Promedio 0.13 0.28 0.38
ALCANCE TOTAL 5.2 4.72 7.94
Para realizar la Evaluación del producto:
Tabla 7
Se enumeran las características técnicas del "producto ideal" a que se aspira (debe tenerse tenerse en cuenta
el presupuesto económico que se tiene). En otras palabras, asegurarse que estos requerimientos específicos
sobrepasan o cumplen con los productos propuestos por el comité de EP. Se envían criterios a los diferentes
fabricantes que producen este equipamiento, además debe pedirse la información que responda a las
preguntas del cuestionario para determinar al o a los fabricantes de mayor prestigio.
Con la información en mano hay que evaluar a los proveedores y seleccionar los que obtengan mayor
puntuación según (tabla 5), además de seleccionar cuales productos pudieran ser considerados en el análisis.
Después se debe de forma detallada mediante la tabla de comparación, los tipos de servicios y fijar el más
óptimo a asumir por el departamento de Ingeniería Clínica.
Desarrollar y ejecutar pruebas a los productos que comprueben seguridad, funcionamiento y especificaciones
técnicas que plantea el fabricante. Eliminar del análisis cualquier muestra que no cumpla esto y que por tanto
convierta al criterio de la tabla de comparación (ver tabla 7) que se esté analizando en un valor mínimo.

Desarrollar entrevistas con otros usuarios (al menos tres posibles) de los equipos que se analizan para
determinar sus niveles de satisfacción con los equipos en particular y con los fabricantes. Realizar visitas al
lugar donde el equipo está funcionando. De ser posible estrevistarse con médicos, enfermeras e ingenieros
biomédicos o clínicos de algún comité de EP que analizó este equipo con anterioridad.
Hacer un balance detallado de la razón costo/beneficio.
Una vez fijados los fabricantes y seleccionados los productos se procede a evaluarlos según tabla 2 . Después
se debe llenar la tabla 3.
El producto de mayor puntuación será el óptimo.
Cada vez que se compra un equipo, este se controla en el Sistema de Mantenimiento y sus datos son
registrados para mantener actualizado un registro de los fabricantes relacionados con la entidad y de los tipos
de producto que en ella se encuentran.
Decidiendo el tipo de Servicio
Luego de seleccionar que equipo se va a comprar hay que decidir el tipo de servicio de mantenimiento que
se le dará a este equipo. Algunas veces hay factores que controlan el proceso de decisión como, por
ejemplo, diferencias dramáticas en los costos totales, esto hace que este proceso sea relativamente fácil, sin
embargo, es mucho más probable que sea una selección difícil.
Desafortunadamente no existe fórmula que, automáticamente genere, la mejor opción cuando se le inserta la
información. La selección depende de numerosas variables que incluyen muchas veces desde los
dispositivos involucrados hasta la situación geográfica del hospital en particular. Debido a esto, para realizar
la selección, se utiliza una matriz que incluye numerosos parámetros comúnmente utilizados y de vital
importancia en una decisión de este tipo. Estos parámetros tienen predefinidas sus posibles respuestas y,
para cada una de ellas, su importancia relativa. Esto permite utilizar esta matriz como un método de
evaluación flexible, capaz de adaptarse a cualquier situación específica. Luego de haber recopilado toda la
información necesaria, se procede a evaluar. Este proceso consiste en sumar, por cada tipo de servicio, el
valor de sus parámetros multiplicado por la importancia relativa del valor de este. El que obtenga la mayor
puntuación constituye la opción a considerar.
Evaluando Necesidades de Equipamiento médico: Un algoritmo simple.
Una de las principales dificultades que enfrenta la administración de los hospitales contemporáneos es tomar
una decisión bien fundamentada al comprar un nuevo equipo médico, sobre todo cuando el hospital está en
un proceso de renovación capital. En la ausencia de técnicas cuantitativas, el administrador generalmente
opta por un procedimiento largo y costoso de prueba y fallo, da por acertadas las peticiones de los
departamentos, o cede ante las presiones ejercidas por los grupos influyentes del hospital. La decisión de
adquirir un nuevo equipo médico en hospitales que ya existen es mucho más compleja que en hospitales
nuevos. Las nuevas instalaciones son generalmente planificadas con un conjunto predefinido de equipos que

proveen una cierta gama de servicios médicos, el presupuesto es usualmente establecido con anterioridad, y
el equipo comprado es nuevo. En las instalaciones ya existentes, si embargo, puede existir una contraparte de
equipos ya funcionando, o que necesitan reparación. Este es un algoritmo simple por el que la cantidad de
equipos necesitados puede ser determinada por medio de un modelo algebraico. Este método permite al
director del hospital y a los jefes de departamentos tener una base común objetiva para negociar las
necesidades departamentales.
Los hospitales necesitan desarrollar un sistema mediante el cual las solicitudes de compra de nuevos equipos
puedan ser rigurosamente evaluadas. Naturalmente, cada departamento trata de impresionar a la
administración con sus necesidades. Los administradores de hospitales están conscientes de este problema,
sin embargo, debido a la ausencia de técnicas cuantitativas y objetivas, están propensos a ceder ante las
presiones de grupos de gran fuerza política en el hospital. Este problemas es más o menos universal, pero
está más acentuado en países subdesarrollados.
Los hospitales de los países desarrollados tienen una pobre gestión de tecnología, especialmente en áreas
rurales. Es por eso, que no es extraño que anualmente se asignen presupuestos sustanciales para el reemplazo
de equipos médicos en los hospitales públicos. Sin embargo este gran gasto no va paralelo a un aumento
significativo en la calidad del servicio asistencial. Por lo tanto es necesario ampliar de la perspectiva de
“control de equipos” a una visión más amplia de “gestión de mantenimiento”.
El concepto de gestión de tecnología está ganando más terreno cada día porque se refiere a los problemas
asociados con equipos médicos más globalmente. En el pasado, el control del equipamiento era visto como
un proceso mediante el cual el proceso de inventario de equipos y piezas de repuesto era alcanzado. ECRI ve
el proceso de planeamiento de la tecnología como una secuencia de pasos empezando con una revisión de
los objetivos estratégicos, seguido de una revisión del equipamiento existente, dirigiéndose entonces a la
sustitución de tecnologías y finalizando, si es necesario, con la adquisición de nuevas tecnologías.
Un paso crítico en el proceso de gestión de tecnología es la política de sustitución de equipos médicos. No es
fácil para el administrador de un hospital enfrentar las diferentes solicitudes departamentales de equipos
médicos sin tener un método concreto para establecer prioridades. Esto solo puede ser alcanzado definiendo
ciertos criterios como las bases para que un equipo A tenga prioridad sobre un equipo B.
Se propone que se considere estos criterios cuando se compre un nuevo equipo: 1) relación ideal equipopaciente,
2) cantidad de equipos existentes que desarrollan la misma función que el equipo solicitado, 3) la
condición de cada uno de los equipos existentes, 4) el impacto del equipo en la calidad de la atención al
paciente, 5)clasificación del equipo en generador de ingresos o no.

La relación equipo paciente define la cantidad ideal de equipos por camas, en un departamento dado.
Aunque esta relación no es común encontrarla en libros de textos porque diferentes hospitales adoptan
diferentes políticas, y debido al rápido avance de la tecnología, puede ser estandarizada por cada hospital
usando los valores publicados por organizaciones de reputación como son Association for the Advancement
of Medical Instumentation (AAMI) y la ECRI, aunque en ausencia de éstos los especialistas de la salud del
hospital pueden acordar lo que constituye un estándar razonable.
El segundo factor, que es el número de equipos existentes puede ser obtenido de la lista de inventario de
equipos. Esta lista debe ser actualizada y controlada por el departamento de ingeniería clínica del hospital o
por el personal del sistema de información. El tercer factor, como su nombre lo indica, es el estado físico del
equipo y debe estar también disponible en la lista de inventarios. Naturalmente, mientras más mala es la
condición del equipo, menor es la confianza del departamento en él. Esto es verdad porque un equipo que
frecuentemente se rompe cuesta al hospital no solamente la suma de la reparación, sino la oportunidad de
usar el equipo.
El cuarto factor es de una importancia significativa porque está relacionado con el objetivo principal en la
asistencia médica que es la calidad de la atención al paciente. Si cierto equipo es obligatorio para la
supervivencia del paciente, como es el caso de un ventilador de una unidad de cuidados intensivos, se le
debe dar cierta prioridad sobre otros que tiene un papel menos crucial. Similarmente, un equipo que acelera
la recuperación del paciente y/o aumenta la calidad en la rehabilitación se le debe dar prioridad sobre esos
que “es bueno tener”.
Finalmente, la efectividad de los costos debe ser también considerada durante el proceso. El hospital
moderno debe considerar tener una orientación hacia la obtención de beneficios para que así pueda proveer
servicios competentes a sus pacientes. Algunos tipos de equipos médicos son conocidos por generar ingresos
sustanciales incluso sin contribuir directamente a la excelencia de la atención al paciente.
Modelo
El objetivo de este algoritmo es que teniendo como entrada los cinco criterios mencionados anteriormente,
dar como salida la cantidad de equipos a comprar sugeridos. Llamemos a la cantidad de camas o usuarios nb,
la relación equipo paciente rr, el número de equipos existentes (disponible) m, la condición de un equipo
dado ci, el valor de la calidad de la atención médica v, y la capacidad de generar ingresos g. Entonces si n es
la cantidad real de equipos a ser comprados, se relaciona con los otros factores a través de la siguiente
ecuación.
n=Int {nb*rr*v*g}-Int{∑
i=
m
1
ci
} (1)
donde Int es el operador, que redondea su argumento al entero más cercano, y ∑ es el operador sumatoria
sobre todas las piezas existentes m.
El problema ahora es asignar valores para nb, rr, v, g, y c en la ecuación 1 para así poder calcular n Nótese
que el primer término de la ecuación 1 suministra la cantidad necesitada por un departamento en particular
sin tener en cuenta lo que ya se posee, mientras que el segundo suministra un número compuesto equivalente
al equipo en funcionamiento que ya existe. La diferencia entre los dos es la cantidad neta necesitada.

Empecemos primero con el factor de condición del equipo c. Es razonable proponer que c tome valor 1 si el
equipo esta operando a toda capacidad y 0 si el equipo es evaluado de inservible, obsoleto o de baja. La
razón de estas selecciones es que un equipo en completa disposición debe ser contado como un equipo
completo, mientras los otros no deben ser contados para ninguna decisión. Asumiendo que entre c y la
condición del equipo existe una relación lineal, diferentes valores de c pueden ser interpolados como se
muestra en la tabla 1.
Condición OK Reparación Menor Reparación Media Reparación Mayor De Baja
c 1 3/4 1/2 1/4 0
Para visualizar la contribución del segundo termino en la ecuación 1 consideremos un simple ejemplo en el
que una sala esta renovando las camas. Asuma que la sala cuenta con 8 camas de las que se reporta que hay
dos de baja, tres necesitando reparaciones menores y 3 en buenas condiciones. El segundo término sería
ahora calculado como: Int{2*0 + 3*3/4 + 3*1} = 5. En otras palabras el administrador pensara son respecto
a esta sala que tiene 5 camas en perfecto estado en ves de 8.
Ahora consideremos la contribución del primer término en la ecuación 1. Como se ha dicho anteriormente,
rr es una relación equipo paciente ideal o recomendada. Esta información esta basada en información de
organizaciones de organizaciones de reputación o de hospitales similares, o del personal especializado del
hospital. Por ejemplo es un estándar aceptado que en cualquier Unidad de Cuidados Intensivos (UCI), cada
cama debe poseer un monitor, en cuyo caso rr=1:1, y la relación es 1. Por otra parte en una UCI puede tener
un solo desfibrilador para todos sus pacientes porque la probabilidad de que se presenten 2 ataques
cardiacos a la vez es muy baja. En este caso rr será de 1:8 y asi sucesivamente.
Los factores menos cuantificables v y g también ameritan una explicación. El factor de la calidad de la
atención médica v es un coeficiente que refleja la importancia del equipo para la supervivencia del paciente.
Como los equipos necesarios para el soporte de la vida no se deben comprometer, a estos equipos se les
asignará un coeficiente de uno, que es el máximo valor posible para v. Además si un equipo es clasificado
como que aumenta la calidad de la atención al paciente, v puede sumir el valor de ¾. Por ultimo si un equipo
es clasificado como “es bueno tener”, v puede asumir el valor de ½. Estos valore son resumidos en la
ecuación 2.
⎧1.......
soporte.
de.
vida
⎪
v= ⎨3/
4..
aumenta.
la.
calidad.
de.
la.
atención.
al.
paciente
⎪
⎩1/
2...
bueno.
tener
El último coeficiente a considerar es g, que está relacionado con la posibilidad de generar ingresos sin
considerar su relevancia en la calidad de la atención médica. Si un equipo no es considerado como generador
de ingresos, se le puede asignar un valor neutral de 1. Si se espera algún ingreso por su concepto se le
asignará el valor de 1.1. Esto es equivalente a darle un 10 % más de peso a los equipos generadores de
ingreso que a los que no lo son en otras palabras.
⎧1.....
no.
generador.
de.
ingresos
g= ⎨
⎩1.
1..
generador.
de.
ingresos
(2)
(3)

En la práctica, el administrador del hospital distribuye planillas de solicitudes a cada departamento
solicitante de equipos nuevos. El cuestionario pide a cada Jefe de Departamento la lista de cantidades y
equipos solicitados, así como también una evaluación de la importancia del equipo para el paciente y sus
potencialidades como generador de ingresos para el hospital. Y ya con todos los datos necesarios para
aplicar la fórmula se puede obtener la cantidad recomendada n.

5.2 TABLA DE EVENTOS
Sistema Adquisición de Tecnologías Tabla de Eventos Fecha:
No Evento Origen Destino Documento
Entrada
20/06/2000
Documento Salida
1 Definir Equipo Ideal Evaluador Características
Ideales
2 Evaluar Proveedor Evaluador Cuestionario
Evaluador Evaluación
Proveedor
3 Evaluar Producto Evaluador Parámetros
Evaluación
Evaluador Evaluación
Producto
4 Seleccionar Equipo Evaluador Tipo Equipo
Evaluador Propuesta Compra
5 Contratar Servicio
Proveedor Solicitud Contrato
Proveedor Contrato
6 Evaluar Servicio Evaluador Características
Servicio
Evaluador Evaluación
Servicio
7 Registrar Servicio Departamento
de IC
Servicio Prestado
8 Necesidad de
Departament
Expediente
Conocer Expediente
del Proveedor
o de IC
9 Necesidad de
Departament
Listado Contratos
Conocer Contratos
o de IC
10 Necesidad de
Departament
Listado
Conocer
o de IC
Evaluaciones
Evaluaciones
Producto
de
Producto
11 Necesidad de
Departament
Listado
Conocer
o de IC
Evaluaciones
Evaluaciones
Proveedor
de
Proveedores
12 Necesidad de
Departament
Listado
Conocer
o de IC
Evaluaciones
Evaluaciones
Servicio
de
Servicio
13 Renovar
Evaluador Parámetros de
Departamento
decisión
Evaluador Cantidades
comprar
a

14 Definir Parámetros
de Evaluación de
Producto
15 Definir Preguntas
para el Fabricante
16 Definir Términos de
Contrato
5.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO
Evaluador
Términos Contrato
Evaluación Proveedor
Evaluación Producto
Propuesta Compra
Evaluación Servicio
Cantidades a Comprar
Cuestionario
Tipo Equipo
Parámetros Evaluación
Características Servicio
Características Ideales
Parámetros de Decisión
Parámetros Producto
Preguntas Fabricante
Evaluador Parámetros
Producto
Evaluador Preguntas
Fabricante
Evaluador Términos
Contrato
Sistema de
Adquisición de
Tecnologías
Solicitud Contrato
Contrato
Listado Evaluaciones de Producto
Listado Evaluaciones Proveedores
Listado Evaluaciones Servicio
Listado Contratos
Expediente
Servicio Prestado
Proveedor
Departamento
de IC

5.4 DIAGRAMA PRELIMINAR
Características
Ideales
Términos
Contrato
Preguntas
Fabricantes
Parámetros de
Producto
Parámetros de
Decisión
Cantidades a
Comprar
Cuestionario
Evaluación
Proveedor
PROVEEDOR
Evaluación
Producto
Tipo
Equipo
1 2 3 4
16
15
Listado
Evaluaciones
Servicio
14
13
12
EQUIPO IDEAL
EVALUACION
PROVEEDOR
Listado
Evaluaciones
Proveedores
11
Parámetros
Evaluación
PREGUNTAS
FABRICANTE
EQUIPO
EVALUACION
SERVICIO
10
Listado
Evaluaciones
Producto
PARAMETROS
PRODUCTO
CONTRATO
EVALUACION
PRODUCTO
Listado
Contratos
6
Propuesta
Compra
5
TERMINOS
CONTRATO
Solicitud
Contrato
Contrato
Características
Servicio
7
Evaluación
Servicio
9
Servicio
Prestado
EXPEDIENTE
8
Expediente

5.5 FACTIBILIDAD ECONOMICA
Beneficios Intangibles
• Disminución de riesgos de muerte, pues al seleccionar equipos de mayor calidad disminuirán las roturas
de éstos.
• Aumentar la calidad de los servicios médicos, al disminuir las interrupciones por roturas de los equipos
por ser estos resultado de una mejor selección.
• Disminución de los tiempos de selección de las nuevas tecnologías, al ser el usuario asistido por el
sistema.
• Disminución de los gastos del hospital a largo plazo, debido a que sólo el 20% del costo total del ciclo de
vida lo constituye el costo de adquisición.
• Humaniza el proceso de selección de nuevas tecnologías, disminuye la subjetividad de este proceso,
debido a que una vez seleccionado el criterio de evaluación y dado un peso relativo a cada elemento de
este, la selección ocurre automáticamente evaluando datos existentes del fabricante y el producto.
• Determinación de los fabricantes de equipos médicos que no tienen calidad, al considerar su historial de
relaciones con la entidad, la calidad de los productos suministrados, así como la seriedad en los servicios
prestados.
Debido a la naturaleza de la atención médica en Cuba (gratuita) es muy difícil determinar los beneficios del
sistema con la Economía Anual (Ea). Los beneficios de éste son dados por una buena selección de los
equipos médicos, y a largo plazo, reportan un ahorro a la entidad debido a que el costo mayor del
equipamiento médico está dado por el mantenimiento, materiales, etc.
Dentro de las inversiones necesarias está el adiestramiento por un mes de un operador y el Jefe de
Departamento de Ingeniería Clínica con un costo de $148.00 y $265.00 respectivamente. Se comprará una
microcomputadora por valor de $1 500.00 y una impresora de $ 300.00; no existirán costos por concepto de
llenado de la base de datos ya que estas se nutrirán de las ya existentes.
I = CTP + Ibásicas + Cprep
I= 12 877.92+ 1 500.00 + 300.00 + 148.00 + 265.00
I= 15 090.92
I – Inversiones necesarias para implantar un sistema en pesos.
CTP - Costo total de proyección en pesos
Ibasicas - Valor de las inversiones básicas en pesos
Cprep - Costo de la preparación de condiciones para la implantación del sistema

5.6 PLANIFICACION DEL PROYECTO
Debido a las características del centro y por la atención de los tutores hacia el proyecto identifico el modo de
desarrollo como orgánico.
ESF = 3 * (MF) 1.12
= 3 * (9.24) 1.12
= 3 * 12.07
ESF = 36.21
CH = 2
ESF
CH =
TDES
ESF
TDES =
CH
TDES = 18 meses
CTP = CHM * ESF
= 396 * 36.21
CTP = 14 339.16
F = 420 * FDE/S
F= 420 * 22
F= 9240
MF=9.24
CHM = 2 * SP
= 2 * 198
CHM = 396
• CTP - Costo total del proyecto.
• CHM - Costo por hombre - mes.
• ESF - Esfuerzo total del proyecto.
• F- Número de instrucciones fuente.
• FDE/S- Flujos de datos de entrada más de salida del sistema.

5.7 ANALISIS
5.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES
NUEVO DIAGRAMA DE CONTEXTO
Evaluador
Parámetros Producto
Preguntas Fabricante
Términos Contrato
Evaluación Proveedor
Evaluación Producto
Propuesta Compra
Evaluación Servicio
Cantidades a Comprar
Cuestionario
Tipo Equipo
Parámetros Evaluación
Características Ideales
Características Servicio
Parámetros de Decisión
Sistema de
Adquisición de
Tecnologías
Solicitud Contrato
Contrato
Análisis Costo Servicio
Listado Evaluaciones de Producto
Listado Evaluaciones Proveedores
Listado Evaluaciones Servicio
Listado Contratos
Expediente
Servicio Prestado
Contrato a Analizar
Equipo a Analizar Baja
Equipo a Comprar
Propuesta Baja
Propuesta Decisión
Proveedor
SGA
SMACOR
Departamento
de IC

5.7.2 DIAGRAMA CERO
Parámetros
Producto
1
Definir
Parámetros
de
Evaluación
Términos
Contrato
Análisis Costo Servicio
Propuesta Decisión
Propuesta Baja
Preguntas
Fabricante
ORDEN
Listado Evaluaciones
Servicio
PREGUNTAS
FABRICANTE
EQUIPO
PROVEEDOR
Listado Evaluaciones
de Producto
Listado Evaluaciones
Proveedores
Expediente
Contrato
2
Gestionar
Contratos
Servicio
Prestado
Evaluación Producto
Evaluación Proveedor
Evaluación Servicio
Propuesta Compra
Cantidades a Comprar
5
Realizar
Análisis
Costo /
EVALUACION
PROVEEDOR
3
Evaluar
Cuestionario
Tipo Equipo
Beneficio
CONTRATO
Parámetros Evaluación
Características Ideales
Contrato a Analizar
TERMINOS
Características Servicio
Equipo a Analizar Baja
Equipo a Comprar
CONTRATO
Parámetros de Decisión
EVALUACION
SERVICIO
Listado Contratos
4
Emitir
Listados
EXPEDIENTE
PARAMETROS
PRODUCTO
EVALUACION
PRODUCTO
EQUIPO IDEAL
Solicitud
Contrato

5.7.3 DIAGRAMA UNO
Preguntas Fabricante
5.7.4 DIAGRAMA DOS
Solicitud Contrato
Contrato
1.1
Definir
Preguntas
Fabricantes
2.1
Contratar
Parámetro
TERMINOS
CONTRATO
PREGUNTAS
FABRICANTE
Escoger
Parámetro
1.3
Definir
Términos
Contrato
EXPEDIENTE
EQUIPO
PROVEEDOR
CONTRATO
TERMINOS
CONTRATO
PARAMETROS
PRODUCTO
Términos Contrato
2.2
Registrar
Servicio
1.2
Definir
Parámetros
Producto
Parámetros Evaluación
Servicio Prestado

5.7.5 DIAGRAMA 2.1
5.7.6 DIAGRAMA TRES
Propuesta
Compra
Cantidades
a Comprar
Solicitud Contrato
Características
Ideales
Tipo
Equipo
Parámetros
de decisión
2.1.1
Solicitar
Contrato
3.1
Definir
Equipo Ideal
3.6
Seleccionar
Equipo
3.5
Renovar
Departamento
EQUIPO IDEAL
TERMINOS
CONTRATO
EQUIPO
PROVEEDOR
CONTRATO
PREGUNTAS
FABRICANTE
CONTRATO
EVALUACION
SERVICIO
EVALUACION
PROVEEDOR
EQUIPO
PROVEEDOR
EVALUACION
PRODUCTO
TERMINOS
CONTRATO
2.1.2
Registrar
Contrato
PARAMETROS
PRODUCTO
3.2
Evaluar
Proveedor
3.4
Evaluar
Servicio
Cuestionario
EXPEDIENTE
3.3
Evaluar
Producto
Contrato
Evaluación
Proveedor
Parámetros
Evaluación
Características
Servicio
Evaluación
Producto
Evaluación
Servicio

5.7.7 DIAGRAMA CUATRO
Listado Evaluaciones
Servicio
Expediente
4.1
Emitir
Listado
Evaluaciones
Servicio
EVALUACION
SERVICIO
4.5
Emitir
Expediente
EXPEDIENTE
Listado Evaluaciones
de Producto
CONTRATO
4.2
Emitir
Listado
Evaluaciones
de Producto
EVALUACION
PRODUCTO
PROVEEDOR
Escoger
Informe
Opción
Informe
EQUIPO
EVALUACION
PROVEEDOR
4.3
Emitir
Listado
Contratos
Listado Contratos
4.4
Emitir
Listado
Evaluaciones
Proveedores
Listado Evaluaciones
Proveedores

5.7.8 DIAGRAMA CINCO
Opción
Tipo
Análisis Costo
Servicio
Contrato a Analizar
Escoger
Tipo de
Análisis
5.1
Analizar
Servicio
EQUIPO
ORDEN
EXPEDIENTE
5.2
Analizar
Estado de
Equipo
5.3
Analizar
Rentar vs
Comprar
Propuesta Baja
Equipo a Analizar
Baja
Propuesta Decisión
Equipo a Comprar

5.8 DISEÑO
5.8.1 GRAFO CONVERSACIONAL
1.1 1.2 1.3 1.4 1.5
2.1
1 3
2
2.2
4
0
4.1 4.2 4.3 4.4 4.5 4.6 4.6
2.3
0
2
2.4 2.5 2.6
0
5
6.1
6
6.2
2.7
6.3
7
7.1 7.2
2.8
2.9

5.8.2 ESTADOS
Número Descripción Español Estructurado
1 Archivo
1.1. Cambiar Contraseña
1.2. Usuarios
1.3. Personalizar
1.4. Preparar Página
1.5. Salir
2. Parámetros
2.1. Categorías Producto
2.2. Parámetros Producto 1.2
2.3. Categorías Proveedor
2.4. Preguntas Fabricante 1.1
2.5. Características Técnicas
2.6. Costo / Ganancia
2.7. Norma Técnica
2.8. Términos Contrato 1.3
2.9. Posibles Términos
3. Contrato
3.1 Solicitud 2.1.1
3.2. Actualizar 2.1.2
3.3. Servicio 2.2
4. Evaluar
4.1 Evaluaciones
4.2. Proveedor 3.2
4.3. Equipo Ideal 3.1
4.4. Producto 3.3
4.5. Servicio 3.4
4.6. Seleccionar Producto 3.6
4.7. Renovar Departamento 3.5
5. Listados
5.1. Contratos 4.3
5.2. Evaluaciones Proveedor 4.4
5.3. Expediente 4.5
5.4. Evaluaciones Producto 4.2
5.5. Evaluaciones Servicio 4.1
6. Ayuda
6.1. Contenido
6.2. Acerca de
5.8.3 DISEÑO LÓGICO GLOBAL
Nombre del
Fichero Inicial
Descripción
Carideal {Cartecn + Equideal + Obligatorio + Valideal + Tipo + Umbral}
Cartecn {Codigo + Nombre + Descrip}
Catcosga {Codigo + Anual + Tipo + Nombre + Descrip}
Catprod {Codigo + Peso + Nombre + Descrip}
Catprov {Codigo + Nombre + Descrip + Maxpunt}
Comerc {Codigo + Nombre + Descrip}
Compais {Comerc + Pais}
Contcomp {Codigo + Fecha + Fechaent + Condent}
Contrato {Codigo + Tipo + Contrato + Valor + Proveed + Formapag + Comentar}
Contserv {Codigo + Fechinic + Tdur}
Costeval {Evamodel + Catcosga + Valor}
Costserv {Tiposerv + Evalserv + Catcosga + Valor}
Desccont {Pt_termcont + Pt_codigo + Contrato + Valor}

Equicomp {Unitario + Contcomp + Cantidad + Unidad}
Equideal {Evaluac + Evaluad + Codigo + Generico + Aceptado}
Equiserv {Contserv + Unitario + Tiposerv}
Evalprov {Proveed + Evaluad + Evaluac + Fechinic + Fechterm + Valor + Codigo}
Evalserv {Modelo + Evaluac + Codigo + Evaluad + Fechinic + Fechter + Valor}
Evaluac {Codigo + Fechterm + Fechinic + Tipo + Evaluac}
Evaluad {Codigo + Nombre + Apellido + Cargo}
Evamodel {Modelo + Fechinic + Fechterm + Evaluac + Codigo + Valor }
Expserv {Unitario + Contserv + Fechsol + Fechresp + Fechent + Comentar + Costo + Result}
Normtecn {Codigo + Nombre + Descrip}
Ocupac {Codigo + Nombre + Descrip}
Ocupeval {Evaluad + Ocupac}
Parprod {Catprod + Codigo + Nombre + Descrip}
Pescat {Catprov + Evaluac + Peso}
Pesoeval {Catprod + Evamodel + Peso}
Pesterm {Termcont + Evalserv + Peso}
Posterm {Termcont + Codigo + Nombre + Porcval + Descrip}
Pregunta {Catprov + Codigo + Descrip + Nombre}
Puntcart {Cartecn + Evamodel + Evaluac + Valor}
Puntmod {Parprod + Evaluad + Evamodel + Evaluacion}
Puntntec {Normtecn + Evamodel + Evaluac}
Puntserv {Pt_termcont + Pt_codigo + Tiposerv + Evalserv + Valor}
Ranking {Evaluad + Evamodel + Catprod + Ranking}
Respuest {Evalprod + Respuesta + Pregunta}
Termcont {Codigo + Nombre + Descrip + Tipo}
Tiposerv {Codigo + Nombre + Descrip}

5.8.4 DER
Evaluación
Proveedor
Pregunta
Categoría
Proveedor
Posible
Término
Evaluación
Servicio
Evaluador
Proveedor
Tipo Servicio
Término
Contrato
Evaluación
Característica
Técnicas
Equipo Ideal
Ocupación
País
Categoría
Costo/Ganacia
Genérico
Modelo
Fabricante
Comercialización
Contrato Contrato
Servicio Compra
Contrato
Normas
Técnicas
Evaluación
Modelo
Fecha
Servicio
Equipo
Parámetro
Producto
Categoría
Producto

5.7 CONCLUSIONES
Uno de los mayores problemas que presentan los directores de hospitales es establecer la estrategia y la toma
de decisiones en la compra de los equipos médicos, se carece en todos los departamentos de Electromedicina
del país y en muchos de los países de América Latina con un asistente para la compra de nuevas tecnologías
como el que aquí se presenta. Desde el punto de vista de la Gestión Tecnológica el módulo de adquisición
es por no decir el más importante, uno de los módulos más importantes, porque es el que contribuye (junto
con especialistas técnicos y médicos) a que se introduzcan tecnologías de mejores prestaciones.
La búsqueda de criterios que ayuden a evaluar tanto a proveedores y fabricantes como a los productos
siempre ha sido una necesidad imperiosa para todos los que tienen que ver con el proceso de adquisición, se
pretende por tanto con este sistema tener almacenados estos criterios y validar los respectivos pesos en
función de la experiencia de diferentes especialistas para incorporarlos al sistema, además de ser un
consultante en la toma de decisión, evaluar el desempeño de los encargados de la realización de los contratos
de servicios.

6. CONCEPCIÓN DEL SISTEMA DE SEGURIDAD Y PROTECCIÓN
El sistema incluye toda la información del hospital relacionada con el mantenimiento de los equipos
médicos, adquisición de tecnología e inventario de los surtidos. Por la importancia que tienen cada uno de
estos, es que se hace imprescindible garantizar una total integridad de la base de datos. El no lograrlo y
permitir simples variaciones por “intrusos” puede ocasionar que ocurran cosas tales como:
• Alteración de la planificación del mantenimiento preventivo
• No realización de las intervenciones a determinados equipos
• No generación de órdenes correctivas a partir de los reportes de averías
• Variación en el plan y consumo de surtidos
• Variación de la existencia real de surtidos en inventario
• Salidas ficticias del almacén
• No generación de pedidos necesarios o generación de innecesarios
• No realizar la mejor variante de compra
• Pérdida de la garantía de los contratos.
• Alteración de los costos e historial de equipos.
Por lo anteriormente expuesto es que se considera que el presente sistema necesita de una alta seguridad y
protección. Esta es una de las principales razones por las que se decidió usar Oracle, como el servidor de la
base de datos, y Windows NT como sistema operativo; siendo ambos altamente confiables. Existe una
jerarquía de derechos, que rige el uso del sistema, y al gran número de usuarios para el cual está diseñado.
Dentro de esta jerarquía se definieron distintos tipos de usuarios: un administrador del sistema y uno por
cada módulo, siendo estos los únicos con posibilidades de variar la base de datos, también se creó un grupo
para los usuarios del sistema y uno para los usuarios de cada módulo, los cuales sólo tienen posibilidad de
consultar la información.
7. CONCEPCIÓN DEL SISTEMA DE AYUDA
La ayuda debido a los estándares que se han ido implantando mundialmente constituye una parte importante
del sistema. Si este quiere ser competitivo debe ofrecerle al usuario tantas facilidades como se pueda.
En este sistema el usuario tendrá disponible en cada momento ayuda intuitiva y fácil de comprender a la que
podrá acceder con solo presionar la tecla F1 o a través del menú de opciones en la correspondiente opción de
Ayuda. En cada pantalla del sistema al solicitarse ayuda, el sistema le oferce al usuario una ayuda contextual
tratando siempre de estar lo más cerca posible de lo que podría ser la duda del cliente. Además, cada una de
las opciones del sistema, así como las consideraciones que se asumen en la ejecución de ellas, esta
propiamente documentada para evitar cualquier tipo de confusión por parte del usuario. Cada ventana ha
sido diseñada con el objetivo de expresar explícitamente cómo y en que orden debe operar el usuario.

8. DISEÑO INTERFAZ HOMBRE – MÁQUINA
El diseño de las pantallas se ha llevado a cabo bajo los estándares de Windows, usando colores opacos para
que no molesten a la vista. Así como también se han organizado los elementos en cada una de ellas para que
sea más fácil interactuar con el sistema. Los botones de navegación se han ubicado en una barra de
herramienta que es común para todos los formularios.
Las pantallas más importantes del sistema son:
Figura 4. Ventana para confeccionar los procedimientos de los modelos.

Figura 5. Ventana para actualizar la información referente a los proveedores del hospital
.
Figura 6 Ventana para entrar los surtidos al inventario

Figura 6 Ventana para realizar la evaluación de los equipos
Figura 7 Barra de herramientas común para todos los formularios del sistema.

9. CONCLUSIONES.
El trabajo de diploma titulado: Sistema de Gestión Tecnológica Hospitalario desarrollado por los autores ha
cumplido los objetivos propuestos, por cuanto.
• Se llevó a cabo la concepción Sistema de Gestión Tecnológica Hospitalaria en su versión 1.0.con el
análisis, diseño y programación de tres de los subsistemas que lo componen: SMACOR , SGA ,
SADTEC
• Se realizó el estudio sobre las potencialidades que ofrece la herramienta de desarrollo para sistemas de
Gestión de Bases de Datos ORACLE, ofreciendo los elementos para su elección.
• Se realizaron las primeras pruebas de ejecución entre los módulos ofreciendo resultados satisfactorios.
Los beneficios del productos son innumerables. Pero se puede resumir que con la creación, actualización y
mantenimiento de sus bases de datos se sentarán las bases para la creación de Sistemas Expertos con el
objetivo de ofrecer servicios de Diagnóstico Remoto (DR) a todas las Instituciones Hospitalarias de
cualquier país.
Producto de la relevancia del trabajo, cuatro usuarios han hecho solicitud para adquirir la primera versión del
sistema. Tres de ellos son hospitales de referencia de nuestro país, que actualmente tienen instalada la
versión de SMACOR 3.1 (CIREN, Clínica Central Cira García y Hospital Clínico Quirúrgico Hermanos
Ameijeiras ). El cuarto usuario es la empresa productora y comercializadora de productos informáticos del
Ministerio de Salud Publica, CEDISAP.

10. RECOMENDACIONES.
Realizar un sistema de reportes parametrizado para todos los módulos, con el objetivo de que el propio
usuario pueda configurar sus informes, dándole así un alcance infinito en cuanto a la información que puede
ser consultada. Además de que estas salidas sean en su mayoría gráficas.
Ofrecer la posibilidad al módulo de SMACOR la planificación de mantenimiento por áreas dentro del
hospital.
Incluir un sistema de alertas que se disparen de forma automática ante la ocurrencia de determinados
eventos que ocurran, como por ejemplo: mantenimientos atrasados, violaciones de frecuencias y tiempos de
mantenimientos, etc., con el objetivo de avisar al usuario de la ocurrencia de los mismos.
En el módulo de Adquisición de Nuevas Tecnologías se recomienda la inclusión de varios algoritmos
alternativas para la realización de evaluaciones con el objetivo de que el sistema se pueda ajustar a
condiciones específicas.
Realizar un enlace entre el modulo de fiabilidad programado en MATLAB 5.3 y el módulo de
mantenimiento, SMACOR.
Aumentar el acceso para usuarios que solo desean consultar/actualizar la información en estaciones de
trabajo en las cuales no se encuentren instalados las aplicaciones clientes, usando para esto una interfaz
WWW mediante una intranet.
Desarrollar el módulo de Vigilancia de Equipos médicos enlazado a los ya existentes.

11. BIBLIOGRAFÍA
[1] AAMI meeting 1999 (interview). Clinical engineering and information systems. Biomedical
Instrumentation and Technology. Vol 33. # 3. Pp 199-203. U.S.A 1999.
[2] AAMI meeting 1999 (lesson). Integrating clinical engineering and information systems. Biomedical
Instrumentation and Technology. Vol 33. # 4. Pp 295-297. U.S.A 1999.
[3] Adler. D. and et all. Clinical Information System: Consideration in selecting the hospital department
with primary responsibility. Biomedical Instrumentation and Technology.. Vol 29. # 2 .pp 97-105.
U.S.A.1995.
[4] American Hospital Asociation. Manual de Ingeniería en Hospitales. Ed. Limusa. 2 da edición.
México.1975
[5] Anderson T. J. Home health care. A new challenge for clinical engineers. Biomedical
Instrumentation and Technology. Vol 33. # 3. Pp 121-124 . U.S.A 1999.
[6] Baete G. Productivity Improvement in the community hospital. Biomedical Instrumentation and
Technology. Vol 29.# 4 . pp 322-328. U.S.A. 1995.
[7] Blumberg D. F. Service program diagnostic and decision support technology for improving health
technology service efficiency and productivity. Biomedical Instrumentation and Technology. Vol 32. #
4. Pp 370-385 . U.S.A 1998.
[8] Blumberg D. F. Technological developments and approach to improving service quality.
Biomedical Instrumentation and Technology. Vol 33. # 1. Pp 35-44 . U.S.A 1999.
[9] Bridget. A. Mataban. M. Prototype Expert System for infusion pump Maintenance. Biomedical
Instrumentation and Technology. Vol 28. # 1 .pp 19-29. U.S.A. 1994.
[10] Brinkman O. M. In house survival in an asset management climate. Biomedical Instrumentation
and Technology. Vol 32. # 6. pp 425-427. U.S A. 1998.
[11] Capuano M. Koritko Steve. Justifying tracking BMET training. Biomedical Instrumentation and
Technology.. Vol 28.# 6. pp 466-473. U.S.A. 1994
[12] Capuano M. Koritko Steve. Technology Acquisition strategies for clinical engineering. Vol 31.# 4.
pp 335-356. U.S.A. 1997
[13] Capuano M. Koritko Steve. Risk Oriented Maintenance System Biomedical Instrumentation and
Technology. Vol 30. # 1. pp 25-35. U.S.A. 1996.
[14] Cohen T. Benchmark indicators for medical equipment repair and maintenance. Biomedical
Instrumentation and Technology. Vol 29. # 4 . pp 308 -320. U.S.A. 1995.

[15] Cohen T. Computerized management system for clinical engineering. Biomedical Instrumentation
and Technology. Vol 26. # 3 . pp 191 -196. U.S.A. 1992.
[16] Cohen T. Validating medical equipment repairs and maintenance metrics: A progress report.
Biomedical Instrumentation and Technology. Vol 31. #1 pp 23-31. U.S.A .1995.
[17] Cohen T. Validating medical equipment repairs and maintenance metrics: Parts II. Biomedical
Instrumentation and Technology. Vol 32. # 2. pp 136-144. U.S.A 1998.
[18] Dolan M. A. Risk management and medical devices. Biomedical Instrumentation and Technology.
Vol 33. # 4. Pp 331-333. U.S.A 1999.
[19] Fouladinejad F., Roberts R. J. Analysis of training activities of Clinical Engineering in the U.K.
Biomedical Instrumentation and Technology. Vol 32. # 3. Pp 254-270 . U.S.A 1998.
[20] Francour E. D. Learning from a Merger opportunity. Biomedical Instrumentation and Technology.
Vol 32. # 1. Pp 45-49 . U.S.A 1998.
[21] G. Donald. N. Análisis económico en ingeniería. Segunda edición. Mcgrow Hill. 1975
[22] G. I. Johnston. Proposed Information System for management of electromedical
equipment.Computing in biomedical and clinical Engineering. pp 46-56. 1 era ed . U.S.A 1983.
[23] Health Technology. Cost of alternative types of services. Vol 3.# 3 pp 22-32. Winter . U.S.A. 1989
[24]Handbook of Biomedical Engineering.2 nd ed . 1994
[25] Health Technology. Special report on managing service contract, ECRI. Vol 3. # 4 .Winter U.S.A
1989
[26] Health care Technology management. Steris corporation cleaning up in the business of sterilization.
# 6. Vol 7. June. U.S.A .1996
[27] Health Technology. Types of services their advantages and disadvantages.. .Vol 3. # 4 pp 39-21.
Winter U.S.A. 1989
[28] Health care Technology management. # 2. Vol 2. July. U.S.A 1994
[29] Health care Technology management. Vol 3. # 3 June. U.S.A 1995
[30] Health care Technology management. Vol 7. # 11.. June. U.S.A 1997
[31] Health Technology. Special report on technology management: Preparing your hospital for the
1990s, ECRI. Vol 3. #1 U.S.A . Spring 1989.
[32] Hospital Risk Control, ECRI. July 1989.
[33] Informatizar la gestión de mantenimiento ,una necesidad. Revista española de mantenimiento. # 80.
España 1994.
[34] Inspection and preventive maintenace system. 3 rd .ed . ECRI. U.S.A. 1995

[35] James J. P. Equipment management risk rating system based on engineering endpoint. Biomedical
Instrumentation and Technology. Vol 33. # 2. Pp 115-120 . U.S.A 1999.
[36] Keil. R. Ode. The joint Commission´s agenda for change. What does it mean for equipment
managers ? Biomedical Instrumentation and Technology. Vol 28. #1.pp 14-17.. U.S.A 1994.
[37] Leeming. N. M. Fulginiti. V. J. Validity and Clinical Engineering Indicators. Biomedical
Instrumentation and Technology. Vol 31. # 1 pp 33- 42. U.S.A. 1997.
[38]Lerman S. Solving technical challenges in difficult conditions. Biomedical Instrumentation and
Technology. Vol 32. # 6. pp 429-431. U.S.A. 1998.
[39] L. R. Gene. Medical Equipment data retrieval program. Computing in Biomedical and Clinical
Engineering. pp 42-45. 1 rsd edition .U.S.A 1983
[40] Martinez.G.R. Laboratorio de Verificación de Equipos Medicos. Tesis de Maestría.1998. (Material
no publicado)
[41] Massimo F. F.The standanrd “Health care Information System Architecture” and the DHE
middleware International Journal of Medical Informatic. 52. pp 39-51. 1995.
[42] Militello L. Learning to Thing Like User: Using Cognotive Task Analysis To Meets today’s health
care design challenges. Biomedical Instrumentation and Technology. Vol 32. # 5. pp 535-540. U.S.A
1998.
[43] Morris L. R. Consulting for Clinical Engineers. Biomedical Instrumentation and Technology. Vol
32. # 1. pp 71-76. U.S.A 1998.
[44] Mosquera C.G y otros. Disponibilidad y confiabilidad de systemas industriales. de. Univ. UGMA.
Mayo 1995
[45] Mosquera L. Un modelo sencillo de gestión integrada para continuar mejorando la administracion
hospitalaria. Revista salvadoreña de mantenimiento hospitalario. # 3. pp 7-13. El Salvador. 1996
[46] Navarrete. P. E Treto O. el MAC, un sistema para evaluar la calidad del mantenimiento. (material
no publicado)
[47] Nipa H. J. Biomedical equipment management using a microcomputer. Computing in biomedical
and clinical Engineering. pp 31-37. 1 srt ed . U.S.A. 1983.
[48] O´dea T and et all. Clinical engineering management and annotated bibliography 1989-1993.
Biomedical Instrumentation and Technology.. Vol 28 # 2. pp 101-111. U.S.A .1994.
[49] Organización Panamericana de la Salud.Ingeniería y Mantenimiento.1989.
[50] Portuondo. P. F. Economía de Empresas Industriales. Tomos I y II. Editorial Pueblo y
Educación. Cuba.1983

[51] Prieto. H. F, Rosete. U.R.S. Ingeniería Clínica . Fundamentos para la implementación de la
tecnología en los hospitales. Gac Med Mexicana. Mexico. 1993
[52] Procedimiento para la evaluación de proveedores. CCEEM 1995. (material no publicado)
[53] Rodríguez.D. E. Sánchez. M. C. Miguel C.A. Proyecto de Gestión tecnológica para el sistema
hospitalario cubano. Publicación electrónica IV Simposio Latinoamericano de Bioingeniería.
Bucaramanga.Colombia. 1994.
[54] Rosoeu E., Adam J., Beatrice F. The Endotester TM : “A virtual Instrumentation” Evaluation
System for Fiberoptic Endoscopes. Biomedical Instrumentation and Technology. Vol 32. # 5. pp 480-
487. U.S.A 1998.
[55] Shaffer. J. M. Clinical Engineering. Past Experience and future strategies. Biomedical
Instrumentation and Technology. Vol 28. # 3. pp 181-185. U.S.A 1995
[56] Shaffer. D. M, Shaffer. J. M. Support for Biomedical equipment decision making. Biomedical
Instrumentation and Technology.. Vol 28. # 6 pp 482-201. U.S.A .1994.
[57] Sistema Informático de Gestión del Equipamiento Biomédico. En CD ROM Sistema de Gestión y
Evaluación del Equipamiento Biomédico (BEAM) de la Comunidad Económica Europea. 1995.
[58] Stiefel. H. R. Managing Assertively: Specific tactics for clinical engineering managers. Biomedical
Instrumentation and Technology. Vol 29. #2 pp 89-96. U.S.A 1995
[59] Stiefel H. R, Rizkala. E. The element of a complete product evaluation. Biomedical Instrumentation
and Technology). . Vol 28. # . pp 482-201. U.S.A 1994 .
[60] Sue B. M. Designing medical devices to reduce the likelihood of error. Biomedical Instrumentation
and Technology. Vol 33. # 2. Pp 108-113 . U.S.A 1999.
[61] Tawfik. Evaluating medical equipment needs: a simple algorithm. Biomedical Instrumentation and
Technology. Vol 28. # 3 pp 187-194. U.S.A.1994.
[62] User´s guide Inspection and preventive maintenance task software. 2 nd ed. ECRI U.S.A.1995.
[63] Veluchamy. S. A proposed computer assisted preventive maintenance system. Computing in
Biomedical and clinical Engineering. 57-61. 1rsd de. 1983
[64] Welch L. W. Human Factors Analysis and Dedign Support in Medical Devices Development.
Biomedical Instrumentation and Technology. Vol 32. # 1. pp 77-82. U.S.A 1998.
[65] Welch L. W. Human factors in the FDA quality system regulation. Biomedical Instrumentation
and Technology. Vol 32. # . pp . U.S.A 1998.
[66] Welch L. W. Human factors usability test and evaluation. Biomedical Instrumentation and
Technology. Vol 32. # 2. Pp 183-187 . U.S.A 1998.

[67 ]Welch L. W. Human factors in the health care facility. Biomedical Instrumentation and
Technology. Vol 32. # 3. Pp 311-316 . U.S.A 1998.

INDICE
1. INTRODUCCIÓN. ................................................................................................. 3
2. ANTECEDENTES.................................................................................................. 5
CAPÍTULO # 1 FUNDAMENTACIÓN TEÓRICA Y ELECCIÓN DE LA
HERRAMIENTA DE DESARROLLO.................................................................. 6
1.1 LA GESTIÓN TECNOLOGÍCA HOSPITALARIA. ......................................... 6
1.2 TENDENCIAS ACTUALES SOBRE EL USO DE LA INFORMATICA EN
EL SECTOR DE SALUD Y EN LA ESPECIALIDAD DE INGENIERÍA
CLÍNICA............................................................................................................. 6
1.2.1 OPTIMIZACIÓN DE LOS SERVICIOS TÉCNICOS USANDO LAS
NUEVAS TECNOLOGÍAS DE LA INFORMACIÓN Y DIAGNOSTICO
REMOTO DEL EQUIPAMIENTO BIOMEDICO............................................. 7
1.3 LOS SISTEMAS DE INFORMACIÓN HOSPITALARIA (HIS).................... 15
1.4 FUNDAMENTOS DE LA ELECCIÓN DE LA HERRAMIENTA DE
PROGRAMACIÓN........................................................................................... 21
CAPÍTULO # 2 DESCRIPCIÓN Y CONCEPCIÓN DEL SISTEMA DE
GESTIÓN TECNOLÓGICA HOSPITALARIA................................................. 27
CAPÍTULO # 3 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE
MANTENIMIENTO ASISTIDO POR COMPUTADORAS ORIENTADO A
RIESGO (SMACOR). ............................................................................................ 33
3.1 DESCRIPCIÓN DEL OBJETO DE AUTOMATIZACIÓN............................. 33
3.2 TABLA DE EVENTOS .................................................................................... 34
3.3 DIAGRAMA DE CONTEXTO EXTRUCTURADO DEL SMACOR ............ 37
3.4 DIAGRAMA PRELIMINAR DEL SMACOR ................................................. 39
3.5 FACTIBILIDAD ECONÓMICA ...................................................................... 40
3.6 PLANIFICACIÓN DEL PROYECTO.............................................................. 40
3.7 ANÁLISIS ......................................................................................................... 41
3.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES NUEVO
DIAGRAMA DE CONTEXTO ....................................................................... 41
3.7.2 DIAGRAMA CERO....................................................................................... 43
3.7.3 DIAGRAMA UNO......................................................................................... 44
3.7.4 DIAGRAMA DOS ......................................................................................... 45
3.7.5 DIAGRAMA 2.1 ............................................................................................ 46
3.7.6 DIAGRAMA 2.2 ............................................................................................ 47
3.7.7 DIAGRAMA 2.3 ............................................................................................ 48
3.7.8 DIAGRAMA TRES ....................................................................................... 49
3.7.9 DIAGRAMA CUATRO................................................................................. 50
3.7.10 DIAGRAMA 4.1 .......................................................................................... 51
3.7.11 DIAGRAMA 4.2 .......................................................................................... 52
3.7.12 DIAGRAMA 4.3 .......................................................................................... 53
3.8 DISEÑO............................................................................................................. 54
3.8.1 GRAFO CONVERSACIONAL ..................................................................... 54
3.8.2 ESTADOS ...................................................................................................... 56
3.8.3 DISEÑO LÓGICO GLOBAL ........................................................................ 58
3.8.4 DER ................................................................................................................ 60
3.9 CONCLUSIONES............................................................................................. 61

CAPÍTULO # 4 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE
ALMACENES (SGA)............................................................................................. 62
4.1 DESCRIPCIÓN DEL OBJETO DE AUTOMATIZACIÓN............................. 62
4.2 TABLA DE EVENTO DEL SGA..................................................................... 65
4.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO. ...................................... 66
4.4 DIAGRAMA PRELIMINAR............................................................................ 67
4.5 FACTIBILIDAD ECONÓMICA ...................................................................... 68
4.6 PLANIFICACIÓN DEL PROYECTO.............................................................. 68
4.7 ANÁLISIS ......................................................................................................... 69
4.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES................................ 69
4.7.2 DIAGRAMA CERO....................................................................................... 70
4.7.3 DIAGRAMA UNO......................................................................................... 71
4.7.4 DIAGRAMA DOS ......................................................................................... 72
4.7.5 DIAGRAMA TRES ....................................................................................... 73
4.7.6 DIAGRAMA CUATRO................................................................................. 74
4.8 DISEÑO............................................................................................................. 75
4.8.1 GRAFO CONVERSACIONAL ..................................................................... 75
4.8.2. ESTADOS ..................................................................................................... 76
4.8.3 DISEÑO LÓGICO GLOBAL ........................................................................ 77
4.8.4 DER ................................................................................................................ 78
4.8.5 CONCLUSIONES.......................................................................................... 79
CAPÍTULO # 5 ANÁLISIS Y DISEÑO DEL SUBSISTEMA DE
ADQUISICIÓN DE TECNOLOGÍAS (SADTEC). ............................................ 80
5.1 DESCRIPCION DEL OBJETO DE AUTOMATIZACION............................. 80
5.2 TABLA DE EVENTOS .................................................................................... 90
5.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO ....................................... 91
5.4 DIAGRAMA PRELIMINAR............................................................................ 92
5.5 FACTIBILIDAD ECONOMICA ...................................................................... 93
5.6 PLANIFICACION DEL PROYECTO.............................................................. 94
5.7 ANALISIS ......................................................................................................... 95
5.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES................................ 95
5.7.2 DIAGRAMA CERO....................................................................................... 96
5.7.3 DIAGRAMA UNO......................................................................................... 97
5.7.4 DIAGRAMA DOS ......................................................................................... 97
5.7.5 DIAGRAMA 2.1 ............................................................................................ 98
5.7.6 DIAGRAMA TRES ..................................................................................... 98
5.7.7 DIAGRAMA CUATRO................................................................................. 99
5.7.8 DIAGRAMA CINCO................................................................................... 100
5.8 DISEÑO........................................................................................................... 101
5.8.1 GRAFO CONVERSACIONAL ................................................................... 101
5.8.2 ESTADOS .................................................................................................... 102
5.8.3 DISEÑO LÓGICO GLOBAL ...................................................................... 102
5.8.4 DER .............................................................................................................. 104
5.7 CONCLUSIONES........................................................................................... 105
6. CONCEPCIÓN DEL SISTEMA DE SEGURIDAD Y PROTECCIÓN..... 106
7. CONCEPCIÓN DEL SISTEMA DE AYUDA ................................................. 106
8. DISEÑO INTERFAZ HOMBRE – MÁQUINA .............................................. 107
9. CONCLUSIONES............................................................................................... 110

10. RECOMENDACIONES................................................................................... 111
11. BIBLIOGRAFÍA............................................................................................... 112
12. ANEXOS ............................................................................................................117
Anexo 1. Figuras de imágenes seleccionadas de artículos originales ................... 117
Anexo 2. SMACOR............................................................................................... 121
Anexo 3. SGA........................................................................................................ 154
Anexo 4. SADTEC ................................................................................................172