01 - Definição v6.0

Central do Médico (Cockpit) — Definição (v6.0)

Documentos desta funcionalidade: 01 - Definição (v6.0) · 02 - Especificação (v6.0) · 03 - Protótipo (v6.0, código executável em 03 - Protótipo v6.0.html) · 04 - Mapeamento de Banco de Dados (v6.0) · 05 - Registro de Decisões (v1.20)

---

SEÇÃO 1 — DEFINIÇÃO

Um dia na Central do Médico

Você chega à clínica para iniciar seu turno. Ao abrir o Gemed Onco, a primeira tela que surge é o seu Cockpit. No topo, quatro indicadores rápidos mostram que você tem 12 consultas hoje, 5 prescrições aguardando sua assinatura, 3 pacientes já em tratamento nas poltronas e 2 procedimentos em andamento na clínica.

Ao longo da manhã, você não precisa “caçar” informações. Se um paciente chega na recepção, o painel de Consultas atualiza sozinho, mostrando quem está com status Recepcionado (fez check-in, pronto para atendimento). Se surge uma dúvida da enfermagem, uma nova mensagem pisca no painel de Mensagens. Antes de chamar o próximo paciente, você bate o olho no painel Pacientes em procedimento e vê, por uma barra de progresso, que a infusão da Dona Maria está correndo dentro do tempo previsto. O painel mostra todos os pacientes em tratamento na clínica, não apenas os seus, permitindo uma visão global da operação da unidade. Quando sobra um minuto entre atendimentos, você acessa o painel de Prescrições Pendentes e, assina e revisa as prescrições do dia a partir de um único painel, garantindo que a farmácia e a enfermagem sigam o fluxo sem interrupções. É o seu dia controlado em uma única visão, sem cliques desnecessários.

Objetivo

Prover ao médico oncologista uma interface centralizada que consolide todas as informações críticas para a gestão do seu turno de trabalho em tela única. O foco é eliminar a navegação excessiva entre menus, reduzir a carga cognitiva e aumentar a segurança do paciente através de alertas visuais de atrasos e pendências críticas.

Escopo

• Incluído: Cabeçalho com busca inteligente (por nome, nome da mãe, CPF ou data de nascimento); Indicadores de desempenho (KPIs); Painel de Consultas cronológico; Painel de Prescrições para assinatura rápida; Painel de conversas e alertas internos (não é chat em tempo real — ver RN-CM-015); Monitoramento de tempo de infusão dos pacientes; Atalhos para o Prontuário Eletrônico (PEP).
• Excluído: Digitação de evoluções clínicas (feito no PEP); Criação de novos protocolos; Gestão de horários da agenda; Comunicação externa (E-mail/WhatsApp).

Personas

Persona	Papel no Sistema	Necessidade Principal
Médico Oncologista	Usuário Principal	Visão 360º do dia, agilidade na assinatura e monitoramento de segurança.
Recepcionista	Stakeholder operacional	Mantém as agendas atualizadas (status Agendado e Recepcionado). Recebe resultados de exames dos pacientes para encaminhar aos médicos. O status “Aguardando recepção” pode ser definido manualmente pela recepcionista ou via integração com totem de fila.
Enfermeira e Farmacêutica	Stakeholders clínicos (não usam o Cockpit diretamente)	Recebem prescrições assinadas para liberar o tratamento. A enfermagem só administra a prescrição depois que ela tiver sido assinada por um médico e, quando exigido, revisada antes da aplicação (regra completa em RN-CM-020). Enfermagem e Farmácia são tratadas como uma persona só nesta tabela porque nenhuma das duas interage com o Cockpit em si — aparecem aqui apenas como stakeholders impactados pelas decisões tomadas nele.

Workflows do Profissional

A Central do Médico é um hub que toca múltiplos workflows do profissional. Cada workflow é documentado abaixo com seu resumo e os touchpoints específicos da Central.

Workflow 1 — Atendimento de Consulta

Resumo: O paciente chega à clínica, pega número na fila de espera e aguarda ser chamado pela recepcionista, que faz o check-in. O paciente aguarda na sala de espera. O médico, antes de chamar o paciente, analisa o prontuário, verifica anotações e exames anteriores. Então chama o paciente, inicia o atendimento (perguntas, constatação do estado atual, análise de exames trazidos, solicitação de novos exames, prescrições). O médico pode registrar a evolução clínica durante ou após a consulta. Ao finalizar, fecha o atendimento e foca no próximo paciente. O paciente sai do consultório e vai embora ou passa na recepção para marcar retorno.

Touchpoints da Central:

Momento do workflow	Necessidade do profissional	O que a Central oferece	Decisão de design justificada
Antes de chamar o próximo paciente	Saber rapidamente quem está recepcionado e pronto para atendimento	Painel de Consultas com status “Recepcionado” em destaque (chip azul + borda lateral)	Filtro padrão prioriza quem falta atender (RN-CM-021).
Antes de chamar o próximo paciente	Identificar se o paciente está atrasado (horário passou e não iniciou)	Selo “Atrasado · Xmin” em vermelho leve, com ponto pulsante, no card de consulta (D-CM-054)	Pacientes atrasados provavelmente geram sobreposição de horários. Cabe ao médico decidir quem atender primeiro - o atrasado ou o pontual que já aguarda.
Entre atendimentos	Acessar o prontuário do próximo paciente sem navegar por menus	Clique no card de consulta abre diretamente o PEP	Um clique é o menor caminho entre identificar o paciente e o prontuário, que o médico precisa checar antes de chamá-lo.
Início do turno	Ter um panorama geral do dia (quantas consultas, quantas pendentes, quantas atrasadas — consultas cujo horário passou e que ainda não foram iniciadas)	KPI “Consultas Hoje” com número “finalizadas/total” e subtexto “pendentes · atrasadas”	Panorama de carga de trabalho em um olhar, sem abrir o painel, logo ao logar.
Durante o turno	Não ser interrompido por informações irrelevantes	Consultas finalizadas aparecem esmaecidas na sua posição original (RN-CM-021)	Durante o turno, o médico foca nos próximos atendimentos - finalizadas saem do foco visual sem sumir da lista.

Workflow 2 — Tratamento Oncológico (Monitoramento)

Resumo: O paciente em tratamento oncológico tem um plano terapêutico com ciclos e sessões previstos. Em cada dia de tratamento, o paciente chega à clínica, faz check-in, é preparado pela enfermagem (acesso venoso, sinais vitais) e inicia a infusão do quimioterápico. A enfermagem monitora o paciente durante a infusão (checagens periódicas). O médico acompanha o progresso do tratamento, avalia resposta, ajusta protocolo quando necessário e prescreve a próxima sessão. O tratamento pode ser suspenso por intercorrências (febre neutropênica, reação alérgica). O paciente pode não aderir ao planejamento (descompasso de intervalos entre ciclos).

Touchpoints da Central:

Momento do workflow	Necessidade do profissional	O que a Central oferece	Decisão de design justificada
Entre consultas / durante o turno	Saber quais pacientes estão em procedimento na clínica e em qual etapa	Painel Pacientes em procedimento com status (Em atendimento / Aguardando) e local na clínica	Consolida em um olhar onde cada paciente está no fluxo, sem o médico sair da sua tela.
Durante o monitoramento	Saber se uma infusão está dentro do tempo previsto ou atrasada	Barra de progresso inline (3px) na linha do nome, com porcentagem	Reforça o motivador de segurança de RN-CM-016 com monitoramento periférico; desenho discreto (3px) para não competir com nome/status.
Entre consultas	Decidir se precisa intervir em um procedimento em andamento	Clique no card abre a prescrição do procedimento; botão separado “PEP” abre o prontuário	A prescrição (o que está sendo infundido, dose, diluente) é a ação primária para decidir se intervir; o PEP é secundário, para contexto clínico completo.
Início do turno	Saber quantos pacientes estão em tratamento sob sua responsabilidade e quantos não estão aderentes	KPI “Em Tratamento” com número principal (em tratamento) e subtexto “não aderentes” (critério: RN-CM-023)	Identifica pacientes em risco de não adesão logo ao logar, sem abrir o painel.
Durante o turno	Filtrar apenas seus pacientes vs. ver todos (das clínicas em que atende)	Botão de alternância (toggle) “Meus / Todos” (default: Meus)	Default prioriza os próprios pacientes (RN-CM-021); alternar para “Todos” cobre casos como cobrir plantão de outro médico, sem mudar de tela.

Workflow 3 — Prescrição e Dispensação

Resumo: O médico define o protocolo de tratamento e prescreve os medicamentos para cada ciclo/sessão. A prescrição fica pendente de assinatura. O médico assina (com ou sem certificado digital) na véspera ou no dia da aplicação. A farmácia recebe a prescrição assinada e manipula o medicamento. Como segunda barreira de segurança, o sistema marca automaticamente a prescrição como pendente de revisão a partir do dia anterior à aplicação agendada (valor-padrão de 1 dia de calendário, configurável por clínica) — um médico (preferencialmente o prescritor ou o médico assistente do paciente) precisa abrir a prescrição e confirmá-la como revisada antes que a enfermagem possa administrar o medicamento. A prioridade das prescrições não revisadas cresce da mesma forma que a das não assinadas, conforme a hora da aplicação se aproxima.

Touchpoints da Central:

Momento do workflow	Necessidade do profissional	O que a Central oferece	Decisão de design justificada
Início do turno / entre atendimentos	Assinar prescrições pendentes antes que a farmácia possa manipular	Painel de Prescrições Pendentes com botão “Assinar” no card que abre a tela de assinatura com a prescrição completa	A assinatura é o gargalo que abre o resto do fluxo (a farmácia só manipula depois dela) — daí a prioridade de expô-la logo no painel.
Início do turno	Priorizar quais prescrições assinar primeiro (as mais urgentes)	Chips de urgência: vermelho (<12h) e laranja (12-24h) com tempo restante	Cor sinaliza, de longe, que a janela de ação está fechando (limiares em RN-CM-011).
Dentro da janela de revisão (padrão: aplicação hoje ou no dia seguinte, até 23:59)	Confirmar que a prescrição foi revisada por um médico antes da administração ao paciente	Card de prescrição tipo “Revisar”, gerado automaticamente pelo sistema (RN-CM-020). Botão “Revisar” abre a prescrição completa para o médico validar ou ajustar antes de confirmar	Reaproveita a mesma escalada visual (chip vermelho/laranja) das prescrições não assinadas (RN-CM-011) — o médico já reconhece o padrão.
Início do turno	Saber quantas prescrições urgentes (menos de 12h) precisam de sua atenção	KPI “Alertas de Prescrição” com número principal (urgentes) em vermelho e subtexto com duas contagens: total a revisar, e a assinar nos próximos 7 dias	Número em vermelho chama atenção imediata ao logar; subtexto dá contexto sem competir com ele.
Ao assinar uma prescrição	Confirmar que a assinatura foi processada e retornar à Central	Toast de sucesso “Prescrição assinada com sucesso” + retorno automático à Central, focada no painel de Prescrições Pendentes + atualização do KPI	Toast + retorno automático + decremento do KPI fecham o loop de feedback sem o médico precisar navegar de volta manualmente.
Ao revisar prescrições	Focar primeiro nas prescrições que é preferencialmente responsável por revisar (seus pacientes), mas poder ajudar a revisar as de colegas quando necessário	Toggle pill “Meus / Todos” no painel de Prescrições Pendentes (RN-CM-021)	O médico prioriza naturalmente seus próprios pacientes, mas pode ajudar a revisar as de colegas quando necessário — daí o toggle (comportamento exato: RN-CM-021).

Workflow 4 — Comunicação Interna

Resumo: Diferentes profissionais da clínica (organizados em equipes, como recepção, farmácia e enfermagem) precisam comunicar informações ao médico durante o turno: recados, solicitações, resultados de exames, dúvidas sobre prescrições, notificações de intercorrências. Módulos do sistema também podem gerar alertas automáticos (ex: prescrição urgente, atraso de infusão). O emissor — pessoa ou módulo — pode definir um prazo para resposta. O médico recebe essas conversas, precisa priorizá-las, pode responder diretamente pelo Cockpit, ou resolvê-las/descartá-las e arquivar as encerradas. Algumas são urgentes (intercorrência durante infusão), outras são informativas (confirmação de manipulação). Diferente de uma notificação avulsa, cada item é uma conversa (thread) que pode acumular respostas de ambos os lados.

Touchpoints da Central:

Momento do workflow	Necessidade do profissional	O que a Central oferece	Decisão de design justificada
Durante todo o turno	Receber conversas e alertas da equipe sem sair da Central	Painel de Mensagens com conversas em aberto (RN-CM-015)	Integra comunicação ao cockpit para resposta rápida entre atendimentos, sem alternar de tela.
Ao receber uma conversa nova	Identificar rapidamente que há conversa não lida	Conversas não lidas com ícone colorido e borda lateral destacada (RN-CM-015)	Identificação periférica de pendências sem precisar ler o conteúdo.
Ao revisar a lista de conversas	Priorizar conversas com prazo de resposta	Prazo exibido no card (“Responder até 14:00”) + ordenação por prazo primeiro	Prazo é compromisso — visível no card, permite triagem sem abrir a conversa.
Ao precisar esclarecer algo rapidamente	Responder sem sair do Cockpit, sem precisar telefonar ou ir até a equipe	Campo de resposta no modal da conversa — envia uma nova mensagem na thread e muda o status para “Respondida”	Muitas dúvidas simples (confirmar uma dose, avisar que já viu o recado) cabem numa frase — uma tela separada de chat quebraria o fluxo entre atendimentos.
Ao resolver uma solicitação	Arquivar a conversa com um botão e uma confirmação	Botão “Resolvido” no modal (RN-CM-015)	Resolver só depois de abrir e ler: o botão não fica no card, para ninguém encerrar para toda a equipe um item que não leu (D-CM-089).
Ao receber algo puramente informativo, sem necessidade de resposta	Tirar a conversa do painel sem marcá-la como resolvida	Botão “Descartado” no card (RN-CM-015)	Nem toda conversa pede uma resolução — descartar existe como saída separada para o que já cumpriu seu papel só por ter sido visto (ex: confirmação de manipulação da farmácia).
Durante todo o turno	Distinguir se a conversa é de uma pessoa ou um alerta automático	Ícone identificador — pessoa ou sino, conforme a origem (RN-CM-022; ícone exato: Seção 2.8)	Categorização visual instantânea da origem, sem ler o texto.
Ao ler a resposta de uma conversa endereçada a uma equipe	Saber que quem respondeu falou pela equipe, não só por si mesmo	Nome da equipe exibido junto ao nome de quem escreveu, em toda mensagem dela (RN-CM-015, RN-CM-022)	Sem essa informação o médico não sabe se está falando com a equipe como um todo ou só com uma pessoa específica — relevante para saber a quem cobrar depois.

Regras de Negócio Consolidadas

Cada regra abaixo tem um código (ex: RN-CM-020) que permite localizá-la e rastreá-la até sua implementação na Seção 2. A numeração tem saltos (ex: de RN-CM-006 para RN-CM-011) porque regras intermediárias foram consolidadas ou removidas ao longo de revisões anteriores deste documento — não é um sinal de conteúdo faltando.

Layout e Visualização

• RN-CM-001 — Tela única, sem rolagem geral: A Central ocupa a tela inteira — o médico vê os 4 painéis sem precisar rolar a página principal. Cada painel rola de forma independente quando tem mais itens do que cabem no espaço disponível. (Detalhamento técnico de implementação do scroll independente por painel: ainda não especificado na Seção 2 desta versão — a referência anterior a “Seção 2.8” estava incorreta, essa seção não cobre este comportamento.)
• RN-CM-002 — Quatro painéis fixos: A interface é dividida em quatro quadrantes fixos, cada um com uma função específica:
  • Quadrante superior esquerdo — Consultas: Agenda de consultas do médico no dia, com status visual de cada paciente (Agendado, Aguardando recepção, Recepcionado, Em atendimento, Finalizado).
  • Quadrante superior direito — Prescrições Pendentes: Lista de prescrições que aguardam ação do médico, divididas em duas categorias: prescrições para assinar (aguardando assinatura digital) e prescrições para revisar (já assinadas, marcadas automaticamente pelo sistema quando a aplicação agendada está dentro da janela de revisão (padrão: 1 dia) e ainda não foi revisada por nenhum médico, nem assinada depois de a janela ter aberto — RN-CM-020).
  • Quadrante inferior esquerdo — Mensagens: Conversas e alertas não lidos, de pessoas/equipes ou do sistema, com ação de responder, resolver ou descartar, feita dentro do modal da conversa.
  • Quadrante inferior direito — Pacientes em procedimento: Monitoramento de pacientes previstos e presentes na unidade para procedimentos e tratamentos (infusões, aplicações, checagens) — não inclui consultas médicas, apenas procedimentos terapêuticos e diagnósticos. O painel é um resumo; o detalhe fica numa tela exclusiva de Pacientes em procedimento (ainda a definir), aberta por um item do Menu Lateral (D-CM-031).
  • Diferenciação visual: O cabeçalho de cada painel possui um fundo cinza claro para se diferenciar do corpo do painel (fundo branco), orientando o olhar do usuário entre a área estrutural e a área de conteúdo. (Cor exata: ainda não tokenizada na Seção 2.8 desta versão — a referência anterior apontava para lá, mas a tabela de componentes não lista este par de cores; a especificar.)
• RN-CM-003 — Títulos como links de navegação: Os títulos dos 4 painéis são clicáveis e funcionam como links para as telas dedicadas correspondentes. No estado normal, o título aparece em peso regular (sem negrito) com cor neutra; ao passar o mouse ou tocar (conforme o dispositivo), a cor muda para o azul secundário e uma seta (→) aparece discretamente ao lado do título. (Cor exata: Seção 2.8.) Esta abordagem substitui links separados (‘Ver agenda →’, ‘Ver todas →’, etc.), reduzindo ruído visual no cabeçalho. Motivador: o título é o elemento mais natural para clicar; a seta ao interagir garante descobribilidade sem poluir o estado normal.

Busca Inteligente

• RN-CM-004 — Lógica de Busca: A busca começa a filtrar assim que o médico digita 2 caracteres e para por um instante — não a cada tecla, para não sobrecarregar o sistema com uma consulta a cada letra digitada (intervalo exato: Seção 2.1). Se a entrada começar com número, busca por CPF ou Data de Nascimento; se começar com letra, busca por Nome do Paciente ou Nome da Mãe. A busca é aproximada — usa o mecanismo de correspondência já existente no sistema (fora do escopo desta especificação), que tolera erros de digitação e nomes parecidos, sempre retornando a lista mais provável mesmo sem um resultado exato. Motivador: um médico buscando entre atendimentos não pode perder tempo digitando um nome ou CPF completo e correto — a tolerância a erro é o que torna a busca realmente rápida de usar.

Consultas e Atendimento

• RN-CM-005 — Status de Atendimento: As consultas devem refletir o status real:
  • Agendado = consulta marcada, mas sem mais interações
  • Aguardando recepção = paciente está presente na clínica, mas ainda não fez o check-in
  • Recepcionado = paciente fez o check-in com a recepção e está pronto para ser atendido
  • Em atendimento = paciente está em atendimento com o profissional (médico)
  • Finalizado = paciente já realizou a consulta
• RN-CM-006 — Ordenação: A lista de consultas é sempre cronológica, priorizando o próximo atendimento.
• RN-CM-030 — Horário bloqueado não é consulta: um horário que a Recepção bloqueou na agenda do médico (Agenda do Médico, RN-AGM-019) é uma reserva de tempo, não um atendimento — não aparece no painel de Consultas e não entra em nenhum número do indicador “Consultas Hoje” (total, finalizadas, pendentes ou atrasadas), nem em nenhuma outra contagem de agendas ou de pacientes desta funcionalidade. Motivador: contar um bloqueio como consulta inflaria a carga de trabalho do dia e poderia exibi-lo como um paciente “atrasado”. Para ver os bloqueios da própria agenda, o médico abre a Agenda do Médico, que os exibe. Mapeamento técnico do filtro: Seção 4.1/4.2.
• RN-CM-031 — Consulta em atendimento além do previsto: a consulta em atendimento está sob controle do médico, e uma consulta que fica aberta além da duração prevista na agenda provavelmente é uma anomalia — o atendimento não foi fechado, ou foi iniciado sem querer e o médico não está atendendo. Por isso, quando o tempo desde o início do atendimento passa da duração prevista, o card mostra o tempo decorrido em destaque (ex.: “há 1h20”), com ícone e cor de atenção, para incomodar o olhar. Não há tolerância, e o destaque some quando a consulta é finalizada. A consulta em atendimento continua sendo “pendente” e não é “atrasada” (D-CM-008).
• RN-CM-032 — Escopo de clínicas do médico (consultas, prescrições, procedimentos e mensagens): o login é autorizado para um cliente (tabela Cliente); as clínicas do cliente (ClienteEmpresa) têm os dados no banco do cliente (ClienteBD). Durante o login naquele cliente, o médico vê as agendas (painel e indicador de Consultas, painel e indicador de Procedimentos), as prescrições (painel e indicadores) e as mensagens das clínicas em que ele atende, e não só as da clínica em que está logado — o mesmo critério da Agenda do Médico (RN-AGM-002) (D-CM-066, que substitui nesse ponto D-CM-050 e D-CM-060). Uma clínica do cliente em que o médico não atende fica de fora das agendas, das prescrições, dos procedimentos e das mensagens: ele não é médico dela e não pode atender, revisar, assinar prescrições nem enviar mensagens por ela. Como o sistema sabe em quais clínicas o médico atende (D-CM-067): são as clínicas do cliente a que o usuário tem acesso (RN-CIU-009), o mesmo critério da Agenda do Médico (ClinicVisible()); quem perde o acesso a uma clínica deixa de ver as agendas e as prescrições dela, mas não perde o acesso aos pacientes (D-CM-068, D-CM-070); a expectativa é que essas agendas e prescrições sejam redirecionadas ou canceladas, o que é expectativa dele e não uma regra definida. Isto é uma exceção do sistema, só para médicos: os demais profissionais ficam restritos à clínica escolhida na tela de seleção de clínicas. Ao trocar de clínica, o médico pode trocar de cliente e passa a ver as clínicas em que atende no novo cliente. Regras de cada clínica: as janelas de prescrição de RN-CM-020 (“a assinar” e “a revisar”) obedecem aos parâmetros da clínica de cada prescrição, isto é, a clínica da agenda dela (D-CM-060); o “hoje”, o fim do dia de cada janela e os horários exibidos seguem o fuso da clínica em que o usuário está logado (RN-AGM-018, D-CM-062), também para prescrições de clínicas de outro fuso: o médico vê um só dia e as mesmas horas em toda a tela, e não se confunde achando que uma prescrição está adiantada quando já está na hora. Exibição: quando o médico atende em mais de uma clínica, cada card de consulta, de prescrição, de procedimento e de mensagem mostra o nome curto da clínica, como informação secundária (RN-AGM-017, a; E-CM-028, D-CM-061); com uma só clínica, a informação não aparece. Os indicadores “Consultas Hoje”, “Procedimentos Hoje” e “Alertas de Prescrição” e o toggle “Todos” das prescrições seguem o mesmo escopo (E-CM-029): “Todos” soma as prescrições de todos os médicos, mas só nas clínicas em que o médico logado atende. O card de mensagem também mostra a clínica (D-CM-064), e só entram conversas de clínicas em que o médico atende. O rótulo do indicador de alertas e o indicador “Em Tratamento” usam os parâmetros da clínica em que o médico está logado (D-CM-063). A Agenda do Médico segue o mesmo critério, agora com filtro explícito (D-CM-068). O que é medido por paciente — o indicador “Em Tratamento”, a adesão ao protocolo e a busca de pacientes — não tem filtro por clínica, porque o médico não perde o acesso ao paciente (D-CM-070). Para o médico, Paciente.IdChClinica não faz diferença; ele será filtro para o administrativo e outras funções, fora do escopo da Central.

Tags de Atenção

