ParaApre

ciaçã

o por Jú

ri

FACULDADE DE ENGENHARIA DA UNIVERSIDADE DO PORTO

Monitorização de bio-sinais utilizandodispositivos móveis

Daniel Ferreira

Mestrado Integrado em Engenharia Informática e Computação

Orientador: Gil Manuel Magalhães de Andrade Gonçalves (Professor)

Coorientador: Raquel Sousa (Engenheira)

17 de Junho de 2012

Monitorização de bio-sinais utilizando dispositivos móveis

Daniel Ferreira

Mestrado Integrado em Engenharia Informática e Computação

17 de Junho de 2012

Resumo

A maior longevidade das populações acarreta um aumento da prevalência de doenças crónicas,como as doenças cardiovasculares (que são a maior causa de morte nos países industrializados)e as demências. Devido à elevada morbi-mortalidade provocada por estas doenças crónicas, énecessária uma monitorização contínua dos sinais vitais de pessoas em situações de risco. Atu-almente, esta monitorização é realizada recorrendo ao monitor de Holter, que recolhe dados deeletrocardiograma durante um longo período para serem posteriormente avaliados. No entanto,esta não é uma monitorização em tempo real. Existe outro tipo de monitorização em que os biosinais obtidos, além de serem guardados localmente, são também comunicados para um servidorremoto, permitindo uma monitorização contínua, em tempo real. Esta monitorização necessitade uma plataforma específica, tendo os pacientes que conviver com mais um dispositivo no seuquotidiano.

As Tecnologias da Informação e Comunicação têm tomado um papel de destaque na gestãoe prestação de cuidados de saúde e assistência social. Uma das suas aplicações é no acompanha-mento dos pacientes no seu dia a dia, de modo a, em caso de urgência, permitir uma interven-ção mais atempada pelos serviços médicos. No campo das TIC, temos assistido à ascensão dossmartphones, dispositivos com grande mobilidade, conetividade e capacidade de processamento.São dispositivos ideais para levar o acompanhamento dos pacientes ao próximo nível, substituindoa necessidade de plataformas específicas para cada tipo de monitorização, facilitando assim o diaa dia dos pacientes. Esta capacidade dos smartphones começa a ser cada vez mais evidente com oaparecimento, diariamente, de novas aplicações médicas que tiram proveito das suas característi-cas.

Assim, aproveitando a elevada mobilidade e poder de processamento disponibilizados pelossmartphones, o objetivo desta Dissertação é desenvolver uma aplicação para smartphone que re-alize a avaliação da condição cardíaca de um paciente, através de bio-sinais adquiridos por umdispositivo com interface bluetooth e sensores do próprio smartphone, e posterior integração comum sistema de telemetria médica.

Palavras-chave Aplicações Médicas, Monitorização Móvel, Dispositivos Móveis, Bio Sinais

i

ii

Abstract

The aging of the population causes an increased prevalence of chronic diseases, such as car-diovascular disease (which is the leading cause of death in developed countries) and dementia.Because of the high morbidity and mortality rates associated with this group of diseases, it is ne-cessary to continuously monitor the vital signs of people at risk. Nowadays this monitoring iscarried out by a Holter monitor, which acquires electrocardiogram data for a long period of time,so that they can be analyzed later. However, this is not a real-time monitoring. There is anothertype of monitor, which stores the data and communicates with a remote server, allowing a conti-nuous monitoring and in real-time. The latter system requires a specific platform and, as result,the patients have to adapt to yet another device in their daily activities.

Information and communication technologies (ICT) have had a remarkable role in the ma-nagement of health care distribution and social work, and can be applied on daily monitoring ofpatients, providing a timely opportunity for medical staff to intervene. In the ICT field we havewitnessed the rise of smartphones as a gadget with great mobility, connectivity and processing ca-pacities. They are the ideal device to take the monitoring of patients to the next level, replacing theneed for specific platforms for each type of monitoring, and facilitating the daily lives of patients.this ability of smartphones becomes more and more apparent with the daily increasing number innew medical applications that profit from its characteristics.

Therefore, the goal of this Dissertation is to create an application for smartphones which takesadvantage of the portability and processing capacities of smartphones to assess cardiac function,using bio signals captured by a device with bluetooth interface and the sensors on the smartphone,and subsequent processing with a medical telemetry system.

Keywords Medical Applications, Mobile Monitoring, Mobile Devices, Bio Signals

iii

iv

Agradecimentos

Ao Professor Gil Gonçalves e à Engenheira Raquel Sousa, pela orientação dada durante arealização desta Dissertação.

Daniel Ferreira

v

vi

Conteúdo

1 Introdução 11.1 Contexto/Enquadramento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2 Motivação e Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.3 Estrutura do Documento . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

2 Revisão Bibliográfica 72.1 Plataformas de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . . . . . 7

2.1.1 Android . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72.1.2 iOS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.1.3 Windows Phone 7 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

2.2 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.1 Zephyr BioHarness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2.2 Zephyr HXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.3 Under Armor e39 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.2.4 Plataforma de Aquisição de Bio Sinais . . . . . . . . . . . . . . . . . . . 9

2.3 Aplicações para Smartphones . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92.4 Sistemas de Deteção de Quedas . . . . . . . . . . . . . . . . . . . . . . . . . . 102.5 Sistemas de Monitorização em Residência . . . . . . . . . . . . . . . . . . . . . 11

2.5.1 AlarmNet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.2 Aid-N . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122.5.3 In-Home Assessment of the Activities of Daily Living of the Elderly . . . 132.5.4 The Smart Medical Home . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.5 PlaceLab . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.6 CodeBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.5.7 Assisted Cognition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2.6 Sistemas de Monitorização Móvel . . . . . . . . . . . . . . . . . . . . . . . . . 132.6.1 Monitor de Holter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6.2 Heartronic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142.6.3 eCAALYX (Enhanced Complete Ambient Assisted Living Experiment) . 142.6.4 MobiSense . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.6.5 iCare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

2.7 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

3 Definição do Problema 173.1 Descrição . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

3.1.1 Requisitos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183.2 Solução . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19

3.2.1 Plataforma de Desenvolvimento . . . . . . . . . . . . . . . . . . . . . . 19

vii

CONTEÚDO

3.2.2 Funcionalidades . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203.3 Aplicações Existentes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22

3.3.1 Aplicação Móvel - Keepcare Mobile . . . . . . . . . . . . . . . . . . . . 223.3.2 Aplicação Web . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

3.4 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

4 Conceção 254.1 Serviço . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284.3 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5 Implementação 315.1 Sensores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31

5.1.1 Zephyr BioHarness . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.1.2 Zephyr HXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.1.3 ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34

5.2 Ligação ao Servidor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.3 Base de Dados Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.4 Geofencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 375.5 Atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.6 Quedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 405.7 Avaliação de Dados e Alertas . . . . . . . . . . . . . . . . . . . . . . . . . . . . 415.8 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42

6 Testes e Resultados 436.1 Dados de Monitorização . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 446.2 Deteção de Quedas . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.3 Avaliação de Atividade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.4 Resumo e Conclusões . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48

7 Conclusões e Trabalho Futuro 497.1 Satisfação dos Objetivos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 497.2 Trabalho Futuro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50

Referências 51

viii

Lista de Figuras

1.1 Visão geral de um sistema de monitorização em tempo real . . . . . . . . . . . . 31.2 Aplicações Médicas no Android Market . . . . . . . . . . . . . . . . . . . . . . 41.3 WiMM One . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2.1 Dispositivo Zephyr BioHarness . . . . . . . . . . . . . . . . . . . . . . . . . . . 82.2 Aplicação Instant Heart Rate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102.3 Aplicação para iPhone de Lembretes com base na localização . . . . . . . . . . . 102.4 Bengala do sistema SmartFall . . . . . . . . . . . . . . . . . . . . . . . . . . . 112.5 Arquitetura do Sistema AlarmNet . . . . . . . . . . . . . . . . . . . . . . . . . 122.6 Arquitetura do Sistema Heartronic . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.1 Prioridade de Processos em Android . . . . . . . . . . . . . . . . . . . . . . . . 203.2 Arquitetura do sistema onde será integrado o Serviço . . . . . . . . . . . . . . . 22

4.1 Visão geral do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.2 Organização do Sistema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254.3 Sequência de Comunicação entre Aplicação e Serviço para ligação do Bioharness 284.4 Estrutura da Base de Dados . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29

5.1 Lista de sensores emparelhados . . . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Zephy Bioharness pronto a receber ligação . . . . . . . . . . . . . . . . . . . . . 335.3 Zephyr HXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 345.4 Simulação da comunicação com Docklight . . . . . . . . . . . . . . . . . . . . . 355.5 Comunicação com Sensor ABS . . . . . . . . . . . . . . . . . . . . . . . . . . . 355.6 Deteção de ondas R . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.7 Janela para definição da vedação virtual . . . . . . . . . . . . . . . . . . . . . . 375.8 Força exercida no smartphone a caminhar . . . . . . . . . . . . . . . . . . . . . 385.9 Força exercida no smartphone a descer escadas . . . . . . . . . . . . . . . . . . 395.10 Força durante queda . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40

6.1 Dados de monitorização obtidos a partir do Zephyr HXM . . . . . . . . . . . . . 446.2 Aplicação Web com dados recebidos . . . . . . . . . . . . . . . . . . . . . . . . 446.3 Notificação de alerta . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 456.4 Força durante a descida de degraus . . . . . . . . . . . . . . . . . . . . . . . . . 466.5 Força durante uma caminhada . . . . . . . . . . . . . . . . . . . . . . . . . . . 476.6 Força durante uma corrida . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

ix

LISTA DE FIGURAS

x

Lista de Tabelas

1.1 Índice de dependência de idosos . . . . . . . . . . . . . . . . . . . . . . . . . . 1

5.1 Dados adquiridos pelo BioHarness . . . . . . . . . . . . . . . . . . . . . . . . . 325.2 Dados adquiridos pelo HXM . . . . . . . . . . . . . . . . . . . . . . . . . . . . 335.3 Dados adquiridos pelo sensor ABS . . . . . . . . . . . . . . . . . . . . . . . . . 34

6.1 Dados adquiridos em várias quedas . . . . . . . . . . . . . . . . . . . . . . . . . 46

xi

LISTA DE TABELAS

xii

Abreviaturas e Símbolos

AAL Ambient Assisted LivingCDMA Code division multiple accessECG EletrocardiogramaGPS Global Positioning SystemGSM Global System for Mobile CommunicationsNUTS Nomenclatura Comum das Unidades Territoriais EstatísticasPMP Plataforma de Monitorização PessoalSDK Source Development KitTIC Tecnologias da Informação e ComunicaçãoUMTS Universal Mobile Telecommunication System

xiii

Capítulo 1

Introdução2

A evolução da medicina e a melhoria significativa da qualidade e nível de vida nas sociedades4

ocidentais têm proporcionado um aumento da esperança média de vida que, juntando ao menor

número de nascimentos, faz com que tenhamos uma população envelhecida, com cada vez me-6

nor ratio de pessoas jovens ativas por pessoas idosas [1]. Grande número destas pessoas idosas

não consegue viver em independência [2] (ver tabela 1.1) devido a demências, que podem causar8

problemas como perda de orientação ou falta de mobilidade, situações que, frequentemente, de-

terminam o recurso a lares de idosos. No entanto, existem diversas situações em que os idosos10

continuam a fazer a sua vida isolados.

Região ÍndiceNorte 24.4%Centro 31.9%Lisboa 27.4%Alentejo 36.4%Algarve 29.7%Açores 18.1%Madeira 18.6%

Tabela 1.1: Índice de dependência de idosos

Em alguns casos, estas doenças cardiovasculares e demências, bem como os medicamentos12

utilizados no seu tratamento, podem afetar o equilíbrio, criando situações propícias a quedas, que

constituem a principal causa de morte por acidente nesta faixa etária. As mortes por queda em14

idosos representam 70% das mortes por quedas em toda a população [3]. É também necessário

considerar as implicações que uma queda pode ter nas capacidades de um idoso, que podem não16

levar à morte, mas afetam a capacidade motora, devido à fragilidade que este grupo etário revela.

