coletor de dados para aplicações de saúde baseadas na ...€¦ · oliveira, lucio soares de....
TRANSCRIPT
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
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.