UNIJUÍ UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL. DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS

Transcrição

1 UNIJUÍ UNIVERSIDADE REGIONAL DO NOROESTE DO ESTADO DO RIO GRANDE DO SUL DCEEng DEPARTAMENTO DE CIÊNCIAS EXATAS E ENGENHARIAS CURSO DE GRADUAÇÃO EM CIÊNCIA DA COMPUTAÇÃO Uma Arquitetura Baseada em Web Services para Apoio à Correta Execução das Recomendações Médicas pelo Paciente MARIANA TEIXEIRA DORNELLES PARISE Santa Rosa, RS - Brasil 2014

2 MARIANA TEIXEIRA DORNELLES PARISE Uma Arquitetura Baseada em Web Services para Apoio à Correta Execução das Recomendações Médicas pelo Paciente 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 obtenção do grau de Bacharel em Ciência da Computação. Orientador: Edson Luiz Padoin Santa Rosa, RS - Brasil 2014

3 Dedicatória Dedico este trabalho a todos os professores que já tive, pois sem eles nada seria possível.

4 AGRADECIMENTOS Agradeço primeiro a Deus, por me permitir a benção de mais uma encarnação, dos erros e aprendizados que só a vida terrena nos proporciona. Aos meus pais por terem me acolhido em sua família, obrigada por terem sido meus primeiros professores, me ensinando o valor do estudo e do trabalho, sem falar dos inúmeros valores morais. Ao meu esposo pela paciência e apoio incondicional, obrigada por nunca ter me deixado desistir. A todos os professores que já tive, principalmente ao meu orientador Edson Luiz Padoin e aos professores Gerson Battisti, Sandro Sawicki e Vinicius Maran. Agradeço também aos meus amigos Carolina Belmonte, Francis Neis dos Santos e Cristiano Politowiski que estavam sempre prontos para dar um bom palpite.

5 RESUMO Os Sistemas de Informação e a internet tem se tornado essenciais, sendo usados inclusive no apoio aos pacientes durante tratamentos médicos. Devido ao fato dos medicamentos exercerem importante papel no sucesso destes tratamentos, há necessidade do desenvolvimento de estratégias para contribuir com correta execução das recomendações médicas. Trabalhos recentes indicam a importância dos pacientes receberem informações precisas e consistentes a respeito das terapias medicamentosas, sendo os Sistemas de Informação em Saúde podem proporcionar essa facilidade. Através de pesquisa bibliográfica verificou-se a carência de sistemas para o auxílio ao paciente em relação aos tratamentos farmacológicos. Dentre os sistemas estudados poucos apresentaram garantia à fidelidade das recomendações médicas ou possibilidade de interoperar com outros sistemas. Baseando-se nas limitações dos sistemas estudados, este trabalho propõe uma arquitetura que objetiva facilitar a administração de medicamentos levando em conta o contexto de cada paciente (tempo e localidade), garantindo fidelidade às recomendações médicas e permitindo a interoperabilidade do mesmo através de módulos baseados em Web Services e HL7. Tal arquitetura divide-se em três módulos: módulo web, módulo móvel e módulo de controle. Este trabalho propõe-se a desenvolver um dos módulos. Como resultado foi desenvolvido um protótipo de módulo de controle que implementa completamente os Web Services e parcialmente o padrão HL7. Palavras-chave: Sistemas Distribuídos, Sistemas de Informação em Saúde, Web Services, REST, HL7, Padrões de Informação em Saúde, Administração de Medicamentos, Assistente de Medicação.

6 ABSTRACT Information Systems and the Internet has become essential, including being used on supporting patients during medical treatments. Because of the drugs exert major role to the success of these treatments, is required to develop strategies to help with proper execution of medical recommendations. Recent studies indicate the importance of patients receive consistent and accurate information about the drug therapies, and the Health Information Systems can provide this facility. Through literature there is a lack of systems to aid the patient in relation to pharmacological treatments. The studied systems showed little guarantee to the fidelity of medical recommendations or the possibility of interoperate with other systems. Based on the limitations of the studied systems, this paper proposes an architecture that aims to facilitate the administration of medication taking into account the context of each patient (time and location), ensuring fidelity to medical recommendations and enabling interoperability through the same modules based on Web Services and HL7. This architecture is divided into three modules: web module, mobile module and the control module. This study aims to develop one module. As a result we developed a prototype of a control module that implements the Web Services completely and partially the HL7 standard. Key-words: Distributed Systems, Healthcare Systems, Web Services, REST, HL7, Information Healthcare Standards, Medication Adherence, Medication Advisor.

7 LISTA DE SIGLAS ADL AMESC API BD CEP CML CoOL CORBA CPF CRM DB4o DICOM EHS EJB ER GLN GPS IDE IHC HAPI HL7 HTML HTTP JSF JPA JVM NFC OMS ORM PEP Archetype Definition Language Assistente de Medicação Sensível ao Contexto Baseado em Web Services Application Programming Interface Banco de Dados Código de Endereçamento Postal Context Modeling Language Context Ontology Language Common Object Request Broker Architecture Cadastro de Pessoa Física Conselho Regional de Medicina DataBase for Objects Digital Imaging and Communications in Medicine Eletronic Healthcare Systems Enterprise Java Beans Entidade-Relacionamento Gerador de Linguagem Natural Global Positioning System Integrated Development Kit Interação Humano Computador HL7 Application Programming Interface Health Level Seven HyperText Markup Language Hypertext Transfer Protocol JavaServer Faces Java Persistence API Java Virtual Machine Near Field Communication Organização Mundial de Saúde Object Role Modeling Prontuário Eletrônico do Paciente

8 RDC RES REST RFID RG RMI RPC P2P SDK SGH SI SIC SIS SisMAM SMS SMTP SOAP SQL STIN S-RES SGBD UDDI UML URL URI W3C WS WSD WSDL XML Resolução da Diretoria Colegiada Registros Eletrônicos de Saúde Referência de Estilo Representacional Radio-Frequency IDentification Registro Geral Remote Method Invocation Remote Procedure Call Peer-to-Peer Software Development Kit Sistema de Gestão Hospitalar Sistemas de Informação Sistemas de Informação Clinica Sistemas de Informação em Saúde Sistema Móvel para Administração de Medicamentos Short Message Service Simple Mail Transfer Protocol Simple Object Acess Protocol Structured Query Language Simpósio de Tecnologia da Informação Sistemas de Registro Eletrônico de Saúde Sistema de Gerenciamento de Banco de Dados Universal Description, Discovery, and Integration Unified Modeling Language Uniform Resource Locator Universal Resource Identifier World Wide Web Consortium Web Services Web Service Description Web Service Description Language extensible Markup Language

9 LISTA DE FIGURAS Figura 1 - Exemplo de código XML Figura 2 - Estrutura da Mensagem SOAP Figura 3 - Arquitetura do Sistema Online de Agendamento de Consultas baseado em Web Services Figura 4 - Visão geral do sistema PEP Figura 5 - Arquitetura do Assistente de Medicação Figura 6 - Arquitetura do Aplicativo Mobile Medicine Figura 7 - Arquitetura do Sistema AMESC Figura 8 - Diagrama entidade-relacionamento Figura 9 - Diagrama de pacotes Figura 10 Classes do pacote modelo Figura 11 Classes do pacote dao Figura 12 Classes do pacote resources Figura 13 Classe do pacote hl Figura 14 Classes do pacote testes Figura 15 Classe de configuração do hibernate Figura 16 Configuração do hibernate Figura 17 Exemplo de classe anotada Figura 18 Classe web.xml Figura 19 Estrutura da classe AlarmeResource.java Figura 20 Método getalarmes Figura 21 Método getalarme Figura 22 Método adicionaalarme... 68

10 Figura 23 Método atualizaalarme Figura 24 Método removealarme Figura 25 Estrutura da classe createamessage Figura 26 Método createmessage Figura 27 Método createxmlmessage Figura 28 Métodos stringtomessage e xmlmessage Figura 29 Método getinfo Figura 30 Classe HL7Resource Figura 31 Método getmessage Figura 32 Método getxmlmessage Figura 33 Método recebemensagem Figura 34 Método recebemensagemxml Figura 35 Inserção de um alarme Figura 36 Confirmação da inserção Figura 37 Recuperação de todos os alarmes Figura 38 Atualização de um alarme Figura 39 Confirmação de atualização Figura 40 Consulta à um alarme Figura 41 Exclusão de um alarme Figura 42 Confirmação da exclusão Figura 43 Nova consulta a todos os alarmes Figura 44 Acesso as informações do paciente através de uma mensagem HL Figura 45 Criação da tabela alarme Figura 46 Criação da tabela dispositivo Figura 47 Criação da tabela medicamento Figura 48 Criação da tabela local

11 Figura 49 Criação da tabela restricao Figura 50 Criação da tabela local_pacoente Figura 51 Criação da tabela medico Figura 52 Criação da tabela paciente Figura 53 Criação da tabela pessoa Figura 54 Criação da tabela restricao_medicamento Figura 55 Criação da tabela prescricao... 97

12 LISTA DE QUADROS Quadro 1 Relação entre os métodos HTTP e as operações em banco de dados relacionais. 30 Quadro 2 - Comparativo entre formas de representação de contexto Quadro 3 - Comparativo tecnológico entre os trabalhos relacionados Quadro 4 - Descrição da prescrição médica Quadro 5 - Representação das preferências do paciente Quadro 6 - Histórico de notificações do paciente em um dia normal Quadro 7 - Correspondências entre métodos HTTP, operações e URIs na entidade alarme

13 SUMÁRIO INTRODUÇÃO PROBLEMA PROJETO ASSISTENTE DE MEDICAÇÃO SENSÍVEL AO CONTEXTO BASEADO EM WEB SERVICES (AMESC) ORGANIZAÇÃO DO TRABALHO REFERENCIAL TEÓRICO SISTEMAS DE INFORMAÇÃO EM SAÚDE PADRÕES DE INFORMAÇÃO EM SAÚDE TIPOS DE APLICAÇÃO PRESCRIÇÃO MÉDICA COMPUTAÇÃO DISTRIBUÍDA E WEB SERVICES ESTILOS ARQUITETURAIS E MIDDLEWARE WS SOAP WSDL REST APLICAÇÕES SENSÍVEIS AO CONTEXTO AQUISIÇÃO DE CONTEXTO MODELOS DE REPRESENTAÇÃO DE CONTEXTO TRABALHOS RELACIONADOS ANÁLISE PROJETO E CENÁRIO ARQUITETURA AMESC... 44

14 3.1.1 MÓDULO WEB MÓDULO DE CONTROLE MÓDULO MÓVEL CENÁRIO HIPOTÉTICO MODELAGEM E IMPLEMENTAÇÃO ANÁLISE DE REQUISITOS DADOS DO PACIENTE DADOS DO MÉDICO DADOS DO MEDICAMENTO DADOS DA PRESCRIÇÃO DADOS DO USUÁRIO DADOS DOS ALARMES DADOS DOS DISPOSITIVOS MODELAGEM DOS REQUISITOS TECNOLOGIAS UTILIZADAS POSTGRESQL HIBERNATE JAVA API HAPI JAX-RS ASTAH POSTER MOZILLA FIREFOX NETBEANS IDE IMPLEMENTAÇÃO DIAGRAMA DE PACOTES... 57

15 4.4.2 DIAGRAMAS DE CLASSES CLASSES DO PACOTE MODELO CLASSES DO PACOTE DAO CLASSES DO PACOTE RESOURCES CLASSE DO PACOTE HL CLASSES DO PACOTE DE TESTES CLASSE DE CONFIGURAÇÃO DO HIBERNATE DETALHES DE IMPLEMENTAÇÃO IMPLEMENTAÇÃO DO BANCO DE DADOS IMPLEMENTAÇÃO DO WEB SERVICE REST IMPLEMENTAÇÃO DAS MENSAGENS HL RESULTADOS SIMULAÇÃO ALARMERESOURCE.JAVA HL7RESOURCE.JAVA CONSIDERAÇÕES FINAIS REFERÊNCIAS BIBLIOGRÁFICAS APÊNDICE A APÊNDICE B... 98

16 15 INTRODUÇÃO Com o passar dos anos, os Sistemas de Informação em Saúde (SIS) tem se difundido cada vez mais e se tornam muitas vezes indispensáveis. Tais sistemas são definidos pela Organização Mundial de Saúde (OMS) como mecanismos constituídos de fases de coleta de dados, processamento, análise e transmissão de informação, objetivando o gerenciamento dos serviços de saúde, promovendo organização, operacionalização e produção de informações (CAVALCANTE; FERREIRA; SILVA, 2011). A internet tem se tornado uma ferramenta importante no aperfeiçoamento de hospitais e clínicas permitindo que os pacientes interajam facilmente com os profissionais de saúde (FIELD et al, 2011). Com base no levantamento bibliográfico realizado podemos observar que uma grande parcela dos SIS é voltada para as instituições e profissionais de saúde, podendo destacar-se o apoio à decisão, prontuários e registros eletrônicos. E uma minoria de sistemas voltados ao apoio do paciente, como sistemas para agendamento de consultas, administração de medicamentos ou mesmo lembretes quanto às revisões periódicas e realização de exames (ZHANG et al, 2012) e (SYMEY; SANKARANARAYANAN; BINTI SAIT, 2013). Dentre os sistemas de apoio ao paciente pesquisados, destacam-se os sistemas de administração de medicamentos devido à importância da administração correta dos remédios para o sucesso do tratamento médico (SCHEIER et al, 2013). A respeito de tais sistemas, pode-se notar que poucos apresentam restrições quanto aos dados da administração de medicamentos, permitindo ao paciente inserir os fármacos a serem tomados e sua posologia, e não garantindo total fidelidade às recomendações médicas. Portanto faz-se necessário ampliar os estudos e pesquisas de sistemas que possibilitem fidelidade às recomendações dos profissionais de saúde e a interoperabilidade, permitindo interações com softwares de clínicas médicas. Assim também, auxiliando no tratamento médico e possibilitando futuras trocas de informações, as quais poderão agilizar e tornar mais dinâmico o tratamento médico. Tendo em vista que a ingestão correta dos medicamentos representa um desafio tanto para o público idoso, quanto para qualquer pessoa que necessite tomar algum fármaco de acordo com um escalonamento complexo (SCHREIER et al, 2013). O presente trabalho visa propor a arquitetura de um assistente de medicamentos e desenvolver um módulo da mesma. Sendo esta arquitetura sensível ao contexto baseado em Web Services (WS), auxiliando na administração de medicamentos provendo uma solução voltada para o paciente que parte da

