contratación del mantenimiento de la plataforma · pdf file... (seguridad paciente) ......

OBIo02VerDocumentoTramiteServlet Página 1/37

Contratación del Mantenimiento de la plataforma

Osakidetza Business Intelligence


Índice Página

1 INTRODUCCIÓN _______________________________________________________ 4

2 SITUACIÓN ACTUAL ____________________________________________________ 5

2.1 Atención Especializada _______________________________________________ 6

2.2 Atención Primaria___________________________________________________ 7

2.3 Centro de servicios de salud multicanal - Osarean ________________________ 8

2.4 Áreas Generales ____________________________________________________ 9 2.4.1 Área Pacientes ____________________________________________________________ 9 2.4.2 Área Oferta preferente ______________________________________________________ 9 2.4.3 Área Estratificación Pacientes ________________________________________________ 9

2.5 Cuadros de Mando _________________________________________________ 10 2.5.1 Área HFT (Historial Fármaco Terapéutico) ____________________________________ 10

3 OBJETO DEL CONTRATO ______________________________________________ 12

3.1 Línea de Mantenimiento y Soporte ___________________________________ 12 3.1.1 Atención a Consultas y Soporte de 2º nivel ____________________________________ 12 3.1.2 Mantenimiento Correctivo _________________________________________________ 12 3.1.3 Mantenimiento Preventivo/Perfectivo ________________________________________ 13

3.2 Línea de Evolución _________________________________________________ 13

3.3 Gestión del Inventario, Repositorios y Documentación ___________________ 14

3.4 Gestión y Administración del Servicio _________________________________ 14

3.5 Transferencia de Conocimiento en la finalización del proyecto _____________ 15

4 ESPECIFICACIONES TÉCNICAS ________________________________________ 16

4.1 Infraestructura ____________________________________________________ 16

4.2 Plataformas de Business Intelligence de Osakidetza ______________________ 16 4.2.1 Atención Especializada ____________________________________________________ 16 4.2.2 Atención Primaria ________________________________________________________ 18 4.2.3 Centro de Servicios Sanitarios Multicanal _____________________________________ 20

4.3 Estándares de INTEGRACIÓN ______________________________________ 22 4.3.1 Servicios Web ___________________________________________________________ 22 4.3.2 Gestor de Eventos ________________________________________________________ 24

5 EQUIPO DE TRABAJO _________________________________________________ 26

5.1 Equipo de Trabajo _________________________________________________ 26

5.2 Consideraciones al Equipo de Trabajo _________________________________ 26 5.2.1 Condicionantes de los equipos de trabajo ofertado ______________________________ 26 5.2.2 Currículo de los componentes del Equipo de Trabajo. ____________________________ 26

5.3 Ubicación del equipo de trabajo ______________________________________ 27

6 CONTROL Y SEGUIMIENTO ____________________________________________ 28

7 CONTENIDO DE LAS OFERTAS _________________________________________ 29

8 PROPIEDAD DE LOS PRODUCTOS ENTREGADOS ________________________ 31

9 CONFIDENCIALIDAD __________________________________________________ 32

10 PRESUPUESTO Y PLAZOS ______________________________________________ 33


10.1 Presupuesto _______________________________________________________ 33

10.2 Plazos ____________________________________________________________ 33

10.3 Facturación _______________________________________________________ 33

11 CRITERIOS DE ADJUDICACIÓN ________________________________________ 34

12 CONSULTAS AL PLIEGO _______________________________________________ 36

13 ANEXO I. CUESTIONARIO DE PERSONAL _______________________________ 37


1 INTRODUCCIÓN En el ejercicio 2013, Osakidetza , define un Plan Estratégico de Business Intelligence como base para establecer de forma corporativa, los modelos que permitan la explotación de datos en todas las áreas con el objetivo, tanto de dar salida al gran potencial de información que constituye el conjunto de sistemas de Osakidetza , como de iniciar el funcionamiento del Centro de Competencias en Business Intelligence de Osakidetza (CCBI). Como figura dinamizadora dentro de Osakidetza para asegurar el alineamiento con el negocio de las iniciativas de Business Intelligence se constituye el Centro de Competencias en Business Intelligence de Osakidetza , en adelante CCBI, cuya misión es la de actuar como el órgano estratégico, táctico y operativo de todas las necesidades que surjan en la organización en materia de Business Intelligence, y por tanto ser clave en el proceso de estandarización. Adicionalmente a la implantación del CCBI como órgano gestor y director de todas las iniciativas de BI de Osakidetza, se consolidan las siguientes iniciativas:

• Plataforma corporativa de BI para la Atención Espec ializada • Cuadro de Mando de Gestión Hospitalaria. información operativa, táctica y

estratégica acerca de la gestión y operatividad del sistema de información de un hospital.

• Cuadro de Mando Corporativo de Osakidetza , que integra tanto indicadores de Atención Especializada, como indicadores de Atención Primaria

Estas iniciativas complementan la Plataforma de BI para la Atención Primaria , ya existente, por lo que se dispone en la actualidad, de una plataforma analítica completa para el entorno asistencial, en continua evolución, razón por la cual se emite el presente expediente. Osakidetza tiene estandarizada como herramienta de BI corporativa, la herramienta de Oracle, Oracle Business Intelligence Enterprise Edition , en adelante OBIEE, por lo que todas las tareas derivadas de este mantenimiento se realizarán con este producto. En este sentido, y a fin de garantizar los objetivos del presente expediente, se valorará la inclusión en el equipo de trabajo, de profesionales que acrediten a nivel individual alguna de las siguientes especializaciones:

