DOC20230727083813Pliego de Prescripciones Tecnicas

EXPEDIENTE: CONP/2022/3290
SSCC-SESPA
PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DEL

SUMINISTRO, IMPLANTACIÓN, PUESTA EN MARCHA, MANTENIMIENTO DE
PRODUCTO, SOPORTE TERCER NIVEL Y MANTENIMIENTO EVOLUTIVO DE
UN ESPACIO DE DATOS DE SALUD EN EL SERVICIO DE SALUD DEL
PRINCIPADO DE ASTURIAS
INDICE
1 INTRODUCCIÓN ............................................................................................................................3
2 OBJETO Y ALCANCE ....................................................................................................................5
3 MARCO LEGAL ............................................................................................................................10
4 PRESCRIPCIONES TÉCNICAS DEL ESPACIO DE DATOS DE SALUD ...................................11
4.1 Estructura general del Sistema. Proyecto CUÉLEBRE.................................................11
4.2 Fuentes de información principales...............................................................................12
4.3 Repositorio de Datos de Uso Primario ..........................................................................18
4.3.1 Características generales del Repositorio de Uso Primario....................................18
4.3.2 Interfaz FHIR y SMART On FHIR ...........................................................................20
4.3.3 Ingesta de datos en el repositorio y carga inicial ....................................................20
4.3.4 Gestor de Reglas ....................................................................................................21
4.3.5 Gestión de Datos Maestros.....................................................................................22
4.3.6 Servidor de Terminologías Clínicas ........................................................................24
4.3.7 Analítica de Datos y monitorizacion ........................................................................25
4.4 Visor 360 .......................................................................................................................27
4.5 Repositorio de Datos Anonimizados para Uso Secundario ..........................................32
4.5.1 Infraestructuras y Servicios en la Nube ..................................................................33
4.5.2 Herramientas de almacenamiento, gestión y manipulación y preparación de los
datos ................................................................................................................................34
4.5.3 Herramientas de soporte al desarrollo de modelos de Machine Learning..............36
4.5.4 Caso de Uso de Machine Learning en ámbito farmacológico.................................39
4.5.5 Subsistema de Anonimización de datos .................................................................39
4.5.6 Ingesta de datos en el repositorio y carga inicial ....................................................40
4.5.7 Analítica de Datos y monitorizacion ........................................................................41
4.5.8 Exportación de conjuntos de datos .........................................................................41
4.5.9 Trabajos derivados de cambios de proveedor o de plataforma base .....................42
4.6 Gobierno del Dato .........................................................................................................43
Estado Original Página Página 1 de 79
Código Seguro de Verificación (CSV) 14156533646256034553
Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

SSCC-SESPA
4.7 Integración de Sistemas................................................................................................43

4.8 Análisis y Modelado ......................................................................................................46
4.8.1 Modelado del Repositorio de Uso Primario.............................................................46
4.8.2 Modelado del Repositorio del Uso Secundario .......................................................49
4.9 Gestión de usuarios, seguridad y auditoría...................................................................49
4.10 ASISTENCIA TÉCNICA Y MANTENIMIENTO POSTERIOR A LA PUESTA EN
PRODUCCIÓN DE LA SOLUCIÓN.....................................................................................52
4.10.1 Mantenimiento de producto y soporte tercer nivel ................................................53
4.10.1.1 Servicio de Mantenimiento de producto ......................................................................53
4.10.1.2 Soporte de tercer nivel....................................................................................................54
4.10.2 Servicio de Mantenimiento Evolutivo ....................................................................56
4.10.3 Horarios de Cobertura y Tiempos de Servicio o Resolución ................................56
5 REQUISITOS DE ARQUITECTURA TECNOLÓGICA .................................................................58
5.1 Requisitos infraestructura TIC.......................................................................................58
6 LICENCIAMIENTO .......................................................................................................................61
7 FORMACIÓN Y DIFUSIÓN ..........................................................................................................62
8 FASES E HITOS DEL PROYECTO..............................................................................................62
9 PROPIEDAD.................................................................................................................................68
9.1 Productos sin licencia....................................................................................................68
9.2 Productos con licencia ..................................................................................................69
10 ENFOQUE METODOLOGICO Y DOCUMENTACIÓN...............................................................70
11 SEGUIMIENTO Y CONTROL.....................................................................................................72
12 ACCESO REMOTO A LOS SISTEMAS DE EXPLOTACIÓN.....................................................72
13 TRANSFERENCIA TECNOLÓGICA ..........................................................................................72
14 GARANTÍA..................................................................................................................................73
15 ANEXO I: MODELO DE AUTENTICACIÓN Y AUTORIZACION DE APLICACIONES
FRENTE AL LDAP CORPORATIVO DEL SERVICIO DE SALUD DEL PRINCIPADO DE
ASTURIAS .......................................................................................................................................74

SSCC-SESPA
1 INTRODUCCIÓN
La actividad sanitaria produce una cantidad ingente de datos, El SESPA es el
organismo responsable de su gestión, guarda y custodia. Esos datos asistenciales
provienen tanto de dispositivos de electromedicina, como de registros en la Historia
Clínica como en los sistemas departamentales. Esa información se conserva tanto a
nivel estructural como en lenguaje natural.
Así, siguiendo estas directrices establecidas se implantó la Historia clínica
electrónica en Atención Hospitalaria, a través de los sistemas SELENE y Milenium y
en atención primaria a través del sistema OMI y ECAP. Asimismo se implantaron
diversos sistemas departamentales que se integran con la HCE, convirtiendo así la
HCE el soporte más adecuado para la asistencia sanitaria, facilitando el manejo y
accesibilidad de la documentación clínica de los pacientes tanto a los profesionales
como a los propios ciudadanos.
Sin embargo la integración de datos entre los sistemas de departamentales y los

grandes sistemas de información no son absolutos y cada vez el esfuerzo y la
demanda de interoperabilidad de los datos entre los distintos sistemas es mayor con
el objetivo de dar una asistencia sanitaria de calidad y completa.
Actualmente el Decreto de Estructura del SESPA, en su artículo 42 atribuye a la
Subdirección de Infraestructuras y Servicios Técnicos la gestión del mantenimiento
de los sistemas de información del SESPA así como el desarrollo, implantación,
gestión y mantenimiento de los sistemas de información departamentales que les
sean propios, así como la planificación, gestión y mantenimiento de las
infraestructuras TIC, tanto hardware como software sobre las que recaen.”
Así en base a esta competencia, esta Subdirección mantiene, a través de personal
propio y mediante contratos de mantenimiento específicos, un conjunto elevado de
sistemas de información que se pueden clasificar en hospitalarios, de atención
primaria, laboratorio, imagen médica, departamentales, que cumplen una función
determinada y que no siempre están adecuadamente integrados para que pueda
explotarse toda la capacidad que tiene la gran cantidad de datos generados.
Además para corresponder con la demanda cada vez más exigente, de disponer de
información de un paciente, de forma centralizada, sin relacionarse en procesos
asistenciales independientes, el SESPA mantiene y pone a disposición de los
profesionales la Historia Resumida de Salud (HRS), donde se puede consultar de
manera centralizada la información más relevante de ese paciente proveniente no
solo de los sistemas de información nucleares sino también de las distintas
departamentales
Aun siendo tremendamente útil, la HRS tiene muchas carencias para dar respuesta
a las expectativas actuales porque carece de multitud de información relevante que
se encuentran en los sistemas de información clínicos departamentales al ser datos

SSCC-SESPA
de información adicional que no suben a la HRS o la departamental tiene poca

capacidad de interoperabilidad
Por otro lado, esta orientación asistencial, de tener a disposición de los
profesionales, de una manera centralizada la mayor cantidad de información clínica
del paciente, se ha visto incrementada exponencialmente en estos últimos años, lo
que hace cada vez es más difícil y costosa la atención de esta demanda lo que
requiere acometer desarrollos en las distintas departamentales. Sin embargo, en
ocasiones no es posible dar respuesta desde los equipos de mantenimiento de los
distintos sistemas a peticiones de información, interoperabilidad o análisis de datos.
En particular es de destacar la problemática reiterada derivada de la necesidad de
confeccionar extracciones de datos para usos específicos ante demandas de
diferente procedencia, esta situación penaliza de forma significativa el
mantenimiento de los sistemas de información al requerir múltiples intervenciones en
diferentes sistemas aportando muy poco valor añadido y mucho trabajo con el
consiguiente coste económico.
Para paliar estas deficiencias y dar el servicio de una manera más ágil y eficiente la
Subdirección de Infraestructuras y Servicios Técnicos propone el establecimiento de
un repositorio de datos con información clínica de cada paciente de forma
centralizada, que serán suministrados desde los distintos sistemas de información
que en la actualidad mantiene la Subdirección. De esta manera se podrán mantener
y gestionar los datos sanitarios, que en este momento realizan en cada uno de los
sistemas de información, de una manera integrada, homogeneizada y actualizados
on-line. Asimismo la Subdirección de Infraestructuras debe dar respuesta a la
solicitud de descarga de datos asistenciales que se realizan por los distintos grupos
de investigación que conforma en el IISPA y la FINBA. Como órgano gestor de esta
demanda y de cara a poder dar cumplimiento con la normativa de protección de
datos, se pretende creación de un repositorio de datos anonimizados para cumplir
con las solicitudes de descarga de datos de grupos de investigación.
Toda esta información, recogida y progresivamente enlazada permitirá responder a
una parte importante de estos retos:
 Mejorar la gestión de los cuidados aplicando los mejores protocolos para

la gestión de los pacientes de forma más personalizada.
 Con la incorporación de los datos aportados por las personas y los nuevos
dispositivos médicos, realizar una adecuada, eficiente y más segura
gestión de la enfermedad.
 Ayudar a que los modelos de cuidado tengan en cuenta el contexto social
de los ciudadanos.
 Mejorar la gestión poblacional de la salud.
 Mejorar las opciones de los tratamientos para cada colectivo en función de
su eficacia y seguridad (medida con información del mundo real).
 Estratificar riesgos y medir resultados en salud para lograr una atención
coordinada y eficiente.
 Empoderar e incentivar a los individuos a adoptar estilos de vida más
saludables.

SSCC-SESPA
 Acelerar la investigación biomédica.

 Mediante las técnicas actuales de Big data, avanzar en una medicina
basada en la evidencia.
 Evolucionar hacia una medicina personalizada o de precisión.
 Con la integración con fuentes como las ambientales, poder trabajar en
una medicina predictiva.
.
2 OBJETO Y ALCANCE
El objeto del contrato es el SUMINISTRO Y MANTENIMIENTO POSTERIOR DE UN
ESPACIO DE DATOS DE SALUD EN EL SERVICIO DE SALUD DEL PRINCIPADO
DE ASTURIAS, incluyendo tanto un repositorio de datos clínicos para uso primario,
un visor 360 de datos del paciente, como un repositorio de datos anonimizados para
uso secundario.
Se requiere por tanto de dos repositorios de datos con información clínica de cada
paciente de forma centralizada, que serán suministrados desde los distintos
sistemas de información corporativos.
El primero de los repositorios centralizará la información para su uso primario, es

decir, para la práctica asistencial, permitiendo una mejora con respecto a la solución
que se maneja actualmente de CGM HUP (Healthcare Unified Platform). Para
conseguir esta centralización y consolidación de la información se requieren un
conjunto de elementos o subsistemas que resolverán las problemáticas específicas
de centralizar información clínica de distintos sistemas, de distintos fabricantes, con
terminologías distintas y capacidades de integración distintas. Sobre este repositorio
primario se desarrollará un visor que mostrará la información clave de cada paciente
consolidada en el repositorio.
El segundo de los repositorios estará orientado a la explotación masiva de datos,

investigación, y en general lo que se consideran “usos secundarios”. Este repositorio
tendrá información consolidada de distintas fuentes para manejar toda la información
relevante que se considere necesaria para los distintos usos que se vayan
identificando, siempre trabajando con información sin identificación personal. Se
requiere también la ejecución de un caso de uso de machine learning sobre este
repositorio, centrado en el ámbito farmacológico.
Se consolidará directa o indirectamente, los datos e información de los diferentes

sistemas de información de Salud y se proporcionará los mecanismos necesarios de
acceso (lectura, actualización, inserción y borrado) a los repositorios, que actuarán
de forma centralizada, proporcionando como elemento de valor añadido un conjunto
de servicios digitales

SSCC-SESPA
Será capaz de gestionar diferentes tipos de información y formatos, para 2 tipos de

usos principales:
 Uso primario de la información de Salud: cuando los datos de salud se utilizan

para proporcionar atención médica y tomar decisiones sobre la atención de la
persona de quien se recopilaron (traducción de (The ODI report, s.f.))
 Uso secundario de los datos de Salud: es el uso de datos de salud agregados

de fuentes a nivel de la población, para mejorar la planificación de la atención
personal, el desarrollo de medicamentos, el control de la seguridad, la
investigación y la formulación de políticas (The ODI report, s.f.).
La información será coordinada adecuadamente entre las diferentes capas que

componen la plataforma, de modo que, por ejemplo, información ya normalizada y
almacenada en el área de información de Uso Primario podrá ser compartida con el
área de Uso Secundario (tratada como una fuente de información origen más, sin
tener que volver a todas las fuentes).
Debe responder a las necesidades derivadas del uso primario y secundario de la

información, como la accesibilidad, interoperabilidad y estandarización tanto en el
consumo como en el intercambio de información mediante estándares
internacionales (FHIR-HL7, SNOMED-CT, LOINC, CIE-10…).
El alcance de la contratación abarca:
 Suministro e implantación de un REPOSITORIO DE DATOS DE SALUD

(REPOSITORIO DE USO PRIMARIO) con información clínica de cada
paciente de forma centralizada, integrada, homogeneizada y actualizados de
forma automatizada. Se incluyen todos los elementos de software y servicios
necesarios (Análisis, diseño, desarrollo, pruebas, instalación, y configuración
de la solución a implantar, incluyendo las integraciones necesarias con otros
sistemas).
 Suministro e implantación de una INTERFAZ FHIR y SMART ON FHIR para
facilitar la interoperabilidad del repositorio de uso primario.
 Suministro e implantación de un GESTOR DE REGLAS que permita disparar
acciones sobre los datos y/o sistemas externos cuando se cumplan
determinadas condiciones previamente configuradas.
 Suministro e implantación de un sistema de GESTIÓN DE DATOS
MAESTROS que permita la conversión, adaptación y/o mapeo de datos
maestros que permita disponer de una información homogénea que
incorporar a los nuevos sistemas a implantar.
 Suministro e implantación de un sistema de GESTIÓN DE TERMINOLOGÍAS
CLÍNICAS que permita la estandarización de la información a las

SSCC-SESPA
terminologías clínicas que sean necesarias para la integración de los datos y

consolidación de la información en un repositorio único y centralizado.
 Suministro e implantación de un VISOR 360 que permita la consulta de un
conjunto configurable de datos del repositorio primario para que el profesional
asistencial del SESPA pueda conocer la información clínica más relevante de
un paciente en función de su perfil.
 Suministro e implantación de un REPOSITORIO DE DATOS

ANONIMIZADOS PARA USO SECUNDARIO (REPOSITORIO DE USO
SECUNDARIO), preparado para la utilización de BigData y de Inteligencia
Artificial.
 Suministro de las SERVICIOS EN LA NUBE que sean necesarias para la
implantación del repositorio de datos anonimizados para uso secundario,
incluyendo tanto la infraestructura como los servicios necesarios.
 Suministro e implantación de herramientas de MONITORIZACIÓN Y
ANALÍTICA DE DATOS para los repositorios suministrados.
 ANÁLISIS y MODELADO de los conjuntos de datos almacenados en los
REPOSITORIOS A SUMINISTRAR. En el caso del repositorio primario se
requerirá la incorporación de las entidades de información que modelan los
datos almacenados (en adelante “arquetipos” para facilitar la comprensión de
este término, sin que deba entenderse sujeto a ninguna norma o estándar
específico) necesarios para el adecuado registro de la información disponible
en los sistemas corporativos.
 El proyecto a implementar tendrá la filosofía de “llave en mano”, debiendo el
adjudicatario hacerse cargo de todas las tareas necesarias para la puesta en
producción y operación de los sistemas durante la vigencia del contrato. No
están incluidos los trabajos a realizar sobre terceros sistemas que son
externos a la solución y propiedad del Principado de Asturias. En el caso del
repositorio secundario, se realizará tanto el análisis y diseño del espacio de
datos como el despliegue y parametrización de las
herramientas/componentes a emplear en la plataforma para los análisis
basados en Big Data e Inteligencia Artificial.
 Sistema que se encargue de la gestión y mantenimiento del repositorio de los
arquetipos utilizados en el repositorio primario, facilitando herramientas o
funcionalidades para el mantenimiento de los mismos, como es el versionado
o interoperabilidad con FHIR.
 Modelado de los datos flexible, adaptable y basado en estándares, para
adaptarse a las guías y diseños que se elaboren desde el Ministerio de
Sanidad, especialmente deberá de estar preparado para la implementación
del Espacio de Datos que se está diseñando por un grupo de trabajo
específico.
 Desarrollo de un caso de uso de Machine Learning en el ámbito
farmacológico.

SSCC-SESPA
 Puesta en producción de herramientas y modelos analíticos desarrollados

sobre las estructuras de los repositorios de datos en el repositorio primario.
 Suministro e implantación de un sistema de integración de tipo Enterprise
Service Bus, para la interconexión entre los componentes de la plataforma y
el resto de sistemas. La instalación de este ESB podrá quedar excluida del
ámbito del contrato en caso de que el SESPA disponga de un ESB como
Sistema Corporativo al inicio del contrato. En caso de que el SESPA implante
un ESB corporativo durante la ejecución del presente contrato, el
adjudicatario realizará la migración de los desarrollos a dicho ESB
corporativo.
 Desarrollo e implantación de las INTEGRACIONES que deban implementarse
tanto para la migración inicial como para la captura ordinaria de los datos a
obtener de los Sistemas de Información origen. Será responsabilidad del
adjudicatario identificar e implementar la solución específica óptima para
capturar la información, que deberá validarse y aprobarse por el SESPA.
 Están excluidas de esta contratación la parte de las adaptaciones y
desarrollos que deban realizarse sobre otros sistemas del SESPA, las cuales
serán requeridas a los distintos proveedores o responsables de su
mantenimiento. Sí se requerirá del adjudicatario la participación activa en el
análisis y diseño de las integraciones que pudieran involucrar los
mencionados cambios en otros sistemas del SESPA.
 Desarrollo e implantación de las INTEGRACIONES que permitan a otros
sistemas del SESPA integrarse con el repositorio de uso primario y con el
respositorio de uso secundario para el aprovechamiento o actualización de la
información almacenada.
 INGESTA DE DATOS INICIAL en los repositorios suministrados, tanto para el
repositorio de uso primario como para el secundario.
 Realización de los trabajos de ANONIMIZACIÓN de datos que sean
necesarios para la ingesta de información en el repositorio de uso secundario.
 Suministro de licenciamiento de todos los productos y subproductos que se
requieran para la implantación y puesta en producción del repositorio primario
y secundario, incluyendo, en su caso, los componentes identificado en este
Pliego de Prescripciones Técnicas y aquellos que sean ofertados dentro de la
propuesta del adjudicatario como elementos que componen la solución
ofertada. El proyecto no tendrá dependencias de componentes externos que
hagan inviable el proyecto en caso de no aportar el SESPA dichos
componentes. Todos los sistemas y subsistemas que se requieran para la
construcción, mantenimiento, operación o modelado de los sistemas
suministrados. Respecto al licenciamiento necesario para el despliegue del
software en los servidores del Principado de Asturias, solamente será
necesario aportar el licenciamiento que a mayores requiera el Principado de
Asturias para desplegar el sistema en sus infraestructuras. Licenciamiento
corporativo para el SESPA sin limitación de usuarios, que permita cubrir las