Além deste problema temos também uma grande incidência de doenças cardiovasculares tanto18

em idosos como em pessoas jovens ativas, devido a hábitos alimentares e tipos de vida cada vez

1

Introdução

mais sedentários, que dependem de uma monitorização contínua, pois são doenças com uma ele-

vada taxa de morbimortalidade. Mais de 30% dos óbitos em Portugal são causados por doenças 2

cardiovasculares [4]. É possível prevenir alguns dos episódios cardíacos agudos, como o enfarte

do miocárdio, decorrentes de doenças cardiovasculares diagnosticadas, recorrendo a monitoriza- 4

ção contínua de pessoas em situação de risco, através da leitura em tempo real de ECG e de ritmo

cardíaco, o que pode ser feito recorrendo a internamento hospitalar. No entanto, os custos e a 6

redução da qualidade de vida do paciente tornam esta alternativa inadequada. Existem, também,

os serviços em ambulatório, que tratam de muitos destes casos, porém são muito dispendiosos e 8

frequentemente insuficientes, devido ao facto de não proporcionarem uma monitorização contínua.

É, portanto, urgente a criação de uma solução que alivie os serviços em ambulatório, previna 10

acidentes ou permita uma resposta atempada a pacientes diagnosticados como casos de risco,

reduza os custos, e, mais importante, melhore a qualidade de vida desses pacientes. 12

1.1 Contexto/Enquadramento

Esta Dissertação enquadra-se nas áreas de Aplicações Médicas e Aplicações para Dispositivos 14

Móveis. Foi realizada em ambiente empresarial na empresa Increase Time. A Increase Time é

uma empresa de base tecnológica que desenvolve e comercializa soluções inovadoras para um 16

envelhecimento independente, ativo e com qualidade, de idosos e portadores de doenças crónicas

e/ou degenerativas. A empresa posiciona-se como um fornecedor de soluções TIC inovadoras para 18

apoio à saúde e assistência social destinadas ao mercado doméstico ou de residências assistidas.

1.2 Motivação e Objetivos 20

No presente, recorrendo ao monitor de Holter [5], é possível realizar um tipo de Monitorização

Móvel com o objetivo de diagnóstico. O monitor de Holter consiste em elétrodos, aplicados no 22

corpo de um paciente, ligados por cabos a um dispositivo que regista a atividade cardíaca do

mesmo durante um longo período, ao contrário dos ECG convencionais, que apenas registam 24

os sinais num curto espaço de tempo. Normalmente, é utilizado durante 24 horas, ou mais, de

modo a haver um período largo de amostragem que permite observar a existência de episódios 26

esporádicos, como arritmias cardíacas. Este monitor tem o inconveniente de ser pouco prático

para um uso diário contínuo e de não realizar uma monitorização em tempo real, muitas vezes 28

essencial para a vida do paciente. Assim, é possível colmatar esta falha recorrendo a outro tipo

de monitorização. Esta monitorização é realizada recorrendo a uma arquitetura composta por 3 30

componentes. No lado do paciente é utilizada uma rede de sensores. Esta rede de sensores pode

conter sensores de medição de: 32

• Eletrocardiograma;

• Batimento cardíaco; 34

• Temperatura;

2

Introdução

• Movimento;

Estes sensores podem ser todos colocados num só dispositivo, que, ao ser colocado numa fita,2

pode ser usado por um paciente como se fosse uma peça de roupa. O segundo componente é

um servidor remoto que recebe os sinais dos sensores e que os processa. Este processamento é4

realizado através de algoritmos de avaliação de ECG e fusão de dados dos diversos sensores de

modo a lançar alertas e notificações em casos de alerta, sem a necessidade de uma supervisão6

contínua de um profissional de saúde. Para haver uma comunicação entre os sensores e o servidor

remoto é utilizado um terceiro componente, uma Plataforma de Monitorização Pessoal, que faz a8

ponte entre os sensores e o servidor. Esta plataforma é transportada pelos pacientes juntamente

com os sensores.10

SensoresPlataforma de Monitorização

PessoalServidor Remoto

Figura 1.1: Visão geral de um sistema de monitorização em tempo real

Normalmente, a comunicação entre os sensores e a PMP é feita através de uma rede sem

fios, recorrendo a bluetooth ou Wi-Fi, no entanto também poderá ser feita através de fios. Esta12

necessidade de uma plataforma específica para este tipo de utilização, a PMP, torna os custos

desta monitorização elevados, além da necessidade dos pacientes transportarem mais um dispo-14

sitivo consigo, tal como acontece com o monitor de Holter. É possível ultrapassar este problema

recorrendo a um dispositivo cada vez mais comum, os smartphones.16

Os smartphones são, sem dúvida, uma história de sucesso. No último ano, nos Estados Uni-

dos da América, os smartphones já se encontram perto da marca dos 50% do total dos utilizadores18

móveis [6], um número com tendência a aumentar, até os chamados featurephones serem uma

minoria. No presente, mundialmente, as vendas de smartphones já ultrapassam a venda de com-20

putadores pessoais [7]. Portugal, onde existe mais do que um telemóvel por habitante, é também

exemplo desta tendência, principalmente na população mais jovem, mas também em alguma po-22

pulação sénior, visto que os smartphones trazem algumas facilidades de utilização que não eram

anteriormente proporcionadas. É, portanto, um mercado muito apelativo, tanto pela facilidade de24

desenvolvimento de aplicações, e sua distribuição, como pela possibilidade de retorno devido ao

grande número de potenciais clientes, o que possibilita diversas oportunidades para diversas áreas.26

Na área da Saúde, onde se foca esta Dissertação, nota-se um aumento da quantidade de aplicações

desenvolvidas para estes dispositivos.28

Este mercado é também um mercado em rápida evolução. Nos últimos meses temos visto uma

introdução de um novo tipo de dispositivos mais pequenos, como o dispositivo WiMM One [8]30

3

Introdução

Figura 1.2: Aplicações Médicas no Android Market

da figura 1.3, para serem utilizados como relógios de pulso, com as mesmas funcionalidades dos

smartphones. Devido à ainda maior portabilidade destes dispositivos será possível, no futuro, ter 2

soluções cada vez mais cómodas para os pacientes.

Figura 1.3: WiMM One

4

Introdução

Estes dispositivos têm também funcionalidades que serão importantes para este tipo de utiliza-

ção. Atualmente, grande parte dos smartphones estão equipados com acelerómetros que avaliam2

a força a que o dispositivo está sujeito em cada momento, em cada eixo. Utilizando esta informa-

ção, é possível, através do processamento destes dados, avaliar o nível de atividade física que o4

utilizador está a realizar e ainda detetar a ocorrência de quedas, podendo atuar o mais rapidamente

possível de modo a minimizar o efeito de uma queda. Estes dispositivos estão também equipados6

de GPS, o que permite saber, em caso de emergência, a localização dos utilizadores, bem como

criar uma vedação virtual e ser notificado quando essa vedação é transposta.8

Por isso, a principal questão de investigação nesta Dissertação é explorar o potencial de utilizar

um dispositivo genérico em substituição de uma plataforma de monitorização específica, através10

do desenvolvimento de uma aplicação para smartphones, aproveitando também diversas vantagens

como a integração dos próprios sensores e a capacidade de processamento dos smartphones.12

1.3 Estrutura do Documento

Para além da introdução, este documento contém mais seis capítulos. No capítulo 2, é descrito14

o estado de arte e são referenciados trabalhos relacionados. No capítulo 3 é detalhado o problema e

será apresentada a solução proposta. Os capítulos 4 e 5 são referentes à conceção e implementação,16

respetivamente, da solução. No capítulo 6 são apresentados os testes realizados e os resultados

obtidos e por fim, no capítulo 7 é feita a conclusão da Dissertação.18

5

Introdução

6

Capítulo 2

Revisão Bibliográfica2

Para a realização desta Dissertação é necessária uma pesquisa acerca de projetos existentes,4

dentro da mesma temática. Esta pesquisa foi feita recorrendo a artigos, publicados em revistas

científicas inseridas em bases de dados bibliográficas e bibliotecas digitais. Assim, é possível6

obter informação acerca do tipo de sistemas de monitorização existentes, como funcionam, a sua

estrutura, e perceber onde se irá inserir este trabalho. É necessário também conhecer as potenciais8

plataformas a utilizar de modo a escolher as mais vantajosas para o projeto.

2.1 Plataformas de Desenvolvimento10

Para desenvolvimento da aplicação, que irá tratar os sinais recebidos dos sensores, será uti-

lizada uma plataforma móvel. Todas têm as suas características diferenciadoras e é com base12

nestas características que será selecionada a plataforma mais vantajosa onde será implementada a

solução.14

2.1.1 Android

O sistema Android [9], num nível mais baixo, é composto por um kernel Linux, e em alto nível,16

por uma máquina virtual Java, Dalvik Virtual Machine. Isto faz com que seja um sistema versátil,

compatível com grande variabilidade de hardware, podendo ser utilizado em plataformas com18

especificações distintas, permitindo assim aos fabricantes criar dispositivos cada vez mais baratos,

com as características necessárias para correr o sistema. O desenvolvimento de aplicações para os20

dispositivos é feito recorrendo a Java. O sistema permite que as aplicações desenvolvidas tenham

uma grande liberdade de acesso a funcionalidades do sistema. Os dispositivos integram sensores22

de GPS, acelerómetro, giroscópio e bússola e suportam comunicação por bluetooth, GSM, 3G

(UMTS), CDMA e Wi-Fi. De grande relevância também é o facto de, atualmente, ser o sistema24

com maior quota de mercado.

7

Revisão Bibliográfica

2.1.2 iOS

O sistema iOS [10] é o sistema operativo utilizado pelos dispositivos Apple iPhone. É um 2

sistema UNIX, baseado em Mac OS X, e apenas existe nos dispositivos da Apple, que em média

têm um custo mais elevado. O desenvolvimento de aplicações é feito na linguagem Objetive-C Ao 4

contrário do sistema Android, as aplicações são corridas em código nativo, e não numa máquina

virtual, contudo existem limitações de acesso a funcionalidades de sistema que tornam impeditivo 6

o uso de alguns tipos de aplicações. De maior relevância será a impossibilidade das aplicações

permanecerem em execução quando enviadas para background. Os dispositivos dispõem de senso- 8

res de GPS, giroscópio, acelerómetro e bússola, e comunicação por bluetooth, GSM, 3G(UMTS),

CDMA e Wi-Fi. 10

2.1.3 Windows Phone 7

É a nova versão do sistema operativo móvel da Microsoft [11], sucessora da plataforma Win- 12

dows Mobile. Os dispositivos necessitam de cumprir certas especificações de hardware para po-

derem ser licenciados e correr o sistema operativo. O desenvolvimento é feito na linguagem C#, 14

recorrendo às plataformas Silverlight e XNA. Tal como as outras plataformas, os smartphones

Windows Phone 7 possuem sensores de GPS, giroscópio, acelerómetro e bússola, e comunicação 16

por bluetooth, GSM, 3G, CDMA e Wi-Fi.

2.2 Sensores 18

Devido à existência de vários tipos de sensores, para vários tipos de monitorização, a pesquisa

apresentada nesta secção é orientada aos sensores utilizados pela empresa Increase Time. 20

2.2.1 Zephyr BioHarness

O Zephyr BioHarness consiste num dispositivo colocado numa fita, usável pelos utilizadores, 22

que obtém informações fisiológicas compreensivas e as transmite através de bluetooth. Possibilita

a leitura de dados como ECG, batimento cardíaco, frequência respiratória e movimento. 24

Figura 2.1: Dispositivo Zephyr BioHarness

8

Revisão Bibliográfica

É disponibilizado pela Zephyr uma versão para programadores que inclui um conjunto de

ferramentas para o desenvolvimento de aplicações compatíveis com o dispositivo.2

2.2.2 Zephyr HXM

O Zephyr HXM é uma versão simplificada, e pequena, do BioHarness. Apenas obtém sinais4

de ritmo cardíaco, velocidade e distância percorrida. Também é disponibilizado pela Zephyr um

SDK para facilitar o desenvolvimento para o dispositivo.6

2.2.3 Under Armor e39

