adquisición e implantación de un sistema de … alcance técnico de la solución ... 6.3.16...

Laboratorio_2015-2018 Página 1/66

Adquisición e Implantación de un Sistema de

información para los laboratorios de Osakidetza


Índice Página

1 INTRODUCCIÓN ............................................................................................................... 4

2 SITUACION ACTUAL ........................................................................................................ 5

3 OBJETO DEL CONTRATO ............................................................................................... 8

4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN ..................................................... 10

4.1 Alcance Funcional .................................................................................................... 10 4.1.1 Nivel 1: Red de diagnóstico biológico ................................................................................ 10 4.1.2 Nivel 2: Unidades de gestión .............................................................................................. 11 4.1.3 Nivel 3: Servicios y laboratorios centrales ......................................................................... 11 4.1.4 Nivel 4: Laboratorios de respuesta hospitalaria (LRH) y Urgencias (LURG) .................... 12 4.1.5 Nivel 5: Point of Care Testing (POCT) .............................................................................. 12

4.2 Detalle de las funcionalidades requeridas.............................................................. 13 4.2.1 Estructura básica y Configuración del Sistema .................................................................. 13 4.2.2 Gestión de Peticiones y Visor de Resultados ...................................................................... 14 4.2.3 Gestión de la Extracción ..................................................................................................... 15 4.2.4 Gestión de Laboratorio ....................................................................................................... 16 4.2.5 Gestión de Estadística, Sistema de Calidad y Gestión Documental ................................... 18 4.2.6 Facturación ......................................................................................................................... 19

5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN ............................................................. 20

5.1 Alcance técnico de la solución ................................................................................. 20

5.2 Entornos .................................................................................................................... 21

5.3 Plan de Contingencia ............................................................................................... 22

6 LÍNEAS DE TRABAJO .................................................................................................... 23

6.1 Consultoría ............................................................................................................... 23

6.2 Migración de información Histórica ...................................................................... 23

6.3 Integración con los S.I. Corporativos ..................................................................... 23 6.3.1 Catálogos Corporativos ...................................................................................................... 24 6.3.2 Gestor Documental ............................................................................................................. 24 6.3.3 SAP: Recursos Humanos .................................................................................................... 24 6.3.4 e-Osabide. Atención Especializada (HIS hospitalario) ....................................................... 24 6.3.5 Osabide-AP. (Estación clínica Atención Primaria) ............................................................ 25 6.3.6 Osabide-Global. (Estación clínica Atención Especializada) ............................................... 25 6.3.7 CLINIC. Visor de Historia Clínica ..................................................................................... 26 6.3.8 Índice de laboratorio (IPL) ................................................................................................. 26 6.3.9 Versia (Nefrología) ............................................................................................................. 26 6.3.10 Cuidados intensivos ....................................................................................................... 26 6.3.11 Infección Nosocomial (INOZ) ....................................................................................... 27 6.3.12 TAO. Sistemas de Anticoagulación ............................................................................... 27 6.3.13 Net bank. Banco de Sangre ............................................................................................ 27 6.3.14 SSDwlab 6. Cribado de Síndrome de Down .................................................................. 27 6.3.15 Programa de Cribado de Cáncer Colorrectal ................................................................. 27 6.3.16 Sistema Económico-Financiero (ERP-SAP) (Pdte. Unzaga) ......................................... 28 6.3.17 Salud Pública (SIM). Dpto. Salud .................................................................................. 28 6.3.18 Gasometrías ................................................................................................................... 28

6.4 Formación y Coaching ............................................................................................. 28 6.4.1 Formación ........................................................................................................................... 28 6.4.2 Coaching ............................................................................................................................. 29

6.5 Implantación ............................................................................................................ 30 6.5.1 Atención a consultas y Soporte ........................................................................................... 30


6.5.2 Mantenimiento evolutivo .................................................................................................... 31

6.6 Monitorización ......................................................................................................... 32

7 PRODUCTOS A OBTENER ............................................................................................. 33

8 PLANIFICACIÓN DEL PROYECTO.............................................................................. 34

9 EQUIPO DE TRABAJO ................................................................................................... 35

10 CONTENIDO DE LAS OFERTAS .................................................................................. 36

11 PROPIEDAD DE LOS PRODUCTOS ............................................................................. 38

12 CONFIDENCIALIDAD .................................................................................................... 39

13 PRESUPUESTO, PLAZOS Y PENALIZACIONES ........................................................ 40

13.1 Presupuesto .............................................................................................................. 40

13.2 Plazos ........................................................................................................................ 40

13.3 Forma de pago .......................................................................................................... 40

14 CRITERIOS DE ADJUDICACIÓN ................................................................................. 41

15 CONSULTAS AL PLIEGO ............................................................................................... 43

16 ANEXO I: DOCUMENTO DE ARQUITECTURA Y TECNOLOGÍA ........................... 44

16.1 Arquitectura y tecnología ........................................................................................ 44 16.1.1 Consideraciones Tecnológicas ....................................................................................... 44 16.1.2 Dispositivos de entrada/salida ........................................................................................ 47 16.1.3 Seguridad, acceso, autenticación y autorización ............................................................ 48 16.1.4 Monitorización ............................................................................................................... 48 16.1.5 Backup/Restore .............................................................................................................. 49

16.2 Interoperabilidad ..................................................................................................... 49 16.2.1 Servicios Web ................................................................................................................ 50 16.2.2 Gestor de Eventos .......................................................................................................... 51

16.3 Alineamiento con las Directrices Tecnológicas ..................................................... 52

17 ANEXO II: RED DE COMUNICACIONES .................................................................... 53

17.1 Elementos principales .............................................................................................. 53 17.1.1 Datacenter ...................................................................................................................... 53 17.1.2 Red WAN ...................................................................................................................... 53

17.2 Caudal Centros con Laboratorio ............................................................................ 54

18 ANEXO III: ESPECIFICACIONES DEL CLIENTE (MAQUETA) . ............................ 56

19 ANEXO IV: CONEXIONES/LABORATORIO ............................................................... 57

19.1 Analizadores ............................................................................................................. 57

19.2 Middleware ............................................................................................................... 64

20 ANEXO V: CRITERIOS DE SELECCIÓN ..................................................................... 66


1 INTRODUCCIÓN El Plan Director de los Laboratorios de Osakidetza (PDL), ha puesto de manifiesto la necesidad de renovación tecnológica de la actual solución para la gestión de los laboratorios, por lo que el presente expediente propone la adquisición de un software especializado que permita, tanto una gestión adecuada de los pacientes y el proceso del laboratorio, como una correcta explotación de sus resultados, en un entorno corporativo en el que los laboratorios trabajan integrados en la Red de Diagnóstico Biológico de Osakidetza (RDBO). El nuevo sistema de información debe contemplar todo el proceso asistencial del laboratorio, incluyendo la gestión de solicitudes, en un contexto de integración de las disciplinas del Laboratorio Clínico y las demás aplicaciones corporativas, incluyendo los aspectos de gestión clínica, el control de calidad y la gestión de conocimiento, además de las herramientas para la docencia y la investigación. La RDB de Osakidetza está integrada por los siguientes centros:

• Hospital Universitario Donostia (HUD) o Hospital Bidasoa (HBD) o Hospital de Mendaro (HMEN) o Hospital de Zumárraga (HZU)

• Hospital Universitario Araba (HUA) o Hospital Alto Deba (HAD) o Hospital de Txagorritxu (HTX) o Hospital de Santiago Apóstol (HSA) o Hospital de Leza (HLZ)

• Hospital Universitario Cruces (HUC) o Hospital San Eloy (HSE) o Hospital de Urduliz (HUR)

• Hospital de Galdakao-Usansolo (HGU) o Hospital de Gernika (HGE)

• Hospital Universitario Basurto (HUB) o Hospital de Sta. Marina (HSM)


2 SITUACION ACTUAL En la actualidad existe una único LIS en Osakidetza , la solución Omega 3000 de Roche junto al sistema de gestión de muestras PSM de la misma empresa, con una instalación distribuida, independiente y diferenciada por cada laboratorio. Existe una identificación única del paciente en Osakidetza (CIC-Código de Identificación Corporativo), y un Número de Identificación de Solicitudes único en toda la RDBO. No existen catálogos corporativos en el ámbito del laboratorio, aunque actualmente se está trabajando en el catálogo de pruebas, y cada laboratorio hace uso de catálogos, prestaciones y circuitos diferenciados. Existe un sistema de mapeo manual y básico entre los 5 laboratorios centrales, que permiten un mínimo nivel de interoperabilidad entre los mismos, de forma que se envían muestras y se reciben resultados entre los distintos laboratorios de forma electrónica sin cambios en la numeración La mayoría de las solicitudes son electrónicas. Existen 2 gestores de peticiones diferenciados:

• Atención Primaria: o Osabide-AP (módulo de Petición)

� Gestiona el petitorio electrónico de la Atención Primaria � Desarrollo propio, tecnología C/S (Cliente/servidor), VB (Visual

Basic) y BBDD (Base de Datos) Oracle. � Aplicación centralizada

o Osabide-AP (módulo de Extracciones)

� Asociación de la muestra con la orden médica (solicitud) � Desarrollo propio, tecnología C/S, VB y BBDD Oracle. � Aplicación centralizada

o Osabide-AP (módulo de Laboratorio)

� Gestiona la Recepción / Envío de peticiones/resultados entre Osabide-AP y Omega 3000

� Desarrollo propio, tecnología C/S, VB y BBDD Oracle. � Aplicación centralizada

• Atención Especializada:

o Osabide Global (módulo de Petición/Extracciones) � Gestiona el petitorio electrónico de la Atención Especializada � Asociación de la muestra con la orden médica (solicitud) � Desarrollo propio, tecnología C/S, Centura y BBDD Oracle. � Aplicación distribuida, con una instalación por hospital

