diseño conceptual de la plataforma valencia

VALENCIA.DATA

Diseño conceptual de la plataforma VALENCIA.DATA

Entregable: E2.1

Paquete de trabajo: PT2

VALENCIA.DATA 3


ÍNDICE 1 INTRODUCCIÓN 4 2 DISEÑO CONCEPTUAL 5

2.1 Caso de uso de Almacenamiento de datos personales 8 2.2 Caso de uso de perfilado para proyectos de I+D 9 2.3 Caso de uso de datos de proyectos de investigación 10 2.3.1 Estudio Carro-Mochila 10 2.3.2 Estudio longitudinal para la prevención de caídas 14 2.4 Caso de uso con aplicación externa 18 2.5 Caso de uso de servicio de explotación de datos 19 2.5.1 Explotación de datos anónimos 19 2.5.2 Explotación de datos personales 20

3 MODELO DE DATOS DE VALENCIA.DATA 21 3.1 Modelo Entidad-Relación 21 3.1.1 Glosario: definición de “entidades” 23 3.2 Modelos de uso 28 3.2.1 Participante solicita darse de baja (borrado de todos sus datos) 28 3.2.2 Participante accede a modificar los datos de su perfil 29 3.2.3 Participante consulta sus datos en el SISTEMA 29 3.2.4 Gestor busca y convoca participantes para un proceso de adquisición de datos. 29 3.2.5 Gestor invita a participantes a completar datos de su ficha (perfil) 30 3.2.6 Gestor comunica a Investigador lista de participantes 31 3.2.7 Gestor amplía la ficha de participantes (perfil) 31 3.2.8 Investigador crea nueva Ficha de trabajo 31 3.2.9 Investigador busca y consulta Protocolos 32 3.2.10 Investigador crea nuevo Protocolo, o lo modifica. 33 3.2.11 Investigador almacena Datos de una Ficha de trabajo 33 3.2.12 Aplicación externa almacena Datos en un proceso automático. 34 3.2.13 Investigador descarga Datos de una Ficha de trabajo 34 3.2.14 Investigador busca Datos de varias fichas de trabajo (incluidas las asociadas a aplicaciones)34 3.2.15 Administrador gestiona usuarios y roles 35 3.2.16 Administrador gestiona Fichas de trabajo 35 3.2.17 Administrador gestiona Protocolos 35 3.2.18 Administrador gestiona Datos 35

1 INTRODUCCIÓN

Este entregable incluye la descripción del diseño conceptual del ecosistema VALENCIA.DATA y el modelo de datos que deberá implementarse en la arquitectura del ecosistema.

Para establecer el diseño conceptual (ver “2 Diseño conceptual”) se han definido perfiles de potenciales usuarios del ecosistema:

• Participantes: sujetos que aportan datos personales. • Investigadores: profesionales expertos en los campos de acción. • Responsable del tratamiento. • Gestor/a • Empresas que acceden a datos.

A partir de estos perfiles se ha generado un mapa conceptual y se han definidos casos de uso para el ecosistema VALENCIA.DATA:

• Caso de uso de almacenamiento de datos personales. • Caso de uso de perfilado para proyectos de I+D. • Caso de uso de datos de proyectos de investigación. • Caso de uso con aplicación externa. • Caso de uso de servicio de explotación de datos.

Finalmente, como resultado del análisis de los diferentes casos de uso listados anteriormente, se ha definido un modelo de entidad-relación (ver ”3.1 Modelo Entidad-Relación”). Este modelo permite representar entidades en una base de datos mediante un diagrama y los atributos de cada entidad.

A partir del modelo de entidad-relación se han generado 18 modelos tipo de uso que permitirán a los desarrolladores diseñar la web app de VALENCIA.DATA cumpliendo con las funcionalidades definidas en los modelos de uso (ver ”3.2 Modelos de uso”).

VALENCIA.DATA 5

5

2 DISEÑO CONCEPTUAL

La Figura 1 muestra el funcionamiento conceptual general del ecosistema (o plataforma) VALENCIA.DATA.

Inicialmente, se definen los siguientes perfiles de usuario de forma preliminar como paso previo al diseño conceptual de la plataforma VALENCIA.DATA:

● Sujetos/ usuarios individuales (participante): son aquellos usuarios que proporcionan datos a la plataforma, realizando ensayos en el IBV, acudiendo a algún córner o rellenando algún cuestionario on-line. En adelante utilizaremos el término participante para el usuario que se registra en VALENCIA.DATA para proporcionar sus datos.

● Investigadores: son aquellos usuarios que tienen acceso a los datos pseudo-anonimizados de los usuarios para realizar tratamientos, pasar de datos brutos a datos agregados, definir los metadatos y también realizar cálculos agrupando los datos.

● Responsable de tratamiento: Inicialmente la entidad responsable de todos los datos que se van a almacenar en VALENCIA.DATA es el IBV. Pero en el futuro el sistema de gestión de datos podría ofrecerse a otras entidades.

● Gestor / atención al usuario: tienen acceso a los datos personales y de contacto de los usuarios para poder proponerles ensayos y/o colaboraciones en proyectos.

● Empresas: Este perfil podrá disponer de datos agrupados en función de su suscripción y de acuerdo a los consentimientos informados que los usuarios hayan proporcionado. En ningún caso se proporcionarán datos individuales o personales sin el consentimiento de los participantes.

La definición completa de los diferentes perfiles se describe con más detalle más adelante.

Figura 1: Mapa conceptual

VALENCIA.DATA 7


En la zona sombreada del mapa conceptual (Figura 1 - derecha) se muestra el flujo de incorporación de datos (en el caso correspondiente se tratará en más detalle):

● Como paso previo, se da de alta al participante en VALENCIA.DATA si aún no está dado de alta.

● En primer lugar, se comprueba si el usuario ya existe en la base de datos para añadir los nuevos datos a su perfil o crear un perfil de usuario nuevo. Esto es necesario para poder conocer el identificador o código del usuario individual.

● Se deberán registrar también los consentimientos informados relacionados.

● Posteriormente se recopilan los datos de un participante. Por ejemplo, mediante un ensayo en el IBV, una aplicación del móvil o en un córner para la captación de datos. Aquí es muy importante una adecuada sincronización de forma que los datos de las mediciones se puedan relacionar siempre con el participante de VALENCIA.DATA.

● En los casos en que no se sincronicen los datos automáticamente entre la aplicación de medida y VALENCIA.DATA, se identificarán con el código o identificador del usuario individual para que pueda realizarse una sincronización posterior.

● Para cada set de datos, existirá un investigador/a responsable, que se encargará de definir e incorporar los datos procesados para su uso en investigación, los datos procesados para mostrar cómo feedback al participante y los metadatos correspondientes a la medición.

● Los datos brutos, procesados y metadatos se actualizan en el perfil del participante en la base de datos de VALENCIA.DATA.

El perfil de investigador/a:

● Es la persona encargada de supervisar las nuevas tipologías de datos para las cuales debe definir los metadatos, los datos procesados que se almacenarán en el sistema y el feedback que se proporcionará al usuario.

● Para tipologías de datos ya definidas, debe realizar los análisis que sean necesarios para obtener los datos procesados ya definidos. Una vez se disponga de los datos procesados, se incorporarán al perfil del participante en VALENCIA.DATA.