Dispositivo também desenvolvido pela Zephyr, em parceria com a Under Armor, com foco8

nos desportistas. Comporta as mesmas funcionalidades do BioHarness, como leitura de ECG,

batimento cardíaco, frequência respiratória e movimento. É aplicado a uma camisola justa.10

2.2.4 Plataforma de Aquisição de Bio Sinais

Plataforma[12] desenvolvida por João Pedro Sousa Oliveira, no âmbito da sua Dissertação12

do Mestrado Integrado em Engenharia Eletrotécnica e de Computadores. Obtém dados de ECG,

ritmo cardíaco e oxigénio no sangue, e trasmite-os por bluetooth.14

2.3 Aplicações para Smartphones

Existem várias aplicações que permitem uma monitorização pontual do utilizador. Estas apli-16

cações recorrem a acessórios que, ligados ao smartphone, permitem obter dados como batimento

cardíaco, quantidade de oxigénio no sangue ou nível de glicose. Temos também algumas apli-18

cações, como a Instant Heart Rate[13], na figura 2.2, que apenas utilizam as capacidades do

smartphone, como o acelerómetro e a câmera, de modo a obter o ritmo cardíaco.20

Também existem aplicações que implementam funcionalidades de geofencing, como o exem-

plo da figura 2.3. Geofencing consiste numa vedação virtual aplicada a um local. Atualmente22

existem várias aplicações para esta funcionalidade. Nos sistemas de smartphones permite que o

dispositivo reaja adequadamente à localização em que se encontra, ligando e desligando serviços24

ou despoletando alarmes de lembretes conforme definido pelo utilizador. No caso de sistemas de

monitorização permite que o cuidador saiba onde se encontra o utilizador e receber alarmes no26

caso deste ter transposto os limites, o que pode ser essencial no caso de pacientes com demências.

9

Revisão Bibliográfica

Figura 2.2: Aplicação Instant Heart Rate

Figura 2.3: Aplicação para iPhone de Lembretes com base na localização

2.4 Sistemas de Deteção de Quedas

Existem vários projetos para desenvolvimento de sistemas de deteção de quedas. Alguns sis- 2

temas estão a ser comercializados atualmente, como o Brickhouse Alert[14] que consiste numa

base que comunica com um sensor que é colocado no tronco de um utilizador. Este sensor co- 4

munica com a base em caso de queda e a base enviará um sinal de alerta a uma unidade médica.

Este sistema só funciona se a queda acontecer em casa, no raio de alcance da base. Existe tam- 6

bém o telemóvel ITT EasyLife[15] que deteta quedas e telefona automaticamente para o número

de emergência. Devido ao interesse em encontrar uma solução satisfatória para este problema 8

10

Revisão Bibliográfica

também existem diversos projetos académicos como o projeto PerFallD [16] que consiste numa

aplicação para smartphone que utiliza o acelerómetro de modo a calcular a força que é exercida2

no smartphone a qualquer momento e assim fazer a deteção de quedas. Existe também o projeto

SmartFall[17] que utiliza uma bengala modificada, de modo a incluir acelerómetros, para efetuar4

a deteção. Também há projetos [18, 19] que consistem em acelerómetros colocados em vários

pontos corpo do paciente para uma deteção mais robusta.6

Figure 2: The SmartCane System

3.1 SensorsThe sensors onboard the SmartCane system includes a tri-

axial accelerometer [27], three signal-axis gyroscopes [28],and two pressure sensors [30]. The gyroscopes, which areplaced perpendicular to each other to measure angular ratein 3D, and the accelerometer are mounted near the handleof the cane with a 30±-slant from the direction of the gravity.The two pressure sensors are fixed at the handle and the tipof the cane, measuring the grip and the downward-pushingforce respectively.

3.2 Acquisition UnitThe acquisition unit comprises a MicroLEAP [5] proces-

sor and a Bluetooth [29] interface board. Each sensor inputchannel can be sampled at a rate of up to 300Hz. For ourapplication, a sampling rate of 26Hz is chosen. The unitis very power-e±cient and supports over 20 hours of con-tinuous sampling and Bluetooth data streaming using six2200mAh AA-size batteries.

3.3 Personal DeviceThe personal device can be any mobile device that sup-

port Bluetooth. Although we choose a tablet PC for easeof programming and data visualization, the algorithm canbe easily ported to cellphone or PDA. The incoming datais received and logged to a file by a data logging daemon.The SmartFall software then reads directly from the file andperforms the detection algorithm in a near real-time fashion.

4. DETECTION ALGORITHM

4.1 A Model for FallThe mechanism of a fall needs to be first understood in

order to develop an eÆective fall detection algorithm. Atypical fall for a cane user consists of a three stages process:1) collapse, 2) impact, and 3) inactivity. During the collapsestage, the user loses balance and falls towards the ground inan accelerated motion. It is assumed that the cane shouldexperience a similar free-fall process even if the user loses

g

n

nInitial position

Final position!

!

ground

h

(a)

X-acceleration

Norm (n)Y-acceleration

(b)

Figure 3: The (a) side view and (b) top view of thetypical falling motion of a cane

control over the cane. We model this free-fall motion asdepicted in Figure 3(a). In this side view, the cane startsfrom a near upright orientation, topples under the force ofgravity, and, just before hitting the ground, changes to ahorizontal orientation. The acceleration perpendicular tothe cane, denoted by the vector n in the figure, is the normof the X- and Y-acceleration of the cane (see the top viewin Figure 3(b)). Thus, n can be calculated as

n = g · cos(µ) (1)

where g is the gravitational acceleration, and µ is the anglebetween the cane and the ground (0± ∑ µ ∑ 90±). Given theinitial height of the accelerometers h, µ can be expressed asa function of time t

µ = arcsin(1 ° g

2ht2) (2)

Since the accelerometers onboard the SmartCane is tilted by30±, the actual norm, n0 observed is therefore

n0 = g · cos(arcsin(1 ° g

2ht2)) · cos(30±) (3)

which can be simplified to

n0 = g · cos(30±) ·r

1 ° (1 ° g

2ht2)2 (4)

The impact stage begins when the cane first makes con-tact with the ground and finishes when the cane becomesmotionless. The impact exerts a counter force on the canethat results in a quick deceleration in the opposite direc-tion of the gravity. Depending on the reaction force, thecane may bounce a few times until the energy is completeddissipated. An exact mathematical model for this stage isextremely di±cult to derive as the motion depends on manyfactors, such as the stiÆness of the ground, material of thecane, shape of the impacting surface, just to name a few.Consequently, we model the impact stage in an empiricalway by collecting and averaging several experiment data.

Assuming the impact has caused a serious injury, boththe user and the cane should lie still on the ground for aprolonged period. If the ground surface is flat,

n0 = g · cos(30±) (5)

for the inactivity stage. This is obviously the easiest stage tomodel, and the duration of the stage is the only concern. Wechoose a period of 1 second, which is comparable to that of

Figura 2.4: Bengala do sistema SmartFall

2.5 Sistemas de Monitorização em Residência

Nesta secção são apresentadas soluções existentes de sistemas de monitorização de pacien-8

tes em residência. Estes sistemas são normalmente pensados para utilização em lares de idosos

e hospitais, onde existem vários pacientes a ser monitorizados. São sistemas constituídos por 410

componentes. O primeiro componente é uma rede de sensores colocada nos pacientes. Estes

sensores recolhem dados como a pulsação, ECG, temperatura e o movimento, através de acele-12

rómetro. Para complementar os dados obtidos por esta rede de sensores fisiológicos são também

utilizados sensores de ambiente, colocados no condomínio, que medem a humidade, temperatura,14

luz, poeira e movimento. Os dados obtidos a partir destes dois componentes são enviados, através

de uma plataforma que recolhe os dados dos sensores, e guardados numa base de dados, remota ou16

11

Revisão Bibliográfica

local, e serão supervisionados por profissionais de saúde. Existem diversas implementações deste

tipo de monitorização, cada um com a sua estrutura e diferente foco. 2

2.5.1 AlarmNet

O sistema AlarmNet [20] consiste numa rede de sensores, de ambiente e fisiológicos, com uma 4

arquitetura escalável e heterogénea. Permite recolha de dados em tempo real que são analisados e

apresentados ao profissional. Faz o estudo do ritmo circadiano e métodos de alimentação de um 6

paciente possibilitando uma gestão de energia dos sensores, sabendo qual ativar a cada momento,

e garantindo a privacidade de cada residente. Os sensores utilizados consistem em sensores infra- 8

vermelhos modificados e sensores de poeiras, sensores de temperatura, luz, pulso e oxigénio no

sangue. 10

Figura 2.5: Arquitetura do Sistema AlarmNet

2.5.2 Aid-N

Este sistema [21] não é para ser implementado numa casa, no entanto a sua arquitetura é si- 12

milar a este tipo. É um sistema com o objetivo de realizar triagem e monitorização de vítimas de

acidentes, ou catástrofes, de modo a não haver a necessidade de um médico fazer uma triagem 14

exaustiva a cada paciente, podendo assim focar os seus esforços nos feridos mais graves. A arqui-

tetura do sistema consiste em sensores de tensão arterial e ECG, que são colocados nos pacientes 16

e ligados a um dispositivo que transmite a informação recebida para um computador local que

estará a ser supervisionado por um profissional de saúde. 18

12

Revisão Bibliográfica

2.5.3 In-Home Assessment of the Activities of Daily Living of the Elderly

Investigadores da Intel Research Seattle e Universidade de Washington criaram um protótipo2

[22] que permite inferir as atividades diárias de cada pessoa. Recorrendo a sensores são etiqueta-

dos objetos usados no dia a dia, como um escova de dentes ou uma chávena de café. O sistema4

apercebe-se do movimento dos objetos etiquetados utilizando leitores de etiquetas. O objetivo é

criar um sistema não obstrutivo que ajude na gestão das atividades diárias dos idosos.6

2.5.4 The Smart Medical Home

Construído pela Universidade de Rochester [23], Nova Iorque, consiste numa "casa"equipada8

de sensores infravermelhos, computadores, bio-sensores e câmeras de vídeo, utilizados pela equipa

de pesquisa para testar conceitos e protótipos com os pacientes. O objetivo é criar um sistema de10

saúde pessoal que permita obter dados 24 horas por dia e apresentá-los aos profissionais de saúde.

2.5.5 PlaceLab12

MIT e TIAX, LLC trabalharam nesta iniciativa [24], que faz parte do projeto House n. A mis-

são do projeto é construir ambientes reais em laboratório, "laboratórios vivos", que são utilizados14

para estudar estratégias conceptuais e tecnológicas. O PlaceLab é um condomínio, apenas com

um quarto, com centenas de sensores instalados em toda a sua área.16

2.5.6 CodeBlue

Desenvolvido na Universidade de Harvard [25], criado para ser utilizado em pré-internamento,18

internamento, resposta a desastres e reabilitação de pacientes cardíacos é um sistema constituído

pelos habituais sensores e software escalável que permite aos profissionais de saúde seguir os20

pacientes.

2.5.7 Assisted Cognition22

Projeto[26] desenvolvido na Universidade de Washington com vista a melhorar a qualidade

de vida de pacientes com Alzheimer e outras demências. Utiliza técnicas de computação úbiqua24

e inteligência artificial de modo a seguir um paciente, reconhecendo padrões nas suas ações e

ajudando-o a completar tarefas do dia a dia.26

2.6 Sistemas de Monitorização Móvel

Nesta secção são apresentadas soluções existentes de sistemas de monitorização móvel de28

pacientes, também conhecidos como sistemas AAL. São sistemas que permitem uma maior mo-

bilidade ao paciente, não interferindo na sua qualidade de vida. Normalmente são constituídos30

por sensores de pulsação, ECG, temperatura e acelerómetro, colocados nos pacientes, e numa

plataforma de monitorização pessoal que recebe os sinais dos sensores e comunica-os, através da32

13

Revisão Bibliográfica

rede ou Wi-Fi, para um servidor remoto onde se encontram os profissionais de saúde a efetuar a

avaliação dos valores recebidos. É neste tipo de sistemas que esta Dissertação se irá inserir. 2

2.6.1 Monitor de Holter