17 16 premissa que todas as prescrições estão corretas, apenas com o intuito de facilitar a correta execução dos procedimentos recomendados. 1.1 Problema Os medicamentos ocupam uma posição importante nos tratamentos médicos (CASSIANI, 2005), sendo assim, a administração errada dos mesmos pode trazer danos à saúde do paciente e prejuízos ao tratamento. O uso correto dos medicamentos é uma atividade séria e que exige responsabilidade perante às consequências de possíveis enganos (LOPES; CARDOSO, 2012). Neste contexto De Camargo Silva et al (2007) demonstram que erros de comunicação perante a administração de medicamentos podem ser fatais através de um estudo descritivo realizado em uma unidade de clínica médica e na farmácia de um hospital universitário, durante este estudo foram analisadas 294 prescrições médicas concluindo que 34,7% estavam ilegíveis ou parcialmente legíveis, 95,9% utilizavam abreviaturas e 94,9% estavam incompletas. Através destes fatos podemos verificar a importância de além da prescrição escrita à mão, o sistema trazer às informações da prescrição ao paciente. Cassiani (2005) afirma que a administração errada dos medicamentos por parte do paciente também ocorre e enfoca na necessidade de informações completas e claras para uma boa administração. A autora mostra que em uma abordagem focada no paciente os erros geralmente são falta de atenção, esquecimento, falta de cuidado e negligência. A aderência aos medicamentos é um comportamento que desempenha valioso papel em terapias baseadas em remédios (SCHEIRER et al, 2013), sendo assim podemos destacar a importância de desenvolver estratégias para contribuir com tal aderência (FERREIRA, 2013). Vicente (2012) afirma que qualquer pessoa pode necessitar de medicamentos em qualquer altura da vida, porém, algumas doenças exigem administração rígida de medicamentos, principalmente as doenças crônicas e as doenças características do envelhecimento (LOBO, 2013). Tornando público alvo deste trabalho todas as pessoas que necessitarem administrar a medicação a ser tomada com maior rigidez. Com base no estudo realizado podemos concluir que são poucos os sistemas de administração de medicamentos que garantem a fidelidade às recomendações do médico e permitem a troca de informações com outros sistemas através da interoperabilidade. Sendo assim, na maioria das vezes não há garantia de que o paciente vá receber, através do sistema,

18 17 às informações corretas a respeito da administração dos fármacos, podendo tal fato prejudicar o tratamento médico. 1.2 Projeto Assistente de Medicação Sensível ao Contexto baseado em Web Services (AMESC) Este trabalho deu origem ao Projeto AMESC, o qual surgiu através do levantamento bibliográfico apresentado no capítulo dois e da análise das limitações das arquiteturas existentes. Dentre essas limitações podemos destacar que uma pequena quantidade dos SIS é voltada ao apoio do paciente e que esse número é ainda menor quando trata-se de sistemas para a administração de medicamentos. Dentre os sistemas que visam a administração de medicamentos não é prioridade a garantia de fidelidade à prescrição médica e nem o uso de padrões de informação em saúde. A partir destes fatos, o projeto visa desenvolver a arquitetura proposta neste trabalho. Esta arquitetura descreve um assistente de medicamentos baseado em Web Services que tem por objetivo facilitar a administração de medicamentos, garantir fidelidade às recomendações médicas, permitir a interoperabilidade do mesmo através de módulos e auxiliar na administração de medicamentos levando em conta o contexto de cada paciente (tempo e localidade). Consideramos que todas as prescrições médicas estão corretas, tendo por objetivo apenas auxiliar na correta execução das recomendações médicas. Este projeto foi apresentado no STIN como uma arquitetura interoperável, extensível e dividida em três módulos (PARISE, M; PARISE, D; MARAN, 2014), a qual será explicada em mais detalhes no capítulo três. Neste trabalho será desenvolvido o módulo de controle, sua implementação pode ser conferida no capítulo quatro. 1.3 Organização do Trabalho O presente trabalho está estruturado em seis capítulos. O capítulo um introduz do tema abordado e o capítulo dois apresenta o referencial teórico, amparando conceitos abordados neste trabalho. O capítulo três apresenta o projeto no qual este trabalho está inserido, o 1 V Simpósio de Tecnologia da Informação (STIN) realizado em outubro de 2014 na Universidade Regional Integrada do Alto Uruguai e das Missões (URI) Campus de Santo Ângelo, RS.

19 18 capítulo quatro apresenta detalhes da modelagem e implementação e o capítulo cinco apresenta os resultados obtidos. Posteriormente são apresentas as considerações finais, abordando as conclusões obtidas durante a elaboração deste trabalho e as propostas para trabalhos futuros, seguido das referências bibliográficas.

20 19 2 REFERENCIAL TEÓRICO Este capítulo servirá para apresentar a contextualização dos tópicos necessários para a compreensão deste trabalho. A sessão 2.1 apresenta os Sistemas de Informação em Saúde, a sessão 2.2 explana a respeito de Computação Distribuída e Web Services, a sessão 2.3 introduz as Aplicações Sensíveis ao Contexto, a sessão 2.4 apresenta alguns Trabalhos Relacionados ao tema deste trabalho e a análise dos mesmos. 2.1 Sistemas de Informação em Saúde Os Sistemas de Informação (SI) computadorizados são softwares desenvolvidos e utilizados com a finalidade de coleta de dados, processamento, armazenamento e análise destes dados, transformando-os em informação útil para atender as necessidades dos usuários (CAVALCANTE; FERREIRA; SILVA, 2011). De acordo com De Fátima Marin (2010) Sistemas de Informação em Saúde abrangem um conjunto de SI focados em cuidados de saúde e administração dos locais que prestam serviços em saúde. Para Daniel (2013) as informações produzidas pelos SIS necessitam de qualidade e relevância para influenciar de forma positiva os serviços de saúde. Espera-se que (CAVALCANTE; FERREIRA; SILVA, 2011): os SIS estejam estruturados de tal forma que propicie um correto manuseio das informações relativas ao paciente, seus procedimentos e a prescrição dos medicamentos, que as informações geradas pelos SIS estejam coerentes de modo à realmente contribuírem nos processos de trabalho e administrativos das organizações, focando os cuidados de saúde Padrões de informação em saúde Modelos de informação em saúde existem em todo sistema computacional usado em saúde. Enquanto médicos, enfermeiras e outros profissionais desta área compartilham vários conceitos clínicos e conseguem se comunicar com eficiência sobre estes conceitos, computadores não tem um padrão universal de representação de informação clínica (OpenEHR, 2013). De acordo com Gonçalves (2010) os três principais padrões de armazenamento e transmissão de dados médicos são:

21 20 Digital Imaging and Communications in Medicine (DICOM) é um padrão para armazenamento, impressão, transmissão e manuseio de imagens médicas (NUNES, 2010), (BIDGOOD et al, 1997). Tal modelo foi adotado como padrão da indústria americana, europeia e japonesa para transferência de imagens, no Brasil existem uma quantidade crescente de equipamentos que suportam DICOM (GUIMARÃES, 2002); Health Level Seven (HL7) é o mais utilizado padrão para armazenamento e transporte de informações médicas no cenário internacional (DE FARIA LEÃO; DA COSTA; FORMAN, 2007), suportando comunicação para troca de informações e imagens entre sistemas baseados no modelo DICOM, ou seja, podese utilizar mensagens HL7 para enviar dados DICOM. Este padrão possui uma Application Programming Interface (API) open-source, a ferramenta HL7 Application Programming Interface (HAPI) que possui um conjunto de classes e interfaces Java que auxiliam no desenvolvimento de aplicativos que dão suporte a mensagens HL7 (GONÇALVES, 2010) e O OpenEHR se fundamenta na modelagem de dois níveis proposta por Thomas Beale, a qual propõe a separação do nível de informação do nível de conhecimento. O nível de informação inclui as classes de objetos e os esquemas de dados e o nível de conhecimento (arquétipos) inclui os conceitos específicos de domínio, baseados em terminologias e ontologias (MORAES et al, 2011). No primeiro nível, também chamado de modelo de referência, é utilizado pelos desenvolvedores para a modelagem de objetos e esquemas de dados, devendo conter apenas conceitos não-voláteis (que variam pouco com o tempo), facilitando a manutenção do sistema. Já no segundo nível, chamado de nível de conhecimento, é utilizado pelo especialista de domínio (profissional de saúde) para criar as definições formais do conteúdo clínico, especificando os conceitos voláteis. Os arquétipos visam expressar um conceito através da combinação de informações, gerando expressões computáveis do conteúdo de um domínio, expressas na forma de declarações de restrição estrutural elaborados sobre um modelo de dados de referência (GONÇALVES, 2010). Uma das linguagens mais usadas para codificar arquétipos é a Archetype Definition Language (ADL), a qual se baseia em modelos de restrições de entidades de domínio para dados de um modelo de referência qualquer (MORAES et al, 2011).

22 Tipos de aplicação Dentre os tipos de aplicação em saúde podemos citar o homecare (serviço de assistência domiciliar) que trata dos cuidados de saúde em casa ou em locais que não sejam as instituições de cuidados em saúde (TIOSSI; MARIN, 2004). Para (DA SILVA SANTOS et al, 2009) o objetivo do homecare é a promoção, a manutenção e o reestabelecimento da saúde do paciente e minimizar os efeitos das doenças ou de invalidez. E como exemplo de homecare systems podemos citar De Almeida, Endler e Haeusler (2012) que desenvolvem uma ferramenta de geração de aplicativos móveis que auxiliam no acompanhamento remoto móvel customizável de pacientes. A utilização da computação móvel para acompanhamento remoto de pacientes pode auxiliar no monitoramento, na prevenção e no tratamento, o que se torna especialmente válido para pacientes com algum tipo de dificuldade de deslocamento até a instituição que presta os serviços de cuidados com a saúde (DE ALMEIDA; ENDLER; HAEUSLER, 2012). Outro exemplo de homecare systems é o projeto DIGA GINGA onde desenvolveu-se o DIGA Doctor e o DIGA Saúde que utilizam a TV Digital para acompanhar a saúde do paciente, a partir de sua casa (DA SILVA SANTOS et al, 2009). Outro tipo de aplicação em saúde que está presente nos trabalhos que compõe o presente estudo trata-se do healthcare, que (VICENTINI et al, 2010) chamou de Eletronic Healthcare Systems (EHS). Estes são os sistemas eletrônicos de saúde que visam os cuidados de saúde oferecidos em instituições públicas e privadas (ZHANG et al, 2012), (DANIEL, 2013), (VICENTINI, 2010) e (SYMEY; SANKARANARAYANAN; BINTI SAIT, 2013). Como exemplo destes sistemas podemos citar: a) Prontuário Eletrônico do Paciente (PEP): trata-se de um sistema computadorizado proprietário onde são armazenadas as informações dos pacientes, é a versão eletrônica do prontuário em papel (VICENTINI, 2010); b) Sistemas de Registro Eletrônico de Saúde (S-RES): são sistemas que registram, recuperam e manipulam informações dos Registros Eletrônicos de Saúde (RES) (DE FARIA LEÃO; DA COSTA; FORMAN, 2007), que contém todo o histórico de saúde do paciente, disponível para pessoas autorizadas, sendo o paciente o dono destas informações (VICENTINI, 2010);

23 22 c) Sistema de Gestão Hospitalar (SGH): é um sistema que gerencia a parte administrativa de um hospital, o sistema engloba questões como leitos ocupados, nutrição, almoxarifado, plantonista entre outros, além do PEP ser um de seus módulos (VICENTINI, 2010); d) Registro Pessoal de Saúde: é um sistema para o paciente, onde este insere e gerencia as informações, podendo compartilhá-las com quem desejar (VICENTINI, 2010); e) Sistema para Marcação de Consulta Online: este sistema possibilita marcação de consultas através da internet (ZHANG et al, 2012) e (FIELD et al, 2011); f) Prescrição Eletrônica: sistema que possibilita a prescrição eletrônica de medicamentos (HENRIQUE; NETO, 2012) e g) Automação de Consultórios: sistema que automatiza consultórios médicos (GODOI; FREITAS, 2012). Conforme a descrição dos tipos de aplicação apresentados, este trabalho pode ser classificado como sendo do tipo homecare systems, pois trata-se de uma aplicação que auxilia o paciente onde ele estiver, o que pode ser em casa, no trabalho ou mesmo na rua Prescrição médica De acordo com a Resolução da Diretoria Colegiada (RDC) 2 Nº 67, os itens que devem ser avaliados em uma prescrição médica são: (i) identificação da instituição ou profissional prescritor com número de registro no conselho profissional; (ii) identificação do paciente, endereço ou leito do paciente; (iii) Medicamento: concentração/dosagem, forma farmacêutica, quantidades e respectivas unidades; modo de usar ou posologia; (iv) local e data de emissão; (v) assinatura e identificação do prescritor. (VIGOLO, 2009). Madruga e Souza (2009) determinam os dados essenciais e facultativos de uma prescrição médica. Como dados essenciais definiram: (i) dados de cabeçalho: nome e endereço do profissional, registro profissional, número de cadastro de pessoa física ou 2 RDC Nº 67, DE 8 DE OUTUBRO DE 2007: Dispõe sobre Boas Práticas de Manipulação de Preparações Magistrais e Oficinais para Uso Humano em farmácias. Disponível em:

24 23 jurídica, podendo contar a especialidade do profissional desde que registrada no Conselho Regional de Medicina (CRM); (ii) superinscrição: nome, endereço e idade (se relevante). (iii) inscrição: nome do fármaco, forma farmacêutica e concentração; (iv) subinscrição: quantidade total a ser fornecida; (v) adscrição: orientações do profissional para o paciente. E como dados facultativos, ressaltam: peso, altura, dosagens específicas, orientações de repouso, dieta, possíveis reações adversas entre outras informações relevantes ao tratamento. (MADRUGA; SOUZA, 2009). Leal descreve as informações mínimas contidas em uma prescrição de medicação de uso endovenoso, oral, tópico e parenteral: a) Endovenoso: nome do medicamento, concentração, forma farmacêutica, dose, diluente, volume, via, velocidade de infusão, posologia, orientações para administração e uso; b) Oral: nome do medicamento, concentração, forma farmacêutica, dose, posologia, via, orientações de uso; c) Tópico: nome do medicamento, concentração, forma farmacêutica, posologia, via, orientações de uso e d) Parenteral: nome do medicamento, concentração, forma farmacêutica, dose, diluente, volume, via, posologia, orientações de administração e uso. 2.2 Computação distribuída e Web Services Aplicações distribuídas consistem em computadores independentes que cooperam via rede simulando uma máquina local (SILVA, D; LOVATTI, 2009). Este tipo de sistema geralmente surge da necessidade de melhorar a capacidade e confiabilidade de uma máquina a fim de atender maiores demandas (PINTO, 2011). Algumas vantagens de seu uso são: melhoria de desempenho, escalabilidade, conectividade, segurança, confiabilidade, tolerância a falhas e transparência. Porém, para um sistema proporcionar todas estas vantagens citadas anteriormente deve ser desenvolvido com base em algum modelo de computação distribuída, como exemplo desses modelos podemos citar: Remote Procedure Call (RPC), Remote Method Invocation (RMI), Peer-to-Peer (P2P), Common Object Request Broker Architecture (CORBA), Grid, Cluster e Web Services (SILVA, D; LOVATTI, 2009).