● El investigador siempre trabajará con datos pseudo-anonimizados no disponiendo de los datos de contacto ni del nombre de los usuarios.

● El investigador también puede definir una consulta para obtener datos de VALENCIA.DATA de una tipología o características de un participante definidas.

○ En el caso de que dichos datos sí existan en VALENCIA.DATA, se revisarán los consentimientos informados de los usuarios para verificar si pueden

8

ser utilizados para el fin que el investigador necesita. En caso afirmativo, se proporcionan los datos pseudo-anonimizados al investigador. En caso negativo, se preguntará al usuario si desea añadir dicho fin a un posible uso de sus datos.

○ En caso de que dichos datos no existan, pero sí existan usuario que cumplan con el perfil definido, se seleccionarán mediante código y a través de atención al cliente o mediante la App del usuario se les propondrá participar en un nuevo estudio para recoger los datos necesarios.

El perfil de participante:

● El participante puede acudir libremente a un córner de medición (punto itinerante de toma de información) o ser citado para un estudio por parte de atención al cliente a petición de un investigador. Se podría estudiar en el futuro la conexión a un sistema d gestión de citas que diera automáticamente las citas en los horarios definidos de acuerdo con los perfiles solicitados.

● El participante tiene acceso a sus datos brutos y en los casos en los que sea posible se le proporcionará un feedback de sus datos con información de interés. En la mayoría de las ocasiones los datos brutos no serán fácilmente interpretables.

● El participante podrá modificar los consentimientos informados de acuerdo a la ley de protección de datos y desde el IBV se le podrá solicitar si desea ampliar su consentimiento para que puedan ser utilizados con otro fin, pudiendo el participante aceptar o rechazar la solicitud.

El perfil de empresa:

● Flujos económicos y de suscripción aún por definir, pero podrá acceder a datos agregados de su interés cuando los participantes lo permitan a través del consentimiento informado. Se prevé que el participante reciba algún tipo de “compensación” por la cesión de sus datos para fines económicos (relacionados con empresas).

A continuación, se describen casos de uso basados en el diseño conceptual descrito.

2.1 CASO DE USO DE ALMACENAMIENTO DE DATOS PERSONALES En este caso se analiza cómo un participante inserta sus datos, cambia sus permisos, concede permisos, etc.

El participante en primer lugar deberá registrarse en el sistema, para ello, definirá un nombre de usuario (puede o no coincidir con su email), una contraseña y proporcionará su fecha de nacimiento.

En un primer diseño preliminar, el participante podría tener las siguientes funcionalidades en su interfaz de VALENCIA.DATA:

VALENCIA.DATA 9


● Mi perfil: Aquí existirán unas características básicas a las que deberá responder. No obstante, podrá ir ampliando la información para una mejor caracterización y que se le pueda proponer participar en más estudios o proyectos para los que se requiera un perfil de participante específico.

● Autorización para uso de mis datos: El usuario podrá consultar para qué fines ha autorizado el tratamiento de sus datos en función de la tipología de los mismos, pudiendo ampliar su autorización para otros fines o revocarla. En este apartado aparecerán avisos o solicitudes de si autoriza el tratamiento de sus datos para determinados fines con la correspondiente compensación (pendiente de definir).

● Mis datos o Mis informes: Aquí se almacenará el feedback respecto a los datos del participante agrupados en diferentes tipologías para que sean fáciles de identificar.

○ El usuario podrá acceder a sus datos brutos. No obstante, puede estar en un formato que sean difícil de interpretar y/o de mostrar. En cualquier caso, el acceso se podrá realizar bajo petición al Delegado de Protección de Datos.

● Participación en estudios: aquí aparecen los estudios en marcha sobre los que se ha solicitado su colaboración (siempre que su perfil cumpla con los criterios de búsqueda definidos por el investigador) Cuando se indique que se desea participar se le proporcionará una cita desde atención al cliente. Además, se tendrá acceso a herramientas de valoración on-line como SUMMA-T, o podrá consultar dónde se encuentran los lugares de participación en ese momento, por si desea acudir a realizarse alguna medición.

2.2 CASO DE USO DE PERFILADO PARA PROYECTOS DE I+D El objetivo de este caso es la localización de un perfil de participante, definido en una investigación, para solicitarles su autorización de uso de datos en la investigación.

El investigador o la investigadora dispondrá de una interfaz de usuario específica donde a modo de ejemplo se citan las siguientes funcionalidades:

● Descargar datos brutos donde los investigadores se identifiquen con un código para realizar el tratamiento correspondiente o para identificar mediante un análisis más complejo si los participantes cumplen con el perfil definido para un estudio específico.

● Cargar datos procesados, metadatos o informes/datos de feedback para el participante (identificado siempre por un código) tras haber realizado el tratamiento correspondiente.

● Realizar búsquedas de sujetos/participante (identificados con código) que cumplan un perfil definido para proponerles su participación en estudios, bien

10

sea rellenando algún cuestionario on-line o proponiéndoles acudir a un ensayo al IBV. Podrá realizar búsquedas simples on-line o descargar datos de una búsqueda simple y posteriormente indicar los códigos de los sujetos que cumplen con los criterios definidos para el estudio.

● Realizar búsquedas de datos que cumplan unas determinadas características (metadatos, datos brutos o procesados), ver si el fin está autorizado y poder solicitar autorización para un tratamiento agregado.

2.3 CASO DE USO DE DATOS DE PROYECTOS DE INVESTIGACIÓN A continuación, se describen dos ejemplos de casos provenientes de proyectos de investigación. Los datos de participantes que se obtienen en proyectos de investigación se tienen que almacenar en la base de datos de VALENCIA.DATA.

2.3.1 Estudio Carro-Mochila

Proceso del ensayo/ estudio en el marco de un proyecto:

1. Se define el perfil de participante necesario para los ensayos y desde atención al cliente del IBV, se busca a los usuarios y se les cita de acuerdo al horario definido para los ensayos.

2. Se realizan los ensayos de acuerdo al protocolo de ensayos (ver 2.3.1.1 Descripción del estudio y 2.3.1.2 Protocolo).

3. Tras realizar los ensayos de acuerdo al protocolo definido tendremos los datos brutos que se detallan en: 2.3.1.3 Datos para añadir a la base de datos.

4. Finalmente, tras el tratamiento de datos, deberían agregarse a la base de datos de VLC.DATA para cada participante, los datos procesados obtenidos (ver 2.3.1.3 Datos para añadir a la base de datos).

2.3.1.1 Descripción del estudio

El objetivo del estudio, que se utiliza como ejemplo, era realizar una comparativa entre el carro objeto de estudio con otro carro de la competencia en condiciones controladas con usuarios simulando acciones representativas.

Durante el ensayo se llevó a cabo:

● Análisis de movimiento para caracterizar la postura adoptada por el sujeto. Como resultado se han obtenido los ángulos adoptados de espalda y brazo utilizando cada carro.

● Cuestionario de satisfacción con el fin de comparar las características de los carros.

● Escaneado de cuerpo completo.

VALENCIA.DATA 11


La descripción del estudio que se va a realizar puede ser simple y utilizarse un campo de texto de la base de datos, o muy elaborado en documento aparte que debe poder guardarse en la base de datos y relacionado con el estudio.

