Machine Translated by Google

Saúde e Tecnologia https://

doi.org/10.1007/s12553-023-00753-3

PAPEL ORIGINAL

Saúde digital em cidades inteligentes: repensando a arquitetura

de monitoramento remoto de saúde combinando edge, nevoeiro e nuvem

Vinicius Facco Rodrigues1 Rodrigo da Rosa Righi1 Cristiano André da Costa1 Felipe André Zeiser2
Bjoern Eskofier2 · Andreas Maier3 · Daeyoung Kim

Recebido: 22 de fevereiro de 2023 / Aceito: 6 de abril de 2023

© O(s) Autor(es) sob licença exclusiva da União Internacional de Ciências Físicas e de Engenharia em Medicina (IUPESM) 2023

Abstrato

Propósito As cidades inteligentes que apoiam a execução de serviços de saúde estão cada vez mais em evidência hoje. Aqui, é comum usar dados de
sinais vitais baseados em IoT para servir uma arquitetura multicamadas. O estado da arte propõe a combinação de edge, fog e computação em nuvem para
dar suporte eficiente a aplicações críticas de saúde. Porém, até onde sabemos, as iniciativas normalmente apresentam as arquiteturas, não trazendo
adaptações e otimizações de execução para atender plenamente às demandas de saúde.
Métodos Este artigo apresenta o modelo VitalSense, que fornece uma arquitetura hierárquica de monitoramento remoto de saúde multicamadas em cidades
inteligentes, combinando computação de borda, neblina e nuvem.
Resultados Embora utilizemos uma composição tradicional, nossas contribuições aparecem no tratamento de cada nível de infraestrutura. Exploramos a
compactação adaptativa de dados e a criptografia homomórfica na borda, um mecanismo de notificação multicamadas, rastreabilidade de saúde de baixa
latência com fragmentação de dados, um mecanismo de execução sem servidor para suportar múltiplas camadas de névoa e um mecanismo de
descarregamento baseado em prioridades de computação de serviços e pessoas.
Conclusões Este artigo detalha a lógica por trás desses tópicos, descrevendo casos de uso do VitalSense para serviços de saúde disruptivos e insights
preliminares sobre a avaliação de protótipos.

Palavras-chave Saúde digital · Cidade inteligente · Monitoramento remoto da saúde · Internet das coisas · Fog computing · Edge computing

1. Introdução
* Rodrigo da Rosa Righi
rrrighi@unisinos.br
Nos últimos anos, o setor saúde entendeu que a Internet pode ser um
Vinicius Facco Rodrigues
viniciusf@unisinos.br instrumento de apoio essencial na busca por melhor qualidade de vida e
melhores condições de atendimento ao paciente [1, 2 ]. Entre outras
Cristiano André da Costa
cac@unisinos.br vantagens associadas à utilização da Internet na área da saúde, destacam-
se a análise e processamento de dados em tempo real através de servidores
Felipe André Zeiser
remotos. Um modelo eficiente capaz de fornecer armazenamento e
felipez@unisinos.br
processamento de aplicações pela Internet é o conceito de computação em
Bjoern Eskofer
nuvem [2]. Esse modelo pode ser descrito como um serviço prestado por
bjoern.eskofer@fau.de
grandes data centers que oferecem parte de sua infraestrutura – hardware
Andreas Maier
andreas.maier@fau.de e software – a terceiros (empresas e pessoas físicas) e organizações
públicas. Ao adquirirem este tipo de serviço, esses clientes terão recursos
Daeyoung Kim
kimd@kaist.ac.kr computacionais com capacidade crescente sem a necessidade de
investimentos significativos de capital financeiro para adquirir, manter e
1
Applied Computing Graduate Program, Universidade doÿVale gerenciar tais recursos.
doÿRio dos Sinos (UNISINOS), SãoÿLeopoldo,
Brasil

2
Universidade Friedrich Alexander Erlangen-Nürenberg (FAU),
A computação em nuvem é o principal suporte para habilitar os
Erlangen, Alemanha
aplicativos da Internet das Coisas (IoT). Os ambientes IoT são compostos
3
Instituto Avançado de Ciência e Tecnologia da Coreia
por centenas ou milhares de dispositivos que
(KAIST), Daejeon, Coreia do Sul

Vol.:(0123456789) 1 3
Machine Translated by Google

Saúde e Tecnologia

gerar constantemente solicitações de dados coletados para posterior
análise. No contexto do Healthcare 4.0 [3], a Internet of Health Things
(IoHT) representa a disseminação de dispositivos IoT aplicados a
aplicações de e-saúde [4]. Este processo naturalmente gera solicitações
pesadas enviadas a um servidor de processamento central, inundando a
rede desse servidor e exigindo um poder computacional que um único
computador muitas vezes não seria capaz de fornecer [5]. Aqui, a
computação em nuvem pode ser usada como meio de processamento
para cenários de IoT para aproveitar sua escalabilidade e modelo de
pagamento conforme o uso. No entanto, o envio de solicitações de um
dispositivo IoT para um servidor em nuvem adiciona sobrecarga de
latência de rede à comunicação que não pode ser aceita em alguns
casos. Por exemplo, podemos citar alguns cenários de e-health, como
aqueles que abordam o eletrocardiograma (ECG) remoto, onde os
tempos de coleta e processamento de dados são críticos para o correto
funcionamento do sistema. Muitas vezes não podemos esperar que uma
mensagem seja enviada, processada na nuvem e devolvida, pois o tempo
envolvido nesses procedimentos pode influenciar aspectos essenciais
de aplicações de tempo crítico [5, 6] . Além disso, mesmo com um
ambiente de computação em nuvem altamente escalável, escalá-lo para
atender a muitas solicitações resultaria em consumo adicional de energia.
Para permitir uma melhor escalabilidade dos sistemas IoT, é
necessário projetar novas arquiteturas e soluções que permitam lidar
com muitos dispositivos e solicitações simultaneamente, mantendo a
Qualidade de Serviço (QoS) [7]. Alinhado com esta frase, nevoeiro
a computação expande os serviços oferecidos pelo modelo tradicional de
nuvem para estar mais próximo dos geradores de dados [8, 9]. Além
disso, a edge computing entra aqui para permitir algum processamento e
suporte à decisão precisamente na fronteira da rede, ou seja, perto do
próprio dispositivo IoT. A computação em nevoeiro ou edge tem como
principais características baixa latência, melhor suporte para coletar a
distribuição geográfica de dados e mobilidade sobre um grande número
de nós na rede. Assim, com acesso predominantemente sem fio, temos
a execução de aplicações em tempo real e um suporte mais significativo
à heterogeneidade dos dispositivos.
Os dados lidos pelos sensores são coletados, processados e armazenados
em um banco de dados temporário em vez de serem entregues na
nuvem, evitando atrasos de ida e volta no tráfego de rede.
Uma combinação de nuvem, neblina e borda é especialmente
pertinente para fornecer uma arquitetura que responda à pesquisa em
saúde e pandemia, como o caso da doença por Coronavírus (COVID-19)
[10]. Mais significativamente, estamos a entrar num período em que a
investigação sobre a longa duração da COVID-19 é dominante.
O objetivo é monitorar continuamente os sinais vitais dos contaminados
pelo vírus com antecedência [11]. No monitoramento remoto da saúde, a
maioria dos sistemas de monitoramento de sinais vitais segue uma
arquitetura generalizada de três camadas composta por dispositivos de
detecção, gateways de neblina e nuvem [12] (ver Fig. 1 (a)).
Ao analisar as iniciativas atuais na literatura, elas não abordam todas as
questões concomitantemente da seguinte forma: (i )

Dados
Dados
Análise de dados processamento e Análise de dados
Dados agregação
Dados e Dados transferir com e
agregação e
aquisição tomando aquisição análise de dados tomando
e transferência transferir com
uma decisão e tomada de uma decisão
análise de dados
decisão

Nuvem Borda Névoa Nuvem

Informática Informática: Informática Informática
computadores
de placa única,
Do utilizador smartphones, Do utilizador

Interface etc. Interface

Dispositivos IoT:
Painéis Dispositivos IoT:
Painéis

sensores, sensores,
Gateway IoT
atuadores, atuadores,
ou
relógios inteligentes, Artificial relógios inteligentes, Artificial Artificial Artificial
Rede IoT
bandas inteligentes, bandas inteligentes,
Inteligência Inteligência Inteligência Inteligência
etc. etc.

Alertas e Alertas e Alertas e Alertas e

Notificações Notificações Notificações Notificações

Saúde Alertas e Saúde Saúde Saúde

Serviços Notificações Serviços Serviços Serviços

Latência Latência

(a) (b)

Figura 1 Comparação entre estratégias tradicionais (a) de monitoramento da saúde e VitalSense (b). Aplicativos podem acessar serviços de saúde de qualquer lugar

13
Machine Translated by Google
Saúde e Tecnologia
rastreabilidade e privacidade, tanto em termos de visão histórica de sinais
vitais como de locais visitados numa cidade inteligente; (ii) inteligência
artificial para executar serviços de saúde de forma proativa, gerando valor
para os usuários finais, além de hospitais e setor público; (iii) mecanismos
de última geração para abordar QoS, capacidade de processamento elástico
e um sistema de notificação de mensagens eficiente e escalável.
Neste contexto, este artigo apresenta o VitalSense como uma nova
arquitetura de cidade inteligente que combina edge, fog e cloud para
gerenciar dados históricos de saúde dos cidadãos, atuando principalmente
no combate ao COVID-19. A Figura 1 (b) demonstra a abordagem
VitalSense, onde contamos com uma topologia de neblina hierárquica e um
mecanismo de computação distribuído distribuído junto com as três camadas
envolvidas. Hospitais, indivíduos através de dispositivos vestíveis, residências
e determinados locais das cidades dependeriam de sensores e leitores para
que sinais vitais e dados de geolocalização fossem coletados para servir de
insumo aos serviços de saúde. O resultado traz benefícios tanto para o setor
público quanto para os próprios cidadãos da cidade inteligente. No
VitalSense, por exemplo, prevemos que o sistema possa chamar
proativamente uma ambulância para a casa de uma pessoa específica,
levando em consideração o processamento baseado em IA de dados
históricos de sinais vitais. Além disso, dados históricos em tempo real nos
permitem gerar dashboards para verificar o grau de propagação do vírus
SARS-CoV-2 (síndrome respiratória aguda grave coronavírus 2) pelos locais
que uma determinada pessoa visitou e analisar a eficácia das ações de
quarentena . Embora utilizemos uma composição tradicional de edge, fog e
cloud, nossas contribuições aparecem na forma como lidamos com cada
nível de infraestrutura. Em detalhes, nossa adição à literatura é uma
arquitetura de monitoramento remoto de saúde que explora:
• Compressão adaptativa de dados e criptografia homomórfica na borda;
• Um mecanismo de notificação multinível;
• Rastreabilidade de integridade de baixa latência com fragmentação de dados;
• Mecanismo de elasticidade de execução sem servidor envolvendo múltiplas
camadas de nevoeiro com um mecanismo de offloading baseado em
prioridades de computação de serviços e pessoas;
• Painéis de controle geográficos ao vivo para visualização de dados.
O restante deste artigo apresenta primeiro o trabalho relacionado na
Seção 2. Aqui, fornecemos discussão da literatura, destacando oportunidades
de pesquisa não cobertas até o momento. Em segundo lugar, a Seção 3
apresenta o Modelo VitalSense, descrevendo sua arquitetura, processos e
algoritmos. Terceiro, a Seção 4 é responsável por discutir os serviços de
saúde e os casos de uso. Esta seção mostra os serviços de saúde para o
futuro e como eles se adaptam à arquitetura de borda, nevoeiro e nuvem
proposta. Por fim, a Seção 5 conclui o artigo, destacando nossas conquistas
para melhorar a qualidade de vida dos cidadãos em todo o mundo.
2. Trabalho relacionado
Esta seção apresenta os principais artigos da literatura no âmbito do
monitoramento remoto em saúde, descrevendo suas principais características
(Tabela 1). A seguir, Seção 2.1
descreve detalhadamente cada artigo e a Seção 2.2 discute as principais
conclusões.
2.1 Estado da arte
O estado da arte atual apresenta diversos artigos com foco no monitoramento
remoto dos sinais vitais dos pacientes. Em geral, a computação em nuvem é
comumente empregada em tais soluções combinadas com edge ou fog [12–
21]. No entanto, alguns exploram estratégias diferentes sem empregar a
nuvem [22, 23]. Sicari et al. [22] propõem um sistema de monitoramento
residencial de quarentena composto por sensores IoT e rastreamento por
Sistema de Posicionamento Global (GPS). O primeiro objetivo é coletar e
analisar sinais vitais de acordo com limites pré-definidos gerando alertas.
Além disso, o sistema realiza monitoramento por GPS para rastrear se o
paciente sai de sua área de quarentena. A proposta não se concentra em
nenhum parâmetro de QoS e depende apenas das redes da Internet e do
Sistema Global para Comunicações Móveis (GSM). Li et al. [14] propõem um
sistema de monitoramento remoto que rastreia a deterioração da frequência
respiratória em pacientes com COVID-19. Os autores apresentam uma
técnica não invasiva de estimativa da frequência respiratória usando WiFi.
Ele transmite dados para a nuvem para monitoramento do paciente e
acionamento de alertas.
Rahman et al. [13] propõem uma estrutura para coletar e analisar dados
fisiológicos de pacientes remotamente. O sistema emprega sensores
vestíveis e um smartphone executando o aplicativo desenvolvido para coletar,
processar e postar dados na nuvem. Além disso, o sistema utiliza a
localização de cada paciente de acordo com seu endereço. O paciente deve
iniciar manualmente o processo de coleta e análise conforme protocolo
definido. Al Bassam et al. [15] propõem um dispositivo vestível no pulso
equipado com sensores de temperatura, saturação de oxigênio (SpO2),
frequência cardíaca e som, fornecendo dados remotos para monitorar e
gerenciar possíveis pacientes infectados por COVID-19. A estratégia usa um
microcontrolador para enviar dados para um back-end em nuvem. De acordo
com as leituras, o sistema pode gerar alarmes de e-mail e mensagens curtas/
serviço de mensagens (SMS). Além disso, um aplicativo móvel permite a
visualização dos dados dos pacientes rastreados.
Paganelli et al. [16] apresentam uma arquitetura conceitual para
monitoramento remoto de pacientes com COVID-19. A arquitetura considera
a aquisição de dados dos usuários em domicílio e em enfermarias médicas.
Os autores definem uma arquitetura de três camadas na qual gateways
móveis e estáticos conectam a camada IoT com uma camada de distribuição
de dados através de um corretor de mensagens.
13
 Tabela
