adquisición e implantación de un sistema de información ... · completar el historial...

/75

Adquisición e Implantación de un

Sistema de información para el proceso

farmacoterapéutico del paciente oncológico

en Osakidetza

/75

Índice Página

1 INTRODUCCIÓN ............................................................................................................... 4

2 SITUACION ACTUAL ........................................................................................................ 5

3 OBJETO DEL CONTRATO ............................................................................................... 7

4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN ....................................................... 9

4.1 Modulo Corporativo .................................................................................................. 9

4.2 Modulo Centro ......................................................................................................... 11

4.3 Módulo Prescripción ................................................................................................ 12

4.4 Módulo Administración .......................................................................................... 15

4.5 Módulo de Informes y Explotaciones ..................................................................... 15

4.6 Trazabilidad ............................................................................................................. 16

5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN ............................................................. 17

5.1 Alcance técnico de la solución ................................................................................. 17

5.2 Entornos .................................................................................................................... 18

6 LÍNEAS DE TRABAJO .................................................................................................... 19

6.1 Consultoría ............................................................................................................... 19

6.2 Accesibilidad a la información histórica ................................................................ 19

6.3 Integración con los S.I. Corporativos ..................................................................... 19

6.4 Formación ................................................................................................................. 22

6.5 Implantación ............................................................................................................ 23

7 MANTENIMIENTO POST-IMPLANTACIÓN ............................................................... 24

7.1 Mantenimiento integral ........................................................................................... 24

7.2 Soporte de hot-line ................................................................................................... 24

8 PRODUCTOS A OBTENER ............................................................................................. 26

9 PLANIFICACIÓN DEL PROYECTO.............................................................................. 27

10 EQUIPO DE TRABAJO ................................................................................................... 28

11 CONTENIDO DE LAS OFERTAS .................................................................................. 29

12 PROPIEDAD DE LOS PRODUCTOS ............................................................................. 31

13 CONFIDENCIALIDAD .................................................................................................... 32

14 PRESUPUESTO, PLAZOS Y FORMA DE PAGO ......................................................... 33

14.1 Presupuesto .............................................................................................................. 33

14.2 Plazos ........................................................................................................................ 33

14.3 Forma de pago .......................................................................................................... 33

15 CRITERIOS DE ADJUDICACIÓN ................................................................................. 34

16 CONSULTAS AL PLIEGO ............................................................................................... 36

17 ANEXO I: DIRECTRICES Y ESPECIFICACIONES TÉCNICAS (DET).................... 37

17.1 Especificaciones para Desarrollo ............................................................................ 37

/75

17.2 Arquitectura de Referencia ..................................................................................... 37

17.3 Directrices de Desarrollo ......................................................................................... 39

17.4 Directrices tecnológicas de IOC .............................................................................. 43

17.5 Interoperabilidad ..................................................................................................... 49

17.6 Explotación Información- Business Intelligence ................................................... 53

17.7 Alineamiento con las Directrices Tecnológicas ..................................................... 53

18 ANEXO II: CUESTIONARIO DE ESPECIFICACIONES TÉCNICAS (CET) ............ 54

18.1 Arquitectura y Tecnología ...................................................................................... 54

18.2 Capa de Presentación .............................................................................................. 57

18.3 Capa de Negocio ....................................................................................................... 59

18.4 Capa de Persistencia ................................................................................................ 61

18.5 Elementos de Interfaz de usuario ........................................................................... 62

18.6 Seguridad, acceso, autenticación y autorización ................................................... 63

18.7 Interoperabilidad ..................................................................................................... 65

18.8 Mantenimiento y Operación ................................................................................... 66

18.9 Directrices de Desarrollo ......................................................................................... 70

18.10 Diagrama de Arquitectura ...................................................................................... 74

19 ANEXO III: ESPECIFICACIONES DEL CLIENTE (MAQUETA) . ............................ 75

/75

1 INTRODUCCIÓN Osakidetza precisa de un sistema de información que dé una solución corporativa e integrada a la gestión de la medicación para la oncología, en todos los centros hospitalarios de Osakidetza . El nuevo sistema de información debe contemplar todo el proceso asistencial ligado a la medicación oncológica, desde el diagnóstico hasta la administración del tratamiento, incluyendo desde la definición de los esquemas o protocolos terapéuticos, hasta su posterior validación, preparación y dispensación, así como también la administración. Se incluirá también dentro de este expediente la explotación de los resultados del ciclo completo. Es por ello que el presente expediente propone la adquisición e implantación, de un software especializado que permita, tanto una gestión adecuada del proceso oncológico completo, como una correcta explotación de sus resultados, en un entorno corporativo e integrado con el sistema Osabide (Historia Clínica de Osakidetza ). Actualmente, Osakidetza realiza atención al paciente oncohematológico, principalmente en los siguientes centros:

• Hospital Universitario Donostia (HUD) • Hospital Universitario Araba. Hospital de Txagorritxu (HTX) • Hospital Universitario Cruces (HUC) • Hospital de Galdakao-Usansolo (HGU) • Hospital Universitario Basurto (HUB)

Aunque el alcance de este expediente incluye el despliegue del producto ofertado exclusivamente en los centros detallados anteriormente, se prevé una futura expansión del producto al resto de hospitales de la red, que a una menor escala, realizan atención a este tipo de paciente.

/75

2 SITUACION ACTUAL En la actualidad cada centro dispone de una solución propia y no corporativa para gestión de la medicación oncológica. Estas soluciones cuentan con un grado de automatización y grado de madurez diferentes, pero todas ellas con escasa integración con el HIS hospitalario y la Historia Clínica Electrónica (HCE) del paciente. A modo orientativo se hace un breve resumen de la solución implantada en cada centro y su actividad:

• Hospital Universitario Donostia: • Solución basada en un desarrollo propio del centro. • Nº de servicios y profesionales que prescriben tratamientos:

o Oncología médica: 19 profesionales o Hematología: 29 profesionales o Pediatría: 3 profesionales o Urología: 3 profesionales

• Número estimado de preparaciones (mezclas)/año en el Servicio de Farmacia: 45.000 (datos 2015).

• Hospital Universitario Araba. Hospital de Txagorrit xu:

• La aplicación informática para la prescripción y gestión del tratamiento oncológico que usa el centro es Farmis_Oncofarm.

• Nº de servicios y profesionales que prescriben tratamientos: o Oncología Médica: 13 profesionales o Hematología: 9 profesionales

• Número estimado de preparaciones (mezclas)/ año que se realizan en el Servicio de Farmacia para estos pacientes: 18.300 mezclas para tratamientos oncohematológicos (datos 2015).

• Hospital Universitario Cruces

• La aplicación informática para la prescripción y gestión del tratamiento oncológico que usa el centro es Oncowin.

• Número de servicios y de profesionales médicos: o Oncología Médica: 16 prescriptores o Oncohematología: 7 prescriptores o Pediatría: 4 prescriptores o Urología: 1 prescriptor

* Existen otros servicios que se hacen cargo de pacientes oncológicos pero sus prescripciones son solamente orales (unos 10 profesionales de diferentes servicios).

• Número estimado de preparaciones (mezclas)/ año que se realizan en el Servicio de Farmacia (se realiza en 2 entornos):

o Servicio de Farmacia: 17.120 Mezclas o Hospital de Día Oncológica: 30.000 Mezclas

• Hospital de Galdakao-Usansolo: • La aplicación informática para la prescripción y gestión del tratamiento

oncológico que usa el centro es Farmis_Oncofarm. • Número de servicios y de profesionales médicos en cada uno de ellos que

realizan prescripción a pacientes oncológicos: o Oncología médica: 6 prescriptores o Ginecología: 3 prescriptores

/75

o Hematología: 11 prescriptores o Urología: 6 prescriptores

� Número estimado de preparaciones (mezclas)/año que se realizan en el Servicio de Farmacia para estos pacientes: 19.000 mezclas para tratamientos oncohematológicos (datos 2015).

• Hospital Universitario Basurto:

• La aplicación informática para la prescripción y gestión del tratamiento oncológico que usa el centro es Farmis_Oncofarm.

• Número de servicios y de profesionales médicos en cada uno de ellos que realizan prescripción a pacientes oncológicos: o Oncología médica: 12 prescriptores o Hematología: 13 prescriptores o Radioterapia: 3 o Urología: 3 prescriptores o Reumatología:2 o Neurología:1 o Nefrología:1

� Número estimado de preparaciones (mezclas) por año que se realizan en el Servicio de Farmacia para estos pacientes: 18.719 mezclas para tratamientos oncohematológicos (datos 2015).

Aunque las aplicaciones detalladas anteriormente aportan una solución al proceso de la medicación oncológica, la información registrada queda en la correspondiente aplicación sin ser accesible desde las soluciones corporativas de Osakidetza, quedando de esta forma, la Historia Clínica y el Historial Farmacoterapéutico (HF) del Paciente de Osakidetza incompletos.

/75

3 OBJETO DEL CONTRATO El objeto de este expediente es la adquisición e implantación de una solución software que cubra el circuito completo de prescripción en el paciente oncológico (prescripción, validación, preparación y administración) de Osakidetza y el desarrollo de las integraciones requeridas. El objeto del contrato incluye:

• Software comercial para la gestión de la medicación oncológica . Este software tendrá una estructura multicentro, que incluirá:

o módulo corporativo (único), donde entre otras funcionalidades, la Comisión Corporativa de Osakidetza , creará y mantendrá los protocolos de medicación.

o módulo propio de cada centro / farmacia , donde partiendo de los protocolos corporativos y configuraciones propias del centro, se realizará el circuito completo oncológico (prescripción, validación, preparación y administración).

El producto ofertado por los licitadores, deberá suministrarse en régimen de licenciamiento corporativo (número ilimitado de usuarios y centros). La solución propuesta deberá ser Multiidioma , garantizado la operativa en euskera y castellano.

• Integración de los productos ofertados con el resto de sistemas de información corporativos de Osakidetza.

• Implantación de la solución. Incluyendo el análisis previo en cada centro, las adaptaciones requeridas si fueran necesarias, el despliegue de la solución con soporte local on site, y la formación al personal sanitario, administrativo e informático.

Asimismo, señalar que los trabajos de implantación, integración o migración de datos, no suponen en ningún caso servicios añadidos, sino que resultan imprescindibles para la puesta en marcha del software objeto del contrato. El precio de las licencias ofertadas incluirá la garantía durante toda la vigencia del contrato. Será obligación del contratista durante este período:

• Poner a disposición de Osakidetza y autorizar el uso de la última versión o actualización disponible en el mercado de todos los productos relacionados en el objeto del presente pliego

• Entregar a Osakidetza todas las versiones mayores de productos y tecnología, que incluyen versiones generales de mantenimiento, versiones de funcionalidad seleccionada y actualizaciones de documentación

• Dar acceso a la base de conocimiento y soporte Web (sistemas de soporte al cliente basados en la web), incluida la posibilidad de registrar peticiones de servicio en línea.

• Servicio telefónico y local de soporte, para la resolución de incidencias y peticiones de servicio.

/75

Los entornos a utilizar en el proyecto y cuyas licencias deberán ser suministradas, serán los siguientes:

• Entorno de Pre-producción • Entorno de Producción

Toda la plataforma hardware y software de base (sistema operativo) requeridos para la implantación del nuevo producto, así como los servicios de administración, monitorización, y operación de la misma, serán suministrados por la Subdirección de Informática y Sistemas de Información de la Organización Central de Osakidetza , no estando incluidos en el objeto de este contrato. La solución ofertada deberá ser multiplataforma (hardware y sistema operativo), pudiendo implantarse, bajo los estándares de Osakidetza que se detallan en Anexo I. Las estaciones de trabajo (PCs) y su software de base, serán los existentes en los hospitales de Osakidetza , por lo que quedan también, fuera del alcance de este contrato, siendo necesario que el producto ofertado se ajuste a la maqueta de Osakidetza que se detalla en el Anexo III.

/75

4 REQUISITOS FUNCIONALES DE LA SOLUCIÓN El sistema de información para la gestión de la medicación oncológica, es considerado como una herramienta de trabajo imprescindible para mejorar la calidad asistencial, completar el Historial Farmacoterapéutico del paciente, incrementar la productividad y minimizar errores en todo el proceso oncológico. Dentro del enfoque en el uso de las nuevas tecnologías, Osakidetza pretende incorporar un sistema de información, integral e integrado con el resto SI corporativos, que dé servicio o todos los centros con atención al paciente oncohematológico. La solución debe ser una herramienta segura y eficaz que cubra el circuito completo de prescripción en el paciente oncológico. Por tanto, debe integrar la prescripción electrónica por parte del médico, las herramientas para el farmacéutico que permitan su validación, cálculos, elaboración y dispensación de los medicamentos, y para enfermería el control y registro de la administración. Adicionalmente, el proyecto supondrá la incorporación de cambios organizativos, tecnológicos y de procesos, que permitan mejorar la organización y la calidad, así como la seguridad y el cuidado integral en el proceso. Además debe garantizar su integración en la historia clínica del paciente, así como facilitar el seguimiento y análisis de los datos de actividad. Toda esta funcionalidad debe contar con una trazabilidad completa durante todo el proceso . La solución debe estar basada en un concepto corporativo y multicéntrico , que partiendo de un módulo común para la configuración general y definición de los de protocolos, y una configuración propia del centro, dé servicio a todos los servicios de oncología y hematología de Osakidetza A continuación se detallan los principales requisitos funcionales:

4.1 Modulo Corporativo La solución ofertada debe contemplar un módulo corporativo, único, que permita a la comisión competente de Osakidetza la posibilidad de integrar las directrices y procedimientos de forma consensuada, para garantizar la eficacia y la seguridad en el uso de protocolos de medicación.

4.1.1 Gestión de Pacientes Toda la gestión de Pacientes se establecerá a través de servicios de integración con la BBDD Corporativa de Pacientes de Osakidetza . Se deberán incluir mínimamente las siguientes operaciones, junto con sus servicios de integración:

• Alta, Baja. Modificación de Pacientes • Fusión de Pacientes • Búsqueda de Pacientes por múltiples criterios

El sistema propuesto ofertará una ficha completa con los datos del paciente, que incluirá al menos la siguiente información:

/75

• Datos de filiación del paciente • Datos antropométricos y alergias • Incorporación de datos de admisión: Organización de servicios, centro,

fecha ingreso, área sanitaria, servicio responsable, episodio de ingreso, ubicación (con posibilidad de cambio manual), etc.

• Distintos datos clínicos: o Orientación diagnóstica o Función hepática o Función renal o Otros datos de Laboratorios (Hematología, Bioquímica,

Microbiología, Inmunología) o Asignación automática grado toxicidad según parámetros

predeterminados. o Comorbilidad asociada (llamada a calculadoras, registro de índices,

etc.)

4.1.2 Gestión Seguridad y Accesos La autenticación en el sistema se realizará vía integración con el Directorio Activo de Osakidetza . El sistema ofertado permitirá la gestión de roles de usuarios y la trazabilidad de la actividad realizada por éstos. Los datos básicos de los Profesionales se establecerán a través de servicios de integración con la BBDD Corporativa de Profesionales de Osakidetza .

4.1.3 Catálogos Corporativos El sistema propuesto ofertará una gestión corporativa y única de los principales catálogos (centros, servicios médicos, vademécum medicamentos, protocolos, etc.). Posteriormente, desde el módulo de centro, existirá la posibilidad de configuración de ciertos atributos de estos catálogos, a nivel de centro. Se deberán detallar los mecanismos que garanticen la gestión, mantenimiento e integridad de estos catálogos. Todos los datos relacionados con la estructura organizativa de Osakidetza (centros, servicios, secciones, profesionales, etc.), serán suministrados por el sistema de gestión corporativo de Osakidetza , siendo necesaria su integración y sincronización.

