66
ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos para o desenvolvimento de arquiteturas na medicina ub´ ıqua Trabalho Individual apresentado ao Programa de P´ os-Graduac ¸˜ ao em Computac ¸˜ ao da Uni- versidade Federal de Pelotas, como requisito parcial para a obtenc ¸˜ ao do grau de Mestre em Ciˆ encia da Computac ¸˜ ao Orientador: Prof. Dr. Adenauer C. Yamin Co-orientador: Profa. Dra. Ana Marilza Pernas Fleischmann Pelotas, 2013

Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

  • Upload
    trananh

  • View
    212

  • Download
    0

Embed Size (px)

Citation preview

Page 1: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

ALEXANDRE RENATO RODRIGUES DE SOUZA

Desafios e requisitos para o desenvolvimento de arquiteturasna medicina ubıqua

Trabalho Individual apresentado ao Programade Pos-Graduacao em Computacao da Uni-versidade Federal de Pelotas, como requisitoparcial para a obtencao do grau de Mestre emCiencia da Computacao

Orientador: Prof. Dr. Adenauer C. YaminCo-orientador: Profa. Dra. Ana Marilza Pernas Fleischmann

Pelotas, 2013

Page 2: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

Dados de catalogacao na fonte:Ubirajara Buddin Cruz – CRB-10/901Biblioteca de Ciencia & Tecnologia – UFPel

A999a Renato Rodrigues de Souza, Alexandre

Desafios e requisitos para o desenvolvimento de ar-quiteturas na medicina ubıqua / Alexandre Renato Rodri-gues de Souza. – Pelotas, 2013. – 66 f: graf. – TrabalhoIndividual (Mestrado) – Programa de Pos-Graduacao emComputacao. Universidade Federal de Pelotas. Centro deDesenvolvimento Tecnologico. Pelotas, 2013. – Orienta-dor Adenauer C. Yamin; Co-orientador Ana Marilza PernasFleischmann.

1. Medicina ubıqua. 2. Computacao ubıqua. 3. Alertasclınicos. 4. Aquisicao de sinais vitais. I. Yamin, AdenauerC.. II. Fleischmann, Ana Marilza Pernas. III. Tıtulo.

CDD: 999.9

Page 3: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

O valor das coisas nao esta no tempo em que elas duram, mas na intensidadecom que acontecem. Por isso existem momentos inesquecıveis, coisas

inexplicaveis e pessoas incomparaveis. — FERNANDO PESSOA

Page 4: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

RESUMO

RENATO RODRIGUES DE SOUZA, Alexandre. Desafios e requisitos para odesenvolvimento de arquiteturas na medicina ubıqua. 2013. 66 f. TrabalhoIndividual (Mestrado) – Programa de Pos-Graduacao em Computacao. Universi-dade Federal de Pelotas, Pelotas.

A computacao ubıqua tem por objetivo incorporar dispositivos computacio-nais no cotidiano das pessoas, de tal forma que a interacao entre os mesmosseja feita da maneira mais natural possıvel. Para isto, estes dispositivos precisaminterpretar as formas usuais de comunicacao dos usuarios e fazer a captura dosseus contextos de interesse. Uma grande melhoria viabilizada pela computacaoubıqua para os profissionais de saude e a possibilidade de lidar com diversasinformacoes simultaneamente de maneira ”calma”, operando na periferia de suapercepcao. Os pacientes, por sua vez, podem ser beneficiados com a reducaodos erros medicos e melhores resultados no tratamento da saude.

Neste trabalho sera apresentada uma revisao dos fundamentos teoricos dacomputacao ubıqua e suas aplicacoes na medicina. Tambem sao identificadasas pesquisas que estao sendo feitas sobre o desenvolvimento de arquiteturaspara ambientes de execucao em computacao ubıqua na area de medicina. Seraoapresentadas as tecnologias relacionadas a aquisicao de sinais vitais e os prin-cipais projetos de pesquisas referentes a este tema. Para finalizar, estao identifi-cados os principais desafios e requisitos para o desenvolvimento de arquiteturasna medicina ubıqua.

Pode-se concluir que a aquisicao de sinais vitais na area de medicina e muitopromissora. Porem estas aplicacoes ainda precisam atender a diversos desafios,tais como seguranca, privacidade, confiabilidade, normas e legislacoes, sensibi-lidade ao contexto, energia, mobilidade e facilidade de uso.

Como decorrencia do estudo realizado e proposto como trabalhos futuros aconcepcao e desenvolvimento de uma arquitetura de software para um ambi-ente ubıquo com aplicacao especıfica na geracao de alertas clınicos, os quaisserao baseados no contexto clınico do paciente. E proposto um sistema com-putacional que identifique alertas importantes que devam ser informados aosprofissionais de medicina, baseados na correlacao de dados do paciente, tera-pia de administracao de drogas e sinais vitais coletadas por equipamentos ele-tromedicos.

Palavras-chave: Medicina ubıqua, computacao ubıqua, alertas clınicos,aquisicao de sinais vitais.

Page 5: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

ABSTRACT

RENATO RODRIGUES DE SOUZA, Alexandre. Challenges and requirementsfor developing ubiquitous medicine architectures. 2013. 66 f. TrabalhoIndividual (Mestrado) – Programa de Pos-Graduacao em Computacao. Universi-dade Federal de Pelotas, Pelotas.

Ubiquitous computing aims to incorporate computing devices in daily life, suchthat the interaction between them is done in the most natural way possible. There-fore these devices need to interpret the usual forms of communication the usersand capture their contexts of interest. A major improvement made possible byubiquitous computing for health professionals is the ability to handle various infor-mation simultaneously in a ”calm” way, operating on the periphery of your aware-ness. Patients in turn, may be benefited by the reduction of medical errors andimproved outcomes in the management of health.

This paper present a review of the theoretical foundations of ubiquitous com-puting and its applications in medicine. It also identifies the research being doneon the development of architectures for environments running on ubiquitous com-puting in medicine. Will be presented the technologies related to the acquisitionof vital signs and major research projects related to this theme. To conclude areidentified the main challenges and requirements for developing architectures inubiquitous medicine.

It was concluded that the collected of vital signs is very promising. But theseapplications have yet to meet several challenges, such as security, privacy, relia-bility, norms and laws, context awareness, energy, mobility and user-friendliness.

As a result of the study is proposed as future work to design and developa software architecture for a ubiquitous environment with specific application togenerate clinical alerts, which will be based on the integration of the patient’sclinical context. It is proposed a computational system that identifies importantalerts that should be reported to health professionals, based on correlation of pa-tient data, drug therapy management and vital signs collected by electromedicalequipment.

Keywords: ubiquitous medicine, ubiquitous computing, clinical alerts, WirelessSensor Networks, remote health monitoring.

Page 6: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

LISTA DE FIGURAS

Figura 1 Arquitetura do Projeto Activity-based Computing (BARDRAM,2009; KROTH; AUGUSTIN, 2010) . . . . . . . . . . . . . . . . 22

