contrato de suministro procedimiento abierto oferta

o02VerDocumentoTramiteServlet Página 1 de 75

CONTRATO DE SUMINISTRO

PROCEDIMIENTO ABIERTO

OFERTA: VARIOS CRITERIOS DE ADJUDICACIÓN

PLIEGO DE PRESCRIPCIONES TÉCNICAS QUE REGIRÁ EN LOS

CONTRATOS DE ADQUISICIÓN DE MATERIAL PARA LA

DETERMINACIÓN Y CONTROL DEL TRATAMIENTO

ANTICOAGULANTE ORAL MEDIANTE AUTOANALIZADORES

PORTÁTILES PARA LAS ORGANIZACIONES DE SERVICIOS DE

OSAKIDETZA Y EN SU AMBITO COMUNITARIO


1.- OBJETO DEL CONTRATO Mediante esta contratación se pretende cumplimentar las necesidades actuales de Material para la determinación y control del Tratamiento Anticoagulante Oral (T.A.O.) a través de la utilización de tiras reactivas, auto analizadores portátiles y sistemas informáticos de gestión de dichos tratamientos, en las Organizaciones de servicios del Ente Público Osakidetza y en su ámbito comunitario. El producto objeto de contratación se considera necesario para la prestación de asistencia sanitaria en las organizaciones de servicios de Osakidetza y en su ámbito comunitario (residencias, domicilios…). No disponiendo de medios materiales ni humanos necesarios para abastecerse se considera idónea la contratación externa. 2.- ÁMBITO DEL CONTRATO Y ORGANIZACIONES IMPLICADAS El presente contrato adjudicará para las Organizaciones del Ente Público Osakidetza y para su ámbito comunitario, la adquisición de Material para la determinación y control del Tratam iento Anticoagulante Oral mediante autoanalizadores portá tiles . Una vez adjudicado el contrato, las organizaciones de servicios concretarán con las mercantiles los lugares de entrega, la cadencia y cualquier otro extremo necesario para la adecuada garantía del suministro. 3.- CARACTERÍSTICAS TÉCNICAS TIRA REACTIVA PARA LA DETERMINACIÓN DEL TIEMPO DE P ROTOMBINA La mercantil adjudicataria proporcionará tanto los materiales consumibles (reactivos, pinchadores y/o lancetas) como la instalación y entrega de los equipos o demás dispositivos necesarios, según las necesidades de las organizaciones de servicios sanitarios de Osakidetza. La mercantil adjudicataria suministrará el software necesario según este PBT y el Anexo I SI de Información para la gestión de la terapia anticoagulante en Osakidetza. El número estimado de aparatos a entregar por la adjudicataria son 1.500, de los cuales 1.310 son las necesidades actuales y 190 en previsión de nuevas necesidades. El adjudicatario tendrá un periodo de 3 meses para entregar los coagulómetros en todos los centros de Osakidetza, excepto los correspondientes a la previsión de futuras necesidades. Además, la empresa adjudicataria deberá proveer 500 aparatos y las tiras necesarias para el programa de autocontrol del paciente en los 3 Territorios Históricos. Se entregarán 250 aparatos el primer año de contrato y los otros 250 el segundo año.


El periodo de Integración con los S.I. Corporativos de Osakidetza será de 18 meses. El equipo mínimo que deberá instalar el adjudicatario en cada puesto constará de:

� Analizadores portátiles de Tiempo de Protombina para control T.A.O. mediante el empleo de tiras reactivas y sistemas de control de calidad.

� Software de Información de datos. Mantenimiento de información histórica.

Integrado con sistemas de información de Osakidetza. � Módulo de gestión de cálculo experto de dosificación para el tratamiento de los

pacientes anticoagulados avalado y documentado por la comunidad científica. Estos contemplan los algoritmos de dosificación de la terapia que servirá de ayuda a los profesionales que lo utilicen.

Se deberá garantizar el cumplimiento de los requisitos marcados en la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal (LOPD) para todos los datos utilizados y registrados.

Los productos y equipos ofertados deberán cumplir la legislación vigente para su comercialización y utilización.

3.1 REQUISITOS MINIMOS A CUMPLIR QUE TENDRÁN CARÁCT ER EXCLUYENTE:

Corre por cuenta de la empresa adjudicataria la formación en el funcionamiento del aparato. También la empresa será responsable del mantenimiento, reparación y sustitución de los equipos. En el caso de detectarse defectos en los productos suministrados, el adjudicatario sustituirá en el plazo máximo de 24 horas dichos productos por otros del mismo tipo con la calidad adjudicada. En caso de lotes de tiras defectuosas, el adjudicatario deberá retirar y reponer todo el lote defectuoso. El adjudicatario deberá tener un soporte telefónico para los aparatos y para el software en el horario de funcionamiento de los centros (de 8:00 a 20:00h), incluido los fines de semana.

3.1.1. TIRAS:

• Estabilidad fuera del envase expuesta a temperatura, ambiente, luz y humedad: ≥ 3 horas.

• Caducidad mínima: 6 meses a partir de la entrega del producto.


3.1.2. LANCETAS:

• El pinchador o lanceta tendrá que adecuarse a la muestra de sangre necesaria.

• El número de lancetas a suministrar será un 10% superior al número de tiras.

3.1.3. COAGULOMETRO:

• Garantizar el óptimo funcionamiento del aparato expuesto a condiciones variables de temperatura, ambiente, luz y humedad.

• Volumen de muestra necesaria para la obtención del resultado de INR: ≤ 10 microlitros.

• Tiempo de obtención de resultados desde que se aplica la muestra hasta que se obtiene el resultado: ≤ 60 segundos.

• Facilitarán la identificación inequívoca del paciente mediante el identificador

único de paciente Osakidetza CIC, (Código de Identificación Corporativo) en la toma y el volcado de datos, siempre y cuando fuera necesario.

3.1.4. SOFTWARE: Alcance y requerimientos del sistema informático: A) ALCANCE:

• Software para la gestión integral del tratamiento anticoagulante de pacientes

de Osakidetza, incluyendo tanto la actividad realizada por los Servicios de Hematología de los hospitales de la red, como el seguimiento realizado en los centros de Atención Primaria y el ámbito socio-sanitario: domicilios, residencias, etc. (Integración del algoritmo de dosificación en los SI Corporativos).

El producto ofertado por los licitadores, deberá suministrarse en régimen de licenciamiento corporativo (número ilimitado de usu arios y centros).

• Servicios de Integración del producto ofertado, con los sistemas de

información corporativos de Osakidetza. La solución ofertada deberá tener capacidad de integración en tiempo real, y en base a mensajería estándar HL7, con los sistemas de información corporativos de Osakidetza.

• Servicios de Migración de información , desde la plataforma actual de Osakidetza (HyTwin de IZASA y Dosis de Roche), al nuevo sistema.

• Servicios de formación e implantación de la solució n en las organizaciones de servicio de Osakidetza y en su ám bito socio-sanitario.

• Ver Anexo I con detalles.


B) REQUERIMIENTOS

B.1 Requisitos generales • Solución con carácter Multicentro (Instalación centralizada en el CPD de la

Organización Central de Osakidetza. La BBDD será única y contendrá la información de todos los centros).

• Solución Multiidioma con posibilidad de traducción al Euskera. • Cumplimiento de legislación vigente en materia de Protección de Datos (LOPD).

• Capacidad de integración con LDAP Corporativo.

• Capacidad de integración con los sistemas de información asistenciales de

Osakidetza. Ver Anexo I. • Capacidad de integración con los autoanalizadores de coagulación en su caso y

con los coagulómetros POC (Point Of Care). • El desarrollo derivado de Integración con terceros, o licencias para conectarse con

otros sistemas serían asumidos por el licitador en el momento de la implantación.

B.2 Requisitos específicos (Funcionalidades) • Gestión de la Identificación única del Paciente en Osakidetza (CIC), integrada en

la Gestión de Pacientes de Osabide.

• Gestión de Seguridad y Accesos. Trazabilidad de todo el proceso. • Algoritmo experto de dosificación y cita, reglas y alertas de riesgo.

• Gestión de tratamiento de anticoagulación (configurable por perfil de usuario), e

integrada en las estaciones clínicas de Osakidetza y en el ámbito socio-sanitario. • Acceso vía web para usuarios externos a Osakidetza (Cliente Web).

• Módulo de gestión de autocontrol para el paciente, integrado con el sistema de

tratamiento de anticoagulación. • Citaciones y agendas multicéntricas integradas con Osabide.

• Integración de controles venosos de anticoagulación con el circuito de analíticas

de Osakidetza. • Dosificación de heparinas, fármacos antivitamina K y nuevos anticoagulantes.

Gestión de fármacos interferentes.


• Recogida y gestión de datos clínicos, complicaciones, eventos y otros datos de

laboratorio. • Informes configurables.

• Estadísticas, indicadores y explotación de datos. Básica y avanzada, global y por

centro.

• Control de calidad de la eficacia de la anticoagulación (TRT: Tiempo en Rango Terapéutico).

El precio unitario de la oferta deberá concretarse en “precio por tira ” e incluirá: la tira, la lanceta, los controles integrados, la cesión de coagulómetros, su mantenimiento, así como el software de información de datos y modulo de gestión de cálculo experto de dosificación, y cualquier otro material o dispositivo que sea necesario para el óptimo funcionamiento y quede considerado en la propuesta ofertada. También queda incluido el mantenimiento, mejoras, integraciones y servicio técnico del software. 4.- MUESTRAS Es condición imprescindible, el envío de muestras debidamente identificadas de todos los artículos ofertados con su correspondiente albarán y en el supuesto de que se quiera que le sean devueltas, especificarlo claramente. Las muestras deberán presentarse en las condiciones óptimas de conservación. Se presentarán tal y como vaya a ser suministrado el artículo a las organizaciones peticionarias.


4.1 ORGANIZACIONES DE SERVICIOS DESTINO DE LAS MUES TRAS

ARTICULOS A PROBAR

ORGANIZACIONES DE

DESTINO DE LOS ARTICULOS A PROBAR

LOTE

ARTICULO

DENOMINACION

UNIDADES (*)

1

2000020

DETERM.TIEMPO PROTOMBINA REACT+CONTROL

150 UNIDADES

C.EZKERRALDEA-

ENKARTERRI : C.S. CASTAÑOS

150 UNIDADES

OSI BILBAO-BASURTO

C.S. ARANGOITI

150 UNIDADES

C. GUIPUZKOA C.S. GROS

150 UNIDADES

H.U. CRUCES

150 UNIDADES H.U. DONOSTIA

150 UNIDADES H.U. ARABA SEDE

TXAGORRITXU

N/A

N/A

COAGULOMETRO

1 aparato**

C.EZKERRALDEA-ENKARTERRI :

C.S. CASTAÑOS

1 aparato** OSI BILBAO-BASURTO C.S. ARANGOITI

1 aparato** C. GUIPUZKOA

C.S. GROS

1 aparato** H.U. CRUCES

1 aparato** H.U. DONOSTIA

1 aparato**

H.U. ARABA SEDE TXAGORRITXU

N/A

N/A

LANCETAS

150 UNIDADES

C.EZKERRALDEA-

ENKARTERRI : C.S. CASTAÑOS

150 UNIDADES

OSI BILBAO-BASURTO C.S. ARANGOITI

150 UNIDADES