• Oracle Business Intelligence Foundation 10 Certified Implementation Specialist • Oracle Business Intelligence Foundation Suite 11g Certified Implementation

Specialist


2 SITUACIÓN ACTUAL Los modelos definidos dentro de la plataforma Osakidetza Business Intelligence son los siguientes:

• Atención especializada: o Urgencias o Hospitalización o Consultas Externas o Farmacia Hospitalaria o Actividad Quirúrgica o Hospitalización a Domicilio o Hospital de día Medico o Hospital de día Quirúrgico o Radiología o Anatomía Patológica o Actividad Enfermería o Actividad Clínica o Archivo o CMBD o Indicadores Online o Camas o Salud Mental

• Atención primaria

o Analíticas o Anamnesis o Citas (Seguridad Agenda) o Citas (Seguridad Paciente) o Condicionantes o Episodios o Formularios o Incapacidad Temporal o Interconsultas o Prescripciones o Radiologías

• Centro servicios salud multicanal

o Cita Previa o IVR / Call center o Consejo Sanitario o Carpeta Salud o CRM Campañas o CRM Crónicos

• Áreas Generales

o Estratificación o HFT o Pacientes o Oferta Preferente


• Cuadros de Mando

o Corporativo Asistencial o Gerencial Asistencial o Urgencias o Hospitalización o Consultas Externas o Farmacia Hospitalaria o Actividad Quirúrgica o Hospitalización a Domicilio o Hospital de día Medico o Hospital de día Quirúrgico o Radiología o Anatomía Patológica o Actividad Enfermería o Actividad Clínica o Archivo o CMBD o Campaña Gripe o Estratificados Departamento o Estratificados Osakidetza o HFT o IT(OSI) o Oferta Preferente(OSI)

2.1 Atención Especializada Los sistemas de información origen del modelo de BI de Atención Especializada son los siguientes:

• e-Osabide : HIS corporativo administrativo • e-Osabide- Farmacia : HIS corporativo Unidosis. • Servicios Web e-Osabide : Web services disponibles en el HIS corporativo

administrativo para la consulta de datos on-line • Osabide Global : Estación clínica Médica corporativa. • Vademécum : Catálogo global de medicamentos • Vitropath : Aplicativo utilizado para anatomía patológica • Osakliniker : Aplicativo para el registro de la información asociada al CMBD • Impax : Aplicativo utilizado por el PACS de pruebas radiológicas. • OsaNaia : Estación enfermería corporativa.

A continuación se detalla el listado de los módulos construidos hasta la fecha, así como los datos que describen el volumen de información asociada. Módulo Sistemas origen

información

Hechos Estrellas Indicadores Dimensiones

Hospitalización e-Osabide 519 1 32 69

Actividad quirúrgica e-Osabide 677 6 62 115

Hospital de día quirúrgico e-Osabide 595 1 17 66

CMBD Osakliniker 136 1 43 31

Hospital de día médico e-Osabide 252 1 11 38

Hospitalización a domicilio e-Osabide 364 2 17 79


Actividad Clínica Osabide Global 548 10 11 77

Farmacia Hospitalaria e-Osabide,

Vademecum

506 9 87 88

Consultas Externas e-Osabide 1320 6 115 58

Anatomía patológica Vitro 212 3 11 33

Diagnósticos y

Procedimientos (Archivo)

e-Osabide 133 2 0 23

Urgencias e-Osabide,

Osabide Global

597 2 35 100

Radiología PACS Impax 212 3 11 39

Indicadores online WS e-Osabide 77 2 24 8

Camas e-Osabide, WS e-

Osabide

49 3 12 4

Salud Mental e-Osabide 93 2 3 13

Actividad Enfermería OsaNaia En

desarrollo

En

desarrollo

En

desarrollo

En desarrollo

2.2 Atención Primaria Los sistemas de información origen, del modelo de BI de Atención Primaria son los siguientes:

• Osabide AP : SI corporativo de Atención Primaria. En el DW cuenta con 10 módulos claramente diferenciados:

• Módulo Analíticas

• Módulo Anamnesis

• Módulo Citas

• Módulo Condicionantes

• Módulo Episodios

• Módulo Formularios

• Módulo Incapacidad Temporal

• Módulo Interconsultas

• Módulo Prescripciones

• Módulo Radiologías

A continuación se detalla el listado de los módulos construidos hasta la fecha, así como los datos que describen el volumen de información asociada.

Módulo Sistemas origen

información

Hechos Estrellas Dimensiones

Analíticas Osabide AP 145 1 22

Anamnesis Osabide AP 135 1 11


Citas Osabide AP 190 1 17

Condicionantes Osabide AP 122 1 11

Episodios Osabide AP 150 1 15

Formularios Osabide AP 162 1 14

Incapacidad temporal Osabide AP 180 1 20

Interconsultas Osabide AP 190 1 22

Prescripciones Osabide AP 140 1 24

Radiología Osabide AP 130 1 19