Este monitor [5] consiste num equipamento, ligado a vários elétrodos, que recolhem sinais 4

como ECG e batimento cardíaco. Estes sinais são armazenados no dispositivo e é feita a sua

avaliação posteriormente pelo profissional de saúde. Normalmente o monitor de Holter é utilizado 6

por um paciente durante um período de 24 horas, ao fim do qual o monitor será entregue ao

profissional de saúde para avaliação. Não é, portanto, um sistema de monitorização em tempo 8

real.

2.6.2 Heartronic 10

O Heartronic [27] é um projeto conjunto de vários países europeus, incluindo Portugal, que

tem como propósito detetar e avaliar a condição cardíaca de um paciente, recorrendo a sensores, 12

em tempo real. Para o conseguir o sistema usa uma arquitetura composta pelos sensores, colocados

no paciente, um smartphone, para receber e transmitir os sinais dos sensores, e um servidor que 14

recebe os sinais do smartphone e os trata, lançando alertas, se necessário. Para isto, a monitoriza-

ção e análise automatizada de ECG é essencial, no entanto os dados são também supervisionados 16

por profissionais de saúde, de modo a evitar falsos-positivos, ou falsos-negativos.

Figura 2.6: Arquitetura do Sistema Heartronic

2.6.3 eCAALYX (Enhanced Complete Ambient Assisted Living Experiment) 18

Projeto [28] financiado pela União Europeia, composto por vários parceiros europeus, in-

cluindo o INESC, com o objetivo de monitorizar remotamente pacientes idosos com doenças cró- 20

nicas. Consiste numa plataforma móvel, desenvolvida para o sistema Android, que atua como uma

ponte informada entre os sensores, colocados nos pacientes, e o sistema dos profissionais de saúde. 22

14

Revisão Bibliográfica

Para o projeto houve como preocupação a usabilidade do sistema tendo em vista o público alvo

da aplicação. É um projeto que ainda se encontra em fase de desenvolvimento, com resultados2

previstos para meados de 2012.

2.6.4 MobiSense4

O MobiSense [29] é um sistema de monitorização remota, focado na monitorização da ativi-

dade dos pacientes. Consiste num PDA que recebe informações dos sensores e transmite-as para6

um servidor remoto. Recorre a heurísticas de modo a saber a posição em que se encontra um

paciente, i.e. se está deitado, em pé ou a correr, para as quais também utiliza informação de ECG8

e ritmo cardíaco. É um sistema focado nos limitados recursos que os dispositivos móveis, princi-

palmente na pouca capacidade das baterias. Para isso, o sistema controla a atividade dos sensores10

colocados nos pacientes de modo a estes só estarem ativos quando necessário.

2.6.5 iCare12

Tal como o projeto eCAALYX apresentado em 2.6.3, também o iCare [30] é um sistema com

foco na população idosa. É composto pelos habituais sensores colocados nos pacientes que enviam14

os dados para um smartphone que os comunica para um servidor, onde se encontra um profissional

de saúde a fazer a avaliação. No entanto este projeto tem também o objetivo de ser um assistente16

para os idosos, de modo a utilizar capacidades do smartphone como o alarme e a localização, para

ajudar o paciente a tomar a medicação às horas certas ou a localizar-se.18

2.7 Resumo e Conclusões

Neste capítulo foram apresentadas as plataformas móveis existentes que poderiam ser con-20

sideradas para o desenvolvimento da aplicação. Também foram referidos alguns dispositivos de

recolha de bio sinais com interface bluetooth que poderão ser utilizados com a aplicação. Foram22

também apresentados projetos que implementam algoritmos de deteção de quedas. Por fim fo-

ram apresentados trabalhos relacionados com o tema desta Dissertação, dos quais se destacam os24

projetos referentes a Sistemas de Monitorização Móvel.

15

Revisão Bibliográfica

16

Capítulo 3

Definição do Problema2

Neste capítulo é apresentado o problema que deu origem a esta Dissertação e explicada a4

solução implementada para o solucionar.

3.1 Descrição6

Mais de 30% dos óbitos em Portugal devem-se a doenças cardiovasculares[4]. Muitas destas

doenças podem ser vigiadas de modo a prevenir episódios irreversíveis, ou até mesmo a morte,8

recorrendo a uma monitorização dos pacientes. Para isso, atualmente, são usados dispositivos

como o monitor de Holter [5] que permite monitorizar, e armazenar, os dados dos sinais vitais du-10

rante um período de tempo, normalmente de um dia, para depois serem analisados por um médico.

Esta monitorização é de diagnóstico, e não de prevenção, devido a não ser uma monitorização em12

tempo real, ou seja, se existir algum sinal com valores alterados só será detetado quando o paciente

se dirigir ao médico.14

Com o dia a dia cada vez mais preenchido das pessoas que compõem a população ativa, é difícil

estas manterem uma vigilância contínua dos seus familiares idosos, com doenças diagnosticadas.16

No caso de estes idosos necessitarem de ser monitorizados continuamente, devido a problemas

cardiovasculares, e não só, torna-se essencial haver uma plataforma que autonomize este processo18

e que permita a monitorização à distância, permitindo assim que, por exemplo, um filho a partir

do seu emprego, mantenha a vigilância remotamente do seu pai, não necessitando de se deslocar20

a casa. No caso de os valores dos sinais estarem alterados o filho receberia um alerta podendo

depois contactar a assistência médica.22

Também no caso de idosos independentes, sem problemas diagnosticados, pode ser de in-

teresse manter uma monitorização das suas atividades e sinais vitais, de modo a permitir uma24

intervenção atempada no caso de um episódio de urgência, como uma queda. Um terço das pes-

soas com idade acima dos 65 anos cai pelo menos uma vez por ano [17]. Estas quedas, que podem26

criar fraturas, podem imobilizar o idoso, que necessitará de assistência médica urgente. No caso

17

Definição do Problema

de ser um idoso que vive sozinho podem passar horas sem que este seja assistido, o que aumentará

os efeitos de uma queda que seria inofensiva. Imaginemos um idoso que vive com a sua mulher 2

em casa. Este pode estar a realizar as suas tarefas de casa e desequilibrar-se e cair, sem a sua

mulher se aperceber porque está noutro compartimento. No entanto, se o seu filho recebesse um 4

alerta de queda conseguiria contactar a sua mãe para ir em auxílio do seu pai.

Em casos de demência é também importante manter sob vigilância a localização de um idoso, 6

pois o idoso pode perder a noção da localização em que se encontra.

É então necessária uma plataforma que detete episódios como quedas, monitorize os sinais 8

vitais, a localização, lance alertas, trate e envie os dados de sensores de monitorização do idoso

para uma aplicação remota e permita a um cuidador, como o familiar, visualizar os dados da 10

monitorização e receber alertas em casos de emergência de modo a poder contactar uma equipa de

assistência médica. 12

Esta Dissertação concentra-se na resolução do problema central do diagrama 1.1, a implemen-

tação da PMP. Esta PMP necessitará de comunicar com os outros 2 componentes desta arquitetura, 14

os sensores e o servidor remoto. Para desenvolver esta plataforma é também necessário ter em

conta a mobilidade do dispositivo, para não ser um dispositivo intrusivo para o utilizador, e a sua 16

autonomia, de modo a permitir que o utilizador seja monitorizado durante um dia inteiro.

3.1.1 Requisitos 18

A Plataforma de Monitorização Pessoal necessita de cumprir os seguintes requisitos:

• Manter uma execução contínua; 20

• Obter valores de sensores de monitorização;

• Armazenar dados de monitorização; 22

• Configurar tipos de monitorização;

• Gerir sensores conectados; 24

• Tratamento de dados de monitorização;

• Comunicação de valores de monitorização em tempo real para servidor remoto; 26

• Minimizar custos associados à transferência de dados para o servidor;

• Deteção de quedas; 28

• Monitorização da localização;

• Permitir configurar valores para lançamento de alertas; 30

• Lançamento e envio de alertas;

18

Definição do Problema

3.2 Solução

3.2.1 Plataforma de Desenvolvimento2

Devido às funcionalidades disponibilizadas e cada vez maior aderência por parte da popula-

ção aos smartphones, este tipo de dispositivo é o candidato ideal a servir de PMP. A escolha da4

plataforma onde foi desenvolvida a aplicação dependeu de diversos fatores, como:

• Facilidade de desenvolvimento;6

• Liberdade de desenvolvimento;

• Acesso a funcionalidades dos dispositivos;8

• Preço dos dispositivos;

• Grau de adoção da plataforma.10

Das plataformas apresentadas em 2.1, a que atualmente tem maiores vantagens nestes pon-

tos é o Android. É um sistema aberto, que permite uma maior liberdade de desenvolvimento, e12

distribuição, de aplicações. Para esta Dissertação é muito importante ter esta liberdade pois há a

necessidade de comunicar com o hardware do sistema sem restrições. As ferramentas para desen-14

volvimento de aplicações são também de fácil acesso e utilização. O preço e o grau de adoção

permitem que a aplicação possa ser utilizada pelo maior número de pessoas.16

De modo a saber que tipo de aplicação criar, foi necessário estudar a forma como é dada

a prioridade aos diferentes tipos de processos pelo Android. O sistema Android faz a gestão18

automática dos recursos do smartphone com base na prioridade definida para cada aplicação. É

de grande importância controlar os recursos, desde tempo de processamento a memória RAM20

disponível, para uma experiência de utilização favorável ao utilizador. Assim, um processo em

Android pode encontrar-se em vários estados:22

• Primeiro Plano - Os processos são considerados como estando em primeiro plano quando

são necessários para algo que o utilizador esteja a realizar. Normalmente, em cada momento,24

há poucos processos deste tipo e estes só serão terminados pelo sistema se os recursos forem

de tal forma escassos que nem sirvam para manter o processo em execução.26

• Visível - São processos que, não estando a receber interação do utilizador, estão visíveis

para este. Este tipo de processos só serão terminados se um processo em primeiro plano28

necessitar dos recursos ocupados por este.

• Serviço - São considerados Serviços os processos que, apesar de não estarem diretamente30

visíveis ao utilizador, realizam tarefas importantes para o que o utilizador está a realizar,

como por exemplo, reproduzir música em segundo plano ou transferência de informação.32

São terminados se um processo com maior prioridade necessitar dos recursos, mas serão

recomeçados quando os recursos voltarem a ficar disponíveis.34

19

Definição do Problema

• Segundo Plano - São processos que não estão a interagir com o utilizador, e portanto po-

dem ser terminados pelo sistema, quando necessário, sem afetar a experiência do utilizador. 2

Normalmente existem vários processos deste tipo e por isso são mantidos em segundo plano

de acordo com a ordem de utilização, de modo a que o sistema termine os utilizados há mais 4

tempo, mantendo os processos mais recentes em memória para que quando o utilizador re-

torne ao processo este recomece rapidamente e esteja logo pronto a receber a sua interação. 6

• Vazio - Este tipo de processos apenas se mantêm em memória de modo a recomeçarem mais

rapidamente quando solicitados. 8

Primeiro Plano

Visível

Serviço

Segundo Plano

Vazio

Prioridade

Figura 3.1: Prioridade de Processos em Android

Assim, para manter uma monitorização contínua, o tipo de processo que se adequa melhor às

necessidades desta aplicação é um Serviço. 10

3.2.2 Funcionalidades

Foram então aproveitadas diversas funcionalidades do sistema Android, como: 12

• Serviços, que podem ser executados em background sem haver a necessidade de interação

do utilizador, e permitindo também que o utilizador realize outras tarefas ao mesmo tempo 14

no smartphone.

• Comunicação, tanto para receber os dados dos sensores, através de bluetooth, como para 16

transmitir os dados processados para o servidor remoto e até, em caso de urgência, comuni-

car um alerta à pessoa responsável pelo paciente ou aos serviços de urgência médica. 18

20

Definição do Problema

• Localização, de modo a permitir ao cuidador saber onde se encontra o paciente a qualquer

momento.2

• Acelerómetro e Giroscópio, dos quais os dados são cruzados com os dados obtidos do

dispositivo bluetooth para uma melhor avaliação. É também através do acelerómetro que4

são detetadas as quedas.

• Notificações, que podem notificar o utilizador de alguma anomalia.6