C. GUIPUZKOA C.S. GROS

150 UNIDADES

H.U. CRUCES

150 UNIDADES

H.U. DONOSTIA

150 UNIDADES

H.U. ARABA SEDE TXAGORRITXU


(*) UNIDADES A ENTREGAR EN CADA ORGANIZACIÓN (**) Si la empresa oferta más de un modelo de coagu lómetro, aportará muestras de cada

uno de ellos.

NOTA 1: Se deberá entregar 1 caja de tiras y de lancetas y 1 coagulómetro , a efectos de su constancia en el expediente de contratación , en la siguiente dirección:

Organización Central Subdirección de Compras, Obras y Servicios Estratégicos

Servicio de Contratación Álava 45 - 01006 Vitoria-Gasteiz

NOTA 2: Aquellas empresas que no presenten muestras en todas las Organizaciones destino y en la Organización Central de los artículos a probar, quedarán excluidas del proceso. NOTA 3: Las muestras presentadas serán sin cargo alguno para Osakidetza. En caso de que la empresa quiera que se le devuelva los coagulómetros o las tiras entregadas en la Organización Central deberá solicitarlo transcurridos 15 días desde la firma del contrato. Las muestras deberán estar depositadas en las direcciones abajo indicadas, siendo el último día de presentación el día de vencimiento del plazo de presentación de ofertas.

DIRECCIÓN Y TELÉFONOS DE LAS ORGANIZACIONES DE DEST INO DE LAS MUESTRAS

ORGANIZACION DIRECCIÓN LUGAR DE ENTREGA A LA ATENCIÓN DE

ORGANIZACIÓN CENTRAL Álava, 45 – 01006 GASTEIZ 1ª Planta

Contratación

Subdirección de Compras, Obras y Servicios Estratégicos

Tfn. 945006273

C. EZKERRALDEA-ENKARTERRI

C.S. CASTAÑOS General Castaños, 34 - 48920 Portugalete

Consulta Josune

Abascal.

Att.: Josune Abascal 619-458473

OSI BILBAO-BASURTO C.S. ARANGOITI Camino de Berriz, 50 - 48014 Bilbao

Consulta Rosa Maguregui

Att.: Rosa Maguregui 94-4745306

C.GIPUZKOA C.S. GROS

Avda. de Navarra, 14-16 - 20013 Donostia-San Sebastián

Consulta 210- 2º piso

Att.: Eduardo Tamayo 609-180235

H.U. CRUCES H.U. CRUCES

Plaza de Cruces, 12 48903 Barakaldo

Servicio Hematología Att.: Sara Erquiaga Tellería

H.U. DONOSTIA H.U. DONOSTIA

Pº Dr. Beguiristain, 107-111 20014 Donostia-San Sebastián

Servicio Hematología Att.: María Araiz Ramírez

H.U.ALAVA SEDE TXAGORRITXU

H.U.ARABA SEDE TXAGORRITXU C/ Jose Atxotegi, s/n - 01009 Vitoria-Gasteiz

Servicio Hematología Att.: Jesús Loza


4.2.- NORMAS PARA LA IDENTIFICACIÓN DE LAS MUESTRAS 1. Cada muestra deberá estar debidamente identificadas con:

• Número de expediente

• Número de lote (y sublote, en su caso) y código de artículo

• Nombre de la empresa ofertante

• Referencia del artículo para el proveedor

• Oferta de que se trata (Base o variante, y en este caso, VAR. 1 ó VAR. 2)

VER MODELO DE ETIQUETA (punto 7)

2. Se deberá ajustar el número de muestras al solicitado en el Pliego de Bases Técnicas. No obstante, la Comisión Técnica podrá requerir la entrega de más muestras si lo considera oportuno.

3. Las muestras que no reúnan los requisitos de identificación no serán valoradas.

4. No se aceptarán artículos que, siendo preceptiva, no contengan la referencia CE impresa.

5. Las muestras no probadas se quedarán en los diferentes Centros de recepción, salvo en los casos en que el proveedor explicite su intención de recuperación.

6. IMPORTANTE: Las muestras se deberán entregar con el correspondiente ALBARÁN

DE ENTREGA.

7. MODELO DE ETIQUETA DE MUESTRA:

La empresa ofertante la ajustará según tamaño de la muestra a aportar, teniendo en cuenta que en ningún caso deberá tapar datos esenciales del artículo.

Nº de expediente: <<expediente >>

Nº Lote: <<lote >>

Nombre empresa: <<empresa >>

Refª del proveedor: <<Refª proveedor >>

Oferta de que se trata: <<Oferta >>


5.- VARIANTES Y OFERTAS CONJUNTAS Variantes: No. Ofertas conjuntas: No 6.- PRESUPUESTO BASE DE LICITACIÓN 6.1. Determinación del presupuesto base de licitaci ón mediante precios unitarios El número de unidades previsto es estimativo, por estar subordinado a las necesidades de las organizaciones de servicios, y por tanto no se considera elemento esencial del contrato. Cualquier variación al alza o la baja, según las necesidades reales, no limitará las obligaciones del contratista ni dará lugar a compensación económica alguna. A todos los efectos se entenderá que el precio unitario estimado como máximo por la Administración 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. El precio unitario de la oferta deberá concretarse en “precio por tira ” e incluirá: la tira, la lanceta, los controles integrados, la cesión de coagulómetros, su mantenimiento, así como el software de información de datos y modulo de gestión de cálculo experto de dosificación, y cualquier otro material o dispositivo que sea necesario para el óptimo funcionamiento y quede considerado en la propuesta ofertada. También queda incluido el mantenimiento, mejoras, integraciones y servicio técnico del software.

Lote Denominación

Consumo Estimado Unidades

4 años

Precio Referid

o a

Precio base Licitación unitario

(IVA excluido)

Presupuesto Licitación (IVA

excluido) 4 años

1 TIRA REACTIVA PARA LA DETERMINACIÓN DEL TIEMPO DE PROTOMBINA 3.163.000 UND 2,2 6.958.600,00

Total 6.958.600,00

Los licitadores podrán presentar 2 tiras distintas una para uso del profesional y otra para autocontrol. El precio de ambas tiras deberá ser el mismo.


6.2. Obligatoriedad de licitar por lotes: Si. 6.3. Revisión de precios : No. 6.4. Máximo de decimales : Cuatro. 6.5. Valor estimado contrato inicial total (IVA exc luido): 6.958.600,00 € 6.6. Valor estimado modificaciones: Se prevé que pueda incrementarse el consumo por un importe de 1.739.650,00 (25%) 7.- PRESUPUESTO ESTIMADO A EFECTOS DE PUBLICIDAD Importe IVA excluido (4 años contrato inicial) 6.958.600,00 €

Valor estimado modificaciones IVA excluido 1.739.650,00 €

Valor estimado prórrogas IVA excluido (1 prórroga de 2 años) 3.479.300,00 €

Valor estimado total IVA excluido (contrato inicial + modificaciones + prórrogas) 12.177.550,00 €

8.- PROCEDIMIENTO DE ADJUDICACIÓN Procedimiento: Abierto Tramitación: Ordinaria 9.- CRITERIOS DE ADJUDICACIÓN Para la elección de los criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el presente documento, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para los servicios objeto de este expediente.


9.1.- Criterios basados en Juicios de Valor

• Valor técnico de los bienes: 50 puntos

Umbral mínimo:

Criterios A+B+C+D: 12 puntos sobre 25. Criterios E: 12 puntos sobre 25.

9.2.- Criterios basados en Fórmulas

• Precio: 50 puntos

En caso de empate en la puntuación final prevalecerá, en primer lugar, la oferta que hubiera obtenido mayor puntuación en el criterio Valor técnico de los bienes, en segundo lugar, la puntuación obtenida en el criterio Precio. De persistir el empate, éste se romperá por sorteo.

9.1.- Criterios basados en Juicios de Valor 50 PUNTOS

METODOLOGÍA Umbral mínimo: Criterios A+B+C+D: 12 puntos sobre 25. Criterios E: 12 puntos sobre 25. Se valorará/n con carácter previo el/los criterios de adjudicación de los que se haya establecido un umbral mínimo de puntuación. Las ofertas deberán superar ese umbral para continuar en el proceso de licitación y ser valoradas conforme al resto de los criterios de adjudicación.


Criterios a valorar por Juicios de valor PUNTUACION

A CARACTERISTICAS TECNICAS DE LAS TIRAS 5

A.1 Tiempo de estabilidad de la tira reactiva fuera del envase, expuesta a temperatura, ambiente, luz y humedad.

B CARACTERISTICAS TECNICAS DEL ANALIZADOR 16

B.1 Funcionamiento óptimo del aparato, expuesto a condiciones variables de temperatura, ambiente, luz y humedad. 2

B.2 Fiabilidad del aparato: Precisión y correlación con la analítica venosa 5

B.3 Volumen de muestra necesaria para la obtención del resultado de INR 1

B.4 Tiempo de obtención de resultados desde que se introduce la tira hasta que da el resultado 2

B.5 Lectura del lote y fecha de caducidad automática sin intervención alguna del usuario. 1

B.6 Peso, tamaño, cable con conexión a USB y a red eléctrica, manejabilidad, portabilidad, visualización pantalla, bluetooth, wifi y cable de red para el volcado, batería recargable.

2

B.7

Identificación automática del paciente por el CIC en la toma y en el volcado de datos, y del operador en el coagulómetro. Lectura por código de barras integrado en el coagulómetro, posibilidad de mantener fijo un identificador para el autocontrol. Posibilidad de transmitir los resultados en bloque.

2

B.8 Se valorará la adaptabilidad del coagulómetro a las diferentes necesidades de los centros (salas extracciones, plantas de los hospitales, domicilios, consultas de enfermería…).

1

C PRESTACIONES COMPLEMENTARIAS. 2

C.1 Plan de Implantación del aparato y de las tiras en el menor tiempo posible y garantizando la formación a todos los usuarios de las organizaciones de servicios de Osakidetza o ámbito socio-sanitario.

D AUTOCONTROL 2

D.1 Se valorará la calidad del proyecto de autocontrol incluido en la oferta, el material educativo y de soporte y el sistema de interconexión y gestión de los datos de paciente

E SISTEMA DE INFORMACION 25

E.1

Funcionalidades de la aplicación. Grado de cumplimiento y desarrollo de los apartados del Punto 3.1.4 B2. Funcionamiento general de la aplicación, facilidad de uso, flexibilidad y adaptación a los diferentes tipos de usuarios y entornos, velocidad y rendimiento, entorno amigable.

14

E.2 Arquitectura tecnológica propuesta Detalle de la Arquitectura Tecnológica.

� Diseño Arquitectura Hardware, detallando los elementos que componen la solución y sus interrelaciones

� Diseño Arquitectura Funcional - Detalle de los elementos funcionales que componen el aplicativo y sus

interrelaciones - Características de la aplicación:

o Servidor de Aplicaciones / Servidor web / Cliente-Servidor o Lenguaje de desarrollo

- Características de los Puestos Cliente Software de Base de Datos. Estrategias de Backup / Recovery / Alta Disponibilidad

6


PUNTUACION E.3 Estrategia de Integración

A nivel Funcional: a) Mapa de Integración entre los distintos ámbitos de la aplicación: Primaria,

Especializada, modulo de Autocontrol y Acceso Web para usuarios externos a Osakidetza.

