Mensageria — Registro de Decisões (v1.30)
Documentos desta funcionalidade: 01 - Definição (v1.30) · 02 - Especificação (v1.30) · 03 - Protótipo (v1.30, código em 03 - Protótipo v1.30.html) · 04 - Mapeamento de Banco de Dados (v1.30) · Cenários de Teste (v1.30) · 05 - Registro de Decisões (v1.30)
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 |
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 NULLcomCHECK; alerta pelo PublishAlert.urgency; AppendAlertUpdatesemurgency; a imutabilidade vale porque a API não tem endpoint de alteração. Valores dos chips: Média neutral-lightereneutral-dark; Baixa contorno neutral-light; Alta error-light, error-darke contornoerror-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). |
| 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 | Em aberto; proposta em Mapeamento 4.4 e Especificação 2.8.9 |
| 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? Proposta: vê o histórico, só age enquanto for membro. O que vale para “faz parte” (momento do envio ou atual) | Em aberto |
| P-MSG-21 | Retenção das conversas, acesso de gestão ou auditor ao conteúdo, e busca por paciente ou assunto | Em aberto |
| P-MSG-22 | A recepção não tem Central; usa só a tela de Mensagens? | Em aberto |
| 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 (lembrete com prazo em meses) e a vencida afunda abaixo de mensagens novas; o vencido deixou de ser prioridade. Manter, ou dar prioridade ao vencido? | Em aberto. Parcialmente tratada: o grau de urgência passa a ordenar antes da data (D-MSG-026); a pergunta sobre priorizar o vencido continua |
| 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: a ordem é pela data do evento (D-MSG-044), podendo mudar. Os campos de busca e exibição foram definidos pelo solicitante (D-MSG-050) | Resolvida em parte (D-MSG-067): Registro clínico por modelo de formulário; Documento por modelo de documento (lista a definir com o input de documentos); sem paginação |
| 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) é preciso uma nova versão da Central (v6.1), só depois de fechar a Mensageria (decisão do solicitante, 05/11/2026) A v1.18 acrescenta: 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) | Em aberto, 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: a seção 13 (chips de urgência) ainda descreve Imediato com fundo cheio e Quanto antes com fundo claro; a Mensageria v1.18 usa só contorno (D-MSG-057). Também não há no Design System o padrão de prazo em texto com dica e balão no toque (D-MSG-058). [PROPOSTA] atualizar o Design System depois que o solicitante validar as outras telas da Mensageria | Em aberto |
| 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) |
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
urgencyLeveletimeIndicator). 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).