EXPTE. G/110/80/1/0736/O101/0000/042014 SUMINISTRO DE ... · 3.2 Condiciones de licitación ......

PLIEGO DE PRESCRIPCIONES

ACUERDO MARCO

EXPTE. G/110/80/1/0736/O101/0000/042014

SUMINISTRO DE MATERIAL FUNGIBLE PARA

EXPLORACIONES DE URODINAMIA

Y CESIÓN DE EQUIPAMIENTO

HOSPITAL UNIVERSITARIO ARABA

1. OBJETO DEL CONTRATO

Mediante esta contratación se pretende cubrir las necesidades de MATERIAL FUNGIBLE PARA EXPLORACIONES DE URODINAMIA con capacidad para realizar estudios de FLUJOMETRÍA, CISTOMETRÍA, PRESIÓN-FLUJO Y PERFILES URETRALES en el Servicio de Urología del Hospital Universitario Araba (Sedes Santiago y Txagorritxu), para un periodo de 4 años (contrato inicial de dos años, más 2 posibles prórrogas de un año cada una), además de la CESIÓN DE EQUIPAMIENTO necesario para la realización de estas exploraciones y estudios. Los productos objeto de contratación se consideran necesarios para la prestación de asistencia sanitaria en Hospital Universitario Araba. Se trata de un contrato de suministro sujeto a lo dispuesto en el art. 196 y siguientes, en relación al art. 9.3a) del TRLCSP, referido a los Acuerdos marco.

2. RÉGIMEN JURÍDICO DEL CONTRATO

Se trata de un contrato de suministro, de naturaleza administrativa, y se rige por el contenido del presente Pliego, por el Pliego de Cláusulas Administrativas Particulares para los contratos de Suministro y por el RDL 3/2011, así como el resto de la legislación administrativa aplicable. En este Pliego se recogen las especificaciones técnicas y administrativas que regirán la contratación para el suministro de material fungible y cesión de equipamiento que se precisa y tienen carácter contractual para las partes.

I. ESPECIFICACIONES TÉCNICAS

3. ESPECIFICACIONES RELATIVAS A LOS LOTES

3.1 Lotes, precios unitarios y consumo estimado El objeto del contrato se constituye en 1 único lote, con 10 sublotes necesarios, en las cantidades y con los precios unitarios máximos que se reflejan:

El número de unidades previsto es estimativo, por estar subordinado a la actividad del Hospital Universitario Araba, y por tanto no se considera elemento esencial del contrato. Cualquier variación al alza o a 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. 3.2 Condiciones de licitación Obligatoriedad de ir a lote entero: Los licitadores deberán ofertar a totalidad de los sublotes que componen el lote, de acuerdo con lo indicado en este Pliego. Variantes: No.

4. ESPECIFICACIONES TÉCNICAS COMUNES PARA LA LICITACIÓN

• Con el objeto de ofrecer el adecuado nivel de protección tanto a los pacientes como a los profesionales sanitarios y a Osakidetza, se certificará que los productos son seguros y cumplen las prestaciones especificadas por el fabricante, reuniendo los correspondientes requisitos establecidos en la normativa específica que regula este tipo de productos sanitarios según su clasificación legal, con especial remisión a sus disposiciones en lo referente a marcado, autorizaciones y tarjetas de implantación:

A) Productos sanitarios implantables activos (marcapasos, desfibriladores,

estimuladores nerviosos y musculares, electrodos, bombas de infusión implantables, implantes cocleares, etc…), de acuerdo con el RD 1616/09, de 26 de octubre, sobre productos sanitarios implantables activos.

B) Prótesis quirúrgicas fijas: productos sanitarios que precisen de una implantación

interna y fija en el paciente a través de un determinado acto quirúrgico, estando dirigidas a sustituir artificialmente y de forma permanente la falta de un órgano o de parte de él o de su función y que no haya sido englobadas en el apartado A), de acuerdo con el RD 1591/09, de 16 de octubre.

• Las empresas deberán indicar en su oferta la referencia del proveedor de cada artículo ofertado.

4.1 Especificaciones técnicas específicas:

• Catéter cistometría 2 vías + Linea de extensión 8 Fr.

• Set de infusión de llenado

• Cúpula para transductor de presión reutilizable