b) Mapa de integración entre las distintas entidades a las que se hace referencia en el apartado 1.4 del Anexo I

A nivel Técnico: Tecnología y Mapa de integración con los SI de Osakidetza a los que se hace referencia en el apartado 1.4 del Anexo I (teniendo en cuenta los estándares del Anexo II)

4

E.4 Estrategia de Migración, Implantación y Plan Formativo • Plan de migración • Plan de implantación • Plan formativo

1

TOTAL 50

Cada apartado y subapartado de la valoración se redondeará a 2 decimales.

En caso de presentar dos tiras distintas según se indica en el punto 6.1 de estas bases, se valorarán individualmente las dos según criterio A y se ponderarán las valoraciones individuales según el peso del consumo estimado de cada tira indicado en el siguiente cuadro, obteniendo una única valoración para las dos tiras.

En caso de presentar dos coagulómetros distintos, uno para uso profesional y el otro para autocontrol, se valorarán individualmente las dos según criterio B y se ponderarán las valoraciones individuales según el peso del consumo estimado de cada tira indicado en el siguiente cuadro, obteniendo una única valoración para los dos coagulómetros.

Denominación

Consumo

estimado

Unidades 4

años

Peso

TIRA REACTIVA PARA LA DETERMINACIÓN DEL TIEMPO DE

PROTOMBINA 3.098.000 97,94%

TIRA REACTIVA PARA LA DETERMINACIÓN DEL TIEMPO DE

PROTOMBINA -AUTO CONTROL 65.000 2,06%

TOTAL 3.163.000 100,00%


A) CARACTERISTICAS TÉCNICAS DE LAS TIRAS

A.1 Tiempo de estabilidad de la tira reactiva fuera del envase, expuesta a temperatura, ambiente, luz y humedad.

Máximo 5 puntos.

Por cada hora que supere las 3 horas mínimas exigidas como requisito se sumará un punto.

La valoración se realizará en base a las mediciones realizadas en los centros a probar.

B) CARACTERISTICAS TECNICAS DEL ANALIZADOR La valoración de los apartados B.1, B.2 y B.4 se realizará en base a las mediciones realizadas en los centros a probar.

La valoración del apartado B.3 se realizará en base a la documentación aportada por el licitador.

La valoración de los apartados B.5, B.6, B.7 y B.8 se realizará en base a la documentación y a las muestras aportadas por el licitador.

C) PRESTACIONES COMPLEMENTARIAS. La valoración se realizará en base a la documentación aportada por el licitador.

D) AUTOCONTROL

La valoración se realizará en base a la documentación aportada por el licitador.

E) SISTEMA DE INFORMACION

La valoración se realizará en base a la documentación aportada por el licitador.


9.2.- Criterios basados en fórmulas 50 PUNTOS

VALORACIÓN ECONÓMICA: 50 PUNTOS

METODOLOGÍA Fórmula: [(C/B) x 0,85 +( (D – B)/(D – C) ) x 0,15] x A

A Puntos máximos

B Oferta de la empresa

C Oferta más baja

D Precio de licitación Si B = D se le asigna 0 puntos.

La puntuación se calculará con 2 decimales.

� Los precios unitarios se reflejarán a CUATRO DECIMALES como máximo y estará referido a la unidad de medida ofertada (unidad).

� Ninguno de los precios unitarios ofertados superarán para cada lote los precios de licitación unitarios indicados en el aparatado 6.1 del presente pliego.

10.- NÚMERO MÁXIMO DE ADJUDICATARIOS POR LOTE

El lote se adjudicará a un único licitador.

11.- GARANTÍAS PARA LA FORMALIZACIÓN DEL CONTRATO Provisional: No se requiere. Definitiva: Si.

12.- PLAZO DE GARANTÍA 6 meses.


13.- PLAZO DE EJECUCIÓN 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 un periodo de dos años. Plazo total de ejecución (inicial más prórroga, en su caso): hasta seis años. 14.- PLAZO DE ENTREGA DE LOS APARATOS Será como máximo de 3 meses desde la adjudicación del Concurso (incluyendo la formación). El periodo de despliegue del Software en todos los centros, incluyendo migración de datos y la Integración con los S.I. Corporativos de Osakidetza será de 18 meses. En el programa de autocontrol del paciente se entregarán 250 aparatos el primer año de contrato y los otros 250 el segundo año. Por el adjudicatario se hará entrega en cada Centro de los correspondientes manuales de instrucciones, operaciones y “mantenimiento de usuario”. Todos los equipos o demás dispositivos necesarios a la finalización del contrato quedarán en propiedad de Osakidetza. 15.- PLAZO DE ENTREGA DESDE LA FECHA DE LOS PEDIDOS El plazo de entrega será como máximo de 2 días naturales a partir de la fecha de notificación de cada pedido. 16.- LUGAR Y ENTREGA DEL SUMINISTRO El contratista estará obligado a entregar los bienes objeto del suministro en el lugar que se designe por cada una de las organizaciones de servicios de Osakidetza o ámbito socio-sanitario. La prestación del suministro incluye el transporte de los productos hasta los centros a cargo de la empresa adjudicataria. Los gastos de la entrega y transporte de los bienes objeto del suministro al lugar fijado serán de cuenta del contratista.


17.- DOCUMENTACIÓN A INCLUIR EN LOS SOBRES 17.1. EN EL SOBRE C (CRITERIOS BASADOS EN JUICIOS D E VALOR) La documentación ha de presentarse adecuadamente ordenada 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. Se podrá, asimismo, incorporar otra documentación sobre características no requeridas, con objeto de cumplimentar un mejor conocimiento de la oferta presentada. Estas deberán ser recogidas en un capitulo aparte consignando como “otra documentación incorporada ”. En la documentación técnica los licitadores incluirán de forma expresa:

� Cumplimiento del Real Decreto 1662/2000, de 29 de s eptiembre, por el que se regulan los productos sanitarios para diagnóstico < <in Vitro>>. Así mismo, se tendrá en cuenta otra normativa relacionada con condiciones de fabricación, importación, comercialización, distribución, venta, etc…, que sea de obligado cumplimiento. En este sentido, deberán contar con productos que ostenten el marcado CE, o aportarán información sobre su no aplicación y la fecha de entrada en vigencia (Disposición transitoria primera del Real Decreto 1662/2000). Deberán aportarse copias de estos documentos y una Declaración Jurada o Certificación de la persona que suministra el producto del cumplimiento de los requisitos esenciales basada en la citada Declaración de Conformidad, todo ello en castellano o bien acompañado de traducción, esta última firmada por el apoderado de la empresa.

� Cumplimiento de la normativa específica.

� Las mercantiles aportarán las acreditaciones sanitarias perceptivas, establecidas

en la normativa vigente respecto a la fabricación y comercialización del producto que presenten.

� Cuando el licitador sea un representante autorizado, lo documentará

expresamente.

� Cumplimiento características requeridas, Punto 3 de estas Bases Técnicas.

� Documentación necesaria para la valoración de los Juicios de Valor. Punto 9.1.

� Descripción detallada de las características del producto (reactivos y otros productos consumibles necesarios) objeto de la licitación. Por cada elemento se incluirá descripción técnica, necesidades y condiciones de almacenaje, caducidad, características de conservación si las hubiere, etc.

� Descripción detallada del procedimiento y fundamento (sensibilidad y especificidad

de la prueba, rangos de la determinación, etc.)

� Descripción técnica detallada de cada uno de los elementos del equipamiento y características de calibración. Condiciones idóneas de uso del equipo.

� Descripción detallada del software de Información de datos y sistema experto en

dosificación.


� Planificación de la instalación de los equipos, puesta en marcha de los mismos y formación del personal.

� Plan de revisiones preventivas de los equipos (calendario anual de revisiones, que

tendrá un intervalo lógico entre ellas, duración, operaciones a realizar en las mismas, etc.)

� Existencia de una adecuada capacidad logística (recursos propios o concertados) para la entrega de los pedidos en las dependencias hospitalarias o comarcas de Osakidetza. Descripción somera de la estructura de recursos de la empresa puesta a disposición del presente procedimiento y ubicación de su sede más próxima. Se especificarán compromisos de suministro de material en tiempos máximos.

� Asesoramiento disponible en caso de ser necesario.

� Criterios generales de control y aseguramiento de la calidad por la empresa en los

diferentes procesos (Ejemplo: Certificaciones ISO).

� Para la valoración de los puntos E2, E.3 y E.4 se incluirá la documentación (en castellano) organizada como se indica a continuación:

E.2 Arquitectura tecnológica propuesta

Detalle de la Arquitectura Tecnológica. � Diseño Arquitectura Hardware, detallando los elementos que componen la

solución y sus interrelaciones � Diseño Arquitectura Funcional

- Detallando los elementos funcionales que componen el aplicativo y sus interrelaciones

- Características de la aplicación: o Servidor de Aplicaciones / Servidor web / Cliente-Servidor o Lenguaje de desarrollo

- Características de los Puestos Cliente Software de Base de Datos. Estrategias de Backup / Recovery / Alta Disponibilidad

E.3 Estrategia de Integración

A nivel Funcional: c) Mapa de Integración entre los distintos ámbitos de la aplicación: Primaria,

Especializada, modulo de Autocontrol y Acceso Web para usuarios externos a Osakidetza.

d) Mapa de integración entre las distintas entidades a las que se hace referencia en el apartado 1.4 del Anexo I

A nivel Técnico: Tecnología y Mapa de integración con los SI de Osakidetza a los que se hace referencia en el apartado 1.4 del Anexo I (teniendo en cuenta los estándares del Anexo II)

E.4 Estrategia de Migración, Implantación y Plan Formativo

• Plan de migración • Plan de implantación • Plan formativo

•


� Otra documentación técnica, catálogos y folletos en castellano, o en su defecto con traducción del contenido.

� Se cumplimentará el Modelo de Descripciones Técnicas de este Pliego, donde se

especificarán el Nombre comercial, cada una de las referencias que se oferten y presentación, que podrá descargarse del perfil del contratante junto con el resto de documentación administrativa del expediente. Deberá estar firmado por el apoderado y se presentará en doble soporte: papel y digital (CD-ROM). El modelo podrá descargarse del perfil del contratante.

17.2. EN EL SOBRE B (CRITERIOS BASADOS EN FORMULAS)

� Se cumplimentará el Modelo de Proposición Económica, que podrá 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 (CD-ROM).

� En caso de discrepancia entre los datos de los modelos en papel, con los del formato digital, prevalecerán aquellos.

� Para cada referencia ofertada se incluirá el código EAN/GTIN13.

18.- RÉGIMEN DE SUSTITUCIÓN DE BIENES OBJETO DE SUM INISTRO Durante la vigencia del contrato, los adjudicatarios están obligados a proponer sustituciones de los productos, materiales seleccionados, software por otros que incorporen avances o innovaciones tecnológicas que mejoren las prestaciones o características de los adjudicados, siempre que su precio sea igual o inferior al vigente en el momento de la propuesta de sustitución y cumplan con los requisitos legales y administrativos determinados en la contratación del artículo primitivo. En todo caso, el órgano de contratación, por propia iniciativa y con la conformidad del suministrador, o a instancia de éste, tiene la facultad de incluir nuevos bienes del tipo adjudicado o similares a los adjudicados cuando concurran motivos de interés público o de nueva tecnología o configuración respecto de los adjudicados, cuya comercialización se haya iniciado con posterioridad a la fecha límite de presentación de ofertas, siempre que su precio no exceda del límite que se establece en el apartado anterior y dispongan de los requisitos legales y administrativos determinados en la contratación base. El órgano de contratación resolverá sobre la petición solicitada para estos supuestos mediante resolución y en el caso de baja o sustitución implicará la exclusión automática del bien cuya baja haya sido acordada o del bien sustituido.


