# Mensageria — Registro de Decisões (v1.33)

**Documentos desta funcionalidade:** [01 - Definição](./01%20-%20Defini%C3%A7%C3%A3o%20v1.33.md) (v1.33) · [02 - Especificação](./02%20-%20Especifica%C3%A7%C3%A3o%20v1.33.md) (v1.33) · [03 - Protótipo](./03%20-%20Prot%C3%B3tipo%20v1.33.md) (v1.33, código em `03 - Protótipo v1.33.html`) · [04 - Mapeamento de Banco de Dados](./04%20-%20Mapeamento%20de%20Banco%20de%20Dados%20v1.33.md) (v1.33) · [Cenários de Teste](./Cen%C3%A1rios%20de%20Teste%20v1.33.md) (v1.33) · 05 - Registro de Decisões (v1.33)

---

Este documento reúne as decisões do solicitante que moldam a Mensageria, as escolhas do Designer que aguardam confirmação e as questões em aberto, no mesmo formato do Registro de Decisões da Central do Médico.

Convenção: **D-MSG-xxx** = decisão do solicitante (vigente); **E-MSG-xxx** = escolha do Designer, a confirmar; **P-MSG-xxx** = questão em aberto. Itens marcados `[INVENÇÃO]` são propostas do Designer, não fatos nem decisões.

## 1. Decisões do solicitante

