Pliego de Bases Técnicas - Euskadi.eus · Gestión de emisiones de tarjetas 41 3.2.5....

Pliego de Bases Técnicas. Implantación y despliegue de Sistema de Aseguramiento de Base Poblacional i/94

Pliego de Bases Técnicas Implantación y despliegue del Sistema de Aseguramiento con Base Poblacional

Fecha: Junio 2011 Referencia: 047/2011

EJIE S.A.

Mediterráneo, 14

Tel. 945 01 73 00*

Fax. 945 01 73 01

01010 Vitoria-Gasteiz

Posta-kutxatila / Apartado: 809

01080 Vitoria-Gasteiz

www.ejie.es

Este documento es propiedad de EJIE, S.A. y su contenido es confidencial. Este documento no puede ser reproducido, en su totalidad o parcialmente, ni mostrado a otros, ni utilizado para otros propósitos que los que han originado su entrega, sin el previo permiso escrito de EJIE, S.A.. En el caso de ser entregado en virtud de un contrato, su utilización estará limitada a lo expresamente autorizado en dicho contrato. EJIE, S.A. no podrá ser considerada responsable de eventuales errores u omisiones en la edición del documento.

Pliego de Bases Técnicas. Implantación y despliegue de Sistema de Aseguramiento de Base Poblacional 2/94

Contenido

Capítulo/sección Página

1 Introducción 5

2 Objeto del contrato 6

2.1 Objeto y alcance del servicio 6

2.2 Descripción del servicio 6

3 Contenido 7

3.1 Situación actual 7

3.1.1. Gestión de Aseguramiento (Q97B) 9

3.1.2. Gestión de emisión de tarjetas y Cuadro de Mando (Q97A) 31

3.1.3. Comunicación de SIIA con Sistemas Externos (Q97J) 33

3.2 Objetivos a alcanzar 35

3.2.1. General 36

3.2.2. Mapa sanitario y estructura asistencial 37

3.2.3. Gestión de asegurados y no asegurados 39

3.2.4. Gestión de emisiones de tarjetas 41

3.2.5. Integrabilidad, retro-compatibilidad 42

3.2.6. Comunicación 45

3.2.7. Explotación de datos 47

3.2.8. Seguridad 50

3.2.9. Requerimientos técnicos generales 52

3.2.10. Otros requerimientos 56


3.3 Plazos de ejecución requeridos 59

3.3.1. Penalizaciones 59

4 Metodología Aplicable y Entorno Tecnológico 61

4.1 Metodología de desarrollo, normativa y Guía de Estilo 61

4.2 Modelo de aseguramiento de la calidad 64

4.2.1. Nivel de Aseguramiento de la Calidad 64

4.2.2. Controles de calidad (SQA) 65

4.2.3. Metodología de pruebas 65

4.2.4. Indicadores 65

4.3 Herramientas del ciclo de vida de las aplicaciones 66

4.4 Entorno Tecnológico 66

4.4.1. Sistemas de Información de Gobierno Vasco 66

4.4.2. Sistemas de Información de Osakidetza 69

5 Descripción de entregables 74

6 Planificación y Organización 75

6.1 Plan de Proyecto 75

6.1.1. Plan de Entregas e Hitos de Control 75

6.1.2. Diagrama de Gantt 75

6.2 Organización del Equipo de Trabajo 75

6.2.1. Asignación de recursos a fases del proyecto 76

6.2.2. Equipo de Trabajo 76

6.3 Transferencia Tecnológica 79

7 Presupuesto y oferta económica 80

8 Mecanismos de Seguimiento, Control y Supervisión 82


8.1 Mecanismos de Seguimiento y Control 82

8.2 Supervisión del proyecto 82

9 Plazo de ejecución y Plan de Facturación 84

10 Criterios de Valoración 86

11 Garantía y Confidencialidad. 88

11.1 Garantía 88

11.2 Confidencialidad de la información 88

11.3 Protección de datos 89

12 Propiedad intelectual. 90

13 Prestaciones superiores o complementarias a las exigidas 91

14 Estructura y Formato de la Propuesta 92

14.1 Estructura normalizada y contenido de las propuestas. 92

14.2 Formato de la Propuesta. 93

14.3 Sobres y Elementos. 93


1 Introducción

El Departamento de Sanidad y Consumo del Gobierno Vasco dispone de herramientas que dan soporte a diferentes procesos de la Dirección de Aseguramiento, Financiación y Contratación Sanitaria. Dichos procesos permiten la gestión del aseguramiento, la emisión de tarjetas sanitarias en todos sus tipos, el mantenimiento básico de profesionales y la explotación de la información de aseguramiento de la que es responsable.

Está prevista, asimismo, la evolución sobre la relación actual del sistema de información de Aseguramiento con otros sistemas de información del Departamento y de organismos externos (Osakidetza, Sistema Nacional de Salud).

Las aplicaciones anteriores se fueron desarrollando e implantando de forma individual o integrándolas con las existentes en momentos de tiempo diferentes. Las circunstancias de cada momento influyeron en las características de los productos resultantes, tanto desde el punto de vista funcional y tecnologías utilizadas (algunas de ellas ya obsoletas) como en el grado de integración de las mismas con el resto del sistema.

Por todo lo anterior el Departamento de Sanidad y Consumo, en su apuesta por implementar el uso de nuevas tecnologías así como mejorar su atención sanitaria y gestión interna, se plantea la construcción e implantación de un nuevo sistema de información que en el que estén centralizadas e integradas las funcionalidades relacionadas con el aseguramiento y la prestación sanitaria.

El objeto del presente documento es servir de Pliego de Bases Técnicas para la contratación de los servicios y licencias (si aplica) necesarios para cumplir con los requerimientos anteriores.


2 Objeto del contrato

2.1 Objeto y alcance del servicio

De acuerdo a lo indicado anteriormente, el objeto de este pliego es la contratación a una empresa del sector, en modalidad de CONTRATO CERRADO, para la realización del análisis, diseño, construcción y puesta en marcha de los sistemas de información para el despliegue del nuevo Sistema de Información de Aseguramiento Sanitario con Base Poblacional.

Los requerimientos principales que ayudan a concretar el alcance de los servicios a prestar se detallan en el apartado Descripción del servicio. Asimismo, el conjunto de los entregables resultantes de los trabajos definidos como alcance del servicio se explicarán posteriormente dentro del apartado Descripción de entregables del presente documento.

2.2 Descripción del servicio

Para la consecución de los objetivos marcados dentro del apartado de Objeto y alcance del servicio será necesario realizar una serie de tareas que se concretarán en el siguiente apartado de Contenido dentro del presente Pliego de Bases Técnicas.


3 Contenido

3.1 Situación actual

Tal y como se ha comentado en el apartado introductorio, el Departamento de Sanidad cuenta con una serie de herramientas, desarrolladas alrededor del Sistema Integrado de Información de Aseguramiento (en adelante, SIIA), que cubren la funcionalidad necesaria para dar soporte a los procesos relacionados con la gestión del aseguramiento y la tarjeta sanitaria.

Descripción de relaciones


Sistemas de Información


Modelo Tecnológico

A continuación se realiza una breve descripción de cada una de ellas con el objeto de que sirvan para ayudar a entender el ámbito y alcance de los trabajos concernientes a este Pliego de Bases Técnicas.

3.1.1. Gestión de Aseguramiento (Q97B)

Cobertura funcional

La aplicación codificada como Q97B constituye el módulo publicado en Intranet para la gestión del aseguramiento y del mapa sanitario y de recursos, así como la solicitud de ejecución de procesos batch. Dicha aplicación está compuesta por los siguientes módulos:

1) Mantenimiento de catálogos generales

Módulo del aplicativo donde se recogen las modificaciones (alta/baja/modificación) sobre las diferentes entidades manejadas por el sistema. Los catálogos que se mantienen son:


1) Tablas básicas

a) Cobertura sanitaria

b) Régimen

c) Parentesco

d) Zonas básicas

e) Tipo de vía

f) Tipos de usuarios

g) Entidades colaboradoras

h) Tipo de operación

i) Tipo de error

j) Tipo de incidencia

k) Entidades de trabajo

l) Tipo de documento

m) Origen de documentos

n) Tipo de direcciones

o) Tipo de teléfonos

p) Tipo de email

q) Causa de bloqueo de emisión

r) Código en plaza (UAP)

s) Puestos RA

t) Tipo de horario

u) Categorías

v) Subtipo de centro

w) Motivo inactividad colegiado

x) Causa alta/baja afiliado

y) Causa alta no afiliado

z) Causa baja no afiliado

aa) Tipo próxima tarjeta

bb) Error emisión

cc) Municipio TSE ciudadano

dd) Municipio TSE-NR

ee) Colectivos emisión

ff) Comarcas Osabide


gg) Zona básica-comarca Osabide

hh) Causa bloqueo emisión plaza

ii) Bloqueo municipios TIS menores

2) Calles

3) Tipos de Centro

4) Especialidades

2) Mantenimiento de estructura sanitaria

De cara a realizar una gestión de la estructura sanitaria y el mapa de recursos de aseguramiento, el aplicativo posee un módulo para el mantenimiento de determinadas entidades.

Los módulos de mantenimiento son los siguientes:

1) Tramos de Callejero

2) Centros


3) Distrito - Sección


4) Plazas médicas


5) Plazas médicas de Refuerzo


6) Colegiados


7) Servicios

8) Servicios-Centros

9) Causas Modificación Plazas Médicas


3) Extracción de estadísticas online


4) Gestión de aseguramiento

El módulo de gestión de aseguramiento es el núcleo del aplicativo. En él se recogen las siguientes funcionalidades:

1) Consulta de asegurados

La consulta de asegurados se realiza mediante un filtro combinado de diferentes campos. También es posible acceder a la inserción de un registro.


La consulta a través de nombre y/o apellidos incorpora un filtro fonético que evita diferencias en las grafías de los mismos (existencia o no de acentos, grafías con b/v, ch/tx/tz/ts, mayúsculas/minúsculas, espacios, partículas en los apellidos,…). Dicho filtro está adaptado específicamente a las casuísticas encontradas en la población de Euskadi.

Una vez realizada la búsqueda, aparece un listado de asegurados sobre el que se pueden realizar consultas relacionadas con dichos registros:

a) Consulta de asegurados con el mismo número de Seguridad Social

b) Consulta de asegurados con el mismo domicilio de residencia.

c) Baja de aseguramiento.

d) Comparación de dos registros, para la depuración de posibles duplicados

e) Consulta de datos del SNS (en relación con la aplicación Q97J)

f) Consulta de información histórica de movimientos entre plazas médicas.

g) Consulta de direcciones, teléfonos o direcciones de correo electrónico alternativas.

Desde este listado se accederá al módulo de mantenimiento de los datos de aseguramiento así como a una ficha resumen con los datos más importantes.


2) Inserción de asegurado

Se recoge, valida e inserta la información de aseguramiento de un registro. Dicha información se agrupa en tres pestañas: Datos personales, Datos Sanitarios y Otros Datos.

En cada inserción se almacena información histórica de los cambios de aseguramiento y de plaza médica.

Asimismo, se envía información del alta al SNS a través de la aplicación Q97J para su registro.


3) Mantenimiento de datos de aseguramiento

Se recoge, valida y modifica la información de aseguramiento de un registro. Dicha información se agrupa en tres pestañas: Datos personales, Datos Sanitarios y Otros Datos.

En cada modificación se almacena información histórica de los cambios de aseguramiento y de plaza médica.

Asimismo, se envía información de la modificación al SNS a través de la aplicación Q97J para su registro.


4) Baja de aseguramiento

Se recoge, valida y registra la información de inactivación de una persona asegurada.

En cada inactivación se almacena información histórica de los cambios de aseguramiento y de plaza médica.

Asimismo, se envía información de la baja al SNS a través de la aplicación Q97J para su registro.

5) Emisión de tarjetas


Permite la emisión, en una impresora local, de una Tarjeta Individual Sanitaria (TIS) de forma online.

6) Gestión de tarjeta electrónica

Se presenta la información relativa a la Tarjeta Electrónica de la persona asegurada.


7) Histórico de Tarjeta Electrónica

Se presenta la información de las Tarjetas Electrónicas emitidas para la persona asegurada.

8) Consulta de direcciones alternativas

Permite consultar y mantener direcciones postales alternativas para la persona asegurada. Dichas direcciones reciben una categoría para su identificación.

9) Consulta de teléfonos alternativos

Permite consultar y mantener teléfonos alternativos para la persona asegurada. Dichos teléfonos reciben una categoría para su identificación.


10) Consulta de direcciones de correo electrónico alternativas

Permite consultar y mantener direcciones de correo electrónico alternativas para la persona asegurada. Dichas direcciones reciben una categoría para su identificación.

11) Cambio masivo

Permite realizar modificaciones masivas de colectivos de personas a las que se les modificarán los mismos datos con los mismos valores.

Se localizan a través de un filtro propio.


Una vez presentados los datos, permite elegir los registros pasa los que se realizarán los cambios

Finalmente, se eligen los datos que se modificarán.


5) Procesos diarios y Procesos batch

Permite la ejecución de diferentes procesos batch, agrupados en los siguientes tipos:

a) Procesos diarios

b) Mantenimiento

i) Nómina de médicos

ii) Cruce con ficheros externos

iii) Procesos depuración

iv) Ordenación médica

c) Listado / Informes

i) Estadísticas

ii) Listado de afiliación

iii) Listado de históricos

iv) Otros listados

v) Informes de afiliación

vi) Informes históricos

d) Exportación Ficheros

i) Mail

ii) Emisión de tarjetas

iii) Otros procesos

Datawarehouse


Adicionalmente a las funcionalidades mencionadas con anterioridad, asociada a la aplicación Q97B existe un Datawareouse con información detallada y agregada para su explotación, así como la información histórica de sus movimientos.

No es objeto del presente apartado del documento detallar las funcionalidades, dimensiones, etc. contenidas en este Datawarehouse.

Componentes tecnológicos

