SERVICIO DE DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS ... · DE HISTORIAS CLINICAS PARA EL...

DONOSTIA UIBERTSITATE OSPITALEA

HOSPITAL UNIVERSITARIO DONOSTIA

Página 1 de 13

PLIEGO DE BASES TÉCNICAS

Nº EXPTE:

G/205/20/1/0655/O301/0000/032014

SERVICIO DE

DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS CLINICAS PARA EL




Página 2 de 13

1.- OBJETO DEL SERVICIO El objeto del presente servicio es la informatización/digitalización de la documentación clínica utilizada en el Hospital Universitario Donostia, en adelante HUD, ya sea la existente en formato papel, la generada por los diferentes aparatos (electrocardiógrafos, espirómetros, etc.) y la aportada por los pacientes. El proyecto contará para su ejecución con los recursos humanos que el HUD dispone en el archivo, además este personal deberá de continuar con la gestión diaria física de las historias del hospital (hospitalización, consultas externas, estudios, hospital de día, etc.), teniendo en cuenta que los trabajos de digitalización y la gestión física de las historias deberán convivir mientras sea necesario. Por lo tanto, para la realización de este servicio la empresa adjudicataria deberá formar a los profesionales del archivo del HUD, así como aportar todas las herramientas hardware y software necesarias para que la información de los documentos que configuran la historia clínica quede recogida digitalmente. En un principio, y hasta que las cargas de trabajo del personal del archivo del hospital no se reduzcan, la digitalización será asumida enteramente por la empresa licitadora. Según vaya incrementándose el nivel de la informatización/digitalización de las historias clínicas y por lo tanto no deban entregarse en formato papel, la digitalización será asumida por el personal del hospital adscrito al archivo. El objetivo, a la finalización del contrato, es conseguir un archivo propio de historias clínicas del HUD completamente informatizado/digitalizado y gestionado, en exclusiva, por personal dependiente del HUD.

2.- ALCANCE DEL PROYECTO El objetivo final de este proyecto es:

• Disponer de toda la información en papel de las hhcc actuales en formato digital, accesible desde Osabide Global y Clinic.

• No generar papel.

• Disponer al final del proyecto de un circuito completo que permita digitalizar el papel generado en el Hospital y hacerlo accesible desde Osabide Global y Clinic.

• Facilitar el acceso inmediato a la historia del paciente en cualquier circunstancia que motive su presencia en el Hospital.

• Utilizar documentación sólo en soporte digital. Así, a medida que vaya consolidándose la digitalización, disminuirá paulatinamente la gestión de las historias en formato papel.



Página 3 de 13

Teniendo en cuenta que la fecha estimada para la formalización e inicio de prestación de servicios y ejecución del contrato se prevé en el último cuatrimestre del presente año, la empresa adjudicataria deberá presentar un plan detallado (incluyendo una estrategia de digitalización) y medios materiales al HUD para que:

- El día 2 de enero de 2015 se disponga de las historias necesarias en formato digital para el normal funcionamiento del HUD de ese día y los sucesivos.

- A partir del día 2 de enero de 2015 el personal de archivo del HUD esté formado y disponga de los medios necesarios para integrarse en el proyecto.

- Plan de proyecto hasta la total digitalización del Archivo actual con los medios propios . A partir de esa fecha la empresa, además, deberá prestar soporte técnico presencial durante toda la vigencia del contrato. La información digitalizada estará accesible desde Osabide. Global y Clinic

3.- CONTENIDO DEL SERVICIO La prestación de los servicios de tratamiento documental deberá incluir por parte del adjudicatario:

� Plan de gestión de la documentación y digitalización de la misma*. � Trazabilidad de la documentación. � Manipulación y eliminación de la documentación no necesaria. � Digitalización e indexación de la documentación. � Integración de la documentación para que pueda ser visualizada desde las aplicaciones.

Osabide Global y Clinic. � Establecimiento de un circuito de continuidad.

*Además, la empresa deberá aportar plan de digitalización de las historias de pacientes no programados y que se presenten a consultas para visita urgente o espontánea. 3.1. SITUACIÓN ACTUAL

