Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios.

Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 1 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 2 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 3 ESCUELA TÉCNICA SUPERIOR DE INGENIERÍA INFORMÁTICA GRADO EN INGENIERÍA DEL SOFTWARE Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Computerized study and implementation of logistics systems applied to hospital settings. Realizado por Francisco José Ruiz Nieto. Tutorizado por Javier López Muñoz. Departamento Lenguajes y Ciencias de la Computación. UNIVERSIDAD DE MÁLAGA MÁLAGA, 8 de 2015 Fecha defensa: El Secretario del Tribunal Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 4 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 5 Resumen. Haciendo uso de las nuevas tecnologías, los Servicios Centrales del SAS quieren optimizar, la logística de todos y cada unos de sus centros sanitarios, todo ello dentro de una política de centralización, que les permita tener acceso a la información logístico-económica de cada centro de Andalucía, en tiempo real. Al mismo tiempo se quieren modernizar los procesos implicados en los circuitos actuales de la logística, para lo cual se integran: • En las plantas de hospitalización sistemas de almacenamiento Kanban: cajones con doble compartimiento, etiquetados con códigos de barra y con gestión de abastecimiento mediante PDAs o pequeñas tabletas electrónicas. • En los almacenes de las Farmacias de los grandes centros hospitalarios, para la gestión de la unidosis, se quiere implantar el uso de armarios electrónicos Kardex, para ayudar a la preparación de los carros de unidosis. • En las unidades con pacientes críticos (UCI, Urgencias, Oncología, con uso habitual de sustancia psicotrópicas), armarios electrónicos, con sistemas de registro de usuario que retiran los fármacos. • Aplicación corporativa de gestión de la historia única de pacientes, DIRAYA DAH de una UTE e implantado por Fujitsu. • Aplicación corporativa de Gestión Farmacológica ATHOS de APD. • Aplicación corporativa Integral de Gestión Logística SIGLO de HP. En nuestro caso vamos a centrar el estudio en la implantación en el Hospital Universitario Regional de Málaga (anteriormente conocido como Complejo Hospitalario Carlos Haya) y más concretamente en la Aplicación corporativa de Gestión Farmacológica ATHOS y sus integraciones con las demás aplicaciones descritas y los sistemas electrónicos de gestión logística. Palabras clave. Implantación, política de centralización, logística, fungibles, farmacia, fármacos, Kanban, Kardex, armarios electrónicos, unidosis, historia única electrónica, HIS. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 6 Abstract Making use of new technologies, the Central Services of SAS want to optimize the logistics of each and every one of its health centers, all within a policy of centralization, which allows them access to logistical and economic information for each center of Andalucía, in real time. At the same time we want to modernize the processes involved in the current logistics circuits for which are integrated: • In hospital wards storage systems Kanban: double compartment drawers labeled with barcodes and supply management through PDAs or small electronic tablets. • In stores Pharmacies large hospitals, to manage the unidosis, we want to implement the use of electronic cabinets Kardex, to help prepare single dose carts. • For units with critically patients (ICU, ER, Oncology, with common psychotropic substance use), electronic cabinets, with user registration systems that removes drugs. • Corporate Management Application patient 's unique history . • Drug Enforcement Corporate Management ATHOS from APD. • Integral Logistics Management Corporate Application SIGLO from HP. In our case we will focus the study on the implementation in the Regional University Hospital in Málaga (formerly known as Hospital Carlos Haya ) and more specifically in corporate ATHOS Drug Application Management and its integration with other applications described and electronic logistics management systems. Keywords. Implementation, political centralization, logistics, consumables, pharmacy, drugs, Kanban, Kardex, electronic cabinets, single dose, unique history electronics, HIS Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 7 Contenido 1. Introducción. .............................................................................................................................. 9 1.1. Objetivo de la implantación del Sist. Logístico Informatizado. ...................................... 9 1.2. Análisis previo de situación. ............................................................................................ 9 2. Métodos y fases de trabajo. ................................................................................................... 12 2.1. Análisis y los grupos de trabajo de expertos. .............................................................. 13 2.1.1. Creación del grupo de trabajo. ................................................................................... 13 2.1.2. Análisis de situación actual y trabajo de grupo. ........................................................ 13 2.1.3. Diseño del Procedimiento General. ............................................................................ 14 2.2. Diseño y desarrollo o pliegos de concurso. ................................................................. 22 2.3. Integraciones. ................................................................................................................. 24 2.3.1. Integración entre las aplicaciones de Farmacia y Logística: ATHOS-SIGLO. ........ 24 2.3.2. Armario Kardex y su integración con la aplicación SIGLO....................................... 30 2.3.3. Armario Kardex y su integración con ambas aplicaciones Farmacéuticas. ............. 41 2.3.4. Armario PYXIS y su integración con la aplicación Farmacéutica. ............................ 43 2.3.5. Armario Omnicell y su integración con la aplicación Farmacéutica. ........................ 46 2.3.6. Sistema de reposición por Código de Barras, en los Almacenes de las Planta. ..... 49 2.3.7. Sistema de Mensajería para la integración, el servicio S127. .................................. 52 2.4. Preimplantación e Implantación. .................................................................................... 71 2.4.1. Preimplantación SIGLO. .............................................................................................. 71 2.4.2. Implantación SIGLO. .................................................................................................... 74 2.4.3. Preimplantación ATHOS. ............................................................................................ 77 2.4.4. Implantación ATHOS. .................................................................................................. 81 Conclusiones. ................................................................................................................................. 83 Referencias bibliográficas. ............................................................................................................ 84 Aportes tecnológicos. .................................................................................................................... 85 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 8 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 9 1. Introducción. 1.1. Objetivo de la implantación del Sist. Logístico Informatizado. El objetivo principal es optimizar, haciendo uso de las nuevas tecnologías, la logística de un complejo hospitalario, todo ello dentro de la política de centralización de software del SAS. Con dicha política se puede tener acceso a la información logístico-económica de cada centro de Andalucía, en tiempo real. 1.2. Análisis previo de situación. Buena parte del software actual del complejo hospitalario solo responde a las necesidades del mismo y no a la política del SAS descrita, por lo tanto hemos de analizar: • Las necesidades actuales del complejo hospitalario. • La política del SAS. • Las herramientas actuales, en uso para determinar si se pueden adaptar o hemos de plantear un cambio de parte o de todos ellos y hablamos de: o Software de gestión logística, o Software de gestión farmacológica, o Software de gestión de pacientes HIS. Hemos mencionado el uso de nuevas tecnologías y no solo nos referimos al uso de software, se pretende integrar sistemas que ayuden a agilizar y optimizar los circuitos logísticos. En este sentido en el complejo hospitalario a estudio se ha diferenciado siempre y de hecho existen dos departamentos diferentes para su gestión, los fungibles y los fármacos. En el caso de los fungibles, tanto en el almacén central como en los de las plantas de hospitalización, se pretende etiquetar las ubicaciones de los artículos con códigos de barras o similares, para poder gestionar sus existencias mediante PDAs o pequeñas tabletas electrónicas, que se sincronizarían con el sistema informático, para ayudar en su reposición y optimización de trazados de personal, para la generación de pedidos de las plantas o reposición a partir de las entregas de los proveedores. En el caso concreto de la plantas ya se usan y se quiere extender a todo el complejo, estanterías con cajones de doble compartimiento, con existencias para una semana por artículo, etiquetando los compartimentos con códigos de barra o un sistema similar y gestionándose su reposición como en el almacén central. Para lo descrito Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 16 1 El sistema presenta el formulario de alta o constitución de un nuevo depósito (ver campos en nota 1) 2 El usuario selecciona el ac ceso a la búsqueda del depósito del SAL, en la cual el sistema presenta los depósitos confirmados del OG. 3 El usuario selecciona uno de los depósitos del SAL y la opción volver [CUGD01.1] 4 El sistema inicializa los campos có digo y descripción del depósito de Siglo con el código y descripción del depósito seleccionado del SAL 5 El usuario mantiene el código y descripción heredados del depósito del SAL [CUGD01.2] 6 El usuario selecciona el acceso a la búsqueda de empresas para seleccionar el proveedor con el que se va a constituir el nuevo depósito, y marca la empresa deseada [CUGD01.3] 7 El usuario acepta los datos del formulario de alta o constitución del depósito [CUGD01.5] 8 El sistema comprueba que se ha indicado todos los datos obligatorios del formulario de alta (depósito del SAL, código, descripción, y proveedor) , y que no existe ya otro depósito con el mismo código o con la misma descripción para el mismo proveedor [CUGD01.E.1][CUGD01.E.2] 9 El sistema guarda el nuevo depósito, en estado “Pendiente de generar pedido inicial” y muestra la relación de los expedientes de contratación (número de expediente, CCA y objeto) en los cuales el proveedor del depósito tiene adjudicados productos sobre artículos con TGL = Depósito asistencial que pertenezcan a la zona indicada en el depósito del SAL para el OG. 10 El usuario selecciona el ex pediente a partir del cual deben generarse las líneas del depósito [CUGD01.4] 11 El sistema inserta una línea al depósito por cada producto adjudicado al proveedor en el expediente seleccionado, dejando la cantidad acordada a cero (para que el usuario la indique a posteriori, en el paso siguiente) 12 El usuario edita cada una de estas líneas insertadas al depósito, indicando la cantidad acordada para cada producto 13 El usuario selecciona la opción “Generar pedido interno” en la cabecera del depósito [CUGD01.6] 15 El sistema genera un pedido externo al proveedor, por las cantidades acordadas para cada uno de los productos del depósito. Este pedido lleva la marca de pedido de depósito (227) y condiciones de entrega (83E => Reponer y no facturar). El pedido queda pendiente de validar por el validador de compras, del mismo modo que cualquier otro pedido externo generado por el sistema. 16 El sistema cambia el estado del depósito a “Activo” 17 Termin a el caso de uso. Secuencia alternativa Paso Acción CUGD01.1 El usuario cancela la selección del depósito del SAL ( paso 3 ) 1 Termina el caso de uso CUGD01.2 Se quiere especificar un código o descripción distinta ( paso 5 ) 1 El usuario edita el código o la descripción 2 El sistema vuelve al punto 6 . CUGD01.3 El usuario cancela la selección del proveedor ( paso 6 ) 1 Termina el caso de uso CU GD01.4 El usuario cancela la selección del expediente ( paso 10 ) . Podrá volver a esta opción de selección del expediente en cualquier momento, mediante el caso de uso SIGLO_RF_CUGD04 Modificar depósito. 1 Termina el caso de uso CUGD01.5 El usuario cancela el alta o constitución del depósito ( paso 7 ) 1 Termina el caso de uso Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 17 CUGD01.6 El usuario deja la generación del pedido interno para otro momento ( paso 13 ) 1 Termina el caso de uso Excepciones Paso Acción CUGD01.0.E.1 Se ha dejado sin cumplimentar algún campo obligatorio ( paso 8 ) 1 El sistema muestra un mensaje indicando el campo o campos obligatorios que se han dejado sin cumplimentar 2 El sistema vuelve al punto 1 CUGD01.0.E.2 Ya existe otro depósito con el mismo código - descripción - proveedor ( paso 8 ) 1 El sistema muestra un mensaje indicando que no se puede crear el depósito porque ya existe otro con los mismos campos indicados 2 El sistema vuelve al punto 1 Inclusiones Prioridad Alta(5) Frecuencia de uso Reglas de negocio Requisitos Especiales Suposiciones Un depósito según se define en el SAL indica que el OG tiene la necesidad de tener un depósito del tipo de material indicado por la clasificación, bajo la responsabilidad de la unidad que se haya indicado, y para el consumo de los centros de consumo establecidos, pero no establece con qué empresa ha de ser ese depósito, ni los productos concretos y sus cantidades. En Siglo-logística es donde se definirán concretamente los depósitos constituidos con las empresas proveedoras, con todos sus detalles para poder gestionar sus consumos y reposiciones. Por lo tanto, un depósito de Siglo-logística se asociará a un depósito “general” que se haya definido y confirmado previamente en el SAL. Comentarios Nota 1) Campos del formulario de alta o constitución de un nuevo depósito:  Depósito SAL  Código  Descripción  Proveedor Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 18 SIGLO_RF_CUGD05 - Registrar salidas de depósito Versión* 2.0 03/02/2009 Autores Nombre autor: Grupo funcional de HP Organización: HP Fuentes Nombre autor: Grupo funcional de SIGLO Organización: Servicio Andaluz de Salud. Área Económica. Objetivos asociados OBJ - 1 Controlar la salida “física” del material del depósito. Descripción En este caso de uso se describen los pasos para dar una salida de material del depósito. Se contemplan dos posibles configuraciones: con reserva o sin reserva. • Si un centro configura SIGLO para permitir reserva, el modelo de funcionamiento del sistema sería el siguiente: siempre que el centro saque material del depósito lo registrara como salida indicando si es una reserva o una salida definitiva (ésta última desencadena un pedido y una posible reposición). Además, si se registra una salida para reserva posteriormente el usuario deberá registrar la correspondiente entrada del material que finalmente no ha sido utilizado. • Si un centro configura SIGLO para registrar sólo las salidas del depósito cuando éstas son efectivas, el centro registrará la salida del material en el sistema una vez que éste ha sido utilizado y este registro siempre generará el correspondiente pedido y, opcionalmente, una reposición. También se contemplan dos posibles configuraciones respecto a la validación de la salida. Los centros podrán configurar el sistema para que la salida se valide antes de enviarla al proveedor o no: • Si el centro requiere validación de la salida, en el momento en que se registre se quedará “pendiente de validar” y hasta que no se acepte no se desencadenarán en el sistema las operaciones asociadas a la salida (imputación de gasto, envío de pedido de reposición, envío de contraalbarán para facturación) • Si el centro no requiere validación de la salida, todas las operaciones relacionadas con la salida se desencadenarán en el momento en que se registre la misma. El funcionamiento del registro de salida será el siguiente: El usuario entra en la pantalla de salidas de depósitos. Si accede a este módulo de manera parametrizada con un depósito en concreto podrá indicar directamente los productos a dar salida leyendo el código EAN simbolizado en barras que estén impresos en ellos. También podrá seleccionar de manera manual el producto a dar salida seleccionándolo de entre los disponibles en el depósito. Para los usuarios que entren en este caso de uso directamente sin un depósito definido deberán seleccionar previamente el depósito mediante una consulta de entre lo depósitos que tengan acceso. Finalmente deberán asignar los datos requeridos para cada salida y quedará registrada la misma, confirmando la entrada de material que se dio en su día para disparar los consumos. Se comunicará al proveedor la facturación del material utilizado y en su caso la reposición del mismo mediante el pedido. SIGLO se comunicará con el Registro de Implantes Quirúrgicos para comunicarle la información cuando el material de depósito sea un implante. Precondiciones 1. El usuario debe estar auten tificado en el sistema 2. El usuario debe tener permiso para registrar salidas de material de depósitos. 3. Debe existir en el sistema un albarán asociado al producto cuya salida se va a registrar. 4. El sistema debe tener parametrizado si permite reserva o no 5. El sistema debe tener parametrizado si requiere validación de la salida o no Postcondiciones 1. El sistema debe registrar el acceso del usuario al módulo de Registro de Salidas de Depósitos. 2. El sistema actualizará el Registro de Depósitos con las modificaciones realizadas. 3. El sistema confirmará la entrada de material que en su día se hizo en la reposición del depósito. 4. El sistema registrará las salidas de material correspondientes y confirmará posteriormente las que sean necesarias en el mismo paso o en un paso posterior independiente. 5. Se generarán los pedidos de reposición según parametrización correspondientes del material utilizado. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 19 Actores Actor caso de uso Actor del sistema Actor 1 AC - 14: Gestor de depósito interno Secuencia normal Paso Acción 1 El sist ema detecta que hay un depósito seleccionado y presenta el campo “Depósito” relleno con la descripción del depósito seleccionado. (1.1) 2 El sistema presenta dos opciones: lectura de EAN de producto (por defecto) o selección manual del producto de entre los disponibles 3 El usuario lee el código EAN del producto ( E1 ) ( 3.1 ) ( 3.2 ) 4 El sistema comprueba que el producto leído pertenece al dep ósito actual y está entre las existencias. (E2) (E3) 5 El sistema muestra los datos del producto seleccionado. ( Ver Nota 1 ) 6 El sistema comprueba si el órgano gestor tiene configurado el modelo de trabajo con reserva o sin reserva. 7 El modelo de trabajo del órgano gestor es con reserva ( 7.1 ) 8 El sistema comprueba que hay una reserva previa del producto (se trata de la operación de salida) (8.1) 9 El usuario selecciona el centros de consumo al que se le puede imputar el gasto (Ver Nota 2) 10 El sistema comprueba que el artículo asociado al producto no tiene la marca de “Registro de Implantes Quirúrgicos” (10.1) 11 El sistema comprueba que el órgano gestor no tiene activada la validación de la salida (11.1) 12 El sistema guarda la información de la salida en estado “Valid ada” 13 El sistema confirma la entrada que se realizó de este material cuando se le dio entrada en el depósito (Ver CUGP17 Recepcionar material de pedido.doc), se realizan las salidas correspondientes, se decrementa en una unidad el número de existencias reservadas y se decrementa en una unidad el campo de existencias registradas 14 El usuario no desea indicar más salidas ( 14.1 ) 15 Termina el caso de uso Secuencia alternativa Paso Acción 1.1 El sistema detecta que no hay un depósito seleccionado . 1 El sistema detecta que no hay un depósito seleccionado y presenta el campo “Depósito” vacío y la opción de buscar un depósito. 2 El usuario pulsa en la opción de buscar un depósito 3 El sistema invoca al caso de uso “ S IGLO_RF_CUGD02 - Consultar depósito ” 4 El sistema muestra en el campo “Depósito” la descripción del depósito seleccionado por el usuario. 5 Volver al punto 2 . 3.1 El usuario elige seleccionar manualmente el producto 1 E l sistema le muestra todos los productos de los que hay existencias en el depósito. 2 El usuario selecciona un producto. ( E4 ) 3 El sistema le muestra las diferentes existencias de ese producto, distinguiendo por fecha de caducidad, número de lote y número de serie. 4 El usuario selecciona una de las existencias, que debe corresponder con la unidad física que se va a sacar del depósito. (E5) Volver al punto 5 . 3.2 El usu ario desea cancelar el registro de la entrada 1 Volver al punto 15 . 7.1 El modelo de trabajo del órgano gestor es sin reserva Volver al punto 9. 8.1 El sistema comprueba que no hay reserva previ a del producto (se trata de la operación de reserva) 1 El sistema incrementa en una unidad el número de existencias reservadas controlando que el número de existencias reservadas no puede ser mayor que el número de existencias registradas. (E6) Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 20 2 El sistema guarda un log con los siguientes datos: la identificación de la existencia que se ha reservado, el usuario que hace la reserva, la fecha y la hora en que se hace la reserva. 3 Volver al punto 13 . 10.1 El sistema comprueba que el artículo asociado al producto tiene la marca de “Registro de Implantes Quirúrgicos” 1 El sistema solicita al usuario los datos necesarios para rellenar la ficha en el Registro de Implantes Quirúrgicos (Ver Nota 3) 2 El usuario completa todos los datos necesarios 3 El sistema invoca al servicio del Registro de Implantes Quirúrgicos 4 El servicio de Registro de Implantes Quirúrgicos notifica que todo ha sido correcto (10.1.4.1) 5 Volver al punto 11 . 11.1 El sistema comprueba que el órgano gestor tiene activada la validación de la salida 1 El sistema guarda la información de la salida en estado “pendiente de validar” 2 Se decrementa en una unidad el número de existencias reservadas y se decrementa en una unidad el campo de existencias registradas. 3 El sistema notifica al validador de salidas que hay una salida del depósito “pendiente de validar” 4 Volver al punto 14 . 14.1 El usuario desea indicar más salidas Volver al punto 3 . 10.1.4.1 El servicio de Registro de Implantes Quirúrgicos notifica que hay un error 1 El error se debe a una equivocación del usuario al insertar un dato (10.1.4.1.1.2) 2 Se corrige el dato erróneo 3 Volver al punto 10.1.3 10.1.4.1.1.2 El error se debe a que no es válida la información enviada al sistema 1 Se queda esa salida “Pendiente de registrar en el Registro de Implantes Quirúrgicos” 2 Volver al punto 10.1.3 . Excepciones Paso Acción E1 No se puede leer el código EAN del producto 1 El sistema indica que el código EAN no es legible 2 Volver al punto 3 . E2 El código EAN leído no se corresponde con ningún producto de los asociados al depósito seleccionado. 1 El sistema indica que el código leído no se corresponde con ningún producto de los asociados al depósito seleccionado. 2 Volver al punto 3 . E3 El código EAN leído no se corresponde con ninguna de las existencias asociadas al depósito seleccionado. 1 El sistema indica que el código leído no se corresponde c on ninguna de las existencias asociadas al depósito seleccionado. 2 Volver al punto 3 . E4 No aparece el producto al que se quiere dar salida. Volver al punto 3.1 E5 No aparece la existencia a la que se quiere dar salida. Volver al punto 3.1 E6 El número de existencias reservadas es mayor que el número de existencias registradas. 1 El sistema muestra un aviso al usuario indicándole que no se puede realizar la reserva solicitada. 2 Volver al punto 14 . E7 El servicio de Registro de Implantes Quirúrgicos notifica que hay un error. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 21 1 El error se debe a una equivocación del usuario al insertar un datos 2 Se corrige 3 Volver al punto 10.1.3 Reglas de negocio Frecuencia de uso Media Usuarios concurrentes* Uno Tiempo de respuesta* Inmediato Comentarios* Nota 1. Los campos de los productos que se muestran son: - CIP - Referencia fabricante - Denominación comercial - Cantidad acordada - Existencias - Cantidad pendiente Nota 2. • Si el depósito se creó en SAL con un único centro de consumo asociado, el sistema automáticamente mostrará ese centro de consumo. • Si el depósito se creó en SAL con varios centros de consumo asociados, el sistema mostrará todos esos centros de consumo y el usuario deberá seleccionar uno de esos. Nota 3. Los datos necesarios para el Registro de Implantes Quirúrgicos son: a) Datos del Paciente: * Tipo de identificación: Tarjeta Sanitaria, DNI, Pasaporte, NUHSA * Identificación * Número de historia clínica * Fecha de nacimiento * Sexo: Mujer, Hombre b) Datos del Centro: * Órgano gestor (Por defecto, no editable) * Fecha de implante (Por defecto, la actual, editable) * Servicio: A seleccionar, entre los existentes * Cirujano implantador: Nombre y apellidos * CNP del cirujano implantador ¿Obtener de Gerhonte? c) Datos del producto implantado: * Empresa suministradora: (Por defecto, el proveedor del depósito) * Empresa fabricante: * Denominación comercial: (Por defecto, la del producto seleccionado) * Referencia del producto: (Por defecto, la del producto seleccionado) * Fecha de caducidad: (Por defecto, la del producto seleccionado si la tiene) * Número de Lote/Número de Serie: (Por defecto, la del producto seleccionado si la tiene) * Localización del implante Nota 4. Reposición de un depósito. El proceso de reposición de un depósito se activará de manera automática cada vez que se registre una salida del mismo. Implica que se genere un pedido del material consumido. Cada vez que se registre una salida de un depósito el sistema comprobará si el campo “reponer” de la linea de la cual se ha consumido una unidad está activa; si es que sí, significa que en el pedido que se genere hay que indicar en el campo condFacturacion= “reponer y facturar”. Si es que no, el pedido que se genere debe llevar en dicho campo el valor “facturar y no reponer”. Se indicará en el detalle de estos pedidos los CIPs o referencias, nº serie y lote de los artículos que se han consumido, junto con el nº de documento que se obtuvo para cada línea al registrar la salida. Para componer el pedido el sistema utiliza las tarifas activas actuales pertenecientes a las ofertas definidas para cada línea en la constitución del depósito. Tener en cuenta que se puede configurar en SIGLO que si el expediente se ha agotado o finalizado, el sistema automáticamente pida por la tarifa de compra menor. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 22 2.2. Diseño y desarrollo o pliegos de concurso. Una vez determinadas las necesidades se requiere designar una Comisión de Expertos, asesorados y también compuesto por personal TIC, que validen las especificaciones definidas en la fase anterior a licitar y definan los criterios de adjudicación y posteriormente valoren dichos criterios, todo ello de acuerdo con la Ley de Contratos del Sector Público (LCSP). La LCSP utiliza la expresión “oferta económicamente más ventajosa” para remitirse a los criterios que el órgano de contratación ha de tener en cuenta para valorar las ofertas de los licitadores en los diferentes procedimientos. Ya se utilice un único criterio (el precio) o ya se considere una multiplicidad de ellos la ley mantiene su preferencia de los criterios automáticamente cuantificables es decir mediante fórmulas en los pliegos. Si en el expediente se contemplan criterios cuya cuantificación dependa de un juicio de valor, la valoración de los mismos corresponderá bien a un comité formado por expertos bien a un organismo técnico especializado, que es nuestro caso, pues obviamente no sólo nos vamos a basar en el precio de una solución informática, si no que a partir del trabajo de la fase anterior y el documento generado, el pliego al que hace referencia la LCSP, recogerá las especificaciones que debe cubrir la solución a la que se le adjudique el contrato, en un porcentaje determinado por el comité de expertos o el organismo técnico especializado designado para llevar a buen término, la adjudicación del contrato. En el caso que nos ocupa se acuerda lo siguiente, como parte del pliego del contrato para la solución de gestión farmacéutica corporativa: • Definir las necesidades de los fármacos en el centro, concretando los principios activos, sus características y presentaciones específicas. • Establecer los stocks de seguridad y los puntos de pedidos de los medicamentos, a través del análisis y control de los factores clínicos y dinámicos del almacén general de medicamento del centro y, en su caso, de los almacenes de consumo. • Detectar los problemas que se produzcan, tales como roturas de stock, inmovilizaciones y cualquier otro motivo que obligue a efectuar un pedido excepcional y, valorando las necesidades y evaluando la urgencia o excepcionalidad del caso, determinando el proveedor y las condiciones. • Definir cantidades requeridas, fechas de recepción de los suministros, condiciones de entrega, condiciones de caducidad y cualquier otra consideración técnica al respecto. • Establecer las dependencias, depósitos o botiquines del servicio de farmacia en que deba realizarse el suministro. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 23 • Certificar la situación del medicamento en el registro farmacéutico nacional, que justificará la disponibilidad y el procedimiento a adoptar para la contratación. • Emitir las certificaciones que se requieran a fin de acreditar la calificación de “no sustituible” otorgada a un medicamento, conforme a lo dispuesto en la instrucción segunda (del pliego de donde está tomado el texto). • Participar en la Comisión Multidisciplinar de URM de ámbito provincial a que hace referencia la cláusula quinta (del pliego de donde está tomado el texto), en lo relativo a la contratación administrativa de medicamentos. • Participar, a través de la Comisión Multidisciplinar de URM de ámbito provincial, en la selección, en el caso de suministro menor, de los proveedores, presentaciones y otras condiciones de los medicamentos a adquirir. • Realizar de forma directa todas las validaciones necesarias en el circuito de pedidos, administrando y gestionando los procedimientos necesarios para generar las propuestas de pedidos a través del Sistema Integral de Gestión Logística SIGLO –Todavía no está operativo y no hay fecha-, teniendo acceso en todo momento, cada Servicio de Farmacia Hospitalaria de la provincia, a la información completa del estado del pedidos generado. • Efectuar la entrada y confirmación de recepción de los suministros de medicamentos, a través del Sistema Integral de Gestión Logística (SIGLO) – Todavía no está operativo y no hay fecha-. • Asumir y garantizar el correcto almacenamiento de medicamentos (conservación, caducidades, alertas y cualquier otra consideración técnica) y su trazabilidad, en base a la codificación y simbolización mediante EAN-13 establecida como requisito por el Servicio Andaluz de Salud. Todo esto con la intención de permitir optimizar la gestión de: • La dosis unitaria a pacientes, • Gestión logística interna (entre el almacén central y el de los distintos servicios) y externa (entre las centrales de compras y los proveedores), • Gestión contable y de facturación, • Datawarehouse que ayude a optimizar las decisiones de la organización. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 24 2.3. Integraciones. 2.3.1. Integración entre las aplicaciones de Farmacia y Logística: ATHOSSIGLO. La aplicación informática corporativa de Farmacia Hospitalaria será el sistema de información que registre de forma individualizada el consumo de medicamentos, proporcionando los datos que permitan dar soporte a las UGC de farmacia para desarrollar la estrategia de uso adecuado de medicamentos del SAS. Dicha aplicación deberá estar integrada con los sistemas de información corporativos, comenzando consigo para completar el circuito necesario para la gestión logística. • En base a la mencionada integración, la aplicación informática corporativa de gestión de Farmacia Hospitalaria se encargará de los siguientes procesos: 1. Mantenimiento de los datos específicos del fichero maestro de medicamentos, para su correcto uso en las diferentes aplicaciones necesarias para la prescripción individualizada, el seguimiento farmacoterapéutico y las demás actividades dirigidas a evaluar el uso adecuado de los medicamentos. 2. Gestión de los botiquines, depósitos y almacenes de consumo de medicamentos, incluyendo: o Registro de las existencias de artículos. o Definición de stocks por cada artículo. o Solicitudes de reposición de los artículos en base a sus puntos de pedido. 3. Gestión de la dispensación y devoluciones a todos los pacientes del hospital, tanto internos, como externos, así como a unidades, botiquines de planta y cualquier depósito de medicamentos dependiente del centro. 4. La aplicación corporativa de Farmacia soportará la gestión de consumos, hasta el máximo nivel de desagregación (Centros de consumo, GFH, prescriptor, indicación o patología e incluso paciente) en base a lo cual se realizará el seguimiento de los acuerdos de consumo establecidos. La aplicación corporativa de Farmacia proporcionará a SIGLO la información de consumos de medicamentos, de forma global, agrupada por el total del Centro. El director la UGC de Farmacia podrá acordar con la Dirección Gerencia del centro otros niveles de desagregación diferentes en esta información. 5. Gestión de la elaboración de fórmulas magistrales, nutriciones, mezclas y productos reenvasados. 6. Trazabilidad y gestión de caducidades de medicamentos dispensados. 7. Intercambio de existencias entre botiquines, depósitos y almacenes del servicio de Farmacia Hospitalaria. • La aplicación SIGLO, por su parte, se encargará de los siguientes procesos, integrada con la aplicación corporativa de Farmacia: 1. Mantenimiento y actualización centralizada del catálogo de medicamentos y Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 25 productos farmacéuticos incluidos Catálogo de Bienes y Servicios del Servicio Andaluz de SAS. 2. Mantenimiento de los productos farmacéuticos del Banco de Bienes y Servicios del Servicio Andaluz de SAS. 3. Gestión completa de expedientes de contratación administrativa. 4. Tramitación de pedidos y devoluciones a proveedor. 5. Gestión del stock del almacén central del servicio de farmacia: o Registro de entrada de medicamentos y productos farmacéuticos. o Confirmación de recepción. o Gestión de stock máximos, críticos y puntos de pedido. o Trazabilidad (lotes). o Gestión de caducidades. o Prestamos de medicamentos entre centros. 6. Facturación y contabilidad. • Carga Inicial De Datos. o Almacenes Los códigos de los Almacenes deben ser comunes en SIGLO y ATHOS. Generalmente hay un único almacén por centro hospitalario, pero en el caso del HRUM, como ya hemos comentado y tenemos uno por centro. En ATHOS el campo Almacén es un VARCHAR2(3). o Centros de Coste. En ATHOS cada GFH tiene asociado un código SAL que identifica el código usado en SIGLO como centro de coste. Un GFH solo puede tener asociado un código SAL (Centro de Coste SIGLO). Un código SAL (Centro de Coste SIGLO) puede pertenecer a varias GFH de ATHOS. En ATHOS: El código GFH es un campo VARCHAR2(5) El código SAL es un campo VARCHAR2(100) Se ha implementado un servicio de recepción de actualización de Tablas Maestras, para la actualización de la tabla de IS_CENTROS_CONSUMO Las equivalencias entre GFH y Centros de Costes SIGLO, el usuario puede mantenerlas accediendo a ATHOS-Admin. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 32 cantidad servida real. • S123: Este servicio confirmará a SIGLO las regularizaciones producidas durante el día (indicando la cantidad relativa regularizada), y de forma programada, notificará los stocks absolutos del armario. • S122: Este servicio informará a SIGLO de los pedidos no tramitados en Kardex, por algún contenido funcionalmente erróneo. En el análisis inicial, se identifica como pedido erróneo aquel que contenga algún producto externo al armario. • S068: Este servicio informará a Kardex de las confirmaciones y/o inventarios/regularizaciones que no se han podido procesar en SIGLO. • Otras Consideraciones: o Renovación de Ticket en Maco El Sistema Kardex renovará su ticket de forma programada, o bien, cuando se detecte un envío con ticket caducado en el servicio de renovación que aporte MACO. o Gestión de Lote y Caducidad El armario almacenará tanto material fungible como medicación. Para el caso de medicación, SIGLO obliga al control de Lote y Caducidad. Dado que el producto no está etiquetado, se propone que el armario dedique un cajetín para cada producto/lote/caducidad. Esto supone una merma de espacio disponible en el armario, pero por otro lado, no requiere que el usuario compruebe el lote dispensado. En el caso de que SIGLO solicite un lote/caducidad que no está disponible (o se ha agotado), el sistema puede confirmar la dispensación con dos líneas. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 33 • Análisis de Circuitos: A continuación vamos a proceder a detallar el análisis que desarrollaron las partes implicadas den los distintos circuitos que conforman la gestión logística, integrada con un Carrusel (Kardex): o Reposiciones de Proveedor: Partiendo de este entorno, lo primero a tener en cuenta sería la reposición de material por los proveedores en el Carrusel. Puesto que la gestión de pedidos al proveedor se gestiona en SIGLO, debería ser desde este extremo desde el que se debería llevar a cabo la reposición de material, para luego notificar al Carrusel las existencias que han llegado y así poder incrementar sus existencias. En la primera fase de la integración, este circuito no estaba contemplado, teniendo el usuario que actualizar las existencias en ambas aplicaciones. A continuación se muestra una gráfica con el circuito completo, para luego desarrollarla. Para este circuito partimos de la recepción de material en el centro, es decir, ya se ha hecho una solicitud de reposición al proveedor, con el consiguiente pedido y acaba de llegar al almacén dicho material. En este punto SIGLO genera una orden de trabajo, en este caso de reposición, a partir del albarán recibido y queda a la espera de que el material sea colocado en el almacén. La confirmación de la orden de trabajo conlleva el incremento de existencias en SIGLO, si la ubicación donde dicho material se va a colocar es de tipo Carrusel, provocará el envío de un mensaje de incremento de existencias, en este caso al carrusel. En Carrusel, al recibir dicho mensaje, realizará las validaciones que se estimen necesarias, si las pasa, realizará el consiguiente incremento de existencias. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 34 En caso contrario, enviará una notificación de error, indicando el motivo por el cual no ha podido realizar la operación. En SIGLO, tras recibirse dicha notificación, se tendrá que revisar donde está el problema y solucionarse. Una vez que esté solucionado, se realizará un nuevo envío, repitiéndose este circuito tantas veces como sea necesario, hasta que la operación se pueda dar por finalizada en el Carrusel. [Seidor] La operativa es correcta, entendemos que SIGLO envía la entrada al Carrusel, una vez realizada la recepción y sólo de aquello que según SIGLO debe de ubicarse en el carrusel. Sólo faltaría añadir la confirmación de la entrada, desde el Carrusel a Siglo, una vez se ha realizado, ya que de lo contrario, el ERP cuenta que en Carrusel hay un stock que probablemente no se ha ubicado y podría dar lugar a que enviara pedidos de salida para los que el carrusel no tiene el stock ubicado, con lo que no los podría servir. Mientras se prepara, la orden de entrada en SIGLO debería permanecer pendiente y sin poder ser modificada. [OTI] Este ciclo quedaría completo, si existiera la Notificación de error funcional por parte del carrusel, será cuando se modifique la orden, sin necesidad de ser bloqueada en SIGLO. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 35 o Preparación de Material Una vez tenemos las existencias alineadas, los almacenes de consumo a los que provee el Carrusel pasarán a solicitar los artículos que necesiten. Cuando se envían las peticiones de preparación de SIGLO al Carrusel, estas vienen a raíz de una solicitud de reposición del almacén de consumo al almacén donde se encuentra el Carrusel. En el almacén central, al preparar el pedido, y si los artículos a enviar pertenecen a ubicaciones del Carrusel, se enviará una petición de preparación al Carrusel, indicándose los artículos a preparar. Si el Carrusel no encuentra problemas en dicha petición, se procederá a preparar el material. Si por el contrario encuentra algún problema, detendrá el proceso y enviará una notificación de error a SIGLO. [OTI] Como se comentaba anteriormente con la Notificación de Error Funcional. En SIGLO se procederá a localizar y solucionar el problema, reenviando de nuevo la petición. Este proceso se realizará tantas veces como sea necesario para que el Carrusel pueda llevar a cabo la preparación. Actualmente la preparación de material se debe hacer en los dos entornos, creemos que se debería hacer en el Carrusel al ser el que va a preparar el material físicamente. Mientras se prepara, la orden de trabajo en SIGLO permanecerá pendiente y sin poder ser modificada. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 36 La salida de material del Carrusel provocará el envío de un mensaje de Confirmación de Preparación a SIGLO. Si dicha confirmación se procesa correctamente, provocará la confirmación de la orden de trabajo y el posterior decremento de existencias. La orden de trabajo quedará pendiente de enviar, y el resto del circuito se realizará en SIGLO, con esto queremos decir, el envío de material al almacén de consumo y su posterior recepción. Si por el contrario encuentra algún problema, dejará la orden de trabajo pendiente y enviará una notificación de error para que el Carrusel solucione el problema y lo vuelva a reenviar. [OTI] Este ciclo está planteado de manera bloqueante, con lo cual se plantea que mientras desde el carrusel no se notifique un error funcional al origen, la petición de preparación siga su ciclo normal de funcionamiento, sin necesidad de generar un mensaje de confirmación de proceso correcto. Sino que solo se notificaría al origen, en el caso que no se haya podido procesar, con la notificación del error funcional. [Seidor] Se entiende que SIGLO envía peticiones a ULISES sólo si tiene stock disponible en la ubicación del carrusel. Se ha de tener en consideración que ULISES puede enviar a SIGLO la confirmación de la preparación de una salida sin que todo el material esté confirmado en su totalidad. Es decir, la salida solicita 5 unidades pero sólo se sirven 3 unidades, independientemente del motivo. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 37 o Regularización de existencias Puesto que la regularización también modifica las existencias, se hace indispensable la integración de este circuito. Para este circuito, se entiende que podríamos partir desde ambos extremos. Actualmente, y para otras integraciones, se está partiendo desde SIGLO, pero también tendría lógica hacerlo desde Carrusel. En un principio vamos a establecer el circuito partiendo desde SIGLO y desde Carrusel, quedando a la espera de que se establezca la mejor forma de proceder en este circuito. Cuando se realiza una regularización en SIGLO, si se hace sobre material contenido en una ubicación del Carrusel, provocará el envío de un mensaje de regularización al Carrusel. A partir de este mensaje, el Carrusel intentará actualizar sus existencias con las indicadas en dicho mensaje. Si no encuentra ningún problema, lo hará y el circuito se dará por finalizado. Si por el contrario encuentra algún problema, enviará una notificación de error, y quedará a la espera de un nuevo mensaje para realizar la operación. Una vez recibida la notificación de error en SIGLO, se procederá a solucionar el problema indicado y a reenviar el movimiento de regularización. En este circuito surgen varias dudas, sobre todo referentes a la forma en la que se clasifica el material. En SIGLO, para un mismo GC, el material está clasificado por lote, serie y fecha de caducidad, y habría que ver cómo se hace en el Carrusel. Dependiendo del modo, la operativa se vería bastante afectada. [Seidor] Como ya hemos comentado anteriormente, no entendemos que se pueda modificar el stock desde un sistema que no sea el que realmente trabaja con el stock físico. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 38 Si se añade stock, ¿en qué ubicación se añade? Lo correcto sería enviar una entrada de material al Carrusel, para que éste la ubique donde estime oportuno y envíe la confirmación al ERP una vez entrada. Si se resta stock, la situación sería exactamente la misma. Entendemos que lo más correcto sería enviar una salida de material a carrusel, de un tipo especial, si se quiere diferenciar, pero que quede a la espera de la confirmación desde el carrusel al ERP una vez realizado el movimiento físico. [OTI] Como hemos comentado anteriormente esta situación es bloqueante. Adjuntamos diagramas propuestos en documentación adjunta. Si por el contrario se decidiera que la regularización se hiciera desde Carrusel, habría que ver si se va a hacer para un artículo, o varios. [Seidor] La regularización generada desde el carrusel, ya sea por un inventario o por cualquier otro motivo, se enviaría al ERP. En la interfaz standard de Ulises enviamos cada x minutos, con x = 0 a 3, dependiendo de la instalación y se envían todos los ajustes pendientes de enviar al ERP hasta éste momento, con lo que se puede enviar 1 o varios, pero éste punto lo dejamos a decisión del ERP. [OTI] Según comentábamos si SIGLO es el que gestiona el STOCK, la regularización del mismo modo que las entradas de compras, se debería hacer desde SIGLO, y los consumos desde CARRUSEL. [HP] Está pendiente decidir en qué extremo se permiten las regularizaciones de material. Es cierto que SIGLO gestiona el Stock, pero el material está físicamente en Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 39 el carrusel por lo que es probable que lo lógico sea permitir la regularización sólo en el Carrusel y que éste la comunique a SIGLO. o Inventario de Existencias Hay ocasiones en las que se necesita actualizar la cantidad de existencias para que estén sincronizadas correctamente en ambos extremos. Para ello usaremos la funcionalidad de inventario. Como las existencias se encuentran físicamente en el carrusel planteamos que el inventario se haga en el carrusel y se comunique a SIGLO. De manera que en esa comunicación lo que se haga sea una actualización de existencias (sin indicar incremento ni decremento, sólo la cantidad final) [OTI] La información que se engloba dentro de cada consumo realizado en el carrusel. [Seidor] En éste caso, lo ideal sería generar un mensaje con la información totalizada por artículo, lote y fecha caducidad, independientemente de la ubicación o ubicaciones en la/s que esté el material. [HP] Sería necesario repasar los parámetros del mensaje de información de consumos, para confirmar que no se necesitan nuevos campos. o Gestión de ubicaciones En el mensaje de integración actual se está identificando únicamente la zona del almacén donde están las existencias a preparar (zona carrusel), de manera que la preparación de pedidos genera una orden de trabajo única para esta zona. Sin embargo no hay una alineación de ubicaciones entre el Carrusel y SIGLO. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 40 Planteamos la opción de que se alineen los datos de ubicaciones ya que las existencias en SIGLO están asociadas a ubicaciones concretas y sería necesario mantener un mapeo en esta información para poder realizar actualizaciones de existencias. [Seidor] Por nuestra parte, no vemos necesario que SIGLO conozca las ubicaciones donde ULISES guarda el stock, por todo lo que hemos indicado anteriormente. Si el motivo de informar a SIGLO de las ubicaciones donde ULISES tiene el stock, es para enviar regularizaciones de stock a ULISES, tampoco sería 100% fiable que pudiera enviarlas, ya que ULISES podría tener reservado el stock para algún pedido o bloqueada la ubicación por algún motivo determinado, o simplemente, que no esté configurado para entrar en la ubicación que le indicara SIGLO. De todas formas, en caso de que se desee, se debería modificar el envío de todos los movimientos en carrusel, para que SIGLO mantuviera una copia exacta del stock por ubicaciones. Sería el mismo mensaje descrito en el apartado anterior de Regularización de existencias, pero en él se incluirían todo tipo de regularizaciones, los movimientos de stock provocados desde Ulises y los movimientos de stock que correspondan a entradas o salidas enviados desde el ERP. [OTI] El stock en SIGLO debería tener asignado el almacén determinado (el que se vea conveniente) y una ubicación por carrusel que exista en el centro. De esta manera se podrán suscribir a esta mensajería tantos carruseles como se requiera en el centro y será el ESB el que podrá enrutar al carrusel implicado en los eventos de negocio. [HP] En la reunión mantenida el 22 de enero se decidió que se tendrá en SIGLO una ubicación para cada artículo asociado a una zona de carrusel y los artículos serán exclusivos del carrusel (comentado ya en el primer punto de este documento). Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 41 2.3.3. Armario Kardex y su integración con ambas aplicaciones Farmacéuticas. Partiendo de que X-FARMA y ATHOS tendrán un periodo de convivencia, en el circuito de unidosis hasta la transición final a ATHOS se plantean los siguientes circuitos para la migración: Situación Actual: Se implementó y se probó pero la copia de la URL-1 a la URL-2 se realizaba manualmente. La solución adoptada es utilizar el fichero que genera X-FARMA para registrar los consumos en ATHOS. Problemas: • Hay que resolver el problema de las URLs donde se genera el fichero. [HRUM] Lo van a tomar de la carpeta de Backup donde se ubica el archivo tras leerlo X-FARMA. • Cuando en X-FARMA se reenvían el fichero en ATHOS se vuelve a contabilizar, ATHOS no puede detectar las repeticiones ya que en los reenvíos X-FARMA cambia el nombre del fichero. • En el fichero que genera X-FARMA no viene el ID del paciente. Para generar el consumo en ATHOS-Prisma por paciente hay que buscar el ID del paciente a través de la CAMA, buscando el paciente que está ingresado en la cama. • Integración ¿por CN o por CODIHOSPI? [HRUM] Lo que menos problemas ocasionaría sería seguir con CN y eso es lo que se va a hacer. X-FARMA ATHOS-STOCK (Consumos) KARDEX Carros Url-1 Url-2 Copia manual Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 48 Funcionalidad. El contenido del fichero se carga en las tablas SC_PYXIS y SL_PYXIS que se corresponde con la siguiente pantalla. El usuario debera revisar y ejecutar el botón Traspaso para que se genere el consumo en firme y descuente del stock. El concumo se genera a la UH y GFH que tenga definido en el Maestro de Dispensadores. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 49 2.3.6. Sistema de reposición por Código de Barras, en los Almacenes de las Planta. A continuación vamos a analizar la metodología seguida en las implantaciones del sistema de reposición por estanterías modulares, etiquetadas con códigos de barra. ¿En qué consiste? El sistema, que actualmente está implantado en todas la plantas de encame del Centro hospitalario Materno-Infantil, y en 9 plantas de encame de H. General (Carlos Haya) está compuesto, básicamente por: - Un sistema modular de almacenamiento con cajones, situados a diferentes alturas. - Etiquetas con la denominación del contenido de los cajones y con códigos de barras. Dichos códigos de barra aportan información sobre el código identificativo de cada artículo y la unidad de consumo (planta de encame), en la que están ubicados los sistemas modulares de almacenamiento. - PDAs con lector de código de barras. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 50 - Módulo Software de Isoft (X-LOG), cuando se implanto el sistema y actualmente de HP (SIGLO) instalado en la PDA, capaz de gestionar las lecturas de Código de Barra, para transformarlas en los pedidos de cada Unidad de Consumo, mediante sincronización de la PDA con un PC, donde debe estar operativo el software de gestión logístico, que actualmente es SIGLO. - Software X-LOG de Isoft, cuando se implanto el sistema y actualmente SIGLO de HP, que a partir de la sincronización de la PDA con el PC, es capaz de generar pedidos de las distintas Unidades de Consumo. - Tabla en la B.D. de SIGLO, donde se encuentran las asociaciones entre las distintas Unidades de Consumo, los servicios donde están las estructuras modulares de almacenamiento temporal, las cantidades semanales que deben servírseles y el tipo de artículo que es, determinado por el subalmancén donde están clasificados (origen de un desarrollo específico para el HRUM). Los cajones se dividen en dos secciones horizontales, para establecer un sistema de doble compartimento y tantas divisiones verticales, como productos distintos, se ubiquen en cada cajón. Las etiquetas, que identifican la disposición de cada artículo, se colocan en unos portas que permiten una fácil extracción de las mismas, para poder colocarlas presentado la cara más apropiada, en cada momento. Las dos caras contienen la misma información, pero una de ellas tiene marcas de colores llamativos, que avisan de la carencia en los dos compartimentos del artículo al que está asociada la etiqueta y por lo tanto de la urgencia de su reposición. El personal, responsable de la reposición de la planta, puede determinar de este modo, con facilidad, que lecturas debe hacer, para que posteriormente se generen los pedidos correspondientes. Metodología a seguir, para implantar el sistema. La implantación de este sistema, requiere efectuar los pasos siguientes: 1. Generar un listado con los consumos anuales de la Unidad de Consumo, donde se implantará el sistema, indicándose la cantidad semanal ideal, para cada tipo de material (1 jornada). 2. Revisar listado de consumos con el/la supervisor/a de la Unidad de Consumo, para ajustar las cantidades propuestas a las que realmente necesitan. El cálculo del consumo nos ofrece una media anual, que no prevé picos en los que el consumo se dispara, (p.e. bronquitis en invierno) (1 jornada). Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 51 3. Revisar listado de consumos, con personal del almacén, para ajustar las cantidades a las presentaciones mínimas que se suelen servir (1 jornada). 4. Generar, imprimir, revisar, cortar y pegar etiquetas a partir del estudio de consumos, que nos habrá permitido determinar el número de referencias y por tanto el número de portas y soportes de etiquetas que deberemos pedir al proveedor de los módulos de almacenamiento (5 jornadas). 5. Medir almacén y estimar número de módulos necesarios (lo puede hacer el proveedor o personal del C. H. Carlos Haya) (1/2 jornada). 6. Petición de los módulos necesarios al proveedor y entrega de los mismos en el nuestro almacén central (6 semanas, 2 en el mejor de los casos). 7. Montaje de los cajones, acorde con los distintos tamaños de los artículos y las cantidades de los mismos que se han pactado, tras la revisión del listado de consumos (4 tardes). 8. Desmontar las estanterías del almacén de la Unidad de Consumo (1 tarde). 9. Montaje de los módulos del proveedor (en el caso de Palex, pueden montarlo ellos o personal del C. H. Carlos Haya) (1 jornada). 10. Colocación de los cajones y sus correspondientes portas en los módulos montados (1 tarde). En total, sin contar el plazo de entrega del proveedor, de los módulos y estimando cada tarde como una jornada, estaríamos hablando de un proceso que requiere de 15 jornadas y ½. El material de gran volumen (Pañales, p.ej.) no se tiene en cuenta para calcular el número de módulos de almacenamiento necesarios, para la Unidad de Consumo, donde se debe implantar el nuevo sistema de reposición. Ahora bien, se simula el sistema de doble compartimento, en estanterías normales, usando distintos niveles de las mismas, para simular cada uno de los compartimentos o bien, usando separadores, en una misma balda. Se requiere tener en cuenta la necesidad de vales de comida, así como de horas extraordinarias, para las labores que se han de desarrollar por las tardes, para evitar entorpecer las tareas habituales y necesarias de las mañanas, que no pueden pararse. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 52 La PDA y la integración de los pedidos internos en el sistema SIGLO. La PDA y el sistema informático, cuando entra y como se integra en todo lo expuesto: 1. Como hemos indicado ya, al agotarse el material de un compartimento, para que el personal que repone dicho material sepa que debe generar un pedido, el personal que dispone de dicho material en la planta debe retirar la etiqueta y colocarla en el rail de pedido correspondiente (uno por columna). 2. Cuando la PDA retorna al almacén central, en el/los PC/s de sincronización con SIGLO, se conectará por USB. También pueden sincronizarse por Bluetooth o incluso desde el mismo lugar donde se efectúa la lectura por Wifi, evitando la necesidad de que la PDA requiera un PC para su sincronización. 3. Al sincronizarse la PDA con SIGLO, se generan lo pedidos de reposición de las plantas, que son preparados por el personal del almacén central y llevados a las unidades de consumo para la correspondiente reposición. 4. En función de cómo se haya configurado el sistema y del momento en que se sincronice el pedido de reposición, la salida se generará en el almacén central al generar el pedido o en la planta al leerse la necesidad. 5. Cuando desde el almacén se efectúe la reposición del material en la unidad de consumo correspondiente, se colocara la etiqueta en el compartimento que estamos utilizando para la reposición y el material en el compartimento que se había quedado vacío. A todo lo anterior hemos de añadirle la aplicación de las PDAs o posiblemente ya hablemos de Tablets, en la gestión de la logística del almacén central, proyecto ya en funcionamiento en el Hospital Virgen del Rocio de Sevilla, por ejemplo y que aquí no tiene fecha de implantación, pero es un hito pendiente muy interesante y no descartado. 2.3.7. Sistema de Mensajería para la integración, el servicio S127. Para que los sistemas integrados se entiendan entre si, la Unidad de Interoperabilidad del SAS ha desarrollado el servicio S127. A continuación vamos a tratar de describir la necesidad funcional cubierta por el servicio, así como los detalles de mensajería que deben usarse en el mismo. DESCRIPCIÓN FUNCIONAL El presente servicio atómico se encargará de informar a los sistemas interesados de los movimientos de entrada, salida, asignaciones y anulación de entrada de artículos y pacientes … Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 53 MODELO DE COMUNICACIÓN La comunicación se llevará a cabo de forma síncrona entre el ESB y el sistema que ofrece el servicio. INTERFAZ Y PARÁMETROS El esquema WSDL del servicio será el siguiente: Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 54 MENSAJERÍA Listado de Mensajes A continuación se presenta un ejemplo del listado de esquemas de la mensajería. Tabla 1. Lista de esquemas Detalle del mensaje OMS^O05 Un mensaje OMS, según HL7, se usa para notificar los datos relativos de los movimientos de entrada, salida y asignaciones de artículos. Este tipo de mensajes sigue la definición estática que se presenta a continuación. A continuación se proporciona una breve descripción de los segmentos que Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 55 usaremos en este servicio atómico: • Segmento MSH: Segmento de cabecera del mensaje. Contiene información sobre el origen y el destinatario del mensaje, información de control y de seguridad. • Segmento PID: Información demográfica del paciente al que se remite la orden. Solo completar en el caso de órdenes con destino un paciente. • Segmento ORC: Contiene la información genérica del movimiento: origen, Id, fecha,. • Segmento RQD: Contiene la información del artículo a mover/transportar: Id, destino, cantidad, etc. • Segmento RQ1: Contiene información detallada de algunas de las características del artículo: precio, proveedor, IVA, etc. • Segmento OBX: Contiene observaciones. • Segmento NTE: Contiene comentarios de paciente y solicitud No se podrán informar segmentos o campos no indicados en este contrato. Del mismo modo aquellos segmentos o nodos no requeridos cuya información no esté disponible no deberán viajar vacíos en el mensaje. El esquema XSD de este tipo de mensaje se encuentra dentro del portal de UNIFICA en la comunidad de Interoperabilidad, concretamente en la siguiente ubicación: Unifica > Interoperabilidad > Documentación > Catálogo de Servicios > Definición de Servicios > Esquemas > OMS_O05.xsd. Detalle del Mensaje ACK Es un mensaje genérico que se utiliza como confirmación de recepción en las comunicaciones. La definición estática de este tipo de mensaje es: En el caso de respuesta positiva: En el caso de respuesta negativa: Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 56 La información a devolver por el sistema destino en los nodos MSH.3.1, MSH.3.2 y MSH.8 en esta respuesta es: A continuación se proporciona una breve descripción de los segmentos que usaremos en este servicio atómico: • El segmento MSA contiene información que indica si la petición ha sido recibida correctamente o no. • En el segmento ERR se detallan los posibles errores detectados durante el proceso de recepción de mensajes. No se podrán informar segmentos o campos no indicados en este contrato. Del mismo modo aquellos segmentos o nodos no requeridos cuya información no esté disponible no deberán viajar vacíos en el mensaje. El esquema XSD de este tipo de mensaje se encuentra dentro del portal de UNIFICA en la comunidad de Interoperabilidad, concretamente en la siguiente ubicación: Unifica > Interoperabilidad > Documentación > Catálogo de Servicios > Definición de Servicios > Esquemas > ACK.xsd. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 57 A continuación se proporciona un ejemplo, que no debe ser utilizado como guía para la implementación del servicio. Segmentos HL7 En este apartado se detallará el contenido de los campos que componen cada uno de los segmentos empleados para componer los mensajes HL7, así como los componentes y subcomponentes que los forman. A continuación se pasa a describir cada segmento, para lo que se tendrá que comprender la siguiente nomenclatura: Columna Campos: Nodo HL7 correspondiente. Columna Long: Longitud máxima del elemento. Columna Tipo: Indica el tipo de dato HL7. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 64 Segmento ORC En este segmento se incluirá la información relativa a la petición que se está realizando. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 65 Segmento TQ1 En este segmento se incluirá la información relativa a la prioridad de la petición. Segmento RQD Este segmento informa en detalle de los datos del artículo. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 66 Segmento RQ1 Este segmento detalla algunas de las características del artículo, relativas al fabricante y al proveedor. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 67 Segmento OBX Se detallará en este segmento la información relativa a las observaciones asociadas a la petición que se realiza. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 68 Segmento NTE Este segmento se utiliza para comunicar información complementaria de la observación. Segmentos Propios Mensaje Ack Segmento MSH Ver el segmento MSH definido en el punto de nodos comunes. Segmento MSA Información sobre la aceptación (o no) del mensaje de entrada incluida en el mensaje de salida. Segmento ERR Información sobre un error, en caso de producirse, que viajará en el mensaje de salida. Tablas HL7 y Tipos HL7 Los campos usados en este servicio que estén asociados a una tabla HL7 usarán la tabla definida en el estándar (véase documentación de referencia de HL7) siempre que no exista una tabla maestra corporativa del SAS asociada a la misma. En caso de existir, se hará uso de la tabla maestra corporativa, la cual se puede consultar en el documento de tablas maestras de la STI. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 69 Informar también que los tipos indicados en las tablas anteriores se corresponden con los tipos de datos HL7, para cualquier duda véase documentación de referencia de HL7. TRATAMIENTO DE ERRORES Definición Todos los errores que se puedan producir serán comunicados al sistema invocador en el mensaje de salida del servicio, mediante el uso de los segmentos MSA y ERR. Lista de Errores Tabla 2 Lista de errores Códigos de Aceptación (Nodo MSA.1) Tabla 1. Códigos de Aceptación Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 70 CUADRO RESUMEN Tabla 4. Cuadro Resumen Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 71 2.4. Preimplantación e Implantación. 2.4.1. Preimplantación SIGLO. Antes del comienzo de la implantación, los centros hospitalarios tuvieron que realizar unas tareas para la configuración de los procesos y las cargas iniciales de datos, necesarios para la correcta implantación de SIGLO. Cada centro tuvo que: • Enviar antes del 31/12/2010 la situación de los indicadores de las tareas de preparación de datos (FICHA). • Planificar la finalización de las tareas indicadas dentro de las fechas de fin, según el cronograma. Metodología de trabajo en la implantación por la empresa adjudicataria: • Elaboración 3C: Consultoría y Configuración de Circuitos con un Calendario de entrevistas (en algunos casos provinciales). • Migración y Carga de datos: Se envió un archivo comprimido “Implantación” con los formatos necesarios para la carga de datos. • Formación 15 días antes del arranque. • Puesta en producción. • Soporte: 3 meses desde la puesta en producción Tareas generales: • Se verificó la adecuación de la organización de los recursos logísticos del centro con los principios y bases organizativas del modelo corporativo de logística del SAS recogidos en el apartado 5.1. de la Resolución 2063/07 de 23 de mayo de 2007, de la Dirección General de Gestión Económica: 1. Puerta virtual única. 2. Identificación corporativa de los productos (SAS, CIP, GC y GS1). 3. Identificación corporativa de proveedores (maestro de proveedores). 4. Identificación corporativa del expediente (CCA). 5. Dirección unitaria de competencias logísticas. Identificación. • Se verificó la adaptación funcional del Centro a los criterios de diseño y funcionamiento de SIGLO®. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 72 Tareas de preparación de datos: 1. Definición del jefe de proyecto en el centro y equipo de apoyo. 2. Catalogación de todos los artículos. 3. Revisión unidades de consumo catálogo del centrocatálogo central. 4. Eliminar obsoletos. 5. Declarar y gestionar productos comprados sin CIP en ámbito CIP. 6. Sistema de Acreditación Logístico (SAL). 7. Acuerdos de Consumo definidos. 8. Identificación de programas internos. 9. Marketing, gestión de oferta y proveedores. 10. Explotación de datos. Cronograma: Provincia Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Sevilla H Macarena y Distrito Aljarafe D. Sevilla Norte Área Osuna SIGLO Nivel 4 Cádiz H Pta del Mar con D.Bahía de Cádiz SIGLO Nivel 4 Jaén H. Jaén, D. Jaén Norte D. Jaén D. Jaén Nordeste y CRTS SIGLO Málaga H.U.Virgen Victoria con DS Valle Guadalhorce H Regional Carlos Haya con CRTS Córdoba H. Reina Sofía y D. Guadalquivir SIGLO H. V. Nieves con D. Baza y D. Motril Granada H J.Ramón Jiménez , H. Vázquez Díaz, y CATS. Huelva H. Infanta Elena y D. Condado Campiña Almería 2010 Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 73 Provincia Enero Febrero Marzo Abril Mayo Junio Julio Agosto Septiembre Octubre Noviembre Diciembre Sevilla SIGLO Nivel 4 Cádiz SIGLO Nivel 4 AGS Norte Huelva Nivel 4 Jaén Nivel 4 Málaga SIGLO Nivel 4 Córdoba Nivel 4 Granada D. Huelva Costa SIGLO Huelva Almería 2011 Tareas de preparación de datos: Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 80 Formación APD ha impartido formación directa y también formación de formadores, al personal de nuestro centro, en el uso de la aplicación, estableciendo diferentes planteamientos organizativos, en función de los distintos módulos de la aplicación. En la formación se han tenido en cuenta las funciones que realizan actualmente los usuarios y los cambios que el nuevo sistema supondrá en su modo de trabajo. Para el desarrollo de formación se ha elaborado un plan conjunto con los servicios implicados para adecuar los horarios y contenidos a la realidad del servicio, con objeto de minimizar su impacto en el trabajo diario. La formación se ha procurado impartir a grupos de 15 personas máximo. A continuación se expone la planificación de la formación de Octubre-Noviembre del 2015, que si bien hubo repaso de cara al arranque en Mayo del 2016, esa fue la formación definitiva: Se definen los contenidos en función de los perfiles, así como la duración estimada para cada curso. Estos contenidos son susceptibles de modificación en función de las particularidades y horarios disponibles del personal implicado. Elaboración de Plan 2 Horas Impartir formación 40 Horas aprox. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 81 2.4.4. Implantación ATHOS. Tras las tareas previas a la preimplantación, se procede finalmente a la implantación de la herramienta gestora de las farmacias hospitalarias, ATHOS, en el ambito corporativo del SAS y para ello se siguen estas pautas: 1. Implantación en entorno de Producción. 2. Apoyo técnico en el proceso de puesta en marcha. 3. Soporte y atención al usuario durante el periodo de puesta en marcha. Cronograma de implantación ATHOS en Carlos Haya. Implantación en entorno de producción. Bajo la supervisión del personal del área técnica del centro y en colaboración con ella, se realiza la migración de la aplicación al entorno de producción. Se verifica la total disponibilidad del nuevo entorno. Migración de la aplicación 8 Horas. Apoyo técnico en el proceso de puesta en marcha. Una vez ejecutadas las fases anteriores, APD conjuntamente con el personal del centro hospitalario, procede a: • Arranque de los distintos módulos del sistema. • Supervisión del manejo de los usuarios. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 82 • Prueba de los diferentes interfaces con otras aplicaciones y verificación al final del día de que la información registrada es correcta. • Verificación del correcto funcionamiento de las integraciones. • Durante el período de puesta en marcha de la aplicación, APD aporta personal técnico con presencia física en el hospital, con el fin de resolver todas las dudas e incidencias que se produzcan en el uso de la aplicación. • Validar que el rendimiento del sistema es el adecuado (para analizar y resolver la lentitud del sistema, bloqueos, etc.). Apoyo técnico In Situ 16 Horas Soporte y atención al usuario durante el periodo de puesta en marcha. Se establece un plazo de 12 meses durante el cual APD pone a disposición del centro hospitalario un servicio de soporte y atención al usuario, durante el que se realiza el diagnóstico y resolución de incidencias relacionadas con la puesta en marcha, se pone a disposición del centro una línea de atención al usuario. Servicio de soporte y atención al usuario 12 meses Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 83 Conclusiones. Tras la exposición del sistema de gestión logístico informatizado en entornos hospitalarios, el análisis previo de los sistemas a implantar, la integración entre dichos sistemas y los ya implantados y los plazos de ejecución de cada proyecto implicado, podemos deducir que los objetivos de los Servicos Centrales del SAS, con la implantación de las herramientas corporrativas son buenos en si: • Homogenización de herramientas software, en todos los centros del SAS. • Posibilidad de acceso a la misma información desde cualquier centro del SAS. • Homogeneizar protocolos de integración con los sistemas electrónicos logísticos. • Optimizar recursos económicos, de personal y material. • Optimizar repartos de recursos dentro de cada Plataforma Provincial. Pero todos esto no es facil ni inmediato y mucho menos en una comunidad autonoma como Andalucia, por su extención, número de centros y recursos a gestionar. Años se requiere, para implantar completamente las distintas herramientas, con sus correspondientes integraciones en toda la comunidad autónoma. Si a todo esto le sumamos la crisis, los recursos económicos disponibles mermados han dado al traste con los plazos e incluso con las decisiones a tomar. Las intenciones han podido ser muy buenas y aunque poco a poco las herramientas se van ajustando, como un engranaje lubricado con cuentagotas, todavía queda mucho por hacer y a menudo porque incluso habiendose partido de buenos grupos de trabajo, con análisis con resultados muy completos, los productos entregados carecen de un alto número de funcionalidades reflejadas en dichos análisis. Si partimos de productos que no se desarrollan desde cero, todo se complica aun más. Incluso tenemos productos bajo un mismo nombre, cuyas funcionalidades han sido adjudicadas a distintos proveedores. La situación actual es un sistema de grandes pretensiones, en los objetivos de los Servicios Centrales y no digamos ya de los usuarios, con una gran disgregación de proveedores cuyas herramientas tratan de entenderse mediante un sistema de mensajeria que no está excento de fallos y cuyo soporte es muy complejo, porque aunque está centralizado, está subcontratado a empresas que no tienen porque corresponderse con ninguna de las adjudicatarias de las herramientas implantadas y es muy frecuente que las soluciones a las incidencias, se dilaten habitualmente por desavenencias entre dichos proveedores. Las herramientas sustituidas tampoco eran perfectas y en el momento del cambio tenian un alto nivel de aceptación. Ese es nuestro objetivo, con el tiempo adquirir un alto nivel de aceptación, tras la mejora continuada de los nuevos sistemas. Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 84 Referencias bibliográficas. Hacia una Plataforma Provincial de Logística Integral y un Número único de Historia de Salud de Andalucía (NUHSA): El empujón tecnológico corporativo del SAS. Eficiencia de Escala en el Proceso Logístico Integral 27-04-10 El sistema de reposición por Código de Barras, en los Almacenes de Planta: Informe reposición con Código de Barras. Especificaciones ATHOS e Integración ATHOS-SIGLO: SA 0099_12 de 16 Abril 2012. Ordenación de la gestión de medicamentos en los centros SAS ATHOS. Grupos de expertos, su composición: Procedimiento de Identificación de Pacientes. DIRECCIÓN GENERAL DE GESTIÓN ECONÓMICA, Subdirección de Compras y Logística: Tareas Pre-implantación SIGLO 20.12.2010. Calendario de Arranque de SIGLO. Sistema de Información Corporativo para Farmacia Hospitalaria: Protocolo de implantación ATHOS. Formación ATHOS APD. ATHOS cronograma V.4.0. ATHOS/Dosis: Asociación del módulo de prescripción, rama “ATHOS” en MACO (Guía de Prescripción). Estudio e implantación de sistemas logísticos informatizados aplicados a entornos hospitalarios. Francisco José Ruiz Nieto Página 85 Aportes tecnológicos: Datalogic Manual de la PDA modelo Datalogic Memor. Grifols Movaco S.A. Kardex@: funcionalidades, integraciones y correos de coordinación para la implantación de ATHOS. Pyxis@: funcionalidades, integraciones y correos de coordinación para la implantación de ATHOS. Palex Medical S.A. Omnicels@: funcionalidades, integraciones y correos de coordinación para la implantación de ATHOS.