o PCH-LAB ((módulo de Extracciones/Laboratorio)

� Asociación de la muestra con la orden médica (solicitud) y gestión de los pacientes pendientes de extracción

� Gestiona el envío de peticiones entre Osabide-Global y Omega 3000

� Desarrollo propio., tecnología C/S, Centura y BBDD Oracle. � Aplicación distribuida, con una instalación por hospital


El circuito de laboratorio Primaria-Especializada está integrado, pudiendo darse el caso de una petición realizada en la Especializada, cuya extracción se realiza en Primaria, y la sucesiva de resultados se ve de nuevo en el hospital. En definitiva, el LIS en funcionamiento, ofrece en cada instalación, funcionalidades diferenciadas, basadas en estructuras y procedimientos distintos, de difícil integración, dificultando la racionalización de los servicios ofertados y la gestión global de la prestación. La población de referencia del año 2.013, volumen de usuarios y nº de camas por laboratorio, es la siguiente:

Hospital Nº. camas

Nº. PCs

Nº. Habitantes

Hospital Universitario Donostia (HUD) 1.100 130

650.000 Hospital Bidasoa 80 17

Hospital Mendaro 100 18

Hospital Zumárraga 100 27

Hospital Universitario Araba (HUA) 62

350.000

Hospital Santiago (HUA) 100 na

Hospital Txagorritxu (HUA) 500 na

Hospital Alto Deba 100 12

Hospital Leza 50 0

Hospital Universitario Cruces (HUC) 1.000 102

500.000 Hospital San Eloy 120 26

Hospital Urduliz 160 na

Hospital Galdakao-Usansolo (HGU) 400 68 300.000

Hospital Gernika 3

Hospital Universitario Basurto (HUB) 700 93 400.000

Hospital Sta. Marina 100 3

Totales 3.320 2.200.000 **Nota: Datos de PCs (inventario a 30/3/2014).

La actividad aproximada de cada Unidad de Gestión Clínica, en función de las peticiones (volantes) y determinaciones (pruebas) que se realizaron en el año 2014, para atender el diagnóstico biomédico de la población de referencia, fue la siguiente:

UGC Nº.

Peticiones (volantes)

Nº. Determinaciones

Hospital Universitario Donostia (HUD) 1.100.000 15.000.000 Hospital Universitario Araba (HUA) 800.000 8.000.000 Hospital Universitario Cruces (HUC) 1.000.000 13.000.000 Hospital Galdakao-Usansolo (HGU) 600.000 6.000.000 Hospital Universitario Basurto (HUB) 800.000 8.500.000

Totales 4.300.000 50.500.000


Los licitadores deberán acreditar si Osakidetza así lo solicita, que los requerimientos exigidos están operativos para todas las disciplina s de los laboratorios , en el momento de presentación de ofertas.


3 OBJETO DEL CONTRATO El objeto principal de este expediente es la adquisición e implantación de un sistema de información para la gestión de los laboratorios de Osakidetza (software), la migración de información desde el sistema actual y el desarrollo de las integraciones requeridas. El objeto del contrato incluye:

• Software comercial , para gestión de todos los laboratorios de las 5 Unidades de Gestión Clínica de laboratorio integrados en la Red de Diagnóstico Biológico de Osakidetza . El producto ofertado por los licitadores, deberá suministrarse en régimen de licenciamiento corporativo (número ilimitado de usuarios y centros). La solución propuesta deberá ser Multiidioma.

• Software comercial para la implantación de un gestor global de peticiones

que incluya: o la solicitud electrónica asistida, integrada (embebida) en la

estaciones clínicas de Osakidetza , OsabideGlobal y Osabide-AP o la visualización de los informes integrada con las mencionadas

estaciones clínicas y o la gestión de la obtención de muestras .

Este producto deberá estar totalmente integrado con el sistema de gestión de laboratorio anteriormente mencionado, pudiendo ser parte del anterior producto, o un producto diferenciado, y al igual que el mismo, deberá suministrarse en régimen de licenciamiento corporativo (número ilimitado de usuarios y centros), teniendo en consideración que el uso del mismo se extenderá a todos los profesionales sanitarios que participen en la asistencia al paciente.

La solución propuesta deberá ser Multiidioma .

• Conexión del producto ofertado con los analizadores, equipos y

middleware operativos en el momento de la implantación del producto. Se consideran incluidas sin cargo en este expediente las conexiones a 270 equipos y 50 middleware en el conjunto de la RDB. Se incluye el detalle orientativo del equipamiento actual en el Anexo IV. Se incluirá también el mantenimiento de estas conexiones durante la vigencia del contrato.

En el fututo , la empresa adjudicataria podrá facturar los gastos de conexión al LIS de nuevos autoanalizadores y demás equipos, a las empresas de diagnóstico que resulten adjudicatarias para la instalación de los mismos, según precios de mercado.

• Migración de información y transición, desde la plataforma actual de Osakidetza , al nuevo sistema.

• Integración de los productos ofertados, con el resto de sistemas de


información corporativos de Osakidetza y del Departamento de Salud.

• Implantación de la solución. Incluyendo el análisis previa en cada UGC de las adaptaciones requeridas si fueran necesarias, el despliegue de la solución con soporte local on site, y la formación al personal sanitario, administrativo e informático. Dentro del proyecto de implantación de la solcuicón, se incluye como garantía durante la vigencia del contrato el soporte

El precio de las licencias ofertadas incluirá la garantía durante toda la vigencia del contrato. Será obligación del contratista durante este período

• Poner a disposición de Osakidetza y autorizar el uso de la última versión o actualización disponible en el mercado de todos los productos relacionados en el objeto del presente pliego

• Entregar a Osakidetza todas las versiones mayores de productos y tecnología, que incluyen versiones generales de mantenimiento, versiones de funcionalidad seleccionada y actualizaciones de documentación

• Dar acceso a la base de conocimiento y soporte Web (sistemas de soporte al cliente basados en la web), incluida la posibilidad de registrar peticiones de servicio en línea

• Servicio telefónico y local de soporte, para la resolución de incidencias y peticiones de servicio.

Los entornos a utilizar en el proyecto y cuyas licencias deberán ser suministradas, serán los siguientes:

• Entorno de Pre-producción • Entorno de Producción

Toda la plataforma hardware y software de base (sistema operativo) requeridos para la implantación del nuevo producto, así como los servicios de administración, monitorización, y operación de la misma, serán suministrados por la Subdirección de Informática y Sistemas de Información de la Organización Central de Osakidetza , no estando incluidos en el objeto de este contrato. La solución ofertada deberá ser multiplataforma (hardware y sistema operativo), pudiendo implantarse, bajo los estándares de Osakidetza que se detallan en Anexo I. Las estaciones de trabajo (PCs) y su software de base, serán los existentes en los hospitales de Osakidetza , por lo que quedan también, fuera del alcance de este contrato, siendo necesario que el producto ofertado se ajuste a la maqueta de Osakidetza que se detalla en el Anexo III.


4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN El Sistema de Información de Laboratorio (LIS), es considerado como una herramienta de trabajo imprescindible para incrementar la productividad y mejorar la calidad asistencial. Dentro del enfoque en el uso de las nuevas tecnologías, Osakidetza pretende incorporar un sistema de información común, integral e integrado que dé servicio a la Red de Diagnóstico Biológico de Osakidetza . Se pretende que el LIS común, se integre además con los SI corporativos de Osakidetza , y los Sistemas de Salud Pública del Departamento de Salud.

4.1 Alcance Funcional El proyecto de implantación de un Sistema de Información para la gestión de los Laboratorios (LIS) debe responder a la estructura y tipología de laboratorios de la RDBO establecida por el Plan Director, basada en un concepto corporativo, jerárquico y multicéntrico de 5 niveles.

4.1.1 Nivel 1: Red de diagnóstico biológico Es el nivel corporación. La solución ofertada debe de ofrecer a este nivel:

• Mantenimiento de catálogos y diccionarios corporativos únicos: o Solicitantes, centros, servicios peticionarios, centros de extracción, centros

de coste o Pruebas, muestras, antibióticos, microorganismos, contenedores. o Reglas corporativas


o Gestión de la integración con otros sistemas corporativos o Gestión de permisos a este nivel.

• Información de actividad, calidad, costes y epidemiológica globalizada y por UGC

• Indicadores y cuadros de mando globalizados y por UGC. • Gestión de peticiones compartidas entre los laboratorios de la RDB. • Gestión de envíos de muestras y recepción de resultados entre los laboratorios

de las 5 UGC.

4.1.2 Nivel 2: Unidades de gestión La solución ofertada debe dar soporte a las 5 Unidades de Gestión Clínica de Laboratorios (UGC) de la RDB :

• Hospital Universitario Donostia (HUD) • Hospital Universitario Araba (HUA) • Hospital Universitario Cruces (HUC) • Hospital Universitario Basurto (HUB) • Hospital de Galdakao-Usansolo (HGU).

Ofreciendo a este nivel los siguientes servicios:

• Información de actividad, calidad, costes y epidemiológica por UGC y por Servicio y Laboratorio

• Indicadores y cuadros de mando globalizados y por Servicio y Laboratorio. • Gestión de peticiones compartidas dentro de los laboratorios de la UGC • Gestión de envíos de muestras y recepción de resultados entre los laboratorios

de la UGC. • Gestión de permisos a nivel de UGC

4.1.3 Nivel 3: Servicios y laboratorios centrales La solución ofertada deberá proveer de las funcionalidades de gestión de laboratorios a los laboratorios centrales de las 5 UGCs, ubicados en los hospitales de referencia de la UGC. La solución debe ser lo suficientemente flexible para adaptarse a distintos modelos y disciplinas del laboratorio:

• Hospital Universitario Donostia (HUD) o Laboratorio Core o Servicio de Inmunología o Servicio de Hematología o Servicio de Bioquímica o Servicio de Microbiología o Servicio de Genética

• Hospital Universitario Araba (HUA)

o Laboratorio Core o Servicio de Hematología o Servicio de Bioquímica o Servicio de Microbiología o Servicio de Genética


• Hospital Universitario Cruces (HUC) o Laboratorio Core o Servicio de Inmunología o Servicio de Hematología o Servicio de Bioquímica o Servicio de Microbiología o Servicio de Genética

• Hospital Universitario Basurto (HUB)

o Laboratorio Core o Servicio de Hematología o Servicio de Bioquímica o Servicio de Microbiología o Servicio de Genética

• Hospital de Galdakao-Usansolo (HGU)

o Laboratorio Core o Servicio de Hematología o Servicio de Bioquímica o Servicio de Microbiología

4.1.4 Nivel 4: Laboratorios de respuesta hospitalar ia (LRH) y Urgencias (LURG) De las 5 UGC, 4 de ellas incluyen LRH ubicados en hospitales comarcales , que dan servicio fundamentalmente a los pacientes ingresados y a las solicitudes urgentes en un contexto de integración con el laboratorio central de la UGC. La solución propuesta debe prestar funcionalidades de urgencias, laboratorio general y microbiología a los LRHs, adaptándose a la dimensión de estos laboratorios:

• Hospital Universitario Donostia (HUD) o LRH Hospital Bidasoa o LRH Hospital de Mendaro o LRH Hospital de Zumárraga

• Hospital Universitario Araba (HUA)

o LRH Hospital Alto Deba o LURG Hospital de Txagorritxu o LURG Hospital de Santiago Apóstol

• Hospital Universitario Cruces (HUC)

o LRH Hospital San Eloy o LRH Hospital de Urduliz

• Hospital de Galdakao-Usansolo (HGU)

o LURG Hospital de Gernika

4.1.5 Nivel 5: Point of Care Testing (POCT) Este nivel solo requiere la conectividad de los equipos POCTs. Así pues, y en base a lo anteriormente descrito, el ámbito de implantación del proyecto se extenderá a:


• Los 5 laboratorios centrales de las UGC:

o Hospital Universitario Donostia (HUD) o Hospital Universitario Araba (HUA) o Hospital Universitario Cruces (HUC) o Hospital Universitario Basurto (HUB) o Hospital de Galdakao-Usansolo (HGU)

• Los 9 laboratorios de Respuestas Hospitalaria (LRH), integrados en los

anteriores: o Hospital Universitario Donostia (HUD)

� LRH Hospital Bidasoa � LRH Hospital de Mendaro � LRH Hospital de Zumárraga

o Hospital Universitario Araba (HUA) � LRH Hospital Alto Deba � LRH Hospital de Txagorritxu

o Hospital Universitario Cruces (HUC) � LRH Hospital San Eloy � LRH Hospital de Urduliz

o Hospital de Galdakao-Usansolo (HGU) � LRH Hospital de Gernika

• Los 2 POCT

o Hospital de Leza o Hospital de Sta. Marina

4.2 Detalle de las funcionalidades requeridas Además de los requisitos generales detallados en el apartado anterior, el producto ofertado deberá incluir las siguientes funcionalidades.

4.2.1 Estructura básica y Configuración del Sistema

4.2.1.1 Gestión de Pacientes Toda la gestión de Pacientes se establecerá a través de servicios de integración con la BBDD Corporativa de Pacientes de Osakidetza . Se deberán incluir mínimamente las siguientes operaciones, junto con sus servicios de integración:

• Alta, Baja. Modificación de Pacientes • Fusión de Pacientes • Búsqueda de Pacientes por múltiples criterios

4.2.1.2 Gestión Seguridad y Accesos La autenticación en el sistema se realizará vía integración con el Directorio Activo de Osakidetza . El sistema ofertada permitirá la gestión de roles de usuarios y la trazabilidad de la actividad realizada por éstos.


4.2.1.3 Catálogos Corporativos El sistema propuesto ofertará una gestión corporativa y única de los principales catálogos del laboratorio (pruebas, unidades, muestras, microorganismos, etc.), incluyendo adicionalmente, la posibilidad de personalización a nivel de UGC, de ciertos atributos de estos catálogos. Se deberán detallar los mecanismos que garanticen la gestión, mantenimiento e integridad de estos catálogos. Todos los datos relativos a los demográficos de una solicitud, relacionados con la estructura organizativa de Osakidetza (centros, servicios, secciones, profesionales, etc.), serán suministrados por el sistema de gestión corporativo de Osakidetza , siendo necesaria su integración y sincronización.

4.2.2 Gestión de Peticiones y Visor de Resultados

4.2.2.1 Petición Electrónica La solución propuesta deberá incluir un sistema de “Petición Electrónica” universal para todo Osakidetza , que facilite el control de la demanda y que se sustentará sobre la definición corporativa de Catálogos definida en el apartado anterior. Las características de este sistema serán las siguientes:

• Se integrará plenamente en la estación clínica corporativa y estará disponible para el personal asistencial. (aproximadamente 6.000 profesionales).

• Deberá acoplarse a la estación Clinica de Osakidetza , como si se tratase de

una parte de la misma, y deberá garantizar un manejo sencillo e intuitivo. No se admitirán soluciones que requieran que el usuario salga de la Estación Clinica para acceder al petitorio de pruebas.

• Deberá posibilitar la recepción y tratamiento de datos clínicos procedentes de

la Historia Clínica de Osakidetza , para su gestión en el laboratorio.

• Deberá ser altamente configurable en función de la tipología de usuario, interoperable entre laboratorios e incorporará un interfaz ágil y sencillo que permita que el laboratorio sea autónomo para la configuración de paneles de solicitud.

• Incluirá la posibilidad de definición de perfiles y protocolos, habilitando el

acceso a la información sobre su composición o algoritmo. Además, se deberá incorporar la gestión de pruebas funcionales.

• Incluirá la posibilidad de acceso a la información de la prueba o muestra del

Catálogo, y se valorará la publicación de información que se considere de utilidad (coste petición, demora máxima resultado, resultados anteriores, etc), en el momento de la solicitud.

• Permitirá la definición de reglas personalizables y configurables por el

laboratorio, estableciendo un dialogo interactivo con el peticionario, a través de la estación clínica.

• Permitirá la petición combinada de pruebas con distintas prioridades.


• Gestión de solicitudes múltiples con extracción única (Primaria y Especializada)

y gestión de solicitudes multimuestra (microbiología).

• Se generará la solicitud electrónica de la petición que se integrará con la HC de Osakidetza , para su posterior citación y/o extracción. Se imprimirá además, la hoja de extracción con los contenedores necesarios, condiciones preanalíticas y del paciente, así como la recomendación del orden de extracción.

4.2.2.2 Gestión de la Citación La definición de agendas y gestión de la cita a Extracción, se realizará en el HIS corporativo de Osakidetza , de la siguiente forma:

• El LIS (módulo de petición electrónica), enviará al HIS corporativo la solicitud electrónica de citación , en aquellas áreas asistenciales que sea necesario.

• El HIS hospitalario tratará y citará la solicitud recibida, enviando la fecha de citación al LIS (módulo de extracción).

• El LIS (petición electrónica) deberá entregar al HIS corporativo toda la información necesaria para realizar la cita, incluyendo aquellas condiciones especiales de la prueba (atributo del Catálogo), que puedan alterar el mapa de citación definido por Osakidetza . Indicar que el mapa de citación está contenido en el HIS corporativo, y determina el centro en que debe ser citado el paciente, en base a criterios de ordenación sanitaria.

4.2.2.3 Visor de resultados Visualizador de informes de laboratorio en tiempo real para todos los clínicos de Osakidetza embebido en la estación clínica que permita la consulta en tiempo real de la información validada en cualquier laboratorio para el que esté autorizado.

• Intuitivo, rápido y de fácil uso. • Visualización del estado de la solicitud • Aviso de solicitudes con resultados pendientes de visualizar. Control de

fechas y horas de visualización. • Posibilidad de aviso de solicitudes con resultados críticos por canales

diversos (alertas en el SI). • Texto, gráficos, imágenes y tablas. • Visualizador evolutivo por prueba o grupo de pruebas con gráficos. • Visualización de pruebas funcionales • Posibilidad de capturar partes del informe o tablas y gráficos evolutivos para

su utilización en otros informes.

4.2.3 Gestión de la Extracción La solución propuesta deberá incluir un módulo específico para la gestión de las Extracciones, que deberá incluir al menos las siguientes funcionalidades:

• Deberá posibilitar la configuración de múltiples centros/salas de extracción, de

diferentes tipología (centros hospitalarios, plantas de hospitalización, centros de salud, etc), respondiendo a la estructura de niveles de la RDBO.

• Se integrará con los SI Corporativos de Osakidetza , principalmente Estación Clínica y HIS (citación).


• Deberá posibilitar la extracción de una prueba procedente de cualquiera de la UGCs de Osakidetza , recalculando el número y tipo de contenedores, si fuera necesario.

• Deberá garantizar la posibilidad de: impresión de etiquetas para los contenedores, trabajar con etiquetas preimpresas o con contenedores pre-etiquetados.

• Se valorará la inclusión de aquellas funcionalidades que faciliten la gestión del proceso de extracción, trazabilidad y seguridad del paciente.

• Se valorará la posibilidad de gestión de volantes múltiples con extracción única (Primaria-Especializada).

4.2.4 Gestión de Laboratorio Se deberán incluir al menos las siguientes funcionalidades:

4.2.4.1 Gestión de Solicitudes intralaboratorio Hace referencia a las funcionalidades que debiera incluir la solución ofertada para la gestión de las peticiones no mecanizadas, y que llegarán al laboratorio en soporte papel. Se deberán incluir al menos las siguientes funcionalidades:

• Registro de solicitudes altamente configurable, seguro, intuitivo y ágil. • Digitalización y consulta del volante en soporte papel, vía lectores de

formularios (volante grafitado) escáneres, etc.

4.2.4.2 Preanalítica La solución ofertada deberá incluir las funcionalidades que permitan de forma ágil, segura y eficiente, la gestión de las muestras desde su extracción hasta el inicio del proceso analítico, incluyendo:

• El registro de presencia de la muestra y su activación. • Conexión con sistemas de clasificación y alicuotación automática. • Sistema de clasificación, alicuotación y enrutado de muestras manual, con

impresión de etiquetas. • Reglas de gestión de muestras: enrutado, clasificación, alicuotación, etc. • Trazabilidad completa de la muestra.

Se valorará la funcionalidad general de la gestión preanalítica en el contexto del conjunto de laboratorios de la RDBO.

4.2.4.3 Conectividad intralaboratorio La solución ofertada deberá ser capaz de conectarse a todos los analizadores, sistemas preanalíticos y middleware en su caso, detallados en el anexo IV, de forma segura, ágil y monitorizable, aprovechando al máximo las posibilidades de comunicación y funcionalidad que ofrezca el instrumento y/o middleware (datos, imágenes, alarmas, control de calidad, lotes de reactivo, etc..)

4.2.4.4 Conectividad extralaboratorio La solución debe permitir y facilitar el envío de pruebas entre los distintos laboratorios de la RDBO de una forma ágil, segura y monitorizable, con un control total sobre los


envíos y la recepción de resultados. Se valorará la funcionalidad y posibilidades de personalización y monitorización del sistema.

4.2.4.5 Gestión de reglas, eventos y alarmas Sistema de reglas manuales y/o automáticas aplicables en cualquier evento que se produzca en todo el proceso. Las reglas deberían tener el rango de corporativas, de UGCs y de servicio/laboratorio. Se valorarán las posibilidades en la confección de estas reglas en cuanto a operadores, operandos, funciones, variedad de eventos disparadores, acciones posibles y proactividad general del sistema. Se valorará asimismo la simplicidad y gestión general de reglas.

4.2.4.6 Control de calidad Deberá disponer de un módulo de control de calidad que permita gestionar el control de calidad analítico, recibiendo datos de los analizadores, el middleware o manualmente y que abarque todas las disciplinas del laboratorio. Se valorará la funcionalidad general de este apartado así como sus capacidades de relación con los datos de los pacientes.

4.2.4.7 Validaciones Deberá permitir varios niveles de validación analítica y clínica, manual y automática con gran agilidad y las máximas posibilidades funcionales y de personalización, que garanticen la seguridad y aportación de valor de todo el proceso. Se valorará la funcionalidad general de esta apartado, la facilidad de acceso a información útil para realizar el proceso (datos clínicos, otros resultados, control de calidad, etc.), las acciones que son posibles a este nivel y las posibilidades de automatización.

4.2.4.8 Informes La solución ofertada deberá permitir la edición y configuración de informes con datos de todo tipo y una gran capacidad de personalización en función de las distintas disciplinas del laboratorio. Los informes deberán poder emitirse en bilingüe, euskera/castellano .

4.2.4.9 Otros aspectos específicos de las disciplin as de laboratorio

Urgencias 4.2.4.9.1Deberá disponer de pantallas y herramientas específicas para una gestión y seguimiento ágiles e intuitivos de peticiones y pruebas urgentes, que ayuden a los profesionales a garantizar unos tiempos de respuesta óptimos tanto en los laboratorios de referencia como en los laboratorios de respuesta hospitalaria.


Adicionalmente, este sistema deberá permitir la gestión de peticiones que combinan pruebas con distinta prioridad.

Microbiología 4.2.4.9.2El sistema debe adaptarse a las particularidades de la disciplina de Microbiología permitiendo su gestión integral. Se detallan algunas necesidades consideradas muy importantes en Microbiología, independientemente de que sean o no comunes al resto de disciplinas:

• Gestión integrada de toda la microbiología, incluyendo biología molecular y serología para interactuar con la información en un mismo módulo.

• Reglas automáticas-inteligentes, en todas las etapas del proceso. Preanalíticas, analíticas y postanalíticas, incluyendo alertas automatizadas a destinatarios concretos sobre microorganismos o resultados de interés clínico o epidemiológico, y alarmas de resultados incongruentes (por valoración conjunta de pruebas y por comparación con resultados previos).

• Módulo estadístico de fácil manejo por el usuario. • Evitar pérdidas de información estadística por cambio en nomenclatura de

microorganismos o pruebas (gestión sencilla de librerías). • Permitir la integración de reglas expertas, eliminación de aislados duplicados

en informes acumulados, edición de informes de antibiograma, etc. • Gestión avanzada de pruebas de susceptibilidad antibiótica.

Genética e inmunología 4.2.4.9.3El sistema debe facilitar la gestión de muestras y seguimiento de los procedimientos utilizados en las pruebas moleculares y citogenéticas así como la elaboración de informes complejos.

4.2.4.10 Seguridad y trazabilidad El sistema debe cumplir la normativa vigente en protección de datos y debe integrarse con la gestión de usuarios de Osakidetza . Debe disponer de herramientas que permitan una gestión ágil de usuarios, grupos y permisos para cualquiera de las áreas y funcionalidades del programa de forma compatible con la política de seguridad de datos de Osakidetza . Debe posibilidad la trazabilidad completa de acciones sobre la base de datos.

4.2.5 Gestión de Estadística, Sistema de Calidad y Gestión Documental

4.2.5.1 Gestión de la Estadística

• Estadísticas configurables por el usuario desde el mismo LIS. • Estadísticas a nivel corporación, UGC y laboratorio/servicio. • Inclusión de URVs y/o costes. • Permite explotar cualquier campo de la base de datos • Permite exportar datos en formatos estándar (csv, txt, xls, etc.) • Análisis de tiempos de respuesta, cargas de trabajo, de actividad horaria.


• Estadísticas específicas de microbiología, informes de resistencias, frecuencia de aislamientos por familias, géneros, especies, serotipos y serogrupos frente a cualquier demográfico de la base de datos.

• Emisión automática y periódica de informes de actividad e incidencias • Posibilidad de crear conceptos estadísticos para agrupar pruebas • Informes configurables por el usuario con envío automático a destinatarios, en

diferentes formatos (Excel, Access, etc.). • Posibilidad de creación de cubos y estadísticas multidimensionales • Posibilidad de conexión con sistemas de Bussines Intelligence (BI).

4.2.5.2 Cuadro de Mando El sistema propuesto deberá incluir un Cuadro de Mando que permita analizar la información en los 5 niveles del modelo jerárquico de la RDBO. En este apartado indicar que la herramienta de Business Intelligence homologada por Osakidetza actualmente, es la solución Oracle Business Intelligence. En caso de ofertarse otras soluciones/herramientas, para el análisis informacional, deberán incluirse en este expediente las licencias requeridas. En cualquier caso, y con independencia de la herramienta a utilizar, los servicios de ETL (Extract, Transform and Load), modelado de la información y construcción del Cuadro de Mando, están incluidos en este expediente.

4.2.5.3 Sistema de calidad y Gestión documental • Soporte para protocolos/documentación de calidad. Control de cambios y

versiones • Soporte para registros de mantenimiento periódico • Gestión de tiempos de respuesta con alarmas configurables • Gestión de incidencias preanalíticas: posibilidad de generar indicadores

automáticos • Gestión de incidencias analíticas: posibilidad de generar indicadores

automáticos • Gestión de incidencias postanalíticas: posibilidad de generar indicadores

automáticos • Indicadores y cuadro de mando desglosables.

4.2.6 Facturación El sistema deberá disponer de la posibilidad de facturación y estadística según precios o URVs a nivel de paciente, médico solicitante u otras agrupaciones de facturación, con envío de esta información a los sistemas corporativos de gestión.


5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN

5.1 Alcance técnico de la solución El Sistema propuesto debe cumplir los siguientes requisitos:

• La solución ofertada debe tener carácter Multicentro, debe ser capaz de operar con múltiples laboratorios de diferentes tipos (análisis clínicos, hematología, microbiología, inmunología y genética) y en diferentes UGC, y dar respuesta a la estructura de 5 niveles de la RDBO.

• El licitador deberá proponer el modelo de arquitectura que considere óptimo, para la correcta operativa de su producto, atendiendo a los requerimientos del mismo y a la capacidad de las comunicaciones de Osakidetza , cuyo detalle se aporta en el Anexo II. El modelo propuesto deberá ser aprobado por Osakidetza , valorándose aquellas soluciones que se adecúen a los estándares de Osakidetza Anexo I, y facultándose a ésta el derecho de modificarlo:

o La aplicación ofertada debe funcionar con las comunicaciones que actualmente están disponibles, detallando el licitador en su propuesta las necesidades de ancho de banda requeridas.

• El licitador deberá detallar en su oferta las necesidades de infraestructura

de soporte al sistema, que deberán garantizar en todo momento la continuidad de servicio. Osakidetza una vez aprobado el dimensionamiento propuesto, será responsable del suministro de la misma.

• La solución propuesta debe gestionar catálogos y diccionarios corporativos únicos más allá del catálogo de pruebas; tanto de los catálogos propios del laboratorio (muestras microrganismos, etc.), como los relativos a estructura organizativa (centros, servicios, secciones, profesionales, estructura de costes, materiales etc.…).

• La solución ofertada debe integrarse con el Directorio Activo de Osakidetza .

o Los datos demográficos del usuario serán comunicados a la aplicación a través de esta integración.

o La solución utilizará el procedimiento de autenticación Single Sign On.

• La solución ofertada debe integrarse con el hardware y software propio de laboratorio , el adjudicatario se responsabilizará del desarrollo, mantenimiento y evolución de los drivers de comunicación con el equipamiento de los laboratorios y las integraciones con otras aplicaciones propias de los laboratorios (soluciones middleware departamentales u otros laboratorios externos), si fuera necesario.

• La solución del LIS en caso de tratarse de cliente pesado, deberá ser fácilmente desplegable.

• La solución del Gestor Global de Peticiones debe estar basada en cliente ligero, solución web, que permita la integración completa del petitorio en la estación clínica de Osakidetza .


• La solución propuesta, deberá integrarse con los SI de Osakidetza , para lo

cual deberá ofertar un frontal de servicios , que permitan la consulta en cualquier momento, del estado de una petición, su contenido, y resultado. El sistema deberá también informar a los SI de Osakidetza de cualquier evento relacionado con la evolución del estado de una petición, haciendo uso de la solución de Gestión de Eventos propia de Osakidetza “Event manager”, y que se detalla en el Anexo I.

• En relación con el puesto cliente , la solución ofertada debe hacer uso de la maqueta de Osakidetza , cuyas características y software de base se detalla en Anexo III .

• El adjudicatario deberá dotar de los mecanismos y herramientas necesarios

para permitir la alta disponibilidad y continuidad de servicio del LIS ofertado.

• El licitador deberá presentar una solución de monitorización de la

disponibilidad del servicio desde el punto de vista del usuario, que deberá integrase con las solución de monitorización de Osakidetza Dicha solución emitirá reportes mensuales sobre la disponibilidad del sistema, que serán enviados de forma automática a la dirección del proyecto.

5.2 Entornos Los entornos a utilizar en el proyecto y para los cuales deberán ser suministradas las licencias suficientes, serán los siguientes:

• Entorno de Desarrollo: o Osakidetza suministrará la infraestructura y el software de base

instalado o Una vez entregado el entorno, la gestión del mismo correrá por cuenta

del adjudicatario, proveyendo Osakidetza únicamente el servicio de backup

• Entorno de Pre-producción/certificación (integració n):

o Osakidetza se hará cargo de la gestión de este entorno, a excepción del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o Su finalidad es la de las pruebas de carga y certificación de arranques o nuevas versiones de productos

• Entorno de Producción:

o Osakidetza se hará cargo de la gestión de este entorno, a excepción del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o En caso de que se conceda acceso al entorno de producción a usuarios técnicos, el acceso se realizará bajo las condiciones previstas en este contrato con respecto al registro de accesos y las circunstancias que puedan justificar ese acceso.

Los entornos de trabajo de Desarrollo y Pre-producción se ubicarán en el CPD de la


Dirección General de Osakidetza , ubicado en Vitoria-Gasteiz. La ubicación del entorno de Producción, quedará sujeta al modelo de arquitectura propuesto por el licitador.

5.3 Plan de Contingencia Se valorará disponer de un sistema de contingencia para eventuales caídas del sistema principal o de parada programada. El licitador expondrá en la oferta el plan de contingencia de servicios que se pondría en marcha en caso de catástrofe. En este plan se detallará clara y precisamente los tiempos de restablecimiento de los sistemas para poder volver a trabajar con normalidad y el grado de funcionamiento del laboratorio durante ese periodo. El plan de contingencia debe estar operativo y simulado, antes de la puesta en marcha de este sistema de información. Como mínimo se deben detallar los siguientes supuestos:

• Parada programada por cambio de versión • Corte físico de una de las comunicaciones entre los hospitales y el alojamiento

del CPD corporativo. • Pérdida de la información del sistema principal de almacenamiento.

En su oferta el licitador incluirá detallar aquellos centros en los que se haya desplegado un plan de contingencia similar al solicitado.


6 LÍNEAS DE TRABAJO Este proyecto incluye principalmente las siguientes líneas de trabajo:

6.1 Consultoría Dado que la estructura y tipología de laboratorios de la RDBO establecida por el Plan Director, se basa en un concepto corporativo, jerárquico y multicéntrico de 5 niveles, será necesario definir, en las primeras fases de este proyecto, un marco de trabajo común, que rija el proceso de implantación del nuevo LIS en los laboratorios de la red. Es por ello, que el licitador deberá incluir en su propuesta la colaboración de consultores expertos que en colaboración con los interlocutores de las 5 UGC que Osakidetza designe, definirán un “modelo de laboratorio tipo ”, que una vez aprobado, se extenderá a las Unidades de Gestión Clínica, en base al Plan de Implantación propuesto, una vez aprobado por Osakidetza . El “modelo de laboratorio tipo” definido, incluirá para su valoración, la solución propuesta para el análisis informacional (Business Itelligence).

6.2 Migración de información Histórica Se incluye dentro del expediente la migración de toda la información histórica existente en el LIS actual (Omega 3000 de Roche), por lo que el licitador detallará en su oferta la estrategia de migración propuesta, teniendo en consideración, que no se prevé mantener el LIS actual, ni siquiera con carácter consultivo, una vez finalizado el presente contrato.

6.3 Integración con los S.I. Corporativos El licitador deberá definir de forma detallada en su oferta el modelo de integración propuesto, que deberá cumplir los estándares detallados en el Anexo I . La solución propuesta deberá, además, tener en consideración las siguientes necesidades:

• Osakidetza dispone de una arquitectura SOA (Service Oriented Architecture) para gobernar y orquestar los servicios disponibles en la organización. El sistema de información ofertado deberá inventariar y hacer públicos los contratos de los servicios que pondrá a disposición de otros sistemas de información.

• Los requisitos de integración del producto ofertado deberán de ser resueltos mediante uno de estos dos métodos: • Escenario 1 - Propagación y consumo de eventos: Event Manager

(desarrollo propio) • Escenario 2 - Consumo de servicios: Oracle SOA Suite (Oracle BPEL

Process Manager, Oracle Service Bus, Oracle Business Rules, ...) • Utilización de mensajería HL7, debiendo aceptar las versiones HL7 2.x (no

XML) y 3, y debiendo adaptarse a las evoluciones que se realicen desde Osakidetza en la adopción de nuevas versiones.

• Utilización del estándar CDA como arquitectura de documentos clínicos electrónicos.


• El modelo definido deberá permitir la implementación de integraciones fuera de estándar en aquellas que Osakidetza considere, y únicamente en aquellas que dicha entidad permita.

• Todas las integraciones entre los aplicativos deben registrar la traza en el registro de accesos exigido por la LOPD e identificar unívocamente a cada usuario que accede.

• La integración con el Gestor Global de Peticiones, en caso de tratarse de un producto diferente al LIS, deberá ser también plena.

o La aplicación debe ser capaz de ser lanzada con llamadas desde otras aplicaciones. Estas llamadas se realizarán mediante parámetros. El licitador deberá explicar en su oferta las posibilidades que ofrece el producto en este ámbito.

El LIS debe integrarse con los siguientes Sistemas de Información:

6.3.1 Catálogos Corporativos Osakidetza está construyendo una plataforma de Catálogos Corporativos, en la que están disponibles actualmente las entidades de Callejero y la BBDD Corporativa de Pacientes, ofertando los servicios de datos necesarios para consulta sobre estas entidades desde aplicaciones externas. Los principales puntos de integración son los siguientes:

• Demográficos del paciente

6.3.2 Gestor Documental Osakidetza está implantando el producto Documentum de EMC, como Gestor Documental. El sistema propuesto deberá almacenar el informe de resultados, en este repositorio.

6.3.3 SAP: Recursos Humanos La gestión de recursos humanos en Osakidetza , está soportada sobre el módulo HR de SAP. Los principales puntos de integración son los siguientes:

• Datos de profesional

6.3.4 e-Osabide. Atención Especializada (HIS hospit alario) La integración con el HIS corporativo de Osakidetza debe de ser completa, de forma que la información administrativa resida en un único lugar y no se produzcan redundancias. Los principales puntos de integración son los siguientes:

• Demográficos del paciente • Estructura organizativa (centros, servicios, secciones, etc) • Ubicación del paciente • Actividad: Episodios, solicitudes y citas

Desarrollo propio J2EE y Oracle. Arquitectura centralizada. CPD de la Organización Central.


6.3.5 Osabide-AP. (Estación clínica Atención Primar ia) Sistema corporativo de Osakidetza para la gestión de la Atención Primaria, incluye gestión administrativa e Historia clínica. La integración del gestor de peticiones, en la estación clínica será plena. El gestor de peticiones, será invocado como una funcionalidad más de la estación (no necesario login), realizándose el paso de parámetros necesario para que la petición sea inteligente (datos clínicos), y se identifique tanto al paciente y su proceso, como al profesional (perfil), que accede al petitorio. Cualquier evento relacionado con el estado de una petición será notificado mediante el Gestor de Eventos de Osakidetza a la estación clínica, quien podrá consultar el resultado/informe de una prueba incluso en tiempo de validación. La estación clínica, recibirá los resultados que aquellas determinaciones que así se consideren como dato estructurado, para su posterior procesamiento. Los principales puntos de integración son los siguientes:

• Actividad: Episodios, solicitudes y citas • Estado de la petición • Recepción y consulta de resultados:

o La integración deberá garantizar la visualización de resultados validados en tiempo real, y la consulta del evolutivo de pruebas.

Desarrollo propio .net y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.6 Osabide-Global. (Estación clínica Atención Es pecializada) Sistema corporativo de Osakidetza para la gestión de la Atención Especializada, exclusivamente Historia clínica. La integración del gestor de peticiones, en la estación clínica será plena. El gestor de peticiones, será utilizado como una funcionalidad más de la estación (no necesario login), realizándose el paso de parámetros necesario para que la petición sea inteligente (datos clínicos), y se identifique tanto al paciente y su proceso, como al profesional (perfil) que accede al petitorio. Cualquier evento relacionado con el estado de una petición será notificado mediante el Gestor de Eventos de Osakidetza a la estación clínica, quien podrá consultar el resultado/informe de una prueba incluso en tiempo de validación. La estación clínica, recibirá los resultados que aquellas determinaciones que así se consideren como dato estructurado, para su posterior procesamiento. Los principales puntos de integración son los siguientes:

• Actividad: Episodios, solicitudes y citas • Estado de la petición • Recepción y consulta de resultados:



Desarrollo propio .net y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.7 CLINIC. Visor de Historia Clínica Osakidetza dispone de un software propio denominado Clinic, que permite una navegación sencilla por la información clínica de un paciente. Los principales puntos de integración son los siguientes:

• Estado de la petición • Recepción y consulta de resultados:


Desarrollo propio en tecnología .NET, con BBDD Oracle. Arquitectura distribuida y albergado en los CPDs Territoriales.

6.3.8 Índice de laboratorio (IPL) Osakidetza dispone de un software propio denominado IPL (Índice de Pruebas de Laboratorio), que constituye un Índice del historial analítico del paciente. Cualquier analítica que se realiza a un paciente, inserta una entrada nueva en el índice, éste dispone además de una referencia del laboratorio que gestiona la petición. Desarrollo propio J2EE y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.9 Versia (Nefrología) Solución propietaria de Baxter, que gestiona los procesos de diálisis peritoneal y hemodiálisis, integrando los mismos en historia Clínica (Osabide Global). Los principales puntos de integración son los siguientes:


o La integración deberá garantizar el envío de resultados en tiempo real de una selección de pruebas a esta aplicación.

J2EE y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.10 Cuidados intensivos Existen actualmente 3 soluciones propietarias para la gestión de intensivos:

• Clinisoft (General Electric):. (Hospital universitario de Donostia) • ICIP de Philips (Hospital universitario Cruces) • Metavision (HUA)

Los principales puntos de integración son los siguientes:




6.3.11 Infección Nosocomial (INOZ) Sistema corporativo de Osakidetza para la gestión de la Infección Nosocomial. Los principales puntos de integración son los siguientes:



ASp.net y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.12 TAO. Sistemas de Anticoagulación Existen 2 soluciones de anticoagulación actualmente:

• Roche • Izasa

Los principales puntos de integración son los siguientes:

• Estado de la petición • Actividad: Petición electrónica desde el sistema de información de

anticoagulantes orales • Recepción y consulta de resultados:


6.3.13 Net bank. Banco de Sangre Solución propietaria de Izasa para la gestión del banco de sangre. Los principales puntos de integración son los siguientes:


o La integración deberá garantizar el envío y recepción en tiempo real de datos y resultados de una selección de pruebas a esta aplicación.

6.3.14 SSDwlab 6. Cribado de Síndrome de Down Solución propietaria de SSDwlab Software para el cribado de síndrome de down

• Estado de la petición • Actividad: Solicitud cribado • Envío, recepción y consulta de resultados.

6.3.15 Programa de Cribado de Cáncer Colorrectal Sistema corporativo de Osakidetza para la gestión del Programa.

• Estado de la petición • Actividad: Solicitud cribado • Envío, recepción y consulta de resultados.


ASP.net y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.16 Sistema Económico-Financiero (ERP-SAP) (Pdte . Unzaga) Conexión con SAP con el sistema de información económico financiero, y específicamente con:

• Módulo de logística de SAP y otros sistemas logísticos de almacenes periféricos (soluciones tipo Rotastock o similares)

• Módulo de controlling de SAP para la gestión de la información económica del laboratorio así como su imputación de costes

• Módulo de facturación a terceros de SAP • Módulo de facturación a proveedores y control de las pruebas realizadas en los

distintos equipos de laboratorio • Modulo de catálogo corporativo de pruebas y materiales de SAP

6.3.17 Salud Pública (SIM). Dpto. Salud La solución propuesta deberá integrarse también con el sistema de Vigilancia microbiológica del Dpto. Salud.



6.3.18 Gasometrías La solución propuesta deberá integrarse también con el sistema de Gestión de Gasometrías.

• Creación de solicitudes • Recepción y consulta de resultados:


El adjudicatario se compromete a integrar el nuevo sistema de información con nuevas aplicaciones corporativas que pudieran surgir, a lo largo del contrato, y a modificar y mantener las integraciones existentes si hubiera cambios en los procedimientos y políticas corporativos.

6.4 Formación y Coaching

6.4.1 Formación La planificación, gestión y ejecución de la formación, correrá a cargo del proveedor, que formará directamente a los siguientes tipos de usuarios:

• Formación a referentes/administradores : el adjudicatario formará a los referentes dentro del personal del Osakidetza que indique la dirección del


proyecto. La formación deberá ser la suficiente para que los referentes puedan realizar la parametrización del sistema.

• Formación a usuarios : orientada a los usuarios finales de la aplicación y enfocada al uso de los distintos módulos y funcionalidades que componen la solución. Esta formación se realizará antes de la puesta en marcha de la aplicación y regularmente durante la duración del contrato. Adicionalmente, el proveedor formará y participará en las campañas informativas tras cambios importantes en el sistema de información.

• Formación técnica : orientada al departamento de informática y enfocada a la

administración de la aplicación y a las herramientas de desarrollo y programación inherentes, si es que las hubiera. Además, se impartirá formación sobre el modelo de datos, destinada a poder explotar la información mediante herramientas de Business Intelligence. Esta formación se realizará antes de la puesta en marcha de la aplicación y regularmente durante la duración del contrato.

El personal del adjudicatario será el encargado de impartir la formación detallada, y de conocer tanto la parametrización como los circuitos de trabajo del Osakidetza . Tras las sesiones de formación el adjudicatario entregará los informes de la efectividad de las formaciones (encuestas de satisfacción, hojas de asistencia, test de autoevaluación, evaluación del formador, etc.). La documentación de los cursos de formación, así como la documentación y guías de uso de las diferentes funcionalidades que ofrezca la aplicación ofertada, es tarea del proveedor que deberá cumplir puntualmente antes de que cualquier formación tenga lugar o cualquier funcionalidad entre en producción. El licitador entregará en la oferta una planificación detallada que explique el alcance de los contenidos de formación y en el que se deberá indicar el número de horas previstas de formación para todos los usuarios y para el personal de informática. Este número de horas es orientativo y en ningún caso será el límite de horas a impartir si la formación no ha llegado al nivel adecuado para la adopción de sistema. Formación online: se creará el material para disponer de toda la formación en formato online en la plataforma de formación corporativa de Osakidetza basada en la herramienta Moodle.

6.4.2 Coaching El licitador prestará un soporte inicial de coaching in-situ 24x7 por un periodo mínimo de 4 semanas después del arranque de la aplicación en cada centro . Este es un punto clave de la gestión del cambio, de acompañamiento al usuario en el cambio. El licitador detallará en su oferta cuánto personal dedicará a esta actividad. Los cambios de versión mayor también requerirán de un equipo de coaching, las dimensiones del cual serán acordadas por el proveedor y Osakidetza en cada ocasión. El servicio prestado debe ser el suficiente para que la adopción sea correcta. Osakidetza se reserva el derecho a solicitar al proveedor un incremento en el número


de personas que presten el servicio en caso de que fuera necesario. Durante la adopción del sistema, en los respectivos procesos de coaching se harán informes diarios del avance y las áreas problemáticas para la dirección del proyecto.

6.5 Implantación La implantaciones en cada UGC, en base al “modelo de laboratorio tipo” definido en la fase de consultoría, requerirá el desplazamiento on-site del equipo de implantación, que deberá permanecer en el centro, en la dimensión que el licitador considere adecuada y que deberá detallar en su propuesta, al menos durante 4 semanas desde el arranque del nuevo SI. El licitador deberá garantizar en todo momento durante el proyecto de implantación, la convivencia entre el actual LIS, y la implantación de la nueva solución. El proveedor deberá designar un coordinador de soporte cuya dedicación y disponibilidad se detallará en la oferta. Dentro de la garantía del proyecto se incluyen las tareas de soporte, resolución de incidencias y atención a mejoras de producto, que se produjeran durante la implantación de la solución en Osakidetza . Las líneas de trabajo que se incluyen son las siguientes:

6.5.1 Atención a consultas y Soporte El adjudicatario ofrecerá el servicio de soporte de todas las aplicaciones e integraciones relacionadas en este expediente desde el arranque del sistema de información hasta el final del contrato. El soporte tendrá varios niveles (1er nivel de soporte y 2do nivel de soporte). Este soporte será del tipo 24x7, si bien fuera del horario laboral (07:30 a 18:00), solo se atenderán incidencias urgentes y tendrá las siguientes características:

• Soporte de 1º Nivel: El adjudicatario habilitará un servicio de soporte telefónico , para la:

o Resolución de consultas a nivel usuario sobre el funcionamiento de la aplicación

o Resolución de incidencias que podrían derivar en el escalado al 2º nivel de soporte

• Soporte de 2º Nivel: El adjudicatario habilitará un equipo de soporte local

ubicado en la Comunidad autónoma de Euskadi con capacidad para desplazarse a cualquiera de los laboratorios de la red, en caso necesario, para la:

o Resolución de incidencias derivadas del 1º nivel de soporte: La empresa adjudicataria se ocupará de la resolución de errores/problemas conocidos de la aplicación con el ANS acordado durante la vigencia del contrato. Estos acuerdos de nivel de servicios (ANS) podrán ser renegociados a petición de Osakidetza anualmente.

o Gestión de las diferentes alarmas automáticas de los sistemas de monitorización de servicios.


o Registro, seguimiento y resolución de las peticiones de mejora solicitadas, y que se gestionarán mediante el Sistema de Gestión de la Demanda corporativo de Osakidetza.

o Soporte .al usuario a la hora de configurar, hacer cambios organizativos, consultas, formulas o reglas especiales etc..

Ambos equipos de soporte harán uso del Sistema de Gestión de Incidencias corporativo de Osakidetza . Las herramientas de gestión a utilizar en este contrato, son las siguientes:

• La herramienta utilizada por el 1º nivel de CAU de Osakidetza , para registro y gestión de las consultas e incidencias técnicas y funcionales de los aplicativos, es el producto HP-Service Manager.

• La herramienta utilizada en Osakidetza para la Gestión de la Demanda, es el producto HP-PPM (Project and Portfolio Management).

El acceso a este servicio de Atención a Consultas y Soporte, podrá realizarse por los siguientes canales:

• Vía derivación del CAU de 1º nivel de Osakidetza (en adelante CAU Osakidetza ), previo registro en HP-Service Manager

• Vía HP-PPM: Registrada en PPM por los servicios de informática de la red. • Vía teléfono: Usuarios expertos y servicios de informática de la red, podrán

realizar consultas telefónicas para la resolución de dudas respecto al funcionamiento de las aplicaciones objeto del contrato

En caso de requerirse la integración de las herramientas actuales y futuras de Osakidetza , con la herramienta propia del proveedor, los costes derivados de esta integración correrán a cargo del adjudicatario.

6.5.2 Mantenimiento evolutivo El licitador determinará el tratamiento a dar a las necesidades de mantenimiento evolutivo que Osakidetza solicite durante el período de implantación de la solución en sus laboratorios, y establecerá un marco de garantía de cobertura de las mismas.

• La toma de requerimientos y análisis funcional de las diferentes peticiones serán realizadas por un consultor experto del adjudicatario en la solución.

• Dentro del mantenimiento evolutivo de la aplicación el adjudicatario se compromete mantener su producto actualizado a la última versión.

• El adjudicatario deberá describir en su oferta, su política de actualizaciones. • La empresa adjudicataria se compromete a aplicar las mejores prácticas en la

puesta en producción de nuevas versiones, parches o nuevos desarrollos de la aplicación, entre ellas la aplicación de pruebas de carga y stress, la validación funcional y técnica del producto y la correcta gestión del cambio para cada una de ellas, así como la correcta documentación de todos estos procesos que será presentada puntualmente a la dirección del proyecto como condición previa a la validación de dicho cambio de versión. Se valorará el uso de procedimientos basados en ITIL las operaciones del equipo del proyecto.

6.5.2.1 Evolución de la plataforma de interoperabi lidad de Osakidetza Dentro del marco de este contrato, se incluye la adaptación del producto suministrado a la evolución de la plataforma de interoperabilidad de Osakidetza : Servicios web


y eventos. Esta evolución de la plataforma de interoperabilidad se realiza una vez al año , siendo notificados los cambios que se incorporan en la misma, con 6 meses de antelación.

6.6 Monitorización Durante la vigencia del contrato, el adjudicatario será el encargado de llevar a cabo las acciones de paradas y cambios en los sistemas de información conforme a las recomendaciones de ITIL e ISO-20.000 y siguiendo los procedimientos de paradas y cambios de los servicios definidos por Osakidetza . Dichas paradas y cambios se realizarán en horario de baja actividad de los centros (tardes, noches y/o fines de semana a convenir con las personas designadas por Osakidetza ), previa aprobación por parte de Osakidetza . El adjudicatario será el encargado de la monitorización del sistema de información

• El licitador incluirá en la propuesta herramientas de monitorización del sistema de información y acceso control remoto, tanto de disponibilidad como de rendimiento de los diferentes servicios desde el punto de vista del usuario final de cada UGC. La oferta debe incluir también la descripción de los servicios que serán monitorizados.

• La dirección del proyecto y el área de Operación de Osakidetza , dispondrán de herramientas de monitorización del sistema parametrizadas por el adjudicatario para que se disponga siempre de una imagen del estado del sistema de información.

• Dicha solución deberá presentar reportes mensuales de los indicadores acordados por Osakidetza y el adjudicatario desde el primer día de funcionamiento de la aplicación propuesta.

• El sistema de monitorización de servicios estará integrado con el sistema corporativo de Osakidetza , de modo que los eventos acordados con la dirección del proyecto sean notificados automáticamente al equipo de Operación.


7 PRODUCTOS A OBTENER El resultado final consistirá en la implantación del Sistema Informático que dará soporte a la gestión de los laboratorios de la RDB, junto con la documentación del Sistema. Los productos a obtener serán, como mínimo, los siguientes:

• Planificación del proyecto. • Especificaciones hardware y software necesarias para la implantación del

producto. • Documentación Técnica del producto. • Informes de seguimiento del proyecto. • Manual de Usuario. • Manual de Explotación. • Manual de Instalación.


8 PLANIFICACIÓN DEL PROYECTO Es necesario que los licitadores presenten los cronogramas en los que se deben especificar los contenidos o tareas y su distribución en el tiempo. Estos cronogramas incluirán, asimismo, los diferentes hitos a cubrir y los entregables.


9 EQUIPO DE TRABAJO Las empresas interesadas en la adjudicación del contrato presentarán en su propuesta la descripción de su equipo de trabajo, especificando los recursos humanos que destinarán al proyecto, sus perfiles profesionales, y las dedicaciones por cada una de sus categorías. Asimismo, se indicarán los precios unitarios/jornada por cada categoría profesional ofertada. Existirá un Director del Proyecto por parte de la empresa adjudicataria, representante de la misma e interlocutor y responsable de los trabajos ante la Dirección del Proyecto de Osakidetza . Osakidetza aportará también la figura de un Director de Proyecto, con la función de coordinar la participación de los recursos humanos del mismo que sean necesarios en cada momento. Osakidetza controlará, mediante la figura de su Director de Proyecto, el cumplimiento de los términos acordados, así como la calidad y adecuación del servicio objeto de este contrato, quedando ambos sujetos a lo que marca la Ley de Contratos de las Administraciones Públicas (texto refundido), en cuanto hace referencia a completar los términos y calidad de los productos desarrollados. Asimismo, deberán identificarse los responsables únicos en cuantas actividades que, por su importancia, se considere oportuno: análisis, desarrollo, control de calidad,. y sus funciones y relaciones con el resto del equipo y Osakidetza . Osakidetza , por su parte, deberá asegurar la colaboración de Técnicos, responsables de la aplicación en las distintas fases del proyecto y designará un líder clínico con visión/conocimiento de los laboratorios , que coordine las necesidades de éstos y a través del cual se canalicen cuantas consultas sean necesarias para el conocimiento detallado del entorno del laboratorio y sus disciplinas.


10 CONTENIDO DE LAS OFERTAS Con carácter obligatorio, las propuestas deberán presentarse en papel y en soporte digital, compatible con las herramientas instaladas en Osakidetza (MSWord 2010, Adobe Acrobat Reader 10). Las ofertas se presentarán en dos modalidades:

• Oferta resumen ejecutivo , donde se recogerán los aspectos fundamentales de la oferta y sus elementos de valor añadido esenciales, conteniendo la información más relevante para la evaluación de la oferta por Osakidetza según los criterios de adjudicación publicados. Este resumen ejecutivo no podrá superar el número de 25 páginas (25 páginas A4).

• Oferta completa, donde se podrá explicar y detallar los diferentes aspectos de

la oferta, siempre que supongan una información directamente relacionada con los servicios propuestos en el pliego. La oferta completa no podrá superar el número de 300 páginas (300 páginas A4).

Ambas modalidades de ofertas se deberán ajustar al siguiente contenido y formato: 1. Introducción

Se detalla el contexto en el que se realiza la oferta y las capacidades globales del licitador para entender y satisfacer los requerimientos del contrato. En este apartado se expondrá la estrategia que la empresa ofertante considera apropiada para alcanzar los objetivos del proyecto.

2. Descripción de la solución propuesta

Descripción detallada de las herramientas/productos ofertados que a priori se consideran apropiados para la realización del proyecto, justificando su adecuación a los objetivos del mismo y realizando una descripción exhaustiva de la funcionalidad que incorporan. Se aportará también detalle exhaustivo tanto del tipo de licenciamiento y volumen de licencias ofertadas, como de los costes de mantenimiento (una vez finalizado el contrato) y las modalidades del mismo.

3. Arquitectura tecnológica y modelo de integración Descripción detallada de la arquitectura propuesta, modelo y elementos que la componen, con objeto de garantizar la escalabilidad y continuidad de servicio. Se valorarán positivamente aquellas soluciones alineadas con los estándares de Osakidetza , detallados en el Anexo I. Se deberá detallar también, de forma exhaustiva la infraestructura requerida para la arquitectura propuesta, describiendo de forma detallada las características de esta infraestructura.


Se incluirá también detalle exhaustivo de la estrategia y modelo de integración del producto ofertado; conexiones con autoanalizadores y estándares para la integración con los SI corporativos.

4. Plan de Trabajo

Descripción específica para cada una de los servicios a prestar: descripción del contenido, estrategia y operativa de trabajo y relación entre tareas, destacando especialmente las tareas relacionadas con el despliegue de la solución, migración de datos y formación y coaching. Se incluirá la planificación en el tiempo de cada línea de trabajo, hitos y productos resultantes, que permitirán la certificación del proyecto. Se incluirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.

5. Organización y Equipo de Trabajo

3.1. Modelo organizativo: Modelo global del proyecto y del equipo humano, distribución de funciones y responsabilidades, tareas, coordinación, dedicación al proyecto, flujos de comunicación, etc.

3.2. Equipo de Trabajo Dimensión, configuración, perfiles y volumen de horas/perfil, del equipo de trabajo propuesto.


11 PROPIEDAD DE LOS PRODUCTOS Todos los productos descritos en el punto 6 de este documento que entregue el adjudicatario quedarán en propiedad exclusiva de Osakidetza , así como su propiedad intelectual, quedando el adjudicatario obligado a renunciar a cualquier derecho sobre estos conceptos.


12 CONFIDENCIALIDAD En consideración al tipo de información procesada, el adjudicatario está obligado a mantener la más absoluta confidencialidad sobre todos aquellos datos y documentos a que tengan acceso con motivo de esta adjudicación. A ellos accederán, exclusivamente, las personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a la misma. Todas ellas serán advertidas del carácter confidencial y reservado de la información a la que tendrán acceso. Todos los ficheros que se pongan a disposición del adjudicatario para la ejecución del contrato son propiedad de Osakidetza y están registrados y sometidos a la salvaguarda que establece la legislación vigente, en especial la relativa a la protección de datos personales. Toda cesión a terceros será perseguida en los tribunales. Osakidetza se reserva el derecho de establecer cualquier tipo de marcaje de los ficheros que se dejarán al adjudicatario, de manera que sus características puedan constituirse como prueba que posibilite localizar el origen y los responsables de las eventuales cesiones. Bajo ningún caso ni circunstancia, el adjudicatario podrá suministrar a terceros, ni utilizar para sí ni para otros, datos facilitados por Osakidetza , para fines distintos a los contemplados en el objeto del presente contrato. El adjudicatario estará obligado a poner en conocimiento de Osakidetza , inmediatamente después de ser detectada, cualquier sospecha de eventuales errores que se puedan producir en el sistema de seguridad de la información. El adjudicatario faculta a Osakidetza para que, al terminar el proyecto, pueda responsabilizarlo y/o repercutirle los costes derivados de posibles reclamaciones ocasionadas por negligencia y/o falta de confidencialidad del mismo.


13 PRESUPUESTO, PLAZOS Y PENALIZACIONES

13.1 Presupuesto El presupuesto máximo asignado y los plazos máximos de ejecución para este proyecto son los siguientes:

• Presupuesto máximo asignado : 2.400.000€(SIN IVA) 2.904.000€ (con 21% IVA)

La valoración económica esta expresada en Euros, es máxima e incluye la totalidad de los conceptos devengables. Se deberán detallar claramente los siguientes aspectos:

• Importe del licenciamiento del producto/s ofertados : Se deberá detallar además, el coste del mantenimiento anual de las licencias ofertadas.

• Importe de la implantación del proyecto: Se deberá detallar el importe por cada una de las tareas que conforman el proyecto de implantación.

La suma total de los conceptos anteriormente señalados no podrá exceder del precio de licitación total. La valoración económica deberá ir obligatoriamente en el sobre B : "Oferta económica y criterios evaluables de forma automática mediante la aplicación de fórmulas”.

13.2 Plazos El plazo de ejecución será de 3 años desde la fecha de formalización del contrato.

13.3 Forma de pago El pago se realizará de la siguiente forma: Se realizará de la siguiente forma:

� Las licencias del producto se facturarán de forma independiente

� Para el resto de las tareas del proyecto, se presentará una factura a la finalización de cada una de las líneas de trabajo detalladas en el capítulo 6 de este Pliego, y tras el VºBº del responsable de Osakidetza .


14 CRITERIOS DE ADJUDICACIÓN Para la elección de los criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el Pliego de Bases Técnicas que se acompaña a este expediente, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para el suministro objeto de este expediente. De acuerdo con lo antedicho, los criterios que servirán de base para la adjudicación del presente contrato serán los siguientes:

JUICIOS DE VALOR: ................................. ..................................................... 60

• Descripción del contenido de la solución: Descripción detallada de las funcionalidades del producto ofertado................................................... 45

� Estructura básica y Configuración del Sistema ...................................... 4

� Gestión de Peticiones y Visor de Resultados ....................................... 15

� Gestión de la Extracción ........................................................................ 2

� Gestión de Laboratorio ........................................................................ 20

� Gestión de Estadística, Sistema de calidad y Gestión documental ............................................................................................ 4

• Arquitectura tecnológica y modelo de integración: Descripción detallada de la arquitectura propuesta , componentes y garantía de escalabilidad y continuidad de servicio .............................................................. 7

• Coherencia y contenido del Plan de Trabajo: Plan de trabajo contenido e hitos: Estrategia de Implantación, migración, formación y soporte .............................................................................................................. 8

Umbral mínimo de la suma de los 3 criterios anterio res: 35 puntos . Se valorarán con carácter previo los criterios de adjudicación en los que se haya establecido un umbral mínimo de puntuación. Las ofertas deberán superar ese umbral para continuar en el proceso selectivo y ser valoradas conforme al resto de los criterios de adjudicación.

FÓRMULA: .......................................... ............................................................ 40

• Precio de la oferta .............................. ................................................ 30

Atendiendo a la tabla que se presenta a continuación, la valoración del precio se realizará de la siguiente forma: � Se establecen 7 tramos para determinar la puntuación obtenida, según el

porcentaje de baja con respecto al importe de licitación, que se calculará de la siguiente forma:


Porcentaje de baja = 1 −��

�� ó��

� En cada uno de los tramos, el valor obtenido será el resultante de la

interpolación del porcentaje de la Baja entre los valores de dicho tramo.

Interpolación %baja = puntostramo∗�%� � �� %�í"�� "�

�%��"��#$%�� " %�í"�� "�

� Los puntos valorados para cada tramo se sumarán hasta alcanzar el porcentaje

de baja presentada. � La oferta cuyo importe sea igual al importe de licitación se valor ará con 0

puntos .

Descripción tramo puntos Puntos Porcentaje de baja de hasta un 5% con respecto al importe de licitación. 6 Porcentaje de baja superior al 5% e igual o inferior al 7,5% con respecto del importe de licitación. 6

Porcentaje de baja superior al 7,5% e igual o inferior al 10 % con respecto del importe de licitación. 6

Porcentaje de baja superior al 10% e igual o inferior al 15% con respecto del importe de licitación. 4



Porcentaje de baja superior al 25%. Este último tramo se valorará de forma que se darán 1 punto a la oferta más económica, interpolándose las restantes ofertas que se sitúen en este tramo de manera proporcional.

1

Total Puntos 30

• Precio del mantenimiento anual .................... ..................................... 10 El precio menor del mantenimiento anual recibirá 10 puntos y el resto proporcionalmente aplicando la siguiente fórmula:

Precio Mínimo

---------------------------------- x 10 Precio Ofertado

El mantenimiento de licencias de los productos ofertados, se contratará una vez finalizado este expediente. La evolución de versiones de los productos ofertados durante la vigencia del contrato, se considera incluida en el presente expediente.

Comité de expertos

� ANTONIO LÓPEZ URRUTIA (Cruces) � Mª.ARANZAZU ARRIETA GUTIERREZ (Cruces) � CARMEN DE NO LENGARAN (HUA) � DIEGO VICENTE ANZA (Donostia) � EDUARDO AMOROTO DEL RIO (Galdakao) � Mª JESUS GARCIA BARCINA (Basurto) � ROSA ORIZA BERNAL (Dirección General � SUSANA IGLESIAS TAMAYO (Dirección General)


15 CONSULTAS AL PLIEGO Durante el periodo de licitación y ante cualquier necesidad de aclaración sobre cuestiones referidas a las especificaciones recogidas en el presente Pliego de Bases Técnicas, los licitadores deberán remitir por correo electrónico las preguntas e información que consideren necesarias para elaborar la Propuesta Técnica. Los licitadores podrán dirigir sus consultas o aclaraciones a la dirección de correo electrónico de la Subdirección de Informática y Sistemas de Información:

[email protected] Los licitadores deberán identificar, a un único responsable de la oferta, que será durante al periodo de licitación, el interlocutor único con Osakidetza para cualquier tipo de consulta o aclaración sobre los términos expuestos en el presente Pliego, no admitiéndose ninguna consulta o aclaración de persona distinta a la señalada. Así mismo los licitadores para formular sus consultas o aclaraciones deberán cumplimentar la siguiente información:

• Nº. Pregunta • Capítulo/Apartado • Página • Párrafo • Descripción de la Consulta


16 ANEXO I: DOCUMENTO DE ARQUITECTURA Y TECNOLOGÍA La solución ofertada deberá estar alineada tecnológicamente con las directrices que se indican a continuación.

16.1 Arquitectura y tecnología El proveedor definirá la arquitectura de la solución y especificará los componentes lógicos y físicos de la misma, así como el diagrama de capas lógicas y su distribución en la infraestructura, los productos software y/o hardware requeridos, protocolos utilizados, necesidades de comunicación (apertura de puertos, balanceadores, …), siguiendo las directrices de Osakidetza que se indican a continuación; será validada por las áreas de Arquitectura e Infraestructuras, Operación y Comunicaciones de Osakidetza . El diseño de la arquitectura será escalable y garantizará el cumplimiento de la normativa de seguridad y de planes de contingencia de Osakidetza , garantizando el óptimo rendimiento de la solución ofertada sobre dicha arquitectura. El diseño de arquitectura se realizará para los entornos de:

• Preproducción (debe ser igual que el entorno de producción) • Producción

La dotación de la infraestructura necesaria para la implantación de la solución correrá a cargo de Osakidetza .

16.1.1 Consideraciones Tecnológicas La solución (producto/aplicación/desarrollo) será una solución Web (sin plug-in’s), con arquitectura de n-capas preferentemente 3 capas: presentación, negocio y persistencia, compatible con tecnología de virtualización y almacenamiento SAN y NAS. El albergue de las capas de negocio y persistencia será centralizado y la capa de presentación distribuida. Plataforma de virtualización VMWare vSphere 5.5 Almacenamiento SAN: EMC VPLEX y NAS. Hitachi HUS Plataformas de desarrollo de la solución:

• .NET sobre Windows 2008R2 • J2EE sobre Red Hat Enterprise Linux 6.6

La relación de tecnologías sobre las que se implantarán y ejecutarán las diversas capas de la solución (versiones mínimas), son:

� Capa de Presentación - Puesto cliente :

Cliente ligero (HTML5)

Características del puesto:

o Windows 7 Enterprise N SP1 32 bits


o Internet Explorer 8.0 (Ver *)

o Office 2010 Standard (Ver **)

o Oracle Client 11gR2

o Java 1.6.0_23

o Framework 3.5 y 4.0

(*) En cuanto al navegador, se debe evitar el uso de Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador.

(**) Al respecto de Office 2010, para el desarrollo de aplicaciones corporativas, no esta permitido el uso, dependencia o interrelación con Access.

� Capa de Negocio - Servidores Web y de Aplicaciones:

o Aplicaciones J2EE / Weblogic 11g

Aplicaciones J2EE que requieran de funcionalidades específicas de Oracle Weblogic Server 11g, que hagan uso de EJBs o colas JMS, o que se apoyen en una base de datos Oracle RAC.

Se deberá certificar la compatibilidad de la aplicación con la siguiente matriz, correspondiente a los distintos productos y componentes empleados en los servidores sobre los que se desplegará la aplicación:

Componente Versión

Sistema Operativo Red Hat Enterprise Linux 6.6 (64bits)

JVM JRockit R28.3.4

Oracle Weblogic Server

10.3.6

Tipo DataSource Oracle GridLink (si la BD es Oracle RAC)

Driver Acceso a BBDD Oracle’s Driver Thin para Oracle Databases 9.x, 10.x, 11.x

o Aplicaciones J2EE / Tomcat

Aplicaciones J2EE que no requieran despliegue sobre OWLS (Oracle Weblogic Server) 11g.

Se deberá certificar la compatibilidad de la aplicación con la siguiente matriz, correspondiente a los distintos productos y componentes empleados en los servidores sobre los que se desplegará la aplicación:

Componente Versión

Sistema Operativo Red Hat Enterprise Linux 6.6 (64 bits)

JVM JRockit R28.3.4


Tomcat 7.0.56

Tipo DataSource Se requiere el uso de un Pool de Conexiones definido por la aplicación *

Driver Acceso a BBDD Ojdbc6.jar

* Ver apartado de Conectores

o Frontales Web para aplicaciones J2EE El acceso a una aplicación desplegada en instancias de OWLS se realizará siempre a través de uno o varios servidores Apache que actúen como frontal web. Estos servidores contarán con los siguientes componentes y versiones:

Componente Versión

Sistema Operativo

Red Hat Enterprise Linux 6.6 (64bits)

Servidor Web Apache Webserver 2.2.26 (OWLS11g)

Apache Webserver 2.2.29 (Tomcat)

Plugin de Salto

(Para OWLS11g)

Apache HTTP Server Plugin 1.1 (WLSPLUGINS_11.1.1.7.0_LINUX.X64_RELEASE)

Plugin de Salto

(Para Tomcat)

Apache Tomcat Connector (mod_jk 1.2.40)

o Aplicaciones .NET / Internet Information Server Aplicaciones .NET que requieran despliegue como aplicación web sobre servidores Internet Information Server, deberán certificar compatibilidad con la siguiente matriz:

Componente Versión

Sistema Operativo Windows 2008 R2 Enterprise (64bits)

.NET Framework 4.0

Internet Information Server

7.5.7600.16385

Sharepoint Server 2010 Enterprise

Acceso a BBDD Oracle ó SQL Server

- Cliente de Oracle “64-bit ODAC 11.2 Release 4 (11.2.0.3.0)”

- ADO.NET / LINQ


� Capa de Persistencia - Servidor de BD y conectores al Servidor de BD:

o Servidor BD

Servidor BD Alta disponibilidad

Oracle 11.2.0.3

� con parada: Stanby

� sin parada: RAC 11.2.0.3

Microsoft SQL Server Enterprise 2008

� S.O.: Cluster Windows 2008R2

� BD: Mirroring

o Conectores:

Servidor de

Aplicaciones Base de Datos Características

J2EE / OWLS 11g

Oracle Database (Single Instance)

Se deben utilizar DataSources de tipo GridLink en caso de Oracle RAC. En cualquier caso siempre se debe utilizar el driver "Oracle’s Driver Thin para Oracle Databases 9.x, 10.x, 11.x"

Oracle Database (RAC)

J2EE / Tomcat Oracle Database (Single Instance o RAC))

La aplicación deberá implementar un sistema de persistencia que acceda a la capa de datos mediante un Pool de Conexiones (Hibernate, JPA/EclipseLink, JPA/TopLink, etc.) utilizando el driver "ojdbc6.jar "

.NET / IIS, WCF

Oracle Database (Single Instance o RAC)

Cliente de Oracle “64-bit ODAC 11.2 Release 4 (11.2.0.3.0)”

Microsoft SQL Server 2008

ADO.NET

NOTA: A medio plazo Osakidetza evolucionará:

o S.O. Windows Server 2008 R2 a Windows Server 2012 R2 o Servidor de Aplicaciones Weblogic 11g a Oracle Weblogic Server 12c o SGBD Oracle 11g a Oracle 12c y MS SQL Server 2008 a SQL Server 2012

La solución (producto/aplicación/desarrollo) deberá ser compatible con la relación de versiones indicadas en el párrafo anterior (las que apliquen).

16.1.2 Dispositivos de entrada/salida La solución deberá ser capaz de interactuar con diversos dispositivos de entrada y salida de diversos fabricantes; siendo dichos dispositivos: pantallas táctiles,


impresoras térmicas, monitores,… Por tanto el interface con los mismos será en base a estándares del mercado. Así mismo la solución deberá adaptarse a la resolución de las diversas pantallas.

16.1.3 Seguridad, acceso, autenticación y autorizac ión El tratamiento de los datos cumplirá lo establecido por la legislación vigente en materia de seguridad y protección de datos. En el ámbito intranet se permitirá el acceso mediante los transportes RMI, JMS, HTTP y HTTPS. El proveedor de servicios de certificación de Osakidetza es Izenpe. Los sistemas de autenticación validos serán:

• Autenticación basada en Directorio Activo (Microsoft Active Directory) corporativo, que permite identificar un empleado de Osakidetza mediante usuario/contraseña o la tarjeta profesional.

• Token de Kerberos , que habrá sido emitido por el Directorio Activo corporativo.

• Autenticación basada en infraestructura de certificación digital (PKI) . Esta autenticación permite la identificación de personas (certificados personales) o de sistemas de información (certificados de servidor)

• Certificados X.509 de servidor , que permitirán identificar sistemas (máquinas) y establecer confianza entre ellas.

• Certificados X.509 de cliente , que permitirán identificar individuos (personas) • Para los servicios web, el estándar WS-Security permitirá aplicar políticas de

autenticación. • El bus de servicios sólo se utilizará para la autenticación basada en

certificados X.509 de servidor. El sistema de autorización se implementará por medio de la definición de roles de usuario en base a los cuales se gestionarán los permisos y acciones sobre los distintos procesos por los que estará compuesta la solución. De modo que cada usuario en función del rol que tenga asignado podrá acceder a una serie de funcionalidades, así como a los datos relativos a su organización de servicio, centro de trabajo, servicio/área de atención. Se crearán grupos de autorización del Directorio Activo (DA). Por cada perfil que tenga la aplicación (médico, enfermera, administrativo, administrador de la aplicación,…) se creará un grupo de autorización en el DA. Se mapeará el perfil al grupo.

16.1.4 Monitorización La solución incluirá un apartado de monitorización en la que se detallen los elementos a monitorizar para asegurar un correcto funcionamiento del sistema, proporcionando los scripts necesarios para que la operativa del sistema pueda ser realizada por un operador, así como los scripts de arranque y parada. La monitorización se puede realizar a través de:

• SCOM mediante Management Pack para sistemas Microsoft • Instalación de agente de CA Wily Introscope para tecnología Web • Instalación de agente de Pandora FMS para sistemas Linux, Unix • Enterprise Manager Cloud Control para SGBD Oracle


• Mensajes SNMP • Activación de log’s que se enviarán a un servidor virtual dedicado

16.1.5 Backup/Restore Identificación de los elementos sobre los que hacer backup, frecuencia y política de persistencia de los mismos, así como restricciones para la realización de estos backups. Así mismo se deberá indicar el procedimiento de recuperación de la solución, que será validado por Osakidetza . Nota: el hardware y herramientas de backup son provistas por Osakidetza

16.2 Interoperabilidad Los requisitos de integración de diversos sistemas de información de Osakidetza se realizaran de acuerdo a una arquitectura orientada a servicios (SOA) sobre la plataforma Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus (OSB), Oracle Business Rules, ...). Dicha arquitectura proporciona una forma bien definida de exposición e invocación de Servicios Web , lo cual facilita la interacción entre diferentes sistemas propios o de terceros. Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a Eventos ; es un diseño a medida que gestiona un conjunto de sistemas que publican eventos y un conjunto de aplicaciones que se suscriben a determinados eventos. Dicha solución se denomina Gestor de Eventos-Event Manager y es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los elementos recibidos.