25 24 Algumas caraterísticas diferem os Web Services de outros modelos de computação distribuída, Kalin (2010) ressalta a infraestrutura aberta, a transparência de linguagem e o design modular. Infraestrutura aberta consiste do uso de protocolos-padrão como HyperText Markup Language (HTML) e extensible Markup Language (XML), que são onipresentes e bem compreendidos. A transparência de linguagem representa a capacidade dos serviços e seus clientes interoperarem independentemente da linguagem de programação na qual foram escritos. O design modular permite que novos serviços sejam criados a partir da integração de serviços existentes (KALIN, 2010). Os Web Services têm se mostrado uma solução promissora na integração de sistemas e na comunicação entre aplicações heterogêneas (BIGOLIN, 2012), pois fornecem independência de plataforma ou linguagem (MARCELO, 2013) facilitando a interoperabilidade de aplicações. Um Serviço Web nada mais é do que um serviço normal que é ofertado pela Web, o que o torna diferenciado é que ele obedece a um conjunto de regras os quais permitem que seja descoberto e acessado por aplicações clientes que também seguem tais padrões (TANENBAUM; WOODHULL, 2008). A arquitetura dos Web Services permite construir aplicações modulares e independentes (SILVA, R; CUNHA, 2007) baseadas no conhecimento mais maduro dos ambientes de computação distribuída, permitem a comunicação direta e a interoperabilidade entre plataformas, sistemas e linguagens (PINTO, 2011). Kalin (2010) afirma que os Web Services podem ser divididos em dois grupos: os de estilo Respresentational State Transfer (REST) e os baseados em Simple Object Access Protocol (SOAP) ou WS-*, os quais não são exatamente distintos devido ao fato dos serviços SOAP fornecidos através de HTTP serem um caso especial dos serviços de estilo REST. As definições de REST e SOAP podem ser entendidas como segue (PINTO, 2011) e (KALIN, 2010) Estilos Arquiteturais e Middleware Os sistemas distribuídos podem ser construídos através de diversos estilos arquiteturais. Tobaldini (2012) divide os estilos arquitetônicos em 7 categorias de acordo com as peculiaridades comuns de cada um, das quais podemos destacar:

26 25 a) Cache: estilo que replica informações, armazenando respostas às requisições realizadas para utilizá-las como resposta a novas requisições semelhantes; b) Cliente-Servidor: estilo composto por um servidor e vários clientes. O servidor disponibiliza serviços sob demanda a requisições de clientes; c) Cliente-Servidor sem Estado: possibilita a comunicação entre cliente e servidor sem que o servidor tenha que conhecer o estado do cliente, conhecida como stateless, o que faz com que qualquer requisição realizada ao servidor tenha que conter todas as informações para a requisição ser processada pelo servidor. Algumas vantagens desse estilo são visibilidade, confiabilidade e escalabilidade, e como desvantagem podemos destacar o alto tráfego de dados na rede devido a condição stateless o que prejudica a performance da aplicação; d) Cliente com Cache-Servidor sem Estado: é a combinação dos estilos Cliente- Servidor sem Estado e Cache. Este estilo possibilita diminuir o número de interações cliente servidor, o que gera escalabilidade e aumento de performance da aplicação, porém diminui a confiabilidade e e) Sistemas em Camadas: divisão da arquitetura em níveis hierárquicos, cada nível só pode interagir e conhecer o nível anterior e o próximo. Este estilo é utilizado para encapsular e proteger os serviços de cada cliente, aperfeiçoar a escalabilidade das aplicações e aplicar políticas de segurança (TOBALDINI, 2012). Em um sistema dividido em camadas, cada camada utiliza os serviços disponibilizados pela camada anterior. De acordo com Coulouris et al (2013) um dos desafios atuais da computação distribuída é a possibilidade da execução de aplicações em conjuntos heterogêneos de computadores e redes. Um middleware tem por objetivo fornecer abstração de programação, mascarar a heterogeneidade das redes, dos sistemas operacionais, das linguagens de programação e do hardware. No caso de sistemas distribuídos que operam via rede o middleware mascara o fato das mensagens passarem por diferentes redes (COULOURIS, 2013) WS De acordo com Kalin (2010) o termo Web Service tem muitos significados, o mesmo autor define um Web Service como um tipo de aplicação distribuída no qual seus

27 26 componentes podem ser aplicados e executados em dispositivos distintos. O World Wide Web Consortium (W3C) caracteriza os Web Services pela sua interoperabilidade e extensibilidade e ressaltam que os mesmos podem ser combinados alcançar operações complexas, permitindo que serviços simples interajam entre si formando serviços sofisticados de alto valor agregado (W3C, 2014). Os WS foram apresentados pela Microsoft em 2000 e a partir de 2002 os Web Services começaram destacar-se entre as tecnologias distribuídas (QUINTÃ, 2008). Atualmente, os sistemas de software são escritos em várias linguagens e armazenados em várias plataformas, sendo raro um sistema atuar sem necessidade de comunicação. Além disso, muitas instituições possuem softwares antigos que fornecem serviços essenciais e não possuem disponibilidade ou recursos para desenvolver softwares integrados aos sistemas atuais. Nestes casos, o uso dos Web Services torna-se uma boa solução devido ao fato dos mesmos promoverem interoperabilidade de linguagem e plataforma (Kalin, 2010) SOAP Coulouris (2013) afirma que o protocolo SOAP especifica regras de uso da XML para encapsular mensagens e envia-las por algum protocolo (por exemplo HTTP), este protocolo foi projetado para prover uma forma simplificada de permitir que dois sistemas diferentes, sem conhecimento um do outro, consigam se comunicar. Devido a este fato, uma grande parte das mensagens SOAP são baseadas em XML (TANEMBAUM, 2007). O XML é uma linguagem de marcação extensível, devido a este fato muitas informações são expressadas neste formato (SAUDATE, 2013). Por ser extensível e uma linguagem de metamarcação proporciona flexibilidade quanto a aparência dos arquivos. Pode referenciar arquivos a serem incluídos para completar determinado arquivo (TANEMBAUM, 2007). Também possui seções específicas de instruções para seus processadores de XML, além disso, sua estrutura básica possui tags e atributos (SAUDATE, 2013). A Figura 1 apresenta um exemplo de XML:

28 27 Figura 1: Exemplo de código XML. Como pode visto a Figura 1 corresponde a uma lista de sucos, onde a tag <sucos> representa a lista propriamente dita, a tag <suco> denota cada suco individualmente, a tag <nome> indica o nome do suco e a tag <ingredientes> apresenta os ingredientes de cada suco. Os serviços baseados em SOAP utilizam a linguagem Web Service Description Language (WSDL) para a descrição do serviço (BIGOLIN, 2012), a qual permite aos clientes obterem informações como os nomes das operações do WS e os tipos de dados envolvidos nas mesmas (KALIN, 2010), WSDL será explicado com mais detalhes na seção O Universal Description, Discovery and Integration (UDDI) é um componente importante dos Web Services e pode ser descrito como um serviço de diretórios que contém descrições de serviços, permitindo que os clientes busquem por serviços de seu interesse. (TANEMBAUM, 2007) De acordo com Kalin (2010) nos WS baseados em SOAP, o SOAP é a infraestrutura menos vista, considerando que atualmente o SOAP é apenas um dialeto XML, o qual é utilizado no envio das mensagens SOAP (PINTO, 2011). Uma mensagem SOAP é composta por três elementos XML o envelope, o cabeçalho e o corpo, sendo que o corpo e o cabeçalho situam-se dentro do envelope e contém elementos internos (COULOURIS, 2013). A estrutura da mensagem pode ser vista na Figura 2:

29 28 Figura 2: Estrutura da mensagem SOAP. Fonte: Adaptado de Kalin (2010). O cabeçalho contém informações relevantes para o trajeto da mensagem entre o remetente e o destinatário, enquanto o corpo contém a mensagem em si. O envelope SOAP não carrega informações a respeito de seu destinatário, deixando a cargo do protocolo usado para o transporte da mensagem a entrega da mesma no local correto (TANEMBAUM, 2007) WSDL A interoperabilidade entre as aplicações é realizada através da troca de mensagens, funcionalidade que é documentada pelo Web Service Description (WSD) onde são descritos o formato da mensagem, o tipo de dados, o protocolo e o formato de transporte para comunicação entre as máquinas. O WSD é a especificação da interface do Web Service, escrita em WSDL (MARCELO, 2013). O WSDL é a linguagem utilizada na descrição de Web Services baseados em SOAP, que contém a descrição das informações utilizadas para chamar os Web Services, como localização, operações disponíveis e assinatura de suas funções (SILVA, D; LOVATTI, 2009). Sua estrutura é composta com um XML com os seguintes elementos definições, tipos, mensagens, interface, vínculos e serviço (COULOURIS, 2013) que podem ser compreendidos como segue.

30 29 a) <definitions>: o elemento definições é o elemento raiz de todo documento WSDL; b) <types>: o elemento tipos define os tipos de dados utilizados; c) <message>: o elemento mensagens especifica as mensagens que implementam o serviço com base nos tipos definidos no elemento tipos; d) <porttype>: o elemento interface apresenta o serviço abstratamente através de operações nomeadas; e) <binding>: o elemento vínculos especifica detalhes de implementação dos serviços apresentados pelo elemento interface e f) <service>: o elemento serviço lista os elementos interface juntamente com os elementos vínculos correspondentes (KALIN, 2010) e (SILVA DE SOUZA; PIRES, 2005) REST REST é um estilo de arquitetura para desenvolvimento de aplicações em rede (ELKSTEIN, 2013). Este estilo arquitetônico foi desenvolvido com o intuito de possibilitar facilmente o desenvolvimento de aplicações web, pois para o desenvolvimento de serviços web baseados em SOAP é necessário o conhecimento de uma grande quantidade de padrões (FELLER, 2010). Este estilo arquitetural foi proposto por Roy Fielding em sua tese de doutorado, Fielding também foi um dos autores da especificação HyperText Transfer Protocol (HTTP). Desta forma não é surpreendente que o estilo REST tenha bases sólidas no HTTP, o qual é um dos protocolos mais utilizados do mundo (SAUDATE, 2013). REST usa o protocolo HTTP para troca de mensagens, sendo assim, usa requisições HTTP para manipular informações (ELKSTEIN, 2013). Um conceito importante em REST é o recurso. Recursos são coleções de dados que são passadas pelo Universal Resouce Identifier (URI), sendo representados pelos URIs (SAUDATE, 2013). Como exemplo poderíamos citar o exemplo de uma listagem de livros de uma biblioteca, de forma que a consulta a lista de livros é um recurso representado pela URI: De acordo com Saudate (2013) podemos dividir a URI em:

31 30 a) esta parte representa o protocolo que está sendo usado, no caso o HTTP. Pode ser compreendido como protocolousado://; b) localhost:8080: esta parte representa o servidor de rede e a porta que estão sendo usados, no caso o servidor de rede local e a porta Pode ser compreendido como servidorderede:porta; c) /biblioteca: representa o contexto da aplicação, ou seja, a raiz que fornece a aplicação para o cliente. Pode ser compreendida como /contextodaaplicação e d) /livros: representa o recurso em sí e é denominada endereço do recurso. Pode ser compreendida como /endereçodorecurso. A partir da explanação a respeito dos recursos, podemos determinar a estrutura genérica de um recurso: protocolousado://servidorderede:porta/contextodaaplicação/endereçodorecurso Os recursos podem ser compreendidos como uma forma de interagir com determinados dados através de métodos HTTP. Na versão atual do HTTP são definidos nove métodos (SAUDATE, 2013), Bigolin (2012) destaca os quatro métodos associados com as operações básicas dos bancos de dados relacionais como pode ser visto no Quadro 1. Quadro 1 - Relação entre os métodos HTTP e as operações em bancos de dados relacionais. Método HTTP Operação no banco de dados GET Consulta POST Inserção PUT Atualização DELETE Deleção Fonte: Autoria Própria. Para o desenvolvimento de serviços REST deve-se estruturar os sistemas em função dos recursos, de modo a todas as operações a serem disponibilizadas poderem ser acessadas pelos métodos HTTP. Uma aplicação baseada em REST se comportará como uma rede de websites (um estado virtual) de forma que o usuário seleciona links (transições de estado) tendo como resultado a próxima página (outro estado da aplicação) a qual é transferida para o usuário e adaptada para seu uso (PINTO, 2011).

32 31 REST é uma alternativa de menor complexidade para os Web Services baseados em SOAP e RPC (ELKSTEIN, 2013) que utiliza um conjunto de interfaces genéricas para promover interações sem estado (stateless) através da transferência de representação dos recursos e não opera diretamente sobre os mesmos. Entre as restrições definidas pelo REST, destacamos: a) Identificação global: Todos os recursos são identificados através de um mecanismo global, no caso uma Uniform Resource Locator (URL); b) Interfaces uniformes: A interação entre os agentes é feita com recursos do protocolo HTTP, utilizando um conjunto de métodos pré-definidos; c) Interações Stateless: O servidor conhece o estado de seus recursos, mas não mantém informações sobre as sessões dos clientes (PINTO, 2011) e d) Separação de capas: os pedidos podem ser transmitidos por quaisquer conectores, porém os mesmos não têm conhecimento sobre seu conteúdo. A aplicação deve compreender a representação do recurso (geralmente um documento XML ou HTML), conhecer seu identificador e a ação requerida. Um dos desafios do REST é sua condição stateless a qual pode gerar uma necessidade de a cada requisição que o servidor receber informações repetidas, aumentando a troca de dados através da rede e podendo diminuir a performance da aplicação. Além disso, o armazenamento do estado apenas no cliente pode gerar dificuldade no servidor em controlar se uma determinada versão do cliente está se comportando de maneira correta ou não (TOBALDINI, 2007), o que pode gerar falhas de segurança e desempenho. 2.3 Aplicações sensíveis ao contexto Em ambientes computacionais a sensibilidade ao contexto representa a capacidade do sistema de adequar seu funcionamento de acordo com informações de seu ambiente, visando fornecer serviços mais adequados aos usuários e aplicações que interagem com este ambiente (MARAN; PALAZZO, 2014). A partir deste aspecto surge como tendência aplicações mais amigáveis, flexíveis e com melhor usabilidade (VENECIAN, 2010). A computação sensível ao contexto é caracterizada por aplicações ou arquiteturas com a capacidade de se adaptarem e particularizarem sua execução com base nas informações de