2.3.1.2 Protocolo

El protocolo, al igual que la descripción del estudio, puede ser simple o muy elaborado.

El protocolo puede describir: - Como se toman las medidas de todos los sujetos que participan en el estudio - Cómo se codifican las medidas y guardan las medidas. - Cómo se procesan las medidas para obtener datos procesados.

El protocolo utilizado debe incluirse en la base de datos y estar relacionado con todos los datos obtenidos con dicho protocolo.

En este ejemplo los datos se anotan en una plantilla mientras se realiza el ensayo, y posteriormente se pasan los datos a una tabla de Excel.

El sujeto debe estar dado como participante en VALENCIA.DATA antes de aplicar un protocolo y tomar datos. De esta forma en las plantillas y tablas se podrán identificar los datos con el código de participante.

2.3.1.3 Datos para añadir a la base de datos

A continuación, se describen los datos que en este caso de uso se debe guardar en VALENCIA.DATA

Datos de los sensores de aceleración

Durante los ensayos se registraban datos de aceleración a través de unos sensores. Los que miden los sensores se guardan en un archivo:

u1_A_arr_acera1-000_00B41DCB.txt

El nombre del archivo identifica entre otras cosas: ● Codificación para indicar la parte del cuerpo con el que se corresponde la

medición: ○ Carrito: DD2 ○ Antebrazo: DD0 ○ Brazo: 69D ○ Espalda: DCB

12

● Codificación que indica la tarea que el usuario estaba realizando: ○ Empujar => em ○ Arrastras => arr ○ Giro => giro ○ Subir bordillo => bor ○ Subir rampa => sub ○ Subir 3 escalones => esc

Escaneado de cuerpo completo

Es un fichero que contiene la forma del cuerpo.

Los ficheros asociados a un dato deben guardarse también en la base de datos de VALENCIA.DATA

Datos del sujeto:

● Sujeto (aquí se indicaría el código de usuario individual para poder relacionarlo) ● Altura

Datos de la prueba:

● Repetición ● Carrito ● Carrito_tipo

Datos resultado del procesamiento de los ficheros de acelerometría:

● mean_trolley_pitch_angle_1 ● mean_trolley_pitch_angle_floor_1 ● mean_trolley_pitch_angle_floor_mod ● std_trolley_pitch_angle ● max_trolley_pitch_angle ● min_trolley_pitch_angle

VALENCIA.DATA 13


● range_trolley_angle mean_back_pitch_angle ● std_back_pitch_angle ● max_back_pitch_angle ● min_back_pitch_angle ● range_back_pitch_angle ● mean_shoulder_yaw_angle ● std_shoulder_yaw_angle ● max_shoulder_yaw_angle ● min_shoulder_yaw_angle ● range_shoulder_angle ● mean_elbow_angle ● std_elbow_angle ● max_elbow_angle ● min_elbow_angle ● range_elbow_angle ● mean_acel_trolley ● std_acel_trolley ● max_acel_trolley ● p95_acel_trolley ● min_acel_trolley ● p5_acel_trolley ● range_acel

Datos procesados del escaneado de cuerpo completo

● Escaneado 3D procesado ● Medidas unidimensionales procesadas:

14

Tabla de datos

Finalmente, todos los datos se organizan en una tabla. Cada fila es un “registro” que contiene todos los datos medidos a una persona en unas condiciones. Las columnas contienen información sobre:

• Sujeto: código para identificar de que persona son las medidas. • Las condiciones en las que se ha medido. • Las medidas que se han obtenido, incluyendo datos de la persona como altura,

peso, etc. • Los nombres de los ficheros de los que se extraen las medidas.

Cada fila de la tabla puede considerase un dato que pertenece a una persona. Cada columna de la fila es un campo del dato.

2.3.2 Estudio longitudinal para la prevención de caídas

