PI2-SecurHome Deliverable - Informe 2 Seguimiento del Proyecto individual 2

En el marco del Proyecto Individual 2 integrado en el Proyecto Coordinado SecurHome (a continuación PI2-SecurHome), el presente Deliverable tiene por objeto sistematizar el desarrollo técnico. del ecosistema PI2-SecurHome ("Aplicación móvil encargada de la interacción del hogar por el medio"). de la televisión") con el apoyo del sistema de televisión iNeighbour.

Es igualmente presentado el funcionamiento tecnológico de las respectivas aplicaciones cliente y del API para permitir el acceso a los datos respectivos por parte del sistema asociado con el sistema proyecto individual 1.

Introducción 

El objetivo principal de este documento es presentar y describir todos los procedimientos llevados a cabo por el equipo de investigación del proyecto individual 2, del programa coordinado SecurHome, en el marco del desarrollo del ecosistema PI2-SecurHome ("Aplicación móvil encargada de la interacción domestica por medio de la televisión"). Se presta especial atención a la descripción de la estructuración de este ecosistema, destacando los componentes de procesamiento del lado del servidor y de gestión de la base de datos. 

El ecosistema PI2-SecurHome, soportado por el sistema de TV iNeighbour, se materializa en el siguiente conjunto de aplicaciones cliente, complementadas con una API para acceder a los datos respectivos por parte del sistema asociado al proyecto individual. 

Puesta a disposición de los usuarios senior para el registro las interacciones televisivas y visualización de recordatorios (medicamentos y consultas).

Puesta a disposición de los usuarios cuidadores para la gestión de las personas a su cargo y la emisión de recordatorios médicos.

Puesta a disposición de los usuarios cuidadores para el seguimiento de las personas dependientes a su cargo y la recepción de alertas.

Desde el punto de vista tecnológico, se utilizó un esquema de desarrollo basado en código, compatible con todas las aplicaciones y que permite la creación de un entorno de desarrollo. 
integrado, capaz de responder eficazmente a estas necesidades. 

Para la implementación de la aplicación de TV se utilizaron STBs comerciales del sistema IPTV comercial MEO. El hecho de que estos STBs estén equipados con middleware de Mediaroom significa que el desarrollo del código del lado del servidor se hizo en C# mientras que la aplicación Admin (backoffice de todo el sistema) se desarrolló usando el framework.NET. La aplicación TV fue desarrollada con la framework Presentation Framework. 

El proyecto se complementó con una base de datos SQL en la que se almacenan los datos relativos a todas las aplicaciones del proyecto. 

2.1.2 Ámbitos de aplicación específicos 

Iniciar sesión 

Al iniciar la aplicación, se le pide al usuario que elija uno de los usuarios disponibles en su casa y que introduzca el PIN de ese usuario. Si el PIN es correcto, el usuario inicia sesión en la aplicación y cambia al Menú. De lo contrario, el usuario recibe información de que el PIN estará incorrecto y regresa a la ventana de diálogo de elección de los usuarios. Hasta este punto, la aplicación se controla a través de Default.aspx y Access.aspx. El archivo Default.aspx muestra la pantalla de bienvenida y redirige la aplicación a la página Access.aspx donde el usuario puede iniciar sesión. 

Menú 

Después de iniciar sesión, el menú SecurHomeTV aparece en la parte superior del televisor, mientras que la radiodifusión televisiva sigue estando disponible. Seleccionando cada una de las opciones de menú (aparte de la opción de menú a la opción "Off"), aparecerán los diferentes submenús del área elegida y un panel de menús se deslizará a la siguiente pantalla hasta el límite inferior del televisor, con la información del primer submenú cargada por defecto. 

Submenú y Detalle 

El contenido de cada submenú varía en función del submenú, aunque en varias áreas la estructura y funcionamiento es similar. El detalle de cada opción elegida puede surgir a través de una animación de diapositivas del panel que revela la información pulsando un botón en la parte superior del panel que le permite volver al área anterior o, alternativamente, a través de una ventana emergente con una transparencia reducida para permitirle centrar su atención en él y no en el contenido de la televisión. 