• Armazenamento Local, que permite guardar dados recebidos dos sensores para serem

transmitidos ao servidor remoto quando possível.8

Para conseguir implementar uma monitorização contínua, é necessário termos um processo a

processar a informação dos sensores continuamente, em segundo plano. Considerando a natureza10

desta aplicação foi então escolhida a implementação de um Serviço. Devido à possibilidade de

o Serviço ser terminado pelo Sistema, e posteriormente recomeçado, é necessário ter uma boa12

política de persistência de modo a, quando o Serviço for terminado e voltar a iniciar, o estado de

ligação aos sensores e os dados não serem perdidos.14

De modo a conseguir fazer a monitorização dos sinais vitais do utilizador, são utilizados sen-

sores que recolhem dados de ritmo cardíaco, frequência respiratória, eletrocardiograma e tempe-16

ratura. Os sensores utilizados, que utilizam interface Bluetooth para a comunicação, são o Zephyr

BioHarness, apresentado em 2.2.1, o Zephyr HXM, referido em 2.2.2, e a plataforma de aquisição18

de bio sinais desenvolvida por João Oliveira, descrita em 2.2.4. A comunicação com os senso-

res foi desenvolvida recorrendo às bibliotecas fornecidas pelo sistema Android para comunicação20

por Bluetooth. Estas bibliotecas contêm métodos que permitem gerir a transmissão de dados en-

tre o sensor e o smartphone. Estes dados são depois processados no smartphone, verificando se22

se encontram dentro dos limites delimitados pelo cuidador. No caso de ultrapassarem os limites é

lançado um alerta local e no servidor remoto. Os dados além de serem processados no smartphone24

são também enviados para o servidor remoto, podendo ser visualizados pelo cuidador através de

uma aplicação web.26

Aproveitando os sensores embutidos no smartphone, nomeadamente o GPS e o acelerómetro,

é possível complementar os dados obtidos pelos outros sensores. No caso do GPS é possível se-28

guir a posição de um utilizador, sabendo onde se encontra a qualquer momento. No caso de uma

emergência é essencial saber onde está localizado o utilizador. No entanto também foi implemen-30

tada uma funcionalidade de geofencing. Para a sua configuração é pedido ao cuidador que indique

um ponto no mapa, e um raio do qual a pessoa a ser monitorizada não deverá sair. Se a pessoa sair32

desse raio será lançado um alerta, avisando o cuidador e a própria pessoa.

Recorrendo ao acelerómetro também é possível saber o nível de atividade de um utilizador,34

fundindo assim com dados como o ritmo cardíaco de modo a saber se o ritmo é o esperado tendo

em conta o nível de atividade ou não. Com o acelerómetro é também possível detetar quedas do36

utilizador, e se houve recuperação após a queda ou o utilizador ficou imobilizado. Para isso é

utilizado um método que tem em conta três variáveis: a força a que está sujeito, o movimento38

21

Definição do Problema

e a orientação do smartphone. Sabendo que numa queda a força a que está sujeito irá diminuir,

e no embate com o chão aumentar, temos um padrão que permite detetar quedas. Neste padrão, 2

de um pico mínimo seguido de um pico máximo, é necessário também avaliar a diferença de

valores entre os picos recorrendo a um threshold cujo valor foi definido depois de recorrer a vários 4

testes, para limitar alguns episódios que poderiam ser também considerados como quedas. Além

da força é possível também avaliar se a pessoa recuperou da queda, ou permaneceu imobilizada 6

no chão, através dos valores de movimento do acelerómetro. Para tornar a deteção de queda mais

robusta também se recorre à orientação do dispositivo, verificando a orientação do smartphone 8

antes e depois da possível queda. Se tivermos uma variação considerável, pe. passando de vertical

a horizontal, consideramos que é uma queda, no entanto se a orientação permanecer inalterada, 10

como no caso de um salto, não consideraremos como queda.

Também é necessário ter em conta o público alvo da aplicação, que será, em grande número, 12

constituído por uma faixa etária mais elevada que poderá ter dificuldades em interagir com o

smartphone. Foi necessário desenvolver uma interface simples, que necessita do mínimo de inter- 14

venção possível por parte do utilizador.

3.3 Aplicações Existentes 16

Na empresa onde foi realizada a Dissertação já estavam a ser desenvolvidas a aplicação web e

a aplicação móvel que trata da interface com o utilizador. Assim, foi necessário integrar o Serviço 18

implementado na aplicação móvel, desenvolvendo métodos que permitissem a gestão do Serviço

através da aplicação. Na figura 3.2 podemos ver onde será inserido o Serviço implementado. 20

Sensores

Serviço

Smartphone Servidor

Figura 3.2: Arquitetura do sistema onde será integrado o Serviço

3.3.1 Aplicação Móvel - Keepcare Mobile

A aplicação Keepcare Mobile consiste numa aplicação que permite ao utilizador: 22

• Ver os dados da monitorização;

22

Definição do Problema

• Criar um lembrete;

• Ver alertas;2

• Desligar parâmetros de monitorização;

• Alterar limites para alertas;4

Esta aplicação para controlar os parâmetros da monitorização e alterar os limites para alertas

comunica com o Serviço através de uma interface implementada pelo Serviço, apresentada em6

4.1. Os dados da monitorização são obtidos a partir da base de dados local, onde o Serviço guarda

a informação recebida dos sensores.8

3.3.2 Aplicação Web

A aplicação web possui as mesmas funcionalidades da aplicação móvel, no entanto, além do10

utilizador, pode também ser utilizada pelo cuidador para visualizar e gerir remotamente a moni-

torização do utilizador. Possui também um histórico mais alargado dos valores da monitorização,12

que é mais limitado no caso da aplicação móvel devido aos limites de armazenamento.

3.4 Resumo e Conclusões14

Neste capítulo foi detalhado o problema e a solução proposta para a sua resolução. Foram

enumeradas as funcionalidades expectáveis da solução de modo a cumprir os requisitos.16

23

Definição do Problema

24

Capítulo 4

Conceção2

4.1 Serviço

Sensores Smartphone Servidor Remoto

Figura 4.1: Visão geral do Sistema

Na figura 4.1 estão representados os vários blocos do sistema e as tecnologias de comunicação4

utilizadas na transferência de informação. Como base da aplicação, e devido à forma como o

Android faz a gestão dos recursos, foi criado um Serviço, que faz a gestão de todo o funcionamento6

da aplicação.

ClientWebService

Sensor HXM/

BioHarness/etc.

GPS

LocalStorage

WebService

AlertGenerator

Acelerómetro

SensorData

Sensores Serviço Local Servidor Remoto

SensorManagers

(HXM, BioHarness, etc.)

Location Data

Accelerometer Data

Figura 4.2: Organização do Sistema

25

Conceção

De modo a manter a aplicação expansível a outros tipos de sensores, foi criada uma classe para

cada tipo de sensor. Assim, sempre que for necessário implementar um protocolo de comunicação 2

para um novo sensor, deverá ser criada uma nova classe que faça a gestão dessa comunicação. O

Serviço contém um objeto de cada sensor conectado, fazendo assim uma gestão independente para 4

cada um, e permitindo acrescentar novos objetos à medida que forem adquiridos novos sensores.

Na figura 4.2 podemos ver o fluxo que os dados têm dentro da aplicação. Os sensores, como o 6

Zephyr BioHarness, enviam os dados, que são tratados como objetos do tipo SensorData, para o

smartphone onde o Serviço os processa, armazena e envia para o servidor remoto. 8

Do smartphone é utilizado o acelerómetro e o sinal de GPS. Para isso a classe Accelerometer-

Data mantém-se à escuta dos dados do acelerómetro, implementando métodos para avaliação do 10

nível de atividade e deteção de quedas, descritos mais detalhadamente no capítulo 5. Para tratar

dos dados de localização é utilizada a classe LocationData. 12

Para o processamento de dados e lançamento de alertas é utilizada a classe AlertGenerator que

avalia se os dados dos sensores se encontram dentro dos valores esperados, lançando alertas em 14

caso negativo.

É necessário o Serviço implementar uma interface de modo a possibilitar que a aplicação res- 16

ponsável pela interface com o utilizador comunique com o Serviço, de modo a permitir que o

utilizador conecte a sensores e altere parâmetros de monitorização. A causa disto é que o Serviço 18

e a aplicação principal são executados em processos diferentes, e para estes casos são disponibili-

zadas as Interfaces AIDL. 20

1 22

2 interface IKeepcareService {

3 /** Request the process ID of this service, to do evil things with it. */ 24

4 int getPid();

5 26

6 /** Demonstrates some basic types that you can use as parameters

7 * and return values in AIDL. 28

8 */

9 void basicTypes(int anInt, long aLong, boolean aBoolean, float aFloat, 30

10 double aDouble, String aString);

11 32

12 /** Activate the HXM monitoring */

13 boolean ActivateHXM(String deviceName); 34

14 /** Deactivate the HXM monitoring */

15 void DeactivateHXM(); 36

16 /** Return the hxm connection status */

17 boolean getHXMState(); 38

18 /** Set the hxm monitorization parameters */

19 void setHXMMonitoring(boolean heartMonitoring); 40

20 /** Returns the current hxm monitoring status */

21 boolean[] getHXMMonitoring(); 42

22

23 44

26

Conceção

24 /** Activate the BioHarness monitoring */

25 boolean ActivateBioHarness(String deviceName);2

26 /** Deactivate the BioHarness monitoring */

27 void DeactivateBioHarness();4

28 /** Return the bioharness connection status */

29 boolean getBioHarnessState();6

30 /** Set the monitorization parameters */

31 void setBioHarnessMonitoring(boolean heartMonitoring, boolean8

respirationMonitoring,

32 boolean temperatureMonitoring, boolean ecgMonitoring);10

33 /** Returns the current bioharness monitoring status */

34 boolean[] getBioHarnessMonitoring();12

35

36 /** Activate the ABS monitoring */14

37 boolean ActivateABS(String deviceName);

38 /** Deactivate the ABS monitoring */16

39 void DeactivateABS();

40 /** Return the ABS status */18

41 boolean getABSState();

4220

43 /** Defines the parameters of the smartphone monitorization capabilities */

44 void setSmartphoneMonitoringState(boolean locationData, boolean fallDetection);22

45 /** Returns the current smartphone monitoring status */

46 boolean[] getSmartphoneMonitoringState();24

47

48 /** Returns the list of the connected devices Mac Addresses */26

49 List<String> getConnectedDevicesMacAddress();

5028

51 /** Returns a map with Macs to sensor types */

52 Map getConnectedDevicesMacToSensorType();30

53

54 /** Define the user id that is currently logged in */32

55 void setSessionId(int id);

56 }34

Listing 4.1: Interface AIDL implementada pelo Serviço

Um exemplo de comunicação entre a aplicação e o Serviço, através da interface AIDL, seria o36

caso em que é necessário iniciar a ligação ao sensor Zephyr BioHarness, exemplificado em 4.3.

27

Conceção

Aplicação Serviço

State

getBioHarnessState()

ActivateBioHarness()

Result

Figura 4.3: Sequência de Comunicação entre Aplicação e Serviço para ligação do Bioharness

De modo a haver uma sincronização entre a aplicação móvel e a aplicação web referida em

3.3.2, foi criada uma classe que gere a comunicação com o WebService. 2

4.2 Base de Dados

Para manter os dados localmente, no smartphone, foi necessário criar um esquema para a base 4

de dados local semelhante, mas mais simplificado, ao da base de dados remota. Nesta base de

dados, apresentada em 4.4, são guardados os valores de monitorização, de modo a permitir ao 6

utilizador ver a sua monitorização localmente, e a guardar os dados até serem enviados para o

servidor remoto. 8

Além dos últimos valores referentes à monitorização, a base de dados local permite que se-

jam armazenados também os dados pessoais do utilizador e configurações dos sensores, como os 10

limites.

28

Conceção

agentid integer Pname textusername textpassword textemail textn_tel textrec_email integerrec_sms integerupdate_time realedited integer

alertid integer Pserver_id integermsg textissue_date textnext_check textlevel integersensor_type textlimit_type textarchived_on textarchived integersensor_id integersynced integerupdate_time real

