Mensageria — Registro de Decisões (v1.17)
Documentos desta funcionalidade: 01 - Definição (v1.17) · 02 - Especificação (v1.17) · 03 - Protótipo (v1.17, código em 03 - Protótipo v1.17.html) · 04 - Mapeamento de Banco de Dados (v1.17) · Cenários de Teste (v1.17) · 05 - Registro de Decisões (v1.17)
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. | 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. | 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. | 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 |
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 | 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 | Comportamento da busca com autocomplete: 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 |
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) | Em aberto: o solicitante ainda não decidiu se usará algum, pela complexidade de o usuário informar só a data ou data e hora |
| 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) | Em aberto, não tratado |
| 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 | Proposta E-MSG-010; confirmar |
| 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: a associação não pode ser alterada (RN-MSG-020). Corrigir com registro, ou encerrar e abrir outra? Que dado desambigua no cartão (data de nascimento, prontuário)? Busca de paciente por nome ou CPF (o anexo previa) | Em aberto |
| 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 | Em aberto; a Especificação recusa o envio a destinatário que não pode receber (EX-MSG-07), falta decidir o caso de alerta |
| 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: quais categorias entram; a ordem é pela data do evento (D-MSG-044), podendo mudar; falta decidir se a lista precisa de paginação. Os campos de busca e exibição foram definidos pelo solicitante (D-MSG-050) | Em aberto em parte |
| 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) | 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 |
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.