4.1.4 Caracterización del Medicamentos, Mezclas y P rotocolos El sistema propuesto ofertará una gestión para la caracterización de los productos farmacéuticos, mezclas y protocolos que participen el en proceso oncológico. Esta caracterización deberá ser lo más detallada posible ya que deberá cubrir todas las posibilidades de prescripción descritas en el punto 4.3 Modulo de prescripción y de los sistemas de validación y de generación de alertas. A su vez, esta caracterización deberá permitir:

• Incorporar decisiones de la Comisión Corporativa de Farmacia sobre posicionamientos, o referencias a determinados documentos (por ejemplo solicitud de un fuera de indicación, etc.)

• Enlaces formularios u otros documentos externos (de Osabide-Global pe.)

/75

• Posibilidad de que las especificaciones definidas en la ficha del medicamento puedan figurar según cada hospital en la Hoja de elaboración, Etiquetas o Hoja administración

Los datos básicos de los medicamentes se establecerán a través de servicios de integración con la BBDD del Vademécum Corporativa de Osakidetza .

4.2 Modulo Centro La solución ofertará un módulo particular para cada una de las los 5 centros objetos del expediente:


El sistema permitirá la parametrización de una serie de información referente a las particularidades y características del centro. Será la farmacia del centro quién realice esta labor.

4.2.1 Configuraciones generales El sistema permitirá la siguiente configuración:

• Gestión de permisos de usuarios del centro. • Posibilidad de parametrizar características organizativas del centro:

preparación en cabina mediante aplicación o mediante hojas de preparación; configuración de etiquetas; uso de control mediante gravimetría, etc...

• Configuración de la parte administrativa (agendas, calendario laboral, etc.). • Centros de coste / imputación asociados a los servicios de prescripción.

4.2.2 Caracterización del Medicamento Cada centro podrá indicar valores propios en la ficha de medicación asociada al centro.

4.2.3 Asociación de Medicación y Protocolos al cent ro El sistema permitirá asociar al centro un subconjunto de la medicación y de los protocolos del catálogo corporativo. Permitirá, además, completar estos protocolos con la medicación de soporte específica del centro. Únicamente será posible prescribir en el centro, el subconjunto de medicación y protocolos previamente asociados el centro.

4.2.4 Módulo de Validación Farmacéutica • Posibilidad de validación electrónica de la orden médica. • Validación automatizada y asistida con control de las variables:

esquema/diagnóstico, ciclo/día, periodicidad, dosis.

/75

• Confirmación en bloque, o no, todos los días de un ciclo, o un nº de ciclos determinado, en función de la prescripción.

• Seguimiento cumplimiento protocolos. • Identificación de fármacos centinelas. • Señal de aviso de confirmación de ciclo por el médico (pendiente de validar por

el farmacéutico). Señal unida al cambio de estado de la orden.

4.2.5 Módulo para la elaboración El producto ofertado permitirá disponer de diferentes soluciones para garantizar una correcta elaboración independientemente del grado de automatización de la farmacia (hojas de elaboración impresas, pantallas táctiles integradas en campana de elaboración, integración de dispositivos de comprobación de gravimetría, etc.) Se deberán incluir al menos las siguientes funcionalidades:

• Edición de las hojas de preparación. • Incorporar códigos de barras, QR, DataMatrix, o similar, para garantizar:

o Seguridad en la identificación de los productos (registro aprovechamientos de viales).

o Trazabilidad de lote y caducidad (si el origen es reciclado también) o Correlación de efectos adversos posibles, causalidad o Nombre y firma del personal técnico que prepara la dosificación.

Cálculo de horas acumuladas de trabajo. o Controles de calidad (microbiológico, pesada)

• Registro de horario de emisión de hoja de preparación. • Registro de la persona que imprime el material de trabajo. • Edición de etiquetas de cada paciente, incluyendo códigos de barras, QR,

DataMatrix, o similar, para identificación de cada preparación. • Permitir contabilizar diariamente las dosis utilizadas de fármacos, y permitir

aprovechar los viales al máximo. • Registro de tiempos de demora en la programación/preparación de

dosificaciones. • Reutilización de viales multidosis. • Control de Calidad:

o Posibilidad de Control gravimétrico de los preparados para que cumplan las condiciones de conservación en los casos que especialmente se requieran.

o Control seguro del envío del tratamiento al Hospital. • Alternativas para el proceso de Producción en Cabina.

4.3 Módulo Prescripción El sistema propuesto ofertará un módulo común para la prescripción clínica. Esta prescripción estará basada en un sistema de soporte a la decisión clínica y orientará la prescripción a los esquemas terapéuticos asociados al centro (sobre los mantenidos y actualizados por la Comisión Corporativa). Al igual que el resto de aplicaciones corporativas, el acceso al tratamiento del paciente debe ser posible desde cualquier centro de Osakidetza , con independencia del centro donde haya sido prescrito el paciente.

/75

El módulo de prescripción deberá ser ofertado como solución web, para ser accesible desde la estación clínica corporativa , Osabide-Global. Se deberán incluir al menos las siguientes funcionalidades:

4.3.1 Opciones de Prescripción • Permitirá crear un perfil de prescripción favorito dependiendo de la especialidad

médica y/o de cada médico. • Establecer niveles de acceso a los medicamentos y protocolos (medicamento

restringido a un servicio, a una indicación clínica, a una condición clínica, etc.) • Sistemas de alertas y de soporte a la decisión clínica que guíen del proceso a

los usuarios avisando de interacciones, contraindicaciones, toxicidades, dosis máximas y acumulativas, ajustes de dosis.

• Selección medicamentos por Nombre comercial /Principio Activo • Selección y volcado de protocolos de quimioterapia:

o Protocolo aprobado. o Protocolo de investigación y ensayos clínicos. o Protocolo medicamento en Uso compasivo. o Línea de tratamiento por cada uno de los citostáticos que componen el

esquema. o Secuencia de administración. Observaciones referentes a la

peculiaridad de su orden. o Alerta de diagnóstico distinto al asignado inicialmente al paciente. o Observaciones fijas asociadas al protocolo.

• Flexibilidad para modificar el protocolo: o Dosis. Ajuste de dosis por porcentaje o por dosis, apoyo de tablas por

protocolo. o Fechas previstas. o Suspender/posponer esquema (en bloque o por componente).

• Acceso a bases de datos externas de medicamentos. • Informar de criterios especiales de prescripción: Extranjeros, Uso Compasivo,

Ensayo Clínico (asociados a la información de restricciones y posicionamientos definidos)

• Prescripción concomitante de esquemas de soporte. • Intención de uso de protocolo de quimioterapia: adyuvancia, neoadyuvancia,

enfermedad metastásica (inducción, consolidación, mantenimiento, recaída, refractariedad)

• Integración y visualización de la historia terapéutica completa (nutrición parenteral, medicamento en ensayo clínico, fórmula magistral, mezclas intravenosas...) en la prescripción del paciente.

• Confirmación de la asistencia del paciente. • Confirmación en bloque, o no todos los días de un ciclo o un nº de ciclos

determinados. • Integración con los cuidados de enfermería. • Textos predefinidos y volcado de cuidados de enfermería • Feedback de la información. Posibilidad de campo libre de texto para

comunicación bidireccional médico-farmacéutico o farmacéutico-farmacéutico • Campo de requisitos para la próxima consulta (pruebas, marcadores, analítica,

etc. • Prioridad de la validación.

4.3.2 Opciones Prescripción (pauta) • Posibilidad de dosificación para citostáticos, fluido y aditivos, por:

/75

o Kg/peso o Superficie corporal o Peso ideal o Peso ideal ajustado o Por edad o AUC o Dosis fija

• Para cada citostático: o Dosis (redondeo a nº entero o a un solo decimal), por principio activo y

a voluntad del validador (y los orales redondearlos a las presentaciones orales disponibles)

� Dosis diaria � Dosis máxima � Dosis máxima por ciclo

o Vía de administración o Vehículo o Volumen o Modo administración o Velocidad de infusión (V/t, gts/t) o Duración infusión o Dispositivo

• Información sobre Ciclos: o Nº ciclos o Nº máximo ciclos o Periodicidad ciclos o Especificar días administración o Horas de administración si procede

• Estado de la orden (“en espera”, “confirmada”, etc.) • Cálculo de Porcentaje de reducción fármaco (por toxicidad) o aumento de dosis • Registro motivo de modificación de dosis • Cálculo de volumen total de fluidos a administrar • Fecha próximo esquema/consulta • Campo libre observaciones generales para instrucciones varias

4.3.3 Prescripción (pediatría) La prescripción debe estar adaptada para cubrir las particularidades y necesidades específicas de la población pediátrica:

• Dosificación tanto en superficie corporal (m2), como en Kg de peso. • Cálculo automático en función de la edad del paciente. Es deseable que el

sistema, según la edad del paciente, calcule la dosis en función del peso o superficie.

• Posibilitar la personalización del vehículo para la elaboración de la mezcla. • El sistema deberá permitir que el fluido se pueda dosificar también en función

del peso y/o superficie corporal. • Se deberá poder modificar el volumen del suero de la mezcla (y o trabajar

dosificando volúmenes por superficie corporal o peso). Esta funcionalidad se considera clave para la elaboración en pacientes pe diátricos.

• El sistema deberá calcular la estabilidad de la mezcla resultante, una vez realizadas las modificaciones, validación y emisión de alertas.

• La terapia adyuvante (antieméticos sueros protectores etc.) deberá poder dosificarse también en función de peso y/o superficie corporal y/o edad del paciente.

• Posibilidad de control del redondeo automático de dosis, permitiéndose sólo en

/75

casos autorizados.

4.3.4 Alta hospitalaria • Consejos de administración para el paciente • Información de medicamentos al paciente al alta • Acceso a base de datos de medicamentos externas

4.4 Módulo Administración La solución ofertada debe incluir un módulo para la administración. Este módulo deberá ser ofertado como solución web, para ser acc esible desde la estación clínica corporativa Osabide-Global. Además se valorarán las distintas alternativas en movilidad que se oferten (administración a través de Tablet, PDA’s, etc.). Al igual que el resto de aplicaciones corporativas, el acceso al tratamiento del paciente debe ser posible desde cualquier centro de Osakidetza , con independencia del centro donde haya sido prescrito el paciente. Se deberán incluir al menos las siguientes funcionalidades:

• Identificación de la enfermera que administra. • Relación unívoca paciente –tratamiento. • Feedback de la información farmacia-enfermería-médico. • Registro electrónico de administración (código de barras, QR, DataMatrix, o

similar). • Consejos de administración en la hoja de registro de administración (uso de

bomba de infusión, velocidad, incompatibilidades, fotoprotección). • Notificación de PRM con posibilidad de incluir en la HC del paciente. • Notificación de incidencias (no PRM) de administración (extravasación, etc.). • Registro horario de administración • Registro de mezclas devueltas, no administradas y susceptibles de ser

recicladas y/o eliminadas. Registro del motivo de devolución. • Enlaces con instrucciones, reacciones de infusión, extravasación, etc. • Instrucciones para informar al paciente.

4.5 Módulo de Informes y Explotaciones El sistema propuesto deberá incluir un apartado específico para la explotación de datos. Este módulo deberá de tener una visión corporativa sobre toda la actividad con independencia del centro para los usuarios del módulo corporativo, y una visión parcial por centro para los usuarios de centro. La solución deberá ofertar distintos tipos de informes que cubran las necesidades de todos los roles que participan en la cadena terapéutica. Tipo de informes requeridos:

• Características de los pacientes, Antecedentes personales • Datos biométricos • Tratamientos aplicados, Esquemas antiguos de tratamiento y de soporte, • Tolerancia a ciclos anteriores • Motivos de alta, Motivos de reingresos • Medicamento/diagnóstico/protocolo • Morbilidad

/75

• Pacientes por diagnóstico, Pacientes por protocolo • Fecha de cambio de protocolo/motivo • Diagnóstico/indicación • Seguimiento y detección de PRM • Toxicidad específica • Errores de Medicación y Reacciones Adversas • Intervenciones farmacéuticas, detección y aviso de dosis máximas y número

máximo de ciclos excedido • De actividad: Carga de trabajo • Económicos: Coste/proceso oncológico, coste / efectividad, etc. • Resultados, Efectividad, Calidad

Deberá existir la posibilidad de exportar estos informes a formatos estándar (csv, txt, xls, etc.). Por último, indicar que actualmente Osakidetza cuenta con una solución corporativa para la explotación de datos asistenciales y gestión, que es la solución Oracle Business Intelligence, es por ello que los servicios de ETL (Extract, Transform and Load) para el modelado de la información en OBI, están incluidos en este expediente .

4.6 Trazabilidad La solución debe garantizar la trazabilidad completa de todas las acciones que se realicen sobre la aplicación.

/75

5 REQUISITOS TÉCNICOS DE LA SOLUCIÓN

5.1 Alcance técnico de la solución El Sistema propuesto debe cumplir los siguientes requisitos:

• La solución ofertada debe tener carácter Multicentro. Todos los centros deberán trabajar con la misma solución y versión del producto. Y al igual que en el resto de aplicaciones de prescripción, la información será accesible para todos los profesionales implicados en el cuidado del paciente, con independencia del centro prescriptor.

• La solución propuesta debe servirse desde una única instalación en la que se irán incorporando los centros en la fase de implantación, hasta que finalmente todos los centros compartan una misma aplicación. Esto implica la existencia de una sola base de datos , asignada en una estructura central, sobre la cual se configurarán las diferentes unidades hospitalarias incluidas en el proyecto. La base de datos se configurará de forma centraliz ada, y se albergará en el CPD de la Dirección General de Osakidetza .

• El licitador deberá proponer el modelo de arquitectura que considere óptimo, para la correcta operativa de su producto, atendiendo a los requerimientos del mismo. El modelo propuesto deberá ser aprobado por Osakidetza , valorándose aquellas soluciones que se adecúen a los estándares de Osakidetza Anexo I, y facultándose a ésta el derecho de modificarlo.

• El licitador deberá detallar en su oferta las necesidades de infraestructura

de soporte al sistema, que deberán garantizar en todo momento la continuidad de servicio. Osakidetza una vez aprobado el dimensionamiento propuesto, será responsable del suministro de la misma.

• La solución propuesta debe gestionar catálogos y esquemas terapéuticos corporativos únicos. Pero a su vez deberá permitir definir información por centro: catalogo medicamentos centro, recuperabilidad de los productos, centros de coste de imputación de los materiales, etc.

• La solución ofertada debe integrarse con el Directorio Activo de Osakidetza .

o Los datos demográficos del usuario serán comunicados a la aplicación a través de esta integración.

o La solución utilizará el procedimiento de autenticación Single Sign On.

• El módulo para la prescripción , debe estar basado en cliente ligero, solución web, que permita la integración completa con la estación clínica médica de Osakidetza .

• El módulo para la administración , debe estar basado en cliente ligero,

solución web, que permita la integración completa con la estación clínica médica y la estación de enfermería de Osakidetza .

• El resto de módulos, en caso de tratarse de clientes pesados, deberán ser

fácilmente desplegables.

/75

• La solución propuesta, debe integrarse con los SI de Osakidetza , para lo cual deberá ofertar un frontal de servicios y deberá consumir del frontal de servicios existente, dependiendo del tipo de integr ación .

• Para aquellas integraciones basadas en eventos , el sistema deberá hacer

uso de la solución de Gestión de Eventos propia de Osakidetza “Event manager”, y que se detalla en el Anexo I.

• En relación con el puesto cliente , la solución ofertada debe hacer uso de la maqueta de Osakidetza , cuyas características y software de base se detalla en Anexo III .

• El adjudicatario deberá dotar de los mecanismos y herramientas necesarios

para permitir la alta disponibilidad y continuidad de servicio de la solución ofertada.

• Cumplimiento de la legislación vigente en materia de protección de datos de

carácter personal.

5.2 Entornos Los entornos a utilizar en el proyecto y para los cuales deberán ser suministradas las licencias suficientes, serán los siguientes:

• Entorno de Pre-producción/certificación (integració n): o Osakidetza se hará cargo de la gestión de este entorno, a excepción

del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o Su finalidad es la de las pruebas de carga y certificación de arranques o nuevas versiones de productos

• Entorno de Producción:

o Osakidetza se hará cargo de la gestión de este entorno, a excepción del despliegue de las versiones de aplicación y software de base (aplicación y BBDD) si éste no corresponde a estándar Osakidetza , que correrán a cargo del adjudicatario.

o En caso de que se conceda acceso al entorno de producción a usuarios técnicos, el acceso se realizará bajo las condiciones previstas en este contrato con respecto al registro de accesos y las circunstancias que puedan justificar ese acceso.

Todos los entornos de trabajo mencionados se ubicarán en el CPD de la Dirección General de Osakidetza , ubicado en Vitoria-Gasteiz.

/75

6 LÍNEAS DE TRABAJO Este proyecto incluye principalmente las siguientes líneas de trabajo:

6.1 Consultoría Dado que la estructura y tipología propuesta se basa en un concepto corporativo y multicéntrico, será necesario definir en las primeras fases de este proyecto, un marco de trabajo común, que rija el proceso de implantación en toda de la red. Es por ello, que el licitador deberá incluir en su propuesta la colaboración de consultores expertos que en colaboración con los interlocutores que la Comisión Corporativa de Farmacia de Osakidetza designe, definirán un “modelo tipo” de trabajo , que una vez aprobado, se extenderá en los centros objetos del contrato, en base al Plan de Implantación propuesto, una vez aprobado por Osakidetza .

6.2 Accesibilidad a la información histórica No se prevé la migración de la información histórica de los distintos sistemas existentes en los centros objeto del expediente, pero se valorará que el licitador proponga soluciones que faciliten el acceso a esta información.

6.3 Integración con los S.I. Corporativos El licitador deberá definir de forma detallada en su oferta el modelo de integración propuesto, que deberá cumplir los estándares detallados en el Anexo I . La solución propuesta deberá, además, tener en consideración las siguientes necesidades:

• Osakidetza dispone de una arquitectura SOA (Service Oriented Architecture) para gobernar y orquestar los servicios disponibles en la organización. El sistema de información ofertado deberá inventariar y hacer públicos los contratos de los servicios que pondrá a disposición de otros sistemas de información.

• Los requisitos de integración del producto ofertado deberán de ser resueltos mediante uno de estos dos métodos:

o Escenario 1 - Propagación y consumo de eventos: Event Manager <(desarrollo propio)

o Escenario 2 - Consumo de servicios: Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus, Oracle Business Rules, ...)