SSCC-SESPA
necesidades del SESPA respecto al uso y explotación de los sistemas

suministrados.
 Deberá cumplir con la Identidad Digital definida en el Principado de Asturias.
 Asegurar la asistencia técnica, mantenimiento y operación de los sistemas
puestos en producción durante el período de ejecución del contrato, desde su
puesta en producción hasta la finalización del contrato. En el caso de las
infraestructuras desplegadas en las instalaciones del Principado de Asturias,
la operación se realizará según los procedimientos establecidos por el
Principado de Asturias, actualmente la operación sobre los sistemas de
preproducción y producción se realiza por parte del Centro de Gestión de
Servicios Informáticos (CGSI).
 La autenticación de usuarios de gestión deberá integrarse con LDAP
corporativo del SESPA, según MODELO DE AUTENTICACIÓN Y
AUTORIZACION DE APLICACIONES FRENTE AL LDAP CORPORATIVO
DEL SERVICIO DE SALUD DEL PRINCIPADO DE ASTURIAS descrito en
ANEXO I. El sistema estará preparado para conectarse si se estima oportuno
por el SESPA, a un sistema corporativo de Single Sign-On (SSO),
incluyéndose dicha eventual integración en el objeto del contrato.
 Instalación de todos los componentes necesarios para el repositorio de uso
primario en el Centro de Proceso de Datos (CPD Asturcón) del Principado de
Asturias y su puesta en marcha. No es objeto de este contrato el suministro
de la infraestructura necesaria para la instalación de los sistemas y
subsistemas en el CPD corporativo en caso de adaptarse al entorno
tecnológico del Principado de Asturias, tal y como se detalla en el apartado
“REQUISITOS DE ARQUITECTURA TECNOLÓGICA" de este Pliego
Técnico.
 Pruebas de componentes, del sistema y pruebas de integración.
 El cumplimiento de las políticas y procedimientos que estén establecidos por
el Principado de Asturias para la instalación o mantenimiento de nuevos
sistemas en el CPD del Principado de Asturias, para todo lo referente a la
Seguridad de los datos y Sistemas de Información, y cualquier normativa o
instrucción derivada de la política del Principado de Asturias respecto a
Tecnologías de la Información.
 Alineamiento con los Espacios de Datos de Salud Europeo y Nacional,
cumplimiento con las normas y regulaciones de seguridad establecidas por
las diferentes Data Authorities de los estados miembros de la Unión Eurpoa, y
se preparará la información para que esté accesible en el catálogo de datos
de salud europeo y nacional. En general, se contempla dentro del objeto de
este contrato que el proyecto desarrollado esté preparado y cumpla con las
expectativas marcadas desde los Espacios de Datos de Salud Europeo y
Nacional.
 Todos los requisitos indicados en el presente Pliego de Prescripciones
Técnicas y necesarios para el buen fin del objeto del contrato.

SSCC-SESPA
3 MARCO LEGAL
La totalidad de las actuaciones a realizar dentro del ámbito del presente proyecto se
realizaran con la más completa garantía de cumplimiento de la legalidad vigente, y
en particular de la siguiente legislación aplicable, o sus correspondientes
actualizaciones:
 Ley 14/1986, de 25 de abril, General de Sanidad.
 Ley 41/2002, de 14 de noviembre, básica reguladora de la autonomía del
paciente y de derechos y obligaciones en materia de información y
documentación clínica.
 Real Decreto 4/2010, de 8 de enero, por el que se regula el Esquema Nacional
de Interoperabilidad en el ámbito de la Administración Electrónica.
 Real Decreto 311/2022, de 3 de mayo, por el que se regula el Esquema Nacional
de Seguridad
 Ley Orgánica 3/2018, de 5 de diciembre, de Protección de Datos de Carácter
Personal y Garantía de los Derechos Digitales.
 Reglamento Europeo UE 2016/679 de Protección de Datos.
 Decreto 178/2005 del Reglamento que regula la historia clínica en los centros
hospitalarios y establece el contenido, conservación y expurgo de sus
documentos.
 Normas Técnicas de Interoperabilidad (NTI) de la Secretaría de Estado de
Administraciones Públicas y las Normas y Guías técnicas de seguridad y
plataformas de firma del Instituto Nacional de Ciberseguridad (INCIBE) y del
Centro Criptológico Nacional (CCN).
 Aquella normativa o esquemas técnicos nacidos en el ámbito de los proyecto de
Historia Clínica del Sistema Nacional y Europeo de Salud.
 Resolución de 17 de junio de 2011, de la Consejería de Administraciones
Públicas y Portavoz del Gobierno, por la que se aprueba la política de seguridad
de los sistemas de información en la Administración del Principado de Asturias
 Código de Deontología Médica.
 Recomendaciones de las Sociedades Científicas de Profesionales Sanitarios.
 Convenio del Consejo de Europa para la protección de los derechos humanos y
la dignidad del ser humano respecto a las aplicaciones de la biología y la
medicina.

SSCC-SESPA
4 PRESCRIPCIONES TÉCNICAS DEL

ESPACIO DE DATOS DE SALUD
4.1 Estructura general del Sistema. Proyecto

CUÉLEBRE
Dentro del ámbito del presente proyecto se incluyen un conjunto de sistemas y
subsistemas, cuya estructura e interrelación entre esos componentes y con otros
sistemas informáticos corporativos se representa en el siguiente diagrama, que debe
tenerse en cuenta como componentes lógicos del sistema, no necesariamente
tienen que implantarse como sistemas o “servidores” específicos.
Como filosofía de la arquitectura de los nuevos Sistemas informáticos a implantar en

el proyecto, estos deberán incorporarse a una Arquitectura Orientada a Servicios
(SOA) persiguiendo maximizar las funcionalidades de cada sistema y subsistema
publicadas a través del bus de integración, con el objetivo de facilitar el posible uso
de dichas funcionalidades por parte de otros Sistemas Corporativos.

SSCC-SESPA
4.2 Fuentes de información principales

Se describen a continuación los principales Sistemas de Información que soportan el
Servicio de Salud del Principado de Asturias (SESPA), que en su mayoría se tratan
de productos comerciales sobre los que existen derechos de propiedad intelectual.
El SESPA dispone de contratos de mantenimiento para todos los sistemas
identificados.
Estos Sistemas de Información son las fuentes principales de datos para los
repositorios de uso primario y secundario objeto de este contrato.
 SIPRES. Sistema de Información Poblacional

o En el SESPA se dispone de un Sistema de Información Poblacional y
de Recursos (SIPRES) que está soportado por el producto comercial
CIVITAS.
o Responsable de
1. la asignación del código autonómico de identificación del
paciente (CIPAUT) para la identificación en los sistemas de
informacion sanitarios del Principado de Asturias.
2. Registro y gestión de datos de identificación, localización,
contacto, prestaciones y adscripción a recursos sanitarios de la
población destinataria de los servicios sanitarios y políticas de
salud.
3. Gestión de la tarjeta sanitaria y otros documentos de
acreditación de la asistencia sanitaria.
o Sistema único centralizado.
o Integrado directamente con ECAP y Historial Unificado del Paciente
(HUP). Indirectamente la información de identificación está integrada
con los distintos HIS y distribuida a otros sistemas a través de ellos.
o Mecanismos de integración: Web services; HL7; Descargas de
ficheros, Vistas de BD publicadas.
 Sistemas de Información Hospitalaria (HIS)

o MILLENNIUM
1. Producto del fabricante CERNER que está implantado en el
Hospital Universitario Central de Asturias (HUCA) y Hospital
Monte Naranco (HMN)
2. Una única instancia que da servicio a ambos centros.

SSCC-SESPA
3. Integrado principalmente con

- HUP para enviarle la información de cada paciente.
- Los distintos sistemas informáticos departamentales de
ambos centros.
4. Mecanismos de integración: Diversos (unas 40 integraciones),
principalmente mensajería HL7, y servicios web aunque también
se utilizan descargas de datos, intercambios de ficheros,
accesos a BD…
o SELENE
1. Producto del fabricante CGM que está implantado en el resto de
hospitales de la Red de Hospitales Públicos del Principado de
Asturias.
2. Una instancia por cada hospital.
3. Integrado principalmente con
- HUP para enviarle la información de cada paciente.
- Los distintos sistemas informáticos departamentales de
cada centro.
4. Mecanismos de integración: Diversos (múltiples integraciones en
algunos casos dependientes de cada hospital), principalmente
mensajería HL7, y servicios web aunque también se utilizan
descargas de datos, intercambios de ficheros, accesos a BD,
FHIR…
 Sistemas de Información en Atención Primaria (PHS)

o ECAP y OMI-AP
1. Producto del fabricante STACKS que está implantado en todos
los Centros de Atención Primaria. Actualmente se está
completando la implantación de la Estación Clínica de Atención
Primaria (ECAP) en todo el SESPA.
2. La ECAP es una solución centralizada con una instancia única
para toda la Comunidad.
3. Integrado principalmente con:
- SIPRES. (coordinación de datos de pacientes)
- Las diferentes instancias de los HIS implantados.

SSCC-SESPA
- Sistemas de Gestión de Laboratorios (dependientes de la

zona de influencia y/o área sanitaria de actuación de
cada laboratorio)
- SAGITARIO (Gestión de Incapacidades Temporales).
- Receta Electrónica.
4. Mecanismos de integración: Diversos, HL7, Servicios web,
intercambio de ficheros.
 Sistema de Información de Laboratorio (LIS)

o Actualmente está en licitación el suministro de un LIS único y
centralizado para todo el SESPA, siendo la situación actual:
AREA SANITARIA LIS
I MODULAB
II MODULAB
III SMARTLIS
IV GESTLAB
V SERVOLAB,
VI OMEGA
VII OPEN LIS (En implantación)
VIII OMEGA
o Las integraciones principales son: con ECAP, o con cada uno de los
HIS de su área.
o Actualmente los distintos LIS se integran principalmente mediante
HL7.
 Sistema de Información de Radiología (RIS)

o EOS
1. Producto EOS de la empresa Babel. Sistema de Información
Radiológico. Utilizado por los servicios de Radiología de todas
las Áreas y por el servicio de Medicina Nuclear del HUCA.
2. Instancias independientes en cada uno de los centros e la Red
de Hospitales Públicos,

SSCC-SESPA
3. Integraciones principales: mediante HL7 con el HIS del centro y

con el PACS que da servicio al centro.
 Sistema de almacenamiento de imagen médica. (PACS)

o IMPAX
1. Producto IMPAX de la empresa Agfa. PACS corporativo para
todo tipo de imagen médica.
2. Una instancia única centralizada.
3. Cada instancia se integra mediante HL7 con los RIS de los
centros a los que da servicio, y mediante DICOM con los
distintos equipos de captura de imagen.
 Receta Electrónica
o sistema cuyo objetivo es permitir la emisión y transmisión de
prescripciones realizadas por los facultativos en el ámbito de Atención
Primaria y Especializada para su posterior dispensación en las oficinas
de farmacia.
o Una instancia única centralizada.
o Se integra principalmente con
1. los sistemas Prescriptores (ECAP y las distintas instancias de
los HIS)
2. SIPRES
o El mecanismo de integración principal se basa en Servicios Web.
 Sistemas de Información Departamentales

No todos los Sistemas de Información Departamentales están implantados en
todos los centros y normalmente tienen instalaciones independientes por
hospital, aunque la infraestructura si está centralizada y normalmente
virtualizada.
Se relacionan los principales Sistemas de Información Departamentales. Solo

se incluyen aquellos con un grado importante de extensión en distintos
centros:
o Farma Tools. (Farmacia Hospitalaria).
o Oncofarm. (Farmacia Oncológica).

SSCC-SESPA
o DietTools.
o Endotools WEB.
o PAT-Win. (Anatomía Patológica)
o ISCV. (Intelli Space Cardio Vascular. Cardiología).
o SINFHO. (Rehabilitación)
o ehCOS Emergency. (Historia Clínica Embarcada en Ambulancias de
Soporte Vital Avanzado)
o SmartCICU. Sistema de gestión de emergencias
o e-Delphyn. (Banco de Sangre)
o GOTA. Gestión de tratamientos anticoagulantes orales.
o Radimetrics. (Gestión de Dosis de Radiación Ionizante. Sistema
centralizado en una instancia única).
Se incluye una tabla resumen con estos y otros sistemas de información implantados
en el SESPA, que podrían tenerse en cuenta como fuentes de información.
AMBITO SISTEMA NOMBRE EMPRESA DE

ÁMBITO
INFORMACIÓN SISTEMA REFERENCIA
Sistema Información Sistema Información
SIPRES Getronics
Poblacional y de Recursos Poblacional y de Recursos
MILLENNIU
NTT
HIS HIS M
SELENE CGM
Estación Clínica AP Estación Clínica AP ECAP Stacks
EOS Babel
RIS RIS
IMPAX Babel (AGFA)
LIS LIS GESTLAB Minsait
TAO (Tratamiento TAO (Tratamiento Minsait
GOTA
Anticoagulante Oral) Anticoagulante Oral) (Werfen)
SISTEMAS DE
CMBD CMBD Decisys GESTIÓN
SANITARIA
Receta
Minsait
Electrónica
Farmacia Farmacia Receta
Electrónica Minsait
(BDCM)
Departamental - Anatomía Departamental - Anatomía
PATWIN Minsait-Dedalus
Patológica Patológica
Departamental - Farmacia Departamental - Farmacia Farmatools Dominion

SSCC-SESPA

ÁMBITO
Global
Departamental - Departamental - Dominion
Dietools
Alimentación hospitalaria Alimentación hospitalaria Global
Departamental - Departamental -
SINFHO Tesis
Rehabilitación Rehabilitación
Departamental - Banco de Departamental - Banco de Hemasoft
eDelphin
Sangre Sangre Software
Departamental Oncología Departamental Oncología
ARIA VARIAN
Radioterápica Radioterápica
Departamental - Farmacia Departamental - Farmacia
Oncofarm IMF
Oncohematológica Oncohematológica
Departamental - Nefrología Departamental - Nefrología Nefrosoft Visual Limes
Fresenius
Departamental - Nefrología Departamental - Nefrología Nefrolink
Medical Care
Departamental - Endoscopia Departamental - Endoscopia Endotools SIMMEDICA
Departamental - UCI Departamental - UCI ICCA Philips Ibérica
Departamental - ECGs Departamental - ECGs iECG Philips Ibérica
Departamental - ECGs Departamental - ECGs ISIS TESIS
Departamental - Cardiología Departamental - Cardiología ISCV Philips Ibérica
Departamental - Cariotipado Departamental - Cariotipado IKAROS Werfen
Gestión de la Incapacidad Gestión de la Incapacidad
Sagitario Divisa iT
Temporal Temporal
Visado de Recetas Visado de Recetas eVisado Divisa iT
Direccionamiento Pacientes Direccionamiento Pacientes QUENDA Plexus Tech
Digitalización Digitalización
ISCAD Inetum
Documentación Clínica Documentación Clínica
Global Tech
Asistencia Médica Urgente Asistencia Médica Urgente SmartCicu
Strategies
OBSAMU OBSAMU OBSAMU NTT
Gestión de dosis de Gestión de dosis de
Radimetrics Bayer
Radiación Radiación
Salud Pública - Cribado Salud Pública - Cribado
SICCRA Bahía Software
Cáncer Colorrectal Cáncer Colorrectal
Gestión y trazabilidad de Gestión y trazabilidad de
Trazins Trazins
material quirúrgico material quirúrgico
Registro Ricoh
Registro de tumores Registro de tumores
Tumores (Mantenimiento)
Esterilización - Marvax Esterilización - Marvax Marvax CGM
Monitorización
Monitorización Monitorización PIC iX
(Philips)
TIREA TIREA
Facturación Facturación
ERCINA Minsait

SSCC-SESPA

ÁMBITO
Obstetricia Obstetricia ISP Philips
A efecto de las estimaciones de almacenamiento que puedan requerirse para el

desarrollo del proyecto, las fuentes principales descritas totalizan un espacio
orientativo de 10 TB.

SSCC-SESPA
4.3 Repositorio de Datos de Uso Primario
4.3.1 Características generales del Repositorio de

Uso Primario
Con carácter general, el objetivo de este repositorio consiste en agregar de forma
centralizada, integrada, homogeneizada y actualizada de forma automatizada toda la
información sanitaria de cada uno de los pacientes cuyos datos de salud sean
gestionados por los sistemas informáticos corporativos del Servicio de Salud del
Principado de Asturias. Si los sistemas de información del SESPA tienen la
capacidad necesaria, se mantendrá la información online perfectamente actualizada.
Los requisitos principales a cumplir por este Repositorio son;
 Almacenar la información de salud de cada uno de los pacientes cuyos datos

de salud se gestionen a través de los diferentes sistemas informáticos del
Servicio de Salud del Principado de Asturias. Esta información de diferentes
procedencias deberá estar consolidada y vinculada en torno a una referencia
única de cada paciente.
 La capa de integración del sistema deberá permitir la actualización online de
la información registrada, a medida que ésta sea actualizada o nueva
información sea agregada en los diferentes sistemas de origen. De forma que
en todo momento el nuevo repositorio centralizado disponga de la información
totalmente actualizada.
 La capa de integración del sistema soportará necesariamente el estándar
FHIR como formato de interoperabilidad, haciendo compatible este repositorio
con desarrollos de front-end que cumplan el estándar SMART on FHIR.
 La instalación de este sistema deberá realizarse en las instalaciones de la
Administración del Principado de Asturias.
 El repositorio de Datos deberá estar concebido para poder llegar a utilizarse
en el futuro como sistema de almacenamiento contra el que se podrán
efectuar posteriores desarrollos de otras aplicaciones (p.ej. futuras
aplicaciones o funcionalidades específicas para el usuario final) que utilicen el
Repositorio como sistema de almacenamiento de la información y se integren
con él mediante el interfaz SMART on FHIR.
 El sistema deberá ser escalable tanto horizontal como verticalmente.
 El sistema deberá proporcionar servicio en modo de alta disponibilidad.
 El modelo de persistencia del Repositorio podrá estar basado en estándares
como OpenEHR, FHIR u otros, siendo responsabilidad del adjudicatario la
definición, configuración y carga del modelo de datos.
o En el presente pliego de prescripciones técnicas, se utilizarán
indistintamente los términos “arquetipo”, “recurso” o “Entidad de
información” para referirse a los distintos conjuntos de datos
gestionados en el Repositorio de uso primario o intercambiados entre

SSCC-SESPA
sistemas, pero sin que el uso de estos términos fije un requerimiento

técnico vinculado necesariamente al uso de OpenEHR, FHIR o de
modelos relacionales, siendo admisible cualquiera de estos formatos.
 Dado que se prevé una continua evolución en el modelo de datos del