3.1.1.- Historias físicas activas actuales HUD: 270.000 aproximadamente. Se digitalizarían las HHCC que tengan o vayan a tener movimiento en el año 2015, correspondientes a citas programadas, ingresos y pruebas complementarias, aproximadamente unas 125.000 Historias, como media se calcula que cada Historia contiene 2,34 episodios y cada episodio 22,72 documentos.



Página 4 de 13

A modo aclaratorio, a continuación se expone un cuadro en el que mes a mes figuran las historias solicitadas durante el año 2013 para cubrir las necesidades del HUD. HHC pedidas en el mes de enero de 2013. A partir de febrero y en los meses sucesivos son aquellas HHCC

diferentes que no se han servido en meses anteriores

3.1.2..-Recursos humanos actuales en el Archivo del HUD

Personal del HUD: 22 personas dedicadas a las tareas de archivo. 3.1.3.- Recursos materiales en el Archivo del HUD 1 Scanner 1 puesto de indexador

3.2. CARACTERÍSTICAS DEL PROCESO DE DIGITALIZACIÓN El proyecto únicamente incluye las historias clínicas en formato papel (incluye el papel generado por los diferentes aparatos de electromedicina que existan en las HHCC), quedando fuera del mismo las placas radiológicas.

3.2.1. Procesos a seguir:

� Extracción de las historias: Extracción selectiva de las historias a digitalizar. � Preparación de la documentación: Extraer grapas, alisar los documentos, etc. � Selección de la documentación a digitalizar: La documentación a no digitalizar de cada

una de las historias clínicas será la siguiente: - Toda la documentación del propio centro o de centros Osakidetza ya informatizada.

- Duplicidades



Página 5 de 13

- Etiquetas. - Páginas en blanco.

- Copias

� Digitalización: La empresa adjudicataria dimensionará y pondrá a disposición del HUD los recursos necesarios para la correcta ejecución de los procesos de digitalización de las historias. La empresa deberá aportar los escáneres necesarios para la digitalización de la documentación, los cuales deberán garantizar la mejor calidad en las imágenes, con posibilidad de digitalizar en color, en escala de grises, mediante tecnología de optimización de imágenes y teniendo en cuenta que los documentos son heterogéneos y pueden contar con papel de distinto tamaño y gramaje y color. La resolución mínima requerida de escaneo será de 200 (puntos por pulgada) ppp. La empresa adjudicataria deberá ampliar los equipos de almacenamientos de Información no estructurada corporativos HDS HNAS 3090 presentes en el CPD del Hospital de Donostia con 16 discos SAS de 900 GB a 10K rpm para formar 4 PG RAID1 (2D + 2P). En la compra, se seguirán siempre las recomendaciones del fabricante para la configuración desplegada en Osakidetza. Tanto el equipamiento como la ampliación de equipos de almacenamiento pasarán a ser propiedad del HUD. La digitalización de la documentación deberá ser segura, garantizando su no alteración desde el momento de su captura.

� Indexación: La indexación se podrá realizar a nivel historia clínica, episodio y de tipo de

documento.

� Destrucción de las Historias Clínicas en formato papel una vez digitalizadas

4.- REQUISITOS TÉCNICOS La empresa licitadora asumirá la integración de sistemas necesarios para que la información digitalizada se visualice en el sistema Osabide Global y Clinic. Para ello se seguirán las especificaciones técnicas definidas por Osakidetza para servicios externos (ANEXO I). Serán a cargo de la empresa adjudicataria todas las herramientas necesarias para el proceso, tanto hardware como software incluyendo el programa de captura de imágenes/digitalización e indexación. El adjudicatario será el único responsable del buen funcionamiento del proceso de digitalización en su globalidad.



Página 6 de 13

PROCEDIMIENTOS DE CONTROL SOBRE LA GRABACIÓN Y DIGITALIZACIÓN

