Closed atodobom closed 4 years ago
Uma outra alternativa seria usar leitores de livros, tem tela visivel sob sol e a bateria tem uma maior duração. Os leitores de livros usam uma versão embarcado do linux então não é complexo o desenvolvimento. Eles tem WIFI e uma porta serial disponivel. Já tenho usados leitores de livros para produção de computadores de voo e seu uso é bem aceito! Sobre a comunicação BT, em vez de usar APP, poderia também usar uma tela tipo terminal telnet, apareceriam as opções em modo texto, e os comandos também seriam enviados em modo texto. Poderíaos usar comandos no formato AT, o formato de comuncação com modens. Existem alguns APPs que fazem a conexão em modo texto e permite adicionar botões rápidos. Ou mesmo poderia usar o blynk para fazer APP de forma muito rápida, ou o AppInventor
Olá. Não sei se entendi em que momento ou camada teria o uso de comandos AT. Só aviso que para o usuário final absolutamente nada disso pode ser necessário, e se possível nem visível. O produto deve ser fechado em si. Apenas com o básico e tudo deve entrar, conectar e operar automaticamente. Ao usuário caberá apenas fazer as configurações da máquina que sejam necessárias, cadastrar paciente etc. Ajustar os níveis de alerta.
As normas de usabilidade vão nos impedir de utilizar qualquer coisa complexa. Por exemplo, o usuário enfermeiro ou médico não pode ter que mexer numa CLP. Se bem entendi as normas NBR ISO 62366 e 60601-1-6, ao menos.
Qualquer ajuste deve ser extremamente simples e intuitivo. E acho que precisamos ter aquele botão parada de emergência, que rearma girando. Não está nos videos deles, mas vi no desenho que está previsto.
A ideia de usar e-reader me parece legal. Mas não acho tão fácil para reprodução por outras equipes. Por isso eu pensei em um APK genérico, feito no MIT AI2 mesmo ou similar (eu gosto do Kodular) e apesar de usar como target um determinado modelo ou alguns modelos de tablets, seria possível rodar em uma grande variedade de aparelhos, apenas instalando o APK.
Oi pessoal,
me preocupa um pouco depender de demais dispositivos por 2 motivos: Anvisa e disponibilidade de estoque.
Nao sei se a anvisa libera um controle via BT por questões de segurança..
Posso estar falando besteira, mas eles tem sido bem restritos
Emerson Moretto emerson@moretto.eng.br 11 99484-0571
On Wed, Apr 1, 2020 at 3:10 PM atodobom notifications@github.com wrote:
Olá. Não sei se entendi em que momento ou camada teria o uso de comandos AT. Só aviso que para o usuário final absolutamente nada disso pode ser necessário, e se possível nem visível. O produto deve ser fechado em si. Apenas com o básico e tudo deve entrar, conectar e operar automaticamente. Ao usuário caberá apenas fazer as configurações da máquina que sejam necessárias, cadastrar paciente etc. Ajustar os níveis de alerta.
As normas de usabilidade vão nos impedir de utilizar qualquer coisa complexa. Por exemplo, o usuário enfermeiro ou médico não pode ter que mexer numa CLP. Se bem entendi as normas NBR ISO 62366 e 60601-1-6, ao menos.
Qualquer ajuste deve ser extremamente simples e intuitivo. E acho que precisamos ter aquele botão parada de emergência, que rearma girando. Não está nos videos deles, mas vi no desenho que está previsto.
A ideia de usar e-reader me parece legal. Mas não acho tão fácil para reprodução por outras equipes. Por isso eu pensei em um APK genérico, feito no MIT AI2 mesmo ou similar (eu gosto do Kodular) e apesar de usar como target um determinado modelo ou alguns modelos de tablets, seria possível rodar em uma grande variedade de aparelhos, apenas instalando o APK.
— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/Inspire-Poli-USP/Inspire-OpenLung/issues/13#issuecomment-607408203, or unsubscribe https://github.com/notifications/unsubscribe-auth/AABS5OFAJ3GFQ34QAHRGZQLRKN7QLANCNFSM4LYKWXPQ .
Você tem toda razão. BT é um empecilho ainda no Brasil. Talvez tenhamos que pensar, se for para usar o tablet mesmo, conectar via USB dele. Se fosse só um monitoramento e alerta.. talvez. Mas se for para configurar e controlar. Acho que teremos problemas.
Acredito que isso não será problema, tendo o protocolo definido, pode-se usar bluetooth ou serial ou até outro meio, utilizando o mesmo código. Pode inclusive deixar pronto e usado apenas em tempo de projeto. Quando for gerar a versão do firmware, compilar usando parâmtros diferentes.
Galera, temos que pensar quer precisamos reduzir o custo e agilizar a prototipação.
Esses IHM de impressoras 3D, não seriam uma opção? Eles já tem encoder rotativo com botão, botão stop, e buzzer.
Esses de impressoras realmente facilitam a vida. O mais em conta do de 20 caracteres x 4 linhas avulso que encontrei no ML hoje foi por 60 (mais frete de 9).
Outra opção seriam os displays gráficos de 320x240 que inclusive já incluem touch (só que resistivo) e pelos preços que vi hoje custam menos do que o kit mencionado de impressora 20x4. Eles permitiriam até traçar os gráficos de pressão/volume/fluxo, coisa mais difícil nos displays de texto, além do touch oferecer mais flexibilidade do que apenas um botão e um potenciometro. Acredito também que teriam uma disponibilidade maior do que estes personalizados da impressora 3d que tem botão/potenciometro/buzzer inclusos. O display gráfico perde na comparação no consumo de energia e na ausência do buzzer, de resto me parece uma opção superior. (não sei o tamanho da tela em si, a resolução é maior mas a tela talvez não seja, preciso ver aqui e atualizo a postagem). Encontrei hoje no ML anúncios deste 320x240 avulso por 43 (mais 18 de frete) e 50 (mais 9 de frete).
Citei esta resolução porque ela me pareceu um custo benefício bom. Displays gráficos c/ resolução inferior me parecem economia exagerada, a tela fica minúscula ao custo de uma economia pequena e telas maiores são um caso a ser analisado e considerado, a depender da redução do preço no atacado.
Em realação a comunicabilidade c/ dispositivos externos, vi que existe o ISO 11073, ele trata justamente da comunicação entre dispositivos médicos. Não sou da área, não sei o quanto ele é seguido no Brasil. Caso seja, seguindo o padrão o sinal dele seria compatível c/ demais equipamentos do hospital. Nada urgente neste momento, p/ uma eventual evolução do produto.
Pessoal, li acima sobre uso de BT. Tenho utilizado Muuuito tais dispositivos e posso afimar - não existem fornecedores realmente confiáveis. Não existe padrão e as conexões variam dependendo do módulo utilizado. Existe também irregularidade no fornecimento deles no Brasil. Posso dizer com certeza que isso iria requerer entre outras coisas, a homologação de um BT específico de determinado fabricante, desde que os testes demonstrassem sua confiabilidade. O alcance do BT também tende a ser reduzido, dependendo do propósito. Utilizei uma centena de BTs HC-05 e realmente a qualidade deles é muito irregular (não que seja impossível seu uso). Se optarem por isso, recomendo apenas o ZS-040 ou JY-MCU (nenhum genérico - sem identificação de fornecedor). Existem ainda novas propostas com maior alcance que ainda não testei, como SPPs etc...
Estou pensando em uma IHM com tablet, conectado via Bluetooth. Por hora enquanto discutimos a possibilidade de colocar um oxímetro, teremos apenas a frequência respiratória. O Arduino pode enviar via SPP em BT, usando um módulo HC05. No tablet penso em ter o nr do quarto, leito, nome do paciente, e gerar alertas em caso de desconexão com o aparelho, ou falhas reportadas.
Eventualmente podemos fazer mais com isso. Apenas agregando mais no APK. Conversando do Dr. Sidomar Cardoso, ele me passou algumas colocações. Ele já foi médico militar no serviço amazônico, e trabalhou muito em locais remotos e sem recursos. Hoje atende pela rede pública e privada em Rondônia. Ele me passou que seria muito interessante agregar um oxímetro ao produto. Monitores multiparâmetros não são comuns em todos os locais e serão raros nessa demanda. Nesta semana perderam um paciente por conta disso. O ventilador estava operando, mas ninguém observou a queda de saturação, e quando viram o ventilador estava forçando ar num paciente em óbito.
Outra coisa ele falou que podemos agregar funcionalidades para organizar um pouco a coisa. Ele acredita que teremos condições difíceis em campo. E se tiver dados do paciente seria bom. Se houver um tablet por aparelho, eles podem estar em rede. E existir um tablet ou qualquer celular no posto de enfermagem, com um apk de supervisão. Ele pode dar alerta na falha de algum aparelho ou perda de comunicação. O tablet do posto pode lançar posologias que podem aparecer nos que estão junto ao paciente. Gerando log de tudo. Enfim... discussão aberta. Vamos considerar opiniões de especialistas para nos conduzir nisso. Estou aqui com Multilaser M7S-GO baixo custo. Android 8 e utilizei para outros projetos.
Estou iniciando um projeto em plataforma AI2 que ficará em aberto para comunidade.