reminderid integer Pserver_id integermsg textissue_date textnext_check textperiod integerperiod_scale textlevel integerarchived integerarchived_on textactive integerupdate_time realagent_id integeredited integerremoved integer

sensorsensor_id integer Psensor_name textsensor_type textsensor_mac textdanger_min realdanger_max realalert_min realalert_max realdanger_battery realalert_battery realupdate_time realedited integer

sensordatadata_id integer PAsensor_id texttype textdata textdate realagent_id integersynced integeralert integer

Figura 4.4: Estrutura da Base de Dados

4.3 Resumo e Conclusões

Neste capítulo foi apresentada uma visão geral de como está estruturada a aplicação. A arqui-2

tetura do sistema foi desenhada de modo a ser fácil acrescentar novos tipos de sensores no futuro,

no entanto foi também afetada pelo modo de funcionamento do sistema Android.4

29

Conceção

30

Capítulo 5

Implementação2

A base da aplicação é um Serviço que gere a comunicação com os sensores e a sincronização4

com o servidor remoto. O Serviço implementa uma interface, definida em 4.1, de modo a permitir

que a aplicação principal, KeepCare Mobile apresentada em 3.3.1, comunique com este Serviço,6

permitindo ao utilizador alterar o estado de conexão com os sensores através da UI, tal como

outros parâmetros relevantes para a monitorização. Quando a aplicação KeepCare Mobile faz a8

ligação ao Serviço este devolve um objeto que permite à aplicação fazer chamadas ao Serviço.

Este Serviço recorre também a TimerTasks, que permitem que uma porção de código seja10

executada pontualmente. Assim foi possível implementar mecanismos de reconexão aos sensores,

no caso dos sensores se desconectarem por algum motivo, como saírem do alcance ou entrarem12

em hibernação.

5.1 Sensores14

Para cada tipo de sensor foi criada uma classe distinta para tratar da comunicação entre o

smartphone e o sensor, devido a cada sensor ter o seu protocolo de comunicação. Nesta classe16

foram implementados métodos para ligar e desligar a ligação ao sensor e detetar se a ligação

ainda se mantém ativa. Para isso, e sabendo que os sensores enviam dados, normalmente, de18

1 em 1 segundo, é executada uma instrução de minuto a minuto que verifica quando ocorreu a

última transmissão, marcando o sensor como desconectado se tiver sido ultrapassado um intervalo20

de tempo definido. Assim é possível ao Serviço saber a cada momento o estado de conexão

com os sensores. Para uma maior flexibilidade é também disponibilizado um método de ativar e22

desativar certos parâmetros de monitorização, de modo a que em sensores com mais de um tipo

de monitorização seja possível selecionar apenas os parâmetros necessários.24

Na imagem 5.1 está representada a interface criada para gerir a interface com os sensores. De-

vido ao modo como funciona a pesquisa de dispositivos por parte do Bluetooth, que é um processo26

demoroso e dispendioso de recursos, esta interface contém uma lista de todos os dispositivos já

31

Implementação

emparelhados com o smartphone e não dos dispositivos visíveis. Assim é possível selecionar um

dispositivo para ser conectado e, se o dispositivo estiver disponível e for reconhecido, a ligação 2

será criada e a célula da lista que contém o seu nome ficará verde. Devido a existirem diferentes

tipos de sensores, da primeira vez que é selecionado um dispositivo da lista é feita a transmissão 4

de uma mensagem de modo a reconhecer o tipo do sensor. Depois é guardado o seu tipo numa

lista de modo a não ser necessário fazer esta verificação novamente. 6

Figura 5.1: Lista de sensores emparelhados

5.1.1 Zephyr BioHarness

Tipo de Dados UnidadeRitmo Cardíaco bpmTemperatura Corporal oCFrequência Respiratória bpmECG mV

Tabela 5.1: Dados adquiridos pelo BioHarness

Para efetuar a comunicação com o sensor BioHarness recorreu-se ao SDK do mesmo, dispo- 8

nibilizado pela Zephyr. A troca de dados é feita recorrendo às bibliotecas de bluetooth do sistema,

mais especificamente utilizando BluetoothSocket e ao mecanismo de Threads para que a comu- 10

nicação seja feita assincronamente. Para obter os dados relevantes à monitorização a partir dos

32

Implementação

dados recebidos é utilizada uma biblioteca da Zephyr que extrai a informação dos Bytes recebi-

dos. O sensor envia 6 tipos de pacotes de dados diferentes. Para a monitorização utilizada os2

mais relevantes são o pacote de dados gerais, recebido em intervalos de 1 segundo, que contém o

ritmo cardíaco, a temperatura corporal e a frequência respiratória, o pacote de dados de ECG, re-4

cebido em intervalos de 252ms, e o pacote de gestão do sensor, que permite configurar os pacotes

enviados pelo sensor.6

O sensor possui um LED que permite saber o estado da ligação. Quando o LED fica vermelho

intermitente significa que o sensor está pronto a ligar-se a um dispositivo bluetooth.8

Figura 5.2: Zephy Bioharness pronto a receber ligação

Quando uma ligação foi criada o LED intercala a intermitência entre o vermelho e o verde.

5.1.2 Zephyr HXM10

Tipo de Dados UnidadeRitmo Cardíaco bpmVelocidade m/s

Tabela 5.2: Dados adquiridos pelo HXM

33

Implementação

No caso do sensor HXM também foi utilizado o SDK do mesmo, disponibilizado pela Zephyr.

A troca de dados é também feita recorrendo a BluetoothSocket e ao mecanismo de Threads para 2

que a comunicação seja feita assincronamente. O sensor envia apenas um pacote de dados a cada

segundo. Para obter os dados relevantes à monitorização a partir dos dados recebidos é utilizada 4

uma biblioteca da Zephyr que extrai a informação dos Bytes recebidos. No caso do HXM não

existem LEDs que identifiquem o estado atual do sensor. O sensor implementa também um método 6

de hibernação que ao fim de 5 minutos de inatividade deixa de enviar dados.

Figura 5.3: Zephyr HXM

5.1.3 ABS 8

Tipo de Dados UnidadeECG mV

Tabela 5.3: Dados adquiridos pelo sensor ABS

O sensor ABS é um sensor desenvolvido no âmbito de uma Dissertação do Mestrado Integrado

em Engenharia Electrotécnica e de Computadores pelo estudante João Oliveira. O sensor dispõe 10

de métodos para obter dados de ECG. Para testes iniciais com a plataforma ABS, devido a ser

ainda um protótipo, foi também utilizada a aplicação Docklight que simula a comunicação com a 12

plataforma. Assim a aplicação Docklight a correr num portátil recebia os pedidos do smartphone

e devolvia os dados requisitados. 14

Mais tarde, já com a plataforma ABS, para a implementação da comunicação com o sensor

recorreu-se, tal como nos sensores da Zephyr, a BluetoothSockets e Threads para manter a co- 16

municação assíncrona. Ao contrário dos sensores da Zephyr, o sensor ABS necessita de receber

34

Implementação

Figura 5.4: Simulação da comunicação com Docklight

pedidos para enviar os dados para o smartphone. Assim, foram também utilizadas TimerTasks que

permitem fazer pedidos de 500ms em 500ms ao sensor, recebendo 247 valores em cada transmis-2

são.

Smartphone Sensor ABS

GetECG()

DadosECG

getHeartRate(DadosECG)

Figura 5.5: Comunicação com Sensor ABS

Estes valores são posteriormente tratados de modo a obter o ritmo cardíaco a partir do sinal4

ECG. Para isso, e sabendo que o ritmo cardíaco pode ser calculado através da distância entre

as ondas R do ECG, foi utilizado um algoritmo adaptativo[31] que considera como ondas R os6

35

Implementação

valores acima de um threshold variável, que é atualizado a cada janela de valores. Após a deteção

das ondas R é calculada a distância temporal entre cada. Sabendo a distância entre cada onda R é 2

possível calcular o ritmo cardíaco através da fórmula 5.1.

Ritmo =60

RtoR(5.1)

Figura 5.6: Deteção de ondas R

Na figura 5.6 estão apontados os pontos detetados das ondas R. A exatidão do algoritmo de- 4

pende da largura e altura da onda R e da distância entre as ondas R. É expectável que a distância

entre 2 ondas R seja, no mínimo, de cerca de 250ms, considerando um ritmo cardíaco de 220 bpm. 6

Sabendo então que dois valores recebidos do sensor estão separados por 2ms, a janela de valores

utilizada para deteção da onda R tem o tamanho de 125 valores, de modo a corresponder a 250ms. 8

5.2 Ligação ao Servidor

O Web Service, implementado pela aplicação web, é um serviço SOAP que recebe objetos 10

do tipo XML. A aplicação desenvolvida apenas envia um tipo de mensagem ao Web Service,

estruturada como o exemplo em 5.1. Esta mensagem contém informação sobre os dados obtidos 12

de um determinado sensor.

14

1 <Message>

2 <sensor id="1" tipo="PulseRate" dados="60" stamp="1338973465000" /> 16

3 </Message>18

Listing 5.1: Mensagem enviada para WebService

De modo a não manter uma transferência constante de informação com o servidor, devido aos

dados dos sensores serem obtidos de segundo a segundo, apenas é enviada uma mensagem de 30 20

em 30 segundos contendo os dados dos sensores obtidos entretanto.

36

Implementação

5.3 Base de Dados Local

Utilizando os métodos disponibilizados pelo sistema foi implementada uma base de dados2

SQLite, que segue o esquema apresentado na figura 4.4.

Para reduzir o peso dos dados da monitorização no espaço de armazenamento do smartphone,4

os dados com mais de 2 dias, que já tenham sido sincronizados com o servidor remoto, são apaga-

dos da base de dados. Assim é possível ao utilizador ver os dados de monitorização dos últimos 26

dias, e se necessitar de ver datas anteriores poderá recorrer à aplicação web.

5.4 Geofencing8

Geofencing consiste na possibilidade de controlar e limitar o perímetro em que uma pessoa se

pode deslocar, despoletando um alerta quando o limite é transposto. Para a implementação são10

utilizados os serviços de localização disponibilizados pelo Android. Devido ao gasto energético

associado ao sensor de GPS, o sistema disponibiliza parâmetros de configuração que necessitam12

de ser afinados para uma melhor eficiência energética, sem afetar a usabilidade. Estes parâmetros,

definidos quando o Serviço é registado como estando à escuta das alterações de posição, consistem14

em valores para o tempo e distância percorrida entre cada atualização da posição. No caso da

necessidade da aplicação a precisão escolhida foi na ordem das centenas de metros e a taxa de16

atualização de 2 em 2 minutos.

Figura 5.7: Janela para definição da vedação virtual

37

Implementação

Assim, quando o Serviço recebe o evento de alteração de posição, fornecida pela antena GPS

do smartphone ou pela rede, determina se o utilizador se encontra dentro de limites predefinidos. 2

Estes limites consistem num raio de alcance e num ponto central, e podem ser definidos pelo

cuidador durante a configuração da aplicação. Para calcular a distância entre a posição atual e o 4

ponto central, e determinar se o utilizador se encontra dentro do raio definido, é necessário calcular

a distância entre dois pontos de coordenadas geográficas. No caso do utilizador se encontrar 6

fora do limite é lançado um alerta para o servidor remoto e uma notificação será apresentada no

smartphone. 8

5.5 Atividade

0  

0,5  

1  

1,5  

2  

2,5  

1   2   3   4   5   6   7   8   9   10  11  12  13  14  15  16  17  18  19  20  21  22  23  24  25  26  27  28  29  30  31  32  33  34  35  36  37  38  39  40  41  42  43  44  45  46  47  48  49  50  51  52  53  54  55  56  57  58  59  60  61  62  63  64  

Força  

Figura 5.8: Força exercida no smartphone a caminhar

O acelerómetro do smartphone mede a força (aceleração) a que o smartphone está exposto em 10

cada eixo em cada momento. Assim, e sabendo que o smartphone quando está em repouso apenas

está sujeito à força gravitacional, é possível calcular o vetor da força a que o smartphone está 12

sujeito e assim avaliar o nível de atividade do utilizador, conseguindo saber se este se encontra em

