Como o objetivo principal desse sistema ´e reportar anormalidades referentes aos sinais vitais do rec´em-nascido e que podem indicar um principio da SMSL, ´e necess´ario identificar em quais situa¸c˜oes se faz necess´ario um alerta e definir quais a¸c˜oes dever˜ao ser tomadas a partir dessa situa¸c˜ao.
Primeiro foram definidos os atores externos os quais s˜ao os alvos desses alertas. Como primeiro alvo o sistema deve informar aos pais da crian¸ca por meio de aplicativo m´ovel. Outra a¸c˜ao importante que o sistema deve tomar ´e notificar o Servi¸co de Sa´ude ou algum m´edico respons´avel, caso algum n´ıvel cr´ıtico seja atingido e seja necess´ario um r´apido atendimento especializado.
O primeiro alerta refere-se `a posi¸c˜ao do bebˆe no ber¸co. Esse alerta deve ser acio- nado quando a crian¸ca esta com a barriga voltada para baixo e n˜ao na posi¸c˜ao indicada pelos especialistas [4]. Como esse alerta ´e considerado n˜ao critico por n˜ao trazer s´erios riscos `a sa´ude do lactente, o sistema apenas deve enviar uma notifica¸c˜ao ao aplicativo m´ovel dos pais para que a crian¸ca seja reposicionada corretamente.
Como j´a foi apresentado na se¸c˜ao 2.1, outro importante fator de risco diz respeito ao n´ıvel de satura¸c˜ao de oxigˆenio no sangue, pois pode indicar diretamente o in´ıcio da hip´oxia e a falta de oxigena¸c˜ao tecidual. Dever˜ao existir dois tipos de alertas referentes a esse fator de risco, sendo que o primeiro deve ocorrer quando esse n´ıvel estiver abaixo de 95%, o que gera um alerta aos pais da crian¸ca como um sinal de alguma situa¸c˜ao que exige aten¸c˜ao. O segundo tipo de alerta deve ocorrer quando o n´ıvel de oxigena¸c˜ao alcan¸car valores abaixo de 90%, o que sugere uma poss´ıvel asfixia. Por ser um n´ıvel
alarmante, o sistema deve alertar n˜ao somente aos pais, mas tamb´em deve gerar o alerta para autoridades m´edicas.
Considerando que a frequˆencia card´ıaca normal para lactentes com menos de 1 ano pode variar entre 120 a 160 bpm [18], alertas sobre este parˆametro tamb´em devem ser con- templados. Tipicamente, quando os bebˆes est˜ao sofrendo asfixia, sua frequˆencia card´ıaca diminui, e o risco surge quando eles n˜ao tˆem uma resposta ativa a essa condi¸c˜ao [4]. A excita¸c˜ao do sono ´e o foco aqui, pois ´e desej´avel que os bebˆes demonstrem uma rea¸c˜ao `a asfixia e n˜ao apenas continuem sofrendo com ela, sendo considerada uma resposta essen- cial a um evento potencialmente fatal, como apneia prolongada ou hipotens˜ao. Portanto, tamb´em dever˜ao existir dois tipos de alertas para essa condi¸c˜ao: o primeiro deve ocorrer quando a frequˆencia card´ıaca estiver abaixo de 80 bpm por um per´ıodo de 30 segundos. Como o tempo ´e considerado relativamente curto, o sistema deve alertar somente aos pais do lactente. O segundo deve ocorrer quando a frequˆencia card´ıaca estiver abaixo de 80 bpm por um per´ıodo de 1 minuto, um tempo considerado suficiente para gerar um alerta n˜ao somente aos pais, mas tamb´em para as autoridades m´edicas.
Pelos motivos citados a respeito da rea¸c˜ao do bebˆe `a asfixia, deve ser inclu´ıdo um alerta sonoro quando os parˆametros sugerirem que a crian¸ca est´a em estado critico [19], pois tais sinais sonoros provocam uma rea¸c˜ao que estimula os centros respirat´orios e a frequˆencia card´ıaca, aumentando a ventila¸c˜ao pulmonar e consequentemente o n´ıvel de oxigˆenio no sangue [20].A Tabela 3 sumariza os alertas mencionados.
Tabela 3: L´ogica dos sinais de alerta
Alertas Condi¸c˜oes Alertar App Alertar autoridade de sa´ude
Disparar alerta sonoro 1 Bebˆe deitado de bru¸cos Sim N˜ao N˜ao 2 SpO2 <95% Sim N˜ao N˜ao
3 SpO2 <90% Sim Sim Sim
4 Frequˆencia card´ıaca <80bpm
por 30 segundos Sim N˜ao N˜ao 5 Frequˆencia card´ıaca <80bpm
por 60 segundos Sim Sim Sim
4
IMPLEMENTAC¸ ˜AO E TESTES
4.1 Prototipa¸c˜ao e ambiente de teste
Um prot´otipo do SML foi desenvolvido tendo como base a especifica¸c˜ao apresen- tadaa anteriormente. Este prot´otipo foi desenvolvido em Java utilizando o paradigma orientado a objetos. Para a persistˆencia dos dados coletados, foi escolhido o uso do SQ- Lite, um banco de dados tratado como referˆencia em sistemas embarcados devido `a sua simplicidade de administra¸c˜ao, implementa¸c˜ao e manuten¸c˜ao.
Como forma de comunica¸c˜ao entre o SML e entidade externas, foram utilizadas as tecnologias de socket e web service. Os sinais vitais do bebˆe em tempo real s˜ao enviados via socket para o aplicativo m´ovel utilizando protocolo UDP. Tal modelo foi escolhido pelo fato que a perda de pacotes ´e toler´avel nesta aplica¸c˜ao, uma vez que s˜ao enviados 1 pacote por segundo e a perda de alguns deles n˜ao interfere de maneira cr´ıtica na sua funcionalidade. Por outro lado, o web service ´e utilizado para consulta de relat´orios do hist´orico de dados e altera¸c˜oes de configura¸c˜ao. O uso de web service tamb´em foi escolhido para a transmiss˜ao dos alertas entre o sistema e as autoridades de sa´ude.
O hardware central do sistema embarcado ´e a placa Intel Galileo Gen 2, a qual ´eR
respons´avel pela coleta das informa¸c˜oes medidas pelos sensores, pela execu¸c˜ao das l´ogicas de neg´ocio definidas e pela comunica¸c˜ao com o aplicativo m´ovel e outros servi¸cos de sa´ude. Como um dos objetivos ´e obter a posi¸c˜ao da crian¸ca, foi pensado em algum sensor que pudesse ser facilmente inserido na vestimenta do rec´em-nascido. A op¸c˜ao escolhida foi o FSR 402, um resistor sens´ıvel `a for¸ca que funciona medindo a press˜ao aplicada em sua superf´ıcie atrav´es de sua varia¸c˜ao de resistˆencia, atuando como uma esp´ecie de “bot˜ao” que ativa quando o peso da crian¸ca exerce uma determinada press˜ao sobre o mesmo. Devido a seu tamanho pequeno e pouqu´ıssima espessura, ele se mostrou ideal para aplica¸c˜ao. Outro sensor considerado indispens´avel ´e o ox´ımetro, pelo qual ´e poss´ıvel obter a satura¸c˜ao de oxigˆenio e a frequˆencia card´ıaca. Neste caso, o sistema ´e compat´ıvel com qualquer ox´ımetro que disponibilize seus dados no modelo do IEEE 11073-10404 Pulse Oximeter Specialization Standdard [21]. Para os alertas sonoros foi utilizada uma placa de som USB gen´erica para habilitar a conex˜ao com um alto-falante, devido ao fato da placa Galileo n˜ao oferece entrada p2. O ambiente de testes foi configurado como ilustra a Figura 8.
Figura 8: Configura¸c˜ao do ambiente de testes
A placa est´a conectada com roteador via cabo Ethernet. O sensor FSR est´a conec- tado por fios jumpers em um protoboard que por sua vez est´a conectada com a placa. A caixa de som ´e outro dispositivo ligado `a placa. Sua conex˜ao se da por meio de um cabo p2 conectado a uma placa de som inserida na placa.
´
E importante ressaltar que devido `as restri¸c˜oes de pre¸co e disponibilidade no mer- cado, n˜ao foi poss´ıvel adquirir um ox´ımetro real. Desta forma, foi desenvolvido em python um simulador capaz de gerar dados com base no modelo IEEE 11073-10404 [21], um con- junto de padr˜oes que abordam a interoperabilidade de dispositivos pessoais de sa´ude. Este simulador ´e executado no computador (conectado na mesma rede do roteador via Wi-Fi) simulando os sinais vitais da crian¸ca e enviado para a placa. Al´em disso, o computador tamb´em foi utilizado para receber os dados destinados `as autoridades de sa´ude e aplicativo m´ovel, pois o objetivo desse projeto n˜ao foi desenvolvˆe-los.