Figura 2 Arquitetura do Projeto ClinicSpace (MACHADO; AUGUSTIN,2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23

Figura 3 Arquitetura do Projeto uMED (RODRIGUES et al., 2011) . . . 27Figura 4 Arquitetura do Projeto UbiDoctor (DINIZ; TRINTA, 2008) . . . . 28Figura 5 Arquitetura do modulo doUHSy (DINIZ; TRINTA, 2008) . . . . 29

Figura 6 Arquitetura de um no sensor (OLIVEIRA, 2011) . . . . . . . . . 34Figura 7 Arquitetura de uma WBAN (www.jneuroengrehab.com) . . . . 35Figura 8 Nike + iPod Sport Kit (www.apple.com/ipod/) . . . . . . . . . . 35Figura 9 Oxımetro de pulso portatil (www.lightinthebox.com) . . . . . . 37Figura 10 Eletrocardiograma (www.caepcampinas.com.br/e-infra-

eletro.asp) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37Figura 11 Medicao manual da frequencia cardıaca (www.adam.com/) . . 38Figura 12 Medicao de temperatura corporal (www.sciencephoto.com) . . 39Figura 13 Analisador de gases anestesicos (www.medicalexpo.es) . . . . 39Figura 14 Equipamento para medicao de Pressao Arterial Nao Invasiva

(www.futurvida.com) . . . . . . . . . . . . . . . . . . . . . . . . 40Figura 15 Arquitetura do projeto Codeblue (LORINCZ et al., 2004) . . . . 41Figura 16 Sensores sem fio desenvolvidos no projeto Codeblue (SHNAY-

DER et al., 2005) . . . . . . . . . . . . . . . . . . . . . . . . . . 42Figura 17 Interface de usuario do projeto Codeblue (SHNAYDER et al.,

2005). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43Figura 18 Arquitetura de servicos do MobiHealth (HALTEREN et al., 2004). 45Figura 19 Sensores e interface de usuario do MobiHealth

(www.mobihealth.com) . . . . . . . . . . . . . . . . . . . . . . 45Figura 20 Cenarios dos testes de prototipos de sensores de movimentos

usados no projeto UbiMon (VAN LAERHOVEN et al., 2004). . 47Figura 21 Arquitetura do projeto UbiMon (NG et al., 2004). . . . . . . . . 47Figura 22 Arquitetura do projeto AlarmNet (WOOD et al., 2006). . . . . . 49Figura 23 Telas de interface do usuario e de administracao do sistema

no projeto AlarmNet (A WOOD, 2008). . . . . . . . . . . . . . 49

Figura 24 Riscos para a privacidade do paciente (KUMAR; LEE, 2012). . 51

Page 7: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

LISTA DE ABREVIATURAS E SIGLAS

PDA - Personal Digital Assistant

GPRS - General Packet Radio Service

CAR - Circadian Activity Rhythm

ANVISA - Agencia Nacional de Vigilancia Sanitaria

PARC - Centro de Pesquisa da Xerox em Palo Alto

STF - Supremo Tribunal Federal

Wi-Fi - Wireless Fidelity

IEEE - Institute of Electrical and Electronics Engineers

ISM - Industrial, Scientific and Medical

IrDA - Infrared Data Association

SIR - Serial Infrared

MIR - Medium Infrared

FIR - Fast Infrared

VFIR - Very Fast Infrared

OCP - Organismo de Certificacao de Produtos

PDAs - Personal Digital Assistant

ABC - Activity-Based Computing

TI - Tecnologia da Informacao

ADCI - Activity-Driven Computing Infrastructure

EHS - Electronic Health System

SUS - Sistema Unico de Saude

UML - Unified Modeling Language

SMS - Short Message Service

UHSys - Ubiquitous Health System

PEP - Prontuario Eletronico do Paciente

RSSF - Rede de Sensores sem Fio

Page 8: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

WBAN - Wireless Body Area Network

BSN - Body Sensor Networks

BPM - Batimentos Por Minuto

ECG - Eletrocardiograma

PANI - Pressao Arterial Nao Invasiva

FC - Frequencia Cardıaca

FR - Frequencia Respiratoria

CO2 - Dioxido de carbono

PAI - Pressao Arterial Invasiva

EMG - Eletromiografia

AVC - Acidente Vascular Cerebral

MyoTel - Myofeedback based Teletreatment service

CAR - Circadian Activity Rhythm

ACK - Acknowledgement

Page 9: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

SUMARIO

1 INTRODUCAO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111.1 Tema . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121.2 Motivacao e Objetivo . . . . . . . . . . . . . . . . . . . . . . . . . . 121.3 Estrutura do Texto . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13

2 CONCEITOS EM COMPUTACAO UBIQUA . . . . . . . . . . . . . . . 152.1 Semantica siga-me . . . . . . . . . . . . . . . . . . . . . . . . . . . 152.2 Consciencia de contexto . . . . . . . . . . . . . . . . . . . . . . . . 152.3 Infraestrutura de comunicacoes em ambientes ubıquos . . . . . 162.4 Uso de frameworks na computacao ubıqua . . . . . . . . . . . . . 18

3 PROJETOS EM MEDICINA UBIQUA . . . . . . . . . . . . . . . . . . . 203.1 ABC (Activity-Based Computing): support for mobility and col-

laboration in ubiquitous computing . . . . . . . . . . . . . . . . . 203.2 ClinicSpace: modelagem de uma ferramenta piloto para

definicao de tarefas clınicas em um ambiente de computacao . 223.3 Pertmed: Sistema de Telemedicina Movel (disponibilizando a

informacao onde ela e necessaria) . . . . . . . . . . . . . . . . . . 243.4 uMed: Um Framework para o Gerenciamento de Aplicacoes Di-

recionadas a Medicina Ubıqua . . . . . . . . . . . . . . . . . . . . 253.5 UbiDoctor: Servico de Gerenciamento de Sessao para Ambien-

tes de Medicina Ubıqua . . . . . . . . . . . . . . . . . . . . . . . . . 27

4 PRINCIPAIS ERROS MEDICOS A SEREM CONSIDERADOS EM ME-DICINA UBIQUA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30

5 AQUISICAO DE SINAIS VITAIS . . . . . . . . . . . . . . . . . . . . . . 335.1 Tipos de sinais vitais . . . . . . . . . . . . . . . . . . . . . . . . . . 355.1.1 Oxımetria de pulso . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.2 Eletrocardiograma . . . . . . . . . . . . . . . . . . . . . . . . . . . 365.1.3 Frequencia cardıaca . . . . . . . . . . . . . . . . . . . . . . . . . . 375.1.4 Temperatura corporal . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.5 Gases respiratorios . . . . . . . . . . . . . . . . . . . . . . . . . . . 385.1.6 Frequencia respiratoria . . . . . . . . . . . . . . . . . . . . . . . . . 395.1.7 Pressao Arterial Nao Invasiva . . . . . . . . . . . . . . . . . . . . . 405.1.8 Pressao Arterial Invasiva . . . . . . . . . . . . . . . . . . . . . . . . 405.2 Projetos para aquisicao de sinais vitais . . . . . . . . . . . . . . . 415.2.1 CodeBlue . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41

Page 10: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

5.2.2 MobiHealth . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 435.2.3 UbiMon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 465.2.4 Alarm-Net . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47

6 DESAFIOS E REQUISITOS PARA O DESENVOLVIMENTO DE AR-QUITETURAS EM MEDICINA UBIQUA . . . . . . . . . . . . . . . . . . 50

6.1 Seguranca e privacidade . . . . . . . . . . . . . . . . . . . . . . . . 506.2 Confiabilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 526.3 Normas e legislacoes . . . . . . . . . . . . . . . . . . . . . . . . . . 526.4 Consciencia do contexto . . . . . . . . . . . . . . . . . . . . . . . . 536.5 Energia . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 536.6 Mobilidade . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.7 Facilidade de uso . . . . . . . . . . . . . . . . . . . . . . . . . . . . 546.8 Projeto de middlewares . . . . . . . . . . . . . . . . . . . . . . . . 55

7 CONSIDERACOES FINAIS E TRABALHOS FUTUROS . . . . . . . . 567.1 Trabalhos futuros . . . . . . . . . . . . . . . . . . . . . . . . . . . . 587.1.1 Proposicao de uma arquitetura de software para medicina ubıqua 58

REFERENCIAS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61

Page 11: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

1 INTRODUCAO

A computacao ubıqua tem como objetivo incorporar os dispositivos computa-cionais no cotidiano das pessoas, de tal forma que a interacao entre os mesmosseja feita da maneira o mais natural possıvel. Para isto, estes dispositivos preci-sam interpretar as formas usuais de comunicacao dos usuarios e fazer a capturados seus contextos de interesse. Um dos grandes benefıcios possibilitados pelacomputacao ubıqua para os profissionais de saude e a reducao da carga cogni-tiva na execucao das tarefas, trazendo maior satisfacao pelo trabalho e melhorqualidade de vida. Os pacientes, por sua vez, ganham com a reducao dos errosmedicos e melhores resultados no tratamento da saude.

O termo computacao ubıqua foi caracterizado em 1988 por Mark Weiser(1952-1999), quando o mesmo era o diretor de tecnologia do Centro de Pes-quisa da Xerox em Palo Alto (PARC). Weiser descreveu a computacao ubıquacomo sendo uma tecnologia que seria desenvolvida no futuro, onde computado-res estariam incorporados no cotidiano das pessoas, de tal forma que a interacaoentre os mesmos seria feita de maneira natural e imperceptıvel (WEISER, 1991).

A computacao ubıqua tambem e chamada de tecnologia tranquila (calmtecnhology ), inteligencia ambiente (inteligence ambient), computacao pro-ativa(proactive computing), internet das coisas (internet of things) e computacao in-visıvel (invisible computing) entre outras denominacoes. No entanto, os termoscomputacao pervasiva e computacao ubıqua sao os mais utilizados (YAMIN; AU-GUSTIN; FERREIRA, 2008).

Para se conseguir que a interacao entre os computadores e os humanos setorne natural, e necessario que este dispositivos interpretem as formas usuais decomunicacao dos humanos e facam a captura do contexto. Para isto os computa-dores deverao interpretar a fala, movimentos corporais (dedos, cabeca, bracos,entre outros), gestos, olhar e expressoes faciais. A captura do contexto se re-fere a possibilidade dos computadores terem seu comportamento adaptado deacordo com o ambiente, tendo portanto consciencia da localizacao e situacaoa que estiverem inseridos (YAMIN; AUGUSTIN; FERREIRA, 2008). Tambem e

Page 12: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

12

necessario que os dispositivos reconhecam-se uns aos outros e facam conexoesautomaticas entre si.

Devido a ubiquidade computacional, onde objetos corriqueiros tornam-se sis-temas de informacao, intensificou-se a preocupacao em reduzir o esforco ne-cessario para que os usuarios de sistemas computacionais possam acompa-nhar as inumeras informacoes disponıveis. Na tentativa de reduzir o esforcocognitivo para a percepcao das informacoes apresentadas, comecou-se a de-senvolver o conceito dos chamados Ambient Information Systems, onde estasinformacoes podem ser percebidas sem que os usuarios necessitem focar suaatencao para as mesmas (MANKOFF et al., 2002). Atraves destes sistemas asfontes de estımulos sensoriais ao nosso redor sao hierarquizadas, sendo queestas informacoes sao apresentadas de forma a privilegiar a periferia da atencaodos usuarios.

1.1 Tema

Este Trabalho Individual tem como tema a relacao entre a computacao ubıquae a medicina, apresentando conceitos, principais projetos, e, culminando comuma sumarizacao dos desafios e requisitos para o desenvolvimento de arquite-turas na medicina ubıqua.

1.2 Motivacao e Objetivo

A qualidade dos servicos prestados na area da saude no Brasil, princi-palmente em instituicoes publicas, e precaria. As instituicoes de saude nopaıs tem dificuldade de comportar a crescente demanda por este tipo deservico. Os resultados sao hospitais lotados, profissionais sobrecarregadose frequentes erros medicos. Segundo o Supremo Tribunal Federal (STF), onumero de denuncias de erros medicos cresceu 52,1% em 2011 em relacaoa 2010 (http://g1.globo.com/sp/campinas-regiao/noticia/2012/05/registros-de-erros-medicos-crescem-52-entre-os-anos-de-2010-e-2011.html).

O avanco tecnologico da comunicacao movel, da computacao embarcada eminiaturizacao dos dispositivos e sensores eletronicos estao gerando significa-tivos progressos ao desenvolvimento de aplicacoes na area medica, permitindoa otimizacao da prestacao de servicos aos profissionais de saude (CASSIANI;GIMENES; MONZANI, 2009). O aprimoramento da comunicacao sem fio (wire-less) expandiu as possibilidades de aquisicao de sinais vitais de forma remota,ampliando a mobilidade dos profissionais de saude. A miniaturizacao de disposi-tivos eletronicos moveis, a maior eficiencia de baterias e a reducao de consumo

Page 13: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

13

de energia dos semicondutores potencializaram o desenvolvimento de inumerassolucoes inovadoras atraves da computacao ubıqua.

Os profissionais de saude que trabalham no ambiente hospitalar possuemuma rotina onde e essencial a mobilidade. Um importante desafio na me-lhoria dos servicos prestados nestes ambientes esta na disponibilizacao dasinformacoes geradas pelos equipamentos medicos sem prejuızo da mobilidadee sem implicar necessariamente em estresse devido ao aumento das fontes deinformacoes. Uma grande melhoria viabilizada pela computacao ubıqua paraos profissionais de saude e a possibilidade de lidar com diversas informacoessimultaneamente de maneira ”calma”, operando na periferia de sua percepcao(RODRIGUES et al., 2011). Os pacientes, por sua vez, podem ser beneficia-dos com a reducao dos erros medicos e melhores resultados no tratamento dasaude.

Para preservar a mobilidade dos profissionais de saude, pode-se desenvol-ver aplicacoes utilizando a abordagem siga-me (follow me) (AUGUSTIN; YAMIN;GEYER, 2005), a qual permite com que as informacoes geradas pelos equi-pamentos medicos sigam os operadores, acompanhando o seu deslocamentoatraves de dispositivos moveis. Conforme a localizacao destes dispositivos sealtera, e necessaria a adaptacao automatica de suas configuracoes de acordocom as alteracoes da rede de acesso as informacoes. Aplicacoes que utilizama semantica siga-me tambem consideram os perfis, preferencias e as alteracoesde contexto oriundas do deslocamento dos profissionais de saude.

Diversas pesquisas tem sido feitas com o objetivo de desenvolver arquiteturasde software que otimizem a rotina dos profissionais de saude aplicando conceitosda computacao ubıqua. Como resultado de uma revisao inicial do estado da arte,diversos destes trabalhos foram revisados com o objetivo de identificar as suascaracterısticas. Neste texto estao apresentados alguns dos projetos relacionadoscom o tema de pesquisa que se objetiva desenvolver durante o mestrado.

Os objetivos deste trabalho consistem em: (i) sistematizar os fundamentosteoricos da computacao ubıqua e suas aplicacoes na medicina, (ii) identificar aspesquisas que estao sendo feitas sobre o desenvolvimento de arquiteturas paraambientes de execucao em computacao ubıqua na area da medicina, (iii) su-marizar as tecnologias relacionadas a aquisicao de sinais vitais e os principaisprojetos de pesquisas referentes a este tema e, (iv) identificar os principais de-safios e requisitos para o desenvolvimento de arquiteturas na medicina ubıqua.

1.3 Estrutura do Texto

O texto e composto por 7 capıtulos.

Page 14: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

14

No capıtulo 1 e abordado o tema do trabalho, objetivos e a motivacao parasua escolha.

No capıtulo 2 sao tratados os conceitos em computacao ubıqua, apresen-tando usas definicoes e infraestruturas necessarias.

O capıtulo 3 apresenta alguns projetos de pesquisa na area da medicina.No capıtulo 4 sao apresentados os principais erros medicos a serem consi-

derados em projetos de medicina ubıqua.No capıtulo 5 aborda o uso da computacao ubıqua na area da medicina, con-

siderando suas principais aplicacoes, tipos de sinais vitais e os trabalhos relaci-onados com a aquisicao de sinais vitais.

Os principais desafios e requisitos para o desenvolvimento de arquiteturas namedicina ubıqua sao discutidos no capıtulo 6.

No capıtulo 7 sao apresentadas as consideracoes finais e trabalhos futuros.

Page 15: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

2 CONCEITOS EM COMPUTACAO UBIQUA

O termo computacao ubıqua e definido com sendo a tecnologia em que oscomputadores sao incorporados no cotidiano das pessoas, de tal forma que ainteracao entre os mesmos seja feita de maneira natural e imperceptıvel (WEI-SER, 1991). Para isto e necessario que as aplicacoes sejam sensıveis ao con-texto e utilizem a semantica siga-me para acompanhar o deslocamento do ope-rador.

2.1 Semantica siga-me

As aplicacoes ubıquas consideram a mobilidade fısica (dispositivos eusuarios) e logica (componentes da aplicacao e servicos). Devido a estas carac-terısticas, as aplicacoes deverao possuir suporte a conexoes de rede que podemocorrer de qualquer posicao geografica (usuarios nomades). Deve-se tambemlevar em consideracao que estas conexoes possuem comunicacao intermitente,ja que, devido as condicoes operacionais do ambiente movel, e comum que ocor-ram desconexoes frequentes (YAMIN, 2004).

A semantica siga-me (follow me applications) permite que o usuario acesseseu ambiente computacional de qualquer localizacao, momento ou meio deacesso, de forma transparente (AUGUSTIN; YAMIN; GEYER, 2005). Portanto,independente onde o usuario estiver e mesmo em movimento, podera executarsuas aplicacoes atraves de um ambiente virtual. O codigo destas aplicacoes saoenviados sob demanda e acessados independentemente do dispositivo compu-tacional que o usuario estiver usando (YAMIN, 2004).

2.2 Consciencia de contexto

Segundo Anind K. Dey (DEY, 2000), “Contexto e qualquer informacao quepode ser usada para caracterizar uma situacao de uma entidade. Uma enti-dade e uma pessoa, um lugar, ou um objeto que e considerado relevante paraa interacao entre um usuario e uma aplicacao, incluindo o proprio usuario e a

Page 16: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

16

propria aplicacao”.A consciencia de contexto (context-aware) e uma tecnologia baseada em

informacoes contextuais com o objetivo de apresentar dados relevantes aosusuarios de sistemas computacionais. Alguns exemplos de informacoes con-textuais sao: localizacao e identificacao do usuario, tipo de dispositivo com-putacional que esta sendo usado, pessoas proximas, horario, entre outros. Aconsciencia de contexto permite que as aplicacoes se adaptem conforme asituacao que estao inseridas, personalizando-se automaticamente para obter omelhor resultado possıvel. Este recurso reduz a sobrecarga de informacoes,mostrando ao usuario somente o que e relevante (MORAES; SOUZA; PRADO,2009).

Atraves da consciencia de contexto a aplicacao fornece informacoes rele-vantes a cada situacao ou atividade a qual o usuario se encontra, diminuindosua carga cognitiva pela reducao da necessidade constante de atencao eintervencoes.

Alguns dos desafios para desenvolvimento de uma aplicacao com suporte aconsciencia de contexto sao (VENECIAN, 2010):

• caracterizacao dos elementos de contexto para uso na aplicacao;

• aquisicao do contexto a partir de fontes heterogeneas, tais como sensoresfısicos, base de dados, agentes e aplicacoes;

• representacao de um modelo semantico formal de contexto;

• processamento e interpretacao das informacoes de contexto adquiridas;

• disseminacao do contexto a entidades interessadas de forma distribuıda eno momento oportuno;

• tratamento da qualidade da informacao contextual.

2.3 Infraestrutura de comunicacoes em ambientes ubıquos

Como visto anteriormente, a computacao ubıqua exige a comunicacao otempo todo e em qualquer lugar, tornando a conectividade um aspecto chavedeste conceito. O rapido avanco nas tecnologias de comunicacao sem fio,tambem conhecidas pelo anglicismo wireless, tem trazido diversas oportunida-des para ampliar a conectividade e colocar a ubiquidade em pratica.

Pode-se classificar as tecnologias de rede sem fios em tres grandes classes:curta, media e longa distancia. Os sistemas de computacao ubıqua sao estru-turados atraves destas classes de rede, possibilitando assim a conectividade aqualquer distancia (ARAUJO, 2003).

Page 17: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

17

As redes de longa distancia sao utilizadas pelos servicos de comunicacaopessoal. As redes dos sistemas celulares que operam em bandas de altafrequencia fazem parte desta classe.

As redes de curta e media distancia (tais como o Bluetooth, ZigBee e Wi-Fi)foram desenvolvidas para permitir a conectividade entre dispositivos de formainvisıvel ao usuario. Este tipo de classe e usado por exemplo para a comunicacaosem fio entre um computador e seus perifericos (impressora, mouse, teclado,entre outros), reduzindo assim o grande numero de cabos.

A seguir estao descritas algumas das principais tecnologias de redes usadasatualmente que suportam a conectividade entre dispositivos:

• Wi-Fi (802.11) - A tecnologia Wi-Fi (Wireless Fidelity ), desenvolvida pelaIEEE (Institute of Electrical and Electronics Engineers), foi rapidamenteaceita como solucao para redes corporativas sem fio. A Wi-Fi utiliza a faixade frequencia ISM de 2,45 GHz, possui alcance de ate 300 metros (podeser maior em areas abertas) e possui taxas de transmissao de dados su-periores a 54 Mbps.

• Bluetooth - A tecnologia Bluetooth foi desenvolvida a partir do ano de 1998atraves da parceria entre a Ericsson, Intel, Toshiba, Nokia e IBM com oobjetivo de especificar um padrao mundial aberto para a conexao sem fioentre dispositivos de telecomunicacoes e de computacao. A comunicacaopode ser feita com dois ou mais dispositivos atraves da faixa de frequenciaISM 1. A comunicacao e onidirecional, suporta transmissoes sıncronas eassıncronas, aceita taxas de transferencia de dados de ate 1 Mbps e possuium alcance de 10 m (ARAUJO, 2003).

• IrDA (Infravermelho) - A tecnologia IrDA (Infrared Data Association) su-porta apenas conexoes ponto-a-ponto a distancias menores que 1 m, comvelocidades de ate 16 Mbps. O angulo de visao entre o transmissor e o re-ceptor e de 30 graus). A comunicacao deve ser feita atraves de uma linhadireta de visao, sem obstaculos, pois os raios infravermelhos nao atraves-sam objetos (ARAUJO, 2003). Foram desenvolvidos varios tipos de IrDA,tais como: SIR (Serial Infrared): padrao original, velocidade de 115 Kbps;MIR (Medium Infrared): velocidade de 1.152 Mbps, nao foi implementadoamplamente; FIR (Fast Infrared): velocidades de ate 4 Mbps, utilizado na

1ISM (Industrial, Scientific and Medical), que e a banda de radiofrequencia situada na faixaentre 2,4000 GHz a 2,4835 GHz). Os equipamentos que funcionam na banda ISM nao dependemde licencas para operacao, mas compartilham seu uso com outros dispositivos de comunicacaonao compatıveis com a tecnologia Bluetooth, tais como portoes automaticos, babas eletronicase telefones sem fio.

Page 18: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

18

maioria dos novos computadores; VFIR (Very Fast Infrared): velocidadesde ate 16 Mbps, ainda nao implementado amplamente.

• Zigbee - O seu protocolo base foi desenvolvido pela Zigbee Alliance paraoperar na banda ISM. A faixa de frequencia de operacao varia conforme opaıs onde for usada. O Zigbee possui baixo consumo de energia (a bateriade um nodo pode durar meses ou ate mesmo anos), ja que permite queos dispositivos entrem em estado de repouso (sleep) quando nao estao emoperacao. Tambem possui como caracterıstica a alta flexibilidade e a pos-sibilidade do uso de ate 65000 nos na rede. Segundo (SILVA MARQUES,2010), esta tecnologia possui um papel importante para o desenvolvimentode ambientes inteligentes, pois possui um baixo custo de implementacao,baixa complexidade, baixo consumo de energia, alta confiabilidade e auto-suficiencia.

