PI2-SecurHome Deliverable - Relatório 2 Seguimento do Projeto Individual 2

O presente documento tem como objetivo principal expor e descrever todos os procedimentos realizados pela equipa de investigação do projeto individual 2, do programa coordenado SecurHome, no âmbito do desenvolvimento do ecossistema PI2-SecurHome (“Aplicación móvil encargada de la interacción domestica por medio de la televisión”). É dada especial atenção à descrição da estruturação deste ecossistema, destacando-se as componentes de processamento server-side e gestão de base de dados. 

O ecossistema PI2-SecurHome, suportado pelo sistema iNeighbour TV, materializa-se no seguinte conjunto de aplicações cliente, complementado com uma API destinada a aceder aos respetivos dados por parte do sistema associado ao projeto individual 1. 

Disponibilizada aos utilizadores séniores para registo das interações televisivas e visualização de lembretes (medicamentos e consultas) 

Disponibilizada aos utilizadores cuidadores para gestão dos seus dependentes e da emissão de lembretes médicos

Disponibilizada aos utilizadores cuidadores para monitorização dos seus dependentes e receção de alertas

Do ponto de vista tecnológico, recorreu-se a um esquema de desenvolvimento baseado em código, server-side, compatível com todas as aplicações e que permitiu criar um ambiente de desenvolvimento integrado, capaz de responder eficazmente a estas necessidades. 

Para a implementação da aplicação TV recorreu-se a STBs comerciais do sistema de IPTV comercial MEO. O facto destas STBs estarem equipadas com middleware Mediaroom implicou que o desenvolvimento de código server-side tenha sido feito em C# enquanto a aplicação Admin (backoffice de todo o sistema) foi desenvolvida com recurso à framework .NET. A aplicação TV foi desenvolvida com a framework Presentation Framework. 

O projeto foi complementado com uma base de dados SQL na qual estão armazenados os dados relativos a todas as aplicações do projeto. 

2.1.2 Áreas especificas da aplicação 

Login 

Ao iniciar a aplicação é pedido ao utilizador que escolha um dos users disponíveis em sua casa e insira o PIN para esse utilizador. Caso o PIN esteja correto, o utilizador faz login na aplicação e passa para o Menu. Caso contrário, o utilizador recebe feedback de que o PIN estará errado e volta à escolha de users. Até esta fase, a aplicação é controlada através dos ficheiros Default.aspx e Acesso.aspx. O ficheiro Default.aspx exibe o splash screen e redireciona a aplicação para a página Acesso.aspx onde o utilizador pode fazer login. 

Menu 

Após efetuar o login aparece o menu SecurHomeTV na parte superior do televisor, enquanto a emissão televisiva continua disponível. Ao selecionar cada uma das opções do menu (exceção feita à opção "Desligar") surgem os vários submenus da área escolhida e deslizará um painel do menu até ao limite inferior do televisor, com a informação do primeiro submenu carregada por defeito. 

SubMenu e Detalhe 

O conteúdo de cada submenu varia consoante o mesmo, apesar de em várias áreas a estrutura e funcionamento ser semelhante. O detalhe de cada opção escolhida pode surgir através de uma animação de slide do painel que revela a informação, mantendo um botão no topo do painel que permite regressar à área anterior ou, então, através de um popup com uma transparência reduzida - para permitir focar a atenção no mesmo e não no conteúdo televisivo. 

Popups de escolha de opções 