• Válvula de seguridad. Conexión valvula anti-retorno.

• Linea de perfusión para estudios de perfil uretral

• Catéter rectal con balón libre de látex

• Electrodos de superficie adhesivos

• Catéter cistometría 2 vías y Perfil uretral + Linea de extensión 8 Fr.

• Linea de extensión

• Catéter cistometría 2 vías - 8 Fr. Punta tipo Tieman

ASPECTOS A VALORAR

• Composición

• Versatilidad

• Idoneidad

• Facilidad de manejo y comodidad en la manipulación.

1 EQUIPO DE URODINAMIA

Con capacidad para realizar estudios:

Flujometría, Cistometría, Presión-Flujo, Perfil Uretral estático y dinámico. • Inalámbrico

• Conectividad con el historial informático del HUA

• Bases de datos • ANEXOS I y II de este Pliego

ASPECTOS A VALORAR

• Características del Software

• Sistema de acoplamiento físico

• Manejabilidad

• Perfil uretral estático y dinámico, con retractor del catéter.

• EMG de alta sensibilidad

• Posibilidad de software para rehabilitación del suelo pélvico.

2 FLUJÓMETROS

• Inalámbricos

• Conectividad al ordenador mediante fibra óptica • Bases de datos • ANEXOS I y II de este Pliego

ASPECTOS A VALORAR

• Compatibilidad para análisis pediátricos

• Pantalla táctil

El licitador dentro de su oferta señalará todos los componentes que forman parte del equipamiento que presentan en cesión.

De acuerdo con los avances tecnológicos, el adjudicatario se comprometerá a las actualizaciones de todo el equipamiento en cesión sin coste alguno para la Administración. Asimismo, durante la vigencia del contrato, la entidad adjudicataria se hará cargo del mantenimiento (correctivo y preventivo) de todos los equipos en cesión, sin coste alguno para la Administración. La formación del personal para el manejo los equipos cedidos será por cuenta de la empresa adjudicataria.

El régimen aplicable al equipo que la empresa adjudicataria ha de poner a disposición del HUA para la realización de las exploraciones objeto del contrato, será el que a continuación se detalla:

A. Permanecerá en el HUA durante el período de vigencia del contrato. El mantenimiento

integral del equipamiento correrá por cuenta del adjudicatario, no generándose ningún cargo para el Centro por este Concepto.

B. Las reparaciones tendrán siempre carácter de urgentes, debiendo proceder la empresa

adjudicataria con extrema diligencia en la resolución de todas las incidencias. C. La instalación y ubicación del equipamiento se realizará en el lugar que los responsables del

Centro indiquen, siendo por cuenta de la empresa adjudicataria los gastos que de ello se deriven, inclusive, en su caso, los ocasionados por la conexión en red del equipamiento adjudicado al sistema informático de gestión existente en el Servicio.

D. En el caso de que la reparación del equipamiento no pueda realizarse en el propio Hospital o

suponga la inutilización del mismo, el adjudicatario estará obligado a sustituir el mismo mientras dure la reparación.

E. La empresa adjudicataria estará obligada a formar suficientemente a los usuarios en el

adecuado manejo del equipamiento, aportando manuales de uso, asumiendo los gastos de puesta en marcha del equipo en cesión.

F. Integración de equipamiento con los sistemas informáticos corporativos. En documentos Anexos I y II de este Pliego se recogen la Guía de Integración y los Requisitos Técnicos con las especificaciones de Interoperabilidad, de obligado cumplimiento y sin que ello represente coste alguno para la Administración.

II. ESPECIFICACIONES ADMINISTRATIVAS

5. VALORACIÓN DEL EXPEDIENTE

Importe contrato inicial (2 años) IVA excluido 84.112,00

Valor estimado modificaciones IVA excluido (20%) 16.822,40

Valor estimado prórrogas (2, de un año) IVA excluido 84.112,00

Valor estimado total IVA excluido (contrato inicial + modificaciones + prórrogas)

185.046,40

Número máximo de decimales: Dos.

6. PLAZO DE EJECUCIÓN

2 años El contrato entrará en vigor desde la fecha de su formalización Se contempla la posibilidad de dos prórrogas de un año de duración cada una.

7. PROCEDIMIENTO DE ADJUDICACIÓN