Relación de estándares de comunicación soportados:

• Protocolos a nivel de mensaje: o SOAP 1.1 y SOAP 1.2, o WSDL 1.1 y WSDL 1.2 Binding, o SOAP con Attachments

• Protocolos de seguridad a nivel de mensaje: o WS-Security 1.0/1.1, o WS-SecurityPolicy, o WS-Policy, o WSPolicyAttachment, o WS-Security: Username Token Profile 1.0/1.1, o WS-Security: X.509 Token Profile 1.0/1.1, o WSSecurity: SAML Token Profile 1.0/1.1, o WS-Security: KerberosToken Profile 1.1, o WS-Reliable Messaging 1.0, o WS-Addressing, o WS-I Basic Profile 1.1

• Protocolos a nivel de transporte: o HTTP 1.0, HTTP 1.1, o TLS, SSL


o Interoperabilidad con registros UDDI v3-compliant o Sistemas middleware basados en JMS/MQ.

16.2.1 Servicios Web Los Servicios Web se implementarán de acuerdo con las especificaciones WSDL v1.1, SOAP v1.1, v1.2, UDDI v2.XX y XML v1.0, con el objetivo de incorporar las recomendaciones de la WS-I definidas en la especificación Basic Profile v1.0, v2.0 y de esta manera asegurar la interoperabilidad entre los sistemas. El estándar de codificación que se utiliza en los mensajes XML es UTF-8. La seguridad aplicada a los servicios web cubrirán los siguientes aspectos:

• Autenticación : Verificar que el cliente (usuario o aplicación) es quien dice ser. La identidad de un usuario se realizará en base a la información presentada por el usuario (usuario/contraseña, certificado, token SAML)

• Autorización : Otorgar acceso a los servicios en base a la identidad del cliente o a los roles asignados.

• Confidencialidad, privacidad : Mantener la información secreta mediante el uso de algoritmos de encriptación estándar de elementos XML.

• Integridad, no repudio : Asegurar que un mensaje permanece inalterado durante la transmisión mediante la firma digital. La firma también valida la identidad del remitente y proporciona una marca de tiempo para garantizar que una transacción no puede ser repudiada más tarde ni por el remitente ni por el destinatario.

Osakidetza usa Oracle Web Service Manager (OWSM) para gestionar y aplicar políticas a los servicios web publicados en la plataforma SOA. La política estándar que Osakidetza ha definido para los servicios proporciona:

• Autenticación mediante certificado x509

• Protección del mensaje mediante firma (sin encriptado)

Existen dos versiones de la política en OWSM, una para servicios y otra para clientes. Para garantizar la interoperabilidad, cada política tiene su versión compatible con tecnología .NET y Java.

• oracle_wss10_x509_token_with_message_sign_service_policy • oracle_wss10_x509_token_with_message_sign_service_policy_net • oracle_wss10_x509_token_with_message_sign_client_policy • oracle_wss10_x509_token_with_message_sign_client_policy_net

Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a través del firewall de aplicaciones (WAF). El WAF aplica reglas contra ataques y define patrones de seguridad.

