Universidade Federal do Rio Grande do NorteCentro de Ciências Exatas e da Terra

Departamento de Informática e Matemática AplicadaBacharelado em Engenharia de Software

Coletor de Dados para Aplicações de SaúdeBaseadas 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 Baseadasna Infraestrutura de IoT.

Monografia de Graduação apresentada aoDepartamento de Informática e MatemáticaAplicada (DIMAp) da Universidade Federaldo Rio Grande do Norte como requisito a ob-tenção do grau de bacharel em Engenharia deSoftware.

Linha de pesquisa:Engenharia de Software.

Orientador

Prof. Msc. Itamir de Morais Barroca Filho

UFRN – Universidade Federal do Rio Grande do NorteDIMAp – Departamento de Informática e Matemática Aplicada

Natal-RN

Novembro/2018

Oliveira, Lucio Soares de. Coletor de dados para aplicações de saúde baseadas nainfraestrutura 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ênciasExatas e da Terra, Departamento de Informática e MatemáticaAplicada, Curso de Engenharia de Software. Natal, 2018. Orientador: Itamir de Morais Barroca Filho.

1. Engenharia de software - Monografia. 2. Internet dascoisas - Monografia. 3. Interoperabilidade - Monografia. 4.Aplicações de saúde - Monografia. I. Barroca Filho, Itamir deMorais. II. Título.

RN/UF/CCET CDU 004.41

Universidade Federal do Rio Grande do Norte - UFRNSistema de Bibliotecas - SISBI

Catalogação de Publicação na Fonte. UFRN - Biblioteca Setorial Prof. Ronaldo Xavier de Arruda - CCET

Elaborado por Joseneide Ferreira Dantas - CRB-15/324

Scanned with CamScanner

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 Baseadasna 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.

Palavras-chave: Internet das Coisas (IoT) 1, Interoperabilidade 2, Aplicações de Saúde 3.

Data Collector for IoT Infrastructure HealthApplications

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.

Keywords : Internet of Things (IoT) 1, Interoperability 2, Health Applications 3.

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

14 Visão de Uso dos Serviços do coletor de dados . . . . . . . . . . . . . . p. 32

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

35 Tela de visualização dos dados do paciente em tempo real. . . . . . . . p. 44

Lista de tabelas

1 Tabela de artigos analisados . . . . . . . . . . . . . . . . . . . . . . . . p. 24

2 Tabela de requisitos do sistema de monitoramento . . . . . . . . . . . . p. 43

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

JMS – Java Message Service

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. 20

2.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

Internet das Coisas (IoT) . . . . . . . . . . . . . . . . . . . . . . p. 25

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

Referências p. 47

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, saturaçã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 deaplicativos de assistência médica baseados em IoT. Fonte: (BARROCA; AQUINO, 2017a)

Pela variedade de sensores, dispositivos e protocolos de dados existentes, o 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 monitoramento 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;

• Oximetría de Pulso;

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 demonitoramento remoto depacientes.

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 analisadosNome original Nome traduzido Autor AnoMedical 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 Edgefor Global Health: Remote,Monitoring with SeverityDetection and Alerts,Transmission

Base Inteligente Baseadaem IoT para a Saúde Global:Remota, Monitoramento comDetecção e Alertas de Gravidade,Transmissão

Rahul KrishnanPathinarupothi 2018

Proposing an iot-basedhealthcare platformtointegrate patients, physiciansand ambulance services

Propondo uma plataformade cuidados de saúde baseadaem iot para integrar pacientes,médicos e serviços de ambulância

Itamir de MoraisBarroca Filho 2017

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 informaçõ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 eTransmissã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 osterminais. 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 visualizaçã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 emIoT, 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 naestrutura 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 manutenibilidade. Portabilidade, 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.

Figura 14: Visão de Uso dos Serviços do coletor de dados

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 serviç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

Além disso, nessa visão é possível perceber o atributo de qualidade interoperabilidade

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 AuthService, 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 identificação e a caracterizaçã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çãoUC01 Cadastro de pacientesUC02 Visualização do pacienteUC03 Atualização dos dados do pacienteUC04 Deletar pacienteUC05 Monitoramento de Dados em tempo realUC06 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 docoletor de dados.

Figura 34: Código de conexão WebSocket com o componente IotDataCollector

Figura 35: Tela de visualização dos dados do paciente em tempo real.

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 tointegrate patients, physicians and ambulance services. In: Computational Science and ItsApplications. [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. Monitoramentointeligente e sensível ao contexto na assistencia domiciliar telemonitorada. In: Anais doXXVIII 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. HealthcareFinancial 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 ofMedical 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 monitoringwith severity detection and alerts transmission. IEEE INTERNET OF THINGSJOURNAL, 2018.

48

RASPBERRY. RASPBERRY PI 3 MODEL B+. 2018. Disponível em: <https://www.raspberrypi.org/products/raspberry-pi-3-model-b-plus/>. Acesso emOutubro 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.