Procedimiento: Abierto Tramitación: Ordinaria Forma: Se atenderá a una pluralidad de criterios de valoración de las ofertas. Número máximo de adjudicatarios por lote: Un adjudicatario.

8. CRITERIOS DE ADJUDICACIÓN

8.1 Criterios basados en Juicios de Valor

VALORACIÓN TÉCNICA: 45 puntos (umbral mínimo: 25 puntos)

La valoración técnica se realizará sobre la documentación técnica correspondiente a los artículos objeto de licitación, de acuerdo con los siguientes criterios y puntuaciones:

CRITERIOS DE VALORACIÓN PUNTUACIÓN

� Equipamiento Hasta 30 puntos

EQUIPO DE URODINAMIA

• Características del Software

• Sistema de acoplamiento físico

• Manejabilidad

• Perfil uretral estático y dinámico, con retractor del catéter.

• EMG de alta sensibilidad

• Posibilidad de software para rehabilitación del suelo pélvico. FLUJÓMETROS

• Compatibilidad para análisis pediátricos

• Pantalla táctil

Excelente: Adecuado: Deficiente:

30 puntos 15 puntos 0 puntos

� Material fungible Hasta 15 puntos

• Composición, versatilidad, idoneidad, etc. • Facilidad de manejo y comodidad en la manipulación.

Excelente: Adecuado: Deficiente:

15 puntos 10 puntos 0 puntos

Las ofertas que no alcancen 25 puntos del valor técnico (45 puntos), quedarán excluidas de la fase Criterios de Valoración por Aplicación de Fórmula.

8.2 Criterios basados en Fórmulas

PRECIO: 55 puntos

La ponderación de este criterio se efectuará según las reglas de la proporcionalidad y, en consecuencia, asignando el máximo de puntos a la oferta más barata y al resto proporcionalmente, con arreglo a la siguiente fórmula:

Puntuación = 55 x (Precio licitación más bajo / Precio de licitación de cada licitador)

Los precios ofertados, en ningún caso, podrán superar los precios unitarios de licitación indicados en el cuadro del punto 3.1. de este Pliego.

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. GARANTÍAS PARA LA FORMALIZACIÓN DEL CONTRATO

Garantía Provisional: No se requiere. Garantía Definitiva: No se requiere.

10. PLAZO DE EJECUCIÓN DEL ACUERDO MARCO

Plazo de ejecución inicial del contrato: Dos años. El contrato entrará en vigor desde la fecha de su formalización. Prórrogas: Sí. Dos prórrogas por un periodo de un año cada una. Plazo total de ejecución (inicial más prórroga, en su caso): Hasta cuatro años.

11. LUGAR Y ENTREGA DEL SUMINISTRO

Las empresas adjudicatarias deberán entregar los bienes objeto del suministro en el lugar que se designe por el Hospital Universitario Araba. La prestación del suministro incluye el transporte de los productos hasta el Centro 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.

12. DOCUMENTACIÓN A INCLUIR EN LOS SOBRES

12.1 En el Sobre C (Criterios basados en Juicios de Valor) Es recomendable que la documentación que se presente esté 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. En la documentación técnica los licitadores incluirán de forma expresa:

� Cumplimiento del Real Decreto 1591/2009, de 16 de octubre, por el que se regulan los productos sanitarios. Además de la documentación administrativa exigida en este Pliego, deberá incluir la declaración CE de Conformidad que le corresponda, de acuerdo a la clase de producto sanitario de que se trate que acredite el cumplimiento de los requisitos esenciales de los productos establecidos en el Real Decreto 1591/2009, de 16 de octubre, por el que se regulan los productos sanitarios, en castellano o traducción jurada emitida por un traductor acreditado. Pueden aportarse copias de estos documentos o bien 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 responsable de la empresa.

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

En el Sobre C, los licitadores incluirán documentación acreditativa de los siguientes extremos:

� Nombre comercial, referencias y presentación de cada uno de los productos objeto de licitación. Para ello deberán cumplimentar el “Cuadro de Ofertas Técnicas.xls”, que podrá descargarse del perfil del contratante junto con el resto de documentación administrativa del expediente. En el caso de que para un mismo lote se oferten varias referencias, éstas se deberán especificar en Anexo separado, y en las casillas correspondientes a Referencia y

