Triagem Técnica de Pedidos

Objetivo

Avaliar a viabilidade técnica de cada pedido antes da manipulação: compatibilidade entre ativos, dosagens dentro de faixas seguras, forma farmacêutica adequada ao uso pretendido. A triagem é o gate que separa “documentos coerentes” de “produto viável de ser produzido”.

Posição no fluxo do ERP

Etapa de entrada: Ag. Triagem — etapa 7. O pedido chega aqui automaticamente após a impressão dos rótulos (todos os produtos foram pintados em Impresso, sistema avançou para Ag. Triagem junto).
Etapa de saída: Triado — etapa 8. Farm. Triagista aprova e avança manualmente.
Padrão de avanço: Manual por pedido inteiro. Diferente das conferências (que operam por produto), a triagem avalia o pedido todo de uma vez — se um produto tem problema, o pedido inteiro volta.

Como o Farm. Triagista encontra o trabalho do dia

O Farm. Triagista usa o filtro padrão da produção (ver Como cada etapa enxerga o trabalho do dia):

Filtro de status: Pedidos em Ag. Triagem
Filtro de data: Data de retirada da REQ = hoje
Ordenação: Por hora (12:00 primeiro → 19:00 por último, com :30 intercalados)

Quando acontece

Após a impressão dos rótulos. Neste ponto, os dados já foram consolidados (nome do paciente, composição, posologia estão nos rótulos). A triagem técnica verifica se o que vai ser produzido é tecnicamente viável e seguro.

Como funciona

A Farm. Triagista pega o pedido em Ag. Triagem e faz quatro verificações, nesta ordem. Se qualquer uma das três primeiras falhar, o pedido todo volta. A quarta (datas) gera questionamento mas não necessariamente rejeição.

Verificação 1 — Dados do paciente

A Farm. Triagista confere se o nome do paciente nos rótulos é consistente com o pedido de venda. Parece trivial, mas erros aqui significam que o produto pode ir para a pessoa errada.

O que faz (físico): Compara visualmente o nome no rótulo com o nome no pedido.
O que muda (ERP): Nada ainda — só avança após todas as verificações.

Verificação 2 — Interação entre ativos

Verifica se os ativos de todos os produtos do pedido são compatíveis entre si. Um pedido pode ter 3 produtos — um sérum, um peeling, um selante — e os ativos de um podem interagir com os do outro.

O que faz (físico): Analisa a composição de cada produto da REQ. Cruza ativos entre todos os produtos do pedido. Verifica incompatibilidades conhecidas (ex: ácido retinóico + AHA em uso simultâneo).
Base de conhecimento: Experiência farmacêutica + protocolos da KB + literatura técnica.

Verificação 3 — Dosagens e forma farmacêutica

Verifica se cada ativo está dentro da faixa terapêutica segura e se a forma farmacêutica (creme, gel, sérum) é coerente com a base e o uso pretendido.

O que faz (físico): Confere concentração de cada ativo contra faixas conhecidas. Verifica se a forma farmacêutica é compatível com a base e o uso (ex: creme para uso tópico não pode ter ativo de uso oral).

Verificação 4 — Consistência de datas

A Triagem é o último gate humano antes da produção de fato começar. O Farm. Triagista verifica se as datas do pedido fazem sentido — especialmente quando o JSON da conferência automática sinalizou alerta de data (⚠️).

O que faz: Consulta o JSON consolidado e verifica se há alerta no campo datas.alerta. Se retirada_anterior_sem_prioridade, questiona: a data de retirada é antes da previsão e não tem prioridade marcada — foi intencional? O pedido vai aparecer na fila de produção antes de ser “esperado” pelo ERP.
Quando questiona: Quando o JSON traz datas.divergencia_tipo: "antecipado" e datas.prioridade_marcada: false
Ação: Se a data está incorreta, volta o pedido para que a Atendente corrija ou solicite prioridade. Se é intencional (casos excepcionais), registra observação e segue.

Ver Regra de consistência entre Previsão e Retirada para contexto completo.

Decisão — Aprovar ou rejeitar

Se tudo conforme, a Farm. Triagista avança o pedido para Triado no ERP. O pedido está liberado para manipulação.