• RN-CM-025 — Tags de Atenção: Tags são marcadores visuais criados e administrados por cada clínica (não fixos no sistema), atribuídos a um paciente — no cadastro do paciente ou no prontuário — para sinalizar rapidamente uma característica que merece atenção do profissional (ex.: VIP, em quimioterapia). Aparecem em pontos definidos da aplicação — nesta funcionalidade, nos cards dos painéis de Consultas e de Pacientes em procedimento (Seção 2) — apenas as tags habilitadas, na definição de cada tag, para exibição em agendas — os dois painéis são, na prática, agendas do dia (de consultas e de procedimentos), e é esse o critério que vale, não o nome da tela que os hospeda: uma tag pode existir e estar ativa para o paciente sem aparecer aqui, se não tiver sido habilitada para agendas (mesmo critério usado pela Agenda do Médico, RN-AGM-006). Além disso, a própria tag pode ter um período de vigência opcional, definido no seu cadastro — quando definido (início, fim, ou ambos), a tag só é exibida dentro desse período; sem período definido, não há essa restrição. Esse período de vigência da tag é distinto da atribuição da tag a um paciente específico (que tem seu próprio período: no cadastro, o da atribuição; no prontuário, o do registro de prontuário em que a tag foi atribuída). A tag VIP é uma tag administrativa, atribuída no cadastro do paciente como as demais, e é exceção a ambos os critérios (habilitação por tela e vigência da tag) — é sempre exibida. O cadastro e a administração das tags em si (quais existem, cores, quem pode criar, em quais telas cada uma aparece, período de vigência) pertencem a uma funcionalidade própria, fora do escopo deste documento — aqui só se documenta como elas aparecem no Cockpit e o critério de exibição nesta tela; mapeamento técnico do filtro: Seção 4.1. Vigência por data: os períodos de vigência (da tag e da atribuição ao paciente) são comparados só pela data, no fuso da clínica, sem a hora: a tag vale desde o dia do início e inclui o dia do fim. Ordem no card: primeiro o ícone de 1ª Consulta (junto ao nome), depois as tags assistenciais (atribuídas no prontuário) e por fim as administrativas (atribuídas no cadastro, como VIP); dentro de cada grupo, ordem alfabética pela sigla. A tag “1ª Consulta”, embora exibida visualmente junto com essas tags, não pertence a este cadastro — ver RN-CM-028.
• RN-CM-028 — Ícone de 1ª Consulta: Diferente das demais Tags de Atenção (RN-CM-025), que vêm do cadastro de tags da clínica (ProgramaApoio), a primeira consulta do paciente é sinalizada por um ícone (circle-number-1, Tabler Icons), não por um chip de texto. A sinalização é derivada diretamente da agenda do dia (Agenda.PrimeiraConsulta = 'S'), sem cadastro nem período de vigência geridos pela clínica — a cor é fixa no sistema (token --color-first-visit do Design System). O ícone aparece logo depois do nome do paciente, nos mesmos painéis que as demais Tags de Atenção (Consultas e Pacientes em procedimento), mas não está sujeita ao bitmask MostrarEm nem ao período de vigência do ProgramaApoio, por não pertencer a esse cadastro. O ícone abre uma dica com o texto “1ª Consulta” quando recebe o toque (no celular) ou o mouse — a dica não depende de passar o mouse, que não existe em tela de toque. O ícone não recebe o foco do teclado: o leitor de tela lê “1ª Consulta” no nome do card, e é aceito que, com o uso, o médico associe o símbolo à primeira consulta (D-CM-035).

Prescrições e Assinatura

• RN-CM-011 — Alertas de Urgência: Prescrições com menos de 12 horas para a aplicação ganham um alerta vermelho. Entre 12h e 24h, o alerta é laranja. A partir de 24h restantes, não há alerta visual — o tempo restante continua sendo exibido, só sem destaque de cor, porque a urgência ainda não justifica chamar a atenção do médico para aquela prescrição especificamente (a prescrição continua na lista normalmente, só sem o realce). Isso ocorre com frequência, já que uma prescrição pendente de assinatura pode aparecer na lista com bem mais de 24h de antecedência (Seção 4.7) — a ausência de alerta nesse caso é o comportamento esperado, não uma lacuna. Por enquanto, esses limiares (12h/24h) são valores fixos no sistema, iguais para todas as clínicas — não um parâmetro configurável (diferente dos limiares de tempo de RN-CM-020, que são parâmetro por clínica). Esta regra vale tanto para prescrições pendentes de assinatura quanto para prescrições pendentes de revisão (RN-CM-020) — a urgência é sempre calculada em relação ao tempo restante até a aplicação agendada, independentemente do tipo de pendência. Quando a hora da aplicação já passou e a prescrição ainda não foi assinada ou revisada, ela continua na lista com o atraso no lugar do tempo restante e o mesmo alerta vermelho, e continua contando como urgente até que seja assinada ou revisada. O atraso é escrito em minutos abaixo de 1 hora (“40min atrasada”), em horas e minutos de 1 hora até 47h59 (“1h59 atrasada”) e em dias a partir de 48 horas (“30 dias atrasada”); do mesmo modo, o tempo restante abaixo de 1 hora aparece em minutos (“45min restantes”). A lista de prescrições é ordenada pelo tempo restante, do menor para o maior (as vencidas primeiro), com desempate pelo nome do paciente, em ordem alfabética (D-CM-047) e, para o mesmo nome, pelo identificador da prescrição (E-CM-027).

• RN-CM-012 — Assinatura Digital: A assinatura de prescrições pode ocorrer de 2 modos, definidos por parâmetro de configuração do cliente: (a) assinatura com certificado digital — exige que o médico possua certificado digital ativo vinculado ao seu perfil; (b) assinatura sem certificado — validada apenas pela sessão do usuário logado, sem exigência de certificado. O modo ativo é determinado pela configuração da clínica. Motivador: nem toda clínica tem infraestrutura ou exige assinatura com certificado digital (padrão ICP-Brasil, a infraestrutura de certificação usada no Brasil) para prescrições — por isso o modo é configurável por clínica, não fixo no sistema. Quando o modo exige certificado e o médico não tem um certificado ativo, ele não pode assinar digitalmente e segue o processo de assinatura física em papel (fora do escopo deste documento). Em ambos os modos, a ação de assinar sempre abre a prescrição completa para o médico revisar antes de confirmar — nunca é um clique direto a partir do card, porque é responsabilidade do médico saber o que está assinando.

• RN-CM-020 — Revisão Automática Pré-Aplicação: Antes de a enfermagem administrar uma prescrição, a clínica espera que ela tenha sido assinada por um médico e, perto da aplicação, revisada — ou assinada já dentro da janela de revisão, o que dispensa a revisão (D-CM-040). A revisão é uma segunda barreira de segurança, desvinculada de qualquer notificação de problema pela farmácia ou enfermagem. A Central não bloqueia a administração: ela mostra as pendências, e o bloqueio, se existir, é do fluxo da enfermagem (fora deste documento). A classificação segue uma ordem de precedência: primeiro verifica se a prescrição precisa ser assinada; só depois, se precisa ser revisada — nunca as duas ao mesmo tempo. Não existe mais o conceito de “assinatura vencida”: uma vez assinada, a prescrição nunca volta a exigir nova assinatura só por decurso de tempo — essa era a regra até a v4.38 (ver Histórico). As duas janelas só limitam a antecedência, não há limite para trás: uma prescrição cuja hora de aplicação já passou continua na lista — com o tempo restante negativo e o alerta vermelho de RN-CM-011, contando como urgente — até ser assinada (“a assinar”) ou revisada (“a revisar”). Uma prescrição nessa situação, com a agenda já passada, indica falha de processo da clínica (uma agenda de paciente que não veio e não foi cancelada nem marcada como falta); a correção é da Recepção, que cancela a agenda ou registra a falta, e a Central apenas mantém o problema visível (D-CM-033). Do mesmo modo, uma prescrição que chega a procedimento sem nenhuma assinatura é falta grave de processo: espera-se que o fluxo da enfermagem bloqueie o início do procedimento, e a Central não trata esse caso como normal (ela permanece em “a assinar”). Uma consequência aceita desta simplificação: uma prescrição já assinada, nunca formalmente revisada e com aplicação ainda além da janela de revisão não aparece em nenhuma das duas listas até a aplicação entrar na janela — sem um mecanismo de expiração para trazê-la de volta à atenção do médico antes disso. Em detalhe:

  • Precedência 1 — “a assinar”: a prescrição é “a assinar” quando nunca foi assinada por nenhum médico (fonte da assinatura, incluindo compatibilidade com prescrições legadas: RN-CM-029) e a aplicação agendada cai até o fim do dia de hoje mais 7 dias (valor-padrão; contado em dias de calendário no fuso da clínica em que o usuário está logado (D-CM-062), como na janela de revisão: com hoje dia 10, entram as aplicações até 17 às 23:59) — inclusive quando a hora da aplicação já passou. Essa janela de antecedência é um parâmetro configurável por clínica, em dias de calendário — mapeamento completo do parâmetro de banco (PrescricaoTempoAssinatura) na Seção 4.6. Com várias clínicas, vale o parâmetro da clínica da prescrição (clínica da agenda dela), não o da clínica em que o médico está logado (RN-CM-032, D-CM-060). Uma prescrição nunca assinada, mas com aplicação além dessa janela, ainda não aparece em nenhuma das duas listas — só entra em “a assinar” quando a aplicação se aproxima.
  • Precedência 2 — “a revisar”: só é avaliada quando a prescrição já foi assinada ao menos uma vez, em qualquer momento (portanto não é “a assinar”). Nesse caso, quando a aplicação agendada cai até o fim do dia de hoje mais N dias (N = 1, valor-padrão; contado em dias de calendário no fuso da clínica em que o usuário está logado (D-CM-062), não em horas: com N = 1 e hoje dia 10, entram as aplicações dos dias 10 e 11, até 23:59) — inclusive quando a hora da aplicação já passou —, e ainda não existe confirmação de revisão (“Marcar como Revisada”), o sistema marca a prescrição como “a revisar” — salvo em dois casos (D-CM-039, D-CM-040): (a) a assinatura do médico foi feita depois de a janela de revisão daquela prescrição ter aberto, isto é, na meia-noite do dia da aplicação menos N dias ou depois (com N = 1 e aplicação no dia 23, a janela abre às 00:00 do dia 22: assinada no dia 22 a prescrição não precisa de revisão; assinada no dia 21, precisa) — a assinatura feita já perto da aplicação dispensa a revisão; (b) a administração da prescrição já começou (o procedimento está em andamento), caso em que revisar já não faz sentido e a prescrição sai da lista. Diferente da assinatura, a confirmação de revisão não tem prazo de validade: uma vez revisada, a prescrição não volta a aparecer nesta lista, mesmo que a administração seja adiada. A assinatura que dispensou a revisão, ao contrário, perde esse efeito se a aplicação for adiada para depois do limite: a comparação é refeita com a nova data de aplicação, e a prescrição entra em “a revisar” quando essa data entrar na janela (D-CM-052, D-CM-059): ela não volta a ser “a assinar” — a prescrição já assinada não precisa ser assinada de novo —, só volta a “a revisar” quando a nova data entrar na janela de revisão. Essa janela de antecedência (1 dia, quando a clínica não configura outro valor) é o parâmetro NumeroDiasRevisaoPrescricoes, já existente no sistema atual (número máximo de dias à frente em que o revisor vê prescrições para revisar), configurável por clínica, em dias, independente da janela de “a assinar” — mapeamento completo do parâmetro de banco na Seção 4.6. Com várias clínicas, vale o parâmetro da clínica da prescrição (RN-CM-032, D-CM-060).
  • Nem uma coisa nem outra: uma prescrição já assinada e já revisada, ou já assinada mas com aplicação fora de ambas as janelas de antecedência (nem perto o bastante da aplicação para “a revisar”, nem — por já estar assinada — elegível para “a assinar”), não aparece em nenhuma das duas listas.
  • Só entram nas duas listas prescrições que ainda estão em andamento: já finalizadas, faturadas, de atendimento externo ou canceladas não precisam mais de assinatura ou revisão para fins deste painel, mesmo que nunca tenham sido assinadas ou revisadas (domínio completo de situações em Seção 4.5 do Mapeamento de Banco de Dados). Esse filtro, combinado com a abolição da assinatura vencida, evita que prescrições já aplicadas há muito tempo, mas nunca formalmente revisadas, se acumulem indefinidamente na lista de “a revisar” (ver achado documentado no Mapeamento de Banco de Dados, Seção 4.6, e nos Cenários de Teste).
  • Quem revisa: qualquer médico pode revisar, mas o sistema sinaliza preferencialmente o médico prescritor e o médico assistente do paciente como revisores ideais.
  • O que “revisar” significa: o médico pode apenas confirmar a prescrição como revisada (“Marcar como Revisada” — registra uma nova confirmação de revisão, sem alterar a prescrição em si) ou, se identificar necessidade de ajuste, editá-la — o que gera uma nova versão da prescrição (novo registro, com a versão anterior cancelada) que precisa ser assinada novamente (volta à Precedência 1, como uma prescrição nunca assinada: a nova versão nasce sem nenhuma assinatura, nem a moderna nem os campos legados, e entre as versões só uma é válida, as outras ficam canceladas — D-CM-050, D-CM-052).
  • Prescrições “a revisar” seguem a mesma escala de urgência de prescrições não assinadas (RN-CM-011), conforme o tempo restante até a aplicação.
  • Regra vigente “por enquanto”: sujeita a revisão futura, como qualquer regra deste documento.