Marca/Modelo se deberá rellenar “Varias referencias”, “Ver Anexo”, etc.

Deberá estar firmado por el representante legal de la empresa.

� Ficha descriptiva con indicación de las características técnicas, composición, diseño, estructura y elementos constituyentes de cada uno de los lotes ofertados.

� Catálogos y folletos en cualquiera de los dos idiomas oficiales de la Comunidad

Autónoma, o en su defecto con traducción del contenido.

� Necesidades y condiciones de almacenajes, caducidades, etc.

� Organización y logística puesta por la mercantil a disposición del contrato, lugar y forma de contactar para el aprovisionamiento, frecuenta de las comunicaciones, etc.

� Medios técnicos y 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).

� Información relativa a lo dispuesto en la Ley de Prevención de Riesgos Laborales (Ley 31/1995, de 8 de noviembre):

- Forma correcta de utilización por los usuarios - Medidas adicionales a adoptar. - Riesgos laborales que conlleve su uso normal, así como su manipulación o

empleo inadecuado. - Información sobre el sistema disponible y obligaciones en relación al

etiquetado y envasado del producto (manipulación en condiciones de seguridad).

- Descripción sobre la identificación de su contenido. - Especificaciones sobre los riesgos que su almacenamiento o utilización

comporten para la salud y seguridad del personal sanitario. 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”.

12.2 En el Sobre B (Criterios basados en Fórmulas) CRITERIO PRECIO Se deberán cumplimentar el Anexo VI del Pliego y el Cuadro de Ofertas Económicas que podrán descargarse del perfil del contratante junto con el resto de documentación administrativa del expediente. Deberán estar firmados por el representante legal de la empresa. Para cada referencia ofertada se incluirá el código EAN/GTIN13. Los precios unitarios deberán expresarse con un máximo de 2 decimales. De no ser así, se procederá a su redondeo. Ninguno de los precios unitarios ofertados superará el precio de licitación unitario reflejado en el Anexo IV (Especificaciones relativas al material fungible).

13. RÉGIMEN DE SUSTITUCIÓN DE BIENES OBJETO DE SUMINISTRO

Durante la vigencia del contrato, los adjudicatarios están obligados a proponer sustituciones de los productos o materiales seleccionados, 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 inicialmente adjudicado 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 sea igual o inferior al inicialmente adjudicado 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.

14. 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 procedo 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 determinen el órgano de contratación.

15. RESOLUCIÓN DE CONTRATO

Además de por las causas recogidas en el RDL 3/2011, se podrá instar la resolución del contrato cuando se den dos o más infracciones que signifiquen incumplimientos de gravedad del RD 1591/2009, de 16 de octubre, por el que se regulan los productos sanitarios. En caso de resolución de contrato por esta causa, se ofrecerá la formalización de contrato al siguiente licitador por orden de puntuación, siempre que su producto no sea el mismo que el que suministraba el adjudicatario.

- ANEXO I -

Subdirección de Informática y Sistemas de Información

Desarrollo y Mantenimiento de Aplicaciones

Nombre del documento:

B61 – Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor

Fecha:

29/10/2013

B61- Repositorio de Sistemas externos/Digitalización Guía de integración para el centro y proveedor

Versión: v.2.4

Fecha: 28/03/2014

ÍNDICE

1 Introducción ...................................... ........................................................................ 15

1.1 Definición de Sistema Externo ......................................................................... 15 1.2 Tipos de Sistemas Externos ............................................................................ 15 1.3 Requisitos para los Sistemas Externos ............................................................ 15 1.4 Niveles a los que asociar un informe ............................................................... 16

2 Descripción de la Aplicación Sistemas Externos .... ............................................... 17

2.1 Arquitectura de Desarrollo ............................................................................... 17 2.2 Catálogo de Servicios Web ............................................................................. 1 2.3 Conector SFTP ................................................................................................ 2

3 Proceso ........................................... .......................................................................... 3

3.1 Sistemas Externos con integración total .......................................................... 3 3.2 Sistemas Externos con integración nula .......................................................... 4

4 Documentación a facilitar por Sistema Externo ..... ................................................ 5

Introducción

Definición de Sistema Externo