O popup de escolha de opções é controlado através da página EventsTopLayer.aspx. Esta página foi criada de maneira a funcionar independentemente do resto da aplicação. No redireccionamento para esta página, que é feito através de uma SubmitAction, devem ser indicados dois parâmetros: o id do botão que despoleta a ação de invocação do popup e uma keyword que é utilizada na página EventsTopLayer.aspx.cs para identificar quais as opções a exibir no popup. Na mesma página é criado um xml virtual que irá guardar as opções a mostrar no popup, bem como as ações a executar caso seja escolhida uma opção. O xml servirá como ponte entre a informação a disponibilizar e o controlo TvPhysicsGrid que exibe a informação no televisor. Consoante a keyword que é recolhida no topo da página, o xml é construído com dois campos principais, texto a exibir no televisor e url para o qual será executada uma NavigateAction. Se apenas for necessário escolher uma opção, então o popup exibe a mensagem de "Opção guardada" e fecha-se automaticamente. Caso contrário, o popup através de um parâmetro de exit determina que não deve ser fechado e com a nova keyword escolhida sabe quais as opções a exibir. O processo repete-se então até que todas as opções necessárias sejam escolhidas. Para suavizar o aparecimento do popup são utilizadas duas animações próprias da framework: FadeAnimation e ZoomAnimation. Em qualquer altura o utilizador pode fechar o popup sem seleccionar uma opção através do botão do telecomando Back, como é referido na mensagem que está sob o popup. Existem ainda uma série de validações consoante cada opção. No caso da escolha de datas, por exemplo, é sempre considerada a data atual para que o utilizador não possa escolher uma data passada. Os dias, meses, anos, horas e minutos são apresentados, não por ordem crescente, mas num painel circular com focus inicial na opção atual (dia de hoje, mês atual...). No caso da escolha de utilizadores para enviar convites, à medida que vão sendo escolhidos utilizadores, estes desaparecem do popup, para que o utilizador não envie o mesmo convite mais que uma vez para a mesma pessoa. 

O tratamento dos dados escolhidos é feito através de código JavaScript que é incluído na página Mainpage.aspx através do controlo TvScript. A comunicação entre as opções escolhidas no popup e a página Mainpage.aspx é feita através de SendEventAction. Na SendEventAction são comunicados os dados recolhidos em Json através das opções selecionadas no popup. Estes são recolhidos pelo Javascript através da sua função Eval e convertidos em objetos que serão guardados ou exibidos no televisor conforme necessário.

2.2 Aplicação Admin

A aplicação Admin encontra-se, à semelhança do restante projeto, alojada na máquina virtual da AlticeLabs. Ao nível do desenvolvimento da página web foi utilizada uma estrutura base que permite criar um layout global para a aplicação. Assim, e recorrendo às valências da Framework .NET, foram encadeadas duas master pages que servem de corpo a todas as páginas do website. A página “Master.master” tem por missão criar a estrutura global da aplicação enquanto a página “Menu.master” tem por missão criar o menu que permita a interação com os utilizadores do site assim como os widgets que se encontram sempre presentes ao longo da aplicação.