19.- FACULTAD DE INSPECCIÓN El órgano de contratación, directamente o a través de la entidad que considere más idónea por su especialización, tiene la facultad de inspeccionar y de ser informado del proceso de fabricación o elaboración del producto objeto del contrato, pudiendo ordenar análisis, ensayos y pruebas de los materiales a emplear, así como establecer sistemas de control de calidad, dictando cuantas disposiciones estime oportunas para el cumplimiento de lo convenido. El contratista está obligado a asumir los gastos de comprobación de materiales, vigilancia del proceso de fabricación y/o distribución, si procede, y de los materiales, personal, transporte, entrega, gastos de instalación y formación del personal propio de los Centros que determine el órgano de contratación. 20.- OTRAS ESPECIFICACIONES DEL CONTRATO Si durante la vigencia del contrato o contratos resultantes de este procedimiento, el adjudicatario viniera a ofertar unas condiciones económicas más ventajosas a las incluidas en el contrato en vigor, por razones de interés público se procederá a modificar el contrato de acuerdo a las mismas. En todo caso, las empresas que resulten adjudicatarios en el presente expediente vendrán obligados a notificar y aplicar a las Organizaciones de Servicios de Osakidetza cualquier condición más favorable o cualquier oferta a un precio menor que se derive de la tramitación y adjudicación de un expediente de contratación declarado por el Ministerio de Sanidad, Política Social e Igualdad de adquisición centralizada en el ámbito estatal para los productos incluidos en el presente expediente, procediéndose en su caso a modificar el contrato de acuerdo a las mismas. En Vitoria-Gasteiz, a 1 de julio de 2014


ANEXO I

SI de Información para la gestión de la terapia ant icoagulante en

Osakidetza

Requisitos Tecnológicos


1. El software para la Gestión del Historial de Ant icoagulación del paciente en Osakidetza, contemplará las siguientes tareas:

• Análisis del Sistema

• Parametrización/Adecuación del software

• Migración de información histórica

• Integración con el Sistema de Información Asistencial

• Implantación del proyecto

• Formación en la herramienta

1.1 Análisis del Sistema

El propósito de esta actividad será, describir el alcance, los objetivos y los requisitos del Sistema.

En esta fase se analizará el proceso de migración de datos de los sistemas existentes al actual aplicativo.

1.2 Parametrización Adecuación del software

Adecuación y/o parametrización del producto de acuerdo a las definiciones funcionales y a las características del entorno.

En este apartado los licitadores deberán detallar la capacidad de adecuación del producto a los requerimientos de Osakidetza, así como las garantías que ofrece el licitador ante la edición de nuevas versiones del mismo.

1.3 Migración de información Histórica

Se realizarán las tareas de migración de la información histórica de los actuales sistemas de información de Osakidetza, HyTwin, HytGold de IZASA, Dosis de Roche

1.4 Integración con los S.I. Corporativos de Osakid etza

Análisis y desarrollo de la integración necesaria con los sistemas de información asistenciales de Osakidetza , entre los que destacan:

1.4.1. e-Osabide. Atención Especializada La integración con el HIS corporativo de Osakidetza debe de ser completa, de forma que la información administrativa resida en un único lugar y no se produzcan redundancias.

Desarrollo propio: plataforma de desarrollo J2EE y SGBD Oracle.


1.4.2. Osabide Global. Atención Especializada Sistema corporativo, que se consolida como la Estación Clínica de Osakidetza , extendido actualmente a la Atención Especializada. La integración en la estación clínica será plena. El SI que gestione el Historial de Anticoagulacion del paciente se invocará como una funcionalidad más de la estación (no necesario login), realizándose el paso de parámetros necesario para que la gestion sea inteligente (datos clínicos), y se identifique tanto al paciente y su proceso, como al profesional (perfil), que accede. Cualquier evento relacionado con la entrada/salida de un paciente en el circuito de Anticoagulacion será notificado mediante el Gestor de Eventos de Osakidetza a la estación clínica de forma que pueda ser informado en el módulo de Alertas de dicho SI Desarrollo propio: plataforma de desarrollo .NET y SGBD Oracle.

1.4.3. Osabide-AP. Atención Primaria Sistema corporativo de Osakidetza para la gestión de la Atención Primaria, incluye gestión administrativa e Historia clínica.

La integración en la estación clínica será plena. El SI que gestione el Historial de Anticoagulacion del paciente se invocará como una funcionalidad más de la estación (no necesario login), realizándose el paso de parámetros necesario para que la gestion sea inteligente (datos clínicos), y se identifique tanto al paciente y su proceso, como al profesional (perfil), que accede.

Desarrollo propio: plataforma de desarrollo .NET y SGBD Oracle.

1.4.4. CLINIC. Visor de Historia Clínica

Osakidetza dispone de un software propio denominado Clinic, que permite una navegación sencilla por la información clínica de un paciente.

Desarrollo propio: plataforma de desarrollo .NET, y SGBD Oracle.

1.4.5. PRESBIDE. Sistema de Prescripción Universal Sistema corporativo de Osakidetza para la gestión de la Prescripción Ambulatoria (Receta), integrado con el sistema de Receta Electrónica de Sanidad.


1.4.6. Sistemas de Información de Laboratorio Osakidetza dispone de una solución comercial, para la gestión del Sistema de Información de laboratorio.

En la actualidad las estaciones clínicas se integran con los sistemas de laboratorio corporativos de Osakidetza , tanto para la gestión de solicitud de pruebas analíticas, de Microbiología, Hematología y de Bioquímica, como para la consulta de resultados de las pruebas, a través de la solución propia de Osakidetza.


1.4.7. Sistemas Externos Sistema corporativo de Osakidetza para el almacenamiento y consulta de documentación clínica.

Desarrollo propio: plataforma de desarrollo .NET y SGBD Oracle.

1.4.8. Carpeta de Salud Sistema corporativo de Osakidetza que habilita el acceso del paciente a su Historia Clínica, permitiendo la incorporación de información, si este lo deseara.


1.5 Implantación del proyecto Una vez desarrollada la aplicación se deberá pasar a producción el sistema, para lo cual será necesaria la coordinación para su implantación e integración.

1.6 Formación en la herramienta Se incluye dentro del proyecto la formación en la herramienta, para lo cual los licitadores deberán detallar el Plan Formativo, especificando, mínimamente: • Tipo de formación (usuario final, formación a formadores, etc.) • Perfiles a formar • Duración de las sesiones /perfil

1.7 Gestión Incidencias y Solicitudes Para realizar la gestión del conjunto de actividades de soporte y atención a consultas e incidencias técnicas y funcionales de usuarios, respecto a la aplicación objeto del contrato, se utilizarán las siguientes herramientas

• Registro, seguimiento y resolución de los errores de las aplicaciones detectados, mediante la aplicación de gestión de incidencias corporativa de Osakidetza.

• Registro, seguimiento y resolución de las peticiones registradas en la herramienta de gestión de la demanda corporativa de Osakidetza.

2. ESTÁNDARES TECNOLÓGICOS Ver anexo II. Los licitadores deberán especificar en su oferta los requisitos del hardware necesario para la implantación del producto.


ANEXO II

DIRECTRICES TECNOLOGICAS DE OSAKIDETZA

Para verificar que una solución (producto/aplicación/desarrollo) esta alineado tecnológicamente

con las directrices que se indican a continuación.

1. Arquitectura y tecnológica

El proveedor definirá la arquitectura de la solución y especificará los componentes lógicos y

físicos de la misma, así como el diagrama de capas lógicas y su distribución en la

infraestructura, los productos software y/o hardware requeridos, protocolos utilizados,

necesidades de comunicación (apertura de puertos, balanceadores, …), siguiendo las

directrices de Osakidetza que se indican a continuación; será validada por las áreas de

Arquitectura, e Infraestructuras, Operación y Comunicaciones de Osakidetza.

El diseño de la arquitectura será escalable y garantizará el cumplimiento de la normativa de

seguridad y de planes de contingencia de Osakidetza, garantizando el óptimo rendimiento de la

solución ofertada sobre dicha arquitectura.

El diseño de arquitectura se realizará para los entornos de:

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

- Producción

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

de Osakidetza.

1.1 Consideraciones Tecnológicas

La solución (producto/aplicación/desarrollo) será una solución Web (sin plug-in’s), con

arquitectura de n-capas preferentemente 3 capas: presentación, negocio y persistencia.

Plataformas de desarrollo de la solución:

� .NET sobre Windows 2008R2

� J2EE sobre Red Hat Enterprise Linux 6.4


El albergue de las capas de negocio y persistencia será centralizado y la capa de presentación

distribuida.

La relación de tecnologías sobre las que se implantarán y ejecutarán las diversas capas de la

solución (versiones mínimas), son:

� Capa de Presentación - Puesto cliente :

Cliente ligero (HTML5)

Características del puesto:

o Windows 7 Enterprise N SP1 32 bits

o Internet Explorer 8.0 (Ver *)

o Office 2010 Standard (Ver **)

o Oracle Client 11gR2

o Java 1.6.0_23

o Framework 3.5 y 4.0

(*) En cuanto al navegador, se debe evitar el uso de Applets (Java), componentes

ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de

software embebido en el navegador.

(**) Al respecto de Office 2010, para el desarrollo de aplicaciones corporativas, no esta

permitido el uso, dependencia o interrelación con Access.

� Capa de Negocio - Servidores Web y de Aplicaciones:

o Aplicaciones J2EE / Weblogic 11g

Aplicaciones J2EE que requieran de funcionalidades específicas de Oracle

Weblogic Server 11g, que hagan uso de EJBs o colas JMS, o que se apoyen en una

base de datos Oracle RAC.

Se deberá certificar la compatibilidad de la aplicación con la siguiente matriz,

correspondiente a los distintos productos y componentes empleados en los

servidores sobre los que se desplegará la aplicación:


Componente Versión

Sistema Operativo Red Hat Enterprise Linux 6.4 (64bits)

JVM JRockit R28.2.5

Oracle Weblogic Server 10.3.6

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

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

o Aplicaciones J2EE / Tomcat

Aplicaciones J2EE que no requieran despliegue sobre OWLS (Oracle Weblogic

Server) 11g.

Se deberá certificar la compatibilidad de la aplicación con la siguiente matriz,

correspondiente a los distintos productos y componentes empleados en los

servidores sobre los que se desplegará la aplicación:

Componente Versión

Sistema Operativo Red Hat Enterprise Linux 6.4 (64 bits)

JVM JRockit R28.2.5

Tomcat 6.0.32

Tipo DataSource Se requiere el uso de un Pool de Conexiones

definido por la aplicación *

Driver Acceso a BBDD Ojdbc6.jar

* Ver apartado de Conectores

o Frontales Web para aplicaciones J2EE

El acceso a una aplicación desplegada en instancias de OWLS se realizará siempre a

