gestion tecnologica hospitalaria

1

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

2

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.

3

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).

4

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.

5

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.

6

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.

7

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.

8

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.

9

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:

10

Modulo de Gestión de Configuración:

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

Modulo de soluciones:

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.

Modulo de análisis de tendencias:

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.

Modulo de control de programas:

Su función es la de controlar la realización de, y la adquisición de nuevas versiones.

Modulo compartido de coordinación de recursos :

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

11

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.

12

Tecnología Bases de la

justificación de costo

Automatización y computadoras de

oficina

Telecomunicaciones

Electrónica Medica Automatización de edificios y equipos

de explotación Ganancia general

55 % 35 % 50 % 64 %

Captura y retensión de conocimiento y especialización

41 % 45 % 48 % 55 %

Evita llamadas de servicios innecesarias

31 % 43 % 21 % 34 %

Reducción de costos y tiempos de entrenamientos

21 % 18 % 14 % 21 %

Reducción de tiempos medios de reparaciones y diagnósticos

37 % 28 % 19 % 34 %

Reducción de no soluciones a problemas debido a partes y componentes y habilidades técnicas

31 % 21 % 22 % 20 %

Otras (aumento de ganacias, valor añadido de productos)

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])

13

Beneficios Efectos Proveedor de servicios

Cliente

Reduce los tiempos de entrenamientos del personal de mantenimiento

Reduce los costos de mano de obra por cada técnico dedicado a mantenimiento

X

Reduce o elimina el esfuerzo requerido para analizar datos

Reduce los requerimientos de personal

X

Reduce o elimina el esfuerzo requerido para recolección de datos

Reduce los requerimientos de personal

X

Reduce el transcurso de tiempo requerido para evaluar y diagnosticar un problema

• Reduce los requerimientos de personal.

• Mejora la utilización técnica de equipos.

X X

Mejora la predicción de fallos para iniciar mantenimiento preventivos previos a los fallos de emergencia

• Reduce los requerimientos de personal.

• Mejora la utilización técnica de equipos.

X

Mejora los tiempos de respuestas

Mayor satisfacción y retención del cliente.

X X

Mejor servicio y diferenciación

Potencial para ganar nuevos mercados y mejorar posiciones en mercados actuales

X

Mejora la asignación de recursos

Reduce los costos de personal e inventario de partes y componentes

X

Posibilidad de ofrecer servicios remotos en áreas inaccesibles

Reduce los costos de personal e inventario de partes y componentes

X X

Reduce los servicios improductivos debido a ala falta de partes de componentes

Reduce los costos de personal

X X

Tabla 2. Beneficios primarios e impacto del DR en el servicio de equipos (Fuente: [9]).

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.

14

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.

15

• 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.

16

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.

17

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.

18

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

19

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:

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.

HCS relativas a las actividades:

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

20

HSC relativo a los recursos:

Responsable por proporcionar y manejar los datos relativos a los recursos de la organización de salud

HCS de autorización e identificación de usuarios :

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]

21

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 Oracle™s. 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

22

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 conectados al servidor

1,399.00

Para 10 usuarios conectados al servidor

1,999.00

Para 25 usuarios conectados al servidor

3,999.00

Tabla 3. Licencias de SQL Server.

Licencia Precio (USD) Por usuario

conectado a un Servidor

(Precio por usuario)* 7 = 4200

Precio por usuario=600 Datos seleccionado de la pagina web de Oracles

el día 22/06/2000 Tabla 4 Licencias de Oracle.

.

23

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

24

• 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

25

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

26

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.

27

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.

28

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,

29

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

30

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.

31

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.

32

Figura 3 Diagrama Cero del Sistema de Gestión Tecnológica.

Sistema de Mantenimiento

Orientado a Riesgo

Sistema de Adquisición de

Tecnología

Sistema de Gestión de

Almacén

País

FabricanteProveedor

Equipo

Modelo

Surtido

Cuenta

Unidad Medida

Orden Trabajo

Consumo Real

Plan

Consumo

Centro Costo

Area

Genérico

Eventos de este módulo Eventos de este módulo

Eventos de este módulo

33

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).

34

3.2 TABLA DE EVENTOS

Sistema de Mantenimiento Asistido por Computadoras Orientado a Riesgo (SMACOR)

Tabla de Eventos Fecha: 20/06/2000

No Evento Origen Destino Documento Entrada