amargeod
aa
ia
d
irid
cró
aan
itcla
ciê
)ab)o
rC
Gu
,ía
i)rd
pq
C
R
tF
irsee
aE
V
F
elre
dcv(rf

13
o.ocfe
noR
A
F
d levíN
ssiaiantiiS
v acincéT SoQ

-
otnem
91e
a-trD
o
n
ote
Ito
2V
in
im
cm
]O
22
oae
0oe
2
m
C
P2cr[
d ,2O,A
C
R
T
pSB
P
F ad,rToobI otnoeãmçarz,o
,sille
ta
einu
tio
im
sa
eM
oip
dvil

otnema
sae.S
trrtM
esa
P lG
A
S
er

otnemarootsto
s2iinaim
]a3
2 one
0te
1
M
id
2vsr[ ,2O
C,F
T
pVB
S m
,aed,vrTu
oon
bI seanl,:a
rso
,s,usn
yeh
rtia
a
e e
o
rp
rdosw
n
o
itvta
ciso
rsu
íe
nim
a
tndsnq
stm
a eê
a
earcA
S
rg
escvt
d aicnêtal

.erto
and
sheso
n
lm
isio
td
m
a
reraada
tvçtuctatp
iío
n
rlsciau
n
o
m
f-m
esirésiL
ge
ae
oxe
rM
lre
acvrt
p
d
Machine Translated by Google

-
otnemaroosttso
2iinaim
]a2
2 one
0te
1
M
id
2vsr[ m
,,2,eG
O
gv,,T
H
R
C
P
u
T
poN
d R
SI
B
E

,otnoeetn
m
neoe
sa
am
yh
ve
ts;.ia
neim
e
p
d
sratsrw
ase
o m
ta
o
nU
o
sreistca
e
cld
m
a
en
io
á
d
rvn
iC
ro
tn
m
lia
apo
e
n
ucsáru
M
lA
Ora
ocsvft
u
g
e
d
p
n

-
otnem
91e
a-trD
o
noteIto
1V
in
im
cm
]O
2R
4
oae
0oe
1
m
C
R
P2cr[
d m
,ae
dvrouB
n oaãaisrivcósinto
im
aêdm
ru
,sn
iipF
qiatsa
n sisW
e eE
ru
drtf

oãça.,zm
silaaeaturvresu
alie
pv
n
a

-
otnem
91e
a-trD
o
noteIto
1V
in
im
cm
]O
25
oae
0oe
1
m
C
P2cr[
d meg,,d
2aeu
O
tsg,n,o
T
R
sT
peoloC
d H
B
S
E
dcIt sosm
rsete
ie
ro
m
ceve
sdíâtneúsrere
uoS
a qsvf
p
d
e

rodaso
loeãrõçton;çavso
da
ezio
m
.tscim
risa
od
la
io
;o
aucS
e r/a
rtrild
ud
o
q
irvm
cM
rlP
a
en
p
sa
fi-n
d
u
n
o
e m
lG
U
iA
S
nvsI
o
a
e
g
p
d

-
otnem
91e
a-trD
o
noteIto
1V
in
im
cm
]O
26
oae
0oe
1
m
C
P2cr[
d ,2O,A
C
R
T
pPB
S
F
e m
,aed,vrTu
oon
bI rodae
lon
aro
rtsn
uhe
ao
tp
erdce
so
a
t,da
o
re
iodstua
,lm
re
g,d
a
sú
nq
cm
o
T
m
ldo
ê
uo
a
eirlo
m
C
A
E
S
rd
FnscIt
q
u

amargoidrac)o
GrC
teEle( otnesm
n
s.;o
so
ea
sm
;yxvsg
e
tm
sia
eia
m
e
rtsw
sa a
o
lcte
m
so
pssitca
e
cn
lm
en
m
b
d
rnio
rT
tm
e
lasa
uore
p
e o
m
lrp
O gcisrftI
e
u
a
d

otnemaroosttso
1iinaim
]a7
2 one
0te
1
M
id
2vsr[ aicnê,2ouO
sq,lA
T
pe
uS
P
Brp
df a,iogsra
ernte
a

,sedea
m
o
snsdo
h
ão
;e
.a
m
o
ied
tçm
ld
htso
a;ritam
p
sa
io
nm
a
é
secga
e
te
atro
o se
blioa
rtu
e cfa
in
d
o
m
rcvisro
u
tse
m
aa
óca
g
u
n
e
o se
rlaliB
rp
nscvrt
e
a
o
d

oãçaacriun
re
so
tuu1
odsm
r2
]ú
dnt8s0
a1E
o
e dsc-[
2
,am
neil,bvTu
eonI otnemaaigeaéchnta
nla
eiog
larb
ectrlse
asE
u
n bc
d
q
e
n aicnê,arei,cafsndanêrxa
e
tard
ptl

otn,oeaãm
i,rçoáaraãi,an
d
m
tçcse.e
ar;m
scm
e
a zs,isga
ze
o
ge
pa
oeilu
eg
arclã
m
an
m
áved
d ro
gsrcru
gtoe
n
e
a ru
onln
ocirfli
d
e
p
a

-
otnemaroosttso
0iinaim
]a9
2 on0
m ete
1
M
i2
dvsr[
e ,2O,A
C
R
pPS
F m
,aed,vrTu
oon
bI enoshepre
so
a
trodstaedú
nm
le
aoS
dsc

od.m
o;neã
he
adrçtsstda
oa
;iom
e
snm
osdcçem
g ee
ato
se
ile
nd
avce
m
iprn
dvtro
u
a
tm
e
vaesa
usrlím
e
o
n lD
iB
ra
gscvt
n
o
u
d
p
e
Saúde e Tecnologia
Machine Translated by Google

Saúde e Tecnologia

rede. A arquitetura compreende um kit IoT composto por um microcontrolador

e um transceptor de rádio para conexão ao gateway mais próximo.

Rahmani et al. [23] propõem um gateway inteligente na rede -

-
SoQ

-
aicnêtal
borda do trabalho para coletar, processar e transmitir dados para a nuvem. Ele
fornece vários serviços, incluindo compactação, filtragem, segurança, análise
de dados e fusão. O principal objetivo é gerar notificações, priorizar dados
críticos e diminuir o volume de dados, reduzindo assim a latência no envio de
dados para a nuvem. Pacientes em movimento alteram o acordo do gateway
base -
indo para a cobertura. Sahu et al. [12] propõem uma arquitetura de três níveis
para monitoramento de sinais vitais. Os autores empregam uma unidade
microcontroladora (MCU) conectada a vários sensores corporais.
Ele extrai dados deles e os transmite para um aplicativo de smartphone via
Bluetooth. O aplicativo pode fornecer análise de dados e alarmes para
medições de sensores. O sistema -
tem também pode enviar dados para um servidor em nuvem usando uma
conexão com a Internet; entretanto, o foco principal da proposta é o
eslaG
A
S
er
ileK
B
S
E
u
g
p
L
e
sr(

olS
q
p
d
a
n
e
irf
c
s
eB

u
dtre
rtm
no
a

trrtM
e

tsrero
u
n
e
a

P
em
nrLb
u
a

m
vre
rd
spwg

m ig
e
q
á
d
vin
srva
e

a
sflã

otnemsaae.S
E

iva
e
t)titiro

te
u
o
ia
ae
w
n

ip
sçrsog
g
;o

rçzsc
e
d
rco

m
ua
c
oa

;tm
ya

,e
oa
ga

e
a
s.o

o
çsnd
e
ayrte

sm
a
se

sçãmn
ço
n,hh
hocdra

:a
.ãoa

processamento local e alarmes.

,otne,om
oço
m
otnoesãn hídrza
sayvo
sod rm
to
p
iud ,iiaw te
,ln
b
lo xm
ercisre
oa n
a tin
u
rd ism
m
tu
tilóo ertM
pa
no iA
e
g
a
d
p
cfl
is
v

Sangeetha et al. [19] propõem um sistema de monitoramento remoto de

saúde para áreas rurais que compreende a entrega de medicamentos por
meio de drones. A estratégia consiste em um smartphone adquirir dados de
sensores de saúde e enviá-los para um servidor em nuvem através da Internet.
Os serviços de análise de dados processam dados na nuvem e geram alertas
quando identificam anomalias -
oon
bI

aoE
pI
d
a
levíN

me,vTuonI
,aed,vrTu

rm
,T
bg
eeiâ do
m

soerttenm

malidades. Dependendo da gravidade, cuidadores, médicos ou serviços de

ambulância podem ser alertados. Mukherjee et al. [17] propõem uma estrutura
edge-fog-cloud para IoHT que prevê as condições dos pacientes e gera alertas.
Eles desenvolveram um fluxo de trabalho que coleta dados de uma rede de
área corporal (BAN) usando um dispositivo de borda e encaminha dados para
nós de neblina. Noti-
As modificações e o processamento posterior ocorrem somente quando o
processamento de neblina identifica anormalidades.
Chudhary e Sharma [18] propõem um quadro de névoa-nuvem -
ssiaiantiiS
v

pES
P
B
F

TBe
R
O,C
A
T

P
,2,G

trabalho para IoT compreendendo quatro camadas: coleta de dados, névoa,

nuvem e aplicação. Os nós de nevoeiro processam dados localmente para
fornecer um tempo de resposta mais rápido enquanto retransmitem dados para
a nuvem quando o processamento local não é necessário. Por sua vez, a
camada de aplicação fornece uma interface para os usuários acessarem os
dados processados das camadas de nuvem e de neblina. Aziz et al. [21]
propõem um sistema de monitoramento em tempo real para rastrear a pressão
arterial e a temperatura corporal de pacientes remotos.
A solução depende da conectividade GSM para enviar alertas a um servidor
remoto quando as leituras dos sensores violam limites predefinidos. Em
seguida, o servidor back-end retransmite as mensagens para o celular do
médico. Além disso, o sistema anexa dados de GPS aos alertas para que a
equipe médica possa enviar um

ambulância, se for o caso. Priambodo e Kadarina [20] detalham um

monitoramento remoto do paciente COVID-19 para rastrear SpO2, frequência
cardíaca e localização do paciente. Um smartphone funciona como um gateway
m
C
P2
d
cr[

M
id
2
sr[
v

M
i2
d
sr[
v
2

Tabela
2

2
oe

0te

ete
nR
Fd
a

oae
0

one

on0
]2O
0

]a3

]a1
cm

im

im
cfeo

im

1
8iina

6iina
in
0V
o.o

Ito

o
tts

tts
ote

otnemaroos

otnemaroos

para coletar dados de sensores, anexar identificações -

a-trD
91e
otnem n
o

informações de navegação e GPS e, em seguida, transmiti-las para um controle remoto

13
Machine Translated by Google
servidor. Por sua vez, o servidor remoto emprega Logstash, Elasticsearch
e Kibana para processamento de dados para que os médicos possam
analisar os dados dos pacientes.
2.2 Discussão
Como mostra a Tabela 1 , a maioria dos artigos concentra-se no
monitoramento de sinais vitais em geral [12, 13, 17, 19, 21, 23] ou em
pacientes com monitoramento de COVID-19 [14–16, 20, 22]. Comumente,
visam monitorar sinais vitais como: (i) temperatura corporal (BT); (ii) pressão
arterial (PA); (iii) saturação de oxigênio no sangue (SpO2); (iv) frequência
cardíaca (FC); (v) frequência respiratória (FR); (vi) variabilidade da frequência
cardíaca (VFC); e (vii) eletrocardiograma (ECG). A IoT desempenha um
papel crítico nessas estratégias, pois elas dependem de pequenos
dispositivos sensores móveis. Além disso, a maioria dos autores emprega
diferentes níveis de computação em suas soluções, combinando tecnologias
de ponta ou de nuvem com dispositivos IoT.
Embora benéfica, a computação em névoa aparece em apenas dois
artigos [17, 18] como uma solução para melhorar o desempenho de tais
sistemas. As soluções podem se beneficiar de unidades de processamento
de dados mais próximas fornecidas pelo nevoeiro, melhorando o tempo de resposta.
aumentar significativamente o desempenho.
Aplicações críticas do domínio da saúde requerem processamento rápido e
atrasos excessivos podem comprometer a sua finalidade. A literatura atual
carece de uma proposta que explore o nevoeiro em tais cenários para
melhorar o tempo de resposta em situações críticas. Isso leva à pesquisa
atual que combina nevoeiro com IoT, edge e nuvem para melhorar o tempo
de resposta.
3 O modelo VitalSense
VitalSense visa fornecer um sistema de monitoramento de saúde em larga
escala e em tempo real para cidades inteligentes. Sua principal característica
é o emprego de nevoeiro e borda para fornecer processamento próximo de
dados para pacientes e administradores de saúde. Ele também emprega a
nuvem para agregação e análise de dados. Como o processamento de
dados está no limite, os usuários se beneficiam de um tempo de resposta
rápido, essencial para aplicações médicas. A utilização da monitorização
remota da saúde pode melhorar significativamente a prestação de serviços
de saúde à população. Nos cuidados de saúde tradicionais, os pacientes
visitam um centro médico para exames de saúde periódicos ou para tratar
problemas de saúde. Tal cenário mostra a reatividade do sistema público de
saúde que exige a ação do paciente diante de um problema repentino para
a prestação de serviços de saúde. VitalSense oferece uma abordagem
proativa na prestação de serviços de saúde, independentemente das ações
do paciente.
Além do monitoramento de sinais vitais, o VitalSense também inclui
rastreamento de movimento das pessoas. Sistemas de localização em tempo
real (RTLS) [24] podem integrar a arquitetura injetando informações de
rastreamento de pessoas na borda da arquitetura.
O RTLS melhora a compreensão dos padrões de movimento e da exposição
a locais de risco, fornecendo informações de posicionamento interno e
externo. Atualmente, existem vários
13
Saúde e Tecnologia
Tecnologias RTLS para diferentes objetivos dependendo da precisão
necessária, incluindo identificação por radiofrequência (RFID), banda
ultralarga (UWB) e GPS. VitalSense depende de portais urbanos RFID que
podem rastrear quando uma pessoa acessa ou sai de uma determinada
região. Os dados adquiridos nos portais geram informações que podem dar
suporte a diversos serviços. Por exemplo, a monitorização de multidões é
crucial para a monitorização de pandemias e controlo de perigos.
Acompanhar os movimentos das pessoas de região para região ajuda a
monitorizar a sua exposição a danos potenciais. Portanto, a administração
pública pode agir antecipadamente quando situações críticas estiverem
propensas a acontecer.
Com conceitos como IoT, Big Data e Indústria 4.0 (I4.0) [25] tornando-se
onipresentes nas indústrias, incluindo as de e-saúde, o crescimento
exponencial de dados temporais gerados por sensores IoT provavelmente
continuará. Esses dados são vitais para as empresas; analisá-lo e agir de
acordo com os resultados pode otimizar a qualidade da produção, economizar
energia e melhorar a qualidade de vida dos cidadãos usuários finais. Porém,
ao analisar quantidades tão grandes de dados, temos uma tendência de
estressar o computador e a rede. Neste contexto, ao selecionar protocolos
de transferência mais eficientes, uma aplicação baseada em IoT pode
Como o artigo expõe, ao projetar o tráfego de dados em uma cidade
inteligente, podemos lidar com o tráfego excessivo de rede que poderíamos
facilmente evitar se o middleware enviasse apenas o número de pontos de
dados necessários. Em resumo, percebemos na literatura científica que hoje
não existe uma solução capaz de otimizar o tráfego de dados IoT sem
esforço e ao mesmo tempo alcançar uma representação de dados sem
perdas. Normalmente, as abordagens compactam dados no lado do servidor
enquanto os descompactam no lado do cliente. Essa ideia sofre com a
calibração do overhead referente às atividades de compressão e
descompressão e dos possíveis ganhos de tempo de transmissão, além de
modificações principalmente do lado do cliente.
Nossa proposta de compressão de dados reside no limite.
A ideia principal é enviar dados de sinais vitais para o nevoeiro de acordo
com o estado da pessoa e os serviços contratados.
Por exemplo, podemos enviar dados para o nevoeiro com mais frequência
para bebés ou idosos. Além disso, se detectarmos alguma complicação de
saúde no limite (como os dados coletados estiverem fora dos limites
predefinidos para um tipo específico de sinal vital) ou se uma pessoa
específica tiver uma doença crônica ou estiver se recuperando de tratamento
médico, podemos manter uma alta frequência na transmissão de dados edge-
fog. Porém, pessoas saudáveis e de meia idade podem trabalhar com
períodos de transmissão mais elevados sem comprometer a detecção de
problemas de saúde. É importante ressaltar que a frequência de transmissão
é adaptada por pessoa, sendo dinâmica junto com o funcionamento da
arquitetura.
3.1 Arquitetura
I4.0 trouxe recentemente vários sensores IoT para o mundo real que os
hospitais agora podem empregar em serviços de saúde, chamados
Machine Translated by Google

Saúde e Tecnologia

Saúde 4.0. VitalSense se baseia nesses conceitos para construir uma árvore na qual os nós pais agregam informações dos nós filhos para
arquitetura capaz de coletar dados de pacientes independentemente da produzir conhecimento da região.
localização. A Figura 2 apresenta a arquitetura VitalSense composta por Finalmente, a camada de nuvem fornece uma plataforma central que
três camadas: borda, neblina e nuvem. Os indivíduos na periferia da rede agrega dados de toda a implantação. Os serviços em nuvem empregam
usam sensores de saúde prontos para uso para monitorar seus sinais uma infraestrutura mais robusta para a análise profunda dos dados. Além
vitais durante as atividades diárias. VitalSense apresenta Edge Controllers disso, os administradores de saúde têm uma visão mais ampla de
para capturar dados de sensores que fornecem processamento, diversas regiões na camada de nuvem. Isso permite soluções capazes
transmissão e feedback de dados. Edge Controllers são dispositivos de identificar zonas de risco e surtos de doenças o mais rapidamente
colocados próximos a sensores capazes de alcançá-los para extrair possível. VitalSense pode dimensionar seus serviços usando infraestrutura
dados. Por exemplo, um Edge Controller pode ser um smartphone ou em nuvem para obter elasticidade de recursos. Portanto, ele suporta uma
um computador de placa única instalado na casa do usuário. arquitetura crescente onde mais nós de neblina podem ser integrados à
solução.
Na camada de neblina, os nós de neblina distribuídos geograficamente Ao implantar a arquitetura VitalSense, algumas tecnologias podem
oferecem uma infraestrutura próxima de processamento de dados. Os garantir segurança de dados e QoS. Links de rede dedicados podem
nós Fog fornecem diversos serviços de saúde, fornecendo notificações fornecer redes privadas para permitir a comunicação ponta a ponta entre
para Edge Controllers e produzindo relatórios para administradores públicos. os módulos da arquitetura.

Em contraste com os Edge Controllers, que não se comunicam entre si, Além disso, as redes privadas fornecem canais de comunicação mais
os nós de nevoeiro podem trocar dados e descarregar o processamento confiáveis, melhorando a QoS. O uso de Multi-Protocol Label Switching
de dados [26]. Além disso, os nós de neblina formam uma hierarquia (MPLS) [27] e Wide Definido por Software

Notificação Armazenamento de dados Sem servidor e contêineres Filtragem e agregação Descarregamento de dados Criptografia de dados Painéis e visualização

Painéis para visualização de dados

Recursos em nuvem
MEVUN

Recursos em nuvem

Nó de nevoeiro

Fragmentação
AOVÉN

Nó de nevoeiro

Mecanismo sem servidor,

elasticidade do recipiente,
e descarregamento de processos
Nó de nevoeiro Nó de nevoeiro Rastreabilidade

Notificação
Nó de nevoeiro Nó de nevoeiro

Compressão de dados e
homomórfico
criptografia

Borda Borda Borda Borda

ADROB

Controlador Controlador Controlador Controlador

aicnêtaL

aicnêtaL

Movendo-se Movendo-se

(a) (b)

Fig. 2 Arquitetura tradicional de neblina a versus projeto de arquitetura b do VitalSense empregando borda, neblina e nuvem

13
Machine Translated by Google
A rede Area (SD-WAN) [28] pode suportar QoS ao trabalhar em um
ambiente de rede compartilhada. Os provedores de nevoeiro podem
empregar tais tecnologias no nível da rede para fornecer estratégias
dinâmicas de QoS de acordo com as necessidades.
3.1.1 Camada de borda
A camada de borda compreende vários sensores que coletam dados de
pessoas e do meio ambiente. Esses sensores podem monitorar sinais
vitais e transmiti-los ao VitalSense. Os indivíduos podem usar um sensor
para monitorar diversos parâmetros de saúde durante as atividades
diárias. A tecnologia sem fio permite a extração e coleta de dados sem
exigir que o indivíduo descarregue os dados manualmente. O VitalSense
coloca nesta camada o módulo Edge Controller responsável pela coleta
de dados. Tal módulo também fornece pré-processamento de dados
antes de transmiti-los para as camadas superiores, permitindo o
fornecimento próximo de serviços aos usuários por meio da geração de
alertas tanto para os usuários quanto para as camadas superiores.
Gerenciar dados pessoais é sempre um desafio em relação à
privacidade no mundo IoT. Atualmente, o Regulamento Geral de
Proteção de Dados1 (RGPD) define vários critérios para reforçar o
controlo e os direitos dos indivíduos sobre os seus dados. VitalSense
aborda isso propondo uma topologia de rede robusta que coloca os Edge
Collectors como pontos de entrada conectados diretamente aos sensores.
Assim, pode fornecer serviços de criptografia de dados na fronteira da
rede protegendo os dados dos usuários. Em particular, esta camada
emprega criptografia assimétrica (RSA 2048) para transferir dados para
o nevoeiro. Além disso, VitalSense não coleta informações de
identificação e apenas transmite dados anonimizados para o sistema.
Ao se cadastrar para utilizar o sistema, a VitalSense exige que o titular
consinta para o tratamento de seus dados. VitalSense gera um código
hash exclusivo para cada indivíduo rotular os dados sem transmitir
informações de identificação junto com eles.
A Figura 3 detalha a operação da camada de borda, incluindo a
arquitetura do Edge Controller. Na parte inferior, o Edge Controller
fornece um middleware de sensor capaz de se conectar a sensores por
meio de três estratégias diferentes: (i) assinar fluxos de dados; (ii) coletar
dados utilizando APIs de sensores; (iii) ou extrair dados de aplicativos
de fornecedores. O middleware fornece dados brutos dos sensores para
o módulo de processamento de dados. Os dados provenientes dos
sensores fluem em duas fases paralelas diferentes.
Primeiro, os Edge Controllers devem preparar os dados antes que
possam ser transmitidos ao nevoeiro. Nesta fase, o módulo filtra, agrega,
compacta e criptografa diversas amostras de dados.
Por um lado, a filtragem, a agregação e a compactação reduzem a
quantidade de dados, melhorando o desempenho da rede.
Por outro lado, a criptografia garante a proteção dos dados.
1 mensagens: (i) notificações; (ii) dados do serviço;
https://gdpr.eu/
13
Saúde e Tecnologia
Durante a segunda fase, o Edge Controller gera notificações utilizando
serviços leves. Ele analisa amostras de dados brutos empregando
algoritmos de previsão, correlação e classificação. O módulo de
notificação gera notificações com base na saída dos serviços.
Dependendo do hardware do Edge Controller, ele pode realizar ações
de notificação, como acender um LED, exibir uma mensagem na tela ou
enviar uma mensagem para um serviço de rede.
A conexão do Edge Controller com a camada fog ocorre em um
modelo bidirecional de publicação-assinatura. Primeiro, o Edge Controller
publica dados no fog por meio de um servidor Message Queu-ing
Telemetry Transport (MQTT) no qual os nós do fog se inscrevem. Em
segundo lugar, o Edge Controller assina fluxos de dados do nevoeiro
para ouvir notificações. O protocolo de conexão entre essas camadas
ocorre através de um processo de handshake. Os Edge Controllers não
sabem qual nó de neblina devem conectar. Os nós de nevoeiro alcançam
primeiro os Edge Control-lers para informar uma nova conexão. O
módulo Fog Connector lida com a nova conexão e se conecta à
notificação
Servidor MQTT deste nó fog específico. Portanto, uma vez que um nó
de nevoeiro se conecta para ler dados, o Edge Controller também escuta
notificações deste novo nó de nevoeiro.
3.1.2 Camada de neblina
A camada de neblina compreende vários nós distribuídos geograficamente
(nós de neblina) responsáveis pelo processamento de dados da borda e
pelo fornecimento de serviços para as camadas de borda e de nuvem.
Os nós de nevoeiro formam o núcleo da arquitetura, uma vez que
processam dados de sensores aplicando diferentes algoritmos para
análise de dados. Os resultados dessa análise podem gerar notificações
para componentes de borda ou de nuvem. Além disso, os nós de
nevoeiro residem perto da borda da rede, o que reduz o atraso na
comunicação, melhorando o tempo de resposta. A Figura 4 mostra uma
arquitetura de nó fog e os módulos que a compõem.
Os nós Fog fornecem duas plataformas diferentes para
processamento de dados: (i) funções serverless; e (ii) pool de
contêineres. Diferente da nuvem, os recursos são mais limitados no
nevoeiro. Portanto, o compartilhamento de recursos é um desafio em tal
solução, visto que um nó fog processa dados de vários usuários
simultaneamente. Serverless fornece uma maneira rápida de executar
tarefas de computação em recursos compartilhados. No entanto, algumas
tarefas podem exigir mais tempo de computação do que outras e sofrer
limitações de tempo limite de plataformas sem servidor.
VitalSense propõe a combinação de pool de contêineres e sem servidor
para executar tarefas. O pool de contêineres pode oferecer suporte ao
processamento de dados para tarefas que exigem mais tempo.
O Orquestrador de Dados é responsável por escolher cada solução de
acordo com o consumo e disponibilidade de recursos.
VitalSense propõe uma topologia de rede onde os nós de neblina
são organizados em uma estrutura hierárquica. Cada nó nevoeiro pode
assinar um nó pai e vários nós filhos para receber três tipos de
Machine Translated by Google

Saúde e Tecnologia

Figura 3 Arquitetura da camada Edge.

NÓ DE NÉVOA
O middleware do sensor coleta dados
de sensores que suportam diferentes
interfaces. Os dados são então CONECTOR DE BORDA SERVIDOR MQTT

processados e transmitidos para o

nevoeiro, enquanto o processamento
local pode gerar notificações

pm
otroeãea
d
Publicar Se inscrever Publicar Se inscrever

SERVIDOR MQTT CONECTOR DE NÉVOA

Provisionamento de dados Provisionamento de serviços

Criptografia Heurística
uS
tiom
n o
a
e

Compressão Classificação

oãçacifitoN
DB
PROC AN
E TR
S S
A

Agregação Correlação
LG
N
OLD
E TO
E R
C
E

Filtragem Predição
ROSNES

API de sensores dados de aplicativos

ERAWELDDIM

Conector MQTT
Conector Coletor (puxando)

Estacionário Móvel

IoT MQTT Smartphone

& Sensor
Porta de entrada
fornecedor

aplicativo

Vestível
Vestível
ou
Estação
Sensores autônomos Sensores integrados

e (iii) transferência de dados. Um determinado nó nevoeiro pode assinar
notificações de seus nós filhos e gerar novas mensagens de alerta
agregando dados de múltiplas fontes. Por sua vez, os dados de serviço
referem-se a mensagens contendo cálculos resultantes de serviços
específicos. O módulo Análise de Dados compreende diversos serviços
que produzem uma saída que é publicada no servidor MQTT. Os nós pai
e filho podem se inscrever para receber dados de serviço e usar as
informações
em seu processamento local.
Um determinado nó de neblina possui recursos limitados que podem
levar a uma situação de sobrecarga de acordo com o número de usuários.
Nesses casos, o Fog Connector pode encaminhar dados para
processamento para um nó pai. O Request Manager decide se os recursos
estão disponíveis, informando ao Fog Connector em qual direção as
solicitações devem fluir. Em caso de descarregamento
necessidades, o Fog Connector publica dados no servidor MQTT, onde o
nó pai consome dados para processamento.
Além da topologia pai/filho, os nós fog também podem se conectar a
nós irmãos. Os nós Brother são os nós fisicamente mais próximos de um
nó de neblina específico. O canal de comunicação é importante para
migrar uma sessão de usuário quando o usuário está mudando de uma
região para outra. Portanto, os nós irmãos podem executar uma estratégia
de transferência para que o sistema possa manter o rastreamento e o
histórico do usuário.
Privacidade e segurança também são questões importantes no
tratamento de dados de pacientes. Os nós Fog geram um par de chaves
RSA 2048 para permitir a criptografia de dados na camada de borda. Os
controladores de borda usam a chave pública para criptografar os dados,
enquanto os nós de névoa usam a chave privada para descriptografá-los.
Além disso, VitalSense emprega algoritmos de criptografia homomórfica [29] neste

13
Machine Translated by Google

Saúde e Tecnologia

Serviço
Fig. 4 Arquitetura da camada de neblina.
NÓ DA CAMADA SUPERIOR (NÓ DE FOG ou NUVEM)
Os dados são recebidos de vários Conector de nevoeiro Servidor MQTT
Edge Collectors para serem analisados e se inscrever

Serviço
processados por diferentes serviços. Os

Serviço
nós de nevoeiro podem gerar notificações
de acordo com o processamento do mensagem NÓ DE NÉVOA

serviço e da análise

Serviço
Notificação
Base de dados
Gerente

Dados
Funções sem servidor
1

megasnem

revercsensi
Análise

pm
otroeãe a
d
eu eu eu

IPA
MQTT Registro de nevoeiro e
eu eu eu

eP
adaatrrton d
e
Conector de nevoeiro n
Servidor Gerente Prioritário

Solicitar
Gerente
1
Conjunto de contêineres

IPA
Recipiente

eP
adaatrrton d
e
megasnem

revercsensi
pm
otroeãe a
d

Gerente

mensagem

se inscrever

Conector de nevoeiro Servidor MQTT

NÓ DA CAMADA INFERIOR (BORDA OU NÓ DE NÉVOA)

camada que garante que todos os dados que fluem no sistema
sejam seguros. Os dados brutos podem ser transferidos para
serviços de terceiros e nuvens públicas, que podem realizar cálculos
aritméticos com os dados sem acessá-los. Esses serviços não
podem ver os dados reais e precisam solicitar um nó de névoa para
descriptografar o resultado de sua computação.
o número de indivíduos e sua posição naquela região específica.
Tal painel pode auxiliar na tomada de decisões do administrador
público que pode atuar proativamente para mitigar os riscos para a
população.
3.1.4 Organização da rede

3.1.3 Camada de nuvem A Figura 6 mostra a organização da rede do VitalSense. A

A camada de nuvem é o agregador de dados de toda a arquitetura.
Ele se conecta aos nós de neblina no topo da hierarquia para receber
notificações e dados agregados. A nuvem combina dados de todas
as fontes, proporcionando uma visão geral mais ampla da arquitetura.
A análise global é possível nesta camada através de algoritmos de
previsão e classificação de dados. Os aplicativos podem usar
recursos da nuvem para gerar insights críticos para administradores
públicos. Painéis, visualizações e gráficos são exemplos de
aplicativos em tempo real que podem monitorar regiões. Além disso,
os relatórios de dados podem fornecer uma compreensão valiosa
dos padrões e regiões de risco com base nos dados processados no
nevoeiro.
A Figura 5 demonstra um painel de visualização de dados na
camada de nuvem. O painel pode mostrar regiões que concentram
anormalidades nas medições de um determinado sinal vital. A Figura
5 demonstra uma visão ampliada da cidade de Porto Alegre,
mostrando círculos vermelhos em regiões onde vários indivíduos
apresentam febre. Por sua vez, a Fig. 5b mostra o mesmo painel,
mas ampliando uma região específica onde a concentração é alta.
O administrador público pode visualizar
interconexão entre sensores, Edge Controllers, nós de neblina e
nuvem forma uma topologia híbrida de malha em estrela. Na
fronteira, as Redes de Área Pessoal (PAN) compreendem os
sensores do paciente conectados a um Edge Controller para produzir
dados. Alternativamente, os sensores podem formar uma rede de
curto alcance na qual um nó mestre coleta seus dados para transmitir
ao Edge Controller. A tecnologia sem fio, como Bluetooth e WiFi, é
predominante nesta camada. No entanto, também é possível uma
conexão Ethernet entre o nó mestre e o Edge Controller.
Como ponto de entrada para o sistema, os Edge Controllers
ficam próximos o suficiente dos PANs enquanto se conectam aos
nós de neblina em redes locais (LAN). Cada Edge Controller se
conecta a um único nó de neblina, e eles podem mudar de acordo
com a mobilidade do Edge Controller. Os Mobile Edge Controllers
mudam seu nó de névoa ao longo do tempo de acordo com a proximidade da rede.
A mobilidade só é possível ao empregar a tecnologia WiFi e 5G para
conectar o nevoeiro. Ao empregar a tecnologia Ethernet, os Edge
Controllers são fixados em residências, hospitais, lojas, entre outros.
A fibra nesta camada pode fornecer uma conexão segura e privada
ao nevoeiro, suportando transmissão de dados de alta taxa e baixa
latência.

13
Machine Translated by Google

Saúde e Tecnologia

MAPA DE MONITORAMENTO DE SINAIS VITAIS MAPA DE MONITORAMENTO DE SINAIS VITAIS

SINAL VITAL SINAL VITAL

Temperatura SpO2 Frequência cardíaca Taxa de respiração Temperatura SpO2 Frequência cardíaca Taxa de respiração

MEDIDAS ANORMAIS: 1.257 MEDIÇÕES ANORMAIS: 137

(a) (b)
Fig. 5 Painel para visualização do mapa e navegação de acordo com medições de sinais vitais fora da normalidade: a mostra uma visão mais ampla de uma cidade,
enquanto b amplia uma determinada região de interesse

No nevoeiro, uma topologia de rede mesh hierárquica constrói o caminho para consumir dados e fornecer serviços. Esses nós de neblina também podem se
a nuvem, fornecendo serviços de baixa latência até a borda. conectar a vários nós de neblina vizinhos de acordo com a proximidade física e
Os nós de neblina mais próximos da borda se conectam aos Edge Controllers para de rede. Moving Edge Controllers só podem

Figura 6 Topologia de rede

Ethernet\WiFi\Bluetooth\PAN

Ethernet\WiFi\5G\LAN

Ethernet\5G\WAN

Distritos
Sensores

BORDA NÉVOA NUVEM

Nó de nevoeiro
Cidades

Controlador de borda

Hospitais, clínicas,
casas, etc.

13
Machine Translated by Google

Saúde e Tecnologia

mude para um dos vizinhos, e o vizinho permite a transferência entre os nós
de neblina envolvidos no processo. Além disso, os nós de neblina podem se
conectar a um nó pai ou à nuvem. Os nós de névoa pai permitem o
descarregamento do processamento de dados se um nó de névoa específico
estiver sobrecarregado. Além disso, os nós parentais compreendem regiões
físicas que fornecem serviços específicos para uma determinada região que
monitoram.
A distribuição física dos nós de neblina e sua topologia de rede devem ser
orientadas pela segmentação urbana (distritos, cidades, entre outros). A
granularidade desta segmentação é flexível de acordo com as necessidades.
Por exemplo, é possível, para um caso particular, distribuir um nó de neblina
por distrito conectado a um nó de neblina pai de uma cidade. Distritos com
maior densidade populacional podem ter vários nós de neblina ou até mesmo
nós de neblina dedicados para hospitais. Independentemente da granularidade,
a topologia ainda respeita a topologia de rede do VitalSense.
3.2 Serviço de nomenclatura de informações e distribuição de dados
O gerenciamento de dados no mundo IoT é um dos muitos desafios que as
soluções de computação em neblina enfrentam [30]. Os sistemas semelhantes
à nuvem tradicionalmente empregam soluções centralizadas de armazenamento
de dados que exigem dispositivos para transmitir um grande volume de dados
através da Internet (Fig. 7a). Os dispositivos IoT podem produzir uma enorme
quantidade de dados enviando-os para a nuvem ao custo de alta latência.
Os serviços de saúde que solicitam esses dados também sofrem as mesmas
penalidades de latência. A computação em neblina resolve essa desvantagem
permitindo o armazenamento local de dados em nós de neblina que estão
mais próximos dos dispositivos. Tal estratégia compreende uma solução
distribuída de armazenamento de dados na qual os dados são espalhados
entre vários nós de neblina (Fig. 7b). Isso torna o gerenciamento de dados
complexo, uma vez que um dispositivo específico pode mover e alterar nós
de neblina dinamicamente. Nesses casos, a busca de dados deste dispositivo
específico exige que o sistema pesquise seus dados em vários locais.

Fig. 7 Estratégias de distribuição

Nuvem
de dados: sistemas tradicionais
semelhantes a nuvem em que
a nuvem centraliza os dados; e b
0 0
estratégia de névoa espalhando 1 1
os dados entre vários nós 2 2

...
...

3 3
4 4
tenLcay

5 5
6 6
7
Alto volume de 7
.H

aicnaêttlaAl
dados transmitidos
n através de n
Internet para e
da nuvem
IoT Saúde
Dispositivo Serviço

(a)

Névoa Névoa Névoa

Nó Nó Nó Onde
éo
dados?

0 3 n-2 0 3 n-2
... n-1
teLnoLcw
a
y

aicanxêiataBl

1 4 1 4 n-1
2 5 n 2 5 n

IoT Saúde
Dispositivo Serviço

(b)

13
Machine Translated by Google
Saúde e Tecnologia
Fig. 8 Diagrama de sequência de
armazenamento e acesso de dados Borda
usando o INS para localizar os dados Sensor Controlador
ID eletrônico
aperto de mão (eID)
ACEITAR
conectar()
OK
laço
enviar()
OK
VitalSense emprega uma estratégia de rastreabilidade de dados que
oferece dois recursos principais: rastreamento de localização do usuário e
pesquisa de dados mais rápida. Como os usuários podem se mover e se
conectar a diferentes nós de nevoeiro, seus dados podem ser espalhados
3.3 Processamento de serviços distribuídos
por vários servidores, impondo desafios para recuperar dados de um determinado período.
Portanto, propomos um novo componente denominado Information Naming
Service (INS) colocado na nuvem para manter o rastreamento dos dados. O
INS registra todos os eventos de handshake que os componentes edge-fog
e handoff executam. Portanto, ele pode rastrear alterações na topologia da
rede e determinar em quais nós específicos os dados de um determinado
dispositivo são armazenados.
Cada dispositivo possui um Edge Controller cadastrado no INS.
Os Edge Controllers possuem IDs exclusivos que informam aos nós de
neblina no processo de handshake. Portanto, a cada processo de handshake
e handoff, os nós de neblina registram a operação no INS. O INS implementa
um sistema de nomenclatura semelhante ao DNS da Internet, permitindo
consultas a partir de um determinado ID. Figura 8
descreve um diagrama de sequência mostrando as operações que ocorrem
entre Edge Controllers, nós de neblina e o INS.
Para acessar os dados de um aparelho, o VitalSense consulta o ID do
aparelho no INS. Ele pode fornecer uma janela de tempo específica para
filtrar um período de destino. O INS fornece as entradas que descrevem o
caminho do dispositivo e o tempo atribuído para cada nó de neblina. Portanto,
o HealthStack pode acessar diretamente os dados nos nós de névoa para
processamento posterior. Por exemplo, podemos empregar técnicas de
sharding [31] para que o HealthStack possa acessar o nó com o maior
volume de dados ou o nó mais próximo para buscar os dados. Ao implantar
um sistema distribuído de armazenamento de dados, os administradores
devem levar vários aspectos em consideração [30]. A fragmentação de dados
aborda vários aspectos, como
Névoa
Dados
Nó INS
Middleware
identificação
registrar (eID, fID, hora)
ACEITAR
pesquisa (xID)
enviar()
RESPOSTA
OK
solicitar()
RESPOSTA
como tolerância a falhas, escalabilidade e distribuição de dados. Contudo,
há outros que também devem ser considerados: segurança, privacidade,
disseminação de dados e replicação de dados.
VitalSense suporta diversos serviços na camada de neblina distribuídos
entre vários nós. O mesmo serviço é executado em diferentes níveis,
permitindo a transferência de processos de um nó para outro. Em outras
palavras, um nó fog específico pode descarregar uma amostra de dados para
um nó diferente para processar a solicitação.
O descarregamento de dados é essencial quando um nó específico fica
sobrecarregado com muitas solicitações que prejudicam seu desempenho.
A Figura 9 apresenta o modelo de distribuição de carga realizado pelo
componente Request Manager dos nós fog. O Receptor de Solicitação (1)
decide onde processar as solicitações recebidas de acordo com as prioridades
do usuário e do serviço e a previsão computada por um modelo de
aprendizado de máquina no Modelo Preditor (2). Este módulo específico
prevê quanto tempo a execução do serviço levará para ser concluída. Em
seguida, delega as solicitações ao nó atual (3) caso não ultrapasse o tempo
limite ou ao nó superior (4) caso este ultrapasse. Embora o modelo de
aprendizado de máquina ainda esteja aprendendo o comportamento dos
serviços, a previsão pode não ser totalmente precisa, especialmente nas
primeiras execuções. Isso pode executar a solicitação no nó, mas exceder
o tempo limite das primeiras solicitações. Portanto, como pretendemos
garantir a confiabilidade se a execução exceder o tempo limite, a execução
é reexecutada no nó superior para se beneficiar de capacidades de
processamento ilimitadas. É fundamental mencionar que o nevoeiro
13
Machine Translated by Google
Fig. 9 Gerenciador de solicitações
responsável por processar e
enviar solicitações: (1) decide
onde processar as solicitações
recebidas com base nas
previsões (2) e, em seguida,
delega as solicitações ao nó
atual (3) ou ao nó superior (4). )
Sem servidor
3 Preditor
Solicitar
Funções Executor
4 1
Processo
Descarregador
nós são heterogêneos. Cada um tem seu modelo, permitindo-lhes
aprender seu comportamento particular.
Após executar a solicitação, o Request Executor armazena sua
duração para que o Predictor Model possa utilizar esta informação
para prever quanto tempo as execuções futuras levarão para terminar.
Amostras de duração recentes têm um impacto maior nas previsões. Os
parâmetros e entradas da solicitação também devem ser armazenados
no banco de dados, pois a duração pode variar dependendo da entrada.
Caso os recursos do nó estejam sobrecarregados e a conexão com o nó
superior esteja inacessível, o Executor de Solicitações adiciona solicitações
recebidas a uma fila. A fila de tarefas garante que nenhuma solicitação
será descartada e garante confiabilidade para serviços urgentes. Se os
recursos locais ficarem disponíveis novamente, o Request Executor
executa as solicitações enfileiradas localmente. Quando o nó superior
estiver acessível novamente, mas os recursos locais ainda estiverem
sobrecarregados, o Process Offloader descarrega verticalmente as
solicitações para ele. Dependendo da carga de trabalho dos nós
superiores, todos os nós podem ficar sobrecarregados e os Request
Managers os descarregam recursivamente até chegar à nuvem.
Nesse caso, a solicitação é processada sem limite de tempo, executando
com capacidades de processamento ilimitadas fornecidas pelos
fornecedores de nuvem.
Existem dois tipos de prioridades que o Receptor da Solicitação
precisa considerar ao decidir quais solicitações são as mais importantes:
(i) prioridade do usuário; e (ii) prioridade de serviço. As prioridades
impactam a decisão da camada (nó de névoa mais próximo ou nós de
névoa pai da hierarquia) onde o sistema deve executar solicitações. O
objetivo principal é executar solicitações no nó fog mais próximo sempre
que possível, resultando em respostas de baixa latência devido à
proximidade física entre os dispositivos de borda e o nó. Todas as
solicitações podem ser executadas no nó fog mais próximo quando ele
tiver muitos recursos computacionais disponíveis, independentemente do
13
Saúde e Tecnologia
...
SERVIÇOS NA NUVEM
NÓ DE NÉVOA
NÓ DE NÉVOA
NÓ DE NÉVOA
Gerenciador de solicitações
2
Modelo
aferaT
aliF
eB
osdaa d
oãçaruD
ocirótsiH
se
Solicitar Métrica
Receptor Colecionador
CONTROLADOR DE BORDA
prioridade. Por outro lado, as solicitações de baixa prioridade devem ser
descarregadas para os nós de nevoeiro pai quando a plataforma estiver
enfrentando picos de uso elevados e quando o nó de nevoeiro mais
próximo estiver sobrecarregado.
A prioridade do usuário é essencial quando usuários específicos
devem receber mais atenção do que outros, como idosos ou grupos em
situação de risco na área da saúde, que devem ter suas solicitações
executadas com a menor latência possível. Este último está relacionado
com a prioridade do próprio serviço, uma vez que serviços específicos
podem ser mais críticos que outros.
É importante ressaltar que a prioridade do usuário é dinâmica e é recebida
na carga útil da solicitação, pois uma pessoa com problemas de saúde
pode ficar mais saudável depois de algum tempo, e solicitações posteriores
deverão indicar prioridades mais baixas. A prioridade do serviço é
normalmente estática e não muda com o tempo, a menos que o serviço
seja reimplantado ou a prioridade seja reconfigurada globalmente e, por
esse motivo, seja buscada no banco de dados.
O módulo Request Receiver é responsável por combinar ambas as
informações em um único valor numérico. Ele combina ambos os valores
e calcula um valor de classificação, conforme detalhado na Figura 10.
Serviços críticos com alta prioridade de usuário podem ser os primeiros a
serem executados no nó fog mais próximo. Em contraste, solicitações de
serviços de baixa prioridade com usuários de baixa prioridade são mais
viáveis de serem executadas em nós de névoa pai, como a nuvem. Em
resumo, a regra para combinar os dois valores é somar as duas
prioridades, enquanto o ranking é esse resultado final.
4 Implantação e casos de uso
Esta seção explora casos de uso de aplicativos que podem aproveitar os
recursos do VitalSense. Além disso, demonstramos como implantar a
arquitetura de um ponto de vista ascendente.
Machine Translated by Google