• Es responsabilidad de cada aplicación publicada en la DMZ controlar el acceso y autorizar a los usuarios.

• El OSB de internet publica los servicios a los que pueden acceder las aplicaciones de internet.

• El OSB de internet audita todas las llamadas a los Servicios Web mediante una política propietaria de Osakidetza gestionada por OWSM.

• En el OSB de internet se protegen todos los servicios con la política oracle_wss10_x509_token_with_message_sign_service_policy. Esta política


autentica a las aplicaciones mediante certificado x509 y firma el mensaje de petición y respuesta.

• El OSB de internet delega la ejecución a servicios publicados en la Intranet. • En la intranet, se despliegan instancias independientes de servicios web para

dar servicio a las peticiones que llegan desde el OSB de Internet. Nota: OSB -> Oracle Service Bus 11.1.1.7

16.2.2 Gestor de Eventos

A continuación se describen los requisitos técnicos que tienen que cumplir las aplicaciones para publicar y/o recibir eventos.

• Estándares de comunicación La mensajería del Servicio Osakidetza se implementará de acuerdo con las especificaciones del estándar HL7 versión 2.XX o con cualquier otro formato propio de Osakidetza ; de esta manera se asegura la interoperabilidad entre los sistemas de información.

• Relación de tecnologías soportadas para la publicación y subscripción a eventos. Tecnologías que soporta el gestor de eventos para la publicación y subscripción a eventos, así como si la modalidad soporta transaccionalidad y las opciones de seguridad disponibles:

Modalidad Tecnología Transaccional Orden Seguridad Publicación Mensajería JMS Sí Sí, si el publicador

establece el parámetro UnitOfOrder

Autenticación (user/pass)

Publicación Servicio web No No Ninguna, Autenticación (user/pass) y WS-Security

Subscripción

Mensajería JMS Sí Sí. Event Manager garantiza la entrega en el mismo orden que ha

recibido los mensajes

Autenticación (user/pass)

Subscripción

Servicio OSB Sí Sí. Event Manager garantiza la entrega en el mismo orden que ha


Ninguna

Subscripción

Servicio web Sí Sí. Event Manager garantiza la entrega en el mismo orden que ha


Ninguna, Autenticación (user/pass) y WS-Security

Por cada modalidad y tecnología se deben cumplir unos requisitos técnicos que serán indicados al adjudicatario para la implementación de esta forma de integración.


Mensajería. Definición de Evento Un evento es un documento XML definido mediante un XSD, donde:

• id: Es el identificador del tipo de evento. Se genera durante el proceso de alta del evento en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el id sea válido.

• correlation: Es un campo libre en el que el publicador del evento indica un número correlativo relativo a su sistema.

• source: Es el identificador del publicador. Se genera durante el proceso de alta de un publicador en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el source sea válido.