Repositorio, éste deberá ser extensible y modificable, facilitando la
incorporación de nueva información mediante la ampliación/modificación del
modelo de persistencia y del resto de elementos afectados. Es especialmente
relevante disponer de una óptima solución para los siguientes aspectos,
encontrando la mejor solución posible, aunque no puedan resolverse
totalmente de forma automática:
o Ante modificaciones del modelo de persistencia, proporcionar una
adecuada gestión del cambio en los distintos elementos del sistema.
o Facilitar la adaptación de la capa de interoperabilidad de forma que
ante cualquier modificación en el modelo de datos de persistencia, la
capa de integración se adapte y permita un intercambio de datos de
entrada y salida acorde al nuevo modelo de datos. Idealmente éste
cambio en el interfaz de integración debería realizarse de forma
automática o semiautomática.
o Facilitar la adaptación del resto de sistemas integrados con el
Repositorio ante cambios en su estructura. (Por ejemplo, mediante la
coexistencia de versiones sucesivas de arquetipos en el repositorio y
de sus correspondientes interfaces de integración, …)
o Mecanismos de evolución-modificación del repositorio de datos, en
aspectos como gestión de versiones del modelo de datos, versionado
de los interfaces de integración, gestión de la correlación entre
sistemas integrados con el repositorio y las [eventuales] versiones de
los interfaces.
o Procesos de actualización y/o adecuación de los datos preexistentes
en el repositorio, tras modificaciones en el modelo de datos.
o Procedimientos ágiles para la aplicación de cambios, traslado de
parametrizaciones (arquetipos, usuarios, permisos), y despliegue de
actualizaciones en los distintos entornos (desarrollo, integración y
producción), con procedimientos lo más automatizados posibles.
o Adaptación del visor 360 a las modificaciones en el modelo de
persistencia y/o modelo de servicios.
o Se tendrán en cuenta mecanismos de evolución del sistema en general
y sus interdependencias previsibles con otros sistemas.
Concretamente, el procedimiento de actualización ante los siguientes
tipos de cambio:
 Agregar un campo a un arquetipo preexistente.
 Eliminar un campo de un arquetipo preexistente.
 Crear un nuevo arquetipo.
 Substituir un arquetipo por otro que se fije de forma corporativa
(pasar a usar una implementación diferente del mismo
concepto).
Para cada uno de esos tipos de cambio se deberá especificar y se
tendrá en cuenta:

SSCC-SESPA
Proceso de modificación del modelo de datos.


Proceso de adaptación/migración de los datos preexistentes.

Proceso de actualización de los interfaces de interoperabilidad

Proceso de actualización del modelo de datos y de los datos en

el Subsistema módulo de Monitorización y Analítica de Datos
 Proceso de actualización entre entornos (Desarrollo, integración,
producción)
 Deberá estar dimensionado convenientemente para proporcionar un
rendimiento adecuado, sobre la previsión de tener que gestionar la
información completa de más de un millón de pacientes y dar servicios a
todos los profesionales asistenciales del SESPA que accederán a este
sistema para consultar información consolidad de pacientes.
 La instalación del sistema se efectuará en infraestructuras propias de la
Administración del Principado de Asturias. No se contempla la utilización de
infraestructuras en la nube ni de terceros para este sistema.
4.3.2 Interfaz FHIR y SMART On FHIR

El repositorio de datos de uso primario deberá publicar sus contenidos a través de
un interfaz de interoperabilidad que cumpla el estándar FHIR.
Esta característica deberá permitir que el repositorio actúe como el repositorio FHIR
para aplicaciones compatibles con el estándar Smart on FHIR.
Además del Servidor FHIR debe incluir soporte para el protocolo OAuth2.0
(framework de autorización que permite a una aplicación obtener acceso limitado a
un servicio digital), para cumplir Smart on FHIR y así aprovechar al máximo la
interoperabilidad con aplicaciones, apps y otros servicios digitales del sector de la
Salud.
4.3.3 Ingesta de datos en el repositorio y carga

inicial
El repositorio tendrá una capa de integración que permitirá la actualización online de
la información registrada, en la medida que ésta sea actualizada o agregada en los
diferentes sistemas de origen. El nuevo repositorio centralizado perseguirá disponer
de la información totalmente actualizada.
Tanto para la ingesta de datos inicial como la actualización on-line de la información
en una fase del servicio ya implantado y estable, el diseño a priorizar será la
implementación de una capa de servicios que permita actualizar el repositorio de
forma on-line y basado en estándares.
Se priorizará la utilización de la capa de servicios de integración del repositorio,
generando toda la mensajería que dé lugar a la carga de datos. Para los sistemas

SSCC-SESPA
del SESPA que no puedan integrarse con esta mensajería, se valorará que el
adjudicatario realice una transformación de los datos que reciba o descargue de
estos sistemas, para generar la mensajería que lanzará sobre la capa de integración
del repositorio, u otras soluciones equivalentes que faciliten una solución que
actualice totalmente online.
Se considera incluido en el ámbito del proyecto la migración de los datos disponibles
en los diferentes sistemas informáticos en los que actualmente se encuentra
disgregada la información de datos de salud del paciente.
Para cada uno de los sistemas de los que el repositorio tomará información (en
adelante sistemas fuente), se realizará una propuesta de integración en la que se
partirá de las posibilidades actuales del sistema origen y se adaptará a sus
posibilidades. Se diseñará una hoja de ruta para cada sistema fuente con las
diferentes actuaciones de mejora a aplicar en ambos sistemas (tanto en el sistema
origen como en CUÉLEBRE) hasta llegar al modelo deseado que sea totalmente
online.
4.3.4 Gestor de Reglas

Se valorará la capacidad de definir reglas que permitan la declaración de reglas
destinadas a procesar los eventos, o determinadas condiciones sobre los datos del
repositorio y desencadenen una acción previamente definida. Algunos ejemplos de
esta funcionalidad pueden ser la propagación de alertas entre sistemas, o
generación de avisos ante determinadas condiciones.
Las reglas evaluarán la información recibida en los eventos/mensajes o la contenida
en el repositorio, pudiendo completar dicha información mediante la invocación a
sistemas externos. Con esa información adicional se evaluará la condición de
ejecución de la regla, si la condición de ejecución se activa, entonces se ejecutarán
un conjunto de acciones definidas en la regla. Si la condición de ejecución no se
activase, y en caso contrario, opcionalmente se podrá indicar otro conjunto de
acciones a ejecutar.
Un objetivo de este sistema de gestión de reglas será su utilización conjunta con los
futuros modelos de IA que pasen a estar disponibles para el SESPA, tanto los
desarrollados con la infraestructura del presente proyecto, como los incorporados
por otras vías. Por este motivo, el motor de reglas deberá permitir su integración con
dichos modelos de forma simple y flexible.
Algunas funcionalidades a valorar en el subsistema de gestión de reglas serán:
 Estructura de la regla:
o Condición de ejecución. A evaluar para cada invocación de la regla, Si
la evaluación es positiva, se ejecutará el bloque principal de acciones
de la regla.

SSCC-SESPA
 En la evaluación de la condición se podrá utilizar la información

entrante en la invocación a la regla (recibida como entrada), así
como la obtenida mediante la invocación de consultas a otros
sistemas. Estas invocaciones a sistemas externos deberán
soportar como mínimo la consulta a servicios publicados en el
ESB.
o Bloque principal de acciones. A ejecutar en caso de que la condición de
ejecución se evalúe como “verdadera”.
o Bloque de acciones opcional. A ejecutar en caso de que la condición de
ejecución se evalúe como “falsa”.
o Prioridad de la regla.
 Tanto en la evaluación de la condición de ejecución, como entre las acciones
a ejecutar en los citados bloques, será posible invocar a sistemas externos a
través del ESB, y opcionalmente mediante otros mecanismos de integración.
 Posibilidad de ejecutar reglas ordenadamente en función de su prioridad.
 Flexibilidad y usabilidad para la definición y modificación de reglas en el
sistema.
4.3.5 Gestión de Datos Maestros

Se requiere la implantación de un subsistema destinado a la gestión, conversión,
adaptación y/o mapeo de datos maestros (Reference Data) que permita disponer de
una información homogénea que incorporar a los nuevos sistemas a implantar: tanto
al sistema Repositorio de Datos Primario, como al Repositorio de Datos Secundario.
No se pretende con este contrato el suministro de una solución de MDM, sino que se
acota inicialmente a resolver la problemática que se genera al centralizar datos que
no comparten los mismos conjuntos de valores para tablas maestras y que
finalmente deben consolidarse en un repositorio centralizado final. Se enumeran las
problemáticas a resolver y se identifican las conversiones entre sistemas “origen” y
“destino”, para facilitar la comprensión de la solución esperada.
El subsistema publicará sus funcionalidades a través de una capa de servicios
interoperables, poniéndolas así a disposición de cualquier componente de la
solución o de otro sistema corporativo que pudiese requerirlo.
El sistema proporcionará las funcionalidades necesarias para efectuar las
conversiones de datos “maestros” utilizadas por los distintos sistemas involucrados.
Las formas de uso previstas incluyen:
 Efectuar el mapeo de un valor, obtenido a partir de la siguiente información de

entrada:
o Identificación del sistema informático de origen.
o Identificación del sistema informático de destino.

SSCC-SESPA
o Identificación del concepto de datos a mapear (Ej. Códigos de países,

códigos de “sexos”, códigos de Centros)
o Valor a mapear.
 Se deberá soportar que los mapeos puedan ser no simétricos entre dos
sistemas concretos (Los mapeos de valores del “sistema A” al “sistema B”
podrían ser diferentes de los correspondientes del “sistema B” al “sistema A”.)
 Permitir la descarga de una tabla de mapeo completa de un concepto dado,

entre un sistema de origen y uno de destino. Para poder ser utilizada en otros
procesos de migración de datos externos al sistema.
 Permitir la consulta del listado de tablas de mapeo existentes entre un sistema

de origen y uno de destino.
 Permitir agregar nuevos sistemas de origen y destino.
 Permitir agregar, cargar y mantener conjuntos de mapeos entres sistemas.
 Flexibilidad para definir las reglas de mapeo que sean necesarias.
 Permitir definir reglas de mapeo de valores numéricos a valores

textuales/codificados en base a rangos de valores:
Ejemplo:
o [0..50] -> “Bajo”
o [51..75]  “Medio”
o [76..100] ”Alto”…
o En el anterior ejemplo, un valor numérico de 62 se mapearía al valor
textual “Medio”.
 Permitir definir varias reglas de mapeo ordenadas por prioridades.

Utilizándose dicha prioridad en los procesos de mapeo de valores.
 Permitir definir reglas o mapeos por defecto. Estas reglas por defecto deberán
poder generar alertas por configuración. Estas alertas se utilizarán con el fin
de revisar la calidad de los mapeos existentes y la conveniencia de incorporar
mapeos específicos para los datos convertidos con las reglas por defecto.
 Proporcionar herramientas o mecanismos para facilitar la validación

automática o semiautomática de las tablas de mapeos cargadas en el
sistema. (Ej. Catalogar conjuntos de datos de pruebas y validar que dichos
conjuntos de datos disponen de mapeos correctos, detectando los casos que
no dispongan de los mismos)

SSCC-SESPA
Está incluido en el alcance de este contrato el análisis y carga inicial de todos los
mapeos a realizar, según el conjunto de sistemas de información origen
seleccionados como fuentes de datos.
Si bien se requerirá la carga de todos los mapeos/conversiones que permitan la
conversión de los datos originados en los distintos sistemas de información origen
seleccionados y dirigidos hacia los nuevos sistemas en el objeto del contrato, el
sistema deberá disponer de la posibilidad de servir de repositorio de mapeos entre
cualquier pareja de sistemas de origen y destino, sin más que efectuar la carga de
dichos mapeos de valores.
4.3.6 Servidor de Terminologías Clínicas

Suministro e implantación de un sistema de GESTIÓN DE TERMINOLOGÍAS
CLÍNICAS que permita la estandarización de la información a las terminologías
clínicas que sean necesarias para la integración de los datos y consolidación de la
información en un repositorio único y centralizado. En adelante se hará mención a
este subsistema o funcionalidad como “Servidor de Terminologías Clínicas”, para
facilitar el buen entendimiento de lo que se solicita, pero sin condicionar que deba
suministrarse un Servidor de Terminologías al uso.
Si bien el uso previsto de este subsistema se centrará en los procesos de carga y
actualización de datos de los dos nuevos Sistemas (repositorio de uso primario y
secundario) el nuevo Servidor de Terminologías deberá configurarse para poder ser
utilizado por otros sistemas corporativos gracias a una capa de integración que
exponga sus servicios. Se aclara que el alcance se acotará inicialmente al ámbito de
este proyecto.
Los principales requisitos a cumplir por parte de este subsistema son:
 Deberá soportar la gestión de diversos catálogos y/o clasificaciones, al

menos todos los manejados por los sistemas de información origen
identificados del SESPA y los seleccionados para el trabajo en el repositorio
de datos destino.
 Deben permitir cargar Mapeos/correspondencias/equivalencias entre
catálogos y/o clasificaciones.
 Debe permitir la carga de catálogos/clasificaciones multiidioma.
 Deben facilitar la gestión de la vida de esos catálogos y clasificaciones.
o Simplificar la incorporación de nuevas versiones, así como de los
correspondientes mapeos, atendiendo a las diferencias de formatos y
distribución de los catálogos y clasificaciones más significativos.
 Debe ser integrable en una arquitectura SOA. Por ello, se valorarán las
posibilidades del producto en cuanto a integrabilidad de la solución,
ofreciendo una amplia variedad de mecanismos y posibilidades de
integración. Se valorará el hecho de estar basado en el estándar de Recursos
de Interoperabilidad de Salud Rápida (FHIR).

SSCC-SESPA
 El componente se proporcionará completamente operativo incluyendo la

carga de datos de las terminologías, clasificaciones y/o mapeos
correspondientes que se identifiquen como necesarios en la ejecución del
proyecto. A modo informativo, sin ser limitante respecto a otras terminologías
que se identifiquen a lo largo del proyecto, actualmente las principales
terminologías utilizadas en los sistemas de información del SESPA son las
siguientes:
SNOMED-CT
SNOMED II
LOINC
CIE10
CIE9
CIAP
CIAP 2
CIEO
Catálogo de pruebas de la SENIM
Catálogo de pruebas de la SERAM
No siendo una condición de obligado cumplimiento, se valorará como mejora que el

Servidor de Terminologías Clínicas tenga un alcance global a todo el SESPA, que
cubra las necesidades del resto de sistemas de la organización.
4.3.7 Analítica de Datos y monitorizacion

Este subsistema de analítica de datos deberá disponer de un almacenamiento local
en el que se registrará la información procedente del Repositorio de Datos de uso
Primario previamente anonimizada, por otro lado dispondrá de una herramienta que
permita la explotación estadística y analítica de los datos registrados. El conjunto de
ambos sistemas deberá proporcionar unas funcionalidades de cara al usuario final
para la explotación de los datos, similares a las proporcionadas por el producto
Kibana configurado sobre un cluster ElasticSearch.
La carga de datos se adecuará a los mecanismos acordados para la ingesta de
información desde los distintos sistemas origen.
El almacenamiento local de datos deberá ser escalable para permitir gestionar
grandes volúmenes de datos, requiriéndose la configuración en cluster extensible en
nodos.
La naturaleza tecnológica del almacenamiento quedará a discreción del
adjudicatario, contemplándose tanto soluciones basadas en sistemas relacionales,
como en índices de motores de búsqueda, (Ej. ElasticSearch), u otros tipos de
almacenamiento (MongoDB)
 Deberá disponer de una adecuada gestión de usuarios y grupos y espacios

de almacenamiento que permita configurar mediante permisos los accesos a

SSCC-SESPA
las funcionalidades principales y a los datos gestionados. Como mínimo

deberá permitr configurar:
o Gestión de “espacios de almacenamiento” o Tenants. Dentro de los
que se podrán agrupar, tantos los distintos conjuntos de datos a
explotar como los usuarios y/o grupos de usuarios con permisos para
efectuar diferentes acciones sobre dicho “espacio de almacenamiento”
o Control de acceso a las funcionalidades principales del subsistema
definible, al menos a nivel de grupo de usuarios.
o Control de acceso a los conjuntos de datos a explotar.
o Permitirá definir componentes gráficos (gráficas, dashboards) de forma
independiente entre distintos grupos de usuarios,
o La gestión de usuarios y grupos deberá integrarse con el sistema
Gestor de Identidades del SESPA.
 Permitirá a un usuario con privilegios adecuados la definición y configuración
de gráficas en diversos formatos así como tablas de datos. Entre los formatos
gráficos deberán incluirse al menos los siguientes:
o Gráficos de tartas, de barras, de líneas, mapas de calor, utilización de
mapas,
o Permitir agrupar la información por:
 Intervalos de tiempo
 Rangos de valores definidos por el usuario,
 Los “n” valores que maximicen o minimicen alguna función de