• Utilización de mensajería HL7, debiendo aceptar las versiones HL7 2.x (no

XML) y 3, y debiendo adaptarse a las evoluciones que se realicen desde Osakidetza en la adopción de nuevas versiones.

• Utilización del estándar CDA como arquitectura de documentos clínicos electrónicos.

• El modelo definido deberá permitir la implementación de integraciones fuera de estándar en aquellas que Osakidetza considere, y únicamente en aquellas que dicha entidad permita.

/75

• Todas las integraciones entre los aplicativos deben registrar la traza en el registro de accesos exigido por la LOPD e identificar unívocamente a cada usuario que accede.

• La aplicación debe ser capaz de ser lanzada con llamadas desde otras aplicaciones. Estas llamadas se realizarán mediante parámetros. El licitador deberá explicar en su oferta las posibilidades que ofrece el producto en este ámbito.

• El adjudicatario se compromete a modificar y mantener las integraciones existentes, si hubiera cambios en los procedimientos y políticas corporativos.

El sistema de gestión de la medicación para la oncología debe integrarse con los siguientes Sistemas de Información:

6.3.1 Catálogos Corporativos Osakidetza está construyendo una plataforma de Catálogos Corporativos, en la que está disponible actualmente la BBDD Corporativa de Pacientes, ofertando los servicios de datos necesarios para consulta sobre estas entidades desde aplicaciones externas. Los principales puntos de integración son los siguientes:

• Demográficos del paciente.

6.3.2 SAP: Recursos Humanos La gestión de recursos humanos en Osakidetza , está soportada sobre el módulo HR de SAP. Los principales puntos de integración son los siguientes:

• Datos de profesional.

6.3.3 SAP: Gestión de Materiales La gestión de materiales en Osakidetza , está soportada sobre el módulo MM de SAP. Los principales puntos de integración son los siguientes:

• Entradas, lotes, caducidades, stocks, precios, ubicaciones. • Consumos de los productos empleados en la elaboración de los tratamientos.

6.3.4 Vademécum Corporativo Osakidetza dispone en colaboración con el Departamento de Salud, de un Vademécum Corporativo, base de todos los sistemas corporativos de prescripción y del historial farmacoterapéutico del paciente. Los principales puntos de integración son los siguientes:

• Catálogos básicos para la caracterización de la medicación (principios activos, unidades de dosificación, unidades de dispensación, vías de administración, formas farmacéuticas, etc. ).

• Características mínimas de los productos farmacéuticos (código nacional, código corporativo del producto farmacéutico, nombre comercial, nombre específico de Osakidetza , etc.)

/75

Desarrollo propio J2EE y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.5 e-Osabide (HIS hospitalario) La integración con el sistema e-osabide, HIS corporativo de Osakidetza debe de ser completa, de forma que la información administrativa resida en un único lugar y no se produzcan redundancias. Los principales puntos de integración son los siguientes:

• Demográficos del paciente. • Estructura organizativa (centros, servicios, secciones, etc). • Ubicación del paciente. • Actividad: Episodios, solicitudes y citas.


6.3.6 e-Osabide. Historial Farmacoterapéutico Hospi talario Parte del Historial Farmacoterapéutico del paciente se encuentra en la aplicación corporativa para la prescripción hospitalaria e-Osabide, por lo que las prescripciones realizadas en esta solución, deberán integrarse en este Historial Farmacoterapéutico Hospitalario. Los principales puntos de integración son los siguientes:

• Prescripciones/ Esquemas: estados, fechas, etc. Desarrollo propio J2EE y Oracle. Arquitectura centralizada. CPD de la Organización Central.

6.3.7 e-Osabide. Prescripción / Dispensación Farmac ia Hospitalaria Osakidetza dispone de una solución corporativa para la Prescripción / Dispensación de medicación de la Farmacia Hospitalaria. Por lo que la medicación prescrita en esta solución que vaya ser dispensada en la Farmacia Hospitalaria, deberá integrarse con la solución corporativa. A su vez, las cantidades dispensadas referentes a estos medicamentos, deberán constar en la solución. Los principales puntos de integración son los siguientes:

• Prescripciones que vayan a ser dispensadas en la Farmacia Hospitalaria. • Dispensaciones realizadas


6.3.8 Osabide (Estación clínica) Sistema corporativo de Osakidetza para la gestión de la Historia clínica. Este sistema es la estación clínica de los profesiones asistenciales, por lo que será desde el mismo, desde donde se dará acceso a la solución corporativa para la

/75

medicación oncológica. Los principales puntos de integración son los siguientes:

• Accesos a los módulos de prescripción y administración. • Eventos más significativos del proceso oncológico: los principales eventos

relacionados con el proceso oncológico serán notificados mediante el Gestor de Eventos de Osakidetza a esta estación clínica

La estación clínica de Osakidetza (desarrollo propio, BBDD Oracle) se sirve de forma centralizada con 2 tecnologías:

• OsabideGlobal: Cliente rico con tecnología .net • OsabideINTEGRA: Cliente ligero (movilidad), con tecnología HTML5

6.3.9 Laboratorios Actualmente, la solución implantada en los laboratorios de Osakidetza es el producto Omega3000 de Roche. No obstante, Osakidetza está inmersa en un proyecto de sustitución de la solución anterior, por el software comercial GESTLAB de Cointec. Los principales puntos de integración son los siguientes:

• Resultados

6.3.10 OBI (Solución de Business Intelligence de Os akidetza) Sistema corporativo de Osakidetza de Business Intelligence para la explotación de datos asistenciales y gestión. Los principales puntos de integración son los siguientes:

• Prescripción y administración. • Consumos por paciente.

Desarrollo basado en la herramienta de Oracle, Oracle Business Intelligence Enterprise Edition.

6.3.11 Ulises El Hospital Universitario Donostia pose un software específico para la gestión de los medicamentos dentro de la farmacia llamado Ulises. La aplicación existente para la gestión de la medicación oncológica en el hospital, incluye una integración con este software a través de un fichero de texto. La solución final, debe contemplar esta integración.

6.4 Formación La planificación, gestión y ejecución de la formación, correrá a cargo del proveedor, que formará directamente a los siguientes tipos de usuarios:

• Formación a formadores: el adjudicatario formará a los referentes dentro del personal de Osakidetza que indique la dirección del proyecto. La formación

/75

deberá ser la suficiente para que los referentes puedan realizar la formación en cascada. Esta formación se realizará antes de la puesta en marcha de la aplicación.

• Formación técnica : orientada al departamento de informática y enfocada a la administración de la aplicación y a las herramientas de desarrollo y programación inherentes, si es que las hubiera. Además, se impartirá formación sobre el modelo de datos, destinada a poder explotar la información mediante herramientas de Business Intelligence. Esta formación se realizará antes de la puesta en marcha de la aplicación.

La documentación de los cursos de formación, así como la documentación y guías de uso de las diferentes funcionalidades que ofrezca la aplicación ofertada, es tarea del proveedor, que deberá proporcionar puntualmente antes de que cualquier formación tenga lugar o cualquier funcionalidad entre en producción. El licitador entregará en la oferta una planificación detallada que explique el alcance de los contenidos de formación y en el que se deberá indicar el número de horas previstas de formación para los usuarios y para el personal de informática. Este número de horas es orientativo y en ningún caso será el límite de horas a impartir si la formación no ha llegado al nivel adecuado para la adopción de sistema.

6.5 Implantación La implantaciones se ejecutara en base al “modelo tipo” definido en la fase de consultoría. Se requerirá realizar la prestación del servicio en los siguientes centros de manera presencial:


El equipo de implantación deberá permanecer en el centro, en la dimensión que el licitador considere adecuada y que deberá detallar en su propuesta, al menos durante 2 semanas desde el arranque del nuevo SI. El licitador deberá garantizar en todo momento durante el proyecto de implantación, la convivencia entre el actual sistema, y la implantación de la nueva solución. El proveedor deberá designar un coordinador de soporte cuya dedicación y disponibilidad se detallará en la oferta. Dentro de la garantía del proyecto se incluyen las tareas de soporte, resolución de incidencias y atención a mejoras de producto, que se produjeran durante la implantación de la solución en Osakidetza . Finalmente, señalar que los trabajos de implantación, integración o migración de datos, no suponen en ningún caso servicios añadidos, sino que resultan imprescindibles para la puesta en marcha del software objeto del contrato.

/75

7 MANTENIMIENTO POST-IMPLANTACIÓN El servicio de Mantenimiento post-implantación, que se contratará una vez finalice este expediente, pero cuyo coste deberá detallar el licitador , deberá incluir al menos los servicios que se detallan a continuación:

7.1 Mantenimiento integral Incluye los servicios de mantenimiento propiamente dicho de la solución implantada. A los efectos de una mejor comprensión, se consideran los siguientes tipos de mantenimiento:

• Preventivo: Es aquel incluye las revisiones periódicas, verificaciones calibraciones y ajustes que aseguran que la solución se mantienen dentro de sus especificaciones operativas, y previenen la aparición de fallos. En cada revisión se realizarán los ajustes, modificaciones y sustituciones que se estime necesarios para un correcto funcionamiento del sistema.

• Correctivo: Es aquel que incluye aquellos cambios precisos para corregir los

errores del producto software y que tienen como finalidad restablecer los parámetros originales de funcionamiento.

• Evolutivo : Es aquel que incluye mejoras y nuevas funcionalidades. El

adjudicatario incluirá en sus productos todas aquellas funcionalidades que considere mejoras de carácter general para la aplicación, teniendo en especial consideración aquellas propuestas por Osakidetza .

7.2 Soporte de hot-line El Mantenimiento deberá incluir los Soportes de Mantenimiento de 1º, 2º y 3º nivel desde el Centro de Soporte del licitador, incluyéndose, por tanto, todos aquellos viajes que se consideren necesarios realizar para el correcto funcionamiento de la aplicación contratada/instalada. El horario será el habitual de oficina. Los contenidos de los soportes de mantenimiento de 1º, 2º y 3º nivel son los siguientes:

• Mantenimiento de 1º Nivel : Acceso al servicio de soporte telefónico del licitador para la resolución de consultas a nivel usuario sobre el funcionamiento de la aplicación contratada y de nuevas funcionalidades instaladas.

• Mantenimiento de 2º Nivel: Asesoramiento a nivel de tablas y funcionamiento interno de la aplicación. En errores producidos por la utilización incorrecta de la aplicación contratada o por causas ajenas al adjudicatario, ya puedan ser de hardware y/o de conexiones con otras aplicaciones, el adjudicatario se compromete al asesoramiento y, si es posible, resolución de cualquier problema que haya podido causar éste sobre la aplicación contratada, siempre y cuando no impliquen desplazamientos al centro del cliente en el cual esté instalada la aplicación.

• Mantenimiento de 3º Nivel: Corrección de errores existentes en la aplicación por los medios que la compañía considere oportunos en función de la gravedad y la posibilidad de proporcionar al cliente una solución adecuada, quedando incluidos cuantos viajes sean necesarios para la total resolución de los

/75

problemas indicados a continuación: o Parada del entorno de Producción. Afectación amplia o total de la

aplicación y que no sean causas ajenas al adjudicatario, es decir, que sean imputables al mismo.

o Incidencias que afectan a la operativa diaria de los usuarios dificultando su tarea y que el soporte del adjudicatario remoto no sea capaz de solucionar en 48 horas.

7.2.1 Asistencia en el centro – acceso remoto Deberá existir comunicación vía VPN para que desde el centro de mantenimiento, pueda acceder a los centros. La mayoría de las incidencias se resolverán de forma remota, mediante la consulta de la incidencia y el posterior envío del software adaptado. Sin embargo, hay otro tipo de servicios que requieren asistencia en el centro:

• Jornadas de trabajo con otros proveedores para resolver incidencias conjuntas. • Implantación en centro piloto de una versión nueva para su validación y

aceptación

7.2.2 Tiempos de respuesta En lo referente a los niveles de servicio deberán mantenerse orientativamente los siguientes ratios:

• El tiempo máximo de respuesta será el siguiente: � Horario de oficina: 2 horas desde la notificación de la incidencia. � Fuera de Horario de oficina: primera hora del día siguiente válido

• Si se reporta una incidencia debido a un error de la aplicación que reproduce

un problema que impide la explotación correcta de la aplicación y no admite una solución temporal razonable, se procederá a aplicar una solución de emergencia.

Dicha solución de emergencia implicará que una vez localizado el error se procederá a su pronta reparación y al envío al Cliente de una versión de la aplicación para su instalación. El tiempo máximo de envío de esta versión de urgencia desde su diagnóstico será de:

� 24 horas laborables si el error es crítico (no es posible trabajar con la aplicación)

� 48 horas laborables si el error es muy grave (gran degradación en el uso del sistema)

� y una semana natural en el resto de los casos.

Además, el servicio técnico tomará las acciones que sean necesarias para restaurar la integridad de los datos gestionados por la aplicación, en caso de que ésta se hubiera visto comprometida. Se registrará todas las incidencias y dará contestación telefónicamente o por correo electrónico con la consiguiente solución, enviando mensualmente por correo un informe que detallará las consultas abiertas en el mes, las consultas cerradas con una descripción de su solución y las consultas que se encuentran pendientes, así como los parámetros de calidad del servicio.

/75

8 PRODUCTOS A OBTENER El resultado final consistirá en la implantación del Sistema Informático que dará soporte a la gestión de la medicación para la oncología, junto con la documentación del Sistema. Los productos a obtener serán, como mínimo, los siguientes:

• Planificación del proyecto. • Especificaciones hardware y software necesarias para la implantación del

producto. • Documentación Técnica del producto. • Informes de seguimiento del proyecto. • Manual de Usuario. • Manual de Explotación. • Manual de Instalación.

/75

9 PLANIFICACIÓN DEL PROYECTO Es necesario que los licitadores presenten los cronogramas en los que se deben especificar los contenidos o tareas y su distribución en el tiempo. Estos cronogramas incluirán, asimismo, los diferentes hitos a cubrir y los entregables.

/75

10 EQUIPO DE TRABAJO Las empresas interesadas en la adjudicación del contrato presentarán en su propuesta la descripción de su equipo de trabajo, especificando los recursos humanos que destinarán al proyecto, sus perfiles profesionales, y las dedicaciones por cada una de sus categorías. Existirá un Director del Proyecto por parte de la empresa adjudicataria, representante de la misma e interlocutor y responsable de los trabajos ante la Dirección del Proyecto de Osakidetza . Osakidetza aportará también la figura de un Director de Proyecto, con la función de coordinar la participación de los recursos humanos del mismo que sean necesarios en cada momento. Osakidetza controlará, mediante la figura de su Director de Proyecto, el cumplimiento de los términos acordados, así como la calidad y adecuación del servicio objeto de este contrato, quedando ambos sujetos a lo que marca la Ley de Contratos de las Administraciones Públicas (texto refundido), en cuanto hace referencia a completar los términos y calidad de los productos desarrollados. Asimismo, deberán identificarse los responsables únicos en cuantas actividades que, por su importancia, se considere oportuno: análisis, desarrollo, control de calidad,. y sus funciones y relaciones con el resto del equipo y Osakidetza . Osakidetza , por su parte, deberá asegurar la colaboración de técnicos responsables de la aplicación en las distintas fases del proyecto y designará un Coordinador, a través del cual se canalicen cuantas consultas sean necesarias para el conocimiento detallado de dicha solución.

/75

11 CONTENIDO DE LAS OFERTAS Con carácter obligatorio, las propuestas deberán presentarse en papel y en soporte digital, compatible con las herramientas instaladas en Osakidetza (MSWord 2010, Adobe Acrobat Reader 10). Las ofertas se presentarán en dos modalidades:

• Oferta resumen ejecutivo , donde se recogerán los aspectos fundamentales de la oferta y sus elementos de valor añadido esenciales, conteniendo la información más relevante para la evaluación de la oferta por Osakidetza según los criterios de adjudicación publicados. Este resumen ejecutivo no podrá superar el número de 25 páginas (25 páginas A4).

• Oferta completa, donde se podrá explicar y detallar los diferentes aspectos de

la oferta, siempre que supongan una información directamente relacionada con los servicios propuestos en el pliego. La oferta completa no podrá superar el número de 300 páginas (300 páginas A4).

Ambas modalidades de ofertas se deberán ajustar al siguiente contenido y formato: 1. Introducción

Se detalla el contexto en el que se realiza la oferta y las capacidades globales del licitador para entender y satisfacer los requerimientos del contrato. En este apartado se expondrá la estrategia que la empresa ofertante considera apropiada para alcanzar los objetivos del proyecto.

2. Descripción de la solución propuesta

Descripción detallada de las herramientas/productos ofertados que a priori se consideran apropiados para la realización del proyecto, justificando su adecuación a los objetivos del mismo y realizando una descripción exhaustiva de la funcionalidad que incorporan. Se aportará también detalle exhaustivo tanto del tipo de licenciamiento ofertado, así como del mantenimiento propuesto, una vez finalizado el contrato, y las modalidades del mismo.

3. Arquitectura tecnológica y modelo de integración Descripción detallada de la arquitectura propuesta, modelo y elementos que la componen, con objeto de garantizar la escalabilidad y continuidad de servicio. Se valorarán positivamente aquellas soluciones alineadas con los estándares de Osakidetza , detallados en el Anexo I. Se deberá detallar también, de forma exhaustiva la infraestructura requerida para la arquitectura propuesta, describiendo de forma detallada las características de esta infraestructura.

/75

Se incluirá también un detalle exhaustivo de la estrategia y modelo de integración del producto ofertado con los SI corporativo.

4. Plan de Trabajo

Descripción específica para cada una de los servicios a prestar: descripción del contenido, estrategia y operativa de trabajo y relación entre tareas, destacando especialmente las tareas relacionadas con el despliegue de la solución, formación y coaching. Se incluirá la planificación en el tiempo de cada línea de trabajo, hitos y productos resultantes, que permitirán la certificación del proyecto. Se incluirán los procedimientos a seguir para el control del proyecto, a fin de detectar posibles desviaciones y tomar las acciones correctivas adecuadas.

5. Organización y Equipo de Trabajo

3.1. Modelo organizativo: Modelo global del proyecto y del equipo humano, distribución de funciones y responsabilidades, tareas, coordinación, dedicación al proyecto, flujos de comunicación, etc.

3.2. Equipo de Trabajo Dimensión, configuración, perfiles y volumen de horas/perfil, del equipo de trabajo propuesto.

/75

12 PROPIEDAD DE LOS PRODUCTOS Todos los productos descritos en el punto 8 de este documento que entregue el adjudicatario quedarán en propiedad exclusiva de Osakidetza , así como su propiedad intelectual, quedando el adjudicatario obligado a renunciar a cualquier derecho sobre estos conceptos.

/75

13 CONFIDENCIALIDAD En consideración al tipo de información procesada, el adjudicatario está obligado a mantener la más absoluta confidencialidad sobre todos aquellos datos y documentos a que tengan acceso con motivo de esta adjudicación. A ellos accederán, exclusivamente, las personas estrictamente imprescindibles para el desarrollo de las tareas inherentes a la misma. Todas ellas serán advertidas del carácter confidencial y reservado de la información a la que tendrán acceso. Todos los ficheros que se pongan a disposición del adjudicatario para la ejecución del contrato son propiedad de Osakidetza y están registrados y sometidos a la salvaguarda que establece la legislación vigente, en especial la relativa a la protección de datos personales. Toda cesión a terceros será perseguida en los tribunales. Osakidetza se reserva el derecho de establecer cualquier tipo de marcaje de los ficheros que se dejarán al adjudicatario, de manera que sus características puedan constituirse como prueba que posibilite localizar el origen y los responsables de las eventuales cesiones. Bajo ningún caso ni circunstancia, el adjudicatario podrá suministrar a terceros, ni utilizar para sí ni para otros, datos facilitados por Osakidetza , para fines distintos a los contemplados en el objeto del presente contrato. El adjudicatario estará obligado a poner en conocimiento de Osakidetza , inmediatamente después de ser detectada, cualquier sospecha de eventuales errores que se puedan producir en el sistema de seguridad de la información. El adjudicatario faculta a Osakidetza para que, al terminar el proyecto, pueda responsabilizarlo y/o repercutirle los costes derivados de posibles reclamaciones ocasionadas por negligencia y/o falta de confidencialidad del mismo. Adicionalmente y como condición general, todos los servicios prestados deberán contar con las medidas de seguridad y de confidencialidad adecuadas al grado de sensibilidad de la información suministrada, de acuerdo con lo descrito en la LOPD

/75

14 PRESUPUESTO, PLAZOS Y FORMA DE PAGO

14.1 Presupuesto El presupuesto máximo asignado y los plazos máximos de ejecución para este proyecto son los siguientes:

• Presupuesto máximo asignado : 575.000€(SIN IVA) La valoración económica esta expresada en Euros, es máxima e incluye la totalidad de los conceptos devengables. El importe anterior se deberá distribuir en las siguientes partidas, cuyos precios máximos se indican a continuación: Se deberán detallar claramente los siguientes aspectos:

• Importe de las licencias del producto ofertado. Se deberá detallar además el coste del mantenimiento anual del producto, que no podrá ser superior al 25% del coste total del proyecto.

El mantenimiento anual, incluirá al menos los servicios detallados en el capítulo 7, de este pliego.

• Importe de la implantación del proyecto: Se deberá detallar el importe por cada una de las líneas de trabajo detalladas en el capítulo 6 de este Pliego de bases técnicas.

Asimismo, se indicarán los precios unitarios/hora por cada categoría profesional ofertada.

La suma total de los conceptos anteriormente señalados no podrá exceder del precio de licitación total. La valoración económica deberá ir obligatoriamente en el sobre B : “Oferta económica y criterios evaluables de forma automática mediante la aplicación de fórmulas”.

14.2 Plazos El plazo de ejecución será de 16 meses desde el día siguiente a la fecha de formalización del contrato.

14.3 Forma de pago Se realizará de la siguiente forma:

� Las licencias del producto se facturarán una vez recepcionadas, y tras el VºBº del responsable de Osakidetza.

� Para el resto de las tareas del proyecto, se presentará una factura a la finalización de cada una de las líneas de trabajo detalladas en el capítulo 6 de este Pliego, y tras el VºBº del responsable de Osakidetza .

/75

15 CRITERIOS DE ADJUDICACIÓN Para la elección de los criterios de valoración y su ponderación se han tenido en consideración los aspectos más significativos recogidos en el Pliego de Bases Técnicas que se acompaña a este expediente, a fin de garantizar que las ofertas de los licitadores se ajusten a lo exigido para el suministro objeto de este expediente. De acuerdo con lo antedicho, los criterios que servirán de base para la adjudicación del presente contrato serán los siguientes:

JUICIOS DE VALOR: ................................. ..................................................... 70

• Descripción del contenido de la solución: Descripción detallada de las funcionalidades del producto ofertado ....................................................... 40

� Modulo Corporativo. Estructura básica y Configuración ......................... 7

� Modulo Centro. Configuración ............................................................... 7

� Módulo Prescripción .............................................................................. 7

� Módulo Validación Farmacéutica y Elaboración ..................................... 9

� Módulo Administración........................................................................... 5

� Módulo de Monitorización, Informes y Explotaciones ............................. 5

• Modelo de integración: Descripción detallada del tipo, mecanismos y puntos de integración ........................................................................................ 5

• Arquitectura tecnológica propuesta: Descripción detallada de la arquitectura propuesta, componentes y garantía de escalabilidad y continuidad de servicio .................................................................................... 10

• Coherencia y contenido del Plan de Trabajo: Plan de trabajo contenido e hitos: Estrategia de Implantación, consulta del histórico existente, formación y soporte ......................................................................... 15

Umbral mínimo de la suma de los 4 criterios anterio res: 40 puntos . Se valorarán con carácter previo los criterios de adjudicación en los que se haya establecido un umbral mínimo de puntuación. Las ofertas deberán superar ese umbral para continuar en el proceso selectivo y ser valoradas conforme al resto de los criterios de adjudicación.

FÓRMULA: .......................................... ............................................................ 30

• Precio de la oferta ............................. .......................................................... 25

Atendiendo a la tabla que se presenta a continuación, la valoración del precio se realizará de la siguiente forma: � Se establecen 6 tramos para determinar la puntuación obtenida, según el

porcentaje de baja con respecto al importe de licitación, que se calculará de la siguiente forma:

/75

Porcentaje de baja = 1 −��

�� ó��

� En cada uno de los tramos, el valor obtenido será el resultante de la

interpolación del porcentaje de la Baja entre los valores de dicho tramo.

Interpolación %baja =

puntostramo∗�%� � �� %�í"�� "�

�%��"��#$%�� " %�í"�� "�

� Los puntos valorados para cada tramo se sumarán hasta alcanzar el porcentaje

de baja presentada. � La oferta cuyo importe sea igual al importe de licitación se valor ará con 0

puntos .

Descripción tramo puntos Puntos Porcentaje de baja de hasta un 5% con respecto al importe de licitación. 7 Porcentaje de baja superior al 5% e igual o inferior al 7,5% con respecto del importe de licitación. 6

Porcentaje de baja superior al 7,5% e igual o inferior al 10 % con respecto del importe de licitación. 5

Porcentaje de baja superior al 10% e igual o inferior al 15% con respecto del importe de licitación. 4

Porcentaje de baja superior al 15% e igual o inferior al 20% con respecto del importe de licitación. 2

Porcentaje de baja superior al 20%. Este último tramo se valorará de forma que se darán 1 punto a la oferta más económica, interpolándose las restantes ofertas que se sitúen en este tramo de manera proporcional.

1

Total Puntos 25

• Precio del mantenimiento anual .................... ................................................. 5 El precio menor del mantenimiento anual recibirá 5 puntos y el resto proporcionalmente aplicando la siguiente fórmula:

Precio Mínimo

---------------------------------- x 5 Precio Ofertado

El mantenimiento del producto ofertado, se contratará una vez finalizado este expediente, y deberá incluir al menos los servicios detallados en el capítulo 7 de este pliego. La evolución de versiones del producto ofertado durante la vigencia del contrato, se considera incluida en el presente expediente.

Comité de expertos

� GORKA MENTXAKA ATXALANDABASO (Dirección General) � MAITE CUADRADO ZUBIZARRETA (Dirección General) � SUSANA IGLESIAS TAMAYO (Dirección General)

/75

16 CONSULTAS AL PLIEGO Durante el periodo de licitación y ante cualquier necesidad de aclaración sobre cuestiones referidas a las especificaciones recogidas en el presente Pliego de Bases Técnicas, los licitadores deberán remitir por correo electrónico las preguntas e información que consideren necesarias para elaborar la Propuesta Técnica. Los licitadores podrán dirigir sus consultas o aclaraciones a la dirección de correo electrónico de la Subdirección de Informática y Sistemas de Información:

[email protected] Los licitadores deberán identificar, a un único responsable de la oferta, que será durante al periodo de licitación, el interlocutor único con Osakidetza para cualquier tipo de consulta o aclaración sobre los términos expuestos en el presente Pliego, no admitiéndose ninguna consulta o aclaración de persona distinta a la señalada. Así mismo los licitadores para formular sus consultas o aclaraciones deberán cumplimentar la siguiente información:

• Nº. Pregunta • Capítulo/Apartado • Página • Párrafo • Descripción de la Consulta

/75

17 ANEXO I: DIRECTRICES Y ESPECIFICACIONES TÉCNICAS (DET) Este anexo, DET (Directrices y Especificaciones Técnicas), contiene las Directrices y Especificaciones Técnicas de los Sistemas de Información de Osakidetza en el ámbito TIC.