De modo esquemático, los componentes tecnológicos que conforman la solución anterior se resumen en la siguiente tabla:


Concepto Descripción

Plataforma base • Servidor web: IPlanet

• Servidor de aplicaciones: BEA WebLogic Server 8.1

• Base de datos: Oracle 10g

• Procesos batch: COBOL

• Análisis del Datawarehouse: Business Objects 5.1.7

Integraciones La aplicación Q97B tiene integraciones con los siguientes sistemas externos:

• Sistemas internos del Departamento de Sanidad: A través del acceso al modelo de datos.

• Sistemas de información de Osakidetza

Estado actual de implantación

Todas las funcionalidades comentadas con anterioridad se encuentran productivas y estables.

3.1.2. Gestión de emisión de tarjetas y Cuadro de Mando (Q97A)

Cobertura funcional

La aplicación Q97A permite la gestión y seguimiento de todo el proceso de emisión de tarjetas sanitarias en todas sus modalidades (TIS, ONA, TIES), así como la explotación de un Cuadro de Mando de emisiones y movimientos.

1) Gestión de emisiones

Una vez realizada la solicitud de emisión desde un proceso batch de Q97B, el lote de tarjetas a emitir queda pendiente de ser recogido por la empresa troqueladora. Una vez realizada la emisión de las tarjetas, dicha empresa cerrará el lote, indicando los errores que puedan haberse dado en el proceso.


En el caso de la ONA, la empresa certificadora indica previamente cuáles son las solicitudes de ONA que deben emitirse. El aplicativo registra dichas solicitudes para ser incluidas en un lote en la emisión del Departamento.

2) Cuadro de mando

Permite realizar un seguimiento de las emisiones y los movimientos realizados en un rango de tiempo determinado.


3.1.3. Comunicación de SIIA con Sistemas Externos (Q97J)

Cobertura funcional


La aplicación Q97J permite la relación con el Sistema Nacional de Salud. Según las especificaciones del SNS, las funcionalidades incluidas en esta aplicación son las siguientes:

1) Recepción de notificaciones

Recibe y registra las notificaciones enviadas por el SNS. En fases posteriores está previsto el procesamiento de dicha información, de modo que se ejecuten tareas automatizadas según el contenido de dichos mensajes.

2) Consulta de situación de aseguramiento

Recoge la solicitud del usuario para realizar una consulta online contra el SNS y presenta la información junto con la actual del asegurado en la TIS.



De modo esquemático, los componentes tecnológicos que conforman la solución anterior se resumen en la siguiente tabla:


Concepto Descripción

Plataforma base • Servidor web: Apache 2.X

• Servidor de aplicaciones: BEA WebLogic Server 8.1

• Base de datos: Oracle 10g

Integraciones La aplicación Q97J tiene integraciones con los siguientes sistemas externos:

• Sistemas internos del Departamento de Sanidad: A través del acceso al modelo de datos.

• Sistemas de información del SNS

3.2 Objetivos a alcanzar

La ejecución de las tareas a realizar dentro del ámbito de la futura contratación debe ir encaminada a la consecución de unos objetivos que figurarán como requerimientos a cumplir.

El detalle de las necesidades a cumbrir se determinará en la fase de análisis del proyecto. No obstante, con la finalidad de estructurar de un modo claro los requerimientos a cumplir por el adjudicatario final de la contratación, detallamos los mismos en unas tablas agrupándolos según la siguiente disposición:


3.2.1. General

General

De modo general, el nuevo Sistema de Aseguramiento de Base Poblacional deberá satisfacer los siguientes requerimientos.

ID Requerimiento Requerimiento Descripción detallada

GRAL-001 Conservación de funcionalidades actuales El sistema deberá adaptar la funcionalidad que se realiza en el actual Sistema de Información. En fase de análisis se definirán qué procesos se adaptan y cuáles deberán permanecer. En estos casos, la nueva Plataforma deberá garantizar el uso de estos procesos.

GRAL-002 Historificación. General A efectos de análisis de la información, se deberán proporcionar funcionalidades de historificación de datos que persigan un doble objetivo: • Liberar al sistema on-line de la carga innecesaria en el manejo de estos datos históricos. • Contar con diferentes estrategias de gestión y almacenamiento para los datos históricos Los procesos de historificación de datos deberán ser totalmente parametrizables.

GRAL-003 Historificación. Relaciones entre entidades Dentro de los procesos de historificación, deberán tenerse en cuenta las relaciones de los diferentes objetos entre sí para ofrecer una visión coherente de la información, conservando la relación y coherencia entre los datos existentes actualmente y los que se generen para la nueva plataforma, realizando las adaptaciones/migraciones que fueran necesarias para garantizar este punto.


GRAL-004 Bilingüismo La Plataforma de Tarjeta Sanitaria deberá permitir la consulta de la información tanto en euskera como en castellano, así como la transición entre ambos idiomas a demanda del usuario. También se debe valorar el que se permita el mantenimiento y presentación de la información relativa a catálogos básicos (centros, domicilios,...)

GRAL-005 Filtro fonético El aplicativo, para las búsquedas que así se determinen, deberá contar con un filtro fonético, similar al actual, que recoja aquellos aspectos que se determinen necesarios para simplicar las tareas de búsqueda de las diferentes entidades manejadas por el Sistema de Información.

GRAL-006 Soporte para el despliegue en fases En el caso de que dentro del proyecto se determine necesario un despliegue faseado de la solción, deberá garantizarse el funcionamiento de la solución global, realizando aquellas acciones que se precisen oportunas.

3.2.2. Mapa sanitario y estructura asistencial

Mapa sanitario y estructura asistencial

La Plataforma de Tarjeta Sanitaria recogerá la información relativa al Mapa Sanitario y la Estructura Asistencial. Esta información debe estar validada por las entidades competentes a tal fin, y se aportarán mecanismos para garantizar que resulte correcta y coherente.

Dentro de este apartado se detallan los requerimientos que se deben cumplir.



MAPA-001 Gestión de la estructura sanitaria y asistencial

El sistema dispondrá de módulos específicos para la gestión de la estructura sanitaria y asistencial relativa al aseguramiento. Entre las funcionalidades que deberán recogerse, deberá: • permitir la consulta y el manteniento de las entidades que forman parte de la estructura sanitaria y asistencial en atención primaria: Comarcas de Atención Primaria, Unidades de Atención Primaria, Zonas Básicas, Centros de Atención Primaria, Plazas Médicas, Colegiados, Enfermería,…. • Permitir la consulta y el manteniento de las entidades que forman parte de la estructura sanitaria y asistencial en atención especializada: Organizaciones de servicios, Centros, Servicios,… • Permitir la gestión de dichas entidades, como la organización y agrupación de los mismos, la asistencia de colegiados y personal de enfermería en determinadas plazas, la adscripción de plazas de refuerzo

MAPA-002 Gestión de los datos relativos a domicilios El sistema dispondrá de módulos específicos para la gestión de la información relativa a los domicilios (calles, portales, tramos,…). Para ello, se considera necesario utilizar NORA (referenciada dentro de la sección de Entorno Tecnológico) como repositorio de información correspondiente a la ubicación geográfica. Deberá realizarse una migración de la información actual, relacionandola con la existente en NORA. Entre las funcionalidades que deberán recogerse, deberá: • Creación provisional de entidades (calles, tramos, portales,…) y consolidación de los datos, una vez supervisados por NORA. • Gestión de incidencias e incorrelaciones en la información correspondiente a los domicilios. • Extender a otras entidades (como por ejemplo, centros) la codificación de domicilios.


3.2.3. Gestión de asegurados y no asegurados

Gestión de asegurados y no asegurados

La gestión de asegurados y no asegurados se corresponde con el núcleo central de la Plataforma de Tarjeta Sanitaria. A través de ella, se consultan, mantienen y consolidan los datos relativos al aseguramiento, y que permiten el acceso a los diferentes servicios del Departamento.

Dentro de este apartado se detallan los requerimientos que debe cumplir.


ASEG-001 Población objetivo El sistema recogerá e identificará correctamente toda la población que, de facto, puede acceder a la asistencia sanitaria pública. Dados los tres niveles de personas que se recogerán en la nueva plataforma: . los datos de TIS se consideran propios de la nueva plataforma . los datos de empadronados no asegurados se podrán ir incorporando a la base de datos en función de su relación con ella (nuevas leyes, acuerdos o convenios) . las personas que reciben asistencia en Osakidetza, fuera de esos colectivos, a través de las integraciones con los Sistemas de Información de Osakidetza. Dicho acceso será a datos consolidados, depurados y completos. A través de esta identificación, será posible conocer información de identificación, contacto, derecho, titularidad, situación respecto al aseguramiento,... Se dotarán de mecanismos para todas las operaciones que la Dirección de Aseguramiento y Contratación Sanitaria recoja en su manual de procedimientos.


ASEG-002 Carga inicial de información poblacional La nueva Plataforma recogerá inicialmente toda la información existente en el actual sistema de la TIS, adaptándola en lo que sea necesario. En el proceso de la carga, el sistema dispondrá de procesos que permitan el análisis y depuración de la información existente, en busca de posibles errores en la información, como por ejemplo: • Registros con información clave duplicada, errónea, inválida o inexistente • Registros sin relación aparente (registros huérfanos) o relación incorrecta. • Registros pendientes de validación, formalización, renovación,…

Asimismo, en la fase de análisis de la carga de la nueva plataforma se determinará la necesidad y viabilidad de una carga inicial de la información de pacientes de los Sistemas de Información de Osakidetza. Si como resultado de dicho análisis se determina la conveniencia de dicha carga, ésta deberá contar con mecanismos similares a los mencionados con anterioridad.

ASEG-003 Procedimientos de consulta y mantenimiento

El sistema preverá la posibilidad de que se pueda consultar y mantener la información poblacional. Esta información será accesible desde: . Sistemas de Información del propio Departamento, . Sistemas de Información de otras entidades, habilitados a tal efecto (Osakidetza, SNS,…) ..

ASEG-004 Procesos de extracción de datos y cruce con diferentes orígenes de datos

La nueva Plataforma deberá cubrir las necesidades analíticas de la Dirección de Aseguramiento y Contratación Sanitaria y los agentes que correspondan. Para ello, se deberá tener en consideración el manual de Procedimientos de la Dirección de Aseguramiento y Contratación Sanitaria.


3.2.4. Gestión de emisiones de tarjetas

Gestión de emisión de tarjetas



EMIS-001 Procedimientos de emisión de tarjetas El Sistema contará con procesos para la emisión de tarjetas sanitarias. Se tendrán en cuenta todos los tipos de tarjetas a contemplar, así como las diferentes modalidades de emisión (provisionales, temporales, desplazados, duplicados,…). Los detalles tanto de tipos de tarjeta y de modalidades de emisión se concretarán en fase de análisis, procurando, no obstante, dotar de flexibilidad al sistema para permitir la incorporación de nuevos tipos de tarjetas. A este respecto podrán existir necesidades adicionales que se determinarán en la fase de análisis del proyecto.

EMIS-002 Seguimiento de situación de la emisión de tarjetas sanitarias

Se proveerá de mecanismos para poder determinar la situación de la emisión de tarjetas para su seguimiento, bien sea a través de lotes o de elementos individuales.

EMIS-003 Emisión presencial de tarjetas Se deberá habilitar un proceso para la emisión de tarjetas en puestos determinados a tal efecto y con la garantía de seguridad adecuada. Este proceso obtendrá el mismo resultado que una emisión de oficio habitual.

EMIS-004 Contingencias en emisión de tarjetas El sistema deberá proveer de los mecanismos de contingencia necesarios para cubrir todas las


funcionalidades de la tarjeta y sus posibles usos.

3.2.5. Integrabilidad, retro-compatibilidad

Iintegrabilidad, retro-compatibilidad, calidad de la información



INTE-001 Integración con otros Sistemas de Información

El sistema tendrá que disponer de las integraciones necesarias para garantizar la calidad del dato, así como para poner a disposición de otros Sistemas de Información del Departamento o relacionados esta información, con especial atención a la integración con Osakidetza y el SNS. Las integraciones creadas para garantizar la calidad del dato procurarán realizarse con los poseedores del dato validado, evitando así reproducir errores generados en otros Sistemas de Información. Las integraciones creadas para permitir el acceso a estos datos por parte de otros Sistemas de Información utilizarán los mecanismos de integración disponibles en la infraestructura homoloagada para tal fin dentro de los estándares tecnológicos del Gobierno Vasco. Dichas integraciones deberán construirse de modo que cumplan con los requerimientos de: • Rendimiento • Trazabilidad • Escalabilidad • Robustez


que se requieran en los escenarios funcionales asociados. Se deberán analizar los diferentes tipos de integración: . Sincronía . Síncronos . Asíncronos . Tecnología/paradigma . Servicios . Eventos . Otros aspectos que pudieran surgir.

INTE-002 Integración con otros Sistemas de Información

En la integración con el SNS y con Osakidetza se necesita de un módulo que permita el seguimiento, tramitación y explotación de todos los procesos relacionados con la integración. Deberá proveerse, asimismo, de los mecanismos de contigencia adecuados para prever cualquier circunstancia que pueda afectar la integración.

INTE-003 Retro-compatibilidad con otros sistemas De cara a garantizar el acceso de otros sistemas de información tal como se produce actualmente, el Sistema de Tarjeta Sanitaria deberá prever los mecanismos adecuados a tal fin. Estos mecanismos podrán suponer la replicación de información en otros repositorios a los que se permita el acceso del mismo modo que se hace actualmente.

INTE-004 Integración en los Sistemas Asistenciales de Osakidetza

Dentro de los sistemas asistenciales de Osakidetza deberán llevarse a cabo las siguientes acciones:

• Desarrollo del metamodelo de datos ciudadano/paciente entre el Sistema Poblacional y el Asistencial, incluyendo la definición de los datos mínimos para la sincronización de pacientes/ciudadanos entre BBDD Poblacional y BBDD Asistencial.