Documento Salida

1 Adquisición de un equipo médico

Proveedor Ficha del Equipo

Cliente Reporte de Avería

2 Rotura de un Equipo

Técnico Orden de Trabajo Correctiva

3 Fin de 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. Procedimiento.

6 Nuevo Genérico Departamento de Ingeniería Clínica

Datos Genérico

7 Nuevo Grupo Departamento de Ingeniería Clínica

Datos Grupo. Procedimiento.

8 Nuevo Técnico Departamento de Ingeniería Clínica

Datos Técnico

9 Necesidad de Conocer Cantidad de Intervenciones

Departamento de Ingeniería Clínica

Cantidad Intervenciones

10 Necesidad de Conocer Duración de las Intervenciones


Duración de las Intervenciones

11 Necesidad de Conocer Tiempo Promedio de Respuesta


Tiempo Promedio de Respuesta

12 Necesidad de Conocer Tiempo de Cambio Estado Promedio


Tiempo de Cambio Estado Promedio

35

13 Necesidad de Conocer Consumo de Surtidos


Consumo de Surtidos

14 Necesidad de Conocer Cumplimiento del Correctivo


Cumplimiento del Correctivo

15 Necesidad de Conocer Horas Totales de Correctivo


Horas Totales de Correctivo

16 Necesidad de Conocer Solicitudes Verdaderas de Correctivo


Solicitudes Verdaderas de Correctivo

17 Necesidad de Conocer Cantidad de Equipos Fuera de Servicio


Cantidad de Equipos Fuera de Servicio

18 Necesidad de Conocer Utilización Técnica del Hospital


Utilización Técnica del Hospital

19 Necesidad de Conocer Utilización del Parque de Equipos


Utilización del Parque de Equipos

20 Necesidad de Conocer Utilización del tiempo de los técnicos


Utilización del tiempo de los técnicos

21 Necesidad de Conocer Listado de Proveedores


Listado de Proveedores

22 Necesidad de Conocer Listado de Equipos


Listado de Equipos

23 Necesidad de Conocer Expediente del equipo


Expediente del equipo

36

24 Necesidad de Conocer Listado del Personal


Listado del Personal

37

3.3 DIAGRAMA DE CONTEXTO EXTRUCTURADO DEL SMACOR

Departamento de Ingeniería Clinica

Gestión Tecnológica en un

Sistema de Información Hospitalaria

ProveedorTécnico

Cliente

1

2

2.1

3 45

67

810

11

12

13

1415

1617

1820

21

228 9

19

23

24

5.1

7.1

38

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

39

3.4 DIAGRAMA PRELIMINAR DEL SMACOR

PROCEDIMIENTO

Período Análisis

Listado Proveedores

Período Análisis

Período Análisis

Período Análisis Cantidad Equipos

Fuera ServicioPeríodo Análisis

Período Análisis

HorasTotales de Correctivo

Cumplimiento Correctivo

Período Análisis

Consumo Surtidos

Reporte de Avería

Procedimiento

Datos Grupo

Cantidad de Intervenciones

Período Análisis

Período Análisis

Período Análisis

Duración Intervenciones

Período Análisis

Datos Técnico

Procedimiento

Datos Genérico

Datos Modelo

Datos Proveedor

Resultados Reparación

Orden de Trabajo Correctiva

21

20

19

18 17 16 15 14 13

12

11

10

9

8

7

22

23

24

1 2 3 4 5 6

Ficha del equipo

Período Análisis

Tiempo Promedio Respuesta

Período Análisis

Tiempo Cambio Estado Promedio

Solicitudes Verdaderas Correctivo

Utilización Técnica del Hospital

Utilización del Parque de Equipos

Utilización Tiempo Técnicos

Período Análisis

Listado Equipos

Período Análisis

Expediente Equipos

Listado Personal

Período Análisis

EQUIPO

MODELO

GENERICO

OT AVERIA

PERSONAL

GRUPO

PROVEEDOR

PROCEDIMIENTO GRUPO

CONSUMO

40

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

41

3.7 ANÁLISIS 3.7.1 DIAGRAMA DE FLUJO DE DATOS POR NIVELES NUEVO DIAGRAMA DE

CONTEXTO

Gestión Tecnológica en un

Sistema de Información Hospitalaria

Cliente

Proveedor



Técnico

12

2.13

45

6