Saúde e Tecnologia

Fig. 10 Ranking combinando 20

as prioridades do serviço e do
usuário, com cores intensas
10 10 11 12 13 14 15 16 17 18 19 20
representando as solicitações mais importantes
9 9 10 11 12 13 14 15 16 17 18 19

8 8 9 10 11 12 13 14 15 16 17 18

7 7 8 9 10 11 12 13 14 15 16 17

6 6 7 8 9 10 11 12 13 14 15 16

5 5 6789 10 11 12 13 14 15

ilrC
oãçeadcaifdisisroae d
p
rrsirtiU
oy
p
e

4 4 5678 9 10 11 12 13 14

3 3 456789 10 11 12 13

2 2 345678 9 10 11 12

1 1 23456789 10 11

0 0 12345678 9 10
0

0123454689 10

Prioridade de serviço

4.1 Instância de implantação de arquitetura estão disponíveis dependendo do nível do qual os aplicativos se
beneficiam. Os aplicativos podem variar de painéis a algoritmos de
A Figura 11 apresenta a implantação de cada módulo da arquitetura, previsão para gerar alertas. As seções a seguir descrevem diferentes
incluindo aspectos de infraestrutura. A base de implantação diz respeito casos de uso.

aos dispositivos IoT na casa do indivíduo. A pessoa alvo usa um

