# Central do Médico — mudanças da v5: guia para desenvolvimento **Para quem é:** time de desenvolvimento (back-end, banco e front-end) que já implementou a Central do Médico a partir dos documentos da série v4 e precisa saber o que mudar para chegar à v5.20. **Base de comparação (o que foi desenvolvido):** Definição v4.42, Especificação v4.37, Mapeamento de Banco de Dados v4.48 (arquivos em `Histórico/`). **Destino:** Definição v5.20, Especificação v5.20, Protótipo v5.20, Mapeamento v5.20, Cenários de Teste v5.20 e Registro de Decisões v1.19 (série v5 fechada em 29/10/2026; os arquivos estão em `Central do Médico (Cockpit)/Histórico/`). **Linha do tempo da v5:** v5.0 abriu em 08/10/2026; v5.1 e v5.2 em 09/10; v5.3 em 10/10; v5.4 em 13/10; v5.5 em 14/10 (só alinhamento de cores ao Design System, sem mudança de regra nem de contrato); v5.6 em 21/10 (idioma da clínica e tradução sem queda para pt-BR — seção 5); v5.7 em 21/10 (só dois detalhes visuais: destaque de conversa não lida e tamanho do percentual da barra — seções 4.5 e 4.6); v5.8 em 26/10 (anel de foco de 2px e chips de urgência leves — seção 4.8; sem mudança de regra, contrato ou schema); v5.9 em 26/10 (desempate por nome do paciente, todas as clínicas do cliente com o campo `clinic`, nova versão de prescrição sem assinaturas, `CHECK` de `Mensagem.Tipo`, selo "Atrasado" e número do KPI mais leves — seções 2, 3.1, 3.3, 4.3, 4.4 e 6); v5.10 em 26/10 (médico vê agendas, prescrições e mensagens de todas as clínicas do cliente, com janelas de prescrição por clínica; campo `clinic` também em `procedures`; chips em peso regular; campo em repouso com `neutral-light`; seções 3.1, 3.2, 4.2, 4.5, 4.6, 4.8, 4.10 e 8); v5.11 em 26/10 (o "hoje" das janelas de prescrição no fuso da clínica logada; clínica também no card de mensagem, com o campo `clinic` em `conversations`; ligação das clínicas do login com a base do cliente por `SegEmpresa` e `Clinica`; seções 2, 3.1, 3.2, 4.2, 4.5, 4.11, 7 e 8); v5.12 a v5.14 em 26/10 (o médico vê só as clínicas a que tem acesso e a Agenda filtra igual; perda de acesso tira agendas e prescrições, não pacientes; nome do campo de `SegEmpresa`; `Clinica.FusoHorario` descontinuada; seções 2 e 4.8); v5.15 em 27/10 (cores e nome do status vindos da API, `administered` no lugar de `completed`, procedimento cancelado com textos riscados; seção 4.12); v5.16 em 27/10 (status do procedimento em chip, troca de formato no mesmo deploy, nomes de `TermoTraducao`; seção 4.12); v5.17 em 28/10 (botões pela seção 12 do Design System, "Aguardando recepção"; seção 4.14); v5.18 em 28/10 (painel de Mensagens alinhado à Mensageria; seção 4.13). **Situação:** v1.19, 29/10/2026 — **versão final e fechada.** A v5.20 foi para desenvolvimento e este guia não recebe mais mudanças. O que mudar a partir da v6.0 está em `Central do Médico - mudanças da v6 - guia para desenvolvimento.md`. **Como ler.** Este documento é um resumo de diferenças, não substitui a especificação: a regra completa, os critérios de aceitação e os SQLs estão nos documentos v5.5, citados em cada item. As citações "v5.5" nas linhas "Fonte" indicam a versão em que o item foi conferido; o que mudou nas v5.6, v5.7, v5.8, v5.9 e v5.10 está nas seções 2, 3.1, 3.2, 3.3, 4.2, 4.3, 4.4, 4.5, 4.6, 4.8, 4.10, 5 e 6. Cada mudança traz o código da decisão no Registro de Decisões: - **D-CM-nnn** — decidido pelo solicitante. Pode implementar. - **E-CM-nnn** — escolha do Designer, ainda a confirmar pelo solicitante. Implemente, mas saiba que pode mudar. - **[PROPOSTA]** — proposta do Designer (invenção), sem decisão. Não tratar como requisito. - **P-CM-nnn** — pergunta em aberto. Está listada na seção 8; algumas podem alterar código já feito. --- ## 1. Resumo por camada | Camada | O que muda | Seção | |---|---|---| | Banco | Campo novo `ClienteEmpresa.FusoHorarioOficial` (IANA) no lugar de `FusoOficial`; filtro `RemovidoEm IS NULL` em todas as leituras; `Agenda.Data` sai de uso; seed de `PrescricaoTempoAssinatura`; índice proposto; v5.9: `CHECK` de `Mensagem.Tipo` só com `'Response'` (a aplicar) | 2 | | Back-end — contrato | Ids inteiros (não `uuid`); `tags` viram objetos; campos novos `elapsedMinutes`, `overtime`, `minutesRemaining`, `isPreferredReviewer`, `firstTime` (procedimentos), `toSignWindowDays`; novos status de procedimento; `startTime` de procedimentos em "HH:mm"; `sourceType` e `type` de mensagem com novos valores | 3.1 | | Back-end — regras | Janelas de prescrição em dias de calendário; assinatura dentro da janela dispensa revisão; administração iniciada retira só "a revisar"; ordenação por minutos; tags em duas origens com vigência por data; diagnóstico com início do prontuário; progresso por `TempoAplicacao`; funções de status em ordem | 3.2 a 3.9 | | Front | Painel "Pacientes em procedimento"; ícone de 1ª Consulta; "há 1h20"; textos de tempo da prescrição; confirmação ao resolver/descartar; faixa de sem conexão (o polling de 1 e 5 minutos já existia na v4.37); seletor de tema; botões, avatar e toggle com novos tokens; acessibilidade | 4 | | i18n | Chaves novas, alteradas e removidas (tabelas completas) | 5 | | Tema e cores | Na v5.15, cores de status vindas da API (`status.colors`, classes `.chip-status` e `.avatar-status`); tokens `--color-on-primary`, `--color-first-visit`; valores do Design System de 14/10/2026; na v5.8, anel de foco de 2px e chips de urgência leves (Design System de 26/10/2026) | 6 | | Testes | Cenários v5.5; data-base 23/09/2026 12:00; limites da planilha de carga | 7 | --- ## 2. Banco de dados e parâmetros Fonte: Mapeamento v5.5, "Campos novos", "Índices" e "Seeds da Funcionalidade"; Log de Mudanças Estruturais do Banco de Dados (07/10/2026). | Item | Antes (v4) | Agora (v5.5) | Decisão | |---|---|---|---| | Fuso da clínica | `ClienteEmpresa.FusoOficial` (`smallint`, deslocamento) | `ClienteEmpresa.FusoHorarioOficial` (`varchar(64)`, IANA, ex.: `America/Sao_Paulo`). Campo novo em `IpSeguranca`; `NOT NULL` depois de preencher as clínicas existentes. Todo "hoje" e todo horário exibido usam esse fuso. **Migração a criar** (Log de Mudanças Estruturais, 07/10/2026) | Decidido pelo solicitante na Agenda do Médico | | Exclusão lógica | Não havia regra geral | Toda leitura filtra `RemovidoEm IS NULL` nas tabelas que têm o campo: `Agenda`, `Paciente`, `PEP`, `PEPDiagnostico`, `ProgramaApoio`, `ProgramaApoioPaciente`. **Não** têm o campo: `Prescricao`, `PacienteFoto`, `PEPProgramaApoioPaciente` — nelas não filtrar | Regra de todo o sistema (início da Seção 4 do Mapeamento) | | `Agenda.Data` | Os Mapeamentos v4.x já filtravam o dia por `DhAgendaIniUTC`; `Agenda.Data` não aparece neles | Será descontinuado: nenhuma consulta nova usa `Agenda.Data`; usar `Agenda.DhAgendaIniUTC` convertido para o fuso da clínica. Só a massa de teste e o script `UPDATE DATAS` ainda a tocam | DT-002 (Decisões Transversais, 10/10/2026) e Log de Mudanças Estruturais de 10/10/2026 | | Janela de "a revisar" | Parâmetro `PrescricaoTempoRevisao` (**[PROPOSTA]**, janela contínua a partir de agora, `DATEADD(DAY, X, SYSDATETIMEOFFSET())`) | Parâmetro **já existente** `NumeroDiasRevisaoPrescricoes` (`IpParametro`/`IpParametroChave`), em dias de calendário. Padrão 1 dia no Gemed 2.1 quando a linha não existe (o sistema atual assume 2). **Não criar** `PrescricaoTempoRevisao` | D-CM-006, D-CM-023, D-CM-037 | | Janela de "a assinar" | `PrescricaoTempoAssinatura` (**[PROPOSTA]**, 7 dias contínuos) | `PrescricaoTempoAssinatura` continua **[PROPOSTA]**, mas agora em dias de calendário. Padrão 7 dias. Aplicar o seed em todo cliente, mesmo existindo o padrão no código: `IpParametro` (`IdParametro` = `PrescricaoTempoAssinatura`, `Dominio` NULL, `UsuarioControla` `S`, `Tipo` `N`, `Descricao` = "Dias de calendário a partir de hoje em que prescrição nunca assinada aparece em "a assinar"", 91 caracteres) e `IpParametroChave` (`IdChave` = id da clínica, `Valor` = `7`, `IdChave2` NULL). **A `Descricao` da v4.48 tinha 123 caracteres, acima do `varchar(100)`: use a da v5.5.** O valor é lido com `COALESCE((SELECT TRY_CONVERT(int, ipc.Valor) ...), padrão)`; valor não numérico cai no padrão (a v4.48 lia `ipc.Valor` direto) **Não criar** `PrescricaoValidadeAssinatura` (conceito de assinatura vencida abolido desde a v4.39) | D-CM-037 | | `Mensagem.Tipo` (v5.9) | `CHECK` aceita `'Initial'`, `'Update'`, `'Reply'` e `'Response'` (segundo a Biblioteca de Schema (DDL)) | `CHECK` aceita **só `'Response'`** (D-CM-052). **A aplicar no banco**; quem grava mensagens com os outros valores (primeira mensagem, alertas do sistema) precisa passar a gravar `'Response'`; impacto fora da Central não levantado. Registrado no Log de Mudanças Estruturais (26/10/2026) | D-CM-052 | | Ligação das clínicas (v5.11) | — | O login é de um `Cliente`; as clínicas dele são linhas de `ClienteEmpresa` (IpSeguranca), e os dados ficam no banco do cliente. Cadeia: `ClienteEmpresa.Id` = `SegEmpresa.SegurancaClienteEmpresaId` → `SegEmpresa.IdEmpresa` → `Clinica.IdEmpresa` (chave estrangeira real) → `Clinica.IdChClinica`, que é o valor de `Agenda.IdChClinica` e de `IpParametroChave.IdChave`. `{IdClinica}` nas consultas é o `IdChClinica` da clínica logada. O campo de `SegEmpresa` é `SegurancaClienteEmpresaId`, o nome do DDL (D-CM-071). A coluna `Clinica.FusoHorario` está descontinuada (D-CM-072): não use; o fuso vem de `ClienteEmpresa.FusoHorarioOficial`. Padrões por clínica: `NumeroDiasRevisaoPrescricoes` = 1, `PrescricaoTempoAssinatura` = 7 | D-CM-065 (D-CM-006, D-CM-037), D-CM-071, D-CM-072 | | Clínicas em que o médico atende (v5.12) | — | O médico vê só as clínicas do cliente em que atende, na Central e na Agenda. **Confirmado (v5.13, D-CM-067):** são as clínicas a que o usuário tem acesso (`ClientePerfilAcessoUsuario`, o mesmo critério de `ClinicVisible()` da Agenda). A aplicação monta `{ClinicasDoMedico}` (`IdEmpresa`, `IdChClinica`) e filtra: consultas e procedimentos por `Agenda.IdChClinica IN` essa lista; prescrições pelo `INNER JOIN` com `{LimitesPorClinica}`, que tem uma linha por clínica da lista; conversas por `Conversa.IdEmpresa IN` a lista; ações sobre conversa de outra clínica são recusadas. Quem perde o acesso a uma clínica deixa de ver as agendas e as prescrições dela, mas **não perde o acesso aos pacientes** (D-CM-068, D-CM-070); a Agenda do Médico tem o mesmo filtro (Mapeamento da Agenda v1.10). "Em Tratamento", adesão ao protocolo e busca de pacientes seguem sem filtro por clínica, e `Paciente.IdChClinica` não é usado pela Central (o solicitante informou que será filtro do administrativo e de outras funções, fora deste escopo). SQL em Mapeamento, início da Seção 4 | D-CM-066, D-CM-067, D-CM-068, D-CM-070 | | Índice | — | **[PROPOSTA]** `IX_Agenda_IdChRecurso_TipoAgenda_DhAgendaIniUTC`, o mesmo da Agenda do Médico (a confirmar com o time de banco). A Central lê mais colunas de `Agenda`; ajustar o `INCLUDE` desse índice, sem criar um segundo. Os endpoints de procedimentos (4.3, 4.4) filtram por tipo e dia, sem o médico — o índice não os atende como está | Mapeamento, "Índices" | **Conferir antes do deploy:** a linha de `IpParametro` de `NumeroDiasRevisaoPrescricoes` existe nas bases novas? A aba `IpParametro` da planilha de carga traz a **definição** de `PrescricaoTempoRevisao` (sem valor por clínica e sem uso) — ela **não** deve ser criada em produção. --- ## 3. Back-end: mudanças por endpoint ### 3.1 Mudanças de contrato (tabela única) Fonte: Especificação v5.5, Seção 2.9. "Antes" é a Especificação v4.37. | Endpoint | Campo | Antes | Agora | |---|---|---|---| | `appointments`, `procedures`, `prescriptions`, `patients/search` | `id`, `patient.id` | `uuid` | **inteiro**. `appointments`: `id` = `Agenda.IdAgenda`, `patient.id` = `Agenda.IdPaciente`. `procedures` e `prescriptions`: `id` = `Prescricao.IdPrescricao` (**não** `Agenda.IdAgenda`), `patient.id` = `Prescricao.IdPaciente`. `patients/search`: `id` = `Paciente.IdPaciente`. Só os ids de conversa e de mensagem continuam `uuid` | | `conversations` | `patient.id` | `uuid` | inteiro (`Conversa.IdPaciente`; o Mapeamento v4.48 escrevia `Conversa.PacienteId`). `patient` é `null` também quando o paciente tem `RemovidoEm` | | `appointments`, `procedures` | `tags` | lista de strings | lista de objetos `{ code, description, color }`, já na ordem de exibição (seção 3.6) | | `appointments` | `elapsedMinutes`, `overtime` | não existiam | novos (seção 3.5) | | `appointments` | `firstTime` | já existia, como `char` `'S'/'N'` de `Agenda.PrimeiraConsulta`; a tag `1a_consulta` também vinha em `tags` | **booleano** (`= 'S'`); a 1ª Consulta **sai de `tags`** (D-CM-003) | | `appointments`, `procedures` | `patient.preferredName` | o Mapeamento v4.48 escrevia `prefferedName` (erro de digitação) | conferir que o JSON emite `preferredName` | | `appointments` | `startTime`, `endTime` | já eram "HH:mm" | sem mudança (a mudança de formato vale só para `procedures`) | | `procedures` | `startTime` | ISO em UTC | **"HH:mm" no fuso da clínica**, como em `appointments` (D-CM-042) | | `procedures` | `firstTime` | não existia | novo, booleano (`Agenda.PrimeiraConsulta = 'S'`, D-CM-029) | | `procedures` | `progress` | percentual de `Agenda.Tempo` | percentual de `Prescricao.TempoAplicacao`; **`null`** quando a prescrição não tem tempo de aplicação (seção 3.9) | | `procedures` | `status` | `scheduled`, `waiting`, `checked`, `preparation`, `administering`, `administered`/`completed` (a v4 era inconsistente entre Especificação e Mapeamento), `finished`, `canceled` | Na v5.15, `status` é objeto `{ domain, name, colors }` (seção 4.12); `domain` = `scheduled \| waiting \| checked \| preparation \| administering \| administered \| finished \| canceled`. De v5.4 a v5.14 o valor foi `completed`; na v5.15 volta a `administered` (D-CM-074) | | `prescriptions` | `minutesRemaining` | não existia | novo, inteiro, negativo quando a hora da aplicação já passou | | `prescriptions` | `hoursRemaining` | horas | inteiro **truncado em direção a zero** (D-CM-026) | | `prescriptions` | `isPreferredReviewer` | só em `to_review` na Especificação v4.37 (o Mapeamento v4.48 já dizia os dois tipos) | presente nos **dois** tipos (`to_sign` e `to_review`) | | `prescriptions` | `type` | janela contínua | filtrado pelas janelas de calendário (seção 3.2) | | `prescriptions` | ordenação | `hoursRemaining` crescente | `minutesRemaining` crescente; desempate pelo **nome do paciente** (nome social, se houver; senão o civil; sem diferenciar maiúsculas e acentos) e, para o mesmo nome, por `id` crescente (D-CM-047, E-CM-027; v5.9) | | `appointments` | `clinic` | não existia | **novo (v5.9)**, string ou `null`: nome curto da clínica (`Agenda.IdChClinica` → `Chave.Descricao`); `null` quando o **médico atende em uma só clínica** (`ClinicVisible()` da Agenda do Médico; v5.12: entre a v5.10 e a v5.11 a regra era "o cliente tem uma só clínica"). O endpoint devolve as consultas das **clínicas em que o médico atende**, filtradas por `{ClinicasDoMedico}` (D-CM-066, E-CM-028, D-CM-067) | | `prescriptions` | `clinic` | não existia | **novo (v5.9)**, mesma regra, a partir de `Prescricao.IdAgenda` → `Agenda.IdChClinica`. Prescrições das clínicas em que o médico atende; `reviewScope = all` = todos os médicos dessas clínicas (D-CM-066, E-CM-029). Os parâmetros das janelas são os da clínica de cada prescrição (D-CM-060; seção 3.2) | | `procedures` | `clinic` | não existia | **novo (v5.10)**, string ou `null`, mesma origem e regra de `appointments.clinic` (`Prescricao.IdAgenda` → `Agenda.IdChClinica`). O endpoint devolve os procedimentos das clínicas em que o médico atende (D-CM-061, D-CM-066) | | `conversations` | escopo | só a clínica da sessão (`Conversa.IdEmpresa`) | **filtro pelas clínicas do médico (v5.12)**: `Conversa.IdEmpresa IN` as clínicas em que o médico atende; o vínculo continua pelo destinatário (D-CM-066; na v5.10 e na v5.11 não havia filtro de clínica, D-CM-060) | | `conversations` | `clinic` | não existia | **novo (v5.11, D-CM-064)**, string ou `null` quando o médico atende em uma só clínica: `Conversa.IdEmpresa` → `Clinica.IdEmpresa` → `Clinica.IdChClinica` → `Chave.Descricao` (E-CM-033). `Conversa.IdEmpresa` é o `SegEmpresa.IdEmpresa` (D-CM-069; P-CM-052) | | `kpis/prescription-alerts` | `toSignWindowDays` | não existia | novo: a janela de assinatura da clínica, em dias (`PrescricaoTempoAssinatura`, padrão 7). O front monta o rótulo "p/assinar (próx. N dias)" com ele. O campo `toSignNext7Days` **continua com esse nome**, por compatibilidade, mesmo com a janela configurável | | `kpis/procedures-today` | `total` | já era `count(Situacao IN ('A','V'))` | só esclarecimento, **sem mudança de query** (D-CM-038): inclui completos e finalizados; os três subtotais não precisam somar o total | | `kpis/appointments-today` | `delayed` | — | não conta consulta em atendimento (D-CM-008) | | `conversations` | `sourceType` | `person \| system` | **`User \| System`** (D-CM-042) | | `conversations/{id}` | `messages[].type` | `initial \| reply \| update` | valor único **`Response`** (D-CM-042). Atenção: no banco, o `CHECK` do tipo de mensagem ainda aceita `Initial`, `Update` e `Reply`; deve passar a aceitar só `Response` (D-CM-052, seção 2) | Polling (RN-CM-017, Especificação 2.9; **os intervalos já valiam na v4.37**, o novo é a faixa de sem conexão): **1 minuto** para `appointments`, `conversations` e o KPI `appointments-today`; **5 minutos** para `prescriptions`, `procedures` e os KPIs `procedures-today`, `prescription-alerts` e `in-treatment`. Se uma atualização falhar, o front mantém os últimos dados e mostra a faixa de sem conexão (seção 4.7). Esse intervalo é do front; não há push nem websocket. ### 3.2 Janelas de prescrição: "a revisar" e "a assinar" Fonte: Mapeamento 4.6 e 4.7; Definição RN-CM-020; D-CM-023, D-CM-037. **Mudança central:** as duas janelas deixam de ser contínuas (hoje + N × 24 h) e passam a ser **dias de calendário no fuso da clínica logada** (v5.11, D-CM-062). "N dias" é o dia de hoje mais N dias, até 23:59:59, e não há limite para trás (as já vencidas continuam na lista). A aplicação (não o SQL) calcula os limites, para respeitar mudança de horário de verão: - **Por clínica (v5.10, D-CM-060; fuso v5.11, D-CM-062, E-CM-032):** cada clínica do cliente tem os próprios parâmetros N e S, e a prescrição segue os da clínica dela (`Agenda.IdChClinica`). A aplicação monta, a cada chamada, uma tabela `{LimitesPorClinica}` com uma linha por clínica de `{ClinicasDoMedico}` (v5.12, D-CM-066; o `INNER JOIN` com ela é também o filtro de clínicas) (`IdChClinica`, `N`, `S`, `LimiteRevisaoUTC`, `LimiteAssinaturaUTC`; padrões N = 1 e S = 7 quando não há linha em `IpParametroChave`) e as consultas de 4.6 e 4.7 a ligam à prescrição por `a.IdChClinica`. **O "hoje" e o fim do dia de cada janela são os do fuso da clínica em que o usuário está logado** (decisão do solicitante), também para prescrições de clínicas de outro fuso: o médico vê um só dia em toda a tela. O fuso de cada clínica da prescrição não entra no cálculo. - `LimiteRevisaoUTC` = meia-noite local do dia (hoje + N + 1), no fuso da clínica logada, convertida para UTC; N = `NumeroDiasRevisaoPrescricoes` (padrão 1). - `LimiteAssinaturaUTC` = idem com S = `PrescricaoTempoAssinatura` (padrão 7). - Condição no SQL: `Agenda.DhAgendaIniUTC < lc.Limite...UTC`, sem piso (`lc` = a linha da clínica da prescrição). Exemplo (padrão de 1 dia, hoje = dia 10): aplicação no dia 11 às 23:30 entra em "a revisar"; no dia 12 às 00:00, não entra (entra à 00:00 do dia 11). Condições comuns às duas listas e aos três números do KPI: - `Prescricao.Situacao IN ('P','G','A','O')`. Prescrição `Q`, `F`, `E` ou `C` não aparece. - `Prescricao.IdAgenda` obrigatório: prescrição sem agenda fica fora (D-CM-025). - `Agenda.RemovidoEm IS NULL` e `Paciente.RemovidoEm IS NULL`. - Escopo "Meus": `Prescricao.IdChProfissionalMed = {médico logado}` **ou** `Paciente.IdChProfissional = {médico logado}`. "Todos" remove essa restrição, nas duas categorias. O KPI é sempre "Meus", com o mesmo critério (prescritor **ou** assistente) nas três métricas. **Atenção:** o texto "Filtros do endpoint" do Mapeamento v4.48 dizia "apenas prescritor" para `toSignNext7Days` e para a parcela de assinatura de `urgent`, contradizendo as funções do mesmo documento; quem seguiu esse texto precisa corrigir. **"A assinar" (`to_sign`):** nenhuma assinatura existe — nem `PrescricaoAssinatura.TipoAssinatura = 'A'`, nem o par legado `Prescricao.DataAssinaturaPrescricao`/`IdChProfissionalAssinou` (RN-CM-029). Aplicação antes de `lc.LimiteAssinaturaUTC`. Sem filtro de administração iniciada. **"A revisar" (`to_review`):** já assinada por qualquer das duas fontes; aplicação antes de `lc.LimiteRevisaoUTC`; **nenhum** registro `TipoAssinatura = 'R'` jamais registrado (a confirmação de revisão não tem prazo); e as duas exceções abaixo. **Exceção (a) — assinatura dentro da janela de revisão dispensa a revisão (D-CM-040, E-CM-019).** A prescrição não é "a revisar" se existe assinatura `'A'` (ou `DataAssinaturaPrescricao`) com data **igual ou posterior à meia-noite local do dia da aplicação menos N dias**. Exemplo, N = 1 e aplicação no dia 11: assinatura do dia 10 às 00:00 em diante dispensa; assinatura do dia 9 não dispensa. Com aplicação no dia 10, a janela abre no dia 9 às 00:00. - O valor `{InicioJanelaRevisaoLocal}` é **por linha** (depende da `DhAgendaIniUTC` de cada prescrição e do `N` da clínica dela; o fuso é o da clínica logada, `{FusoWindowsLogin}`). - `PrescricaoAssinatura.Data` e `Prescricao.DataAssinaturaPrescricao` são `datetime` sem fuso; a Especificação os trata como **hora local da clínica**. É escolha do Designer **a confirmar com o time de banco** (E-CM-019). A conversão do dia da aplicação usa `AT TIME ZONE` com o nome Windows do fuso, traduzido pela aplicação a partir do IANA. - Consequência visível: assinar uma prescrição cuja aplicação já está na janela de revisão a tira da lista inteira, e o número "P/ assinar" diminui em um (e "Urgentes", se era urgente). Não passa para "a revisar". **Exceção (b) — administração iniciada (D-CM-039, E-CM-018).** `Agenda.DhInfusaoIniUTC` preenchido retira só "a revisar". Uma prescrição "a assinar" com administração iniciada **continua na lista e no número**, de propósito: sem assinatura em procedimento é falha grave de processo e deve ficar visível (D-CM-033, D-CM-039). A correção é da Recepção (cancelar a agenda ou marcar falta), não do médico. **KPI `urgent`** = prescrições "a assinar" mais "a revisar" do médico com menos de 12 h para a aplicação. Classificação por **minutos** (`< 720`), não pelo `hoursRemaining` truncado: 11h59 é urgente mesmo aparecendo como 11. As vencidas contam como urgentes até serem assinadas ou revisadas (D-CM-013, D-CM-024). **Nova versão de prescrição (v5.9, D-CM-050, D-CM-052).** Editar uma prescrição gera uma nova versão; a anterior fica cancelada e, entre as versões, só uma é válida (`Prescricao.Situacao` fora de `P`/`G`/`A`/`O` já a tira das listas). A nova versão nasce **sem assinaturas**: não herda `PrescricaoAssinatura` nem os campos legados (`IdChProfissionalAssinou`, `DataAssinaturaPrescricao`); portanto é "a assinar". A assinatura que dispensou a revisão não vale mais se a aplicação for adiada: a comparação de E-CM-019 é refeita com a nova data, e a prescrição volta **só a "a revisar"**, quando a nova data entrar na janela de revisão. Ela **não** volta a "a assinar": a prescrição já assinada não precisa ser assinada de novo (D-CM-059). ### 3.3 `minutesRemaining`, `hoursRemaining` e ordenação - `minutesRemaining = DATEDIFF(MINUTE, SYSDATETIMEOFFSET(), Agenda.DhAgendaIniUTC)`. - `hoursRemaining = minutesRemaining / 60` com divisão inteira do T-SQL (trunca em direção a zero; 90 min → 1, −90 min → −1). - Ordenação da lista sem `type`: `minutesRemaining` crescente, desempate pelo nome do paciente (D-CM-047) e, para o mesmo nome, por `id` crescente (E-CM-027, **a confirmar**). Vencidas ficam no topo. O `hoursRemaining` sozinho não distingue −40 min de +20 min — por isso a ordenação é pelos minutos. ### 3.4 Textos de tempo da prescrição (calculados no front) Fonte: D-CM-041, D-CM-055. O back-end só envia `minutesRemaining`. | Situação | Regra | Exemplo (pt-BR) | |---|---|---| | Restante, menos de 60 min | minutos | "45min restantes" (D-CM-055) | | Restante, 60 min ou mais | horas truncadas | "8h restantes", "123h restantes" | | Atrasada, menos de 60 min | minutos | "40min atrasada" | | Atrasada, de 60 min a 47h59 | horas e minutos, minutos com dois dígitos | "1h59 atrasada", "3h00 atrasada" | | Atrasada, 48 h ou mais | dias, parte inteira (piso) | "30 dias atrasada"; 59 h → "2 dias atrasada" | Atrasada sempre com o chip vermelho. O corte de chips por urgência (RN-CM-011: crítica `< 12 h`, atenção de 12 h a 24 h, texto simples acima de 24 h) não mudou. ### 3.5 Consultas: `elapsedMinutes`, `overtime`, `delayMinutes` Fonte: Mapeamento 4.1; D-CM-017, D-CM-008. - `elapsedMinutes = DATEDIFF(MINUTE, Agenda.DhAtendimentoIniUTC, SYSDATETIMEOFFSET())` quando `DhAtendimentoIniUTC` não é nulo e `DhAtendimentoFimUTC` é nulo (consulta em atendimento); `NULL` nos demais estados. - `overtime = elapsedMinutes > Agenda.Tempo`; `false` se qualquer um for nulo. Sem tolerância. - `delayMinutes`: sem mudança de regra (0 quando o horário previsto ainda não chegou). - Indicador de consultas: "atrasadas" não conta consulta em atendimento (D-CM-008). - Bloqueios de horário da Recepção (RN-CM-030, RN-AGM-019) são gravados como agenda de consulta com o paciente reservado "B". O filtro `Paciente.Paciente <> 'B'` (via `Agenda.IdPaciente`) em `appointments` e em `kpis/appointments-today` **já existia** desde o Mapeamento v4.48; só a descrição mudou. ### 3.6 Tags (`appointments.tags` e `procedures.tags`) Fonte: Mapeamento 4.1 (mapa de campos e Domínios); D-CM-002, D-CM-021, D-CM-022; RN-CM-025. - **Duas origens, unidas, ambas com join em `ProgramaApoio`:** 1. `ProgramaApoioPaciente` por `IdPaciente` — atribuição no cadastro do paciente; tags de `Finalidade` `D` (administrativas), **inclusive VIP**. 2. `PEPProgramaApoioPaciente` → `PEP` por `PEP.IdPaciente` — atribuição no prontuário; tags de `Finalidade` `A` (assistenciais). A chave de `PEPProgramaApoioPaciente` é `IdPEP` (um registro de PEP leva uma tag). - Se a mesma tag vier das duas origens, aparece uma vez. - **VIP** vem de `ProgramaApoioPaciente`; `Paciente.PacienteVip` **não é lido** (D-CM-002). **Remover** o `UNION` com `Paciente.PacienteVip` (bit = 1 virava a tag `vip`) e o filtro de vigência antigo (`DataInicio <= hoje`, `DataFim` nulo ou `>= hoje`, que não tratava a hora). VIP é exceção ao filtro `MostrarEm` e à vigência da tag. - Filtros das tags de `ProgramaApoio`: `(MostrarEm & 32) = 32` (bit 6, **Agendas** — não o bit da Central do Médico); vigência da própria tag (`DataInicio`/`DataFim`); `RemovidoEm IS NULL`. - **Vigência por data, inclusiva nas duas pontas (D-CM-021):** compara-se só o dia de calendário no fuso da clínica, sem hora. Início hoje ou antes, e fim (se houver) hoje ou depois. Vale para a tag e para a atribuição ao paciente. Para o prontuário usar `PEP.DataInicioUTC`/`DataFimUTC` (`datetimeoffset`, convertidos para o fuso da clínica antes de tomar a data); **`PEP.DataInicio`/`DataFim` não são lidos** (D-CM-009). - **Saída:** `code` = `ProgramaApoio.Sigla`; `description` = `ProgramaApoio.Descricao`; `color` = `ProgramaApoio.Cor` (`#RRGGBB`; ausente ou inválida, o front usa `--color-neutral-lighter`). - **Ordem (D-CM-022):** `Finalidade` `A` antes de `D`; em cada grupo, alfabética pela sigla. A lista já sai ordenada; o front não reordena. - A 1ª Consulta **não é tag**: é `firstTime`. ### 3.7 Diagnóstico (`appointments.patient.diagnosis`) Fonte: Mapeamento 4.1; D-CM-009, D-CM-010. Todos os diagnósticos oncológicos "ativos" (`PEPDiagnostico.Tipo = 'O'`), sem `RemovidoEm` em `PEPDiagnostico` e em `PEP`, **e com `PEP.DataInicioUTC` até o fim de hoje** no fuso da clínica (nulo = vigente desde sempre). Diagnóstico de um PEP que só começa depois de hoje não é retornado. Só o início é avaliado; `PEP.DataFimUTC` não filtra. ### 3.8 Funções de status (D-CM-030, DT-010) As condições são avaliadas **em ordem; vale a primeira que se aplicar**. `Agenda.Situacao` é `NOT NULL`. `AppointmentStatus()` (**também mudou**: na v4.48 a lista não tinha ordem, e `Situacao = 'V'` com fim preenchido e início nulo satisfazia `checked` e `finished` ao mesmo tempo; agora vale `finished`. Origem: Especificação/Mapeamento v5.0 e DT-010): | Ordem | Status | Condição | |---|---|---| | 1 | `canceled` | `Situacao IN ('C','D','F','I','M','O','T')` | | 2 | `finished` | `Situacao = 'V'` e `DhAtendimentoFimUTC` preenchido | | 3 | `consultation` | `Situacao = 'V'`, `DhAtendimentoIniUTC` preenchido, `DhAtendimentoFimUTC` nulo | | 4 | `checked` | `Situacao = 'V'` e `DhAtendimentoIniUTC` nulo | | 5 | `waiting` | `Situacao = 'A'` e `DhChegadaUTC` preenchido | | 6 | `scheduled` | `Situacao = 'A'` e `DhChegadaUTC` nulo | `ProcedureStatus()`: | Ordem | Status | Condição | |---|---|---| | 1 | `canceled` | `Situacao IN ('C','D','F','I','M','O','T')` | | 2 | `finished` (alta) | `Situacao = 'V'` e `DhAtendimentoFimUTC` preenchido | | 3 | `administered` (infusão terminada, sem alta) | `Situacao = 'V'`, `DhInfusaoFimUTC` preenchido, `DhAtendimentoFimUTC` nulo | | 4 | `administering` | `Situacao = 'V'`, `DhInfusaoIniUTC` preenchido, `DhInfusaoFimUTC` nulo | | 5 | `preparation` | `Situacao = 'V'`, `DhAtendimentoIniUTC` preenchido, `DhInfusaoIniUTC` nulo | | 6 | `checked` | `Situacao = 'V'` e `DhAtendimentoIniUTC` nulo | | 7 | `waiting` | `Situacao = 'A'` e `DhChegadaUTC` preenchido | | 8 | `scheduled` | `Situacao = 'A'` e `DhChegadaUTC` nulo | O que mudou: o valor do status 3 é `administered` (D-CM-074; de v5.4 a v5.14 a série usou `completed`, que não deve ser implementado); `finished` ganhou precedência sobre `administered` (a massa tem 23 linhas com alta e `DhInfusaoFimUTC` nulo, que devem ser `finished`); com `DhInfusaoFimUTC` preenchido nunca é `administering`; com início de infusão preenchido e `DhAtendimentoIniUTC` nulo vale `administering`, não `checked`. KPI `procedures-today`: `total` = contagem de `Situacao IN ('A','V')` (inclui completos e finalizados); `inProgress` = `administering`; `waiting` = `waiting` + `checked` + `preparation`; `scheduled` = `scheduled`. `startTime` do procedimento (nome mantido por herança): se finalizado, `DhAtendimentoFimUTC`; senão, se `Situacao = 'V'`, `DhAtendimentoIniUTC`; senão `DhAgendaIniUTC` — sempre convertido para "HH:mm" do fuso da clínica (RN-CM-026, D-CM-042). A ordenação do painel continua pelo horário **agendado**, desempate alfabético pelo nome do paciente (RN-CM-027). ### 3.9 Progresso do procedimento (`progress`) Fonte: Mapeamento 4.3; D-CM-015, D-CM-020, D-CM-034. ```sql CAST(ROUND(DATEDIFF(MINUTE, Agenda.DhAtendimentoIniUTC, SYSDATETIMEOFFSET()) * 100.0 / NULLIF(Prescricao.TempoAplicacao, 0), 0) AS int) ``` `TempoAplicacao` é `numeric(6,0)`, em minutos. `NULL` quando `TempoAplicacao` é nulo ou zero — o front não desenha a barra e mostra "sem tempo previsto". A base **deixou de ser** `Agenda.Tempo`. O contrato não traz o tempo de aplicação; o `null` de `progress` também ocorre em atendimento sem início (P-CM-042, item 2). ### 3.10 Outras mudanças de leitura - **Busca de pacientes (`patients/search`).** O número de prontuário **não é critério da busca comum** (D-CM-036), mas **continua nos resultados** (`medicalRecordNumber`, ECF.03.14). Já era assim no Mapeamento v4.48 e na Especificação v4.37; a decisão só confirma. A chave `id:` (busca pelo prontuário) existirá só para a certificação, **sem contrato, mapeamento nem texto de ajuda ainda** (P-CM-038). Se o back-end já compara o texto digitado com o prontuário, tirar da busca comum. - **Correções de escrita no Mapeamento v4.48 (conferir se o código copiou o erro):** `Prescricao.IdAgenda <> NULL` (nunca verdadeiro) → `IS NOT NULL`; `Agenda.TipoAgenda IN 'Q', 'R'` → `IN ('Q','R')`; `DhAtendimentoFim` (coluna inexistente) → `DhAtendimentoFimUTC`; `Conversa.PacienteId` → `Conversa.IdPaciente`; `RemovidoEm IS NULL` também em `Agenda`, `Paciente` e `PEP` nas duas partes de `PatientInTreatmentCount` e no `TreatmentPlanAdherenceCount` (`kpis/in-treatment`, 4.5). - **Conversas:** resolver e descartar valem para **todos os destinatários** (D-CM-011). Sem "desfazer" e sem texto de auditoria (D-CM-014). Descartar continua sendo `PATCH` (registro append-only, nunca excluído). --- ## 4. Front-end: mudanças por área Fonte: Especificação v5.5, Seções 2.1 a 2.8; Protótipo v5.5 (`03 - Protótipo v5.5.html` ilustra o comportamento; onde divergir da Especificação ou do Mapeamento, vale o documento — ver divergências conhecidas do protótipo na seção 7). Ícones: só Lucide ou react-icons. ### 4.1 Cabeçalho e busca - O menu do avatar tem o seletor de **tema** (Automático, Claro, Escuro; `MSG_themeOptions`) e "Sair". Sem nome, CRM nem especialidade no cabeçalho. Seleção do tema: ver o guia `Tema claro e escuro - guia para desenvolvimento.md`. **Se a escolha é guardada entre sessões não foi decidido** (o Design System traz só uma [PROPOSTA] de guardar no navegador; os Cenários registram a lacuna). - Busca de pacientes: nome, CPF, data de nascimento e nome da mãe. **Prontuário não entra como critério da busca comum** (D-CM-036), mas continua **exibido nos resultados** (ECF.03.14). A comparação ignora acentos. - Busca como combobox/listbox acessível (seção 4.8). ### 4.2 KPI Bar | Card | O que muda | |---|---| | Consultas Hoje | Subtexto passa a "X pendentes (Y atrasadas)"; no singular "1 pendente (1 atrasada)". As atrasadas já estão contadas nas pendentes (D-CM-018). Para leitor de tela: "X pendentes, das quais Y atrasadas" | | Procedimentos Hoje | O número principal inclui os procedimentos já finalizados (D-CM-038; esclarecimento, a query já era assim). O subtexto "X em atendimento · Y aguardando · Z previstos" não precisa fechar a conta. O clique abre a tela de **Pacientes em procedimento** (antes "Procedimentos na Clínica"). Desde a v5.10 conta os procedimentos de todas as clínicas do cliente (D-CM-060) | | Alertas de Prescrição | Subtexto "X p/revisar · Y p/assinar (próx. {n} dias)", com `{n}` = `toSignWindowDays`; no singular "próx. 1 dia". Antes era fixo "próx. 7 dias". Com clínicas de janelas diferentes, `toSignWindowDays` é o da clínica em que o médico está logado (D-CM-063). O número principal fica em `color-error-dark` quando maior que zero (v5.9, D-CM-054, D-CM-058) | | Os quatro cards | Falha do endpoint de KPIs mostra "—" nos valores e não trava os outros painéis. Falha em atualização automática mantém os últimos valores e liga a faixa de sem conexão | ### 4.3 Painel de Consultas | Item | Antes | Agora | Decisão | |---|---|---|---| | 1ª Consulta | chip de texto "1ª Consulta" dentro das tags | **ícone** `circle-number-1` (Tabler; react-icons `TbCircleNumber1`), 18 px, sem fundo, cor `--color-first-visit`, logo depois do nome do paciente. `role="img"` e `aria-label` "1ª Consulta" | D-CM-003 | | Dica do ícone | `title` nativo | dica (`role="tooltip"`) que abre ao passar o mouse **e ao tocar**. O toque abre só a dica e não aciona o card; fecha ao tocar fora (esse primeiro toque só fecha a dica), ao rolar, ao redimensionar e com Esc. **Não fecha sozinha na atualização automática** (polling de 1 min). Com o mouse, fica aberta enquanto o ponteiro estiver sobre o ícone ou sobre a própria dica. Área de toque do ícone de 44 × 44 px | D-CM-016, E-CM-013 confirmada | | Foco de teclado do ícone | — | o ícone **não recebe foco**; "1ª Consulta" já está no nome acessível do card | D-CM-035 | | Ordem do que aparece no card | — | ícone de 1ª Consulta (junto ao nome), tags assistenciais, tags administrativas; o back-end já envia as tags ordenadas | D-CM-022 | | Selo de atraso | — | "Atrasado · Nmin" único, para qualquer consulta atrasada e não iniciada. A Central **não** distingue "Esperando" de "Não chegou" (isso existe só na Agenda do Médico). Selo leve (v5.9): fundo `--color-error-light`, texto e ponto em `--color-error-dark`, sem contorno (5,6:1 no claro, 6,3:1 no escuro); só o ponto do selo pulsa (some com movimento reduzido). A Agenda do Médico mantém o selo preenchido com `--color-alert-fill` | D-CM-004, E-CM-007, D-CM-054, E-CM-026 | | Consulta em atendimento além do previsto | — | quando `overtime` é `true`, mostra ao lado do status "há 1h20" (abaixo de 1 h, "há 45min"), com ícone Lucide `clock-alert`, fundo `color-highlight-light`, sem contorno, texto e ícone `color-highlight-dark` (v5.8; até a v5.7 era fundo `-medium`, contorno e texto `neutral-darker`: o chip usa os mesmos tokens do chip "Atenção", D-CM-046). Some quando a consulta é finalizada. O front monta o texto a partir de `elapsedMinutes`; a partir de 1 h os minutos têm dois dígitos ("há 1h05", "há 2h00"). O nome acessível do card acrescenta "em atendimento há 1h20, além do previsto" | D-CM-017, E-CM-017 confirmada; D-CM-046 | | Diagnóstico | uma lista | todos os diagnósticos oncológicos ativos; um com PEP que começa depois de hoje não vem | D-CM-009, D-CM-010 | | Bloqueio de horário | — | nunca aparece, em nenhum toggle | RN-CM-030 | | Selo de atraso (marcador) | "🔴 15min" (emoji) | texto "Atrasado · 15min", sem emoji | Especificação 2.3 | | Finalizadas esmaecidas | fundo mais claro **e opacidade reduzida** | fundo mais claro e borda discreta, **sem reduzir a opacidade** (para manter o contraste); a cor do chip Finalizado também mudou (valores na seção 6) | Especificação 2.3, 2.8 | Sem mudança: ordenação cronológica, toggle Pendentes (default) / Todas, bordas laterais de Recepcionado (`secondary-pure`) e Aguardando (`--color-status-waiting-border`), clique no card abre o PEP, título do painel leva à Agenda do Médico. ### 4.4 Painel de Prescrições Pendentes - **Texto de tempo e atraso** conforme a seção 3.4, montado no front a partir de `minutesRemaining`. Chaves novas na seção 5. - **Ordenação:** a lista já vem ordenada do back-end (seção 3.3); o front não reordena. - **Destaque "Meu"** (`isPreferredReviewer`) nos **dois** tipos de card, não só "a revisar". É só destaque visual, sem texto com nomes de terceiros. - **Meus / Todos** afeta as duas categorias da mesma forma. Default "Meus". "Meus" esconde a pendência de um colega ausente; "Todos" existe para a colaboração (D-CM-028). - **Depois de assinar:** toast de sucesso, retorno à Central com foco no painel de Prescrições, e o KPI atualizado — "P/ assinar" diminui em um (e "Urgentes", se era urgente). Se a aplicação estava na janela de revisão, a prescrição some da lista inteira (seção 3.2, exceção (a)). - **Prescrição vencida** (hora da aplicação já passou) continua na lista com o chip vermelho e conta em "Urgentes" até ser assinada ou revisada. - Tela de assinatura, de revisão e endpoints de ação de prescrição **continuam fora desta especificação** (processo de Prescrições, documento à parte). ### 4.5 Painel de Mensagens - **Escopo (v5.12, D-CM-066):** o painel lista as conversas do médico das clínicas em que ele atende, filtradas por `Conversa.IdEmpresa` (seção 3.1; na v5.10 e na v5.11 era de todas as clínicas do cliente, D-CM-060). No banco, `IdEmpresa` é NOT NULL e entra nas chaves estrangeiras compostas: as junções usam `Id` + `IdEmpresa`, e toda linha nova das ações grava o `IdEmpresa` da conversa (Mapeamento 4.8 e 4.9). O card mostra a linha de clínica (v5.11, D-CM-064), no mesmo formato e com a mesma regra dos demais cards (seção 4.11). - **Confirmação ao resolver e ao descartar** (D-CM-032, E-CM-021). Diálogo `role="alertdialog"` com `aria-modal`, `aria-labelledby` (título) e `aria-describedby` (corpo). Foco inicial em **Cancelar**; Tab e Shift+Tab ficam entre Cancelar e o botão de confirmar; Esc cancela (quando aberto sobre o modal da conversa, cancela só a confirmação); o foco volta ao botão que abriu o diálogo. O texto vale para qualquer destinatário e **não promete "desfazer"** (D-CM-014). - Sem "desfazer" e sem texto de auditoria (D-CM-014). - Prazo da conversa no card: o emoji "⏰ Responder até 14:00" vira o ícone Lucide `clock` + o texto "Responder até 14:00". - `sourceType` agora é `User | System`; `messages[].type` é sempre `Response`. O front que testava `person`/`system` ou `initial`/`reply`/`update` precisa ser ajustado. - **Conversa não lida (v5.7, D-CM-045):** ícone e borda lateral esquerda (3 px) em `color-secondary-dark`. A Especificação v5.5 pedia `primary-pure` no ícone e `secondary-pure` na borda (1,7:1 e 2,0:1 sobre branco, abaixo de 3:1); o protótipo já usava `secondary-dark`. Lida: ícone `neutral-pure`, sem borda. - Modal da conversa: ver acessibilidade (seção 4.8). - **v5.18 (D-CM-087):** assunto no cartão, retirada do selo "Respondida", ícones `check`/`check-check`, ordem e `responded`, decididos na Mensageria; descritos na seção 4.13. ### 4.6 Painel Pacientes em procedimento | Item | Antes | Agora | Decisão | |---|---|---|---| | Nome do painel | "Procedimentos na clínica" | **"Pacientes em procedimento"**. O card do KPI continua "Procedimentos Hoje" | D-CM-019 | | Ícone de 1ª Consulta | não havia | mesmo ícone, mesma dica e mesma regra de teclado do painel de Consultas, quando `firstTime` é `true` | D-CM-029 | | Status | `administered`/`completed` (confuso) — na v5.15, `administered` | Agendado, Aguardando recepção, Recepcionado, Em preparo, Em aplicação, **Completo** (infusão terminada, sem alta), **Finalizado** (alta registrada), Cancelado | D-CM-030 | | Barra de progresso | base `Agenda.Tempo` | só para "Em aplicação"; base `TempoAplicacao`; 50 px × 3 px, percentual em 10 px (`--font-size-xs`; D-CM-045, v5.7) na linha do nome; trilho `neutral-lighter`, barra `neutral-dark`; passou de 100% fica `error-dark` | D-CM-015, E-CM-008 | | Sem tempo de aplicação | barra | **sem barra e sem percentual**; texto discreto "sem tempo previsto" | D-CM-034 | | Horário do card | ISO em UTC | `startTime` "HH:mm" já no fuso da clínica. (Mostrar o horário de **término** a partir de Finalizado, RN-CM-026, já valia na v4.37) | D-CM-042 | Sem mudança: toggle Meus (default) / Todos, ordenação por horário agendado com desempate alfabético. **v5.10 (D-CM-060, D-CM-061):** o painel e o indicador "Procedimentos Hoje" reúnem os procedimentos das clínicas em que o médico atende (v5.12, D-CM-066); o card mostra a linha de clínica (ícone `building-2` de 14 px, texto de 12 px `color-neutral-pure`) quando `clinic` vem preenchido, como nos cards de consulta e de prescrição (seção 4.10). ### 4.7 Faixa de sem conexão e estados Fonte: Especificação 2.7; D-CM-007, D-CM-027 (E-CM-001). - Se uma atualização automática falhar **depois** de o painel ou indicador já ter carregado: mantém os últimos dados e mostra **uma só faixa** para toda a Central, largura total, logo abaixo do cabeçalho. - Ícone Lucide `wifi-off` e `MSG_connectionLost`: "Sem conexão — dados atualizados às {hh:mm}", horário no fuso da clínica. - O horário é o da atualização bem-sucedida **mais antiga** entre os painéis e indicadores que estão falhando (pior caso de defasagem). - `role="status"`, anunciada uma vez ao aparecer, sem botão de fechar; some sozinha quando nenhuma atualização está falhando. - Em telas de até 1024 px o cabeçalho fica preso no topo e a faixa fica presa junto. - Painel que falha **antes** de ter dados continua com `MSG_endpointFail`, e a faixa não aparece por causa dele. - Cada painel tem skeleton próprio durante o carregamento; a busca mostra spinner dentro do campo. ### 4.8 Acessibilidade (Especificação 2.8, subseção "Acessibilidade (transversal)", D-CM-012) - Contraste: texto de informação ≥ 4,5:1 (3:1 em texto grande e componentes gráficos), nos dois temas. `color-neutral-medium` não vale como texto de informação nem placeholder. Finalizado se distingue por fundo e borda, nunca por opacidade. - Teclado: todo card e controle alcançável por Tab; Enter e Espaço fazem o que o clique faz. O botão de ação (Assinar, Revisar, PEP, Resolvido) é um controle à parte, **sem aninhamento** dentro do elemento clicável do card. - Foco visível (v5.8, D-CM-046; Design System, seção 11): em `:focus-visible`, anel de **2 px** em `--color-neutral-dark`, `outline-offset` de 2 px (recuado, `-2px`, só no item do menu do usuário; o anel do card é externo, afastado 2 px, e cabe no padding do painel), 11,2:1 ou mais nos dois temas. Até a v5.7 era 3 px. O anel de foco agora é regra do Design System (`gemed-theme.css` traz a regra); quem usa `--ring` local pode trocar. Nunca `outline: none` sem substituto. - Alvos de toque: mínimo 44 × 44 px. - Modal de conversa: `role="dialog"`, `aria-modal="true"`, nome acessível pelo título; foco entra e fica preso; Esc fecha; o foco volta a quem abriu (ou ao próximo elemento do painel, se a conversa saiu da lista). - Toasts: `role="status"` com `aria-live="polite"`; erros em `role="alert"`. - Busca: `role="combobox"` com `aria-expanded`, `aria-controls`, `aria-activedescendant`; lista `role="listbox"`, itens `role="option"`; setas navegam, Enter seleciona, Esc fecha; "nenhum paciente encontrado" em região `aria-live`. - `prefers-reduced-motion: reduce` desliga o ponto pulsante do selo "Atrasado" e a entrada dos avisos. - 360 px sem rolagem horizontal; chips e tags quebram de linha. - **Botões, avatar e toggle (Especificação 2.8; antes da v5 → agora; os botões mudam de novo na v5.17, seção 4.14):** Revisar e PEP: transparente com borda `primary` → fundo `secondary-light`, texto `neutral-darker`. Resolvido: texto `primary-pure` → contorno 1 px `neutral-light`, texto `neutral-dark`. **Descartado: preenchido `error-pure` com texto branco → transparente, contorno 1 px `error-dark`, texto `error-dark`.** Avatar do painel de Procedimentos: `primary-light`/`primary-dark` → `neutral-light`/`neutral-dark`. Toggle ativo: ganha contorno 1 px `neutral-dark`, texto `neutral-darker` (era `secondary-dark`) e área clicável de 44 px. Foco do campo de busca: borda de 2 px (v4) → anel de 3 px (v5.0 a v5.7) → **borda de 2 px `neutral-dark`, sem anel** (v5.8; `border: 1px` mais `box-shadow: inset 0 0 0 1px`, para o campo não mudar de tamanho). - **Chips de urgência (v5.8, D-CM-046):** Crítico (< 12 h, inclusive atrasada) = fundo `color-error-light`, sem contorno, texto e ícone `triangle-alert` em `color-error-dark`; Atenção (12 h a 24 h) = fundo `color-highlight-light`, sem contorno, texto e ícone `clock` em `color-highlight-dark`; os dois em peso regular, 400 (v5.10, D-CM-056; até a v5.9, `font-weight-medium`). Contraste do texto: 5,6:1 e 5,0:1 no claro; 6,3:1 e 8,9:1 no escuro. Até a v5.7: fundo `-medium`, contorno de 1 px e texto `neutral-darker`. O ícone continua, para a urgência não depender só da cor. Botões "Revisar"/"PEP" e toggles ativos usam texto `neutral-darker` (E-CM-004, a confirmar). ### 4.9 v5.9: clínica no card, desempate por nome, selo e número do KPI mais leves - **Linha de clínica (D-CM-050, E-CM-028):** nos cards de consulta e de prescrição, quando `clinic` vem preenchido, mostrar na última linha do card o ícone Lucide `building-2` (14 px) e o nome curto, em 12 px `color-neutral-pure`, sem chip. `clinic` é `null` quando o médico atende em uma só clínica: nesse caso, não desenhar a linha (v5.12, D-CM-066; entre a v5.10 e a v5.11 a regra foi "cliente com uma clínica", D-CM-060). Incluir o nome da clínica no nome acessível do card. - **Ordenação das prescrições (D-CM-047, E-CM-027):** `minutesRemaining`, depois nome do paciente (sem diferenciar maiúsculas e acentos), depois `id`. O protótipo usa `localeCompare('pt-BR', { sensitivity: 'base' })`; no back-end, a collation do banco. - **Selo "Atrasado" (D-CM-054, D-CM-058):** fundo `--color-error-light`, texto e ponto `--color-error-dark`, sem contorno; só o ponto pulsa. O selo e o número não usam mais `--color-alert-fill` (o `.toast-error` do protótipo ainda o usa). - **Número do KPI de Alertas:** `--color-error-dark` (era `--color-error-pure`). O "há 1h20" continua leve (D-CM-053). ### 4.10 v5.10: escopo do cliente, janelas por clínica e campo em repouso - **Escopo (D-CM-060):** o login é autorizado para um cliente; as clínicas (`ClienteEmpresa`) ficam no banco do cliente. Durante o login, o **médico** vê agendas, prescrições e mensagens das clínicas do cliente em que atende (v5.12, D-CM-066; antes, todas as clínicas do cliente); **os demais profissionais** ficam só na clínica escolhida na seleção de clínicas. Ao trocar de clínica, o médico pode trocar de cliente. Todos os endpoints filtram pelas clínicas do médico (`{ClinicasDoMedico}`); "hoje" e os horários de consultas e procedimentos seguem o fuso da clínica logada; as janelas de prescrição também (v5.11, D-CM-062, seção 3.2). - **Linha de clínica:** aparece quando o médico atende em mais de uma clínica, nos cards de consulta, prescrição e procedimento (E-CM-028, D-CM-061); na v5.11, também no de mensagem (D-CM-064). - **Janelas de prescrição por clínica:** seção 3.2 (D-CM-060, D-CM-062). Rótulo do indicador e "Em Tratamento" com a clínica logada (D-CM-063). - **Chips:** peso regular, 400 (D-CM-056). - **Campo de texto em repouso:** borda `--color-neutral-light` (1,7:1 no claro, 1,8:1 no escuro), como no Design System; o protótipo deixou de usar `neutral-pure` no campo de busca e no de resposta do modal. Contraste abaixo de 3:1 aceito pelo solicitante (D-CM-057). - **Prescrição já assinada** não volta a "a assinar" se a aplicação for adiada (D-CM-059, seção 3.2). ### 4.11 v5.11: mensagem com clínica e relógio único - **Card de mensagem (D-CM-064; o card mudou de novo na v5.18, seção 4.13):** mostra a linha de clínica (ícone `building-2` de 14 px e nome curto em 12 px `color-neutral-pure`, sem chip) quando `conversations[].clinic` vem preenchido; `null` com uma só clínica (não desenhar a linha). Incluir o nome da clínica no nome acessível do card. A linha vai depois das linhas do card (na v5.18: assunto e hora na linha 1, "autor: texto" na linha 2), como nos outros cards. - **Relógio único (D-CM-062):** a tela inteira usa o "hoje" e o fuso da clínica logada. O front não calcula janela de prescrição; só exibe o que o back-end manda. - **Sem mudança** de regra, contrato ou schema além do campo `clinic` de `conversations` e da cadeia de clínicas da seção 2. ### 4.14 v5.17: botões pela seção 12 do Design System e "Aguardando recepção" Fonte: Especificação v5.17 (2.8), Design System (seções 4a e 12), D-CM-084, D-CM-085, D-CM-086 (confirma E-CM-049). | Botão | Até a v5.16 | Na v5.17 | |---|---|---| | Assinar (card de prescrição) | Preenchido `primary-pure`, texto `--color-on-primary` | Secundário: transparente, contorno 1 px `neutral-pure`, texto `neutral-dark` | | Revisar (card de prescrição), PEP (card de procedimento) | Fundo `secondary-light`, texto `neutral-darker` | Secundário (como acima) | | Resolvido (card de mensagem e modal) | Terciário: contorno 1 px `neutral-light`, texto `neutral-dark` | Secundário (como acima) | | Responder (modal de mensagem) | Fundo `secondary-light`, texto `neutral-darker` | Primário: `--color-primary-strong` (`#007A13`), texto `--color-on-primary-strong` (branco), 5,5:1 nos dois temas | | Cancelar (caixa de confirmação) | Terciário | Secundário | | Resolver (caixa de confirmação) | Preenchido `primary-pure`, texto `--color-on-primary` | Primário (verde escuro) | | Descartado (modal) e Descartar (caixa de confirmação) | Destrutivo: transparente, contorno e texto `error-dark` | Sem mudança (D-CM-086: o Design System ainda não define o destrutivo) | - Regra da seção 12: no máximo um botão preenchido por região; botão dentro de card é sempre secundário. Os tokens `--color-primary-strong` e `--color-on-primary-strong` são iguais nos dois temas (não entram no bloco escuro). - `--color-on-primary` continua no sistema (contadores, logotipo), mas o Assinar não o usa mais. - **Nome do status `waiting` (D-CM-084):** o texto cadastrado em `TermoTraducao` é "Aguardando recepção" (com "r" minúsculo); vem da API em `status.name`. ### 4.13 v5.18: mudanças do painel de Mensagens vindas da Mensageria Fonte: Mensageria, `05 - Registro de Decisões v1.2` (D-MSG-021, D-MSG-023; seção 4), `02 - Especificação v1.2` (2.3 e 2.8.1) e `01 - Definição v1.2` (RN-MSG-002, 016 e 018), em `Definições e especificações/Mensageria/`. **Estado: na Central desde a v5.18 (D-CM-087).** Fonte também na Central: Especificação v5.18 (2.5, 2.8, 2.9), Mapeamento v5.18 (4.8, 4.9), Cenários CT-MSG-05, 08, 15 e 23 a 25. Vale só para o painel de Mensagens. Escolhas do Designer a confirmar: E-CM-050 (campo `authorIsMe`, ícone só no card, cor do `check-check`, assunto do modal). | # | Mudança | Até a v5.17 | Na v5.18 | Onde mexe | |---|---|---|---|---| | 1 | Assunto no cartão | Texto da última mensagem e "Há 15 min · Sandra", sem assunto | Linha 1: assunto (uma linha, truncado) com a hora à direita; linha 2: "autor: texto da última mensagem". Responde ao contexto perdido em respostas curtas | Back-end: `POST /reply` grava a leitura de quem respondeu (Mapeamento 4.9); campo `subject` (`Conversa.Assunto`) e `authorIsMe` ("Você"; E-CM-050) em `conversations[]` e `subject` no detalhe; front (card) | | 2 | Selo "Respondida" | Existe, quando o médico já respondeu e a conversa voltou a ficar não lida | **Retirado.** A resposta nova é a última mensagem, com o autor, e o cartão volta a ficar não lido (borda e ícone de origem coloridos; a Central não usa o ícone de carta da Mensageria, E-CM-050) | Front (card) | | 3 | Aviso de lida | Não existe | Quando a última mensagem é do médico (e não é de alerta do sistema), `check` (enviada) ou `check-check` (lida por pelo menos um dos outros) antes da hora; rótulos "Enviada" e "Lida" para leitor de tela. Campo `readByOthers` (`boolean|null`) em `conversations[]`, calculado por `ConversaLeitura` (Mensageria, Mapeamento 4.1) | Back-end (campo) e front (ícone) | | 4 | Ordem | Por estado de leitura; dentro de cada grupo, o prazo mais próximo e depois a mais recente | Por estado de leitura; dentro de cada grupo, o maior entre a última mensagem e o prazo, mais recente primeiro; empate: a conversa criada mais recentemente (RN-MSG-002). A Mensageria v1.3 põe o grau de urgência antes da data (seção 4.15) | Back-end (`ORDER BY`, Mapeamento 4.8; empate por `Conversa.CriadoEmUtc`); o resultado esperado de CT-MSG-08 não muda com a massa atual; novo CT-MSG-25 | | 5 | Valor do estado "respondida" | `replied` | `responded` (é o valor do banco, `Responded`) | Back-end (`status` de `conversations[]`, do detalhe e das respostas de `POST .../read` e `.../reply`), front e CT-MSG-15 da Central | | 6 | Horário | Relativo ("Há 15 min") | Continua relativo no painel; a Mensageria passa a usar a mesma regra nos cartões (D-MSG-032, v1.4; dentro da conversa segue data e hora). A regra do formato relativo foi definida na Mensageria v1.3 (D-MSG-028) e está **pendente de versão da Central**: seção 4.15, item 3 | — | | 7 | Botão "Resolvido" | Estilo definido na Central | Secundário, com contorno, quando a Central adotar o padrão de botões (Design System, seção 12); **o botão sai do card na v5.19** (seção 4.15, item 4) | CSS — **feito na v5.17** (D-CM-085, seção 4.14) | **Não muda:** borda e ícone de não lida em `secondary-dark` de 3 px, linha da clínica, `type` sempre `Response`, e resolver e descartar valendo para todos os destinatários. --- ### 4.12 v5.15 e v5.16: cores e nome do status vindos da API Fonte: Especificação v5.15 e v5.16 (2.3, 2.6, 2.8, 2.9), Mapeamento v5.15 e v5.16 (4.1, 4.3), Design System de 27/10/2026 (seção 4), DT-016. Guia relacionado: `Mudanças no Design System - guia para desenvolvimento.md`, seção 3.14. - **Contrato (D-CM-073):** em `appointments` e `procedures`, `status` deixa de ser texto e vira objeto `{ "domain": "finished", "name": "Finalizado", "colors": { "light": { "background": "#EDE7FA", "text": "#6A4FC4" }, "dark": { "background": "#302F52", "text": "#C0AFED" } } }`. As regras do front (toggle, bordas, selo de atraso, horário do procedimento) usam `domain`. `name` já vem no idioma da clínica. `colors` vem com os quatro valores ou não vem. - **Banco:** cores em `IpTerminologia.DomEstadoAgendaConsulta` e `IpTerminologia.DomEstadoAgendaProcedimento` (chave `CodEstado`; consulta `A`, `D`, `G`, `J`, `M`, `X`; procedimento `SCH`, `WTI`, `CKD`, `PRP`, `ADM`, `ASD`, `FNS`, `CNL`); nome em `TermoTraducao` (`Termo` = `CodEstado`, `Origem` = nome da tabela). Base global: mesmas cores para todas as clínicas. As tabelas ainda não estão na Biblioteca de Schema (DDL). - **`administered` (D-CM-074):** o status 3 de `ProcedureStatus()` volta a ser `administered` (`CodEstado` `ASD`). Quem implementou `completed` (v5.4 a v5.14) troca o valor; quem ficou no `administered` da v4 mantém, mas confere a ordem de avaliação (seção 3.8). - **Front, painel de Consultas:** chip com `.chip-status` e avatar de iniciais com `.avatar-status`, passando as cores como variáveis locais (`--st-bg-l`, `--st-fg-l`, `--st-bg-d`, `--st-fg-d`) só depois de validar o formato `#RRGGBB`; sem cor válida, chip e avatar ficam neutros. No avatar, iniciais em `--color-neutral-darker` nos dois temas, sobre o fundo do status (D-CM-075). Trocar o tema troca o par sem recarregar. - **Front, painel de Procedimentos (v5.16):** o status também é chip `.chip-status`, com `status.colors` e `status.name` (D-CM-079), na linha 2 do card, entre o local e as tags, com o horário entre parênteses logo depois do chip (E-CM-048). O avatar continua neutro (D-CM-077). Procedimento cancelado: nome, local, tags e clínica riscados (`text-decoration: line-through` em cada elemento, não no card, porque o risco se propaga e não pode ser desfeito no chip); o chip "Cancelado" e o avatar ficam sem risco (D-CM-076, D-CM-077). O risco não é anunciado pelo leitor de tela. - **Deploy (D-CM-080):** back-end e front-end trocam o formato de `status` (texto → objeto) no mesmo deploy, na Central e na Agenda do Médico; não há período com os dois formatos. - **Indicadores (D-CM-081):** o indicador `EstadoAgendaConsulta` de `IpTerminologia.Indicadores` será descontinuado depois da implementação nova; a Central não o lê. - **Nomes (D-CM-082):** os textos de `TermoTraducao` em pt-BR são "Em atendimento", "Em preparo" e "Em aplicação" (não "Em administração"). - **i18n:** saem do catálogo do front as chaves `status-*` (2.3 e 2.6). ### 4.15 v5.19: mudanças vindas da Mensageria (v1.3 a v1.8) Fonte: Mensageria `05 - Registro de Decisões v1.3` (D-MSG-025 a 028; seção 4), `01 - Definição v1.3` (RN-MSG-002 e 034), `02 - Especificação v1.3` (2.3.1, 2.3.8, 2.8.1) e Design System de 28/10/2026 (seção 13), em `Definições e especificações/Mensageria/`. **Estado: na Central desde a v5.19 (D-CM-088 e D-CM-089, 29/10/2026); a v5.20 (D-CM-090) renomeia o campo para `urgencyLevel` e o indicador de tempo para `timeIndicator`.** Fonte também na Central: Especificação v5.19 (2.5, 2.9, i18n), Mapeamento v5.19 (4.8), Protótipo v5.19, Cenários CT-MSG-19, 26 a 29 e CT-ACES-11. Vale só para o painel de Mensagens. Os itens 1 e 2 dependem da criação da coluna `GrauUrgencia` (L-09 da Mensageria); o contrato e o chip foram confirmados pelo solicitante em 28/10/2026 (D-MSG-029). O domínio em `IpTerminologia.Indicadores` é `GrauUrgencia` (D-MSG-034), com as chaves do HL7 **em minúsculas** (`routine`, `urgent`, `asap`, `stat`; D-MSG-046, já aplicadas no banco pelo solicitante); a chave de `TermoTraducao` ainda será definida. Escolhas do Designer a confirmar: E-CM-051 (chip também no modal, `serverNow` na resposta, textos `msg-ha-min`, `msg-ha-h` e `msg-grau-titulo`). | # | Mudança | Até a v5.18 | Na v5.19 | Onde mexe | |---|---|---|---|---| | 1 | Grau de urgência no cartão | Não existe | Chip só com o nome do grau, depois do chip do paciente e antes do de prazo, só quando a conversa tem grau (RN-MSG-034): Rotina, Urgente, Quanto antes ou Imediato (domínio HL7, D-MSG-039), com ícone `flag`, título "Grau de urgência: {nome}" e cor da seção 13 do Design System (Imediato sólido com `--color-alert-fill`; Quanto antes com fundo claro de erro e contorno; Urgente neutro; Rotina com contorno). Campo `urgencyLevel: { key: "routine|urgent|asap|stat", name }|null` em `conversations[]` e no detalhe; `name` já traduzido (`IpTerminologia.Indicadores` e `TermoTraducao`) **[PROPOSTA de contrato, E-MSG-018]** | Back-end (campo e leitura de `mensageria.Conversa.GrauUrgencia`, coluna ainda a criar: Mapeamento da Mensageria, L-09), front (card, `.chip-urg`, e modal); o chip é o mesmo do Design System, seção 13, e não é maiúsculo (`text-transform: none`) | | 2 | Ordem com o grau | Por estado de leitura; dentro de cada grupo, o maior entre a última mensagem e o prazo | Por estado de leitura; dentro de cada grupo, primeiro o grau (Imediato, Quanto antes, Urgente, Rotina e, por último, sem grau) e, dentro do mesmo grau, a regra atual (RN-MSG-002, D-MSG-026) | Back-end (`ORDER BY`, `GrauUrgencia` nulo conta como 0); CT-MSG-08 e CT-MSG-25 da Central | | 3 | Horário relativo | "Há 15 min", sem regra definida | Regra (D-MSG-028), no fuso da clínica (DT-001, DT-005): mesmo dia e menos de 1 h: "Há x min"; mesmo dia: "Há x h"; outro dia (dia de calendário): data e hora. A Mensageria usa a mesma regra nos cartões (D-MSG-032, v1.4), e a data e hora fica só dentro da conversa. Detalhes ainda propostos: x inteiro por truncamento, mínimo 1 min, recálculo a cada atualização de 1 minuto (E-MSG-019) | Front (formatação do horário do card); novos textos em `TermoTraducao` nos três idiomas | | 4 | Botão "Resolvido" no card | Secundário com contorno em todo card aberto (v5.17, D-CM-085) | **Retirado do card.** "Resolvido" e "Descartado" existem só no modal da conversa, com a mesma confirmação (D-CM-089; Mensageria D-MSG-047). Motivo: a leitura vem antes de encerrar, e um alerta não é resolvido para toda a equipe sem ser lido; os críticos de UX e do médico recomendaram a retirada | Front: remover o botão do card (`card-action` de conversa) e o `aria-label` "Resolvido: {assunto}"; o card fica com um só alvo de toque; endpoints e confirmação não mudam | **Não muda:** o chip "Crítico"/"Atenção" de alertas de atendimento (D-CM-046), que segue leve e com outro sentido (o grau deixou de ter o nome "Crítica", P-MSG-31 resolvida na Mensageria); o modal de mensagem, a confirmação de resolver e descartar, os endpoints de `read`, `reply`, `resolve` e `dismiss`, e a borda de não lida. --- ## 5. Internacionalização (v4.37 → v5.6) **Mudança da v5.6 (21/10/2026), back-end** (D-CM-044; decisões transversais DT-011 e DT-012): - O idioma de todo texto é o da clínica atual (`ClienteEmpresa.IdiomaOficial`), inclusive as mensagens do sistema, que a Especificação v5.5 dizia traduzir "para o idioma do usuário". Não há idioma por usuário. - Termo buscado em `TermoTraducao` (`Termo`, `Origem`, `Idioma`) sem linha no idioma da clínica: o campo recebe a própria chave (`Termo`) e o back-end registra anomalia no log técnico com `Termo`, `Origem` e `Idioma`. Não há queda para pt-BR nem para outro idioma. Se a implementação da v4 fazia queda para pt-BR, ela deve ser retirada. - `TermoTraducao.Termo` passa a `varchar(128)` (Log de Mudanças, 21/10/2026); sem efeito nos termos usados pela Central. Fonte: Especificação v5.5, blocos "Internacionalização" de cada painel. pt-BR é o idioma da certificação SBIS (D-CM-036); en-US e es-419 constam da especificação. **Chaves novas** | Chave | pt-BR | en-US | es-419 | |---|---|---|---| | `dica-primeira-consulta` | 1ª Consulta | First visit | Primera consulta | | `consulta-ha-tempo` | há {t} | for {t} | hace {t} | | `presc-restante` | {h}h restantes | {h}h left | {h}h restantes | | `presc-restante-min` | {m}min restantes | {m}min left | {m}min restantes | | `presc-atrasada-hm` | {h}h{mm} atrasada | {h}h{mm} overdue | {h}h{mm} de atraso | | `presc-atrasada-dias` | {d} dias atrasada | {d} days overdue | {d} días de atraso | | `presc-atrasada-min` | {m}min atrasada | {m}min overdue | {m}min de atraso | | `MSG_resolveConfirmTitle` | Resolver conversa? | Resolve conversation? | ¿Resolver la conversación? | | `MSG_resolveConfirmBody` | A conversa será marcada como resolvida para todos os destinatários. | The conversation will be marked as resolved for all recipients. | La conversación se marcará como resuelta para todos los destinatarios. | | `MSG_resolveConfirmOk` | Resolver | Resolve | Resolver | | `MSG_discardConfirmTitle` | Descartar conversa? | Discard conversation? | ¿Descartar la conversación? | | `MSG_discardConfirmBody` | A conversa será descartada para todos os destinatários. | The conversation will be discarded for all recipients. | La conversación se descartará para todos los destinatarios. | | `MSG_discardConfirmOk` | Descartar | Discard | Descartar | | `MSG_confirmCancel` | Cancelar | Cancel | Cancelar | | `proc-sem-tempo` | sem tempo previsto | no planned time | sin tiempo previsto | | `MSG_connectionLost` | Sem conexão — dados atualizados às {hh:mm} | No connection — data updated at {hh:mm} | Sin conexión — datos actualizados a las {hh:mm} | | `MSG_themeOptions` | Tema / Automático (segue o sistema do aparelho) / Claro / Escuro | Theme / Automatic (follows the device setting) / Light / Dark | Tema / Automático (sigue la configuración del dispositivo) / Claro / Oscuro | Também são novos os singulares "pendente" e "atrasada" dos cards de KPI nos três idiomas (o título "Alertas de prescrição" já existia); a tabela completa está na Especificação 2.2, bloco "Internacionalização". Os textos de confirmação e "sem tempo previsto" são escolha do Designer (E-CM-021, a confirmar; ver também P-CM-041). **Chaves alteradas** | Chave | Antes | Agora | |---|---|---| | `painel-título` (procedimentos) | Procedimentos na clínica / Procedures at the clinic / Procedimientos en la clínica | Pacientes em procedimento / Patients in procedure / Pacientes en procedimiento | | KPI "assinar" | p/assinar (próx. 7 dias) — texto fixo | p/assinar (próx. {n} dias), com variante singular "próx. 1 dia"; en-US "to sign (next {n} days)"; es-419 "p/firmar (próx. {n} días)" | | `status-completo` (en-US) | Completed (igual a Finalizado) | Complete. Na v5.15, as chaves `status-*` saem do catálogo: o nome vem da API (`status.name`, seção 4.12) | | `toggle-meus` (es-419, procedimentos) | Mios | Míos | | `status-atendimento` (en-US) | In consulation (erro de digitação) | In consultation | | `MSG_searchPac` (en-US) | Search Pacient... | Search patient... | | `MSG_searchFoot` (en-US) | Enter parte of ... | Enter part of ... | | `MSG_searchFoot` (es-419) | texto com "Ingrese parte del busque por nombre..." | reescrito: "Ingrese parte del nombre, ID, nombre de la madre o fecha de nacimiento para filtrar" | | `status-agendado` (en-US) | Shceduled (erro de digitação) | Scheduled | | KPI "atrasadas" (es-419) | atrasada | atrasadas | **Chave removida:** `chip-T_restante` ("T RESTANTES"). Substituída pelas chaves `presc-restante*` e `presc-atrasada-*`. --- ## 6. Tema, cores e tokens Fonte: Especificação 2.8; D-CM-027, D-CM-043; guia `Mudanças no Design System - guia para desenvolvimento.md` (não repetido aqui). - A Central segue o **Design System de 14/10/2026**. Nenhum uso de token mudou na v5.5; só os valores (regra C8 e `neutral-pure` claro `#526A90`). Quem já implementou o Design System atualizado não tem trabalho adicional na Central, exceto, na v5.8, o anel de foco e os chips de urgência (seção 4.8). - **`--color-on-primary`** é o token do texto e dos ícones sobre `--color-primary-pure` (botão Assinar). Texto escuro sobre o verde, nos dois temas. - **Status de agenda (v5.15 e v5.16):** chip e avatar de iniciais da consulta e, desde a v5.16, chip de status do procedimento (D-CM-079) usam as cores que vêm da API em `status.colors`, pelas classes `.chip-status` e `.avatar-status` do Design System (seção 4; seção 4.12 deste guia). `--color-status-waiting-border` continua na borda lateral. Até a v5.14, eram os tokens `--color-status-*-bg`/`-fg`; eles continuam no Design System como referência dos valores, mas o componente não os usa mais. - **`--color-first-visit`** no ícone da 1ª Consulta. - Tags do cadastro: classe `.chip-tag` com `--tag` = `ProgramaApoio.Cor`. - Número do KPI de alertas: texto em `color-error-dark` desde a v5.9 (D-CM-054, D-CM-058; 6,3:1 no claro e 7,4:1 no escuro; antes `color-error-pure`), não badge preenchido. Selo "Atrasado": ver a seção 4.3. Contador do painel: badge `color-neutral-lighter` com texto `color-neutral-darker`. - Barra de progresso: `neutral-dark`; vermelha em `error-dark`. - Faixa de sem conexão: `highlight-light`, `neutral-dark`, `neutral-lighter` (Design System, seção 7). - **v5.8 (26/10/2026):** a Central passa a seguir o Design System de 26/10/2026, que só acrescentou o token `--color-field-changed` (`#467EE5`, borda de campo alterado; a Central não tem campo editável e não o usa) e a seção 11 (estados de campo e foco). Nenhum valor existente mudou. Chips de urgência e anel de foco: seção 4.8. --- ## 7. Testes e massa de dados Fonte: `Cenários de Teste v5.11.md`; `CargaCMZero.xlsx`; `ScriptComplementarvCM.sql`. - **v5.10 a v5.12 (escopo de clínicas):** casos novos que **dependem de massa proposta**, ainda inexistente na carga (v5.12: um cliente de três clínicas, das quais o Dr. 9 atende em duas, e outro de uma só; a segunda clínica com outro `FusoHorarioOficial`): CT-CONS-19 (consultas das clínicas dele, a da terceira clínica fora, linha de clínica e horário no fuso da clínica logada), CT-CONS-20 (troca de cliente), CT-PRES-19 (prescrições das clínicas dele, "Meus" e "Todos", sem a da terceira), CT-PRES-21 (reagendamento de prescrição já assinada, D-CM-059), CT-PRES-22 (janelas de assinatura diferentes por clínica), CT-PRES-23 (o "hoje" da janela de revisão é o da clínica logada, com fusos −03:00 e −04:00), CT-PROC-14 (procedimentos das clínicas dele) e CT-MSG-22 (conversas das clínicas dele, linha de clínica, resposta gravada na clínica de origem e recusa de ação sobre conversa da terceira). A restrição dos demais profissionais à clínica escolhida não é testada na Central. - **v5.8:** CT-ACES-06 (foco: anel de 2 px; campo de busca com borda de 2 px) e CT-ACES-07 (chips leves e seus contrastes) têm novo resultado esperado; nenhum dado de massa muda. - Os Cenários de Teste v5.5 cobrem os 4 painéis, os 4 KPIs, a busca e as exceções (tema, acessibilidade, faixa de sem conexão). Os resultados esperados estão em pt-BR; en-US e es-419 aparecem só onde há texto próprio a conferir. - **Data-base: 23/09/2026 12:00.** Toda data relativa ("hoje", "hoje+N") gira em torno desse instante. A carga recalcula as datas a cada execução (`UPDATE DATAS`, relativo a `GETDATE()`); em outro dia, os valores absolutos dos cenários se deslocam e precisam ser reconferidos. - Médicos da massa: IdChProfissional 11 (Craig Evans) e 9 (Gilliard Onório Santos). **Cuidados conhecidos com a massa e com o protótipo (não corrigidos):** 1. O `UPDATE DATAS` da planilha tem um erro de digitação (`DATEAD`) no `UPDATE PEP` (`DataInicioUTC`): o comando falha e o script **para ali**, e os `UPDATE` seguintes não rodam. - Além disso, o script não desloca nenhum `DhInfusaoFimUTC`; a Agenda 138 é o exemplo visível (fim em 18/09, início em 23/09). 2. A aba `PrescricaoAssinatura` da planilha tem colunas `Reassinar` e `Status` que **não existem no DDL** de `GescomClienteAlfa` (a pergunta que isso motivou foi decidida em D-CM-050: a nova versão da prescrição nasce sem assinaturas). 3. A aba `IpParametro` da planilha traz a definição de `PrescricaoTempoRevisao` (sem valor por clínica e sem uso); ela **não deve** ser criada (seção 2). 4. Na massa entregue, a prescrição 71 fica fora das listas, porque a assinatura 1030 (22/09 11:14) cai dentro da janela de revisão. A "massa alternativa da 71" (sem assinatura, para ter o caso vencido e urgente) usada em CT-PRES-11 e CT-KPI-04.2 é **[PROPOSTA]** do Designer, a validar com o solicitante — não é massa entregue. Outras lacunas: nenhum procedimento da massa resolve para "Completo" (CT-PROC-11 exige alterar a Agenda 138) e nenhuma prescrição tem `TempoAplicacao` vazio ou zero. 5. 23 linhas da massa têm alta e `DhInfusaoFimUTC` nulo: o resultado esperado é `finished`. 6. O protótipo foi validado **apenas em JSDOM/node**, não num navegador real. 7. O protótipo não testa `Situacao = 'V'` em alguns status de procedimento e ainda compara o texto da busca com o prontuário (P-CM-042, P-CM-038): **o Mapeamento é a referência, não o protótipo.** Outras divergências conhecidas do protótipo: ele ordena as tags no front (a Especificação diz que o back-end já envia ordenado); en-US e es-419 só existem no protótipo para o que é novo ou alterado. (A borda e o ícone de conversa não lida em `secondary-dark` e o percentual da barra em 10 px eram divergências até a v5.6; foram decididos em D-CM-045 e a Especificação v5.7 já os descreve assim.) O chip "Crítico" da Especificação é o mesmo que a classe `.chip-critical` do protótipo e o que o KPI chama de "Urgentes". --- ## 8. Decisões abertas que podem mudar o desenvolvimento Fonte: Registro de Decisões v1.13. Nada aqui bloqueia a implementação do que está nas seções 2 a 6; são os pontos em que o código pode ser refeito se o solicitante decidir diferente. Cada "ideia do Designer" abaixo é **invenção**, sem decisão. ### 8.1 Escolhas do Designer a confirmar (implementar como descrito) | Código | O que está implementado como proposta | Se mudar, afeta | |---|---|---| | E-CM-004 | Botões "Revisar"/"PEP" e toggles ativos com texto `neutral-darker`. (A parte dos chips e a E-CM-003, anel de foco, foram decididas em D-CM-046.) | Só CSS | | E-CM-024 | Itens [PROPOSTA] da seção 11 do Design System: 2 px em "selecionado" e "com erro", precedência entre estados abaixo de "erro" (erro antes de selecionado foi decidido, D-CM-049), `:focus-visible` | Só CSS | | E-CM-018 | "Administração iniciada" = `Agenda.DhInfusaoIniUTC` preenchido; retira só "a revisar" | SQL de 4.6 e 4.7 | | E-CM-019 | "Assinatura dentro da janela" = assinatura em data ≥ meia-noite local de (dia da aplicação − N); `datetime` sem fuso tratado como hora local da clínica **(a confirmar com o time de banco)** | SQL de 4.6 e 4.7 (`{InicioJanelaRevisaoLocal}`), conversão de fuso | | E-CM-021 | Textos de confirmação, "sem tempo previsto" e "{d} dias atrasada" | Só i18n | | E-CM-032 | Tabela `{LimitesPorClinica}` com uma linha por `Clinica` do banco do cliente, montada pela aplicação, com limites em UTC no fuso da clínica logada; a hora das assinaturas (`datetime` sem fuso) é lida como hora local da clínica logada | SQL de 4.6 e 4.7; serviço que monta os limites | | E-CM-033 | Nome da clínica no card de mensagem pelo caminho `Conversa.IdEmpresa` → `Clinica.IdEmpresa` → `Clinica.IdChClinica` → `Chave.Descricao`; a condição de exibir o nome mudou na v5.12: "o médico atende em mais de uma clínica" (D-CM-067) | Contrato de `conversations`; query de 4.8 | | E-CM-027 | Último critério de desempate das prescrições: `id` crescente, para o mesmo nome de paciente | `ORDER BY` do endpoint | | E-CM-028 | Nome curto da clínica no card de consulta e de prescrição (ícone `building-2` de 14 px, texto de 12 px `neutral-pure`), só quando o médico atende em mais de uma clínica (D-CM-066); campo `clinic` | Contrato de `appointments` e `prescriptions`; CSS do card | | E-CM-029 | "Consultas Hoje", "Procedimentos Hoje", "Alertas de Prescrição" e o toggle "Todos" seguem o escopo das clínicas em que o médico atende (D-CM-066) | Queries de 4.2, 4.4 e 4.7 (filtro por `{ClinicasDoMedico}`) | ### 8.2 Perguntas em aberto (P-CM) | Código | Pergunta | Impacto provável no código | |---|---|---| | P-CM-003 | Confirmar que assinar uma prescrição na janela de revisão a tira da lista e baixa o número (D-CM-040). Atenção: o sistema atual tem `RevisorIgualMedicoQueAssinou` (padrão "N"), que impede o mesmo médico de assinar e revisar — vai em sentido contrário | Regra de 4.6 e 4.7 | | P-CM-007 | `attendanceMode` deve ser objeto `{code, label}`, como na Agenda do Médico? (Ideia do Designer: sim, para reaproveitar o componente) | **Contrato** de `appointments` (`procedures` não tem `attendanceMode`) | | P-CM-026 (a) | Resolver/descartar conversa sem trilha de auditoria (SBIS NGS1.07.03) — a mensageria pode ser tratada como canal auxiliar fora do SBIS? | Pode exigir auditoria nos endpoints `resolve` e `discard` | | P-CM-035 | Lembrete: parâmetro do sistema atual que permite ou não que outros médicos assinem as prescrições do prescritor. Não foi localizado em `ParametrosGemedLegado.csv`; existem `MedicoPodeRevisar`, `EnfermeiroPodeRevisar`, `FarmaceuticoPodeRevisar`, `RevisorIgualMedicoQueAssinou`. Especificar em versão futura | Interação com "Todos" e com D-CM-040 | | P-CM-036 | Nome e comportamento do item do Menu Lateral que abre a tela de Pacientes em procedimento (hoje "Pacientes na Clínica Hoje"). Ideia do Designer: "Pacientes em procedimento" | Menu Lateral (outra funcionalidade) | | P-CM-037 | SBIS: (1) "Todos" e o médico assistente em "Meus" versus ECF.16.01(c); (2) card sem o médico prescritor versus ECF.17.01; (3) ECF.17.18 e os idiomas adicionais | Pode restringir "Todos" ou mudar o card | | P-CM-038 | Especificar a chave `id:` da busca (contrato, banco, texto de ajuda, formato)? Ideia do Designer: especificar só o necessário para a demonstração e tirar o prontuário da busca comum | Endpoint `patients/search` | | P-CM-039 | Prescrição "a assinar" com infusão iniciada aparece como "3h00 atrasada" (pode ser lido como "ainda não aplicada"); "a revisar" com infusão iniciada some. Ideias do Designer: (a) texto "Em aplicação sem assinatura"; (b) manter "a revisar" na lista com a marca "revisão não feita"; (c) avisar na tela de assinatura quando a aplicação já passou ou começou | Texto do card; exceção (b) de 4.6 | | P-CM-040 | Cancelar a agenda ou marcar falta cancela a prescrição? As consultas de 4.6 e 4.7 **não olham `Agenda.Situacao`**, só `Prescricao.Situacao` e `Agenda.RemovidoEm`; uma vencida sem desfecho fica na lista e em "Urgentes". Ideias do Designer: (a) excluir agendas fora de A/V; (b) vencidas há muitos dias no fim da lista; (c) aviso ao assinar uma vencida | SQL de 4.6 e 4.7; ordenação | | P-CM-041 | Textos a avaliar, com alternativas (invenção do Designer): "atrasada há 3h00"; "duração da infusão não informada"; "Isso não pode ser desfeito." na confirmação; "Infusão concluída" × "Alta dada" no lugar de Completo × Finalizado | Só i18n | | P-CM-052 | `Conversa.IdEmpresa` deveria guardar o `IdChClinica` e não o `IdEmpresa`? O solicitante acha que o ideal seria, e adiou. Hoje guarda `SegEmpresa.IdEmpresa` (confirmado, D-CM-069) | Filtro de 4.8; mensageria (`GescomMensageria.sql`) | | P-CM-042 | Divergências técnicas menores (itens 1 a 5): protótipo sem `Situacao = 'V'` em alguns status; `progress` nulo com dois significados; painel de procedimentos mostra ou não os cancelados; recálculo de "45min restantes" entre os polls de 5 min; "0min restantes" com exatamente 0 minuto. Os itens 6 a 8 e a segunda parte do 3 foram decididos em D-CM-052 | Detalhes do front e do contrato | --- ## 9. Rastreabilidade: mudança → decisão → documento | Mudança | Decisão | Onde está a regra completa | |---|---|---| | Bloqueio de horário da Recepção fora da Central | D-CM-001 | Definição RN-CM-030; Mapeamento 4.1, 4.2 | | VIP vem de `ProgramaApoioPaciente` | D-CM-002 | Definição RN-CM-025; Mapeamento 4.1 | | 1ª Consulta como ícone | D-CM-003, D-CM-016, D-CM-035 | Especificação 2.3, 2.8; Definição RN-CM-028 | | Selo "Atrasado" único | D-CM-004 | Especificação 2.3 | | Mudanças do painel de Mensagens vindas da Mensageria (assunto no cartão, selo "Respondida" retirado, `check`/`check-check`, ordem, `responded`) | D-CM-087 (a partir de D-MSG-021 e D-MSG-023, Mensageria) | Seção 4.13; Especificação 2.5, 2.9 | | Janela de revisão: parâmetro existente, padrão 1 dia | D-CM-006 | Mapeamento 4.6 | | Faixa de sem conexão | D-CM-007, D-CM-027 | Especificação 2.7 | | "Atrasadas" não conta consulta em atendimento | D-CM-008 | Mapeamento 4.2 | | Vigência de prontuário e diagnóstico | D-CM-009, D-CM-010 | Mapeamento 4.1 | | Resolver/descartar vale para todos; sem desfazer; confirmação | D-CM-011, D-CM-014, D-CM-032 | Definição RN-CM-015; Especificação 2.5 | | Acessibilidade | D-CM-012 | Especificação 2.8 | | Prescrição vencida fica na lista e é urgente | D-CM-013, D-CM-024 | Definição RN-CM-011, RN-CM-020; Mapeamento 4.6, 4.7 | | Progresso por `TempoAplicacao` | D-CM-015, D-CM-020, D-CM-034 | Mapeamento 4.3 | | "há 1h20" na consulta em atendimento | D-CM-017 | Especificação 2.3; Mapeamento 4.1 | | Subtexto "X pendentes (Y atrasadas)" | D-CM-018 | Especificação 2.2 | | Painel "Pacientes em procedimento" | D-CM-019 | Especificação 2.6 | | Item do Menu Lateral que abre a tela de Pacientes em procedimento | D-CM-031 (nome do item em P-CM-036) | Menu Lateral (outra funcionalidade) | | Seletor de tema no menu do avatar | sem D-CM; Design System, seção 6 | Especificação 2.1. Persistência da escolha não decidida | | `Agenda.Data` descontinuada | DT-002 | Decisões Transversais; Log de Mudanças Estruturais (10/10/2026) | | Vigência de tag por data, inclusiva | D-CM-021 | Mapeamento 4.1 | | Ordem das tags | D-CM-022 | Mapeamento 4.1; Especificação 2.3 | | Janelas em dias de calendário | D-CM-023, D-CM-037 | Mapeamento 4.6, 4.7 | | Prescrição sem agenda fora das listas | D-CM-025 | Mapeamento 4.6, 4.7 | | `hoursRemaining` truncado | D-CM-026 | Mapeamento 4.7 | | Escopo "Meus" e colaboração em "Todos" | D-CM-028 | Especificação 2.4 | | `firstTime` em procedimentos | D-CM-029 | Mapeamento 4.3 | | Status de procedimento em ordem | D-CM-030 | Mapeamento 4.3, 4.4 | | "A assinar" inclui vencidas; falha de processo é da Recepção | D-CM-033 | Definição RN-CM-020 | | Prontuário fora dos critérios da busca (já era assim); `id:` só na certificação; idioma | D-CM-036 | Especificação 2.1, 2.10 | | Total de Procedimentos Hoje inclui finalizados (esclarecimento, sem mudança de query) | D-CM-038 | Mapeamento 4.4 | | Administração iniciada retira só "a revisar" | D-CM-039 | Mapeamento 4.6, 4.7 | | Assinatura na janela dispensa revisão | D-CM-040 | Mapeamento 4.6, 4.7 | | Textos de tempo e atraso | D-CM-041 | Especificação 2.4 | | Contrato: `Response`, `User \| System`, `startTime` "HH:mm", `completed`/`finished` (na v5.15, `administered`) | D-CM-042, D-CM-074 | Especificação 2.9 | | Status como objeto `{ domain, name, colors }`, cores das tabelas `DomEstadoAgenda*` | D-CM-073 | Especificação 2.3, 2.9; Mapeamento 4.1, 4.3 | | Avatar: iniciais `neutral-darker` sobre a cor do status | D-CM-075 | Especificação 2.3, 2.8 | | Procedimento cancelado com textos riscados | D-CM-076, D-CM-077 | Especificação 2.6 | | Status do procedimento em chip | D-CM-079, E-CM-048 | Especificação 2.6, 2.8 | | Troca do formato de `status` no mesmo deploy | D-CM-080 | Especificação 2.9 | | Indicador `EstadoAgendaConsulta` descontinuado depois | D-CM-081 | Mapeamento, "Tabelas novas" | | Nomes "Em atendimento", "Em preparo", "Em aplicação" | D-CM-082 | Especificação 2.3, 2.6 | | Nome "Aguardando recepção" | D-CM-084 | Especificação 2.3, 2.6 | | Botões pela seção 12 do Design System | D-CM-085, D-CM-086 | Especificação 2.8 | | Painel de Mensagens alinhado à Mensageria | D-CM-087, E-CM-050 | Especificação 2.5, 2.9; Mapeamento 4.8 | | Alinhamento ao Design System de 14/10 | D-CM-043 | Especificação 2.8 | | Idioma da clínica e tradução sem queda para pt-BR | D-CM-044 | Especificação 2.9 e i18n | | Conversa não lida em `secondary-dark`; percentual da barra em 10 px | D-CM-045 | Especificação 2.5, 2.6 e 2.8 | | Anel de foco de 2 px; chips de urgência leves; token `--color-field-changed` | D-CM-046 | Especificação 2.3, 2.4 e 2.8; Design System 4a e 11 | | Desempate das prescrições pelo nome do paciente | D-CM-047, E-CM-027 | Definição RN-CM-011; Especificação 2.4 e 2.9; Mapeamento 4.7 | | Erro antes de selecionado na precedência dos campos | D-CM-049 | Design System 11 | | Nova versão de prescrição nasce sem assinaturas; Central em todas as clínicas do cliente (**revisto na v5.12 por D-CM-066**) | D-CM-050, D-CM-052, E-CM-028, E-CM-029 | Definição RN-CM-020 e RN-CM-032; Especificação 2.3, 2.4 e 2.9; Mapeamento 4.1 e 4.7 | | Ordem das mensagens confere com ECF.17.04 | D-CM-051 | Especificação 2.10 | | `CHECK` de `Mensagem.Tipo` só `Response` | D-CM-052 | Mapeamento 4.9; Log de Mudanças Estruturais | | Selo "Atrasado" e número do KPI mais leves; "há 1h20" leve | D-CM-053, D-CM-054, D-CM-058 | Especificação 2.2, 2.3 e 2.8 | | "45min restantes" abaixo de 1 hora | D-CM-055 | Especificação 2.4 | | Chips "Crítico"/"Atenção" em peso regular (400) | D-CM-056 | Especificação 2.4 e 2.8 | | Campo em repouso com `neutral-light` (contraste aceito) | D-CM-057 | Especificação 2.8; Protótipo | | Prescrição já assinada não é assinada de novo; só volta a "a revisar" | D-CM-059 | Definição RN-CM-020; Cenários (CT-PRES-21) | | Médico vê agendas, prescrições e mensagens de todas as clínicas do cliente (**revisto na v5.12 por D-CM-066**); janelas por clínica; `clinic` em `procedures` | D-CM-060, D-CM-061 | Definição RN-CM-032 e RN-CM-020; Especificação 2.2 a 2.6 e 2.9; Mapeamento 4.1 a 4.8; Cenários (CT-PRES-22, CT-PROC-14, CT-MSG-22) | | "Hoje" e fim do dia das janelas de prescrição no fuso da clínica logada; N e S por clínica | D-CM-062, E-CM-032 | Definição RN-CM-020 e RN-CM-032; Mapeamento 4.6 e 4.7; Cenários (CT-PRES-23) | | Rótulo do alerta e "Em Tratamento" com a clínica logada | D-CM-063 | Especificação 2.2 e 2.9; Mapeamento 4.5 e 4.6 | | Card de mensagem com a clínica; campo `clinic` em `conversations` | D-CM-064, E-CM-033 | Especificação 2.5 e 2.9; Mapeamento 4.8; Cenários (CT-MSG-22) | | Ligação das clínicas: `ClienteEmpresa` → `SegEmpresa` → `Clinica` → `IpParametroChave` | D-CM-065 | Mapeamento, início da Seção 4 | | Médico vê só as clínicas em que atende (Central e Agenda); linha de clínica quando atende em mais de uma; `{ClinicasDoMedico}`; perda de acesso | D-CM-066, D-CM-067, D-CM-068, D-CM-070 | Definição RN-CM-032; Especificação 2.2 a 2.6 e 2.9; Mapeamento, início da Seção 4 e 4.1 a 4.8; Cenários (CT-CONS-19, CT-PRES-19, CT-PROC-14, CT-MSG-22) | | Grau de urgência no cartão, ordem pelo grau, horário relativo e botão "Resolvido" fora do card, no painel de Mensagens (v5.19) | D-CM-088 e D-CM-089 (Central); D-MSG-025 a 028, 046 e 047 (Mensageria) | Mensageria: Definição RN-MSG-002 e 034; Especificação 2.3.8 e 2.8.1; Design System, seção 13; este documento, seção 4.15 | Mudanças sem código D-CM próprio neste documento (ids inteiros, `tags` como objetos, `FusoHorarioOficial`, `RemovidoEm`): estão no Histórico de Versões da Especificação e do Mapeamento, a partir da v5.0. --- ## Histórico de Versões - **v1.19** (29/10/2026) — Guia fechado: a série v5 foi fechada na v5.20 e foi para desenvolvimento (a pedido do solicitante). Sem mudança de conteúdo técnico; só o cabeçalho (destino "v5.20" em vez de "v5.14", pasta `Histórico/`, situação). As mudanças da nova versão estão no guia da v6. - **v1.18** (29/10/2026) — Destino passa à série v5.20 (Registro v1.19). Nomes técnicos (D-CM-090): na seção 4.15, o campo do grau é `urgencyLevel` (era `urgency`); o chip "Crítico"/"Atenção" dos painéis de Consultas e de Prescrições é o `timeIndicator` (valores propostos `critical`, `attention`, `normal`; classes `chip-critical` e `chip-attention`, antes `chip-urgente` e `chip-atencao`). A contagem `urgent` do endpoint de alertas de prescrição não muda. - **v1.17** (29/10/2026) — Destino passa à série v5.19 (Registro v1.18). Seção 4.15: deixa de ser "pendente" e passa a descrever a v5.19; chaves do grau em minúsculas (D-MSG-046); novo item 4, o botão "Resolvido" sai do card (D-CM-089); item 7 da seção 4.13 e seção 9 ajustados. - **v1.16** (28/10/2026) — Seção 4.15, item 1 (e 2): o grau da Mensageria passa ao domínio HL7 (Rotina, Urgente, Quanto antes, Imediato; `urgency: { key, name }`; chip só com o nome; D-MSG-039). A ordem passa a Imediato, Quanto antes, Urgente, Rotina e sem grau. - **v1.15** (28/10/2026) — Seção 4.15 atualizada para a Mensageria v1.4: o horário relativo vale também nos cartões da Mensageria (D-MSG-032); contrato do grau e chip confirmados (D-MSG-029); domínio `GrauUrgencia` (D-MSG-034). Item 6 da seção 4.13 ajustado. - **v1.14** (28/10/2026) — Nova seção 4.15, "Pendente de versão da Central": três mudanças do painel de Mensagens vindas da Mensageria v1.3 (grau de urgência no cartão, ordem pelo grau, regra do horário relativo, D-MSG-025 a 028); itens 4 e 6 da seção 4.13 apontam para ela; seção 9 com uma linha. Nenhuma mudança já implementada na v5.18 foi alterada. - **v1.13** (28/10/2026) — Destino passa à série v5.18 (Registro v1.17). A seção 4.13 deixa de ser "pendente": as mudanças do painel de Mensagens vindas da Mensageria estão na Central v5.18 (D-CM-087), com a coluna "Onde mexe" ajustada (`subject`, `authorIsMe`, empate da ordem, CT-MSG-25). E-CM-049 confirmada (D-CM-086). Seção 9 com as novas decisões. - **v1.12** (28/10/2026) — Destino passa à série v5.17 (Registro v1.16). Nova seção 4.14: botões pela seção 12 do Design System (D-CM-085, E-CM-049) e nome "Aguardando recepção" (D-CM-084). Na seção 4.13, o item 7 (Resolvido com contorno) fica marcado como feito; os outros seis seguem pendentes de pedido. Seção 9 com as novas decisões. - **v1.11** (27/10/2026) — Nova seção 4.13, "Pendente de versão da Central": sete mudanças do painel de Mensagens decididas na Mensageria (assunto no cartão, selo "Respondida" retirado, `check`/`check-check` com `readByOthers`, nova ordem, `responded`, horário relativo mantido, botão "Resolvido" com contorno). Marcadas como ainda fora das especificações da Central, por pedido do solicitante. A seção 4.5 aponta para ela e a seção 9 ganha uma linha. Nenhuma outra seção muda; destino segue a série v5.16. - **v1.10** (27/10/2026) — Destino passa à série v5.16 (Registro v1.15). Seção 4.12: status do procedimento em chip (D-CM-079, E-CM-048), avatar neutro confirmado (D-CM-077), troca de formato no mesmo deploy (D-CM-080), indicador `EstadoAgendaConsulta` descontinuado depois (D-CM-081) e nomes de `TermoTraducao` (D-CM-082). Nomes atualizados nas demais seções; seção 9 com as novas decisões. - **v1.9** (27/10/2026) — Destino passa à série v5.15 (Registro v1.14). Nova seção 4.12: `status` como objeto `{ domain, name, colors }`, tabelas `DomEstadoAgendaConsulta` e `DomEstadoAgendaProcedimento`, `administered` no lugar de `completed`, avatar com iniciais `neutral-darker`, procedimento cancelado com textos riscados (D-CM-073 a D-CM-076). Seções 1, 3.1, 3.8, 4.6, 5, 6 e 9 ajustadas. - **v1.8** (26/10/2026) — Destino passa à série v5.14 (Registro v1.13). Corrige a v1.7: quem perde o acesso a uma clínica perde as agendas e as prescrições dela, não os pacientes (D-CM-070); "Em Tratamento", adesão e busca seguem sem filtro por clínica. Nome do campo de `SegEmpresa` fixado no do DDL (D-CM-071). `Clinica.FusoHorario` descontinuada (D-CM-072). Sem mudança de código em relação à v1.7. Saem P-CM-050 e P-CM-053; segue em aberto P-CM-052. - **v1.7** (26/10/2026) — Destino passa à série v5.13 (Registro v1.12). E-CM-034 vira decisão (D-CM-067); perda de acesso a uma clínica (D-CM-068); `Conversa.IdEmpresa` e fonte do fuso confirmados (D-CM-069). Sem mudança de código em relação à v1.6, exceto: a Agenda do Médico passa a ter o mesmo filtro por `{ClinicasDoMedico}` (Mapeamento da Agenda v1.10). P-CM-050 reduzida ao nome do campo; novas P-CM-052 e P-CM-053; sai P-CM-051. - **v1.6** (26/10/2026) — Destino passa à série v5.12 (Registro v1.11). Nova mudança descrita: o médico vê só as clínicas em que atende, em vez de todas as clínicas do cliente (D-CM-066): tabela `{ClinicasDoMedico}` e filtros em todos os endpoints (seção 3.1), `{LimitesPorClinica}` só com as clínicas do médico (seção 3.2), linha de clínica quando atende em mais de uma, casos de teste com cliente de três clínicas. Novas escolhas a confirmar: E-CM-034. Sai a questão P-CM-049; entra P-CM-051. - **v1.5** (26/10/2026) — Destino passa à série v5.11 (Registro v1.10). Novas mudanças descritas: "hoje" e fim do dia das janelas de prescrição no fuso da clínica logada (D-CM-062, seção 3.2); `{LimitesPorClinica}` com uma linha por `Clinica` (E-CM-032); rótulo do alerta e "Em Tratamento" com a clínica logada (D-CM-063, seção 4.2); card de mensagem com a clínica e campo `clinic` em `conversations` (D-CM-064, E-CM-033; seções 3.1, 4.5 e nova 4.11); ligação das clínicas por `SegEmpresa` e `Clinica` (D-CM-065, seção 2); casos de teste novos da v5.10 e v5.11 descritos na seção 7 (lacuna da v1.4). Seção 8: saem E-CM-030 (D-CM-061), E-CM-031 e P-CM-048; novas E-CM-032, E-CM-033, P-CM-049 e P-CM-050. v1.4 arquivada em `Para Desenvolvedores/Histórico/Central do Médico - mudanças da v5 - guia para desenvolvimento v1.4.md`. - **v1.4** (26/10/2026) — Destino passa à série v5.10 (Registro v1.9). Novas mudanças descritas: escopo do cliente inteiro para agendas, prescrições e mensagens do médico (D-CM-060, seções 3.1, 4.5 e 4.10); janelas de prescrição por clínica (D-CM-060, E-CM-031, seção 3.2); `clinic` em `procedures` (E-CM-030); chips em peso regular (D-CM-056); campo em repouso com `neutral-light` (D-CM-057); prescrição já assinada não volta a "a assinar" (D-CM-059); "45min restantes" aprovado (D-CM-055); selo e número do KPI aprovados (D-CM-058). Corrigido na seção 4.2 o número do KPI de alertas, que ainda dizia `color-error-pure`. Seção 8: saem E-CM-020, E-CM-025, E-CM-026, P-CM-043, P-CM-046 e P-CM-047; novas E-CM-030, E-CM-031 e P-CM-048; E-CM-028 e E-CM-029 ajustadas. v1.3 arquivada em `Para Desenvolvedores/Histórico/Central do Médico - mudanças da v5 - guia para desenvolvimento v1.3.md`. - **v1.3** (26/10/2026) — Destino passa à série v5.9 (Registro v1.8). Novas mudanças descritas: desempate por nome do paciente (D-CM-047); campo `clinic` e escopo de todas as clínicas do cliente (D-CM-050, E-CM-028, E-CM-029); nova versão de prescrição nasce sem assinaturas (D-CM-052); `CHECK` de `Mensagem.Tipo` só com `Response` (D-CM-052, seção 2); selo "Atrasado" e número do KPI mais leves (D-CM-054, E-CM-026; seções 4.3 e 6, nova 4.9). Seção 8: saem E-CM-022, E-CM-023, P-CM-008, P-CM-026 (e), P-CM-044 e P-CM-045; novas E-CM-026 a E-CM-029, P-CM-046 e P-CM-047. v1.2 arquivada em `Para Desenvolvedores/Histórico/Central do Médico - mudanças da v5 - guia para desenvolvimento v1.2.md`. - **v1.2** (26/10/2026) — Destino passa à série v5.8. Novas mudanças descritas: v5.7 (D-CM-045: conversa não lida em `secondary-dark`, percentual da barra em 10 px) e v5.8 (D-CM-046: anel de foco de 2 px, campo de busca com borda de 2 px, chips de urgência leves, token `--color-field-changed` sem uso na Central). Seção 8.1: E-CM-003 resolvida, E-CM-004 reduzida a botões e toggles, novas E-CM-023 a E-CM-025; seção 8.2: novas P-CM-043 a P-CM-045. Revisão por Dois Críticos (26/10/2026): corrigidos o recuo do anel do card, o item 7 da seção 7 (divergências já decididas em D-CM-045) e a ressalva da seção 6. v1.1 arquivada em `Para Desenvolvedores/Histórico/Central do Médico - mudanças da v5 - guia para desenvolvimento v1.1.md`. - **v1.1** (21/10/2026) — Destino passa à série v5.6: seção 5 ganha a mudança de idioma e tradução (D-CM-044, DT-011, DT-012). - **v1.0** (20/10/2026) — Primeira versão. Revisão por Dois Críticos (técnico e negócio/UX) antes de fechar: achados aplicados (itens que já valiam na v4 e estavam como mudança, tabela de botões e avatar, chaves de i18n, detalhes do seed, massa de teste). Compara a série v4 (Definição v4.42, Especificação v4.37, Mapeamento v4.48) com a série v5.5 (Definição, Especificação, Protótipo, Mapeamento e Cenários v5.5; Registro de Decisões v1.4), a pedido do solicitante: "gere um documento com as diferenças que criamos desde a abertura da v5 para facilitar ao time de desenvolvimento os ajustes necessários."