7

810

11

12

13

1415 16

1718

20

21

22 89

1923

24

5.1

7.1

25

26

2930 31

32

27

28

3841

29

30

31

32

33

34

35

36

37

39

40

42

43

44

SGA

42

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

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

EquipoPersonal

Plan

Grupo Modelo

OT

Consumo

Consumo Real

1 22.13

4

5

5.1

6

77.1

8

3839404142

34

35

36

37

91011121314151617181920212223242526

2728293031323344

44

3.7.3 DIAGRAMA UNO

1.1 Actualizar

Equipo

1.2 Actualizar Proveedor

1.5 Actualizar

Grupo

1.4 Actualizar Genérico

1.3 Actualizar

Modelo

1.6 Actualizar

Técnico

1

8

4

5

5.1

7

7.1

6

Equipo

Proveedor

Personal

Modelo

Genérico

Grupo Procedimiento

Procedimiento Grupo

45

3.7.4 DIAGRAMA DOS

2.1 Preventivo

2.2 Correctivo 2.3

Estado del Mantenimiento

41

42

43

38

23

2.1

39

40

Modelo

Consumo

Consumo Real

Equipo

Procedimiento

PlanOT

Personal

Avería

46

3.7.5 DIAGRAMA 2.1

2.1.1 Emitir Orden

Preventiva

2.1.2 Recibir

Resultados de la

Intervención

2.1.3 Obtener

Probabilidad de Rotura

2.1.4 Obtener Nivel de Prioridad

38 41

42 43

Modelo

Equipo

Personal

Consumo

Consumo Real

Avería

Plan

OT

Procedimiento

47

3.7.6 DIAGRAMA 2.2

2.2.1 Recepcionar Reporte de

Avería

2.2.2 Emitir Orden

Correctiva

2.2.3 Recibir

Resultados de la

Reparación

Equipo

AveríaModelo

Personal

Consumo Real

OT

2

2.1 3

48

3.7.7 DIAGRAMA 2.3

2.3.1 Planificar

Mantenimiento Preventivo

2.3.2 Obtener Surtidos

Planificados

Equipo

Modelo

Personal

OT

Consumo

Plan

Procedimiento

4039

49

3.7.8 DIAGRAMA TRES

3.1 Obtener

Listado de Equipos

3.2 Obtener

Listado de Proveedores

3.4 Obtener

Expediente del Equipo

3.3 Obtener

Listado de Técnicos

35

37

34

36

Equipo

Proveedor

Personal

Modelo

Consumo Real

Genérico OT

50

3.7.9 DIAGRAMA CUATRO

4.1 Obtener Informes

Preventivos

4.2 Obtener Informes

Correctivos

4.3 Obtener Informes Generales

GenéricoAveria

Equipo

Personal

Plan

Modelo

OTConsumo

Consumo Real

19202122232425

26

1817161514131211109

44

31

3233

27282930

51

3.7.10 DIAGRAMA 4.1

4.1.1 Emitir Informe Cantidad de

Intervenciones

4.1.2 Emitir Informe Duración de

las Intervenciones

4.1.7 Emitir Informe de Consumo de Surtidos

Genérico

Equipo

Personal

Plan

Modelo

OT

Consumo

Consumo Real

4.1.3 Emitir Informe Cumplimiento

del Plan

4.1.8 Emitir Informe Eficiencia de Especialista

4.1.4 Emitir Informe

Tiempo Promedio de

Respuesta

4.1.6 Emitir Informe de Análisis de

Costos


Tiempo de Cambio de

Estado

19 20 21

22

232425

26

52

3.7.11 DIAGRAMA 4.2

4.2.1 Em itir Inform e

Cantidad de Intervenciones


Duración de las

Intervenciones

4.2.8 Em itir Inform e Horas Totales de Correctivo

Equipo

Personal

ModeloOT

Consum o Real

4.2.3 Em itir Inform e Cum plim iento del Correctivo

4.2.10 Em itir Inform e Eficiencia de Especialista


Tiem po Prom edio de

Respuesta

4.2.7 Em itir Inform e Consum o de

Suridos


Análisis de Costos


Tiem po Cam bio Estado

Prom edio


Solicitudes Verdaderas

9 10 11

12

13

141516

18

17

Averia

Genérico

53

3.7.12 DIAGRAMA 4.3


Utilización Técnica Hospital