| ID | Data | Decisão | Onde está aplicada |
| --- | --- | --- | --- |
| D-MSG-001 | 21/10/2026 | Todas as datas e horários da mensageria usam o fuso da clínica, e cada tela mostra a linha de fuso como na Agenda do Médico (MSG-TAGM-09 e 10). | RN-MSG-005; Especificação 2.3.3; CA-MSG-002.4 |
| D-MSG-002 | 21 e 22/10/2026 | Ordem das conversas abertas: primeiro as não lidas, depois as lidas pendentes; em cada grupo, a mais nova primeiro. A data de cada conversa é a mais recente entre a última mensagem e o prazo (sugestão aceita pelo solicitante em 22/10). | RN-MSG-002; Especificação 2.3.3, 2.3.7; CA-MSG-001.1, 001.2 |
| D-MSG-003 | 21/10/2026 | "Vencida" vale também para alertas do sistema que tenham prazo. | RN-MSG-003; CA-MSG-002.2 |
| D-MSG-004 | 21/10/2026 | O prazo não pode ser anterior ao momento do envio, e a API também recusa. | RN-MSG-004; CA-MSG-002.3 |
| D-MSG-005 | 21/10/2026 | As telas de conversa mostram quem enviou e para quem foi enviada. | RN-MSG-006; Especificação 2.3.5 |
| D-MSG-006 | 22/10/2026 | O usuário pode enviar mensagem a si mesmo, como lembrete de tarefa, e aparece na lista de destinatários como "(você)". | RN-MSG-007; CA-MSG-007.1 |
| D-MSG-007 | 22/10/2026 | Qualquer participante pode resolver ou descartar; vale para todos; sem desfazer; confirmação com os textos já existentes da Central. | RN-MSG-008; Especificação 2.3.6; CA-MSG-005.1 a 005.3 |
| D-MSG-008 | 22/10/2026 | Conversa finalizada não tem campo de resposta nem mensagem artificial: o estado (Resolvida ou Descartada) é a resposta. | RN-MSG-009; CA-MSG-005.4, 005.5 |
| D-MSG-009 | 22/10/2026 | O painel da Central mostra só conversas abertas; a tela de Mensagens tem duas abas (Abertas e Finalizadas), com o mesmo cartão do painel. | RN-MSG-001, 011; Especificação 2.3.1 a 2.3.3 |
| D-MSG-010 | 22/10/2026 | O ícone à esquerda do cartão distingue pessoa de sistema (pessoa ou sino), sem foto e sem iniciais. **Substituída pela D-MSG-056 (v1.18): o ícone saiu.** | Especificação 2.3.1; CA-MSG-004.1 |
| D-MSG-011 | 22/10/2026 | Conversa não lida: borda lateral e ícone de carta (Lucide `mail`) antes do assunto. **Cor e espessura substituídas por D-MSG-021 (3 px em `secondary-dark`).** | RN-MSG-017; CA-MSG-003.1 |
| D-MSG-012 | 22/10/2026 | O cartão mostra, na segunda linha, "autor: última mensagem" e, à direita da primeira linha, data e hora da última mensagem; o chip azul é o paciente. | Especificação 2.3.1; CA-MSG-004.2 |
| D-MSG-013 | 22/10/2026 | Prazo com data e hora em um único campo, com máscara do idioma da clínica, 24 h. | RN-MSG-012; Especificação 2.3.4 |
| D-MSG-014 | 22/10/2026 | Textos nos três idiomas (pt-BR, en-US, es-419); confirmações reutilizam os textos da Central. | RN-MSG-013; Especificação 2.9 |
| D-MSG-015 | 22/10/2026 | O membro de uma equipe recebe as mensagens enviadas à equipe, inclusive as que ele mesmo enviou (resposta a P-MSG-02). | RN-MSG-015; CA-MSG-007.2 |
| D-MSG-016 | 22/10/2026 | O documento "Especificação Funcional Consolidado, Serviço de Comunicação Entre Profissionais, v1.0" (12/08/2026) é a base da Definição e da Especificação; nas divergências vale o que foi decidido em conversa. | 01 - Definição, Histórico |
| D-MSG-017 | 22/10/2026 | Ficam em aberto, por decisão do solicitante, o componente único de data e hora no React (P-MSG-04: ainda não decidiu se usará algum) e o padrão de cores dos botões (P-MSG-01: quer discutir antes). | — |
| D-MSG-018 | 22/10/2026 | As cores dos chips de estado (Resolvida em verde, Descartada em contorno, Vencida em vermelho) estão aprovadas ("ok para as cores"); resposta a P-MSG-03. (Vencida deixou de ser chip na D-MSG-053 e agora é texto vermelho com dica, D-MSG-058.) | Especificação 2.7 |
| D-MSG-019 | 27/10/2026 | Resolve P-MSG-24. Palavras do solicitante: "Não há conflito. A versão em português estará disponível integralmente". Mantêm-se os três idiomas; o pt-BR é completo e en-US e es-419 complementam. | RN-MSG-013; Especificação 2.11 |
| D-MSG-020 | 27/10/2026 | Resolve P-MSG-25: "opção B". A chave do envio por pessoa é guardada em `AlertaPublicacao` com `ModuloOrigem = 'User'`, sem hash do conteúdo. | 04, L-06; Especificação 2.8.3 |
| D-MSG-021 | 27/10/2026 | Respostas a P-MSG-09. **Ordem:** "Mensageria está correta" (a Central deve adotar a de RN-MSG-002). **Horário:** "manter ambas leituras" (a Central mostra o horário relativo, "Há 15 min"; as telas da Mensageria mostram data e hora; ver E-MSG-014 e P-MSG-28). **Borda:** "central está correta" (3 px; a cor `secondary-dark` é a de D-CM-045). **Valor no banco:** "responded é o correto" (a Central usa `replied` e deve alinhar). **Estado (selo "Respondida"):** o solicitante pediu para ver visualmente; segue em aberto (P-MSG-13). | RN-MSG-002, 017; Especificação 2.3; 04, 4.3 |
| D-MSG-022 | 27/10/2026 | Resolve P-MSG-01: "opção C com botões secundários com contorno" e, sobre o verde do botão, "vamos criar um novo token verde escuro (opção 3)". Um só botão preenchido por região; o preenchido usa o novo token `--color-primary-strong`; o secundário tem contorno. O Design System ganhou os tokens e a seção 12 (entrada de 27/10/2026 (4)). | Especificação 2.3 e 2.7; Design System |
| D-MSG-023 | 27/10/2026 | Resolve P-MSG-13. O cartão mostra só a última mensagem, com o assunto, o autor e a data e hora; a data e hora ficam à direita, na linha do assunto. Palavras do solicitante: "o chip de respondida não parece ser necessário"; "mantemos a data e hora à direita na linha do assunto"; "gostei da idéia do check / check-check, vamos implementar". Resposta nova volta a marcar o cartão como não lido (borda e carta). Resolvida ou descartada some do painel. Quem enviou vê `check` (enviada) ou `check-check` (lida). | RN-MSG-016, 018; Especificação 2.3 |
| D-MSG-024 | 27/10/2026 | Resolve P-MSG-29: "correto, o destinatário precisa ter acesso à clínica do remetente". | RN-MSG-025 |
| D-MSG-025 | 28/10/2026 | Grau de urgência da conversa, pedido dos stakeholders depois da primeira apresentação. Decisões do solicitante: opcional; quatro graus; propriedade da conversa; mostrado só quando preenchido; o 4 "apareceria se o remetente marcou"; "não é possível alterar depois do envio"; "alertas de sistema podem ter grau", e "o processo de origem decide"; nome "Grau de urgência"; os nomes seguem o domínio em `IpTerminologia.Indicadores` com termos em `TermoTraducao`. A escala é a do código legado, conferida pelo solicitante ("os números de prioridade são o inverso e têm nomes"): vazio = Não informado, 1 Baixa, 2 Média, 3 Alta, 4 Crítica. Substitui a primeira proposta (1 = mais urgente, 4 = sem urgência). | RN-MSG-034, 028, 032; Especificação 2.3.8; 04, L-09 e L-10 |
| D-MSG-026 | 28/10/2026 | Ordem com o grau: "opção B" e "sem grau (ou Não informado) fica abaixo de 4" (lido como abaixo de todos os graus, pois 4 passou a ser Crítica). Dentro de cada camada (não lidas, lidas pendentes): Crítica, Alta, Média, Baixa, sem grau; dentro do mesmo grau, a chave de data. O risco de a Crítica antiga ficar acima de uma conversa recente é da regra escolhida. | RN-MSG-002; Especificação 2.3.7 e 2.8.1 |
| D-MSG-027 | 28/10/2026 | Cores dos chips de urgência: "opção A", com a razão do solicitante: "estamos falando de um alerta, que deve chamar a atenção. Acho que podemos criar um conjunto novo para essa característica: alertas que precisam de ação com sentido de urgência/prioridade". Crítica sólida (`--color-alert-fill`); Alta com fundo claro de erro e contorno; Média neutra cheia; Baixa com contorno neutro; ícone `flag`. Sem amarelo: no tema escuro o amarelo da Alta ficava mais destacado que a Crítica e parecido com o chip de prazo. É uma exceção consciente ao padrão leve dos chips (D-CM-046, "o chip não deve pesar no card"), registrada como nova seção 13 do Design System. **Os estilos de Imediato e Quanto antes passaram a só contorno na D-MSG-057; as cores ficam.** | Especificação 2.3.8; Design System, seção 13 |
| D-MSG-028 | 28/10/2026 | Resolve P-MSG-28: "confirmado" para a regra do horário relativo da Central, no fuso da clínica. Mesmo dia e menos de 1 h: "Há x min". Mesmo dia: "Há x h". Mais de um dia: data e hora. "Mais de um dia" é lido como dia de calendário no fuso da clínica (DT-001, DT-005), como o Designer propôs e o solicitante confirmou. A Mensageria adota a mesma regra no cartão (D-MSG-032). | Guia da Central, seção 4.15; seção 4 deste documento |
| D-MSG-029 | 28/10/2026 | Confirmações do solicitante ("OK") às escolhas do Designer E-MSG-001, 008, 010, 011, 016, 017 e 018: passam a decisões (assunto obrigatório; leitura do remetente gravada no envio; resolver e descartar exigem só Visualizar; estado "lida"; seletor de grau em botões de rádio; posição e alcance do chip de urgência; contrato e valores do grau). | Linhas das escolhas na seção 2 |
| D-MSG-030 | 28/10/2026 | Resolve E-MSG-002: "limite de 2000 caracteres (adicionar contador no componente de texto)". Vale para a mensagem e para a resposta. | Especificação 2.3.4 e 2.6; CA-MSG-018.4 |
| D-MSG-031 | 28/10/2026 | Corrige E-MSG-004: "o processo é para gerar um link rápido na conversa para o objeto que se quer direcionar; só se pode escolher 1 tipo de processo por conversa (ou é o paciente ou a prescrição ou um documento; paciente = prontuário; pode haver outros tipos de processos ainda não mapeados)". O processo deixa de depender de escolher o paciente; a lista de tipos é extensível. | RN-MSG-021; Especificação 2.3.4, 2.6, 2.8.9; 04, 4.4 |
| D-MSG-032 | 28/10/2026 | Resolve E-MSG-014: "usar a leitura de horário da Central para a Mensageria". O cartão da Mensageria mostra o horário relativo (D-MSG-028); dentro da conversa segue data e hora (E-MSG-019). | RN-MSG-035; Especificação 2.3.1, 2.3.7 |
| D-MSG-033 | 28/10/2026 | Resolve P-MSG-30: "se o alerta se agrava, o módulo de origem abre nova conversa e descarta a anterior". O grau continua imutável. A tabela de ações já aceita ação sem usuário. | RN-MSG-016, 034; Especificação 2.8.10 |
| D-MSG-034 | 28/10/2026 | Resolve em parte P-MSG-32: "nome do domínio é GrauUrgencia" (em `IpTerminologia.Indicadores`). Falta definir a chave de `TermoTraducao`. P-MSG-31 fica em espera a pedido do solicitante: os termos do grau podem mudar. | 04, L-10 e 4.6 |
| D-MSG-035 | 28/10/2026 | Resolve P-MSG-33 (a): "Podemos deixar só paciente, Paciente e Prontuário é a mesma coisa, link para o prontuário do paciente". O tipo de processo é **Paciente** (leva ao prontuário). | RN-MSG-021; Especificação 2.3.4, 2.6 |
| D-MSG-036 | 28/10/2026 | Resolve P-MSG-33 (b): "para achar um documento ou uma prescrição, seria melhor que ele selecionasse primeiro o paciente (pois ambos estão dentro do prontuário do paciente). [...] navegação em 3 etapas: primeiro busca o paciente, depois seleciona o objeto (prescrição ou documento) e depois o documento ou prescrição em si". | RN-MSG-021; Especificação 2.3.4, 2.8.9; CA-MSG-019.1 a 019.4 |
| D-MSG-037 | 28/10/2026 | Resolve P-MSG-33 (c): "não sei se agenda é um objeto para link; em geral as informações importantes estão no prontuário; mas pensei em outro objeto: registro clínico, talvez seja útil poder criar um atalho para ele". **Agenda sai** da lista; **Registro clínico** entra. | RN-MSG-021; 04, 4.4 |
| D-MSG-038 | 28/10/2026 | Campos de seleção com busca: "no item do processo, ao invés de uma combo, devemos ter um autocomplete (com busca associada), inclusive no caso do paciente: para o paciente busca pelo nome; para a prescrição busca pelo ciclo+sessão (exemplo C1D15); para documentos, pode buscar pela data da inclusão ou o nome do documento; para registro clínico, pode buscar pela data do registro e/ou nome do registrante". E: "destinatário também deveria ser um autocomplete com busca, pois em clínicas grandes, pode ser que tenha que lidar com dezenas de pessoas. Se for manter o combo, eu começaria pelas equipes, depois os nomes individuais" (lido como autocomplete, com equipes antes de pessoas). | RN-MSG-036; Especificação 2.3.4, 2.3.9, 2.8.7 a 2.8.9; CA-MSG-020.2 a 020.6 |
| D-MSG-039 | 28/10/2026 | Muda o domínio do grau de urgência: "vamos usar o domínio do HL7": `Routine` (Rotina), `Urgent` (Urgente), `ASAP` (Quanto antes), `STAT` (Imediato), com os textos em pt-BR, en-US e es-419 informados. Substitui Baixa, Média, Alta e Crítica (D-MSG-025, E-MSG-016 e 018 na parte dos nomes e valores). | RN-MSG-034, 002; Especificação 2.3.8, 2.6, 2.8; 04, L-09, L-10; Design System, seção 13 |
| D-MSG-040 | 28/10/2026 | Ordem do formulário: "depois de assunto, deveria vir o campo da mensagem, só então os opcionais. Começaria com o grau de urgência e depois o prazo para resposta. Depois os outros". Ordem: Destinatário, Assunto, Mensagem, então os opcionais: grau, prazo, paciente e processo. | Especificação 2.3.4; CA-MSG-020.1 |
| D-MSG-041 | 29/10/2026 | Resolve P-MSG-35 (a): "mantemos o nome GrauUrgencia e as chaves são os termos do HL7 (routine, urgent, asap, stat)". | 04, L-09, L-10, 4.6 |
| D-MSG-042 | 29/10/2026 | Resolve P-MSG-35 (b): "não é necessário converter, vamos descontinuar aquela funcionalidade do legado". Sem conversão da prioridade antiga. | 04, L-09 |
| D-MSG-043 | 29/10/2026 | Resolve P-MSG-35 (c): "Rotina deve aparecer como chip". Os quatro graus aparecem como chip quando informados. | RN-MSG-034; Especificação 2.3.8; CA-MSG-021.1 |
| D-MSG-044 | 29/10/2026 | Resolve P-MSG-34 em parte: "em princípio, documentos e registros clínicos são ordenados por data do evento, mas isso pode mudar quando formos tocar nesses assuntos a fundo". A direção (mais recente primeiro) é proposta do Designer; as categorias de documento e de registro clínico seguem em aberto. | RN-MSG-036; Especificação 2.3.9; CA-MSG-021.3 |
| D-MSG-045 | 29/10/2026 | Aparência do cartão: o solicitante notou que os cartões da Mensageria estavam "quadrados e grudados uns nos outros" e que no sistema "os cards têm pontas arredondadas e são um pouco separadas". Não havia decisão para o estilo anterior: era uma herança do protótipo de redesenho de 22/10/2026. O cartão passa ao padrão do painel da Central. | Especificação 2.3.1, item 8; CA-MSG-021.2 |
| D-MSG-046 | 29/10/2026 | Resolve P-MSG-37: "vamos usar tudo minúsculo, como no HL7. Já alterei no BD". As chaves do grau são `routine`, `urgent`, `asap` e `stat`, no banco (`Conversa.GrauUrgencia`, `Indicadores.Indicador`), na API (`urgency.key`, envio) e no protótipo. Os nomes exibidos continuam Rotina, Urgente, Quanto antes e Imediato. | RN-MSG-034; Especificação 2.6, 2.8; 04, L-09, L-10; CT-MSG-285 |
| D-MSG-047 | 29/10/2026 | Resolve P-MSG-36 com a opção 1: "vamos remover o botão". O cartão do painel e da lista não tem botão "Resolvido"; resolver e descartar ficam só dentro da conversa (modal e página). Base: os dois críticos (UX e médico) recomendaram a mesma retirada, por causa do risco de resolver sem ler, sobretudo em alerta do sistema, e da mensagem errada do fluxo. Efeito colateral: a Central v5.18 (D-CM-085) ainda tem o botão no painel, e precisa de nova versão. | Especificação 2.3.1 item 5, 2.3.5, 2.10; CA-MSG-005.1, 021.4; CT-MSG-105, 130, 253, 266, 326 |
| D-MSG-048 | 29/10/2026 | Nomes técnicos. 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)". O campo do grau na API e no código passa de `urgency` a `urgencyLevel` (`urgencyLevel: { key, name }`; envio `urgencyLevel`; `PublishAlert.urgencyLevel`); a coluna `GrauUrgencia` e o domínio não mudam. O indicador de tempo (chip "Crítico"/"Atenção") dos painéis de Consultas e de Prescrições da Central chama-se `timeIndicator`. Substitui `urgency` em E-MSG-018 | Especificação 2.6, 2.8; 04, 4.4; CT-MSG-283 |
| D-MSG-049 | 29/10/2026 | Painel de Mensagens da Central sem limite de cartões. Palavras do solicitante: "O painel deve apresentar todas mensagens abertas e ter rolagem própria (como os outros paineis)." Sai o texto "Até 4 cartões; link 'Ver todas as mensagens' quando há mais de 4". Origem do limite: estava na Especificação desde a v1.0 (22/10/2026), sem decisão do solicitante registrada; a RN-MSG-001 e a RN-MSG-002, citadas ali, não falam de 4. Era um erro do Designer, que divergia da Central (2.5), que mostra todas as conversas não finalizadas | RN-MSG-001; Especificação 2.3.2; CA-MSG-001.1 e 001.3; CT-MSG-101, 279 |
| D-MSG-050 | 29/10/2026 | Campos de busca do item do processo na tela de nova mensagem. Palavras do solicitante: "prescrição: prescricao.identificacao (qualquer parte do termo) / documento: nome (exibir nome + data) / registro clínico: data (exibir data + modelo + profissional)". Substitui as chaves da D-MSG-038 (prescrição por ciclo e sessão; documento por nome ou data de inclusão; registro clínico por data e/ou registrante). Cada tipo filtra só pelo seu campo. O Designer mapeou as colunas na Biblioteca de Schema (DDL) em 04, 4.4.1; origem do registro clínico e data do documento são propostas (P-MSG-38) | RN-MSG-036; Especificação 2.3.9, 2.8.9; CA-MSG-020.4; 04 4.4.1; CT-MSG-315 a 317 |
| D-MSG-051 | 30/10/2026 | Origem do registro clínico e situação do documento. Palavras do solicitante: "Registro clínico: PronQuestionário é a tabela certa. Porém, Data do evento é DataEvento, profissional buscamos por IdProfissional->Profissional.IdUsuario->SegUsuario.SegurancaUsuarioId->IpSeguranca.Usuario.Apelido+Usuario.Tratamento e modelo é IdQuestionario->Questionario.Descricao. Documento: vamos ficar com essa definição por enquanto, ainda não temos uma definição clara de como implementaremos os documentos." Confirma a proposta do Designer para a tabela e o modelo; corrige a data (`DataEvento`, não `[Data]`) e o profissional (nome vem do IpSeguranca). Documento fica como está em 04, 4.4.1, provisório | RN-MSG-036; 04 4.4.1; CT-MSG-317 |
| D-MSG-052 | 30/10/2026 | Respostas do solicitante: (1) "fizemos um atalho. o SegurancaUsuarioId realmente aponta para a tabela IpSeguranca.Usuario"; (2) tratamento antes do apelido, correto; (3) a busca por data usa "dd/mm" e "dd/mm/aaaa". Fecha a P-MSG-38. Registrado o atalho como lacuna L-11 em 04 | 04 4.4.1; L-11; Especificação 2.3.9 |
| D-MSG-053 | 05/11/2026 | Novo visual do cartão de conversa. Palavras do solicitante: "não estou satisfeito com o visual. parece que não é o mesmo sistema das outras funcionalidades (...) muito pesado, muita informação competindo (...) a última mensagem deveria ter mais relevância, depois o título da thread, depois a urgência e depois as outras informações." Respostas às perguntas do Designer: conceito "cartão como a Central"; círculo à esquerda com ícone do tipo (pessoa/sino); Rotina também aparece; no celular, título e paciente ficam no cartão além de autor, horário e última mensagem. Proposta do Designer, a validar no protótipo v1.15 **[PROPOSTA]**: mensagem em 14 px até 2 linhas; título em 12 px; urgência como único chip; paciente e prazo em texto cinza com ícone; só "Vencida" colorido; fim do ícone de carta (não lida = borda e peso médio); cabeçalho do painel e contagem como na Central | 2.3.1; CA-MSG-004.2; Central 2.5 |
| D-MSG-054 | 05/11/2026 | Links e equipe no cartão. Palavras do solicitante: "sobre o paciente: quando ele aparece, ele é um link para o prontuário do paciente. quando seleciono um processo, por exemplo, uma prescrição, ele deve ser um link para essa prescrição. Se o remetente faz parte de uma equipe ela deve aparecer, pois o usuário está respondendo em nome da equipe." Aplicação do Designer: o paciente e o processo são links no cartão e no cabeçalho da conversa (o botão "Abrir …" saiu); o nome da equipe vem junto ao autor, no cartão e nas mensagens (a regra já existia na RN-MSG-030, mas o protótipo não a mostrava). **[PROPOSTA]:** a leitura de que o processo também aparece no cartão; "Você (Equipe)" para o próprio usuário; cartão com botão sobreposto, para não pôr link dentro de botão; área de toque de 44 px nos links | 2.3.1; 2.3.5; CA-MSG-021.5 e 021.6; RN-MSG-020, 021, 030 |
| D-MSG-055 | 05/11/2026 | Um só link por cartão. Palavras do solicitante: "só haverá 1 link, ou é o prontuário do paciente ou é algum processo relacionado a ele. Então no exemplo, poderia aparecer só 1 link com 'FOLFOX - C4D1 de Maria Souza'. 1. sim, o processo aparece sempre, quando houver; 2. sim, mostre 'Você (Equipe x)...'; 3. pode reduzir para data - modelo; 4. sim, o painel de mensagens da central deve receber os links (mas esse fazemos depois que fecharmos o sistema de mensageria)". Substitui os dois links da D-MSG-054 por um (processo, ou paciente quando não há processo); registro clínico no link: "data - modelo"; "Você (Equipe)" confirmado; Central v6.1 depois do fechamento da Mensageria | 2.3.1; 2.3.5; CA-MSG-009.1 e 021.5; MSG-TMSG-43 |
| D-MSG-056 | 10/11/2026 | Cartão sem ícone de tipo e com pesos reduzidos. Palavras do solicitante (05/11): "o que acha de retirar o icone de tipo? para um profissional da saúde, é importante saber se a origem é do sistema ou de uma pessoa? O remetente já diz que é do sistema ou de uma pessoa/equipe. Não podemos dar a impressão que os alertas de sistema são mais importantes do que de uma pessoa ou equipe. Pensei isso porque ainda acho que o card ainda está pesado." Aplicação do Designer, a validar **[PROPOSTA]**: o círculo com ícone sai do cartão; o autor fica em peso médio e o texto da mensagem em peso normal, lida ou não; o não lido se distingue só pela borda lateral de 3 px. A conversa (cabeçalho e mensagens) ainda mostra o sino do sistema e entra na avaliação das outras telas. Substitui D-MSG-010 | 2.3.1 itens 1, 2 e 6; CA-MSG-003.1, 004.1 e 022.4 |
| D-MSG-057 | 10/11/2026 | Chips de urgência só com contorno. Palavras do solicitante (09/11): "não sei se eu daria mais peso para a situação de vencida... acho que tem o mesmo peso da urgência"; (10/11) "para diferenciar a função [...] damos mais peso para o chip de urgência"; (10/11, depois de ver a amostra): "Escala: ok, mantemos esse layout (espessura e bandeira)". Decisão: Imediato com contorno de 2 px e bandeira cheia; Quanto antes com contorno de 1 px e bandeira vazia; sem preenchimento; as cores (`error-dark`) não mudam. Contrastes medidos no protótipo v1.18: 6,3:1 (claro) e 7,4:1 (escuro) sobre o cartão. O Design System, seção 13, ainda descreve os estilos antigos (P-MSG-41) | 2.3.8; CA-MSG-022.5 |
| D-MSG-058 | 10/11/2026 | Prazo como texto, "Vencida" curto e dica. Palavras do solicitante (10/11): "o prazo de vencimento poderia ficar sem contorno, só com o ícone de relógio. E quando vencida, fica vermelha. [...] Acho que não precisamos dizer a quanto tempo está vencida, então quando vencer, podemos colocar o label 'Vencida' [...] podemos colocar um tooltip que informa a data e hora do prazo"; respostas às interpretações do Designer: "Celular: ok, tocar no vencida abre um balão com a data e hora". Decisão: prazo a vencer = ícone `clock` e "dd/mm, hh:mm", sem contorno; vencido = `clock` e "Vencida" em vermelho, sem data; dica com "Responder até dd/mm/aaaa, hh:mm"; no celular, tocar em "Vencida" abre um balão. **[PROPOSTA] do Designer, aceita pelo solicitante:** manter a data curta ao lado do relógio quando ainda não venceu; trocar o ícone de alerta pelo relógio também em "Vencida". **[PROPOSTA] do Designer, sem resposta explícita:** fechar o balão ao tocar fora, tocar de novo ou Esc. MSG-TMSG-06 passa a "Vencida" **Confirmado em 11/11/2026:** tocar fora e tocar de novo fecham o balão; o Esc fica, com o comportamento da dica de 1ª Consulta (D-MSG-059). | 2.3.1 item 4; CA-MSG-002.1, 022.1 a 022.3; MSG-TMSG-06 |
| D-MSG-059 | 11/11/2026 | Dica do prazo igual à dica de 1ª Consulta. Palavras do solicitante: "fechar o balão: ok para tocar fora e tocar de novo. Não sei quanto ao Esc: verifique na tela da central e na lista se há alguma funcionalidade que possa conflitar com esse comportamento"; depois: "vamos manter o Esc, use o mesmo comportamento da dica 1a consulta". Verificação do Designer (código da Central v6.0 e da lista): o Esc já é usado pela dica de 1ª Consulta, pela confirmação, pelo modal de mensagem, pela lista de busca e pelo menu do usuário; o cartão fica atrás do modal e da confirmação, então não há conflito real. Decisão: mouse abre ao passar e mantém aberta; toque abre e tocar de novo fecha; tocar fora só fecha (sem acionar o que está sob o dedo); rolar, redimensionar e Esc fecham; o texto não recebe foco (o nome acessível do cartão traz a informação). **[PROPOSTA] do Designer:** usar o mesmo comportamento também no prazo a vencer (o solicitante falou só de "Vencida"); Esc fecha só a dica antes de qualquer camada de cima | 2.3.1 item 4; CA-MSG-022.1 a 022.3; Central D-CM-016 |
| D-MSG-060 | 11/11/2026 | Destinatário: fica o autocomplete, com linha de apoio mais rica; a coluna lateral do protótipo do desenvolvedor não entra. Palavras do solicitante: "vamos manter o autocomplete na seleção do destinatário com a linha mais rica. Eu acredito que nesse tipo de comunicação, o usuário saiba os nomes das pessoas, mas talvez não saiba a que equipe ela pertence (pois a configuração das equipes são feitas pelo cliente, independente de tipo de profissional ou setor/área). Poderia haver uma forma de buscar uma pessoa e atribuir para a equipe dela - não sei como fazer isso ainda." Razões do Designer para não adotar a coluna: no celular a lista empilha 432 px antes do formulário; paciente e processo continuam em autocomplete (dois padrões na mesma tela); a lista fixa escala pior que a busca (D-MSG-038). Decisão: cada pessoa mostra as equipes a que pertence; cada equipe mostra o número de membros. **[PROPOSTA]** do Designer para "buscar uma pessoa e atribuir à equipe dela": ao digitar o nome de uma pessoa, as equipes dela aparecem no grupo "Equipes" com "Inclui {nome}" (E-MSG-023) | 2.3.4; RN-MSG-036; CA-MSG-020.7; 04 4.2 |
| D-MSG-061 | 11/11/2026 | Prazo em data e horário separados, com o rótulo "Prazo para resolução". Palavras do solicitante: "data e hora: vamos adotar data e hora separados"; "rotulo do prazo: vamos usar 'Prazo para resolução'". Aplicação do Designer, a validar **[PROPOSTA]**: campos nativos do navegador (`date` e `time`, como no protótipo do desenvolvedor); os dois ou nenhum (MSG-EMSG-05 reescrita); data mínima de hoje; MSG-LMSG-26 "Data", MSG-LMSG-27 "Horário"; MSG-LMSG-11 retirado. Resolve em parte a P-MSG-04. Abre P-MSG-42 e P-MSG-43 | 2.3.4; RN-MSG-012; CA-MSG-008.2; P-MSG-04 |
| D-MSG-062 | 11/11/2026 | Pontos do protótipo do desenvolvedor, confirmados ou recusados pelo solicitante: "limite de mensagem: vamos manter 2000" (D-MSG-030); "paciente: vamos manter autocomplete" (D-MSG-038); "contexto: bloco desnecessário" (o bloco recolhível "Vincular contexto" não entra: Paciente e Processo ficam como campos do formulário, sob "Opcionais", D-MSG-040). Nenhuma mudança de regra | 2.3.4 |
| D-MSG-063 | 11/11/2026 | Equipes da pessoa no destinatário adotadas. Palavras do solicitante: "gostei da proposta de 'inclui {nome}'. vamos adotá-la". A E-MSG-023 deixa de ser [PROPOSTA] e vira decisão: a linha da pessoa mostra as equipes dela, e a busca por nome de pessoa traz as equipes dela com "n membros · Inclui {nome}" | 2.3.4; CA-MSG-020.7; RN-MSG-036 |
| D-MSG-064 | 11/11/2026 | Prazo: data obrigatória, horário opcional, sempre em 24 h, e "Resolver até" na dica. Palavras do solicitante: "o usuário pode só escolher a data (sem horário)"; "P-MSG-42: usar 'Resolver até'"; "P-MSG-43: na área médica sempre usar horário 24h (usar componente que force 24h)". Decisão: a data é obrigatória e o horário é opcional (a regra de "os dois ou nenhum" da D-MSG-061 sai); a dica passa a "Resolver até {dt}" (MSG-TMSG-05) e o nome acessível do cartão, "Vencida. Resolver até {dt}"; o horário é um campo de texto com máscara `hh:mm`, em 24 h, no lugar do campo nativo `time`. **[PROPOSTA]** do Designer: sem horário, o prazo vai até 23:59 da clínica (P-MSG-44); só o horário, sem data, dá MSG-EMSG-05 ("Informe a data do prazo."); horário inválido dá MSG-EMSG-15 | 2.3.4; CA-MSG-008.2; MSG-TMSG-05; RN-MSG-012 |
| D-MSG-065 | 11/11/2026 | Grau de urgência no formulário mais discreto. Palavras do solicitante: "pode ser mais discreto (do tamanho do chip mesmo) e quando acionado, poderia assumir as cores e ícones de seu respectivo chip nos cards". Decisão: as quatro opções têm o tamanho do chip (24 px), só o nome e contorno neutro; a marcada assume a cor, o contorno e o ícone `flag` do chip dos cartões (Imediato: 2 px e bandeira cheia; Quanto antes: 1 px; Urgente e Rotina: como nos cartões). Continua sendo rádio, e tocar na marcada a desmarca. **[PROPOSTA]** do Designer: área de toque de 44 px por uma área invisível ao redor | 2.3.4; 2.3.8; E-MSG-016 |
| D-MSG-066 | 11/11/2026 | Prazo sem horário mostra só a data. Palavras do solicitante: "Pra prazo sem horário, só exibe a data. Internamente tratamos como até 23:59 do dia selecionado". Decisão: sem horário, o prazo vale até 23:59 da clínica e o cartão, a dica e a conversa mostram só a data. **[PROPOSTA]** do Designer para não criar coluna: um prazo gravado às 23:59:00 da clínica é tratado como "sem horário"; a alternativa é a coluna `PrazoComHorario` (bit) | 2.3.4; CA-MSG-008.2, 022.1; RN-MSG-012 |
| D-MSG-067 | 11/11/2026 | Categorias dos itens do processo e paginação. Palavras do solicitante: "vamos definir as categorias quando trabalharmos com o input de documentos (provavelmente são os modelos de documento). Para os registros clínicos, a categoria é o modelo de formulário. Acredito que não sejam muitos dados a ponto de precisar de paginação". Decisão: Documento, por modelo de documento (lista a definir com o input de documentos); Registro clínico, por modelo de formulário; sem paginação. Resolve em parte a P-MSG-34 | 2.3.9; 2.8.9 |
| D-MSG-068 | 11/11/2026 | Busca de paciente igual à do cabeçalho. Palavras do solicitante: "vamos utilizar o mesmo componente da busca de pacientes do cabeçalho (a linha contém o nome, data de nascimento e cpf), e se busca por nome ou cpf". Decisão: a linha traz nome, data de nascimento e CPF; a busca é por nome ou CPF. **Substituída em parte pela D-MSG-071:** o solicitante corrigiu a leitura do Designer; a busca tem os mesmos critérios da Central. Responde à pergunta de P-MSG-17 sobre o dado que desambigua e sobre a busca por CPF | 2.3.4; CA-MSG-020.3; 2.8.8 |
| D-MSG-069 | 11/11/2026 | Destinatário que não pode receber. Palavras do solicitante: "ok sobre a recusa. Alertas de sistema que emitem para usuários que não podem receber gera log de anomalia para o suporte avisar o cliente". Decisão: o envio por pessoa é recusado (EX-MSG-07); o alerta do sistema para quem não pode receber não é entregue e grava anomalia no log de sistema do projeto. **Confirmada em 11/11/2026** ("concordo"), com a proposta de o módulo de origem receber "não entregue" na chamada de publicação; o que conta como "não pode receber" (inativo, de licença, sem Visualizar, equipe sem membros ativos) segue o EX-MSG-07 | EX-MSG-07; 2.8.10 |
| D-MSG-070 | 11/11/2026 | Resolver e descartar exigem só o direito Visualizar. Palavras do solicitante: "P-MSG-12: aceito E-MSG-010". Já estava confirmada na D-MSG-029 (28/10/2026), e a linha da P-MSG-12 estava desatualizada; fica reafirmada. Retirados os marcadores [PROPOSTA, P-MSG-12] da Especificação e do CT-MSG-180 | CA-MSG-010.2 |
| D-MSG-071 | 11/11/2026 | Busca de paciente com o componente do cabeçalho, completo. Palavras do solicitante: "pode usar o componente do cabeçalho do jeito que está, com todas as funcionalidades. Então haverá busca por nome da mãe e data de nascimento. Inclusive o dropdown pode ser o mesmo". Decisão: mesma busca e mesmo dropdown da Central (2.1): nome e nome da mãe (entrada com letra), CPF e data de nascimento (entrada com dígito), mínimo de 2 caracteres, rodapé de orientação, e resultados com nome, prontuário, sexo, nascimento, mãe e CPF. A única diferença é o efeito de escolher: preencher o campo, em vez de abrir o prontuário. Corrige a leitura da D-MSG-068 | 2.3.4; CA-MSG-020.3; 2.8.8; Central 2.1 |
| D-MSG-072 | 11/11/2026 | Paciente errado: descartar e enviar outra. Palavras do solicitante: "se o usuário errar o paciente, deve descartar a msg (de preferência dizendo que colocou o paciente errado) e criar outra". Decisão: a associação continua imutável (RN-MSG-020); o remetente responde na própria conversa que o paciente estava errado, descarta e envia outra. Sem campo novo: o aviso é uma resposta comum. O Designer não incluiu motivo no descarte (ver a pergunta de P-MSG-45) | RN-MSG-020; CA-MSG-020.8 |
| D-MSG-073 | 11/11/2026 | Motivo do descarte não entra agora. Palavras do solicitante: "P-MSG-45: vamos deixar como está e ver a necessidade desse rigor, quando em produção". Decisão: o aviso de paciente errado continua sendo uma resposta comum antes de descartar (D-MSG-072); revisar com a experiência de produção | D-MSG-072 |
| D-MSG-074 | 11/11/2026 | Fechamento da tela de nova mensagem. Palavras do solicitante: "E-MSG-020: ok, correto. E-MSG-021: ok, mantemos o padrão. Data mínima: correto. Área de toque: ok. Prazo sem horário: ok. [P-MSG-07 e 34] correto, vamos aguardar. [P-MSG-41] ok". Confirmadas: E-MSG-020 (trocar o paciente zera tipo e item; tipo sem item dá erro), E-MSG-021 (padrão de autocomplete; o campo Paciente segue a busca do cabeçalho, D-MSG-071), data mínima de hoje no prazo, área de toque de 44 px do seletor de grau e tratamento do 23:59:00 como prazo sem horário (D-MSG-066). P-MSG-07, 34 e 41 aguardam (itens por módulo, modelos de documento, Design System) | 2.3.4; 2.3.9; 2.8.9 |
| D-MSG-075 | 11/11/2026 | Tela Conversa eliminada: fica só o modal. O solicitante perguntou: "Será que é necessário ter os 2? Pois o conteúdo é o mesmo, só que um está restrito em um modal e o outro é uma página"; o Designer recomendou uma só tela, o modal, também na lista; o solicitante: "concordo. Vamos eliminar a tela Conversa". Estrutura do modal, conforme o solicitante: no cabeçalho, título da conversa, De e Para, tags de urgência, link do processo ou do paciente e tag de prazo; abaixo, a trilha, com cartões que mostram o remetente, os ícones de envio e leitura, a data e hora e a mensagem; no fim da trilha, o campo de resposta e o botão "Responder". Leitura do Designer: o cabeçalho é fixo (não rola com a trilha). Reaproveita o modal da Central; a Central v6.1 não precisa mudar por causa disso | 2.3.5; 2.3.1 item 5; RN-MSG-006 |
| D-MSG-076 | 11/11/2026 | Resolver e Descartar no cabeçalho do modal, em verbos. Proposta do solicitante (11/11): botões "Descartado" e "Resolvido" no cabeçalho, com os verbos "Descartar" e "Resolver"; o Designer opinou a favor, com cuidados; o solicitante: "concordo". Decisão: os botões ficam em linha própria no cabeçalho, abaixo do link e longe do "x"; os dois com contorno (o único botão preenchido do modal é "Responder", Design System, seção 12); só em conversa aberta, inclusive alerta do sistema; ordem Resolver, Descartar; as confirmações e os textos delas não mudam. A Central precisa adotar os mesmos verbos no modal dela (v6.1, P-MSG-39) | 2.3.5; MSG-BMSG-06 e 07; CA-MSG-005.1 |
| D-MSG-077 | 11/11/2026 | Ajustes de layout do modal, após ver o protótipo v1.27. Pedido do solicitante: Resolver e Descartar ao lado das linhas De e Para, e "Responder" desalinhado do campo. Decisão: os dois botões ficam à direita das linhas De e Para, um sobre o outro (largura de 360 px não comporta os dois lado a lado), e o link e os chips seguem abaixo; "Responder" alinhado ao topo da caixa do campo, com a mesma altura; o contador fica abaixo da caixa. Substitui a posição "em linha própria" de D-MSG-076; o resto de D-MSG-076 permanece | 2.3.5; CA-MSG-005.1 |
| D-MSG-078 | 11/11/2026 | Botões do cabeçalho conforme a largura e fechamento de itens em aberto do protótipo. Palavras do solicitante: "no desktop, se houver espaço, comece com os 2 botões na mesma linha, qdo não houver espaço empilhe-os"; "E-MSG-016: concordo com o seletor"; "E-MSG-017: chip de urgência está ótimo do jeito que está (primeiro da 3a linha)"; "Prazo para resolução: já está definido"; "Processo relacionado: já está registrado que detalharemos quando criarmos as funcionalidades". Decisão: Resolver e Descartar ficam lado a lado quando a área útil do cabeçalho tem 480 px ou mais (desktop) e empilhados quando não (celular); refina D-MSG-077. E-MSG-016 e 017 reafirmadas (já confirmadas na D-MSG-029); a [PROPOSTA] da D-MSG-065 sobre rádio desmarcável e chip também em Finalizadas e na conversa fica confirmada. Prazo: sem pendência. Processo relacionado: categorias detalhadas nas funcionalidades de documentos e registros clínicos (D-MSG-067, 074). Retirados da lista "Em aberto" do protótipo | 2.3.5; 2.3.4; E-MSG-016; E-MSG-017 |
| D-MSG-079 | 12/11/2026 | Sino do cabeçalho adiado (P-MSG-06). Palavras do solicitante: "O sino no cabeçalho é uma proposta inicial, concebida para ser um dropdown de tarefas pendentes do usuário. Porém o painel do profissional já faz esse papel. Vamos deixar em aberto até maturarmos essa necessidade (veremos isso quando o sistema for para produção)". Decisão: nenhum comportamento é definido para o sino do cabeçalho (sem contador, sem dropdown) e a Mensageria não depende dele; o painel do profissional cumpre o papel de lista de pendências. A necessidade será reavaliada em produção. O sino dentro do modal (mensagem do sistema) não muda | P-MSG-06; 2.3.1 |
| D-MSG-080 | 12/11/2026 | Verbos nos botões, também na Central. Palavras do solicitante: "P-MSG-39: adotamos os verbos nos botões". Decisão: a Central do Médico adota "Resolver" e "Descartar" nos botões do modal dela, como a Mensageria (D-MSG-076). O resto da P-MSG-39 (cartão e hierarquia na Central v6.1) continua para depois do fechamento da Mensageria | P-MSG-39 |
| D-MSG-081 | 12/11/2026 | Atualização do Design System. Palavras do solicitante: "P-MSG-41: pode atualizar o design system". Feito em 12/11/2026 (Design System, seções 12 a 14): chips de urgência só com contorno (D-MSG-057), seletor do grau (D-MSG-065), prazo em texto com dica (D-MSG-058, 059) e ações no cabeçalho de modal (D-MSG-076 a 078). Nenhum token novo; o botão Danger segue indefinido | P-MSG-41 |
| D-MSG-082 | 12/11/2026 | Quem sai da equipe. Palavras do solicitante: "P-MSG-20: aceita a proposta: vê o histórico, mas só age enquanto for membro". Decisão: quem recebeu uma conversa pela equipe e saiu continua vendo o histórico dela e deixa de poder responder, resolver ou descartar. Confirmado em 12/11/2026 (D-MSG-088): quem enviou a conversa continua agindo mesmo sem ser membro (CA-MSG-014.1 já prevê autor que não é da equipe) | RN-MSG-015; CA-MSG-007.4 |
| D-MSG-083 | 12/11/2026 | Recepção terá uma Central. Palavras do solicitante: "P-MSG-22: Recepção terá uma central também". Decisão: a recepção não usa só a tela de Mensagens; terá a sua Central, e o painel de Mensagens da Mensageria passa a poder aparecer nela, como nas demais. O desenho da Central da recepção é de outra funcionalidade | P-MSG-22 |
| D-MSG-084 | 12/11/2026 | Vencida antes das datas a vencer. Palavras do solicitante: "P-MSG-27: priorizar vencido antes das datas a vencer". Decisão: dentro do mesmo grau de urgência e da mesma camada, a conversa vencida vem antes das demais (RN-MSG-002). Entre vencidas, a mais atrasada primeiro (confirmado em D-MSG-088); o grau de urgência continua antes do vencimento (D-MSG-026) | RN-MSG-002; CA-MSG-001.6 |
| D-MSG-085 | 12/11/2026 | Valores de `ProcessoTipo` e `ProcessoChave` (P-MSG-07). Palavras do solicitante: "ProcessoTipo terá: Paciente, Prescricao, Documento, RegistroClinico, Agenda - essa lista pode aumentar conforme a necessidade dos usuários (mas implementada pelo desenvolvimento). O ProcessoChave será a chave do item. Por exemplo, para o paciente será o IdPaciente em Paciente, para a prescrição, será o IdPrescricao em Prescricao, para o Documento, será o IdPEP em PEPDocumento, para o registro clínico, será o IdQuestResposta em PronQuestionario, para a agenda será o IdAgenda em Agenda". Decisão: cinco tipos, com essas chaves, todas chave primária na Biblioteca de Schema (DDL); **Agenda volta à lista** (tinha saído em D-MSG-037). Resta definir busca e exibição do item de Agenda (**[PROPOSTA]**, P-MSG-48) | 04, 4.4 e 4.4.1; RN-MSG-021, 036; 2.8.9 |
| D-MSG-086 | 12/11/2026 | Filtros, busca e paginação das listas (P-MSG-47). Palavras do solicitante: concordou com os pontos 1 a 11 da análise do Designer (12/11/2026), e sobre "Enviadas por mim": "são as enviadas por mim" (as que o usuário iniciou). Decisão: RN-MSG-037 (filtros de Abertas e de Finalizadas, período padrão de 3 meses com presets, busca nas duas abas, resumo e limpar, "Buscar em todo o período", "Mostrar mais" com 20 e 50). As três [PROPOSTA] que ficaram (opções do período, data de finalização e contagem de Finalizadas) foram confirmadas em D-MSG-089 | RN-MSG-037; 2.3.3; 2.8.1; CA-MSG-023.1 a 023.7 |
| D-MSG-087 | 12/11/2026 | Retenção e acesso ao conteúdo (P-MSG-21). Palavras do solicitante: "P-MSG-21: aprovada proposta". Decisão: sem prazo de expurgo até haver política de retenção; só quem participa lê o conteúdo; gestor e auditor não leem conteúdo alheio; a trilha registra ações sem conteúdo | RN-MSG-038 |
| D-MSG-088 | 12/11/2026 | Confirmações. Palavras do solicitante: "P-MSG-27: mais atrasadas primeiro" e "quem enviou continua agindo" (a mensagem dizia P-MSG-21; é a P-MSG-20, que trata de quem sai da equipe). Decisão: entre conversas vencidas do mesmo grau, a mais atrasada primeiro; quem enviou a conversa continua agindo mesmo sem ser membro da equipe | RN-MSG-002, 015; CA-MSG-001.6, 007.4 |
| D-MSG-089 | 12/11/2026 | Pontos em aberto de filtros e período (P-MSG-47). Palavras do solicitante: "1. ao invés de Todo o período, o label pode ser 'Tudo'. Concordo com o Personalizado com 2 datas / 2. ok / 3. ok". Decisão: o período tem 3 meses (padrão), 6, 12, **Tudo** e **Personalizado** (data inicial e final); o período vale pela data de finalização; o total da aba Finalizadas não considera o período. Os textos em inglês e espanhol de "Tudo" (All, Todo) são escolha do Designer | RN-MSG-037; MSG-LMSG-34, 35; 2.8.1 |
| D-MSG-090 | 12/11/2026 | Item de Agenda (P-MSG-48). Palavras do solicitante: "4. ok, busca pela data, mostrar também o tipo (Consulta, Quimioterapia, Radioterapia, etc)". Decisão: o item de Agenda é buscado pela data e mostra a data e a hora de início e, abaixo, o tipo. **[PROPOSTA]** do Designer: o "tipo" é a classificação da agenda (`AgendaClassificacao.Descricao` por `Agenda.IdAgendaClassificacao`, a mesma que a Agenda do Médico chama de tipo de consulta, RN-AGM-008); os valores não foram conferidos | RN-MSG-021; 2.3.9; 2.8.9; 04, 4.4.1 |
| D-MSG-091 | 12/11/2026 | Filtro rápido no Design System (P-MSG-49). Palavras do solicitante: "5. ok, vamos definir um filtro rápido no design system". Decisão: a seção 15 do Design System define o filtro rápido (botão alternável de 32 px, área de toque de 44 px, ativo com borda `neutral-dark` e `check`, fila com rolagem horizontal) | Design System, seção 15; 2.7 |
| D-MSG-092 | 12/11/2026 | Campos com rótulo flutuante como padrão (formulário de nova mensagem). Palavras do solicitante: "No questionário dinâmico, definimos um padrão de comportamento dos componentes de input: cinza claro quando em estado inicial, com o label da pergunta como placeholder em neutral pure; quando focado, fica com a borda neutral dark e o placeholder se torna um label na borda superior do campo; quando o valor do input for diferente do original, fica com a borda azul clara; se o conteúdo ficar errado, fica com a cor vermelha com a msg do erro embaixo. Vamos tornar esse comportamento padrão". Decisão: o comportamento vale para todos os campos do formulário e entra no Design System (seção 11, "Campo com rótulo flutuante"). Substitui a decisão anterior de rótulo fixo acima do campo (2.3.4). "Horário" perde o "(opcional)" porque o rótulo agora ocupa o espaço do campo. O que o solicitante não descreveu ficou como [PROPOSTA] (P-MSG-50) | 2.3.4; 2.3.10; 2.7; 2.10; Design System, seção 11 |