El adjudicatario deberá describir los controles de calidad que realizará sobre los procesos de digitalización e indexación con el fin de detectar posibles errores y poder proceder a su corrección a la mayor brevedad. Además de los controles de calidad previstos por la propia empresa, el HUD se reserva el derecho a realizar las comprobaciones que considere oportunas para la correcta supervisión de los trabajos ejecutados por la empresa adjudicataria.

5.- RECURSOS 5.1 RECURSOS MATERIALES La empresa deberá aportar, detalle del espacio físico propio y del necesario en el HUD para la ejecución del contrato y propuesta de acondicionamiento de los espacios que será asumido íntegramente por el adjudicatario. En el supuesto de que fuera necesaria la salida del HUD de la documentación a digitalizar, la empresa adjudicataria dispondrá de todos los medios, procedimientos y sistemas de seguridad que resulten precisos en cumplimiento de la normativa y de la prudencia debida, en consideración a las características del material y la trascendencia de la información contenida en la documentación clínica. El adjudicatario aportará los medios técnicos y materiales necesarios para la correcta ejecución de los trabajos. Los medios instalados en el Hospital para que el personal del archivo pueda ejecutar los trabajos de digitalización a partir del día 2 de enero de 2015, quedarán en propiedad del HUD una vez finalizado el contrato, no obstante el adjudicatario podrá utilizar otros medios técnicos de su propiedad como apoyo al proyecto. Será responsabilidad de la empresa adjudicataria el mantenimiento y control de calidad de todas las herramientas que se utilicen en las diversas fases de los servicios contratados. 5.2 RECURSOS HUMANOS La empresa adjudicataria pondrá a disposición del HUD el personal especializado y debidamente acreditado en el tratamiento documental sanitario con la finalidad de formar al personal del archivo sobre los siguientes aspectos:

� Funcionamiento software de digitalización e indexación. � Funcionamiento escáneres y mantenimiento de los mismos. � Selección y expurgo de la documentación. � Parametrización y clasificación de los lotes documentales. � Escaneo de los documentos según las características técnicas del escáner.



Página 7 de 13

� Indexación de las imágenes digitalizadas. � Revisión de la indexación.

La empresa licitadora especificará en su oferta la composición y cualificación del equipo de trabajo y años demostrables de experiencia en el tratamiento, expurgo y digitalización de documentación clínica. Este personal será propio de la empresa adjudicataria y terminará su servicio en el Centro simultáneamente a la finalización del contrato. Formación. El adjudicatario deberá acompañar en su oferta un plan de formación para el personal del archivo del HUD, en el que se deberá concretar la formación que propone, detallando el contenido, cronograma y duración de la misma, así como la metodología y recursos a emplear.

La formación deberá realizarse de lunes a viernes, en los horarios que determine el HUD. La empresa adjudicataria garantizará, por lo que respecta a su propio personal, el cumplimiento de las normativas aplicables en materia de recursos humanos, seguridad social, minusvalía, salud y prevención de riesgos laborales, así como otras de general aplicación. Uniformidad. Será obligación del contratista identificar de forma visible a todo su personal durante las horas en que realice el servicio dentro del recinto del HUD.

6.- OBLIGACIONES GENERALES DEL ADJUDICATARIO La empresa adjudicataria será la responsable de la calidad técnica de los trabajos que desarrolle, de las prestaciones y servicios realizados, así como de las consecuencias que se deriven por las omisiones, errores y métodos inadecuados. La empresa adjudicataria elaborará y planificará el servicio teniendo en cuenta al personal aportado por el Centro y que el servicio diario de gestión de las historias en el hospital debe continuar sin ninguna alteración.

7.- RESPONSABILIDAD 7.1 RESPONSABILIDAD LABORAL La responsabilidad empresarial de los trabajadores que presten el servicio objeto del contrato, será en todos los órdenes, jurídico-legales, de la empresa que resulte adjudicataria. Por ello, la relación de los mismos con el HUD será intermediada por la empresa adjudicataria que los tenga contratados y sin que, en ningún caso, pueda deducirse para dicho hospital obligación alguna de tipo laboral, civil, administrativa, frente a los mismos.



Página 8 de 13