4.3.2 Emitir Informe Utilización del

Parque de Equipos

4.3.7 Emitir Análisis de Eficiencia

del Departamento

Genérico

Equipo

Personal

Modelo

OT

4.3.3 Emitir Análisis

de Costos Generales

4.3.8 Emitir Informe Cantidad de

Equipos fuera de servicio


Tiempo Cambio Estado

Promedio

4.3.6 Emitir Análisis de Utilización vs Eficiencia

4.3.5 Emitir Informe Utilización del tiempo de los

técnicos

27 28 29

30

313233

44

Averia

Consumo Real

54

3.8 DISEÑO 3.8.1 GRAFO CONVERSACIONAL

5

39 40

6

4342

41

17

2223 24

25 2627 28 29

3130

18

35 36 37 38

4

2

16151412

13

212019

11

0

3

32 3334

1

7 8 910

55

32 33

49

3453 55

54

47

44 45 46

56 57 5958

51 52

50

41

82

0

83 84 85817978

48

39

64

0

65 66 6763626160

40

0

70 696877767574737271

80

56

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

57

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

Preventivo 4.1.5

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

Correctivo 4.2.5

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

58

3.8.3 DISEÑO LÓGICO GLOBAL

Nombre del Fichero Inicial

Descripción

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}

59

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}

60

3.8.4 DER

Especialidad

Grupo

Marca

Personal

Brigada

Calificación

País

Proveedor Fabricante

Plan

Aplazo

Surtido

Genérico

Modelo

Fallo

Equipo

Estado Equipo

Orden de Trabajo

Orden Terrminada

Alerta

Subdirección

Area

Tipo Tarea

Alimentación

Parámetros

Unidad Medida

Intervención

Cuenta

Centro de Costo

TareaAvería

Cliente

Estado Orden

B

A

Leyenda:

Relación de uno a unoRelación de muchos a muchos

Relación de uno a muchos entre B y A respectivamente

61

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.

62

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.

63

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

64

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.

65

4.2 TABLA DE EVENTO DEL SGA. Sistema de Gestión de Almacén

TABLA DE EVENTOS Fecha: 20/06/2000

No

Evento

Origen

Destino

Documento Entrada

Documento Salida.

1 Comprar Artículos

Comprador Factura

2 Solicitar Productos

Jefe del Centro de Costo

Solicitud de Productos

3 Entregar Artículos

Jefe del Centro de Costo

Entrega de Artículos

4 Ajustar Inventario Jefe de Almacén

Ajuste de Inventario

5 Nuevo Producto Jefe de Almacén

Datos del producto

6 Nueva Cuenta Jefe de Almacén

Datos de la Cuenta

7 Necesidad de Adquirir Artículos

Comprador Pedido de Artículos

8 Obtener Artículos Existentes

Jefe de Almacén

Artículos Existentes

9 Conocer Adquisiciones Hechas

Jefe de Almacén

Artículos Comprados

10 Conocer Ajustes de Inventario Realizados

Jefe de Almacén

Ajustes de Inventario

11 Conocer Entregas Hechas

Jefe de Almacén

Entregas Hechas

12 Obtener Solicitudes Recibidas

Jefe de Almacén

Solicitudes Recibidas

13 Obtener Pedidos Hechos

Jefe de Almacén

Pedidos Hechos

66

4.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO.

67

4.4 DIAGRAMA PRELIMINAR.

68

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

69

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

70

4.7.2 DIAGRAMA CERO

71

4.7.3 DIAGRAMA UNO

72

4.7.4 DIAGRAMA DOS

73

4.7.5 DIAGRAMA TRES

74



0

17

2

23 24 2522 29 302826

31

18 20 2119

32

10 1197 8 161412 13 15

4 6

453533 34 3836 37 39 40 41 42 43 44

5

654

0

0

0

3127

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

Despacho

Recepción

Compra

Devolución

PosiciónSubestante

Surtido

Ajuste

Estado

Cliente

Genérico

Estante

Almacén

Cuenta

Unidad Medida

Pedido OrdenSolicitud

Proveedor Fabricante

Causa

Subgenérico

Específico

Consecutivo

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 Máxima

Preguntas del 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 FABRICANTEModelo MODELO A MODELO B MODELO C

Categorías Alcance Comentar Alcance Come Alcance ComeSEGURIDAD 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

Tabla 7