orden (suma,
o Modificar los parámetros de presentación de los elementos visuales.
(Etiquetas, títulos, leyendas, colores)
 Permitirá a un usuario con privilegios adecuados la definición y configuración
de cuadros de mandos (dashboards).
o Los componentes gráficos de un dashboard podrán vincularse entre sí,
con el fin de conseguir comportamientos dinámicos, permitiendo
incorporar y eliminar filtros que modifiquen los datos presentados en el
dashboard.
 Permitirá la inclusión de filtros, tanto en los gráficos como en los cuados de
mando.
 Permitirá la exploración de los datos de forma directa, permitiendo el filtrado
de los mismos por los distintos campos del modelo de datos.
 Permitirá la realización de búsquedas mediante un lenguaje de consultas.
 Se requiere que ante las modificaciones en el modelo de datos (arquetipos)
del sistema Repositorio de Datos de Salud, se aplique de forma simplificada y
lo más automatizada posible la actualización del correspondiente modelo de
datos del módulo de analítica de datos.
 El sistema deberá permitir:
o la inserción y actualización de los datos registrados.
o La invocación de consultas contra los datos almacenados en el
subsistema. Estas consultas deberán permitir tanto la extracción de
datos almacenados como su explotación agregada, por cualquier
campo o combinación de campos del modelo y mediante diferentes
sistemas y métodos de agregación.

SSCC-SESPA
 El sistema se deberá entregar:

o Totalmente integrado con los orígenes de datos necesarios.
o Configurado internamente, en estructura de usuarios/ grupos/
organizaciones.
o con el conjunto de scripts, desarrollos, procedimientos. Que sean
necesario para proceder a una recarga completa de la los datos a
explotar.

SSCC-SESPA
4.4 Visor 360

Suministro e implantación de un VISOR 360 que permita la consulta de un conjunto
configurable de datos del repositorio primario para que el profesional asistencial del
SESPA pueda conocer la información clínica más relevante de un paciente en
función de su perfil.
El Visor 360 se plantea como una herramienta de consulta de los datos
almacenados en el Repositorio de Datos de Salud, para ser utilizada por distintos
perfiles de personal sanitario del Servicio de Salud del Principado de Asturias. Se
establece como requisito general la facilidad de uso y agilizad del acceso a la
información que necesita consultar cada profesional.
El Visor 360 deberá cumplir los siguientes requisitos y características:
 Orientada principalmente a la presentación de los datos de un paciente

concreto.
 Deberá presentar la información principal disponible en el Repositorio de

Datos de Salud. Como parte del proyecto de implantación, se organizarán
sesiones de trabajo con un grupo específico de referentes del SESPA para
identificar el contenido y organización del visor. Se valorará una primera
propuesta por parte del licitador, que se tomará como referencia inicial en el
proyecto de implantación. A modo de ejemplo, se espera que el contenido del
visor muestre al menos:
o Totalidad de Informes médicos incorporados al Repositorio.
o Resultados de pruebas de laboratorio.
o Resultados de pruebas de imagen médica.
o Otros resultados de pruebas médicas.
o Problemas de salud.
o Antecedentes.
o Alergias.
o Alertas.
o Episodios y/o procesos.
o Citas y pruebas en atención hospitalaria.
o Medicación.
 Componente de visualización de datos en formato Línea del Tiempo.

o Este componente presentará en una línea de tiempo que soportará
zoom y desplazamientos, diferentes iconos identificativos de distintos
tipos de información (periodos de ingreso, informes de distintos tipos,
resultados de laboratorio, pruebas de imagen, periodos de incapacidad
transitoria, períodos de ingreso hospitalario).
o Los distintos iconos podrán ir acompañados de otros componentes
visuales que presenten información de resumen de cada elemento de
información (Por ejemplo, tooltips al pasar el ratón sobre el elemento),

SSCC-SESPA
o La selección por el usuario de un elemento concreto, deberá presentar

en la propia ventana la información de detalle que sea relevante. A
modo de ejemplo de la información a presentar considerar los
siguientes casos:
 El contenido del informe vinculado a una prueba/visita.
 El detalle de resultados de una analítica.
 Los enlaces a las imágenes de pruebas de imagen.
 Enlaces a los visores de otros tipos de pruebas (ej. ECGs)
 La información relevante vinculada a un ingreso.
o En caso de ser necesario, además se permitirá la navegación directa
hasta la pantalla donde poder consultar el detalle completo del
elemento seleccionado por el usuario, para el caso de no poder
presentarse toda esta información de detalle en la misma ventana.
 Configurable por Perfil o grupo de usuarios, de forma que la información

presentada y la agrupación de dicha información sea configurable para los
distintos perfiles de usuario que se definan inicialmente en la implantación del
proyecto y los que posteriormente se definan. (Ej. Cardiólogo, Enfermera de
Digestivo, Dermatólogo, Inspector)
 La gestión de perfiles de usuario y permisos permitirá a los futuros

administradores de la aplicación la creación de nuevos perfiles con
visualizaciones de los datos configurables a su medida.
 Control altamente configurable de la información mediante permisos

asignables a perfiles. Se deberá permitir el control de acceso a la información
configurable por perfiles al menos a los siguientes elementos: (ejemplo: perfil
A solo puede acceder a informes del mismo servicio, no puede ver formularios
de datos, o determinada información sensible)
o El centro/sistema de procedencia: Selección de áreas sanitarias,
centros, primaria, hospitalizada.
o Servicios.
o Tipos de informes, formularios de datos.
 Gestión de información de acceso restringido. Se dotará de un sistema que

permita fijar restricciones de acceso a la información con el fin de cubrir las
distintas necesidades legales y organizativas (como ejemplo de esta
necesidad se enumeran: Interrupciones del embarazo, Salud mental,
prevención de riesgos laborales).
o Esta funcionalidad permitirá controlar que determinada información
sobre un paciente concreto, sea únicamente accesible a un conjunto
restringido de usuarios del Visor 360.
o Se deberá contemplar un comportamiento en cuanto a restricciones de
acceso que sea compatible con las restricciones configurables
actualmente en los sistemas operacionales principales, de forma que
las restricciones que se definan en estos sistemas sean transmitidas y
actualizadas al Visor 360.

SSCC-SESPA
o Podrá requerirse la gestión de restricciones de acceso en base a

niveles de seguridad vinculados a elementos incluidos en la
información clínica (informes, formularios, episodios/procesos) y a cada
perfil de usuario, de forma que los perfiles con acceso a un nivel de
seguridad dado, puedan consultar la información clínica que tenga
asignado ese nivel. No obstante, la definición funcional exacta se
determinará en las fases iniciales de ejecución del proyecto.
 Aplicación web multinavegador.
 La integración con el Repositorio de Datos de Salud se realizará en base a la

interfaz FHIR desarrollada por el adjudicatario en el repositorio primario.
 El sistema deberá ser escalable e instalable en un entorno de alta

disponibilidad.
 El visor se asegurará siempre de mostrar la información totalmente

actualizada, detectando para cada uno de los datos mostrados si están
actualizados on-line. En caso contrario, como puede ocurrir cuando los datos
de un sistema no se transfieren on-line sino que tienen cierto retraso por estar
programados con actualizaciones programadas, se deberá forzar una
consulta a los sistemas origen para actualizar esos datos en el repositorio.
Sin alcanzar el nivel de requisitos imprescindibles, sí se valorarán muy

positivamente la inclusión del siguiente conjunto de funcionalidades orientadas a
facilitar y potenciar la usabilidad de la aplicación, entre las que se incluyen los
tres componentes siguientes:
 Componente de visualización de conjuntos de datos de información clínica en

formato “muro de publicaciones”. Este componente presentara los textos de
los tipos de información seleccionados por el usuario (Ej. Notas clínicas,
formularios de datos) en un componente único en el que la información se
presente en una única pantalla en orden cronológico de más reciente a más
antigua con “scroll infinito” (ampliando la información presentada a demanda
del usuario).
o Este componente deberá soportar la posibilidad al usuario de filtrar los
datos a presentar de forma flexible, al menos,
 Por el tipo de información a volcar: ej. Notas clínicas, informes,
formularios de registro de datos clínicos.
 Por el área sanitaria / centro/ primaria, especializada, Salud
Mental…
 Por los servicios vinculados a la información.
o Sobre la información seleccionada por el usuario, este dispondrá de la
posibilidad de efectuar búsquedas. Tras efectuar una búsqueda de un
texto, automáticamente en el muro se efectuará un desplazamiento

SSCC-SESPA
hasta la primera “ocurrencia” del termino buscado, incluso en el caso

de que el usuario no hubiera desplazado aún el scroll de la ventana
hasta dicho contenido. Asimismo dispondrá de botones para localizar
en el muro, la siguiente y la anterior ocurrencia con el fin de agilizar la
revisión de los resultados.
 Componente de búsqueda textual sobre la totalidad de información registrada

para un paciente. El objetivo de este componente es simplificar la localización
de datos concretos dentro de toda la información disponible sobre un
determinado paciente (Ej. Localizar el informe, nota clínica. en los que se
indicaba un determinado término/s).
o Los resultados de las búsquedas presentarán el tipo de elemento de
información en el que se han localizado las cadenas de texto
solicitadas, junto con un extracto del contenido en el que se mostrarán
de forma destacada las cadenas buscadas. Desde estos resultados de
búsqueda se podrá acceder a la pantalla donde se encuentra accesible
el elemento de información completo (la pantalla de visualización de la
nota clínica localizada, o bien del informe, la pantalla donde se
presenten las observaciones de la petición, el formulario de datos, o
aquel elemento de información en el que se hayan localizado los textos
solicitados)
o Entre las posibilidades de búsqueda que deberá ofrecer de forma
similar a otros buscadores, se deberán contemplar:
 Por defecto la inclusión de varias palabras provocará la
búsqueda de contenidos que las contengan todas. (operador
funcional AND)
 Soportar otros operadores de búsqueda:
 Soportar la búsqueda de elementos que contengan
alguna de las palabras indicadas (operador funcional
OR).
 Soportar la búsqueda de elementos que NO contengan
alguna palabra (operador funcional NOT)
 Soportar la agrupación de varias palabras para ser tratada como
una sola (por ejemplo encerrando las mismas entre comillas
dobles).
Igualmente serán valoradas otras propuestas que mejoren las capacidades del visor
360, complementarias a las anteriormente descritas.
En caso de que determinada información a presentar en el Visor 360 no pudiera

mantenerse actualizada ‘online’ en el Repositorio de Datos de Salud (por ejemplo
por imposibilidad de integrar online desde el Sistema operacional de origen al
Repositorio de Datos de Salud), el Visor 360 provocará, en el momento de acceder
un usuario a los datos no actualizados online de un paciente determinado, las

SSCC-SESPA
actuaciones necesarias para que esos datos de ese paciente se actualicen en el

Repositorio de Datos de Salud, inmediatamente antes de su presentación al usuario
El visor 360 tendrá especial cuidado con algunas características básicas y

recomendables para cualquier portal, como son:
□ Sencillez: "menos es más". Sitios claros y limpios, menús concretos y
directos. Los gráficos recargados y las animaciones deben ser utilizadas con
moderación y cuando su uso tenga justificación y esté relacionado con el
contenido.
□ Usabilidad: Fácil de usar, debe tener pocos pasos para llegar a la información,
debe procurar mostrar la información más importante a un clic.
□ Rapidez: Es muy recomendable que una página web cargue en menos de 3
segundos.
□ Universalidad: Deberá verse correctamente en la mayoría de navegadores.
□ Intuitivo.
□ Accesible: debe ser accesible a las personas con discapacidades.
□ Visor extensible. El visor 360 será compatible con el estándar SMART on
FHIR, de forma que se integre con el Repositorio de Datos de Uso Primario
mediante este interfaz estándar. Debe contemplar además la posibilidad de
incluir dentro de su interfaz futuros componentes, widgets o aplicaciones
desarrollados también como compatibles con SMART on FHIR.
□ Deberá permitir la apertura del Visor 360 desde aplicaciones externas,
manteniendo la autenticación del usuario. En caso de estar disponible y de
que el SESPA tenga adaptados los sistemas implicados, el visor 360 se
conectará al sistema Single Sign On (SSO) corporativo.
□ Integrable. Además de ser abierto de forma directa e independiente, la forma
de acceso principal consistirá en ser accedido desde los principales sistemas
de información clínica del SESPA, manteniendo el contexto del paciente de la
aplicación desde la que se lance el Visor y los datos de autenticación del
usuario (profesional del SESPA). Para facilitar una mejor experiencia del
usuario y no tener que solicitar las credenciales al lanzar la aplicación, estará
integrado con la solución Single Sign-On del Principado de Asturias
(actualmente Red Hat Single Sign-On).
o Además de la apertura del Visor como aplicación independiente desde
dichos sistemas, se proporcionará un mecanismo de apertura del Visor
que posibilite su integración dentro de la interfaz de usuario de otros
sistemas externos.

SSCC-SESPA
□ Estructura modular. Se tendrá en cuenta en la valoración de la solución la

orientación hacia un desarrollo basado en componentes independientes
aunque acoplables, que pueda permitir la integración de dichos componentes
en otros sistemas externos.
El visor 360 sustituirá al actual sistema CGM HUP (Healthcare Unified Platform), por
lo que deberá contemplar al menos toda la información que centraliza actualmente
dicho sistema, manteniendo y mejorando los procesos de actualización de datos e
integración con los distintos sistemas del SESPA. Estas integraciones ya habrán
sido contempladas en el desarrollo del repositorio de uso primario y por tanto los
datos serán consultados principalmente de este repositorio. El adjudicatario deberá
encargarse y planificar la gestión del cambio para la puesta en marcha del visor 360
y desconexión del HUP respecto las funcionalidades actuales como visor de
información.
Respecto a la capa de servicios implementada actualmente en el CGM HUP, estos
servicios para consumir información de pacientes deberán de proporcionarse desde
la capa de servicios del repositorio de uso primario.
4.5 Repositorio de Datos Anonimizados para

Uso Secundario
Se requiere contar con una serie de funcionalidades analíticas y de software para
poder procesar y analizar los datos de manera eficiente y efectiva. Al menos se
deben contemplar las siguientes funcionalidades:
 Integración de datos y extracción: Debe permitir la integración de datos de

diferentes fuentes, ya sean internas o externas.
 Acceso a los datos: Debe ser posible acceder a los datos de manera segura y
controlada, según los permisos de acceso establecidos por los propietarios de
los datos.
 Limpieza de datos: Es fundamental contar con herramientas de limpieza y
preprocesamiento de los datos para asegurar que los datos sean completos y
precisos.
 Análisis estadístico: El entorno debe soportar una amplia gama de técnicas de
análisis estadístico para extraer información relevante de los datos. Además,
debe de dar soporte a técnicas de minería de datos, aprendizaje automático
etc.
 Visualización de datos: El entorno debe permitir la creación de gráficos y
visualizaciones interactivas para ayudar a los investigadores a interpretar los
datos y comunicar los resultados de manera efectiva.

SSCC-SESPA
 Seguridad de datos: Es esencial que el entorno garantice la seguridad y

privacidad de los datos para cumplir con los requisitos legales y éticos.
 Colaboración: El entorno debe permitir la colaboración entre usuarios de la
plataforma, especialmente con perfil investigador y la gestión de proyectos
para fomentar el trabajo en equipo y el intercambio de conocimientos.
La infraestructura y servicios proporcionados deberán estar dimensionados para dar

cobertura a las necesidades de almacenamiento, procesamiento y servicios que
cubran las necesidades planteadas por el SESPA en el objeto y prescripciones
técnicas de este contrato. Podrá contemplarse la disponibilidad de un solo entorno
hasta llegar a la puesta en producción de la plataforma, momento en el que se
deberá disponibilidad de otro entorno de preproducción o test. Los servicios
desplegados se irán dimensionando según la necesidades del proyecto, optimizando
en todo momento el uso de recursos.
4.5.1 Infraestructuras y Servicios en la Nube

En el caso del Repositorio de Datos Anonimizados para Uso Secundario, se requiere
el almacenamiento y uso de servicios en la Nube.
La nube seleccionada deberá cumplir con las normativas aplicables en materia de
seguridad y en particular:
 Certificado de categoría Alta del ENS
 ENS – Certificaciones del Esquema Nacional de Seguridad 27001

Estará dotada de capacidades de escalabilidad que permitan el crecimiento, tanto
vertical como horizontal, sin necesidad de modificar la configuración inicial física y/o
lógica de la infraestructura, es decir, debe permitir tanto integraciones con nuevos
sistemas de información como incrementos en la capacidad de cómputo y
almacenamiento sin requerir de grandes esfuerzos de integración.
La plataforma software deberá estar basada en componentes que se fundamenten
en el Open Source, o muy extendidas en el mercado, que no limiten su utilización
por ser productos solo conocidos por el fabricante y sin una cobertura de partners.
Asegurará su escalabilidad a futuro y el desarrollo de una arquitectura flexible, que
dé respuesta a los diversos casos de uso y a las diferentes necesidades analíticas,
siendo la principal la explotación eficiente de grandes volúmenes de información
Debe permitir la ingesta de datos y procesamiento tanto en tiempo real como en
diferido mediante la carga en batch, esto es fundamental ya que no todos los
procesos requerirán de una actualización/carga continua de los orígenes y permite
reducir el coste computacional asociado a mantener estas bases de datos
actualizadas en tiempo real.

SSCC-SESPA
La plataforma software deberá disponer de los mecanismos necesarios para

garantizar la disponibilidad, la integridad de los datos y ser tolerante a fallos,
minimizando el impacto en la calidad del servicio, tanto para la ingesta y
almacenamiento de información como para el resto de las capacidades. En este
sentido, la plataforma software deberá incluir mecanismos de distribución de carga
en el clúster.
Los conjuntos de datos requerirán diferentes frecuencias de acceso, por lo que se
deberá poder asignar recursos de infraestructura y capacidad de procesamiento en
aquellos conjuntos de datos que así lo demanden, como puede ocurrir, por ejemplo,
con el análisis en tiempo real.
Se pretende disponer de una plataforma que soporte y sea compatible con las
tecnologías de almacenamiento y explotación de datos de mayor implantación en
este tipo de sistemas Big Data. El tipo de explotación de datos incluirá, no solo la
generación de eventuales descargas, junto con una explotación estadística de la
información, sino que deberá permitir la realización de proyectos de desarrollo de
proyectos de I+D basados en tecnologías de machine learning, mediante las que
desarrollar o mejorar modelos de inteligencia artificial por parte de diferentes grupos
de trabajo.
Se contempla en el objeto del contrato el conjunto servicios profesionales requeridos
para adecuar la nueva infraestructura en cloud al uso previsto de la misma, en todo
lo correspondiente a los procesos de gestión, certificación, adecuación,
administración. En todo lo relativo al cumplimiento normativo de la plataforma y las
herramientas incluidas principalmente en materia de seguridad y protección de
datos, de forma que se haga entrega de una infraestructura que cumpla con plenas
garantías todos los requisitos técnicos, funcionales y legales para su explotación.
4.5.2 Herramientas de almacenamiento, gestión y

manipulación y preparación de los datos
El Repositorio de datos para Uso Secundario deberá proporcionar un conjunto de
funcionalidades destinadas al almacenamiento de información de distintas
procedencias y en distintos formatos, su posterior procesamiento y manipulación,
principalmente orientados a combinar los datos de diferentes procedencias, filtrarlos,
actualizarlos y conseguir un nuevo conjunto de datos acorde a unas necesidades y
características definidas de forma específica (bien las necesidades expresadas por
un proyecto de investigación, o bien la necesidad de confeccionar una descarga
específica de un conjunto de datos). Este conjunto de datos final sería puesto a
disposición de sus destinatarios, mediante la asignación de permisos de acceso a
los mismos.
Deberá permitir la utilización de diferentes sistemas de almacenamiento de datos
masivos, que conformarán un lago de datos (data lake, de su traducción al inglés)

SSCC-SESPA
con información, tanto estructurada, como no estructurada, incluyendo al menos los

siguientes:
 Sistema de ficheros distribuidos HDFS o sistema de almacenamiento de

objetos, compatible con el estándar S3.
 Sistemas de almacenamientos NoSQL con estructuras columnares, basadas
en documentos, clave-valor y orientadas a indexación.
 Sistema de archivos de red Network File System (NFS).
 Cualquier otro sistema que sea necesario para los componentes propuestos
en la solución.
El data lake se organizará, a su vez, en capas lógicas, identificándose 3 niveles
principales:
 Capa bronze (Raw Layer): En esta capa se almacenarán los datos brutos,
procedentes de múltiples fuentes, en su formato nativo, sin ningún
procesamiento (raw data). Funcionará como la capa de entrada de datos,
para el data lake, y ayudará a evitar la extracción de los sistemas de origen.
 Capa Silver (Curated Layer): En esta capa se almacenarán los datos que se
han limpiado y modificado de su formato original. La finalidad de esta capa es
que los datos estén más preparados para ser consumidos, pudiéndose
realizar cálculos o agregaciones de los mismos.
 Capa Gold (Consumption Layer): En esta capa se almacenarán los datos
específicos para las aplicaciones y/o servicios analíticos, creados en el
entorno de la plataforma software, que consumen los datos del datalake. El
acceso a esta capa debe restringirse a los desarrolladores y usuarios de las
aplicaciones/servicios analíticos.
La plataforma software deberá permitir que los datos del data lake sean
provisionados, hacia otras capas u otros sistemas externos, mediante interfaces de
acceso, basados en estándares abiertos como API REST, JDBC, ODBC, etc
Formatos de información de entrada a soportar: El sistema deberá permitir
almacenar información almacenada en origen en diferentes formatos, entre ellos:
 Bases de datos relacionales. Constituirán inicialmente el principal origen de

información a incorporar.
 Imagen médica. Principalmente ficheros en formato DICOM.
 Ficheros.
Formatos de almacenamiento interno de la información. Se tendrá en cuenta la

disponibilidad en la plataforma de soporte para el almacenamiento de la anterior

SSCC-SESPA
información en una variedad suficiente de formatos técnicos. A modo de ejemplo, se

podrán ofertar los siguientes:
 HDFS
 S3
 Bases de datos basadas en documentos.
 Bases de datos de información geográfica.
 Bases de datos columnares o clave-valor
 Sistemas de indexación y búsqueda.
Herramientas de tratamiento de los datos.

El conjunto de herramientas a proporcionar en el Repositorio de uso secundario
permitirá a los usuarios técnicos habilitados el tratamiento de la información
incorporada al sistema, con el fin de poder incorporar nuevos conjuntos de datos,
revisarlos y corregirlos, efectuar las transformaciones necesarias con los mismos,
cruzar con otra información previamente disponible, documentar los datos,
metadatos y transformaciones realizadas y finalmente publicar de forma controlada
dentro de la plataforma los conjuntos de datos obtenidos para su acceso por parte
de los usuarios a los que se asignen los permisos pertinentes.
Integración con sistema de linaje de datos y de gestión de metadatos.

Las herramientas de almacenamiento de la información así como las encargadas de
su tratamiento deberán estar integradas con sistemas de gestión de los metadatos y
de linaje de los mismos que permita la adecuada descripción de la información
gestionada a través de la plataforma y posibiliten la documentación de los conjuntos
de datos tratados, aspecto especialmente relevante en los conjuntos de datos a
publicar para su uso final.
Publicación de datos procesados:

Los conjuntos de datos una vez procesados, filtrados y seleccionados por los
usuarios técnicos de la plataforma con las herramientas antes descritas, serán
publicados dentro de la plataforma para su utilización por parte de los usuarios a los
que se habilite el acceso de forma selectiva.
Los datos publicados, podrán ser replicados a un espacio de trabajo propio del
proyecto para ser posteriormente tratados mediante las herramientas
proporcionadas por la plataforma.

SSCC-SESPA
4.5.3 Herramientas de soporte al desarrollo de

modelos de Machine Learning
El repositorio de Datos Anonimizados para Uso Secundario deberá proporcionar
funcionalidades que permitan el análisis y procesado de la información mediante
tecnologías destinadas a la analítica avanzada de los datos, la aplicación de
técnicas de Machine Learning y el desarrollo y entrenamiento de modelos de I.A.
Todo ello puesto a disposición de proyectos independientes de investigación y
desarrollo que requerirán datos, componentes y funcionalidades independizados.
Incorporará herramientas/componentes para la construcción de modelos analíticos
avanzados, que seguirán el ciclo de vida propio de las técnicas de analítica
avanzada e inteligencia artificial. Entendiendo que los productos resultantes de esta
puedan ser desde cuadros de mando a modelos de inteligencia artificial pasando por
bases de datos preprocesadas listas para su publicación, es necesario que se de
soporte al ciclo de vida de este tipo de proyectos. A modo de resumen, un ciclo
genérico comenzaría con la ingesta o adquisición de datos, a los que se aplican
técnicas estadísticas para su análisis y procesado, de forma que sobre estos
conjuntos de datos se puedan construir, entrenar, validar y comparar los modelos
analíticos que, finalmente, serán publican para ser consumidos o reutilizables.
En particular se deberán soportar las siguientes funcionalidades:
 La forma de trabajo se basará en la existencia de equipos de trabajo

compuestos por profesionales de diferentes perfiles. Para esta confección de
equipos de trabajo será necesaria una adecuada gestión de usuarios, perfiles
o grupos de usuarios y permisos de acceso a los diferentes elementos de la
plataforma.
 Vinculados a dichos equipos de trabajo se podrán crear proyectos. Cada

proyecto encapsulará los recursos necesarios para cumplir unos objetivos –
típicamente de investigación y/o desarrollo- específicos.
 A estos proyectos se les habilitará el acceso a través de la plataforma a los

datos del repositorio que hayan sido solicitados previamente como elemento
de entrada en el proyecto. Una vez realizado todo el proceso de evaluación y
aprobación de la solicitud, se realizará la preparación de los datos a través de
las herramientas de gestión y manipulación de la información de la plataforma
y se habilitará el acceso al personal adscrito al proyecto.
 A dichos proyectos se les podrán asignar los recursos necesarios para las
tareas a acometer. Deberán disponer de:
o Acceso a copias de la información que necesiten explotar.
 Cada proyecto podrá disponer de un conjunto de datos para su
manipulación exclusiva acorde a sus necesidades.

SSCC-SESPA
 Se podrán solicitar las actualizaciones de los datos de partida de

forma puntual.
 El proyecto dispondrá de la posibilidad de incorporar al mismo
otros datos en principio no considerados como de interés
general para el repositorio en su conjunto, sino únicamente para
el proyecto concreto en que se requieran.
o La posibilidad de incorporar información que sea de interés específico
para el proyecto pero no para el resto de proyectos.
o Capacidades para la exploración de los datos, y su explotación
estadística.
o Herramientas de desarrollo y test de modelos de machine learning.
o Soportar el desarrollo basado diferentes en lenguajes de programación,
garantizando al menos el pleno soporte al lenguaje Python,
permitiendo incorporar librerías a cada proyecto independiente.”
o Se deberá permitir el uso de diferentes versiones de los lenguajes de
programación soportados a los diferentes proyectos gestionados en la
plataforma. Se deberá permitir también la incorporación de diferentes
versiones de librerías, para cubrir las necesidades específicas de los
distintos proyectos.
o El sistema se entregará configurado con estas librerías, para ser
“seleccionadas” al crear un nuevo proyecto…
o Permitir a los proyectos importar librerías específicas.
o En particular se valorará incorporar el soporte integrado para los
siguientes frameworks/librerías para lenguaje Python:
 TensorFlow
 Keras
 PyTorch
 MXNet
 spaCy
 Scikit-learn.
 MONAI
 Open CV
o Se requiere disponer de la funcionalidad de facilitar el desarrollo,
entrenamiento y/o optimización de modelos de inteligencia artificial de

SSCC-SESPA
forma automatizada (Auto ML). Se valorará la simplicidad del uso de

esta funcionalidad y el grado en el que facilite el desarrollo de modelos
a perfiles de usuarios no expertos técnicamente.
o Disponer de la posibilidad de aplicar Transfer Learning, tanto de cara a
importar a la plataforma algoritmos previamente entrenados, como de
exportarlos de la misma.
o Soporte a la utilización de Jupyter Notebooks o formatos
funcionalmente equivalentes.
o Posibilidad de realizar tratamiento de los datos suministrados en base a
desarrollos en lenguaje R.
4.5.4 Caso de Uso de Machine Learning en ámbito

farmacológico
Se propondrá en la oferta técnica al menos un caso de uso relacionado con el
ámbito farmacéutico.
En la fase de análisis y definición del proyecto de implantación, se formará un grupo
de trabajo con personas de referencia seleccionadas por el SESPA para identificar
posibles casos de uso de Machine Learning relacionado con el ámbito
farmacológico, además del/los propuestos por el licitador. Los propuestos por el
grupo de trabajo serán de un alcance, en esfuerzos, equiparable al propuesto por el
adjudicatario. Se pretende evitar que el adjudicatario se encuentre con la obligación
de desarrollar un caso de uso con una complejidad muy superior al dimensionado en
su oferta.
Se realizará por el adjudicatario un análisis previo de estos casos de uso
identificados y se estudiará la viabilidad de su implementación, atendiendo a todos
los aspectos que sean necesarios para su ejecución exitosa, como la disponibilidad
y calidad de los datos, posibles aplicaciones.
Finalmente el grupo de trabajo seleccionará para su ejecución un caso de uso
identificado como viable y el adjudicatario diseñará un plan de proyecto y se
encargará de su desarrollo.
4.5.5 Subsistema de Anonimización de datos

Se requiere el suministro e implantación de una solución de anonimización de datos
para las tareas de este proyecto o exportaciones del repositorio que requieran
anonimizar los datos de forma irreversible.
El alcance de esta solución de anonimización se limita a datos estructurados en los
que la anonimización se identifica como sencilla, sin tener que ejecutar algoritmos de

SSCC-SESPA
Procesamiento de Lenguaje Natural para identificar datos personales en textos no

estructurados, ni anonimización avanzada en imágenes médicas. Se requiere una
solución acotada en su complejidad para resolver la carga de datos anonimizados
desde el repositorio de datos de uso primario o bien desde otros sistemas
corporativos.
Se facilitará la actualización incremental de datos anonimizados en el repositorio
secundario, mediante un proceso de actualización que permita la agregación o
actualización de la información del repositorio cumpliendo la normativa vigente en lo
relativo a protección de datos de carácter personal y seguridad.
4.5.6 Ingesta de datos en el repositorio y carga

inicial
Además del análisis, modelado e implementación del repositorio para uso
secundario, se incluye en el alcance del contrato la ingesta de datos inicial y la
implementación de los mecanismos de actualización que se determinen.
La política de actualización de datos del repositorio secundario tendrá que diseñarse

de forma independiente a la del repositorio de uso primario debido, principalmente
debido a que:
 los datos a almacenar en el repositorio secundario, pueden incluir información

adicional a la registrada en el primario.
 La información en el repositorio secundario deberá estar anonimizada.
 El uso “secundario” previsto para la información de este repositorio.

Se tendrá en cuenta que los datos podrán obtenerse directamente de los Sistemas
de Información actuales del SESPA, o de los datos consolidados en el Repositorio
de Uso Primario del proyecto. En cualquier caso, se ejecutará el proceso de
anonimización y adecuación de los datos.
Captura y tratamiento de los datos de información desde diferentes fuentes, en
formatos estructurados y no estructurados, y asumiendo grandes volúmenes de
datos. Las fuentes de información podrán ser tanto internas al SESPA como
externas, de cualquier tipología.
Procesos de captura de información en tiempo real, cercanos a tiempo real o
procesos planificados.
Construcción de procesos de extracción, transformación y carga (ETL).

SSCC-SESPA
Construcción de flujos de datos y orquestación de procesos, incorporando elementos

de flujos de control, preparación de datos y evaluación de calidad de datos.
Los procesos se podrán ejecutar sobre la plataforma software y podrán ser
monitorizados para consultar su estado o resultados de ejecución.
La plataforma software incorporará múltiples conectores para facilitar la extracción e
inserción de datos.
4.5.7 Analítica de Datos y monitorizacion

Se requerirá disponer de analítica y monitorización de los datos almacenados en el
Repositorio de Datos de Uso Secundario, si bien deberá permitir la incorporación de
información de otros orígenes.
Deberá proporcionar por tanto soporte para implementar y desarrollar las técnicas de
analítica avanzada más habituales, entre otras:
 Data Mining y Text Mining.

 Aprendizaje automático (Machine Learning).
 Aprendizaje profundo (Deep Learning).
 Patrones y tendencias.
 Visualización y simulación.
 Análisis semántico.
 Análisis estadístico univariante y multivariante.
 Análisis de grafos.
 Clustering y algoritmos de clasificación.
Soportará al menos los lenguajes de programación Open Source para el desarrollo e
implementación de estos modelos y técnicas analíticas, incluyendo la posibilidad de
desarrollar código al menos en R y Python. Estos lenguajes de programación
cuentan con librerías y módulos validados de ciencia de datos, que facilitarán este
tipo de análisis. Además de esto, se proporcionará un entorno de programación
amigable que permitirá que los usuarios, con el rol de científico de datos, desarrollar
código desde una interfaz amigable sobre el entorno investigador en los lenguajes
mencionados previamente.
Deberá disponer de una herramienta que permita la explotación estadística y
analítica de los datos registrados.
4.5.8 Exportación de conjuntos de datos

El intercambio de datos facilita la publicación e intercambio de productos de datos. El
producto resultante de los proyectos de investigación o analítica avanzada no será únicamente
un modelo analítico o código, sino que en general podrá incluir diferentes tipos de contenido:

SSCC-SESPA
- Informes extraídos del análisis de los conjuntos de datos como resultado de

los proyectos de investigación, los cuales deberán reflejar, no solo los análisis
realizados en los datos, sino las fuentes de información empleadas, el linaje
de estas, transformaciones y análisis realizados y código empleado,
asegurando la transparencia y replicabilidad de todo el protocolo y estudio.
- Conjuntos de datos o vistas de datos resultantes de la consulta a las
diferentes capas del Data Lake, que hayan sido validados o empleados en
diferentes estudios y que se disponibilicen a la comunidad investigadora.
- Modelos analíticos tanto a nivel de código y documentación necesaria como
incluidos con sus dependencias en entornos virtuales o contenedores Docker
que permitan su descarga y replicabilidad de una forma ágil. Además, en el
caso de validar un modelo y publicarlo con un consumo periódico se deberá
poder publicar las APIs correspondientes que serán gestionadas desde la
plataforma software.
- Cuadros de mando y visualizaciones de datos desarrolladas sobre las fuentes
de la plataforma, de manera que puedan ser reutilizables en su totalidad o a
modo de template por otros investigadores/gestores para sus estudios.
El consumo de los modelos analíticos se podrá realizar también a través de las capacidades
que proporciona la capa de visualización y provisión.
Se valorará la posibilidad de exportación de conjuntos de datos a modelos

estandarizados o establecidos en proyectos nacionales o internacionales. Entre
estos modelos se puede identificar la exportación a modelo OMOP y/o el que se
defina para el Espacio de Datos del Servicio Nacional de Salud, requerimientos de
E.U. Patient Summary.
4.5.9 Trabajos derivados de cambios de proveedor o

de plataforma base
El proveedor deberá proceder a definir una solución alternativa y un proceso de

migración, para la traslación de la solución y sus datos a otro entorno, con similares
funcionalidades y rendimiento, para su ejecución en el caso de que el SESPA
considere totalmente necesario, de forma que pueda seguir utilizando la solución y
todos los datos registrados en ella desde el inicio de la prestación.
Si, por cualquier causa, se produce un cambio de proveedor en el contrato y fuera

necesaria una transición, o bien a futuro se produce un cambio de sistema
informático en el ámbito objeto de este expediente, el adjudicatario estará obligado a
dar toda la asistencia a un tercero, designado por el SESPA, a fin de posibilitar una
transición ordenada y operativa de todo lo realizado.

SSCC-SESPA
4.6 Gobierno del Dato

El alcance del presente contrato no tiene el objetivo de desarrollar un proyecto del
gobierno del dato para toda la organización, sin embargo es preciso cubrir las
necesidades específicas de este proyecto de implantación, puesto que los datos y su
gobierno son el elemento básico sobre el que pivota todo el sistema.
Se deberá realizar una propuesta que incluya las necesidades básicas para el éxito
del proyecto, que se identifican en los siguientes aspectos:
1. Arquitectura de Datos
2. Modelado y Diseño
3. Almacena-miento y operación
4. Seguridad
5. Calidad del Dato
6. Metadatos
7. Interopera-bilidad
8. Referencias y Datos Maestros
9. Analítica Descriptiva; 10. ML y MLOpps
4.7 Integración de Sistemas

Se incluye en el objeto del contrato el desarrollo e implantación de las
INTEGRACIONES que deban implementarse para la migración inicial y captura
ordinaria de los datos a obtener de los Sistemas de Información origen. Será
responsabilidad del adjudicatario identificar la solución específica óptima para
capturar la información, que deberá validarse y aprobarse por el SESPA y estar
alineada con las políticas establecidas por el Principado de Asturias respecto a
integración de sistemas en el ámbito sanitario (actualmente la Consejería de
Sanidad). Está excluida en esta contratación las adaptaciones y desarrollos que
ineludiblemente tengan que realizarse en los sistemas del SESPA, en el caso de que
no existan alternativas viables que no requieran modificaciones en los sistemas del
SESPA.
Desarrollo e implantación de las INTEGRACIONES que permitan a otros sistemas
del SESPA integrarse con los nuevos sistemas incluidos en el objeto del contrato
para el aprovechamiento o actualización de la información almacenada.

SSCC-SESPA
Se requiere que los distintos sistemas y subsistemas a implantar se integren en una

Arquitectura Orientada a Servicios, permitiendo así el uso de las funcionalidades
proporcionadas por cada uno de los nuevos componentes por parte del resto de
Sistemas corporativos. Esta arquitectura orientada a servicios que da lugar la
solución implantada se interconectará con el ESB corporativo sanitario, en el
momento que esté disponible. Considerándose incluidos en el ámbito del contrato
los desarrollos y/o parametrizaciones a realizar en el citado ESB.
En caso de que en las etapas iniciales de ejecución del presente contrato no se
disponga aún del citado ESB corporativo sanitario, se contemplará como incluido en
el presente contrato la implantación de un sistema ESB de carácter temporal que
actuará como elemento intermedio entre los distintos sistemas corporativos y los
nuevos componentes a implantar dentro del presente contrato. El conjunto de
desarrollos de integración realizados dentro del ESB temporal se migrará
posteriormente al ESB corporativo definitivo cuando se disponga del mismo. Se
contempla también dentro del objeto del presente contrato la migración de las
integraciones desarrolladas en el ESB temporal al ESB corporativo definitivo,
siempre que sea realizable dentro de la duración del contrato.
Para aquellas cargas de información necesarias por lotes, y aunque se puede
también el motor ESB para realizarlas, se proporcionará mecanismos para soportar
ETL (Extracting Tranforming and Load).
Se requerirá al eventual ESB temporal al menos las siguientes características
mínimas.
 Capacidad de securizar las integraciones definidas en el ESB en base a la

información de credenciales y permisos para usuarios y sistemas disponible
en el Gestor de Identidades del SESPA.
 Este motor de integración deberá dar soporte a integración estándar

tecnológica (Web Service – WS y REStful services) y estándar propio de
Sanidad (al menos, HL7 2.x y FHIR). Además se relacionan como mínimo lo
siguientes:
o SOAP 1.1/SOAP 1.2
o WSDL 1.1/WSDL 2.0
o MTOM/SwA
o Formatos REST.
o XML
o JSON
o HTTP.
o JMS

SSCC-SESPA
A continuación se proporcionan prescripciones técnicas detalladas para algunas de

las integraciones más representativas.
 Integrabilidad de la solución:
Los distintos sistemas a implantar dentro del ámbito del presente proyecto
deberán proporcionar una interfaz de integración que permita publicar sus
funcionalidades principales, para su uso por parte de otros sistemas
corporativos, como parte relevante de una Arquitectura Orientada a Servicios.
Las interfaces de comunicación estarán diseñadas para facilitar la flexibilidad
de adaptación a cambios, y estarán dimensionadas para cubrir las
necesidades computacionales existentes o previstas. Se persigue una
arquitectura orientada a servicios, aunque también se consideran válidas
otras arquitecturas monolíticas siempre que sean capaces de publicar sus
funcionalidades dentro de una arquitectura SOA.
La capa de servicios estará adecuadamente documentada para facilitar su
utilizar por otros sistemas.
 Integraciones con el resto de Sistemas de Información Sanitarios:

Las integraciones entre los nuevos sistemas a implantar en el ámbito de este
proyecto y el resto de sistemas del SESPA se realizarán prioritariamente a
través del ESB corporativo de sanidad utilizado como BUS de Integraciones,
cuando se estime que aporta un valor añadido, facilitando la utilización por
otros sistemas de una manera más eficiente, su monitorización y operación.
 Integraciones con solución corporativa de Procesamiento de Lenguaje Natural

(NLP):
Está prevista la licitación a nivel corporativo de un sistema de Procesado de
Lenguaje Natural, con el cual, los nuevos sistemas deberán integrarse para
hacer uso de las funcionalidades de dicho sistema que sean de utilidad en la
implantación de nuevos sistemas definidos como objeto del presente pliego.
En caso de disponer de este sistema durante la vigencia del contrato, se
utilizará como una fuente más de información, o prestador de servicios, para
dar valor añadido a la información almacenada en el repositorio.
 Integraciones con solución corporativa de Anonimización

En el caso de disponer el Principado de Asturias de un sistema de anonimización de
datos, la plataforma objeto de este contrato hará uso de dicha solución de
anonimización para todas situaciones que sean necesarias.

SSCC-SESPA
4.8 Análisis y Modelado

Es objeto de este contrato el ANÁLISIS y MODELADO de los conjuntos de datos
almacenados en los REPOSITORIOS A SUMINISTRAR. En el caso del repositorio
primario se requerirá la incorporación de los arquetipos necesarios para el adecuado
registro de la información disponible en los sistemas corporativos. En el caso del
repositorio secundario, se realizará tanto el análisis y diseño del espacio de datos y
las herramientas a desplegar para los análisis Big Data e Inteligencia Artificial.
Se requiere del adjudicatario la adecuada definición del modelo de datos tanto del
repositorio primario como del secundario.
Modelado de los datos flexible, adaptable y basado en estándares, para adaptarse a
las guías y diseños que se elaboren desde el Ministerio de Sanidad, especialmente
deberá de estar preparado para la implementación del Espacio de Datos que se está
diseñando por un grupo de trabajo específico.
4.8.1 Modelado del Repositorio de Uso Primario

En el caso del repositorio primario se requerirá la incorporación de las entidades de
información que modelan los datos almacenados (en adelante “arquetipos” para
facilitar la comprensión de este término, sin que deba entenderse sujeto a ninguna
norma o estándar específico) necesarios para el adecuado registro de la información
disponible en los sistemas corporativos.
El modelo de persistencia del Repositorio podrá estar basado en el estándar
OpenEHR, FHIR o bien en soluciones específicas, siendo responsabilidad del
adjudicatario la definición, configuración y carga del modelo de datos.
Se valorará que la solución esté enfocada a la definición de Modelo Dual: Es aquel
en el que la información clínica se organiza mediante un modelo de referencia (RM)
que proporciona las entidades y una estructura básica para representarlas, y unos
arquetipos o combinaciones restringidas y estructuradas de las entidades del modelo
de referencia
Los modelos duales permiten independizar los datos del conocimiento. Los datos
son fijos y estables en el tiempo (responden al RM), mientras que el conocimiento
clínico está sometido a un proceso continuo de cambios y evolución ligado a la
propia evolución de la ciencia médica.

SSCC-SESPA
Se valorará por tanto que el repositorio permita las funcionalidades de un CDM

(Common Data Model) que persista en la tecnología y modo que mejor rendimiento y
funcionalidades proporciones a la Organización de Salud, y que permita la definición
de arquetipos propios e importar/exporta las definiciones de otros estándares. Debe
tenerse en cuenta el inferfaz de interoperabilidad FHIR y las posibles ventajas de
poder incorporar ADLs para acelerar y normalizar la definición de arquetipos.
En la definición de los arquetipos se deberá tener en cuenta:
 Los estándares o recomendaciones de más amplia implantación.
 Las definiciones de arquetipos que pudieran utilizarse a nivel nacional.
 Las capacidades de registro de información de los sistemas de origen.

Se valorará que la definición de arquetipos pueda realizarse mediante un editor
fácilmente manejable para usuarios no técnicos. Se valorará que dicho editor
soporte la creación y/o modificación de arquetipos públicos disponibles en formato
ADL, o bien de recursos, y/o perfiles-contenidos FHIR. Deberá soportar la
incorporación/definición/actualización automatizada de los arquetipos en el
Repositorio de uso Primario y favorecerá la adaptabilidad del visor 360.
Dada la complejidad de la definición, mantenimiento, implementación de la
persistencia, interoperabilidad, se requiere un componente o módulo específico de la
solución que se encargue de la gestión y mantenimiento del repositorio de los
arquetipos, facilitando herramientas que permitan su uso compartido.
A continuación se enumeran algunas de las características que deberá cumplir el
repositorio de uso primario.
□ Solución para la captura de la información y persistencia de los datos basados
en los arquetipos definidos en el servidor. Permitirá la integración según

SSCC-SESPA
varias tecnologías, como una capa de integración por APIs, mapeos, ETL,
FHIR o procesamiento de mensajería o eventos.
□ Herramientas para la utilización de los datos, descargas específicas, analítica
de datos o incluso respuesta a trabajos de investigación que requieran
descargas específicas del repositorio. La solución facilitará estas tareas para
reducir la complejidad por la utilización de arquetipos.
□ Permitirá la extracción de la información para una visualización de los datos
personalizada. También tendrá que resolver la posibilidad de realizar
descargas de datos para sistemas analíticos o para procesos de analítica
avanzada. Se deberá facilitar la exportación de los datos registrados en el
sistema, al menos en formato JSON, o XML, de forma que se posibilite su
tratamiento de forma externa al sistema.
□ Monitorización y Auditoría sobre el repositorio.
□ APIs que faciliten la utilización de las distintas funcionalidades de la
plataforma. La solución será modular y orientada a servicios.
□ Podrá tener un Servidor de Terminologías, aunque también es posible su
implementación como otro subsistema externo y que haga uso de él, o como
otro componente del proyecto. En cualquier caso, deben cubrirse las
necesidades específicas de este proyecto.
□ Este subsistema o plataforma que controla el propio modelado y el
almacenamiento de la información y resuelve la persistencia de los datos
tendrá la capacidad de ser escalable y configurarse en alta disponibilidad.
Este subsistema resolverá la persistencia de los datos según los arquetipos
utilizados, sin mezclar la lógica de negocio y facilitando la interoperabilidad técnica
para la integración de los datos entre sistemas, que principalmente se realizará
utilizando FHIR. Se tendrá un mapeo a FHIR de sus servicios y de los contenidos
gestionados.
Tomando como punto de partida la información recopilada previamente por el
SESPA, el adjudicatario deberá identificar con el SESPA los conjuntos de datos y
Sistemas de Información que se seleccionan como principales para obtener la
información para el repositorio, realizando un trabajo de consultoría para documentar
todo lo necesario respecto a los datos, capacidades y tipologías de los sistemas de
información origen, capacidades de interoperabilidad, interlocutores, y todo aquello
que resulte necesario para incorporar exitosamente cada conjunto de datos. El
SESPA proporcionará información y asistirá en esta tarea al adjudicatario,
poniéndole en contacto con los proveedores que mantienen estos sistemas,
facilitando la comunicación y la documentación disponible.
Como resultado de los análisis realizados y la consultoría, se seleccionarán los
conjuntos de datos que se incorporarán al repositorio, estableciendo varias fases en
el proyecto para incluir en primer lugar los más relevantes e incorporando

SSCC-SESPA
progresivamente el resto. Según este análisis y planificación, el adjudicatario

realizará una propuesta para el modelado de cada uno de los conjuntos de datos,
que será revisada conjuntamente con el SESPA mediando grupos de trabajo que
validen y acuerden el modelo final.
4.8.2 Modelado del Repositorio del Uso Secundario

Este repositorio está pensado para el uso secundario, que principalmente se
identifica:
 Analítica descriptiva.
 Analítica avanzada implementando modelos de Machine Learning, Deep

Learning, Redes Neuronales, y en general la aplicación de la Inteligencia
Artificial.
 BigData.
 Investigación utilizando conjuntos de datos con un diseño específico pero

que vienen del mismo espacio de datos.
Como complemento al diseño realizado para el repositorio primario, en este
repositorio para uso secundario se trabajará con datos anonimizados, creando en un
primer momento un diseño de espacio de datos que permita cubrir las necesidades
más habituales respecto a estos usos.
Se aprovecharán la información del repositorio primario como uno de los orígenes de
información.
4.9 Gestión de usuarios, seguridad y auditoría

Los distintos sistemas y subsistemas a implantar deben incluir, al menos, las
siguientes funcionalidades vinculadas a la gestión de usuarios, seguridad y auditoría:
- Integración de la autenticación con el mecanismo corporativo establecido por
el Principado de Asturias, que para el caso de empleados se integrarán con
los credenciales corporativas (según LDAP y solución de Gestión de Identidad
(GID)). Se integrará con la solución Single Sign-On del Principado de Asturias
(actualmente Red Hat SSO).
- Los perfiles de usuario que existan en la organización para el caso de
profesionales, se gestionarán con la pertenencia a grupos en el LDAP
corporativo (Gestionado por el GID del SESPA), si es que es posible su
automatización en el GID, delegando también la autorización utilizando el
modelo RBAC (Role-Based Acces Control), es decir, modelo de acceso
basado en roles..

SSCC-SESPA
- Asegurar la auditoría y trazabilidad de la información registrada por los

usuarios del sistema, permitiendo el control histórico de la actividad y su
responsable. Es decir, se registrarán las actividades de los usuarios en el
sistema, de forma que:
o El registro indicará quién realiza la actividad, cuándo la realiza y sobre
qué información.
o Se incluirá la actividad de los usuarios y, especialmente, la de los
operadores y administradores en cuanto puedan acceder a la
configuración y actuar en el mantenimiento del sistema.
o Deberán registrarse las actividades realizadas con éxito y los intentos
fracasados.
o La determinación de qué actividades deben registrarse y con qué
niveles de detalle se adoptará a la vista del análisis de riesgos
realizado sobre el sistema.
o Se activarán los registros de actividad en los servidores.
o Toda la recolección de registros y correlación de eventos se podrá
requerirse que se trasladen a un sistema corporativo que gestione
centralizadamente esta información.
o Existirá una completa trazabilidad en los mecanismos de integración
que se utilicen entre sistemas, que utilizarán métodos de autenticación
y comunicación seguros.
Requisitos de seguridad del sistema de información

Con carácter general, todos los componentes y subsistemas deberán cumplir con las
directrices y normativas aplicables en materia de seguridad de los Sistemas de
información y Comunicaciones de la organización.
Específicamente los requisitos de seguridad del sistema construido deberán, al
menos:
a) Cumplir con la Política de seguridad de la organización y sus normativas
asociadas.
b) Cumplir con el Esquema Nacional de Seguridad (ENS) en el ámbito de
aplicación con un sistema categorizado como nivel alto.
 Realización de un análisis de riesgos formal, usando un lenguaje específico, con

