# Central do Médico (Cockpit) — Registro de Decisões (v1.20)

**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) · [Cenários de Teste](./Cen%C3%A1rios%20de%20Teste%20v6.0.md) (v6.0) · 05 - Registro de Decisões (v1.20)

---

Este documento reúne, num só lugar, as decisões do solicitante que moldam a Central do Médico, as escolhas feitas pelo Designer que ainda aguardam confirmação e as questões em aberto. Ele existe para que as decisões não fiquem espalhadas pelos Históricos de Versões dos outros documentos, onde cada uma aparece misturada à descrição da mudança que ela provocou. Os Históricos continuam registrando *o que mudou em cada versão* e citam o código da decisão (D-CM-xxx) em vez de repetir o raciocínio.

Convenção: **D-CM-xxx** = decisão do solicitante (vigente); **E-CM-xxx** = escolha do Designer, a confirmar; **P-CM-xxx** = questão em aberto, aguardando o solicitante. Decisões anteriores à numeração (v1.0 a v4.48) permanecem descritas nos Históricos de cada documento, onde o contexto delas está inteiro.

## 1. Decisões do solicitante

| ID | Data | Decisão | Onde está aplicada |
| --- | --- | --- | --- |
| D-CM-001 | 08/10/2026 | O bloqueio de horário na agenda do médico é feito pela Recepção (RN-AGM-019, Agenda do Médico); ele não é consulta, não aparece no painel de Consultas e não entra em nenhum número do indicador "Consultas Hoje" (RN-CM-030). | Definição (RN-CM-030); Especificação 2.2/2.3; Mapeamento 4.1/4.2; Cenários CT-KPI-07, CT-CONS-10 |
| D-CM-002 | 08/10/2026 | A tag VIP vem de `ProgramaApoioPaciente` (cadastro do paciente), como as tags administrativas; `Paciente.PacienteVip` não é lido por enquanto. VIP é exceção ao `MostrarEm` e à vigência da tag. | Definição (RN-CM-025); Mapeamento 4.1 (`tags`) |
| D-CM-003 | 09/10/2026 | A 1ª Consulta deixa de ser um chip/badge de texto e passa a ser o ícone `circle-number-1` (Tabler Icons), 18px, sem fundo, cor `--color-first-visit`, logo depois do nome do paciente, com rótulo acessível "1ª Consulta" — o mesmo da Agenda do Médico. | Definição (RN-CM-028); Especificação 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-03) |
| D-CM-004 | 09/10/2026 | A Central não diferencia "Esperando" (paciente já na clínica) de "Não chegou": o selo "Atrasado · Nmin" é o mesmo para qualquer consulta atrasada e não iniciada. A distinção existe só na Agenda do Médico. | Especificação 2.3 (Atraso); Protótipo |
| D-CM-005 | 09/10/2026 | O painel do quadrante inferior direito passa a se chamar "Procedimentos hoje" (antes "Procedimentos na Clínica"). O indicador da barra continua "Procedimentos Hoje". (O nome do painel foi trocado de novo em D-CM-019.) | Definição; Especificação 2.2, 2.6 e i18n; Mapeamento; Protótipo; Cenários |
| D-CM-006 | 09/10/2026 | A janela de "a revisar" (RN-CM-020) usa o parâmetro do sistema atual `NumeroDiasRevisaoPrescricoes`, no lugar do `PrescricaoTempoRevisao` que havia sido proposto. Com a linha ausente, vale o padrão de 1 dia, que é o padrão do Gemed 2.1 (o código do sistema atual assume 2; o solicitante manteve 1). A janela segue contínua (N × 24h a partir de agora) — **substituído nesse ponto por D-CM-023** (dias de calendário). | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6, 4.7 e Seeds; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-007 | 09/10/2026 | A faixa de sem conexão segue o formato da Agenda do Médico e do Design System, seção 7: ícone `wifi-off` e "Sem conexão — dados atualizados às {hh:mm}", `role="status"`. | Especificação 2.7; Protótipo; Cenários (CT-SIS) |
| D-CM-008 | 09/10/2026 | "Atrasadas", no indicador "Consultas Hoje", não conta as consultas já em atendimento: só as não iniciadas com horário previsto vencido. As em atendimento continuam sendo "pendentes". | Especificação 2.2; Mapeamento 4.2 (`delayed`); Protótipo; Cenários (CT-KPI-01) |
| D-CM-009 | 09/10/2026 | A data que vale para a vigência do prontuário (`PEP`) é `PEP.DataInicioUTC` (e `DataFimUTC`); `PEP.DataInicio`/`DataFim` não são lidos. | Mapeamento 4.1 (`tags`, `patient.diagnosis`); Cenários |
| D-CM-010 | 09/10/2026 | Um diagnóstico cujo prontuário (`PEP`) só começa depois de hoje não é exibido no card. Só o início é avaliado. | Especificação 2.3; Mapeamento 4.1 (`patient.diagnosis`); Cenários (CT-CONS-13) |
| D-CM-011 | 09/10/2026 | Resolver ou descartar uma conversa vale para todos os destinatários: uma conversa endereçada a uma equipe ou a mais de uma pessoa sai do painel de todos quando qualquer um a resolve ou descarta. | Definição (RN-CM-015); Especificação 2.5; Mapeamento 4.9; Cenários (CT-MSG-17/18) |
| D-CM-012 | 09/10/2026 | Os defeitos de acessibilidade e de interface apontados na revisão da v5.0 devem ser corrigidos (contraste, teclado, modal, avisos, alvos de toque, movimento reduzido, tela de 360px, cabeçalho preso em até 1024px). | Especificação 2.8 (Acessibilidade); Protótipo; Cenários (CT-ACES) |
| D-CM-013 | 09/10/2026 | Prescrição cuja hora de aplicação já passou e que ainda não foi assinada (ou revisada) continua na lista, com o chip vermelho, como antes de passar a hora; continua contando em "Urgentes" até ser assinada ou revisada. (Resolve P-CM-001.) | Definição (RN-CM-011, RN-CM-020); Especificação 2.4; Mapeamento 4.6/4.7 (`hoursRemaining`); Protótipo; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-014 | 09/10/2026 | Resolver ou descartar uma conversa não tem "desfazer": a conversa é uma ferramenta de comunicação e facilitação de tarefas, não um processo auditado. Não há texto de auditoria nas telas nem na especificação. (Resolve a parte de desfazer de P-CM-010.) | Definição (RN-CM-015); Especificação 2.5 |
| D-CM-015 | 09/10/2026 | O progresso do procedimento usa o tempo de aplicação da prescrição, `Prescricao.TempoAplicacao` (em minutos), e não `Agenda.Tempo`. (Resolve P-CM-013.) | Definição (RN-CM-016); Especificação 2.6; Mapeamento 4.3 (`progress`); Protótipo; Cenários (CT-PROC) |
| D-CM-016 | 09/10/2026 | O ícone de 1ª Consulta abre uma dica ao ser tocado, porque o `title` nativo não aparece em tela de toque. (Resolve P-CM-014.) | Definição (RN-CM-028); Especificação 2.3 e 2.8; Protótipo |
| D-CM-017 | 10/10/2026 | Consulta em atendimento além da duração prevista da agenda (`Agenda.Tempo`): o card mostra o tempo decorrido em destaque ("há 1h20"), com ícone e cor de atenção, para incomodar o olhar — é provavelmente uma anomalia (atendimento não fechado, ou iniciado sem querer). Sem tolerância. (Escolhida a proposta principal de P-CM-011.) | Definição (RN-CM-031); Especificação 2.3 e 2.9; Mapeamento 4.1 (`elapsedMinutes`, `overtime`); Protótipo; Cenários (CT-CONS-17) |
| D-CM-018 | 10/10/2026 | O subtexto do indicador "Consultas Hoje" passa a "X pendentes (Y atrasadas)" — as atrasadas já estão contadas nas pendentes. (Escolhida a opção (a) de P-CM-012.) | Especificação 2.2 e i18n; Protótipo; Cenários (CT-KPI-01) |
| D-CM-019 | 10/10/2026 | O painel do quadrante inferior direito passa a se chamar "Pacientes em procedimento" (en-US "Patients in procedure", es-419 "Pacientes en procedimiento"); o indicador da barra continua "Procedimentos Hoje". Substitui o nome de D-CM-005. | Definição; Especificação 2.2, 2.6 e i18n; Mapeamento; Protótipo; Cenários |
| D-CM-020 | 10/10/2026 | O progresso do procedimento conta o tempo desde `Agenda.DhAtendimentoIniUTC`, sobre `Prescricao.TempoAplicacao`. (Confirma o que já estava; resolve P-CM-017.) | Especificação 2.6; Mapeamento 4.3 (`progress`) |
| D-CM-021 | 10/10/2026 | A vigência de tag (da própria tag e da atribuição ao paciente, no cadastro e no prontuário) é comparada só pela data, no fuso da clínica, sem a hora: início e fim são inclusivos. Decisão já tomada em outra conversa do projeto e confirmada aqui. Substitui a escolha E-CM-014. | Definição (RN-CM-025); Mapeamento 4.1 (`tags`, Domínios); Cenários (CT-CONS-11, 16) |
| D-CM-022 | 10/10/2026 | Ordem dos chips no card: primeiro o ícone de 1ª Consulta (junto ao nome), depois as tags assistenciais (`ProgramaApoio.Finalidade = 'A'`), depois as administrativas (`'D'`, como VIP); dentro de cada grupo, ordem alfabética pela sigla. (Resolve P-CM-021.) | Definição (RN-CM-025); Especificação 2.3 e 2.9; Mapeamento 4.1 (`tags`); Protótipo; Cenários (CT-CONS-15) |
| D-CM-023 | 10/10/2026 | A janela de "a revisar" é em dias de calendário no fuso da clínica, não em 24 horas: com N dias e hoje o dia 10, entram as aplicações dos dias 10 a 10+N (N = 1: dias 10 e 11, até 23:59), mais as já vencidas. Substitui a escolha E-CM-005 (janela contínua). | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6 e 4.7; Protótipo; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-024 | 10/10/2026 | Uma prescrição vencida sem desfecho fica na lista e em "Urgentes" até ser assinada ou revisada; na prática ela será cancelada, reprogramada ou aplicada, e não fica nesse estado para sempre. Não há limite para trás nem ação de dispensar. (Resolve P-CM-020.) | Definição (RN-CM-011, RN-CM-020) |
| D-CM-025 | 10/10/2026 | Prescrições sem `IdAgenda` ficam fora das listas e das contagens. (Resolve P-CM-027.) | Mapeamento 4.6 e 4.7 |
| D-CM-026 | 10/10/2026 | Confirmadas as escolhas do Designer E-CM-010 (rótulo "p/assinar" montado no front), E-CM-012 (sem tempo de aplicação, sem barra), E-CM-013 (comportamento da dica da 1ª Consulta) e E-CM-015 (`hoursRemaining` truncado, classificação por minutos). | Especificação 2.2, 2.3, 2.6 e 2.9; Mapeamento 4.6 |
| D-CM-027 | 13/10/2026 | Confirmadas as escolhas do Designer: E-CM-001 (faixa de sem conexão com o horário da atualização bem-sucedida mais antiga entre os painéis que falham; presa junto ao cabeçalho até 1024px), E-CM-002 (token `--color-on-primary`, texto escuro sobre o verde primário nos dois temas — incorporado ao Design System em 14/10/2026, D-CM-043; guia para o desenvolvedor em `Para Desenvolvedores/`), E-CM-006 (traduções en-US e es-419 do painel, de "há {t}" e "atrasada", da dica da 1ª Consulta e do status Completo), E-CM-007 (só o ponto do selo "Atrasado" pulsa), E-CM-008 (barra de progresso do procedimento em `neutral-dark`, `error-dark` acima de 100%), E-CM-009 (bordas laterais de Recepcionado e Aguardando ficam como estão), E-CM-016 ("atrasada" no feminino; o formato do texto mudou em D-CM-041) e E-CM-017 (destaque da consulta além do previsto com os tokens do chip "Atenção", ícone `clock-alert`, minutos com dois dígitos). Seguem a confirmar E-CM-003 e E-CM-004. | Especificação 2.3, 2.4, 2.6, 2.7, 2.8; Protótipo; Guia do Design System |
| D-CM-028 | 13/10/2026 | No escopo "Meus", a prescrição de um colega ausente fica fora da lista e do indicador do médico logado — aceito. O toggle "Todos" existe para a colaboração: os médicos resolvem as pendências mesmo com o responsável ocupado. (Resposta "sim" à questão P-CM-002.) | Definição (RN-CM-020); Especificação 2.4 |
| D-CM-029 | 13/10/2026 | O contrato de Procedimentos passa a trazer `firstTime` (booleano, `Agenda.PrimeiraConsulta = 'S'`), como a agenda de consultas; o card de procedimento mostra o ícone de 1ª Consulta (RN-CM-028). | Mapeamento 4.3; Especificação 2.6 e 2.9; Protótipo; Cenários (CT-PROC) |
| D-CM-030 | 13/10/2026 | **[O valor de contrato `completed` do status Completo foi substituído por D-CM-074: `administered`.]** Status de procedimento: `ProcedureStatus()` é avaliada em ordem e vale a primeira condição que se aplica — Cancelado, Finalizado (alta: `DhAtendimentoFimUTC` preenchido), Completo (infusão terminada: `DhInfusaoFimUTC` preenchido, sem alta), Em administração (`DhInfusaoIniUTC` preenchido, sem fim de infusão), Preparo, Recepcionado, Aguardando recepção e Agendado. Com `DhInfusaoFimUTC` preenchido o procedimento nunca é "Em administração"; com alta registrada é sempre "Finalizado", mesmo com o fim da infusão vazio (23 linhas da massa). Valores de contrato: `completed` (Completo) e `finished` (Finalizado). (Resolve P-CM-006 e parte de P-CM-033.) | Mapeamento 4.3 e 4.4; Especificação 2.6 e 2.9; Cenários (CT-PROC) |
| D-CM-031 | 13/10/2026 | Haverá um item no Menu Lateral que abre diretamente a tela exclusiva de Pacientes em procedimento (tela ainda não definida); o painel da Central continua sendo o resumo. (Resolve P-CM-009; o nome do item fica em P-CM-036.) | Menu Lateral (outra funcionalidade) |
| D-CM-032 | 13/10/2026 | Resolver e descartar uma conversa passam a pedir confirmação, que informa que a ação vale para todos os destinatários. (Resolve P-CM-010; os textos são escolha do Designer, E-CM-021.) | Definição (RN-CM-015); Especificação 2.5 e i18n; Protótipo; Cenários (CT-MSG) |
| D-CM-033 | 13/10/2026 | Fica como está o texto "p/assinar (próx. 7 dias)", cujo número inclui as prescrições já vencidas. Prescrição de agenda já passada e ainda não assinada não deveria existir: indica falha grave de processo (agenda de paciente que não veio e foi esquecida). A correção é da Recepção, cancelando a agenda ou marcando falta; a Central só deixa o problema visível (D-CM-024). (Resolve P-CM-023.) | Definição (RN-CM-020) |
| D-CM-034 | 13/10/2026 | Procedimento "Em administração" cuja prescrição não tem tempo de aplicação mostra, no lugar da barra, o texto discreto "sem tempo previsto". (Resolve P-CM-024.) | Especificação 2.6 e i18n; Protótipo; Cenários (CT-PROC) |
| D-CM-035 | 13/10/2026 | É aceitável que o ícone da 1ª Consulta não receba o foco do teclado: o leitor de tela lê "1ª Consulta" no nome do card e, com o uso, o médico associa o símbolo. Não há dica ao foco. (Resolve P-CM-025.) | Especificação 2.8 |
| D-CM-036 | 13/10/2026 | Conformidade SBIS, itens de P-CM-026: (b) o requisito de idioma (ECF.17.18) pede português do Brasil, que é o idioma a apresentar na certificação; en-US e es-419 ficam na especificação, fora da avaliação; (c) a busca da Central não usa número de prontuário; existe um artifício na busca, a chave "id:" (busca pelo prontuário), que será mostrado na certificação mas não entra na busca normal por enquanto — o escopo da busca fica como está (resolve P-CM-032); (d) o toggle "Meus" satisfaz ECF.16.01(c) e o "Todos" permite a colaboração entre médicos. Os itens (a) e (e) seguem em P-CM-026. | Especificação 2.10 |
| D-CM-037 | 13/10/2026 | As duas janelas de prescrição — "a assinar" (`PrescricaoTempoAssinatura`, padrão 7 dias) e "a revisar" (`NumeroDiasRevisaoPrescricoes`, padrão 1 dia) — são em dias de calendário no fuso da clínica: "N dias" é o dia de hoje e os N dias seguintes, até 23:59. (Resolve P-CM-028; estende D-CM-023.) | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6 e 4.7; Cenários; Decisões Transversais (DT-005) |
| D-CM-038 | 13/10/2026 | Sem mudança: o total do indicador "Procedimentos Hoje" inclui os procedimentos finalizados; o subtexto é um auxiliar telegráfico de pendências e não precisa fechar a conta. A Especificação passa a dizer isso. (Resolve P-CM-029.) | Especificação 2.2; Cenários (CT-KPI-03) |
| D-CM-039 | 13/10/2026 | Uma prescrição cuja administração já começou sai da lista "a revisar", porque revisar já não faz sentido. Prescrição que chega ao procedimento sem assinatura é falta grave de processo da clínica: a expectativa é que o fluxo da enfermagem bloqueie o início do procedimento, de modo que a Central não trata esse caso como normal. (Resolve P-CM-030; a forma de aplicar está em E-CM-018.) | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários (CT-PRES) |
| D-CM-040 | 13/10/2026 | A assinatura do médico feita dentro da janela de revisão dispensa a revisão: a prescrição assinada nesse período não aparece em "a revisar". Exemplo do solicitante: assinada no dia anterior à aplicação, com janela de 1 dia. A regra não estava especificada; antes, só "Marcar como Revisada" encerrava a revisão, e a assinatura recente não bastava. A definição exata está em E-CM-019. (Comentário do solicitante em P-CM-030; resolve a divergência de P-CM-003, a confirmar.) | Definição (RN-CM-020); Especificação 2.4; Mapeamento 4.6 e 4.7; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-041 | 13/10/2026 | Texto do atraso da prescrição: abaixo de 1 hora só minutos ("40min atrasada"); de 1 hora a 47h59 horas e minutos ("1h59 atrasada"); a partir de 48 horas, dias ("30 dias atrasada"). Altera E-CM-016. (Resolve P-CM-031.) | Especificação 2.4 e i18n; Protótipo; Cenários (CT-PRES-11) |
| D-CM-042 | 13/10/2026 | Contrato: (1) o tipo de mensagem devolvido é um só, `Response`; (2) a origem da mensagem é `System` ou `User`; (3) o horário dos procedimentos (`startTime`) é hora no fuso da clínica ("HH:mm"), como na Agenda; (4) o status "Completo" é `completed` (D-CM-030). **[Item (4) substituído por D-CM-074: `administered`.]** (Resolve P-CM-033.) | Especificação 2.9; Mapeamento 4.3, 4.7 e 4.8 |
| D-CM-043 | 14/10/2026 | A Central segue o Design System de 14/10/2026: `--color-on-primary` (D-CM-027) foi incorporado ao Design System (seção 4a) e vale para todo texto ou ícone sobre `--color-primary-pure`; os novos `-dark` do tema claro (regra C8) e o `--color-neutral-pure` claro `#526A90` entram no bloco de tokens. Nenhum uso de token muda na Central. | Protótipo (bloco de tokens); Especificação 2.8 |
| D-CM-044 | 21/10/2026 | Idioma e tradução seguem as decisões transversais DT-011 e DT-012: (1) todo texto exibido segue o idioma da clínica atual (`ClienteEmpresa.IdiomaOficial`), inclusive as mensagens do sistema, que a Especificação dizia traduzir "para o idioma do usuário"; (2) termo de `TermoTraducao` sem tradução no idioma da clínica: vai a própria chave (`Termo`) e o back-end registra anomalia (`Termo`, `Origem`, `Idioma`), sem queda para pt-BR. Autorização do solicitante: "pode ajustar toda documentação" (21/10/2026). | Especificação (mensagens do sistema; 2.10, ECF.17.18); Mapeamento (blocos "Internacionalização"); Protótipo (`?lang`) |
| D-CM-045 | 21/10/2026 | (1) Conversa não lida: ícone e borda lateral esquerda em `color-secondary-dark` (como no protótipo), no lugar de `primary-pure`/`secondary-pure`, que ficavam abaixo de 3:1. (2) Percentual da barra de progresso de procedimento em `font-size-xs` (10px), como no protótipo, no lugar de 9px, que não existe no Design System. | Especificação 2.5, 2.6 e 2.8 |
| D-CM-046 | 26/10/2026 | Pedido do solicitante ao rever E-CM-003 e E-CM-004: (1) O anel de foco do teclado tem 2px em vez de 3px: o solicitante pediu uma altura menor ("2px talvez") e, vendo o resultado com 2px, disse que estava ótimo. Resolve E-CM-003. A cor `neutral-dark`, o afastamento de 2px, o campo de texto sem anel e o valer como padrão de todas as telas são proposta do Designer (E-CM-024). (2) Chips de urgência leves, alternativa A, escolhida pelo solicitante: Crítico em fundo `color-error-light` e Atenção em fundo `color-highlight-light`, sem contorno, texto e ícone na cor `-dark` da família (ícones `triangle-alert` e `clock`), peso `font-weight-medium`. Resolve E-CM-004 nos chips (o peso `font-weight-medium` era escolha do Designer, E-CM-025, revista em D-CM-056: peso regular). Motivo dado por ele: o chip é um alerta e não deve pesar no card; quem protagoniza são as informações do paciente e da prescrição. (3) O solicitante pediu que a borda azul de campo alterado, usada na tela de registros clínicos (cor medida em `#467EE5`, 2px), seja um token do Design System: `--color-field-changed` (seções 4a e 11). | Especificação 2.3, 2.4 e 2.8; Protótipo; Cenários (CT-ACES-06 e 07); Design System 4a e 11; guias do tema e de desenvolvimento |
| D-CM-047 | 26/10/2026 | Desempate das prescrições pelo nome do paciente: a lista é ordenada pelo tempo restante, do menor para o maior (as vencidas primeiro) e, com o mesmo tempo restante, pelo nome do paciente em ordem alfabética. Substitui E-CM-022, que desempatava pelo identificador da prescrição. Resposta do solicitante: "E-CM-022: desempate pelo nome do paciente". O critério para o mesmo nome é E-CM-027. | Definição (RN-CM-011); Especificação 2.4 e 2.9; Mapeamento 4.7; Protótipo; Cenários (CT-PRES-18) |
| D-CM-048 | 26/10/2026 | Confirmada a escolha E-CM-023: `--color-field-changed` (`#467EE5`) tem o mesmo valor nos dois temas. Resposta: "E-CM-023: ok". | Design System 4a e 11 (sem mudança) |
| D-CM-049 | 26/10/2026 | Na precedência entre os estados de um campo, "com erro" vem antes de "selecionado". Resposta: "E-cm-024: com erro precede selecionado". O restante de E-CM-024 segue a confirmar, inclusive a ordem dos estados abaixo de "erro". | Design System 11 (sem mudança de texto) |
| D-CM-050 | 26/10/2026 | **[O escopo "todas as clínicas do cliente" deste item foi substituído por D-CM-066: só as clínicas em que o médico atende.]** Resposta a P-CM-008. (1) Editar uma prescrição gera uma **nova versão**, que precisa ser assinada de novo; a versão anterior fica cancelada e a nova nasce sem assinaturas (D-CM-052). Para a Central, a nova versão é uma prescrição nunca assinada e volta para "a assinar". (2) A Central mostra as consultas e as prescrições de **todas as clínicas do cliente** em que o usuário está logado. Palavras do solicitante: "a central deve mostrar as consultas e prescrições de todas as clínicas do cliente em que o usuário está logado". Como mostrar a clínica no card, o efeito nos indicadores e no "Todos" são propostas do Designer (E-CM-028 e E-CM-029); o que ficou em aberto foi respondido em D-CM-060. | Definição (RN-CM-020; nova RN-CM-032); Especificação 2.2, 2.3, 2.4, 2.9; Mapeamento 4.1, 4.2 e 4.7; Protótipo; Cenários (CT-CONS-19, CT-PRES-19 e 20) |
| D-CM-051 | 26/10/2026 | **[A ordem das conversas foi trocada por D-CM-087; a conformidade da nova ordem está em P-CM-057.]** A ordem das mensagens confere com ECF.17.04 (ordem cronológica). Resposta: "P-CM-26(e): ordenação confere". Fecha o item (e) de P-CM-026. | Definição (SBIS); Especificação 2.10 |
| D-CM-052 | 26/10/2026 | Respostas aos itens 3, 6, 7 e 8 de P-CM-042. (3, segunda parte) Entre as versões de uma prescrição há uma só válida; as outras ficam canceladas. Por isso a versão antiga e a nova não aparecem juntas na mesma agenda (o filtro de situação já garante isso). (6) Uma nova versão de prescrição já nasce **sem assinaturas**: não herda a assinatura moderna nem os campos legados. (7) Palavras do solicitante: "sim, perde o efeito, entra no próximo ciclo de 7 dias". A assinatura que serviu de revisão perde o efeito se a aplicação for adiada para depois do limite; o que "próximo ciclo de 7 dias" significa na prática foi decidido em D-CM-059. (8) O banco deve mudar: o tipo de mensagem aceita só `Response`, como o contrato; a mudança entra no Log de Mudanças Estruturais do Banco de Dados. | Definição (RN-CM-020); Mapeamento 4.9 e Log de Mudanças; Cenários (CT-PRES-20 e 21) |
| D-CM-053 | 26/10/2026 | O chip "há 1h20" (consulta além do previsto) continua leve, como os chips de prescrição. Resposta a P-CM-044: "manter leve". | Especificação 2.3 |
| D-CM-054 | 26/10/2026 | O selo "Atrasado" e o número do indicador de Alertas ficam mais leves. Resposta a P-CM-045: "sim, ficam mais leves". A forma (cores e tokens) foi proposta pelo Designer e aprovada em D-CM-058. | Definição (fluxo de consulta); Especificação 2.2, 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-04) |
| D-CM-055 | 26/10/2026 | O tempo restante abaixo de 1 hora aparece em minutos ("45min restantes"), em vez de "0h restantes". Resposta a E-CM-020: "ok, aprovado". | Especificação 2.4 e i18n; Protótipo |
| D-CM-056 | 26/10/2026 | O texto dos chips "Crítico" e "Atenção" fica no peso regular (400); o `font-weight-medium` sai dos dois. Resposta a E-CM-025: "manter regular (400)". RN-CM-019 ("sem texto em negrito") não muda. | Especificação 2.4 e 2.8; Protótipo |
| D-CM-057 | 26/10/2026 | A borda do campo em repouso fica em `--color-neutral-light`, como diz o Design System (seção 11), com contraste de 1,7:1 no tema claro e 1,8:1 no escuro, abaixo dos 3:1 que a WCAG 1.4.11 pede para o limite de um campo; o solicitante aceitou esse contraste. Resposta a P-CM-043: "manter neutral-light" (escrito como "E-CM-043", leitura do Designer: P-CM-043). O protótipo passa a usar `neutral-light` no campo de busca e no de resposta do modal de mensagens (antes `neutral-pure`). | Especificação 2.8 (Input e Acessibilidade); Protótipo |
| D-CM-058 | 26/10/2026 | A proposta do Designer para o selo "Atrasado" e o número do indicador de Alertas está aprovada: selo com fundo `color-error-light`, texto e ponto `color-error-dark`, sem contorno, só o ponto pulsa; número do indicador em `color-error-dark`. Resposta: "E-CM-045: proposta aprovada" (leitura do Designer: não existe E-CM-045; a proposta é a de E-CM-026, que respondia a P-CM-045). A Agenda do Médico segue com o selo preenchido (`--color-alert-fill`); a Central só usa esse token no toast de erro do protótipo. | Especificação 2.2, 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-04) |
| D-CM-059 | 26/10/2026 | Assinatura que serviu de revisão e aplicação adiada (D-CM-052, item 7), leitura A: a prescrição já assinada **não precisa ser assinada de novo**. A assinatura que dispensou a revisão perde esse efeito se a aplicação for adiada para depois do limite, e a prescrição volta só a "a revisar", quando a nova data entrar na janela de revisão (hoje, 1 dia). Resposta a P-CM-047: "a que aplicou, prescrição assinada não precisa ser assinada novamente". | Definição (RN-CM-020); Especificação 2.4 (critérios); Cenários (CT-PRES-21) |
| D-CM-060 | 26/10/2026 | **[O escopo "todas as clínicas do cliente" deste item foi substituído por D-CM-066; as janelas por clínica seguem valendo.]** Escopo do cliente e regras por clínica (resposta a P-CM-046). Palavras do solicitante: "as janelas obedecem às regras de suas respectivas clínicas". Hierarquia explicada por ele: o login é autorizado para um cliente (`Cliente`); dentro do cliente há várias clínicas (`ClienteEmpresa`), com dados no banco do cliente (`ClienteBD`); por isso o médico tem acesso a **todas as agendas, prescrições e mensagens** do cliente durante o login naquele cliente. Ao mudar de clínica, o médico pode mudar de cliente, e passa a ver todas as clínicas do novo cliente. Isto é uma **exceção do sistema para médicos**; os demais profissionais ficam restritos à clínica escolhida na tela de seleção de clínicas. Efeitos na Central (aplicação feita pelo Designer a partir desta decisão; (a) e (c) estão também em E-CM-029 e E-CM-028): (a) "todas as clínicas do cliente" vale para consultas, prescrições, procedimentos e mensagens, e para os indicadores correspondentes; (b) as janelas de prescrição (`PrescricaoTempoAssinatura`, `NumeroDiasRevisaoPrescricoes`) são as da clínica de cada prescrição; (c) a regra de exibir o nome da clínica passa a ser "cliente com mais de uma clínica" (ver E-CM-028). O que ficou em aberto nesta decisão foi resolvido depois: o fuso das janelas em D-CM-062, o rótulo do indicador e "Em Tratamento" em D-CM-063, a clínica nas mensagens em D-CM-064 e a ligação das clínicas em D-CM-065. | Definição (RN-CM-032, RN-CM-020, dependências); Especificação 2.2 a 2.6 e 2.9; Mapeamento 4.1 a 4.8; Protótipo (Demo); Cenários (CT-CONS-19, CT-PRES-19 e 22, CT-PROC-14, CT-MSG-22) |
| D-CM-061 | 26/10/2026 | Confirmação de E-CM-030. Palavras do solicitante: "E-CM-030: ok, confirmado". O card de procedimento mostra o nome curto da clínica, no mesmo formato, com o mesmo ícone e a mesma condição dos cards de consulta e de prescrição (só quando o cliente tem mais de uma clínica; **desde D-CM-066, só quando o médico atende em mais de uma**); o contrato de `procedures` ganha o campo `clinic`. | Definição (RN-CM-032); Especificação 2.6 e 2.9; Mapeamento 4.3; Protótipo; Cenários (CT-PROC-14) |
| D-CM-062 | 26/10/2026 | Resposta a E-CM-031. Palavras do solicitante: "ok, para a tabela, mas acho que é melhor que o hoje seja calculado no fuso da clínica que o usuário está logado. Senão ele pode pensar que está adiantado e na verdade já está na hora." Decisão: (1) a aplicação monta a tabela de limites por clínica, com os parâmetros de cada uma (como em E-CM-032); (2) o "hoje", o fim do dia de cada janela (assinar e revisar) e os horários exibidos seguem o fuso da **clínica em que o usuário está logado**, também para as prescrições de clínicas de outro fuso. Efeito: um só "hoje" em toda a tela (consultas, procedimentos, prescrições e indicadores). O fuso da clínica da prescrição deixa de ser usado. | Definição (RN-CM-032, RN-CM-020); Especificação 2.2, 2.4 e 2.9; Mapeamento 4.6 e 4.7; Protótipo (comentários); Cenários (CT-PRES-22, CT-PRES-23) |
| D-CM-063 | 26/10/2026 | Resposta a P-CM-048, itens (a) e (b). Palavras do solicitante: "a. ok, está correto / b. ok, está correto". Eram propostas do Designer e valem: (a) o rótulo "p/assinar (próx. N dias)" do indicador de alertas e o campo `toSignWindowDays` usam o N da clínica em que o médico está logado; (b) o indicador "Em Tratamento" usa os parâmetros `TempoPacienteAtivoAgenda` e `TempoPacienteAtivoPrescricao` da clínica em que o médico está logado. | Especificação 2.2 e 2.9; Mapeamento 4.5 e 4.6; Protótipo; Cenários (CT-PRES-22) |
| D-CM-064 | 26/10/2026 | Resposta a P-CM-048, item (c). Palavras do solicitante: "mostrar a clínica nos cards de mensagem". O card de conversa mostra o nome curto da clínica de origem, com o mesmo formato e a mesma regra dos demais cards (só quando o cliente tem mais de uma clínica; **desde D-CM-066, só quando o médico atende em mais de uma**); o contrato de `conversations` ganha o campo `clinic`. De onde vem o nome: E-CM-033. | Definição (RN-CM-032); Especificação 2.5 e 2.9; Mapeamento 4.8; Protótipo; Cenários (CT-MSG-22) |
| D-CM-065 | 26/10/2026 | Resposta a P-CM-048, item (e): como ligar as clínicas. Palavras do solicitante: "dentro do banco do cliente há uma tabela SegEmpresa, que contém o campo IpSegurancaEmpresaId que é o guid correspondente em ClienteEmpresa. Essa tabela tem um par chamado Clinica, que contém o campo IdChClinica, que identifica a que clínica os registros pertencem. Os limites estão no banco do cliente em IpParametro e IpParametroChave (onde está o id da clínica (IdChave, nesse caso aponta para o IdChClinica))"; e "os defaults para revisar = 1 e para assinar = 7". A cadeia fica: `ClienteEmpresa.Id` (IpSeguranca) = `SegEmpresa.SegurancaClienteEmpresaId` → `SegEmpresa.IdEmpresa` → `Clinica.IdEmpresa` (chave estrangeira real) → `Clinica.IdChClinica` = `Agenda.IdChClinica` = `IpParametroChave.IdChave`. Os padrões 1 e 7 já estavam em D-CM-006 e D-CM-037 e foram conferidos. O nome do campo: o solicitante escreveu `IpSegurancaEmpresaId`; na Biblioteca de Schema (DDL) (`GescomClienteAlfa` e `GescomZeradoPadronizacao`) o campo é `SegurancaClienteEmpresaId` (`uniqueidentifier NULL`), e é o nome usado nos documentos (confirmar em P-CM-050). | Mapeamento (ligação das clínicas, 4.5, 4.6 e 4.8); Cenários |
| D-CM-066 | 26/10/2026 | Resposta ao item (d) de P-CM-048, depois explicado em P-CM-049. Palavras do solicitante: "O correto nos 2 casos é mostrar as clínicas que o usuário atende (não faz sentido mostrar pacientes de uma clínica que ele não atende, pois ele não pode fazer nada por ela - atender, revisar e assinar prescrições, mandar mensagens... porque ele não é o médico dessa clínica". (1) Na Central do Médico e na Agenda do Médico, o médico vê só as clínicas em que atende: consultas, prescrições, procedimentos e mensagens de outra clínica do cliente não aparecem nem entram nos indicadores, nem com o toggle "Todos". (2) Isto substitui, nesse ponto, D-CM-050 e D-CM-060 ("todas as clínicas do cliente"). Continuam valendo de D-CM-060 as janelas de prescrição por clínica; a regra de que os demais profissionais ficam na clínica escolhida não foi alterada. (3) O nome da clínica nos cards aparece quando o médico atende em mais de uma clínica, a mesma regra da Agenda (RN-AGM-017, a). (4) DT-013 revista (Decisões Transversais v1.7). (5) A Agenda do Médico foi alinhada depois, por D-CM-068. Como o sistema sabe em que clínicas o médico atende: D-CM-067. | Definição (RN-CM-032, dependências, Fluxo); Especificação 2.2 a 2.6 e 2.9; Mapeamento (Seção 4, bloco novo, 4.1 a 4.8); Protótipo (texto do Demo); Cenários (CT-CONS-19 e 20, CT-PRES-19, 22 e 23, CT-PROC-14, CT-MSG-22) |
| D-CM-067 | 26/10/2026 | Confirmação de E-CM-034. Palavras do solicitante: "E-CM-034: vamos usar as clinica que o usuário tem acesso. Recurso.IdChClinica e RecursoHorario tem relação com a marcação de agendas (tarefa da recepção), eles tem relação porque só quem é um recurso na clínica pode ter horário marcado, mas acho que não influencia nesse momento." "Atender", para o sistema, é a clínica do cliente a que o usuário tem acesso (`ClientePerfilAcessoUsuario`, RN-CIU-009), traduzida para `IdChClinica` pela cadeia de D-CM-065 (tabela `{ClinicasDoMedico}`). `Recurso.IdChClinica` e `RecursoHorario` ficam fora desta regra. | Definição (RN-CM-032, dependências); Mapeamento (Seção 4, bloco "Clínicas em que o médico atende"); Cenários (massa) |
| D-CM-068 | 26/10/2026 | Resposta a P-CM-051. Palavras do solicitante: "sim, precisa filtrar pelas clínicas que o usuário tem acesso. Se ele perdeu acesso a uma clínica, não pode mais ver suas agendas e nem mesmo os pacientes dela." (1) A Agenda do Médico passa a filtrar explicitamente pelas clínicas a que o usuário tem acesso (Agenda: Definição v1.17, Especificação v1.20, Mapeamento v1.10 e Cenários de Teste v1.7; o Protótipo não muda). (2) Na Central isso já vale, pelo filtro de D-CM-066, para consultas, prescrições, procedimentos e mensagens. (3) "Nem mesmo os pacientes dela": esta parte foi corrigida pelo solicitante em D-CM-070; o médico não perde o acesso ao paciente. | Agenda do Médico (RN-AGM-002, CA-008.9, Mapeamento 4.1 a 4.3, CT-AGM-CTX-11); Definição da Central (RN-CM-032); Mapeamento da Central (Seção 4) |
| D-CM-069 | 26/10/2026 | Respostas aos itens (b) e (c) de P-CM-050. **(b)** `Conversa.IdEmpresa` guarda o `SegEmpresa.IdEmpresa`: "correto, é o valor de SegEmpresa.IdEmpresa... mas pensando aqui, acho que o ideal é que fosse o IdChClinica, não idEmpresa... mas deixe isso pendente para decidir depois." A troca por `IdChClinica` ficou em P-CM-052. **(c)** Fuso: "Já haviamos definido que ClinicaFusoHorario está descontinuado. Verifique na documentação." Verifiquei: o fuso vem de `ClienteEmpresa.FusoHorarioOficial` (Log de Mudanças Estruturais, 07 e 08/10/2026; o solicitante esclareceu então que o campo fica em `ClienteEmpresa`), e nenhuma consulta da Central lê `Clinica.FusoHorario`. **Não encontrei registro escrito** de que `Clinica.FusoHorario` foi descontinuado, e a Biblioteca de Schema (DDL) ainda traz a coluna; registrei como dito pelo solicitante (depois achei um registro parcial, citado em D-CM-072). Nada mudou nas consultas. O item (a) foi respondido em D-CM-071. | Mapeamento (Seção 4, 4.8) |
| D-CM-070 | 26/10/2026 | Resposta a P-CM-053. Palavras do solicitante: "pois é... ele não perde acesso ao paciente, somente às suas agendas e prescrições que provavelmente serão redirecionadas ou canceladas. Para o médico, Paciente.IdChClinica não faz diferença, mas para o administrativo e outras funções será um filtro." (1) Corrige D-CM-068: quem perde o acesso a uma clínica perde as agendas e as prescrições dela, não os pacientes. (2) O que é medido por paciente ("Em Tratamento", adesão ao protocolo, busca de pacientes) não passa por filtro de clínica para o médico; nada muda no SQL. (3) `Paciente.IdChClinica` não é usado pela Central; o solicitante informou que será filtro para o administrativo e outras funções, ainda sem especificação (fora do escopo da Central). (4) "Provavelmente serão redirecionadas ou canceladas" é a expectativa do solicitante, não uma regra definida: o que acontece com as agendas e prescrições da clínica sem acesso não está especificado. | Definição (RN-CM-032); Mapeamento (Seção 4); Agenda do Médico (RN-AGM-002) |
| D-CM-071 | 26/10/2026 | Resposta ao item (a) de P-CM-050. Palavras do solicitante: "utilize o termo do DDL". O campo de `SegEmpresa` que guarda o guid de `ClienteEmpresa` é `SegurancaClienteEmpresaId`. `IpSegurancaClienteEmpresaId` não é adotado; por isso não há mudança de nome no banco e nada a registrar no Log por este motivo. | Mapeamento (Seção 4, ligação entre a clínica do login e a base do cliente); guia DOC-009 |
| D-CM-072 | 26/10/2026 | Pedido do solicitante: "registre no log que Clinica.FusoHorario foi descontinuado". Feito: entrada de 26/10/2026 no Log de Mudanças Estruturais do Banco de Dados (total passa a 24). A coluna continua na Biblioteca de Schema (DDL), e não foi informado se será removida. Em D-CM-069 (c) eu escrevi que não achei registro escrito; depois achei um parcial, no Mapeamento da Agenda do Médico v1.1 (07/10/2026), e ele está citado no Log. | Log de Mudanças Estruturais; Mapeamento (Seção 4) |
| D-CM-073 | 27/10/2026 | Cores e nome do status vêm da API, no próprio status (DT-016): `status` vira objeto `{ domain, name, colors }` em `appointments` e `procedures`. As cores ficam nas tabelas `IpTerminologia.DomEstadoAgendaConsulta` e `DomEstadoAgendaProcedimento` (chave `CodEstado`; consulta: `A`, `D`, `G`, `J`, `M`, `X`; procedimento: `SCH`, `WTI`, `CKD`, `PRP`, `ADM`, `ASD`, `FNS`, `CNL`), e o nome em `TermoTraducao`, nos 3 idiomas. Mesmas cores para todas as clínicas. Palavras do solicitante: "criamos duas tabelas em IpTerminologia: DomEstadoAgendaConsulta e DomEstadoAgendaProcedimento, que guardam as 4 cores além do Id do estado e sua descrição. O termo tem seu valor nos 3 idiomas em TermoTraducao"; "o termo é identificado pelo campo CodEstado"; "sim, mesma cor para todas as clínicas (nota: estamos discutindo do cliente escolher suas cores, mas seria uma alternativa opcional, ainda em discussão - isso pode modificar essa definição)". Origem: proposta "Cores de status por tema" da equipe de front, aprovada pelo solicitante | Especificação 2.3, 2.6, 2.8, 2.9; Mapeamento 4.1, 4.3; Protótipo |
| D-CM-074 | 27/10/2026 | O valor de contrato do status "Completo" do procedimento é `administered` (`CodEstado` `ASD`), no lugar de `completed` (D-CM-030, D-CM-042). Palavras do solicitante: "o termo correto é administered" | Especificação 2.6, 2.9; Mapeamento 4.3, 4.4; Protótipo; Cenários CT-PROC-11 |
| D-CM-075 | 27/10/2026 | Avatar de iniciais: texto `color-neutral-darker` sobre a cor de fundo do status, nos dois temas. Palavras do solicitante: "sobre o avatar, acho melhor que seja neutral-darker sobre a cor do status, pois ele deve representar mais o paciente do que o estado da agenda. Mas gosto da idéia do status da agenda estar representada sutilmente no avatar." | Especificação 2.3, 2.8; Protótipo |
| D-CM-076 | 27/10/2026 | Card cancelado: chip "Cancelado" em cinza preenchido, como na proposta do front, e os textos do card riscados, exceto o chip de estado; só os textos. Palavras do solicitante: "vamos manter o cancelado como proposto pelo front, mas acrescentamos que o card cancelado fica com os textos riscados (hora, nome, etc), exceto o chip de estado"; "só os textos". Na Central, vale para o card de procedimento cancelado (o painel de Consultas não mostra canceladas) | Especificação 2.6; Protótipo; Cenários CT-PROC-15 |
| D-CM-077 | 27/10/2026 | Confirmação de E-CM-046. Palavras do solicitante: "E-CM-046: confirmado". No card de procedimento cancelado, o status não é riscado e o avatar continua neutro (`color-neutral-light` / `color-neutral-dark`), sem a cor do status. Com D-CM-079, o status sem risco é o chip | Especificação 2.6, 2.8; Protótipo |
| D-CM-078 | 27/10/2026 | Confirmação de E-CM-047. Palavras do solicitante: "E-CM-047: confirmado". Ficam os caminhos de endpoint da Especificação 2.9 | Especificação 2.9 |
| D-CM-079 | 27/10/2026 | Resposta a P-CM-054. Palavras do solicitante: "status do procedimento devem virar chip colorido". O status do card de procedimento vira chip `.chip-status` com `status.colors` e `status.name`, como no painel de Consultas | Especificação 2.6, 2.8, 2.9; Protótipo; Cenários CT-PROC-11, 15, 16 |
| D-CM-080 | 27/10/2026 | Resposta a P-CM-056. Palavras do solicitante: "trocar front e back no mesmo deploy". A troca de `status` de texto para objeto é feita no mesmo deploy, sem período com os dois formatos; vale também para a Agenda do Médico | Especificação 2.9; Agenda do Médico, Especificação |
| D-CM-081 | 27/10/2026 | Resposta a P-CM-055. Palavras do solicitante: "indicadores serão descontinuados depois da implementação nova". O indicador `EstadoAgendaConsulta` de `IpTerminologia.Indicadores` sai de uso depois que `DomEstadoAgendaConsulta` e `DomEstadoAgendaProcedimento` estiverem em uso | Mapeamento, "Tabelas novas"; Log de Mudanças Estruturais do Banco de Dados |
| D-CM-082 | 27/10/2026 | Nomes dos status em pt-BR. Palavras do solicitante: "os termos corretos registrados em TermoTraducao são: Em atendimento, Em preparo, Em aplicação (ao invés de Em administração)". Os documentos passam a usar esses nomes (antes "Em Atendimento", "Preparo" e "Em administração") | Todos os documentos da Central; Agenda do Médico; Design System, seção 4 |
| D-CM-083 | 27/10/2026 | Pedido do solicitante: "na próxima alteração dos documentos, pode corrigir as menções antigas" (proveniência de decisão no corpo dos documentos, apontada pela revisão técnica da v5.15). Feito na v5.16: as menções saem do corpo da Definição, da Especificação, do Protótipo, do Mapeamento e dos Cenários, e do Mapeamento v1.12 da Agenda do Médico; a proveniência fica no Histórico de Versões e neste Registro | Todos os documentos da Central; Agenda do Médico, Mapeamento |
| D-CM-084 | 28/10/2026 | Nome do status `waiting` em pt-BR. Palavras do solicitante: "Aguardando recepção" (resposta sobre a divergência entre a Agenda, "Aguardando Recepção", e a Central, "Aguardando recepção"). É o texto cadastrado em `TermoTraducao`; Central e Agenda do Médico passam a usá-lo | Todos os documentos da Central; Agenda do Médico |
| D-CM-085 | 28/10/2026 | Botões da Central alinhados à seção 12 do Design System. Palavras do solicitante: "alinhe o botão na próxima versão" e, entre três opções, "Seção 12 inteira". Botões dentro de card são secundários, com contorno (Assinar, Revisar, PEP, Resolvido); o preenchido em verde escuro (`--color-primary-strong`, texto `--color-on-primary-strong`) fica para a ação principal de modal e caixa de diálogo; Cancelar com contorno. O Assinar deixa de usar `--color-on-primary` | Especificação 2.8; Protótipo; Cenários CT-ACES-07 |
| D-CM-086 | 28/10/2026 | Confirmação de E-CM-049. Palavras do solicitante: "E-CM-049: aceito as duas iniciativas". No modal de mensagem, o primário é "Responder" e "Resolvido" é secundário; "Descartado" e "Descartar" seguem no estilo destrutivo até o Design System definir o botão destrutivo | Especificação 2.8; Protótipo |
| D-CM-087 | 28/10/2026 | O painel de Mensagens adota as mudanças decididas na Mensageria (Registro de Decisões da Mensageria, D-MSG-021 e D-MSG-023). Palavras do solicitante: "Ponto em aberto: pode incluir na central." (1) assunto na linha 1 do card, com o horário à direita, e "autor: texto" na linha 2; (2) sem o selo "Respondida"; (3) aviso de leitura `check`/`check-check` quando a última mensagem é do médico, com o campo `readByOthers`; (4) ordem: não lidas primeiro; dentro de cada grupo, a data mais recente entre a última mensagem e o prazo; empate pela conversa criada mais recentemente (RN-MSG-002); (5) valor `responded` no lugar de `replied`; (6) o horário continua relativo no painel (a Mensageria mostra data e hora) | Definição RN-CM-015; Especificação 2.5, 2.8, 2.9, 2.10; Mapeamento 4.8, 4.9; Protótipo; Cenários CT-MSG-05, 08, 15, 23 a 26 |
| D-CM-088 | 29/10/2026 | O painel de Mensagens adota o grau de urgência, a ordem pelo grau e o horário relativo da Mensageria. Palavras do solicitante: "a central está aberta, pode alterar a documentação." (1) chip com o nome do grau (Rotina, Urgente, Quanto antes, Imediato), inclusive Rotina (D-MSG-043); (2) chaves do HL7 em minúsculas: `routine`, `urgent`, `asap`, `stat` (D-MSG-046); (3) ordem dentro de cada camada de leitura: grau (Imediato, Quanto antes, Urgente, Rotina, sem grau) e depois a data (RN-MSG-002, D-MSG-026); (4) horário relativo: "Há x min", "Há x h" ou data e hora (D-MSG-028, D-MSG-032); (5) o grau é imutável e a prioridade do legado não é convertida (D-MSG-042) | Definição RN-CM-015; Especificação 2.5, 2.9, i18n; Mapeamento 4.8; Protótipo; Cenários CT-MSG-27 e 29 |
| D-CM-089 | 29/10/2026 | O botão "Resolvido" sai do card do painel de Mensagens. Palavras do solicitante (Mensageria): "vamos remover o botão" (D-MSG-047), depois de consultar um crítico de UX e um médico crítico, que recomendaram a retirada (risco de resolver sem ler, sobretudo alerta do sistema; mensagem errada do fluxo). "Resolvido" e "Descartado" ficam só no modal. Substitui o botão do card de D-CM-085 (o modal não muda) | Definição RN-CM-015; Especificação 2.5, 2.8, 2.10; Protótipo; Cenários CT-MSG-19, 26, 28 e CT-ACES-11 |
| D-CM-090 | 29/10/2026 | Nomes técnicos, para não confundir o grau de urgência da conversa com o indicador de tempo. Palavras do solicitante: "podemos lidar com nomes mais específicos, como urgenceLevel (para o grau de urgência)" (grafia corrigida pelo Designer para `urgencyLevel`, a confirmar) e "Use timeIndicator para usar nos 2 paineis (pois é a mesma função)". `urgencyLevel` é o grau da conversa; `timeIndicator` é o chip "Crítico"/"Atenção" dos painéis de Consultas e de Prescrições. Substitui `urgency` em D-CM-088 e E-CM-051. Fora do escopo: o campo `urgent` do endpoint de alertas de prescrição (a contagem do KPI) não muda. Valores `critical`, `attention`, `normal` do `timeIndicator`: proposta do Designer | Especificação 2.5, 2.9, terminologia; Mapeamento 4.8; Protótipo |