En este caso se describe de forma somera una fase de una investigación longitudinal tipo, desarrollada en el IBV. La metodología utilizada se basa en recoger datos primarios de la ciudadanía mayor de 65 años en 4 sesiones, durante un periodo de tiempo acotado a la realización de una intervención no farmacología. Concretamente se ejemplifica el caso de uso utilizando como referencia el proyecto ISTOPFALLS (puede ver más información del proyecto en https://www.youtube.com/watch?v=AvCfC6PNMz8)

2.3.2.1 Descripción del estudio

El objetivo general del estudio fue analizar las mejoras en las variables biomecánicas relacionadas con las caídas en las personas mayores tras intervención no farmacológica con juegos serios.

Antes del inicio de la toma de datos es necesaria la localización de las personas participantes en el estudio, estas personas deben cumplir el perfil establecido en la investigación, en este caso 25 hombres y 25 mujeres con un intervalo de edad de 65 a 85 años.

Para la consecución del objetivo del estudio, fue necesario: • Realizar una intervención con juegos serios que fomentan las capacidades

funcionales de las personas. • Analizar, de forma longitudinal en 4 sesiones, mediante medidas objetivas

(escalas y pruebas biomecánicas) la evolución de las dimensiones personales que influyen en la probabilidad de caídas en las personas de mayor edad.

Las dimensiones personales analizada en este caso son: física, Cognitiva, probabilidad de caídas, actividad física/ Ejercicio, salud y grado de uso tecnología.

https://www.youtube.com/watch?v=AvCfC6PNMz8

VALENCIA.DATA 15


Las variables de cada una dimensión en cada una de las valoraciones se analizan con las escalas que se nombran en la Tabla 1 (Ver. Estas escalas recogen datos cuantitativos y cualitativos.

Los ensayos se realizarán en el domicilio de la persona participante. Dónde se realizan 4 sesiones en un total de 24 semanas, cada sesión se realiza con una diferencia de 8 semanas entre ellas.

Tabla 1: Ejemplo de 9 de las 45 escalas utilizadas.

Escalas y pruebas a realizar Inicio A las 8 semanas

A las 16 semanas

24 semanas

General

Consentimiento informado

Certificado médico: apto para participar en la investigación

Pruebas físicas

Physiological Profile Assessment (PPA)

Kinect Sit-To-Stand Test (K-STS)

Pruebas cognitivas

Mini-Cog dementia screening (Mini-Cog)/GP Cog

Caídas

Iconographical-Falls Efficacy Scale (Icon-FES)

Actividad Física

Physical Activity Enjoyment Scale (PACES)

Salud

European Quality of Life-5 Dimensions (EQ-5D)

Uso de tecnología

System Usability Scale (SUS)

En este caso la descripción del estudio es compleja necesita de un documento que se pueda subir a la base de datos de VALENCIA.DATA. Estos documentos que amplían la descripción adicional del estudio son “documentación adicional. Por

16

tanto, VALENCIA.DATA necesita un repositorio de documentos y/o un gestor de documentos.

2.3.2.2 Protocolo

Las escalas de toma de datos forman parte del protocolo de ensayo. El protocolo es un documento donde se establece el qué, cuándo, cómo, con qué y dónde se debe hacer cada una de las tareas del ensayo.

Durante la investigación se genera documentación que debe guardase con los datos generados. Es necesario disponer de esta información de forma asociada a los datos para en un futuro poder aumentar la muestra de datos con la misma metodología, asegurar la fiabilidad y repetibilidad de los mismos. Además, esta documentación permite la trazabilidad de la investigación y la transmisión de conocimiento entre investigadores/as. El protocolo en este caso se compone de varios documentos:

Los documentos base que se asocian a los datos de los ensayos son:

• Formulario de petición de localización de usuarios • Protocolo de ensayos (debe incluir escalas o/y descripción de instrumentos de

medida). • Metodología de tratamiento de datos.

La documentación asociada al protocolo puede generarse durante el estudio. Debe ser posible añadir documentación cuando se define el estudio, cuando se está realizando, y al finalizar el estudio.

2.3.2.3 Datos para añadir a la base de datos.

Una vez finalizados los ensayos se vuelcan los datos brutos a una Excel para a continuación realizar los análisis pertinentes y disponer de los datos procesados.

En cada una de las sesiones de valoración se cumplimentan las escalas correspondientes, según tabla 1. A continuación se vuelcan los datos de las misma en una Excel. Ver Figura 2: tabla de datos brutos escala de salud.

VALENCIA.DATA 17


Figura 2: Tabla de datos brutos escala de salud.

En algunas de las escalas se registra el dato bruto de cada una de las variables y luego la puntuación final de la misma, estos datos globales o puntuación final se vuelcan en otra Excel. Ver Figura 3.

Figura 3: tabla de datos de puntación total de varias escalas

Una vez finalizados los estudios es necesario hacer un análisis comparativo de los datos, en cada uno de ellos, por lo que se genera otra Excel para registrar estos datos.

18

Figura 4: tabla de datos de puntación total de varias escalas

Finalmente, tras el tratamiento de datos, deberían agregarse a la base de datos de VALENCIA.DATA para cada usuario, todos los datos obtenidos, por los motivos anteriormente indicados.

En un mismo estudio y para los mismos participantes se pueden generar colecciones de datos (tablas) diferentes. Será necesario que la base de datos contenga una entidad que identifique estos datos.

2.4 CASO DE USO CON APLICACIÓN EXTERNA En este caso se analiza cómo podría interaccionar una aplicación para guardar datos en VALENCIA.DATA. La diferencia con el caso anterior es que la aplicación es la encargada de guardar los datos que va adquiriendo. En el caso anterior hay un proceso manual realizado por un investigador. El investigador organiza los datos en una tabla para poder guardarlos en VALENCIA.DATA.

Como ejemplo, se ha escogido SUMMA-T (https://www.summa-t.com/). SUMMA-T es una aplicación web IBV donde en cualquier momento un usuario puede entrar y rellenar una encuesta. SUMMAT analiza los datos y genera informes para el usuario. Los datos de dichas encuestas y los informes de feedback para el usuario deberán ser incorporados al usuario de VALENCIA.DATA y el flujo de datos es continuo.

La comunicación con VALENCIA.DATA se debe realizar mediante APIs que proporciona VALENCIA.DATA y a las que llama la aplicación.

Los pasos a seguir serían: 1. SUMMA-T utiliza como gestor de usuarios a VALENCIA.DATA. Al darse de alta un

usuario en SUMMA-T, lo hace como participante en VALENCIA.DATA y con el mismo consentimiento informado.

VALENCIA.DATA 19


2. Los datos que va generando SUMMA-T se guardan en la base de datos de VALENCIA.DATA asociados al código del participante. Es decir, SUMMA-T utiliza como gestor de datos a VALENCIA.DATA.

3. SUMMA-T accede a VALENCIA.DATA para recuperar datos de un participante. SUMMA-T procesa los datos y genera el informe o feedback que le llega al usuario.

Las aplicaciones utilizan VALENCIA.DATA como gestor de usuarios y de datos. VALENCIA.DATA no procesa los datos. El procesamiento de los datos depende de cada aplicación, que será la encargada de proporcionar el feedback a los usuarios. Opcionalmente, la aplicación puede utilizar VALENCIA.DATA para guardar los informes de cada usuario.

● Posteriormente SUMMAT mandará todos los datos de los cuestionarios completados por los usuarios individuales y los informes en pdf a VALENCIA.DATA.

2.5 CASO DE USO DE SERVICIO DE EXPLOTACIÓN DE DATOS Los datos personales almacenados en VALENCIA.DATA pueden ofrecerse a empresas y otras entidades. Este servicio consiste generar paquetes de datos que cubran necesidades específicas, pero hay que diferenciar entre datos anónimos y datos personales.

2.5.1 Explotación de datos anónimos

Los datos anónimos no son datos personales. Por tanto, la entidad responsable de los datos (en este caso el IBV) puede generar paquetes de datos anónimos como servicio para empresas o centros de investigación.

Un ejemplo sería la generación de paquetes de datos con medidas antropométricas. Una empresa de calzado o ropa puede solicitar datos de dimensiones de perfiles específicos de personas para obtener medias de formas, tallas, etc.

Otro ejemplo sería la generación de paquetes de datos de la aplicación SUMMA-T sobre condiciones y bienestar laboral. Estos datos podrían servir para que una empresa se compare con otras similares, o tomar decisiones sobre políticas para mejorar el bienestar laboral de los trabajadores.

Cada paquete de datos puede necesitar diferentes tipos de tratamiento para que se considere como datos anónimos.

20

VALENCIA.DATA permite realizar búsquedas de datos por perfiles de participante, pero no anonimiza los datos. Es responsabilidad de la entidad responsable del tratamiento aplicar el proceso adecuado para anonimizar los datos en cada caso.

2.5.2 Explotación de datos personales

El consentimiento que da un participante al registrarse en VALENCIA.DATA solo permite el acceso a sus datos a la entidad responsable del procesamiento, y para los usos definidos en el consentimiento. No permite transferir datos, total o parcialmente a otra entidad.

No es posible definir consentimientos informados genéricos para la transferencia de datos. Por ello es necesario analizar cada caso o petición de datos realizada.

Ante una petición de datos personales, los pasos a seguir son: 1) Generar un consentimiento informado con al menos:

a. A quién se van a transferir los datos. b. Qué datos se van a transferir. c. El propósito o uso que van a tener los datos.

2) Realizar una búsqueda de los datos solicitados. 3) Identificar participantes cuyos datos se pretende transferir. 4) Enviar a los participantes identificados el consentimiento informado. 5) Registrar en VALENCIA.DATA la aceptación del consentimiento. 6) Transferir los datos de los participantes que hayan aceptado.

VALENCIA.DATA permite generar consentimientos específicos, enviarlos a participantes y registrar su aceptación. Los participantes tendrán acceso a los consentimientos que hayan aceptado.

VALENCIA.DATA 21


3 MODELO DE DATOS DE VALENCIA.DATA

Como resultado del análisis de los diferentes casos de uso explicados anteriormente, se ha definido un modelo de entidad-relación. Este modelo permite representar entidades de una Base de Datos mediante un diagrama y los atributos de cada entidad.

A partir del modelo de entidad-relación se han generado 18 modelos de uso que permitirán a los desarrolladores diseñar la web app de VALENCIA.DATA cumpliendo con las funcionalidades definidas en los modelos de uso (ver 3.2 Modelos de uso)

3.1 MODELO ENTIDAD-RELACIÓN

Figura 5: Diagrama Entidad-Relación