• RN-CM-029 — Compatibilidade legada para a assinatura: além do registro de assinatura do médico em PrescricaoAssinatura (tipo A — Precedência 1 de RN-CM-020), um par de campos legados também conta como evidência de que a prescrição já foi assinada, para prescrições gravadas antes da adoção da tabela de assinaturas atual: Prescricao.IdChProfissionalAssinou (o médico que assinou) e Prescricao.DataAssinaturaPrescricao (a data dessa mesma assinatura) — os dois registram o mesmo evento legado, não duas fontes independentes. Isso fecha a antiga ambiguidade sobre IdChProfissionalAssinou “sem data própria” ([A DEFINIR] desde a v4.28 do Mapeamento de Banco de Dados): a data existe, é DataAssinaturaPrescricao. Como também não existe mais o conceito de validade/vencimento de assinatura (RN-CM-020), essa distinção deixou de ter efeito prático nesta versão — mas a relação correta entre os dois campos passa a estar documentada. Mapeamento completo na Seção 4.6/4.7.

Comunicação Interna

• RN-CM-015 — Conversas, Alertas e Priorização: Toda comunicação no Cockpit (mensagens entre profissionais e alertas automáticos do sistema) é tratada como uma conversa, que pode acumular várias mensagens — como uma thread. Em detalhe:
  • Não lida: uma conversa fica marcada como “não lida” até que o médico a abra; abrir não a remove do painel, só tira o destaque visual e a empurra para depois das ainda não vistas na ordenação (ver “Ordenação” na Seção 2.5).
  • O que aparece no painel: o painel compacto do Cockpit (Seção 2.5) mostra todas as conversas em aberto do médico logado — lidas e não lidas. Uma conversa só desaparece dali quando é marcada como Resolvida ou Descartada; essa ação é definitiva (não pode ser desfeita) e é precedida de uma confirmação que avisa que a ação vale para todos os destinatários (D-CM-032); vale para todos os destinatários — uma conversa endereçada a uma equipe ou a mais de uma pessoa sai do painel de todos quando qualquer um a resolve ou descarta — e fica registrada no histórico da conversa; não há “desfazer”, porque a conversa é uma ferramenta de comunicação entre profissionais. O histórico completo (incluindo as já resolvidas/descartadas) fica reservado a uma tela dedicada, fora do escopo desta versão.
  • Prazo: quem inicia a conversa — uma pessoa ou um módulo automático do sistema — pode definir um prazo para resposta ou resolução.
  • Resposta: o médico pode responder diretamente pelo Cockpit, sem precisar telefonar ou ir até quem enviou; responder também marca a conversa como lida.
  • Equipe (destinatário coletivo): uma conversa pode ser endereçada a uma equipe (recepção, farmácia, enfermagem) em vez de a uma pessoa específica — todos os membros da equipe recebem a conversa como destinatários. Quando um membro da equipe responde, a resposta é a mesma para todos: o médico e os demais membros da equipe veem a mesma thread, não cópias separadas. Toda mensagem escrita por um membro de uma equipe dentro de uma conversa endereçada a ela mostra o nome da equipe junto ao nome de quem escreveu (RN-CM-022) — a pessoa está respondendo como representante da equipe, não só em nome próprio.
  • Alerta recorrente: se o mesmo tipo de alerta automático acontecer de novo depois de uma conversa já encerrada, o sistema abre uma conversa nova (não reabre a antiga), mas mantém o vínculo com a anterior para quem for consultar o histórico depois.
  • Retorno à camada de não lidas: se uma conversa que o médico já respondeu recebe uma nova mensagem depois dessa resposta, ela volta para a camada de não lidas do painel — destaque visual restaurado, prioridade de ordenação elevada de novo. O card mostra a mensagem nova e quem a escreveu; não há selo de estado (“Respondida”).
  • Leitura pelos outros: quando a última mensagem da conversa é do médico, o card mostra se ela já foi lida por pelo menos um dos outros participantes — um visto quando só foi enviada, dois vistos quando foi lida.
  • Grau de urgência (D-CM-088): a conversa pode ter um grau opcional, definido no envio ou pelo módulo de origem e imutável: Rotina, Urgente, Quanto antes ou Imediato (domínio do HL7; RN-MSG-034 da Mensageria). O card mostra o nome do grau num chip, inclusive Rotina; sem grau, nada aparece.
  • Horário no card (D-CM-088): relativo ao momento atual, no fuso da clínica — “Há x min” (mesmo dia, menos de 1 hora), “Há x h” (mesmo dia) ou data e hora (dia anterior); dentro do modal, sempre data e hora (RN-MSG-035).
  • Ordem: primeiro as conversas não lidas, depois as lidas; dentro de cada grupo, vem primeiro o maior grau de urgência (Imediato, Quanto antes, Urgente, Rotina, sem grau) e, com o mesmo grau, a de data mais recente, e a data de cada conversa é a mais recente entre a última mensagem e o prazo para resposta (quando existe); em caso de empate, vem primeiro a conversa criada mais recentemente. É a mesma regra da tela de Mensagens (RN-MSG-002).
  • (Detalhamento técnico — nomes de campo, fórmula de “não lida”, modelo de dados: Seção 2.5 e Seção 4.8.)
• RN-CM-022 — Identificação da origem: Cada conversa exibe um ícone que distingue apenas se a origem é uma pessoa ou um alerta automático do sistema — o ícone continua binário (pessoa vs. sistema), sem uma variação por equipe (recepção, farmácia, enfermagem). Quando a mensagem foi escrita por um membro de uma equipe respondendo em nome dela (conversa endereçada à equipe — RN-CM-015), o nome da equipe aparece como texto ao lado do nome da pessoa (ex.: “Sandra (Farmácia)”), em vez de uma variação de ícone. Motivador: um ícone por equipe seria redundante com o nome por extenso já exibido em cada mensagem; a identificação da equipe fica a cargo do texto, não do ícone.

Pacientes em procedimento (Monitoramento)

• RN-CM-016 — Barra de Progresso: Exibe o tempo decorrido do procedimento versus o tempo de aplicação previsto na prescrição. Se ultrapassar 100%, a barra torna-se vermelha. Motivador: o tempo de infusão é um parâmetro de segurança — uma infusão que ultrapassa o tempo previsto pode indicar problema no acesso venoso, na bomba de infusão ou reação do paciente; a barra vermelha chama a atenção do médico sem que ele precise abrir o prontuário para checar. Quando a prescrição do procedimento não tem tempo de aplicação, não há como calcular o progresso: no lugar da barra o card mostra, discretamente, o texto “sem tempo previsto” (D-CM-034).
• RN-CM-023 — Critério de Não Adesão: Um paciente em tratamento conta como “não aderente” (KPI “Em Tratamento”, subtexto) quando o tratamento se desvia do planejado no protocolo em qualquer uma de três situações (lógica “OU” — basta uma delas para contar como não aderente): a primeira sessão do tratamento (C1D1) foi realizada em data diferente da planejada, além de uma margem de tolerância — checagem que só se aplica quando existe um plano terapêutico formal cadastrado para o mesmo protocolo, e é ignorada quando não existe, já que nem todo médico chega a criar um; uma sessão já esperada para uma data passada não foi de fato realizada; ou a data real de uma sessão diverge da data esperada para ela, sempre contada a partir do início do ciclo em que aquela sessão está — não do início do tratamento inteiro. Esse terceiro cálculo, diferente do primeiro, não depende de plano terapêutico — usa só as prescrições já realizadas do paciente — e aplica duas margens de tolerância diferentes: uma menor para o desvio de uma sessão dentro do próprio ciclo, e uma maior para o desvio do início de um ciclo em relação ao ciclo anterior (cada novo ciclo é conferido contra quando o ciclo anterior de fato começou, não contra uma data fixa). As margens de tolerância vêm do protocolo do paciente (critério e mapeamento de campos exatos: Seção 4.5).
• RN-CM-024 — Critério de Paciente em Tratamento: Um paciente conta para o número principal do KPI “Em Tratamento” quando teve agenda realizada ou prescrição registrada dentro de uma janela recente de atividade (padrão: 180 dias, cerca de 6 meses) — passado esse período sem nenhuma das duas, ele deixa de ser considerado em tratamento para fins deste indicador. Essa janela é um parâmetro configurável por clínica, não um valor fixo no sistema; quando a clínica não tem o parâmetro configurado, vale o padrão de 180 dias (mapeamento de banco: Seção 4.5).
• RN-CM-026 — Horário Exibido no Card, Conforme o Andamento: O card de um procedimento mostra um horário cujo sentido muda conforme o andamento — enquanto o procedimento não termina, é o horário em que o atendimento começou; a partir de Finalizado, passa a ser o horário em que o atendimento terminou, não mais o de início. Motivador: uma vez concluído o procedimento, o horário de término é a informação mais útil ao médico (ex.: saber há quanto tempo o paciente está liberado) — o de início deixa de ter relevância imediata.
• RN-CM-027 — Ordenação do Painel Pacientes em procedimento: A lista é ordenada cronologicamente pelo horário agendado do procedimento (Agenda.DhAgendaIniUTC) — não pelo horário exibido no card, que pode ser o de início real ou o de término conforme o andamento (RN-CM-026). Dois procedimentos agendados para o mesmo horário são desempatados em ordem alfabética pelo nome do paciente. Motivador: o horário agendado reflete a ordem de chegada esperada ao longo do turno — uma referência estável, que não muda quando um atendimento atrasa, adianta ou já foi concluído; o horário exibido no card serve para informar o médico, não para ordenar a lista.

Filtros e Estados Padrão dos Painéis

• RN-CM-021 — Filtro padrão restrito ao que exige ação agora: Os três painéis com botão de alternância (toggle) de filtro abrem, por padrão, mostrando só o que precisa de ação do médico agora — o panorama completo fica a um clique de distância, nunca escondido de vez:
  • Painel de Consultas: toggle “Pendentes/Todas”, default “Pendentes”. Consultas finalizadas não somem da lista ao alternar para “Todas” — aparecem esmaecidas, na posição cronológica original.
  • Painel Pacientes em procedimento: toggle “Meus/Todos”, default “Meus” (pacientes do médico logado).
  • Painel de Prescrições Pendentes: toggle “Meus/Todos”, default “Meus”. O toggle filtra as duas categorias (a assinar e a revisar) da mesma forma: “Meus” mostra só as prescrições em que o médico logado é o prescritor ou o médico assistente do paciente; “Todos” soma as prescrições de todos os médicos, nas clínicas em que o médico logado atende (RN-CM-032), nas duas categorias. Qualquer médico pode assinar uma prescrição, não só quem a prescreveu — na prática, isso costuma acontecer quando a aplicação está próxima e o prescritor não está disponível ou está ocupado com outro atendimento; não é uma questão de prioridade entre médicos, apenas de disponibilidade.

Atualização de Dados

• RN-CM-017 — Atualização Frequente: A Central deve ser um espelho confiável da realidade da clínica, sem que o médico precise recarregar a página manualmente. Os dados são atualizados automaticamente em segundo plano, em intervalos fixos (não é uma atualização instantânea a cada mudança — ver mecanismo técnico exato na Seção 2.9). O intervalo varia por painel, dividido em dois grupos conforme o quanto a próxima ação do médico depende da mudança de estado daquele painel:
  • Grupo de 1 minuto (esquerda): painel de Consultas e painel de Mensagens, e o KPI “Consultas Hoje”. Nestes, o estado muda com frequência e a ação seguinte do médico (chamar o próximo paciente, responder uma mensagem) depende diretamente dessa mudança — uma defasagem tem custo operacional imediato.
  • Grupo de 5 minutos (direita): painel de Prescrições Pendentes, painel Pacientes em procedimento, e os KPIs “Alertas de Prescrição” e “Procedimentos Hoje”. Nestes, o estado muda com frequência menor e depende mais de uma atualização de terceiros (farmácia, enfermagem) ou do próprio médico (assinar, revisar) do que de uma mudança contínua externa — alguns minutos de defasagem não comprometem a decisão do médico.
  • O KPI “Em Tratamento” não tem painel correspondente no grid (abre a tela “Pacientes do Médico”); por seguir o mesmo raciocínio do Grupo de 5 minutos — adesão ao protocolo muda em escala de dias/sessões, não de minuto a minuto — fica agrupado com ele. (Classificação proposta pelo Designer para este KPI especificamente, já que não há um painel correspondente para herdar a frequência — a confirmar.)
  • Falha na atualização: se uma atualização automática falha depois de a Central já ter carregado os dados (queda de conexão ou erro do servidor), os últimos dados continuam na tela e a Central avisa, numa faixa única, que está sem conexão e a que horas os dados foram atualizados pela última vez; o aviso some quando uma atualização volta a funcionar. É o aviso padrão do sistema (Design System, seção 7); detalhes na Seção 2.7.
• RN-CM-019 — Hierarquia visual sem negrito: A Central não utiliza negrito em nenhum elemento estrutural. A hierarquia visual é construída exclusivamente através de tamanho tipográfico, cor e espaçamento. Destaques importantes são feitos por contraste cromático (chips coloridos, borda lateral dos KPIs, número vermelho de alertas) e por tamanho de fonte. Motivador: o negrito deve ser economizado para destaques verdadeiramente importantes; informações estruturais devem orientar o olhar discretamente, não competindo com as informações clínicas que importam. (Valores exatos de peso e tamanho de fonte: Seção 2.8.)

