bruno miguel vieira fernandes - universidade do...

Bruno Miguel Vieira Fernandes

Sistema de Monitorização e Gestão deSinais Vitais baseado em Dispositivos Móveis

Brun

o M

iguel

Vieir

a Fe

rnan

des

Dezembro de 2011UMin

ho |

201

1Si

stem

a de

Mon

itori

zaçã

o e

Gest

ão d

eSi

nais

Vita

is b

asea

do e

m D

ispo

sitiv

os M

óvei

s

Universidade do MinhoEscola de Engenharia

Dezembro de 2011

Tese de MestradoCiclo de Estudos Integrados Conducentes ao Grau deMestre em Engenharia Eletrónica Industrial e Computadores

Trabalho efetuado sob a orientação doProfessor Doutor José Augusto AfonsoProfessor Doutor Ricardo João Ferreira Simões

Bruno Miguel Vieira Fernandes

Sistema de Monitorização e Gestão deSinais Vitais baseado em Dispositivos Móveis

Universidade do MinhoEscola de Engenharia

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis iii

Agradecimentos

A realização do trabalho de dissertação apresentado resulta de um longo

processo de desenvolvimento que não pôde deixar de contar com a contribuição de

inúmeras pessoas e instituições. Aqui quero deixar expressa a minha gratidão para

com todos que direta ou indiretamente me ajudaram a atingir este objetivo.

Quero agradecer aos meus orientadores, Professor José Augusto Afonso e

Professor Ricardo Simões, pelas importantes indicações dadas durante o projeto, mas

a cima de tudo pela disponibilidade e paciência que sempre demonstraram.

À Helena, por todo o apoio e incentivo e amizade, que sem dúvida ajudaram a

tornar todo o trabalho mais fácil.

Ao Duarte, pelos conhecimentos e valiosas informações transmitidas durante a

fase inicial da dissertação.

Ao Hospital Privado de Guimarães por ter disponibilizado as condições

necessárias à realização de testes clínicos, durante a fase de validação do projeto, e

ainda a todos seus enfermeiros e médicos que, posteriormente, participaram no

processo de avaliação.

Ao Doutor Otílio Rodrigues pelas relevantes observações efetuadas durante o

desenvolvimento e também pelas palavras de aprovação para com o trabalho final

apresentado.

Aos meus amigos pelo apoio, amizade e alegria que sempre me transmitiram.

Por último, mas não menos importante, à minha família por nunca me ter

deixado de me incentivar, durante a realização deste projeto, mas principalmente pelo

amor incondicional e pelas condições dadas para que sempre pudesse alcançar os

meus objetivos.

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis v

Resumo

O crescimento exponencial da utilização de equipamentos de computação e

comunicação móveis, a que temos assistido nos últimos anos, está diretamente

relacionado com as elevadas potencialidades e constantes inovações que lhes têm sido

conferidas. A área da medicina é uma das muitas que tem encontrado aplicabilidade

para estes equipamentos, e que, em associação com as mais recentes tecnologias de

mensuração e análise de sinais vitais tornou possível a construção de um novo

paradigma de monitorização médica.

Nesta dissertação é apresentado um sistema de gestão e monitorização que

recorre a um dispositivo móvel para efetuar o acompanhamento clínico de pacientes.

Este sistema foi desenvolvido como parte integrante do projeto de monitorização de

sinais vitais, MOHLL, que foi desenvolvido em parceria com o Hospital privado de

Guimarães, e para o qual foram criados de raiz os sensores wireless, a rede ZigBee de

encaminhamento de dados, o servidor de dados, e o Website para interação com os

restantes elementos do projeto.

O principal objetivo desta dissertação é permitir que pacientes não-críticos, em

internamento hospitalar ou doméstico, possam ter os seus dados vitais

permanentemente acompanhados por pessoal médico especializado, através de um

PDA com acesso à Internet.

Os sinais vitais passiveis de serem monitorizados são o ritmo cardíaco, a

temperatura corporal e o eletrocardiograma (ECG), mas existe ainda a possibilidade

alargamento aos sinais de oximetria e de pressão arterial, para os quais o sistema já se

encontra preparado.

Esta dissertação descreve o trabalho de integração no projeto MOHLL, do

sistema de monitorização e gestão com recurso a dipositivos móveis. Partindo de uma

primeira análise ao projeto e ao conjunto de características que a aplicação móvel

deveria possuir, é feita uma explicação de todo o processo de desenvolvimento e

implementação das funções disponibilizadas por esta aplicação. São ainda

apresentados os resultados das simulações operacionais e avaliações médicas que

permitiram validar o sistema desenvolvido como um instrumento adequado para a

monitorização de sinais vitais em tempo real.

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis vii

Abstract

In the past few years, we have witnessed an exponential growth of the mobile

communication and computing devices usage, which is directly related with the high

potential and constant features innovation that have been conferred upon them. The

medical field is one of the many which have found a particular use for these devices,

which alongside the latest vital signs acquisition and analysis technologies have made

possible the emergence of a new health monitoring paradigm.

This dissertation presents a monitoring and management system which uses a

mobile device to follow the health condition of inpatients. This system was developed

as a complement of a complete vital signs monitoring system, MOHLL project, which

was developed in partnership with the Guimarães Private Hospital, and for which were

designed from scratch the wireless sensors, the ZigBee network for data routing, the

data server, and the Website used to interact with the other project components.

The dissertation main objective is to allow hospital or home based non-critical

patients, to be continuously followed by a specialist physician, through an Internet-

connected PDA.

There are three types of signs which can be monitored through this system, they

are the heart rate, the body temperature and the ECG. However, there are also

implemented the necessary functions to address the oximetry and blood pressure

signals.

This dissertation provides a detailed description of the work carried out in order

to integrate the handset mobile monitoring and management system with the MOHLL

project. Starting from an initial analysis to the set of features that the mobile

application should be equipped with, the whole development and implementation

process of the provided functions is then explained. Also, there are presented the

operational test results and medical evaluation stats and comments that validated the

developed system as a suitable tool in the real-time vital signs monitoring process.

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis ix

Índice

Agradecimentos .................................................................................................................................... iii

Resumo .................................................................................................................................................. v

Abstract ............................................................................................................................................... vii

Índice .................................................................................................................................................... ix

Lista de Figuras ..................................................................................................................................... xi

Lista de Tabelas .................................................................................................................................. xiii

Lista de Abreviaturas ........................................................................................................................... xv

CAPÍTULO 1 Introdução ................................................................................................................ 1

1.1. Motivação e Enquadramento ......................................................................................................... 1

1.2. Objetivos ........................................................................................................................................ 5

1.3. Organização da Dissertação ........................................................................................................... 6

CAPÍTULO 2 Estado da Arte .......................................................................................................... 9

2.1. Introdução ...................................................................................................................................... 9

2.2. Classificação de Sistemas de Recolha e Transmissão de Sinais Cardíacos via PDA/Smartphones 10

2.3. Sistemas sem Análise Intermédia de Dados ................................................................................. 11

2.3.1. Secure Mobile Computing ................................................................................................. 11

2.3.2. Mobile Telemedicine System for Home Care and Patient Monitoring ............................. 12

2.3.3. A PDA-based Portable Wireless ECG Monitor for Medical Personal Area Networks ........ 14

2.4. Sistemas com Análise Intermédia de Dados................................................................................. 15

2.4.1. Wearable ECG-recording System for Continuous Arrhythmia Monitoring in a

Wireless Tele-Home-Care Situation .................................................................................................. 16

2.4.2. EPI- MEDICS ....................................................................................................................... 17

2.5. Outros Sistemas............................................................................................................................ 19

2.5.1. A Web Base System for ECG Data Transferred using ZigBee/IEEE Technology................. 19

2.5.2. Code Blue .......................................................................................................................... 21

CAPÍTULO 3 Projeto MOHLL ....................................................................................................... 23

3.1. Introdução .................................................................................................................................... 23

3.2. Sensores ....................................................................................................................................... 24

3.2.1. Eletrocardiograma............................................................................................................. 26

3.2.2. Ritmo Cardíaco .................................................................................................................. 28

3.2.3. Temperatura Corporal ...................................................................................................... 28

3.3. Rede ZigBee .................................................................................................................................. 29

3.3.1. Pilha protocolar ZigBee/IEEE 802.15.4 .............................................................................. 30

3.3.2. Arquitetura da Rede .......................................................................................................... 31

3.3.3. Routers e Coordenadores de Rede ................................................................................... 33

3.4. Sistema de Gestão e Visualização de Dados ................................................................................ 34

3.4.1. Aplicação de Recolha de Dados ........................................................................................ 35

3.4.2. Base de Dados ................................................................................................................... 37

3.4.3. Interface da Aplicação Web .............................................................................................. 38

3.4.4. Monitorização ................................................................................................................... 40

CAPÍTULO 4 Sistema de Monitorização e Gestão Móvel ............................................................. 43

Índice

x Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis

4.1. Introdução .................................................................................................................................... 43

4.2. Conceitos Teóricos e Hardware .................................................................................................... 44

4.2.1. Equipamentos Móveis ....................................................................................................... 45

4.2.2. Sistemas de Comunicação ................................................................................................. 47

4.2.3. Software ............................................................................................................................ 49

4.3. Estrutura e Análise Funcional das Aplicações Desenvolvidas ...................................................... 54

4.3.1. Análise de Requisitos ........................................................................................................ 54

4.3.2. Servidor – Suporte a Aplicações Móveis ........................................................................... 55

4.3.3. Aplicação para o PDA ........................................................................................................ 59

CAPÍTULO 5 Resultados Experimentais e Discussão.................................................................... 75

5.1. Introdução .................................................................................................................................... 75

5.2. Testes Não Funcionais .................................................................................................................. 76

5.3. Avaliação Médica ......................................................................................................................... 78

CAPÍTULO 6 Conclusões e Sugestões de Trabalho Futuro ........................................................... 81

6.1. Conclusões .................................................................................................................................... 81

6.2. Trabalho Futuro ............................................................................................................................ 82

Referências .......................................................................................................................................... 83

Anexo I ................................................................................................................................................ 87

Anexo II ............................................................................................................................................... 89

Anexo III .............................................................................................................................................. 91

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis xi

Lista de Figuras

Figura 1.1 - Estrutura do projeto MOHLL. .................................................................................................... 4

Figura 1.2 - Esquema de integração no projeto MOHLL. .............................................................................. 5

Figura 2.1 - Representação do sinal de ECG recebido [JurWe08]. ............................................................. 12

Figura 2.2 - Estrutura do sistema proposto (adaptada de [FigDi04]). ........................................................ 13

Figura 2.3 - Esquemas de monitorização permitidos pelo sistema [CaGoAl06]. ........................................ 14

Figura 2.4 - À esquerda, o sensor e o HDD. À direita, as diferentes partes do HDD [FeGu05]. ................. 16

Figura 2.5 - Arquitetura simplificada do sistema EPI-MEDICS [RuFaNo05]. ............................................... 18

Figura 2.6 - Estrutura do sistema criado [KhWaNa08]. .............................................................................. 19

Figura 2.7 - Software desenvolvido para o PDA [KhWaNa08]. ................................................................... 20

Figura 2.8 - Rede wireless criada por sensores e dispositivos móveis [We05]........................................... 21

Figura 3.1 - Arquitetura geral do sistema [FeAfCoSi10]. ............................................................................ 24

Figura 3.2 - Esquemático do sensor de ECG: (a) módulo de aquisição, (b) módulo de acondicionamento, (c) módulo de alimentação e (d) módulo de comunicação [Ma09]. .......................... 26

Figura 3.3 - Sensor de ECG e encapsulamento. (1) led indicador de atividade; (2) pilha; (3) interrutor ON/OFF; (4) módulo ZigBee; (5) representação de forma como orientação. ............................................ 27

Figura 3.4 - Representação gráfica do ciclo cardíaco com a indicação de cada uma das ondas do ECG e do intervalo entre as ondas R [TeBu10]. ................................................................................................. 28

Figura 3.5 - Arquitetura alto-nível da comunicação baseada em sistemas ZigBee. ................................... 31

Figura 3.6 - Topologias de rede ZigBee (adaptado de [NaIn10]). ............................................................... 31

Figura 3.7 - Protótipos de redes ZigBee aplicadas ao projeto MOHLL, implantadas através da topologia em malha (adaptado de [FeAfCoSi10]). ..................................................................................... 32

Figura 3.8 – Encapsulamento; Router/Coordenar de rede; antena. .......................................................... 33

Figura 3.9 - Serviços do sistema de gestão de dados e respetivas ligações. .............................................. 35

Figura 3.10 - Modelo Entidade - Relação da Base de Dados [Pe09]. .......................................................... 38

Figura 3.11 - Estrutura do Website para interação com os utilizadores [Pe09]. ........................................ 39

Figura 3.12 - Applet destinado a cada paciente. ........................................................................................ 40

Figura 3.13 – Janela de histórico de temperatura de um paciente ............................................................ 42

Figura 4.1 - Sistema de Monitorização e Gestão (Subsistema Móvel - a vermelho) [Adaptada de Pe09]. ......................................................................................................................................................... 44

Figura 4.2 - Qtek 9090 [Gsm10]. ................................................................................................................. 46

Figura 4.3 - Arquitetura da plataforma .Net Compact Framework [NCF11] .............................................. 51

Figura 4.4 - Relação entre os blocos do servidor ........................................................................................ 56

Figura 4.5 - Distribuição por camadas da AAD (exclusivamente para o Web Browser) [Pe09]. ................. 58

Figura 4.6 - Arquitetura do sistema de suporte à aplicação PDA [adaptada de FeAfSi11] ........................ 58

Figura 4.7 - Diagrama da interface da aplicação. ....................................................................................... 61

Figura 4.8 - Diagrama do processo de comunicação. ................................................................................. 62

Figura 4.9 - Janela de autenticação. ........................................................................................................... 63

Índice de Figuras

xii Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis

Figura 4.10 – Menu: esq. Monitorização; dir. Gestão de Pacientes ........................................................... 64

Figura 4.11 - Menu - Gestão de Sensores ................................................................................................... 64

Figura 4.12 - Janela Inserir Paciente (esq.); Janela Editar Paciente (dir.). .................................................. 65

Figura 4.13 - Janela Configurar Alertas ....................................................................................................... 66

Figura 4.14 - Janela Listar Associações esq.; Janela Associar Sensor dir. ................................................... 67

Figura 4.15 - Janela Inserir Sensor .............................................................................................................. 68

Figura 4.16 - Janela de Monitorização. ....................................................................................................... 69

Figura 4.17 - Janela Histórico de ECG ......................................................................................................... 70

Figura 4.18 - Janela Histórico de Temperatura. ......................................................................................... 71

Figura 4.19 - Escala da area de representação do sinal de ECG ................................................................. 72

Figura 4.20 - Funcionamento da Janela de Monitorização......................................................................... 73

Figura 4.21 - Janela de Recuperação de erros de ligação ........................................................................... 74

Figura 5.1 - Organização do sistema de monitorização durante a fase de testes ...................................... 75

Figura 5.2 - Teste efetuado por um profissional de saúde do HPG [FeAfSi11]........................................... 79

Figura 5.3 - Distribuição dos resultados da avaliação efetuada ................................................................. 80

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis xiii

Lista de Tabelas

Tabela I - Especificações protocolares das medições enviadas para a ARD ............................................... 36

Tabela II – Consumo energético e autonomia do PDA em função de diferentes modos de funcionamento ........................................................................................................................................... 76

Tabela III - Tempos de acesso às diferentes áreas do sistema ................................................................... 77

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis xv

Lista de Abreviaturas

AAD – Aplicação de Acesso aos Dados

ADC – Analog-to-Digital Converter

API – Application Programming Interface

APS – Application Support Sub-Layer

ARD – Aplicação de Recolha de Dados

BD – Base de Dados

CPU – Central Processing Unit

ECG – Eletrocardiograma

EHR – Electronic Health Record

EMG – Eletromiografia

GMT – Greenwich Mean Time

GPRS – General Packet Radio Service

GSM – Global System for Mobile Communications

HHD – Hand Held Device

HSPA – High Speed Packet Access

HTTP – Hypertext Transfer Protocol

HPG – Hospital Privado de Guimarães

IEEE – Institute of Electrical and Electronics Engineers

IP – Internet Protocol

JSP – Java Server Pages

MAC – Media Access Control

MIDP – Mobile Imformation Device Profile

MOHLL – Mobile Health Living Lab

MOLEC – Monitorización On-Line de Enfermos del Corazón

NWK – Network Layer

OEM – Original Equipment Manufacturer

PC – Personal Computer

PCMCIA – Personal Computer Memory Card International Association

PDA – Personal Digital Assistant

PEM – Personal ECG Monitor

Lista de Abreviaturas

xvi Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis

PHP – Hypertext Preprocessor

PHY – Physical Layer

RF – Radio Frequency

SDK – Software Development Kit

SGBD – Sistema Gestor de Base de Dados

SMS – Short Message Service

TCP – Transmission Control Protocol

UDP – User Datagram Protocol

UIT – União Internacional de Telecomunicações

UMTS – Universal Mobile Telecommunications System

URI – Uniform Resource Identifier

WPAN – Wireless Personal Area Network

XML – Extensible Markup Language

http://en.wikipedia.org/wiki/Physical_layer

Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis 1

CAPÍTULO 1

Introdução

Monitorizar um sistema ou atividade significa supervisionar, controlar, avaliar,

uma série de indicadores representativos do seu desempenho, ou seja, é a operação

que permite caracterizar o seu estado ou funcionamento.

No ambiente que nos rodeia existe uma grande quantidade de informação que

nos passa despercebida, ou simplesmente é ignorada por não nos parecer importante

ou ser inacessível. A tecnologia constitui um meio para aumentar a capacidade de o

ser humano captar e analisar essas informações, de modo a melhor interagir com o

meio circundante.

As tecnologias de monitorização médica são o meio que permite a recolha de

informações relativas a um elevado número de sinais fisiológicos, e que, quando

disponibilizados de forma fidedigna ao pessoal médico, são um importante

instrumento para uma análise precisa sobre o real estado de saúde do paciente

monitorizado.

1.1. Motivação e Enquadramento

Ao longo da última década (2000-2010), a utilização de dispositivos de

comunicações móveis, como telemóveis ou PDAs (Personal Digital Assistant), tem

registado uma elevada taxa de crescimento, levando a que os serviços de comunicação

disponibilizados por estes dispositivos sejam o meio de comunicação mais utilizado a

nível mundial. Dados da União Internacional das Telecomunicações (UIT) revelam que,

no fim de 2009, existiam cerca de 4,6 mil milhões de subscrições móveis ativas, o que

corresponde a 67% da população mundial, sendo que a taxa de penetração média nos

países desenvolvidos é superior a 100% [ITU10], como por exemplo em Portugal, onde,

no fim do segundo semestre de 2010, existiam mais de 15 milhões de estações móveis

ativas [AN10].

A enorme difusão dos serviços associados aos equipamentos de comunicação

móvel tem sido simultaneamente acompanhada pelo aumento das suas capacidades,

Capítulo 1 – Introdução

2 Sistema de monitorização e gestão de sinais vitais baseado em dispositivos móveis

deixando de ser aparelhos em que apenas a comunicação por voz ou através de

mensagens escritas era permitida, para se tornarem verdadeiros dispositivos de

computação, com um número de aplicações cada vez maior. Inovações tecnológicas,

como o aumento de capacidade de processamento e memória, acesso a redes wireless

com cada vez maior largura de banda ou a utilização de sistemas operativos

desenvolvidos especialmente para dispositivos como PDAs e smartphones, vieram

possibilitar a execução de funções normalmente associadas aos PCs (Personal

Computers), como por exemplo o uso de ferramentas de produtividade do tipo MS

Office, suporte para conteúdos multimédia, acesso à Internet ou a possibilidade de

desenvolvimento de aplicações próprias.