dispositivo de pulso, como um smartwatch, que monitora vários sinais
vitais. O Edge Collector pode ser implantado em um computador de placa
única na casa do indivíduo ou em seu smartphone. Portanto, ele pode
chegar ao smartwatch para extrair dados usando WiFi ou Bluetooth. Uma
conexão com a Internet usando um Modem/Roteador permite a
comunicação com a rede fog de ponta a ponta. As tecnologias Virtual
Private Network (VPN) e MPLS podem garantir a privacidade e o
desempenho desta conexão, garantindo QoS na transmissão de dados.
A rede compreende vários links entre nós de nevoeiro distribuídos
pela cidade no nevoeiro. Por exemplo, pode-se implantar um servidor fog
node em postes de serviços públicos, racks de rede, lojas, mercados,
hospitais, entre outros. O principal requisito é que a infraestrutura de rede
para esses nós de nevoeiro forneça garantias de desempenho, usando
VPN e MPLS como exemplo.
Essa infraestrutura é a mesma quando se conecta o nevoeiro com a
nuvem. Portanto, o fim da infraestrutura são os data centers em nuvem,
que também se conectam à Internet fornecendo seus endpoints aos nós
de neblina. Além disso, os aplicativos do usuário podem se conectar aos
serviços em nuvem usando sua conexão pública à Internet, da mesma
forma que serviços e sites padrão.
VitalSense suporta o desenvolvimento de diversos serviços para rodar
em todos os níveis da arquitetura. Diferentes tipos de dados
4.2 Controle de exposição a riscos
A Figura 12 representa um sistema de gerenciamento de exposição ao
risco onde o usuário pode monitorar o tempo de exposição às regiões de
risco em um intervalo de tempo. Consiste no monitoramento de trajetória
que cruza dados de localização com classificações de regiões de risco.
Cada zona pode ser classificada dependendo dos parâmetros de saúde
dos usuários de cada região. Além disso, o sistema público de saúde e
os próprios pacientes podem reportar ao sistema o seu estado atual. As
técnicas de aprendizado de máquina podem classificar cada região
combinando diferentes fontes de dados. Dependendo do caso, uma
região de alto risco pode significar algo diferente.
Por exemplo, um sistema de monitoramento de doenças infecciosas pode
relatar o tempo de exposição à doença e o potencial de contração. Outro
exemplo é um sistema de exposição a perigos que pode rastrear e alertar
os usuários para evitar cruzar uma área específica devido a um vazamento
de gás ou incêndio.
Além de fornecer alertas diretamente aos usuários, tal sistema
também fornece informações valiosas aos administradores públicos. Por
exemplo, painéis construídos com base nas informações mostram o
status em tempo real de diversas regiões. Nas regiões onde os riscos
estão a aumentar, os administradores podem tomar medidas proactivas
para mitigar potenciais ameaças à população. Em