Fluxo Principal (O Ciclo do Dia)

1. Início do Turno: O médico faz login e visualiza o panorama geral nos KPIs.
2. Triagem de Pendências: Antes do primeiro paciente, o médico assina as prescrições pendentes de assinatura e confirma a revisão das prescrições marcadas automaticamente como “a revisar” (aplicação agendada dentro da janela de revisão, padrão de 1 dia), priorizando as mais urgentes.
3. Atendimento: Ao identificar um paciente “Recepcionado” no painel de Consultas, o médico clica no nome para abrir o PEP e iniciar o atendimento.
4. Monitoramento: Entre consultas, o médico observa o painel Pacientes em procedimento para verificar se algum tratamento está atrasado ou finalizado.
5. Mensagens: O médico responde dúvidas rápidas da equipe via painel de Mensagens sem sair da tela principal.

Premissas

• A assinatura de prescrições pode exigir certificado digital ou não, dependendo da configuração do cliente. Se a clínica está configurada para assinatura com certificado digital, o médico que possuir certificado assina digitalmente; o médico que não possuir certificado deve imprimir e assinar fisicamente. Se a clínica não está configurada para certificado digital, a assinatura é validada apenas pela sessão do usuário logado.
• A resolução mínima de tela recomendada é de 1920x1080 (Full HD).
• [A DEFINIR — escopo desktop/mobile, estudo de uso pendente] RN-CM-001/002 (grid fixo de 4 quadrantes sem rolagem geral) e RN-CM-003 (dependente de toque/hover) presumem uso em desktop ou tablet, reforçado pela premissa acima de resolução mínima recomendada — mas não há, até esta versão, uma decisão de produto explícita de que a Central é desktop/tablet-only, o que tensiona com o mandato mobile-first do projeto. Avaliação de 28/08/2026: a necessidade de ver os 4 painéis sem rolar parece importante mesmo em telas menores, mas o uso em celular provavelmente seria pontual (tirar uma dúvida, consultar um paciente específico), não para gerenciar o turno inteiro. Hipótese do Designer para validar num estudo futuro, não uma decisão tomada: a Central (este cockpit) fica desktop/tablet-only, enquanto as telas de destino de cada painel (Agenda, Prontuário, Prescrições, Procedimentos) seguem mobile-first, já que são acessadas para consultas pontuais. Fica pendente de um estudo de uso mobile dedicado antes de confirmar como regra de negócio.

Dependências

Sistema/Módulo	Dependência	Impacto
Módulo de Agenda	Status da agenda	Sem isso, o painel de consultas não atualiza.
Módulo de Agenda	Data/hora da aplicação da prescrição	A marcação automática de “a revisar” (RN-CM-020) depende da data/hora de aplicação agendada na prescrição — sem essa informação, o sistema não consegue calcular a janela de revisão e disparar o estado de revisão.
Serviço de Assinatura	Integração com Certificadora	Necessário para a validade jurídica da assinatura (quando aplicável).
Recepcionista	Atualização de status na agenda	Define os status “Agendado” e “Recepcionado” no painel de Consultas.
Segurança (Check-in de Usuários)	Cliente do login e clínicas do cliente (Cliente, ClienteEmpresa); acesso do usuário às clínicas (RN-CIU-009); clínica escolhida na seleção de clínicas	O médico vê as clínicas do cliente em que atende (as que o usuário acessa; D-CM-067); os demais profissionais, só a clínica escolhida (RN-CM-032, D-CM-066). Quando o médico atende em mais de uma clínica, o nome da clínica aparece nos cards de consulta, prescrição, procedimento e mensagem.

Requisitos SBIS Aplicáveis

SBIS (Sociedade Brasileira de Informática em Saúde) certifica prontuários eletrônicos no Brasil; “ECF” é o prefixo de código usado pela planilha de requisitos dessa certificação (RequisitosSBIS-v5.2) para esta categoria de requisito. Requisitos aplicáveis a esta funcionalidade:

ID SBIS	Descrição Acessível	Implementação no Cockpit
ECF.03.11	Busca multifatorial de pacientes	Implementado na busca do cabeçalho (Nome, CPF, Mãe).
ECF.16.01	Listagem de pendências do profissional	Implementado no Painel de Prescrições Pendentes.
ECF.17.04	Registro de eventos em ordem cronológica	Aplicado na ordenação de Consultas; dentro de cada conversa, as mensagens seguem a ordem de envio. A lista de conversas passa a seguir a ordem de RN-CM-015 (não lidas primeiro; depois a data mais recente entre a última mensagem e o prazo; D-CM-087); a ordem anterior foi conferida contra o requisito (D-CM-051), e a Mensageria classifica a nova como atendimento parcial (lista em ordem de prioridade, não cronológica) — a confirmar (P-CM-057).

---

Histórico de Versões

• v6.0 (29/10/2026) — Abertura da versão 6.0 a pedido do solicitante: a série v5 foi fechada na v5.20, que foi para desenvolvimento, e fica em Histórico/ sem alterações. Esta versão é, por ora, cópia da v5.20: nenhuma mudança de regra, tela, contrato ou schema. As mudanças da v6 serão descritas para o time de desenvolvimento em Para Desenvolvedores/Central do Médico - mudanças da v6 - guia para desenvolvimento.md. Acompanha 01-Definição v6.0, 02-Especificação v6.0, 03-Protótipo v6.0, 04-Mapeamento v6.0, Cenários de Teste v6.0 e 05-Registro de Decisões v1.20.

• v5.20 (29/10/2026) — Acompanha as versões v5.20 dos demais documentos e 05-Registro de Decisões v1.19. Decisão D-CM-090: sem mudança de regra; cabeçalhos sincronizados.

• v5.19 (29/10/2026) — Acompanha 02-Especificação v5.19, 03-Protótipo v5.19, 04-Mapeamento v5.19, Cenários de Teste v5.19 e 05-Registro de Decisões v1.18. Decisões D-CM-088 e D-CM-089. RN-CM-015: grau de urgência, horário relativo e ordem pelo grau; o botão “Resolvido” sai do card (touchpoint “Ao resolver uma solicitação”).

• v5.18 (28/10/2026) — Acompanha 02-Especificação v5.18, 03-Protótipo v5.18, 04-Mapeamento v5.18, Cenários de Teste v5.18 e 05-Registro de Decisões v1.17. Decisões D-CM-086 e D-CM-087 (05 - Registro de Decisões v1.17). RN-CM-015: sem selo “Respondida” (a resposta aparece como última mensagem, com o autor); novo item de leitura pelos outros participantes (um visto: enviada; dois: lida); novo item de ordem (não lidas primeiro; depois a data mais recente entre a última mensagem e o prazo; empate pela conversa criada mais recentemente), a mesma regra da tela de Mensagens (D-CM-087). SBIS ECF.17.04: nova ordem a confirmar (P-CM-057).

• v5.17 (28/10/2026) — Acompanha 02-Especificação v5.17, 03-Protótipo v5.17, 04-Mapeamento v5.17, Cenários de Teste v5.17 e 05-Registro de Decisões v1.16. Decisões D-CM-084 e D-CM-085 (05 - Registro de Decisões v1.16). Sem mudança de regra de negócio: nome “Aguardando recepção”, como cadastrado em TermoTraducao (antes “Aguardando Recepção”; D-CM-084); botões da tela alinhados ao Design System (assunto da Especificação).

• v5.16 (27/10/2026) — Acompanha 02-Especificação v5.16, 03-Protótipo v5.16, 04-Mapeamento v5.16, Cenários de Teste v5.16 e 05-Registro de Decisões v1.15. Decisões D-CM-077 a D-CM-083 (05 - Registro de Decisões v1.15). Sem mudança de regra de negócio: nomes de status como cadastrados em TermoTraducao — “Em atendimento”, “Em preparo” e “Em aplicação” (antes “Em Atendimento”, “Preparo” e “Em administração”; D-CM-082); menções de proveniência de decisões (“solicitante”) retiradas do corpo, que passam a existir só aqui e no Registro de Decisões (D-CM-083).

• v5.15 (27/10/2026) — Acompanha 02-Especificação v5.15, 03-Protótipo v5.15, 04-Mapeamento v5.15, Cenários de Teste v5.15 e 05-Registro de Decisões v1.14. Decisões D-CM-073 a D-CM-076 (05 - Registro de Decisões v1.14). Sem mudança de regra de negócio: cores e nome do status passam a vir da API (DT-016), o status “Completo” do procedimento tem valor de contrato administered e o card de procedimento cancelado fica com os textos riscados — assuntos dos documentos técnicos.

• v5.14 (26/10/2026) — Acompanha 02-Especificação v5.14, 03-Protótipo v5.14, 04-Mapeamento v5.14, Cenários de Teste v5.14 e 05-Registro de Decisões v1.13. Decisões em 05 - Registro de Decisões v1.13 (D-CM-070 a D-CM-072). RN-CM-032 corrigida (D-CM-070): quem perde o acesso a uma clínica deixa de ver as agendas e as prescrições dela, mas não perde o acesso aos pacientes; “Em Tratamento”, adesão ao protocolo e busca de pacientes seguem sem filtro por clínica, e Paciente.IdChClinica não afeta o médico (será filtro do administrativo e de outras funções). A frase de D-CM-068 (v5.13) “e os pacientes dela” não vale mais. Sai a questão P-CM-053. Nome do campo de SegEmpresa: SegurancaClienteEmpresaId, o do DDL (D-CM-071; sai a questão P-CM-050). Sem mudança de tela, de contrato ou de SQL.

• v5.13 (26/10/2026) — Acompanha 02-Especificação v5.13, 03-Protótipo v5.13, 04-Mapeamento v5.13, Cenários de Teste v5.13 e 05-Registro de Decisões v1.12. Decisões em 05 - Registro de Decisões v1.12 (D-CM-067 a D-CM-069). RN-CM-032: a escolha E-CM-034 vira decisão (D-CM-067): “atende” = a clínica do cliente a que o usuário tem acesso. Nova regra de perda de acesso (D-CM-068): quem perde o acesso a uma clínica deixa de ver as agendas dela e os pacientes dela; a Agenda do Médico ganha filtro explícito (nova versão da Agenda). Fica em aberto como isso vale para o que é medido por paciente (P-CM-053).

• v5.12 (26/10/2026) — Acompanha 02-Especificação v5.12, 03-Protótipo v5.12, 04-Mapeamento v5.12, Cenários de Teste v5.12 e 05-Registro de Decisões v1.11. Decisão em 05 - Registro de Decisões v1.11 (D-CM-066). Resposta do solicitante ao item (d) de P-CM-049: nas duas telas (Central e Agenda do Médico) o médico vê só as clínicas em que atende (“não faz sentido mostrar pacientes de uma clínica que ele não atende, pois ele não pode fazer nada por ela”). RN-CM-032 reescrita: sai o escopo “todas as clínicas do cliente” (D-CM-050, D-CM-060); a condição de mostrar o nome da clínica passa a ser “o médico atende em mais de uma clínica”, igual à da Agenda (RN-AGM-017, a); o toggle “Todos” e os indicadores seguem o mesmo escopo; linha do toggle (Fluxo) e dependência de Segurança ajustadas. Como o sistema sabe onde o médico atende é a escolha E-CM-034 (as clínicas a que o usuário tem acesso, como na Agenda), a confirmar. A Agenda do Médico não muda de versão.

• v5.11 (26/10/2026) — Acompanha 02-Especificação v5.11, 03-Protótipo v5.11, 04-Mapeamento v5.11, Cenários de Teste v5.11 e 05-Registro de Decisões v1.10. Decisões em 05 - Registro de Decisões v1.10 (D-CM-061 a D-CM-065). (1) RN-CM-032: o “hoje”, o fim do dia das janelas de prescrição e os horários seguem o fuso da clínica em que o usuário está logado (D-CM-062; substitui a proposta E-CM-031 de usar o fuso da clínica da prescrição). (2) RN-CM-032: o card de mensagem também mostra a clínica (D-CM-064) e o card de procedimento, por D-CM-061. (3) O rótulo do indicador de alertas e o “Em Tratamento” usam os parâmetros da clínica logada (D-CM-063). (4) RN-CM-020: o fuso das duas janelas passa a ser o da clínica logada. (5) Padronizada a grafia dos rótulos “p/revisar” e “p/assinar”, como na tabela de textos da Especificação. (6) Sai o “em aberto” de P-CM-048; resta P-CM-049 (alinhar a Agenda do Médico).