2.4 Uso de frameworks na computacao ubıqua

Existem diversos projetos de frameworks para aplicacoes em computacaoubıqua. Neste secao sera definido o conceito de frameworks, suas carac-terısticas, benefıcios e principais desafios de desenvolvimento.

Frameworks sao codigos reutilizaveis de uma parte ou de todo um sistema desoftware. Estes codigos sao descritos por um conjunto de classes abstratas. Oprojeto de software e normalmente composto de componentes e conexoes paraque as instancias destas classes colaborem entre si (JOHNSON; FOOTE, 1988).O frameworks e portanto uma aplicacao praticamente completa, onde o progra-mador ira desenvolver os codigos especıficos para a sua aplicacao. As classessao abstratas porque nao possuem implementacao, pois serao completadas paracada aplicacao especıfica que sera desenvolvida (ERICH GAMMA, 2003).

O uso de frameworks pode reduzir significativamente o custo de desenvol-vimento de um software, ja que grande parte do codigo ja foi desenvolvido esera reutilizado para o desenvolvimento da nova aplicacao. O esforco para odesenvolvimento de novas aplicacoes e reduzido, ja que somente serao criadoscodigos para atender as particularidades destes novos softwares.

Os frameworks usam programacao orientada a objetos e reunem codigos ebibliotecas de diversas linguagens em um ambiente unico. Isto torna possıvel ouso da linguagem de programacao mais adequada para a funcionalidade dese-jada. A arquitetura criada e flexıvel e expansıvel, com o objetivo de criar solucoespara problemas comuns.

Os frameworks trazem diversas vantagens no processo de desenvolvimentode codigos de software, tais como maior produtividade, padronizacao, reducao

Page 19: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

19

no custo de desenvolvimento de novas aplicacoes, reducao do tempo paralancamento de novas aplicacoes (time-to-market), menos erros de software de-vido ao uso em varias aplicacoes (os bugs foram descobertos e corrigidos ante-riormente), maior compatibilidade e consistencia entre aplicacoes, entre outros.

Entre os grandes desafios do desenvolvimento de frameworks esta a maiorcomplexidade em seu projeto e codificacao, a reusabilidade do codigo deve sermuito bem planejada e os benefıcios de sua criacao vem a longo prazo. Parao seu desenvolvimento e necessario vasta experiencia no uso de boas praticasde codificacao e documentacao de software, sendo requisito basico uma equipealtamente qualificada.

Devido ao contınuo desenvolvimento de dispositivos moveis, atualmente po-demos encontrar uma grande variedade de modelos deste tipo de equipamentos.Como a maior parte dos recursos disponıveis nestes dispositivos sao semelhan-tes, a maior parte dos codigos criados para um modelo pode ser usado em di-versos outros. O uso de frameworks no desenvolvimento das aplicacoes reduzsignificativamente o trabalho necessario para a criacao destes softwares, poisgrande parte dos codigos podem ser reaproveitados de outros projetos.

Page 20: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

3 PROJETOS EM MEDICINA UBIQUA

Diversas pesquisas tem sido feitas com o objetivo de desenvolver arquiteturasde software para otimizar a rotina dos profissionais de saude utilizando os con-ceitos de computacao ubıqua. A seguir estao apresentados alguns dos projetosrelacionados com o tema.

3.1 ABC (Activity-Based Computing): support for mobilityand collaboration in ubiquitous computing

O ABC (Activity-Based Computing) (BARDRAM, 2005; BARDRAM; CHRIS-TENSEN; OLSEN, 2002; BARDRAM; CHRISTENSEN, 2007; BARDRAM, 2009)e um projeto de computacao ubıqua para apoio a mobilidade e colaboracao nasatividades de trabalho humano atraves do desenvolvimento de um framework.O projeto foi iniciado em 2001 pela Universidade de Aarhus em parceria comUniversidade de TI de Copenhague, contando tambem com o apoio do HospitalRegional de Horsens.

Os principais objetivos do projeto ABC sao:

• dar suporte as atividades humanas atraves do gerenciamento de tarefascom o auxılio da computacao;

• dar suporte a mobilidade atraves da distribuicao de atividades em ambien-tes de computacao heterogeneos (desktop PC, tablet, notebook, PDA, telaou projecao na parede de uma sala de cirurgia);

• permitir a colaboracao assıncrona possibilitando que varias pessoas parti-cipem de uma mesma atividade;

• dar suporte a atividades sıncronas para colaboracao em tempo real atravesde compartilhamento por diversos clientes.

Atraves do framework desenvolvido e possıvel que as atividades sejam inter-rompidas e retomadas posteriormente com seu estado anterior totalmente recu-

Page 21: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

21

perado, mesmo que o local seja diferente ou o dispositivo de computacao usadoseja outro. O sistema permite que todas as aplicacoes e recursos associadoscom as atividades sejam restaurados automaticamente quando uma atividadee retomada, otimizando consideravelmente a rotina clınica. Este suporte a per-sistencia atende a necessidade de mobilidade, que e um dos principais requisitosdas rotinas clınicas em hospitais.

A ideia central deste projeto e o desenvolvimento de aplicacoes para otimizara rotina dos profissionais de saude, considerando os aspectos inerentes a pro-fissao. Para isto foram construıdos varios cenarios do ambiente hospitalar, ba-seados nas rotinas dos medicos e enfermeiros. Esta trabalho foi realizado paraidentificar modelos de atividades, permitindo assim desenvolver uma aplicacaopara reconhecimento de contexto.

As principais atividades identificadas se referem aos seguintes cenarios:

• busca de medicamentos na farmacia do hospital, administracao e controlede medicamentos (realizadas por enfermeiros);

• prescricoes de medicamentos (realizadas por medicos), baseadas em re-sultados de exames e discussao com outros profissionais de saude sobredosagens e tipos de drogas;

• colaboracao;

• videonferencias para consultas e diagnosticos;

• conversas com os paciente para explicar diagnosticos e tratamentos;

• cirurgias.

A arquitetura desenvolvida utiliza o conceito de infra-estrutura de computacaoguiada por atividades (ADCI - Activity-Driven Computing Infrastructure). O mo-nitoramento das atividades de rotina do ambiente hospitalar e do contexto dousuario permitem a descoberta das atividades executadas pelo clınico, o quepossibilita que o sistema atue de forma pro-ativa. Isto permite que sejam exe-cutadas de forma automatica aplicacoes baseadas na atividade e contexto dousuario, reduzindo desta forma o tempo gasto caso fosse necessario navegarem uma interface (menu) com diversas opcoes.

Os usuarios e recursos sao identificados e localizados atraves de dispositivosde radio-frequencia disponıveis no ambiente hospitalar.

O sistema desenvolvido permite que todos os recursos digitais (resultados deexames laboratoriais, imagens para diagnosticos, registros medicos) necessariospara a realizacao de uma atividade relacionada com um determinado pacientesejam organizados e agrupados logicamente.

Page 22: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

22

A Figura 1 apresenta a arquitetura do projeto ABC, o qual foi estruturado nasseguintes camadas:

• Infraestrutura: realiza o gerenciamento das atividades colaborativas e dis-tribuıdas atraves da adaptacao dos recursos ou servicos disponıveis emum determinado ambiente computacional;

• Cliente: gerencia a atividade em um dispositivo especıfico;

• Aplicacao: possui rotinas e padroes para a utilizacao dos servicos dis-ponıveis na arquitetura do cliente.

Figura 1: Arquitetura do Projeto Activity-based Computing (BARDRAM, 2009;KROTH; AUGUSTIN, 2010)

3.2 ClinicSpace: modelagem de uma ferramenta pilotopara definicao de tarefas clınicas em um ambiente decomputacao

O projeto ClinicSpace (SILVA, 2009; FERREIRA et al., 2009) tem como obje-tivo adaptar um middleware para gerenciamento de atividades clınicas atraves dacomputacao ubıqua. Esta sendo desenvolvido na Universidade Federal de SantaMaria pelo Grupo de Sistemas de Computacao Movel (GMob). O ClinicSpace eum Sistema Eletronico de Saude (EHS - Electronic Health System) cuja arqui-tetura foi desenvolvida com o objetivo de atender aos requisitos dos medicos,diminuindo assim a frequente rejeicao na implantacao deste tipo de sistema noambiente hospitalar. O sistema disponibiliza um assistente para ajudar os pro-fissionais de saude a executar suas atividades, usando para isto a computacaoorientada a atividades.

Page 23: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

23

Figura 2: Arquitetura do Projeto ClinicSpace (MACHADO; AUGUSTIN, 2011)

O projeto usa a captura de contexto para reduzir a complexidade do sis-tema para os profissionais de saude. Os elementos de contexto processadossao tempo, recursos, perfil, paciente, localizacao dispositivos e sensores. Asinformacoes do ambiente clınico sao capturadas e integradas automaticamenteas aplicacoes do sistema computacional, tornando os servicos prestados aospacientes mais otimizados e com melhor qualidade (FERREIRA et al., 2009).

A arquitetura tambem permite a personalizacao no modo como cada usuarioexecuta as atividades, aumentando assim a aderencia do sistema automatizadono ambiente hospitalar com o objetivo de aumentar a sua aceitacao.

A Figura 2 apresenta a arquitetura do projeto ClinicSpace, o qual foi estrutu-rado nos seguintes nıveis:

• Nıvel superior: operador do sistema (profissional de saude) que gerenciasuas tarefas a serem executadas no ambiente ubıquo;

• Nıvel intermediario: responsavel pelo mapeamento e gerenciamento dastarefas definidas pelo operador e subtarefas (aplicacoes uıquas);

• Nıvel inferior: responsavel pela execucao das aplicacoes e gerenciamentodo ambiente ubıquo atraves do middleware EXEHDA (YAMIN, 2004).

A seguir estao descritas o significado das abreviacoes usadas para identificaros componentes da arquitetura:

• IETC: Interface de Edicao de Tarefas e Contexto

• SGDT: Subsistema de Gerenciamento Distribuıdo de Tarefas;

Page 24: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

24

• SGT: Servico de Gerenciamento de Tarefas;

• SAT: Servico de Acesso a Tarefas;

• SCT: Servico de Contexto de Tarefas

• pEHS: pervasive Electronic Health System.

Como diferencial em relacao a outros projetos semelhantes, o ClinicSpacee arquitetado com foco nos profissionais de saude que serao os usuarios dosistema, permitindo que os mesmos personalizem as suas tarefas. O sistemadesenvolvido permite que os usuarios facam um balanceamento entre automati-zar e controlar a execucao das tarefas, disponibilizando recursos como agenda-mento, execucao, interrupcao, continuacao e cancelamento de atividades. O pro-jeto tambem implementa a semantica siga-me, permitindo que as tarefas acom-panhem o usuario mesmo que ele troque de dispositivo computacional.

3.3 Pertmed: Sistema de Telemedicina Movel (disponibili-zando a informacao onde ela e necessaria)

O projeto Pertmed (RODRIGUES, 2011) tem como objetivo cientıfico avaliaro uso na area de saude de algumas das tecnologias desenvolvidas pelas pes-quisas em computacao ubıqua, atendendo dessa forma a necessidade de mo-bilidade dos profissionais que atuam no ambiente hospitalar. O sistema a serdesenvolvido fara a conexao entre dispositivos moveis e o sistema informatizadode acesso as informacoes clınicas do hospital, possibilitando assim que os pro-fissionais de saude tenham acesso as mesmas de forma ubıqua.

O Pertmed esta sendo desenvolvido atraves da parceria entre grupos depesquisa da Universidade Federal de Santa Maria (Grupo de Sistemas deComputacao Movel - GMob), Universidade Catolica de Pelotas e UniversidadeFederal de Pelotas (Grupo de Processamento Paralelo e Distribuıdos - G3PD).

O projeto tem como premissa a colaboracao dos profissionais de saude doshospitais universitarios destas instituicoes, os quais serao responsaveis por de-terminar os requisitos do sistema a ser desenvolvido. Estes profissionais tambemcontribuirao para a identificacao de caracterısticas e funcionalidades, analise eadequacao do projeto a rotina hospitalar. Alem do atendimento as necessidadedestes dois hospitais, o sistema tem como meta a generalizacao da solucao parao atendimento aos requisitos da rede SUS (Sistema Unico de Saude), onde po-dera ser utilizado amplamente.

O Pertmed busca viabilizar o atendimento a lugares remotos e carentes, ondeha falta de servicos de saude especializados devido ao alto custo de transporte.

Page 25: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

25

Isto seria viabilizado atraves do acesso ao estado de saude do paciente atravesde monitoramento remoto. Simples orientacoes clınicas poderiam ser enviadasdiretamente aos celulares dos pacientes. Desta forma o projeto contribuira coma reducao na fragmentacao e interrupcao de tratamentos devido a dificuldade deacesso aos servicos de saude.

O sistema esta sendo desenvolvido na plataforma Java, utilizando diagramasUML (Unified Modeling Language) e programacao orientada a objetos. O geren-ciamento do ambiente ubıquo e feito atraves do middleware EXEHDA (YAMIN,2004).

Este projeto pretende disponibilizar informacoes de saude (tais como resul-tados de exames laboratoriais e registros de pacientes) aos medicos e enfer-meiros sempre que necessarias, baseadas em contexto, independentemente dolocal onde se encontram, a qualquer momento e de qualquer dispositivo (acessoubıquo).

De acordo com a proposta do projeto, para se ter qualidade nos servicosprestados na area da saude, e necessario que os profissionais tenham acessorapido as informacoes clınicas dos pacientes, permitindo assim que os mesmostomem decisoes rapidas. Estas informacoes podem ser acessadas pelos profis-sionais de saude atraves da internet e dispositivos moveis, tais como smartpho-nes, telefones celulares e PDAs. O sistema tambem disponibiliza o trafego deinformacoes entre os profissionais de saude e os pacientes.

3.4 uMed: Um Framework para o Gerenciamento deAplicacoes Direcionadas a Medicina Ubıqua

O projeto uMED e uma arquitetura para desenvolvimento de software direci-onada a medicina ubıqua (RODRIGUES, 2011; RODRIGUES et al., 2011), con-cebido como parte dos esforcos de pesquisa do projeto PERTMED. O uMED foidesenvolvido no Grupo de Pesquisa em Processamento Paralelo e Distribuıdo(G3PD) da Universidade Catolica de Pelotas (UCPel).

Este projeto permite o monitoramento remoto dos sinais vitais de pacientesinternados em um ambiente hospitalar. O sistema pode emitir alertas clınicosatraves da captura de informacoes contextuais. Os alertas sao baseados emregras criadas pelos profissionais de saude, sendo possıvel altera-las a qualquermomento.

O uMED permite aos clınicos monitorar e controlar remotamente dispositivose equipamentos eletromedicos (tais como ventiladores pulmonar e bombas deinfusao) com o objetivo de otimizar a rotina clınica dos profissionais de saude.Os dispositivos podem ser para controle ambiental, como por exemplo alarmes,

Page 26: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

26

luzes de sinalizacao, aquecedores e umidificadores. Atraves deste frameworkos equipamentos e dispositivos do ambiente ubıquo podem ser configurados,acionados ou desligados.