través de uno o varios servidores Apache que actúen como frontal web. Estos

servidores contarán con los siguientes componentes y versiones:


Componente Versión

Sistema Operativo Red Hat Enterprise Linux 6.4 (64bits)

Servidor Web Apache Webserver 2.2.25

Plugin de Salto

(Para OWLS11g)

Apache HTTP Server Plugin 1.1 (WLSPLUGINS_11.1.1.6.0_LINUX.X64_111122.1115.0001)

Plugin de Salto

(Para Tomcat)

Apache Tomcat Connector (mod_jk 1.2.32)

o Aplicaciones .NET / Internet Information Server

Aplicaciones .NET que requieran despliegue como aplicación web sobre servidores

Internet Information Server, deberán certificar compatibilidad con la siguiente matriz:

Componente Versión

Sistema Operativo Windows 2008 R2 Enterprise (64bits)

.NET Framework 4.0

Internet Information Server 7.5.7600.16385

Windows Server App Fabric

6.1

Sharepoint Server 2010 Enterprise

Acceso a BBDD Oracle ó SQL Server

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

- ADO.NET / LINQ

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

o Servidor BD

Servidor BD Alta disponibilidad

Oracle 11.2.0.3 � con parada: Stanby


� sin parada: RAC 11.2.0.3

Microsoft SQL Server

Enterprise 2008

� S.O.: Cluster Windows 2008R2

� BD: Mirroring

o Conectores:

Servidor de Aplicaciones Base de Datos Características

J2EE / OWLS 11g

Oracle Database (Single Instance)

Se deben utilizar DataSources de tipo GridLink , apoyándose en el driver "Oracle’s Driver Thin para Oracle Databases 9.x, 10.x, 11.x" Oracle Database (RAC)

J2EE / Tomcat Oracle Database (Single Instance)

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

.NET / IIS, WCF Oracle Database (Single Instance) Cliente de Oracle “64-bit ODAC 11.2

Release 4 (11.2.0.3.0)” Oracle Database (RAC)

Microsoft SQL Server 2008 ADO.NET

1.2 Dispositivos de entrada/salida

La solución deberá ser capaz de interactuar con diversos dispositivos de entrada y salida de

diversos fabricantes; siendo dichos dispositivos: pantallas táctiles, impresoras térmicas,

monitores,… Por tanto el interface con los mismos será en base a estándares del mercado.

Así mismo la solución deberá adaptarse a la resolución de las diversas pantallas.

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

Los sistemas de autenticación validos serán:

- Autenticación basada en Directorio Activo (Microsoft Active Directory)

corporativo, que permite identificar un empleado de Osakidetza mediante

usuario/contraseña o la tarjeta profesional.

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

- Autenticación basada en infraestructura de certificación digital (PKI) . Esta

autenticación permite la identificación de personas (certificados personales) o de

sistemas de información (certificados de servidor)

- Certificados X.509 de servidor , que permitirán identificar sistemas (máquinas) y

establecer confianza entre ellas.

- Certificados X.509 de cliente , que permitirán identificar individuos (personas)

- Para los servicios web, el estándar WS-Security permitirá aplicar políticas de

autenticación.

- El bus de servicios sólo se utilizará para la autenticación basada en certificados X.509

de servidor.

El sistema de autorización se implementará por medio de la definición de roles de usuario en

base a los cuales se gestionarán los permisos y acciones sobre los distintos procesos por los

que estará compuesta la solución. De modo que cada usuario en función del rol que tenga

asignado podrá acceder a una serie de funcionalidades, así como a los datos relativos a su

organización de servicio, centro de trabajo, servicio/área de atención.

Se crearán grupos de autorización del Directorio Activo. 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.4 Monitorización

La solución incluirá un apartado de monitorización en la que se detallen los elementos a

monitorizar para asegurar un correcto funcionamiento del sistema, proporcionando los scripts

necesarios para que la operativa del sistema pueda ser realizada por un operador, así como los

scripts de arranque y parada.

La monitorización se puede realizar a través de:

- SCOM mediante Management Pack para sistemas Microsoft


- Instalación de agente de CA Wily Introscope para tecnología Web

- Instalación de agente de Pandora FMS para sistemas Linux, Unix

- Enterprise Manager Cloud Control para SGBD Oracle

- Mensajes SNMP

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

1.5 Backup/Restore

Identificación de los elementos sobre los que hacer backup, frecuencia y política de

persistencia de los mismos, así como restricciones para la realización de estos backups.

Así mismo se deberá indicar el procedimiento de recuperación de la solución, que será validado

por Osakidetza.

Nota: el hardware y herramientas de backup son provistas por Osakidetza

2. Interoperabilidad

Ver Anexo III.

3. Alineamiento con las Directrices Tecnológicas

Para verificar que una solución (producto/aplicación/desarrollo) esta alineado tecnológicamente

con las directrices anteriormente indicadas, se debe entregar la siguiente documentación:

• Procesos de negocio.

• Flujo de información entre los diferentes componentes de la solución.

• Documentación Técnica de la solución (*acorde al punto 1)

Debe incluir la arquitectura de la solución especificando los componentes lógicos y

físicos de la misma, así como el diagrama de capas lógicas y su distribución en la

infraestructura, los productos software y/o hardware requeridos, protocolos

utilizados, necesidades de comunicación (apertura de puertos, balanceadores, …),

etc

• Especificaciones hardware y software necesarias para la implantación de la solución,

acorde al uso (usuarios, concurrencia, disponibilidad, volumetría/almacenamiento, ..)


Cada entregable deberá figurar en un documento, según el orden y títulos indicados en la

relación anterior.


ANEXO III

Especificaciones de Interoperabilidad

Requisitos Técnicos


1. Introducción Osakidetza ha adoptado el paradigma SOA como la solución corporativa para la integración de servicios y clientes. La arquitectura orientada a servicios (en inglés Service Oriented Architecture), es un concepto de arquitectura de software que define la utilización de servicios para dar soporte a los requisitos del negocio. Permite la creación de sistemas de información altamente escalables que reflejan el negocio de la organización, a su vez brinda 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. El siguiente documento contiene las definiciones respecto a los servicios web que Osakidetza pondrá a disposición para que las Empresas Usuarias puedan integrarse con los Sistemas de información de Osakidetza. Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a eventos (Event-driven SOA).


2. Arquitectura orientada a servicios

2.1. Resumen de los estándares soportados Los estándares de comunicación soportados por la infraestructura SOA actual de Osakidetza son:

• 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 SOAP MTOM

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

• Protocolos a nivel de transporte: o HTTP 1.0, HTTP 1.1, o TLS, SSL o Interoperabilidad con registros UDDI v3-compliant o Sistemas middleware basados en JMS/MQ.

2.1.1. Protocolos a nivel de mensaje SOAP (siglas de Simple Object Access Protocol) es un protocolo estándar que define cómo dos objetos en diferentes procesos pueden comunicarse por medio de intercambio de datos XML. El protocolo SOAP tiene tres características principales:

• Extensibilidad : seguridad y WS-routing son extensiones aplicadas en el desarrollo.

• Neutralidad : SOAP puede ser utilizado sobre cualquier protocolo de transporte como HTTP, SMTP, TCP o JMS.

• Independencia : SOAP permite cualquier modelo de programación. Los Servicios Web del Servicio Osakidetza se implementarán de acuerdo con las especificaciones WSDL v1.1, SOAP v1.1, v1.2, UDDI v2.XX y XML v1.0, esto 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 utilizan en los mensajes XML es UTF-8.


2.1.2. Protocolos de seguridad a nivel de mensaje Osakidetza dispone de una arquitectura SOA para gobernar y orquestar los servicios disponibles en la organización. Esta arquitectura incluye la implementación y gestión de la seguridad de forma centralizada. La seguridad aplicada a los servicios web cubre los siguientes aspectos:

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

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

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

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

2.1.3. Política de autenticación y protección de me nsaje en internet Osakidetza usa Oracle Web Service Manager (OWSM) para gestionar y aplicar políticas a los servicios corporativos 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

En la siguiente figura se muestra el uso de las políticas de OWSM en la arquitectura general.


• Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a través del 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 sevicios a los que pueden acceder las aplicaciones de internet.

• El OSB de internet audita todas las llamadas a los web services 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.

• La aplicación consumidora de servicios web deberá tener en cuenta que es necesario disponer de un certificado de aplicación cliente válido para poder invocar a los servicios web.

• Las llamadas a servicios web, siempre a través del OSB dedicado para el ámbito de Internet / DMZ, se deberán realizar mediante protocolo seguro (HTTPS) y aplicando las políticas de seguridad WSS correspondientes a la firma y autorización descritas.

2.2 Requisitos funcionales A la hora de publicar un nuevo servicio, es necesario rellenar el contrato de servicio y previo desarrollo, enviarlo a Osakidetza para su supervisión. El servicio deberá cumplir los standares de nomenclatura y especificaciones definidas para servicios desde Osakidetza. Finalmente se deberá realizar la solicitud para que se efectúe el alta en el OSB de Osakidetza.


3. Arquitectura orientada a Eventos

3.1 Propósito Se recogen los requisitos técnicos que tienen que cumplir las aplicaciones para publicar y/o recibir eventos del gestor corporativo de eventos de Osakidetza (Event Manager). Este manual se complementa con “DOC001 - Event Manager - Manual de desarrollo.pdf”.

3.2 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 superior, o con cualquier otro formato propio de Osakidetza y de esta manera asegurar la interoperabilidad entre los sistemas. Para dar soporte al envío de mensajería a diferentes sistemas subscriptores Osakidetza dispone una capa de arquitectura denominada Gestor de eventos –Event Manager.

3.3 Alcance Esta información contiene información destinada los siguientes perfiles:

• Arquitectos - responsables de la toma de decisión de diseño y arquitectura de aplicaciones

• Desarrolladores – encargados de implementar la integración de aplicaciones con el gestor de eventos, ya sea para la publicación o subscripción.

3.4 Arquitectura de Event Manager La figura 2.1 representa la arquitectura de alto nivel de Event Manager. La solución permite gestionar un conjunto de sistemas que publicarán eventos y otro conjunto de aplicaciones que estarán subscritas a determinados eventos. Event Manager es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los eventos recibidos. Event Manager se implenta sobre Oracle Service Bus desplegado sobre Oracle WebLogic Server. Los sistemas de publicación y subscripción pueden ser internos o externos a OSB. La solución soporta un conjunto determinado de tecnologías y protocolos de publicación y subscripción.


Figura 2.1 : Arquitectura de alto nivel del gestor de eventos OSB

Este documento recoge los requisitos técnicos necesarios para que diferentes aplicaciones y sistemas de información puedan realizar la publicación y subscripción de eventos. La tabla siguiente contiene las diferentes tecnologías que soporta el gestor de eventos para la publicación y subscripción a eventos, así como si la modalidad soporta transaccionalidad y las opciones de seguridad disponibles. Modalidad Tecnología Transaccional Orden Seguridad

Publicación Mensajería JMS Sí Sí, si el publicador establece el parámetro

UnitOfOrder

Autenticación (user/pass)

Publicación Servicio web Sí No Ninguna, Autenticación

(user/pass) y WS-Security

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

recibido los mensajes incluso en

situaciones de error de comunicación con el

suscriptor

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


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

• even: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.

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

• even: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.

