Escala de UTI que aprende com quem a cumpre
Rostera é o sistema de apoio à decisão que coleta preferências da equipe de enfermagem, alimenta o modelo de otimização e devolve a escala para quem vai trabalhá-la.
O problema
A escala da UTI é montada à mão, consome horas da chefia de enfermagem e distribui mal aquilo que ninguém mede: noites, fins de semana, feriados, habilidades e preferências.
A proposta
Um sistema em três partes. Um instrumento que elicita preferências sem cansar a equipe, um motor de otimização que gera a escala respeitando as restrições rígidas, e um ciclo de feedback que corrige os pesos do modelo a cada período trabalhado.
O diferencial declarado do trabalho é a usabilidade junto a sofisticação matemática. De nada adianta um modelo ótimo se a equipe não alimenta os dados que ele consome.
Onde estamos
Arquitetura e modelo de dados fechados. O plugin já cria as tabelas, registra os três perfis de acesso e expõe a API. Próximo passo: o instrumento de elicitação.
Arquitetura
Quatro camadas e uma fronteira. A fronteira é o que garante que o modelo matemático possa ser trocado sem reescrever o sistema.
-
WordPress como casca, não como site
Autenticação, perfis de acesso e hospedagem já resolvidos. O que é aplicação de verdade vive num plugin próprio, versionado em git, que é o artefato técnico do trabalho.
-
Tabelas relacionais próprias
Trinta profissionais em trinta dias com três turnos geram milhares de registros por mês. Isso exige estrutura relacional.
-
O solver pergunta, o site não chama
O worker consulta periodicamente se há escala a resolver. Com isso o motor pode rodar num notebook, num servidor da universidade atrás de firewall ou dentro do hospital, sem nenhuma mudança de código.
-
Contrato JSON congelado
O formato do que vai e do que volta é fixo e versionado. Trocar a linguagem do modelo passa a ser uma decisão de pesquisa, não uma refatoração do sistema. Ou seja, pode ser feito sem problemas.
Modelo de dados
Vinte e cinco tabelas em três blocos. O cadastro é estável, o planejamento é o coração do trabalho, e o terceiro bloco é o que mantém o sistema vivo.
nrp_unitsA unidade. Leitos e parâmetros da UTI.nrp_contract_rulesRegras duras por vínculo: carga semanal, dias consecutivos, descanso mínimo.nrp_staffO profissional, ligado ao usuário do sistema.nrp_skillsCatálogo de competências. Estruturado para o skill-mix futuro.nrp_staff_skillsQuem tem qual competência e em que nível.nrp_shift_typesTurnos da unidade, com duração e marcação de noturno.nrp_periodsO horizonte de planejamento. Eixo temporal de todo o sistema.nrp_calendar_daysA data como entidade, com classe de feriado. Natal não vale o mesmo que feriado municipal.nrp_demandQuantos profissionais são exigidos em cada turno de cada dia.nrp_constructsO catálogo de perguntas. As perguntas vivem no banco, não no código.nrp_preferencesAs respostas, com peso normalizado e confiança que decai com o tempo.nrp_preference_budgetOrçamento de pontos de cada pessoa, com saldo que rola entre períodos.nrp_day_requestsPedidos em datas específicas e quantos pontos a pessoa apostou neles.nrp_availabilityIndisponibilidade dura. Não é preferência, é bloqueio.nrp_solver_runsCada execução do modelo, com função objetivo, gap e tempo. É a rastreabilidade dos resultados.nrp_assignmentsA escala em si. Uma linha por pessoa por turno por dia.nrp_assignment_editsToda intervenção humana na escala, com motivo inferido automaticamente.nrp_schedule_ackConfirmação da escala publicada, dentro de uma janela configurável.nrp_swap_requestsTrocas entre profissionais e sua aprovação.nrp_absence_eventsAusências, com a antecedência do aviso. Gatilho da reotimização.nrp_pulse_checksA nota de cansaço dada no dia seguinte a cada plantão.nrp_pairwise_responsesComparações forçadas entre duas alternativas de escala.nrp_fairness_ledgerSaldo acumulado de noites, feriados e pedidos atendidos por pessoa.nrp_notificationsFila de avisos, hoje dentro do sistema, amanhã por push ou mensagem.nrp_push_subscriptionsAssinaturas de notificação no navegador, para a fase seguinte.Coleta contínua
Um formulário longo respondido uma vez apenas não informaria o bastante. A coleta precisa acontecer em doses pequenas, o tempo todo, com retorno visível para quem responde.
-
Questionário inicial
Respondido uma vez, ao entrar no sistema. Cobre os constructos essenciais e distribui o orçamento de pontos do primeiro período.
-
Nota do plantão
Ao final de um turno, uma pergunta de um toque. Cinco segundos. É o dado mais valioso do sistema porque é fresco e amarrado a um plantão específico.
-
Perguntas soltas ao longo das semanas
Duas ou três por semana, rotacionando entre os constructos que ainda não foram cobertos. O catálogo inteiro é respondido em meses, sem ninguém perceber.
-
Comparação entre dois cenários
A pergunta só aparece quando o sistema identifica que não sabe diferenciar duas situações que a pessoa realmente viveu na escala. Escolha forçada informa muito mais que uma nota de 1 a 5.
-
Conferência da escala publicada
Ao publicar, cada pessoa tem uma janela para dar ok ou apontar os dias problemáticos. O conflito aparece antes de virar pedido de troca em cima da hora.
-
Leitura das correções da chefia
Cada vez que a chefia move alguém, o sistema registra e deduz o motivo sozinho. Nada é exigido dela. Quando ela sempre tira a mesma pessoa do domingo, existe uma regra que ninguém escreveu.
-
Painel de transparência
Cada pessoa vê o próprio saldo de noites, feriados e pedidos atendidos, comparado com a média da equipe. É o que sustenta todos os outros seis: sistema que não devolve nada para de receber dados.
Os 29 constructos
Agrupados em sete blocos. Os essenciais entram no questionário inicial, o restante é liberado aos poucos.
Conceitos do Modelo
Quatro mecanismos que transformam resposta de formulário em coeficiente de função objetivo, sem cair na armadilha de comparar utilidades entre pessoas diferentes.
Orçamento de pontos
Cada profissional recebe um número fixo de 'pontos' por período e distribui entre os pedidos. Sem isso, todo mundo marca tudo como prioridade máxima e a elicitação não informa nada. Com isso, os pesos já saem normalizados e comparáveis entre pessoas.
Pontos não gastos rolam parcialmente para o período seguinte, com teto, para que alguém possa economizar até uma data que importa de verdade.
Equidade entre períodos
Um saldo acumulado por pessoa registra noites, fins de semana, feriados e taxa de pedidos atendidos. Esse saldo entra no modelo de três formas: como restrição rígida em janela móvel, como peso dinâmico que cresce conforme o déficit da pessoa, e como rodízio explícito de feriados grandes.
A função objetivo ganha ainda um termo de dispersão, para evitar a solução que minimiza a penalidade total fazendo três pessoas absorverem todo o prejuízo.
Preferência declarada e preferência revelada
O que a pessoa escreve no formulário e o que ela faz nem sempre coincidem. Quem marcou tanto faz para o turno noturno mas pede troca de todo plantão de noite três meses seguidos declarou uma coisa e revelou outra.
O sistema captura a segunda sem pedir nada a mais: pedidos de troca, ausências e correções da chefia. Comparar as duas matrizes é a discussão que se abre para a continuidade no mestrado.
Confiança que decai
Toda preferência guarda um grau de confiança que cai com o tempo sem reconfirmação. Preferência de oito meses atrás pesa menos que a de semana passada, e abaixo de um limiar o sistema simplesmente repergunta.
Entregas
Noventa horas em seis blocos de quinze, até 27 de novembro. Nenhum bloco depende de o modelo matemático já existir.
-
1
Fundação
Concluído em 19/09Plugin funcional, 25 tabelas criadas na ativação, três perfis de acesso, catálogo de perguntas semeado e API base no ar.
-
2
Instrumento de elicitação
Até 03/10O questionário inicial, desenhado para celular, com contador de pontos em tempo real, calendário de pedidos e validação de consistência.
-
3
Tela da equipe
Até 17/10Minha escala, próximos plantões, nota do plantão, pedido de troca e o painel de transparência pessoal.
-
4
Tela da chefia
Até 31/10Definição de demanda por turno, grade da escala com edição manual, publicação de período e relatórios de cobertura e equidade.
-
5
Integração com o motor
Até 14/11Contrato JSON congelado, worker em modo pull e um gerador simples que respeita as restrições rígidas, para exercitar todo o fluxo antes do modelo real.
-
6
Teste e documentação
Até 27/11Roteiro de teste, sessão de validação com o orientador, ajuste visual e relatório de estágio.
Próximas tarefas
- Definir arquitetura e fronteira com o modelo
- Fechar o modelo de dados das 25 tabelas
- Semear o catálogo de 29 constructos
- Escrever o plugin com tabelas, perfis e API
- Gerar massa de dados sintéticos para teste
- Desenhar as telas do questionário inicial
- Implementar o contador de orçamento de pontos
- Calibrar a janela de conferência com a chefia (ver quanto tempo a equipe pode 'dar ok' para a escala feita.
- Definir a linguagem do modelo matemático