repouso ou em movimento. 14

1 // calculate the g-force 16

38

Implementação

2 double g=Math.sqrt(x * x + y * y + z * z)/SensorManager.GRAVITY_EARTH;2

Listing 5.2: Cálculo da Força G

Os níveis de atividade são considerados recorrendo a thresholds. A força, durante o movi-

mento, pode apresentar valores inferiores a 1G, como pode ser visto na figura 6.5. Para estes4

valores serem considerados como movimento é retirada à força obtida a força da gravidade e feito

o módulo ao valor obtido. Assim, é esperado que, em repouso, este valor seja 0, e com movimento6

será sempre superior a 0.

Valor = |G−Gravidade| (5.2)

Na figura 5.9 podemos ver um exemplo de dados obtidos enquanto uma pessoa desce escadas.8

Se fosse utilizada a média da Força G obtida teríamos valores perto dos 1G, portanto como se a

pessoa estivesse em repouso, no entanto isso não representaria a realidade. Assim, aplicando a10

fórmula 5.2, obtemos os valores a cinzento que permitem chegar à conclusão de que a pessoa se

encontra em movimento.12

0  

0,2  

0,4  

0,6  

0,8  

1  

1,2  

1,4  

1,6  

1,8  

1   6   11  

16  

21  

26  

31  

36  

41  

46  

51  

56  

61  

66  

71  

76  

81  

86  

91  

96  

101  

106  

111  

116  

121  

126  

131  

136  

141  

146  

151  

156  

161  

166  

171  

176  

181  

186  

191  

Força  G   Força  Processada  

0

0,2

0,4

0,6

0,8

1

1,2

1,4

1,6

1,8

1 6 11 16 21 26 31 36 41 46 51 56 61 66 71 76 81 86 91 96 101

106

111

116

121

126

131

136

141

146

151

156

161

166

171

176

181

186

191

Força  G Força  Processada

Figura 5.9: Força exercida no smartphone a descer escadas

Para obter resultados mais satisfatórios é também utilizada a média dos últimos 30 valores

obtidos pelo acelerómetro, para amenizar picos.14

No caso de se detetar que o nível de atividade do utilizador é elevado durante um certo pe-

ríodo tempo ao fim do qual o utilizador entra em repouso, é também considerado um intervalo de16

39

Implementação

tempo de recuperação. Este intervalo é importante para a avaliação composta dos sensores, pois é

expectável que o utilizador ao fim de realizar uma atividade com nível elevado de movimento se 2

encontre com, por exemplo, o ritmo cardíaco elevado durante o tempo de recuperação e não deve

ser lançado um alerta imediatamente. 4

5.6 Quedas

Durante uma queda, as forças que atuam sobre uma pessoa têm um padrão conhecido [19, 6

32, 31]. Em repouso a força a que o corpo está sujeito é de 1G, a força gravitacional. Durante

uma queda, a força exercida sobre uma pessoa diminui inicialmente, não chegando a 0G, tal como 8

numa queda livre, mas a valores de cerca de 0.3G. No momento anterior ao embate do corpo com

o chão a força está no seu mínimo, e, no embate, aumenta rapidamente, até valores acima de 2G. 10

Assim é possível, através dos valores obtidos do acelerómetro em 5.2, detetar um episódio de

queda através da deteção de um pico mínimo, a queda, seguido de um pico máximo, o impacto. 12

0  

0,2  

0,4  

0,6  

0,8  

1  

1,2  

1,4  

1,6  

1,8  

1   4   7   10  13  16  19  22  25  28  31  34  37  40  43  46  49  52  55  58  61  64  67  70  

Força  

Figura 5.10: Força durante queda

Na figura 5.10 está representada a força a que o smartphone está sujeito numa queda simulada.

O método que deteta o padrão descrito consiste na avaliação dos valores da força a que está sujeito 14

o smartphone, recorrendo ao acelerómetro, verificando se o valor atual é um mínimo ou um má-

ximo. No caso de ser mínimo é guardado o seu valor e o momento em que ocorreu. No caso de ser 16

um máximo e não existir um mínimo já definido, o máximo é desprezado. No caso de existir um

mínimo é verificado se o máximo e o mínimo estão fora dos thresholds definidos para os episódios 18

de queda. Estes thresholds são definidos após vários testes de modo a evitar a deteção de episó-

dios do dia a dia como quedas, episódios como o utilizador sentar-se numa cadeira, em que a força 20

40

Implementação

mínima é superior à força mínima numa queda. No caso de não haver nenhum máximo acima

do threshold para o máximo durante um intervalo de 500 ms (o tempo de queda) após a deteção2

do mínimo, então o mínimo também é desprezado. Para tornar o reconhecimento mais robusto

foi também utilizada a orientação do dispositivo [19], para, por exemplo, evitar reconhecer saltos4

como quedas. Sabendo que uma pessoa depois de cair fica numa posição diferente da posição

antes da queda, é possível comparar a orientação do smartphone antes e após a possível queda.6

Para isso é necessário ter em conta as 3 componentes do acelerómetro, referentes aos 3 eixos, de

modo a calcular a variação da força aplicada em cada eixo nos momentos antes e depois da queda.8

Depois de detetada uma queda é ainda possível saber se o utilizador recuperou da queda ou se

permaneceu imobilizado. Para isso é detetado se existe movimento nos 30 segundos após a queda,10

que indicaria que o utilizador se teria levantado. Se não for detetado movimento será considerada

uma queda sem recuperação.12

Na implementação do algoritmo de quedas, após alguns testes com o equipamento disponível,

um Samsung Galaxy Y, chegou-se à conclusão que a deteção, apesar de realizar a deteção de14

quedas de uma forma muito favorável, infelizmente também detetava alguns falsos positivos. Para

a deteção ser mais robusta seria necessário utilizar um smartphone com, além do acelerómetro, um16

giroscópio, que atualmente existem em número muito reduzido. Assim seria possível determinar

de forma mais exata as alterações de orientação entre os momentos anterior e posterior à queda18

pois o giroscópio permite saber a rotação que o smartphone sofreu em cada eixo. Para resolver

este problema foi decidido que apenas seriam consideradas quedas episódios em que o utilizador20

permanecesse deitado depois de detetado o episódio de queda. Para isso foi implementado um

método que após a deteção do padrão de queda fica à escuta do acelerómetro de modo a verificar22

se o nível de atividade do utilizador chega a um certo nível. Se for então detetada atividade, nos

segundos seguintes à queda, significa que se terá levantado e a possível queda será desprezada.24

Assim é possível prevenir casos de falsos positivos detetados durante os testes, em situações como

a subida de escadas. De modo a eliminar falsos positivos no caso de não ser detetado movimento26

após a queda, é lançado um alarme com a duração de 20 segundos, no smartphone, que permite

ao utilizador cancelar o envio do alerta de queda. Apenas no fim do alarme, se o utilizador não28

cancelar, é que será lançado o alerta.

5.7 Avaliação de Dados e Alertas30

A avaliação dos dados dos sensores é feita sempre que é recebida informação. Esta avaliação

consiste em verificar se os valores recebidos se encontram dentro dos limites inferiores e superi-32

ores definidos, de alerta e perigo. Para a avaliação de alguns parâmetros, como o caso do ritmo

cardíaco, é também tido em conta o nível de atividade do utilizador, sendo que os limites são adap-34

tados ao nível de atividade atual. Devido à possível existência de ruído não era fiável o lançamento

de notificações no caso de haver um valor a ultrapassar os limites, e portanto é feita a avaliação36

recorrendo a um número de valores consecutivos. Se um certo número de valores ultrapassar o

limite de alerta ou perigo é lançada a notificação de alerta, e enviada a informação ao servidor38

41

Implementação

remoto. A informação de alerta enviada são os últimos segundos de dados recebidos antes de o

alerta ocorrer. No caso de o limite ultrapassado ser de alerta a notificação gerada pode ser cance- 2

lada, se os valores normalizarem nos instantes seguintes. Em casos de queda sem recuperação são

também enviados alertas para o servidor com a informação da localização do utilizador. 4

5.8 Resumo e Conclusões

Neste capítulo foi detalhada a Implementação da solução, explicando como foram implemen- 6

tadas as funcionalidades presentes nos requisitos e os algoritmos utilizados.

42

Capítulo 6

Testes e Resultados2

Neste capítulo serão apresentados testes realizados ao funcionamento da aplicação desenvol-4

vida. Devido à natureza da aplicação, que maioritariamente consiste num Serviço que corre em

background, não é possível demonstrar a aplicação em execução, no entanto é possível ver os6

efeitos da aplicação, e isso será mostrado nesta secção. Para os testes feitos foi utilizado o equipa-

mento Samsung Galaxy Y.8

43

Testes e Resultados

6.1 Dados de Monitorização

A obtenção dos dados de monitorização através dos sensores foi testada com os sensores 2

Zephyr HXM, Zephyr BioHarness e ABS. Na figura 6.1 estão a ser mostrados os dados obtidos a

partir do sensor. Estes dados são dados presentes localmente na base de dados. 4

Figura 6.1: Dados de monitorização obtidos a partir do Zephyr HXM

Depois de obtidos os dados dos sensores, estes, além de serem armazenados localmente, são

enviados ao servidor. Na imagem 6.2 podemos ver na aplicação web os dados anteriormente 6

mostrados na aplicação móvel.

Figura 6.2: Aplicação Web com dados recebidos

44

Testes e Resultados

Para o lançamento de alertas foi simulada a existência de valores fora dos limites esperados.

Na figura 6.3 é apresentada uma notificação ao utilizador quando o limite é ultrapassado com2

vários valores consecutivos.

Figura 6.3: Notificação de alerta

6.2 Deteção de Quedas4

Para testar o algoritmo de deteção de quedas foram realizadas simulações de possíveis quedas

no dia a dia. De modo a não haver lesões as quedas eram feitas para um colchão, o que no final6

acaba por afetar o resultado da força máxima exercida, devido ao amortecimento da queda. Tal

como visto na figura 5.10, numa queda temos um mínimo seguido de um máximo. Assim, vai ser8

apresentada uma tabela com valores mínimos e máximos obtidos nos testes. Estas quedas foram

todas detetadas pelo algoritmo.10

O grande desafio do algoritmo é a eliminação de falsos positivos. Existem diversos casos do

dia a dia com padrões de força iguais ao de uma queda. Nos testes realizados, como o da figura12

6.4, temos o padrão de forças exercidas durante a descida de degraus. Existem alguns momentos,

compostos por pontos mínimos seguidos de máximos que ultrapassam os thresholds, que seriam14

detetados como queda. No entanto, no caso do smartphone estar equipado com giroscópio, a

orientação seria tida em conta e, devido à orientação se manter quase constante, nestes pontos16

não seriam consideradas quedas. No caso de smartphones sem giroscópio seria considerado o

movimento que ocorre após a deteção do episódio de queda e ainda, no caso de ser considerada18

queda, dar a oportunidade ao utilizador de identificar o episódio como falso positivo.

45

Testes e Resultados

Mínimo Máximo Detetada0.440558514145203 1.804129392231330 Sim0.598867775210669 1.935861237160340 Sim0.498288078016330 1.955935415950680 Sim0.360053709948513 1.857338730819520 Sim0.391872987903297 1.973827750086030 Sim0.396518051296940 1.898999933489810 Sim0.331456279329699 2.021189046377210 Sim0.481594821183422 2.126148575899280 Sim0.250974667570889 1.801827547127440 Sim0.398360918636170 1.811759019558920 Sim0.397133269790199 1.896040743651580 Sim0.371730533139451 1.875716041098280 Sim0.308569018235600 2.333833272296210 Sim0.396518051296940 2.292566194510230 Sim0.493364165698935 2.360047655149800 Sim0.546874986517950 2.020041123320280 Sim0.430790274687336 2.277233082343250 Sim0.398867775210669 2.587577185401450 Sim0.265625001100976 2.275946396044480 Sim

Tabela 6.1: Dados adquiridos em várias quedas

Figura 6.4: Força durante a descida de degraus

46

Testes e Resultados

6.3 Avaliação de Atividade

Para a avaliação da atividade física também são usados thresholds. Para a definição destes2