un fundamento matemático reconocido internacionalmente. El análisis deberá
cubrir los siguientes aspectos:
1. Identifique y valore cualitativamente los activos más valiosos del sistema.

SSCC-SESPA
2. Identifique y cuantifique las amenazas posibles.

3. Identifique las vulnerabilidades habilitantes de dichas amenazas.
4. Identifique y valore las salvaguardas adecuadas.
5. Identifique y valore el riesgo residual.
 Cumplimiento de la guía de Seguridad de las TIC, CC-STIC 857, Requisitos de

seguridad para Aplicaciones de Cibersalud en el contexto del ENS. En un anexo
de la oferta técnica se explicará en detalle el cumplimiento de cada una de las
siguientes pruebas:
1. Prueba de la finalidad de la aplicación.

2. Prueba de la arquitectura.
3. Prueba del código fuente.
4. Prueba del software de terceros.
5. Prueba de la aplicación de criptografía.
6. Prueba de la autenticación.
7. Prueba del almacenamiento y la protección de datos.
8. Prueba de las interacciones específicas de la plataforma.
9. Prueba de la comunicación de red.
10. Prueba de la resiliencia.
 Cumplimiento de las medidas de seguridad exigidas para un sistema

categorizado de nivel alto ENS (anexo II ENS). En un anexo de la oferta técnica
se explicará en detalle este cumplimiento, es decir, como se van a cumplir cada
uno de los controles exigidos en dicho anexo II ENS.
c) Construir un sistema de información libre de vulnerabilidades y brechas de
seguridad que puedan afectar a cualquiera de las dimensiones de la seguridad
de la información, para ello el licitador realizará:
 Test de intrusión o pentesting sobre los sistemas informáticos que conforman el