Os sistemas de comunicação disponibilizados têm também sido amplamente

desenvolvidos, aumentando tanto em número como em capacidade, velocidade ou

alcance. A difusão das redes 2G e 3G veio permitir a utilização de sistemas de

comunicação que vão desde o GSM/GPRS até ao UMTS/HSPA, onde já são possíveis

taxas de transferências de dados até 7.2 Mbit/s [Gra09]. Para além dos serviços de

comunicação de longa distância disponibilizados pelas operadoras móveis, estes

dispositivos permitem também transferência de dados em redes sem fios de curto

alcance, como as ligações Bluetooth ou as redes WLAN, a partir das quais se pode ter

acesso à Internet com elevadas velocidades de comunicação.

Todas as evoluções relacionadas com os dispositivos móveis vieram alargar o

número e o tipo de aplicações possíveis para estes, tornando-os elementos

indispensáveis em algumas áreas e com potencial para o serem em muitas outras.

Uma das áreas onde existem várias oportunidades de utilização destes equipamentos

computacionais é na prestação de cuidados de saúde, em que o número de aplicações

disponíveis tem vindo a crescer nas mais variadas vertentes da medicina [SaKah10].

Teleconsultas, transmissão de resultados de exames, monitorização de sinais vitais,

sistemas de diagnóstico, acionamento de alarmes em casos de emergência, gestores

de medicação, nutrição ou exercício, acesso ao historial médico de pacientes, ou

simplesmente disponibilização de informação médica para fins educativos, são

algumas das aplicações comercialmente disponíveis para os smartphones, quer dos

prestadores de cuidados de saúde, quer dos pacientes.

A monitorização de sinais vitais é um recurso de inegável importância no campo



da medicina, pois permite um permanente acompanhamento da condição fisiológica

dos pacientes. Através deste recurso, o tempo de resposta a emergências clínicas pode

ser significativamente reduzido em relação a casos em que não são utilizados

quaisquer sistemas de monitorização, possibilitando assim a tomada de medidas no

sentido de impedir o agravamento do estado clínico dos pacientes. Simultaneamente,

através da constante análise dos sinais vitais recolhidos, estes sistemas podem servir

para a deteção de doenças ainda em fase inicial. No entanto, os sistemas de

monitorização ainda têm uma reduzida taxa de utilização, estando reservados na sua

maioria para casos de internamentos nos cuidados intensivos [FeAfCoSi10]. Para uma

ampliação do número de utilizadores destes sistemas nas unidades hospitalares, estes

devem permitir o controlo eficiente de gastos e ser o menos invasivos possível,

recorrendo a sensores tão impercetíveis quanto possível, pelo uso, por exemplo, de

meios de comunicação sem fios com as unidades de visualização.

As tecnologias wireless vieram permitir uma separação entre os instrumentos de

aquisição de dados e os monitores, com a distância entre estes dois blocos a variar em

função da arquitetura do sistema de monitorização, podendo ir desde alguns metros

quando apenas se recorre a comunicações locais, até a vários milhares de quilómetros,

caso haja possibilidade de transmissão de informações via Internet. Desta forma, uma

análise precisa de determinado tipo de sintomas pode ser conseguida através da

transmissão de dados em longas distâncias, sendo assim disponibilizados meios para

que médicos especialistas avaliem condições clínicas particulares, mesmo não estando

presencialmente disponíveis. Este aspeto é particularmente importante, atendendo à

falta destes profissionais nos mais variados centros hospitalares e em relação às mais

variadas áreas médicas.

As comunicações usando redes sem fios podem também conferir maior

mobilidade aos pacientes, permitindo que estes se desloquem, enquanto são

monitorizados, numa determinada zona formada por redes com múltiplos recetores,

que enviam a informação para uma central de gestão de dados.

Tomando em consideração todos os factos anteriormente expostos, foi

desenvolvido o projeto apresentado nesta dissertação. O seu objetivo é, recorrendo às

inovações promovidas nos telemóveis, PDAs e smartphones, bem como no campo das

comunicações wireless e no dos sensores de parâmetros fisiológicos, implementar um



sistema de monitorização e gestão de dados de pacientes com recurso a dispositivos

móveis.

Esta dissertação surge no âmbito do projeto MOHLL (Mobile Health Living Lab),

que surgiu de uma pareceria criada entre a Universidade do Minho e a Casa de Saúde

de Guimarães, com o objetivo de desenvolver um sistema de monitorização remota de

sinais vitais de pacientes não críticos.

Este projeto visa permitir que sinais fisiológicos como temperatura, ritmo

cardíaco ou eletrocardiograma (ECG) de pacientes que necessitem de um

acompanhamento contínuo sejam transmitidos para um servidor central, através de

uma rede de sensores sem fios, implementada através do protocolo

ZigBee/IEEE802.15.4. Esta unidade central tem como função a gestão, armazenamento

e disponibilização dos dados referentes quer aos valores dos sinais medidos, quer a

informações acerca dos pacientes, dos utilizadores do sistema ou dos sensores. Todas

as informações do sistema podem depois ser acedidas através de dispositivos com

ligação à internet, computadores ou PDAs/smartphones. A arquitetura do sistema de

monitorização é apresentada na Figura 1.1.

Figura 1.1 - Estrutura do projeto MOHLL.

O projeto MOHLL está dividido em várias partes, estando o desenvolvimento de

cada uma delas a cargo de um diferente elemento da equipa de investigadores que



constitui o grupo de trabalho. A descrição de cada uma dessas fases é feita de forma

mais detalhada no CAPÍTULO 3 da presente dissertação.

1.2. Objetivos

O intuito deste trabalho é fazer a integração no projeto MOHLL dos sistemas de

monitorização e gestão de dados recorrendo a dispositivos móveis. Na Figura 1.2 são

destacados os blocos correspondentes a esses sistemas dentro da arquitetura geral do

projeto.

Figura 1.2 - Esquema de integração no projeto MOHLL.

O dispositivo móvel deverá possibilitar, por intermédio de uma ligação à rede

local sem fios do hospital ou através da Internet, que os profissionais de saúde tenham

acesso a:

Visualização, em tempo real, de sinais vitais de pacientes, com a

apresentação do sinal ECG a ser feita de forma gráfica;

Representação da evolução de sinais ao longo do tempo (históricos);

Apresentação de sinais visuais de alarme para valores fora dos limites

pretendidos;

Representação do nível da bateria correspondente a cada sensor;



Gestão da informação dos pacientes: listar, inserir, editar e eliminar;

Gestão da informação referente aos sensores: listar, inserir e eliminar;

Configuração dos parâmetros de atividade fisiológica normal de cada

paciente;

Gestão da associação de sensores a pacientes;

O sistema deve incluir ainda um mecanismo de autenticação dos utilizadores dos

dispositivos portáteis que efetue o controlo do acesso aos registos dos pacientes com

base nas respetivas permissões.

Falhas que surjam nas mais variadas ligações estabelecidas durante todo o

processo, que vai desde a aquisição até à amostragem, devem ser eficientemente

geridas, no sentido de conferir maior robustez ao sistema de monitorização remota.

Este fator permite aumentar a segurança nos acessos ao servidor e a fiabilidade da

comunicação e transmissão de dados, sendo este mais um dos aspetos a ter em conta

na fase de implementação do projeto.

1.3. Organização da Dissertação

Neste primeiro capítulo, é feita a abordagem ao tema central da dissertação

explicando as motivações e fazendo a contextualização do trabalho, bem como

definindo os seus objetivos.

A restante documentação da tese está dividida em cinco capítulos. No CAPÍTULO

2 é feito o estudo de alguns projetos relacionados com o tema, onde são analisadas as

diferentes arquiteturas relativas aos sistemas móveis de monitorização médica.

No CAPÍTULO 3 são descritos pormenorizadamente vários aspetos de trabalhos

prévios do projeto MOHLL, no qual se insere o trabalho apresentado nesta dissertação,

nomeadamente em termos de recolha, gestão e análise de sinais vitais.

No CAPÍTULO 4 é apresentado todo o trabalho de desenvolvimento do sistema

de monitorização móvel desta dissertação, bem como o processo de integração deste

sistema no projeto MOHLL. São ainda apresentados nesse capítulo os conceitos

teóricos e as tecnologias utilizadas durante todo o trabalho.

No CAPÍTULO 5 são apresentados os resultados finais da aplicação desenvolvida,



bem como a avaliação à qual esta foi submetida pelos seus presumíveis utilizadores.

Por último, no CAPÍTULO 6, são tiradas algumas conclusões acerca do trabalho

efetuado, bem como são deixadas algumas sugestões de desenvolvimentos futuros.


CAPÍTULO 2

Estado da Arte

2.1. Introdução

A implementação de sistemas de monitorização e análise de sinais vitais usando

dispositivos móveis tem sido objeto de bastantes projetos de investigação,

desenvolvidos com o propósito de estudar as diferentes abordagens possíveis do

tema, bem como demonstrar as vantagens da implementação dos referidos sistemas.

Várias são também as empresas que reconheceram que esta área possui um elevado

potencial para exploração comercial, tendo desenvolvido vários produtos nesse

sentido.

O crescente número de soluções apresentadas vem confirmar que o auxílio da

tecnologia nos cuidados de saúde, nomeadamente nos sistemas de monitorização,

será um fator de grande desenvolvimento na área, sendo esta uma solução de grande

potencial e ainda pouco desenvolvida, tendo em conta os meios tecnológicos

existentes e o número de aplicações em que estes podem ser utilizados.

Neste capítulo, são apresentadas diferentes abordagens quanto à estrutura e

tipologia de monitorização já implementada, dentro da área de monitorização remota

de pacientes. Entre os muitos projetos e produtos que poderiam ser reportados, foram

escolhidos alguns dos que apresentam características semelhantes às do projeto

descrito nesta dissertação, pelo menos no que toca à utilização de um tipo de

dispositivo móvel de gestão e/ou visualização de dados. Também o tipo de dados

monitorizados nestes sistemas foi um aspeto a ter em conta na escolha destes, pois a

maioria tem como principal foco de atenção o controlo do estado cardiovascular de

indivíduos, isto é, do seu ECG. Embora muitos tipos de sinais possam ser

monitorizados, o sinal de ECG é o que apresenta uma maior complexidade, quer

quanto à sua correta deteção, transmissão e visualização gráfica, quer quanto aos

recursos utilizados nestas atividades.

Capítulo 2 – Estado da Arte


2.2. Classificação de Sistemas de Recolha e Transmissão de Sinais Cardíacos via PDA/Smartphones

Dentro da área da monitorização cardiovascular, as primeiras soluções

propostas, como por exemplo os monitores Holter, permitem gravar os sinais de um

paciente durante um determinado período de tempo, sendo depois entregues a um

especialista para este avaliar a condição cardíaca do indivíduo. Este tipo de sistemas

tem, no entanto, a desvantagem de apenas gravar informação, não tendo nenhum

meio de comunicação que possibilite o envio dessa informação ou o acionamento de

algum meio de alerta quando, surgem problemas cardiovasculares urgentes. Várias

soluções foram estudadas no sentido de corrigir este problema, e em [RoGoIl05] foi

feita uma classificação de algumas destas soluções, dividindo-as em dois grupos.

O primeiro grupo recorre ao uso de um equipamento móvel em conjunto com

sensores para detetar e transmitir, através de redes sem fios, os sinais vitais do

paciente para um centro hospitalar onde estes são analisados. Algumas destas

soluções possuem também a possibilidade de gravar e representar os dados no

próprio dispositivo móvel.

Os sistemas que recorrem ao envio contínuo dos sinais adquiridos pelos

sensores, embora permitam sua análise em tempo real, revelam pouca eficiência, isto

porque a constante necessidade de enviar informação, mesmo que esta não tenha

especial importância, desperdiça recursos energéticos para efetuar essas

comunicações e recursos económicos, especialmente se forem usados os serviços das

redes móveis GPRS/GSM/UMTS.

No segundo grupo, são considerados os sistemas em que o próprio dispositivo

móvel utilizado, para além de um meio de captar e transmitir dados, funciona também

como plataforma de processamento de dados, entre os sensores e os centros

hospitalares. O seu objetivo é permitir que se faça uma análise dos dados recolhidos

de modo a que, autonomamente, sejam detetadas anomalias e enviados alertas para o

pessoal médico indicado.

Nas próximas secções, são apresentados exemplos destes dois tipos de

arquitetura, bem como soluções que não se enquadram em nenhuma destes grupos,

mas que recorrem também a dispositivos móveis para criação de um sistema de



monitorização médica.

2.3. Sistemas sem Análise Intermédia de Dados

As soluções apresentadas nesta secção enquadram-se no primeiro dos grupos

descrito anteriormente, em que a análise é efetuada após a transmissão dos dados

recolhidos. Dentro deste grupo, e para além dos projetos expostos a seguir, podem ser

indicadas algumas empresas que apostam neste tipo de soluções, como é o caso da

Alive Technology [Al10], da Vitaphone [Vit10], da ActiveECG [Ac10] ou da Philips com o

seu sistema IntelliVue [Phil10].

2.3.1. Secure Mobile Computing

O projeto Secure Mobile Computing foi desenvolvido, na Universidade da

Virginia, com o objetivo de utilizar o ritmo cardíaco adquirido pelo sistema

implementado tanto para ser monitorizado pelo dispositivo móvel (PDA) [JurWe08]

como para servir de sistema de segurança do mesmo [SecMob09]. Este último aspeto

surgiu como a vertente principal do projeto, e consiste em criar uma ligação entre o

dispositivo móvel e o seu utilizador, através da permanente monitorização do seu

ritmo cardíaco, com o objetivo de acrescentar mais um nível de segurança na

preservação de informações confidenciais contidas em dispositivos móveis sujeitos a

serem perdidos ou roubados. Consoante as escolhas do utilizador, quando o sinal deixa

de ser recebido ou quando são detetadas condições anormais no sinal, o PDA bloqueia

e requer uma nova autenticação ou simplesmente elimina os dados restritos.

Um sistema de monitorização remota de sinais vitais foi desenvolvido como

complemento do projeto Secure Mobile Computing e utiliza as mesmas bases deste. O

utilizador/paciente traz consigo um dispositivo em forma de banda adesiva constituído

por um sensor biométrico, um microcontrolador e um rádio Bluetooth. O sensor foi

desenvolvido para detetar o sinal de ECG e a partir deste extrair a frequência cardíaca.

O sinal de ECG é enviado para o PDA através do protocolo de comunicação sem fios

Bluetooth, e caso assim se pretenda, é representado em tempo real, como é mostrado

na Figura 2.1. Estes dados são depois transmitidos, através dos serviços Web do PDA,



para um servidor onde poderão ser vistos pelos utilizadores autorizados, por exemplo

um médico que, com esta informação, terá assim mais meios para avaliar a condição

do seu paciente.

O sistema operativo do PDA utilizado no projeto é o Windows Mobile, e recorre-

se à programação C# no desenvolvimento da aplicação de monitorização e transmissão

de sinais [Jur09], sendo estas, características idênticas às do projeto desenvolvido e

apresentado nesta dissertação.

Este projeto apresenta, no entanto, alguns problemas em termos de energia e

performance, pois, quando o sistema se encontra em funcionamento, a utilização do

CPU do dispositivo, quer para processamento gráfico quer para comunicação, requer

um elevado consumo de energia, o que limita bastante a utilização do sistema em

modo contínuo.

Figura 2.1 - Representação do sinal de ECG recebido [JurWe08].

2.3.2. Mobile Telemedicine System for Home Care and Patient Monitoring

M. V. M. Figueiredo e J. S. Dias [FigDi04] desenvolveram um sistema de

monitorização idealizado para acompanhamento médico de pacientes, a partir de suas

casas. Este projeto tem como propósito tentar reduzir o número de pacientes e o



tempo de internamento destes em hospitais e centros médicos, assim como tentar

suprimir a necessidade de visitas regulares ao domicílio por parte do pessoal médico

que acompanha pacientes acamados em casa. Assim, é apresentada uma alternativa

no ramo da telemedicina, que usa as várias tecnologias de comunicação associadas aos

telemóveis e PDAs como meio de inovação.

Tal como nos serviços tradicionais de telemedicina, é usada uma arquitetura

cliente servidor, representada na Figura 2.2, em que o paciente é responsável pela

recolha dos dados dos equipamentos e pelo seu posterior envio, via internet. O

servidor, normalmente situado no hospital, recebe os dados e disponibiliza-os ao

pessoal médico responsável pelo paciente, podendo assim avaliar a condição deste.

Figura 2.2 - Estrutura do sistema proposto (adaptada de [FigDi04]).

O monitor que se encontra ligado ao paciente recolhe os seus dados vitais,

nomeadamente o ECG, ritmo cardíaco, pressão do sangue, SPO2 (saturação de

oxigénio no sangue) e temperatura. Posteriormente, estes dados são transferidos para

o telemóvel, que se encarrega de os agrupar em pacotes e os enviar para o servidor do

centro hospitalar, utilizando os protocolos TCP/IP e/ou UDP. No servidor, os dados

recebidos são armazenados numa base de dados, onde podem ser consultados por

médicos e enfermeiros, através de uma aplicação existente no PC servidor.

Dependendo do tipo de monitor utilizado, os drivers desenvolvidos para o

telemóvel diferem, havendo necessidade de desenvolver software específico para cada

tipo de equipamento, o que se pode tornar problemático, atendendo ao número de

equipamentos disponíveis atualmente. Neste projeto, foram implementados drivers

para comunicar com o monitor Agilent A3, através da porta série RS232. A aplicação

desenvolvida para o telemóvel foi feita usando o Java MIDP (Mobile Information

Device Profile). Do lado do servidor também se recorreu à tecnologia java para



implementar o sistema de gestão e visualização de dados, existindo a possibilidade de

estes serem exportados para ficheiros XML ou serem de impressos.

2.3.3. A PDA-based Portable Wireless ECG Monitor for Medical Personal Area Networks

Na Universidade de Málaga foi desenvolvido um outro projeto de monitorização

de sinais de ECG à distância [CaGoAl06]. O PDA é mais uma vez escolhido como

dispositivo de receção, visualização e transmissão de dados, existindo vários cenários

para o enquadramento deste nas estruturas de monitorização apresentadas. A

arquitetura do sistema foi idealizada de modo a permitir que a interação entre os

vários componentes do sistema seja bastante versátil, recorrendo a tecnologias

wireless como Bluetooth, Wi-Fi ou UMTS para transmissão dos sinais vitais de um ou

vários pacientes.

No âmbito deste projeto, todas as aplicações foram desenvolvidas recorrendo

apenas a software open source, evitando assim questões de licenciamento de

software, bem como restrições a hardwares específicos. Neste caso, o sistema

operativo Linux foi o usado quer nos PDAs quer nos computadores servidores ou

visualizadores.

Figura 2.3 - Esquemas de monitorização permitidos pelo sistema [CaGoAl06].

Os vários cenários propostos para monitorização do ECG, apresentados na Figura

2.3, vão desde o esquema mais simples, em que existe um monitor portátil, PDA, que

acompanha o paciente para que este possa visualizar e gravar o seu eletrocardiograma



(A), até à estrutura de monitorização de vários pacientes em simultâneo e a partir de

qualquer localização, com a possibilidade de qualquer computador com ligação à

internet poder aceder aos dados transmitidos para o servidor do sistema (D). Os

cenários intermédios, em termos de complexidade, correspondem: um à ligação de

dois PDAs, através de uma rede de curto alcance, em que um se encarrega de

transmitir os dados recolhidos e outro, ao cargo de um elemento do pessoal médico,

tem a função de receber e apresentar esses mesmos dados (B); o outro cenário (C)

corresponde à monitorização de vários pacientes, a partir de um só computador,

aplicável em sistemas de monitorização remota, centralizada, de vários casos críticos

em simultâneo.

O sistema de recolha de dados consiste em conectar ao PDA uma placa PCMCIA,

