PROGRAMA DE PÓS-GRADUAÇÃO EM TECNOLOGIA DA INFORMAÇÃO MESTRADO PROFISSIONAL EM TECNOLOGIA DA INFORMAÇÃO
Um Módulo de Protocolo para Aplicações de IoT em Saúde
Ari Barreto de Oliveira
Natal-RN Dezembro de 2020
Um Módulo de Protocolo para Aplicações de IoT em Saúde
Qualificação de Mestrado apresentada ao Programa de Pós-graduação em Tecnologia da Informação da Universidade Federal do Rio Grande do Norte como requisito parcial para a obtenção do grau de Mestre em Tecnologia da informação.
Universidade Federal do Rio Grande do Norte – UFRN Instituto Metrópole Digital – IMD
Programa de Pós-Graduação em Tecnologia da Informação
Orientador: Prof. Dr. Gustavo Girão Barreto da Silva
Natal/RN
2020
Oliveira, Ari Barreto de.
Um módulo de protocolo para aplicações de IoT em saúde / Ari Barreto de Oliveira. - 2020.
68 f.: il.
Dissertação (mestrado profissional) - Universidade Federal do Rio Grande do Norte, Instituto Metrópole Digital, Programa de Pós-Graduação em Tecnologia da Informação, Natal, RN, 2021.
Orientador: Prof. Dr. Gustavo Girão Barreto da Silva.
1. Internet das coisas - Dissertação. 2. IoT - Dissertação.
3. Cuidados de saúde. 4. Módulo de inteligência. 5. Módulo de protocolo. I. Silva, Gustavo Girão Barreto da. II. Título.
RN/UF/BCZM CDU 004.4:616 Catalogação de Publicação na Fonte. UFRN - Biblioteca Central Zila Mamede
Elaborado por Ana Cristina Cavalcanti Tinôco - CRB-15/262
Um Módulo de Protocolo para Aplicações de IoT em Saúde
Prof.º Dr. Gustavo Girão Barreto da Silva (Orientador)
Prof.º Dr. Itamir de Morais Barroca Filho (Membro Interno)
Prof.ª Dra. Monica Magalhães Pereira (Membro Externo ao Programa)
Prof.º Dr. Ivan Saraiva Silva (Membro Externo à Instiuição)
Natal-RN Dezembro de 2020
Dedico este trabalho aos mais de um milhão e 500 mil mortos por COVID-19 no mundo no ano de 2020.
Agradecimentos
Agradeço à Deus pela vida e pela oportunidade de estudar.
Agradeço a minha esposa Mikaely, que tanto me deu apoio, incentivo e ajuda em todas as horas. Se não fosse por ela nem aqui estaria. E agradeço ao nosso pequeno e amado Pedro, de 3 anos. Sempre escolheu as melhores horas para pausar meus estudos (à força) e me dar alguns minutos de descanso (e brincadeiras para ele).
Não posso esquecer de agradecer à minha querida sogra, aos meus pais, irmãos e toda a família, que também deram apoio sempre que necessário para que eu pudesse cumprir as atividades de trabalho e estudo nesta fase da vida.
Agradeço ao meu pai, o professor Dr. José Arimatés de Oliveira (UFRN), pela ajuda e por servir de inspiração em minha carreira acadêmica.
Não posso esquecer dos meus amigos Roberto e Vitor pelas tecnologias ensinadas e ao meu primo Cephas pelo apoio em todos os momentos.
E por fim, agradeço ao meu orientador Girão pela paciência e inspiração neste processo. Espero ter sempre a mesma paciência e visão estratégica com meus alunos também.
A todos, o meu muito obrigado. De coração.
Resumo
A Internet das Coisas está em pleno crescimento e cada vez mais dispositivos estão conectados, gerando grande quantidade de dados. Em algumas áreas, esta grande quantidade de dados gerados não é plenamente usada para a descoberta de informações adicionais. Isto é uma realidade na área da saúde, onde já há a possibilidade de geração de dados a partir de dispositivos que usem protocolos abertos ou sensores de hardware de código aberto conectados, como sensores de ambiente ou sensores de corpo humano. Esta dissertação tem como objetivo propor um módulo de protocolo que possa, através de dados oriundos de sensores de IoT em saúde, ajudar a equipe de saúde a obter informações úteis, trazendo, desta forma, benefícios diretos para a saúde do paciente e agilidade do atendimento hospitalar e redução de custos. Aqui foi realizada a implementação de um Módulo de Protocolo e de um Módulo de Verificação, indicando possíveis benefícios da utilização de tal arquitetura no monitoramento de pacientes com COVID-19.
Palavras-chave: IoT, cuidados de saúde, módulo, protocolo, inteligência
Abstract
The Internet of Things is growing and every day more devices are connected, generating massive amounts of data. In some areas, this large amount of data is not always used to discover additional information. This is also a reality in healthcare where it is already possible to generate large amounts of data from devices that use open protocols or open-source hardware sensors such as environment sensors or human body sensors. This dissertation aims to propose an intelligence module that can, through data from IoT sensors in health, help the health team to obtain useful information, thus bringing direct benefits to the patient's health and speed of care hospital and cost reduction. Here, an Intelligence Module and a Verification Module were implemented, indicating possible benefits of using this architecture in monitoring patients with COVID-19.
Keywords: IoT, healthcare, platform, protocol, intelligence
Lista de Ilustrações
Figura 1: Estimativa do número de Unidades de IoT instaladas, por categoria em 2018 (CSI
MAGAZINE, 2016) ... 12
Figura 2: Contexto deste trabalho e contribuições de outros autores ... 14
Figura 3: Modelo de uso do Padrão HL7. Fonte: RADES (2019) ... 18
Figura 4: Arduino Uno R3. Fonte: Site oficial arduino.com ... 19
Figura 5: e-Health Sensor Platform para Arduino conectado a todos os seus sensores. Fonte: Cooking Hacks (2019). ... 20
Figura 6: Índice da comunidade de programação, com destaque para JAVA (TIOBE, 2020) ... 22
Figura 7: Arquitetura de Referência em Saúde proposta. Fonte: BARROCA FILHO (2018) 31 Figura 8: Arquitetura de Referência proposta. Fonte CHEN (2012). ... 32
Figura 9: Arquitetura do aplicativo móvel e-Health care system. Fonte: Jang et al. (2011) .. 33
Figura 10: Análise da frequência dos sinais recebidos para determinar padrões. Fonte: Jang et al. (2011) ... 34
Figura 11: Arquitetura do sistema de ECG. Fonte: BANZILA e DAVID (2013) ... 35
Figura 12: Arquitetura para sistemas de saúde com IoT utilizando Fog Computing. Fonte: MONTEIRO et al. (2018) ... 35
Figura 13: Arquitetura para monitoramento de Saúde. Fonte: DOLUI e DATTA (2014) ... 37
Figura 14: Espirômetro e Acelerômetro para medição de frequência respiratória. Fonte: FEKR et al.(2015) ... 38
Figura 15 - Google Flu Trends analisando casos de gripe da África do Sul de 2006 a 2015 39 Figura 16 - Sintomas apresentados por pacientes que testaram positivo ou negativo para COVID-19 ... 40
Figura 17: Arquitetura de Referência utilizada baseada na proposta de BARROCA FILHO (2018), com destaque ao módulo de Inteligência, equivalente ao Módulo de Protocolo aqui proposto. ... 44
Figura 18: Visão de decomposição do coletor de dados de Oliveira (2020) ... 46
Figura 19: Arquitetura resumida, com detalhamento interno do funcionamento do módulo de protocolo. ... 47
Figura 20: Diagrama de Classes do Módulo de protocolo, conforme implementado ... 49
Figura 21: Software ItelliJ IDEA editando código fonte da API ... 52
Figura 22: Página principal do Módulo de Validação, conforme implementado ... 53
Figura 23: Ambiente de testes, visualização da tabela de regras. ... 54
Figura 24: Origem das nomenclaturas relacionadas ao COVID-19 (Fonte: GORBALENYA et al. 2020) ... 61
Lista de Tabelas
Tabela 1: Trabalhos relacionados, suas contribuições e diferenças ... 42 Tabela 2: Exemplo de tabela de regras simples baseadas em intervalo cronometrado. ... 51 Tabela 3: Detalhamento da API do módulo de protocolo ... 60
Lista de Abreviaturas
AI Artificial Intelligence
AJAX Asynchronous JavaScript and XML API Application Programming Interface
ASCII American Standard Code for Information Interchange BI Business Intelligence
BPM Batimentos Cardíacos por minuto COVID-19 Coronavirus Disease 2019 CSS Cascating Style Sheet DA Data Acquisition DF Diagnostic Feedback
DM Decision Making
ECG Eletrocardiograma EJB Enterprise JavaBeans GPS Global Positioning System HL7 Health Level Seven
HTML Hyper Text Markup Language IoT Internet of Things
IP Internet Protocol
JSON JavaScript Object Notation LCD Liquid Cristal Display mmHg Milímetros de Mercúrio
REST Representational State Transfer UTI Unidade de Tratamento Intensivo XML Extensible Markup Language
Sumário
1 Introdução ... 11
1.1 Objetivos ... 13
1.1.1 Objetivos Específicos ... 14
1.1.2 Metodologia ... 14
2 IoT e Saúde ... 16
2.1 Padrão HL7 ... 16
2.2 Plataforma de sensores e-Health ... 18
2.3 Linguagens de programação e tecnologias ... 20
2.3.1 Java ... 21
2.3.2 Spring Framework ... 22
2.3.3 Spring Boot ... 22
2.3.4 Lombok ... 23
2.3.5 Maven ... 23
2.3.6 Testes ... 23
2.3.7 Tomcat ... 24
2.3.7 Arquitetura em e Microsserviços ... 24
2.3.7 HTML, CSS e JavaScript ... 25
2.4 Dados de Saúde ... 25
2.5 Análise dos dados e tempo de resposta ... 27
2.6 Disponibilização dos dados ... 28
2.7 Limitação de Grupo de Estudo ... 28
3 Trabalhos Relacionados ... 30
3.1 Aspectos importantes nos artigos ... 41
4 Proposta de um Módulo de Protocolo para IoT Aplicado à Saúde ... 43
4.1 A Arquitetura de referência base ... 43
4.2 A coleta de dados ... 44
4.3 Detalhamento do Módulo de Protocolo ... 46
4.3.1 Detalhamento da Arquitetura ... 48
4.4 Implementação e Validação da Arquitetura ... 51
4.4.1 Testes no Módulo de Validação ... 54
4.5 API ... 55
4.6 Perfil de Pacientes ... 60
4.6.1 Pacientes infectados por COVID-19 ... 61
5 Considerações Finais e Trabalhos Futuros ... 63
Referências ... 64
1 Introdução
Segundo ASHTON (2018), a Internet das Coisas (IoT, do inglês Internet of Things) pode ser considerada a grande primeira evolução da Internet. Isto porque, até então, a Internet era diretamente relacionada aos usuários e suas necessidades em cada dispositivo. A Internet das Coisas pode ser definida como uma tecnologia voltada para “coisas” que se conectam entre si, gerando dados ou executando ações de forma autônoma e, claro, se comunicando também com as pessoas (ATZORI et al., 2010).
É notável um grande crescimento do número de dispositivos conectados nos últimos anos. Desde 2008 estes já superam o número de habitantes na terra (MEULEN 2017), e podem chegar a 75 bilhões de dispositivos conectados até 2025, segundo LUCERO (2016).
Um exemplo deste panorama são as lâmpadas inteligentes, que mesmo quando não estão emitindo luz devem seguir conectadas, aguardando um comando de acendimento, seja de um usuário humano ou de outro sistema computacional. Outro exemplo são os dispositivos vestíveis, que monitoram constantemente a atividade física de uma pessoa, e podem emitir alertas caso algum dos índices esteja fora do intervalo desejável. Com esta visão, a tendência é que seja cada vez mais necessário que itens isolados se conectem para compartilhar informações. E assim como hoje é incomum ter um computador desconectado, em breve será incomum ter um aparelho de ar-condicionado ou uma cafeteira nesta mesma situação.
Mundialmente, a área de automação comercial e de domótica são, dentre as tecnologias de IoT, as que atualmente mais atraem investimento e com os maiores parques instalados de IoT no mundo, de acordo com a CSI MAGAZINE (2016). Apesar disto, muitas outras áreas podem também aproveitar os benefícios do crescimento, evolução e barateamento desta tecnologia para expandir suas possibilidades. A saúde é uma destas áreas (como visto na Figura 1). Nesta, o uso de IoT pode auxiliar em diversos campos, seja agilizando o atendimento médico, o tempo de resposta para emergências, prevendo a ocorrência de eventos graves, dentre outras possibilidades. Em todos os casos, o benefício esperado é a melhoria na qualidade e expectativa de vida do público usuário desta tecnologia (DATTA 2015).
Com a pandemia de COVID-19, ficou ainda mais intensa a busca por equipamentos pessoais de sensoriamento de saúde (ATES et al 2021). Termômetros e oxímetros de pulso, por exemplo, se tornaram ainda mais populares. Um dos impactos disto foi que muitos dispositivos “wearable” (em português, vestíveis), como relógios inteligentes, incorporaram estas funcionabilidades em seus últimos modelos. Com eles é possível acompanhar dados interessantes sobre a saúde do usuário, como batimentos cardíacos, oxigenação do sangue e temperatura corporal - a depender do modelo do dispositivo.
As demandas da área de saúde que podem ser auxiliadas pela IoT são extensas, envolvendo desde as necessidades em hospitais e estabelecimentos de atenção à saúde, passando pelas ambulâncias e ambientes de emergência chegando até aos ambientes de home care (ou seja, cuidados de saúde em casa). Mesmo com todas estas possibilidades, a área de saúde ainda não se utiliza plenamente destas tecnologias, tendo, de acordo com a Figura 1 (na série Healthcare), uma das menores participações no mercado de IoT.
Figura 1: Estimativa do número de Unidades de IoT instaladas, por categoria em 2018 (CSI MAGAZINE, 2016)
Em ambientes de UTI, por exemplo, pacientes são habitualmente monitorados por equipamentos hospitalares que costumam exibir os dados em monitores paramétricos, localizados a vista dos profissionais de saúde. Sua principal função, indiscutivelmente é exibir em tempo real os valores obtidos, bem como fornecer alertas sonoros e visuais quando os valores saírem do padrão de normalidade. Em geral, os dados históricos gerados são armazenados no equipamento por algumas horas, apenas para que seja possível ser observada a média, máximos e mínimos dos valores no período. Porém, o registro definitivo é realmente feito pela equipe de enfermagem: periodicamente um profissional deve ir até próximo do monitor para anotar as informações apresentadas no prontuário do paciente.
Quanto às ambulâncias, os protocolos de funcionamento podem variar de acordo com a gestão e o objetivo do deslocamento. Um caso comum de uso das ambulâncias é no momento do translado de um paciente em estado de urgência ou emergência para um centro hospitalar especializado. Quando é recebida uma chamada de emergência solicitando, por exemplo, uma ambulância para ir até a casa de um paciente em cuidados domiciliares, o ambiente da ambulância (equipamentos e profissionais) é rapidamente preparado baseado
nas informações de estado de saúde que foram passadas quando a chamada foi realizada.
Caso o paciente (antes da chegada da ambulância) tenha alguma mudança repentina de estado (por exemplo uma parada cardíaca), será necessário que a equipe da ambulância seja avisada por telefone, ainda durante o trajeto de ida. Em um cenário perfeito, a equipe da ambulância deveria ter acesso em tempo real aos dados do paciente, desde o momento que foi acionada até a entrega dele no destino.
Durante a pandemia de COVID-19, se tornou necessário o monitoramento simultâneo de milhões de infectados, com o objetivo de acompanhar seus sintomas e realizar, caso necessário e no tempo propício, sua internação hospitalar. Neste cenário existe um grande benefício na utilização de dispositivos IoT para coleta e análise de dados da saúde do paciente em tempo real, que é a possibilidade de prever a lotação de setores e programar transferências internas de pacientes. Não apenas isto, mas também poderia haver uma otimização no processo das transferências externas, pois a equipe poderia, através dos dados em tempo real do paciente, escolher o momento ideal para realizar cada transferência.
Estes fatores indicam que a atual forma de utilização dos dados de sensoriamento de saúde pode ser melhorada, com o objetivo de gerar benefícios tanto para o paciente quanto para os profissionais e serviços de saúde envolvidos. Estes benefícios estão relacionados com a agilidade na identificação de problemas de saúde (aferíveis por sensores) em um paciente, a rápida notificação das equipes e a possibilidade de obter prognósticos sobre a saúde do paciente.
1.1 Objetivos
O objetivo desta dissertação é a concepção, detalhamento e desenvolvimento de um módulo de protocolo, baseado em uma arquitetura de referência para IoT em saúde criada e descrita na tese de doutorado do professor Itamir Barroca Filho (BARROCA FILHO, 2018).
O “Módulo de Protocolo” aqui proposto significa uma parte reutilizável de software com a função de fornecer informações úteis sobre dados obtidos de sensores de IoT para Saúde.
Sua “inteligência” pode ser enquadrada na categoria de sistema especialista, simulando a decisão de um profissional da área, porém sem usar obrigatoriamente técnicas de Inteligência Artificial.
1.1.1 Objetivos Específicos
• Pesquisar e relatar as principais técnicas utilizadas para a análise de dados de sensores de IoT para saúde;
• Analisar as possibilidades de monitoramento para pacientes com COVID-19;
• Descrever a arquitetura de um módulo de protocolo que gere informações relevantes baseado nos dados dos sensores
• Validar a arquitetura proposta através de um Módulo de Validação
1.1.2 Metodologia
Para atingir estes objetivos, inicialmente foi realizado um levantamento literário das técnicas atualmente utilizadas para gerenciar sensores de IoT em Saúde, auxiliar na geração de diagnósticos e prognósticos e disponibilizar os dados obtidos para a cadeia de profissionais de saúde que necessitem dos dados. Este levantamento foi feito através de pesquisas de artigos em bancos de dados científicos.
Para a captura de dados pelos sensores foi usado como referência o trabalho de Lúcio Oliveira (OLIVEIRA, 2018), que descreveu um coletor de dados para aplicações de saúde baseadas na infraestrutura de IoT, dentro da mesma arquitetura de referência aqui estudada.
Os dados são obtidos por sensores junto ao paciente e então encaminhados para um módulo seguinte.
Por fim, foi aqui apresentado um módulo de software baseado em conceitos observados no levantamento da literatura, com técnicas efetivas para aproveitamento dos dados obtidos. Com isso, é capaz de gerar informação útil sobre a saúde do paciente e subsídios para tomada de decisão humana ou automatizada. A Figura 2 apresenta um diagrama, indicando o contexto deste trabalho e a contribuição de outros autores.
Para exemplificação e foco, foi definido como objetivo o monitoramento específico de pacientes infectados com COVID-19. É possível, porém, que as técnicas e resultados aqui demonstrados, possam ser aplicados a outros grupos de pacientes, com outro perfil de acompanhamento e patologias.
Figura 2: Contexto deste trabalho e contribuições de outros autores
O restante deste texto está dividido da seguinte maneira: No capítulo 2 é abordado o uso de Internet das Coisas na saúde, as tecnologias existentes e desafios. No capítulo 3 são listados trabalhos relacionados, destacando seus pontos positivos e negativos em relação a este. No capítulo 4 o módulo é apresentado e detalhado. Por último, no capítulo 5, estão descritos a conclusão e os próximos passos que podem ser realizados nesta mesma linha.
2 IoT e Saúde
As aplicações de IoT em saúde estão em constante crescimento, mas ainda distante de sua plena potencialidade, frente as possibilidades atuais. De acordo com JAIGIRDAR et al. (2019), existem já tecnologias em fase inicial, mas espera-se que nos próximos anos aconteça um grande crescimento nesta área.
Nas pesquisas realizadas neste trabalho, foi encontrada na academia uma significativa quantidade de publicações enumerando as novas possibilidades de aplicação de IoT na saúde, formas de sensoriamento, tratamento e armazenamento dos dados gerados, como pode ser visto nas publicações de PETRELLIS et al. (2019) e POENARU (2013), por exemplo, que descreveram diferentes tecnologias de sensoriamento de pacientes com uso de IoT.
Alguns autores também discutem sobre a possibilidade de integrar os dispositivos médicos atuais com redes de IoT, para não apenas disponibilizar dados coletados, mas até mesmo para o gerenciamento dos equipamentos e sua manutenção de uma forma geral (AZRA e DACHYAR, 2020).
Outros autores ainda, como BARROCA FILHO (2018), conforme já mencionado, detalham propostas de arquiteturas para sensoriamento e controle com IoT para aplicações hospitalares. Através delas é possível realizar a integração de diferentes dispositivos IoT em uma aplicação única, compartilhando dados com todas as áreas do atendimento de saúde.
Estas arquiteturas apresentam propostas de fluxo dos dados do paciente, desde a coleta dos dados, seu armazenamento, políticas de segurança para disponibilização dos dados e integração com outros sistemas de atenção à saúde.
2.1 Padrão HL7
SIMBORD (1987) descreve o HL7 (Health Level 7) como um padrão desenvolvido para a indústria da saúde, com objetivo de permitir a troca de informações entre diferentes equipamentos e aplicativos relacionados com tecnologia de informação para saúde, conforme pode ser visto na Figura 3. Ele é assim chamado pois atua no sétimo nível do protocolo de redes OSI (a “camada de aplicação”). Isto significa, em outras palavras, que a forma de conexão física entre os dispositivos, a rede que os liga e seus protocolos não deverão ser um impeditivo para a intercomunicação dos dispositivos e sistemas com agilidade, segurança e confiabilidade.
A criação deste padrão de saúde ocorreu em 1987, devido a necessidade de integrar sistemas e dispositivos médicos que até então não tinham integração (RADES, 2018). Sua documentação determina o uso de vários padrões, como um protocolo de troca de mensagens que abrange todas as áreas de atenção e cuidados em saúde, garantias de
qualidade da transmissão, criptografia e segurança dos dados. Pela padronização gerada, alguns problemas clássicos na indústria da saúde ganharam solução. Como exemplo, podemos citar a possibilidade de rapidamente obter o prontuário de um paciente, para que seja usado por um prestador de serviço de saúde. Isto é possível, por exemplo, pois o HL7 determina o padrão para que todos os dados sejam criados e transmitidos, incluindo até prontuários médicos.
Como benefício, a indústria de saúde obtém uma redução de custos para a integração de diferentes sistemas de saúde, uma vez que todos os desenvolvedores e prestadores de serviço poderão rapidamente acessar e transferir dados de maneira uniforme, sem teoricamente necessitar compreender a tecnologia específica criada por cada fabricante.
Além disto, equipamentos antigos poderão ser reutilizados ou ter seu uso prolongado na integração com outros sistemas (LEVIN, 2019). Assim, um hospital poderia, por exemplo, comprar um aplicativo de celular que se integre com os sistemas atuais e gere novos relatórios, sem para isto ter que substituir equipamentos ou sistemas.
É importante salientar que o HL7 é um padrão aberto e gratuito desde 2013, ou seja, pode ser usado e licenciado sem custo, permitindo aos desenvolvedores a sua utilização plena, sem limites. A opção de licenciamento pago, oferecido pelo desenvolvedor, a Health Level Seven International, é necessário apenas para desenvolvedores que desejem implementar novos padrões ou desejem receber suporte técnico especializado.
Apesar de não ser o único padrão existente mundialmente, o HL7, criado em 1987, chegou a ser reconhecido em 2005 em publicações como sendo um dos padrões mais influentes do mundo no campo da informática médica (KONCAR, 2005; SHAVER, 2015).
Ainda hoje, os padrões da HL7 são adotados por grandes órgãos de padronização, como o American National Standards Institute (ANSI) e a International Organization for Standardization (ISO), conforme SHAVER (2015). Atualmente, seus padrões são utilizados nas versões 2 e 3. A segunda (HL7 v2) versão é amplamente utilizada, sendo compatível com versões anteriores, e transmite seus dados através de cadeias ASCII. De acordo com a RADES (2017), a terceira versão do HL7 (v3), utiliza escrita XML e não é retrocompatível.
Por este motivo, é uma versão, atualmente, menos utilizada globalmente.
A existência do HL7 mostra que é possível realizar a interligação de diferentes sistemas e dispositivos médicos, com o objetivo de interligar informações. Caso se deseje implementar um novo sistema, usando dispositivos IoT, por exemplo, seria possível aproveitar toda a infraestrutura já existente (e compatível) no hospital para gerar uma só base de dados e decisões.
Figura 3: Modelo de uso do Padrão HL7. Fonte: RADES (2019)
2.2 Plataforma de sensores e-Health
O Arduíno tem papel fundamental no crescimento da Internet das Coisas (CHARALAMPOS, 2012). De acordo com SOUZA et al. (2011), o Arduíno é uma placa eletrônica cujo projeto é de acesso público e gratuito, composta por um microcontrolador, de forma que, sozinha, esta pode operar sensores e atuadores, recebendo e enviando dados digitais e analógicos. Além disto, seu projeto simples fez com que pudesse ser comercializada a baixo custo. Por estes motivos, ela se tornou uma placa ideal para desenvolvedores de soluções em hardware e estudantes da área, por exemplo. A Figura 4 mostra o modelo Arduino Uno, um dos mais populares modelos (MITCHELL, 2018).
Existem alternativas de placas eletrônicas com o mesmo objetivo do Arduíno. Algumas utilizam o mesmo formato e aspectos técnicos semelhantes, sendo denominadas
“compatíveis com Arduíno”. As placas “Arduíno Severino”, e “Marminino” são exemplos de projetos gratuitos criados por brasileiros, que podem ser montadas utilizado componentes facilmente encontrados em lojas de componentes eletrônicos, conforme descrito por SILVA e TELES (2016).
Algumas placas para dispositivos IoT disponíveis no mercado, porém, adotam outros formatos, outra arquitetura e não são compatíveis com Arduíno. Por exemplo, esp8266,
esp32, Raspberry PI e Intel Galileo são placas de prototipagem, não compatíveis com Arduíno mas que em geral podem desempenhar a mesma função (ŠKRABA et al., 2017).
Figura 4: Arduino Uno R3. Fonte: Site oficial arduino.com
Para aumentar as possibilidades de uso das placas Arduíno, desenvolvedores fabricam diversas placas acopláveis (chamadas também de Shields) para que sejam conectadas diretamente em um Arduino e assim forneçam novas possibilidades, como por exemplo conexão com internet, botões físicos, visores LCD, etc.
O e-Health Sensor Platform, ou simplesmente e-Health Shield (Figura 5) é um destes shields fabricados. Trata-se de um dispositivo que tem como objetivo principal realizar a conexão de sensores médicos a um Arduino convencional. Em seu kit tradicional, vendido amplamente pela Internet, é possível encontrar o Shield juntamente com diversos sensores médicos. Uma vez em uso, os dados obtidos por este dispositivo podem ser enviados para outros sistemas de informação, com mais poder de processamento por exemplo, facilitando desta forma a análise, processamento, acionamento de notificações, dentre outras ações.
Figura 5: e-Health Sensor Platform para Arduino conectado a todos os seus sensores. Fonte: Cooking Hacks (2019).
Quanto aos seus sensores, o e-Health Shield (em sua versão “v2”) consegue monitorar as seguintes informações de um indivíduo:
● Posição do corpo
● Temperatura corporal
● Eletromiografia
● Fluxo de ar
● Resposta galvânica da pele
● Pressão sanguínea
● Oxigenação sanguínea
● Nível de glicose
Esta plataforma de sensores até poderia ser usada para a geração de dados reais de um paciente monitorado (se fosse regulamentada no país para tal), porém, seu principal objetivo é fazer a simulação da obtenção de dados de equipamentos hospitalares. Desta forma, é possível validar uma proposta de arquitetura de saúde em IoT, através da injeção de dados e a verificação posterior dos resultados.
2.3 Linguagens de programação e tecnologias
Além do hardware, ou seja, dos equipamentos necessários para o monitoramento dos pacientes, é importante também descrever todas as tecnologias de software, ou seja, as ferramentas, linguagens de programação e tecnologias (de um modo geral), que foram
utilizadas para o desenvolvimento do módulo de protocolo aqui proposto. Neste tópico, serão descritas as principais tecnologias aplicadas.
2.3.1 Java
Java é uma linguagem de programação criada na Sun Microsystems na década de 1990, que tem como uma de suas características principais ser multiplataforma, ou seja, pode ser executada em diferentes sistemas operacionais (HORSTMANN, 2008). Isto é possível pois não é uma linguagem compilada diretamente para código nativo do computador, mas sim para um “bytecode”, ou seja, um código intermediário que é interpretado por uma máquina virtual específica Java.
A linguagem Java foi escolhida para este estudo devido a uma série de características propícias, dentre as quais poderiam ser citadas:
• Ampla documentação e comunidade, para troca de informações e resolução de possíveis problemas durante o desenvolvimento da aplicação;
• Compatibilidade com grande quantidade de sistemas operacionais;
• É uma linguagem gratuita, assim como muitas das ferramentas e ambientes de desenvolvimento que podem ser utilizados para programação em Java;
• Grande quantidade de frameworks, ou seja, conjuntos de códigos reutilizáveis para agilizar o processo de desenvolvimento de software com qualidade.
Além destes fatores, Java é, há muitos anos, uma das linguagens mais usadas do mundo (TIOBE, 2020), o que aumenta a probabilidade da continuidade deste projeto por outras equipes que se interessem no futuro, bem como a fácil integração dos resultados com outros módulos existentes. A Figura 6 apresenta a evolução histórica das linguagens de programação, com destaque para JAVA. Foi observada, para esta pesquisa, a atividade da comunidade de desenvolvedores em diferentes plataformas virtuais, como Google, Bing, Yahoo!, Wikipedia, Amazon, YouTube e Baidu.
Figura 6: Índice da comunidade de programação, com destaque para JAVA (TIOBE, 2020)
2.3.2 Spring Framework
O Spring Framework é um conjunto de códigos para aplicações Java que auxiliam o desenvolvedor no desenvolvimento de aplicações, tornando o desenvolvimento mais simples, o código mais fácil de compreender e manter e oferecendo também uma série de módulos para persistência, segurança, testes, integração dentre outros (SPRING, 2020a).
Alguns destes fatores positivos são possíveis devido a características do framework, como a utilização da Inversão de Controle (IoC - Inversion of Control) e da Injeção de Dependência (DI - Dependency Injection). A Inversão de Controle está relacionada com a técnica de delegar para outros elementos o controle sobre a criação de objetos e execução de métodos. Desta forma, o programador fica livre de ter que gerenciar manualmente alguns comportamentos do objeto, pois serão gerenciados por este outro elemento. Quanto à Injeção de Dependência, trata-se de uma das formas de implementar a Inversão de Controle.
Uma questão importante é que o programador não é obrigado a utilizar todos os módulos disponíveis, podendo este escolher o que deseja usar, e rapidamente fazer uma aplicação. Desta forma, objetiva-se que o sistema gerado seja mais leve, por executar apenas componentes necessários.
2.3.3 Spring Boot
De acordo com SPRING (2020b), o Spring Boot é um framework auxilia com as tarefas de infraestrutura para aplicações stadalone, ou seja, aplicações independentes (dependendo
apenas do Java). Através de seu uso é possível criar diferentes aplicações, como uma API REST, aplicações web, dentre várias outras. A grande vantagem para o desenvolvedor que usa Spring Boot é que este poderá focar no desenvolvimento do código da regra de negócio de seu projeto e investir menos tempo na criação e configuração deste. Para tanto, este framework já possui até um servidor Tomcat (servidor Web, apresentado na seção 2.3.7) embarcado, de forma que o desenvolvedor poderá rapidamente colocar em produção o seu software. Por estes motivos, o código geral da aplicação se tornará mais simples e direto.
2.3.4 Lombok
O Lombok é uma biblioteca Java que tem como objetivo também simplificar o código de aplicações Java. O desenvolvedor poderá escrever menos códigos “boilerplate”, ou seja, códigos que sempre são incluídos no mesmo lugar, quase sem nenhuma alteração. Um exemplo destes códigos são os métodos de recuperação e configuração das propriedades das classes (conhecidos como getters e setters). Para tal, o desenvolvedor deverá inserir anotações especiais no código e no momento da compilação (com compiladores Maven ou Gradle) estes códigos Java serão adicionados automaticamente no momento da compilação (SOUZA, 2013).
2.3.5 Maven
De acordo com BEZERRA (2018), o Apache Maven é um gerenciador de construção (ou build) e dependências para aplicativos Java, baseado no conceito de Project Object Model (POM). Desta forma, ele permite ao desenvolvedor a configuração de dependências dos projetos através de um único arquivo chamado pom.xml. O Maven é construído utilizando uma arquitetura baseada em plugin, ou seja, é possível escrever plugins para fazer interface com compiladores de qualquer outra linguagem. Por este motivo, apesar de ser primariamente utilizado para construir e gerenciar projetos em Java, esta tecnologia também já pode ser utilizada para o gerenciamento de projetos escritos em C#, Ruby, Scala, dentre outras linguagens.
2.3.6 Testes
Os testes de software são uma atividade muito importante para verificar a qualidade do software e rapidamente encontrar problemas durante ou após o término do seu
desenvolvimento (TAHCHIEV 2010). Para estas atividades, neste projeto foram usadas três tecnologias: JUnit, Mockito e AssertJ.
O JUnit é um framework que gerencia testes de unidade de uma aplicação. Ele facilita tanto a criação como a manutenção dos códigos para verificar se os métodos das classes funcionam como esperado. Dentre as vantagens de utilizar este framework está o fato de ser um software de código livre e ser amplamente utilizado pela comunidade de desenvolvedores, o que facilita o processo de desenvolvimento por haver uma grande quantidade de exemplos disponíveis. Ao final da execução dos testes, um relatório é gerado sobre a execução de cada verificação.
Para testes também foi usada a biblioteca Java Mockito. Este componente cria “mocks”, ou seja, objetos que simulam o comportamento de determinadas classes ou métodos, sem a necessidade de usar a implementação real em partes determinadas do código. Esta abordagem é útil para testar um trecho de código isoladamente, ignorando outras dependências temporariamente.
E por fim, também foi utilizada o AssertJ, uma biblioteca de código aberto que que facilita verificações. Sua utilidade é oferecer métodos que se pareçam com afirmações e que não retornem erros. Caso a afirmação executada seja falsa, o teste falhará. Por exemplo, o código: assertThat(dataDeHoje).isToday(); irá verificar uma variável e validar se contém a data de hoje. Caso não tenha, o teste irá falhar.
2.3.7 Tomcat
O Tomcat é um servidor web Java, desenvolvido pela Apache, e implementa as tecnologias Java Servlet, JavaServer Pages, Java Expression Language e Java WebSocket.
Trata-se de um software gratuito, com ampla comunidade de desenvolvedores, e é distribuído sobre a licença “Apache License version 2” e é desenvolvido pelos melhores desenvolvedores do mundo (TOMCAT 2020). O objetivo de um servidor WEB é aceitar pedidos feitos por clientes HTTP (geralmente de navegadores de Internet), e servi-los com respostas também em HTTP.
2.3.7 Arquitetura em e Microsserviços
Arquitetura em microsserviços é um estilo, ou abordagem de arquitetura de software.
Sua definição indica que os componentes do software devem ser desmembrados em partes pequenas, de forma que cada uma delas seja independente, porém trabalhe em conjunto com as outras partes para executar uma mesma tarefa. Esta abordagem é o oposto do desenvolvimento tradicional monolítico, onde o sistema é um grande bloco único. De acordo
com FOWLER (2014), cada microsserviço executa em seu próprio processo e se comunicando com mecanismos leves, geralmente uma API de recurso HTTP.
Dentre as vantagens de se utilizar os microsserviços podem ser destacadas a facilidade e agilidade no desenvolvimento, a possibilidade de reutilização dos serviços em outras aplicações e a possibilidade de escalar rapidamente um serviço. Escalabilidade de um sistema diz respeito a possibilidade deste de estar preparado para crescer, ou aguentar maior carga.
A arquitetura proposta por Itamir (BARROCA FILHO 2018) é baseada em microsserviços, uma vez que cada módulo trabalhará de forma independente. O módulo de protocolo, aqui descrito, é um dos microsserviços poderão compor o sistema.
2.3.7 HTML, CSS e JavaScript
Apesar de não terem sido utilizadas para o desenvolvimento do módulo de protocolo, as tecnologias HTML, CSS e JavaScript foram utilizadas para gerar um sistema usado para validar a arquitetura, se conectando ao módulo de protocolo através de sua API.
HTML, ou HyperText Markup Language (em português, linguagem de marcação de texto) não é uma linguagem de programação, mas uma linguagem de organização de objetos dentro de um website (SILVA, 2019). Os navegadores de Internet (como Chrome ou Edge) fazem a interpretação da linguagem HTML para gerar uma página compreensível e exibi-la ao usuário. CSS, por sua vez, significa Cascating Style Sheet (em português folha de estilo em cascata), e tem como objetivo auxiliar na formatação, cor, espaçamento e demais aspectos visuais de uma página.
Já o JavaScript é uma linguagem de programação de script em alto nível, estruturada, interpretada, de tipagem dinâmica e fraca (SILVA, 2010). Apesar do nome, JavaScript não tem relação direta com a linguagem Java. É uma linguagem desenvolvida para ser executada dentro de navegadores de internet, juntamente com HTML e CSS, sendo atualmente suportada pelos principais navegadores de internet disponíveis.
Neste trabalho foi gerada uma página HTML, utilizando o Framework Bootstrap, que é um conjunto de códigos gratuitos para agilizar e padronizar o desenvolvimento Web, utilizando JavaScript e JQuery. Esta, por sua vez, é uma biblioteca gratuita de funções JavaScript.
2.4 Dados de Saúde
Uma abordagem interessante para sistemas que trabalhem com obtenção de fluxo de dados externos é seguir um pré-processamento, um processamento e um pós-
processamento dos dados. Isto significa que os dados precisariam ser inicialmente recebidos e organizados, num processo conhecido como pré-processamento. Neste processo, é comum que alguns dados sejam perdidos ou não consigam ser coletados, em seu processo de obtenção. Por exemplo, dados sobre a posição do corpo do paciente são obtidos instantaneamente, diferente dos dados de frequência cardíaca, que necessitam de alguns segundos para aferimento. Já dados de temperatura necessitam normalmente de mais tempo de preparação, para garantir a estabilização da temperatura obtida pelo sensor. Ao mesmo tempo, alguma falha no posicionamento do sensor pode prejudicar a leitura ou mesmo podem gerar atraso na coleta. O pré-processamento de dados é necessário para corrigir estas falhas e estabilizar os valores, que serão processados a seguir. Dados que cheguem atrasados demais, incompletos ou corrompidos devido à alguma falha no transporte, podem neste momento ser descartados, de acordo com a regra de negócio de cada aplicação.
O objetivo da fase de processamento é, efetivamente, transformar dados outrora brutos em informações úteis. Este processo pode ocorrer utilizando diferentes técnicas. Uma delas é a análise computacional dos valores, baseado em valores previamente descritos pela literatura médica considerando o perfil de cada paciente. Por exemplo, a análise da Glicose no sangue, que possui índices definidos para normalidade ou atenção para um paciente, mas que variam de indivíduo para indivíduo, de acordo com sua patologia. Esta análise pode ser feita de forma mais aprimorada se forem observados também diferentes sensores e o cruzamento dos valores destes. Por exemplo, enquanto uma pessoa se alimenta, a glicose normalmente sobe no sangue, porém deve se estabilizar minutos depois.
Outra estratégia é a análise de dados através de algoritmos de mineração de dados, que possam automaticamente, através da análise computacional, categorizar os pacientes em grupos que possam ser (posteriormente) rotulados como de maior ou menor risco, ou que demandem maior ou menor atenção e cuidados, por exemplo. Esta rotulação, deve ser calibrada, com a análise de especialistas em saúde. Uma vez realizada, seria possível verificar se algum paciente está, com o passar dos dias, migrando de um para outro perfil.
Após seu processamento e geração das informações necessárias, será preciso realizar um pós-processamento, para que este dado seja armazenado corretamente para fins históricos, disponibilizado para demais profissionais, para que notificações sejam disparadas, gerando ou não ações automáticas para cada resultado.
A parte deste fluxo que vai do recebimento dos dados (já pré-filtrados) até a geração da informação final, fazem parte de um, aqui denominado, “Módulo de Protocolo”. O objetivo é que este módulo possa ser usado por diferentes sistemas informacionais que possam fornecer como entrada os dados de sensores e obtenham como saída informações processadas e organizadas.
2.5 Análise dos dados e tempo de resposta
Além da coleta e distribuição dos dados, é necessário que seja pensado em um fluxo interno, dentro do Módulo de Protocolo, capaz de executar ações de tomada de decisão com a agilidade e precisão (que sistemas de saúde exigem). Isso porque algumas ações de resposta a emergência devem ser tratadas e executadas no ponto de processamento mais próximo (possível) ao paciente. Um bom exemplo é um sensor que detecta uma parada cardíaca em um paciente monitorado. Não seria tolerável que a ação de resposta para tal acontecimento dependa de um processamento longo, após o armazenamento e processamento dos dados históricos, por exemplo. Isso porque, dependendo dos cálculos que sejam feitos ou do intervalo de dados necessários, por falta de conexão ou por atrasos na rede, este evento poderia não ter resposta em tempo hábil, conforme descreveu RATHORE (2016).
Este dilema é o mesmo enfrentado por outros softwares, como por exemplo, o banco de dados de informações de tráfego do aplicativo de geolocalização Waze (FIRE et al., 2012).
Milhões de usuários ao redor do mundo enviam automaticamente informações sobre a velocidade que estão trafegando em uma determinada via. Quando esta informação é recebida pelo servidor do Waze, e muitas vezes até confirmada por outros usuários, é um excelente indicador para alertar outros usuários. Porém, às vezes, por problemas de software, ou hardware ou conexão de dados não consegue enviar estes dados, que acabam chegando apenas minutos ou horas depois do momento em que ocorreram. Em alguns casos, estes dados são úteis. Mas após um certo tempo de atraso, estes dados já são automaticamente descartados, pois o dado já não terá relevância para o banco de dados.
Por outro lado, os dispositivos de IoT comumente não possuem grande poder de processamento e armazenamento. A grande quantidade de dados gerados de diferentes sensores precisa ser recebida, tratada e processada em algum local com maior poder de processamento, para que possa gerar, através de análises mais profundas, previsões e possíveis diagnósticos/prognósticos. Muitas destas informações serão disponibilizadas antes mesmo que alguma intercorrência médica ocorra. Por exemplo, é esperado que seja possível detectar a probabilidade de uma parada cardíaca, apenas analisando o histórico do paciente atrelado com informações vindas de sensores de eletrocardiograma, pressão, batimentos, dentre outros. Seria possível, desta forma, categorizar pacientes em uma enfermaria, baseado na gravidade de seu estado de saúde no exato momento da análise.
Desta forma, um módulo de Protocolo em saúde deve conter tanto fluxos de análise rápida, para tomada de decisão imediata (verificação de valores simples e notificação imediata), como também análises com processamento mais detalhado.
2.6 Disponibilização dos dados
Um módulo de Protocolo para Internet das Coisas em Saúde precisa processar os dados e gerar informações para diferentes necessidades de saúde. Módulos de ambulância, módulo médico hospitalar e módulos administrativos possuem diferentes necessidades, baseado no mesmo montante de dados, conforme escreveu ASHTON (2018).
Para exemplificar, um módulo de ambulância necessita saber, de tempos em tempos, o estado de um paciente, além de ter sempre disponível o quadro geral de saúde dele. O problema é que, ao se trabalhar com sensor de IoT, a chegada dos dados não é padronizada.
Ou seja, alguns sensores enviam dados com frequência maior do que outros. Além disto, trabalhar com IoT e dispositivos sem fio prevê que, numa possível falta de comunicação temporária entre os sensores, alguns dados podem chegar fora de ordem ou muito atrasados.
Seria necessário um tratamento do fluxo de dados em tempo real, reagrupando-os e gerando um novo fluxo de dados para tal módulo.
Um módulo médico exigiria, possivelmente, mais informações históricas sobre o paciente, incluindo análises como a resposta do corpo do paciente a eventos anteriormente já realizados, evitando que a equipe médica realize procedimentos que anteriormente já se mostraram pouco eficazes ou perigosos para a vida do paciente.
Já um módulo administrativo poderia se aproveitar dos dados gerais dos pacientes para estimar o tempo de ocupação dos leitos em um hospital, prioridade para procedimentos ou para acolhimento, baseado no histórico de outros pacientes com dados do sensoriamento semelhantes. Desta forma, as estimativas e ações do serviço hospitalar poderiam ser mais precisas.
Assim, é possível ver que um módulo de protocolo precisa organizar os dados coletados e processados de forma que seja possível utilizá-los para diferentes ambientes.
2.7 Limitação de Grupo de Estudo
Um módulo de protocolo completo deve prever todas as informações específicas de um determinado paciente: desde dados pouco relevantes para este, indo até os valores críticos.
Deve também processar todo o fluxo de dados relacionados com este paciente, com o objetivo de ser o mais preciso possível.
Na área da saúde, diferentes patologias criam diferentes situações de análise para os pacientes monitorados. Por exemplo, pacientes com internação hospitalar de longa duração tem um perfil de saúde específico, diferentes de pacientes que pode deambular normalmente ou que estão em internação domiciliar. Pacientes com complicações cardíacas podem ter um perfil de batimento cardíaco diferente de pacientes sem tais alterações no coração, alterando
valores que possam ser referência em outras patologias. Assim, uma pressão sanguínea de 120x80 mmHg pode ser normal para um paciente, porém letal para outro.
Sabendo desta diversidade de possibilidades dentro da área de cuidados em saúde, para fins de estudo delimitaremos a observação dos dados dos pacientes a um grupo específico, onde seja possível observar corretamente os dados e os resultados obtidos. Desta forma, não testaremos todas as possibilidades de um módulo de protocolo, mas sim aquilo que é útil para este projeto.
Dente as muitas possibilidades, foi escolhida, por sua relevância no atual momento, o acompanhamento de pacientes infectados com COVID-19 em sua evolução clínica antes de uma internação hospitalar ou de sua transferência interna dentro de um hospital. Trata-se de um grupo crítico, que precisa de monitoramento em tempo real, e precisa que seus dados sejam avaliados, para que a indicação de internação ou transferência seja criada apenas quando realmente seja necessário, para reduzir ao máximo o estresse da rede hospitalar, como no caso da pandemia de COVID-19 iniciada em 2020 (NORONHA, 2020). Outro motivo para esta escolha foi a possibilidade de monitoramento de pacientes com este diagnóstico observando sensores comuns, como oxigenação do sangue, batimentos cardíacos, frequência respiratória dentre outros.
3 Trabalhos Relacionados
Pelas pesquisas bibliográficas realizadas durante o período de desenvolvimento desta dissertação, foi possível observar que existe uma boa e crescente quantidade de literatura disponível focada nesta área de estudo, dentro da área de IoT. Isto se deve ao estágio de crescimento de uso de tecnologias de IoT para saúde, conforme dados apresentados na Figura 1 e estudos de JAIGIRDAR et al. (2019). Foram realizadas diversas pesquisas bibliográficas utilizando o Google Acadêmico com combinações das principais palavras- chave foco deste trabalho (e-health, iot Health, health data mining, intelligence), que gerou, em 2019, aproximadamente 90 publicações aparentemente relacionadas. Após análise superficial dos artigos (analisando principais partes do texto), foram reduzidos para 29 artigos relacionados, relevantes para este trabalho. Destes, foram selecionados sete artigos com correlação grande relevância que, nos tópicos a seguir, serão resumidos. Também foi feita uma pesquisa sobre COVID-19, observando os artigos mais relevantes da área, de acordo com o Google Acadêmico (palavra chaves relacionadas a “COVID-19” e “symptoms”). Desta última pesquisa, três artigos foram aqui detalhados.
A partir das informações coletadas nestas publicações foi possível observar boas técnicas, as fragilidades dos modelos atuais e assim propor um módulo de protocolo relevante para futuros softwares de saúde.
1. Architectural design of IoT-based healthcare applications
Esta publicação é uma tese de doutorado, realizada na UFRN - Brasil, por Itamir Barroca Filho. Este trabalho apresenta uma sistematização do design arquitetural de aplicações de IoT para Saúde e propõe um novo modelo de arquitetura.
O primeiro nível de abstração da arquitetura de referência para saúde proposta descreve a arquitetura em quatro camadas, sendo: camada de serviços (responsável por serviços via API), camada de monitoramento (responsável pelo monitoramento dos pacientes, conversando diretamente com os sensores), camada intermediária (middeware para receber os dados monitorados e persisti-los na camada de serviços) e camada de qualidade de atributos (responsável por garantir que as aplicações IoT são seguras e confiáveis), conforme pode ser visto na Figura 7.
Figura 7: Arquitetura de Referência em Saúde proposta. Fonte: BARROCA FILHO (2018)
Esta publicação de Barroca Filho é relevante para esta dissertação pois detalha a necessidade do módulo de protocolo que, segundo o autor, receberia e poderia classificar os dados recebidos pelos sensores. Este módulo também poderia ser configurado com os valores críticos de cada paciente, para poder gerar as mensagens de alerta para os módulos que foram previamente configurados (ambulância, hospital, família, etc.).
Apesar de propor um “módulo de Inteligência” (equivalente ao “módulo de protocolo”
aqui descrito), esta publicação não dá detalhes de seu funcionamento nem das técnicas usadas para a classificação dos dados recebidos pelos sensores. Desta forma, baseado na arquitetura de referência sólida apresentada por Barroca Filho é que está sendo proposta nesta dissertação a construção de um módulo de protocolo.
2. Hybrid Decision Making in the Monitoring of Hypertensive Patients
Esta publicação, da Universidade de Beijing (2012) propõe um sistema híbrido de tomada de decisão e monitoramento usando técnicas de mineração de dados.
Na Figura 8 é possível observar a arquitetura proposta pelos autores, que a dividiram em três módulos, sendo eles:
● Módulo de Aquisição de Dados (DA Module): responsável por obter e persistir os dados dos sensores
● Módulo de Tomada de Decisão (DM Module): este é o módulo principal descrito neste trabalho. Ele primeiramente recebe os dados do módulo de aquisição de dados e realiza um pré-processamento, que envolve: limpar, integrar, selecionar e transformar os dados. Em seguida ele é colocado no algoritmo de mineração para aprendizado e classificação.
● Módulo de Feedback de Diagnóstico (DF Module): por fim, este módulo é responsável por se comunicar enviando alertas para os meios cadastrados. Este módulo inclui um banco de dados de conhecimento, para, a partir dos resultados gerados, gerar relatórios detalhados do que fazer, para cada caso. A notificação enviada será detalhada com toda análise crítica.
Figura 8: Arquitetura de Referência proposta. Fonte CHEN (2012).
Um fator importante foi o desvio de fluxo que ocorre no módulo de tomada de decisão, que rapidamente, mesmo antes de executar o algoritmo de Data Mining pode enviar notificações, agilizando o processo em caso de emergências.
Por fim, foi visto que o objetivo da arquitetura proposta pelos autores é o monitoramento de pacientes com hipertensão, sendo, desta forma, o objeto de estudo deste artigo muito semelhante ao foco de estudo desta dissertação. A principal diferença observada é em relação ao grupo estudado e os parâmetros observados, que se limitam ao acompanhamento de fatores relacionados a problemas cardíacos, enquanto nesta dissertação o objetivo é detalhar uma análise multisensorial.
3. Development of a Mobile e-Health Care System for Rapid Detection of Emergent Situations
Este artigo foi escrito por JANG et al. da Hoseo University da Coreia do Sul em 2011, e propõe um aplicativo para smartphones para detectar situações emergência, cruzando diferentes sensores independentes, como sensor de aceleração, vibração, temperatura e GPS. Seu objetivo é identificar situações de emergência gerais, como desmaios, quedas, febre e convulsões.
A arquitetura do sistema está demonstrada na Figura 9. O telefone celular seria utilizado para coletar as informações de sensores já presentes no aparelho, como aceleração, vibração, temperatura e GPS e em seguida analisar a frequência dos valores obtidos (Figura 10), para verificar se o paciente possivelmente caiu ou está em alguma situação de risco quando não possa, por conta própria, solicitar ajuda. Nos testes realizados pelos autores, conseguiram uma precisão de 86% de acerto na análise do evento ocorrido, avaliando caminhadas, convulsões e desmaios.
Figura 9: Arquitetura do aplicativo móvel e-Health care system. Fonte: Jang et al. (2011)
Os autores descreveram ainda que o sistema pode “aprender” padrões do paciente para melhorar a precisão dos diagnósticos gerados. Este aprendizado é baseado apenas na obtenção da média dos valores dos sensores.
Esta publicação de JANG et al. está relacionada com esta dissertação pois apresenta a possibilidade de processamento e tomada de decisão diretamente no primeiro ponto de
captação dos dados monitorados além de usar o cruzamento de valores de diferentes sensores para obter uma informação única.
O trabalho, porém, é limitado a situações de emergência gerais (desmaios, quedas, febre, convulsões), não utilizando sensores externos, nem focando em outros grupos de pacientes ou dificuldades de saúde em específico. Outra fragilidade é relacionada a persistência dos dados, que ocorre em um servidor externo, chamado de “centro de controle”, para onde periodicamente as informações são apenas enviadas e armazenadas. Neste local não ocorre nenhum processamento dos dados, seu objetivo é apenas fornecer dados históricos para os profissionais de saúde. Isto pode levar à conclusão de que de uma arquitetura de referência de mais qualidade poderia trazer melhores resultados para este sistema.
Figura 10: Análise da frequência dos sinais recebidos para determinar padrões. Fonte: Jang et al. (2011)
4. Wireless Intelligent Systems for Biosignals Monitoring Using Low Cost Devices
Esta publicação de BRANZILA e DAVID da Iasi University (Romênia) em 2013 descreve a utilização de dispositivos de baixo custo para obtenção e transmissão de dados de eletrocardiograma. No estudo, os autores utilizaram um Arduíno Uno para receber e transmitir as informações para o sistema computacional que gera gráficos a partir das informações.
Apesar de ser uma publicação de resultados modestos, sem prognósticos nem análise detalhada dos valores, esta publicação permanece aqui em trabalhos relacionados pois a obtenção e transmissão de valores vindos de eletrocardiograma não é uma tarefa simples,
pela grande quantidade de dados gerada e pela necessidade de sincronia dos mesmos para obter um diagnóstico preciso. Para contornar isto os autores desenvolveram um software simulador de ECG, para normalizar os sinais recebidos antes da transmissão. A Figura 11 apresenta a arquitetura do sistema.
Figura 11: Arquitetura do sistema de ECG. Fonte: BANZILA e DAVID (2013)
5. Developing an e-health system based on IoT, fog and cloud computing
Este artigo, escrito por MONTEIRO et al. da UFPB – Brasil em 2018, apresenta uma arquitetura para sistemas de saúde com uso de fog computing, conforme pode ser visto na Figura 12.
Figura 12: Arquitetura para sistemas de saúde com IoT utilizando Fog Computing. Fonte: MONTEIRO et al.
(2018)
Basicamente a arquitetura está dividida em níveis, iniciando nas camadas do paciente, dos sensores de IoT nos pacientes, e dos microcontroladores, responsáveis por unificar os dados e enviá-los para o próximo nível. Os dois próximos níveis são os dispositivos “fog” (do inglês, névoa) e o nível cloud (do inglês, nuvem). Os autores propuseram estes dois níveis separados para descrever a necessidade de um nível intermediário (névoa) antes do armazenamento definitivo (nuvem). Segundo os autores, a fog seria composta por dispositivos de média capacidade computacional (como o Raspberry PI) para pré-processar os dados e analisar de maneira superficial a necessidade de gerar alertas imediatamente. O nível CLOUD já teria possibilidade ilimitada de armazenamento e processamento, podendo, agora sim, realizar os processos de análise detalhada dos dados.
Esta abordagem é interessante pois é possível que a grande demanda de dados gerada em um ambiente hospitalar gere um fluxo muito intenso de dados, aumentando assim o tempo de resposta. Para o desenvolvimento do módulo de protocolo desta dissertação poderá ser necessário considerar fluxos com tempo de resposta mais baixo para ações de emergência.
6. Patient Health Management System using e-Health Monitoring Architecture
Os pesquisadores da Índia e da França MUKHERJEE et al. descreveram nesta publicação de 2014 uma arquitetura completa para monitoramento de Saúde. A arquitetura deles, a princípio, não apresenta diferenciais positivos em relação a arquitetura usada como base desta dissertação (apresentada por BARROCA FILHO), como pode ser visto na Figura 13. É composta de uma camada de recepção (sensores), uma camada de serviços e uma camada de middleware e API’s, não especificando se há espaço para soluções de inteligência, nem onde estas estariam localizadas.
Figura 13: Arquitetura para monitoramento de Saúde. Fonte: DOLUI e DATTA (2014)
Ainda assim, a abordagem dos autores é interessante em alguns pontos específicos, como na camada de recepção. Nela, são mesclados dois tipos de sensores: sensores do ambiente e do paciente para que seja processado para um determinado paciente. Neste caso, sensores de ambiente podem ser usados para mais de um paciente, como em enfermarias, por exemplo.
7. Design and Evaluation of an Intelligent Remote Tidal Volume Variability Monitoring System in E-Health Applications
Este artigo foi escrito por FEKR et al. (2015), do Canadá, e detalha um sistema de inteligência para monitoramento de pacientes com foco em funções pulmonares. O autor cita importantes aspectos de dispositivos vestíveis de IoT bem como também aborda a integração de resultados de diversos sensores. Na Figura 14 é possível ver a comparação dos resultados de um sensor tradicional com outros sensores vestíveis, utilizando tecnologias diferentes (acelerômetro).
Figura 14: Espirômetro e Acelerômetro para medição de frequência respiratória. Fonte: FEKR et al.(2015)
Neste caso, devido ao uso de outras tecnologias mais acessíveis (acelerômetro de aparelho celular), foi necessário realizar um pré-processamento dos dados, para corrigir as falhas e aproximar o valor do real, conforme pode ser observado também na Figura 14. A publicação também descreve com muitos detalhes as fórmulas matemáticas utilizadas para a adaptação.
8. Defending against the Novel Coronavirus (COVID-19) outbreak: How can the Internet of Things (IoT) help to save the world?
RAHMAN et al. (2020) descrevem ações e tecnologias disponíveis para auxiliar no combate às pandemias. Essas tecnologias variam de plataformas de hardware de monitoramento de sinais vitais a smartphones, dispositivos vestíveis e até mesmo softwares que podem usar inteligência artificial para detectar eventos de possíveis epidemias e mais rapidamente do que os meios tradicionais.
Um desses métodos foi o Google Flu Trends, descontinuado em 2015, mas que, apesar de algumas falhas, alcançou resultados interessantes em várias situações, como a previsão de epidemias de gripe em alguns países em até 10 dias antes que as autoridades locais percebessem. A Figura 15 apresenta a atividade de buscas sobre gripe na África do Sul entre 2006 e 2015, por exemplo.
Figura 15 - Google Flu Trends analisando casos de gripe da África do Sul de 2006 a 2015
O método consistia em analisar os termos mais pesquisados em seu mecanismo de busca (febre, dor de cabeça etc.) e utilizar o IP do dispositivo para registrar a localização. A ferramenta foi descontinuada por falhas em seu método de avaliação (os sintomas pesquisados poderiam estar relacionados com outras doenças). Além disso, recebeu críticas relacionadas à violação da privacidade do usuário.
Os autores concluem que com os dispositivos atuais e com poder de processamento de dados e tecnologia de análise de dados disponíveis, seria possível (e necessário) propor sistemas que pudessem observar os dados do usuário de maneira segura e gerar dados úteis para as autoridades de saúde pública.
9. Association of chemosensory dysfunction and COVID-19 in patients presenting with influenza-like symptoms
O artigo apresentado por YAN et al. (2020) se concentra em descrever a correlação entre disfunção quimiossensorial e COVID-19, comparando-a com sintomas semelhantes aos da influenza, que podem estar associados a outras doenças também. A disfunção quimiossensorial é um dos sintomas mais comuns da COVID-19, que é a perda do olfato ou paladar.
Além de trazer essas informações, os autores realizaram uma pesquisa com pacientes para relacionar os principais sintomas e a probabilidade, com base nos resultados, de esses pacientes serem diagnosticados posteriormente com COVID-19 e outras doenças. Como
resultado, foram analisados 27 fatores como idade, sexo, internação (sim ou não), sintomas e comorbidades. A Figura 16 apresenta alguns dos resultados desta pesquisa.
Figura 16 - Sintomas apresentados por pacientes que testaram positivo ou negativo para COVID-19
Esta relação, listada pelos autores, é muito importante para embasar este trabalho sobre um módulo de protocolo para dados de IoT em saúde. Isto porque, fica claro que os dados coletados por sensores de IoT podem também ajudar a indicar que um paciente está ou não com COVID-19.
10. Clinical characteristics of 113 deceased patients with coronavirus disease 2019: retrospective study
Este trabalho apresenta os resultados de uma pesquisa realizada no Hospital Wuhan Tongji, por CHEN TAO et al. (2020), que comparou dados de pacientes que morreram em decorrência de complicações causadas pelo COVID-19 com os dados de outros pacientes que conseguiram se recuperar. Assim, foi possível identificar padrões de dados obtidos por meio do paciente que indicam maior ou menor risco de complicações e óbito para pacientes já infectados.