● Cada participante se caracteriza con una serie de “variables”/”metadatos” que definen su perfil y sus datos de contacto. Estos metadatos permiten realizar perfiles. Ejemplo de perfil: mujer mayor de 30 años qué practica deporte habitualmente.

22

● El dato debe perteneces a un único participante. Un participante puede tener guardados muchos datos diferentes. Por ejemplo los resultados de un ensayo de equilibrio, o el escaneado de la forma de su cabeza.

● Cada dato se encuentra descrito por las “variables” /” metadatos” que se definen en el mapa conceptual. Cada dato se recomienda que sea de una única tipología de dato, aunque puede estar compuesto por datos brutos y procesados.

○ Por ejemplo, en el caso de escaneados, en un mismo dato se podría incluir el dato bruto y los diferentes procesados, especificando en el protocolo con que se relacione tanto el protocolo de medida como de procesado y las fechas de ambos. O se podría considerar cada procesado como un dato en sí mismo a criterio del investigador.

● Cada dato está asociado con una “selección de participantes” (única para cada dato). Si es un dato secundario, además se relaciona con un protocolo de procesado (o varios) y un dato o datos iniciales. La selección de participantes puede ser simplemente “abierta a cualquier persona” o a una muestra con características específicas.

● Un mismo protocolo (de medida o de procesado) puede estar relacionado con varios datos y puede ser reutilizado en varias selecciones de participantes Así se facilitará la transferencia de conocimientos entre investigadores.

● Una selección de participantes está asociada siempre con al menos un protocolo de medida. Aunque puede asociarse con más de un protocolo.

○ Por ejemplo, en el caso de que, a un participante dentro de un proyecto, le hagamos un escaneado 3D y una encuesta SUMMAT.

■ Tendríamos una selección de participantes y una ficha técnica de trabajo.

■ 2 datos (uno para SUMMAT y otra para el escaneado 3D).

■ 2 protocolos (uno para SUMMAT y otro para el escaneado 3D).

■ Los datos procesados dependientes de cada uno de los datos se podrían incluir en el “dato inicial” SUMMAT o escaneado 3D que corresponda, o en un “dato secundario” relacionado con el dato inicial, incluirlo en el dato inicial o en uno secundario sería criterio del investigador. En ambos casos se incluiría el protocolo de procesado.

● Una ficha técnica de proyecto está compuesta de una o varias “selecciones de participantes”.

VALENCIA.DATA 23


3.1.1 Glosario: definición de “entidades”

● Participante: se refiere a cada una de las personas que colaboran en VLC.DATA realizando ensayos, encuestas, etc. y que ceden sus datos. En su perfil se incluyen datos de contacto a los que solo tendrá acceso personal administrativo, autorizado (rol Gestor definido más adelante). Además, se incluirán, entre otros los siguientes metadatos, características antropométricas, socio-demográficas y condiciones de salud, que permitan un mejor perfilado cuando se realicen búsquedas para los siguientes ensayos.

● Los metadatos pueden cambiar en el futuro o existir la necesidad de ampliarlos. Por tanto, debe haber algún mecanismo que permita el acceso a través del rol del administrador.

● SuperAdministrador/a: Crea entidades que son las responsables del tratamiento de los datos según la legislación vigente. Crea el rol de Administrador de las entidades. Inicialmente solo existirá la entidad IBV.

● Roles de personal de la entidad, con acceso al portal de gestión o administración.

○ Administrador/a: Crea y asigna cuentas de Gestor e Investigador. Tiene acceso a parámetros configurables de la aplicación.

○ Gestor/a: Tiene acceso completo al perfil del participante y a todos los datos. Puede modificar el perfil del participante y añadir participantes.

○ Investigador/a: Tiene acceso a todos los datos del participante y perfil pseudo-anonimizados (asociados a un código). No tiene acceso a datos de contacto como:

■ Nombre y apellidos

■ Correo, teléfono, y dirección.

■ Cualquier campo de mensajería que se añada en el futuro: Skype o similar.

● Dato: Normalmente un dato es un conjunto de mediciones que utilizan un mismo instrumento de medida y pueden explotarse de forma independiente. Pero es decisión del investigador la forma en que organiza los datos. En ocasiones el investigador/a, si está justificado y acordado para dicha tipología de datos, puede decidir incluir en el “dato” mediciones de diferentes equipos, o también diferentes procesados a partir de un dato bruto. Esos procesados podrían incluirse dentro del mismo “dato” por considerarse que dependen del mismo.

24

○ Por ejemplo:

■ Si en una misma sesión se mide antropometría y SUMMAT, serían 2 “datos” distintos con sus correspondientes procesados.

■ Si en una sesión se mide acelerometría en sensores colocados en diferentes partes del cuerpo, se considerarán un único dato.

■ Si en una sesión se obtiene el peso y la altura del participante, el investigador puede calcular el Índice de Masa Corporal (IMC) y guardarlo en el mismo Dato, aunque el IMC es un dato procesado. En otros casos más complejos el Investigador puede decidir guardar los datos del procesamiento como un Dato separado, indicando una referencia al Dato o Datos que se han utilizado para obtener el dato procesado/secundario.

■ Los cuestionarios realizados a la vez que otras mediciones se almacenarán en el mismo dato. No obstante, habría que considerar si algunos de los parámetros deberían formar parte de los metadatos que caracterizan al “dato”.