com 4 entradas analógicas, o que permite aquisição de sinal de ECG recorrendo ao

esquema de 3 derivações. Posteriormente, estes valores analógicos recolhidos são

processados e tratados pelo PDA, ficando disponíveis para serem representados ou

transmitidos através de uma das tecnologias de comunicação disponíveis. Estão no

entanto a ser estudadas alternativas a este sistema de recolha de dados, como por

exemplo a substituição da placa PCMCIA por um microcontrolador de baixo consumo,

comunicando com o PDA através de uma ligação série ou de um sistema de

transmissão Bluetooth.

2.4. Sistemas com Análise Intermédia de Dados

Vários são os projetos de investigação e produtos de empresas que se

enquadram no segundo grupo descrito na secção 2.2 deste capítulo. Dentro dos

projetos de investigação podem ser referenciados o sistema UbiMon [Ubi10], do

Imperial College of London ou o sistema MOLEC [RoDraGo04], desenvolvido na

Universidade do País Basco. Quanto a soluções comerciais que se enquadram neste

segundo grupo, podem ser destacados alguns equipamentos da empresa Cardio Net

[Car10]. De seguida, são apresentados mais pormenorizadamente alguns exemplos

deste tipo de sistema, que recorre aos dispositivos móveis para criara um processo de

processamento dos dados antes de dar feedback aos prestadores de cuidados de

saúde.



2.4.1. Wearable ECG-recording System for Continuous Arrhythmia Monitoring in a Wireless Tele-Home-Care Situation

R. Fensil et al. [FeGu05] apresentam mais um sistema que permite transmitir

sinais de ECG para uma estação de diagnóstico no hospital, podendo ainda detetar,

autonomamente, a ocorrência de arritmias cardíacas. Este projeto foi idealizado para

permitir que pacientes com um historial ou com tendência a ter problemas

cardiovasculares possam ser monitorizados durante todas as suas atividades diárias.

O sensor utilizado para adquirir o sinal de ECG utiliza apenas 2 elétrodos ligados

ao circuito eletrónico que trata o sinal e o envia, usando um transmissor RF (CC1050 da

Texas Instruments), para um recetor que está interligado com um PDA, criando assim

um Hand Held Device (HHD), como mostra a Figura 2.4. O HDD é usado como unidade

de processamento para análise e gravação temporária do sinal, e utiliza o serviço GPRS

(General Packet Radio Service) para enviar os sinais de alarme e os registos do

eletrocardiograma para o servidor do sistema. Os médicos acedem então a estes

dados, através de um computador com ligação à internet, desde que este possua

também o software de representação de dados desenvolvido.

Figura 2.4 - À esquerda, o sensor e o HDD. À direita, as diferentes partes do HDD [FeGu05].

O sistema de alarme é ativado quando o HDD deteta alguma atividade anormal

no ECG, guardando então o sinal durante um minuto e transmitindo depois essas

informações. Os dados referentes aos cálculos do ritmo cardíaco assim como outros

dados sobre a atividade cardíaca dos pacientes são regularmente enviados para a base

de dados, que pode ser consultada pelos médicos para irem avaliando o estado dos

seus pacientes.

O PDA tem como sistema operativo o Microsoft Windows Mobile, sendo o C# a

linguagem usada para desenvolver os programas de análise, representação e



transmissão de dados via internet.

O HHD criado tem a vantagem de o sistema de comunicação com o sensor ser

alimentado externamente, permitindo assim uma monitorização contínua por vários

dias. Devido ao tamanho do PDA, recetor RF e respetiva alimentação, a dimensão total

do sistema móvel pode tornar-se um inconveniente, visto este equipamento ter de

estar sempre próximo do paciente.

2.4.2. EPI- MEDICS

O projeto europeu EPI-MEDICS (Enhanced Personal, Intelligent and Mobile

system for Early Detection & Interpretation of Cardiological Syndromes) [RuFaNo05]

[GoSiFa02] surgiu com o propósito de criar um sistema de monitorização inteligente

para deteção de problemas cardiovasculares. A solução apresentada permite recolher,

gravar e analisar o sinal de ECG, sendo capaz de detetar situações anómalas e

consequentemente enviar diferentes tipos de alerta para os profissionais de saúde

indicados.

A base principal do projeto desenvolvido é um monitor pessoal de ECG (PEM –

Personal ECG Monitor), que permite avaliar localmente, e o mais depressa possível, a

condição cardíaca de pacientes, nomeadamente detetando arritmias ou isquemias. A

deteção do sinal de ECG é feita recorrendo apenas a 3 derivações de referência, um

subsistema do tradicional meio que recorre 12 derivações. Após a recolha do sinal,

este é associado ao EHR (Electronic Health Record), que se encontra num cartão de

memória inserido no dispositivo PEM. Através de uma rede neuronal artificial que

processa o sinal adquirido, são usadas técnicas de tomada de decisões para gerar

diferentes tipos de alarme, tendo em conta o sinal e o historial cardíaco do paciente

gravado no EHR. As mensagens de alerta contendo os sinais gravados são enviadas,

tendo em conta a análise feita na etapa anterior, para o sistema de saúde mais

apropriado (ex: urgências hospitalares; médicos especialistas).

Os protocolos de comunicação usados no envio de dados entre os vários

elementos do sistema são: o protocolo Bluetooth, para comunicação entre o PEM e

um telemóvel ou PDA; o GSM/GPRS, para o envio dos sinais para a base de dados do

servidor do serviço PEM ou para outros dispositivos móveis; e a internet, para permitir



o acesso aos dados contidos no servidor, por parte de outros computadores, através

do site criado em HTML. A Figura 2.5 pretende esquematizar os conceitos básicos do

projeto EPI-MEDICS, as situações onde pode ser utilizado e os diferentes recetores de

alarmes consoante a gravidade destes.

Em situações de pouca urgência, o alarme é apenas destinado ao próprio

paciente, sendo mostrada uma mensagem no dispositivo PEM; num cenário de

gravidade intermédia, os dados de ECG são enviados para o servidor do sistema, e

este, para além de enviar uma mensagem a um médico cardiologista, também

disponibiliza esses dados na internet para que estes possam ser consultados; em

situações de elevada urgência, o sistema alerta um centro de urgências hospitalar para

que envie uma ambulância em socorro desse paciente.

Figura 2.5 - Arquitetura simplificada do sistema EPI-MEDICS [RuFaNo05].

Este sistema permite um acompanhamento personalizado, remoto e em tempo

real de pacientes, só envolvendo pessoal médico caso seja necessário, permitindo

assim uma redução de custos em relação a outros sistemas. O projeto prevê, no

entanto, que o PEM apenas seja utilizado em determinados períodos de tempo:

periodicamente, em função das instruções de um cardiologista, ou sempre que o

paciente se sentir mal. Esta opção tem como objetivo conseguir gerir o consumo

energético dos dispositivos móveis utilizados. Devido a este tipo de monitorização não

contínua, esta solução perde alguma eficácia em relação aos sistemas de

acompanhamento continuado.



2.5. Outros Sistemas

2.5.1. A Web Base System for ECG Data Transferred using ZigBee/IEEE Technology

O sistema de monitorização remota implementado por [KhWaNa08] tem como

objetivo permitir o acompanhamento de pacientes que se encontram internados nas

mais diversas plataformas hospitalares. Pode funcionar como complemento aos

tradicionais meios de visualização de sinais vitais, permitindo que estes sejam também

avaliados remotamente, dentro ou fora do hospital. A arquitetura do sistema é

apresentada na Figura 2.6.

A base de funcionamento do projeto consiste em atribuir a cada paciente um

dispositivo transmissor de sinais de ECG, constituído por um sensor e um módulo

ZigBee, que permite criar uma rede wireless para envio dos dados recolhidos. O

processo de receção de sinais é feito através de uma rede de equipamentos,

distribuídos pelo hospital, que fazem a deteção dos dispositivos transmissores

pessoais, onde os dados são tratados e posteriormente enviados para a rede

responsável por os encaminhar até ao servidor Web do hospital. Este servidor é o

responsável por: receber e armazenar os dados de cada paciente na base de dados do

sistema; analisar os sinais de ECG recolhidos; enviar mensagens de alerta sempre que

forem detetadas anomalias cardíacas em algum paciente; disponibilizar a informação

sobre o estado dos pacientes na internet.

Figura 2.6 - Estrutura do sistema criado [KhWaNa08].

O subsistema de análise e notificação permite detetar irregularidades quer no



ritmo cardíaco quer nas ondas e intervalos do sinal de ECG captado. Caso surja alguma

situação que necessite da atenção médica, é enviada uma mensagem SMS através de

um telemóvel ligado ao servidor, recorrendo ao sistema GSM.

As páginas Web criadas, em PHP, para monitorização de dados e gestão do

sistema, foram alocadas no computador servidor recorrendo ao software Apache. Os

médicos podem então visualizar os dados de ECG recolhidos, a partir de um browser

de um qualquer PC. Através de um PDA, com o software desenvolvido para a

plataforma Windows Mobile 5.0 em C#, os médicos podem também ter acesso aos

dados dos pacientes, desde que o mesmo esteja ligado à internet. A comunicação

entre os PDAs e o servidor é feita através de sockets TCP/IP. A representação dos

dados e do ambiente do software criado para o PDA podem ser vistos na Figura 2.7.

Figura 2.7 - Software desenvolvido para o PDA [KhWaNa08].

Este projeto apresenta uma estrutura bastante semelhante ao projeto de

investigação onde se insere o trabalho desenvolvido e apresentado nesta dissertação.

A comunicação ZigBee entre os sensores e a rede recetora de dados; a posterior

comunicação com um servidor; gestão de dados gravados numa base de dados

implementada através do software MySQL; as páginas de Web que podem ser

acedidas através de qualquer computador com ligação à internet; e a visualização e

gestão de dados através de um software desenvolvido para a plataforma Windows

Mobile, são características partilhadas pelos dois projetos mencionados.



2.5.2. Code Blue

O projeto Code Blue: A Wireless Sensor Network for Medical Care and Disaster

Response [MaFuWe04] [We05], desenvolvido na Universidade de Harvard, apresenta

uma estrutura de funcionamento destinada a situações de emergência médica em

resposta a desastres e acidentes com elevado número de feridos, servindo-se da

integração de uma rede de sensores de sinais vitais, sem fios e de baixo consumo, com

PDAs e outros sistemas computacionais. O sistema pretende ajudar as equipas de

emergência no local a avaliar pacientes, distribuir informação em tempo real pelo

pessoal apropriado e permitir uma gestão eficiente dos recursos hospitalares quanto à

orientação de pacientes.

Os vários sensores criados para implementação neste projeto destinam-se a

recolher informação dos sinais de ECG, pressão arterial, ritmo cardíaco, nível de

oxigénio no sangue, EMG, posição e movimento dos indivíduos monitorizados. Estes

sensores funcionam também como nós de uma rede wireless ad hoc, que permite a

localização, endereçamento, autenticação, segurança, assim como tratamento e

distribuição dos sinais vitais, de uma forma descentralizada, por todos os elementos

dessa rede, como podemos ver na Figura 2.8.

Figura 2.8 - Rede wireless criada por sensores e dispositivos móveis [We05].

O projeto Code Blue prevê a ligação dos mais variados sistemas computacionais,



móveis e fixos, no esquema de encaminhamento de informação, requerendo no

entanto que estes possuam um sistema de comunicação wireless baseado no

protocolo 802.11. Na fase de implementação do projeto, recorreu-se no entanto ao

.Net Compact Framework, a correr num PDA iPAQ, com sistema operativo Windows

CE, para desenvolvimento da aplicação de triagem de pacientes.

A estrutura deste sistema pode no entanto sofrer alterações, de modo a permitir

a aplicação deste noutro tipo de aplicações médicas, como na monitorização contínua

de pacientes em ambulatório ou em situações de acompanhamento remoto de

pacientes com doenças crónicos ou idosos acamados em casa.


CAPÍTULO 3

Projeto MOHLL

3.1. Introdução

A presente dissertação, sobre a monitorização de sinais vitais com recurso a

dispositivos móveis, foi desenvolvida como parte de um projeto em que se pretende

criar um sistema de acompanhamento eletrónico permanente de pacientes a partir de

diferentes locais. Este sistema de monitorização está inserido num programa que

prevê a sua utilização no piso de internamentos do Hospital Privado de Guimarães,

permitindo ao pessoal médico seguir o estado clínico dos pacientes através de um

computador ou PDA. Neste capítulo, é apresentado o trabalho do grupo de

investigadores que desenvolveram ou estão a desenvolver os equipamentos ou

estruturas, hardware e software, inerentes à implementação do projeto.

Mais especificamente, o sistema pretende utilizar vários sensores independentes

para adquirir os sinais de temperatura corporal, oximetria, eletrocardiograma e ritmo

cardíaco, estes dois últimos utilizando um só sensor. A capacidade dos elementos

sensores se auto-organizarem em rede é utilizada para transmitir todos os dados para

um coordenador central, sendo essa rede implementada a partir dos protocolos

ZigBee/IEEE 802.15.4. Do coordenador de rede, os dados são depois encaminhados,

através de um gateway ZigBee – Wi-Fi, para um servidor central onde são

armazenados por longos períodos de tempo. A arquitetura do sistema pode ser vista

na Figura 3.1. A partir do computador central, os dados são disponibilizados para

visualização em tempo real via Internet, ou através da rede Wi-Fi ou Ethernet, quando

dentro do hospital. A possibilidade de se poderem monitorizar vários pacientes em

simultâneo permite que no hospital possa haver uma estação de monitorização geral.

A capacidade de consultar o histórico clínico de pacientes ou a ativação de alarmes,

sempre que os sinais vitais saem fora dos limites estabelecidos, são outras das

características do sistema.

Devido à utilização de ligações sem fios entre equipamentos, esta abordagem

permite que qualquer cama do hospital se torne adequada para o cuidado intensivo de

Capítulo 3 – Projeto MOHLL


pacientes não críticos que necessitem de ter os seus sinais vitais constantemente

supervisionados, possibilitando ainda que estes se possam movimentar livremente,

desde que existam dispositivos de receção de dados, routers ou coordenadores ZigBee,

distribuídos pelas várias zonas destinadas aos pacientes.

Figura 3.1 - Arquitetura geral do sistema [FeAfCoSi10].

Elementos como sensores, equipamentos de transmissão de dados e aplicações

de armazenamento e visualização, foram desenvolvidos especificamente para este

projeto, com o intuito de facilitar a respetiva interligação, o que acaba por se traduzir

numa otimização do comportamento global do sistema.

Nas próximas secções, são descritos cada um desses elementos, bem como o

modo como se integram no projeto.

3.2. Sensores

Na fase de planeamento do projeto, definiu-se que os dispositivos para aquisição

de sinais vitais a desenvolver seriam os sensores de ritmo cardíaco, oximetria,

temperatura corporal e eletrocardiograma. Neste momento, já existem protótipos

para adquirir os valores de ECG, ritmo cardíaco e temperatura, enquanto o sensor de

oximetria se encontra em desenvolvimento.

Proporcionar maior liberdade e mobilidade aos pacientes que utilizam os

sensores foi uma das preocupações, durante a fase de idealização do projeto,

pretendendo-se, por isso, construir equipamentos portáteis de pequenas dimensões,



discretos e confortáveis, ou seja, o menos invasivos possível e sem quaisquer ligações

por fios com outros equipamentos.

Todos os sensores foram projetados para serem equipamentos energeticamente

eficientes, construídos de forma ergonómica de modo a reduzir os custos dos

internamentos. Devem, simultaneamente, poder ser adaptados a diversos cenários

para além da utilização em plataformas hospitalares, tais como nas casas dos pacientes

ou até nas ruas e em movimento permanente. A facilidade de manuseamento dos

equipamentos foi, por isso, uma das características a ter em conta, visto o variado tipo

de pessoas que os poderiam operar.

Cada um dos dispositivos sensoriais é constituído por vários módulos interligados

entre si:

Módulo de aquisição de sinal. Um transdutor que converte um estímulo

físico num sinal elétrico.

Módulo de acondicionamento do sinal. Circuitos de amplificação e

filtragem do sinal elétrico proveniente do módulo anterior.

Módulo de comunicação wireless. Responsável pela conversão analógico-

digital e pelo envio dos dados. Todos os dispositivos recorrem ao módulo

de comunicação ZigBee JN5139-M00 da Jennic para a transmissão de

dados [FeAfCoSi10].

Módulo de alimentação. Integra uma bateria destinada a fornecer

energia a todos os outros módulos. As baterias usadas são escolhidas de

acordo com vários fatores, o que leva a que estas possam ser diferentes

consoante as características dos sensores onde são utilizadas.

A título de exemplo desta organização, é apresentado, na Figura 3.2, o esquema

de hardware desenvolvido para o sensor de ECG, onde se discriminam os quatro

módulos supracitados.



Figura 3.2 - Esquemático do sensor de ECG: (a) módulo de aquisição, (b) módulo de acondicionamento, (c) módulo de alimentação e (d) módulo de comunicação [Ma09].

Esta arquitetura permite atribuir ao sistema de sensores uma elevada

independência relativamente a outros equipamentos.

De seguida são apresentadas características mais específicas dos sensores que se

encontram já desenvolvidos e têm um protótipo final implementado (ECG/ritmo

cardíaco e temperatura corporal).

3.2.1. Eletrocardiograma

O princípio de funcionamento deste sensor consiste em captar e amplificar as

variações de potencial elétrico geradas pela atividade do músculo cardíaco.

Foram testadas várias configurações para este sensor, antes de se chegar à

versão final. Existiram evoluções nos sistemas de amplificação e filtragem usados, nas

baterias escolhidas, de modo a otimizar a relação autonomia tamanho, e no sistema de

aquisição de dados, onde houve uma eliminação dos cabos de ligação aos elétrodos.

Os três elétrodos são inseridos na própria estrutura do sensor e ligados diretamente à

placa de circuito impresso, tal como o sistema de alimentação. Dos elétrodos, dois são

usados como pontos de aquisição do potencial elétrico do coração, enquanto um

terceiro serve como referência para o cálculo da diferença entre eles. No entanto, os

elétrodos têm de estar corretamente distribuídos e orientados no peito do paciente de

modo a atingir-se o funcionamento pretendido. A resposta a esta especificidade foi

dada através de uma indicação na estrutura de encapsulamento do sensor, que



consistiu em desenhar na caixa a forma de um coração, com o objetivo de indicar a

orientação correta para colocação do dispositivo no peito dos pacientes. O sensor e a

caixa envolvente são apresentados na Figura 3.3.

Para tratamento do sinal (diferença de potencial medida) são executadas várias

fases de amplificação e filtragem. O amplificador de instrumentação da Texas

Instruments (INA118) foi usado como amplificador inicial e redutor de ruído do sinal,

seguindo-se depois os filtros analógicos responsáveis pela eliminação das frequências

fora da gama 0.5 Hz – 40 Hz. Foi usado também um filtro notch para reduzir o ruído da

rede elétrica (50 Hz), assim como um amplificador não-inversor, responsável por

ajustar o ganho final do circuito. O circuito de acondicionamento desenvolvido pode

ser observado na Figura 3.2, bloco (b).

Figura 3.3 - Sensor de ECG e encapsulamento. (1) led indicador de atividade; (2) pilha; (3) interrutor ON/OFF; (4) módulo ZigBee; (5) representação de forma como orientação.

O sinal pós-tratamento entra no módulo de comunicação que, através do seu

ADC interno de 12 bits, converte e posteriormente envia o sinal digital a uma

frequência de 200 Hz. A cada dez minutos é também enviado o nível da bateria do

sensor, para que, durante a monitorização do paciente ao qual este se encontra

associado, se possa avaliar também o estado da bateria e impedir que esta

descarregue totalmente antes de ser substituída, prevenindo assim falhas na

monitorização.



3.2.2. Ritmo Cardíaco