Para realizar la Evaluación del producto: 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 equipo-paciente, 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{∑=

m

i

ic1

} (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.

v=

tenerbuenopacientealatenciónladecalidadlaaumenta

vidadesoporte

....2/1.........4/3

.........1 (2)

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.

g=

ingresosdegeneradoringresosdegeneradorno

....1.1........1

(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: 20/06/2000

No Evento Origen Destino Documento Entrada

Documento Salida

1 Definir Equipo Ideal Evaluador Características Ideales

Evaluador Cuestionario 2 Evaluar Proveedor Evaluador Evaluación

Proveedor Evaluador Parámetros

Evaluación 3 Evaluar Producto

Evaluador Evaluación Producto

Evaluador Tipo Equipo 4 Seleccionar Equipo Evaluador Propuesta Compra Proveedor Solicitud Contrato 5 Contratar Servicio Proveedor Contrato Evaluador Características

Servicio 6 Evaluar Servicio

Evaluador Evaluación Servicio

7 Registrar Servicio Departamento de IC

Servicio Prestado

8 Necesidad de Conocer Expediente del Proveedor

Departamento de IC

Expediente

9 Necesidad de Conocer Contratos

Departamento de IC

Listado Contratos

10 Necesidad de Conocer Evaluaciones de Producto

Departamento de IC

Listado Evaluaciones Producto

11 Necesidad de Conocer Evaluaciones de Proveedor

Departamento de IC

Listado Evaluaciones Proveedores

12 Necesidad de Conocer Evaluaciones de Servicio

Departamento de IC

Listado Evaluaciones Servicio

Evaluador Parámetros de decisión

13 Renovar Departamento

Evaluador Cantidades a comprar

14 Definir Parámetros de Evaluación de Producto

Evaluador Parámetros Producto

15 Definir Preguntas para el Fabricante

Evaluador Preguntas Fabricante

16 Definir Términos de Contrato

Evaluador Términos Contrato

5.3 DIAGRAMA DE CONTEXTO ESTRUCTURADO

Contrato

Evaluación Producto

Listado Evaluaciones Servicio Listado Evaluaciones Proveedores Listado Evaluaciones de Producto

Listado Contratos

Expediente

Servicio Prestado

Solicitud Contrato

Evaluación ServicioPropuesta Compra

Cuestionario

Características Ideales

Parámetros Evaluación Tipo Equipo

Evaluación Proveedor

Cantidades a Comprar

Parámetros de Decisión

Características Servicio


TecnologíasEvaluador

Proveedor

Departamento de ICParámetros Producto

Preguntas Fabricante

Términos Contrato

5.4 DIAGRAMA PRELIMINAR

PROVEEDOR



Listado Contratos

Expediente

Servicio Prestado

Evaluación Servicio


Contrato

Solicitud Contrato

Propuesta Compra

Tipo Equipo



Cuestionario Características Ideales

1 2 3 4

15

5

6

7

9

14

1012

16

Parámetros Evaluación



Listado Evaluaciones Producto

EQUIPO IDEAL

EVALUACION PROVEEDOR

PREGUNTAS FABRICANTE

PARAMETROS PRODUCTO

EVALUACION PRODUCTO

EQUIPO

CONTRATO

TERMINOS CONTRATO

EXPEDIENTEEVALUACION SERVICIO

813

11

Parámetros de Producto

Preguntas Fabricantes

Términos Contrato

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

F = 420 * FDE/S

F= 420 * 22

F= 9240

MF=9.24

CH = 2

CH = TDESESF

TDES = CHESF

TDES = 18 meses

CTP = CHM * ESF

= 396 * 36.21

CTP = 14 339.16

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



Análisis Costo Servicio

Listado Evaluaciones Proveedores Listado Evaluaciones de Producto

Propuesta DecisiónPropuesta Baja

Equipo a Comprar Equipo a Analizar Baja

Contrato a Analizar


Listado Contratos

Expediente

Servicio Prestado


Evaluación ServicioPropuesta Compra

Cuestionario

Parámetros Evaluación Tipo Equipo




Parámetros ProductoPreguntas Fabricante

Términos Contrato

Contrato

Solicitud Contrato


TecnologíasEvaluador

Proveedor

Departamento de IC

SMACOR

SGA

5.7.2 DIAGRAMA CERO

Propuesta Decisión

Equipo a Analizar Baja Parámetros de Decisión

Características Servicio Características Ideales

Tipo Equipo

Parámetros Evaluación

Cuestionario


Propuesta Compra Evaluación Servicio

Evaluación Producto Evaluación Proveedor

Expediente

Listado EvaluacionesServicio


Listado Evaluaciones de Producto

Servicio Prestado

Contrato

Términos Contrato

Preguntas Fabricante

Parámetros Producto

1 Definir

Parámetros de

Evaluación

2 Gestionar Contratos

3 Evaluar

5 Realizar Análisis Costo /

Beneficio

4 Emitir

Listados

PROVEEDOR

EQUIPO IDEAL



PARAMETROS PRODUCTO

EQUIPO

CONTRATO

EXPEDIENTE

EVALUACION SERVICIO

EVALUACION PRODUCTO

TERMINOS CONTRATO

Solicitud Contrato

Listado Contratos

Contrato a Analizar

Equipo a Comprar

Propuesta Baja


ORDEN

5.7.3 DIAGRAMA UNO

5.7.4 DIAGRAMA DOS

Servicio Prestado

Contrato

Solicitud Contrato

2.1 Contratar

2.2 Registrar Servicio

EXPEDIENTE

EQUIPO

PROVEEDOR

CONTRATO

TERMINOS CONTRATO

Preguntas Fabricante Parámetros Evaluación

Términos Contrato

1.1 Definir

Preguntas Fabricantes

1.2 Definir

Parámetros Producto

1.3 Definir

Términos Contrato

PREGUNTAS FABRICANTE PARAMETROS

PRODUCTO

TERMINOS CONTRATO

Escoger Parámetro

Parámetro

5.7.5 DIAGRAMA 2.1

5.7.6 DIAGRAMA TRES

Propuesta Compra




Cuestionario

Tipo Equipo Parámetros

Evaluación

Parámetrosde decisión



3.1 Definir

Equipo Ideal

3.2 Evaluar

Proveedor

3.3 Evaluar Producto

3.4 Evaluar Servicio

3.5 Renovar

Departamento

EQUIPO IDEAL

EVALUACION SERVICIO

TERMINOS CONTRATO


PROVEEDOR

EQUIPO

CONTRATO

EVALUACION PRODUCTO


PARAMETROS PRODUCTO

3.6 Seleccionar

Equipo

EXPEDIENTE


Contrato

Solicitud Contrato

2.1.1 Solicitar Contrato

2.1.2 Registrar Contrato

EQUIPO

PROVEEDOR

CONTRATO

TERMINOS CONTRATO


Opción Informe

Expediente


Listado Evaluaciones de Producto

Listado Contratos


4.1 Emitir Listado

Evaluaciones Servicio

4.2 Emitir Listado

Evaluaciones de Producto

4.3 Emitir Listado

Contratos

4.4 Emitir Listado

Evaluaciones Proveedores

4.5 Emitir

Expediente

Escoger Informe

EVALUACION SERVICIO

EVALUACION PRODUCTO

CONTRATO


PROVEEDOR

EQUIPO

EXPEDIENTE

5.7.8 DIAGRAMA CINCO

Propuesta Decisión

Equipo a Comprar

Equipo a Analizar Baja

Propuesta Baja


Opción Tipo

5.1 Analizar Servicio

5.2 Analizar

Estado de Equipo

5.3 Analizar

Rentar vs Comprar

EQUIPO

ORDEN

EXPEDIENTE

Escoger Tipo de Análisis

Contrato a Analizar


64 7

7.1 7.26.36.26.11.1 1.2 1.3 1.4 1.5

1 32

0

0

4.1 4.2 4.3 4.4 4.5 4.6 4.6

5

2

2.82.72.32.2

0

2.4 2.5 2.62.12.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

Evaluación Modelo

Equipo IdealEvaluador


Pregunta

Categoría Proveedor

Proveedor

Característica Técnicas

Modelo

Parámetro Producto

Categoría Producto

Ocupación

Tipo Servicio


Término Contrato

País

Equipo

Fabricante

Normas Técnicas

Categoría Costo/Ganacia

ComercializaciónPosible Término

Contrato

Contrato Servicio

Contrato Compra

Fecha Servicio

Genérico

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. 1era 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. 1rsd 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

gestion tecnologica hospitalaria

Documents

Transcript of gestion tecnologica hospitalaria