La selección de opciones que aparece se controla a través de la página EventsTopLayer.aspx. Esta página ha sido diseñada para funcionar independientemente del resto de la aplicación. En redirección 
para esta página, que se realiza a través de una SubmitAction, se deben indicar dos parámetros: el parámetro id del botón que activa la acción de invocación emergente y una palabra clave que se utiliza en la página EventsTopLayer.aspx.cs para identificar qué opciones mostrar en la ventana emergente. En la misma página está creado un xml virtual que guardará las opciones a mostrar en el popup, así como las acciones a realizar si se elige una opción.

El xml servirá de puente entre la información que se va a poner a disposición y la TvPhysicsControl de red que muestra la información en el televisor. Dependiendo de la palabra clave que se recoja en el archivo en la parte superior de la página, el xml se construye con dos campos principales, texto para mostrar en el televisor y url para el que NavigateAction se ejecute. Si sólo necesita elegir una opción, entonces la opción muestra el mensaje "Opción guardada" y se cierra automáticamente. De lo contrario, y a través de un parámetro de salida determina que no debe cerrarse y con la nueva palabra clave sabe qué opciones mostrar. El proceso se repite hasta que todas las opciones sean elegidas. Para suavizar la apariencia de la ventana emergente se utilizan dos animaciones propias del framework: FadeAnimation y ZoomAnimation. En cualquier momento el usuario puede cerrar la ventana emergente sin seleccionar una opción utilizando el botón Atrás del mando a distancia, como por ejemplo al que se hace referencia en el mensaje que se encuentra debajo de la ventana emergente. También hay una serie de validaciones que dependen de cada opción. En el caso de la selección de fechas, por ejemplo, la fecha actual siempre se tiene en cuenta para que el usuario no pueda elegir una fecha anterior. Los días, meses, años, horas y minutos se muestran, no en orden ascendente, sino en un panel circular con el foco inicial en la opción actual (hoy, mes en curso...). En el caso de la elección de los usuarios para enviar las invitaciones, a medida que se eligen usuarios, éstos desaparecen de la ventana emergente, de modo que el usuario no envíe la misma invitación más de una vez a la misma persona. 

El tratamiento de los datos seleccionados se realiza mediante código JavaScript que se incluye en la página Mainpage.aspx a través del control TvScript. La comunicación entre las opciones elegidas en la ventana emergente y la opción la página Mainpage.aspx se realiza a través de SendEventAction. En SendEventAction se comunican los datos recogidos en Json a través de las opciones seleccionadas en la ventana emergente. Estos son recogidos por Javascript a través de su función Eval y convertido en objetos que se guardarán o mostrarán en el directorio TV según sea necesario. 

2.2 Aplicación Admin  

La aplicación Admin está, como el resto del proyecto, alojada en la máquina virtual de la plataforma  AlticeLabs. En cuanto al desarrollo de la página web, se ha utilizado una estructura básica que permite la creación de un diseño global de la aplicación. Por lo tanto, y utilizando las capacidades de .NET Framework, fueron enlazadas dos master pages que sirven como cuerpo de todas las páginas del sitio web. 
La página "Master.master" tiene la misión de crear la estructura global de la aplicación mientras que la página "Menu.master" tiene la misión de crear el menú que permite la interacción con los usuarios del sitio. así como los widgets que siempre están presentes a lo largo de la aplicación. 