Un Sistema Externo será denominado a cualquier Sistema bien de telemedicina, bien de digitalización, que sea capaz de generar informes por un mecanismo diferente a las herramientas corporativas de informes o digitalización de Osakidetza.

Tipos de Sistemas Externos

Existirán diferentes tipos de Sistemas Externos y en función de la tipología, el mecanismo de la integración será diferente.

• Integración Total: Sistemas Externos que serán capaces de integrarse con el HIS de Osakidetza (eOsabide) a través de servicios web y hacer uso del conector de grabación (dll desarrollada en .NET).

• Integración Nula: Sistemas Externos que no serán capaces de integrarse con el HIS. Además no serán capaces de integrarse con servicios web y/o con el conector de grabación.

Requisitos para los Sistemas Externos

Requisitos mínimos (obligatorios):

• El Sistema Externo tiene que ser capaz de generar el informe en formato pdf.

• El Sistema Externo tiene que ser capaz de generar el pdf con una nomenclatura concreta. Sólo para los Sistemas Externos con integración nula.

• El Sistema Externo tiene que ser capaz de almacenar el informe en una ruta concreta que le será facilitada. Cada centro que lo necesite, contará con un servidor de ficheros donde se almacenarán temporalmente los informes de aquellos Sistemas Externos con integración nula. Estos informes NO pueden tener la propiedad Read Only activada. Además en este mismo servidor se montará el servicio a la escucha, el cual llevará a cabo la integración para los Sistemas Externos con integración nula. Sólo para los Sistemas Externos con integración nula.

• Los Sistemas Externos con integración total, también deberán guardar temporalmente el informe pdf en alguna ubicación, pero dicha ubicación podrá ser elegida por el proveedor del Sistema Externo y no será impuesta por Osakidetza. Los Sistemas Externos con integración total, deberán conocer la ruta exacta de donde tienen que almacenar el informe en el FTP. Esta ruta la determinará el Web Service de grabación Sólo para los Sistemas Externos con integración total.

• El informe deberá poder ligarse a un paciente bien identificado y/o a un episodio concreto.

• El Sistema Externo dará un nombre único a cada informe.

• Los informes deben ser definitivos, o sea, que no sufrirán variaciones. Podrá existir alguna excepción para algún caso muy particular.

Requisitos deseables (estos requisitos deberán ser obligatorios para aquellos Sistemas Externos que aún no hayan sido contratados):

• El Sistema Externo tendrá integración con el HIS. Los datos identificativos de los pacientes o de los episodios a informar o digitalizar serán obtenidos a través de eOsabide.

• El Sistema Externo se podrá integrar con el Servicio Web de grabación de metadatos.

• El Sistema Externo se podrá integrar con el conector de grabación del informe (dll desarrollada en .NET)

Requisitos y comprobación del funcionamiento en el puesto que se integre con Sistemas Externos:

• El equipo tiene que tener acceso al bus de datos donde están albergados y publicados los web services de Sistemas Externos.

Para probar este acceso, sólo habrá que ver que se obtiene respuesta (mediante un ping) del bus de datos (osb.osasunet), la respuesta debe ser correcta.

Ejemplo prueba:

• Una vez generados los certificados requeridos (publico / privado) tal como se indica

en esta documentación habrá que realizar una prueba pare ver que el puesto accede al servidor SFTP. Para ello, desde la ubicación de los certificados habrá que ejecutar el siguiente comando:

psftp [email protected] –i certificado_privado.ppk Ejemplo prueba en un entorno PREproduccion

• El puesto debe tener instalado el MS Framework .NET 3.5.

Niveles a los que asociar un informe

Actualmente se puede asociar informes a dos niveles diferentes:

• A nivel de paciente: El informe estará asociado a un paciente concreto.

• A nivel de episodio: El informe estará asociado a un episodio concreto. A futuro y si es necesario para algún Sistema Externo, se podrá desarrollar un tercer nivel, en el que los informes o digitalizaciones puedan ser asociadas a una prueba o cita.