• even:timestamp : Lo establece el publicador del evento en el momento del envío.

• even: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.

• even: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.

Los códigos de error y su descripción se listan en la siguiente tabla:


Código Mensaje Descripción

EventBroker-01 Unsupported message type

El tipo de mensaje del evento no está soportado. Este tipo de error es interno de Event Manager y no es común que se reproduzca porque la asociación del tipo de mensaje al evento está controlada mediante la consola de administración Event Manager.

EventBroker-02 Invalid TXT payload type Indica que el contenido de even:payload está vacío o es una cadena de longitud cero.

EventBroker-03 Invalid XML payload type Indica que el contenido de even:payload no es un XML válido.

EventBroker-04 Unsupported subscriptor type detected

El tipo de subscriptor no es válido. Este tipo de error es interno de Event Manager y no es común que se reproduzca porque la asociación del tipo al subscriptor está controlada mediante la consola de Event Manager.

EventBroker-05 Security violation detected (any security needed)

Error interno de Event Manager

EventBroker-06 El publicador no está dado de alta para este evento

El publicador del evento indicado en el campo even:source no está autorizado para enviar el tipo de evento indicado en el campo even:id

EventBroker-07 La publicación está suspendida para el publicador/evento

Se ha deshabilitado desde la consola de control de Event Manager el envío de eventos para el publicador indicado en el campo even:source o para el tipo de evento indicado en el campo even:id

EventBroker-08 Fallo en findEventoById con id xxx: Evento no encontrado

No se ha encontrado el tipo de evento correspondiente al código de la etiqueta even:id

EventBroker-09 No hay subscriptores configurados para este evento

No hay subscriptores configurados para el tipo de evento correspondiente al código de la etiqueta even:id

3.6 Publicación de eventos mediante mensajería JMS

3.6.1. Requisitos técnicos Event Manager dispone de un Proxy Service que permite enviar mensajes SOAP sobre JMS. En la siguiente tabla se muestran los requisitos por tecnología:


Plataforma Integración posible

Requisitos técnicos de comunicación

Réquisitos técnicos de alta disponibilidad

Java J2EE Sí Ninguno.Las aplicaciones J2EE se despliegan sobre Oracle WebLogic Server que proporciona todo el subsistema JMS

Ninguno. Las aplicaciones J2EE se despliegan sobre Oracle WebLogic Server que proporciona los agentes SAF para garantizar la alta disponibilidad y entrega ordenada de los mensajes ante cualquier tipo de contingencia.

Java standalone Sí Se requiere el uso de la librería wlfullclient.jar para la comunicación con Oracle WebLogic Server

La aplicación deberá de implementar un sistema que garantice la alta disponibilidad y la entrega ordenada de los eventos ante cualquier tipo de contingencia.

.NET Sí Se requiere el uso de la librería com.bea.weblogic.jms.dotnetclient_1.3.0.0.zip para la comunicación con Oracle WebLogic Server


3.6.2. Requisitos funcionales Es necesario rellenar el formulario de alta de publicador y hacer la solicitud para que se efectúe el alta en Event Manager.

3.7. Publicación de eventos mediante servicio web

3.7.1. Requisitos técnicos Event Manager dispone de un Proxy Service que permite enviar mensajes SOAP sobre HTTP/HTTPS. En la siguiente tabla se muestran los requisitos por tecnología:





Java J2EE Sí Ninguno.Las aplicaciones J2EE se despliegan sobre Oracle WebLogic Server que proporciona las librerías necesrias para la comunicación SOAP sobre HTTP/HTTPS.


Java standalone Sí Se requiere el uso de las librerías necesarias para realizar llamadas SOAP sobre HTTP/HTTPS.


.NET Sí Se requiere el uso de las librerías necesarias para realizar llamadas SOAP sobre HTTP/HTTPS.


En cualquier caso, las aplicaciones deberán de desarrollar un cliente web service que cumpla las especificaciones del WSDL proporcionado por Osakidetza.

3.7.2. Requisitos funcionales Es necesario rellenar el formulario de alta de publicador y hacer la solicitud para que se efectúe el alta en Event Manager.

3.8. Subscripción a eventos mediante servicio web

3.8.1 Requisitos técnicos Event Manager puede enviar eventos a un subscriptor mediante servicio web.




Java J2EE Sí Ninguno.Las aplicaciones J2EE se despliegan sobre Oracle WebLogic Server que proporciona las librerías necesrias para la publicación de servicios web SOAP sobre HTTP/HTTPS.

Ninguno.

Event Manager garantiza la alta disponibilidad y la entrega ordenada de los eventos ante cualquier tipo de contingencia.





Java standalone Sí Se requiere el uso de las librerías y los servicios necasrios para publicar web services SOAP sobre HTTP/HTTPS.

Ninguno. Event Manager garantiza la alta disponibilidad y la entrega ordenada de los eventos ante cualquier tipo de contingencia.

.NET Sí Ninguno. La plataforma .NET ofrece los servicios necesarios para publicar servicios web SOAP sobre HTTP/HTTPS.

Ninguno. Event Manager garantiza la alta disponibilidad y la entrega ordenada de los eventos ante cualquier tipo de contingencia.

El servicio web publicado por el subscriptor debe implementar el WSDL proporcionado por Osakidetza. El servicio web implementa dos operaciones: • reveiceEvent Event Manager llama a este método cuando el subscriptor necesita

recibir únicamente el payload del evento. El payload corresponde únicamente al mensaje HL7.

• receiveFullEvent Event Manager llama a este método cuando el subscriptor se configura para recibir el evento completo, con header y payload. Un ejemplo de evento con header.

3.8.2 Requisitos funcionales Es necesario rellenar el formulario de alta de subscriptor y hacer la solicitud para que se efectúe el alta en Event Manager. Entre otros datos, se debe de indicar la url del web service al que Event Manager enviará los eventos.


4. Anexo Servicio Mantenimiento y/o Evolución Se deberá de incluir este anexo en los contratos a realizar, este servicio debe consistir en incluir los cambios de interoperabilidad que requieren un mantenimiento permanente. Tanto evolución de los servicios web y/o eventos actuales, como de la publicación de nuevos servicios y/o eventos y, en general, todo lo relacionado con la interoperabilidad de los sistemas objetos del contrato. La ejecución de este servicio de mantenimiento se realizara una vez al año, desde la Subdirección de Informática de SSCC se comunicara los cambios abordar en el mes de enero en curso, con un plazo de adaptación de 6 meses desde la notificación de la misma. La no adaptación de los sistemas a los nuevos requisitos implicara la posibilidad de riesgo de que los sistemas integrados queden aislados.


5. Seguridad SOA Ver Anexo IV.


ANEXO IV

SEGURIDAD SOA REQUISITOS PARA APLICACIONES


1. OBJETIVO DEL DOCUMENTO Definir los requisitos que deben cumplir las aplicaciones a la hora de integrarse con otros sistemas mediante SOA, siempre a través del Bus de Servicios de Osakidetza (OSB), en lo referente a los aspectos de seguridad a tener en cuenta en función del rol que desempeñe la aplicación dentro de la integración (proveedora de servicios o cliente) y el ámbito en el que se produzca dicha integración (Intranet / Internet/JASO). Por el momento se definen los requisitos y tareas necesarias relativas a las aplicaciones que consumen servicios, dentro del ámbito de Internet. Este documento detalla únicamente los requisitos de seguridad definidos a nivel de infraestructura SOA. Se ha de tener en cuenta que determinadas aplicaciones proveedoras de servicios pueden establecer consideraciones adicionales, como por ejemplo autenticación en base a usuarios de aplicación.


2. CONSIDERACIONES GENERALES

Independientemente de si la aplicación consumidora de servicios web está ubicada en la Intranet de Osakidetza o en la DMZ, o en Internet, o en jaso, deberá tener en cuenta que es necesario disponer de un certificado de aplicación cliente válido para poder invocar a los servicios web.

• Es necesario obtener un Certificado de Aplicación Cliente. Generalmente este certificado podrá ser generado por Osakidetza, salvo en uno de los siguientes supuestos:

o Aplicaciones que vayan a consumir servicios web publicados en Internet, y que la aplicación proveedora requiera por alguna circunstancia el Certificado de la Aplicación Cliente, no pudiendo utilizarse el del OSB de Osakidetza.

o Aplicaciones externas a Osakidetza que ya dispongan de Certificado de Aplicación Cliente emitido por una entidad certificadora oficial.

o Aplicaciones para las que, dada la naturaleza de su negocio y/o los datos que manejen, Osakidetza considere necesario emplear un Certificado de Aplicación Cliente emitido por una entidad certificadora oficial.

• La solicitud del certificado se realizará mediante la petición correspondiente a través del Equipo de Sop. Implantación / Gestión del Cambio.

• Si el certificado a emplear no ha sido emitido por Osakidetza, o por IZENPE bajo la CA “CA App Vascas(2)”, será necesario indicar la CA correspondiente al equipo de Sop. Web para su inclusión en el OSB de Osakidetza. En cualquier caso se deberá tratar de una CA pública reconocida si no ha sido emitida por Osakidetza.

• Se deberá proporcionar además, al equipo de Sop. Web, la parte pública del certificado que empleará la aplicación cliente ya que se autorizará el acceso a los servicios web requeridos en base a dicho certificado.

• El equipo de desarrollo deberá emplear siempre el certificado de su aplicación cliente en las llamadas a los servicios web requeridos. Se deberá intentar registrar dicho certificado en un almacén externo a la aplicación, normalmente proporcionado por el servidor de aplicaciones y configurado por el equipo de Soporte Web (salvo en el caso de aplicaciones externas a Osakidetza).


• Las llamadas a servicios web, siempre a través del OSB dedicado para el ámbito de Internet / DMZ /JASO, se deberán realizar mediante protocolo seguro (HTTPS) y aplicando las políticas de seguridad WSS correspondientes a la firma y autorización. Estas políticas se han definido en base a las proporcionadas por Oracle WebServices Manager:

o oracle_wss10_x509_token_with_message_sign_service_policy o oracle_wss10_x509_token_with_message_sign_service_policy_net o oracle_wss10_x509_token_with_message_sign_client_policy o oracle_wss10_x509_token_with_message_sign_client_policy_net

A continuación se incluye la guía de desarrollo para la utilización de certificados de seguridad en las llamadas a servicios web. Ver anexo V COE10 – Seguridad.

• Para poder realizar las llamadas mediante protocolo seguro HTTPS, la aplicación cliente deberá registrar la CA “CA App Vascas(2)”.


3. AMBITO DE INTERNET

Las aplicaciones que consuman servicios publicados desde el ámbito de Internet / DMZ, o que estando ubicadas en este ámbito consuman servicios de la intranet de Osakidetza, deberán tener en cuenta las consideraciones descritas a continuación con el objetivo de satisfacer los requisitos de seguridad definidos para las integraciones SOA de estas características.

3.1 [INET01] Osakidetza -> OSB -> DMZ

Entrarán dentro del caso [INET01] aquellas aplicaciones desplegadas en la Intranet de Osakidetza y que consuman Servicios web publicados por aplicaciones en la DMZ de Osakidetza.

3.1.1 WSS

La resolución de las políticas de seguridad WSS, correspondientes a Firma y Autorización, se realizará en dos tramos, siendo el segundo transparente para la aplicación consumidora de servicios web:

o Cliente -> OSB