○ Dentro del “dato” se pueden incluir los siguientes metadatos (definición de metadato en el siguiente punto:

■ Características sociodemográficas y antropométricas del participante en el momento del ensayo extraídas de su perfil de usuario.

■ Tipología/formato del dato. Por ejemplos, escaneado 3D cuerpo completo, fallskip, summat, etc…

■ Dato inicial/dato secundario.

● Dato inicial: Primer dato (ver definición de dato) que se obtiene después de la aplicación de un protocolo de medida. Puede contener datos brutos y procesados que no suelan ser utilizados de forma independiente.

● Dato secundario: Dato que es obtenido mediante el tratamiento o procesado de un dato o datos iniciales mediante un protocolo de procesado.

■ Fecha de obtención

■ Fiabilidad

VALENCIA.DATA 25


■ Etc.

● Consentimientos de tratamiento de datos. Todos los datos tienen al menos un consentimiento: el consentimiento que da cada participante al darse de alta en VLCDATA. Se pueden añadir consentimientos a datos específicos. Por ejemplo:

○ Consentimiento para transferir datos a otra empresa o profesional ajeno al IBV.

○ Consentimiento para que el IBV utilice los datos con un propósito diferente al establecido cuando el participante se da de alta.

● Consentimiento informado de medida, o de protocolo de medida. Este consentimiento no tiene nada que ver con el almacenamiento o uso de los datos. Este consentimiento es la información que se le da al participante antes de medir, cuando el protocolo de medida puede implicar algún disconfort o consecuencia. Por ejemplo, dolor, fatiga, etc.

Este consentimiento deberá ir con una rúbrica del participante. No es suficiente con un click del ratón. Estos consentimientos pueden ser tomados en papel, y posteriormente escaneados y guardados en PDF.

No es necesario que estos consentimientos puedan ser consultados por los participantes. Opcionalmente, el gestor y el investigador pueden guardarlos y buscarlos en la base de datos. El sistema de gestión debe poder relacionar estos consentimientos con:

o El participante.

o La ficha técnica de trabajo

o La selección de participantes.

Hay datos y/o protocolo que no tendrán asociado este tipo de consentimiento. Por ejemplo:

○ Una encuesta on-line.

○ Los datos de geolocalización que transfiere una app desde el móvil del usuario.

● Metadato: Datos altamente estructurados que describen características de los datos, como el contenido, calidad, información y otras circunstancias o atributos.

● Ficha técnica de trabajo: Describe el material y métodos Proporciona información de:

○ Cómo se mide

26

○ Con qué se mide.

○ A quién se mide,

○ Cuándo se mide.

Una ficha técnica de trabajo debe estar compuesta por una o varias selecciones de participantes (¿a quién?), y cada selección participante tiene uno o varios protocolos (¿cómo? ¿con qué?). Además de otros metadatos de interés:

○ Documento descripción (texto)

○ Fecha de toma de dato

○ Año

○ Investigador/a responsable

○ identificación del proyecto en del ERP1 que utiliza la entidad. IBV utiliza NAVISION como ERP.

○ Etc.

● Selección de participantes: Define a quién se mide, por ejemplo, a un grupo de participantes que van a participar en el mismo proceso de toma de datos. Cada selección de participantes está relacionada con uno o varios protocolos (¿cómo se obtienen los datos? ¿con qué se obtienen los datos?). Y cada selección de participantes se podrá relacionar únicamente con una ficha técnica.

Contendrá una descripción de perfiles y cupos de participantes con la que se podrá realizar la búsqueda de los mismos.

○ Descripción perfil objetivo (sexo, edad, IMC, etc.…) Puede ser “libre” donde cualquier participante podría incluirse.

Ejemplo: Una ficha de trabajo con 2 selecciones de participantes:

Selección de participantes 1: mujeres adultas para medir equilibrio con NedSVE (protocolo A). Descripción perfil objetivo: 5 mujeres entre 20 y 30 años, 5 mujeres entre 30 y 40 años, y 5 mujeres entre 40 y 50 años.

Selección de participantes 2: mujeres mayores para medir equilibrio con FallSkip (protocolo B). Descripción perfil objetivo: 5 mujeres entre 50 y 60 años, 5 mujeres entre 60 y 70 años, y 5 mujeres entre 70 y 80 años.

● Protocolo: Define ¿cómo? ¿con qué? y ¿dónde?. Los protocolos con los que se relaciona un dato deben ser necesariamente “protocolos de medida” o

1 Sistema de planificación de recursos empresariales (ERP, por sus siglas en inglés, enterprise resource planning).

VALENCIA.DATA 27


“protocolo de procesado” que se describen a continuación. Protocolo en el mapa conceptual define una entidad abstracta, el metadato “descripción” sería una variable a definir en ambas tipologías de protocolo. Un protocolo puede ser un documento complejo de muchas páginas, o algo muy simple, como un texto que indique el aparato con que se ha medido. Por ejemplo: “Medido con reloj POLAR modelo XXX”.

Los protocolos pueden contener, o dividirse en:

○ Protocolo de medida: Define ¿cómo? ¿con qué? y ¿dónde?. Debería poder ser “reutilizable” para ensayos, en caso de medir las mismas variables con los mismos instrumentos de medida para que los “datos” relacionados con diferentes “fichas técnicas” pudieran ser comparables.

■ En caso de que el procesado para el mismo ¿cómo? y ¿con qué? fuera siempre el mismo, entonces sí lo incluiría dentro del protocolo.

■ Incluirá los siguientes metadatos:

● Documento descripción

● Normativa relacionada

● Frecuencia muestreo

● Equipo de medida

● Descripción general del recurso para la toma de datos. Por ejemplo: técnico/a con perfil sociosanitario que disponga conocimientos para la toma de medidas antropométricas, o con formación específica en habilidades sociales.

● Descripción de laboratorio o espacio en campo. Por ejemplo, comedor en casa particular con 16 metros cuadrados

● Procesado (algoritmos) en caso de que formen parte intrínseca del protocolo de medida y sean siempre utilizados conjuntamente.

● Etc.

○ Protocolo de procesado: Define cómo se realiza el tratamiento o procesado de los datos a partir de un dato inicial.

■ Incluirá los siguientes metadatos:

28

● Documento descripción

● Algoritmos

● Versión

● Tratamiento de datos realizado

● Etc.

3.2 MODELOS DE USO

3.2.1 Participante solicita darse de baja (borrado de todos sus datos)

Borrado implica la eliminación de VALENCIA.DATA del participante y todos sus datos. Existe un plazo legal de 30 días para borrar al participante.

El borrado solo lo puede realizar el rol Gestor, y únicamente si existe una petición del participante. La aplicación no permite al gestor borrar al participante hasta que hayan transcurrido 20 días de la petición. Este plazo se establece para permitir al IBV anonimizar los datos antes de borrarlos si lo considera necesario.

Este plazo de 20 días (y el de 30) puede cambiar en el futuro. Por tanto, debe haber algún mecanismo que permita acceso al código para cambiarlo, o que sea configurable a través del rol del administrador.

El participante debe disponer en la aplicación de un menú o campo al entrar a su perfil que le permita:

1. Solicitar darse de baja

2. Una vez solicitada la baja debe poder ver en su perfil que ha solicitado la baja y el estado del proceso de la misma (por ejemplo, baja en trámite, quedan XX días para que su baja sea efectiva.

3. Retirar la solicitud de baja mientras el gestor no lo haya borrado definitivamente.

Pasos: 1. El participante solicita la eliminación de sus datos. Al solicitarlo se envía un

correo al participante indicando que:

a. Sus datos serán eliminados en un plazo máximo 30 días.

b. Que durante ese plazo y mientras su cuenta exista puede retirar su petición de baja.

2. El participante aparece en una vista, o tabla, de participantes pendientes de borrar.

VALENCIA.DATA 29


3. Llega una notificación al gestor indicando el código de participante que desea ser borrado.

4. A los 20 días llega una segunda notificación al gestor.

5. El participante aparece resaltado en la tabla de pendientes de borrar.

6. Entre el día 20 y 30 el gestor procede a borrar al participante. En el momento de borrado se envía un correo al participante indicando que su cuenta se ha dado de baja y sus datos eliminados.

7. Si se cumple el plazo de 30 días sin que se haya borrado al participante, se envía un segundo mensaje al gestor con copia al administrador.

Si antes de la eliminación el participante retira la petición de baja: 1. Se envía un mensaje al gestor notificando la retirada. 2. El participante desaparece de la vista o pestaña de participantes pendientes de

borrar.

3.2.2 Participante accede a modificar los datos de su perfil

El participante podrá en todo momento modificar los datos de su perfil obtenidos mediante:

- Ficha de alta de participante. - Encuesta de alta de participante.

NOTA: El perfil de participante podrá contener campos que solo puede completar el gestor y que el participante ni verá, ni podrá modificar. Por ejemplo

3.2.3 Participante consulta sus datos en el SISTEMA

El participante tendrá acceso a sus datos en el sistema mediante las fichas de trabajo. - Podrá ver los títulos de las fichas de trabajo con las que se han guardado datos

suyos. Tendrá una vista con los títulos de las Fichas y número de datos para cada ficha.

El participante podrá descargarse los datos eligiendo fichas de trabajo.

3.2.4 Gestor busca y convoca participantes para un proceso de adquisición de datos.

Un investigador redacta una ficha técnica de trabajo en la que describe uno o varios perfiles de participantes (Selección) y el número de participantes que necesita de cada perfil.

La ficha llega al gestor. Y el gestor define una búsqueda o filtro para cada uno de los perfiles definidos en la ficha.

30

Como resultado del filtro el gestor encuentra un número de participantes que cumplen el perfil solicitado. Se entiende como proceso de adquisición de datos el participar en unos ensayos, contestar a una encuesta, etc.

El gestor marca todos o parte de los participantes para guardarlos en una lista de “posibles participantes en el proceso de adquisición”.

El gestor contacta con los participantes (email, teléfono, etc) para preguntarles si desean participar. El contacto se puede realizar:

A. Por grupos. Por ejemplo, enviando un email a grupos de 5 - 10. En función de la respuesta decide contactar con más participantes.

B. Uno a uno. C. Todos a la vez.

El proceso de adquisición puede requerir establecer un calendario de citas (tipo sistema de reservas) o no. Ejemplos:

a) Hace falta calendario de citas para un ensayo en laboratorio porque solo se puede ensayar a un determinado número de personas a la vez.

b) No hace falta calendario de citas para rellenar una encuesta online.