Posteriormente à criação destas duas masterpages a aplicação corre numa lógica de páginas soltas onde se encontra colocado o html e o código servidor (C#) necessário para o funcionamento disponibilizado em cada uma das respetivas áreas. No entanto o código que se repete em diversas áreas foi centralizado no ficheiro "inWebPage.cs" cuja classe é estendida em todas as classes das páginas especificas do site. Paralelamente a este código a aplicação recorre ainda, à semelhança da aplicação TV, às camadas de interação iNeigDAL e iNeigBLL através das quais comunica com a BD e disponibiliza todos os dados relativos ao utilizador.

2.3 Aplicação Mobile 

A aplicação móvel, intitulada SecurHome Mobile, tem como público-alvo os cuidadores dos séniores. Nesta aplicação o cuidador pode aceder aos dados de consumo televisivo do sénior e dessa forma fazer uma monitorização em tempo real da atividade do sénior de forma a prevenir eventuais acidentes em contexto doméstico. 

Rotina de servidor 

Além da vertente de monitorização manual por parte do cuidador foi ainda desenvolvido uma Console Application que permite verificar, um determinado intervalo de tempo, a atividade do sénior cruzando-a com os seus hábitos diários de consumo. Com base nos desvios ao padrão e recorrendo a informação especifica da aplicação ITPV (agenda de eventos e medicação) o sistema emite alertas para os cuidadores com diferentes graus de gravidade.

Estes alertas, que variam numa escala cromática de verde (sem alerta) até vermelho (o mais grave) são recebidos via email ou SMS pelo cuidador que a partir dos mesmos poderá ignorar, informado o sistema que não há qualquer problema com o sénior em causa, ou tomar outro tipo de precauções no sentido de resolver o problema detetado pelo sistema. 

2.4 Sistema de alertas 

O modo de funcionamento do algoritmo de geração de alertas é sequencial e cumulativo. Todos os utilizadores são analisados um a um pelo sistema através de um conjunto de critérios sequenciais que podem, simplesmente, interromper o processo ou fazer o mesmo seguir rumos diferentes consoante os dados analisados anteriormente. 

O processo de analise de um utilizador passa por 3 fases. A primeira, uma análise geral igual para todos os utilizadores; a segunda consoante o estado do utilizador na aplicação (online/offline); e a terceira que consiste na geração e disseminação do alerta. Com esta divisão procura-se garantir, como se perceberá mais à frente, a hierarquia nos critérios de forma a garantir maior otimização do código e, por conseguinte, maior velocidade na análise dos utilizadores. 

A tabela seguinte apresenta a escala cromática associada a cada nível de alerta, permitido, assim, uma correta interpretação de cores e avisos sempre que abordados ao longo deste documento.

2.4.1 Fase 1 – Triagem 

Nesta fase os utilizadores irão ser sujeitos a quatro passos que permitem fazer a triagem do estado do utilizador na aplicação. Em seguida explica-se com detalhe como decorre este processo sabendo desde já que inicialmente o código de alerta atribuído é o 000. 

Antes de iniciar o processo de análise, da interação do utilizador na aplicação IPTV, o sistema analisa as permissões para fazer a verificação. Assim, o primeiro passo consiste em saber se há autorização para efetuar a análise do utilizador. No caso de não haver permissão o sistema atribui um código 000|300 se a falta de permissão se dever ao utilizador estar em férias/ausente; ou um código 000|400 se tal impedimento se dever apenas a questões de privacidade. Ao englobar esta funcionalidade o sistema orienta todos os recursos para os utilizadores interessados na análise do seu estado, eliminando desde logo aqueles que não pretendem, por uma das razões anteriores, ter o sistema ativo. Esta funcionalidade, definida futuramente pelo cuidador na aplicação móvel, tem ainda como função eliminar avisos durante períodos em que as rotinas são interrompidas por questões de ausência do sénior do seu lar. Se tudo estiver autorizado o sistema arranca a análise individual. 

O passo seguinte consiste em verificar se existe algum alerta lançado na aplicação, isto é, verifica se este utilizador parte para o processo de análise com a sua situação regular ou se já anteriormente tinha sido emitido algum alerta na aplicação para si. Este critério não acarreta nenhuma interrupção do processo significando apenas um mapeamento inicial. No caso de o utilizador ter já algum alerta lançado é-lhe atribuído um código 001, enquanto se não tiver se mantém com o 000. 

No passo seguinte o sistema verifica se existe algum alerta de emergência requerido através do botão amarelo da aplicação não lido por nenhum dos seus cuidadores. Esta questão, tal como a anterior, não termina o processo abruptamente servindo mais uma vez apenas para enquadrar melhor o utilizador em relação à análise. Assim, em caso de resposta ser afirmativa é-lhe atribuído um 002 enquanto em caso negativo permanece com o código que vem de trás. Seguidamente, o critério de análise são os medicamentos em atraso. O sistema verifica nesta fase o histórico de medicação nas últimas 48 horas. Este valor das 48 horas é facilmente configurável e foi ajustado diversas vezes de forma a garantir um grau de eficácia no processo de geração de alertas. Tendo em conta que, no componente PI2-SecurHome, entendeu-se que as 48 horas seriam um período razoável. Por este motivo, se o utilizador tiver medicação em atraso o seu código de análise passa para um 003 enquanto se não tiver se mantem o código anterior. Em termos de resultado prático, ter medicação em atraso significa a emissão automática de um alerta do tipo Azul (sinalização). Depois de recolhidos os dados genéricos do algoritmo de deteção o sistema entra na fase de analisar o estado do utilizador na aplicação. Mediante o utilizador estiver ligado ou desligado o processo segue caminhos diferentes em função das diferenças que cada estado acarreta. 

2.4.2 Fase 2 – Utilizadores ligados 

Se o utilizador se encontrar ligado o sistema chama um método específico no algoritmo, sendo que primeiro passo consiste em verificar se está lançada na aplicação alguma notificação de presença, isto é, se existe na aplicação alguma pergunta “Ainda está aí?” por responder. No caso de não existir nenhuma notificação o sistema segue para o passo seguinte sem alterar os códigos que transitavam dos passos anteriores. Caso esteja lançada é verificada, com base nos dados recolhidos ao longo da utilização da aplicação IPTV, a média de tempo demorado a responder a estas notificações. Esta verificação tem como intuito perceber se é habitual este utilizador ausentar-se da televisão durante períodos longos o que originará o surgimento destas notificações acabando por responder mais tarde. No caso do tempo de resposta ser superior à média é atribuído um código de segundo nível 101. No caso de ser inferior o código atribuído é o 102. Em ambos os casos a análise é interrompida neste ponto e é emitido um alerta para o cuidador com base nos códigos atribuídos. Sem notificações a análise prossegue. 

Sabendo que não há nenhuma notificação lançada o sistema continua a analisar dados de interação com vista a detetar se algo de errado se passa com o utilizador. O sistema verifica nesta fase a data e hora da última interação com a televisão. Para tal recorre à análise de diversos indicadores como a última mudança de canal, notificação (presença ou medicamentos) respondidasou a última entrada na aplicação TV através do histórico do registo de interações do iNeighbour TV. Assim que dispõe dessa data o sistema subtrai-a pela data atual para, partindo do intervalo de tempo, proceder à análise deste parâmetro. 

O primeiro passo desta verificação passa por confirmar que a última interação ocorreu há menos de vinte minutos. O parâmetro “vinte minutos” é configurável mas a sua adoção deveu-se ao facto de ser metade do tempo necessário para a aplicação SecurHome TV lançar a notificação de presença com a pergunta “Ainda está a ver televisão?” que se cifra em 40 minutos. No caso da última interação ter sido há menos de vinte minutos o sistema assume que tudo está bem com o utilizador. No entanto, se o tempo for superior, é feita uma verificação de despistagem. Esta despistagem permite antecipar até um máximo de vinte minutos o lançamento da notificação de interação e assim aumentar a eficácia do sistema em caso de acidente. 

A despistagem consiste assim em cruzar o programa que está a ser emitido com os hábitos do utilizador. O sistema verifica se o programa que está a ser visto é ou não habitual para o utilizador. O conceito de habitual, neste caso, é apurado através do cruzamento dos padrões de visualização. Nesta fase considera-se programa habitual qualquer programa cuja visualização seja superior a 5% do consumo total do utilizador. O valor de 5% permite, por exemplo, excluir todos os programas nunca vistos, mas garante a inclusão de programas com uma única transmissão semanal. Se o programa for considerado habitual é retornado um código de segundo nível 103 enquanto se não for o retorno é feito com um código de segundo nível 104. 

Ultrapassados todos estes passos de verificação o sistema emite o alerta com base no código de primeiro e segundo nível associado e o mesmo é enviado, pelos mecanismos adjacentes ao nível gerado, para o cuidador terminando assim o processo de verificação. 

Uma vez que o utilizador está ligado as possibilidades de verificação do algoritmo ficam muito dependentes da notificação de presença e da consequente resposta, assim, o método de verificação para utilizadores ligados é consideravelmente mais simples e de mais fácil compreensão do que o método para utilizadores desligados que se apresenta em seguida. 

2.4.3 Fase 2 – Utilizadores desligados 

Semelhante ao processo desencadeado para os utilizadores ligados, o modo dedicado aos utilizadores desligados é chamado pela fase 1 (triagem). Para tal é desencadeado um método específico no algoritmo. Ao entrar neste modo é automaticamente adicionado um código de segundo nível com o valor 200. Em seguida é iniciada a análise com base nos critérios definidos para utilizadores desligados. 

O primeiro passo da verificação passa por analisar se a causa para estar desligado da aplicação é estar a participar nalgum evento ou consulta. Para isso o sistema aproveita a existência destes dados no ecossistema PI2-SecurHome cruzando-os. Para aumentar a eficácia desta verificação o sistema adiciona trinta minutos às horas definidas como início e fim das consultas. Se a hora atual se encontrar dentro deste período o sistema assume que a ausência do utilizador se deve à participação numa consulta devidamente agendada na aplicação IPTV. A verificação é imediatamente interrompida e este facto é refletido na aplicação móvel para que o cuidador possa saber a razão do seu dependente estar desligado. Se o utilizador não estiver a participar num evento é atribuído o código de segundo nível 201 e no caso de não estar numa consulta o 202, em ambos os casos o sistema prossegue a análise. 

Outro dos problemas comuns, detetados durante o período de desenvolvimento, foi a geração de alertas para utilizadores que vivem acompanhados e cujo parceiro se encontrava ligado. O facto de só existir uma STB por casa potencialmente originará inicialmente a emissão de alertas para o utilizador desligado. 

Como tal, verifica-se a existência de outro utilizador ligado na casa. Se esse utilizador existir e estiver ligado o sistema assume que essa é a causa do estado desligado e termina o processo atribuindo um código de segundo nível com o valor 210. No caso de não estar ninguém ligado na mesma casa é atribuído um valor 203 e o sistema prossegue. 

Sabendo que o utilizador não tinha nada agendado para esta data, e que não se encontra mais ninguém em casa a utilizar a componente SecurHomeTV, o passo seguinte é compreender quando foi a última sessão do utilizador. Para tal verifica-se o histórico de sessões do utilizador em causa. 

Assim que é recolhida essa data e hora o sistema analisa se esta sessão foi há menos de uma hora. Se o utilizador esteve ligado num período inferior a sessenta minutos o sistema assume que nada de errado se passa e dá por concluído o processo. 

Por outro lado, se a última sessão for superior a três dias o sistema atribui um código de segundo nível 209. A opção pelos três dias tem como única razão a prevenção do fim-de- semana, isto é, previne-se assim uma ausência de dois dias. Os três dias garantem desta forma o suposto retorno à rotina semanal que, nesta faixa etária, pode significar, por exemplo, o regresso a casa após um fim- de-semana em casa de um filho. Neste caso o sistema prossegue para o passo seguinte. E é justamente no passo seguinte que o consumo televisivo assume o principal papel na deteção de desvios do utilizador. Nesta fase é verificado se naquele momento estão a ser transmitidos programas da preferência do utilizador. Para apurar esta preferência são recolhido os hábitos de consumo televisivo do utilizador e são considerados preferidos programas com mais de 25% de visualização. Este valor de 25% é configurável. A existência ou não de programas favoritos a serem transmitidos não representa nesta fase qualquer reflexo para o processo, o sistema limita-se a guardar esta informação e a usá-la nos passos seguintes depois de verificada a probabilidade do utilizador estar ligado naquele período temporal. Esta opção evita assim que o alerta seja emitido de uma forma precipitada apenas em função da preferência do utilizador e sem analisar mais dados considerados fundamentais para este critério. 

Sem sair do mesmo patamar, o sistema procura complementar a informação anterior atribuindo um valor para a probabilidade do utilizador estar ligado neste período temporal. Assim são verificados os últimos 15 dias de utilização da aplicação e dessa análise resulta a probabilidade deste se encontrar ligado. Se a probabilidade de estar ligado for superior a 50% e estiverem a ser emitidos programas favoritos é adicionado ao código um valor 205 de segundo nível. No caso de não estarem a ser transmitidos e do utilizador não estar desligado há mais de 3 dias é retornado um segundo nível de 208. Já se a probabilidade for superior a 25% (e inferior a 50%) é retornado um código 206 se a este facto se juntar a existência de programas favoritos a serem emitidos. Por fim, se a probabilidade for superior a 10% e estiverem a ser emitidos programas favoritos o código retornado é o 207. 

Se nenhuma destas condições se verificar o sistema assume que não havendo programas favoritos a ser emitidos e a probabilidade for inferior a 10% é altamente improvável o utilizador estar ligado e assume esse facto como a razão da ausência do utilizador não emitindo qualquer alerta e finalizando de imediato o processo. 

Ao cruzar todos estes valores nesta fase, procura-se despistar todos os erros provocados por alterações às rotinas provocadas por programas em direto ou fins-de-semana cuja programação é consideravelmente diferentes dos outros dias. Por exemplo, um utilizador que todos os dias vê uma telenovela às 21h pode não o fazer apenas porque o programa que está a ser emitido naquele dia é um jogo de futebol em direto. O mesmo pode acontecer se um sénor vir todos os dias um programa matutino durante a semana, mas não o faz se àquela hora de um Sábado ou Domingo estiver a dar programação infantil. 

Ultrapassados todos os critérios, o sistema retorna para a função principal o código de alerta gerado. Ao fazê-lo o sistema entra na última fase do processo de emissão de alertas. Para isso o código, composto pelo primeiro e segundo nível, é executado e transformado num alerta, tal como se explica no tópico seguinte.

2.4.4 Fase 3 – Emissão do alerta 

Este momento representa a derradeira fase do processo de análise de um utilizador. É, portanto, aqui que ocorre toda a gestão dos alertas por parte da aplicação e o seu consequente envio. Nesta fase do processo é então criado um objeto desta classe e passados como parâmetros o ID do utilizador e o código retornado da fase anterior. Este código é recolhido e partido para que possam ser interpretados os diferentes níveis e causas dos avisos. Desta análise resulta a ação seguinte. 

Nesta fase é fundamental para o sistema decidir o que pode fazer com o alerta, com base nos códigos retornados o sistema pode decidir inserir um novo alerta, reduzir ou aumentar um alerta já lançado ou simplesmente ignorar no caso de um cuidador ter assumido que tudo estava bem há menos de 12 horas. O valor de 12 horas é editável e procura evitar que vários alertas sejam consecutivamente gerados pela aplicação pelos motivos que levaram um cuidador a dizer que não havia motivo para o alerta. No entanto, se o alerta for do nível mais elevado (vermelho) este critério é ignorado e o alerta é inserido na mesma. 

A emissão dos alertas é, tal como toda a aplicação, um processo altamente hierarquizado que se procura, agora, explicar. Assim que se obtém um número inteiro o sistema tentar inserir esse alerta na BD. No entanto, tal só acontece se este valor for superior a 1 (sem alerta) e se o alerta for inferior ao alerta já lançado. Contudo, o sistema dispõe de capacidade para remover alertas sempre que algumas condições se verificarem. Se alguém se ligar dentro de casa e estiver lançado um alerta para o outro membro o sistema remove o alerta anteriormente lançado. 

Repetição de alertas 

Outro dos problemas recorrentes deste sistema resulta dos avisos sucessivos (sempre que este tem a mesma gravidade do anterior) para os cuidadores caso o aviso não seja resolvido. Para que tal aconteça de forma equilibrada é necessário dotar o sistema de condições que permitam que essa repetição seja feita com critério e em função da gravidade do alerta. 

Assim, se o alerta é de nível 2 só será inserido um novo alerta passado 1 dia. No caso do alerta em causa ser de nível 3 esta repetição é feita num período igual ou superior a 12 horas. Para nível 4 este período cifra-se nas 3 horas enquanto num alerta de gravidade extrema (5) a repetição é feita de hora em hora. 

Com estes períodos procura-se conseguir uma redundância em função da gravidade e, assim, garantir que os cuidadores assumem a responsabilidade de serem eles a remover o alerta assumindo perante o sistema que tudo está bem. Todos estes valores são facilmente configuráveis na aplicação.

Envio de correio eletrónico 

A mensagem que é enviada para o cuidador tem como título “Alerta @grau detetado na aplicação SecurHomeTV”. A mesma mensagem tem como corpo a explicação do aviso informando o cuidador da causa que originou o erro e a respetiva gravidade. Por fim, esta mensagem é composta por uma hiperligação através da qual o utilizador pode remover o alerta assumindo assim que nada de errado se passa com o seu dependente. No entanto, o corpo da mensagem fica ainda assim dependente do destinatário uma vez que esta pode ser enviada para o cuidador, para o próprio e para a administração do sistema. 

Envio de SMS 

No caso do envio das mensagens escritas o sistema recorre a uma API externa. A mensagem que é recebida pelo utilizador refere que foi despoletado um alerta com um determinado grau de gravidade. Devido à limitação de caracteres o utilizador não é informado da causa pela qual o aviso foi despoletado. 

Finalização do processo 

Assim que os alertas são despoletados, pelas vias correspondentes, o processo de verificação do utilizador está terminado. Aqui o sistema avança para o utilizador seguinte, no caso de estar a correr todos, ou simplesmente termina o seu processo. 

Botão de emergência 

Além da recolha de dados acima referida a aplicação TV dispõe de um mecanismo que permite ao sénior enviar um pedido de emergência. Este botão de pânico está disponível para o utilizador através do botão amarelo do comando.

No caso de um sénior premir este botão o sistema envia, de imediato, uma mensagem escrita e um email para o cuidador assim como altera automaticamente o nível de alerta do sénior para vermelho, o nível mais grave da hierarquia (ver Escalas). 

3.2 Utilizador: sénior 

Identificam-se, a seguir, os dados que poderão ser partilhados, entre a componente PI2-SecurHome e a componente PI1-SecurHome, através dos respetivos métodos da Web API. 

3.2.1 Dados existentes 

Dados televisivos 

• Estado na aplicação (offline, online...) 

• Consumo televisivo em tempo real 

• Últimos programas de TV vistos num intervalo de tempo 

• Hora da última interação com a televisão 

Dados médicos 

• Lista de medicamentos e posologia 

• Lista de consultas médicas futuras 

• Lista de exames marcados 

• Histórico de medicação com hora da toma e estado (tomada / não tomada) 

Dados pessoais 

• Perfil do utilizador (nome, sexo, data de nascimento, localidade, foto de perfil, interesses e aptidões) 

• Avisos atuais 

• Mensagens recebidas 

3.2.2 Métodos 

UserStatus 

• Lista do estado do utilizador na aplicação (offline/online) + última interação com a TV + consumo televisivo em tempo real 

LastTVShows 

• Lista últimos programas vistos num intervalo de tempo. 

LastMedication 

• Lista histórico de medicação com hora da toma e estado (tomada / não tomada) 

ReceiveMessages 

• Lista de mensagens recebidas pelo utilizador 

User

• Lista dados do utilizador por ID 

MedicalAppointments 

• Lista de Consultas 

MedicalExams 

• Lista de Exames 

3.3 Utilizador: cuidador 

3.3.1 Dados existentes 

Dados pessoais 

• Dados de perfil 

• Lista de dependentes 

• Mensagens enviadas 

Dados de acesso 

• Lista de login nas aplicações web/mobile 

• Hora do último login nas aplicações web/mobile 

3.3.2 Métodos 

Caregivers 

• Lista dados do cuidador por ID 

Logins 

• Lista o histórico de Logins nas aplicações Web e Mobile 

Dependentes 

• Lista os dependentes do cuidador 

SentMessages 

• Lista de alertas recebidas pelo cuidador 

4 Síntese final 

Os desenvolvimentos reportados neste documento foram tecnicamente avaliados, tendo-se verificado o correto funcionamento do ecossistema PI2-SecurHome, quer ao nível das suas 3 aplicações cliente, quer ao nível da API desenvolvida. 

Estão, assim, reunidas as condições para que: 

• no âmbito do projeto individual 1 se possam aceder aos dados existentes, de forma a comparar a performance do sistema de alertas interno (do ecossistema PI2-SecurHome) com a do sistema desenvolvido pelos parceiros. 

• no âmbito do projeto individual 3 se realize a respetiva avaliação de campo com end-users (seniores e respetivos cuidadores) reais.