O ritmo cardíaco é calculado através da forma de onda do eletrocardiograma

adquirido, tendo sido por isso dispensável o desenvolvimento de um outro sensor

apenas com este objetivo.

A medição do ritmo cardíaco foi baseada na implementação de um processo de

deteção dos picos R dos complexos QRS, a partir dos quais é possível calcular o

intervalo de tempo do ciclo cardíaco, conforme exemplificado na Figura 3.4.

No sistema de aquisição de ritmo cardíaco implementado, é enviado, a cada 10

segundos, o valor do número de batimentos cardíacos por minuto (bpm) estimado a

partir da média dos intervalos RR registados nesse intervalo de tempo.

Figura 3.4 - Representação gráfica do ciclo cardíaco com a indicação de cada uma das ondas do ECG e do intervalo entre as ondas R [TeBu10].

3.2.3. Temperatura Corporal

Um protótipo para um sensor de temperatura foi também desenvolvido de base

para o projeto de monitorização de sinais vitais MOHLL. As características estruturais

são semelhantes ao sensor de ECG/ritmo cardíaco apresentado anteriormente,

partilhando, para além disso, o mesmo tipo de módulo de comunicação. Diferem, no

entanto, quanto ao tipo de bateria usada, muito devido às diferentes exigências nas

comunicações efetuadas por cada um, visto o sensor de temperatura apenas enviar

novas medições a cada 3 minutos. Este valor pode no entanto ser alterado via

software.

A precisão do sensor varia bastante consoante a sonda (probe) utilizada na

aquisição da temperatura. A sonda usada no módulo de aquisição do sensor

desenvolvido foi escolhida por ser já empregue noutros aparelhos médicos presentes

no hospital onde está a ser implementado o projeto-piloto, sendo por isso já

conhecida do pessoal médico responsável por operar os dispositivos. Esta sonda



médica tem uma precisão de ±0.1 °C na gama de temperaturas de 34 °C a 43 °C, sendo

um valor aceitável para este tipo de aplicação.

A colocação do sensor no corpo do paciente é feita através de uma fita têxtil

colocada no seu braço, perto da axila, onde deve estar posicionada a sonda.

3.3. Rede ZigBee

O tipo rede de comunicação de dados utilizada é uma das escolhas com maior

influência no desempenho final do sistema, devendo ser tomada em função das

características pretendidas. Fatores relacionados com o consumo de energia, alcance

do sinal, largura de banda, latência de transmissão, escalabilidade, custo, fiabilidade

ou segurança, são alguns dos aspetos a considerar durante a fase de idealização do

processo de comunicação.

As necessidades do sistema impunham a construção de uma rede pessoal sem

fios de curto alcance (de 10 a 100 m), usualmente denominada por WPAN (wireless

personal area network), na qual poderiam coexistir vários tipos de equipamentos (nós

da rede). No caso específico, seriam sensores (end devices), routers ou coordenadores

de rede. Para a correta integração do sistema no ambiente hospitalar, os dispositivos

criados deveriam cumprir alguns requisitos relacionados com o tamanho, custo e

eficiência energética. Quanto à integração na rede, estes deveriam ser capazes de se

associarem e desassociarem facilmente sem interferir no funcionamento da mesma.

A partir destes pressupostos, o standard de comunicação sem fios ZigBee foi a

tecnologia escolhida para implementação da rede responsável para encaminhar os

dados sensoriais adquiridos até ao servidor do sistema, pois apresenta vantagens que

permitem preencher os vários requisitos do sistema.

Devido à variedade de topologias de rede aceites, ao grande número de nós

suportados por rede (até 65536) e ao reduzido consumo de energia, as redes ZigBee

são especialmente atrativas para dispositivos remotos alimentados por baterias, como

é o caso dos sensores de sinais vitais desenvolvidos. A estes fatores, há ainda que

acrescentar que a simples estruturação da pilha protocolar leva a uma redução do

custo final dos equipamentos [Ma09].



3.3.1. Pilha protocolar ZigBee/IEEE 802.15.4

A arquitetura da tecnologia de comunicação ZigBee encontra-se dividida por

camadas protocolares, como se pode observar na Figura 3.5, em que cada uma delas

fornece um conjunto de serviços específicos à camada superior.

O standard IEEE 802.15.4 [IE06] define a camada física (PHY) e a camada de

controlo de acesso ao meio (Media Access Control, MAC), responsáveis pelas

operações de baixo-nível, tais como receção e transmissão de dados, ativação e

desativação do transceiver, gestão de ligação aos outros dispositivos de rede, acesso

aos canais RF ou validação de tramas. Estas camadas foram criadas pelo grupo de

trabalho 802.15 do IEEE, que tem como orientação específica as comunicações em

WPANs (Wireless Personal Area Network). As normas desenvolvidas pelo standard

802.15.4 destinam-se a redes que possam necessitar de baixas taxas de transmissão de

dados (20 – 250Kb/s), mas que requeiram também um baixo custo, reduzida

complexidade e alta eficiência energética. Estas características tornam a utilização

deste protocolo especialmente indicada em sistemas de médio alcance (até 100 m),

em que a autonomia dos equipamentos seja um dos principais requisitos, como é o

caso dos sensores alimentados por baterias desenvolvidos no âmbito do projeto

MOHLL.

O protocolo ZigBee, desenvolvido pela ZigBee Alliance [Zi08], assenta sobre as

camadas especificadas pelo padrão IEEE 802.15.4, sendo aqui definidas as camadas de

rede (NWK) e de suporte à aplicação (APS – Application Support Sub-Layer). A primeira

tem como função gerir as questões relacionadas com a deteção de equipamentos de

rede, descoberta de rotas (route discovery) ou encaminhamento de mensagens,

enquanto a segunda serve como interface entre a camada de rede e a camada de

aplicação.

Por fim, na camada superior, são definidas, pelo utilizador final ou pelo produtor

do equipamento (OEM – original equipment manufacturer), as funcionalidades

pretendidas para o dispositivo, ou seja, a sua aplicação. No caso dos nós sensores

utilizados no projeto, é nesta camada que, por exemplo, se calcula o ritmo cardíaco do

paciente a partir de uma sequência de amostras de sinal de eletrocardiograma.



Figura 3.5 - Arquitetura alto-nível da comunicação baseada em sistemas ZigBee.

3.3.2. Arquitetura da Rede

Os dispositivos que constituem uma rede ZigBee podem agrupar-se de diferentes

formas (topologias). As topologias de configuração de uma rede ZigBee, Figura 3.6,

podem ser: estrela (star), árvore (tree) ou malha (mesh).

Figura 3.6 - Topologias de rede ZigBee (adaptado de [NaIn10]).

Na configuração de rede em estrela, o coordenador é o responsável por

estabelecer contacto direto com todos os outros dispositivos de rede. Isto leva a que

os end devices (sensores) tenham de estar próximos do elemento coordenador, o que

restringe a utilização deste esquema de rede a áreas reduzidas.

Seguindo uma estrutura hierarquizada, a topologia de árvore permite aumentar

a distância de funcionamento da rede. Contrariamente ao que acontecia na estrutura



de rede anterior, os dados podem ser encaminhados através de vários nós da rede, no

seu caminho entre os sensores e o coordenador. Esta configuração apresenta, no

entanto, a desvantagem de, no caso de um dos routers perder a sua ligação à rede,

todos os seus nós dependentes perderem também a sua via de comunicação com o

coordenador, ficando assim fora da rede, no caso de não existirem outros routers ao

seu alcance.

As características inerentes ao tipo de rede que o projeto MOHLL impõe levou a

que a topologia de malha (mesh) fosse a escolhida para organizar e gerir os

dispositivos do sistema. Isto porque as características desta permitem distribuir os

dispositivos por uma vasta área, como é a de um piso hospitalar, e ao mesmo tempo

ajustar automaticamente a sua organização sempre que deixe de ser detetado algum

elemento ou caso surja um novo equipamento na rede. Quando isso acontece são

criados caminhos novos para a transmissão de dados entre os end devices e o

coordenador da rede, conferindo assim alguma independência às ligações entre

dispositivos.

A arquitetura ZigBee disponibiliza até 16 canais de comunicação diferentes, o

que permite assegurar a fiabilidade do serviço de transferência de dados, através da

escolha de um canal não suscetível a interferências de outras redes sem fios. No

esquema apresentado na Figura 3.7 são estruturadas duas redes ZigBee (dois

coordenadores), configuradas através da topologia de malha, a operar em canais

diferentes. Os sensores dos pacientes monitorizados têm a possibilidade de se

associarem tanto a um dos coordenadores como a um dos routers, consoante a

qualidade da comunicação oferecida por cada um.

Figura 3.7 - Protótipos de redes ZigBee aplicadas ao projeto MOHLL, implantadas através da topologia em malha (adaptado de [FeAfCoSi10]).

Os coordenadores por sua vez estão conectados a um gateways ZigBee – Wi-Fi,

responsáveis por encaminhar os dados até ao servidor do sistema, que, na Figura 3.7,



surge representado também como a estação de monitorização.

3.3.3. Routers e Coordenadores de Rede

Para além dos elementos sensoriais apresentados na secção 3.2, também foram

desenvolvidos os equipamentos de encaminhamento (routers) e gestão de rede

(coordenador), apresentados na Figura 3.8.

Está definido pelo protocolo ZigBee que estes equipamentos devem ter os seus

módulos de comunicação sempre disponíveis para receber e enviar dados de e para os

restantes elementos da rede, o que se traduz num consumo energético dificilmente

suportável por baterias, recorrendo-se por isso a um determinado tipo de alimentação

externa. A possibilidade de os end devices terem um tipo de alimentação embutida

prende-se com o facto de os seus módulos transceptores (receção/ transmissão)

apenas serem ligados quando surge necessidade de enviar ou receber mensagens, o

que permite então optar por soluções mais práticas (baterias), sem que a autonomia

desses equipamentos seja significativamente prejudicada.

Figura 3.8 – Encapsulamento; Router/Coordenar de rede; antena.

Atendendo ao facto de estes serem os elementos fixos da rede, a sua colocação

teria de ser estudada de modo a que pudessem ser instalados convenientemente sem

que, no entanto, se destacassem dentro do ambiente onde seriam inseridos. A opção

tomada passou por embutir os routers nos “candeeiros” das luzes de emergência, que,

aliado ao facto de nessa posição haver uma fonte de alimentação permanente, os

torna também impercetíveis. A maior potência disponibilizada por uma alimentação

externa permite, desde logo, utilizar um módulo ZigBee também ele mais potente, o



que acaba por se traduzir num maior alcance. O módulo ZigBee escolhido (Jennic

JN5139-M02) tem a particularidade de utilizar uma antena externa, contrariamente

aos módulos dos sensores.

Toda a estrutura física dos routers e dos coordenadores é partilhada entre si,

sendo o seu comportamento distinguido através da aplicação instalada no

microprocessador dos equipamentos. Outra diferença surge no tipo de alimentação

externa utilizada, pois os routers são alimentados por transformadores ligados à rede

elétrica, enquanto os coordenadores de rede, visto estarem ligados ao computador

que funciona como gateway ZigBee – WiFi, são alimentados via um cabo série – USB,

por onde são também transferidos os dados relativos à comunicação entre os dois

dispositivos.

3.4. Sistema de Gestão e Visualização de Dados

O subsistema de gestão de dados do projeto foi desenvolvido com o intuito de

coordenar as atividades de recolha das informações sensoriais adquiridas pelos

sensores, armazenamento das mesmas e disponibilização para visualização de todos os

dados do sistema. Na Figura 3.9 é apresentado um esquema das ligações estabelecidas

entre as diversas aplicações responsáveis por cada uma das fases do processo de

gestão.

Aplicação de recolha de dados (ARD), para receção e encaminhamento de

dados provenientes da rede de sensores.

Aplicação de Acesso aos Dados (AAD), suporte às aplicações Web que

servem de interface com os utilizadores do sistema. Responde a todos os

pedidos feitos pelas aplicações Web através das quais os utilizadores,

recorrendo a um browser de Internet, podem gerir as informações

relacionadas com os pacientes, utilizadores, sensores e alertas, bem

como visualizar todos os sinais sensoriais.

Base de Dados, para armazenar todos os dados relevantes do sistema.

Esta estabelece uma relação direta com os outros dois serviços do

sistema e constitui o único elemento de ligação, indireta, entre eles.



Figura 3.9 - Serviços do sistema de gestão de dados e respetivas ligações.

Todas as ligações estabelecidas entre o subsistema de gestão e os outros

elementos do projeto, nomeadamente a rede de sensores e as aplicações Web de

monitorização (Java applet), são feitas através do protocolo HTTP [Pe09]. De referir

ainda que a comunicação com a rede de sensores é feita, indiretamente, através dos

gateways ligados aos coordenadores de rede. Estes foram implementados, através de

aplicações desenvolvidas em linguagem C#, para receber os pacotes de dados

provenientes da rede ZigBee e reorganizar a informação para enviar para a ARD

(Aplicação de Recolha de Dados) do servidor, via HTTP.

Para implementação dos serviços de gestão no servidor do sistema, foram

utilizadas as seguintes linguagens de programação: Java, para o desenvolvimento da

ARD e da AAD (Java servlets); HTML e JSP (Java Server Pages) para desenvolvimento

das páginas Web, sendo o JSP usado para interagir com a BD.

A configuração do computador como servidor Web foi feita recorrendo ao

software Apache Tomcat, por este ser de utilização livre e conseguir atingir bons

desempenhos ao nível da velocidade e estabilidade. Quanto ao Sistema Gestor de Base

de Dados (SGBD) foi utilizado o MySQL, que se caracteriza por ser rápido, robusto e

flexível quando existe necessidade armazenamento de grandes quantidades de dados

[Pe09].

3.4.1. Aplicação de Recolha de Dados

A constante disponibilidade que a ARD deve demonstrar para receber os dados

provenientes da rede de sensores surge com o principal requisito deste serviço, visto

ser fundamental que todos os sinais recolhidos possam ser rapidamente

encaminhados e armazenados na base de dados.



A ARD é dividida em camadas com responsabilidades diferentes, como: receber

os dados da rede de sensores (camada de apresentação); estabelecer a comunicação

com a base de dados (camada de dados); agregar os dados recebidos e estabelecer

ligação entre as duas camadas anteriores (camada de negócio). Através desta

estruturação em camadas, é possível gerir a ARD de modo a que apenas exista uma

camada responsável pela comunicação com a rede de sensores (gateway) e outra com

a base de dados, o que permite abstrair as restantes camadas dessas ligações externas.

De modo a que o elemento da rede de sensores responsável pela comunicação

com a ARD, gateway ZigBee – WiFi, possa encaminhar corretamente os dados

sensoriais recolhidos, é lhe fornecido o endereço IP da máquina onde a aplicação se

encontra instalada, permitindo assim criar uma ligação através do protocolo HTTP. As

transmissões de dados, entre o sistema de sensores e a aplicação de recolha de dados,

exigem, no entanto, uma coordenação quanto ao formato das mensagens trocadas,

tendo sido por isso desenvolvido o protocolo aplicacional que se encontra detalhado

na Tabela I. As mensagens são constituídas por quatro campos, com informações

específicas da medição a ser transmitida. Nestes, indica-se: o tipo de informação

enviada (sensorType); a referência do sensor (sensorID); a data da medição

(timestamp), em milissegundos (a contar desde 1 de Janeiro de 1970, às 01:00:00

GMT); e os dados referentes à medição efetuada (data), podendo estes variar

consoante o tipo de sensor a que se referem.

Tabela I - Especificações protocolares das medições enviadas para a ARD

Variáveis Descrição

sensorType

01 – Update Bateria 02 – ECG

03 – Oximetria 04 – Ritmo Cardíaco 05 – Temperatura

sensorID Número de identificação do sensor

timestamp Identificação temporal da medição

data

ECG – 50 amostras recolhidas durante 250 ms Oximetria – Medida em percentagem

Ritmo Cardíaco – Número de batimentos cardíacos por minuto Temperatura – Temperatura em graus Celsius

Bateria – Nível de bateria do sensor, existindo 4 níveis possíveis



3.4.2. Base de Dados

A principal exigência ao serviço de Base de Dados do sistema está relacionada

com cadência de armazenamento, sendo necessário que seja possível armazenar, no

menor espaço de tempo possível, um elevado número de dados referentes às várias

medições efetuadas. Sendo o sensor de ECG o que maior número de medições envia

por unidade de tempo (quatro envios, de 50 amostras, por segundo), pode-se verificar

que, se, por exemplo, estiverem a ser monitorizados dez pacientes, é necessário que a

BD consiga gerir 40 inserções por segundo, só para este tipo de sensores. Após a

otimização do processo de armazenamento, foi possível aferir que o número de

inserções poderia ir até cerca das quatro mil por minuto (≈67 por segundo), levando a

que o requisito imposto quanto à velocidade de inserção de dados na BD fosse

cumprido.

A organização estrutural dos dados, pode ser observada no modelo Entidade –

Relação apresentado na Figura 3.10 . As entidades definidas foram:

Pacientes. Contém informações sobre os pacientes como nome, data de

nascimento ou diagnóstico.

Alertas. Para cada paciente, são definidos os intervalos entre os quais o

sinal medido é considerado estável, para cada um dos tipos de sensores

passíveis de lhe serem associados.

PacienteSensor. São indicadas as características das associações

efetuadas entre sensores e pacientes.

Sensores. São agregadas informações como número de série ou tipo de

sensor.

Medições. Para cada uma, são identificados os números de série, o sensor

à qual está associado, a data e o valor da medição.

Utilizadores. Identificação do login e do tipo de privilégio das pessoas

com acesso ao sistema.



Figura 3.10 - Modelo Entidade - Relação da Base de Dados [Pe09].

3.4.3. Interface da Aplicação Web

Com o intuito de permitir aos utilizadores interagirem com o sistema de

monitorização, foi desenvolvida uma aplicação Web para gestão de informações e

visualização de sinais vitais de pacientes. A aplicação consiste num site de Internet que

pode ser acedido, a partir de qualquer Web browser.

As operações disponíveis no site são:

Monitorizar sinais vitais de pacientes;

Visualizar a evolução temporal de alguns desses sinais (históricos);

Listar, adicionar e eliminar sensores;

Listar, adicionar, editar e remover pacientes;

Listar, adicionar, editar e remover utilizadores;

Associar/desassociar sensores a pacientes;

Determinar os valores dos alertas para cada paciente.

Na Figura 3.11 é apresentada a estrutura do site e as atividades permitidas a



cada um dos tipos de utilizador.

Figura 3.11 - Estrutura do Website para interação com os utilizadores [Pe09].

Apenas os utilizadores registados podem aceder ao sistema, tendo sido para isso

implementado um método de autenticação, que serve também para distinguir as

classes de utilizadores, bem como os privilégios que lhes são atribuídos. Os três tipos

de utilizadores com acesso ao site são:

Visualizador, com permissão para monitorizar sinais e visualizar

históricos. Os pacientes podem ser inseridos nesta classe, para terem

acesso aos seus dados;

Gestor, com as mesmas permissões do Visualizador, mais as opções de

gestão relacionadas com os sensores, pacientes e as suas associações,

bem como com a definição de alertas;

Administrador, em tudo semelhante ao utilizador Gestor, mas ainda com

permissão para efetuar a gestão na área das autorizações de pessoal

(listar, adicionar, editar e remover utilizadores).



3.4.4. Monitorização

O processo de apresentação e representação gráfica de sinais vitais é uma das

principais vantagens do projeto de monitorização de pacientes, descrito neste

capítulo. Simultaneamente, é também a operação mais complexa disponibilizada pelo

site. A secção de monitorização do sistema permite visualizar o estado de, no máximo,

seis pacientes em simultâneo. Para cada um destes, é criado um aplicativo (java

applet) onde podem ser visualizados todos os sinais fisiológicos, adquiridos pelos

sensores que lhe estão associados.