El adjudicatario se obligará al cumplimiento, bajo su exclusiva responsabilidad, de las disposiciones vigentes sobre relaciones laborales, seguridad social y cualquier otra de carácter general con respecto a las personas que aporte para el cumplimiento del servicio. 7.2 RESPONSABILIDAD LEGAL EN MATERIA DE PROTECCIÓN DE DATOS DE CARÁCTER PERSONAL La empresa adjudicataria será la responsable de dotar de todas las medidas necesarias para garantizar el cumplimiento de la legislación vigente en cada momento, en materia de Protección de Datos de Carácter Personal y será asimismo responsable de su cumplimiento en todos sus extremos. El adjudicatario como encargado del tratamiento, tal y como se define en la letra g) del artículo 3 de la Ley Orgánica 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal, declara expresamente que conoce quedar obligado al cumplimiento de los dispuesto en la citada LOPD y especialmente en lo indicado en sus artículos 9,10 y 12, adoptando las medidas de seguridad que le correspondan según el Real Decreto 1720/2007, de 21 de diciembre, Reglamento de desarrollo de la LOPD. Igualmente serán de aplicación las disposiciones de desarrollo de las normas anteriores que se encuentren en vigor a la adjudicación de este contrato o que puedan estarlo durante su vigencia, y aquellas normas del Real Decreto 1720/2007, de 21 de diciembre, Reglamento de desarrollo de la LOPD. La empresa adjudicataria declara expresamente que conoce quedar obligada al cumplimiento de lo dispuesto en LO 15/1999, de 13 de diciembre, de Protección de Datos de Carácter Personal y, expresamente en lo indicado en su artículo 10 en cuanto al deber de secreto. Se deberá de cumplir la normativa de la legislación de la CAPV, de la legislación española y comunitaria, entre otros la Ley de Sanidad 14/86; Ley de Protección de Datos 15/99 y su Reglamento; Ley 41/02 de 14 de noviembre de 2002; Decreto 175/89 de la CAPV; Decreto 303/92 de la CAPV; Decreto 38/2012 de la CAPV. La empresa adjudicataria y el personal encargado de la realización de las tareas guardará secreto profesional sobre todas las informaciones, documentos y asuntos a los que tenga acceso o conocimiento durante la vigencia del contrato, estando obligados a no hacer públicos o enajenar cuantos datos conozcan como consecuencia o con ocasión de su ejecución, incluso después de finalizar el plazo contractual. Los licitadores deberán aportar una memoria descriptiva, de las medidas que adoptarán para asegurar la confidencialidad e integridad de los datos manejados y de la documentación facilitada. Asimismo, la empresa adjudicataria deberá comunicar al organismo contratante, la persona o



Página 9 de 13

persona que serán directamente responsables de la puesta en práctica y de la inspección de dichas medidas de seguridad, adjuntando su perfil profesional. Si la empresa adjudicataria aporta equipos informáticos, una vez finalizadas las tareas, el adjudicatario, previamente a retirar los equipos informáticos, deberá borrar toda la información utilizada o que se derive de la ejecución del contrato, mediante el procedimiento técnico adecuado. La destrucción de la documentación de apoyo, si no se considera indispensable, se efectuará mediante máquina destructora de papel o cualquier otro medio que garantice la ilegibilidad, efectuándose esta operación en el lugar donde se realicen los trabajos. El adjudicatario se compromete a no dar información y datos proporcionados por el organismo contratante para cualquier otro uso no previsto en el presente Pliego. En particular, no proporcionará, sin autorización escrita del organismo contratante, copia de los documentos o datos a terceras personas. Todos los productos entregados y/o resultantes del alcance de este proyecto quedarán en exclusiva propiedad de Osakidetza, quedando el adjudicatario obligado a renunciar a cualquier derecho sobre estos conceptos. El resultado de las tareas realizadas, así como el soporte utilizado serán propiedad de Osakidetza.