2.3 Centro de servicios de salud multicanal - Osare an El CSSM dispone de un Cuadro de Mando con información relativa a Cita previa, IVR, Consejo sanitario, Carpeta de salud, CRM-Campañas y CRM-Crónicos cuyo objetivo es extraer informes y analizar la evolución temporal de adopción de los servicios. Además de estos informes también se provee al usuario de indicadores que pueden ser analizados en informes a demanda, generados por el propio el usuario. De esta manera el CSSM puede analizar los siguientes aspectos:

• KPI’s (Key Performance Indicator) reflejando la eficiencia de los servicios del CSSM mediante indicadores que miden el nivel de desempeño de un proceso.

• Comparativas de algunos KPI’s. • Gráficos de tendencia mostrando la evolución de algunos KPI´s • Módulo que permite la configuración de informes propios a medida.

Se ha diseñado un Cuadro de Mando Integral, que dispone de informes predefinidos que permiten ver el estado de los servicios y un Cuadro de Mando Operativo con sus correspondientes herramientas de análisis multidimensional y de reporting. Este se realiza a través del módulo OBIEE Answers. Dentro del Cuadro de Mando se han predefinido informes para las diferentes funcionalidades definidas y en cuanto al Cuadro de Mando Operativo se ha puesto a disponibilidad del usuario información relativa a las funcionalidades que se describen a continuación:

• Cita Previa : Indicadores e Informes que definen el nivel de servicio de Cita Previa a través de la Web, el IVR, Call Center y personal de Osakidetza . Se analiza la información desde varios puntos de vista como citas autogestionadas por el ciudadano, por tipología de consulta, etc.

• IVR/ Call Center: Se analiza la información relacionada con el nivel del servicio prestado por el IVR (Interactive Voice Response) desde indicadores e informes predefinidos.

• Consejo Sanitario : Indicadores e Informes que analizan la información aportada por la herramienta de Consejo Sanitario de Gestión de dolencias. Informes que indican la actividad telefónica del servicio, la calidad del servicio, etc.

• Carpeta de Salud : Indicadores e Informes que dan a conocer la actividad de esta aplicación que permite que el paciente tenga acceso a sus datos personales y sus datos de salud como informes médicos, resultados de pruebas diagnósticas, alergias, problemas resueltos y problemas activos.

• CRM- Campañas : Indicadores e Informes que dan a conocer la situación


de las diferentes campañas definidas en el módulo de Campañas de CRM • CRM- Crónicos : Indicadores que miden dentro de los datos del programa

de crónicos del CRM, los clientes, a qué programas están adheridos, qué actividades tienen, el estado de las actividades, etc.

• Alarmas : Control de cargas

2.4 Áreas Generales Se exponen a continuación varias áreas con entidad propia dentro de la plataforma Osakidetza Business Intelligence.

2.4.1 Área Pacientes Esta área corresponde a pacientes con datos de nivel alto.

2.4.2 Área Oferta preferente Los sistemas de información origen, del modelo de BI de Oferta Preferente son los siguientes:

• Osabide AP : HIS corporativo de atención primaria.

En el DW cuenta con 2 módulos claramente diferenciados:

• Módulo Oferta Preferente (Consulta) : Este módulo es una copia de los datos operacionales (ODS) filtrando solo los registros necesarios para calcular el cumplimiento de tareas e Indicadores. Sirve como punto de cálculo del modelo final pero a su vez puede ser consultado por los usuarios para realizar segmentaciones customizadas de paciente.

• Módulo Oferta Preferente: En él se encuentran ya calculados los cumplimientos de tareas e indicadores y el porcentaje de cumplimiento por fecha(Cuatrimestre) y Ámbito (Cupo-UAP-Comarca)

A continuación se detalla el listado de los módulos construidos hasta la fecha, así como los datos que describen el volumen de información asociada. Módulo Sistemas origen

información

Hechos Estrellas Dimensiones

Oferta preferente Consulta Osabide AP 50 1 6

Oferta preferente Osabide AP 25 1 6

2.4.3 Área Estratificación Pacientes Este área esta actualmente esta en proceso de diseño. El objetivo es diseñar un proceso que incorpore los ficheros de entrada necesarios para poder realizar los procesos de Estratificación de pacientes Los orígenes de la información serán tanto los Sistemas de Información de Osakidetza como ficheros planos obtenidos entre otros orígenes del Departamento de Salud.


2.5 Cuadros de Mando Para todos los módulos descritos anteriormente existe un cuadro de mando asociado, con una preselección de los indicadores y ejes de análisis más representativos de cada módulo, mostrando la información en formato de tablas y gráficos. Como muestra, los cuadros de mando siguientes, disponen de la cantidad de informes que se indica a continuación:

CM Páginas Informes

Hospitalización 10 121

Actividad quirúrgica 8 191

Hospital de día quirúrgico 3 58

CMBD 9 45

Hospital de día médico 4 47

Hospitalización a domicilio 5 76

Actividad Clínica 4 39

Farmacia 511 34

Consultas Externas 11 19

Anatomía patológica 2 33

Urgencias 5 61

Inicio 1 7

Gerencial 3 179

Indicar que existe una agregación de información tanto de Atención Primaria como de Atención Especializada a nivel mensual que alimenta el Cuadro de Mando Corporativo:

Módulo Sistemas origen

información

Indicadores Dimensiones

CMC BI AE 197 8

2.5.1 Área HFT (Historial Fármaco Terapéutico) Esta área corresponde con las Prescripciones y las Dispensaciones del circuito de Receta Electrónica