Na área da página destinada a cada paciente, é feita a sua identificação (nome,

idade, quarto e cama), seguida da apresentação dos sinais vitais monitorizados, como

pode ser observado na Figura 3.12. A estes, são também acrescentadas algumas

funcionalidades como:

Apresentação do nível das baterias de cada sensor;

Mudança da cor dos valores, de verde para vermelho, sempre que estes

saiam fora dos intervalos de funcionamento definidos;

Ativação de um alarme sonoro quando os sinais medidos estão fora dos

valores considerados normais;

Para os sinais algébricos, apresentação de valores de forma intermitente

quando se referem a medições demasiado antigas, em representação de

mau funcionamento dos sensores ou das redes.

Figura 3.12 - Applet destinado a cada paciente.

Para implementar a área de visualização de sinais vitais, foi escolhida a

tecnologia Java applet devido ao facto de permitir a integração da linguagem java na



interface Web construída, levando a que se pudessem utilizar algumas funcionalidades

gráficas, necessárias para o desenvolvimento do processo de amostragem dos sinais.

Sendo a execução do applet feita, através do Java Virtual Machine, apenas no

computador cliente, surgiu a necessidade de recorrer ao protocolo HTTP para

estabelecer a comunicação entre o applet e o servidor, como meio de acesso aos

dados do sistema.

O método implementado para atualização em tempo real dos valores sensoriais

consiste em efetuar um pedido ao servidor, para que, sempre que novos dados forem

adicionados à Base de Dados, estes sejam transmitidos para o applet do paciente

correspondente, o qual se encarrega de efetuar a representação desses novos valores.

No caso dos valores representativos do sinal de ECG, estes são enviados em

conjuntos de 50 amostras, das quais são retirados os pontos necessários para a

representação gráfica do sinal. Estes conjuntos de amostras são alocados em

diferentes elementos de uma lista Queue, que após a representação gráfica de cada

um dos grupos de amostras agregados elimina o elemento correspondente, libertando

espaço na Queue para inserção de novos valores.

O processo de atualização dos valores numéricos relativos aos sinais de

oximetria, temperatura ou frequência cardíaca consiste em, a cada 500 milissegundos,

ler o valor contido no elemento de um Array referente ao tipo de dado que se quer

atualizar (posição 0- oximetria, 1- frequência cardíaca, 3- temperatura). Para garantir

que os dados apresentados são referentes apenas à última medição efetuada, sempre

que um novo valor é recebido, este é colocado na posição do Array correspondente,

substituindo o anterior, o que leva a que este novo valor seja o apresentado após a

atualização do layout do applet. De referir ainda que as imagens referentes ao estado

das baterias dos sensores seguem também este procedimento de atualização.

Nesta área de monitorização, os utilizadores têm ainda possibilidade de

consultar a evolução temporal dos sinais medidos, através da opção de visualização de

históricos, sendo a apresentação desses dados idêntica à que pode ser observada na

Figura 3.13.

Todas as características da plataforma de monitorização foram planeadas para

que as instâncias criadas durante a utilização do site pudessem ser executadas em

qualquer browser Web, sem que se tivesse que recorrer ao uso de softwares próprios



ou mais dificilmente acessíveis. A utilização de bibliotecas livres para implementação

dos applets é um dos exemplos das opções tomadas para que utilização deste sistema

pudesse ser tão generalizada quanto possível.

Figura 3.13 – Janela de histórico de temperatura de um paciente

No sentido de gerir os pedidos efetuados pelas instâncias de monitorização

criadas, foi desenvolvida uma Aplicação de Acesso aos Dados (AAD) dentro do Servidor

do sistema. Esta tem uma arquitetura semelhante à ARD descrita anteriormente,

igualmente dividida por camadas: Camada de Apresentação, Camada de Negócio e

Camada de Dados. Respetivamente, as suas funções visam comunicar com o applet;

fazer consultas periódicas à BD, enviar novos dados e estabelecer a ligação entre as

outras camadas; fazer a abstração à BD. Este tema voltará, no entanto, a ser abordado

com mais pormenor no ponto 4.3.2.

Esta aplicação é responsável por gerir o canal de comunicação existente entre o

servidor e o applet, que é aberto após a execução do primeiro pedido de informação,

mantendo-se assim até que a comunicação seja terminada por qualquer uma das

partes. Através do mesmo, são enviados dados sempre que exista uma atualização dos

valores referentes às medições feitas pelos sensores associados ao paciente cujo

estado se pretende monitorizar.


CAPÍTULO 4

Sistema de Monitorização e Gestão Móvel

4.1. Introdução

Como derivação do projeto apresentado no CAPÍTULO 3, foi idealizado um

sistema móvel de monitorização e gestão pessoal. Este teria como principal objetivo

permitir ao pessoal médico um permanente acompanhamento do estado dos

pacientes, quer em situações de análise de rotina, quer em casos urgentes, em que a

opinião de um médico especialista fosse importante, podendo este não se encontrar

próximo do paciente crítico. Como acréscimo, foi definido, que pessoal autorizado pelo

sistema teria meios para gerir todas as informações relacionadas com os pacientes e

respetivos equipamentos de recolha de sinais vitais, o que no caso de algumas

operações de associação se poderia tornar bastante útil, devido à mobilidade deste

sistema. Outra das suas utilizações previa a possibilidade de os próprios pacientes

terem também acesso aos seus dados fisiológicos e controlar o seu estado de saúde,

contribuindo para que estes pudessem intervir de forma mais fundamentada nos

cuidados de saúde recebidos.

Com base nestes pressupostos, e tendo em consideração todos os elementos do

projeto MOHLL implementados anteriormente, foram então definidas as orientações

para integração do sistema móvel de monitorização. As decisões tomadas impunham

que esta integração fosse efetuada de modo a aproveitar o trabalho anteriormente

desenvolvido, isto é, partindo do sistema de recolha e armazenamento de dados, criar

condições para que o suporte às aplicações dos sistemas móveis (PDAs) fosse feito em

bases semelhantes às utilizadas para o suporte aos browsers, ou seja, através de um

sistema de comunicação assente no protocolo HTTP. Esta solução pretendia conservar

a simplicidade da arquitetura do elemento servidor do projeto, excluindo a

necessidade de modificações estruturais para acolher um novo meio de ligação entre a

base de dados e os dispositivos móveis. Na Figura 4.1 pode ser observada a arquitetura

do sistema após a inclusão dos elementos de apoio às aplicações móveis de

monitorização e gestão.

Capítulo 4 – Sistema de Monitorização e Gestão Móvel


Figura 4.1 - Sistema de Monitorização e Gestão (Subsistema Móvel - a vermelho) [Adaptada de Pe09].

Este capítulo tem como propósito apresentar todo o trabalho efetuado para o

desenvolvimento das plataformas de suporte ao sistema móvel de acompanhamento

médico, abordando os vários temas pertinentes à elaboração do mesmo. Partindo da

análise dos requisitos funcionais, das tecnologias utilizadas e dos equipamentos

disponíveis, são descritos os passos relevantes da implementação e fundamentadas as

opções tomadas no sentido de atingir os objetivos propostos.

4.2. Conceitos Teóricos e Hardware

Para melhor compreender as opções tomadas durante a fase de implementação

das aplicações desenvolvidas para permitir o acompanhamento remoto de pacientes, é

necessário ter algumas noções de quais as restrições técnicas, tanto ao nível de

software como de hardware e quais os meios disponíveis para atingir esses fins.

Nesta secção, pretende-se descrever os conteúdos teóricos, os equipamentos, as

tecnologias mais relevantes e as plataformas de desenvolvimento utilizadas para a

implementação do sistema de monitorização, em tempo real, com recurso a

plataformas móveis.



4.2.1. Equipamentos Móveis

Os vários equipamentos móveis de comunicação, como PDAs e smartphones,

que têm vindo a ser disponibilizados no mercado apresentam inovações tecnológicas

que permitem aumentar consideravelmente as suas aplicabilidades, bem como

potenciar novas abordagens à utilização destes. Na sua origem, estiveram os

telemóveis e comunicações através das redes das operadoras móveis que, com os

avanços que lhes foram sendo introduzidos, se transformaram em aparelhos com

verdadeiras capacidades computacionais. Diversas características podem ser

apontadas como responsáveis por este facto, sendo que as mais importantes são:

Boa capacidade de processamento;

Elevada capacidade de armazenamento;

Comunicações sem fios: Bluetooth, Wi-Fi e/ou infravermelhos (IrDA);

Acesso à internet (Web browser, e-mail, etc.);

Sistemas operativos desenvolvidos de raiz;

GPS integrado;

Captação de imagens em alta resolução;

Reprodução de ficheiros de som e vídeo de elevada qualidade, bem

como possibilidade de leitura e edição de ficheiros do MS Office ou de

outros ficheiros multimédia;

Aumento do tamanho dos visores e ecrãs tácteis com boas resoluções.

A tendência é que estes recursos continuem a sofrer melhoramentos, ao mesmo

tempo que novas funcionalidades vão surgindo.

Paralelamente a estes aspetos, surge também a possibilidade de desenvolver

software dedicado, ou seja aplicações específicas para um determinado equipamento,

marca ou, mais recentemente, para um dado sistema operativo, tendo possibilidade

de interagir com os vários recursos disponibilizados pelo equipamento, como o GPS ou

a câmara. Em 2009, o valor gasto neste tipo de aplicações, compradas ou subscritas

pelos utilizadores, rondou os 10 mil milhões de dólares, sendo previsível que este valor

suba para cerca de 32 mil milhões de dólares em 2015 [Hol10], tornando visível a

importância deste novo tipo de mercado na proliferação destes equipamentos.

Associada ao facto de estas aplicações poderem ter objetivos que vão desde o



entretenimento à prestação de serviços, está a possibilidade de qualquer pessoa ter ao

seu alcance ferramentas que lhe permitem desenvolver as suas próprias aplicações,

fator que tem conduzido muitas empresas e utilizadores particulares a apostar neste

ramo de atividade, quer para comercialização, quer para utilização própria das

aplicações desenvolvidas. Na presente dissertação, é feito o recurso a essa capacidade

de criação de software para, tirando partido das capacidades de um dado

equipamento, conseguir executar uma determinada atividade.

O equipamento utilizado é o PDA Qtek 9090 com o sistema operativo Windows

Mobile 5.0 (após atualização) e tem as seguintes características ao nível do hardware

[Mq10][Gsm10]:

Processador Intel PXA263, 400 MHz

Memória: 32 MB ROM, 128 MB SDRAM

GSM/GPRS: GSM Quad-band 850/900/1800/

1900; GPRS, Classe 10 Multi-slot

Bluetooth versão 1.1

WLAN integrada: Wi-Fi 802.11b

Porta de Infravermelhos IrDA SIR

Porta de 22 pinos para: USB; Alimentação;

Áudio; Porta série

Expansões: slot para cartões MMC/SDIO;

conector para antena externa; Jack áudio

(2.5 Ø), slot para cartões SIM

Câmara a cores CMOS VGA, 640x480 pixéis

Teclado integrado QWERTY

Ecrã TFT-LCD 240 x 320 pixéis de 3.5

polegadas, táctil, 64K cores

Bateria Li-Ion 1400mAh, amovível

Dimensões: 71.6mm x 1125mm x18.7mm

Peso (c/ bateria) 205g

Uma das propriedades com maior relevância no âmbito deste projeto está

relacionada com as capacidades de comunicação disponibilizadas. Estas são analisadas

Figura 4.2 - Qtek 9090 [Gsm10].



de seguida.

4.2.2. Sistemas de Comunicação

Uma parte determinante na eficiência do sistema de gestão de dados está

relacionada com os meios de comunicação utilizados para transferir informação entre

os vários elementos computacionais do sistema. Em termos práticos, este facto pode

ser corroborado pela necessidade de, sempre que é efetuada qualquer ação

relativamente à monitorização ou gestão de dados do sistema, ter de se estabelecer

uma ligação ao servidor do sistema, visto aí se encontrar concentrada toda a

informação necessária.

Tendo em conta todo o trabalho previamente desenvolvido e todas as opções

tomadas até ao início desta tese, a utilização do protocolo HTTP como meio de

comunicação entre o PDA e o servidor surgiu de forma evidente. Esta opção, para além

de simplificar o sistema de comunicação, restringindo todas as transferências de

informação com o servidor a um só protocolo, permite ainda aproveitar os recursos de

abstração à base de dados (AAD) sempre que as ações a executar pelo PDA tiverem

correspondência às opções disponíveis no site. Como exemplo, pode ser apresentada a

situação em que se pretende associar um sensor a um paciente. Tanto através do site

como através do PDA esta opção estaria disponível e, pese embora mensagens

enviadas terem conteúdos diferentes, o processo de interação com a base de dados

seria igual nos dois casos.

HTTP

O HTTP (Hypertext Transfer Protocol) é um protocolo, ao nível aplicacional, usado

em sistemas de informação de hipermédia distribuídos e colaborativos, desenvolvido

para transmissão de dados e ficheiros [IETF99], sendo considerado como a base para

maioria das comunicações estabelecidas na Internet atualmente.

O protocolo HTTP é baseado numa estrutura de pedidos/resposta entre um

cliente (ex: Web browser) e um servidor. Este último, é responsável por agregar todas

as informações necessárias, bem com disponibilizar o acesso aos recursos desejados

pelo cliente, e sempre que recebe um pedido (HTTP request), responde enviando uma



mensagem com a informação desejada pelo cliente, ou simplesmente o informa sobre

do estado de execução das ações solicitadas.

Todas as mensagens obedecem a uma estrutura definida por uma linha inicial

obrigatória (request line), seguida das linhas cabeçalho onde são passadas informações

relativas à configuração da mensagem enviada e formato da resposta pretendida. No

esquema de pedidos, o princípio de ligação é feito através da localização e

identificação dos recursos desejados pelo cliente, e que são acedidos com base no

esquema de identificação URI (Uniform Resource Identifier).

A estrutura da pilha protocolar da Internet supõe a interação entre várias

camadas de protocolos distintos. No caso, para suporte às aplicações HTTP, é

requerida uma elevada fiabilidade no que toca à transferência de pacotes dados,

gerida pelo protocolo usado na camada de transporte. Assim se justifica que, na

maioria dos casos, seja o protocolo TCP o escolhido para estabelecer ligações entre

servidores e clientes, por este ser o método mais fidedigno no que toca à comunicação

de dados de forma ordenada e sem falhas, devido à gestão de erros no fluxo de bytes e

à garantia de entrega de pacotes. Sempre que se recorre ao protocolo TCP, a fase de

transmissão de dados é precedida por uma fase configuração da conexão, que é

encerrada logo que esta já não seja necessária. Até à versão HTTP/1.1, este era o

procedimento mesmo que o objetivo fosse receber uma atualização constante da

resposta para um mesmo pedido [EdC01], ou seja, para efetuar esta atualização era

necessário enviar constantemente o pedido. Esta característica tornava o streaming de

dados através deste protocolo numa tarefa bastante complexa e/ou muito limitada.

No entanto a partir da versão HTTP/1.1, foi introduzido um mecanismo de reutilização

de conexões, permitindo que fossem obtidas atualizações constantes da resposta para

um mesmo pedido. No projeto que nesta dissertação se apresenta, este recurso foi

utilizado para possibilitar o processo de monitorização em tempo real, ou seja, o

streaming de dados referentes aos sinais vitais recolhidos.

Dentro do trabalho desenvolvido, em todos os processos de comunicação,

streaming ou não, existe uma ligação entre sistemas computacionais que recorrem a

diferentes linguagens, mais especificamente Java no servidor (AAD) e C# no cliente

PDA. Portanto, foi necessário recorrer a um protocolo de mensagens que fosse

suportado por cada uma dessas linguagens. Visto que, o sistema servidor utiliza um



processo de transferência de dados com o applet que recorre ao método Post, foi

assim definido que este seria também o método utilizado nas comunicações com o

PDA.

Um método é um campo nas configurações dos pedidos HTTP que identifica a

ação que deve ser executada no objeto identificado no URL, neste caso no servidor. O

método Post tem a particularidade de, para além de permitir incluir no corpo da

mensagem informação ou parâmetros para serem processados pelo recetor, não ter

limite no que toca ao tamanho das mensagens enviadas [HW11].

Para implementar este protocolo foi usada a função doPost da classe

HttpServlet, no caso da linguagem Java, enquanto que no caso da aplicação móvel

desenvolvida em C# foram utilizadas as classes WebRequest e Webresponse

pertencentes ao namespace System.Net da .NET Framework Class Library.

4.2.3. Software

Para desenvolvimento deste projeto, foram usadas diferentes linguagens e

ambientes de desenvolvimento. As escolhas efetuadas, quanto à utilização destes,

tiveram em conta fatores relacionados com os equipamentos disponíveis e respetivos

sistemas operativos, bem como outras questões relacionadas com o anterior

desenvolvimento das aplicações do servidor. No caso da aplicação para o PDA, e visto

este recorrer ao sistema operativo Windows Mobile, no caso a versão 5.0, foi definido

que as aplicações a criar fossem desenvolvidas com base na plataforma .Net Compact

Framework. Todas estas premissas levaram a que se optasse pela ferramenta de

desenvolvimento da Microsoft, o Visual Studio 2008. Quanto às aplicações de suporte

implementadas no servidor, estas foram desenvolvidas usando o software IDE Eclipse.

Nos seguintes pontos serão apresentadas algumas informações adicionais e

detalhes acerca destas plataformas e restantes componentes de software de

linguagens usadas.

Windows Mobile

O Windows Mobile foi desenvolvido pela Microsoft, a partir do Windows CE

(Windows Embedded Compact), com o intuito de ser utilizado como sistema operativo



de dispositivos computacionais móveis, quer estes tivessem ou não propriedades

telefónicas. Assim seria possível executar tarefas semelhantes às disponibilizadas pelo

Windows para um PC comum, utilizando versões específicas das ferramentas MS

Office, Internet Explorer, Outlook ou Windows Media Player, entre outras.

Várias versões foram lançadas, tendo sido introduzidas inovações em cada uma

delas. Uma dessas inovações esteve relacionada com a disponibilização de ferramentas

de suporte a aplicações de software desenvolvidas num ambiente externo à Microsoft,

quer por programadores independentes quer por outras empresas, o .Net Compact

Framework. Neste projeto é utilizado um PDA em que o sistema operativo foi

atualizado da versão 2003 SE para a versão 5.0 do Windows Mobile, possibilitando

assim o uso de ferramentas mais recentes no desenvolvimento das aplicações

implementadas.

A utilização deste SO foi definida no início do projeto tendo em conta que para

além de se ter disponível um equipamento que o suportava, este tinha na altura uma

significativa cota no mercado dos sistemas operativos para dispositivos móveis. Este

mercado tem vindo a crescer significativamente, e não tendo o Windows Mobile

acompanhado este crescimento em volume de vendas, a sua cota de mercado

diminuiu bastante, devido em grande parte ao aparecimento de novos sistemas

operativos como o IPhone da Apple ou o Google Android. Em 2010, a Microsoft

anunciou que não iria continuar o desenvolvimento do Windows Mobile, substituindo-

o por um sistema operativo completamente novo, o Windows Phone 7.

.Net Compact FrameWork

O .Net Framework é uma ferramenta desenvolvida pela Microsoft com o objetivo

de disponibilizar um meio de suporte ao desenvolvimento e execução dos códigos das

aplicações de software. Estas podem ser implementadas recorrendo a diversas

linguagens orientadas ao objeto, o que permite a interoperabilidade entre aplicações,

mesmo que estas sejam desenvolvidas em linguagens diferentes. Uma das

componentes fundamentais desta plataforma é a sua extensa biblioteca, que, entre

outros, faculta os comandos para criação de interfaces gráficas, acesso a base de

dados ou gestão dos recursos referentes às comunicações de rede e a aplicações Web.

A outra componente fundamental está relacionada com a gestão do código das