8.- PROGRAMA DE TRABAJO Y PROYECTO TÉCNICO El licitador aportará Programa de Trabajo en el que se especifiquen los contenidos o tareas a realizar, su distribución en el tiempo de forma suficientemente clara y desarrollada, que permita evaluar la viabilidad de su instalación y puesta en marcha. En el supuesto de que dicho programa contemple la posibilidad de realizar parte del servicio fuera de las instalaciones del HUD, serán a cargo del adjudicatario los gastos derivados de la preparación, transporte y custodia temporal de las Historias hasta su destrucción y/o devolución. Este cronograma incluirá, asimismo, los diferentes hitos de objetivos y el plan de implantación, que garantice la disponibilidad de las historias clínicas digitalizadas. Incluirá también la solución propuesta para la integración en el sistema de la documentación no informatizada proveniente de los aparatos de electromedicina. Además la empresa licitadora aportará un Proyecto Técnico que contendrá obligatoriamente y como mínimo los siguientes aspectos:

• Documentación concerniente al proceso de gestión, objeto del contrato, expresando por escrito sus compromisos de cumplimiento del Servicio en los términos descritos en el presente Pliego.

• Recursos humanos: Estructura orgánica de la empresa y relación del personal que destinará al proyecto.

• Plan de Formación que la empresa se propone realizar durante la ejecución del contrato.



Página 10 de 13

• Recursos materiales y técnicos: Relación detallada de los recursos materiales, auxiliares y técnicos de que dispone la empresa y aquellos que se compromete a poner a disposición del Centro para la ejecución del contrato.

• Plan de seguridad. Certificado emitido por la empresa licitadora acreditando el cumplimiento de todas las medidas de seguridad y la normativa legal vigente en especial en materia de seguridad. Anexo a dicho certificado, una relación detallada concretando las medidas de seguridad (físicas, informáticas o de cualquier otra índole) a aplicar en cada fase del proceso, en especial aquellas destinadas a prevenir la materialización de amenazas para la información o a reducir el impacto de las mismas en caso de realización.

• Memoria descriptiva, de las medidas que adoptarán para asegurar la confidencialidad e integridad de los datos manejados y de la documentación facilitada.

• Plan de contingencia que presente la solución para el caso de que se requiera una historia clínica que se encuentre fuera de las instalaciones del HUD.

9.- DESTRUCCION DE LA DOCUMENTACIÓN La empresa adjudicataria mantendrá la documentación en custodia durante un plazo de seguridad aproximado de 2 meses desde la finalización del trabajo. Una vez finalizado el mismo, y previa autorización firmada por el HUD dando su conformidad, se procederá a la destrucción de la documentación en los términos establecidos en la Ley. Realizada la destrucción total de la documentación, la empresa adjudicataria entregará al responsable del proyecto un informe y certificado de la destrucción realizada que incluirá todos los datos de la misma para garantizar la trazabilidad:

• Fecha de recogida de la documentación

• Cantidad de HHCC

• Descripción de la documentación destruida, series documentales procesadas, nº de soportes por serie...

• Fecha de destrucción de la documentación.

• Fotocopia del albarán de retiro de documentación para destrucción, autentificada por la empresa adjudicataria.



Página 11 de 13

10.- CRITERIOS DE ADJUDICACION 10.1.- Criterios de adjudicación basados en juicio de valor 50%

Puntos subcriterios

Puntuación total

Umbral mínimo

1.- PROGRAMA DE TRABAJO.29% 29 22

1.1.Proceso de gestión: Tareas a realizar, cronograma y puesta en marcha del proyecto. 10%

10

1.2.Recursos materiales y técnicos Relación detallada de los recursos materiales, auxiliares y técnicos de que dispone la empresa y aquellos que se compromete a poner a disposición del HUD durante y después de finalizado el contrato. 7%

7

1.3.Recursos humanos. Relación de personas que la empresa destinará al proyecto, su cualificación y funciones. 2%

2

1.4.Memoria descriptiva. Medidas que se adoptarán para asegurar la confidencialidad 2%

2

1.5.Plan de contingencia. Solución para el caso que se requiera una historia clínica que se encuentre fuera de las instalaciones del HUD.4%

4

1.6. Plan de formación 4% 4

2.- PROYECTO TECNICO. Solución técnica y ergonómica en cuanto al programa informático presentado.15%