Descripción de la Aplicación Sistemas Externos Sistemas Externos tiene como misión recoger los informes generados por los Sistemas de Telemedicina, así como las historias que sean digitalizadas. Se almacenará el metadata asociado al informe en una BBDD centralizada y se guardará el informe en un repositorio de informes centralizado. Por último, se ofrecerá un servicio para la consulta de dichos informes por las aplicaciones que se quieran subscribir a la consulta de los informes de los Sistemas Externos. Para este fin se han desarrollado los siguientes componentes:

- Repositorio del metadata: repositorio físico de datos que contendrá el metadata del informe. Será una base de datos centralizada. Para grabar la información, será necesario hacer uso del WS de grabación contenido dentro del BUS SOA.

- Repositorio del Informe: repositorio físico de ficheros que contendrá los informes generados por los Sistemas Externos (pdfs). Es un servidor de tipo SFTP. Para grabar el informe (archivo con formato pdf), será necesario hacer uso del conector de grabación.

- Plataforma de servicios universales de grabación y consulta: aglutinará todas las funcionalidades necesarias para grabar el metadato de los informes generados por los Sistemas Externos, así como las necesarias para su consulta. Además proporcionarán las rutas únicas donde se alojarán los informes dentro del repositorio de informes.

- Servicio a la escucha: Para aquellos Sistemas Externos con integración nula, existirá un servicio que se encargará de realizar la integración por ellos con el WS de grabación y con el conector de grabación. Para ello será necesario que el Sistema Externo genere los informes en pdf en una ruta concreta y con una nomenclatura concreta.

Arquitectura de Desarrollo

Sistemas Externos presenta la siguiente arquitectura:

• Sistema Externo: Sistema de telemedicina que genera informes o sistema de digitalización que digitaliza informes en papel.

• Servicio a la escucha: Servicio que facilita la labor de grabación de los informes y los metadata asociados al informe para aquellos Sistemas Externos incapaces de integrarse con servicios web y con la plataforma centralizada de almacenamiento de informes.

• Base de Datos: Soportarán los metadata de los informes generados por los Sistemas externos. El servidor será Oracle 11g Release 2.

• Repositorio de informes centralizado: Servidor con protocolo SFTP. Se almacenarán los informes en dicho servidor a través de un protocolo SFTP. Para facilitar la grabación de los informes en el Servidor SFTP, se facilita un conector que hace toda la labor.

• Plataforma Servicios de grabación y consulta: Plataforma que expone una serie de servicios y operaciones para llevar a cabo las operaciones de grabar y consultar. Los servicios web serán alojados en el Service Bus y estarán disponibles tanto para los Sistemas Externos que puedan hacer uso de ellos, como para el servicio a la escucha.

• Aplicaciones de consulta: Las aplicaciones que necesiten consultar los informes generados por los diferentes Sistemas Externos, podrán hacerlo a través del WS de consulta. Actualmente están identificadas Clinic y OsabideGlobal como aplicaciones que consultarán estos informes pudiéndose ampliar el abanico

Para obtener este dibujo en

formato png acceda al siguiente

enlace

Sistemas Externos.png

ARABAKO UNIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO ARABA

Catálogo de Servicios Web

SistExtConsultaWS Consulta de los informes originados por cualquier Sistema

Externo Descripción Parámetros:

XML en formato string representado por un esquema XSD (SistExtConsultaPet)

Métodos: - existeInformePaciente_v2 - getInformesPaciente_v4 - existeInformeEpisodio_v2 - getInformesEpisodio_v4 - getInformePDF

Resultado: XML en formato string representado por un esquema XSD (SistExtConsultaRes)

SistExtRegistroWS Graba el metadata de los informes originados por cualquier

Sistema Externo Descripción Parámetros:

XML en formato string representado por un esquema XSD (SistExtRegistroPet)

Métodos: - RegistroInformePaciente_v2 - RegistroInformeDatosPaciente_v3 - ActualizarInformePaciente - RegistroInformeEpisodio - RegistroInformeDatosEpisodio_v2 - ActualizarInformeEpisodio

Resultado: XML en formato string representado por un esquema XSD (SistExtRegistroRes)


Conector SFTP ConectorFTP Graba el informe facilitado en el destino indicado Descripción Parámetros que se obtienen del fichero de configuración:

- IP del SFTP - Usuario del SFTP - RutaTemporal Sin Procesar, ruta donde se tienen que