• Definición del modelo de dispersión de información entre el Sistema Asistencial y el Poblacional, definiendo las reglas de negocio únicas y coordinadas y los puntos exactos de sincronización junto con el flujo de procesos desencadenados.

• Desarrollo de la solución en función de las reglas de negocio definidas y acorde al modelo de dispersión.

Se incluirán mínimamente las tareas de:

o Adaptación de los sistemas asistenciales para ajustarlos al nuevo modelo de integración-sincronización-dispersión.

o Desarrollo del frontal de servicios Web de la parte asistencial. o Desarrollo de las reglas de negocio acorde a las establecidas en el sistema

Poblacional. o Desarrollo del flujo de procesos desencadenados.

• Cruce de datos entre BBDD Poblacional y Asistencial

Se deberá realizar el cruce de datos e intercambio de información previo al arranque de sincronización.

Nota: Para las modificaciones a realizar en los entornos de Osakidetza se aplicará el entorno tecnológico de Osakidetza explicado posteriormente..


3.2.6. Comunicación

Comunicación

Existen varios actores que intervienen en el flujo de datos de Aseguramiento, desde el propio ciudadano, los centros de Osakidetza, las unidades TIS y Servicios Centrales del Departamento.

La nueva plataforma de Tarjeta Sanitaria, cuya implantación es objeto del presente Pliego de Bases Técnicas, deberá contar con la funcionalidad necesaria que facilite que dichos actores puedan tener un canal de comunicación ágil para dar al ciudadano/paciente una buena Atención Sanitaria.

ID Requerimiento

Requerimiento Descripción detallada

COMU-001 Comunicación. Requerimientos generales Deberá existir un sistema de comunicaciones que cumpla con los siguientes requerimientos básicos: • Permitir el intercambio de mensajes entre los diferentes conjuntos de usuarios: unidades TIS, Servicios Centrales, Osakidetza, SNS y potencialmente, ciudadanía a través de servicios online. • La información deberá poder ir asociada a una modificación concreta del paciente, al paciente en general, o a una situación en general no asociada a la persona. La funcionalidad de mensajería deberá poder realizarse: . directamente por parte de los diferentes usuarios del sistema . mediante el uso de los servicios que se definan a tal efecto por parte de otros Sistemas de Información (para posibilitar la integración con otros, por ejemplo con Osabide AP)

COMU-002 Seguridad y trazabilidad El sistema de comunicación, como el resto de los sistemas, deberá contar con los controles de seguridad y trazabilidad de la información pertinentes. Al ser un sistema que se deberá integrar con


sistemas terceros, las funcionalidades de seguridad y trazabilidad deberán integrarse convenientemente con éstos.


3.2.7. Explotación de datos

Explotación de datos

Una de las partes más importantes de la nueva plataforma será dotarla de las funcionalidades para analizar la información almacenada en cada uno de los módulos que conforman la plataforma global. Para poder realizar un análisis completo, no pueden verse dichos módulos como módulos inconexos sino como una plataforma totalmente integrada. Esta “plataforma integrada” no ha de serlo únicamente entre los diferentes módulos sino también con los sistemas terceros de los que se requiera información o funcionalidad concreta.

Para poder realizar un análisis completo de la información almacenada, será necesario contar con información de los diferentes sistemas transaccionales, historificada o no, así como de información agregada en un Datawarehouse que permita un análisis “multidimensional”. Dicho análisis de la información podrá realizarse a través de informes predefinidos, procedimientos de “Query ad-hoc” o incluso de cuadros de mando.

Los detalles de la explotación de datos necesaria serán definidos en la fase de análisis del proyecto.


EXPL-001 Información del sistema transaccional Todos los módulos a implantar dentro del proyecto deberán contar con funcionalidades de consultas concretas sobre el sistema transaccional, esté esta información en la BBDD de la operativa general o almacenada como histórico. Las consultas y funcionalidades específicas a realizar se concretarán en la fase de análisis del proyecto.

EXPL-002 Integración con otras fuentes de información

Si, para tener una visión completa de la información, se necesita integrarse con sistemas terceros más allá de los diferentes módulos que conformen la plataforma, las funcionalidades de explotación


de datos tendrán que contemplar dichas integraciones.

EXPL-003 Adaptación de procesos del DataWareHouse existente

La nueva Plataforma deberá dar solución a la consulta de información histórica almacenada hasta el momento de la puesta en marcha de la misma. Para ello, deberá prever la continuidad de la información, su homogeneidad y coherencia con la información pre-existente

EXPL-004 Informes. Requerimientos generales El nuevo Sistema de Aseguramiento con base poblacional deberá proporcionar los informes necesarios para cubrir los escenarios de negocio que se definan en la fase de análisis del proyecto. Dichos informes deberán poder realizarse contra los datos de la Base de Datos transaccional (incluyendo los registros historificados) así como contra la información agregada en el Datawarehouse/Datamarts

EXPL-005 Informes. Interactividad Los informes generados podrán ser tanto interactivos como información estática en función de las necesidades de negocio. Estos últimos, a su vez, deberán ser exportables a diferentes formatos como .pdf, .html, etc.

EXPL-006 Informes. Planificación y publicación Aunque esta necesidad deberá concretarse en la fase de análisis del proyecto de implantación, deberá cubrirse el escenario de generación planificada de informes y posterior almacenamiento, envío y/o publicación en un portal de informes.

EXPL-007 Query ad-hoc La información agregada almacenada en el Datamart deberá ser objeto de ser explotada por herramientas de "Query ad-hoc" por los diferentes usuarios identificados en función de su perfil. No obstante, dentro del entregable del proyecto deberán generarse las queries y procedimientos de análisis más habituales para su reutilización por los usuarios que convenga.

EXPL-008 Seguridad La totalidad de la información manejada en la explotación de datos deberá tener los controles de seguridad que se definan: autenticación, autorización, control de acceso a datos, etc.


Asimismo, el acceso a la información deberá cumplir con lo descrito en la LOPD proporcionando, en su caso, las soluciones de auditoría que se definan.

EXPL-009 Uso de herramientas GIS El sistema dotará de herramientas de análisis geográfico de la información, especialmente la que está relacionada con la provisión de servicios (distribución de personas en plazas, ubicación de determinados colectivos, distribución de tarjetas,…)

EXPL-010 Elaboración de cuadros de mando y mecanismos de explotación

El sistema estará provisto de los cuadros de mando y extracciones de estadísticas oportunos para la toma de decisiones y seguimiento de la información almacenada en el sistema. Los cuadros de mando existentes (emisión y movimientos) podrán ser ampliados en su funcionalidad, así como completarse con otros que se consideren apropiados.


3.2.8. Seguridad

Seguridad

Los sistemas de información del Gobierno Vasco incorporan controles de seguridad que cubren los aspectos generales de: autenticación, autorización, control de acceso a datos, etc. Por la naturaleza de los datos a contener en la nueva plataforma, esta característica de seguridad de los sistemas tiene, si cabe, una mayor importancia debiendo cubrir la normativa vigente de la LOPD.

Esta característica de seguridad será transversal a la totalidad de las funcionalidades contempladas dentro de la plataforma y deberá tener la posibilidad de integrarse con los sistemas de seguridad estándar que existen actualmente, como el caso de XLNets.

ID Requerimiento

Requerimiento Descripción detallada

SEGU-001 Controles generales La totalidad de las funcionalidades proporcionadas por cada uno de los módulos deberán contar con el control de acceso que se defina en el análisis funcional garantizando los procesos de: • Autenticación • Autorización • Control de acceso a datos concretos • Auditoría de acceso a la información Los procesos anteriores deberán poder realizarse tanto a través de usuario/contraseña como con certificados digitales.

SEGU-002 Integración con XLNets La plataforma deberá poder integrarse con el repositorio de seguridad horizontal del Gobierno XLNets para la consecución de los objetivos anteriormente mencionados. Si se optara por esta


opción, deberán realizarse los trabajos necesarios para obtener dicha integración.

SEGU-003 Mecanismo de contingencia En aquellos casos que así se requiera, los controles de seguridad deberán proporcionar un mecanismo alternativo a utilizar en escenarios de contingencia, no sólo de Sistemas de Información, sino también ante posibles extravíos de tarjetas, etc.

SEGU-004 Auditoría y trazabilidad Adecuándose a la normativa de la LOPD, los sistemas deberán guardar una trazabilidad de acceso y modificación de los datos albergados por el aplicativo. Para ello, podrán ayudarse de la solución horizontal de Oracle Selective Audit (OSA) para las aplicaciones del Gobierno Vasco.

SEGU-005 Protección de información sensible El sistema deberá permitir la protección de información sensible para determinados colectivos (infancia, maltrato,…) que así lo requiera. La solución propuesta deberá ser lo suficientemente versátil como para permitir la incorporación de diferentes colectivos a esta protección desde la propia plataforma.

SEGU-006 Seguridad. Seguridad perimetral y encriptación de la información.

La solución propuesta a implantar deberá asimismo definir los escenarios de seguridad perimetral, acceso a datos concretos, encriptación de información, etc. La solución propuesta deberá ser validada por los responsables de EJIE a nivel técnico y del equipo jurídico del Departamento de Sanidad para los componentes legales.

SEGU-007 Niveles y mecanismos de exposición de las funcionalidades

Los escenarios de seguridad planteados deberán contemplar no sólo los Sistemas de Información sino también la seguridad y exposición de la funcionalidad a través de los diferentes canales de comunicación.


3.2.9. Requerimientos técnicos generales

Requerimientos técnicos generales

Dentro de este apartado plasmamos los requerimientos tecnológicos generales y tareas asociadas que deben llevarse a cabo por parte del proveedor adjudicatario del presente Pliego de Bases Técnicas.


TECN-001 Arquitectura general del sistema Las ofertas recibidas como respuesta al presente Pliego de Bases Técnicas deberán definir la arquitectura general del sistema propuesto cubriendo: • Plataformas base necesarias y/o compatibles para la solución propuesta: Sistema operativo, Servidores de Aplicaciones, Sistemas gestores de base de datos, etc. • Arquitectura general del sistema: descomposición en capas del sistema, despliegue de los diferentes componentes, exposición de las diferentes funcionalidades, etc. • Entornos contemplados: desarrollo, pruebas, integración, preproducción, formación, etc. • Dimensionamiento aproximado de los elementos físicos necesarios (hardware, almacenamiento, comunicaciones, etc.) para dar soporte a la funcionalidad requerida • Otros aspectos que las empresas ofertantes consideren de interés para la correcta valoración de la oferta. Asimismo, dentro del alcance de las tareas a realizar, deberá terminar de concretarse la arquitectura del sistema adecuándose a las particularidades de los Sistemas de Información del Gobierno Vasco.

TECN-002 Integración en los procesos actuales Si se propone una plataforma que no encaje con exactitud en los estándares actuales de Sistemas


de Información emitido por la Dirección de Informática y Telecomunicaciones del Gobierno Vasco, la propuesta deberá contemplar las tareas necesarias para la incorporación del sistema en los Sistemas de Información y procedimientos de gestión del Gobierno Vasco. Entre otros: • Herramientas de compilación y despliegue • Traspaso entre entornos • Procedimientos de backup y recuperación • Monitorización de los sistemas • Identificación y gestión de incidencias y problemas

TECN-003 Rendimiento y soporte de carga El sistema a implantar deberá ser capaz de soportar la carga y proporcionar el rendimiento necesario. Para ello: • Dentro del proyecto deberán fijarse los SLA requeridos para cada uno de los servicios a proporcionar y, en caso de requerir del uso de servicios de terceros, fijar los SLA requeridos para cada uno de dichos servicios externos. • La plataforma deberá estar diseñada y desarrollada para el soporte de dichos requerimientos. • Los diferentes elementos deberán estar preparados para funcionar en esquemas de reparto de carga para ser capaces de soportar, no sólo los requerimientos derivados de un uso habitual de la herramienta, sino también los "picos" de actividad que pudieran darse. • Dentro de los procedimientos de calidad, deberán realizarse las pruebas de carga y rendimiento del sistema necesarias para garantizar esta condición.

TECN-004 Monitorización y análisis de métricas Con el objeto de analizar y detectar posibles anomalías en el comportamiento del sistema, la nueva plataforma deberá dotarse de sistemas de monitorización y análisis de métricas que permitan realizar las tareas anteriores.

TECN-005 Escalabilidad y procedimiento de gestión de la capacidad

La plataforma deberá ser altamente escalable, tanto desde su diseño como para el despliegue posterior de la misma. Deberá fijarse el procedimiento de escalabilidad así como un procedimiento de "gestión de la capacidad" que permita a los equipos de soporte de sistemas del Gobierno Vasco


realizar las acciones necesarias que sean requeridas para escalar en aquellos casos que así se determinen.

TECN-006 Alta disponibilidad y contingencia La solución deberá funcionar en escenarios de "alta disponibilidad" así como en escenarios de "contingencia". Para ello, además de la preparación de la plataforma desde su análisis/diseño/desarrollo hasta su implantación final, deberán realizarse las adaptaciones necesarias del sistema para la integración del mismo en el Plan de Continuidad de Negocio de los Sistemas de Información del Gobierno Vasco.

TECN-007 Uso de estándares Para la totalidad de la integración, deberán primarse y valorarse el uso de estándares de integración como: • Estándares como HL7 • WS-Profile Esta orientación hacia el uso de estándares no se circunscribirá únicamente al escenario de integración con sistemas terceros sino que aplicará a la totalidad de los componentes de la nueva plataforma.

TECN-008 Uso de sistemas horizontales del Gobierno Vasco

Siempre que sea necesario cubrir determinada funcionalidad, la nueva plataforma deberá primar el uso de los sistemas horizontales del Gobierno Vasco como es el caso de: • XLNets como sistema de seguridad para la autenticación/autorización de los usuarios. • Oracle Selective Audit (OSA) como solución de auditoría de acceso a datos. • Uso de los servicios proporcionados por Izenpe como CA: Firma electrónica, TSA, etc. La imposibilidad de la no utilización de dichos sistemas horizontales, deberá quedar convenientemente justificada en cada caso y validada a posteriori por los equipos de EJIE competentes al efecto.