La aplicación empleará su Certificado de Aplicación Cliente para resolver las políticas de WSS en sus llamadas al OSB de Internet/DMZ.

El OSB verificará la firma en la llamada y firmará la respuesta con su propio certificado.

En el OSB se autorizará el acceso a los servicios web requeridos en base al Certificado de Aplicación Cliente empleado en las llamadas.

o OSB -> Proveedor

El OSB empleará su propio certificado de seguridad para invocar al servicio web de la aplicación proveedora, firmando las peticiones.

La aplicación proveedora verificará la firma en la llamada y firmará la respuesta al OSB. Además deberá cumplir la política de autorización aceptando peticiones que incluyan el certificado del OSB.

3.1.2 HTTPS

Como se indicaba en el apartado de consideraciones generales, la aplicación cliente deberá efectuar las llamadas a los servicios publicados en el OSB mediante protocolo seguro HTTPS.

3.2 [INET02] Osakidetza -> OSB -> Internet

En el caso [INET02] se englobarán aplicaciones desplegadas en la Intranet de Osakidetza y que consuman Servicios web publicados por aplicaciones en Internet.

3.2.1 Compatibilidad de Políticas

Se deberá proporcionar al equipo de Sop. Web información sobre las políticas de seguridad definidas por el servicio web al que se va a invocar, a fin de estudiar su


inclusión en el OSB empleando las políticas equivalentes de entre las que proporciona Oracle WebServices Manager (OWSM).

La resolución de estas políticas se realizará entre el OSB y el proveedor del servicio web, siendo transparente para la aplicación cliente.

3.2.2 WSS

Al igual que en el caso [INET01], la resolución de las políticas de seguridad WSS, correspondientes a Firma y Autorización, se realizará en dos tramos, siendo el segundo transparente para la aplicación consumidora de servicios web:

o Cliente -> OSB




o OSB -> Proveedor

El OSB empleará su propio certificado de seguridad para resolver las políticas específicas que requiera el servicio web publicado en Internet.

3.2.3 HTTPS


3.3 [INET03] DMZ -> OSB ->Osakidetza

Corresponderán al caso [INET03] todas aquellas aplicaciones que, estando desplegadas en la DMZ de Osakidetza, consuman servicios web publicados por aplicaciones ubicadas dentro de la Intranet.

3.3.1 WSS

La resolución de las políticas de seguridad WSS, correspondientes a Firma y Autorización, se negociará exclusivamente entre la aplicación consumidora de los servicios web y el OSB, siendo transparente para la aplicación que proporciona los servicios.

o Cliente -> OSB




o OSB -> Proveedor


La comunicación entre el OSB y la aplicación proveedora del servicio se realizará mediante protocolo HTTP no securizado y sin requerir políticas de seguridad WSS.

3.4 [INET04] Internet -> WAF -> OSB ->Osakidetza

Entrarán dentro del caso [INET04] aquellas aplicaciones desplegadas en Internet que consuman Servicios web publicados por aplicaciones en la Intranet de Osakidetza.

3.4.1 WEB APPLICATION FIREWALL (WAF)

El acceso a la infraestructura de Osakidetza desde Internet se realizará a través del WAF corporativo. Para posibilitar dicho acceso será necesario realizar una petición al equipo de Internet y Seguridad, proporcionando la siguiente información:

o URL del servicio publicado en el OSB de Osakidetza para el ámbito de Internet / DMZ.

o Descriptor WSDL correspondiente al servicio al que se quiere acceder.

o Lista de métodos del servicio que se van a consumir. Si se requiere acceso a todos los métodos del servicio web indicarlo así en lugar de proporcionar una lista.

o Indicar en cada caso si se debe permitir el envío y/o recepción de archivos adjuntos.

o Si el acceso se va a realizar desde un número determinado de orígenes, relación de las IPs desde las que se realizarán las peticiones.

o Certificado de la aplicación cliente para configurar la autorización de acceso en el WAF.

3.4.2 WSS

Al igual que en el caso [INET03], la resolución de las políticas de seguridad WSS, correspondientes a Firma y Autorización, se negociará exclusivamente entre la aplicación consumidora de los servicios web y el OSB, siendo transparente para la aplicación que proporciona los servicios.

o Cliente -> OSB




o OSB -> Proveedor



3.4.3 HTTPS



4. AMBITO DE JASO

Las aplicaciones que consuman servicios publicados desde el ámbito de JASO, o que estando ubicadas en este ámbito consuman servicios de la intranet de Osakidetza, deberán tener en cuenta las consideraciones descritas a continuación con el objetivo de satisfacer los requisitos de seguridad definidos para las integraciones SOA de estas características.

4.1 [INET05] -> JASO -> OSB ->Osakidetza

Entrarán dentro del caso [INET05] aquellas aplicaciones desplegadas en jaso que consuman Servicios web publicados por aplicaciones en la Intranet de Osakidetza.

4.1.1 WSS

La resolución de las políticas de seguridad WSS, correspondientes a Firma y Autorización, se negociará exclusivamente entre la aplicación consumidora de los servicios web y el OSB, siendo transparente para la aplicación que proporciona los servicios.

o Cliente -> OSB

La aplicación empleará su Certificado de Aplicación Cliente para resolver las políticas de WSS en sus llamadas al OSB.



o OSB -> Proveedor


4.1.2 HTTPS



5. RESUMEN DE REQUISITOS

A continuación se resumen los requisitos necesarios, tanto a nivel general como para cada caso.

GENERAL

� Obtener Certificado de Aplicación Cliente (Osakidetza / Izenpe u otra entidad certificadora reconocida por Osakidetza).

� Emplear el certificado en las llamadas a los WS, embebido en la aplicación cliente o preferiblemente utilizando un almacén de certificados proporcionado por el servidor de aplicaciones.

� Las llamadas, siempre al OSB de Internet/DMZ, se realizarán mediante HTTPS y aplicando WSS (Firma + Autorización).

� Proporcionar a Sop. Web:

• Si el certificado no es de Osakidetza o de la CA "CA App Vascas(2)" de Izenpe, la CA del certificado.

• La parte pública del certificado.

� Registrar en la aplicación cliente la CA "CA App Vascas(2)"para establecer llamadas HTTPS.

[INET01] OSAKIDETZA -> OSB -> DMZ

� No se ha de tener en cuenta más consideraciones que las generales.

[INET02] OSAKIDETZA -> OSB -> INTERNET

� Proporcionar a Sop. Web:

• Información sobre políticas específicas del proveedor.

• Parte pública del certificado de la aplicación proveedora del servicio.

[INET03] DMZ -> OSB ->OSAKIDETZA

� No se ha de tener en cuenta más consideraciones que las generales.

[INET04] INTERNET -> WAF -> OSB ->OSAKIDETZA

� Solicitar al equipo de Internet y Seguridad acceso vía WAF, proporcionando la siguiente información:

� URL del servicio publicado en el OSB

� Descriptor WSDL

� Lista de métodos del servicio que se van a consumir

� Indicar en cada caso si se debe permitir el envío y/o recepción de archivos adjuntos

� Si el acceso se va a realizar desde un número determinado de orígenes, relación de las IPs desde las que se realizarán las peticiones


� Registrar en la aplicación proveedora la CA "CA App Vascas(2)"para establecer llamadas HTTPS.

[INET05] JASO -> OSB ->OSAKIDETZA

� Registrar en la aplicación proveedora la CA "CA App Vascas(2)"para establecer llamadas HTTPS.


ANEXO V

COE10 - SEGURIDAD


COE10 – SEGURIDAD

Guía de implementación

Autor: Centro de Excelencia SOA Osakidetza Fecha Creación: 08/08/2012 Última Modificación: 13/08/2012 Referencia Documento: Seguridad Versión: 0.2


Control del documento

Registro de cambios

Revisores

Distribución

Fecha Autor Versión Cambio

08Ago12 Adolfo Ranea 0.1 Creación 13Ago12 Adolfo Ranea 0.2 Cliente .NET

Nombre Empresa Cargo Aritza Iratzagorria Osakidetza Responsable sistemas centralizados Nicolás González Osakidetza Responsable funcional


Contenidos

Control del documento ............................………….…………………………………………………………………2

Registro de cambios …………………………………………………………………………………………... 2

Revisores………………………………………………………………………………………………………..2

Distribución……………………………………………………………………………………………………..2

Introducción…………………………………………………………………………………………………………...4

Propósito………………………………………………………………………………………………………...4

Descripción de las políticas de seguridad …………………………………………………………………………….5

Política de autenticación y protección de mensaje en internet………………………………………………......5

Guía de implementación………………………………………………………………………………………………..7

Desarrollo del cliente OSB en las aplicaciones Java de Internet………………………………………………...7

Desarrollo del cliente OSB en las aplicaciones .NET de Internet ………………………………………………8

Referencias……………………………… …………………………………………………………………………11


Introducción

Propósito El objetivo de este documento es documentar la implementación de las políticas de seguridad en Osakidetza. Este documento pretende ser una guía para el desarrollo de clientes y servicios que cumplan las políticas de seguridad definidas por Osakidetza para la arquitectura SOA.


Descripción de las políticas de seguridad

Política de autenticación y protección de mensaje en internet Osakidetza usa Oracle Web Service Manager (OWSM) para gestionar y aplicar políticas a los servicios corporativos 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

En la siguiente figurase muestra el uso de las políticas de OWSM en la arquitectura general.

Arquitectura seguridad internet e intranet Implementación de políticas con OWSM


• Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a través del 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 sevicios a los que pueden acceder las aplicaciones de internet.

• El OSB de internet audita todas las llamadas a los web services 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.


Guía de implementación

Desarrollo del cliente OSB en las aplicaciones Java de Internet

Escenario

Una aplicación de internet implementa una llamada a un servicio publicado en el OSB de internet. El servicio web publicado en el OSB está protegido mediante la política:

oracle/oracle_wss10_x509_token_with_message_sign_service_policy

Requisitos

Antes de realizar el desarrollo se deben de cumplir los siguientes requisitos:

1. La aplicación de internet debe de contar con un certificado x509 válido.

2. El nombre que figura en el certificado de la aplicación se debe de dar de alta en el realm de WebLogic de OSB para que se realice correctamente la autenticación.

3. Se debe de conocer la URL del servicio publicado en OSB así como la ruta a su WSDL. Desarrollo

Para generar las clases del cliente del servicio web se usa una tarea ANT. Se muestra un ejemplo:

1. <project name="OSBClient" basedir ="." default ="build_client" > 2. <target name="build_client" > 3. <taskdef name="clientgen" classname ="weblogic.wsee.tools.anttasks.ClientGenTask" > 4. <classpath > 5. <fileset dir ="WL_HOME/server/lib" > a. <include name="**/*.jar" /> 6. </ fileset > 7. </ classpath > 8. </ taskdef > 9. <clientgen 10. failonerror ="true" 11. type ="JAXWS" 12. wsdl ="http://ip:puerto/ruta_servicio/ProxyServicePS?WSDL " 13. destFile ="${basedir}/WebContent/WEBINF/lib/ServiceWss.jar" 14. serviceName ="ServiceWss" 15. copyWsdl ="false" 16. > 17. </ clientgen > 18. </ target > 19. </ project >


Es necesario adaptar la tarea ANT al entorno:

• Linea 5: WL_HOME es la ruta al directorio de instalación de WebLogic