17.1 Especificaciones para Desarrollo Este apartado refleja los principales aspectos del diseño técnico de la arquitectura de referencia para aplicaciones web, definida por Osakidetza . Una arquitectura de referencia es un conjunto de patrones diseñados y probados para ser usados en un contexto específico, en nuestro caso, en los sistemas de misión crítica de Osakidetza . Es una guía de ayuda para ser usada por los arquitectos y desarrolladores, que permite conceptualizar nuevas aplicaciones rápidamente reutilizando un diseño suficientemente probado. La arquitectura de referencia refleja las decisiones y aspectos técnicos de diseño basados en la experiencia de Osakidetza en el desarrollo, mantenimiento y evolución de aplicaciones web. El principal propósito de la arquitectura de referencia para aplicaciones web es por lo tanto, homogeneizar el desarrollo, despliegue y explotación en producción de las aplicaciones. En este sentido, la implementación de la arquitectura de referencia aportará los siguientes beneficios perseguidos por Osakidetza :

• Mejorar el rendimiento de las aplicaciones. • Garantizar la escalabilidad y la tolerancia a fallos. • Facilitar las integraciones entre sistemas. • Aprovechar las tecnologías estándares y capacidades proporcionadas por los

recursos hardware y software existentes en la organización. • Reducir el coste del mantenimiento (evolutivo y correctivo) mediante la

simplificación del diseño de la solución y la implementación del mismo.

17.2 Arquitectura de Referencia Una de las características generales de los proyectos con éxito es que existe un diseño previo bien fundamentado que define la arquitectura general del sistema, las soluciones de infraestructura y plataforma (por ejemplo alta disponibilidad, recuperación frente a desastres, copia de seguridad y restauración, monitorización), y realiza un mapeo de requerimientos a elementos de la arquitectura. Desde el punto de vista de sistemas de información, este requerimiento estratégico debe tener una base de arquitectura y diseño previo que permita cumplirlo durante la evolución del ciclo de vida. Los principios de la arquitectura de referencia , describen los principios fundamentales que se han considerado para el diseño de dicha arquitectura. Los principios representan los preceptos o reglas básicas que guían el proceso de diseño.

La arquitectura de referencia se describe usando tres vistas diferentes: • Vista lógica o conceptual, en la que se presenta la arquitectura mediante una

visión de alto nivel que permite entender los diferentes componentes que

/75

intervienen y las interacciones existentes entre ellos. • Vista de implementación , en la que se proporcionan detalles adicionales

sobre la tecnología y productos para la construcción de los diferentes componentes.

• Vista de despliegue , en la que se describe de forma pormenorizada la información del sistema relativa a la instalación y explotación que se realiza por entornos.

17.2.1 Vista lógica El propósito de la vista lógica es permitir un entendimiento de alto nivel de la arquitectura de referencia y de las diferentes capas y componentes en las que está estructurada. También se define la integración con otros sistemas. Sobre esta vista lógica se deberían plasmar todos los elementos que deben ser considerados cuando se diseña una nueva aplicación.

Las aplicaciones deben de tomar este diseño como referencia e indicar: • Las capas de la arquitectura de referencia que se implementarán • Servicios externos con los que interactúa la aplicación • Clientes que usarán la aplicación • Servicios de persistencia de datos

En la siguiente figura se muestra la vista lógica de la arquitectura de referencia para aplicaciones web.

Figura 1. Vista lógica de la arquitectura de referencia

/75

17.3 Directrices de Desarrollo Se contemplan como directrices de desarrollo, las normativas , estándares y recomendaciones para la elaboración de un código fuente homogéneo , estandarizado y de calidad , con el objeto de minimizar las tareas de mantenimiento y la deuda tecnológica . También se incorporan las especificaciones para la obtención de sistemas de información seguros , con un rendimiento óptimo y adaptado a las necesidades de las tecnologías definidas por las Arquitecturas de Software que se tomarán como referencia en los desarrollos. A continuación se enumeran algunas de las directrices de desarrollo que deberán cumplir las soluciones desarrolladas para Osakidetza :

17.3.1 Construcción de Aplicaciones por Capas El principal objetivo de la construcción de aplicaciones por capas, es la separación de la lógica de negocio, de la lógica de diseño . Su principal ventaja, es que el desarrollo se puede llevar a cabo en varios niveles y, en caso de que sea necesario llevar a cabo algún cambio, sólo se necesita intervenir al nivel requerido. El ejemplo clásico de este tipo de práctica y el que se contempla a nivel de directriz, es el consistente en separar las aplicaciones en tres capas: Presentación , Negocio y Persistencia . Por lo tanto, las aplicaciones serán desarrolladas en capas ; es decir, se diseñará las aplicaciones separando entre los modelos de datos, la lógica de aplicación, y la interfaz de usuario . Si optamos por esta separación de responsabilidades, podremos compartir totalmente el modelo de datos y sólo tendremos que adaptar la interfaz de usuario. Por cada capa se consideran una serie de directrices de desarrollo basadas en el modelo de tres capas propuesto por la Arquitectura de Referencia de Osakidetza .

17.3.2 Capa de Presentación Mediante la capa de presentación se separa la interacción del usuario respecto a la lógica de negocio. El uso de la arquitectura en tres capas en el desarrollo de aplicaciones, ha favorecido la aparición de tecnologías que facilitan la implantación de esta capa, además de un conjunto de buenas prácticas que mejoran el proceso de su implementación. Directrices de Desarrollo para la Capa de Presentac ión:

• Finalidad: Presentar la información al usuario. La capa de presentación, también llamada "capa de usuario", deberá presentar el sistema al usuario, comunicar la información necesaria y capturar la misma en un proceso que realiza un filtrado para validar los datos respecto al formato. No deberá procesar datos ni tomar decisiones . Esta capa se comunica únicamente con la capa de negocio. También es

/75

conocida como interfaz gráfica y debe tener la característica de ser "amigable" (comprensible y fácil de usar) para el usuario.

• Modularidad: Controlar la relación entre las vistas.

En una vista sólo debe hacerse referencia a otras vistas relacionadas con su funcionalidad. En ejecución, se recomienda integrar la vista con un sistema de plantillas , para poder aumentar de esta manera la reusabilidad y el encapsulamiento de funcionalidades .

• Internacionalización y localización: Preparar las aplicaciones para diferentes

idiomas y convenciones. Las aplicaciones estarán preparadas para que puedan adaptarse a diferentes idiomas y convenciones (formatos de fecha, moneda, etc.), sin necesidad de realizar cambios de relevancia en el código.

• Validaciones: Realizar validaciones sobre los datos introducidos por los

usuarios. La vista será la responsable de la validación inicial de los datos introducidos por el usuario. La validación debe ser obligatoria sólo para el caso de campos y formato. Nunca deberá realizarse una validación de negocio d esde esta capa .

• Catálogo de controles: Elaborar un catálogo con la lista de controles.

Se especificará, si es posible, la función del control, los posibles validadores/conversores que se le puedan asociar, los eventos que pueda lanzar y los atributos que puedan cambiarse para manipular su aspecto externo. Los controles deberían permitir el tratamiento de componentes y eventos que posibiliten extraer de la vista toda la lógica de interfaz. La consecuencia principal de este enfoque, es que desde la vista nunca se manipularán los controles . El objetivo es que la construcción de la vista sea una tarea totalmente autónoma del resto de componentes de la función de negocio .

• Uso de plantillas: Facilitar el mantenimiento haciendo uso de plantillas.

Se debe utilizar un framework de plantillas (templates) en la capa de presentación , ya que de esta manera se facilita el mantenimiento del diseño de los sistemas de información. Existen frameworks que posibilitan aislar el diseño de la aplicación en un único fichero de plantilla (o más, si se necesitan). Esto facilita la tarea de hacer modificaciones en e l diseño .

• Controles de interfaz: Utilizar un identificador único para los controles de

interfaz. Todos los controles de interfaz, deben mantener un identificador único para facilitar su compresión , reutilización y batería de pruebas del mismo.

• Independencia entre capas: Evitar el acoplamiento entre distintas capas.

Cada capa debe tomar la responsabilidad que le corresponde. En este caso, debe evitarse que la capa de presentación realice atribuciones que le correspondan a otras capas.

17.3.3 Capa de Negocio La capa de negocio expone la lógica necesaria a la capa de presentación para que el usuario, a través de la interfaz, interactúe con las funcionalidades de la aplicación.

/75

Se utilizarán componentes de negocio para abstraer la lógica de negocio de otros problemas generales de las aplicaciones, como la concurrencia, transacciones, persistencia, seguridad, etc… Directrices de Desarrollo para la Capa de Negocio:

• Reglas de negocio: Implementar las reglas de negocio en esta capa. Los módulos que requieran una funcionalidad deberán encontrarla en un solo lugar y única versión. No debe haber réplica de funcionalidades en ninguna de las otras capas (Persistencia y/o Presentación)

• Validaciones de datos: Garantizar el valor correcto de los datos.

Esta capa debe garantizar que los datos requeridos para procesarla hayan sido debidamente validados, y sólo se puede iniciar el flujo del proceso de negocio si la validación resultó correcta.

• Comunicación entre capas: Definir la estrategia de comunicación entre capas.

La comunicación entre capas se debe establecer mediante objetos del modelo. Se crearán entidades sin métodos, sólo tendrán propiedades, campos y atributos, que nos servirán para almacenar información, como puede ser la asociación de las propiedades a las columnas de la base de datos.

• Transacciones: Tratar convenientemente las transacciones de los datos.

La capa de modelo de datos proporciona los datos al sistema, pero las transacciones que involucren a dichos datos, se deben manejar desde la capa de negocio.

• Excepciones: Encapsular en la capa de negocio las excepciones y trasladarlas

de forma correcta a la capa de presentación. El objetivo es simplificar el manejo de excepciones de la aplicación. Se recomienda tener bien definida una política para el tratamiento de excepciones y disponer de una jerarquía propia de e xcepciones . Como norma general, las aplicaciones no deberán nunca extender las excepciones del sistema , sino las de su propia jerarquía de clases.

• Servicios encapsulados: Encapsular la capa de negocio en servicios.

Se debe encapsular la capa de negocio en servicios, para de esta forma aislar la base de datos respecto de una interacción direct a con el usuario . Estos servicios de negocio conforman un "puente" entre el usuario y los datos. Responden a peticiones de usuarios u otros servicios de negocio aplicando procedimientos formales y reglas de negocio a datos relevantes.

• Acceso a servicios: Controlar el acceso a los servicios en la capa de negocio.

El control de acceso al servicio de negocio debe hacerse en la capa de negocio, puesto que podemos tener distintas capas de presentación, como por ejemplo, una capa de presentación web y una capa de presentación Web Services. El control de acceso puede realizarse tanto a nivel de método, dentro de cada servicio, como a nivel de servicio vertical.

• Inyección de Dependencias : Uso del patrón de diseño ‘Inyección de

Dependencias’ (DI), como forma de ‘Inversión de control’ (IoC) La Inversión de Control (Inversion of Control en inglé s, IoC) es un método

/75

de programación en el que el flujo de ejecución de un programa se invierte respecto a los métodos de programación tradicionales. En la Inversión de Control se especifican respuestas deseadas a sucesos o solicitudes de datos concretas, dejando que algún tipo de entidad o arquitectura externa lleve a cabo las acciones de control que se requieran en el orden necesario y para el conjunto de sucesos que tengan que ocurrir. Es el principio subyacente a la técnica de Inyección de Dependencias, siendo términos frecuentemente confundidos.

La Inyección de Dependencias (Dependency Injection en inglés, DI) es un patrón de diseño orientado a objetos , en el que se suministran objetos a una clase en lugar de ser la propia clase quien cree el objeto. La forma habitual de implementar este patrón es mediante un "Contenedor DI" y objetos planos o simples, por ejemplo los llamados POJO. El contenedor inyecta a cada objeto, los objetos necesarios según las relaciones plasmadas en un fichero de configuración. Típicamente este contenedor es implementado por un framework externo a la aplicación.

La implementación de un patrón de diseño como la ‘Inyección de Dependencias’ permite gestionar de una manera eficiente las dependencias entre los diferentes componentes de una aplicación, sin tener que recurrir a un acoplamiento no deseable entre estos.

17.3.4 Capa de Persistencia La necesidad de vincular los datos guardados en una base de datos relacional, con los objetos de una aplicación orientada a objetos, determina la aparición del concepto de persistencia de objetos . Siguiendo el paradigma de desarrollo en tres capas, la persistencia queda recogida en su propia capa, sepa rada de la lógica de negocio y de la interfaz de usuario . La persistencia de la información es probablemente la parte más crítica en una aplicación de software y permite ejecutar operaciones en el almacenamiento persistente (base de datos). El modelo de objetos de un sistema, difiere en muchos aspectos del modelo relacional. La interfaz que une esos dos modelos se llama asociación objeto-relacional (ORM en inglés). La capa de persistencia encapsula el comportamiento necesario para mantener los objetos. Directrices de Desarrollo para la Capa de Persisten cia:

• Asociación Objeto-Relacional: Usar un mapeador Objeto Relacional para implementar la capa de persistencia. Se debe utilizar un mapeador Objeto-Relacional para implementar la capa de persistencia, ya que es una técnica que permite convertir los tipos de datos utilizados en un lenguaje de programación orientado a objetos y los utilizados en una base de datos relacional, lo que posibilita el uso de las características propias de la orientación a objetos.

• Uso del patrón DAO: Crear una clase DAO por cada objeto de negocio del

sistema El patrón CRUD , reconocido como el patrón más importante del acceso a datos, indica que cada objeto debe ser creado en base de datos para q ue sea persistente . Para esto es necesario asegurar que existen operaciones que

/75

permiten a la capa inferior (de acceso a datos) leerlo, actualizarlo o borrarlo.

Mediante la implementación de DAO's pueden proporcionarse las operaciones CRUD necesarias para cada aplicación. No es obligatorio que cada DAO implemente todas las operaciones CRUD (puede no ser necesario en la lógica funcional del sistema). Por lo tanto, se recomienda crear un DAO distinto por cada objeto de negocio en el sistema .

• Manejo de la caché: Usar la caché en las aplicaciones para reducir tiempos de

lectura. Se recomienda utilizar un sistema de caché en las aplicaciones, para reducir tiempos de lectura, ya que la mayoría de accesos de lectura acceden a una pequeña parte de los datos de la aplicación. Normalmente, hay un conjunto de datos que son relevantes a todos los usuarios y que, por lo tanto, son accedidos con más frecuencia.

• Concurrencia de usuarios: Permitir la concurrencia de usuarios.

Se debe permitir que varios usuarios trabajen en la misma base de datos, protegiendo los datos de ser escritos erróneamente . En la mayoría de los casos, se utilizará el bloqueo optimista, soportado por la mayoría de los motores de persistencia como la opción por defecto.

• Referencias circulares entre objetos: Evitar las referencias circulares entre

objetos de la capa de persistencia. Se deben evitar las referencias circulares, facilitando la localización de los objetos. De esta manera, se devuelve el objeto solicitado sin necesidad de realizar un recorrido para localizarlo, lo que supone un acceso más efectivo.

• Actualización en cascada: Utilizar la actualización en cascada siempre que sea

posible. Utilizar la posibilidad que ofrecen algunos frameworks para la actualización en cascada de objetos. Una actualización en cascada permite que las modificaciones hechas a un objeto se repliquen en l os objetos relacionados . De esta manera se mejora el mantenimiento de los objetos, se asegura que los cambios introducidos se replican de manera eficiente y se mantiene la integridad de los datos . .