thresholds foram feitos testes de diferentes tipos de atividade. Na figura 6.5 podemos ver a força

exercida durante uma caminhada, e o threshold definido como mínimo para a atividade ser consi-4

derada baixa.

0  

0,05  

0,1  

0,15  

0,2  

0,25  

0,3  

0,35  

0,4  

0,45  

1   5   9   13  

17  

21  

25  

29  

33  

37  

41  

45  

49  

53  

57  

61  

65  

69  

73  

77  

81  

85  

89  

93  

97  

101  

105  

109  

113  

117  

121  

125  

129  

133  

137  

141  

145  

149  

153  

157  

161  

165  

169  

173  

177  

181  

185  

189  

193  

197  

201  

205  

209  

213  

217  

221  

225  

229  

233  

237  

Força  exercida   Ac8vidade  baixa  

Figura 6.5: Força durante uma caminhada

Na imagem 6.6 temos o padrão de forças exercido numa corrida e o threshold usado para6

marcar a atividade como alta.

0  

0,1  

0,2  

0,3  

0,4  

0,5  

0,6  

0,7  

0,8  

1   3   5   7   9   11  

13  

15  

17  

19  

21  

23  

25  

27  

29  

31  

33  

35  

37  

39  

41  

43  

45  

47  

49  

51  

53  

55  

57  

59  

61  

63  

65  

67  

69  

71  

73  

75  

77  

79  

81  

83  

85  

87  

89  

91  

93  

95  

97  

99  

101  

103  

105  

107  

109  

111  

113  

115  

117  

Força  exercida   Ac8vidade  alta  

Figura 6.6: Força durante uma corrida

47

Testes e Resultados

6.4 Resumo e Conclusões

Neste capítulo foram apresentados alguns testes realizados com a aplicação desenvolvida. No 2

caso dos dados de monitorização temos uma aplicação capaz de obter os dados dos sensores,

armazená-los localmente e enviá-los para um servidor, sendo antes processados e lançados alertas 4

se necessário. Na deteção de quedas os resultados são animadores, a deteção é feita em pratica-

mente todas as quedas testadas, no entanto é ainda necessario testar em ambientes reais, o que 6

neste caso é uma tarefa difícil. A avaliação de atividade também se revelou precisa, podendo até

mais tarde, e após testes com mais utilizadores, os thresholds serem definidos consoante o tipo de 8

utilizador.

48

Capítulo 7

Conclusões e Trabalho Futuro2

O objetivo deste relatório foi apresentar o trabalho realizado para a Dissertação. Este trabalho4

compreendeu diversas fases, começando pela revisão bibliográfica feita no âmbito da disciplina de

Preparação da Dissertação, e completada durante a Dissertação, a fase de descrição do problema6

e a proposta de solução, passando finalmente à conceção e implementação da solução. Durante e

após a fase de implementação foram também realizados testes à solução implementada.8

Nesta Dissertação investigou-se a possibilidade de utilização de um dispositivo genérico para

substituir as plataformas de monitorização pessoal, utilizadas actualmente, que comunicam em10

tempo real com serviços médicos. Para isso, foi criada uma aplicação para smartphones Android

que permite adquirir dados de monitorização através de um sensor com interface bluetooth e enviá-12

los através da rede móvel ou Wi-Fi, para um servidor remoto. Estes dados são também processados

pela aplicação de modo a lançar alertas em caso de perigo. Esta aplicação aproveita também as14

ferramentas disponibilizadas pelo smartphone, nomeadamente o sensor de localização por GPS,

que permite monitorizar a posição do utilizador, e o sensor de aceleração. Através deste sensor16

foi implementado um sistema de deteção de quedas, que comunica com o servidor em caso de

emergência, e um sistema de avaliação da atividade física. Assim, foi possível fazer a correlação18

dos dados da atividade física com os dados dos sinais vitais obtidos para uma melhor avaliação da

condição do utilizador.20

7.1 Satisfação dos Objetivos

Os objetivos inicialmente definidos, de criação de uma plataforma de monitorização pessoal22

implementada num smartphone, foram cumpridos. Esta plataforma permite realizar a monitoriza-

ção dos sinais vitais de um utilizador, e ainda acrescentar funcionalidades baseadas nas caracterís-24

ticas dos smartphones, como a monitorização da localização e deteção de quedas. Assim, com este

trabalho, é possível concluir que os smartphones são um excelente candidato para a substituição26

de uma plataforma de monitorização pessoal específica.

49

Conclusões e Trabalho Futuro

7.2 Trabalho Futuro

No futuro, devido ao tipo de utilizadores a que a aplicação se destina, será necessário realizar 2

mais testes, com uma maior gama de utilizadores, de modo a otimizar alguns parâmetros dos

algoritmos de avaliação de atividade física e deteção de quedas. No caso do algoritmo de deteção 4

de quedas será também necessário avaliar os benefícios da utilização de um smartphone com

giroscópio embutido face ao seu custo, que atualmente ainda é elevado. Também com a introdução 6

de novos tipos de sensores será necessário implementar os protocolos de comunicação com estes,

que deverá ser um trabalho facilitado pela modularidade da aplicação nesse campo. Em relação 8

à interacção com o utilizador, será importante avaliar como é feita a utilização da aplicação por

parte de utilizadores idosos e como poderá ser facilitada essa interação. 10

50

Referências

[1] I. N. de Estatística, “Statistical yearbook 2010,” 2011. Disponível em2

http://www.ine.pt/ngt_server/attachfileu.jsp?look_parentBoui=133823849&att_display=n&att_download=y.4

[2] I. N. de Estatística, “As pessoas 2010,” 2012. Disponível em http://www.ine.pt/ngt_server/attachfileu.jsp?look_parentBoui=134078095&att_display=6

n&att_download=y.

[3] H. Edelberg, “Falls and function: how to prevent falls and injuries in patients with impaired8

mobility.,” Geriatrics, vol. 56, no. 3, p. 41, 2001.

[4] I. N. de Estatística, “Indicadores sociais 2010,” 2011. Disponível em http://www.10

ine.pt/ngt_server/attachfileu.jsp?look_parentBoui=132500372&att_display=n&att_download=y.12

[5] H. M. School, “Holter.” Disponível em http://mednet.umic.pt/portal/server.pt/community/Diagnostico/Diagnostico$Detail?idDiagnostico=14

DT0028_016, acedido a última vez em 31 de Janeiro de 2012.

[6] “More US Consumers Choosing Smartphones.” Disponí-16

vel em http://blog.nielsen.com/nielsenwire/consumer/more-us-consumers-choosing-smartphones-as-apple-closes-the-gap-on-android/,18

acedido a última vez em 23 de Janeiro de 2012.

[7] “Vendas de smartphones ultrapassam vendas de computadores.” Disponível em http://20

sol.sapo.pt/inicio/Tecnologia/Interior.aspx?content_id=40711, ace-dido a última vez em 7 de Fevereiro de 2012.22

[8] “Wimm one.” Disponível em http://www.wimm.com/wimm_preview.html, acedidoa última vez em 31 de Janeiro de 2012.24

[9] “Android - developers.” Disponível em http://www.android.com/developers/,acedido a última vez em 31 de Janeiro de 2012.26

[10] “ios dev center.” Disponível em http://developer.apple.com/devcenter/ios/index.action, acedido a última vez em 31 de Janeiro de 2012.28

[11] “App hub.” Disponível em http://create.msdn.com/en-US/, acedido a última vezem 31 de Janeiro de 2012.30

[12] J. a. Pedro and S. Oliveira, “Desenvolvimento e integração de sensores numa Plataforma parasistemas de Monitorização Pessoais,” 2012.32

51

REFERÊNCIAS

[13] “Instant heart rate.” Disponível em http://www.instantheartrate.com/, acedido aúltima vez em 7 de Fevereiro de 2012. 2

[14] “Brickhouse alert.” Disponível em http://www.brickhousealert.com/, acedido aúltima vez em 4 de Junho de 2012. 4

[15] “Itt easy line.” Disponível em http://www.ttmonaco.com/en/easy/default.htm,acedido a última vez em 4 de Junho de 2012. 6

[16] J. Dai, X. Bai, Z. Yang, and Z. Shen, “PerFallD: A pervasive fall detection system usingmobile phones,” Pervasive Computing and, 2010. 8

[17] M. Lan, A. Nahapetian, A. Vahdatpour, L. Au, W. Kaiser, and M. Sarrafzadeh, “SmartFall:An Automatic Fall Detection System Based on Subsequence Matching for the SmartCane,” 10

Proceedings of the 4th International ICST Conference on Body Area Networks, 2009.

[18] B. N. Jia, “Detecting Human Falls with a 3-Axis Digital Accelerometer,” pp. 1–7, 2009. 12

[19] M. Luštrek, H. Gjoreski, S. Kozina, B. Cvetkoviü, V. Mirchevska, and M. Gams, “DetectingFalls with Location Sensors and Accelerometers,” Artificial Intelligence, no. 2006, pp. 1662– 14

1667, 2010.

[20] A. Wood, G. Virone, T. Doan, and Q. Cao, “ALARM-NET: Wireless sensor networks for 16

assisted-living and residential monitoring,” tech. rep., 2006.

[21] T. Massey, T. Gao, M. Welsh, J. Sharp, and M. Sarrafzadeh, “The Design of a Decentralized 18

Triage System,” Signs, pp. 1–19, 2006.

[22] D. Wilson, S. Consolvo, and K. Fishkin, “In-home assessment of the activities of daily living 20

of the elderly,” In Extended Abstracts of CHI 2005: Workshops - HCI Challenges in HealthAssessment, pp. 1–3, 2005. 22

[23] J. Marsh, “House calls.” Disponível em http://www.rochester.edu/pr/Review/V64N3/feature2.html, acedido a última vez em 31 de Janeiro de 2012. 24

[24] A. House and T. Initiative, “A House_n + TIAX Initiative,” 2004.

[25] D. Malan, T. Fulford-jones, M. Welsh, and S. Moulton, “CodeBlue : An Ad Hoc Sensor 26

Network Infrastructure for Emergency Medical Care,” Robotics, pp. 3–6.

[26] H. Kautz, D. Fox, O. Etzioni, G. Borriello, and L. Arnstein, “An Overview of the Assisted 28

Cognition Project,” in In AAAI-2002 Workshop on Automation as Caregiver: The Role ofIntelligent Technology in Elder, 2002. 30

[27] V. Rocha, P. Borza, J. Correia, G. Goncalves, A. Puscas, R. Seromenho, A. Mascioletti,A. Picano, S. Cocorada, and M. Carp, “Wearable computing for patients with coronary di- 32

seases: Gathering efforts by comparing methods,” International Conference on Automation,Quality and Testing, Robotics, vol. 2, pp. 1–9, 2010. 34

[28] M. N. K. Boulos, S. Wheeler, C. Tavares, and R. Jones, “How smartphones are changing theface of mobile and participatory healthcare: an overview, with example from eCAALYX.,” 36

Biomedical engineering online, vol. 10, p. 24, Jan. 2011.

52

REFERÊNCIAS

[29] A. B. Waluyo, W.-S. Yeoh, I. Pek, Y. Yong, and X. Chen, “Mobisense: Mobile body sen-sor network for ambulatory monitoring,” in Transactions on Embedded Computing Systems,2

vol. 10, (1515 Broadway, 17th Floor, New York, NY 10036-5701, United States), 2010.

[30] Z. Lv, F. Xia, G. Wu, L. Yao, and Z. Chen, “iCare: A mobile health monitoring system for4

the elderly,” in Proceedings - 2010 IEEE/ACM International Conference on Green Compu-ting and Communications, GreenCom 2010, 2010 IEEE/ACM International Conference on6

Cyber, Physical and Social Computing, CPSCom 2010, (Hangzhou, China), pp. 699–705,2010.8

[31] H. C. Chen and S. W. Chen, “A Moving Average based Filtering System with its Applicationto Real-time QRS Detection,” Computers in Cardiology, 2003.10

[32] a. K. Bourke, J. V. O’Brien, and G. M. Lyons, “Evaluation of a threshold-based tri-axialaccelerometer fall detection algorithm.,” Gait & posture, vol. 26, pp. 194–9, July 2007.12

53