• Linea 12: wsdl: es la URL al Proxy Service publicado en el OSB

• Linea 14: serviceName: se deberá de indicar el nombre del servicio

• Linea 13: destFile: ruta donde se desea generar el cliente del web service

Cuando la tareaANT se ejecuta con éxito la salida es similar a esto:

Buildfile: WSOSBClient/clientgen_build.xml build_client: [clientgen] Ignoring JAXRPC options building a JAXWS client [clientgen] [clientgen] *********** jaxws clientgen attribute settings *************** [clientgen] [clientgen] wsdlURI: http://host:port/wss/ServiceWssPS?WSDL [clientgen] packageName : null [clientgen] destDir : /tmp/_vhn32z [clientgen] [clientgen] *********** jaxws clientgen attribute settings end *************** [clientgen] Consider using <depends>/<produces> so that wsimport won't do unnecessary compilation [clientgen] parsing WSDL... [clientgen] generating code... [clientgen] compiling code... [null] Compiling 9 source files to /tmp/_vhn32z [null]

Building jar: ../WEBINF/lib/ServiceWss.jar [AntUtil.deleteDir] Deleting directory /tmp/_vhn32z

BUILD SUCCESSFUL

Total time: 7 seconds

Una vez generado el JAR del cliente se puede implementar la llamada al servicio: 1. String keyStoreFileName = "/ruta_al_keystore/client.keystore"; 2. String keyStorePasswd = "password_keystore"; 3. String certAlias = "alias_certificado"; 4. String keyPasswd = "password_certificado"; 5. Service_Service service = new Service_Service(); 6. Service port = service.getServicePort(); 7. // create credential provider and set it to the request context 8. List<CredentialProvider> credProviders = new ArrayList<CredentialProvider>(); 9. CredentialProvider cp = new ClientBSTCredentialProvider(keyStoreFileName, keyStorePasswd, certAlias, keyPasswd, "JKS"); 10. credProviders.add(cp); 11. Map<String, Object> requestContext = ((BindingProvider) port).getRequestContext(); 12. requestContext.put(BindingProvider.ENDPOINT_ADDRESS_PROPERTY, "http://host_osb /wss/ServiceWssPS");


13. requestContext.put(WSSecurityContext.CREDENTIAL_PROVIDER_LIST, credProviders); 14. requestContext.put(WSSecurityContext.TRUST_MANAGER, new TrustManager() { 15. public boolean certificateCallback(X509Certificate[] chain, int validateErr) { 16. return true ; 17. } 18. }); 19. Recipe recipe = port.getRecipe("1"); 20. System.out.println("recipe = " + recipe.getDescription());

En el ejemplo se muestra una llamada a un servicio web de prueba: • Linea 1 a la 4: definir la ruta al almacén de certificados, contraseña de almacén, alias del certificado de aplicación y contraseña del certificado privado de aplicación

• Lineas 5 y 6: se obtiene el port del servicio

• Lineas 8, 9 y 10: se crean los proveedores de credenciales. En nuestro caso, la credencial será el certificado público x509.

• Lineas 11 y 12: se establece la URL del servicio. Esto no es estrictamente necesario si en el WSDL ya se está indicando la URL correcta

• Linea 13: se pone el proveedor de credenciales en la llamada

• Lineas 14, 15,16 y 17: se define un gestor de confianza. En este caso se establece que siempre se va a confiar en el certificado del servidor

• Lineas 19 y 20: Se realiza la llamada al servicio y se lista el resultado

Desarrollo del cliente OSB en las aplicaciones .NET de Internet

Escenario

Una aplicación de internet implementa una llamada a un servicio publicado en el OSB de internet. El servicio web publicado en el OSB está protegido mediante la política:

oracle/oracle_wss10_x509_token_with_message_sign_service_policy_net

Requisitos

Antes de realizar el desarrollo se deben de cumplir los siguientes requisitos:

1 La aplicación de internet debe de contar con un certificado x509 válido.

2 El nombre que figura en el certificado de la aplicación se debe de dar de alta en el realm de WebLogic de OSB para que se realice correctamente la autenticación.

3 Se debe de conocer la URL del servicio publicado en OSB así como la ruta a su WSDL.


Desarrollo

El cliente se crea con la herramienta SvcUtil.exe. Se pasa como parámetro la URL del WSDL del servicio.

SvcUtil genera la clase output.cs y el archivo de configuración app.config.

Modificar el archivo app.config para añadir el custom binding son las propiedades que se indican en el siguiente listado:

1. <?xml version="1.0" encoding="utf8"?> 2. <configuration> 3. <system.serviceModel> 4. <behaviors> 5. <endpointBehaviors> 6. <behavior name="secureBehaviour"> 7. <clientCredentials> 8. <clientCertificate findValue="CN=Fito"/> 9. <serviceCertificate> 10. <defaultCertificate findValue="weblogic" 11. storeLocation="CurrentUser" storeName="My" 12. x509FindType="FindBySubjectName"/> 13. </serviceCertificate> 14. </clientCredentials> 15. </behavior> 16. </endpointBehaviors> 17. </behaviors> 18. <bindings> 19. 20. <customBinding> 21. <binding name="RecipesServiceClientBinding"> 22. <security 23. defaultAlgorithmSuite="Basic128" 24. authenticationMode="MutualCertificate" 25. requireDerivedKeys="false" 26. includeTimestamp="true" 27. keyEntropyMode="CombinedEntropy" 28. messageProtectionOrder="SignBeforeEncrypt" 29.

messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurit yPolicy11BasicSecurityProfile10"

30. requireSecurityContextCancellation="false" 31. allowSerializedSigningTokenOnReply="true" 32. enableUnsecuredResponse="true"> 33. <localClientSettings cacheCookies="true" 34. detectReplays="false" replayCacheSize="900000" maxClockSkew="00:05:00"


35. maxCookieCachingTime="Infinite" replayWindow="00:05:00" 36. sessionKeyRenewalInterval="10:00:00" sessionKeyRolloverInterval="00:05:00" 37. reconnectTransportOnFailure="true" timestampValidityDuration="00:05:00" 38. cookieRenewalThresholdPercentage="60" /> 39. <localServiceSettings detectReplays="true" 40. issuedCookieLifetime="10:00:00" maxStatefulNegotiations="128" 41. replayCacheSize="900000" maxClockSkew="00:05:00" 42. negotiationTimeout="00:01:00" replayWindow="00:05:00" 43. inactivityTimeout="00:02:00" sessionKeyRenewalInterval="15:00:00" 44. sessionKeyRolloverInterval="00:05:00" 45. reconnectTransportOnFailure="true" maxPendingSessions="128" 46. maxCachedCookies="1000" timestampValidityDuration="00:05:00" /> 47. <secureConversationBootstrap /> 48. </security> 49. <textMessageEncoding maxReadPoolSize="64" 50. maxWritePoolSize="16" messageVersion="Soap11" writeEncoding="utf8"> 51. <readerQuotas maxDepth="32" maxStringContentLength="8192" 52. maxArrayLength="16384" maxBytesPerRead="4096" 53. maxNameTableCharCount="16384" /> 54. </textMessageEncoding> 55. <httpTransport manualAddressing="false" 56. maxBufferPoolSize="524288" maxReceivedMessageSize="65536" 57. allowCookies="false" authenticationScheme="Anonymous" 58. bypassProxyOnLocal="false" hostNameComparisonMode="StrongWildcard" 59. keepAliveEnabled="true" maxBufferSize="65536" 60. proxyAuthenticationScheme="Anonymous" realm="" transferMode="Buffered" 61. unsafeConnectionNtlmAuthentication="false" useDefaultWebProxy="true" /> 62. </binding> 63. </customBinding> 64. </bindings> 65. <client> 66. <endpoint address="http://192.168.56.1:8585/wss2/RecipeServic eWssPS" 67. binding="customBinding" bindingConfiguration="RecipesServiceClientBinding" 68. contract="RecipesService" name="RecipesService" behaviorConfiguration="secureBehaviour" > 69. <identity> 70. <dns value="weblogic"/> 71. </identity>


72. </endpoint> 73. 74. </client> 75. </system.serviceModel> 76. </configuration> • De la línea 20 a63 se define el customBinding. Este bindig tiene las propiedades para que el cliente sea interoperable con la política de OWSM.

• En la línea 8 se indica el nombre del certificado cliente que se usará para firmar el mensaje. Este certificado se debe de encontrar en el perfil del usuario.

• Aunque el mensaje no se firma, WCF exige que se haga referencia al certificado público del servidor. Esta referencia se hace en las líneas 9 a 14.

• El certificado del servidor se debe de añadir en los certificados de confianza dentro del almacén del usuario actual. La política custom de Osakidetza no incluye firma, por lo tanto, es necesario cambiar el ProtectionLevel en el interfaz del cliente. Acontinuación se muestra un ejemplo: 1 public interface RecipesService { 2 3 // CODEGEN: Parameter 'return' requires additional schema information that cannot be captured using the param eter mode. The specific attribute is 'System.Xml.Serialization.XmlElementAttribute'. 4 [System.ServiceModel.OperationContractAttribute(Act ion="http://com.oracle.lab.owsm/RecipesServic e/getRecipeRe quest", ReplyAction="http://com.oracle.lab.owsm/RecipesServ ice/getRecipeResponse", ProtectionLevel = System.Net.Security.ProtectionLevel.Sign)] 5 [System.ServiceModel.XmlSerializerFormatAttribute() ] 6 [return: System.ServiceModel.MessageParameterAttribute(Name= "return")] 7 getRecipeResponse getRecipe(getRecipeRequest reques t); 8 } En la línea 4 se indica la propiedad:

ProtectionLevel = System.Net.Security.ProtectionLevel.Sign

Que indica que el mensaje sólo se firma, no se encripta.

Para completar el ejemplo se muestra un ejemplo de uso del cliente:

1. using System; 2. using System.ServiceModel; 3. using System.ServiceModel.Description; 4. using System.Net.Security; 5. 6.


7. namespace ClienteWS 8. { 9. class MainClass 10. { 11. public static void Main (string[] args) 12. { 13. Console.WriteLine ("Llamando al servicio de tes t…"); 14. 15. RecipesServiceClient servicio = new RecipesServ iceClient(); 16. 17. getRecipeRequest peticion = new getRecipeReques t(); 18. peticion.arg0 = "1"; 19. recipe receta = servicio.getRecipe("1"); 20. 21. Console.WriteLine ("Receta: "+receta.descriptio n); 22. Console.WriteLine ("Receta: "+receta.id); 23. Console.WriteLine ("Receta: "+receta.ingredient s[0].name); 24. Console.WriteLine ("Receta: "+receta.ingredient s[1].name); 25. Console.ReadLine(); 26. } 27. } 28. }


Referencias

Oracle® Fusion Middleware Interoperability Guide for Oracle Web Services Manager:

http://docs.oracle.com/cd/E15523_01/web.1111/e16098/toc.htm

How To: Call a Java EE Web Service from a .Net Client:

http://blogs.msdn.com/b/bursteg/archive/2008/07/19/howtocallajavaeeweb-servicefromanetclient.aspx

How to: Use Certificate Authentication and Message Security in WCF Calling from Windows Forms:

http://msdn.microsoft.com/enus/library/ff648360.aspx

contrato de suministro procedimiento abierto oferta

Documents