• v5.10 (26/10/2026) — Acompanha 02-Especificação v5.10, 03-Protótipo v5.10, 04-Mapeamento v5.10, Cenários de Teste v5.10 e 05-Registro de Decisões v1.9. Decisões em 05 - Registro de Decisões v1.9 (D-CM-055 a D-CM-060). (1) RN-CM-032 reescrita como escopo do cliente: o médico vê as agendas, as prescrições e as mensagens de todas as clínicas do cliente (exceção do sistema, só para médicos; os demais profissionais ficam na clínica escolhida), e o nome da clínica aparece quando o cliente tem mais de uma (D-CM-060). (2) RN-CM-020: as janelas de “a assinar” e “a revisar” seguem a clínica da prescrição (D-CM-060); a assinatura que dispensou a revisão e perdeu o efeito leva a prescrição só a “a revisar”, sem nova assinatura (D-CM-059, resolve P-CM-047). (3) Tabela de dependências (Segurança) ajustada. Em aberto: P-CM-048.

• v5.9 (26/10/2026) — Acompanha 02-Especificação v5.9, 03-Protótipo v5.9, 04-Mapeamento v5.9, Cenários de Teste v5.9 e 05-Registro de Decisões v1.8. Decisões em 05 - Registro de Decisões v1.8 (D-CM-047 a D-CM-054). (1) RN-CM-011: o desempate das prescrições passa a ser pelo nome do paciente (D-CM-047; E-CM-027). (2) Nova RN-CM-032: consultas e prescrições de todas as clínicas do cliente, com o nome da clínica no card só quando o médico acessa mais de uma (D-CM-050; E-CM-028, E-CM-029); parâmetros por clínica em aberto (P-CM-046). (3) RN-CM-020: a nova versão de uma prescrição editada nasce sem assinaturas e entre as versões só uma é válida; a assinatura que dispensou a revisão perde o efeito se a aplicação for adiada (D-CM-050, D-CM-052; P-CM-047). (4) ECF.17.04 conferido para as mensagens (D-CM-051). (5) Fluxo de consulta: o selo “Atrasado” é leve (D-CM-054; E-CM-026).

• v5.8 (26/10/2026) — Acompanha 02-Especificação v5.8, 03-Protótipo v5.8, 04-Mapeamento v5.8, Cenários de Teste v5.8 e 05-Registro de Decisões v1.7. Decisão em 05 - Registro de Decisões v1.7 (D-CM-046). Sem mudança de regra de negócio nem de conteúdo deste documento: a versão ajusta só detalhes visuais da Especificação (anel de foco de 2px e chips de urgência mais leves). O chip vermelho/laranja citado nos fluxos é o mesmo, em versão mais leve.

• v5.7 (21/10/2026) — Acompanha 02-Especificação v5.7, 03-Protótipo v5.7, 04-Mapeamento v5.7, Cenários de Teste v5.7 e 05-Registro de Decisões v1.6. Decisão em 05 - Registro de Decisões v1.6 (D-CM-045). Sem mudança de regra de negócio: a versão ajusta só detalhes visuais da Especificação (cor do destaque de conversa não lida e tamanho do percentual da barra).

• v5.6 (21/10/2026) — Acompanha 02-Especificação v5.6, 03-Protótipo v5.6, 04-Mapeamento v5.6, Cenários de Teste v5.6 e 05-Registro de Decisões v1.5. Decisão em 05 - Registro de Decisões v1.5 (D-CM-044, decisões transversais DT-011 e DT-012). Sem mudança de regra de negócio nesta seção: idioma e tradução dos textos ficam nos documentos técnicos.

• v5.5 (14/10/2026) — Acompanha 02-Especificação v5.5, 03-Protótipo v5.5 e 04-Mapeamento v5.5. Decisão em 05 - Registro de Decisões v1.4 (D-CM-043). Sem mudança de regra de negócio: a versão alinha a Central ao Design System de 14/10/2026 (cores), assunto só dos documentos técnicos.

• v5.4 (13/10/2026) — Acompanha 02-Especificação v5.4, 03-Protótipo v5.4 e 04-Mapeamento v5.4. Decisões em 05 - Registro de Decisões v1.3 (D-CM-027 a D-CM-042, E-CM-018 a E-CM-021). (1) RN-CM-020: as duas janelas (“a assinar”, 7 dias; “a revisar”, 1 dia) são em dias de calendário (D-CM-037); assinatura feita depois de a janela de revisão abrir dispensa a revisão (D-CM-040, E-CM-019); prescrição com administração iniciada sai de “a revisar” (D-CM-039, E-CM-018); a vencida sem desfecho indica falha de processo da Recepção (D-CM-033). (2) RN-CM-011: formato do atraso em minutos, horas e minutos e dias, e do restante abaixo de 1 hora em minutos (D-CM-041, E-CM-020). (3) RN-CM-015: confirmação antes de resolver ou descartar (D-CM-032). (4) RN-CM-016: texto “sem tempo previsto” no lugar da barra (D-CM-034). (5) RN-CM-028: ícone sem foco de teclado aceito (D-CM-035). (6) Painel Pacientes em procedimento: item do Menu Lateral para a tela exclusiva (D-CM-031). (7) Escopo: a busca não cita prontuário (D-CM-036). (8) Revisão por Dois Críticos: RN-CM-020 deixa de prometer um bloqueio que a Central não faz e de chamar a revisão de “independente” quando a assinatura a dispensa; RN-CM-011 passa a registrar a ordenação e o desempate (E-CM-022); resíduos de “um clique” removidos.

• v5.3 (10/10/2026) — Acompanha 02-Especificação v5.3, 03-Protótipo v5.3 e 04-Mapeamento v5.3. Decisões em 05 - Registro de Decisões v1.2 (D-CM-017 a D-CM-026, E-CM-016 e E-CM-017). Revisão por Dois Críticos (técnico e negócio/UX) antes de fechar: ver o Histórico do Registro. (1) RN-CM-031 nova: consulta em atendimento além do previsto ganha destaque com o tempo decorrido (D-CM-017). (2) RN-CM-020: a janela de “a revisar” é em dias de calendário no fuso da clínica — com N = 1 e hoje dia 10, entram os dias 10 e 11 até 23:59, mais as vencidas (D-CM-023). (3) RN-CM-011: a prescrição vencida mostra o atraso (“2h atrasada”) no lugar do tempo restante (E-CM-016); vencida sem desfecho fica na lista (D-CM-024). (4) RN-CM-025: vigência de tag comparada só pela data, com início e fim inclusivos (D-CM-021); ordem dos chips (D-CM-022). (5) O painel passa a se chamar “Pacientes em procedimento” (D-CM-019); o indicador da barra continua “Procedimentos Hoje”. (6) Fluxo do dia: “1 dia” deixa de ser 24h.

• v5.2 (09/10/2026) — Acompanha 02-Especificação v5.2, 03-Protótipo v5.2 e 04-Mapeamento v5.2. Decisões em 05 - Registro de Decisões v1.1. Revisão por Dois Críticos (técnico e negócio/UX) antes de fechar: achados aplicados; os que dependem do solicitante estão em P-CM-019 a P-CM-027. (1) RN-CM-020: o padrão da janela de “a revisar” é 1 dia (D-CM-006 corrigida); a janela não tem limite para trás e a Precedência 1 também inclui aplicações já vencidas; a prescrição vencida segue na lista até ser assinada ou revisada (D-CM-013). (2) RN-CM-011: a vencida mantém tempo negativo e chip vermelho e conta como urgente. (3) RN-CM-016: o progresso usa o tempo de aplicação da prescrição (D-CM-015). (4) RN-CM-015: sem “desfazer” (D-CM-014). (5) RN-CM-028: a dica do ícone abre ao toque e ao mouse (D-CM-016). (6) Resíduos de “2 dias” removidos do fluxo e de RN-CM-002; “assinatura recente” trocada por “assinada e revisada”. Texto técnico anterior a esta versão, em partes do corpo, não foi refatorado.

• v5.1 (09/10/2026) — Acompanha 02-Especificação v5.1 e 04-Mapeamento v5.1; abre o 05 - Registro de Decisões, que passa a concentrar as decisões do solicitante (códigos D-CM-xxx abaixo). Aplicadas: o painel inferior direito passa a se chamar “Procedimentos hoje” (D-CM-005; o termo mudou em todo o corpo); RN-CM-028 passa de tag/chip “1ª Consulta” a ícone (D-CM-003); RN-CM-020: a janela de “a revisar” passa de 1 dia a 2 dias, parâmetro NumeroDiasRevisaoPrescricoes do sistema atual (D-CM-006); a conversa resolvida ou descartada sai do painel de todos os destinatários (D-CM-011). Sem mudança de texto, só registradas: a Central não diferencia “Esperando” de “Não chegou” (D-CM-004); “Atrasadas” não conta consultas em atendimento (D-CM-008). Revisão por Dois Críticos (09/10/2026): crítico técnico e crítico de negócio/UX sobre o pacote v5.1; o Designer conferiu cada achado contra os arquivos antes de aplicar. Aplicado: o indicador “Consultas Hoje” passa a dizer que “atrasadas” são as consultas não iniciadas com horário vencido (consistente com D-CM-008). Pontos de UX sem decisão do solicitante ficaram em aberto no 05 - Registro de Decisões (P-CM-010 a P-CM-016).

• v5.0 (08/10/2026) — Abertura da versão 5.0 a pedido do solicitante (“fechamos esta versão da central do médico… Pode ajustar todos os pontos pendentes derivadas das outras funcionalidades que estamos desenvolvendo”). Ajustes vindos da Agenda do Médico (Definição v1.15), do Design System e do Log de Mudanças Estruturais do Banco de Dados: (1) RN-CM-030: o bloqueio de horário passa a ser o feito pela Recepção (Agenda do Médico, RN-AGM-019); a v4.42 citava o bloqueio feito pelo médico (RN-AGM-004, retirada da Agenda) e a regra RN-AGM-011, e remetia a um mecanismo a detalhar na Agenda. O efeito na Central não muda: o bloqueio continua fora do painel e de todas as contagens. (2) RN-CM-025: as tags atribuídas no prontuário entram, além das atribuídas no cadastro do paciente — mesmo critério da Agenda do Médico (RN-AGM-006), com a vigência do registro de prontuário; a tag VIP é atribuída no cadastro (ProgramaApoioPaciente), seguindo a decisão do solicitante na Agenda do Médico (“desconsidere o campo Paciente.PacienteVip, por enquanto”), e deixa de ser descrita como “não vinda do cadastro de tags”. (3) RN-CM-017: nova regra de falha na atualização — faixa única de “sem conexão” com o horário da última atualização, padrão do sistema (Design System, seção 7, de 07/10/2026), no lugar do ícone “Offline” em cada painel (aplicação na Especificação 2.7). Levados ao solicitante, sem mudança nesta versão: representação da tag “1ª Consulta” por ícone (como na Agenda, RN-CM-028); distinção “Esperando”/“Não chegou” no sinalizador de atraso (RN-AGM-009); nomes “Pacientes na Clínica Hoje” (Menu Lateral) × “Procedimentos na Clínica” (painel); divergências com o legado (NumeroDiasRevisaoPrescricoes × PrescricaoTempoRevisao).

• v4.42 (29/09/2026) — Alinhamento com a Agenda do Médico (01-Definição v1.6), aprovado pelo solicitante: nova RN-CM-030 — horários bloqueados pelo médico na Agenda do Médico não aparecem no painel de Consultas nem contam no indicador “Consultas Hoje” ou em qualquer outra contagem de agendas/pacientes. Motivo: o solicitante decidiu que bloqueios ficam fora das contagens de agendas e de pacientes (Agenda do Médico, RN-AGM-011); como o registro de bloqueio é gravado como agenda de consulta (TipoAgenda = 'C', default decidido pelo solicitante), o filtro atual do painel e do KPI (TipoAgenda = 'C') o incluiria — achado da revisão de alinhamento entre os dois documentos. Acompanha 02-Especificação v4.37, 03-Protótipo v3.19 e 04-Mapeamento de BD v4.48. Também corrigido o texto de RN-CM-025, que ainda dizia que as tags exibidas são as habilitadas “para exibição na Central do Médico” — o filtro vigente, desde a v4.37 do Mapeamento de BD, é o de agendas (bit 32), não o da Central (bit 8); achado do crítico de negócio da Agenda do Médico, conferido contra a Seção 4.1 antes de corrigir. Cenários de Teste v1.20 não atualizado nesta rodada (ver Histórico da Especificação v4.37). Revisão por Dois Críticos: incluída na rodada da Agenda do Médico (ver Histórico daquele documento).

