Contract
PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN MEDIANTE PROCEDIMIENTO ABIERTO PARA LA PUESTA A DISPOSICION DE PRODUCTOS Y EQUIPOS NECESARIOS PARA REALIZAR PRUEBAS DE ANALISIS CLINICOS DE RUTINA Y URGENCIA DE LA OSI ARABA y DE LA OSI ALTO DEBA.
1.- ANTECEDENTES
La Unidad de Gestión Clínica (UGC) de los Laboratorios xx Xxxxx, forma parte de la Red de Diagnóstico Biológico de Osakidetza (RDBO).
En este contexto, se propone la contratación corporativa de los reactivos y equipos necesarios para la realización de pruebas analíticas urgentes y ordinarias para la mencionada UGC.
.
El presente documento consta de los siguientes Anexos. ANEXO I Prescripciones técnicas de los laboratorios.
ANEXO II Características técnicas y actividad anual prevista.
ANEXO III Prescripciones técnicas relativas al desarrollo informático. ANEXO IV Ley de Protección de datos de carácter personal.
ANEXO V Criterios de valoración y puntuación. ANEXO VI Atención a usuarios y prestación de servicio
Documento informativo de Directrices y especificaciones técnicas informáticas
2.- OBJETO DEL CONTRATO
El objeto del presente contrato consiste en la puesta a disposición, mediante procedimiento abierto, de los productos y equipos necesarios, en régimen de cesión, para el procesamiento automático de pruebas analíticas urgentes y ordinarias en los laboratorios de la UGC xx Xxxxx: Laboratorios xxx XXX (Laboratorio central, Laboratorios de Urgencias xxx XXX Sede Txagorritxu y xxx XXX Sede Santiago) y el laboratorio de respuesta hospitalaria (LRH) del HAD.
3.- DEFINICIÓN DEL CONTRATO
A efectos de este pliego, las pruebas analíticas susceptibles de ser realizadas en los laboratorios xxx XXX o en el LRH del HAD son especificadas en el Anexo II. Los licitadores estarán obligados a ofertar, como mínimo, el 99% de las técnicas objeto del presente contrato
Las prescripciones técnicas de estos laboratorios están especificadas en el Anexo I. El adjudicatario deberá:
Poner a disposición de Osakidetza el equipamiento, la tecnología y los sistemas de información para su gestión, en régimen de disponibilidad, además de los consumibles necesarios para la realización de todas aquellas pruebas analíticas relacionadas en el Anexo II.
La actividad de los laboratorios indicada en el Anexo II se facilita a título orientativo, con el fin de que las empresas licitantes puedan dimensionar el equipamiento adecuado para los Laboratorios. La empresa adjudicataria se compromete a adecuar el equipamiento ofertado inicialmente, para adaptarse a las necesidades que pudieran derivarse de cambios en la actividad, durante el periodo de vigencia del contrato.
Instalar y mantener el equipamiento, la tecnología, los sistemas de información, así como el material necesario, para que el personal técnico de los Laboratorios de la UGC xx Xxxxx lleve a cabo todas las actividades y tareas que precisen los procesos analíticos descritos en el objeto del concurso.
El licitador deberá incluir en su oferta los equipos con los niveles más actualizados tecnológicamente que disponga en el momento de la propuesta.
Instalar y mantener el equipamiento, la tecnología y el Middleware necesario para la gestión del proceso analítico, así como dotar del material preciso, para que el personal de los Laboratorios de la UGC Araba incorporen al sistema de información del laboratorio los resultados analíticos y la información generada, por vía electrónica de acuerdo a las necesidades de los hospitales incluidos y de Osakidetza,
Actualmente el sistema informático es OMEGA 3000 de la empresa ROCHE. A lo largo del periodo de ejecución del contrato está previsto que el sistema informático migre al nuevo sistema informático corporativo GESTLAB.
Instalar, si fuera necesario, los equipos adecuados para el tratamiento y acondicionamiento del agua necesaria para el funcionamiento de los Laboratorios. Los gastos de mantenimiento, recambios y fungibles para los sistemas de tratamiento y acondicionamiento del agua, serán a cargo de la empresa adjudicataria.
Ofertar equipos en redundancia, siempre que sea necesario, para asegurar el servicio ante incidencias en los Laboratorios de la UGC xx Xxxxx.
Asegurar la renovación tecnológica durante el periodo de vigencia del presente contrato.
Hacerse cargo de los reactivos y materiales para la puesta a punto de las técnicas y el acondicionamiento de los equipos, anterior a la puesta en producción de los analizadores y resto de equipos. Así mismo, será a cargo del adjudicatario el consumo de reactivos, controles, calibradores, y todos aquellos elementos necesarios para el mantenimiento preventivo y correctivo.
Dotar a los Laboratorios con el equipamiento adecuado que permita cumplir con los tiempos máximos de respuesta urgente, preferente y ordinaria que considere la dirección de la los Laboratorios de la UGC Araba, y que podrán ser auditados por la comisión de control de este contrato.
En todas las instalaciones, en función del calor y ruido que generen los equipos y elementos auxiliares ofertados, el adjudicatario aportará los medios necesarios que garanticen el óptimo funcionamiento de los equipos y confort de la sala de trabajo. Aquellos elementos auxiliares de los equipos que sean susceptibles de generar ruido, vibración y aumento de temperatura, deberán colocarse en un cuarto técnico adecuado para albergarlos siempre que sea posible.
4.- OTRAS CONDICIONES DEL ADJUDICATARIO
4.1.- Formación
La entidad adjudicataria, previa conformidad de la dirección de los Laboratorios, determinará el programa formativo a seguir por el personal. La formación que se considere necesaria será financiada por el adjudicatario.
Cualquier modificación en los equipos conllevará un periodo de formación del personal en los mismos términos señalados en el párrafo anterior.
4.2.- Indicadores gestión clínica
El adjudicatario deberá permitir y facilitar, a la dirección de los Laboratorios de la UGC Araba, el acceso permanente a las aplicaciones informáticas y sistemas de información empleados para la prestación del servicio. Sin perjuicio de lo anterior, los licitadores deberán proponer los sistemas de información que permitan realizar un seguimiento continuado de indicadores, la detección de los fallos y la aplicación de medidas correctoras, así como su evaluación externa por parte de la los Laboratorios de la UGC Araba o de personas o entidades en la que deleguen. Los indicadores deberán estar integrados en el sistema de información de Gestión Clínica que los Laboratorios de la UGC Araba utilicen.
La adjudicataria deberá poner a disposición de los Laboratorios de la UGC Araba todos los datos relativos a rendimientos de cada una de las pruebas para facilitar el análisis relativo a los mismos.
4.3.- Calidad
4.3.1.- Obligaciones generales
El adjudicatario estará obligado a que el objeto del contrato responda a los umbrales de calidad que determine la dirección de los Laboratorios de la UGC Araba.
Se debe incluir en la oferta materiales y programas de control de calidad internos, a elegir entre uno propio y otro de reconocido prestigio por los Laboratorios de la UGC Araba. Así como controles de calidad externos para todas las metódicas y equipos, que correrán a cargo del adjudicatario y serán también elegidos por los Laboratorios de la UGC Araba.
Todo el material y equipamiento ofertado deberá de disponer del marcado CE. 4.3.2.- Protocolos y Procedimientos de actuación
Con carácter enunciativo y no limitativo, la entidad adjudicataria deberá disponer y mantener actualizado la siguiente documentación:
Manual de procedimientos (en idioma español):
Contendrá actualizados, al menos, los siguientes procedimientos:
Procedimientos normalizados de los equipos en formato electrónico que detallen los métodos y protocolos que se utilizarán, con su fundamento, la descripción de la preparación de reactivos o medios, la realización de las técnicas, los métodos de medida y los instrumentos necesarios.
Tratamiento y protección de datos, sistema de archivo y manual actualizado del sistema informático, así como un documento de procedimientos y medidas de seguridad de obligado cumplimiento para el personal con acceso a los datos de carácter personal en el que se establezcan las medidas, normas y procedimientos encaminados a garantizar el nivel de seguridad exigido en la normativa vigente con especial referencia a las medidas exigibles en el nivel alto de protección de datos.
4.4.- Plan de diseño de instalaciones y equipamiento del laboratorio
Los licitadores deberán elaborar, en los términos previstos en el PCAP, un plan de diseño de instalaciones y equipamientos de los laboratorios
El Plan de diseño de instalaciones y equipamientos contendrá una memoria desarrollada que explique y justifique la solución propuesta, tanto en relación con la estructura como atendiendo a las instalaciones y su funcionalidad.
Asimismo, aportará:
Planos: que expresen las soluciones propuestas, esquemas de principio, diagramas de recorridos y sistemas. Se desarrollarán las diversas instalaciones con la localización de los elementos que lo componen. En cualquier caso los planos cumplirán la normativa vigente de protección contra incendios.
Perspectivas foto-realistas del conjunto y cuanta información gráfica quiera añadir el licitador para la mejor comprensión de la propuesta.
4.5.- Puesta en marcha
Los licitadores deberán elaborar, en los términos previsto en el PCAP, un plan de puesta en marcha de los Laboratorios de la UGC xx Xxxxx y el LRH del HAD, que incluya todas las áreas y contendrá los aspectos recogidos en el apartado 8.8. de este Pliego.
La empresa adjudicataria deberá realizar los trabajos que requiera la instalación de los equipos para el correcto funcionamiento final. La instalación del aparataje, instrumentación y/o dispositivos ofertados por el/los adjudicatario/s se realizarán bajo la supervisión y directrices de los servicios técnicos de cada hospital. Se entiende que los equipos serán suministrados con todos aquellos dispositivos o elementos de interconexión, accesorios de anclaje o fijación necesarios para un total y correcto funcionamiento, con la obligación de retirar los elementos de embalaje así como los equipos a los que sustituyan, en caso de ser necesario.
La instalación y la puesta en marcha de los equipos serán siempre previas a la entrega del reactivo, es decir, con productos sin cargo para el hospital.
Los trabajos de instalación de equipos, instrumentación y/o dispositivos, serán por cuenta del adjudicatario, incluyendo la adecuación de espacios e instalaciones necesarias para el correcto funcionamiento de los equipos.
Los plazos de entrega e instalación de los equipos y plazos de formación del personal que vaya a utilizar los equipos se establecerán en coordinación con la Dirección de la UGC.
Serán excluidas todas aquellas ofertas que no se comprometan a poner en funcionamiento la instalación en un plazo de tres meses a partir de la fecha de la firma del contrato.
4.6.- Rendimientos de los reactivos
Las empresas licitadoras incluirán en su oferta el rendimiento garantizado para cada prueba, en las condiciones de trabajo de los Laboratorios y según volumen de actividad orientativo indicado en el Anexo II.
El rendimiento se expresará en porcentaje y se calculará mediante la siguiente fórmula: Rendimiento= (pruebas validadas clínicamente / pruebas consumidas) x 100%.
Los rendimientos mínimos aceptables por laboratorio serán:
Para más de 100.000 pruebas anuales, rendimiento superior al 98,5%. Entre 50.000 y 100.000 pruebas anuales, rendimiento superior al 97,5%. Entre 30.000 y 50.000 pruebas anuales, rendimiento superior al 95%.
Entre 5.000 y 30.000 pruebas anuales, rendimiento superior al 92,5%. Entre 2.000 y 5.000 pruebas anuales, rendimiento superior al 90%.
Con carácter mínimo semestral se revisará el rendimiento para cada prueba. En los casos que los rendimientos sean inferiores a los establecidos, la empresa adjudicataria abonará el importe de los reactivos adicionales para cubrir la diferencia, siempre y cuando el bajo rendimiento no sea debido al mal uso de los reactivos o del equipamiento por parte de los Laboratorios.
Las empresas licitadoras deberán incluir en sus ofertas su compromiso en este sentido. 4.7.- Servicio técnico
El adjudicatario se encargará del mantenimiento y reparación de los equipos durante el periodo de vigencia del contrato, así como, a actualizar y/o reponer los mismos en el supuesto de cambio o mejora tecnológica, sin coste adicional.
El mantenimiento incluido en la oferta comprenderá todas las actuaciones de mantenimiento preventivo, correctivo y normativo.
La sustitución de los componentes de los aparatos, sean considerados consumibles o no (lámparas, jeringas, pipetas, etc.) que forman parte del equipo y son imprescindibles para su funcionamiento se realizará de acuerdo con el adjudicatario y todo ello no supondrá coste adicional alguno para el hospital.
El adjudicatario deberá disponer de un especialista técnico in situ dedicado que apoye al personal del centro en la puesta en marcha de técnicas, configuración de los sistemas, resolución de incidencias y formación del personal.
4.8.- Infraestructura auxiliar
El licitador deberá de proveer de la siguiente infraestructura auxiliar para dar soporte al sistema:
Los licitadores deberán ofertar un sistema xx xxxxxxx automatizado para la gestión física e informática de los reactivos, que permita disponer en el laboratorio a tiempo real de un control exacto de existencias y caducidades para productos conservados a temperatura controlada (frío y temperatura ambiente).
En la oferta se incluirá para el laboratorio CORE, un sistema que permita la gestión del serotecado de todas las muestras. La seroteca incluirá muestras por tiempo indefinido (- 80ºC) o temporal (-20º), estas últimas por un tiempo no inferior a 1 año. En cada seroteca se incluirán las muestras que así lo precisen según las características clínico- epidemiológicas del paciente y tendrán siempre un carácter clínico-asistencial.
Sistema de gestión de los residuos generados cumpliendo la normativa vigente.
Consultoría para la optimización de los procesos y adecuación de los espacios de los laboratorios para garantizar la máxima funcionalidad. La adecuación de los espacios correrá a cargo del adjudicatario.
Adecuación de las instalaciones de fontanería y conexiones eléctricas e informáticas necesarias.
4.9.- Finalización del contrato
Una vez finalizado el contrato, los equipos deberán ser retirados por el adjudicatario, en un plazo no superior a 6 semanas.
5.- DESARROLLO INFORMATICO
Las prescripciones técnicas relativas al desarrollo informático son las que se especifican en el Anexo III de este Pliego.
6.- COMISION DE CONTROL Y EVALUACIÓN DE LA GESTIÓN DEL PRESENTE CONTRATO:
El órgano de contratación, o la persona en quien delegue, y sin perjuicio de las facultades inspectoras de la Administración Sanitaria, podrá inspeccionar los servicios, instalaciones, locales, así como toda la documentación relacionada con el objeto del contrato. Para ello, la adjudicataria deberá facilitar la realización de sus tareas inspectoras, poniendo a su disposición cuanta información y documentos sean necesarios, así como facilitando el acceso a todas las dependencias e instalaciones.
Asimismo, el órgano de contratación nombrará una comisión técnica de control de toda la actividad relacionada con el objeto del presente contrato. Dicha comisión podrá plantear la realización de cuantas auditorias considere oportunas en orden a la verificación del objeto del contrato. También dicha comisión será la responsable de realizar las comprobaciones que estime pertinentes con el objeto de verificar las posibles
discrepancias entre las cantidades físicas de cada producto necesarias para la realización de una prueba analítica, y que el proveedor debe reflejar en su oferta técnica, y la cantidad que efectivamente resulte necesaria para la ejecución del contrato.
7.- PROTECCIÓN DE DATOS
El adjudicatario está obligado expresamente al cumplimiento de lo establecido en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal y en el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal y demás legislación concordante con respecto al tratamiento de los datos personales contenidos en los ficheros inscritos por el HUA, el HAD y el Departamento de Sanidad y Consumo, Osakidetza, y sus Organizaciones de Servicios en la Agencia Vasca de Protección de Datos, así como a las exigencias recogidas en la Ley 14/1986, de 25 xx xxxxx, General de Sanidad, a las incluidas en la Ley 41/2002, de 14 de noviembre, básica reguladora de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica y a las relacionadas en la Ley 33/2011, de 4 de octubre, General de Salud Pública.
El adjudicatario se compromete a tratar dichos datos personales observando los principios exigibles por la legislación en materia de protección de datos, en particular los relativos a la calidad de los datos, seguridad de los mismos y deber xx xxxxxxx, así como a cumplir las instrucciones recibidas de la Organización Central de Osakidetza, xxx XXX, del HAD o del Departamento de Sanidad y Consumo, no aplicando o utilizando dichos datos con finalidad distinta a las especificadas.
El adjudicatario deberá observar el secreto profesional respecto de los datos personales objeto de tratamiento, manteniendo absoluta confidencialidad y reserva sobre cualquier dato que pudiera conocer con ocasión del cumplimiento de los servicios prestados, no comunicando a ningún tercero, ni siquiera para su conservación, los datos facilitados por el Departamento de Sanidad y Consumo, Osakidetza, el HUA, el HAD y otras Organizaciones de Servicios como responsables del fichero. Esta obligación subsistirá aún después de finalizar sus relaciones con el titular del fichero o, en su caso, con el responsable del mismo.
En el supuesto de que el adjudicatario, como encargado del tratamiento, destine los datos a finalidad distinta a la estipulada, los comunique o utilice incumpliendo las instrucciones fijadas en el presente contrato, será también considerado responsable del tratamiento, respondiendo de las infracciones en que hubiese incurrido. El adjudicatario como encargado del tratamiento se compromete a la observancia de las medidas de seguridad
correspondientes al tratamiento de los datos personales xxx XXX, del HAD del Departamento de Sanidad y Consumo, de Osakidetza y de sus Organizaciones de Servicios a los que tuviere acceso, de acuerdo al nivel de protección que corresponda a los datos facilitados según lo establecido en el Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica15/1999, de 13 de diciembre, de protección de datos de carácter personal, o en cualquier otra norma que lo sustituya o modifique.
El adjudicatario, una vez cumplida la responsabilidad contractual, se compromete a devolver al HUA, al HAD al Departamento de Sanidad y Consumo, a Osakidetza y a sus Organizaciones de Servicios, los datos objeto del tratamiento, soportes o documentos en que éstos consten, así como a destruir aquellos según instrucciones del responsable del tratamiento.
Las prescripciones relativas a protección de datos, además de las anteriores, son las que se especifican en el Anexo IV de este Pliego.
8.- DOCUMENTACIÓN TÉCNICA A PRESENTAR POR LOS LICITADORES
Se deberá aportar toda la documentación en formato normalizado Office (Word y/o pdf) y AutoCad.
Con independencia de que el licitador o licitadores puedan presentar en su oferta cuanta información complementaria consideren de su interés, deberán presentar la exigida en cualquier apartado de este Pliego y, además la siguiente:
8.1.- Equipos y medios materiales para la prestación del suministro
Las empresas licitadoras incluirán en su oferta las especificaciones de los equipos ofertados indicando su número y características técnicas detalladas.
Características de las técnicas ofertadas y los rendimientos garantizados de los reactivos, Tecnología y funcionalidad del equipamiento propuesto.
Características de la gestión de los reactivos.
Gestión del mantenimiento de los equipos por el usuario.
Listado de conexiones actualmente disponibles de analizadores de otras empresas a las soluciones de automatización ofertadas (cadena robótica)
8.2.- Servicios logísticos
Características técnicas del material, ficha técnica o ruta informática de acceso al mismo.
Sistema de aseguramiento de la trazabilidad, la seguridad y las condiciones adecuadas en los envíos (tiempo de respuesta, mantenimiento de la cadena de frío,..).
Disponibilidad de sistemas automáticos o semiautomáticos de gestión y almacenamiento de reactivos.
8.3.- Sistemas de información
Deberán explicitarse los medios propuestos para la realización de todas las obligaciones recogidas en el Anexo III de este Pliego relativo al desarrollo Informático.
La planificación, organización del servicio, soporte de usuarios y niveles de acuerdo de servicio.
Funcionalidad y prestaciones del sistema informático. La solución de hardware adoptada.
La estrategia de integración con los sistemas de información existentes.
8.4.- Pruebas adicionales
Las empresas licitadoras deberán incluir en su oferta una relación de todas las pruebas no relacionadas en el Anexo II que podrían realizarse en los mismos equipos Estas pruebas deberán estar valoradas económicamente unitariamente, a título informativo, en la oferta económica.
8.5.- Servicio técnico
El adjudicatario proveerá de un plan de asistencia técnica personalizado para los Laboratorios de la UGC xx Xxxxx con los requerimientos mínimos expresado en el Anexo
VI. Este plan deberá detallar: recursos humanos, medios tecnológicos, horarios, tiempos de respuesta y tipos de soporte a disposición de la unidad.
8.6.- Servicio mantenimiento
El adjudicatario proveerá de un plan de formación al personal sobre los equipos y sistemas que será continuado en el tiempo.
8.7.- Infraestructura auxiliar
El proyecto técnico de instalaciones auxiliares y el de agua desmineralizada con las redundancias necesarias para garantizar un funcionamiento ininterrumpido 24 horas 365 días al año.
El proyecto de almacenamiento y gestión de los stocks, incluida la posibilidad de robotización del mismo, y su conexión con el sistema SAP.
Descripción de la consultoría para la optimización de los procesos y la adaptación de los espacios a las necesidades funcionales.
8.8.- Puesta en marcha
El adjudicatario aportará:
El plan de apertura: actuaciones y cronograma para la puesta en funcionamiento del servicio objeto del contrato.
Las fases de aceptación de los nuevos equipos: los plazos de instalación, sus verificaciones así como las pruebas de calibración.
En el supuesto de que las empresas licitadoras no presenten la documentación técnica con la información requerida, y la forma de presentación no sea la solicitada, la oferta técnica no será evaluada y, por lo tanto, se rechazará.
9.- MUESTRAS
No es necesaria la entrega de muestras.
10.- VARIANTES
No se admitirán variantes.
11.- PRESUPUESTO BASE DE LICITACIÓN
11.1. Presupuesto base de licitación Los precios unitarios de licitación se establecen para la unidad de medida fijada, precio prueba.
A todos los efectos el número de pruebas previsto es estimativo, estando sujeto al gasto efectivo que vendrá condicionado por las necesidades reales derivadas de la actividad asistencial de Osakidetza, y por tanto no se considera elemento esencial del contrato. Osakidetza, por tanto, no queda obligada a la demanda de una determinada cuantía de pruebas, ni a gastar la totalidad del presupuesto.
A todos los efectos se entenderá que el precio unitario estimado como máximo por Osakidetza comprende todos los gastos directos e indirectos que el contratista debe realizar para la normal ejecución del contrato, y toda clase de tasas, impuestos (excepto IVA) y licencias.
11.2. Obligatoriedad de licitar a lote completo: Si
11.3. Posibilidad de licitar por artículos dentro de un mismo lote: No
11.4. Revisión de precios: No
11.5 Previsión de modificación: Sí. Se prevé que pueda incrementarse el consumo total en un importe del 25%.
Dicha modificación será justificada en caso de producirse un incremento de la actividad estimada a causa del aumento de las necesidades asistenciales en relación con el objeto del contrato.
11.6. Forma de pago: La facturación se realizará en base al suministro realizado.
12.- PRESUPUESTO ESTIMADO A EFECTOS DE PUBLICIDAD
Importe estimado total de licitación IVA excluido (4 años contrato inicial) | 9.827.065,86€ |
Valor estimado modificaciones (25%) IVA excluido | 2.456.766,47€ |
Valor estimado prórrogas IVA excluido (1 prórroga de 2 años) | 4.913.532,93€ |
Valor estimado total de contratos IVA excluido (contrato inicial + modificaciones + prórrogas) | 17.197.365,26€ |
13.- PROCEDIMIENTO DE ADJUDICACIÓN
13.1. Procedimiento: Abierto
13.2. Tramitación: Ordinaria
14.- CRITERIOS DE ADJUDICACION
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 presente documento a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para el suministro objeto de este expediente.
En caso de que, de la aplicación de los criterios de adjudicación se derivase un empate de puntuaciones, éste se dirimirá a favor de la oferta que hubiera obtenido mayor puntuación en la valoración técnica. De persistir el empate, se atenderá a las valoraciones en el criterio precio.
14.1. Criterios basados en Juicios de Valor Características Generales 20 puntos
Valoración técnica de las ofertas: 20 puntos Metodología utilizada: Ver Anexo V, apartado A
. Criterios basados en juicios de valor Características Específicas 30 puntos
Valoración técnica de las ofertas: 30 puntos Metodología utilizada: Ver Anexo V, apartado B
Existirá un umbral mínimo por la suma de puntuación obtenida por el cumplimiento de criterios técnicos: 25 puntos sobre 50. Las ofertas deberán superar este umbral para continuar en el proceso de licitación.
14.2. Criterios económicos basados en Fórmulas 50 puntos
PRECIO: Precio: 45 puntos
Se valorará con 0 puntos aquella empresa que no realice bajada con respecto al precio de licitación.
Puntuación del resto de ofertas = según la siguiente fórmula (teniendo en cuenta un máximo de dos decimales).
4 Porcentaje de bajada de oferta a valorar
Puntuación obtenida = 45 ∗ J Porcentaje de bajada de la nejor oferta
MEJORA ECONÓMICA SOBRE EL PRECIO DE OFERTA INICIAL POR INCREMENTO DE ACTIVIDAD GLOBAL: 5 PUNTOS
Compromiso del licitador consistente en la bonificación sobre los incrementos de actividad global que iguala o supera el 5% de crecimiento (Sí: 5 puntos; No: 0 puntos)
-A incrementos de actividad entre 5% - 7% se aplicará una bonificación del 4% sobre el exceso total de la facturación anual
-A incrementos de actividad entre 7.1% - 10% se aplicará una bonificación del 6% sobre el exceso total de la facturación anual
-A incrementos de actividad superiores al 10% se aplicará una bonificación del 7% sobre el exceso total de la facturación anual.
15.- NÚMERO MÁXIMO DE ADJUDICATARIOS POR XXXX
Único adjudicatario.
16.- GARANTÍAS PARA LA FORMALIZACIÓN CONTRATO
Provisional: No se requiere. Definitiva: 5% de licitación
17.- PLAZO DE GARANTÍA
Durante la vigencia del contrato
18.-PLAZO DE EJECUCION DEL CONTRATO
Plazo de ejecución inicial del contrato: Cuatro años. El contrato entrará en vigor desde la fecha de su formalización.
Prórrogas: Sí. Una prórroga por periodo de dos años.
Plazo total de ejecución (inicial más prórrogas): Hasta seis años.
19.- LUGAR Y ENTREGA DEL SUMINISTRO
El contratista estará obligado a entregar los bienes objeto del suministro en el lugar que se designe por Osakidetza.
20.- DOCUMENTACION A INCLUIR EN LOS SOBRES
20.1. EN EL SOBRE C (CRITERIOS BASADOS EN JUICIOS DE VALOR)
Es recomendable que la documentación que se presente esté adecuadamente archivada y ordenada, teniendo en cuenta y siguiendo el sistema de puntuación establecido y acompañada de un índice temático al objeto de facilitar la revisión de las propuestas y agilizar el proceso de valoración de las mismas. Asimismo, toda la información aportada deberá ir en formato digital.
Se adjuntará toda la documentación que justifique el cumplimiento de los criterios técnicos solicitados especificándose la página de la oferta técnica en la que se hace referencia al mismo. (Anexo V).
Se podrá, asimismo, incorporar otra documentación sobre características no requeridas, con objeto de cumplimentar un mejor conocimiento de la oferta presentada. Éstas deberán ser recogidas en un capítulo aparte consignando como “otra documentación incorporada”.
Los catálogos y folletos vendrán en castellano, o debidamente traducidos.
Aparte de la documentación requerida en el presente pliego se cumplimentará el Cuadro de Ofertas Técnicas que deberá descargarse del perfil del contratante, donde se especificarán el nombre comercial, cada una de las referencias que se oferten y número de pruebas por envase, código EAN del envase de venta y el Rendimiento por prueba. Deberá estar firmado por el apoderado y se presentará en doble soporte: papel y digital, formato EXCEL (no PDF).
En caso de discrepancia entre los datos de los modelos en papel, con los del formato digital, prevalecerán aquellos en papel.
20.2. EN EL SOBRE B (CRITERIOS BASADOS EN FORMULAS)
Se cumplimentará el Modelo de Proposición Económica, que deberá descargarse del perfil del contratante junto con el resto de documentación administrativa del expediente. Deberá estar firmado por el representante legal de la empresa y se presentará en doble soporte: papel y digital.
Los precios unitarios se reflejarán a 4 DECIMALES como máximo y estará referido a la unidad de medida ofertada. De no respetarse los 4 decimales se procederá a su redondeo.
Se deberá presentar el compromiso del licitador consistente en la bonificación sobre los incrementos de actividad global
En caso de discrepancia entre los datos de los modelos en papel, con los del formato digital, prevalecerán aquellos en papel.
Aparte de la documentación requerida en el presente pliego se cumplimentará el Cuadro de Ofertas Económicas que deberá descargarse del perfil del contratante, donde se especificará el precio unitario ofertado (IVA excluido) para cada material.
Toda la documentación relativa a criterios de adjudicación valorables mediante fórmulas, deberá ser incluida en su sobre correspondiente.
Prescripciones técnicas de los laboratorios Requisitos.
ANEXO I
1.- INTRODUCCIÓN
La UGC de los Laboratorios xx Xxxxx forma parte de la RDBO y está constituida por los siguientes nodos:
Laboratorio Central ubicado en la 8ª planta del edificio de CCEE de la OSI Araba
2 Laboratorios de Urgencias ubicados respectivamente en el HUA (sede Txagorritxu y en el HUA sede Santiago).
1 Laboratorio de Respuesta Hospitalaria en el Hospital Alto Deba 1 punto de POCT en el Hospital xx Xxxx.
Las características generales para estos laboratorios son:
Calidad: las pruebas que se realicen han de cumplir holgadamente los estándares de calidad admitidos por la Comunidad Científica.
Automatización: Los laboratorios deberán disponer de equipos y sistemas de automatización en gran escala que permitan garantizar la seguridad del paciente y del profesional, una alta productividad, así como la eliminación de tareas y procesos que no aporten valor en un contexto de eficiencia.
Contexto clínico y expertización: los sistemas de información y comunicación que den soporte a los laboratorios deben garantizar que éstos se gestionen en el contexto clínico del paciente, con los protocolos y guías que se definan y que se facilite la aportación de expertos tanto al informe final como a una mejor gestión de la demanda.
1.1.- LABORATORIO CENTRAL XXX XXX
Se ubica en la planta octava del edificio del CCEE y tiene las siguientes funciones: Gestión de la fase preanalítica y postanalítica
Recepción Centrifugación Clasificación
Alicuotación y distribución de muestras Gestión de archivos de muestras Gestión de informes
Procesamiento
Informe: la validación pruebas se llevará a cabo en el área de conocimiento especializada por vía electrónica
Archivo
Gestión de las pruebas especiales de toda el área Procesamiento
Informe: la validación de pruebas se llevará a cabo en el área de conocimiento especializada por vía electrónica
Archivo
Gestión de todas las peticiones y muestras que se derivan a otros Laboratorios
1.2.- LABORATORIO URGENCIAS HUA SEDE SANTIAGO
Se ubica en la planta baja del edificio del HUA Santiago y tiene las siguientes funciones: Gestión de la fase preanalítica y postanalítica del laboratorio del HUA Santiago. Recepción
Centrifugación Clasificación
Alicuotación y distribución de muestras Gestión de archivos de muestras Gestión de informes
Gestión de todas las pruebas de respuesta rápida (tiempo de respuesta menor a 30min, salvo excepciones expresas) las 24 horas todos los días del año.
Procesamiento Informe Archivo
Gestión de todas las peticiones y muestras que se derivan al Laboratorio central
1.3.- LABORATORIO URGENCIAS HUA SEDE TXAGORRITXU
Se ubica en la planta semisótano del edificio del XXX Xxxxxxxxxxx y tiene las siguientes funciones:
Gestión de la fase preanalítica y postanalítica del laboratorio del XXX Xxxxxxxxxxx Recepción
Centrifugación
Clasificación
Alicuotación y distribución de muestras Gestión de archivos de muestras Gestión de informes
Gestión de todas las pruebas de respuesta rápida (tiempo de respuesta menor a 30min, salvo excepciones expresas) las 24 horas todos los días del año.
Procesamiento Informe Archivo
Gestión de todas las peticiones y muestras que se derivan al Laboratorio central
1.4.- LABORATORIO DE RESPUESTA HOSPITALARIA DEL HAD
Se ubica en la planta cuarta del Hospital Alto Deba y tiene las siguientes funciones: Gestión de la fase preanalítica y postanalítica
Recepción Centrifugación Clasificación
Alicuotación y distribución de muestras Gestión de archivos de muestras Gestión de informes
Gestión de todas las pruebas de respuesta rápida (tiempo de respuesta menor a 30min, salvo excepciones expresas) las 24 horas todos los días del año.
Procesamiento
Informe Archivo
Gestión de las pruebas solicitadas desde las áreas de hospitalización preferentes y ordinarias de baja complejidad
Procesamiento
Informe: la validación de pruebas se llevará a cabo en el área de conocimiento especializada por vía electrónica
Archivo
Gestión de todas las peticiones y muestras que se derivan al Laboratorio central
2. SISTEMA DE AUTOMATIZACIÓN TOTAL LABORATORIO CENTRAL
Se ofertarán sistemas de automatización total con capacidad para procesar las muestras necesarias según la cartera de servicios mencionada en los Anexos II y III y los tiempos de respuesta establecidos.
Los sistemas de automatización han de permitir crear configuraciones adecuadas a los requerimientos actuales del laboratorio y los que, derivados del incremento de la demanda, se puedan requerir en el futuro. Por tanto los sistemas han de ser configurables, o ampliables en número de módulos in situ, con mínima alteración de la rutina diaria del laboratorio.
Se solicitan dos cadenas robotizadas independientes.
La disposición física de ambas cadenas debe facilitar al máximo la funcionalidad y la comodidad para el personal.
Los sistemas deben permitir en cualquier momento la localización de muestras con fácil accesibilidad.
Los sistemas permitirán definir reglas que prioricen la entrada en determinados equipos en función de las pruebas solicitadas así como la generación de test reflejos o repeticiones basados en reglas predefinidas en los analizadores y/o en el sistema middleware de gestión.
2.1 SISTEMA DE AUTOMATIZACIÓN TOTAL ÁREA XX XXXXX
Para la realización de las magnitudes del área xx xxxxx, los licitadores ofertarán una solución global de automatización (cadena robotizada) con capacidad para conectar equipos analíticos que den respuesta a las técnicas ofertadas que se describen en el lote para dicho área.
Concretamente, esta cadena debe disponer de la capacidad de gestionar muestras xx xxxxx, plasma, orina y líquidos biológicos.
El sistema debe permitir automatizar tareas manuales poco productivas como el registro/ aceptación de los tubos, destaponado, centrifugado, carga y descarga de tubos en los sistemas analíticos, repeticiones o análisis de nuevas magnitudes y sellado y almacenamiento de los tubos, pudiéndose controlar y verificar las incidencias que ocurran con los tubos, clasificación y ordenación/ distribución de muestras.
El sistema de automatización total deberá disponer de identificación individual del tubo mediante código xx xxxxxx y radiofrecuencia durante todo el proceso, para asegurar la completa trazabilidad de la muestra en todo momento.
La conexión de los analizadores a la cadena robótica será bidireccional.
Se deberá posibilitar la carga de los tubos directamente en los sistemas analíticos, de forma que se asegure un trabajo continuado y como alternativa en caso de avería de la cadena de transporte de muestras.
El sistema deberá permitir la gestión simultánea de tubos urgentes, preferentes y de rutina, así como de diferentes tipos de tubos durante todo el proceso preanalítico, analítico y postanalítico.
El sistema de automatización dispondrá de un sistema de almacenamiento refrigerado de tubos, de forma que una vez finalizado el trabajo con los mismos puedan almacenarse tapados y refrigerados a 2-8ºC. La solución de almacenamiento deberá tener una capacidad mínima de 15.000 tubos. Deberá posibilitar la gestión automatizada de tubos desde estos módulos para repeticiones y medición de magnitudes reflejas sin que el usuario haya de transportar las muestras de forma manual.
La cadena será abierta, permitiendo la conexión de analizadores propios o de terceros, con experiencia probada en el entorno nacional y europeo.
Esta cadena debe disponer de:
Sistema/s de entrada de muestras lo más flexible posible. Sistema/s de centrifugación.
Sistema/s destaponadores. Sistema/s clasificadores.
Sistema/s alicuotadores. Sistemas analíticos.
Sistema/s retaponadores
Sistema/s archivadores de muestras en línea de al menos 7 días.
2.2 SISTEMA DE AUTOMATIZACIÓN TOTAL ÁREA DE SANGRE TOTAL
Los licitadores ofertarán una solución global de automatización (cadena robotizada) con capacidad para conectar equipos analíticos que den respuesta a las técnicas ofertadas
La funcionalidad del sistema será la de realizar los hemogramas, extensiones y tinciones con reglas preestablecidas, realizar la prueba de reticulocitos a las muestras seleccionadas así como clasificar aquellas muestras a las que se les solicita VSG y/o Hemoglobina Glicosilada. Finalmente el sistema generará un archivo de forma automática o semiautomática.
La realización de las pruebas de Hemoglobina Glicosilada y VSG no son objeto de este concurso pero se realizarán con el mismo tubo de EDTA. En el Anexo II se especifica el número estimado de pruebas de cada una de ellas a realizar.
El sistema debe permitir la generación de test reflejos o repeticiones basados en reglas predefinidas en los analizadores y/o en el sistema middleware de gestión.
El sistema debe permitir automatizar tareas manuales poco productivas como el registro/ aceptación de los tubos, carga y descarga de tubos en los sistemas analíticos, repeticiones o análisis de nuevas magnitudes, pudiéndose controlar y verificar las incidencias que ocurran con los tubos, clasificación y ordenación/ distribución de muestras.
El sistema de automatización total deberá disponer de identificación individual del tubo mediante código xx xxxxxx y radiofrecuencia durante todo el proceso, para asegurar la completa trazabilidad de la muestra en todo momento.
La conexión de los analizadores a la cadena robótica será bidireccional.
Se deberá posibilitar la carga de los tubos directamente en los sistemas analíticos, de forma que se asegure un trabajo continuado y como alternativa en caso de avería de la cadena de transporte de muestras.
El sistema deberá permitir la gestión simultánea de tubos urgentes, preferentes y de rutina, así como de diferentes tipos de tubos durante todo el proceso preanalítico, analítico y postanalítico.
La cadena será abierta, permitiendo la conexión de analizadores propios o de terceros, con experiencia probada en el entorno nacional y europeo.
Esta cadena debe disponer de:
Sistema/s de entrada de muestras lo más flexible posible. Sistema/s clasificadores.
Sistema/s extensores -teñidores Sistemas analíticos.
Sistema de gestión de archivo de muestras.
Debe disponer de la capacidad de gestionar muestras de sangre total y líquidos biológicos.
3.- EQUIPOS ANALÍTICOS BIOQUÍMICA E INMUNOENSAYO PARA TODOS LOS NODOS
Los equipos analíticos deberán ser de última generación, con capacidad de realizar las pruebas mencionadas en el Anexo II y cumplir con los tiempos de respuesta de las pruebas urgentes.
Se requieren sistemas de bioquímica totalmente automáticos, multicanal, selectivo y discreto con tecnología de medida colorimetría, turbidimetría e ISE
Equipos bioquímicos capaces de medir índices séricos (ictericia, hemólisis, lipemia).
La calidad analítica de las técnicas debe ser como mínimo las especificadas por las recomendaciones nacionales e internacionales.
Se debe garantizar la transferibilidad de resultados entre los diferentes equipos y la simplicidad en la gestión de reactivos.
En los Laboratorios de Urgencias HUA sede Txagorritxu y sede Santiago y en el Laboratorio de Respuesta Hospitalaria del HAD, los sistemas deben ser redundantes de forma que se garantice la prestación del servicio urgente en caso de fallo con mínimas complicaciones y que la parte urgente apoye también la ordinaria. La redundancia debería ser con equipos y sistemas iguales que puedan ser utilizados de forma indistinta por el personal y que garanticen la transferibilidad de los resultados.
El número de equipos analíticos necesarios debería ser el mínimo que garantice en caso de necesidad, la redundancia citada manteniendo la simplicidad y practicabilidad. Los equipos serán en lo posible iguales por línea, al menos en cuanto al manejo y la gestión de reactivos.
La practicabilidad general de los sistemas y su simplicidad deberían permitir su funcionamiento 24 horas y su manejo por personal a turnos.
Carga continua de muestras y que pueda trabajar simultáneamente con distintos tipos de muestras.
Identificación de muestras por código xx xxxxxx. Capacidad de priorización de muestras urgentes.
Posibilidad de utilizar tubo primario o secundario con diferentes tamaños y cubiletes.
Dilución automática de las muestras. Repetición automática y/o manual con dilución o concentración de muestras.
La gestión de las muestras debe garantizar la no contaminación de las mismas y debe incluir dispositivos que impidan la contaminación cruzada o ambiental de las muestras con antígenos, anticuerpos o ácidos nucleicos en caso de tener que realizar técnicas susceptibles de contaminación.
Los sistemas deberán disponer de sensores de tubo, muestra, así como detección de fibrina y coágulos.
La gestión de reactivos debe permitir la carga y descarga fácil de los mismos. Reactivos refrigerados en el sistema e identificados por código xx xxxxxx.
Monitorización del volumen de reactivo disponible.
Los sistemas de bioquímica deben de disponer xx xxxxxxx abiertos que permitan incorporar técnicas de las que el equipo no disponga.
4.- EQUIPOS ANALÍTICOS PARA MUESTRAS DE SANGRE TOTAL PARA TODOS LOS NODOS
Las características generales de los equipos analíticos serán:
Deberán ser nuevos, de última generación y de probada solvencia en hospitales de nuestras mismas características y prestaciones
Los analizadores ofertados para realizar los hemogramas deberán como mínimo permitir la medida de los siguientes parámetros sanguíneos:
Serie roja: recuento de eritrocitos, hematíes, hemoglobina, hematocrito, volumen corpuscular medio, índices eritrocitarios (RDW, etc.).
Serie blanca: recuento de leucocitos y su diferenciación porcentual y absoluta, en al menos cinco poblaciones (neutrófilos, linfocitos, monocitos, eosinófilos y basófilos).
Recuento de plaquetas, volumen plaquetar medio y otros índices plaquetarios como el PDW.
Recuento de retículocitos en porcentaje y número absoluto.
En los Laboratorios de Urgencias HUA sede Txagorritxu y sede Santiago y en el Laboratorio de Respuesta Hospitalaria del HAD, los sistemas deben ser redundantes de forma que se garantice la prestación del servicio urgente en caso de fallo con mínimas complicaciones y que la parte urgente apoye también la ordinaria. La redundancia debería ser con equipos y sistemas iguales que puedan ser utilizados de forma indistinta por el personal y que garanticen la transferibilidad de los resultados.
Así mismo, a cada uno estos nodos se dotará de un equipo para la realización de extensión y tinción , sin que, en este caso , se requiera redundancia
El número de equipos analíticos necesarios debe ser el óptimo que garantice la redundancia citada manteniendo la simplicidad y practicabilidad.
La practicabilidad general de los sistemas y su simplicidad debe permitir su funcionamiento 24 horas y su manejo por personal a turnos.
Deberán disponer de un sistema experto de validación con reglas configurables integradas en el analizador.
La capacidad de trabajar con micromuestras (pediatría). A tal efecto las empresas licitadoras deberán facilitar en su oferta datos acerca de la cantidad mínima de muestra requerida en modo manual.
Esta área debe incluir un sistema de recuento diferencial automatizado por microscopía digital y software para su gestión remota, en todos los nodos.
La capacidad de programación de ciclos de puesta en marcha, fin de trabajo y limpiezas automáticas.
La calidad analítica de las técnicas debe ser como mínimo la especificada por las recomendaciones nacionales e internacionales.
Extensores-teñidores automáticos para la producción de frotis teñidos de sangre periférica en todos los nodos y que deberá estar integrado en la cadena de automatización en el caso del Laboratorio central
Disponer de muestreador automático con una capacidad ilimitada de carga de muestras. La identificación positiva de muestras por código xx xxxxxx en modo automático y manual. Capacidad de priorización de muestras urgentes
.
5.- EQUIPOS ANALÍTICOS PARA PRUEBAS DE HEMOSTASIA PARA TODOS LOS NODOS
Las características generales de los equipos analíticos serán:
Los equipos analíticos deberán ser nuevos, de última generación, de alta capacidad y de probada solvencia en hospitales de nuestras mismas características y prestaciones (hospitales terciarios de alta especialización). Deberán ser capaces de realizar otras pruebas de coagulación (el licitador especificará qué otras pruebas de la cartera de servicios es posible realizar) y se deberá aportar un Agregómetro.
En los Laboratorios de Urgencias HUA sede Txagorritxu y sede Santiago y en el LRH del HAD, los sistemas deben ser redundantes de forma que se garantice la prestación del
servicio urgente en caso de fallo con mínimas complicaciones y que la parte urgente apoye también la ordinaria. La redundancia debería ser con equipos y sistemas iguales que puedan ser utilizados de forma indistinta por el personal y que garanticen la transferibilidad de los resultados.
El número de equipos analíticos necesarios debería ser el óptimo que garantice la redundancia citada manteniendo la simplicidad y practicabilidad con una velocidad mínima de 100 pruebas /h por equipo.
La practicabilidad general de los sistemas y su simplicidad deberían permitir su funcionamiento 24 horas y su manejo por personal a turnos.
Posibilidad de configuración de reglas de validación automática de los resultados integradas en el analizador.
Los sistemas deben de disponer xx xxxxxxx abiertos que permitan incorporar nuevas técnicas.
La identificación positiva de muestras y reactivos por código xx xxxxxx en modo automático y manual.
Los sistemas deberán ser capaces de trabajar con el tubo cerrado o abierto y en carga continua de muestras y reactivos.
La calidad analítica de las técnicas debe ser como mínimo la especificada por las recomendaciones nacionales e internacionales.
Los reactivos de trombofilia deberán tener una estabilidad mínima de un mes en frigorífico entre 2 y 8°
Capacidad para realizar la prueba de anticoagulante lúpico según las últimas recomendaciones internacionales de la y SITH. La aplicación en el analizador debe estar certificado por el fabricante.
Posibilidad de realizar Fibrinógeno Xxx-Xxxxxx. Características del Agregómetro:
- Equipo de agregación independiente.
- Una centrifuga específica para la agregación que permita la rápida obtención de plasma rico y pobre plaquetas directamente de los tubos extracción de citrato.
- Debe disponer de un amplio panel de reactivos (mínimo de ADP, ristocetina, , ácido araquinódico, colágeno y epinefrina.
6.- SOFTWARE DE GESTIÓN DEL SISTEMA PARA EL CORE DEL LABORATORIO CENTRAL XXX XXX
Para la gestión del sistema CORE se dispondrá de un software middleware en conexión con el SIL que lleve a cabo la gestión total del mismo cuya especificaciones figuran en el Anexo III.
Actividad y Pruebas
ANEXO II
ANEXO II Catálogo de pruebas Y precios de licitacion LABORATORIO CORE HUA HAD | |||||||||
Pruebas | LAB CENTRAL | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
BIOQUIMICA GENERAL | |||||||||
25 hidroxicolecalciferol (Vitamina D) | LAB CENT | 16.463 | 5,0764 | 83.572,7732 | |||||
GPT/ALT | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 364.068 | 0,0528 | 19.222,7904 |
GOT/AST | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 312.820 | 0,0528 | 16.516,8960 |
Albúmina | LAB CENT | HSANT | HAD | 134.664 | 0,0220 | 2.962,6080 | |||
Bilirrubina | LAB CENT | HSANT | HAD | 175.542 | 0,0495 | 8.689,3290 | |||
Bilirrubina Directa | LAB CENT | HSANT | HAD | 24.409 | 0,0330 | 805,4970 | |||
Amilasa | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 49.205 | 0,3300 | 16.237,6500 |
Xxxxxx | XXX CENT | HSANT | URGTXA | URGSAN | URGAD | 713 | 0,4805 | 342,5965 | |
Colesterol | LAB CENT | HSANT | HAD | 265.332 | 0,0440 | 11.674,6080 | |||
Colesterol HDL | LAB CENT | HSANT | HAD | 180.823 | 0,3300 | 59.671,5900 | |||
Calcio | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 165.048 | 0,0495 | 8.169,8760 |
Cloruro | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 32.387 | 0,0330 | 1.068,7710 |
CPK Creatinfosfoquinasa | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 45.899 | 0,2737 | 12.562,5563 |
Colinesterasa | LAB CENT | 832 | 0,0727 | 60,4864 | |||||
Creatinina | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 529.303 | 0,0154 | 8.151,2662 |
Factor reumatoide | LAB CENT | 11.969 | 0,9350 | 11.191,0150 | |||||
Ferritina | LAB CENT | HSANT | HAD | 115.504 | 1,1000 | 127.054,4000 | |||
Fosfatasa alcalina | LAB CENT | HSANT | HAD | URGTXA | URGSAN | 78.294 | 0,0990 | 7.751,1060 | |
GGT | LAB CENT | 201.673 | 0,0945 | 19.058,0985 | |||||
Fosfato | LAB CENT | HSANT | HAD | 166.542 | 0,0495 | 8.243,8290 | |||
Glucosa | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 462.691 | 0,0495 | 22.903,2045 |
LDH Lactato deshidrogenasa | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 67.805 | 0,0727 | 4.929,4235 |
Hierro | LAB CENT | HSANT | HAD | 122.118 | 0,0660 | 8.059,7880 | |||
Magnesio | LAB CENT | 36.410 | 0,0727 | 2.647,0070 | |||||
Microalbumina | LAB CENT | HSANT | HAD | 61.213 | 0,5500 | 33.667,1500 | |||
Potasio | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 405.996 | 0,0330 | 13.397,8680 |
Proteína C reactiva (PCR) | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 173.098 | 0,8139 | 140.884,4622 |
Procalcitonina | LAB CENT | HSANT | HAD | URGTXA | URGAD | 18.604 | 8,6437 | 160.807,3948 | |
Proteínas totales | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 159.119 | 0,0219 | 3.484,7061 |
Protéinas totales orina | LAB CENT | HSANT | HAD | 12.615 | 0,4950 | 6.244,4250 | |||
Sodio | LAB CENT | HSANT | HAD | URGTXA | URGSAN | 403.405 | 0,0330 | 13.312,3650 | |
Transferrina | LAB CENT | HSANT | HAD | 121.481 | 0,4950 | 60.133,0950 | |||
Urato | LAB CENT | HSANT | HAD | URGTXA | URGAD | 253.291 | 0,0660 | 16.717,2060 | |
Trigliceridos | LAB CENT | HSANT | HAD | 194.918 | 0,1320 | 25.729,1760 | |||
Troponina | LAB CENT | HSANT | HAD | URGTXA | URGSAN | 23.949 | 1,6500 | 39.515,8500 | |
Urea | LAB CENT | HSANT | HAD | URGTXA | URGSAN | 185.623 | 0,0660 | 12.251,1180 | |
Cobalamina (Vitamina B12) | LAB CENT | HSANT | 61.495 | 1,3200 | 81.173,4000 | ||||
Folato | LAB CENT | HSANT | 62.945 | 1,2650 | 79.625,4250 | ||||
Lipasa | LAB CENT | HSANT | 4.074 | 0,1527 | 622,0998 | ||||
Peptido natiuretico | LAB CENT | URGTXA | URGSAN | 15.188 | 12,3739 | 187.934,7932 | |||
LITIO | LAB CENT | 1.751 | 2,5300 | 4.430,0300 | |||||
TIROIDEOS ANTICUERPOS (ANTI TPO) | LAB CENT | 8.631 | 1,9800 | 17.089,3800 | |||||
HOMOCISTEINA | LAB CENT | 1.488 | 4,4000 | 6.547,2000 | |||||
RECEPTOR SOLUBLE TRANSFERRIN | LAB CENT | 701 | 11,0000 | 7.711,0000 | |||||
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
HORMONAS | |||||||||
T3L Triyodotironina libre | LAB CENT | HSANT | HAD | 17.184 | 0,8800 | 15.121,9200 | |||
T4LTiroxina libre | LAB CENT | HSANT | HAD | 39.763 | 0,8800 | 34.991,4400 | |||
TSH | LAB CENT | HSANT | HAD | 136.790 | 0,9900 | 135.422,1000 | |||
FSH Folitropina | LAB CENT | 5.368 | 1,2100 | 6.495,2800 | |||||
Cortisol | LAB CENT | 4.135 | 1,7600 | 7.277,6000 | |||||
Luteotropina (LH) | LAB CENT | 5.285 | 1,2100 | 6.394,8500 | |||||
Prolactina | LAB CENT | 6.220 | 1,2100 | 7.526,2000 | |||||
Estradiol | LAB CENT | 4.049 | 1,1000 | 4.453,9000 | |||||
Progesterona | LAB CENT | 791 | 1,1000 | 870,1000 | |||||
Testosterona Total | LAB CENT | 5.051 | 1,4300 | 7.222,9300 | |||||
PTH Paratohomona intacta | LAB CENT | 16.173 | 1,1000 | 17.790,3000 | |||||
DHEA-SO4 | LAB CENT | 1.773 | 1,9800 | 3.510,5400 | |||||
SHBG | LAB CENT | 2.997 | 1,9800 | 5.934,0600 | |||||
INSULINA | LAB CENT | 1.765 | 1,9800 | 3.494,7000 | |||||
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
FARMACOS Y DROGAS | |||||||||
Digoxina | LAB CENT | HAD | URGTXA | URGSAN | 3.912 | 1,9800 | 7.745,7600 | ||
Fenitoina | LAB CENT | URGTXA | URGSAN | 1.177 | 1,9800 | 2.330,4600 | |||
Fenobarbital | LAB CENT | URGTXA | URGSAN | 1.382 | 1,9800 | 2.736,3600 | |||
Carbamacepina | LAB CENT | URGTXA | URGSAN | 1.564 | 1,9800 | 3.096,7200 | |||
Valproato | LAB CENT | URGTXA | URGSAN | 3.274 | 1,9800 | 6.482,5200 | |||
VANCOMICINA | LAB CENT | URGTXA | 1.140 | 1,9800 | 2.257,2000 | ||||
AMIKACINA | LAB CENT | URGTXA | 964 | 2,9700 | 2.863,0800 | ||||
ETHANOL | LAB CENT | URGTXA | 446 | 1,9800 | 883,0800 | ||||
GENTAM | LAB CENT | URGTXA | 244 | 1,9800 | 483,1200 | ||||
TOBRAMICINA | LAB CENT | URGTXA | 276 | 2,9700 | 819,7200 | ||||
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
MARCADORES TUMORALES | |||||||||
CEA Antígeno carcinoembrionario | LAB CENT | 10.092 | 0,8155 | 8.230,0260 | |||||
CA 15-3 | LAB CENT | 4.143 | 1,3200 | 5.468,7600 | |||||
AFP Xxxx 0 fetoproteína | LAB CENT | 6.040 | 0,7700 | 4.650,8000 | |||||
CA 125 | LAB CENT | 3.741 | 1,3200 | 4.938,1200 | |||||
PSA Antígeno prostático específico | LAB CENT | HSANT | HAD | 37.811 | 0,7267 | 27.477,2537 | |||
PSA LIBRE Antígeno prostático específico | LAB CENT | HSANT | HAD | 7.262 | 1,2031 | 8.736,9122 | |||
CA 19-9 | LAB CENT | 6.472 | 1,3200 | 8.543,0400 | |||||
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
PROTEINAS | |||||||||
HAPTOGLOBINA | LAB CENT | URGTXA | 913 | 2,0900 | 1.908,1700 | ||||
XXXX 0 ANTITRIPSINA | LAB CENT | URGTXA | 1.875 | 1,5950 | 2.990,6250 | ||||
CERULOPLASMINA | LAB CENT | URGTXA | 2.120 | 2,0900 | 4.430,8000 | ||||
X0X | XXX XXXX | XXXXXX | 4.762 | 1,2100 | 5.762,0200 | ||||
C4 | LAB CENT | URGTXA | 4.814 | 1,2100 | 5.824,9400 | ||||
IGA | LAB CENT | URGTXA | 25.481 | 0,9900 | 25.226,1900 | ||||
IGG | LAB CENT | URGTXA | 20.529 | 0,9900 | 20.323,7100 | ||||
IGM | LAB CENT | URGTXA | 19.709 | 0,9900 | 19.511,9100 | ||||
BETA 0 XXXXXXXXXXXXXX | XXX XXXX | XXXXXX | 3.789 | 2,0900 | 7.919,0100 |
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
HEMATOLOGIA GENERAL | |||||||||
Hemograma | LAB CENT | HSANT | HAD | URGTXA | URGAD | 510.052 | 0,2484 | 126.686,7158 | |
Reticulocitos | LAB CENT | HSANT | HAD | 12.343 | 0,6637 | 8.192,5428 | |||
Pruebas | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL |
HEMOSTASIA-COAGULACION | |||||||||
Tiempo de Protrombina (TP) | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 204.244 | 0,4400 | 89.867,3600 |
Tiempo de tromboplastina parcial activada (APTT) | LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | 162.665 | 0,3300 | 53.679,4500 |
Xxxxxx X | XXX CENT | HSANT | URGTXA | URGSAN | URGAD | 14.843 | 2,8600 | 42.450,9800 | |
Anticoagulante lúpico (AL) (screening) | LAB CENT | 3.894 | 6,1927 | 24.114,2570 | |||||
Anticoagulante lúpico (AL) (Confirmatorio) | LAB CENT | 3.968 | 12,1000 | 48.012,8000 | |||||
Antitrombina III funcional | LAB CENT | 1.078 | 1,4300 | 1.541,5400 | |||||
Factor II | LAB CENT | 126 | 1,3200 | 166,3200 | |||||
Factor IX | LAB CENT | 39 | 1,3200 | 51,4800 | |||||
Factor V | LAB CENT | 84 | 1,6500 | 138,6000 | |||||
Factor VII | LAB CENT | 139 | 1,6500 | 229,3500 | |||||
Factor VIII | LAB CENT | 144 | 1,3200 | 190,0800 | |||||
Factor X | LAB CENT | 48 | 1,6500 | 79,2000 | |||||
Factor XI | LAB CENT | 29 | 1,6500 | 47,8500 | |||||
Factor XII | LAB CENT | 58 | 1,9800 | 114,8400 | |||||
Proteína S funcional | LAB CENT | 518 | 2,4200 | 1.253,5600 | |||||
Proteína C actividad | LAB CENT | 428 | 9,9000 | 4.237,2000 | |||||
LAB CENT | HSANT | HAD | URGTXA | URGSAN | URGAD | Nº Pruebas año | Pº Unitario | IMPORTE LICITACION ANUAL | |
SEROLOGIA INFECCIOSA | |||||||||
VIH 1- VIH2 Anticuerpos + Ag VIH | LAB CENT | HSANT | HAD | URGTXA | URGSAN | 21.094 | 1,4300 | 30.164,4200 | |
Hepatitis virus X Xx xx xxxxxxxxxx | XXX XXXX | XXXXX | XXX | XXXXXX | XXXXXX | 0.000 | 0,9900 | 2.516,5800 | |
Hepatitis virus A IgM | LAB CENT | URGTXA | URGSAN | 3.201 | 1,9800 | 6.337,9800 | |||
Hepatitis virus B anticore XxX | XXX XXXX | XXXXXX | XXXXXX | 00.000 | 1,9800 | 40.320,7200 | |||
Hepatitis virus B anti-antígeno de superficie IgG c | LAB CENT | HSANT | URGTXA | URGSAN | 6.208 | 1,9800 | 12.291,8400 | ||
Hepatitis virus S (B)Totales (IgG+IgM) | LAB CENT | HSANT | HAD | 20.001 | 1,9800 | 39.601,9800 | |||
Hepatitis virus S (A)Totales (IgG+IgM) | LAB CENT | XXXXXX | XXXXXX | 000 | 1,9800 | 1.114,7400 | |||
Hepatitis virus S (C)Totales (IgG+IgM) | LAB CENT | HSANT | HAD | 17.252 | 2,4200 | 41.749,8400 | |||
Citomegalovirus IgG | LAB CENT | HSANT | URGTXA | URGSAN | 2.930 | 1,9800 | 5.801,4000 | ||
Citomegalovirus IgM | LAB CENT | HSANT | URGTXA | URGSAN | 3.717 | 1,9800 | 7.359,6600 | ||
Rubeola virus IgG | LAB CENT | URGTXA | URGSAN | 5.910 | 1,9800 | 11.701,8000 | |||
Toxoplasma gondii IgG cuantitativa | LAB CENT | URGTXA | URGSAN | 2.729 | 1,9800 | 5.403,4200 | |||
VHB AG E SUERO/PLASMA | LAB CENT | URGTXA | URGSAN | 2.259 | 1,3200 | 2.981,8800 | |||
VHB ANTI-ANTIGE..TI IgG SUERO/PLASMA | LAB CENT | URGTXA | URGSAN | 2.255 | 1,5400 | 3.472,7000 | |||
ANTIESTREPTOLISINA O (ASLO) | LAB CENT | XXXXXX | XXXXXX | 000 | 1,3750 | 801,6250 | |||
ANTICUERPOS ANTI-TREPONEMA PALLIDUM | LAB CENT | URGTXA | URGSAN | 12.733 | 1,8150 | 23.110,3950 |
ANEXO III
Prescripciones técnicas relativas al desarrollo Informático
1.- INTRODUCCIÓN
El adjudicatario debe proponer un Sistema de Información para la Gestión del proceso (Middleware) que además de conectarse al sistema de información del laboratorio (SIL) garantice una adecuada gestión de las muestras y pruebas, que proporcione acceso a los resultados de los análisis a través de su conexión e interacción con el sistema de información del laboratorio descrito más abajo, y que provea de un sistema de explotación de los datos para fines de control de gestión.
2.- FUNCIONALIDADES DEL SISTEMA MIDDLEWARE:
El sistema proporcionará, al menos, las siguientes funcionalidades: La trazabilidad total de las muestras dentro del sistema.
La gestión del control de calidad.
Gestión de resultados y alarmas: revisión y validación técnica y facultativa, en un entorno web.
La gestión de las situaciones contingentes (fallo de un equipo, etc.) ofreciendo alternativas sencillas.
La explotación de la información para la mejora del proceso.
Además se cumplirán todas las especificaciones recogidas en este Anexo III.
3.- COORDINACIÓN Y DIRECCIÓN DEL PROYECTO
La empresa designará un jefe de proyecto en el ámbito informático, que será interlocutor único con Osakidetza y las UGCs. Dicho jefe de proyecto podrá acompañarse del personal técnico y funcional que estime conveniente en su relación con los homólogos de los hospitales y Osakidetza.
Se establecerán reuniones de seguimiento con la regularidad y contenido que en su momento se determinen.
4.- UBICACIÓN FÍSICA
El equipamiento dedicado a la realización de los servicios objeto del contrato se ubicará en dependencias de las UGCs, distribuido en:
Área de gestión del laboratorio. Residirán en ella los equipos directamente relacionados con la actividad propia del laboratorio y los puestos informáticos necesarios para su control y gestión, en dependencias de las UGCs
Para los equipos destinados a servidores de aplicaciones, de bases de datos y procesos. En función de la solución propuesta se decidirá si se alojan en el Centro de Proceso de Datos (CPD) de SSCC o en el CPD del centro donde se ubica el Laboratorio.
5.- INSTALACIONES E INFRAESTRUCTURA BÁSICA
La empresa adjudicataria utilizará las instalaciones e infraestructura básica de las UGCs, en concreto, el cableado de datos y los servicios de electricidad y refrigeración, tanto los generales como los del CPD.
Si la inclusión del equipamiento del adjudicatario implicase la necesidad de incrementar o reconfigurar las infraestructuras propias del hospital, el coste económico de estas modificaciones será asumido por la citada empresa.
6.- EQUIPAMIENTO INFORMÁTICO Y ARQUITECTURA
El adjudicatario aportará el hardware y software necesarios para la prestación del servicio, y se encargará de su instalación, configuración, puesta en producción, mantenimiento y adecuación, así como de dar el adecuado soporte al usuario y a las incidencias que pudieran surgir.
Los puestos informáticos necesarios para su control y gestión del Laboratorio estarán configurados con la maqueta de Osakidetza.
El equipamiento físico y lógico que tenga que interactuar o integrarse con otros sistemas de información del Departamento de Salud, de las UGCs, de Osakidetza o de sus Organizaciones de Servicios cumplirá los estándares definidos por éstos, tal y como viene establecido en el Anexo III. Estos estándares actuales podrían ser modificados por las UGCs u Osakidetza durante el contrato.
Actualmente, la versión de maqueta que se instala en los equipos de Osakidetza, es la 2.6; aunque convive con versiones anteriores instaladas.
Hardware
Procesador con un mínimo de tecnología de 45nm, caché L2 de 3 Mb y FSB de 1.066 Mhz. Memoria RAM 2 Gb.
Disco duro 250 Gb
Monitor 19 pulgadas con resolución 1440x900 mayoritaria o 1280x1024.
Sistema operativo
Windows 7 Enterprise N (32 Bit) SP1 + Windows media feature Pack
Asimismo, la arquitectura de los sistemas a instalar en el CPD cumplirá los estándares definidos en dicho Anexo III. Estos estándares actuales podrían ser modificados por las UGCs u Osakidetza durante el contrato.
La configuración de toda la infraestructura informática, en especial la electrónica (de comunicaciones y seguridad) y el equipamiento instalado en el CPD, seguirá los criterios establecidos por Osakidetza, las UGCs, y será supervisado por los hospitales y los SSCC.
7.- COMUNICACIONES Y CONECTIVIDAD
El equipamiento informático del adjudicatario, tanto el situado en el área de gestión del laboratorio como en el área de CPD, estará conectado a la red local del hospital.
En el área de gestión del laboratorio el adjudicatario proveerá las infraestructuras necesarias para conectar los equipos de trabajo necesarios si las ya existentes no fuesen suficientes o tuviesen que plantearse cambios de ubicación de las mismas. En caso de ser necesaria la ampliación de cableado (puntos de red) y/o electrónica de comunicaciones, la adquisición e implantación de las citadas infraestructuras deberá atenerse a los criterios marcados por Osakidetza, y las UGCs.
En el área de CPD el adjudicatario proveerá las infraestructuras adecuadas para la arquitectura que se defina si las ya existentes no fuesen suficientes siguiendo los estándares de Osakidetza y de las UGCs en esta materia, incluyendo cableado, electrónica de comunicaciones (switches), balanceadores, equipos de seguridad y tantos dispositivos
como sean necesarios para interconectar, de forma segura y con capacidad y disponibilidad suficientes, todo el equipamiento.
Las comunicaciones externas se realizarán a través de la red corporativa de Osakidetza.
8.- SERVICIO DE DIRECTORIO
Tanto los Servidores del área de CPD como los PCs del área de gestión del laboratorio estarán integrados en el dominio que indiquen las UGCs del Directorio Activo (Microsoft) de los hospitales.
9.- GESTIÓN, ADMINISTRACIÓN DE LOS SISTEMAS
Corresponde al adjudicatario la gestión y administración de las máquinas y los sistemas de información (servidores, PCs, dispositivos periféricos, bases de datos, aplicaciones, etc.) dedicados a la prestación de este servicio, así como la atención de usuarios e incidencias con relación al software y hardware aportado por el adjudicatario.
Las tareas de gestión y administración se llevarán a cabo desde puestos situados en el área de gestión del laboratorio y en el servicio de informática del Hospital.
Si para actividades de monitorización, mantenimiento u otras similares, el adjudicatario considera necesario disponer de un acceso externo, podrá dotarse de una conexión VPN (accesible desde Internet), con las condiciones y requisitos que para este tipo de enlaces tienen establecidos Osakidetza y las UGCs. En cualquier caso se garantizará siempre el acceso a cualquier dato de carácter personal de una forma segura, cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros.
La empresa facilitará al hospital documentación detallada acerca de la configuración de las máquinas, en especial electrónica (si la hubiera) y servidores, y la mantendrá permanentemente actualizada.
10.- MONITORIZACIÓN Y AUDITORÍA
Las UGCs y los SSCC dispondrán de capacidad de monitorización de los equipos informáticos de la empresa adjudicataria, con el suficiente nivel de autorización para cumplir al menos dos objetivos:
Comprobar que la instalación se adecua a lo establecido previamente. Disponer de información sobre la disponibilidad o indisponibilidad del servicio.
Más allá de esta exigencia, las UGCs y los Servicios Centrales de Osakidetza se reservan el derecho de efectuar auditorias tan extensas, profundas y detalladas como consideren oportuno para comprobar:
La calidad de las instalaciones.
La adecuación a lo comprometido y acordado.
El cumplimiento de estándares de seguridad y LOPD, así como la normativa aplicable en este ámbito.
Para todo ello la empresa proveerá los medios, herramientas y elementos de conectividad necesarios.
11.- INTEGRACIÓN Y ADECUACIÓN CON RESPECTO A LOS SISTEMAS DE INFORMACIÓN CON LAS UGCS, OSAKIDETZA Y DE SUS ORGANIZACIONES DE SERVICIOS
El Sistema de Información para la información del proceso (Middleware) deberá integrarse con los Sistemas de Información de cada laboratorio SIL, siendo responsabilidad del adjudicatario tanto el esfuerzo de integración desde el extremo del laboratorio como las adecuaciones al software corporativo y propio del hospital y las infraestructuras que sean requeridas para garantizar las prestaciones actuales de los Sistemas de Información de Osakidetza y sus Organizaciones de Servicios, derivadas de la implantación de este sistema.
Los estándares de obligado cumplimiento en cuanto a integración de sistemas se detallan en el , documento de descripción de requisitos técnicos para publicadores y subscriptores de eventos. Estos estándares actuales podrían ser modificados por las UGCs u Osakidetza durante el contrato.
Las adaptaciones requeridas en los Sistemas de Información del Departamento de Salud, de las UGCs, de Osakidetza y de sus Organizaciones de Servicios derivadas de la adopción de la solución propuesta deberán ser asumidas por el adjudicatario. El desarrollo será realizado por las empresas que Osakidetza, y las UGCs determinen en cada momento, principalmente los adjudicatarios de sus contratos de mantenimiento.
Así mismo, el coste de las conexiones y/o las licencias que sean necesarias para conectarse a OMEGA 3000, de la empresa ROCHE y GESTLAB de la empresa COINTEC serán asumidas por el adjudicatario durante todo el periodo que dure el contrato.
Los cambios de arquitectura e infraestructuras que fueran requeridos para mantener las funcionalidades actuales y futuras en los Sistemas de Información relatados, así como el desarrollo, pruebas unitarias y de integración, paso a producción, y expansión a todos los centros de las nuevas versiones de los Sistemas de Información en este apartado descritos deberán ser igualmente asumidos por el adjudicatario.
Los Sistemas de Información corporativos a integrar y adecuar:
Sistema de Información del Laboratorio OMEGA 3000 y GESTLAB
El Middleware aportado por el proveedor deberá integrarse con el Sistema de Información del Laboratorio con que cuenta Osakidetza utilizando los catálogos de laboratorio corporativos de Osakidetza
Se aplicará para estos equipos el funcionamiento “point of care”, la captura de demográficos de pacientes se realizará en el HIS corporativo, utilizando los catálogos corporativos de Osakidetza que se precise. Además, se mantendrán actualizados dichos datos, si fuera necesario en el middleware, según la información enviada por el HIS. De ningún modo, se permitirá que se incorpores/actualicen pacientes o sus datos desde el middleware.
En este caso, los estándares de obligado cumplimiento en cuanto a integración de sistemas serán mediante “web Service” y eventos que se detallan en el , documento de descripción de requisitos técnicos para publicadores y suscriptores de eventos. Estos estándares actuales, podrían ser modificados por las UGCs u Osakidetza durante la vigencia del contrato.
12.- NORMATIVA Y ESTÁNDARES
En todas las instalaciones del hospital, incluyendo el laboratorio, la empresa actuará con conocimiento y supervisión de las UGCs. En las interconexiones físicas y lógicas con el resto del hospital o de otros nodos de la red corporativa de Osakidetza y en cualquier actuación que implique a personas o equipos de las UGCs, de Osakidetza o de sus Organizaciones de Servicios la empresa cumplirá los estándares y normativa que estos determinen; entre otros:
La gestión de las muestras. Normativa de seguridad.
Especificaciones técnicas de infraestructura. Estándares de arquitectura de sistemas y desarrollo. Estándares de arquitectura y configuración de CPDs. Normativa y estándares de conectividad.
Normativa y estándares de conectividad. Requisitos técnicos para publicadores y subscriptores de eventos. Gestor de Eventos Event Manager.
Normativa para puesta en producción de aplicaciones en CPDs. Normativa para relación con el centro de atención a usuarios (CAU).
Estos estándares podrían ser modificados por las UGCs u Osakidetza durante el contrato.
13. INFORMACIÓN DE SEGUIMIENTO Y CONTROL DEL SERVICIO
La empresa adjudicataria elaborará y remitirá a Osakidetza y las UGCs información relativa a la prestación del servicio, con la regularidad que se determine y con el contenido y detalle necesarios, tanto para la comprobación del cumplimiento de los niveles de servicio como para facilitar las decisiones de gobierno de la actividad.
Asimismo, la empresa pondrá a disposición de las UGCs la capacidad para acceder a los sistemas y aplicaciones en base a su función auditora.
Para llevar a cabo estas exigencias, la empresa dispondrá los elementos técnicos necesarios, conforme a los procedimientos y estándares determinados por Osakidetza y/o las UGCs
Cumplimiento de la ley de protección de datos de carácter personal
ANEXO IV
1.- INTRODUCCIÓN
La contratista se compromete a cumplir las medidas y requisitos de seguridad exigidos por el Departamento de Salud, por las UGCs, por Osakidetza y por sus Organizaciones de Servicios.
El coste de las actuaciones de cualquier tipo, incluidas las auditorias, derivadas del cumplimiento de la LOPD y normativa relacionada, serán por cuenta del adjudicatario.
2.- NORMATIVA QUE APLICA
La contratista cumplirá con la legislación vigente en materia de protección de datos de carácter personal conforme a lo dispuesto en la normativa que se relaciona a continuación y a las disposiciones de desarrollo de dicha normativa en materia de Protección de Datos que se encuentren en vigor a la adjudicación de este contrato o que puedan estarlo durante su vigencia:
2.1.- LEGISLACIÓN COMUNITARIA
Directiva 95/46/CE del Parlamento y del Consejo, de 24 de Octubre de 1.995, relativa a la protección de las personas físicas en lo que respecta al tratamiento de datos personales y a la libre circulación de estos datos.
Carta de los Derechos Fundamentales de la Unión Europea (2000/C 364/01).
Artículo 8.
Proyecto de Constitución para Europa (DOUEC de 16 de diciembre de 2004, artículo I-51).
2.2.- LEGISLACIÓN ESTATAL
Ley Orgánica15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal.
Real Decreto 1720/2007, de 21 de diciembre por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal.
Constitución española de 27 de diciembre de 1.978. Artículo 18. Ley 14/1986, de 25 xx xxxxx, General de Sanidad.
Ley 41/2002, de 14 de noviembre, básica reguladora de la autonomía del paciente y de derechos y obligaciones en materia de información y documentación clínica.
Ley 33/2011, de 4 de octubre, General de Salud Pública.
2.3.- LEGISLACIÓN AUTONÓMICA
Ley 2/2004 de 25 de febrero, de ficheros de datos de carácter personal de titularidad pública y de creación de la Agencia Vasca de Protección de Datos.
Decreto 308/2005 de 18 de octubre, por el que se desarrolla la Ley 2/2004, de 25 de febrero de ficheros de datos de carácter personal de titularidad pública y de creación de la Agencia Vasca de Protección de Datos.
Decreto 309/2005, de 18 de Octubre, por el que se aprueba el Estatuto de la Agencia Vasca de Protección de Datos.
Resolución de 21 de Julio de 2005, del Director de la Agencia Vasca de Protección de Datos por la que se establecen los modelos normalizados y los medios por los que debe procederse a la solicitud de las inscripciones de creación, modificación o supresión de ficheros en el Registro de Protección de Datos de la Agencia Vasca de Protección de Datos.
Resolución de 28 de Noviembre de 2.005, del Director de la Agencia Vasca de Protección de Datos por la que se desarrolla la estructura orgánica de la Agencia Vasca de Protección de Datos.
3.- PROTECCIÓN DE DATOS
1) Las UGCs, Osakidetza y sus Organizaciones de Servicios son responsables de los ficheros que se tratan con motivo del servicio objeto de la contratación, conforme
a la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (en adelante LOPD). Dichos ficheros están declarados ante el Registro General de la Agencia Vasca de Protección de Datos
Todo lo que se estipula a continuación se circunscribe a los datos de carácter personal contenidos en los ficheros antedichos que el adjudicatario pudiera tratar con motivo de la prestación del servicio contratado.
2) La contratista, como parte del presente contrato, deberá cumplir con lo especificado en el punto 34 xxx Xxxxxx de Cláusulas Administrativas Particulares.
3) La contratista, no podrá utilizar dichos datos para otro fin distinto del indicado en los acuerdos adoptados en el presente contrato, dedicado a definir el objeto del mismo.
4) La contratista se compromete a tratar los datos conforme a las instrucciones que le marquen las UGCs, Osakidetza y otras Organizaciones de Servicios como responsables de los ficheros.
5) La contratista en ningún caso comunicará, mostrará, cederá ni revelará datos, ni siquiera para su conservación, a terceras personas ajenas a la relación contractual que se establece en el presente contrato, salvo requerimiento judicial específico.
6) La contratista se compromete a cumplir todo lo dispuesto en la legislación vigente sobre protección de datos que le sea de aplicación. Así, todo dato que conozca cualquiera de sus subordinados, como consecuencia de la realización del presente contrato, debe mantenerse en la más estricta confidencialidad, no pudiendo comunicarse a terceros ni emplearse en uso propio, respondiendo de los posibles perjuicios que se pudieran derivar para las UGCs, Osakidetza y otras Organizaciones de Servicios y para los afectados.
7) El personal dependiente de la contratista se comprometerá a no revelar la información que pudiera conocer en función de su cargo o cometido durante la prestación del presente contrato y posteriormente al mismo
8) La contratista como encargado del mantenimiento de datos de carácter personal provenientes del presente contrato, se obliga a devolverlos a las UGCs y a Osakidetza una vez cumplida la prestación contractual, en el plazo de tres meses, o
en su caso, a destruirlos, al igual que el soporte o documento en el que consten aquellos.
La contratista quedará sujeta al régimen de responsabilidad que instaura la LOPD y responderá personalmente siempre que destine los datos a una finalidad diferente a la estipulada en el presente contrato, los comunique a terceros, o los utilice incumpliendo alguna de las cláusulas de este contrato.
9) La contratista deberá implantar las medidas de seguridad precisas de tipo técnico y organizativo que, en función del nivel de protección correspondiente a los datos de carácter personal a los que tenga acceso durante la prestación de los servicios, impone la normativa vigente de protección de datos. Las medidas mínimas de seguridad obligatorias para este contrato se contienen en el apartado de medidas de seguridad siguientes.
4.- MEDIDAS DE SEGURIDAD
4.1.- Medidas de nivel básico
4.1.1.- Acceso a través de redes de comunicaciones
1) La contratista se compromete a que las medidas de seguridad exigibles a los accesos a datos de carácter personal a través de redes de comunicaciones garantizarán un nivel de seguridad equivalente al correspondiente a los accesos en modo local.
4.1.2.- Régimen de trabajo fuera de los locales de ubicación del fichero
1) La ejecución de tratamiento de datos de carácter personal fuera de los locales de la ubicación del fichero es autorizada expresamente por el responsable del fichero. La contratista se compromete a garantizar el nivel de seguridad correspondiente al tipo de fichero tratado fuera de los locales. Esta autorización abarca las ejecuciones de datos fuera de la ubicación del fichero en los siguientes supuestos:
- Para albergar copias de seguridad
- Recuperaciones de datos
- Contingencias
- Simulacros de planes de contingencias
- Mantenimientos de equipos
4.1.3.- Ficheros temporales
1) La contratista se compromete a que los ficheros temporales cumplirán el nivel de seguridad que les corresponda dependiendo de la naturaleza de los datos de carácter personal manifestados por el Responsable del Fichero.
2) La contratista se compromete a borrar todo fichero temporal una vez que haya dejado de ser necesario para los fines que motivaron su creación.
4.1.4.- Funciones y obligaciones
1) Las funciones y obligaciones de los trabajadores de la contratista con acceso a los Sistemas de Información de las UGCs, Osakidetza y otras Organizaciones de Servicios respecto de la seguridad de los datos de carácter personal deberán estar definidas, difundidas y documentadas.
4.1.5.- Registro de Incidencias
1) La contratista dispondrá de un procedimiento de notificación y gestión de incidencias, el cual contendrá necesariamente un registro en el que se haga constar el fichero de datos de carácter personal implicado, el tipo de incidencia, el momento en que se ha producido, la persona que realiza la notificación, a quién se le comunica y los efectos que se hubieran derivado de la misma.
2) La contratista considerará como incidencia de seguridad las recuperaciones de datos y, por tanto, las consignará indicando la persona que ejecutó el proceso, los datos restaurados y, en su caso, qué datos ha sido necesario grabar manualmente en el proceso de recuperación.
4.1.6.- Identificación y autenticación
1) La contratista establecerá un mecanismo que permita la identificación de forma inequívoca y personalizada de todo aquel usuario que intente acceder al sistema de información y la verificación de que está autorizado.
2) Cuando el mecanismo de autenticación se base en la existencia de contraseñas, la contratista dispondrá de una herramienta de asignación, distribución y almacenamiento que garantice su confidencialidad e integridad, tal y como se establece en la descripción del servicio de administración de usuarios.
3) La contratista se compromete a que los mecanismos que controlan las contraseñas obligarán al usuario a cambiarlas con la periodicidad que determine la contratista (se especificarán períodos para el cambio, no superiores a 1 año) y mientras estén vigentes se almacenarán de forma ininteligible.
4.1.7.- Control de acceso
1) Los usuarios tendrán acceso autorizado únicamente a aquellas aplicaciones con el perfil que precisen para el desarrollo de sus funciones.
2) La contratista establecerá mecanismos para evitar que un usuario pueda acceder a aplicaciones con derechos distintos de los autorizados.
3) La contratista dispondrá de una relación actualizada de usuarios, que tengan acceso autorizado al sistema de información, conteniendo el acceso autorizado para cada uno de ellos.
4) Solamente las personas autorizadas por las UGCs y Osakidetza podrán gestionar las autorizaciones de acceso a los recursos.
4.1.8.- Gestión de Soportes
1) La contratista se compromete a que los soportes informáticos que contengan datos de carácter personal identificarán el tipo de información que contienen, serán inventariados y se almacenarán en un lugar de acceso restringido al personal autorizado.
2) La salida de soportes informáticos que contengan datos de carácter personal, fuera de los locales en los que esté ubicado el fichero, únicamente podrá ser autorizada por el responsable del fichero – las UGCs, Osakidetza u otras Organizaciones de Servicios.
3) La contratista se compromete a que cuando el soporte vaya a ser desechado o reutilizado, se adoptarán las medidas necesarias para impedir cualquier recuperación posterior de la información almacenada en él, previamente a que se proceda a su baja en el inventario.
4) La contratista se compromete a que cuando los soportes vayan a salir fuera de los locales en que se encuentran ubicados los ficheros, se adoptarán las medidas
necesarias para impedir cualquier recuperación indebida de la información almacenada en ellos.
5) La contratista establecerá un sistema de registro de entrada de soportes informáticos que permita, directa o indirectamente, conocer el tipo de soporte, la fecha y hora, el emisor, el número de soportes, el tipo de información que contienen, la forma de envío y la persona responsable de la recepción que deberá estar debidamente autorizada.
6) La contratista establecerá un sistema de registro de salida de soportes informáticos que permita, directa o indirectamente, conocer el tipo de soporte, la fecha y hora, el destinatario, el número de soportes, el tipo de información que contienen, la forma de envío y la persona responsable de la entrega que deberá estar debidamente autorizada.
4.1.9.- Copias de Respaldo y Recuperación
1) La contratista se compromete a que los procedimientos establecidos para la realización de copias de respaldo y para la recuperación de los datos garantizará su reconstrucción en el estado en que se encontraban al tiempo de producirse la pérdida o destrucción.
2) La contratista se compromete a realizar copias de respaldo, al menos semanalmente, salvo que en dicho periodo no se hubiera producido ninguna actualización de los datos.
3) Será necesaria la autorización por escrito del responsable del fichero para la ejecución de los procedimientos de recuperación de los datos, conforme los requisitos establecidos sobre recuperación de datos en el capítulo siguiente.
4) Al menos cada seis meses la contratista realizará la verificación del correcto funcionamiento de las copias de seguridad.
4.1.10.- Pruebas con datos reales
1) La contratista se compromete a que las pruebas anteriores a la implantación o modificación de los sistemas de información que traten ficheros con datos de carácter personal no se realizarán con datos reales, salvo que se asegure el nivel de seguridad correspondiente al tipo de fichero tratado y se anote su realización en el
documento de Seguridad y se realice una copia de seguridad previa de los Sistemas de Información
4.1.11.- Ficheros en soporte no automatizado
1) A los ficheros en soporte no automatizado les será de aplicación las medidas establecidas en las disposiciones anteriores y las obligaciones comunes de los capítulos I, II y III del título VIII del Reglamento de la LOPD. El adjudicatario deberá implantar las siguientes medidas específicas para el tratamiento de ficheros en soporte no automatizado que contengan datos de carácter personal:
• Establecerá los criterios y procedimientos de archivo de soportes y documentos con el fin de garantizar la correcta conservación, localización y consulta y de ejercicio de los derechos de oposición, acceso, rectificación y cancelación. En todo caso, se atenderá a los criterios dispuestos en la norma sectorial que le sea aplicable.
• Los dispositivos de almacenamiento de los documentos que contengan datos de carácter personal deberán disponer de mecanismos que obstaculicen su apertura y en cualquier caso, se adoptarán medidas que impidan el acceso de personas no autorizadas.
• Implantar medidas con el objetivo de que durante los procesos de revisión o tramitación de la documentación se impida el acceso a personas no autorizadas.
4.2.- Medidas de nivel medio
1) La contratista se compromete a designar uno o varios responsables de seguridad que se encargarán de coordinar y controlar la efectiva aplicación de las medidas de seguridad definidas en el presente contrato.
4.2.1.- Auditoría
1) La contratista se compromete a que los sistemas de información e instalaciones de tratamiento de datos se someterán a una auditoría que verifique el cumplimiento del reglamento, de:
• Los procedimientos e instrucciones vigentes en materia de seguridad de datos, al menos, cada dos años. El informe de auditoría deberá dictaminar
sobre la adecuación de las medidas y controles al Título VIII del Real Decreto 1720/2007, de 21 de diciembre, por el que se aprueba el Reglamento de desarrollo de la Ley Orgánica 15/1999, de 13 de diciembre, de protección de datos de carácter personal, identificar sus deficiencias y proponer las medidas correctoras o complementarias necesarias. Deberá, igualmente, incluir los datos, hechos y observaciones en que se basen los dictámenes alcanzados y recomendaciones propuestas.
• Los informes de auditoría serán analizados por el responsable de seguridad competente, que elevará las conclusiones al responsable del fichero para que adopte las medidas correctoras adecuadas y quedarán a disposición de la Agencia de protección de Datos competente.
• Lo dispuesto en los puntos anteriores será de aplicación asimismo cuando se produzcan cambios sustanciales en los Sistemas de Información que puedan repercutir en el cumplimento de las medidas de seguridad.
4.2.2.- Identificación y autenticación.
1) El mecanismo de identificación y autenticación de usuarios del adjudicatario deberá de restringir el número de intentos de acceso a un máximo de cinco.
4.2.3.- Control de acceso físico
1) La contratista deberá establecer un control del acceso físico a los locales donde se encuentren los Sistemas de Información con datos de carácter personal.
4.3.- MEDIDAS DE NIVEL ALTO
4.3.1.- Distribución de soportes
1) La contratista se compromete a que la distribución de los soportes que contengan datos de carácter personal se realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que dicha información no sea inteligible ni manipulada durante su transporte.
4.3.2.- Registro de accesos
1) La contratista dispone de un mecanismo que de cada acceso a los ficheros de datos de nivel alto:
• Guarda como mínimo, la identificación del usuario, la fecha y hora en que se realizó, el fichero accedido, el tipo de acceso y si ha sido autorizado o denegado.
• En el caso de que el acceso haya sido autorizado, se guarda la información que permita identificar el registro accedido.
• Los mecanismos que permiten el registro de los datos de acceso estarán bajo el control directo del personal competente del adjudicatario sin que se deba permitir, en ningún caso, la desactivación de los mismos.
• El periodo mínimo de conservación de los datos registrados es de dos años.
2) La contratista se compromete a revisar al menos una vez al mes la información del registro de accesos y a remitir un informe a Osakidetza sobre las revisiones realizadas
4.3.3.- Copias de Respaldo y Recuperación
1) La contratista conservará una copia respaldo y de los procedimientos de recuperación de los datos en un lugar diferente de aquél en que se encuentren los equipos informáticos que los tratan cumpliendo, en todo caso, las medidas de seguridad exigidas.
4.3.4.- Telecomunicaciones
1) La contratista se compromete a que la transmisión de datos de carácter personal a través de redes de telecomunicaciones la realizará cifrando dichos datos o bien utilizando cualquier otro mecanismo que garantice que la información no sea inteligible ni manipulada por terceros.
4.3.5.- Ficheros en soporte no automatizado
1) La contratista deberá implantar los siguientes procedimientos y medidas ante el tratamiento de ficheros no automatizados de nivel alto:
• Los armarios, archivadores u otros elementos en los que se almacenen los ficheros no automatizados con datos de carácter personal deberán encontrarse en áreas con acceso protegido mediante puertas dotadas de sistemas de apertura con llave o dispositivo equivalente. Si no fuera posible por las características de los mismos, se adoptarán medidas alternativas y se motivarán ante el responsable del fichero que las hará constar en el Documento de Seguridad.
• La generación de copias o la reproducción de los documentos únicamente podrá ser realizada bajo el control del personal autorizado. Deberá procederse a la destrucción de las copias o reproducciones desechadas de forma que se evite el acceso a la información o su recuperación posterior.
• El acceso a la documentación se limitará exclusivamente al personal autorizado y se establecerán mecanismos que permitan identificar los accesos realizados por múltiples usuarios. También se registrarán los accesos de personal no autorizado de acuerdo con el procedimiento establecido al efecto en el documento de seguridad.
• Deberán adoptarse medidas dirigidas a impedir el acceso o manipulación de la información objeto de traslado físico.
.
Criterios de valoración y puntuación
ANEXO V
Apartado A - Criterios de valoración Características generales 20 Puntos.
PUNTUACIÓN MÁXIMA | |
1. Características de flexibilidad, versatilidad y eficiencia de los flujos de trabajo en la solución ofertada | Hasta 13 puntos |
1.1.Formato de conexión de los analizadores ofertados al sistema global de automatización | 2 puntos |
1.2.Capacidad de conexión probada de analizadores de otros proveedores, valorándose especialmente la conexión de analizadores de Hb1AC (HPLC), velocidades de sedimentación globular, alergias y electroforesis capilar a las soluciones de automatización | 2 puntos |
1.3.Rendimiento de las soluciones de automatización para el transporte de muestras | 2 puntos |
1.4.Mejores prestaciones de la solución de almacenamiento y recuperación de tubos de la solución de automatización del área xx xxxxx | 2 puntos |
1.5.Escalabilidad y sencillez para hacer crecer la cadena robótica en caso de mayor actividad o reorganización del laboratorio | 2 puntos |
1.6.Escalabilidad y flexibilidad en la configuración de los analizadores de alto volumen: bioquímica, inmunoensayo y hematimetría | 3 puntos |
2. Adecuación de la solución ofertada al espacio disponible, de forma que se faciliten los flujos de trabajo y los circuitos de muestras | Hasta 4 puntos |
3. 3. Sistema de gestión de almacenes | Hasta 3 puntos |
3.1.Soluciones aportadas por el licitador en caso de contingencia | 2 puntos |
3.2.Gestión de las referencias | 1 punto |
PUNTUACIÓN MÁXIMA TOTAL | 20 puntos |
Apartado B - Criterios de valoración Características Específicas 30 Puntos
CARACTERÍSTICAS DE LOS ANALIZADORES DE BIOQUÍMICA E INMUNOENSAYO (Hasta 14
Puntos)
PUNTUACIÓN | |
1. Condiciones de almacenaje de reactivos, calibradores y controles en los analizadores (2 puntos) | |
1.1. Los analizadores de bioquímica del Laboratorio Central serán capaces de almacenar 70 petacas de reactivos como mínimo por módulo en un único compartimento refrigerado (2-12 ⁰C). | 0,5 puntos |
1.2. Los analizadores de inmunoensayo del Laboratorio Central serán capaces de almacenar 45 petacas de reactivos como mínimo por módulo en un único compartimento refrigerado (2-12 ⁰C). | 0,5 puntos |
1.3. Posibilidad de almacenamiento de los viales de controles y calibradores de bioquímica e inmunoensayo a bordo de los analizadores en un compartimento refrigerado (2-12ºC) y programación automática de los mismos para su procesamiento. -Cumplimiento en todos los centros: (1 punto) -Cumplimiento sólo en el HUA sede consultas externas (0,5 puntos) -Resto de casos: 0 puntos | Hasta 1 punto |
2. Formato y manejo de reactivos en los analizadores (6 Puntos) | |
2.1. Utilización de reactivos de bioquímica e inmunoensayo que puedan ser fácilmente cargados y descargados sin necesidad de parar, pausar su funcionamiento en ningún momento o necesiten llegar a un estado de stand-by. -Cumplimiento en todos los centros: 1 punto -Cumplimiento sólo en el HUA (sede consultas externas): 0,5 puntos -Resto de casos: 0 puntos | Hasta 1 punto |
2.2.Formato compacto de reactivos en un soporte único para cada uno de los ensayos a procesar en los analizadores de bioquímica e inmunoensayo -Cumplimiento en todos los centros: 2 puntos -Cumplimiento sólo en el HUA (sede consultas externas): 1 | Hasta 2 puntos |
PUNTUACIÓN | |
punto -Resto de casos: 0 puntos | |
2.3. Los envases de reactivos de los analizadores de bioquímica e inmunoensayo ofertados tanto para el laboratorio core como para los laboratorios de respuesta rápida son intercambiables. | 1 punto |
2.4. Disponibilidad de presentaciones de reactivos como mínimo de 500 tests por envase para pruebas de inmunoensayo de alto volumen (TSH, T4 libre, PSA, vitamina D). | 2 puntos |
3. Tecnología (2,5 Puntos) | |
3.1. La tecnología de los sistemas de bioquímica permite informar resultados directos y automáticos para pruebas de enzimas, en muestras que excedan el rango lineal preconfigurado, sin repeticiones adicionales por dilución. | 2,5 puntos |
4. Medioambiente (3,5 Puntos) | |
4.1. Para evitar la contaminación por arrastre entre muestras, los equipos de inmunoensayo no requieren la utilización de puntas de pipeta desechables, contribuyendo a la disminución del volumen de residuos sólidos generados por el laboratorio | 2 puntos |
4.2. Consumo de agua purificada de cada módulo de bioquímica ofertado igual o inferior a 30 litros/ hora | 1,5 puntos |
CARACTERÍSTICAS DE LOS ANALIZADORES DE HEMATIMETRÍA (Hasta 9 Puntos)
PUNTUACIÓN | |
5. Condiciones de almacenaje de reactivos en los analizadores (1 punto) | |
5.1. Los reactivos necesarios para la realización del hemograma están integrados dentro de la estructura del analizador | 1 punto |
6. Formato y manejo de reactivos en los analizadores (4 puntos) | |
6.1. Carga continua de todos los reactivos del hemograma sin necesidad de pausar o parar el contador (reactivos por duplicado) | 2 puntos |
6.2. Los contadores utilizan un máximo de 3 reactivos para hacer el hemograma y 1 reactivo para los reticulocitos | 2 puntos |
7. Manejo de muestras (2 Puntos) | |
7.1. Autonomía de carga inicial de muestras en cada uno de los contadores para más de 110 tubos | 1 punto |
7.2. Posibilidad de priorización de muestras urgentes sobre rutina en muestras cargadas en la misma gradilla, así como configurar varias posiciones de entrada para muestras urgentes | 1 punto |
8. Tecnología (2 Puntos) | |
8.1. Diferencial leucocitario de 6 poblaciones en todas las muestras sin requerir reactivos adicionales | 1 punto |
8.2. Medición del parámetro %Plaquetas reticuladas | 1 punto |
CARACTERÍSTICAS DE LOS ANALIZADORES DE HEMOSTASIA (Hasta 4 Puntos)
PUNTUACIÓN | |
10. Condiciones de almacenaje de reactivos en los analizadores (0,2 Puntos) | |
10.1. Nevera integrada con aseguramiento de la temperatura y con control centralizado. | 0,2 puntos |
11. Formato y manejo de reactivos en los analizadores (2,2 Puntos) | |
11.1 Los reactivos para realizar el tiempo de Protrombina , el tiempo de Cefalina serán líquidos y con una estabilidad en el analizador superior a 9 días | 0,8 puntos |
11.2 El reactivo de Dímero D será líquido, de alta sensibilidad y con valor predictivo negativo del 100% para patologías tromboembólicas (TVP y TEP), avalado por un organismo internacional. | 0,8 puntos |
11.3 Existencia de Reactivos para valoración de los anticoagulantes orales de acción directa (Rivarosaban, Apixaban y Dabigatran) elaborados por el mismo fabricante que el analizador ofertado. | 0,4 puntos |
11.4 Agregómetro: Presencia xx xxxxxxx extra que permitan añadir nuevos agonistas | 0,2 puntos |
12. Manejo de muestras (1,4 Puntos) | |
12.1 Control preanalítico que evalúe la integridad de la muestra tanto en el llenado del tubo primario como las posibles interferencias de hemólisis ictericia y lipemia así como detección de obstrucciones en aguja atribuibles a coágulos. | 0,4 puntos |
12.2. Chequeo de las interferencias HIL (hemólisis, ictericia y lipemia) específico para cada ensayo utilizando los umbrales de la ficha técnica de cada reactivo y configurables por el usuario. | 0,6 puntos |
12.3 Posibilidad de establecer repeticiones y test reflejos automáticos desde el propio equipo. | 0,2 puntos |
12.4 Primer resultado de Tiempo de Protrombina desde stand by en menos de 3 minutos y de Dímero D en menos de 15 minutos | 0,2 puntos |
13. Tecnología (0,2 Puntos) | |
13.1. Posibilidad de automatizar en cadena pruebas hemostáticas especiales de acuerdo con catálogo de nuestro Laboratorio | 0,2 puntos |
CARACTERÍSTICAS COMUNES SOFTWARE (Hasta 3 Puntos)
PUNTUACIÓN | |
9. Condiciones de almacenaje de reactivos en los analizadores | |
9.1. El software de los sistemas analíticos de bioquímica, inmunoensayo y hematimetría, tanto de los laboratorios de rutina como de los de respuesta hospitalaria, dispone del mismo interface de usuario, de cara a asegurar la mayor flexibilidad en la asignación de personal, sin necesidad de formación adicional | 3 puntos |
Las empresas licitadoras deberán aportar la justificación y las referencias adecuadas que permitan evidenciar el grado de cumplimiento de cada uno de los criterios.
Se indicará la página de la oferta en la que se describe cada una de las características solicitadas.
Atención a usuarios y acuerdos de nivel de servicio
ANEXO VI
1.- SOPORTE A USUARIOS Y MANTENIMIENTO
El adjudicatario ofrecerá soporte de usuarios (atención de consultas e incidencias) y mantenimiento con relación al software y hardware aportado por el mismo en base a esta licitación.
El mantenimiento cubrirá adaptaciones o extensión de funcionalidades requeridas por los responsables del laboratorio, sin que supongan modificación de las condiciones esenciales del contrato.
2.- HORARIO DE PRESTACIÓN DE SERVICIOS DE SOPORTE
Para los servicios de soporte, el horario de prestación debe cubrir suficientemente las necesidades de asistencia de los diferentes entornos. Deberá ofertarse como mínimo:
De 8.00 a 22:00 horas, de forma ininterrumpida (Lu-Vi). Xxxxxxx, Xxxxxxxx y festivos de
08.00 a 15.00 horas
. Fuera de este horario debe existir al menos un buzón de avisos para dejar constancia de incidencias y reclamar servicio prioritario para el siguiente día.
Cuando el tiempo de respuesta para peticiones urgentes implique una incidencia crítica se dispondrá de soporte presencial o localizado las 24 horas de forma ininterrumpida todos los días del año.
3.- ACUERDO DE NIVEL DE SERVICIO
Un atributo de catalogación importante para las incidencias es la urgencia o la criticidad de las mismas (prioridad), que influirá en el cumplimiento de la misión de la UDBG en relación a los tiempos de respuesta comprometidos con nuestros clientes clínicos.
Las incidencias quedan recogidas en la base de datos correspondiente, con fecha/hora de incidencia, necesidad de personal técnico (mantenimiento interno o del proveedor), fecha/hora de llamada y fecha/hora de resolución.
Una incidencia se considera crítica cuando provoca que los tiempos de respuesta superen los límites establecidos a continuación de forma general:
1. Solicitadas desde atención primaria:
◦ Peticiones no preferentes: se considerará una incidencia crítica cuando el tiempo de respuesta supere las 48 horas para las pruebas cuyo tiempo de respuesta comprometido es inferior a 24 horas.
◦ Peticiones preferentes: se considerará crítica cuando la incidencia impida que las pruebas se informen en el día de extracción
2. Solicitadas desde el medio hospitalario:
◦ Peticiones no preferentes: se considerará crítica cuando la incidencia impida que las pruebas se informen en el día de extracción.
◦ Peticiones preferentes: se considerará crítica cuando impida que se informen antes de las 15:00 del mismo día de extracción
◦ Peticiones urgentes o de respuesta rápida: Cuando impida que el informe esté disponible antes de los 90 minutos desde la recepción de la muestra en el laboratorio.
El adjudicatario remitirá un informe mensual electrónico detallado relacionado con todas las incidencias, señalando aquellas consideradas críticas según lo indicado en los dos puntos anteriores, así como el tiempo transcurrido entendido desde que se efectúa la solicitud de soporte técnico hasta la resolución de la incidencia. En el caso de las incidencias críticas se podrá aplicar como penalización en la factura mensual un descuento correspondiente al número de determinaciones afectadas equivalentes a la carga de trabajo no realizada en el tiempo descrito anteriormente
DET - Directrices y Especificaciones Técnicas Informática 2.017
ÍNDICE
1 Objeto 64
2 Especificaciones para Desarrollo ¡Error! Marcador no definido.
2.1 Arquitectura de Referencia 65
2.1.1 Vista lógica 65
2.2 Directrices de Desarrollo 67
2.2.1 Construcción de Aplicaciones por Capas 67
2.2.2 Capa de Presentación67
2.2.3 Capa de Negocio 69
2.2.4 Capa de Persistencia 71
3 Directrices tecnológicas de IOC 74
3.1 Entorno tecnológico 74
3.2 Dispositivos de entrada/salida 76
3.3 Seguridad, acceso, autenticación y autorización 78
3.4 Monitorización 79
3.5 Backup/Restore 81
4 Interoperabilidad 81
4.1 Servicios Web 82
4.2 Gestor de Eventos 84
4.2.1 Estándares de comunicación 84
4.2.2 Mensajería. Definición de Evento 86
5 Explotación Información- Business Intelligence 87
6 Soluciones Móviles 88
6.1 Tecnologías Cliente 89
6.1.1 Apache Xxxxxxx 89
6.1.2 AngularJS 89
6.1.3 Ionic Framework 89
6.2 Tecnologías Servidor 90
6.2.1 | Nginx 90 | |
6.2.2 | Node.js | 90 |
6.2.3 | MongoDB | 90 |
7 Directrices SQA: Aseguramiento de la Calidad del Software 90
7.1 Calidad Interna 90
7.2 Calidad Externa 93
7.3 Calidad de uso 95
Este documento, DET (Directrices y Especificaciones Técnicas), contiene las Directrices y Especificaciones Técnicas de los Sistemas de Información de Osakidetza en el ámbito TIC.
El objeto es incluirlo en los Pliegos de Bases Técnicas (PBTs) de los expedientes de contratación para la adquisición, mejora, evolución o adaptación de las soluciones (producto/aplicación/desarrollo) que conforman los Sistemas de Información de Osakidetza y/o cualquier otra contratación que requiera recursos TIC que sean competencia de la Subdirección de Informática de la Dirección General de Osakidetza.
Este apartado refleja los principales aspectos del diseño técnico de la arquitectura de referencia para aplicaciones web, definida por Osakidetza.
Una arquitectura de referencia es un conjunto de patrones diseñados y probados para ser usados en un contexto específico, en nuestro caso, en los sistemas de misión crítica de Osakidetza. Es una guía de ayuda para ser usada por los arquitectos y desarrolladores, que permite conceptualizar nuevas aplicaciones rápidamente reutilizando un diseño suficientemente probado.
La arquitectura de referencia refleja las decisiones y aspectos técnicos de diseño basados en la experiencia de Osakidetza en el desarrollo, mantenimiento y evolución de aplicaciones web. El principal propósito de la arquitectura de referencia para aplicaciones web es por lo tanto, homogeneizar el desarrollo, despliegue y explotación en producción de las aplicaciones.
En este sentido, la implementación de la arquitectura de referencia aportará los siguientes beneficios perseguidos por Osakidetza:
▪ Mejorar el rendimiento de las aplicaciones.
▪ Garantizar la escalabilidad y la tolerancia a fallos.
▪ Facilitar las integraciones entre sistemas.
▪ Aprovechar las tecnologías estándares y capacidades proporcionadas por los recursos hardware y software existentes en la organización.
▪ Reducir el coste del mantenimiento (evolutivo y correctivo) mediante la simplificación del diseño de la solución y la implementación del mismo.
1.1 ARQUITECTURA DE REFERENCIA
Una de las características generales de los proyectos con éxito es que existe un diseño previo bien fundamentado que define la arquitectura general del sistema, las soluciones de infraestructura y plataforma (por ejemplo alta disponibilidad, recuperación frente a desastres, copia de seguridad y restauración, monitorización), y realiza un mapeo de requerimientos a elementos de la arquitectura.
Desde el punto de vista de sistemas de información, este requerimiento estratégico debe tener una base de arquitectura y diseño previo que permita cumplirlo durante la evolución del ciclo de vida.
Los principios de la arquitectura de referencia, describen los principios fundamentales que se han considerado para el diseño de dicha arquitectura. Los principios representan los preceptos o reglas básicas que guían el proceso de diseño.
La arquitectura de referencia se describe usando tres vistas diferentes:
▪ Vista lógica o conceptual, en la que se presenta la arquitectura mediante una visión de alto nivel que permite entender los diferentes componentes que intervienen y las interacciones existentes entre ellos.
▪ Vista de implementación, en la que se proporcionan detalles adicionales sobre la tecnología y productos para la construcción de los diferentes componentes.
▪ Vista de despliegue, en la que se describe de forma pormenorizada la información del sistema relativa a la instalación y explotación que se realiza por entornos.
1.1.1 VISTA LÓGICA
El propósito de la vista lógica es permitir un entendimiento de alto nivel de la arquitectura de referencia y de las diferentes capas y componentes en las que está estructurada. También se define la integración con otros sistemas.
Sobre esta vista lógica se deberían plasmar todos los elementos que deben ser considerados cuando se diseña una nueva aplicación.
Las aplicaciones deben de tomar este diseño como referencia e indicar:
• Las capas de la arquitectura de referencia que se implementarán
• Servicios externos con los que interactúa la aplicación
• Clientes que usarán la aplicación
• Servicios de persistencia de datos
En la siguiente figura se muestra la vista lógica de la arquitectura de referencia para aplicaciones web.
Figura 1. Vista lógica de la arquitectura de referencia
1.2 DIRECTRICES DE DESARROLLO
Se contemplan como directrices de desarrollo, las normativas, estándares y recomendaciones para la elaboración de un código fuente homogéneo, estandarizado y de calidad, con el objeto de minimizar las tareas de mantenimiento y la deuda tecnológica.
También se incorporan las especificaciones para la obtención de sistemas de información seguros, con un rendimiento óptimo y adaptado a las necesidades de las tecnologías definidas por las Arquitecturas de Software que se tomarán como referencia en los desarrollos.
A continuación se enumeran algunas de las directrices de desarrollo que deberán cumplir las soluciones desarrolladas para Osakidetza:
1.2.1 CONSTRUCCIÓN DE APLICACIONES POR CAPAS
El principal objetivo de la construcción de aplicaciones por capas, es la separación de la lógica de negocio, de la lógica de diseño. Su principal ventaja, es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sea necesario llevar a cabo algún cambio, sólo se necesita intervenir al nivel requerido.
El ejemplo clásico de este tipo de práctica y el que se contempla a nivel de directriz, es el consistente en separar las aplicaciones en tres capas: Presentación, Negocio y Persistencia.
Por lo tanto, las aplicaciones serán desarrolladas en capas; es decir, se diseñará las aplicaciones separando entre los modelos de datos, la lógica de aplicación, y la interfaz de usuario. Si optamos por esta separación de responsabilidades, podremos compartir totalmente el modelo de datos y sólo tendremos que adaptar la interfaz de usuario.
Por cada capa se consideran una serie de directrices de desarrollo basadas en el modelo de tres capas propuesto por la Arquitectura de Referencia de Osakidetza.
1.2.2 CAPA DE PRESENTACIÓN
Mediante la capa de presentación se separa la interacción del usuario respecto a la lógica de negocio.
El uso de la arquitectura en tres capas en el desarrollo de aplicaciones, ha favorecido la aparición de tecnologías que facilitan la implantación de esta capa, además de un conjunto de buenas prácticas que mejoran el proceso de su implementación.
Directrices de Desarrollo para la Capa de Presentación:
Finalidad: Presentar la información al usuario.
La capa de presentación, también llamada "capa de usuario", deberá presentar el sistema al usuario, comunicar la información necesaria y capturar la misma en un proceso que realiza un filtrado para validar los datos respecto al formato. No deberá procesar datos ni tomar decisiones.
Esta capa se comunica únicamente con la capa de negocio. También es conocida como interfaz gráfica y debe tener la característica de ser "amigable" (comprensible y fácil de usar) para el usuario.
Modularidad: Controlar la relación entre las vistas.
En una vista sólo debe hacerse referencia a otras vistas relacionadas con su funcionalidad. En ejecución, se recomienda integrar la vista con un sistema xx xxxxxxxxxx, para poder aumentar de esta manera la reusabilidad y el encapsulamiento de funcionalidades.
Internacionalización y localización: Preparar las aplicaciones para diferentes idiomas y convenciones.
Las aplicaciones estarán preparadas para que puedan adaptarse a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.), sin necesidad de realizar cambios de relevancia en el código.
Validaciones: Realizar validaciones sobre los datos introducidos por los usuarios.
La vista será la responsable de la validación inicial de los datos introducidos por el usuario. La validación debe ser obligatoria sólo para el caso xx xxxxxx y formato. Nunca deberá realizarse una validación de negocio desde esta capa.
Catálogo de controles: Elaborar un catálogo con la lista de controles.
Se especificará, si es posible, la función del control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo.
Los controles deberían permitir el tratamiento de componentes y eventos que posibiliten extraer de la vista toda la lógica de interfaz. La consecuencia principal de este enfoque, es que desde la vista nunca se manipularán los controles. El objetivo es que la construcción de la vista sea una tarea totalmente autónoma del resto de componentes de la función de negocio.
Uso xx xxxxxxxxxx: Facilitar el mantenimiento haciendo uso xx xxxxxxxxxx.
Se debe utilizar un framework xx xxxxxxxxxx (templates) en la capa de presentación, ya que de esta manera se facilita el mantenimiento del diseño de los sistemas de información. Existen frameworks que posibilitan aislar el diseño de la aplicación en un único fichero de plantilla (o más, si se necesitan). Esto facilita la tarea de hacer modificaciones en el diseño.
Controles de interfaz: Utilizar un identificador único para los controles de interfaz.
Todos los controles de interfaz, deben mantener un identificador único para facilitar su
compresión, reutilización y batería de pruebas del mismo.
Independencia entre capas: Evitar el acoplamiento entre distintas capas.
Cada capa debe tomar la responsabilidad que le corresponde. En este caso, debe evitarse que la capa de presentación realice atribuciones que le correspondan a otras capas.
1.2.3 CAPA DE NEGOCIO
La capa de negocio expone la lógica necesaria a la capa de presentación para que el usuario, a través de la interfaz, interactúe con las funcionalidades de la aplicación.
Se utilizarán componentes de negocio para abstraer la lógica de negocio de otros problemas generales de las aplicaciones, como la concurrencia, transacciones, persistencia, seguridad, etc…
Directrices de Desarrollo para la Capa de Negocio:
Reglas de negocio: Implementar las reglas de negocio en esta capa.
Los módulos que requieran una funcionalidad deberán encontrarla en un solo lugar y única versión. No debe haber réplica de funcionalidades en ninguna de las otras capas (Persistencia y/o Presentación)
Validaciones de datos: Garantizar el valor correcto de los datos.
Esta capa debe garantizar que los datos requeridos para procesarla hayan sido debidamente validados, y sólo se puede iniciar el flujo del proceso de negocio si la validación resultó correcta.
Comunicación entre capas: Definir la estrategia de comunicación entre capas.
La comunicación entre capas se debe establecer mediante objetos del modelo. Se crearán entidades sin métodos, sólo tendrán propiedades, campos y atributos, que nos servirán para almacenar información, como puede ser la asociación de las propiedades a las columnas de la base de datos.
Transacciones: Tratar convenientemente las transacciones de los datos.
La capa de modelo de datos proporciona los datos al sistema, pero las transacciones que involucren a dichos datos, se deben manejar desde la capa de negocio.
Excepciones: Encapsular en la capa de negocio las excepciones y trasladarlas de forma correcta a la capa de presentación.
El objetivo es simplificar el manejo de excepciones de la aplicación. Se recomienda tener bien definida una política para el tratamiento de excepciones y disponer de una jerarquía propia de excepciones. Como norma general, las aplicaciones no deberán nunca extender las excepciones del sistema, sino las de su propia jerarquía de clases.
Servicios encapsulados: Encapsular la capa de negocio en servicios.
Se debe encapsular la capa de negocio en servicios, para de esta forma aislar la base de datos respecto de una interacción directa con el usuario. Estos servicios de negocio conforman un "puente" entre el usuario y los datos. Responden a peticiones de usuarios u otros servicios de negocio aplicando procedimientos formales y reglas de negocio a datos relevantes.
Acceso a servicios: Controlar el acceso a los servicios en la capa de negocio.
El control de acceso al servicio de negocio debe hacerse en la capa de negocio, puesto que podemos tener distintas capas de presentación, como por ejemplo, una capa de presentación web y una capa de presentación Web Services.
El control de acceso puede realizarse tanto a nivel de método, dentro de cada servicio, como a nivel de servicio vertical.
Inyección de Dependencias: Uso del patrón de diseño ‘Inyección de Dependencias’ (DI), como forma de ‘Inversión de control’ (IoC)
La Inversión de Control (Inversion of Control en inglés, IoC) es un método de programación en el que el flujo de ejecución de un programa se invierte respecto a los métodos de programación tradicionales. En la Inversión de Control se especifican respuestas deseadas a sucesos o solicitudes de datos concretas, dejando que algún tipo de entidad o arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y para el conjunto de sucesos que tengan que ocurrir. Es el principio subyacente a la técnica de Inyección de Dependencias, siendo términos frecuentemente confundidos.
La Inyección de Dependencias (Dependency Injection en inglés, DI) es un patrón de diseño orientado a objetos, en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. La forma habitual de implementar este patrón es mediante un "Contenedor DI" y objetos planos o simples, por ejemplo los llamados POJO. El contenedor inyecta a cada objeto, los objetos necesarios según las relaciones plasmadas en un fichero de configuración. Típicamente este contenedor es implementado por un framework externo a la aplicación.
La implementación de un patrón de diseño como la ‘Inyección de Dependencias’ permite gestionar de una manera eficiente las dependencias entre los diferentes componentes de una aplicación, sin tener que recurrir a un acoplamiento no deseable entre estos.
1.2.4 CAPA DE PERSISTENCIA
La necesidad de vincular los datos guardados en una base de datos relacional, con los objetos de una aplicación orientada a objetos, determina la aparición del concepto de persistencia de objetos. Siguiendo el paradigma de desarrollo en tres capas, la persistencia queda recogida en su propia capa, separada de la lógica de negocio y de la interfaz de usuario.
La persistencia de la información es probablemente la parte más crítica en una aplicación de software y permite ejecutar operaciones en el almacenamiento persistente (base de datos). El modelo de objetos de un sistema, difiere en muchos aspectos del modelo relacional. La interfaz que une esos dos modelos se llama asociación objeto-relacional (ORM en inglés). La capa de persistencia encapsula el comportamiento necesario para mantener los objetos.
Directrices de Desarrollo para la Capa de Persistencia:
Asociación Objeto-Relacional: Usar un mapeador Objeto Relacional para implementar la capa de persistencia.
Se debe utilizar un mapeador Objeto-Relacional para implementar la capa de persistencia, ya que es una técnica que permite convertir los tipos de datos utilizados en un lenguaje de programación orientado a objetos y los utilizados en una base de datos relacional, lo que posibilita el uso de las características propias de la orientación a objetos.
Uso del patrón DAO: Crear una clase DAO por cada objeto de negocio del sistema
El patrón CRUD, reconocido como el patrón más importante del acceso a datos, indica que cada objeto debe ser creado en base de datos para que sea persistente. Para esto es necesario asegurar que existen operaciones que permiten a la capa inferior (de acceso a datos) leerlo, actualizarlo o borrarlo.
Mediante la implementación de DAO's pueden proporcionarse las operaciones CRUD necesarias para cada aplicación. No es obligatorio que cada DAO implemente todas las operaciones CRUD (puede no ser necesario en la lógica funcional del sistema). Por lo tanto, se recomienda crear un DAO distinto por cada objeto de negocio en el sistema.
Manejo de la caché: Usar la caché en las aplicaciones para reducir tiempos de lectura.
Se recomienda utilizar un sistema de caché en las aplicaciones, para reducir tiempos de lectura, ya que la mayoría de accesos de lectura acceden a una pequeña parte de los datos de la aplicación. Normalmente, hay un conjunto de datos que son relevantes a todos los usuarios y que, por lo tanto, son accedidos con más frecuencia.
Concurrencia de usuarios: Permitir la concurrencia de usuarios.
Se debe permitir que varios usuarios trabajen en la misma base de datos, protegiendo los datos de ser escritos erróneamente. En la mayoría de los casos, se utilizará el bloqueo
optimista, soportado por la mayoría de los motores de persistencia como la opción por defecto.
Referencias circulares entre objetos: Evitar las referencias circulares entre objetos de la capa de persistencia.
Se deben evitar las referencias circulares, facilitando la localización de los objetos. De esta manera, se devuelve el objeto solicitado sin necesidad de realizar un recorrido para localizarlo, lo que supone un acceso más efectivo.
Actualización en cascada: Utilizar la actualización en cascada siempre que sea posible.
Utilizar la posibilidad que ofrecen algunos frameworks para la actualización en cascada de objetos. Una actualización en cascada permite que las modificaciones hechas a un objeto se repliquen en los objetos relacionados. De esta manera se mejora el mantenimiento de los objetos, se asegura que los cambios introducidos se replican de manera eficiente y se mantiene la integridad de los datos.
Osakidetza dispone de múltiples aplicaciones desarrolladas en diversas tecnologías (principalmente Java y .Net), y albergadas en diferentes plataformas (principalmente Apache HTTP Server, Microsoft IIS y Citrix XenApp como soluciones de presentación, Oracle WebLogic y Microsoft IIS como servidores de aplicación y Oracle RDBMS y Microsoft SQL Server como servidores de BBDD).
El modelo de referencia de las aplicaciones es una solución Web (sin plug-in’s), con arquitectura de n-capas preferentemente 3 capas: presentación, negocio y persistencia, compatible con tecnología de virtualización y almacenamiento SAN y NAS.
Dicha arquitectura es escalable horizontalmente en cuanto a las capas de negocio y persistencia (reparte la carga equitativamente entre los diversos servidores que ejecutan la lógica de negocio y estos a su vez, mediante un pool de conexiones acceden a la capa de persistencia), y es tolerante a fallos garantizando la continuidad de negocio.
Los servidores que atienden a las capas de negocio y persistencia están ubicados en los dos CPDs de la Dirección General de Osakidetza siendo el reparto de los mismos proporcional en un CPD u otro; la capa de presentación está distribuida en los puestos de trabajo fijos, portátiles, móviles y tabletas en los diversos centros de Osakidetza (Hospitales, Centros de salud, etc..).
De modo que la solución (producto/aplicación/desarrollo) a suministrar deberá ser compatible con el modelo de arquitectura indicado en el párrafo anterior y con la relación de productos y tecnologías que se indican a continuación (las que apliquen).
1.3 ENTORNO TECNOLÓGICO
En conjunto, el entorno tecnológico de las soluciones actualmente en producción es:
- Plataformas de desarrollo:
▪ .NET sobre Windows 2012R2
▪ Java sobre Red Hat Enterprise Linux 7
▪ Aplicaciones móviles:
▪ Node.js, Express, AngularJS, MongoDB sobre Red Hat Enterprise Linux 7
▪ Ionic, Xxxxxxx sobre Android, iOS o WindowsPhone
- Plataforma de virtualización:
▪ VMWare vSphere 5.5
- Almacenamiento:
▪ SAN: EMC VPLEX
▪ NAS Hitachi HUS
-
- Sistemas Operativos:
▪ Servidores:
▪ Windows 2012 R2
▪ Red Hat Enterprise Linux 7
▪ Puesto de trabajo fijo: Windows 7 Enterprise N SP1 32 bits
▪ Puesto de trabajo móvil: Android, iOS, WindowsPhone
-
- Servidores Web:
▪ Apache Webserver 2.4
▪ MS IIS 8.5 (S.O. Windows 2012 R2)
▪ Oracle Web Server 11.1.1.7
▪ Web Dispatcher de SAP Netweaver 7.20
▪ Nginx 1.8.0
-
- Servidores de Aplicación:
▪ Apache Tomcat 7 + JDK 7 / JDK 8
▪ Oracle Weblogic Server 12c + JDK 8
▪ MS IIS 8.5 + .NET Framework 4.5
▪ Application Server de SAP Netweaver 7.X
▪ Node.js 4.1.0
-
- Sistemas de Gestión de Bases de Datos (*)
▪ Oracle 12c (RAC)
▪ Microsoft SQL Server 2012 (Always on)
▪ MongoDB 2.6
(*) Continuidad de negocio y Alta disponibilidad: Oracle RAC, SQL Server Always ON
-
- Gestión de contenidos:
▪ MS SharePoint 2010 Enterprise
▪ EMC Documentum 7.2
-
- Infraestructura SOA:
▪ Oracle Service Bus 12c (12.2.1) + JDK 8.0
-
- Plataforma de firma (PKI):
▪ Izenpe
- Autenticación:
▪ Directorio Activo de MS (AD)
▪ Directorio Ligero de MS (LDS)
- Puesto de trabajo fijo:
▪ Navegador: IE 8.0
▪ Office 2010 Standard
▪ Oracle Client 11gR2
▪ Java 1.6.0_23
▪ Framework 3.5 y 4.0
- Modo de ejecución/escritorio:
▪ local: puesto fijo o móvil
▪ remoto: Citrix Xen Desktop 7.6
Consideraciones en relación a los de productos y tecnologías indicados anteriormente:
- En cuanto al navegador, se debe evitar el uso de Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador.
- Al respecto de Office 2010, no está permitido el uso, dependencia o interrelación con Access.
- A corto plazo Osakidetza evolucionará:
o S.O. de Puesto de trabajo:
▪ Windows 7 a Windows 10
o Navegador:
▪ IE8 a IE11 nativo preferentemente y Enterprise Mode de IE11 para compatibilidad con IE8.
o Infraestructura SOA:
▪ Oracle Service Bus 11.1.1.7 a 12c (12.2.1) Dispositivos de entrada/salida
La solución deberá ser capaz de interactuar con diversos dispositivos de entrada y salida de diversos fabricantes; siendo dichos dispositivos: pantallas táctiles, impresoras térmicas, monitores, por tanto el interface con los mismos será en base a estándares xxx xxxxxxx.
Así mismo la solución deberá adaptarse a la resolución de las diversas pantallas.
En relación a dispositivos móviles se deben tener en cuenta ciertas particularidades en relación a las características de movilidad, tamaño, comunicación inalámbrica e interacción con las personas:
• Son aparatos pequeños.
• La mayoría de estos aparatos se pueden transportar en el bolsillo del propietario o en un pequeño bolso.
• Tienen capacidad de procesamiento.
• Tienen conexión permanente o intermitente a una red.
• Tienen memoria (RAM, tarjetas MicroSD, flash, etc.).
• Normalmente se asocian al uso individual de una persona, tanto en posesión como en operación, de modo que puede adaptarlos a su gusto.
• Tienen una alta capacidad de interacción mediante la pantalla o el teclado.
En lo que se refiere a dispositivos sobre los que tienen que ejecutar soluciones de movilidad hay dos ámbitos que son las soluciones orientadas a profesionales de Osakidetza y soluciones orientadas al ciudadano.
Las aplicaciones orientadas al ciudadano se ejecutarán en dispositivos de consumo ya sean móviles, tabletas o cualquier otro dispositivo al que vaya destinada la solución. En este caso el desarrollo deberá ejecutarse en dispositivos con los diferentes sistemas operativos que haya en el mercado.
En las aplicaciones orientadas a los profesionales de Osakidetza las aplicaciones deberán de ejecutarse en el dispositivo elegido y homologado para soportar la solución. Habrá que tener en cuenta los siguientes aspectos:
• Ergonomía, tamaño y usabilidad del dispositivo, se refiere a que cumpla las expectativas del usuario en ámbito en el que se va a desarrollar el proyecto.
• Especificaciones de limpieza y resistencia a los golpes.
• Características de comunicaciones como pueden ser conectividad Wifi y 4G.
1.4 SEGURIDAD, ACCESO, AUTENTICACIÓN Y AUTORIZACIÓN
El tratamiento de los datos cumplirá lo establecido por la legislación vigente en materia de
seguridad y protección de datos.
En el ámbito intranet se permitirá el acceso mediante los transportes RMI, JMS, HTTP y HTTPS.
El proveedor de servicios de certificación de Osakidetza es Izenpe.
Osakidetza ha dotado a todos sus profesionales de certificados corporativos reconocidos, en soporte tarjeta criptográfica, con capacidad de firma de documentos y mails, cifrado y autenticación en el AD.
Además, para los nuevos SI que necesitan firma electrónica ágil, Osakidetza ha implantado una solución horizontal de firma, basada en certificados alojados en HSMs, llamada “firma centralizada”. Son certificados con las mismas características y garantías que los alojados en tarjeta criptográfica. Estos HSM son de última generación y cumplen con las más exigentes normas internacionales (FIPS 140-2 Level 2 and Level 3, Common Criteria at EAL 4+ y RoHS compliant). Permiten la firma a través de CSP propio (applets) y la firma directa basada en una Pasarela de firma propietaria.
Izenpe es también el proveedor de la infraestructura de autenticación, validación y firma basada en certificados electrónicos. Osakidetza dispone de 2 Zain en HA (equipos TrustedX de Safelayer) en propiedad y su backup, en modo servicio, en los Zain de Izenpe. La integración con estos equipos se puede realizar mediante su librería Smartwrapper. Provee diferentes servicios web (validación, evolución de firmas, firma en servidor, etc.) alojados en los OSB de Osakidetza.
Así mismo, Osakidetza dispone de su propia infraestructura de Custodia de documentos firmados, para asegurar la validación de cualquier firma realizada en sus sistemas de información con certificados electrónicos. Está constituida por 2 equipos Siaval en HA, de la empresa SIA, y HSM Ncipher propios.
Para la firma electrónica de documentos in-situ por parte de sus pacientes, Osakidetza dispone de una solución denominada “firma biométrica”, que asegura la validez de todas las firmas implicadas. Se apoya en la solución SmartAccess de Telefónica.
Osakidetza está inmerso en la adecuación de toda su infraestructura y sistemas de información al reglamento europeo eIDAS. Tanto en cuestión de certificados como de niveles de aseguramiento (autenticación).
Los sistemas de autenticación validos son:
- Autenticación basada en Directorio Activo (Microsoft Active Directory) corporativo, que permite identificar un empleado de Osakidetza mediante usuario/contraseña o la tarjeta profesional.
- Token de Kerberos, que habrá sido emitido por el Directorio Activo corporativo.
- Autenticación basada en infraestructura de certificación digital (PKI). Esta autenticación permite la identificación de personas (certificados personales) o de sistemas de información (certificados de servidor)
- Certificados X.509 de servidor, que permitirán identificar sistemas (máquinas) y establecer confianza entre ellas.
- Certificados X.509 de cliente, que permitirán identificar individuos (personas)
- Para los servicios web, el estándar WS-Security permitirá aplicar políticas de autenticación.
- El bus de servicios sólo se utilizará para la autenticación basada en certificados
X.509 de servidor.
El sistema de autorización se implementará por medio de la definición de roles de usuario en base a los cuales se gestionarán los permisos y acciones sobre los distintos procesos por los que estará compuesta la solución. De modo que cada usuario en función del rol que tenga asignado podrá acceder a una serie de funcionalidades, así como a los datos relativos a su organización de servicio, centro de trabajo, servicio/área de atención.
Se crearán grupos de autorización del Directorio Activo. Por cada perfil que tenga la aplicación (medico, enfermera, administrativo, administrador de la aplicación,…) se creará un grupo de autorización en el DA. Se mapeará el perfil al grupo.
1.5 MONITORIZACIÓN
Osakidetza dispone de una plataforma de monitorización a través de la cual ya tiene establecida una línea de monitorización base de su infraestructura y SI.
En este sentido la solución deberá incluir un apartado en el que se describan los elementos a monitorizar para asegurar un correcto funcionamiento del sistema, servicio o
producto suministrado de forma integral dentro de la mencionada plataforma de monitorización.
La monitorización se podrá llevar a cabo a través de alguna combinación de los siguientes productos o métodos que Osakidetza integra dentro de su plataforma de monitorización:
- SCOM mediante Management Pack para sistemas Microsoft
- Instalación de agente de CA Wily Introscope para tecnología Web
- Instalación de agente de Pandora FMS para sistemas Linux, Unix
- Enterprise Manager Cloud Control para SGBD Oracle
- Mensajes SNMP
- Activación de log’s que se enviarán a un servidor virtual dedicado
Con el objetivo de monitorizar la solución que vaya a ser suministrada, deberán detallarse los objetos concretos a monitorizar para garantizar su correcto funcionamiento más allá de los aspectos generales de la infraestructura de sistemas que los alberguen; dicha relación de objetos podrá incluir, aunque no exclusivamente, algunos como:
- Procesos en ejecución
- Puertos de comunicaciones a la escucha
- Eventos concretos en registros del sistema
- Unidades de disco o File Systems
Para cada uno de ellos deberán incluirse los umbrales de consumo que se consideren anormales, especificándose 2 valores a partir de los cuales establecer el correspondiente nivel de alerta preventiva o alerta crítica según proceda.
Adicionalmente podrán suministrarse scripts o procesos para llevar a cabo:
- Pruebas sintéticas de los sistemas cuyo resultado determine el correcto funcionamiento del sistema o el correspondiente nivel de alerta preventiva
- Operativas sobre el sistema que puedan ayudar a determinar o especificar la condiciones concretas de los errores o alertas producidos.
- Operativas sobre el sistema para intentar remediar automáticamente la condición de la alerta o error, como reinicio de procesos o servicios, etc.
Todos estos procesos deberán entregarse con su correspondiente documentación, y su operativa deberá resultar sencilla de modo que pueda ser realizada por un operador.
1.6 BACKUP/RESTORE
Osakidetza dispone de una infraestructura para la realización de copias de seguridad y restauración a través de red basada en Veritas Netbackup.
De modo que la solución deberá especificar los procedimientos necesarios a llevar a cabo para la recuperación del servicio ante la pérdida del mismo, corrupción de sus datos o alguno de sus componentes. En este sentido se plantearán escenarios de recuperación independientes para cada uno de los posibles componentes impactados y el orden de ejecución en caso de que deban ejecutarse secuencialmente para la recuperación de varios componentes o del sistema completo en su conjunto.
A partir de los procedimientos anteriormente descritos y en cada uno de ellos, se inferirá los elementos concretos sobre los que se requiere hacer Backup, en qué orden, con qué frecuencia y política de persistencia deben llevarse a cabo para poder satisfacer los distintos escenarios de recuperación del servicio contemplados. Así mismo deberán indicarse las restricciones que pudieran existir para la realización del Backup: posible impacto en el servicio, restricciones horarias, etc.
Los distintos procedimientos de recuperación suministrados con la solución deberán ser validados por Osakidetza para garantizar su compatibilidad con la infraestructura de copia de seguridad y restauración existente.
Interoperabilidad
Los requisitos de integración de diversos sistemas de información de Osakidetza se realizaran de acuerdo a una arquitectura orientada a servicios (SOA) sobre la plataforma Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus (OSB), Oracle Business Rules, ...).
Dicha arquitectura proporciona una forma bien definida de exposición e invocación de Servicios Web, lo cual facilita la interacción entre diferentes sistemas propios o de terceros.
Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a Eventos; es un diseño a medida que gestiona un conjunto de sistemas que
publican eventos y un conjunto de aplicaciones que se suscriben a determinados eventos. Dicha solución se denomina Gestor de Eventos-Event Manager y es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas, enrrutar y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los elementos recibidos.
Relación de estándares de comunicación soportados:
• Protocolos a nivel de mensaje:
o SOAP 1.1 y SOAP 1.2
o WSDL 1.1 y WSDL 1.2 Binding
o SOAP con Attachments
o JSON – REST (para aplicaciones móviles)
• 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: XXXX Xxxxx 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
o WSSecurity: JWT Token (aplicaciones móviles en internet)
• 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
o HTTPS
1.7 SERVICIOS WEB
Los Servicios Web se implementarán de acuerdo con las especificaciones WSDL v1.1, SOAP v1.1, v1.2, JSON-REST (en el caso de aplicaciones móviles), 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: Xxxxxxx 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
• oracle_http_jwt_token_server_policy
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.
• Entre el OSB de intranet y el OSB de intranet, se realiza una federación de servicios con las condiciones de seguridad habituales.
Nota: OSB -> Oracle Service Bus 11.1.1.7 -> Paso a OSB 12c
1.8 GESTOR DE EVENTOS
A continuación se describen los requisitos técnicos que tienen que cumplir las aplicaciones para publicar y/o recibir eventos.
1.8.1 ESTÁNDARES DE COMUNICACIÓN
La mensajería del Servicio Osakidetza se implementará de acuerdo con las especificaciones del estándar HL7 versión 2.XX o con cualquier otro formato propio de Osakidetza; de esta manera se asegura la interoperabilidad entre los sistemas de información.
Relación de tecnologías soportadas para la publicación y subscripción a eventos.
Tecnologías que soporta el gestor de eventos para la publicación y subscripción a eventos, así como si la modalidad soporta 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 | Mensajería JMS | Sí | Sí. Event Manager garantiza la entrega en el mismo orden que ha recibido los mensajes | Autenticación (user/pass) |
Subscripción | Servicio OSB | Sí | Sí. Event Manager garantiza la entrega en el mismo orden que ha 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.
1.8.2 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, aqui 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.
Explotación Información- Business Intelligence
La herramienta usada para desarrollo de tecnología Business Intelligence es Oracle Business Intelligence Enterprise Edition (OBIEE).
Esta herramienta es una herramienta web, que está soportada por una cada de presentación en Apache, y un servidor Web (Weblogic). En esta capo web de Weblogic se definen los ROLES de usuario (grupos y perfiles de usuario) que luego se usan para la Seguridad de Acceso a Datos y a partes de la aplicación
En este servidor también se alberga el RPD, que es donde se desarrolla toda la metadata y las distintas Áreas accesibles por usuarios.
Todos los datos accesibles desde OBI están almacenados en una única BBDD de Producción.
Para realizar la carga de datos (Incremental), utilizamos la herramienta de extracción (ETL) en ODI.
Para poder realizar las cargas incrementales necesitamos que los orígenes de datos tengan alguna fecha o característica que indique que el dato se ha modificado el día anterior, y así poder hacer cargas de sólo aquello que no existe en destino o se ha modificado. (Un LAST_MODIFIED por ejemplo). Las cargas son normalmente diarias, aunque existen cargas anuales o trimestrales.
Versiones utilizadas:
• Motor Business Intelligence
o Oracle Business Intelligence 11.1.1.6.2
• Servidor Web
o WebLogic Server: 10.3.5.0 BBDD (Exadata)
o Exadata: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 - 64bit Production
• ETL
o ODI -> Oracle Data Integrator 11g Build ODI_11.1.1.7.0 GENERIC_130302.2156
Este apartado refleja las tecnologías para el desarrollo de aplicaciones móviles, definida por Osakidetza.
Comprende dos capas:
• Tecnologías para el desarrollo en cliente: aplicaciones para dispositivos móviles tales como tablets, smartphones (iOS, Android, Windows Phone)
• Tecnologías para el desarrollo en servidor: servicios para la integración con servicios backend, seguridad y lógica de negocio movilidad.
Las características comunes a todas las tecnologías de movilidad son:
- Licencia de código abierto (open source)
- Permiten el desarrollo de aplicaciones multiplataforma
- Lenguajes de programación JavaScript, XXXX0, XXX0
En la siguiente figura se muestra la vista lógica de la arquitectura de referencia para aplicaciones en movilidad.
2.1 TECNOLOGÍAS CLIENTE
2.1.1 APACHE XXXXXXX
Apache Xxxxxxx es un framework para el desarrollo de aplicaciones.
Permite a los programadores desarrollar aplicaciones para dispositivos móviles utilizando herramientas genéricas tales como JavaScript, HTML5 y CSS3.
Las aplicaciones resultantes son híbridas, es decir que no son realmente aplicaciones nativas al dispositivo (ya que el renderizado se realiza mediante vistas web y no con interfaces gráficas específicas de cada sistema), pero tampoco se trata de aplicaciones web dado que son aplicaciones empaquetadas.
2.1.2 ANGULARJS
AngularJS es un framework de JavaScript de código abierto, mantenido por Google, que ayuda con la gestión de lo que se conoce como aplicaciones de una sola página. Su objetivo es aumentar las aplicaciones basadas en navegador con capacidad de Modelo Vista Controlador (MVC), en un esfuerzo para hacer que el desarrollo y las pruebas sean más fáciles.
La biblioteca lee el HTML que contiene atributos de las etiquetas personalizadas adicionales, entonces obedece a las directivas de los atributos personalizados, y une las piezas de entrada o salida de la página a un modelo representado por las variables estándar de JavaScript. Los valores de las variables de JavaScript se pueden configurar manualmente, o recuperados de los recursos JSON estáticas o dinámicas.
2.1.3 IONIC FRAMEWORK
Ionic es un SDK completo de código abierto para el desarrollo de aplicaciones móviles híbridas. Construido sobre AngularJS y Apache Xxxxxxx, Ionic ofrece herramientas y servicios para el desarrollo de aplicaciones móviles híbridos utilizando tecnologías web como CSS, HTML5, y Sass.
Las aplicaciones pueden ser construidas con estas tecnologías Web y luego distribuidas a través de las tiendas de aplicaciones nativas para ser instalado en los dispositivos mediante el aprovechamiento xx Xxxxxxx.
2.2 TECNOLOGÍAS SERVIDOR
2.2.1 NGINX
Nginx es un servidor web/proxy inverso ligero de alto rendimiento. Actualmente Nginx se usa en más de 100 millones de sitios web.
Es un software moderno y su adopción ha sido muy rápida debido a su implementación ligera, que proporciona unos tiempos de respuesta muy bajos con un consumo de recursos hardware mínimo.
2.2.2 NODE.JS
Node.js es un entorno de programación en la capa del servidor basado en el lenguaje de programación ECMAScript (JavaScript), asíncrono, con I/O de datos en una arquitectura orientada a eventos y basado en el motor V8 de Google.
Node.js es ligero y eficiente ejecutando aplicaciones que hacen uso intensivo de grandes cantidades de datos en tiempo real y corren en dispositivos distribuidos.
2.2.3 MONGODB
Mongodb es una base de datos No SQL open source. Mongodb está orientada a documentos, en vez de guardar los datos en tablas como se hace en las base de datos relacionales, MongoDB guarda estructuras de datos en documentos tipo JSON con un esquema dinámico.rectrices SQA: Aseguramiento de la Calidad del Software
Con el objetivo de garantizar la bondad de los entregables del proyecto, Osakidetza aplicará un control de calidad a los mismos.
Dichos controles establecerán unos requisitos mínimos a cumplir dentro del ciclo de vida del software cuyo alcance incluirá la revisión documental, el cumplimiento de criterios de calidad interna, calidad externa y calidad de uso de los artefactos software.
2.3 CALIDAD INTERNA
Osakidetza realiza controles de calidad interna de código en sus aplicaciones, dichos controles constan de dos aspectos:
• Cumplimiento normativo de codificación
• Cumplimiento de métricas de ingeniería de software
En la actualidad, para la medición del dicho cumplimiento, Osakidetza utiliza la herramienta SONARQUBE.
Cumplimiento normativo de codificación
Osakidetza dispone de una normativa de codificación y buenas prácticas que se pondrá a disposición del adjudicatario y cuyo cumplimiento se exigirá en las entregas de las versiones de código. Existen distintos conjuntos de reglas de codificación en función de la tecnología de implementación (java, .net, js, html, etc)
Dichas reglas se han categorizado en función de su importancia y exigencia de cumplimiento atendiendo a la siguiente tabla.
CATEGORIZACIÓN | GRADO DE CUMPLIMIENTO |
Bloqueantes | No se aceptará ningún incumplimiento de una regla tipo BLOQUEANTE |
Críticas | No se aceptará ningún incumplimiento de una regla tipo CRITICO |
Mayores | No se aceptará un incremento de incumplimiento de reglas MAYORES con respecto a la última versión entregada de la aplicación |
Menores | No se aceptará un incremento de incumplimiento de reglas MENORES con respecto a la última versión entregada de la aplicación |
Cumplimiento de métricas de ingeniería de software
En la siguiente tabla se indican a modo resumen las métricas que se contemplarán en la validación del código. Los criterios de aceptación y rechazo se proporcionarán al adjudicatario Dichos criterios podrá variar en función de la tecnología de implementación utilizada, no obstante se proporciona las medidas mínimas exigibles, y que serán de obligado cumplimiento en todos los entregables de software.
INDICADOR | DESCRIPCIÓN | CRITERIO |
Documentación de código | % de número de líneas que contienen un comentario. | x= 30% |
Documentación de API | Número de clases, métodos (sin contar métodos de acceso como get y set) y propiedades públicas que contienen una cabecera de comentarios. En caso de Java, JavaDoc. En caso de .Net, Ndoc. Puede haber varias implementaciones. | >=80% |
Código duplicado | Número de líneas, bloques de código y archivos duplicados. | <= 5% |
Complejidad media por clase | Grado en el cual un componente o sistema tiene un diseño y/o estructura interna que es difícil de comprender, mantener y verificar. | <= 50 |
Complejidad media por método | Media de la complejidad por método. | <= 20 |
Cobertura sentencia pruebas unitarias | Número de líneas de código cubiertas por las pruebas unitarias. | >= 60% |
Pruebas unitarias correctas | Número de pruebas unitarias que se han finalizado correctamente. | >= 90% |
Deuda técnica | Concepto por el cual se estable un precio al coste | No se aceptarán incrementos de |
de corregir todos los defectos encontrados. | deuda técnica | |
Calificación SQALE | Calificación estándar de calidad basada en los resultados obtenidos por los indicadores del análisis estático. | A o B |
2.4 CALIDAD EXTERNA
Osakidetza realiza controles de calidad externa de las aplicaciones, dichos controles constan de dos aspectos:
• Plan de pruebas de la aplicación
• Cumplimiento del plan de pruebas de la aplicación
INDICADOR | DESCRIPCIÓN | DESVIACIÓN |
Plan de pruebas de la aplicación | Deberá elaborarse un plan de pruebas de la aplicación, donde se especificará y detallará conforme a la normativa de calidad de Osakidetza. | 0% |
Cumplimiento del plan de pruebas de la aplicación | Se deberá aportar evidencias de la ejecución del plan de pruebas y garantía de ausencia de defectos en las mismas conforme a los criterios de aceptación y rechazo definidos en el plan de pruebas. | 0% |
Plan de pruebas de la aplicación
El objetivo de Osakidetza con respecto a las pruebas es asegurar el resultado de las actividades de pruebas y proporcionar la base de información necesaria para las tareas a
ejecutar, definiendo los niveles y tipos de test, “que” se va a probar, “cómo” se realizarán las pruebas y “cuándo” se da por finalizado el testeo.
• Encontrar defectos (diferencia entre lo especificado y lo que “hace” el sistema)
• Comprobar que el software no provoca efectos secundarios adversos
• Identificar puntos xx xxxxx críticos en el sistema
• Identificar y clasificar riesgos
• Evaluar objetivamente la calidad de los productos testeados
• Formar los equipos de trabajo para realizar las pruebas definidas
• Presentar los resultados de las pruebas y recomendaciones para próximas etapas del proyecto
• Encontrar problemas mayores que puedan ser un riesgo para el proyecto
El Plan de pruebas de la aplicación tiene como objetivo identificar y describir el alcance de las pruebas para el nivel de testeo seleccionado y las tareas a ejecutar, durante el ciclo de vida de testeo: Planificación, Preparación, Especificación, Ejecución y Finalización.
El propósito del Plan de Pruebas es:
• Proveer un documento central donde estén identificados todos los aspectos que gobiernan el testeo con el objetivo de planificar las actividades y tener el control sobre el avance y los riesgos del testeo.
• Comunicación. Comunicar a todos los stakeholders (cualquier persona involucrada en el proyecto) el plan de pruebas con el fin de lograr la aceptación del mismo, y el compromiso para llevarlo a cabo
• Plan de alto nivel con que será utilizado por el Responsable de Calidad, Analista de Pruebas y responsables del proyecto para indicar las tareas y elaborar los planes detallados según la fase del proyecto.
En forma adicional cubre los siguientes objetivos:
• Identificar el alcance, recursos, requisitos de ambiente, riesgos, supuestos y restricciones del testeo
• Identificar los motivos principales que justifican los esfuerzos de test
• Especificar la estrategia inicial de las pruebas para cada nivel de prueba identificado
• Identificar los recursos necesarios para llevar a cabo las pruebas
• Identificar, clasificar y gestionar los riesgos del proyecto de test
Se proporcionará al adjudicatario una plantilla de Plan de Pruebas para su cumplimentación y seguimiento
Cumplimiento del plan de pruebas de la aplicación
El objetivo de Osakidetza con respecto al cumplimiento del plan de pruebas es obtener evidencias de la consecución del plan de pruebas definido en el propio plan de pruebas.
Dentro del plan de pruebas se clasificarán las pruebas por Importancia, y se exigirá la ejecución satisfactoria y sin defectos de todas las pruebas categorizadas como Alta y Media.
Riesgo / Importancia | Acciones |
Alta (Must) | Se tiene que probar |
Media (Should) | Se debe probar |
Baja (Could) | Se puede probar |
2.5 CALIDAD DE USO
Rendimiento
Se exigirá que el rendimiento de la aplicación en uso (producción) cumpla y se ajuste a los requisitos no funcionales y al plan de pruebas diseñado en etapas tempranas. En cualquier caso, el comportamiento de la aplicación deberá cumplir de forma obligatoria los siguientes criterios en la ejecución de las pruebas técnicas.
INDICADOR | DESCRIPCIÓN | DESVIACIÓN |
Prueba de | El tiempo de respuesta de la aplicación deberá mantenerse invariable con el incremento de | +/- 10% |
escalabilidad | usuarios concurrentes(a menos que exista alguna saturación de recursos del sistema), al menos hasta alcanzar la carga pico estimado. | |
Prueba de estrés | Tras someter al sistema al doble de carga nominal, tras la disminución de dicha carga a la carga normal de trabajo (80%), la aplicación deberá garantizar su estabilidad y recuperación sin necesidad de reinicio. | +/- 10% |
Prueba de estabilidad | La aplicación deberá garantizar un tiempo de respuesta estable manteniendo una carga nominal normal (80 %) durante al menos 12 h | +/- 10% |
Usabilidad
Se exigirá que la aplicación mantenga unos criterios de usabilidad que permitan:
• Facilitar el aprendizaje de la aplicación sin requerir conocimientos técnicos en su uso. El sistema deberá ser fácil de usar, asegurando unos bajos costes de aprendizaje y de asistencia o ayuda al usuario.
• Flexibilizar las posibilidades con las que el usuario y el sistema pueden intercambiar información, permitiendo la multiplicidad de vías para realizar la tarea, similitud con tareas anteriores y la optimización entre el usuario y el sistema.
• Asegurar la velocidad de uso de la aplicación permitiendo el acceso a la información en el menor número posible de clics de ratón.
• El interfaz de usuario deberá ser amigable de forma que se incremente la satisfacción y la productividad de los usuarios.
• Optimizar los costes de diseño, rediseño y mantenimiento.
La ISO 9241-11:1998 “Guidance on usability”, define la usabilidad como: " La medida con la que un producto se puede usar por usuarios determinados para conseguir objetivos específicos con efectividad, eficiencia y satisfacción en un contexto de uso concreto"
Osakidetza exigirá el cumplimiento de las directrices de la ISO 9241-151 en cuanto al cumplimiento del grado de usabilidad a exigir en el desarrollo de la aplicación
Accesibilidad
El cumplimiento de la accesibilidad de la aplicación incorporará posibilidades de navegación que garanticen el acceso a la información y a los servicios proporcionados minimizando al máximo las limitaciones y/o restricciones por razón de discapacidad de cualquier carácter o condicionantes técnicos, atendiendo así a la normativa existente.
Se deberán aplicar todas las pautas correspondientes al nivel de accesibilidad AA, llegando a un nivel AAA en las secciones que la configuración de los contenidos y diseño lo permita (Sede electrónica). La accesibilidad se regirá por las pautas WAI indicadas por el Word Wide Web Consortium (W3C).
La accesibilidad no se refiere únicamente a personas discapacitadas. Un sitio web accesible y que se adapte a diferentes tipos de usuario podrá ser visitado por más personas; esta flexibilidad también da beneficios a personas con discapacidades temporales (una convalecencia o enfermedad, problemas de visión), personas de edad avanzada, con una conexión lenta a Internet, que utilizan un dispositivo móvil, etc.
Compatibilidad y portabilidad
Osakidetza exigirá la compatibilidad de la aplicación con los siguientes navegadores web al menos en su última versión estable del fabricante y al menos dos anteriores: Internet Explorer, Firefox, Google Crome, Safari y Mozilla.
La empresa adjudicataria garantizará el funcionamiento de la aplicación con estos navegadores y se responsabilizará de la actualización de la aplicación en caso de necesidad para garantizar la compatibilidad de la misma con estos navegadores durante toda la ejecución del contrato y su periodo de mantenimiento.
El interfaz debe visualizarse independientemente del sistema operativo utilizado por el cliente.
Se exige que el diseño sea multi-dispositivo, es decir, accesible y visible desde cualquier dispositivo tipo teléfono móvil, tablet, etc.