- Se recogen las Prescripciones generadas en Presbide, tanto en Primaria como en Especializada y las actualizaciones de las mismas.

- Se recoge la necesidad de Visado y si está o no visada dicha prescripción, dato proveniente del Departamento de Salud

- Además se recoge la información de las recetas dispensadas en Farmacia Los sistemas de información origen, del modelo de BI de Oferta Preferente son los siguientes:

• PRESBIDE: Sistema Universal de prescripción de receta.


• SI del departamento de Salud A continuación se detalla el listado de los módulos construidos hasta la fecha, así como los datos que describen el volumen de información asociada. Módulo Sistemas origen

información

Indicadores Estrellas Dimensiones

HFT Presbide, Dtp.

Sanidad

4 1 312


3 OBJETO DEL CONTRATO El objeto del presente expediente es la prestación del servicio de Mantenimiento y Evolución de la plataforma Osakidetza Business Intelligence. Este servicio comprende el ciclo completo de desarrollo, destacando principalmente las siguientes líneas de trabajo:

3.1 Línea de Mantenimiento y Soporte Los servicios que contempla esta línea de trabajo son los siguientes:

3.1.1 Atención a Consultas y Soporte de 2º nivel Definido como el conjunto de actividades de soporte y atención a consultas e incidencias técnicas y funcionales de usuarios, respecto a los servicios objeto del contrato. 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 y el flujo de Mantenimiento, es el producto HP-PPM (Project and Portfolio Management).

El servicio de Atención a Consultas y Soporte, actuará como soporte de 2ª nivel de los servicios contratados, pudiendo realizarse el acceso al servicio por los siguientes canales:

• Vía derivación del CAU de 1º nivel o 2º nivel de O sakidetza, previo registro en HP-Service Manager

• Vía HP-PPM: Incidencia registrada en HP-PPM, por la Subdirección de informática de Osakidetza

• Vía teléfono: derivado del CAU Osakidetza o de la Subdirección de informática de Osakidetza

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.

3.1.2 Mantenimiento Correctivo Definido como aquel proceso orientado a la reparación de defectos existentes en un sistema software. Estos defectos pueden manifestarse de distintas formas:

• Cuando el programa falla o termina inesperadamente. • Un programa produce un resultado que no es acorde con los requisitos.

Se contemplan dos tipos básicos de mantenimiento correctivo:


• Reparaciones de emergencia: ejecutadas en cortos periodos de tiempo y generalmente sobre un único programa.

• Reparaciones planificadas: arreglan defectos que no requieren una atención inmediata y reexaminan todas las reparaciones de emergencia.

El mantenimiento correctivo incluye actividades que comprenden desde la colaboración activa con Osakidetza en el diagnóstico de los defectos detectados y su propuesta de solución, hasta el seguimiento y resolución de los mismos. También se incluyen como responsabilidad del adjudicatario los desarrollos necesarios para corregir los datos erróneos por el mal funcionamiento de la aplicación. Toda actuación sobre el software motivado por un fallo o error de la aplicación será considerada siempre como actividad correctiva y en ningún caso actividad de tipo evolutivo. La resolución de un error en producción puede motivar el despliegue de equipos de desarrollo para edición de parche y actuaciones presenciales, si fuera necesario.

3.1.3 Mantenimiento Preventivo/Perfectivo Definido como el conjunto de acciones propuestas por el proveedor orientadas a la modificación de las aplicaciones con el fin de minimizar el mantenimiento correctivo y mejorar la calidad de las mismas. Para su gestión se utilizará el mismo sistema que en el mantenimiento Adaptativo/Evolutivo.

3.2 Línea de Evolución Se describen los 2 tipos de mantenimiento:

• Mantenimiento Adaptativo Son las modificaciones que afectan a los entornos en los que el sistema opera, por ejemplo, cambios de configuración del hardware, software de base, gestores de base de datos, comunicaciones, etc. Incluye, entre otros:

o Cambios en el entorno de los datos o su procesamiento o Cambios en la plataforma o arquitectura tecnológica o Modificación de procedimientos existentes que no implican nuevas

funcionalidades o Exportaciones e importaciones de datos dedicados a la integración con

otras aplicaciones del entorno, para mantenimiento de integridad de la información

o Integración con otros aplicativos a nivel de plataforma tecnológica o La parametrización de aplicaciones

Este tipo de mantenimiento se regirá por los mismos criterios descritos en el mantenimiento evolutivo.

• Mantenimiento Evolutivo

Son las incorporaciones, modificaciones y eliminaciones necesarias para cubrir la evolución o cambio de las necesidades del usuario, es decir, la incorporación


de nuevas funcionalidades a la cobertura actual del software. Incluye, entre otros:

o Cambios en los requisitos de la aplicación o Modificaciones derivadas de cambios en la normativa o Modificaciones que supongan mejoras del aplicativo y por tanto

incorporables a la versión base

3.3 Gestión del Inventario, Repositorios y Document ación Dada la naturaleza y características del servicio objeto del contrato se hace imprescindible contar con un inventario detallado de todos los artefactos de la aplicación contratada, necesarios para la realización de las actividades de mantenimiento encomendadas al adjudicatario, entre otros, el código fuente, los contenidos estáticos, los scripts de creación de base de datos, los ficheros de configuración, etc. Se subraya también la necesidad de generar la documentación y elementos adicionales fijados por el Servicio de Implantación de Osakidetza para cada versión de aplicación:

• Manual de explotación • Documento de implantación • Carga de código en las zonas de traspaso • Cálculo de volumetría de datos • Contratos de servicio • Otros documentos según la tipología y características de la aplicación

(seguridad y accesos, plan de continuidad de negocio, configuración de recursos, etc.)

Excepto la documentación necesaria para realizar el proceso de implantación del cambio (que se generará previamente), las actualizaciones aquí definidas deberán realizarse en un plazo máximo de 48 horas desde el cierre de la solicitud de trabajo. El incumplimiento sobre la obligación del mantenimiento y actualización del inventario, del repositorio y de la documentación generará la no aceptación del trabajo.

3.4 Gestión y Administración del Servicio El suministrador se responsabilizará de la gestión del contrato, de la gestión del servicio, del seguimiento y reporte a los distintos comités, de las actividades relacionadas con el aseguramiento de la calidad y la mejora continua del servicio, gestión de la organización estructural y de trabajo de sus equipos y de generar la documentación necesaria. Se contemplan principalmente los siguientes tipos de funciones:

• Priorización, coordinación, supervisión y seguimiento general de los servicios incluidos en el contrato.

• Coordinación con unidades funcionales de Osakidetza • Coordinación y supervisión de integraciones y estándares. • Documentación, información y gestión del conocimiento.

Se incluyen en esta línea de trabajo las actividades relativas a la gestión y seguimiento del propio servicio, cuyos indicadores e informes deben ser reportados al comité de


seguimiento para su aprobación y control. Se deberán cumplimentar mínimamente los informes detallados en el apartado de “Control y seguimiento” del presente pliego de bases técnicas, valorándose tanto la incorporación de nuevos indicadores como informes adicionales que proponga el licitador y que contribuyan a la mejora en la gestión del servicio.

3.5 Transferencia de Conocimiento en la finalizació n del proyecto Antes del cese o finalización de este contrato, el adjudicatario estará obligado a devolver el control del servicio a Osakidetza y/o al suministrador o suministradores que ésta determine. El adjudicatario deberá garantizar el proceso de transferencia de conocimiento, mediante la entrega de la documentación que se estime oportuna e impartiendo unas sesiones de transferencia de conocimiento, bajo la supervisión de Osakidetza .


4 ESPECIFICACIONES TÉCNICAS

4.1 Infraestructura Osakidetza proveerá la infraestructuras (hardware y software) necesarias para facilitar la prestación del servicio a los entornos de Desarrollo, Pre-producción y Producción. El adjudicatario será el encargado de dotar del equipamiento personal (portátil y teléfono) a los profesionales.

4.2 Plataformas de Business Intelligence de Osakide tza Se describen a continuación las plataformas de Business Intelligence existentes actualmente en Osakidetza y objeto del presente mantenimiento. Se podrán realizar durante la vigencia del presente expediente, trabajos relacionados con el estudio y consolidación, si procede, de todas las áreas dentro de una plataforma única.

4.2.1 Atención Especializada La arquitectura técnica utiliza diversos productos de Oracle:

Componente Producto/Versión BI Oracle Business Intelligence Enterprise Edition 11.1.1.6.2

ETL Oracle Data Integrator 11.1.1.5.0 (con Repository Creation Utility 11.1.5.2)

Base de Datos Oracle Database Server Enterprise Edition 11.2.0.3 (con OLAP Option)

Se dispone de 3 entornos de trabajo: Entorno Tareas Desarrollo Construcción y Pruebas unitarias

Preproducción Pruebas integradas, Pruebas de usuario y Formación

Producción Producción

El Modelo de Arquitectura utilizado se encuentra compuesto de las áreas mostradas en el siguiente diagrama: .


El Modelo se estructura en cuatro capas principales:

1. Orígenes de Información : Sistemas fuentes de información. Sistemas operacionales y ficheros de datos.

2. Procesos de Extracción y carga : Procesos de aprovisionamiento de información.

3. Datawarehouse . Almacenamiento de datos:

a. Staging Area (STG). Repositorio temporal que contiene réplicas de los datos de los distintos sistemas origen a cargar en el resto de modelos de datos del Datawarehouse. En este modelo se aplican transformaciones y reglas de validación.

b. Modelo Corporativo (ODS). Modelo relacional normalizado orientado al análisis (OLAP) en detalle (no agregación) que incorpora todas las áreas o módulos que estén bajo el alcance del sistema de BI.

c. Modelo de Negocio (DDS). Modelo relacional agregado y normalizado orientado a análisis (OLAP) específicos. Dicho modelo se crea para mejorar de rendimiento de algunas consultas agregando información de un modelo corporativo o varios (ODSs) así como para atender características funcionales especiales.

4. Explotación de Información con OBIEE:

a. Portal BI. Acceso a los diferentes servicios proporcionados por el sistema: cuadros de mando, informes predefinidos, alertas…

b. Plataforma analítica. Herramientas para la generación de informes y análisis.


4.2.2 Atención Primaria

La arquitectura técnica utiliza diversos productos de Oracle:

Componente Producto/Versión BI Oracle Business Intelligence Enterprise Edition 11.1.1.6.2

ETL Oracle Warehouse Builder Base de Datos Oracle Database Server Enterprise Edition 11.2.0.3 (con OLAP Option)