33 32 contexto. Vieira (2009) afirma que a definição de contexto ainda não é um consenso entre os pesquisadores, frisando que existem várias definições para o conceito de contexto. O conceito de contexto foi inicialmente definido como qualquer informação relevante sobre entidades para a interação usuário-aplicação, atuando como restrições que influenciam o comportamento de um sistema (MARAN; PALAZZO, 2014). Este conceito foi definido de diferentes formas para diferentes áreas da computação, por exemplo, Brézillon definiu este conceito na área de Inteligência Artificial como algo que delimita a solução de um problema sem causar interferências explícitas. Chen (2002) definiu contexto como um conjunto de estados e peculiaridades de um ambiente no qual um evento relevante de uma aplicação ocorre ou que define a conduta de uma aplicação (Vieira, 2009). De acordo com Maran e Palazzo (2014) atualmente contexto é definido como o conhecimento resultante obtido do fluxo de atividades de sistemas sensíveis ao contexto, independente de interações e adaptando-se de forma imperceptível ao usuário. Segundo Venecian (2010) as informações contextuais podem ser caracterizadas através de alguns pontos cruciais como segue: a) Características temporais: as informações contextuais podem ser qualificadas como dinâmicas ou estáticas. Informações dinâmicas são dados que variam constantemente, como a localização de um usuário ou o nível de luminosidade em sua volta. Informações estáticas especificam aspectos invariáveis do sistema, como o número do CPF 3 de uma pessoa; b) Imperfeição: a informação contextual pode estar incorreta caso não demonstre corretamente as condições do ambiente modelado, inconsistente se apresentar informação controversa ou incompleta se o contexto não for identificado sobre alguns aspectos. Informações imperfeitas podem advir de sensores, algoritmos de abstração e dos próprios usuários. Além de falhas de comunicação e interferências, outras falhas podem gerar informações imperfeitas e c) Representações Alternativas: devido à grande parte das informações de contexto chegarem às aplicações através de sensores e estes possuem um nível de abstração menor que a informação pretendida, as aplicações abstraem a informação recebida de diferentes sensores de acordo com seu interesse o que resulta em informações 3 Cadastro de Pessoa Física

34 33 diferentes de acordo com sua finalidade. Por exemplo um sensor envia a informação de latitude e longitude e outro envia a informação de nível de ruído, a partir destas informações a aplicação pode determinar se a pessoa está na sala de sua casa ou em sua sala na empresa em que trabalha, ou seja, o mesmo contexto pode ser representado de diversas formas em diversos momentos da aplicação. A computação sensível ao contexto interfere diretamente em algumas operações dos sistemas, dentre elas podemos destacar: (i) descrição do estado atual do ambiente, a qual geralmente é composta por informações recebidas por sensores e agregadas para formar informações de alto nível, (ii) dados do domínio, (iii) descoberta de recursos, o sistema necessitando de determinado recurso pode utilizá-los de acordo com as informações de contexto dos mesmos, (iv) ações dos sistemas, as informações de contexto são utilizadas como disparador para determinadas ações, (v) modificação de serviços, as informações de contexto podem servir como parâmetros para determinados serviços (MARAN; PALAZZO, 2014) Aquisição de contexto Para Loureiro et al (2009) o objetivo da computação sensível ao contexto é a aquisição de dados de forma que os mesmos possam refletir as condições do usuário e do ambiente em que o dispositivo está inserido, considerando as características específicas do mesmo. Os autores ainda destacam que cada tipo de dados possui desafios específicos com relação a aquisição de contexto. A aquisição de dados de contexto trata da forma como os dados são obtidos, podendo ser sentida, derivada ou explicitamente provida. A aquisição sentida obtém as informações a partir de sensores, por exemplo: localização, temperatura, nível de ruído e nível de luminosidade. A aquisição derivada adquire informações durante a execução da aplicação, como a idade de um usuário, que pode ser calculada a partir da data de nascimento. A aquisição provida é quando os dados são fornecidos explicitamente à aplicação, como os dados obtidos por um formulário (VENCIAN, 2010). No presente trabalho serão utilizadas as três formas de aquisição de contexto.

35 Modelos de representação de contexto De acordo com (MARAN; PALAZZO, 2014) e (VENCIAN, 2010), as informações de contexto podem ser representadas de diversas formas, dentre elas podemos destacar o modelo chave-valor, os esquemas de marcação, os modelos gráficos, os modelos orientados a objetos, os modelos baseados em lógica e os modelos baseados em ontologias. Os quais são descritos na sequência: a) O modelo chave-valor é um modelo que trabalha com atributos e valores, sendo a mais simples representação de contexto. Composto por conjuntos de pares chavevalor é fácil de gerenciar e eficiente em consultas, porém, com pouca capacidade de expressão em estruturas complexas de dados e contextos; b) Os esquemas de marcação utilizam tags para marcação de estruturas hierárquicas, as quais definem a estrutura do dado. Este modelo tem sido utilizado para transmissão de informações e armazenamento temporário de dados em sistemas ubíquos, sendo mais estruturado e flexível que o modelo chave-valor, entretanto, é dependente da aplicação (devido à falta de padrões para a representação estrutural do contexto) e não apresenta facilidades na recuperação de informações em estruturas complexas; c) Os modelos gráficos são fundamentados em notações gráficas, sendo, na maioria das vezes, derivados de adaptações ou extensões de Unified Modeling Language (UML), Object Role Modeling (ORM) e Context Modeling Language (CML). Este modelo é de fácil entendimento e possibilita o uso de outras linguagens na representação do nível mais baixo dos diagramas; d) Os modelos orientados a objeto são fundamentados no paradigma de programação orientado a objetos, podendo ser implementados diretamente na linguagem do sistema ou através da utilização de modelos gráficos traduzidos para uma linguagem deste paradigma. Tendem a ser fortemente acoplados às linguagens de programação, dificultando o compartilhamento das informações de contexto entre módulos de sistemas interoperáveis, porém, fornecem reutilização de modelagens e encapsulamento de informação; e) Nos modelos baseados em lógica o contexto é definido em forma de expressões ou fatos a partir de um conjunto de outros fatos ou expressões, gerando a necessidade

36 35 de uma linguagem de representação formal. Tais modelos permitem melhor representação do contexto, porém, dificultam a inferência do mesmo. São utilizadas juntamente com outros modelos, destacando-se as ontologias de formato OWL-DL e f) Os modelos baseados em ontologias representam as informações de contexto através de uma especificação formal e explícita de um conjunto de conceitos de forma compartilhada denominada ontologia por Borst (1997). Têm sido propostas inúmeras ontologias para a representação de contextos, dentre elas podemos destacar a Context Ontology Language (CoOL), a qual é utilizada largamente em sistemas ubíquos. Uma comparação dos modelos de representação de contexto foi elaborada por Strang e Popien (2004), concluindo que os modelos baseados em ontologias e os modelos orientados a objeto são os que atendem de maneira mais satisfatória os requisitos apresentados pelos autores. Outra comparação ente modelos de representação de contexto em relação aos requisitos necessários para modelagem de contexto e sistemas de gerenciamento de contexto foi elaborada por Bettini et al (2010). Os requisitos estão citados abaixo: a) Heterogeneidade e Mobilidade: modelar e tratar as fontes móveis e heterogêneas de dados; b) Relacionamentos e Dependências: relacionamentos e dependência dos elementos de contexto; c) Sem restrição de tempo: consulta de informações já coletadas e das previsões das informações de contexto; d) Imperfeição: capacidade de representar as informações de forma a evitar contextos incompletos, ambíguos ou conflitantes; e) Inferência: capacidade de adaptação do sistema baseado nas informações de contexto e f) Usabilidade no formalismo de modelagem: ferramentas e metodologias de apoio aos projetistas na construção de modelos de contexto. Eficiência no acesso ao contexto: característica essencial para superar as dificuldades da

37 36 grande quantidade de informação gerada e a complexidade na representação dessas informações. Quadro 2 - Comparativo entre formas de representação de contexto. Modelo/Requisito Modelo Orientado a Objetos Modelo Espacial Modelo Ontológico Heterogeneidade Satisfatório Parcial Satisfatório Mobilidade Parcial Satisfatório Insatisfatório Relacionamentos Parcial Parcial Satisfatório Sem restrição de tempo Satisfatório Satisfatório Insatisfatório Imperfeição Parcial Parcial Insatisfatório Inferência Parcial Insatisfatório Satisfatório Usabilidade Satisfatório Parcial Parcial Inferência Parcial Satisfatório Insatisfatório Fonte: Adaptada de Maran e Palazzo (2014). O Quadro 2 analisa o modelo orientado a objetos, o modelo espacial e o modelo ontológico sob a ótica das características propostas por Bettini et al (2010). Como podemos observar o modelo orientado a objetos é único modelo que, mesmo sendo de forma parcial, atende minimamente os requisitos necessários para modelagem de contextos e sistemas de gerenciamento de contexto. 2.4 Trabalhos relacionados No artigo Desenvolvendo um Sistema Online de Agendamento de Consultas Baseado em Arquitetura de Web Service (ZHANG et al, 2012), os autores visaram desenvolver uma aplicação em três camadas que pode ser vista na Figura 3. Tal aplicação permite a comunicação e a troca de informações do Sistema de Agendamento de Consultas com os Sistemas de Informação Clinica (SIC) existentes ou ser escalável para integrar qualquer SIC futuramente desenvolvido.

38 37 Figura 3. Arquitetura do Sistema Online de Agendamento de Consultas baseado em Web Services. Fonte: Zhang et al (2012). A solução foi criada a partir das tecnologias SOAP, WSDL e UDDI. Como resultado todo sistema capaz de analisar texto e se comunicar pelos protocolos padrões de internet (HTTP, Simple Mail Transfer Protocol (SMTP) ou XML) pode se comunicar com o Web Service. Gonçalves (2010) implementa um protótipo de Prontuário Eletrônico do Paciente e um serviço de consulta às informações do paciente, para a integração de aplicações externas utilizando o padrão de armazenamento e transmissão de dados médicos HL7.

39 38 O Sistema PEP consiste em: uma base de dados (PEP-BD) modelada com base no conjunto de informações selecionado para o PEP, uma aplicação web (PEP-WEB) que realiza inserção edição e visualização dos dados do PEP, e um serviço de troca de mensagens do padrão HL7, o qual possibilita consulta de uma aplicação externa às informações do prontuário do paciente através da internet. A Figura 4 demonstra a visão geral do Sistema PEP. Figura 4. Visão geral do sistema PEP. Fonte: Gonçalves (2010). Para o banco de dados foi usado o Sistema de Gerenciamento de Banco de Dados (SGBD) PostgreSQL, a PEP-WEB foi desenvolvida usando JavaEE, rodando em um servidor de aplicação JBoss e utilizando o framework Seam, o qual agrega padrões consagrados como JavaServer Faces (JSF), Enterprise JavaBeans (EJB) e Java Persistence API (JPA). Soto, Pabllo e Campos (2008) propõem o Sistema Móvel para Administração de Medicamentos (SisMAM) uma aplicação móvel que visa administrar os medicamentos dos pacientes no local que o paciente se encontra no momento da administração do medicamento. Este trabalho desenvolve uma ontologia para os diferentes tipos de medicamentos no seu processo de administração e cria componentes para a interface com o usuário. Para o desenvolvimento da aplicação utilizou-se uma arquitetura genérica de aplicações móveis que compreende as camadas de Interação Humano-Computador (IHC), que define os elementos da relação usuário-aplicação, aplicação móvel, que representa a aplicação executada no dispositivo móvel, Middleware de Integração, usada como meio de interligar a

40 39 aplicação e o sistema de informação hospitalar, e a quarta camada é o Sistema de Informação Hospitalar, que compreende as camadas de software do SI disponível no hospital. Em (FERREIRA et al, 2013) os autores apresentam um assistente de medicação que tem por propósito auxiliar os idosos na administração de medicamentos diária. A não-adesão dos medicamentos por parte deste público se tornou um problema, trazendo a importância do desenvolvimento de estratégias e aplicações que contribuam para a adesão. A aplicação móvel traz além dos lembretes, informações a respeito do uso da medicação e procedimentos em caso de esquecimento dos remédios. Figura 5. Arquitetura do Assistente de Medicação. Fonte: Ferreira et al (2013). Alcançando o público idoso através de fala, toque, elementos gráficos e sensibilidade ao contexto, tal aplicação é dividida em vários módulos e visões, como pode ser visualizado na Figura 5. Dentre eles podemos destacar quatro gerentes (gerente de visão, gerente de usuário, gerente de alarme, gerente de voz e gerente de usuário) e quatro serviços: serviço de usuário, serviço de fala, serviço de imagem e Gerador de Linguagem Natural (GLN). Vicente (2012) apresenta um aplicativo de gestão de medicamentos em dispositivos moveis o Mobile Medicine, desenvolvido a partir dos frameworks Phonegap e jquery Mobile, e informações da base de dados da INFARMED para o banco de dados de medicamentos, sua arquitetura pode ser vista na Figura 6.

41 40 O uso do sistema é restrito a um usuário por dispositivo, sendo permitido criar ou não um perfil, e podendo definir um contato de emergência entre os contatos de seu dispositivo. A pesquisa de medicamentos é realizada de duas formas: pelo nome ou código de barras do medicamento, o qual pode ser digitado ou lido pelo leitor embutido no programa através da câmera digital. Após a pesquisa é possível adicionar medicamentos as prescrições e definir lembretes para tomá-los. As informações sobre princípios ativos dos medicamentos são exibidas em um navegador que busca as informações na versão portuguesa da Wikipédia. Na seção prescrições são exibidas e inseridas prescrições, podendo também verificar o princípio ativo dos medicamentos, a data de início da prescrição e os lembretes, os lembretes podem ser alterados e removidos. Terminar prescrição remove-a deste e a insere no histórico, que pode ser visualizado nesta seção. Figura 6: Arquitetura do Aplicativo Mobile Medicine. Fonte: Vicente (2012). Lopez e Cardoso (2012) apresentam uma proposta de sistema móvel, que através da realidade aumentada auxilia deficientes auditivos e profissionais de saúde na preparação e administração de medicamentos. Tal sistema se compõe em dois módulos, o HelpMed e o TranningMed. O módulo TranningMed objetiva auxiliar no treinamento de profissionais de enfermermagem, o qual ainda não foi implementado. O Módulo HelpMed está sendo desenvolvido utilizando o SDK Vuforia e a IDE Eclipse, este módulo visa auxiliar os deficientes auditivos através de informações de texto e vídeo propiciando que os mesmos administrem e/ou preparem os medicamentos de forma correta. Através dos vídeos, mostra informações dos medicamentos solicitados usando a linguagem de libras.