TECN-009 Multinavegador El sistema deberá soportar la navegación a través de los navegadores actualmente homologados


para desarrollo de aplicaciones del Gobierno Vasco: IE8+, Firefox 3+ entre otros (.


3.2.10. Otros requerimientos

Otros

En este apartado se recogen otros requerimientos que, no pudiendo ser clasificados dentro de ninguno de los grupos anteriores, entran dentro del alcance de las tareas a realizar para dar solución a los requerimientos planteados dentro de este Pliego de Bases Técnicas.


OTRO-001 Definición de modelo y servicios de CAU Para que la nueva plataforma proporcione el servicio demandado en producción deberá contar con un modelo de CAU (posiblemente descompuesto en varios niveles) que proporcionará a las diferentes tipologías de usuarios el soporte demandado. Dentro del alcance de los trabajos a realizar se encontrará la definición de dicho modelo entre los que se encontrarán: servicios a proporcionar, horario del servicio, estimaciones de costes asociadas, etc.

OTRO-002 Despliegue. Plan de despliegue El despliegue de la nueva plataforma de Tarjeta Sanitaria deberá realizarse teniendo en consideración a diferentes actores (centros, unidades TIS, Servicios Centrales, etc.) y factores (estado de los sistemas, despliegue de las comunicaciones). Se requerirá realizar un plan de despliegue. Éste incluirá tanto una estrategia como una planificación, de manera conjunta con los diferentes colectivos implicados.

OTRO-003 Despliegue. Seguimiento del despliegue Una vez definido del plan de despliegue, deberá realizarse el seguimiento correspondiente incluyendo: • Seguimiento del estado de las diferentes tareas


• Detección de problemas o riesgos • Fijar responsabilidades para las acciones correctivas en cada caso • Ejecución de las tareas que, dentro del proceso de despliegue, sean competencia del proyecto a realizar tras la adjudicación del presente Pliego de Bases Técnicas

OTRO-004 Despliegue. Soporte al despliegue Tras la puesta en producción del sistema, y hasta el despliegue final del mismo, deberá existir un equipo de soporte a dicho proceso de despliegue. Dentro de sus responsabilidades estarán las siguientes: • Soporte correctivo de los aplicativos • Soporte adaptativo de los aplicativos • Soporte funcional a los usuarios • Adaptación del sistema para su adecuación a la fase de despliegue

OTRO-005 Formación Deberá formarse a los usuarios finales de los diferentes sistemas de información, así como a los responsables del mantenimiento del mismo. Deberá establecerse, por tanto, un plan de formación e impartirse los cursos o charlas que se fijen dentro de este plan. La formación a impartir no cubrirá a los Centros de Salud aunque, en caso necesario, deberá contemplarse una "formación a formadores" para estos colectivos.

OTRO-006 Acuerdos de Nivel de Servicio La nueva plataforma de Tarjeta Sanitaria, para su correcto funcionamiento, precisa del de sistemas terceros con los que se integrará. Dentro de este ámbito, deberán definirse los Acuerdos de Nivel de Servicio (ANS) necesarios para garantizar un funcionamiento óptimo de la plataforma de Tarjeta Sanitaria.

OTRO-007 Contingencia. Definición y acciones necesarias

La criticidad de la nueva plataforma de Tarjeta Sanitaria precisa de la definición de un plan de contingencia y de unas acciones que deberán llevarse a cabo para que las diferentes situaciones contempladas puedan soportarse. Deberán definirse las diferentes contingencias que pueden darse en los escenarios de negocio


impactados por la implantación de la nueva plataforma, procedimientos a llevar a cabo en cada caso, y dotar a los sistemas de información de las funcionalidades necesarias para poder soportar los requerimientos planteados.

OTRO-008 Licencias y soporte correctivo del producto Si aplicara, deberán proporcionarse (y valorarse) las licencias de producto necesarias más allá del software base ya definido en los estándares tecnológicos del Gobierno Vasco. Asimismo, deberán incluirse los servicios de soporte correctivo posterior y actualizaciones pertinentes como parte del periodo de garantía estándar . Este periodo podrá ser mejorado por el ofertante.

OTRO-009 Conservación de las adaptaciones realizadas

En caso que la oferta recibida oferte un producto final como respuesta al presente Pliego de Bases Técnicas, se deberá garantizar que todas las adaptaciones necesarias que haya que incorporar al producto, deberán de ser realizadas de tal manera que se garantice que no se pierdan al producirse actualizaciones a las sucesivas versiones del producto. Es decir, que si hay que hacer alguna adaptación del producto para ajustarse a los requerimientos y luego la versión del producto cambia, dicha actualización puede y debe seguir funcionando. En caso de no ser así, la empresa ofertante se encargaría de realizar las adaptaciones necesarias nuevamente para que la nueva versión del producto se ajuste a los requerimientos.

OTRO-010 Migración de información existente El sistema deberá recoger toda la información existente en el actual Sistema de Información y adaptarla para el uso en la nueva plataforma de Tarjeta Sanitaria. En el caso de la información relativa a los registros históricos, se deberá garantizar la continuidad entre la información existente y la que se genere a partir de la nueva aplicación.

OTRO-011 Acceso a funcionalidades durante el proceso de migración

El sistema deberá permitir el acceso a todas las funcionalidades existentes actualmente, mientras no se migre dicha funcionalidad a la nueva plataforma de Tarjeta Sanitaria. En el caso de que, por planificación del proyecto, haya funcionalidades que queden sin incorporar a la plataforma de Tarjeta Sanitaria, el sistema deberá permitir su utilización, plenamente integrada dentro del propio Sistema.


3.3 Plazos de ejecución requeridos

Además de los requerimientos técnicos y funcionales planteados anteriormente para la nueva plataforma, existen unos requerimientos de tiempo que los trabajos a realizar deben cumplir. Éstos son los reflejados en la siguiente tabla:

Objetivo Fecha límite

Módulos base implantados en producción 5 meses tras la fecha de arranque del proyecto

Los módulos/funcionalidades base serán los necesarios para el soporte de los requerimientos agrupados bajo los siguientes conceptos:

• General

• Mapa sanitario y estructura asistencial

• Gestión de asegurados y no asegurados

• Gestión de emisiones de tarjetas

• Integrabilidad, retro-compatibilidad

• Seguridad

• Requerimientos técnicos generales

• Otros requerimientos

3.3.1. Penalizaciones

El no cumplimiento de los plazos anteriormente marcados, por razones imputables a la empresa adjudicataria, podrá derivar en la aplicación por parte de E.J.I.E. de una penalización del 2% del monto total del contrato por cada quince días hábiles transcurridos desde la fecha fijada como límite.

La aplicación de penalizaciones se basará en los siguientes puntos:

• Todas las entregas de trabajos de la empresa adjudicataria, serán realizadas según el sistema de calidad de EJIE. Será el documento de entrega y recepción el que se utilice para el cálculo de los días de retraso, no contando esta fecha de entrega en el supuesto de existencias de errores y carencias en los entregables.

• Se marcará como hito de aplicación de penalización la puesta en producción del sistema, marcando como tal fecha la en la que el sistema está listo para proporcionar la totalidad de las funcionalidades


definidas, en un entorno real, a los diferentes actores que intervienen en los diferentes escenarios de Tarjeta Sanitaria. Con respecto a este punto:

o Para la puesta en producción del sistema éste deberá haber pasado por todos los controles de calidad definidos, no siendo motivo justificable para un retraso la ejecución de ninguna de las tareas derivadas de la aplicación de las políticas de calidad (por ejemplo, haber pasado satisfactoriamente las pruebas de rendimiento del sistema).

o Los entornos contemplados para la futura plataforma deberán ser tres: Desarrollo, Preproducción y Producción siguiendo los estándares habituales para los sistemas del Gobierno Vasco. La implantación de la solución y los trabajos asociados en cada caso deberán realizarse en todos ellos y siguiendo este orden, no contemplándose una posible justificación del retraso la aplicación del flujo habitual de los Sistemas de Información para la nueva solución. Un claro ejemplo podría ser la propuesta por parte del proveedor de la implantación del sistema directamente en el entorno de producción.

• Será potestad de EJIE el rescindir unilateralmente el contrato a la empresa adjudicataria si la penalización a aplicar sobrepasara el 40% del importe de los trabajos a realizar.

• E.J.I.E. tendrá la potestad de aplicar la penalización conforme a los parámetros previos de manera unilateral sin ser necesario ningún acuerdo previo con la empresa adjudicataria pero sí una vez haya sido informada esta última.


4 Metodología Aplicable y Entorno Tecnológico

4.1 Metodología de desarrollo, normativa y Guía de Estilo

La organización del trabajo y ejecución del proyecto estará basada en la Metodología de planificación y desarrollo de sistemas de información ARINBIDE. No obstante, será objeto de las primeras fases del proyecto el acordar los diferentes elementos a incluir de manera que se garantice la calidad y control de los entregables pero se adecue mejor a las necesidades concretas del proyecto de implantación y despliegue de la Tarjeta Sanitaria.

ARINBIDE se concibe como una metodología práctica para el ciclo de vida completo del software, basada en Métrica 3, y adaptada a las necesidades y directrices de E.J.I.E. Además consta de un apartado para establecimiento de una metodología de Gestión de Proyectos. Como Plan de Calidad la propia metodología, en sus apartados de trabajo habitual, genera los registros necesarios para el sistema de calidad de E.J.I.E.

Para todo el ciclo de vida del proyecto, ARINBIDE define las siguientes fases metodológicas:

• Gestión del proyecto (GPR)

• Análisis del Sistema de Información (ASI)

• Diseño del Sistema de Información (DSI)

• Construcción del Sistema de Información (CSI)

• Implantación y Aceptación del Sistema (IAS)

• Mantenimiento del Sistema de Información (MSI)

• Gestión de la configuración (GCO)

Información detallada sobre las fases y entregables de la metodología ARINBIDE, se encuentra en la página web de E.J.I.E.: http://www.ejie.net/documentacion.htm

En las distintas fases del proyecto, teniendo en cuenta la mencionada metodología ARINBIDE, y según el alcance de aplicación de la misma acordada entre la dirección del proyecto y la empresa adjudicataria en las fases iniciales del proyecto, ésta última deberá contemplar, entre otros, los siguientes elementos:

• Análisis del sistema. Lo realizará en su totalidad el adjudicatario. Debe incluir:

El catálogo de requisitos y la relación de los módulos del sistema.

Análisis de las aplicaciones, ASI (ERS)

Especificación del Plan de Pruebas resultante de la fase Análisis

• Diseño del sistema. Lo realizará en su totalidad el adjudicatario. Debe incluir:

Diseño de las aplicaciones, DSI.

Especificar el detalle del Plan de Pruebas del sistema por cada uno de los niveles de prueba: unitarias, de integración, de sistema, de implantación y de aceptación

• Construcción del sistema.


Lo realizará en su totalidad el adjudicatario, teniendo en cuenta las directrices de E.J.I.E. en lo que se refiere a los módulos estándar, las normas de funcionamiento y albergue de las aplicaciones en Internet/Intranet, el Manual de Identidad Corporativa del Gobierno Vasco y las directrices de la Oficina para la Modernización de la Administración en lo que respecta a estética, diseño y funcionalidades de las páginas Web.

Incluirá la ejecución del Plan de Pruebas, para verificar el cumplimiento de los requisitos establecidos en el mismo, abarcando pruebas unitarias, de integración y del sistema. Dentro de dicho Plan de Pruebas deberán venir incluidas las Pruebas Unitarias y, en función de las posibilidades de la tecnología propuesta, la ejecución de las mismas deberá estar dotada de cierto automatismo proporcionado por herramientas adicionales, como el caso de JUnit para aplicaciones Java.

Para la identificación de estas herramientas, siempre que sea posible, la empresa adjudicataria deberá restringirse al uso de las herramientas homologas para el desarrollo de aplicaciones en E.J.I.E. a tal fin.

En caso de que las herramientas homologadas en la actualidad no cubrieran las funcionalidades requeridas tanto por la dirección del proyecto en E.J.I.E. como, potencialmente, por el equipo de la empresa adjudicataria, deberán analizarse herramientas alternativas que den soporte a la funcionalidad requerida y utilizarlas en caso de que así se estime conveniente.

El diseño del sistema tendrá en cuenta el nivel de accesibilidad AA (WAI-AA), para aquellos módulos que sean accesibles desde Internet.

Todos los sistemas desarrollados deberán soportar al menos los siguientes idiomas: euskera, castellano.

La aplicación, las páginas, los textos, los mensajes de error/aviso y/o cualquier otro componente (tool-tip, textos en imagen,….) dirigidos al usuario final deberán estar en ambos idiomas: euskera y castellano.

• Implantación en desarrollo.

La empresa adjudicataria llevará a cabo la instalación de las aplicaciones en el entorno de desarrollo de E.J.I.E., habiendo realizado previamente las pruebas necesarias durante la fase de construcción. Para la ejecución de estas pruebas, será necesario tomar como referencia el plan de pruebas definido así como las herramientas automáticas que faciliten aspectos tales como pruebas de regresión en las diferentes entregas/releases.

Siempre que la tecnología de la solución propuesta lo permita, la totalidad de los ficheros necesarios deberán depositarse en la herramienta homologada de Control de Versiones “Subversion” (http://subversion.tigris.org/) previamente a la implantación en el entorno de Desarrollo. Asimismo, se utilizarán las herramientas de control de releases proporcionadas por la herramienta a tal fin.

Los entregables de esta fase incluyen en la Especificación de Construcción del Sistema (CSI) y el sistema implantado.

Ejecución de las Pruebas de implantación, y Pruebas de Aceptación del Sistema, evaluando los resultados


Dentro de este entorno deberá trabajarse con herramientas que faciliten la ejecución automatizada de las pruebas al estilo de la herramienta JUnit para tecnología Java.

El desarrollo o parametrización de la plataforma final deberá tener como uno de sus pilares la construcción de casos de prueba asociados.

Podrá valorarse una estrategia de TDD (Test-Driven Development http://en.wikipedia.org/wiki/Test-driven_development) que garantice un sistema totalmente estable en sus diferentes releases

Las pruebas construidas con estas herramientas deberán ser ejecutadas también en el entorno de preproducción tal y como se detallará posteriormente.

• Implantación en entorno de test o preproducción.

La empresa adjudicataria preparará los paquetes y dará soporte a la realización por E.J.I.E. de la correspondiente implantación en el entorno de test o preproducción, donde se realice el primer test con los usuarios finales de los sistemas.

A fin de realizar las comprobaciones necesarias, en este entorno de preproducción también deberán realizarse la ejecución de las pruebas automatizadas con las herramientas concretas que se acuerden (JUnit para tecnología Java o equivalentes).

En caso de considerarse necesario, se llevarán a cabo las Pruebas de Aceptación en este entorno.

• Pruebas de carga y rendimiento:

Que incluye la verificación de los niveles de respuesta de la aplicación ante las previsiones de carga del sistema. Asimismo se verificará su comportamiento global en cuanto a consumo de memoria y CPU de los componentes que lo forman.

Las pruebas de carga y rendimiento serán de obligando cumplimiento para la empresa adjudicataria debiendo ejecutarse éstas contra el entorno de preproducción. La ejecución de estas pruebas de carga y rendimiento potencialmente podrán ser requeridas para cada una de las diferentes releases del producto. No obstante, será dentro del proyecto donde la empresa adjudicataria y el responsable del mismo por parte de EJIE marquen una política de ejecución de dicho tipo de pruebas.

• Implantación en producción y puesta en marcha del sistema. Incluirá:

Fuentes de la aplicación.

BBDD: scripts y carga inicial de datos.

Sistema implantado en entorno pruebas de E.J.I.E.

Informe de pruebas unitarias y de integración.

Manual de instalación / Explotación.

Manuales de Usuario y la Ayuda On-line deberán estar en ambos idiomas: euskera y castellano.

Formación a los usuarios, administradores del sistema y equipos de desarrollo encargados del mantenimiento de la plataforma en el futuro.


Sistema implantado en entorno de producción.

Ejecución del resto de tareas necesarias para el cumplimiento de los requerimientos especificados en el apartado Objetivos a alcanzar.

En todas las fases del proyecto, así mismo será de referencia el documento de Estándares de desarrollo de sistemas software, que establece requisitos obligatorios y recomendaciones a seguir en todo el proceso de ejecución del proyecto, en cuando a la elaboración de los productos y la entrega de los mismos a E.J.I.E.

Igualmente será de referencia el Documento de Estándares Tecnológicos de Gobierno Vasco, publicado en: www.euskadi.net/informatika

4.2 Modelo de aseguramiento de la calidad

EJIE contempla la calidad en distintos ámbitos de aplicación, tanto calidad en los procesos como calidad en los productos.

Para asegurar la calidad en el proceso de gestión del proyecto, durante le ejecución del mismo el adjudicatario deberá contemplar y proveer la documentación que sea requerida en cumplimiento de la metodología ARINBIDE.

Por otro lado, con el objetivo de asegurar la calidad en el proceso de elaboración y la calidad de los productos software obtenidos, será de referencia obligatoria el modelo de aseguramiento de la calidad definido por E.J.I.E. en el documento Estándares de calidad de producto software. v1.3, que contempla:

• Asignación del Nivel de Aseguramiento de la Calidad (NAC) del sistema a desarrollar

• Definición de los controles de calidad a ejecutar, en base al NAC asignado

• Metodología de pruebas y calidad del software elaborada por E.J.I.E, que define el desglose de fases, actividades y tareas así como el conjunto de entregables a elaborar para el aseguramiento de la calidad del sistema.

• Obtención de Indicadores NAC, que define un conjunto mínimo de indicadores que toda aplicación bajo estándares tecnológicos deberá satisfacer, así como el procedimiento y herramientas para obtenerlos.

En este ámbito de definición de la calidad, será de referencia el documento de Aseguramiento de la Calidad de Sistemas Software v1.0, así como la Metodología de Pruebas v1.0.

A continuación se detalla el modelo de aseguramiento de la calidad establecido para el proyecto objeto de contratación.

4.2.1. Nivel de Aseguramiento de la Calidad

El NAC asignado para este proyecto es: ALTO.


4.2.2. Controles de calidad (SQA)

En función del NAC asignado, se han definido una serie de controles de calidad, cuya ejecución es obligatoria o recomendada, tal y como se define en el documento de Aseguramiento de la Calidad de Sistemas Software v1.0.

El adjudicatario deberá contemplar la ejecución de estos controles de calidad, dentro del alcance del proyecto objeto de contratación. Asimismo, existirá dentro de la gestión del proyecto una Oficina Técnica que supervisará los trabajos realizados por le empresa adjudicataria tal y como se explicará posteriormente en el apartado Metodología de pruebas del presente Pliego de Bases Técnicas.

4.2.3. Metodología de pruebas

Dada la existencia de una Oficina Técnica adjunta a la dirección de proyecto en EJIE, paralela y ajena al presente pliego de contratación, la ejecución de la Metodología de Pruebas será preceptiva y responsabilidad de dicha Oficina Técnica. No obstante, el adjudicatario del presente pliego deberá por tanto trabajar en coordinación con la citada Oficina Técnica, facilitando los entregables y la información necesaria que sean requeridos en las distintas fases del proyecto así como realizando las acciones que sean necesarias para el aseguramiento de la calidad de los entregables, sean estos documentos, aplicativos software o cualquiera que se defina como tal dentro del alcance del Pliego de Bases Técnicas.

Con independencia de lo aquí especificado, se recuerda que la metodología de desarrollo ARINBIDE incluye tareas y actividades destinadas a la ejecución y gestión de pruebas, cuyo cumplimiento está implícito en el proyecto objeto del presente pliego.

4.2.4. Indicadores

Aunque la propia Metodología de Pruebas ya define un conjunto completo de indicadores y sus umbrales asociados, existe un conjunto básico de indicadores que toda aplicación a implantar en el entorno de GV-EJIE deberá satisfacer.

En el entorno de desarrollo, para obtener los resultados de los indicadores para el proyecto se deberán seguir las instrucciones marcadas en el documento Indicadores_NAC.Desarrollo v1.0, en el que se especifican detalladamente los pasos a realizar y las herramientas a utilizar en cada momento.

El adjudicatario del presente contrato deberá contemplar la ejecución de las tareas necesarias para la obtención de estos indicadores, dentro del alcance del proyecto objeto de contratación.

Igualmente, como parte del aseguramiento de la calidad, se ha definido para el entorno de pruebas (pre-producción) el documento Indicadores_NAC.Pruebas v1.0. El adjudicatario del presente contrato deberá suministrar toda la información y entregables que sean requeridos en este ámbito para la realización de las pruebas por parte de EJIE.

La mayor parte de las herramientas detalladas en los documentos de indicadores mencionados anteriormente circunscriben su ámbito de aplicación a las tecnologías mayormente utilizadas en la actualidad en la construcción de Sistemas de Información del Gobierno Vasco (J2EE y .NET). Siempre que dichas herramientas sean aplicables su uso deberá primar sobre cualquier otro.


No obstante, el presente Pliego de Bases Técnicas contempla la posibilidad de presentar soluciones basadas en tecnologías actualmente no estándar. En estos casos el adjudicatario, dentro de la propuesta a presentar como respuesta a este Pliego de Bases Técnicas, deberá proponer el uso de tecnologías y herramientas alternativas. El uso de una herramienta u otra en cada caso deberá ser acordado con E.J.I.E.

4.3 Herramientas del ciclo de vida de las aplicaciones

Como soporte e instrumento necesario en la ejecución de todas las fases del proyecto, existe un conjunto de herramientas homologadas por E.J.I.E., que abarcan todo el ciclo de vida de las aplicaciones, y que facilitan la realización de distintas tareas y normalizan la obtención de entregables.

Estas herramientas homologadas son las que se utilizan en el entorno de trabajo de E.J.I.E., no pudiendo utilizarse en el mismo otras herramientas similares o equivalentes.

Para los trabajos a realizar en las dependencias del proveedor, su uso es recomendado frente a otros productos o herramientas del mercado, para dar cobertura a los cometidos para los que están destinadas. No obstante, en los casos en los que el resultado de uso de las herramientas sea un entregable con un formato específico y normado, su uso será obligatorio frente a otras herramientas de mercado, o bien en cualquier caso deberá proporcionarse un formato compatible.

En el documento PBT-Anexo Herramientas v1.0 se detallan las herramientas homologadas.

No obstante, el presente Pliego de Bases Técnicas contempla la posibilidad de presentar soluciones basadas en tecnologías actualmente no estándar. En estos casos el adjudicatario, dentro de la propuesta a presentar como respuesta a este Pliego de Bases Técnicas, deberá proponer el uso de tecnologías y herramientas alternativas. El uso de una herramienta u otra en cada caso deberá ser acordado con E.J.I.E.

4.4 Entorno Tecnológico

4.4.1. Sistemas de Información de Gobierno Vasco

El entorno tecnológico base será el definido en los estándares del Gobierno Vasco que se consideren necesarios para la ejecución de este proyecto conforme a sus características específicas. No obstante, se considera la posibilidad de presentar soluciones alternativas más allá de las especificadas. En este caso, el grado de similitud de la solución presentada en la oferta con los estándares y la arquitectura general de los sistemas de información del Gobierno Vasco, será tenido en consideración a la hora de valorar la solución propuesta.

Sistemas horizontales

Dentro de los estándares, existe un conjunto de utilidades y sistemas horizontales de uso corporativo que dan solución tecnológica a distintos ámbitos funcionales de uso común, que se citan a continuación, y que el proyecto objeto de contratación deberá contemplar según sus necesidades.


Para las áreas funcionales de tramitación de expedientes del sistema final se deberán seguir las directrices marcadas por el modelo básico de tramitación (MBT) del Gobierno Vasco, es decir, identificar la familia a la cual pertenece el procedimiento a mecanizar, recoger los datos mínimos definidos como invariantes de información, modelar los trámites establecidos como invariantes de tramitación, e informar al sistema de visión de ciudadano (Mis Gestiones). Además, con objeto de simplificar y homogeneizar los puntos de acceso y las interfaces gráficas de usuario, y de asegurar una correcta interpretación de las normas legales vigentes, el nuevo producto deberá hacer uso del conjunto de módulos y sistemas comunes que constituyen el núcleo de elementos corporativos horizontales de base de plataforma tecnológica de e-Administración, PLATEA, desarrollando y completando por lo tanto todo aquello que dichos sistemas requieran:

• Sistemas de infraestructura de tramitación, PLATEA-Tramitación. Permiten ofrecer al administrado una visión homogénea de los procesos de tramitación gestionados por cualquier departamento de Gobierno Vasco, facilitar al empleado público las herramientas básicas y únicas de gestión de tareas de tramitación, definir y establecer los flujos de tramitación adscritos al modelo básico de tramitación, y aportar las soluciones técnicas necesarias que garantizan el cumplimiento de las normativas y procedimientos legales vigentes en materia de tramitación.

Para la publicación de contenidos y aplicaciones en internet, deberá seguirse la normativa corporativa así como las herramientas de soporte al modelo de presencia en internet:

• Herramientas de gestión de contenidos, portales, ejes de catalogación y buscador: PLATEA-Internet. Gestionan la creación, publicación y mantenimiento de contenidos en los portales de internet administrados por Gobierno Vasco, y su catalogación en ejes homogéneos que faciliten su búsqueda. Facilita igualmente los mecanismos para la integración de las aplicaciones en la propia infraestructura de portales.

Como plataforma de integración entre sistemas:

• La infraestructura de integración. Simplifica y estandariza los modelos de intercambio de datos y de procesos entre aplicativos, proporcionando para ello las herramientas y sistemas necesarios para su implementación en base a una plataforma tecnológica unificada, normalizada y compartida. Ofrece soluciones corporativas para el intercambio síncrono de información (exposición de servicios por medio de adaptadores), y el intercambio asíncrono (propagador-enrutador), así como la creación de procesos orquestados. Asimismo, incluye herramientas de replicación de datos.

Como referencia obligada respecto a los ámbitos mencionados, deberá considerarse el documento PLATEA – Plataforma Tecnológica para la e-Administración.

El sistema final deberá valorar la utilización del sistema de seguridad homologado en el entorno de Gobierno Vasco:

• XLNets. Gestiona los procesos de autenticación y autorización de accesos a usuarios (y sistemas) para aplicativos y recursos, desarrollados bajo distintas tecnologías.

Para los desarrollos basados en entorno tecnológico J2EE, en todas las fases de desarrollo del nuevo sistema se deberá contemplar el framework J2EE homologado en el entorno de Gobierno Vasco:

• Geremua. Capa software entre una aplicación y el software de base (sistema operativo, máquina virtual, bases de datos, middleware) que ayuda a resolver problemáticas comunes a gran cantidad de aplicaciones. Se consigue acelerar los tiempos de desarrollo y mejorar la calidad del software, e incluso el rendimiento, pues también marca una tendencia arquitectural hacia las mejores prácticas de diseño y desarrollo.


Para las necesidades de gestión documental, deberá valorarse el uso el sistema corporativo existente:

• Dokusi. Sistema Integral de Gestión Documental cuyo principal objetivo es la implantación de todas las funciones de gestión documental necesarias en los procesos de producción administrativa. Expone su uso a las aplicaciones departamentales mediante su capa de servicios - framework de servicios documentales – FSD, proporcionando además otras utilidades para la carga masiva de documentación, e interfaces gráficas.

En el documento PBT-PLATEA-Anexos v2 2 se anexa explicación detallada de los sistemas corporativos involucrados en PLATEA.

Como solución corporativa de información de datos de localización:

• NORA. Sistema horizontal de gestión de datos de localización –dirección postal-, que proporciona información actualizada y normalizada hasta nivel de portal. Ofrece diversas alternativas tecnológicas de uso, y como principal valor añadido aporta el tratamiento de Altas Provisionales, solución que permite a las aplicaciones asegurar la normalización de los datos de su negocio, y a su vez favorecer la actualización continua de la información. Incluye además información geográfica. En el documento PBT-Anexo NORA v1.0 se detalla información de referencia acerca del sistema.

Para facilitar el tratamiento de pago telemático del ciudadano a la administración:

• Pasarela de pagos: Sistema que provee los servicios necesarios para gestionar peticiones de pago generadas por la administración para el ciudadano, incluida la aplicación internet de pago electrónico on-line u off-line. En el documento PBT-Anexo Pasarela de Pagos v1.0 se detalla información de referencia acerca del sistema.

Otros productos y soluciones corporativas existentes son los siguientes:

• Gestión de procesos batch:

o K31/O75: Soluciones corporativas para la ejecución de procesos desasistidos

o CONTROL-M: Planificación de procesos batch

• Generación de informes:

o JReport. Existe un middleware corporativo (T43) para uso por las aplicaciones departamentales, con tecnología J2EE.

o Reporting Services (Microsoft)

• Business Intelligence:

o Bitam Artus

• Sistemas de Información Geográfica:

o GIS Corporativo, basado en productos ESRI (ArcIMS, ARcSDE, ArcView)

Plataformas tecnológicas


Además de los sistemas horizontales especificados, el nuevo sistema, según sus necesidades, deberá utilizar los módulos y servicios establecidos por el Plan de Informática y Telecomunicaciones del G.V. y especificados en el documento de guía de estándares tecnológicos: EJIE S.A., Sociedad Informática del Gobierno Vasco - Estándares.

En todos los casos, y según corresponda al entorno tecnológico a utilizar, se utilizarán igualmente las Herramientas del ciclo de vida de las aplicaciones. En el documento PBT-Anexo Herramientas v1.0 se relacionan las herramientas homologadas.

Existe asimismo un conjunto de librerías software homologadas, recogidas en los manuales de albergue de aplicaciones, que deberán contemplarse según corresponda, en el proceso de diseño técnico y construcción del sistema (Izenpe, FOP, POI, LinearBarCode, JfreeChart, IAIK, …)

4.4.2. Sistemas de Información de Osakidetza

Este apartado únicamente es aplicable al requerimiento “INTE-004”

4.4.2.1 INTRODUCCIÓN

Osakidetza, dispone de un conjunto de aplicaciones asistenciales sobre las cuales da soporte a su actividad, siendo la Gestión de Pacientes, un módulo trasversal utilizado por todas las áreas de negocio.

La gestión del Servicio de Mantenimiento y Evolución de estas Aplicaciones y sistemas de información, en adelante SMEA, está adjudicado a un único proveedor, siendo la Subdirección de Informática y Sistemas de Información de Osakidetza, quien mantiene las funciones de control, dirección y de relación con el negocio, garantizando el compromiso de los niveles de servicio.

Dado que dentro del alcance del presente expediente se incluyen también las adaptaciones que sobre el software de Osakidetza fueran requeridas para la implantación del nuevo SI, será necesario que el equipo de trabajo ofertado para las tareas de integración con Osakidetza, trabaje de forma coordinada con el equipo de SMEA de ésta.

Es por ello que el equipo propuesto por los licitadores para el desarrollo de la integración con Osakidetza, deberá trabajar con la metodología, procedimientos y en la ubicación indicada por este Ente, integrándose como parte activa del equipo de SMEA durante el desarrollo de las tareas de integración requeridas.

4.4.2.2 ESPECIFICACIONES TÉCNICAS

4.4.2.2.1 Infraestructura

Osakidetza proveerá la infraestructuras (hardware y software) necesarias para facilitar la prestación del servicio a los entornos de Pre-producción, Producción y Formación.

Puesto que el equipo de trabajo desarrollará su trabajo en oficinas propias, el adjudicatario deberá asumir la instalación de las infraestructuras requeridas para el desarrollo del servicio, esto incluye:


• Aislamiento total (desde nivel de red) de los puestos informáticos del equipo de trabajo del resto de la red del adjudicatario.

• Dotación de línea dedicada, de caudal suficiente, para la conexión a los entornos de preproducción, producción y formación necesarios.

4.4.2.2.2 Estándares

Se describen, a título informativo, los estándares actuales, si bien estos podrán ser modificados por la Osakidetza durante el contrato.

4.4.2.2.2.1 Estándares de arquitectura de sistemas

4.4.2.2.2.1.1 Estándar para aplicaciones corporativas

Arquitectura en tres capas: presentación, aplicación y base de datos.

• Capa de presentación:

� Se ejecutará principalmente en un navegador, considerándose siempre como necesarios para la certificación de cualquier sistema las versiones de

• Microsoft Internet Explorer 7 o superior

• Mozilla Firefox 3.5 o superior

• Google Chrome 7 o superior

• Safari 4 o superior

• Opera 10 o superior

� Deberá de garantizarse el funcionamiento correcto sobre sistemas operativos abiertos o propietarios, aunque éstos se encuentren virtualizados.

� Se deberá hacer uso de un framework RIA basado en HTML y javascript como ZK Direct RIA, Vaadin, SproutCore, RAP, GWT, etc...

� En caso de necesidad, se deberá justificar si una aplicación debe alcanzar un nivel de accesibilidad AA. La funcionalidad descrita de presentación se podrá realizar en servidor y el HTML entregado al cliente cumplirá los niveles de accesibilidad definidos por la WAI (Iniciativa de Accesibilidad Web).

� También se debe de prever la necesidad de presentar la capa de presentación en dispositivos móviles.

• Lógica de negocio (capa de presentación y servidor de aplicaciones):

� S.O. Linux Red Hat 4 update 5 o Red Hat 5 update 3

� Oracle WebLogic Server 10.3.3 o superior


� Apache HTTP Server 2.2 o superior

� Tomcat

� SOA Suite 11g (BPEL)

• Base de Datos:

� S.O. Linux Red Hat 4 update 5 o Red Hat 5 update 3

� Oracle 10.2.0.3 / 10.2.0.4 / 11g

� MySQL Server

4.4.2.2.2.1.2 Estándar para entornos Windows

• Estándares software para Servicios Web (.NET):

� Lógica de negocio (capa de presentación y servidor de aplicaciones):

• S.O. Windows 2002 o superior

• IIS 6.0 (el que viene con Windows 2002) o superior

� Base de datos:

• S.O. Linux Red Hat 4 update 5 o Red Hat 5 update 3

• Oracle 10.2.0.3 / 10.2.0.4 / 11g

• MySQL Server

• Estándares entorno Citrix:

• Servidor de Aplicaciones: Citrix Presentation Server 4.5 sobre Windows 2003 Server o superior.

• Cliente Citrix. Versión 11.2 o superior

• Estándares de Aplicaciones .net - C/S:

• Microsoft Windows Server 2008 R2/64 bits

• IIS 7.5

• Microsoft .NET Framework v2.0.50727 / 4.0 - 64 bits

• ODP.NET 32bits/ 64 bits

• Windows AppFabric

• Visual Basic 6.0


• Servidor de Caché/SQL Server:

• Microsoft Windows Server 2008 R2/64 bits, Enterprise Edition

• Microsoft SQL Server 2008 Enterprise Edition 64-bits

• Estándares Centura:

• Unify Team Developer 5.2 version del parche 2

• Cliente Oracle 10

• Client Access AS/400 IBM

4.4.2.2.2.1.3 Estándar de arquitectura física de sistemas

• Entornos de pre-producción (certificación), producción y formación.

• Capa de presentación y de negocio en alta disponibilidad: servidores (blades) balanceados vía hardware

• Aceleradores criptográficos (finalizan sesiones SSL)

• Arquitectura de seguridad: DMZ

• Cluster de firewalls

• CPD de contingencia: réplica física de cabinas de almacenamiento a través de enlace dedicado (DWDM) Fibre Channel

• Flujo de acceso a aplicaciones diferenciado entre usuarios internos (conectados a red sanitaria) y usuarios externos (acceden a las aplicaciones desde Internet vía proxy inverso).

4.4.2.2.2.2 Estándares de desarrollo

La estrategia en materia de desarrollo de Osakidetza, se orienta 2 plataforma diferenciadas, plataforma J2EE y .NET, que se gestionan de forma centralizada, de tal manera que dicha aplicación cumpla los requisitos fundamentales que a continuación se detallan:

• El sistema de información deberá de estar diseñado sobre una arquitectura n-capas.

• El cliente será un cliente ligero, es decir, un navegador Web

• Se puede requerir que la aplicación se ejecute y sea practicable en navegadores web de dispositivos móviles, por lo tanto, el framework de renderizado debe de representar la aplicación en base al soporte.

• En casos concretos y por necesidades propias del proyecto, el cliente puede requerir un interfaz de usuario altamente interactivo. Para estos casos, se puede implementar un cliente rico basado en tecnologías como: RCP, Open Laszlo, Flex, etc.

• El sistema de información se deberá desarrollar sobre la JDK 1.6 o superior.


• Se debe usar un framework MVC para aplicaciones web: JSF, Oracle ADF, Spring MVC Framework, Struts2, etc.

• Utilización de una capa de persistencia para la plataforma Java EE y conforme al estándar EJB3: Hibernate, TopLink, Kodo, OpenJPA, etc...

• Osakidetza dispone de una arquitectura SOA para gobernar y orquestar los servicios disponibles en la organización. En este sentido, el sistema de información deberá inventariar y hacer públicos los contratos de los servicios que pone a disposición de otros sistemas de información.

• Los requisitos de integración del sistema de información deberán de ser resueltos mediante uno de estos tres métodos:

� Escenario 1 - Réplica de datos: Oracle Streams

� Escenario 2 - Propagación y consumo de eventos: Event Manager

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

• En base a requerimientos de seguridad, en los escenarios 2 y 3, se deben de poder soportar los estándares WS-Security.

• El sistema de información deberá integrarse con el sistema de Gestión de Identidades de Osakidetza, para el alta baja y modificación de usuarios.


5 Descripción de entregables

Los productos a entregar, tanto productos software como documentación, serán aquellos que define la metodología de desarrollo ARINBIDE, en referencia a las fases definidas dentro del alcance del proyecto.

Igualmente, dentro del alcance definido del proyecto, la Metodología de Pruebas v1.0, así como el documento de Aseguramiento de la Calidad de Sistemas Software v1.0, detallan los entregables a proporcionar en el ámbito de la calidad.

Con independencia de lo descrito y requerido a nivel metodológico y especificado como requerimiento en el Pliego de Bases Técnicas (metodología de desarrollo Arinbide, y Metodología de Pruebas), a continuación se añaden tareas y entregables a realizar/suministrar por el adjudicatario:

Implantación en el Entorno de Desarrollo de EJIE

Definición, ejecución y gestión del Plan de Pruebas

Preparación de componentes y soporte a la implantación en el entorno de Test o Preproducción.

Soporte a la implantación en el entorno de Producción.

Soporte en la fase de despliegue de la Plataforma.

La documentación de usuario deberán estar en ambos idiomas: euskera y castellano.

La aplicación, las páginas, los textos, tablas de códigos, los mensajes de error/aviso y/o cualquier otro componente (tool-tip, textos en imagen,….) dirigidos al usuario final deberán estar en ambos idiomas: euskera y castellano.

Entrega de fuentes de todos los componentes, ficheros de configuración, elementos gráficos utilizados,…..y cualquier otro elemento que se considere necesario para el normal y adecuado mantenimiento/evolución del sistema, en soporte magnético (DVD).

Confección y entrega de la documentación (funcional, técnica, de explotación y de usuario) correspondiente a cada una de las fases del proyecto tanto en formato papel, como en formato electrónico.

Licencias y elementos adicionales necesarios más allá de los ya contemplados con anterioridad y necesaiors para el correcto funcionamiento y mantenimiento posterior del Sistema de Información.

Todos los entregables deberán proporcionarse utilizando las herramientas homologadas en EJIE para el ciclo de vida de las aplicaciones, o en su caso proporcionando formatos compatibles.


6 Planificación y Organización

6.1 Plan de Proyecto

6.1.1. Plan de Entregas e Hitos de Control

El licitador deberá incluir en su Documento de Propuesta Técnica una descripción de las principales:

• Fases y tareas del proyecto,

• Entregas resultantes de cada fase,

• Hitos de control y/o verificación,

junto con sus correspondientes fechas estimadas de inicio y finalización.

Asimismo, el licitador podrá establecer propuestas de entregas y/o certificaciones parciales acordes con el planteamiento del proyecto establecido, siempre que:

• Lo considere más adecuado para facilitar la implantación y puesta en marcha del objeto del contrato.

• No se establezca nada en sentido contrario en los apartados de: Objeto del contrato y Contenido.

6.1.2. Diagrama de Gantt

El licitador deberá presentar un Diagrama de Gantt o Cronograma de las Fases y Tareas propuestas para la ejecución de las realizaciones objeto del presente pliego. Asimismo, este diagrama de Gantt deberá venir explicado en un formato de tabla especificando:

• Nombre de la tarea y descripción de la misma

• Fecha de inicio estimada

• Fecha de fin estimada

6.2 Organización del Equipo de Trabajo

El licitador deberá describir en su Documento de Propuesta Técnica:

• La organización (perfiles) del equipo de proyecto asignado a la realización de las actividades resultantes del presente pliego

• Las funciones de los mismos


• La relación nominal de los participantes, junto su correspondiente documento de currículo.

6.2.1. Asignación de recursos a fases del proyecto

El licitador deberá incluir en su Documento de Propuesta Técnica, un desglose de horas y % de dedicación total por perfil y fase del proyecto, siguiendo el siguiente modelo:

Gest. Proyecto Análisis Diseño Construcción Implantación Descripción Perfil

Horas % Horas % Horas % Horas % Horas %

Total Horas

Jefe Proyecto Analista Funcional Analista Técnico Analista-Program. Programador Diseñador … TOTAL

(*) Este desglose de horas se considerará como orientativo y será tenido en consideración en el momento de valorar el grado de aproximación a la planificación del proyecto según la estimación del licitador, permitiendo, de esta forma, valorar la idoneidad del dimensionamiento del equipo de trabajo propuesto y su adecuación a la consecución de los objetivos. No obstante, este desglose de horas no se considera vinculante al no tratarse de una contratación de horas de desarrollo, sino un proyecto “llave en mano” según el importe total ofertado.

6.2.2. Equipo de Trabajo

El equipo de trabajo propuesto estará formado por personal técnico con categoría profesional y nivel de especialización adecuados a las necesidades planteadas en cada momento, de acuerdo con las actividades que se vayan desarrollando. El licitador debe comprometerse, en caso de ser adjudicatario, a mantener el equipo según lo establecido en el Documento de Propuesta Técnica, y durante el periodo fijado en cada actividad específica.

6.2.2.1. Veracidad de los datos

E.J.I.E. se reserva la facultad de solicitar, en cualquier momento, antes o después de la adjudicación y durante el curso de los trabajos, de cualquier otro tipo de documento complementario, en orden a la comprobación de cuantos datos haya ofrecido la empresa adjudicataria, tanto respecto a la misma, como a los recursos de que disponga.

La falsedad en los mismos podrá implicar asumir penalizaciones y, en último término, podrá provocar la resolución del contrato.


6.2.2.2. Condicionante del equipo de trabajo ofertado

La falsedad en el nivel de conocimientos técnicos del personal ofertado, deducida del contraste entre lo reflejado en el currículo y los conocimientos reales demostrados en la ejecución de los trabajos podría, en último término, podrá provocar la revisión de la adjudicación y en su caso la rescisión del pedido/contrato.

6.2.2.3. Constitución inicial del equipo de trabajo

El equipo humano a incorporar tras la formalización del contrato para la ejecución de los trabajos deberá estar formado por componentes relacionados en la oferta adjudicataria y consecuentemente valorados.

Si tras la adjudicación se observara que el equipo de proyecto no se corresponde con el Documento de Propuesta Técnica objeto de la misma y:

• Caso que el adjudicatario presente justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio, se procederá a:

La presentación por el adjudicatario de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.

Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de E.J.I.E.

• Caso de que se demostrase que el cambio no se corresponde con causa justificada, de fuerza mayor y no imputable al adjudicatario, E.J.I.E. se reserva el derecho no solo a la aprobación de la persona o personas sustitutivas, sino incluso a la revisión de la adjudicación y en su caso la rescisión del pedido/contrato, si este hecho fuera elemento determinante en la mencionada adjudicación.

6.2.2.4. Modificaciones en la composición del equipo de trabajo

La valoración final de la productividad y calidad de los trabajos de las personas que realizan los trabajos objeto del presente pliego corresponde a la Dirección del Proyecto de E.J.I.E., siendo potestad suya solicitar el cambio de cualquiera de los componentes del equipo de trabajo, con un preaviso de quince días, por otro de igual categoría, si existen razones justificadas que lo aconsejen.

Si el adjudicatario propusiera el cambio de una de las personas del equipo de trabajo, se deberá solicitar por escrito con quince días de antelación, y requerirá de las siguientes condiciones:

• Justificación escrita, detallada y suficiente, explicando el motivo que suscita el cambio.

• Presentación de posibles candidatos con un perfil de cualificación técnica igual o superior al de la persona que se pretende sustituir.

• Aceptación de alguno de los candidatos por parte de la Dirección del Proyecto de E.J.I.E.

Los posibles inconvenientes de adaptación al entorno de trabajo y al proyecto debidos a las sustituciones de personal, deberán subsanarse mediante periodos de solapamiento sin coste adicional, durante el tiempo necesario. Si a criterio de la Dirección del Proyecto de E.J.I.E. esto no fuera posible, las dos primeras semanas de trabajo del sustituto no serán facturables corriendo a cargo del adjudicatario los gastos que se deriven de esta condición.


6.2.2.5. Jornada laboral y lugar de realización de los trabajos.

Los trabajos de desarrollo se realizarán normalmente en las dependencias del adjudicatario en cuyo caso:

• La jornada de trabajo estará de acuerdo a la establecida por el adjudicatario siempre y cuando cumpla con los requerimientos de los servicios demandados por E.J.I.E.,

• Los componentes del grupo de trabajo desarrollarán su labor con hardware y software propiedad del adjudicatario. Dicha ubicación deberá ser lo suficientemente cercana a E.J.I.E., S. A. como para garantizar una presencia rápida en las instalaciones de E.J.I.E., ante cualquier eventualidad que pudiera surgir.

Las pruebas de integración, de carga, aceptación, la puesta a punto de los productos, así como la implantación en los diferentes entornos, se realizarán en los locales de E.J.I.E.

La fase de soporte al despliegue de la plataforma y los trabajos puntuales que, por su naturaleza, así lo requieran, se realizarán en los locales de E.J.I.E.

En aquellos casos en que los trabajos deban ser realizados en las dependencias de E.J.I.E, estos se realizarán en las siguientes condiciones:

• La jornada de trabajo estará de acuerdo a la establecida por E.J.I.E.,

• Con carácter general los componentes del grupo de trabajo deberán desarrollarán su labor con hardware y software propiedad del adjudicatario, salvo para labores de instalación, implantación, y puesta en marcha, que se realizará mediante los puestos asignados por la Dirección del Proyecto de E.J.I.E.

• Si por circunstancias excepcionales y cuando la realización efectiva de los trabajos no se ajuste a la planificación o así se requiera por las necesidades del servicio, el adjudicatario deberá comprometerse a una plena disponibilidad incluso fuera del horario habitual (salvo acuerdo previo por la Dirección del Proyecto de E.J.I.E.), sin que la realización del trabajo tenga una consideración especial a efectos de cómputo de horas o tarifa aplicable a las mismas

6.2.2.6. Currículo de los componentes del grupo de trabajo.

Se deberá adjuntar el currículo individual detallado de todos y cada uno de los componentes del grupo de trabajo propuesto para la realización de las tareas y actividades de los trabajos objeto de contratación, junto con el papel/perfil (conforme a los indicados en el cuado anterior) que asumen en la realización descrita.

La no inclusión del currículo de alguno de los participantes, puede suponer la imposibilidad de una adecuada evaluación del apartado de “Organización del Proyecto”, pudiendo el licitador no ser puntuado por este concepto.

Datos del currículo:

• Apellidos y Nombre,

• Edad,

• Conocimientos metodológicos y tecnológicos principales.


• Formación Reglada: Centro, Titulación y Fechas (desde-hasta).

• Formación no Reglada: Centro, Curso y Fecha (desde-hasta).

• Experiencia Acumulada: Total Años.

• Experiencia profesional: Empresa, Puesto / Responsabilidades, Meses o Años, Fecha (desde-hasta).

• Conocimientos y Experiencia obtenida Proyectos: Proyecto, Puesto / Responsabilidades, Meses, Fecha (desde-hasta), y principales tecnologías utilizadas, para al menos los principales o correspondientes a experiencias similares.

6.3 Transferencia Tecnológica

Durante la ejecución de los trabajos objeto del contrato el adjudicatario se compromete, en todo momento, a facilitar a las personas designadas por la Dirección del proyecto de E.J.I.E. así como la información y documentación que ésta solicite. Todo esto para disponer de un pleno conocimiento de los trabajos desarrollados o de los eventuales problemas que puedan plantearse y de las tecnologías, métodos, y herramientas utilizados para resolverlos.


7 Presupuesto y oferta económica

En documento separado y siguiendo lo establecido en el modelo de Pliego/Hoja de Cláusulas Administrativas se deberán incluir:

• Importe Total de la oferta Económica: con y sin I.V.A. incluyendo todos los aspectos a valorar

• Relación completa de los costes contenidos en la propuesta, indicando para el caso de los recursos humanos:

Número de horas por persona y categoría/perfil.

Coste hora por categoría/perfil.

Los costes se presentarán, desglosarán y totalizarán según el siguiente modelo.

Categoría y/o Precio Unitario Horas Importe Importe Perfil Euros / Hora Dedicadas Neto IVA Incluido Jefe de Proyecto Analista Funcional Analista Técnico Analista-Programador Programador Diseñador …. … TOTAL Precio/Medio Total Horas Total Neto Total con IVA

En los precios ofertados se entenderán ya incluidos: las dietas, gastos de desplazamiento y/o cualquier otro gasto necesario para la realización del servicio. Con independencia de lo aquí indicado será necesario incluir el desglose de cualquier gasto o aspecto objeto del presente pliego si así fuera requerido de forma expresa en el Pliego/Hoja de Cláusulas Administrativas.

Se tendrán en cuenta posibles prestaciones superiores a las solicitadas ofertadas por el licitador y debidamente valoradas, tanto en cuanto al nivel de esfuerzo (horas por perfil), como económicamente, siempre y cuando E.J.I.E. las considere como tales desde el punto de vista del proyecto y si así se especificase en el apartado de “Prestaciones Superiores/Complementarias a las Exigidas” dentro del apartado de Criterios de Valoración.

En el caso de que se presente como base para la nueva plataforma elementos pertenecientes a una solución comercial, excluyendo dentro de los mismos a los estándares ya incluidos comentados anteriormente (ver Entorno Tecnológico) así como los relativos a las diferentes herramientas de explotación de datos propuestas, deberán valorarse las licencias necesarias para dar solución a la nueva plataforma y dicha valoración será incluida dentro del cálculo del coste total del proyecto ofertado.

El presupuesto y oferta económica se establece con un importe máximo de 1.100.000 € (IVA no incluido). Este valor será el tomado como base para los Criterios de Valoración explicados posteriormente. Dicho


importe deberá incluir las licencias necesarias más allá del Software Base estándar del Gobierno Vasco detallados en los estándares tecnológicos así como la totalidad de los requerimientos a cumplir detallados.


8 Mecanismos de Seguimiento, Control y Supervisión

La gestión del proyecto se realizará según las normas procedimentales y de calidad de la Gestión de Proyectos de E.J.I.E.

El control y seguimiento de la calidad de servicio, será realizado por la Dirección del Proyecto de E.J.I.E.

Durante el desarrollo y ejecución del proyecto, E.J.I.E. podrá establecer controles de calidad sobre la actividad desarrollada.

8.1 Mecanismos de Seguimiento y Control

El equipo de trabajo estará dirigido por un Responsable del Proyecto con dedicación estable y suficiente, quien coordinará las tareas implicadas en el proyecto y será el interlocutor principal con la Dirección del Proyecto de E.J.I.E.

Deberán establecerse todos los mecanismos de control que permitan verificar de forma continuada el cumplimiento de los objetivos especificados, tanto en plazos como en términos de calidad final. Para ello se contempla:

• Reuniones de seguimiento: a partir del plan de entregas requerido se celebrarán reuniones periódicas o coincidiendo con los puntos de decisión, destinadas a revisar el grado de cumplimiento de las tareas planificadas, la entrega de productos, las reasignaciones de personal, la validación de las programaciones de actividades a realizar, etc.

• Reuniones de control económico: de control económico del proyecto para llevar a cabo el plan de pagos establecido.

• Informes de situación y progreso: con los que la empresa adjudicataria comunicará a la Dirección del Proyecto de E.J.I.E., del estado puntual de los trabajos, de los objetivos alcanzados, de las incidencias ocurridas, etc.

• Certificaciones parciales: si procede.

• Hojas de control de tareas: si procede.

• Documentos de gestión de proyectos: a solicitud del responsable de E.J.I.E., la empresa adjudicataria cumplimentará los documentos de gestión de proyectos, según un modelo definido: actas de reuniones, registro de inspección y ensayo, informes de progreso, control de configuración (módulos-componentes instalados), etc.

8.2 Supervisión del proyecto

Tanto la dirección como la supervisión del Proyecto serán llevadas a cabo por el personal de E.J.I.E., S.A. asignado al mismo.

Los productos del trabajo deberán ser aprobados tanto por el Responsable del Proyecto por parte del adjudicatario, como por la Dirección del Proyecto de E.J.I.E.. Si los encuentran conformes, emitirán su informe


favorable, empezándose a computar desde ese momento el período de garantía que todo trabajo de realización externa debe aportar en previsión de defectos no detectados en las pruebas realizadas.

El incumplimiento de los plazos pactados sin causa que lo justifique, dará lugar a las penalizaciones que se acuerden en las condiciones particulares mencionadas en este Pliego de Bases Técnicas.


9 Plazo de ejecución y Plan de Facturación

La entrega del producto objeto del contrato tendrá como fecha límite el 31 de Diciembre de 2012.

El adjudicatario tiene derecho al abono, con arreglo a los precios convenidos, de los trabajos que realmente ejecute, con sujeción al contrato otorgado, a sus modificaciones aprobadas y a las órdenes dadas por escrito por E.J.I.E.

La facturación del precio del contrato, se efectuará a través de la presentación de las correspondientes facturas expedidas con los requisitos legales exigidos y repartidas de forma orientativa (los hitos de facturación y reparto se acordarán en el arranque del proyecto entre el Director de Proyecto de EJIE con el adjudicatario del concurso) según el cuadro siguiente:

A la Aprobación del Documento de Análisis Funcional 10%

A la Aprobación del Diseño Técnico 10%

A la Aprobación en el Entorno de Desarrollo 20%

A la Aprobación en el Entorno de Test 10%

A la Aprobación en el Entorno de Producción 20%

A la finalización del los procesos asociados al Despliegue de la plataforma 15%

A la Aceptación Definitiva de la Dirección del Proyecto de E.J.I.E. de los trabajos realizados 15%

• La aprobación de las tareas de implantación implica:

La implantación en el entorno correspondiente

y la aprobación por la Dirección del Proyecto de E.J.I.E. de las tareas asociadas, entre otras, al seguimiento del plan de calidad.

• El plan de facturación definitivo se determinará sobre la base del plan de proyecto establecido en la fase de definición inicial del mismo. Para esto deberá tenerse en cuenta que:

En función del plan del proyecto y de acuerdo con la Dirección del Proyecto de E.J.I.E, podrán ser establecidas entregas parciales. Éstas podrán implicar facturaciones acordes al alcance de las mismas, tras las correspondientes verificaciones y certificaciones.

La no conformidad de los productos recepcionados, tanto en cuanto al alcance funcional respecto el plan de entregas preestablecido, como en cuanto al incumplimiento de las normas/estándares marcados, y/o en cuanto al nivel de calidad de los mismos, pueden provocar la paralización del plan de facturación hasta que se resuelvan las no conformidades. Caso de que los trabajos efectuados no se puedan adecuar a la prestación contratada, como consecuencia de vicios o defectos graves imputables al contratista, no pudiendo ser


utilizados por E.J.I.E. en tiempo y/o condiciones apropiados, E.J.I.E. estará exento de la obligación de pago o tendrá derecho, en su caso, a la recuperación del importe satisfecho.

El plan de facturación establecido al inicio del proyecto podrá ser revisado y/o modificado, a lo largo del proyecto y como consecuencia de actividades de replanificación del mismo establecidas en los procedimientos de control y seguimiento del proyecto.

• Para llevar a cabo el abono de los importes relativos a los conceptos de cada una de las facturas será requisito imprescindible disponer de la certificación de conformidad de los mismos emitida por la Dirección del Proyecto de E.J.I.E.


10 Criterios de Valoración

Los criterios de adjudicación que servirán de base para la valoración de las propuestas, así como sus pesos de ponderación se recogen a continuación. Para la evaluación de las propuestas se establece un criterio de ponderación con una puntuación máxima de 100 puntos.

A continuación se detalla la puntuación y aspectos que se tendrán en cuenta para la adjudicación del trabajo:

Característica Objeto de valoración Puntos

Valoración económica 30

Entendimiento del proyecto y calidad de la solución 25

Plan y equipo de trabajo 25

Arquitectura de la solución y compatibilidad con los estándares de Gobierno 15

Prestaciones superiores/complementarias a las exigidas 5

Valoración económica

La proposición económica se valorará mediante la siguiente fórmula:

Total puntos proposición económica x Precio oferta más ventajosa (la de menor precio) Precio de la oferta evaluada

Como se ha mencionado anteriormente, deberá incluirse dentro del precio las licencias adicionales a los estándares del Gobierno si procediera en función de la solución presentada.

En caso de que la oferta presentada no se ajuste a los valores de referencia del pliego por exceso se adjudicarán 0 (cero) puntos en este concepto quedando exlcuido automáticamente del proceso posterior de valoración.

Asimismo, en caso que el precio ofertado sea inferior al 30% del precio medio todas las ofertas recibidas, se podrá apreciar, que la realización no puede ser cumplida como consecuencia de desproporcionada o anormal.

En este caso se procederá a: • Analizar el resto de los apartados de la oferta, en particular: el planteamiento de la solución, las

soluciones técnicas adoptadas y aquellas otras condiciones excepcionalmente favorables de que disponga el licitador para ejecutar la prestación, que justifiquen el ahorro y que permitan el procedimiento de ejecución del contrato, y/o

• Requerir al licitador para que justifique la valoración de la oferta y precise las condiciones de la misma, en particular en lo que se refiere a las circunstancias que permitan el ahorro y que garanticen el procedimiento de ejecución del contrato.


Si considerando la justificación efectuada por el licitador, se estimase que la oferta no puede ser cumplida como consecuencia de la inclusión de valores anormales o desproporcionados, respecto este criterio será la menor valorada.

Entendimiento del proyecto y calidad de la solución

En este apartado se analiza si la propuesta que realiza el proveedor se ajusta tanto en alcance como en profundidad a las necesidades marcadas en el pliego de bases técnicas, así como la calidad de la solución planteada.

En caso de que la oferta no se ajuste a las necesidades planteadas en el pliego de bases técnica, la puntuación será de cero, excluyéndose automáticamente esta oferta del resto del proceso selectivo.

Plan y equipo de trabajo

Se valorará la organización, planificación y estrategia de desarrollo del proyecto así como el equipo presentado.

Arquitectura de la solución y compatibilidad con los estándares de Gobierno

Como se ha mencionado anteriormente, es posible que puedan proponerse tecnologías alternativas a las existentes como estándar en la actualidad, que den solución a las funcionalidades demandadas.

Dentro de este apartado se valorará la arquitectura general del sistema: escalabilidad, alta disponibilidad, etc. así como el encaje de la misma, con sus tecnologías asociadas, y su posibilidad de asimilación / compatibilidad / adaptación con las que figuran en los estándares actuales del Gobierno Vasco.

Prestaciones superiores/complementarias a las exigidas

En este apartado se valorará aquellas mejoras tanto funcionales como técnicas que el proveedor plantee en su oferta y que se consideren beneficiosas para el proyecto.


11 Garantía y Confidencialidad.

Las cláusulas relativas a la propiedad intelectual, garantía y confidencialidad de la información, así como el resto de condiciones generales de contratación se encuentran disponibles en la web de E.J.I.E. (www.ejie.net) en el apartado perfil de contratante.

11.1 Garantía

El período de garantía será como mínimo de 1 año a partir de la aceptación del trabajo. No obstante los licitadores especificarán, en su caso, el tiempo de garantía ofrecido superior al mínimo, así como el alcance de la misma.

11.2 Confidencialidad de la información

La Dirección del proyecto entregará la información y documentación que considere necesaria para la realización del presente trabajo, debiendo la empresa adjudicataria comprometerse a:

• Tratar con absoluta confidencialidad todo el material y la información que reciba como consecuencia de los trabajos realizados objeto de la adjudicación, durante el periodo de tiempo de duración de la misma,

• No utilizar la misma para otros fines que los recogidos en el presente Pliego de Condiciones Técnicas.

• No duplicar, copiar, revelar, ceder o vender total o parcialmente la información obtenida, en todo o en parte, a terceros sin autorización escrita de E.J.I.E.,

• Advertir a sus empleados de sus obligaciones respecto a la confidencialidad de la información, velando por el cumplimiento de la misma,

• Restringir la utilización de la información obtenida como consecuencia de los trabajos realizados objeto del presente pliego de bases técnicas, exclusivamente para aquellos empleados que tengan necesidad de conocerla y con la finalidad de realizar los trabajos expuestos.

• Poner todos los medios a su alcance para conservar el carácter confidencial y reservado tanto de la información y documentación recibida de E.J.I.E., como de los resultados obtenidos del trabajo realizado.

• La devolución de toda la información, material y/ soportes informáticos obtenidos, así como a la descarga de la misma de sus equipos informáticos o (si existieran), una vez finalizado el periodo de contratación correspondiente.

Cualquier infracción en este sentido será calificada como grave y será causa de resolución del contrato, sin perjuicio de las responsabilidades penales, o de otro tipo, en que se puedan incurrir.


11.3 Protección de datos

El adjudicatario quedará obligado al cumplimiento de lo dispuesto en la Ley Orgánica de Protección de Datos, sobre protección de datos de carácter personal. En este sentido, deberá sujetarse a los preceptos de la Ley Orgánica 15/1999, de 13 de diciembre, LOPD, y su Reglamento de Desarrollo, RD 1720/2007, de 21 de diciembre.


12 Propiedad intelectual.

Todos los derechos de propiedad intelectual y de ‘Copyright’ de cualquier producto o subproducto derivados de los trabajos realizados bajo la correspondiente adjudicación serán propiedad exclusiva de E.J.I.E., obligándose las partes a otorgar el documento oportuno cuando éste sea necesario, para la debida constancia pública de este hecho ante cualquier Organismo o Registro, tanto de la Comunidad Autónoma como de la Administración Central del Estado Español.

Asimismo todo producto o subproducto derivada de la correspondiente contratación no podrá ser utilizado para otros fines fuera del ámbito de la misma, sin el permiso expreso y por escrito de E.J.I.E.

La empresa adjudicataria será responsable de daños y perjuicios que se deriven del incumplimiento de esta obligación.


13 Prestaciones superiores o complementarias a las exigidas

El Licitador podrá incluir en su propuesta de colaboración cuantas prestaciones adicionales considere oportunas para la mejora de su actuación, siendo valoradas conforme a lo establecido en el apartado de Criterios de Valoración.

En cualquier caso, al respecto cabe aclarar los siguientes puntos:

• Deberán ser:

Descritas en cuanto a sus objetivos, funcionalidad y alcance,

Necesariamente valoradas tanto en cuanto:

Esfuerzo: Horas, (dentro del Documento de Propuesta Técnica Técnica)

Coste: Euros, (dentro del Documento de Propuesta Económica), La finalidad de esta solicitud es la de permitir a E.J.I.E. realizar un mejor y más adecuado análisis comparativo de las propuestas recibidas.

Caso que:

Elementos similares hayan sido diferentemente valorados en las distintas propuestas recibidas, o que

Determinadas prestaciones hayan sido (a juicio de E.J.I.E.) sobrevaloradas.

Se definirá por parte de E.J.I.E. un patrón general de esfuerzo por perfil para las mismas y se re-estimará su valoración a los precios correspondientes de los perfiles de cada uno los licitadores.

• Posibles mejoras correspondientes a la ampliación del periodo mínimo de garantía establecido, deberán ser referidas e indicadas, pero en ningún caso valoradas en cuanto a esfuerzo y coste.

• Con independencia de lo indicado en los puntos anteriores, las prestaciones superiores/complementarias ofrecidas por el licitador, serán valoradas siempre y cuando E.J.I.E.:

Considere que realmente están fuera del alcance base del proyecto.

Las considere beneficiosas desde el punto de vista del proyecto.


14 Estructura y Formato de la Propuesta

El licitador sólo podrá presentar su propuesta contemplando una única alternativa siempre y cuando no se indique lo contrario en los requerimientos a cumplir detallados anteriormente en este pliego. Tal es el caso de la propuesta de herramientas de explotación de datos.

14.1 Estructura normalizada y contenido de las propuestas.

La propuesta que se presente por el licitador deberá aportar la información que se requiere en todos sus apartados y estar obligatoriamente estructurada de la siguiente forma:

Documento de Propuesta Técnica, incluyendo

• Índice.

• Presentación y Características Generales:

Identificación del pliego al que responde la propuesta.

Acatamiento con carácter general a las condiciones del pliego.

A partir de este punto, los siguientes apartados se particularizarán para cada una de las soluciones que se oferten.

• Descripción de la Solución Técnica.

Se incorporará al inicio de este apartado el resumen de los aspectos más significativos y relevantes de la solución propuesta. Se deberá incluir información detallada de la propuesta en relación con los requisitos de este pliego. Se trata, en definitiva, de una memoria descriptiva del proyecto.

• Metodología y Entorno Tecnológico.

• Planificación y Organización.

Se indicarán las principales fases/tareas del proyecto y el cronograma de trabajos.

Organización del equipo de proyecto, junto perfiles, funciones y responsabilidades.

Equipo de trabajo.

Datos relativos de todos los componentes del equipo de trabajo, incluyendo el cuadro de asignación de recursos a fases del proyecto.

Composición del equipo de trabajo propuesto, ordenado por categorías profesionales.

Currículo de cada uno de los componentes, de acuerdo a lo indicado en el apartado Equipo de Trabajo y recogido en Anexo al Documento de Propuesta Técnica.

• Procedimientos de Gestión, Control y Calidad de Proyectos

Se incluirá en este apartado la descripción de las medidas dispuestas por el licitador para asegurar la calidad de los trabajos, medios humanos y materiales, aseguramiento de calidad,


así como aquellas otras que se prevé aplicar para vigilar y garantizar el adecuado cumplimiento del contrato.

• Prestaciones superiores o complementarias a las exigidas, si las hubiera:

El adjudicatario podrá incluir en su propuesta cuantas prestaciones adicionales considere oportunas para la mejora de su actuación, estas (salvo ampliaciones en la garantía) deberán ser necesariamente valoradas tanto en cuanto al nivel de esfuerzo (horas por perfil) como económicamente y de forma separada en los Documentos de Propuesta Técnica y Propuesta/Oferta Económica

• Garantía, Confidencialidad y Propiedad Intelectual.

Nota: En ningún caso se deberá incluir información Económica en el Documento de Propuesta Técnica.

Documento de Propuesta/Oferta Económica, incluyendo:

• Importe Total de la oferta Económica: con y sin I.V.A.

• Relación completa de los costes contenidos en la propuesta, indicando:

Número de horas por persona y categoría/perfil.

Coste hora por categoría/perfil. Siguiendo el modelo establecido.

• Cualquier otro requisito establecido en el Pliego/Hoja de Cláusulas Administrativas.

14.2 Formato de la Propuesta.

El soporte físico de las propuestas deberá ser:

• Papel, debidamente encuadernada, y

• CD/DVD, en formato electrónico (.pdf).

14.3 Sobres y Elementos.

Todas las propuestas deberán entregarse en sobre o paquete debidamente cerrado, y

• Con etiqueta indicando sobre el mismo:

Descripción/Título y

Referencia Presentes en la carátula del presente Pliego.

• Recogiendo en su interior:


Documento de Propuesta Técnica, siguiendo la estructura requerida en el apartado de Estructura y Formato de la Propuesta, del presente documento.

Documento de Propuesta Económica siguiendo la estructura requerida en el apartado de Presupuesto/Oferta económica, del presente documento y de lo indicado en el Pliego/Hoja de Cláusulas Administrativas

Soporte Magnético con los documentos electrónicos correspondientes, rotulado sobre el mismo: Descripción/Título y Referencia del Pliego.

Pliego de Bases Técnicas - Euskadi.eus · Gestión de emisiones de tarjetas 41 3.2.5....

Documents

Transcript of Pliego de Bases Técnicas - Euskadi.eus · Gestión de emisiones de tarjetas 41 3.2.5....