PPT HCU.pdf

{# full_text keeps real newlines; whitespace-pre-wrap renders them (so no |linebreaks filter, which would double the spacing). #}

<!-- image --> PLIEGO TÉCNICO PARA LA PRESTACIÓN DE LOS SERVICIOS DE IMPLANTACIÓN DE UN SISTEMA DE INFORMACIÓN DE HISTORIA CLÍNICA ÚNICA CENTRALIZADA SOBRE UNA INFRAESTRUCTURA TECNOLÓGICA EN CLOUD PARA LA COMUNIDAD VALENCIANA ## ÍNDICE | 1 | INTRODUCCIÓN......................................................................................................................4 | INTRODUCCIÓN......................................................................................................................4 | INTRODUCCIÓN......................................................................................................................4 | |-------|------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | 2 | OBJETO..................................................................................................................................7 | OBJETO..................................................................................................................................7 | OBJETO..................................................................................................................................7 | | 3 | ALCANCE DEL PROYECTO........................................................................................................9 | ALCANCE DEL PROYECTO........................................................................................................9 | ALCANCE DEL PROYECTO........................................................................................................9 | | 4 | FUNCIONALIDADES Y CARACTERÍSTICAS DE LA HCU ..............................................................12 | FUNCIONALIDADES Y CARACTERÍSTICAS DE LA HCU ..............................................................12 | FUNCIONALIDADES Y CARACTERÍSTICAS DE LA HCU ..............................................................12 | | | 4.1 | Cobertura funcional de los actuales sistemas de información............................................ 13 | Cobertura funcional de los actuales sistemas de información............................................ 13 | | | 4.1.1 | Validación de los procesos asistenciales y flujos de trabajo ........................................... 14 | Validación de los procesos asistenciales y flujos de trabajo ........................................... 14 | | | 4.1.2 | Procesos clínico-asistenciales y administrativos y flujos de trabajo ............................... 15 | Procesos clínico-asistenciales y administrativos y flujos de trabajo ............................... 15 | | | 4.1.3 | Compromiso de adecuación de las funcionalidades ....................................................... 15 | Compromiso de adecuación de las funcionalidades ....................................................... 15 | | | Control y cumplimiento de las prestaciones adicionales ............................................................. 15 | Control y cumplimiento de las prestaciones adicionales ............................................................. 15 | Control y cumplimiento de las prestaciones adicionales ............................................................. 15 | | 4.2 | Características de interoperabilidad y normalización de la Historia Clínica Única.............. 16 | Características de interoperabilidad y normalización de la Historia Clínica Única.............. 16 | Características de interoperabilidad y normalización de la Historia Clínica Única.............. 16 | | | 4.2.1 | Modelo de interoperabilidad de la Conselleria de Sanitat.............................................. 16 | Modelo de interoperabilidad de la Conselleria de Sanitat.............................................. 16 | | | 4.2.2 | Requerimientos de compatibilidad derivados de los sistemas actuales......................... 17 | Requerimientos de compatibilidad derivados de los sistemas actuales......................... 17 | | | 4.2.2.1 | 4.2.2.1 | Interoperabilidad con repositorio/plataforma FHIR............................................... 17 | | | 4.2.2.2 | 4.2.2.2 | Interoperabilidad con el gestor documental corporativo ...................................... 18 | | | 4.2.2.3 | 4.2.2.3 | Interoperabilidad con el LakeHouse corporativo ................................................... 19 | | | 4.2.2.4 | 4.2.2.4 | Interoperabilidad con la Plataforma de monitorización y captura de señales | | | corporativa ............................................................................................................................... 19 | corporativa ............................................................................................................................... 19 | corporativa ............................................................................................................................... 19 | | | 4.2.2.5 | 4.2.2.5 | Interoperabilidad con el proyecto del Gestor de Imágenes Médicas Digitales (GIMD/PACS) corporativo de la Comunitat Valenciana ........................................................... 19 | | | 4.2.2.6 | 4.2.2.6 | Interoperabilidad con el resto de los sistemas de la Conselleria de Sanitat .......... 20 | | 4.2.3 | Estándares de compatibilidad ......................................................................................... 22 | Estándares de compatibilidad ......................................................................................... 22 | Estándares de compatibilidad ......................................................................................... 22 | | | 4.2.3.1 | 4.2.3.1 | Interoperabilidad técnica........................................................................................ 22 | | | 4.2.3.2 | 4.2.3.2 | Interoperabilidad sintáctica.................................................................................... 23 | | | 4.2.3.3 | 4.2.3.3 | Interoperabilidad semántica................................................................................... 23 | | | 4.2.3.4 | 4.2.3.4 | Interoperabilidad organizacional............................................................................ 24 | | | 4.2.3.5 | 4.2.3.5 | Seguridad ................................................................................................................ 25 | | 4.2.4 | Otros requerimientos ...................................................................................................... 25 | Otros requerimientos ...................................................................................................... 25 | Otros requerimientos ...................................................................................................... 25 | | | 4.2.4.1 | 4.2.4.1 | Plataforma lanzadera de aplicaciones externas ..................................................... 25 | | | 4.2.4.2 | 4.2.4.2 | Integración con Nébula visor externo..................................................................... 26 | | | 4.2.4.3 | 4.2.4.3 | Integración con Plataforma Autonómica de Interoperabilidad de Datos Segura .. 27 | | 4.3 | Configuración y gobierno de la solución.............................................................................. 27 | Configuración y gobierno de la solución.............................................................................. 27 | Configuración y gobierno de la solución.............................................................................. 27 | <!-- image --> | | 4.4 | Migración de datos .............................................................................................................. 29 | |-----------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------| | 5 REQUISITOS TÉCNICOS .........................................................................................................30 | 5 REQUISITOS TÉCNICOS .........................................................................................................30 | 5 REQUISITOS TÉCNICOS .........................................................................................................30 | | 5.1 | Requisitos técnicos generales y arquitectura ...................................................................... | 30 | | 5.2 | Infraestructura y modelo de despliegue.............................................................................. | 33 | | 5.2.1 | Responsabilidades del adjudicatario............................................................................... | 34 | | 5.3 | Red y conectividad............................................................................................................... | 36 | | 5.3.1 | Red Corporativa de la Conselleria de Sanidad: Red Arterias........................................... | 36 | | 5.3.2 | Criterios y características para la HCU............................................................................. | 37 | | 5.4 | Seguridad ............................................................................................................................. | 38 | | 5.5 | Gestor o gestores de base de datos..................................................................................... | 39 | | 5.6 | Adecuación y soportes futuros ............................................................................................ | 40 | | 5.7 | Calidad del software ............................................................................................................ | 40 | | 6 REQUISITOS DE IMPLANTACIÓN ...........................................................................................42 | 6 REQUISITOS DE IMPLANTACIÓN ...........................................................................................42 | 6 REQUISITOS DE IMPLANTACIÓN ...........................................................................................42 | | 6.1 | Fases del proyecto ............................................................................................................... | 42 | | 6.1.1 | Fase de puesta en marcha e inicio .................................................................................. | 43 | | 6.1.2 | Fase de diseño y configuración de la solución 'Estándar' de la HCUydelainfraestructura | | | requerida ...................................................................................................................................... 43 | requerida ...................................................................................................................................... 43 | requerida ...................................................................................................................................... 43 | | 6.1.3 | Fase de implantación de la solución en los hospitales y HACLES.................................... | 44 | | 6.1.4 | Fase de mantenimiento y soporte post-arranque........................................................... | 45 | | 6.1.5 | Fase de finalización del contrato..................................................................................... | 46 | | 6.2 | Plan de implantación ........................................................................................................... | 46 | | 6.3 | Plan de soporte y gestión del cambio.................................................................................. | 48 | | 6.3.1 | Soporte a Usuarios .......................................................................................................... | 48 | | 6.3.2 | Gestión del Cambio ......................................................................................................... | 49 | | 6.4 Plan de formación................................................................................................................ 50 | 6.4 Plan de formación................................................................................................................ 50 | 6.4 Plan de formación................................................................................................................ 50 | | 6.4.1 | Modelo formativo............................................................................................................ | 50 | | 6.4.2 | Plataforma de formación................................................................................................. | 50 | | 6.4.3 | Cursos presenciales ......................................................................................................... | 51 | | 6.4.4 | Presencialidad en el soporte post-arranque ................................................................... | 52 | | 6.4.5 | Evaluación del plan de formación y conocimientos adquiridos...................................... | 52 | | 6.5 | Plan de comunicación.......................................................................................................... | 53 | | 6.6 | Plan de migración................................................................................................................. | 54 | | 6.7 | Plan de retorno del servicio de la HCU................................................................................ | 55 | | 7 | PLANIFICACIÓN Y GESTIÓN DEL PROYECTO...........................................................................57 | | | 7.1 | Gestión del proyecto requerida por parte del adjudicatario............................................... | 57 | | 7.1.1 7.1.2 | Metodología de trabajo................................................................................................... Servicios de la oficina de | 59 proyecto.................................................................................. 59 | <!-- image --> | 7.2 | | Herramientas para la gestión del proyecto ......................................................................... 60 | |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | | 7.2.1 Gestión de la documentación.......................................................................................... | 60 | | 7.2.2 | Entregables y herramientas............................................................................................. 60 | | | Entregables Fase de Puesta en Marcha e incio del proyecto................................................... 61 | Entregables Fase de Puesta en Marcha e incio del proyecto................................................... 61 | Entregables Fase de Puesta en Marcha e incio del proyecto................................................... 61 | | Entregables Fases de diseño y configuración de la solución e infraestructura, despliegue de la solución en los centros y mantenimiento................................................................................ 61 | Entregables Fases de diseño y configuración de la solución e infraestructura, despliegue de la solución en los centros y mantenimiento................................................................................ 61 | Entregables Fases de diseño y configuración de la solución e infraestructura, despliegue de la solución en los centros y mantenimiento................................................................................ 61 | | Entregables asociados al proyecto completo........................................................................... 63 | Entregables asociados al proyecto completo........................................................................... 63 | Entregables asociados al proyecto completo........................................................................... 63 | | Entregables Fase de finalización del contrato.......................................................................... 64 | Entregables Fase de finalización del contrato.......................................................................... 64 | Entregables Fase de finalización del contrato.......................................................................... 64 | | 7.2.3 | 7.2.3 | Gestión de la calidad ....................................................................................................... 64 | | 8 LICENCIAS ............................................................................................................................65 | 8 LICENCIAS ............................................................................................................................65 | 8 LICENCIAS ............................................................................................................................65 | | 9 GARANTÍA INTERAL DE LA SOLUCIÓN....................................................................................67 | 9 GARANTÍA INTERAL DE LA SOLUCIÓN....................................................................................67 | 9 GARANTÍA INTERAL DE LA SOLUCIÓN....................................................................................67 | | 9.1 Canales de Comunicación para la recepción y registro de incidencias................................ 67 | 9.1 Canales de Comunicación para la recepción y registro de incidencias................................ 67 | 9.1 Canales de Comunicación para la recepción y registro de incidencias................................ 67 | | 9.2 Soporte correctivo ............................................................................................................... 68 | 9.2 Soporte correctivo ............................................................................................................... 68 | 9.2 Soporte correctivo ............................................................................................................... 68 | | 9.3 Soporte preventivo .............................................................................................................. 70 10 | 9.3 Soporte preventivo .............................................................................................................. 70 10 | 9.3 Soporte preventivo .............................................................................................................. 70 10 | | Acuerdo de nivel de servicio (ANS)........................................................................................71 | Acuerdo de nivel de servicio (ANS)........................................................................................71 | Acuerdo de nivel de servicio (ANS)........................................................................................71 | | 10.1.1 Tiempos de respuesta a incidencias o peticiones ........................................................... 71 | 10.1.1 Tiempos de respuesta a incidencias o peticiones ........................................................... 71 | 10.1.1 Tiempos de respuesta a incidencias o peticiones ........................................................... 71 | | 10.1.2 Tiempos de resolución..................................................................................................... 71 10.1.3 Tiempos de respuesta de la aplicación............................................................................ 72 | 10.1.2 Tiempos de resolución..................................................................................................... 71 10.1.3 Tiempos de respuesta de la aplicación............................................................................ 72 | 10.1.2 Tiempos de resolución..................................................................................................... 71 10.1.3 Tiempos de respuesta de la aplicación............................................................................ 72 | | 10.1.4 Disponibilidad de la solución de HCU.............................................................................. 72 | 10.1.4 Disponibilidad de la solución de HCU.............................................................................. 72 | 10.1.4 Disponibilidad de la solución de HCU.............................................................................. 72 | | 10.1.5 Mantenimiento correctivo .............................................................................................. 72 | 10.1.5 Mantenimiento correctivo .............................................................................................. 72 | 10.1.5 Mantenimiento correctivo .............................................................................................. 72 | | 10.1.6 Mantenimiento evolutivo................................................................................................ 73 10.1.7 | 10.1.6 Mantenimiento evolutivo................................................................................................ 73 10.1.7 | 10.1.6 Mantenimiento evolutivo................................................................................................ 73 10.1.7 | | Compromiso de adecuación de las funcionalidades ....................................................... 74 Control y cumplimiento de las prestaciones adicionales ................................................ | Compromiso de adecuación de las funcionalidades ....................................................... 74 Control y cumplimiento de las prestaciones adicionales ................................................ | Compromiso de adecuación de las funcionalidades ....................................................... 74 Control y cumplimiento de las prestaciones adicionales ................................................ | | 74 Documentación del proyecto .......................................................................................... 75 10.1.10 Gestión administrativa del contrato................................................................................ 75 | 74 Documentación del proyecto .......................................................................................... 75 10.1.10 Gestión administrativa del contrato................................................................................ 75 | 74 Documentación del proyecto .......................................................................................... 75 10.1.10 Gestión administrativa del contrato................................................................................ 75 | | 10.1.8 10.1.9 | 10.1.8 10.1.9 | 10.1.8 10.1.9 | | ANEXO.................................................................................................................................76 | ANEXO.................................................................................................................................76 | ANEXO.................................................................................................................................76 | | 11 | 11 | 11 | ## 1 INTRODUCCIÓN El presente Pliego de Prescripciones Técnicas (en adelante PPT) tiene por finalidad describir las especificaciones y requisitos técnicos y funcionales, prestaciones y composición, que tendrán el carácter de mínimos, para la adquisición y puesta en marcha de un sistema de información de historia clínica única y centralizada (en adelante HCU ) para las ocho agrupaciones sanitarias interdepartamentales (en adelante ASI), centros adscritos a las ASIs y los HACLES de la Comunidad Valenciana. Una ASI es una estructura asistencial que integra hospitales y centros de atención primaria de diferentes departamentos de salud para asegurar el acceso de la población a la cartera de servicios en condiciones de equidad y de forma eficiente. Por tanto, la HCU debe dar respuesta funcional a las necesidades de los diferentes profesionales de salud que integran la ASI, sus hospitales, servicios, centros de especialidades y sus centros de atención primaria. Este contrato tiene un quíntuple objetivo: ## 1. Mejorar la Calidad Asistencial - Información completa y accesible: La nueva HCU proporcionará acceso inmediato a la historia clínica completa de la población atendida, incluyendo información relevante como alergias, medicaciones, resultados de pruebas, imágenes, etc., lo que facilita la toma de decisiones clínicas informadas y reduce el riesgo de errores. - Coordinación de la atención: La nueva HCU facilitará la comunicación y la coordinación entre los diferentes profesionales involucrados en la atención de la población atendida, mejorando la continuidad asistencial y evitando duplicidades o información contradictoria. Optimizando la integración e información entre Atención Primaria, Hospitalaria, Salud Pública e Inspección. - Soporte a la decisión clínica: La nueva HCU deberá incorporar herramientas de soporte a la decisión clínica (CDS), como alertas, recordatorios y guías de práctica clínica, que ayudan a los profesionales a tomar decisiones más seguras y efectivas. Así como incorporar algoritmos y la IA a la práctica diaria para la mejora y agilidad de la toma de decisiones. - Reducción de errores relacionados con la asistencia sanitaria: La digitalización de la información y la automatización de procesos reducirá el riesgo de errores de medicación, transcripción y otros errores comunes en la atención sanitaria. - Mejora de la seguridad de la población atendida: La nueva HCU facilitará la identificación de pacientes, la anonimización y seudonimización de los datos, cuando sea necesario, la detección precoz de deterioro agudo, la gestión de alergias y la conciliación de la medicación, lo que contribuirá a una mayor seguridad del paciente. ## 2. Aumentar Eficiencia Operativa - Optimización de flujos de trabajo: La nueva HCU permitirá automatizar tareas administrativas y clínicas, como la gestión de citas, la prescripción electrónica, la notificación y gestión de las EDO, la solicitud de pruebas y la generación de informes, lo que liberará tiempo a los profesionales para dedicarlo a la atención al paciente. - Reducción del uso de papel: La digitalización de la información reduce la necesidad de papel, lo que disminuye los costos de almacenamiento, impresión y gestión de documentos. - Mejora de la productividad: La automatización de tareas y la disponibilidad de información en tiempo real aumentan la productividad de los profesionales sanitarios y del personal administrativo. La incorporación de herramientas de GenIA serán clave en esta mejora de la productividad. <!-- image --> <!-- image --> - Facilitación de la investigación: La nueva HCU se convertirá en una de las fuentes primarias de datos para la investigación clínica y epidemiológica, facilitando el análisis de datos y la generación de conocimiento. ## 3. Aumentar la Satisfacción de Pacientes y Profesionales - Acceso a la información: El conjunto de la población atendida podrán acceder a su propia información médica a través de portales de pacientes, lo que les permitirá participar activamente en su cuidado y tomar decisiones informadas. - Reducción de la carga administrativa: La automatización de tareas administrativas, como la gestión de citas y la generación de informes, libera tiempo a los profesionales para dedicarlo a la atención de la población atendida. - Comunicación más efectiva: La nueva HCU facilitará la comunicación entre pacientes y profesionales, mejorando la relación médico-paciente y la satisfacción con la atención recibida. - Reducción de tiempos de espera: La optimización de los flujos de trabajo y la automatización de tareas contribuirán a reducir los tiempos de espera para la población atendida. - Mayor satisfacción profesional: Los profesionales sanitarios valoran la eficiencia, la accesibilidad a la información y el soporte a la decisión clínica que ofrece una HCU, lo que podrá mejorar su satisfacción laboral. ## 4. Atención centrada en el paciente: - Facilitar el acceso a la información: La HCU deberá permitir a la población atendida acceder a su información clínica de forma fácil y segura, a través del Portal del Paciente u otros medios. - Promover la participación del paciente: La HCU deberá facilitar la participación de los pacientes en la toma de decisiones sobre su cuidado, y permitirles aportar información y su experiencia. - Personalizar la atención: La HCU deberá permitir la personalización de la atención al paciente, teniendo en cuenta sus características individuales y sus preferencias. - Mejorar la comunicación : La HCU deberá facilitar la comunicación entre los pacientes y los profesionales sanitarios, a través de herramientas como la mensajería segura o la video consulta. - Proteger la privacidad: La HCU deberá garantizar la privacidad y la confidencialidad de los datos de los pacientes, cumpliendo con la normativa vigente. ## 5. Mejorar la salud poblacional: - Prevención y detección temprana: La HCU facilita la identificación de la población atendida con factores de riesgo o enfermedades crónicas, lo que permite implementar programas de prevención y detección temprana, mejorando la salud de la población a largo plazo. - Gestión de enfermedades crónicas: La HCU proporciona herramientas para el seguimiento y la gestión de pacientes con enfermedades crónicas, lo que permite una atención más coordinada y personalizada, mejorando los resultados de salud. - Análisis de datos poblacionales: La HCU proporciona datos agregados y anonimizados que pueden ser utilizados para análisis epidemiológicos, identificación de tendencias y planificación de servicios de salud, contribuyendo a mejorar la salud de la población en general. - Investigación clínica: La HCU facilita la investigación clínica al proporcionar acceso a datos anonimizados y estructurados, lo que permite realizar estudios más eficientes y obtener resultados más relevantes para la salud de la población. <!-- image --> Este proyecto se enmarca en la Estrategia de Salud Digital de la Conselleria de Sanidad, cuyo propósito es avanzar hacia un nuevo modelo de atención centrado en la persona, facilitando una visión integral del paciente, la toma de decisiones fundamentada en datos y la evaluación del valor de las intervenciones clínicas. ## 2 OBJETO El objeto del presente contrato es la adquisición, puesta en marcha y mantenimiento correctivo y evolutivo de un sistema de información de historia clínica única y centralizada para las ocho agrupaciones sanitarias interdepartamentales , centros adscritos a las ASIs y los HACLES de la Comunidad Valenciana, así como centros de salud pública e inspección, el servicio de emergencias médicas y el Centro de Transfusiones de la Comunitat Valenciana, a excepción de la atención primaria. El adjudicatario será responsable de: - Suministro y mantenimiento de una licencia universal y perpetua 1 de la última versión de software de la HCU, que integre todos los componentes de software base necesarios para su completa instalación y correcto desempeño. - Soporte y mantenimiento de esta licencia, que asegurará el acceso automático a mejoras en nuevas versiones y servicio de soporte por parte del fabricante. - Servicios de configuración, puesta en marcha y gestión de la plataforma tecnológica (Infraestructura) en la que se implantará y funcionará la HCU. Dicha infraestructura se plantea como una solución basada en SaaS (Software como servicio), en concreto en nube privada, donde el proveedor adjudicatario se responsabiliza de la provisión, gestión y dimensionamiento de la infraestructura subyacente (servidores, almacenamiento, red) y de los costes asociados al consumo de datos (transferencia, almacenamiento, procesamiento), garantizando la optimización de estos recursos, es decir, de la nube, según el apartado 5.2 del PPT. Estos servicios incluyen: - o El aprovisionamiento y configuración de los recursos de infraestructura necesarios. - o La administración de la infraestructura , incluyendo la creación de máquinas virtuales, la configuración de redes, la gestión de almacenamiento y la implementación de medidas de seguridad. - o La monitorización del rendimiento, disponibilidad y seguridad de la infraestructura. - o Y el mantenimiento y soporte técnico necesario y suficiente para la resolución de incidencias y problemas relacionados con la infraestructura. o - Servicios de puesta en marcha o implantación de la solución informática adquirida (HCU) en los hospitales y centros adscritos del sistema de sanidad pública valenciana, de acuerdo con las directrices fijada en el apartado 6 del PPT, lo que incluye: - o La Instalación, configuración y despliegue de los módulos, herramientas y funcionalidades exigidas en el PPT en los hospitales y centros de adscritos de las 8 ASIs, así como los HACLES adscritos a estas agrupaciones, centros de salud pública e inspección, el servicio de emergencias médicas y el Centro de Transfusiones de la Comunitat Valenciana, - o La configuración de la interoperabilidad con los actuales sistemas de información según los modelos y opciones que se describirán en el PPT. 1 Una licencia universal de uso de software, en este contexto de historia clínica, permite a toda la organización utilizar el sistema de forma ilimitada y sin restricciones para el ejercicio de sus competencias. Esto implica que todos los centros, servicios, profesionales dependientes de la entidad e incluso pacientes, puedan acceder, usar y, en su caso, adaptar la solución sin necesidad de licencias individuales o adicionales. Una licencia es además perpetua , significa que la organización adquiere el derecho de uso de forma indefinida, sin depender de renovaciones periódicas ni del pago de cuotas futuras, lo que garantiza la propiedad efectiva del derecho de uso . No obstante, el carácter perpetuo no implica necesariamente el acceso automático a mejoras o nuevas versiones del software. Para ello, es habitual que la organización mantenga contratos de soporte y mantenimiento , que le aseguren la evolución tecnológica de la solución y su alineación con los cambios normativos, funcionales y de seguridad . <!-- image --> <!-- image --> - o La migración de los datos requeridos en el PPT que garanticen la continuidad asistencial entre las soluciones existentes y la nueva HCU. - o El aseguramiento de un plan de formación que capacite y habilite al personal clínicoasistencial en el buen uso y manejo de la solución a todos los profesionales de los hospitales y centros de adscritos de las 8 ASIs, así como los HACLES de la Comunitat Valenciana, personal de Salud Pública, personal del Centro de Transfusiones de la Comunitat Valenciana y los profesionales de los servicios de emergencias médicas. - Servicios de mantenimiento correctivo y evolutivo de la solución que dará cobertura al soporte técnico requerido para el correcto funcionamiento, mediante la resolución de incidencias o caídas del sistema, realización de las tareas de control preventivo y actualización de versiones y/o software de base necesario, contemplando en cualquier caso el mantenimiento correctivo y evolutivo de la solución ofertada. Este suministro y puesta en marcha de la nueva HCU se entiende como un proyecto de tipo 'llave en mano', es decir, que incluirá la más completa instalación y puesta en servicio para su total operatividad. Si bien en la práctica habitual del mercado el suministro de una licencia universal y perpetua de software de una HCU se ha contemplado históricamente como parte de una solución 'llave en mano', donde el proveedor incluía en el precio de la licencia tanto el suministro como su mantenimiento y, en su caso, actualización, para este contrato se requiere un desglose específico de los costes asociados a cada componente. Por tanto, aunque la adquisición del suministro sigue siendo una de las prestaciones principales del contrato, y el mantenimiento y la actualización pueden considerarse prestaciones consustanciales y accesorias para alcanzar dicha finalidad, se detallará el importe correspondiente al mantenimiento de las licencias, no así del mantenimiento correctivo, evolutivo y soporte postarranque, que son servicios requeridos en la implantación de la solución. Los precios tomados en consideración para el cálculo siguen siendo los fijados por los propios fabricantes, pero se ha procedido a la desagregación de la parte correspondiente al mantenimiento. Esta desagregación no supone la aplicación de costes derivados del convenio colectivo de aplicación, dado que se trata de un producto estándar cuyo mantenimiento está determinado por el suministrador de antemano. ## 3 ALCANCE DEL PROYECTO En el DECRETO 121/2024, de 24 de septiembre, del Consell, se desarrolla la estructura, funcionamiento y régimen de coordinación entre los distintos centros y servicios integrados en las agrupaciones sanitarias interdepartamentales (ASI) y su integración en las estrategias de salud de la Conselleria de Sanidad. Ilustración 1: Mapa de la Comunidad Valenciana y su distribución de ASIs <!-- image --> El alcance del proyecto incluye los 24 departamentos de salud existentes en la Comunidad Valenciana con un total de 33 hospitales , incluyendo concesiones administrativas y consorcios, cada uno de ellos trabajando con 2 HIS (Hospital Information System) diferentes corporativos , IRIS e HIGIA, desarrollados con tecnología actualmente obsoleta que limita su funcionalidad y la integración con otras aplicaciones y 9 HIS distintos no corporativos. Así como también los 16 Centros de Salud Pública y los Servicios Centrales. Ilustración 2: Estado actual sistemas Atención Primaria y Atención Especializada <!-- image --> A continuación, se muestra el detalle de cada uno de los hospitales que conforman cada ASI, así como su HIS actual: <!-- image --> O <!-- image --> Ilustración 6. Detalle HACLES <!-- image --> <!-- image --> La nueva HCU única y centralizada no sólo deberá estar desplegada en los hospitales y HACLES, sino que también en los diferentes tipos de centros adscritos que se enumeran a continuación, con los módulos y funcionalidades que apliquen a cada caso y tipo de centro, pero con la capacidad para sus profesionales de visualizar la información completa de la Historia Clínica de un paciente: - Consultorio - Centro de salud - Centro de salud mental - Centro de conductas adictivas - Centro de salud sexual y reproductiva - Unidad de odontología - Centro de especialidades - Centro de alcohología - Centro de atención pediátrica - Centro sanitario integrado - Unidad de conductas adictivas - Hospital de día de salud mental - Punto de atención continuada - Hospital salud mental - Unidad básica de rehabilitación - Centro de desintoxicación - Centros sociosanitarios - Centros concertados - Centros de salud pública En aras que los licitadores puedan estimar el plan de implantación, formación y gestión del cambio, así como hacer una estimación de la migración en base a la actividad de cada centro, en el Anexo II -Estructura organizativa y volumetría hospitales se ha detallado toda esta información para tener un mayor contexto y entendimiento de la situación actual y alcance. Así mismo, en el Anexo III -Mapa aplicaciones de la Conselleria y APIS de integración se detalla por bloque funcional, la relación de sistemas que se encuentran implantados actualmente, bien de forma corporativa o departamental (por hospital). ## 4 FUNCIONALIDADES Y CARACTERÍSTICAS DE LA HCU En este apartado se establece los requisitos mínimos relativos a las características funcionales de la HCU. Estos requisitos no serán objeto de valoración como criterio de valoración. Uno de los pilares de la Estrategia de Salud Digital de la Comunidad Valenciana es la de evolucionar las capacidades de la Historia Clínica hacia un sistema único orientado a almacenar los datos de forma completa , accesible , usable y segura . Para ello se requiere disponer de una solución de HCU unificada y normalizada de alto rendimiento que: - Esté catalogada dentro del cuadrante mágico Gartner relativo a los Electronic Medical Record (EMR)/ Electronic Health Record (EHR) y/o mencionada en los Best in Klass Awards -Global Software, en los últimos 3 años. La fecha de inclusión de la solución en los mencionados reportes debe ser anterior o igual a la fecha de presentación de la oferta. - Haya facilitado la certificación de la Joint Commission International en al menos 1 implantación. - Haya ayudado a alcanzar el nivel de certificación Electronic Medical Record Adoption Model (EMRAM) HIMSS nivel 6 en al menos 5 implantaciones o el nivel 7 en al menos 1 implantación. - Ayude a cubrir y poder registrar la información clínico-asistencial de todos los procesos asistenciales de un hospital de nivel 1, 2, 3 o 4 (según especifica el decreto 121/2024 1 , de 24 de septiembre, que regula la estructura, el funcionamiento y la coordinación entre los centros sanitarios y servicios asistenciales integrados en las ocho agrupaciones sanitarias interdepartamentales (ASI) que conforman el actual sistema valenciano de salud) e incluya la atención primaria. - Tenga una alta capacidad de personalización para adaptarse a los flujos de trabajo y las preferencias que se marquen desde la Conselleria de Sanidad y teniendo también en cuenta las preferencias de los usuarios, en aspectos como el idioma, por ejemplo, o la capacidad de configuración de la propia estación clínica. - Facilite la comunicación y la colaboración entre los profesionales sanitarios, a través de herramientas de mensajería segura, videoconferencia y compartición de información. - La HCU deberá ofrecer la capacidad de crear unidades o servicios virtuales, que permitan la organización flexible y dinámica de los profesionales sanitarios y los recursos en torno a las necesidades de los pacientes, independientemente de su ubicación física o del centro al que pertenezcan. Características de las Unidades/Servicios Virtuales: - o Multidisciplinariedad: Permitir la creación de equipos multidisciplinares que incluyan profesionales de diferentes especialidades y categorías profesionales, para abordar la atención al paciente de forma integral. - o Multicentro: Facilitar la colaboración entre profesionales de diferentes centros sanitarios, permitiendo el acceso a la información del paciente y la coordinación de la atención de forma segura y eficiente. - o Flexibilidad: Permitir la creación y disolución de unidades virtuales de forma ágil, adaptándose a las necesidades cambiantes del sistema sanitario. - o Personalización: Permitir la configuración de las unidades virtuales con diferentes roles y permisos de acceso a la información, adaptándose a las características de cada equipo. - Pueda incorporar herramientas avanzadas de soporte a la decisión clínica (CDS) basadas en inteligencia artificial y machine learning, bien de forma directa en la solución o vía integración con terceras soluciones. 1 https://dogv.gva.es/es/eli/es-vc/d/2024/09/24/121/dof/spa/html <!-- image --> <!-- image --> - Permita la gestión de alertas personalizadas basadas en reglas, que se activen en tiempo real ante eventos clínicos relevantes, como resultados de laboratorio críticos, interacciones medicamentosas o riesgos de caídas. Como por ejemplo: la detección precoz de deterioro agudo basado en algoritmos como la escala NEWS2, qsofa u otros. - Incluya especificidad en las estaciones clínicas para diferentes profesionales sanitarios y diferentes ámbitos hospitalarios, con herramientas y plantillas adaptadas a las necesidades de cada área. A la vez que disponga de una experiencia de usuario optimizada que: - Disponga de una interfaz de usuario responsive, que se adapte automáticamente a diferentes dispositivos (ordenadores, tablets, smartphones) y resoluciones de pantalla. - Utilice técnicas de diseño intuitivo y experiencia de usuario (UX) para facilitar la navegación, la búsqueda de información y la realización de tareas. - Ofrezca opciones de personalización avanzada, que permitan a los usuarios configurar la interfaz, los flujos de trabajo y las alertas según sus preferencias. - Incorpore mecanismos de ayuda contextual y guías interactivas que faciliten el aprendizaje y el uso del sistema. - Garantice la accesibilidad para personas con discapacidad, cumpliendo con los estándares WCAG 2.1 nivel AA. Y tenga un enfoque basado en el dato y la innovación: - Facilite la investigación clínica y la innovación en el ámbito de la salud, proporcionando acceso a datos anonimizados y herramientas de análisis. - Se integre con dispositivos wearables y aplicaciones móviles de salud, permitiendo la captura y el análisis de datos de salud en tiempo real. - Facilite la participación de la población atendida en su cuidado, a través de herramientas de educación para la salud, recordatorios de citas y sistemas de monitorización domiciliaria. - Sea capaz de procesar información bajo el estándar ISO13606 y arquetipos, que interopere con estándares como FHIR, perfiles IHE o CDA. A continuación, se detallarán otros aspectos y funcionalidades que la solución propuesta debe cumplir. ## 4.1 Cobertura funcional de los actuales sistemas de información El adjudicatario deberá suministrar un producto de HCU que cubra, como mínimo , las funcionalidades y ámbitos actualmente disponibles en los sistemas existentes. En el Anexo I -Cobertura funcional de este PPT, se detalla las funcionalidades y ámbitos de los sistemas existentes (Orion-Clinic, IRIS e HIGIA, Orion-RIS, SIA) indicando para cada una de las funcionalidades el grado de cumplimiento que se requiere. Si bien en el anexo no se especifican exhaustivamente todas las funciones actuales, el adjudicatario se compromete a que la solución de HCU propuesta tenga: 1. Cubrimiento Integral de Funcionalidades Actuales : La solución de HCU deberá garantizar la continuidad y disponibilidad de todas las funcionalidades operativas actuales de los ámbitos existentes, asegurando que la nueva solución incluya los módulos y procesos esenciales para la operación óptima de las áreas clínicas, administrativas, financieras y de gestión. 2. Compromiso de Adecuación de las Funcionalidades : En caso de que la solución de HCU propuesta cubra parcialmente alguna de las funcionalidades exigidas de los módulos y sistemas actuales, el adjudicatario se compromete a desarrollar, implementar y poner en funcionamiento dichas funcionalidades dentro de un plazo acordado, sin generar costos adicionales para la Administración. La parcialidad de carencia de funcionalidades no podrá ser superior al 10%, de forma individual en cada uno de los sistemas que se definen en el Anexo I, <!-- image --> y no se admitirán soluciones cuya funcionalidad se haya marcado com o 'Imprescindible' y ésta la cobertura funcional sea parcial. En ningún caso, el plazo para la realización de las posibles adecuaciones será superior a la fecha prevista de implantación del primer hospital, fecha estimada según el plan de proyecto en el mes 12. El seguimiento y evaluación de estas adecuaciones se medirá a través de KPI dentro de los acuerdos de nivel de servicio detallados en siguientes apartados de este pliego. 3. Escalabilidad y Adaptabilidad : La solución de HCU deberá ser adaptable y escalable, con capacidad para incorporar futuras mejoras o modificaciones que surjan como parte de la evolución tecnológica o necesidades operativas no previstas al momento de la adjudicación. Para ello, los licitadores deberán presentar el roadmap a 5-8 años de la solución, indicando qué funcionalidades, herramientas y módulos que ya están comprometidos, desde las respectivas fábricas de desarrollo, en las siguientes versiones de producto (detallando qué funcionalidades se desplegaran en cada versión y año previsto de despliegue) e indicando el procedimiento y capacidad anual (horas y/o recursos) para la incorporación de nuevas funcionalidades que surjan directamente desde el equipo funcional de la Conselleria de Sanidad y cuya solución requiera desarrollo y no configuración o integración. 4. Garantía de Cumplimiento : El adjudicatario deberá garantizar que la solución de HCU cumpla con todos los requerimientos legales y normativos vigentes, y cualquier nueva regulación aplicable durante la vigencia del contrato. ## 4.1.1 Validación de los procesos asistenciales y flujos de trabajo En aras de poder evaluar y valorar las funcionalidades mínimas exigidas se solicitará a los licitadores los siguientes elementos: - Vídeos de una duración máxima de 5minutos por vídeo en los que se muestre cómo la solución ofertada da respuesta al proceso y/o flujo de trabajo solicitado en el Anexo V , en relación con las herramientas, funcionalidades, pasos que deberá realizar el usuario, interacción con otros sistemas u otros elementos disponibles en la solución. Por cada uno de los vídeos tan sólo se deberá mostrar lo concerniente a dicho caso de uso. En caso de que la solución requiera de adaptación en alguna de las funcionalidades exigidas, se deberá especificar, tanto en la memoria técnica como en el vídeo correspondiente. - Memoria descriptiva de las funcionalidades. - Para cada uno de los requisitos identificados en el Anexo I -Cobertura funcional , se deberá indicar si la solución: - o Cumple el requisito. - o No cumple el requisito. - o Cumple el requisito parcialmente. En la columna observaciones, se podrá indicar: - o Apartado donde la oferta refleja la información sobre el requisito. - o Descripción del modo de cumplimiento del requisito. - o Descripción de la adaptación requerida, complejidad, compromiso y tiempo estimado de desarrollo. La mesa de contratación se reserva el derecho de poder citar a aquellos licitadores sobre los que se requiera más detalle, para que se puedan realizar demostraciones en directo de los procesos y flujos de trabajo definidos. ## 4.1.2 Procesos clínico-asistenciales y administrativos y flujos de trabajo En el Anexo V -Procesos clínico-asistenciales y administrativos se ha detallado por cada proceso, las principales funcionalidades y acciones que se requieren visualizar en los vídeos que los licitadores deberán aportar. Se han documentado procesos clínico-asistenciales y administrativos y flujos de trabajo a nivel ámbito individual y también se han enumerado varios procesos transversales en los que se quiere visualizar cómo interaccionan varios módulos de la HCU y procesos. ## 4.1.3 Compromiso de adecuación de las funcionalidades El adjudicatario se compromete a informar a la Conselleria de Sanitat de forma periódica en cada uno de los comités de implantación sobre el estado y avance de las adecuaciones o desarrollos de nuevas funcionalidades requeridas y pendientes de implementar. Estas modificaciones serán las que queden reflejadas en el Anexo I y sobre las que el adjudicatario se comprometerá a incluir en la solución de HCU. Para la fecha prevista de implantación en el primer hospital, la versión de la solución a desplegar deberá estar cerrada, es decir, todas las adecuaciones y nuevas funcionalidades deberán estar completamente desarrolladas, implementadas y validadas. Se realizará un seguimiento del siguiente indicador y en caso de incumplimiento se procederá a la penalización correspondiente. | Indicador | Unidad de medición | Nivel permitido | Frecuencia | |--------------------------------------|--------------------------------------------------------------------------------------------------------------|-------------------|--------------| | Implantación completa de la solución | % de funcionalidades que requieren adecuación para cumplir las funcionalidades existentes en los SI actuales | 100% | Mensual | ## Control y cumplimiento de las prestaciones adicionales | Indicador | Unidad de medición | Nivel permitido | Frecuencia | |---------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|--------------| | Implantación de prestaciones adicionales propuestas en la memoria técnica | % de ámbitos, módulos y funcionalidades de prestaciones adicionales propuestas, priorizadas por el Comité de Dirección del proyecto e implantadas durante la vigencia del contrato | 100% | Semestral | El adjudicatario se compromete a informar a la Conselleria de Sanidad del estado y avance del despliegue de las prestaciones adicionales propuestas y priorizadas en la fase 1 del proyecto. <!-- image --> <!-- image --> ## 4.2 Características de interoperabilidad y normalización de la Historia Clínica Única Uno de los requisitos fundamentales para la implantación de la Historia Clínica Única es la interoperabilidad entre sistemas, concebida como la capacidad de varios sistemas o componentes para, intercambiar información, comprender estos datos y utilizarlos. De este modo, la información es compartida y está accesible desde cualquier punto de la red asistencial en la que se requiera su consulta, garantizando la coherencia y calidad de los datos en todo el sistema, con el consiguiente beneficio para la continuidad asistencial y la seguridad del paciente. La pieza fundamental de la interoperabilidad es la utilización de estándares que definan los métodos para llevar acabo estos intercambios de información. Mediante la utilización de estándares, se pretende unificar y simplificar la implementación de interfaces entre los sistemas, para lograr la integración entre ellos, reducir el coste de implantación y actualización, optimizar los flujos de trabajo, mejorar la eficiencia, reducir errores y en definitiva simplificar el acceso a la información de los pacientes. Las ofertas garantizarán un adecuado nivel de interoperabilidad técnica, semántica y organizativa, conforme a las estipulaciones del Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica (ENI). En concreto, se cumplirán las Normas Técnicas de Interoperabilidad establecidas por dicho esquema. Se cuidarán especialmente los aspectos de interoperabilidad orientados a la ciudadanía, de tal forma que se evite la discriminación a los ciudadanos por razón de sus elecciones tecnológicas. ## 4.2.1 Modelo de interoperabilidad de la Conselleria de Sanitat La Subdirección General de Tecnologías de la Información y las Comunicaciones para la Salud (SDGTICS) ha emprendido un ambicioso proyecto cuyo objetivo es la integración de los sistemas de información, de modo que sea posible dar respuesta a las necesidades particulares que se dan en cada una de las vertientes, a la vez que asegura el correcto flujo de información entre ellas y con aquellos sistemas que reúnen la información de la historia clínica del paciente. La solución resultante de este proyecto es una plataforma que contenga un repositorio con todos los datos de los diferentes sistemas de información que se irán conectando, a la vez que proporciona un mecanismo centralizado de intercambio de datos en tiempo real, sin la necesidad de implementar integración punto a punto entre los sistemas. Esta plataforma de almacenamiento es Global Repository, componente de Onesait HealthCare de Minsait, que almacena la información mediante la implementación del estándar FHIR® versión R4. Se trata de un estándar de nueva generación creado por HL7, que combina los principales beneficios de estándares anteriores (HL7 v2, HL7 v3 y Clinical Document Architecture (CDA)) a la vez que incorpora aquellos elementos no implementados en dichos estándares y que surgen como nuevas necesidades en los modelos de prestación de salud en las organizaciones. Además del FHIR® Server, Global Repository ha sido certificado en los perfiles de IHE para el intercambio de documentos: - IHE XDS: Cross Enterprise Document Sharing - IHE MHD: Mobile access to Health Documents La implementación de Global Repository proporciona una serie de tecnologías, estándares y decisiones de diseño que otorgan un conjunto de características técnicas que refuerzan la disponibilidad, fiabilidad, escalabilidad, flexibilidad e interoperabilidad del repositorio de información clínica: - Proporciona una indexación completa de todos los datos incluidos en cada recurso FHIR® - Dispone de capacidad para incluir nuevas extensiones sobre un objeto FHIR®. - Ofrece una capa de servicios FHIR® basada en una API RESTful (XML y JSON). - Soporta la búsqueda por todos los tipos de datos especificados en FHIR - La relación con el Global Repository se deberá realizar en base a los mecanismos de seguridad y autorización basada en OAuth2, con capacidad para integrarse con otros sistemas de identificación a través de SAML2 y JWT. En lo relativo a este contrato, y en relación con la lista de sistemas con los que la nueva HCU debe integrarse, la opción preferente de integración será vía la plataforma/repositorio FHIR®. Así mismo, el repositorio/plataforma FHIR® actuará de Gateway para que la HCU pueda interoperar con aquellos sistemas que estén en el plan de proyectos de adhesión del repositorio, evitando así la integración sistema a sistema. Durante el periodo de implantación de HCU existe la posibilidad que sea necesario realizar alguna integración uno a uno con aquellos S.I. que todavía no estén integrados con el Global Repository ni tampoco se pueda utilizar el propio Gateway de la plataforma/repositorio FHIR®. En esta situación se hará uso del motor de integración corporativo Rhapsody que gestiona las integraciones actuales, tanto para la instancia centralizada como con las instancias departamentales existentes en cada hospital Ilustración 7. Arquitectura digital de la ESD-CV e integraciones HCU <!-- image --> ## 4.2.2 Requerimientos de compatibilidad derivados de los sistemas actuales ## 4.2.2.1 Interoperabilidad con repositorio/plataforma FHIR La HCU debe tener capacidad de usar perfiles FHIR, mecanismos de autenticación y autorización (OAuth2, tokens) para acceder al repositorio FHIR, seguridad y privacidad, etc., adicionalmente, la HCU debe: - Utilizar modelos de información y ontologías compartidas para garantizar la consistencia semántica de los datos clínicos intercambiados entre la HCU y el repositorio FHIR. - Implementar mecanismos de validación semántica para asegurar la coherencia y la no contradicción de los datos intercambiados. - Asegurar que las terminologías clínicas utilizadas en la HCU se mapeen correctamente a los códigos y conceptos equivalentes en el repositorio FHIR <!-- image --> <!-- image --> - Implementar mecanismos de orquestación de servicios para coordinar el flujo de información entre la HCU, el repositorio FHIR y otros sistemas. - Implementar mecanismos de monitorización y gestión de errores para detectar y resolver problemas de interoperabilidad. - Tener capacidad de utilizar la API RESTful de FHIR® tanto para lectura y visualización de datos del repositorio en la HCU, como para persistencia de datos de la HCU en el repositorio. ## 4.2.2.2 Interoperabilidad con el gestor documental corporativo En la actualidad, la Conselleria de Sanitat cuenta con un gestor documental corporativo, una herramienta diseñada para la gestión centralizada, organizada y segura de todos los documentos generados en el ámbito sanitario. Este gestor permite almacenar, clasificar, acceder y compartir información clínica y administrativa de manera eficiente, garantizando la trazabilidad y confidencialidad de los datos conforme a las normativas de protección de datos y los estándares de interoperabilidad. El gestor documental corporativo desempeña un papel fundamental en la estrategia de Salud Digital de la Conselleria de Sanitat dentro del eje de Transformación de procesos eficientes, automatizando de forma progresiva los procesos y tareas complejas. En el contexto del proyecto de HCU, esta herramienta juega un papel clave como soporte central para la gestión integral de la documentación clínica. Su integración con la HCU permite la consolidación de la información sanitaria de los pacientes en un único repositorio accesible desde cualquier punto de atención sanitaria dentro del sistema, garantizando la continuidad asistencial. Además, actúa como una herramienta esencial para mantener el registro digitalizado de toda la documentación generada en el proceso asistencial, como informes médicos, resultados de pruebas diagnósticas, consentimientos informados, entre otros, ofreciendo una visión unificada y estructurada del historial clínico del paciente. A continuación, se indican los requerimientos que la solución debe cumplir en relación con el gestor documental: - La solución de HCU deberá ser capaz de almacenar documentos clínicos en el gestor documental corporativo utilizando la API REST, siguiendo la estructura de carpetas y metadatos definida por la GV. El tiempo de respuesta para el almacenamiento de un documento no deberá superar los 5 segundos. - La solución de HCU deberá permitir la subida de documentos clínicos al gestor documental corporativo en los formatos establecidos en el Esquema Nacional de Interoperabilidad y formatos propietarios Office 365, manteniendo la estructura original de los archivos. Cada documento almacenado en el gestor documental deberá contar con metadatos obligatorios como: identificador único del paciente, tipo de documento, fecha de creación, autor y especialidad médica. - La solución de HCU deberá ser capaz de leer y acceder a los documentos clínicos contenidos en el gestor documental y representarlos en el visor de Historia Clínica de la HCU. - La solución de HCU deberá ser capaz de iniciar y participar en flujos de trabajo definidos en el gestor documental, como el proceso de aprobación de informes médicos o la gestión de consentimientos informados. La integración deberá permitir la visualización del estado actual de los flujos de trabajo y las tareas pendientes desde la HCU. En caso de implementarse algún flujo interno, el resultado de éste se deberá integrar con el gestor documental. - La autenticación de usuarios en el gestor documental desde la solución de HCU se realizará mediante Single Sign-On (SSO), utilizando un proveedor de identidad compatible. - Todos los datos transmitidos entre la HCU y el gestor documental deberán estar cifrados utilizando el protocolo HTTPS. <!-- image --> - La solución de HCU deberá registrar todas las operaciones realizadas sobre los documentos en el gestor documental, incluyendo el usuario, la fecha, la hora y la acción realizada. - La solución de HCU deberá ser capaz de gestionar el mismo número mínimo de documentos que maneja el gestor documental, sin perder rendimiento. - La integración deberá soportar un mínimo de 50 usuarios concurrentes accediendo a documentos en el gestor documental desde la solución de HCU. ## 4.2.2.3 Interoperabilidad con el LakeHouse corporativo La Conselleria de Sanitat cuenta con una plataforma analítica avanzada desde la que poder hacer un uso primario y secundario de los datos. Si bien la fuente primaria de esta plataforma será el propio repositorio/plataforma FHIR®, la nueva HCU debe estar preparada para su conexión con la plataforma analítica, en caso de que se requiera, y con la granularidad y periodicidad del dato que se defina en los posibles casos de uso. El adjudicatario asumirá todos los procesos de ETL (Extract, Transform, Load) para transformar los datos de la HCU al formato requerido por el LakeHouse corporativo. ## 4.2.2.4 Interoperabilidad con la Plataforma de monitorización y captura de señales corporativa La nueva HCU se deberá integrar con la plataforma de monitorización y captura de señales corporativa de la CS, dicha plataforma permitirá capturar de manera agnóstica, centralizada e interoperable todos los datos biomédicos generados por el paciente en cualquier punto de la ruta asistencia (intra y extrahospitalaria, incluyendo el domicilio de pacientes), en tiempo real y en alta resolución, independientemente del tipo y marca de dispositivo médico. La plataforma no sólo incorporará herramientas para la captura y almacenamiento de las señales, sino que también ofrecerá servicios de visualización y digitalización de la ficha del paciente en todo el continuo asistencial; de forma que desde la HCU se podrá acceder a toda los datos de la monitorización de los principales parámetros hemodinámicos, sin saltos ni cortes, de por ejemplo, un paciente que entrando en urgencias, pase al área quirúrgica, posteriormente a la UCI y acabe en una planta de hospitalización. Se emplearán estándares de transmisión adaptados al entorno tecnológico vigente dentro del ámbito sanitario nacional y al tipo de dato enviado, como REST, SOAP, HL7 V2.X, HL7 CDA, HL7 FHIR y DICOM Web; permitiendo el intercambio de distintos formatos, como JSON, XML o DICOM, entre plataformas y aplicaciones de manera independiente. Desde la nueva HCU se debe permitir la visualización de las tendencias y curvas registradas durante la monitorización en base a los datos almacenados en la plataforma de monitorización. Esta funcionalidad es clave en ámbitos donde la monitorización continua de pacientes es muy relevante a la hora de valorar el estado de salud del paciente y de su toma de decisión, como son las áreas quirúrgicas, áreas de anestesia y reanimación y áreas de críticos, entre otras (paritorios, ICTUS, cardiología, etc). ## 4.2.2.5 Interoperabilidad con el proyecto del Gestor de Imágenes Médicas Digitales (GIMD/PACS) corporativo de la Comunitat Valenciana La HCU deberá integrarse con el Gestor de Imágenes Médicas Digitales (GIMD/PACS) corporativo de la Comunitat Valenciana, el cual ya se encuentra desplegado y en funcionamiento. Para ello, se requiere la integración con todos los servicios que conforman el anillo de imagen médica digital asociado a GIMD, incluyendo el Visor de Imagen (VNA) y el Repositorio de Informes centralizado. Esta integración permitirá a los usuarios de la HCU acceder a las imágenes médicas y a los informes radiológicos de forma centralizada y eficiente. <!-- image --> La HCU deberá permitir la visualización de las imágenes médicas almacenadas en el PACS. Las imágenes médicas se mostrarán en la historia clínica del paciente, asociadas a los episodios asistenciales correspondientes, permitiendo una visión integral de la información. El acceso a las imágenes deberá ser fluido y eficiente, con tiempos de carga rápidos, incluso para imágenes de gran tamaño. La HCU deberá acceder al informe radiológico centralizado que se genera y almacena en el PACS, evitando la duplicidad de información y garantizando la consistencia de los datos. El informe radiológico se mostrará en la historia clínica del paciente, asociado al episodio asistencial y a las imágenes correspondientes. La integración se centrará en la consulta de imágenes e informes desde la HCU. No se requiere que la HCU pueda modificar o añadir información al PACS. ## 4.2.2.6 Interoperabilidad con el resto de los sistemas de la Conselleria de Sanitat El adjudicatario asumirá todas las integraciones actualmente identificadas, las derivadas de las necesidades de evolución de los sistemas, de la implantación de otras aplicaciones, de la HCU de la Conselleria de Sanitat, de componentes corporativos de la Conselleria de Sanitat, aparatos diagnósticos y de electromedicina, y del cumplimiento con las normas y criterios que a este respecto sean definidos por SDGTICS. Se contemplan también los servicios necesarios para la fase de análisis de procesos y definición funcional, así como la consultoría que fuese necesaria En el Anexo III -Mapa aplicaciones de la Conselleria y APIS de integración se detalla el mapa de sistemas actual de la Conselleria de Sanitat con los que la nueva HCU deberá interoperar siguiendo el modelo de APIs indicado en el mismo Anexo. En el caso de no estar conectado alguno de estos sistemas al repositorio, en el momento de la implantación de la HCU, se realizará la integración punto a punto a través de un motor de integración centralizado o departamental según la naturaleza de la integración, y con los estándares básicos de mensajería e intercambio (HL7 versión 2.5 o superior). El mapa de sistemas recoge por bloque funcional la relación de sistemas que se encuentran implantados actualmente, bien de forma corporativa o departamental (por hospital). Se exige la, integración con cada uno de los sistemas que hay en la lista. El adjudicatario asumirá los servicios de integraciones con otros sistemas inicialmente no identificados o que sea preciso integrar en aras de tener y completar una visión única de la Historia Clínica de los pacientes. En esta línea se engloban también los sistemas asociados a las pruebas funcionales. En la siguiente tabla se listan aquellos servicios más representativos que disponen de equipamiento y sistemas de información que generan informes de resultados y que se deberán vincular a la HCU para todos los servicios y sistemas que realicen pruebas funcionales. Para su vinculación, el adjudicatario deberá garantizar la integración con todos los sistemas asociados a pruebas funcionales existentes y futuros, garantizando la identificación unívoca del paciente bien a través de gestión de listas de trabajo o gestión y envío de datos demográficos. En el modelo de interoperabilidad que cada licitador detallará se debe explicar cómo se pretende abordar estos sistemas, si bien algunas pruebas como por ejemplo los electrocardiogramas, pruebas de esfuerzo, holters o equipamiento hemodinámico para la monitorización de signos vitales la HCU se integrará con la plataforma descrita anteriormente para esta finalidad: Servicio Prueba/Equipamiento En caso de necesidad de programación de nuevos servicios, mensajería o cualquier elemento necesario para la integración completa y automática con los sistemas de información de la Conselleria de Sanidad y plataformas de integración utilizadas en la Conselleria de Sanidad, el coste de esta integración/desarrollo irá a cargo de la empresa adjudicataria, así como cualquier tipo de licencia y hardware adicional si fuera necesario para alcanzar este objetivo, siempre conforme a las especificaciones marcadas por el Comité de Implantación. <!-- image --> | Cardiología | Bioimpedancia, Ecocardiografía, Electrocardiograma, Estudio Electrofisiológico, Ergoespirometría, Holter-ECG, Holter-TA, Mesa Basculante, Test de Flecainida, Prueba de esfuerzo, Hemodinámica, Electrofisiología cardiaca | |----------------------|----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Hemodinámica | Coronariografia, Cateterismo Derecho, Cate. Derecho Test Vasoreactividad, Angioplastia Coronaria, Cierre FOP, Cierre CIA, Cierre Orejuela Izquierda, TAVI, Cierre Fuga Periprotesica, Valvuloplastia | | Medicina Digestiva | Endoscopias y Biopsias, Manometría Esofágica, PHMetría Esofágica | | Neumología | Broncoscopia, Función Pulmonar, Polisomnografía, Pletismografía, Espirometrías, Espirografía forzada, Poligrafía respiratoria,P. de difusión pulmonar, Volúmenes pulmonares, Cicloergoespirometría, P. de provocación con metacolina, Gasometría arterial, Presiones Respiratorias Estáticas, Broncodilatación tras Espirometría Basal, Medición Óxido Nítrico, Auto CPAP, Provocación con Manitol, Volúmenes + PBD, Test de Marcha GMWT, P. Difución Pulmonar + PBD | | Neurología | Neurosonología, Polisomnografía | | Neurofisiología | Potenciales Evocados-PE, Monitorización Intraoperatoria-MIO, Electroencefalografía-EEG, Electromiografía-EMG, PSG nocturna, Poligrafía Cardiorespiratoria, Test de latencias múltiples (MSLT),PSG nocturna con monitorización presi, PSG con ajuste de CPAP, CPAP (Presión Positiva Continua en la Vía Aérea) | | Oftalmología | Biometría, Campimetría, OCT Heidelberg, Topografía, Gazelab, Retinografía, Láser Argón, Láser Nd-Yag, Angiografía, Paquimetría, Contaje Células Endoteliales, Campos visuales, Inyección Intravitrea | | Otorrinolaringología | Audiometría, Rinomanometria, Timpanometría, Polisomnografía, VHIT, VNG, Fibrolaringoscopia flexible, Audiometría tonal liminar, Audiometría infantil, Audiometría verbal, Impedanciometría-ORL, Audiometría Tonal con Ayuda, Audiometría Verbal con Ayuda | | Pediatría | Bioimpedanciometria, Prueba Hidrogeno Espirado, Test del sudor, Espirometría pediátrica, Prueba broncodilatadora, Oxido Nitrico Exalado (Niox-Mino), Ecocardio. (P.P.), Otoemisiones,Inmunocap Rapid Children,Inmunocap Rapid Adult, Sedación Pediátrica, Potenciales Auditivos Automáticos, Tira Reactiva Orina, Estrepto-Test, Pruebas Cutáneas Inhalantes Pediatría, Pruebas Cutáneas Alimentos Pediatría, Pruebas Cutáneas Medicamentos Pediatría Pruebas Epicutáneas Pediatría, Prueba Provocación Alimentos Pediatría, Prueba Provocación Medicamentos Pediatría, Test Provocación Nasal Pediatría | | Urología | Estudio Urodinámico, Flujometría, Flujometría simple, Urodinámica, Urodinámica Infantil, Urodinámica con Pesario, Medición de Residuo tras Flujometría, Flujometría + EMG, Litotricia, Dilatación Uretral, Mitomicina C, Cystistat, Otras Instilaciones | | Rehabilitación | Fisioterapia en grupo, Fisioterapia Combinada, Fisioterapia linfedema, Fisioterapia suelo pélvico, Fisioterapia | <!-- image --> | | musculoesquelética, Rehabilitación cardíaca, Estimulación Precoz, Escuela de hombro, Escuela de columna | |------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Dermatología | Terapia Fotodinámica | | Nefrología | Revisión FAV | | Unidad del Dolor | Epidural Lumbar, Paravertebral torácico, Paravertebral Lumbar, Infiltración Nervio Periférico, Infiltración Punto Gatillo, Infiltra. Tox. Botulinica Punto Gatillo, Infiltración Art. Hombro Con Corticoide, Infiltración Art. Hombro A. Hialurónico, Infiltración Art. Rodilla Con Corticoide, Infiltración Articular Cadera Corticoide, Infiltración Art. Cadera A. Hialurónico, Infiltración Sacroilíaca, Relleno Bomba Intrafecal | | Hematología | Aspirado, Aspirado+Biopsia, Sangria | | Alergia | Pruebas cutáneas inhalantes, Pruebas cutáneas alimentos, Pruebas cutáneas medicamentos, Pruebas epicutáneas ,Test provocación con alimentos, Test de provocación con medicamentos, Pruebas cutáneas con hyminópteros, Pruebas urticaria, Fenospirometria- alergia | | Endoscopia | Endoscopia digestiva, Endoscopias Ginecológicas, Endoscopias Neumológicas, Endoscopias Urológicas | En el anexo también se ha indicado una serie de sistemas cuya integración estará supeditada a que la solución de HCU ofertada tenga un módulo o ámbito de cobertura funcional que iguale al sistema que se integra, en cuyo caso dicha integración quedará sujeta a decisión del Comité de Implantación. ## 4.2.3 Estándares de compatibilidad A continuación, se detallan una serie de requisitos generales que forman parte del modelo de interoperabilidad previsto de la Conselleria de Sanitat y que deberá cumplir la solución ofertada. ## 4.2.3.1 Interoperabilidad técnica Protocolos, estándares, tecnologías que debe incorporar la solución de HCU: - Estándares básicos de mensajería e intercambio (HL7 versión 2.5 o superior), CDA para representar documentos clínicos de cualquier tipo. - Utilización de Estándares básicos de información gráfica (DICOM 3.0). - Utilización de Frameworks IHE. - FHIR versión R4 o superiores. - Utilización de conectores o servicios web. - Protocolos de transporte estándares de mercado. - Soporte de intercambio de información bajo XML, JSON - Tecnología REST. Soporte de la API RestFul del servidor FHIR utilizando las operaciones CRUD de los recursos y opciones de búsqueda FHIR. ## 4.2.3.2 Interoperabilidad sintáctica La solución deberá soportar los siguientes formatos para el intercambio de información: - XML - JSON ## 4.2.3.3 Interoperabilidad semántica A nivel de interoperabilidad semántica y terminología clínica, la Conselleria de Sanitad dispone de un servidor de terminologías con el que la solución deberá integrarse: - Ontology Server, componente de Onesait HealthCare de Minsait, es un servidor de terminologías FHIR® que implementa los diferentes recursos implicados según el estándar y que además se adecua al 'Terminology Service Capability Statement' (https://www.hl7.org/fhir/terminology-module.html). Este servidor de terminología gestionará los catálogos estándar, catálogos de los Recursos FHIR, maestros de HCU y los mapeos necesarios entre catálogos propios y estándares. La interoperabilidad semántica es la que tiene impacto directo y visible en el trabajo de los profesionales sanitarios, y en los ciudadanos, ya que es la que permite incorporar la información intercambiada y usarla como propia. Es necesario abordar dentro del periodo de vigencia de este contrato, las necesidades de interoperabilidad semántica que surjan desde la Conselleria de Sanitat. Se exigirá que la solución de HCU esté preparada para la utilización de los siguientes estándares semánticos (así como catálogos de terminologías estándares de características similares): - SNOMED CT (Systematized Nomenclanture of Medicine - Clinical Terms) - LOINC (Logical Observation Identifiers Names and Codes) - NANDA (Diagnósticos enfermería), NIC (Clasificación de Intervenciones de Enfermería) y NOC (Clasificación de Resultados de Enfermería) - CIAP-2 (Clasificación Internacional de Atención Primaria versión 2) - CIE-9 -MC (Clasificación Internacional de Enfermedades 9ª revisión, Modificación Clínica) - CIE-10-ES (Clasificación Internacional de Enfermedades 10ª revisión, Modificación Clínica. Diagnósticos) - CIE-10-PCS (Clasificación Internacional de Enfermedades 10ª revisión, Sistema de Clasificación de Procedimientos) - CIE-11 (Clasificación Internacional de Enfermedades 11ª revisión) - CIE-O-3 (Clasificación Internacional de Enfermedades para Oncología, 3ª revisión) - HPO (Human Phenotype Ontology) - ORPHA (Información sobre enfermedades raras y medicamentos huérfanos) - OMIM (Online Mendelian Inheritance in Man) - ATC (Anatomical, Therapeutic, Chemical Classification System) - Catálogo SERAM (Sociedad Española de Radiología Médica) - Catálogo SEMNIM (Sociedad Española de Medicina Nuclear e Imagen Molecular) <!-- image --> - Catálogo SIVAIN (Sistema de Información en Vacunaciones e Inmunizaciones) - Nomenclátor de Prescripción. Medicamentos y Valuesets - Nomenclátor de Facturación - BIFIMED (Buscador de la Información sobre la situación de financiación de medicamentos) - Master Translation Catalog Proyecto EU Patient Summary - PROApp (Catálogos empleados en el proyecto PROApp) Del mismo modo, HCU debe estar preparado para la utilización de catálogos propios definidos a nivel corporativo por la CS (Catálogo de pruebas diagnóstico-terapéuticas de Medicina Digestiva, Catálogo de pruebas diagnóstico-terapéuticas de Urología, Motivo de rechazo de una propuesta/interconsulta, …) y de los catálogos disponibles en el catálogo de recursos corporativos (estructura organizativa, estructura geográfica, servicios, … ). ## 4.2.3.4 Interoperabilidad organizacional En el Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional de Interoperabilidad en el ámbito de la Administración Electrónica, se define la interoperabilidad organizativa como un componente clave de la misma, dedicado a la capacidad de las entidades para cooperar y coordinar sus procesos, con el fin de alcanzar objetivos comunes de manera eficaz y eficiente. A continuación, se hace referencia a un conjunto de requisitos para asegurar esta interoperabilidad organizacional. - Gobernanza centralizada: Se deberá establecer una estructura de gobernanza clara para la gestión de la HCU a nivel centralizado, definiendo las responsabilidades, roles y mecanismos de coordinación para la toma de decisiones que involucren a todos los centros involucrados. Se deberá especificar la composición y funciones del comité de gobierno. - Comunicación y notificación centralizada: Se deberá implementar un sistema de comunicación y notificación centralizado que permita la difusión de información relevante a todos los centros involucrados, incluyendo alertas, avisos y notificaciones de eventos. Se deberá especificar los canales de comunicación y los tipos de notificaciones soportadas, así como los grupos receptores de las misma. - Flujos de trabajo inter-hospitalarios: Se detallará de forma centralizada los flujos de trabajo inter-hospitalarios soportados. La HCU debe soportar flujos de trabajo que involucren a múltiples hospitales, permitiendo la coordinación de la atención al paciente entre diferentes centros, incluyendo la derivación de pacientes, el acceso a la información clínica compartida y la gestión de recursos. Para ello se tendrá en consideración: - o Estandarización de acuerdos: Se deberá establecer un modelo estandarizado de acuerdo de intercambio de información entre los hospitales, que defina las condiciones de acceso y uso de los datos compartidos, incluyendo las responsabilidades, los mecanismos de control y las medidas de seguridad. Se deberá proporcionar una plantilla de acuerdo adaptable a las necesidades específicas. - o Centralización de consentimientos: La HCU deberá gestionar de forma centralizada los consentimientos de los pacientes para el acceso y uso de su información por parte de los diferentes hospitales. Se deberá garantizar la accesibilidad y actualización de los consentimientos en tiempo real para todos los centros. - o Acceso unificado a la información: La HCU deberá proporcionar un punto de acceso unificado a la información clínica de los pacientes, permitiendo a los profesionales <!-- image --> <!-- image --> sanitarios acceder a la historia clínica completa del paciente, independientemente del centro donde haya sido atendido. - o Herramientas de colaboración multi-centro: La HCU deberá integrar herramientas que faciliten la colaboración entre profesionales de diferentes hospitales, como sistemas de videoconferencia, mensajería instantánea y compartición de documentos, adaptadas al contexto de una red de hospitales. - Monitorización y evaluación global: La HCU deberá permitir la monitorización y evaluación de los resultados de la colaboración entre los hospitales, proporcionando indicadores y reportes sobre la eficiencia y efectividad de los procesos inter-hospitalarios. ## 4.2.3.5 Seguridad Aunque en el apartado 10 de este documento se detalla en profundidad todos los aspectos relativos a la privacidad y protección de datos y aspectos globales de seguridad, en este subapartado se hace mención de las características mínimas exigidas en lo relativo a la interoperabilidad y la seguridad: - Securización por el servidor de seguridad de la plataforma basado en OAuth 2 y OpenID Connect. - Implementación de mecanismos de seguridad, autenticación y autorización basada en OAuth2, con capacidad para integrarse con otros sistemas de identificación a través de SAML2 y JWT. ## 4.2.4 Otros requerimientos ## 4.2.4.1 Plataforma lanzadera de aplicaciones externas La HCU deberá incorporar una plataforma lanzadera de aplicaciones externas que permita a los usuarios acceder y ejecutar aplicaciones de terceros desde la propia interfaz de la HCU. La plataforma deberá integrarse con el sistema de autenticación de la HCU y soportar estándares de interoperabilidad como OAuth2 y OpenID Connect. Se deberá poder personalizar el acceso a las aplicaciones en función del rol y las necesidades de cada usuario. Funcionalidades requeridas a la plataforma: - La plataforma deberá incluir un catálogo de aplicaciones disponibles, con descripciones y categorías. - Se deberá poder añadir, eliminar y actualizar las aplicaciones disponibles en la plataforma. - La plataforma deberá exponer APIs para que las aplicaciones externas puedan integrarse con la HCU y acceder a sus datos y funcionalidades. - Se deberá registrar la actividad de los usuarios en la plataforma lanzadera para fines de auditoría. - Se deberán implementar mecanismos de control de acceso para garantizar que solo los usuarios autorizados puedan acceder a las aplicaciones. - La plataforma deberá integrarse con el sistema de autenticación de la HCU y soportar estándares de interoperabilidad. - Se deberá poder personalizar el acceso a las aplicaciones en función del rol, perfil profesional, centro, servicio, sección, navegador, método (GET, POST), etc… ## 4.2.4.2 Integración con Nébula visor externo No se contempla la migración del histórico de los diferentes sistemas a la nueva HCU, toda esta información se tendrá disponible y accesible a través de la plataforma/repositorio FHIR® y según los modelos de interoperabilidad descritos en apartados anteriores. Las entidades contempladas a diseñar como recursos FHIR en el expediente SDA-TIC/3-21CC son las siguientes: - Pacientes - Profesionales de salud - Organización - Contacto - Episodio - Citas - Alergias e intolerancias - Lista de problemas - Procedimientos - Resultados pruebas RX - Medicación - Vacunación - Informes de alta y seguimiento - Signos vitales Este primer volcado de datos a la plataforma/repositorio FHIR® se le irán sumando la ingesta de datos del resto de sistemas y aplicaciones de la Conselleria que se tratarán en contratos distintos al expediente anterior y al objeto de esta licitación. En la actualidad, en aras de resolver y facilitar los problemas derivados de la fragmentación y dispersión de los datos en los diferentes sistemas de información, la CS ha puesto al servicio de sus profesionales un conjunto de herramientas informáticas para facilitar, agregar y visualizar desde un único punto la información de sus diferentes sistemas de información. Como parte de este conjunto de herramientas, el sistema de información Nébula/Sirion es esencial. Nébula es una aplicación que tiene como objetivo ofrecer en una única interfaz de usuario información agregada de los principales sistemas de información: Orion-Clinic y SIA, si bien también dispone de información de los HIS (IRIS e HIGIA), Orion-Ris, PATWIN, Gestlab, Mizar y Papiro, así como información procedente de departamentos con sistemas de información propios. Para ello utiliza los servicios que ofrece Sirion, una aplicación centralizada que interconecta las diferentes instancias de Nébula entre sí y éstas a su vez con SIP, SIA, GAIA, HSE, SIVIO, SIV y Marca de Cronicidad. El sistema conformado por las aplicaciones Nébula y Sirion será referido a partir de ahora como el sistema de información Nébula/Sirion. Nébula ya está en 25 hospitales, los 17 hospitales de agudos, los 5 HACLES y en 3 exóticos (sin OC ni HIS corporativo). Teniendo en cuenta el expediente SDA-TIC/3-21CC y otros que vayan alimentando plataforma/repositorio FHIR®, se requiere que la nueva HCU deberá interoperar con Nébula/Sirion en los siguientes escenarios: - Acceso al histórico de información que no haya sido migrada a la plataforma/repositorio FHIR. Es decir, acceso desde la HCU a Nébula/Sirion, como ya se está haciendo con Orion-Clinic u Orion-RIS. Caso de uso: - o Hospital con la nueva HCU desplegada que requiera información de otro hospital cuya información no haya sido migrada al repositorio FHIR. <!-- image --> <!-- image --> El acceso a Nébula/Sirion se realizaría vía la plataforma de lanzadera de aplicaciones externas. - Conexión de Nébula/Sirion a la nueva HCU en caso de que no haya integración con el repositorio FHIR. Para este caso, la nueva HCU deberá implementar todos los WS que implementa cualquier Nébula y se podrá integrar los datos recogidos en la nueva HCU y tenerlos accesibles desde cualquier visor Nébula como otro hospital más. Caso de uso: - o Hospital con alguno de los sistemas de información actuales que deba consultar información de uno de los hospitales con la nueva HCU y cuya información no se encuentra volcada al repositorio FHIR. Este escenario se contempla como medida de contingencia requerida en caso de que por tiempos de proyecto no se haya podido interoperar directamente con el repositorio. ## 4.2.4.3 Integración con Plataforma Autonómica de Interoperabilidad de Datos Segura La Plataforma Autonómica de Interoperabilidad de la Generalitat Valenciana (en adelante PAI) es una plataforma de interoperabilidad de servicios horizontales que ofrece la posibilidad de compartir e integrar servicios entre entidades públicas. Está disponible para todas las Consellerias y Organismos dependientes de la Generalitat, así como para las diferentes entidades de la Comunitat Valenciana, a través de la cual podrán ofertar en un catálogo común sus servicios de interés, acceder a la totalidad de los servicios ofertados, y promover la identificación y generación de nuevos servicios dentro de dicho catálogo. La Plataforma ofrece un entorno seguro donde publicar los servicios de las administraciones, permitiendo la integración, a la vez que ofrece un entorno de ejecución, una pasarela entre administraciones, y un entorno securizado y monitorizable. Facilitando, en definitiva, a las aplicaciones que estén autorizadas, la realización de las consultas necesarias para verificar los datos de un ciudadano que ha iniciado un trámite con la administración, liberándole de la obligación de aportar dicha documentación. Actualmente, la Plataforma Autonómica de Interoperabilidad de Datos Segura de la DGTIC se está utilizando para el envío de SMS de recordatorio a los ciudadanos (recordatorio de citas programadas en consultas externas, recordatorio intervenciones quirúrgicas, recordatorio seguimiento pacientes crónicos, etc.). La HCU deberá interoperar con PAI para que desde ésta y con la información requerida y proporcionada desde HCU, se generen los SMS. A la vez que deberá, HCU, estar preparada para recibir la mensajería de vuelta que pueda generar un paciente, por ejemplo: respuesta ante el recordatorio de cita en CEX, con una respuesta de cancelación y reprogramación de cita. La HCU deberá contemplar posibles nuevos usos de la PAI, tanto para consumo de servicios publicados por la DGTIC, como para la publicación de nuevos servicios sanitarios, que otras AAPP o ministerio demandan. En caso de que estos se implementen, la HCU deberá interoperar con ellos. ## 4.3 Configuración y gobierno de la solución El proveedor deberá colaborar en la definición e implementación de políticas y procedimientos para el uso y la gestión de la HCU, incluyendo la gestión de acceso, la seguridad de la información, la privacidad del paciente y la continuidad del negocio. Así como en la descripción e implementación de los procedimientos de adaptación y parametrización de la solución a los circuitos preestablecidos en los centros objeto de este contrato. <!-- image --> Una de las funciones y responsabilidades del Comité de Seguimiento e Implantación será la del gobierno de la nueva HCU, en aras que pueda marcar unas directrices globales, supervisar su implementación, el uso y la evolución de la solución. Para la configuración y gobierno de la solución se exige: - Un gobierno centralizado de la solución, de forma que todos los centros operen según las políticas y procedimientos establecidos. - Mecanismos de adaptabilidad que permitan configurar la solución, con autonomía y desde la propia solución, a las necesidades de las diferentes tipologías de centros, ámbitos, flujos de trabajo, profesionales/perfiles. - Registros de auditoría y trazabilidad tanto de la configuración como de la operativa en la solución. En detalle: - La nueva HCU deberá proporcionar herramientas de administración que permitan la gestión de usuarios, la configuración del sistema, la monitorización del rendimiento y la generación de informes. - La nueva HCU ofrezca una amplia gama de opciones de configuración para adaptarse a los procesos y flujos de trabajo, las preferencias de los usuarios y los requisitos específicos de cada departamento o servicio. - La nueva HCU contemplará opciones de configuración de preferencias de los usuarios a nivel de interfaz. - La nueva HCU deberá permitir la personalización de la interfaz de usuario, los formularios clínicos, las plantillas de documentos y resultados, las alertas y los informes. - La nueva HCU deberá contar con un sistema de gestión de roles y permisos granular que permita definir el acceso a la información y las funcionalidades según el perfil de cada usuario (personal facultativo, personal de enfermería, administrativos, etc.). Así como vincular varios perfiles a un mismo usuario. - La HCU deberá permitir el acceso a usuarios externos, como investigadores, personal de centros concertados o residencias, pero con un control de acceso granular que garantice la seguridad y la privacidad de los datos de los pacientes. El control de acceso de estos usuarios externos estará basado en pacientes asignados. Para los usuarios externos sin una relación asistencial directa con el paciente, el acceso a la HCU se limitará a la historia clínica de los pacientes que tengan asignados. Esto significa que: - o Investigadores: Solo podrán acceder a las historias clínicas de los pacientes que participan en el estudio de investigación autorizado. - o Personal de centros concertados: Solo podrán acceder a las historias clínicas de los pacientes que son derivados al centro concertado para recibir atención sanitaria. - o Residencias: Solo podrán acceder a las historias clínicas de los pacientes que están bajo su cuidado y supervisión. - La nueva HCU deberá contar con un sistema de gestión de cambios que permita registrar, evaluar, autorizar e implementar modificaciones en la configuración del sistema. - La nueva HCU deberá registrar todas las acciones realizadas en el sistema, incluyendo la configuración, el acceso a los datos y las modificaciones en la información del paciente. - Se deberá proporcionar herramientas de auditoría que permitan la revisión de los registros y la generación de informes de auditoría. - La HCU deberá implementar controles de trazabilidad que registren todos los accesos a la historia clínica de los pacientes, incluyendo la identificación del usuario, la fecha y hora del acceso, los datos consultados y la justificación del acceso. Se deberán implementar <!-- image --> mecanismos de control automático que verifiquen la relación asistencial del usuario con el paciente y soliciten una justificación adicional si no existe dicha relación. El personal responsable de la protección de datos deberá supervisar los accesos y verificar la adecuación de las justificaciones - La nueva HCU permitirá la configuración de flujos de trabajo de forma autónoma por parte de la CS. - La nueva HCU permitirá la configuración de reglas y alertas. - La nueva HCU permitirá la generación dinámica de formularios e informes - El proveedor deberá colaborar en la elaboración e implementación de políticas y procedimientos para el uso y la gestión de la HCU, incluyendo la gestión de acceso, la seguridad de la información, la privacidad del paciente y la continuidad del negocio. Se proporcionará al adjudicatario todos los elementos, ítems y catálogos requeridos para realizar la carga inicial y configuración del sistema. ## 4.4 Migración de datos La migración de datos es un proceso crítico para el éxito de la implantación de la nueva Historia Clínica Única. El proveedor adjudicatario deberá garantizar la integridad, precisión y disponibilidad de la información migrada desde los sistemas de información actuales, asegurando que la HCU sea completamente operativa desde el día del arranque, sin pérdida de información ni interrupción de la atención al paciente. Para ello, se han identificado una serie de variables e ítems que serán los mínimos e imprescindibles a tener migrados en el momento del arranque en cada uno de los hospitales. En el Anexo IV -Datos a migrar se ha detallado cada uno de estos ítems. El adjudicatario deberá asumir los trabajos de migración, teniendo en cuenta la variabilidad de los sistemas y niveles de despliegue de una misma solución, sin menoscabo de llevar a cabo cualquier tipo de migra ion que exija la solución ofertada en aras de asegurar continuidad asistencial, fácil gestión del cambio y el éxito de la implantación en cada centro. No se contempla la migración del histórico de los diferentes sistemas a la nueva HCU, toda esta información se tendrá disponible y accesible a través de la plataforma/repositorio FHIR y en los modelos de interoperabilidad descritos en apartados anteriores. ## 5 REQUISITOS TÉCNICOS En este apartado se establece los requisitos mínimos relativos a las características técnicas de la HCU. Estos requisitos no serán objeto de valoración como criterio de valoración. ## 5.1 Requisitos técnicos generales y arquitectura Desde el punto de vista de arquitectura y requisitos técnicos generales la solución deberá cumplir: - La solución ofertada debe tener carácter Multicentro, entendiendo como tal que permita la gestión integrada de todos los centros asistenciales de la Comunidad desde una única instancia centralizada. - El sistema debe mantener enlazados los posibles identificadores de cada paciente en cada centro. - La solución debe disponer de una tipología de instalación centralizada, de forma que todos los recursos críticos y componentes se concentren en un único punto. - Debe ser una aplicación web basada en HTML5 que no requiera instalar software adicional (excepto plugins o complementos puntuales que fueran ser necesarios para el propio navegador) o aplicaciones locales en los dispositivos de los usuarios para acceder a la solución. Se podrán realizar pruebas de concepto para evaluar las características técnicas, el rendimiento y la usabilidad de la aplicación en un entorno real; simulando el acceso de un gran número de usuarios concurrentes. - La solución debe ser responsive, adaptándose a diferentes tamaños de pantalla y dispositivos. - La aplicación tiene que soportar tanto protocolo https como http. - La solución debe estar basada mayoritariamente en componentes Open Source. - La aplicación debe tener un enfoque multicapa donde las funcionalidades estén divididas en distintas capas lógicas. La arquitectura presentada debe contener tres capas bien diferenciadas: la capa de persistencia o acceso a base de datos, la capa de lógica de negocio, y el interfaz de usuario final que será de tipo web, tanto para puestos de trabajo fijos como en movilidad. - La solución expondrá APIs abiertas basadas en estándares (REST, FHIR) para facilitar la integración con otros sistemas y el desarrollo de nuevas aplicaciones. - La aplicación debe ser modular de modo que se estructure en componentes o módulos independientes que puedan ser desarrollados, actualizados y mantenidos de forma separada. - La arquitectura debe estar basada en microservicios, de modo que si un servicio falla, el resto del sistema pueda seguir operando sin verse afectado. - La aplicación deberá ser desacoplada de forma que los componentes principales estén diseñados para operar de manera independiente entre sí. - La solución se deberá desplegar, como mínimo, en los siguientes entornos: formación, preproducción y producción. - La solución debe permitir escalabilidad vertical (hardware): capacidad de almacenamiento, comunicaciones y cómputo para cada servidor; ya físico o virtual. - La solución debe permitir escalabilidad horizontal (servidores): número de servidores trabajando conjuntamente; ya físicos o virtuales. - La solución debe garantizar un alto rendimiento (objetivable) y una altísima disponibilidad del servicio. Los licitadores deberán detallar en su oferta qué mecanismos de redundancia y tolerancia a fallos se implementarán para el proyecto en aras de poder garantizar una disponibilidad mínima del sistema del 99,99%: - o A nivel de redundancia: se exige redundancia activa que contemple la interconexión de un mínimo de dos centros de datos independientes y resilientes entre sí, compatibles con redundancia geográfica que contemple poder mitigar riesgos <!-- image --> <!-- image --> medioambientales, como inundaciones, condiciones climáticas extremas y actividad sísmica y que por tanto el rango sea un mínimo de 50km, rango que debe permitir tener réplica asíncrona entre los centros de datos. Con conexión a puntos neutros (IXP) distintos y con los anchos de banda de acceso e interconexión necesarios y suficientes para garantizar el alto rendimiento demandado para la solución sin degradación apreciable hasta el mínimo de usuarios concurrentes contemplados en los requisitos iniciales (ver Anexo II - Estructura organizativa y volumetría hospitales) , más un 20% de incremento. - o A nivel de balanceo de carga: se exige que la solución garantice los escalados horizontal (número de servidores por centro de datos) y vertical (dimensionamiento de los servidores) necesarios y suficientes para atender adecuadamente la demanda de sesiones de usuario y las exigencias de procesamiento de éstas, garantizando en todo momento los tiempos de respuesta exigidos. Será responsabilidad del adjudicatario habilitar los balanceadores necesarios en cada centro de datos para facilitar la gestión dinámica y fluida del tráfico de red y las solicitudes de servicio de las instancias de usuario, su óptima distribución entre los distintos servidores disponibles, la mejor experiencia para el usuario final, la garantía de alta disponibilidad para el sistema, su escalabilidad automática, la optimización de los recursos, la mejora del rendimiento general y la tolerancia a fallos. - o A nivel de tolerancia a fallos/disponibilidad: la opción preferente de la Conselleria de Sanitat es disponer de una infraestructura tolerante a fallos real en cada centro de datos más que una infraestructura de alta disponibilidad, para, así, evitar, dentro de lo posible, la necesidad de conmutación entre equipos. El objetivo es evitar los tiempos de inactividad, no limitarlos. En cualquier caso, no será un criterio excluyente el optar por un modelo u otro, según las características propias de las soluciones de los licitadores; pero sí a decidir. Sí que se requiere que la conmutación entre equipos sea automática. - Se exige que la solución (ya desde la aplicación ordinaria, ya desde un visor alternativo de contingencia) permita el acceso a determinados datos y funcionalidades incluso cuando no haya conexión a la red informática, sin necesidad de sincronización de datos cuando se recupere la conexión. Para ello se solicitan las siguientes funcionalidades y casos de uso: - o Acceso offline a la HCU: Los usuarios (ya desde la aplicación ordinaria, ya desde un visor de contingencia) deberían poder acceder a la información clínica relevante de los pacientes, incluyendo historial médico, medicamentos, alergias, resultados de pruebas y otros datos esenciales, incluso sin conexión a la red informática (modo aislado/autónomo). En caso de aislamiento (a nivel de centro o de puesto de trabajo), la información y funcionalidades mínimas disponibles en modo lectura en todos y cada uno de los puestos de trabajo de tipo 'emergencia' o pertenecientes, por su particular identidad móvil, a las UHD (Unidades Hospitalarias Domiciliarias), serán las siguientes: - Consulta de pacientes y listas de trabajo en cada uno de los siguientes ámbitos funcionales: urgencias, hospitalización, hospital de día, hospitalización a domicilio, partos en curso y listad de neonatos sanos. - Consulta del listado de interconsultas de pacientes ingresados en activo o en seguimiento. - Consulta de citas programadas. - Consulta parte quirúrgicos programados. - Consulta extracciones de laboratorio. - Listados de prescripción de medicamentos por servicios y unidades de enfermería. - Generación listados de farmacia para la validación farmacéutica y dispensación. - Listados de administración de medicación por unidad de enfermería. - Visualización de pruebas diagnósticas solicitadas. - Generación de informes y escalas de valoración. - Planes y actividad programada de enfermería. - Antecedentes, alergias, vacunas. - Acceso retrospectivo de, al menos, 7 días a la Historia Clínica de los pacientes con episodio activo en el momento de la parada. Todas ellas en modo offline. - o Infraestructura requerida: El adjudicatario dimensionará y proporcionará la infraestructura necesaria y suficiente requerida para la consulta de los datos y la utilización de las funcionalidades mínimas con un rendimiento óptimo en caso de emergencia/aislamiento. Para esas situaciones; se aceptan como soluciones válidas: servidores offline hacia WAN con bases de datos replicadas a nivel de LAN, puestos de trabajo PC de contingencia (mínimo, 1 por unidad de enfermería y/o servicio clínico, o una solución mixta que contemple ambos modelos; más, en cualquier caso, todos los puestos de trabajo móviles de las Unidades Hospitalarias Domiciliarias). Los servidores y puestos de trabajo referidos deberán dimensionarse adecuadamente para dicho propósito y garantizar la cobertura funcional necesaria y suficiente durante los mencionados períodos de emergencia/aislamiento. - o Copia local sincronizada: Para posibilitar el acceso offline, se exige que la solución implemente una copia local (a nivel de centro, de puesto de trabajo de emergencia, o ambos; incluyendo siempre todos los puestos de trabajo móviles de las UHD) de los datos en cada uno de los hospitales o centros usuarios de la HCU. Esta copia local se accederá en modo lectura y no se requerirá la implementación de mecanismos de sincronismo posteriores, pues no habrá lugar a tener herramientas de escritura durante el período de desconexión. - o Activación en caso de pérdida de servicio: En caso de pérdida de conexión a la red o aislamiento del centro o puestos de trabajo (siempre objetivados desde Servicios Centrales y/o los servicios de Informática de los hospitales y centros usuarios de la HCU), la solución deberá tener acceso inmediato y automático al modo offline y utilizar la copia local de los datos para permitir la continuidad asistencial y atención al paciente. - Notificación al usuario: El sistema deberá notificar al usuario que se ha activado el modo offline y está trabajando con la misma aplicación pero con funcionalidad reducida y una copia local de los datos, o que debe utilizar el visor HCU de emergencia; si fuera ésta la solución alternativa habilitada en el proyecto para casos de aislamiento. - Funcionalidad limitada: Se podrá limitar la funcionalidad de la aplicación (o visor de contingencia) en modo offline a las tareas clínicas básicas (al menos las referidas anteriormente) y al acceso a la información esencial del paciente. - Con una cadencia anual, se deberá hacer un simulacro (programado) de contingencia para verificar el funcionamiento y uso del sistema offline, así como impartir la formación y trasladar adecuadamente a los usuarios implicados la información e instrucciones pertinentes sobre cómo proceder en caso necesario. - o Consideraciones adicionales. - Seguridad de la copia local: Se deberán implementar medidas de seguridad para proteger la copia local de los datos, como el cifrado y el control de acceso. - Rendimiento: El acceso a los datos y la funcionalidad de la aplicación en modo offline deberán ser fluidos y eficientes. <!-- image --> <!-- image --> - Actualización de la copia local: Se deberá establecer un mecanismo para actualizar la copia local de la aplicación y los datos cuando se disponga de nuevas versiones. ## 5.2 Infraestructura y modelo de despliegue Se busca un modelo de despliegue flexible y escalable que permita a la Conselleria de Sanitat aprovechar las ventajas de una nube soberana y privada con línea dedicada. Se exige una solución basada en SaaS (software como servicio), donde el proveedor adjudicatario se responsabilice de la provisión, gestión y dimensionamiento de la infraestructura subyacente (servidores, almacenamiento, red) para asegurar un rendimiento y operación óptimos. El dimensionamiento se basará en los requisitos de este Pliego de Prescripciones Técnicas, la experiencia del proveedor en otras implantaciones similares (tipología, dimensión, complejidad, criticidad, etc.) y las mejores prácticas del sector. La solución SaaS exigida en nube privada deberá cumplir con los siguientes requisitos a efectos de diseño, implementación y despliegue: - Soberanía de datos: La solución y los datos deberán residir en territorio español y estar sujetos a la legislación española, asegurando el cumplimiento de las normativas de protección de datos y evitando el acceso no autorizado por parte de terceros países. Es necesario que se pueda asegurar tanto el centro de datos como la región donde se desplieguen los servicios y datos; garantizando que los servicios no serán desplazados a otros centros de datos, para mover las cargas en caso de ser necesario. Se deberá garantizar la portabilidad de los datos y la posibilidad de migrar la HCU a otra plataforma en el futuro, sin dependencia del proveedor de la nube soberana. Se deberá proporcionar un plan de salida que detalle los pasos y los procedimientos para la migración de la solución completa a otra plataforma. Así como una estimación de los costes de los servicios requeridos para dicha salida. - El adjudicatario deberá proporcionar la infraestructura necesaria mediante suscripción en la nube que permita como comunicación principal la conexión directa y privada a la misma desde la red informática corporativa de área extensa (WAN) de la Conselleria de Sanitat, a través de la red MPLS MacroLAN que proporciona el proveedor de comunicaciones de la GVA (el equivalente a Microsoft® Azure® ExpressRoute®, Amazon® AWS® DirectConnect®, Google® CloudInterconnect®, Oracle® OCI®FastConnect®), o similares. La conectividad deberá garantizar alto rendimiento (objetivo y generalizado en todos los ámbitos de la solución), ancho de banda suficiente, baja latencia (máximo 50 ms) y máxima seguridad evitando el tráfico público de Internet. Como comunicación secundaria o de backup, el adjudicatario deberá ajustarse a los recursos y mecanismos puestos a disposición del proyecto por la parte contratante (failover a través de Internet mediante tráfico cifrado IPSec / Lan To Lan, o el que se considerare oportuno). - Control de acceso: La Conselleria deberá tener un control total sobre el acceso a los datos y la infraestructura, con la capacidad de definir políticas de acceso y monitorizar la actividad de los usuarios. Si bien, se establece que el adjudicatario del contrato de Historia Clínica Única será el responsable de la gestión integral de la infraestructura, incluyendo la provisión, configuración, monitorización, mantenimiento y soporte de los recursos cloud y demás recursos exigidos o incluidos en su oferta. Será responsabilidad de la Conselleria de Sanitat: - o Definir las políticas de acceso y seguridad: La Conselleria establecerá las políticas de acceso a los datos y la infraestructura, y definirá los requisitos de seguridad y cumplimiento normativo. En todo momento, el Delegado de Protección de Datos (DPD) que designe la Conselleria podrá solicitar y tener acceso a la información y la documentación relacionada con la seguridad y la protección de datos en la nube. <!-- image --> - o El DPD podrá realizar auditorías al proveedor de la nube para verificar el cumplimiento de las medidas de seguridad y la normativa de protección de datos. El resultado de la auditoría se facilitará al adjudicatario para su conocimiento en caso de tener que aplicar acciones mitigadoras o correctoras que, en cualquier caso, se considerarán incluidas como obligaciones contractuales para el adjudicatario. - o Monitorizar la actividad de los usuarios: La Conselleria tendrá acceso a las herramientas de monitorización para supervisar la actividad de los usuarios y el uso de los recursos. - o Aprobar los cambios en la infraestructura: Cualquier cambio significativo en la infraestructura deberá ser aprobado por la Conselleria de Sanitat. - Seguridad : La infraestructura deberá contar con medidas de seguridad robustas para proteger la confidencialidad, integridad y disponibilidad de los datos, incluyendo cifrado, cortafuegos (firewalls), sistemas de detección de intrusos y mecanismos de prevención de pérdida de datos. El detalle de estas medidas de seguridad se describe en el siguiente apartado. - Cumplimiento normativo: La infraestructura y los servicios cloud deberán cumplir con todas las normativas y estándares de seguridad y privacidad aplicables, incluyendo el RGPD (Reglamento General de Protección de Datos), la LOPDGDD (Ley Orgánica de Protección de Datos Personales y garantía de los derechos digitales) y Esquema Nacional de Seguridad (ENS) nivel 'Alto'. - Certificaciones : Se exigirá que el proveedor de la solución y/o de la infraestructura de la nube privada y soberana cuente, al menos, con las siguientes certificaciones de seguridad, calidad y sostenibilidad: ISO 9001, ISO 27001, ISO 27017, ISO 27018, ISO 22301, ISO 14001 y SOC 2. Así como la serie de normas EN 50600 para el diseño, la construcción y la operación de centros de datos (CPD), con un enfoque también centrado en la disponibilidad, la eficiencia energética y la seguridad. - Experiencia : El proveedor de cloud que proponga el adjudicatario deberá tener experiencia demostrada en el despliegue y la gestión de infraestructuras para sistemas de información sanitarios de tipología, dimensión, complejidad y criticidad similares a las exigidas; preferiblemente con experiencia en el despliegue de una Historia Clínica Única en entornos hospitalarios. ## 5.2.1 Responsabilidades del adjudicatario El adjudicatario asumirá las siguientes responsabilidades en la gestión de la infraestructura: - Provisión de recursos: - o Adquirir y aprovisionar los recursos de infraestructura necesarios en la nube, incluyendo servidores virtuales, almacenamiento, redes, servicios de comunicaciones y otros servicios cloud. - o El coste de consumo de datos asociado al despliegue de la infraestructura estará incluido en el precio de la oferta y no se facturará de forma separada. - o Asegurar que los recursos cumplan con los requisitos de rendimiento, escalabilidad y seguridad que garanticen una óptima utilización de la solución. - o Los recursos de infraestructura estarán gestionados por el adjudicatario con personal completamente localizado en territorio español, salvo circunstancias especiales de colapso o emergencia operativa que pudieran precisar recursos técnicos altamente especializados independientemente de su localización geográfica; pero, en cualquier caso, sujetos a las legislaciones española y de la Unión Europea. - o Adicionalmente, se deberá proveer el servicio de firewall de próxima generación (NGFW) en la nube FortiGate-VM® (ya operativa en el ámbito de sistemas de información de la Conselleria de Sanitat) a fin de securizar la infraestructura implantada en la nube y que sea posible su gestión a través de las herramientas de <!-- image --> gestión centralizadas FortiManager® y FortiAnlyser® que ya posee la Conselleria de Sanitat. - Configuración y administración: - o Configurar y administrar la infraestructura, incluyendo la creación de máquinas virtuales, la configuración de redes, la gestión de almacenamiento y la implementación de medidas de seguridad; siempre en estrecha colaboración con los recursos técnicos propios de la Conselleria de Sanitat y/o los propios de las empresas adjudicatarias de cualesquiera otros proyectos en intersección de ámbito operativo con el propio de la HCU. - o Mantener la infraestructura actualizada y optimizada para el correcto funcionamiento de la HCU en el mejor escenario tecnológico posible al amparo de las obligaciones contractuales de las partes. - Monitorización. Teniendo en cuenta que la Conselleria de Sanitat cuenta con herramientas de gestión centralizadas como son FortiManager® y FortiAnlyser®, se detallan una serie de requisitos que buscan complementar y agregar valor a la parte de la monitorización: - o Monitorizar el rendimiento, la disponibilidad y la seguridad de la infraestructura, utilizando herramientas de monitorización y alertas. - o El proveedor deberá proporcionar herramientas para la monitorización del rendimiento, la disponibilidad y la seguridad de la infraestructura, con la capacidad de generar alertas y visualizar métricas clave. - o El proveedor deberá proporcionar herramientas para la gestión y supervisión de todos los elementos (infraestructura, comunicaciones y lógica/funcional de tres capas: presentación, aplicación y datos) más allá de los sistemas de control propios del proveedor de la infraestructura de nube soberana y privada contratada. - o El proveedor deberá configurar alertas para notificar a los servicios centrales competentes de la Conselleria de Sanitat y a cada hospital o centro incorporado al proyecto de HCU, sobre eventos críticos o especialmente relevantes, tales como fallos en los servidores, problemas de rendimiento, deterioro de los servicios de comunicaciones, incidentes de seguridad, u otros. - o Se requiere la capacidad de automatizar tareas de gestión y optimización de la infraestructura, como el aprovisionamiento o reconfiguración de servidores y sistemas de comunicaciones, la gestión de copias de seguridad y la escalabilidad (preferiblemente automática) de los recursos de todo tipo habilitados para el proyecto. - o Reportar a la Conselleria de Sanitat sobre el estado de la infraestructura y cualquier incidencia que se produzca. - o Reportar al Delegado de Protección de Datos (DPD) cualquier brecha de seguridad que afecte a los datos de los pacientes. - o Realizar un plan de respuesta a incidentes junto con el DPD para garantizar que se tomen las medidas adecuadas para mitigar el impacto de las brechas de seguridad. ## · Mantenimiento: - o Realizar las tareas de mantenimiento de la infraestructura, incluyendo la aplicación de actualizaciones, parches de seguridad y otras acciones necesarias para garantizar el óptimo funcionamiento del sistema. - Soporte técnico: - o Proporcionar a la Conselleria el soporte técnico necesario y suficiente para la resolución de incidencias y problemas relacionados con la infraestructura. - Documentación: - o El adjudicatario deberá documentar, y mantener actualizada durante toda la duración del contrato, la configuración de la infraestructura y los procedimientos de mantenimiento. ## 5.3 Red y conectividad ## 5.3.1 Red Corporativa de la Conselleria de Sanidad: Red Arterias La Conselleria de Sanidad dispone de una red corporativa de comunicaciones (Red Arterias) que interconecta todos los centros sanitarios y administrativos en el ámbito de la Comunidad Valenciana y facilita el acceso a la información desde cualquier puesto de trabajo. La red de comunicaciones sanitarias ('Arterias') cuenta con 1.003 nodos conectados. Cada nodo de red alberga uno o más centros, tanto asistenciales como administrativos, dando cobertura a un total de aproximadamente 1.365 centros (hospitales, centros de salud, centros de especialidades, consultorios auxiliares y centros administrativos), de los cuales uno es el nodo troncal del Centro de Informática de la Conselleria de Sanidad y 39 se corresponden con sedes de gran tamaño y CPD propio, la mayoría de ellos hospitales. Además, posibilita el acceso remoto desde cualquier ubicación a servicios corporativos, para empresas, organismos externos y usuarios en movilidad. La evolución de la Red Arterias en los últimos años ha estado marcada por las crecientes demandas de los proyectos. Es por ello por lo que la red se ha convertido en un factor crítico y ha exigido realizar un especial esfuerzo en mejorar las infraestructuras de comunicaciones existentes en todos los centros de la Conselleria de Sanidad, incorporando nuevas tecnologías de acceso con el objetivo de alcanzar la conectividad de todos los puestos de trabajo, optimizar el rendimiento y asegurar su disponibilidad. Las sedes que forman parte la red Arterias se pueden agrupar en tres tipos, en función de su tamaño y sus requerimientos funcionales: | Tipo Sede | Descripción | Localización | Número | |------------------------|----------------------------------------------------------------------------------------------------------------|----------------|----------| | Nodo Troncal | Centro de Informática. Incluye CPD corporativo. | 1 | Tipo 1 | | Centros con CPD propio | Hospitales Salud Pública Servicios Centrales Direcciones Territoriales Centro de Transfusión de la CV EVES SES | 38 | Tipo 2 | | Centros sin CPD propio | Centros sanitarios y administrativos, distribuidos en el ámbito de la Comunidad Valenciana. | 1330 | Tipo 3 | La sede Nodo Troncal está ubicada en el Centro de Informática de la Conselleria de Sanidad, y es el lugar donde se encuentran instalados los servidores donde se alojan los principales sistemas de información corporativos que siguen una arquitectura centralizada, así como la totalidad de servicios de red horizontales, tanto de voz como de datos. Se trata de una red IP con tecnologías 10-gigabit y 40-gigabit Ethernet (par trenzado y fibra óptica) dividida en entornos funcionales, de modo que se garantiza una alta disponibilidad, rendimiento y seguridad, debido a la criticidad de los servicios allí ubicados. <!-- image --> <!-- image --> La interconexión a la Red Arterias de todos los centros administrativos y asistenciales de la Conselleria de Sanidad es soportada por la red de área extensa o Red Corporativa del GVA (RCGV), siendo el ámbito geográfico la Comunidad Valenciana. La red Arterias actual está implementada como una red MacroLan/VPN-IP para tráfico interno proporcionada por el proveedor de datos de la Generalitat Valenciana, en donde todos los centros (hospitales y centros asistenciales y el CPD centralizado de la Conselleria de Sanidad) se encuentran conectados unos con otros a través de una topología mallada de todos con todos dentro de la VRF. Cualquier acceso a la red Arterias e Internet tiene que pasar por el CPD del nodo centralizado del Centro de Informática. El servicio VPN-IP actualmente puede ser con tecnologías FTTH y 4G. Bajo este modelo de red, se puede ver Arterias como una única red donde se conectan todos los centros, y que por lo tanto tiene una arquitectura mallada (todos los nodos pueden conectarse con el resto, directamente). Dentro de la arquitectura de la RCGV, podemos distinguir dos tipos de redes: - Red MacroLan/VPN-IP para tráfico interno. Une todos los centros o sedes de una misma Conselleria, por tanto, existe una red de este tipo por cada Conselleria. En el caso de la Conselleria de Sanidad, su red interna es la red Arterias. - Red IP-Gigabit para tráfico externo. Se trata de una única red que une todas las Consellerías y sirve de salida a Internet. La RCGV, en la actualidad, está soportada y provisionando por los operadores adjudicatarios de las comunicaciones corporativas y de conectividad a Internet de la GVA, siendo la DGTIC el organismos encargada de gestionarla velando por la adecuada operatividad de la red mediante el establecimiento de mecanismos de diversificación de la red, tanto a nivel de red física en cuanto a trazado físico y centrales locales como en cuanto a red lógico con redundancia de equipamiento en cada una de las sedes y centrales e comunicaciones. La Conselleria de Sanitat ha emprendido actuaciones para que a lo largo de 2025 se disponga de diversificación total de red para conectividad a la Red Arterias (WAN de la Conselleria de Sanitat) en todos los hospitales y centros de la Conselleria de Sanitat con centro de proceso de datos (CPD) propio, así como la posibilidad de habilitar mecanismos de redundancia de líneas de conexión a Internet con operadores adicionales al operador principal adjudicatario de la gestión de la RCGV (Red Corporativa de la Generalitat Valenciana). Esto permitirá dotar a los hospitales, y otros centros, de línea principal y varias líneas de backup, tanto para la conexión a la Red Arterias como para la salida a Internet; implementadas con diferentes tecnologías: fibra óptica, móvil 4G (o superior) y comunicaciones vía satélite; asegurando, así, la redundancia de la conectividad y la diversidad de tecnologías y operadores. De este modo, las referidas sedes operativas usuarias de la HCU y con o sin CPD propio, disfrutarán de un grado de disponibilidad elevado que garantizará la conectividad necesaria con los sistemas de información ubicados tanto en el nodo troncal del Centro de Informática de la Conselleria de Sanitat como en las infraestructuras en la nube (cloud) asignadas al proyecto. ## 5.3.2 Criterios y características para la HCU En lo relativo a criterios y características de red y conectividad, a continuación, se indican los mínimos exigibles: - La solución de HCU deberá funcionar de manera óptima con un ancho de banda mínimo de 100 Mbps (full dúplex) en LAN/WAN y 10 Mbps (full dúplex) en conexiones remotas. - La latencia máxima aceptable será de 50 ms, tanto en LAN/WAN como en conexiones remotas. - El tráfico de la solución de HCU deberá tener la máxima prioridad en la red, utilizando mecanismos de QoS para asegurar el ancho de banda y latencia adecuados. <!-- image --> - La red deberá estar protegida mediante firewalls de próxima generación que permitan el control de acceso y la protección contra amenazas externas, sistemas de detección de intrusos (IDS) y prevención de intrusiones (IPS), y VPN para el acceso seguro desde ubicaciones remotas (con autenticación de dos factores). - Se deberá implementar la segmentación de la red mediante VLANs para separar el tráfico de la HCU de otros sistemas y aplicaciones, mejorando la seguridad y el rendimiento. ## 5.4 Seguridad En lo relativo a criterios y características de seguridad, a continuación, se indican los mínimos exigibles: - La solución/proveedor debe contar con la certificación ISO 27001. - La solución/proveedor debe contar con la certificación ISO 9001. - La solución/proveedor debe cumplir con el Reglamento General de Protección de Datos (RGPD). - La solución/proveedor debe cumplir con la certificación Certified Information Systems Auditor (SISA). - La solución/proveedor debe cumplir con el Esquema Nacional de Interoperabilidad (ENI). - La solución/proveedor debe cumplir con el Esquema Nacional de Seguridad (ENS) nivel alto. - Se debe implementar 2FA (Autenticación de Dos Factores) para mejorar la seguridad del acceso, requiriendo dos formas de verificación antes de permitir el mismo. - La solución debe soportar el uso de certificados digitales que estén homologados por la Agencia de Tecnología y Certificación Electrónica (ATCE) para garantizar la autenticidad y seguridad en las comunicaciones y transacciones electrónicas. En caso de que la solución no los dispiusieram el adjudicatario tendrá que realizar las modificaciones necesarias (de forma rápida y urgente) en su solución en caso de actualización de los certificados por parte de la ATCE de la Comunitat Valenciana. - La solución deberá permitir desde la instalación inicial la firma digital de todos los informes, documentos y transacciones, asegurando la integridad y autenticidad de éstos, que sean establecidos por el Comité de Implantación. - La solución debe incorporar técnicas de anonimización y seudonimización para proteger la identidad de los sujetos en los datos, cumpliendo con las regulaciones de privacidad. - Se deben mantener registros de auditoría detallados para todas las acciones realizadas en la solución, proporcionando trazabilidad y permitiendo la revisión de eventos y cambios. - La solución debe incluir redundancias, réplicas, sistemas alternativos de cómputo y comunicaciones, copias de seguridad regulares y un plan de recuperación ante desastres; necesarios y suficientes para garantizar el mayor grado posible de continuidad de la actividad asistencial y la recuperación de datos en caso de fallos o eventos adversos. - Se deben implementar medidas de protección contra ataques de denegación de servicio (DoS y/o DDoS) para garantizar la disponibilidad y estabilidad de la solución frente a intentos de sobrecarga. - La solución debe contar con un plan de ciberseguridad que defina las estrategias y medidas para proteger la infraestructura, los datos y las comunicaciones frente a amenazas y ataques. - La solución debe contar con mecanismos para el cifrado de datos que garanticen la protección de la información tanto en tránsito como en reposo, asegurando la confidencialidad y seguridad de los datos. - Los 'web services' deben estar securizados mediante protocolos y técnicas de cifrado para proteger la comunicación y los datos transmitidos. - La solución debe permitir la prevención de XSS (Cross Site Scripting). - La solución debe permitir la prevención de CSRF (Cross Site Request Forgery). - La solución debe contar con un mecanismo de prevención de sesiones múltiples. <!-- image --> - La solución debe permitir la funcionalidad SoD (Segretation of Duties) o segregación de responsabilidades. - Se deberá garantizar la integración contra el LDAP (Directorio Activo de la Conselleria de Sanitat, dominio CS) para la autenticación centralizada. - La gestión de usuarios y roles debe estar integrada con los mecanismos de autenticación de la Conselleria de Sanitat para asegurar una administración coherente y segura de los accesos. - Inicio de sesión habilitado para CAPTCHA para evitar ataques masivos DoS/DDoS y reforzar la protección contra ataques de fuerza bruta. ## 5.5 Gestor o gestores de base de datos En lo relativo al gestor de base de datos las características exigibles serán las siguiente: - El motor o motores de bases de datos que formen parte de la infraestructura del proyecto, deben permitir transacciones ACID (Atomicidad, Consistencia, Aislamiento, Durabilidad) en los clústeres residentes en cada centro de datos; tanto a nivel de producción como de réplica. - Como sistemas de gestión de bases de datos (uno o varios), se aceptan como adecuados los óptimos para el proyecto a criterio del licitador que garanticen los máximos niveles de rendimiento, seguridad, flexibilidad, funcionalidad, redundancia, disponibilidad, escalabilidad y resiliencia. Se consideran válidos tanto sistemas de gestión de bases de datos relacionales, o SQL, tales como Oracle®, SQL-Server®, MySQL®, IBM-Informix®, PostgreSQL® u otros; como no relacionales, o NoSQL, tales como MongoDB®, Cassandra®, Redis®, OrientDB®, Couchbase® u otros; a efectos de disponer de las herramientas y entornos adecuados para el almacenamiento y gestión de datos estructurados y no-estructurados. - Se requiere un mínimo de tres instancias de cada una de las bases de datos necesarias y suficientes para la ejecución del proyecto: una base de datos primaria (transaccional) y dos réplicas (idénticas y consistentes). La replicación deberá ser continua y automática, no basada en procesos batch, para minimizar la pérdida de datos en caso de fallo. Esto para cada centro de datos. A nivel de consistencia de los datos - o Dentro de cada centro de datos: Las réplicas deberán ser síncronas, garantizando que cualquier escritura en la base de datos primaria se refleje inmediatamente en las réplicas. Esto asegura la máxima consistencia de datos dentro de un mismo centro de datos. - o Entre centros de datos: Se requiere atomicidad transaccional entre los centros de datos interconectados. Sin embargo, y como punto de partida, a revisar en caso de ser necesario, no se requieren de mecanismos de replicación que optimicen el rendimiento y minimicen la latencia, como la replicación basada en logs o la consistencia eventual, en lugar de protocolos 2PC/3PC que pudieran penalizar los tiempos de respuesta. A nivel de seguridad: - o La comunicación entre la base de datos primaria y las réplicas deberá ser segura, utilizando protocolos de cifrado y autenticación. - o Se deberán implementar medidas de seguridad para proteger las réplicas contra accesos no autorizados y ciberataques. - Escalado de lectura en las réplicas de la base de datos, permitiendo que las instancias secundarias puedan actuar de fuentes de lectura para distribuir el tráfico total de consultas y mejorar el rendimiento y los tiempos de respuesta. - Se requiere que el cifrado de base de datos sea tanto en reposo como en tránsito. - El control de acceso estará basado en roles (RBAC), permitiendo una gestión granular de permisos para los usuarios. - Compatibilidad con la autenticación de certificados SCRAM y x.509. - Se deben asegurar los registros de auditoría a nivel de base de datos. - Se requiere, como nivel de seguridad adicional, una gestión de listas blancas para el control del acceso a través de IP a nivel de Base de Datos. - El gestor o gestores de bases de datos deberán dar soporte a distintos tipos de búsqueda: por campos fijos (indexados o no), por texto libre (como Lucene o similar), por vectores para manejar embeddings y búsquedas de similitud dando soporte a casos de GenAI. También se debe poder realizar búsquedas híbridas combinando todos los tipos de índices (B-Tree, fulltext search, vectorial, geoespacial, etc.). - Se deberá garantizar el rendimiento en los escalados verticales y horizontales a medida que la volumetría del proyecto vaya aumentando. - Se requieren vistas de navegación inteligible sobre los datos de la historia clínica directamente en la base de datos sin necesidad de un usuario técnico o el uso de sentencias SQL (Structured Query Language). - Capacidad para incorporar actualizaciones y/o modificaciones de estructuras y/o modelos de datos evitando la migración de esquemas y con mínimo o nulo impacto en las versiones de producción de las aplicaciones que pudieran requerir paradas del sistema o reinicio masivo de sesiones. - El gestor o gestores de bases de datos deberán dar soporte, al menos, a los diferentes tipos de datos clínicos: - o Ficheros - o Datos interoperables - o Series temporales - o Genómica (tipo VCF, Variant Call Format) - o Vectores - o Otros que la solución ofertada pudiera contemplar ## 5.6 Adecuación y soportes futuros Para poder asegurar tanto la inversión económica como el esfuerzo humano en la implantación de la solución, el adjudicatario deberá entregar una declaración responsable en la que debe comprometerse a disponer de versiones que aseguren la compatibilidad de su producto con las posibles versiones de los sistemas operativos de los puestos de trabajo a los que la Conselleria de Sanidad se vea obligada a migrar por obsolescencia de estos, durante al menos los próximos 10 años. ## 5.7 Calidad del software El aseguramiento del cumplimiento de la calidad del producto se considera fundamental para garantizar la correcta prestación de los servicios, por lo que, de forma específica, se implementará como línea de trabajo, la gestión de calidad del software. El licitador deberá elaborar una propuesta organizativa y un plan de trabajo detallado para acometer las siguientes tareas: - Evolución normativa. Dentro del ámbito de actuación específico del contrato, todo lo relativo a la recogida de las normas actuales, revisión, corrección y en su caso ampliación de la normativa existente, que el adjudicatario deberá presentar, mediante los planes para garantizar la calidad del software. Al finalizar el contrato se deberán entregarse todos los documentos relativos al plan de calidad del software estándar que, al menos, deberán contemplar los siguientes aspectos: - o Verificación de la inclusión de pruebas unitarias, de integración, de carga, sobre los desarrollos realizados. <!-- image --> <!-- image --> - o Control de versiones de código fuente sobre los desarrollos dentro del ámbito de este contrato. - o Gestión de la documentación asociada a la solución completa. - o Apoyo y orientación para la implementación de la normativa. - o Informes periódicos del grado de cumplimiento de las normas implantadas. - Control de la calidad de software. De forma específica el adjudicatario deberá dotarse de las herramientas, infraestructuras y perfiles necesarios para realizar controles de calidad sobre el software y los productos entregados. - Certificación. Previo al paso de un desarrollo a los distintos entornos demandados (formación, preproducción y producción), el adjudicatario deberá elaborar y presentar un informe con la certificación correspondiente de que ha superado los controles de calidad establecidos, así como que el desarrollo en cuestión cumple completamente con los requisitos funcionales particulares para los que hubiera sido diseñado. ## 6 REQUISITOS DE IMPLANTACIÓN En este apartado se establece los requisitos mínimos relativos al plan de despliegue de la HCU. Estos requisitos no serán objeto de valoración como criterio de valoración. El proyecto deberá quedar totalmente implantado y validado por parte de la Conselleria de Sanidad 60 meses después de la adjudicación definitiva del expediente. La puesta en producción del sistema se realizará por fases, siendo objeto de este concurso, la fase de implantación de la solución en el ámbito de la atención especializada de las 8 ASIs: en dónde se incluyen los hospitales, HACLES y centros adscritos; para estos últimos, se deberá garantizar que los profesionales de estos centros reciban la formación necesaria para poder utilizar las funcionalidades de la HCU que les sean requeridos en esta primera fase de implantación (funcionalidades de visualización de información relativa a la atención especializada). Los ámbitos, módulos, funcionalidades e integraciones a implantar son todos aquellos indicados en este PPT como mínimos exigibles, así como todos aquellos ámbitos, módulos y funcionalidades que el adjudicatario haya propuesto en su memoria técnica y desde el Comité de Implantación y de proyecto de la Conselleria Sanidad, se apruebe su implantación y despliegue. La implantación de aquellos ámbitos, módulos y funcionalidades que no se prioricen desde el Comité de Implantación y de proyecto de la Conselleria Sanidad para esta primera fase, será objeto de contratación en un nuevo expediente de servicios de implantación. Derivada de la consulta preliminar para adquisición, desarrollo y/o adecuación a un nuevo sistema de información hospitalaria y de las diferentes sesiones de trabajo que se hicieron con las empresas que mostrar interés en dicha consulta, se desprende que serán requeridas más de 900.000 horas para lo que son los servicios de: - Diseño y configuración de la solución "Estándar". - Servicios de integración con el repositorio/plataforma FHIR y otros Sistemas de Información. - Servicios de migración. - Servicios de configuración y parametrización. - Servicios de formación y gestión del cambio. - Servicios de go-live y soporte al go-live. - Servicios de gestión de proyecto. ## 6.1 Fases del proyecto Para una mayor claridad al licitador, se han agrupado las actividades o servicios a realizar en cinco grandes fases del proyecto: - Fase de puesta en marcha e Inicio. - Fase de diseño y configuración de la solución 'Estándar' de la HCU y de la infraestructura requerida. - Fase de implantación de la solución en los hospitales y HACLES. - Fase de mantenimiento y soporte post-arranque - Fase de finalización del contrato. En los siguientes subapartados se detalla el objetivo de la fase, principales actividades e hitos. En el apartado 7.2.3 se realizará un listado exhaustivo de la documentación y entregables a generar en cada fase. <!-- image --> ## 6.1.1 Fase de puesta en marcha e inicio El objetivo de esta fase es establecer las bases para una implementación exitosa del proyecto. Esto implica definir las estructuras de gobierno del proyecto, establecer canales de comunicación claros, validar el alcance del proyecto y alinear a todos los stakeholders (personal sanitario, directivos, proveedores, etc.). ## Actividades Clave: - Kick-off meeting con todos los implicados. - Designación del equipo del proyecto (tanto del proveedor como de la Conselleria de Sanidad). - Definición de roles y responsabilidades. - Elaboración del plan de implantación de proyecto detallado: - o Cronograma detallado con hitos, tareas, dependencias y responsables. - o Plan de gestión de riesgos (identificación, análisis, mitigación). - o Plan de comunicación (interna y externa). - o Plan de gestión de la calidad. - o Plan de formación. - o Plan de gestión del cambio. - o Plan de migración de datos (si aplica). - o Plan de pruebas. - o Mecanismos de seguimiento y control del proyecto. - Establecimiento de indicadores clave de rendimiento (KPIs) para medir el progreso. - Validación de los requisitos funcionales y técnicos de la HCU. - Análisis de la situación actual de los sistemas de información en los hospitales. - Inicio de la gestión del cambio ## Objetivo: - Suministro de licencias de la solución de HCU. ## 6.1.2 Fase de diseño y configuración de la solución 'Estándar' de la HCU y de la infraestructura requerida El objetivo de esta fase es adaptar la solución HCU a las necesidades específicas de la Conselleria de Sanidad y preparar la infraestructura tecnológica para su despliegue. ## Actividades Clave: - Análisis detallado de los procesos clínicos y administrativos de los hospitales. - Configuración de la infraestructura requerida para la solución HCU, incluyendo los despliegues de los diferentes entornos: formación y preproducción. - Configuración 'Estándar' de la solución HCU acorde a los requisitos mínimos definidos. - Pruebas de concepto (POC) para validar la solución y la infraestructura. - Configuración conectores de interoperabilidad entre la solución y la plataforma FHIR. - Elaboración de la documentación técnica de la solución y la infraestructura. - Definición de la estrategia de migración de datos (ítems vivos). - Desarrollo de las adaptaciones o extensiones necesarias para cubrir las necesidades específicas de la Comunidad Valenciana que no estén cubiertas por la solución estándar. - Diseño del plan de formación para los usuarios. - Diseño del plan de soporte. ## Hitos: - Hito 1. Despliegue y configuración de la infraestructura del entorno de formación. - Hito 2. Despliegue y configuración de la infraestructura del entorno de preproducción. <!-- image --> - Configuración estándar de la solución. - Validación de la solución a implantar en el primer hospital. ## 6.1.3 Fase de implantación de la solución en los hospitales y HACLES El objetivo de esta fase es desplegar la solución HCU en todos los hospitales y HACLES de la Comunidad Valenciana, asegurando una transición suave y minimizando las interrupciones en la atención al paciente. ## Actividades clave: - Preparación del entorno de producción y adecuación de la infraestructura y servicios asociados acorde al plan de arranque. - Migración de datos desde los sistemas existentes. - Instalación y configuración de la HCU en el entorno de producción de cada centro, incluyendo la configuración de interfaces y la migración de datos (ítems vivos). - Pruebas exhaustivas de la solución en cada hospital (pruebas de integración, pruebas de usuario, pruebas de rendimiento, etc.). - Formación del personal sanitario y administrativo en el uso de la HCU. - Despliegue gradual de la solución en cada hospital (por ejemplo, por servicios o áreas). - Soporte in-situ durante la puesta en marcha. - Monitorización del rendimiento y resolución de problemas. ## Hitos: - Implantación de la solución en el primer hospital: - o Hito 3. Hospital General Universitario de Valencia - Implantación de la solución en la primera ASI: ASI Valencia -Oeste: - o Hito 4. Hospital de Manises - o Hito 5. Hospital General de Requena - o Hito 6. Hospital Crónicos Mislata (HACLE) - Implantación de la solución en la ASI Alicante Norte: - o Hito 7. Hospital de Denia - o Hito 8. Hospital Universitario San Juan - o Hito 9. Hospital La Marina Baixa - o Hito 10. Hospital La Pedrera (HACLE) - Implantación de la solución en la ASI Castellón: - o Hito 11. Hospital Comarcal Vinaròs - o Hito 12. Hospital Universitario Castellón - o Hito 13. Hospital Provincial Castellón - o Hito 14. Hospital Universitario de la Plana - o Hito 15. Hospital La Magdalena (HACLE) - Implantación de la solución en la ASI Alicante Centro: - o Hito 16. Hospital Virgen de los Lirios - o Hito 17. Hospital General Universitario de Elda - o Hito 18. Hospital General Universitario Dr. Balmis - o Hito 19. Hospital Sant Vicent del Raspeig (HACLE) - Implantación de la solución en la ASI Valencia Norte: - o Hito 20. Hospital de Sagunto <!-- image --> - o Hito 21. Hospital Francesc de Borja - o Hito 22. Hospital Clínico de Valencia - o Hito 23. Hospital La Malvarrosa - Implantación de la solución en la ASI Alicante Sur: - o Hito 24. Hospital General Universitario de Elche - o Hito 25. Hospital Vega Baja - o Hito 26. Hospital Universitario de Torrevieja - o Hito 27. Hospital de Vinalopó - Implantación de la solución en la ASI Valencia Sur: - o Hito 28. Hospital Arnau de Vilanova - o Hito 29. Hospital Universitario Politécnico La Fe - o Hito 30. Hospital Psiquiátrico Provincial - o Hito 31. Hospital Dr. Moliner (HACLE) - o Hito 32. Hospital de Llíria - Implantación de la solución en la ASI Valencia -Este: - o Hito 33. Hospital General de Ontinyent - o Hito 34. Hospital Universitario Dr. Peset - o Hito 35. Hospital Pare Jofre (HACLE) - o Hito 36. Hospital Universitario Ribera - o Hito 37. Hospital Lluis Alcanyis - Implantación todas las prestaciones adicionales ofertadas y priorizadas por el Comité de Implantación ## 6.1.4 Fase de mantenimiento y soporte post-arranque Esta fase tiene como objetivo garantizar la estabilidad, el correcto funcionamiento, la evolución continua y la adaptación de la HCU a las necesidades cambiantes de los usuarios y del entorno, una vez implementada en cada centro. Comprende los servicios de soporte técnico y funcional, mantenimiento (correctivo, preventivo, evolutivo y adaptativo), monitorización, formación continua y gestión del cambio. Esta fase se iniciará para cada hospital o centro tras su correspondiente puesta en producción, y se extenderá hasta la finalización del contrato (mes 60), momento en el cual comenzará el período de garantía legal. ## Actividades clave: - Soporte Técnico: Atención y resolución de incidencias técnicas relacionadas con la HCU (errores de software, problemas de rendimiento, etc.). Registro, clasificación y seguimiento de todas las incidencias y peticiones de servicio en un sistema de ticketing, con asignación de prioridades según su impacto y urgencia. - Soporte Funcional: Atención y resolución de dudas y consultas de los usuarios sobre el uso de la HCU. Creación de una base de conocimientos con preguntas frecuentes y soluciones a problemas comunes. - Mantenimiento Correctivo: Corrección de errores y defectos detectados en la HCU. Resolución de problemas de software o hardware, con su consecuente desarrollo de parches o actualizaciones para corregir los errores. - Realización de tareas de mantenimiento preventivo programadas para prevenir problemas y optimizar el rendimiento de la HCU, incluyendo: - o Monitorización continua del rendimiento y la disponibilidad de la HCU y de la infraestructura asociada. <!-- image --> - o Revisión y análisis de logs. - o Verificación de la integridad de la base de datos. - o Optimización de la base de datos (reorganización de índices, actualización de estadísticas, etc.). - o Aplicación de parches de seguridad y actualizaciones del sistema operativo y del software de base. - Formación Continua: Impartición de cursos de actualización y reciclaje para los usuarios sobre nuevas funcionalidades o cambios en la HCU. - Evaluación de la Satisfacción del Usuario: Realización de encuestas y entrevistas periódicas para evaluar la satisfacción de los usuarios con la HCU e identificar áreas de mejora. - Mantenimiento evolutivo: implantación de la última versión de software disponible en todo momento para todos los hospitales y centros objeto de la licitación. Recopilación de peticiones de mejora y nuevas funcionalidades de los usuarios. ## Objetivos: - Tras la implantación de cada hospital dará inicio la fase de mantenimiento en dicho hospital. Será una fase gradual en la que irán sumándose nuevos hospitales a la fase de mantenimiento a medida que van arrancando según los hitos establecidos en la fase de implantación. - Fin de Contrato, e inicio de la Garantía: En el mes 60 se dará por finalizado el contrato, dando inicio al período de garantía. ## 6.1.5 Fase de finalización del contrato Esta fase formaliza el cierre del proyecto y la transferencia de responsabilidades a la Conselleria de Sanidad. Es una fase de cierre y transferencia . Esta fase se deberá planificar 2 meses antes de la finalización del contrato. ## Actividades Clave: - Revisión Final del Proyecto: Verificación de que se han cumplido todos los objetivos del proyecto y que se han entregado todos los entregables. - Elaboración del Informe Final del Proyecto: Documento que resume todo el trabajo realizado, los resultados obtenidos, las lecciones aprendidas y las recomendaciones para el futuro. - Transferencia de Conocimiento: Transferencia de todo el conocimiento y la documentación necesaria al personal de la Conselleria de Sanidad para que puedan gestionar y mantener la HCU de forma autónoma o transferirlo al mismo proveedor u otro. - Cierre Administrativo del Contrato: Formalización de la finalización del contrato. ## 6.2 Plan de implantación El diseño del plan de implantación es clave en aras de cumplir los objetivos del proyecto tanto desde el punto de vista funcional, técnico, de gestión del cambio y también en lo relativo a los plazos del proyecto. Para ello, se deberá detallar una metodología que busque la máxima optimización de los recursos, identificando y proponiendo la ejecución de tareas de ámbito general, así como la incorporación de tareas de ámbito local (hospital) o por ASI. Las mínimas tareas exigidas serán las siguientes: - Análisis previo del sistema, junto con los responsables asistenciales designados por parte de la Conselleria y los Hospitales, con el objetivo de llevar a cabo la parametrización del sistema acorde a las necesidades generales, partiendo de una configuración estándar y de consenso. <!-- image --> <!-- image --> - Análisis específico por hospital o tipología de hospital. Ajuste de la configuración y parametrización base. - Implantación y parametrización de la solución. El adjudicatario deberá configurar el sistema ofertado a las necesidades de cada una de las unidades asistenciales incluidas en el ámbito del contrato. Personalizando el sistema para adaptarlo al flujo de trabajo de cada una de las unidades asistenciales. - Migración de los ítems 'vivos'. - Instalación total del sistema , integraciones, migraciones, conexiones, etc. - Formación a los profesionales (asistenciales, administrativos e informáticos) usuario del sistema. - Aceptación del sistema y arranque. - Soporte presencial y acompañamiento durante el arranque en cada unidad para atender las necesidades de las diferentes unidades. - Soporte post-arranque en modalidad N2 y N3. - Gestión del proyecto de acuerdo con metodologías de gestión estándar (como PMBOK). Durante cada una de las fases del proyecto, el adjudicatario aportará los recursos humanos y el tiempo necesario hasta que el sistema esté funcionando correctamente. El adjudicatario deberá garantizar en todo momento durante el proyecto de implantación, la convivencia entre el actual sistema existente y la implantación de la nueva solución. El adjudicatario deberá designar un coordinador/es de soporte cuya dedicación y disponibilidad se detallará en la oferta. Será responsabilidad de cada departamento de informática de cada hospital la preparación y configuración de los PCs y entornos de movilidad en los que se vaya a utilizar la solución. El adjudicatario proporcionará documentación técnica, funcional y cuadernos de prueba para verificar el correcto funcionamiento del aplicativo. A continuación, se expone, a título indicativo y no exhaustivo, un plan de implantación referencial para la fase de despliegue de la Historia Clínica Única (HCU), articulado en torno a hitos de consecución, y priorizando, prima facie, un despliegue progresivo por Áreas de Salud Integradas (ASIS). No obstante, se deja expedita la vía para que los licitadores, en el ejercicio de su autonomía y fundamentadamente, propongan otras alternativas de despliegue, basadas en las características intrínsecas de la solución ofertada, sus capacidades técnicas y organizativas, y su know-how en proyectos de análoga naturaleza. Estas propuestas deberán respetar los objetivos generales del proyecto y ajustarse a los requisitos técnicos y funcionales establecidos en el presente pliego, garantizando siempre la consecución efectiva de los resultados esperados. Se significa, que cualquier propuesta de plan de implantación alternativa deberá ser motivada in extenso, detallando las ventajas y beneficios que reportaría frente al plan referencial, y justificando, pormenorizadamente, la viabilidad técnica y organizativa de la misma. La propuesta de implantación final que se lleve a cabo deberá ser aprobada a criterio de la Conselleria y el adjudicatario quedará igualmente comprometido en el pleno cumplimiento de los objetivos generales del proyecto. <!-- image --> Ilustración 8. Propuesta plan de implantación <!-- image --> ## 6.3 Plan de soporte y gestión del cambio El Plan de Soporte y Gestión del Cambio tiene como objetivo asegurar la correcta adopción e integración de la Historia Clínica Única (HCU) en el sistema sanitario de la Comunidad Valenciana, minimizando el impacto en los usuarios y maximizando los beneficios del proyecto. ## 6.3.1 Soporte a Usuarios El adjudicatario deberá proporcionar un servicio de soporte técnico y funcional a los usuarios de la HCU, que incluya: - Canales de atención: Ofrecer múltiples canales de atención a los usuarios, como teléfono, correo electrónico, chat y portal web de soporte. - Disponibilidad: Garantizar la disponibilidad del servicio de soporte durante las 24 horas del día, los 7 días de la semana, con tiempos de respuesta acordados en el ANS (Acuerdo de Nivel de Servicio). - Resolución de incidencias: Resolver las incidencias y los problemas técnicos y funcionales que puedan surgir durante el uso de la HCU, con un seguimiento exhaustivo y una comunicación proactiva con los usuarios. - Base de conocimientos: Crear y mantener una base de conocimientos con información relevante sobre la HCU, incluyendo manuales de usuario, tutoriales y preguntas frecuentes. - Herramientas de soporte remoto: Utilizar herramientas de soporte remoto para asistir a los usuarios en la resolución de problemas y la configuración del sistema. - Gamificación y Comunidad de la HCU: La gamificación puede ser una herramienta muy efectiva para aumentar la motivación, el compromiso y la participación de los usuarios en la formación de la HCU. Al incorporar elementos de juego en el proceso de aprendizaje, se puede crear una experiencia más atractiva y divertida, que fomente la adquisición de conocimientos y el desarrollo de habilidades. El servicio de soporte y mantenimiento que se realizará será del tipo 'integral'. Se incluirá todo el soporte (técnico y funcional) y mantenimiento (Preventivo, Correctivo, Evolutivo, Adaptativo y Técnico-legal) del material suministrado por el adjudicatario durante la vigencia del contrato y las conexiones existentes entre la solución de HCU y los distintos sistemas de información existentes en la Unidades Asistenciales. ## 6.3.2 Gestión del Cambio El adjudicatario deberá implementar una estrategia de gestión del cambio que facilite la adopción de la HCU por parte de los usuarios, que incluya: - Análisis de impacto: Realizar un análisis del impacto de la HCU en los procesos de trabajo, los roles y la cultura de la organización, para identificar las áreas que requerirán una mayor adaptación al cambio. - Formación a usuarios: Desarrollar e impartir programas de formación adaptados a los diferentes perfiles de usuario, utilizando metodologías participativas y materiales de apoyo de calidad. El detalle del plan de formación se especifica en el siguiente apartado. - Plan de comunicación: Diseñar y ejecutar un plan de comunicación para informar a los involucrados sobre el proyecto, los cambios que implica y los beneficios esperados. El detalle del plan de comunicación se especifica en el siguiente apartado. - Gestión de la resistencia al cambio: Identificar y abordar las posibles resistencias al cambio por parte de los usuarios, implementando estrategias para facilitar la adopción del sistema y minimizar el impacto en los flujos de trabajo. - Evaluación de la adopción: Medir la adopción de la HCU y el grado de satisfacción de los usuarios, utilizando encuestas, entrevistas y análisis de datos de utilización. El adjudicatario deberá realizar un seguimiento y evaluación del plan de gestión del cambio, que incluya: - Definición de métricas de éxito: Establecer métricas para medir la adopción de la HCU, la satisfacción de los usuarios y el cumplimiento de los objetivos. - Monitorización del progreso: Realizar un seguimiento del progreso del plan, identificando las áreas que requieren atención. - Evaluación del impacto: Evaluar el impacto de la HCU en la organización y en la atención al paciente en aras que se puedan medir y documentar los beneficios esperados que se han indicado en el apartado 1 del presente pliego. Así mismo, en aras de minimizar la resistencia al cambio, facilitar la adopción de la nueva HCU y su formación y asegurar la continuidad operativa, se exige que los proveedores la elaboración de un Documento de Procesos que refleje los procesos actuales y futuros de las aplicaciones corporativas claves afectadas por la transformación digital. Este documento servirá como guía y punto de referencia para comprender el impacto de los cambios en los flujos de trabajo de los usuarios. El Documento de Procesos deberá incluir, como mínimo, la siguiente información: - Descripción detallada de los procesos actuales: Detallar paso a paso cómo se realizan las tareas actualmente en las aplicaciones corporativas, incluyendo los roles y responsabilidades de los usuarios involucrados. - Descripción detallada de los procesos futuros: Describir cómo se realizarán las mismas tareas con las nuevas herramientas y procesos digitales, incluyendo los nuevos roles y responsabilidades. - Mapas de procesos: Utilizar diagramas de flujo para visualizar los procesos actuales y futuros, facilitando la comprensión de los cambios y las interacciones entre los diferentes actores. - Impacto en los usuarios: Identificar cómo los cambios afectarán a los usuarios, qué necesitan saber para adaptarse a los nuevos procesos y qué beneficios obtendrán de la transformación digital. <!-- image --> <!-- image --> - Glosario de términos: Incluir un glosario de términos para asegurar una comprensión común de los conceptos y la terminología utilizada. El Documento de Procesos se centrará en los procesos y las aplicaciones corporativas más críticas y que tengan un mayor impacto en los usuarios. Los procesos que detallar serán los mismos que se han especificado en el apartado '4.1.2 Procesos asistenciales y flujos de trabajo' del presente PPT. El Documento de Procesos deberá estar disponible en formato digital accesible para todos los usuarios, a través de la intranet corporativa u otras plataformas de colaboración. ## 6.4 Plan de formación ## 6.4.1 Modelo formativo Los licitadores deberán ofertar un modelo formativo híbrido que combine las siguientes modalidades: 1. Formación online a través de un Plataforma e-learning 2. Cursos presenciales, tanto en salas y aulas formativas como formación en puestos de trabajo 3. Presencialidad en el soporte post-arranque 4. Evaluación y seguimiento ## 6.4.2 Plataforma de formación El proveedor deberá ofertar una plataforma de formación e-learning que cumpla con los siguientes requisitos: ## 1. Funcionalidades esenciales: - Gestión de usuarios: - o Permitir el auto-registro de usuarios y la inscripción en cursos. - o Soportar la importación y exportación de usuarios desde sistemas externos, como LDAP y Active Directory. - o Disponer de perfiles de usuario con información relevante, incluyendo rol profesional, departamento, historial formativo y competencias. - o Permitir la segmentación de usuarios por grupos y roles para asignar formaciones específicas. - Gestión de cursos: - o Facilitar la creación y gestión de cursos con diferentes formatos, como texto, vídeo, SCORM y otros formatos multimedia. - o Permitir la organización de cursos en categorías y planes de formación (learning path) por rol profesional. - o Incluir herramientas de autoría para crear contenido interactivo. - o Ofrecer herramientas de evaluación del aprendizaje, como cuestionarios, tareas y foros. - o Permitir el seguimiento del progreso del alumno en tiempo real. - o Mostrar información detallada de cada curso: descripción, objetivos, duración, requisitos previos, formador, etc. - o Incluir un sistema de recomendación de cursos basado en el perfil del usuario, su historial formativo y sus intereses. - o Evaluación de los cursos mediante encuesta y/o exámenes que acrediten el conocimiento adquirido. - Comunicación e interacción: <!-- image --> - o Disponer de foros de discusión para fomentar la interacción entre alumnos y formadores. - o Incluir un sistema de mensajería interna para la comunicación directa entre usuarios. - o Ofrecer notificaciones y recordatorios personalizados. - o Integrar herramientas de videoconferencia para sesiones en vivo. ## · Gamificación: - o Implementar un sistema de puntos, insignias y clasificaciones para motivar la participación. - o Incluir retos y actividades para incentivar el aprendizaje. - Informes y analíticas: - o Generar informes sobre el progreso de los alumnos, el uso de la plataforma y la eficacia de la formación. - o Ofrecer visualización de datos en paneles de control. - o Permitir la exportación de datos en diferentes formatos. ## · Certificaciones: - o Facilitar la emisión de certificados de finalización de cursos. - o Permitir la personalización de certificados con la imagen corporativa de la CS. - o Incluir un sistema de registro y verificación de certificados. ## 2. Requisitos técnicos: - Accesibilidad: Cumplir con los estándares de accesibilidad WCAG para garantizar el acceso a todos los usuarios. - Seguridad: Implementar medidas de seguridad para proteger los datos de los usuarios y el contenido formativo, cumpliendo con el Esquema Nacional de Seguridad (ENS). - Integración: Integrarse con sistemas externos, como LDAP y sistemas de Single Sign-On (SSO). - Escalabilidad: Ser capaz de manejar un gran número de usuarios y cursos sin afectar al rendimiento. - Rendimiento: Ofrecer tiempos de respuesta óptimos y alta disponibilidad. - Soporte técnico: Proporcionar un servicio de soporte técnico con acuerdos de nivel de servicio (SLA) definidos. ## 6.4.3 Cursos presenciales La planificación, gestión y ejecución de la formación, correrá a cargo del proveedor, que formará directamente a los siguientes tipos de usuarios: - Referentes/administradores: el adjudicatario formará a los referentes que seleccionen los responsables de la Conselleria de Sanidad. La formación deberá ser la necesaria para que los referentes puedan realizar la parametrización y mantenimiento básico del sistema. Estos usuarios actuarán como multiplicadores del conocimiento y líderes en la adopción del sistema en sus respectivos departamentos o centros. Por lo tanto, su formación debe ser más extensa y profunda que la del resto de usuarios. - Usuarios clínicos, asistenciales y administrativos : orientada a los usuarios finales de la aplicación y enfocada al uso de los distintos módulos y funcionalidades que componen la solución. Esta formación se realizará antes de la puesta en marcha de la aplicación y regularmente durante la fase de implantación y garantía. El adjudicatario deberá garantizar la formación del máximo número de usuarios posible, implementando estrategias proactivas para facilitar el acceso y la participación en los programas de formación, y adaptando las modalidades y los horarios a las necesidades de los diferentes perfiles de usuario. - Formación al equipo Help Desk: orientada a los usuarios que darán un primer nivel de soporte a los usuarios. Esta formación debe tener una orientación práctica a la hora de resolver las <!-- image --> principales consultas y dudas de los usuarios. Se deberá incluir una herramienta de soporte para el troubleshooting básico, antes que se escale la incidencia o duda al nivel 2. - Formación técnica del producto: orientada a los Departamento de Sistemas y Tecnologías de la información de los diferentes hospitales, así como a los técnicos que así lo requieran de la Conselleria de Sanidad y enfocada a la administración de la aplicación, incluyendo formación sobre el modelo de datos. - Formación técnica: orientada al personal técnico de los Departamentos de Sistemas y Tecnologías de la Información de los diferentes hospitales, así como a los técnicos de la Conselleria de Sanitat, en la administración y gestión de la infraestructura sobre la que se despliega la HCU o en la administración de gestión de bases de datos no relacionales o en la administración de la nube. El adjudicatario deberá entregar la documentación de los cursos de formación, así como la documentación y guías de uso de las diferentes funcionalidades que ofrezca la aplicación ofertada. En lo relativo a la formación, se ofrecerá una planificación detallada del alcance de los contenidos, así como el número de horas previstas para los diferentes tipos de usuarios detallados anteriormente. Este número de horas es orientativo y en ningún caso será el límite de horas a impartir si la formación no ha llegado al nivel adecuado para la adopción del sistema. El adjudicatario deberá incluir los manuales de explotación, FAQs (preguntas más frecuentes) y procedimientos de atención de incidencias correspondientes para que puedan actuar los servicios propios del Gobierno en caso necesario. Los formadores deberán tener la cualificación y la experiencia adecuadas en la HCU y en metodologías de formación. En cuanto a la logística y materiales requeridos, los licitadores deberán indicar qué necesidades prevén tener por cada uno de los hospitales, HACLES y centros adscritos, en aras que desde la CS se pueda dimensionar las aulas y equipos informáticos. ## 6.4.4 Presencialidad en el soporte post-arranque El adjudicatario deberá ofrecer asistencia presencial en los hospitales, HACLES y centros adscritos una vez estos arranquen con la nueva HCU. Durante las visitas presenciales, el equipo de soporte deberá: - Resolver incidencias y problemas técnicos. - Brindar asesoramiento y apoyo a los usuarios en el uso de la HCE. - Identificar posibles mejoras y optimizaciones del sistema. - Recoger la opinión de los usuarios sobre la HCE y el servicio de soporte. El adjudicatario deberá generar informes periódicos sobre las visitas presenciales, detallando las incidencias resueltas, las consultas atendidas y las acciones realizadas. En relación con la duración del soporte presencial se establecen dos periodos: - Periodo inicial: Se establece una duración mínima de 4 semanas. - Soporte continuo: Después del periodo inicial, se establece un nivel de soporte presencial continuo, con una frecuencia menor de visitas a los hospitales establecida en una visita a la semana. ## 6.4.5 Evaluación del plan de formación y conocimientos adquiridos En la metodología del plan de formación se deberá detallar y establecer una serie de métricas para evaluar la eficacia de la formación y conocimientos que adquieren los diferentes tipos de usuario. A continuación se indican algunas de éstas: - Tasa de asistencia a las sesiones presenciales. - Resultados de las pruebas de evaluación. - Encuestas de satisfacción. - Nivel de conocimiento y competencia adquirido. - Número de incidencias reportadas tras la formación. - Número de horas mensuales de acceso a la plataforma formativa on-line. - Número de visitas realizadas para soporte continuo. ## 6.5 Plan de comunicación El licitador adjudicatario deberá elaborar e implementar un plan de comunicación que cumpla con los siguientes objetivos: - Informar: Difundir información clara y concisa sobre el proyecto de la HCU, sus objetivos, beneficios, fases de implantación y calendario. Asegurar que todos los involucrados del proyecto (profesionales sanitarios, pacientes, gestores, ciudadanía) reciban información relevante y actualizada sobre el proyecto. - Generar interés y confianza: Crear interés y expectativas positivas hacia la HCU, destacando sus ventajas y su impacto en la mejora de la atención sanitaria. Generar confianza en el proyecto y en la capacidad de la Conselleria de Sanitat para llevarlo a cabo con éxito. - Promover la participación: Fomentar la participación activa de los usuarios y otros involucrados en el proyecto, a través de canales de comunicación bidireccionales y espacios de diálogo. - Resolver dudas y preocupaciones: Responder a las preguntas y preocupaciones de los involucrados del proyecto sobre la HCU, ofreciendo información clara y transparente y abordando las posibles resistencias al cambio. - Gestionar las expectativas: Gestionar las expectativas de los involucrados del proyecto sobre la HCU, evitando rumores o desinformación y promoviendo una visión realista del proyecto y sus beneficios. El plan de comunicación deberá dirigirse a los siguientes públicos objetivo: - Profesionales sanitarios: Personal facultativo, personal de enfermería, auxiliares de enfermería, técnicos y personal administrativo de los centros sanitarios de la Comunitat Valenciana. - Pacientes: Ciudadanos que utilizan los servicios sanitarios de la Comunitat Valenciana. - Gestores y administradores: Responsables de la gestión de los centros sanitarios y de la Conselleria de Sanitat. - Medios de comunicación: Periodistas y medios de comunicación que difunden información sobre el sector salud. - Ciudadanía en general: Público en general interesado en la mejora de la atención sanitaria en la Comunitat Valenciana. El plan de comunicación deberá utilizar una variedad de canales de comunicación para llegar a todos los públicos objetivo, incluyendo: - Comunicación interna: - o Correo electrónico. - o Intranet. - o Cartelería en los centros sanitarios. - o Reuniones y jornadas informativas. - o Boletines informativos. - Comunicación externa: <!-- image --> - o Página web del proyecto. - o Redes sociales. - o Medios de comunicación (notas de prensa, entrevistas, etc.). - o Publicidad en medios online y offline. - o Eventos y campañas de difusión. - Comunicación con los pacientes: - o Portal del paciente. - o Folletos informativos. - o SMS y mensajes de texto. El plan de comunicación deberá incluir un cronograma detallado que especifique las acciones de comunicación que se realizarán en cada fase del proyecto, desde la planificación hasta la puesta en marcha y el seguimiento de la HCU. El plan de comunicación deberá especificar los recursos necesarios para su ejecución, incluyendo personal, materiales y herramientas de comunicación. También deberá incluir un presupuesto detallado para las acciones de comunicación. El Plan de Comunicación contemplará al menos: - Una presentación inicial del plan de proyecto con los diferentes responsables designados por cada área, así como los gestores de proyecto y en general los interlocutores designados. - Tener localizado y accesible el repositorio de información y documentación de avance de proyecto y si se estableciera algún sistema de noticias al respecto. - o El plan también tendrá que prever la disposición de su repositorio de trabajo con la información importante y útil de proyecto, en cuanto a lo que deba ser comunicado. - o El plan tendrá que contemplar los avisos de estado de los SI implicados y afectados durante la vida del proyecto (pe. tiempos de parada o degradados de servicio) y avances de proyecto en general. - Que cada participante del proyecto tenga claro cuál es su rol y función. Que tanto los involucrados como afectados sepan a quien dirigirse en cada momento. Que se establezcan los canales de comunicación y los procedimientos necesarios para ello. - Una presentación de cierre de proyecto y el nuevo modelo de relación establecido con Tecnologías de la Información, en adelante TI, o los proveedores tecnológicos según sea el caso de cara a la gestión, explotación y soporte de los SI del proyecto. - Se deberá incluir un plan de gestión de crisis para responder a posibles problemas o controversias relacionadas con la HCU. El plan de comunicación deberá incluir mecanismos para evaluar su eficacia y realizar un seguimiento de los resultados, utilizando métricas como el alcance de los mensajes, la participación de los usuarios y el impacto en la opinión pública. Se deberán elaborar informes de seguimiento periódicos que se presentarán a la Conselleria de Sanitat. ## 6.6 Plan de migración La planificación, gestión y ejecución de la migración de los ítems 'vivos' correrá a cargo del proveedor. De la misma forma, será de su responsabilidad cualquier herramienta, licencia de software o módulo que incorpore en el proyecto para la realización de la migración de los datos. De cara al plan de migración, los licitadores no sólo deberán tener en cuenta los ítems a migrar, sino que también deben valorar el sistema origen de estos, tipología de datos, formato y volumetría. Tal y como se ha detallado en el apartado '3. Alcance del Proyecto', en la Comunidad Valenciana existen diferentes sistemas de información a nivel de HIS y EMR y es clave que se tenga en consideración para `poder personalizar la migración por hospital o tipología de hospitales. No se contempla la migración del histórico de los diferentes sistemas, toda esta información se tendrá disponible y accesible a través de la plataforma/repositorio FHIR. El alcance de la migración se acotará a los ítems 'vivos' que deben garantizar la continuidad asistencial entre los sistemas que dejaran de utilizarse y la nueva HCU. <!-- image --> <!-- image --> En el Anexo IV -Datos a migrar , se ha indicado cuáles son los ítems que deberán estar migrados por cada uno de los sistemas de información existentes. El adjudicatario de la nueva HCU asumirá, en caso de que los haya, de aquellos costes de servicios de terceros en los que se requiera de trabajos específicos para la migración de datos a la nueva HCU, incluyendo, entre otros, lo siguientes trabajos: - Conversión de formatos de datos propietarios o no estándar a formatos compatibles con la nueva HCU. - Desarrollo de conectores o adaptadores para la extracción de datos de sistemas legados o con interfaces no estándar. - Limpieza y validación de datos que requieran la aplicación de reglas complejas o la intervención de expertos en análisis de datos. - Migración de bases de datos obsoletas o que no se integren fácilmente con la nueva HCU. - Validación de datos clínicos por parte de profesionales sanitarios con experiencia en terminología médica y codificación clínica. - Optimización del rendimiento del proceso de migración para grandes volúmenes de datos. - Escalabilidad de la infraestructura para soportar la migración de datos. Se realizarán pruebas de migración en un entorno de pruebas que simule el entorno de producción, con un conjunto de datos representativo. Una vez se valide este entorno, se deberá realizar la migración completa en el entorno de preproducción. En el plan de migración se deberá detallar qué mecanismos se proponen utilizar para validar y garantizar la información migrada, así como qué acciones mitigadoras se implementarán para evitar duplicados, inconsistencias o valores faltantes. Se deberá implementar un proceso de reconciliación de datos que permita comparar la información migrada con los datos originales en los sistemas de origen, con una precisión del 99.9%. ## 6.7 Plan de retorno del servicio de la HCU En el apartado 5.2 se ha indicado que los licitadores deberán proporcionar un plan de salida que garantice la portabilidad de los datos y la posibilidad de migrar la HCU a otra plataforma en el futuro, sin dependencia del proveedor de la nube soberana. Los licitadores deberán detallar exhaustivamente los pasos y los procedimientos para la migración de la solución completa a otra plataforma. Así como una estimación de los costes de los servicios requeridos para dicha salida y cualquier otro punto que sea relevante detallar. A continuación se detallan los compromisos que el adjudicatario se comprometerá a asumir y que se deberán ver reflejados en el plan de devolución a detallar en la memoria técnica: ## Transferencia y retorno de datos: - Formato estándar y accesible: Facilitar la devolución completa de todos los datos generados y almacenados durante la vigencia del contrato en un formato estándar, estructurado, interoperable y legible por máquina. Se priorizarán formatos abiertos y ampliamente utilizados en el sector salud, como FHIR, XML o CSV. El formato específico se acordará con la Conselleria con suficiente antelación. - Integridad y seguridad: Garantizar la integridad, la seguridad y la confidencialidad de los datos durante el proceso de transferencia, cumpliendo con la normativa de protección de datos (RGPD, LOPDGDD) y las políticas de seguridad de la Conselleria. <!-- image --> - Herramientas de migración: Proporcionar las herramientas y los scripts necesarios para la extracción y la migración de los datos a la nueva infraestructura. - Validación de datos: Colaborar con la Conselleria en la validación de los datos migrados para asegurar su completitud y consistencia. ## Exportación de la configuración del sistema: - Documentación completa: Entregar la documentación técnica completa de la HCU, incluyendo manuales de usuario, guías de administración, especificaciones técnicas, diagramas de arquitectura, códigos de configuración y cualquier otro elemento que permita la comprensión y la reconstrucción funcional del sistema. ## Asistencia técnica para la migración: - Soporte integral: Proporcionar asistencia técnica y operativa completa para la migración de los datos y del sistema a la nueva infraestructura designada por la Conselleria. Este soporte incluirá: - o Capacitación inicial al personal de la Conselleria sobre la nueva infraestructura y la migración de la HCU. - o Acompañamiento técnico durante todo el proceso de migración, con presencia de personal cualificado del adjudicatario. - o Soporte técnico posterior a la migración para resolver incidencias y garantizar el correcto funcionamiento de la HCU en la nueva infraestructura. ## Plazo y procedimiento de retorno: - Plazo máximo: El adjudicatario deberá devolver la información y completar la migración en un plazo máximo de 6 meses, a contar desde la notificación de finalización del contrato o de la decisión de migrar a una nueva infraestructura. - Plan de transición: Se deberá acordar un plan de transición detallado con la Conselleria, que incluya hitos, plazos y responsabilidades, para evitar interrupciones en el servicio y garantizar una migración ordenada y sin pérdida de datos. ## Borrado de datos: - Eliminación segura y certificada: Una vez confirmada la correcta transferencia de los datos, el adjudicatario estará obligado a eliminar de forma segura toda la información relacionada con la HCU almacenada en sus sistemas, siguiendo la normativa de protección de datos (RGPD, LOPDGDD) y las políticas de seguridad de la Conselleria. El borrado deberá ser certificado mediante un informe o declaración emitida por el adjudicatario, que garantice la eliminación completa y segura de los datos. ## Compromiso del Adjudicatario: - El adjudicatario se compromete a facilitar el retorno del servicio de la HCU y la migración a la nueva infraestructura de forma diligente y eficiente, cumpliendo con las obligaciones establecidas en esta cláusula y colaborando con la Conselleria de Sanitat para asegurar una transición sin interrupciones y la protección de los datos de los pacientes. ## 7 PLANIFICACIÓN Y GESTIÓN DEL PROYECTO El proveedor deberá presentar un plan de implantación de proyecto detallado que incluya: - Fases del proyecto: Definición clara de las fases del proyecto. - Hitos y entregables: Identificación de hitos clave y entregables específicos para cada fase del proyecto, con fechas estimadas de finalización. Es necesario que los licitadores presenten los cronogramas en los que se deben especificar los contenidos o tareas y su distribución en el tiempo para cada ASI. - Recursos asignados: Detalle de los recursos humanos y técnicos que el proveedor asignará al proyecto, incluyendo roles, responsabilidades y experiencia. Asimismo, se indicarán los precios unitarios/jornada por cada categoría profesional ofertada. - Metodología de gestión de proyectos: Descripción de la metodología de gestión de proyectos que se utilizará, incluyendo herramientas y procesos de seguimiento. - Gestión de riesgos: Identificación de los principales riesgos del proyecto y estrategias para su mitigación. - Plan de comunicación: Definición de los canales y mecanismos de comunicación entre el proveedor, el equipo del proyecto y los usuarios y grupos de trabajo clave. El adjudicatario se compromete, en todo momento, a facilitar a las personas designadas por parte de la Conselleria, la información y documentación que soliciten para disponer de un pleno conocimiento de las circunstancias en que se desarrollan los trabajos, así como de los eventuales problemas que puedan plantearse y de las tecnologías, métodos y herramientas utilizados para resolverlos. ## 7.1 Gestión del proyecto requerida por parte del adjudicatario La gestión del proyecto y el gobierno de este contrato implican la realización de una serie de actividades, reuniones, planes, informes, entregables, etc. especificados a lo largo de este documento, que deberán quedar registrados por parte de la empresa adjudicataria en el Sistema de Gestión de Proyectos TI que la CS disponga. Durante todo el ciclo de vida del contrato, a través de la gestión del proyecto por parte de la CS se realizará el seguimiento y control del proyecto, de los plazos establecidos y su progresión. Se supervisará la consecución tanto en tiempo como en forma, de manera que se garantice la correcta ejecución y logro de los objetivos del proyecto. Dentro del proyecto, el adjudicatario proporcionará todos los servicios de gestión de proyecto necesarios. Se incorporará un equipo para la gestión de proyecto con los perfiles necesarios para las tareas de Dirección, Gestión y Ejecución del proyecto. Sus funciones serán: ## Dirección y Gestión de proyecto: - Planificación global de la ejecución del proyecto incluyendo un cronograma completo y detallado por ASI. - Mantenimiento del plan de objetivos y roadmap asociados al proyecto global de implantación que serán actualizados al menos cada tres meses - Gestión de las comunicaciones para los responsables internos de las distintas actividades a realizar por la empresa. - Gestión de interacciones con los responsables de proyecto designados tanto en los servicios centrales de la Conselleria como en las Subdirecciones de Sistemas de las áreas sanitarias y hospitales donde se implante la solución. - Gestión las solicitudes de cambio según impacto y establecer prioridad con el responsable de proyecto o según criterios establecidos. <!-- image --> - Seguimiento de nivel alto de la situación de todo el proyecto. - Seguimiento y análisis de nivel alto de problemas identificados en los proyectos. - Control del nivel de servicio (SLA) de los distintos proyectos de implantación en curso y de las tareas asociadas a la garantía integral, elaborando y manteniendo los informes y cuadros de indicadores necesarios para conocer y comunicar los avances, riesgos o incidencias del proyecto. - Interlocución con las unidades funcionales. - Elaboración de informes de distinta índole, se definen los siguientes requerimientos para la elaboración de: - o Resumen de reunión: tiempo máximo de entrega una vez realizada la misma: 3 días laborables. - o Informe mensual de actividad por parte del adjudicatario: antes del 5 día laborable del mes siguiente al que hace referencia el informe. ## Control de la aplicación, integraciones de sistemas de información y entornos de despliegue: - Coordinación entre los equipos y proyectos de la Conselleria de Sanidad con los que se implementarán las integraciones. - Mantenimiento de inventario de integraciones entre aplicaciones. - Mantenimiento de inventario de dependencias operativas o funcionales con otras aplicaciones. - Coordinación de las pruebas de integración en los distintos entornos. - Gestión de peticiones de cambio o de mejora. - o Recepción de la petición. - o Análisis de la petición (estimación de coste/esfuerzo de desarrollo). - o Apoyo funcional a la definición de la petición. - o Solicitar validación del alcance y priorización de las peticiones por responsable de la Conselleria. - Gestión de cambios: - o Control de las peticiones de cambio a incluir en cada versión o configuración. - o Elaboración de documento de alcance de la propuesta de revisión. - o Actualización de la planificación de las revisiones en el directorio de proyecto - o Inclusión de control de cambios en una revisión recibida relacionando las peticiones de cambio que se incluyen en dicha versión. - o Comunicación a los servicios de soporte del cambio de versión (planificación) y entrega de la documentación asociada. - o Comunicación a sistemas afectados según dependencias operativas inventariadas. - Control del Soporte 3N de incidencias y problemas - o Análisis de la incidencia/problema escalado desde el ServiceDesk - o Escalado a proveedor de desarrollo en caso de que el responsable de proyecto no sea capaz de resolver la misma. En caso de identificarse como necesaria una petición de cambio (versión correctiva), generar petición de cambio. o ## Control de los procesos de implantación e integración de equipamiento: - Control y ejecución de las tareas necesarias para el cumplimiento de los objetivos y calendario de implantación a nivel de cada ASI. - Diseño del plan de implantación. Sometimiento a aprobación del plan de implantación a responsables de la Conselleria. - Elaboración de informe de implantación en cada centro y área sanitaria. - Elaboración de informes de seguimiento mensual que contenga: - o Seguimiento de objetivos <!-- image --> - o Detalle de implantación para unidades funcionales/centro/área - Elaboración de informes de seguimiento resumido para las unidades funcionales y propietario del proceso. - Elaboración de resúmenes de reunión y actas de acuerdos de implantación. - Gestión de las actividades para capacitación. - o Elaboración de la documentación adecuada a los roles a formar y las funcionalidades a explicar. - o Diseño y ejecución de las actividades para la capacitación del usuario final - o Capacitación para la gestión de incidencias a los equipos de Soporte y Clínica de servicios centrales TI Conselleria y de las ASI. Adicionalmente durante la ejecución de los trabajos, el adjudicatario se comprometerá en todo momento a facilitar al Equipo de Dirección y de Seguimiento Operativo del proyecto por parte de la CS, toda la información y documentación que se solicite disponer para el pleno conocimiento de las circunstancias en que se desarrollan los trabajos, la planificación de entregas, la fecha real de entregas e instalaciones, etc., además de informar y mantener al corriente de los eventuales problemas que puedan plantearse durante este, y de las tecnologías, métodos y herramientas utilizados para resolverlos en el caso que se requiera. ## 7.1.1 Metodología de trabajo Se ejecutará y gestionará el proyecto global especificado en este documento, tomando como referencia de base algunos marcos de trabajo y métodos ágiles junto con metodologías de gestión de proyectos; adaptándose en cualquier caso por parte de la empresa adjudicataria, al entorno y contexto corporativo de la CS, así como en sus normativas internas, metodología (procedimientos, procesos, plantillas, formatos, etc.) y en el uso de las herramientas corporativas de trabajo que se indiquen. En cuanto a la ejecución ágil en general, el punto de partida serán el marco de trabajo Scrum y el método Kanban. Scrum adaptado según las consideraciones del Equipo de Seguimiento Operativo o Dirección de proyecto por parte de la CS; y Kanban a considerar su conveniencia según el tipo de servicios o tareas a realizar en cada fase del contrato. ## 7.1.2 Servicios de la oficina de proyecto La empresa adjudicataria constituirá una Oficina de Proyecto, PMO (Project Management Office) para realizar el seguimiento y control de la ejecución del proyecto y de cada una de las implantaciones en los hospitales, HACLES y centros adscritos. Las principales tareas a desarrollar son las siguientes: - Presentación de un Plan de Proyecto y un Plan de calidad de los trabajos a realizar, de acuerdo con las previsiones contenidas en este pliego en coordinación con los órganos de control del proyecto previstos en el mismo. - Seguimiento, control y evaluación / auditoría del proyecto global, realizando la dirección y coordinación del resto de equipos funcionales, técnicos y de infraestructuras asociadas a la ejecución y seguimiento de las diferentes líneas de trabajo del proyecto con la finalidad de asegurar la consecución de los objetivos previstos y la correcta ejecución del proyecto. Esta actividad se llevará a cabo desde el momento de la adjudicación del contrato hasta la finalización del mismo. <!-- image --> <!-- image --> - Control del avance del proyecto y del cumplimiento del contrato, garantizando la coherencia en la planificación del proyecto de implantación y el cumplimiento de los hitos establecidos en el desarrollo e implantación de la HCU. - Identificar los riesgos y prevenir posibles desviaciones en el cumplimiento de las estimaciones de plazos del proyecto global. - Realización de los diferentes informes periódicos de seguimiento del proyecto, tanto parciales como globales, proporcionando una visión global del cumplimiento del calendario previsto y el grado de avance del proyecto. - Seguimiento y control de los ANS mediante un cuadro de mando para su seguimiento y evaluación mensual. - Gestión y mantenimiento de la documentación. ## 7.2 Herramientas para la gestión del proyecto ## 7.2.1 Gestión de la documentación Es de interés aunar y mantener la documentación de una manera reglada, de forma que permita a cualquier usuario que tenga contacto con el proyecto, poder conocer los procesos de negocio que implementa el proyecto así como las características técnicas asociadas a dicha implementación. Para ello de manera normalizada la CS proporcionará un repositorio completo y conciso, donde el contratista entregará la documentación del proyecto. La documentación asociada a cada uno de los entregables de proyecto será ubicada en dicho repositorio conforme se avance en las entregas parciales o totales de estos, y a lo largo del ciclo de vida del proyecto. Estos documentos deberán ser actualizados y entregados en todas sus sucesivas versiones, de manera que pasarán a formar parte de los entregables de versión y activos del proyecto. ## 7.2.2 Entregables y herramientas A continuación, se indica el conjunto de entregables que se deberán genera a lo largo del ciclo de vida del proyecto. Los entregables se han agrupado temporalmente según la fase en la que deben ser generados. Las herramientas que se utilizarán para las tareas de gestión documental serán: - Gestor Documental (Gestor\_Documental\_CS) proporcionado por la CS para almacenar la información en formato fichero. - Instancia de JIRA (JIRA\_CS) proporcionada por la CS para la gestión de tareas del proyecto. La instancia JIRA\_CS será la única que se considere a efectos de gestión del proyecto. No se considerará entregado ningún documento que no se encuentre almacenado en Gestor\_Documental\_CS. El cumplimiento de los Acuerdos de Nivel de Servicio (ANS) es fundamental para el éxito de este proyecto. Por lo tanto, todos los entregables del proyecto deberán cumplir con los ANS definidos en el contrato y asociados a la Documentación del proyecto. Cualquier incumplimiento podrá ser penalizado según las condiciones establecidas en el Anexo I. ## Entregables Fase de Puesta en Marcha e incio del proyecto | Actividad | Entregables | |------------------------|----------------------------------------------------------------| | Arranque | Presentación de reunión de Kick-off | | Arranque | Acta de reunión de Kick-off | | Definición de proyecto | Plan director de proyecto | | Definición de proyecto | Plan de aseguramiento de la calidad y la seguridad | | Definición de proyecto | Plan de devolución del servicio/contrato | | Definición de proyecto | Acta Aceptación de la fase Puesta en marcha (Acta de Arranque) | Entregables Fases de diseño y configuración de la solución e infraestructura, despliegue de la solución en los centros y mantenimiento Entregables asociados al proyecto completo Estos entregables deberán crearse en la primera versión del proyecto y actualizarse en todas las sucesivas versiones de los distintos componentes que se entreguen. | SUMINISTRO DE LICENCIAS Y PUESTA EN MARCHA POR HOSPITAL | SUMINISTRO DE LICENCIAS Y PUESTA EN MARCHA POR HOSPITAL | |-----------------------------------------------------------|--------------------------------------------------------------------------| | Actividad | Entregables | | Implantación HCU | Licencias HCU | | Implantación HCU | Documento de alcance | | Implantación HCU | Documento de requerimientos funcionales y técnicos | | Implantación HCU | Documento de procesos | | Implantación HCU | Flujogramas y Plan de contingencia | | Implantación HCU | Manuales de configuración, guías, procesos de arranque, etc. | | Implantación HCU | Manuales de gestión y monitorización de la solución y la infraestructura | | Implantación HCU | Pruebas de implementación | | Implantación HCU | Pruebas de interoperabilidad | | Implantación HCU | Validación paso a producción/implantación | | SERVICIOS DE SOPORTE DE PRODUCTO, MANTENIMIENTO Y GARANTÍAS | SERVICIOS DE SOPORTE DE PRODUCTO, MANTENIMIENTO Y GARANTÍAS | |---------------------------------------------------------------|---------------------------------------------------------------| | Actividad | Entregables | <!-- image --> <!-- image --> | Gestión de cambios versiones | y Licencias nuevas versiones, parches, actualizaciones menores y hotfixes Planificación de actualizaciones Entregables Ídem 'tabla de suministro y puesta en marcha' necesarios/afectados para la gestión de cambios y versiones | |--------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Asistencia técnica multicanal | Modelo de relación/uso de soporte (proceso de soporte, accesos, herramienta, contactos, horarios, etc.) Registros de soporte y consulta | | Servicios mantenimiento | de Informe trimestral de servicios realizados detallando las incidencias y consultas resueltas y pendientes | | FORMACIÓN Y CAPACITACIÓN | FORMACIÓN Y CAPACITACIÓN | |----------------------------------------------|----------------------------| | Actividad | Entregables | | Definición y ejecución del Plan de formación | Plan de formación | | Definición y ejecución del Plan de formación | Materiales de Formación | | GESTIÓN DEL PROYECTO | GESTIÓN DEL PROYECTO | |------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Actividad | Entregables | | Definición de proyecto | Plan director actualizado • El Plan director únicamente se actualizará cuando haya cambios sustanciales a nivel económico, contractual o de equipo asignado al proyecto | | Definición de proyecto | Plan de aseguramiento de la calidad actualizado y de la seguridad • El Plan de aseguramiento de la calidad únicamente se actualizará cuando hayacambiosen procedimientos operativos que impacten en el aseguramiento de la calidad del proyecto • El Plan de Aseguramiento de la Seguridad define las medidas y procedimientos para proteger la confidencialidad, integridad y disponibilidad de la información clínica almacenada en la HCU. | | Seguimiento operativo | Informe de seguimiento operativo del proyecto • Informe para las reuniones del Equipo de seguimiento operativo • Contendrá: o Indicadores de seguimiento técnico o Indicadores de seguimiento del plan de implantación o Indicadores de seguimiento del plan de formación o Indicadores de seguimiento del plan de comunicación | <!-- image --> | | o Indicadores de seguimiento de aseguramiento de la calidad y de a seguridad o Seguimiento de planificación actualizada o Seguimiento de riesgos del proyecto | |-------------------------|-----------------------------------------------------------------------------------------------------------------------------------------------------------------| | | Acta de seguimiento operativo | | Seguimiento económico | Informe de seguimiento económico y ANS | | Seguimiento económico | Acta de seguimiento económico | | Secretaría del proyecto | Actas de reuniones | | DOCUMENTACIÓN | DOCUMENTACIÓN | |-----------------------------------------------------------------|---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Actividad | Entregables | | Actualización de la documentación asociada al proyecto completo | Versiones actualizadas de: • Documento de análisis completo • Documento de diseño completo: Documentación detallada del modelo de datos separado por componentes o módulos con descripción de los campos, tablas, etc. • Documento de negocio: Este documento permitirá describir de una manera general los distintos procesos que el sistema implementa • Documento de arquitectura: Descripción detallada de la arquitectura de cada módulo de la aplicación • Documento de infraestructura desplegada: Detalle de la infraestructura requerida en el proyecto • Documento de integraciones: Contiene descripción de todas las integraciones del proyecto descritas de la perspectiva técnica y | | Actividad | Entregables | |-----------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Actualización de la documentación asociada al proyecto completo | Versiones actualizadas de: • Documento de análisis completo • Documento de diseño completo: Documentación detallada del modelo de datos separado por componentes o módulos con descripción de los campos, tablas, etc. | <!-- image --> | • Documento de negocio: Este documento permitirá describir de una manera general los distintos procesos que el sistema implementa. • Documento de arquitectura: Descripción detallada de la arquitectura de cada módulo de la aplicación. • Documento de infraestructura desplegada: Detalle de la infraestructura requerida en el proyecto. • Documento de integraciones: Contiene descripción de todas las integraciones del proyecto descritas de la perspectiva técnica y funcional. • Documento de migraciones: Contiene descripción de todas las migraciones del proyecto descritas de la perspectiva técnica y funcional. | |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| ## Entregables Fase de finalización del contrato | Actividad | Entregables | |------------------------------------------------|-------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------| | Comprobación de entrega de documentación | Acta de la existencia y corrección de la siguiente documentación en el repositorio documental: • Procedimientos de trabajos establecidos • Todos los activos documentales del proyecto: o Documentación asociada a cada entrega o Versiones actualizadas de la documentación asociada al proyecto • Manuales de usuario actualizados (tanto en la aplicación como en documentación) • Descripción detallada de los archivos y propiedades de configuración del sistema • Descripción e instrucciones de despliegue de los diferentes componentes de sistema | | Comprobación de Documentación | Situación del sistema de información al final del contrato: • Trabajos en curso • Solicitudes de cambios pendientes | | Sesiones de capacitación (técnica y funcional) | Acta de sesiones de transferencia de conocimiento | | Aceptación | Acta de aceptación de la Fase de devolución del servicio | ## 7.2.3 Gestión de la calidad El proceso de Gestión de la Calidad es un proceso continuo que abarca todo el ciclo de vida del contrato y que persigue la excelencia y mejora continua de los procesos, productos y servicios. El objetivo es el aseguramiento de la calidad del proceso y de la solución de HCU. <!-- image --> La supervisión de este proceso corresponde al responsable de calidad del adjudicatario, en coordinación con su homólogo del responsable del proyecto por parte de la CS. El adjudicatario elaborará en la fase de Toma de Servicio un Plan de Aseguramiento de la Calidad y la seguridad que contiene las tareas que tiene previsto realizar para cumplir dicho objetivo. Entregará la primera versión del plan durante la fase de Toma de servicio, y será aprobado por el Comité de Dirección. Una vez aprobado, el adjudicatario es el responsable de ejecutarlo en contenido y plazo. Cada vez que la CS lo exija o cuando el adjudicatario lo considere conveniente, el Plan de Aseguramiento de la Calidad y de la Seguridad y será actualizado y sometido a una nueva aprobación en el siguiente comité. El plan contendrá las métricas, ANS e indicadores (KPIs) a recabar. Para cada métrica se establecerán umbrales sobre los cuales han de permanecer los indicadores, los hitos en los que se obtendrán las métricas y las acciones correctoras que se aplicarán si los valores obtenidos están fuera de los umbrales previstos. También se establecerán las auditorías a practicar y su contenido. Las métricas y auditorías tendrán en cuenta, entre otras, las siguientes características: - El conocimiento del servicio, - La calidad de los entregables y productos, - Lo ajustado de las estimaciones, - La formación y experiencia de los equipos de trabajo, - Las actividades preventivas frente a las reactivas, - La satisfacción de las personas que solicitan los servicios. ## 8 LICENCIAS Se considera incluida una licencia de software de la HCU de naturaleza corporativa , la cual conferirá el derecho irrevocable y sin limitación temporal para utilizar la versión específica del software, una vez desplegada al término del contrato, sin necesidad de abonar cuotas recurrentes por concepto de licencia para dicha versión . Se entiende por corporativa aquella licencia cuyo ámbito de uso abarca cualquiera de las ocho agrupaciones sanitarias interdepartamentales, incluyendo hospitales y los diferentes centros adscritos a las ASIs y los HACLES de la Comunidad Valenciana En relación con el licenciamiento del sistema ofertado, se deberá cumplir: - El número de usuarios concurrentes: ilimitado . No existirá límite superior en cuanto al número posible de usuarios concurrentes que simultáneamente accedan a la HCU. - Durabilidad de la licencia: El adjudicatario suministrará siempre la última versión de software de su solución. Una vez finalizado el período contractual, los hospitales y centros objeto de esta licitación deberán tener implantada la última versión de software de la solución de HCU. La Administración adquirirá, como parte del presente contrato, el derecho irrevocable y sin limitación temporal para continuar utilizando dicha versión específica del software en los centros mencionados, sin que ello devengue costes adicionales por concepto de licenciamiento para la versión desplegada al finalizar el contrato. - Durante el periodo de garantía se deberá actualizar la versión del software de HCU implantada en caso de que se detecten incidencias y problemas en su uso. La licencia universal de la última versión de software de la HCU integrará todos los componentes de software base necesarios para su completa instalación y correcto desempeño, sin necesidad de proporcionar licencias adicionales (licencias de sistemas operativos, licencias de servidor de base de datos, licencias de sistemas de virtualización y/o licencias de herramientas de explotación de datos).El suministro de esta licencia da derecho al conjunto de ámbitos, módulos, funcionalidades e integraciones que contiene la última versión del software del producto propuesto. <!-- image --> No se admitirán propuestas que consideren como elementos adicionales, con coste separado o como licencias complementarias, aquellos componentes o servicios que sean esenciales para la instalación, despliegue, puesta en marcha y correcto funcionamiento operativo de la solución de HCU, en cumplimiento de los requisitos de este pliego. Todo lo necesario para el funcionamiento integral de la HCU se considerará parte intrínseca de la oferta. A efectos de garantizar la trazabilidad y el control patrimonial, todos los componentes hardware, software y licencias que formen parte de la solución HCU, deberán ser debidamente inventariados, con identificación única, descripción detallada y, en su caso, número de serie, y entregados a la administración en formato editable. ## 9 GARANTÍA INTERAL DE LA SOLUCIÓN El adjudicatario garantizará, durante el período de garantía establecido, el correcto funcionamiento del software suministrado de HCU (incluyendo todos sus módulos, componentes e interfaces), conforme a las especificaciones técnicas y funcionales descritas en este pliego, en la documentación anexa y en los Acuerdos de Nivel de Servicio (ANS) que formen parte del contrato. Esta garantía comprenderá, como mínimo: - La corrección, sin coste adicional para la Administración, de cualquier error, defecto o fallo de funcionamiento que se detecte en el software. - La provisión de actualizaciones y nuevas versiones del software que sean necesarias para corregir errores, mejorar la funcionalidad, garantizar la seguridad o asegurar el cumplimiento de la normativa aplicable. - El soporte técnico necesario para la resolución de incidencias y dudas relacionadas con el uso del software. - El cumplimiento de los niveles de servicio definidos en los ANS El tiempo de garantía será de 24 meses a contar desde la validación del 100% de la implantación y validación del sistema en todos los hospitales de la Comunitat Valenciana. Durante el periodo de garantía se cumplirán los siguientes requisitos: - El adjudicatario deberá disponer de un modelo de aplicación de la garantía integral que dé respuesta eficazmente a las averías y paradas no programadas de la HCU, que componen este suministro, que actuará durante todo el período de garantía ofertado. - El incumplimiento de los parámetros mínimos indicados en este PPT o de las mejoras ofertadas por el licitador en su caso, darán lugar a las penalizaciones correspondientes que se indican en el Pliego de Cláusulas Administrativas que rigen esta contratación. - El modelo de aplicación de la garantía integral proporcionado deberá permitir un funcionamiento permanente del sistema con un nivel de interrupción mínimo o nulo. - Para cumplir estas obligaciones, el adjudicatario deberá disponer de este servicio, con servicio de localización permanente (email, sistema de localización, teléfonos, centro de atención telefónica, y cualquier otro necesario) y dotado de adecuado y suficiente personal con la cualificación técnica y profesional adecuada y con los medios materiales pertinentes. El modelo de Garantía Integral deberá al menos disponer de: ## 9.1 Canales de Comunicación para la recepción y registro de incidencias El adjudicatario tendrá que mantener un registro estructurado con toda la información relativa a las incidencias y solicitudes. Este registro deberá ser accesible, sin coste adicional, para la Conselleria con el objetivo de facilitar el seguimiento de los acuerdos de niveles de servicio. La gestión de las incidencias se realizará a través de la herramienta corporativa de gestión de incidencias y peticiones de la Conselleria y/o vía telefónica, pudiendo ser usado como medio alternativo el correo electrónico ante cualquier problema de la plataforma corporativa, si bien en estos dos últimos casos el adjudicatario siempre ha de registrar posteriormente en la plataforma la incidencia comunicada. El adjudicatario deberá facilitar una dirección de correo y un número de teléfono que estarán en funcionamiento según lo indicado en el apartado horarios del soporte. El proveedor garantizará durante la duración del contrato, la asistencia técnica durante las 24 horas del día, 7 días a la semana, incluyendo festivos (24x7x365). <!-- image --> <!-- image --> La resolución de incidencias, a ser posible, será inmediata siendo este canal el utilizado principalmente para resolver dudas en el uso de sus funcionalidades. Una vez que la empresa registre la resolución de la incidencia junto con información sobre las actuaciones y procedimientos seguidos para tal fin, será la encargada de cerrarla tras la confirmación con el usuario. La empresa adjudicataria creará y mantendrá un documento con un histórico de todas las incidencias que se produzcan ('Documento de Incidencias') y que al menos, detallará la siguiente información para cada una de ellas: - Código de identificación de la incidencia - Fecha y hora de apertura de la incidencia - Fecha y hora de resolución de la incidencia - Descripción detallada del error - Descripción detallada de la solución adoptada. En el caso de las solicitudes el adjudicatario deberá registrar la siguiente información: - Código de identificación de la solicitud - Fecha y hora de apertura de la solicitud - Fecha y hora de entrega de solución propuesta - Descripción detallada de la solicitud - Descripción detallada de la solución propuesta. - Valoración de la solución propuesta Mensualmente, y siempre que así lo requiera la dirección del proyecto durante la duración del contrato, la empresa adjudicataria facilitará este 'Documento de incidencias' . ## 9.2 Soporte correctivo Soporte correctivo es la actividad consistente en diagnosticar y solucionar incidencias de funcionamiento de la solución tratada en el pliego, así como las integraciones con dispositivos u otros sistemas de información. Las incidencias pueden ser debidas a errores en el código fuente, de integración o en la interacción de este software básico (base de datos, servidor de aplicaciones, sistemas operativos, etc.). Las incidencias se clasificarán según dos parámetros Impacto y Urgencia , y cuyos valores se muestran en las tablas siguientes. - Impacto, definido como la importancia del incidente dependiendo de cómo éste afecte a los procesos de negocio y/o del número de usuarios afectados. - Urgencia, definida como rapidez necesaria para resolver la incidencia. | IMPACTO | Descripción | Aplicación | |-----------|---------------|--------------| <!-- image --> | Grave o Crítico | Incidentes en producción que afecta a algún sistema de información crítico: • HCU • Aplicaciones centralizadas: SIA, integración entre SIA-Laboratorio online a través de Rhapsody, GAIA, SIP, LOGIS, CRC, NOMINA, CSPORTALES, App Salut. • Aplicaciones distribuidas: ORION CLINIC, ORION RIS, HIGIA, IRIS, ALTAHOSPITALARIA, DEIMOS. • Servicios del puesto de trabajo con afectación masiva (Correo, Directorio Activo, DNS, Servidor de ficheros, Antivirus...). | APLICA | |-------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|----------| | Significativo | Incidentes en producción que afectan a uno o más sistemas de información con menor orden de criticidad: • Aplicaciones centralizadas y distribuidas no críticas. • Servicios médicos de urgencia al paciente: mostrador de urgencias y admisión, controles de enfermería, estaciones de radiólogos y quirófanos. | APLICA | | Moderado | Incidentes que afectan a: • Aplicaciones centralizadas y distribuidas que afectan a entornos de PRE, TEST y FOR. • Servicios médicos ofrecidos al paciente: mostrador de Centros de Salud y especialidades y facultativos. | APLICA | | Menor | Incidentes en producción que afectan a servicios administrativos del personal sanitario: administrativo, aulas, informático y portable. | APLICA | | URGENCIA | Descripción | Aplicación | |------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|---------------|--------------| | Pérdidas de servicio total sin alternativa de solución para el usuario, impidiendo el uso y funcionamiento de las aplicaciones necesarias para desempeñar su trabajo. | APLICA | Urgente | | Degradación del servicio sin alternativa de solución para el usuario, impidiendo el uso y funcionamiento de las aplicaciones necesarias para desempeñar su trabajo. | APLICA | Muy rápido | | • Incidentes que impiden realizar con normalidad ciertas funciones principales del usuario. • Pérdidas de servicio total o degradación del servicio con alternativa de solución. • Servicio degradado sin afectar a usuario. | APLICA | Rápido | | • Incidentes que impiden realizar con normalidad ciertas funciones no principales del usuario. • Incidentes sin impacto en el servicio. | APLICA | Pronto | <!-- image --> Una vez tipificada la incidencia según los dos parámetros, esta se registrará en el Sistema de Gestión de Servicios TI asignándole la prioridad en base a la siguiente matriz de prioridades de incidentes. Ilustración 9. Matriz impacto y urgencia de posibles incidentes | | | URGENCIA | URGENCIA | URGENCIA | URGENCIA | |---------|-----------------|------------|------------|------------|------------| | | | Urgente | Muy rapido | Rapido | Pronto | | IMPACTO | Grave o critico | | 一 | 2 | 3 | | IMPACTO | Significativo | 2 | 2 | 3 | 4 | | IMPACTO | Moderado | 2 | 3 | 4 | 4 | | IMPACTO | Menor | 4 | 4 | 4 | 4 | Los tiempos de resolución asignados son los siguientes: - Prioridad 1: El tiempo de resolución debe ser inferior a 2 horas. - Prioridad 2: El tiempo de resolución debe ser inferior a 4 horas. - Prioridad 3: El tiempo de resolución debe ser inferior a 12 horas. - Prioridad 4: Según disponibilidad, pero en ningún caso será superior a 1 mes. El proveedor diagnosticará las incidencias, diseñará una solución y preparará una revisión correctiva del módulo afectado. El proveedor procederá a la implantación inmediata de las correcciones de errores detectados. Las tareas de mantenimiento y soporte se prestarán in situ, siempre que ésta se considere que es la única vía para la resolución de la incidencia. El adjudicatario facilitará listados mensuales informativos en el que se indiquen las incidencias y las intervenciones realizadas del mes. ## 9.3 Soporte preventivo Con periodicidad semestral, se realizará una comprobación de la configuración general de la aplicación, así como una revisión general del funcionamiento del sistema, con el fin de prevenir posibles fallos de éste. También se realizará un soporte preventivo de tablas y estructuras de la Aplicación. ## 10 ACUERDO DE NIVEL DE SERVICIO (ANS) Se establecen un conjunto de Acuerdos a Nivel de Servicio (en adelante ANS), con niveles de cumplimiento que serán objeto de seguimiento para garantizar la calidad del proyecto y de los servicios prestados. De esta forma, se definen los indicadores de niveles de servicio para establecer una base objetiva y medible para el control de los servicios y la mejora de estos. El adjudicatario deberá cumplir con unos niveles de calidad que garanticen la eficiencia de las tareas y la calidad del servicio de soporte que se proporcione, así como la adecuada implantación de la herramienta de cada centro en el sistema corporativo. Los niveles de servicio establecidos como requisitos tienen carácter de mínimos y deberán ser aceptados o mejorados por el licitador. Su medición comenzará en el momento del inicio de la prestación de los servicios del Centro. Los indicadores de ANS que figuran en este contrato podrán ser revisables por parte de la Conselleria de Sanidad, a lo largo del periodo de vigencia de este, tanto en la descripción, valores de referencia, o incluso añadir nuevos indicadores, siempre con el objetivo de mantener los niveles de calidad requeridos para la prestación del servicio. Los Niveles de Servicio Mínimos en los sistemas suministrados por el contratista serán los siguientes: ## 10.1.1 Tiempos de respuesta a incidencias o peticiones El tiempo de respuesta para cualquier tipo de incidencia o petición escalada por el hospital no será superior a 30 minutos. ## 10.1.2 Tiempos de resolución Estos tiempos se establecen en función de la prioridad que se le asigne en el momento de la comunicación de la incidencia a partir de la notificación de esta a través de cualquiera de los cauces acordados: | Prioridad | Incidencia | Tiempo máximo de resolución | |----------------------------|------------------------------------------------------------|-------------------------------| | Prioridad 1 - Muy urgente | Interrupción del sistema sin alternativa de funcionamiento | 2 horas | | Prioridad 2 -Urgente | Interrupción del sistema con alternativa de funcionamiento | 4 horas | | Prioridad 3 - (No urgente) | Incidencias que no impidan el trabajo de los usuarios | 12 horas | Los servicios destinatarios podrán realizar consultas referentes al estado de las incidencias al adjudicatario, cuyo tiempo de respuesta no podrá ser superior a 48 horas. La catalogación de la gravedad será competencia del responsable de la Unidad en el momento en el que se produzca la incidencia, y en ningún caso la empresa adjudicataria será la que clasifique el tipo de gravedad. En el caso de las solicitudes el tiempo de respuesta para presentar la solución y valoración propuesta no podrá exceder los 15 días naturales. <!-- image --> ## 10.1.3 Tiempos de respuesta de la aplicación | Indicador 1 | Descripción del indicador | Nivel permitido | Nivel objetivo | Periodicidad | |---------------------------------------------|-------------------------------------------------------------------|-------------------|------------------|----------------| | Tiempo medio de respuesta de la aplicación | Tiempo medio de respuesta de la aplicación en cualquier operación | 1 segundo | 0,5 segundo | A petición | | Tiempo máximo de respuesta de la aplicación | Tiempo de respuesta de la aplicación en cualquier operación | 5 segundos | 2 segundos | A petición | Estos tiempos se medirán en condiciones normales de funcionamiento de la red de datos que proporcione la CS. ## 10.1.4 Disponibilidad de la solución de HCU | Indicador | Descripción del indicador | Tipo | Nivel permitido | Periodicidad | |-------------------------------------|-----------------------------|---------|-------------------|----------------| | Aplicación en horario de criticidad | Disponibilidad | Crítico | 99,50% | Diario | | Aplicación en horario de criticidad | Máximo número de paradas | Crítico | 2 | Trimestral | | Aplicación en horario no crítico | Máximo número de paradas | Otros | 4 | Trimestral | | | Máximo tiempo de paradas | Otros | 1 hora | Trimestral | | | Máximo acumulado anual | Otros | 2 horas | Trimestral | ## 10.1.5 Mantenimiento correctivo Modificaciones necesarias para corregir errores del producto. Los niveles de servicio que deberán cumplirse son: | Indicador | | Descripción del indicador | Tiempo de resolución | Nivel permitido | Periodicidad | |------------------------------------|----|------------------------------------------------------------------------------------------------------------------------------------|-----------------------------------|-------------------|----------------| | Resolución incidencias prioridad A | de | % de incidencias resueltas en plazo asignado desde la notificación por la unidad de soporte a usuarios o detectadas proactivamente | Menos de 3 horas | 100% | Mensual | | Resolución incidencias prioridad B | de | % de incidencias resueltas en plazo asignado desde la notificación por la unidad de soporte a usuarios o detectadas proactivamente | Menos de 5 horas Menos de 8 horas | 90% 100% | Mensual | | Resolución incidencias prioridad C | de | % de incidencias resueltas en plazo asignado desde la notificación por la unidad de soporte a usuarios o detectadas proactivamente | Menos de 2 horas Menos de 6 horas | 85% 100% | Mensual | <!-- image --> <!-- image --> | Reincidencias | % de incidencias resueltas en plazo asignado desde la notificación por la unidad de soporte a usuarios o detectadas proactivamente | Menos de 6 días | 5% | Mensual | |-----------------|--------------------------------------------------------------------------------------------------------------------------------------|-------------------|------|-----------| - Prioridad A: Interrupción de un servicio sin alternativa de funcionamiento. - Prioridad B: Degradación o interrupción de un servicio que tiene alternativa de funcionamiento. - Prioridad C: Degradación del servicio, pero no impide el trabajo de los usuarios. - El no funcionamiento de las integraciones con otros sistemas se considerará como resolución de incidencia de prioridad A. - En caso de discrepancia será la Conselleria de Sanidad quien determine el nivel de prioridad atendiendo a las definiciones anteriores. ## 10.1.6 Mantenimiento evolutivo El adjudicatario determinará el tratamiento a dar a las necesidades de mantenimiento evolutivo que la Conselleria de Sanidad solicite durante el período de implantación de la solución en sus centros, y establecerá un marco de garantía de cobertura de estas. La toma de requerimientos y análisis funcional de las diferentes peticiones serán realizadas por un consultor experto del adjudicatario en la solución. Dentro del mantenimiento evolutivo de la aplicación el adjudicatario se compromete mantener su producto actualizado a la última versión. El adjudicatario deberá describir en su oferta, su política de actualizaciones. La empresa adjudicataria se compromete a aplicar las mejores prácticas en la puesta en producción de nuevas versiones, parches o nuevos desarrollos de la aplicación, entre ellas la aplicación de pruebas de carga y stress, la validación funcional y técnica del producto y la correcta gestión del cambio para cada una de ellas, así como la correcta documentación de todos estos procesos que será presentada puntualmente a la dirección del proyecto como condición previa a la validación de dicho cambio de versión. La calidad del mantenimiento evolutivo será medida en función del siguiente cuadro, donde, de acuerdo con los plazos acordados entre la Conselleria de Sanidad y el adjudicatario, se evaluarán los % de cumplimiento que se detallan a continuación: | Modificaciones planificadas | Nivel permitido | |-------------------------------|-------------------| | En plazo acordado | 90% | | Con desvío del 20% | 100% | | Modificaciones urgentes | Nivel permitido | | En menos de una semana | 80% | | En menos de 2 semanas | 85% | |-------------------------|-------| | En menos de 4 semanas | 90% | El proveedor se compromete a desarrollar e implementar las nuevas funcionalidades priorizadas por la Conselleria, de acuerdo con el roadmap y el plan de desarrollo acordado. El plazo máximo de implementación será de: | Desarrollo nuevas funcionalidades priorizadas desde la Conselleria | Nivel permitido | |----------------------------------------------------------------------------|-------------------| | Adaptaciones normativas, mejoras rendimiento, usabilidad y accesibilidad | 6 meses | | Incorporación nuevos ámbitos y funcionalidades (de media o baja prioridad) | 9 meses | | Incorporación nuevos ámbitos y funcionalidades complejas | 12 meses | ## 10.1.7 Compromiso de adecuación de las funcionalidades | Indicador | Unidad de medición | Nivel permitido | Frecuencia | |--------------------------------------|--------------------------------------------------------------------------------------------------------------|-------------------|--------------| | Implantación completa de la solución | % de funcionalidades que requieren adecuación para cumplir las funcionalidades existentes en los SI actuales | 100% | Mensual | El adjudicatario se compromete a informar a la Conselleria de Sanitat de forma periódica en cada uno de los comités de implantación sobre el estado y avance de las adecuaciones o desarrollos de nuevas funcionalidades requeridas y pendientes de implementar. Estas modificaciones serán las que queden reflejadas en el Anexo I y sobre las que el adjudicatario se comprometerá a incluir en la solución de HCU. Para la fecha prevista de implantación en el primer hospital, la versión de la solución a desplegar deberá estar cerrada, es decir, todas las adecuaciones y nuevas funcionalidades deberán estar completamente desarrolladas, implementadas y validadas. ## 10.1.8 Control y cumplimiento de las prestaciones adicionales | Indicador | Unidad de medición | Nivel permitido | Frecuencia | |---------------------------------------------------------------------------|------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------|-------------------|--------------| | Implantación de prestaciones adicionales propuestas en la memoria técnica | % de ámbitos, módulos y funcionalidades de prestaciones adicionales propuestas, priorizadas por el Comité de Dirección del proyecto e implantadas durante la vigencia del contrato | 100% | Semestral | El adjudicatario se compromete a informar a la Conselleria de Sanidad del estado y avance del despliegue de las prestaciones adicionales propuestas y priorizadas en la fase 1 del proyecto. <!-- image --> ## 10.1.9 Documentación del proyecto Son una serie de indicadores que pretenden medir que la documentación del proyecto esté disponible en tiempo y sea convenientemente actualizada. - IC\_ENTR\_INF : Entrega de Informes y documentación - o N.º de informes y documentos entregados fuera del plazo fijado - IC\_RECH\_INF : Rechazo de informes o documento - o Veces que un informe o documento es rechazado más de una vez por información imprecisa o incorrecta - IC\_INCO\_REU : Incomparecencia a reunió - o Incomparecencia del adjudicatario a las reuniones convocadas, sin justificación previa y aprobación de cambio de fecha de la reunión. - IC\_HERR\_NA : Herramienta de gestión no actualizada - o Grado de avance de los proyectos no actualizado en la herramienta de gestión. | Indicador | Valor objetivo | Cumplimiento | Incumplimiento | Periodicidad | |-------------|---------------------|---------------------|---------------------|----------------| | C_ENTR_INF | 0 informes/docs. | <=0 informes/docs | >0 informes/docs. | Mensual | | IC_RECH_INF | 0 informes/docs. | <=0 informes/docs. | >0 informes/docs. | Mensual | | IC_INCO_REU | 0 incomparecencias | 0 incomparecencias | >0 incomparecencias | Mensual | | IC_HERR_NA | Actualizado al 100% | Actualizado al 100% | Actualizado al 100% | Mensual | ## 10.1.10 Gestión administrativa del contrato Este indicador pretende medir el retraso en la presentación de la factura, una vez que la ejecución de un trabajo facturable ha sido finalizada y aceptada. El retraso se medirá en días naturales desde la reunión en la que se aprueba el Informe de Seguimiento Económico de un periodo de facturación hasta el correcto registro de la factura en FACe (Punto General de Entrada de Facturas Electrónicas). | Indicador | Valor objetivo | Cumplimiento | Incumplimiento | Periodicidad | |-----------------------------------|------------------|----------------|------------------|----------------| | Plazo de presentación de facturas | <= 30 días | <= 30 días | > 30 días | Trimestral | <!-- image --> ## 11 ANEXO A continuación, se enumeran los anexos disponibles que se mencionan a lo largo del presente documento. - Anexo I -Cobertura funcional. - Anexo II -Estructura organizativa y volumetría hospitales. - Anexo III -Mapa aplicaciones de la Conselleria y APIS de integración. - Anexo IV -Datos a migrar. - Anexo V -Procesos clínico-asistenciales y administrativos. - Anexo VI -Procesos a valorar como prestaciones adicionales. València, a fecha de la firma electrónica. LA SUBDIRECTORA GENERAL DE ASISTENCIA SANITARIA LA JEFA DEL SERVICIO DE APLICACIONES PARA ASISTENCIA SANITARIA <!-- image -->