42 41 O sistema web Seu Remédio oferece lembretes de medicamento por Short Message Service (SMS) na hora, data e frequência previamente escolhidas pelo paciente. Através de um cadastro simples, o paciente pode cadastrar no sistema o nome do medicamento, a frequência com que será tomado, o horário de cada dose, a data de início e fim do tratamento, permitindo a inclusão de uma mensagem que será enviada junto com o lembrete da medicação (SEU REMÉDIO, 2014). O aplicativo móvel MediSafe (2014) objetiva integrar comportamentos mais saudáveis a vida diária das pessoas em geral, através de um sistema móvel de gestão de medicamentos que utiliza serviços em nuvem. Utilizando um banco de dados sincronizado na nuvem e podendo ser utilizado em plataforma Android e ios, a aplicação provê maior aderência ao tratamento por pacientes. Oferece um serviço de administração de medicamentos, lembrando o paciente da toma por SMS, ligação ou . Também é disponibilizada uma aplicação de suporte para família, a qual é avisada quando o paciente não toma os medicamentos de forma correta, levando em conta que o paciente informa o aplicativo quando toma os medicamentos. O relatório de toma de medicamento pode ser enviado para o médico em formato de planilha. Lobo (2013) apresenta o Personal Medication Advisor, um assessor pessoal de medicação capaz de interagir em tempo-real com o usuário através de recursos de fala, imagens e texto. O qual auxilia na administração de medicamentos através de informações de: dosagem, frequência, posologia, via, objetivos, restrições e reações adversas do medicamento. Também notifica sobre as medicações prescritas pelo médico, podendo executar um questionário a respeito do estado de saúde do paciente e enviá-lo ao profissional de saúde responsável pelo paciente-usuário através de ou mensagem. Tal projeto foi desenvolvido usando Android Software Development Kit (SDK), Google Voice para reconhecimento de fala, ispeech para sintetização de voz e para representar o conhecimento utiliza ontologias através da Jena API e da ferramenta Protégé. O Personal Medication Advisor é dividido em cinco módulos: o reconhecedor, o analisador de linguagem, o gerenciador de diálogos, o gerador de linguagem e o sintetizador. Schreier et al (2013) desenvolveu um sistema de administração de medicamentos multimodal que utiliza duas tecnologias de aquisição de dados de curto alcance em smartphones contemporâneos, o Near Field Communication (NFC) para ler etiquetas de Radio-Frequency IDentification (RFID) e as câmeras do telefone para escanear códigos de barra. A administração de medicamentos é feita a partir de um software baseado em android

43 42 que foi desenvolvido para rodar em qualquer smartphone capacitado a rodar uma ferramenta NFC. As informações da administração do medicamento são inseridas pelo paciente na primeira leitura do RFID, sendo guardada em um banco de dados SQLite no próprio dispositivo Análise Através dos dados apresentados no Quadro 3 podemos analisar os trabalhos que abordam diretamente a administração de medicamentos. Nota-se prevalência da plataforma móvel e dos pacientes como público-alvo. Também podemos ressaltar que nenhum dos trabalhos citados usa algum padrão de informação em saúde, reduzindo a possibilidade de interoperabilidade futura com outros sistemas. Quadro 3 Comparativo tecnológico entre os trabalhos relacionados. Trabalho / Plataforma Público Alvo Representação Tecnologia de Sensibilidade ao Tecnologia de Informação desenvolvimento Contexto 1 Móvel Paciente e cuidador/ familiar - - Não 2 Móvel Paciente e Tabelas Microsoft Speach Sim cuidador Plataform, MOSES 1, GIZA++ 2, SRILM3 tools. 3 Móvel Paciente XML Phonegap e jquery Mobile Não 4 Móvel Deficientes auditivos e profissionais de saúde Tabelas SDK AR Vuforia Não 5 Web Paciente - - Não 6 Móvel Paciente Ontologias Android SDK, Google Voice, ispeech, Jena API, Protégé Não

44 43 7 Móvel Paciente Tabelas NFC, SQLite Não 1 - (MEDISAFE, 2014); 2 - (FERREIRA et al, 2013); 3 - (VICENTE, 2012); 4 - (LOPES; CARDOSO, 2012); 5 (SEUREMÉDIO, 2014); 6 - (LOBO, 2013) e 7 - (SCHREIER, 2013). Também é importante salientar que dos trabalhos que desenvolveram lembretes dos medicamentos (SEU REMÉDIO, 2014), (MEDISAFE, 2014), (VICENTE, 2012), (FERREIRA, 2013) e (SCHREIER, 2013) nenhum deles apresenta ligação com qualquer sistema utilizado pelos profissionais de saúde, deixando a cargo do paciente a entrada de dados do modo de uso pretendido dos medicamentos. Apesar de não ter comunicação com outros softwares, Ferreira (2013) deixa claro que os usuários não devem realizar a entrada de dados, porém não propõe uma solução. O Personal Medication Advisor (LOBO, 2013) se comunica através de Web Services com um sistema de clínica médica, porém, não implementa lembretes.

45 44 3 PROJETO E CENÁRIO Este capítulo visa explanar sobre o projeto no qual este trabalho está inserido. Na seção 3.1 há uma descrição da motivação e do objetivo do projeto. A seção 3.2 detalha a arquitetura do projeto, seus módulos e a interação entre os mesmos. Na seção 3.4 são apresentados dois cenários hipotéticos de funcionamento do sistema proposto pela arquitetura. 3.1 Arquitetura AMESC A arquitetura proposta é composta de três módulos interoperáveis: o módulo móvel, o módulo de controle e o módulo web. Como pode ser visto na Figura 7 o módulo web promove a interação com o médico e com o paciente. O módulo web comunica-se com o módulo de controle para buscar dados do Banco de Dados (BD) ou informar atualizações feitas pelo usuário. O módulo de controle interage com o sistema de informação clínica a fim de receber as informações da prescrição diretamente do consultório médico. O módulo de controle comunica-se com o módulo web e com o módulo móvel como um serviço de acesso ao banco de dados (representado na Figura 7 como BD), sendo toda inserção, alteração, leitura ou deleção das informações do BD ocorre no módulo de controle. O módulo móvel promove a interação com o paciente e mantém um banco de dados interno ao módulo, sendo que este possui as informações do BD que são referentes ao paciente. A comunicação deste módulo com o módulo de controle se dá com o objetivo de manter os dois bancos de dados sincronizados. A interação entre os módulos acontece através de mensagens transmitidas pelos Web Services REST. A garantia de fidelidade às recomendações médicas pode ser compreendida pelo fato das informações da prescrição serem inseridas diretamente pelo médico no módulo web ou através do sistema de informação clínica. Desta forma a prescrição médica se encontrará no sistema AMESC exatamente como o médico prescreveu no consultório, sendo que apenas o profissional de saúde pode alterar esta prescrição.

46 45 Figura 7: Arquitetura AMESC. Como pode ser visto na Figura 7 os módulos comunicam-se entre si através de mensagens HL7 transmitidas através de Web Services baseados no estilo REST. O uso de módulos interoperáveis permite o desenvolvimento de novos módulos que comuniquem-se com os módulos originais através de mensagens HL7 passadas por REST. Esta possibilidade torna a arquitetura AMESC extensível através do desenvolvimento de novos módulos Módulo Web O módulo web pode ser compreendido com um site que comunica-se com o médico e com o paciente através da web, e com o módulo de controle através de mensagens HL7. Através deste módulo o paciente é capaz de gerenciar suas informações pessoais e preferências de notificação. E o médico gerencia seus dados pessoais e as prescrições médicas, sendo que estas podem ser obtidas diretamente do SIC no módulo de controle. A comunicação com o módulo de controle ocorre com o objetivo de atualizar o BD e solicitar informações previamente cadastradas. Este módulo ainda não foi desenvolvido Módulo de Controle O módulo de controle atua como um serviço de acesso ao BD, todas as solicitações ou atualizações são enviadas ou recebidas em forma de mensagens HL7 pelos outros dois módulos e pelo SIC. As mensagens HL7 podem ser mensagens de solicitação de informações

47 46 ou de atualização. As mensagens de solicitação de informações exigem uma mensagem de resposta e, as mensagens de atualização exigem uma confirmação de volta para o módulo que inciou a comunicação. A comunicação com o módulo web objetiva receber atualizações feitas pelo usuário e fornecer informações ao website. Assim como no módulo móvel ocorre uma sincronização dos bancos de dados, a cada modificação do BD ou do banco de dados interno do módulo móvel há o envio de uma mensagem. Também notifica o módulo móvel de modificações no BD, abastecendo e mantendo atualizado o BD interno do módulo móvel. A modelagem e implementação deste módulo será descrita no capítulo 4 deste trabalho Módulo Móvel O módulo móvel é composto de uma aplicação móvel que interage com o paciente, permitindo o mesmo alterar ou inserir suas informações pessoais e preferências de notificação. Mantém uma cópia interna do BD da aplicação, que é atualizado através da interação com o usuário e com o módulo de controle, além de informar o módulo de controle das atualizações que ocorrem na aplicação móvel. Também notifica o paciente das orientações de toma dos medicamentos, levando em conta o contexto do mesmo (data, hora, localização e preferências do paciente). Seu desenvolvimento está sendo realizado utilizando a linguagem Java para Android, através do Integrated Development Environment (IDE) Eclipse, e o banco de dados orientado a objetos DataBase for Objects (DB4o). 3.2 Cenário Hipotético Um cenário hipotético do funcionamento deste arquitetura foi desenvolvido para permitir uma melhor compreensão da mesma. Para este cenário admite-se o médico Felipe e o paciente João. A inserção da prescrição pode ocorrer manualmente através do website disponibilizado pela arquitetura AMESC ou diretamente pelo sistema de informação usado na clínica médica. Neste paciente João consulta com o médico Felipe, o qual prescreve o medicamento Dipirona duas vezes ao dia (de 12 em 12h) durante 10 dias e o medicamento Cataflan duas vezes ao dia (de 12 em 12h), sendo que um medicamento deve ser tomado a cada seis horas

48 47 intercalando os dois fármacos. A prescrição pode ser vista no Quadro 4 e os passos do processo de uso do sistema poder ser vistos a seguir: Quadro 4 Descrição da prescrição médica. Medicamento Periodicidade Período Observações Dipirona 12 em 12h 10 dias Intercalar com o Cataflan Cataflan 12 em 12h 10 dias Intercalar com a Dipirona Felipe, que já havia cadastrado seus dados pessoais no website, cadastra os medicamentos no mesmo e pede que João o acesse, cadastre seus dados pessoais e suas preferências de notificação, e baixe o aplicativo móvel em seu smartphone. João acessa o website, cadastra-se e registra suas preferências que são: Gostaria de ser notificado por alarme sonoro e notificação no celular quando estiver em casa, apenas por notificação no celular quando estiver no trabalho, e por alerta vibratório e notificação do celular quando estiver em outros lugares. Os horários que tomarei os medicamentos, dentro da restrição imposta pelo médico, serão 03:00h, 09:00h, 15:00h e 21:00h, como pode ser visto no Quadro 5. Quadro 5 Representação das preferências do paciente. Local Alarme sonoro Notificação no celular Alerta vibratório Casa X X - Trabalho - X - Outros lugares - X X Após tudo configurado, o sistema analisa a duração do tratamento com medicamentos, o dia atual, a hora atual e as preferências de João e o avisa de forma que suas preferências e as exigências do médico sejam atendidas. João trabalha das 8:45 às 18:15, faz intervalo para o almoço das 12:45 às 14:15 no qual vai para casa fazer sua refeição, após o trabalho João realiza suas tarefas pessoais até às 21:30 horas e depois vai para casa. Neste contexto o aplicativo móvel identifica a localização de João, em cada horário de toma de medicamento durante os dez dias do tratamento. Em um dia comum, o

49 48 aplicativo notificará João através de notificação no celular e alarme sonoro às 3h da manhã, através de notificação no celular às 9h da manhã, através de notificação no celular às 15h e através de alarme vibratório e notificação no celular às 21h, como pode ser visto no Quadro 6. Quadro 6 Histórico de notificações do paciente em um dia normal. Horário Local Forma de notificação 3h Casa Notificação no celular e alarme sonoro 9h Trabalho Notificação no celular 15h Trabalho Notificação no celular 21h Outro local Notificação no celular e alarme vibratório A cada notificação é necessário que João informe ao aplicativo que tomou o medicamento através de uma interação com o dispositivo móvel para que cesse a notificação, caso contrário o dispositivo continuará notificando-o. Após os 10 dias de tratamento o aplicativo cessa os alarmes até que se inicie um novo tratamento informado pelo médico.

50 49 4 MODELAGEM E IMPLEMENTAÇÃO Este capítulo tem como objetivo demonstrar a modelagem e implementação do módulo de controle do Projeto AMESC. Na seção 4.1 é apresentada a análise dos requisitos necessários para a implementação deste módulo. Na seção 4.2 os requisitos definidos na seção 4.1 são modelados e apresentados em forma de um diagrama Entidade-Relacionamento (ER). Na seção 4.3 é feita uma breve explicação sobre as tecnologias utilizadas para o desenvolvimento deste módulo e na seção 4.4 são apresentados detalhes sobre a implementação do módulo de controle. 4.1 Análise de Requisitos Para modelagem do banco de dados do módulo de controle foi realizada uma análise das informações relevantes para o mesmo. Tais informações são apresentadas nesta seção Dados do paciente Para o módulo de controle são importantes os seguintes dados do paciente: nome, número de Registro Geral (RG), telefone, endereço, nome para recados, telefone para recados, e para recados. Caso o paciente seja menor de idade devem constar também: nome do responsável, telefone do responsável, número RG do responsável e do responsável. A respeito da localização, as informações relevantes são: país, estado, cidade, bairro, rua, complemento, número, CEP (Código de Endereçamento Postal), latitude, longitude e altitude de cada localidade informada. A respeito das preferências do paciente, as informações relevantes são os tipos de alarme desejados para as diferentes localidades e os horários de toma dos medicamentos, os quais devem estar de acordo com as restrições definidas pelo médico Dados do médico Os dados relevantes do médico para a arquitetura AMESC são nome, número de inscrição no CRM, telefone e endereço do consultório, especialidade e .