• timestamp: Lo establece el publicador del evento en el momento del envío. • metadata : Puede contener un xml que ayude a describir el contenido del

evento. Event Manager puede utilizar esta información para tomar decisiones de enrutado.

• payload: Es el contenido del evento. Puede ser cualquier cadena de texto o XML.

El resultado devuelto cuando se publica un evento en Event Manager es un XML definido por un XSD, donde: • uuid: Es un identificador único que se asigna a cada evento procesado por

Event Manager. • processed: true o false, si el evento se ha procesado correctamente o con

errores. • errorCode: Si se ha producido un error, aquí se informa el código del error. • errorDescription: Si se ha producido un error contiene la descripción de éste. Se realiza gestión de errores: codificación de errores y descripción de los mismos.

16.3 Alineamiento con las Directrices Tecnológicas Para verificar que una solución (producto/aplicación/desarrollo) esta alineado tecnológicamente con las directrices anteriormente indicadas, se debe entregar la siguiente documentación:

• Procesos de negocio. • Flujo de información entre los diferentes componentes de la solución. • Documentación Técnica de la solución (*acorde al punto 17.1)

Debe incluir la arquitectura de la solución especificando los componentes lógicos y físicos de la misma, así como el diagrama de capas lógicas y su distribución en la infraestructura, los productos software y/o hardware requeridos, protocolos utilizados, necesidades de comunicación (apertura de puertos, balanceadores, …), etc.

• Especificaciones hardware y software necesarias para la implantación de la solución, acorde al uso (usuarios, concurrencia, disponibilidad, volumetría/almacenamiento, ..) Cada entregable deberá figurar en un documento, según el orden y títulos indicados en la relación anterior.


17 ANEXO II: RED DE COMUNICACIONES

17.1 Elementos principales

17.1.1 Datacenter La infraestructura de Datacenter de Osakidetza está formada por dos sedes interconectadas entre ellas mediante una conexión redundada de fibra óptica oscura dedicada. De manera gráfica sería como sigue:

17.1.2 Red WAN Actualmente Osakidetza dispone de dos redes WAN MPLS. Una de ellas operada por Euskaltel y la otra por Telefónica. En el siguiente diagrama se ve de manera esquemática:


En el esquema anterior se observa que los centros están divididos por tipo, en función de su tamaño con el siguiente detalle de caudales:

CAUDAL POR

ACCESO NÚMERO DE ACCESOS OPERADOR

TIPO 1 2 Gbps 2 EUSKALTEL

TIPO 2 300Mbps 2 EUSKALTEL



TIPO 5 4Mbps* 2 TELEFÓNICA

* Caudal variable en función de la cobertura de operador.

Las características principales de la Red de comunicaciones de Osakidetza son las siguientes:

• Cifrado de los datos que transitan por la red WAN.

• Alta Disponibilidad y Redundancia de la solución de modo que se asegure la continuidad de las comunicaciones en todos los centros ante eventuales incidencias.

• Utilización máxima de las capacidades solicitadas de modo que se obtenga el aprovechamiento máximo de los accesos y caudales totales de cada centro (Balanceo de Carga ). Ambos accesos se utilizan de forma simultánea.

• Se permite la comunicación any-to-any (spoke-to-spoke) entre todos los centros.

• Calidad de Servicio : Mediante la configuración de Clases de Servicio (CoS)

soportadas sobre la Red MPLS.

17.2 Caudal Centros con Laboratorio

CENTRO Tipo Caudal línea 1

(Mbps) Caudal línea 2

(Mbps)

o Hospital Universitario Basurto (HUB) 2 300 300

o Hospital Universitario Donostia (HUD) 2 300 300

� LRH Hospital Bidasoa 3 80 80

� LRH Hospital de Mendaro 3 80 80


� LRH Hospital de Zumárraga 3 80 80

o Hospital Universitario Araba (HUA)

� LRH Hospital Alto Deba 3 80 80

� LRH Hospital de Txagorritxu 2 300 300

o Hospital Universitario Cruces (HUC) 2 300 300

� LRH Hospital San Eloy 3 80 80

� LRH Hospital de Urduliz 3 80 80

o Hospital de Galdakao-Usansolo (HGU) 2 300 300

� LRH Hospital de Gernika 3 80 80


18 ANEXO III: ESPECIFICACIONES DEL CLIENTE (MAQUETA) Actualmente, la versión de maqueta que se instala en los equipos de Osakidetza es la 2.6; aunque convive con versiones anteriores instaladas.

• Hardware: o Procesador con un mínimo de Tecnología de 45 nm, Caché L2 de 3

Mb. y FSB de 1.066 Mhz. o Memoria RAM 2 Gb o Disco duro 250 Gb o Monitor 19 pulgadas con resolución 1440x900 mayoritaria o 1280x1024.

• Sistema Operativo

o Windows 7 Enterprise N (32 Bit) SP1 + Windows Media Feature Pack1


19 ANEXO IV: CONEXIONES/LABORATORIO A título informativo, se detallan a continuación las conexiones existentes a día de hoy en cada una de las UGC.

19.1 Analizadores

UGC Laboratorio/área Nombre equipo Tipo equipamiento (Analizador/otros) Proveedor Número

Basurto

Banco de Sangre Wadiana Analizador Grifols 1

Bioquimica Cap250 Alergia Analizador TermoFisher 1

Bioquimica Cap250 Inmuno Analizador TermoFisher 1

Bioquimica QC Sensor SOH Analizador Palex 1

Bioquimica Phoresis Analizador Sebia 1

Bioquimica BN II Nefelometro Analizador Siemens 1

Bioquimica Inmulite 2000 Analizador Siemens 1

Bioquimica Cobas e601 Analizador Roche 1

Bioquimica HbA1C Analizador Menarini 3

Citodiagnóstico FC 500 Analizador Izasa 1

Coagulación STA-Rack Analizador Roche 3

Coagulación STA Compact Analizador Roche 1

Externos Versia Aplicación gestión externa Baxter 1

Externos SSD Cribado Down Roche 1

Externos Reflab Laboratorio externo Reference Laboratory

1

Laboratorio Central Cobas 8000 Analizador Roche 1

Laboratorio Central Cobas 6000 Analizador Roche 2

Laboratorio Central Modular EEE Analizador Roche 1

Laboratorio Central Sysmex N Analizador Roche 3

Laboratorio Central Cellavision Analizador Roche 1

Laboratorio Central STA Compact Analizador Roche 2

Laboratorio Central Super Aution Analizador Menarini 3

Laboratorio Central Aution Jet Analizador Menarini 1

Laboratorio Central IRIS Analizador Beckman 2

Laboratorio Central Vescube VSG Analizador Menarini 2

Laboratorio Central GEM 3000 Analizador Izasa 2

Laboratorio Central TS1000 Clasificador Roche 1

Laboratorio Central Sysmex SP100 Extensor-Teñidor Roche 1

Laboratorio Central Cobas MPA Preanalítica Roche 1

Microbiología Bactec 9240 Analizador B-D 4

Microbiología Phoenix Analizador B-D 1

Microbiología ACS Centaur Analizador Siemens 1

Microbiología Ampli Prep Analizador Roche 1

Microbiología Inmulite 2000 Analizador Siemens 1

Microbiología Dynex Analizador Alere 1

Microbiología Freedom EVOlyzer Analizador Alere 1



Cruces

Bioquímica/Gastro Ocsensor Analizador Palex 1

Bioquímica/Gastro DS2 Analizador Alere 1

Bioquímica/Hormonas Hybrid Analizador Vitro 1

Bioquímica/Hormonas Kryptor Analizador Brahms 1

Bioquímica/Hormonas Liaison Analizador Palex 1

Bioquímica/metabolismo Dimension Analizador Siemens 1

Bioquímica/metabolismo Agilent GC-MS Analizador Agilent 1

Bioquímica/metabolismo Biocrom Analizador Gomensoro 1

Bioquímica/Proteínas Capillarys Analizador Sebia 1

Bioquímica/Proteínas Unicap 1000 Analizador Thermofisher 1

Bioquímica/Proteínas SPA plus Analizador Binding Site 1

Bioquímica/Proteínas BNII Analizador Siemens 2

Bioquímica/Urianálisis Urisys 2400 Analizador Roche 2

Bioquímica/Urianálisis UF1000i Analizador Roche 1

Hematología/Banco de sangre Autovue Analizador Ortho 1

Hematología/Banco de sangre

Wadiana Analizador Grifols 2

Hematología/coagulación especial

Triturus Analizador Grifols 1

Inmunología DS2 Analizador Palex 2

Inmunología Fax Canto 500 Analizador Beckton Dickinson 1

Inmunología Fax Scalibur Analizador Beckman 1

Inmunología Phadia 250 Analizador Thermofisher 1

Laboratorio Core Variant II Analizador BioRad 2

Laboratorio Core Urisys 2400 Analizador Roche 1

Laboratorio Core VSG Analizador Alifax 2

Laboratorio Core Osmometro Arkray Analizador Menarini 2

Laboratorio Core Cobas 6000 Analizador Roche 1

Laboratorio Core Architect Analizador Abbott 1

LRH San Eloy Advia 1800 Analizador Siemens 2

LRH San Eloy Advia 2120 Analizador Siemens 2

LRH San Eloy Stratus Analizador Siemens 1

LRH San Eloy Mini Vidas Analizador Biomerieux 1

LRH San Eloy Alifax VSG Analizador Beckman 1

LRH San Eloy Orina Analizador Menarini 1

LRH San Eloy Wadiana Analizador Grifols 2

Microbiología/Microbiología molecular Microlab Star Let IVD (Hamilton) Alicuotador Roche 1

Microbiología/Microbiología molecular

Cobas Ampliprep/Cobas TaqMan Analizador Roche 1

Microbiología/Serología no core LiaIson XL Analizador Palex (Diasorin) 1

Microbiología/Serología no core DS2 Analizador Alere 1

Microbiología/Serología no core Freedom Evolyzer Analizador Alere 1

Microbiología/Siembras Inocula Sembrador Beckton Dickinson 1

Preanalítica Label Etiquetador tubos Beckton Dickinson 2



Donostia

HUD-Bioquímica DSX System Autoanalizador inmunoensayo Palex 1

HUD-Genética LigthCycler Instrument 480 II Termociclador Roche 1

HUD-Genética LigthCycler Instrument 2.0 Termociclador PCR a tiempo real Roche 1

HUD-Hematología Multiplate Analizador funcion plaquetaria Roche 1

HUD-Hematología Erytra Analizador grupos sanguineos Grifols 1

HUD-Hematología Erytra Analizador grupos sanguineos Grifols 1

HUD-Inmunología FasCalibur Citometro de flujo Beckman 2

HUD-Inmunología API IF Blot Robot automatizacion fluorescencia I MENARINI 1

HUD-Inmunología API IF Plus Robot automatizacion fluorescencia II MENARINI 1

HUD-Inmunología Blot Robot tiras autoinmunidad EuroImmun 1

HUD-Microbiología 2XL Blue Mod Autoanalizador antibiogramas Biomerieux 2

HUD-Microbiología XN 1000 Autoanalizador morfologia LCR Roche 1

HUD-Microbiología Bioplex 2200 Autoanalizador serologia Bio Rad 2

HUD-Microbiología Architect 2000 Autoanalizador serologia ABBOTT 1

HUD-Microbiología Architect i200 SR Autoanalizador serologia ABBOTT 1

HUD-Microbiología Behring processor III Autoanalizador serologia Siemens 1