## 2. Escolhas do Designer, a confirmar

Escolhas feitas sem pedido explícito do solicitante. Valem até serem confirmadas ou trocadas.

| ID | Escolha | Onde está |
| --- | --- | --- |
| E-CM-004 | Toggles ativos com texto `neutral-darker` (os chips de urgência saíram por D-CM-046; os botões, por D-CM-085). | Especificação 2.8; Protótipo |
| E-CM-018 | "Administração iniciada" (D-CM-039) = `Agenda.DhInfusaoIniUTC` preenchido na agenda da prescrição. A regra retira só as prescrições "a revisar"; a "a assinar" com administração iniciada continua na lista (vencida, em vermelho), porque esconder esse caso esconderia a falha de processo que o solicitante descreveu. | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários (CT-PRES-11, CT-PRES-14) |
| E-CM-019 | Definição de "assinatura dentro da janela de revisão" (D-CM-040): vale quando existe assinatura do médico (`PrescricaoAssinatura` com `TipoAssinatura = 'A'`, ou `Prescricao.DataAssinaturaPrescricao`) cuja data é igual ou posterior à meia-noite, no fuso da clínica em que o usuário está logado (D-CM-062), do dia da aplicação menos N dias — isto é, feita depois de a janela de revisão daquela prescrição ter aberto. Exemplo com N = 1 e aplicação em 23/09: a janela abre em 22/09 00:00; assinatura em 22/09 11:14 dispensa a revisão, assinatura em 21/09 18:00 não. As duas colunas de data são `datetime` sem fuso e são tratadas como hora local da clínica **[a confirmar com o time de banco]**. Qualquer assinatura que atenda vale (uma nova versão reassinada vale pela nova data). | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários |
| E-CM-021 | Textos novos: confirmação de resolver ("Resolver conversa?" / "A conversa será marcada como resolvida para todos os destinatários." / "Cancelar" · "Resolver"), confirmação de descartar ("Descartar conversa?" / "A conversa será descartada para todos os destinatários." / "Cancelar" · "Descartar"), "sem tempo previsto" e "{d} dias atrasada", com tradução em en-US e es-419 (Especificação 2.5 e 2.6). | Especificação 2.5, 2.6, 2.4 (i18n); Protótipo |
| E-CM-024 | Itens da seção 11 do Design System que são do Designer: valer como padrão de todas as telas (o solicitante descreveu o critério para a tela de registros clínicos); espessura de 2px nos estados "selecionado" e "com erro"; precedência entre os estados abaixo de "erro" (selecionado > alterado > repouso — "erro antes de selecionado" foi decidido em D-CM-049); `:focus-visible`; afastamento de 2px do anel; campo de texto sem anel (a borda "selecionado" faz o papel); a regra de item que permanece selecionado (borda do item mais anel de foco afastado). O solicitante definiu as cores da borda por estado e pediu o anel de 2px. | Design System 11 |
| E-CM-027 | Para prescrições com o mesmo tempo restante e o mesmo nome de paciente (nome social, se houver; senão o nome civil), o último critério é o identificador da prescrição, do menor para o maior. A comparação de nomes ignora maiúsculas e acentos (ordem alfabética do pt-BR). Sem isso a ordem de dois itens iguais poderia mudar a cada atualização automática. | Definição (RN-CM-011); Especificação 2.4 e 2.9; Mapeamento 4.7; Cenários (CT-PRES-18) |
| E-CM-028 | Como mostrar a clínica (D-CM-050): nos cards de consulta e de prescrição (e, por D-CM-061, de procedimento e, por D-CM-064, de mensagem), o nome curto da clínica como informação secundária (ícone Lucide `building-2` de 14px e texto de 12px em `color-neutral-pure`, sem chip), **só quando o médico atende em mais de uma clínica** — o mesmo ícone e a mesma regra da Agenda do Médico (RN-AGM-017, a), por D-CM-066 (entre D-CM-060 e D-CM-066 a regra foi "o cliente tem mais de uma clínica"). O campo `clinic` vem do back-end, `null` com uma só clínica. O fuso de "hoje" e dos horários é o da clínica em que o médico está logado, como na Agenda (RN-AGM-018, decidida pelo solicitante naquela funcionalidade). | Definição (RN-CM-032); Especificação 2.3, 2.4, 2.6, 2.9; Mapeamento 4.1, 4.3 e 4.7; Cenários (CT-CONS-19, CT-PRES-19, CT-PROC-14) |
| E-CM-029 | Os indicadores "Consultas Hoje", "Procedimentos Hoje" (por D-CM-060) e "Alertas de Prescrição" contam o mesmo conjunto dos painéis, isto é, as clínicas em que o médico atende (D-CM-066; senão o número não bateria com a lista). O toggle "Todos" das prescrições amplia para todos os médicos, mas só nessas clínicas. | Definição (RN-CM-032); Especificação 2.2 e 2.4; Mapeamento 4.2, 4.4 e 4.7 |
| E-CM-032 | Como montar a tabela de limites por clínica, depois de D-CM-062 e D-CM-065: a aplicação lê todas as linhas de `Clinica` do banco do cliente (toda `Agenda.IdChClinica` aponta para `Clinica`, então nenhuma prescrição fica sem linha) e, para cada uma, os valores de `NumeroDiasRevisaoPrescricoes` (N, padrão 1) e `PrescricaoTempoAssinatura` (S, padrão 7) em `IpParametroChave` (`IdChave` = `IdChClinica`); com isso monta a tabela `{LimitesPorClinica}` (`IdChClinica`, N, S, `LimiteRevisaoUTC`, `LimiteAssinaturaUTC`). Os limites em UTC são a meia-noite do dia (hoje + N + 1) e (hoje + S + 1) **no fuso da clínica logada** (D-CM-062), convertida para UTC pela aplicação (por causa do horário de verão). O fuso da clínica logada vem de `ClienteEmpresa.FusoHorarioOficial` (a clínica da sessão). A hora das assinaturas (`PrescricaoAssinatura.Data`, `datetime` sem fuso) é lida como hora local da clínica logada, para a exceção (a) de E-CM-019: é uma simplificação do Designer, que só difere do correto se as clínicas do cliente tiverem fusos diferentes. | Mapeamento 4.6 e 4.7; Definição (RN-CM-020, RN-CM-032); Cenários (CT-PRES-22, CT-PRES-23) |
| E-CM-033 | Nome da clínica no card de mensagem (D-CM-064) e contagem das clínicas do cliente. (1) O nome sai do mesmo lugar dos outros cards (`Chave.Descricao`), pelo caminho `Conversa.IdEmpresa` = `SegEmpresa.IdEmpresa` → `Clinica.IdEmpresa` → `Clinica.IdChClinica` → `Chave.IdChave`. Isso supõe que `Conversa.IdEmpresa` guarde o `SegEmpresa.IdEmpresa` (a mensageria declara `int`, `SegEmpresa` declara `smallint`, e não há chave estrangeira entre as duas bases de tabelas): confirmado em D-CM-069. (2) A condição de exibir o nome deixou de ser "o cliente tem mais de uma clínica": com D-CM-066 é "o médico atende em mais de uma clínica" (D-CM-067). | Mapeamento 4.1 e 4.8; Especificação 2.5 e 2.9 |
| E-CM-048 | Posição do chip de status no card de procedimento (D-CM-079): na linha 2, entre o local e as tags; o horário entre parênteses fica logo depois do chip, fora dele | Especificação 2.6; Protótipo |
| E-CM-050 | Detalhes do card de conversa não definidos na Mensageria (D-CM-087): (1) campo `authorIsMe` no contrato da Central, para o front mostrar "Você" (a Mensageria usa `lastAuthor` com o id do autor); (2) o aviso de leitura só no card, não nas mensagens dentro do modal (na Mensageria, ainda **[PROPOSTA]**); (3) a cor `--color-secondary-dark` do `check-check` acompanha a proposta da Mensageria, que ainda não foi aprovada lá; (4) o assunto do modal (nome acessível) passa a ser `subject`, e não o texto da primeira mensagem; (5) a conversa nova do mock (Claire, Enfermagem); (6) o card da Central não ganha o ícone de carta (Lucide `mail`) da Mensageria para não lida: continua com a borda e o ícone de origem coloridos (D-CM-045) | Especificação 2.5, 2.9; Mapeamento 4.8; Protótipo; guia de desenvolvimento da v5, seção 4.13 |
| E-CM-051 | Detalhes do card de conversa com o grau e o horário (D-CM-088): (1) o chip fica na linha do prazo, antes do prazo, e o grau também aparece no modal, ao lado do horário e do autor; (2) nome acessível do card com "Grau de urgência: {nome}"; (3) campo `urgencyLevel` e `serverNow` na resposta de `conversations[]` (a Mensageria já usa `serverNow`); (4) x do horário relativo por truncamento, mínimo de 1 min, recalculado a cada atualização de 1 minuto (E-MSG-019); (5) textos `msg-ha-min`, `msg-ha-h` e `msg-grau-titulo` nos três idiomas | O solicitante pediu a alteração, sem estes detalhes; (1) e (2) seguem a Mensageria (E-MSG-017, E-MSG-022), (3) a (5) a E-MSG-019 | Especificação 2.5, 2.9, i18n; Mapeamento 4.8; Protótipo |