15 10

2.1. Sw desarrollado bajo estándares y compatibilidad con la plataforma de Osakidetza 9%

9

2.2. Usabilidad 3% 3

2.3. Rapidez 3% 3

3.- SISTEMAS EXTERNOS. Integración con Osakidetza, según el anexo I. 6%

6 6 3

TOTAL 50 puntos

Las empresas licitadoras que no alcancen el umbral mínimo en el programa de trabajo o en la solución técnica, quedarán excluidas y no serán valoradas en la siguiente fase. Asímismo quedarán excluidas aquellas empresas, que no alcancen como mínimo la mitad de los puntos asignado a cada ítem.



Página 12 de 13

10.2. Criterios evaluables de forma automática mediante la aplicación de fórmulas

50%.

ECONOMICO PUNTOS

MAXIMOS FORMULA

PRECIO SUBLOTE 1

20

Se otorgarán 20 puntos a la oferta más económica y 0 puntos a las ofertas cuyos importes coincidan con el presupuesto base de licitación, las que lo superen quedarán excluidas. El resto de ofertas obtendrá una puntuación proporcional de acuerdo a la siguiente fórmula: ( Presupuesto base de licitación - oferta a valorar) / (presupuesto base de licitación - oferta más económica)*20. (20%)

PRECIO SUBLOTE 2

30

Se otorgarán 30 puntos a la oferta más económica y 0 puntos a las ofertas cuyos importes coincidan con el presupuesto base de licitación, las que lo superen quedarán excluidas. El resto de ofertas obtendrá una puntuación proporcional de acuerdo a la siguiente fórmula: ( Presupuesto base de licitación - oferta a valorar) / (presupuesto base de licitación - oferta más económica)*30. (30%)

Total 50 puntos .

11- PRESUPUESTO, PLAZO DE EJECUCIÓN Y FORMA DE PAGO

11.1 PRESUPUESTO DEL CONTRATO

- Implantación, desarrollo y formación.

- Además de las herramientas hardware y software necesarias, puesta en marcha y consolidación del proyecto.

- Ampliación equipos almacenamiento corporativos HDS VSP

- Seguimiento y supervisión del proyecto durante la vigencia del contrato

55.000 euros

- Digitalización de 125.000 Historias Clínicas a 2.96€/unidad.

370.000 euros

PRESUPUESTO DE LICITACIÓN ( IVA excluido)

425.000,00 euros



Página 13 de 13

11.2 PLAZO DE EJECUCIÓN El plazo de ejecución del contrato será de 16 meses a contar desde la fecha de inicio establecida en el documento contractual. 11.3 FACTURACIÓN La facturación se distribuirá de la siguiente manera: La mitad del importe de la adjudicación se facturará en los primeros cuatro (4) meses del contrato coincidiendo con cuatro entregas mensuales y la otra mitad repartido en los doce (12) meses siguientes a partes iguales. El presente pliego de bases técnicas (PBT) consta de 13 páginas y un Anexo I normalizado por los servicios informáticos de la Organización Central de Osakidetza con dos partes:

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

• Especificaciones de Interoperabilidad. Requisitos técnicos.

En Donostia- San Sebastián a 13 de marzo de 2014

EL ORGANO DE CONTRATACION

Fdo.: José Manuel L. de Guevara Portugal DIRECTOR GERENTE DEL HUD

DONOSTIA UNIBERTSITATE OSPITALEA


Página 1 de 13

ANEXO I

• Repositorio de Sistemas externos / Digitalización. Guía

para el centro y proveedor

• Especificaciones de Interoperabilidad. Requisitos

Técnicos

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

Página. 2 de 13

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

Versión: v.2.4

Fecha: 29/10/2013





Fecha:

29/10/2013

Página. 3 de 13

ÍNDICE

1 Introducción ...................................... .............................................................. 4

1.1 Definición de Sistema Externo ............................................................... 4

1.2 Tipos de Sistemas Externos .................................................................. 4

1.3 Requisitos para los Sistemas Externos.................................................. 4