51 Dados do medicamento Os dados relevantes do medicamento são a associação de fármacos ou fármaco, o detentor do medicamento, o nome comercial do medicamento, a concentração dos fármacos e sua forma farmacêutica Dados da Prescrição Sobre a prescrição, os dados relevantes são o paciente e o médico a qual está prescrição se refere, o medicamento a qual se refere, seu o horário, frequência de toma, via, quantidade, restrições alimentares, restrições em relação a outros medicamentos, observações do médico e as datas de início e fim do uso dos medicamentos Dados do usuário Os dados relevantes de cada usuário são o nome, o , o nome de usuário usado para acessar o sistema, a senha correspondente a este usuário, seu endereço (o qual é tratado como uma localidade), data de nascimento e telefone Dados dos alarmes Os dados importantes a respeito dos alarmes criados pelo módulo móvel são o horário, o tipo de alarme, a qual prescrição o alarme se refere e se o mesmo foi visualizado pelo paciente ou não Dados dos dispositivos A respeito dos dispositivos usados pelos pacientes são relevantes o Android Id 4, o nome e o paciente a qual pertence o mesmo. 4 Android Id é um identificador único de cada dispositivo (YANG, Z; YANG, M, 2012).

52 Modelagem dos Requisitos A modelagem do banco de dados foi feita a partir do levantamento de requisitos já apresentado. O diagrama ER que representa a modelagem das informações como é apresentado na Figura 8.

53 Figura 8 - Diagrama entidade-relacionamento. 52

54 53 As informações do médico e do paciente foram modeladas a partir da entidade Pessoa, que possui as informações comuns aos dois. O nome de usuário (username) e senha utilizados pelo usuário estão situados na entidade Pessoa pois tanto médicos quanto pacientes possuem um usuário e senha de acesso. O endereço do usuário é representado a partir de uma referência que é a tabela local. Os dispositivos móveis que pertencem aos pacientes estão representados através da tabela dispositivo. Os dados dos locais estão representados na tabela Local, a qual possui os dados tradicionais de um endereço (rua, bairro, cep, etc.) e as informações usadas em Global Positioning Systems (GPS) - longitude, latitude e altitude. Permitindo que os endereços sejam inseridos manualmente pelo usuário e não obrigatoriamente pelo uso do Google Maps. Os locais são relacionados aos pacientes através da tabela Local_Paciente. A modelagem das informações da prescrição possui informações detalhadas afim de permitir os mais diversos tipos de prescrições, permitindo que o escalonamento de toma dos medicamentos seja das mais variadas formas. Os atributos cada_dias, cada_horas, cada_minutos e cada_meses representam uma periodicidade de dias, horas, minutos ou meses. No caso de um medicamento Y precisar ser tomado a cada 2 dias, a cada 5 horas, a cada 30 minutos, a cada dois meses ou a cada 1 ano, este conjunto de atributos deve ser usado na representação. No caso do medicamento necessitar ser tomado uma certa quantidade de vezes ao dia, ao ano, ao mês ou na semana usamos os atributos vezes_dia, vezes_mes, vezes_ano e vezes_semana. Como exemplo de escalonamento que utiliza os atributos mencionados na sentença anterior podemos exemplificar um medicamento Z que precisa ser tomado uma vez ao dia, duas vezes ao mês, duas vezes por ano ou três vezes por semana. Para representações mais complexas, como a representação de um medicamento B que precisa ser tomado três vezes ao dia, sendo uma vez a cada oito horas, esta prescrição é representada pelos atributos vezes_dia e cada_horas. A cada prescrição é associado um medicamento, um médico e um paciente. As prescrições de mais de um medicamento feitas pelo médico são representadas no banco de dados como linhas da tabela Prescrição. Quando dois ou mais medicamentos são prescritos juntos, intercalados, separados, com uma diferença específica de tempo entre a toma de cada um ou com uma frequência específica para a ingestão é usada a entidade Restrição, aonde são descritas as restrições deixadas pelo médico. Na tabela Restrição_Medicamento uma Restrição pode ser associada a uma ou mais prescrições indicando que aquelas prescrições seguem esta Restrição em específico.

55 54 Para cada prescrição e de acordo com as Restrições associadas a mesma, são criados Alarmes que representam os horários em que o dispositivo deve notificar o paciente da toma de medicamentos. 4.3 Tecnologias Utilizadas Para o desenvolvimento deste trabalho algumas tecnologias foram utilizadas. Esta seção tem por objetivo apresentar brevemente tais tecnologias e as motivações de escolha de cada uma PostgreSQL A ferramenta PostgreSQL é um SGBD de código-aberto e relacional, que possui interfaces nativas de programação JAVA. Possui 15 anos de desenvolvimento ativo e uma significante reputação de confiabilidade, integridade de dados e conformidade a padrões, sendo usada inclusive comercialmente (PostgreSQL, 2014). A escolha deste SGBD se deu devido a sua reputação e compatibilidade com a linguagem Java Hibernate O Hibernate é um framework de mapeamento objeto-relacional, ou seja, uma ferramenta que facilita o mapeamento de bancos de dados relacionais em linguagens de programação orientadas a objeto. Esta ferramenta pode ser usada com diversos bancos de dados, porém é especifica para a linguagem Java (HIBERNATE, 2014). Gotardo e Junior (2013) salientam que o uso deste framework deixa o programador mais livre para pensar no funcionamento da aplicação em si, sem preocupar-se como seus objetos se corresponderão com o banco de dados relacional. Este framework está sendo usado devido as facilidades que proporciona e à compatibilidade com a linguagem de programação Java.

56 Java Java é uma linguagem de programação que pode ser caracterizada pela sua simplicidade, portabilidade, alta performance e segurança (ASCENCIO; CAMPOS, 2012), sendo considerada uma linguagem de alto nível. Outra característica do Java é a utilização da Java Virtual Machine (JVM) que é o elemento que fornece a portabilidade e segurança, pois a mesma transforma o código escrito pelo programador em linguagem de máquina e o executa (SCHILDT; SKRIEN, 2013). Por ser uma linguagem orientada a objetos (GOMES, 2009), favorece o reuso, a manutenção e a extensão dos códigos (ASCENCIO; CAMPOS, 2012). Além das características anteriores Java é uma linguagem muito utilizada e que possui muitas ferramentas de apoio. Como podemos ver esta linguagem provê os requisitos necessários para o desenvolvimento da arquitetura proposta, além de favorecer o desenvolvimento de módulos extensíveis devido à orientação a objetos. Devido às vantagens apresentadas está linguagem está sendo utilizada neste trabalho API Hapi HAPI é uma API de código aberto e orientada a objetos que tem por objetivo facilitar a programação Java com o padrão HL7 (HAPI, 2014). Consiste de uma estrutura de classes e interfaces java que auxiliam na criação de sistemas que suportam HL7, auxiliando na criação e manipulação de mensagens HL7. Esta API não está diretamente ligada a organização HL7, porém é recomendada pela mesma (HL7, 2014) e (HAPI 2014). Esta ferramenta está sendo usada devido a recomendação da organização HL7 e a compatibilidade dos serviços prestados pela mesma com os objetivos do módulo de controle JAX-RS Java API RESTful Web Services (JAX-RS) é uma especificação Java que proporciona suporte na criação de Web Services REST (DAL MORO et al, 2011) e (SAUDATE, 2013). Por ser uma especificação, há diversas implementações da mesma, sendo que a implementação recomendada pela Oracle é o framework Jersey (ORACLE DOCUMENTATION, 2014) e (SAUDATE, 2013).

57 56 O Jersey é um framework de código aberto para o desenvolvimento de Web Services REST que provê suporte à especificação JAX-RS. O Jersey não é apenas uma implementação, pois o mesmo fornece uma API própria que estende a especificação JAX-RS com funcionalidades adicionais que simplificam o desenvolvimento dos servidores e clientes. (JERSEY, 2014). Devido às facilidades providas pelo JAX-RS juntamente com o Jersey e ao fato desta implementação ser recomendada pela Oracle esta ferramenta está sendo usada na implementação deste trabalho Astah O Astah é uma ferramenta para modelagem de sistemas para UML. Através dessa ferramenta podem ser desenvolvidos fluxogramas, diagramas de fluxo de dados, diagramas Entidade-Relacionamento (ER) entre outros (ASTAH REFERENCE MANUAL, 2013), esta ferramenta objetiva a orientação a objetos (PEPE; MATHIAS, 2010). Por ser uma ferramenta de modelagem de sistemas para UML, que objetiva a orientação a objetos, utilizou-se o Astah para o desenvolvimento dos diagramas deste projeto Poster O Poster é uma ferramenta para desenvolvedores que se apresenta como um complemento dos navegadores Mozilla Firefox e Google Chrome. A mesma permite interação com serviços web e com outros recursos que lhe permitam fazer requisições HTTP, possibilitando a interação com os recursos e a inspeção os resultados (POSTER, 2014). Saudate (2013) em seu livro recomenda o uso desta ferramenta para realizar testes com os Web Services, ressaltando que esta é uma forma cômoda devido ao fato de proporcionar uma interface gráfica para o desenvolvimento de testes em Web Services. Devido à recomendação de uso por Saudate (2014) e da facilidade encontrada para o uso da ferramenta, a mesma foi utilizada para realizar os testes dos Web Services neste trabalho.

58 Mozilla Firefox O Mozilla Firefox é um navegador de código aberto (SILVA, M, 2012) que destaca-se por sua confiabilidade, flexibilidade e rapidez. Sendo considerado o navegador mais confiável da internet o mesmo apresenta mecanismos anti-restreamento, navegação privativa, conexões seguras, proteção à nível mundial e atualizações de segurança automáticas. Este navegador destaca-se também pela rapidez, apresentando boa velocidade tanto para tarefas pesadas quanto leves (MOZILLA, 2014). Devido às vantagens apresentadas acima e à disponibilidade do complemento Poster para este navegador o mesmo está sendo utilizado neste trabalho NetBeans IDE O NetBeans IDE é um ambiente de desenvolvimento integrado multiplataforma que oferece ferramentas poderosas para desenvolvimento Java, além de suportar outras tecnologias (ORACLE, 2014). Esta IDE provê um ótimo suporte para tecnologias Java e está em constante atualização, além de prover mais eficiência na edição do código através dicas e ferramentas de refatoração. Além das facilidades já apresentadas o NetBeans possui suporte ao desenvolvimento de Web Services REST (NETBEANS, 2014). Devido às vantagens apresentadas este IDE está sendo usado no desenvolvimento do módulo de controle. 4.4 Implementação Nesta seção é descrita a implementação do módulo móvel através de diagramas e da demonstração das classes desenvolvidas, as quais foram desenvolvidas em Java utilizando a IDE NetBeans Diagrama de Pacotes O módulo de controle do sistema AMESC foi organizado em cinco pacotes, como pode ser visto na Figura 9. De forma a simplificar a leitura, nos referiremos aos pacotes pela

59 58 palavra após o segundo ponto, por exemplo o pacote com.modulodecontrole.testes será citado durante o texto como pacote de testes ou pacote testes. Figura 9 Diagrama de pacotes. Os pacotes dao e modelo são relacionados ao banco de dados, sendo que o pacote modelo abriga classes que representam as entidades do BD. As classes do pacote dao encapsulam o acesso ao banco de dados, sendo que qualquer operação com as entidades é feita através destas classes. No pacote resources estão as classes que representam os recursos fornecidos pelo Web Service REST, sendo que cada entidade do banco de dados possui um recurso correspondente. O pacote hl7 contém as classes que implementam o padrão HL7, as mesmas são utilizadas no envio das mensagens hl7. O pacote de testes abriga classes utilizadas para testes durante o desenvolvimento do projeto. Para melhor compreensão da estrutura do módulo de controle, os diagramas de classes e detalhes da implementação das mesmas serão apresentados nas próximas seções Diagramas de Classes Os diagramas apresentados a seguir representam as classes dos pacotes apresentados no diagrama de pacotes. Por uma questão estética os métodos get e set das classes Java foram ocultados, assim como os parâmetros dos métodos.

60 Classes do pacote modelo As classes do pacote modelo representam o mapeamento objeto-relacional das entidades do banco de dados, como podemos observar na Figura 10. Figura 10 Classes do pacote modelo.

61 Classes do pacote dao As classes do pacote dao são utilizadas para o acesso ao banco de dados, as mesmas podem ser visualizadas na Figura 11. Figura 11 Classes do pacote dao Classes do pacote resources Cada classe do pacote resources representa um recurso do sistema, como pode ser conferido na Figura 12.

62 61 Figura 12 Classes do pacote resources Classe do pacote hl7 Figura 13. O pacote hl7 é composto pela classe CreateAMessage.java e pode ser visualizado na Figura 13 Classe do pacote hl7.

63 Classes do pacote testes As classes do pacote testes foram utilizadas para testar as operações de banco de dados do. Estas classes podem ser visualizadas na Figura 14. Figura 14 Classes do pacote testes Classe de configuração do Hibernate A classe de configuração do Hibernate está situada no pacote padrão do projeto Java, como pode ser verificado na Figura 15. Figura 15 Classe de configuração do hibernate.

64 Detalhes de implementação Nesta seção são apresentados os detalhes de apresentação do módulo de controle. Os mesmos são divididos em implementação do banco de dados, implementação dos Web Services REST e implementação das mensagens HL Implementação do banco de dados O banco de dados foi implementado em PostgreSQL, sendo que os códigos Structured Query Language (SQL) do banco podem ser vistos no Apêndice A. O mapeamento objetorelacional foi realizado através da ferramenta Hibernate, havendo uma classe anotada para cada entidade do banco de dados. O mapeamento objeto relacional foi feito através do Hibernate, a configuração da ferramenta é feita através da classe hibernate.cfg.xml e pode ser vista na Figura 16. Figura 16 Configuração do Hibernate.

65 64 A configuração do Hibernate ocorre através de um arquivo XML, onde são estabelecidas as propriedades a serem usadas e as classes que serão mapeadas para o funcionamento correto da aplicação. Nas tags properties são encontradas as informações necessárias para a conexão com o banco de dados, neste caso o postgresql. Nas tags mapping estão descritas as classes que são mapeadas pelo Hibernate. O mapeamento das classes se deu através de anotações, na Figura 17 podemos visualizar uma classe com os atributos anotados. Figura 17 Exemplo de classe anotada Implementação do Web Service REST O Web Service REST foi desenvolvido a partir do JAX-RS com a implementação Jersey. A configuração da API ocorre nas tags <servlet> e <servlet-mapping> da classe web.xml, que pode ser vista na Figura 18.