sistema global con presentación de informe técnico detallado e informe ejecutivo
resultado de las pruebas anteriores.
 Auditoría del código fuente de los componentes desarrollados para el sistema
global.
NOTA: El sistema global solo podrá ponerse en producción cuando no existan
vulnerabilidades en el producto.
d) Cumplimiento de Reglamento General de Protección de Datos (RGPD) y Ley
Orgánica de Protección de Datos y Garantía de los derechos digitales
(LOPDGDD).
 Análisis de necesidad de realización de una Evaluación de Impacto en Protección

de datos (EIPD).
 Elaboración de Evaluación de Impacto en protección de datos (EIPD) antes de la
puesta del sistema en producción.

SSCC-SESPA
 Elaboración del Registro de Actividades de Tratamiento de la actividad/es

correspondiente/s.
 Formularios de recogida de datos adaptados al derecho de información en caso
necesario.
 Derecho a la limitación del tratamiento.
4.10 ASISTENCIA TÉCNICA Y MANTENIMIENTO

POSTERIOR A LA PUESTA EN PRODUCCIÓN
DE LA SOLUCIÓN
Se incluye en el objeto de este contrato la asistencia técnica y el mantenimiento de
los sistemas puestos en producción durante el período de ejecución del contrato,
desde su puesta en producción hasta la finalización del contrato.
Los servicios de mantenimiento necesarios son de carácter correctivo, adaptativo y
evolutivo. Así mismo, en aras del aseguramiento de la calidad, se entiende como
necesario un servicio Hot-Line de tercer nivel de soporte.
El soporte podrá solucionar las incidencias bien con actuaciones sobre los datos o
bien a través de la entrega de una nueva versión o de un parche correctivo sin
necesidad de esperar a una nueva versión completa para la subsanación de errores
o fallos ocultos. Asimismo, el soporte incluye la prestación de servicio para ayuda al
uso diario de la herramienta, resolución de dudas y consultas tanto técnicas como
funcionales.
Se proporcionarán canales telefónicos y de gestión de incidencias entre el personal
técnico del SESPA y el servicio de soporte del fabricante para resolver dudas
complejas o asesoramiento en las cuestiones técnicas del producto.

SSCC-SESPA
4.10.1 Mantenimiento de producto y soporte tercer

nivel
Para los servicios de mantenimiento de producto y soporte tercer nivel se
dimensiona un equipo de trabajo estimado, deberán tenerse en cuenta las horas de
dedicación estimadas para facilitar la ejecución de dichos trabajos:
Nº Horas
Perfil (2 años)
Director de proyecto 108
Jefe de proyecto 720
Consultor clínico 720
Consultor experto en Repositorios Datos Clínicos 720
Consultor experto en producto 720
Consultor Data Quality 720
Consultor Data Scientist 720
Consultor Big Data 720
Consultor Data Architect 720
Experto en integraciones con sistemas sanitarios e interoperabilidad 1440
Analista Programador 2160
Analista Programador experto en visualización de datos 720
Total 10188
La distribución de estas horas en perfiles profesionales queda sujeto a las

necesidades del proyecto y la solución que finalmente resulte adjudicataria, según
los trabajos que se requieran y la especialización técnica que implique la necesidad.
Lo que sí ha de tenerse en cuenta son las horas totales indicadas para estos
servicios (10.188 para 2 años).
4.10.1.1 Servicio de Mantenimiento de producto

Suministro de mejoras, parches y actualizaciones del software en las siguientes condiciones:
NOTA: Se relacionan todos los servicios que son necesarios para el mantenimiento de producto,
aunque una parte estén incluidos dentro de la garantía. Se justifica esta redacción para tener una
visión completa del mantenimiento a realizar, por coherencia con los servicios de mantenimiento
de producto que se requieren para los Sistemas de Información del SESPA. Entre los servicios
incluidos en la garantía está por ejemplo la “subsanación de errores o fallos ocultos que se pongan
de manifiesto en el funcionamiento de los productos entregados, o que se descubran mediante
pruebas o por cualquier otro medio”.

SSCC-SESPA
 Se garantizará la disponibilidad, sin coste adicional, de nuevas actualizaciones de todo el

software objeto de mantenimiento en un plazo máximo de tres meses a partir de su
comercialización por parte del fabricante.
 Al menos dos actualizaciones anuales de software y documentación incluyendo:

1. Corrección de errores.
2. Revisión de versiones.
3. Mejoras en el Software.
4. Licencias de uso para las instalaciones.
5. Procedimientos de actualización.
 Al menos bianualmente se realizará una actualización de software que implique una

subida de versión del producto, contemplando en este proceso de actualización la formación
que sea necesaria por el cambio.
 Todo el software liberado y previamente a su instalación, ha de ser visado,

validado y autorizado por el Responsable del Contrato del SESPA.
 En el caso de que una actualización principal de todo el software suponga un cambio de

plataforma tecnológica que el Responsable del Contrato no estime adecuada dentro de su
Plan de Sistemas, se garantizará la continuidad de la versión instalada durante al menos
cinco años.
 En caso de que un cambio normativo implique la modificación del software, está deberá
estar disponible al menos quince días antes de la entrada en vigor de dicho cambio.
4.10.1.2 Soporte de tercer nivel

a) Consultas a través de cualquiera de los posibles canales de comunicación, para que los
técnicos del Servicio de Salud del Principado de Asturias y de los centros de soporte
contratados (actualmente el Centro de Gestión de Servicios Informáticos – CGSI) puedan
establecer una comunicación fluida con los técnicos del fabricante del software para resolver
incidencias complejas, dudas funcionales, escalado de errores de aplicación. destinada a
garantizar la solución de incidencias de la forma más efectiva posible
b) Soporte Técnico. Permitirá la resolución de cualquier duda o incidencia sobre el

funcionamiento técnico de los sistemas objeto de este contrato.
Incluirá la realización de los informes técnicos y procedimientos de extracciones

de datos y tratamientos de la información necesarios para la resolución de las
incidencias. Además, se incluirán las tareas propias de administración de
sistemas, escaladas por el CGSI, para mantener el funcionamiento adecuado del
sistema.
El soporte técnico prestará colaboración al CGSI en todos los procesos, incluyendo la gestión

SSCC-SESPA
de capacidad, continuidad, disponibilidad y seguridad. Se incluirá la elaboración de

procedimientos sobre las Bases de Datos encaminados a optimizar el rendimiento y
garantizar la consistencia de los datos.
Cuando se considere necesario, se podrá solicitar soporte para las explotaciones

y procesos especiales no incluidos en el estándar del producto, tales como
extracciones de datos, estadísticas, o procesos automáticos realizados desde los
servidores de base de datos o en cualquier otro servidor o componente del
sistema.
c) Soporte Funcional y de Aplicación. Permitirá resolver cualquier duda o incidencia que se

presente sobre el funcionamiento o características de los productos objeto de este contrato.
Incluirá el análisis y valoración de los nuevos desarrollos que se soliciten.
d) Soporte de Integración. Resolución de incidencias producidas en el intercambio de

mensajes entre los productos objeto de este contrato y el resto de sistemas con los que se
integran.
Apoyo a la monitorización de las integraciones y a las acciones encaminadas a asegurar la

consistencia de las mismas. Incluirá todas las tareas de análisis, diseño, implementación e
implantación para la interconexión con cualquier otro sistema de información que sea
requerido.
e) Servicio de Explotación del Repositorio de Uso Secundario. Se contempla dentro del

presente pliego la explotación de las herramientas requeridas para el tratamiento de la
información gestionada a través del Repositorio de uso Secundario, en todas aquellas tareas
sobre las que no se haya efectuado una adecuada transferencia de conocimiento y no se
disponga por parte de la Administración del Principado de Asturias de personal dedicado y
con conocimientos suficientes.
f) Desarrollos sobre el sistema, modificaciones y nuevas peticiones. Desarrollo de nuevas

funcionalidades o adaptaciones como consecuencia de requisitos externos o internos.
Formación experta a los referentes Técnico-Funcionales de la Administración en temas
novedosos de la gestión, de inminente puesta en marcha o para la correcta asunción de
funciones expertas de administración de la plataforma. Diseño e implantación de nuevas
integraciones. Parametrización de nuevos campos o mensajes de intercambio entre el
Sistema de Información y el resto de sistemas con los que se integra

SSCC-SESPA
4.10.2 Servicio de Mantenimiento Evolutivo

La finalidad principal es asegurar la realización de las evoluciones funcionales o
parametrizaciones que sean específicas del SESPA y queden fuera de la línea de
desarrollo de los productos que el fabricante diseñe para todos sus clientes y no
puedan cubrirse con las horas del servicio de mantenimiento de producto y soporte
tercer nivel.
Cada trabajo a realizar a través de éste servicio se solicitará, valorará, autorizará y
facturará de manera individual, enmarcándose en bloques de necesidades:
 Desarrollo de nuevas funcionalidades o adaptaciones como consecuencia de

requisitos externos o internos.
 Formación experta a los referentes Técnico-Funcionales de la Administración

en temas novedosos de la gestión, de inminente puesta en marcha o para la
correcta asunción de funciones expertas de administración de la plataforma.
 Diseño e implantación de nuevas integraciones.
 Parametrización de nuevos campos o mensajes de intercambio entre el