Después de la creación de estas dos páginas la aplicación se ejecuta en una lógica de páginas donde se encuentran el html y el código del servidor (C#) necesarios para el funcionamiento disponible en cada una de las áreas respectivas. 

Sin embargo, el código que se repite en varias áreas se centró en el archivo "inWebPage.cs". cuya clase se extiende en todas las clases de páginas específicas del sitio. 

Paralelamente a este código, la aplicación también utiliza, al igual que la aplicación de TV, la función Capas de interacción iNeigDAL e iNeigBLL a través de las cuales se comunica con BD y proporciona todos los datos relativos al usuario. 

2.3 Aplicación móvil 

La aplicación móvil, titulada SecurHome Mobile, está dirigida a cuidadores de personas mayores. En esta aplicación, el cuidador puede acceder a los datos de consumo de la televisión y, de este modo, monitorizar la actividad del sénior en tiempo real con el fin de prevenir posibles accidentes en el hogar. 

Rutina del servidor 

Además de la monitorización manual del cuidador, se desarrolló una Console Application para comprobar, durante un cierto periodo de tiempo, la actividad de la persona mayor, cruzándola con sus hábitos de consumo diario. Basándose en las desviaciones estándar y utilizando información específica de la aplicación del ITPV (eventos y horario de medicación), el sistema emite alertas a los cuidadores con diferentes grados de gravedad. 

Estas alertas, que van desde una escala cromática verde (sin alertas) hasta una roja (la más grave) son recibidas por correo electrónico o SMS por el cuidador, que puede ignorarlas, informar al sistema de que no hay ningún problema con la persona de edad avanzada de que se trate, o tomar otro tipo de precauciones para resolver el problema detectado por el sistema. 

2.4 Sistema de alerta 

El modo de funcionamiento del algoritmo de generación de alertas es secuencial y acumulativo. Todos los usuarios son analizados uno por uno por el sistema utilizando un conjunto de criterios secuenciales que simplemente pueden interrumpir el proceso o hacerlo ir en diferentes direcciones dependiendo de los datos analizados anteriormente. 

El proceso de análisis de un usuario pasa por 3 fases. El primero, un análisis general es el mismo para todos los usuarios; el segundo depende del status del usuario en la aplicación (online/offline); y el tercero, que consiste en la generación y difusión de la alerta. 

Esta división busca asegurar, como se verá más adelante, la jerarquía en los siguientes criterios para asegurar una mayor optimización del código y, por lo tanto, una mayor rapidez en el análisis de los usuarios 

La siguiente tabla muestra la escala cromática asociada a cada nivel de alerta permitido, por lo tanto, una correcta interpretación de los colores y advertencias siempre que abordados a lo largo de este documento:

2.4.1 Fase 1 - Triaje 

En esta fase, los usuarios serán sometidos a cuatro pasos que les permitirán filtrar el estado del usuario en la aplicación. A continuación, explicamos detalladamente cómo se produce este proceso, sabiendo que inicialmente el código de alerta asignado es 000. 

Antes de iniciar el proceso de análisis de la interacción del usuario en la aplicación IPTV, el sistema analiza los permisos para la verificación. Por lo tanto, el primer paso es saber si hay autorización para realizar el análisis de usuario. En caso de no tener permiso, el sistema asigna un código 000|300 si la falta de permiso se debe a que el usuario se encuentra de vacaciones o fuera de casa; o un código 000|400 si este impedimento se debe únicamente a cuestiones de privacidad. Incluyendo esto el sistema dirige todos los recursos a los usuarios interesados en el análisis de su Estado, eliminando inmediatamente a aquellos que no tienen la intención, por una de las razones antes mencionadas, de tener el sistema activo. Esta funcionalidad, definida en el futuro por el cuidador en la aplicación móvil, también tiene la función de eliminar las advertencias durante los períodos en los que las rutinas se ven interrumpidas por la ausencia de la persona mayor en su hogar. Si todo está autorizado, el sistema inicia el análisis individual. 

El siguiente paso es comprobar si hay una alerta en la aplicación, es decir, si este usuario inicia el proceso de análisis con su situación habitual o si ya se ha emitido una alerta en la aplicación con anterioridad. Este criterio no implica ninguna interrupción del proceso, significa sólo un mapeo inicial. En caso de que el usuario ya tenga una alerta se le asigna el código 001, siempre que no permanezca con el 000. 

En el siguiente paso, el sistema verifica si hay una alerta de emergencia requerida por el botón amarillo de la aplicación que no haya sido leída por ninguno de sus cuidadores. Esta pregunta, al igual que la anterior, no termina el proceso abruptamente, sino que sirve una vez más para enmarcar mejor al usuario en relación con el análisis. Así, si la respuesta es afirmativa, se asigna al usuario un 002, mientras que si no, permanece con el código anterior.

En el siguiente paso el sistema verifica si hay una alerta de emergencia requerida por el botón amarillo de la aplicación no leída por ninguno de sus cuidadores. Esta pregunta, al igual que la anterior, no termina el proceso abruptamente, sino que sirve una vez más para enmarcar mejor al usuario en relación con el análisis. Así, si la respuesta es "sí", se atribuye al usuario el 002 mientras que si no, permanece con el código anterior. 

Después, los criterios de análisis son los medicamentos retrasados. El sistema verifica el historial de medicación en las últimas 48 horas en esta etapa. Este valor de 48 horas es fácilmente configurable y ha sido ajustado varias veces para asegurar un grado de efectividad en el proceso de generación de alertas. Teniendo en cuenta que, en el componente PI2-SecurHome, se consideró que el 48 horas sería un tiempo razonable. Por esta razón, si se ha retrasado con la medicación, su código de análisis cambia a 003 mientras que si no se conservará el código anterior. En términos prácticos, disponer de medicamentos retrasados significa la emisión automática de una alerta del tipo Azul (señalización). Después de recoger los datos genéricos del algoritmo de detección, el sistema entra en la fase de analizar el estado del usuario en la aplicación.  Según el usuario está conectado o desconectado el proceso sigue caminos diferentes según las diferencias que cada estado supone. 

2.4.2 Fase 2 - Usuarios conectados 

Si el usuario está conectado, el sistema llama a un método específico en el algoritmo, y el primer paso es comprobar si hay una notificación de presencia en la aplicación, es decir, si hay una pregunta "¿Aún estás ahí? En caso de que no haya ningún aviso, el sistema pasa al paso siguiente sin modificar los códigos que han transitado de los pasos anteriores. Caso sea lanzada se verifica, en base a los datos recogidos durante el uso de la aplicación IPTV, el tiempo medio de respuesta a esas notificaciones. El objetivo de esta verificación es comprender si es habitual que este usuario esté ausente de la tele durante períodos de tiempo largos, lo que dará lugar a la aparición de tales notificaciones y, en última instancia, a que responda más tarde. En caso de que el tiempo de respuesta sea superior a la media se atribuirá un código de segundo nivel 101. Si es inferior, el indicador asignado es 102. En ambos casos la evaluación se detiene en este punto y se emite una alerta al cuidador basándose en los códigos asignados. Sin notificaciones, el análisis continúa. 

Sabiendo que no hay ningún aviso contabilizado, el sistema sigue analizando datos para detectar si hay algún problema con el usuario. El sistema verifica en esta fase la fecha y la hora de la última interacción con la televisión. Para ello, utiliza el análisis de varias indicadores como el último cambio de canal, la notificación (presencia o medicamentos) a los que se ha respondido o la última entrada en la aplicación de TV a través del historial del registro de interacciones de iNeighbour TV. 

Tan pronto como tiene esa fecha, el sistema la resta por la fecha actual, empezando por el intervalo que se procede al análisis de este parámetro. El primer paso de esta verificación es confirmar que la última interacción se produjo hace menos de veinte minutos. El parámetro "veinte minutos" es configurable pero su adopción se debió a que es la mitad del tiempo necesario para que la aplicación SecurHome TV inicie la notificación de presencia con la pregunta: "¿Sigues viendo la tele?", que está cifrada en 40 minutos. 

En caso de que la última interacción fuera hace menos de veinte minutos, el sistema asume que todo está en su lugar, así como el usuario. Sin embargo, si el tiempo es mayor, se realiza una verificación de detección. Esta evaluación permite anticipar hasta un máximo de veinte minutos la publicación de la notificación y aumentar así la eficacia del sistema en caso de accidente. 

Así pues, el cribado consiste en cruzar el programa que se emite con los hábitos del usuario. El sistema comprueba si el programa que se está visualizando es habitual para el usuario. El concepto habitual en este caso es refinado cruzando los patrones de visión. 

En esta etapa cualquier programa cuya visualización sea superior al 5% del consumo total del usuario se considera un programa habitual. El valor del 5% permite, por ejemplo, excluir todos los programas nunca antes vistos, pero garantiza la inclusión de programas con una única transmisión semanal. Si el programa se considera normal, se devuelve un código de segundo nivel 103 y siempre que no hay retorno se realiza un código de segundo nivel 104. 

Una vez completados todos estos pasos de verificación, el sistema emite la alerta en base al código de primer y segundo nivel asociado y la envía, por los mecanismos adyacentes al nivel generado, al cuidador, completando así el proceso de verificación. 

Una vez que el usuario ha iniciado sesión, las posibilidades de verificación del algoritmo dependen en gran medida de la notificación de presencia y la consiguiente respuesta, por lo que el método de verificación para los usuarios que han iniciado sesión es considerablemente más sencillo y fácil de entender que el método para los usuarios que han cerrado la sesión que se presenta a continuación. 

2.4.3 Fase 2 - Usuarios desconectados 

Al igual que el proceso activado para los usuarios conectados, el modo dedicado para los usuarios desconectados es llamado por la fase 1 (triaje). Esto se activa mediante un método específico en el algoritmo. Al entrar en este modo, se añade automáticamente un código de segundo nivel con el valor 200. A continuación, se inicia el análisis en base a los criterios definidos para los usuarios desconectados. 

El primer paso de la comprobación es analizar si la causa de la desconexión de la aplicación es para participar en algún evento o consulta. Para ello el sistema aprovecha la existencia de estos datos sobre el ecosistema PI2-SecurHome cruzándolos. Para aumentar la eficacia de esta verificación, el sistema añade treinta minutos a las horas definidas como inicio y fin de las consultas. Si la hora actual es dentro de este período, el sistema supone que la ausencia del usuario se debe a la participación en una consulta debidamente programada sobre la aplicación IPTV. La verificación es inmediata y este hecho se refleja en la aplicación móvil para que el cuidador pueda conocer la razón por la qué está fuera de línea. Si el usuario no está participando en un evento el código de segundo nivel 201 y en caso de no estar en una consulta 202, en ambos casos el sistema continúa el análisis. 

Otro de los problemas comunes detectados durante el periodo de desarrollo fue la generación de alertas para usuarios que viven con alguien y cuya pareja está conectada. El hecho de que sólo haya un STB por casa puede desencadenar la emisión inicial de alertas para el usuario desconectado. 

Como tal, se verifica si hay otro usuario conectado en la casa. Si este usuario existe y está activado, el sistema asume que ésta es la causa del estado de desactivación y finaliza el proceso asignando un código de segundo nivel con el valor 210. En caso de que no haya nadie conectado se le asigna un valor de 203 y el sistema procede. 

Sabiendo que el usuario no tenía nada programado para esta fecha, y que ya no se encuentra nadie en casa usando el componente SecurHomeTV, el siguiente paso es entender cuando fue la última sesión del usuario. Esto se hace comprobando el historial de sesiones del usuario en cuestión. 

Tan pronto como se recoge esta fecha y hora, el sistema analiza si esta sesión fue hace menos de una hora. Si el usuario ha estado conectado durante menos de sesenta minutos, el sistema supone que no hay nada raro y concluye el proceso. 

Por otra parte, si la última sesión dura más de tres días, el sistema asigna un indicador de segundo nivel 209. La única razón para optar por los tres días es la prevención de los fines de semana, es decir, evitar un absentismo de dos días. Los tres días garantizan así la supuesta vuelta a la rutina semanal que, en este grupo de edad, puede significar, por ejemplo, el regreso a casa después de un fin de semana en el hogar de un hijo. En este caso, el sistema pasa al siguiente paso. 

Y es precisamente en el siguiente paso que el consumo de televisión asume el papel principal en la detección de desviaciones del usuario. En esta fase se comprueba si se están transmitiendo programas de la preferencia del usuario. Para determinar esta preferencia, se recogen los hábitos de consumo de televisión del usuario y se consideran preferibles los programas con más del 25% de visionado. Este valor del 25% es configurable. 

La existencia o no de programas favoritos a transmitir no representa en esta fase ningún reflejo del proceso, el sistema simplemente almacena esta información y la utiliza en los siguientes pasos después de verificar la probabilidad de que el usuario esté conectado en ese periodo de tiempo. De este modo, esta opción evita que la alerta se emita de forma precipitada sólo en función de las preferencias del usuario y sin analizar ningún otro dato que se considere fundamental para este criterio. 

Sin dejar el mismo nivel, el sistema busca complementar la información anterior asignando un valor a la probabilidad de que el usuario esté conectado en este periodo de tiempo. Así, se verifican los últimos 15 días de uso de la aplicación y de este análisis resulta la probabilidad de estar conectado. 

Si la probabilidad de estar conectado es superior al 50% y se emiten programas favoritos, se añade un valor de segundo nivel de 205 al código. Si no se están transmitiendo y el usuario no ha estado desconectado durante más de 3 días, un segundo nivel de 208. Si la probabilidad es superior al 25% (e inferior al 50%), se devuelve un código 206 y si a este valor se añade el hecho de que también hay programas favoritos para ser emitidos. Finalmente, si la probabilidad es superior al 10% y se están emitiendo programas favoritos, el código devuelto es el 207.  

Si no se cumple ninguna de estas condiciones, el sistema supone que no hay ningún programa favorito a ser emitido y la probabilidad es inferior al 10% es muy poco probable que el usuario esté conectado y asume este hecho como causa de la ausencia del usuario no emitiendo ninguna alerta y finalizando inmediatamente el proceso. 

Al cruzar todos estos valores en esta etapa, buscamos detectar todos los errores causados por cambios en las rutinas causados por programas en vivo o de fin de semana cuya programación es considerablemente diferente a la de otros días. Por ejemplo, un usuario que ve una telenovela todos los días a las 21.00 horas puede no hacerlo sólo porque el programa que se emite ese día sea un partido de fútbol. Lo mismo puede ocurrir si un sénior ve un programa todos los días por la mañana pero no lo hace a la misma hora de un sábado o un domingo porque están emitiendo programas para niños. 

Una vez que se han cumplido todos los criterios, el sistema devuelve el código de advertencia generado a la función principal. Al hacerlo, el sistema entra en la última fase del proceso de alerta. Para ello, el código, compuesto por el primer y segundo nivel, se ejecuta y se transforma en una alerta, tal y como se explica en el siguiente tema. 

2.4.4 Fase 3 - Emisión de alertas 

Este momento representa la fase final del proceso de análisis de un usuario. Es, por lo tanto, aquí donde se realiza toda la gestión de las alertas de la aplicación y su consiguiente envío. 

En esta fase del proceso, se crea un objeto de esta clase y se pasa como parámetros el ID de usuario y el código devuelto de la fase anterior. Este código se recoge y se rompe para poder interpretar los diferentes niveles y causas de las advertencias. Este análisis da como resultado la siguiente acción. 

En esta etapa es fundamental que el sistema decida qué puede hacer con la alerta, en base a los códigos devueltos el sistema puede decidir insertar una nueva alerta, reducir o aumentar una ya liberada o simplemente ignorarla en caso de que el cuidador haya asumido que todo estaba bien hace menos de 12 horas. El valor de 12 horas es editable y tiene por objeto evitar que se generen consecutivamente varias alertas por la aplicación por las razones que llevaron a un cuidador a decir que no había una razón para la misma. Sin embargo, si la alerta es del nivel más alto (rojo), este criterio es ignorado y la alerta se inserta. 

El tema de las alertas es, como toda la aplicación, un proceso altamente jerárquico que ahora tratamos de explicar. Tan pronto como se obtiene un número entero, el sistema intenta insertar esa alerta en el BD. Sin embargo, este sólo se produce si este valor es superior a 1 (sin descripción) y si la descripción es inferior a la ya emitida. 

Sin embargo, el sistema tiene la capacidad de eliminar alertas cuando no se cumplen algunas condiciones. Si alguien se conecta dentro de la casa y se emite una alerta para el otro miembro el elimina la alerta emitida anteriormente.

Repetición de alertas 

Otro problema recurrente en este sistema es el resultado de advertencias sucesivas (cuando la advertencia es tan grave como la anterior) para los cuidadores si no se resuelve la advertencia. Para que esto ocurra de forma equilibrada, es necesario dotar al sistema de condiciones que le permitan hacerlo con precisión y de acuerdo con la gravedad de la alerta. 

Por lo tanto, si la alerta es de nivel 2, sólo se insertará una nueva alerta después de 1 día. Si la alerta en cuestión es de nivel 3, esta repetición tendrá lugar durante un período de 12 horas o más. Para el nivel 4 este período es de 3 horas, mientras que para una alerta de gravedad extrema (5) la repetición se realiza cada hora. 

Con estos periodos tratamos de conseguir una redundancia en función de la gravedad y así asegurarnos de que los cuidadores asumen la responsabilidad de retirar la alerta y asumir ante el sistema que todo está bien. Todos estos valores son fácilmente configurables en la aplicación. 

Envío de e-mails 

El mensaje que se envía al cuidador se titula "Alerta @grado detectado en la aplicación SecurHomeTV". El mismo mensaje tiene como cuerpo la explicación de la advertencia informando al cuidador de la causa que causó el error y su gravedad. Finalmente, este mensaje consiste en un hipervínculo a través del cual el usuario puede eliminar la alerta asumiendo que no hay ningún problema con la persona a su cargo.

Sin embargo, el cuerpo del mensaje sigue dependiendo del destinatario, ya que estos pueden ser enviados al cuidador, al propio y a la administración del sistema. 

Envío de SMS 

Al enviar mensajes escritos, el sistema utiliza una API externa. El mensaje que recibe el usuario indica que se ha disparado una alerta con un cierto grado de gravedad. Debido a la limitación de caracteres, el usuario no es informado de la causa por la que la alerta ha sido desencadenada. 

Finalización del proceso 

Tan pronto como las alertas son activadas por los canales correspondientes, el proceso de verificación de usuario finaliza. Aquí, el sistema avanza al siguiente usuario, en caso de que esté ejecutando todos ellos, o simplemente completa el proceso. 

Botón de emergencia 

Además de la recogida de datos mencionada anteriormente, la aplicación de TV dispone de un mecanismo que permite al ciudadano mayor enviar una solicitud de emergencia. Este botón de pánico está disponible para el usuario a través del botón amarillo del mando a distancia. 

En caso de que una persona mayor pulse este botón, el sistema envía inmediatamente un mensaje escrito y un correo electrónico al cuidador, así como cambia automáticamente el nivel de alerta de la persona mayor a rojo, el nivel más grave de la jerarquía (véase Escalas). 

3.2 Usuario: senior 

Se identifican, a continuación, los datos que podrían compartirse entre el componente PI2- SecurHome y el componente PI1-SecurHome utilizando los respectivos métodos de la API Web. 

3.2.1 Datos existentes 

Datos de televisión 

- Status de la solicitud (offline, online...) 
- Consumo de televisión en tiempo real 
- Últimos programas de televisión vistos en una franja horaria 
- Hora de la última interacción con la televisión 

Datos médicos 

- Lista de medicamentos y dosis 
- Lista de futuras citas médicas 
- Lista de exámenes programados 
- Historial de medicamentos con la hora de tomarlos y su estado (tomar / no tomar) 

Datos personales 

- Perfil de usuario (nombre, sexo, fecha de nacimiento, ciudad, foto del perfil, intereses y habilidades) 
- Notificaciones actuales 
- Mensajes recibidos 

3.2.2 Métodos 

Estado del usuario 

- Lista del estado del usuario en la aplicación (offline/online) + última interacción con el televisor + consumo de televisión en tiempo real 

LastTVShows 

- Enumera los últimos programas vistos en un intervalo de tiempo. 

LastMedication 

- Lista histórica de medicamentos con hora de toma y estado (tomar/no tomar) 

RecibirMensajes 

- Lista de mensajes recibidos por el usuario 
Usuario - Lista de datos de usuario por ID 

Citas médicas 

- Lista de Consultas 

Exámenes Médicos 

- Lista de exámenes 

3.3 Usuario: cuidador 

3.3.1 Datos existentes 

Datos personales 

- Datos del perfil 
- Lista de dependientes 
- Mensajes enviados 

Datos de acceso 

- Lista de inicio de sesión para aplicaciones web/móviles 
- Hora del último acceso a las aplicaciones web/móviles 

3.3.2 Métodos 

Cuidadores 

- Lista de datos del cuidador por ID 

Inicios de sesión 

- Muestra el historial de los inicios de sesión de las aplicaciones Web y móviles. 

Dependientes 

- Enumera los dependientes del cuidador 

Mensajes Enviados  

- Lista de alertas recibidas por el cuidador 

4. Resumen final 

Los desarrollos reportados en este documento han sido evaluados técnicamente, con los siguientes resultados se verificó el correcto funcionamiento del ecosistema PI2-SecurHome, tanto a nivel de sus 3 aplicaciones cliente, tanto a nivel de la API desarrollada. 

Por lo tanto, se cumplen las condiciones para ello: 

- en el marco del proyecto individual 1, se puede acceder a los datos existentes para comparar el rendimiento del sistema de alerta interno (del ecosistema PI2-SecurHome) con el sistema desarrollado por los socios. 

- En el marco del proyecto individual 3, la evaluación de campo respectiva se lleva a cabo con los end-users (personas mayores y sus cuidadores).