A medida que los participantes aceptan participar, el gestor marca en la lista de posibles participantes a aquellos que han aceptado participar, y va estableciendo las citas si hace falta.

Una vez se llega al número de participantes requerido, el gestor puede eliminar de la “lista” los sobrantes: aquellos que no han aceptado participar, o que no se le ha llegado a pedir que participen.

La lista de participantes se guarda. De forma que el gestor puede buscar participantes que en el pasado participaron en procesos asociados a una ficha técnica de trabajo. Esto es útil por dos motivos:

1) En ocasiones interesa evitar que un participante vuelva a participar en procesos de adquisición de datos similares y recientes en el tiempo.

2) Y a veces lo contrario: pedir que repitan unas pruebas que ya han realizado.

Puede ocurrir que no se llegue al número de participantes que necesita de cada perfil. En esos casos el gestor puede consultar con el investigador y ampliar el campo de búsqueda de participantes. En este caso el gestor añade a la lista participantes que no cumplen estrictamente con el filtro inicial.

3.2.5 Gestor invita a participantes a completar datos de su ficha (perfil)

El participante no está obligado a rellenar todos los campos de la encuesta.

El gestor puede buscar participantes que no hayan rellenado un determinado campo y enviarles un mensaje sugiriendo que lo rellenen.

Este caso es útil cuando se buscan participantes para una ficha de trabajo. Si no encuentra suficientes participantes que cumplan un perfil, el gestor puede buscar aquellos que lo cumplen parcialmente y no han contestado alguna de las preguntas.

VALENCIA.DATA 31


3.2.6 Gestor comunica a Investigador lista de participantes

El gestor puede imprimir o exportar las listas de participantes (excel, csv). El gestor decide qué campos del perfil adjunta junto con el código de participante.

Esta lista impresa, o exportada, es la que utilizará para comunicar al investigador los participantes.

NOTA: el gestor puede incluir en la lista el nombre y otros datos personales si el investigador los necesita para recibir al participante en el laboratorio. El investigador es responsable de destruir la lista.

3.2.7 Gestor amplía la ficha de participantes (perfil)

Los campos del perfil pueden modificarse y ampliarse: - Añadiendo, eliminando o modificando preguntas de la encuesta. - Añadiendo, eliminando o modificando campos del perfil oculto al que no tiene

acceso el participante.

3.2.8 Investigador crea nueva Ficha de trabajo

La ficha de trabajo será el punto de entrada para que el investigador agregue nuevas colecciones de datos al sistema. Constará de:

1) OBLIGATORIO. Alias ficha. Servirá para identificarla dentro del sistema. Debe ser unívoco, sin repeticiones.

2) OBLIGATORIO. Nombre descriptivo (Título). Breve descripción de la ficha de proyecto

3) OBLIGATORIO. Resumen. Campo de texto con un resumen de la ficha de trabajo. 4) OPCIONAL. Documento descriptivo. Descripción ampliada (un Word) 5) OBLIGATORIO. Fecha de creación 6) OPCIONAL. Referencias a proyectos IBV 7) OBLIGATORIO. Una o varias selecciones de participantes.

Referencias a proyectos IBV:

El IBV clasifica el trabajo en su ERP por proyectos. Cada proyecto tiene un código y un acrónimo. El investigador puede añadir a la ficha de trabajo el código y acrónimo del proyecto para futuras búsquedas. Lo más habitual es que una ficha de trabajo esté relacionada con un solo proyecto. Pero a veces puede ocurrir se utilice el mismo trabajo en varios proyectos.

La inclusión del código y acrónimo del proyecto es opcional. Pueden generarse fichas sin asocial al proyecto, pero el interfaz debe preguntar siempre si se desea relacionar la ficha con algún proyecto.

Cuando se incluye el proyecto hay que asegurar que dicho proyecto existe en el ERP del IBV. Para ello se puede hacer un proceso que cargue datos de proyectos en alguna colección de MongoDB una vez al día. O se puede consultar la

32

información en tiempo real utilizando un usuario sql*server del ERP del IBV, atacando directamente a las tablas o vistas sql del ERP.

El investigador define una o varias selecciones de participantes incluidas en la ficha de trabajo. Una selección son los participantes que van a participar en el mismo proceso de adquisición de datos (usando los mismos protocolos). Implica que el investigador quiere conseguir los mismos datos de todos ellos. Por ejemplo, el investigador quiere 5 hombres y 5 mujeres para hacer un ensayo de fatiga con diferentes zapatos. Y los datos que quiere conseguir son su frecuencia cardiaca y su opinión sobre el confort del zapato. Para cada selección describe:

1) OBLIGATORIO. Nombre descriptivo. Permite identificar la selección dentro de la ficha.

2) OBLIGATORIO. Perfiles de los participantes. El perfil es el criterio de búsqueda que utilizará el gestor. (Actualmente el IBV utiliza un documento WORD)

3) OBLIGATORIO. Ensayos o procesos de captación de datos. Es la información que utiliza el gestor para informar a los participantes. (Actualmente el IBV utiliza un documento WORD)

4) OBLIGATORIO. Fechas previstas de inicio y fin. Estas fichas sirven al gestor para establecer un calendario de citas con los participantes.

5) OBLIGATORIO. Referencias de los protocolos que se van a utilizar. El investigador los selecciona de la colección de protocolos existentes o los crea si no existen.

Una vez creada la ficha, el investigador que la crea es el único que puede modificarla. Le denominamos el investigador responsable. El investigador responsable puede transferirla a otro investigador para que continúe el trabajo si hace falta. NOTA: un administrador tiene que tener la posibilidad de cambiar el investigador responsable de forma excepcional, por ejemplo, en caso de baja por enfermedad.

Una vez finalizada la ficha el trabajador la marca para que le llegue al gestor. NOTA: El investigador debe notificar al gestor cambios que puedan afectar a la selección de participantes.

3.2.9 Investigador busca y consulta Protocolos