ubicar los informes sin procesar. - Indicador de Borrado (Indica si se debe borrar o no el informe de la ruta temporal o ruta origen) - Número de Reintentos. - Organización de Servicios Código de la OS (Organización de Servicios) a la cual pertenece el centro donde se ha generado el informe. - Centro Código de centro donde se ha generado el informe

Parámetros que recibe el conector:

- RutaTemporal donde se ha ubicado el pdf en local. La ruta donde el conector obtendrá el pdf original para subir al servidor. Esta ruta tendrá que determinar el path y el nombre del fichero.

- RutaEnFTP, donde se almacenará el informe. La ruta, con el nombre del fichero incluido donde se almacenará el pdf en el FTP. Esta ruta se obtendrá del web service de registro y contendrá el path y el nombre del fichero. Métodos:

- guardarEnFTP Resultado:

El método devolverá un string con el mensaje correspondiente si ha ido correctamente o si ha ocurrido algún problema.


Proceso A continuación se describe el flujo de trabajo por cada tipo de Sistema Externo

Sistemas Externos con integración total

1. El Sistema Externo dispondrá al usuario final de un aplicativo integrado con el HIS de Osakidetza (eOsabide).

2. El usuario final, será capaz de buscar pacientes o episodios a través de dicho aplicativo.

3. Una vez seleccionado el paciente o episodio, el usuario final podrá realizar informes asociados o digitalizar información asociada al elemento buscado y seleccionado.

4. El Sistema Externo, generará un informe definitivo (A excepción del algún caso muy particular).

5. El Sistema Externo invocará el WS de grabación, llamando a uno de los siguientes métodos en función de la situación que se esté dando (insertar o actualizar el informe que está ligado a nivel de paciente o de episodio):

a. RegistroInformeDatosPaciente: Este método registra los metadatos de un informe en la BBDD de los SSEE a nivel de paciente, los datos del paciente son facilitados por el Origen (Sistema Externo integrado con eOsabide y/o el catalogo corporativo pacientes).

b. ActualizarInformePaciente: Este método devuelve la ruta donde actualizar un informe que en la BBDD está como no definitivo y que está a nivel de paciente. No actualiza ningún campo exceptuando el estado pudiendo ser definitivo o no definitivo. No se podrán actualizar informes que estén marcados en BBDD como definitivos. Sólo podrán hacer uso de este método aquellos Sistemas Externos, previo validación, puedan generar y almacenar informes no definitivos.

c. RegistroInformeDatosEpisodio: Este método registra un informe en la BBDD de los SSEE a nivel de episodio, los datos del paciente y del episodio son facilitados por el Origen (Sistema Externo integrado con eOsabide y/o el catalogo corporativo pacientes).

d. ActualizarInformeEpisodio : Este método devuelve la ruta donde actualizar un informe que en la BBDD está como no definitivo y que está a nivel de episodio. No actualiza ningún campo exceptuando el estado pudiendo ser definitivo o no definitivo. No se podrán actualizar informes que estén marcados en BBDD como definitivos. Sólo podrán hacer uso de este método aquellos Sistemas Externos, previo validación, puedan generar y almacenar informes no definitivos.


6. Cualquiera de los anteriores métodos devolverá una ruta donde almacenar el informe físico. El Sistema Externo deberá hacer uso del conector de grabación para almacenar el informe en un servidor de tipo SFTP facilitando al conector varios parámetros, entre ellos, la ruta temporal con el fichero pdf.

Sistemas Externos con integración nula

1. El Sistema Externo, generará un informe definitivo (a excepción del algún caso muy particular) desde su aplicativo, el cual, no estará integrado con eOsabide.

2. El Sistema Externo almacenará dicho informe en un servidor de ficheros del centro con formato pdf.

3. El Sistema Externo deberá generar el pdf con una nomenclatura concreta, siguiendo los pasos indicados por la Organización Central.

4. En el servidor de ficheros se deberá configurar el servicio a la escucha. Esta labor la realizará el departamento de informática con ayuda de los técnicos de la UTE

5. En el servidor de ficheros se deberá programar el servicio a la escucha. Esta labor la realizará el departamento de informática con ayuda de los técnicos de la UTE.