13
Machine Translated by Google

Saúde e Tecnologia

Fig. 11 Exemplo de implantação

da arquitetura Vital - Sense em uma
cidade inteligente

13
Machine Translated by Google
Saúde e Tecnologia
Fig. 12 Sistema de controle
de exposição ao risco
além disso, podem gerar alertas públicos à população de acordo com
a degradação da situação em regiões específicas.
Quando o sistema detecta vazamento de soluções tóxicas ou doenças
transmitidas pelo ar, ele pode isolar automaticamente a área. Ao
mesmo tempo, o pronto-socorro público recebe alertas solicitando
ajuda proativa. Ser proativo em tais cenários pode melhorar
significativamente os serviços de assistência à saúde.
4.3 Prestação proativa de serviços
A Figura 13 demonstra uma prestação de serviço proativa em que
um hospital envia uma ambulância ao receber um alerta proativo
vindo do nevoeiro. Neste cenário, um usuário usa um sensor de
monitoramento cardíaco que fornece dados ao sistema. O Edge
Controller coleta os dados em tempo real e encaminha as amostras
para o nevoeiro. Um serviço de análise em tempo real processa os
dados realizando previsões para identificar possíveis falhas cardíacas.
A neblina notifica o sistema de saúde pública sobre uma emergência
iminente. Assim, a ambulância disponível mais próxima pode atender
a chamada e atender proativamente o paciente em sua própria casa.
Embora a figura apresente um caso específico de monitoramento
cardíaco, tal serviço funciona para diversos tipos de dados. Por
exemplo, o mesmo serviço funciona para detecção de quedas de
idosos ou detecção de vazamentos de substâncias tóxicas. Pode
gerar previsões complexas para regiões inteiras ao combinar dados
de vários sensores, incluindo vários locais. Vários usuários relatando
aumento de febre e tosse em uma determinada região podem indicar
um surto de doença. A utilização de previsões nos serviços de saúde
pode mitigar crises de saúde pública ou mesmo evitar que as pessoas
se exponham a situações perigosas. Além de fornecer alertas ao
sistema público de saúde, o usuário também pode receber notificações
sobre perigos ou crises de saúde. Portanto, os usuários também
podem procurar assistência médica com antecedência e proativamente.
Combinado com o serviço anterior, o usuário pode receber alertas
em tempo real ao entrar em regiões de risco previsto.
4.4 Painel de controle de saúde pública
A apresentação de dados clínicos resumidos num único painel ou
dashboard está cada vez mais em evidência. São ferramentas que
utilizam representações visuais de dados para permitir uma menor
carga de processamento cognitivo. Portanto, aumentam a velocidade
e a precisão da tomada de decisões. As representações visuais
facilitam a identificação de tendências, padrões ou anormalidades em
um determinado banco de dados em comparação com a análise de
dados sem estrutura [32]. A Figura 14 demonstra como seria um
painel condensando vários dados de pacientes em um único painel.
A coleta de dados de sensores torna possível monitorar regiões
inteiras, incluindo a detecção das regiões mais
13
Machine Translated by Google
Fig. 13 Atendimento proativo
de ambulância
HOSPITAL
ALERTA
Névoa
Nó
Histórico
Borda
Controlador
regiões e problemas críticos. Além disso, é possível apresentar o estado
atual dos sinais vitais da região e ampliar as microrregiões de acordo
com um parâmetro específico. Embora o painel apresente dados de
diversos indivíduos, é possível navegar por dados de pacientes
específicos, por exemplo. Esses painéis podem estar disponíveis em
diferentes níveis, inclusive para o prestador de serviços de saúde ou
para o governo com agregação de dados.
O design utilizado para os recursos visuais de um dashboard deve
buscar o equilíbrio entre a complexidade visual e a utilidade das
informações. Essencialmente, os dashboards devem ser adaptados à
finalidade pretendida e ao utilizador final, considerando as suas
capacidades analíticas e nível de conhecimento. A perspectiva do
paciente precisa ser repetidamente enfatizada. A apresentação dos
dados em gráficos deve ser a escolha na hora de comparar, agrupar ou
reconhecer padrões nas informações [33]. Em outras situações, as
tabelas devem ser a escolha quando houver necessidade de avaliar
valores específicos [33]. Devido à complexidade, deve-se evitar a
apresentação de informações em fórmulas e frações. Outros detalhes,
como a apresentação de valores específicos com o mesmo número de
casas decimais e a mesma escala nos seus eixos dos gráficos,
13
Saúde e Tecnologia
EMERGÊNCIA
Análise e previsão em tempo real
Atual Predição
agora
também devem ser observados para evitar vieses na interpretação das
informações apresentadas.
O uso de esquemas de cores ajuda a chamar a atenção para
resultados que indicam uma área de preocupação, como aumento da
temperatura corporal ou diminuição da oxigenação sanguínea. As cores
verde ou azul, amarelo ou laranja e vermelho devem ser escolhidas
preferencialmente para indicar sequencialmente o risco ou gravidade
de uma anormalidade fisiológica [34]. Alertas na cor cinza podem indicar
problemas no sistema durante a recuperação dos elementos que
compõem a informação a ser visualizada. Vale ressaltar que os
indicadores clínicos de uma condição de saúde devem ser baseados em evidências cie
e ser reconhecido nas diretrizes nacionais [35]. Além das diferentes
cores indicativas, o sistema pode notificar o usuário com serviços de
alerta para indicar que determinados dados estão fora dos limites pré-
determinados. Os serviços de alerta podem ser projetados para gerar
links que auxiliem o usuário na tomada de decisão, como oferecer a
opção de ligar para um serviço de emergência ou serviço especializado,
enviar mensagem ou e-mail ao médico responsável com detalhes do
quadro, ou mesmo para buscar informações sobre o porquê do alerta
ter sido emitido.
Machine Translated by Google
Saúde e Tecnologia
PAINEL DE CONTROLE DE SAÚDE PÚBLICA
ESTADOS MONITORADOS INDIVÍDUOS MONITORADOS
50 3.587.871
Fig. 14 Dashboard condensando diversos dados do paciente em um único painel por região em tempo real. O mapa permite aumentar e diminuir o zoom em regiões específicas
5 Discussão e experimentos preliminares
VitalSense é uma solução desenvolvida como parte de dois projetos
de pesquisa: MinhaHistoriaDigital (MyDigitalHistory) e
MinhaSaudeDigital (MyDigitalHealth), que focam em questões de
saúde pública no Brasil. O principal objetivo da presente pesquisa é
desenvolver e implantar a infraestrutura na cidade de Porto Alegre,
Rio Grande do Sul, Brasil. Esta seção apresenta os experimentos e
considerações iniciais sobre o desenvolvimento e implantação do
VitalSense.
A Seção 5.1 apresenta experimentos preliminares usando Shard-
ing para testar o desempenho da estratégia de distribuição de dados.
A seguir, a Seção 5.2 apresenta os principais dispositivos IoT
disponíveis no mercado para monitorar sinais vitais.
5.1 Eficiência na distribuição de dados usando fragmentação
Realizamos experimentos preliminares para validar a eficiência da
distribuição de dados do modelo usando Sharding em uma
infraestrutura baseada em Docker para individualizar o processamento
em um único computador. A configuração do host consiste em um
Intel Core i7 Hexa-core de 2,6 GHz, 16 GB de RAM DDR4 Dual-
Channel de 2.667 MHz e um SSD com taxa de leitura e gravação de
3.200 MB/s e 2.200 MB/s, respectivamente. Empregamos MongoDB
como um banco de dados que implementa Sharding
PERÍODO ALERTAS STATUS
TEMPO REAL 102 SOBRE
Temperatura
SpO2
Frequência cardíaca
Respiração/minuto
de forma direta e eficiente. Conforme mostrado na Figura 15, por ser
um requisito para o uso de sharding no MongoDB, adicionamos ao
modelo um servidor de configuração que armazena os metadados
da localização dos registros na estrutura.
Estabelecemos dois cenários preliminares para validar a eficiência
do modelo utilizando Sharding (com dois nós) em comparação com
um banco de dados centralizado. O primeiro cenário realiza uma
busca utilizando um filtro pelo servidor na consulta. No segundo, a
consulta foi realizada sem filtragem, retornando todo o banco de
dados. Ambos os cenários consideram um banco de dados com
mais de 2 milhões de registros dos quais recuperamos uma amostra
de dados em 10 execuções diferentes. A Figura 16 apresenta os
resultados para ambos os cenários.
Os resultados preliminares mostram que o emprego do Sharding
leva a uma melhoria de aproximadamente 20% no tempo de resposta
da consulta. O fator proximidade com os dados não é aplicável nos
experimentos visto que as instâncias rodam na mesma máquina;
caso contrário, traria ainda mais vantagens ao Sharding em um
cenário real distribuído. Com Shard-ing, os resultados mostram um
tempo médio de resposta de 1,36 e 1,38 s (com desvio padrão de
0,1350 e 0,0919 s) no primeiro e no segundo cenários. Sem
Sharding, o tempo de resposta é de 1,66 e 1,78 s (com desvio
padrão de 0,1430 e 0,1751 s) para o primeiro e segundo cenários.
Nos experimentos com Sharding, o tempo de busca de todos os
registros em
13
Machine Translated by Google
Fig. 15 Metodologia de
avaliação usando duas
instâncias de Sharding
Replicado
Fragmento nº 1 Roteador
ambos os nós ou um único nó são praticamente iguais. Devido à distribuição
dos dados entre diversos servidores, a consulta é executada
simultaneamente, distribuindo a carga de trabalho.
Os experimentos preliminares mostram as vantagens de distribuir
dados entre vários nós de neblina em vez de centralizá-los na nuvem. Além
de melhorar o tempo de resposta na consulta de dados, também melhora
o desempenho de toda a rede ao não encaminhar dados de todos os
sensores para a nuvem. Além disso, as aplicações podem solicitar dados
da infraestrutura do Fog e se beneficiar de uma transmissão de dados mais
rápida, uma vez que o Fog está mais próximo da aplicação do que da
nuvem.
5.2 Instruções sobre monitoramento de sinais vitais
Atualmente, estamos testemunhando um aumento nas soluções de IoT
para monitoramento da autossaúde. A cada dia novos dispositivos são
disponibilizados no mercado para que todos possam comprar e monitorar
seus sinais vitais por meio de aplicativos para smartphones. Os dispositivos
IoT constituem a base dos sistemas de monitoramento remoto de sinais
vitais, fornecendo dados de saúde dos indivíduos em tempo real. A falta
dessas informações pode comprometer a viabilidade das soluções, uma
vez que dependem da extração de dados de saúde dos pacientes. Hoje
em dia, diversas soluções propõem dispositivos de monitoramento
específicos que aos poucos estão se tornando produtos prontos para uso,
disponíveis para todos. Embora existam vários dispositivos disponíveis,
eles não são totalmente adaptados para suportar um sistema de monitoramento massivo.
de frequência cardíaca e SpO2 são os mais comuns entre os aparelhos.
Seu foco principal é fornecer informações a quem está usando o dispositivo
por meio de aplicativos proprietários para smartphones. Além disso, a
maioria dos dispositivos equipa apenas alguns sensores,
Fig. 16 Tempo de resposta ao consultar dados do banco de dados com e sem
Sharding
13
Saúde e Tecnologia
Configuração Replicado
Metadados Roteador Fragmento #2
o que pode exigir que os pacientes usem mais de um dispositivo para
monitoramento remoto da saúde.
O uso de vários dispositivos é aceitável quando o indivíduo já é um
paciente que pode ficar em casa para monitoramento remoto após já
identificar uma condição médica. No entanto, ao focar no monitoramento
proativo da saúde, não é viável que os indivíduos usem diversos dispositivos
durante as atividades diárias. O monitoramento diário da saúde deve ser
contínuo do ponto de vista do paciente. Não deve impor desconforto e
restrições às atividades dos indivíduos. Isso só é possível através de
dispositivos equipados com vários sensores ao mesmo tempo.
Portanto, os indivíduos só podem usar um dispositivo exclusivo, como um
smartwatch ou uma banda inteligente. Assim, este dispositivo pode
suportar diversos protocolos de comunicação para fornecer dados de
diversos sensores em um formato padrão.
Para avaliar a disponibilidade de tais dispositivos, realizamos pesquisas
de mercado em busca de dispositivos candidatos de monitoramento de
saúde pessoal para integrar o modelo VitalSense. Avaliamos 149
dispositivos, incluindo smartwatches, bandas inteligentes e anéis
inteligentes, analisando os sensores que equipam, recursos de segurança,
disponibilidade de API e protocolos de comunicação. Descartamos todos
os dispositivos com apenas um ou dois sensores, pois nos concentramos
em dispositivos que suportam um amplo conjunto de sensores.
A Tabela 2 compara 40 dispositivos IoT inteligentes resultantes que
equipam vários sensores de sinais vitais. A tabela mostra que os sensores
Além disso, apenas sete aparelhos possuem todos os sensores de sinais
vitais, representando 4,7% de todo o conjunto de 149 aparelhos. Embora
vários dispositivos estejam disponíveis, apenas alguns suportam um
conjunto completo de sensores, demonstrando a falta de dispositivos para
soluções de monitoramento remoto de sinais vitais. Pesquisas futuras
devem focar intensamente neste tópico, uma vez que pode limitar o
potencial de soluções de monitoramento remoto de saúde de sinais vitais.
VitalSense trabalha com edge, nevoeiro e computação em nuvem,
trazendo uma ideia dos distritos onde operam os nós de nevoeiro. Ou seja,
nossa arquitetura foi inicialmente planejada para cobrir áreas urbanas.
Contudo, podemos alargar esta área de cobertura às zonas rurais através
da adopção de requisitos tecnológicos. No nosso entendimento, o
fornecimento de energia e a comunicação pela Internet são os problemas
mais expressivos nas áreas agrícolas. Algumas estratégias poderiam ser
tomadas para agregá-los, tais como: (i) podemos usar dispositivos
wearables IoT baseados em bateria para coletar sinais vitais; (ii) podemos
usar tecnologias de radiofrequência de longo alcance.
Para ambos os casos, LoRa e LoRaWAN aparecem como uma das
melhores iniciativas para conectar áreas rurais. LoRa e LoRaWAN
Machine Translated by Google