## 3. Questões em aberto

| ID | Questão | Situação |
| --- | --- | --- |
| P-CM-003 | Quando o médico assina uma prescrição cuja aplicação já está na janela de revisão, o que ele deve ver depois? **Divergência:** a regra RN-CM-020 dizia que a prescrição passava na hora para "a revisar" e continuava na lista (assinar e revisar eram duas ações separadas), enquanto o critério de aceitação do indicador de alertas dizia que o número diminui em um. **Com D-CM-040** (assinatura dentro da janela dispensa a revisão) as duas passam a concordar: a prescrição sai da lista e o número diminui. Pergunta: confirma que isto resolve? **Atenção (P-CM-035):** no sistema atual o parâmetro `RevisorIgualMedicoQueAssinou` (padrão "N") impede que o revisor seja o mesmo médico que assinou, o que vai em sentido contrário. | Aguarda o solicitante. |
| P-CM-007 | A Central e a Agenda do Médico descrevem o mesmo dado de jeitos diferentes. O **modo de atendimento** (`attendanceMode`): a Agenda envia um objeto com código e texto (`{code, label}`); a Central envia só um texto — e a própria Especificação da Central mostra o código no exemplo ("in_person") enquanto o Mapeamento diz que é o texto traduzido. (O outro ponto, o formato do horário dos procedimentos, foi resolvido em D-CM-042.) Pergunta: a Central deve enviar `attendanceMode` como objeto `{code, label}`, igual à Agenda? **Ideia do Designer (invenção):** sim, para o mesmo componente de tela servir às duas. | Aguarda o solicitante. |
| P-CM-026 | Conformidade SBIS (`RequisitosSBISv5.2 ambulatorial.xlsx`), item que segue em aberto: **(a)** NGS1.07.03 pede trilha de auditoria ao inativar um registro do prontuário; resolver ou descartar uma conversa não tem auditoria (D-CM-014). O solicitante gostaria de tratar a mensageria como ferramenta auxiliar, um canal não oficial de comunicação que ficaria fora do SBIS; falta confirmar se isso é possível, já que pode haver conteúdo clínico nas conversas. Observação do Designer: os alertas automáticos do sistema (prescrição urgente, infusão atrasada) têm conteúdo clínico e podem ser descartados para todos os destinatários sem trilha de auditoria; conversas livres e alertas do sistema podem precisar de tratamento diferente. (Os itens b, c e d foram decididos em D-CM-036 e o item e, em D-CM-051.) | Aguarda o solicitante (item a: confirmar se é possível). |
| P-CM-035 | **Lembrete pedido pelo solicitante:** o sistema atual tem parâmetros que controlam quem pode assinar e quem pode revisar prescrições; isso não foi especificado na Central. O solicitante lembra de um parâmetro que permite ou não que outros médicos assinem as prescrições do prescritor — **não o localizei** no catálogo `ParametrosGemedLegado.csv`. Parâmetros próximos que existem no catálogo: `MedicoPodeRevisar`, `EnfermeiroPodeRevisar`, `FarmaceuticoPodeRevisar` (quem pode ser o revisor; padrão "N" para os três) e `RevisorIgualMedicoQueAssinou` (o revisor pode ser o mesmo médico que assinou; padrão "N"). Para especificar numa versão futura: dizer qual é o parâmetro de assinatura por outro médico e como ele interage com o "Todos" e com D-CM-040. | Lembrete — especificar em versão futura. |
| P-CM-036 | O Menu Lateral (Check-in de Usuários, Épico 5) tem hoje o item "Pacientes na Clínica Hoje". Com D-CM-031, o item que abre a tela de Pacientes em procedimento precisa de nome e de comportamento definidos naquela funcionalidade. **Ideia do Designer (invenção):** chamá-lo "Pacientes em procedimento", igual ao painel. | Aguarda o solicitante (outra funcionalidade). |
| P-CM-037 | **Conformidade SBIS das prescrições e do idioma** (`RequisitosSBISv5.2 ambulatorial.xlsx`). (1) ECF.16.01(c) diz que o sistema não deve permitir que outros profissionais, além do autor, vejam um registro em aberto. O toggle "Todos" mostra a prescrição ainda não assinada de um colega a qualquer médico, e "Meus" também inclui o médico assistente, que não é o autor. A decisão D-CM-036 (d) registrou que "Meus" satisfaz o requisito; a Especificação citava outro item, ECF.16.01(e) (lista com todos os registros em aberto), que a Central cobre só em parte, porque lista as prescrições até o fim da janela de assinatura. (2) ECF.17.01: o card de prescrição não mostra o médico prescritor. (3) ECF.17.18 diz "obrigatoriamente em português do Brasil" e não fala de outros idiomas; que en-US e es-419 fiquem fora da avaliação (D-CM-036 b) é uma leitura do Designer. **Ideias do Designer (invenção):** levar o conflito entre "Todos" e ECF.16.01(c) a quem conhece a avaliação da SBIS antes de decidir; se houver conflito, limitar "Todos" às prescrições já assinadas ou em revisão. | Aguarda o solicitante. |
| P-CM-038 | **Chave `id:` da busca.** D-CM-036 (c) diz que a chave existe e será mostrada na certificação. Mas ela não está especificada: não há contrato do endpoint, mapeamento de banco, texto de ajuda nem formato (por exemplo, `id:0012345`), e a massa de teste não tem número de prontuário. O protótipo ainda compara o texto digitado com o prontuário na busca comum, o que contraria a decisão. Pergunta: quer que eu especifique a chave `id:` (contrato, banco, teste)? **Ideia do Designer (invenção):** especificar só o necessário para a demonstração e tirar o prontuário da busca comum no protótipo. | Aguarda o solicitante. |
| P-CM-039 | **Cartão da prescrição quando a infusão já começou.** Uma prescrição "a assinar" com a infusão iniciada aparece como "3h00 atrasada", em vermelho; o médico pode entender que ainda não foi aplicada, quando o problema real é "paciente em infusão sem assinatura". Já a prescrição "a revisar" com a infusão iniciada some da lista (D-CM-039), embora seja falha parecida (revisão não feita antes da administração). E uma assinatura feita depois da hora da aplicação conta como "dentro da janela", sem nenhum aviso ao médico. **Ideias do Designer (invenção):** (a) com infusão iniciada, trocar o texto por "Em aplicação sem assinatura", mantendo o chip vermelho; (b) manter a "a revisar" com infusão iniciada na lista, com a marca "revisão não feita"; (c) avisar, na tela de assinatura, quando a aplicação já passou ou já começou. | Aguarda o solicitante. |
| P-CM-040 | **Prescrição vencida só sai da lista se for assinada ou revisada.** D-CM-033 diz que a correção é da Recepção (cancelar a agenda ou marcar falta). Mas as consultas de 4.6 e 4.7 não olham a situação da agenda (`Agenda.Situacao`): só `Prescricao.Situacao` e `Agenda.RemovidoEm`. Se cancelar a agenda ou marcar falta não cancelar a prescrição nem preencher `RemovidoEm`, a prescrição continua na lista e em "Urgentes". Além disso, as mais atrasadas ficam no topo e podem esconder a que está a 45 minutos da aplicação. Pergunta: cancelar a agenda ou marcar falta cancela a prescrição no sistema? **Ideias do Designer (invenção):** (a) excluir da lista as agendas canceladas ou com falta (`Agenda.Situacao` fora de A/V); (b) ordenar as vencidas há mais de alguns dias no fim da lista; (c) avisar ao assinar uma vencida: "a aplicação prevista passou há N dias". | Aguarda o solicitante (a pergunta sobre o efeito da Recepção). |
| P-CM-041 | **Textos a avaliar** (as sugestões são invenção do Designer). "30 dias atrasada" e "3h00 atrasada" soam estranhos, porque "atrasada" fica colado a "dias" e a "3h00"; alternativa: "atrasada há 3h00", "atrasada há 30 dias". "sem tempo previsto" pode ser lido como "sem horário"; o que falta é a duração da infusão na prescrição; alternativa: "duração da infusão não informada" (en-US: "Duration not set"). A confirmação de resolver ou descartar não diz que não dá para desfazer (D-CM-014); alternativa: acrescentar "Isso não pode ser desfeito." "Completo" e "Finalizado" parecem sinônimos em pt-BR; a diferença é "infusão terminada, ainda sem alta" × "alta registrada"; alternativa: "Infusão concluída" × "Alta dada" (en-US: "Infusion complete" × "Discharged"). Em "Completo", o horário do card é o do início do atendimento; a Especificação não diz isso. | Aguarda o solicitante. |
| P-CM-042 | **Divergências técnicas menores, sem efeito na massa de teste atual.** (1) O protótipo não exige `Situacao = 'V'` nos status Finalizado, Completo e Em aplicação, como exige o Mapeamento. (2) `progress` nulo tem dois significados (prescrição sem tempo de aplicação; atendimento sem início) e o contrato não traz o tempo de aplicação; o protótipo distingue os dois, o contrato não. (3) Não está dito se o painel mostra procedimentos cancelados (o status existe; o indicador só conta agendas A e V). (4) Não está dito se o front recalcula "45min restantes" entre as atualizações automáticas de 5 minutos; o protótipo recalcula. (5) Com exatamente 0 minuto restante, o texto é "0min restantes", embora a hora tenha passado. (Os itens 6 a 8 e a segunda parte do item 3 foram decididos em D-CM-052.) **Ideia do Designer (invenção):** tratar cada item como tarefa técnica pequena, depois de decidir P-CM-040 e P-CM-039. | Aguarda o solicitante (priorizar). |
| P-CM-052 | **`Conversa.IdEmpresa` deveria guardar o `IdChClinica`, e não o `IdEmpresa`?** Você achou que o ideal seria `IdChClinica` e pediu para decidir depois. Hoje o campo guarda `SegEmpresa.IdEmpresa` (D-CM-069), e a Central chega à clínica por `SegEmpresa.IdEmpresa` → `Clinica.IdEmpresa` → `IdChClinica`. Se mudar, a mensageria (`GescomMensageria.sql`: `Conversa`, `ConversaDestinatario`, `ConversaLeitura`, `Mensagem`, `ConversaAcao`, `OutboxEvento`, `Equipe` e `EquipeMembro`, com chaves compostas) e o filtro de 4.8 mudam. Nada alterado. | Adiada pelo solicitante. |
| P-CM-057 | **SBIS ECF.17.04 (eventos em ordem cronológica) com a nova ordem das conversas.** A ordem anterior foi conferida e aceita (D-CM-051). A nova (D-CM-087) usa a data mais recente entre a última mensagem e o prazo, e o prazo não é um evento ocorrido; a Mensageria classifica o item como atendimento parcial (lista em ordem de prioridade; mensagens de cada conversa na ordem de envio). Vale a mesma classificação na Central? | Aberta |