1.4 Niveles a los que asociar un informe ..................................................... 5

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

2.1 Arquitectura de Desarrollo ..................................................................... 6

2.2 Catálogo de Servicios Web .................................................................... 9

2.3 Conector SFTP ...................................................................................... 10

3 Proceso ........................................... ................................................................ 11

3.1 Sistemas Externos con integración total ................................................ 11

3.2 Sistemas Externos con integración nula ................................................ 11

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





Fecha:

29/10/2013

Página. 4 de 13

1 Introducción

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

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

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





Fecha:

29/10/2013

Página. 5 de 13

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

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





Fecha:

29/10/2013

Página. 6 de 13

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

2.1 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





Fecha:

29/10/2013

Página. 7 de 13

identificadas Clinic y OsabideGlobal como aplicaciones que consultarán estos informes pudiéndose ampliar el abanico





Fecha:

29/10/2013

Página. 8 de 13

Para obtener este dibujo en formato

png acceda al siguiente enlace

Sistemas Externos.png

de13

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

Para más información se puede consultar los siguientes anexos.

B61_SistExtConsultaWS_v06.00.doc

B61_SistExtRegistroWS_v10.00.doc

de13

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

Para más información se puede consultar el siguiente anexo.

Sistemas Externos.DSI.DFS_ConectorFTP_2013.02.27_v04.00.doc

de13

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

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

3.2 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 en el siguiente anexo.

Sistemas Externos.DSI.DFS_Requisitos_de_Nomenclatura_y_Formato_2012.09.27_V2.1.3.doc

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. A continuación se ofrece una guía de los cómo configurar el servicio.

de13

Sistemas Externos.DSI.DFS_Configuración Servicio Escucha_2012.11.27_v02.00.doc

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. A continuación se ofrece una guía de los cómo programar el servicio.

Sistemas Externos.DSI.DFS_Programar Servicio Escucha_2012.11.27_v02.00.doc

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.

4 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 La plantilla a rellenar será la siguiente, una por cada Sistema Externo:

CPD22-CODSE-NOMSE-SISTEMA EXTERNO-ANEXO_FICHA_DE_APLICACION_V5.doc

de13

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

de13




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

de13

ÍNDICE

1 Introducción ...................................... ............................................................. 3

2 Arquitectura orientada a servicios ................ ............................................... 4

2.1 Resumen de los estándares soportados ............................................... 4

2.2 Requisitos funcionales ........................................................................... 6

3 Arquitectura orientada a Eventos .................. ............................................... 7

3.1 Propósito ............................................................................................... 7

3.2 Estándares de Comunicación ................................................................ 7

3.3 Alcance .................................................................................................. 7

3.4 Arquitectura de Event Manager ............................................................. 7

3.5 Mensajería. Definición de un evento ...................................................... 8

3.6 Publicación de eventos mediante mensajería JMS ............................... 10

3.7 Publicación de eventos mediante servicio web ..................................... 11

3.8 Subscripción a eventos mediante servicio web ..................................... 12

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

de13

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

de13

6 Arquitectura orientada a servicios

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

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

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

de13

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

6.1.3 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 intranet

Implementació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

GlobalAplicaciones

IntranetXxx

Login de apliación:

Usuario/Pass o Certificado

Certificado de

aplicación

Certificado de

aplicación

Certificado de

aplicación

Clientes

Internet

HTTPS

Proxy Services

POLITICAS OWSM:

oracle/wss10_x509_token_with_message_sign_service_policy

oracle/auditoria

Business Services

de13

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

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

de13

7 Arquitectura orientada a Eventos

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

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

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

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

de13

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

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

de13

• 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

de13

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

7.6 Publicación de eventos mediante mensajería JMS

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


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

de13

7.7 Publicación de eventos mediante servicio web

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

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

de13

7.8 Subscripción a eventos mediante servicio web

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

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

de13

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

SERVICIO DE DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS ... · DE HISTORIAS CLINICAS PARA EL...

Documents

Transcript of SERVICIO DE DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS ... · DE HISTORIAS CLINICAS PARA EL...