17.4 Directrices tecnológicas de IOC Osakidetza dispone de múltiples aplicaciones desarrolladas en diversas tecnologías (principalmente Java y .Net), y albergadas en diferentes plataformas (principalmente Apache HTTP Server, Microsoft IIS y Citrix XenApp como soluciones de presentación, Oracle WebLogic y Microsoft IIS como servidores de aplicación y Oracle RDBMS y Microsoft SQL Server como servidores de BBDD). El modelo de referencia de las aplicaciones es una solución Web (sin plug-in’s), con arquitectura de n-capas preferentemente 3 capas: presentación, negocio y persistencia, compatible con tecnología de virtualización y almacenamiento SAN y NAS. Dicha arquitectura es escalable horizontalmente en cuanto a las capas de negocio y persistencia (reparte la carga equitativamente entre los diversos servidores que ejecutan la lógica de negocio y estos a su vez, mediante un pool de conexiones acceden a la capa de persistencia), y es tolerante a fallos garantizando la continuidad

/75

de negocio. Los servidores que atienden a las capas de negocio y persistencia están ubicados en los dos CPDs de la Dirección General de Osakidetza siendo el reparto de los mismos proporcional en un CPD u otro; la capa de presentación está distribuida en los puestos de trabajo fijos, portátiles, móviles y tabletas en los diversos centros de Osakidetza (Hospitales, Centros de salud, etc.). De modo que la solución (producto/aplicación/desarrollo) a suministrar deberá ser compatible con el modelo de arquitectura indicado en el párrafo anterior y con la relación de productos y tecnologías que se indican a continuación (las que apliquen).

17.4.1 Entorno tecnológico En conjunto, el entorno tecnológico de las soluciones actualmente en producción es:

• Plataformas de desarrollo: � .NET sobre Windows 2012R2 � Java sobre Red Hat Enterprise Linux 7 � Aplicaciones móviles: � Node.js, Express, AngularJS, MongoDB sobre Red Hat Enterprise Linux 7 � Ionic, Cordova sobre Android, iOS o WindowsPhone

• Plataforma de virtualización:

� VMWare vSphere 5.5

• Almacenamiento: � SAN: EMC VPLEX � NAS Hitachi HUS

• Sistemas Operativos

� Servidores: o Windows 2012 R2 o Red Hat Enterprise Linux 7

� Puesto de trabajo fijo: Windows 7 Enterprise N SP1 32 bits � Puesto de trabajo móvil: Android, iOS, WindowsPhone

• Servidores Web:

� Apache Webserver 2.4 � MS IIS 8.5 (S.O. Windows 2012 R2) � Oracle Web Server 11.1.1.7 � Web Dispatcher de SAP Netweaver 7.20 � Nginx 1.8.0

• Servidores de Aplicación:

� Apache Tomcat 7 � Oracle Weblogic Server 12c + JDK 8.0 � MS IIS 8.5 + .NET Framework 4.5 � Application Server de SAP Netweaver 7.X � Node.js 4.1.0

• Sistemas de Gestión de Bases de Datos

� Oracle 12c (RAC) � Microsoft SQL Server 2008R2, SQL Server 2012

/75

� MongoDB 2.6

• Gestión de contenidos: � MS SharePoint 2010 Enterprise � EMC Documentum 7.2

• Infraestructura SOA:

� Oracle Service Bus 12c (12.2.1) + JDK 8.0

• Plataforma de firma (PKI): � Izenpe

• Autenticación:

� Directorio Activo de MS (AD) � Directorio Ligero de MS (LDS)

• Puesto de trabajo fijo:

� Navegador: IE 8.0 � Office 2010 Standard � Oracle Client 11gR2 � Java 1.6.0_23 � Framework 3.5 y 4.0

• Modo de ejecución/escritorio:

� local: puesto fijo o móvil � remoto: Citrix Xen Desktop 7.6

Consideraciones en relación a los de productos y tecnologías indicados anteriormente:

• En cuanto al navegador, se debe evitar el uso de Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador.

• Al respecto de Office 2010, no está permitido el uso, dependencia o interrelación con Access.

• A corto/medio plazo Osakidetza evolucionará: o S.O. de Servidor:

� Windows Server 2008 R2 a Windows Server 2012 R2 o S.O. de Puesto de trabajo:

� Windows 7 a Windows 10 o Navegador:

� IE8 a IE11 nativo preferentemente y Enterprise Mode de IE11 para compatibilidad con IE8.

o Servidor de Aplicaciones: � Weblogic 11g a Oracle Weblogic Server 12c � MS IIS 7.5 a MS IIS 8.5

o SGBD: � Oracle 11g a Oracle 12c � MS SQL Server 2008R2 a SQL Server 2012

o Infraestructura SOA: � Oracle Service Bus 11.1.1.7 a 12c (12.2.1)

17.4.2 Dispositivos de entrada/salida La solución deberá ser capaz de interactuar con diversos dispositivos de entrada y salida de diversos fabricantes; siendo dichos dispositivos: pantallas táctiles,

/75

impresoras térmicas, monitores, por tanto el interface con los mismos será en base a estándares del mercado. Así mismo la solución deberá adaptarse a la resolución de las diversas pantallas. En relación a dispositivos móviles se deben tener en cuenta ciertas particularidades en relación a las características de movilidad, tamaño, comunicación inalámbrica e interacción con las personas:

• Son aparatos pequeños. • La mayoría de estos aparatos se pueden transportar en el bolsillo del

propietario o en un pequeño bolso. • Tienen capacidad de procesamiento. • Tienen conexión permanente o intermitente a una red. • Tienen memoria (RAM, tarjetas MicroSD, flash, etc.). • Normalmente se asocian al uso individual de una persona, tanto en posesión

como en operación, de modo que puede adaptarlos a su gusto. • Tienen una alta capacidad de interacción mediante la pantalla o el teclado.

En lo que se refiere a dispositivos sobre los que tienen que ejecutar soluciones de movilidad hay dos ámbitos que son las soluciones orientadas a profesionales de Osakidetza y soluciones orientadas al ciudadano. Las aplicaciones orientadas al ciudadano se ejecutarán en dispositivos de consumo ya sean móviles, tabletas o cualquier otro dispositivo al que vaya destinada la solución. En este caso el desarrollo deberá ejecutarse en dispositivos con los diferentes sistemas operativos que haya en el mercado. En las aplicaciones orientadas a los profesionales de Osakidetza deberán de ejecutarse en el dispositivo elegido y homologado para soportar la solución. Habrá que tener en cuenta los siguientes aspectos:

• Ergonomía, tamaño y usabilidad del dispositivo, se refiere a que cumpla las expectativas del usuario en ámbito en el que se va a desarrollar el proyecto.

• Especificaciones de limpieza y resistencia a los golpes. • Características de comunicaciones como pueden ser conectividad Wifi y 4G.

17.4.3 Seguridad, acceso, autenticación y autorizac ión El tratamiento de los datos cumplirá lo establecido por la legislación vigente en materia de seguridad y protección de datos. En el ámbito intranet se permitirá el acceso mediante los transportes RMI, JMS, HTTP y HTTPS. El proveedor de servicios de certificación de Osakidetza es Izenpe. Osakidetza ha dotado a todos sus profesionales de certificados corporativos reconocidos, en soporte tarjeta criptográfica, con capacidad de firma de documentos y mails, cifrado y autenticación en el AD. Además, para los nuevos SI que necesitan firma electrónica ágil, Osakidetza ha implantado una solución horizontal de firma, basada en certificados alojados en HSMs, llamada “firma centralizada”. Son certificados con las mismas características y

/75

garantías que los alojados en tarjeta criptográfica. Estos HSM son de última generación y cumplen con las más exigentes normas internacionales (FIPS 140-2 Level 2 and Level 3, Common Criteria at EAL 4+ y RoHS compliant). Permiten la firma a través de CSP propio (applets) y la firma directa basada en una Pasarela de firma propietaria. Izenpe es también el proveedor de la infraestructura de autenticación, validación y firma basada en certificados electrónicos. Osakidetza dispone de 2 Zain en HA (equipos TrustedX de Safelayer) en propiedad y su backup, en modo servicio, en los Zain de Izenpe. La integración con estos equipos se puede realizar mediante su librería Smartwrapper. Provee diferentes servicios web (validación, evolución de firmas, firma en servidor, etc.) alojados en los OSB de Osakidetza . Así mismo, Osakidetza dispone de su propia infraestructura de Custodia de documentos firmados, para asegurar la validación de cualquier firma realizada en sus sistemas de información con certificados electrónicos. Está constituida por 2 equipos Siaval en HA, de la empresa SIA, y HSM Ncipher propios. Para la firma electrónica de documentos in-situ por parte de sus pacientes, Osakidetza dispone de una solución denominada “firma biométrica”, que asegura la validez de todas las firmas implicadas. Se apoya en la solución SmartAccess de Telefónica. Osakidetza está inmerso en la adecuación de toda su infraestructura y sistemas de información al reglamento europeo eIDAS. Tanto en cuestión de certificados como de niveles de aseguramiento (autenticación). Los sistemas de autenticación validos son:

• Autenticación basada en Directorio Activo (Microsoft Active Directory) corporativo, que permite identificar un empleado de Osakidetza mediante usuario/contraseña o la tarjeta profesional.

• Token de Kerberos, que habrá sido emitido por el Directorio Activo corporativo. • Autenticación basada en infraestructura de certificación digital (PKI). Esta

autenticación permite la identificación de personas (certificados personales) o de sistemas de información (certificados de servidor)

• Certificados X.509 de servidor, que permitirán identificar sistemas (máquinas) y establecer confianza entre ellas.

• Certificados X.509 de cliente, que permitirán identificar individuos (personas) • Para los servicios web, el estándar WS-Security permitirá aplicar políticas de

autenticación. • El bus de servicios sólo se utilizará para la autenticación basada en

certificados X.509 de servidor. El sistema de autorización se implementará por medio de la definición de roles de usuario en base a los cuales se gestionarán los permisos y acciones sobre los distintos procesos por los que estará compuesta la solución. De modo que cada usuario en función del rol que tenga asignado podrá acceder a una serie de funcionalidades, así como a los datos relativos a su organización de servicio, centro de trabajo, servicio/área de atención. Se crearán grupos de autorización del Directorio Activo. Por cada perfil que tenga la aplicación (medico, enfermera, administrativo, administrador de la aplicación,…) se creará un grupo de autorización en el DA. Se mapeará el perfil al grupo.

/75

17.4.4 Monitorización Osakidetza dispone de una plataforma de monitorización a través de la cual ya tiene establecida una línea de monitorización base de su infraestructura y SI. En este sentido la solución deberá incluir un apartado en el que se describan los elementos a monitorizar para asegurar un correcto funcionamiento del sistema, servicio o producto suministrado de forma integral dentro de la mencionada plataforma de monitorización. La monitorización se podrá llevar a cabo a través de alguna combinación de los siguientes productos o métodos que Osakidetza integra dentro de su plataforma de monitorización:

• SCOM mediante Management Pack para sistemas Microsoft • Instalación de agente de CA Wily Introscope para tecnología Web • Instalación de agente de Pandora FMS para sistemas Linux, Unix • Enterprise Manager Cloud Control para SGBD Oracle • Mensajes SNMP • Activación de log’s que se enviarán a un servidor virtual dedicado

Con el objetivo de monitorizar la solución que vaya a ser suministrada, deberán detallarse los objetos concretos a monitorizar para garantizar su correcto funcionamiento más allá de los aspectos generales de la infraestructura de sistemas que los alberguen; dicha relación de objetos podrá incluir, aunque no exclusivamente, algunos como:

• Procesos en ejecución • Puertos de comunicaciones a la escucha • Eventos concretos en registros del sistema • Unidades de disco o File Systems

Para cada uno de ellos deberán incluirse los umbrales de consumo que se consideren anormales, especificándose 2 valores a partir de los cuales establecer el correspondiente nivel de alerta preventiva o alerta crítica según proceda. Adicionalmente podrán suministrarse scripts o procesos para llevar a cabo:

• Pruebas sintéticas de los sistemas cuyo resultado determine el correcto funcionamiento del sistema o el correspondiente nivel de alerta preventiva

• Operativas sobre el sistema que puedan ayudar a determinar o especificar la condiciones concretas de los errores o alertas producidos.

• Operativas sobre el sistema para intentar remediar automáticamente la condición de la alerta o error, como reinicio de procesos o servicios, etc.

Todos estos procesos deberán entregarse con su correspondiente documentación, y su operativa deberá resultar sencilla de modo que pueda ser realizada por un operador.

17.4.5 Backup/Restore Osakidetza dispone de una infraestructura para la realización de copias de seguridad y restauración a través de red basada en Veritas Netbackup. De modo que la solución deberá especificar los procedimientos necesarios a llevar a cabo para la recuperación del servicio ante la pérdida del mismo, corrupción de sus datos o alguno de sus componentes. En este sentido se plantearán escenarios de

/75

recuperación independientes para cada uno de los posibles componentes impactados y el orden de ejecución en caso de que deban ejecutarse secuencialmente para la recuperación de varios componentes o del sistema completo en su conjunto. A partir de los procedimientos anteriormente descritos y en cada uno de ellos, se inferirá los elementos concretos sobre los que se requiere hacer Backup, en qué orden, con qué frecuencia y política de persistencia deben llevarse a cabo para poder satisfacer los distintos escenarios de recuperación del servicio contemplados. Así mismo deberán indicarse las restricciones que pudieran existir para la realización del Backup: posible impacto en el servicio, restricciones horarias, etc. Los distintos procedimientos de recuperación suministrados con la solución deberán ser validados por Osakidetza para garantizar su compatibilidad con la infraestructura de copia de seguridad y restauración existente.

17.5 Interoperabilidad Los requisitos de integración de diversos sistemas de información de Osakidetza se realizaran de acuerdo a una arquitectura orientada a servicios (SOA) sobre la plataforma Oracle SOA Suite (Oracle BPEL Process Manager, Oracle Service Bus (OSB), Oracle Business Rules, ...). Dicha arquitectura proporciona una forma bien definida de exposición e invocación de Servicios Web, lo cual facilita la interacción entre diferentes sistemas propios o de terceros. Sobre la misma arquitectura SOA, Osakidetza implementa una solución de integración orientada a Eventos; es un diseño a medida que gestiona un conjunto de sistemas que publican eventos y un conjunto de aplicaciones que se suscriben a determinados eventos. Dicha solución se denomina Gestor de Eventos-Event Manager y es responsable de recibir los eventos publicados, ejecutar las validaciones adecuadas, enrutar y almacenar los eventos para su envío a los subscriptores que estén asociados a cada uno de los elementos recibidos. Relación de estándares de comunicación soportados:

• Protocolos a nivel de mensaje: o SOAP 1.1 y SOAP 1.2 o WSDL 1.1 y WSDL 1.2 Binding o SOAP con Attachments o JSON – REST (para aplicaciones móviles)

• Protocolos de seguridad a nivel de mensaje:

o WS-Security 1.0/1.1 o WS-SecurityPolicy o WS-Policy o WSPolicyAttachment o WS-Security: Username Token Profile 1.0/1.1 o WS-Security: X.509 Token Profile 1.0/1.1 o WSSecurity: SAML Token Profile 1.0/1.1 o WS-Security: KerberosToken Profile 1.1 o WS-Reliable Messaging 1.0 o WS-Addressing o WS-I Basic Profile 1.1

/75

o WSSecurity: JWT Token (aplicaciones móviles en internet)

• Protocolos a nivel de transporte: o HTTP 1.0, HTTP 1.1 o TLS, SSL o Interoperabilidad con registros UDDI v3-compliant o Sistemas middleware basados en JMS/MQ o HTTPS

17.5.1 Servicios Web Los Servicios Web se implementarán de acuerdo con las especificaciones WSDL v1.1, SOAP v1.1, v1.2, JSON-REST (en el caso de aplicaciones móviles), UDDI v2.XX y XML v1.0, con el objetivo de incorporar las recomendaciones de la WS-I definidas en la especificación Basic Profile v1.0, v2.0 y de esta manera asegurar la interoperabilidad entre los sistemas. El estándar de codificación que se utiliza en los mensajes XML es UTF-8. La seguridad aplicada a los servicios web cubrirán los siguientes aspectos:

• Autenticación: Verificar que el cliente (usuario o aplicación) es quien dice ser. La identidad de un usuario se realizará en base a la información presentada por el usuario (usuario/contraseña, certificado, token SAML)

• Autorización: Otorgar acceso a los servicios en base a la identidad del cliente o a los roles asignados.

• Confidencialidad, privacidad: Mantener la información secreta mediante el uso de algoritmos de encriptación estándar de elementos XML.

• Integridad, no repudio: Asegurar que un mensaje permanece inalterado durante la transmisión mediante la firma digital. La firma también valida la identidad del remitente y proporciona una marca de tiempo para garantizar que una transacción no puede ser repudiada más tarde ni por el remitente ni por el destinatario.

Osakidetza usa Oracle Web Service Manager (OWSM) para gestionar y aplicar políticas a los servicios web publicados en la plataforma SOA. La política estándar que Osakidetza ha definido para los servicios proporciona:

• Autenticación mediante certificado x509 • Protección del mensaje mediante firma (sin encriptado)

Existen dos versiones de la política en OWSM, una para servicios y otra para clientes. Para garantizar la interoperabilidad, cada política tiene su versión compatible con tecnología .NET y Java.

• oracle_wss10_x509_token_with_message_sign_service_policy • oracle_wss10_x509_token_with_message_sign_service_policy_net • oracle_wss10_x509_token_with_message_sign_client_policy • oracle_wss10_x509_token_with_message_sign_client_policy_net • oracle_http_jwt_token_server_policy

Los clientes y aplicaciones que acceden a través de internet entran a la DMZ a través del firewall de aplicaciones (WAF). El WAF aplica reglas contra ataques y define patrones de seguridad.

/75

• Es responsabilidad de cada aplicación publicada en la DMZ controlar el acceso y autorizar a los usuarios.

• El OSB de internet publica los servicios a los que pueden acceder las aplicaciones de internet.

• El OSB de internet audita todas las llamadas a los Servicios Web mediante una política propietaria de Osakidetza gestionada por OWSM.

• En el OSB de internet se protegen todos los servicios con la política oracle_wss10_x509_token_with_message_sign_service_policy. Esta política autentica a las aplicaciones mediante certificado x509 y firma el mensaje de petición y respuesta.

• El OSB de internet delega la ejecución a servicios publicados en la Intranet. • En la intranet, se despliegan instancias independientes de servicios web para

dar servicio a las peticiones que llegan desde el OSB de Internet. • Entre el OSB de intranet y el OSB de intranet, se realiza una federación de

servicios con las condiciones de seguridad habituales. Nota: OSB -> Oracle Service Bus 11.1.1.7 -> Paso a OSB 12c

17.5.2 Gestor de Eventos A continuación se describen los requisitos técnicos que tienen que cumplir las aplicaciones para publicar y/o recibir eventos.

17.5.2.1 Estándares de comunicación La mensajería del Servicio Osakidetza se implementará de acuerdo con las especificaciones del estándar HL7 versión 2.XX o con cualquier otro formato propio de Osakidetza ; de esta manera se asegura la interoperabilidad entre los sistemas de información. A continuación se presenta la relación de tecnologías soportadas para la publicación y subscripción a eventos, así como si la modalidad soporta transaccionabilidad y las opciones de seguridad disponibles:

Modalidad Tecnología Transaccional Orden Seguridad

Publicación Mensajería JMS Sí Sí, si el publicador establece el parámetro

UnitOfOrder

Autenticación (user/pass)

Publicación Servicio web No No Ninguna, Autenticación (user/pass) y WS-Security

Subscripción Mensajería JMS Sí Sí. Event Manager garantiza la entrega en el mismo orden

que ha

recibido los mensajes

Autenticación (user/pass)

Subscripción Servicio OSB Sí Sí. Event Manager garantiza la entrega

Ninguna

/75

en el mismo orden que ha recibido los

mensajes

Subscripción Servicio web Sí Sí. Event Manager garantiza la entrega en el mismo orden

que ha

recibido los mensajes

Ninguna, Autenticación (user/pass) y WS-Security

Por cada modalidad y tecnología se deben cumplir unos requisitos técnicos que serán indicados al adjudicatario para la implementación de esta forma de integración.

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

• id : Es el identificador del tipo de evento. Se genera durante el proceso de alta del evento en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el id sea válido.

• correlation : Es un campo libre en el que el publicador del evento indica un

número correlativo relativo a su sistema.

• source : Es el identificador del publicador. Se genera durante el proceso de alta de un publicador en el sistema de administración de Event Manager. Durante el procesamiento de un evento se verifica que el source sea válido.

• timestamp : Lo establece el publicador del evento en el momento del envío.

• metadata : Puede contener un xml que ayude a describir el contenido del

evento. Event Manager puede utilizar esta información para tomar decisiones de enrutado.

• payload : Es el contenido del evento. Puede ser cualquier cadena de texto o

XML.

El resultado devuelto cuando se publica un evento en Event Manager es un XML definido por un XSD, donde:

• uuid : Es un identificador único que se asigna a cada evento procesado por Event Manager.

• processed : true o false, si el evento se ha procesado correctamente o con

errores.

• errorCode : Si se ha producido un error, aqui se informa el código del error.

• errorDescription : Si se ha producido un error contiene la descripción de éste. Se realiza gestión de errores: codificación de errores y descripción de los mismos.

/75

17.6 Explotación Información- Business Intelligence La herramienta usada para desarrollo de tecnología Business Intelligence es Oracle Business Intelligence Enterprise Edition (OBIEE). Esta herramienta es una herramienta web, que está soportada por una cada de presentación en Apache, y un servidor Web (Weblogic). En esta capo web de Weblogic se definen los ROLES de usuario (grupos y perfiles de usuario) que luego se usan para la Seguridad de Acceso a Datos y a partes de la aplicación En este servidor también se alberga el RPD, que es donde se desarrolla toda la metadata y las distintas Áreas accesibles por usuarios. Todos los datos accesibles desde OBI están almacenados en una única BBDD de Producción. Para realizar la carga de datos (Incremental), utilizamos la herramienta de extracción (ETL) en ODI. Para poder realizar las cargas incrementales necesitamos que los orígenes de datos tengan alguna fecha o característica que indique que el dato se ha modificado el día anterior, y así poder hacer cargas de sólo aquello que no existe en destino o se ha modificado. (Un LAST_MODIFIED por ejemplo). Las cargas son normalmente diarias, aunque existen cargas anuales o trimestrales. Versiones utilizadas:

• Motor Business Intelligence o Oracle Business Intelligence 11.1.1.6.2

• Servidor Web

o WebLogic Server: 10.3.5.0

• BBDD (Exadata) o Exadata: Oracle Database 11g Enterprise Edition Release 11.2.0.3.0 -

64bit Production • ETL

o ODI -> Oracle Data Integrator 11g Build ODI_11.1.1.7.0 GENERIC_130302.2156

17.7 Alineamiento con las Directrices Tecnológicas Para verificar que una solución (producto/aplicación/desarrollo) está alineada tecnológicamente con las directrices anteriormente indicadas, se debe entregar cumplimentado el cuestionario detallado en el Anexo II (CET).

/75

18 ANEXO II: CUESTIONARIO DE ESPECIFICACIONES TÉCNICAS (CET)

Este documento, CET (Cuestionario de Especificaciones Técnicas ), contiene un cuestionario para evaluar el grado de alineamiento de la solución ofertada con respecto a las Directrices y Especificaciones Técnicas que figuran en el PBT del expediente de contratación de la solución. Dicho cuestionario servirá de herramienta para la toma de decisiones por parte de Osakidetza a la hora de adjudicar el expediente. De modo que los licitadores deberán cumplimentar dicho cuestionario y adjuntarlo a la oferta junto con el resto de documentación solicitada en el expediente.

18.1 Arquitectura y Tecnología Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.1.1 Tecnologías de desarrollo ¿Qué tecnología/s se han utilizado/utilizarán en el desarrollo de la solución?

- JAVA/JEE - .NET - PHP - Ruby - Python - Scala - JavaScript - Otras:

18.1.2 Frameworks ¿Qué framework/s se han utilizado/utilizarán en el desarrollo de la solución, ya sean full-stack o combinados para las capas de Presentación, Negocio y Persistencia? Añadir la versión.