O uMED foi desenvolvido com a premissa de ser integrado ao middlewareEXEHDA (YAMIN, 2004), empregando suas funcionalidades de reconhecimentoe adaptacao de contexto. Seu objetivo principal e melhorar a mobilidade dos pro-fissionais de saude atraves do fornecimento de servicos de saude, com acessoindependente do tempo e localizacao. O framework propoe uma infraestruturapara integracao de sensores e dispositivos computacionais moveis e fixos nomeio hospitalar, disponibilizando servicos com consciencia ao contexto atravesde um ambiente ubıquo.

A Figura 3 apresenta a arquitetura do projeto uMED, o qual foi estruturadonos seguintes modulos:

• Gerente de Atuacao: permitem controlar (ligar, desligar e configurar) osatuadores do ambiente ubıquo de forma manual (atraves do operador) ouautomatica (atraves do servidor de contexto);

• Gerente de Aplicacoes: fornece ao usuario as aplicacoes disponibilizadaspelo framework : emissao de alertas aos profissionais de saude baseadosno monitoramento de sinais vitais, acionamento imediato e configuracaodos atuadores e elaboracao de relatorios personalizados;

• Gerente de Borda: realiza o primeiro processamento dos sinais aquisita-dos pelos sensores e faz o tratamento dos dados para acionamento dosatuadores;

• Gerente de Comunicacao: responsavel por enviar mensagens denotificacao aos clınicos, pacientes e familiares atraves de mensagems SMS(Short Message Service), Google Talk e e-mail;

• Servidor de Contexto: realiza o processamento de informacoes de con-texto atraves do suporte semantico.

Como diferencial frente a outros projetos, o uMED possui a possibilidadede geracao de relatorios personalizados pelos usuarios para estudo de casosclınicos e a criacao de regras para inclusao e exclusao de atuadores e sensores,de maneira que as caracterısticas dos mesmos possam ser abstraıdas.

Page 27: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

27

Figura 3: Arquitetura do Projeto uMED (RODRIGUES et al., 2011)

3.5 UbiDoctor: Servico de Gerenciamento de Sessao paraAmbientes de Medicina Ubıqua

O projeto UbiDoctor (DINIZ; TRINTA, 2008) e um middleware, desenvol-vido na Universidade Federal de Pernambuco (UFPE), proposto para fornecerservicos de medicina ubıqua com o objetivo de melhorar a produtividade dos pro-fissionais de saude. Atraves desta arquitetura estes profissionais podem acessarde forma ubıqua os dados pessoais e casos clınicos de pacientes, visualizar pa-receres clınicos anteriores e solicitar segunda opiniao a outros medicos.

O UbiDoctor considera a necessidade de atendimento a premissas tais comoa interacao entre os profissionais de saude para troca de informacoes e opinioes

Page 28: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

28

clınicas, suporte a mobilidade dos usuarios (caracterıstica inerente ao ambientehospitalar), necessidade de acesso as informacoes de saude do paciente atravesde diversos tipos de dispositivos computacionais, nomadismo e interrupcoesconstantes da execucao de atividades.

A Figura 4 apresenta a arquitetura do middleware UbiDoctor, o qual foi estru-turado nos seguintes servicos:

• Servico de Gerenciamento de Contexto: encarregado de examinar osdados contextuais e enviar aos demais servicos atraves de variaveis decontexto;

• Servico de Gerenciamento de Sessoes: disponibiliza a manutencao epersistencia das sessoes e a migracao de aplicacoes;

• Servico de Adaptacao de Conteudo: faz a adequacao das informacoes aserem apresentadas ao usuario considerando a abrangencia da rede e ascaracterısticas e configuracoes do dispositivo computacional usado.

Figura 4: Arquitetura do Projeto UbiDoctor (DINIZ; TRINTA, 2008)

Com o objetivo de realizacao de testes foram implementados os servicos degerenciamento de contexto, gerenciamento de sessao e adaptacao de conteudodo middleware UbiDoctor. Tambem foi desenvolvida uma aplicacao prototipochamada de UHSys (Ubiquitous Health System) para uso destes servicos. OUHSys possibilita aos profissionais clınicos acessarem um sistema de ProntuarioEletronico do Paciente (PEP), permitindo que o mesmo seja utilizado a qual-quer momento (anytime), de qualquer lugar (anywhere) e em qualquer disposi-tivo computacional (any device). O sistema tambem permite que os profissionaisde saude solicitem e atendam a pedidos de segunda opiniao medica.

Page 29: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

29

Atraves da arquitetura desenvolvida, o medico pode fazer a migracao de umaatividade em execucao para outro tipo de dispositivo computacional, no qual a ta-refa continuara a ser executada. Atraves do servico de gerenciamento de sessaoesta troca e feita com a persistencia do conteudo assegurada. Dependendo dostipos de dispositivos usados, o ajuste do conteudo a ser exibido ao usuario erealizado atraves dos servicos de gerenciamento de contexto e adaptacao deconteudo do middleware.

Na Figura 5 pode-se observar a arquitetura doUHSy.

Figura 5: Arquitetura do modulo doUHSy (DINIZ; TRINTA, 2008)

Na parte superior da figura estao os servidores de aplicacao dos PEPs, en-quanto na parte inferior estao representados os servicos disponibilizados pelomiddleware UbiDoctor. Estes componentes formam o back end do sistema, res-ponsaveis pelos servicos disponibilizados aos clientes. Os componentes queacessam o ambiente computacional atraves de computadores pessoais, tablets,PDAs ou telefones celuares sao denominados clientes e formam o front end docenario.

Os profissionais de saude podem acessar os dados do paciente atraves dofront end de qualquer lugar, usando diversos tipos de dispositivos computaci-onais atraves de diversas possibilidades de rede de acesso. Dependendo dodispositivo de acesso usado, as aplicacoes terao mais ou menos recursos dis-ponibilizados aos clientes. Por exemplo, a aplicacao web usada em computado-res pessoais tera mais recursos disponıveis que um telefone celular, devido aslimitacoes impostas pelos tamanhos de display e teclado deste ultimo.

Page 30: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

4 PRINCIPAIS ERROS MEDICOS A SEREM CONSIDE-RADOS EM MEDICINA UBIQUA

Os hospitais tem se tornado ambientes cada vez mais complexos, onde euma rotina diaria o uso de equipamentos e procedimentos de alto risco a vidados pacientes. Devido as estas caracterısticas sao comuns os efeitos adversosao paciente causados por erros medicos.

O erro medico pode ser definido como a falha ao nao concluir como previstouma acao planejada ou o uso de um plano errado para atingir um determinadoobjetivo. Os erros mais comuns sao falhas nos sistemas, processos e condicoesque permitem que as pessoas errem ou falhem em nao prevenı-los (CORRIGANet al., 2009).

Dois grandes estudos que analisaram as instituicoes de saude dos EstadosUnidos identificaram que ao menos 44 mil pessoas morrem nos hospitais a cadaano devido a erros medicos que poderiam ser evitados. Este numero ultrapassaas mortes atribuıdas a AIDS, cancer de mama e acidentes de transito. Alemdas vidas perdidas, estes erros representam um custo neste paıs entre 17 e 29bilhoes de dolares, incluindo os gastos em cuidados adicionais devido aos errose produtividade familiar (CORRIGAN et al., 2009).

O processo de terapia medicamentosa no ambiente hospitalar e altamentecomplexo e muito vulneravel a falhas que podem ocorrer em alguma desuas varias etapas: prescricao, transcricao, dispensacao, distribuicao, preparo,administracao e monitorizacao. O uso da tecnologia pode trazer mais segurancaatraves da simplificacao e padronizacao deste processo, evitando assim muitodos erros medicos que podem ocorrer durante todo o ciclo do tratamento medi-camentoso. Deve-se introduzir verificacoes em diversas fases do processo como objetivo de identificar falhas antes que elas cheguem ao paciente (CASSIANI;GIMENES; MONZANI, 2009).

Estas verificacoes podem ser feitas para garantir os chamados Seven Rightsda terapia medicamentosa:

• droga correta: garantir que o medicamento a ser administrado esta cor-

Page 31: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

31

reto;

• paciente correto: garantir que o medicamento sera administrado ao paci-ente correto;

• dose correta: garantir que a quantidade de medicamento esta correta;

• tempo correto: garantir que o momento de administrar o medicamentoesta correto;

• via correta: garantir que o medicamento sera aplicado no acesso corretocorreto (intravenoso, subcutaneo, interosseo/medula ossea, inalacao, ente-ral, transdermico, intramuscular);

• motivo correto: garantir que o medicamento sera administrado pelo motivocorreto;

• documento correto: garantir que a prescricao esta correta;

Dentre as diversas possibilidades de tecnologias que podem ser aplicadas aeste processo, podemos citar a prescricao medica eletronica, codigo de barras,etiquetas RFID e bombas de infusao inteligentes.

A prescricao eletronica e um sistema computadorizado usado pelo medicopara receitar medicamentos aos pacientes. O uso deste recurso evita proble-mas de interpretacao devido a rasuras ou caligrafia ilegıvel, incompatibilidadeentre medicamentos e pode informar quanto as alergias do paciente a uma de-terminada droga. O uso de codigos de barras e etiquetas RFID podem ser usa-dos para identificar operadores dos eletromedicos, pacientes, medicamentos eprescricoes. As bombas de infusao inteligentes (Smart Pumps) sao equipa-mentos eletromedicos usados para administracao de medicamentos, as quaispossuem alertas que informam quando a programacao incorreta de doses demedicamentos (CASSIANI; GIMENES; MONZANI, 2009).

Com o uso dos princıpios de fatores humanos no projeto de equipamentosmedicos e possıvel reduzir ou ate mesmo eliminar a maioria dos erros medicosrelacionados a operacao deste tipo de dispositivos. Esta area cientıfica e alta-mente interdisciplinar e tem como objetivo identificar e resolver as deficiencia nouso de dispositivos, levando em consideracao os aspectos humanos e as carac-terısticas inerentes ao ambiente hospitalar. Os estudos estao fortemente basea-dos nos princıpios oriundos de pesquisas sobre a psicologia cognitiva, os quaistentam entender os processos mentais relacionados com o comportamento dosseres humanos (FENNIGKOH; HARO, 2009). A cognicao e a forma de como ocerebro percebe, aprende, recorda e pensa sobre todas as informacoes captadasatraves dos sentidos humanos (tato, olfato, audicao, paladar e visao).

Page 32: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

32

Alguns dos processos estudados pela psicologia cognitiva sao:

• como as pessoas se comunicam;

• como e feita a percepcao e processamento de informacoes;

• como comentem erros;

• como interagem com equipamentos e suas interfaces;

• como resolvem problemas;

• como interagem com o ambiente;

• como julgam e tomam decisoes;

• como formam conceitos.

O correto entendimento e aplicacao dos conceitos da psicologia cognitiva po-dem criar grandes oportunidades no desenvolvimento de equipamentos medicosmais seguros, intuitivos e eficientes. Como resultado e possıvel reduzir signifi-cativamente os erros medicos oriundos de operacao inadequada de dispositivosmedicos, aumentando a satisfacao dos profissionais de saude e a eficacia notratamento da saude do paciente.

Os erros medicos podem ser prevenidos atraves do projeto do sistema desaude em todos os nıveis, objetivando torna-lo mais seguro ao dificultar que aspessoas facam algo errado, possibilitando ser mais facil fazer da maneira cor-reta (CORRIGAN et al., 2009). Atraves do desenvolvimento de equipamentosmedicos usando este ponto de vista e possıvel trazer mais seguranca ao ambi-ente hospitalar e melhorias nas terapias de saude.

Page 33: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

5 AQUISICAO DE SINAIS VITAIS

As aplicacoes utilizando redes de sensores sem fio sao uma tendencia no mo-nitoramento de saude (PANTELOPOULOS; BOURBAKIS, 2008). Neste capıtulosera apresentado uma revisao sobre este tecnologia e os principais sinais vitaismonitorados em aplicacoes medicas.

O avanco da tecnologia permitiu o desenvolvimento e a miniaturizacao desistemas microcontrolados com comunicacao sem fio em dispositivos portateis.

Rede de Sensores sem Fio (RSSF) e uma tecnologia que permite a aquisicaode dados sensoriais a partir de pequenos dispositivos independentes, chamadosde nodos ou nos, distribuıdos em uma regiao de interesse (CARVALHO-JR; RI-BAS; FIGUEIREDO, 2011). Estes dispositivos possuem poder de computacaolimitado e fazem uso da comunicacao wireless para a coleta de dados e conexaocom alguma rede, como por exemplo a Internet (LOUREIRO, 2006).

As RSSF podem ser consideradas como uma das primeiras implementacoesreais da computacao ubıqua, segundo a qual dispositivos computacionais even-tualmente iriam permear o ambiente (LOUREIRO, 2006). Este dispositivos de-vem ser pequenos, inteligentes, baratos e funcionar por grandes perıodos detempo de forma autonoma.

De acordo com (LOUREIRO et al., 2003), o termo no ”indica um ele-mento computacional com capacidade de processamento, memoria, interfacede comunicacao sem fio, alem de um ou mais sensores do mesmo tipo ou nao.Redes de sensores sem fio diferem de redes de computadores tradicionais emvarios aspectos. Normalmente essas redes possuem um grande numero de no-dos distribuıdos, tem restricoes de energia, e devem possuir mecanismos paraauto-configuracao e adaptacao devido a problemas como falhas de comunicacaoe perda de nodos. Uma RSSF tende a ser autonoma e requer um alto grau decooperacao para executar as tarefas definidas para a rede.”

Como exemplo concreto do avanco de redes de sensores especializadas paraaquisicao de sinais vitais temos as Wireless Body Area Network (WBAN). Estasredes tambem sao chamadas de Body Sensor Networks (BSN), as quais cons-

Page 34: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

34

Figura 6: Arquitetura de um no sensor (OLIVEIRA, 2011)

tituem uma RSSF otimizada para uso na area da saude. Esta rede e compostapor um conjunto de unidades moveis (nos sensoriais ou atuadores) e compactascolocados na roupa, corpo ou sob a pele do paciente. Esta promissora tecno-logia esta permitindo o desenvolvimento de aplicacoes nas areas de monitora-mento remoto de saude, medicina e esportes, beneficiando-se da liberdade demovimento possibilidade pelo uso das WBANs. Um exemplo da aplicacao seria oenvio de sinais vitais de um paciente para um central de monitorizacao e controleou a um profissional de saude encarregado.

Como requisitos essenciais, cada no possui uma fonte de energia propria comalto grau de eficiencia energetica, o que permite o funcionamento por toda suavida util sem necessitar de manutencao, e dimensoes reduzidas, possibilitandoseu uso no vestuario do paciente. Estes nos se comunicam entre si e com acentral atraves de tecnologia sem fio, enquanto a central de controle se comunicacom o mundo externo por meio de uma rede local, rede de dados para telefoniacelular ou pela Internet (MARCELINO, 2008).

O uso de WBANs torna possıvel um monitoramento mais completo dascondicoes de saude dos pacientes, permitindo assim a supervisao e registro per-manente de seus sinais vitais (MARCELINO, 2008). Desta forma os profissionaisde saude conseguem obter um diagnostico medico mais preciso, resultando emum tratamento clınico mais eficiente.

O Nike + iPod Sport Kit (www.apple.com/ipod/) e um exemplo de um produtocomercial baseado em WBAN para uso durante a pratica de exercıcios fısicos.O sistema e baseado no uso de um sensor colocado dentro de um tenis, o qualse comunica com o iPod atraves de comunicacao sem fio. Durante o exercıcio,pode-se consultar no iPod informacoes tais como a distancia percorrida, caloriasgastas, tempo de duracao e ritmo da corrida.

