Central do Médico (Cockpit) — Registro de Decisões (v1.20)
Documentos desta funcionalidade: 01 - Definição (v6.0) · 02 - Especificação (v6.0) · 03 - Protótipo (v6.0, código executável em 03 - Protótipo v6.0.html) · 04 - Mapeamento de Banco de Dados (v6.0) · Cenários de Teste (v6.0) · 05 - Registro de Decisões (v1.20)
Este documento reúne, num só lugar, as decisões do solicitante que moldam a Central do Médico, as escolhas feitas pelo Designer que ainda aguardam confirmação e as questões em aberto. Ele existe para que as decisões não fiquem espalhadas pelos Históricos de Versões dos outros documentos, onde cada uma aparece misturada à descrição da mudança que ela provocou. Os Históricos continuam registrando o que mudou em cada versão e citam o código da decisão (D-CM-xxx) em vez de repetir o raciocínio.
Convenção: D-CM-xxx = decisão do solicitante (vigente); E-CM-xxx = escolha do Designer, a confirmar; P-CM-xxx = questão em aberto, aguardando o solicitante. Decisões anteriores à numeração (v1.0 a v4.48) permanecem descritas nos Históricos de cada documento, onde o contexto delas está inteiro.
1. Decisões do solicitante
| ID | Data | Decisão | Onde está aplicada |
|---|---|---|---|
| D-CM-001 | 08/10/2026 | O bloqueio de horário na agenda do médico é feito pela Recepção (RN-AGM-019, Agenda do Médico); ele não é consulta, não aparece no painel de Consultas e não entra em nenhum número do indicador “Consultas Hoje” (RN-CM-030). | Definição (RN-CM-030); Especificação 2.2/2.3; Mapeamento 4.1/4.2; Cenários CT-KPI-07, CT-CONS-10 |
| D-CM-002 | 08/10/2026 | A tag VIP vem de ProgramaApoioPaciente (cadastro do paciente), como as tags administrativas; Paciente.PacienteVip não é lido por enquanto. VIP é exceção ao MostrarEm e à vigência da tag. | Definição (RN-CM-025); Mapeamento 4.1 (tags) |
| D-CM-003 | 09/10/2026 | A 1ª Consulta deixa de ser um chip/badge de texto e passa a ser o ícone circle-number-1 (Tabler Icons), 18px, sem fundo, cor --color-first-visit, logo depois do nome do paciente, com rótulo acessível “1ª Consulta” — o mesmo da Agenda do Médico. | Definição (RN-CM-028); Especificação 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-03) |
| D-CM-004 | 09/10/2026 | A Central não diferencia “Esperando” (paciente já na clínica) de “Não chegou”: o selo “Atrasado · Nmin” é o mesmo para qualquer consulta atrasada e não iniciada. A distinção existe só na Agenda do Médico. | Especificação 2.3 (Atraso); Protótipo |
| D-CM-005 | 09/10/2026 | O painel do quadrante inferior direito passa a se chamar “Procedimentos hoje” (antes “Procedimentos na Clínica”). O indicador da barra continua “Procedimentos Hoje”. (O nome do painel foi trocado de novo em D-CM-019.) | Definição; Especificação 2.2, 2.6 e i18n; Mapeamento; Protótipo; Cenários |
| D-CM-006 | 09/10/2026 | A janela de “a revisar” (RN-CM-020) usa o parâmetro do sistema atual NumeroDiasRevisaoPrescricoes, no lugar do PrescricaoTempoRevisao que havia sido proposto. Com a linha ausente, vale o padrão de 1 dia, que é o padrão do Gemed 2.1 (o código do sistema atual assume 2; o solicitante manteve 1). A janela segue contínua (N × 24h a partir de agora) — substituído nesse ponto por D-CM-023 (dias de calendário). | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6, 4.7 e Seeds; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-007 | 09/10/2026 | A faixa de sem conexão segue o formato da Agenda do Médico e do Design System, seção 7: ícone wifi-off e “Sem conexão — dados atualizados às {hh:mm}”, role="status". | Especificação 2.7; Protótipo; Cenários (CT-SIS) |
| D-CM-008 | 09/10/2026 | ”Atrasadas”, no indicador “Consultas Hoje”, não conta as consultas já em atendimento: só as não iniciadas com horário previsto vencido. As em atendimento continuam sendo “pendentes”. | Especificação 2.2; Mapeamento 4.2 (delayed); Protótipo; Cenários (CT-KPI-01) |
| D-CM-009 | 09/10/2026 | A data que vale para a vigência do prontuário (PEP) é PEP.DataInicioUTC (e DataFimUTC); PEP.DataInicio/DataFim não são lidos. | Mapeamento 4.1 (tags, patient.diagnosis); Cenários |
| D-CM-010 | 09/10/2026 | Um diagnóstico cujo prontuário (PEP) só começa depois de hoje não é exibido no card. Só o início é avaliado. | Especificação 2.3; Mapeamento 4.1 (patient.diagnosis); Cenários (CT-CONS-13) |
| D-CM-011 | 09/10/2026 | Resolver ou descartar uma conversa vale para todos os destinatários: uma conversa endereçada a uma equipe ou a mais de uma pessoa sai do painel de todos quando qualquer um a resolve ou descarta. | Definição (RN-CM-015); Especificação 2.5; Mapeamento 4.9; Cenários (CT-MSG-17/18) |
| D-CM-012 | 09/10/2026 | Os defeitos de acessibilidade e de interface apontados na revisão da v5.0 devem ser corrigidos (contraste, teclado, modal, avisos, alvos de toque, movimento reduzido, tela de 360px, cabeçalho preso em até 1024px). | Especificação 2.8 (Acessibilidade); Protótipo; Cenários (CT-ACES) |
| D-CM-013 | 09/10/2026 | Prescrição cuja hora de aplicação já passou e que ainda não foi assinada (ou revisada) continua na lista, com o chip vermelho, como antes de passar a hora; continua contando em “Urgentes” até ser assinada ou revisada. (Resolve P-CM-001.) | Definição (RN-CM-011, RN-CM-020); Especificação 2.4; Mapeamento 4.6/4.7 (hoursRemaining); Protótipo; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-014 | 09/10/2026 | Resolver ou descartar uma conversa não tem “desfazer”: a conversa é uma ferramenta de comunicação e facilitação de tarefas, não um processo auditado. Não há texto de auditoria nas telas nem na especificação. (Resolve a parte de desfazer de P-CM-010.) | Definição (RN-CM-015); Especificação 2.5 |
| D-CM-015 | 09/10/2026 | O progresso do procedimento usa o tempo de aplicação da prescrição, Prescricao.TempoAplicacao (em minutos), e não Agenda.Tempo. (Resolve P-CM-013.) | Definição (RN-CM-016); Especificação 2.6; Mapeamento 4.3 (progress); Protótipo; Cenários (CT-PROC) |
| D-CM-016 | 09/10/2026 | O ícone de 1ª Consulta abre uma dica ao ser tocado, porque o title nativo não aparece em tela de toque. (Resolve P-CM-014.) | Definição (RN-CM-028); Especificação 2.3 e 2.8; Protótipo |
| D-CM-017 | 10/10/2026 | Consulta em atendimento além da duração prevista da agenda (Agenda.Tempo): o card mostra o tempo decorrido em destaque (“há 1h20”), com ícone e cor de atenção, para incomodar o olhar — é provavelmente uma anomalia (atendimento não fechado, ou iniciado sem querer). Sem tolerância. (Escolhida a proposta principal de P-CM-011.) | Definição (RN-CM-031); Especificação 2.3 e 2.9; Mapeamento 4.1 (elapsedMinutes, overtime); Protótipo; Cenários (CT-CONS-17) |
| D-CM-018 | 10/10/2026 | O subtexto do indicador “Consultas Hoje” passa a “X pendentes (Y atrasadas)” — as atrasadas já estão contadas nas pendentes. (Escolhida a opção (a) de P-CM-012.) | Especificação 2.2 e i18n; Protótipo; Cenários (CT-KPI-01) |
| D-CM-019 | 10/10/2026 | O painel do quadrante inferior direito passa a se chamar “Pacientes em procedimento” (en-US “Patients in procedure”, es-419 “Pacientes en procedimiento”); o indicador da barra continua “Procedimentos Hoje”. Substitui o nome de D-CM-005. | Definição; Especificação 2.2, 2.6 e i18n; Mapeamento; Protótipo; Cenários |
| D-CM-020 | 10/10/2026 | O progresso do procedimento conta o tempo desde Agenda.DhAtendimentoIniUTC, sobre Prescricao.TempoAplicacao. (Confirma o que já estava; resolve P-CM-017.) | Especificação 2.6; Mapeamento 4.3 (progress) |
| D-CM-021 | 10/10/2026 | A vigência de tag (da própria tag e da atribuição ao paciente, no cadastro e no prontuário) é comparada só pela data, no fuso da clínica, sem a hora: início e fim são inclusivos. Decisão já tomada em outra conversa do projeto e confirmada aqui. Substitui a escolha E-CM-014. | Definição (RN-CM-025); Mapeamento 4.1 (tags, Domínios); Cenários (CT-CONS-11, 16) |
| D-CM-022 | 10/10/2026 | Ordem dos chips no card: primeiro o ícone de 1ª Consulta (junto ao nome), depois as tags assistenciais (ProgramaApoio.Finalidade = 'A'), depois as administrativas ('D', como VIP); dentro de cada grupo, ordem alfabética pela sigla. (Resolve P-CM-021.) | Definição (RN-CM-025); Especificação 2.3 e 2.9; Mapeamento 4.1 (tags); Protótipo; Cenários (CT-CONS-15) |
| D-CM-023 | 10/10/2026 | A janela de “a revisar” é em dias de calendário no fuso da clínica, não em 24 horas: com N dias e hoje o dia 10, entram as aplicações dos dias 10 a 10+N (N = 1: dias 10 e 11, até 23:59), mais as já vencidas. Substitui a escolha E-CM-005 (janela contínua). | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6 e 4.7; Protótipo; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-024 | 10/10/2026 | Uma prescrição vencida sem desfecho fica na lista e em “Urgentes” até ser assinada ou revisada; na prática ela será cancelada, reprogramada ou aplicada, e não fica nesse estado para sempre. Não há limite para trás nem ação de dispensar. (Resolve P-CM-020.) | Definição (RN-CM-011, RN-CM-020) |
| D-CM-025 | 10/10/2026 | Prescrições sem IdAgenda ficam fora das listas e das contagens. (Resolve P-CM-027.) | Mapeamento 4.6 e 4.7 |
| D-CM-026 | 10/10/2026 | Confirmadas as escolhas do Designer E-CM-010 (rótulo “p/assinar” montado no front), E-CM-012 (sem tempo de aplicação, sem barra), E-CM-013 (comportamento da dica da 1ª Consulta) e E-CM-015 (hoursRemaining truncado, classificação por minutos). | Especificação 2.2, 2.3, 2.6 e 2.9; Mapeamento 4.6 |
| D-CM-027 | 13/10/2026 | Confirmadas as escolhas do Designer: E-CM-001 (faixa de sem conexão com o horário da atualização bem-sucedida mais antiga entre os painéis que falham; presa junto ao cabeçalho até 1024px), E-CM-002 (token --color-on-primary, texto escuro sobre o verde primário nos dois temas — incorporado ao Design System em 14/10/2026, D-CM-043; guia para o desenvolvedor em Para Desenvolvedores/), E-CM-006 (traduções en-US e es-419 do painel, de “há {t}” e “atrasada”, da dica da 1ª Consulta e do status Completo), E-CM-007 (só o ponto do selo “Atrasado” pulsa), E-CM-008 (barra de progresso do procedimento em neutral-dark, error-dark acima de 100%), E-CM-009 (bordas laterais de Recepcionado e Aguardando ficam como estão), E-CM-016 (“atrasada” no feminino; o formato do texto mudou em D-CM-041) e E-CM-017 (destaque da consulta além do previsto com os tokens do chip “Atenção”, ícone clock-alert, minutos com dois dígitos). Seguem a confirmar E-CM-003 e E-CM-004. | Especificação 2.3, 2.4, 2.6, 2.7, 2.8; Protótipo; Guia do Design System |
| D-CM-028 | 13/10/2026 | No escopo “Meus”, a prescrição de um colega ausente fica fora da lista e do indicador do médico logado — aceito. O toggle “Todos” existe para a colaboração: os médicos resolvem as pendências mesmo com o responsável ocupado. (Resposta “sim” à questão P-CM-002.) | Definição (RN-CM-020); Especificação 2.4 |
| D-CM-029 | 13/10/2026 | O contrato de Procedimentos passa a trazer firstTime (booleano, Agenda.PrimeiraConsulta = 'S'), como a agenda de consultas; o card de procedimento mostra o ícone de 1ª Consulta (RN-CM-028). | Mapeamento 4.3; Especificação 2.6 e 2.9; Protótipo; Cenários (CT-PROC) |
| D-CM-030 | 13/10/2026 | [O valor de contrato completed do status Completo foi substituído por D-CM-074: administered.] Status de procedimento: ProcedureStatus() é avaliada em ordem e vale a primeira condição que se aplica — Cancelado, Finalizado (alta: DhAtendimentoFimUTC preenchido), Completo (infusão terminada: DhInfusaoFimUTC preenchido, sem alta), Em administração (DhInfusaoIniUTC preenchido, sem fim de infusão), Preparo, Recepcionado, Aguardando recepção e Agendado. Com DhInfusaoFimUTC preenchido o procedimento nunca é “Em administração”; com alta registrada é sempre “Finalizado”, mesmo com o fim da infusão vazio (23 linhas da massa). Valores de contrato: completed (Completo) e finished (Finalizado). (Resolve P-CM-006 e parte de P-CM-033.) | Mapeamento 4.3 e 4.4; Especificação 2.6 e 2.9; Cenários (CT-PROC) |
| D-CM-031 | 13/10/2026 | Haverá um item no Menu Lateral que abre diretamente a tela exclusiva de Pacientes em procedimento (tela ainda não definida); o painel da Central continua sendo o resumo. (Resolve P-CM-009; o nome do item fica em P-CM-036.) | Menu Lateral (outra funcionalidade) |
| D-CM-032 | 13/10/2026 | Resolver e descartar uma conversa passam a pedir confirmação, que informa que a ação vale para todos os destinatários. (Resolve P-CM-010; os textos são escolha do Designer, E-CM-021.) | Definição (RN-CM-015); Especificação 2.5 e i18n; Protótipo; Cenários (CT-MSG) |
| D-CM-033 | 13/10/2026 | Fica como está o texto “p/assinar (próx. 7 dias)”, cujo número inclui as prescrições já vencidas. Prescrição de agenda já passada e ainda não assinada não deveria existir: indica falha grave de processo (agenda de paciente que não veio e foi esquecida). A correção é da Recepção, cancelando a agenda ou marcando falta; a Central só deixa o problema visível (D-CM-024). (Resolve P-CM-023.) | Definição (RN-CM-020) |
| D-CM-034 | 13/10/2026 | Procedimento “Em administração” cuja prescrição não tem tempo de aplicação mostra, no lugar da barra, o texto discreto “sem tempo previsto”. (Resolve P-CM-024.) | Especificação 2.6 e i18n; Protótipo; Cenários (CT-PROC) |
| D-CM-035 | 13/10/2026 | É aceitável que o ícone da 1ª Consulta não receba o foco do teclado: o leitor de tela lê “1ª Consulta” no nome do card e, com o uso, o médico associa o símbolo. Não há dica ao foco. (Resolve P-CM-025.) | Especificação 2.8 |
| D-CM-036 | 13/10/2026 | Conformidade SBIS, itens de P-CM-026: (b) o requisito de idioma (ECF.17.18) pede português do Brasil, que é o idioma a apresentar na certificação; en-US e es-419 ficam na especificação, fora da avaliação; (c) a busca da Central não usa número de prontuário; existe um artifício na busca, a chave “id:” (busca pelo prontuário), que será mostrado na certificação mas não entra na busca normal por enquanto — o escopo da busca fica como está (resolve P-CM-032); (d) o toggle “Meus” satisfaz ECF.16.01(c) e o “Todos” permite a colaboração entre médicos. Os itens (a) e (e) seguem em P-CM-026. | Especificação 2.10 |
| D-CM-037 | 13/10/2026 | As duas janelas de prescrição — “a assinar” (PrescricaoTempoAssinatura, padrão 7 dias) e “a revisar” (NumeroDiasRevisaoPrescricoes, padrão 1 dia) — são em dias de calendário no fuso da clínica: “N dias” é o dia de hoje e os N dias seguintes, até 23:59. (Resolve P-CM-028; estende D-CM-023.) | Definição (RN-CM-020); Especificação 2.2 e 2.4; Mapeamento 4.6 e 4.7; Cenários; Decisões Transversais (DT-005) |
| D-CM-038 | 13/10/2026 | Sem mudança: o total do indicador “Procedimentos Hoje” inclui os procedimentos finalizados; o subtexto é um auxiliar telegráfico de pendências e não precisa fechar a conta. A Especificação passa a dizer isso. (Resolve P-CM-029.) | Especificação 2.2; Cenários (CT-KPI-03) |
| D-CM-039 | 13/10/2026 | Uma prescrição cuja administração já começou sai da lista “a revisar”, porque revisar já não faz sentido. Prescrição que chega ao procedimento sem assinatura é falta grave de processo da clínica: a expectativa é que o fluxo da enfermagem bloqueie o início do procedimento, de modo que a Central não trata esse caso como normal. (Resolve P-CM-030; a forma de aplicar está em E-CM-018.) | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários (CT-PRES) |
| D-CM-040 | 13/10/2026 | A assinatura do médico feita dentro da janela de revisão dispensa a revisão: a prescrição assinada nesse período não aparece em “a revisar”. Exemplo do solicitante: assinada no dia anterior à aplicação, com janela de 1 dia. A regra não estava especificada; antes, só “Marcar como Revisada” encerrava a revisão, e a assinatura recente não bastava. A definição exata está em E-CM-019. (Comentário do solicitante em P-CM-030; resolve a divergência de P-CM-003, a confirmar.) | Definição (RN-CM-020); Especificação 2.4; Mapeamento 4.6 e 4.7; Cenários (CT-KPI-04, CT-PRES) |
| D-CM-041 | 13/10/2026 | Texto do atraso da prescrição: abaixo de 1 hora só minutos (“40min atrasada”); de 1 hora a 47h59 horas e minutos (“1h59 atrasada”); a partir de 48 horas, dias (“30 dias atrasada”). Altera E-CM-016. (Resolve P-CM-031.) | Especificação 2.4 e i18n; Protótipo; Cenários (CT-PRES-11) |
| D-CM-042 | 13/10/2026 | Contrato: (1) o tipo de mensagem devolvido é um só, Response; (2) a origem da mensagem é System ou User; (3) o horário dos procedimentos (startTime) é hora no fuso da clínica (“HH:mm”), como na Agenda; (4) o status “Completo” é completed (D-CM-030). [Item (4) substituído por D-CM-074: administered.] (Resolve P-CM-033.) | Especificação 2.9; Mapeamento 4.3, 4.7 e 4.8 |
| D-CM-043 | 14/10/2026 | A Central segue o Design System de 14/10/2026: --color-on-primary (D-CM-027) foi incorporado ao Design System (seção 4a) e vale para todo texto ou ícone sobre --color-primary-pure; os novos -dark do tema claro (regra C8) e o --color-neutral-pure claro #526A90 entram no bloco de tokens. Nenhum uso de token muda na Central. | Protótipo (bloco de tokens); Especificação 2.8 |
| D-CM-044 | 21/10/2026 | Idioma e tradução seguem as decisões transversais DT-011 e DT-012: (1) todo texto exibido segue o idioma da clínica atual (ClienteEmpresa.IdiomaOficial), inclusive as mensagens do sistema, que a Especificação dizia traduzir “para o idioma do usuário”; (2) termo de TermoTraducao sem tradução no idioma da clínica: vai a própria chave (Termo) e o back-end registra anomalia (Termo, Origem, Idioma), sem queda para pt-BR. Autorização do solicitante: “pode ajustar toda documentação” (21/10/2026). | Especificação (mensagens do sistema; 2.10, ECF.17.18); Mapeamento (blocos “Internacionalização”); Protótipo (?lang) |
| D-CM-045 | 21/10/2026 | (1) Conversa não lida: ícone e borda lateral esquerda em color-secondary-dark (como no protótipo), no lugar de primary-pure/secondary-pure, que ficavam abaixo de 3:1. (2) Percentual da barra de progresso de procedimento em font-size-xs (10px), como no protótipo, no lugar de 9px, que não existe no Design System. | Especificação 2.5, 2.6 e 2.8 |
| D-CM-046 | 26/10/2026 | Pedido do solicitante ao rever E-CM-003 e E-CM-004: (1) O anel de foco do teclado tem 2px em vez de 3px: o solicitante pediu uma altura menor (“2px talvez”) e, vendo o resultado com 2px, disse que estava ótimo. Resolve E-CM-003. A cor neutral-dark, o afastamento de 2px, o campo de texto sem anel e o valer como padrão de todas as telas são proposta do Designer (E-CM-024). (2) Chips de urgência leves, alternativa A, escolhida pelo solicitante: Crítico em fundo color-error-light e Atenção em fundo color-highlight-light, sem contorno, texto e ícone na cor -dark da família (ícones triangle-alert e clock), peso font-weight-medium. Resolve E-CM-004 nos chips (o peso font-weight-medium era escolha do Designer, E-CM-025, revista em D-CM-056: peso regular). Motivo dado por ele: o chip é um alerta e não deve pesar no card; quem protagoniza são as informações do paciente e da prescrição. (3) O solicitante pediu que a borda azul de campo alterado, usada na tela de registros clínicos (cor medida em #467EE5, 2px), seja um token do Design System: --color-field-changed (seções 4a e 11). | Especificação 2.3, 2.4 e 2.8; Protótipo; Cenários (CT-ACES-06 e 07); Design System 4a e 11; guias do tema e de desenvolvimento |
| D-CM-047 | 26/10/2026 | Desempate das prescrições pelo nome do paciente: a lista é ordenada pelo tempo restante, do menor para o maior (as vencidas primeiro) e, com o mesmo tempo restante, pelo nome do paciente em ordem alfabética. Substitui E-CM-022, que desempatava pelo identificador da prescrição. Resposta do solicitante: “E-CM-022: desempate pelo nome do paciente”. O critério para o mesmo nome é E-CM-027. | Definição (RN-CM-011); Especificação 2.4 e 2.9; Mapeamento 4.7; Protótipo; Cenários (CT-PRES-18) |
| D-CM-048 | 26/10/2026 | Confirmada a escolha E-CM-023: --color-field-changed (#467EE5) tem o mesmo valor nos dois temas. Resposta: “E-CM-023: ok”. | Design System 4a e 11 (sem mudança) |
| D-CM-049 | 26/10/2026 | Na precedência entre os estados de um campo, “com erro” vem antes de “selecionado”. Resposta: “E-cm-024: com erro precede selecionado”. O restante de E-CM-024 segue a confirmar, inclusive a ordem dos estados abaixo de “erro”. | Design System 11 (sem mudança de texto) |
| D-CM-050 | 26/10/2026 | [O escopo “todas as clínicas do cliente” deste item foi substituído por D-CM-066: só as clínicas em que o médico atende.] Resposta a P-CM-008. (1) Editar uma prescrição gera uma nova versão, que precisa ser assinada de novo; a versão anterior fica cancelada e a nova nasce sem assinaturas (D-CM-052). Para a Central, a nova versão é uma prescrição nunca assinada e volta para “a assinar”. (2) A Central mostra as consultas e as prescrições de todas as clínicas do cliente em que o usuário está logado. Palavras do solicitante: “a central deve mostrar as consultas e prescrições de todas as clínicas do cliente em que o usuário está logado”. Como mostrar a clínica no card, o efeito nos indicadores e no “Todos” são propostas do Designer (E-CM-028 e E-CM-029); o que ficou em aberto foi respondido em D-CM-060. | Definição (RN-CM-020; nova RN-CM-032); Especificação 2.2, 2.3, 2.4, 2.9; Mapeamento 4.1, 4.2 e 4.7; Protótipo; Cenários (CT-CONS-19, CT-PRES-19 e 20) |
| D-CM-051 | 26/10/2026 | [A ordem das conversas foi trocada por D-CM-087; a conformidade da nova ordem está em P-CM-057.] A ordem das mensagens confere com ECF.17.04 (ordem cronológica). Resposta: “P-CM-26(e): ordenação confere”. Fecha o item (e) de P-CM-026. | Definição (SBIS); Especificação 2.10 |
| D-CM-052 | 26/10/2026 | Respostas aos itens 3, 6, 7 e 8 de P-CM-042. (3, segunda parte) Entre as versões de uma prescrição há uma só válida; as outras ficam canceladas. Por isso a versão antiga e a nova não aparecem juntas na mesma agenda (o filtro de situação já garante isso). (6) Uma nova versão de prescrição já nasce sem assinaturas: não herda a assinatura moderna nem os campos legados. (7) Palavras do solicitante: “sim, perde o efeito, entra no próximo ciclo de 7 dias”. A assinatura que serviu de revisão perde o efeito se a aplicação for adiada para depois do limite; o que “próximo ciclo de 7 dias” significa na prática foi decidido em D-CM-059. (8) O banco deve mudar: o tipo de mensagem aceita só Response, como o contrato; a mudança entra no Log de Mudanças Estruturais do Banco de Dados. | Definição (RN-CM-020); Mapeamento 4.9 e Log de Mudanças; Cenários (CT-PRES-20 e 21) |
| D-CM-053 | 26/10/2026 | O chip “há 1h20” (consulta além do previsto) continua leve, como os chips de prescrição. Resposta a P-CM-044: “manter leve”. | Especificação 2.3 |
| D-CM-054 | 26/10/2026 | O selo “Atrasado” e o número do indicador de Alertas ficam mais leves. Resposta a P-CM-045: “sim, ficam mais leves”. A forma (cores e tokens) foi proposta pelo Designer e aprovada em D-CM-058. | Definição (fluxo de consulta); Especificação 2.2, 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-04) |
| D-CM-055 | 26/10/2026 | O tempo restante abaixo de 1 hora aparece em minutos (“45min restantes”), em vez de “0h restantes”. Resposta a E-CM-020: “ok, aprovado”. | Especificação 2.4 e i18n; Protótipo |
| D-CM-056 | 26/10/2026 | O texto dos chips “Crítico” e “Atenção” fica no peso regular (400); o font-weight-medium sai dos dois. Resposta a E-CM-025: “manter regular (400)”. RN-CM-019 (“sem texto em negrito”) não muda. | Especificação 2.4 e 2.8; Protótipo |
| D-CM-057 | 26/10/2026 | A borda do campo em repouso fica em --color-neutral-light, como diz o Design System (seção 11), com contraste de 1,7:1 no tema claro e 1,8:1 no escuro, abaixo dos 3:1 que a WCAG 1.4.11 pede para o limite de um campo; o solicitante aceitou esse contraste. Resposta a P-CM-043: “manter neutral-light” (escrito como “E-CM-043”, leitura do Designer: P-CM-043). O protótipo passa a usar neutral-light no campo de busca e no de resposta do modal de mensagens (antes neutral-pure). | Especificação 2.8 (Input e Acessibilidade); Protótipo |
| D-CM-058 | 26/10/2026 | A proposta do Designer para o selo “Atrasado” e o número do indicador de Alertas está aprovada: selo com fundo color-error-light, texto e ponto color-error-dark, sem contorno, só o ponto pulsa; número do indicador em color-error-dark. Resposta: “E-CM-045: proposta aprovada” (leitura do Designer: não existe E-CM-045; a proposta é a de E-CM-026, que respondia a P-CM-045). A Agenda do Médico segue com o selo preenchido (--color-alert-fill); a Central só usa esse token no toast de erro do protótipo. | Especificação 2.2, 2.3 e 2.8; Protótipo; Cenários (CT-TEMA-04) |
| D-CM-059 | 26/10/2026 | Assinatura que serviu de revisão e aplicação adiada (D-CM-052, item 7), leitura A: a prescrição já assinada não precisa ser assinada de novo. A assinatura que dispensou a revisão perde esse efeito se a aplicação for adiada para depois do limite, e a prescrição volta só a “a revisar”, quando a nova data entrar na janela de revisão (hoje, 1 dia). Resposta a P-CM-047: “a que aplicou, prescrição assinada não precisa ser assinada novamente”. | Definição (RN-CM-020); Especificação 2.4 (critérios); Cenários (CT-PRES-21) |
| D-CM-060 | 26/10/2026 | [O escopo “todas as clínicas do cliente” deste item foi substituído por D-CM-066; as janelas por clínica seguem valendo.] Escopo do cliente e regras por clínica (resposta a P-CM-046). Palavras do solicitante: “as janelas obedecem às regras de suas respectivas clínicas”. Hierarquia explicada por ele: o login é autorizado para um cliente (Cliente); dentro do cliente há várias clínicas (ClienteEmpresa), com dados no banco do cliente (ClienteBD); por isso o médico tem acesso a todas as agendas, prescrições e mensagens do cliente durante o login naquele cliente. Ao mudar de clínica, o médico pode mudar de cliente, e passa a ver todas as clínicas do novo cliente. Isto é uma exceção do sistema para médicos; os demais profissionais ficam restritos à clínica escolhida na tela de seleção de clínicas. Efeitos na Central (aplicação feita pelo Designer a partir desta decisão; (a) e (c) estão também em E-CM-029 e E-CM-028): (a) “todas as clínicas do cliente” vale para consultas, prescrições, procedimentos e mensagens, e para os indicadores correspondentes; (b) as janelas de prescrição (PrescricaoTempoAssinatura, NumeroDiasRevisaoPrescricoes) são as da clínica de cada prescrição; (c) a regra de exibir o nome da clínica passa a ser “cliente com mais de uma clínica” (ver E-CM-028). O que ficou em aberto nesta decisão foi resolvido depois: o fuso das janelas em D-CM-062, o rótulo do indicador e “Em Tratamento” em D-CM-063, a clínica nas mensagens em D-CM-064 e a ligação das clínicas em D-CM-065. | Definição (RN-CM-032, RN-CM-020, dependências); Especificação 2.2 a 2.6 e 2.9; Mapeamento 4.1 a 4.8; Protótipo (Demo); Cenários (CT-CONS-19, CT-PRES-19 e 22, CT-PROC-14, CT-MSG-22) |
| D-CM-061 | 26/10/2026 | Confirmação de E-CM-030. Palavras do solicitante: “E-CM-030: ok, confirmado”. O card de procedimento mostra o nome curto da clínica, no mesmo formato, com o mesmo ícone e a mesma condição dos cards de consulta e de prescrição (só quando o cliente tem mais de uma clínica; desde D-CM-066, só quando o médico atende em mais de uma); o contrato de procedures ganha o campo clinic. | Definição (RN-CM-032); Especificação 2.6 e 2.9; Mapeamento 4.3; Protótipo; Cenários (CT-PROC-14) |
| D-CM-062 | 26/10/2026 | Resposta a E-CM-031. Palavras do solicitante: “ok, para a tabela, mas acho que é melhor que o hoje seja calculado no fuso da clínica que o usuário está logado. Senão ele pode pensar que está adiantado e na verdade já está na hora.” Decisão: (1) a aplicação monta a tabela de limites por clínica, com os parâmetros de cada uma (como em E-CM-032); (2) o “hoje”, o fim do dia de cada janela (assinar e revisar) e os horários exibidos seguem o fuso da clínica em que o usuário está logado, também para as prescrições de clínicas de outro fuso. Efeito: um só “hoje” em toda a tela (consultas, procedimentos, prescrições e indicadores). O fuso da clínica da prescrição deixa de ser usado. | Definição (RN-CM-032, RN-CM-020); Especificação 2.2, 2.4 e 2.9; Mapeamento 4.6 e 4.7; Protótipo (comentários); Cenários (CT-PRES-22, CT-PRES-23) |
| D-CM-063 | 26/10/2026 | Resposta a P-CM-048, itens (a) e (b). Palavras do solicitante: “a. ok, está correto / b. ok, está correto”. Eram propostas do Designer e valem: (a) o rótulo “p/assinar (próx. N dias)” do indicador de alertas e o campo toSignWindowDays usam o N da clínica em que o médico está logado; (b) o indicador “Em Tratamento” usa os parâmetros TempoPacienteAtivoAgenda e TempoPacienteAtivoPrescricao da clínica em que o médico está logado. | Especificação 2.2 e 2.9; Mapeamento 4.5 e 4.6; Protótipo; Cenários (CT-PRES-22) |
| D-CM-064 | 26/10/2026 | Resposta a P-CM-048, item (c). Palavras do solicitante: “mostrar a clínica nos cards de mensagem”. O card de conversa mostra o nome curto da clínica de origem, com o mesmo formato e a mesma regra dos demais cards (só quando o cliente tem mais de uma clínica; desde D-CM-066, só quando o médico atende em mais de uma); o contrato de conversations ganha o campo clinic. De onde vem o nome: E-CM-033. | Definição (RN-CM-032); Especificação 2.5 e 2.9; Mapeamento 4.8; Protótipo; Cenários (CT-MSG-22) |
| D-CM-065 | 26/10/2026 | Resposta a P-CM-048, item (e): como ligar as clínicas. Palavras do solicitante: “dentro do banco do cliente há uma tabela SegEmpresa, que contém o campo IpSegurancaEmpresaId que é o guid correspondente em ClienteEmpresa. Essa tabela tem um par chamado Clinica, que contém o campo IdChClinica, que identifica a que clínica os registros pertencem. Os limites estão no banco do cliente em IpParametro e IpParametroChave (onde está o id da clínica (IdChave, nesse caso aponta para o IdChClinica))”; e “os defaults para revisar = 1 e para assinar = 7”. A cadeia fica: ClienteEmpresa.Id (IpSeguranca) = SegEmpresa.SegurancaClienteEmpresaId → SegEmpresa.IdEmpresa → Clinica.IdEmpresa (chave estrangeira real) → Clinica.IdChClinica = Agenda.IdChClinica = IpParametroChave.IdChave. Os padrões 1 e 7 já estavam em D-CM-006 e D-CM-037 e foram conferidos. O nome do campo: o solicitante escreveu IpSegurancaEmpresaId; na Biblioteca de Schema (DDL) (GescomClienteAlfa e GescomZeradoPadronizacao) o campo é SegurancaClienteEmpresaId (uniqueidentifier NULL), e é o nome usado nos documentos (confirmar em P-CM-050). | Mapeamento (ligação das clínicas, 4.5, 4.6 e 4.8); Cenários |
| D-CM-066 | 26/10/2026 | Resposta ao item (d) de P-CM-048, depois explicado em P-CM-049. Palavras do solicitante: “O correto nos 2 casos é mostrar as clínicas que o usuário atende (não faz sentido mostrar pacientes de uma clínica que ele não atende, pois ele não pode fazer nada por ela - atender, revisar e assinar prescrições, mandar mensagens… porque ele não é o médico dessa clínica”. (1) Na Central do Médico e na Agenda do Médico, o médico vê só as clínicas em que atende: consultas, prescrições, procedimentos e mensagens de outra clínica do cliente não aparecem nem entram nos indicadores, nem com o toggle “Todos”. (2) Isto substitui, nesse ponto, D-CM-050 e D-CM-060 (“todas as clínicas do cliente”). Continuam valendo de D-CM-060 as janelas de prescrição por clínica; a regra de que os demais profissionais ficam na clínica escolhida não foi alterada. (3) O nome da clínica nos cards aparece quando o médico atende em mais de uma clínica, a mesma regra da Agenda (RN-AGM-017, a). (4) DT-013 revista (Decisões Transversais v1.7). (5) A Agenda do Médico foi alinhada depois, por D-CM-068. Como o sistema sabe em que clínicas o médico atende: D-CM-067. | Definição (RN-CM-032, dependências, Fluxo); Especificação 2.2 a 2.6 e 2.9; Mapeamento (Seção 4, bloco novo, 4.1 a 4.8); Protótipo (texto do Demo); Cenários (CT-CONS-19 e 20, CT-PRES-19, 22 e 23, CT-PROC-14, CT-MSG-22) |
| D-CM-067 | 26/10/2026 | Confirmação de E-CM-034. Palavras do solicitante: “E-CM-034: vamos usar as clinica que o usuário tem acesso. Recurso.IdChClinica e RecursoHorario tem relação com a marcação de agendas (tarefa da recepção), eles tem relação porque só quem é um recurso na clínica pode ter horário marcado, mas acho que não influencia nesse momento.” “Atender”, para o sistema, é a clínica do cliente a que o usuário tem acesso (ClientePerfilAcessoUsuario, RN-CIU-009), traduzida para IdChClinica pela cadeia de D-CM-065 (tabela {ClinicasDoMedico}). Recurso.IdChClinica e RecursoHorario ficam fora desta regra. | Definição (RN-CM-032, dependências); Mapeamento (Seção 4, bloco “Clínicas em que o médico atende”); Cenários (massa) |
| D-CM-068 | 26/10/2026 | Resposta a P-CM-051. Palavras do solicitante: “sim, precisa filtrar pelas clínicas que o usuário tem acesso. Se ele perdeu acesso a uma clínica, não pode mais ver suas agendas e nem mesmo os pacientes dela.” (1) A Agenda do Médico passa a filtrar explicitamente pelas clínicas a que o usuário tem acesso (Agenda: Definição v1.17, Especificação v1.20, Mapeamento v1.10 e Cenários de Teste v1.7; o Protótipo não muda). (2) Na Central isso já vale, pelo filtro de D-CM-066, para consultas, prescrições, procedimentos e mensagens. (3) “Nem mesmo os pacientes dela”: esta parte foi corrigida pelo solicitante em D-CM-070; o médico não perde o acesso ao paciente. | Agenda do Médico (RN-AGM-002, CA-008.9, Mapeamento 4.1 a 4.3, CT-AGM-CTX-11); Definição da Central (RN-CM-032); Mapeamento da Central (Seção 4) |
| D-CM-069 | 26/10/2026 | Respostas aos itens (b) e (c) de P-CM-050. (b) Conversa.IdEmpresa guarda o SegEmpresa.IdEmpresa: “correto, é o valor de SegEmpresa.IdEmpresa… mas pensando aqui, acho que o ideal é que fosse o IdChClinica, não idEmpresa… mas deixe isso pendente para decidir depois.” A troca por IdChClinica ficou em P-CM-052. (c) Fuso: “Já haviamos definido que ClinicaFusoHorario está descontinuado. Verifique na documentação.” Verifiquei: o fuso vem de ClienteEmpresa.FusoHorarioOficial (Log de Mudanças Estruturais, 07 e 08/10/2026; o solicitante esclareceu então que o campo fica em ClienteEmpresa), e nenhuma consulta da Central lê Clinica.FusoHorario. Não encontrei registro escrito de que Clinica.FusoHorario foi descontinuado, e a Biblioteca de Schema (DDL) ainda traz a coluna; registrei como dito pelo solicitante (depois achei um registro parcial, citado em D-CM-072). Nada mudou nas consultas. O item (a) foi respondido em D-CM-071. | Mapeamento (Seção 4, 4.8) |
| D-CM-070 | 26/10/2026 | Resposta a P-CM-053. Palavras do solicitante: “pois é… ele não perde acesso ao paciente, somente às suas agendas e prescrições que provavelmente serão redirecionadas ou canceladas. Para o médico, Paciente.IdChClinica não faz diferença, mas para o administrativo e outras funções será um filtro.” (1) Corrige D-CM-068: quem perde o acesso a uma clínica perde as agendas e as prescrições dela, não os pacientes. (2) O que é medido por paciente (“Em Tratamento”, adesão ao protocolo, busca de pacientes) não passa por filtro de clínica para o médico; nada muda no SQL. (3) Paciente.IdChClinica não é usado pela Central; o solicitante informou que será filtro para o administrativo e outras funções, ainda sem especificação (fora do escopo da Central). (4) “Provavelmente serão redirecionadas ou canceladas” é a expectativa do solicitante, não uma regra definida: o que acontece com as agendas e prescrições da clínica sem acesso não está especificado. | Definição (RN-CM-032); Mapeamento (Seção 4); Agenda do Médico (RN-AGM-002) |
| D-CM-071 | 26/10/2026 | Resposta ao item (a) de P-CM-050. Palavras do solicitante: “utilize o termo do DDL”. O campo de SegEmpresa que guarda o guid de ClienteEmpresa é SegurancaClienteEmpresaId. IpSegurancaClienteEmpresaId não é adotado; por isso não há mudança de nome no banco e nada a registrar no Log por este motivo. | Mapeamento (Seção 4, ligação entre a clínica do login e a base do cliente); guia DOC-009 |
| D-CM-072 | 26/10/2026 | Pedido do solicitante: “registre no log que Clinica.FusoHorario foi descontinuado”. Feito: entrada de 26/10/2026 no Log de Mudanças Estruturais do Banco de Dados (total passa a 24). A coluna continua na Biblioteca de Schema (DDL), e não foi informado se será removida. Em D-CM-069 (c) eu escrevi que não achei registro escrito; depois achei um parcial, no Mapeamento da Agenda do Médico v1.1 (07/10/2026), e ele está citado no Log. | Log de Mudanças Estruturais; Mapeamento (Seção 4) |
| D-CM-073 | 27/10/2026 | Cores e nome do status vêm da API, no próprio status (DT-016): status vira objeto { domain, name, colors } em appointments e procedures. As cores ficam nas tabelas IpTerminologia.DomEstadoAgendaConsulta e DomEstadoAgendaProcedimento (chave CodEstado; consulta: A, D, G, J, M, X; procedimento: SCH, WTI, CKD, PRP, ADM, ASD, FNS, CNL), e o nome em TermoTraducao, nos 3 idiomas. Mesmas cores para todas as clínicas. Palavras do solicitante: “criamos duas tabelas em IpTerminologia: DomEstadoAgendaConsulta e DomEstadoAgendaProcedimento, que guardam as 4 cores além do Id do estado e sua descrição. O termo tem seu valor nos 3 idiomas em TermoTraducao”; “o termo é identificado pelo campo CodEstado”; “sim, mesma cor para todas as clínicas (nota: estamos discutindo do cliente escolher suas cores, mas seria uma alternativa opcional, ainda em discussão - isso pode modificar essa definição)”. Origem: proposta “Cores de status por tema” da equipe de front, aprovada pelo solicitante | Especificação 2.3, 2.6, 2.8, 2.9; Mapeamento 4.1, 4.3; Protótipo |
| D-CM-074 | 27/10/2026 | O valor de contrato do status “Completo” do procedimento é administered (CodEstado ASD), no lugar de completed (D-CM-030, D-CM-042). Palavras do solicitante: “o termo correto é administered” | Especificação 2.6, 2.9; Mapeamento 4.3, 4.4; Protótipo; Cenários CT-PROC-11 |
| D-CM-075 | 27/10/2026 | Avatar de iniciais: texto color-neutral-darker sobre a cor de fundo do status, nos dois temas. Palavras do solicitante: “sobre o avatar, acho melhor que seja neutral-darker sobre a cor do status, pois ele deve representar mais o paciente do que o estado da agenda. Mas gosto da idéia do status da agenda estar representada sutilmente no avatar.” | Especificação 2.3, 2.8; Protótipo |
| D-CM-076 | 27/10/2026 | Card cancelado: chip “Cancelado” em cinza preenchido, como na proposta do front, e os textos do card riscados, exceto o chip de estado; só os textos. Palavras do solicitante: “vamos manter o cancelado como proposto pelo front, mas acrescentamos que o card cancelado fica com os textos riscados (hora, nome, etc), exceto o chip de estado”; “só os textos”. Na Central, vale para o card de procedimento cancelado (o painel de Consultas não mostra canceladas) | Especificação 2.6; Protótipo; Cenários CT-PROC-15 |
| D-CM-077 | 27/10/2026 | Confirmação de E-CM-046. Palavras do solicitante: “E-CM-046: confirmado”. No card de procedimento cancelado, o status não é riscado e o avatar continua neutro (color-neutral-light / color-neutral-dark), sem a cor do status. Com D-CM-079, o status sem risco é o chip | Especificação 2.6, 2.8; Protótipo |
| D-CM-078 | 27/10/2026 | Confirmação de E-CM-047. Palavras do solicitante: “E-CM-047: confirmado”. Ficam os caminhos de endpoint da Especificação 2.9 | Especificação 2.9 |
| D-CM-079 | 27/10/2026 | Resposta a P-CM-054. Palavras do solicitante: “status do procedimento devem virar chip colorido”. O status do card de procedimento vira chip .chip-status com status.colors e status.name, como no painel de Consultas | Especificação 2.6, 2.8, 2.9; Protótipo; Cenários CT-PROC-11, 15, 16 |
| D-CM-080 | 27/10/2026 | Resposta a P-CM-056. Palavras do solicitante: “trocar front e back no mesmo deploy”. A troca de status de texto para objeto é feita no mesmo deploy, sem período com os dois formatos; vale também para a Agenda do Médico | Especificação 2.9; Agenda do Médico, Especificação |
| D-CM-081 | 27/10/2026 | Resposta a P-CM-055. Palavras do solicitante: “indicadores serão descontinuados depois da implementação nova”. O indicador EstadoAgendaConsulta de IpTerminologia.Indicadores sai de uso depois que DomEstadoAgendaConsulta e DomEstadoAgendaProcedimento estiverem em uso | Mapeamento, “Tabelas novas”; Log de Mudanças Estruturais do Banco de Dados |
| D-CM-082 | 27/10/2026 | Nomes dos status em pt-BR. Palavras do solicitante: “os termos corretos registrados em TermoTraducao são: Em atendimento, Em preparo, Em aplicação (ao invés de Em administração)”. Os documentos passam a usar esses nomes (antes “Em Atendimento”, “Preparo” e “Em administração”) | Todos os documentos da Central; Agenda do Médico; Design System, seção 4 |
| D-CM-083 | 27/10/2026 | Pedido do solicitante: “na próxima alteração dos documentos, pode corrigir as menções antigas” (proveniência de decisão no corpo dos documentos, apontada pela revisão técnica da v5.15). Feito na v5.16: as menções saem do corpo da Definição, da Especificação, do Protótipo, do Mapeamento e dos Cenários, e do Mapeamento v1.12 da Agenda do Médico; a proveniência fica no Histórico de Versões e neste Registro | Todos os documentos da Central; Agenda do Médico, Mapeamento |
| D-CM-084 | 28/10/2026 | Nome do status waiting em pt-BR. Palavras do solicitante: “Aguardando recepção” (resposta sobre a divergência entre a Agenda, “Aguardando Recepção”, e a Central, “Aguardando recepção”). É o texto cadastrado em TermoTraducao; Central e Agenda do Médico passam a usá-lo | Todos os documentos da Central; Agenda do Médico |
| D-CM-085 | 28/10/2026 | Botões da Central alinhados à seção 12 do Design System. Palavras do solicitante: “alinhe o botão na próxima versão” e, entre três opções, “Seção 12 inteira”. Botões dentro de card são secundários, com contorno (Assinar, Revisar, PEP, Resolvido); o preenchido em verde escuro (--color-primary-strong, texto --color-on-primary-strong) fica para a ação principal de modal e caixa de diálogo; Cancelar com contorno. O Assinar deixa de usar --color-on-primary | Especificação 2.8; Protótipo; Cenários CT-ACES-07 |
| D-CM-086 | 28/10/2026 | Confirmação de E-CM-049. Palavras do solicitante: “E-CM-049: aceito as duas iniciativas”. No modal de mensagem, o primário é “Responder” e “Resolvido” é secundário; “Descartado” e “Descartar” seguem no estilo destrutivo até o Design System definir o botão destrutivo | Especificação 2.8; Protótipo |
| D-CM-087 | 28/10/2026 | O painel de Mensagens adota as mudanças decididas na Mensageria (Registro de Decisões da Mensageria, D-MSG-021 e D-MSG-023). Palavras do solicitante: “Ponto em aberto: pode incluir na central.” (1) assunto na linha 1 do card, com o horário à direita, e “autor: texto” na linha 2; (2) sem o selo “Respondida”; (3) aviso de leitura check/check-check quando a última mensagem é do médico, com o campo readByOthers; (4) ordem: não lidas primeiro; dentro de cada grupo, a data mais recente entre a última mensagem e o prazo; empate pela conversa criada mais recentemente (RN-MSG-002); (5) valor responded no lugar de replied; (6) o horário continua relativo no painel (a Mensageria mostra data e hora) | Definição RN-CM-015; Especificação 2.5, 2.8, 2.9, 2.10; Mapeamento 4.8, 4.9; Protótipo; Cenários CT-MSG-05, 08, 15, 23 a 26 |
| D-CM-088 | 29/10/2026 | O painel de Mensagens adota o grau de urgência, a ordem pelo grau e o horário relativo da Mensageria. Palavras do solicitante: “a central está aberta, pode alterar a documentação.” (1) chip com o nome do grau (Rotina, Urgente, Quanto antes, Imediato), inclusive Rotina (D-MSG-043); (2) chaves do HL7 em minúsculas: routine, urgent, asap, stat (D-MSG-046); (3) ordem dentro de cada camada de leitura: grau (Imediato, Quanto antes, Urgente, Rotina, sem grau) e depois a data (RN-MSG-002, D-MSG-026); (4) horário relativo: “Há x min”, “Há x h” ou data e hora (D-MSG-028, D-MSG-032); (5) o grau é imutável e a prioridade do legado não é convertida (D-MSG-042) | Definição RN-CM-015; Especificação 2.5, 2.9, i18n; Mapeamento 4.8; Protótipo; Cenários CT-MSG-27 e 29 |
| D-CM-089 | 29/10/2026 | O botão “Resolvido” sai do card do painel de Mensagens. Palavras do solicitante (Mensageria): “vamos remover o botão” (D-MSG-047), depois de consultar um crítico de UX e um médico crítico, que recomendaram a retirada (risco de resolver sem ler, sobretudo alerta do sistema; mensagem errada do fluxo). “Resolvido” e “Descartado” ficam só no modal. Substitui o botão do card de D-CM-085 (o modal não muda) | Definição RN-CM-015; Especificação 2.5, 2.8, 2.10; Protótipo; Cenários CT-MSG-19, 26, 28 e CT-ACES-11 |
| D-CM-090 | 29/10/2026 | Nomes técnicos, para não confundir o grau de urgência da conversa com o indicador de tempo. Palavras do solicitante: “podemos lidar com nomes mais específicos, como urgenceLevel (para o grau de urgência)” (grafia corrigida pelo Designer para urgencyLevel, a confirmar) e “Use timeIndicator para usar nos 2 paineis (pois é a mesma função)”. urgencyLevel é o grau da conversa; timeIndicator é o chip “Crítico”/“Atenção” dos painéis de Consultas e de Prescrições. Substitui urgency em D-CM-088 e E-CM-051. Fora do escopo: o campo urgent do endpoint de alertas de prescrição (a contagem do KPI) não muda. Valores critical, attention, normal do timeIndicator: proposta do Designer | Especificação 2.5, 2.9, terminologia; Mapeamento 4.8; Protótipo |
2. Escolhas do Designer, a confirmar
Escolhas feitas sem pedido explícito do solicitante. Valem até serem confirmadas ou trocadas.
| ID | Escolha | Onde está |
|---|---|---|
| E-CM-004 | Toggles ativos com texto neutral-darker (os chips de urgência saíram por D-CM-046; os botões, por D-CM-085). | Especificação 2.8; Protótipo |
| E-CM-018 | ”Administração iniciada” (D-CM-039) = Agenda.DhInfusaoIniUTC preenchido na agenda da prescrição. A regra retira só as prescrições “a revisar”; a “a assinar” com administração iniciada continua na lista (vencida, em vermelho), porque esconder esse caso esconderia a falha de processo que o solicitante descreveu. | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários (CT-PRES-11, CT-PRES-14) |
| E-CM-019 | Definição de “assinatura dentro da janela de revisão” (D-CM-040): vale quando existe assinatura do médico (PrescricaoAssinatura com TipoAssinatura = 'A', ou Prescricao.DataAssinaturaPrescricao) cuja data é igual ou posterior à meia-noite, no fuso da clínica em que o usuário está logado (D-CM-062), do dia da aplicação menos N dias — isto é, feita depois de a janela de revisão daquela prescrição ter aberto. Exemplo com N = 1 e aplicação em 23/09: a janela abre em 22/09 00:00; assinatura em 22/09 11:14 dispensa a revisão, assinatura em 21/09 18:00 não. As duas colunas de data são datetime sem fuso e são tratadas como hora local da clínica [a confirmar com o time de banco]. Qualquer assinatura que atenda vale (uma nova versão reassinada vale pela nova data). | Definição (RN-CM-020); Mapeamento 4.6 e 4.7; Cenários |
| E-CM-021 | Textos novos: confirmação de resolver (“Resolver conversa?” / “A conversa será marcada como resolvida para todos os destinatários.” / “Cancelar” · “Resolver”), confirmação de descartar (“Descartar conversa?” / “A conversa será descartada para todos os destinatários.” / “Cancelar” · “Descartar”), “sem tempo previsto” e “{d} dias atrasada”, com tradução em en-US e es-419 (Especificação 2.5 e 2.6). | Especificação 2.5, 2.6, 2.4 (i18n); Protótipo |
| E-CM-024 | Itens da seção 11 do Design System que são do Designer: valer como padrão de todas as telas (o solicitante descreveu o critério para a tela de registros clínicos); espessura de 2px nos estados “selecionado” e “com erro”; precedência entre os estados abaixo de “erro” (selecionado > alterado > repouso — “erro antes de selecionado” foi decidido em D-CM-049); :focus-visible; afastamento de 2px do anel; campo de texto sem anel (a borda “selecionado” faz o papel); a regra de item que permanece selecionado (borda do item mais anel de foco afastado). O solicitante definiu as cores da borda por estado e pediu o anel de 2px. | Design System 11 |
| E-CM-027 | Para prescrições com o mesmo tempo restante e o mesmo nome de paciente (nome social, se houver; senão o nome civil), o último critério é o identificador da prescrição, do menor para o maior. A comparação de nomes ignora maiúsculas e acentos (ordem alfabética do pt-BR). Sem isso a ordem de dois itens iguais poderia mudar a cada atualização automática. | Definição (RN-CM-011); Especificação 2.4 e 2.9; Mapeamento 4.7; Cenários (CT-PRES-18) |
| E-CM-028 | Como mostrar a clínica (D-CM-050): nos cards de consulta e de prescrição (e, por D-CM-061, de procedimento e, por D-CM-064, de mensagem), o nome curto da clínica como informação secundária (ícone Lucide building-2 de 14px e texto de 12px em color-neutral-pure, sem chip), só quando o médico atende em mais de uma clínica — o mesmo ícone e a mesma regra da Agenda do Médico (RN-AGM-017, a), por D-CM-066 (entre D-CM-060 e D-CM-066 a regra foi “o cliente tem mais de uma clínica”). O campo clinic vem do back-end, null com uma só clínica. O fuso de “hoje” e dos horários é o da clínica em que o médico está logado, como na Agenda (RN-AGM-018, decidida pelo solicitante naquela funcionalidade). | Definição (RN-CM-032); Especificação 2.3, 2.4, 2.6, 2.9; Mapeamento 4.1, 4.3 e 4.7; Cenários (CT-CONS-19, CT-PRES-19, CT-PROC-14) |
| E-CM-029 | Os indicadores “Consultas Hoje”, “Procedimentos Hoje” (por D-CM-060) e “Alertas de Prescrição” contam o mesmo conjunto dos painéis, isto é, as clínicas em que o médico atende (D-CM-066; senão o número não bateria com a lista). O toggle “Todos” das prescrições amplia para todos os médicos, mas só nessas clínicas. | Definição (RN-CM-032); Especificação 2.2 e 2.4; Mapeamento 4.2, 4.4 e 4.7 |
| E-CM-032 | Como montar a tabela de limites por clínica, depois de D-CM-062 e D-CM-065: a aplicação lê todas as linhas de Clinica do banco do cliente (toda Agenda.IdChClinica aponta para Clinica, então nenhuma prescrição fica sem linha) e, para cada uma, os valores de NumeroDiasRevisaoPrescricoes (N, padrão 1) e PrescricaoTempoAssinatura (S, padrão 7) em IpParametroChave (IdChave = IdChClinica); com isso monta a tabela {LimitesPorClinica} (IdChClinica, N, S, LimiteRevisaoUTC, LimiteAssinaturaUTC). Os limites em UTC são a meia-noite do dia (hoje + N + 1) e (hoje + S + 1) no fuso da clínica logada (D-CM-062), convertida para UTC pela aplicação (por causa do horário de verão). O fuso da clínica logada vem de ClienteEmpresa.FusoHorarioOficial (a clínica da sessão). A hora das assinaturas (PrescricaoAssinatura.Data, datetime sem fuso) é lida como hora local da clínica logada, para a exceção (a) de E-CM-019: é uma simplificação do Designer, que só difere do correto se as clínicas do cliente tiverem fusos diferentes. | Mapeamento 4.6 e 4.7; Definição (RN-CM-020, RN-CM-032); Cenários (CT-PRES-22, CT-PRES-23) |
| E-CM-033 | Nome da clínica no card de mensagem (D-CM-064) e contagem das clínicas do cliente. (1) O nome sai do mesmo lugar dos outros cards (Chave.Descricao), pelo caminho Conversa.IdEmpresa = SegEmpresa.IdEmpresa → Clinica.IdEmpresa → Clinica.IdChClinica → Chave.IdChave. Isso supõe que Conversa.IdEmpresa guarde o SegEmpresa.IdEmpresa (a mensageria declara int, SegEmpresa declara smallint, e não há chave estrangeira entre as duas bases de tabelas): confirmado em D-CM-069. (2) A condição de exibir o nome deixou de ser “o cliente tem mais de uma clínica”: com D-CM-066 é “o médico atende em mais de uma clínica” (D-CM-067). | Mapeamento 4.1 e 4.8; Especificação 2.5 e 2.9 |
| E-CM-048 | Posição do chip de status no card de procedimento (D-CM-079): na linha 2, entre o local e as tags; o horário entre parênteses fica logo depois do chip, fora dele | Especificação 2.6; Protótipo |
| E-CM-050 | Detalhes do card de conversa não definidos na Mensageria (D-CM-087): (1) campo authorIsMe no contrato da Central, para o front mostrar “Você” (a Mensageria usa lastAuthor com o id do autor); (2) o aviso de leitura só no card, não nas mensagens dentro do modal (na Mensageria, ainda [PROPOSTA]); (3) a cor --color-secondary-dark do check-check acompanha a proposta da Mensageria, que ainda não foi aprovada lá; (4) o assunto do modal (nome acessível) passa a ser subject, e não o texto da primeira mensagem; (5) a conversa nova do mock (Claire, Enfermagem); (6) o card da Central não ganha o ícone de carta (Lucide mail) da Mensageria para não lida: continua com a borda e o ícone de origem coloridos (D-CM-045) | Especificação 2.5, 2.9; Mapeamento 4.8; Protótipo; guia de desenvolvimento da v5, seção 4.13 |
| E-CM-051 | Detalhes do card de conversa com o grau e o horário (D-CM-088): (1) o chip fica na linha do prazo, antes do prazo, e o grau também aparece no modal, ao lado do horário e do autor; (2) nome acessível do card com “Grau de urgência: {nome}”; (3) campo urgencyLevel e serverNow na resposta de conversations[] (a Mensageria já usa serverNow); (4) x do horário relativo por truncamento, mínimo de 1 min, recalculado a cada atualização de 1 minuto (E-MSG-019); (5) textos msg-ha-min, msg-ha-h e msg-grau-titulo nos três idiomas | O solicitante pediu a alteração, sem estes detalhes; (1) e (2) seguem a Mensageria (E-MSG-017, E-MSG-022), (3) a (5) a E-MSG-019 |
3. Questões em aberto
| ID | Questão | Situação |
|---|---|---|
| P-CM-003 | Quando o médico assina uma prescrição cuja aplicação já está na janela de revisão, o que ele deve ver depois? Divergência: a regra RN-CM-020 dizia que a prescrição passava na hora para “a revisar” e continuava na lista (assinar e revisar eram duas ações separadas), enquanto o critério de aceitação do indicador de alertas dizia que o número diminui em um. Com D-CM-040 (assinatura dentro da janela dispensa a revisão) as duas passam a concordar: a prescrição sai da lista e o número diminui. Pergunta: confirma que isto resolve? Atenção (P-CM-035): no sistema atual o parâmetro RevisorIgualMedicoQueAssinou (padrão “N”) impede que o revisor seja o mesmo médico que assinou, o que vai em sentido contrário. | Aguarda o solicitante. |
| P-CM-007 | A Central e a Agenda do Médico descrevem o mesmo dado de jeitos diferentes. O modo de atendimento (attendanceMode): a Agenda envia um objeto com código e texto ({code, label}); a Central envia só um texto — e a própria Especificação da Central mostra o código no exemplo (“in_person”) enquanto o Mapeamento diz que é o texto traduzido. (O outro ponto, o formato do horário dos procedimentos, foi resolvido em D-CM-042.) Pergunta: a Central deve enviar attendanceMode como objeto {code, label}, igual à Agenda? Ideia do Designer (invenção): sim, para o mesmo componente de tela servir às duas. | Aguarda o solicitante. |
| P-CM-026 | Conformidade SBIS (RequisitosSBISv5.2 ambulatorial.xlsx), item que segue em aberto: (a) NGS1.07.03 pede trilha de auditoria ao inativar um registro do prontuário; resolver ou descartar uma conversa não tem auditoria (D-CM-014). O solicitante gostaria de tratar a mensageria como ferramenta auxiliar, um canal não oficial de comunicação que ficaria fora do SBIS; falta confirmar se isso é possível, já que pode haver conteúdo clínico nas conversas. Observação do Designer: os alertas automáticos do sistema (prescrição urgente, infusão atrasada) têm conteúdo clínico e podem ser descartados para todos os destinatários sem trilha de auditoria; conversas livres e alertas do sistema podem precisar de tratamento diferente. (Os itens b, c e d foram decididos em D-CM-036 e o item e, em D-CM-051.) | Aguarda o solicitante (item a: confirmar se é possível). |
| P-CM-035 | Lembrete pedido pelo solicitante: o sistema atual tem parâmetros que controlam quem pode assinar e quem pode revisar prescrições; isso não foi especificado na Central. O solicitante lembra de um parâmetro que permite ou não que outros médicos assinem as prescrições do prescritor — não o localizei no catálogo ParametrosGemedLegado.csv. Parâmetros próximos que existem no catálogo: MedicoPodeRevisar, EnfermeiroPodeRevisar, FarmaceuticoPodeRevisar (quem pode ser o revisor; padrão “N” para os três) e RevisorIgualMedicoQueAssinou (o revisor pode ser o mesmo médico que assinou; padrão “N”). Para especificar numa versão futura: dizer qual é o parâmetro de assinatura por outro médico e como ele interage com o “Todos” e com D-CM-040. | Lembrete — especificar em versão futura. |
| P-CM-036 | O Menu Lateral (Check-in de Usuários, Épico 5) tem hoje o item “Pacientes na Clínica Hoje”. Com D-CM-031, o item que abre a tela de Pacientes em procedimento precisa de nome e de comportamento definidos naquela funcionalidade. Ideia do Designer (invenção): chamá-lo “Pacientes em procedimento”, igual ao painel. | Aguarda o solicitante (outra funcionalidade). |
| P-CM-037 | Conformidade SBIS das prescrições e do idioma (RequisitosSBISv5.2 ambulatorial.xlsx). (1) ECF.16.01(c) diz que o sistema não deve permitir que outros profissionais, além do autor, vejam um registro em aberto. O toggle “Todos” mostra a prescrição ainda não assinada de um colega a qualquer médico, e “Meus” também inclui o médico assistente, que não é o autor. A decisão D-CM-036 (d) registrou que “Meus” satisfaz o requisito; a Especificação citava outro item, ECF.16.01(e) (lista com todos os registros em aberto), que a Central cobre só em parte, porque lista as prescrições até o fim da janela de assinatura. (2) ECF.17.01: o card de prescrição não mostra o médico prescritor. (3) ECF.17.18 diz “obrigatoriamente em português do Brasil” e não fala de outros idiomas; que en-US e es-419 fiquem fora da avaliação (D-CM-036 b) é uma leitura do Designer. Ideias do Designer (invenção): levar o conflito entre “Todos” e ECF.16.01(c) a quem conhece a avaliação da SBIS antes de decidir; se houver conflito, limitar “Todos” às prescrições já assinadas ou em revisão. | Aguarda o solicitante. |
| P-CM-038 | Chave id: da busca. D-CM-036 (c) diz que a chave existe e será mostrada na certificação. Mas ela não está especificada: não há contrato do endpoint, mapeamento de banco, texto de ajuda nem formato (por exemplo, id:0012345), e a massa de teste não tem número de prontuário. O protótipo ainda compara o texto digitado com o prontuário na busca comum, o que contraria a decisão. Pergunta: quer que eu especifique a chave id: (contrato, banco, teste)? Ideia do Designer (invenção): especificar só o necessário para a demonstração e tirar o prontuário da busca comum no protótipo. | Aguarda o solicitante. |
| P-CM-039 | Cartão da prescrição quando a infusão já começou. Uma prescrição “a assinar” com a infusão iniciada aparece como “3h00 atrasada”, em vermelho; o médico pode entender que ainda não foi aplicada, quando o problema real é “paciente em infusão sem assinatura”. Já a prescrição “a revisar” com a infusão iniciada some da lista (D-CM-039), embora seja falha parecida (revisão não feita antes da administração). E uma assinatura feita depois da hora da aplicação conta como “dentro da janela”, sem nenhum aviso ao médico. Ideias do Designer (invenção): (a) com infusão iniciada, trocar o texto por “Em aplicação sem assinatura”, mantendo o chip vermelho; (b) manter a “a revisar” com infusão iniciada na lista, com a marca “revisão não feita”; (c) avisar, na tela de assinatura, quando a aplicação já passou ou já começou. | Aguarda o solicitante. |
| P-CM-040 | Prescrição vencida só sai da lista se for assinada ou revisada. D-CM-033 diz que a correção é da Recepção (cancelar a agenda ou marcar falta). Mas as consultas de 4.6 e 4.7 não olham a situação da agenda (Agenda.Situacao): só Prescricao.Situacao e Agenda.RemovidoEm. Se cancelar a agenda ou marcar falta não cancelar a prescrição nem preencher RemovidoEm, a prescrição continua na lista e em “Urgentes”. Além disso, as mais atrasadas ficam no topo e podem esconder a que está a 45 minutos da aplicação. Pergunta: cancelar a agenda ou marcar falta cancela a prescrição no sistema? Ideias do Designer (invenção): (a) excluir da lista as agendas canceladas ou com falta (Agenda.Situacao fora de A/V); (b) ordenar as vencidas há mais de alguns dias no fim da lista; (c) avisar ao assinar uma vencida: “a aplicação prevista passou há N dias”. | Aguarda o solicitante (a pergunta sobre o efeito da Recepção). |
| P-CM-041 | Textos a avaliar (as sugestões são invenção do Designer). “30 dias atrasada” e “3h00 atrasada” soam estranhos, porque “atrasada” fica colado a “dias” e a “3h00”; alternativa: “atrasada há 3h00”, “atrasada há 30 dias”. “sem tempo previsto” pode ser lido como “sem horário”; o que falta é a duração da infusão na prescrição; alternativa: “duração da infusão não informada” (en-US: “Duration not set”). A confirmação de resolver ou descartar não diz que não dá para desfazer (D-CM-014); alternativa: acrescentar “Isso não pode ser desfeito.” “Completo” e “Finalizado” parecem sinônimos em pt-BR; a diferença é “infusão terminada, ainda sem alta” × “alta registrada”; alternativa: “Infusão concluída” × “Alta dada” (en-US: “Infusion complete” × “Discharged”). Em “Completo”, o horário do card é o do início do atendimento; a Especificação não diz isso. | Aguarda o solicitante. |
| P-CM-042 | Divergências técnicas menores, sem efeito na massa de teste atual. (1) O protótipo não exige Situacao = 'V' nos status Finalizado, Completo e Em aplicação, como exige o Mapeamento. (2) progress nulo tem dois significados (prescrição sem tempo de aplicação; atendimento sem início) e o contrato não traz o tempo de aplicação; o protótipo distingue os dois, o contrato não. (3) Não está dito se o painel mostra procedimentos cancelados (o status existe; o indicador só conta agendas A e V). (4) Não está dito se o front recalcula “45min restantes” entre as atualizações automáticas de 5 minutos; o protótipo recalcula. (5) Com exatamente 0 minuto restante, o texto é “0min restantes”, embora a hora tenha passado. (Os itens 6 a 8 e a segunda parte do item 3 foram decididos em D-CM-052.) Ideia do Designer (invenção): tratar cada item como tarefa técnica pequena, depois de decidir P-CM-040 e P-CM-039. | Aguarda o solicitante (priorizar). |
| P-CM-052 | Conversa.IdEmpresa deveria guardar o IdChClinica, e não o IdEmpresa? Você achou que o ideal seria IdChClinica e pediu para decidir depois. Hoje o campo guarda SegEmpresa.IdEmpresa (D-CM-069), e a Central chega à clínica por SegEmpresa.IdEmpresa → Clinica.IdEmpresa → IdChClinica. Se mudar, a mensageria (GescomMensageria.sql: Conversa, ConversaDestinatario, ConversaLeitura, Mensagem, ConversaAcao, OutboxEvento, Equipe e EquipeMembro, com chaves compostas) e o filtro de 4.8 mudam. Nada alterado. | Adiada pelo solicitante. |
| P-CM-057 | SBIS ECF.17.04 (eventos em ordem cronológica) com a nova ordem das conversas. A ordem anterior foi conferida e aceita (D-CM-051). A nova (D-CM-087) usa a data mais recente entre a última mensagem e o prazo, e o prazo não é um evento ocorrido; a Mensageria classifica o item como atendimento parcial (lista em ordem de prioridade; mensagens de cada conversa na ordem de envio). Vale a mesma classificação na Central? | Aberta |
Histórico de Versões
- v1.20 (29/10/2026) — Abertura da série v6.0 (ver 01-Definição v6.0). A série v5 foi fechada na v5.20 / Registro v1.19, que foi para desenvolvimento. Nenhuma decisão, escolha ou questão nova ou alterada: tudo o que estava em aberto na v1.19 segue em aberto (escolhas E-CM-004, 018, 019, 021, 024, 027, 028, 029, 032, 033, 048, 050 e 051; questões P-CM-003, 007, 026, 035 a 042, 052 e 057). A numeração D/E/P não é reaproveitada; os próximos códigos livres são D-CM-091, E-CM-052 e P-CM-058.
- v1.19 (29/10/2026) — Resposta do solicitante: D-CM-090 (nomes técnicos
urgencyLeveletimeIndicator). A numeração D/E/P não é reaproveitada. - v1.18 (29/10/2026) — Respostas do solicitante: D-CM-088 (grau de urgência, ordem pelo grau e horário relativo no painel de Mensagens) e D-CM-089 (botão “Resolvido” fora do card). Nova escolha: E-CM-051. D-CM-085 recebe a nota de que o botão do card foi retirado. A numeração D/E/P não é reaproveitada.
- v1.17 (28/10/2026) — Respostas do solicitante: D-CM-086 (E-CM-049 confirmada) e D-CM-087 (mudanças do painel de Mensagens vindas da Mensageria). D-CM-051 recebe nota de substituição. Sai E-CM-049. Nova escolha: E-CM-050 (detalhes do card de conversa). Nova questão: P-CM-057 (ECF.17.04 com a nova ordem). A numeração D/E/P não é reaproveitada.
- v1.16 (28/10/2026) — Respostas do solicitante: D-CM-084 (“Aguardando recepção”) e D-CM-085 (botões pela seção 12 do Design System). E-CM-004 fica restrita aos toggles. Nova escolha: E-CM-049 (primário do modal de mensagem e botões destrutivos). A numeração D/E/P não é reaproveitada.
- v1.15 (27/10/2026) — Respostas do solicitante às escolhas e questões da v1.14. Novas decisões: D-CM-077 (E-CM-046 confirmada), D-CM-078 (E-CM-047 confirmada), D-CM-079 (status do procedimento em chip), D-CM-080 (troca do formato de
statusno mesmo deploy), D-CM-081 (indicadorEstadoAgendaConsultadescontinuado depois), D-CM-082 (nomes “Em atendimento”, “Em preparo” e “Em aplicação”) e D-CM-083 (proveniência retirada do corpo dos documentos). Saem E-CM-046, E-CM-047, P-CM-054, P-CM-055 e P-CM-056. Nova escolha: E-CM-048 (posição do chip no card de procedimento). A numeração D/E/P não é reaproveitada. - v1.14 (27/10/2026) — Respostas do solicitante sobre a proposta “Cores de status por tema” da equipe de front. Novas decisões: D-CM-073 (cores e nome do status vindos da API, tabelas
DomEstadoAgendaConsultaeDomEstadoAgendaProcedimento, cores globais), D-CM-074 (administeredno lugar decompleted), D-CM-075 (avatar com iniciaisneutral-darkersobre a cor do status) e D-CM-076 (card cancelado com textos riscados, exceto o chip). Novas escolhas: E-CM-046 (procedimento cancelado: status em texto sem risco, avatar neutro) e E-CM-047 (caminhos dos endpoints mantidos). Novas questões: P-CM-054 (status do procedimento em chip), P-CM-055 (indicadorEstadoAgendaConsulta) e P-CM-056 (transição do contrato destatus, achado da Revisão por Dois Críticos). D-CM-030 e D-CM-042 recebem nota de substituição. A numeração D/E/P não é reaproveitada. - v1.13 (26/10/2026) — Respostas do solicitante às questões P-CM-050 (item a) e P-CM-053. Novas decisões: D-CM-070 (o médico não perde o acesso ao paciente, só às agendas e prescrições da clínica;
Paciente.IdChClinicanão afeta o médico e será filtro do administrativo e de outras funções), D-CM-071 (nome do campo deSegEmpresa: o do DDL) e D-CM-072 (Clinica.FusoHorariodescontinuada, registrada no Log). D-CM-068 e D-CM-069 recebem notas de correção. Saem P-CM-050 e P-CM-053. Segue em aberto P-CM-052 (adiada pelo solicitante). A numeração D/E/P não é reaproveitada. - v1.12 (26/10/2026) — Respostas do solicitante às escolhas e questões da v1.11. Novas decisões: D-CM-067 a D-CM-069 (E-CM-034 confirmada: “atende” = clínicas a que o usuário tem acesso; a Agenda do Médico filtra pelas mesmas clínicas e quem perde o acesso não vê mais agendas nem pacientes da clínica;
Conversa.IdEmpresa=SegEmpresa.IdEmpresae fonte do fuso). Saem: E-CM-034 (D-CM-067) e P-CM-051 (D-CM-068); P-CM-050 fica só com o item (a). Novas questões: P-CM-052 (IdChClinicana mensageria, adiada pelo solicitante) e P-CM-053 (pacientes de clínica sem acesso). A numeração D/E/P não é reaproveitada. - v1.11 (26/10/2026) — Resposta do solicitante ao item (d) de P-CM-048 (explicado em P-CM-049): nas duas telas, Central e Agenda do Médico, o médico vê só as clínicas em que atende. Nova decisão: D-CM-066 (substitui nesse ponto D-CM-050 e D-CM-060; marcas incluídas nas duas linhas). E-CM-028, E-CM-029 e E-CM-033 ajustadas. Nova escolha do Designer: E-CM-034 (onde está “atende” no banco). Sai: P-CM-049 (respondida). Nova questão: P-CM-051 (filtro explícito na Agenda). A numeração D/E/P não é reaproveitada.
- v1.10 (26/10/2026) — Respostas do solicitante às escolhas e questões da v1.9. Novas decisões: D-CM-061 a D-CM-065 (E-CM-030 confirmada; “hoje” das janelas de prescrição no fuso da clínica logada; itens (a) e (b) de P-CM-048 como propostos; clínica nos cards de mensagem; ligação das clínicas por
SegEmpresaeClinica, com os parâmetros porIdChave=IdChClinica). Saem: E-CM-030 (D-CM-061), E-CM-031 (substituída por D-CM-062 e E-CM-032) e P-CM-048 (resolvida, com o item (d) reescrito em P-CM-049). Novas escolhas do Designer: E-CM-032 e E-CM-033. Novas questões: P-CM-049 (Agenda do Médico, explicada com exemplo, pois o solicitante não entendeu o item (d)) e P-CM-050 (três conferências). Os padrões 1 e 7 foram conferidos (D-CM-006, D-CM-037). A numeração D/E/P não é reaproveitada. - v1.9 (26/10/2026) — Respostas do solicitante às questões da v1.8. Novas decisões: D-CM-055 a D-CM-060 (E-CM-020 aprovada; chips em peso regular 400; campo em repouso mantém
neutral-light; selo “Atrasado” e número do indicador aprovados; prescrição já assinada não precisa ser assinada de novo; escopo do cliente inteiro para médicos e regras por clínica). Saem: E-CM-020, E-CM-025 e E-CM-026 (resolvidas), P-CM-043, P-CM-046 e P-CM-047 (respondidas). E-CM-028 e E-CM-029 ajustadas ao escopo do cliente. Novas escolhas do Designer: E-CM-030 e E-CM-031. Nova questão: P-CM-048. A numeração D/E/P não é reaproveitada. - v1.8 (26/10/2026) — Respostas do solicitante às questões da v1.7 e às perguntas “explique o que é o E-CM-020” e “mostre visualmente” (E-CM-025 e P-CM-043; a mostra visual foi entregue em 26/10/2026 e as duas seguem abertas). Novas decisões: D-CM-047 a D-CM-054 (desempate pelo nome do paciente; E-CM-023 confirmada; erro antes de selecionado; nova versão da prescrição e Central em todas as clínicas do cliente; ordem das mensagens confere com ECF.17.04; itens 3, 6, 7 e 8 de P-CM-042; chip “há 1h20” leve; selo “Atrasado” e número do KPI mais leves). Saem: E-CM-022 (substituída por D-CM-047), E-CM-023 (D-CM-048), P-CM-008 (D-CM-050), P-CM-044 (D-CM-053), P-CM-045 (D-CM-054); P-CM-026 fica só com o item (a); P-CM-042 fica com os itens 1 a 5. E-CM-024 reduzida (D-CM-049). Novas escolhas do Designer: E-CM-026 a E-CM-029. Novas questões: P-CM-046 e P-CM-047. E-CM-020 segue a confirmar (o solicitante pediu só a explicação). A numeração D/E/P não é reaproveitada.
- v1.7 (26/10/2026) — Nova decisão D-CM-046 (anel de foco de 2px; chips de urgência leves, alternativa A; token
--color-field-changed), aplicada na série v5.8. Autorização do solicitante: “quero que essa cor azul seja um token no design system. pode alterar os documentos” (26/10/2026), depois de ver o resultado visual de E-CM-003 e E-CM-004. Saem: E-CM-003 (resolvida) e a parte dos chips de E-CM-004, que fica restrita a botões e toggles. Novas escolhas do Designer: E-CM-023 a E-CM-025. Novas questões: P-CM-043 a P-CM-045. Revisão por Dois Críticos (26/10/2026, técnico e negócio/UX): D-CM-046 reescrita para separar o que o solicitante disse do que o Designer propôs (E-CM-024, E-CM-025); aplicadas as correções nos documentos da série. - v1.6 (21/10/2026) — Nova decisão D-CM-045: o solicitante aprovou (“1. ok / 2. ok”, 21/10/2026) as duas recomendações do Designer para as pendências deixadas pelo crítico técnico na v1.4 (cor do destaque de conversa não lida; tamanho do percentual da barra). O contorno do chip “Urgente” segue em E-CM-004.
- v1.5 (21/10/2026) — Nova decisão D-CM-044 (idioma da clínica e tradução sem queda para pt-BR, DT-011 e DT-012), aplicada na série v5.6.
- v1.4 (14/10/2026) — Nova decisão D-CM-043 (Central alinhada ao Design System de 14/10/2026;
--color-on-primaryincorporado). Autorização do solicitante: “pode ajustar a central do médico” (14/10/2026), depois de aprovar no Design System a regra C8, o novoneutral-puree a incorporação do token. Correção registrada na Especificação v5.5: as linhas “Badge Error” e “Badge Primary” da 2.8 contradiziam a Seção 2.2 e o protótipo e foram alinhadas a eles (não é decisão nova). Revisão por crítico técnico (subagente, Seções 2 a 4 e tokens; a Definição não mudou, sem crítico de negócio): tokens do.htmlconferidos por script contra o Design System (claro 58/58, escuros 41/41, blocos escuros idênticos); linhas novas da 2.8 e contrastes conferidos. Aplicado: comentários de contraste e de cabeçalho do.htmlque ainda citavam valores antigos ou “a incorporar”; link do.htmlno Protótipo .md; menção de E-CM-002 em D-CM-027; irmãos citados no Histórico da Especificação e dos Cenários. Não aplicado, levado ao solicitante: ícone e borda de conversa não lida — a Especificação (2.5 e 2.8) pedeprimary-pure/secondary-pure(1,7:1 e 2,0:1 sobre branco, abaixo de 3:1) e o protótipo usasecondary-dark, sem decisão registrada; tamanho do percentual da barra (2.8 diz 9px; o protótipo usa--font-size-xs, 10px); contorno do chip “Urgente” (2,6:1; segue em E-CM-004). - v1.3 (13/10/2026) — Respostas do solicitante às pendências da v1.2. Novas decisões: D-CM-027 a D-CM-042 (escolhas do Designer confirmadas; escopo “Meus”;
firstTimeem Procedimentos; status de procedimento em ordem e valorescompleted/finished; item do menu para a tela de Pacientes em procedimento; confirmação ao resolver/descartar conversa; “sem tempo previsto”; decisões de conformidade SBIS sobre idioma, busca e “Meus”/“Todos”; janelas de prescrição em dias de calendário; total de “Procedimentos Hoje” inclui finalizados; prescrição com administração iniciada sai de “a revisar”; assinatura na janela dispensa a revisão; texto do atraso em horas e minutos e em dias; contrato comResponse,System/Usere hora no fuso da clínica). Saem como confirmadas ou resolvidas: E-CM-001, 002, 006, 007, 008, 009, 016 e 017; P-CM-002, 004, 006, 009, 010, 023, 024, 025, 028, 029, 030, 031, 032 e 033. Novas escolhas do Designer: E-CM-018 a E-CM-021. Explicadas em linguagem simples e mantidas abertas: P-CM-003, 007, 008; P-CM-026 reduzida aos itens (a) e (e); P-CM-034 resolvida pela própria massa (a planilha salva em 13/10/2026 traz a tag 8 com siglaC.PI,MostrarEm= 38, e a paciente 14 ligada a ela: Carmen mostra IC e depois C.PI, o que só ocorre com “assistenciais primeiro”; a alfabética geral daria C.PI, IC — a sugestão da sigla “ADM” fica sem efeito); novas P-CM-035 (lembrete: parâmetros de assinatura e revisão do sistema atual) e P-CM-036 (nome do item do Menu Lateral). Seguem a confirmar E-CM-003 e E-CM-004. Revisão por Dois Críticos (13/10/2026, técnico e negócio/UX): corrigidos nos documentos os achados factuais (cabeçalhos com o Registro v1.3,isPreferredReviewernos dois tipos, critérios de aceitação da assinatura na janela, citação de E-CM-020,typede 4.7, resíduos de “um clique”, contagem da massa desatualizada); nova E-CM-022 (desempate por identificador); os achados que dependem de decisão do solicitante viraram P-CM-037 a P-CM-042. A numeração D/E/P não é reaproveitada. - v1.2 (10/10/2026) — Respostas do solicitante à v1.1. Novas decisões: D-CM-017 a D-CM-026 (consulta em atendimento além do previsto; “X pendentes (Y atrasadas)”; painel “Pacientes em procedimento”; progresso desde
DhAtendimentoIniUTC; vigência de tag por data; ordem dos chips; janela de “a revisar” em dias de calendário; vencidas ficam; prescrições sem agenda ficam fora; escolhas do Designer confirmadas). Saem como resolvidas ou substituídas: E-CM-005 (por D-CM-023), E-CM-010, 012, 013 e 015 (confirmadas, D-CM-026), E-CM-011 (por E-CM-016), E-CM-014 (por D-CM-021); P-CM-011, 012, 016, 017, 018 (planilha corrigida), 019, 020, 021, 022 e 027. Novas escolhas do Designer: E-CM-016 (“2h atrasada”) e E-CM-017. Questões reescritas em linguagem simples, com exemplo e ideia marcada como invenção: P-CM-023 a P-CM-026; nova P-CM-028. Revisão por Dois Críticos (10/10/2026): corrigidos inconsistências de texto e de SQL (janela de calendário em Cenários e Mapeamento,IS NULL,IN (...), ordenação porminutesRemaining, notas de D-CM-006 e D-CM-013); itens que dependem de decisão viraram P-CM-029 a P-CM-034; os demais achados (acessibilidade, mensagens de erro, textos i18n, ACs faltantes, notas de versão no corpo de documentos antigos) seguem como pendências de revisão e não foram alterados. A numeração D/E/P não é reaproveitada: os códigos que saem deixam lacunas. - v1.1 (09/10/2026) — Respostas do solicitante às questões em aberto da v1.0. Novas decisões: D-CM-013 (prescrição vencida permanece na lista, com tempo negativo e vermelho, e conta como urgente; resolve P-CM-001), D-CM-014 (conversa sem “desfazer” e sem auditoria; resolve a parte de desfazer de P-CM-010), D-CM-015 (progresso por
Prescricao.TempoAplicacao; resolve P-CM-013), D-CM-016 (dica do ícone de 1ª Consulta ao toque; resolve P-CM-014). D-CM-006 corrigida: o padrão da janela de revisão é 1 dia (a v1.0 dizia 2); a planilha de massa passou a ter o parâmetro. Novas escolhas do Designer: E-CM-010 (rótulo do KPI “p/assinar” montado no front com a janela enviada pelo backend; resolve P-CM-015), E-CM-011 a E-CM-013. Questões reescritas com ideias do Designer, marcadas como invenção, para o solicitante escolher: P-CM-011 (consulta em atendimento que passa do previsto), P-CM-012 (atrasadas dentro das pendentes), P-CM-016 (nome do painel). Novas: P-CM-017 (início da contagem do progresso) e P-CM-018 (nome do parâmetro na planilha de massa). Revisão por Dois Críticos (um técnico, outro de negócio e UX): achados aplicados nos demais documentos da v5.2; os que dependem de decisão do solicitante viraram P-CM-019 a P-CM-027. Novas escolhas do Designer: E-CM-014 (limite do fim da vigência de tag) e E-CM-015 (arredondamento dehoursRemaining). P-CM-005 saiu: a divergência era só de texto no Mapeamento, que a v4.46 já havia resolvido (prescritor ou médico assistente nas três métricas); o texto foi corrigido. - v1.0 (09/10/2026) — Criação do documento a pedido do solicitante (“tente separar as decisões do histórico”). Reúne as decisões de 08 e 09/10/2026 da Central do Médico (D-CM-001 a D-CM-012), as escolhas do Designer a confirmar (E-CM-001 a E-CM-009) e as questões em aberto (P-CM-001 a P-CM-016, as de 010 a 016 vindas da Revisão por Dois Críticos). Decisões anteriores à v5.0 não foram migradas: nos Históricos elas vêm entrelaçadas com a mudança que provocaram, e extraí-las perderia o contexto.