aplicações criadas para o .Net Framework, durante a fase de execução destas. Esta

gestão é feita pelo Common Language Runtime (CLR), uma máquina virtual para

execução dos programas que, para além de permitir uma abstração ao hardware,

também tem funções como administração de memória, segurança ou gestão de

exceções [NF11].

No sentido de obter as mesmas funcionalidades de desenvolvimento e execução

de aplicações, mas para dispositivos móveis, foi desenvolvido o .Net Compact

Framework que, partindo da mesma arquitetura que a versão de base, tem

características que permitem gerir melhor os recursos disponibilizados. As limitações

de bateria e processamento dos dispositivos a que este Framework se destina levaram

a que fosse necessário reduzir o número de classes disponibilizadas e comprimir o CLR,

tendo por outro lado sido acrescentadas funções específicas para aproveitar as

características desses mesmos equipamentos bem como para permitir a integração e

interação das aplicações criadas com o restante software. Na Figura 4.3 é possível

observar a estrutura da plataforma .Net Compact Framework.

Neste Projeto foi utilizada a versão 3.5 do .Net Compact Framework, tendo sido

para isso efetuada uma atualização deste software no dispositivo utilizado, bem como

uma alteração no esquema de registos do PDA.

Figura 4.3 - Arquitetura da plataforma .Net Compact Framework [NCF11]

Visual Studio

O Visual Studio é um IDE disponibilizado pela Microsoft para servir como

http://en.wikipedia.org/wiki/Common_Language_Runtime



plataforma de desenvolvimento de software, que pode ir desde aplicações para

interfaces gráficas até vários tipos de aplicações Web, sendo para isso disponibilizados

diferentes tipos de linguagens de programação como C/C++, VB.NET, C#,

HTML/XHTML ou JavaScript. As aplicações criadas têm como destino as plataformas da

Microsoft: Windows, Windows Mobile, Windows Phone, Windows CE, .Net

Framework, .Net Compact Framework e Microsoft Silverlight.

Foi utilizada a Professional Edition do Visual Studio 2008 para criar as aplicações

de gestão e monitorização a serem executadas no dispositivo móvel com o SO

Windows Mobile 5.0. Foi necessário para isso integrar com o Visual Studio um SDK

(Software Development Kit), no caso o Windows Mobile SDK 5.0, e que inclui

ferramentas de emulação para permitir efetuar testes e a depuração das aplicações

durante a sua fase de desenvolvimento. Todo o código das aplicações criadas para o

dispositivo móvel foi criado recorrendo à linguagem computacional C# (C Sharp).

Eclipse

O Eclipse é uma plataforma de desenvolvimento de software, disponibilizado de

forma gratuita, que contém um IDE com suporte para várias linguagens de

programação, mas que está normalmente associado ao desenvolvimento de aplicações

em Java. De base apenas as ferramentas para desenvolvimento para Java (JTD Java

Development Tools) são disponibilizadas, sendo necessário acrescentar diferentes

plug-ins caso se pretenda utilizar outras linguagens ou ferramentas.

No projeto descrito nesta dissertação foi utilizada a plataforma Eclipse, versão

3.5 (Galileo), para desenvolvimento das funções Java, de suporte às aplicações móveis,

integradas na estrutura previamente implementada do servidor do projeto. Nesse

sentido, foram especialmente úteis as ferramentas de suporte a servidores (p.ex:

Apache Tomcat) disponibilizadas, que permitem, entre outras opções, testar as

funções do servidor diretamente no ambiente desenvolvimento.

Apache Tomcat

O Apache Tomcat é um container de servlets desenvolvido pela Apache Software

Foundation, e é distribuído de forma gratuita, sendo o meio de referência para

implementação das tecnologias Java Servlet e JavaServer Pages (JSP) da Sun

http://en.wikipedia.org/wiki/C_(programming_language)

http://en.wikipedia.org/wiki/C%2B%2B

http://en.wikipedia.org/wiki/VB.NET

http://en.wikipedia.org/wiki/VB.NET

http://en.wikipedia.org/wiki/HTML

http://en.wikipedia.org/wiki/XHTML

http://en.wikipedia.org/wiki/JavaScript



Microsystems. Possui ainda a possibilidade de desempenhar o papel servidor Web

HTTP para serviços implementados em Java, podendo ainda ser integrado com outros

servidores Web dedicados.

Foi utilizada a versão 6.0 do Tomcat para implementar o servidor do projeto, que

para além de disponibilizar as páginas Web desenvolvidas para a gestão e

monitorização via Web Browser continha também todos os serviços de apoio do

sistema (ARD e AAD).

MySQL

O MySQL é um sistema gestor de base de dados (SGBD), que se baseia na

linguagem SQL (Structured Query Language) para criar os mecanismos de interação

com registos de informação.

Características como a sua elevada fiabilidade e estabilidade, reduzida exigência

de recursos e facilidade de utilização ajudaram a tornar esta ferramenta na SGBD mais

utilizada no mundo, inclusivamente por empresas responsáveis por serviços Web

utilizados mundialmente e em larga escala por empresa como a Google, a Wikipedia

ou o Facebook, nas quais a fiabilidade relativa à gestão, divulgação e relacionamento

de dados è enorme.

Esta ferramenta tem uma enorme portabilidade, sendo capaz de suportar mais

de 20 plataformas, entras as quais: Linux, Windows, Mac OS, Solaris, HP_UX, IBM AIX.

Isso, em conjunto com as APIs específicas para utilização nas mais variadas linguagens

de programação, como Java, Visual Basic, C/C++, C#, Perl, PHP ou ASP, torna o MySQL

numa poderosa ferramenta também no desenvolvimento de sistemas informáticos

que necessitem de uma gestão fiável de dados.

No caso do projeto apresentado nesta dissertação, o MySQL foi utilizado no

desenvolvimento da base de dados onde são guardados todas as informações do

sistema, numa arquitetura de relações já apresentada, Figura 3.9. Para o acesso à base

de dados foi utilizada a API disponibilizada para a linguagem Java sobre na qual está

implementado o servidor do sistema, sendo este único elemento do projeto que acede

diretamente à base de dados.



4.3. Estrutura e Análise Funcional das Aplicações Desenvolvidas

4.3.1. Análise de Requisitos

Numa fase inicial do processo de planeamento, foram definidos os requisitos

funcionais da aplicação de monitorização móvel, tendo em conta tanto os fatores

estruturais do sistema MOHLL, previamente implementado, como as especificidades

inerentes à utilização dos referidos dispositivos móveis. Esta pré-análise do papel e

características de que o sistema de monitorização móvel deveria ser dotado traduziu-

se na definição dos seguintes requisitos funcionais como elementos base da aplicação

a instalar no PDA:

Autenticação, através de correlação username/password de modo a

restringir os acessos apenas a utilizadores autorizados.

Funcionalidades de gestão operacional do sistema global de monitorização.

- Gestão de dados dos pacientes (adicionar, editar, eliminar);

- Gestão de sensores (adicionar, eliminar);

- Gestão de associações sensores-paciente (associar, editar, desassociar);

- Definição de limites mínimos e máximos aceitáveis para cada um dos

sinais fisiológicos recolhidos de modo individual para cada paciente.

Visualização de todos os dados recolhidos.

- Visualização, em tempo real, dos dados referentes a cada um dos sinais

fisiológicos recolhidos;

- Representação gráfica das variações dos dados captados ao longo do

tempo;

- Apresentação de informação anexa à monitorização, como o nível da

bateria de cada sensor ou indicação sobre a disposição dos valores

medidos, fora ou dentro dos limites definidos para cada paciente.

Um dos fatores considerados durante a elaboração desta lista foi tentar garantir

que a maioria das capacidades disponibilizadas no site pudesse ser transportada para a

aplicação móvel. Assim, tanto as funções de monitorização como as referentes à

gestão do sistema poderiam ser acedidas de modo mais prático. No entanto, as



funções relacionadas com a gestão de utilizadores, isto é, adicionar, editar e eliminar

dados referentes aos utilizadores, como nome, username e password, bem como a

definição do grau de acesso facultado, não foram incluídas no grupo de

funcionalidades atribuídas à aplicação móvel, visto não ser uma necessidade

recorrente no processo de funcionamento do sistema global de monitorização. Este

processo seria apenas disponibilizado através do site e, como previamente descrito,

apenas acessível ao(s) utilizador(es) administrador(es).

Nas considerações iniciais deste projeto, foi definido que o programa criado teria

um propósito de utilização esporádica, isto no que toca ao tipo de monitorização a

praticar: de rotina, de consulta; bem como no que se refere às situações de gestão

onde, previsivelmente, será mais utilizado: auxílio prático ao trabalho dos responsáveis

por interagir com os pacientes e controlar a distribuição dos sensores.

Esta premissa foi assumida de certo modo pelas limitações que um equipamento como

um PDA ou um smartphone tem, no que toca especialmente à duração da sua bateria,

especialmente quando o seu sistema de comunicação Wi-Fi necessita de estar em

atividade constante, como é o caso.

A acrescentar a estas apreciações, foi ainda determinado que as aplicações a

desenvolver teriam de ser capazes de sustentar alguns fatores críticos como a

capacidade de absorver falhas do sistema sem prejuízo para o utilizador, quer estas

fossem relativas ao meio de distribuição de dados, quer estas fossem provocadas por

qualquer tipo de limitação no equipamento usado.

A seguir são descritos mais pormenorizadamente os programas desenvolvidos

tanto para o PDA usado, como para o software embutido no computador servidor.

4.3.2. Servidor – Suporte a Aplicações Móveis

Visto o servidor ser o ponto comum de todas as comunicações, a correta

estruturação dos seus subsistemas de ligação externa surge como um dos fatores

críticos deste processo de troca de dados.

Para perceber as alterações introduzidas no servidor no sentido de este poder

responder a um novo tipo de cliente, a aplicação móvel, é necessário compreender



primeiro as especificidades do servidor no seu estado anterior à adição deste novo

cliente.

Como já foi mencionado, o servidor é constituído por diferentes componentes,

cada um com funções singulares. A base de dados, onde são agregadas todas as

informações do sistema de gestão e monitorização, é o elemento comum às duas

aplicações Web (DataCollect e WebServer) que completam os serviços do servidor.

Estas nunca cruzam informação diretamente, somente através da BD, e são

responsáveis por lidar com os dados provenientes de clientes distintos, respondendo a

pedidos de informação ou encaminhando os dados recebidos até à BD. O DataCollect

(ARD) está diretamente relacionado com o cliente gateway ZigBee – WiFi, até onde são

conduzidos, através da rede ZigBee, os dados medidos por cada um dos elementos da

rede de sensores. Quanto à função do WebServer (AAD), esta passa por interagir com

os clientes destinatários do sistema, ou seja, as aplicações destinadas a disponibilizar

ao utilizador o meio para consultar ou gerir todos os dados do sistema. O esquema de

ligações entre estes blocos pode ser observado na Figura 4.4.

Figura 4.4 - Relação entre os blocos do servidor

Tendo em conta a necessidade de acrescentar no servidor um meio que

permitisse o suporte à aplicação instalada no PDA, a opção tomada passou por não

acrescentar um sistema de suporte independente para efetuar a ligação da nova

aplicação à BD, mas sim inserir na organização precedente um novo ramo de ligação.

Deste modo seria possível manter a arquitetura do servidor já implementada, evitando

assim introduzir qualquer tipo de mudança estrutural, que potencialmente provocaria

um decréscimo de eficiência no sistema global.

A possibilidade de integração do sistema de suporte às aplicações móveis dentro

do programa servidor previamente desenvolvido apenas foi possível devido à sua

organização em subaplicações com funcionamento independente. No que se refere a



este projeto, foram mantidas todas as configurações da ARD (DataCollect) e, já que a

aplicação de monitorização móvel não previa o acréscimo de nenhum novo tipo de

dados, também foi definido que seria mantida a estrutura do modelo de relações da

base de dados. Visto esta ser partilhada também com os pedidos efetuados pelo

Website, uma alteração destas relações seria inviável, e um acréscimo de novas

relações, com repetição dos mesmos dados, traria reduzidos benefícios em

comparação com a maior complexidade organizacional que seria originada.

Como foi descrito no ponto 3.4.4, a estrutura da aplicação AAD assenta na

distribuição por camadas que tem como propósito fazer com que o funcionamento de

cada camada seja abstraído dos detalhes de implementação das restantes, fazendo

com que a interação entre as camadas seja efetuada exclusivamente através dos seus

elementos públicos.

Para permitir que o sistema servidor tivesse também um mecanismo de

interação com as funções de monitorização e gestão implementadas no PDA, foi

introduzida na AAD (WebServer) uma nova camada de aplicação com este propósito

específico.

Mas uma questão que vale a pena clarificar está relacionada com alguns

pormenores funcionais de cada uma das camadas previamente implementadas. Na

Figura 4.5 é possível verificar a estrutura criada para o suporte ao Web Browser. A

Camada de Dados é a única que estabelece uma relação com a BD, pois a sua função é

fazer a abstração da AAD aos dados do sistema. É por isso aqui que são organizadas as

queries a enviar à BD e as respetivas respostas a encaminhar às camadas superiores. A

Camada de Negócio, para além de efetuar a ligação entre as duas camadas adjacentes,

trata igualmente de todas as comunicações de dados com as paginas HTML do site,

excetuando as funções relacionadas com o applet Java, já que estas ficam ao cargo da

Camada de Apresentação. Este pormenor prende-se com o facto de o site ser visível no

cliente, mas ser gerado a partir do código JSP alocado dentro da máquina servidora,

contrariamente ao que acontece com o applet. Sendo este uma aplicação a ser

executada apenas no PC cliente, tem de utilizar o método Post para comunicar com a

máquina servidora através de um canal de streaming de dados. Isto implica que do

ponto para o servidor, os applet criados durante a monitorização no Web browser

sejam vistos como componentes externos, exclusivos do cliente.



Figura 4.5 - Distribuição por camadas da AAD (exclusivamente para o Web Browser) [Pe09].

Esta perceção por parte do servidor em relação aos serviços do applet é similar à

que o servidor tem sobre todas as funções do PDA, o que significa que no caso da

aplicação do PDA, todos os acessos ao servidor são feitos via método Post, pois esta,

tal como o applet, é executada exclusivamente no equipamento do cliente. Neste

sentido, o processo de integração do sistema de suporte às aplicações móveis passou

por adicionar uma Camada de Apresentação PDA (CAP) que funciona em paralelo com

a anteriormente implementada Camada de Apresentação. Mas, enquanto a mais

antiga apenas trata das comunicações com o applet e as suas funções de

monitorização, a nova camada executa todo o trabalho de receção e envio de

informações para a aplicação PDA.

Figura 4.6 - Arquitetura do sistema de suporte à aplicação PDA [adaptada de FeAfSi11]

Assim, no que se refere à aplicação móvel, as restantes camadas, a de Negócio e

a de Dados, podem ser vistas como uma única camada de abstração à base de dados,



como está esquematicamente demonstrado na Figura 4.6. Estas duas camadas

inferiores foram, no entanto, igualmente adaptadas para responder a algumas

características específicas das funções do PDA. Entre novas funções adicionadas, foram

também resolvidas questões de pormenor relacionadas com inconsistências de dados

durante o funcionamento quer do site quer da aplicação móvel.

A opção de não inserir as configurações de suporte numa mesma Camada de

Apresentação deveu-se essencialmente à incontornável possibilidade de aparecimento

de conflitos entre threads de comunicação, caso dois sistemas de proveniências

diferentes (PDA e site) estivessem a utilizar as funções de monitorização de sinais em

simultâneo. Isto devido ao elevado número de recursos necessários, sempre que o

envio de dados em tempo real relativos aos sinais medidos é requerido por qualquer

um dos sistemas, pelo applet contido no Web Browser ou pela janela de monitorização

da aplicação do PDA. No ponto seguinte, será abordado este tema novamente quando

for descrito o funcionamento desta parcela da aplicação móvel.

A Camada de Apresentação PDA (CAP) foi desenvolvida em linguagem JAVA e

recorre ao método doPost da classe Servlet (API Java) para responder aos pedidos, de

inserção ou consulta de dados, efetuados pela aplicação móvel através do protocolo

HTTP. Cada pedido, constituído de acordo com um protocolo de mensagens

previamente definido, é diretamente recebido pela CAP, que estabelece uma

correspondência direta a uma das suas subfunções. A partir daí, os pedidos são

descodificados, quer quanto ao tipo de ação a executar, quer quanto aos dados que

transporta, e seguidamente encaminhados para as camadas posteriores responsáveis

por aceder à base de dados. A CAP é depois responsável por enviar uma resposta para

a aplicação móvel com a confirmação de execução do pedido e, se for caso disso, os

dados requeridos. Os diagramas de sequência que representam os diferentes

protocolos para os diferentes tipos de comunicações estabelecidas entre o PDA e o

Servidor podem ser observados no Anexo I.

4.3.3. Aplicação para o PDA

O ponto de partida para o desenvolvimento da aplicação de monitorização e

gestão desenvolvida para o PDA foi tentar fazer com que um regular utilizador do site



desenvolvido para o projeto MOHLL pudesse reconhecer facilmente todas as

características e funcionalidades com as quais estaria habituado a trabalhar. Mas, visto

esta aplicação também poder ter como utilizador um próprio paciente do sistema,

também foi feito um esforço para que se percecionasse de modo relativamente rápido

as possibilidades disponibilizadas pela interface da aplicação.

Assim, a organização da interface assenta na mesma organização do site fazendo

com que passe a existir uma estrutura comum a todos os elementos clientes com os

quais todos os utilizadores trabalham, diminuindo desta forma o tempo de adaptação

necessário para interagir com os diversos sistemas. A estrutura da interface gráfica

criada para a aplicação pode ser observada na Figura 4.7.

Tendo em conta o tipo de informação com que este sistema trabalha, a utilização

de um sistema de autenticação para restringir o acesso à informação apenas a pessoas

autorizadas é uma necessidade básica, sendo por isso o primeiro ponto de contacto

dos utilizadores com a aplicação. A partir daí os conteúdos disponibilizados a cada

utilizador diferem consoante o nível de autorização que lhes foi atribuído.

Os conteúdos estão divididos por três áreas de operação principais:

monitorização de sinais, gestão de pacientes e gestão de sensores. Os utilizadores

referenciados como Administradores ou Gestores têm acesso a todas as áreas de

funções, enquanto os utilizadores Visualizadores apenas tem a possibilidade de

interagir com as funções de monitorização de sinais. Na Figura 4.7 está distinguida a

vermelho a zona de operação à qual este último grupo de utilizadores está restringido.



Figura 4.7 - Diagrama da interface da aplicação.

Classe de Comunicação

A execução de uma grande parte das funções disponibilizadas pela aplicação

requer que seja estabelecida uma interação com o servidor do sistema, no sentido de

se proceder à transferência dos dados inerentes ao tipo de função a executar.

Considerando então o elevado número de comunicações levadas a cabo, sempre que a

aplicação é executada, resolveu-se criar uma classe de comunicação especificamente

para lidar com as transferências de informação com servidor e que se relaciona com as

diferentes funções disponibilizadas pela aplicação PDA. Um esquema da posição

relativa desta classe dentro da aplicação pode ser observado acima, na Figura 4.6,

encontrando-se aí referenciada como “Connection Class”.



Esta classe funciona como elemento público da aplicação, sendo através desta

que a aplicação comunica com o exterior. A sua implementação está assente num

modelo WebRequest / WebResponse ou, como o próprio nome indica, num esquema

de pedidos e respostas estabelecido com o servidor. Nas configurações das classes

referidas são indicados os processos e os métodos que elas devem utilizar com o

intuito de alcançar o servidor do sistema MOHLL. No caso específico, é indicado o URI

(Uniform Resource Identifier) do servidor, o método (Post) utilizado para efetuar o

pedido e o tempo máximo permitido para cada acesso, antes de a comunicação ser