Saúde e Tecnologia

Tabela 2 Detalhes dos dispositivos: Frequência Respiratória (FR); Frequência Cardíaca (FC); Variabilidade da Frequência Cardíaca (VFC); Temperatura corporal (BT); e saturação de
oxigênio (SpO2)

Dispositivo Sinais vitais Segurança Comunicação API

Cripta RR HR HRV BT SpO2. Autorização

Amazfit GTR 2e ÿ ÿ ÿ ÿ ÿ BLE, Bluetooth 5.0

Amazfit GTR 3 Pró ÿÿ ÿ ÿ ÿ ÿ Bluetooth 5.0, Wi-Fi
Amazfit GTS 2e ÿ ÿ ÿ ÿ ÿ BLE, Bluetooth 5.0
Amazon GTS 3 ÿ ÿ ÿ ÿ ÿ BLE, Bluetooth 5.0
Amazfit TRex Pro ÿÿ ÿ ÿ ÿ BLE, Bluetooth 5.0

Pulseira Biostrap EVO ÿÿÿ ÿ ÿ Bluetooth

Colmi Terra 2 ÿ ÿ ÿ Bluetooth

Colmi Land 2 S ÿ ÿ ÿ Bluetooth

Colmi P8 ÿ ÿ ÿ Bluetooth