Se não conforme, a Farm. Triagista detalha o motivo e decide para onde o pedido volta. Além de problemas técnicos (ativos, dosagens, interações), a Triagem é quem detecta problemas no rótulo impresso — falta de aviso ou erro de dados. O destino da volta depende do tipo de problema:

Dois tipos de volta do rótulo

Tipo de problema	Exemplo	Volta para	Quem resolve	O que acontece
Erro de dados (inconformidade OCR/PV/REQ)	Nome do paciente errado, composição divergente, dosagem errada no rótulo	Pago	Atendente corrige as fontes (OCR/PV/REQ), avança de novo para Ag. Impressão	JSON é regenerado, novo PDF do rótulo é gerado, Setor de Impressão reimprime
Falta de aviso (dados corretos, rótulo incompleto)	Rótulo precisa de aviso adicional (ex: “uso tópico”, “manter refrigerado”, alerta de interação)	Ag. Impressão	Setor de Impressão adiciona avisos no PDF, reimprime, avança para Impresso com PDFs alterados	Não precisa regenerar JSON — os dados estão corretos, só falta informação complementar no rótulo

A lógica da distinção: se o problema está nos dados (OCR, PV ou REQ incorretos), é preciso voltar até a origem dos dados (Pago) para corrigir e regenerar tudo. Se o problema está na apresentação do rótulo (dados corretos mas falta aviso), o Setor de Impressão tem autonomia para ajustar o PDF sem envolver o Atendente.

Volta por problema técnico (pedido inteiro)

Problemas técnicos (interação entre ativos, dosagem fora da faixa, forma farmacêutica inadequada) voltam o pedido inteiro. O que acontece depois depende da origem do pedido:

Resumo RACI

Verificação	R (Executa)	A (Presta contas)	C (Consulta)	I (Informado)
Dados do paciente	Farm. Triagista	Farm. Triagista	—	—
Interação entre ativos	Farm. Triagista	Farm. Triagista	—	—
Dosagens e forma farmacêutica	Farm. Triagista	Farm. Triagista	—	—
Consistência de datas	Farm. Triagista	Farm. Triagista	Atendente (se dúvida sobre data)	—
Rejeição por dados (volta Pago)	Farm. Triagista	Farm. Triagista	—	Atendente (corrige fontes)
Rejeição por falta de aviso (volta Ag. Impressão)	Farm. Triagista	Farm. Triagista	—	Setor de Impressão (adiciona aviso, reimprime)
Aprovação	Farm. Triagista	Farm. Triagista	—	—

Regras de decisão e escalação

Rejeição em pedido executivo: Normal e esperado. A prescrição veio de fora, a Neofarma não influenciou. Farm. Triagista detalha o problema. Pedido volta ao Atendente, que contata o profissional prescritor para ajustar.
Rejeição em pedido consultivo: Falha sistêmica. O consultivo só deveria sugerir o que já está validado. Se a triagem rejeita, o problema é no portfólio — não no atendimento. Gera ocorrência obrigatória tipo falha-sistemica. O protocolo que gerou a sugestão precisa ser corrigido.
Dosagem no limite: Se a dosagem está dentro da faixa mas no limite superior, Farm. Triagista libera com observação registrada. Se acima da faixa, rejeita.
Ativo desconhecido: Se a prescrição contém ativo que a Neofarma nunca manipulou, rejeitar e informar ao Atendente. Pode gerar processo de entrada de produto no portfólio.
Prescrição de profissional renomado com dosagens atípicas: Farm. Triagista pode liberar mediante registro de que a prescrição é de responsabilidade do profissional. Não criar precedente automático — cada caso é avaliado individualmente.

Exceções conhecidas

Pedido com um único produto: A verificação de interação entre ativos é simplificada (só verifica ativos internos do produto).
Prescrição de renovação (mesmo paciente, mesma fórmula): Farm. Triagista pode agilizar se já triou fórmula idêntica recentemente, mas ainda precisa verificar — a composição pode ter mudado no cadastro.

Detalhes de sistema

Mecanismos automáticos que operam neste processo. Referência completa em referencia-sistema-erp.