dada como falhada. Estas configurações são depois associadas à mensagem codificada,

onde estão contidos os dados que uma determinada função da aplicação precisa de

enviar para o servidor, de modo a que este lhe responda com os dados pedidos. Na

Figura 4.8 é possível observar um diagrama que pretende apresentar os conceitos

sobre os quais é executado o processo de comunicação do PDA com o servidor.

Esta classe de comunicação implementa ainda um processo de certificação de

respostas previamente definido com o servidor, estabelecendo uma rotina de

verificação de cabeçalho da resposta, não estando este relacionado com o conteúdo

da resposta, mas sim com a origem dos dados. Quanto ao conteúdo, este é

posteriormente encaminhado para a área de código da função que despoletou o

pedido e aí sim efetuada a validação do conteúdo.

Figura 4.8 - Diagrama do processo de comunicação.

É necessário ainda referir que este processo não é utilizado pelas funções de

monitorização de dados em tempo real, pois a lógica de comunicação em streaming

não se coaduna com o perfil de pedido/resposta que esta classe pretende

implementar, visto o canal de acesso criado no início da comunicação encerrar logo

que a resposta tenha sido recebida. Visto as comunicações de monitorização

necessitarem de um canal aberto permanente, o princípio de comunicação usado varia

ligeiramente. Posteriormente será explicado este processo de transferência contínua

de dados de modo mais detalhado.



Interface gráfica e funções associadas

Neste ponto, são apresentadas as diferentes janelas (forms) que constituem a

interface da aplicação, assim como as funções disponibilizadas ao utilizador, bem como

os mais relevantes procedimentos auxiliares embutidos em cada janela.

Como já foi mencionado, a primeira janela com a qual os utilizadores entram em

contacto com a aplicação é a janela de autenticação, Figura 4.9. Nesta, para além das

funções relacionadas com a validação do utilizador, são gravados nas variáveis do

sistema o nível de autorização associado e a diferença temporal existente entre os

relógios dos dois equipamentos (PDA e servidor). Esta necessidade de saber qual o

atraso temporal entre estas duas componentes do sistema deve-se ao modo como os

dados das medições sensoriais são enviados pelo servidor. Associado ao valor medido

está obrigatoriamente o timestamp de recolha da amostra, mas este é calculado em

relação ao relógio do servidor. Daí, o fato de conhecer o horário exato em que cada

equipamento está sincronizado, permite à aplicação PDA avaliar a validade ou

antiguidade das medições recebidas.

Figura 4.9 - Janela de autenticação.

Nesta janela, o utilizador tem ainda a opção de configurar o IP do servidor, que é

depois utilizado na construção do URI usado na comunicação HTTP. Esta opção seria

apenas útil no caso de o servidor não ter um IP fixo, mas visto este ser um processo

pouco prático para os utilizadores esta opção será de futuro eliminada, ficando o

endereço do servidor gravado permanentemente nas definições da aplicação.



Após a correta autenticação do utilizador, este é encaminhado para a janela de

menu da aplicação, Figura 4.10 e Figura 4.11. Esta está dividida em três abas, que

funcionam basicamente como três janelas independentes. Na primeira, estão listados

os pacientes com sensores associados e só estes pois os restantes não são passiveis de

ser monitorizados; na segunda, surge a listagem de todos os pacientes do sistema e as

opções de gestão associadas a estes; na terceira, aparece a listagem e as funções de

gestão relacionadas os sensores do sistema.

Figura 4.10 – Menu: esq. Monitorização; dir. Gestão de Pacientes

Figura 4.11 - Menu - Gestão de Sensores



Durante o funcionamento do sistema, vários utilizadores em vários pontos de

acesso diferente podem interagir com os dados gravados na BD. Assim sendo, e tendo

em consideração que a Janela Menu tem de apresentar várias listas de componentes

do sistema, foi introduzido no código desta janela uma thread a correr em segundo

plano que faz consultas periódicas ao servidor no sentido de poder atualizar as listas

apresentadas, caso seja efetuada alguma alteração num dos componentes das listas.

Por exemplo, se um paciente fosse eliminado do sistema enquanto algum utilizador

desta aplicação estivesse na janela Menu, esse paciente iria desaparecer das listagens,

quer na aba de monitorização, quer na aba de gestão de pacientes.

Das opções na aba de janela, a função “Eliminar Paciente” é a única que não

direciona o utilizador para uma nova janela, mostrando apenas uma mensagem ao

utilizador no sentido de este confirmar a opção de eliminação.

Quanto às funções “Inserir Paciente” e “ Editar Paciente” presentes na aba de

gestão de pacientes, têm um funcionamento bastante semelhante, diferindo somente

na apresentação ou não dos dados do paciente consoante se pretenda Editar ou

Inserir, respetivamente. Esta apresentação dos dados de um paciente, quando se

pretende editar as suas informações, pressupõe, obviamente, uma consulta inicial ao

servidor de dados do sistema. Estas duas janelas podem ser observadas na Figura 4.12.

Figura 4.12 - Janela Inserir Paciente (esq.); Janela Editar Paciente (dir.).

Ainda dentro das opções de gestão, pode ser encontrada a função de



configuração de alertas, ilustrada na Figura 4.13. Aí o utilizador poderá definir os

valores máximos e mínimos para os quais os sinais fisiológicos do paciente são

considerados aceitáveis. Estes limites podem ser definidos quer o paciente tenha ou

não um sensor do tipo do limite que se está a definir, entrando posteriormente em

funcionamento quando o respetivo sinal fisiológico começar a ser monitorizado.

Figura 4.13 - Janela Configurar Alertas

Para finalizar as opções de gestão de pacientes, é disponibilizada a função

“Associar Sensores”, que serve para gerir a associação de sensores a determinado

paciente. Na Figura 4.14, são apresentadas as janelas relacionadas com esta opção. À

esquerda é apresentada a janela que faz a listagem dos sensores associados, e aqui

pode ainda ser feita a desassociação de qualquer dos sensores apresentados na lista

através do botão “DEL”. Caso se selecione a opção “Associar Sensor” é-se direcionado

para a janela apresentada do lado direito da Figura 4.14, onde são apresentados os

sensores que não estão associados a qualquer paciente. Neste caso concreto, não seria

possível associar nenhum dos sensores listados nessa janela, visto o paciente em

questão já ter a ele associados os tipos de sensores disponíveis na lista.



Figura 4.14 - Janela Listar Associações esq.; Janela Associar Sensor dir.

Quanto às opções disponibilizadas na aba de “Gestão de Sensores”, estas dão a

possibilidade ao utilizador de inserir um novo sensor, janela correspondente à

apresentada na Figura 4.15, ou permite que o utilizador elimine um sensor do sistema.

Esta segunda opção, tal como a função previamente apresentada de eliminação de

pacientes, não apresenta nenhuma nova janela, mas apenas uma mensagem com um

pedido de confirmação da ação.

As funções “Eliminar”, tanto a de Sensores como a de Pacientes, têm uma rotina

de verificação, implementada no servidor, que deteta se o componente que se

escolheu eliminar tem alguma associação a outros componentes, de modo a terminar

essa associação antes de apagar o campo correspondente da base de dados. Por

exemplo, quando se elimina um paciente, esta rotina verifica se este tem sensores

associados, e caso isto se verifique ela é responsável por libertar estes sensores para

futuras associações a outros pacientes.

Na Figura 4.15 pode ainda ser observado o teclado de apoio que surge no ecrã,

sempre que o utilizador entra numa janela na qual poderá ter de inserir caracteres.

Este pode no entanto ser minimizado para se poder ter uma maior visibilidade sobre a

janela e as suas opções.



Figura 4.15 - Janela Inserir Sensor

No que se refere à da aba de monitorização, é apenas disponibilizada ao

utilizador a função “Visualizar”, que o direciona até à janela de monitorização dos

sinais vitais do paciente selecionado. Esta, como pode ser observado na Figura 4.16,

tem um formato semelhante ao applet de monitorização do site. As informações

básicas do cliente a monitorizar começam por ser apresentadas no início da janela,

seguidas da área de representação gráfica do sinal de ECG, bem como das áreas de

apresentação dos valores (numéricos) dos restantes sinais. Neste caso, apenas estão

visíveis os espaços destinados à amostragem do valor de temperatura corporal e do

ritmo cardíaco. No entanto, esta janela está já preparada para receber a introdução

dos restantes sinais, de oximetria e pressão arterial. O valor apresentado nestes

campos tem ainda a informação acerca da posição destes valores em relação aos

limites definidos na área de gestão de pacientes: verde para os valores dentro dos

limites; vermelho para os valores fora dos limites, e que por isso requerem mais

atenção por parte do pessoal médico.

Cada sinal apresentado é acompanhado ainda da informação referente ao nível

da bateria do sensor que o está a recolher. No caso do sensor de ECG esta indicação

encontra-se no canto superior direito, enquanto os restantes sinais possuem esta

informação à frente do valor medido.

Uma funcionalidade acrescentada nesta janela é a possibilidade de controlar a



grossura da linha usada durante a representação gráfica do sinal de ECG, que pode

também ter a sua escala de representação vertical alterada através da função Zoom.

Figura 4.16 - Janela de Monitorização.

No final da janela de monitorização, é disponibilizada ao utilizador a opção de

visualizar também o histórico de qualquer um dos sinais que estão a ser

acompanhados, embora de modos diferentes. Em relação ao ECG, só é possível

apresentar o histórico referente ao último minuto de recolha do sinal, ou seja, durante

a visualização do sinal, existe uma função destinada a guardar os dados que estiverem

a ser recebidos, e caso o utilizador necessite de analisar um ponto específico desta

monitorização, a função de histórico de ECG permite que este pare a sua

representação e observe melhor esse acontecimento. No entanto, mesmo durante a

visualização do histórico, a função de gravação de sinal continua a guardar os dados

em tempo real, de modo a que o utilizador possa ainda visualizá-los noutra consulta ao

histórico de ECG. Este gráfico do histórico de ECG é representado sobre a mesma

grelha onde é feita a apresentação do sinal em tempo real. Como a escala temporal é

igual, a visualização do sinal pode ser feita utilizando uma barra de scroll horizontal

para alterar os intervalos de tempo da representação, Figura 4.17.



Figura 4.17 - Janela Histórico de ECG

Quanto aos históricos de temperatura e de ritmo cardíaco, a sua visualização é

feita numa janela onde são apresentadas as últimas 24 horas de visualização de

recolha do sinal, como pode ser visto na Figura 4.18. O funcionamento desta janela

consistem em requerer ao servidor todas as medições feitas por um tipo de sensor

(consoante o histórico que se está a visualizar), correspondentes às 24 horas

anteriores ao pedido, e posteriormente utilizar as funções gráficas de desenho

(System.Drawing) para representar a evolução temporal desse sinal.

Nesta janela, é disponibilizada ainda a função de Zoom, que permite ao

utilizador variar os intervalos de representação do sinal, permitindo que este alterne

entre uma visualização mais global da variação do sinal, até uma zona temporal mais

específica. No caso do histórico de Temperatura, o intervalo de observação mais

pequeno é de uma hora, enquanto para o sinal de ritmo cardíaco, este intervalo é de

10 minutos, devido ao facto de este sinal ter uma variação bastante mais inconstante

do que o sinal de temperatura corporal.



Figura 4.18 - Janela Histórico de Temperatura.

Monitorização

Em relação ao desenvolvimento da aplicação, as funções de monitorização são

simultaneamente as mais importantes e as mais exigentes ao nível da utilização dos

recursos gráficos, de processamento e de comunicação do PDA.

A primeira fase deste processo passou por encontrar a melhor forma de

implementar as funções de representação gráfica dos sinais. Visto o .Net Compact

Framework não suportar as funcionalidades gráficas disponibilizadas no comum .Net

Framework, e visto o equipamento utilizado ter algumas limitações gráficas, foi

necessário encontrar um método de representação que fosse suportado pelos

recursos dos PDA, e ao mesmo tempo que sustentasse as exigências temporais

requeridas para a mostragem do sinal de ECG.

Assim, o processo de representação escolhido baseou-se nas limitadas, mas

pouco exigentes funções de desenho disponíveis (System.Drawing.Drawing2D). A

partir do momento em que a área de desenho (plot area) é definida, a representação

dos gráficos é feita em função das fórmulas matemáticas de definição de retas entre

dois pontos, e das escalas utilizadas.

No caso do ECG, durante o processo de criação da janela de monitorização é

colocada no fundo da área de desenho uma imagem (classe System.Drawing.Bitmap)

que ajuda o utilizador compreender as escalas de representação do sinal, visto, neste



caso, não existirem legendas da escala. Como se pode ver na imagem ilustrada na

Figura 4.19, a escala de representação horizontal é de cerca de 2,4 segundos do sinal,

enquanto a escala vertical corresponde a 2,4 milivolts.

Figura 4.19 - Escala da area de representação do sinal de ECG

Foi definido que, quando a trabalhar em tempo real, a representação gráfica do

sinal de ECG é feita em blocos de 250 milissegundos, nos quais são reproduzidas as 50

amostras recolhidas para o intervalo correspondente. A continuidade da

representação é garantida por uma rotina que vai apagando o sinal antigo, à medida

que novas entradas do sinal são recebidas e que necessitam de utilizar essa área.

Tal como anteriormente mencionado, o esquema de comunicação nesta área da

aplicação é diferente de todas as restantes interações com o servidor. Por forma a

garantir a contínua receção dos valores medidos pelos sensores, a aplicação começa

por enviar ao servidor um WebRequest, onde são pedidas as medições efetuadas pelos

sensores associados ao paciente indicado na mensagem de pedido. A partir desse

momento, e até que a aplicação peça para encerrar a comunicação ou esta seja

encerrada por algum fator externo, fica estabelecido um canal de comunicação entre

os dois por onde são recebidos os dados das medições efetuadas. Na prática a

aplicação apenas recebe uma WebResponse para o pedido efetuado, mas visto o

servidor não dar a resposta por concluída, pode ir acrescentando dados à resposta à

medida que eles vão sendo acrescentados na base de dados, ou seja, do ponto de vista

da aplicação, os vários conjuntos de dados rececionado ao longo do tempo

correspondem a linhas da resposta.

Dentro da aplicação servidor, para responder às necessidades de comunicação e



apresentação dos dados recebidos, foi desenvolvido um sistema de threads para que

durante a execução dos diferentes processos do sistema não haja áreas de código

dependentes de outras. Assim para toda a gestão relacionada com a comunicação,

receção e armazenamento de dados por Arrays (baterias; ritmo cardíaco; temperatura)

e Queue (ECG), foi implementada a thread HttpConnection, enquanto que para lidar

com o aspeto gráfico da janela foram inseridos na thread principal do código duas

funções despoletadas por timers, uma para representar o gráfico de ECG a cada 250

milissegundos e outra para fazer a atualização dos restantes conteúdos da janela

(baterias e medições de ritmo cardíaco e temperatura corporal). Na Figura 4.20 pode

ser observado o esquema de funcionamento da área de visualização de dados da

aplicação para PDA:

Figura 4.20 - Funcionamento da Janela de Monitorização

Como demonstrado, ao longo de toda aplicação são executadas inúmeras

transações de informação com o servidor, mas tratando-se este de um sistema móvel

com recurso a ligações sem fios, a perda de sinal por este e por outros motivos foi uma

das preocupações tidas em consideração durante o processo de blindagem da

aplicação a inconsistências de funcionamento.

Assim, foi desenvolvida mais uma janela de recuperação de erros (Figura 4.21)

que, um pouco à imagem do que acontece por defeito num Web browser comum,

informa o utilizador acerca das falhas de comunicação que podem ocorrer durante a

execução do código do programa, dando-lhe depois a possibilidade de tentar efetuar

uma nova conexão ao servidor ou simplesmente sair e dar por encerrados todos os

recursos da aplicação.



Figura 4.21 - Janela de Recuperação de erros de ligação


CAPÍTULO 5

Resultados Experimentais e Discussão

5.1. Introdução

Como meio de validação do funcionamento e operacionalidade das aplicações de

gestão e monitorização móvel anteriormente descritas, realizaram-se alguns testes

onde diferentes aspetos do comportamento das aplicações foram analisados. Neste

capítulo são apresentados os resultados obtidos durante a realização dos testes à

aplicação para o PDA implementada como parte do projeto MOHLL.

Embora apenas sejam apresentados os resultados finais, o processo de validação

foi sendo executado durante o decurso do desenvolvimento da aplicação, visto o

processo de criação do software ter sido baseado, em parte, no princípio de tentativa

erro, ao qual está associada a permanente validação das diferentes etapas do sistema.

Este processo de constante avaliação, onde foi garantida a certificação de todas as

opções disponibilizadas pela aplicação aos seus utilizadores, possibilitou que esta

avaliação final do sistema móvel de monitorização pudesse ser mais focada em

questões operacionais do ponto de vista do utilizador.

Todos os resultados apresentados de seguida foram efetuados tendo por base a

mesma configuração organizacional de elementos de rede, onde as comunicações

entre o PDA e o computador servidor foram executadas através de uma rede wireless

com um único router de encaminhamento de dados. Esta estrutura usada pode ser

observada na Figura 5.1

Router

PDA

WAN

WAN

Paciente-Sensor

ZigBee

Coordenador de Rede

Figura 5.1 - Organização do sistema de monitorização durante a fase de testes

Capítulo 5 – Resultados Experimentais e Discussão


5.2. Testes Não Funcionais

A influência que a utilização da aplicação tem no consumo energético do PDA, foi

um dos aspetos considerados durante a avaliação da aplicação, e os resultados obtidos

podem ser observados na Tabela II. Estes dados estão no entanto diretamente

relacionados com o PDA usado e respetivas características, como capacidade da

bateria ou o consumo do hardware. Como já foi referido, para efetuar todos os testes

da aplicação, foi utilizado o PDA Qtek 9090 que possui uma bateria de iões de lítio com

1400mAh de capacidade, que, devido ao facto de já ter um tempo de utilização

relativamente elevado, tem uma natural diferença de rendimento, quando comparada

com uma bateria nova.

Tabela II – Consumo energético e autonomia do PDA em função de diferentes modos de funcionamento

A análise destes resultados permite comprovar que a aplicação tem uma elevada

exigência ao nível do consumo energético, especialmente quando em situações de

monitorização, pois neste caso é constante a necessidade que o sistema tem de

recorrer à comunicação wireless para atualizar os valores dos sinais recolhidos pelos

sensores. A exigência é ainda maior quando o sinal de ECG está também a ser captado,

pois para este, além de ser requerido um esquema de comunicações ainda mais

complexo (1 pacote de dados a cada 250 milissegundos), está também associada a

representação gráfica do sinal, na mesma proporção temporal da receção dos dados.

Convém ainda referir que este teste foi efetuado em condições ótimas de receção de

sinal Wi-Fi, tendo o consumo de energia tendência a aumentar caso existam



interferências entre o PDA e router wireless.

Estes resultados vêm reforçar a ideia de que o sistema criado não tem

capacidade para suportar um tipo de monitorização contínua, tendo este um perfil

apenas indicado para uma utilização esporádica, de rotina ou de emergência. Este não

é, no entanto, um problema específico do sistema criado e a análise e procura de

soluções para este problema tem sido um tema amplamente debatido [VaHuCr10],

[CaHe10], pois o nível de desenvolvimento dos smartphones não tem sido

acompanhado convenientemente pela eficiência das suas baterias.

A apreciação do funcionamento de uma aplicação de software como esta pode

também ser feita em termos de rapidez de execução. Tendo em consideração que

durante a utilização da aplicação são efetuadas inúmeras transferências de pacotes

entre o PDA e o servidor do projeto, este tempo que demora a realizar cada tarefa está

dependente do número de transferências necessárias à sua conclusão e também do

caminho (número de hops) que os dados têm de percorrer na rede, ou seja, o número

de elementos de rede por onde os pacotes têm de passar para chegar do PDA ao

