# Central do Médico (Cockpit) — Especificação (v6.0) **Documentos desta funcionalidade:** [01 - Definição](./01%20-%20Defini%C3%A7%C3%A3o%20v6.0.md) (v6.0) · [02 - Especificação](./02%20-%20Especifica%C3%A7%C3%A3o%20v6.0.md) (v6.0) · [03 - Protótipo](./03%20-%20Prot%C3%B3tipo%20v6.0.md) (v6.0, código executável em `03 - Protótipo v6.0.html`) · [04 - Mapeamento de Banco de Dados](./04%20-%20Mapeamento%20de%20Banco%20de%20Dados%20v6.0.md) (v6.0) · [05 - Registro de Decisões](./05%20-%20Registro%20de%20Decis%C3%B5es%20v1.20.md) (v1.20) --- ## SEÇÃO 2 — ESPECIFICAÇÃO Premissa de design: Toda decisão de design nesta especificação é justificada pelos touchpoints de workflow documentados na Seção 1. Ao escolher um componente, definir uma ordenação, priorizar uma informação visualmente ou estabelecer um comportamento de navegação, a decisão apoia o fluxo real do profissional naquele momento específico do workflow. Consulte a seção "Workflows do Profissional" na Seção 1 para o contexto completo de cada touchpoint. Tema claro e escuro: a tela segue o Design System (`Para IA/Design System.md`, seções 1 a 11) — tema claro por padrão, tema escuro pela preferência do sistema do aparelho ("Automático") ou fixado pelo usuário no menu do avatar ("Tema": Automático, Claro, Escuro). Nenhuma cor desta especificação é específica de um tema: os valores de cor são tokens do Design System, que trocam de valor no tema escuro pelas regras C1–C7, e qualquer valor hexadecimal citado adiante corresponde ao token equivalente do tema claro; cores de status vêm da API, no próprio status (`status.colors`, um par fundo/texto para cada tema), e são aplicadas pelas classes `.chip-status` (chip) e `.avatar-status` (avatar) do Design System, seção 4; cores de tag usam o padrão `.chip-tag` com a cor do cadastro (seção 5). ### 2.1 Cabeçalho (Header) com Busca de Pacientes US-CM-000 — Buscar pacientes rapidamente Como médico, quero buscar qualquer paciente pelo nome, CPF, data de nascimento ou nome da mãe diretamente do cabeçalho, para acessar o prontuário sem precisar navegar por menus. Descrição Funcional: O cabeçalho é a barra superior fixa da Central do Médico e contém 3 blocos: 1. Identificação da clínica: Nome da clínica onde o médico está logado (sem a unidade/local de atendimento). 2. Campo de busca de pacientes: Campo de texto. A busca é inteligente e contextual: - O placeholder do campo deve ser `MSG_searchPac` para deixar explícito que é uma busca por pacientes. - Ao abrir o dropdown de resultados, exibir uma mensagem de orientação no rodapé da lista: `MSG_searchFoot`. - A primeira busca é acionada quando o usuário digita os primeiros 2 caracteres e para de digitar por 1 segundo. A partir desse primeiro disparo, a lista vai sendo filtrada dinamicamente conforme o usuário continua digitando, sem necessidade de novo intervalo de pausa. - A busca sempre retorna uma lista, pois o algoritmo busca por aproximação de termos. Se o usuário digitar "ay", o sistema busca termos em torno de "ay": "ay" será o mais prioritário, mas se não encontrar, retornará "ai", "aj" e assim por diante. - Se a entrada começar com dígito, o sistema busca por CPF ou Data de Nascimento. Se começar com letra, busca por Nome do Paciente ou Nome da Mãe. - Os resultados da busca devem conter minimamente: nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF (conforme requisito SBIS ECF.03.14). - Ao selecionar um paciente na lista de resultados, o sistema abre o Prontuário Eletrônico do Paciente (PEP). - O número de prontuário aparece nos resultados, mas não é critério da busca comum (D-CM-036). Existe um artifício na busca, a chave `id:` (ex: `id:0012345`), que localiza o paciente pelo prontuário; ele será mostrado na certificação e não entra na busca normal por enquanto, até se avaliar se é útil ao médico. 3. Menu do usuário: Avatar com foto do profissional (quando disponível) ou iniciais, com um ícone de dropdown (seta) ao lado. **Não exibe nome, CRM ou especialidade do médico no cabeçalho** — essas informações vivem dentro do menu, não como texto fixo visível. Clicar no avatar ou na seta abre um menu suspenso abaixo, à direita, com ações específicas do usuário. Por enquanto, o menu contém o seletor "Tema" (Automático, Claro, Escuro — Design System, seção 6; `MSG_themeOptions`) e "Sair". Itens previstos para versões futuras (fora do escopo desta versão, ainda não especificados): autocadastro/edição de perfil, dados de faturamento e pagamento (conta bancária, PIX) e dados de especialidade (CRM, RQE). Clicar fora do menu ou selecionar um item o fecha. Justificativa de workflow: A busca por pacientes no cabeçalho atende ao touchpoint 'Antes de chamar o próximo paciente' (Workflow 1) e ao touchpoint 'Decidir se precisa intervir em um procedimento' (Workflow 2). Em ambos os momentos, o médico pode precisar acessar um prontuário que não está visível nos painéis — a busca global no cabeçalho é o atalho universal, disponível em qualquer momento do turno. Critérios de Aceitação: - Dado que o médico digita "Ma" no campo de busca, quando ele para de digitar por 1 segundo, então o sistema deve retornar pacientes cujo nome ou nome da mãe contenham "Ma" ou termos aproximados, exibindo nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF. - Dado que o médico digita "12" no campo de busca, quando ele para de digitar por 1 segundo, então o sistema deve buscar por CPF ou data de nascimento que contenham "12". - Dado que o médico digita apenas 1 caractere, então o sistema não deve disparar a busca, exibindo a mensagem `MSG_searchMin` no rodapé do dropdown. - Dado que o médico digita "ay" e não existe paciente com esse termo exato, então o sistema deve retornar pacientes com termos próximos (aproximação), como "Ayla", "Aymoré", ordenados por relevância. - Dado o médico seleciona um paciente na lista de resultados, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP), preservando o contexto do profissional logado. - Dado que a busca não retorna resultados, então o sistema deve exibir `MSG_searchNone` - Dado que o médico clica no avatar ou na seta de dropdown, então o sistema deve abrir o menu do usuário abaixo, à direita, contendo ao menos o seletor "Tema" e o item "Sair". - Dado que o menu do usuário está aberto e o médico clica fora dele, então o sistema deve fechar o menu. - Dado que o médico clica em "Sair" no menu, então o sistema deve encerrar a sessão (fluxo de logout fora do escopo deste documento). - Dado que o médico escolhe "Escuro" (ou "Claro") no seletor "Tema", então todas as telas da Central passam para o tema escolhido, e com "Automático" seguem a preferência do sistema do aparelho. - Dado que o cabeçalho é renderizado, então ele não deve exibir nome do médico, CRM, especialidade ou unidade/local de atendimento — apenas o nome da clínica à esquerda e o avatar com dropdown à direita. Internacionalização: | Termo | pt-BR | en-US | es-419 | | | -------------- | ------------------------------------------------------------------------- | ----------------------------------------------------------- | --------------------------------------------------------------------------------- | --- | | MSG_searchPac | Procurar paciente... | Search patient... | Buscar paciente... | | | MSG_searchFoot | Digite parte do nome, CPF, data de nascimento ou nome da mãe para filtrar | Enter part of the name, ID, mother's name or DOB to filter | Ingrese parte del nombre, ID, nombre de la madre o fecha de nacimiento para filtrar | | | MSG_searchMin | Digite pelo menos 2 caracteres para iniciar a busca. | Type at least 2 characters to start searching. | Escriba al menos 2 caracteres para iniciar la búsqueda. | | | MSG_searchNone | Nenhum paciente encontrado com os dados informados. | No patient found with the provided data. | Ningún paciente encontrado con los datos informados. | | | MSG_themeOptions | Tema / Automático (segue o sistema do aparelho) / Claro / Escuro | Theme / Automatic (follows the device setting) / Light / Dark | Tema / Automático (sigue la configuración del dispositivo) / Claro / Oscuro | | --- ### 2.2 KPI Bar (Indicadores) US-CM-001 — Visualizar indicadores do dia Como médico, quero ver um resumo numérico do meu dia (consultas, tratamentos, procedimentos na clínica e alertas) em uma barra no topo, para ter um panorama rápido sem precisar analisar cada painel. Descrição Funcional: Layout dos cards: Cada KPI card possui uma borda lateral esquerda colorida (4px) que identifica visualmente a categoria: - Consultas Hoje → azul (color-secondary-pure), - Em Tratamento → verde (color-primary-pure), - Procedimentos Hoje → âmbar (color-highlight-pure), - Alertas de Prescrição → vermelho (color-error-pure). O ícone do KPI fica posicionado à direita do texto. Motivador: a borda colorida permite identificação rápida da categoria mesmo em uma olhada periférica, sem necessidade de leitura do título. Justificativa de workflow: Os 4 KPIs correspondem aos 4 workflows que a Central toca: Consultas Hoje (Workflow 1), Em Tratamento (Workflow 2), Alertas de Prescrição (Workflow 3) e Procedimentos Hoje (Workflow 2). No início do turno (touchpoint comum a todos os workflows), o médico precisa calibrar expectativas de carga de trabalho — os KPIs dão isso em um olhar, sem abrir nenhum painel. Cada KPI é clicável porque, após o panorama inicial, o médico pode precisar aprofundar em um workflow específico. A KPI Bar é uma faixa horizontal entre o cabeçalho e o grid 2×2, contendo 4 cartões de indicadores fixos. Cada cartão é clicável e navega para a tela dedicada correspondente. 1. Consultas Hoje: Exibe "finalizadas/total" (ex: "4/6"). Subtexto: "X pendentes (Y atrasadas)" — as atrasadas já estão contadas nas pendentes, e o parêntese deixa isso visível sem ocupar espaço (D-CM-018); no singular, "1 pendente (1 atrasada)". Para o leitor de tela: "X pendentes, das quais Y atrasadas". - Definição dos termos: - Pendentes: agendas que ainda não foram finalizadas - Atrasadas: agendas pendentes cuja hora marcada já passou e que ainda não foram iniciadas — uma consulta já em atendimento é pendente, mas não é atrasada - Horários bloqueados pela Recepção na agenda do médico não entram em nenhum destes números (RN-CM-030). - Ao clicar: abre a tela da Agenda do Médico 2. Em Tratamento: Exibe o total de pacientes em tratamento (número principal) cujo médico assistente é o médico logado. Subtexto: 'Y não aderentes'. - Definição dos termos: - Em tratamento (número principal): pacientes que estão em tratamento cujo médico assistente é o médico logado - Não aderentes: pacientes em tratamento que não estão conformes com o planejamento do tratamento (plano terapêutico) — pode ser por descompasso com os intervalos entre sessões e/ou ciclos previstos - Ao clicar: abre a tela de Pacientes do Médico 3. Procedimentos Hoje: Exibe o total de procedimentos (não consultas) do médico logado na unidade hoje — o total inclui os procedimentos já finalizados (D-CM-038). Subtexto: "X em atendimento · Y aguardando · Z previstos" — é um auxiliar telegráfico das pendências do dia, não precisa fechar a conta com o número principal (D-CM-038). - Definição dos termos: - Em atendimento: pacientes do médico logado que já estão em procedimento (iniciaram quimioterapia, estão realizando cateterismo ou limpeza de cateter, iniciaram sessão radioterápica, iniciaram cirurgia, etc.) - Aguardando: pacientes do médico logado que estão na clínica (em check-in ou sendo preparados para o procedimento) mas ainda não iniciaram o procedimento - Previstos: pacientes do médico logado que ainda não chegaram à clínica mas têm procedimento previsto para o dia - Ao clicar: abre a tela de Pacientes em procedimento 4. Alertas de Prescrição: Exibe o total de prescrições pendentes urgentes (menos de 12h para aplicação). Subtexto: "X p/revisar · Y p/assinar (próx. N dias)", onde N é a janela de assinatura (padrão 7), enviada pelo backend no campo `toSignWindowDays`; com clínicas de janelas diferentes, N é o da clínica em que o médico está logado (D-CM-063) — o front monta o texto (e o traduz) com esse número; no singular, "próx. 1 dia". - Definição dos termos: - Urgentes (número principal): prescrições pendentes de assinatura E pendentes de revisão com menos de 12h para a aplicação agendada - P/revisar: prescrições marcadas automaticamente pelo sistema como "a revisar" (aplicação agendada dentro da janela de antecedência de revisão — parâmetro `NumeroDiasRevisaoPrescricoes`, configurável por clínica, em dias, valor-padrão 1 dia — em dias de calendário no fuso da clínica em que o usuário está logado (D-CM-037, D-CM-062), com o N da clínica de cada prescrição (D-CM-060), e ainda sem revisão de nenhum médico — nem assinatura feita depois de a janela abrir (D-CM-040) — e sem administração iniciada (D-CM-039), inclusive quando a hora da aplicação já passou — ver RN-CM-020) - P/assinar (próx. N dias): prescrições pendentes de assinatura com aplicação prevista hoje ou nos próximos N dias de calendário, no fuso da clínica em que o usuário está logado (N = `PrescricaoTempoAssinatura` da clínica de cada prescrição, padrão 7; D-CM-037, D-CM-060, D-CM-062), inclusive as que já passaram da hora de aplicação — mesmo quando a administração já foi iniciada, pois uma prescrição sem assinatura em procedimento é falha grave de processo e deve continuar visível (D-CM-039) - Quando o valor principal (urgentes) for maior que zero, o número deve aparecer em vermelho escuro (cor `color-error-dark`, D-CM-054, D-CM-058: 6,3:1 sobre `base-pure` no claro e 7,4:1 no escuro; antes `color-error-pure`). - Ao clicar: abre a tela de Prescrições Pendentes Escopo de clínicas (D-CM-066, RN-CM-032, E-CM-029): "Consultas Hoje", "Procedimentos Hoje" e "Alertas de Prescrição" contam as consultas, os procedimentos e as prescrições das clínicas em que o médico atende, o mesmo conjunto dos painéis. "Em Tratamento" conta os pacientes do médico; a janela de atividade usa os parâmetros da clínica em que ele está logado (D-CM-063). Critérios de Aceitação: - Dado que o médico abre a Central, quando os dados são carregados, então a KPI Bar deve exibir os 4 indicadores com seus respectivos subtextos. - Dado que o KPI de Alertas de Prescrição tem 3 prescrições urgentes, então o número "3" deve ser exibido em vermelho escuro (`color-error-dark`). - Dado que o KPI de Alertas de Prescrição tem 0 urgentes, então o número "0" deve ser exibido na cor padrão (não vermelho). - Dado que o médico clica no card "Consultas Hoje", então o sistema deve navegar para a tela da Agenda do Médico. - Dado que a Recepção bloqueou um horário hoje na agenda do médico, então esse bloqueio não entra no total, nas finalizadas, nas pendentes nem nas atrasadas do card "Consultas Hoje" (RN-CM-030). - Dado que o médico clica no card "Em Tratamento", então o sistema deve navegar para a tela de Pacientes do Médico. - Dado que o médico clica no card "Procedimentos Hoje", então o sistema deve navegar para a tela de Pacientes em procedimento. - Dado que o médico clica no card "Alertas de Prescrição", então o sistema deve navegar para a tela de Prescrições Pendentes. - Dado que o endpoint de KPIs falha, então a KPI Bar deve exibir "—" nos valores e os demais painéis devem continuar operando normalmente. Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | |-------|-------|--------|----| |Card Consultas Hoje - título|CONSULTAS HOJE|TODAY'S APPOINTMENTS|CONSULTAS DE HOY| |Card Consultas Hoje - pendentes|pendentes|pending|pendientes| |Card Consultas Hoje - atrasadas|atrasadas|delayed|atrasadas| |Card Consultas Hoje - pendente (n = 1)|pendente|pending|pendiente| |Card Consultas Hoje - atrasada (n = 1)|atrasada|delayed|atrasada| |Card Em tratamento - título|EM TRATAMENTO|IN TREATMENT|EN TRATAMIENTO| |Card Em tratamento - não aderentes|não aderentes|non-adherent|no adherentes| |Card Procedimentos Hoje - título|PROCEDIMENTOS HOJE|TODAY'S PROCEDURES|PROCEDIMIENTOS HOY| |Card Procedimentos Hoje - em atendimento|em atendimento|in progress|en atención| |Card Procedimentos Hoje - aguardando|aguardando|waiting|en espera| |Card Procedimentos Hoje - previstos|previstos|scheduled|programados| |Card Alertas de prescrição - título|ALERTAS DE PRESCRIÇÃO|PRESCRIPTION ALERTS|ALERTAS DE PRESCRIPCIÓN| |Card Alertas de prescrição - revisar|p/revisar|to review|p/revisar| |Card Alertas de prescrição - assinar|p/assinar (próx. {n} dias)|to sign (next {n} days)|p/firmar (próx. {n} días)| |Card Alertas de prescrição - assinar (n = 1)|p/assinar (próx. 1 dia)|to sign (next 1 day)|p/firmar (próx. 1 día)| --- ### 2.3 Painel de Consultas (Quadrante Superior Esquerdo) US-CM-002 — Visualizar consultas do dia Como médico, quero ver minhas consultas do dia em ordem cronológica com informações clínicas relevantes, para organizar meu fluxo de atendimento. US-CM-003 — Filtrar consultas pendentes Como médico, quero alternar entre "Todas" e "Pendentes" no painel de consultas, para focar apenas nas consultas que ainda não foram realizadas. Descrição Funcional: O painel de Consultas exibe a agenda do médico para o dia, composta por cards de consulta. Cada card contém: - Hora prevista da consulta e hora prevista de término (ou tempo previsto da consulta) - Nome do paciente com foto (avatar com iniciais ou foto, quando disponível), seguido do ícone de 1ª Consulta quando for o caso (RN-CM-028): ícone `circle-number-1` (Tabler Icons, react-icons `TbCircleNumber1`), 18px, sem fundo, cor `--color-first-visit`, com `role="img"`, rótulo acessível e dica "1ª Consulta"; a dica abre ao passar o mouse e também ao tocar no ícone (no celular não existe passar o mouse) — o toque no ícone abre só a dica e não aciona o card; o ícone não recebe foco próprio, porque "1ª Consulta" já faz parte do nome acessível do card; a dica fecha ao tocar fora (esse primeiro toque só fecha a dica, não aciona o que estiver sob o dedo), ao rolar a tela, ao redimensionar a janela ou com Esc; com o mouse ela fica aberta enquanto o ponteiro estiver sobre o ícone ou sobre a própria dica; e não fecha sozinha na atualização automática do painel - Diagnóstico(s) oncológico(s) (se houver — ex: "Ca. Mama"; um paciente pode ter mais de um diagnóstico oncológico ativo, e todos são exibidos; um diagnóstico cujo registro de prontuário começa depois de hoje ainda não vale e não é exibido) - Modo de atendimento (Presencial / Teleatendimento) - Clínica (D-CM-066, RN-CM-032, E-CM-028): nome curto da clínica da consulta, em texto de 12px `color-neutral-pure` com o ícone Lucide `building-2` de 14px, como informação secundária (sem chip), só quando o médico atende em mais de uma clínica (D-CM-066, mesma regra de RN-AGM-017, a); com uma só clínica, a linha não aparece. O painel reúne as consultas das clínicas em que o médico atende (RN-AGM-002), e "hoje" e os horários seguem o fuso da clínica em que o médico está logado (RN-AGM-018, D-CM-062). - Tags de atenção (se houver — ex: VIP, Quimioterapia; o ícone de 1ª Consulta não é uma tag: aparece logo depois do nome do paciente e segue regra própria, RN-CM-028). Ordem (D-CM-022): primeiro o ícone de 1ª Consulta (junto ao nome), depois as tags assistenciais (`ProgramaApoio.Finalidade = 'A'`) e por fim as administrativas (`'D'`, como VIP); dentro de cada grupo, ordem alfabética pela sigla - Status da agenda (Agendado, Aguardando recepção, Recepcionado, Em atendimento, Finalizado) - Consulta em atendimento além do previsto (D-CM-017): quando o tempo desde o início do atendimento (`Agenda.DhAtendimentoIniUTC`) passa da duração prevista da agenda (`Agenda.Tempo`), o card mostra ao lado do status o tempo decorrido em destaque — "há 1h20" (abaixo de 1h, "há 45min") —, com o ícone Lucide `clock-alert` e cor de atenção (fundo `color-highlight-light`, sem contorno, texto e ícone `color-highlight-dark`, os mesmos tokens do chip "Atenção" de RN-CM-011; D-CM-046; leve, como os chips de prescrição, D-CM-053) (tokens e posição confirmados — D-CM-027, E-CM-017). Motivo: a consulta em atendimento está sob controle do médico, e uma consulta aberta por muito tempo provavelmente é uma anomalia (atendimento não fechado, ou iniciado sem querer), então deve incomodar o olhar. Sem tolerância: o destaque aparece assim que o tempo passa do previsto e some quando a consulta é finalizada. O nome acessível do card acrescenta "em atendimento há 1h20, além do previsto" Horários bloqueados: bloqueios feitos pela Recepção na agenda do médico não aparecem neste painel, em nenhum estado do toggle (RN-CM-030). Ordenação: A lista deve estar ordenada pela hora agendada. Consultas finalizadas permanecem na sua posição original na ordem cronológica. Filtro: Deve haver um toggle em estilo pill (botões com borda discreta e fundo branco) entre 'Todas' e 'Pendentes'. O default é mostrar apenas as pendentes (oculta finalizadas). Ao alternar para 'Todas', as finalizadas aparecem na sua posição original esmaecidas. Motivador: o estilo pill é mais discreto que o bloco cinza anterior, competindo menos com o conteúdo dos cards. Tratamento visual de finalizadas: Consultas finalizadas devem aparecer esmaecidas (cor de fundo mais clara e borda discreta, sem redução de opacidade, para manter o contraste do texto), mantendo a ordem cronológica da agenda. Não são movidas para o final da lista — permanecem na sua posição original, apenas com sinalização visual de que já foram concluídas. Atraso: Quando o paciente está atrasado (horário agendado já passou e a consulta não foi iniciada nem finalizada), mostrar um sinalizador de "Atrasado" com o tempo de atraso em minutos, igual para qualquer consulta atrasada e não iniciada — a Central não diferencia paciente que já está na clínica ("Esperando") de paciente que ainda não chegou ("Não chegou"), distinção que existe só na Agenda do Médico (ex: "Atrasado · 15min", selo leve, sem contorno, com fundo `--color-error-light` e texto e ponto em `--color-error-dark` — contraste de 5,6:1 no tema claro e 6,3:1 no escuro —, e só o ponto pulsa (D-CM-054, D-CM-058); a Agenda do Médico mantém o selo preenchido com `--color-alert-fill`, Design System seção 4a). Cores de status (RN-CM-005): vêm da API, no próprio status (`status.colors`: `light` e `dark`, cada um com `background` e `text` em `#RRGGBB`; DT-016), e são aplicadas pelas classes `.chip-status` (chip) e `.avatar-status` (avatar de iniciais) do Design System, seção 4; o front usa o par do tema vigente e troca de par sem recarregar quando o tema muda. Sem `colors` (ou com valor fora do formato `#RRGGBB`), chip e avatar ficam neutros (Design System, seção 4). No avatar, as iniciais ficam em `color-neutral-darker` sobre a cor de fundo do status, nos dois temas: o avatar representa o paciente, e o status aparece nele só de forma sutil. O nome do status também vem da API (`status.name`, já no idioma da clínica). Os valores são os da tabela `IpTerminologia.DomEstadoAgendaConsulta` (Mapeamento 4.1), iguais para todas as clínicas; os de referência estão no Design System, seção 4. Destaque visual por status: Além dos chips coloridos, cards com status "Recepcionado" recebem uma borda lateral esquerda (3px) na cor secondary-pure (azul), sinalizando que o paciente está pronto para atendimento. Cards com status "Aguardando recepção" recebem borda lateral esquerda (3px) na cor do token `--color-status-waiting-border` (#FF8A80 no tema claro), sinalizando que o paciente está presente na clínica. Outros status não recebem borda adicional. Motivador: a borda colorida é consistente com o padrão de KPI cards e permite identificação periférica dos pacientes prontos para atendimento sem necessidade de leitura do chip. Navegação: O título do painel ('Consultas') é um link clicável para a tela dedicada da Agenda do Médico. No hover, o título muda de cor e uma seta (→) aparece ao lado. Ao clicar em qualquer card de consulta, o sistema abre o Prontuário Eletrônico do Paciente (PEP). Motivador: o título como link elimina a necessidade de um botão separado 'Ver agenda →', reduzindo ruído visual no cabeçalho do painel. Justificativa de workflow: Este painel atende ao touchpoint 'Antes de chamar o próximo paciente' (Workflow 1). O toggle default 'Pendentes' reflete que, neste momento do workflow, o médico só precisa ver quem falta atender. O badge de atraso reflete a exceção do workflow onde o horário passou e o paciente não foi chamado. O clique no card abrindo o PEP reflete que, neste momento, o médico precisa do prontuário para se preparar antes de chamar o paciente. Estado vazio: Quando não há consultas para exibir no toggle ativo, exibir ícone de calendário vazio com a mensagem correspondente ao toggle — `MSG_appointmentNonePending` (toggle 'Pendentes') ou `MSG_appointmentNoneAll` (toggle 'Todas'). Critérios de Aceitação: - Dado que o médico abre a Central, quando o painel de Consultas carrega, então o default deve mostrar apenas consultas pendentes, ordenadas por hora agendada. - Dado que o médico clica no toggle "Todas", então as consultas finalizadas devem aparecer na sua posição original esmaecidas (cor de fundo mais clara e borda discreta, sem redução de opacidade). - Dado que uma consulta agendada para 09:00 não foi iniciada e são 09:15, então o sistema deve exibir o selo "Atrasado · 15min" no card da consulta. - Dado que o médico atende em duas clínicas e há consultas hoje nas duas, então o painel mostra todas na mesma lista cronológica, cada card com a linha de clínica (ícone `building-2` e nome curto), e "Consultas Hoje" conta as duas; dado que o médico atende em uma só clínica, então nenhum card mostra o nome da clínica (D-CM-066, E-CM-028). - Dado que o cliente tem três clínicas (A, B e C), o médico atende em A e B e há consulta hoje na clínica C com outro médico, então o painel não mostra essa consulta e "Consultas Hoje" não a conta, mesmo com o toggle "Todos" (D-CM-066). - Dado que o médico clica em qualquer card de consulta, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP). - Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada da Agenda do Médico. - Dado que a Recepção bloqueou um horário hoje na agenda do médico, então o bloqueio não aparece no painel, nem no toggle 'Pendentes' nem no 'Todas' (RN-CM-030). - Dado que o toggle está em 'Pendentes' e não há consultas pendentes no dia, então o painel deve exibir "Nenhuma agenda pendente para o dia" (`MSG_appointmentNonePending`). - Dado que o toggle está em 'Todas' e não há nenhuma consulta no dia (pendente ou finalizada), então o painel deve exibir "Nenhuma agenda para o dia" (`MSG_appointmentNoneAll`). - Dado que uma consulta tem status "Recepcionado", então o card deve exibir borda lateral esquerda na cor secondary-pure (azul). - Dado que uma consulta tem status "Aguardando recepção", então o card deve exibir borda lateral esquerda na cor do token `--color-status-waiting-border`. Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | | ------------------- | ---------------------------- | ---------------------------- | -------------------------- | | painel-título | Consultas | Appointments | Consultas | | toggle-todas | Todas | All | Todas | | toggle-pendentes | Pendentes | Pending | Pendientes | | chip-atrasado | Atrasado | Delayed | Atrasado | | dica-primeira-consulta | 1ª Consulta | First visit | Primera consulta | | consulta-ha-tempo | há {t} | for {t} | hace {t} | | MSG_appointmentNonePending | Nenhuma agenda pendente para o dia | No pending appointments for this day | No hay citas pendientes para este día | | MSG_appointmentNoneAll | Nenhuma agenda para o dia | No appointments for this day | No hay citas para este día | Rótulos de status: vêm traduzidos da API (`status.name`; `TermoTraducao` com `Termo` = `CodEstado` e `Origem` = `DomEstadoAgendaConsulta`, Mapeamento 4.1), não são catalogados no front. --- ### 2.4 Painel de Prescrições Pendentes (Quadrante Superior Direito) US-CM-004 — Visualizar prescrições pendentes Como médico, quero ver as prescrições pendentes de assinatura ou revisão ordenadas por prioridade, para priorizar as que têm menos tempo até a aplicação agendada. US-CM-005 — Assinar prescrição Como médico, quero revisar e assinar prescrições pendentes diretamente no Cockpit, para que a farmácia possa liberar o medicamento a tempo. US-CM-006 — Revisar prescrição Como médico, quero revisar e confirmar prescrições que o sistema marcou automaticamente como pendentes de revisão perto da aplicação, para garantir que algum médico validou a prescrição antes da administração ao paciente. Descrição Funcional: O painel de Prescrições Pendentes lista as prescrições que aguardam ação do médico, divididas em duas categorias: 1. Prescrições para assinar — nunca assinadas por nenhum médico, com aplicação agendada dentro da janela de antecedência de assinatura (RN-CM-020). Essa janela também não é um valor fixo: é um parâmetro configurável por clínica, em dias de calendário no fuso da clínica (D-CM-037), com valor-padrão de 7 dias — com N = 7 e hoje sendo o dia 10, entram as aplicações até 17, 23:59, mais as já vencidas — mapeamento do parâmetro de banco (`PrescricaoTempoAssinatura`) na Seção 4.6 do Mapeamento de Banco de Dados. 2. Prescrições para revisar — marcadas automaticamente pelo sistema quando a aplicação agendada entra na janela de antecedência de revisão e a prescrição ainda não foi revisada por nenhum médico (RN-CM-020) — assinatura feita depois de a janela abrir conta como revisão (D-CM-040) e prescrição com administração iniciada já saiu da lista (D-CM-039). Essa janela não é um valor fixo: é um parâmetro configurável por clínica, em dias, com valor-padrão de 1 dia (parâmetro `NumeroDiasRevisaoPrescricoes`, já existente no sistema atual; o padrão de 1 dia é do Gemed 2.1), usado também quando a clínica não tem o parâmetro configurado — mapeamento do parâmetro de banco na Seção 4.6 do Mapeamento de Banco de Dados. A janela de revisão é independente dos limiares de urgência dos chips (12h/24h, RN-CM-011), que são fixos: a janela é em dias de calendário no fuso da clínica (D-CM-023): com N = 1 e hoje sendo o dia 10, entram as aplicações dos dias 10 e 11, até 23:59, mais as já vencidas — um dia não são 24 horas. Por isso uma prescrição "a revisar" cuja aplicação é no dia seguinte, depois do horário atual, aparece sem chip (24h ou mais restantes). Uma prescrição só entra nessa categoria depois de já assinada — é uma segunda barreira de segurança, independente e posterior à assinatura, não relacionada a notificações de farmácia ou enfermagem; diferente da assinatura, a confirmação de revisão ("Marcar como Revisada") não tem prazo de validade — uma vez revisada, a prescrição não volta a aparecer nesta lista (RN-CM-020). Em ambas as categorias, só entram prescrições "em andamento" (`Prescricao.Situacao` em `P`/`G`/`A`/`O`) — uma prescrição já finalizada (`Q`), faturada (`F`), de atendimento externo (`E`) ou cancelada (`C`) não aparece em nenhuma das duas listas, mesmo que nunca tenha sido assinada ou revisada (RN-CM-020). Cada card de prescrição contém: - Nome do paciente (nome social, se houver; caso contrário nome civil) — o endpoint envia ambos (`preferredName`/`legalName`, mesmo padrão do painel de Consultas e de Procedimentos) para o médico perceber uma eventual questão de nome social/gênero antes de abrir a prescrição - Código da prescrição, no formato "Protocolo CxDy" (ex: "CARBO-TAXOL C3D1", onde C = ciclo e D = dia/sessão) — vem pronto do banco (`Prescricao.Identificacao`), sem montagem de protocolo e ciclo como campos separados - Data da agenda da aplicação agendada (ex: "22/07 18:00") — importante principalmente para prescrições pendentes de revisão, pois a data é o próprio motivo pelo qual a prescrição está nessa lista - Tempo restante até a aplicação agendada (D-CM-041): abaixo de 1 hora, em minutos ("45min restantes"); a partir de 1 hora, em horas ("8h restantes"). Quando a hora da aplicação já passou e a prescrição segue sem assinatura ou revisão, o card mostra o atraso no lugar do tempo restante, sempre com o chip vermelho: abaixo de 1 hora, "40min atrasada"; de 1 hora até 47h59, horas e minutos com dois dígitos nos minutos ("1h59 atrasada", "3h00 atrasada"); a partir de 48 horas, em dias ("30 dias atrasada"). No contrato, `hoursRemaining` e `minutesRemaining` seguem menores ou iguais a zero; os textos são montados no front a partir de `minutesRemaining` (chaves em Internacionalização). O feminino foi confirmado (D-CM-027); o formato em horas, minutos e dias segue D-CM-041; a exibição em minutos do tempo restante abaixo de 1 hora segue D-CM-055 - Tipo de ação (Assinar ou Revisar) - Clínica (D-CM-066, RN-CM-032, E-CM-028): nome curto da clínica da agenda da prescrição, com o mesmo formato, a mesma regra de exibição e o mesmo ícone do card de consulta; só aparece quando o médico atende em mais de uma clínica. O painel e o toggle "Todos" reúnem as prescrições das clínicas em que o médico atende (D-CM-066). O tempo restante é sempre até a aplicação; já as janelas que decidem se a prescrição entra em "a assinar" ou "a revisar" seguem os parâmetros da clínica da própria prescrição (D-CM-060); o "hoje" e o fim do dia de cada janela seguem o fuso da clínica em que o médico está logado (D-CM-062). - Destaque visual (não texto com nomes de terceiros), nas duas categorias, quando o médico logado é o prescritor ou o médico assistente do paciente — revisor ou assinante preferencial (RN-CM-020) Terminologia: o chip "Crítico" (menos de 12h, inclusive atrasada) é o mesmo que o KPI chama de "Urgentes"; o chip "Atenção" cobre de 12h a menos de 24h. No código, o indicador de tempo se chama `timeIndicator` (valores `critical`, `attention` e `normal` **[PROPOSTA]**) e vale também para o chip "Atenção" da consulta em atendimento além do previsto (D-CM-090); não se confunde com `urgencyLevel`, o grau de urgência da conversa. O campo `urgent` do endpoint de alertas de prescrição (a contagem do KPI) não muda. Ordenação: As prescrições devem ser ordenadas por prioridade — quanto mais próxima da data de aplicação agendada, mais prioritária é: ordem crescente de `minutesRemaining`, com desempate pelo nome do paciente em ordem alfabética (nome social, se houver; senão o nome civil; sem diferenciar maiúsculas e acentos) e, para o mesmo nome, pelo `id` da prescrição, do menor para o maior (D-CM-047, E-CM-027). Prescrições com a hora de aplicação já passada (tempo restante negativo) ficam na lista, no topo da ordenação (são as de menor tempo restante), e continuam contando como urgentes até serem assinadas ou revisadas. As prescrições com menos de 12 horas restantes — o que inclui as de tempo negativo — são classificadas como "Críticas" e marcadas com chip vermelho leve (fundo `color-error-light`, sem contorno, texto e ícone em `color-error-dark`, ícone `triangle-alert`). Entre 12h e 24h, são "Atenção" e marcadas com chip laranja leve (fundo `color-highlight-light`, sem contorno, texto e ícone em `color-highlight-dark`, ícone `clock`). Nos dois chips o peso do texto é o regular (`font-weight-regular`, 400; D-CM-056). O chip é um alerta e não deve pesar no card — quem protagoniza é a informação do paciente e da prescrição —, por isso não tem contorno nem fundo saturado; o ícone garante que a urgência não dependa só de cor, e o par `-dark` sobre `-light` mantém o contraste do texto acima de 4,5:1 (Crítico 5,6:1 e Atenção 5,0:1 no tema claro; 6,3:1 e 8,9:1 no escuro) (D-CM-046). A partir de 24h restantes (RN-CM-011), não há chip — o tempo restante é exibido como texto simples, sem fundo colorido, na cor padrão de texto secundário do card (`color-neutral-pure`); isso é comum, já que prescrições pendentes de assinatura podem aparecer na lista com até 7 dias de calendário de antecedência (parâmetro `PrescricaoTempoAssinatura`, valor-padrão 7 dias — Seção 4.6/4.7). Filtro "Meus / Todos": O painel tem um toggle em estilo pill entre "Meus" e "Todos", que afeta as duas categorias (a assinar e a revisar) da mesma forma — 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). "Meus" mostra as prescrições — a assinar e a revisar — em que o médico logado é o prescritor ou o médico assistente do paciente (revisor/assinante preferencial, RN-CM-020). "Todos" mostra as prescrições de todos os médicos, nas clínicas em que o médico logado atende (D-CM-066), nas duas categorias. O default é "Meus" — consistente com o padrão do painel Pacientes em procedimento. Assinatura (tela de assinatura): Ao clicar em "Assinar", o sistema abre a tela de assinatura com a prescrição completa para que o médico revise e se certifique de que é a prescrição correta. É responsabilidade do médico saber o que está assinando — a assinatura não pode ser um clique direto sem revisão. A tela exibe todos os medicamentos, doses, vias, diluentes e instruções. Após revisão, o médico clica em "Assinar" na tela, que processa a assinatura conforme o modo configurado (com ou sem certificado digital). Em caso de sucesso, o sistema exibe um toast de sucesso "Prescrição assinada com sucesso" e retorna automaticamente à Central do Médico, focada no painel de Prescrições Pendentes, com o KPI de Alertas atualizado. Se a prescrição assinada tiver aplicação dentro da janela de revisão, ela sai da lista inteira: a assinatura feita depois de a janela abrir dispensa a revisão (D-CM-040, E-CM-019) — o número de "P/assinar" diminui em uma unidade (e o de "Urgentes", se a prescrição era urgente); não há "reassinar" nem passagem automática para "a revisar". Em caso de erro, exibir toast de erro na tela de assinatura. Revisão (tela de revisão): Ao clicar em "Revisar", o sistema abre a prescrição completa (medicamentos, doses, vias, diluentes e instruções) para o médico validar. O médico tem duas opções: (a) confirmar que a prescrição está correta, clicando em "Marcar como Revisada" — o sistema registra o médico revisor e o timestamp, e a prescrição sai da lista de pendentes; ou (b) identificar necessidade de ajuste e editar a prescrição, recalculando, adicionando ou retirando medicamentos. Nesse segundo caso, o sistema cancela a prescrição atual e cria uma nova versão com os itens ajustados — como é uma prescrição nova, ela precisa ser assinada novamente pelo médico (mesmo fluxo de assinatura de uma prescrição inédita) antes de sair da lista de pendentes; a edição por si só não conta como revisão. Em ambos os casos, o sistema retorna automaticamente à Central do Médico, focada no painel de Prescrições Pendentes, com o contador atualizado. Assinatura digital: A assinatura pode ocorrer de 2 modos, conforme configuração do cliente: - (a) Assinatura com certificado digital — exige certificado ativo vinculado ao perfil do médico - (b) Assinatura sem certificado — validada pela sessão do usuário logado Navegação: O título do painel ('Prescrições Pendentes') é um link clicável para a tela dedicada. No hover, o título muda de cor e uma seta (→) aparece ao lado. Justificativa de workflow: Este painel atende aos touchpoints 'Assinar prescrições pendentes' e 'Confirmar que a prescrição foi revisada por um médico antes da administração ao paciente' (Workflow 3). O botão 'Assinar' abre a tela de assinatura com a prescrição completa porque é responsabilidade do médico saber o que está assinando — a assinatura não pode ser um clique direto sem revisão. Os chips de urgência (vermelho/laranja) refletem que, no workflow, a prioridade é cronológica: quanto menos tempo até a aplicação, mais urgente — e essa lógica vale igualmente para prescrições pendentes de assinatura e de revisão (RN-CM-020), já que ambas representam risco crescente conforme a aplicação se aproxima. A prescrição completa é sempre exibida para revisão porque o médico precisa validar o que está confirmando, não apenas um resumo. O retorno automático à Central após assinar ou revisar reflete que o médico precisa voltar ao seu fluxo de trabalho sem navegação manual. O toggle "Meus/Todos" atende ao touchpoint 'Ao revisar prescrições': no workflow, o médico prioriza naturalmente seus próprios pacientes, mas precisa poder ajudar a revisar as de colegas ausentes — daí a possibilidade de alternar sem sair da tela. Estado vazio: Quando não há prescrições pendentes para exibir no toggle ativo, exibir ícone de check com a mensagem correspondente ao toggle — `MSG_prescriptionNoneMine` (toggle 'Meus') ou `MSG_prescriptionNoneAll` (toggle 'Todos'). Critérios de Aceitação: - Dado que uma prescrição possui 10 horas restantes para aplicação, então o sistema deve renderizar o chip de tempo com fundo `color-error-light`, sem contorno, texto e ícone `triangle-alert` em `color-error-dark`, e o KPI de Alertas deve exibir o valor em vermelho. - Dado que uma prescrição possui 18 horas restantes, então o sistema deve renderizar o chip com fundo `color-highlight-light`, sem contorno, texto e ícone `clock` em `color-highlight-dark`. - Dado que uma prescrição possui 30 horas restantes para aplicação, então o sistema não deve renderizar chip — apenas o texto do tempo restante, sem fundo colorido (RN-CM-011). - Dado que o médico clica em "Assinar" em uma prescrição, então o sistema deve abrir a tela de assinatura com a prescrição completa para revisão. - Dado que o médico clica em "Assinar" na tela de assinatura, quando a assinatura é validada (via certificado ou sessão, conforme configuração), então o sistema deve exibir toast de sucesso, retornar automaticamente à Central do Médico focada no painel de Prescrições Pendentes, e o número de "P/assinar" do KPI de Alertas deve diminuir em uma unidade (e o de "Urgentes", se a prescrição era urgente) — inclusive quando a aplicação está dentro da janela de revisão, pois a assinatura feita depois de a janela abrir dispensa a revisão (D-CM-040). - Dado que o médico clica em "Assinar" na tela de assinatura e a assinatura falha, então o sistema deve exibir um toast de erro na tela de assinatura: "Falha na validação da assinatura. Verifique seu certificado ou tente novamente." - Dado que uma prescrição já assinada (em qualquer momento) tem aplicação agendada dentro da janela de antecedência de revisão configurada para a clínica, ainda não foi revisada, não tem assinatura feita depois de a janela abrir (D-CM-040) e não teve a administração iniciada (D-CM-039), então o sistema deve marcá-la automaticamente como "a revisar" e exibi-la no painel com ação "Revisar" (RN-CM-020) — não há mais verificação de validade/vencimento da assinatura. - Dado que a clínica não tem a janela de antecedência de revisão configurada, então o sistema deve assumir 1 dia como valor-padrão (RN-CM-020). - Dado que a clínica não tem a janela de antecedência de assinatura configurada, então o sistema deve assumir 7 dias como valor-padrão (RN-CM-020). - Dado que uma prescrição nunca foi assinada e tem aplicação agendada além do fim do 7º dia de calendário seguinte a hoje (fora da janela de antecedência de assinatura, D-CM-037), então o sistema não deve exibi-la em nenhuma das duas listas. - Dado que uma prescrição já assinada (em qualquer momento, mesmo há muitos meses) nunca recebeu confirmação de revisão e sua aplicação agendada está além da janela de antecedência de revisão (mais distante no futuro), então o sistema não deve exibi-la em nenhuma das duas listas até a aplicação entrar na janela — não há mais um mecanismo de "assinatura vencida" que a devolva à lista de assinatura. - Dado que uma prescrição nunca assinada, ou assinada e ainda não revisada, tem a hora de aplicação já passada, então o sistema deve mantê-la na lista ("a assinar" ou "a revisar"), com o atraso (ex: "3h00 atrasada") e o chip vermelho, e deve contá-la em "Urgentes" até que seja assinada ou revisada (RN-CM-011). - Dado que uma prescrição está com `Situacao` em `Q` (Confirmada/Finalizada), `F` (Faturada), `E` (Atendimento Externo) ou `C` (Cancelada), então o sistema não deve exibi-la em nenhuma das duas listas, mesmo que nunca tenha sido assinada ou revisada. - Dado que a janela de antecedência de revisão é a padrão (1 dia), hoje é o dia 10 às 12h e uma prescrição já assinada e ainda não revisada tem aplicação no dia 11 às 23:30 (35h30 de agora), então o sistema deve exibi-la no painel com ação "Revisar" e sem chip de urgência (RN-CM-011, RN-CM-020). - Dado que a janela é a padrão (1 dia) e hoje é o dia 10, então uma prescrição já assinada e não revisada com aplicação no dia 12 às 00:00 não deve aparecer em "a revisar" nem no número "P/revisar"; ela passa a aparecer à 00:00 do dia 11 (D-CM-023). - Dado que a clínica configurou a janela de antecedência de revisão em 2 dias, hoje é o dia 10 às 12h e uma prescrição assinada e não revisada tem aplicação no dia 12 às 09:00, então o sistema deve exibi-la no painel com ação "Revisar" (D-CM-023). - Dado que a janela de revisão é a padrão (1 dia), hoje é o dia 10 e uma prescrição com aplicação no dia 11 foi assinada no dia 10 às 08:00 (a janela dessa prescrição abre no dia 10 às 00:00), então ela não aparece em "a revisar" nem no número "P/revisar" — a assinatura feita depois de a janela abrir dispensa a revisão (D-CM-040, E-CM-019). Se a assinatura for de antes de 00:00 do dia da aplicação menos N (no fuso da clínica) — por exemplo, assinada no dia 9 às 23:00 para uma aplicação no dia 11 —, a prescrição continua em "a revisar". Com aplicação no dia 10, a janela abre no dia 9 às 00:00. - Dado que uma prescrição "a revisar" tem a administração iniciada (`Agenda.DhInfusaoIniUTC` preenchido), então ela sai de "a revisar" e do número "P/revisar" (D-CM-039, E-CM-018). - Dado que uma prescrição "a assinar" tem a administração iniciada, então ela permanece em "a assinar" e conta em "P/assinar" — sem assinatura em procedimento é falha grave de processo e continua visível (D-CM-039, D-CM-033). - Dado que a clínica configurou a janela de assinatura em 3 dias, hoje é o dia 10 e uma prescrição nunca assinada tem aplicação no dia 13 às 23:00, então ela aparece em "a assinar"; com aplicação no dia 14 às 00:00, não aparece (D-CM-037). - Dado que uma prescrição está atrasada há 45 minutos, 3 horas, 59 horas e 30 dias, então os textos são "45min atrasada", "3h00 atrasada", "2 dias atrasada" e "30 dias atrasada"; e faltando 45 minutos ou 8 horas, "45min restantes" e "8h restantes" (D-CM-041). - Dado que duas prescrições têm o mesmo `minutesRemaining`, então a do paciente cujo nome vem primeiro na ordem alfabética aparece primeiro; se o nome for o mesmo, a de menor `id` (D-CM-047, E-CM-027). - Dado que o médico atende em duas clínicas, então as prescrições das duas aparecem no painel e em "Alertas de Prescrição", cada card com o nome da clínica; com uma só clínica, o nome não aparece (D-CM-066, E-CM-028, E-CM-029). - Dado que o cliente tem três clínicas (A, B e C) e o médico atende em A e B, então as prescrições da clínica C não aparecem no painel, nem com o toggle "Todos", e não entram em "Alertas de Prescrição" (D-CM-066). - Dado que o médico troca de clínica e, com isso, de cliente, então todos os painéis e indicadores passam a mostrar as clínicas em que ele atende no novo cliente, e nada do cliente anterior (D-CM-066, DT-013). - Dado que a clínica A do cliente configurou a janela de assinatura em 3 dias, a clínica B em 7 dias, hoje é o dia 10 e as duas têm uma prescrição nunca assinada com aplicação no dia 15, então a da clínica B aparece em "a assinar" e a da clínica A não (cada prescrição segue o parâmetro da própria clínica; D-CM-060). - Dado que o médico está logado numa clínica de fuso −03:00, o cliente tem outra clínica de fuso −04:00, a janela de revisão é de 1 dia, hoje é o dia 10 e uma prescrição já assinada e ainda não revisada, da clínica de fuso −04:00, tem aplicação no dia 12 às 00:30 (horário −03:00; dia 11 às 23:30 no relógio dela), então ela não aparece em "a revisar": o fim do dia 11 é medido no fuso da clínica logada (D-CM-062). - Dado que uma prescrição já assinada, que dispensou a revisão por ter sido assinada dentro da janela, é reagendada para depois do limite, então ela não volta a "a assinar" (não precisa ser assinada de novo) e só aparece em "a revisar" quando a nova data entrar na janela de revisão (D-CM-052, D-CM-059). - Dado que o médico edita uma prescrição e grava, então a versão anterior fica cancelada e sai da lista, e a nova versão aparece em "a assinar", sem nenhuma assinatura; ao assiná-la dentro da janela de revisão, ela sai da lista (D-CM-050, D-CM-052, D-CM-040). - Dado que o médico clica em "Revisar", então o sistema deve abrir a prescrição completa, permitindo confirmar a revisão ("Marcar como Revisada") ou editar a prescrição. - Dado que o médico clica em "Marcar como Revisada", então o sistema deve registrar o médico revisor e o timestamp, exibir toast de sucesso, remover a prescrição da lista de pendentes e retornar automaticamente à Central do Médico focada no painel de Prescrições Pendentes. - Dado que o médico edita a prescrição na tela de revisão e clica em "Gravar", então o sistema deve cancelar a prescrição atual, criar uma nova versão com os itens ajustados e exigir que o médico assine essa nova versão (mesmo fluxo de assinatura), retornando automaticamente à Central do Médico focada no painel de Prescrições Pendentes após a assinatura. - Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada de Prescrições Pendentes. - Dado que o toggle está em 'Meus' e não há prescrições pendentes (nem a assinar nem a revisar em que o médico logado é o prescritor ou o médico assistente), então o painel deve exibir "Sem prescrições pendentes para você" (`MSG_prescriptionNoneMine`). - Dado que o toggle está em 'Todos' e não há prescrições pendentes (nem a assinar nem a revisar de nenhum médico das clínicas em que o médico logado atende), então o painel deve exibir "Sem prescrições pendentes" (`MSG_prescriptionNoneAll`). - Dado que a prescrição tem protocolo "CARBO-TAXOL" no Ciclo 3, Dia 1, então o sistema deve exibir o código da prescrição como recebido do endpoint (`prescriptionCode`), ex: "CARBO-TAXOL C3D1", sem remontar a string a partir de campos separados. - Dado que o card de prescrição exibe a data da agenda, então o formato deve ser "dd/MM HH:mm" (ex: "22/07 18:00"). - Dado que o painel é carregado, então o toggle "Meus/Todos" deve iniciar na posição "Meus". - Dado que o médico ativa o toggle "Meus", então o painel deve exibir apenas as prescrições — a assinar e a revisar — em que o médico logado é o prescritor ou o médico assistente do paciente. - Dado que o médico ativa o toggle "Todos", então o painel deve exibir todas as prescrições, tanto a assinar quanto a revisar, de qualquer médico, nas clínicas em que o médico logado atende (D-CM-066). Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | | -------------------- | ------------------------- | ------------------------ | ----------------------------- | | painel-título | Prescrições Pendentes | Pending Prescriptions | Prescripciones Pendientes | | botão-assinar | Assinar | Sign | Firmar | | botão-revisar | Revisar | Review | Revisar | | MSG_prescriptionNoneMine | Sem prescrições pendentes para você | No pending prescriptions for you | Sin prescripciones pendientes para usted | | MSG_prescriptionNoneAll | Sem prescrições pendentes | No pending prescriptions | Sin prescripciones pendientes | | presc-restante | {h}h restantes | {h}h left | {h}h restantes | | presc-restante-min | {m}min restantes | {m}min left | {m}min restantes | | presc-atrasada-hm | {h}h{mm} atrasada | {h}h{mm} overdue | {h}h{mm} de atraso | | presc-atrasada-dias | {d} dias atrasada | {d} days overdue | {d} días de atraso | | presc-atrasada-min | {m}min atrasada | {m}min overdue | {m}min de atraso | | MSG_prescriptionSigned | Prescrição assinada com sucesso | Prescription signed successfully | Prescripción firmada con éxito | | MSG_prescriptionSignError | Falha na validação da assinatura. Verifique seu certificado ou tente novamente. | Signature validation failed. Check your certificate or try again. | Fallo en la validación de la firma. Verifique su certificado o intente nuevamente. | | toggle-meus | Meus | Mine | Míos | | toggle-todos | Todos | All | Todos | --- ### 2.5 Painel de Mensagens (Quadrante Inferior Esquerdo) > Modelo de dados de Conversas e Alertas (`IP.Mensageria`, ver documento "Conversas-e-Alertas"): o que seria uma "mensagem" avulsa é uma `Conversa` (thread), que pode acumular várias `Mensagem` — o médico pode responder, não só resolver/descartar. **Escopo do painel:** este painel compacto do Cockpit mostra todas as conversas em aberto do médico logado, das clínicas em que ele atende (D-CM-066) — lidas e não lidas —, priorizando as não lidas na ordenação (critério de desempate dentro de cada camada em "Ordenação", abaixo); uma conversa só deixa de aparecer aqui quando é resolvida ou descartada. Uma tela dedicada, ainda não especificada neste documento, mostrará também as conversas já finalizadas (resolvidas ou descartadas), formando o histórico completo. US-CM-007 — Receber conversas e alertas internos Como médico, quero ver conversas e alertas da equipe (recepção, farmácia, enfermagem) e do próprio sistema, ordenados por prioridade, para responder solicitações e recados sem precisar acessar outra tela. US-CM-008 — Arquivar conversa resolvida Como médico, quero marcar uma conversa como resolvida ou descartá-la com um botão e uma confirmação, para manter minha lista enxuta e o foco nas pendentes. US-CM-012 — Responder rapidamente Como médico, quero responder uma conversa com uma frase curta direto do Cockpit, para esclarecer algo simples sem precisar telefonar ou sair do meu fluxo de trabalho. Descrição Funcional: O painel de Mensagens exibe todas as `Conversa` do médico logado que ainda não estão em estado final (`Status` diferente de `Resolvida` e `Descartada`), estejam **lidas ou não lidas** para ele (ver definição de "não lida" em RN-CM-015). Ler uma conversa (abrir o modal, ou responder) não a remove do painel — ela permanece visível, mas passa para o grupo de prioridade reduzida na ordenação (ver "Ordenação" abaixo), perdendo o destaque visual de não lida. Motivador: uma conversa aberta ainda pode estar pendente de alguma ação do médico (resolver, descartar, aguardar retorno) mesmo depois de lida — escondê-la do painel faria o médico perder o rastro dela até a próxima atividade, obrigando-o a confiar na memória para lembrar do que ficou em aberto. O histórico completo (incluindo as já resolvidas/descartadas) continua reservado à tela dedicada mencionada acima. Uma conversa chega ao médico de duas formas: enviada diretamente a ele (`Conversa.IdUsuarioDestino`, quando `DestinoTipo = 'User'`), ou enviada a uma equipe da qual ele é membro (`Conversa.EquipeId`, quando `DestinoTipo = 'Team'`; o vínculo individual de cada destinatário fica registrado em `ConversaDestinatario.EquipeOrigemId`). Cada card contém: - Ícone identificador: bell da biblioteca Lucide para alertas automáticos (`OrigemTipo = 'System'`); ícone genérico de pessoa para qualquer conversa aberta por um usuário (`OrigemTipo = 'User'`), seja ela endereçada a um indivíduo ou a uma equipe. O ícone não varia por equipe (recepção/farmácia/enfermagem) — quando o autor responde como membro de uma equipe, a identificação vem do texto do nome (item abaixo, e RN-CM-022), não de um ícone diferente. - Linha 1: assunto da conversa (`Conversa.Assunto`), em uma linha, truncado com reticências; à direita, o horário relativo da última mensagem (ex.: "Há 15 min"). Quando a última mensagem é do médico logado (nunca num alerta do sistema), vem antes do horário o aviso de leitura: ícone Lucide `check` (enviada: nenhum outro participante leu até ela; `color-neutral-pure`) ou `check-check` (lida por pelo menos um dos outros participantes; `color-secondary-dark`), de 16px, com o rótulo "Enviada" ou "Lida" para leitor de tela e como dica; a forma, e não só a cor, distingue os dois. Num autoenvio (o médico é o único participante), `check-check` desde o envio. O horário é relativo ao momento atual, no fuso da clínica (RN-CM-015; RN-MSG-035; D-CM-088): no mesmo dia e há menos de 1 hora, `msg-ha-min` ("Há x min"); no mesmo dia, `msg-ha-h` ("Há x h"); em dia anterior, data e hora no formato do idioma da clínica. **[PROPOSTA, E-CM-051]:** x é o inteiro por truncamento, com mínimo de 1 min; o texto é recalculado a cada atualização automática de 1 minuto, com o horário do servidor (`serverNow`) e não o do aparelho. O modal mostra sempre data e hora. - Linha 2: "autor: texto da última mensagem", em uma linha, truncada com reticências. A última mensagem não é necessariamente a inicial — se a equipe respondeu depois do médico, o card mostra a resposta mais recente. O autor é "Você" quando é o médico logado, "Sistema" nos alertas automáticos e o nome de quem escreveu nos demais casos. Quando quem escreveu é membro de uma equipe respondendo em nome dela (conversa endereçada à equipe — `DestinoTipo = 'Team'`, autor membro dessa `Equipe`), o nome da equipe aparece junto, em toda mensagem dela, não só na primeira (ex.: "Sandra (Farmácia): Medicamento Carboplatina em falta.") — RN-CM-015, RN-CM-022 - Grau de urgência (D-CM-088, RN-MSG-034): quando a conversa tem grau (`Conversa.GrauUrgencia`; chaves `routine`, `urgent`, `asap`, `stat`), chip só com o nome (Rotina, Urgente, Quanto antes ou Imediato), com ícone Lucide `flag` de 14px, na linha do prazo e antes dele, com título e nome acessível "Grau de urgência: {nome}" (`msg-grau-titulo`). Cores da seção 13 do Design System: Imediato sólido (`--color-alert-fill`, texto `--color-base-pure`, `flag` preenchida); Quanto antes com fundo `--color-error-light`, texto `--color-error-dark` e contorno de 1px; Urgente `--color-neutral-lighter` com texto `--color-neutral-dark`; Rotina transparente com contorno de 1px `--color-neutral-light`. Rotina também aparece. Sem grau, nada é exibido. O nome vem traduzido da API; o grau não muda depois do envio. É outro sentido do que o chip "Crítico"/"Atenção" da prescrição (D-CM-046), que segue leve. - Prazo (opcional): quando `Conversa.PrazoEmUtc` está definido, exibir no card (ex: ícone Lucide `clock` + "Responder até 14:00") - Quando `Conversa.IdPaciente` está definido, um link com o nome do paciente relacionado, permitindo abrir o contexto clínico diretamente (o painel não concede acesso ao prontuário por si só — a autorização continua sendo validada pelo módulo de destino, conforme a fronteira de responsabilidade do IP.Mensageria) - Clínica (D-CM-064, RN-CM-032, E-CM-033): nome curto da clínica de origem da conversa, no mesmo formato (texto de 12px `color-neutral-pure`, ícone Lucide `building-2` de 14px, sem chip), com a mesma regra dos demais cards: só aparece quando o médico atende em mais de uma clínica (D-CM-066). O painel reúne as conversas do médico das clínicas em que ele atende; conversa de clínica em que ele não atende não aparece. Conversas não lidas: Uma conversa está não lida para o médico logado quando `Conversa.UltimaSequencia > ConversaLeitura.UltimaSequenciaLida` (ou quando não existe `ConversaLeitura` para ele ainda) — essa condição não filtra quais conversas aparecem no painel (todas as não finalizadas aparecem, lidas ou não), mas determina dois efeitos: (a) o destaque visual — ícone e borda lateral esquerda em `color-secondary-dark` (contraste ≥ 3:1 sobre o card nos dois temas: 6,1:1 no claro, 11,1:1 no escuro), aplicados somente aos cards não lidos; cards já lidos usam a borda neutra padrão (transparente) e o ícone na cor neutra; (b) a camada de prioridade na ordenação (ver "Ordenação" abaixo). Ao abrir o modal da conversa, o sistema grava `ConversaLeitura.UltimaSequenciaLida = Conversa.UltimaSequencia` para aquele médico; o card perde o destaque visual e migra para a camada de prioridade reduzida na próxima atualização da lista, mas **permanece no painel** — para os demais membros de uma equipe, o indicador de não lida permanece intacto (leitura é individual). Não é utilizado negrito no texto — a distinção visual vem exclusivamente do ícone colorido e da borda lateral (RN-CM-019). Ordenação: As conversas são ordenadas em duas camadas. Primeiro, por estado de leitura: todas as conversas **não lidas** aparecem antes de todas as **lidas** — uma conversa lida nunca aparece à frente de uma não lida. Dentro de cada camada, vem primeiro o grau de urgência (Imediato, Quanto antes, Urgente, Rotina e, por último, sem grau; D-CM-088) e, dentro do mesmo grau, a conversa de data mais recente, e a data de cada conversa é a mais recente entre o envio da última mensagem e o prazo (`PrazoEmUtc`, quando definido); em caso de empate, vem primeiro a conversa criada mais recentemente. É a regra da tela de Mensagens (RN-MSG-002), e a lista já vem ordenada do servidor (Seção 4.8). Efeito conhecido: uma conversa com prazo distante fica no topo da sua camada, e uma vencida desce abaixo das mensagens novas (risco registrado na Mensageria, P-MSG-27). Ação no card (D-CM-089): o card não tem botão de ação; o clique abre o modal, e "Resolvido" e "Descartado" ficam só dentro dele, para que a leitura venha antes de encerrar, em especial nos alertas do sistema. "Resolvido", depois de uma confirmação (abaixo), muda `Conversa.Status` para `Resolvida`, removendo o card da lista. O contador do painel deve ser atualizado. Isso é uma mudança de estado, não uma exclusão — a conversa continua existindo no histórico da conversa, só sai da visão de pendentes. Vale para todos os destinatários: o estado pertence à conversa, não ao médico; se a conversa foi endereçada a uma equipe ou a mais de uma pessoa, ela sai do painel de todas quando qualquer uma a resolve ou descarta. Confirmação ao resolver ou descartar (D-CM-032, E-CM-021): "Resolvido" e "Descartado", no modal, abrem antes uma caixa de confirmação (`role="alertdialog"`, foco inicial em "Cancelar", Esc cancela) que informa que a ação vale para todos os destinatários: título "Resolver conversa?" / "Descartar conversa?", texto "A conversa será marcada como resolvida para todos os destinatários." / "A conversa será descartada para todos os destinatários.", botões "Cancelar" e "Resolver" / "Descartar" (textos em Internacionalização). Só a confirmação altera o status. Continua sem "desfazer" (D-CM-014). Ação ao clicar no card: Ao clicar no card, o sistema abre um modal com a thread completa (todas as `Mensagem` da conversa, em ordem, cada uma com autor e timestamp), o prazo (se houver) e três ações: - Campo de texto + botão "Responder" — envia uma nova `Mensagem` (`Tipo` = `'Response'`), atualiza `Conversa.UltimaSequencia` e muda `Status` para `'Responded'`. A conversa permanece na lista (responder não é uma ação terminal) — o médico pode continuar acompanhando até que a equipe confirme ou até resolver/descartar. - "Resolvido" — depois da confirmação, muda `Conversa.Status` para `Resolvida`. - "Descartado" — depois da confirmação, muda `Conversa.Status` para `Descartada`. Isso **não exclui** a conversa (o modelo de dados é append-only e preserva o histórico da conversa; não há "desfazer" — a conversa é uma ferramenta de comunicação) — apenas sai da lista de pendentes, com o mesmo efeito visual de "Resolvido" para o médico — e, como em "Resolvido", vale para todos os destinatários da conversa. Motivador: o descarte permite remover conversas informativas ou irrelevantes que não exigem resposta, sem marcá-las como resolvidas — a distinção fica registrada no histórico da conversa. Conversas do sistema (alertas automáticos): Geradas por módulos da plataforma (ex: Prescrição, Infusão, Agenda) via `AlertaPublicacao`, com chave de idempotência garantindo que retries não dupliquem o alerta. Usam o ícone bell da biblioteca Lucide e seguem as mesmas regras de ordenação, destaque de não lidas e ações — exceto "Responder", que não se aplica a alertas puramente informativos sem um destinatário humano do outro lado (o front deve ocultar o campo de resposta quando `OrigemTipo = 'System'`, mantendo apenas Resolvido/Descartado). O remetente exibido é "Sistema". Se a mesma anomalia recorrer depois que a conversa anterior foi resolvida ou descartada, uma nova `Conversa` é criada apontando para a anterior via `ConversaAnteriorId` — o médico vê um alerta novo, não a reabertura do antigo. Padrão de internacionalização (i18n) para mensagens do sistema: As mensagens geradas pelo sistema devem ser documentadas com suas versões em português (pt-BR), inglês (en-US) e espanhol (es-419), conforme tabela padrão abaixo: | Código da mensagem | pt-BR | en-US | es-419 | | -------------------- | -------------------------------------------------------------- | ------------------------------------------------------------------- | ----------------------------------------------------------------- | | SYS_PRESC_URGENT | Prescrição urgente: menos de 12h para aplicação de {paciente}. | Urgent prescription: less than 12h until application for {patient}. | Prescripción urgente: menos de 12h para aplicación de {paciente}. | | SYS_PRESC_REVIEW | Prescrição de {paciente} pendente de revisão antes da aplicação. | Prescription for {patient} pending review before application. | Prescripción de {paciente} pendiente de revisión antes de la aplicación. | | SYS_INFUSION_DELAY | Infusão de {paciente} ultrapassou o tempo previsto. | Infusion for {patient} exceeded expected time. | Infusión de {paciente} superó el tiempo previsto. | | SYS_PATIENT_CHECKIN | {paciente} fez check-in na recepção. | {patient} checked in at reception. | {paciente} hizo check-in en recepción. | | SYS_SESSION_REMINDER | Lembrete: {paciente} tem sessão prevista para {horario}. | Reminder: {patient} has session scheduled for {time}. | Recordatorio: {paciente} tiene sesión programada para {horario}. | Convenções da tabela: - Variáveis entre chaves {} são substituídas dinamicamente pelo sistema - O código da mensagem (SYS_*) é usado internamente para identificação e não é exibido ao usuário - Cada mensagem de sistema corresponde ao `Conteudo` da `Mensagem` inicial de uma `Conversa` com `OrigemTipo = 'System'` - Novas mensagens do sistema devem ser adicionadas a esta tabela como padrão de documentação - A tradução é feita no backend, no idioma da clínica atual (`ClienteEmpresa.IdiomaOficial`; DT-012); o frontend recebe a mensagem já traduzida Navegação: O título do painel ('Mensagens') é um link clicável para a tela dedicada de Mensagens. No hover, o título muda de cor e uma seta (→) aparece ao lado. Justificativa de workflow: Este painel atende aos touchpoints 'Receber conversas e alertas da equipe' e 'Responder sem sair do Cockpit' (Workflow 4). O painel manter conversas lidas visíveis, mas em prioridade reduzida, reflete que, neste espaço compacto do Cockpit, o médico precisa ver "o que está pendente de atenção agora" sem perder de vista o que já leu mas ainda não encerrou — uma conversa já lida deixa de competir pela atenção imediata dele, mas continua acessível até ser resolvida ou descartada, evitando que ele precise confiar na memória para lembrar do que ficou em aberto. O destaque visual e a prioridade das não lidas refletem que, no workflow, conversas não lidas são as pendências que mais competem com a atenção do médico agora. A data de cada conversa considera o prazo, quando existe, porque conversas com prazo são compromissos no workflow. O campo de resposta no modal reflete que muitas dúvidas simples podem ser resolvidas com uma frase, sem justificar uma tela de chat separada. 'Resolvido' fica só no modal (D-CM-089): os críticos de UX e do médico concluíram que um botão no card ensina que encerrar é o único caminho e permite resolver, para toda a equipe e sem desfazer, um alerta que ninguém leu. O grau de urgência aparece no card porque, no workflow, o médico precisa ver o que não pode esperar antes de abrir (D-CM-088). O botão 'Descartado' reflete que algumas conversas são puramente informativas e não exigem resposta — o médico precisa removê-las da lista sem marcá-las como resolvidas. Estado vazio: Quando não há nenhuma conversa não finalizada (lida ou não lida) para o médico logado, exibir ícone de balão vazio com a mensagem `MSG_notificationNone`. Conversas já lidas, mas ainda em aberto, contam como conteúdo do painel — não disparam o estado vazio. Critérios de Aceitação: - Dado que chega uma nova conversa da farmácia, quando os dados são atualizados, então o card deve aparecer com o ícone e a borda lateral esquerda na cor `color-secondary-dark` (sem negrito no texto). - Dado que o médico abre o modal de uma conversa não lida, então o sistema deve gravar `ConversaLeitura.UltimaSequenciaLida = Conversa.UltimaSequencia` para aquele médico, e o card deve perder o destaque visual de não lida e migrar para depois das conversas não lidas na atualização seguinte da lista — sem sair do painel. - Dado que duas conversas estão na mesma camada de leitura, então vem primeiro a de maior grau (Imediato, Quanto antes, Urgente, Rotina, sem grau) e, com o mesmo grau, a de data mais recente, sendo a data de cada uma a mais recente entre a última mensagem e o prazo (quando existe); em caso de empate, vem primeiro a conversa criada mais recentemente. - Dado um card de conversa, então a linha 1 mostra o assunto (truncado com reticências quando não cabe) e o horário relativo à direita, e a linha 2 mostra "autor: texto da última mensagem", com "Você" quando o autor é o médico logado. - Dado uma conversa com grau de urgência (inclusive `routine`), então o card mostra o chip com o nome do grau, o ícone `flag` e o título "Grau de urgência: {nome}"; sem grau, não mostra chip (D-CM-088). - Dado uma conversa cuja última mensagem foi enviada hoje há menos de 1 hora, então o card mostra "Há x min"; hoje há 1 hora ou mais, "Há x h"; em dia anterior, data e hora no fuso da clínica (D-CM-088). - Dado o card de uma conversa (de pessoa ou do sistema), então ele não tem botão de ação; só o modal oferece "Resolvido" e "Descartado" (D-CM-089). - Dado que a última mensagem da conversa é do médico logado, então o card mostra `check` antes do horário enquanto nenhum outro participante a leu e `check-check` quando pelo menos um leu (num autoenvio, `check-check` desde o envio); quando a última mensagem é de outra pessoa ou do sistema, o card não mostra o ícone. - Dado que existem conversas lidas e não lidas ao mesmo tempo, quando a lista é renderizada, então todas as não lidas devem aparecer antes de todas as lidas, independentemente de prazo ou atividade. - Dado que o médico digita uma resposta no modal e clica em "Responder", então o sistema deve gravar uma nova mensagem na thread, mudar o status da conversa para "Respondida", marcar a conversa como lida para o médico (a própria resposta conta como leitura) e migrá-la para a camada de prioridade reduzida do painel, sem removê-la — a menos que já exista atividade não vista por ele antes da resposta, caso em que ela permanece na camada de não lidas. - Dado que uma conversa já foi respondida pelo médico e uma nova mensagem chega depois disso, então a conversa deve retornar à camada de não lidas do painel (destaque visual restaurado), mostrando a mensagem nova e o autor dela, sem selo de estado. - Dado que o médico abre o modal e clica em "Resolvido", então o sistema deve abrir a confirmação "Resolver conversa?" informando que vale para todos os destinatários, com o foco em "Cancelar"; ao confirmar, o status da conversa deve mudar para "Resolvida", o card deve ser removido da lista e o contador do painel deve ser atualizado (D-CM-032). - Dado que a confirmação de resolver ou descartar está aberta e o médico clica em "Cancelar" ou aperta Esc, então nada muda: a conversa permanece na lista com o mesmo status (D-CM-032). - Dado que o médico clica no card de uma conversa, então o sistema deve abrir um modal com a thread completa, contendo o campo de resposta e os botões "Resolvido" e "Descartado". - Dado que o médico clica em "Descartado" no modal, então o sistema deve abrir a confirmação "Descartar conversa?"; ao confirmar, o status da conversa deve mudar para "Descartada" (sem excluir o registro), o card deve ser removido da lista e o contador do painel deve ser atualizado. - Dado que a conversa é um alerta automático (`OrigemTipo = 'System'`), então o modal não deve exibir o campo de resposta, apenas "Resolvido" e "Descartado". - Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada de Comunicação/Mensagens (tela fora do escopo desta especificação — mostrará também as conversas já finalizadas, resolvidas ou descartadas). - Dado que não há nenhuma conversa não finalizada (lida ou não lida) para o médico logado, então o painel deve exibir "Sem mensagens pendentes" (`MSG_notificationNone`). - Dado que o médico enviou (ou recebeu) uma conversa endereçada à equipe de Farmácia (não a uma pessoa específica), quando Sandra — membro dessa equipe — responde pela thread, então tanto o card quanto o modal da thread completa devem exibir "Sandra (Farmácia)" como autor da mensagem, em vez de apenas "Sandra", em toda mensagem que ela escrever nessa conversa (não só na primeira resposta). - Dado que Carla — que não é membro da equipe de destino da conversa — responde numa conversa endereçada a um indivíduo (não a uma equipe), então o card e o modal devem exibir apenas "Carla", sem sufixo de equipe. - Dado que o médico atende em duas clínicas e tem uma conversa aberta originada em cada uma, então o painel mostra as duas na mesma lista, na ordem de RN-CM-015, cada card com a linha de clínica (ícone `building-2` e nome curto); com uma só clínica, nenhum card mostra o nome (D-CM-066, D-CM-064). - Dado que o médico abre e responde a conversa originada na segunda clínica, então o modal e a resposta funcionam como nos demais cards, e a nova mensagem é gravada na clínica de origem da conversa (4.9). Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | | -------------------- | -------------------------- | ------------------------ | ----------------------------- | | painel-título | Mensagens | Messages | Mensajes | | botão-resolvido (modal) | Resolvido | Resolved | Resuelto | | msg-ha-min | Há {n} min | {n} min ago | Hace {n} min | | msg-ha-h | Há {n} h | {n} h ago | Hace {n} h | | msg-grau-titulo | Grau de urgência: {name} | Urgency level: {name} | Grado de urgencia: {name} | | botão-descartado | Descartado | Discarded | Descartado | | botão-responder | Responder | Reply | Responder | | placeholder-resposta | Escreva uma resposta... | Write a reply... | Escriba una respuesta... | | msg-voce | Você | You | Usted | | msg-enviada | Enviada | Sent | Enviada | | msg-lida | Lida | Read | Leída | | label-há | Há T | T ago | Hace T | | label-prazo-responder | Responder até T | Reply by T | Responder antes de T | | MSG_notificationNone | Sem mensagens pendentes | No pending messages | Sin mensajes pendientes | | MSG_conversationResolved | Conversa marcada como resolvida | Conversation marked as resolved | Conversación marcada como resuelta | | MSG_conversationDiscarded | Conversa descartada | Conversation discarded | Conversación descartada | | MSG_replySent | Resposta enviada | Reply sent | Respuesta enviada | | MSG_resolveConfirmTitle | Resolver conversa? | Resolve conversation? | ¿Resolver la conversación? | | MSG_resolveConfirmBody | A conversa será marcada como resolvida para todos os destinatários. | The conversation will be marked as resolved for all recipients. | La conversación se marcará como resuelta para todos los destinatarios. | | MSG_resolveConfirmOk | Resolver | Resolve | Resolver | | MSG_discardConfirmTitle | Descartar conversa? | Discard conversation? | ¿Descartar la conversación? | | MSG_discardConfirmBody | A conversa será descartada para todos os destinatários. | The conversation will be discarded for all recipients. | La conversación se descartará para todos los destinatarios. | | MSG_discardConfirmOk | Descartar | Discard | Descartar | | MSG_confirmCancel | Cancelar | Cancel | Cancelar | --- ### 2.6 Painel Pacientes em procedimento (Quadrante Inferior Direito) US-CM-009 — Monitorar procedimentos na clínica Como médico, quero ver todos os pacientes presentes na unidade com seus status e localização, para planejar visitas e saber quem está disponível para atendimento. US-CM-010 — Acompanhar tempo de atendimento Como médico, quero ver o progresso do atendimento de pacientes em tratamento com barra de tempo, para saber quanto tempo já passou e se está dentro do previsto. US-CM-011 — Filtrar meus pacientes na clínica Como médico, quero filtrar a lista de pacientes na clínica para mostrar apenas os meus, para me concentrar nos pacientes sob minha responsabilidade. Descrição Funcional: O painel Pacientes em procedimento monitora pacientes previstos e presentes na unidade para procedimentos terapêuticos e diagnósticos (infusões, aplicações, checagens) — não inclui consultas médicas, apenas procedimentos. Cada card de paciente contém: - Nome do paciente com avatar, seguido do ícone de 1ª Consulta quando `firstTime` é verdadeiro (RN-CM-028, D-CM-029) — o mesmo ícone, a mesma dica e a mesma regra de teclado do painel de Consultas - Prescrição do procedimento (ex: "AC-T C2D14", "Paclitaxel C1D8") - Local na clínica (ex: "Consultório 4", "Sala de Infusão 2") - Clínica (D-CM-066, D-CM-061): nome curto da clínica do procedimento, no mesmo formato, com a mesma regra de exibição e o mesmo ícone dos cards de consulta e de prescrição (`building-2`, 12px `color-neutral-pure`), só quando o médico atende em mais de uma clínica. O painel e o indicador reúnem os procedimentos das clínicas em que o médico atende. - Status do procedimento (Agendado, Aguardando recepção, Recepcionado, Em preparo, Em aplicação, Completo, Finalizado ou Cancelado — domínio e ordem de avaliação em `ProcedureStatus()`, Seção 4.3/4.4; vale a primeira condição que se aplica, D-CM-030), exibido como chip colorido, como no painel de Consultas: classe `.chip-status` com as cores de `status.colors` e o texto de `status.name` (já no idioma da clínica; os nomes desta lista são os de referência em pt-BR); sem `colors`, o chip fica neutro. O chip fica na linha 2 do card, entre o local e as tags, e o horário entre parênteses vem logo depois dele, quando houver. O avatar continua neutro, sem a cor do status. "Completo" (valor de contrato `administered`) = infusão terminada (`DhInfusaoFimUTC` preenchido) e paciente ainda sem alta; "Finalizado" = alta registrada (`DhAtendimentoFimUTC` preenchido), mesmo que o fim da infusão esteja vazio - Procedimento cancelado (`canceled`): todos os textos do card ficam riscados — nome do paciente, local, tags e clínica —, exceto o chip de status ("Cancelado") e o avatar; o ícone de 1ª Consulta, a barra de progresso e o botão PEP não são texto do card e não recebem o risco. Motivador: mostrar no próprio card que o procedimento não aconteceu, como o item cancelado da Agenda do Médico. O risco não é anunciado pelo leitor de tela; o nome acessível do card já traz o status. - Horário do atendimento (quando aplicável): horário de início enquanto o procedimento não termina; a partir de Finalizado, passa a mostrar o horário de término, não mais o de início (RN-CM-026) - Tempo de aplicação previsto da prescrição (`Prescricao.TempoAplicacao`), quando aplicável — é a base da barra de progresso - Tags do paciente (se houver) Ordenação: A lista é ordenada cronologicamente pelo horário agendado do procedimento — 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). Procedimentos agendados para o mesmo horário são desempatados em ordem alfabética pelo nome do paciente (RN-CM-027). Barra de progresso: Pacientes com status 'Em aplicação' exibem uma barra de progresso inline (50px de largura, 3px de altura) na mesma linha do nome do paciente, acompanhada da porcentagem em fonte reduzida (`font-size-xs`, 10px). A barra é extremamente discreta e não ocupa uma linha separada, evitando que pareça uma divisão entre cards. O percentual é o tempo decorrido ÷ o tempo de aplicação da prescrição (`Prescricao.TempoAplicacao`, em minutos); se a prescrição não tem tempo de aplicação (vazio ou zero), o card não mostra a barra nem a porcentagem e exibe, no lugar, o texto discreto "sem tempo previsto" (D-CM-034). Se o tempo decorrido ultrapassar 100% da estimativa, a barra torna-se vermelha (cor `error-dark`, por contraste com o trilho — Seção 2.8). Motivador: a barra na linha do nome é percebida como parte do card, não como separador. O destaque visual fica reservado apenas para o estado de atraso (vermelho). Filtro 'Meus pacientes': O toggle em estilo pill (não checkbox) alterna entre 'Meus' e 'Todos'. O filtro 'Meus' está ativado por padrão. Motivador: o estilo pill é consistente com o toggle do painel de Consultas e mais discreto que um checkbox. Navegação: O título do painel ('Pacientes em procedimento') é um link clicável para a tela dedicada. No hover, o título muda de cor e uma seta (→) aparece ao lado. Ao clicar no card de paciente, o sistema abre a prescrição do procedimento (se houver). O card contém um botão separado 'PEP' para abrir o Prontuário Eletrônico. Se não houver prescrição associada, o clique no card abre diretamente o PEP. Justificativa de workflow: Este painel atende aos touchpoints 'Saber quais pacientes estão em procedimento' e 'Decidir se precisa intervir' (Workflow 2). A barra de progresso discreta reflete que, no workflow de monitoramento, o médico faz checagem periférica entre atendimentos — não precisa de detalhe, só de saber se está dentro ou fora do tempo. O clique no card abrindo a prescrição (e não o PEP) reflete que, neste momento do workflow, o médico primeiro verifica o que está sendo infundido antes de decidir se precisa do prontuário completo. O botão 'PEP' separado reflete que o prontuário é a ação secundária neste momento. Estado vazio: Quando não há pacientes para exibir no toggle ativo, exibir ícone de prédio vazio com a mensagem correspondente ao toggle — `MSG_proceduresNoneMine` (toggle 'Meus') ou `MSG_proceduresNoneAll` (toggle 'Todos'). Critérios de Aceitação: - Dado que um paciente está com status "Em aplicação", então o painel deve exibir uma barra de progresso inline na linha do nome representando o tempo decorrido vs. o tempo de aplicação previsto na prescrição. - Dado que o tempo decorrido ultrapassa 100% do tempo de aplicação previsto, então a barra de progresso deve mudar para a cor vermelha (`error-dark`). - Dado que a prescrição do procedimento não tem tempo de aplicação (vazio ou zero), então o card não deve exibir a barra de progresso nem a porcentagem e deve exibir, no lugar, o texto "sem tempo previsto" (D-CM-034). - Dado que `firstTime` é verdadeiro para o procedimento, então o card deve exibir o ícone de 1ª Consulta logo depois do nome do paciente, com a dica "1ª Consulta" ao toque ou ao mouse (RN-CM-028, D-CM-029). - Dado que um procedimento tem `DhInfusaoFimUTC` preenchido e `DhAtendimentoFimUTC` vazio, então o status deve ser "Completo" (`administered`); com `DhAtendimentoFimUTC` preenchido, "Finalizado", mesmo com `DhInfusaoFimUTC` vazio; e nunca "Em aplicação" com `DhInfusaoFimUTC` preenchido (D-CM-030). - Dado que um procedimento tem um status com `colors`, então o card deve exibir o chip com o nome (`status.name`) e o par fundo/texto do tema vigente; sem `colors`, o chip neutro. - Dado que um procedimento está com status `canceled`, então o card deve exibir riscados o nome do paciente, o local, as tags e a clínica, e sem risco o chip "Cancelado" e o avatar. - Dado que o toggle "Meus" está ativado, então o painel deve exibir apenas pacientes com vínculo direto com o médico logado. - Dado que o médico atende em duas clínicas e há procedimento hoje nas duas, então o painel e "Procedimentos Hoje" reúnem os dois, e cada card mostra o nome da clínica; com uma só clínica, o nome não aparece (D-CM-066, D-CM-061). - Dado que o médico desativa o toggle "Meus", então o painel deve exibir todos os pacientes presentes na unidade. - Dado que o médico clica no card de paciente, então o sistema deve abrir a prescrição do procedimento (se houver). Se não houver prescrição associada, abre diretamente o PEP. - Dado que o médico clica no botão de PEP no card, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP). - Dado que um procedimento está com status "Finalizado", então o card deve exibir o horário de término do atendimento, não mais o de início (RN-CM-026). - Dado que dois procedimentos estão agendados para o mesmo horário, então eles devem aparecer na lista em ordem alfabética pelo nome do paciente (RN-CM-027). - Dado que o toggle 'Meus' está ativado e não há pacientes com vínculo direto com o médico logado, então o painel deve exibir "Sem pacientes seus para o dia" (`MSG_proceduresNoneMine`). - Dado que o médico desativa o toggle 'Meus' e não há nenhum paciente presente na unidade, então o painel deve exibir "Sem pacientes para o dia" (`MSG_proceduresNoneAll`). Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | | ------------------ | ------------------------ | ------------------------ | ---------------------------- | | painel-título | Pacientes em procedimento | Patients in procedure | Pacientes en procedimiento | | toggle-todos | Todos | All | Todos | | toggle-meus | Meus | Mine | Míos | | botão-PEP | PEP | EHR | HCe | | MSG_proceduresNoneMine | Sem pacientes seus para o dia | No patients of yours for today | Sin pacientes suyos para el día | | MSG_proceduresNoneAll | Sem pacientes para o dia | No patients for today | Sin pacientes para el día | | proc-sem-tempo | sem tempo previsto | no planned time | sin tiempo previsto | Rótulos de status: vêm traduzidos da API (`status.name`; `TermoTraducao` com `Termo` = `CodEstado` e `Origem` = `DomEstadoAgendaProcedimento`, Mapeamento 4.3), não são catalogados no front. --- ### 2.7 Fluxos de Exceção e Estados (Consolidado) | Painel | Condição | Exibição | | --------------- | ---------------------------------------------------------- | ----------------------------------------------------------------------------- | | Qualquer painel | Falha de endpoint no carregamento (painel ainda sem dados) | MSG_endpointFail | | Qualquer painel | Falha numa atualização automática, com dados já exibidos (queda de conexão ou erro do servidor) | Manter os últimos dados na tela + faixa de sem conexão (abaixo) | | KPI Bar | Falha de endpoint no carregamento | Exibir "—" nos valores; demais painéis continuam operando | | KPI Bar | Falha numa atualização automática, com valores já exibidos | Manter os últimos valores + faixa de sem conexão (abaixo) | Faixa de sem conexão: se uma atualização automática (RN-CM-017) falhar depois de os dados de um painel ou indicador já terem sido carregados, os últimos dados continuam na tela e aparece a faixa de sem conexão, padrão do sistema (Design System, seção 7): uma só para toda a Central, de largura total, logo abaixo do cabeçalho (2.1), com o ícone Lucide `wifi-off` e o texto `MSG_connectionLost` — "Sem conexão — dados atualizados às {hh:mm}", com o horário no fuso da clínica. A faixa é uma região `role="status"`, anunciada uma vez ao aparecer, sem botão de fechar, e some sozinha quando nenhuma atualização está falhando. (Confirmado — D-CM-027, E-CM-001.) O formato é o da Agenda do Médico (Design System, seção 7); como a Central tem vários painéis com intervalos diferentes, o horário mostrado é o da atualização bem-sucedida mais antiga entre os painéis e indicadores que estão falhando — o pior caso de defasagem; e a faixa some quando todos voltam a atualizar. Em telas de até 1024px, em que o cabeçalho fica preso no topo, a faixa fica presa junto com ele. A faixa não substitui `MSG_endpointFail`, que continua valendo para o painel que falha antes de ter qualquer dado. Motivador: o horário diz ao médico quão velhos os dados podem estar (ex.: se o status de um paciente ainda é confiável); um ícone por painel não dizia isso e se repetia quatro vezes. Critérios de Aceitação: - Dado que a Central já carregou os dados e a atualização automática do painel de Consultas falha, então os últimos dados continuam na tela e aparece, logo abaixo do cabeçalho, a faixa "Sem conexão — dados atualizados às {hh:mm}" (`MSG_connectionLost`), com o horário da última atualização bem-sucedida. - Dado que a faixa está visível e as atualizações voltam a funcionar, então a faixa some sozinha, sem ação do médico. - Dado que um painel falha já no carregamento inicial, então ele exibe `MSG_endpointFail` e a faixa não aparece por causa dele. - Dado que dois painéis estão falhando em atualizações automáticas, então aparece uma só faixa, com o horário da atualização bem-sucedida mais antiga entre eles. Estados de loading: Cada painel exibe skeleton loading independente quando os dados estão sendo carregados. A busca exibe um spinner dentro do campo de input durante a consulta à API. Internacionalização | Termo/Localização | pt-BR | en-US | es-419 | | ----------------- | ---------------------------------------------------- | --------------------------------------- | ---------------------------------------------- | | MSG_endpointFail | Dados temporariamente indisponíveis. Tente novamente | Data temporarily unavailable. Try again | Datos temporalmente no disponibles. Reintentar | | MSG_connectionLost | Sem conexão — dados atualizados às {hh:mm} | No connection — data updated at {hh:mm} | Sin conexión — datos actualizados a las {hh:mm} | --- ### 2.8 Mapeamento de Componentes do Design System | Componente | Variante | Estados | Tokens aplicados | | ------------------------- | ------------------------- | --------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------ | | Button | Primary (Responder, no modal de mensagem; Resolver, na caixa de confirmação) | default, hover, disabled, loading | bg: `--color-primary-strong`; text: `--color-on-primary-strong` (5,5:1 nos dois temas); sem borda; no máximo um por região (Design System, seção 12; D-CM-085, E-CM-049) | | Button | Secondary (Assinar, Revisar e PEP, nos cards; Resolvido, no modal de mensagem; Cancelar, na caixa de confirmação) | default, hover, disabled | bg: transparent; border: 1px `color-neutral-pure` (5,5:1 no claro, 7,1:1 no escuro); text: `color-neutral-dark` (14,6:1 e 11,2:1); botão dentro de card é sempre secundário (Design System, seção 12; D-CM-085) | | Button | Danger (Descartado, no modal de mensagem; Descartar, na caixa de confirmação) | default, hover | bg: transparent; border: 1px color-error-dark; text: color-error-dark — o Design System ainda não define o botão destrutivo (seção 12); escolha do Designer (E-CM-049) | | Chip | Active (Crítico) | default | bg: color-error-light; sem borda; text e ícone: color-error-dark; font-weight-regular (400; D-CM-056); ícone Lucide `triangle-alert` (D-CM-046) | | Chip | Active (Atenção) | default | bg: color-highlight-light; sem borda; text e ícone: color-highlight-dark; font-weight-regular (400; D-CM-056); ícone Lucide `clock` (D-CM-046) | | Chip | Status (consulta e procedimento) | default | classe `.chip-status` com `status.colors` (fundo/texto do tema vigente; Design System, seção 4); sem `colors`: chip neutro; texto = `status.name` | | Chip | Tag de atenção (cadastro) | default | classe `.chip-tag` com `--tag` = `ProgramaApoio.Cor` (Design System, seção 5); texto = `ProgramaApoio.Sigla` | | KPI Value | Alerta (KPI Alertas) | default, alerta (urgentes > 0) | default: color-neutral-darker; alerta: text color-error-dark, font-size-xxl (24px; 6,3:1 sobre base-pure no claro, 7,4:1 no escuro; D-CM-054) — Seção 2.2 | | Badge | Contador do painel | default | bg: color-neutral-lighter; text: color-neutral-darker; font-size-sm; radius-pill (16,2:1 no claro, 11,2:1 no escuro) | | Input | Bordered (busca) | default, focus, disabled | border: color-neutral-light (repouso; contraste de 1,7:1 no claro e 1,8:1 no escuro, abaixo dos 3:1 da WCAG 1.4.11, aceito em D-CM-057) → focus: borda de 2px color-neutral-dark, sem anel extra (Design System, seção 11; ver Acessibilidade); height: input-height | | Avatar | SM/MD (paciente, Consultas) | default | classe `.avatar-status`: fundo = `status.colors.{tema}.background`; iniciais `color-neutral-darker` nos dois temas (Design System, seção 4) | | Avatar | SM/MD (paciente, Procedimentos) | default | bg: color-neutral-light; text: color-neutral-dark; sem a cor do status (D-CM-077) | | Progress | Bar (atendimento) | default, critical | bg track: color-neutral-lighter; bg bar: color-neutral-dark → critical: color-error-dark (contraste ≥ 3:1 com o trilho — D-CM-027, E-CM-008) | | Toast | Success/Error | default | Ver Design System para tokens de toast | | Tooltip | Default | hover | bg: color-neutral-dark; text: color-base-pure | | KPI Card | Borda colorida lateral | default, hover | border-left: 4px solid; cores: secondary-pure (consultas), primary-pure (tratamento), highlight-pure (procedimentos), error-pure (alertas) | | Panel Title Link | Link com seta no hover | default, hover | font-weight: 400; color: neutral-darker → hover: secondary-dark; arrow: opacity 0 → hover: opacity 1 | | Toggle Pill | Filtro de painel | active, inactive | border: 1px solid neutral-lighter; active: bg secondary-light, text neutral-darker, contorno 1px neutral-dark; inactive: bg transparent, text neutral-pure; área clicável 44px | | Progress Bar Inline | Barra na linha do nome | default, danger | width: 50px; height: 3px; bg track: neutral-lighter; bg fill: neutral-dark → danger: error-dark (contraste ≥ 3:1 com o trilho — D-CM-027, E-CM-008); pct font: font-size-xs (10px), color-neutral-pure | | Card Highlight (Consulta) | Borda colorida por status | recepcionado, aguardando, default | recepcionado: border-left 3px solid secondary-pure; aguardando: border-left 3px solid `--color-status-waiting-border`; default: sem borda | | Message Icon (Lucide) | Origem da conversa | unread, read | unread: ícone color-secondary-dark e borda lateral 3px color-secondary-dark; read: ícone color-neutral-pure, sem borda. Apenas 2 ícones: `bell` (sistema/alerta automático) e um ícone genérico de pessoa (conversa com usuário) — não há ícone por equipe | | Read Icon (Lucide) | Aviso de leitura (card de conversa) | sent, read | `check` 16px `color-neutral-pure` (enviada); `check-check` 16px `color-secondary-dark` (lida; 6,1:1 no claro, 11,1:1 no escuro); rótulo "Enviada"/"Lida" para leitor de tela e dica; só quando a última mensagem é do médico logado (D-CM-087) | | Icon | 1ª Consulta | default, hover e toque (dica) | Tabler `circle-number-1` (react-icons `TbCircleNumber1`), 18px, cor `--color-first-visit`, sem fundo; `role="img"` e `aria-label` "1ª Consulta"; dica (`role="tooltip"`) aberta por mouse ou toque, sem depender do `title` nativo (que não aparece em tela de toque) | | User Menu Dropdown | Avatar + caret | closed, open | avatar: bg neutral-dark, text base-pure, radius-full; caret: rotate 180° quando open; menu: bg base-pure, shadow-medium, radius-m, min-width 160px; item: hover bg base-dark | > Nota: o Chip de urgência só se aplica dentro de 24h restantes (RN-CM-011, Seção 2.4). A partir de 24h, não há componente Chip — o tempo é exibido como texto simples, cor `color-neutral-pure`. #### Acessibilidade (transversal) Requisitos válidos para todos os painéis, nos dois temas (claro e escuro): - Contraste: texto de informação com razão mínima de 4,5:1 (3:1 em texto grande e em componentes gráficos). `color-neutral-medium` não é usado como texto de informação (nem em placeholder); os cards Finalizado se distinguem por cor de fundo e borda, nunca por redução de opacidade. Exceção aceita (D-CM-057): a borda de repouso dos campos de texto (`color-neutral-light`) fica abaixo de 3:1 sobre o fundo. - Teclado: todo card (consulta, prescrição, procedimento e conversa) e todo controle é alcançável por Tab; Enter e Espaço fazem o que o clique faz; o nome acessível do card é o próprio conteúdo (horário, nome, ícone de 1ª Consulta, diagnóstico, status, modo de atendimento, atraso, tags e, quando exibida, a clínica). O ícone de 1ª Consulta, isolado, não recebe o foco do teclado: o leitor de tela lê "1ª Consulta" no nome do card (aceito em D-CM-035). O botão de ação do card (Assinar, Revisar, PEP) é um controle à parte, sem aninhamento dentro do elemento clicável do card. O card de conversa não tem botão de ação (D-CM-089); o nome acessível dele inclui o grau de urgência, quando houver ("Grau de urgência: {nome}"). - Foco visível (Design System, seção 11; D-CM-046): em `:focus-visible`, anel de 2px em `color-neutral-dark`, afastado 2px do controle, em botões, toggles, cards, links, abas e itens de menu; contraste entre 11,2:1 e 14,6:1 contra `base-pure` e `base-dark`, nos dois temas (mínimo exigido: 3:1). No item do menu do usuário, que o menu corta, o anel fica recuado (`outline-offset` de -2px); o anel do card é externo, com afastamento de 2px, e cabe no padding do painel (só em navegador sem `:has` ele fica recuado). Em todo campo de texto da tela (busca e resposta do modal de conversa), vale a borda de 2px no lugar do anel. No campo de busca não há anel: a borda de 2px `color-neutral-dark` é o indicador de foco. O foco nunca é removido (`outline: none`) sem esse substituto. - Alvos de toque: área clicável mínima de 44×44px em todo controle (a área pode ser maior que o desenho do controle). - Modal de conversa: `role="dialog"`, `aria-modal="true"`, nome acessível pelo título; o foco entra no diálogo, fica preso nele (Tab e Shift+Tab), Esc fecha, e o foco volta ao elemento que o abriu (ou ao próximo elemento do painel, se a conversa saiu da lista). - Avisos (toasts): região `role="status"` com `aria-live="polite"`; erros em `role="alert"`. - Busca de pacientes: padrão combobox/listbox (`role="combobox"` com `aria-expanded`, `aria-controls` e `aria-activedescendant`; lista `role="listbox"`, itens `role="option"`); setas navegam, Enter seleciona, Esc fecha; "nenhum paciente encontrado" e dicas anunciados em região `aria-live`; a comparação ignora acentos. - Movimento: com `prefers-reduced-motion: reduce`, as animações contínuas (ponto pulsante do selo "Atrasado") e a entrada dos avisos ficam desligadas. - Celular (360px): sem rolagem horizontal da página; chips e tags quebram de linha em vez de ultrapassar o card. Em até 1024px, o cabeçalho (e a faixa de sem conexão) ficam presos no topo. Critérios de Aceitação: - Dado que o médico navega só pelo teclado, então ele alcança, nesta ordem, os indicadores, o título e o filtro de cada painel e os cards, e Enter ou Espaço num card faz o que o clique faz. - Dado que o modal de uma conversa está aberto, então Tab e Shift+Tab não saem dele, Esc o fecha e o foco volta ao card que o abriu. - Dado que os temas claro e escuro, então nenhum texto de informação tem contraste menor que 4,5:1. - Dado que o sistema operacional pede movimento reduzido, então o selo "Atrasado" não pulsa. --- ### 2.9 Integração com Backend Decisão arquitetural: 1 endpoint por painel + 1 endpoint por KPI card, em vez de um único endpoint consolidado. Justificativa: paralelismo (frontend dispara chamadas simultâneas), resiliência (falha em um endpoint não bloqueia os demais — especialmente importante para os KPIs, onde um problema em um indicador não trava os outros três), granularidade de atualização. Mecanismo de atualização automática (RN-CM-017): polling — o front-end consulta os endpoints acima em intervalos fixos, sem push/websocket. Se uma atualização falhar, os últimos dados permanecem na tela e aparece a faixa de sem conexão (Seção 2.7). Intervalo por endpoint: 1 minuto para `appointments`, `conversations` e o KPI `appointments-today`; 5 minutos para `prescriptions`, `procedures` e os KPIs `procedures-today`, `prescription-alerts` e `in-treatment` (ver justificativa de negócio de cada grupo em RN-CM-017). Endpoints de KPI (1 por card): - [GET] /api/v1/cockpit/doctor/kpis/appointments-today - Função: Retornar o indicador de Consultas Hoje - Response 200: `{ "total": 6, "finished": 4, "pending": 2, "delayed": 1 }` - [GET] /api/v1/cockpit/doctor/kpis/in-treatment - Função: Retornar o indicador de Em Tratamento - Response 200: `{ "inTreatment": 43, "nonAdherent": 2 }` - [GET] /api/v1/cockpit/doctor/kpis/procedures-today - Função: Retornar o indicador de Procedimentos Hoje - Response 200: `{ "total": 8, "inProgress": 2, "waiting": 4, "scheduled": 2 }` — `total` inclui os procedimentos já finalizados e completos; os três subtotais não precisam somar o total (D-CM-038). - [GET] /api/v1/cockpit/doctor/kpis/prescription-alerts - Função: Retornar o indicador de Alertas de Prescrição - Response 200: `{ "urgent": 3, "toReview": 1, "toSignNext7Days": 5, "toSignWindowDays": 7 }` - Detalhamento dos campos: `urgent` = total de prescrições pendentes de assinatura OU pendentes de revisão (RN-CM-020) com `hoursRemaining` < 12h (RN-CM-011). `toReview` = total de prescrições atualmente marcadas como "a revisar", independente da urgência. `toSignNext7Days` = total de prescrições pendentes de assinatura com aplicação agendada dentro da janela de assinatura da clínica (o nome do campo vem do padrão de 7 dias e foi mantido por compatibilidade; a janela é contada em dias de calendário, com o N da clínica de cada prescrição e o "hoje" no fuso da clínica logada, D-CM-037, D-CM-062). `toReview` não inclui prescrições com assinatura feita depois de a janela de revisão abrir (D-CM-040) nem com administração iniciada (D-CM-039); `toSign...` mantém as com administração iniciada. `toSignWindowDays` = a janela de assinatura em dias (`PrescricaoTempoAssinatura`, padrão 7; da clínica em que o médico está logado, D-CM-063), para o front montar o rótulo "p/assinar (próx. N dias)" no idioma da clínica atual (DT-012). Mapeamento de BD: Seção 4.6. Endpoints de leitura (painéis): - [GET] /api/v1/cockpit/doctor/appointments - Response 200: `{ "appointments": [ { "id": 1234, "patient": { "id": 567, "preferredName": "", "legalName": "Maria da Silva", "photo": "url|null", "diagnosis": ["Ca. Mama"] }, "clinic": "Oncocentro Sul", "startTime": "08:00", "endTime": "08:30", "status": { "domain": "finished", "name": "Finalizado", "colors": { "light": { "background": "#EDE7FA", "text": "#6A4FC4" }, "dark": { "background": "#302F52", "text": "#C0AFED" } } }, "attendanceMode": "in_person", "delayMinutes": 0, "elapsedMinutes": null, "overtime": false, "firstTime": false, "tags": [ { "code": "VIP", "description": "Paciente com tratamento administrativo diferenciado", "color": "#80FF38" } ] } ] }` - `diagnosis`: lista de strings — um paciente pode ter mais de um diagnóstico oncológico ativo; todos são retornados e exibidos (ver mapeamento na Seção 4.1). - `status`: objeto, no mesmo formato da Agenda do Médico (GET /day). `domain`: um dos valores de `AppointmentStatus()` (Seção 4.1) — `scheduled | waiting | checked | consultation | finished` (o painel não traz canceladas); é o campo que o front usa nas regras (toggle, bordas, selo de atraso). `name`: nome do status já traduzido para o idioma da clínica (texto do chip). `colors`: `light` e `dark`, cada um com `background` e `text` (`#RRGGBB`), as cores do chip e do avatar em cada tema (Design System, seção 4); vem com os quatro valores preenchidos ou não vem — sem `colors`, o front mostra chip e avatar neutros. Mapeamento de BD: Seção 4.1. - Troca de formato: `status` passa de texto a objeto em `appointments` e `procedures` no mesmo deploy do back-end e do front-end, sem período com os dois formatos (D-CM-080); o mesmo vale para a Agenda do Médico (`GET /day`). - `clinic`: nome curto da clínica da consulta, ou `null` quando o médico atende em uma única clínica (RN-CM-032, E-CM-028) — a condição é aplicada pelo back-end, como na Agenda do Médico (RN-AGM-017, a), para o front não precisar saber quantas clínicas o médico atende. O endpoint devolve as consultas das clínicas em que o médico atende (D-CM-066). - `id`, `patient.id`: números inteiros (`Agenda.IdAgenda`, `Agenda.IdPaciente`), como no Mapeamento (Seção 4.1); o mesmo vale para `id` e `patient.id` de `procedures`, `prescriptions` e `patients/search` (4.3, 4.7, 4.10) e para `patient.id` de `conversations` (4.8) — só os ids de conversa e de mensagem são `uuid`. - `tags`: lista de tags de atenção do paciente, cada uma com `code` (sigla, texto do chip), `description` (dica e rótulo acessível) e `color` (cor do cadastro, hexadecimal `#RRGGBB`, fundo do chip — Design System, seção 5; ausente ou inválida, o chip usa `color-neutral-lighter`). Vêm do cadastro de tags da clínica, atribuídas no cadastro do paciente ou no prontuário (RN-CM-025), e a tag VIP, que é atribuída no cadastro do paciente (Seção 4.1). A 1ª Consulta não vem em `tags`: é o campo `firstTime` (RN-CM-028). A lista já vem na ordem de exibição (D-CM-022): tags assistenciais (`Finalidade` `A`) antes das administrativas (`D`), cada grupo em ordem alfabética pela sigla. - `attendanceMode`: modo de atendimento (presencial, teleatendimento etc.) — mesmo nome de campo usado pela Agenda do Médico. - `elapsedMinutes`: minutos desde `Agenda.DhAtendimentoIniUTC` quando a consulta está em atendimento; `null` nos demais estados. `overtime`: `true` quando `elapsedMinutes` passa de `Agenda.Tempo` (D-CM-017); o front monta o texto "há 1h20" e o traduz. - Horários bloqueados (RN-CM-030) nunca são retornados por este endpoint. - [GET] /api/v1/cockpit/doctor/prescriptions - Query params: `type` (opcional: `to_sign` | `to_review`) — usado pela tela dedicada de Prescrições Pendentes para filtrar por categoria. O painel do Cockpit não envia o parâmetro e recebe as duas categorias combinadas, já ordenadas por `minutesRemaining` crescente, desempate pelo nome do paciente e, depois, por `id` (RN-CM-011, D-CM-047). `reviewScope` (opcional: `mine` | `all`, default `mine`) — controla o toggle "Meus/Todos": afeta as duas categorias (`to_sign` e `to_review`) da mesma forma — `mine` restringe a prescrições em que o médico logado é o prescritor ou o médico assistente do paciente; `all` remove essa restrição, mostrando as prescrições de todos os médicos, nas clínicas em que o médico logado atende (D-CM-066). - Response 200: `{ "prescriptions": [ { "id": 1234, "patient": { "id": 567, "preferredName": "", "legalName": "Roberto Oliveira" }, "prescriptionCode": "CARBO-TAXOL C3D1", "clinic": "Oncocentro Sul", "scheduleDate": "2026-07-22T18:00:00Z", "hoursRemaining": 8, "minutesRemaining": 480, "type": "to_sign", "isPreferredReviewer": false }, { "id": 1235, "patient": { "id": 568, "preferredName": "", "legalName": "Carlos Mendes" }, "prescriptionCode": "FOLFOX C1D1", "clinic": "Oncocentro Norte", "scheduleDate": "2026-07-22T14:00:00Z", "hoursRemaining": 18, "minutesRemaining": 1080, "type": "to_review", "isPreferredReviewer": true } ] }` - `minutesRemaining`: minutos até a aplicação agendada, negativo quando a hora já passou; é a base dos textos de tempo restante e "atrasada" (D-CM-013, D-CM-041). `hoursRemaining` continua como inteiro truncado em direção a zero (D-CM-026). - `patient.preferredName`/`patient.legalName`: mesmo padrão de `appointments` e `procedures` — o front decide qual exibir como nome principal (nome social se houver), mas ambos são enviados para o médico perceber questões de gênero/identidade antes do atendimento. - `prescriptionCode`: substitui os antigos campos `protocol`/`cycle` por um único campo já formatado (protocolo + ciclo/sessão, ex: "CARBO-TAXOL C3D1"), espelhando `Prescricao.Identificacao` diretamente — sem necessidade de montar a string no backend. - `clinic`: nome curto da clínica da agenda da prescrição (`Prescricao.IdAgenda` → `Agenda.IdChClinica`), ou `null` quando o médico atende em uma única clínica — mesma regra de `appointments.clinic` (RN-CM-032, E-CM-028). O endpoint devolve as prescrições das clínicas em que o médico atende, e `reviewScope = all` amplia para todos os médicos dessas clínicas (D-CM-066, E-CM-029). - Campo presente nos dois tipos, `to_sign` e `to_review` (RN-CM-020): `isPreferredReviewer` = `true` quando o médico logado é o prescritor OU o médico assistente do paciente — usado pelo front para destacar visualmente que este médico é revisor preferencial, sem bloquear a ação para os demais (qualquer médico pode revisar). Os campos `prescriberName`/`attendingDoctorName` cogitados numa versão anterior foram removidos — o booleano já é suficiente para o front filtrar/destacar, sem expor nomes de terceiros nesta lista. - `type = to_sign` só retorna prescrições nunca assinadas com aplicação agendada até o fim do dia (hoje + S) em dias de calendário, com S = `PrescricaoTempoAssinatura` da clínica da prescrição (padrão 7) e "hoje" no fuso da clínica em que o médico está logado (inclusive as que já passaram da hora; D-CM-037, D-CM-060, D-CM-062) — evita inflar a lista com prescrições distantes no tempo, sem relevância imediata. - Mapeamento de BD: Seção 4.7. - [GET] /api/v1/cockpit/doctor/conversations - Alinhado à entidade `Conversa` do modelo de mensageria (IP.Mensageria, schema `mensageria` em `GescomClienteAlfa`). Retorna todas as conversas do médico logado, das clínicas em que ele atende (D-CM-066), com `Status` não-terminal (`'Sent'`, `'Read'` ou `'Responded'`), lidas ou não. Este é o comportamento do painel compacto do Cockpit; uma tela dedicada (fora do escopo desta versão) listará também as conversas já finalizadas (`'Resolved'`/`'Dismissed'`). - Response 200: `{ "conversations": [ { "id": "uuid", "subject": "Falta de Carboplatina", "sourceType": "User | System", "authorName": "Sandra", "authorIsMe": false, "clinic": "Oncocentro Sul", "lastMessage": "Medicamento Carboplatina em falta.", "lastMessageAt": "2026-07-22T13:45:00Z", "deadline": "2026-07-22T14:00:00Z|null", "urgencyLevel": { "key": "asap", "name": "Quanto antes" } | null, "status": "sent | read | responded", "unread": true, "readByOthers": null, "patient": { "id": 567, "preferredName": "", "legalName": "Roberto Oliveira" } | null } ] }` — exemplo de uma conversa endereçada a uma equipe, com o autor respondendo como representante dela: `authorName: "Sandra (Farmácia)"` (mesmo campo, sem campo novo — RN-CM-015, RN-CM-022, resolução em 4.8). - `sourceType`: `System` quando `Conversa.OrigemTipo = 'System'` (alerta automático via `ModuloOrigem`); `User` quando `OrigemTipo = 'User'` — vale tanto para conversa endereçada a um indivíduo quanto a uma equipe. - `clinic`: nome curto da clínica de origem da conversa (D-CM-064), ou `null` quando o médico atende em uma única clínica, como em `appointments.clinic`; origem em 4.8 (E-CM-033). - `subject`: assunto da conversa (`Conversa.Assunto`), linha 1 do card. - `urgencyLevel` (D-CM-088): `null` quando a conversa não tem grau; senão `{ key, name }`, com `key` em minúsculas, do domínio HL7 (`routine`, `urgent`, `asap` ou `stat`; Mensageria D-MSG-046), e `name` já traduzido para o idioma da clínica (`IpTerminologia.Indicadores` e `TermoTraducao`); o front não mantém a lista de nomes. **[PROPOSTA de contrato, E-MSG-018 da Mensageria]**; depende da coluna `Conversa.GrauUrgencia` (L-09 da Mensageria). A resposta traz também `serverNow` (UTC) **[PROPOSTA, E-CM-051]** para o horário relativo. - `authorName`: nome de quem escreveu a última mensagem (`Usuario.Apelido`, ver 4.8), ou "Sistema" quando `sourceType = System`. Inclui o nome da equipe entre parênteses quando a conversa é endereçada a uma equipe (`DestinoTipo = 'Team'`) e o autor é membro dela — ver "Resolução do nome da equipe" na Seção 4.8. - `authorIsMe` (boolean): `true` quando a última mensagem é do médico logado; o front mostra "Você" (`msg-voce`) no lugar de `authorName` (E-CM-050). - `readByOthers` (boolean | null): só tem valor quando a última mensagem é do médico logado (nulo em alerta do sistema e quando a última é de outra pessoa); `true` quando pelo menos um dos outros participantes leu até ela, e num autoenvio; o front mostra `check` (false) ou `check-check` (true). Calculado na consulta, sem coluna nova (4.8). - Ordem: a lista vem ordenada do servidor (RN-CM-015; Seção 4.8); o front não reordena. - `status`: `sent` = `'Sent'`, `read` = `'Read'`, `responded` = `'Responded'` (D-CM-087). `'Resolved'`/`'Dismissed'` nunca aparecem aqui (já saíram da lista). Um item com `status = responded` pode estar lido ou não lido, dependendo se houve atividade nova desde a resposta do médico — ver campo `unread`. - `unread` (boolean): `true` quando `Conversa.UltimaSequencia > ConversaLeitura.UltimaSequenciaLida` (ou não existe `ConversaLeitura` para o médico). Usado pelo front para o destaque visual e para a camada de prioridade na ordenação (RN-CM-015) — não filtra mais quais itens são retornados. - Mapeamento de BD: Seção 4.8. - [GET] /api/v1/cockpit/doctor/procedures - Response 200: `{ "procedures": [ { "id": 1234, "prescriptionCode": "AC-T C1D21", "patient": { "id": 567, "legalName": "Roberto Oliveira", "preferredName": "", "photo": "url|null" }, "clinic": "Oncocentro Sul", "location": "Sala de Infusão 2", "status": { "domain": "administering", "name": "Em aplicação", "colors": { "light": { "background": "#00E676", "text": "#005F31" }, "dark": { "background": "#12443C", "text": "#00E676" } } }, "startTime": "09:30", "firstTime": false, "progress": 65, "mine": true, "tags": [ { "code": "LC", "description": "Linha de cuidados", "color": "#FFD6D1" } ] } ] }` - `clinic`: nome curto da clínica da agenda do procedimento (`Agenda.IdChClinica`), ou `null` quando o médico atende em uma única clínica (RN-CM-032, D-CM-061), como em `appointments.clinic`. O endpoint devolve os procedimentos das clínicas em que o médico atende (D-CM-066). - `startTime`: horário "HH:mm" no fuso da clínica (D-CM-042), como em `appointments`. `firstTime`: booleano, `Agenda.PrimeiraConsulta = 'S'` (RN-CM-028, D-CM-029), como em `appointments`. `progress`: percentual inteiro (arredondado) do tempo decorrido sobre o tempo de aplicação da prescrição (`Prescricao.TempoAplicacao`, em minutos); `null` quando a prescrição não tem tempo de aplicação — o front não desenha a barra e mostra "sem tempo previsto" (D-CM-034). Mapeamento de BD: Seção 4.3. - `status`: objeto, no mesmo formato de `appointments.status`. `domain`: um dos valores de `ProcedureStatus()` (Seção 4.3/4.4) — `scheduled | waiting | checked | preparation | administering | administered | finished | canceled`, avaliados em ordem (D-CM-030): `administered` = infusão terminada sem alta ("Completo"); `finished` = alta registrada. `name`: nome traduzido para o idioma da clínica (texto exibido no card). `colors`: como em `appointments`; pinta o chip de status do card (Seção 2.6). - `tags`: lista de tags de atenção do paciente, no mesmo formato (`code`, `description`, `color`) e com a mesma origem de `appointments.tags`, ver Seção 4.1/4.3. A lista já vem na ordem de exibição (D-CM-022): tags assistenciais (`Finalidade` `A`) antes das administrativas (`D`), cada grupo em ordem alfabética pela sigla. - `prescriptionCode`: substitui o campo `prescriptionId` de uma versão anterior deste documento — o valor nunca foi um identificador único, sempre foi o código formatado da prescrição (protocolo + ciclo/sessão), mesmo campo já usado em `prescriptions` (Seção 2.9). - [GET] /api/v1/patients/search - Query params: `q` (string, mínimo 2 caracteres) - Response 200: `{ "patients": [ { "id": 567, "name": "Maria da Silva", "medicalRecordNumber": "0012345", "gender": "F", "birthDate": "1972-08-15", "motherName": "Joana da Silva", "cpf": "12345678901" } ] }` Endpoints de ação: > Nota: os endpoints de ação sobre uma prescrição individual (abrir prescrição completa, assinar, marcar como revisada, editar/gravar nova versão) **saíram do escopo deste documento**. Eles pertencem à tela de detalhe da prescrição, que é chamada a partir deste Cockpit mas faz parte de um processo mais amplo de Prescrições (fora do domínio "Central do Médico") e deve ser especificada em documento próprio. RN-CM-020 continua aqui porque define a regra de negócio usada no cálculo do KPI e do painel (Seções 4.6/4.7), mesmo que a execução da ação em si esteja documentada em outro lugar. - [GET] /api/v1/conversations/{id} — Retorna a thread completa (todas as `Mensagem`, em ordem) para exibição no modal. - Response 200: `{ "id": "uuid", "subject": "string", "status": "sent | read | responded", "deadline": "2026-07-22T14:00:00Z|null", "patient": { ... } | null, "messages": [ { "id": "uuid", "type": "Response", "author": "Sandra | Sistema", "content": "string", "createdAt": "2026-07-22T13:30:00Z" } ] }` - [POST] /api/v1/conversations/{id}/read — Marca a conversa como lida pelo médico logado (chamado ao abrir o modal). - Response 200: `{ "id": "uuid", "status": "read" }` — idempotente; se a conversa já estiver `Respondida`, o status não regride para `read`. - [POST] /api/v1/conversations/{id}/reply — Envia uma resposta na thread (não disponível para conversas com `sourceType = System`, ver RN-CM-015). - Request: `{ "content": "string" }` - Response 200: `{ "id": "uuid", "status": "responded", "message": { "id": "uuid", "content": "string", "createdAt": "2026-07-22T13:50:00Z" } }` - [PATCH] /api/v1/conversations/{id}/resolve — Muda o status da conversa para `Resolvida`. Substitui o antigo `PATCH /messages/{id}/resolve`. - Response 200: `{ "id": "uuid", "status": "resolved" }` - [PATCH] /api/v1/conversations/{id}/discard — Muda o status da conversa para `Descartada`. Substitui o antigo `DELETE /messages/{id}` — o método mudou de DELETE para PATCH porque o registro nunca é excluído fisicamente, só muda de status (modelo append-only, ver RN-CM-015). - Response 200: `{ "id": "uuid", "status": "discarded" }` --- ### 2.10 Conformidade SBIS (Detalhamento) |Requisito|Como a Central do Médico atende| |---|---| |ECF.03.11|O campo de busca no header permite pesquisar pacientes por nome, CPF, data de nascimento e nome da mãe. A busca inteligente (RN-CM-004) interpreta automaticamente o tipo de entrada. O número de prontuário não é critério da busca comum; a chave `id:` (busca pelo prontuário) será mostrada na certificação (D-CM-036). Pendente: a chave ainda não tem contrato, mapeamento nem texto de ajuda (P-CM-038).| |ECF.03.14|O endpoint GET /api/v1/patients/search retorna os campos obrigatórios: nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF em cada resultado.| |ECF.16.01(e)|Após o login, o painel de Prescrições Pendentes exibe as prescrições em aberto de responsabilidade do médico, permitindo acesso direto para assinatura ou revisão. O toggle "Meus" restringe a lista às prescrições de responsabilidade do médico; o toggle "Todos" permite a colaboração entre médicos, para resolver pendências com o responsável ocupado (D-CM-036). Atendimento parcial: a lista cobre as prescrições com aplicação até o fim da janela de assinatura, não todos os registros em aberto, e o "Todos" mostra prescrições de colegas — a compatibilidade com ECF.16.01(c) está em aberto (P-CM-037).| |ECF.17.01|Todos os cards de paciente identificam univocamente o paciente (nome + ID). As conversas identificam o autor de cada mensagem (nome da pessoa ou "Sistema", com o nome da equipe adicionado quando a pessoa responde como representante de uma equipe — RN-CM-015 — ver `authorName` na Seção 2.9). As prescrições identificam o paciente no card; o médico prescritor consta da prescrição aberta, e o card da Central não o mostra (P-CM-037).| |ECF.17.02|As mensagens internas exibem timestamp de criação (criadaEm). As ações de assinatura e resolução registram data/hora automaticamente no backend.| |ECF.17.04|As consultas são ordenadas cronologicamente pelo horário agendado. As conversas seguem 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), e as mensagens de cada conversa, a ordem de envio. As prescrições são ordenadas por urgência cronológica (tempo restante). A ordem anterior das conversas foi conferida contra o requisito (data de ocorrência do evento; D-CM-051); a Mensageria classifica a nova ordem como atendimento parcial (lista em ordem de prioridade, não cronológica) — a confirmar (P-CM-057).| |ECF.17.18|Toda a interface, incluindo rótulos, mensagens, títulos de tela e descritivos, está em português do Brasil. O pt-BR é o idioma apresentado na certificação; en-US e es-419 constam da especificação (D-CM-036). O idioma exibido é sempre o da clínica atual (DT-012); na certificação, a clínica está em pt-BR. O requisito diz "obrigatoriamente em português do Brasil" e não trata de idiomas adicionais: que os demais fiquem fora da avaliação é interpretação do Designer, a confirmar (P-CM-037).| |ECF.17.19|Mensagens de erro e feedback ao usuário (toasts, alerts) são em linguagem não técnica. Erros técnicos do backend são tratados e traduzidos para mensagens amigáveis.| --- ## 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 01-Definição v5.20, 03-Protótipo v5.20, 04-Mapeamento v5.20, Cenários de Teste v5.20 e 05-Registro de Decisões v1.19. Decisão D-CM-090 (nomes técnicos): `urgencyLevel` (grau da conversa, era `urgency`) e `timeIndicator` (indicador de tempo dos painéis de Consultas e de Prescrições). Sem mudança de regra. - **v5.19** (29/10/2026) — Acompanha 01-Definiçã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 (05 - Registro de Decisões v1.18), vindas da Mensageria v1.8 (D-MSG-025 a 028, 032, 039, 046 e 047). (1) 2.5: chip do grau de urgência no card, com as quatro chaves em minúsculas; ordem pelo grau antes da data dentro de cada camada de leitura; horário relativo com a regra "Há x min", "Há x h" e data e hora. (2) 2.5, 2.8, 2.10: o botão "Resolvido" sai do card; "Resolvido" e "Descartado" ficam só no modal. (3) 2.9: campos `urgency` e `serverNow` em `conversations[]` **[PROPOSTA]**; i18n com `msg-ha-min`, `msg-ha-h` e `msg-grau-titulo`. Nova escolha E-CM-051. - **v5.18** (28/10/2026) — Acompanha 01-Definiçã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). (1) 2.5: painel de Mensagens alinhado à Mensageria (D-CM-087, a partir de D-MSG-021 e D-MSG-023): assunto na linha 1 do card, com o horário relativo à direita; "autor: texto" na linha 2; sem o selo "Respondida"; aviso de leitura `check`/`check-check` quando a última mensagem é do médico (`readByOthers`); nova ordem (não lidas primeiro; depois a data mais recente entre a última mensagem e o prazo; empate pela conversa criada mais recentemente); valor `responded` no lugar de `replied`; horário relativo mantido; critérios de aceitação e catálogo de textos (`msg-voce`, `msg-enviada`, `msg-lida`; sai `chip-respondida`). (2) 2.8: nova linha do ícone de leitura. (3) 2.9: `subject`, `authorIsMe`, `readByOthers` e `responded` no contrato de `conversations` e das ações; a lista vem ordenada do servidor. (4) 2.10: ECF.17.04 com a nova ordem, a confirmar (P-CM-057). (5) E-CM-049 confirmada (D-CM-086), sem mudança de texto. (6) Revisão por crítico técnico (subagente) aplicada antes de fechar. Até a v5.17, o valor de `'Responded'` no contrato era `replied`. - **v5.17** (28/10/2026) — Acompanha 01-Definiçã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). (1) 2.8: botões alinhados à seção 12 do Design System (D-CM-085): Assinar, Revisar, PEP e Resolvido com contorno (secundários); Responder e o botão de confirmar "Resolver" em verde escuro (`--color-primary-strong`, texto `--color-on-primary-strong`); Cancelar com contorno; Descartado e "Descartar" seguem no estilo destrutivo (E-CM-049); sai a linha do botão terciário, que não é mais usado. (2) nome "Aguardando recepção", como cadastrado em `TermoTraducao` (antes "Aguardando Recepção"; D-CM-084). - **v5.16** (27/10/2026) — Acompanha 01-Definiçã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). (1) 2.6 e 2.8: o status do procedimento passa a chip colorido (`.chip-status`, D-CM-079; posição no card, E-CM-048), com critério novo; avatar neutro confirmado (D-CM-077); no card cancelado, o chip fica sem risco. (2) 2.9: `colors` de `procedures` passa a ser usado; a troca de `status` de texto para objeto é feita no mesmo deploy de back-end e front-end (D-CM-080). (3) 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). (4) Revisão por crítico técnico (subagente) aplicada antes de fechar. (5) 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 01-Definiçã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). Cores e nome do status vêm da API, no próprio status (DT-016; Design System de 27/10/2026, seção 4): (1) 2.3, "Cores de status" reescrito — classes `.chip-status` e `.avatar-status`, chip e avatar neutros sem `colors`, iniciais do avatar em `color-neutral-darker` sobre a cor de fundo do status (D-CM-075); (2) saem dos catálogos de 2.3 e 2.6 as chaves `status-*`, substituídas por `status.name`; (3) 2.6: valor de contrato `administered` no lugar de `completed` para "Completo" (D-CM-074); card de procedimento cancelado com os textos riscados, exceto o status e o avatar (D-CM-076, E-CM-046), com critério novo; o painel não usa `status.colors` (P-CM-054); (4) 2.8: linhas do chip e do avatar de consulta; (5) 2.9: `status` vira objeto `{ domain, name, colors }` em `appointments` e `procedures` (D-CM-073). - **v5.14** (26/10/2026) — Acompanha 01-Definiçã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 D-CM-070 a D-CM-072: quem perde o acesso a uma clínica perde as agendas e as prescrições dela, mas não os pacientes (corrige a v5.13, que dizia "e pacientes"). Sem mudança de tela, de texto ou de contrato. - **v5.13** (26/10/2026) — Acompanha 01-Definiçã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 D-CM-067 a D-CM-069: a escolha E-CM-034 ("atende" = clínicas a que o usuário tem acesso) vira decisão e a perda de acesso a uma clínica tira dela agendas e pacientes (D-CM-068). Sem mudança de tela, de texto ou de contrato; o escopo de clínicas descrito em 2.2 a 2.6 e 2.9 já é o das clínicas que o usuário acessa. - **v5.12** (26/10/2026) — Acompanha 01-Definiçã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): o médico vê só as clínicas em que atende, em todos os painéis e indicadores (consultas, prescrições, procedimentos, mensagens), e o toggle "Todos" só amplia para os outros médicos dessas clínicas. A linha de clínica nos cards aparece quando o médico atende em mais de uma clínica (igual à Agenda, RN-AGM-017, a). Textos de 2.2 a 2.6 e 2.9 ajustados; critérios de aceitação com "médico atende em duas clínicas" no lugar de "cliente tem duas clínicas"; novos critérios com três clínicas no cliente, das quais o médico atende em duas (2.3 e 2.4). Como o sistema sabe onde o médico atende: E-CM-034 (a confirmar), detalhado no Mapeamento. - **v5.11** (26/10/2026) — Acompanha 01-Definiçã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) O "hoje" e o fim do dia das janelas de assinatura e de revisão seguem o fuso da clínica em que o usuário está logado (D-CM-062), com o N e o S da clínica de cada prescrição; novo critério de aceitação com duas clínicas de fusos diferentes (2.4). (2) O rótulo "p/assinar (próx. N dias)", `toSignWindowDays` e o "Em Tratamento" usam a clínica logada (D-CM-063). (3) O card de mensagem mostra a clínica (D-CM-064): novo item em 2.5, campo `clinic` em `conversations` (2.9) e dois critérios de aceitação. (4) E-CM-030 vira D-CM-061. (5) Lacunas fechadas: `type = to_sign` em 2.9 diz qual janela e qual fuso usa; o critério de 2.3 que ainda falava em "o médico tem acesso a uma só clínica" passa a "o cliente tem uma só clínica"; critérios de aceitação das mensagens por clínica. (6) Grafia dos rótulos padronizada em "p/revisar" e "p/assinar", como na tabela de textos de 2.2. - **v5.10** (26/10/2026) — Acompanha 01-Definiçã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) Chips "Crítico" e "Atenção" em peso regular, 400 (D-CM-056). (2) Campo em repouso: `neutral-light` mantido, com a exceção de contraste registrada em 2.8 (D-CM-057). (3) E-CM-020 e E-CM-026 viram D-CM-055 e D-CM-058. (4) Escopo do cliente (D-CM-060): procedimentos ganham o campo `clinic` e a linha de clínica no card (E-CM-030); "Procedimentos Hoje" e Mensagens passam a cobrir todas as clínicas; a linha de clínica aparece quando o cliente tem mais de uma; janelas de prescrição por clínica; novos critérios de aceitação (janelas diferentes; prescrição já assinada não é assinada de novo, D-CM-059). Rótulo do indicador de alertas e "Em Tratamento" com a clínica de entrada, interino em P-CM-048. - **v5.9** (26/10/2026) — Acompanha 01-Definiçã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 D-CM-047 a D-CM-054. (1) 2.4 e 2.9: desempate das prescrições pelo nome do paciente e, depois, pelo `id` (D-CM-047, E-CM-027), com o critério de aceitação correspondente. (2) 2.2, 2.3, 2.4 e 2.9: escopo de todas as clínicas do cliente, campo `clinic` nas consultas e nas prescrições e linha de clínica no card quando o médico acessa mais de uma (D-CM-050, E-CM-028, E-CM-029); novos critérios de aceitação, inclusive o de "editar, gravar e reassinar"; parâmetros por clínica em aberto (P-CM-046). (3) 2.2, 2.3 e 2.8: selo "Atrasado" e número do KPI de Alertas mais leves, `color-error-light`/`color-error-dark` (D-CM-054, E-CM-026); o "há 1h20" fica leve, como os chips (D-CM-053). (4) 2.10: ECF.17.04 conferido para as mensagens (D-CM-051). (5) Saem do texto E-CM-022 e a pendência P-CM-044. - **v5.8** (26/10/2026) — Acompanha 01-Definiçã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), pedido do solicitante ao rever E-CM-003 e E-CM-004 do guia de desenvolvimento. (1) 2.3, 2.4, 2.8 e critérios de aceitação: chips de urgência leves (alternativa A escolhida pelo solicitante): Crítico em fundo `color-error-light` e Atenção em `color-highlight-light`, sem contorno, texto e ícone na cor `-dark` da família, peso `font-weight-medium` (antes: fundo `-medium`, contorno de 1px e texto `neutral-darker`). O chip "há 1h20" da consulta em atendimento (2.3), que reaproveita os tokens do chip "Atenção", acompanha a mudança. (2) 2.8: o foco visível passa de anel de 3px para anel de 2px em `color-neutral-dark`, afastado 2px, e a linha de Input descreve a borda de 2px `color-neutral-dark` como foco do campo de busca, sem anel extra (Design System, seção 11, de 26/10/2026) — o que também desfaz a divergência entre o anel de 3px e a borda de 2px que o cenário CT-ACES-06 registrava. (3) E-CM-003 resolvida; E-CM-004 resolvida nos chips e mantida só para botões e toggles; novas E-CM-023 a E-CM-025 e P-CM-043 a P-CM-045 (Registro de Decisões v1.7). Revisão por Dois Críticos (26/10/2026): corrigidos a descrição do anel do card e o contraste do anel, e o termo "Crítico"/"Urgentes" ganhou uma linha de terminologia na 2.4. - **v5.7** (21/10/2026) — Acompanha 01-Definiçã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). (1) 2.5 e 2.8: destaque de conversa não lida passa a ícone e borda lateral em `color-secondary-dark`, como o protótipo já fazia; o texto anterior (`primary-pure` no ícone, `secondary-pure` na borda) dava 1,7:1 e 2,0:1 sobre branco, abaixo do mínimo de 3:1 para componente gráfico. (2) 2.6 e 2.8: percentual da barra de progresso em `font-size-xs` (10px), como o protótipo; 9px não existe na escala do Design System. Pendências levantadas pelo crítico técnico na v5.5 e resolvidas pelo solicitante. - **v5.6** (21/10/2026) — Acompanha 01-Definiçã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). (1) Mensagens do sistema e rótulo "p/ assinar (próx. N dias)" do KPI de prescrições: seguem o idioma da clínica atual, não o do usuário (DT-012). (2) Conformidade SBIS, ECF.17.18: registrado que o idioma exibido é o da clínica. Sem mudança de contrato. - **v5.5** (14/10/2026) — Acompanha 01-Definição v5.5, 03-Protótipo v5.5, 04-Mapeamento v5.5, Cenários de Teste v5.5 e 05-Registro de Decisões v1.4. Decisão em 05 - Registro de Decisões v1.4 (D-CM-043). (1) 2.8: o botão Primary (Assinar) aponta para `--color-on-primary` na seção 4a do Design System, onde o token foi incorporado em 14/10/2026 (aceito em D-CM-027). (2) 2.8: duas linhas corrigidas para o que a Seção 2.2 e o protótipo já descreviam desde versões anteriores — o número de alertas do KPI é texto em `color-error-pure` (não um badge preenchido com texto `base-pure`, que daria 3,7:1 em texto pequeno) e o contador do painel é um badge em `color-neutral-lighter` com texto `color-neutral-darker` (não um badge `primary-pure` com texto `base-pure`, que daria 1,7:1). Achado do Designer ao incorporar o token; a regra do Design System (texto sobre `primary-pure` usa `--color-on-primary`) continua valendo se um badge verde for adotado no futuro. (3) Os valores de cor dos tokens seguem o Design System de 14/10/2026 (regra C8 e `neutral-pure` claro `#526A90`); nenhum uso de token mudou na Central. - **v5.4** (13/10/2026) — Acompanha 01-Definiçã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) 2.1 e 2.10: o número de prontuário não é critério da busca comum; chave `id:` só para a certificação; conformidade SBIS de idioma e de "Meus/Todos" (D-CM-036). (2) 2.2: total de "Procedimentos Hoje" inclui os finalizados (D-CM-038); termos de "P/ revisar" e "P/ assinar" com dias de calendário, assinatura na janela e administração iniciada (D-CM-037, 039, 040). (3) 2.4: janelas de assinatura e de revisão em dias de calendário; assinatura feita depois de a janela de revisão abrir dispensa a revisão (E-CM-019); administração iniciada retira só "a revisar" (E-CM-018); textos do tempo restante e do atraso (D-CM-041, E-CM-020) e chaves de i18n novas (`presc-restante-min`, `presc-atrasada-hm`, `presc-atrasada-dias`; `presc-atrasada-h` e `chip-T_restante` removidas). (4) 2.5: confirmação ao resolver ou descartar, com textos nos três idiomas (D-CM-032, E-CM-021). (5) 2.6: ícone de 1ª Consulta (D-CM-029), "sem tempo previsto" (D-CM-034), status em ordem de avaliação, Completo e Finalizado (D-CM-030). (6) 2.8: escolhas E-CM-001, 002, 008 e 017 confirmadas; ícone da 1ª Consulta sem foco de teclado (D-CM-035). (7) 2.9: `firstTime` e `startTime` "HH:mm" em `procedures`; status `completed`/`finished` no lugar de `administered`; mensagens com tipo único `Response`; origem `User | System` (D-CM-042). Seguem a confirmar E-CM-003, 004, 018 a 022. (8) Revisão por Dois Críticos: `isPreferredReviewer` nos dois tipos (alinhado ao Mapeamento); critérios de aceitação da assinatura na janela separados por dia de aplicação; "P/ assinar" é o número que diminui ao assinar; 2.10 sem afirmações de conformidade sem base (P-CM-037, P-CM-038); resíduos de "um clique" removidos. - **v5.3** (10/10/2026) — Acompanha 01-Definiçã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) 2.2: subtexto "X pendentes (Y atrasadas)" (D-CM-018). (2) 2.3: destaque da consulta em atendimento além do previsto, "há 1h20" (D-CM-017, E-CM-017); ordem das tags e do ícone (D-CM-022); dica sem marcador de escolha (confirmada, D-CM-026). (3) 2.4: janela de "a revisar" em dias de calendário, com critérios de aceitação novos (D-CM-023); "2h atrasada" no lugar do tempo negativo (E-CM-016). (4) 2.6: painel "Pacientes em procedimento" (D-CM-019). (5) 2.9: `elapsedMinutes`, `overtime` e `minutesRemaining`; tags já ordenadas. (6) i18n: textos de "atrasada", "há {t}", singulares de pendente/atrasada e nome do painel em en-US e es-419. - **v5.2** (09/10/2026) — Acompanha 01-Definiçã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) 2.2: o KPI "p/assinar (próx. N dias)" é montado no front a partir de `toSignWindowDays` (E-CM-010), com singular para 1 dia; padrão de revisão de 1 dia. (2) 2.3: dica do ícone de 1ª Consulta ao toque e ao mouse; o primeiro toque fora só fecha a dica; a dica não fecha na atualização automática (D-CM-016, E-CM-013). (3) 2.4: prescrição vencida na lista, com tempo negativo e chip vermelho (D-CM-013, E-CM-011); novos critérios de aceitação. (4) 2.5: sem "desfazer" nem texto de auditoria (D-CM-014). (5) 2.6: progresso por `TempoAplicacao`; sem tempo, sem barra (D-CM-015, E-CM-012); barra em `error-dark`; status "Em administração". (6) 2.9: `progress` e `toSignWindowDays` no contrato; `to_sign` inclui vencidas. (7) i18n: chave da dica "1ª Consulta", correções de plural e de "Completed" duplicado. - **v5.1** (09/10/2026) — Acompanha 01-Definição v5.1, 03-Protótipo v5.1 e 04-Mapeamento v5.1; decisões em 05 - Registro de Decisões. (1) 2.2: "Atrasadas" não conta consultas em atendimento (D-CM-008); "P/ revisar" com janela padrão de 2 dias, parâmetro `NumeroDiasRevisaoPrescricoes` (D-CM-006). (2) 2.3: ícone de 1ª Consulta no lugar da tag (D-CM-003); selo "Atrasado" único, sem distinguir "Esperando" de "Não chegou" (D-CM-004); diagnóstico de prontuário com início no futuro não é exibido (D-CM-010). (3) 2.4: chips Urgente/Atenção com fundo `-medium`, contorno, texto escuro e ícone (E-CM-004); padrão de 2 dias para "a revisar" nos critérios de aceitação. (4) 2.5: resolver/descartar vale para todos os destinatários (D-CM-011). (5) 2.6 e i18n: painel "Procedimentos hoje" (D-CM-005). (6) 2.7: faixa de sem conexão no formato da Agenda (D-CM-007); a regra do horário com vários painéis fica como escolha do Designer (E-CM-001). (7) 2.8: nova subseção "Acessibilidade (transversal)" com critérios de aceitação (D-CM-012); linha do ícone de 1ª Consulta; botões, chips e toggle com os tokens do protótipo (E-CM-002 a E-CM-004); nota do chip de urgência recolocada fora da tabela; foco da busca em anel de 3px. 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: nome do campo `Conversa.IdPaciente`; critérios de aceitação dos chips alinhados aos tokens da Seção 2.4; Finalizado sem redução de opacidade; correção de textos i18n; tabela da 2.8 sem linha em branco; redação sem referência à origem do pedido. 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 ("Pode ajustar todos os pontos pendentes derivadas das outras funcionalidades que estamos desenvolvendo"). Acompanha 01-Definição v5.0. **Vindos da Agenda do Médico:** (1) RN-CM-030 passa a falar do bloqueio feito pela Recepção (RN-AGM-019) em 2.2, 2.3 e nos critérios de aceitação; (2) `attendanceMode` deixa de citar `appointmentType`, campo que saiu da Agenda; (3) contrato de `appointments`: `id` e `patient.id` inteiros (o exemplo trazia `"uuid"`, divergente do Mapeamento 4.1 — achado registrado na Agenda v1.13); (4) contrato de `tags` (appointments e procedures): lista de objetos `{ code, description, color }`, como na Agenda v1.14 — o Mapeamento já dizia que cor e descrição vêm de `ProgramaApoio`, mas o contrato só trazia o nome; a 1ª Consulta sai da descrição de `tags` (é o campo `firstTime`, RN-CM-028); tags atribuídas no prontuário entram (RN-CM-025). **Vindos do Design System:** (5) faixa de sem conexão (seção 7, de 07/10/2026) no lugar do ícone "Offline" por painel — 2.7 reescrita, com critérios de aceitação e `MSG_connectionLost`; falha no carregamento inicial continua em `MSG_endpointFail`; (6) tema claro e escuro (seções 1 a 6): parágrafo no início da Seção 2, seletor "Tema" no menu do avatar (`MSG_themeOptions`, texto igual ao da Agenda, MSG-BAGM-17); (7) cores de status e de borda por tokens `--color-status-*` (seção 4) no lugar de valores fixos — o Finalizado passa do roxo `#9679E1` citado na v4.37 para o par `#EDE7FA`/`#6A4FC4` que o Protótipo já usava e o Design System adotou; o avatar de iniciais da consulta usa o mesmo par do chip; tag com cor do cadastro por `.chip-tag` (seção 5). **[PROPOSTA do Designer, a confirmar]** horário exibido na faixa quando vários painéis falham (o da atualização bem-sucedida mais antiga). **Levados ao solicitante, sem mudança:** ícone de 1ª Consulta (Agenda v1.6, `circle-number-1`); sinalizador de atraso "Esperando"/"Não chegou" (Agenda, RN-AGM-009: "pode ser levada à Central depois de validada"); nomes "Pacientes na Clínica Hoje" × "Procedimentos na Clínica". A origem da tag VIP deixa de ser pendência: segue a decisão do solicitante na Agenda do Médico (Mapeamento v1.6) — VIP atribuída no cadastro, `Paciente.PacienteVip` não é lido. **Correções de consistência (revisão):** nomes dos tokens de status (`scheduled`, `waiting`, `checked`, `consultation`, `finished`, como no Design System); valores hexadecimais dos critérios de aceitação de 2.2, 2.4 e 2.6 trocados por tokens; emoji em "Atrasado" e no prazo da conversa trocados por selo/ícone Lucide; ids de `procedures`, `prescriptions`, `patients/search` e `patient.id` de `conversations` inteiros (DDL e Mapeamento); cor de tag ausente ou inválida cai para `color-neutral-lighter`. Protótipo 5.0 acompanha. - **v4.37** (29/09/2026) — Alinhamento com a Agenda do Médico (Especificação v1.1), aprovado pelo solicitante: (1) RN-CM-030 (nova na Definição v4.42) aplicada ao KPI "Consultas Hoje" (2.2) e ao painel de Consultas (2.3), com um critério de aceitação em cada; (2) o destino do clique no KPI "Consultas Hoje" era chamado de "tela de Agenda de Consultas" — é a Agenda do Médico, a mesma aberta pelo título do painel; texto e critério de aceitação corrigidos; (3) o item do card de consulta "Tipo de consulta (Presencial / Teleatendimento)" descrevia na verdade o modo de atendimento — renomeado para "Modo de atendimento", e o campo `type` de `GET /appointments` renomeado para `attendanceMode`, mesmo nome já usado na Agenda do Médico (onde "tipo de consulta" é outro campo, configurável pela clínica). Nenhuma mudança visual no protótipo além do texto de navegação do KPI. **Cenários de Teste v1.20 não foi atualizado nesta rodada** — RN-CM-030 e o novo nome de campo afetam cenários do painel de Consultas e do KPI; atualização pendente, a combinar com o solicitante (documento em edição por ele). Acompanha 01-Definição v4.42, 03-Protótipo v3.19 e 04-Mapeamento de BD v4.48. - *(sincronização, 29/09/2026)* — sem mudança de conteúdo deste documento (esclarecimentos de RN-CM-029 e da resolução do nome da equipe são de nível de banco de dados, sem efeito na UI/UX aqui especificada); apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.41 e Mapeamento de BD v4.47 — ver Histórico desses documentos. - **v4.36** (29/09/2026) — Acompanha 01-Definição v4.40: corrigida a Seção 2.4, que afirmava que o toggle "Meus/Todos" só afeta "a revisar" e que "a assinar" é sempre do médico logado (RN-CM-012: só o próprio prescritor assina) — o solicitante esclareceu que qualquer médico pode assinar, e que a citação a RN-CM-012 estava errada (essa regra trata do modo de assinatura, não de quem pode assinar). O toggle passa a afetar as duas categorias igualmente: "Meus" = prescritor ou médico assistente do paciente; "Todos" = toda a clínica. Atualizados: parágrafo do filtro, 2 Critérios de Aceitação sobre o comportamento do toggle, 2 Critérios de Aceitação sobre o estado vazio, e a descrição de `reviewScope` no endpoint (Seção 2.9). Sem mudança de UI/prototipagem visível — o comportamento do toggle já existia; só a extensão da sua abrangência muda no back-end. Acompanha 04-Mapeamento de BD v4.46 e Cenários de Teste v1.20. Revisão por Dois Críticos: não aplicável — correção pontual a partir de esclarecimento direto do solicitante. - **v4.35** (28/09/2026) — Acompanha 01-Definição v4.39: RN-CM-020 simplificada, abolindo "assinatura vencida" — §2.4 reescrita para refletir a nova regra de 2 categorias sem expiração: "a assinar" ganha janela própria de 7 dias, agora parametrizada (`PrescricaoTempoAssinatura`, [PROPOSTA]); "a revisar" perde a exigência de "assinatura dentro da validade" (removida das duas ocorrências nos Critérios de Aceitação) e ganha, junto com "a assinar", um filtro por `Prescricao.Situacao` (só `P`/`G`/`A`/`O`) — pedido do solicitante, para que prescrições já finalizadas/faturadas não se acumulem na lista de revisão. Novos critérios de aceitação cobrindo o default de 7 dias, o corte da janela de assinatura e o filtro de situação. Nenhuma mudança de UI/prototipagem — o painel já exibia as mesmas 2 ações e o mesmo toggle. Acompanha 04-Mapeamento de BD v4.45 e Cenários de Teste v1.19. - **v4.34** (28/09/2026) — Pedido do solicitante, generalizando a v4.33 (Painel de Consultas) para os outros 2 painéis com toggle: (1) **Prescrições Pendentes (2.4):** `MSG_prescriptionNone` ("Sem prescrições pendentes") dividida em `MSG_prescriptionNoneMine` = "Sem prescrições pendentes para você" (toggle 'Meus') e `MSG_prescriptionNoneAll` = "Sem prescrições pendentes" (toggle 'Todos', texto inalterado). (2) **Procedimentos na Clínica (2.6):** `MSG_proceduresNone` ("Sem pacientes para o dia") dividida em `MSG_proceduresNoneMine` = "Sem pacientes seus para o dia" (toggle 'Meus') e `MSG_proceduresNoneAll` = "Sem pacientes para o dia" (toggle 'Todos', texto inalterado). As duas novas mensagens ("...para você"/"...seus...") são proposta do Designer, confirmada pelo solicitante — diferente da mensagem de Consultas (v4.33), que foi ditada literalmente por ele; a mensagem 'Todos' de cada painel mantém o texto original, sem mudança. Atualizados, nas duas seções: parágrafo "Estado vazio", 1 Critério de Aceitação dividido em 2, e a tabela de Internacionalização (2 linhas no lugar de 1). Sem mudança de endpoint/campo — distinção só de apresentação, resolvida no front a partir do estado do toggle já existente (mesmo padrão da v4.33). Acompanha 03-Protótipo v3.18 (`renderPrescricoes()`/`renderClinica()`) e Cenários de Teste v1.18 (CT-PRES-06 e CT-PROC-07 divididos por estado do toggle; achado de que o estado 'Todos' vazio não é reproduzível com a massa atual em nenhum dos dois painéis, diferente de Consultas — 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 Mapeamento de Banco de Dados v4.44 (contexto do solicitante incorporado ao achado em aberto sobre `Paciente.PacienteVip` — ver Histórico desse documento). - **v4.33** (28/09/2026) — Pedido direto do solicitante: a mensagem de estado vazio do Painel de Consultas (2.3) era única ("Nenhuma agenda para este dia", `MSG_appointmentNone`) para os dois estados do toggle 'Pendentes'/'Todas' — passa a ser duas mensagens distintas, definidas pelo solicitante: `MSG_appointmentNonePending` = "Nenhuma agenda pendente para o dia" (toggle 'Pendentes') e `MSG_appointmentNoneAll` = "Nenhuma agenda para o dia" (toggle 'Todas', nota: a palavra "este" foi removida da mensagem original por decisão do solicitante, não é erro de digitação). Atualizados: parágrafo "Estado vazio", os 2 Critérios de Aceitação correspondentes (antes 1) e a tabela de Internacionalização (2 linhas no lugar de 1, 3 idiomas). Sem mudança de endpoint/campo — a distinção é só de apresentação, resolvida no front a partir do estado do toggle já existente. Acompanha 03-Protótipo v3.17 (`renderConsultas()`) e Cenários de Teste v1.16 (CT-CONS-06 dividido em 06.1/06.2). - *(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 Definição v4.38 e Mapeamento de Banco de Dados v4.42 (default de 180 dias para `TempoPacienteAtivo*`, RN-CM-024). - **v4.32** (28/09/2026) — Pedido do solicitante: a janela de antecedência de revisão (RN-CM-020, parâmetro `PrescricaoTempoRevisao`) passa a ser expressa em dias, com valor-padrão de 1 dia (antes descrito como 24h). Ajustados: definição de "P/ revisar" (2.2), item "Prescrições para revisar" (2.4) e os 3 Critérios de Aceitação de "a revisar" (padrão de 1 dia quando não configurado; exemplo passa de 48h para 2 dias — valor ilustrativo). Comportamento equivalente ao anterior: 1 dia = 24 horas contadas a partir de agora. Limiares dos chips de urgência (12h/24h, RN-CM-011) e o campo `hoursRemaining` não mudam. Sem mudança de endpoint/campo. - **v4.31** (28/09/2026) — Pedido do solicitante, após a pergunta "existe algum parâmetro para o período em que uma prescrição entra em revisão, ou está fixo em 24h?": a auditoria mostrou que 01-Definição (RN-CM-020) e 04-Mapeamento de BD (Seção 4.6, `IpParametro.PrescricaoTempoRevisao`, default de 24h via `COALESCE`) já tratavam a janela como parâmetro por clínica, mas esta Especificação ainda a descrevia como "1 dia (24h)" fixo. Ajustados: (1) definição de "P/ revisar" do KPI de Alertas (2.2); (2) item "Prescrições para revisar" do Painel de Prescrições Pendentes (2.4), agora apontando para o parâmetro e explicitando a independência em relação aos limiares fixos dos chips (RN-CM-011); (3) Critério de Aceitação de "a revisar" reescrito sem valor fixo, e 2 critérios novos — valor-padrão de 24h quando o parâmetro não está configurado, e exemplo com janela de 48h (valor ilustrativo, não é um padrão). Sem mudança de endpoint/campo — `hoursRemaining` e `type` continuam iguais; a leitura do parâmetro fica no backend (Seção 4.6 do Mapeamento, sem mudança). Protótipo v3.16 não muda: os dados simulados usam o valor-padrão de 24h. - *(sincronização, 28/09/2026)* — sem mudança de conteúdo deste documento; a descrição da regra de assinar/revisar (2.4) já era compatível com a regra corrigida de RN-CM-020 nesta rodada (2 níveis de precedência: assinatura vencida sempre volta para "a assinar"; "a revisar" só com assinatura válida e aplicação próxima) — a Seção 2.4 nunca chegou a descrever a simplificação incorreta da rodada revertida (25-27/09/2026), então não havia nada para desfazer aqui. Apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.36 (RN-CM-020 corrigida, RN-CM-029 nova) e Mapeamento de Banco de Dados v4.40 — ver Histórico desses dois documentos. - **v4.30** (25/09/2026) — Pedido do solicitante, durante a validação de `Cenários de Teste v1.8`: complementando RN-CM-027 e RN-CM-028 (01-Definição v4.35). (1) Painel de Procedimentos (2.6): adicionado o parágrafo "Ordenação" (ausente até esta versão) e um novo Critério de Aceitação para o desempate alfabético. (2) Painel de Consultas (2.3): a lista de campos do card ajustada para remover "1ª Consulta" como exemplo de tag de `ProgramaApoio` (não é — RN-CM-028) e apontar para a regra própria dessa tag. Sem mudança de endpoint/campo (Seção 4 não muda — ver Mapeamento de Banco de Dados). Revisão por Dois Críticos (crítico técnico): nenhuma correção necessária. - **v4.29** (24/09/2026) — Confirmação do solicitante, em resposta à pergunta "qual é a regra de priorização do painel de Mensagens?": o critério de desempate dentro da camada das conversas lidas (prazo, depois atividade mais recente — os mesmos dois critérios já usados na camada das não lidas) estava registrado desde a v4.21 como proposta do Designer, pendente de confirmação ("a confirmar com o solicitante"). Solicitante confirmou manter a regra como está. Duas frases ajustadas (parágrafo de escopo e parágrafo "Ordenação", ambos em 2.5) para remover a pendência — sem mudança de comportamento, só fechamento de uma decisão em aberto. RN-CM-015 (01-Definição) não muda — já era atemporal, nunca mencionou a pendência de confirmação nem o critério de desempate em si. Revisão por Dois Críticos: não aplicável (fechamento de pendência já documentada, sem novo conteúdo técnico a revisar). - *(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.28** (23/09/2026) — Pedido do solicitante, complementando RN-CM-026 (01-Definição v4.34): documentado que o horário exibido no card de Procedimentos na Clínica (2.6) passa a ser o de término, não o de início, quando o status é Finalizado. Atualizados a descrição do campo na lista de conteúdo do card e um novo Critério de Aceitação. Sem mudança de endpoint/campo nesta seção (mapeamento técnico completo: Seção 4.3 do Mapeamento de Banco de Dados, v4.38). Revisão por Dois Críticos (crítico técnico): nenhuma correção necessária. - **v4.27** (23/09/2026) — Pedido do solicitante, complementando RN-CM-011 (01-Definição v4.33): documentado o terceiro caso da escala de urgência (a partir de 24h restantes, sem chip — só texto simples do tempo restante), que não existia em nenhuma versão anterior. Atualizados: parágrafo "Ordenação" (2.4), novo Critério de Aceitação com o caso de 30h restantes, e nota na tabela de Componentes do Design System (2.8) esclarecendo que o Chip de urgência só se aplica dentro de 24h. Sem mudança de endpoint/campo (Seção 4 não muda — ver Mapeamento de Banco de Dados). Revisão por Dois Críticos (crítico técnico): nenhuma correção necessária — nova linha de i18n não foi necessária, o texto simples reaproveita o rótulo "T RESTANTES" já existente. - *(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). - *(sincronização, 22/09/2026)* — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.32 e Mapeamento de Banco de Dados v4.35 (RN-CM-025, vigência da tag por `ProgramaApoio.DataInicio`/`DataFim` — ver Histórico desses dois documentos). - *(sincronização, 22/09/2026)* — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.31 e Mapeamento de Banco de Dados v4.34 (RN-CM-025 e filtro de tags por `MostrarEm` — ver Histórico desses dois documentos). - *(sincronização, 16/09/2026)* — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.28 e Mapeamento de Banco de Dados v4.31 (RN-CM-023 corrigida — ver Histórico desses dois documentos). - *(sincronização, 16/09/2026)* — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.29 e Mapeamento de Banco de Dados v4.32 (RN-CM-023 corrigida novamente — ver Histórico desses dois documentos). - *(sincronização, 16/09/2026)* — sem mudança de conteúdo deste documento; apenas a linha de cabeçalho "Documentos desta funcionalidade" atualizada para apontar Definição v4.30 e Mapeamento de Banco de Dados v4.33 (RN-CM-023 corrigida pela terceira vez — ver Histórico desses dois documentos). - **v4.26** (16/09/2026) — Rodada de correções após a primeira revisão de versão aprovada (Agente de UI/UX, ver Skill Designer). Nome do painel da Seção 2.5 trocado de "Notificações" para "Mensagens" — a Definição e o Protótipo já usavam "Comunicação" (também trocado para "Mensagens" nesses dois documentos), e o link de navegação deste mesmo painel já apontava para a "tela dedicada de Mensagens"; as três grafias diferentes para o mesmo painel foram unificadas em "Mensagens". Atualizado: título da Seção 2.5, corpo do texto, linha "Navegação", critério de aceitação do estado vazio, tabela de Internacionalização (`painel-título` e `MSG_notificationNone`, nas 3 colunas de idioma). - **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`.