Se dispone de 3 entornos de trabajo: Entorno Tareas Desarrollo Construcción y Pruebas unitarias

Preproducción Pruebas integradas, Pruebas de usuario y Formación

Producción Producción

El Modelo de Arquitectura utilizado se encuentra compuesto de las áreas mostradas en el siguiente diagrama:


.

ENTORNO DE PREPRODUCCIóN

PC CLIENTEINFORMATICA

Herramientas Instaladas:OBIEE Cliente: Administrator

OWB Cliente: Designer Center

Servidor Web: Apache TomcatMaquina_Servidor_Web

Acceso web a la URL:http://<Maquina_Servidor_Web>:8080/analytics

PC CLIENTEUSUARIOS

Máquina_LDAP

Máquina OBIEEInstalado:

BI Server, BI SchedulerBI Presentation Server

Acc

eso

Base de DatosDW Atención Primaria

Modelo físicoRepositorio de OWB

Base de DatosStand by Producción

Acceso

Acceso via Data Base link

Acceso a la Base de Datos

Servidor de CorreoSMT Sever

Acceso

Acceso

Acceso web a la URL:http://<Maquina_Servidor_Web>:8080/analytics

NAVEGADORES: Internet explorer 6.XInternet explorer 7.0, Firefox 1.5.X, Firefox 2.0

Para el desarrollo y mantenimiento del modelo de Oracle BI para Osakidetza , se han utilizado las siguientes herramientas:

• Oracle Warehouse Builder para la creación y aprovisionamiento de información del Data Warehouse. Es una herramienta ETL a la que se tendrá permiso de lectura en Preproducción / Producción


• Oracle BI Administrator para el diseño del modelo de datos de usuario y asignación de permisos.

Ambas herramientas forman parte del producto Oracle.

4.2.3 Centro de Servicios Sanitarios Multicanal El CSSM dispone en la actualidad de un Cuadro de Mando con información relativa a Cita previa, IVR, Consejo sanitario, Carpeta de salud, CRM-Campañas y CRM-Crónicos cuyo objetivo es el de extraer informes y analizar la evolución temporal de adopción de los servicios. Además de estos informes también se provee al usuario de indicadores que pueden ser analizados en informes a demanda por el usuario. Además de OBIEE, se utiliza Informatica PowerCenter que es un software de integración de datos, este permite acceder a datos de prácticamente cualquier sistema y en cualquier formato, e integrarlos con los sistemas de almacenamiento de datos propios de la empresa. Para poder gestionar, configurar, administrar, cargar y monitorizar las tablas de la Base de Datos se utiliza la consola de Oracle: Data Warehouse Administration Console (DAC). DAC está especialmente diseñada para aquellas organizaciones que usen Informatica PowerCenter como herramienta de ETL. A continuación se exponen las integraciones con otros sistemas:


CODIGO-NOMBRE COMENTARIO

IVR Información del IVR relativa a número de llamadas, tipo de fin de la llamada, transferencias a centros y encuesta de satisfacción.

IVR Actividad de los agentes virtuales del IVR. Carpeta Salud Trazas de actividad registradas en Carpeta de Salud. Consejo Sanitario Trazas de actividad registradas en Consejo Sanitario.

OsabideAP Citas registradas en Osabide AP desglosadas por fecha, centro de salud, canal de registro, tipo de cita, edad etc.

CRM Siebel Información del estado de las campañas en marcha en CRM.

IVR Información de llamadas recibidas en el call center, llamadas recibidas en IVR y llamadas rechazadas por saturación.

Cita Web Resultados de la encuesta de satisfacción del servicio de cita web.

IVR Número de llamadas al IVR rechazadas por saturación de canales primarios.

Consejo Sanitario Consejo Sanitario. Información de las llamadas gestionadas por el personal de enfermería de Consejo Sanitario.

Las especificaciones de los productos se exponen a continuación:

Producto

OBIIE

Case Mgmt BI Apps

Service BI Apps

Marketing BI Apps

Informatica PowerCenter and PowerConnect Adapters

OBIEE

UPK

UPK

Case Mgmt BI Apps

Service BI Apps

APLIC. SO PRODUCTO VERSION

OBBIE Linux Red Hat Enterprise Server 5

JVM 64-Bit 1.6.0_31-b04

WebLogic 10.3.5.0

Como evolución de la plataforma se esta valorando migrar a las siguientes especificaciones: Business Intelligence Oracle BI EE 11.1.1.6.0 ETL Oracle Data Integrator 11.1.1.6.0 Base de datos Oracle Database Patchset 11.2.0.3


4.3 Estándares de INTEGRACIÓN Los requisitos de integración con los sistemas de información de Osakidetza se soportan en 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 o 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.2 o WSDL 1.1 y WSDL 1.2 Binding o SOAP con Attachments o SOAP MTOM

• 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

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

4.3.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 publicac ión y subscripción a eventos. Las tecnologías que soporta el gestor de eventos para la publicación y subscripción a eventos, así como si la modalidad soporta transaccionabilidad 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 Servicio OSB Sí Sí. Event Manager garantiza la entrega en el mismo orden que ha

recibido los mensajes

Ninguna

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

recibido los mensajes

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


5 EQUIPO DE TRABAJO

5.1 Equipo de Trabajo Para la gestión y el desarrollo del servicio, los licitadores deberán detallar lo siguiente aspectos en su propuesta:

• Organigrama del equipo de trabajo, identificando responsables y funciones a desarrollar según considere para la ejecución del servicio de este pliego.

• Detalle del equipo total de trabajo, que los licitadores consideren necesario, identificando las personas, categoría, horas/categoría ofertada y funciones a desarrollar, para la ejecución de las tareas previstas con el alcance definido en este pliego.

El equipo de trabajo deberá incluir al menos los siguientes recursos:

• 1 Analista Programador Senior OBI: Será el Responsable operativo del Servicio ante Osakidetza .

• 2 Programadores OBI A fin de garantizar los objetivos del presente expediente, se valorará la inclusión en el equipo de trabajo, de profesionales que acrediten a nivel individual las siguientes especializaciones:

• Oracle Business Intelligence Foundation 10 Certified Implementation Specialist • Oracle Business Intelligence Foundation Suite 11g Certified Implementation

Specialist

5.2 Consideraciones al Equipo de Trabajo En relación con el equipo de trabajo solicitado se tendrán en consideración los siguientes aspectos:

5.2.1 Condicionantes de los equipos de trabajo ofertado Durante la ejecución del contrato, Osakidetza podrá verificar los conocimientos y experiencia profesional del equipo de trabajo. No obstante, la falsedad en el nivel de conocimientos técnicos del personal ofertado, así como la sustitución de alguno de los componentes del equipo adscrito a la ejecución de los trabajos, sin observar el procedimiento y requisitos exigidos en los apartados siguientes, facultará a Osakidetza para instar la resolución del contrato.

5.2.2 Currículo de los componentes del Equipo de Trabajo. Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de contratación, junto con el papel/perfil (conforme a los indicados en el cuadro anterior) que asumen en la realización descrita.


La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una adecuada evaluación del criterio de “Medios adscritos para la ejecución del proyecto”, pudiendo el licitador no ser puntuado por este concepto. Para la descripción de los recursos humanos se utilizarán el formulario que se detalla en el ANEXO I.

5.3 Ubicación del equipo de trabajo Sin perjuicio de lo que expresan en el siguiente párrafo, Osakidetza se reserva el derecho de modificar la política en cuanto a ubicaciones del equipo durante el transcurso del contrato, sin que ello suponga un coste adicional para Osakidetza . La prestación del servicio tendrá carácter presencial , ubicándose la totalidad del mismo en las instalaciones de la Organización Cent ral de Osakidetza , ubicada en Vitoria-Gasteiz.


6 CONTROL Y SEGUIMIENTO El propósito de las tareas de control y seguimiento es el de proveer una visión objetiva del estado actual de la prestación del servicio y determinar las posibles desviaciones a fin de aplicar las acciones correctoras que sean necesarias. En este sentido se denomina seguimiento a la evaluación rutinaria del estado, mientras que llamamos control, a la toma de los valores que definen el estado. Los productos resultantes de esta tarea son los informes de seguimiento, un documento donde se anotan los resultados de la evaluación de una iteración de control. Existirán una serie de informes de seguimiento requeridos para el correcto análisis de la evolución del Servicio. El Proveedor utilizará el sistema de Osakidetza para el registro de incidencias y consultas, y complementará la información de dichos sistemas con sus propias herramientas para elaborar estos informes, posibilitando el acceso de Osakidetza a la información empleada para su confección. Se deberán incluir mínimamente tres tipos de informes de periodicidad mensual:

• Informes de Seguimiento: Relación detallada de consultas, incidencias, problemas y peticiones, resumen acumulado del mes actual, acumulado del mes anterior y variación neta del mes, etc.

• Informes del Nivel de Servicio: Grado de cumplimiento de los indicadores, evolución anual, análisis de incidencias o problemas, propuestas de actuación, etc.

• Evolución de la Documentación Técnica: Aplicaciones documentadas con entidades asociadas, documentación en curso, grado de avance, etc.

De lo detallado anteriormente se deriva que el licitador deberá describir en su Oferta:

• El modelo de control y seguimiento a aplicar durante la prestación del servicio, incluyendo las reuniones de seguimiento a celebrar, su objetivo, su periodicidad, los asistentes necesarios, los controles que deben ser ejecutados, etc.

• Los informes de seguimiento que deberán obtenerse en cada fase del servicio, y para cada solicitud de trabajo realizada. Se detallará su objetivo y al menos parcialmente, su contenido.

• Los indicadores de calidad del servicio a medir, y su criticidad asociada. • Los métodos de aplicación de las posibles acciones correctoras


7 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.1 o superior). Las ofertas se presentarán en dos modalidades:

1. 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 de una sola cara).

2. 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, incluidos anexos (300 páginas A4 de una sola cara). En lo relativo al equipo de trabajo , y en el caso de incluir más técnicos de los solicitados, deberá indicarse de forma expresa e inequívoca los profesionales que prestarán el servicio presencial .

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. 2. Descripción de la solución propuesta Este capítulo se estructurará en:

2.1. Planteamiento General En este apartado se expondrá la estrategia que el licitador considera apropiada para alcanzar los objetivos del proyecto, incluyendo la descripción detallada de los servicios ofertados.

2.2. Productos a obtener Como resultado de los servicios detallados en el apartado anterior se obtendrán una serie de documentos / productos que se describirán brevemente en esta sección.