## 2. Escolhas do Designer, a confirmar

| ID | Escolha | Motivo | Onde está |
| --- | --- | --- | --- |
| E-MSG-001 | Assunto obrigatório também para mensagens de pessoas **Confirmada (D-MSG-029).** | O banco exige assunto (até 200 caracteres) e a tela já desenvolvida o exige; o documento anexado dizia que só destinatário e texto eram obrigatórios | RN-MSG-028 (alertas); Especificação 2.6 |
| E-MSG-002 | Mensagem e resposta com até 4000 caracteres. **Substituída por D-MSG-030: 2000 caracteres, com contador no componente de texto.** | O banco aceita texto ilimitado; um limite protege a lista e o painel | Especificação 2.6 |
| E-MSG-003 | Lista paginada de 20 em 20 | Evita carregar todas as finalizadas. Valor `[INVENÇÃO]` | Especificação 2.3.3, 2.8.1 |
| E-MSG-004 | Processo relacionado só depois de escolher o paciente. **Substituída por D-MSG-031: o processo é um atalho de um só tipo, sem depender do paciente.** | O solicitante corrigiu o modelo | Especificação 2.3.4, 2.6 |
| E-MSG-005 | Chave de requisição (`Idempotency-Key`) no envio | Evita duplicar conversa em reenvio por falha de rede | Especificação 2.8.3 |
| E-MSG-006 | Interface interna de publicação de alerta (`PublishAlert`) | O documento anexado pede uma interface de integração; a forma é proposta com base nas tabelas de idempotência e de fila de eventos já existentes | Especificação 2.8.10 |
| E-MSG-007 | Texto "Atualização do sistema" para mensagens do tipo atualização | Distinguir da mensagem inicial do alerta | MSG-TMSG-30 |
| E-MSG-008 | A leitura do remetente é gravada ao enviar **Confirmada (D-MSG-029).** | Quem escreveu já viu; evita "não lida" na própria mensagem | Mapeamento 4.1 |
| E-MSG-009 | Auditoria do endereço de origem pela trilha central de segurança (opção A) | Não altera o schema da mensageria | Mapeamento 4.5, L-01 |
| E-MSG-010 | Resolver e descartar exigem só o direito Visualizar **Confirmada (D-MSG-029).** | O destinatário de um alerta precisa tratá-lo mesmo sem poder enviar | Especificação 2.4 (CA-MSG-010.2) |
| E-MSG-011 | O estado da conversa inclui "lida" (pelo menos um destinatário abriu) e é visível ao remetente; a leitura individual continua separada **Confirmada (D-MSG-029).** | O banco já tem o estado e o problema de negócio é o remetente saber o andamento | RN-MSG-016 |
| E-MSG-012 | Valores do botão primário e do secundário: `#007A13` com texto branco (5,5:1), igual nos dois temas; contorno do secundário em `neutral-pure` e texto em `neutral-dark` | Opção 3 do solicitante; o `primary-dark` não serve de preenchimento porque vira texto claro no tema escuro | Design System, seção 12 |
| E-MSG-013 | Chave de idempotência do envio por pessoa gravada como `{IdUsuario}:{Idempotency-Key}` | Evita que duas pessoas com a mesma chave colidam no índice único | Especificação 2.8.3; 04, L-06 |
| E-MSG-014 | Leitura de "manter ambas leituras" do horário: cada tela mantém o seu formato (Central relativo; Mensageria data e hora). **Substituída por D-MSG-032: a Mensageria usa a leitura de horário da Central no cartão.** | O solicitante pediu a mesma leitura nas duas telas | Especificação 2.3 |
| E-MSG-015 | Cor dos ícones: `check` em `neutral-pure` e `check-check` em `secondary-dark`; o ícone também nas mensagens do usuário dentro da conversa; o `check-check` em conversa de equipe vale quando pelo menos um membro leu | Detalhes que o solicitante não definiu; a forma distingue os dois, a cor só reforça | Especificação 2.3 e 2.8 |
| E-MSG-016 | Seletor do grau no formulário: quatro botões de rádio lado a lado com número e nome, nenhum marcado por padrão; tocar na opção marcada a desmarca; texto de ajuda sobre a imutabilidade **Confirmada (D-MSG-029).** **Nomes, números e contrato revistos por D-MSG-039 (domínio HL7).** | Tocar é mais rápido que abrir uma lista; os nomes ficam visíveis; "Não informado" é o estado sem seleção. Alternativa: lista suspensa | Especificação 2.3.4 |
| E-MSG-017 | Posição e alcance do chip: depois do chip do paciente e antes do de prazo; aparece em Abertas, Finalizadas e no cabeçalho da conversa; texto "Urgência {nome}" **Confirmada (D-MSG-029).** | O solicitante pediu "mostrar só se preenchido", sem definir onde. Em Finalizadas o chip perde utilidade; mostrá-lo mantém a mesma estrutura do cartão (RN-MSG-011) | Especificação 2.3.1, 2.3.8 |
| E-MSG-018 | Contrato e valores: leitura `urgency: { level, name }|null`; envio `urgency: 1..4|null`; coluna `GrauUrgencia tinyint NULL` com `CHECK`; alerta pelo `PublishAlert.urgency`; `AppendAlertUpdate` sem `urgency`; a imutabilidade vale porque a API não tem endpoint de alteração. Valores dos chips: Média `neutral-lighter` e `neutral-dark`; Baixa contorno `neutral-light`; Alta `error-light`, `error-dark` e contorno `error-dark`; Crítica `alert-fill` (token que já existe) **Confirmada (D-MSG-029).** **Nomes, números e contrato revistos por D-MSG-039 (domínio HL7).** | O solicitante pediu "a opção A" sem os valores; os tokens usados já existem no Design System, sem token novo | Especificação 2.3.8, 2.8; 04 L-09 |
| E-MSG-019 | Detalhes do horário relativo e do descarte automático: x inteiro por truncamento com mínimo de 1 min; dentro da conversa o horário segue em data e hora; recálculo a cada atualização de 1 minuto; descarte do alerta anterior por chamada `DismissAlert`, exibido como "Descartada por Sistema" | O solicitante definiu a regra do cartão e que a nova conversa descarta a anterior, sem estes detalhes | Especificação 2.3.7, 2.8.10 |
| E-MSG-020 | **Confirmada em 11/11/2026 (D-MSG-074).** Detalhes da escolha em três etapas: (1) a etapa do paciente é o próprio campo "Paciente" do formulário (não há segunda busca); (2) o tipo só habilita depois do paciente; (3) trocar o paciente limpa o tipo e o item; (4) enviar com tipo e sem item mostra MSG-EMSG-14; (5) o tipo Paciente não tem etapa 3. O solicitante descreveu a navegação, não estes detalhes | Evita pedir o paciente duas vezes | Especificação 2.3.4, 2.8.9 |
| E-MSG-021 | **Confirmada em 11/11/2026 (D-MSG-074).** Comportamento da busca com autocomplete (**o campo Paciente segue a busca do cabeçalho, D-MSG-071**): atraso de 300 ms; sem texto, as primeiras 8 opções; até 8 resultados com aviso de mais; ignora maiúsculas e acentos; vários termos combinados; digitar de novo limpa a escolha; padrão de caixa de combinação para teclado e leitor de tela; busca no servidor com `q` e `limit`. O solicitante definiu os campos e as chaves de busca, não estes detalhes | Padrões comuns de autocomplete; evita baixar listas grandes | Especificação 2.3.9 |
| E-MSG-022 | **Rotina como chip confirmado (D-MSG-043).** (1) O chip mostra só o nome do grau, com título "Grau de urgência: {nome}", porque "Urgência Urgente" repetiria a palavra; (2) correspondência dos quatro valores com os quatro estilos do chip: Imediato = sólido `alert-fill`, Quanto antes = fundo de erro claro com contorno, Urgente = neutro cheio, Rotina = contorno neutro; (3) coluna `GrauUrgencia varchar(10)` guardando a chave HL7, ordem pela `Ordem` do cadastro (Rotina 1 a Imediato 4); (4) contrato `urgency: { key, name }`; (5) subtítulo "Opcionais" no formulário | Mantém as cores já aprovadas e o domínio como veio do solicitante | Especificação 2.3.4, 2.3.8, 2.8; 04 L-09 |
| E-MSG-023 | **Equipes da pessoa no destinatário (D-MSG-060). Adotada em 11/11/2026 (D-MSG-063).** (1) A linha da pessoa mostra até duas equipes e "+n", ou "Sem equipe"; (2) a busca pelo nome de uma pessoa traz também as equipes dela no grupo "Equipes", com "n membros · Inclui {nome}"; (3) contrato: `people[].teams` e `teams[].matchedMembers`; (4) dados de `EquipeMembro` (membro ativo) e `Equipe` (ativa). O solicitante pediu "uma forma de buscar uma pessoa e atribuir para a equipe dela" e disse não saber como; o Designer escolheu esta, que não cria tela nem tabela | Resolve a necessidade sem lista lateral e sem novo padrão; aproveita a ordem "equipes antes de pessoas" (D-MSG-038) | Especificação 2.3.4, 2.8.7; 04 4.2 |
| E-MSG-024 | **Modal como única tela da conversa (D-MSG-075).** (1) Endereço da conversa (`/mensagens/{id}`) que abre a lista com o modal por cima (links de notificação e do suporte); (2) o botão Voltar do navegador fecha o modal; (3) o foco volta ao cartão ao fechar; (4) no celular, folha de altura quase total; (5) cabeçalho fixo e trilha rolável. O solicitante decidiu eliminar a tela, não estes detalhes | Sem página, o endereço e o Voltar do navegador precisam ter um destino claro; altura total e cabeçalho fixo servem a thread longa e ao teclado da resposta | 2.3.5; CT-MSG-350 a 352 |