servidor e vice-versa. Na Tabela III são apresentados os tempos que a aplicação

demora a atingir determinada janela, partindo da janela de menu, sendo que entre a

Janela de Autenticação e a Janela de Menu o sistema demora cerca de 3,8 segundos a

carregar todas as informações e atualizar a interface.

Tabela III - Tempos de acesso às diferentes áreas do sistema

Como é expectável, as funcionalidades que necessitam de transferir mais

pacotes antes de as respetivas janelas apresentarem todos os dados que lhes estão



associados são que apresentam um maior atraso de acesso. No entanto, de um modo

geral, e como pode ser comprovado pelos valores apresentados, a aplicação cumpre as

suas funções dentro de um tempo razoável, tendo em conta a sua permanente

necessidade de transferência de informação.

Os dados recolhidos com a aplicação em funcionamento indicam que uma

simples comunicação com o servidor, usando a classe de comunicação HTTP da

aplicação, demora menos de um segundo.

Neste sentido, sempre que para apresentar uma janela é apenas necessário

efetuar um pedido de dados, como é o caso de Editar Pacientes, Associar Sensores,

Configurar Alertas ou na transição da janela de Monitorização para a Janela Históricos

(3,6 - 2,4), o tempo total para apresentação da janela de destino é pouco superior a

um segundo, visto ter de se acrescentar, ao tempo da comunicação, o tempo

necessário para configurar o layout da janela. As janelas em que o tempo de

apresentação é inferior a um segundo referem-se àquelas onde não é necessário

estabelecer qualquer ligação com o servidor antes de serem apresentadas.

No que se refere às opções de monitorização, tratando-se das mais importantes

e mais complexas funcionalidades disponibilizadas, estas foram analisadas do ponto de

vista do tempo de atraso com que os dados eram apresentados no ecrã do PDA, em

relação ao tempo de recolha dos dados. Este tempo está diretamente dependente da

sincronização entre a receção dos pacotes de dados e a sua representação. Após uma

primeira fase de experiências, em que este tempo de atraso tinha tendência a

aumentar ao longo do tempo devido a uma ligeira dessincronização entre a receção e

representação dos dados, foi conseguido atingir um ponto de equilíbrio que mantém

indefinidamente este atraso no intervalo de 1,5 a 2,5 segundos, dependendo da

quantidade e do tipo de sinais a serem acompanhados. Embora este resultado tenha

sido obtido para situações onde existe apenas um elemento de rede entre o servidor e

o PDA, o tempo conseguido pode ser considerado bom para um tipo de

acompanhamento que se pretende ser em tempo real.

5.3. Avaliação Médica

Um dos principais focos da avaliação a que as aplicações foram submetidas



passou por recolher feedback junto de elementos do pessoal médico do Hospital

Privado de Guimarães. Após uma breve descrição dos objetivos do sistema

apresentado e do projeto no qual este se inseria, já conhecido pela maioria dos

entrevistados, foi dada oportunidade de interagirem diretamente com todas as

funções da aplicação durante uma simulação de situações reais de monitorização,

como pode ser visto na Figura 5.2.

Figura 5.2 - Teste efetuado por um profissional de saúde do HPG [FeAfSi11].

Todos os intervenientes no processo de avaliação hospitalar foram depois

submetidos a um inquérito, que pode ser consultado no Anexo II, no qual se pretendia

aferir o desempenho da aplicação com que interagiram e a sua importância dentro de

um projeto de monitorização de pacientes não críticos.

A avaliação efetuada pode ser em parte traduzida no gráfico representado na

Figura 5.3, nomeadamente no que se refere à opinião dos médicos e enfermeiros

inquiridos relacionada com a parte técnica da organização e funcionamento da

aplicação. Ainda dentro da parte técnica, foi possível recolher a informação de que

nenhum dos inquiridos teve quaisquer dificuldades durante a utilização da mesma.

Do inquérito referido, foi possível ainda concluir que a maioria dos participantes

(6 de 7) considera que esta aplicação pode ter utilidade no acompanhamento clínico

dos utentes. Dentro das funcionalidades disponibilizadas, a possibilidade de

acompanhamento, em tempo real, dos sinais vitais de qualquer paciente, e a partir de

um dipositivo móvel, foi, de forma geral, considerado o aspeto mais relevante do



sistema que lhes foi apresentado. Dentro do campo destinado a críticas e sugestões,

foram dadas sugestões relativas, sobretudo, à melhoria do sistema global de

monitorização. Aqui destacam-se a referência à possibilidade de monitorização dos

outros sinais fisiológicos previstos para o sistema, tensão artéria e oximetria. Também

foi levantada a questão de esta aplicação ser exportada para outros sistemas

operativos mais utilizados atualmente. Quanto aos pontos específicos a esta aplicação

podem ser mencionados:

A necessidade de acrescentar um campo na informação do paciente onde

possam ser descritos os seus antecedentes clinicamente relevantes;

A melhoria do sistema de alerta da aplicação, que deveria indicar ao

utilizador, logo que entra na aplicação, todos os pacientes cujos sinais

vitais se encontram fora dos limites definidos;

A melhoria da escala vertical apresentada na janela de visualização do

histórico do ritmo cardíaco.

Esta última sugestão já foi, entretanto, implementada.

Figura 5.3 - Distribuição dos resultados da avaliação efetuada

Como complemento do processo de avaliação, foi ainda pedido a um

especialista, no caso ao cardiologista Dr. Otílio Rodrigues da Casa de Saúde de

Guimarães, para, após utilizar o sistema, dar a sua opinião sobre o funcionamento e

utilidade do sistema. Como pode ser visto no Anexo III, a sua opinião é que este tipo de

sistemas pode ser bastante relevante na monitorização clínica de pacientes internados

em ambiente hospitalar ou não, tendo ainda considerado que a aplicação permite

efetuar o tipo de acompanhamento a que se propôs de forma eficaz.

0 1 2 3 4 5 6 7

A visualização do ECG é adquada

A visualização da restante

informação é adequada

O menu de opções está

bem organizado

A aplicação é simples de

utilizar

O tempo de resposta da aplicação é adequado

4 3

4

2 1

2 2 2

4 5

1 2

1 1 1 0 0 0 0 0 0 0 0 0 0

Nú

mer

o d

e In

qu

irid

os

Concordo totalmente Concordo Não concordo nem discordo Discordo Discordo totalmente


CAPÍTULO 6

Conclusões e Sugestões de Trabalho Futuro

6.1. Conclusões

Era objetivo da presente dissertação construir um sistema de gestão e

monitorização médica que, recorrendo a um equipamento de computação e

comunicação móvel, permitiria disponibilizar aos profissionais de saúde um método

eficaz de leitura e controlo, em tempo real, dos indicadores significativos do estado

clínico dos seus pacientes. Após todo o processo de desenvolvimento e avaliação,

apresentado ao longo dos últimos capítulos, é possível concluir que o objetivo

proposto foi alcançado.

O sistema construído e apresentado na dissertação não é independente ou

isolado, pois insere-se num projeto global de monitorização denominado MOHLL.

Trata-se pois de um segmento ou de uma parte de um todo, do qual não pode ser

dissociado e que teve direta influência sobre a grande maioria das opções tomadas, no

decurso do desenvolvimento. Implementar, através de uma plataforma móvel, um

método de interação com o sistema de monitorização MOHLL teve pois de basear-se

na estrutura organizacional de funcionamento deste. Não foi, no entanto,

menosprezada a recolha de informação que pudesse influenciar as opções tomadas.

Dentro do que era pretendido foi desenvolvida uma aplicação em C# para um

PDA Qtek 9090 com o sistema operativo Windows Mobile, que estabelece, através do

protocolo HTTP, uma ligação ao servidor do sistema e onde se encontra a base de

dados que contém todas as informações necessárias ao funcionamento da aplicação

móvel.

Mesmo tendo sido encontradas algumas contrariedades no processo de

desenvolvimento de representação gráfica, todas as funcionalidades de gestão e

monitorização, necessárias para interagir com os pacientes, sensores e sinais

fisiológicos recolhidos, foram construídas com sucesso. O trabalho de criação do

suporte à aplicação móvel desenvolvida, instalado no elemento servidor e que

influencia diretamente a eficiência do sistema, teve também um bom comportamento

durante a fase de avaliação da aplicação, não tendo sido detetada qualquer anomalia

Capítulo 6 – Conclusões e Sugestões de Trabalho Futuro


ou evento prejudicial à coerência dos dados trocados com a aplicação móvel.

Após a fase de desenvolvimento o trabalho desenvolvido foi sujeito a uma série

de testes e simulações, em ambiente hospitalar, durante as quais foi possível recolher,

juntos de vários profissionais de saúde, a sua opinião acerca do funcionamento e

usabilidade da aplicação. Aqui, mesmo tendo sido apontados fatores que poderiam

contribuir para a melhoria da aplicação, a conclusão geral é que o sistema proposto

cumpre corretamente as suas funções de monitorização dos sinais de ECG,

temperatura e batimento cardíaco, bem como permite de modo razoavelmente

prático fazer a gestão dos vários elementos do processo de monitorização.

6.2. Trabalho Futuro

Embora os resultados apresentados tenham ido ao encontro dos objetivos

propostos, existe ainda uma boa margem de progresso, não só para este tipo de

aplicação, como para os sistemas móveis de apoio médico.

Uma das funcionalidades que poderia ser incluída no projeto MOHLL, e que está

diretamente relacionado com os dispositivos pessoais e portáteis dos profissionais de

saúde, é a criação de um centro de monitorização automática dentro do computador

servidor, que seria responsável por enviar alertas, através de mensagens SMS, sempre

que fosse detetada uma situação que requeira a atenção de um profissional

especializado. Este sistema teria, no entanto, de ser eficaz ao ponto de conseguir

detetar os acontecimentos realmente importantes, distinguindo-os de outros com

influências externas, como por exemplo a má colocação de um sensor.

Outro dos aspetos com elevada relevância numa perspetiva de melhoramento

deste sistema de monitorização móvel seria desenvolver uma aplicação idêntica, mas

para sistemas operativos mais recentes e com maiores capacidades, como o Android e

o Windows Phone 7, que, para além de uma melhoria significativa das potencialidades

disponíveis, também serviriam para adequação a um maior número e variedade de

equipamentos atuais.

Visto alguns dos mais recentes equipamentos lançados no mercado trazerem já

suporte para aplicações Java embutido nos seus browsers, outra possibilidade de

evolução, seria conseguir criar uma versão móvel do site desenvolvido para um

browser de Internet.


Referências

[Ac10] Active ECG, http://www.activecenter.com/, checked 2010.

[Al10] Alive Tecnologies, http://www.alivetec.com/ , checked 2010.

[AN10] ANACOM, “Serviços Móveis: Informação Estatística 2.º Trimestre de 2010”,

2010.

[CaGoAl06] J. M. Cano-García, E. González-Parada, V. Alarcón-Collantes and E. Casilari-

Pérez, “A PDA-based portable wireless ECG monitor for medical personal area

networks”, IEEE MELECON, 2006.

[CaHe10] A. Carroll, G. Heiser, “An Analysis of Power Consumption in a Smartphone”,

NICTA and University of New South Wales, 2010.

[Car10] CardioNet, http://www.cardionet.com/ , checked 2010.

[EdC01] Ed Criscuolo, Keith Hogie and Ron Parise, ”Transport protocols and applications

for Internet use in space”, Aerospace Conference, IEEE Proceedings, 2001.

[FeAfCoSi10] H. Fernández-Lopez, J.A. Afonso, J.H. Correia, R. Simões, “HM4All: A Vital Signs

Monitoring System based in Spatially Distributed ZigBee Networks”, Pervasive

Computing Technologies for Healthcare (PervasiveHealth), 2010 4th

International Conference on-NO PERMISSIONS, 2010.

[FeAfSi11] Bruno Fernandes, José A. Afonso, Ricardo Simões, “Vital Signs Monitoring and

Management using Mobile Devices”, 6ª Conferência Ibérica de Sistemas e

Tecnologias de Informação CISTI, Universidade do Minho, 2011.

[FeGu05] R. Fensli, E. Gunnarson and T. Gundersen, ”A Wearable ECG-recording System

for Continuous Arrhythmia Monitoring in a Wireless Tele-Home-Care

Situation”, 18th IEEE International Symposium on Computer-Based Medical

Systems, 2005.

[FigDi04] M. V. M. Figueredo, J. S. Dias, “Mobile Telemedicine System for Home Care

and Patient Monitoring”, 26th Annual International Conference of the IEEE

EMBS, 2004.

[GoSiFa02] F. Gouaux, L. Simon-Chautemps, J. Fayn, “Ambient Intelligence and Pervasive

Systems for the Monitoring of Citizens at Cardiac Risk: New Solutions from The

EPI-MEDICS Project”, Computers in Cardiology vol. 29:289−292, 2002.

http://www.activecenter.com/

http://www.alivetec.com/

http://www.cardionet.com/

http://ieeexplore.ieee.org/xpl/mostRecentIssue.jsp?punumber=7416

Referências


[Gra09] P. Grant, “Complex communications - *comms modulation+”, Engineering &

Technology vol.4: 66-99, 2009.

[Gsm10] GSM Arena, “Qtek 9090”, http://www.gsmarena.com/qtek_9090-1171.php,

checked 2010.

[Hol10] Windsor Holden, “Mobile App Stores - Business Models, Strategies & Market

Segmentation 2010-2015”, Juniper Research, 2010.

[HW11] http://www.httpwatch.com/httpgallery/methods/default.aspx#example6b,

checked 2011.

[IE06] IEEE Computer Society, "IEEE Standard for Part 15.4: Wireless Medium Access

Control (MAC) and Physical Layer (PHY), Specifications for Low-Rate Wireless

Personal Area Networks (WPANs)", IEEE , 2006.

[IETF99] Internet Engineering Task Force, “Hypertext Transfer Protocol - HTTP/1.1”, RFC

2616, 1999.

[ITU10] International Telecommunication Union, “Measuring the Information Society

2010”, Genébra, 2010.

[Jur09] A. D. Jurik, “Biotelemetry and Body Sensors: Enabling ECG Monitoring”,

University of Virginia, 2009.

[JurWe08] A. D. Jurik and A. C. Weaver, "Remote Medical Monitoring", IEEE Computer,

vol. 41:96-99, 2008.

[KhWaNa08] P.Khanja, S.Wattanasirichaigoon , J.Natwichai, et al ,” A Web Base System for

ECG Data Transfered using ZigBee/IEEE Technology”, The 3rd International

Symposium on Biomedical Engineering, 2008.

[Ma09] A. Matos, “Desenvolvimento de um sensor de electrocardiograma compatível

com a tecnologia de redes sem fios ZigBee”, Tese de Mestrado em Engenharia

Biomédica, Universidade do Minho, 2009.

[MaFuWe04] D. Malan, T. Fulford-Jones, M. Welsh, S. Moulton, “CodeBlue: An Ad Hoc

Sensor Network Infrastructure for Emergency Medical Care”, the MobiSys

2004 Workshop on Applications of Mobile Embedded Systems, 2004.

[Mq10] MyQtek, “Qtek 9090 Specefications”,

http://www.myqtek.com/europe/products/9090/specifications.aspx, checked

2010.

http://www.juniperresearch.com/viewauthor.php?author=62

http://www.juniperresearch.com/viewpublisher.php?id=232&publisher=9

Referências


[NaIn10] National Instruments, “What Is a Wireless Sensor Network?”,

http://zone.ni.com/devzone/cda/tut/p/id/9895, checked 2010.

[NCF11] Microsoft MSDN, “.Net Compact Framework Architecture”,

http://msdn.microsoft.com/pt-pt/library/9s7k7ce5(v=VS.90).aspx, checked

2011.

[NF11] Microsoft MSDN, “.Net Framework Conceptual Overview”,

http://msdn.microsoft.com/library/zw4w595w.aspx, checked 2011.

[Pe09] D. Pereira, “Sistema de Monitorização Remota de Pacientes”, Tese de

Mestrado em Engenharia e Gestão de Sistemas de Informação, Universidade

do Minho, 2009.

[Phil10] Philips, "IntelliVue Telemetry System", 2007.

[RoDraGo04] J. Rodríguez, L. Dranca, A. Goñi and A. Illarramendi, “A Web Access to Data in a

Mobile ECG Monitoring System”, University of the Basque Country (UPV/EHU),

LSI Department, 2004.

[RoGoIl05] J.Rodriguez, A. Goni and A. Illarramendi, “Real-time classification of ECGs on a

PDA”, IEEE Transactions on Information Technology in Biomedicine, vol . 9:23-

34, 2005.

[RuFaNo05] P. Rubel, J. Fayn, G. Nollo, et al, “Toward personal eHealth in cardiology.

Results from the EPI-MEDICS telemedicine project”, Journal of

Electrocardiology, vol. 38:100–106, 2005.

[SaKah10] J. Sarashon-Kahn, “How Smartphones Are Changing Health Care Consumers

and Providers”, California Health Foundation, 2010.

[SecMob09] Secure Mobile Computing using Biotelemetrics,

http://www.cs.virginia.edu/~acw/SecureMobileComputing, checked 2010.

[TeBu10] Ted Burke, “Biomedical Engineering – ECG Assignment”,

http://eleceng.dit.ie/tburke/biomed/assignment1.html, checked 2010.

[Ubi10] UbiMon, http://www.ubimon.net/, checked 2010.

[VaHuCr10] N. Vallina-Rodriguez, P. Hui, J. Crowcroft, A. Rice, “Exhausting Battery Statistic -

Understanding the energy demands on mobile handsets”, MobiHeld 2010,

University of Cambridge, Deutsche Telekom Laboratories, 2010.

[Vit10] Vitaphone, http://www.vitaphone.de/en/home.html, checked 2010.

http://zone.ni.com/devzone/cda/tut/p/id/9895

http://msdn.microsoft.com/library/zw4w595w.aspx

http://www.cs.virginia.edu/~acw/SecureMobileComputing

http://eleceng.dit.ie/tburke/biomed/assignment1.html

http://www.ubimon.net/

http://www.vitaphone.de/en/home.html

Referências


[We05] Matt Welsh, “CodeBlue: A Wireless Sensor Network for Medical Care and

Disaster Response”, Harvard University, 2005.

[Zi08] ZigBee Standards Organization, “ZigBee Specification”, ZigBee Alliance

Document 053474r17, 2008.

Anexo I

Diagramas de Sequência

Protocolo de comunicações estabelecido na ligação do PDA aos Dados do

Sistema. Ligação do PDA ao servidor feita através do Servlet AAD (Aplicação de Acesso

aos Dados).

Comunicação para requisição de dados

Comunicação para inserção de dados

Comunicação para requisição de dados durante monitorização de pacientes

Anexo II

1. Inquérito (avalie as seguintes afirmações tendo em conta a sua experiência

durante a utilização da aplicação móvel de monitorização)

1

Discordo

Totalmente

2 3 4 5

Concordo

Totalmente

A visualização do ECG é

adequada

A visualização da

restante informação é

adequada

O menu de opções está

bem organizado

A aplicação é simples de

utilizar

O tempo de resposta da

aplicação é adequado

2. Perguntas

Considera que esta aplicação poderá ter utilidade no acompanhamento clínico de

pacientes não críticos?

Sim ____ Não ____ Não consigo avaliar ____

Se respondeu não à questão anterior indique os fatores pelos quais está reticente

quanto à utilidade desta aplicação.

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Teve dificuldades em utilizar alguma das funções disponíveis?

Sim ____ Não ____

Se respondeu sim à pergunta anterior quais foram essas funções e quais foram as

dificuldades sentidas.

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Quais as funcionalidades disponibilizadas pela aplicação que considera mais

relevantes?

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Críticas e sugestões quanto à possível melhoria da aplicação.

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

_______________________________________________________________________

Anexo III

bruno miguel vieira fernandes - universidade do...

Documents