Colmi V23 Pro ÿ ÿ ÿ Bluetooth

Pulseira Empatica E4 ÿÿ ÿ ÿ ÿ ÿ BLE, USB 2.0

Empatica Abrace PLUS ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, USB 2.0

Fitbit Inspire 2 ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, NFC

Fitbit Iônico ÿÿÿ ÿ ÿ ÿ ÿ ÿ SER

Sentido Fitbit ÿÿÿ ÿ ÿ ÿ SER

Fitbit Versa 2 ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, NFC, Wi-Fi

Fitbit Versa 3 ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, NFC, Wi-Fi

Carga Fitbit 5 ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, NFC, Wi-Fi

Fitbit Luxo ÿÿÿ ÿ ÿ ÿ ÿ ÿ BLE, NFC, Wi-Fi
Garmin fênix 6 ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin fênix 6 Pro ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth
Garmin fênix 6ÿS ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin fênix 6ÿS Pro ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth
Garmin fênix 6X Pro ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin Forerunner 245 ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin Forerunner 55 ÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth
Garmin Forerunner 745 ÿÿÿ ÿ ÿ ÿ ANT+, Bluetooth
Garmin Forerunner 945 ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin Forerunner 945 LTE ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi
Garmin Instinto ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi, LTE
Garmin Instinto Solar ÿÿ ÿ ÿ ÿ ANT+, Bluetooth
Garmin Venu 2 ÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth

Garmin Venu Square ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth, Wi-Fi

Garmin Vivoactive 4 ÿÿÿ ÿ ÿ ÿ ÿ ANT+, Bluetooth
Relógio Huawei 3 ÿ ÿ ÿ ÿ BLE, Bluetooth 5.2, LTE, NFC, Wi-Fi
Huawei Relógio 3 Pró ÿ ÿ ÿ ÿ BLE, Bluetooth 5.2, LTE, NFC, Wi-Fi

Anel Oura ÿÿÿ ÿ ÿ ÿ ÿ SER

Pulseira inteligente Xunjia Tech E66 ÿ ÿ ÿ TORNE-SE 4.0

Relógio inteligente Xunjia Tech HW12 ÿ ÿ ÿ Bluetooth 5.2

Relógio inteligente Xunjia Tech W26 ÿ ÿ ÿ Bluetooth

definir um protocolo de rede Low Power Wide Area (LPWA)
projetado para conectar sem fio dispositivos operados por bateria
à Internet em redes regionais, nacionais ou globais. Além disso,
esse dueto atende a requisitos críticos de IoT, como comunicação
bidirecional, segurança ponta a ponta, mobilidade e serviços de
localização. Considerando o escopo do dispositivo, nós
têm uma duração de bateria de até 10 anos hoje. Considerando
o ponto de vista da rede, a taxa de dados LoRaWAN varia de 0,3
kbit/s a 50 kbit/s por canal. Esta largura de banda é totalmente
aceitável para transferir dados de sinais vitais de uma família.
Por exemplo, a Fig. 17 ilustra dados JSON com os sinais vitais
de uma pessoa onde a mensagem inteira tem menos de 200 bytes.

