UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL - UNIJUÍ DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS LEANDRO FERREIRA PAZ ACESSO MÓVEL ÀS INFORMAÇÕES DE SAÚDE DO PACIENTE UTILIZANDO COMPUTAÇÃO UBÍQUA Santa Rosa 2012 LEANDRO FERREIRA PAZ ACESSO MÓVEL ÀS INFORMAÇÕES DE SAÚDE DO PACIENTE UTILIZANDO COMPUTAÇÃO UBÍQUA Trabalho de Conclusão de Curso apresentado ao curso de Ciência da Computação, do Departamento de Ciências Exatas e Engenharias, da Universidade Regional do Noroeste do Estado do Rio Grande do Sul, como requisito parcial para obtenção do grau de Bacharel em Ciência da Computação. Orientador: Me. Professor Juliano Gomes Weber Santa Rosa 2012 Dedicatória Aos meus filhos Isadora e João Pedro, luzes da minha vida. Na tentativa de abrandar a ausência destes dias e noites de leitura e escrita, sem poder dar-lhes a atenção ideal e necessária que, espero, um dia não ressintam. À minha esposa Margiane que muito resiliente manteve o nosso cotidiano andando, me encorajando em todo momento de turbulência. AGRADECIMENTOS Agradeço aos meus Pais por me concederem este espaço em suas caminhadas nesta encarnação e sou grato pelos ensinamentos, pois me deram suporte para enfrentar as dificuldades da vida. Saudades, pai! Agradeço ao meu orientador, Professor Juliano que, em paralelo aos seus conselhos técnicos e científicos, soube amenizar as cobranças e entender que temos limites. Obrigado pela parceria e conversas no talk ao longo das madrugadas, pelas distrações, pela disponibilidade, me ajudando não só no desenvolvimento do trabalho, mas principalmente a fugir de todo o estresse. Sua motivação e positividade foram essenciais para a realização deste trabalho, muito obrigado chefe! Aos professores Vinicius Maran, Alencar Machado e Rogério Martins pelas indiretas e diretas algumas vezes, colocando-me no caminho certo. Muito obrigado! RESUMO As informações geradas nos Registros Eletrônicos de Saúde (RES) são essenciais no auxílio à tomada de decisões por parte de médicos e enfermeiros. No entanto, a burocracia, a dificuldade e o tempo gasto no acesso às informações de pacientes dificultam o trabalho dos profissionais de saúde. Desta forma, faz-se necessária a definição de uma arquitetura, que, aliada a tecnologias provenientes da Computação Ubíqua, visa a fornecer informações a profissionais de saúde de forma ágil em relação às soluções atuais. Este trabalho propõe uma arquitetura de software para celular que possibilite a consulta de informações médicas utilizando conceitos e tecnologias provenientes da Computação Ubíqua. Palavras-chave: Computação Ubíqua na Saúde, Sistemas de Computação Móveis, Telemedicina Móvel, Computação Ubíqua. ABSTRACT The information generated in the EHR (Electronic Health Records) is essential in assisting decision making by doctors and nurses. However, the bureaucracy, the difficulty of access and time spent in accessing patient information hamper the work of health professionals. This, it is necessary to define an architecture that combined technologies from the Ubiquitous Computing, aims to provide information to health professionals in a fast over current solutions. This paper proposes a software architecture that enables the cell to query medical information using concepts and technologies from the Ubiquitous Computing. Keywords: Healthcare Ubicomp, Mobile Computing, Mobile Telemedicine, Ubiquitous Computing. LISTA DE SIGLAS 1D 2D 3D ACID AmUbAS ANSI API APS ASTM CC/PP CCR CDA CID10 CK CML CMP - COMAH EAN EK ER7 GNU GPS GSM GTSH HAPI HL7 IDC IDE - Uma dimensão Duas dimensões Três dimensões Atomicidade, Consistência, Isolamento e Durabilidade Ambiente Ubíquo de Apresentação de Slides American National Standards Institute Application Programming Interface Atenção Primária a Saúde American Society for Testing and Materials Composite Capability/Preference Profiles Continuity Care of Record Clinical Document Architecture Cadastro Internacional de Doenças Context Knowledge Context Modeling Language Context UML Profile Cognitividade com sensibilidade a conexão como suporte a otimização de recursos em Malha Heterogênea European Article Number External Knowledge Enconding Rules Seven General Public License Geo-Posicionamento por Satélite Global System for Mobile Communications Gator Tech Smart House HL7 Application Programming Interface Health Level Seven International Data Corporation Integrated Development Environment IrDA ITF MVJ OHA ORM PC PDF PEP PHCS PRC QR Code RES RFID RIM RSS SAMU SAUM SDK SQL S-RES UML UPC URL W3C XML - Infrared Data Association Interleave Two Five Máquina Virtual Java Open Handset Alliance Object Role Modeling Proceduralized Context Portable Data File Prontuário Eletrônico do Paciente Primary Health Care System Padronização do Registro Clínico - Quick Response Code - Registro Eletrônico de Saúde Radio Frequency Identification Reference Information Model Reduced Space Symbology Sistema de Atendimento Móvel de Urgência Sistema de Assistência a Urgência Médica Software Development Kit Structured Query Language Sistema de Registro Eletrônico de Saúde Unified Modeling Language Universal Product Code Uniform Resource Locator World Wide Web Consortium Extensible Markup Language LISTA DE FIGURAS Figura 1: Diferentes integrações na computação ubíqua. ......................................................... 15 Figura 2: Compartilhamento de recursos da computação móvel e pervasiva com a ubíqua. ... 18 Figura 3: Dimensões da computação ubíqua. ........................................................................... 19 Figura 4: Princípio da descentralização na Computação Ubíqua. ............................................ 20 Figura 5: Diversidade das funcionalidades na Computação Ubíqua. ....................................... 21 Figura 6: Tipos de contextos e suas dinâmicas. ....................................................................... 30 Figura 7: Propaganda sensível ao contexto no GMail. ............................................................. 32 Figura 8: Exemplo de guias turísticos móveis .......................................................................... 32 Figura 9: Conexões ponto-a-ponto e multiponto com Bluetooth. ............................................ 36 Figura 10: Exemplo de uma rede de sensores sem fio. ............................................................ 37 Figura 11: Processo de execução programas Java. ................................................................... 39 Figura 12: Funcionamento do HL7. ......................................................................................... 42 Figura 13: Criação de XML e documento pelo CCR. .............................................................. 44 Figura 14: Previsão de conexões inteligentes até 2016. ........................................................... 48 Figura 15: Ciclo de vida das activities...................................................................................... 50 Figura 16: Download, instalação e funcionamento do Barcode Scanner................................. 51 Figura 17: Exemplo de QR Code. ............................................................................................ 51 Figura 18: Visão do sistema. .................................................................................................... 53 Figura 19: Arquitetura do sistema. ........................................................................................... 54 Figura 20: Diagrama entidade-relacionamento. ....................................................................... 56 Figura 21: Diagrama de classes. .............................................................................................. 58 Figura 22: Diagrama de classes do serviço HL7 da aplicação. ................................................ 59 Figura 23: Fluxograma do processo de identificação de contexto. .......................................... 60 Figura 24: Cenário de uso......................................................................................................... 61 Figura 25: Tela de login. .......................................................................................................... 62 Figura 26: Tela de leitura do QR Code..................................................................................... 63 Figura 27: Tela de menu. .......................................................................................................... 63 Figura 28: Tela de dados pessoais. ........................................................................................... 64 Figura 29: Tela de exames. ....................................................................................................... 65 Figura 30: Tela de procedimentos médicos. ............................................................................ 65 Figura 31: Tela de diagnósticos. .............................................................................................. 66 Figura 32: Tela de alergias. ...................................................................................................... 66 Figura 33: Tela de doenças crônicas......................................................................................... 67 LISTA DE TABELAS Tabela 1: Comparação entre os modelos de contexto. ............................................................. 29 Tabela 2: Exemplos de tecnologias sem fio. ............................................................................ 35 Tabela 3: Teste de Desempenho. .............................................................................................. 67 LISTA DE QUADROS Quadro 1: As Principais Tendências em Computação. ......................................................................... 18 Quadro 2: Exemplo mensagem HL7. .................................................................................................... 42 Quadro 3: Quantidade de caracteres armazenados nos QR Code.......................................................... 52 Quadro 4: Resultados do Teste de Usabilidade. .................................................................................... 68 SUMÁRIO INTRODUÇÃO ........................................................................................................................ 14 2 REVISÃO BIBLIOGRÁFICA .............................................................................................. 17 2.1 HISTÓRICO DA COMPUTAÇÃO UBÍQUA .................................................................. 17 2.2 RELAÇÃO ENTRE COMPUTAÇÃO UBÍQUA, MÓVEL, PERVASIVA E REALIDADE VIRTUAL ......................................................................................................... 18 2.3 PRINCÍPIOS DA COMPUTAÇÃO UBÍQUA ................................................................... 19 2.4 CENÁRIOS DA COMPUTAÇÃO UBÍQUA .................................................................... 21 2.5 ELEMENTOS CHAVE DE UM AMBIENTE UBÍQUO .................................................. 23 2.6 CONTEXTO....................................................................................................................... 25 2.6.1 Representação do Contexto .......................................................................................... 27 2.6.2 Tipos de Contexto .......................................................................................................... 29 2.6.3 Sistemas Sensíveis ao Contexto .................................................................................... 30 2.6.4 Exemplos de Sistemas Sensíveis ao Contexto .............................................................. 31 2.7 DESAFIOS DA COMPUTAÇÃO UBÍQUA ..................................................................... 33 2.8 A COMPUTAÇÃO UBÍQUA E AS TECNOLOGIAS NECESSÁRIAS ......................... 34 2.9 COMPUTAÇÃO UBÍQUA NA SAÚDE .......................................................................... 40 2.10 REGISTRO ELETRÔNICO DE SAÚDE ........................................................................ 40 2.11 PADRÕES DE INTEROPERABILIDADE DE INFORMAÇÕES MÉDICAS .............. 41 2.11.1 HL7 ............................................................................................................................... 42 2.11.2 CCR .............................................................................................................................. 43 2.11.3 Diferenças entre CCR e HL7 ...................................................................................... 44 3 TRABALHOS RELACIONADOS .................................................................................... 45 4 FERRAMENTAS E METODOLOGIA DE DESENVOLVIMENTO ........................... 46 4.1 TECNOLOGIAS USADAS ............................................................................................... 46 4.1.1 API HL7 para JAVA – HAPI ....................................................................................... 46 4.1.2 Android ........................................................................................................................... 47 4.1.3 Barcode Scanner ............................................................................................................ 50 4.1.4 QR Code ......................................................................................................................... 51 4.1.5 SQLite ............................................................................................................................. 52 4.1.6 Técnica de Representação do Contexto ....................................................................... 52 4.2 DESENVOLVIMENTO..................................................................................................... 53 4.2.1 Visão Geral do Sistema ................................................................................................. 53 4.2.2 Arquitetura do Sistema ................................................................................................. 53 4.2.3 Diagrama Entidade-Relacionamento ........................................................................... 54 4.2.4 Diagrama de Classes da Aplicação .............................................................................. 57 4.2.5 Diagrama de Classes do Serviço HL7 .......................................................................... 59 4.2.6 Sensibilidade ao Perfil do Usuário ............................................................................... 59 5 FUNCIONALIDADES DO APLICATIVO E TESTES .................................................. 61 5.1 FUNCIONALIDADES ...................................................................................................... 61 5.2 TELAS DO APLICATIVO ................................................................................................ 62 5.3 REALIZAÇÃO DE TESTES ............................................................................................. 67 CONCLUSÃO......................................................................................................................... 69 REFERÊNCIAS BIBLIOGRÁFICAS ................................................................................. 70 14 INTRODUÇÃO Os sistemas de acompanhamento do histórico de saúde do paciente, também conhecidos como Sistema de Registro Eletrônico de Saúde (S-RES), contribuem consideravelmente no processo de tomada de decisões realizado por profissionais clínicos e no auxílio à prevenção de doenças. Entretanto, a quantidade de dados apresentada nas consultas realizadas nos sistemas atuais inviabiliza o trabalho dos médicos e enfermeiros, pois a procura da informação de que se necessita no momento do atendimento ao paciente exige tempo e atenção (VICENTINI et al, 2010). A utilização de novas tecnologias torna o conhecimento na área da saúde mais acessível e facilita o compartilhamento de informações médicas. Entre as áreas inovadoras que podem contribuir com a área da medicina, destacar-se a computação ubíqua ou internet das coisas, que através da aplicação da computação de forma onipresente (inserida de forma invisível no ambiente) possibilita uma melhora da interação entre os diversos equipamentos médicos, informações em bancos de dados de diversos modelos e os usuários (profissionais da saúde) no ambiente hospitalar (GOULART et al, 2010). Com o constante aumento no uso de aparelhos celulares, tablets e smartphones, a resistência dos usuários em relação ao seu uso no ambiente profissional diminuiu e permitiu a realização de pesquisas relacionadas à integração de dispositivos (fixos e móveis) de uma forma dinâmica (Figura 1). Este é um dos princípios da computação ubíqua, ou seja, a capacidade de utilizar diversos recursos da computação móvel em diferentes lugares, a qualquer momento (WEISER, 1991). Outro importante aspecto dessa concepção é a interação do usuário com o ambiente. A utilização de etiquetas bidimensionais em objetos proporciona que eles sejam identificados apenas de uma forma (MELOAN, 2003). O que resulta numa 15 interação entre o mundo virtual e físico com a internet das coisas (SIORPAES, 2006). Figura 1: Diferentes integrações na computação ubíqua. Fonte: http://www.ntt.com/release_e/letters/BK_is/03_apr/i1.html Outra característica da computação ubíqua é a sensibilidade ao contexto. A aplicação dita sensível ao contexto coleta elementos do ambiente e dos usuários inseridos neste e a partir deste ponto diversas adaptações podem ser realizadas de forma proativa por sistemas ubíquos. Estas modificações ajudam na realização das tarefas do usuário, pois através da combinação de interfaces intuitivas e processos proativos baseados em contexto, os usuários não precisam de conhecimentos específicos de computação para utilizar os sistemas de saúde de forma plena (SOUZA, 2010). De acordo com o trabalho realizado por Chen (2002), o contexto computacional pode ser definido como um conjunto de informações: (i) físicas; (ii) dos usuários ou do tempo; e, (iii) emocionais, que projetam dados que auxiliam sistemas e usuários na realização de suas tarefas. Informações do contexto do usuário podem adaptar seu perfil em relação às atividades desempenhadas por ele, ou seja, moldar a aplicação para que se torne de acordo com as suas preferências, tornando essas mudanças algo imperceptíveis para o usuário (MACHADO; AUGUSTIN, 2011). Dey (2001, p.3, tradução nossa), “contexto é qualquer informação que pode ser usado para caracterizar a situação de uma entidade. Uma entidade é uma pessoa, lugar ou objeto que considerado relevante para a interação entre um usuário e uma aplicação”. Com base nessas informações, este trabalho propõe uma arquitetura integrando sistemas móveis de consulta às informações de pacientes para ambientes hospitalares e tem 16 por objetivo propor um recurso diferenciado na identificação do contexto. O procedimento de consulta usará sensibilidade ao contexto do usuário a partir do tipo de profissional clínico, ou seja, o sistema destacará informações na tela que sejam relevantes para o diagnóstico ou tratamento de doenças. Soma-se à proposta, o uso de um padrão de comunicação médica, interoperável, o Health Level Seven (HL7) (HL7, 2011). O acesso ao cadastro do paciente será através de leitura de código de barras bidimensional. O trabalho está organizado como segue. O Capítulo 1 descreve a Introdução. O Capítulo 2 apresenta a Revisão Bibliográfica. Os Trabalhos Relacionados no Capítulo 3. O Capítulo 4 descreve as Ferramentas e Metodologia de Desenvolvimento. No Capítulo 5, as Funcionalidades do Aplicativo e Testes. Por fim, a Conclusão e Referências Bibliográficas. 17 2 REVISÃO BIBLIOGRÁFICA Neste capítulo é apresentada a revisão bibliográfica dos conceitos utilizados no trabalho, como: definição de computação ubíqua, de onde foi concentrada a concepção principal do trabalho, sensibilidade ao contexto, características do Registro Eletrônico de Saúde e as tecnologias de troca de mensagens médicas. 2.1 HISTÓRICO DA COMPUTAÇÃO UBÍQUA O termo computação ubíqua surgiu pela primeira vez em um artigo escrito por Mark Weiser, em 1991. The Computer for the 21st Century, descreve que interação entre as pessoas e os computadores se tornará imperceptível, ou seja, tudo acontecerá de forma mais natural possível, sem que o usuário perceba totalmente que está acionando um dispositivo ou uma aplicação. Em outras palavras, ela tem o intuito de se aproveitar da evolução da tecnologia, promovendo uma interação com maior transparência entre usuário e computador. Transparente no sentido de o utilizador estar manuseando um dispositivo ou uma aplicação sem ter que saber exatamente como eles operam. Outro aspecto da computação ubíqua ou internet das coisas está na capacidade de se conectar pela computação móvel a diversos recursos em diferentes lugares, a qualquer momento, com a disposição de todas as funcionalidades que estes recursos oferecem (WEISER, 1991). Pesquisando mais a fundo o significado etimológico da palavra ubíqua – do latim ubiquu, adjetivo – que está ao mesmo tempo em toda parte. Através da tecnologia móvel, sensoriamento de ambiente e interoperabilidade na comunicação, a computação se torna presente em qualquer lugar, no instante que o usuário desejar. Isso é um ambiente ubíquo que dotado de sensores, de dispositivos móveis, tudo trabalhando de forma recíproca; trocando informações a todo o momento, colhendo do cenário as informações relevantes na identificação de preferências e ajudando na realização de tarefas. A origem da computação ubíqua vem da passagem da Internet e da Computação Distribuída. Conforme demonstra o Quadro 1. Antigamente, nos mainframes, muitas pessoas trabalhavam num mesmo computador, depois chegaram os personal computers, uma pessoa para cada computador. Hoje, nesta nova etapa da evolução tecnológica, são muitos computadores para uma pessoa (DOMINGUES, 2008). 18 As Principais Tendências em Computação Mainframe Uma máquina para vários usuários Computador Pessoal Uma máquina para cada usuário Computação Ubíqua Muitas máquinas, um usuário. Quadro 1: As Principais Tendências em Computação. Fonte: http://www.johnseelybrown.com/calmtech.pdf. 2.2 RELAÇÃO ENTRE COMPUTAÇÃO UBÍQUA, MÓVEL, PERVASIVA E REALIDADE VIRTUAL Existem algumas diferenças conceituais entre os termos computação ubíqua e pervasiva, móvel e realidade virtual. A primeira é a intersecção da computação móvel com a pervasiva, ou seja, qualquer dispositivo móvel portado por uma pessoa em movimento consiga personalizar as aplicações, serviços, isto é, a partir da situação; configurá-los dinamicamente de acordo com a necessidade do usuário (GOMES, 2007) (CIRILO, 2007). A Figura 2 demonstra esta combinação. Computação Móvel Computação Ubíqua Computação Pervasiva Figura 2: Compartilhamento de recursos da computação móvel e pervasiva com a ubíqua. Fonte: https://twiki2.dcc.ufba.br/pub/MAT570FG/LivroseArtigos/045_AraujoRB.pdf A computação móvel envolve os sistemas computacionais, aplicações que executados nos mais diversos dispositivos trocando informações através de uma rede sem fio, permitindo assim a mobilidade dos aparelhos. A diferença dela para a computação ubíqua é que os dispositivos móveis não conseguem contextualizar as aplicações, isto é, não adequam ao usuário os serviços que estão distribuídos na rede sem para que ele possa realizar suas tarefas sem se preocupar com a tecnologia. Já a computação pervasiva relata que os computadores estarão distribuídos, localizados de forma invisível ou visível ao usuário. Assim, entende-se que os dispositivos não seriam mais máquinas estáticas, mas trabalhando mutuamente com usuários, agindo como sensores. Além disso, transmitindo informações para outros dispositivos e para aplicações (DOMINGUES, 2008). 19 A mobilidade na computação ubíqua é alta comparada com a pervasiva, conforme a Figura 3. Essa transição de equipamentos dentro do espaço é o transporte de aplicações que conversam com outros recursos computacionais, independente de dispositivo, seja qual for sua arquitetura, a mobilidade deve estar presente. Como na computação pervasiva nem todo dispositivo é móvel, é importante manter constantemente a disponibilidade de recursos (GOMES, 2007). Esse contexto pode-se considerar um desafio para a computação ubíqua: oferecer um suporte a essa movimentação de dados (ARAÚJO, 2003). Nível de insersão computacional ALTO Computação pervasiva Computação ubíqua BAIXO ALTO Sistemas tradicionais de computação Nível de mobilidade Computação móvel BAIXO Figura 3: Dimensões da computação ubíqua. Fonte: http://pet.ece.iisc.ernet.in/pallapa/issues.pdf Kirner e Siscoutto (2007), com relação à realidade virtual é “como uma nova geração de interface que usando representações tridimensionais mais próximas da realidade do usuário, permite romper a barreira da tela, além de possibilitar interações mais naturais”. Isto é, o mundo virtual é construído a partir da realidade do ser humano. Diferentemente da realidade virtual, a computação ubíqua invade o mundo real com computadores, dispositivos, sensores, redes sem fio, aplicações (WEISER, 1991). 2.3 PRINCÍPIOS DA COMPUTAÇÃO UBÍQUA Araújo (2001), a computação ubíqua possui alguns princípios que, entre os quais se destacam três: 20 Descentralização: A distribuição dos serviços entre os dispositivos na rede torna cada equipamento responsável por uma tarefa ou mais. Como resultado, é formada uma constante troca de informações, tornando o ambiente inteligente e podendo captar dados deste ou do usuário. Assim é um sistema distribuído. Outro ponto importante é a necessidade de atualizar dispositivos de diferentes capacidades e aspectos, conforme Figura 4. Para isso os servidores devem ser capazes de estabelecer essas diferenças, e possuir grande capacidade de processamento para poder tratar a diversidade de dispositivos. Figura 4: Princípio da descentralização na Computação Ubíqua. Fonte: http://sin054-dsu-20111.blogspot.com.br/2011/02/aula-03-principios-fundamentais-da.html Diversidade: O usuário de um desktop possui atualmente muitas ferramentas disponíveis para a realização de suas atividades. Eles podem pesquisar na web pelo navegador, criar planilhas eletrônicas, digitar textos, enviar e-mails. Ou seja, diversas funcionalidades num dispositivo e na maioria das vezes, executando uma sobre as outras. O princípio da diversidade defende a ideia de que cada dispositivo pode ter funcionalidades que são executadas melhor que em outros aparelhos, conforme Figura 5. Na computação ubíqua, esse aspecto se refere a atender necessidades específicas para usuários particulares. Outra concepção da diversidade é poder lidar com arquiteturas distintas de dispositivos, e desenvolvendo tecnologias comuns para plataformas com limitações próprias. 21 Figura 5: Diversidade das funcionalidades na Computação Ubíqua. Fonte: http://sin054-dsu-20111.blogspot.com.br/2011/02/aula-03-principios-fundamentais-da.htm Conectividade: a computação ubíqua detém a ideia de que aparelhos movam-se juntamente com usuários, acessando todos os serviços disponíveis entre muitas redes heterogêneas, de forma que o utilizador não perceba essa mudança. Para garantir esta mobilidade é imprescindível o uso de padrões de comunicação, que tornem interoperável a troca de informações. 2.4 CENÁRIOS DA COMPUTAÇÃO UBÍQUA Diversos cenários podem ser criados usando computação ubíqua. Entre eles podemse destacar hospitais, casas, indústrias, trânsito, educação, etc. Mas para que isso aconteça há necessidade de mudança nos paradigmas de desenvolvimento de softwares atualmente. Carro e Wagner (2006, p.1) “O modelo atual em que o projetista de software utiliza uma abstração de alto nível do hardware, terá de ser modificado, pois deve-se tirar proveito da computação massivamente paralela mas sem descuidar do consumo de energia e confiabilidade [...]”. A seguir são descritos 4 cenários da computação ubíqua: Hospitais: não é difícil de imaginar que no futuro os hospitais, partindo dos grandes centros e se estendendo até regiões mais remotas, terão capacidade de solucionar os problemas mais complexos. Com a ajuda da tecnologia, profissionais de saúde, através de um middleware que disponibilizará serviços personalizados em todo canto do ambiente hospitalar, portando dispositivos móveis, médicos terão acesso ao Prontuário Eletrônico do Paciente (PEP) através da identificação por etiquetas inteligentes, minimizando assim o trabalho mecânico e burocrático. Moraes, Souza e Prado (2009, 22 p.218) “Ambientes de Computação Ubíqua, em comunidades, lares e hospitais, podem ser extremamente úteis na construção de um modelo de Cuidado de Saúde Pervasivo”. Existirão sistemas que irão realizar checagens completas nos pacientes quando estes adentrarem no ambiente hospitalar, identificando qualquer anomalia e podendo até diagnosticá-los, se utilizando das informações contidas no PEP. Outro cenário é disparar alertas para que uma equipe de médicos faça atendimentos domiciliares. Sensores estarão a todo o momento cuidando pervasivamente de enfermos em suas casas. Um exemplo de projeto na área da medicina é ClinicSpace que já há algum tempo vem sendo desenvolvido com o objetivo de auxiliar os profissionais de saúde a gerenciar, executar e programar as tarefas diárias. Os médicos podem personalizar o gerenciamento das atividades clínicas e que devem responder às questões que definem o seu contexto (GMOB, 2010). Casas inteligentes: totalmente comunicáveis, as casas inteligentes do futuro deixarão a temperatura agradável antes mesmo de o usuário entrar no seu lar. Com bases nas informações de temperatura externa e interna, elas adequarão o sistema de climatização para a temperatura ideal. Poderão desligar o forno que foi esquecido ligado, acender a lareira, as luzes. Transformar a parede da sala numa TV de muitas polegadas. Acessar o programa favorito do utilizador, com bases no contexto do perfil do dono da casa. Poderão abrir e fechar cortinas, regulando a iluminação. Elas estarão sensoriando o ambiente, buscando sinais vitais de seus ocupantes, pois em caso de alguma anomalia poderiam disparar um alerta de voz. O uso de sensores de presença acoplados à roupa, calçados, ou até mesmo ao corpo do usuário tornará o ambiente monitorado por dispositivos, aplicações. Mateas et al apud Bolzani (2010, p.39) “A Computação Ubíqua tenta unir a tecnologia ao modo de vida, na forma de pequenos dispositivos computacionalmente integrados, servindo múltiplos usuários da casa”. Gator Tech Smart House (GTSH) é um projeto de casa inteligente desenvolvido pela Universidade da Flórida desde 2005. Essa concepção surgiu com a necessidade de ajudar pessoas idosas e com necessidades especiais mantendo a qualidade de vida. Os setores da casa são sensoriados, monitorando o estado de seus habitantes. Um middleware foi criado, ele é dividido em camadas de serviços, cada um responsável por alguma função (RIES, 2005). Educação: na escola do futuro, a educação ubíqua será criar métodos de aprendizagem a partir das dificuldades que cada aluno terá. Para Barbosa (2007, p.15) Educação Ubíqua é “[...] como um processo que ocorre em qualquer tempo e lugar, de forma 23 contínua, contextualizada e integrada ao cotidiano do aprendiz”. Com a evolução tecnológica, principalmente na parte de dispositivos móveis como os celulares, a informação ficará acessível em qualquer lugar a qualquer momento, resultando num processo de aprendizagem mais abrangente. Barbosa et al (2008) “a mobilidade do aprendiz e a percepção dos elementos que estão em seu contorno (contexto) são parte do processo educativo, que pode ocorrer de forma contínua, global e transparente”. Um aluno poderá ver um conteúdo de diversas formas, direto na sua classe, como texto, vídeos, imagens transitando em frente aos seus olhos. Um exemplo de projeto é o Ambiente Ubíquo de Apresentação de Slides (AmUbAS), que tem como objetivo compartilhar objetos de aprendizagem, como apresentações multimídia, proporcionando maior dinâmica às aulas. O intuito do sistema é impulsionar a interação entre o corpo docente e discente, tanto dentro como fora da sala de aula (VIDAL et al, 2010). Indústrias: num sistema de produção em larga escala é comum haver uma quantidade enorme de peças, máquinas e trabalhadores. Nesse cenário a dificuldade de encontrar um funcionário, fazer a contagem de estoque, identificar peças se torna cada vez maior conforme aumenta a produção. O uso de etiquetas inteligentes como Radio Frequency Identification (RFID) possibilita a localização rápida de um empregado através de leitores que varrem um ambiente, dependendo da sua capacidade de rastreamento. Cada ferramenta ou peça poderá portar uma etiqueta RFID que, acionando-se um leitor em instantes pode ser feita a contagem do estoque. A identificação de objetos se torna fácil e ágil com códigos de barras bidimensionais. 2.5 ELEMENTOS CHAVE DE UM AMBIENTE UBÍQUO Um ambiente ubíquo é tomado por dispositivos móveis, aplicativos móveis, redes sem fio, sensores, todos diferentes um dos outros, e onde existe uma constante troca de informações. Para que isso ocorra é necessário um serviço que providencie a mobilidade do usuário e o envio de dados entre os dispositivos. Tudo acontecendo de uma forma transparente para o utilizador, isto é, sem que haja necessidade dele saber exatamente como está acontecendo todo o processo. Uma vez que ambientes ubíquos são também geradores de situações, ou seja, a todo o momento ocorre um fato diferente, seja uma movimentação do usuário, uma necessidade específica para realizar uma tarefa, sejam ações improvisadas do usuário, um ambiente ubíquo 24 tem que ser capaz de conseguir se moldar às essas modificações das características do utilizador e do cenário, interpretando da melhor forma os elementos do contexto atual. Conhecer os fatos que rodeiam o usuário da aplicação faz com que esta possa interagir e agir mais proveitosamente em prol deste. A aplicação deve ser ciente do contexto, adaptando-se automaticamente às mudanças no ambiente e às necessidades correntes do usuário, sem exigir sua atenção. Tais aplicações devem explorar características do ambiente como localização do usuário, pessoas próximas, hora do dia, etc... fornecendo informações adequadas à situação ou atividade. (MACHADO, 2010, p.17) As características que são usadas como entradas nessas aplicações móveis e que podem se modificar a qualquer momento, devem ser captadas de forma integral para que sejam oferecidos serviços mais eficientes. E essas modificações podem ser vistas nas movimentações do usuário que modificam também as condições do ambiente em alguns aspectos, por exemplo, condições físicas, recursos computacionais disponíveis, etc (LOUREIRO et al, 2010). Nesse sentido, elementos chave do ambiente ubíquo são essenciais para uma aplicação poder se adaptar. Segundo Ley (2007, p.64), os elementos chave de um ambiente de computação ubíqua são: identificação, localização, detecção e conexão. Identificação Quando existe uma grande quantidade de objetos, indivíduos e fizer com que se tornem úteis, agindo de forma inteligente, há necessidade identificá-los de forma única no ambiente ubíquo. Enfim, os mecanismos que captarão as situações poderão escolher pelas melhores fontes de sinais disponíveis, ou a que se adequar ao tipo de contexto solicitado. Exemplo de tecnologias de identificação: RFID e códigos de barras bidimensionais. Localização A localização de objetos ou indivíduos caracteriza mais um importante papel num ambiente ubíquo: poder descobrir pessoas e objetos. Nino (2009, p.24) “[...] aplicações podem explorar tanto informações explícitas fornecidas pelo sistema, como também informações implícitas provenientes do contexto físico e computacional do ambiente e seus usuários”. Detecção 25 Identificação e localização geram muitas informações, porém, detectar a presença de alterações no ambiente ubíquo através de sensores é além de coletar dados, pode-se responder a certos eventos. Este conceito de sensores capazes de detectar, extrair dados e variações do ambiente onde o usuário se encontra, controlando, configurando e ajustando aplicações conforme a necessidade deste seria capaz de detectar a mútua presença tanto dos usuários como dos demais dispositivos presentes e interagir automaticamente entre eles construindo uma forma inteligente para sua melhor utilização. (KAHL; FLORIANO, 2012, p.4) Conexão O elemento conexão é muito importante num ambiente ubíquo, desde que seja rápida e estável. Forte, Souza e Prado (2006, p.287) “[...] a possibilidade de conexão a qualquer momento e de qualquer lugar outorgou aos usuários uma escolha e uma liberdade sem precedentes [...]”. Coletar informações do contexto com qualidade vai depender da qualidade dos serviços oferecidos, pois as fontes de contexto são também móveis, devendo ter-se um melhor tratamento com aspectos de conexão (VIEIRA et al, 2006, p.15). 2.6 CONTEXTO Contexto tem muitos sentidos do ponto de vista de alguns trabalhos. O autor Dey (2001, p.4) define contexto como “qualquer informação que pode ser usada para caracterizar a situação de uma entidade (pessoa, local ou objeto) que é considerada relevante para a interação entre o usuário e a aplicação, incluindo o próprio usuário e a aplicação”. Já Augustin apud Machado (2010, p.17) contexto é “toda informação relevante para aplicação que pode ser obtida por ela, podendo se referir a informações ambientais (recursos físicos), funcionais (recursos lógicos) ou comportamentais (perfil do usuário)”. Já os autores Truong, Abowd e Brotherton (2001) e Morse, Armstrong e Dey (2000) dividiram o contexto em seis dimensões: quem, o quê, quando, onde, por que e como, elas identificarão as informações contextuais e como pode ocorrer a captura. Em inglês são conhecidas como 5W+1H (Who, What, When, Where, Why e How). A seguir são apresentadas: Who: na construção de um aplicativo é muito importante conhecer os usuários, identificá-los. Ocorre que num cenário existam diferentes tipos de pessoas e deve-se levar em conta que nem sempre o usuário que captura os serviços é que vai acessar 26 eles, por isso a importância de saber quem é. É importante também saber alguns dados que devam ser considerados nessa dimensão como: o número de agentes que vão capturar as aplicações, o número de usuários que vão acessar as aplicações, as sobreposições entre ambos e o modo de captura (público, privado, compartilhado). What: para desempenhar as atividades o agente escolhe o que deseja capturar e ter acesso. Ou seja, quais atividades ele realiza frequentemente ou ocasionalmente. Estas informações geram um perfil que pode ser documentado e usado pelas aplicações na identificação de quem está solicitando o acesso a elas; When: esta dimensão trata o momento que ocorre a captura do serviço e o acesso a ele. O sistema pode utilizar o contexto do tempo para automatizar a inicialização dos serviços. Embora certos serviços iniciem com alguma frequência outros periodicamente é interessante tirar proveito dessa dimensão; Where: indica a localização onde está ocorrendo a captura e acesso aos serviços. É comum as pessoas trabalharem em diversos ambientes, por isso, deve-se levar em conta quando se compartilha serviços: a mobilidade do usuário. As aplicações sabendo do local do acesso dos usuários facilitarão a moldagem dos serviços e mostrar para os usuários quais recursos estão disponíveis naquele ambiente; Why: aqui é relevado as razões que um usuário usa determinada aplicação ou serviço, isto é, a motivação. Ou seja, quais motivos leva o agente ter determinadas ações. É questionado também o porquê um serviço é útil; How: esta dimensão abrange como a captura do contexto será efetuada. Seja por rede sem fio, Geo-Posicionamento por Satélite (GPS) ou triangulação de sinal, por exemplo. Além disso, define a quantidade de dispositivos que captura e acessa os serviços disponíveis. Araujo e Brézillon (2005) definiram que o contexto é relativo a algo, a um foco. O foco é uma tarefa ou um passo na resolução de um problema ou em uma tomada de decisão. Por exemplo, o contexto de um repórter de TV está em passar a notícia. O contexto de um diagnóstico médico está na tomada de decisão. Portanto para os autores, o contexto é sempre o foco de atenção atual do usuário. Ainda, o foco determina onde está o contexto e o que pode ser considerado como relevante, pois nem tudo que é contexto de uma situação é condescendente para tal. Outro exemplo, o foco na realização de um jogo de futebol busca informação na formação dos 27 times, na equipe de juízes, mas não é interessante saber se irá chover no dia, se o estádio é coberto. 2.6.1 Representação do Contexto A quantidade de informação capturada e acessada num modelo de representação do contexto é significativa. No entanto, a dificuldade é organizar o conteúdo de forma a filtrar apenas os dados relevantes para se atingir um foco. E com o passar do tempo, as informações tendem a perder a relevância, ficarem seu valor. O estudo de técnicas para representar o contexto para criação de sistemas tem crescido nos últimos anos. Atualmente, algumas formas de representar o contexto são utilizadas, cada uma com vantagens e desvantagens. A seguir são apresentadas algumas técnicas de como representar o contexto: Modelos Chave-Valor: é considerado o modelo mais simples de programar, pois se constitui de uma lista de pares de chaves. Para modelar o contexto cada chave é um atributo que identifica o elemento do contexto e atribui para essa chave um valor, por exemplo: Chave = nota Valor = menor que cinco Ação: Exibir mensagem “Aluno reprovado!” Modelos de Esquemas de Marcação: é um tipo de linguagem que marcam os dados contextuais. O eXtensible Markup Language (XML) é recomendado pela W3C para criação de dados organizados. Ele divide as informações de forma hierárquica através de tags. Um exemplo é o CC/PP (W3C, 2007) que é uma descrição dos recursos do dispositivo e preferências do usuário; Modelos Gráficos: a representação do contexto neste modelo baseia-se em abordagens Unified Modeling Language (UML), Object Role Modeling (ORM) e grafos textuais. Os modelos baseados em UML usam esta linguagem como perfis para representar o contexto, exemplo Context UML Profile (CMP) (SIMONS, 2007). 28 Context Modeling Language CML (HENRICKSEN; INDULSKA, 2006) utiliza ORM; Modelos baseados em Objetos: a orientação a objetos utiliza as técnicas de herança, encapsulamento e reusabilidade para definir as estruturas do contexto. Com essas técnicas é possível deixar a informação na linha da interface e os detalhes do processamento encapsulados nos objetos (VIEIRA et al, 2006); Modelos baseados em Ontologias: para o contexto, ontologias são conceituadas como um conjunto de primitivas representacionais com as quais modela um domínio do conhecimento. Esse conjunto fornece uma descrição lógica dos dados compartilhados, e define o vocabulário utilizado para compor expressões complexas (GRUBER, 1993). Uma pesquisa de Strang e C.L-Popien (2005) comparou os tipos de representações de contexto existentes e considerou os requisitos a seguir: 1) Composição Distribuída (dc): o modelo é do tipo distribuído e o contexto é montado levando em conta o dinamismo dos dados; 2) Validação Parcial (pv): verifica se o conhecimento é parcialmente inválido dependendo do modelo descrito; 3) Riqueza e Qualidade da Informação (qua): as informações captadas por sensores mudam a todo o momento, neste sentido é importante que a qualidade das informações coletadas; 4) Incompletude e Ambiguidade (inc): as redes de sensores disponibilizam informações que são incompletas e ambíguas. Este aspecto tem que ser atendido pela representação de contexto; 5) Nível de Formalidade (for): é necessário manter um nível de formalidade dos significados das informações coletadas para que não ocorram problemas na compreensão dos significados; 6) Aplicabilidade em Ambientes Existentes (app): considerando a parte de implementação, um modelo de contexto tem que ser aplicável em ambientes de desenvolvimento de aplicações sensíveis ao contexto. Na pesquisa de Strang e C.L-Popien (2005) foram caracterizadas as representações de contexto de acordo com os requisitos relacionados anteriormente, como podem ser 29 observadas na Tabela 1. O sinal “++” indica que a abordagem atende totalmente o requisito, o sinal “+” indica que atende parcialmente e “-“ não atende. Nota-se que o modelo baseado em ontologias atende todos os requisitos, parcial ou totalmente. Tabela 1: Comparação entre os modelos de contexto. Modelo/Requisitios dc pv qua inc for app Chave-valor - - - - - + Esquemas de + ++ - - + ++ Gráficos - - + - + + Objetos ++ + + + + + Ontologias ++ ++ + + ++ + marcação Fonte: http://elib.dlr.de/7444/1/Ubicomp2004ContextWSCameraReadyVersion.pdf 2.6.2 Tipos de Contexto Os autores Brezillon e Pomerol (1999) classificaram a relevância do conhecimento contextual na tomada de decisão em três tipos: (1) Conhecimento Externo (EK – External Knowledge): é o tipo de conhecimento que não tem relevância no foco da tarefa, ou seja, não possui interferência na decisão atual, mas é de conhecimento de todos os envolvidos; (2) Conhecimento Contextual (CK – Context Knowledge): esse é o tipo de contexto que não é usado explicitamente, mas influencia na resolução dos problemas. Ele é estruturado e invocado de acordo com o foco; (3) Contexto Procedimental (PC – Proceduralized Context): este surge a partir do CK e é o resultado dessa combinação de conhecimentos, sai dele o contexto para oferecer serviços sensíveis ao contexto. O conhecimento externo (EK) é a parte do contexto que não é relevante para uma determinada situação, para um determinado foco, conforme a Figura 6. Como no exemplo do jogo de futebol, no estádio existem torcedores de diferentes idades, classe social, raça, porém não são dados que podem interferir na realização do jogo. O conhecimento contextual (CK) é 30 o contexto significativamente relevante para entender a situação e tem forte relação com o foco (VIEIRA et al, 2009). Figura 6: Tipos de contextos e suas dinâmicas. Fonte: http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.32.8174 No exemplo anterior, seriam as informações como localização dos jogadores, habilidades, condição física, experiência; agilidade; quantidades de jogadores disponíveis são dados relevantes para a realização da tarefa, no caso o jogo. E por último, o contexto procedimental (PC) surge a partir do CK, como no exemplo do jogo, o usuário pode saber que existem jogadores contundidos ou que há um atleta no banco de reservas com melhor habilidade para atuar na lateral (VIEIRA et al, 2009). 2.6.3 Sistemas Sensíveis ao Contexto Os sistemas sensíveis ao contexto alavancaram o interesse em usar as técnicas de como representar o contexto, de tornar sistemas computacionais cientes das mudanças de foco. Esses sistemas têm de ser flexíveis que possam se adaptar e capazes de atuar automaticamente para ajudar o usuário na realização de suas atividades, eles devem ser proativos. O contexto pode ser oriundo de fontes diferentes e, portanto, os sistemas devem saber trabalhar com esse impasse de modo que mantenha a interoperabilidade entre eles. (MACHADO, 2010, p. 18). Num ambiente ubíquo onde a mobilidade é o principal diferencial se comparar com um ambiente pervasivo, há uma série de fatores que estão implícitos e outros explícitos cujas 31 características podem ser ou não influentes na construção de argumentos para uma aplicação móvel, ou um middleware. Além disso, entre computadores e pessoas a maneira de comunicação é que esse último expresse sua vontade interagindo com o software ou hardware através do toque, cliques, escrita, etc. No entanto, o ser humano tem outros sentidos para expressar vontades como voz, gestos, presença; pensamentos, que poderão ser captados por sensores espalhados por um ambiente e interpretados por sistemas operacionais e aplicações móveis na forma de contexto. Para isso, uma aplicação móvel sensível ao contexto tem de ser capaz de extrair do ambiente (contexto da computação ou físico); do usuário ou do tempo, dados que ajudem na realização da tarefa (CHEN; KOTZ, 2002). E também capturar de maneira de ágil, a partir da informação do contexto, os serviços que estejam na rede para que o usuário possa utilizá-los na realização da tarefa a que foi designado. Tudo que esteja inserido no ambiente é contexto, desde que seja relevante para a aplicação. 2.6.4 Exemplos de Sistemas Sensíveis ao Contexto Existem algumas aplicações corporativas que usam a técnica de ciência do contexto. Embora seja uma área relativamente ainda em expansão e que falta mais experiência práticas na utilização de contexto, isso já é consequência do aumento do interesse do estudo dessa técnica. A seguir serão descritas duas ferramentas que utilizam sensibilidade ao contexto. GMAIL O sistema de gerenciamento de e-mails da empresa Google, o Gmail (GOOGLE, 2010) usa abordagem de ciência do contexto para promover dicas de serviços para os usuários. Na tela de visualização das mensagens, conforme a Figura 7, no lado direito, uma lista de propagandas relacionadas ao contexto da mensagem. Nota-se na imagem que a conversa é sobre conserto de um notebook, assim, é exibido ao usuário uma lista de links comerciais de empresas que prestam assistência técnica e venda de computadores portáteis. A publicidade é modificada conforme o conteúdo das mensagens. A cada novo e-mail o sistema filtra no contexto o que é relevante para exibir as propagandas aos leitores. 32 Figura 7: Propaganda sensível ao contexto no GMail. GUIAS TURÍSTICOS MÓVEIS Os serviços móveis no guia de turismo têm como propósito satisfazer as necessidades de informação dos turistas e proporcionando-lhes uma variedade informações turísticas relacionadas com a viagem. Os dados como acomodações, emergências, gastronomia, compras e lazer são exibidos para o turista (GRÜN et al, 2008). A Figura 8 mostra exemplos de aplicações móveis que trabalham como guias turísticos. Figura 8: Exemplo de guias turísticos móveis Fonte: http://reuse.cos.ufrj.br/files/publicacoes/mestrado/Mes_PaulaCibele.pdf 33 2.7 DESAFIOS DA COMPUTAÇÃO UBÍQUA A computação ubíqua impulsionará a tecnologia da informação para um patamar jamais visto. No entanto, para que isso aconteça ela terá alguns obstáculos a vencer pela frente. Considerados por alguns autores desafios pertinentes na realidade atual com relação às perspectivas de avanço tecnológico. Há de fato muito que se evoluir no quesito mobilidade, por exemplo, e principalmente na durabilidade da energia para dispositivos, pois o processamento que aplicações ubíquas exigem alto consumo de bateria, como também prolongar o uso do aparelho para dispor ao usuário. Outro fator importante são as redes sem fio. Existe uma variedade de tipos de redes sem fio, isso já é consolidado. No entanto, por possuírem características diferentes, é um desafio para computação ubíqua navegar em redes heterogêneas. E nesse contexto, criar mecanismos que facilitem a descoberta de serviços que agilizem a sincronização de dados, etc. Com as redes, dispositivos, sensores, situações distintas, a complexidade aumenta ao se projetar no computador as condições atuais do usuário e do ambiente de forma mais natural, o que torna também um grande obstáculo para a computação ubíqua: a computação sensível ao contexto. É relativamente complexa essa área, pois o contexto tem que ser extraído dinamicamente com qualidade e ser seguro quanto ao aspecto de extrair aquilo que não é sigiloso, respeitando o modelo da arquitetura de ciência do contexto (LOUREIRO et al, 2010). Os autores Buriol, Rosendo e Sheer (2009) comentam que a interação natural entre dispositivos e seres humanos é também um grande desafio para computação ubíqua. Diferente de teclados, mouses, os dispositivos com interfaces tangíveis têm a concepção de que existe um significado embutido na representação. Atualmente há avanços na área de reconhecimento de voz, escrita, porém o grande desafio é desenvolver procedimentos que reconheçam também gesticulações, formas de expressão e depois traduzi-las para uma aplicação na forma de contexto. Além disso, o desenvolvimento tecnológico de qualidade na área da computação ubíqua encontram-se outras demandas como (FLÔR et al, 2008): a) A sensibilidade ao contexto; b) Conexão espontânea, transparente e dinâmica; c) Formas diferenciadas de interação com dispositivos; 34 d) Segurança; e) Melhoria na capacidade dos dispositivos; f) Validação, privacidade e valor da informação. g) Disponibilidade; h) Escalabilidade; i) Corretude; j) Persistência, entre outros. No entanto, a computação ubíqua vem evoluindo bastante nos últimos anos. Áreas como educação, projetos para casas e saúde. Essa última pode ser considerada um dos ramos mais promissores. Brown e Adams (2007, p. 54, tradução nossa) “Ubiquitous Healthcare é um campo emergente de tecnologia que utiliza um grande número de sensores e atuadores para monitorar e melhorar as condições físicas e mentais dos pacientes”. Existem muitos autores com projetos na computação ubíqua na saúde como citado na seção 2.4 deste trabalho, consequência da promessa dessa área de alavancar as pesquisas da Internet das Coisas. 2.8 A COMPUTAÇÃO UBÍQUA E AS TECNOLOGIAS NECESSÁRIAS Na constituição de um ambiente ubíquo é necessário o trabalho conjunto de algumas tecnologias que ao se interagirem poderão capturar e disponibilizar a informação dinamicamente ao usuário com o uso de dispositivos. Abaixo serão descritas algumas dessas tecnologias como dispositivos, redes de computadores, sensores, linguagem de programação e sistemas operacionais. Dispositivos Novas tecnologias têm surgido com o passar dos anos no campo da mobilidade possuindo diferentes tamanhos, capacidade de processamento. Conforme Madeira (2007, p.23) “Em conjunto com novos dispositivos de entrada/saída, estas tecnologias podem ser consideradas como sendo aquelas que possibilitam o avanço na realização de aplicações e sistemas de Ubicomp”. Celulares, smartphones, tablets, netbooks, notebooks, utilizam recursos da rede executando aplicativos e acessando diferentes serviços e através dela os utilizadores podem se locomover, comunicando-se entre si e mantendo a interoperabilidade das informações. 35 Na medida em que a residência, o meio de transporte e o trabalho do usuário tornam-se os cenários de aplicação da computação ubíqua, oferecendo serviços como segurança, comodidade, informação, entretenimento, e muito mais, um universo incrível de dispositivos diferentes deverá existir para suportar estes serviços (ARAÚJO, 2006, p.10). Organizações como bancos, empresas de cartões de crédito criam aplicações que facilitam o cotidiano dos clientes, permitindo pagamentos e acesso à conta através de dispositivos móveis. Redes de Computadores Para que ocorra a comunicação entre dispositivos é necessário eles estarem conectados em uma rede com ou sem fio. As redes têm como finalidade dispor das informações, recursos a qualquer entidade, seja a onde for sua localização e com o crescente número de diferentes dispositivos as redes terão o desafio de manter a comunicação. Além disso, diferentes meios de acesso e a heterogeneidade das redes sem fio será um obstáculo para os futuros ambientes ubíquos. A natureza dos dispositivos ubíqüos tem elevado o crescimento do uso de tecnologias de redes sem fio, pois fazem dessas uma solução de interconexão mais fácil com ambientes até então inadequados ou então impossíveis de se manter uma comunicação devido à, por exemplo, altos custos e restrições tecnológicas (CORRÊA et al, 2006, p.2). Os tipos de redes de acesso sem fio mais conhecidas são: wi-fi, wimax, bluetooth e infravermelho, conforme a Tabela 2. Tabela 2: Exemplos de tecnologias sem fio. Tecnologia Padrão IEEE Infravermelho 802.11 (IrDA) Bluetooth 802.15 Wi-Fi 802.11 WiMax 802.16 Utilização Aplicações específicas. Normalmente utilizado para troca de informações ponto-a-ponto (P2P). Utilizado para redes pessoais, ou seja, em equipamentos pessoais para troca de informações em curta distância. Possui alcance maior que as outras duas tecnologias anteriores. Porém é utilizada somente para redes locais. Comunicação sem fio em longo alcance. Fonte: http://www.upf.br/computacao/images/stories/TCs/arquivos_20071/ricardo_oliveira.pdf 36 A transmissão por infravermelho IrDA ocorre por meio de pulsos de luz. Ela se caracteriza por não utilizar fios para se conectar e também que possui um comprimento de onda mais longo que o da luz invisível. Outra característica é que a comunicação só pode por apenas entre dois pontos, chamada de ponto-a-ponto. Como pode ser visto na Figura 9, o Bluetooth tanto pode ser ponto-a-ponto como multiponto. A tecnologia Bluetooth é um padrão considerado global sem fio e que permite uma comunicação rápida, simples e barata entre dispositivos. Figura 9: Conexões ponto-a-ponto e multiponto com Bluetooth. Fonte: http://www.lisha.ufsc.br/pub/Billo_BSC_2002.pdf Wi-Fi é marca registrada da empresa Wi-Fi Alliance, que cria produtos pertencentes à norma 802.11. Essa tecnologia sem fio trabalha em altas velocidades através de ondas de rádio, distâncias que variam de 100 metros até 300 metros. A WiMax acrônimo de World wide Interoperability for Microwave Access (Interoperabilidade Mundial para Acesso por Microondas), reconhecida também como uma tecnologia de banda larga sem fio e com alcance superior a Wi-Fi. Na teoria os equipamentos de WiMax atingem distâncias de até 50 km com uma banda passante de até 70 Mbp/s. Sensores O sensoriamento do ambiente é um ponto fundamental da computação ubíqua, pois a partir dele são capturadas as informações as quais são filtradas pelos sistemas computacionais que colocarão ou não relevância ao contexto. Loureiro (2007, p.1) “a noção que dispositivos 37 de computação e sensoriamento pequenos, inteligentes, e baratos irão eventualmente permear o ambiente, levando efetivamente a ambientes de computação ubíqua”. As redes de sensores são diferentes das redes Wi-Fi e WiMax, pois a comunicação nas redes de sensores não é fim-a-fim. A finalidade destes dispositivos é detectar as mudanças no ambiente e transmitir ao usuário. Figura 10: Exemplo de uma rede de sensores sem fio. Fonte: http://gta.ufrj.br/ftp/gta/TechReports/Ingrid05/tese.pdf Os sensores trabalham de forma transparente com o utilizador, ou seja, sem que ele saiba da existência dos sensores tanto individualmente como coletivamente. Na ilustração da Figura 10, o usuário pode estar localizado distantemente do local onde estão os sensores. Linguagem de Programação O desenvolvimento de aplicações para ambientes ubíquas requer eficiência da linguagem de programação usada, pois os dispositivos que executam essas aplicações têm, geralmente, menor capacidade de memória e processamento. Assim, é importante evitar a perda de dados quando a bateria acabar. Outro fator é a heterogeneidade de dispositivos, portanto, a portabilidade da aplicação também é fator importante (ARAÚJO, 2003, p. 62). Assim, a criação de programas para dispositivos móveis requer atenção em alguns pontos. Conforme Araújo (2003, p. 62), para programar sistemas ubíquos deve-se levar em consideração os seguintes critérios: Tamanho limitado da tela, capacidade de entrada de dados, poder limitado de processamento, memória, armazenamento persistente; Alta latência, largura de banda limitada e conectividade intermitente (o que os dispositivos esperam encontrar em termos de conectividade); 38 Utilizar a rede somente quando for necessário; Se utilizar a rede, retirar dela apenas o que for importante; Estar disponível quando a rede estiver off-line. Outras estratégias são importantes para o desenvolvimento de projetos de software para aplicativos móveis, como: manter simples a programação, criar códigos fontes de tamanhos menores; deixar o servidor fazer parte do trabalho mais oneroso, escolher cuidadosamente uma linguagem de programação; usar variáveis locais, evitar concatenação de string, usar threads e evitar sincronização, se a linguagem for Java minimizar o uso de memória (ARAÚJO, 2003, p. 63). Java conceitua-se com muita propriedade com relação aos requisitos para o desenvolvimento de aplicativos ubíquos, pois tem vantagem de ser multiplataforma, ou seja, pode ser executado em qualquer sistema operacional que possua a Máquina Virtual Java (MVJ) instalada. Com Java tem-se a possibilidade de criar aplicações muito eficientes para celulares e qualquer dispositivo em geral e também, além disso, é multi-thread cuja finalidade é suportar processamento paralelo múltiplo. A reutilização do código é outra vantagem e como consequência reduz-se o tempo de programação. Java exibe muitas características que facilitam o desenvolvimento de aplicações móveis. Entre elas, a portabilidade dos bytecodes permite a execução em diferentes hosts com diferentes arquiteturas de software e hardware; multithreading torna os agentes colaborativos e autônomos; serialização de objetos suporta a migração e persistência; carga de classe dinâmica permite o projeto de estratégias eficientes para a recuperação de código dos entes (AUGUSTIN, 2004, p. 76). A Figura 11 mostra como funciona a execução de programas escritos em Java em diferentes sistemas operacionais. No editor, o desenvolvedor escreve o código fonte que após é transformado em bytecodes através do compilador Java. Bytecodes é um código intermediário do código fonte e a aplicação final. Eles não são imediatamente executáveis, devem ser interpretados por uma MVJ pré-instalada no sistema operacional. 39 Figura 11: Processo de execução programas Java. Fonte: http://www.dca.fee.unicamp.br/cursos/PooJava/javaenv/bytecode.html Com isso, existe a portabilidade, pois no momento que os computadores possuam a MVJ instalada, a aplicação será executada da mesma forma que em outras arquiteturas. Portabilidade é essencial em ambientes ubíquos e Java oferece este requisito. A independência de plataforma que a Java oferece, a grande quantidade de bibliotecas disponíveis (de suporte a construção de interfaces gráficas a suporte de rede), e a existência de máquinas virtuais embutidas em vários dispositivos tornou a linguagem Java uma tecnologia chave para o desenvolvimento de software na computação ubíqua (CIRILO, 2007, p. 6). . Portanto, as aplicações que possam ser executadas nas diferentes plataformas existentes conduzem para atingir um dos princípios da computação ubíqua: disponibilizar o acesso a informação em qualquer lugar, em qualquer momento, seja qual for o dispositivo sendo usado. Sistemas Operacionais No topo das funcionalidades da computação ubíqua estão os software. Essas tecnologias fornecem ferramentas para programar e gerenciar os dispositivos em cenários ubíquos. Os software podem ser sistemas operacionais, ambientes ou aplicativos. Os sistemas operacionais gerenciam o hardware dos dispositivos fornecendo acesso a eles para o usuário. Os ambientes são as camadas que fornecem estruturas para a programação e os aplicativos oferecem os serviços aos utilizadores (CAMPIOLO, 2005, p.17). Muitos sistemas operacionais foram desenvolvidos para satisfazer às necessidades específicas da computação ubíqua: Google Android, Windows CE, Windows for Smart Cards, Palm OS, EPOC, QNX, GEOS, e muitos outros. Todos eles rodam em dispositivos com pouca memória e a maioria 40 são projetados para executarem em muitas diferentes plataformas de processadores (HANSMANN, 2003 apud CIRILO, 2007, p. 5). . Os sistemas operacionais para dispositivos móveis podem facilitar a programação, dirigindo os recursos de hardware. Enquanto os de desktops possuem uma variedade de funcionalidades, os sistemas operacionais de dispositivos ubíquos se concentram em aperfeiçoar tarefas, diminuindo a escassez de recursos de hardware. 2.9 COMPUTAÇÃO UBÍQUA NA SAÚDE A eficiência dos serviços hospitalares é causa de grandes debates e reflete não só na sociedade, mas globalmente. A cada ano que passa aumenta o número de atendimentos nos postos de saúde bem como nos hospitais centrais. Consequência disso acrescenta-se unidades hospitalares, aumenta o número de profissionais e proporcionalmente as dificuldades técnicas. Com esses fatos se produz um banco de informações enriquecido, porém muitas vezes difícil de analisar, bem como transformá-los em dados integrados e mais do que nunca interoperáveis. Além disso, as informações podem estar organizadas, mas não estão dispostas de uma forma que seja simples e rápido o acesso. O uso da computação ubíqua no ambiente hospitalar pode tornar a interação entre os profissionais de saúde e os equipamentos médicos mais dinâmica e eficiente. Este avanço é possível através da interpretação pelos sistemas eletromédicos das formas naturais de comunicação dos humanos: fala, movimentos de membros do corpo humano, gestos e contexto. Quanto mais natural for a interface entre a máquina e o homem, mais otimizados se tornarão os serviços prestados pelos estabelecimentos de saúde, trazendo diversos benefícios para os profissionais e para os pacientes (SOUZA, 2011, p. 7). Com isso, o uso da computação ubíqua vem para melhorar esta situação. Com a interoperabilidade dos sistemas, a disponibilidade da informação, vem facilitar e diminuir o tempo de acesso ao Registro Eletrônico de Saúde dos pacientes, sem que o usuário detenha toda sua atenção à manutenção da aplicação, é a proposta de melhoria dos serviços. 2.10 REGISTRO ELETRÔNICO DE SAÚDE O Registro Eletrônico de Saúde (RES) denominado também de Prontuário Eletrônico do Paciente (PEP) é uma base de dados construída a partir da inserção de informações por software de gestão hospitalar. Esses dados referentes ao paciente são obtidos no momento que 41 estão ocorrendo. Massad et al. (2003, p.6), “prontuário eletrônico é um meio físico, um repositório onde todas as informações de saúde, clínicas e administrativas, ao longo da vida de um indivíduo estão armazenadas”. Por outro lado, não se pode chamar o RES um sistema computacional, pelo contrário, ele está inserido nesse, como parte dele. Toda a trajetória da vida da saúde do paciente é gravada na base de dados de um RES. Ao longo desse caminho fatos como vacinas, doenças, acidentes e outros acontecimentos são gravados montando uma enorme base de dados. Alguns desses são extremamente relevantes e que ajudam na decisão dos profissionais de saúde e auxilia-os na prevenção e diagnósticos de doenças. No entanto, a quantidade de informações inviabiliza o trabalho dos profissionais de saúde, pois procurar a informação de que se precisa no momento do atendimento ao paciente é necessário tempo e atenção. Assim, a disponibilidade da informação e a interoperabilidade dos sistemas são extremamente importantes para o andamento dos processos. Garantir a interoperabilidade em Sistemas de Registro Eletrônico de Saúde (S-RES) se deve usar um padrão de comunicação para que ocorra a troca de mensagens entre dispositivos e aplicações médicas. Isto se deve pelo fato que atualmente existe uma variedade de softwares e bases de dados heterogêneas. “Portanto, o uso de padrões na área de informática em saúde contribui para a integração de dados médicos [...]” (SOARES, 2009, p. 63). 2.11 PADRÕES DE INTEROPERABILIDADE DE INFORMAÇÕES MÉDICAS Para que a troca de informação seja transparente tanto por aplicações locais num ambiente hospitalar como para fora dele se faz necessária interoperabilidade. Não importa a plataforma, nem a linguagem usada para desenvolver S-RES, a troca de mensagens ocorrerá devido ao padrão adotado. Esses padrões possuem uma nomenclatura própria para área da saúde, identificando individualmente desde o paciente até eventos como: atendimento ambulatorial, procedimentos cirúrgicos, doenças, diagnósticos, etc. Hoje existe uma variedade de padrões, porém procurou-se discriminar neste trabalho os mais solidificados que ofereçam melhor estrutura. Dentre estes se destacam Continuity Care of Record (CCR), criado pela empresa ASTM International e HL7 - CDA (Health Level Seven – Clinical Document Architecture) de propriedade da organização Health Level Seven. 42 2.11.1 HL7 Health Level Seven (HL7) é uma organização voluntária sem fins lucrativos, que foi fundada em 1987 com o objetivo de produzir protocolos e transações de seguradoras. O HL7 é específico para dados clínicos e administrativos (HL7, 2007). Conceituada como uma das Organizações Desenvolvedoras de Standarts (Padrões) que operando na área da saúde possui “um framework abrangente e normas relacionadas com o intercâmbio, integração, compartilhamento e recuperação de informações de saúde eletrônica que suporta prática clínica e gestão, execução e avaliação dos serviços da saúde” (GONÇALVES, 2010, p.16). Uma mensagem no padrão HL7 versão 2.4 é caracterizada por eventos, por exemplo, na admissão de pacientes, automaticamente um evento é disparado para todas as aplicações que estejam interessadas na informação (PETRY; LOPES, 2005). Como demonstra o Quadro 2, um exemplo de mensagem ADT^A01 enviada na admissão de paciente. MSH|^~\&|AccMgr|1|||20050110045504||ADT^A01|599102|P|2.3||| EVN|A01|20050110045502||||| PID|1||10006579^^^1^MRN^1||DUCK^DONALD^D||19241010|M||1|111 DUCK ST^^FOWL^CA^999990000^^M|1|8885551212|8885551212|1|2||40007716^^^AccMgr^VN^1|123121 234|||||||||||NO NK1|1|DUCK^HUEY|SO|3583 DUCK RD^^FOWL^CA^999990000|8885552222||Y|||||||||||||| PV1|1|I|PREOP^101^1^1^^^S|3|||37^DISNEY^WALT^^^^^^AccMgr^^^^CI|||01||||1|||37^DISNEY ^WALT^^^^^^AccMgr^^^^CI| Quadro 2: Exemplo mensagem HL7. Fonte: http://www.hosinc.com/products/interfaces/interface_documentation.htm#A01 Observando o Quadro 2, as mensagem são compostas por segmentos que são separados pelo caractere pipe. Cada pipe é um campo que contém uma informação. Os dados nos campos não são obrigatórios, pois o HL7 não verifica se o campo está vazio ou não. As mensagens são enviadas para toda aplicação que possua o recurso de receber as mensagens e interpretá-las. A Figura 12 mostra o funcionamento do envio das mensagens HL7. Figura 12: Funcionamento do HL7. Fonte: https://dspace.isep.ipp.pt/jspui/bitstream/123456789/74/1/Tese.pdf 43 A versão mais atual do HL7, a versão 3, foi desenvolvida com uma abordagem direcionada para orientação a objeto, usando princípios de Unified Modeling Language (UML) e a estrutura é criada com XML. Abaixo o histórico das versões (ABRAHÃO, 2005, p.9): 1987. Versão 1.0: Definido o âmbito e o formato de mensagens; 1988. Versão 2.0: Realizada uma série de atualizações; 1990. Versão 2.1: Primeira publicação do Padrão HL7. Efetivamente adotado (Estados Unidos); 1993. Primeira Afiliação Internacional (Alemanha, Holanda); 1994. Versão 2.2: Primeiro reconhecimento pela ANSI; 1997. Versão 2.3: Aprovada pela ANSI. Ampla implementação internacional; 1999. Versão 2.3.1: Aprovada pela ANSI. Realizadas atualizações; 2000. Versão 2.4: Aprovada pela ANSI. Adição de novos eventos, segmentos e mensagens; 2003. Versão 2.5: Aprovada pela ANSI. Adição de novos eventos, segmentos e mensagens; 2005. Versão 3.0 Normative Edition: Parcialmente aprovada pela ANSI. Reestruturação baseada em modelo orientado a objetos Reference Information Model (RIM); 2006. Versão 3.0 Normative Edition May 2006: Parcialmente aprovada pela ANSI. 2.11.2 CCR No ano de 2003 um grupo de médicos, enfermeiros e tecnólogos com o apoio da ASTM International, mais antiga das organizações de padrões de desenvolvimento, criaram um padrão para troca de informações da saúde de pessoas. Conforme a ASTM, o objetivo do Continuity of Care Record é usar a tecnologia da informação para trocar informações relevantes sobre a saúde dos pacientes (ASTM, 2007). O resumo das informações mais relevantes é feito pelo médico no fim da consulta. Este documento em CCR pode ser disponibilizado em papel ou eletronicamente em XML, conforme a Figura 13. A concepção é transportar as informações mais relevantes sobre a condição de saúde do paciente. 44 São dados como alergias, medicações, diagnósticos, procedimentos recentes, tratamentos recentes, recomendações para cuidados futuros, motivo de encaminhamento e transferência. É criado apenas um documento contendo todas as informações e após é disponibilizada para toda a rede. Figura 13: Criação de XML e documento pelo CCR. Fonte: http://www.nchica.org/Past/06/presentations/Kibbe.pdf 2.11.3 Diferenças entre CCR e HL7 Tanto CCR como HL7 são usados para transporte de dados clínicos. Na versão mais nova, o padrão HL7 é definido em formato XML, bem como o CCR. No entanto, versões mais antigas do HL7 são descritos em Encoding Rules Seven (ER7). A diferença mais específica entre as tecnologias é que o CCR envia às aplicações e usuários o resumo do atendimento, contendo todas as informações que o médico relatou serem relevantes, ou seja, existe apenas um envio de informação. Enquanto o HL7 envia partes de um atendimento. Por exemplo, é realizado um exame no paciente, uma mensagem é enviada para todas as aplicações que o enfermo recebeu tal procedimento. Com todas as mensagens HL7 enviadas de um paciente pode-se criar um resumo do atendimento. O que ocorre é que com HL7 o hospital sabe a informação em tempo real. CCR informa para aplicações o que ocorreu até o momento com o paciente e HL7 descreve o que está ocorrendo num determinado instante. 45 3 TRABALHOS RELACIONADOS No levantamento de trabalhos relacionados buscou-se a informações relacionadas à computação ubíqua móvel na medicina, fazendo uma breve descrição de suas principais características. A primeira aplicação relacionada foi desenvolvida sob o padrão de arquitetura de software, REST (Representational State Transfer). Este sistema móvel tem como objetivo principal a busca por resultados laboratoriais por nome de paciente. Trata-se de um sistema em que profissionais clínicos acessam as informações de pacientes que estão sendo atendidos. Selecionando o paciente desejado, abrirá uma lista com resultado de laboratório disponível para este paciente. Selecionando o resultado, aparecerão os detalhes do exame. Além disso, há a opção de fazer buscas por nome do paciente e por resultados de laboratório (ANDRY et al, 2011). O sistema utiliza padrão de comunicação HL7. Adiante foi relacionado um aplicativo móvel que se conecta as funcionalidades de um PEP através de web services. A meta dele é prestar ao médico acesso ao prontuário eletrônico do paciente em qualquer lugar, a qualquer momento. Em suma, o usuário pode inserir dados de seus pacientes e pesquisar, por exemplo, as medicações dos enfermos (MACHADO et al, 2010). O sistema trabalha com padrão de mensagem CCR. O próximo software relacionado é um aplicativo para Iphone e Ipad, cujo acesso aos dados é feito em um registro eletrônico de pacientes. De forma geral, o objetivo da aplicação é permitir ao usuário acessar informações referentes ao paciente dentro de uma base de dados e verificar, editar e excluir compromissos da agenda. O trabalho foi realizado no âmbito do projeto ClinicSpace. Para projetar os procedimentos do software foram abordadas algumas atividades essenciais dos médicos, obtidas através de pesquisa. Alguns elementos importantes podem ser destacados como o uso de serviços do Google Calendar e Health. O sistema usa também CCR para troca de informações médicas (GUERRA, 2010). Em seguida foi relacionado o software móvel Primary Health Care System (PHCS) . O usuário alvo é o agente de saúde, que desenvolve atividades no modelo assistencial Atenção Primária a Saúde (APS). O objetivo do sistema móvel é auxiliar na realização de ações preventivas nos pacientes, como automatizar formulários de cadastro e acompanhar os sinais vitais através de sensores. Todos os dados inseridos e sinais captados pelos sensores são enviados para uma base de dados. Quaisquer profissionais terão acesso a essas informações podendo fazer diagnósticos e prevenções (BARROS et al, 2011). O aplicativo foi desenvolvido sob a infraestrutura do projeto Cognitividade com Sensibilidade a Conexão 46 como Suporte a Otimização de Recursos em Malha Heterogênea (COMAH) (GERCOM UFPA, 2011). Por fim, o último trabalho relacionado foi o Sistema de Assistência a Urgência Médica (SAUM). Ele consiste em módulo desktop e embarcado num palmtop. O objetivo da aplicação é transferir informações em que ocorra caso de atendimento pelo Sistema de Atendimento Móvel de Urgência (SAMU). Através desse sistema é possível transmitir imagens, mensagens escritas ou sonoras entre a equipe do SAMU, médicos, e prontossocorros. Dessa forma, poderia se ter um atendimento à distância de médico e saber com antecedência se há leitos vagos para o enfermo no hospital (JUNIOR, 2008). 4 FERRAMENTAS E METODOLOGIA DE DESENVOLVIMENTO Neste capítulo é mostrada toda implementação do projeto que foi feita na ferramenta IDE Eclipse Indigo 3.7.2. As outras tecnologias utilizadas como HAPI, Android, SDK Android, QRCode, Barcode Scanner, SQLite serão descritas a seguir. O desenvolvimento, os diagramas entidade-relacionamento e de sequência bem como outros aspectos seguem a mesma seção. 4.1 TECNOLOGIAS USADAS 4.1.1 API HL7 para JAVA – HAPI Java possui uma API para programação do protocolo HL7. A HAPI (HL7 Application Programming Interface) (UNIVERSITY HEALTH NETWORK, 2001) é licenciada por Mozilla Public License e General Public License (GNU). Ela tem um conjunto de classes e interfaces que ajudam na criação de aplicativos com suporte a mensagens HL7. A API possui algumas funcionalidades, descritas a seguir: Cria e analisa mensagens para os dois tipos de codificação ER7 e XML; Possui muitas funções que transportam as mensagens; Classes que validam as mensagens no envio e no recebimento; Verifica a lógica das mensagens de acordo com a norma HL7. 47 A criação da tecnologia HL7 existe algumas ferramentas disponíveis. Como o aplicativo foi desenvolvido em Java, definiu-se usar esta API para criação da classe HL7 no projeto. Cabe ressaltar que a escolha por esse padrão de troca de mensagens médicas dentro de diversos que existem, se deu pelo fato do HL7 versão 2.4 atender exatamente a demanda atendida por esse trabalho, sob o ponto de vista da interoperabilidade das informações na estrutura proposta. Apesar de existir padrões mais aceitos como CCR e HL7 versão 3, exigiria um esforço desnecessário de adequação de seus padrões ao projeto, pois sua estrutura é complexa. 4.1.2 Android A escolha do sistema operacional Android (GOOGLE, 2011) se deu pelo fato de ser um sistema muito robusto, inovador e flexível. Além de ser desenvolvido em Linux, é livre, que já é de fato uma característica importante, possui uma interface visual rica em detalhes e várias aplicações que vem pré-instaladas que proporcionam para o desenvolvedor um ambiente favorável (LECHETA, 2010). Desde sua criação em 2007 pela empresa Google, o Android vem a cada nova versão adquirindo melhores funcionalidades, criando novas interfaces com um visual poderoso. Tudo isso surge com o intuito de programar com mais velocidade as ideias no sistema operacional móvel, para que os usuários tenham a chance de usufruir de uma ferramenta com muito mais recursos, extraindo o que há de melhor na primeira plataforma móvel aberta e livre (RABELLO, 2008). Como resultado dessa aceitação do sistema da Google, muitas empresas aderiram ao projeto. Por ser um software livre, essas organizações podem adequar o sistema e personalizálo de acordo com sua necessidade. Hoje o projeto conta com mais de 80 empresas do ramo, desde operadoras móveis até fabricantes de celulares, que formam o grupo denominado Open Handset Alliance (OHA) (OHA, 2012). Outro ponto importante é uma pesquisa divulgada pelo International Data Corporation (IDC), conforme a empresa, até 2016, o Android vai superar o Windows e se tornará o sistema operacional móvel mais utilizado. IDC (2012) “O crescimento do Android está diretamente ligado à propagação dos baixos preços dos dispositivos”. Até o fim de 2012 serão 1,1 bilhões de dispositivos (Figura 14) conectados em todo o mundo, e até 2016 essa marca chegará aos 1,84 bilhões, o dobro de 2011. Neste mercado, a 48 liderança da Microsoft cairá de 35,9% para 25,1% em 2016. Já o Android, passará de 29,4% em 2010 para 31,1% em 2016 (IDC, 2012). Figura 14: Previsão de conexões inteligentes até 2016. Fonte: http://www.idc.com/getdoc.jsp?containerId=prUS23398412. 4.1.2.1 Funcionalidades A linguagem para desenvolvimento de aplicações no Android é Java, totalmente livre. Galpin (2009, p.1) “Um dos pontos mais fortes da plataforma Android é que ela aproveita a linguagem de programação Java”. O sistema operacional possui um SDK que disponibiliza várias ferramentas e API para os programadores. As principais funcionalidades da plataforma são (SPINOLA, 2008): Framework de desenvolvimento de aplicações: reutilização de código e facilidade de acesso a recursos exclusivos e manutenção; Nova máquina virtual Dalvik: criada e otimizada pensando exclusivamente em dispositivos móveis e suas limitações; Navegador web integrado: baseado no projeto Open Source WebKit, o mesmo do iPhone e Nokia série 60; Biblioteca de gráficos otimizada para dispositivos móveis: exclusiva biblioteca para gráficos 2D (duas dimensões) e 3D (três dimensões) baseada na especificação OpenGL ES 1.0 e pode ter aceleração por hardware por opcional; SQLite: armazenamento de dados estruturados; Suporte multimídia: compatibilidade com os principais formatos do mercado; Telefonia com tecnologia GSM: as aplicações podem manipular operações telefônicas, caso o fabricante permita este acesso; 49 Bluetooth, EDGE, 3G, e Wi-Fi: foco nas principais tecnologias de transmissão de dados sem fio, também depende da permissão do fabricante para acesso; Câmera e GPS: pensando em transformar o celular em uma ferramenta para interação com redes sociais, também depende da permissão do fabricante para acesso; Ambiente de desenvolvimento com plug-in para Eclipse: inclui emulador, ferramentas para debug e supervisão de memória e desempenho. 4.1.2.2 Software Development Kit Android As aplicações no Android são desenvolvidas em Java mais o Software Development Kit (SDK) que possui documentação, código e utilitários para que os desenvolvedores consigam criar software de acordo com o padrão de desenvolvimento para Android. O SDK ainda possui um emulador de celular. Para que o programador possa executar o aplicativo é necessário compilar o código com as ferramentas do SDK. Juntamente com todos os dados e recursos em um pacote Android com sufixo .apk é o resultado que representa o aplicativo compilado (LECHETA, 2010, p. 29-31). O SDK é suportado nos seguintes sistemas operacionais: Windows XP (32-bit), Vista (32 ou 64-bit) ou Windows 7 (32 ou 64-bit); Mac OS X 10.5.8 ou posterior (somente x86); Linux (testado no Linux Ubuntu). Exemplo de aplicação desenvolvida para Android é o Barcode Scanner, decodificador de códigos de barras bidimensionais. A biblioteca utilizada é a ZXing (Zebra Crossing) (GOOGLE PROJECT, 2011). 4.1.2.3 Ciclo de Vida das Activities do Android Para entender o diagrama de classes como também o gerenciamento feito pelo Android das activities (telas), é necessário conhecer o funcionamento do ciclo de vida delas. Para controlar esse ciclo, o sistema operacional possui alguns métodos. São eles: onCreate(), onStart(), onResume(), onPause(), onStop() e onDestroy(). A Figura 15 mostra o ciclo. 50 Figura 15: Ciclo de vida das activities. Fonte: LECHETA, 2010, p. 96. O fluxo da Figura 14 significa (LECHETA, 2010, p.98): onCreate(): ele é chamado na primeira vez que a tela é executada; onRestart(): quando a activity é interrompida, o método é invocado antes da tela ser iniciada; onStart(): é invocado quando a tela está tornando-se visível para o usuário; onResume(): quando a tela está executando esse método é invocado; onPause(): para retornar para uma atividade anterior; onStop(): no momento que outra tela é chamada, a anterior é escondida; onDestroy(): a activity é destruída para liberar espaço na memória. 4.1.3 Barcode Scanner Barcode Scanner é um aplicativo para Android criado com a biblioteca de código aberto ZXing, abreviatura de “Zebra Crossing”. Com auxílio da câmera, o disposto tem a possibilidade de fazer a leitura de códigos de barras 1D/2D. Os tipos de código de barras que pode serem lidos com este aplicativo são: UPC-A e UPC-E, EAN-8 e EAN-13, Code 39, Code 93, Code 128, ITF, Codabar, RSS-14, QR Code, Data Matrix, Aztec, PDF 417 51 (GOOGLE PROJECT HOSTING, 2008). A aplicação pode ser baixada gratuitamente no repositório Android Market. Figura 16: Download, instalação e funcionamento do Barcode Scanner. A Figura 16 mostra os passos para baixar e instalar o aplicativo Barcode Scanner no celular. A última imagem é o software em funcionamento fazendo a varredura num código de barras. Atualmente o QR Code é o mais popular código 2D. Sua utilização está em indústrias, revistas, propagandas, etc. 4.1.4 QR Code Em 1994 a empresa japonesa Denso Wave desenvolveu um código de barras bidimensional, o QR Code (Figura 17), com o intuito de armazenar uma quantidade maior de informações e agilizar a codificação e leitura de caracteres do tipo Kanji. QR é acrônimo de Quick Response que é muito utilizado no Japão (DENSO WAVE, 2000). A escolha por esta tecnologia se deu pelo fato que é popularmente conhecida e muito utilizada entre tantas similares do mercado. Para gerar QR Codes existem sites que ao se digitar a informação desejada para codificar, é criado a etiqueta bidimensional. A decodificação é feita por aplicativos como o Barcode Scanner, citado na subseção anterior deste trabalho. Figura 17: Exemplo de QR Code. 52 Fonte: http://www.qrcode.com/qrfeature.html. Atualmente estas etiquetas bidimensionais são usadas para codificar Uniform Resource Locator (URL) direcionada para um site. Porém, os QR Codes podem armazenar diferentes tipos de caracateres. O Quadro 3 mostra os tipos e o tamanho: Apenas números Máximo 7089 dígitos numéricos Apenas alfanuméricos Máximo 4296 dígitos alfanuméricos Binários Máximo 2953 bytes Kanji, Kana Máximo 1817 caracteres Quadro 3: Quantidade de caracteres armazenados nos QR Code. Fonte: (DENSO WAVE, 2000). 4.1.5 SQLite SQLite é uma biblioteca em C que tem embutida um banco dados. Ela já vem préinstalada no Android. O software é destinado para aplicações que não requerem muita complexidade. Foi escolhido por ser um aplicativo de fácil usabilidade e implementação e também de pequeno porte, requisitos essenciais para dispositivos móveis. Alguns exemplos de onde o banco pode ser usado: sites, dispositivos e sistemas embarcados, ferramentas de estatística e análise (SQLITE, 2011). É um banco de dados ideal para aplicações móveis, onde os recursos são reduzidos. Um exemplo é armazenar os links ou conteúdo à escolha do usuário para gerar QR Codes. Algumas características do SQLite: Software livre/domínio público e multiplataforma; Mecanismo de armazenamento seguro com transações ACID; Não necessita de instalação, configuração ou administração; Implementa a maioria do SQL92; O banco de dados é guardado em um único arquivo; Suporta bases de dados acima de 2 terabytes; Sem dependências externas. 4.1.6 Técnica de Representação do Contexto 53 A técnica para representação do contexto escolhida foi o modelo chave-valor. O motivo da escolha foi devido aos requisitos de pouca capacidade computacional do dispositivo móvel e também devido às necessidades de tempo de processamento. 4.2 DESENVOLVIMENTO 4.2.1 Visão Geral do Sistema O sistema pode ser visto na Figura 18. Em resumo, o aplicativo é formado das seguintes partes: Uma aplicação móvel: o sistema permite visualizar as informações dos pacientes como: dados pessoais, exames, procedimentos médicos, diagnósticos, alergias e doenças crônicas; Um banco de dados: uma base que modela as informações referentes ao menu de opções; HL7Client: permite a troca de mensagens no padrão HL7 entre aplicações. APLICAÇÃO MÓVEL BD LOCAL NO DISPOSITIVO HL7Client Figura 18: Visão do sistema. 4.2.2 Arquitetura do Sistema 54 Na Figura 19 pode-se notar que através da aplicação é possível acessar a base de dados local do celular, na qual estão as informações dos pacientes. Outras bases, dispositivos HL7 RES local no celular Figura 19: Arquitetura do sistema. O profissional entra no sistema através de usuário e senha, mediante a confirmação dos dados o aplicativo chama o decodificador de QR Code instalado no celular para fazer a leitura da tag. Inicialmente foi realizada a criação de todas as interfaces do sistema. As interfaces foram construídas com o intuito de apresentar as informações dos pacientes, com ou sem conexão de rede, o RES foi criado dentro do banco de dados do celular para atender este fim. A arquitetura móvel pretende proporcionar aos profissionais de saúde a consulta às informações de pacientes para ambientes hospitalares utilizando tecnologias da computação ubíqua. Para isso, levaram-se em consideração no desenvolvimento da ideia os seguintes fatos: Software de gestão hospitalar são instalados em desktops, gerando demora e dificuldade ao acesso; Profissionais de saúde possuem uma agenda de atividades extensa, não dispondo de tempo para procurar a informação; Ambientes hospitalares são, geralmente, grandes e com fluxo intenso de pessoas; A base de dados de pacientes, os Registros Eletrônicos de Saúde, possuem informações enriquecidas, porém, a busca pelo dado necessário é demorada. 4.2.3 Diagrama Entidade-Relacionamento 55 Para modelagem do banco de dados foi feita a partir da extração de informações do documento redigido pelo Comitê de Padronização do Registro Clínico (PORTAL DA SAÚDE, 1999). Apesar de o documento ser antigo, ele foi usado com objetivo de apenas ter um horizonte das quais informações relevantes se deve ter para criar uma base de dados de um RES. A tabela patient está relacionada com a tabela event, que possui como eventos procedimentos médicos (tabela medicalprocedure), exames (tabela exam) e diagnósticos (tabela diagnosis). Um paciente pode ter diversos eventos durante sua vida como: vacinas, cirurgias, acidentes, internações hospitalares, atendimentos domiciliares e ambulatoriais, etc. E as tabelas allergy e chronicdisease estão relacionadas diretamente à tabela patient, pois são aspectos ligados somente ao paciente. O documento PRC indica para alguns campos que sejam populados com lista de códigos específicos da medicina, como o CID10 (Cadastro Internacional de Doenças). Na modelagem do banco foi usada apenas a descrição do código. 56 Figura 20 mostra o diagrama entidade-relacionamento do modelo de dados do sistema. Figura 20: Diagrama entidade-relacionamento. A seguir a descrição das principais entidades do modelo de dados: a) patient: representa os pacientes em atendimento, aqui se armazenam dados relevantes como: idade, sexo, local de nascimento, situação familiar, foto (se existir), hora do cadastro, data de nascimento. As entidades chronicdisease e allergy são relacionadas com o patient; b) event: aqui são armazenados os eventos ocorridos do paciente. Cada evento pode estar relacionado a um exame, diagnóstico, procedimento médico; 57 c) professional: nesta entidade são armazenados os dados do profissional, desde o usuário, senha e especialidade; d) wordlistofspecialty: esta entidade guarda as palavras relacionadas com a especialidade do profissional clínico. 4.2.4 Diagrama de Classes da Aplicação O sistema operacional móvel Android controla o ciclo de vida das activities ou telas. Uma tela poderá estar sendo executada em segundo plano, pausada ou parada. Quando uma tela sai do topo da pilha, ou seja, quando ela sai da execução, outra assume seu posto (LECHETA, 2010, p. 95). Conforme a Figura 21 todas as telas produzidas são subclasses da classe LifeCycle.class. Essa classe controla o ciclo de vida de todas as activities. Isso se faz necessário pelo fato de que as telas são chamadas através de passagem de parâmetro. Por exemplo, caso o médico atenda outro paciente, a aplicação deve destruir telas que guardam o código do paciente, evitando consultar o enfermo incorreto. Outro exemplo de utilidade do ciclo de vida é em caso seja necessário pausar a aplicação médica para chamar outra aplicação do celular. Um exemplo é em caso do profissional de saúde receber uma ligação telefônica, a aplicação médica ficará em segundo plano. A classe Screen1Login.class verifica o usuário e senha no banco de dados. Após é chamada a classe Screen2ReadQRCode.class, que por sua vez chama o aplicativo Barcode Scanner. Essa aplicação faz a leitura de códigos de barras bidimensional e passa como parâmetro o resultado da leitura. A tela Screen2ReadQRCode.class recebe o código do paciente e faz uma chamada através de uma intenção da tela Scren3ListActivity.class, passando como parâmetro o número do paciente. Nessa é criada uma lista de opções como dados demográficos (Screen4PersonalData.class), procedimentos médicos (Screen8MedicalProcedures.class), diagnósticos (Screen9Diagnosis.class), exames (Screen7Exams.class) e alergias (Screen5Allergy.class). A classe DBAdapter.class é responsável pelas SQL na base de dados. E por fim, a classe IdentifierOfContext.class faz a contextualização do usuário. 58 Figura 21: Diagrama de classes. 59 4.2.5 Diagrama de Classes do Serviço HL7 A arquitetura do sistema foi composta com o serviço de troca de mensagens médicas, o HL7 versão 2.4. É de conhecimento a variedade de tipos de mensagens HL7 que existem na norma. No entanto, para testar o uso desse padrão foi adotado no projeto apenas composição de mensagens do tipo ADT^01, usada em admissões de pacientes. A Figura 22 ilustra o diagrama de classes do serviço HL7 da aplicação. Figura 22: Diagrama de classes do serviço HL7 da aplicação. A classe CreateAMessage.class retira as informações necessárias do banco e compõe a mensagem HL7 que retorna uma string. Já a classe SendAndReceiveAMessage.class recebe como parâmetro a mensagem criada na CreateAMessage.class que por sua vez recebe também as respostas do servidor HL7. Para instanciar ambas foi criada a classe Sender.class. Os testes de envio e recebimento das mensagens foram feitos em laboratório. Foi utilizada a ferramenta Test Panel (UNIVERSITY HEALTH NETWORK, 2001) como servidor de mensagens HL7. 4.2.6 Sensibilidade ao Perfil do Usuário A contextualização do usuário é umas das características de um sistema ubíquo (ESCOBAR, 2011). “O contexto é um dos aspectos-chaves dos sistemas pervasivos e diz 60 respeito a toda informação que é relevante e que pode alterar sua funcionalidade” (Augustin apud Lima, 2006, p.3). Considerando esse atributo, a classe IdentifierOfContext.class, foi desenvolvida com o objetivo buscar as informações que sejam importantes no momento do atendimento ao paciente a partir do tipo de profissional. O fluxograma dessa operação é representado na Figura 23. RES chama Especialidade do clínico Classe IdentifierOfContext Activities Screen5Allergy, Screen6ChronicDisease, Screen7Exams, Screen8MedicalProcedu res, Screen9Diagnosis Tabela Allergy Tabela ChornicDisease Tabela Exam Tabela MedicalProcedure Tabela Diagnosis destaca Tabela WordListOfSpeci alty Interfaces XML String existe? sim Figura 23: Fluxograma do processo de identificação de contexto. Ao entrar na aplicação, o sistema identificará a especialidade do profissional. Essa especialidade está relacionada com uma tabela de palavras específicas. Seguindo, as activities (telas) antes de apresentar o conteúdo para o usuário invocam a classe IdentifierOfContext.class, cuja função é comparar cada palavra existente nos campos das tabelas allergy, chronicdisease, exam, medicalprocedure, diagnosis com o conjunto de strings existentes na tabela wordlistofspecialty. Se uma palavra existir, a classe IdentifierOfContext.class informará as activities para destacar essa informação na tela do usuário. Toma-se como exemplo um médico com especialidade em cardiologia, atende um enfermo. Acessa a aplicação, faz a leitura do QR Code. No momento da visualização das informações do paciente, será observada em destaque (fundo da fonte em cor diferente, por exemplo) a palavra diabetes, ou cardíaco; eletrocardiograma. Explorando assim a atenção do usuário nas informações que sejam cruciais e ajudando o médico ou outro profissional a obter um diagnóstico rápido. 61 5 FUNCIONALIDADES DO APLICATIVO E TESTES Neste capítulo são apresentadas as funcionalidades através do cenário de uso. Em seguida, são mostradas as telas do sistema e na próxima seção são mostrados os testes realizados. 5.1 FUNCIONALIDADES O cenário de uso aqui apresentado tem como objetivo principal avaliar a utilidade do sistema num ambiente hospitalar. Dentro de um hospital existe muita movimentação de pessoas, consequência de muitos atendimentos. Nesses por sua vez é usada a aplicação aqui proposta como meio de acesso às informações de saúde do paciente. Impõem-se nesse cenário que o hospital possui uma rede sem fio, estações de trabalho e servidores, trocando informações a todo o momento, todos os pacientes portando suas etiquetas bidimensionais. A essa rede está conectado o dispositivo móvel executando a aplicação proposta. Um enfermeiro com diversos atendimentos agendados necessita de agilidade e acesso às informações sobre os pacientes. Na visita a cada leito, acessa o sistema no celular com usuário e senha. Através da aplicação aciona a leitura do QR Code, portado pelo enfermo (Figura 24). Adiante, o sistema mostra telas, nelas o profissional de saúde tem acesso aos dados mais relevantes do paciente como: dados demográficos, exames realizados, procedimentos médicos, alergias e doenças crônicas. Na tela Exams, o enfermeiro atenta-se para dois destaques na tela: o paciente realizou um exame denominado eletrocardiograma, tendo como resultado hipertrofia ventricular. Aplicação móvel Mensagem HL7 Outras bases HL7 Ambiente Hospitalar Paciente Registro Eletrônico de Saúde local no celular QRCODE Figura 24: Cenário de uso. 62 A informação em destaque é extremamente relevante, pois o enfermeiro identifica que o paciente pratica atividades físicas regulares. Isso demonstra a importância de uma aplicação onde se emprega a sensibilidade ao contexto. É importante ressaltar que o cenário aqui descrito é fictício, foi criado apenas para visualizar a utilidade do aplicativo. 5.2 TELAS DO APLICATIVO Nesta seção serão apresentadas as telas do aplicativo, com descrições objetivas e suas funcionalidades. A Figura 25 mostra a tela de acesso no sistema. Figura 25: Tela de login. . 63 Na parte inferior notam-se as opções “Login” e “Cancel”. Depois de informar o usuário e senha, o utilizar pode pressionar o botão “Login”. Logo após o acesso ao aplicativo Figura 26: Tela de leitura do QR Code. ser efetuado com sucesso, a tela a seguir é mostrada ao usuário (Figura 26). Ela é responsável por chamar o aplicativo Barcode Scanner, acionando-se o botão “Read QRCode”. Figura 27: Tela de menu. 64 A Figura 27 é o menu de opções que o usuário possui para verificar as informações do paciente. Esta tela é mostra somente após a leitura com sucesso da etiqueta bidimensional. Figura 28: Tela de dados pessoais. Todas as opções do menu, com exceção da opção “Exit”, levam à outras telas, que possuem botões de retorno ao menu principal e leitura de um novo QR Code. Verificam-se também botões para visualizar os eventos anteriores, botão “Prev” e os próximos eventos ocorridos com o enfermo, botão “Next”. Pode-se notar também no frame em cada tela, o nome do profissional e o nome do paciente. A Figura 28 é a tela com os dados pessoais do paciente. A Figura 29 é a tela de exames. Nela a sensibilidade ao perfil do usuário é acionada, colocando uma cor de fundo nas palavras que sejam relacionadas com a especialidade do profissional. A Figura 30 representa os procedimentos médicos realizados pelo enfermo. Os diagnósticos podem ser vistos na Figura 31. Já as alergias, na Figura 32. E por fim, as doenças crônicas na Figura 33. 65 Figura 29: Tela de exames. Figura 30: Tela de procedimentos médicos. 66 Figura 31: Tela de diagnósticos. Figura 32: Tela de alergias. 67 Figura 33: Tela de doenças crônicas. 5.3 REALIZAÇÃO DE TESTES Foram feitos testes que tinham como objetivo verificar o tempo de desempenho do sistema e usabilidade. No teste de desempenho, tentou-se medir o tempo de resposta entre as trocas de telas, chamada do decodificador do QR Code, o Barcode Scanner, e chamadas no banco de dados. Além disso, buscou-se verificar o comportamento da aplicação quando forem executadas transações ou regras de negócio sob condições de carga normal ou limite de trabalho. A Tabela 3 mostra os resultados obtidos nos testes. Tabela 3: Teste de Desempenho. Evento Tempo de resposta (segundos) Inicialização do aplicativo 0.81 Login usuário 0.66 Barcode Scanner 2.1 Resposta leitura QR Code 1.1 Transição entre telas 1.2 Nota-se um tempo pouco significativo na resposta aos eventos. É importante ressaltar que em toda transição entre telas existe a execução de SQL. Foi criado um RES com maior quantidade de dados para testar o tempo de resposta às SQL. 68 Com o objetivo verificar a usabilidade do sistema, foram questionados alguns pontos para os usuários onde as respostas são oferecidas para eles numa escala de 0 a 5, conforme Quadro 4. Questões Usuário 1 Usuário 2 Usuário 3 Média Satisfação em relação ao uso do sistema 5,0 5,0 5,0 5,0 Em relação a sua expectativa ao que o sistema propôs fazer 4,0 4,0 5,0 4,3 Os leiautes das telas foram úteis 4,0 4,0 4,0 4,0 Quantidade de informação mostrada na tela 5,0 5,0 4,0 4,7 Organização da informação 4,0 4,0 5,0 4,3 Sequência de telas 5,0 5,0 5,0 5,0 Aprendizado para operar o sistema 4,0 4,0 5,0 4,3 Tempo para aprender usar o sistema 5,0 5,0 5,0 5,0 Lembranças e usos de comandos 5,0 5,0 5,0 5,0 Número de passos para executar uma tarefa 5,0 5,0 4,0 4,7 0,0 1,0 0,0 Falhas de sistema ocorreram 0,0 Quadro 4: Resultados do Teste de Usabilidade. Conforme os resultados a interface foi verificada, está correta e é de fácil compreensão e uso. 69 CONCLUSÃO A quantidade de informações em sistemas de gestão hospitalar e em RES inviabiliza o trabalho dos profissionais de saúde, pois procurar a informação de que se necessita no momento do atendimento ao paciente exige tempo e atenção. Assim, a disponibilidade da informação e a interoperabilidade dos sistemas são extremamente importantes para o andamento dos processos. Para isso, neste trabalho foi definido como objetivo o desenvolvimento de uma arquitetura de um sistema móvel executado em um dispositivo rodando Android que, utilizando conceitos de computação sensível a contexto e ubíqua, tem o objetivo de diminuir o tempo que um profissional de saúde leva para obter do prontuário do paciente os dados relevantes à sua especialidade a fim de agilizar o diagnóstico. Para ressaltar os dados relevantes à especialidade do profissional de saúde em questão, utilizou-se a informação da sua especialidade para mudar o fundo da cor do texto, dando destaque a palavras que estejam associadas à especialidade cadastrada para o usuário do sistema. No desenvolvimento foram usadas as ferramentas SDK Android 2.2, para linguagem de programação Java, HL7 versão para troca de informações médicas, conceitos de computação ubíqua, QR Code. Para leitura das tags foi utilizado o aplicativo Barcode Scanner. Como armazenamento de dados foi usado o banco de dados SQLite. A conclusão do trabalho verifica que foram atingidos com satisfação os objetivos propostos no projeto. Como trabalhos futuros sugere-se aperfeiçoar a segurança do sistema utilizando certificados digitais, parte considerada fundamental numa aplicação que disponibiliza informações sigilosas sobre os pacientes. Outro ponto a trabalhar é a sincronização com bases remotas, utilizando algum middleware livre como ferramenta de sincronismo. Isso por que o espaço para armazenamento de dados em dispositivos móveis é relativamente pequeno e não demanda tanto processamento. 70 REFERÊNCIAS BIBLIOGRÁFICAS ARAÚJO, Regina B. Computação Ubíqua: princípios, tecnologias e desafios. In: SIMPÓSIO BRASILEIRO DE REDES DE COMPUTADORES, 21, 2003, Natal. Anais. Minicurso: Livro Texto.Natal, RN: UFRN/DIMAp: UnP, 2003. 363. Disponível em: < https://twiki2. dcc.ufba.br/pub/MAT570FG/LivroseArtigos/045_AraujoRB.pdf>. Acesso em: 01 fev. 2012. ARAÚJO, Renata Mendes de.; BRÉZILLON, Patrick. Reinforcing shared contexto to improve collaboration. 2000. Disponível em:< http://www-desir.lip6.fr/ /publications/ pub_345_1_RIA_Brezillon_Araujo.pdf>. Acesso em: 05 jan. 2012. AUGUSTIN, Iara. Abstrações para uma linguagem de programação visando aplicações móveis em um ambiente de pervasive computing. 194 f. Tese de Doutorado em Ciência da Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2004, p.76. Disponível em: <http://www.lume.ufrgs.br/bitstream/handle/10183/3866/000405134.pdf? sequence=1>. Acesso em 04 abr. 2012. ASTM. ASTM E2369 05e1 standart specification for continuity of care record (CCR). Disponível em: <http://www.astm.org/Standards/E2369.htm>. Acesso em: 13 de jan. 2012. ANDRY, Francois et al. A mobile application acessing patients’ health records through a rest api. 2011. Disponível em: < http://www.fandry.net/pub/ANDRY_ET_AL_HealthINF11 .pdf>. Acesso em: 11 mar. 2012. BARBOSA, Débora Nice Ferrari. Um modelo de educação ubíqua orientado à consciência do contexto do aprendiz. 181 f. Tese de Doutorado Computação, Universidade Federal do Rio Grande do Sul, Porto Alegre, 2007, p.15. Disponível em: < http://www.lume.ufrgs.br/ bitstream/handle/10183/10271/000594754.pdf?sequence=1>. Acesso em: 10 fev. 2012 BARBOSA, Débora Nice Ferrari et al. Em direção a educação ubíqua: aprender sempre, em qualquer lugar, com qualquer dispositivo. 2008. Disponível em: < http://www.lume.ufrgs.br /bitstream/handle/10183/10271/000594754.pdf?sequence=1>. Acesso em: 10 fev. 2012. BURIOL, Tiago Martinuzzi; ROSENDO, Matheus; SCHEER, Sérgio. Proposta de plataforma baseada em realidade virtual para treinamento de atividades em linha viva. In: CONGRESSO IBERO-LATINO-AMERICANO DE MÉTODOS COMPUTACIONAI EM ENGENHARIA, 30, 2009, Armação dos Búzios. Anais. Curitiba: UFPR. Disponível em:<www.ppgmne.ufpr.b r/gvis/arquivos/publicacoes/buriol_et_al_CILAMCE2009.pdf>. Acesso em: 09 out. 2011. BROWN, Ian; ADAMS, Andrew A. The ethical challenges of ubiquitous healthcare. 2007, p. 54. Disponível em:<http://www.i-r-i-e.net/inhalt/008/008_9.pdf>. Acesso em: 14 ago. 2011. BREZILLON, P.; POMEROL, J.-Ch. Contextual knowledge sharing and cooperation in intelligent assistant systems. 1999. Disponível em:<http://reference.kfupm.edu.sa/content/ c/o/contextual_knowledge_sharing_and_coopera_124440.pdf>. Acesso em: 20 mar. 2012. 71 BARROS, Victor F. A. et al. Aplicativo móvel para automação e monitoração do sistema de atenção primária a saúde. 2011. Disponível em: < http://seer.ufrgs.br/cadernosdeinformatica /article/download/v6n1p241-244/11765>. Acesso em: 02 de mar. 2012. CHEN, G.; KOTZ, D. Solar: a pervasive-computing infrastructure for context-aware mobile applications. Technical Report TR2002-421, February 2002. Disponível em: <http://www.cs.dartmouth.edu/reports/TR2002-421.pdf>. Acesso em: 05 mar. 2012. CIRILO, Carlos E. Computação ubíqua: definição, princípios e tecnologias. 2007. Disponível em: < http://ufscar.academia.edu/ducirilo/Teaching/14124/Computacao_ Ubiqua_definicao_principios_e_tecnologias >. Acesso em: 10 de fev. 2012. CARRO, Luigi; WAGNER, Flávio R. Desafios para a computação pervasiva no futuro cenário tecnológico. In: GRANDES DESAFIOS COMPUTAÇÃO NO BRASIL 2006-2016. , 1, Campinas. Anais. Campinas: SBC. Disponível em:< http://www.ic.unicamp.br/~cmbm /desafios_SBC/Carro_Wagner.pdf>. Acesso em: 10 out. 2011. CHEN, G.; Kotz D. Solar: A pervasive-computing infrastructure for contexto-aware mobile applications. TECHNICAL REPORT TR2000-381. Darmouth Computer Science. Disponível em:< http://www.cs.dartmouth.edu/reports/TR2002-421.pdf>. Acesso em: 11 mar. 2012. CORRÊA, Underléa et al. Redes locais sem fio: conceitos e aplicações. In: ESCOLA REGIONAL DE REDES DE COMPUTADORES, 4, 2006, p. 2, Passo Fundo. Anais. Belo Horizonte: UFSM. Disponível em:<http://www.lbd.dcc. ufmg.br/colecoes/errc/ 2006/018.pdf>. Acesso em: 09 mai. 2012. CIRILO, Carlos Eduardo. Computação ubíqua: definição, princípios e tecnologias. 2007, p. 6. Disponível em:<http://ufscar.academia.edu/ducirilo/Teaching/14124/Computacao_Ubiqua_ definicao_principios_e_tecnologias>. Acesso em: 06 abr. 2012. CAMPIOLO, Rodrigo. Aspectos de modelagem de ambientes de computação ubíqua. 172 f. Dissertação de Mestrado em Ciência da Computação, Universidade Federal de Santa Catarina, Florianópolis, 2005, p. 17. Disponível em: < http://gta.ufrj.br/ftp/gta/TechReports/Ingrid05/te se.pdf>.Acesso em 28 nov. 2011. DEY, Anind K. Understanding and using context. Disponível em:< http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.67.236&rep=rep1&type=pdf>. Acesso em: 11 mar. 2012. DOMINGUES, Fabiano L. Computação ubíqua. 2008. Disponível em: < http://www.hardware.com.br/artigos/computacao-ubiqua/>. Acesso em: 13 mar. 2012. DENSO WAVE. QR Code. 2000. Disponível em:< http://www.qrcode.com/qrfeature.html>. Acesso em: 10 mar. 2012. ESCOBAR, Maurício da Silva; RIBEIRO, Marcelo Blois. U-MAS: Um meta-modelo para o desenvolvimento de aplicações multiagentes ubíquas. In: SIMPÓSIO BRASILEIRO DE SISTEMAS DE INFORMAÇÃO, 7, 2011, Salvador. Anais, Bahia: UFBA, 2011. Disponível em: < http://www.lbd.dcc.ufmg.br/colecoes/sbsi/2011/umas.pdf>. Acesso em: 12 de Março, 2012. 72 FORTE, Marcos; SOUZA, Wanderley Lopes; PRADO, Antonio Francisco. Utilizando ontologias e serviços web na computação ubíqua. In: SIMPÓSIO BRASILEIRO DE ENGENHARI DE SOFTWARE, 20, 2009, p. 287, Florianópolis. Anais. Belo Horizonte: UFMG. Disponível em: <http://www.lbd.dcc.ufmg.br:8080/colecoes/sbes/2006/019.pdf>. Acesso em: 09 jan. 2012. FLÔR, Daniela Eloise et al. MiD-Mobile Middleware distribuído para adaptação e gerenciamento de transações em ambiente de computação móvel. In: SEMINÁRIO INTEGRADO DE SOFTWARE E HARDWARE, 28, 2008, Belém do Pará. Anais. Belo Horizonte: UFMG. Disponível em:< http://www.lbd.dcc.ufmg.br/colecoes/semish/2008/010.p df>. Acesso em: 25 out. 2011. GOMES, Alexandre R. UbiquitOS – Uma proposta de arquitetura de middleware para adaptabilidade de serviços em sistemas de computação ubíqua. 100 f. Dissertação de Mestrado em Informática, Universidade Brasília, Brasília, 2007. Disponível em: < http://repositorio.bce.unb.br/bitstream/10482/2472/1/2007_AlexandreRodriguesGomes.pdf> Acesso em: 12 out. 2011. GOULART, Leandro J., et al. Saúde e tecnologia da informação: convergência e mobilidade. In: CONGRESSO BRASILEIRO DE INFORMÁTICA NA SAÚDE, 7, 2010, Curitiba. Anais. Curitiba: SBIS. Disponível em: <http://www.sbis.org.br/cbis/arquivos/670.pdf>. Acesso em: 10 ago. 2011. GRUPO DE SISTEMAS DE COMPUTAÇÃO MÓVEL. ClinicSpace – Auxílio às tarefas clínicas em um ambiente hospitalar do futuro baseado em tecnologias da computação ubíqua/pervasiva. Santa Maria: UFSM, 2010. Disponível em: <www-gmob.inf. ufsm.br>. Acesso em: 10 jul. 2011. GRUBER, Thomas R. A translation approach to portable ontology specifications. 1993. Disponível em:<http://www.dbis.informatik.hu-berlin.de/dbisold/lehre/WS0203/SemWeb/lit /KSL-92-17.pdf>. Acesso em: 20 nov. 2011. GRÜN, Christoph et al. Assisting tourists on the move – an evaluation of mobile tourist guides. 2008. Disponível em: <http://publik.tuwien.ac.at/files/PubDat_170357.pdf>. Acesso em: 04 abr. 2012. GONÇALVES, Luciano Witt. Prontuário eletrônico do paciente adotando padrões para telemedicina no Brasil. 2010. 49 f. Monografia de conclusão de curso (Graduação em Ciência da Computação), Universidade Federal do Rio Grande do Sul, Porto Alegre, 2010, p.16. Disponível em:<http://www.lume.ufrgs.br/bitstream/handle/10183/26348/000757803. .pdf?sequence=1>. Acesso em: 01 de maio, 2012. GOOGLE. Gmail. 2010. Disponível em:<https://mail.google.com/intl/pt/policies/>. Acesso em: 30 jun. 2012. ______. Android 2.2 platform. 2011. Disponível em: < http://developer.android.com/s>. dk/android-2.2.html>. Acesso em: 28 de Fevereiro, 2012. 73 GALPIN, Michael. Trabalhando com xml no Android. 2008, p.1. Disponível em: < http://www.ibm.com/developerworks/br/opensource/library/x-android/ >. Acesso em: 23 de abril, 2012. GOOGLE PROJECT. Zxing – Multi-format 1D/2D barcode image processing library with clients for Android, Java. 2011. Disponível em:< http://code.google.com/p/zxing/>. Acesso em: 10 out. 2011. GUERRA, Gustavo Pereira. Desenvolvimento de um aplicativo para iphone e ipad para acesso a informações médicas em um hospital pervasivo no âmbito do projeto clinicspace. 49 f. Trabalho de Conclusão de Curso, Universidade Federal de Santa Maria, Santa Maria, 2010. Disponível em: < http://www-app.inf.ufsm.br/bdtg/arquivo.php?id=137&download=1>. Acesso em: 03 de Março, 2012. GERCOM UFPA. Research Group on Computer Networks and Multimedia Communication. 2012. Disponível em:< http://gercom.ufpa.br/>. Acesso em: 07 de Abril, 2012. HL7. About HL7. Disponível em: <http://www.hl7.org/about/index.cfm?ref=nav>. Acesso em: 26 fev. 2012. IDC. Neraly 1 billion smart connected devices shipped in 2011 with shipments expected to double by 2016, according to IDC. Disponível em: < http://www.idc.com/getdoc.jsp?contai nerId=prUS23398412 >. Acesso em: 26 de abril, 2012 JÚNIOR, Henrique de Aguiar Sá Vila Nova. Proposta de um sistema ubíquo para ambiente hospitalar de Urgência. 2008. Disponível em: < http://www.unibratec.edu.br/tecnologus/wpcontent/uploads/2008/09/n3_vilanova_h.pdf>. Acesso em 09 de Março, 2012. KIRNER, Claudio; SISCOUTTO, Robson. Realidade virtual e aumentada: conceitos, projeto e aplicações. 2007. Disponível em:< http://www.de.ufpb.br/~labteve/publi/ 2007_svrps.pdf>. Acesso em: 3 jan. 2012. KAHL, Marcelo; FLORIANO, Diogo. Computação ubíqua, tecnologia sem limites. 2012, p.4. Disponível em:< http://www.ceavi.udesc.br/arquivos/id_submenu/387/diogo_floriano_ marcelo_kahl_computacao_ubiqua.pdf>. Acesso em: 12 fev. 2012. LEY, David. Ubiquitous Computing. 2007, p.64. Disponível em: < http://www.mmiweb.org. uk/publications/ict/emerging_tech02.pdf>. Acesso em: 10 mar. 2012. LOUREIRO, Antonio Alfredo Ferreira. Redes sem fio na computação ubíqua. 2007, p.1. Disponível em:<http://www.clickciencia.ufscar.br/page.php?story=471>. Acesso em: 30 mar. 2012. LECHETA, Ricardo Rodrigues. Google Android: aprenda a criar aplicações para dispositivos móveis com o Android sdk. 2.ed. p. 29-31, 95, 98. São Paulo: Novatec, 2010. LIMA, João Carlos Damasceno et al. Serviço de autenticação em espaços pervasivos, o caso do projeto pBuy. In: SIMPÓSIO DE INFORMÁTICA DA REGIÃO CENTRO/RS, 5, 2006, Santa Maria, p.3. Anais, Santa Maria: UNIFRA, 2006. Disponível em: < http://www.sirc.u 74 nifra.br/artigos2006/SIRC-Artigo12.pdf >. Acesso em: 15 mar. 2012. MELOAN, Steve. Toward a global internet of things. Sun Developer Network, 2003. Disponível em: <http://java.sun.com/developer/technicalArticles/Ecommerce/rfid/>. Acesso em: 12 ago. 2011. MACHADO, Alencar; AUGUSTIN, Iara. Associando contexto às tarefas clínicas na arquitetura clinicspace. In: SIMPÓSIO BRASILEIRO DE SISTEMAS DE INFORMAÇÃO, 7, 2011, Salvador. Anais. Bahia: UFBA, 2011. Disponível em: < http://www.lbd.dcc.ufmg.br/cole coes/sbsi/2011/associandocontexto.pdf>. Acesso em: 11 mar. 2012. ______. Associação do contexto de interesse do usuário às atividades clínicas na arquitetura clinicspace. 2010. 92 f. Dissertação de Mestrado em Ciência da Computação, Universidade Federal de Santa Maria, Santa Maria, 2010, p.18. Disponível em: <http://cascavel.cpd.ufsm.br/tede/tde_busca/arquivo.php?codArquivo=3467>. Acesso em: 31 de jan. 2012. ______. et al. Aplicações móveis de acesso às informações do paciente. In: CONGRESSO BRASILEIRO DE INFORMÁTICA NA SAÚDE, 22, 2010, Porto de Galinhas. Anais. Porto de Galinhas: ITARGET, 2010. MORAES, João Luís Cardoso de; SOUZA, Wanderley Lopes de; PRADO, Antonio Francisco do. Ambiente de Computação. In: SEMINÁRIO INTEGRADO DE SOFTWARE E HARDWARE, 36, 2009, Bento Gonçalves. Anais. Bento Gonçalves: UFRGS. Disponível em: <http://www.lbd.dcc.ufmg.br/colecoes/semish/2009/005.pdf>. Acesso em: 10 jan. 2012. MATEAS, Michael et al apud BOLZANI, Caio Augustus Morais. Análise de arquiteturas e desenvolvimento de uma plataforma para residências inteligentes. 155 f. Tese de Doutorado em Engenharia Elétrica, Universidade de São Paulo, São Paulo, 2010, p.39. Disponível em: < http://www.teses.usp.br/teses/disponiveis/3/3142/tde-12082010-112005/publico/Tese_Caio_ Augustus_Morais_Bolzani.pdf>. Acesso em 21 nov. 2011. MORSE, David R.; ARMSTRONG, Stephen; DEY, Anind K. The what, who, where, and how of context awareness (2000). 2000. Disponível em:< http://citeseerx.ist .psu.edu/viewdo c/summary?doi=10.1.1.32.8174>. Acesso em: 23 mar. 2012. MADEIRA, Rui Miguel Neves G. Uma infra-estrutura computacional para aumentar objectos reais com informação adicional. 181 f. Dissertação de Mestrado em Engenharia Informática, Universidade Nova de Lisboa, Lisboa, 2007, p.23. Disponível em: < http://run. unl.pt/ bitstream/10362/1963/1/Madeira_2007.pdf>. Acesso em 28 nov. 2011. MASSAD, Eduardo et al. O prontuário eletrônico do paciente na assistência, informação e conhecimento. 2003, p. 6. Disponível em:<http://www.sbis.org.br/site/arquivos/prontuario. pdf>. Acesso em: 13 fev. 2012. NINO, Cássia Pereira. MaPS – Um framework para aplicações colaborativas em ambientes de computação ubíqua. 75 f. Dissertação de Mestrado em Computação, Universidade do Vale do Rio do Sinos, São Leopoldo, 2009, p.24. Disponível em: < http://bdtd.unisinos.br/ 75 tde_arquivos/1/TDE-2009-07-18T111405Z-771/Publico/NinoCassiaPereiraComputacao.pdf>. Acesso em: 10 fev. 2012. OHA. Open Handset Alliance Members. 2012. Disponível em: < http://www.openhandsetal. liance.com/oha_members.html>. Acesso em: 22 de abril, 2012. PETRY, Karine; LOPES, Paula Marien Albrecht. Modelos para interoperabilidade de sistemas hospitalares utilizando padrão HL7. 2005. 189 p. Monografia de conclusão de curso (Graduação em Sistemas de Informação), Universidade Federal de Santa Catarina, Florianópolis, 2005. Disponível em: < http://projetos.inf.ufsc.br/arquivos_projetos/projeto_377/Interoperabilidade%20de%20Sistem as%20Hospitalares%20Utilizando%20o%20Padr%E3o%20HL7.pdf>. Acesso em: 01 mai. 2012. PORTAL DA SAÚDE. Conjunto essencial de informações do prontuário para integração da informação em saúde. 1999. Disponível em:< http://portal.saude.gov.br/portal/arquivos/pd f>. Acesso em: 04 ago. 2011. RIES, Luis H. Estudo de arquiteturas para computação pervasiva. 2005. Disponível em: <http://gse.ufsc.br/~bezerra/students/_outros_orientadores/LuisHenriqueRies/ti1.pdf>. Acesso em: 04 set. 2011. RABELLO, Ramon Ribeiro. Android: um novo paradigma de desenvolvimento móvel. Disponível em: < http://www.cesar.org.br/site/files/file/WM18_Android.pdf >. Acesso em: 21 de abril, 2012. SIORPAES, Sven, et al. Mobile interaction with the internet of things. 2006. Disponível em: <http://www.medien.ifi.lmu.de/pubdb/publications/pub/siorpaes2006pervasivelbr/siorpaes200 6pervasivelbr.pdf>. Acesso em: 10 set. 2011. SOUZA, Marcos Vinicius Bittencourt de. Inferência de atividades clínicas na arquitetura clinicspace a partir de propriedades do contexto. 153 f. Dissertação de Mestrado em Computação, Universidade Federal de Santa Maria, Santa Maria, 2010. Disponível em: <http://cascavel.cpd.ufsm.br/tede/tde_busca/arquivo.php?codArquivo=3444>. Acesso em: 27 fev. 2012. STRANG, Thomas; LINNHOFF-POPIEN, Claudia. A context modeling survey. 2004. Disponível em:< http://elib.dlr.de/7444/1/Ubicomp2004ContextWSCameraReadyVersion.pdf >. Acesso em: 30 abr. 2012. SOUZA, Alexandre Renato Rodrigues. Medicina ubíqua. 2011, p.7. Disponível em:< http://ubiq.inf.ufpel.edu.br/sscau/lib/exe/fetch.php?media=2011-12-25_alexandre_medic ina_ubiqua.pdf>. Acesso em: 20 mai. 2012. SOARES, Vinicius de F. Identificação única de pacientes em fontes de dados distribuídas e heterogêneas. 2009. 153 f. Dissertação de Mestrado em Informática, Universidade Federal do Espírito Santo, Vitória, 2009, p.63. Disponível em:< http://codims.lprm.inf.ufes.br/publicaco es/dissertacaoVinicius.pdf>. Acesso em: 10 de fev. 2012. 76 SPINOLA, Eduardo Oliveira. Android, a nova plataforma móvel – parte 1. Disponível em: < http://www.devmedia.com.br/android-a-nova-plataforma-movel-parte-i/8431>. Acesso em: 25 de abril, 2012. SQLITE. About SQLite. 2011. Disponível em:< http://www.sqlite.org/about.html>. Acesso em: 01 jul. 2012. TRUONG, Khai N.; ABOWD, Gregory D.; BROTHERTON, Jason A. Who, what, when, where, how: design issues of capture & access applications. 2001. Disponível em:< http://khaitruong.com/publications/UBICOMP-2001.pdf>. Acesso em: 13 mar. 2012. TEIXEIRA, Ingrid. Roteamento com balanceamento de consumo de energia para redes de sensores sem fio. 109 f. Dissertação de Mestrado em Ciências em Engenharia Elétrica, Universidade Federal do Rio de Janeiro, Rio de Janeiro, 2005, p.7. Disponível em: < http://gta.ufrj.br/ftp/gta/TechReports/Ingrid05/tese.pdf>. Acesso em: 28 nov. 2011. UNIVERSITY HEALTH NETWORK. HAPI. 2001. Disponível em: < hl7api.sourceforge.net >. Acesso em: 20 nov. 2011. VICENTINI, Caroline F., et al. PEHS – Arquitetura de um sistema de informação pervasivo para auxílio às atividades clínicas. Revista Brasileira de Computação Aplicada. Passo Fundo, n.2, set. 2010. Disponível em: <http://www.upf.br/seer/index.php/rbca/article/view/970/783> Acesso em: 10 ago. 2011. VIEIRA, Vaninha et al. Uso e representação de contexto em sistemas computacionais. 2006, p.15. Disponível em:< http://www.cin.ufpe.br/~fcf3/Contexto%20Computacional/Artigos%20 Computacional/Artigos%20B%E1sicos/Minicurso-SBSC-Texto-FINAL.pdf>. Acesso em: 15 out. 2011. VIDAL, Derig Almeida et al. Um ambiente ubíquo para o suporte ao compartilhamento de recursos educativos. In: CIRCUITO DE TECNOLOGIA DA INFORMAÇÃO, 6, 2010, Rio de Janeiro. Anais. Rio de Janeiro: Essentia. Disponível em: < http://www.essentiaeditora.iff. edu.br/index.php/citi/article/viewFile/1448/676>. Acesso em: 10 jan. 2012. W3C. Composite Capability/Preference Profiles (CC/PP): Structure and Vocabularies 2.0 W3C Working Draft 30 April 2007. Disponível em: < http://www.w3.org/TR/2007/WDCCPP-struct-vocab2-20070430/>. Acesso em: 30 jun. 2012. WEISER, Mark. The computer for the 21st century. Scientific American. [S.l.], p.94 – 104, 1991. Disponível em: <http://www.ubiq.com/hypertext/weiser/SciAmDraft3.html>. Acesso em: 10 de ago. 2011.
Download