• v4.41 (29/09/2026) — Esclarecimento do solicitante sobre RN-CM-029: Prescricao.IdChProfissionalAssinou e Prescricao.DataAssinaturaPrescricao não são duas fontes legadas independentes — formam um par, o mesmo evento de assinatura (um registra quem assinou, o outro quando). Isso fecha, com resposta definitiva, a ambiguidade [A DEFINIR] aberta desde a v4.28 do Mapeamento de Banco de Dados sobre IdChProfissionalAssinou “sem data própria” — a data sempre existiu, é DataAssinaturaPrescricao. Sem efeito prático nesta versão (não há mais cálculo de idade/vencimento de assinatura desde a v4.39), mas a relação correta entre os dois campos passa a estar documentada. Mapeamento técnico completo: 04-Mapeamento de BD v4.47 (Seção 4.6). Revisão por Dois Críticos: não aplicável — esclarecimento factual direto do solicitante.

• v4.40 (29/09/2026) — Correção do solicitante sobre um ponto que a v4.39 tinha deixado mal documentado: RN-CM-021 (Painel de Prescrições Pendentes) afirmava que “as prescrições a assinar são sempre do médico logado (RN-CM-012)” — errado; qualquer médico pode assinar uma prescrição, não só quem a prescreveu. Na prática, isso costuma acontecer quando a aplicação está próxima e o prescritor não está disponível ou está ocupado com outro atendimento — não é uma questão de prioridade entre médicos, apenas de disponibilidade. O toggle “Meus/Todos” passa a filtrar as duas categorias (a assinar e a revisar) da mesma forma: “Meus” = médico logado é prescritor ou assistente do paciente; “Todos” = toda a clínica, nas duas categorias. A citação a RN-CM-012 nunca fez sentido para essa restrição — essa regra trata do modo de assinatura (certificado ou sessão), não de quem pode assinar. Mapeamento técnico completo: 04-Mapeamento de BD v4.46 (Seções 4.6/4.7). Sem impacto em RN-CM-012 em si (não muda). Revisão por Dois Críticos: não aplicável — correção pontual a partir de esclarecimento direto do solicitante, não interpretação nova.

• v4.39 (28/09/2026) — Pedido do solicitante: simplificação grande de RN-CM-020, abolindo o conceito de “assinatura vencida” introduzido na v4.36. Nova regra, 2 precedências sem expiração: (1) “a assinar” = nunca assinada + aplicação nos próximos 7 dias, agora um parâmetro por clínica (PrescricaoTempoRevisao já existia; novo parâmetro PrescricaoTempoAssinatura [PROPOSTA], mapeamento completo em 04-Mapeamento de BD v4.45) — antes esses 7 dias eram um corte só de implementação (Seção 4.6/4.7), não uma regra de negócio nem um parâmetro; (2) “a revisar” = assinada (qualquer época) + sem confirmação de revisão (TipoAssinatura = 'R') + aplicação a 1 dia ou menos (PrescricaoTempoRevisao, sem mudança). O parâmetro PrescricaoValidadeAssinatura (criado na v4.30, nunca aplicado em produção — [PROPOSTA] em todo cliente) é retirado por este documento, sem custo de migração. RN-CM-029 simplificada: as 2 fontes legadas de assinatura deixam de precisar de uma data para calcular idade (não há mais vencimento a calcular), resolvendo por tabela a ambiguidade [A DEFINIR] aberta desde a v4.28 do Mapeamento sobre IdChProfissionalAssinou sem data própria. Novo filtro de Prescricao.Situacao, também pedido pelo solicitante nesta rodada: só prescrições em P/G/A/O entram nas duas listas — motivado por um achado ao conferir a regra contra CargaCMZero.xlsx: sem filtro de situação, e sem o mecanismo de expiração para “limpar” o histórico, quase toda prescrição já assinada desde dez/2025 apareceria em “a revisar” para sempre (nenhum registro TipoAssinatura = 'R' existe na massa hoje); com o filtro, apenas prescrições ainda “em andamento” (não finalizadas/faturadas/externas/canceladas) contam — ver quantificação completa nos Cenários de Teste v1.19. Precedente: entre 25-27/09/2026, uma simplificação semelhante (2 estados sem validade) já havia sido tentada e revertida a pedido do próprio solicitante (“me precipitei” — ver Histórico/Cenários de Teste v1.10 - REVERTIDA); confirmado explicitamente com o solicitante nesta rodada que o pedido atual, mais específico (parâmetros nomeados, filtro de situação, janela de 7 dias explícita), é deliberado, não repetição do episódio anterior. Acompanha 02-Especificação v4.35, 04-Mapeamento de BD v4.45 e Cenários de Teste v1.19 (03-Protótipo sem mudança de conteúdo — apenas sincronização de cabeçalho). Revisão por Dois Críticos (crítico de negócio): 6 correções — (1) contradição em RN-CM-029 com texto obsoleto remanescente da versão de validade, removido; (2) jargão de proveniência de processo (“a pedido do solicitante”, “confirmada pelo solicitante”) reintroduzido no corpo de RN-CM-020, movido para este Histórico; (3) descrição da persona Enfermagem/Farmácia desatualizada (“assinatura válida como revisão recente”), reescrita; (4) códigos de banco (P/G/A/O/Q/F/E/C) expostos na Seção 1, reescritos em linguagem de negócio; (5) trade-off da simplificação (itens que somem das duas listas sem mecanismo de expiração) tornado explícito no corpo da regra; (6) frase de RN-CM-002 sobre o quadrante de pendências completada com “já assinadas”.