13
Machine Translated by Google
Fig. 17 Exemplo de pacote de
dados JSON representando
coleta de sinais vitais de uma pessoa
6 Considerações finais
Prevemos que IA, edge/nevoeiro, fragmentação baseada em
geolocalização, elasticidade de recursos e compressão de dados
apoiarão a nova visão de cidades inteligentes de saúde. O
VitalSense tem como objetivo proporcionar benefícios ao seguinte
grupo de usuários: (i) cidadãos, que terão seus dados monitorados
e receberão alertas sobre possíveis problemas em seus sinais
vitais, bem como alertas sobre propagação de doenças em locais
do cidade e, em particular, aquelas frequentemente visitadas
pelo indivíduo em questão; (ii) gestores públicos, que terão uma
visão macro em tempo real de dados populacionais específicos
e históricos, podendo direcionar políticas públicas para
determinados grupos de pessoas ou bairros da cidade; (iii) os
gestores hospitalares com acesso aos dados municipais relativos
à gestão e previsão da propagação da COVID-19 podem alocar
equipas e solicitar fundos públicos antecipadamente para por distritos e bairros, dado que há maior incidência de uma
aumentar as hipóteses de salvar vidas humanas. O modelo apresenta diversas contribuições
determinada
espalhados por todo o documento:
• Emprego de compressão de dados e criptografia homomórfica
na borda (Seções 3.1.1 e 3.1.2);
• Um mecanismo de notificação multinível (Seções 3.1.1,
3.1.2 e 3.1.3);
• Rastreabilidade de integridade de baixa latência com fragmentação de dados (Sec-
ção 3.2);
• Mecanismo sem servidor, elasticidade de contêiner e mecanismo de
descarregamento de processo (Seção 3.3);
• Painéis de controle geográficos ao vivo para visualização de dados
(Seção 3.1.3).
Além das contribuições técnicas citadas, é fundamental
delinear algumas contribuições sociais e como os autores veem
o futuro da saúde. Prevemos uma coleção de serviços orientados
à latência baseados em IA, aparentemente incorporados à vida
diária dos cidadãos, trazendo um novo conjunto de notificações,
painéis e integração entre pessoas, comunidades, hospitais e o
setor público. Nesse escopo, VitalSense é uma possibilidade de
implantação para possibilitar verdadeiramente o monitoramento
digital de saúde. Abaixo apresentamos alguns cenários de saúde
que podemos viver no curto e médio prazo:
• Analisando os sinais vitais de uma pessoa, um hospital ou clínica pode
enviar um veículo até a casa de um possível paciente, pois prevê-se
que ele esteja se sentindo mal e possa morrer em breve;
13
Saúde e Tecnologia
• Quero ir ao supermercado e estou tentando decidir qual deles ir e qual
seria mais seguro. Posso ver a informação de rastreio dos cidadãos,
pessoas que têm/tiveram COVID-19, e se frequentaram aquele
estabelecimento;
• Analisando dados de sinais vitais de diferentes bairros da cidade e
vendo que a situação está piorando com a previsão de eventos, um
hospital (ou mais de um) pode preparar antecipadamente recursos
humanos e infraestrutura física para receber novos pacientes;
• Podemos analisar que tipo de doença ocorre com maior frequência
num determinado cenário. Em detalhe, podemos explorar as
tendências e a sazonalidade das doenças para obter informações
como estas: quanto mais velha for a faixa etária, maior será a
incidência desta doença específica;
• Também é possível aplicar políticas públicas de saúde personalizadas
doença.
• Utilizando dados de rastreio de pessoas, o sector público pode verificar
se o confinamento funciona;
• Ao obter dados na escala de cidade inteligente, podemos identificar
áreas com piora na saúde mental de pacientes pós-COVID-19, como
crises de ansiedade e depressão devido à perda de familiares.
Assim, o governo pode auxiliá-los indicando acompanhamento
terapêutico/consulta médica;
• Os cidadãos podem ser alertados sobre problemas de saúde pessoais
ou familiares e receber informações sobre a sua comunidade.
VitalSense é uma solução em desenvolvimento dentro de
dois projetos: MinhaHistoriaDigital (MyDigitalHistory) e
MinhaSaúdeDigital (MyDigitalHealth). Eles se concentram na
área de saúde pública no Brasil e são apoiados por agências de
desenvolvimento daquele país. A privacidade é a principal
preocupação nesse cenário, portanto a estratégia de hash
VitalSense é baseada no GPDR. Baseamos as decisões do
modelo na regulamentação e atualmente trabalhamos nessa
frente. O trabalho futuro compreende a implantação ponta a
ponta dos três níveis. Embora tenhamos resultados preliminares,
até onde sabemos, somos os primeiros a explorar novidades
internas nas camadas e a pensar nas interconexões entre elas.
Agradecimentos Os autores gostariam de agradecer aos seguintes
Agências Brasileiras de apoio a este trabalho: a Agência de Apoio à Pesquisa
Fundação do Estado do Rio Grande do Sul (FAPERGS, processos 19/2551–
0001340-0 e 21/2551–0000118-6); Coordenação para o
Machine Translated by Google
Saúde e Tecnologia
Aperfeiçoamento de Pessoal de Nível Superior (CAPES, código financeiro 001);
Conselho Nacional de Desenvolvimento Científico e Tecnológico (CNPq, bolsas
309537/2020–7 e 305263/2021–8).
Contribuição dos autores Todos os autores contribuíram para a concepção e
desenho do estudo. Em particular, Rodrigo Righi e Vinicius Facco trabalharam nas
tecnologias VitalSense. Cristiano da Costa e Bjoern Eskofier se concentraram na
revisão da seção Trabalhos Relacionados, detalhando também as lacunas abertas
na literatura. Daeyoung Kim revisou a composição dos módulos das arquiteturas
Edge, Fog e Cloud. Andreas Mayer se concentrou na análise das informações na
Seção 4, onde apresentamos a Implantação e os Casos de Uso. Todos os autores
contribuíram para as modificações finais do artigo, incluindo mais detalhes em
Financiamento Este trabalho foi apoiado pelos seguintes órgãos brasileiros:
Fundação de Amparo à Pesquisa do Estado do Rio Grande do Sul (FAPERGS,
processos 19/2551–0001340-0 e 21/2551–0000118-
6); Coordenação de Aperfeiçoamento de Pessoal de Nível Superior (CAPES,
código financeiro 001); Conselho Nacional de Desenvolvimento Científico e
Tecnológico (CNPq, bolsas 309537/2020–7 e 305263/2021–8).
Disponibilidade de dados Não aplicável.
Disponibilidade de código Não aplicável.
Declarações
Conflitos de interesses Não aplicável.
Referências
1. Philip NY, Rodrigues JJPC, Wang H, Fong SJ, Chen J. Internet das coisas para
sistemas de monitoramento de saúde domiciliar: avanços atuais, desafios e
direções futuras. IEEE J Sel Áreas Comun. 2021;39(2):300–10. https://
doi.org/10.1109/JSAC.2020.3042421.
2. Rekha G, Yashaswini J. In: Tyagi, AK, Abraham, A., Kaklauskas, A. (eds.)
Indústria 4.0: Uma revolução no setor de saúde via nuvem, Fog Technologies;
2022. pp. Springer, Singapura. https://
doi.org/10.1007/978-981-16-6542-4_16.
3. Tortorella GL, Fogliatto FS, Mac Cawley Vergara A, Vassolo R, Sawhney R.
Healthcare 4.0: tendências, desafios e direções de pesquisa. Controle do
plano de produção. 2020;31(15), 1245–1260.
4. da Costa CA, Pasluosta CF, Eskofier B, da Silva DB, da Rosa Righi R. Internet
de coisas de saúde: Rumo ao monitoramento inteligente de sinais vitais em
enfermarias hospitalares. Artif Intell Med. 2018;89:61–9. https://doi.org/
10.1016/j.artmed.2018.05.005.
5. Shukla S, Hassan MF, Tran DC, Akbar R, Paputungan IV, Khan MK. Melhorando
a latência na Internet das Coisas e na computação em nuvem para
transmissão de dados em tempo real: uma revisão sistemática da literatura
(SLR). Computação Cluster. 2021;3. https://doi.org/10.1007/
s10586-021-03279-3.
6. Buschmann P, Shorim MHM, Helm M, Bröring A, Carle G. Alocação de tarefas
em redes industriais de borda com otimização de enxame de partículas e
aprendizagem por reforço profundo. In: Anais da 12ª Conferência Internacional
sobre Internet das Coisas. IoT 2022, pp. Association for Computing
Machinery, Nova York, NY, EUA (2023). https://doi.org/10.1145/3567445.3571114.
7. Rodrigues VF, Righi RdR, da Costa CA, Antunes RS. Hospitais inteligentes e
sensores IoT: Por que o QOS é essencial aqui? Rede do Atuador J Sens.
2022;11(3). https://doi.org/10.3390/jsan11030033.
8. Aazam M, Zeadally S, Harras KA. Arquitetura de computação em névoa,
avaliação e direções de pesquisas futuras. IEEE Commun Mag. 2018;56(5):46–
52. https://doi.org/10.1109/MCOM.2018.1700707.
9. Tuli S. Ai e gerenciamento de recursos orientado por co-simulação em
ambientes de computação em neblina. SIGMETRICS Perform Eval Rev.
2023;50(3):16–9. https://doi.org/10.1145/3579342.3579347.
10. Parimala Devi M, Raja GB, Gowrishankar V, Sathya T. Em: Chakraborty C,
Banerjee A, Garg L, Rodrigues JJPC. (eds.)
Kit de diagnóstico/terapêutico inteligente baseado em IoMT para pacientes
pandêmicos; 2020. pp. Springer, Singapura. https://doi.org/
10.1007/978-981-15-8097-0_6.
11. Dong Y, Yao YD. Plataforma IoT para prevenção e controle da covid-19: uma
pesquisa. Acesso IEEE. 2021;9:49929–41. https://doi.org/10.
1109/ACESSO.2021.3068276.
12. Sahu ML, Atulkar M, Ahirwal MK, Ahamad A. Sistema de monitoramento de
sinais vitais para cuidados de saúde por meio de aplicativo de serviço pessoal
baseado em IoT. Wirel Pers Commun. 2022;122(1):129–56. https://
doi.org/10.1007/s11277-021-08892-4.
13. Rahman MJ, Morshed BI, Harmon B, Rahman M. Um estudo piloto para uma
estrutura de saúde inteligente para coletar e analisar biomarcadores com
dispositivos vestíveis flexíveis e de baixo custo. Saúde Inteligente.
2022;23:100249. https://doi.org/10.1016/j.smhl.2021.100249.
14. Li F, Valero M, Shahriar H, Khan RA, Ahamed SI. Wi-covid: Uma estrutura de
detecção de sintomas de covid-19 e monitoramento de pacientes usando wi-
fi. Saúde Inteligente. 2021;19:100147. https://doi.org/10.
1016/j.smhl.2020.100147.
15. Al Bassam N, Hussain SA, Al Qaraghuli A, Khan J, Sumesh EP, Lavanya V.
Dispositivo vestível baseado em IoT para monitorar os sinais de pacientes
remotos em quarentena de covid-19. Informática em Medicina desbloqueada.
2021;24: 100588. https://doi.org/10.1016/j.imu.2021.100588.
16. Paganelli AI, Velmovitsky PE, Miranda P, Branco A, Alencar P, Cowan D,
Endler M, Morita PP. Uma arquitetura conceitual de alerta precoce baseada
em IoT para monitoramento remoto de pacientes com Covid-19 em
enfermarias e em casa. Internet das Coisas. 2021;100399. https://
doi.org/10.1016/j.iot.2021.100399.
17. Mukherjee A, Ghosh S, Behere A, Ghosh SK, Buyya R. Internet de coisas de
saúde (ioht) para cuidados de saúde personalizados usando rede integrada
edge-fog-cloud. J Ambient Intell Humaniz Com-put. 2021;12:943–59.
18. Chudhary R, Sharma S. Estrutura assistida por nuvem de neblina para internet
heterogênea de coisas de saúde. Procedia Ciência da Computação.
2021;184, 194–201. https://doi.org/10.1016/j.procs.2021.03.030.
A 12ª Conferência Internacional sobre Sistemas, Redes e Tecnologias
Ambientais (ANT) / A 4ª Conferência Internacional sobre Dados Emergentes
e Indústria 4.0 (EDI40) / Workshops Afiliados.
19. Sangeetha D, Rathnam MV, Vignesh R, Chaitanya JS, Vaidehi V.
In: Vijayakumar, V., Neelanarayanan, V., Rao, P., Light, J. (eds.).
MEDIDRONE — Um sistema de saúde inteligente baseado em análise
preditiva; 2020. pp. Springer, Singapura. https://doi.org/10.
1007/978-981-32-9889-7_2.
20. Priambodo R, Kadarina TM. Monitorando paciente em auto-isolamento de
covid-19 com internet das coisas. In: Conferência Internacional IEEE 2020
sobre Comunicação, Redes e Satélite (Comnetsat); 2020. pp. https://doi.org/
10.1109/Comnetsat50391.2020.9328953.
21. Aziz K, Tarapiah S, Ismail SH, Atalla S. Sistema inteligente de monitoramento
e rastreamento de cuidados de saúde em tempo real usando tecnologias
GSM/GPS. In: 3ª Conferência Internacional do MEC sobre Big Data e
Cidades Inteligentes (ICBDSC) 2016; 2016. pp. https://doi.org/10.1109/
ICBDSC.2016.7460394.
22. Sicari S, Rizzardi A, Coen-Porisini A. Monitoramento domiciliar de pacientes
em quarentena na era da doença covid-19. Saúde Inteligente. 2022;23:100222.
https://doi.org/10.1016/j.smhl.2021.100222.
23. Rahmani AM, Gia TN, Negash B, Anzanpour A, Azimi I, Jiang M, Liljeberg P.
Explorando gateways inteligentes de e-saúde na borda da internet das coisas
em saúde: uma abordagem de computação em névoa. Futur Gener Comput
Syst. 2018;78:641–58. https://doi.org/10.1016/j.
futuro.2017.02.014.
24. Kamel Boulos MN, Berry G. Sistemas de localização em tempo real (rtls) na
área da saúde: uma cartilha condensada. Int J Health Geogr. 2012;11(1):1–8.
13
Machine Translated by Google
25. Xu X, Lu Y, Vogel-Heuser B, Wang L. Indústria 4.0 e indústria 5.0 - início,
concepção e percepção. J Manuf Syst. 2021;
61:530–5.
26. Chabi Sika Boni AK, Hablatou Y, Hassan H, Drira K. Arquitetura de
aprendizagem por reforço profundo distribuída para transferência de
tarefas em sistemas IoT autônomos. In: Anais da 12ª Conferência
Internacional sobre Internet das Coisas. IoT 2022; 2023. pp.
112–118. Association for Computing Machinery, Nova York, NY, EUA.
https://doi.org/10.1145/3567445.3567454.
27. Xiao X, Hannan A, Bailey B, Ni LM. Engenharia de tráfego com mpls na
internet. Rede IEEE. 2000;14(2):28–33. https://doi.
org/10.1109/65.826369.
28. Yang Z, Cui Y, Li B, Liu Y, Xu Y. Rede de área ampla definida por software
(sd-wan): Arquitetura, avanços e oportunidades. In: 28ª Conferência
Internacional sobre Comunicação e Redes de Computadores 2019
(ICCCN); 2019. pp. https://doi.org/10.1109/
ICCCN.2019.8847124.
29. Alloghani M, Alani MM, Al-Jumeily D, Baker T, Mustafina J, Hussain A, Aljaaf
AJ. Uma revisão sistemática sobre o status e o progresso das tecnologias
de criptografia homomórfica. J Inf Secur Appl. 2019;48:102362. https://
doi.org/10.1016/j.jisa.2019.102362.
[Artigo gratuito do PMC] [PubMed] 30. Moysiadis V, Sarigiannidis P, Moscholios I. Rumo ao
gerenciamento de dados distribuídos na computação em névoa. Computação mob sem
fio comum. 2018;2018.
31. Abdelhafiz BM, Elhadef M. Fragmentação de banco de dados para
tolerância a falhas e escalabilidade de dados. In: 2021 2ª Conferência
Internacional sobre Computação, Automação e Gestão do Conhecimento
13
Saúde e Tecnologia
(ICCAKM); 2021. pp. https://doi.org/10.1109/ICCAK
M50778.2021.9357711.
32. Rouhani S, Zamenian S. Uma estrutura arquitetônica para design de
painéis de saúde. J Saúde Eng. 2021;2021, 1964054. https://doi.org/
10.1155/2021/1964054.
33. Simpson SH. Criando um plano de análise de dados: O que considerar ao
escolher estatísticas para um estudo. Pode J Hosp Pharm. 2015;68(4):311–
7. https://doi.org/10.4212/cjhp.v68i4.1471.
34. Caroline Gonçales P, Pinto Júnior D, de Oliveira Salgado P, Machado
Chianca TC. Relação entre estratificação de risco, mortalidade e tempo
de permanência em hospital de emergência. Invest Educ Enferm.
2015;33(3):424–431. https://doi.org/10.17533/udea.iee.v33n3a05.
35. Ghazisaeidi M, Safdari R, Torabi M, Mirzaee M, Farzi J, Goodini A.
Desenvolvimento de painéis de desempenho no setor de saúde: principais
questões práticas. Acta informatica medica: AIM: jornal da Sociedade de
Informática Médica da Bósnia e Herzegovina: casopis Drustva za
medicinsku informatiku BiH. 2015;23(5):317–
21. https://doi.org/10.5455/aim.2015.23.317-321.
Nota do editor A Springer Nature permanece neutra em relação a reivindicações
jurisdicionais em mapas publicados e afiliações institucionais.
A Springer Nature ou seu licenciante (por exemplo, uma sociedade ou outro
parceiro) detém direitos exclusivos sobre este artigo sob um contrato de
publicação com o(s) autor(es) ou outro(s) detentor(es) de direitos; o
autoarquivamento do autor da versão manuscrita aceita deste artigo é regido
exclusivamente pelos termos de tal contrato de publicação e pela lei aplicável.