66 65 Figura 18 Classe web.xml. Como já foi citado no capítulo dois, os recursos são o ponto central dos Web Services REST. Nesta implementação os recursos são utilizados para representar operações sobre as entidades do banco de dados. Todas as entidades são representadas por recursos, os quais foram implementados em classes Java denominadas na forma nomedaentidaderesource.java. As operações que podem ocorrer sobre as entidades são implementadas através dos métodos HTTP e podem ser compreendidas melhor através do Quadro 7. Neste Quadro podem ser vistas as operações sobre a entidade alarme. Quadro 7 Correspondência entre métodos HTTP, operações e URIs na entidade alarme. Método HTTP Operação URI GET selecionar todos os alarmes GET selecionar um alarme a partir de seu identificador POST adicionar um alarme PUT alterar um alarme

67 66 DELETE deletar um alarme Como pode ser observado apenas a operação selecionar um alarme a partir de seu identificador possui um URI diferenciado, as outras operações são singularizadas através dos métodos HTTP. As operações podem ser acessadas por clientes REST através das URIs correspondentes, que estão representadas no Quadro 9. A estrutura da classe AlarmeResource.java com a representação dos métodos HTTP pode ser visualizada na Figura 19. Figura 19 - Estrutura da classe AlarmeResource.java. Na classe AlarmeResource.java são implementados os métodos correspondentes as operações apresentadas no Quadro 9, sendo que o caminho do recurso é definido na acima da classe. Os métodos da classe são correspondidos com os métodos HTTP através @PUT Os métodos podem consumir e

68 67 produzir dados, sendo que o tipo de dado consumido ou produzido é identificado respectivamente pelas O método getalarmes corresponde a operação selecionar todos os alarmes e ao método HTTP GET. Este método consiste de pesquisar todos os alarmes e retorna-los em uma lista representada através de XML, o mesmo pode ser verificado na Figura 20. Figura 20 - Método getalarmes. O método getalarme consiste de pesquisar um alarme a partir de seu identificador e retornar o alarme solicitado através de um XML. Corresponde à operação selecionar um alarme a partir de seu identificador e foi desenvolvido através do método GET do HTTP. A implementação deste método pode ser observada na Figura 21. Figura 21 - Método getalarme. A inserção de novos alarmes ocorre através do método adicionaalarme, o qual corresponde a operação adicionar um alarme e implementa o método POST do HTTP. Este método consome um XML correspondente a um objeto da classe Alarme e faz a inserção do mesmo no banco de dados, retornando uma String de confirmação. A implementação do método adicionaalarme pode ser vista na Figura 22.

69 68 Figura 22 - Método adicionaalarme. O método atualizaalarme desenvolve a operação alterar um alarme através do método POST do HTTP. Este método consome um XML que corresponde ao objeto Alarme a ser modificado e realiza essa operação no banco de dados, produzindo uma String de confirmação. A implementação deste método pode ser verificada na Figura 23. Figura 23 Método atualizaalarme. A deleção de um alarme é implementada através do método removealarme, o qual pode ser verificado na Figura 24. Este método desenvolve a operação deletar um alarme através do método DELETE do HTTP. O mesmo recebe por parâmetro o número identificador do objeto a ser excluído, realiza uma busca no banco de dados a fim de recuperar o objeto desejado e executa uma operação de exclusão.

70 69 Figura 24. Método removealarme. A partir da demonstração da classe AlarmeResource.java pode ser compreendido o mecanismo de implementação do Web Service REST do módulo de controle. As outras entidades são igualmente representadas por recursos, os quais obedecem a mesma estrutura apresentada anteriormente e são modificados de acordo com as entidades que representam Implementação das mensagens HL7 As mensagens HL7 foram implementadas através da API HAPI, para a utilização da mesma foi necessário apenas adicionar ao projeto Java a biblioteca HAPI. A classe CreateAMessage.java foi desenvolvida com o objetivo de implementar uma mensagem HL7, a estrutura desta classe pode ser vista na Figura 25. Figura 25 - Estrutura da classe CreateAMessage.

71 70 A classe CreateAMessage é composta por cinco métodos. Os métodos createmessage e createxmlmessage retornam mensagens HL7 prontas para ser enviadas pelo Web Service REST. Os métodos stringtomessage e xmltomessage convertem a uma mensagem HL7 recebida em formato texto para formato de mensagem. O método getinfo retorna as informações do paciente retiradas de uma mensagem. O método createmessage cria uma mensagem HL7 que contém o nome e o idpessoa de um paciente a partir de um paciente recebido por parâmetro. Este método cria uma mensagem ADT_01 que carrega o nome e o idpessoa do paciente em questão e codifica a mensagem através do parser, sendo criada e retornada uma mensagem HL7 padrão. A implementação deste método pode ser conferida na Figura 26. Figura 26 - Método createmessage. Como pode ser visualizado na Figura 27 os métodos createmessage e createxmlmessage diferem apenas no tipo de parser a ser usado. O método createmessage utiliza PipeParser para criar uma mensagem HL7 padrão e o método createxmlmessage utiliza XMLParser para criar uma mensagem HL7 em formato XML. Sendo assim podemos destacar estes dois métodos possuem a mesma função, apenas mudando o tipo de retorno.

72 71 Figura 27 - Método createxmlmessage. Os métodos stringtomessage e xmltomessage também possuem funções semelhantes e podem ser visualizados na Figura 28. Estes métodos têm por intuito receber uma mensagem HL7 em formato texto (stringtomessage) ou uma mensagem HL7 em formato XML e retornar o formato objeto da mesma. Figura 28 - Métodos stringtomessage e xmltomessage.

73 72 O método getinfo visa extrair as informações desejadas da mensagem HL7, neste caso o nome e o idpaciente de um certo paciente. Como pode ser visto na Figura 29 o método recebe como parâmetro uma mensagem ADT e retorna como um vetor de Strings o nome e o idpaciente. Figura 29 - Método getinfo. O objetivo da implementação das mensagens HL7 tem por objetivo possibilitar que essas mensagens sejam passadas através do Web Service REST. Para tanto foi desenvolvida a classe HL7Resource.java, sua estrutura pode ser conferida na Figura 30. Figura 30 - Classe HL7Resource. A classe HL7Resource é composta por quatro métodos. Os métodos getmessage e getxmlmessage são responsáveis por disponibilizar a consulta a dados do paciente através do

74 73 método GET do HTTP. Os métodos recebemensagem e recebemensagemxml possibilitam o recebimento de mensagens HL7 em formato padrão ou formato XML. Como pode ser visto na Figura 31, o método getmessage disponibiliza a consulta dos dados de um paciente através do RG do mesmo. O método recebe como parâmetro o RG do paciente e utiliza-o para recuperar os dados do paciente desejado, após isto utiliza o método createmessage para criar uma mensagem HL7 em formato texto. Figura 31 - Método getmessage. O método getxmlmessage difere do método getmessage por retornar uma mensagem HL7 no formato XML. Como pode ser observado na Figura 32, é feita uma pesquisa a partir do RG recebido por parâmetro que recupera o paciente desejado, após é utilizado o método createxmlmessage para criar uma mensagem HL7 em formato XML. Figura 32 - Método getxmlmessage. O método recebemensagem pode ser visualizado na Figura 33. O mesmo recebe por parâmetro uma mensagem HL7 em formato texto e utiliza o método stringtotext para transformá-la em uma mensagem em formato objeto. A partir da mensagem em formato

75 74 objeto o método getinfo retorna as informações desejadas em formato de vetor. Este método se propõe a retornar diretamente as informações desejadas, facilitando o uso das mesmas. Figura 33 - Método recebemensagem. Na Figura 34 é demonstrada a implementação do método recebemensagemxml, como pode ser observado este método é muito semelhante ao método recebemensagem. São distintos apenas pelo fato de o método recebemensagemxml receber uma mensagem em formato XML e utilizar o método xmltomessage para converte-la em uma mensagem do tipo objeto. Figura 34 Método recebemensagemxml. A seção de implementação teve como intuito demonstrar o desenvolvimento do módulo de controle, trazendo trechos do código e explicações sobre os mesmos.

76 75 5 RESULTADOS Como resultado deste trabalho foi desenvolvido um protótipo do módulo móvel cujo a implementação foi demonstrada no capítulo 4. Este capítulo demonstra a operação das funcionalidades deste protótipo, para este fim foi desenvolvida uma simulação com a ferramenta Poster e com o browser Mozilla Firefox, a qual será demonstrada na seção Simulação Com o objetivo de dar sequência aos exemplos já usados neste trabalho, foram desenvolvidos testes com a classe AlarmeResource.java e HL7Resource.java. Através destas ferramentas serão verificados métodos desenvolvidos no capítulo anterior, o Poster agirá como o módulo móvel enviando atualizações da entidade Alarme. Esta demonstração tem por objetivo utilizar todas as operações apresentadas no Quadro 7 e demonstrar a recuperação dos dados de um paciente através de uma mensagem HL AlarmeResource.java A partir da inserção de dois alarmes demonstraremos a operação adicionar um alarme. Para este fim foi inserida a URI do recurso correspondente à operação desejada, o XML do alarme a ser inserido e enviado através do método POST, como pode ser visto na Figura 35.

77 76 Figura 35 - Inserção de um alarme. Como o objetivo foi adicionar dois alarmes, este processo foi repetido para dois XMLs diferentes, os quais podem ser verificados no Apêndice B (itens a e b). Após o envio é recebida uma confirmação de inserção no Poster, a mesma pode ser vista na Figura 36.

78 77 Figura 36 - Confirmação da inserção. Para verificar se os alarmes foram inseridos será feita uma consulta a todos os alarmes cadastrados. A recuperação de todos os alarmes se dá através do acesso a URI correspondente a operação selecionar todos os alarmes através do navegador. Todos os alarmes cadastrados no banco de dados são retornados em formato XML, como pode ser visto na Figura 36. Para melhor compreensão das figuras de recuperação de alarmes, nas mesmas a tag <prescricao> foi ocultada.

79 78 Figura 37 Recuperação de todos os alarmes. Um alarme pode ser atualizado através do envio do XML correspondente ao alarme que deseja-se alterar pelo método PUT. No Apêndice B (item c) pode ser visto o XML a ser enviado para alterar no alarme de idalarme 13 o valor da tag <tipo> para silencioso. A Figura 38 demonstra a inserção dos dados da URI e do XML no Poster, os quais são enviados através do método PUT.

80 79 Figura 38 - Atualização de um alarme. A confirmação recebida após o envio pode ser verificada na Figura 39.

81 80 Figura 39 Confirmação de atualização. Para verificarmos o sucesso desta operação podemos recuperar um alarme. A consulta a um alarme pode ser feita através do acesso à URI da operação selecionar um alarme através de seu identificador. Por isso foi acessada a URI e obteve-se como retorno o XML apresentado na Figura 40.

82 81 Figura 40 - Consulta à um alarme. Para demonstrar a operação deletar um alarme e é feita a remoção do alarme idalarme 13. A qual implementa-se inserindo uma URI que inclui para o elemento a ser deletado ou seja idalarme do mesmo, o qual pode ser verificado na Figura 41. Para a efetivar a exclusão é enviado uma solicitação DELETE ao módulo de controle.

83 82 Figura 41 - Exclusão de um alarme. Figura 42. Após o envio da solicitação é recebida uma confirmação, como pode ser verificado na

84 83 Figura 42 - Confirmação da exclusão. Para a verificar a o sucesso da exclusão foi feita uma consulta a todos os alarmes do banco de dados. Como pode ser observado na Figura 43, apenas o alarme de idalarme 31 é apresentado quando são recuperados todos os alarmes.

85 84 Figura 43 Nova consulta a todos os alarmes HL7Resource.java Para a recuperação do idpessoa e do nome de um paciente através de seu RG podemos acessar a URI conforme apresentado na Figura 30. Para buscar um determinado paciente substituímos {id} por seu RG, no caso o RG fictício Como pode ser visto na Figura 44, esta ação resulta no recebimento de uma mensagem HL7 que representa o idpessoa (11) e o nome (Paula Almeida) devidamente codificados em uma mensagem ADT_01. Figura 44 - Acesso às informações do paciente através de uma mensagem HL7. A partir destas demonstrações apresentamos os resultados do desenvolvimento do protótipo do módulo de controle da arquitetura AMESC.

86 85 CONSIDERAÇÕES FINAIS Tratamentos medicamentosos são realizados por qualquer pessoa em qualquer faixa etária. Porém algumas doenças necessitam um escalonamento complexo dos fármacos, destacando as doenças crônicas e próprias do envelhecimento. Assim podemos compreender que todas as pessoas estão sujeitas à necessidade de administrar medicamentos com maior rigidez. A aderência às recomendações médicas é uma atividade que influência significantemente no sucesso dos tratamentos, sendo que erros podem trazer prejuízos à saúde do paciente. Os erros por parte do paciente ocorrem principalmente por falta de atenção, esquecimento, falta de cuidado, negligência e carência de informações completas nas prescrições. A partir revisão bibliográfica feita neste trabalho identificou-se a necessidade de ampliar estudos e pesquisas que incentivem a correta execução das recomendações médicas pelo paciente, assim como o desenvolvimento de estratégias que auxiliem o mesmo com o escalonamento diário dos fármacos. Pode-se observar que os Sistemas de Informação em Saúde são valiosas ferramentas para a elaboração de tais estratégias e que os mesmos podem proporcionar informações concisas e claras, que contribuem para o sucesso das terapias medicamentosas. A respeito dos SIS concluímos que os mesmos deveriam garantir fidelidade às recomendações dos médicos e a interoperabilidade. Permitindo interações com softwares de clínicas médicas, auxiliando no tratamento médico e possibilitando futuras trocas de informações, as quais poderão agilizar e tornar mais dinâmicos futuros atendimentos. A partir dos fatos já apresentados foi proposta uma arquitetura capaz de facilitar a administração de medicamentos, garantir fidelidade às recomendações médicas, permitir a interoperabilidade através de módulos baseados em Web Services e auxiliar na administração de medicamentos levando em conta o contexto de cada paciente, tempo e localidade. Esta arquitetura visa unicamente auxiliar na correta execução das recomendações médicas, sem o intuito de interferir nas decisões do profissional de saúde ou esclarecer os pacientes em relação à medicação em uso. Dos módulos apresentados na arquitetura proposta o módulo de controle foi o foco deste trabalho. Durante o desenvolvimento do mesmo foram encontramos alguns desafios, entre eles podemos destacar a escassez de materiais, livros e artigos que orientem a

