Lar nos Açores e na Madeira: as comparticipações batem certo com as presenças?

No fim do mês, alguém no teu lar senta-se com três coisas: a lista de utentes em acordo, o dossier das presenças e a folha de onde sai o mapa para a Segurança Social regional. Depois passa uma tarde (às vezes duas) a responder à mesma pergunta, utente a utente: "esta senhora esteve cá o mês todo?"

Quase sempre esteve. O problema está no "quase". Há a D. Maria, que foi internada no Hospital do Divino Espírito Santo a 9 e voltou a 17. Há o senhor que entrou a meio do mês, depois de meses em lista de espera. Há a utente que passou uma semana com a filha, que veio de férias do Canadá. E há o óbito do dia 23. Cada um destes casos mexe no que o lar pode pedir, no que o utente ou a família pagam e no que fica registado para uma eventual auditoria. E cada um vive num sítio diferente: num papel na enfermaria, numa mensagem de WhatsApp da família, na memória da técnica que trata disto há quinze anos.

Este artigo explica como pôr esse cruzamento a funcionar a partir dos dados que o lar já tem, sem trocar de sistema e sem entregar a faturação a um chatbot que adivinha.

Porque é que isto é um problema das ilhas (e não só um problema de lares)

Nos Açores e na Madeira, os acordos de cooperação não são geridos pelo ISS do continente. São geridos pelos institutos regionais: o ISSA nos Açores e o ISSM na Madeira. Isto tem duas consequências práticas.

A primeira é que muitas das ferramentas de gestão de lares à venda em Portugal foram pensadas para o circuito continental. Os mapas, os campos e as validações seguem esse modelo. Quem está nas ilhas adapta, exporta para Excel e corrige à mão, e é aí que entram os erros.

A segunda é que as instituições das ilhas ficaram fora das linhas continentais de apoio à IA. A "Linha IA" do PRR para PME só aceitava empresas do continente. Às Regiões Autónomas coube a linha Reindustrializar, que está fechada desde janeiro. Nos Açores, a atualização do Plano Anual de Avisos de setembro tem 34 avisos e nenhum é específico de IA. Na Madeira, a nova agenda regional para a IA nas empresas foi anunciada a 17 de setembro, mas os apoios ainda estão "a ser preparados". Resultado: o que chega às ilhas com o rótulo "IA" é sobretudo formação em prompts. É útil, mas não te fecha o mapa do mês.

Não vemos isto como uma desvantagem. Vemos um problema concreto, recorrente e mensurável, que ninguém está a resolver para o teu contexto. É o tipo de problema que uma equipa pequena resolve bem.

Onde é que o mapa mensal costuma falhar

Não é por desleixo. É porque a informação que decide a faturação nasce em sítios que não falam uns com os outros:

Internamentos hospitalares. A saída é registada pela enfermagem. O regresso às vezes só aparece no diário clínico. Se ninguém fechar a data de regresso, o sistema de faturação não sabe que houve ausência.
Ausências para a família. Fins de semana, Natal, as semanas de verão em que os filhos emigrados vêm às ilhas. Ficam combinadas ao balcão e às vezes nem chegam ao papel.
Entradas e saídas a meio do mês. Admissões, transferências, óbitos. O mês não começa no dia 1 para toda a gente.
Alterações na comparticipação familiar. Uma pensão revista ou um novo elemento no agregado. Muda o que o utente paga e, conforme o acordo, o que se pede.

Cada acordo tem regras próprias sobre o que conta como ausência, a partir de quantos dias, e o que acontece à comparticipação. Não vamos fingir que sabemos as do teu acordo sem as ler. O que sabemos é que a regra é tua e que o sistema a deve aplicar sempre da mesma forma, em vez de depender de quem faz o mapa nesse mês.

Um exemplo trabalhado

Um exemplo ilustrativo, com números inventados mas realistas: um lar em São Miguel com 40 vagas em acordo. Em outubro:

36 utentes estiveram presentes todos os dias;
2 tiveram internamentos hospitalares (um de 8 dias, outro de 3);
1 passou 6 dias com a família;
1 faleceu a dia 23;
1 vaga foi ocupada a dia 14 por uma admissão nova.