• (sincronização, 28/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Especificação v4.34 e Protótipo v3.18 (mensagem de estado vazio dividida por estado do toggle nos painéis de Prescrições Pendentes e Procedimentos na Clínica — ver Histórico desses dois documentos).

• (sincronização, 28/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Mapeamento de Banco de Dados v4.44 (contexto do solicitante incorporado ao achado em aberto sobre Paciente.PacienteVip — ver Histórico desse documento).

• (sincronização, 28/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Especificação v4.33 (mensagem de estado vazio do Painel de Consultas dividida por estado do toggle), Protótipo v3.17 (mesma correção + cor real da tag VIP) e Mapeamento de Banco de Dados v4.43 (correção da suposição sobre a origem da cor de VIP) — ver Histórico desses três documentos.

• v4.38 (28/09/2026) — Decisões do solicitante sobre os achados da v4.37: (1) o valor correto da janela de atividade de RN-CM-024 é 180 dias — o seed com 120 dias em Infra-estrutura/(BD-M) Dados incluídos obrigatórios.md estava errado e foi corrigido lá (cópia anterior arquivada em Infra-estrutura/Histórico/); (2) RN-CM-024 passa a dizer explicitamente que o padrão de 180 dias vale quando a clínica não tem o parâmetro configurado. A janela de revisão de RN-CM-020 (1 dia) foi confirmada como contínua (24 horas antes da aplicação), não por dia de calendário — já descrita assim no Mapeamento de BD, sem mudança de texto nesta Seção.

• v4.37 (28/09/2026) — Pedido do solicitante: os parâmetros de janela de tempo de RN-CM-020 e RN-CM-024 passam a ser expressos em dias. (1) RN-CM-020: a janela de antecedência de revisão (PrescricaoTempoRevisao) deixa de ser descrita como “24h” e passa a ser “1 dia” (valor-padrão), em dias; a frase sobre prescrições fora da janela deixa de citar “24h”. (2) RN-CM-024: o valor-padrão da janela de atividade passa a ser expresso em dias — “180 dias, cerca de 6 meses” (180 é o valor que o exemplo de query do Mapeamento de BD já usava para “6 meses”). Achado registrado para decisão do solicitante, sem alteração nesta versão: o script de seed em Infra-estrutura/(BD-M) Dados incluídos obrigatórios.md grava 120 dias (não 180) para TempoPacienteAtivoAgenda/TempoPacienteAtivoPrescricao nas clínicas 24 e 3521. Limiares dos chips de urgência (12h/24h, RN-CM-011) não mudam — continuam em horas e fixos.

• (sincronização, 28/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Especificação v4.31 (janela de antecedência de revisão de RN-CM-020 descrita como parâmetro por clínica, PrescricaoTempoRevisao, em vez de 24h fixo).

• v4.36 (28/09/2026) — Regra de precedência assinar/revisar de RN-CM-020 reescrita com mais precisão, a pedido do solicitante, corrigindo uma rodada anterior (25-27/09/2026) que havia sido revertida por ser precipitada — aquela rodada simplificou a regra para só 2 estados, eliminando por completo a janela de validade de 7 dias; o solicitante apontou que isso estava errado e formalizou a regra correta, com 2 níveis de precedência claros: (1) “a assinar” — nunca assinada, OU assinada mas com a assinatura vencida (mais de 7 dias, PrescricaoValidadeAssinatura) — uma assinatura vencida sempre volta para “a assinar”, mesmo com a aplicação próxima; (2) “a revisar” — só avaliada quando a prescrição já está assinada e dentro da validade: aplicação a 24h ou menos E nenhuma confirmação de revisão (“Marcar como Revisada”) também dentro da janela de validade de 7 dias. Formalizado que uma confirmação de revisão gera seu próprio registro de assinatura (tipo “revisão”, já suportado pelo esquema — PrescricaoAssinatura.TipoAssinatura = 'R', mapeamento completo na Seção 4.6/4.7 do Mapeamento de Banco de Dados), e que essa confirmação também vence após 7 dias, pelo mesmo parâmetro — antes desta versão, o mecanismo de “revisão” era descrito de forma vaga (“assinatura original ou de revisão”), sem separar claramente a idade da assinatura original (que rege a Precedência 1) da idade de uma eventual confirmação de revisão (que rege a Precedência 2). Nova RN-CM-029, formalizando que o campo legado Prescricao.DataAssinaturaPrescricao também conta como assinatura para efeito da Precedência 1, prevalecendo sobre o registro em PrescricaoAssinatura quando for o mais recente dos dois — achado original do solicitante ao investigar a prescrição 70 (Beatriz A. Lima), confirmado nesta rodada como regra geral, não um caso isolado. Registrado como [A DEFINIR] que o outro campo legado, Prescricao.IdChProfissionalAssinou, não tem data própria e por isso não pode ter sua validade calculada — tratado por ora como assinatura sem vencimento, sem confirmação do solicitante em contrário. Verificado contra a massa real (CargaCMZero.xlsx, data-base 24/09/2026 12:00): das prescrições rastreadas em Cenários de Teste, só a 70 muda de classificação sob a regra corrigida (sai de “a assinar” — sua assinatura mais recente, via RN-CM-029, está dentro da validade, mas a aplicação está a mais de 24h de distância, então não entra em “a revisar” também); as prescrições 43, 68 e 69, inicialmente suspeitas de mudar de classificação numa rodada anterior, permanecem “a assinar” — a assinatura mais recente de cada uma (por qualquer das fontes de RN-CM-029) já está vencida. Detalhamento completo da verificação: Cenários de Teste v1.10. Revisão por Dois Críticos (crítico de negócio): nenhuma correção necessária — a regra evita o erro da rodada revertida (eliminar por completo a janela de validade) ao mesmo tempo em que fecha a lacuna original (compatibilidade legada da data de assinatura).

• v4.35 (25/09/2026) — Pedido do solicitante, durante a validação de Cenários de Teste v1.8: duas regras novas. (1) RN-CM-027 — Ordenação do Painel de Procedimentos (2.6): a Especificação não definia critério de ordenação para este painel (diferente de Consultas/RN-CM-006 e Prescrições/RN-CM-011); o solicitante informou a regra (cronológica pelo horário agendado da agenda, desempate alfabético pelo nome do paciente) — verificada contra a massa de referência (CargaCMZero.xlsx, campo Agenda.DhAgendaIniUTC) e contra a ordem já documentada em Cenários de Teste v1.0: reproduz exatamente a ordem observada, inclusive o empate Roberto N. Alves/Rogério M. Santos (ambos 09:00, desempatado por “Roberto” < “Rogério”). (2) RN-CM-028 — Tag “1ª Consulta”: até esta versão, a tag aparecia como exemplo em RN-CM-025 (Tags de Atenção) sem nota de que sua origem (Agenda.PrimeiraConsulta = 'S') é distinta do cadastro ProgramaApoio que rege as demais tags — RN-CM-025 ajustada para remover o exemplo indevido e apontar para a nova regra. Revisão por Dois Críticos (crítico técnico): não aplicável (fechamento de lacunas já sinalizadas em Cenários de Teste, sem mudança de comportamento além de formalizar regras já em vigor na massa de referência).

• (sincronização, 24/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Especificação v4.29 (confirmação do critério de desempate das conversas lidas no painel de Mensagens — ver Histórico desse documento).

• (sincronização, 24/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Mapeamento de Banco de Dados v4.39 (esclarecimento do solicitante sobre DhAtendimentoIniUTC vs. DhInfusaoIniUTC no campo startTime — ver Histórico desse documento).

• v4.34 (23/09/2026) — Pergunta do solicitante sobre o painel de Procedimentos na Clínica (“nos casos Finalizados, há alguma documentação sobre manter esse horário ou alterá-lo?”) revelou outra lacuna: nenhum documento dizia o que exibir quando o procedimento termina — o horário de início continuava sendo mostrado por efeito colateral da fórmula técnica, sem nenhuma regra de negócio por trás disso. Duas alternativas foram oferecidas como invenção explícita (manter o de início vs. trocar para o de término); confirmado trocar para o de término. Nova RN-CM-026, na seção “Procedimentos na Clínica (Monitoramento)”, ao lado de RN-CM-016/023/024. Mapeamento técnico completo (incluindo o comentário sobre o campo continuar se chamando startTime mesmo passando a carregar um horário de término) na Seção 4.3 do Mapeamento de Banco de Dados (v4.38). Revisão por Dois Críticos (crítico de negócio): nenhuma correção necessária.

• v4.33 (23/09/2026) — Pergunta do solicitante (“para quando o tempo restante é maior que 24h tem badge?”) revelou uma lacuna real em RN-CM-011: a regra só definia os alertas de vermelho (<12h) e laranja (12-24h) — nada dizia o que exibir a partir de 24h, apesar de o painel poder legitimamente mostrar prescrições pendentes de assinatura com bem mais de 24h de antecedência (até 7 dias, Seção 4.7). Duas alternativas foram oferecidas ao solicitante, explicitamente marcadas como invenção (nenhuma estava documentada antes): (a) sem alerta algum a partir de 24h, ou (b) alerta neutro (cinza) nesse caso. Confirmada a opção (a). RN-CM-011 reescrita para cobrir esse terceiro caso, em linguagem de negócio, sem nomes de campo/classe CSS (Lição #20) — mapeamento de apresentação completo na Especificação (Seção 2.4, v4.27) e no Protótipo (v3.15); nenhuma mudança em Seção 4 (a lógica é só de apresentação sobre o campo hoursRemaining, que já existia — não há campo, query ou tabela nova). Revisão por Dois Críticos (crítico de negócio): nenhuma correção necessária — o texto deixa claro que a prescrição continua na lista mesmo sem alerta, evitando a leitura errada de que ela “sumiria” ou seria escondida.

• (sincronização, 23/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Mapeamento de Banco de Dados v4.37 (correção do bit de MostrarEm usado pelos painéis de Consultas/Procedimentos — de “Central do Médico” para “Agendas” — ver Histórico desse documento).

• (sincronização, 23/09/2026) — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho “Documentos desta funcionalidade” atualizada para apontar Mapeamento de Banco de Dados v4.36 (convenção de borda de ProgramaApoio.DataFim harmonizada para inclusiva — ver Histórico desse documento).

• v4.32 (22/09/2026) — Pedido do solicitante, complementando a v4.31 no mesmo tema: RN-CM-025 ganhou um segundo critério de exibição — a própria tag (não a atribuição dela a um paciente) pode ter um período de vigência opcional; quando definido, só é exibida dentro dele. Deixado explícito que isso é distinto do período de atribuição ao paciente, que já existia e já era considerado. Sem nomes de campo nem regra de comparação de datas no corpo (Lição #20) — mapeamento completo, incluindo a diferença de convenção de borda entre os dois períodos, na Seção 4.1 do Mapeamento de Banco de Dados (v4.35). Revisão por Dois Críticos (crítico de negócio): nenhuma correção necessária.

• v4.31 (22/09/2026) — Pedido do solicitante: documentado o critério de exibição de Tags de Atenção (RN-CM-025), que até esta versão descrevia apenas onde as tags aparecem no Cockpit, sem mencionar que a exibição é condicional. Regra reescrita para deixar explícito que só entram nos cards as tags habilitadas, na definição de cada tag, para a tela da Central do Médico — mesmo princípio já usado (mas nunca aplicado de fato nesta funcionalidade) pela Agenda do Médico, RN-AGM-006. Comportamento antes só documentado (a consulta de tags não aplicava esse filtro) e agora também implementado — mapeamento completo do filtro e do domínio técnico por trás dele (ProgramaApoio.MostrarEm, mapa de bits compartilhado com outras funcionalidades) na Seção 4.1 do Mapeamento de Banco de Dados (v4.34). Sem mudança de campo/tabela nesta seção — mudança é de regra de negócio (agora a exibição é filtrada) e de leitura (fica dito explicitamente). Rótulo do bit 5 do domínio (valor 16) registrado com os dois termos informados pelo solicitante nesta rodada — “Confirmação de quimio” e “Central de atendimento” — sem decidir qual é o nome oficial da tela; ver nota completa na Seção 4.1. Revisão por Dois Críticos (crítico de negócio, Skill Designer) sobre a nova redação de RN-CM-025: nenhuma correção necessária — texto sem nomes de campo/tabela nem aritmética de bits, com o motivo de uma tag não aparecer (não habilitada para esta tela) e a exceção vip explícitos para um leitor não técnico.

• v4.30 (16/09/2026) — Quarto ajuste de RN-CM-023, em paralelo com a Seção 4.5 do Mapeamento (v4.33): o solicitante esclareceu como o valor de “sessão” de cada prescrição é definido na criação (aponta para um dia específico dentro do CICLO, reiniciando a cada ciclo — não é uma contagem cumulativa desde o início do tratamento). Isso mudou a terceira condição: a data esperada de uma sessão passa a ser contada a partir do início do CICLO em que ela está, não do início do tratamento inteiro; e a margem de tolerância “maior” (antes descrita como “desvios que atravessam um ciclo diferente”) passa a ser especificamente sobre quando um novo ciclo começa, comparado a quando o ciclo anterior de fato começou. Mudança de precisão na regra, mesma ideia de negócio (duas margens, uma para dentro do ciclo e outra para o próprio início de ciclo).

• v4.29 (16/09/2026) — Terceiro ajuste de RN-CM-023, pedido do solicitante ao revisar a v4.28, em paralelo com a Seção 4.5 do Mapeamento (v4.32): (1) a condição do C1D1 só se aplica quando existe um plano terapêutico formal cadastrado para o mesmo protocolo — antes o texto não deixava essa dependência clara; quando não há plano, a condição é ignorada para aquele paciente. (2) A condição de sessão diverge da data esperada foi simplificada no texto (sem mudança de sentido de negócio) — mantém as duas margens de tolerância (mesma vs. outro ciclo), mas descrita agora sem a mecânica interna de cálculo, que pertence só ao Mapeamento.

• v4.28 (16/09/2026) — Pedido do solicitante ao revisar a RN-CM-023 (v4.27): o cálculo de não adesão não pode depender de plano terapêutico (muitos médicos não criam um no sistema) nem de vínculo garantido entre prescrição real e sessão projetada. RN-CM-023 reescrita em paralelo com a correção técnica feita na Seção 4.5 do Mapeamento de Banco de Dados (v4.31): o cálculo passa a partir das prescrições já realizadas do paciente, ancorado na primeira sessão do tratamento (C1D1), sem depender de plano formal; a condição de “sessão diverge da data estimada” passa a usar duas margens de tolerância diferentes (uma para desvio dentro do mesmo ciclo, outra para desvio que atravessa ciclo), em vez de uma única margem genérica. Texto mantido em linguagem de negócio, sem nomes de campo (mapeamento técnico completo: Seção 4.5 do Mapeamento).

• v4.27 (16/09/2026) — Rodada de correções após a primeira revisão de versão aprovada (Agentes de UI/UX e Técnico, ver Skill Designer). (1) RN-CM-011: os limiares de urgência (12h/24h) voltam a ser descritos como valores fixos “por enquanto” — a v4.26 anterior os tinha descrito como parâmetro configurável por engano, junto com o parâmetro de RN-CM-020; decisão do solicitante nesta versão. (2) RN-CM-020: a “janela de 7 dias” passa a apontar para a Seção 4.6, onde nasce nesta mesma rodada o parâmetro de banco IpParametro.PrescricaoValidadeAssinatura (Mapeamento de Banco de Dados v4.30). (3) RN-CM-023 reescrita de duas para três condições de não adesão, para bater com o Mapeamento de Banco de Dados (que já usava três) — a divergência vinha de a Definição não ter sido atualizada quando a regra evoluiu no documento técnico; a segunda condição também recebeu a correção de conceito registrada no Mapeamento v4.30 (comparação por sessão, não por intervalo entre ciclos). (4) Nova RN-CM-024, documentando o critério de “6 meses de atividade” para entrar no KPI “Em Tratamento” — regra que já existia implementada no Mapeamento de Banco de Dados desde antes da divisão em 4 arquivos, mas nunca tinha chegado à Definição. (5) Nova RN-CM-025 (“Tags de Atenção”), documentando o conceito de tags (criadas e administradas pela própria clínica, sinalizando características do paciente em pontos definidos da aplicação) que já aparecia na Especificação e no Mapeamento sem nunca ter sido definido na Seção 1 — cadastro/administração das tags continua fora do escopo deste documento. (6) RN-CM-015 ganhou um novo bullet (“Retorno à camada de não lidas”), documentando um comportamento que já existia na Especificação (§2.5) e no Protótipo, mas não na Definição: uma conversa já respondida que recebe atividade nova volta a aparecer como não lida, mantendo o selo “Respondida”. (7) Removida a expressão “confirmada com o solicitante” do corpo de RN-CM-023 (proveniência de decisão não deve aparecer fora do Histórico — Lições Aprendidas da Skill Designer); preservada nesta entrada. (8) Nome do painel “Comunicação” trocado para “Mensagens” em todas as 5 ocorrências deste documento (narrativa do dia, tabela de touchpoints, descrição do Quadrante inferior esquerdo, agrupamento de atualização de RN-CM-017, fluxo principal) — consolidando com o nome já usado no link de navegação da Especificação; a seção/workflow “Comunicação Interna” (rótulo de organização do documento, não nome de painel) não foi alterada. (9) Referências cruzadas corrigidas: RN-CM-004 apontava para “Seção 2.8” quando o intervalo de busca está na Seção 2.1; RN-CM-017 apontava para “Seção 2.8” quando o mecanismo de polling está na Seção 2.9. Verificação estendida (pedido do solicitante: “corrija as referências cruzadas”) encontrou mais duas referências a “Seção 2.8” sem destino correspondente — RN-CM-001 (detalhamento do scroll independente por painel) e RN-CM-002 (cor exata do cabeçalho do painel); nenhuma das duas está de fato descrita na Seção 2.8 da Especificação — convertidas em nota honesta de lacuna em vez de apontar para um lugar errado, já que o conteúdo em si ainda não existe em nenhuma seção.

• v4.25 (29/08/2026) — Arquivo criado pela divisão do documento único CM_CockPit_do_medico_v4_25.md em 4 arquivos por seção (ver Skill Designer, “Organização Física: Pasta por Funcionalidade”, Lição #18). Conteúdo desta seção sem alteração de substância em relação à v4.25 do documento original — apenas reorganização física. O histórico de revisões anterior a esta divisão (v4.0 a v4.25, incluindo o racional de cada mudança) está preservado integralmente no documento original, arquivado em Histórico/CM_CockPit_do_medico_v4_25 (documento único, antes da divisão em 4 arquivos).md.

• v4.26 (30/08/2026) — Duas correções pedidas pelo solicitante, focadas em compreensão humana (Workflow 1, “Antes de chamar o próximo paciente” e “Durante o atendimento”): (1) a justificativa de design do badge de atraso foi reescrita para linguagem mais direta — “Pacientes atrasados provavelmente geram sobreposição de horários. Cabe ao médico decidir quem atender primeiro” — sem alterar o comportamento descrito (continua sendo decisão do médico, badge não sugere prioridade). (2) o touchpoint “Durante o atendimento” foi renomeado para “Durante o turno” — “atendimento” é um termo já usado neste documento para o momento em que o profissional está fisicamente com o paciente (consulta em andamento), o que não é o que este touchpoint descreve (o médico navegando entre pacientes ao longo do turno); justificativa de design reescrita no mesmo sentido: “Durante o turno, o médico foca nos próximos atendimentos - finalizadas saem do foco visual sem sumir da lista.” RN-CM-020 (revisão automática pré-aplicação) também ajustada: a janela de “1 dia (24h)” deixa de ser descrita como valor fixo — passa a ser explicitamente um parâmetro configurável por clínica (mesmo padrão já usado para os limiares de urgência de RN-CM-011 e para a janela de 7 dias), com o mapeamento de banco completo do novo parâmetro (IpParametro.PrescricaoTempoRevisao) na Seção 4.6 — pedido do solicitante.