2.3. Herramientas a utilizar Descripción de las herramientas que a priori se consideran adecuadas para la realización del proyecto, justificando su adecuación a los objetivos del mismo y las ventajas que ofrecen frente a otras existentes en el mercado

3. 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 base, configuración y perfiles de los equipos de trabajo para cada una de las líneas de trabajo y servicios a prestar. Si se propone factoría de software, descripción detallada y cumplimiento de las condiciones expresadas en este Pliego: recursos humanos y su dedicación a este proyecto, instalaciones, infraestructura, comunicaciones, seguridad, etc.

4. Plan de Trabajo

Descripción del plan de trabajo detallado para desarrollar las tareas solicitadas, en el plazo de tiempo establecido y con la garantía de calidad requerida. Este plan de trabajo deberá detallar actividades y tareas, las fases e hitos, presentando su calendario de ejecución y diagrama de tiempo.

5. Control y Seguimiento del proyecto

Se describirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.

6. Metodología Se describirá la Metodología seguida por el licitador para el desarrollo de proyectos de estas características.

7. Calidad.

Se describirá las medidas de calidad propuestas por el licitador. 8. Información Económica

La empresa deberá desglosar su oferta detallando por cada fase en los siguientes aspectos:

• Recursos dedicados al proyecto, identificando su categoría profesional. • Horas dedicadas por cada categoría profesional. • Precio por hora de cada categoría profesional.

El resultado de sumar todos los conceptos aquí desglosados deberá ser igual al precio total ofertado.


8 PROPIEDAD DE LOS PRODUCTOS ENTREGADOS Todos los estudios y documentos, así como los productos y subproductos elaborados por el suministrador como consecuencia de la ejecución del contrato serán propiedad de Osakidetza , quien podrá reproducirlos, publicarlos y divulgarlos, total o parcialmente, sin que pueda oponerse a ello el suministrador autor material de los trabajos. El suministrador renuncia expresamente a cualquier derecho que sobre los trabajos realizados como consecuencia de la ejecución del contrato pudieran corresponderle, y no podrá hacer ningún uso o divulgación de los estudios y documentos utilizados o elaborados en base a este pliego de condiciones, bien sea en forma total o parcial, directa o extractada, original o reproducida, sin autorización expresa de Osakidetza .


9 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 tenga acceso con motivo de la 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 los 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. Adicionalmente y como condición general, todos los servicios prestados deberán contar con las medidas de seguridad y de confidencialidad adecuadas al grado de sensibilidad de la información suministrada, de acuerdo con lo descrito en la LOPD.


10 PRESUPUESTO Y PLAZOS

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

• Presupuesto máximo asignado : (SIN IVA) 175.000€ (CON IVA 21%) 211.750€

La valoración económica esta expresada en Euros, es máxima e incluye la totalidad de los conceptos devengables. La suma total de los conceptos anteriormente señalados no podrá exceder del precio de licitación total. Se deberán detallar claramente en la oferta económica el Precio unitario/jornada por categoría ofertada. 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”.

10.2 Plazos El plazo de ejecución será de 1 año desde la fecha de formalización del contrato.

10.3 Facturación Se facturará mensualmente.


11 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 los servicios 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:

• CALIDAD TÉCNCIA .................................. .......................................................... 45

� Descripción del contenido de los trabajos : Estrategia propuesta para abordar el servicio de mantenimiento y descripción detallada de los servicios incluidos en las líneas de trabajo requeridas .................... 20

� Medios adscritos para la ejecución del contrato : Descripción detallada del equipo de trabajo y medios físicos (infraestructuras, herramientas) propuestas ......................................................................... 25

• GESTIÓN DE PROYECTO ................................................................................... 20

� Planificación de actividades: Plan de trabajo contenido e hitos ............. 10

� Control y seguimiento del proyecto : Mecanismos y procedimientos de control del proyecto ...................................................... 10

Umbral mínimo de la suma de los 2 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:

• PRECIO DE LA OFERTA ............................. ...................................................... 35 El precio menor recibirá 35 puntos y el resto proporcionalmente aplicando la siguiente fórmula:

Precio Mínimo ---------------------------------- x 35

Precio Ofertado

No obstante las ofertas que supongan bajas superiores al 25%, podrán ser consideradas ofertas desproporcionadas o temerarias, a los efectos del artículo 86.3 de la Ley de Contratos de las Administraciones Públicas (Texto Refundido).


Comité de expertos

Susana Iglesias Tamayo Maite Cuadrado Zubizarreta Nicolás González López


12 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


13 ANEXO I. CUESTIONARIO DE PERSONAL Este formulario se deberá cumplimentar por cada profesional propuesto, junto con su curriculum vitae. Empresa licitante: Profesional: Categoría ofertada:

Antigüedad

Empresa Categoría F. Alta F. Baja Actividad

Informática

Titulación Académica

Título académico Centro Años

Fecha Expedición TIC S/N

Experiencia en proyectos

Nombre proyecto Perfil (*1) F. Inicio F. Fin Categoría

Entidad Usuaria Funcionalidad (*2) Tecnología (*2)

Contenido del Trabajo

(*1) En un mismo proyecto, puede haber trabajado en diferentes perfiles. (*2) Funcionalidad y Tecnología se refiere a los módulos funcionales y tecnologías con los que ha trabajado por cada proyecto

contratación del mantenimiento de la plataforma · pdf file... (seguridad paciente) ......

Documents