Avanço manual por pedido inteiro: Diferente das conferências (que operam por produto via pintar), a triagem avalia o pedido todo de uma vez. O Farm. Triagista avança manualmente no ERP — aprovação ou rejeição é do pedido inteiro.

JSON consolidado como fonte de alertas: O Farm. Triagista consulta o JSON gerado pela conferência automática para verificar alertas de data. Campos relevantes: datas.alerta (sinaliza divergência retirada × previsão), datas.divergencia_tipo (“antecipado” ou “postergado”), datas.prioridade_marcada (se a Gerente já marcou).

Filtro padrão da produção: A Triagem usa o mesmo filtro das demais etapas: status = Ag. Triagem + data de retirada da REQ = hoje + ordenação por hora. Ver Como cada etapa enxerga o trabalho do dia.

Volta para Ag. Impressão vs. Pago: O sistema permite voltar para dois destinos diferentes. Volta para Pago: o JSON é regenerado, novo PDF de rótulo gerado, Setor de Impressão reimprime tudo. Volta para Ag. Impressão: Setor de Impressão adiciona aviso no PDF existente, sem regenerar JSON. A distinção é: erro de dados → Pago; falta de aviso → Ag. Impressão.

Relação com outros processos

Recebe de: Impressão de rótulos → Ag. Triagem (etapas 6-7 do ERP). Os dados já estão cristalizados nos rótulos neste ponto — gerados a partir do JSON consolidado da conferência automática.
Entrega para (se aprovado): Manipulação — o Manipulador pega o pedido triado e produz
Entrega para (se rejeitado por dados): Volta até Pago — Atendente corrige fontes, JSON regenera, novo PDF
Entrega para (se rejeitado por falta de aviso): Volta até Ag. Impressão — Setor de Impressão adiciona aviso no PDF, reimprime
Entrega para (se rejeitado técnico, executivo): Volta ao Fluxo Executivo — Atendente renegocia com profissional
Entrega para (se rejeitado técnico, consultivo): Ocorrência falha-sistemica + revisão do protocolo
Conferência documental prévia: Conferência Automática já verificou que os 3 documentos são coerentes (usando regras de conferencia-pedido-ocr) — a triagem verifica se são tecnicamente viáveis
Alertas de data: Recebe alertas ⚠️ do JSON da conferência automática sobre divergência entre data de retirada e previsão. A triagem é o gate humano que decide se a divergência é aceitável.
Regras de datas e filtros: regras-datas-filtros-producao — define as 3 datas, filtro padrão da produção, e tipos de envio
Mapa de responsabilidades: Mapa de Responsabilidades por Etapa
Mecanismos de sistema: referencia-sistema-erp — avanço manual, JSON consolidado, filtro padrão

Histórico de evolução

Data	Mudança	Motivação
2026-03-31	Criação do documento com base na Cadeia 1 e distinção executivo/consultivo do CLAUDE.md	2026-03-31-processos-sem-raci
2026-04-01	Reestruturado: narrativa por verificação, ancorado em Ag. Triagem→Triado no ERP, dualidade físico×digital, RACI como resumo	Sessão de arquitetura com João
2026-04-02	Adicionadas referências à conferência automática (dados chegam via JSON consolidado), manipulação e mapa de responsabilidades	Criação do processo de conferência automática — rastreabilidade
2026-04-06	Adicionada Verificação 4 (consistência de datas), filtro de fila do dia (data retirada + hora), link para regras-datas-filtros-producao	2026-04-06-processos-sem-regras-datas-filtros-envio
2026-04-06	Adicionados dois tipos de volta do rótulo: erro de dados → Pago (Atendente corrige, JSON regenera), falta de aviso → Ag. Impressão (Setor de Impressão adiciona aviso, reimprime). RACI expandido com 3 linhas de decisão. Triagem é quem detecta problemas no rótulo, não o Setor de Impressão	Detalhamento com João — fluxos de volta e responsabilidades de impressão
2026-04-06	Adicionada seção “Detalhes de sistema” separando: avanço manual por pedido inteiro, JSON como fonte de alertas, filtro padrão, volta para Ag. Impressão vs. Pago. Link para referencia-sistema-erp	Agregação de detalhes de sistema na documentação de processos

Neofarma KB

Explorador