## 3. Questões em aberto

| ID | Questão | Situação |
| --- | --- | --- |
| P-MSG-01 | Padrão de cores dos botões | **Resolvida** (D-MSG-022) |
| P-MSG-02 | O usuário que pertence à equipe recebe a mensagem enviada à equipe? | **Resolvida:** sim (D-MSG-015) |
| P-MSG-03 | Cores dos chips de estado | **Resolvida** (D-MSG-018) |
| P-MSG-04 | Componente único de data e hora no React (a data só, ou data e hora) | **Resolvida (D-MSG-061 e 064):** data e horário em dois campos; horário opcional e em 24 h |
| P-MSG-05 | Conformidade SBIS da auditoria de resolver e descartar | **Verificada** (Especificação 2.11); lacunas em P-MSG-14 |
| P-MSG-06 | Sino do cabeçalho com contagem de não lidas e vínculo de contexto, itens apontados na auditoria das telas (21/10/2026) | **Adiada (D-MSG-079):** o painel do profissional já faz o papel de pendências; reavaliar em produção |
| P-MSG-07 | Valores de `ProcessoTipo` e `ProcessoChave` e como o formulário lista os processos de um paciente | **Resolvida (D-MSG-085):** cinco tipos e as chaves; a busca e a exibição de Agenda são [PROPOSTA] (P-MSG-48) |
| P-MSG-08 | Depois de uma resposta, o estado "Respondida" volta a "Enviada" quando quem enviou responde? O documento anexado previa uma "réplica" que reabria; o banco aboliu `Reply` em 28/08/2026 e a Central grava toda resposta como "Respondida" | Em aberto; hoje toda resposta leva a "Respondida" |
| P-MSG-09 | Alinhamento da Central do Médico (próxima versão) | **Respondida em parte** (D-MSG-021): ordem da Mensageria; borda e cor da Central; `responded`; horário nos dois formatos. Segue em aberto o selo de estado (P-MSG-13) e o título do modal. A Central precisa de nova versão (a pedir) |
| P-MSG-10 | Direitos Visualizar e Enviar: nomes, valores de ação, perfis iniciais e processo no menu | Em aberto (Mapeamento 4.6) |
| P-MSG-11 | Ordem da aba "Finalizadas" | Proposta na Especificação 2.3.3: pela data de finalização, mais nova primeiro; confirmar |
| P-MSG-12 | Resolver e descartar sem o direito Enviar | **Resolvida (D-MSG-029 e 070):** E-MSG-010 confirmada |
| P-MSG-13 | Selo de estado no cartão | **Resolvida** (D-MSG-023): sem chip de estado; a resposta aparece como última mensagem e o ícone `check`/`check-check` mostra a leitura |
| P-MSG-14 | Lacunas SBIS L-01 (endereço de origem na trilha) e L-02 (cascata de exclusão) | Em aberto; propostas no Mapeamento 4.5 |
| P-MSG-15 | P-CM-026(a): o consultor jurídico quer a mensageria fora do escopo SBIS | Herdada da Central; em aberto |
| P-MSG-16 | Alerta recorrente: hoje, atualização na mesma conversa enquanto aberta e nova conversa ligada depois de finalizada (RN-MSG-016). O anexo previa reenvio. Também: o módulo de origem fica sabendo se o alerta foi resolvido ou descartado? | Em aberto |
| P-MSG-17 | Paciente errado ou homônimo | **Resolvida (D-MSG-071 e 072):** a busca é a do cabeçalho, com nascimento, mãe e CPF na linha; paciente errado: descartar e enviar outra |
| P-MSG-18 | Lista de "enviadas por mim, aguardando resposta" para o remetente (o anexo previa a lista com estado) | Em aberto |
| P-MSG-19 | Destinatário inativo, de licença ou sem o direito Visualizar; equipe sem membros ativos; alerta não entregue | **Resolvida (D-MSG-069):** envio recusado; alerta não entregue gera anomalia no log de sistema |
| P-MSG-20 | Quem sai da equipe: continua vendo e agindo nas conversas que recebeu? | **Resolvida (D-MSG-082 e 088):** vê o histórico; só age enquanto for membro; quem enviou continua agindo |
| P-MSG-21 | Retenção das conversas, acesso de gestão ou auditor ao conteúdo, e busca por paciente ou assunto | **Resolvida (D-MSG-087 e 086):** sem expurgo até haver política; sem acesso da gestão ao conteúdo; busca por paciente ou assunto na RN-MSG-037 |
| P-MSG-22 | A recepção não tem Central; usa só a tela de Mensagens? | **Resolvida (D-MSG-083):** a recepção terá uma Central |
| P-MSG-24 | Idioma e SBIS | **Resolvida** (D-MSG-019) |
| P-MSG-25 | Idempotência do envio por pessoa | **Resolvida** (D-MSG-020, opção B) |
| P-MSG-26 | Tipos de evento da fila de eventos (`OutboxEvento`) | Em aberto |
| P-MSG-27 | Risco da ordem (RN-MSG-002): prazo distante mantém a conversa no topo do seu grupo e a vencida afunda abaixo de mensagens novas. Manter, ou dar prioridade ao vencido? | **Resolvida (D-MSG-084 e 088):** vencida antes das demais no mesmo grau, a mais atrasada primeiro |
| P-MSG-23 | Usuário com acesso a várias clínicas: vê conversas de todas ou só da clínica ativa? | **Respondida pela DT-013 (26/10/2026):** o médico vê as clínicas do cliente em que atende; os demais, só a clínica do login (RN-MSG-025). Falta decidir o envio entre clínicas (P-MSG-29) |
| P-MSG-28 | Formato do horário relativo da Central ("Há 15 min") e a leitura de E-MSG-014 | **Resolvida** (D-MSG-028): regra definida; a leitura de E-MSG-014 foi mantida |
| P-MSG-29 | Envio entre clínicas: o destinatário precisa ter acesso à clínica do remetente? | **Resolvida** (D-MSG-024): sim |
| P-MSG-30 | Alerta cuja anomalia se agrava depois de enviado | **Resolvida** (D-MSG-033): o módulo de origem abre nova conversa, com o novo grau, e descarta a anterior |
| P-MSG-31 | Vocabulário repetido "Crítica" × "Crítico" | **Resolvida** (D-MSG-039): o grau deixou de ter o nome "Crítica". Resta a coincidência de "Urgente" com o rótulo do campo "Grau de urgência", tratada em E-MSG-022 |
| P-MSG-32 | Cadastro do grau em `IpTerminologia.Indicadores` | **Resolvida em parte** (D-MSG-034): o domínio é `GrauUrgencia`. Falta a chave de `TermoTraducao` e conferir o cadastro real |
| P-MSG-33 | **Resolvida** (D-MSG-035 a 037). Processo (D-MSG-031): (a) o tipo "Paciente (prontuário)" e o campo "Paciente" (referência com nome no cartão) se sobrepõem? Escolher o processo de paciente também define o chip do paciente? (b) como o usuário escolhe o objeto de cada tipo (uma prescrição, um documento) sem depender do paciente; (c) manter o tipo "Agenda" (consulta), vindo do documento original, ao lado de Paciente, Prescrição e Documento? | Resolvida: (a) fica só "Paciente", link para o prontuário; (b) escolha em três etapas; (c) Agenda sai, entra Registro clínico |
| P-MSG-34 | Itens de Documento e de Registro clínico: ordem pela data do evento (D-MSG-044), podendo mudar; campos de busca e exibição definidos pelo solicitante (D-MSG-050). Com as chaves de D-MSG-085, resta: o nome e a data do documento (definição provisória, 04 4.4.1) e as categorias, que o solicitante definirá no input de documentos (a DDL já tem `PEPDocumento.IdCategoria`, obrigatório) | **Resolvida em parte (D-MSG-067, 085):** Registro clínico por modelo de formulário; Documento por modelo de documento (lista a definir); sem paginação. Em aberto: só o nome e a data do documento, para quando o módulo de documentos for trabalhado |
| P-MSG-35 | **Resolvida** (D-MSG-041 a 043). Domínio do grau: nome `GrauUrgencia` mantido, chaves do HL7; sem conversão do legado; Rotina aparece como chip | Resolvida |
| P-MSG-36 | **Resolvida** (D-MSG-047): botão "Resolvido" retirado do cartão. Se a limpeza da fila mostrar fricção real nos testes de uso, reavaliar um menu com as ações | Resolvida |
| P-MSG-37 | **Resolvida** (D-MSG-046): chaves do grau em minúsculas, como no HL7 | Resolvida |
| P-MSG-38 | **Resolvida** (D-MSG-051, 052): origem do registro clínico; documento provisório; caminho do profissional direto para `Usuario` (L-11); tratamento antes do apelido; busca por data em "dd/mm" e "dd/mm/aaaa" | Resolvida |
| P-MSG-39 | **Central do Médico:** o painel de Mensagens da Central v6.0 ainda usa o assunto como primeira linha e o chip do paciente. Para ficar igual à Mensageria (D-MSG-053, 055: hierarquia, cartão e link único; v1.18: sem ícone de tipo, autor em peso médio, não lida só pela borda, urgência em contorno e prazo com relógio e dica, D-MSG-056 a 058) é preciso uma nova versão da Central (v6.1), **só depois de fechar a Mensageria** (decisão do solicitante, 05/11/2026) | **Verbos adotados (D-MSG-080).** O restante aguarda o fechamento |
| P-MSG-40 | **Resolvida** (D-MSG-055): processo sempre no cartão; "Você (Equipe)"; link do registro clínico "data - modelo"; links na Central depois do fechamento da Mensageria | Resolvida |
| P-MSG-41 | **Design System:** seção 13 com os chips de urgência só com contorno (D-MSG-057) e padrão de prazo em texto com dica (D-MSG-058) | **Resolvida (D-MSG-081)**, em 12/11/2026 |
| P-MSG-42 | **Rótulo do prazo:** "Prazo para resolução" no formulário, "Responder até" na dica | **Resolvida (D-MSG-064):** a dica passa a "Resolver até {dt}" |
| P-MSG-43 | **Formato dos campos nativos:** o horário em 12 h no navegador em inglês | **Resolvida (D-MSG-064):** horário em 24 h, em componente que força 24 h. A data continua nativa (formato do navegador) |
| P-MSG-44 | **Prazo só com a data** | **Resolvida (D-MSG-066):** vale até 23:59 e só a data é exibida. Resta só a [PROPOSTA] de tratar 23:59:00 como "sem horário" em vez de criar `PrazoComHorario` |
| P-MSG-45 | **Aviso de paciente errado (D-MSG-072):** motivo opcional na confirmação de descartar | **Deixada como está (D-MSG-073):** rever em produção |
| P-MSG-46 | **Botões Resolver e Descartar no cabeçalho do modal e verbos** | **Resolvida (D-MSG-076).** Resta a Central v6.1 adotar os verbos (P-MSG-39) |
| P-MSG-47 | **Filtros e paginação das listas.** Proposta do solicitante (12/11/2026) e análise do Designer | **Resolvida (D-MSG-086 e 089).** Nada em aberto |
| P-MSG-48 | **Item de Agenda no processo:** o que buscar e o que exibir | **Resolvida (D-MSG-090):** busca pela data; exibe data, hora e tipo. Resta só a origem do tipo (classificação da agenda), que é [PROPOSTA] do Designer |
| P-MSG-49 | **Design System:** componente "filtro rápido" | **Resolvida (D-MSG-091):** seção 15 do Design System |
| P-MSG-50 | **Campo com rótulo flutuante: o que o solicitante não descreveu.** Escolhas do Designer no protótipo v1.33, a confirmar: (1) asterisco nos obrigatórios junto com "(opcional)" nos demais; (2) rótulo da data sempre na borda; (3) fundo branco no estado de erro; (4) seleção com "Nenhum" escondido sem foco e `chevron-down`; (5) campo desabilitado com rótulo a 60 %; (6) contraste da borda do estado inicial (`neutral-light` sobre `neutral-lighter`, 1,4:1, abaixo de 3:1 de WCAG 1.4.11); (7) aplicar o padrão também à busca e ao período das listas e à caixa de resposta da conversa, que seguem como estavam | Em aberto, aguarda o solicitante |

