Regras de verificação técnica: automatizando o olhar do biomédico

Todo biomédico experiente carrega na cabeça um checklist invisível: esse valor está dentro da faixa? Bate com o histórico do paciente? O equipamento sinalizou algum flag? Faz sentido clinicamente junto com os outros exames do mesmo pedido? Esse julgamento é o que chamamos de verificação técnica — e ele é feito, resultado por resultado, silenciosamente, dezenas ou centenas de vezes por dia. Um motor de regras de verificação técnica não substitui esse julgamento: ele o transforma em critério explícito, aplicado com consistência total e registrado para auditoria, liberando o biomédico para gastar tempo de raciocínio clínico só onde ele realmente importa.

O problema: bancada lotada e critério na cabeça de uma pessoa

Em laboratórios de médio e alto volume, a maior parte dos resultados que chegam à bancada de verificação é absolutamente normal: dentro da faixa de referência, sem flag do equipamento, coerente com o histórico do paciente. Ainda assim, cada um desses resultados passa pelos olhos de um biomédico antes de virar laudo — porque não existe critério formal e auditável para dizer "este aqui não precisa de revisão".

O efeito colateral é previsível: a atenção do profissional se dilui entre centenas de resultados triviais e os poucos casos que realmente merecem julgamento clínico — um valor limítrofe, uma divergência entre exames do mesmo pedido, um paciente cujo histórico não bate com o resultado atual. Quanto mais a bancada acumula, maior o risco de o olhar cansado deixar passar exatamente o caso que importava.

O que é verificação declarativa

A ideia central de um motor de regras de verificação técnica é simples: em vez de programar fluxos rígidos de código para cada exame, o laboratório declara critérios — em formato estruturado, editável pelo próprio responsável técnico, sem depender de desenvolvimento — e o motor os avalia automaticamente contra cada resultado que chega.

Uma regra declarativa combina, tipicamente, quatro classes de condição:

• Faixa analítica — o valor está dentro do intervalo de referência esperado para idade, sexo e método?
• Flag do equipamento — o analisador sinalizou alarme técnico (coagulação, diluição automática, sinalizador morfológico)?
• Delta check — a variação em relação ao último resultado do mesmo paciente é biologicamente plausível?
• Consistência entre parâmetros — os resultados do mesmo pedido são coerentes entre si (ex.: hemoglobina e hematócrito, ureia e creatinina)?

Quando todas as condições de uma regra são satisfeitas, o resultado é elegível à autoverificação. Quando qualquer uma falha, o resultado é retido para revisão humana — com o motivo exato registrado, não um "verificar manualmente" genérico.

Shadow mode: confiança antes de automação

Nenhum laboratório sério liga um motor de regras direto em produção liberando resultado sem supervisão. O caminho correto — e o que o Lisya adota por padrão — é o shadow mode: o motor roda em paralelo à verificação manual normal, calcula o que teria decidido em cada resultado, mas não interfere na liberação. O biomédico continua verificando 100% dos resultados como sempre fez.

Ao final de cada período em shadow mode, o laboratório compara a decisão do motor com a decisão humana real. Isso responde à pergunta que realmente importa antes de automatizar: a regra concorda com o biomédico na prática, ou só na teoria?

Esse período também revela regras mal calibradas antes que causem dano: uma faixa de referência desatualizada, um delta check afrouxado demais para um analito específico, uma condição que ignora um flag importante de um equipamento novo. Errar no shadow mode não custa nada ao paciente — errar em produção sem essa etapa, custa.

Override: o motor sugere, o biomédico decide

Automação declarativa não é automação cega. Mesmo com regras em produção, o biomédico sempre pode fazer override: reter manualmente um resultado que o motor liberaria, ou — em fluxos que permitem — assumir a responsabilidade de liberar algo que a regra reteve, desde que justifique o motivo.

Cada override fica registrado com quem decidiu, quando e por quê. Essa trilha tem dois usos: serve de evidência de rastreabilidade técnica para acreditação (PALC/ISO 15189), e serve de insumo para recalibrar as próprias regras — se um padrão de override se repete, é sinal de que o critério declarado está errado, não de que o profissional está sendo excessivamente cauteloso.

