Quedas no lar e a hora de inverno: lê-as por hora, turno e ala antes do dia 25

"A D. Fátima caiu outra vez ao fim da tarde." Se diriges um lar ou coordenas a enfermagem, já ouviste esta frase vezes suficientes para teres uma intuição: há horas piores do que outras. O problema é que a intuição não chega para mexer numa escala de pessoal, e o registo que a podia confirmar está espalhado por folhas de ocorrência, notas de turno e um campo de texto livre no software do lar.

No domingo, 25 de outubro, os relógios atrasam uma hora, tanto no continente como nos Açores e na Madeira. O pôr do sol passa de perto das sete para pouco depois das seis da tarde. O jantar, a ida à casa de banho depois do jantar e a passagem do turno da tarde para a noite, que até agora ainda aconteciam com alguma luz, passam a acontecer de noite.

Atenção: não vamos afirmar que a mudança de hora aumenta as quedas no teu lar. Não sabemos, e quem te garantir isso sem olhar para os teus dados está a adivinhar. Dizemos uma coisa mais modesta e mais útil: tens 20 dias para saber a que hora, em que turno e em que ala caem os teus utentes. Assim, no fim de novembro consegues comparar e ver se alguma coisa mudou.

Porque é que a pergunta é difícil num lar real

Nos Açores há 34 ERPI, 1.424 camas protocoladas e 540 idosos em lista de espera. Os próprios lares queixam-se da falta de mão de obra especializada. Ninguém tem uma pessoa livre para passar uma tarde a cruzar folhas de ocorrência com escalas. E mesmo que tivesse, ia bater em três problemas que encontramos sempre que abrimos dados deste tipo.

1. A hora registada nem sempre é a hora da queda. Muitas vezes o registo fica com a hora a que a ocorrência foi escrita, que pode ser no fim do turno. Uma queda às 18h40 escrita às 22h50 aparece no gráfico como queda do turno da noite. Se o teu sistema tem dois campos, hora do evento e hora do registo, é preciso usar o primeiro. Se só tem um, é preciso saber qual dos dois ele guarda.

2. O "turno" não existe no registo, existe na escala. A folha de ocorrência diz "18h40, quarto 12". Que turno estava, quantas pessoas estavam na ala e se alguém tinha saído para o refeitório é informação que está noutro sítio: na escala de pessoal, que muitas vezes vive numa folha de Excel ou num quadro na parede.

3. A própria noite de 25 de outubro tem uma hora repetida. Entre a 1h e as 2h dessa madrugada, o relógio passa duas vezes pela mesma hora. Uma queda registada às 01h30 desse dia pode ter acontecido em dois momentos diferentes. São só alguns minutos por ano, mas um sistema que guarda a hora local sem fuso dá aqui uma resposta errada sem avisar ninguém. Os sistemas bem feitos guardam o instante em UTC e só convertem quando mostram a hora.

Com tudo isto, o relatório "quedas por mês" que o teu software provavelmente já tira não responde à pergunta. Diz-te quantas quedas houve, mas não quando, nem com quem de serviço, nem onde.

Um exemplo trabalhado

Vamos imaginar um lar de 60 camas em São Miguel, com três alas: A (autónomos), B (dependência moderada) e C (demências). Os números são ilustrativos, não de um cliente real, mas a lógica é exatamente a que usamos.

Nos últimos 12 meses houve 74 quedas registadas. Distribuídas por mês, não dizem nada: entre 4 e 9 por mês, sem padrão claro. Depois de corrigir a hora (usando a hora do evento) e de juntar o turno a partir da escala, aparece isto:

• 31 das 74 quedas aconteceram entre as 17h e as 21h.
• 19 dessas 31 foram na ala C.
• Em 14 das 19, o registo menciona ida à casa de banho ou levantar-se da cadeira depois do jantar.
• Nos dias com essas quedas, a ala C tinha uma auxiliar a menos entre as 18h e as 19h30, porque estava a apoiar o refeitório.

Nada disto prova que haja causalidade, mas dá uma hipótese concreta que se pode testar, coisa que o "caem mais ao fim da tarde" não dava. A partir daqui, as decisões são operacionais e baratas: deixar uma auxiliar fixa na ala C durante o jantar, acender a iluminação dos corredores e das casas de banho da ala C às 17h30 em vez de depender do sensor e fazer uma ronda de casa de banho às 19h nos utentes sinalizados.