## 4. Impacto na Central do Médico (Especificação v5.18, seção 2.5)

A Central do Médico está na v5.20 (Registro v1.19). Desde a v5.19 (D-CM-088 e D-CM-089) ela tem o grau, a ordem, o horário relativo e o card sem botão "Resolvido"; o texto abaixo é o da v1.3, a situação está na última coluna. A v5.18 (D-CM-087, 28/10/2026) já adotou o que a Mensageria decidiu até a v1.2 (assunto no cartão, "autor: texto", retirada do selo "Respondida", `check`/`check-check`, ordem, `responded`); o botão "Resolvido" com contorno entrou na v5.17 (D-CM-085). O que a v1.3 acrescenta está pendente de versão da Central (D-MSG-025 a 028):

| Ponto | Central v5.18 | Mensageria v1.3 | Situação na Central |
| --- | --- | --- | --- |
| Ordem do cartão | Não lidas antes das lidas; dentro de cada grupo, o maior entre a última mensagem e o prazo (RN-MSG-002 da v1.2) | Igual, com o grau de urgência antes da data dentro de cada camada (RN-MSG-002, D-MSG-026) | Feito na v5.19 (D-CM-088) |
| Grau de urgência | Não tem | Chip só com o nome (Rotina, Urgente, Quanto antes, Imediato) no cartão e campo `urgencyLevel: { key, name }` na API (RN-MSG-034, D-MSG-025, D-MSG-039); chips da seção 13 do Design System (D-MSG-027) | Feito na v5.19 (D-CM-088) |
| Horário | Relativo ("Há 15 min · Sandra"), sem regra definida | Relativo, pela mesma regra (D-MSG-028, D-MSG-032) | Feito na v5.19 (D-CM-088): a regra de D-MSG-028 (mesmo dia e menos de 1 h: "Há x min"; mesmo dia: "Há x h"; outro dia: data e hora). As duas telas seguem a mesma regra |
| Assunto no cartão, aviso de lida, selo "Respondida" retirado, `responded` | Feitos na v5.18 (D-CM-087) | Iguais | Feito |
| Borda de não lida, linha da clínica, tipo `Response` | Iguais | Iguais | Nenhum |
| Botão "Resolvido" no cartão | Secundário com contorno (v5.17, D-CM-085) | Retirado do cartão (D-MSG-047); fica só dentro da conversa | Feito na v5.19 (D-CM-089) |

