Universidade Federal do Rio Grande do Norte Centro de Ciências Exatas e da Terra
Departamento de Informática e Matemática Aplicada Bacharelado em Engenharia de Software
Coletor de Dados para Aplicações de Saúde
Baseadas na Infraestrutura de IoT.
Lucio Soares de Oliveira
Natal-RN Novembro/2018
Lucio Soares de Oliveira
Coletor de Dados para Aplicações de Saúde Baseadas
na Infraestrutura de IoT.
Monografia de Graduação apresentada ao Departamento de Informática e Matemática Aplicada (DIMAp) da Universidade Federal do Rio Grande do Norte como requisito a ob-tenção do grau de bacharel em Engenharia de Software.
Linha de pesquisa: Engenharia de Software.
Orientador
Prof. Msc. Itamir de Morais Barroca Filho
UFRN – Universidade Federal do Rio Grande do Norte DIMAp – Departamento de Informática e Matemática Aplicada
Natal-RN
Oliveira, Lucio Soares de.
Coletor de dados para aplicações de saúde baseadas na infraestrutura de IoT / Lucio Soares de Oliveira. - 2018. 49f.: il.
Monografia (Bacharelado em Engenharia de Software)
-Universidade Federal do Rio Grande do Norte, Centro de Ciências Exatas e da Terra, Departamento de Informática e Matemática Aplicada, Curso de Engenharia de Software. Natal, 2018. Orientador: Itamir de Morais Barroca Filho.
1. Engenharia de software - Monografia. 2. Internet das coisas - Monografia. 3. Interoperabilidade - Monografia. 4. Aplicações de saúde - Monografia. I. Barroca Filho, Itamir de Morais. II. Título.
RN/UF/CCET CDU 004.41 Universidade Federal do Rio Grande do Norte - UFRN
Sistema de Bibliotecas - SISBI
Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET
Aos meus pais e à meu irmão, que com muito carinho e apoio, não mediram esforçoes para que eu chegasse até está etapa da minha vida.
Agradecimentos
Primeiramente a Deus que permitiu que tudo isso acontecesse. À minha namorada que sempre esteve ao meu lado. Ao meu orientador, pelo orientação, apoio e confiança e aos amigos e colega, que não negaram força e ficaram na torcida, meu muito obrigado.
Coletor de Dados para Aplicações de Saúde Baseadas
na Infraestrutura de IoT.
Autor: Lucio Soares de Oliveira Orientador: Prof. Msc. Itamir de Morais Barroca Filho
Resumo
O crescimento da população mundial, juntamente com o aumento da expectativa de vida e de indivíduos em condições críticas de saúde, tem requerido maior demanda pela infraes-trutura hospitalar. Por conta disso, a assistência domiciliar pode ser vista como um modo de melhorar o atendimento a estes pacientes, visto que necessitam de cuidados constantes e de grandes períodos de observação. Neste quesito, o uso de tecnologias computacionais inovadoras, como a Internet das Coisas (Iot) poderia ser útil para o acompanhamento remoto da população. Entretanto, devido à variedade de sensores e protocolos existentes, o desenvolvimento de aplicações médicas baseadas nessa estrutura se torna um desafio para implementação e manutenção. Logo, o objetivo deste trabalho é o desenvolvimento de um coletor de dados para aplicações de monitoramento remoto de pacientes baseadas na infraestrutura de IoT a fim de fornecer uma abstração entre sensores e aplicações. Com isso, será possível obter benefícios relacionados à disponibilidade, gerenciamento de dados e interoperabilidade entre os diferentes sensores.
Data Collector for IoT Infrastructure Health
Applications
Author: Lucio Soares de Oliveira Supervisor: Prof. Msc. Itamir de Morais Barroca Filho
Abstract
Global population growth, associated with the increase oferece life expectancy and in-dividuals in critical health conditions, has required a greater demand from the hospital structure. Because of this, home care can be seen as a way to improve care for these pa-tients, since they need constant care and great periods of observation. In this regard, the use of innovative computational technologies, such as the Internet of Things (Iot) could be useful for remote monitoring of the population. However, due to the variety of existing sensors and protocols, the development of medical applications based on this structure becomes a challenge for implementation and maintenance. Therefore, the objective of this work is the development of a data collector for remote patient monitoring applications based on the IoT infrastructure in order to provide an abstraction between sensors and applications. With this, it will be possible to obtain benefits related to the availability, data management and interoperability between the different sensors.
Lista de figuras
1 Nuvens de palavras de tecnologias relacionadas aos padrões e protocolos de aplicativos de assistência médica baseados em IoT. Fonte: (BARROCA;
AQUINO, 2017a) . . . p. 14
2 Passos da Metodologia utilizados no trabalho . . . p. 16
3 Monitor multiparamétrico Omni 612, Fonte: (MEDICAL, 2018) . . . p. 21
4 Exemplo HL7 versão 2 . . . p. 22
5 Estrutura do sistema de monitoramento remoto baseado em IoT, Fonte:
(ZHANG, 2018) . . . p. 25
6 Estrutura do sistema de monitoramento Remoto com Detecção de
Gra-vidade e Transmissão de Alertas, Fonte: (PATHINARUPOTHI, 2018) . . . p. 26
7 Paciente vestindo AIM-Vitals compreendendo nós de sensores ECG e PPG. A imagem também mostra a placa de circuito impresso, a caixa
impressa em 3D e os terminais. Fonte: (PATHINARUPOTHI, 2018) . . . . p. 27
8 Capturas do AIM Smart-edge, mostrando a tela de login do paciente, a visualização de ECG em tempo real e a tela de visualização do
monito-ramento de sinais vitais. Fonte: (PATHINARUPOTHI, 2018) . . . p. 27
9 Arquitetura para a plataforma de assistência médica, Fonte: (BARROCA;
AQUINO, 2017b) . . . p. 28
10 Arquitetura expandida para a plataforma de assistência médica baseada
em IoT, Fonte: (BARROCA; AQUINO, 2017b) . . . p. 28
11 Plataforma de assistência médica, Fonte: (BARROCA; AQUINO, 2017b) . p. 29
12 Visão em camadas do coletor de dados . . . p. 31
13 Visão de decomposisão do coletor de dados . . . p. 31
15 Visão de Componentes e Conectores do coletor de dados . . . p. 33
16 Visão de Componentes e Conectores do Gateway. . . p. 35
17 Visão de Componentes e Conectores do IotDataCollector. . . p. 36
18 Visão das classes implementadas no Gateway . . . p. 36
19 Diagrama de organização dos componentes da camada de Sensores. . . p. 37
20 Conexão dos equipamentos com o Gateway. . . p. 37
21 Classe responsável por iniciar os serviços de sockets. . . p. 38
22 Classe responsável pelo envio dos dados aos demais componentes. . . . p. 38
23 Arquivo responsável pelo cadastro dos dispositivos no componente
Ga-teway. . . p. 39
24 Classe responsável pela autenticação dos dispositivos no componente
Ga-teway. . . p. 39
25 Visão do projeto IotDataCollector. . . p. 40
26 Diagrama de organização dos componentes da camada de Middleware. . p. 40
27 Diagrama de organização dos componentes da camada de Middleware . p. 41
28 Diagrama de organização dos componentes da camada de Middleware . p. 41
29 Classe de identificação dos formatos DataFormatService . . . p. 41
30 Transformação do HL7 em JSON . . . p. 42
31 Exemplo de envido dos dados em tempo real com JMS . . . p. 42
32 Diagrama de caso de uso do sistema de monitoramento . . . p. 43
33 Organização do sistema de monitoramento com os demais componentes
do coletor de dados. . . p. 44
34 Código de conexão WebSocket com o componente IotDataCollector . . p. 44
Lista de tabelas
1 Tabela de artigos analisados . . . p. 24
Lista de abreviaturas e siglas
IoT – Internet das Coisas
EJB‘s – Enterprise JavaBeans
ECG – Eletrocardiograma
PI – Pressão Invasiva
ISA – Indice de sedação anestésica
PNI – Pressão não Invasiva
HL7 – Health Level 7
C&C – Componentes e Conectores
AMQP – Advanced Message Queuing Protocol
Sumário
1 Introdução p. 13 1.1 Problema . . . p. 14 1.2 Objetivos . . . p. 15 1.3 Metodologia . . . p. 15 1.4 Declarações e Contribuições . . . p. 16 1.5 Organização do trabalho . . . p. 16 2 Fundamentação Teórica p. 18 2.1 Java . . . p. 18 2.2 Spring Framework . . . p. 18 2.3 Spring Boot . . . p. 19 2.4 ActiveMQ . . . p. 19 2.5 Apache TomCat . . . p. 19 2.6 Arquitetura em MicroServiço . . . p. 20 2.7 MongoDB . . . p. 202.8 Monitor multiparamétrico Omni 612 . . . p. 20
2.9 HL7 . . . p. 21
2.10 Raspberry PI 3 - Model B . . . p. 22
3 Revisão de sistemas de monitoramento remoto de pacientes. p. 24
3.1 Artigos analisados . . . p. 24
3.1.1 Sistema de monitoramento médico de longa distância baseado na
3.1.2 Base Inteligente Baseada em IoT para a Saúde Global: Monito-ramento Remoto com Detecção de Gravidade e Transmissão de
Alertas . . . p. 26
3.1.3 Plataforma de assistência médica baseada em IoT . . . p. 27
3.2 Análise Comparativa . . . p. 29
4 Coletor de Dados Baseado na estrutura de IoT p. 30
4.1 Requisitos . . . p. 30
4.2 Arquitetura . . . p. 31
4.3 Descrição dos componentes . . . p. 34
4.4 Desenvolvimento . . . p. 35
4.4.1 Gateway . . . p. 36
4.4.2 IoTDataCollector . . . p. 39
4.5 Sistema de Monitoramento Remoto . . . p. 42
5 Considerações finais p. 45
5.1 Trabalhos futuros . . . p. 45
13
1
Introdução
A demanda por serviços de saúde e, por conseguinte, pela infraestrutura hospitalar, tem aumentado com o crescimento da população mundial e o aumento da expectativa de vida (HOCHRON, 2015). Isso se deve pela necessidade de pacientes idosos, indivíduos com doenças crônicas ou em condições críticas de saúde, de longos e detalhados períodos de observação hospitalar. Além disso, deve-se considerar que o custo de serviços de saúde é extremamente elevado (COPETTI J. C. B. LEITE, 2008). Dessa forma, um possível modo de melhorar o atendimento a estes pacientes e de reduzir o número de internações hospitalares é a assistência domiciliar (KOCH, 2006).
O fornecimento dessa assistência pode ser dado pelo uso de tecnologias computacio-nais inovadoras, e com o uso da Internet das Coisas. Nesse contexto, nas aplicações de monitoramento remoto de pacientes são utilizados sensores, com os quais os indivíduos podem ser monitorados continuamente e em qualquer parte de suas residências. Tais dis-positivos podem fornecer dados fisiológicos, como pressão arterial, frequência cardíaca, atividades realizadas pelo paciente (caminhar, dormir e/ou comer) e condições do ambi-ente (temperatura, umidade e ventilação). Através destes dados, os enfermeiros, médicos e/ou cuidadores podem direcionar o tratamento adequado de acordo com a evolução clí-nica do paciente. Em contraposição, para o enfermo, o uso desta tecnologia pode reduzir o número de visitas ao consultório médico e tornar os períodos de hospitalização mais curtos (KINSELLA, 2018).
A Internet das Coisas (IoT ), do inglês Internet of Things , emergiu dos avanços de diversas áreas, tais como sistemas embarcados, microeletrônica, comunicação e sensori-amento. Consiste em uma extensão da internet atual que promove a ligação de objetos do cotidiano com capacidade computacional e de comunicação com a internet (SANTOS, 2016). Dessa forma, a conexão com a rede mundial de computadores viabiliza o controle remoto de objetos. Além disso, permite que os mesmos sejam acessados como provedores de serviços. Estas habilidades propiciam uma ampla utilização tanto no âmbito acadêmico quanto no industrial.
14
Particularmente, na área da saúde, espera-se um amplo desenvolvimento e aplicação do IoT, uma vez que esta tecnologia pode propiciar aos pacientes, melhores tratamentos, e aos hospitais, menores custos e lotação. Neste contexto, o potencial de mudança na qualidade de vida dos indivíduos que pode ser promovido com o uso do IoT é inquestionável. A criação de soluções integradas pode promover uma mudança qualitativa nos serviços em prol de integrar sistemas de informação, computação e comunicação com amplo controle. Dessa forma, há uma necessidade urgente de desenvolvimento de tecnologias e aplicativos relacionados à infraestrutura de IoT para saúde (BARROCA; AQUINO, 2017a).
1.1
Problema
Uma das principais características das aplicações de monitoramento remoto de pa-cientes é o acompanhamento corporal e do ambiente. Para sua realização, utiliza-se um conjunto de diferentes sensores a fim de rastrear o quadro clínico do paciente. Conside-rando o monitoramento corporal, os dados obtidos pelos sensores acoplados são: oxímetro de pulso, frequência cardíaca, pele galvânica, transpiração, atividade muscular, tempera-tura corporal, satempera-turação de oxigênio, pressão arterial, fluxo aéreo, movimento corporal, glicemia, freqüência respiratória e ECG (BARROCA; AQUINO, 2017a). Em relação ao mo-nitoramento do ambiente, são implantados sensores no local onde o paciente se encontra. Estes sensores capturam parâmetros associados à temperatura, SPO2, CO2 e pressão at-mosférica. Para a coleta dos dados emitidos, os protocolos de comunicação utilizados são REST, HTTP, MQTT e CoAP. Por sua vez, os formatos de dados mais utilizados são REST, HTTP, MQTT e CoAP e na questão de formato dos dados os protocolos mais uti-lizados são HL7, XML, EHR, CSV, JSON e PHR (BARROCA; AQUINO, 2017a), conforme apresentados na Figura 1 2.
Figura 1: Nuvens de palavras de tecnologias relacionadas aos padrões e protocolos de aplicativos de assistência médica baseados em IoT. Fonte: (BARROCA; AQUINO, 2017a)
desenvol-15
vimento de aplicações de assistência médica baseados na infraestrutura de IoT apresenta vários desafios como: gerenciamento de dados, interoperabilidade, disponibilidade de re-cursos heterogêneos, segurança, privacidade, quantidade de dados gerados pela captura dos sensores dos aplicativos e formato de dados que não são estruturados. Além disso, a grande quantidade de informações emitidas pelos sensores é extremamente complexa e, por isso, requer diferentes mecanismos de armazenamento para os típicos gerenciamentos de bancos de dados (BARROCA; AQUINO, 2017b).
1.2
Objetivos
Este trabalho tem como objetivo o desenvolvimento de um coletor de dados para apli-cações de monitoramento remoto de pacientes baseadas na infraestrutura de IoT. Este recurso irá proporcionar uma interface de abstração entre os sensores de acompanha-mento clínico e as aplicações de monitoraacompanha-mento remoto. Além disso, irá promover uma padronização entre os diversos protocolos existentes e garantir a interoperabilidade entre diferentes sensores, gerenciamento de dados e disponibilidade. Juntamente a esta finali-dade, tem-se o propósito de:
• Descrever o coletor de dados sob diferentes visões arquiteturais;
• Relatar os requisitos e o desenvolvimento desse coletor.
1.3
Metodologia
A metodologia do trabalho baseou-se em uma pesquisa exploratória com o com a finalidade de desenvolver um coletor de dados para aplicações de monitoramento remoto de pacientes baseadas na infraestrutura de IoT. Para que o objetivo fosse alcançado, foram realizados os passos descritos na Figura 2.
A princípio consistiu na aquisição de conhecimentos através da leitura de artigos cien-tíficos acerca de padrões de sensores e aplicações remotas na área de cuidados em saúde. Posteriormente, realizou-se um estudo sobre as tecnologias usadas na implementação do coletor de dados e na leitura dos padrões utilizados em equipamentos na área da saúde. Em seguida, modelou-se a arquitetura e a organização dos dados obtidos dos equipamentos.
A posteriori, desenvolveu-se o coletor de dados propriamente dito. Por fim, foram feitos testes e validações da aplicação. A parte de homologação da solução foi feita por
16
meio da construção de um sistema que consome e processa os dados adquiridos.
Figura 2: Passos da Metodologia utilizados no trabalho
1.4
Declarações e Contribuições
O trabalho apresentado nesta monografia teve como resultado outras contribuições listadas a seguir:
1. Sistema de monitoramento remoto de pacientes;
2. Padronização de dados dos sensores de monitoramento remoto.
1.5
Organização do trabalho
O presente trabalho é organizado em forma de capítulos. Eles estão ordenados e apre-sentados da seguinte forma:
1. Capítulo 2 apresenta a fundamentação teórica necessária para o entendimento deste trabalho;
2. Capítulo 3 descreve os sistemas que foram analisados quando aplicados no cenário de monitoramento remoto de paciente;
3. Capítulo 4 descreve o coletor de dados baseado na estrutura de IoT, mostra seu desenvolvimento desde a arquitetura até a fase de testes e homologação;
17
4. Capítulo 5 apresenta as considerações finais deste trabalho e trabalhos que poderão ser realizados futuramente a partir deste.
18
2
Fundamentação Teórica
O desenvolvimento de aplicações dependem da utilização de um conjunto de tecnicas e tecnologias para que possa tornar o processo de criação mais rápido e com mais qualidade. Nesta seção são apresentados os principais recursos computacionais utilizados durante o desenvolvimento.
2.1
Java
Java é linguagem de programação base para vários tipos de aplicações e um padrão para desenvolvimento e distribuição dessas aplicações. Inicialmente, foi projetado para o desenvolvimento de aplicações portáteis de alto desempenho. Porém, atualmente, esta tecnologia é usada para o desenvolvimento de jogos, softwares web, softwares corporativos, dentre outros. Os dispositivos desenvolvidos em Java têm a característica de funcionarem em ambientes heterogêneos devido à execução virtual de suas aplicações. O Java possui uma comunidade de 9 milhões de desenvolvedores ao redor do mundo, sendo que essa quantidade incentiva seu uso por conta, principalmente, da quantidade de informações geradas sobre esta tecnologia (ORACLE, 2018)
2.2
Spring Framework
Spring é um framework de código aberto, criado com o intuito de simplificar a pro-gramação em Java. Isso possibilita a construção de aplicações que, antes, só era possível utilizando EJB’s .
Atualmente, possui diversos módulos tais como Spring Data (aborda sobre persistên-cia) e Spring Security (associado à segurança da aplicação). No entanto, o principal (Core) pode ser utilizado em qualquer aplicação Java. Dessa forma, as principais funcionalida-des são a injeção de dependência (CDI) e a programação orientada a aspectos (AOP),
19
cabendo ao desenvolvedor solicitar ao Spring o que quer usar. Tais fatos fazem do Spring uma poderosa ferramente, uma vez que não há necessidade de usar todas as ferramentas do framework para criar uma aplicação simples (SPRING, 2018b).
2.3
Spring Boot
Spring Boot é o ponto de partida para construções de aplicações baseadas no Fra-meWork Spring. Foi projetada para agilizar a criação de API REST, Aplicações Web, entre outros. Seu principal objetivo é facilitar a configuração e aumentar a produtividade do desenvolvedor (SPRING, 2018a).
2.4
ActiveMQ
Apache ActiveMQ é um message broker de código-fonte aberto escrito em Java, junta-mente com um cliente completo de Java Message Service (JMS). A comunicação é gerada com recursos como clusters computacionais e a capacidade de utilizar qualquer banco de dados como um fornecedor de persistência JMS, além de memória virtual, cache, e persistência de logs (ACTIVEMQ, 2018).
Emprega diversos modos de alta disponibilidade, incluindo mecanismos de bloqueio de arquivos e de banco de dados a nível de linha, partilha de armazenamento de persistência (através de um sistema de arquivos compartilhados), e replicação real usando o Apache ZooKeeper. Um mecanismo robusto de escalamento horizontal, chamado de Network of Brokers, também é suportado. O ActiveMQ é celebrado por sua flexibilidade de configu-ração, e pelo seu suporte de um amplo número de protocolos de transporte , incluindo OpenWire, Stomp, MQTT, AMQP, REST e WebSockets (ACTIVEMQ, 2018).
2.5
Apache TomCat
Desenvolvido pela Apache Software Foundation, o Apache Tomcat é um software de código aberto para implementação de Java Servlet, JavaServer Pages, tecnologias Java Expression Language e tecnologias Java WebSocket. O software Apache Tomcat é desen-volvido em um ambiente aberto e participativo, sendo liberado sob licença Apache versão 2. O projeto Apache Tomcat pretende ser uma colaboração dos melhores desenvolvedores de todo o mundo (TOMCAT, 2018).
20
2.6
Arquitetura em MicroServiço
O estilo arquitetural de microsserviço é uma abordagem para desenvolver uma única aplicação como um conjunto de pequenos serviços, cada um executando em seu próprio processo e comunicando-se com mecanismos leves, geralmente uma API de recurso HTTP. Esses serviços são criados com base nos recursos de negócios e implementados de maneira independente por máquinas de implantação totalmente automatizadas. Há um mínimo de gerenciamento centralizado desses serviços, que pode ser escrito em diferentes lingua-gens de programação e usar diferentes tecnologias de armazenamento de dados (FOWLER, 2018).
2.7
MongoDB
MongoDB é um software de banco de dados de código aberto e multiplataforma. Armazena dados em documentos flexíveis semelhantes a JSON, o que significa que os campos podem variar de acordo com o documento e a estrutura de dados pode ser alterada ao longo do tempo. O modelo de documento é mapeado para os objetos no código do seu aplicativo, facilitando o trabalho com os dados. Consultas , indexação e agregação em tempo real fornecem maneiras poderosas de acessar e analisar seus dados (MONGODB, 2018). É um banco de dados distribuído em seu núcleo, de modo que a alta disponibilidade, o dimensionamento horizontal e a distribuição geográfica são integrados e fáceis de usar (MONGODB, 2018).
2.8
Monitor multiparamétrico Omni 612
O Monitor Multiparâmetro é um dos equipamentos mais requisitados na medicina, sendo muito utilizado em hospitais, pronto-socorros e clínicas para auxiliar no monitora-mento do sistema vital dos pacientes.
O Monitor multiparamétrico Omini 612 mostrado na figura 3, tem as seguintes funções de monitoramento (MEDICAL, 2018):
• Eletrocardiograma (ECG );
• Respiração;
21
• Temperatura;
• Segmento-ST;
• Pressão Invasiva (PI );
• Indice de sedação anestésica (ISA );
• Pressão Não Invasiva (PNI ).
Figura 3: Monitor multiparamétrico Omni 612, Fonte: (MEDICAL, 2018)
2.9
HL7
O Health Level 7 (HL7 ) é um protocolo internacional para intercâmbio de dados eletrônicos em todos os ambientes na área da aúde, sendo capaz de integrar informações de natureza clínica e administrativa. Esta iniciativa vem de encontro com a crescente preocupação, na área da Saúde e de Tecnologia da Informação, de buscar soluções que
22
possam integrar os diversos sistemas de informações em Saúde de forma transparente e flexível (INC, 2018).
O padrão HL7 versão 2 tem o objetivo de apoiar os fluxos de trabalho de uma insti-tuição de saúde. Ele define uma série de mensagens eletrônicas para o apoio a processos administrativos, logísticos, financeiros, bem como processos clínicos. As mensagens HL7 são baseada em segmentos (linhas) e delimitadores de um caractere. Os segmentos têm componentes (campos) separados por um delimitador de componentes. Um componente pode ter mais subcomponentes, que, por sua vez, são separados pelo delimitador de sub-componentes. Os delimitadores padrão são a barra vertical ou pipe para o separador de campo, acento circunflexo para o separador de componentes, o caracter e comercial para o separador de subcomponentes. O acento til é o separador de repetição padrão. Cada segmento começa com uma cadeia de 3 caracteres, que identifica o tipo de segmento. Cada segmento da mensagem contém uma categoria específica de informações. Cada mensagem tem um MSH como o seu primeiro segmento, que inclui um campo que identifica o tipo de mensagem. O tipo de mensagem determina os tipos de segmento esperados na mensagem. Os tipos de segmento usados em um determinado tipo de mensagem são especificados pela notação gramatical de segmento utilizado nas normas HL7. Podemos ver um exemplo na Figura 4.
Figura 4: Exemplo HL7 versão 2
2.10
Raspberry PI 3 - Model B
Raspberry Pi 3 Model B+ com homologação Anatel é uma placa extremamente ver-sátil para os mais variados projetos como videogames, servidores de arquivos, câmeras de monitoramento e projetos embarcados. Consiste em um mini-PC que processa distribui-ções Linux, como o Raspbian e Ubuntu. Além disso, suporta outros sistemas operacionais, tais como o Windows 10 IoT e versões customizadas do Linux (RASPBERRY, 2018).
23
A versão B+ da Raspberry Pi 3 tem processador de 1.4GHz, 1GB de memória e atual-mente suporta redes wireless no padrão AC, proporcionando maior velocidade velocidade para a conexão e melhorando a performance da placa (RASPBERRY, 2018).
24
3
Revisão de sistemas de
monitoramento remoto de
pacientes.
Antes de iniciar o desenvolvimento do coletor de dados, que será apresentado no Capítulo 4, foi realizada uma revisão exploratória em artigos cientificos cujo o objetivo estivesse no contexto de monitoramento remoto do quadro clínico dos pacientes. Com isso, foi possível realizar uma análises de arquiteturas e tecnologias que estão sendo utilizadas no desenvolvimento desses sistemas e os principais problemas enfrentados na análise, implementação e implantação dessas aplicações.
3.1
Artigos analisados
Os artigos cientificos utilizados foram aqueles cujo objetivo se aproximou do contexto de monitoramento remoto do quadro clínico dos pacientes. Esses artigos são listados na Tabela 3.1.
Tabela 1: Tabela de artigos analisados
Nome original Nome traduzido Autor Ano
Medical long-distance, monitoring system based, on internet of things
Sistema de monitoramento, médico de longa distância, baseado na internet das,coisas
Weiping Zhang 2018
IoT Based Smart Edge for Global Health: Remote, Monitoring with Severity Detection and Alerts, Transmission
Base Inteligente Baseada em IoT para a Saúde Global: Remota, Monitoramento com Detecção e Alertas de Gravidade, Transmissão
Rahul Krishnan
Pathinarupothi 2018
Proposing an iot-based healthcare platformto
integrate patients, physicians and ambulance services
Propondo uma plataforma de cuidados de saúde baseada em iot para integrar pacientes, médicos e serviços de ambulância
Itamir de Morais
25
3.1.1
Sistema de monitoramento médico de longa distância
base-ado na Internet das Coisas (IoT)
O trabalho proposto por Weiping Zhang (ZHANG, 2018), tem como objetivo permitir que médicos possam monitorar parâmetros físicos do corpo dos indivíduos em tempo real. Seu objetivo foi implementar e avaliar se a rede sugerida era confiável e se a transmissão de dados era precisa. Os pesquisadores analisaram e desenvolveram um sistema de mo-nitoramento remoto médico baseado em IoT. Para que esse sistema pudesse ser feito, foi realizado uma arquitetura de hardware utilizando o protocolo ZigBee, a fim de configurar a rede sem fio dos sensores e efetuar a transmissão das informações dos pacientes. Assim, criou-se um projeto do sistema para a exibição dos dados monitorados.
O projeto de circuito de hardware do componente sensor, componente coordenador e o projeto do programa de softwares são correspondentes. Entre eles, o sensor pode coletar três sinais fisiológicos, como temperatura corporal, pulso e ECG. O sensor forma uma rede sem fio com os componentes de roteamento de do coordenador e, em seguida, as infor-mações obtidas são coletadas e transmitidas ao sistema de gerenciamento de inforinfor-mações. Com isso, os médicos podem visualizar tais dados a qualquer momento (ZHANG, 2018) .
Figura 5: Estrutura do sistema de monitoramento remoto baseado em IoT, Fonte: (ZHANG, 2018)
Os pacientes que estão ativos fora do hospital podem transmitir informações à unidade de atendimento médico depois de ingressarem na rede por meio do sensor usado pelo corpo. É mostrado que o componente de sensor, o de roteamento e o coordenador formam a rede de sensores sem fio e esta,constitui a rede de monitoramento. O centro de acompanhamento também pode realizar a transmissão remota de dados via Internet e redes de comunicação móvel, compartilhando informações com outros centros e expandindo para um sistema de
26
rede de monitoramento de telemedicina com maior alcance (ZHANG, 2018). Essa estrutura é demonstrada na Figura 5.
3.1.2
Base Inteligente Baseada em IoT para a Saúde Global:
Mo-nitoramento Remoto com Detecção de Gravidade e
Trans-missão de Alertas
O trabalho proposto por Rahul Krishnan Pathinarupothi (PATHINARUPOTHI, 2018) tem como foco um sistema de borda inteligente baseado em IoT para monitoramento de saúde remoto. O sistema utiliza sensores vitais que transmitem dados em dois softwares, como o Rapid Active Summarization para alertas eficazes de PROgnosis (RASPRO) e Criticality Measure Index (CMI), ambos implementados na borda inteligente da IoT.
O RASPRO transforma dados de sensores volumosos em resumos clinicamente signifi-cativos chamados Motivos de Saúde Personalizados (PHMs). Neste quesito, o mecanismo de alerta CMI calcula uma pontuação de criticalidade agregada. Na borda inteligente de IoT emprega-se um protocolo de risco, que consiste em um rápido envio de alertas e PHMs com menor esforço de dados sob demanda por meio da nuvem (Figura 6).
Figura 6: Estrutura do sistema de monitoramento Remoto com Detecção de Gravidade e Transmissão de Alertas, Fonte: (PATHINARUPOTHI, 2018)
O sistema descrito foi implementado e validado em uma clínica de média escala. Os mecanismos de alerta RASPRO e CMI do AIM Smart-edge são executados nos seguintes tipos de dispositivos: sistema Android para atender a vários pacientes no mesmo leito ou leitos adjacentes e smartphones dos pacientes que executam o Android. Essas aplicações também fornecem interfaces visuais com o usuário a fim de visualizar os parâmetros de ECG, SpO2, BP e a taxa de pulsação ao vivo a medida que são recebidos dos AIM-Vitals (Figura 7). Dessa forma, foi implementado um aplicativo web que é executado em smartphones e computadores para exibir os alertas aos médicos, como é ilustrado na figura 8.
27
Figura 7: Paciente vestindo AIM-Vitals compreendendo nós de sensores ECG e PPG. A imagem também mostra a placa de circuito impresso, a caixa impressa em 3D e os terminais. Fonte: (PATHINARUPOTHI, 2018)
Figura 8: Capturas do AIM Smart-edge, mostrando a tela de login do paciente, a visuali-zação de ECG em tempo real e a tela de visualivisuali-zação do monitoramento de sinais vitais. Fonte: (PATHINARUPOTHI, 2018)
3.1.3
Plataforma de assistência médica baseada em IoT
O trabalho proposto por Itamir de Morais Barroca Filho (BARROCA; AQUINO, 2017b) tem como objetivo o desenvolvimento de uma plataforma baseada em IoT para integrar pacientes, médicos e serviços de ambulância. Antes do desenvolvimento dessa plataforma o autor realizou análises de revisões sistemáticas na literatura com o objetivo de entender o estado atual e as tendências futuras em sistemas médicos baseados em IoT.
Com base na revisão feita, o autor definiu uma arquitetura para orientar o desen-volvimento da plataforma de assistência médica proposta. A arquitetura é composta de 7 camadas e foi usada no desenvolvimento da plataforma de assistência médica baseada em IoT proposta. As camadas são: requisitos, usuários, sistemas e serviços, middleware, monitoramento, comunicação e pacientes (Figura 9). Cada camada citada constitui um conjunto de tecnologias abordadas como é expresso na Figura 10.
28
Figura 9: Arquitetura para a plataforma de assistência médica, Fonte: (BARROCA; AQUINO, 2017b)
Figura 10: Arquitetura expandida para a plataforma de assistência médica baseada em IoT, Fonte: (BARROCA; AQUINO, 2017b)
A plataforma de assistência médica baseada em IoT é composta por cinco módulos: Casa do Paciente, Infraestrutura de Saúde em Nuvem, Hospital, Casa da Família e Serviço de Ambulância (Figura 11). Esses módulos abordam os requisitos funcionais da solução e trabalham juntos em prol de atingir a meta de monitoramento remoto e assistência médica eficiente para pacientes em estado crítico (BARROCA; AQUINO, 2017b).
O principal objetivo desta plataforma é fornecer monitoramento remoto para paci-entes em situação crítica, e foi desenvolvido considerando a necessidade de transferir a assistência médica do hospital para a casa do paciente. Esta tem o foco de integrar pa-cientes, médicos e serviços de ambulância a fim de promover um melhor atendimento e rápidas ações preventivas e reativas de urgência. Também aborda desafios, como
interope-29
Figura 11: Plataforma de assistência médica, Fonte: (BARROCA; AQUINO, 2017b)
rabilidade, segurança e privacidade. Em relação aos requisitos, esta plataforma possui tem Monitoramento Remoto de Pacientes e Ambiente, Gerenciamento de Dados de Assistência à Saúde do Paciente, Gerenciamento de Condições de Saúde do Paciente e Gerenciamento de Emergência e Crise.
3.2
Análise Comparativa
Após a análise dos artigos escolhidos verificou-se que todos possuíam uma arquitetura e objetivos semelhantes. Estes, utilizavam sensores para coleta de dados acerca do estado clínico do indivíduo e disponibilizavam estas informações por meio de um sistema. Porém não há uma padronização adequada dos dados capturados ou a possibilidade de customizar novos dispositivos, ou seja, adicionar novos sensores, pois, cada novo dispositivo exige que haja uma mudança diretamente no código da aplicação, o que dificulta a atualização de tecnologias e implantação de novos sensores. Por esses motivos, um dos objetivos deste trabalho é facilitar na comunicação entre os dispositivos e as aplicações, viabilizando a customização e a troca dos sensores sem afetar os sistemas, assim, agregando o atributo de qualidade de interoperabilidade nas aplicações de saúde.
30
4
Coletor de Dados Baseado na
estrutura de IoT
Conforme apresentado na introdução, este trabalho teve como o objetivo o desenvol-vimento de um coletor de dados baseado na estrutura de IoT voltado para aplicações de monitoramento remoto de pacientes, que pode proporcionando uma interface de abstração entre os sensores de acompanhamento do quadro clínico e as aplicações de acompanha-mento. Para atingir este propósito do projeto, este capítulo apresenta os requisitos do coletos de dados, a arquitetura da aplicação, a descrição dos componentes, o desenvolvi-mento dos módulos e sua implantação.
4.1
Requisitos
O coletor de dados baseado na estrutura de IoT se propõe facilitar o desenvolvimento de novos sistemas de monitoramento remoto de pacientes, realizando uma abstração da comunicação dos sensores de coleta de dados e das aplicações desenvolvidas. Conforme analisada problemática abordada na Introdução, existem diversos sensores, protocolos e de comunicação e formatos de dados. Essa amplitude de dados leva à uma série de difi-culdades no desenvolvimento de aplicações médicas, tais como, gerenciamento dos dados, interoperabilidade, disponibilidade, segurança, dentre outros.
Considerando essas informações, os requisitos levantados para o desenvolvimento do coletor de dados são: facilidade na integração de novos sensores (Interoperabilidade), alta disponibilidade dos dados (Disponibilidade), gerenciamento da grande quantidade de informações geradas e padronização das informações.
31
4.2
Arquitetura
Levando em consideração os requisitos elicitados para o coletor de dados para aplica-ções de saúde baseadas na Infraestrutura de IoT, projetou-se uma arquitetura do sistema e dos componentes presentes a fim de auxiliar no desenvolvimento e manutenção da aplica-ção. Os estilos arquiteturais usados foram: em camadas e em micro-serviço. Além disso, a organização dos componentes foi feita em três camadas, que foi baseado na arquitetura da plataforma de assistência médica (BARROCA; AQUINO, 2017b). As camadas apresentadas são: Sensores, Middleware, e Quality Attributes, demonstradas nas Figura 12 e 13.
Figura 12: Visão em camadas do coletor de dados
Figura 13: Visão de decomposisão do coletor de dados
Através da separação em camadas, o coletor de dados obtém os atributos de portabili-dade e manutenibiliportabili-dade. Portabiliportabili-dade, pois permite que ele seja portável para qualquer
32
aplicação que se comunique com a camada de middleware. A manutenibilidade, pois al-terações que sejam necessárias de serem feitas, podem ser realizadas facilmente, afetando minimamente as demais camadas. Alterações em camadas superiores não afetam as infe-riores, pois estas não dependem das camadas acima.
Na figura 13, é apresentada a visão de decomposição do coletor de dados, em que, além das camadas e os componentes (mostrados na figura 12), são apresentados os serviços da aplicação. A importância desta visão está na simplicidade em demonstrar os componentes deste coletor, fragmentados em serviços. Isso é feito sem mostrar as relações presentes entre eles, que deve ser o foco de visões posteriormente criadas a partir da decomposição. Os serviços presentes no componente de Devices foram escolhidos de acordo com os sensores disponíveis para o desenvolvimento do projeto.
Para a arquitetura do coletor de dados, também observou-se a importância da repre-sentação através da visão arquitetural de "Uso"dos serviços e de Componentes e conecto-res.
Na visão de "Uso dos serviços"representada na Figura 14, as informações que são relatadas na decomposição estão associadas com as dependências entre elas. A leitura da relação é entendida como depends-on, se uma seta de estereótipo "uses"é transmitido de um serviço para outro. Vale salientar que esta visão não apresenta o fluxo de dados entre os serviços, mas apenas as dependências entre eles, as quais obedecem às definições de permissão de uso da visão de camadas.
33
As dependências se iniciam pelo componente de Gateway, o qual depende dos dispo-sitivos, que estarão coletando informações do ambiente e do paciente, e de serviços da Quality Attributes. Internamente ao Gateway, existe dependência entre os serviços: o ser-viço de Network é necessário para os serser-viços de Filter e de Data Receive, que também depende do Filter. Por último, o serviço de DataSend, que depende apenas do Data Re-ceive. Além disso, o Filter Service, depende dos serviços de Authorization, e o DataReceive depende de todos os serviços do componente de interoperabilidade (Driver, DataFormat e Discovery). O componente IotDataCollector, por ser a "porta de entrada"da camada de Middleware, depende do componente de Gateway, pois o serviço de Data Receive do IotDataCollector depende do serviço de Data Send do Gateway. Em seguida, temos o Data Receive como dependência do Data Persist, e ele e do Transformation Data, que é dependência do IoTDataSend. Ainda, o DataReceive depende dos serviços de Driver e Authorization, e o TransformationData depende do DataFormat.
Os serviços da camada de Quality Attributes, por ser cross-cutting, apresentam asso-ciação de dependência com os serviços das demais camadas.
A visão de Componentes e Conectores, apresentada na Figura 15, apresenta os com-ponentes conectados de acordo com o fluxo de dados entre eles, informando os tipos de dados que trafegam na plataforma e as interfaces de comunicação entre os componentes. Esta visão foi construída a partir das visões de Uso e Decomposition, de forma que a comunicação entre os componentes seguem as regras estabelecidas nestas duas visões. A justificativa desta visão é possibilitar a visualização de como os dados devem entrar e sair de cada componente, e promover mais clareza nos aspectos técnicos que eles deverão ser considerados no momento da implementação.
Figura 15: Visão de Componentes e Conectores do coletor de dados
34
na comunicação entre os dispositivos e o componente de Gateway, que permite a comu-nicação com tipos de dispositivos diferentes, ou seja, fluxos de dados diferentes. No que diz respeito ao fluxo de dados apresentado nessa visão, ele se inicia com os dispositivos enviando os dados na forma bruta (HL7 V2.6 e JSON) para o Gateway. O Gateway em-pacota os dados, define os cabeçalhos dos pacotes e os envia para o IotDataCollector. O IotDataCollector vai receber os pacotes de dados, persisti-los e tratá-los, de forma de promover uma interface de saída dos dados.
4.3
Descrição dos componentes
Nesta seção será apresentada as visões de componentes e conectores e sua descrição a partir da perspectiva interna dos componentes, que são apresentados na Figura 15. É importante salientar que os serviços nas visões específicas dos componentes possuem estereótipos («stereotype») que representam os serviços do Coletor de dados, os quais eles estão implementando.
A Figura 16 apresenta a visão de Componentes e Conectores (C&C ) do compo-nente Gateway, este artefato é responsável pela captura dos dados brutos emitidos pelos equipamentos de monitoramento e enviá-los para o artefato IotDataCollector. Esta visão apresenta em detalhes o fluxo de dados entre os serviços internos do componente de Ga-teway. Com esta visão percebe-se o atributo de qualidade de segurança com a existência do AuthService, que trata da autenticação e autorização dos dispositivos conectados ao Gateway.
O fluxo de dados se inicia com os dados (HL7 V2.6 e JSON) dos dispositivos entrando no Gateway, passando primeiramente pelo NATService sem sofrer alteração e seguindo para o RawDataService. Por sua vez, o RawDataService utiliza os serviços de Filter-Service, DeviceDiscoveryService e o AuthFilter-Service, para realizar suas operações de filtro, identificação de dispositivo de origem dos dados, e autenticação/autorização dos disposi-tivos, respectivamente. Em seguida, os dados vão para o serviço de Drivers, que classifica os dados de acordo com o dispositivo de origem. Finalmente, os dados seguem para o RawDataSendService, que é responsável por enviar os dados para o IotDataCollector.
A Figura 17 apresenta a visão detalhada de componentes e conectores do IotData-Collector, que é o artefato responsável por receber os dados do componente Gateway e fazer o entendimento sintático dessas informações e transformalos para um formato co-nhecido. Nesta visão é possível perceber que, além das informações dos tipos de dados
35
Figura 16: Visão de Componentes e Conectores do Gateway.
de entrada e saída deste componente, tem-se o fluxo de dados entre os serviços que o compõem. Iniciando o fluxo, o DataReceiveService se apresenta como o serviço de mais responsabilidade, pois ele se comunica com os serviços de AuthService para realizar au-tenticação/autorização das origens dos dados e DataPersistService para persistir os dados brutos empacotados no componente Gateway. Seguindo o fluxo, o TransformationService é responsável por transformar (ou converter, parsear) o RawData em IoTData, que possui a sintática do contexto dos dispositivos. Para realizar esta transformação, o Transforma-tionService utiliza do DataFormatService, que funciona como um dicionário, auxiliando na tradução do RawData. Por fim, o fluxo é finalizado com o IoTDataSendService, res-ponsável por enviar os IoTData para uma interface de saída dos dados referentes ao monitoramento do paciente e do ambiente.
4.4
Desenvolvimento
Os componentes do projeto foram pensados desde sua arquitetura para terem um baixo nível de acoplamento e interdependência entre eles, além disso, manutenibilidade, escalabilidade e flexibilidade. Por esses motivos eles foram desenvolvidos baseados na arquitetura de microservices. No desenvolvimento do projeto foi utilizado um Monitor Multiparamétrico Omni 6122 e um E-Health Shield para o monitoramento dos dados do paciente. Como acréscimo, para o monitoramento do ambiente, foi utilizado um Raspberry PI 3 - Model B com sensores de temperatura e umidade do ar.
36
Figura 17: Visão de Componentes e Conectores do IotDataCollector.
4.4.1
Gateway
Este artefato é responsável por realizar a captura dos dados dos equipamentos de monitoramento e enviá-los ao componente IotDataCollector e foi desenvolvido utilizando a linguagem de programação JAVA 8 com o Frameword Spring boot. Podemos visualizar a organização das classes do serviço na figura 18, e a organização dos componentes na Figura 19 está disposto na infraestrutura da plataforma a partir do Raspberry PI 3 -Model B.
Figura 18: Visão das classes implementadas no Gateway
O Gateway foi configurado na infraestrutura da plataforma a partir do Raspberry PI 3. O equipamento possui duas interfaces de rede, uma conectada a uma rede que viabiliza o acesso externo para a internet e outra conectada à sub-rede em que estão
localiza-37
Figura 19: Diagrama de organização dos componentes da camada de Sensores.
dos os dispositivos de coleta de dados. Dessa forma, esse dispositivo possui a capacidade de comunicação com ambas as redes, o que permite a captura de dados provenientes dos dispositivos de monitoramento e o posterior envio desses dados para o artefato Iot-DataCollector, disponibilizado em uma infraestrutura web, podemos visualizar melhor a organização do componente Gateway com os demais equipamentos na figura 20 .
Figura 20: Conexão dos equipamentos com o Gateway.
Para a captura dos dados dos equipamentos, foi necessário verificar os protocolos envolvidos utilizados no envio dos dados. Dessa forma, verificou-se que o Monitor mul-tiparamétrico Omni 6122 envia os dados do monitoramento através da interface de rede com os dados no formato HL7, e os dispositivos E-Health Shield e Raspiberry PI disponi-bilizam os dados coletados no formato JSON. E para a coleta dos dados desses dispositivos
38
foi implementado sockets.
Figura 21: Classe responsável por iniciar os serviços de sockets.
A implementação das portas de conexão para a captura de dados foi realizada por meio do componente DataReceiver que disponibiliza sockets nas seguintes portas: 2575/tcp (Omni 6122) e 5000/tcp (e-HealthShield). Assim, após a efetivação da conexão através dos sockets que é realizada através da classe Loader como mostra na figura 21, o com-ponente Driver, que possui capacidade de entender em nivel sintatico cada protocolo em específico, é acionado para a consolidação da captura dos dados. Esse componente conhece as especificidades de cada protocolo e implementa as rotinas necessárias para a adequada captura dos dados. No Gateway, esses componentes são implementados por métodos nas classes DriverEHealth e DriverHL7. Uma vez esses dados capturados, eles são enviados através do componente RawDataSender para o artefato IotDataCollector como mostra a figura 22.
Figura 22: Classe responsável pelo envio dos dados aos demais componentes.
Para a autorização de conexão com o Gateway, foi implementado o componente Autho-rization, que possui um método que realiza controle de acesso e autorização para o
es-39
tabelecimento de conexão dos equipamentos. Essa autorização é realizada através de um pré-cadastro de ip dos dispositivos conectados., sendo assim, toda conexão realizada no Gateway é verificado se o dispositivo está preveamente cadastrado, como mostra nas fi-guras 23 e 24.
Figura 23: Arquivo responsável pelo cadastro dos dispositivos no componente Gateway.
Figura 24: Classe responsável pela autenticação dos dispositivos no componente Gateway.
4.4.2
IoTDataCollector
O artefato IotDataCollector é responsável por receber os dados enviados pelo Gateway, persisti-los em um banco de dados não relacional e, em seguida, transformá-los para um formato conhecido e disponibilizá los através de uma interface para outras aplicações. Este artefato foi desenvolvido utilizando a linguagem de programação JAVA 8 com o Framework Spring Boot. Podemos verificar a organização do projeto do IotDataCollector nas Figuras 25 e 26. Na figura 26 todos os dados enviados para o IotDataCollector passam antes por um Broker. Esta abordagem foi utilizada a fim de escalabilidade, desempenho, disponibilidade e confiabilidade.
O sistema utilizado para desempenhar o papel do Broker foi o Apache ActiveMQ, que consiste em um message broker de código-fonte aberto escrito em JAVA. O Acti-veMQ é conhecido por sua flexibilidade de configuração, e o seu suporte para um número relativamente grande de protocolos de transporte, incluindo OpenWire, Stomp, MQTT, AMQP, REST e WebSockets. Para a aplicação foi utilizado o protocolo Advanced Message Queuing Protocol (AMQP ).
40
Figura 25: Visão do projeto IotDataCollector.
Figura 26: Diagrama de organização dos componentes da camada de Middleware.
Os dados enviados pelos componente de Gateway são publicados em um tópico no bro-ker e disponibilizados para o IotDataCollector. Uma vez que o Framework Spring Boot foi utilizadono desenvolvimento, o mesmo pode proporcionar facilidade na conexão e con-figuração para o ActiveMQ. Para isso, basta adicionar a dependência no projeto e fazer a configuração da conexão como mostrados nas figuras 27 e 28. Após a configuração da
41
conexão do broker o IotDataCollector já está preparado para monitorar e receber as in-formações enviadas pelo Gateway. Uma vez recebidos, os dados são persistidos no banco de dados não relacional, o banco que está sendo utilizado é o MongoDB, em seguida os dados são enviados para o componente TransformationService que realiza a transforma-ção dos dados brutos a partir da identificatransforma-ção e a caracterizatransforma-ção de diferentes formatos (HL7, JSON, entre outros), realizado pelo componente DataFormatService, como mostra na figura 29. Essa transformação resulta em um objeto JSON padronizado, podemos en-tender melhor essa transformação observando a Figura 30, que mostra a transformação de um dado em HL7 v2 para um formato JSON. Após a transformação, o componente IoTDataSendService disponibilizará as informações do paciente já padronizadas por meio de uma interface de monitoramento em tempo real com o JMS (Figura 31).
Figura 27: Diagrama de organização dos componentes da camada de Middleware
Figura 28: Diagrama de organização dos componentes da camada de Middleware
Figura 29: Classe de identificação dos formatos DataFormatService
O Componente IotDataCollector que é responsável pela realização do requisito de interoperabilidade do sistema, pois é capaz de identificar os diferentes tipos de formatos de dados disponibilizados pelos sensores e transformá los em uma única estrutura. Isso é possível pela abstração da complexidade aos demais componentes.
42
Figura 30: Transformação do HL7 em JSON
Figura 31: Exemplo de envido dos dados em tempo real com JMS
4.5
Sistema de Monitoramento Remoto
Para teste e validação dos componentes Gateway e IotDataCollector implementados nos tópicos anteriores, foi desenvolvido um sistema web de monitoramento remoto de pacientes que consome os dados disponibilizados pelos sensores disponíveis no Monitor Multiparamétrico Omni 612 e no E-Health Shield por meio do IotDataCollector.
O sistema teve os seguintes requisitos elicitados como mostra na Tabela 2 e no dia-grama de caso de uso mostrado na figura 32. Porém como o foco do sistema é a validação dos componentes do Coletor de Dados, o requisito principal é o US05, sendo assim ele foi o foco do desenvolvimento do sistema. Para isso, utilizou-se a linguagem de programação JavaScript e JAVA 8 com o Framework Spring Boot de modo que sua organização foi demonstrada na Figura 33.
Os dados que estão sendo monitorados no paciente são fornecidos pelos dois equipa-mentos referentes aos aspectos clínicos utilizados no desenvolvimento deste projeto. Tais informações foram dadas pelo Monitor Multiparamétrico Ommi 612 (ECG e SPO2) e pelo
43
Tabela 2: Tabela de requisitos do sistema de monitoramento
Código Descrição
UC01 Cadastro de pacientes UC02 Visualização do paciente UC03 Atualização dos dados do paciente UC04 Deletar paciente
UC05 Monitoramento de Dados em tempo real UC06 Read health data report
Figura 32: Diagrama de caso de uso do sistema de monitoramento
E-Health Shield (oximentria de pulso, temperatura corporal e saturação de oxigênio).
Para o requisito de monitoramento de Dados em tempo real foi implementado uma página web para facilitar a visualização dos dados que representam a condição de saúde do paciente monitorado, tornando possível o seu acompanhamento remoto pela equipe médica.
A conexão do sistema de monitoramento com o Coletor de dados é realizada através de WebSocket implementado em JavaScript, o sistema faz a conexão inicial com o IotDa-taCollector para receber os dados de um determinado paciente, se a conexão for permitida pelo IotDataCollector o sistema ficará monitorando uma rota específica referente ao pa-ciente como mostra na figura 34.
Pela facilidade da utilização da conexão websocket com publish subscribe, todo dado publicado pelo IotDataCollector na rota monitorada pelo sistema de monitoramento re-moto, a aplicação automaticamente será informada que à uma informação nova do paci-ente, assim realizando as informações na página web disponibilizada para a visualização dos dados pelos usuários, como mostra na figura 35.
44
Figura 33: Organização do sistema de monitoramento com os demais componentes do coletor de dados.
Figura 34: Código de conexão WebSocket com o componente IotDataCollector
45
5
Considerações finais
Neste trabalho, foi desenvolvido um coletor de dados em prol de facilitar o desen-volvimento de aplicações de monitoramento remoto de pacientes. Tal fato permitiu uma abstração entre os sensores, as aplicações de monitoramento e o sistema web de monito-ramento remoto de pacientes. A arquitetura do coletor foi pensada e desenhada levando em consideração os requisitos elicitados para o coletor após uma análise dos principais problemas enfrentados no desenvolvimento do sistema de monitoramento remoto.
Os requisitos elicitados para o coletor de dados baseado na infraestrutura de IoT foram: (i) interoperabilidade, a fim de, facilitar a integração de diferentes tipos de sensores sem afetar as aplicações de monitoramento remoto; (ii) disponibilidade, pois, como trata-se de um sistema com alto nível de criticidade, precisa estar funcionando constantemente; (iii) gerenciamento dos dados, já que o tráfego de informações disponibilizadas pelos sensores é demasiada. A interoperabilidade, especificamente, foi demonstrada pela conexão de dois equipamentos distintos de monitoramento que não afetavam o comportamento dos demais componentes do sistema. Além disso, desenhou-se a arquitetura do IoTDataCollector a fim de facilitar a evolução do componente e aceitar outros tipos de equipamentos com formato de dados diferentes.
Durante o desenvolvimento deste projeto, foi possível aplicar conhecimentos em várias áreas da Engenharia de Software, pois, durante sua execução, foi necessária análise de requisitos, desenvolvimento da arquiteturas e de componentes do coletor de dados.
5.1
Trabalhos futuros
O propósito de desenvolver um coletor de dados baseado na infraestrutura de IoT para sistema de monitoramento remoto foi criar uma abstração entre os sensores e suas respectivas aplicações. Assim, aumentou-se a interoperabilidade dos diferentes tipos de equipamentos e a disponibilidade das informações. Porém, ainda é possível desenvolver
46
componentes para evoluir o coletor de dados e deixá-los mais robusto. Tais componentes são:
• Monitor de detecção de falhas: A função do monitor é realizar a verificação da disponibilidade e coletar dados de monitoramento de infraestrutura de aplicações e equipamentos. Além disso, este componente deverá enviar alertas ao usuário em casos de falhas e, em determinadas situações, agir de forma proativa executando comandos para a recuperação de serviços e aplicações em estado de falha;
• Inteligência: Monitor responsável pela aplicação de regras de inferência dos dados de modo que possam ser semanticamente compreendidos e apresentem informações relevantes sobre o estado de saúde de um paciente.
Com esses componentes, pode-se melhorar questões associadas com segurança, disponibi-lidade e tolerância à falha do coletor de dados. Além disso, como projetos futuros, pode-se evoluir o sistema do coletor de dados em IoT para um Middleware para a área da saúde.
47
Referências
ACTIVEMQ. Apache ActiveMQ. 2018. Disponível em: <https://pt.wikipedia.org/ wiki/Apache_ActiveMQ>. Acesso em Outubro 20, 2018.
BARROCA, I. de M.; AQUINO, G. S. de. Iot-based healthcare applications: A review. The 2017 International Conference on Computational Science and Its Applications, 2017.
BARROCA, I. de M.; AQUINO, G. S. de. Proposing an iot-based healthcare platform to integrate patients, physicians and ambulance services. In: Computational Science and Its Applications. [S.l.]: ICCSA, 2017. p. 188–202.
COPETTI J. C. B. LEITE, O. L. T. d. P. C. B. A. C. L. d. N. A. Monitoramento inteligente e sensível ao contexto na assistencia domiciliar telemonitorada. In: Anais do XXVIII Congresso da SBC. [S.l.]: SBC, 2008. p. 166–180.
FOWLER, M. Microservices. 2018. Disponível em: <https://martinfowler.com/ articles/microservices.html>. Acesso em Outubro 20, 2018.
HOCHRON, P. G. S. Driving physician adoption of mheath solu- tions. Healthcare Financial Management, 2015.
INC, H. Sobre o HL7. 2018. Disponível em: <http://www.hl7.com.br/sobre-hl7/>. Acesso em Outubro 07, 2018.
KINSELLA. The home telehealth primer. Telemedicine information exchange. 2018. Disponível em: <https://informationfortomorrow.com/HomeTelehealthPrimer. htm>. Acesso em Outubro 07, 2018.
KOCH, S. Home telehealth—current state and future trends. International Journal of Medical Informatics, 2006.
MEDICAL, V. Monitor Omni 612. 2018. Disponível em: <http://vitamedical.com. br/2020/Equipamento/MonitorOmni612_5/>. Acesso em Outubro 07, 2018.
MONGODB. About MongoDB. 2018. Disponível em: <https://www.mongodb.com/ what-is-mongodb>. Acesso em Outubro 20, 2018.
ORACLE. About Java. 2018. Disponível em: <https://www.java.com/pt_BR/about/>. Acesso em Outubro 20, 2018.
PATHINARUPOTHI, R. K. Iot based smart edge for global health: Remote monitoring with severity detection and alerts transmission. IEEE INTERNET OF THINGS JOURNAL, 2018.
48
RASPBERRY. RASPBERRY PI 3 MODEL B+. 2018. Disponível em: <https: //www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/>. Acesso em Outubro 07, 2018.
SANTOS, L. A. M. S. B. P. Internet das Coisas: da Teoria à Prática. [S.l.], 2016.
SPRING. About Spring Boot. 2018. Disponível em: <https://spring.io/projects/ spring-boot>. Acesso em Outubro 20, 2018.
SPRING. About Spring Framework. 2018. Disponível em: <https://spring.io/ projects/spring-framework>. Acesso em Outubro 20, 2018.
TOMCAT, A. About Apache Tomcat. 2018. Disponível em: <http://tomcat.apache. org/>. Acesso em Outubro 20, 2018.
ZHANG, M. K. W. Medical long-distance monitoring system based on internet of things. EURASIP Journal on Wireless Communications and Networking, 2018.