- Spring Framework (JEE) - Struts 2 (JEE) - Grails (JEE) - JSF (JEE) - .NET Framework (Indicar lenguajes a emplear: C#, ASP.NET, C++, otros) - Symfony (PHP) - Laravel (PHP) - CodeIgniter (PHP) - Yii (PHP) - Zend (PHP) - Ruby on Rails (Ruby) - Sinatra (Ruby) - Django (Python) - Flask (Python) - Play (Scala y Java)

/75

- AngularJS (JavaScript) - EmberJS (JavaScript) - Backbone (JavaScript) - Otros:

18.1.3 Arquitectura de Software ¿Qué patrón de arquitectura de software se ha utilizado/utilizará en el desarrollo de la solución?

- Arquitectura de capas: o C/S (cliente/servidor) o 3 capas (presentación, negocio, persistencia)

- Otro:

18.1.4 Tecnologías de virtualización ¿La solución es compatible con tecnologías de virtualización de infraestructura? En caso afirmativo indique cual y la versión.

- Si o VMWare vSphere o Otra:

- No

18.1.5 Sistemas Operativos ¿Con qué sistemas operativos en cuanto a servidores y equipos de trabajo de usuario final, es compatible la solución? Añadir la versión.

- Servidores:

o Microsoft

o Red Hat

o Otros:

- Equipo de trabajo de usuario final: (PC, portátil, móvil, tableta, …)

o Microsoft Windows

o Android

o iOS

o WindowsPhone

o Otros:

18.1.6 Servidores Web y de Aplicación Si la solución requiere servidores web y/o servidores de aplicación, ¿con qué middleware/s es compatible en cada caso? Añadir la versión.

- Servidor Web:

o Apache Webserver

/75

o Microsoft IIS

o Oracle Web Server

o Web Dispatcher de SAP Netweaver

o Nginx

o Otro:

- Servidor de Aplicaciones:

o Apache Tomcat

o Oracle Weblogic Server

o Microsoft IIS

o Aplication Server de SAP Netweaver

o Node,js (Express, Mongoose, Socket.io)

o Otro:

18.1.7 Sistemas de Gestión de Base de Datos (SGBD) ¿Qué SGBDs son/serán soportadas por la solución? Añadir la versión.

- Microsoft SQL Server o Juego de caracteres: o Modo de autenticación: o Servicios adicionales:

� Integration Services � Reporting Services � Otro:

- Oracle Database o Juego de caracteres:

- Oracle RAC o Juego de caracteres:

- Oracle MySQL - MongoDB - Otro:

¿Cuántos esquemas de Base de Datos usará la solución? ¿Requiere acceder a la Base de Datos por otra vía que no sea a través de la solución?

- Si o Permisos de escritura o Permisos de administración

- No ¿Requiere acceder a esquemas de otras aplicaciones? En caso afirmativo indicar con qué tecnología/producto y versión. - Si

o Streams o GoldenGate o Otro:

- No

/75

¿Cuál es la volumetría de datos aproximada que almacenará la solución en sus esquemas propietarios? ¿Es de esperar un aumento considerable en el volumen de datos almacenados con el transcurso del tiempo? ¿Es necesario realizar una gestión de datos históricos?

18.1.8 Appliances y otros componentes hardware ¿La solución requiere hardware adicional especifico tipo appliance o similar? En caso afirmativo indique características y detalles

- Si - No

18.2 Capa de Presentación Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.2.1 Modelo de Cliente ¿Qué modelo de cliente tiene la solución?

- Cliente ligero - Cliente rico - Cliente pesado

18.2.2 Equipo de trabajo del usuario final

¿Qué tipo de equipo de trabajo requiere la solución?

- Puesto fijo (PC, Portatil): - Puesto movil: (Tablet, móvil):

18.2.3 Modo de ejecución ¿Qué modo de ejecución requiere la solución?

- Escritorio local - Escritorio remoto:

o Citrix Xen Desktop o Otro

18.2.4 Requisitos en el equipo de trabajo del usuar io final ¿La solución requiere instalar algún software en el equipo de trabajo del usuario final?

/75

- Si o Propio de la solución o De terceros (*)

- No (*) Si el software requerido es de terceros, conteste a las siguientes cuestiones: Si la solución requiere el uso de navegador ¿utiliza Applets (Java), componentes ActiveX (.NET), Flash u otras tecnologías que impliquen la descarga y ejecución de software embebido en el navegador? En caso afirmativo especifique.

- Si - No

¿La solución requiere componentes de Microsoft Office? En caso afirmativo indique cual/es y la versión.

- Si - No

¿La solución requiere algún otro software adicional al indicado anteriormente? En caso afirmativo, especifique.

- Si o Equipo de trabajo fijo o Equipo de trabajo movil

- No ¿La solución accede o hace uso de impresoras, escáneres o ficheros del equipo de usuario? En caso afirmativo, especifique:

- Si - No

18.2.5 Cliente Rico (RIA- Rich User Interface) ¿La solución hace uso de algún framework RIA (RichUser Interface)?

- Sí - No

En caso afirmativo, ¿qué frameworks RIA utilizará la aplicación?

- JSF - Java Applet - HTML5 - GWT - Silverlight - Adobe Flex - Ionic Framework - Otros

En caso de utilizar JSF, ¿qué implementación será utilizada? Añadir la versión.

/75

- Mojarra JavaServer Faces - Apache MyFaces - Otros

En caso de utilizar JSF, ¿qué librería/s de componentes o extensiones serán utilizadas? Añadir la versión.

- PrimeFaces - RichFaces - IceFaces - OpenFaces - Otras:

18.2.6 Sistema de Plantillas ¿La Solución hace uso de algún sistema de plantillas?

- Sí - No

En caso afirmativo, ¿qué motor de plantillas utiliza la solución? Añadir la versión.

- Freeemarker - Velocity - Tiles - Otros:

18.2.7 Librerías de JavaScript ¿La Solución hace uso de alguna librería de JavaScript?

- Sí - No

En caso afirmativo, ¿qué librería/s de JavaScript utilizará la solución? Añadir la versión

- jQuery - Dojo - MooTools - Kendo - React - YUI - Prototype - Otros

18.3 Capa de Negocio Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.3.1 Tecnologías para la comunicación entre capas ¿Qué tecnologías utilizará la solución para la comunicación entre capas? Indicar la Versión

/75

- EJBs - Spring Framework - Web Services - Otros

18.3.2 Transacciones ¿La solución hará uso de transacciones?

- Sí - No

En caso afirmativo, ¿qué tecnologías utilizará la solución para gestionar las transacciones? Indicar la Versión

- EJBs - Spring Framework - Web Services - Otros

18.3.3 Escalabilidad ¿La solución soporta ejecución en balanceo de carga sobre múltiples instancias simultáneas?

- Si - No

En caso afirmativo, ¿se requiere persistencia de las sesiones de usuario? (indicar tipo):

- Si o Por IP de origen o Basada en cookies o Otros (indicar):

- No

18.3.4 Requisitos de almacenamiento ¿La solución requiere espacio en disco para almacenar archivos?

- Si - No

En caso afirmativo, indique:

- Tipo de almacenamiento y espacio o SAN, MB/GB/TB: o NAS, MB/GB/TB::

- Tipo de archivos (temporales/persistentes): ¿El almacenamiento ha de ser compartido entre las posibles múltiples instancias desplegadas para la solución?

/75

- Sí - No

18.4 Capa de Persistencia Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.4.1 Método de Acceso a Base de Datos ¿Qué tecnologías utilizará la solución para el acceso a la base de datos? Indicar la versión

- Procedimientos Almacenados - JDBC - ADO (.NET) - Otros

18.4.2 Tecnologías para la implementación de Persis tencia ¿Qué tecnologías utilizará la solución para la implementación de persistencia de datos? Indicar la versión

- GridLink, - JPA/EclipseLink - JPA/TopLink - Hibernate - ADO.NET/LINQ (.NET) - NHibernate (.NET) - Entity Framework (.NET) - Otros

18.4.3 Gestión de Caché ¿La solución utilizará algún sistema de caché para el almacenamiento y manejo de información de alta demanda?

- Sí - No

En caso afirmativo, ¿qué tipo de herramientas se utilizarán a tal efecto?

- OSCache, - EhCache, - EJB Cache - JPA Cache - Memcached - Redis - Varnish - Oracle Coherence (Cluster) - Cache de HTML5 - Otras:

/75

18.5 Elementos de Interfaz de usuario Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.5.1 Dispositivos ¿Con qué tipos de dispositivos de entrada/salida será capaz de interactuar la solución?

- PC - Smartphones (Indicar si requiere uso de teclado y/o pantalla táctil) - Tablets (Indicar si requiere uso de teclado y/o pantalla táctil) - Impresoras - Otros:

18.5.2 Tamaños ¿ A partir de qué tamaño (en pulgadas) se garantiza la usabilidad de la solución?

- 4 pulgadas - 5 pulgadas - 7 pulgadas - 9 pulgadas - 10 pulgadas - 12 pulgadas - Otros:

18.5.3 Resoluciones ¿Qué resoluciones estarán soportadas por la solución?

- 1440×900 - 1280×1024 - 1280×960 - 1280×800 - 1024×768 - 800×600 - Otras:

18.5.4 Navegadores ¿Qué navegadores serán soportadas por la solución? Añadir a partir de que versión estará soportado cada navegador.

- Internet Explorer - Google Chrome - Mozilla Firefox - Microsoft Edge - Opera - Safari - Otros:

/75

18.5.5 Internacionalización y Localización ¿La solución hace uso de estándares de internacionalización (i18n) ?

- Sí - No

¿La solución hace uso de estándares de localización (L10n) ?

- Sí - No

18.5.6 Accesibilidad ¿Cumplirá la solución algunas de las Pautas de Accesibilidad al Contenido en la Web (WCAG)?

- Sí - No

¿En caso afirmativo, qué nivel de conformidad WCAG 2.0 cumplirá la solución?

- A - AA - AAA

18.5.7 Usabilidad ¿Se utilizarán técnicas y/o herramientas para evaluar la Usabilid ad (UX) de la solución?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán a tal efecto?

- Selenium - UsabilityTools - Visual WebsiteOptimizer - Otras:

18.6 Seguridad, acceso, autenticación y autorizació n Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.6.1 Ámbito de uso ¿Cuál es/será el ámbito de uso de la solución desde el punto de vista del usuario final? Indique los que proceda

- Interno – Osakidetza (Intranet) - Externo (Internet/Redes privadas)

o Admin Publica: (especificar)

/75

o Proveedor/Empresa: (especificar) o Ciudadano

18.6.2 Protocolos de Acceso ¿Qué tipos de protocolos de comunicación utilizará la solución?

- HTTP - HTTPS - RMI - JMS - Otros:

18.6.3 Autenticación ¿La solución utilizará algún sistema de autenticación ?

- Sí - No

En caso afirmativo, ¿qué tipo?

- Directorio Activo y/o Directorio Ligero de Microsoft (AD y/o LDS) - Token de Kerberos - Infraestructura de certificación digital (PKI) a través de Izenpe - Certificados X.509 de servidor - Certificados X.509 de cliente - Otro:

18.6.4 Autorización ¿La solución utilizará algún sistema de autorización? En caso afirmativo especifique.

- Si o Grupos de autorización de Directorio Activo de MS o Otros

- No

18.6.5 Firma electrónica ¿La solución requiere el uso de firma electrónica? En caso afirmativo indique qué tipo.

- Si - No

18.6.6 Legislación en materia de seguridad ¿La solución está adaptada al cumplimiento de la legislación vigente en materia de seguridad? En caso afirmativo indique cual/es.

- Sí

/75

o LOPD - Ley Orgánica 15/1999 de Protección de los Datos de Carácter Personal, desarrollada posteriormente por el Real Decreto 1720/2007 de 21 de diciembre. Estatal.

� nivel alto � nivel medio � nivel bajo

o LSSICE - Ley 34/2002, de 11 de julio de Servicios de la Sociedad de información y Comercio Electrónico.

o Otras: - No

18.7 Interoperabilidad Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.7.1 Servicios Web ¿La solución será capaz de integrarse con Servicios Web ? Es decir, será capaz de exponer (capacidad de publicación) y consumir (capa cidad de suscripción) Servicios Web en formato SOAP y REST ?

- Sí - No

En caso afirmativo, ¿qué implementación se utilizará para la publicación de Servicios Web ? Añadir la versión

- JAX-WS - AXIS 2 - WCF - Otras

¿El aplicativo implementará algún protocolo de seguridad para la comunicación en Servicios Web ?

- Sí - No

En caso afirmativo, ¿qué tipo de protocolo de seguridad se implementará para la comunicación en Servicios Web ? Añadir la Versión

- WSS (WS-Security) - SAML - Otros:

18.7.2 Eventos ¿Necesita la solución recibir eventos de otras aplicaciones de Osakidetza ?

- Sí

/75

- No ¿Publicará la solución eventos al sistema de gestor de eventos de Osakidetza para ser distribuidos a otras aplicaciones?

- Sí - No

¿De qué tecnologías hará uso la solución para la publicación y subscripción a eventos?

- Mensajería JMS - Servicios Web - Servicios OSB

¿Qué estándares para el intercambio de información sanitaria soportará la solución? Indicar la versión

- HL7 - DICOM - SNOMED-CT - LOINC - Otros:

18.7.3 Servicios en la Nube (Cloud) ¿La solución hará uso de algún servicio en la nube para almacenar o consumir servicios?

- Sí - No

En caso afirmativo, indique cuáles son dichos servicios en la nube:

18.8 Mantenimiento y Operación Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.8.1 Retrocompatibilidad ¿La solución soporta retrocompatibilidad de versiones?

- Sí - No

En caso afirmativo, ¿de qué tipo? Añadir las versiones soportadas

- Modelo de datos - Componentes de lógica de negocio - Cliente - Otros:

/75

18.8.2 Gestión de versiones ¿La solución soporta actualización de versiones sin corte de servicio?

- Sí - No

18.8.3 Distribución en dispositivos móviles ¿La solución será distribuida en dispositivos móviles?

- Sí - No

En caso afirmativo, ¿de qué manera se llevará a cabo dicha distribución?

- MDM (Mobile Device Management) - Marketplace (Google, Play, Apple Store, etc…) - Fichero con la aplicación empaquetada (APK, etc…) - Otros:

¿Qué tipo de solución se propondrá para movilidad / dispositivos móviles?

- Aplicación nativa - Aplicación híbrida - Aplicación web (adaptada a dispositivos móviles)

Si la solución es nativa, ¿en qué plataformas se llevará a cabo su distribución? Indicar la versión

- Android - iOS - Windows Phone - Otras:

Si la solución es nativa o híbrida, ¿tendrá versión web accesible desde un navegador?

- Si (indicar los navegadores soportados junto a la versión mínima soportada) - No

Si la solución es híbrida, ¿qué frameworks se utilizarán para su desarrollo?

- Ionic Framework - Cordova / PhoneGap - jQuery Mobile - Sencha Touch - Otros:

18.8.4 Acceso e interacción en dispositivos móviles ¿Cómo se efectuará la entrada de datos en el dispositivo móvil?

- Teclado - Pantalla

/75

- Código de Barras - Otros:

¿Cómo se accederá a los recursos hardware del dispositivo móvil?

- De manera nativa - A través de plugins de Cordova / PhoneGap (enumerar) - Otros:

18.8.5 Impresión ¿La solución hace uso de impresión y/o gestión de reports ?

- Sí - No

En caso afirmativo, ¿qué tecnologías de impresión utilizará la aplicación?

- BIRT - JasperReports - ReportServer - Pentaho - FOP - Crystal Reports (.NET) - Otros:

18.8.6 Gestión de Errores ¿La solución hará uso de estándares y/o patrones de software para el contro l y gestión de errores ?

- Sí - No

En caso afirmativo, indique dichos estándares y patrones:

18.8.7 Logs y Trazas ¿La solución maneja algún tipo de fichero de Logs y/o Trazas?

- Sí - No

En caso afirmativo, ¿qué tipo de información se escribe en los ficheros de log y/o trazas?

- Seguridad - BBDD - Errores - Otros

/75

¿Qué librerías/herramientas utilizará la solución para la gestión de Logs y/o Trazas?

- SLF4J - LogBack - Log4j - Apache Commons Logging - NLog (.NET) - Log4net (.NET) - Otros:

18.8.8 Monitorización ¿La solución incluye documentación sobre reglas de monitorización formalmente definidas mediante objetos monitorizables y umbrale s de alerta concretos ? En caso afirmativo especifique.

- Sí - No

¿La solución incluye registro de eventos de error o advertencia en fiche ros de logs o registros del sistema ? En caso afirmativo especifique.

- Sí - No

¿La solución incluye procesos o scripts de pruebas sintéticas mediante l os que se pueda determinar el estado de salud del servicio o sus componentes ? En caso afirmativo especifique

- Sí - No

¿La solución incluye procesos o scripts de remediación automática de condiciones error o restauración del servicio, como reinicio de procesos, servicios, etc. ? En caso afirmativo especifique.

- Sí - No

18.8.9 Backup y Restore Copia de seguridad/Salvaguarda de la solución : ¿La solución incluye documentación sobre los elementos concretos sobre los que se requiere hacer Backup ? En caso afirmativo especifique.

- Sí - No

En caso afirmativo, ¿se incluyen documentación sobre orden de dependencia de los elementos a salvaguardar, recomendaciones de frecuencia y políticas de

/75

persistencia ? En caso afirmativo especifique.

- Sí - No

Restauración de la solución : ¿La solución incluye documentación sobre el procedimiento de restauración del servicio en caso de fallo o corrupción del mismo? En caso afirmativo especifique.

- Sí - No

En caso afirmativo, ¿se incluyen procedimientos de restauración independientes para cada componente de la solución indicando el orden de precedencia de cada uno? En caso afirmativo especifique.

- Sí - No

18.9 Directrices de Desarrollo Marcar y/o especificar lo que proceda en cada una de las cuestiones que se plantean a continuación. Si en alguna cuestión no se indica nada se entenderá que no aplica.

18.9.1 Gestión y Versionado del Código Fuente ¿Se utilizará alguna herramienta para la gestión y versionado del código fuente y como repositorio durante el desarrollo?

- Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán a tal efecto?

- Git - Subversion - Mercurial - CVS - Visual SourceSafe (.NET) - Otros:

18.9.2 Librerías y Ficheros de Configuración ¿La solución hará uso de ficheros de configuración ?

- Sí - No

¿En caso de utilizarse ficheros de configuración , irán empaquetados con la aplicación?

- Sí

/75

- No

¿La solución hará uso de librerías ?

- Sí - No

¿En caso de utilizarse librerías , irán empaquetadas con la aplicación?

- Sí - No

¿En caso de utilizarse librerías que no vayan empaquetadas con la aplicación, será necesaria la creación de una biblioteca con las librerías necesarias en el Servidor de Aplicaciones ?

- Sí - No

18.9.3 Gestión de Dependencias ¿Se utilizará durante el desarrollo alguna herramienta para la gestión automatizada de dependencias, tareas y/o builds ?

- Sí - No


- Maven - Gradle - NuGet (.NET) - Ant - Otras:

18.9.4 Versionado de Binarios ¿La solución hará uso de alguna herramienta como repositorio para el versionado de los binarios (librerías, etc…) del aplicativo?

- Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán para el versionado de binarios?

- Artifactory - Nexus - Archiva - Otras:

18.9.5 Gestión de la Configuración y los Activos ¿La solución hará uso de alguna herramienta para la gestión de la configuración y

/75

de los activos ? - Sí - No

En caso afirmativo, ¿qué herramientas se utilizarán a tal efecto? - Puppet - Chef - Ansible - Salt - Vagrant - Docker - Otras:

18.9.6 Integración Continua ¿Se llevará a cabo algún tipo de Integración durante la fase de desarrollo y mantenimiento del aplicativo?

- Sí - No


- Jenkins - AnthillPro - Team Foundation Server (.NET) - Git - Otras:

18.9.7 Documentación ¿Se adjuntará algún tipo de documentación junto con la solución?

- Sí - No

En caso afirmativo, indicar el tipo de documentación que se entregará junto a la aplicación y el formato:

- Documentación Técnica (formato digital y/o papel) - Documentación de Usuario (formato digital y/o papel) - Otras:

En caso de aportar documentación técnica en formato digital a partir del código fuente, ¿qué herramientas se utilizarán para su generación?

- Javadoc (Java) - Sandcastle (.NET) - Doxygen (.NET) - phpDocumentos (PHP) - Otras

/75

18.9.8 Automatización de Pruebas ¿Se establecerán planes de pruebas unitarias automatizadas con sus correspondientes test (que serán entregados junto a la solución), para asegurar que cada uno de los módulos de código funcione correctamente por separado?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para los test de pruebas unitarias automatizadas ?

- JUnit (Java) - NUnit (.NET) - PHPUnit (PHP) - QUnit (JavaScript) - Otras:

¿Se establecerán planes de pruebas de integración automatizadas para asegurar el correcto funcionamiento del sistema en su conjunto en base a todos los elementos unitarios que lo componen?

- Sí - No

¿Se establecerán planes de pruebas de aceptación automatizadas en forma de un conjunto de pruebas que deberán ser ejecutadas por los usuarios del sistema para validar que dicho sistema cumple con los requisitos de funcionamiento esperado y proceder así a la aceptación del sistema?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para las pruebas de aceptación automatizadas ?

- Selenium - Otras:

¿Se establecerán planes de pruebas de rendimiento y carga automatizadas en forma de un conjunto de pruebas que deberán ser ejecutadas para analizar y medir el desempeño del aplicativo?

- Sí - No

¿En caso afirmativo, qué herramientas se utilizarán para las pruebas de rendimiento y carga automatizadas ?

- JMeter

/75

- BadBoy - HP LoadRunner - Otras:

18.10 Diagrama de Arquitectura Para mejor comprensión de la arquitectura de la solución, adjunte la representación gráfica de las vistas que se indican a continuación:

- Vista lógica

- Vista de implementación

- Vista de despliegue

/75

19 ANEXO III: ESPECIFICACIONES DEL CLIENTE (MAQUETA) Actualmente, la versión de maqueta que se instala en los equipos de Osakidetza es la 2.6; aunque convive con versiones anteriores instaladas.

• Hardware: o Procesador con un mínimo de Tecnología de 45 nm, Caché L2 de 3

Mb. y FSB de 1.066 Mhz. o Memoria RAM 2 Gb o Disco duro 250 Gb o Monitor 19 pulgadas con resolución 1440x900 mayoritaria o 1280x1024.

• Sistema Operativo

o Windows 7 Enterprise N (32 Bit) SP1 + Windows Media Feature Pack1

adquisición e implantación de un sistema de información ... · completar el historial...

Documents