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.

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)
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
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.”