Indicadores: medir para confiar

Um motor de regras sem indicador de acompanhamento é uma caixa preta — e caixa preta não passa em auditoria nenhuma. Os números abaixo ilustram o tipo de painel que um laboratório de médio porte costuma acompanhar mês a mês depois de colocar a autoverificação declarativa em produção.

Vale separar dois eixos de leitura: volume (quanto do total é auto-verificado) e segurança (quantos desses casos, se fossem auditados retroativamente por um biomédico sênior, teriam sido retidos). O primeiro mede eficiência; o segundo mede se a eficiência está sendo comprada com risco.

Exames com maior variabilidade clínica ou dependência de flags morfológicos — coagulograma, hormônios — naturalmente têm taxa de autoverificação mais baixa, e isso é esperado: a regra não deve ser calibrada para "liberar mais", deve ser calibrada para liberar o que é seguro liberar.

Grupos de regras e alertas: granularidade importa

Regra única e genérica para "todos os exames" não funciona — cada analito tem seu próprio comportamento biológico e sua própria tolerância a variação. Por isso o motor precisa suportar grupos de regras organizados por exame, perfil de paciente (pediátrico, gestante, UTI) e até por equipamento de origem, já que o mesmo parâmetro pode ter faixas e flags diferentes conforme o analisador que gerou o resultado.

Exemplo prático: potássio sérico

Um valor de potássio dentro da faixa de referência, sem flag de hemólise do equipamento e com delta check compatível com o histórico do paciente, é elegível à autoverificação. Já um potássio limítrofe alto, ou com flag de amostra hemolisada, ou com salto abrupto frente ao último resultado do mesmo paciente — mesmo que "dentro da faixa" — deve ser retido, porque potássio é justamente o tipo de analito onde o erro pré-analítico (hemólise) e o valor crítico têm consequência clínica real e rápida.

Como implantar sem virar um projeto de TI

A resistência mais comum a um motor de regras é achar que ele exige uma equipe de desenvolvimento dedicada. Não deveria: se o motor é de fato declarativo, o responsável técnico configura faixas, flags e deltas em uma tela de regras — sem escrever uma linha de código — e o próprio sistema versiona cada alteração.

1. Mapeie os exames de maior volume primeiro. Hemograma e bioquímica de rotina costumam concentrar o maior ganho de foco com o menor risco.
2. Declare as regras com o responsável técnico, usando a faixa de referência e os flags que o laboratório já usa hoje — não invente critério novo do zero.
3. Rode em shadow mode por semanas suficientes para acumular volume estatístico relevante, não só alguns dias.
4. Compare decisão do motor × decisão humana e ajuste as regras que mais divergem antes de promover qualquer coisa.
5. Promova por grupo de exame, não tudo de uma vez — comece pelo que teve maior concordância no shadow mode.
6. Acompanhe override e indicadores continuamente — regra de verificação técnica não é "configurar e esquecer".

Onde a verificação técnica termina e a liberação clínica começa

Vale separar dois conceitos que às vezes se confundem: a verificação técnica (analítica) confirma que o resultado é tecnicamente confiável — o método funcionou, o valor é plausível, não há flag pendente. A liberação clínica — geralmente feita ou supervisionada pelo médico responsável ou biomédico com assinatura — assume a responsabilidade final pelo laudo diante do paciente e, quando aplicável, aplica a assinatura digital.

O motor de regras atua na primeira etapa. Ele não decide o que vai para o paciente — ele decide quais resultados já chegam prontos, tecnicamente validados, para a etapa de liberação, e quais precisam de olhar humano antes disso. Essa distinção é o que torna o motor auditável sem tirar a responsabilidade técnica de quem assina.

Regras de verificação técnica não são sobre substituir o biomédico por um algoritmo — são sobre dar forma explícita a um critério que ele já aplica todo dia, e devolver a esse profissional o tempo que hoje se perde revisando, um a um, resultado que já era óbvio antes de chegar na tela. O laboratório que declara suas regras, testa em shadow mode, mede o que promove e mantém o override sempre disponível não está automatizando por automatizar — está tornando visível, auditável e consistente algo que sempre foi crítico e, até agora, invisível.