87 86 implementação do protocolo HL7 utilizando Java, apesar da abundância de informações sobre o protocolo em si. O protótipo apresentado desenvolveu parcialmente as funcionalidades do módulo realizando a comunicação REST e a manipulação das entidades do banco de dados com êxito, porém não implementou esta comunicação através de mensagens HL7. Este trabalho contribuiu apresentando uma arquitetura que abrange as necessidades apresentadas através do estudo bibliográfico. Tal arquitetura permite a fidelidade às prescrições médicas e a interoperabilidade através dos Web Services e do padrão HL7. O resultado apresentado no desenvolvimento deste trabalho permite a interoperabilidade através dos Web Services e através do desenvolvimento do módulo web garantirá fidelidade às recomendações médicas. Como trabalhos futuros pretende-se desenvolver a comunicação deste módulo através de mensagens HL7 e desenvolver o módulo web, sendo que o módulo móvel está sendo desenvolvido de acordo com Projeto AMESC. Também propõe-se o desenvolvimento de materiais de apoio à implementação do padrão HL7 a partir da linguagem Java, a implementação de segurança na arquitetura AMESC (para não ocorrem invasões com o intuito de modificar prescrições e prejudicar a saúde do paciente ou a reputação do médico) e a implementação de um sistema que auxilie o paciente desde a marcação da consulta até o final do tratamento médico, interagindo com o Sistema de Informação Clínica.

88 87 REFERÊNCIAS BIBLIOGRÁFICAS ASCENCIO, Ana Fernanda Gomes; CAMPOS, Edilene Aparecida Veneruchi de. Fundamentos da PROGRAMAÇÃO de COMPUTADORES: ALGORITMOS, PASCAL, C/C++ (PADRÃO ANSI) E JAVA. São Paulo: Pearson Education do Brasil, ª Edição. 569 p. ASTAH REFERENCE MANUAL Em: < Acessado em 04/11/2014 às 13:00. Aula com dicas para uma boa prescrição médica hospitalar para os internos do Curso de Medicina da Faculdade Ingá (Uningá). Em: < Acesso em: 14/3/2014 às 15:45. BETTINI, C et al. A survey of context modelling and reasoning techniques. Pervasive Mob. Comput., vol. 6, no. 2, pp , Apr BIGOLIN, Marcio. REST x SOAP Análise e implementação de Web Services BIDGOOD, W. Dean et al. Understanding and using DICOM, the data interchange standard for biomedical imaging. Journal of the American Medical Informatics Association 4.3 (1997): BORST, W. Construction of Engineering Ontologies for Knowledge Sharing and Reuse. PhD thesis, University of Twente, P.O. Box AE Enschede - The Netherlands, CASSIANI, Sílvia Helena De Bortoli. A segurança do paciente e o paradoxo no uso de medicamentos. Rev Bras Enferm, v. 58, n. 1, p. 95-9, CAVALCANTE, Ricardo Bezerra; FERREIRA, Marina Nagata; SILVA, Poliana Cavalcante. Sistemas de Informação em Saúde: possibilidades e desafios. Revista de Enfermagem da UFSM, v. 1, n. 2, p , COULOURIS, George et al. SISTEMAS DISTRIBUÍDOS: Conceitos e Projetos. Porto Alegre: Bookman Editora LTDA, ª Edição p. DA SILVA SANTOS, Marcos Eduardo et al. Desenvolvendo Aplicações Home Care no Ambiente GINGA. InfoBrasil 2009 Fortaleza CE. DAL MORO, Tharcis; DORNELES, Carina; REBONATTO, Marcelo Trindade. Web services WS-* versus Web Services REST. Revista de Iniciação Científica, v. 11, n. 1, DANIEL, Vanessa Marques. Os Sistemas de Informação em Saúde e seu apoio à gestão e ao planejamento do SUS: uma análise de estados brasileiros DE ALMEIDA, Vitor Pinheiro; ENDLER, Markus; HAEUSLER, Edward Hermann. Patient Buddy-Build: Acompanhamento remoto móvel customizável de pacientes com doenças crônicas. XIII Congresso Brasileiro em Informática em Saúde CBIS, 2012.

89 88 DE CAMARGO SILVA, Ana Elisa Bauer et al. Problemas na comunicação: uma possível causa de erros de medicação. Acta Paul Enferm, v. 20, n. 3, p , DE FARIA LEÃO, Beatriz; DA COSTA, Cláudio Giulliano Alves; FORMAN, John Lemos. Manual de Certificação para Sistemas de Registro Eletrônico em Saúde DE FÁTIMA MARIN, Heimar. Sistemas de informação em saúde: considerações gerais. Journal of Health Informatics, v. 2, n. 1, ELKSTEIN, M. Learn REST: a tutorial. Em: < Acesso em: 05 de novembro FELLER, Nadjia Jandt. Estendendo rest-unit: geração baseada em U2TP de drivers e dados de teste para RESTful Web Services FERREIRA, Flávio et al. Multimodal and Adaptable Medication Assistant for the Eldery. 8ª Conferência Ibérica de Sistemas e Tecnologias de Informação - CISTI, Em: < Acesso em: 26/2/2014 às 8: Health Level Seven International. FIELD, Ryan et al. Health Care Providers Attitudes Towards Online Appointment Scheduling Systems at Planned Parenthood GODOI, Marcos R; FREITAS, Tadeu. Projeto Automação e Integração de Consultórios, Operadoras e Prestadores de Serviço na Área da Saúde. XIII Congresso Brasileiro em Informática em Saúde CBIS, GOMES, Pedro Tiago Magalhaes. Master Patient Index. Tese de Doutorado. Master s thesis, Faculdade de Ciências da Universidade do Porto, Portugal, GONÇALVES, Luciano W. Prontuário Eletrônico do Paciente Adotando Padrões Para a Telemedicina no Brasil. Trabalho de graduação. Universidade Federal do Rio Grande do Sul, Porto Alegre - RS, GOTARDO, Vitor; JUNIOR, Edson A. Oliveira. Análise de Desempenho dos Frameworks de Persistência Hibernate e Spring Data. Maringá, Paraná: EspWeb/UEM, GUIMARÃES, Renato Rangel. Conversão de imagens do formato DICOM visando a inter-operacionalidade de sistemas através da WEB HAPI. Em: < Acessado em: 30/10/2014 às 17:00. HENRIQUE, Fabricio Gustavo; NETO, Geraldo Henrique. Desenvolvimento de Software de Prescrição Eletrônica para Instituição Oncológica. XIII Congresso Brasileiro em Informática em Saúde CBIS, HIBERNATE. Em: < Acessado em: 30/10/2014 às 22:00. HL7. Em: < Acessado em: 30/10/2014 às 18:00.

90 89 Interfaceware. Em: < Acessado em: 11/08/2014 às 15:26. JERSEY. Em: < Acessado em: 30/10/2014 às 23:30. KALIN, Martin. Java Web Services: Implementando. Rio de Janeiro: Alta Books Editora, p. LOBO, Joana Polónia. Pesonal Medication Advisor. Faculdade de Engenharia da Universidade do Porto FEUP, Porto, Portugal LOPES, Renato Aquino; CARDOSO, Alexandre. Um Sistema de Realidade Aumentada Associado a Dispositivos Móveis para Auxiliar o Preparo, Treinamento e Administração de Medicamentos. Faculdade de Universidade Federal de Uberlândia UFU Uberlândia, MG, Brasil 2012 LOUREIRO, Antônio Alfredo Ferreira et al. Computação Ubíqua Ciente de Contexto: Desafios e Tendências. Anais do XXVII Simpósio Brasileiro de Redes de Computadores e Sistemas Distribuídos (SRBC 09), MADRUGA, Célia Maria Dias; SOUZA, Eurípedes Sebastião Mendonça de. Manual de Orientações Básicas para Prescrição Médica. Conselho Federal de Medicina, João Pessoa, Ideia Editora Ltda. MARAN, Vinícius; PALAZZO, Oliveira. Uma Revisão de Técnicas de Revisão e Persistência de Informações de Contexto e Inferências de Situações em Sistemas Ubíquos. Universidade Federal do Rio Grande do Sul UFRGS, Porto Alegre, RS, Brasil. MARCELO, Alisson. Análise de desempenho da camada de segurança de aplicações DPWS MEDISAFE. Em: < Acessado em: 18/03/2014 às 17:49 MediSafe Project LTD MORAES, João C. et al. Uma Arquitetura Baseada em Agentes Inteligentes para Troca de Mensagens Sensível ao Contexto para o Cuidado de Saúde Pervasivo. Departamento de Computação (DC)-Universidade Federal de São Carlos (UFSCar), São Carlos-SP, MOZILLA. Em: Acessado em 08/11/2014 às 00:00. NETBEANS. Em: < Acessado em: 8/10/2014 às 15:30. NUNES, Mateus Bisotto. Proposta de solução e de método de validação para sistema de visualização de exames em salas de cirurgia OPENEHR. Em: < Acesso em: 30 novembro openehr Brasil. ORACLE. Em: < Acessado em: 08/10/2014 às 15:00.

91 90 ORACLE DOCUMENTATION. Em: < Acessado em: 30/10/2014 às 14:00. PARISE, Mariana T. D.; PARISE, Doglas; MARAN, Vinicius. AMESC - Um Assistente de Administração de Medicamentos Sensível ao Contexto Baseado em Webservices. V STIN - Simpósio de Tecnologia da Informação da Região Noroeste do Estado do Rio Grande do Sul, 2014, Santo Ângelo. ANAIS V STIN, PEPE, Murilo Cesar Procopio Ferreira; MATHIAS, Ivo Mario. Modelagem de um Sistema para Tratamento de Séries Temporais Utilizando a Tecnologia de Redes Neurais Artificiais. XIX Encontro Anual de Iniciação Científica - EAIC. 2010, UNICENTRO, Guarapuava PR. PINTO, Paulo Sergio Bernardo. Webservice: a realidade da computação distribuída como ferramenta de integração entre tecnologias, POSTER. Em: < Acessado em: 06/11/2014 às 22:30. POSTGRESQL. Em: < Acessado em: 30/10/2014 às 19:30. QUINTÃ, André Figueiredo. Integração de sistemas de produção. Universidade de Aveiro Portugal SCHREIER, Günter et al. Design and Evaluation of a Multimodal mhealth based Medication Management System for Patient Self Administration. 35th Annual International Conference of the IEEE EMBS, Osaka, Japan SAUDATE, Alexandre. REST: Construa API's inteligentes de maneira simples. São Paulo: Casa do Código, p. SCHILDT, Herbert; SKRIEN, Dale. Programação com Java: uma introdução abrangente. Porto Alegre: Bookman Editora LTDA, p. SEU REMÉDIO. Em: < Acessado em: 18/03/2014 às 17:30. SILVA, Diogo Francisco Sales da; LOVATTI, Flávio Rodrigo. Computação Distribuída, Web Service um estudo de caso. Centro Universitário Vila Velha, SILVA, Marlos Otávio Corrêa da. Ferramenta interativa para acompanhamento das atividades na web f. Trabalho de Conclusão de Curso (Graduação) Universidade Tecnológica Federal do Paraná, Curitiba, SILVA, Reginaldo F.; CUNHA, José A. Arquitetura de Segurança em Aplicações Baseadas em Web Services. HOLOS-ISSN , v. 3, p , SILVA DE SOUZA, Thiago; PIRES, Paulo de Figueiredo. Tecnologia de Serviços Web: conceitos e aplicações. In: 20º Simpósio Brasileiro de Banco de Dados; 19º Simpósio

92 91 Brasileiro de Engenharia de Software. (Org.). Mini-Cursos do 20º SBBD e 19º SBES p SOTO, Rafael; PABLLO, Cayo; CAMPOS, Jorge A. P. SISMAM: SISTEMA MÓVEL PARA ADMINISTRAÇÃO DE MEDICAMENTOS. In: Congresso Brasileiro de Informática em Saúde, 2008, Campos do Jordão. CBIS'2008 XI Congresso Brasileiro de Informática em Saúde. Campos do Jordão, STRANG, Thomas, POPIEN Claudia Linnhoff. A context modeling survey. Workshop Proceedings SYMEY, Yeo; SANKARANARAYANAN, Suresh; BINTI SAIT, Siti Nurafifah. Application of Smart Technologies for Mobile Patient Appointment System. International Journal, v. 2, n. 4, TANENBAUM, Andrew S.; WOODHULL, Albert S. Sistemas Operacionais: Projetos e Implementação. Grupo A, TIOSSI, Marta; MARIN, Alessandra. Home Care baseado em evidências. UNINGÁ Unidade de Ensino Superior Ingá LTDA., n. 01, p , TOBALDINI, Ricardo Ghisi. Arquitetura REST: um estudo de sua implementação em linguagens de programação. Universidade Federal de Santa Catarina UFSC Santa Catarina, SC, Brasil VENECIAN, Luthiano Rodrigues. Um Mecanismo de Sensibilidade ao Contexto com Suporte Semântico para Computação Ubíqua. Universidade Católica de Pelotas PUC, Pelotas VICENTE, Valter Pedro Lopes. Gestão de medicamentos em dispositivos móveis. Universidade de Aveiro UA Aveiro, Portugal VICENTINI, Caroline Fighera et al. PEHS Arquitetura de um Sistema de Informação Pervasivo para Auxílio às Atividades Clínicas. Revista Brasileira de Computação Aplicada, v. 2, n. 2, p , VIEIRA, Vaninha; TEDESCO, Patricia; SALGADO, Ana. Modelos e Processos para o desenvolvimento de Sistemas Sensíveis ao Contexto. André Ponce de Leon F. de Carvalho, Tomasz Kowaltowski (Org.). Jornadas de Atualização em Informática (2009): VIGOLO, Vander et al. Desenvolvimento de uma plataforma wireless para prescrição médica e verificação de sinais vitais baseado em PDA WORLD WIDE WEB CONSORTIUM (W3C). Em: < Acessado em: 29/10/2014 às 21:00. YANG, Zhemin; YANG, Min. Leakminer: Detect information leakage on android with static taint analysis. Third World Congress on Software Engineering. IEEE, p

93 ZHANG, Xiaojun et al. Developing an Online Patient Appointment Scheduling System based on Web Services architecture,

94 93 APÊNDICE A Códigos SQL do banco de dados Este documento traz os códigos SQL do banco de dados implementado no módulo móvel do sistema AMESC. Criação das tabelas no BD: a) Figura 45 Criação da tabela alarme. b) Figura 46 Criação da tabela dispositivo.

95 94 c) Figura 47 Criação da tabela medicamento. d) Figura 48 Criação da tabela local. e) Figura 49 Criação da tabela restricao.

96 95 f) Figura 50 Criação da tabela local_paciente. g) Figura 51 Criação da tabela medico.

97 96 h) Figura 52 Criação da tabela paciente. i) Figura 53 Criação da tabela pessoa. j) Figura 54 Criação da tabela restricao_medicamento.