A seguir vem a parte que quase ninguém faz, que é medir. Fixas o ponto de partida antes de 25 de outubro e comparas as semanas de novembro com as mesmas semanas do ano passado, no mesmo intervalo horário e na mesma ala. Se as quedas das 17h às 21h na ala C baixarem, tens evidência. Se não baixarem, também tens: deixas de gastar uma auxiliar onde ela não faz diferença.

A objeção: "temos poucas quedas, isto não é estatística"

É verdade. Num lar de 40 ou 60 camas, os números são pequenos, e quem tira conclusões a partir de três quedas numa semana engana-se. Por isso a análise tem de ser honesta em relação ao tamanho da amostra:

• Usa 12 a 24 meses, não um mês.
• Junta as horas em blocos (por exemplo, 17h–21h), em vez de olhar hora a hora.
• Mostra sempre os números absolutos ao lado das percentagens. "40 %" impressiona, mas se forem "2 em 5" não quer dizer nada.
• Trata o resultado como hipótese a testar e não como diagnóstico.

A outra objeção que ouvimos é que são dados de saúde e não se podem mandar para uma IA qualquer. Também é verdade, e é exatamente por isso que a forma como o sistema é construído conta mais do que o modelo.

O que significa "IA fundada nos teus dados" num lar

Um chatbot genérico ao qual perguntas "a que horas caem mais os idosos?" responde com a média de estudos internacionais. Pode até estar certa em média, mas não diz nada sobre a tua ala C. O que nós construímos funciona de outra forma:

• Lê diretamente das tuas fontes: o software do lar ou o ERP, o registo de ocorrências, a escala de pessoal e, se existir, o registo de administração de medicação. Não há folha intermédia copiada à mão.
• Só lê, não escreve. Não altera nenhum registo clínico nem nenhuma escala. O acesso é feito com um utilizador de leitura que o teu informático pode revogar a qualquer momento.
• Fica tudo auditado. Cada pergunta e cada consulta aos dados ficam registadas, com quem perguntou, quando e que tabelas foram lidas. Se a Segurança Social ou uma auditoria interna pedirem, tens o rasto.
• Cada resposta mostra de onde vem. Quando a diretora técnica pergunta no WhatsApp "quantas quedas houve na ala C entre as 17h e as 21h desde junho?", a resposta traz o número, a lista de ocorrências que o compõem e a regra que foi usada para atribuir o turno. Se a regra estiver mal, vê-se logo e corrige-se.

A parte da IA serve para transformar a pergunta em português numa consulta aos teus dados e para explicar o resultado. Os números vêm da base de dados do lar, e o modelo nunca os inventa.

Aprendemos isto a construir o Doseo, um ERP para lares feito para o Brasil, com o regulamento sanitário da ANVISA (RDC 502) e a lei de proteção de dados de lá (LGPD) incorporados de raiz, e com circuito fechado de medicação por código de barras. Num lar, um registo com a hora errada não é um pormenor estético, porque muda a decisão de quem está de serviço.

Porque é que isto chega primeiro às ilhas

Os apoios continentais à adoção de IA ficaram de fora para os Açores e a Madeira, e a fatia regional ainda está "em preparação". Na prática, um lar em Angra, na Horta ou no Funchal não vai ter um programa a pagar-lhe isto antes do inverno. Também não precisa. Precisa de uma equipa pequena que ligue os dados que já tem, em modo de leitura, e que lhe dê uma resposta verificável antes de 25 de outubro. O trabalho é feito à distância sobre a tua infraestrutura e não obriga a trocar de software nem a ter alguém da tua equipa a tempo inteiro no projeto.

O próximo passo, concreto

Até ao dia 25, reúne três coisas: uma exportação do registo de quedas dos últimos 12 meses (mesmo que seja em Excel), a escala de pessoal do mesmo período e a lista de quartos por ala. Com isto conseguimos dizer-te, numa conversa, se a tua hora de evento é fiável, como fica a distribuição por hora, turno e ala, e se vale a pena ligar o sistema de forma permanente para acompanhares novembro.

Escreve para hello@leiritech.com ou liga para o +351 914 572 595. Do outro lado está quem escreve o código.