HUD-Microbiología Vidas VS30 Autoanalizador serologia Biomerieux 1

HUD-Microbiología UF 1000i Citometro urocultivos Roche 1

HUD-Microbiología UF 1000i Citometro urocultivos Roche 1

HUD-Microbiología EasyMag Extractor acidos nucleicos Biomerieux 1



HUD-Microbiología Bruker LT Identificacion bacteriana Bruker 1

HUD-Microbiología Bactec MGIT960 Incubador cultivos micobacterias Beckton Dickinson 1

HUD-Microbiología Bactec MGIT960 Incubador cultivos micobacterias Beckton Dickinson 1

HUD-Microbiología Bactec 9240 Incubador hemocultivos Beckton Dickinson 1



HUD-Microbiología DS2 Dynex Robot ELISA Dinex 1

HUD-Microbiología Cobas Ampliprep Robot preparador muestras Roche 1

HUD-Microbiología Cobas 4800 Z480 Sistema completo Ext-Amplif-Detec PCR a tiempo real Roche 1

HUD-Microbiología Cobas 6800 Pendiente de sustitución

Sistema completo Ext-Amplif-Detec PCR a tiempo real Roche 1

HUD-Microbiología SmartCycler Termociclador PCR a tiempo real Werfen 1

HUD-Microbiología CFX 96 Termociclador PCR a tiempo real Bio Rad 1


HUD-Microbiología LigthCycler Instrument 2.0 Termociclador PCR a tiempo real Roche 1

HUD-Microbiología LigthCycler Instrument 2.0 Termociclador PCR a tiempo real Roche 1




Donostia


HUD-Microbiología Cobas Taqman Termociclador PCR a tiempo real Roche 1

HUD-Microbiología m2000rt Termociclador PCR a tiempo real microplaca Abbott 1

LRH Bidasoa Wadiana Analizador grupos sanguineos Grifols 1

LRH Bidasoa Microscan Autoanalizador antibiogramas Beckman 1

LRH Bidasoa 2XL Blue Mod Autoanalizador antibiogramas Biomerieux 1

LRH Bidasoa Bactec 9240 Incubador hemocultivos Beckton Dickinson 1

LRH Mendaro Wadiana Analizador grupos sanguineos Grifols 1

LRH Mendaro 2XL Blue Mod Autoanalizador antibiogramas Biomerieux 1

LRH Mendaro Bactec 9240 Incubador hemocultivos Beckton Dickinson 1

LRH Zumarraga Wadiana Analizador grupos sanguineos Grifols 1

LRH Zumarraga 2XL Blue Mod Autoanalizador antibiogramas Biomerieux 1

LRH Zumarraga Bactec 9240 Incubador hemocultivos Becton Dickinson 1



Galdakao

BANCO DE SANGRE Wadiana ANALIZADOR GRIFOLS 1

BANCO DE SANGRE ERITRA ANALIZADOR GRIFOLS 1

BIOQUIMICA Unicell-Dxi ANALIZADOR BECKMAN 1

BIOQUIMICA OSMO STATION 6050 ANALIZADOR MENARINI 2

Gernika INTEGRA 400 ANalizador Roche 1

Gernika AQT 90 FLEX ANALIZADOR RADIOMETER 1

Gernika PICCOLO ANALIZADOR Werfen 1

Gernika STA satelite ANALIZADOR STAGO 1

Gernika SYSMEX XT 4000i ANALIZADOR ROCHE 1

HEMATOLOGIA S.ROJA-CITOMORFOLOGIA ALIFAX ANALIZADOR WERFEN 2

HEMATOLOGIA S.ROJA-CITOMORFOLOGIA HB 8180 ANALIZADOR MENARINI 3

INMUNOLOGIA Y ALERGIA DSX ANALIZADOR PALEX 1

INMUNOLOGIA Y ALERGIA UNICAP 250 ANALIZADOR THERMO-FISHER

1

INMUNOLOGIA Y ALERGIA XIRIL 75 ANALIZADOR PALEX 1

MICROBIOLOGIA Bactec MGIT960 ANALIZADOR BECTON-DICKINSON 1

MICROBIOLOGÍA BACTEC FX HEMOCULTIVO INCUBADOR-LECTOR

BECTON-DICKINSON 1

MICROBIOLOGÍA Microscan INCUBADOR/LECTOR CMI SIEMENS 1

MICROBIOLOGÍA OSIRIS LECTOR ANTIBIOGRAMAS BIO-RAD 1

ORINAS URISYS 2400 ANALIZADOR ROCHE 2

ORINAS SEDIMAX ANALIZADOR MENARINI 2

ORINAS OC-SENSOR ANALIZADOR PALEX 1

PROTEINAS BNII ANALIZADOR SIEMENS 1

PROTEINAS CAPILLARYS 2 ANALIZADOR SEBIA 1

SEROLOGIA VIDAS ANALIZADOR BIOMERIEUX 1

SEROLOGIA TAQMAN 48 ANALIZADOR ROCHE 1

SEROLOGIA MINILYSER ANALIZADOR INVERNESS 1

SEROLOGIA ARCHITECT i2000 SR ANALIZADOR ABBOTT 1

SEROLOGIA DYNEX ANALIZADOR ALERE 1

URGENCIAS INTEGRA 400 ANALIZADOR ROCHE 1

URGENCIAS Cobas U 711 ANALIZADOR ROCHE 1

URGENCIAS CELLAVISION ANALIZADOR ROCHE 1

URGENCIAS Sysmex 5000 ANALIZADOR ROCHE 1



HUA

Lab. Urgencias HUA Santiago Cell-Dyn Sapphire Analizador Abbott 2

Lab. Urgencias HUA Santiago Architect ci 4100 Analizador Abbott 2

Lab. Urgencias HUA Santiago ACL TOP 700 Analizador Werfen/Abbott 1

Lab. Urgencias HUA Santiago ACL TOP 500 Analizador Werfen/Abbott 1

Lab. Urgencias HUA Santiago Aution Max AX-4280 Analizador Menarini 1

Lab. Urgencias HUA Santiago Wadiana Analizador Grifols 2

Lab. Urgencias HUA Santiago Mini Vidas Analizador BioMerieux 1

Lab. Urgencias HUA Txagorritxu Architect ci 4100 Analizador Abbott 2

Lab. Urgencias HUA Txagorritxu Cell-Dyn Sapphire Analizador Abbott 2

Lab. Urgencias HUA Txagorritxu ACL TOP 700 Analizador Werfen-Werfen 2

Lab. Urgencias HUA Txagorritxu COBAS u 411 Analizador Roche 1

Lab. Urgencias HUA Txagorritxu Kryptor compact Analizador Atom 1

Lab. Urgencias HUA Txagorritxu Erytra Analizador Grifols 2

ALTO DEBA ARCHITECT ci8200 Analizador ABBOTT 2

ALTO DEBA XT-4000i Analizador ROCHE 1

ALTO DEBA XT-2000i Analizador ROCHE 1

ALTO DEBA ACL TOP 300 Analizador Werfen 2

ALTO DEBA CELLA VISION Analizador ROCHE 1

ALTO DEBA Cobas e 411 Analizador ROCHE 1

ALTO DEBA Cobas u 411 Analizador ROCHE 1

ALTO DEBA Capillarys Analizador SEBIA 1

ALTO DEBA OC-Sensor Analizador PALEX 1

ALTO DEBA URISYS 2400 Analizador ROCHE 1

ALTO DEBA Micro Scan Analizador SIEMENS 1

ALTO DEBA Wadiana Analizador GRIFOLS 1

ALTO DEBA Ves Matic 60s Analizador MENARINI 1

ALTO DEBA HA-8160 Analizador MENARINI 1

H. LEZA Piccolo Analizador WERFEN 1

H. LEZA Movilab Analizador ROCHE 1

Lab. Central HUA. Bioquímica Especial Triage Drogas Abuso Alere 1

Lab. Central HUA. Bioquímica Especial Capillarys Electroforesis/Inmunotipado Sebia 1

Lab. Central HUA. Bioquímica Especial BN II Nefelómetro Siemens 1

Lab. Central HUA. Bioquímica Especial Osmo Station 6060 Osmómetro Menarini 1

Lab. Central HUA. Bioquímica Especial Cobas 6000 Quimioluminiscencia Roche 1

Lab. Central HUA. Hematología Especial Citomics FC 500 Citómetro Flujo Beckman 1

Lab. Central HUA. Hematología Especial Navios Citómetro Flujo Beckman 1

Lab. Central HUA. Hematología Especial Aquios CL Citómetro Flujo Beckman 1



HUA

Lab. Central HUA. Hematología Especial ACL TOP 700 Coagulómetro Werfen 1

Lab. Central HUA. Hematología Especial Alifax Velocidad Sedimentación Beckman 2

Lab. Central HUA. Inmunología Inmunocap 250 Alergias-Autoanticuerpos Phadia 2

Lab. Central HUA. Inmunología Luxcan Multiplex IgE especifica Alergias-Autoanticuerpos CapitalBio 1

Lab. Central HUA. Inmunología Quantalyser Autoanticuerpos Werfen 1

Lab. Central HUA. Inmunología Euroblot One Autoanticuerpos EuroImmun 1

Lab. Central HUA. Inmunología Bioflash Autoanticuerpos Werfen 1

Lab. Central HUA. Inmunología Helios Autoanticuerpos Werfen 1

Lab. Central HUA. Inmunología Facscalibur Citómetro Flujo Beckton Dickinson 1

Lab. Central HUA. Microbiología Sensititre ARIS Identificación + ATB Werfen 1

Lab. Central HUA. Microbiología MGIT Incubador Micobaterias Beckton Dickinson 1

Lab. Central HUA. Microbiología / PCR CFX-96 Analizador Werfen 1

Lab. Central HUA. Microbiología / PCR Smart Cycler Analizador Werfen 1

Lab. Central HUA. Microbiología / PCR GenXpert Analizador Werfen 1

Lab. Central HUA. Microbiología / PCR Flurocycler Analizador Hain Lifescience 1

Lab. Central HUA. Microbiología / PCR Cobas Ampliprep-Tagman Biología Molecular Roche 2

Lab. Central HUA. Microbiología / Serología DS 2 Analizador Alere 1

Lab. Central HUA. Microbiología / Serología LIAISON Analizador Palex 1

Lab. Central HUA. Microbiología / Serología MariPOC Analizador Leti 1

Lab. Central HUA. Orinas UF 1000 Citómetro Flujo Roche 2

Lab. Central HUA. Orinas Diana (OC-Sensor) Sangre Oculta Heces Palex 1


19.2 Middleware

UGC Laboratorio/área Nombre Middleware Proveedor Cantidad Finalidad

Basurto

Integración Reference Reference Laboratory 1 Integración laboratorio externo

Laboratorio Central Menasoft Menarini 1 Middleware Instrumentos Menarini

Laboratorio Central PSM/ Labflow Roche 1 Middleware Instrumentos Roche

Microbiología EpiCenter Becton Dickinson 1 Middleware Instrumentos Beckton Dickinson

POCT Gemweb Werfen 1 Middleware POCT Werfen

Cruces

Hematología/Coagulación Hytwin werfen 1 Programa de anticoagulación

HSE Modulab werfen 1 Middleware Instrumentos Werfen


Laboratorio Core Centralink Siemens 2 Middleware Instrumentos Siemens

Microbiología/Bacteriología LabPro Beckman 1 Middleware Instrumentos Beckman

Microbiología/Bacteriología EpiCenter Becton Dickinson 1 Middleware Instrumentos Beckton Dickinson

Microbiología/Microbiología molecular Modulab Gold Werfen 1 Middleware Instrumentos Werfen

POCT IT1000 Roche 1 Middleware POCT Roche

POCT Rapidcom Siemens 1 Middleware POCT Siemens


Galdakao

Gernika Radiance Radiometer 1 Middleware integración AQT-90

Gernika IT1000 Roche 1 POCT MOVILAB

Integración Reference Reference Laboratory

1 Integración laboratorio externo

Laboratorio Core PSM/ Labflow Roche 1 Middleware Instrumentos Roche



HUA

Hematología/Coagulación GOTA werfen 1 Programa de anticoagulación


Lab. Central HUA. Bioquímica Especial

Piano Horiba 1 Middleware Instrumentos Horiba

Lab. Central HUA. Core Lab AMS Omnilab 1 Middleware Instrumentos Abbott

Lab. Central HUA. Microbiología Epicenter Beckton 1 Middleware Instrumentos Beckton

Dickinson Lab. Central HUA. Microbiología

LabPro Siemens 1 Middleware Instrumentos Beckman

Lab. Central HUA. Orinas Menasoft Menarini 1 Middleware Instrumentos Menarini



UGC Laboratorio/área Nombre Middleware Proveedor Cantidad Finalidad

HUD

Area organizativa Core Menasoft Menarini 1 Middleware Instrumentos Menarini

Area organizativa Core PSM/ Labflow Roche 1 Middleware Area Organizativa Core

Hematología/Coagulación Hytwin werfen 1 Programa de anticoagulación


LRH Bidasoa PSM/ Labflow Roche 1 Middleware Instrumentos LRH Bidasoa

LRH Bidasoa Hytwin werfen 1 Programa de anticoagulación

LRH Mendaro PSM/ Labflow Roche 1 Middleware Instrumentos LRH Mendaro

LRH Mendaro Modulab Werfen 1 Middleware Instrumentos Werfen

LRH Zumárraga PSM/ Labflow Roche 1 Middleware Instrumentos LRH Zumarraga

LRH Zumárraga Hytwin werfen 1 Programa de anticoagulación


Microbiología PSM/ Labflow Roche 1 Middleware Area serología

Microbiología PSM/ Labflow Roche 1 Middleware Otras áreas de microbiología (aparatos Roche, BioRad, Dinex

POCT Cobas IT1000 Roche 1 Middleware POCT Roche



20 ANEXO V: CRITERIOS DE SELECCIÓN Podrán concurrir al concurso las empresas que dispongan de las referencias y requisitos que se detallan a continuación.

• La solución de gestión de laboratorio ofertada, deberá contar con al menos dos referencias operativas y funcionantes en centro hos pitalario o similar, con una actividad anual superior a 500.000 peticion es (volantes) ó 5.000.000 determinaciones (pruebas).

• La solución de gestión de laboratorio ofertada, deberá contar con al menos dos referencias operativas y funcionantes en centro ho spitalario o similar, en el área de laboratorio general.

• La solución de gestión de laboratorio ofertada, deberá contar con al menos dos referencias operativas y funcionantes en centro hos pitalario o similar, en la disciplina de Microbiología

Para su acreditación deberán aportarse certificados expedidos o visados por el órgano competente cuando el destinatario sea una entidad del Sector Público. Cuando el destinatario sea un sujeto privado, mediante certificado expedido por éste.

adquisición e implantación de un sistema de … alcance técnico de la solución ... 6.3.16...

Documents