---

## Histórico de Versões

- **v1.20** (29/10/2026) — Abertura da série v6.0 (ver 01-Definição v6.0). A série v5 foi fechada na v5.20 / Registro v1.19, que foi para desenvolvimento. Nenhuma decisão, escolha ou questão nova ou alterada: tudo o que estava em aberto na v1.19 segue em aberto (escolhas E-CM-004, 018, 019, 021, 024, 027, 028, 029, 032, 033, 048, 050 e 051; questões P-CM-003, 007, 026, 035 a 042, 052 e 057). A numeração D/E/P não é reaproveitada; os próximos códigos livres são D-CM-091, E-CM-052 e P-CM-058.
- **v1.19** (29/10/2026) — Resposta do solicitante: D-CM-090 (nomes técnicos `urgencyLevel` e `timeIndicator`). A numeração D/E/P não é reaproveitada.
- **v1.18** (29/10/2026) — Respostas do solicitante: D-CM-088 (grau de urgência, ordem pelo grau e horário relativo no painel de Mensagens) e D-CM-089 (botão "Resolvido" fora do card). Nova escolha: E-CM-051. D-CM-085 recebe a nota de que o botão do card foi retirado. A numeração D/E/P não é reaproveitada.
- **v1.17** (28/10/2026) — Respostas do solicitante: D-CM-086 (E-CM-049 confirmada) e D-CM-087 (mudanças do painel de Mensagens vindas da Mensageria). D-CM-051 recebe nota de substituição. Sai E-CM-049. Nova escolha: E-CM-050 (detalhes do card de conversa). Nova questão: P-CM-057 (ECF.17.04 com a nova ordem). A numeração D/E/P não é reaproveitada.
- **v1.16** (28/10/2026) — Respostas do solicitante: D-CM-084 ("Aguardando recepção") e D-CM-085 (botões pela seção 12 do Design System). E-CM-004 fica restrita aos toggles. Nova escolha: E-CM-049 (primário do modal de mensagem e botões destrutivos). A numeração D/E/P não é reaproveitada.
- **v1.15** (27/10/2026) — Respostas do solicitante às escolhas e questões da v1.14. Novas decisões: D-CM-077 (E-CM-046 confirmada), D-CM-078 (E-CM-047 confirmada), D-CM-079 (status do procedimento em chip), D-CM-080 (troca do formato de `status` no mesmo deploy), D-CM-081 (indicador `EstadoAgendaConsulta` descontinuado depois), D-CM-082 (nomes "Em atendimento", "Em preparo" e "Em aplicação") e D-CM-083 (proveniência retirada do corpo dos documentos). Saem E-CM-046, E-CM-047, P-CM-054, P-CM-055 e P-CM-056. Nova escolha: E-CM-048 (posição do chip no card de procedimento). A numeração D/E/P não é reaproveitada.
- **v1.14** (27/10/2026) — Respostas do solicitante sobre a proposta "Cores de status por tema" da equipe de front. Novas decisões: D-CM-073 (cores e nome do status vindos da API, tabelas `DomEstadoAgendaConsulta` e `DomEstadoAgendaProcedimento`, cores globais), D-CM-074 (`administered` no lugar de `completed`), D-CM-075 (avatar com iniciais `neutral-darker` sobre a cor do status) e D-CM-076 (card cancelado com textos riscados, exceto o chip). Novas escolhas: E-CM-046 (procedimento cancelado: status em texto sem risco, avatar neutro) e E-CM-047 (caminhos dos endpoints mantidos). Novas questões: P-CM-054 (status do procedimento em chip), P-CM-055 (indicador `EstadoAgendaConsulta`) e P-CM-056 (transição do contrato de `status`, achado da Revisão por Dois Críticos). D-CM-030 e D-CM-042 recebem nota de substituição. A numeração D/E/P não é reaproveitada.
- **v1.13** (26/10/2026) — Respostas do solicitante às questões P-CM-050 (item a) e P-CM-053. Novas decisões: D-CM-070 (o médico não perde o acesso ao paciente, só às agendas e prescrições da clínica; `Paciente.IdChClinica` não afeta o médico e será filtro do administrativo e de outras funções), D-CM-071 (nome do campo de `SegEmpresa`: o do DDL) e D-CM-072 (`Clinica.FusoHorario` descontinuada, registrada no Log). D-CM-068 e D-CM-069 recebem notas de correção. Saem P-CM-050 e P-CM-053. Segue em aberto P-CM-052 (adiada pelo solicitante). A numeração D/E/P não é reaproveitada.
- **v1.12** (26/10/2026) — Respostas do solicitante às escolhas e questões da v1.11. Novas decisões: D-CM-067 a D-CM-069 (E-CM-034 confirmada: "atende" = clínicas a que o usuário tem acesso; a Agenda do Médico filtra pelas mesmas clínicas e quem perde o acesso não vê mais agendas nem pacientes da clínica; `Conversa.IdEmpresa` = `SegEmpresa.IdEmpresa` e fonte do fuso). Saem: E-CM-034 (D-CM-067) e P-CM-051 (D-CM-068); P-CM-050 fica só com o item (a). Novas questões: P-CM-052 (`IdChClinica` na mensageria, adiada pelo solicitante) e P-CM-053 (pacientes de clínica sem acesso). A numeração D/E/P não é reaproveitada.
- **v1.11** (26/10/2026) — Resposta do solicitante ao item (d) de P-CM-048 (explicado em P-CM-049): nas duas telas, Central e Agenda do Médico, o médico vê só as clínicas em que atende. Nova decisão: D-CM-066 (substitui nesse ponto D-CM-050 e D-CM-060; marcas incluídas nas duas linhas). E-CM-028, E-CM-029 e E-CM-033 ajustadas. Nova escolha do Designer: E-CM-034 (onde está "atende" no banco). Sai: P-CM-049 (respondida). Nova questão: P-CM-051 (filtro explícito na Agenda). A numeração D/E/P não é reaproveitada.
- **v1.10** (26/10/2026) — Respostas do solicitante às escolhas e questões da v1.9. Novas decisões: D-CM-061 a D-CM-065 (E-CM-030 confirmada; "hoje" das janelas de prescrição no fuso da clínica logada; itens (a) e (b) de P-CM-048 como propostos; clínica nos cards de mensagem; ligação das clínicas por `SegEmpresa` e `Clinica`, com os parâmetros por `IdChave` = `IdChClinica`). Saem: E-CM-030 (D-CM-061), E-CM-031 (substituída por D-CM-062 e E-CM-032) e P-CM-048 (resolvida, com o item (d) reescrito em P-CM-049). Novas escolhas do Designer: E-CM-032 e E-CM-033. Novas questões: P-CM-049 (Agenda do Médico, explicada com exemplo, pois o solicitante não entendeu o item (d)) e P-CM-050 (três conferências). Os padrões 1 e 7 foram conferidos (D-CM-006, D-CM-037). A numeração D/E/P não é reaproveitada.
- **v1.9** (26/10/2026) — Respostas do solicitante às questões da v1.8. Novas decisões: D-CM-055 a D-CM-060 (E-CM-020 aprovada; chips em peso regular 400; campo em repouso mantém `neutral-light`; selo "Atrasado" e número do indicador aprovados; prescrição já assinada não precisa ser assinada de novo; escopo do cliente inteiro para médicos e regras por clínica). Saem: E-CM-020, E-CM-025 e E-CM-026 (resolvidas), P-CM-043, P-CM-046 e P-CM-047 (respondidas). E-CM-028 e E-CM-029 ajustadas ao escopo do cliente. Novas escolhas do Designer: E-CM-030 e E-CM-031. Nova questão: P-CM-048. A numeração D/E/P não é reaproveitada.
- **v1.8** (26/10/2026) — Respostas do solicitante às questões da v1.7 e às perguntas "explique o que é o E-CM-020" e "mostre visualmente" (E-CM-025 e P-CM-043; a mostra visual foi entregue em 26/10/2026 e as duas seguem abertas). Novas decisões: D-CM-047 a D-CM-054 (desempate pelo nome do paciente; E-CM-023 confirmada; erro antes de selecionado; nova versão da prescrição e Central em todas as clínicas do cliente; ordem das mensagens confere com ECF.17.04; itens 3, 6, 7 e 8 de P-CM-042; chip "há 1h20" leve; selo "Atrasado" e número do KPI mais leves). Saem: E-CM-022 (substituída por D-CM-047), E-CM-023 (D-CM-048), P-CM-008 (D-CM-050), P-CM-044 (D-CM-053), P-CM-045 (D-CM-054); P-CM-026 fica só com o item (a); P-CM-042 fica com os itens 1 a 5. E-CM-024 reduzida (D-CM-049). Novas escolhas do Designer: E-CM-026 a E-CM-029. Novas questões: P-CM-046 e P-CM-047. E-CM-020 segue a confirmar (o solicitante pediu só a explicação). A numeração D/E/P não é reaproveitada.
- **v1.7** (26/10/2026) — Nova decisão D-CM-046 (anel de foco de 2px; chips de urgência leves, alternativa A; token `--color-field-changed`), aplicada na série v5.8. Autorização do solicitante: "quero que essa cor azul seja um token no design system. pode alterar os documentos" (26/10/2026), depois de ver o resultado visual de E-CM-003 e E-CM-004. Saem: E-CM-003 (resolvida) e a parte dos chips de E-CM-004, que fica restrita a botões e toggles. Novas escolhas do Designer: E-CM-023 a E-CM-025. Novas questões: P-CM-043 a P-CM-045. Revisão por Dois Críticos (26/10/2026, técnico e negócio/UX): D-CM-046 reescrita para separar o que o solicitante disse do que o Designer propôs (E-CM-024, E-CM-025); aplicadas as correções nos documentos da série.
- **v1.6** (21/10/2026) — Nova decisão D-CM-045: o solicitante aprovou ("1. ok / 2. ok", 21/10/2026) as duas recomendações do Designer para as pendências deixadas pelo crítico técnico na v1.4 (cor do destaque de conversa não lida; tamanho do percentual da barra). O contorno do chip "Urgente" segue em E-CM-004.
- **v1.5** (21/10/2026) — Nova decisão D-CM-044 (idioma da clínica e tradução sem queda para pt-BR, DT-011 e DT-012), aplicada na série v5.6.
- **v1.4** (14/10/2026) — Nova decisão D-CM-043 (Central alinhada ao Design System de 14/10/2026; `--color-on-primary` incorporado). Autorização do solicitante: "pode ajustar a central do médico" (14/10/2026), depois de aprovar no Design System a regra C8, o novo `neutral-pure` e a incorporação do token. Correção registrada na Especificação v5.5: as linhas "Badge Error" e "Badge Primary" da 2.8 contradiziam a Seção 2.2 e o protótipo e foram alinhadas a eles (não é decisão nova). Revisão por crítico técnico (subagente, Seções 2 a 4 e tokens; a Definição não mudou, sem crítico de negócio): tokens do `.html` conferidos por script contra o Design System (claro 58/58, escuros 41/41, blocos escuros idênticos); linhas novas da 2.8 e contrastes conferidos. Aplicado: comentários de contraste e de cabeçalho do `.html` que ainda citavam valores antigos ou "a incorporar"; link do `.html` no Protótipo .md; menção de E-CM-002 em D-CM-027; irmãos citados no Histórico da Especificação e dos Cenários. Não aplicado, levado ao solicitante: ícone e borda de conversa não lida — a Especificação (2.5 e 2.8) pede `primary-pure`/`secondary-pure` (1,7:1 e 2,0:1 sobre branco, abaixo de 3:1) e o protótipo usa `secondary-dark`, sem decisão registrada; tamanho do percentual da barra (2.8 diz 9px; o protótipo usa `--font-size-xs`, 10px); contorno do chip "Urgente" (2,6:1; segue em E-CM-004).
- **v1.3** (13/10/2026) — Respostas do solicitante às pendências da v1.2. Novas decisões: D-CM-027 a D-CM-042 (escolhas do Designer confirmadas; escopo "Meus"; `firstTime` em Procedimentos; status de procedimento em ordem e valores `completed`/`finished`; item do menu para a tela de Pacientes em procedimento; confirmação ao resolver/descartar conversa; "sem tempo previsto"; decisões de conformidade SBIS sobre idioma, busca e "Meus"/"Todos"; janelas de prescrição em dias de calendário; total de "Procedimentos Hoje" inclui finalizados; prescrição com administração iniciada sai de "a revisar"; assinatura na janela dispensa a revisão; texto do atraso em horas e minutos e em dias; contrato com `Response`, `System`/`User` e hora no fuso da clínica). Saem como confirmadas ou resolvidas: E-CM-001, 002, 006, 007, 008, 009, 016 e 017; P-CM-002, 004, 006, 009, 010, 023, 024, 025, 028, 029, 030, 031, 032 e 033. Novas escolhas do Designer: E-CM-018 a E-CM-021. Explicadas em linguagem simples e mantidas abertas: P-CM-003, 007, 008; P-CM-026 reduzida aos itens (a) e (e); P-CM-034 resolvida pela própria massa (a planilha salva em 13/10/2026 traz a tag 8 com sigla `C.PI`, `MostrarEm` = 38, e a paciente 14 ligada a ela: Carmen mostra IC e depois C.PI, o que só ocorre com "assistenciais primeiro"; a alfabética geral daria C.PI, IC — a sugestão da sigla "ADM" fica sem efeito); novas P-CM-035 (lembrete: parâmetros de assinatura e revisão do sistema atual) e P-CM-036 (nome do item do Menu Lateral). Seguem a confirmar E-CM-003 e E-CM-004. Revisão por Dois Críticos (13/10/2026, técnico e negócio/UX): corrigidos nos documentos os achados factuais (cabeçalhos com o Registro v1.3, `isPreferredReviewer` nos dois tipos, critérios de aceitação da assinatura na janela, citação de E-CM-020, `type` de 4.7, resíduos de "um clique", contagem da massa desatualizada); nova E-CM-022 (desempate por identificador); os achados que dependem de decisão do solicitante viraram P-CM-037 a P-CM-042. A numeração D/E/P não é reaproveitada.
- **v1.2** (10/10/2026) — Respostas do solicitante à v1.1. Novas decisões: D-CM-017 a D-CM-026 (consulta em atendimento além do previsto; "X pendentes (Y atrasadas)"; painel "Pacientes em procedimento"; progresso desde `DhAtendimentoIniUTC`; vigência de tag por data; ordem dos chips; janela de "a revisar" em dias de calendário; vencidas ficam; prescrições sem agenda ficam fora; escolhas do Designer confirmadas). Saem como resolvidas ou substituídas: E-CM-005 (por D-CM-023), E-CM-010, 012, 013 e 015 (confirmadas, D-CM-026), E-CM-011 (por E-CM-016), E-CM-014 (por D-CM-021); P-CM-011, 012, 016, 017, 018 (planilha corrigida), 019, 020, 021, 022 e 027. Novas escolhas do Designer: E-CM-016 ("2h atrasada") e E-CM-017. Questões reescritas em linguagem simples, com exemplo e ideia marcada como invenção: P-CM-023 a P-CM-026; nova P-CM-028. Revisão por Dois Críticos (10/10/2026): corrigidos inconsistências de texto e de SQL (janela de calendário em Cenários e Mapeamento, `IS NULL`, `IN (...)`, ordenação por `minutesRemaining`, notas de D-CM-006 e D-CM-013); itens que dependem de decisão viraram P-CM-029 a P-CM-034; os demais achados (acessibilidade, mensagens de erro, textos i18n, ACs faltantes, notas de versão no corpo de documentos antigos) seguem como pendências de revisão e não foram alterados. A numeração D/E/P não é reaproveitada: os códigos que saem deixam lacunas.
- **v1.1** (09/10/2026) — Respostas do solicitante às questões em aberto da v1.0. Novas decisões: D-CM-013 (prescrição vencida permanece na lista, com tempo negativo e vermelho, e conta como urgente; resolve P-CM-001), D-CM-014 (conversa sem "desfazer" e sem auditoria; resolve a parte de desfazer de P-CM-010), D-CM-015 (progresso por `Prescricao.TempoAplicacao`; resolve P-CM-013), D-CM-016 (dica do ícone de 1ª Consulta ao toque; resolve P-CM-014). D-CM-006 corrigida: o padrão da janela de revisão é 1 dia (a v1.0 dizia 2); a planilha de massa passou a ter o parâmetro. Novas escolhas do Designer: E-CM-010 (rótulo do KPI "p/assinar" montado no front com a janela enviada pelo backend; resolve P-CM-015), E-CM-011 a E-CM-013. Questões reescritas com ideias do Designer, marcadas como invenção, para o solicitante escolher: P-CM-011 (consulta em atendimento que passa do previsto), P-CM-012 (atrasadas dentro das pendentes), P-CM-016 (nome do painel). Novas: P-CM-017 (início da contagem do progresso) e P-CM-018 (nome do parâmetro na planilha de massa). Revisão por Dois Críticos (um técnico, outro de negócio e UX): achados aplicados nos demais documentos da v5.2; os que dependem de decisão do solicitante viraram P-CM-019 a P-CM-027. Novas escolhas do Designer: E-CM-014 (limite do fim da vigência de tag) e E-CM-015 (arredondamento de `hoursRemaining`). P-CM-005 saiu: a divergência era só de texto no Mapeamento, que a v4.46 já havia resolvido (prescritor ou médico assistente nas três métricas); o texto foi corrigido.
- **v1.0** (09/10/2026) — Criação do documento a pedido do solicitante ("tente separar as decisões do histórico"). Reúne as decisões de 08 e 09/10/2026 da Central do Médico (D-CM-001 a D-CM-012), as escolhas do Designer a confirmar (E-CM-001 a E-CM-009) e as questões em aberto (P-CM-001 a P-CM-016, as de 010 a 016 vindas da Revisão por Dois Críticos). Decisões anteriores à v5.0 não foram migradas: nos Históricos elas vêm entrelaçadas com a mudança que provocaram, e extraí-las perderia o contexto.