De acordo com (GASPAR, 2009), o tipo de ligacao entre o sensor (instaladono pe do esportista) e o iPod (colocado no braco) e chamada on-body. Casoo iPod estivesse colocado a uma curta distancia e fora do corpo do atleta, aligacao seria chamada de off-body. No caso de sensores implantados, a ligacao

Page 35: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

35

Figura 7: Arquitetura de uma WBAN (www.jneuroengrehab.com)

Figura 8: Nike + iPod Sport Kit (www.apple.com/ipod/)

e chamada de in-body.

5.1 Tipos de sinais vitais

Nesta secao serao caracterizados os principais sinais fisiologicos monitora-dos pelas aplicacoes voltadas a medicina ubıqua.

Page 36: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

36

5.1.1 Oxımetria de pulso

A oxımetria de pulso (SpO2) realiza de forma rapida, precisa e pratica amedicao da porcentagem de hemoglobina saturada com oxigenio no sangue(SpO2) (PIZARRO, 2003). Este e um metodo nao invasivo que permite obterde forma instantanea o estado de oxigenacao arterial do paciente. O monitora-mento deste parametro pode ser feito de forma contınua, trazendo assim maiorseguranca aos processos de administracao de oxigenio ao paciente. A analisede SpO2 e feita principalmente em pacientes com obstrucao pulmonar cronicae doencas respiratorias, atraves da qual pode-se avaliar os sistemas cardıaco erespiratorio.

O sensor possui um formato semelhante a um prendedor de roupas e nor-malmente e instalado na ponta de um dos dedos das maos do paciente, as quaissao regioes ricas em vasos sanguıneos. Tambem e possıvel coloca-lo nos dedosdos pes, nariz e no lobulo da orelha.

O fato de nosso sangue possuir uma cor mais ou menos vermelha indicauma maior ou menor taxa de oxigenacao. A medicao e feita atraves de um fo-todetector, que e um dispositivo semicondutor aprimorado para absolver fotons,combinando os princıpios da pletismografia e espectrofotometria. Sao geradosdois sinais com comprimentos de onda diferentes (luzes vermelha e infraverme-lha), os quais atravessam a regiao repleta de vasos sanguıneos. Parte do sinalirradiado sera absorvido pelo sangue arterial, sendo que os sinais resultantessao entao medidos pelo fotodetector. O resultado da oxigenacao arterial do paci-ente e obtido pela diferenca da absorcao de luz, que varia conforme a existenciade hemoglobina oxigenada ou desoxigenada (SILVEIRA, 2007). Atraves destemetodo tambem e possıvel medir a frequencia cardıaca do paciente.

Geralmente os equipamentos usados para fazer esta medicao, chamados deoxımetros de pulso, sao pequenos e portateis.

5.1.2 Eletrocardiograma

O eletrocardiograma (ECG) e uma importante ferramenta para monitoramentodo funcionamento do coracao, capaz de fazer o registro da atividade eletricarelacionada a acao do musculo cardıaco. A atividade mecanica gerada pelocoracao produz um sinal eletrico que e captado atraves de eletrodos colocadosna pele do paciente. Este sinal eletrico possui amplitude entre 50uV e 5mV efrequencia entre 0,1 a 100Hz (PIZARRO, 2003).

Depois da captura, o sinal e entao filtrado e processado para a geracao degraficos e valores numericos, os quais podem ser avaliados por um profissionalde saude qualificado para realizar a sua analise e uma correta interpretacao.

A analise de ECG e usada para diagnosticar doencas e arritmias relativas

Page 37: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

37

Figura 9: Oxımetro de pulso portatil (www.lightinthebox.com)

a problemas no funcionamento do coracao, tais como taquicardia, bradicardia,infartos do miocardio, entre outras. O exame tambem e usado para avaliar o fun-cionamento do musculo cardıaco atraves de exames de esforco fısico (PIZARRO,2003).

Figura 10: Eletrocardiograma (www.caepcampinas.com.br/e-infra-eletro.asp)

5.1.3 Frequencia cardıaca

Este parametro indica o numero de batimentos cardıacos por unidade detempo e e usualmente expresso em batimentos por minuto (BPM), podendo sermedido atraves do oxımetro de pulso, ECG (eletrocardiograma) ou atraves daPANI (Pressao Arterial Nao Invasiva). A frequencia cardıaca (FC) e usada paraauxiliar no diagnostico e acompanhamento das condicoes clınicas de pacientes.

A faixa de frequencia cardıaca de adultos em repouso considerada normal ede 60 a 100 BPM, sendo que os valores abaixo sao considerados como bra-dicardia e os acima como taquiacardia (GARCIA, 2002). Os monitores mul-

Page 38: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

38

tiparametricos possuem alarmes visuais e sonoros de baixa e alta frequenciacardıaca.

Tambem e possıvel medir manualmente a FC em partes do corpo onde pode-se sentir a pulsacao arterial, tais como peito, pescoco e pulso. Para isto bastapressionar o peito com a palma da mao e o pescoco (arteria carotida, locali-zada pouco abaixo da mandıbula) ou punho com os dedos indicador e medio,contando o numero de batimentos em um minuto.

Figura 11: Medicao manual da frequencia cardıaca (www.adam.com/)

5.1.4 Temperatura corporal

A temperatura em seres humanos e quase sempre constante, mesmo quandoestamos submetidos a muito calor ou frio, gracas a nosso aparelho termore-gulador. Quando ha um problema que gere uma deficiencia nesta regulacaotermica, ocorre hipertermia (quando o corpo produz ou absorve mais calor doque pode dissipar), hipotermia (queda da temperatura) e febre (aumento datemperatura corporal acima do ponto de regulacao). A producao de calor emnosso organismo e feita atraves da alimentacao, fıgado e musculos. Ja aperda calorica acontece pelo sangue atraves da transmissao do calor para asuperfıcie do corpo atraves da radiacao, evaporacao, conveccao e conducao(www.infoescola.com/fisiologia/temperatura-corporal/).

A temperatura e medida em partes do corpo que possuam uma grandeirrigacao sanguınea, tais como boca, axila, anus e esofago. Para medir estagrandeza pode-se usar um termistor, o qual e um componente eletronico quegera uma tensao eletrica proporcional a temperatura.

5.1.5 Gases respiratorios

Atraves de um analisador de gases pode-se medir a concentracao deoxigenio, gas carbonico, agentes anestesicos e oxido nitroso na mistura inspi-

Page 39: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

39

Figura 12: Medicao de temperatura corporal (www.sciencephoto.com)

rada e expirada pelos pacientes (PIZARRO, 2003). Para fazer esta analise umapequena amostra de gas e coletada do sistema respiratorio do paciente atravesde um tubo. No equipamento esta amostra passa por algumas etapas, onde eavaliada por diferentes metodos para a deteccao e medicao da quantidade exis-tente de cada um destes tipos de gases.

Figura 13: Analisador de gases anestesicos (www.medicalexpo.es)

5.1.6 Frequencia respiratoria