À mão, isto são cinco casos a investigar em quatro sítios diferentes. Com o sistema ligado aos registos do lar, o resultado é uma lista de exceções que já vem pronta:

5 utentes com dias a rever em outubro. 2 internamentos (datas de saída e regresso tiradas do registo de enfermagem), 1 ausência familiar (registada na receção a 11/10, regresso a 17/10), 1 óbito (23/10), 1 admissão (14/10). 35 utentes sem exceções.

Cada linha traz a origem: que registo, quem o fez e quando. A técnica não refaz o mês. Confirma cinco casos e fecha. Em vez de "acho que está certo", tens "está certo, e isto é a prova".

O ponto crítico está nesta imagem: o regresso do hospital tem de ficar registado no momento em que acontece, por quem está à porta. Se fica para depois, o mapa do fim do mês herda o buraco.

Como funciona, sem magia

O que montamos é uma camada por cima do que já tens, não um sistema novo:

Leitura, só leitura. Ligamo-nos ao software de gestão do lar, à folha de presenças ou ao registo de enfermagem que já usas, em modo read-only. Não escrevemos na tua base de dados nem mexemos na faturação.
As regras do teu acordo, em código. Lemos contigo o acordo de cooperação e as orientações do ISSA ou do ISSM que se aplicam. Cada regra fica escrita, versionada e testada. Se a regra mudar, muda num sítio só.
Exceções, não relatórios. O resultado não é um PDF de 40 páginas. É a lista do que não bate certo, com a razão e a origem de cada número.
Perguntas em português normal. A direção pode perguntar pelo WhatsApp ou na consola "quantos dias de internamento tivemos em outubro?" ou "quem entrou depois do dia 1?". A resposta vem dos teus dados, com a consulta registada.

Porque é que um chatbot genérico não serve aqui

Se colares a folha de presenças num assistente genérico e pedires "calcula as comparticipações", ele dá-te uma resposta. Pode até estar certa. O problema é que não tens como saber, e nenhum auditor aceita "foi o que a IA disse".

A diferença está em três coisas. Uma IA fundada responde só a partir dos teus registos e, quando o dado não existe, diz que não existe. Os valores são calculados por código que aplica a regra do teu acordo, e o modelo de linguagem serve apenas para perceberes a pergunta e explicares a resposta. E cada resposta fica auditada: quem perguntou, o que foi consultado e o que foi devolvido. É esta a parte que te protege numa inspeção.

As objeções que ouvimos

"Já temos software de gestão de lar." Ótimo, é daí que lemos. Não te pedimos para o trocar. Pedimos acesso de leitura.

"São dados de saúde." São, e por isso o acesso é read-only, os dados ficam onde estão ou numa infraestrutura na UE, e cada consulta fica registada. O RGPD faz parte da arquitetura desde o primeiro dia, não é uma checkbox no fim.

"A nossa técnica faz isto há quinze anos e não erra." Provavelmente erra pouco. Mas o conhecimento está na cabeça dela, e quando ela vai de férias ou se reforma o lar fica sem ele. Pôr as regras em código não a substitui. Passa a ser o registo escrito do que ela sabe.

"Somos pequenos." A maioria dos lares das ilhas também é. O primeiro passo cabe numa semana de trabalho: ler um mês real, aplicar as regras e comparar com o mapa que já foi entregue.

De onde vem esta experiência

No Brasil construímos e operamos um ERP para lares de idosos, com registo de medicação em circuito fechado com código de barras e conformidade com a ANVISA e a LGPD desde a origem. As regras em Portugal são outras, e não as confundimos. O método é o mesmo: a conformidade está na arquitetura e cada número tem uma origem que dá para mostrar.

O próximo passo

Escolhe um mês já fechado, por exemplo setembro. Envia-nos o mapa que foi entregue e dá-nos acesso de leitura aos registos de presenças. Nós devolvemos a lista de exceções que o sistema encontraria e comparamos com o que foi faturado. Se bater tudo certo, ficas com a prova de que o teu processo funciona. Se não bater, ficas a saber onde está a diferença.

Falas diretamente com quem escreve o código: hello@leiritech.com · +351 914 572 595.