Sistema de Información y el resto de sistemas con los que se integra.
Se establece una dedicación de 2547 horas (repartidas en 1273,5 horas anuales)

de trabajo para mantenimiento evolutivo en el ámbito de este contrato.
4.10.3 Horarios de Cobertura y Tiempos de Servicio

o Resolución
El horario de cobertura general para la prestación del servicio será de 08:00 a 18:00
de lunes a jueves y de 08:00h a 15:00h los viernes, excepto durante los meses de
julio y agosto que será de 08:00 a 15:00h de lunes a viernes. No obstante, el
Servicio de Salud tendrá la posibilidad de solicitar trabajos en horario no laborable
(parcheado, subidas de versión), si así se requiere, como parte integrante del
contrato.
El adjudicatario pondrá a disposición del Servicio de Salud al menos un teléfono de

contacto y una cuenta de correo donde reportar las incidencias detectadas que
serán clasificadas de acuerdo a los siguientes criterios. Se facilitarán los canales de
comunicación con el personal técnico y funcional del SESPA, así como la
coordinación con el CGSI.

SSCC-SESPA
El Acuerdo de Nivel de Servicio (ANS) se expresa atendiendo a la siguiente

clasificación:
Mantenimiento correctivo. Atendiendo al tipo de error:
Error Tiempo de resolución

máximo
Muy Grave: Error que impide el funcionamiento de
la aplicación sin disponer de una alternativa de 3 horas
funcionamiento.
Grave: Error que degrada el funcionamiento de la
aplicación teniendo otra alternativa que evite la
parada del centro o pérdida de funcionalidad de
alguna gestión principal de la aplicación. También 24 horas
se considera grave si existe un compromiso de
tiempo de respuesta con el centro o existe un
riesgo de parada inminente.
Leve: Error que afecta a módulos no críticos de la 14 días naturales

aplicación y no tienen repercusión próxima.
Resto de Servicios:
Servicio Tiempo de Tiempo de resolución

respuesta
Mantenimiento preventivo 72 horas Próxima versión
Mantenimiento perfectivo - Próxima versión
Mantenimiento evolutivo - Próxima versión.
En el caso de que sea necesaria una
nueva versión o “parche” que incluya
modificaciones oficiales con fecha
anterior a la aparición de una nueva
versión, se entregará ésta en la fecha
que determine la Administración
Sanitaria.

SSCC-SESPA
5 REQUISITOS DE ARQUITECTURA
TECNOLÓGICA
5.1 Requisitos infraestructura TIC.
El Servicio de Salud del Principado de Asturias dispone de la infraestructura alojada

en los CPDs corporativos del Principado de Asturias. La descripción de esta
infraestructura tecnológica se podrá solicitar a la unidad de contratación y se
entregará bajo acuerdo de confidencialidad.
Estas infraestructuras están disponibles para la implantación de este proyecto.
Deberán seguirse las políticas y directrices marcadas por el Principado de Asturias

respecto a la implantación, gestión y operación de los Sistemas de Información
corporativos.
En caso de que el sistema propuesto sea compatible con las tecnologías indicadas,
deberá incluirse en la oferta las necesidades requeridas para la puesta en marcha
de todos los entornos a proporcionar, la ampliación requerida debe utilizar los
mismos elementos hardware y software que los indicados en este punto. La no
inclusión de esta información de requerimientos hardware será causa de exclusión
de la licitación. En caso contrario, es decir, que las infraestructuras disponibles no
fuesen compatibles total o parcialmente con el sistema propuesto, el adjudicatario
aportará el equipamiento para la puesta en marcha de la solución (todos los
entornos) y se hará cargo del mantenimiento durante los doce meses posteriores a
su puesta en funcionamiento.
En cualquier caso y para no generar dudas, se hace explicito que no forma parte de
la licitación el suministro de hardware para todos los sistemas que se implanten on
Premise, pero se requiere conocer los requerimientos de la solución propuesta. El
licenciamiento de software que se requiera si es objeto de este contrato y deberá
aportarse por el adjudicatario.
Plan de contingencia, Alta disponibilidad y CPD de respaldo.
La plataforma se configurará en alta disponibilidad y todos los componentes, con la

lógica excepción de software instalado en puesto de trabajo (cliente), estarán
redundados.

SSCC-SESPA
El Principado de Asturias dispone de un CPD Principal y un CPD Secundario

funcionando en modo activo/pasivo. Forma parte de la implantación la puesta en
marcha de la solución en ambos CPD.
Forma parte de la implantación, la elaboración del Plan de Contingencia para el
supuesto de que el sistema de información deje de estar accesible por cualquier
causa. Dicho Plan de contingencia debe contemplar los procedimientos a ejecutar
para poner en marcha el sistema en el CPD de respaldo, así como la definición de la
forma trabajo ante una imposibilidad total de uso del sistema.
La puesta en marcha requerirá necesariamente de la superación de un plan de
pruebas de puesta en marcha en el CPD Secundario que el adjudicatario debe
elaborar y consensuar con el Servicio de Salud.
Entornos a proporcionar.
Para aquellos productos a instalar en las infraestructuras del Principado de

Asturias, deben ponerse en marcha los siguientes entornos:
- Producción en CPDp (CPD Principal) y CPDr (CPD respaldo)
- Preproducción en CPDr
- Desarrollo en CPDr
Todos ellos serán independientes y deberán estar operativos a la vez sin interferir
entre ellos.
La documentación entregada debe permitir a los técnicos de la Administración del
Principado de Asturias la puesta en marcha de otros entornos en cualquier momento
y en caso necesario.
Los entornos podrán convivir funcionando a la vez en el mismo hardware de forma
autónoma sin interferir entre sí.
Con el fin de optimizar las plataformas es posible que mediante el uso de máquinas
virtuales y de técnicas de disaster recovery los entornos de preproducción y
desarrollo hagan uso de las mismas infraestructuras físicas que el entorno de
respaldo.
Para aquellos productos a instalar en la nube (repositorio de uso secundario), la
infraestructura y servicios proporcionados deberán estar dimensionados para dar
cobertura a las necesidades de almacenamiento, procesamiento y servicios que
cubran las necesidades planteadas por el SESPA en el objeto y prescripciones
técnicas de este contrato. Podrá contemplarse la disponibilidad de un solo entorno
hasta llegar a la puesta en producción de la plataforma, momento en el que se
deberá disponibilidad de otro entorno de preproducción o test. Los servicios

SSCC-SESPA
desplegados se irán dimensionando según la necesidades del proyecto, optimizando

en todo momento el uso de recursos.
Dimensionamiento de los entornos

Debe entregarse como parte de la oferta el dimensionamiento de cada uno de los
entornos teniendo en cuenta los siguientes criterios.
Producción.
El sistema debe estar adecuadamente dimensionado, teniendo en cuenta los
servicios ofrecidos y los usuarios potenciales.
Preproducción.
Aproximadamente debe tener un 10% de la capacidad del entorno de producción en
cuanto a usuarios del sistema y del 100% en cuanto a la capacidad de gestión de
historias clínicas y permitir realizar las pruebas de carga necesarias para la
validación del sistema.
Desarrollo.
Debe ser suficiente para poder compilar cualquiera de los módulos integrantes de la
solución y para las labores de desarrollo y/o pruebas que se requieran.
Escalabilidad y Elasticidad
Se requiere que la solución tecnológica propuesta incorpore capacidad de
escalabilidad vertical y horizontal a posibles escenarios de aumento de demanda de
los servicios centralizados.
Se valorará positivamente que además de la capacidad de escalabilidad reactiva
anterior, se incorporen mecanismos automatizados de adaptación de las
capacidades de almacenamiento y cómputo a las necesidades del servicio en tiempo
real (elasticidad).
Pruebas de aceptación
Como paso previo a la entrada en producción, se requerirá superar exitosamente al
menos las siguientes pruebas de aceptación de la infraestructura:
- Pruebas de Alta Disponibilidad en el CPD Principal, evidenciando la
continuidad del servicio ante distintas eventualidades o contingencias
- Pruebas de Continuidad de Negocio, que deberán evidenciar que el servicio
de producción, ante contingencias o eventualidades graves en el CPD

SSCC-SESPA
Principal puede der restaurado en el CPD Secundario con valores de RTO y

RPO aceptables.
- Pruebas de Carga para evidenciar que la plataforma está correctamente
dimensionada para soportar la demanda de servicio esperada.
6 LICENCIAMIENTO
El licitador debe aportar licencias y soporte de todos los componentes software de la
solución propuesta para los entornos que lo requieran.
El licenciamiento del sistema objeto de contratación, será corporativo para todos sus
componentes. Se entiende que está incluido todo el software necesario para la
ejecución del sistema, así como el soporte y mantenimiento del mismo durante la
vigencia del contrato. Esto incluye licencias de sistema operativo, Gestor de Base de
Datos, servidor de aplicaciones y cualquier otro software base que fuera necesario
para la correcta ejecución del sistema. Para todos aquellos elementos software que
se instalen en la infraestructura actual del Principado de Asturias, y no requiera un
incremento de licenciamiento por parte del Principado de Asturias, no será necesario
que el adjudicatario aporte las licencias que corresponderían a una instalación
independiente. No será necesario por parte del adjudicatario incluir licencias de
backup, o de monitorización.
El suministro de las licencias de uso de las nuevas versiones del programa que el
fabricante pudiera desarrollar en el futuro y que se compromete a suministrar sin
costo adicional al SESPA, durante la duración del presente contrato y comprende las
siguientes definiciones:
• Acciones Correctivas: trabajos realizados por el fabricante encaminados a
resolver errores de los programas en explotación.
• Acciones Evolutivas: trabajos realizados, siempre de "motu propio", por el
fabricante para la introducción en los programas de nuevas funcionalidades o mejora
de los procesos ya existentes. Se asegurará la participación del SESPA en la
orientación de aquellos aspectos del aplicativo que le pudieran afectar.
El adjudicatario se compromete a mantener informado al SESPA, al menos de forma
periódica, acerca de las nuevas funcionalidades sobre las que el fabricante esté
trabajando. En caso de que hubiera alguna disconformidad respecto a los
contenidos de las nuevas funcionalidades, el adjudicatario habilitará los
procedimientos necesarios para que la funcionalidad en cuestión pueda no ser
utilizada por el SESPA. Así mismo el adjudicatario mantendrá informado al SESPA
de en qué versiones evolutivas de producto irán incorporadas dichas
funcionalidades.

SSCC-SESPA
7 FORMACIÓN Y DIFUSIÓN
El adjudicatario definirá y acordará, junto a la Dirección del Proyecto, los programas
y material de formación y difusión que se precisen para cubrir formación técnica, de
soporte y programa de difusión y gestión del cambio.
Será el adjudicatario el encargado impartir la formación específica, considerando, al
menos, los siguientes aspectos:
 Formación Técnica. Orientada al personal técnico informático. Se realizará

formación en la administración, parametrización y soporte a usuarios.
 Formación de Soporte. El plan de formación incluirá de forma claramente

identificable las actividades y estrategias formativas destinadas a la
transferencia de conocimiento y a la consecución del modelo de soporte
conjunto con el CGSI durante la ejecución del proyecto.
 Formación a los referentes/formadores. Orientada a la formación de

referentes dentro del personal asistencial que designe la Administración del
Principado.
Se elaborarán guías prácticas, vídeos explicativos, sistemas guiados de autoayuda y

aquellos otros medios convenientes para complementar la formación y el plan de
comunicación y difusión, así como los medios más adecuados para ponerlos a
disposición de personal de la administración y ciudadanos.
8 FASES E HITOS DEL PROYECTO

Se identifica a continuación el diseño de fases en la que se desarrollará el proyecto,
incluyendo adicionalmente los hitos principales de los trabajos generales a realizar.
Estas fases se tomarán como una referencia para la obtención de hitos y
entregables inicialmente identificados, pero no limitará la ejecución del proyecto con
una metodología ágil en la que se vayan consiguiendo objetivos y productos
parciales que con el avance del proyecto se vayan completando y perfeccionando.
A continuación se describen las fases, hitos y tareas que conforman a alto nivel el
proyecto. Debe tenerse en cuenta la alta complejidad y volumen de tareas a
desarrollar en cada una de las fases, que además dependerá de la oferta técnica

SSCC-SESPA
diseñada por el adjudicatario. Los hitos y tareas que se relacionan a continuación se

corresponden con los principales entregables esperados. El adjudicatario describirá
en su oferta el desarrollo de tareas a alto nivel para la consecución de los objetivos
del proyecto, teniendo libertad para organizar y diseñar el proyecto de la forma más
eficiente y efectiva posible.
Las tareas y entregables que se describen se han de tomar como mínimos a obtener
en cada una de las fases, el diseño detallado de hitos, tareas y entregables será
propuesta por el adjudicatario y acordada con el SESPA.
 Fase 1. Análisis y Diseño detallado de la solución

(Hito 1. - 2 meses desde inicio del proyecto)
Tareas principales, entregables:
- Dinámica de gestión y dirección del proyecto.
- Documentación de análisis y diseño detallado de la solución.
Se incluirá la definición funcional de los distintos componentes y la
priorización consensuada de funcionalidades a introducir en los
subsistemas a lo largo del proyecto.
- Modelado inicial de la información en los repositorios de datos.
- Datos Maestros y Terminologías Clínicas.
- Establecimiento del gobierno de dato en el proyecto.
- Documento de Diseño y Arquitectura tecnológica necesaria en el proyecto
a desplegar en el CPD del Principado de Asturias (documento DDA según
metodología del Principado), Repositorio Primario.
- Documento de Diseño y Arquitectura tecnológica para el Repositorio de
uso Secundario.
 Fase 2. Instalación de la infraestructura tecnológica para el Repositorio de Uso

Primario y Secundario
- Documento actualizado de Diseño y Arquitectura tecnológica necesaria en
el proyecto a desplegar en el CPD del Principado de Asturias (documento
DDA según metodología del Principado), Repositorio Primario. Se
acompañaran los documentos adicionales necesarios como el Manual de
Instalación y Operación (MIO).
- Documento actualizado de Diseño y Arquitectura tecnológica para el
Repositorio de uso Secundario.
- Informe técnico de la arquitectura tecnológica instalada.
 Fase 3. Despliegue de la solución en los sistemas de desarrollo e integración

o Hito 3.1 Repositorio de Uso Primario
- Primera revisión de la definición del modelo de datos inicial.

SSCC-SESPA
- Diseño técnico del proceso de ingesta y actualización de datos.

- Carga de Datos Maestros y Terminologías Clínicas.
- Entrega de la documentación técnica requerida para cada uno
de los componentes de la solución. Manuales técnicos y de
operación.
- Instalación de los componentes del repositorio primario en los
entornos de desarrollo e integración. Configuración inicial de los
mismos.
- Primera ingesta de datos.
o Hito 3.2 Repositorio de Uso Secundario

- Entrega de la documentación técnica requerida para cada uno
de los componentes de la solución. Manuales técnicos y de
operación.
- Diseño técnico del proceso de ingesta y actualización de datos.
- Procesos de anonimización y pseudonimización de datos.
- Instalación de los componentes del repositorio en el entorno de
integración, con una configuración básica y consumos de
recursos adecuados a la carga de trabajo inicial.
- Primera ingesta de datos.
 Fase 4. Despliegue en producción carga inicial de datos de los repositorios

(primario y secundario)

- Definición del modelo de datos inicial. Implantación en producción.
- Configuración inicial del repositorio.
- Carga inicial de información al repositorio.
- Interfaz FHIR y SMART On FHIR.
- Actualización y perfeccionamiento de los componentes del Sistema.

- Instalación de los componentes del repositorio en el entorno de
producción, con una configuración y consumos de recursos adecuados
a la carga de trabajo inicial.
- Carga inicial de datos. Anominización de datos.
- Analítica de datos y monitorización.
 Fase 5. Despliegue en integración de la capa de integración para la actualización

on-line del repositorio de datos primario

SSCC-SESPA
- Entrega de la documentación técnica requerida, tanto de las integraciones

y procesos de actualización de datos, como de los componentes
utilizados.
- Configuración y pruebas de las integraciones con el repositorio primario.
 Fase 6. Despliegue en producción de la capa de integración para la actualización

on-line del repositorio de datos primario
- Configuración y pruebas de las integraciones con el repositorio primario.
- Entrega parcial de los materiales de formación técnicos y de soporte.
- Formación técnica y de soporte iniciales.
 Fase 7. Despliegue en integración del visor 360

- Entrega de la documentación técnica requerida.
- Instalación en el entorno de integración de la primera versión del visor 360.
- Entrega parcial de los materiales de formación (referentes/formadores).
- Integración del visor 360 con otros sistemas del SESPA.
 Fase 8. Despliegue en producción del visor 360

- Formación a formadores/referentes.
- Documentación técnica de instalación y operación.
- Despliegue y configuración de la primera versión de la solución.
 Fase 9. Desarrollo de un caso de uso para farmacia

(Hito 9. – Resultado del caso de uso de farmacia - 18 meses desde inicio del
proyecto)
- Entrega de la definición funcional del caso de uso.
- Análisis y diseño del proceso de ejecución del caso de uso.
- Configuración del repositorio, carga de datos necesaria y ejecución del
proceso.
- Entregables finales del caso de uso.
 Fase 10. Despliegue en integración de segunda versión de los Repositorios con

un alcance ampliado respecto a los datos almacenados e integraciones

SSCC-SESPA
- Despliegue en integración de una evolución de los repositorios acorde al

alcance funcional definido en la fase I del proyecto.
- Entrega de la documentación funcional y técnica actualizadas.
 Fase 11. Despliegue en producción de segunda versión de los Repositorios con

un alcance ampliado respecto a los datos almacenados e integraciones
- Despliegue en producción de una evolución de los repositorios acorde al
alcance funcional definido en la fase I del proyecto.
- Entrega parcial de los materiales de formación.
 Fase 12: Soporte y consolidación del espacio de datos desplegado en

producción.
(Hito 12. - Finalización del proyecto de suministro e implantación del espacio de
datos. Se inicia la fase de mantenimiento regular del sistema y soporte de tercer
nivel. - 24 meses desde inicio del proyecto)
- Entrega final de los materiales de formación
- Formación y difusión de personal técnico y de referentes. Transferencia de
capacidades de soporte y mantenimiento de los sistemas.
 Fase 13: Soporte del Sistema y Asistencia Tercer Nivel.