Un investigador puede buscar protocolos de diferentes formas: 1) Protocolos que aparezcan en datos que contengan determinados campos o

combinación de ellos. Ejemplos: a) Lista de protocolos utilizados en datos que contengan el campo “longitud

del pie” b) Lista de protocolos utilizados en datos que contengan el campo “longitud

del pie” y generados entre los años 2014 y 2019. c) Lista de protocolos utilizados en datos en los que el campo “Proyectos”

contengan el código “PROY19/00001” 2) Lista de protocolos utilizados en fichas de trabajo que cumplan alguna de estas

condiciones:

VALENCIA.DATA 33


a) en las que el campo “Proyectos” contengan un código determinado, por ejemplo: “PROY19/00001”

b) en las fichas de trabajo de determinado investigador. 3) Buscar dentro de la colección de protocolos. Ejemplos:

a) Por una palabra o texto en el campo “Título” del protocolo, o metadatos que incluidos en el protocolo.

3.2.10 Investigador crea nuevo Protocolo, o lo modifica.

Un protocolo tendrá los siguientes campos: - OBLIGATORIO. Número de versión. Campo creado automáticamente por el

sistema. - OBLIGATORIO. Título. - OBLIGATORIO. Resumen. Texto descriptivo. - OBLIGATORIO. Etiquetas. Es obligatorio poner al menos una. Al introducir la

etiqueta la interfaz debe sugerir el uso de etiquetas similares ya existentes. - Opcional. Ficheros adjuntos. Normalmente serán documentos de WORD. Para

cada fichero adjunto es OBLIGATORIO tener un campo de descripción.

Un protocolo nuevo puede crearse desde cero, o a partir de la copia de una existente. La copia se puede asimilar a “Guardar como”.

No pueden modificarse un protocolo que ya ha sido utilizado en algún dato (incluyendo los ficheros adjuntos). La modificación de protocolos utilizados implica la generación de una nueva versión.

NOTA: En el caso de que un investigador detecte un error en el protocolo ya utilizado, el administrador podrá realizar los cambios. Se entiende por error que el protocolo no refleja correctamente el proceso de adquisición de datos que ya están guardados en el sistema.

3.2.11 Investigador almacena Datos de una Ficha de trabajo

El investigador responsable o autorizado, una vez obtenidos los datos mediante aplicaciones externas a este sistema, podrá almacenarlos en el sistema.

Para ello subirá una excel o fichero csv donde: ● La primera fila indicará la estructura de los campos del json de datos en el que

se convertirá. ● Cada fila contendrá un dato de un participante (una tupla de datos en realidad). ● En la primera columna se identificará a los participantes con el código interno de

ValenciaData ● Cada celda de una tupla contendrá un dato o una referencia a un fichero (que

deberá subirse al sistema también).

Cada conjunto de datos (fichero excel/csv) deberá almacenarse en el sistema caracterizándose por:

34

1) OBLIGATORIO. Ficha técnica de trabajo y una selección de participantes de dicha ficha. En el momento de subir los datos el interfaz preguntará al investigador a qué selección de participantes y ficha de trabajo corresponde. En el IBV la forma habitual de buscar Fichas será buscar fichas asociadas a un Proyecto.

NOTA: Antes de subir un conjunto de datos hay que confirmar los protocolos. En la ficha de trabajo están ya definidos protocolos para cada selección. Estos protocolos se muestran al investigador (por ejemplo, código y título) y el investigador decide si los confirma o pone otros. Esto se realiza porque durante el proceso de adquisición de datos el investigador puede haber modificado el protocolo.

3.2.12 Aplicación externa almacena Datos en un proceso automático.

El IBV puede integrar aplicaciones externas en el sistema que almacenan de forma automática datos en el sistema mediante un API-REST. En este caso, el único campo obligatorio es el identificador de participante.

La aplicación deberá incluir junto con el dato: 1) ID Ficha técnica de trabajo. 2) ID Selección de participantes.

El sistema deberá verificar que el participante, la ficha, proyectos y protocolos existen antes de subir datos. En caso contrario devolverá un mensaje de error.

3.2.13 Investigador descarga Datos de una Ficha de trabajo

De manera inversa al caso de uso anterior, un investigador podrá descargarse los conjuntos de datos correspondientes a una ficha de trabajo concreta.

Cualquier investigador podrá descargar los datos de cualquier ficha de trabajo, sin necesidad de estar autorizado.

En el proceso de descarga, el investigador obtendrá un fichero excel/csv por cada selección de participantes que formen parte de la ficha. La estructura de ese fichero será igual que en la subida (primera fila etiquetas de campos, primera columna identificadores de participantes).

El investigador podrá decidir si junto a cada fichero estructurado de datos se descargan también los ficheros referenciados en él. Como estos ficheros pueden ser muy pesados, sería deseable que pudiera elegir cuáles necesita descargar y cuáles no.

3.2.14 Investigador busca Datos de varias fichas de trabajo (incluidas las asociadas a aplicaciones)

Un investigador podrá buscar datos combinando diferentes entradas: 1) Perfil de usuario en el momento de generación del dato. Ejemplo: Mujeres, de

30 a 40 años, con hijos menores.

VALENCIA.DATA 35


2) La existencia de un campo en el dato. Ejemplo: el dato contiene el campo “longitud del pie”

3) Valores de campos en el dato. Ejemplos: a) El campo “Proyectos” contiene “PROY0001” b) El campo “Protocolos” contiene “PROT0001” c) El campo “Longitud del pie” es mayor de 20

3.2.15 Administrador gestiona usuarios y roles

El rol de administrador permitirá dar de alta, modificar y eliminar usuarios. Además, les podrá asignar y desasignar roles de Participante, Gestor, Investigador y Administrador.

Los datos de los usuarios que tengan rol de participante, antes de borrarlos, podrán ser sometidos antes a un proceso de anonimización.

3.2.16 Administrador gestiona Fichas de trabajo

Sólo el administrador podrá modificar e incluso eliminar fichas de trabajo que ya tengan datos.

Eliminar una ficha de trabajo implica la eliminación de la selección de participantes que la forman (no de los participantes, sólo la selección) y de los datos que se hayan tomado para la misma.

Modificar una ficha de trabajo, cuando afecte a la selección de participantes, implica la generación de avisos al investigador autorizado en la ficha, para que modifique la búsqueda de usuarios si es necesario. Además, puede implicar el borrado o reasignado de datos ya existentes de un participante de esta ficha de trabajo.

Las altas de fichas de trabajo las podrán realizar tanto investigadores como administradores.

3.2.17 Administrador gestiona Protocolos

Sólo el administrador podrá modificar e incluso eliminar protocolos que ya tengan datos asociados.

El administrador podrá realizar operaciones masivas de reasignación de datos a protocolos, así podrá, en caso de detectar un protocolo repetido o equivalente, reasignar todos los datos de un protocolo a otro y eliminar el duplicado.

Las altas de protocolos las podrán realizar tanto investigadores como administradores.

3.2.18 Administrador gestiona Datos

Sólo el administrador podrá modificar datos guardados en el sistema.

El administrador podrá realizar operaciones masivas para modificar nombres de campos de los datos, añadir campos o modificar valores. Estas se realizarán de forma excepcional.

diseño conceptual de la plataforma valencia

Documents