Informe de valoración de los criterios de adjudicación cuan… - Recogida de señales electromédicos en e…

VALORACIÓN PARA LA LICITACIÓN DE LA CONTRATACIÓN DE UN SISTEMA CORPORATIVO PARA LA RECOGIDA DE SEÑALES DE EQUIPOS ELECTROMÉDICOS EN EL SERVICIO - NEXTGENERATIONEU ARAGONÉS DE SALUD EN EL MARCO DEL PLAN DE RECUPERACIÓN, TRANSFORMACIÓN Y RESILIENCIA FINANCIADO POR LA UNIÓN EUROPEA - Nº Expediente: SAN-2025-20077 Valoración de Ofertas Técnicas     Departamento de Sanidad El presente informe tiene por objeto la valoración técnica de las ofertas presentadas, conforme a los criterios de adjudicación sujetos a juicio de valor establecidos en el Pliego de Cláusulas Administrativas Particulares y en el Pliego de Prescripciones Técnicas, en particular los descritos en el Anexo X correspondiente a criterios técnicos.   La valoración se realiza exclusivamente sobre la documentación técnica presentada por los licitadores, sin referencias ni comparaciones entre ofertas, y atendiendo a los criterios y ponderaciones fijados en el pliego. Se procede a la valoración técnica de las ofertas presentadas por las siguientes firmas licitadoras: -  UTE T-Systems - Bettercare, en adelante TSYSBET -  UTE VITALERA-PRHOINSA, en adelante PROVITA -  DEXTRO -  UTE VITIO-HIBERUS, en adelante VITHIB ## 1. Solución Propuesta: - 1.1. Características del Servicio de Consultoría-Análisis de situación (Punto 4.1 PPT). Hasta 3 puntos -  TSYSBET (apartado 1.1 de su oferta) La propuesta desarrolla de forma completa el servicio de consultoría y análisis de situación, garantizando una comprensión clara del entorno actual del Servicio Aragonés de Salud. Se describen una metodología el servicio de consultoría, integrando análisis clínico, técnico y organizativo: las actividades relativas a la definición de necesidades técnicas, funcionales y de seguridad, el análisis de interoperabilidad, los criterios de accesibilidad y usabilidad, la identificación de arquetipos clínicos y flujos de trabajo, el desarrollo de guías de integración, la identificación de requisitos de seguridad y la definición de indicadores y métricas. Se detalla para cada línea de trabajo, su principal impacto, la relación con los entregables y el valor generado, tanto para el proyecto, como para el Servicio Aragonés de Salud. Se valora el desarrollo este apartado en la oferta de TSYSBET con: 3 puntos sobre 3 posibles -  PROVITA (apartado 4.1 de su oferta)   La oferta incluye el servicio de consultoría y análisis de situación, describiendo de manera breve, las actividades para determinar el punto de partida del Servicio Aragonés de Salud. Se identifican los aspectos a abordar sobre interoperabilidad, arquitectura, usabilidad y KPIs. El desarrollo es adecuado, aunque se identifica margen de mejora en la concreción técnica y metodológica de todas las actividades previstas en el PPT. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 2 puntos sobre 3 posibles -  DEXTRO (apartado 1.2 de su oferta) La propuesta de consultoría ofertada presenta un alto grado de adecuación a los requisitos del PPT. Se describen de forma detallada las actuaciones a realizar, así como las características generales, funcionales, técnicas y de interoperabilidad, incluyendo integración mediante estándares (HL7, FHIR, CDA, IHE), normalización semántica y mecanismos de integración con sistemas corporativos. Se aporta, como valor añadido, un servicio diferencial de consultoría clínica colaborativa, lo que establece una base sólida para una implantación segura, escalable y sostenible. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 3 puntos sobre 3 posibles -  VITHIB (apartado 1.1 de su oferta) La oferta describe de manera detallada las actividades a desarrollar durante la fase de consultoría y análisis inicial de situación, incluyendo alcance y contexto estratégico: identificación de necesidades técnicas, funcionales y de seguridad, el análisis de la interoperabilidad de los sistemas existentes, la definición de criterios de accesibilidad y usabilidad, la identificación de arquetipos clínicos y flujos de trabajo, así como el establecimiento de mecanismos de integración con los sistemas corporativos, conforme a lo indicado en el PPT. Asimismo, se concretan los KPIs y los entregables correspondientes a la Fase 1, alineados con lo indicado en el PPT. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 3 puntos sobre 3 posibles - 1.2. Características de la herramienta de la plataforma ofertada: (Punto 4.2 PPT). Hasta 23 puntos, con el siguiente desglose  ## 1.2.1. Características generales de la solución (hasta 3 puntos) -  TSYSBET (apartado 1.2 de su oferta) La plataforma propuesta da respuesta integral al alcance del proyecto: una solución que se estructura en bloques funcionales complementarios, con una arquitectura modular, abierta y escalable. Ofrece una solución funcional robusta y bien diseñada, con enfoque claramente agnóstico, buena gestión y catalogación de datos/señales, interfaces profesionales avanzadas, portal de paciente funcional y capacidades de evaluación e indicadores bien resueltas. La gestión de alertas y la comunicación entre actores están presentes. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 3 puntos sobre 3 posibles -  PROVITA (apartado 4.2.1 de su oferta) La solución propuesta describe de forma estructurada las capacidades generales de la plataforma en sus distintos ámbitos, incluyendo interoperabilidad e integraciones, y aporta enlace a vídeo demostrativo. El enfoque es coherente y viable, si bien el nivel de detalle técnico observable presenta margen de mejora en algunos subapartados. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 3 posibles -  DEXTRO (apartado 1.3 de su oferta) Se describen una visión general de la plataforma, las capacidades generales de la plataforma, su arquitectura en capas y su enfoque modular orientado a procesos clínicos. La interoperabilidad descrita y su integración nativa con los componentes de Philips hacen que se garantice un flujo clínico continuo entre el entorno domiciliario y hospitalario y coherencia en el registro clínico. Se indican referencias y protocolos ya diseñados, lo que facilitaría la implantación. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 3 puntos sobre 3 posibles -  VITHIB (apartado 1.2.1 de su oferta)    Se hace un breve resumen de una solución dual formada por dos plataformas que forman un ecosistema único formando una propuesta modular, distribuída y escalable. Si bien es cierto que la solución propuesta cumple íntegramente todos los requisitos del apartado 4.2.1 del PPT, no queda del todo clara la unificación funcional de ambas soluciones. La visualización de ambas en HCE es factible pero no asegura una integración total. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 1 puntos sobre 3 posibles ## 1.2.2. Características funcionales de la solución (hasta 6 puntos) -  TSYSBET (apartado 1.2.4 de su oferta) La oferta presenta un grado de adecuación muy alto a los requisitos funcionales del apartado 4.2.2 del PPT, con una descripción especialmente estructurada por componentes (plataforma IoMT, visores, concentradores, integración cloud, alertas, portal profesional, portal paciente, comunicación e indicadores). Se realiza una descripción muy bien detallada de cada uno de los componentes que permite: visualización en tiempo real de la monitorización del paciente, revisión retrospectiva en alta resolución, gestión clínica transversal del paciente en todo el recorrido asistencial, monitorización domiciliaria y soporte al seguimiento del paciente en domicilio, cumpliendo de forma general con el enfoque de continuidad asistencial y con los requisitos de solución agnóstica y multiusuario, incluyendo además modularidad para escalabilidad a nuevas patologías y unidades. En relación con la plataforma de recogida de señales (IoMT), se detalla la captura multifuente (señales continuas, parámetros discretos, cuestionarios/escalas, datos introducidos por el paciente, eventos/anotaciones) y se explicita la independencia de fabricante, el soporte de múltiples conectividades y protocolos, la capacidad de incorporar nuevos drivers bajo disponibilidad de equipo de muestra y la identificación de ubicación/entorno (hospital/servicio/domicilio). También se menciona la captación y gestión de ondas en alta resolución (200 Hz) y se remite al entorno tecnológico propuesto para el dimensionamiento/escala, lo que cubre el requisito de alta resolución, si bien parte del detalle arquitectónico queda referenciado a otro apartado (no íntegramente desarrollado dentro del bloque funcional). Respecto a los visores de monitorización, la oferta aporta un nivel de adecuación sobresaliente al enumerar y posicionar herramientas específicas: BC Mview y BC Workstation para visualización en tiempo real y retrospectiva de ondas en alta resolución, BC Tracker para visión discreta/gestión de camas e información relevante (incluidos scorings) y BC Home para el entorno domiciliario. Se describe su carácter web, multidispositivo y accesible mediante accesos securizados, la capacidad de visualización multifabricante y la centralización simultánea de múltiples camas, alineándose con los requisitos del PPT (multiseñal, personalizables, ondas hemodinámicas, multi-cama, embebibles y accesibles). Adicionalmente, se declara de forma expresa que BC Link, BC Mview y BC Workstation disponen de certificado CE clase IIb para uso en monitorización continua, punto crítico exigido por el pliego.  En cuanto a concentradores (software y hardware) e integración con nubes de proveedores, la oferta cubre de manera completa ambos bloques: describe el concentrador software como habilitador de integración multivendor sin hardware adicional cuando hay conectividad de red, soportando estándares (HL7, FHIR, IEEE11073, DICOM, API REST, etc.) y permitiendo gestión operativa (monitorización de incidencias, alertas de desconexión). Para el concentrador hardware, se especifica que no es requisito intrínseco salvo necesidad por falta de conectividad, pero se propone su incorporación con persistencia local, batería, gestión remota e interfaces sencillas; además, se concreta el rol de tablet/smartphone como nodo en domicilio. La integración con nubes se detalla mediante conectores agnósticos, vinculación paciente-dispositivo, validación por mensaje y capacidad de integrar datos discretos y documentos/informes como objetos clínicos en HCE, por lo que no se aprecia un vacío funcional relevante en este componente. Finalmente, el módulo de alertas, el portal del profesional, el módulo de indicadores, la comunicación y el portal del paciente se describen con un nivel de concreción alto y directamente trazable al PPT. Se contempla recepción/procesado/visualización de alertas, alertas sonoras en críticos, motor de reglas configurable, auditoría y estandarización/integración con HCE. El portal del profesional (BC Home) incluye prescripción mediante planes preconfigurados, personalización individual, seguimiento con tendencias, gestión de dispositivos IoMT, administración de roles/permisos y trazabilidad completa. Para indicadores, se propone integración con el ecosistema analítico corporativo (Qlik) comprometiendo 300 horas de soporte para el diseño y despliegue de KPIs. Como matiz, la comunicación bidireccional se plantea 'en versiones evolutivas previstas', aunque se afirma que se habilitará chat / videollamada / mensajería / notificaciones en BC Home para pacientes autorizados; conviene dejar constancia de que, tal como está redactado, parte de esta capacidad se vincula a evolución/implantación progresiva. La propuesta presenta como principal limitación funcional que, aunque, cumple con los requisitos de agnosticismo, visores, administración, portales y comunicación, parte de la funcionalidad clínica avanzada (alertas, reglas complejas, evaluación de resultados) depende en mayor medida de configuraciones y desarrollos sobre la plataforma base. Esto puede requerir un mayor esfuerzo de parametrización funcional, pero no puede ser objeto de penalización. ## Conclusión: Oferta muy completa y bien detallada, con cobertura explícita de los componentes requeridos (IoMT agnóstica, captura multifuente y alta resolución, inventario y gestión, visores multiseñal con retrospectiva, concentradores, integración cloud, alertas, portales profesional/paciente, comunicación e indicadores), incluyendo además un enfoque por fases y caso clínico que asegura visión transversal del paciente y despliegue progresivo corporativo.   ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 6 puntos sobre 6 posibles -  PROVITA (apartado 4.2.2 de su oferta) La oferta presenta una plataforma de telemonitorización e integración IoMT con un grado de adecuación alto a los requisitos funcionales del PPT, aportando además evidencia práctica mediante entorno de demostración y material audiovisual. Se detalla una solución agnóstica y multiusuario, con control por roles (RBAC) y capacidad de integración bidireccional con sistemas corporativos, apoyándose en estándares (FHIR, HL7, openEHR) y normalización semántica. Asimismo, se recogen funcionalidades de captura de señales y diferenciación del punto de origen/ubicación, así como el compromiso de incorporar nuevos drivers cuando sea necesario, lo que encaja con los requisitos de conectividad agnóstica y evolución de base instalada. En relación con la captura y procesamiento de señales en tiempo real, la propuesta describe adquisición continua de constantes, almacenamiento histórico y consulta retrospectiva, incluyendo visualización de tendencias. Además, se menciona la capacidad de gestión de datos 'en alta resolución' y la existencia de visores con retrospectiva mínima de 96 horas, si bien la memoria no desarrolla con el mismo nivel de detalle la arquitectura específica de almacenamiento/gestión de ondas en alta resolución (p. ej., dimensionamiento, repositorio de ondas, estrategia de retención), que el PPT solicita 'indicar solución y arquitectura propuesta para ese caso', quedando la adecuación en este subapartado razonablemente cubierta pero mejorable en concreción. En cuanto a gestión y catalogación de dispositivos, la oferta incorpora un inventario configurable con alta/baja, asociación inequívoca paciente-dispositivo, monitorización de estado, notificaciones y trazabilidad/histórico de cambios, incluyendo jerarquía por contexto asistencial (domicilio/hospital, unidad, cama, etc.) y versionado del catálogo. También se compromete la integración inicial de los 25 kits y describe tipologías, estándares (IEEE 11073 en dispositivos propuestos) y validación end-to-end del flujo, lo que se alinea de forma clara con el inventario y gestor exigidos por el PPT. La interfaz de administración para usuarios/permisos/dispositivos se entiende cubierta por la descripción del módulo de gestión, aunque no se listan pantallas o funciones administrativas de manera explícita. Respecto a los visores de monitorización, la propuesta es consistente con el pliego: visores multiseñal y personalizables, visualización simultánea de varias camas y multivendor, ondas hemodinámicas y parámetros numéricos en tiempo real, acceso web desde distintos dispositivos y posibilidad de embebido en sistemas corporativos. Además, se incluye visor histórico con 96 horas. No obstante, en el texto se afirma que la plataforma Vitalera está 'en transición' y se citan distintas referencias de marcado CE (MDD en transición a IIa MDR y, por otro lado, clase IIb MDR asociada a Digistat), mientras que el PPT exige como mínimo CE clase IIb en monitorización continua como condición crítica. La oferta declara disponer de clase IIb (MDR) 'adjunta en anexos', por lo que funcionalmente se considera cubierto, pero la redacción podría ser más inequívoca en la atribución del marcado al conjunto plataforma/visores objeto del contrato.   Finalmente, en los módulos asistenciales restantes, la oferta describe de forma completa el módulo de alertas (motor de reglas, operación cercana a tiempo real, personalización por paciente, trazabilidad/auditoría e integración con HCE), el portal del profesional (prescripción, planes, seguimiento, acceso a históricos, priorización, perfiles), el portal del paciente (app/web, registro manual/automático, cuestionarios, mensajería segura y videollamadas, notificaciones) y un módulo de indicadores con capacidad de parametrización y crecimiento. También se cubre la comunicación síncrona y asíncrona (chat, videollamada, notificaciones). Como aspecto no explicitado con el mismo nivel de detalle, el PPT contempla interoperabilidad con nubes de proveedores y 'procesamiento de documentos e informes': se menciona el módulo y su enfoque, pero sin ejemplos concretos de conectores ya disponibles, catálogo único corporativo ya implementado o flujos tipo para documentos, quedando cubierto a nivel descriptivo, pero con menor evidencia funcional específica. La principal debilidad funcional de esta propuesta es su menor cohesión global como plataforma única, al percibirse como una suma de soluciones hospitalarias y domiciliarias con distinto grado de madurez funcional. Asimismo, la integración funcional entre hospital y domicilio, especialmente en la gestión unificada de alertas y flujos asistenciales, no está bien detallada, lo que puede impactar en la continuidad asistencial real. ## Conclusión: La oferta presenta una solución funcional muy alineada con el PPT, cubriendo de forma amplia los bloques nucleares (IoMT agnóstica, inventario, visores, alertas, portales, comunicación e indicadores) y comprometiendo la integración inicial de kits y drivers. Existen, no obstante, áreas mejorables de concreción (arquitectura de alta resolución/ondas y detalle de conectores cloud e informes) y cierta ambigüedad redaccional sobre el marcado CE IIb aplicable al conjunto plataforma/visores, aunque se afirma su disponibilidad en anexos. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 3 puntos sobre 6 posibles ##  DEXTRO (apartado 1.4 de su oferta) La oferta presenta una adecuación global alta al apartado 4.2.2 del PPT en cuanto a enfoque funcional y organización por módulos clínicos (seguimiento, alertas, protocolos, comunicación, paciente/profesional), con un planteamiento coherente de continuidad asistencial y especial foco en el caso de uso DM2. No obstante, una parte relevante de los requisitos del pliego están formulados como integración con tecnologías Philips (Capsule MDIP/Neuron 3, PIC iX, IntelliVue Guardian) y, en el texto aportado, no queda explicitado con el mismo nivel de detalle algunos elementos exigidos por el PPT relativos a visores web mínimos (incluida retrospectiva de ondas 96h), embebido en sistemas corporativos, alta resolución/almacenamiento de ondas y marcado CE clase IIb para la plataforma y visores del bloque de monitorización continua (aunque puede estar en otras secciones no aportadas).   En la plataforma de recogida de señales (IoMT), la propuesta articula un ecosistema doble: por un lado, MoviSalud como 'core' funcional para telemonitorización domiciliaria y gestión clínica (constantes, autocontroles, cuestionarios, protocolos, tareas y analítica funcional) y, por otro, Capsule MDIP/Neuron 3 como capa de integración de dispositivos biomédicos hospitalarios. Funcionalmente se describe captura continua de señales en tiempo real, consolidación de tendencias y estandarización para su visualización, así como la capacidad de conectar equipamiento legacy vía RS-232 mediante Neuron 3, lo cual encaja con el requisito de solución agnóstica y de incorporar conectividad para equipos heterogéneos. Sin embargo, en el extracto no se detallan aspectos clave del PPT como inventario/administración de dispositivos IoMT con jerarquía y versionado, ni el compromiso expreso de desarrollar nuevos drivers ante nuevos equipos, más allá de la capacidad genérica de integración. Respecto a visores de monitorización, la oferta sí describe un portal profesional con panel poblacional, semáforos clínicos, vista individual y tendencias longitudinales, lo que cubre bien la dimensión de seguimiento clínico y priorización. Ahora bien, el PPT exige visores multiseñal con requisitos específicos (ondas hemodinámicas en tiempo real, visualización simultánea multi-cama y multi-proveedor, visor histórico con retrospectiva mínima de 96 horas de parámetros y ondas, visor del continuo discreto y visor/gestión de paciente a domicilio), además de accesibilidad web multidispositivo y posibilidad de embeberse en sistemas corporativos. En el texto aportado se menciona PIC iX como elemento de visualización en entorno crítico y se alude a una presentación coherente de señales, pero no se acredita explícitamente la existencia/alcance de los visores web mínimos exigidos (especialmente retrospectiva de ondas 96h, multi-cama multiproveedor y embebido), ni se concreta la disponibilidad y arquitectura de almacenamiento de alta resolución. En cuanto a concentradores hardware/software e integración con nubes, la propuesta incorpora Neuron 3 como concentrador para equipos serie en hospital (alineado con el pliego) y describe la App/portal como capa de captura guiada del paciente y comunicación push (sustituyendo SMS) para domicilio. Se menciona la integración funcional con tecnologías Philips y la existencia de un gestor de dispositivos y kits, pero no se detalla de forma específica la integración con nubes de fabricantes (conectores, vinculación paciente-dispositivo, validación por mensaje, procesamiento de documentos/informes y normalización semántica con catálogo único) tal como lo pide el PPT. Asimismo, se habla de modularidad e 'interoperabilidad', pero sin concretar en el extracto el uso de estándares (HL7/FHIR/IEEE11073) como requisito funcional transversal para todos los componentes, ni el mecanismo de normalización semántica. Finalmente, para alertas, portal profesional/paciente, comunicación e indicadores, la oferta cubre ampliamente el enfoque funcional: motor de alertas y semáforos (verde/ámbar/rojo), árboles de decisión, adherencia, mensajería inteligente (DiabeText), comunicaciones push bidireccionales, gestión de casos y bandeja priorizada, educación sanitaria, gamificación y analítica funcional. Esto se alinea con los módulos del PPT de gestión de alertas, portales y comunicación, y aporta valor asistencial. Como aspecto a verificar, el PPT exige que 'el sistema/plataforma y visores' dispongan como mínimo de marcado CE clase IIb en monitorización continua (requisito excluyente). En el extracto no se menciona este punto de forma expresa, por lo que no puede considerarse acreditado dentro de esta sección funcional.   A pesar de la amplitud funcional descrita, el principal aspecto negativo de la propuesta es la dependencia funcional de múltiples componentes integrados (MoviSalud, Capsule, PIC iX, Guardian), lo que introduce cierta complejidad en la percepción de 'sistema único' exigida por el PPT, especialmente en el módulo de gestión de alertas. Aunque las alertas están bien resueltas en el ámbito hospitalario y domiciliario, la unificación completa del ciclo de vida de la alerta y su explotación transversal requiere una gobernanza clara. Asimismo, el módulo de analítica e indicadores, aunque sólido, no sustituye a un BI corporativo, lo que puede limitar la explotación avanzada sin integraciones adicionales. ## Conclusión: Oferta con alto encaje funcional en telemonitorización domiciliaria, gestión clínica y continuidad asistencial (protocolos, semáforos, tareas, comunicación y analítica nativa), y con una propuesta de integración hospitalaria basada en componentes Philips que, en enfoque, es compatible con el requisito de captura de señales en críticos. No obstante, en el texto aportado no quedan identificados explícitamente varios requisitos funcionales críticos del PPT (visores web mínimos y retrospectiva de ondas 96h, embebido, detalle de alta resolución/almacenamiento de ondas, integración con nubes y normalización semántica con catálogo único, y acreditación CE clase IIb para monitorización continua), por lo que la adecuación debe considerarse parcialmente demostrada en esta sección. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 4 puntos sobre 6 posibles -  VITHIB (apartado 1.2.2 de su oferta) La oferta de la UTE Vitio-Hiberus presenta una adecuación muy elevada a los requisitos funcionales establecidos en el apartado 4.2.2 del PPT, con un nivel de detalle exhaustivo y claramente alineado con el modelo corporativo del Servicio Aragonés de Salud. La solución aborda de forma integral tanto la monitorización hospitalaria avanzada (mediante PIC iX y Capsule MDIP) como la telemonitorización domiciliaria IoMT, articulándolas en un episodio clínico único y continuo, sin rupturas entre hospital y domicilio. Se describen con precisión los flujos asistenciales completos (ingreso, estancia hospitalaria, alta y seguimiento domiciliario), garantizando la trazabilidad del dato, la coherencia demográfica (ADT) y la integración directa con la HCE, lo que responde de manera directa a uno de los objetivos nucleares del pliego: la eliminación de silos de información. Desde el punto de vista funcional, la oferta cubre y acredita explícitamente los requisitos más críticos del PPT. En monitorización hospitalaria, PIC iX proporciona visores multipaciente, acceso web near real time, visualización de ondas hemodinámicas en alta resolución ( ≥ 200 Hz), retrospectiva de hasta 7 días, scoring clínico (EWS), gestión de traslados y continuidad del episodio entre unidades, cumpliendo sobradamente los requisitos de visores, control centralizado y acceso interdepartamental. En el ámbito IoMT, la plataforma describe de forma muy detallada la recogida de señales agnóstica, la gestión y catalogación avanzada de dispositivos y kits, la vinculación pacientedispositivo, la existencia de concentradores hardware y software con persistencia offline, y la integración con nubes de proveedores en modos push y pull. Asimismo, se explicita la normalización semántica mediante HL7 v2, FHIR, SNOMED CT, LOINC e IEEE 11073, incluyendo catálogo único y validación semántica, lo que satisface plenamente los requisitos de interoperabilidad del pliego.   Adicionalmente, la solución desarrolla con un alto grado de madurez el módulo de gestión de alertas, con definición multinivel de criticidad, reglas de escalado, trazabilidad completa del ciclo de vida, auditoría indeleble y mecanismos probados de reducción de falsos positivos, aportando evidencias de impacto real en entornos asistenciales. Los portales del profesional y del paciente están ampliamente descritos, incluyendo prescripción, configuración de planes de actividades, seguimiento clínico, comunicación síncrona y asíncrona, indicadores, informes e integración directa con HCE mediante botón lanzador. Todo ello configura un ecosistema dual paciente-profesional coherente, escalable y plenamente alineado con la continuidad asistencial exigida en el PPT. Desde el punto de vista funcional, la principal debilidad de la propuesta radica en la complejidad operativa derivada de una solución dual (plataforma hospitalaria y plataforma domiciliaria diferenciadas), lo que puede exigir un mayor esfuerzo inicial de coordinación y gobierno funcional para asegurar una experiencia completamente homogénea para el profesional. Aunque los módulos funcionales exigidos por el PPT están cubiertos, la gestión integrada de alertas y la explotación de indicadores dependen de una correcta orquestación entre ambos entornos. Asimismo, la riqueza funcional puede implicar una curva de adopción mayor si no se acompaña de una adecuada gestión del cambio y formación continuada. ## Conclusión: La oferta acredita de forma clara, estructurada y verificable el cumplimiento de los requisitos funcionales del pliego, aportando además evidencias de madurez, interoperabilidad real, normalización semántica y experiencia previa en entornos asistenciales complejos. La descripción cubre explícitamente los visores, la alta resolución de señales, la integración con HCE, la gestión avanzada de dispositivos IoMT y la trazabilidad clínica de extremo a extremo. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 4 puntos sobre 6 posibles ## 1.2.3. Características técnicas de la solución (hasta 6 puntos) -  TSYSBET (apartado 1.2.5 de su oferta)  ## Arquitectura Modular y Escalabilidad: -  Describe de forma muy clara su arquitectura modular con componentes diferenciados y desacoplados para (ingesta/procesamiento/entrega). -  Posee un único componente de ingesta, BcLink, de ingesta de datos que permite su despliegue independiente y escalado deslocalizado, tanto horizontal como vertical. Agrega funciones de cacheo local que hace robusta la solución en cuanto a fallos de desconexiópn o caída en sus diferentes opciones de despliegue. Posee además capacidad nativa de procesamiento, normalización y homogeniezación de los datos tipo discreto y onda. -  Persistencia local concentradores (hospitalario: baterías, domiciliario: tablets offline). -  BDTR como cache operativo (últimos valores/minutos) -  Describe de forma muy clara el flujo de ingesta de los datos en la BDTR y luego el proceso de consolidación en una única BBDD centralizada de tiempo real y, de allí, a la BBDD de Histórico (BHD). Oferta APIs para consulta desde ambas BBDD, tanto de tiempo real como de histórico permitiendo incluso la consulta y gestión de información tipo onda a largo plazo. Tecnológicamente permite aprovechar lo mejor de las BBDD relacionales con las BBDD documentales y permite incluso portabilidad de datos entre diferentes tipos de BBDD (Oracle - Postgree). -  BDTR (tiempo real, JSON relacional, <1s latencia) + BDH (histórico, migración automática). -  Consolidación única hospital+domicilio → dato corporativo unificado. -  Historificación meses/años configurable. -  Motor ingesta valida/normaliza pre-BDTR (SNOMED/LOINC/up-downsampling 200Hz) -  En cuanto a consulta de los datos proporciona un API Gateway REST/FHIR completa: sincrónica (BDTR real-time) y asincrónica (suscripciones FHIR/WebSockets/MQTT). Permite Consulta a BDTR y BDH: últimos datos, ventanas temporales, agregados, series altas frecuencias. Optimizada para usuarios concurrentes (miles consultas/segundo) -  Plantea los módulos de visualización separando de forma acertada la de tiempo real y la de dato discrete histórico que enriquece con dato clínico procedente de la integración con sistemas corporativos, permitiendo vistas por paciente o unidad en ambos casos. -  Por ultimo, describe de forma completa las características técnicas del portal del profesional y del paciente para tetemonitorización y el mundo de la movilidad. Separa pues, de forma acertada, ambos mundos (hospitalario y telemonitorización) lo cual independiza el funcionamiento sin renunciar a la consolidación del dato en un único repositorio normalizado. Esto blinda ambos ámbitos frente al otra en cuanto a caídas, picos de uso, crecimiento desigual, etc. Asocia su despliegue excatamente a la política cloud del Gobierno de Aragón (IaaSy Terraform) como se indicaba en el PPTEC. -  En cuanto a la tipología de arquitectura de despliegue, se trata, en todos sus componentes de una arquitectura microservicios desacoplada. Esto permite, de nuevo, independencia, escalado horizontal clústeres replicados, despliegue multiAZ. Se responsabiliza, de forma clara, de la gestión y soporte de la capa de   microservicios, como se pide en el PPTEC, describiendo una gestión colaborativa SALUD - proveedor muy acertada. ## Robustez y Fiabilidad: -  Garantiza Alta disponibilidad y describe como la implementa: failover automático, colas persistentes, reintentos. -  Detalla sus capacidades para volúmenes críticos: 1500 pacientes simultáneos, 10k eventos/minuto. -  Describe controles de ingesta para duplicados, desconexiones, etc. ## Gestión de permisos y trazabilidad: -  RBAC granular y gestionable definiendo usuarios/sistemas/perfiles. -  Soporte OAuth2/OIDC/SAML + SSO corporativo. -  Diferenciación orígenes: automática (applicable a dispositivos y sistemas), manual (portal paciente/profesional). Aplica esta diferenciación y RBAC tanto a la ingesta como a la consulta en todos sus módulos y APIs -  Garantiza ENS nivel Alto/GDPR -  Soporta TLS 1.2/ 1.3 para dato en tránsito y cifra el dato en reposo con AES-256 -  Permite sandboxing de dispositivos -  Garantiza auditoría completa (who/when/what). Aplica la confianzo cero por defecto con validación y almacenado de traza de origen y destino de cada mensaje ## Como conclusion: -  Se oferta una plataforma madura con una arquitectura robusta, confinable, escalable y autorrecuperable -  Garantiza consolidación centralizada con funciones avanzadas de cacheo -  Garantiza capacidades masivas de ingesta y consulta con funciones nativas de normalización -  Asegura la auditoria y seguridad del dato -  Como valor adicional oferta 300 horas para la construcción de un informe sobre Qlik (herramienta corporative) como refuerzo a la función estadística de la propia solución ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 6 puntos sobre 6 posibles -  PROVITA (apartado 4.2.3 de su oferta) ## Arquitectura Modular y Escalabilidad:  -  Describe la solución que se apoya en tres componentes diferenciados: -  ASCOM MDI como concentrador software y harware de señales -  Suite Digistat para la captura y visualización hospitalaria, junto con ASCOM MDI dará soporte a la parte hospitalaria -  La solución Vitalera de seguimiento remoto -  Menciona su consolidación para visión transversal pero no aclara flujos por lo que se presentan como plataformas demasiado desacopladas -  Esta arquitectura está desacoplada con componentes diferenciados por ámbito: -  Describe en su parte ASCOM MDI + DIGISTAT componentes diferenciados para (ingesta/procesamiento/entrega). No detalla arquitectura ni opciones de instalación por lo que no puede valorarse. -  No describe los componentes técnicos de la plataforma de hospital ni telemonitorización lo que impide, en gran parte, su valoración. -  Define la existencia de la BDTR y la BDH pero no detalla su forma de alimentación ni su detalle como parte de una arquitectura completa de las soluciones, no se entiende su presencia dentro de la definición desacoplada. Presenta la alimentación de la BDH desde la BDTR como un proceso automático, pero no da ningún detalle, se intuye que no hay alimentación síncrona y nativa sino más bien un proceso de extracción y carga tipo warehouse. Esto limita las opciones de consulta desde otros sistemas. -  Esto refuerza de nuevo la idea de una solución desacoplada entre los diferentes módulos, lejos de lo que quiere conseguirse. ## En cuanto a la oferta de APIs para consulta: -  No detalla APIs específicas de consulta BDTR/BDH. Menciona "APIs y estándares interoperabilidad" genéricos (HL7/FHIR), pero sin endpoints, latencia ni diferenciación BDTR (real-time) vs BDH (histórico) -  La asegura (en modo consulta y suscripción) pero no detalla funciones en cuanto a tiempo real, ventanas temporales largas, recuperación de datos tipo onda, últimos datos, agregados, series altas frecuencias. -  No describe su forma de optimización ni capacidades para usuarios concurrentes Presenta módulos de visualización (DIGISTAT y telemonitorización) desacoplados sin continuidad: -  El modulo de hospitalaria tiene una limitación de 96 horas Describe de forma somera las características técnicas de los components de ASCOM MDI + DIGISTAT y de Vitalera. No detalla la formula de gestión lo que pudiera crear algún conflicto entre gestor de sistemas y gestor de aplicación. ## Robustez y Fiabilidad: -  Garantiza Alta disponibilidad y pero no describe cómo se implementa    -  No da ningún detalle en cuanto a capacidades ni limitaciones para volúmenes altos y críticos. ## Gestión de permisos y trazabilidad: -  Menciona la gestión basada en RBAC para Vitalera pero basado en perfiles pre existentes para DIGISTAT, no indica que sea configurable. -  Además, los perfiles señalados para DIGISTAT no parecen granulares, por ejemplo, por categoría profesional o servicio o por cuidador o paciente en el caso del portal del paciente. -  No menciona soporta OAuth2 o JWT, habla de SSo de forma genérica. -  No menciona que se puedan definir permisos o controles finos a nivel de carga (dispositivos conectados) y consulta de APIs. -  Garantiza ENS /GDPR -  Soporta TLS para dato en tránsito y cifra el dato en reposo, sin mención de algoritmo específico -  Garantiza auditoría completa (who/when/what. ## Como conclusión: -  Se oferta una plataforma desacoplada de tres components para los dos ámbitos (hospitalario + telemonitorización) de los que no queda clara su integración. -  Presenta muy poco nivel de detalle en todas sus descripciones. -  Asegura la auditoria y seguridad del dato pero, también, sin descripción detallada. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 3 puntos sobre 6 posibles -  DEXTRO (apartado 1.3 y 1.5 de su oferta) ## Arquitectura Modular y Escalabilidad: -  Describe la solución que se apoya en dos componentes diferenciados: -  Suite de Philips (Capsule/PIC/Guardian) para la parte hospitalaria -  La solución MoviSALUD para la telemonitorización -  Con consolidación en MoviSALUD para visión transversal y BBDD centralizada de información de señales a nivel corporativo -  Esta arquitectura es modular con componentes diferenciados por ámbito: -  Describe en su parte hospitalaria (Philips) componentes diferenciados para (ingesta/procesamiento/entrega) pero, en sí mismos, de forma interna, funcionan como un componente que no permite opciones diferentes de instalación, sino una implantación, se entiende centralizada, que no solventa algunos problemas que pudieran aparecer como la latencia (al hacerlo lejos de los centros y con ello de sus redes), la resiliencia ante desconexiones...   -  Describe los componentes de MoviSALUD que, aquí sí, está basada en microservicios que garantizan en mayor manera las posibilidades de instalación y escalado, autonomía, etc. separando la parte de ingesta, almacenamiento (basada en el servidor FHIR y en el servidor terminológico) y visualización: portal del profesional y paciente. Permite en este punto despliegue de componentes de ingesta de datos independientes y escalado deslocalizado, tanto horizontal como vertical. -  Garantiza Persistencia local concentradores (hospitalario: baterías, domiciliario: tablets offline). -  No concreta los tiempos de actualización de la BDTR y la BDH Describe el flujo de ingesta de los datos en la BDTR y el proceso de consolidación en una única BBDD centralizada en MoviSALUD pero no de forma precisa. Parece más bien un repositorio alimentado por procesos de extracción y carga, tipo datewarehouse, que una opción nativa (al tratarse de sistemas de diferentes fabricantes) cargando en MoviSALUD los datos desde la plataforma de Philps. En cuanto a la oferta de APIs para consulta, la asegura, pero no detalla funciones en cuanto a tiempo real, ventanas temporales largas, recuperación de datos tipo onda, últimos datos, agregados, series altas frecuencias. No describe su forma de optimización ni capacidades para usuarios concurrentes Presenta módulos de visualización (PIC y MoviSALUD) desacoplados, separando de forma acertada la de tiempo real y la de dato discreto histórico que enriquece con dato clínico procedente de la integración con sistemas corporativos, permitiendo vistas por paciente o unidad en ambos casos. -  El modulo PIC tiene, eso sí, una limitación de 7 días Por ultimo, describe de forma completa las características técnicas del portal del profesional y del paciente para tetemonitorización y el mundo de la movilidad. Separa pues, de forma acertada, ambos mundos (hospitalario y telemonitorización) lo cual independiza el funcionamiento sin renunciar a la consolidación del dato en un único repositorio normalizado. -  Esto blinda ambos ámbitos frente al otra en cuanto a caídas, picos de uso, crecimiento desigual, etc. -  En cuanto a la tipología de arquitectura de despliegue se ve la implantación de la parte Philips como menos flexible. Por otro lado, no detalla la formula de gestión lo que pudiera crear algún conflict entre gestor de sistemas y gestor de aplicación en cuanto a la responsabilidad de gobierno de la capa docker. ## Robustez y Fiabilidad: -  Garantiza Alta disponibilidad y pero no describe como se implementa en la parte Philips. -  No detalla capacidades ni limitaciones para volúmenes altos y críticos. ## Gestión de permisos y trazabilidad:   -  Posee un modulo de gestión de usuarios y permisos que ofrece la posibilidad de definir perfiles clínicos, permisos granulares y niveles de acceso a los distintos módulos de la plataforma. -  Soporta OAuth2. -  No detalla si esta definición de permisos aplica también a nivel de carga (dispositivos conectados) y consulta de APIs. -  Garantiza ENS /GDPR -  Soporta TLS para dato en tránsito y cifra el dato en reposo con AES-256 -  Garantiza auditoría completa (who/when/what) si bien no se explicita qué datos almacena procedentes de la integración con Philips. ## Como conclusion: -  Se oferta una plataforma madura con una arquitectura robusta pero la integración entre Philips y MoviSALUD presenta debilidades frente a una integración nativa. -  Garantiza consolidación centralizada, garantiza capacidades de ingesta y consulta, pero no entra en detalle de estas capacidades más allá de la mención de las mismas. -  Asegura la auditoria y seguridad del dato. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 4 puntos sobre 6 posibles -  VITHIB (apartado 1.3 de su oferta) ## Arquitectura Modular y Escalabilidad: -  Describe la solución que se apoya en dos componentes diferenciados: -  Suite de Philips (Capsule/PIC) para la parte hospitalaria -  La solución para la telemonitorización -  Como gran debilidad no se encuentra en su oferta mención a la consolidación de datos entre ambas lo que no garantiza la visión transversal y la existencia BBDD centralizada de información de señales a nivel corporativo. Se señalan, parece, como dos plataformas desacopladas con dos propósitos diferentes -  Esta arquitectura está desacoplada con componentes diferenciados por ámbito: -  Describe en su parte hospitalaria (Philips) componentes diferenciados para (ingesta/procesamiento/entrega) que no permite opciones diferentes de instalación, sino una implantación, se entiende centralizada, que no solventa algunos problemas que pudieran aparecer como la latencia (al hacerlo lejos de los centros y con ello de sus redes), la resiliencia ante desconexiones... -  No describe los componentes técnicos de la plataforma de telemonitorización lo que impide, en gran parte, su valoración. -  Garantiza Persistencia local concentradores (hospitalario: baterías, domiciliario: tablets offline).   -  Define la existencia de la BDTR y la BDH pero no detalla su forma de alimentación ni su detalle como parte de una arquitectura completa de las soluciones, no se entiende su presencia dentro de la definición desacoplada que hace de los ámbitos hospitalario y de telemonitorización. Presenta la aplimentación de la BDH desde la BDTR como un proceso configurable de retención y volcado, es decir, no hay alimentación síncrona y nativa sino más bien un proceso de extracción y carga tipo warehouse. Esto limita las opciones de consulta desde otros sistemas. -  Esto refuerza de nuevo la idea de una solución desacoplada entre los mundos hospitalario y telemonitorización, lejos de lo que quiere conseguirse. En cuanto a la oferta de APIs para consulta la asegura (en modo consulta y suscripción) pero no detalla funciones en cuanto a tiempo real, ventanas temporales largas, recuperación de datos tipo onda, últimos datos, agregados, series altas frecuencias. No describe su forma de optimización ni capacidades para usuarios concurrentes Presenta módulos de visualización (PIC y telemonitorización) desacoplados sin continuidad: -  El modulo PIC tiene una limitación de 7 días Describe de forma completa las características técnicas de los components de Philips pero de forma muy somera las del portal de telemonitorización. -  En cuanto a la tipología de arquitectura de despliegue se ve la implantación de la parte Philips como menos flexible. No detalla la formula de gestión lo que pudiera crear algún conflicto entre gestor de sistemas y gestor de aplicación. ## Robustez y Fiabilidad -  Garantiza Alta disponibilidad y pero no describe como se implementa en la parte Philips. -  No describe nada en cuanto al portal de telemonitorización lo que no permite su valoración tampoco en este punto. -  No da ningún detalle en cuanto a capacidades ni limitaciones para volúmenes altos y críticos. ## Gestión de permisos y trazabilidad -  Menciona la gestión basada en RBAC pero, parece, con perfiles ya pre existentes, es decir, no indica que sea configurable. -  Soporta OAuth2. -  No parece que, del mismo modo, se puedan definer permisos o controles finos a nivel de carga (dispositivos conectados) y consulta de APIs. -  Garantiza ENS /GDPR -  Soporta TLS para dato en tránsito y cifra el dato en reposo con AES-256   -  Garantiza auditoría completa (who/when/what) si bien no se explicita qué datos almacena procedentes de la integración con Philips. Proporciona interfaces específicos de consulta de la auditoria. ## Como conclusion: -  Se oferta una plataforma desacoplada de dos components de los que no queda clara su integración que, parece, no está trabajada de antemano y debe construirse en tiempo de proyecto lo cual supone mucho riesgo con los plazos existentes. -  No está clara la consolidación centralizaday si bien señala capacidades de ingesta y consulta, no entra en detalle de estas capacidades más allá de la mención de las mismas. -  Asegura la auditoria y seguridad del dato. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 3 puntos sobre 6 posibles ## 1.2.4. Características de interoperabilidad e integraciones de la solución (hasta 8 puntos) -  TSYSBET (apartado de referencia 1.2.6 de su oferta) Conectores y protocolos IoMT/nubes, agnosticismo: -  BC Link ofrece conectores hardware/software exhaustivos para cualquier dispositivo/fabricante, siendo una solcuión agnóstica de fabricante. -  Hardware: RS-232/422/485, LAN TCP/UDP, WiFi, Bluetooth/BLE, 4G/5G -  Software: IEEE 11073/PCHAlliance, protocolos propietarios (binarios, ASCII, XML/JSON), APIs REST/Webhooks/SDK de nubes IoMT, SFTP -  Cloud-to-cloud: HL7 v2 ORU/OMD, FHIR mensajería, pull/push para réplica en tiempo real desde nubes proveedores -  Permite conexiones tipo pull / push -  Validación paciente-dispositivo pre-ingesta -  Lleva a cabo upsampling/downsampling nativo de ondas para llevar a cabo su homogeneización -  Se compromete al desarrollo de conectores contra dispositivos no existentes en su inventario actual pero sí en el SALUD -  Esto cubre todos los casos del PPT (estándar, propietario, app móvil, cloud) ## Estándares de integración: -  Garantiza cumplimiento total con:   -  HL7 v2.x (ADT, ORU, ORM/OMP, v2.6 XML), FHIR R4/R5 (Patient, Observation, Device…..) -  DICOM, CDA/CCR/CCD -  IHE PCD completo: ACM, DEC, IDCO, IPEC, PIV, RTM, SPD, RDQ -  Compatible con EAI Rhapsody del SALUD -  Puede hacer uso del servidor terminologías SNS para garantizar su integración semántica. -  Incide en su alineamiento garantizado con el SNS lo que asegura la integración futura con el ecosistema planteado por el Ministerio de Sanidad, indicando que en todo momento sus productos seguirán las directrices del mismo y del ENI, este punto es diferencial en su oferta ## Gestión inventario dispositivos: -  Inventario vivo inteligente con: -  Catalogación automática (modelo, versión, fabricante, ubicación). -  Trazabilidad completa (vinculación paciente-dispositivo-episodio) -  Monitorización tiempo real (conectividad, incidencias, alertas desconexión) -  Existencia de un Laboratorio de certificación: Endpoints prueba, procedimientos homologación, certificado conformidad que podrá ser utilizado durante la vida del Proyecto para las pruebas de conexión de equipos y dispositivos con la plataforma, este punto es diferencial en su oferta -  Soporta actualización remota si el dispositivo lo permite, lo que es diferencial en su oferta. ## Normalización semántica: -  Haciendo uso, antes de la ingesta del catálogo corporativo SNOMED CT/LOINC/ CIE (y del servidor de terminologías del Ministerio) -  Normaliza el Código clínico, descripción normalizada, unidad medida, rangos válidos -  Propone la creación de un Refset transversal del SALUD para comparabilidad universal del que se hace responsable, este punto es diferencial en su oferta -  Mapeo automático formatos heterogéneos → datos estructurados/explotables -  Validación estructural antes ingesta (origen, paciente, dispositivo). ## Integración HCE/sistemas corporativos: -  Bidireccional con: -  HCE/GUHARA, HIS, EMPI, farmacia, laboratorio via HL7/FHIR/REST/SOAP -  Señala cada tipo de mensaje de forma detallada -  Incide no sólo en la integración de consulta estructurada si no en la posibilidad de remisión de informes PDF a HCE -  Datos monitorización → objetos clínicos HCE (constantes, ondas, informes PDF base64)   -  Expone de forma clara que será nodo de consolidación y dato único: Hospital + domicilio de forma que la integración con HCE sea única -  La integración es bidireccional de forma que el portal del professional y el paciente puede alimentarse con datos de HCE para enriquecer el contexto clínico del paciente -  Señala la capacitación de la BBDD consolidada para su uso en investigación y proyectos de I+D, este punto es diferencial en su oferta ## Como conclusión: -  Traduce de forma perfecta los requisitos del PPT en un mapa completo de integraciones con conectores agnósticos, uso de estándares y normalización SNOMED/LOINC, integrando perfectamente dispositivos multivendor, nubes IoMT y HCE -  Como puntos diferenciales: -  se alinea de forma nativa con las disposiciones del SNS lo que garantiza esta integración a nivel nacional -  propone la constitución de un laboratorio de certificación -  integración bidireccional con HCE y las aplicaciones corporativas -  conformación de una BBDD para la integración con herramientas de analítica asociadas a I+D e investigación clínica ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 8 puntos sobre 8 posibles -  PROVITA (apartado de referencia 4.2.4 de su oferta) ## Conectores IoMT y Agnosticismo: -  Soporta conectividad multivendor vía Digistat (monitores, ventiladores, bombas) y Vitalera (tensímetros, pulsioxímetros, glucómetros), con drivers propietarios y SDK para BLE/WiFi. -  Permite conexiones tipo pull / push -  Validación paciente-dispositivo pre-ingesta -  No detalla capacidades de upsampling/downsampling -  No se compromete al desarrollo de drivers si no los tiene ya en su catálogo -  Soporta cloud (pull/push via REST/MQTT), lo detalla para el caso de uso de glucosa/insulina -  Añade la función de uso de VitaleraScan que facilita la integración por reconocimiento de imagen, lo que es diferencial en su oferta -  Cubre todos los casos del PPT (estándar, propietario, app móvil, cloud) ## Estándares de integración: -  Garantiza cumplimiento con:   -  Menciona HL7 v2.x pero no describe los mensajes ni eventos soportados (ADT, ORU, ORM/OMP…) ni si tiene limitaciones con las versiones -  Menciona capacidades FHIR pero no indica si R4/R5 ni los recursos soportados (Patient, Observation, Device…..) -  DICOM, mencionado en su oferta, pero sin detalle de lo que permite respecto a ello -  No menciona capacidades de integración sobre HL7 CDA/CCR/CCD -  No menciona el framework IHE PCD como referencia de sus desarrollos de interoperabilidad -  No menciona su paradigma de Compatible con el EAI Rhapsody del SALUD ## Normalización semántica: -  Haciendo uso, antes de la ingesta, del catálogo corporativo SNOMED CT/LOINC/ CIE -  No menciona, específicamente, la normalización de unidades de medida y rangos válidos -  Mapeo automático formatos heterogéneos → datos estructurados/explotables -  Validación estructural antes ingesta (origen, paciente, dispositivo) ## Integración HCE (GUHARA) Bidireccional: -  Menciona flujos para sincronización demográfica y envío de constantes/alertas a HCE, con acceso contextual vía SSO (GUIA) y URLs embebidas -  No especifica la posibilidad de enriquecer, mediante integración, el contexto clínico con información de sistemas de farmacia, laboratorio, etc. -  No detalla los tipos de mensaje a integrar -  Parece limitada y más pensada para la alimentación de alertas e infores sobre HCE que una integración complete real ## Gestión Inventario: -  Ofrece inventario configurable de kits/dispositivos con estados (disponible/ocupado/higienización) ## Como conclusion: -  Cubre los requisites de forma limitada y presenta un mapa de integraciones poco detallado con conectores agnósticos, uso de estándares y normalización SNOMED/LOINC, integrando dispositivos multivendor, nubes IoMT y HCE -  Se echa en falta: -  Detalle de los procesos de downsampling/upsampling -  Detalle de normalización de unidades y rangos de normalidad -  Detalle de las integraciones con los sistemas corporativos -  Integración en sentido HCE  Solución pobre -  Integración con cloud de terceros en tiempo real   -  Se valora como valos diferencial la funcionalidad de Scaneo de Imagen ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 6 puntos sobre 8 posibles -  DEXTRO (apartado de referencia 1.3.4 y 1.6 de su oferta) ## Conectores y protocolos IoMT/nubes, agnosticismo: -  Ofrece conectores hardware/software con más de 1.500 drivers para cualquier dispositivo/fabricante, siendo una muy completa. -  Hardware: RS-232/422/485, LAN TCP/UDP, WiFi, Bluetooth/BLE - o No menciona capacidades 4G/5G -  Software: IEEE 11073/PCHAlliance, protocolos propietarios (binarios, ASCII, XML/JSON), APIs REST/SDK de nubes IoMT - o No menciona capacidades SFTP que parecen útiles para dispositivos legacy - o No menciona webhooks útiles para integraciones con nubes -  Cloud-to-cloud: HL7 v2 ORU/OMD, FHIR mensajería, pull/push para réplica en tiempo real desde nubes proveedores -  Permite conexiones tipo pull / push -  Validación paciente-dispositivo pre-ingesta -  No se menciona el upsampling/downsampling nativo de ondas para llevar a cabo su homogeneización -  Se compromete al desarrollo de conectores contra dispositivos no existentes en su inventario actual pero sí en el SALUD -  Esto cubre todos los casos del PPT (estándar, propietario, app móvil, cloud) ## Estándares de integración: -  Garantiza cumplimiento total con: -  HL7 v2.x (ADT, ORU, SIU, ORM/OMP, v2.6 XML), FHIR R4/R5 (Patient, Observation, Device…..) -  CDA/CCR/CCD -  IHE PCD completo: ACM, DEC, IDCO, IPEC, PIV, RTM, SPD, RDQ -  No describe sus capacidades de integración DICOM, lo cual supone una merma funcional a nivel de integración ## Gestión inventario dispositivos: -  Inventario vivo inteligente con: -  No se menciona la Catalogación automática sino que debe hacerse manualmente -  Trazabilidad completa (vinculación paciente-dispositivo-episodio) -  No describe Monitorización en tiempo real  ## Normalización semántica: -  Haciendo uso, antes de la ingesta del catálogo corporativo SNOMED CT/LOINC/ CIE (y del servidor de terminologías del Ministerio) -  No menciona, específicamente, la normalización de unidades de medida y rangos válidos -  Mapeo automático formatos heterogéneos → datos estructurados/explotables -  Validación estructural antes ingesta (origen, paciente, dispositivo). ## Integración HCE/sistemas corporativos: -  Propone flujos ADT/ORU para sincronización demográfica y de prescripciones y datos clínicos -  Especifica la posibilidad de enriquecer, mediante integración, el context clínico con información de sistemas de farmacia, laboratorio, etc. -  No detalla los tipos de mensaje a integrar ## Como conclusión: -  Traduce de forma completa los requisitos del PPT en un mapa completo de integraciones con más de 1.500 conectores, uso de estándares y normalización SNOMED/LOINC, integrando perfectamente dispositivos multivendor, nubes IoMT y HCE -  Se echa en falta el soporte del estándar DICOM, al menos su no mención en la oferta -  No señala capacidades de inventario automático -  No señala valores añadidos asociados a este punto ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 7 puntos sobre 8 posibles -  VITHIB (apartado 1.2 de su oferta) ## Conectores y protocolos IoMT/nubes, agnosticismo: -  Ofrece conectores hardware/software para múltiples dispositivos/fabricantes: -  Hardware: RS-232/422/485, LAN TCP/UDP, WiFi, Bluetooth/BLE, 4G/5G -  Software: IEEE 11073/PCHAlliance, protocolos propietarios (binarios, ASCII, XML/JSON), APIs REST/Webhooks/SDK de nubes IoMT con algunas limitaciones que explicita en la oferta - o No menciona capacidades SFTP que parecen útiles para dispositivos legacy -  Cloud-to-cloud: pull/push para réplica en tiempo real desde nubes proveedores - o No menciona en su oferta capacidades HL7 v2 ORU/OMD que podrían limitar algunas soluciones -  Permite conexiones tipo pull / push -  Validación paciente-dispositivo pre-ingesta    -  Lleva a cabo upsampling/downsampling nativo de ondas para llevar a cabo su homogeneización -  Esto cubre todos los casos del PPT (estándar, propietario, app móvil, cloud) ## Estándares de integración: -  Garantiza cumplimiento con: -  HL7 v2.x (ADT, ORU, ORM/OMP, v2.6 XML), FHIR (Patient, Observation, Device…..) -  No se menciona HL7 CDA/CCR/CCD -  DICOM -  IHE PCD, si bien no detalla los perfiles soportados: ACM, DEC, IDCO, IPEC, PIV, RTM, SPD, RDQ… -  Compatible con EAI Rhapsody del SALUD -  Se echa en falta su detalle ya que se menciona todo de forma genérica ## Gestión inventario dispositivos: -  Inventario vivo inteligente con: -  Catalogación manual (modelo, versión, fabricante, ubicación). -  Trazabilidad completa (vinculación paciente-dispositivo-episodio) -  Monitorización tiempo real (conectividad, incidencias, alertas desconexión) -  Existencia de un Laboratorio de certificación ## Normalización semántica: -  Haciendo uso, antes de la ingesta del catálogo corporativo SNOMED CT/LOINC -  No se menciona en la oferta la consolidación de episodios normalizados en CIE -  Normaliza el Código clínico, descripción normalizada, unidad medida, rangos válidos -  Propone la creación de un Refset transversal del SALUD -  Mapeo automático formatos heterogéneos → datos estructurados/explotables -  Validación estructural antes ingesta (origen, paciente, dispositivo) ## Integración HCE/sistemas corporativos: -  Bidireccional con: -  HCE/GUHARA, HIS, EMPI via HL7/FHIR/REST/SOAP -  No señala cada tipo de mensaje de forma detallada -  Incide no sólo en la integración de consulta estructurada si no en la posibilidad de remisión de informes PDF a HCE -  No detalla la integración bidireccional con alimentación clinica desde HCE a la plataforma   No se aclara de forma adecuada la consolidación en una única BBDD sino que parece que se trata de dos sistemas (hospitalario y telemonitorización) lo que puede implica llevar a cabo las integraciones de forma doble ## Como conclusión: -  Traduce de forma perfecta los requisitos del PPT en un mapa completo de integraciones, uso de estándares y normalización SNOMED/LOINC, integrando perfectamente dispositivos multivendor, nubes IoMT y HCE -  No señala capacidades de inventario automático -  Señala como valor añadido la posibilidad de uso del servidor FHIR corporativo como pasarela, pero no parece claro ya que añade complejidad y los plazos son muy ajustados Se valora el desarrollo este apartado en la oferta de VITHIB con: 6 puntos sobre 8 posibles ## 1.3. Características del Entorno Tecnológico propuesto (Punto 5 PPT). Hasta 4 puntos ##  TSYSBET (apartado 1.3 de su oferta) Su solución permite modelos total mente onPrem, totalmente Cloud e híbridos pero, además de presentar esta facilidad para la toma final de decisión, platea en su oefta el Modelo híbrido como la mejor opción de forma totalmente justificada: Plantea un modelo híbrido 95% on -premise + 5% nube, exactamente en la línea de lo solicitado en el pliego: maximizar CPDs corporativos y usar nube solo donde aporta más valor (telemonitorización domiciliaria). Propone mantener la parte hospitalaria (UCI, urgencias, semicríticos) on -premise, con el dato clínico siempre bajo dominio del SALUD, lo que da respuesta directa a: -  riesgo de caídas de red externa, -  latencia en entornos críticos, -  soberanía del dato y facilitar el cumplimiento ENS/ENI/MDR. Separación clara de infraestructuras y módulos: -  Distingue con precisión tres capas de infraestructura, indicando qué se despliega dónde y por qué: -  Infraestructura central corporativa (CPD): BDTR y BDH corporativas, integración con HCE/HIS/EMPI/BDU/Rhapsody, consolidación de datos hospitalarios y domiciliarios.   -  Infraestructura local por hospital (BC Link gateway): servidores locales para integración con monitores y equipos, con capacidad de funcionamiento autónomo ante desconexión de la plataforma central. -  Infraestructura en nube (IaaS): pasarela IoMT para la telemonitorización domiciliaria, desplegada en cuentas cloud del Gobierno de Aragón, como IaaS terraformada (IaC) tal y como exigía el PPT. ## Proporciona Autonomía local y continuidad asistencial: -  El diseño por hospital garantiza que, aunque se pierda conexión con CPD o nube, el BC Link local sigue operando, manteniendo la integración con equipamiento crítico y la monitorización continua. -  Esto responde de forma perfecta a las preocupaciones del pliego sobre continuidad de servicio y alta disponibilidad en entornos críticos, y es un punto diferencial frente a arquitecturas excesivamente centralizadas. ## Cloud IaaS, IaC y seguridad: -  La nube se usa exclusivamente para la ingesta y orquestación IoMT domiciliaria, con: -  despliegue como IaaS (ECS/Fargate, RDS, VPC, VPN IPsec, WAF, etc.), -  toda la infraestructura definida con Terraform, facilitando reproducibilidad, portabilidad y gestión por el propio SALUD. -  Este modelo respeta la exigencia del PPT de no introducir PaaS/SaaS opacos y de mantener propiedad y control del dato en el SALUD, limitando la exposición del CPD a tráfico directo desde domicilio. Lleva a cabo una descripción completa del Dimensionamiento tanto local (CPU, RAM, disco) como en nube: -  Para cada bloque (hospital tipo, CPD, cloud) detalla recursos mínimos y escalables: -  vCPU, RAM y almacenamiento por servidor BC Link, BD local y BD corporativas, -  consumos iniciales y márgenes de crecimiento (ondas vs discretos, BDTR vs BDH), -  Capacidad y escalado de servicios cloud (tareas de ingesta, RDS, IOPS, throughput). Esto permite evaluar objetivamente el ajuste a las necesidades del proyecto y comparar ofertas en términos de realismo de capacidad y coste futuro, algo que el pliego pedía explícitamente. Desarrolla incluso la necesidad de entornos de Preproducción y sus capacidades concretas necesarias. ## Como conclusión:   -  Traduce de forma perfecta los requisitos del PPT en un diseño concreto de entorno tecnológico (1.3) -  Justifica con claridad el modelo híbrido como la opción óptima para equilibrio entre seguridad, latencia y coste -  Documenta de forma exhaustiva la separación de roles (CPD corporativo, hospital local, nube IoMT), la autonomía en fallo de red y el dimensionamiento detallado en proceso, memoria y disco, tanto para el arranque como para el crecimiento futuro ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 4 puntos sobre 4 posibles ##  PROVITA (apartados 4.3 y 4.2.3 de su oferta) En la oferta de la UTE ProVita (Vitalera + Prhoinsa/Ascom) la cobertura de arquitectura tecnológica/entorno tecnológico es muy deficitaria y muy poco concreta. En todo el documento se indica que la plataforma soporta despliegues on -premise, cloud o híbridos y que es multisite/multicentro, pero no se desarrolla un diseño arquitectónico específico para el SALUD ni se justifica una elección clara de modelo. No se encuentra en 4.3 ni en otros apartados una descripción detallada de la arquitectura física/lógica (topología, capas, roles de cada entorno) adaptada al contexto del contrato; remiten a que la definición de arquitectura se hará en la Fase 1 de consultoría, pero esto no permite valoración en la oferta. La memoria afirma que la solución es una plataforma corporativa, agnóstica, escalable, multisite y multicentro, combinando Digistat (hospital) y Vitalera (domicilio), con separación entre BBDD de tiempo real e históricos y modelo de datos normalizado, sin embargo, no se presenta un diagrama ni una arquitectura objetivo concreta para el SALUD: -  No se explicita si el backend se desplegará centralmente en CPD, replicado por hospital, o mixto. -  No se presenta ni justifica una opción (on -prem/híbrida/cloud) con argumentos de latencia, criticidad o costes, más allá de frases genéricas sobre IoMT y multisite. Se habla de forma totalmente genérica (plataforma corporativa multisite, Digistat+Vitalera, IoMT, etc.), sin aterrizar al modelo concreto que se va a implantar en Aragón ni su por qué. En lo relativo a la Continuidad de servicio y soberanía del dato: -  Se menciona el cumplimiento de ENS, seguridad, integración con GUHARA y otros sistemas corporativos, y un modelo operativo avanzado y seguro pero sin ninguna descripción. -  No se detalla un esquema técnico de continuidad de servicio:   -  No se explica explícitamente qué pasa si se cae la conexión entre hospitales y un CPD central o con la nube. -  No se describe que cada hospital pueda operar autónomamente en caso de desconexión, ni cómo se sincronizaría después. -  Sobre la soberanía del dato para SALUD, se alude a integración con la HCE corporativa y cumplimiento normativo, pero no se indica de forma concreta dónde residen físicamente los datos clínicos (CPD SALUD vs nube del proveedor) ni cómo se garantiza que permanecen bajo dominio del SALUD. ## Centralizado vs por centro, y despliegue del portal de telemonitorización: -  La solución se define como multisite/multicentro y plataforma corporativa, lo que sugiere un núcleo centralizado lo que puede comprometer la continuidad de entornos críticos. -  Sobre el portal de telemonitorización: -  Se describe funcionalmente la plataforma de Vitalera (apps/web para paciente y profesional, SDKs para integrarse con apps corporativas, cuestionarios, planes, alertas). -  Pero no se indica de forma explícita cómo se desplegará ese portal en la infraestructura del SALUD (si será un servicio central, si se aloja en nube, si se instala en CPD, si habrá instancias por centro, etc.). ## Consolidación de datos de los centros: -  Se afirma que la plataforma actúa como punto único de consolidación de datos procedentes de dispositivos médicos, sensores domiciliarios, cuestionarios y otros sistemas clínicos, con separación entre base de tiempo real y repositorio histórico. -  No obstante: No se describe cómo se consolida la información entre hospitales y domicilio (qué flujos, qué BBDD centrales, qué integraciones). -  No hay un modelo claro tipo BDTR corporativa + BDH, ni capacidades de esa consolidación (latencias, volúmenes, escalado) ## Como conclusión: -  La UTE ProVita sí declara soporte de despliegues on -premise, cloud e híbridos y una plataforma corporativa multisite/multicentro, pero lo hace a un nivel tan genérico que no permite valoración -  No concreta un modelo arquitectónico específico para el SALUD ni justifica su elección, ni mucho menos sus requisitos. ## No detalla: -  una arquitectura física/lógica clara (centralizada vs por centro), -  mecanismos técnicos de continuidad de servicio ante caídas de red, -  garantías técnicas explícitas de soberanía del dato (localización física y control), -  el modo de despliegue del portal de telemonitorización en la infraestructura corporativa ni un modelo preciso de consolidación y consulta de datos a nivel corporativo   ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 4 posibles -  DEXTRO (apartados 1.5 y 1.8 de su oferta) ## Modelo arquitectónico propuesto: -  La oferta plantea explícitamente un modelo on -premise centralizado recomendado, donde todos los componentes críticos (MoviSalud Core, FHIR Server, CDM, motor de alertas, autenticación y los sistemas Philips MDIP, PIC iX, Guardian) se ejecutan dentro de la infraestructura del SALUS de forma corporativa. -  Esto plantea dudas en cuanto a la autonomía de los Hospitales en entornos críticos, dependencias de latencias, problemas de escalibilidad en el crecimiento del entorno de telemonitorización. -  La arquitectura se basa en microservicios desplegados en contenedores Docker sobre máquinas virtuales gestionadas por el SALUD, con separación en capas (presentación, servicios, datos, interoperabilidad, seguridad), y una organización funcional en cuatro capas: captura, ingesta/procesamiento, interoperabilidad/normalización semántica y visualización (portal profesional y app paciente). -  No resuelve la política de la administración compartida tal y como se solcitaba en el PPTEC -  Se detalla de forma completa la integración funcional con Philips: MDIP como pasarela IoMT hospitalaria, PIC iX como centro de monitorización continua y Guardian como motor EWS, con los eventos integrados en MoviSalud por lo que presenta la consolidación de forma complete. ## Componentes cloud y soberanía del dato: -  En el entorno tecnológico se define qué componentes cloud externos se permiten: nubes de fabricantes de dispositivos (glucómetros, wearables, etc.) y algunos servicios de IA/analítica, siempre integrados vía APIs REST y sin exposición directa de la red interna del SALUD. Se explica que el modelo preferente es mantener todo el dato clínico, históricos, logs y auditorías dentro del CPD del SALUD, usando cloud solo para servicios que, por diseño, deben ejecutarse fuera (nubes de fabricantes, IA). -  Esto da una buena respuesta a la soberanía del dato. ## Continuidad de servicio y alta disponibilidad: -  Se describe la redundancia y tolerancia a fallos: réplicas de contenedores críticos, balanceadores internos, bases de datos con replicación en caliente, backups automáticos y DRP con recuperación en minutos, monitorización 24x7 y alertas técnicas.   -  Se indica un punto importante: la caída parcial de MoviSalud no afecta a la monitorización hospitalaria crítica, porque PIC iX y Guardian mantienen su propia alta disponibilidad certificada por Philips pero no detalla las capacidades de resiliencia de la parte Philips. -  Es decir, la continuidad está razonablemente pensada, aunque no se detalla la autonomía por hospitalpor lo que parece señalar una dependencia a nivel corporativo de dos plataformas de gran tamaño, la de monitorización hospitalaria y la de telemonitorización. ## Centralización vs despliegue por centro -  El diseño que se deduce es fundamentalmente centralizado en CPD del SALUD: -  MoviSalud y los componentes Philips se plantean como parte de una arquitectura on -premise corporativa, no se describen servidores tipo por hospital ni modelos de gateway local con operación autónoma explícita. -  La continuidad en entornos críticos se apoya en la propia HA de Philips y en la robustez del CPD, pero no se explicita un modelo 'por centro' que permita seguir operando localmente si el enlace al CPD cae. -  Esto es una limitación frente modelos que separan infraestructura central y nodos locales por Hospital autónomos. ## Capacidad, dimensionamiento y crecimiento: -  Describe microservicios, contenedores, orquestación, escalabilidad horizontal, separación de capas y tipos de almacenamiento (SQL para estructurado, time -series para señales, repositorios documentales). -  Sin embargo, el documento no entra al detalle numérico en cuanto a: -  vCPU, RAM y disco por servidor o por hospital, más allá del dimensionamiento inicial pero sin indicar de forma clara su crecimiento por número de pacientes/camas, dispositivos. -  capacidad de BBDD corporativas (equivalentes a BDTR/BDH) con métricas de volumen y retención. -  En la práctica, se describe una plataforma preparada para escalar con el proyecto y se justifican las capacidades técnicas (microservicios, contenedores, escalado), pero sin detalle de dimensionamiento explícito y cuantificable. ## Consolidación de datos y telemonitorización: -  MoviSalud actúa como el núcleo de consolidación: recoge señales desde dispositivos domiciliarios (kits, apps, IoMT) y desde hospital (vía Philips y Neuron 3/MDIP), normaliza con CDM y expone por FHIR/HL7. -  Se describe bien la visión longitudinal del paciente y la integración funcional entre domicilio-hospital-SAS, pero de nuevo sin una descripción detallada de BBDD corporativas diferenciadas (tiempo real vs histórico, por centro vs central) No señala necesidades de entornos de Preproducción.  ## Como Conclusión: -  La oferta de Dextro detalla una arquitectura central on -premise basada en microservicios y contenedores, con buena descripción de capas, integración con Philips y medidas de HA/DRP, con los contras anteriormente señalados. -  Aporta una visión clara de soberanía del dato (dato clínico en CPD del SAS, cloud limitado a servicios de fabricantes/IA) y de continuidad de servicio, apoyándose en la HA certificada de los componentes Philips, si bien esta es dependiente de la disponibilidad de dos plataformas centralizadas. -  No define servidores tipo por hospital ni un esquema de nodos locales autónomos, lo que deja pco clara la continuidad en caso de pérdida de conexión con el CPD. -  No presenta un dimensionamiento cuantitativo detallado (CPU, RAM, disco) inicial y de crecimiento que permita evaluar con precisión la adecuación de capacidad para arranque y futuro. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 2 puntos sobre 4 posibles ##  VITHIB (apartados 1.2 y 1.3 de su oferta) La solución se apoya en dos plataformas: -  Philips (PIC iX, Capsule MDIP, etc.) para la monitorización hospitalaria en tiempo real. -  Vitio Platform para telemonitorización IoMT (portal profesional, portal paciente, VitioHub, apps, concentradores). Se indica que ambas se integran mediante estándares HL7, FHIR y DICOM, con interoperabilidad con GUHARA y el ecosistema corporativo, garantizando 'una única visión del paciente a lo largo del continuo asistencial, pero esto se indica de forma totalmente genérica. Incluso, llevando a cabo afirmaciones como que la plataforma de Vitio puede servirse como Software. Platean a los evaluadores dudas razonables sobre la integración real (consolidación de la información hospitalaria y de telemonitorización en una sola BBDD para conformar esa vision transversal por paciente). Se plantea explícitamente definir y diseñar la arquitectura de la Base de Datos de Tiempo Real (BDTR) y la Base de Datos Hist ó rica (BDH), durante la fase de consultoría, lo que impide su valoración real en la oferta. Se describe, con un detalle bajo, el backend de Vitio IoMT y con un detalle razonable la arquitectura de la plataforma de Philips que supone local centralizada: -  Esta centralización plantea dudas en cuanto a la autonomía de los Hospitales en entornos críticos, dependencias de latencias, problemas de escalibilidad en el crecimiento del entorno de telemonitorización NO queda claro (y se señala como gran debilidad de la oferta):   -  Consolidación Philips + Vitio en la misma BBDD -  El documento define conceptualmente BDTR/BDH, pero no especifica de forma explícita si en producción la BDTR/BDH serán únicas para todo el ecosistema (Philips + Vitio) o si cada plataforma mantiene sus propias BBDD y solo se integran a nivel de mensajes/visores. -  No se encuentra una afirmación del tipo: las señales procedentes de Philips PIC iX y las procedentes de Vitio se consolidan en una BDTR/BDH corporativa común, gobernada por el SALUD, con un modelo de datos único. -  Esto deja dudas importantes sobre si el dato queda realmente unificado en un repositorio clínico común o si se mantiene una doble pila de datos (Philips por un lado, Vitio IoMT por otro) unidas solo por visibilidad o interoperabilidad. Se indica que se definirá en la fase de consultoría el modelo de despliegue óptimo (on -premise, nube o híbrido) y se justificará en términos de criticidad, seguridad y costes, pero no fija una arquitectura objetivo cerrada y jsutificada en la oferta. No plantea un diagrama o descripción clara de cómo se distribuyen Philips y Vitio entre CPD, hospitales y nube, ni cómo se materializan las BDTR/BDH (ubicación, tecnologías, rol por centro). ## Continuidad de servicio y soberanía del dato: -  Hay referencias generales a ENS, RGPD, seguridad 'by design' y zero -trust, pero no se describe de forma operativa cómo se garantiza la continuidad en caso de caída de red o de CPD, ni si Philips o Vitio pueden operar de forma autónoma por hospital con posterior reconciliación. -  Tampoco se deja claramente indicado que el dato clínico completo (incluidas ondas) resida bajo dominio exclusivo del SALUD más, si cabe, indicando modelos como SaaS o nubes públicas de forma explícita, ya que no refiere a la nube pública propietaria bajo gobierno del SALUD. ## Centralizado vs por centro y despliegue del portal: -  Se habla de plataforma corporativa y multisite/multicentro, pero no se precisa si el backend IoMT y las BDTR/BDH se alojan centralmente en CPD, si hay instancias locales por hospital, o un modelo mixto por lo que se entiende que no es así. -  El portal de telemonitorización (Vitio) se describe funcionalmente y a nivel de canales (web, apps, SDK, VitioHub), pero no se concreta si es posible o recomendable su despliegue en la infraestructura del SALUD (CPD propio vs cloud del proveedor, modelo IaaS/PaaS, etc.). No hace referencia a entornos de pruebas. ## Como conclusion: -  La UTE Vitio-Hiberus presenta una arquitectura conceptualmente muy diferenciada para la parte hospitalaria (Philips) e IoMT (Vitio), así como la intención de definir BDTR/BDH y un plan de capacidad, pero no parece que sean    - nativamente consolidadas si no una tarea a abordar en el Proyecto lo que supone un riesgo para los plazos exigentes del mismo. -  No deja claramente especificado cómo se consolidan en una misma BBDD corporativa los datos procedentes de Philips y de Vitio, lo que genera dudas sobre la existencia de un repositorio clínico único y homogéneo para señales hospitalarias y domiciliarias. -  Tampoco fija y justifica, en la oferta, una arquitectura objetivo concreta (on -prem/híbrida) ni detalla la distribución CPD/hospital/nube, mecanismos de continuidad de servicio ni la localización final del dato -  No detalla capacidades exactas al arranque y provision al crecimiento. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 1 puntos sobre 4 posibles ## 1.4. Sistema y características del sistema de licenciamiento. (Punto 6 PPT). Hasta 4 puntos ##  TSYSBET (apartado 1.4 de su oferta) La oferta presentada define un modelo de licenciamiento corporativo, ilimitado y de carácter perpetuo, que se alinea de forma clara con los requerimientos establecidos en el PPT en relación con la protección de la inversión pública, la capacidad de despliegue corporativo y la ausencia de restricciones operativas. El derecho de uso completo de la plataforma BC Link y de su ecosistema de aplicaciones clínicas permite al Servicio Aragonés de Salud disponer desde el inicio de una solución extensible, preparada para evolucionar a lo largo de la vida útil del proyecto sin condicionantes derivados del número de usuarios, pacientes, centros o dispositivos. En cuanto al alcance funcional cubierto por las licencias, la oferta detalla de manera expresa la inclusión de todos los módulos funcionales necesarios para dar respuesta al objeto del contrato, incluyendo conectividad biomédica hospitalaria e IoMT, captura y procesamiento de señales, integración multivendor, almacenamiento estructurado, portales clínicos y de paciente, motores de alertas, gestión del ciclo de vida de dispositivos y capacidades de explotación de datos e indicadores. Se indica de forma explícita que no se aplican licencias parciales ni escalados por volumen, garantizando que la solución resulta plenamente operativa sin necesidad de adquirir módulos adicionales, plugins o componentes complementarios no previstos. Desde la perspectiva de la interoperabilidad e integración extremo a extremo, la propuesta describe un conjunto de componentes plenamente integrables entre sí, capaces de cubrir el ciclo completo desde la captura e ingesta de datos hasta su integración con los sistemas corporativos y la explotación analítica. La solución se apoya en estándares abiertos o de amplia adopción en el sector, tales como HL7 v2.x, FHIR, IHE, LDAP/AD, OAuth2 y tecnologías SQL/ETL, lo que asegura su integración con la HCE, sistemas de identidad, repositorios corporativos y servicios de seguridad del Servicio Aragonés de Salud, en coherencia con lo exigido en el PPT.   La oferta también delimita con claridad el alcance del licenciamiento frente a los servicios profesionales, especificando de forma transparente aquellos elementos que no se incluyen en la licencia (servicios de despliegue adicional, nuevas parametrizaciones, desarrollos específicos o ampliaciones funcionales futuras), lo que contribuye a una adecuada previsibilidad presupuestaria. Asimismo, se describe una arquitectura modular y escalable que permite la incorporación progresiva de nuevos casos de uso, equipamiento biomédico y colectivos de pacientes sin impacto sobre la explotación existente ni necesidad de renegociar licencias. Finalmente, en relación con la vigencia, mantenimiento y soporte, la oferta garantiza que el licenciamiento incluye mantenimiento correctivo, preventivo y evolutivo, soporte técnico especializado, derecho de actualización a nuevas versiones y cumplimiento continuo de ENS, RGPD y normativa sanitaria, asegurando la estabilidad y sostenibilidad de la solución. No se identifican elementos sujetos a procesos de descatalogación o fin de vida, comprometiéndose el adjudicatario a mantener la vigencia y soporte de los componentes durante el periodo exigido. En conjunto, el modelo de licenciamiento se considera muy bien adaptado a las prescripciones del PPT. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 3,5 puntos sobre 4 posibles ##  PROVITA (apartado 4.4 de su oferta) La oferta presentada describe un modelo de licenciamiento de carácter corporativo, orientado a proporcionar una visión general del coste y a evitar restricciones artificiales en el uso de la plataforma dentro del alcance del contrato. Si bien este planteamiento resulta conceptualmente coherente con los principios generales recogidos en el PPT, la descripción se mantiene en un nivel excesivamente genérico, sin concretar con suficiente precisión el alcance real del licenciamiento ni los términos técnicos y funcionales que lo sustentan. En relación con el ámbito subjetivo y objetivo del licenciamiento, la oferta indica que la licencia abarcaría a los centros, profesionales y pacientes incluidos en el alcance del contrato, tanto en entorno hospitalario como domiciliario. No obstante, esta cobertura se formula de manera declarativa, sin especificar los mecanismos de control, límites operativos, condiciones de uso o escenarios de crecimiento, lo que dificulta evaluar con claridad el grado de protección efectiva frente a restricciones futuras o necesidades de ampliación del servicio. Respecto a los módulos y componentes incluidos en la licencia, la propuesta se limita a enumerar de forma agregada los 'módulos principales de la plataforma', así como el uso de plugins, drivers y conectores necesarios. Sin embargo, no se aporta una descripción detallada de las características técnicas y funcionales de dichos módulos, ni se identifica de forma individualizada el conjunto de componentes que conforman la solución, lo que impide verificar con precisión si el licenciamiento cubre de manera íntegra todas las funcionalidades necesarias para una respuesta extremo a extremo, tal y como exige el PPT.  Desde el punto de vista de la interoperabilidad e integración, la oferta menciona de forma genérica la inclusión de conectores para los dispositivos y sistemas contemplados en el contrato, pero no detalla los estándares, protocolos o arquitecturas de referencia que garanticen la interoperabilidad entre los distintos componentes de la plataforma ni su integración efectiva con los sistemas corporativos del Servicio Aragonés de Salud. Esta ausencia de concreción técnica limita la evaluación del grado real de alineación con los requisitos del PPT en este ámbito. Finalmente, aunque la propuesta señala la inexistencia de costes ocultos dentro del alcance definido y su alineación con la estructura de costes del mantenimiento y evolución, se introduce una indefinición relevante al remitir cualquier extensión de alcance o necesidades adicionales a acuerdos futuros no descritos. En conjunto, el modelo de licenciamiento se considera solo parcialmente adaptado a las prescripciones del PPT, cumpliendo los principios generales requeridos, pero con un nivel de detalle claramente insuficiente para valorar adecuadamente la cobertura funcional, técnica y de interoperabilidad exigida. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 2 puntos sobre 4 posibles -  DEXTRO (apartado 1.9 de su oferta) La oferta presentada define un modelo de licenciamiento corporativo global que responde de forma directa a los requerimientos del PPT, al contemplar la inclusión de todos los productos, módulos y funcionalidades necesarios para proporcionar una solución completa de análisis de datos extremo a extremo. La licencia propuesta cubre la totalidad de la plataforma MoviSalud, sin limitaciones por número de usuarios, pacientes, centros, camas virtuales o áreas asistenciales, lo que garantiza la disponibilidad funcional íntegra de la solución para el Servicio Aragonés de Salud desde el inicio del proyecto y a lo largo de su evolución. En relación con la descripción detallada de las características técnicas y funcionales de los componentes incluidos en la licencia, la oferta especifica de forma clara que se incluyen todos los módulos funcionales existentes de la plataforma, así como una biblioteca clínica avanzada con más de cuarenta patologías ya desarrolladas, reutilizables y configurables. Asimismo, se indica expresamente que no existen licencias adicionales por módulos, plugins, drivers o funcionalidades internas necesarias para completar la funcionalidad de análisis de datos, lo que asegura que la solución ofertada es plenamente operativa sin necesidad de contrataciones complementarias no previstas. Desde el punto de vista de la integración e interoperabilidad de los componentes, la propuesta describe un ecosistema único en el que todos los elementos de la plataforma son interoperables entre sí, permitiendo cubrir el ciclo completo desde la captura e ingesta de datos hasta la explotación y publicación de servicios analíticos. La solución se apoya en estándares abiertos o de amplia adopción en el sector sanitario, tales como HL7, FHIR, SNOMED CT y LOINC, garantizando la integración con sistemas corporativos y plataformas externas, así como la extensibilidad futura de la solución sin dependencias propietarias restrictivas.   En lo relativo a componentes de terceros, la oferta identifica de forma transparente aquellos elementos externos que cuentan con modelos de licenciamiento propios (videoconferencia, plataformas cloud de fabricantes de dispositivos o servicios avanzados de IA), diferenciándolos claramente de la licencia corporativa de la plataforma. Se indica que estos componentes no son necesarios para cubrir los requisitos funcionales del proyecto y que, en caso de incorporarse, la plataforma garantiza su integración técnica mediante APIs estándar, manteniendo la coherencia del ecosistema sin generar dependencias técnicas ni costes ocultos dentro de la licencia ofertada. Finalmente, en cuanto a la vigencia, soporte y continuidad de los componentes, la oferta establece un modelo de evolución continua con actualizaciones periódicas incluidas, soporte funcional y técnico, y compatibilidad garantizada con los entornos del Servicio Aragonés de Salud. Se asegura expresamente que ninguno de los componentes ofertados se encuentra en proceso de descatalogación o fin de vida, comprometiéndose el adjudicatario a garantizar su vigencia y soporte durante un periodo mínimo de cinco años. En conjunto, el modelo de licenciamiento propuesto se considera plenamente adecuado a las exigencias del PPT, al ofrecer una solución completa, escalable, interoperable, sostenible en el tiempo y alineada con las necesidades estratégicas del Servicio Aragonés de Salud. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 3 puntos sobre 4 posibles -  VITHIB (apartado 1.4 de su oferta) La oferta presentada define un modelo de licenciamiento diferenciado por ámbitos funcionales, distinguiendo entre la plataforma hospitalaria de monitorización PIC iX/Capsule y la plataforma de telemonitorización domiciliaria Vitio. Este planteamiento permite una adecuación funcional a los distintos contextos asistenciales, si bien introduce una fragmentación del modelo de licencias que condiciona su aplicación homogénea a nivel corporativo, alejándose de un esquema plenamente transversal para todo el Servicio Aragonés de Salud. En el ámbito de la monitorización hospitalaria, el licenciamiento se basa en el número de camas, monitores o equipos conectados, evitando la vinculación al número de usuarios o accesos profesionales, lo que resulta adecuado para entornos asistenciales de alta rotación. No obstante, este enfoque supedita la escalabilidad del sistema al crecimiento físico del parque de dispositivos, lo que puede requerir ampliaciones de licencias a medida que se extienda el despliegue, introduciendo un condicionante económico ligado a la evolución del servicio. Respecto a la plataforma de telemonitorización domiciliaria Vitio, la oferta establece una licencia corporativa que incluye los módulos funcionales esenciales (interfaces profesional y paciente, backend, motor de alertas y APIs de integración), garantizando la operativa básica del servicio. Sin embargo, el modelo vincula la licencia al número de kits de telemonitorización activos, lo que implica una dependencia directa del volumen de pacientes monitorizados, limitando la flexibilidad frente a escenarios de crecimiento no lineal del programa asistencial.   Desde el punto de vista de la interoperabilidad e integración, la propuesta contempla mecanismos de conexión con sistemas corporativos mediante APIs y arquitecturas estándar, permitiendo el intercambio de información clínica y técnica. No obstante, la oferta no detalla de forma suficientemente explícita el alcance de la integración extremo a extremo entre los distintos componentes hospitalarios y domiciliarios bajo un único marco de licenciamiento, lo que introduce incertidumbre sobre la homogeneidad funcional del conjunto de la plataforma. Finalmente, en relación con el soporte, mantenimiento y evolución, la oferta incluye servicios de soporte técnico y actualizaciones correctivas, contribuyendo a la estabilidad operativa. Sin embargo, la coexistencia de modelos de licenciamiento basados en dispositivos, camas o kits, junto con exclusiones explícitas de determinados componentes de infraestructura, reduce la previsibilidad presupuestaria a largo plazo y condiciona la escalabilidad corporativa plena. En conjunto, la propuesta se considera parcialmente alineada con las prescripciones del PPT, cumpliendo los requisitos mínimos exigidos, pero con limitaciones estructurales en el modelo de licencias. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 2 puntos sobre 4 posibles ## 2. Metodología de trabajo (Punto 7 PPT) ## 2.1. Planificación del proyecto (máx. 2 ptos.) ##  TSYSBET (apartado 2.1 de su oferta) La metodología de trabajo propuesta presenta un planteamiento coherente, completo y bien estructurado, alineado con los principios de gestión exigidos por el Servicio Aragonés de Salud y con las prescripciones del Punto 7 del PPT. La oferta articula el proyecto mediante un modelo de gestión híbrido que combina prácticas predictivas y ágiles, integrando planificación, gobernanza, aseguramiento de calidad y transferencia de conocimiento, lo que permite una ejecución ordenada, controlada y orientada a resultados verificables dentro del plazo contractual establecido. En relación con la Fase 1, la metodología define de forma clara los objetivos, actividades y entregables asociados al análisis inicial del contexto asistencial y tecnológico del Servicio Aragonés de Salud. Se describen actuaciones específicas de auditoría de equipamiento biomédico, análisis de sistemas corporativos, evaluación de flujos asistenciales y diseño de la arquitectura objetivo, así como la elaboración de documentos alineados con los entregables exigidos en el PPT. Este enfoque permite disponer de una base sólida para el diseño del despliegue y para la toma de decisiones posteriores, garantizando una comprensión adecuada del entorno de partida.   Respecto a la Fase 2, la propuesta desarrolla con suficiente nivel de detalle las actividades de implantación, integración, parametrización y formación, contemplando la ejecución en paralelo de los distintos entornos asistenciales y la validación progresiva de los resultados. Se identifican mecanismos de control, pruebas funcionales, validaciones técnicas y acciones de capacitación dirigidas a los profesionales del Servicio Aragonés de Salud, asegurando la correcta puesta en marcha de la solución conforme al Plan de Implantación definido en la fase anterior. Finalmente, en cuanto a la Fase 3 y a la transferencia tecnológica, la metodología incluye actividades de seguimiento de la actividad, estabilización del sistema, medición de indicadores y elaboración de informes finales, junto con acciones de transferencia de conocimiento y documentación. Se contemplan mecanismos de gobernanza, reporting y mejora continua que permiten consolidar el uso de la plataforma y asegurar su sostenibilidad operativa. En conjunto, la metodología se considera plenamente alineada con las prescripciones técnicas del PPT, presentando un grado de desarrollo, coherencia y viabilidad adecuados. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 2 puntos sobre 2 posibles -  PROVITA (apartado 5.1 de su oferta) La metodología de trabajo propuesta se estructura formalmente en fases y adopta un enfoque híbrido Agile-Waterfall, alineándose de manera general con la organización por fases prevista en el PPT. La oferta identifica los principales ejes metodológicos planificación, equipo de trabajo y seguimiento- y plantea como objetivo la reducción de riesgos y la adopción por parte de los usuarios. No obstante, el planteamiento metodológico se mantiene en un nivel descriptivo y genérico, sin desarrollar de forma suficientemente concreta cómo se articulará la ejecución real del proyecto en el contexto organizativo y tecnológico específico del Servicio Aragonés de Salud. En relación con la Fase 1, la propuesta describe actividades de análisis de procesos asistenciales, definición de arquitectura técnica e interoperabilidad e inventario de equipamiento, fijando hitos generales y una duración estimada. Sin embargo, el desarrollo metodológico no concreta con el detalle requerido los mecanismos de validación de resultados, la elaboración y aprobación formal de los entregables exigidos en el PPT, ni la realización de pruebas de carga y rendimiento de la plataforma, aspectos que resultan obligatorios para la correcta finalización de esta fase según el pliego. Respecto a la Fase 2, la metodología contempla la implantación técnica, las integraciones con sistemas corporativos, la parametrización de programas de telemonitorización y la puesta en marcha progresiva por centros. No obstante, la descripción de estas actividades es principalmente enumerativa, sin detallar la secuencia operativa, los criterios objetivos de aceptación, ni la dependencia explícita del Plan de Implantación definido en la fase anterior, lo que dificulta evaluar la viabilidad real del despliegue conforme a los plazos y condiciones establecidos en el PPT.   Finalmente, en cuanto a la Fase 3 y a la transferencia tecnológica, la oferta incluye referencias a seguimiento, optimización, gestión de riesgos y definición de mejoras, así como a la existencia de un registro de riesgos. Sin embargo, estos elementos se presentan de forma insuficientemente desarrollada, sin detallar los procedimientos sistemáticos de mantenimiento preventivo y correctivo, la gestión continuada de indicadores, ni los mecanismos formales de validación y transferencia de entregables y formación exigidos en el apartado 7.4 del PPT. En conjunto, la metodología se considera limitadamente alineada con las prescripciones técnicas, adecuada en su planteamiento general, pero con carencias relevantes en concreción, trazabilidad y exhaustividad. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 2 posibles -  DEXTRO (apartado 2.1 de su oferta) La metodología de trabajo propuesta se articula formalmente conforme a las fases establecidas en el PPT (Análisis y Consultoría, Implantación e Integración y Seguimiento), identificando su encaje con el horizonte temporal del contrato. No obstante, el planteamiento metodológico se apoya de manera predominante en un enfoque intensivo orientado a un caso de uso concreto, lo que limita su capacidad de dar respuesta de forma equilibrada y homogénea al conjunto de necesidades, escenarios asistenciales y procesos organizativos previstos en el pliego para el Servicio Aragonés de Salud. En relación con la Fase 1, la oferta describe numerosas actividades de análisis técnico, funcional y clínico, si bien el desarrollo metodológico presenta carencias relevantes en cuanto a sistematización y alcance general. El análisis se centra principalmente en el despliegue del MVP asociado al caso DM2, sin concretar de forma suficiente cómo se abordará el análisis global del entorno corporativo del SAS, las pruebas de carga y rendimiento de la plataforma en escenarios ampliados, ni la reutilización de los entregables para otros procesos asistenciales distintos del piloto inicial exigido en el PPT. Respecto a la Fase 2, la metodología detalla con profundidad las tareas de implantación, integración y pilotaje del MVP, pero lo hace desde una perspectiva altamente específica y dependiente de una configuración concreta, sin desarrollar mecanismos claros de adaptación del plan de implantación a otros centros, dispositivos o unidades asistenciales. Esta orientación reduce la flexibilidad metodológica requerida para un despliegue corporativo progresivo, tal y como contempla el PPT. Finalmente, en cuanto a la Fase 3 y a la transferencia tecnológica, la propuesta aborda el seguimiento y la estabilización del sistema de forma genérica, sin definir con suficiente precisión los procedimientos continuados de mantenimiento preventivo y correctivo, la gestión sistemática de indicadores, ni los mecanismos formales de validación, aceptación y transferencia de entregables previstos en el apartado 7.4 del PPT. En conjunto, la metodología se considera solo parcialmente alineada con las prescripciones técnicas, adecuada en su estructura formal pero con limitaciones significativas en su alcance, generalización y concreción operativa.   ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 1,5 puntos sobre 2 posibles -  VITHIB (apartado 2.1 de su oferta) La metodología de trabajo presentada se apoya principalmente en una planificación temporal mediante cronograma, identificando fases, hitos y entregables alineados nominalmente con las fases establecidas en el PPT. Se incluyen referencias explícitas a las actividades de análisis y consultoría, implantación e integración, y seguimiento de la actividad, así como a los entregables exigidos en cada una de ellas. No obstante, el enfoque metodológico se limita en gran medida a una enumeración de tareas y resultados, sin desarrollar un marco operativo que describa cómo se ejecutarán y validarán dichas actividades en el contexto organizativo y tecnológico específico del Servicio Aragonés de Salud. En relación con la Fase 1 - Análisis y consultoría, la oferta identifica correctamente los ámbitos de actuación (requisitos técnicos, funcionales y de seguridad, interoperabilidad, flujos clínicos, experiencia de usuario y KPIs) y asocia estos trabajos a los entregables exigidos en el PPT. Sin embargo, la descripción metodológica es excesivamente sintética, sin detallar la dinámica de trabajo con los equipos del Servicio Aragonés de Salud, los mecanismos de contraste y validación de los análisis realizados, ni la forma en que se abordarán aspectos críticos como las pruebas de rendimiento o la priorización de necesidades, lo que limita la evaluación de la solidez del planteamiento. Respecto a la Fase 2 - Implantación e integración, se contemplan las actividades fundamentales de instalación de infraestructura, integración con sistemas existentes, validación de interoperabilidad, suministro de kits y formación. No obstante, estas actuaciones se presentan sin un desarrollo metodológico suficiente, careciendo de una explicación clara sobre la secuencia de ejecución, los criterios de aceptación de cada hito o la dependencia efectiva del Plan de Implantación definido en la fase previa, elementos clave exigidos por el PPT para garantizar la viabilidad técnica y organizativa del despliegue. Por último, en cuanto a la Fase 3 y a la gestión transversal del proyecto, la oferta incorpora un apartado específico de gestión de riesgos y referencias a certificaciones de calidad relevantes, lo que evidencia una orientación general hacia el control y la mejora continua. Sin embargo, estos elementos se presentan de forma genérica y poco contextualizada, sin integrarse de manera clara en un modelo de seguimiento operativo, de mantenimiento preventivo y correctivo, ni en un esquema de transferencia tecnológica y validación de entregables conforme a lo establecido en el apartado 7.4 del PPT. En conjunto, la metodología se considera parcialmente alineada con las prescripciones técnicas, adecuada en su planteamiento básico, pero con carencias relevantes de desarrollo, concreción y trazabilidad.   ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 1 puntos sobre 2 posibles ## 2.2. Equipo de trabajo (Composición, cualificación y número de efectivos (máx. 2 ptos.) -  TSYSBET (apartado 2.2 de su oferta) La oferta presenta un modelo de equipo de trabajo excepcionalmente sólido, maduro y plenamente alineado con las exigencias del PPT, definiendo de forma inequívoca la figura del Responsable del Proyecto como interlocutor único ante el Servicio Aragonés de Salud, así como su integración directa con la estructura de gobernanza del contrato. El modelo organizativo incorpora mecanismos avanzados de coordinación, comités de dirección y seguimiento, reporting estructurado, control de KPIs y gestión activa de riesgos, asegurando una supervisión continua de la ejecución y una toma de decisiones ágil y trazable en todo el ciclo del proyecto. En cuanto a la composición y cualificación del equipo, la propuesta cubre de manera exhaustiva todos los perfiles mínimos exigidos en el pliego (responsable de proyecto, arquitecto de sistemas, especialista en integraciones, ingeniero de software y consultor funcional), desarrollando además con gran nivel de detalle sus responsabilidades, tareas y encaje dentro del proyecto. La incorporación de un equipo extendido multidisciplinar (producto, I+D, soporte clínico, ciberseguridad y analítica de datos), disponible de forma inmediata y sin impacto contractual, refuerza de manera notable la capacidad de respuesta ante contingencias técnicas, organizativas o asistenciales, aportando un valor añadido especialmente relevante en un entorno sanitario crítico. Respecto al dimensionamiento, dedicación y continuidad, la oferta destaca por su alto grado de concreción y compromiso, detallando dedicaciones por perfil conforme a los mínimos exigidos en el PPT, garantizando la estabilidad de los recursos durante toda la vigencia del contrato y estableciendo mecanismos explícitos de respaldo y escalado de equipo. La matriz RACI presentada, junto con la asignación clara de responsabilidades por fase e hito contractual, permite verificar de forma objetiva la capacidad del equipo para ejecutar el proyecto sin dependencias externas, asegurar la continuidad operativa y cumplir los plazos y niveles de servicio establecidos. Finalmente, la experiencia acreditada del equipo, su conocimiento directo del entorno del Servicio Aragonés de Salud, la especialización en integración biomédica e interoperabilidad sanitaria avanzada, así como la alineación plena con los estándares normativos (HL7, FHIR, DICOM, SNOMED, ENS), consolidan una propuesta de máxima solvencia técnica y organizativa. El equipo propuesto constituye una garantía real y demostrable de ejecución exitosa, adopción clínica efectiva y sostenibilidad del servicio a largo plazo.   ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 2 puntos sobre 2 posibles -  PROVITA (apartado 5.2 de su oferta) La oferta presenta una descripción estructurada del equipo y del modelo de gobernanza alineada con el PPT, identificando la existencia de un Responsable de Proyecto como interlocutor principal ante el Servicio Aragonés de Salud y detallando la interacción con la figura de Responsable del contrato por parte de la Administración. El organigrama propuesto establece líneas de coordinación, canales de comunicación (comités de seguimiento, reuniones técnicas y circuitos de escalado) y mecanismos de control (seguimiento en herramientas, reporting y gestión de incidencias), lo que evidencia una orientación clara a la supervisión de la ejecución conforme a las instrucciones del órgano gestor. En cuanto a la composición del equipo, la propuesta define un conjunto de perfiles que cubren, con carácter general, las exigencias mínimas del PPT: responsable/jefe de proyecto, perfiles de arquitectura, integración, desarrollo e implantación y consultoría funcional. Además, incorpora roles complementarios (seguridad/ENS, calidad/testing, dirección de integraciones) que contribuyen a reforzar el enfoque de cumplimiento, trazabilidad y aseguramiento de la calidad. No obstante, la oferta remite parte de la información determinante (experiencia y currículum) al sobre correspondiente, lo que reduce el detalle verificable en esta memoria sobre la acreditación efectiva de requisitos críticos (años de experiencia y certificaciones deseables) exigidos para los perfiles principales. Respecto a dimensionamiento, dedicaciones y contingencias, la oferta expone un compromiso de estabilidad del equipo, mecanismos de gestión de rotación y medidas para garantizar continuidad, así como la disponibilidad de perfiles especializados para mantener niveles de servicio. Sin embargo, la propuesta no concreta de forma suficientemente objetiva las dedicaciones estimadas por categoría ni el número de efectivos por perfil, elementos expresamente requeridos en el PPT para valorar la dimensión y capacidad del equipo para la puesta en marcha e implantación del caso de uso, lo que limita la evaluación de su adecuación cuantitativa y de su capacidad real de absorción de contingencias. En conjunto, el equipo y el esquema organizativo se consideran adecuados y alineados en términos cualitativos con lo solicitado en el PPT (roles, funciones, gobernanza, coordinación con el Responsable del contrato y orientación a seguimiento/transferencia). No obstante, el nivel de concreción es insuficiente en aspectos clave para la valoración   (dimensionamiento y dedicaciones, y evidencia integrada de requisitos de experiencia/certificación en esta memoria), lo que justifica una adecuación parcialmente completa. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 2 posibles ##  DEXTRO (apartado 2.2 de su oferta) La oferta describe de manera clara y estructurada el modelo organizativo y el organigrama del equipo, identificando de forma expresa la figura del Director/Responsable del Proyecto como interlocutor principal ante el Servicio Aragonés de Salud, en coherencia con lo exigido en el PPT. Asimismo, se define un modelo de coordinación con el responsable del contrato designado por la Administración y se establecen mecanismos formales de gobernanza, comités de seguimiento y coordinación entre los distintos actores tecnológicos implicados, garantizando una adecuada supervisión y control de la ejecución del proyecto. En cuanto a la composición del equipo, la propuesta cubre de forma completa y explícita todos los perfiles mínimos exigidos en el PPT (responsable de proyecto, arquitecto de sistemas, especialistas en integraciones, ingenieros de software y consultores funcionales), incorporando además perfiles complementarios que refuerzan áreas críticas como pruebas, documentación, soporte y e-learning. La descripción de roles y responsabilidades es detallada y coherente con las funciones y tareas definidas en el pliego, evidenciando una correcta comprensión de las necesidades técnicas, clínicas y organizativas del proyecto. Respecto al dimensionamiento y dedicación, la oferta aporta un cuadro detallado de recursos, indicando número de efectivos por perfil, porcentajes de dedicación y horas asignadas, lo que permite valorar de manera objetiva la capacidad real del equipo para afrontar la implantación del caso de uso en el plazo contractual establecido. Este nivel de concreción responde de forma directa a las exigencias del PPT y demuestra una planificación adecuada para la ejecución en paralelo de las distintas líneas de trabajo, así como para la gestión de posibles contingencias de personal. Por último, la propuesta acredita de forma suficiente la experiencia, capacitación y certificaciones de los perfiles clave, incluyendo certificaciones en gestión de proyectos, metodologías ágiles y estándares de interoperabilidad sanitaria, así como experiencia previa en implantaciones en entornos sanitarios complejos. El modelo de colaboración con el Servicio Aragonés de Salud, basado en roles espejo y presencia operativa continuada, refuerza la viabilidad del planteamiento. En conjunto, el equipo propuesto se considera plenamente alineado con las prescripciones técnicas, adecuado en dimensión, cualificación y organización.   ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 2 puntos sobre 2 posibles -  VITHIB (apartado 2.2 de su oferta) La oferta describe de manera muy detallada y estructurada el equipo de trabajo, identificando de forma expresa todos los perfiles exigidos en el PPT y designando claramente la figura del Responsable de Proyecto como interlocutor principal ante el Servicio Aragonés de Salud. El modelo organizativo presentado garantiza una adecuada coordinación con el Responsable del contrato designado por la Administración y contempla mecanismos de seguimiento, control de hitos y gestión de riesgos alineados con las exigencias del pliego, lo que facilita una supervisión eficaz de la ejecución del servicio. En cuanto a la composición y cualificación del equipo, la propuesta cubre plenamente los perfiles mínimos requeridos (responsable de proyecto, arquitecto de sistemas y de soluciones, especialistas en integraciones, ingenieros de software y consultores funcionales), incorporando además perfiles adicionales de alto valor (DevOps, ingeniero de datos, analista BI, responsables de calidad y testing) que refuerzan ámbitos críticos como la interoperabilidad, la explotación del dato, la estabilidad operativa y la evaluación mediante indicadores. La descripción individualizada de cada rol, junto con la acreditación de experiencia y formación, evidencia una adecuada correspondencia con las funciones y tareas definidas en el PPT. Respecto al dimensionamiento y capacidad técnica, la oferta concreta el número total de profesionales asignados, su especialización y la cobertura de todas las áreas clave del proyecto, lo que permite valorar de forma objetiva la suficiencia del equipo para la implantación del caso de uso exigido. Asimismo, la disponibilidad de recursos técnicos, herramientas de desarrollo, laboratorio de pruebas y equipamiento específico para validación de dispositivos y pruebas de interoperabilidad aporta un valor añadido relevante y refuerza la viabilidad técnica del planteamiento, especialmente en un entorno sanitario de alta complejidad. En conjunto, el equipo propuesto se considera plenamente adecuado y alineado con las prescripciones técnicas del PPT, tanto por la cobertura de perfiles exigidos como por el elevado nivel de especialización, experiencia y medios puestos a disposición del proyecto. El grado de detalle aportado permite verificar la capacidad del licitador para asegurar la correcta ejecución del contrato, la continuidad del servicio y la implantación efectiva de la solución. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 2 puntos sobre 2 posibles ## 2.3. Transferencia tecnológica y entregables (máx. 2 ptos.)  -  TSYSBET (apartado 2.3 de su oferta) La propuesta de T-Systems y Better Care se adecúa de forma muy alta a lo requerido en el punto 7.4 del PPT, al plantear una transferencia tecnológica continua y verificable, con entrega de documentación 'viva' en formatos normalizados, validación por hitos y un catálogo de entregables muy completo (arquitectura, manuales, guías de integración, inventarios, evidencias de pruebas, plan de soporte/mantenimiento y acta formal de transferencia). Asimismo, vincula la formación y la entrega documental a cada fase del proyecto (consultoría-implantación-seguimiento), incorporando mecanismos de shadowing, comités de transferencia y criterios de aceptación, lo que refuerza la trazabilidad y la autonomía real del SALUD. Como conclusión, la oferta no se limita a enunciar formación y manuales, sino que estructura la transferencia como un proceso gobernado y auditable, alineado con ENS/RGPD y con los estándares de interoperabilidad, garantizando que el conocimiento y la documentación pasan al repositorio del proyecto y que ninguna actividad se considera cerrada sin capacitación y validación. Se otorga puntuación máxima por cobertura exhaustiva de entregables, enfoque progresivo y formalización de la transferencia con evidencias y actas de cierre. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 2 puntos sobre 2 posibles -  PROVITA (apartado 2.3 de su oferta) La oferta contempla un plan de transferencia de conocimiento que incluye formación técnica dirigida a los equipos de sistemas e ingeniería clínica, así como formación funcional para los profesionales sanitarios usuarios de la plataforma. Asimismo, se prevé la entrega de documentación básica y necesaria para la operación del sistema, incluyendo manuales de usuario y administración, guías de integración y procedimientos de operación y gestión de incidencias. Este planteamiento resulta coherente con el objetivo del PPT de garantizar la autonomía progresiva del Servicio Aragonés de Salud en la explotación y evolución de la solución. No obstante, la propuesta se formula de manera genérica, sin detallar el formato concreto de los entregables, los mecanismos de validación por parte del Servicio Aragonés de Salud, ni la trazabilidad de la documentación generada como entregables formales integrados en el repositorio del proyecto. Tampoco se explicita de forma expresa el condicionamiento del cierre de actividades a la validación de la formación, tal y como establece el PPT. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 2 posibles -  DEXTRO (apartado 2.3 de su oferta)    La propuesta de DEXTRO presenta una adecuación global elevada a los requisitos establecidos en el apartado 7.4 del PPT, al definir la transferencia tecnológica como un proceso continuo y documentado a lo largo de todas las fases del proyecto. Se contempla la generación sistemática de documentación técnica y funcional, su validación formal por parte del Director del Proyecto del SAS y su incorporación a un repositorio estructurado, garantizando así el acceso permanente del Servicio Aragonés de Salud al conocimiento generado durante la ejecución del contrato. Asimismo, se recoge de forma expresa la obligatoriedad de impartir formación a técnicos y usuarios finales como condición previa al cierre de las actividades, en coherencia con lo exigido en el pliego. No obstante, aunque el planteamiento es sólido y cumple los mínimos exigidos, la propuesta se centra fundamentalmente en la descripción exhaustiva de la documentación y los entregables, sin concretar con el mismo nivel de detalle los mecanismos de verificación práctica de la transferencia efectiva de conocimiento ni los criterios objetivos de evaluación de la capacitación alcanzada por los distintos perfiles del SAS. En consecuencia, aun tratándose de una oferta bien alineada con el PPT y técnicamente solvente, se considera que el grado de desarrollo y concreción no alcanza el máximo nivel posible en este apartado . ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 1,5 puntos sobre 2 posibles -  VITHIB (apartado 2.3 de su oferta) La propuesta de la UTE muestra una adecuación notable a los requisitos del apartado 7.4 del PPT, al plantear la transferencia tecnológica como un proceso estructurado, planificado por fases y orientado a garantizar la autonomía operativa del Servicio Aragonés de Salud. Se describen de forma clara los objetivos, el alcance y la metodología de la transferencia, incorporando un plan formativo amplio y diferenciado por perfiles (técnico, explotación y clínico), así como un conjunto relevante de entregables documentales (manuales, guías, procedimientos, actas de transferencia e informes de evaluación). Asimismo, se contempla expresamente la validación del conocimiento adquirido mediante evaluaciones, encuestas de satisfacción y un cierre formal de la transferencia, en línea con el espíritu del pliego. No obstante, pese a su enfoque completo y alineado con buenas prácticas (ISO, ITIL, VBHC), la propuesta presenta un grado de reiteración elevado y un nivel de detalle muy extenso, que diluye en parte la concreción operativa exigida por el PPT en cuanto a formatos normalizados, mecanismos de validación por parte del SALUD y trazabilidad directa de los entregables dentro del repositorio corporativo del proyecto. En consecuencia, aun tratándose de una oferta bien estructurada y claramente alineada con los objetivos de transferencia de conocimiento y capacitación, se considera que el nivel de ajuste y precisión no alcanza el máximo exigible en este criterio.   ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 1,5 puntos sobre 2 posibles ## 2.4. Metodología de seguimiento y control (máx. 2 ptos.) -  TSYSBET (apartado 2.4 de su oferta) La oferta en este punto cubre bien lo esencial (comités, checkpoints por fase, herramientas tipo MS Project/Confluence/JIRA, registro de riesgos y reporting) pero en su formulación inicial es más declarativa y con menos detalle operativo, aunque mantiene coherencia y trazabilidad suficiente. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 2 puntos sobre 2 posibles -  PROVITA (apartado 5.4 de su oferta) La oferta presenta un marco correcto basado en mejora continua y seguimiento, pero con un nivel de especificación menor (menos concreción en cadencias, indicadores, herramientas y circuitos de control), por lo que su robustez es más limitada, con un nivel correcto, pero menos concreto. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 2 posibles -  DEXTRO (apartado 2.4 de su oferta) La oferta es muy completa y operativizable, al definir una gobernanza multinivel (Comité Directivo, Técnico y Científico-Asistencial), una PMO como núcleo de control, cadencias claras (semanal/quincenal/mensual), gestión ITIL de incidencias-problemas-cambios, registro vivo de riesgos, control de calendario (Gantt vivo, alertas tempranas) y cuadro de mando con indicadores, aportando visibilidad continua y mecanismos formales de escalado y validación. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 2 puntos sobre 2 posibles  ##  VITHIB (apartado 2.5 de su oferta) La propuesta con oficina de gestión + Redmine, comités y un sistema de indicadores/ANS muy desarrollado, incluso con índice FQE y planes de mejora, resulta sólida en el control del servicio y reporting, aunque está más orientada a operación/ANS y ticketing que a la gobernanza específica del proyecto y del MVP, y su extensión y complejidad pueden penalizar la claridad y focalización. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 1 puntos sobre 2 posibles ## 2.5. Normas de calidad seguidas por la empresa (máx. 2 ptos.) ##  TSYSBET (apartado 2.5 de su oferta) La oferta presenta un enfoque de calidad integral y estructurado (planificaciónaseguramiento-control-mejora continua), enfatizando calidad 'by design', auditoría y trazabilidad por fases, y una orientación clara a seguridad del dato y continuidad asistencial. Declara cumplimiento regulatorio sanitario de alto nivel para entornos críticos (menciona producto sanitario CE clase IIb) y un marco de seguridad con SGSI certificado (se citan ISO 27001/27701/ENS), además de contemplar pruebas unitarias, de integración y UAT, y un conjunto de KPIs de calidad (disponibilidad, interoperabilidad, seguridad, datos, usabilidad, continuidad asistencial, rendimiento). El planteamiento es coherente con un despliegue sanitario y cubre bien los objetivos del PPT, aportando métricas operativas y disciplina de calidad continuada. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 2 puntos sobre 2 posibles ##  PROVITA (apartado 5.5 de su oferta) La oferta plantea un marco de calidad correcto y razonable para un proyecto sanitario, apoyándose en buenas prácticas de gestión de calidad (menciona ISO 9001 'o equivalentes'), y en seguridad de la información alineada con ISO 27001 y ENS ALTO, además de prácticas de desarrollo seguro (pruebas automatizadas, revisiones de código y validación en preproducción). Con ello cubre los ejes básicos que pide el PPT: asegurar calidad del servicio, seguridad y un ciclo de despliegue controlado antes de producción. No obstante, el planteamiento se formula de forma genérica y en parte condicionada ('en caso de aplicar', 'alineamiento con'), sin aportar un listado de certificaciones efectivamente acreditadas ni referencias explícitas a normas específicas de software sanitario / producto sanitario (p. ej., ISO 13485, IEC 62304, MDR) que elevarían el nivel de evidencia regulatoria en un entorno clínico.    ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 1 puntos sobre 2 posibles -  DEXTRO (apartado 2.5 de su oferta) La propuesta articula un sistema de aseguramiento de calidad transversal a todo el ciclo de vida (diseño, desarrollo, integración, pruebas, documentación, formación, validación y puesta en producción), con trazabilidad requisitos-tareas-pruebas-validación y control de configuración/cambios. Aporta además un marco de certificaciones y cumplimiento muy pertinente para salud: ISO 9001 y ISO 13485 para gestión de calidad en entorno sanitario; ENS (certificado en 2025 para MoviSalud) y referencia a ISO 27001 (indicando que está en proceso), junto con GDPR/LOPDGDD y evidencias para auditoría MRR. En el ámbito de producto sanitario hospitalario, incorpora componentes Philips con marcado CE clase IIb y referencias a MDR y normas técnicas relevantes (p. ej., IEC 62366, IEC 62304/82304). También detalla gestión de riesgos/no conformidades (registro vivo, causa raíz, CAPA) y pruebas multinivel incluyendo seguridad y rendimiento. La propuesta está bien fundamentada y orientada a auditoría y trazabilidad; la ligera minoración se justifica porque parte del marco (ISO 27001) se declara 'en proceso' para un actor concreto, aunque el conjunto queda sólidamente cubierto. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 1.5 puntos sobre 2 posibles -  VITHIB (apartado 2.5 de su oferta) La propuesta define un marco de calidad y cumplimiento normativo excepcionalmente completo, con un inventario explícito de estándares aplicables a producto sanitario y software médico (MDR 2017/745, RD 192/2023, IEC/ISO 62304, IEC 82304-1, IEC 60601-1-8, ISO 14155), gestión de calidad (ISO 13485, ISO 9001), gestión de riesgos (ISO 14971, ISO 31000), seguridad (ENS RD 311/2022 ALTO, ISO 27001:2022, ISO 27017/27018, OWASP, IEC 81001-5-1), privacidad (RGPD/LOPDGDD e ISO 25237), accesibilidad/usabilidad (ISO 62366, RD 1112/2018, WCAG 2.2) e interoperabilidad (HL7 v2, FHIR, SNOMED CT, LOINC, ISO/IEEE 11073). Además, describe con detalle un enfoque Security by Design y Zero Trust, evidencias de seguridad previas a producción (SAST, SBOM, pentest externo), gestión continua de vulnerabilidades (NIST NVD), cifrado robusto, retención ampliada de logs, arquitectura perimetral (NGFW/WAF), federación de identidad (SSO/cl@ve), y resiliencia (IaC, backups, alta disponibilidad). El nivel de especificación, trazabilidad y medidas verificables satisface plenamente el objetivo del PPT de asegurar estándares de calidad y regulaciones del sector salud, justificando la puntuación máxima. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 2 puntos sobre 2 posibles   ## 3. Participación y contribuciones acreditadas en proyectos similares (Max. 5 puntos) Se valorará la oferta del licitador que acredite el desarrollo de al menos un proyecto de implantación similar en el ámbito sanitario en los últimos 5 años y de qué forma puede contribuir a la solución propuesta ##  TSYSBET (apartado 3 de su oferta) La propuesta acredita de manera amplia y consistente su participación en proyectos similares en el ámbito sanitario, aportando un volumen elevado de implantaciones reales, operativas y recientes en el Sistema Nacional de Salud, muchas de ellas de carácter corporativo, multicentro y clínicamente crítico, plenamente alineadas con el objeto del contrato. Se documentan referencias de alto valor como el Hospital Clínic de Barcelona (desde 2012), Sant Pau, ICS (ARGOS), Bellvitge, Arnau de Vilanova (UCI extendida), Consorci Sanitari Maresme i Selva, Hospital Asil de Granollers y proyectos estratégicos financiados con fondos estatales como HES Connecta, cubriendo conectividad biomédica agnóstica, monitorización avanzada en UCI y quirófanos, continuidad asistencial hospital-domicilio, telemonitorización IoMT y despliegues regionales complejos. La oferta no solo enumera experiencias, sino que explicita claramente la transferencia de aprendizajes, capacidades técnicas y conocimiento del ecosistema aragonés, incluyendo base instalada previa en el SALUD y equipos locales con continuidad en el tiempo, lo que refuerza la contribución directa a la solución propuesta y reduce riesgos de implantación. En conjunto, la experiencia acreditada es sólida, extensa, contrastable y directamente aplicable al proyecto. ## Se valora el desarrollo este apartado en la oferta de TSYSBET con: 5 puntos sobre 5 posibles ##  PROVITA (apartado 6 de su oferta) La oferta acredita claramente proyectos similares en el ámbito sanitario en los últimos 5 años y, además, describe de forma convincente cómo esa experiencia contribuye a la solución propuesta. La contribución al SAS se concreta en reutilización de conectores/patrones, know-how de gestión del cambio por fases, y elementos diferenciales aplicables (modelo operativo seguro, módulo de captura 'scan', y módulo de alertas con clasificación sanitaria). Aporta varias implantaciones comparables y una trazabilidad clara de transferibilidad al contexto del SAS. Sin embargo, en el extracto, parte de la acreditación queda formulada de manera descriptiva y la evidencia documental (certificados/actas/contratos o hitos verificables) no se muestra explícitamente, aunque la consistencia y relevancia de los casos es alta. ## Se valora el desarrollo este apartado en la oferta de PROVITA con: 3 puntos sobre 5 posibles  ##  DEXTRO (apartado 3 de su oferta) La oferta acredita de forma suficiente y pertinente la participación en proyectos similares en el ámbito sanitario en los últimos cinco años, especialmente en el terreno de la integración de sistemas clínicos, dispositivos médicos y plataformas de monitorización, alineados con los requisitos del pliego. Destacan referencias corporativas de alto impacto como el proyecto RADELEC del Servicio de Salud de las Illes Balears, con integración regional HL7 v2 bidireccional con múltiples HCE, normalización semántica y despliegue multicentro, así como su réplica en varias comunidades adicionales; las integraciones de monitorización en entornos críticos con dispositivos Philips mediante perfiles IHE PCD, normalización SNOMED CT/LOINC y evolución hacia FHIR R4; y el proyecto de telemonitorización domiciliaria corporativa en el Servicio Cántabro de Salud (2024-2025), con integración multivendor IoMT y alineación con los principios del GT6 del SNS. A ello se suma un equipo interno especializado en interoperabilidad sanitaria (HL7, FHIR, IHE PCD, IEEE 11073) y la aportación específica al caso de uso de Diabetes Mellitus tipo II mediante la integración de DiabeText en MoviSalud, respaldada por evidencia científica y con una contribución claramente explicada en términos de adherencia, control metabólico y continuidad asistencial. En conjunto, la experiencia está bien documentada, es transferible al contexto del SAS y muestra contribución concreta a la solución propuesta. Sin embargo, parte de las referencias se describen de forma agregada sin detallar hitos contractuales cerrados o resultados cuantificados homogéneos para todos los casos. ## Se valora el desarrollo este apartado en la oferta de DEXTRO con: 4 puntos sobre 5 posibles -  VITHIB (apartado 3 de su oferta) La oferta acredita experiencia relevante y contrastada en proyectos de telemonitorización sanitaria, especialmente en Hospitalización a Domicilio y seguimiento de pacientes crónicos, con implantaciones reales y operativas en varios hospitales públicos de referencia (Hospital Universitario de Navarra, Gregorio Marañón, Reina Sofía de Tudela, Fundación Alcorcón, entre otros), aportando además resultados clínicos medibles, uso continuado de la plataforma y difusión científica en congresos nacionales. Resulta especialmente significativa la experiencia previa de la solución PIC iX dentro del propio Servicio Aragonés de Salud, con más de una década de funcionamiento estable en unidades críticas, lo que reduce riesgos de compatibilidad y facilita la adopción. Asimismo, la participación de Hiberus refuerza la capacidad de la UTE en proyectos corporativos de transformación digital e interoperabilidad en servicios regionales de salud, incluyendo la adjudicación reciente de un proyecto PADP para Osasunbidea. No obstante, aunque la experiencia es sólida, se concentra principalmente en telemonitorización domiciliaria y entornos concretos, con menor evidencia de despliegues corporativos integrales de alcance regional equivalente al del presente contrato. ## Se valora el desarrollo este apartado en la oferta de VITHIB con: 3 puntos sobre 5 posibles   ## Se expone a continuación un cuadro-resumen de valoración: | Item a valorar | Máx. | TSYSBET | PROVITA | DEXTRO | VITHIB | |-----------------------------------------|----------|-----------|-----------|-----------|-----------| | 1.1. Consultoría y Análisis | 3 ptos. | 3 ptos. | 2 ptos. | 3 ptos. | 3 ptos. | | 1.2.1 Características Generales | 3 ptos. | 3 ptos. | 1 ptos. | 3 ptos. | 1 ptos. | | 1.2.2 Características Funcionales | 6 ptos. | 6 ptos. | 3 ptos. | 4 ptos. | 4 ptos. | | 1.2.3 Características Técnicas | 6 ptos. | 6 pto. | 3 ptos. | 4 ptos | 3 ptos | | 1.2.4 Características Interoperabilidad | 8 ptos. | 8 pto. | 6 pto. | 7 pto. | 6 pto. | | 1.3 Entorno Tecnológico | 4 ptos. | 4 ptos. | 1 ptos. | 2 ptos. | 1 ptos. | | 1.4 Licenciamiento | 4 ptos. | 3,5 ptos. | 2 ptos. | 3 pto. | 2 pto. | | 2.1. Planificación | 2 ptos. | 2 ptos. | 1 ptos. | 1,5 pto. | 1 pto. | | 2.2. Equipo | 2 ptos. | 2 ptos. | 1 ptos. | 2 pto. | 2 pto. | | 2.3. Transferencia | 2 ptos. | 2 ptos. | 1 ptos. | 1,5 pto. | 1,5 pto. | | 2.4. Metodología | 2 ptos. | 2 ptos. | 1 ptos. | 2 ptos. | 1 pto. | | 2.5. Normas de Calidad | 2 ptos. | 2 ptos. | 1 ptos. | 1,5 pto. | 2 pto. | | 3. Participación Proyectos | 5 ptos. | 5 pto. | 3 ptos. | 4 ptos. | 3 ptos. | | TOTAL | 49 ptos. | 48,5 ptos | 26 ptos | 38,5 ptos | 30,5 ptos | En cuanto a los mínimos de calidad los licitadores deben, según lo indicado en el anexo XI del PCAP, en:    -  Superar o igualar los 18 puntos en la suma de la valoración de los criterios 1.1, 1.2.1, 1.2.2, 1.2.3, 1.2.4, 1.3 y 1.4: -  TSYSBET: 33,5 puntos -  PROVITA: 18 puntos -  DEXTRO: 26 puntos -  VITHIB: 20 puntos -  Superar o igualar los 5 puntos en la suma de la valoración de los criterios 2.1, 2.2 2.3, 2.4 y 2.5: -  TSYSBET: 10 puntos -  PROVITA: 5 puntos -  DEXTRO: 8,5 puntos -  VITHIB: 7,5 puntos En todos los casos se superan los mínimos establecidos en el PCAP. El total de puntos asociados a los criterios expuestos en el Anexo XI del PCAP por licitador resulta ser el siguiente: -  TSYSBET: 48,5 puntos -  - PROVITA: 26 puntos -  DEXTRO: 38,5 puntos -  VITHIB: 30,5 puntos EL SUBDIRECTOR DE INFRAESTRUCTURAS E INTEGRACIÓN DEL CGIPC Fdo.: Francisco-Javier Martón Aguirre LA SUBDIRECTORA DE DESARROLLO E INTELIGENCIA DE NEGOCIO DEL CGIPC Fdo.: Noelia Sánchez Pérez LA RESPONSABLE DE HCE DE LA DIRECCION GRAL DE SALUD DIGITAL E INFRAESTRUCTURAS Fdo.: Trinidad Serrano Aulló

Informe de valoración de los criterios de adjudicación cuantificables mediante juicio de valor