6. Una vez que el servicio a la escucha está configurado y programado, los informes generados y almacenados por el Sistema Externo en el servidor de ficheros del centro, serán procesados por este servicio. Este servicio se integrará con el WS de grabación y posteriormente con el conector de grabación. Además eliminará del servidor de ficheros aquellos informes que hayan sido correctamente procesados (dependiendo del parámetro del fichero de configuración). Comentar que el servicio a la escucha, elabora un log cada vez que es disparado, en el que relata que informes han sido subidos a la BBDD y al repositorio de informes y cuales permanecen en el servidor de ficheros porque ha sucedido algún error. Estos log deben ser revisados, por si hubiera incidencias, por el responsable de la aplicación en el centro / informático del centro, así mismo deberá dar solución a las mismas revisando a su vez la carpeta de informes no procesados.


Documentación a facilitar por Sistema Externo Todo Sistema Externo debe estar perfectamente documentado. Para ello se ha elaborado una ficha que deberá ser rellenada por el departamento de informática del centro de donde se ubique el Sistema Externo con ayuda del proveedor del Sistema Externo. Entre la documentación se deberán recoger los siguientes datos:

• Centro

• Sistema Externo

• Proveedor

• Descripción / funcionalidad

• Tipología de informes

• Responsables

• Comunicaciones

• Recursos Hardware

• Recursos Software

• Integración con el HIS

• Volumetría

• Observaciones Para facilitar la labor de recogida de información, se puede solicitar (informatica del centro) algunas de las fichas de los sistemas externos arrancados actualmente


- ANEXO II -

Subdirección de Informática y Sistemas de Información

Desarrollo y Mantenimiento de Aplicaciones

Nombre del documento:

Especificaciones de Interoperabilidad. Requisitos Técnicos Fecha:

10/3/2014

Especificaciones de Interoperabilidad Requisitos Técnicos

Proyecto: Especificaciones de Interoperabilidad

Fecha : 10/3/2014

Asunto: Requisitos Técnicos

Versión: <v02r00> Fecha: 10/3/2014


ÍNDICE

1 Introducción ...................................... ....................................................................... 9

2 Arquitectura orientada a servicios ................ .......................................................... 10

2.1 Resumen de los estándares soportados ......................................................... 10 2.2 Requisitos funcionales .................................................................................... 13

3 Arquitectura orientada a Eventos .................. ......................................................... 14

3.1 Propósito ........................................................................................................ 14 3.2 Estándares de Comunicación ......................................................................... 14 3.3 Alcance ........................................................................................................... 14 3.4 Arquitectura de Event Manager ....................................................................... 14 3.5 Mensajería. Definición de un evento ............................................................... 16 3.6 Publicación de eventos mediante mensajería JMS ......................................... 17 3.7 Publicación de eventos mediante servicio web ............................................... 18 3.8 Subscripción a eventos mediante servicio web ............................................... 19

4 Anexo Servicio Mantenimiento y/o Evolución ........ ............................................... 21


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


Arquitectura orientada a servicios

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.

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.

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.

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 figura se muestra el uso de las políticas de OWSM en la arquitectura general.

WAF

OSB Intranet

Base de Datos de Auditoría

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

Zzz

Cola JMS de AuditoríaOSB Internet

Xxx YyyAplicaciones Internet

DMZ

Intranet

HTTP

Servios Web Internet HIS

Base de Datos HIS

HIS Osabide Global

Aplicaciones Intranet

Xxx

Login de apliación : Usuario /Pass o Certificado

Certificado de aplicación



Clientes Internet

HTTPS

Proxy ServicesPOLITICAS OWSM :oracle /wss10_x509_token_with_message _sign_service _p olicyoracle /auditoria

Business Services

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

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.


Arquitectura orientada a Eventos

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

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.

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.

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


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

Publicación de eventos mediante mensajería JMS

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


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.

Publicación de eventos mediante servicio web


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:


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


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

Subscripción a eventos mediante servicio web


Event Manager puede enviar eventos a un subscriptor mediante servicio web.


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


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.


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.

EXPTE. G/110/80/1/0736/O101/0000/042014 SUMINISTRO DE ... · 3.2 Condiciones de licitación ......

Documents

Transcript of EXPTE. G/110/80/1/0736/O101/0000/042014 SUMINISTRO DE ... · 3.2 Condiciones de licitación ......