(Hito 13. - Transferencia tecnológica del suministro e implantación del espacio de
datos e información de mantenimiento y soporte
(46 meses desde inicio del proyecto)
Hito 13: Cierre del proyecto
(48 meses desde inicio del proyecto)
- Servicio de mantenimiento de producto, correctivo, adaptativo y evolutivo.
- Soporte tercer nivel.
- Informe trimestral de prestación del servicio de mantenimiento y soporte
de tercer nivel.
Se muestra un cronograma de la planificación estimada para las fases del suministro

(Fase 1 – 12):

SSCC-SESPA
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24
Fase 1. Análisis y Diseño detallado de la solución
Fase 2. Instalación de la infraestructura tecnológica para
el Repositorio de Uso Primario y Secundario
Fase 3. Despliegue de la solución en los sistemas de
desarrollo e integración
Fase 4. Despliegue en producción y carga inicial de
datos de los repositorios (primario y secundario)
Fase 5. Despliegue en integración de la capa de
integración para la actualización on-line del repositorio de
datos primario
Fase 6. Despliegue en producción de la capa de
integración para la actualización on-line del repositorio de
datos primario
Fase 7. Despliegue en integración del visor 360
Fase 8. Despliegue en producción del visor 360
Fase 9. Desarrollo de un caso de uso para farmacia

Fase 10. Despliegue en integración de segunda versión
de los Repositorios con un alcance ampliado respecto a
los datos almacenados e integraciones
Fase 11. Despliegue en producción de segunda versión
de los Repositorios con un alcance ampliado respecto a
los datos almacenados e integraciones
Fase 12: Soporte y consolidación del espacio de datos
desplegado en producción

SSCC-SESPA
9 PROPIEDAD
La propiedad de los trabajos y productos derivados de este contrato dependerá de la
solución propuesta por el licitador.
Todas las licencias, de productos principales o secundarios, software o hardware

que lo requiera, deben ir a nombre del SESPA.
Para los componentes software de la solución propuesta basados en desarrollos a

medida para el SESPA aplica el punto “Productos sin licencia”, para los
componentes software de la solución propuesta basados en productos con algún
tipo de licencia aplica el punto “Productos con licencia”.
9.1 Productos sin licencia

En el caso en que el licitador proponga componentes que no sean propiedad de un
fabricante o conjunto de fabricantes, el adjudicatario cede los derechos derivados de
la Ley de Propiedad Intelectual a favor del SESPA, tanto del componente software
adquirido o desarrollado, como de los subsistemas que lo integren, así como de
todos los productos y subproductos elaborados por el adjudicatario como
consecuencia de la ejecución del presente contrato, cediendo todos los derechos de
explotación y propiedad de los mismos.
Estos derechos comprenden la reproducción, distribución, comunicación pública y

transformación, total o parcialmente, a favor del SESPA sin que pueda oponerse a
ello el adjudicatario autor material de los trabajos. La titularidad de estos derechos
afecta, a título enunciativo y no limitativo, al conjunto de la documentación técnica de
análisis y diseño, documentación de planificación y pruebas, documentación de
usuario, productos audiovisuales, software desarrollado específicamente para el
SESPA y, en conjunto, todos y cada uno de los trabajos, informes y documentos
susceptibles de ser objeto de propiedad intelectual.
El adjudicatario garantiza al SESPA que el desarrollo es absolutamente original, por
lo que puede garantizar que todo el software y las herramientas utilizadas no
vulneran ninguna normativa, contrato, derecho, interés o propiedad de terceros.
El adjudicatario renuncia expresamente a cualquier derecho que pueda

corresponderle sobre los trabajos realizados como consecuencia de la ejecución del
presente concurso y no podrá hacer ningún uso o divulgación de los estudios y
documentos utilizados o elaborados sobre la base de este pliego de condiciones,

SSCC-SESPA
bien sea en forma total o parcial, directa o extractada, original o reproducida, sin
autorización expresa del SESPA.
9.2 Productos con licencia
En el caso en que el licitador proponga componentes con algún tipo de licencia, el

SESPA reconoce los derechos derivados de la Ley de Propiedad Intelectual a favor
del adjudicatario o terceros, tanto del componente software adquirido o desarrollado,
como del conjunto de documentos, diagramas, esquemas y demás elementos
previos que lo conforman.
El adjudicatario cede su desarrollo únicamente para su uso por parte del SESPA,
comprometiéndose el SESPA a no ceder su uso parcial o total de ninguna forma, ni
ponerlo a disposición de terceros.
El adjudicatario garantiza al SESPA que el desarrollo es absolutamente original, por

lo que puede garantizar que todo el software y las herramientas utilizadas no
vulneran ninguna normativa, contrato, derecho, interés o propiedad de terceros.
En todo caso, y aun cuando se excluya la cesión de los derechos de explotación

relativos a la propiedad intelectual, el SESPA podrá siempre autorizar el uso del
correspondiente producto a los entes, organismos y entidades de él dependientes.
El adjudicatario acepta expresamente que no podrá hacer ningún uso o divulgación

de los estudios, trabajos y documentos utilizados o elaborados sobre la base de este
pliego de condiciones, bien sea en forma total o parcial, directa o extractada, original
o reproducida, sin autorización expresa del SESPA.
El SESPA podrá divulgar, sin requerir autorización del contratista, los trabajos
realizados y el uso de los componentes.

SSCC-SESPA
10 ENFOQUE METODOLOGICO Y
DOCUMENTACIÓN
Para acometer los objetivos perseguidos por el Servicio de Salud del Principado de
Asturias se establecerá una metodología de trabajo que permita coordinar las tareas
a realizar y disponga de los mecanismos de control y seguimiento básicos que se
concretarán en la primera etapa del proyecto.
El método de trabajo se basará en la creación de equipos de trabajo, en el que
participarán consultores funcionales, así como usuarios clave de la administración,
cuyo objetivo es realizar las tareas de planificación y ejecución de cada una de las
fases del proyecto descritas en este documento, así como informar al comité de
seguimiento del avance del proyecto.
Marco Metodológico.
Obligatoriamente se seguirán las directrices metodológicas de la APA en cuanto a
protocolos de actuación, guías, métodos y procedimientos, no admitiéndose el uso
de otras metodologías que tengan la misma finalidad que las mencionadas en el
presente pliego. En general se observará, en su última versión:
 Metodología de gestión de proyectos.
La planificación, ejecución, seguimiento y control del proyecto se ajustará a la

Metodología de Gestión de Proyectos Informáticos del Principado de Asturias
MEGEPA 2007.
 Metodología de sistemas.
En las partes del proyecto que requieran la participación del servicio de

infraestructuras, se deberá seguir la Metodología de Sistemas del Principado de
Asturias, MESISPA.
 Pruebas y operación
Se seguirán las directrices metodológicas marcadas por la Dirección General de

Seguridad y Estrategia Digital en cuanto a las pruebas de aceptación de los
productos entregados.

SSCC-SESPA
Los planes de pruebas seguirán la Metodología de Pruebas de Sistemas de

Información (METESPA) de la Dirección General de Seguridad y Estrategia
Digital.
Los parámetros a medir en las pruebas de las funcionalidades que son objetos de
este contrato, como entre otros el rendimiento de la aplicación aceptable serán al
menos los proporcionados por la aplicación en el momento de inicio del contrato.
De igual forma se seguirán las especificaciones vigentes en la APA para

los documentos de operación y explotación recogidas en las especificaciones
particulares para el desarrollo de sistemas de información en el Principado de
Asturias y documentación sobre el Sistema de Gestión de Calidad del CGSI.
En estos ámbitos la APA sigue las directrices de la Guía de Buenas Prácticas
“ITIL”.
.
La documentación generada durante la ejecución del contrato será de propiedad
exclusiva del SESPA, sin que el contratista pueda conservarla, ni obtener copia de la
misma o facilitarla a terceros sin la expresa autorización del SESPA, que la daría en
su caso previa petición formal del contratista con expresión del fin.
Así mismo, la documentación generada deberá de estar en castellano, incluidos los
manuales de usuario. Solamente se permiten manuales en inglés para documentos
técnicos del producto que no sean de uso para los técnicos del Principado de
Asturias.
Se identifican al menos los siguientes documentos:
 Documento de Arquitectura del Sistema (DDA).
 Manual de Instalación y Operación (MIO).
 Manual de usuario (MDU).
 Manual de administrador del sistema.
 Documentación técnica de la interfaz de integración.
Incidencias y cambios.
El registro y seguimiento de incidencias y cambios se realiza siguiendo la
metodología ITIL y está basado en el uso de la herramienta Remedy cuyo uso es
obligatorio en este proyecto. Las licencias necesarias para su uso por parte del
adjudicatario se consideran incluidas en la oferta.
La documentación sobre metodologías, calidad u otra documentación que se cita
expresamente en este pliego puede entregarse al licitador bajo demanda.

SSCC-SESPA
11 SEGUIMIENTO Y CONTROL
La Subdirección de Infraestructuras y Servicios Técnicos del SESPA, o, en su caso,
el órgano directivo del SESPA responsable de la gestión de las Infraestructuras
Tecnológicas y Servicios Técnicos, realizará el seguimiento y control de las
actividades descritas en éste pliego nombrando al responsable del contrato.
Con objeto de realizar un seguimiento continuo de la situación de los servicios,
existirá un Comité de Seguimiento del que formará parte una persona que asuma la
Jefatura del Proyecto, designada por la empresa adjudicataria y la persona
responsable del contrato o la/as personas en que delegue. La persona que ostente
la responsabilidad de la Jefatura del Proyecto por la empresa adjudicataria, será la
persona responsable de las actividades desarrolladas en el marco de este contrato.
12 ACCESO REMOTO A LOS SISTEMAS

DE EXPLOTACIÓN
En el caso de necesidad de acceso remoto a los sistemas con el fin de garantizar la
resolución de incidencias de la forma más efectiva posible, éstos serán autorizados,
tutelados y llevados a cabo según las directrices que la Subdirección de
Infraestructuras y Servicios Técnicos determine en cada momento.
13 TRANSFERENCIA TECNOLÓGICA
Durante la ejecución de los trabajos objeto del contrato el adjudicatario se
compromete, en todo momento, a facilitar a las personas designadas por la
Administración del Principado de Asturias, la información y documentación que éstas
soliciten para disponer de un pleno conocimiento de las circunstancias en que se
desarrollan los trabajos, así como de los eventuales problemas que puedan
plantearse y de las tecnologías, métodos, y herramientas utilizadas para resolverlos.
Dentro del alcance de los servicios incluidos en el contrato, el adjudicatario
proporcionará a lo largo de los últimos 6 meses de ejecución todos los recursos y
servicios necesarios para su transferencia a la Administración del Principado de
Asturias o al nuevo proveedor adjudicado por ésta para la continuación de los
servicios de soporte técnico y funcional.

SSCC-SESPA
14 GARANTÍA
El adjudicatario garantizará, al menos por un periodo de dos años, los productos
derivados del servicio objeto del contrato, a contar desde la fecha de recepción de
los mismos, obligándose a realizar durante dicho periodo los cambios necesarios
para solventar las deficiencias detectadas imputables a la firma adjudicataria si así lo
solicita la Administración del Principado de Asturias.
Dicha garantía incluirá la subsanación de errores o fallos ocultos que se pongan de
manifiesto en el funcionamiento de los productos entregados, o que se descubran
mediante pruebas o por cualquier otro medio, así como la conclusión de la
documentación incompleta y subsanación de la que contenga deficiencias. Los
productos originados como consecuencia de la subsanación de defectos deberán
entregarse de conformidad con lo exigido en el Pliego
Al finalizar la garantía, el producto ha de encontrarse actualizado a su última versión

disponible.

SSCC-SESPA
15 ANEXO I: MODELO DE
AUTENTICACIÓN Y AUTORIZACION DE
APLICACIONES FRENTE AL LDAP
CORPORATIVO DEL SERVICIO DE
SALUD DEL PRINCIPADO DE ASTURIAS
Introducción
A partir de la puesta en marcha del proyecto de Gestión de Identidad (GID), el
Servicio de Salud del Principado de Asturias (SESPA) dispone de un repositorio
centralizado de cuentas de usuario, basado en LDAP. Ese repositorio centralizado,
permite que los usuarios de aplicaciones de los sistemas de información del SESPA
tengan un solo login/passwd para todas las aplicaciones integradas con dicho
repositorio. Por esa razón, las aplicaciones de nueva implantación deben ser
capaces de autenticar a sus usuarios con el LDAP corporativo y, en la medida de lo
posible, delegar también la autorización utilizando el modelo RBAC (Role-Based
Acces Control), es decir, modelo de acceso basado en roles.
Conceptos básicos.
Se exponen a continuación dos conceptos básicos que se usaran a lo largo del
documento:
Autenticación. La autenticación del usuario es el proceso por el cual se valida un
usuario (en la mayoría de los casos con login/password). Que un usuario este
autenticado NO implica necesariamente acceso a ninguna aplicación/servicio, lo
único que indica es que el usuario ha facilitado correctamente sus credenciales.
Para acceder a algún servicio, debe estar autorizado en ese servicio.
Autorización. Una vez que el usuario esta autenticado, debe comprobarse sus
permisos, tanto de acceso a aplicaciones, como de acciones que está autorizado a
realizar en las diferentes aplicaciones. Ese proceso de comprobación es lo que se
denomina autorización.
Modelo de autenticación.
Todas las aplicaciones deben utilizar el directorio corporativo para validar a sus
usuarios. Las razones para hacerlo son las siguientes:
- Necesidad de mantener una única cuenta de usuario (login) a lo largo de
todas las aplicaciones de la organización.

SSCC-SESPA
- Necesidad de mantener la contraseña sincronizada en todas las aplicaciones.

Lo que impide que las aplicaciones gestionen sus propias contraseñas.
- Bloqueo automático de cuenta cuando el usuario cese en su relación
contractual con la organización.
Para utilizar el directorio corporativo en la autenticación de usuarios, es necesario

que la aplicación sea capaz de utilizar el protocolo LDAP.
La autenticación del usuario se realizara haciendo una operación bind en la rama
adecuada del directorio corporativo. La rama a la que pertenecen los usuarios es:
“ou=personales,ou=usuarios,o=sespa” y el DN sobre el que hay que hacer bind
será “uid=<LOGIN_USUARIO>,ou=personales,ou=usuarios,o=sespa”.
Si el usuario supera el proceso de autenticación se pasara a validar sus

autorizaciones según el modelo de autorización indicado a continuación.
Las direcciones IP y puertos de acceso al LDAP se facilitaran en fase de
implantación.
Modelo de autorización.
El modelo de autorización implementado está basado en pertenencia a grupos
(modelo RBAC), es decir, un usuario estará autorizado a hacer algo, en función de
que pertenezca o no a un determinado grupo. Bajo este punto de vista, lo datos en
los que se basará la autorización de las aplicaciones residirán en el directorio
corporativo y el “calculo” de lo que una persona puede hacer o no en función de esa
pertenencia queda delegado en las aplicaciones.
Para cada aplicación cuyos usuarios estén gestionados por la GID existirá unidad
organizativa bajo la rama “ou=servicios, o=sespa”, por debajo de la cual, estarán
todos los grupos que la aplicación necesite o vaya a usar. La inclusión de un usuario
en uno u otro grupo debe hacerse desde el sistema de gestión de identidad.
De esta forma, para que un usuario este autorizado a tener determinado rol en una
aplicación, es necesario que:
- El usuario tenga cuenta activa en el directorio corporativo.
- Exista la rama “ou=<ID_APLICACION>,ou=servicios,o=sespa”.
- Exista un grupo bajo la rama “ou=<ID_APLICACION>, ou=servicios,
o=sespa”, por cada perfil de acceso diferente a la aplicación.
- El usuario pertenezca a alguno de los grupos indicados en el punto
anterior, es decir, tendrá un atributo isMemberOf con valor

SSCC-SESPA
“cn=<NOMBRE_GRUPO>, ou=<ID_APLICACION>, ou=aplicación,

ou=servicios, o=sespa”.
- Un usuario podrá pertenecer a todos los grupos necesarios para que su
perfil efectivo de acceso a la aplicación sea el adecuado.
Consideraciones.
La puesta en marcha de nuevas aplicaciones, deberá tener en cuenta las siguientes
consideraciones:
- Las aplicaciones no gestionarán usuarios, utilizaran el LDAP corporativo
como repositorio de cuentas de usuario.
- Las aplicaciones no podrán cambiar la contraseña de los usuarios. El
cambio de contraseña debe hacerse a través de la página
https://miclave.sespa.pa.
- La autorización debe estar basada en pertenencia a grupos.
- La creación de la rama de la aplicación y su identificador es una tarea que
recae sobre el Servicio de Salud.
- La responsabilidad sobre la administración de los grupos de usuarios recae
en el Servicio de Salud, bajo petición de los responsables de la aplicación.
- La responsabilidad de la asociación de los usuarios con sus grupos, recae en
el servicio de Salud del Principado de Asturias, bajo petición de los
responsables de la aplicación. Puede hacerse de forma automática a través
de la gestión de roles de la GID o de forma manual.
- La asociación de perfiles/grupos a determinadas funcionalidades de la
aplicación es responsabilidad de la aplicación.
- Se dispone de una librería java a disposición de los proveedores de
aplicaciones desarrolladas con este lenguaje que incluye la funcionalidad
necesaria para la autenticación y autorización en el LDAP corporativo.
Cuestionario Orientativo
A continuación, se detalla un pequeño cuestionario que, a simple vista, permite
conocer si una aplicación es susceptible de integrar completamente con el modelo
de autenticación y autorización definido.
Aplicación Si/No
¿Puede autenticar haciendo LDAP bind para cuentas del tipo

uid=<usuario>, ou=personales, ou=usuarios, o=sespa?

SSCC-SESPA
¿Puede leer el atributo isMemberOf de la clase inetOrgPerson de

LDAP?
¿Puede mapear una entrada en el atributo isMemberOf a un perfil de

acceso en la aplicación?
¿Es suficiente con los datos de inetOrgPerson para que un usuario

tenga acceso a la aplicación?
Si la respuesta es positiva en todos los casos, inicialmente es factible su integración.

En caso de que alguna sea negativa, se requiere un estudio detallado del caso.
LOPEZ MINGUEZ Firmado digitalmente por

LOPEZ MINGUEZ YOLANDA
YOLANDA - DNI - DNI 09425441H
Fecha: 2023.03.23 00:25:20
09425441H +01'00'

DOC20230727083813Pliego de Prescripciones Tecnicas

Cargado por

Información del documento

Título original

Derechos de autor

Formatos disponibles

Compartir este documento

Compartir o incrustar documentos

Opciones para compartir

¿Le pareció útil este documento?

¿Este contenido es inapropiado?

Copyright:

Formatos disponibles

DOC20230727083813Pliego de Prescripciones Tecnicas

Cargado por

Copyright:

Formatos disponibles

EXPEDIENTE: CONP/2022/3290

PLIEGO DE PRESCRIPCIONES TÉCNICAS PARA LA CONTRATACIÓN DEL

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

4.7 Integración de Sistemas................................................................................................43

Estado Original Página Página 2 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

Sin embargo la integración de datos entre los sistemas de departamentales y los

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

de información adicional que no suben a la HRS o la departamental tiene poca

 Mejorar la gestión de los cuidados aplicando los mejores protocolos para

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

 Acelerar la investigación biomédica.

El primero de los repositorios centralizará la información para su uso primario, es

El segundo de los repositorios estará orientado a la explotación masiva de datos,

Se consolidará directa o indirectamente, los datos e información de los diferentes

Estado Original Página Página 5 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

Será capaz de gestionar diferentes tipos de información y formatos, para 2 tipos de

 Uso primario de la información de Salud: cuando los datos de salud se utilizan

 Uso secundario de los datos de Salud: es el uso de datos de salud agregados

La información será coordinada adecuadamente entre las diferentes capas que

Debe responder a las necesidades derivadas del uso primario y secundario de la

El alcance de la contratación abarca:

 Suministro e implantación de un REPOSITORIO DE DATOS DE SALUD

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

terminologías clínicas que sean necesarias para la integración de los datos y

 Suministro e implantación de un REPOSITORIO DE DATOS

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

 Puesta en producción de herramientas y modelos analíticos desarrollados

Estado Original Página Página 8 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

necesidades del SESPA respecto al uso y explotación de los sistemas

Estado Original Página Página 9 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

Estado Original Página Página 10 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

4 PRESCRIPCIONES TÉCNICAS DEL

4.1 Estructura general del Sistema. Proyecto

Como filosofía de la arquitectura de los nuevos Sistemas informáticos a implantar en

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

4.2 Fuentes de información principales

 SIPRES. Sistema de Información Poblacional

 Sistemas de Información Hospitalaria (HIS)

Estado Original Página Página 12 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

3. Integrado principalmente con

 Sistemas de Información en Atención Primaria (PHS)

Estado Original Página Página 13 de 79

Código Seguro de Verificación (CSV) 14156533646256034553

Dirección electrónica de validación del CSV https://consultaCVS.asturias.es/

- Sistemas de Gestión de Laboratorios (dependientes de la