Contratación del Mantenimiento de la plataforma Osakidetza Business Intelligence OBIo02VerDocumentoTramiteServlet Página 1/37
Í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 OBIo02VerDocumentoTramiteServlet Página 2/37
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 OBIo02VerDocumentoTramiteServlet Página 3/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 Especializada 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 OBIo02VerDocumentoTramiteServlet Página 4/37
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 OBIo02VerDocumentoTramiteServlet Página 5/37
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 Hechos Estrellas Indicadores Dimensiones información 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 OBIo02VerDocumentoTramiteServlet Página 6/37
Actividad Clínica Osabide Global 548 10 11 77 Farmacia Hospitalaria e-osabide, 506 9 87 88 Vademecum Consultas Externas e-osabide 1320 6 115 58 Anatomía patológica Vitro 212 3 11 33 Diagnósticos y e-osabide 133 2 0 23 Procedimientos (Archivo) Urgencias e-osabide, 597 2 35 100 Osabide Global Radiología PACS Impax 212 3 11 39 Indicadores online WS e-osabide 77 2 24 8 Camas e-osabide, WS e- 49 3 12 4 Osabide 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 Hechos Estrellas Dimensiones información Analíticas Osabide AP 145 1 22 Anamnesis Osabide AP 135 1 11 OBIo02VerDocumentoTramiteServlet Página 7/37
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 - Osarean 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 OBIo02VerDocumentoTramiteServlet Página 8/37
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 Hechos Estrellas Dimensiones información 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. OBIo02VerDocumentoTramiteServlet Página 9/37
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 Indicadores Dimensiones información 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. OBIo02VerDocumentoTramiteServlet Página 10/37
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 HFT Sistemas origen información Presbide, Dtp. Sanidad Indicadores Estrellas Dimensiones 4 1 312 OBIo02VerDocumentoTramiteServlet Página 11/37
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 Osakidetza, 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: OBIo02VerDocumentoTramiteServlet Página 12/37
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 OBIo02VerDocumentoTramiteServlet Página 13/37
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 Documentació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 OBIo02VerDocumentoTramiteServlet Página 14/37
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. OBIo02VerDocumentoTramiteServlet Página 15/37
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 Osakidetza 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 Desarrollo Preproducción Producción Tareas Construcción y Pruebas unitarias Pruebas integradas, Pruebas de usuario y Formación Producción El Modelo de Arquitectura utilizado se encuentra compuesto de las áreas mostradas en el siguiente diagrama:. OBIo02VerDocumentoTramiteServlet Página 16/37
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. OBIo02VerDocumentoTramiteServlet Página 17/37
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 Desarrollo Preproducción Producción Tareas Construcción y Pruebas unitarias Pruebas integradas, Pruebas de usuario y Formación Producción El Modelo de Arquitectura utilizado se encuentra compuesto de las áreas mostradas en el siguiente diagrama: OBIo02VerDocumentoTramiteServlet Página 18/37
ENTORNO DE PREPRODUCCIóN NAVEGADORES: Internet explorer 6.X Internet explorer 7.0, Firefox 1.5.X, Firefox 2.0 PC CLIENTE USUARIOS Acceso web a la URL: http://<maquina_servidor_web>:8080/analytics Acceso web a la URL: http://<maquina_servidor_web>:8080/analytics Servidor Web: Apache Tomcat Maquina_Servidor_Web Máquina_LDAP Acceso PC CLIENTE INFORMATICA Herramientas Instaladas: OBIEE Cliente: Administrator OWB Cliente: Designer Center Acceso Acceso Acceso a la Base de Datos Máquina OBIEE Instalado: BI Server, BI Scheduler BI Presentation Server Acceso Servidor de Correo SMT Sever Acceso via Data Base link Base de Datos DW Atención Primaria Base de Datos Stand by Producción. Modelo físico Repositorio de OWB 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 OBIo02VerDocumentoTramiteServlet Página 19/37
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: OBIo02VerDocumentoTramiteServlet Página 20/37
CODIGO-NOMBRE IVR IVR Carpeta Salud Consejo Sanitario OsabideAP CRM Siebel IVR Cita Web IVR Consejo Sanitario COMENTARIO Información del IVR relativa a número de llamadas, tipo de fin de la llamada, transferencias a centros y encuesta de satisfacción. Actividad de los agentes virtuales del IVR. Trazas de actividad registradas en Carpeta de Salud. Trazas de actividad registradas en Consejo Sanitario. Citas registradas en Osabide AP desglosadas por fecha, centro de salud, canal de registro, tipo de cita, edad etc. Información del estado de las campañas en marcha en CRM. Información de llamadas recibidas en el call center, llamadas recibidas en IVR y llamadas rechazadas por saturación. Resultados de la encuesta de satisfacción del servicio de cita web. Número de llamadas al IVR rechazadas por saturación de canales primarios. 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 especificaciones: las siguientes 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 OBIo02VerDocumentoTramiteServlet Página 21/37
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. OBIo02VerDocumentoTramiteServlet Página 22/37
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. OBIo02VerDocumentoTramiteServlet Página 23/37
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 publicació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. OBIo02VerDocumentoTramiteServlet Página 24/37
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. OBIo02VerDocumentoTramiteServlet Página 25/37
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. OBIo02VerDocumentoTramiteServlet Página 26/37
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 Central de Osakidetza, ubicada en Vitoria-Gasteiz. OBIo02VerDocumentoTramiteServlet Página 27/37
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 OBIo02VerDocumentoTramiteServlet Página 28/37
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 OBIo02VerDocumentoTramiteServlet Página 29/37
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. OBIo02VerDocumentoTramiteServlet Página 30/37
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. OBIo02VerDocumentoTramiteServlet Página 31/37
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. OBIo02VerDocumentoTramiteServlet Página 32/37
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. OBIo02VerDocumentoTramiteServlet Página 33/37