As mudanças estão descritas no guia para desenvolvedores (`Para Desenvolvedores/Central do Médico - mudanças da v5 - guia para desenvolvimento.md`, seção 4.15). Os cenários CT-MSG-01 a 25 da Central continuam valendo para o painel atual até essa versão; os da Mensageria usam CT-MSG-101 em diante.

---

## Histórico de Versões

- **v1.0** (22/10/2026) — Criação do Registro de Decisões da Mensageria, a pedido do solicitante, reunindo as decisões de 21 e 22/10/2026 e as questões abertas P-MSG-01 a P-MSG-23 (as seis primeiras vêm do documento de regras de 22/10/2026). Resolvidas nesta data: P-MSG-02 (sim), P-MSG-03 (cores aprovadas) e P-MSG-05 (SBIS verificado). Mantidas em aberto por decisão do solicitante: P-MSG-01 e P-MSG-04. P-MSG-16 a 23 e E-MSG-011 vieram da revisão do crítico de negócio.
- **v1.0, revisão por Dois Críticos** (22/10/2026) — Acrescentados P-MSG-24 a 27 vindos do crítico técnico (idioma × SBIS, idempotência, fila de eventos, risco da ordenação).
- **v1.1** (27/10/2026) — Respostas do solicitante a P-MSG-01, 09, 24 e 25 (D-MSG-019 a 022; E-MSG-012 a 014); P-MSG-23 respondida pela DT-013; novas P-MSG-28 e 29; seção 4 reescrita com a Central v5.15. P-MSG-13 (selo de estado) segue em aberto à espera da decisão depois da comparação visual enviada em 27/10/2026.
- **v1.2** (27/10/2026) — P-MSG-13 e P-MSG-29 resolvidas (D-MSG-023 e 024); E-MSG-015; tabela da seção 4 com assunto no cartão, aviso de lida e a retirada do selo.
- **v1.3** (28/10/2026) — Grau de urgência: D-MSG-025 a 027 (requisito, ordem, cores); P-MSG-28 resolvida (D-MSG-028); E-MSG-016 a 018; novas P-MSG-30 a 32; P-MSG-27 tratada em parte; seção 4 com a regra do horário relativo da Central e o grau de urgência.
- **v1.4** (28/10/2026) — Respostas do solicitante ao v1.3: D-MSG-029 a 034 (sete escolhas do Designer confirmadas; limite de 2000 caracteres; processo de um só tipo; horário relativo também na Mensageria; alerta que se agrava; domínio `GrauUrgencia`); E-MSG-002, 004 e 014 substituídas; E-MSG-019 nova; P-MSG-30 resolvida, P-MSG-31 em espera, P-MSG-32 resolvida em parte, P-MSG-33 nova; seção 4 com o horário igual nas duas telas.
- **v1.5** (28/10/2026) — Respostas do solicitante ao P-MSG-33: D-MSG-035 (só "Paciente", link para o prontuário), D-MSG-036 (escolha em três etapas), D-MSG-037 (Agenda sai, Registro clínico entra); E-MSG-020 nova; P-MSG-33 resolvida, P-MSG-34 nova. A D-MSG-031 fica parcialmente revista: o processo volta a exigir paciente, por decisão do solicitante (D-MSG-036).
- **v1.6** (28/10/2026) — Respostas do solicitante: D-MSG-038 (busca com autocomplete em destinatário, paciente e item do processo), D-MSG-039 (grau no domínio HL7), D-MSG-040 (ordem do formulário); E-MSG-021 e 022 novas; P-MSG-31 resolvida; P-MSG-35 nova.
- **v1.7** (29/10/2026) — Respostas do solicitante: D-MSG-041 a 045 (domínio e chaves, sem conversão, Rotina como chip, ordem dos itens, aparência do cartão); P-MSG-35 resolvida; P-MSG-34 em parte; novas P-MSG-36 (botão "Resolvido") e P-MSG-37 (maiúsculas das chaves).
- **v1.9** (29/10/2026) — Respostas do solicitante: D-MSG-048 (nomes técnicos `urgencyLevel` e `timeIndicator`). Seção 4 atualizada: a Central v5.19 já tem o grau, a ordem, o horário relativo e o card sem botão "Resolvido".
- **v1.8** (29/10/2026) — Respostas do solicitante: D-MSG-046 (chaves do grau em minúsculas) e D-MSG-047 (botão "Resolvido" retirado do cartão); P-MSG-36 e P-MSG-37 resolvidas; Central pendente também do botão.
- **v1.10** (29/10/2026) — Resposta do solicitante: D-MSG-049 (painel sem limite de 4 cartões, com rolagem própria).
- **v1.11** (29/10/2026) — Resposta do solicitante: D-MSG-050 (campos de busca e exibição do item do processo); P-MSG-34 ajustada; nova P-MSG-38 (origem de registro clínico e data do documento).
- **v1.12** (30/10/2026) — Resposta do solicitante: D-MSG-051 (origem do registro clínico; documento provisório); P-MSG-38 resolvida em parte.
- **v1.13** (30/10/2026) — Respostas do solicitante: D-MSG-052; P-MSG-38 resolvida; lacuna L-11 aberta no Mapeamento.
- **v1.14** (30/10/2026) — Correção do Designer em D-MSG-052: a coluna se chama `SegurancaUsuarioId`, como o solicitante escreveu; a divergência vinha da Biblioteca de Schema (DDL) desatualizada. L-11 retirada.
- **v1.15** (05/11/2026) — Resposta do solicitante: D-MSG-053 (novo visual do cartão); nova P-MSG-39 (Central).
- **v1.16** (05/11/2026) — Resposta do solicitante: D-MSG-054 (links de paciente e processo; equipe junto ao autor); nova P-MSG-40.
- **v1.17** (05/11/2026) — Resposta do solicitante: D-MSG-055 (um só link por cartão); P-MSG-40 resolvida; P-MSG-39 aguarda o fechamento da Mensageria.
- **v1.18** (10/11/2026) — Respostas do solicitante: D-MSG-056 (sem ícone de tipo, pesos), D-MSG-057 (urgência em contorno), D-MSG-058 (prazo, "Vencida", dica e balão no toque); nova P-MSG-41 (Design System); P-MSG-39 ampliada.
- **v1.19** (11/11/2026) — Respostas do solicitante: D-MSG-059 (dica como a de 1ª Consulta), D-MSG-060 (destinatário com linha mais rica; coluna lateral não entra), D-MSG-061 (prazo em data e horário; rótulo "Prazo para resolução"), D-MSG-062 (limite de 2000, paciente em autocomplete, sem bloco de contexto); nova E-MSG-023; P-MSG-04 resolvida em parte; novas P-MSG-42 e P-MSG-43.
- **v1.20** (11/11/2026) — Respostas do solicitante: D-MSG-063 ("Inclui {nome}" adotado; E-MSG-023 decidida), D-MSG-064 (data obrigatória, horário opcional em 24 h, "Resolver até"), D-MSG-065 (grau de urgência do tamanho do chip); P-MSG-04, 42 e 43 resolvidas; nova P-MSG-44 (prazo só com a data).
- **v1.21** (11/11/2026) — D-MSG-066 (prazo sem horário mostra só a data; vale até 23:59); P-MSG-44 resolvida.
- **v1.22** (11/11/2026) — Respostas do solicitante: D-MSG-067 (categorias dos itens, sem paginação), D-MSG-068 (busca de paciente como a do cabeçalho), D-MSG-069 (alerta para destinatário que não pode receber vai ao log de sistema), D-MSG-070 (P-MSG-12; já confirmada na D-MSG-029); P-MSG-12 e 19 resolvidas, P-MSG-17 e 34 em parte.
- **v1.23** (11/11/2026) — Respostas do solicitante: D-MSG-069 confirmada; D-MSG-071 (busca de paciente completa, como a do cabeçalho; corrige a D-MSG-068); D-MSG-072 (paciente errado: descartar e enviar outra); P-MSG-17 resolvida; nova P-MSG-45 (motivo do descarte).
- **v1.24** (11/11/2026) — D-MSG-073 (P-MSG-45 deixada como está); E-MSG-021 anotada: o campo Paciente segue a busca do cabeçalho.
- **v1.25** (11/11/2026) — D-MSG-074 (tela de nova mensagem fechada: E-MSG-020 e 021, data mínima, área de toque e prazo sem horário confirmados); P-MSG-07, 34 e 41 aguardam.
- **v1.26** (11/11/2026) — D-MSG-075 (tela Conversa eliminada; só o modal, também na lista; estrutura confirmada pelo solicitante); nova E-MSG-024 ([PROPOSTA]: endereço, Voltar do navegador, foco, altura total, cabeçalho fixo); nova P-MSG-46 (botões no cabeçalho e verbos, aguardando decisão).
- **v1.27** (11/11/2026) — D-MSG-076 (Resolver e Descartar no cabeçalho do modal, em linha própria e com contorno, nos verbos); P-MSG-46 resolvida.
- **v1.28** (11/11/2026) — D-MSG-077 (posição de Resolver e Descartar ao lado de De e Para; Responder alinhado ao campo).
- **v1.29** (11/11/2026) — D-MSG-078 (botões lado a lado conforme a largura; E-MSG-016 e 017 reafirmadas; itens do protótipo em aberto fechados).
- **v1.30** (12/11/2026) — D-MSG-079 (sino do cabeçalho adiado; P-MSG-06 adiada até produção).
- **v1.31** (12/11/2026) — D-MSG-080 a 084 (verbos na Central; Design System atualizado; quem sai da equipe; recepção com Central; vencida antes das demais); P-MSG-20, 22, 27 e 41 resolvidas, P-MSG-39 em parte; nova P-MSG-47 (filtros e paginação das listas).
- **v1.32** (12/11/2026) — D-MSG-085 a 088 (tipos e chaves do processo, com Agenda; filtros, busca e paginação das listas; retenção e acesso; confirmações de ordem e de quem envia); P-MSG-07, 20, 21, 27 e 47 resolvidas, P-MSG-34 reduzida; novas P-MSG-48 (item de Agenda) e P-MSG-49 (filtro rápido no Design System).
- **v1.33** (12/11/2026) — D-MSG-089 a 092 (período "Tudo" e "Personalizado"; item de Agenda com tipo; filtro rápido no Design System; campos com rótulo flutuante como padrão); P-MSG-47, 48 e 49 resolvidas; nova P-MSG-50 (detalhes do padrão de campo que o solicitante não descreveu).