SERVICIO DE DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS CLINICAS PARA EL HOSPITAL UNIVERSITARIO DONOSTIA

Transcripción

1 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA PLIEGO DE BASES TÉCNICAS Nº EXPTE: G/205/20/1/0655/O301/0000/ SERVICIO DE DIGITALIZACIÓN/INFORMATIZACIÓN DE HISTORIAS CLINICAS PARA EL HOSPITAL UNIVERSITARIO DONOSTIA Página 1 de 13

2 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 2 de 13

3 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 SITUACIÓN ACTUAL Historias físicas activas actuales HUD: 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 Historias, como media se calcula que cada Historia contiene 2,34 episodios y cada episodio 22,72 documentos. Página 3 de 13

4 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 A partir de febrero y en los meses sucesivos son aquellas HHCC diferentes que no se han servido en meses anteriores Recursos humanos actuales en el Archivo del HUD Personal del HUD: 22 personas dedicadas a las tareas de archivo 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 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 4 de 13

5 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA - 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 5 de 13

6 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 6 de 13

7 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 7 de 13

8 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 8 de 13

9 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 9 de 13

10 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 10 de 13

11 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 10.- CRITERIOS DE ADJUDICACION Criterios de adjudicación basados en juicio de valor 50% Puntos subcriterios Puntuación total Umbral mínimo 1.- PROGRAMA DE TRABAJO.29% Proceso de gestión: Tareas a realizar, cronograma y puesta 10 en marcha del proyecto. 10% 1.2.Recursos materiales y técnicos Relación detallada de los 7 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% 1.3.Recursos humanos. Relación de personas que la empresa 2 destinará al proyecto, su cualificación y funciones. 2% 1.4.Memoria descriptiva. Medidas que se adoptarán para 2 asegurar la confidencialidad 2% 1.5.Plan de contingencia. Solución para el caso que se requiera 4 una historia clínica que se encuentre fuera de las instalaciones del HUD.4% 1.6. Plan de formación 4% PROYECTO TECNICO. Solución técnica y ergonómica en cuanto al programa informático presentado.15% 2.1. Sw desarrollado bajo estándares y compatibilidad con la 9 plataforma de Osakidetza 9% 2.2. Usabilidad 3% Rapidez 3% SISTEMAS EXTERNOS. Integración con Osakidetza, según el anexo I. 6% TOTAL 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 11 de 13

12 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA Criterios evaluables de forma automática mediante la aplicación de fórmulas 50%. ECONOMICO PRECIO SUBLOTE 1 PRECIO SUBLOTE 2. Total PUNTOS MAXIMOS FORMULA 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%) 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%) 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 euros - Digitalización de Historias Clínicas a 2.96 /unidad euros PRESUPUESTO DE LICITACIÓN ( IVA excluido) ,00 euros Página 12 de 13

13 DONOSTIA UIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA 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 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 Página 13 de 13

14 DONOSTIA UNIBERTSITATE OSPITALEA HOSPITAL UNIVERSITARIO DONOSTIA ANEXO I Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Especificaciones de Interoperabilidad. Requisitos Técnicos Página 1 de 13

15 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Desarrollo y Mantenimiento de Aplicaciones 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: 29/10/2013 Página. 2 de 13

16 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor ÍNDICE Desarrollo y Mantenimiento de Aplicaciones Fecha: 29/10/ Introducción Definición de Sistema Externo Tipos de Sistemas Externos Requisitos para los Sistemas Externos Niveles a los que asociar un informe Descripción de la Aplicación Sistemas Externos Arquitectura de Desarrollo Catálogo de Servicios Web Conector SFTP Proceso Sistemas Externos con integración total Sistemas Externos con integración nula Documentación a facilitar por Sistema Externo Página. 3 de 13

17 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Desarrollo y Mantenimiento de Aplicaciones Fecha: 29/10/ 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. Página. 4 de 13

18 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Desarrollo y Mantenimiento de Aplicaciones El Sistema Externo se podrá integrar con el Servicio Web de grabación de metadatos. Fecha: 29/10/2013 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 usuarioftp@sftp-aplic.osakidetza.svs.local i certificado_privado.ppk Ejemplo prueba en un entorno PREproduccion El puesto debe tener instalado el MS Framework.NET 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. Página. 5 de 13

19 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor 2 Descripción de la Aplicación Sistemas Externos Desarrollo y Mantenimiento de Aplicaciones Fecha: 29/10/2013 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 Página. 6 de 13

20 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Desarrollo y Mantenimiento de Aplicaciones Fecha: 29/10/2013 identificadas Clinic y OsabideGlobal como aplicaciones que consultarán estos informes pudiéndose ampliar el abanico Página. 7 de 13

21 Subdirección de Informática y Sistemas de Información Nombre del documento: B61 Repositorio de Sistemas externos / Digitalización. Guía para el centro y proveedor Desarrollo y Mantenimiento de Aplicaciones Fecha: 29/10/2013 Para obtener este dibujo en formato png acceda al siguiente enlace Sistemas Externos.png Página. 8 de 13

22 2.2 Catálogo de Servicios Web SistExtConsultaWS Descripción SistExtRegistroWS Descripción Consulta de los informes originados por cualquier Sistema Externo 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) Graba el metadata de los informes originados por cualquier Sistema Externo 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_SistExtConsulta WS_v06.00.doc B61_SistExtRegistro WS_v10.00.doc Página 9 de13

23 2.3 Conector SFTP ConectorFTP Descripción Graba el informe facilitado en el destino indicado 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_ _v04.00.doc Página 10 de13

24 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_ _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. Página 11 de13

25 Sistemas Externos.DSI.DFS_Configuración Servicio Escucha_ _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_ _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-NOM SE-SISTEMA EXTERNO-ANEXO_FICHA_DE_APLICACION_V5.doc Página 12 de13

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

27 Nombre del documento: Especificaciones de Interoperabilidad. Requisitos Técnicos Subdirección de Informática y Sistemas de Información Desarrollo y Mantenimiento de Aplicaciones 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 Página 1 de13

28 ÍNDICE 1 Introducción Arquitectura orientada a servicios Resumen de los estándares soportados Requisitos funcionales Arquitectura orientada a Eventos Propósito Estándares de Comunicación Alcance Arquitectura de Event Manager Mensajería. Definición de un evento Publicación de eventos mediante mensajería JMS Publicación de eventos mediante servicio web Subscripción a eventos mediante servicio web Anexo Servicio Mantenimiento y/o Evolución Página 2 de13

29 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). Página 3 de13

30 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 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 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) Página 4 de13

31 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. Arquitectura seguridad internet e intranet Implementación de políticas con OWSM Clientes Internet DMZ WAF HTTPS Login de apliación: Usuario/Pass o Certificado Zzz Certificado de aplicación Xxx Certificado de aplicación Yyy Certificado de aplicación Aplicaciones Internet HTTP OSB Internet Cola JMS de Auditoría Proxy Services POLITICAS OWSM: oracle/wss10_x509_token_with_message_sign_service_policy oracle/auditoria Base de Datos de Auditoría Business Services Intranet Servios Web Internet HIS OSB Intranet HIS Osabide Global Xxx Aplicaciones Intranet Base de Datos HIS Página 5 de13

32 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. Página 6 de13