A frequencia respiratoria (FR) e o numero de vezes por minuto que nossoorganismo realiza ciclos de inspiracao e expiracao. Apesar destes ciclosrespiratorios serem involuntarios, podemos alterar sua frequencia por von-tade propria ate certo ponto. O sistema nervoso de uma pessoa adultaestimula a ventilacao pulmonar em uma frequencia de 12 a 15 ciclos porminuto. Ao realizarmos exercıcios fısicos ou quando ocorre a reducao daconcentracao de oxigenio no sangue, nosso sistema nervoso aumenta a FR paracaptar mais gas (https://sites.google.com/site/educopediaedfisica/seguranca-no-esporte/frequencia-respiratoria).

Page 40: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

40

A FR e medida atraves sinal da curva de capnografia, que uma tecnica usadapara obter informacoes sobre os padroes de respiracao, producao e eliminacaode dioxido de carbono (CO2) do sistema respiratorio, perfusao pulmonar eventilacao alveolar.

5.1.7 Pressao Arterial Nao Invasiva

A medicao da PANI e realizada de modo indireto atraves do metodo osci-lometrico (PIZARRO, 2003). Para isto uma bolsa inflavel (manguito) e instaladano braco do paciente e a pressao sanguınea e medida atraves da variacao depressao no interior da mesma. O manguito passa a ser inflado ate bloquear ofluxo de sangue na arteria braquial do braco. A bolsa passa entao a ser esva-ziada, fazendo com que a oscilacao de pressao aumente ate atingir um valormaximo, quando entao comeca a diminuir.

A pressao sistolica (ponto mais alto da pressao nas arterias) e o valor me-dido dentro da bolsa quando a oscilacao comeca a ser perceptıvel. A pressaodiastolica (ponto mais baixo da pressao nas arterias, que e a pressao que estasempre presente sobre as paredes arteriais) e o valor medido quando a oscilacaodeixa de ser perceptıvel (www.eerp.usp.br/ope/manual.htm).

A medicao de pressao no interior do manguito pode ser feita atraves de trans-dutores de pressao (em um equipamento digital) ou por um manometro (em umequipamento convencional - esfigmomanometro).

Figura 14: Equipamento para medicao de Pressao Arterial Nao Invasiva(www.futurvida.com)

5.1.8 Pressao Arterial Invasiva

Atraves da medicao da pressao arterial invasiva (PAI) e possıvel obter va-lores confiaveis, diretos e contınuos, tornando possıvel detectar precocementecomplicacoes no estado do paciente.

A medida e feita por um transdutor de pressao e um cateter inserido no sis-tema circulatorio do paciente (PIZARRO, 2003). O cateter e preenchido com um

Page 41: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

41

fluıdo fisiologico que transmite a pressao do ponto de medicao ate o sensor. Otransdutor de pressao deve possuir rapido tempo de resposta e alta sensibilidade.

5.2 Projetos para aquisicao de sinais vitais

Nesta secao sao apresentados alguns trabalhos baseados em redes sem fiopara aquisicao de sinais vitais.

5.2.1 CodeBlue

Codeblue (MALAN; FULFORD-JONES; WELSH, 2004; LORINCZ et al., 2004;SHNAYDER et al., 2005; GAO et al., 2005) e um projeto da Universidade de Har-vard com foco no desenvolvimento de infraestrutura de rede para sensores semfio em aplicacoes medicas. O sistema possui suporte para uso em emergencias,cuidados medicos em situacoes de desastres e reabilitacao de pacientes comproblemas cardıacos. O sistema e baseado em uma rede de sensores paramonitoramento de sinais vitais e registros medicos para uso em decisoes nostratamentos de saude. Tambem e possıvel monitorar a localizacao dos pacientesatraves de sinais de radiofrequencia.

Com a arquitetura criada e possıvel melhorar o atendimento de vıtimas em de-sastres e acidentes, atraves da coleta de sinais vitais e localizacao dos pacientesdurante o regaste. O sistema permite integrar estes dados com as informacoesde outros sistemas de saude, possibilitando que os clınicos possam, remota-mente, dar pareceres medicos e indicar o procedimento mais adequado.

Figura 15: Arquitetura do projeto Codeblue (LORINCZ et al., 2004)

O projeto suporta o uso de sensores para monitoramento sem fio de oxime-tria, eletrocardiograma (ECG ou EKG), eletromiografia (EMG) e movimentos (SH-

Page 42: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

42

NAYDER et al., 2005). Com o sensor de oximetria e possıvel medir a frequenciacardıaca e a porcentagem de saturacao de oxigenio no sangue. O ECG e me-dido atraves de um par de sensores, os quais permitem fazer o monitoramentocontınuo da atividade eletrica do coracao, atraves do qual e possıvel identificararritmias e ataques do coracao. A EMG e feita atraves do uso de eletrodos su-perficiais colocados na pele do paciente, os quais medem os impulsos eletricosdos musculos. Os movimentos dos membros (tais como bracos, pernas, cos-tas e tronco) sao monitorados atraves de um acelerometro de tres eixos e umgiroscopio. O acelerometro monitora a orientacao e movimento de cada seg-mento do corpo. O giroscopio mede a velocidade angular e, combinado comdados do acelerometro, pode ser utilizado para determinar com precisao posicaodos membros. A EMG e os sensores de movimento sao utilizados para avaliar aeficacia em tratamentos para a doenca de Parkinson e na reabilitacao fısica aposum acidente vascular cerebral (AVC).

Figura 16: Sensores sem fio desenvolvidos no projeto Codeblue (SHNAYDERet al., 2005)

O Codeblue opera com diversos tipos de dispositivos, tais comomotes1 de baixa potencia, PCs e PDAs (MALAN; FULFORD-JONES;WELSH, 2004). O modulo e composto de um mote modelo MICA2(http://bullseye.xbow.com:81/Products/productdetails.aspx?sid=174) que trans-mite, a um determinado intervalo de tempo, pacotes de dados com medicoesde sinais vitais do paciente (MALAN; FULFORD-JONES; WELSH, 2004). Es-tas informacoes podem ser transmitidas para um PC ou notebook atraves decomunicacao com fio ou diretamente para os PDAs dos profissionais de saudeatraves de comunicacao wireless.

O nucleo da arquitetura do CodeBlue e baseada em um modelo decomunicacao publish, onde os dispositivos podem se inscrever para receberinformacoes dos sensores de interesse. A arquitetura de hardware e a camada

1Mote e um modulo microcontrolado que possui alimentacao propria atraves de baterias, sen-sores, porta de entrada/saıda e um modulo de comunicacao.

Page 43: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

43

de software responsavel pela descoberta de novos nos permitem que sensoressejam facilmente integrados a rede. A arquitetura do sistema pode ser parame-trizada atraves de filtros, por meio dos quais e possıvel criar regras para envio dealertas quando um sensor apresente alguma medicao que se encontre fora dafaixa considerada normal (SHNAYDER et al., 2005).

A Figura 17 mostra uma tela de interface do Codeblue apresentando o re-latorio de monitoramento dos sensores de batimentos cardıacos, oximetria eECG.

Figura 17: Interface de usuario do projeto Codeblue (SHNAYDER et al., 2005).

5.2.2 MobiHealth

O projeto MobiHealth (MAGAZINE; TECHNOLOGY, 2009; WAC et al., 2009;JONES et al., 2006; KONSTANTAS; HERZOG, 2003; HALTEREN et al., 2004;KONSTANTAS; HERZOG, 2003; JONES et al., 2003) foi criado com o objetivo deatender diversas areas da saude, tais como homecare, traumas, monitoramentode pacientes de alto risco e portadores de doencas cronicas. Varias condicoesmedicas foram consideradas, tais como arritmias cardıacas, artrite reumatoide,insuficiencia respiratoria e gravidez de alto risco.

Page 44: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

44

O MobiHealth foi inicialmente desenvolvido pela Comissao Europeia, entre osanos de 2002 e 2004, com a finalidade de criar uma plataforma de servicos parapacientes e profissionais de saude. Nesta etapa o objetivo foi descobrir se seriapossıvel realizar assistencia medica atraves de sistemas moveis de cuidados asaude com o uso de redes de comunicacao 2.5 e 3G .

Posteriormente, entre os anos 2004 e 2008, o projeto foi continuado pelogrupo holandes de pesquisas HealthService24, quando passou a ser chamadode Freeband Awareness (MAGAZINE; TECHNOLOGY, 2009). Nesta fase o ob-jetivo foi desenvolver uma plataforma de servicos sensıveis ao contexto, atravesda disponibilizacao de servicos adaptaveis ao contexto do usuario (localizacao,momento e atividade que esta realizando). Tambem fazia parte do escopo doprojeto a avaliacao do potencial de mercado para os sistemas de monitoramentoremoto.

Atualmente o MobiHealth esta sendo desenvolvido pelo projeto europeu cha-mado de MyoTel (Myofeedback based Teletreatment service). O grupo esta pes-quisando o potencial de mercado para myofeedback baseado em monitoramentoremoto e sistemas de tratamento para pacientes que sofrem de dores cronicasnos ombros e nas costas (www.myotel.eu/). O projeto conta com o apoio de di-versos parceiros europeus, tais como fornecedores de hardware, hospitais, pres-tadores de servicos medicos, operadoras de redes moveis de dados, desenvol-vedores de aplicacoes e infra-estrutura moveis.

Em todos os projetos estao sendo feitos experimentos com diversos cenariospara cuidados de saude e tipos de pacientes, realizados por grupos de pesquisasde diferentes paıses europeus (WAC et al., 2009).

O sistema MobiHealth possibilita que os sinais vitais de pacientes possamser monitorados remotamente por uma BAN customizavel, a qual e conectada auma plataforma movel de servicos de saude atraves de uma rede sem fio (MAGA-ZINE; TECHNOLOGY, 2009; WAC et al., 2009). Desta forma os pacientes comdoencas cronicas podem ser monitorados sem a necessidade de estarem hos-pitalizados, podendo prosseguir as suas atividades diarias com liberdade e re-ceberem pareceres de profissionais de saude em tempo real. Com a plataformadesenvolvida e possıvel monitorar continuamente a pressao arterial, frequenciacardıaca, respiracao e ECG (WAC et al., 2009).

A BAN e formada por sensores, atuadores, meios de comunicacao e modulosde processamento. Os sensores da rede BAN sao instalados no corpo do paci-ente. A comunicacao entre os nodos da rede BAN e feita atraves de redes decomunicacao sem fio de curto alcance, tais como a tecnologia Bluetooth (MA-GAZINE; TECHNOLOGY, 2009). O sistema possui uma unidade-base movel,implementada atraves de um PDA da fabricante HTC, que aquisita os sinais vi-

Page 45: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

45

tais e os envia para um servidor de aplicacao atraves de uma rede de bandalarga sem fio (Wi-Fi ou 2.5/3/3.5G) (WAC et al., 2009). Estes sinais vitais saoentao transmitidos para analise pelos profissionais de saude.

Figura 18: Arquitetura de servicos do MobiHealth (HALTEREN et al., 2004).

Figura 19: Sensores e interface de usuario do MobiHealth (www.mobihealth.com)

Como resultado, o projeto provou que o monitoramento movel e remoto depacientes reduz os custos dos tratamentos de saude, ja que diminui a quanti-dade de exames que precisam ser realizados nos hospitais e melhora a quali-dade de vida dos pacientes (WAC et al., 2009). As pesquisas realizadas tambemconcluem que a BAN e uma tecnologia em crescimento e que ira apoiar estesobjetivos.

Page 46: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

46

5.2.3 UbiMon

O UbiMon (NG et al., 2004; VAN LAERHOVEN et al., 2004) (Ubiquitousmonitoring environment for wearable and implantable sensors ou Ambiente deMonitoracao Onipresente para Sensores Vestıveis ou Implantaveis) e um fra-mework desenvolvido pelo Departamento de Computacao do Imperial CollegeLondon com o objetivo de disponibilizar um monitoramento contınuo e em temporeal do estado fisiologico de pacientes nao hospitalizados e que estejam desen-volvendo suas atividades normais no seu dia-a-dia. O projeto considera pacien-tes com arritmias cardıacas ou em acompanhamento pos-operatorio. O sistemapermite o armazenamento e processamento a longo prazo dos dados aquisita-dos, possibilitando desta forma a analise de tendencias, deteccao e predicaode situacoes de risco a vida do paciente. Os resultados da analise dos dadoscoletados podem ser enviados para o medico responsavel pelo paciente. Alemdisto, o sistema pode automaticamente acionar uma ambulancia no caso de umaemergencia medica.

De acordo com as pesquisas do projeto (VAN LAERHOVEN et al., 2004), umdos principais desafios no monitoramento contınuo de pacientes que nao estaohospitalizados e identificar qual o contexto em que os sinais fisiologicos estaosendo aquisitados. Isto se deve ao fato de que os sinais vitais variam conformea atividade em que o paciente esta envolvido e a inumeros fatores ambientais.Como exemplo, uma alteracao nos sinais de ECG podem ser tanto devido acondicao cardıaca do paciente quanto ao estresse fısico e mental ao qual o paci-ente esta submetido.Portanto, neste projeto, foram considerados sensores paraentender o contexto do paciente, juntamente com os demais sensores para mo-nitoramento dos sinais vitais, para que possa ter uma imagem mais ampla doestado fisiologico do paciente.

A figura 20 apresenta alguns cenarios dos testes de prototipos de sensoresde movimentos usados para identificar o contexto do corpo do paciente, ou seja,se o mesmo esta caminhando, sentado, correndo, subindo escadas, andando debicicleta, etc. Estes testes foram feitos para identificar as posicoes mais adequa-das para instalacao dos sensores no corpo do paciente e quais tipos de sensoresideais para uso.

O projeto e baseado em uma BSN (Body Sensor Network ) usando uma redead hoc, composta de sensores vestıveis e implantaveis. O projeto possui su-porte para diversos sensores sem fio, tais como temperatura corporal, pressaosanguınea, SpO2, frequencia cardıaca e ECG (NG et al., 2004). Tambem estaodisponıveis sensores, tais como acelerometros, para suporte a consciencia docontexto.

Conforme apresentado na figura 21, a arquitetura do sistema e composta

Page 47: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

47

Figura 20: Cenarios dos testes de prototipos de sensores de movimentos usadosno projeto UbiMon (VAN LAERHOVEN et al., 2004).

de uma unidade de processamento local, nos sensores da rede BSN, servidorcentral, banco de dados do paciente e estacoes de trabalho (computadores outelefones celulares) (NG et al., 2004). A unidade de processamento local e com-posta por um telefone celular ou PDA com um cartao compact flash, responsavelpela aquisicao, analise e apresentacao dos sinais originados do sensores. Estedispositivo tambem e responsavel por apresentar mensagens de alerta ao paci-ente no caso de ocorrencia de alguma anormalidade dos sinais vitais. Os dadosaquisitados sao enviados pelo PDA ao servidor central atraves de comunicacaoWi-Fi e redes 3G/GPRS. As estacoes de trabalho sao usadas pelos profissio-nais de saude para analise detalhadas de condicoes anormais dos sinais vitais econsulta de dados (VAN LAERHOVEN et al., 2004).

Figura 21: Arquitetura do projeto UbiMon (NG et al., 2004).

5.2.4 Alarm-Net

AlarmNet (WOOD et al., 2006; A WOOD, 2008) e um projeto desenvolvidopela Universidade da Virgınia com o objetivo de realizar a monitorizacao contınuae em tempo real de sinais vitais de idosos e demais pessoas que necessitem deassistencia medica. Atraves de uma rede de sensores sem fio o sistema ubıquo

Page 48: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

48

monitora o comportamento destas pessoas em suas casas durante seu dia-a-dia,criando um historico medico, identificando padroes e alteracoes nas atividadesdos pacientes, as quais possam indicar problemas de saude. O sistema e base-ado em sensores de sinais vitais colocados no vestuario do paciente e tambemna monitorizacao de variaveis ambientais para prover a sensibilidade ao contexto.

Conforme pode ser visto na figura 22, o sistema e composto pelos seguintescomponentes: SeeMote, rede de sensores moveis corporais, AlarmGate, Back-end, interface com os usuarios e sensores ambientais (A WOOD, 2008). See-Mote sao dispositivos compostos de alto-falantes e displays graficos coloridosque sao usados para apresentar informacoes graficas e mensagens de voz aospacientes, como por exemplo, o horario de tomar um determinado medicamento.A rede de sensores moveis colocados no corpo do paciente e responsavel pelomonitoramento dos sinais fisiologicos e localizacao do paciente. Para coletar ossinais fisiologicos estao disponıveis sensores de peso corporal, pressao do san-gue, ECG, SpO2 e frequencia cardıaca. Os sensores de ECG e SpO2 usados fo-ram desenvolvidos pelo projeto CodeBlue (MALAN; FULFORD-JONES; WELSH,2004) na Universidade de Harvard (WOOD et al., 2006). O AlarmGate e uma pla-taforma embarcada para gerenciamento de operacoes do sistema, execucao deaplicacoes e gerenciamento de comunicacao entre os sensores sem fio e a redeIP. O sistema Back-end e responsavel pelo armazenamento no banco de dadose analise das informacoes coletadas pelos sensores, polıticas de privacidade,configuracoes do sistema e informacoes dos operadores. A interface com osusuarios pode ser acessada atraves de dispositivos moveis, tais como PDA ecomputadores, atraves das quais os profissionais de saude e a famılia do paci-ente podem consultar os dados coletados pelos sensores. Na figura 22 estaoapresentadas as telas de interface do usuario (a esquerda) e de administracaodo sistema (a direita). Os sensores ambientais sao usados para identificacao docontexto atraves no monitoramento de temperatura, umidade, aceleracao, movi-mento, poeira e luminosidade.

O projeto Satire (GANTI et al., 2006) foi integrado no AlarmNet, sendo usadono monitoramento das atividades diarias do paciente para identificar padroes decomportamento (WOOD et al., 2006). O sensoriamento e realizado atraves doacelerometro que faz parte da rede de sensores corporais. O sistema realizaanalises do ritmo circassiano (Circadian Activity Rhythm - CAR), com o objetivode aprender o padrao do ciclo biologico do paciente (WOOD et al., 2006). Estaanalise e usada para suporte ao gerenciamento de energia baseado em contexto,polıticas dinamicas de privacidade e associacao de dados. Caso alguma anor-malidade for detectada no comportamento tıpico do paciente, o sistema emiteum alerta para a verificacao se algum problema de saude esta causando esta

Page 49: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

49

Figura 22: Arquitetura do projeto AlarmNet (WOOD et al., 2006).

Figura 23: Telas de interface do usuario e de administracao do sistema no projetoAlarmNet (A WOOD, 2008).

irregularidade. O uso pelo paciente do banheiro por um numero de vezes muitomaior que o normal, reducao no numero de refeicoes e alteracoes na quanti-dade de horas de sono sao alguns exemplos de deteccao de anormalidades quepoderiam ser identificadas pelo sistema.

Page 50: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

6 DESAFIOS E REQUISITOS PARA O DESENVOLVI-MENTO DE ARQUITETURAS EM MEDICINA UBIQUA

As aplicacoes que fazem o uso de redes de comunicacao sem fio na areade saude precisam atender a diversos desafios e requisitos. Conforme os estu-dos realizados, a seguir serao apresentados os topicos mais relevantes a seremconsiderados no desenvolvimento de arquiteturas para a medicina ubıqua.

6.1 Seguranca e privacidade

As informacoes referentes a saude de um paciente devem estar disponıveissomente para os profissionais de saude autorizados, tanto por razoes legaisquanto eticas. Devido a isto os dados de cadastro do paciente e os si-nais vitais aquisitados devem ter consistencia e protecoes contra adulteracoes,interceptacoes e interferencias. Portanto a seguranca e uma questao importantea ser considerada no desenvolvimento de aplicacoes sem fio para a area medica.

A espionagem dos dados de saude pode trazer danos ao paciente de di-versas formas, ja que um adversario (tal como por exemplo um inimigo pes-soal, polıtico rival, treinador de um atleta competidor, agente de seguros e pla-nos de saude, empresario concorrente, etc.) do mesmo podera utilizar estasinformacoes de forma ilegal ou para tirar vantagens (KUMAR; LEE, 2012). Por-tanto as informacoes de saude devem ser confidenciais, ja que seu acesso podecausar risco de vida ao paciente ou tornar questoes privadas publicamente dis-ponıveis. Como exemplificado pela figura 24, no caso de portar uma doencaembaracosa, caso esta informacao se torne publica atraves de redes sociais,tais como Facebook ou Twitter, poderia fazer com que o paciente sentisse vergo-nha. Alguns tipos de doencas tambem podem fazer com que uma pessoa percaseu emprego ou impeca a contratacao de um plano de saude ou seguro de vida.

De acordo com (STEELE et al., 2009), embora um estudo feito com um grupode idosos na Astralia ter revelado que a privacidade das informacoes de saudenao tem efeito significativo na aceitacao de um sistema de rede sem fio, os as-

Page 51: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

51

Figura 24: Riscos para a privacidade do paciente (KUMAR; LEE, 2012).

pectos de privacidade devem ser considerados como um requisito importante nodesenvolvimento deste tipo de aplicacoes. Este mesmo estudo mostrou que osidosos possuem uma alta rejeicao a sistemas com monitorizacao por camarasde video. Segundo (IKONEN; KAASINEN, 2008) os pacientes devem ter auto-nomia. Conforme os pesquisadores do projeto CareNet (SUNNY CONSOLVO;SHELTON, 2004), as aplicacoes de saude devem possuir regras bem definidasdo nıvel de privacidade dos dados dos pacientes. Desta forma os pacientes po-deriam decidir quais informacoes podem ser acessadas e em qual intervalo detempo (SUNNY CONSOLVO; SHELTON, 2004; ALEMDAR; ERSOY, 2010). Noprojeto Smart Home Care Network (TABAR; KESHAVARZ; AGHAJAN, 2006) autilizacao de sensores de imagens e proposta para propositos de verificacao so-mente em caso de emergencias, implementando desta forma um mecanismo deprivacidade (ALEMDAR; ERSOY, 2010).

Os desenvolveres de sistemas para a area da saude devem se certificar queas aplicacoes sao resistentes contra ataques a sua seguranca. De modo geral,as questoes de seguranca mais usadas na literatura se referem a criptografia dedados (ALEMDAR; ERSOY, 2010). No entanto, antes de estabelecer a criptogra-fia, as polıticas de seguranca devem ser abordadas em primeiro lugar.

A autenticacao forte do usuario e um dos requisitos essenciais para atenderaos requisitos de privacidade e seguranca em aplicacoes para a saude. Destaforma os usuarios deverao provar que possuem autorizacao para acessar asinformacoes fisiologicas e demais dados do paciente (KUMAR; LEE, 2012).

A confirmacao da integridade dos dados fisiologicos do paciente e um re-quisito importante que deve ser levado em consideracao nas aplicacoes wi-reless (KUMAR; LEE, 2012). Devido a natureza nas transmissoes de dadossem fio e necessario o uso de mecanismos para a garantia da integridade dasinformacoes, criando formas de identificar alteracoes nos dados geradas por pes-

Page 52: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

52

soas nao autorizadas.

Nas aplicacoes de saude estao envolvidos com as informacoes do pacientediversos tipos de profissionais, tais como medicos, enfermeiros, farmaceuticos,companhias de seguros, funcionarios de laboratorios, assistentes sociais, en-tre outros. Portanto e indispensavel a criacao de regras para acesso aos da-dos do paciente pelos usuarios do sistema, restringindo assim o acesso a estasinformacoes atraves de um mecanismo de controle (KUMAR; LEE, 2012).

6.2 Confiabilidade

A disponibilidade e confiabilidade dos servicos e dados de saude sao re-quisitos que devem ser atendidos pelas aplicacoes de saude, garantindo queas informacoes possam ser acessadas pelos cuidadores sempre que forem ne-cessarias (KUMAR; LEE, 2012). As instituicoes de saude nao irao utilizar dispo-sitivos ou aplicacoes que poderiam gerar processos judiciais ou custos em casode falhas (NOORZAIE, 2006).

A confiabilidade envolve as fases de medicao, comunicacao e analise dos si-nais vitais coletados do paciente. A medicao implica na precisao com que os da-dos fisiologicos sao aquisitados atraves de hardware e software. A comunicacaoe a etapa que precisa de mais consideracao (CHOI; ZHOU, 2010), pois envolve agarantia e integridade da transferencia de dados entre os nos sensores, unidadede processamento local e servidor central. A analise se refere a eficiencia dosalgoritmos de analise dos sinais vitais.

Para se obter confiabilidade na comunicacao dos dados pode-se utilizar umprotocolo de retransmissao (CHOI; ZHOU, 2010). Para isto, o no sensor enviaum dado com pedido de confirmacao (ACK - Acknowledgement) ao dispositivomovel destinatario. No caso no no nao receber o ACK dentro de um perıododeterminado de tempo, o no devera retransmitir os dados novamente por umnumero de vezes pre-determinado ate receber o ACK. O tipo mais adequadode infra-estrutura de rede de comunicacao a ser utilizado na aplicacao deve seravaliado de acordo com a complexidade no estado de saude e nıvel de riscodos pacientes que estao sendo tratados (NGOC; JAIN, 2008). Em unidades detratamento para tratamento de pacientes em estado grave, por exemplo, deve-seutilizar servicos com o maior QoS possıvel.

6.3 Normas e legislacoes

Existem diversas exigencias regulatorias para uso de equipamentos eaplicacoes medicas em seres humanos. Ate mesmo os equipamentos prototipos

Page 53: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

53

deverm atender rigorosos requisitos de seguranca para poderem ser testadosem pacientes (NEVES; STACHYRA; RODRIGUES, 2008). Devem ser conside-rados aspectos como ergonomia, seguranca, interface que evite erros humanos,alem de imunidade e baixa emissao de ruıdos eletromagneticos dos circuitoslogicos, circuitos analogicos, alimentacao e transferencias de dados dos siste-mas medicos.

No Brasil, para comercializar equipamentos e dispositivos para a area desaude e obrigatorio obter um registro na ANVISA. Para isto, a ANVISA exigeque o fabricante do produto obtenha um certificado de conformidade tecnica emi-tido por um organismo acreditado pelo INMETRO. A certificacao ira comprovar,atraves de diversos tipos de ensaios em laboratorios credenciados, que o equi-pamento ou dispositivo eletromedico atende a requisitos tecnicos normativos deseguranca eletrica, operacao, documentacao, producao e funcionalidade.

6.4 Consciencia do contexto

Consciencia do contexto e definida como fornecer informacoes relevantese/ou servicos para o usuario considerando a tarefa do mesmo (DEY; ABOWD,1999). Esta consciencia pode ser obtida pelo processamento e integracao dasinformacoes coletadas de sensores espalhados pelo ambiente (ALEMDAR; ER-SOY, 2010). Ainda segundo (ALEMDAR; ERSOY, 2010), e possıvel melho-rar as informacoes de contexto atraves de modelos ontologicos. Atraves darepresentacao semantica dos dados aquisitados pela rede de sensores sem fioe possıvel organizar as informacoes para serem interpretadas mais facilmente.

6.5 Energia

De acordo com (STANKOVIC, 2009), o gerenciamento de energia e um dospontos mais importantes no projeto de uma infra-estrutura de RSSF, pois a ener-gia e limitada. Ainda segundo o autor, a maior parte do consumo de energia edevido a transferencia de dados atraves da comunicacao sem fio.

A maioria dos dispositivos que usam rede sem fio operam alimentados porbaterias, portanto um dos principais requisitos para tornar estes sistemas viaveise operar com um consumo de energia muito baixo (NGOC; JAIN, 2008). Emaplicacoes crıticas e de essencial importancia que o sistema nao pare de operarporque a energia da bateria se esgotou. Portanto cada no da rede de sensorsem fio deve possuir uma fonte de energia propria com alto grau de eficienciaenergetica, o que permite o funcionamento por toda sua vida util sem necessitarde manutencao (MARCELINO, 2008; NEVES; STACHYRA; RODRIGUES, 2008).

Page 54: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

54

Segundo (ALEMDAR; ERSOY, 2010), o uso de baterias recarregaveis podenao ser recomendavel para algumas aplicacoes, tais como em sistemas para usocom idosos. Depender que o paciente ou cuidador recarregue as baterias aindae uma questao importante a ser resolvida, pois pode haver esquecimento.

Algumas aplicacoes de RSSF nao precisam de alimentacao por baterias(CHOI; ZHOU, 2010). Em RFIDs passivos, por exemplo, a energia e transmi-tida por radiofrequencia. No entanto este tipo de sistemas possui uma grandelimitacao de distancia, pois e necessario que os receptores RFIDs estejamproximos do transmissor. Outras aplicacoes usam celulas solares, tambem cha-madas de celulas fotoeletrica e celula fotovoltaicas, para converter a luz incidenteem energia eletrica por meio do efeito fotovoltaico. Porem, neste ultimo caso, ascelulas solares possuem grandes dimensoes e dependem da incidencia de raiossolares, limitando assim sua aplicacao.

6.6 Mobilidade

Segundo (ALEMDAR; ERSOY, 2010), o principal objetivo de sistemas paramonitoramento remoto de saude e permitir que os pacientes tenham uma vidaindependente de servicos de saude de alta qualidade. As redes de sensoressem fio estao possibilitando o desenvolvimento de aplicacoes que permitem eincentivam a mobilidade dos pacientes e cuidadores, criando assim sistemasubıquos para cuidados da saude.

A possibilidade de comunicacao wireless e as pequenas dimensoes dos nosde uma RSSF permitem maior mobilidade, menores restricoes ao paciente, osquais em conjunto com a computacao vestıvel, e uma forma quase invisıvel parao monitoramento de pacientes (BRADY et al., 2006).

6.7 Facilidade de uso

O desenvolvimento de aplicacoes que impactem o mınimo possıvel na vidados pacientes e um grande desafio para os pesquisadores (NOORZAIE, 2006).Para isto e necessario o desenvolvimento de sistemas uteis, amigaveis e discre-tos.

Segundo (ALEMDAR; ERSOY, 2010), os diferentes grupos de usuarios (pa-cientes e profissionais de saude) devem ter plena satisfacao ao usar o sistema.Para isto, o desenvolvimento deve levar em consideracao o desenvolvimento deinterfaces naturais, considerando as necessidades reais e as limitacoes de cadagrupo de usuarios.

Page 55: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

55

6.8 Projeto de middlewares

Existem diversos padroes de protocolos de comunicacao e hardware parainterface com os sensores usados em RSSF na area da saude. O uso de mid-dlewares reduz a complexidade e da suporte a instalacao plug and play destesdiferentes tipos de sensores (ALEMDAR; ERSOY, 2010). O objetivo e desenvol-ver recursos de software que possam ser reusados em varias aplicacoes, redu-zindo assim o esforco de desenvolvimento.

Page 56: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

7 CONSIDERACOES FINAIS E TRABALHOS FUTUROS

Existe uma grande expectativa no uso futuro da computacao ubıqua no de-senvolvimento de aplicacoes voltadas para uso em medicina. Atraves desta tec-nologia sera possıvel a aquisicao de dados de saude dos pacientes a distancia,possibilitando que os mesmos recebam cuidados medicos onde estejam. Apopulacao esta envelhecendo e a necessidade de cuidados a saude de maneiracontınua cresce a cada dia. Os profissionais de saude necessitam de que osavancos tecnologicos os auxiliem no atendimento deste desafio.

O avanco tecnologico da comunicacao movel, da computacao embarcada eminiaturizacao dos dispositivos e sensores eletronicos estao gerando significa-tivos progressos ao desenvolvimento de aplicacoes na area medica, permitindoa otimizacao da prestacao de servicos aos profissionais de saude (CASSIANI;GIMENES; MONZANI, 2009). O aprimoramento da comunicacao sem fio (wire-less) expandiu as possibilidades de supervisao e controle dos dispositivos ele-tromedicos de forma remota, ampliando a mobilidade dos profissionais de saude.A miniaturizacao de dispositivos eletronicos moveis, a maior eficiencia de bate-rias e a reducao de consumo de energia dos semicondutores potencializaramo desenvolvimento de inumeras solucoes inovadoras atraves da computacaoubıqua.

Os profissionais de saude que trabalham no ambiente hospitalar possuemuma rotina onde e essencial a mobilidade. Um importante desafio na me-lhoria dos servicos prestados nestes ambientes esta na disponibilizacao dasinformacoes geradas pelos equipamentos medicos sem prejuızo da mobilidadee sem implicar necessariamente em estresse devido ao aumento das fontes deinformacoes. Uma grande melhoria viabilizada pela computacao ubıqua paraos profissionais de saude e a possibilidade de lidar com diversas informacoessimultaneamente de maneira ”calma”, operando na periferia de sua percepcao(RODRIGUES et al., 2011). Os pacientes, por sua vez, podem ser beneficia-dos com a reducao dos erros medicos e melhores resultados no tratamento dasaude.

Page 57: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

57

O uso adequado dos avancos tecnologicos nos cuidados ao paciente e funda-mental para a mitigacao de erros medicos, trazendo mais seguranca e qualidadeaos servicos prestados aos pacientes (CASSIANI; GIMENES; MONZANI, 2009).A analise de custo-benefıcio para implantacao destas tecnologias deve tambemlevar em consideracao os ganhos com a reducao dos erros medicos. Segundoo Instituto de Medicina da Academia Nacional de Ciencias dos Estados Unidos,o custo financeiro anual oriundo dos erros medicos neste paıs fica em torno deUS$ 17 a 29 bilhoes (CORRIGAN et al., 2009). Nao ha pesquisas especıficassobre o assunto no Brasil, mas alguns estudos apontam que as denuncias deerros medicos estao crescendo nos ultimos anos (BITENCOURT et al., 2007).

O uso da computacao ubıqua no ambiente hospitalar pode tornar a interacaoentre os profissionais de saude e os equipamentos medicos mais dinamica eeficiente. Este avanco e possıvel atraves da interpretacao pelos sistemas ele-tromedicos das formas naturais de comunicacao dos humanos: fala, movimen-tos de membros do corpo humano, gestos e contexto. Quanto mais natural for ainterface entre a maquina e o homem, mais otimizados se tornarao os servicosprestados pelos estabelecimentos de saude, trazendo diversos benefıcios paraos profissionais e para os pacientes.

Existem atualmente diversas aplicacoes baseadas em redes de comunicacaosem fio que apresentam um bom potencial de uso. Muitas das demandas na areamedica ja estao sendo atendidas pelos projetos existentes. Nos ultimos anosestao sendo desenvolvidos sistemas que permitem aquisicao remota de sinaisvitais de pacientes, trazendo mais qualidade de vida e melhores resultados notratamento de saude. As inumeras pesquisas dedicadas a este assunto indicamque teremos evolucoes significativas nesta area nos proximos anos. Porem estasaplicacoes ainda precisam atender a diversos desafios, tais como seguranca, pri-vacidade, confiabilidade, normas e legislacoes, sensibilidade ao contexto, ener-gia, mobilidade e facilidade de uso.

Neste trabalho foi apresentado uma revisao dos fundamentos teoricos dacomputacao ubıqua e suas aplicacoes na medicina. Tambem foram identifica-das as pesquisas que estao sendo feitas sobre o desenvolvimento de arquitetu-ras para ambientes de execucao em computacao ubıqua na medicina. Posteri-ormente foram apresentadas as tecnologias relacionadas a aquisicao de sinaisvitais e os principais projetos de pesquisas referentes a este tema. Para finalizarforam identificados os principais desafios e requisitos para o desenvolvimento dearquiteturas na medicina ubıqua.

Page 58: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

58

7.1 Trabalhos futuros

A analise dos trabalhos relacionados indica que os projetos atuais na area demedicina ubıqua propoem solucoes para aquisicao de sinais vitais, controle dedispositivos medicos e gerenciamento das atividades dos profissionais da areade saude. As mensagens de alertas geradas pelos projetos propostos conside-ram apenas a avaliacao individual da variacao de um determinado sinal vital dopaciente. Desta forma, quando um dos parametros medidos se afasta da faixade valor considerada normal, um alerta clınico e gerado e enviado ao profissionalde saude. Como exemplo, pode-se criar uma regra para gerar um alerta quandoa temperatura do paciente estiver acima de 38◦C.

7.1.1 Proposicao de uma arquitetura de software para medicina ubıqua

Nesse contexto, como trabalhos futuros propoe-se a concepcao e desenvol-vimento de uma arquitetura de software para um ambiente ubıquo com aplicacaoespecıfica na geracao de alertas clınicos, os quais serao baseados na integracaodo contexto clınico do paciente, o que vem a configurar a situacao do paciente,identificada em um determinado intervalo de tempo. Neste sentido, objetiva-se construir um sistema computacional que identifique alertas importantes quedevam ser informados aos profissionais de saude, baseados na correlacao dedados do paciente (idade, sexo, peso, altura, dados clınicos, alergias, historicoclınico), terapia de administracao de drogas (medicamento, dose, via, tempo, mo-tivo) e sinais vitais coletadas por equipamentos eletromedicos (curvas de ECG,respiracao, oximetria, debito cardıaco, pressao arterial, temperatura, capnogra-fia, batimentos cardıaco). Considerando estas informacoes, o sistema sera ca-paz de gerar alertas, tais como incompatibilidade entre drogas administradas aopaciente, aplicacao de drogas antagonicas (se cessar de administrar uma droga,tem que cessar a outra), variacao de sinais vitais diferentes do esperado emdecorrencia da administracao de uma determinada droga, administracao de ummedicamento que o paciente possua alergia, superdosagem de medicamentos,entre outros. Como exemplo, se o medico administrar uma droga no pacientecom o objetivo de acelerar os batimentos cardıacos e isto nao ocorrer, o sistemaseria capaz de detectar e gerar um alerta clınico para informar esta situacao. Osalertas gerados serao enviados aos profissionais de saude de forma ubıqua utili-zando a abordagem siga-me, sendo recebido a qualquer momento (anytime), emqualquer lugar (anywhere) e em qualquer dispositivo computacional (any device).

A arquitetura proposta tem como premissa atender parte dos esforcos daempresa Lifemed no desenvolvimento de tecnologias para integracao de bom-bas de infusao com equipamentos de monitorizacao e diagnostico atraves da

Page 59: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

59

comunicacao wireless. Como resultados esperados, com a geracao de aler-tas clınicos inteligentes podem ser agregados qualidade, eficacia e segurancaaos procedimentos de medicacao intravenosa. Por sua vez, atraves do usoda computacao ubıqua espera-se viabilizar o emprego de novas tecnologias,otimizando a rotina clınica, reduzindo os erros de medicacao e aumentando aseguranca do paciente.

7.1.1.1 Objetivos e resultados esperados da arquitetura proposta

* Objetivo Geral

O objetivo geral deste projeto de pesquisa e a concepcao e desenvolvi-mento de uma arquitetura de software especıfica para geracao de alertasclınicos em um ambiente ubıquo, baseados na integracao do contexto clınico dopaciente, identificada como sua situacao.

* Objetivos Especıficos

• sistematizacao dos fundamentos teoricos da computacao ubıqua e suasaplicacoes na medicina;

• caracterizacao do estado da arte das arquiteturas para ambientes deexecucao em computacao ubıqua utilizadas na area de medicina;

• levantamento de pesquisas que estao sendo feitas atualmente na area demedicina ubıqua no cenario internacional;

• identificacao das tecnologias relacionadas a computacao e medicinaubıqua;

• identificacao de premissas, requisitos e tecnicas para interface com equi-pamentos eletromedicos;

• caracterizacao do ambiente medico-hospitalar e do contexto clınico do pa-ciente;

• caracterizacao do processo de administracao de drogas no ambiente hos-pitalar;

• atendimento de parte dos esforcos da empresa Lifemed no desenvolvi-mento de tecnologias para integracao de bombas de infusao com equipa-mentos de monitorizacao e diagnostico atraves da comunicacao wireless;

• concepcao da arquitetura de software para alertas clınicos em um ambienteubıquo;

Page 60: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

60

• desenvolvimento de um software prototipo para geracao de alertas clınicosno ambiente hospitalar;

• divulgacao do trabalho desenvolvido em eventos e revistas da area.

* Resultados esperados

A expectativa com o desenvolvimento de uma arquitetura especıfica parageracao de alertas clınicos e trazer mais seguranca aos pacientes e tornar arotina dos profissionais de saude mais otimizada. Como resultados a seremalcancados, pretende-se melhorar a qualidade nos servicos prestados noambiente hospitalar, melhorando a eficacia das terapias de saude e reduzindodesse modo o tempo de internacao. Tambem se objetiva tornar os medicos e en-fermeiros mais satisfeitos ao gerar solucoes que, ao mesmo tempo que ampliamsua mobilidade, potencializam sua capacidade de resolver os problemas.

Page 61: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

61

REFERENCIAS

A WOOD, J. S. G. V. L. S. Z. H. Q. C. T. D. Y. W. L. F. R. S. Context-Aware WirelessSensor Networks for Assisted-Living and Residential Monitoring. , [S.l.], 2008.

ALEMDAR, H.; ERSOY, C. Wireless sensor networks for healthcare: A survey.Computer Networks, [S.l.], 2010.

ARAUJO, R. B. d. Computacao ubıqua: princıpios, tecnologias e desafios. XXISimposio Brasileiro de Redes de Computadores, [S.l.], 2003.

AUGUSTIN, I.; YAMIN, A.; GEYER, C. F. R. Managing the Follow-me Semanticsto Build Large-scale Pervasive Applications. , [S.l.], 2005.

BARDRAM, J. E. Activity-based computing: support for mobility and collaborationin ubiquitous computing. Personal and Ubiquitous Computing, [S.l.], 2005.

BARDRAM, J. E. Activity-Based Computing for Medical Work in Hospitals. Tran-sactions on Computer-Human Interaction (TOCHI, [S.l.], 2009.

BARDRAM, J. E.; CHRISTENSEN, H. B. Pervasive Computing Support for Hos-pitals: An overview of the Activity-Based Computing Project. Pervasive Compu-ting, IEEE, [S.l.], 2007.

BARDRAM, J. E.; CHRISTENSEN, H. B.; OLSEN, A. K. Activity-Driven Com-puting Infrastructure–Pervasive Computing in Healthcare. Submitted to “Perva-sive, [S.l.], 2002.

BITENCOURT, A. G. V.; NEVES, N. M. B. C.; NEVES, F. B. C. S.; BRASIL, I.S. P. d. S.; SANTOS, L. S. C. d. Analise do erro medico em processos etico-profissionais: implicacoes na educacao medica. REVISTA BRASILEIRA DEEDUCACAO MEDICA, [S.l.], 2007.

BRADY, S.; CARSON, B.; O’GORMAN, D.; MOYNA, N. Combining wireless withwearable technology for the development of on-body networks. , [S.l.], 2006.

Page 62: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

62

CARVALHO-JR, A. R. de; RIBAS, A. D.; FIGUEIREDO, C. M. S. Algoritmo deNavegacao Robotica em Redes de Sensores sem Fio baseado no RSSI. , [S.l.],2011.

CASSIANI, S. H. d. B.; GIMENES, F. R. E.; MONZANI, A. A. S. O uso da tecno-logia para a seguranca do paciente. [S.l.]: Revista Eletronica de Enfermagem,2009.

CHOI, J. S.; ZHOU, M. Recent advances in wireless sensor networks for healthmonitoring. International Journal Of Intelligent Control And Systems, [S.l.],2010.

CORRIGAN, J. M.; DONALDSON, M. S.; KOHN, L. T.; MCKAY, T.; PIKE, K. C. ToErr Is Human:Building a Safer Health System. , [S.l.], 2009.

DEY, A. K. Providing architectural support for building context-aware applications., [S.l.], 2000.

DEY, A. K.; ABOWD, G. D. Towards a better understanding of context and context-awareness. 1st International Symposium on Handheld and Ubiquitous Com-puting, [S.l.], 1999.

DINIZ, J. R. B.; TRINTA, F. A. M. Avaliacao de um Servico de Gerenciamento deSessao para Ambientes de Medicina Ubıqua. , [S.l.], 2008.

ERICH GAMMA, R. H. R. J. J. V. Design Patterns : Elements of Reusable Object-Oriented Software. , [S.l.], 2003.

FENNIGKOH, L.; HARO, D. Human Factors and the Control of Medical Device-Related Error. Freescale - Beyondbits, [S.l.], 2009.

FERREIRA, G. G. L.; SILVA, F. L. d.; LIBRELOTTO, G. R.; AUGUSTIN, I.; YA-MIN, A. C. Introduzindo o Gerenciando de Tarefas Clınicas em um Middlewareda Computacao Pervasiva. , [S.l.], 2009.

GANTI, R. K.; JAYACHANDRAN, P.; ABDELZAHER, T. F.; STANKOVIC, J. A.SATIRE: a software architecture for smart AtTIRE. In: MOBISYS ’06: PROCEE-DINGS OF THE 4TH INTERNATIONAL CONFERENCE ON MOBILE SYSTEMS,APPLICATIONS AND SERVICES, 2006. Anais. . . [S.l.: s.n.], 2006.

GAO, T.; GREENSPAN, D.; WELSH, M.; JUANG, R. R.; ALM, A. Vital signs mo-nitoring and patient tracking over a wireless network. , [S.l.], 2005.

GARCIA, E. A. C. Biofisica. [S.l.]: Sarvier, 2002.

Page 63: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

63

GASPAR, D. C. D. Projecto e Estudo de uma Antena em Cinto. 2009. Tese(Doutorado em Ciencia da Computacao) — .

HALTEREN, A. van; BULTS, R.; WAC, K.; DOKOVSKY, N.; KOPRINKOV, G.;WIDYA, I.; KONSTANTAS, D.; JONES, V. MobiHealth: ambulant patient monito-ring. Wearable eHealth Systems for Personalised Health Management, [S.l.],2004.

IKONEN, V.; KAASINEN, E. Ethical assessment in the design of ambient assistedliving. Dagstuhl Seminar Proceedings 07462, [S.l.], 2008.

JOHNSON, R. E.; FOOTE, B. Designing reusable classes. Journal of object-oriented programming, [S.l.], 1988.

JONES, V.; HALTEREN, A. van; BULTS, R.; KONSTANTAS, D.; WIDYA, I.; HER-ZOG, R. MobiHealth: Mobile Healthcare. , [S.l.], 2003.

JONES, V.; HALTEREN, A. van; WIDYA, I.; KOPRINKOV, G.; BULTS, R.; KONS-TANTAS, D.; HERZOG, R. Mobihealth: Mobile health services based on bodyarea networks. , [S.l.], 2006.

KONSTANTAS, D.; HERZOG, R. Continuous monitoring of vital constants for mo-bile users: the MobiHealth approach. 25’ Annual lntemational Conference ofthe IEEE EMBS, [S.l.], 2003.

KROTH, M. L.; AUGUSTIN, I. Comparativo entre Projetos de Infraestrutura Com-putacional Pervasiva para Ambientes Clınicos. IX Simposio de Informatica daRegiao Centro/RS, [S.l.], 2010.

KUMAR, P.; LEE, H.-J. Security Issues in Healthcare Applications Using WirelessMedical Sensor Networks: A Survey. Sensors, [S.l.], 2012.

LORINCZ, K.; MALAN, D. J.; FULFORD-JONES, T. R. F.; NAWOJ, A.; CLAVEL,A.; SHNAYDER, V.; MAINLAND, G.; WELSH, M.; MOULTON, S. Sensor networksfor emergency response: Challenges and opportunities. PERVASIVE compu-ting, [S.l.], 2004.

LOUREIRO, A. A. F. Redes de Sensores Sem Fio. , [S.l.], 2006.

LOUREIRO, A. A. F.; NOGUEIRA, J. M. S.; RUIZ, L. B.; FREITAS MINI, R. A. de;NAKAMURA, E. F.; FIGUEIREDO, C. M. S. Redes de Sensores Sem Fio. , [S.l.],2003.

Page 64: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

64

MACHADO, A.; AUGUSTIN, I. Associando Contexto as Tarefas Clınicas na Arqui-tetura ClinicSpace. VII Simposio Brasileiro de Sistemas de Informacao, [S.l.],2011.

MAGAZINE, E.; TECHNOLOGY. Healthcare to go: the MobiHealth system. E&TEngineering and Technology Magazine, [S.l.], 2009.

MALAN, D.; FULFORD-JONES, T.; WELSH, M. Codeblue: An ad hoc sensornetwork infrastructure for emergency medical care. , [S.l.], 2004.

MANKOFF, J.; DEY, A.; HSIEH, G.; KIENTZ, J.; LEDERER, S.; AMES, M. Heu-ristic Evaluation of Ambient Displays. , [S.l.], 2002.

MARCELINO, I. Estruturacao de um sistema de monitorizacao remota e deprevencao de infoexclusao de idosos no seu domicılio - msc ipmarcelino. , [S.l.],2008.

MORAES, J. L. C. d.; SOUZA, W. L. d.; PRADO, A. F. d. Ambientede Computacao Ubıqua para o Cuidado de Saude Pervasiva (ACUCSP).lbd.dcc.ufmg.br, [S.l.], 2009.

NEVES, P.; STACHYRA, M.; RODRIGUES, J. Application of wireless sensornetworks to healthcare promotion. , [S.l.], 2008.

NG, J. W. P.; LO, B. P. L.; WELLS, O.; SLOMAN, M.; PETERS, N.; DARZI, A.;TOUMAZOU, C. Ubiquitous monitoring environment for wearable and implantablesensors (UbiMon). , [S.l.], 2004.

NGOC, T. V.; JAIN, R. Medical applications of wireless networks. , [S.l.], 2008.

NOORZAIE, I. Survey paper: medical applications of wireless networks. , [S.l.],2006.

OLIVEIRA, H. F. C. Software para aquisicao e processamento de sinais vi-tais e biomecanicos por rede sem fios. 2011. Tese (Doutorado em Ciencia daComputacao) — Universidade do Minho.

PANTELOPOULOS, A.; BOURBAKIS, N. A Survey on Wearable Biosensor Sys-tems for Health Monitoring. 30th Annual International IEEE EMBS Conference,[S.l.], 2008.

PIZARRO, P. J. C. MonitorIP – Monitoramento de sinais vitais atraves de umarede IP. , [S.l.], 2003.

Page 65: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

65

RODRIGUES, S. L. uMED - Uma Arquitetura para Desenvolvimento de SoftwareDirecionada a Medicina Ubıqua. , [S.l.], 2011.

RODRIGUES, S. L.; DILLI, R. M.; WARKEN, N.; VENECIAN, L. R.; LOPES, J.L. B.; AUGUSTIN, I. Um Framework para o Gerenciamento de Aplicacoes Direci-onadas a Medicina Ubıqua. , [S.l.], 2011.

SHNAYDER, V.; CHEN, B.-r.; LORINCZ, K.; FULFORD-JONES, T. R. F. Sensornetworks for medical care. , [S.l.], 2005.

SILVA, F. L. d. ClinicSpace: modelagem de uma ferramenta-piloto paradefinicao de tarefas clınicas em um ambiente de computacao pervasiva ba-seado em tarefas e direcionado ao usuario. 2009. Tese (Doutorado em Cienciada Computacao) — .

SILVA MARQUES, A. A. da. Dispositivo Electronico Pessoal para Aquisicaode Dados obtidos por Sensores. 2010. Tese (Doutorado em Ciencia daComputacao) — Faculdade de Engenharia da Universidade do Porto.

SILVEIRA, C. S. Uma proposta de tecnologia embarcada na internacao domici-liar. , [S.l.], 2007.

STANKOVIC, S. Medical Applications Based on Wireless Sensor Networks. ,[S.l.], 2009.

STEELE, R.; LO, A.; SECOMBE, C.; WONG, Y. K. Elderly persons’ perceptionand acceptance of using wireless sensor networks to assist healthcare. Interna-tional Journal of Medical Informatics, [S.l.], 2009.

SUNNY CONSOLVO, P. R.; SHELTON, B. E. The CareNet Display: Lessons Le-arned from an In Home Evaluation of an Ambient Display. , [S.l.], 2004.

TABAR, A. M.; KESHAVARZ, A.; AGHAJAN, H. Smart Home Care Network usingSensor Fusion and Distributed Vision-based Reasoning. , [S.l.], 2006.

VAN LAERHOVEN, K.; LO, B. P. L.; NG, J. W. P.; THIEMJARUS, S.; KING, R.;KWAN, S.; GELLERSEN, H.-W.; SLOMAN, M.; WELLS, O.; NEEDHAM, P.; PE-TERS, N.; DARZI, A.; TOUMAZOU, C. Medical healthcare monitoring with wea-rable and implantable sensors. , [S.l.], 2004.

VENECIAN, L. R. Um Mecanismo de Sensibilidade ao Contexto com SuporteSemaAUntico para Computac Aßa AEo Ub AAf±qua., [S.l.], 2010.

Page 66: Desafios e requisitos para o desenvolvimento de ...inf.ufpel.edu.br/site/wp-content/uploads/2013/12/TIAlexandre.pdf · ALEXANDRE RENATO RODRIGUES DE SOUZA Desafios e requisitos

66

WAC, K.; BULTS, R.; BEIJNUM, B. van; WIDYA, I.; JONES, V.; KONSTANTAS, D.;VOLLENBROEK-HUTTEN, M. Mobile Patient Monitoring: The MobiHealth Sys-tem. , [S.l.], 2009.

WEISER, M. The Computer for the 21st Century. Scientific American, [S.l.],1991.

WOOD, A.; VIRONE, G.; DOAN, T.; CAO, Q.; SELAVO, L.; WU, Y.; FANG, L.; HE,Z.; LIN, S.; STANKOVIC, J. ALARM-NET: Wireless sensor networks for assisted-living and residential monitoring. , [S.l.], 2006.

YAMIN, A. C. Arquitetura para um Ambiente de Grade Computacional dire-cionado as Aplicacoes Distribuıdas, Moveis e Conscientes do Contexto daComputacao Pervasiva. 2004. Tese (Doutorado em Ciencia da Computacao) —Universidade Federal do Rio Grande do Sul.

YAMIN, A. C.; AUGUSTIN, I.; FERREIRA, G. P. Grade Computacional comoInfra-estrutura para a Computacao Pervasiva/Ubıqua. ERAD, [S.l.], 2008.