02 - Especificação v4.25

Central do Médico (Cockpit) — Especificação (v4.25)

Documentos desta funcionalidade: 01 - Definição (v4.26) · 02 - Especificação (v4.25) · 03 - Protótipo (v3.13, código executável em 03 - Protótipo v3.13.html) · 04 - Mapeamento de Banco de Dados (v4.28)

---

SEÇÃO 2 — ESPECIFICAÇÃO

Premissa de design: Toda decisão de design nesta especificação é justificada pelos touchpoints de workflow documentados na Seção 1. Ao escolher um componente, definir uma ordenação, priorizar uma informação visualmente ou estabelecer um comportamento de navegação, a decisão apoia o fluxo real do profissional naquele momento específico do workflow. Consulte a seção “Workflows do Profissional” na Seção 1 para o contexto completo de cada touchpoint.

2.1 Cabeçalho (Header) com Busca de Pacientes

US-CM-000 — Buscar pacientes rapidamente

Como médico, quero buscar qualquer paciente pelo nome, CPF, data de nascimento ou nome da mãe diretamente do cabeçalho, para acessar o prontuário sem precisar navegar por menus.

Descrição Funcional:

O cabeçalho é a barra superior fixa da Central do Médico e contém 3 blocos:

1. Identificação da clínica: Nome da clínica onde o médico está logado (sem a unidade/local de atendimento — removido por decisão do responsável do projeto).
2. Campo de busca de pacientes: Campo de texto. A busca é inteligente e contextual:
   • O placeholder do campo deve ser MSG_searchPac para deixar explícito que é uma busca por pacientes.
   • Ao abrir o dropdown de resultados, exibir uma mensagem de orientação no rodapé da lista: MSG_searchFoot.
   • A primeira busca é acionada quando o usuário digita os primeiros 2 caracteres e para de digitar por 1 segundo. A partir desse primeiro disparo, a lista vai sendo filtrada dinamicamente conforme o usuário continua digitando, sem necessidade de novo intervalo de pausa.
   • A busca sempre retorna uma lista, pois o algoritmo busca por aproximação de termos. Se o usuário digitar “ay”, o sistema busca termos em torno de “ay”: “ay” será o mais prioritário, mas se não encontrar, retornará “ai”, “aj” e assim por diante.
   • Se a entrada começar com dígito, o sistema busca por CPF ou Data de Nascimento. Se começar com letra, busca por Nome do Paciente ou Nome da Mãe.
   • Os resultados da busca devem conter minimamente: nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF (conforme requisito SBIS ECF.03.14).
   • Ao selecionar um paciente na lista de resultados, o sistema abre o Prontuário Eletrônico do Paciente (PEP).
3. Menu do usuário: Avatar com foto do profissional (quando disponível) ou iniciais, com um ícone de dropdown (seta) ao lado. Não exibe nome, CRM ou especialidade do médico no cabeçalho (removido por decisão do responsável do projeto) — essas informações vivem dentro do menu, não como texto fixo visível. Clicar no avatar ou na seta abre um menu suspenso abaixo, à direita, com ações específicas do usuário. Por enquanto, o menu contém apenas “Sair”. Itens previstos para versões futuras (fora do escopo desta versão, ainda não especificados): autocadastro/edição de perfil, dados de faturamento e pagamento (conta bancária, PIX) e dados de especialidade (CRM, RQE). Clicar fora do menu ou selecionar um item o fecha.

Justificativa de workflow: A busca por pacientes no cabeçalho atende ao touchpoint ‘Antes de chamar o próximo paciente’ (Workflow 1) e ao touchpoint ‘Decidir se precisa intervir em um procedimento’ (Workflow 2). Em ambos os momentos, o médico pode precisar acessar um prontuário que não está visível nos painéis — a busca global no cabeçalho é o atalho universal, disponível em qualquer momento do turno.

Critérios de Aceitação:

• Dado que o médico digita “Ma” no campo de busca, quando ele para de digitar por 1 segundo, então o sistema deve retornar pacientes cujo nome ou nome da mãe contenham “Ma” ou termos aproximados, exibindo nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF.
• Dado que o médico digita “12” no campo de busca, quando ele para de digitar por 1 segundo, então o sistema deve buscar por CPF ou data de nascimento que contenham “12”.
• Dado que o médico digita apenas 1 caractere, então o sistema não deve disparar a busca, exibindo a mensagem MSG_searchMin no rodapé do dropdown.
• Dado que o médico digita “ay” e não existe paciente com esse termo exato, então o sistema deve retornar pacientes com termos próximos (aproximação), como “Ayla”, “Aymoré”, ordenados por relevância.
• Dado o médico seleciona um paciente na lista de resultados, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP), preservando o contexto do profissional logado.
  • Dado que a busca não retorna resultados, então o sistema deve exibir MSG_searchNone
• Dado que o médico clica no avatar ou na seta de dropdown, então o sistema deve abrir o menu do usuário abaixo, à direita, contendo ao menos o item “Sair”.
• Dado que o menu do usuário está aberto e o médico clica fora dele, então o sistema deve fechar o menu.
• Dado que o médico clica em “Sair” no menu, então o sistema deve encerrar a sessão (fluxo de logout fora do escopo deste documento).
• Dado que o cabeçalho é renderizado, então ele não deve exibir nome do médico, CRM, especialidade ou unidade/local de atendimento — apenas o nome da clínica à esquerda e o avatar com dropdown à direita.

Internacionalização:

Termo	pt-BR	en-US	es-419
MSG_searchPac	Procurar paciente…	Search Pacient…	Buscar paciente…
MSG_searchFoot	Digite parte do nome, CPF, data de nascimento ou nome da mãe para filtrar	Enter parte of the name, ID, mother’s name or DOB to filter	Ingrese parte del busque por nombre, ID, nombre de la madre o fecha de nacimiento
MSG_searchMin	Digite pelo menos 2 caracteres para iniciar a busca.	Type at least 2 characters to start searching.	Escriba al menos 2 caracteres para iniciar la búsqueda.
MSG_searchNone	Nenhum paciente encontrado com os dados informados.	No patient found with the provided data.	Ningún paciente encontrado con los datos informados.

---

2.2 KPI Bar (Indicadores)

US-CM-001 — Visualizar indicadores do dia

Como médico, quero ver um resumo numérico do meu dia (consultas, tratamentos, procedimentos na clínica e alertas) em uma barra no topo, para ter um panorama rápido sem precisar analisar cada painel.

Descrição Funcional:

Layout dos cards: Cada KPI card possui uma borda lateral esquerda colorida (4px) que identifica visualmente a categoria:

• Consultas Hoje → azul (color-secondary-pure),
• Em Tratamento → verde (color-primary-pure),
• Procedimentos Hoje → âmbar (color-highlight-pure),
• Alertas de Prescrição → vermelho (color-error-pure). O ícone do KPI fica posicionado à direita do texto. Motivador: a borda colorida permite identificação rápida da categoria mesmo em uma olhada periférica, sem necessidade de leitura do título.

Justificativa de workflow: Os 4 KPIs correspondem aos 4 workflows que a Central toca: Consultas Hoje (Workflow 1), Em Tratamento (Workflow 2), Alertas de Prescrição (Workflow 3) e Procedimentos Hoje (Workflow 2). No início do turno (touchpoint comum a todos os workflows), o médico precisa calibrar expectativas de carga de trabalho — os KPIs dão isso em um olhar, sem abrir nenhum painel. Cada KPI é clicável porque, após o panorama inicial, o médico pode precisar aprofundar em um workflow específico.

A KPI Bar é uma faixa horizontal entre o cabeçalho e o grid 2×2, contendo 4 cartões de indicadores fixos. Cada cartão é clicável e navega para a tela dedicada correspondente.

1. Consultas Hoje: Exibe “finalizadas/total” (ex: “4/6”). Subtexto: “X pendentes · Y atrasadas”.
   • Definição dos termos:
     • Pendentes: agendas que ainda não foram finalizadas
     • Atrasadas: agendas pendentes cuja hora marcada já passou
   • Ao clicar: abre a tela de Agenda de Consultas
2. Em Tratamento: Exibe o total de pacientes em tratamento (número principal) cujo médico assistente é o médico logado. Subtexto: ‘Y não aderentes’.
   • Definição dos termos:
     • Em tratamento (número principal): pacientes que estão em tratamento cujo médico assistente é o médico logado
     • Não aderentes: pacientes em tratamento que não estão conformes com o planejamento do tratamento (plano terapêutico) — pode ser por descompasso com os intervalos entre sessões e/ou ciclos previstos
   • Ao clicar: abre a tela de Pacientes do Médico
3. Procedimentos Hoje: Exibe o total de pacientes do médico logado com procedimentos (não consultas) previstos ou em andamento na unidade hoje. Subtexto: “X em atendimento · Y aguardando · Z previstos”.
   • Definição dos termos:
     • Em atendimento: pacientes do médico logado que já estão em procedimento (iniciaram quimioterapia, estão realizando cateterismo ou limpeza de cateter, iniciaram sessão radioterápica, iniciaram cirurgia, etc.)
     • Aguardando: pacientes do médico logado que estão na clínica (em check-in ou sendo preparados para o procedimento) mas ainda não iniciaram o procedimento
     • Previstos: pacientes do médico logado que ainda não chegaram à clínica mas têm procedimento previsto para o dia
   • Ao clicar: abre a tela de Procedimentos na Clínica
4. Alertas de Prescrição: Exibe o total de prescrições pendentes urgentes (menos de 12h para aplicação). Subtexto: “X p/ revisar · Y p/ assinar (próx. 7 dias)”.
   • Definição dos termos:
     • Urgentes (número principal): prescrições pendentes de assinatura E pendentes de revisão com menos de 12h para a aplicação agendada
     • P/ revisar: prescrições marcadas automaticamente pelo sistema como “a revisar” (agenda de aplicação a 1 dia ou menos e ainda sem revisão de nenhum médico — ver RN-CM-020)
     • P/ assinar (próx. 7 dias): prescrições pendentes de assinatura com aplicação prevista nos próximos 7 dias
   • Quando o valor principal (urgentes) for maior que zero, o número deve aparecer em vermelho (cor error-pure, f44336).
   • Ao clicar: abre a tela de Prescrições Pendentes

Critérios de Aceitação:

• Dado que o médico abre a Central, quando os dados são carregados, então a KPI Bar deve exibir os 4 indicadores com seus respectivos subtextos.
• Dado que o KPI de Alertas de Prescrição tem 3 prescrições urgentes, então o número “3” deve ser exibido em vermelho (#F44336).
• Dado que o KPI de Alertas de Prescrição tem 0 urgentes, então o número “0” deve ser exibido na cor padrão (não vermelho).
• Dado que o médico clica no card “Consultas Hoje”, então o sistema deve navegar para a tela de Agenda de Consultas.
• Dado que o médico clica no card “Em Tratamento”, então o sistema deve navegar para a tela de Pacientes do Médico.
• Dado que o médico clica no card “Procedimentos Hoje”, então o sistema deve navegar para a tela de Procedimentos na Clínica.
• Dado que o médico clica no card “Alertas de Prescrição”, então o sistema deve navegar para a tela de Prescrições Pendentes.
• Dado que o endpoint de KPIs falha, então a KPI Bar deve exibir ”—” nos valores e os demais painéis devem continuar operando normalmente.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
Card Consultas Hoje - título	CONSULTAS HOJE	TODAY’S APPOINTMENTS	CONSULTAS DE HOY
Card Consultas Hoje - pendentes	pendentes	pending	pendientes
Card Consultas Hoje - atrasadas	atrasadas	delayed	atrasada
Card Em tratamento - título	EM TRATAMENTO	IN TREATMENT	EN TRATAMIENTO
Card Em tratamento - não aderentes	não aderentes	non-adherent	no adherentes
Card Procedimentos hoje - título	PROCEDIMENTOS HOJE	TODAY’S PROCEDURES	PROCEDIMIENTOS HOY
Card Procedimentos hoje - em atendimento	em atendimento	in progress	en atención
Card Procedimentos hoje - aguardando	aguardando	waiting	en espera
Card Procedimentos hoje - previstos	previstos	scheduled	programados
Card Alertas de prescrição = título	ALERTAS DE PRESCRIÇÃO	PRESCRIPTION ALERTS	ALERTAS DE PRESCRIPCIÓN
Card Alertas de prescrição - revisar	p/revisar	to review	p/revisar
Card Alertas de prescrição - assinar	p/assinar (próx. 7 dias)	to sign (next 7 days)	p/firmar (próx. 7 dias)

---

2.3 Painel de Consultas (Quadrante Superior Esquerdo)

US-CM-002 — Visualizar consultas do dia

Como médico, quero ver minhas consultas do dia em ordem cronológica com informações clínicas relevantes, para organizar meu fluxo de atendimento.

US-CM-003 — Filtrar consultas pendentes

Como médico, quero alternar entre “Todas” e “Pendentes” no painel de consultas, para focar apenas nas consultas que ainda não foram realizadas.

Descrição Funcional:

O painel de Consultas exibe a agenda do médico para o dia, composta por cards de consulta. Cada card contém:

• Hora prevista da consulta e hora prevista de término (ou tempo previsto da consulta)
• Nome do paciente com foto (avatar com iniciais ou foto, quando disponível)
• Diagnóstico(s) oncológico(s) (se houver — ex: “Ca. Mama”; um paciente pode ter mais de um diagnóstico oncológico ativo, e todos são exibidos)
• Tipo de consulta (Presencial / Teleatendimento)
• Tags de atenção (se houver — ex: VIP, Quimioterapia, 1ª Consulta)
• Status da agenda (Agendado, Aguardando Recepção, Recepcionado, Em Atendimento, Finalizado)

Ordenação: A lista deve estar ordenada pela hora agendada. Consultas finalizadas permanecem na sua posição original na ordem cronológica.

Filtro: Deve haver um toggle em estilo pill (botões com borda discreta e fundo branco) entre ‘Todas’ e ‘Pendentes’. O default é mostrar apenas as pendentes (oculta finalizadas). Ao alternar para ‘Todas’, as finalizadas aparecem na sua posição original esmaecidas. Motivador: o estilo pill é mais discreto que o bloco cinza anterior, competindo menos com o conteúdo dos cards.

Tratamento visual de finalizadas: Consultas finalizadas devem aparecer esmaecidas (cor de fundo mais clara e opacidade reduzida), mantendo a ordem cronológica da agenda. Não são movidas para o final da lista — permanecem na sua posição original, apenas com sinalização visual de que já foram concluídas.

Atraso: Quando o paciente está atrasado (horário agendado já passou e a consulta não foi iniciada nem finalizada), mostrar um sinalizador de “Atrasado” com o tempo de atraso em minutos (ex: ”🔴 15min”).

Cores de status: Agendado ffe0b3, Aguardando Recepção ffc5c1, Recepcionado b7e3ff, Em Atendimento d1df9d, Finalizado 9679e1.

Destaque visual por status: Além dos chips coloridos, cards com status “Recepcionado” recebem uma borda lateral esquerda (3px) na cor secondary-pure (azul), sinalizando que o paciente está pronto para atendimento. Cards com status “Aguardando Recepção” recebem borda lateral esquerda (3px) na cor ff8a80 (vermelho-claro), sinalizando que o paciente está presente na clínica. Outros status não recebem borda adicional. Motivador: a borda colorida é consistente com o padrão de KPI cards e permite identificação periférica dos pacientes prontos para atendimento sem necessidade de leitura do chip.

Navegação: O título do painel (‘Consultas’) é um link clicável para a tela dedicada da Agenda do Médico. No hover, o título muda de cor e uma seta (→) aparece ao lado. Ao clicar em qualquer card de consulta, o sistema abre o Prontuário Eletrônico do Paciente (PEP). Motivador: o título como link elimina a necessidade de um botão separado ‘Ver agenda →’, reduzindo ruído visual no cabeçalho do painel.

Justificativa de workflow: Este painel atende ao touchpoint ‘Antes de chamar o próximo paciente’ (Workflow 1). O toggle default ‘Pendentes’ reflete que, neste momento do workflow, o médico só precisa ver quem falta atender. O badge de atraso reflete a exceção do workflow onde o horário passou e o paciente não foi chamado. O clique no card abrindo o PEP reflete que, neste momento, o médico precisa do prontuário para se preparar antes de chamar o paciente.

Estado vazio: Quando não há consultas agendadas, exibir ícone de calendário vazio com a mensagem MSG_appointmentNone.

Critérios de Aceitação:

• Dado que o médico abre a Central, quando o painel de Consultas carrega, então o default deve mostrar apenas consultas pendentes, ordenadas por hora agendada.
• Dado que o médico clica no toggle “Todas”, então as consultas finalizadas devem aparecer na sua posição original esmaecidas (cor de fundo mais clara e opacidade reduzida).
• Dado que uma consulta agendada para 09:00 não foi iniciada e são 09:15, então o sistema deve exibir o sinalizador ”🔴 Atrasado · 15min” no card da consulta.
• Dado que o médico clica em qualquer card de consulta, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP).
• Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada da Agenda do Médico.
• Dado que não há consultas agendadas no dia, então o painel deve exibir “Nenhuma agenda para este dia” (MSG_appointmentNone).
• Dado que uma consulta tem status “Recepcionado”, então o card deve exibir borda lateral esquerda na cor secondary-pure (azul).
• Dado que uma consulta tem status “Aguardando Recepção”, então o card deve exibir borda lateral esquerda na cor ff8a80.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
painel-título	Consultas	Appointments	Consultas
toggle-todas	Todas	All	Todas
toggle-pendentes	Pendentes	Pending	Pendientes
chip-atrasado	Atrasado	Delayed	Atrasado
status-agendado	Agendado	Shceduled	Agendada
status-aguardando	Aguardando recepção	Waiting reception	Esperando recepción
status-recepcionado	Recepcionado	Checked-in	Recepcionado
status-atendimento	Em Atendimento	In consulation	En atención
status-finalizado	Finalizado	Completed	Finalizado
MSG_appointmentNone	Nenhuma agenda para este dia	No appointments for this day	No hay citas para este día

---

2.4 Painel de Prescrições Pendentes (Quadrante Superior Direito)

US-CM-004 — Visualizar prescrições pendentes

Como médico, quero ver as prescrições pendentes de assinatura ou revisão ordenadas por prioridade, para priorizar as que têm menos tempo até a aplicação agendada.

US-CM-005 — Assinar prescrição

Como médico, quero revisar e assinar prescrições pendentes diretamente no Cockpit, para que a farmácia possa liberar o medicamento a tempo.

US-CM-006 — Revisar prescrição

Como médico, quero revisar e confirmar prescrições que o sistema marcou automaticamente como pendentes de revisão perto da aplicação, para garantir que algum médico validou a prescrição antes da administração ao paciente.

Descrição Funcional:

O painel de Prescrições Pendentes lista as prescrições que aguardam ação do médico, divididas em duas categorias:

1. Prescrições para assinar — aguardando assinatura digital do médico
2. Prescrições para revisar — marcadas automaticamente pelo sistema quando a agenda de aplicação está a 1 dia (24h) ou menos da data/hora atual e a prescrição ainda não foi revisada por nenhum médico (RN-CM-020). Uma prescrição só entra nessa categoria depois de já assinada — é uma segunda barreira de segurança, independente e posterior à assinatura, não relacionada a notificações de farmácia ou enfermagem.

Cada card de prescrição contém:

• Nome do paciente (nome social, se houver; caso contrário nome civil) — o endpoint envia ambos (preferredName/legalName, mesmo padrão do painel de Consultas e de Procedimentos) para o médico perceber uma eventual questão de nome social/gênero antes de abrir a prescrição
• Código da prescrição, no formato “Protocolo CxDy” (ex: “CARBO-TAXOL C3D1”, onde C = ciclo e D = dia/sessão) — vem pronto do banco (Prescricao.Identificacao), sem montagem de protocolo e ciclo como campos separados
• Data da agenda da aplicação agendada (ex: “22/07 18:00”) — importante principalmente para prescrições pendentes de revisão, pois a data é o próprio motivo pelo qual a prescrição está nessa lista
• Tempo restante até a aplicação agendada (ex: “8h restantes”)
• Tipo de ação (Assinar ou Revisar)
• No caso de revisões: destaque visual (não texto com nomes de terceiros) quando o médico logado é revisor preferencial — prescritor ou médico assistente do paciente (RN-CM-020)

Ordenação: As prescrições devem ser ordenadas por prioridade — quanto mais próxima da data de aplicação agendada, mais prioritária é. As prescrições com menos de 12 horas restantes são classificadas como “Críticas” e marcadas com chip vermelho (fundo ffebee, texto d32f2f). Entre 12h e 24h, são “Atenção” e marcadas com chip laranja (fundo fff8e1, texto ff8f00).

Filtro “Meus / Todos”: O painel tem um toggle em estilo pill entre “Meus” e “Todos”, que afeta apenas as prescrições para revisar — as prescrições para assinar já são, por definição, sempre do médico logado (RN-CM-012: só o próprio prescritor assina) e por isso aparecem em ambos os estados do toggle, sem alternância. “Meus” mostra apenas as prescrições a revisar em que o médico logado é o prescritor ou o médico assistente do paciente (revisor preferencial, RN-CM-020). “Todos” mostra todas as prescrições a revisar de qualquer médico da clínica, somadas às prescrições a assinar do próprio médico logado. O default é “Meus” — consistente com o padrão do painel de Procedimentos — porque as prescrições a assinar nunca são escondidas pelo toggle; o filtro só decide o quanto o médico quer ver do trabalho de revisão de colegas.

Assinatura (tela de assinatura): Ao clicar em “Assinar”, o sistema abre a tela de assinatura com a prescrição completa para que o médico revise e se certifique de que é a prescrição correta. É responsabilidade do médico saber o que está assinando — a assinatura não pode ser um clique direto sem revisão. A tela exibe todos os medicamentos, doses, vias, diluentes e instruções. Após revisão, o médico clica em “Assinar” na tela, que processa a assinatura conforme o modo configurado (com ou sem certificado digital). Em caso de sucesso, o sistema exibe um toast de sucesso “Prescrição assinada com sucesso” e retorna automaticamente à Central do Médico, focada no painel de Prescrições Pendentes, com o KPI de Alertas atualizado. Em caso de erro, exibir toast de erro na tela de assinatura.

Revisão (tela de revisão): Ao clicar em “Revisar”, o sistema abre a prescrição completa (medicamentos, doses, vias, diluentes e instruções) para o médico validar. O médico tem duas opções: (a) confirmar que a prescrição está correta, clicando em “Marcar como Revisada” — o sistema registra o médico revisor e o timestamp, e a prescrição sai da lista de pendentes; ou (b) identificar necessidade de ajuste e editar a prescrição, recalculando, adicionando ou retirando medicamentos. Nesse segundo caso, o sistema cancela a prescrição atual e cria uma nova versão com os itens ajustados — como é uma prescrição nova, ela precisa ser assinada novamente pelo médico (mesmo fluxo de assinatura de uma prescrição inédita) antes de sair da lista de pendentes; a edição por si só não conta como revisão. Em ambos os casos, o sistema retorna automaticamente à Central do Médico, focada no painel de Prescrições Pendentes, com o contador atualizado.

Assinatura digital: A assinatura pode ocorrer de 2 modos, conforme configuração do cliente:

• (a) Assinatura com certificado digital — exige certificado ativo vinculado ao perfil do médico
• (b) Assinatura sem certificado — validada pela sessão do usuário logado

Navegação: O título do painel (‘Prescrições Pendentes’) é um link clicável para a tela dedicada. No hover, o título muda de cor e uma seta (→) aparece ao lado.

Justificativa de workflow: Este painel atende aos touchpoints ‘Assinar prescrições pendentes’ e ‘Confirmar que a prescrição foi revisada por um médico antes da administração ao paciente’ (Workflow 3). O botão ‘Assinar’ abre a tela de assinatura com a prescrição completa porque é responsabilidade do médico saber o que está assinando — a assinatura não pode ser um clique direto sem revisão. Os chips de urgência (vermelho/laranja) refletem que, no workflow, a prioridade é cronológica: quanto menos tempo até a aplicação, mais urgente — e essa lógica vale igualmente para prescrições pendentes de assinatura e de revisão (RN-CM-020), já que ambas representam risco crescente conforme a aplicação se aproxima. A prescrição completa é sempre exibida para revisão porque o médico precisa validar o que está confirmando, não apenas um resumo. O retorno automático à Central após assinar ou revisar reflete que o médico precisa voltar ao seu fluxo de trabalho sem navegação manual. O toggle “Meus/Todos” atende ao touchpoint ‘Ao revisar prescrições’: no workflow, o médico prioriza naturalmente seus próprios pacientes, mas precisa poder ajudar a revisar as de colegas ausentes — daí a possibilidade de alternar sem sair da tela.

Estado vazio: Quando não há prescrições pendentes, exibir ícone de check com a mensagem MSG_prescriptionNone.

Critérios de Aceitação:

• Dado que uma prescrição possui 10 horas restantes para aplicação, então o sistema deve renderizar o chip de tempo com fundo vermelho claro (#FFEBEE) e texto em vermelho (#D32F2F), e o KPI de Alertas deve exibir o valor em vermelho.
• Dado que uma prescrição possui 18 horas restantes, então o sistema deve renderizar o chip com fundo laranja claro (#FFF8E1) e texto laranja (#FF8F00).
• Dado que o médico clica em “Assinar” em uma prescrição, então o sistema deve abrir a tela de assinatura com a prescrição completa para revisão.
• Dado que o médico clica em “Assinar” na tela de assinatura, quando a assinatura é validada (via certificado ou sessão, conforme configuração), então o sistema deve exibir toast de sucesso, retornar automaticamente à Central do Médico focada no painel de Prescrições Pendentes, e o KPI de Alertas deve subtrair uma unidade.
• Dado que o médico clica em “Assinar” na tela de assinatura e a assinatura falha, então o sistema deve exibir um toast de erro na tela de assinatura: “Falha na validação da assinatura. Verifique seu certificado ou tente novamente.”
• Dado que uma prescrição assinada tem aplicação agendada para 1 dia (24h) ou menos a partir de agora e ainda não foi revisada, então o sistema deve marcá-la automaticamente como “a revisar” e exibi-la no painel com ação “Revisar” (RN-CM-020).
• Dado que o médico clica em “Revisar”, então o sistema deve abrir a prescrição completa, permitindo confirmar a revisão (“Marcar como Revisada”) ou editar a prescrição.
• Dado que o médico clica em “Marcar como Revisada”, então o sistema deve registrar o médico revisor e o timestamp, exibir toast de sucesso, remover a prescrição da lista de pendentes e retornar automaticamente à Central do Médico focada no painel de Prescrições Pendentes.
• Dado que o médico edita a prescrição na tela de revisão e clica em “Gravar”, então o sistema deve cancelar a prescrição atual, criar uma nova versão com os itens ajustados e exigir que o médico assine essa nova versão (mesmo fluxo de assinatura), retornando automaticamente à Central do Médico focada no painel de Prescrições Pendentes após a assinatura.
• Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada de Prescrições Pendentes.
• Dado que não há prescrições pendentes, então o painel deve exibir “Sem prescrições pendentes” (MSG_prescriptionNone).
• Dado que a prescrição tem protocolo “CARBO-TAXOL” no Ciclo 3, Dia 1, então o sistema deve exibir o código da prescrição como recebido do endpoint (prescriptionCode), ex: “CARBO-TAXOL C3D1”, sem remontar a string a partir de campos separados.
• Dado que o card de prescrição exibe a data da agenda, então o formato deve ser “dd/MM HH:mm” (ex: “22/07 18:00”).
• Dado que o painel é carregado, então o toggle “Meus/Todos” deve iniciar na posição “Meus”.
• Dado que o médico ativa o toggle “Meus”, então o painel deve exibir apenas as prescrições a revisar em que o médico logado é o prescritor ou o médico assistente do paciente, mantendo visíveis todas as prescrições a assinar do médico logado (estas não são afetadas pelo toggle).
• Dado que o médico ativa o toggle “Todos”, então o painel deve exibir todas as prescrições a revisar da clínica, somadas às prescrições a assinar do médico logado.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
painel-título	Prescrições Pendentes	Pending Prescriptions	Prescripciones Pendientes
botão-assinar	Assinar	Sign	Firmar
botão-revisar	Revisar	Review	Revisar
chip-T_restante	T RESTANTES	T REMAINING	T RESTANTES
MSG_prescriptionNone	Sem prescrições pendentes	No pending prescriptions	Sin prescripciones pendientes
MSG_prescriptionSigned	Prescrição assinada com sucesso	Prescription signed successfully	Prescripción firmada con éxito
MSG_prescriptionSignError	Falha na validação da assinatura. Verifique seu certificado ou tente novamente.	Signature validation failed. Check your certificate or try again.	Fallo en la validación de la firma. Verifique su certificado o intente nuevamente.
toggle-meus	Meus	Mine	Míos
toggle-todos	Todos	All	Todos

---

2.5 Painel de Notificações (Quadrante Inferior Esquerdo)

Modelo de dados de Conversas e Alertas (IP.Mensageria, ver documento “Conversas-e-Alertas”): o que seria uma “mensagem” avulsa é uma Conversa (thread), que pode acumular várias Mensagem — o médico pode responder, não só resolver/descartar. Escopo do painel: este painel compacto do Cockpit mostra todas as conversas em aberto do médico logado — lidas e não lidas —, priorizando as não lidas na ordenação; uma conversa só deixa de aparecer aqui quando é resolvida ou descartada. Uma tela dedicada, ainda não especificada neste documento, mostrará também as conversas já finalizadas (resolvidas ou descartadas), formando o histórico completo.

US-CM-007 — Receber conversas e alertas internos

Como médico, quero ver conversas e alertas da equipe (recepção, farmácia, enfermagem) e do próprio sistema, ordenados por prioridade, para responder solicitações e recados sem precisar acessar outra tela.

US-CM-008 — Arquivar conversa resolvida

Como médico, quero marcar uma conversa como resolvida ou descartá-la com um clique, para manter minha lista enxuta e o foco nas pendentes.

US-CM-012 — Responder rapidamente

Como médico, quero responder uma conversa com uma frase curta direto do Cockpit, para esclarecer algo simples sem precisar telefonar ou sair do meu fluxo de trabalho.

Descrição Funcional:

O painel de Notificações exibe todas as Conversa do médico logado que ainda não estão em estado final (Status diferente de Resolvida e Descartada), estejam lidas ou não lidas para ele (ver definição de “não lida” em RN-CM-015). Ler uma conversa (abrir o modal, ou responder) não a remove do painel — ela permanece visível, mas passa para o grupo de prioridade reduzida na ordenação (ver “Ordenação” abaixo), perdendo o destaque visual de não lida. Motivador: uma conversa aberta ainda pode estar pendente de alguma ação do médico (resolver, descartar, aguardar retorno) mesmo depois de lida — escondê-la do painel faria o médico perder o rastro dela até a próxima atividade, obrigando-o a confiar na memória para lembrar do que ficou em aberto. O histórico completo (incluindo as já resolvidas/descartadas) continua reservado à tela dedicada mencionada acima. Uma conversa chega ao médico de duas formas: enviada diretamente a ele (Conversa.IdUsuarioDestino, quando DestinoTipo = 'User'), ou enviada a uma equipe da qual ele é membro (Conversa.EquipeId, quando DestinoTipo = 'Team'; o vínculo individual de cada destinatário fica registrado em ConversaDestinatario.EquipeOrigemId). Cada card contém:

• Ícone identificador: bell da biblioteca Lucide para alertas automáticos (OrigemTipo = 'System'); ícone genérico de pessoa para qualquer conversa aberta por um usuário (OrigemTipo = 'User'), seja ela endereçada a um indivíduo ou a uma equipe. O ícone não varia por equipe (recepção/farmácia/enfermagem) — quando o autor responde como membro de uma equipe, a identificação vem do texto do nome (item abaixo, e RN-CM-022), não de um ícone diferente.
• Texto da última mensagem da thread (não necessariamente a inicial — se a equipe respondeu depois do médico, o card mostra a resposta mais recente)
• Nome de quem escreveu a última mensagem, com timestamp (ex: “Há 15 min · Sandra”; para alertas automáticos, “Há 15 min · Sistema”). Quando quem escreveu é membro de uma equipe respondendo em nome dela (conversa endereçada à equipe — DestinoTipo = 'Team', autor membro dessa Equipe), o nome da equipe aparece junto, em toda mensagem dela, não só na primeira (ex: “Há 15 min · Sandra (Farmácia)”) — RN-CM-015, RN-CM-022
• Prazo (opcional): quando Conversa.PrazoEmUtc está definido, exibir no card (ex: ”⏰ Responder até 14:00”)
• Selo de status quando a conversa já foi respondida pelo médico em algum momento (Status = Respondida) mas voltou a ficar não lida por nova atividade — sinaliza que a resposta já foi dada e há algo novo desde então, diferenciando de uma conversa nunca respondida
• Quando Conversa.PacienteId está definido, um link com o nome do paciente relacionado, permitindo abrir o contexto clínico diretamente (o painel não concede acesso ao prontuário por si só — a autorização continua sendo validada pelo módulo de destino, conforme a fronteira de responsabilidade do IP.Mensageria)

Conversas não lidas: Uma conversa está não lida para o médico logado quando Conversa.UltimaSequencia > ConversaLeitura.UltimaSequenciaLida (ou quando não existe ConversaLeitura para ele ainda) — essa condição não filtra quais conversas aparecem no painel (todas as não finalizadas aparecem, lidas ou não), mas determina dois efeitos: (a) o destaque visual — ícone na cor de destaque (primary-pure) e borda lateral esquerda em secondary-pure, aplicados somente aos cards não lidos; cards já lidos usam a borda neutra padrão (transparente) e o ícone na cor neutra; (b) a camada de prioridade na ordenação (ver “Ordenação” abaixo). Ao abrir o modal da conversa, o sistema grava ConversaLeitura.UltimaSequenciaLida = Conversa.UltimaSequencia para aquele médico; o card perde o destaque visual e migra para a camada de prioridade reduzida na próxima atualização da lista, mas permanece no painel — para os demais membros de uma equipe, o indicador de não lida permanece intacto (leitura é individual). Não é utilizado negrito no texto — a distinção visual vem exclusivamente do ícone colorido e da borda lateral (RN-CM-019).

Ordenação: As conversas são ordenadas em duas camadas. Primeiro, por estado de leitura: todas as conversas não lidas aparecem antes de todas as lidas — uma conversa lida nunca aparece à frente de uma não lida, mesmo que tenha prazo mais próximo ou atividade mais recente. Dentro de cada camada, os mesmos dois critérios decidem a ordem (proposta do Designer para manter consistência entre as duas camadas — critério de desempate das lidas a confirmar com o solicitante):

1. Prazo (PrazoEmUtc, quando definido) — conversas com prazo mais próximo aparecem primeiro
2. Atividade mais recente (LIFO) — para conversas sem prazo, a com a mensagem mais recente aparece primeiro

Ação no card: Cada card exibe um botão “Resolvido” que muda Conversa.Status para Resolvida, removendo o card da lista. O contador do painel deve ser atualizado. Isso é uma mudança de estado, não uma exclusão — a conversa continua existindo (auditável), só sai da visão de pendentes.

Ação ao clicar no card: Ao clicar no card, o sistema abre um modal com a thread completa (todas as Mensagem da conversa, em ordem, cada uma com autor e timestamp), o prazo (se houver) e três ações:

• Campo de texto + botão “Responder” — envia uma nova Mensagem (Tipo = 'Response'), atualiza Conversa.UltimaSequencia e muda Status para 'Responded'. A conversa permanece na lista (responder não é uma ação terminal) — o médico pode continuar acompanhando até que a equipe confirme ou até resolver/descartar.
• “Resolvido” — mesma função do botão no card.
• “Descartado” — muda Conversa.Status para Descartada. Isso não exclui a conversa (o modelo de dados é append-only, preserva histórico/auditoria) — apenas sai da lista de pendentes, com o mesmo efeito visual de “Resolvido” para o médico. Motivador: o descarte permite remover conversas informativas ou irrelevantes que não exigem resposta, sem marcá-las como resolvidas — a distinção fica registrada para quem precisar auditar depois.

Conversas do sistema (alertas automáticos): Geradas por módulos da plataforma (ex: Prescrição, Infusão, Agenda) via AlertaPublicacao, com chave de idempotência garantindo que retries não dupliquem o alerta. Usam o ícone bell da biblioteca Lucide e seguem as mesmas regras de ordenação, destaque de não lidas e ações — exceto “Responder”, que não se aplica a alertas puramente informativos sem um destinatário humano do outro lado (o front deve ocultar o campo de resposta quando OrigemTipo = 'System', mantendo apenas Resolvido/Descartado). O remetente exibido é “Sistema”. Se a mesma anomalia recorrer depois que a conversa anterior foi resolvida ou descartada, uma nova Conversa é criada apontando para a anterior via ConversaAnteriorId — o médico vê um alerta novo, não a reabertura do antigo.

Padrão de internacionalização (i18n) para mensagens do sistema:

As mensagens geradas pelo sistema devem ser documentadas com suas versões em português (pt-BR), inglês (en-US) e espanhol (es-419), conforme tabela padrão abaixo:

Código da mensagem	pt-BR	en-US	es-419
SYS_PRESC_URGENT	Prescrição urgente: menos de 12h para aplicação de {paciente}.	Urgent prescription: less than 12h until application for {patient}.	Prescripción urgente: menos de 12h para aplicación de {paciente}.
SYS_PRESC_REVIEW	Prescrição de {paciente} pendente de revisão antes da aplicação.	Prescription for {patient} pending review before application.	Prescripción de {paciente} pendiente de revisión antes de la aplicación.
SYS_INFUSION_DELAY	Infusão de {paciente} ultrapassou o tempo previsto.	Infusion for {patient} exceeded expected time.	Infusión de {paciente} superó el tiempo previsto.
SYS_PATIENT_CHECKIN	{paciente} fez check-in na recepção.	{patient} checked in at reception.	{paciente} hizo check-in en recepción.
SYS_SESSION_REMINDER	Lembrete: {paciente} tem sessão prevista para {horario}.	Reminder: {patient} has session scheduled for {time}.	Recordatorio: {paciente} tiene sesión programada para {horario}.

Convenções da tabela:

• Variáveis entre chaves {} são substituídas dinamicamente pelo sistema
• O código da mensagem (SYS_*) é usado internamente para identificação e não é exibido ao usuário
• Cada mensagem de sistema corresponde ao Conteudo da Mensagem inicial de uma Conversa com OrigemTipo = 'System'
• Novas mensagens do sistema devem ser adicionadas a esta tabela como padrão de documentação
• A tradução para o idioma do usuário é feita no backend; o frontend recebe a mensagem já traduzida

Navegação: O título do painel (‘Notificações’) é um link clicável para a tela dedicada de Mensagens. No hover, o título muda de cor e uma seta (→) aparece ao lado.

Justificativa de workflow: Este painel atende aos touchpoints ‘Receber conversas e alertas da equipe’ e ‘Responder sem sair do Cockpit’ (Workflow 4). O painel manter conversas lidas visíveis, mas em prioridade reduzida, reflete que, neste espaço compacto do Cockpit, o médico precisa ver “o que está pendente de atenção agora” sem perder de vista o que já leu mas ainda não encerrou — uma conversa já lida deixa de competir pela atenção imediata dele, mas continua acessível até ser resolvida ou descartada, evitando que ele precise confiar na memória para lembrar do que ficou em aberto. O destaque visual e a prioridade das não lidas refletem que, no workflow, conversas não lidas são as pendências que mais competem com a atenção do médico agora. A ordenação por prazo reflete que conversas com prazo são compromissos no workflow. O campo de resposta no modal reflete que muitas dúvidas simples podem ser resolvidas com uma frase, sem justificar uma tela de chat separada. O botão ‘Resolvido’ com um clique reflete que resolver é uma ação frequente e repetitiva no dia do médico. O botão ‘Descartado’ reflete que algumas conversas são puramente informativas e não exigem resposta — o médico precisa removê-las da lista sem marcá-las como resolvidas.

Estado vazio: Quando não há nenhuma conversa não finalizada (lida ou não lida) para o médico logado, exibir ícone de balão vazio com a mensagem MSG_notificationNone. Conversas já lidas, mas ainda em aberto, contam como conteúdo do painel — não disparam o estado vazio.

Critérios de Aceitação:

• Dado que chega uma nova conversa da farmácia, quando os dados são atualizados, então o card deve aparecer com o ícone na cor primary-pure e borda lateral esquerda na cor secondary-pure (sem negrito no texto).
• Dado que o médico abre o modal de uma conversa não lida, então o sistema deve gravar ConversaLeitura.UltimaSequenciaLida = Conversa.UltimaSequencia para aquele médico, e o card deve perder o destaque visual de não lida e migrar para depois das conversas não lidas na atualização seguinte da lista — sem sair do painel.
• Dado que duas conversas da mesma camada de leitura (ambas não lidas, ou ambas lidas) têm prazo definido, quando a lista é renderizada, então a conversa com prazo mais próximo deve aparecer primeiro dentro daquela camada.
• Dado que conversas sem prazo existem dentro de uma mesma camada de leitura, então elas devem ser ordenadas pela atividade mais recente (LIFO), após as conversas com prazo daquela camada.
• Dado que existem conversas lidas e não lidas ao mesmo tempo, quando a lista é renderizada, então todas as não lidas devem aparecer antes de todas as lidas, independentemente de prazo ou atividade.
• Dado que o médico digita uma resposta no modal e clica em “Responder”, então o sistema deve gravar uma nova mensagem na thread, mudar o status da conversa para “Respondida”, marcar a conversa como lida para o médico (a própria resposta conta como leitura) e migrá-la para a camada de prioridade reduzida do painel, sem removê-la — a menos que já exista atividade não vista por ele antes da resposta, caso em que ela permanece na camada de não lidas.
• Dado que uma conversa já foi respondida pelo médico e uma nova mensagem chega depois disso, então a conversa deve retornar à camada de não lidas do painel (destaque visual restaurado), com o selo indicando que já houve resposta anterior.
• Dado que o médico clica em “Resolvido” no card ou no modal, então o status da conversa deve mudar para “Resolvida”, o card deve ser removido da lista e o contador do painel deve ser atualizado.
• Dado que o médico clica no card de uma conversa, então o sistema deve abrir um modal com a thread completa, contendo o campo de resposta e os botões “Resolvido” e “Descartado”.
• Dado que o médico clica em “Descartado” no modal, então o status da conversa deve mudar para “Descartada” (sem excluir o registro), o card deve ser removido da lista e o contador do painel deve ser atualizado.
• Dado que a conversa é um alerta automático (OrigemTipo = 'System'), então o modal não deve exibir o campo de resposta, apenas “Resolvido” e “Descartado”.
• Dado que o médico clica no título do painel, então o sistema deve navegar para a tela dedicada de Comunicação/Mensagens (fora do escopo desta versão — mostrará também as conversas já finalizadas, resolvidas ou descartadas).
• Dado que não há nenhuma conversa não finalizada (lida ou não lida) para o médico logado, então o painel deve exibir “Sem notificações pendentes” (MSG_notificationNone).
• Dado que o médico enviou (ou recebeu) uma conversa endereçada à equipe de Farmácia (não a uma pessoa específica), quando Sandra — membro dessa equipe — responde pela thread, então tanto o card quanto o modal da thread completa devem exibir “Sandra (Farmácia)” como autor da mensagem, em vez de apenas “Sandra”, em toda mensagem que ela escrever nessa conversa (não só na primeira resposta).
• Dado que Carla — que não é membro da equipe de destino da conversa — responde numa conversa endereçada a um indivíduo (não a uma equipe), então o card e o modal devem exibir apenas “Carla”, sem sufixo de equipe.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
painel-título	Notificações	Notifications	Notificaciones
botão-resolvido	Resolvido	Resolved	Resuelto
botão-descartado	Descartado	Discarded	Descartado
botão-responder	Responder	Reply	Responder
placeholder-resposta	Escreva uma resposta…	Write a reply…	Escriba una respuesta…
chip-respondida	Respondida	Replied	Respondida
label-há	Há T	T ago	Hace T
label-prazo-responder	Responder até T	Reply by T	Responder antes de T
MSG_notificationNone	Sem notificações pendentes	No pending notifications	Sin notificaciones pendientes
MSG_conversationResolved	Conversa marcada como resolvida	Conversation marked as resolved	Conversación marcada como resuelta
MSG_conversationDiscarded	Conversa descartada	Conversation discarded	Conversación descartada
MSG_replySent	Resposta enviada	Reply sent	Respuesta enviada

---

2.6 Painel de Procedimentos na Clínica (Quadrante Inferior Direito)

US-CM-009 — Monitorar procedimentos na clínica

Como médico, quero ver todos os pacientes presentes na unidade com seus status e localização, para planejar visitas e saber quem está disponível para atendimento.

US-CM-010 — Acompanhar tempo de atendimento

Como médico, quero ver o progresso do atendimento de pacientes em tratamento com barra de tempo, para saber quanto tempo já passou e se está dentro do previsto.

US-CM-011 — Filtrar meus pacientes na clínica

Como médico, quero filtrar a lista de pacientes na clínica para mostrar apenas os meus, para me concentrar nos pacientes sob minha responsabilidade.

Descrição Funcional:

O painel de Procedimentos na Clínica monitora pacientes previstos e presentes na unidade para procedimentos terapêuticos e diagnósticos (infusões, aplicações, checagens) — não inclui consultas médicas, apenas procedimentos.

Cada card de paciente contém:

• Nome do paciente com avatar
• Prescrição do procedimento (ex: “AC-T C2D14”, “Paclitaxel C1D8”)
• Local na clínica (ex: “Consultório 4”, “Sala de Infusão 2”)
• Status do procedimento (Agendado, Aguardando recepção, Recepcionado, Preparo, Em administração, Completo ou Finalizado — domínio completo em ProcedureStatus(), Seção 4.3/4.4)
• Horário de início do atendimento (quando aplicável)
• Duração estimada do procedimento (quando aplicável)
• Tags do paciente (se houver)

Barra de progresso: Pacientes com status ‘Em Atendimento’ exibem uma barra de progresso inline (50px de largura, 3px de altura) na mesma linha do nome do paciente, acompanhada da porcentagem em fonte reduzida (9px). A barra é extremamente discreta e não ocupa uma linha separada, evitando que pareça uma divisão entre cards. Se o tempo decorrido ultrapassar 100% da estimativa, a barra torna-se vermelha (cor error-pure, f44336). Motivador: a barra na linha do nome é percebida como parte do card, não como separador. O destaque visual fica reservado apenas para o estado de atraso (vermelho).

Filtro ‘Meus pacientes’: O toggle em estilo pill (não checkbox) alterna entre ‘Meus’ e ‘Todos’. O filtro ‘Meus’ está ativado por padrão. Motivador: o estilo pill é consistente com o toggle do painel de Consultas e mais discreto que um checkbox.

Navegação: O título do painel (‘Procedimentos na Clínica’) é um link clicável para a tela dedicada. No hover, o título muda de cor e uma seta (→) aparece ao lado. Ao clicar no card de paciente, o sistema abre a prescrição do procedimento (se houver). O card contém um botão separado ‘PEP’ para abrir o Prontuário Eletrônico. Se não houver prescrição associada, o clique no card abre diretamente o PEP.

Justificativa de workflow: Este painel atende aos touchpoints ‘Saber quais pacientes estão em procedimento’ e ‘Decidir se precisa intervir’ (Workflow 2). A barra de progresso discreta reflete que, no workflow de monitoramento, o médico faz checagem periférica entre atendimentos — não precisa de detalhe, só de saber se está dentro ou fora do tempo. O clique no card abrindo a prescrição (e não o PEP) reflete que, neste momento do workflow, o médico primeiro verifica o que está sendo infundido antes de decidir se precisa do prontuário completo. O botão ‘PEP’ separado reflete que o prontuário é a ação secundária neste momento.

Estado vazio: Quando não há pacientes na unidade, exibir ícone de prédio vazio com a mensagem MSG_proceduresNone.

Critérios de Aceitação:

• Dado que um paciente está com status “Em Atendimento”, então o painel deve exibir uma barra de progresso inline na linha do nome representando o tempo decorrido vs. a duração estimada.
• Dado que o tempo decorrido ultrapassa 100% da duração estimada, então a barra de progresso deve mudar para a cor vermelha (#F44336).
• Dado que o toggle “Meus” está ativado, então o painel deve exibir apenas pacientes com vínculo direto com o médico logado.
• Dado que o médico desativa o toggle “Meus”, então o painel deve exibir todos os pacientes presentes na unidade.
• Dado que o médico clica no card de paciente, então o sistema deve abrir a prescrição do procedimento (se houver). Se não houver prescrição associada, abre diretamente o PEP.
• Dado que o médico clica no botão de PEP no card, então o sistema deve abrir o Prontuário Eletrônico do Paciente (PEP).
• Dado que não há pacientes na unidade, então o painel deve exibir MSG_proceduresNone.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
painel-título	Procedimentos na clínica	Procedures at the clinic	Procedimientos en la clínica
toggle-todos	Todos	All	Todos
toggle-meus	Meus	Mine	Mios
botão-PEP	PEP	EHR	HCe
status-agendado	Agendado	Scheduled	Programado
status-aguardando	Aguardando recepção	Waiting reception	Esperando recepción
status-recepcionado	Recepcionado	Checked-in	Recepcionado
status-preparo	Preparo	Preparation	Preparación
status-administrando	Em administração	Administering	En administración
status-completo	Completo	Completed	Completo
status-finalizado	Finalizado	Completed	Finalizado
status-cancelado	Cancelado	Canceled	Cancelado
MSG_proceduresNone	Sem pacientes para o dia	No patients for today	Sin pacientes para el día

---

2.7 Fluxos de Exceção e Estados (Consolidado)

Painel	Condição	Exibição
Qualquer painel	Falha de endpoint	MSG_endpointFail
Qualquer painel	Queda de conexão	Manter últimos dados na tela + ícone discreto de “Offline” no canto do painel
KPI Bar	Falha de endpoint	Exibir ”—” nos valores; demais painéis continuam operando

Estados de loading: Cada painel exibe skeleton loading independente quando os dados estão sendo carregados. A busca exibe um spinner dentro do campo de input durante a consulta à API.

Internacionalização

Termo/Localização	pt-BR	en-US	es-419
MSG_endpointFail	Dados temporariamente indisponíveis. Tente novamente	Data temporarily unavailable. Try again	Datos temporalmente no disponibles. Reintentar

---

2.8 Mapeamento de Componentes do Design System

Componente	Variante	Estados	Tokens aplicados
Button	Primary (Assinar)	default, hover, disabled, loading	bg: color-primary-pure; text: color-base-pure; height: btn-height-sm; radius: radius-m
Button	Secondary (Revisar)	default, hover, disabled	bg: transparent; border: color-primary-pure; text: color-primary-pure
Button	Tertiary (Resolvido)	default, hover	bg: transparent; text: color-primary-pure
Button	Danger (Descartado)	default, hover	bg: color-error-pure; text: color-base-pure
Chip	Active (Crítico)	default	bg: color-error-light; text: color-error-dark
Chip	Active (Atenção)	default	bg: color-highlight-light; text: color-highlight-dark
Chip	Status (consulta)	default	Ver cores por status na RN-CM-005
Badge	Error (KPI Alertas)	default	bg: color-error-pure; text: color-base-pure
Badge	Primary (contadores)	default	bg: color-primary-pure; text: color-base-pure
Input	Bordered (busca)	default, focus, disabled	border: color-neutral-light → focus: color-neutral-dark (2px); height: input-height
Avatar	SM/MD (paciente)	default	bg: color-primary-light; text: color-primary-dark
Progress	Bar (atendimento)	default, critical	bg track: color-neutral-lighter; bg bar: color-primary-pure → critical: color-error-pure
Toast	Success/Error	default	Ver Design System para tokens de toast
Tooltip	Default	hover	bg: color-neutral-dark; text: color-base-pure
KPI Card	Borda colorida lateral	default, hover	border-left: 4px solid; cores: secondary-pure (consultas), primary-pure (tratamento), highlight-pure (procedimentos), error-pure (alertas)
Panel Title Link	Link com seta no hover	default, hover	font-weight: 400; color: neutral-darker → hover: secondary-dark; arrow: opacity 0 → hover: opacity 1
Toggle Pill	Filtro de painel	active, inactive	border: 1px solid neutral-lighter; active: bg secondary-light, text secondary-dark; inactive: bg transparent, text neutral-pure
Progress Bar Inline	Barra na linha do nome	default, danger	width: 50px; height: 3px; bg track: neutral-lighter; bg fill: primary-pure → danger: error-pure; pct font: 9px
Card Highlight (Consulta)	Borda colorida por status	recepcionado, aguardando, default	recepcionado: border-left 3px solid secondary-pure; aguardando: border-left 3px solid ff8a80; default: sem borda
Message Icon (Lucide)	Origem da conversa	unread, read	unread: color primary-pure; read: color neutral-pure. Apenas 2 ícones: bell (sistema/alerta automático) e um ícone genérico de pessoa (conversa com usuário) — não há ícone por equipe
User Menu Dropdown	Avatar + caret	closed, open	avatar: bg neutral-dark, text base-pure, radius-full; caret: rotate 180° quando open; menu: bg base-pure, shadow-medium, radius-m, min-width 160px; item: hover bg base-dark

---

2.9 Integração com Backend

Decisão arquitetural: 1 endpoint por painel + 1 endpoint por KPI card, em vez de um único endpoint consolidado. Justificativa: paralelismo (frontend dispara chamadas simultâneas), resiliência (falha em um endpoint não bloqueia os demais — especialmente importante para os KPIs, onde um problema em um indicador não trava os outros três), granularidade de atualização.

Mecanismo de atualização automática (RN-CM-017): polling — o front-end consulta os endpoints acima em intervalos fixos, sem push/websocket nesta versão. Intervalo por endpoint: 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 (ver justificativa de negócio de cada grupo em RN-CM-017).

Endpoints de KPI (1 por card):

• [GET] /api/v1/cockpit/doctor/kpis/appointments-today
  • Função: Retornar o indicador de Consultas Hoje
  • Response 200: { "total": 6, "finished": 4, "pending": 2, "delayed": 1 }
• [GET] /api/v1/cockpit/doctor/kpis/in-treatment
  • Função: Retornar o indicador de Em Tratamento
  • Response 200: { "inTreatment": 43, "nonAdherent": 2 }
• [GET] /api/v1/cockpit/doctor/kpis/procedures-today
  • Função: Retornar o indicador de Procedimentos Hoje
  • Response 200: { "total": 8, "inProgress": 2, "waiting": 4, "scheduled": 2 }
• [GET] /api/v1/cockpit/doctor/kpis/prescription-alerts
  • Função: Retornar o indicador de Alertas de Prescrição
  • Response 200: { "urgent": 3, "toReview": 1, "toSignNext7Days": 5 }
  • Detalhamento dos campos: urgent = total de prescrições pendentes de assinatura OU pendentes de revisão (RN-CM-020) com hoursRemaining < 12h (RN-CM-011). toReview = total de prescrições atualmente marcadas como “a revisar”, independente da urgência. toSignNext7Days = total de prescrições pendentes de assinatura com aplicação agendada nos próximos 7 dias. Mapeamento de BD: Seção 4.6.

Endpoints de leitura (painéis):

• [GET] /api/v1/cockpit/doctor/appointments
  • Response 200: { "appointments": [ { "id": "uuid", "patient": { "id": "uuid", "preferredName": "", "legalName": "Maria da Silva", "photo": "url|null", "diagnosis": ["Ca. Mama"] }, "startTime": "08:00", "endTime": "08:30", "status": "finished", "type": "in_person", "delayMinutes": 0, "firstTime": false, "tags": ["vip"] } ] }
  • diagnosis: lista de strings — um paciente pode ter mais de um diagnóstico oncológico ativo; todos são retornados e exibidos (ver mapeamento na Seção 4.1).
  • tags: lista de tags de atenção do paciente (ex: vip, quimioterapia, 1a_consulta) — ver origem de cada uma na Seção 4.1.
• [GET] /api/v1/cockpit/doctor/prescriptions
  • Query params: type (opcional: to_sign | to_review) — usado pela tela dedicada de Prescrições Pendentes para filtrar por categoria. O painel do Cockpit não envia o parâmetro e recebe as duas categorias combinadas, já ordenadas por hoursRemaining crescente (RN-CM-011). reviewScope (opcional: mine | all, default mine) — controla o toggle “Meus/Todos”: afeta somente as prescrições to_review; as to_sign nunca são filtradas por este parâmetro, pois já são sempre do médico logado (RN-CM-012).
  • Response 200: { "prescriptions": [ { "id": "uuid", "patient": { "id": "uuid", "preferredName": "", "legalName": "Roberto Oliveira" }, "prescriptionCode": "CARBO-TAXOL C3D1", "scheduleDate": "2026-07-22T18:00:00Z", "hoursRemaining": 8, "type": "to_sign" }, { "id": "uuid", "patient": { "id": "uuid", "preferredName": "", "legalName": "Carlos Mendes" }, "prescriptionCode": "FOLFOX C1D1", "scheduleDate": "2026-07-22T14:00:00Z", "hoursRemaining": 18, "type": "to_review", "isPreferredReviewer": true } ] }
  • patient.preferredName/patient.legalName: mesmo padrão de appointments e procedures — o front decide qual exibir como nome principal (nome social se houver), mas ambos são enviados para o médico perceber questões de gênero/identidade antes do atendimento.
  • prescriptionCode: substitui os antigos campos protocol/cycle por um único campo já formatado (protocolo + ciclo/sessão, ex: “CARBO-TAXOL C3D1”), espelhando Prescricao.Identificacao diretamente — sem necessidade de montar a string no backend.
  • Campo exclusivo do tipo to_review (RN-CM-020): isPreferredReviewer = true quando o médico logado é o prescritor OU o médico assistente do paciente — usado pelo front para destacar visualmente que este médico é revisor preferencial, sem bloquear a ação para os demais (qualquer médico pode revisar). Os campos prescriberName/attendingDoctorName cogitados numa versão anterior foram removidos — o booleano já é suficiente para o front filtrar/destacar, sem expor nomes de terceiros nesta lista.
  • type = to_sign só retorna prescrições com aplicação agendada nos próximos 7 dias — evita inflar a lista com prescrições distantes no tempo, sem relevância imediata.
  • Mapeamento de BD: Seção 4.7.
• [GET] /api/v1/cockpit/doctor/conversations
  • Alinhado à entidade Conversa do modelo de mensageria (IP.Mensageria, schema mensageria em GescomClienteAlfa). Retorna todas as conversas do médico logado com Status não-terminal ('Sent', 'Read' ou 'Responded'), lidas ou não. Este é o comportamento do painel compacto do Cockpit; uma tela dedicada (fora do escopo desta versão) listará também as conversas já finalizadas ('Resolved'/'Dismissed').
  • Response 200: { "conversations": [ { "id": "uuid", "sourceType": "person | system", "authorName": "Sandra", "lastMessage": "Medicamento Carboplatina em falta.", "lastMessageAt": "2026-07-22T13:45:00Z", "deadline": "2026-07-22T14:00:00Z|null", "status": "sent | read | replied", "unread": true, "patient": { "id": "uuid", "preferredName": "", "legalName": "Roberto Oliveira" } | null } ] } — exemplo de uma conversa endereçada a uma equipe, com o autor respondendo como representante dela: authorName: "Sandra (Farmácia)" (mesmo campo, sem campo novo — RN-CM-015, RN-CM-022, resolução em 4.8).
  • sourceType: system quando Conversa.OrigemTipo = 'System' (alerta automático via ModuloOrigem); person quando OrigemTipo = 'User' — vale tanto para conversa endereçada a um indivíduo quanto a uma equipe.
  • authorName: nome de quem escreveu a última mensagem (Usuario.Apelido, ver 4.8), ou “Sistema” quando sourceType = system. Inclui o nome da equipe entre parênteses quando a conversa é endereçada a uma equipe (DestinoTipo = 'Team') e o autor é membro dela — ver “Resolução do nome da equipe” na Seção 4.8.
  • status: sent = 'Sent', read = 'Read', replied = 'Responded'. 'Resolved'/'Dismissed' nunca aparecem aqui (já saíram da lista). Um item com status = replied pode estar lido ou não lido, dependendo se houve atividade nova desde a resposta do médico — ver campo unread.
  • unread (boolean): true quando Conversa.UltimaSequencia > ConversaLeitura.UltimaSequenciaLida (ou não existe ConversaLeitura para o médico). Usado pelo front para o destaque visual e para a camada de prioridade na ordenação (RN-CM-015) — não filtra mais quais itens são retornados.
  • Mapeamento de BD: Seção 4.8.
• [GET] /api/v1/cockpit/doctor/procedures
  • Response 200: { "procedures": [ { "id": "uuid", "prescriptionCode": "AC-T C1D21", "patient": { "id": "uuid", "legalName": "Roberto Oliveira", "preferredName": "", "photo": "url|null" }, "location": "Sala de Infusão 2", "status": "administering", "startTime": "2026-07-22T09:30:00Z", "progress": 65, "mine": true, "tags": ["quimioterapia"] } ] }
  • status: um dos valores de ProcedureStatus() (Seção 4.3/4.4) — scheduled | waiting | checked | preparation | administering | administered | completed | canceled.
  • tags: lista de tags de atenção do paciente (ex: vip, quimioterapia) — mesma origem de appointments.tags, ver Seção 4.1/4.3.
  • prescriptionCode: substitui o campo prescriptionId de uma versão anterior deste documento — o valor nunca foi um identificador único, sempre foi o código formatado da prescrição (protocolo + ciclo/sessão), mesmo campo já usado em prescriptions (Seção 2.9).
• [GET] /api/v1/patients/search
  • Query params: q (string, mínimo 2 caracteres)
  • Response 200: { "patients": [ { "id": "uuid", "name": "Maria da Silva", "medicalRecordNumber": "0012345", "gender": "F", "birthDate": "1972-08-15", "motherName": "Joana da Silva", "cpf": "12345678901" } ] }

Endpoints de ação:

Nota: os endpoints de ação sobre uma prescrição individual (abrir prescrição completa, assinar, marcar como revisada, editar/gravar nova versão) saíram do escopo deste documento. Eles pertencem à tela de detalhe da prescrição, que é chamada a partir deste Cockpit mas faz parte de um processo mais amplo de Prescrições (fora do domínio “Central do Médico”) e deve ser especificada em documento próprio. RN-CM-020 continua aqui porque define a regra de negócio usada no cálculo do KPI e do painel (Seções 4.6/4.7), mesmo que a execução da ação em si esteja documentada em outro lugar.

• [GET] /api/v1/conversations/{id} — Retorna a thread completa (todas as Mensagem, em ordem) para exibição no modal.
  • Response 200: { "id": "uuid", "status": "sent | read | replied", "deadline": "2026-07-22T14:00:00Z|null", "patient": { ... } | null, "messages": [ { "id": "uuid", "type": "initial | reply | update", "author": "Sandra | Sistema", "content": "string", "createdAt": "2026-07-22T13:30:00Z" } ] }
• [POST] /api/v1/conversations/{id}/read — Marca a conversa como lida pelo médico logado (chamado ao abrir o modal).
  • Response 200: { "id": "uuid", "status": "read" } — idempotente; se a conversa já estiver Respondida, o status não regride para read.
• [POST] /api/v1/conversations/{id}/reply — Envia uma resposta na thread (não disponível para conversas com sourceType = system, ver RN-CM-015).
  • Request: { "content": "string" }
  • Response 200: { "id": "uuid", "status": "replied", "message": { "id": "uuid", "content": "string", "createdAt": "2026-07-22T13:50:00Z" } }
• [PATCH] /api/v1/conversations/{id}/resolve — Muda o status da conversa para Resolvida. Substitui o antigo PATCH /messages/{id}/resolve.
  • Response 200: { "id": "uuid", "status": "resolved" }
• [PATCH] /api/v1/conversations/{id}/discard — Muda o status da conversa para Descartada. Substitui o antigo DELETE /messages/{id} — o método mudou de DELETE para PATCH porque o registro nunca é excluído fisicamente, só muda de status (modelo append-only, ver RN-CM-015).
  • Response 200: { "id": "uuid", "status": "discarded" }

---

2.10 Conformidade SBIS (Detalhamento)

Requisito	Como a Central do Médico atende
ECF.03.11	O campo de busca no header permite pesquisar pacientes por nome, CPF, data de nascimento e nome da mãe. A busca inteligente (RN-CM-004) interpreta automaticamente o tipo de entrada.
ECF.03.14	O endpoint GET /api/v1/patients/search retorna os campos obrigatórios: nome completo, número de prontuário, sexo, data de nascimento, nome da mãe e CPF em cada resultado.
ECF.16.01(e)	Após o login, o painel de Prescrições Pendentes exibe as prescrições em aberto de responsabilidade do médico, permitindo acesso direto para assinatura ou revisão.
ECF.17.01	Todos os cards de paciente identificam univocamente o paciente (nome + ID). As conversas identificam o autor de cada mensagem (nome da pessoa ou “Sistema”, com o nome da equipe adicionado quando a pessoa responde como representante de uma equipe — RN-CM-015 — ver authorName na Seção 2.9). As prescrições identificam o paciente e o médico prescritor.
ECF.17.02	As mensagens internas exibem timestamp de criação (criadaEm). As ações de assinatura e resolução registram data/hora automaticamente no backend.
ECF.17.04	As consultas são ordenadas cronologicamente pelo horário agendado. As mensagens seguem ordenação por data limite e LIFO. As prescrições são ordenadas por urgência cronológica (tempo restante).
ECF.17.18	Toda a interface, incluindo rótulos, mensagens, títulos de tela e descritivos, está em português do Brasil.
ECF.17.19	Mensagens de erro e feedback ao usuário (toasts, alerts) são em linguagem não técnica. Erros técnicos do backend são tratados e traduzidos para mensagens amigáveis.

---

Histórico de Versões

• v4.25 (29/08/2026) — Arquivo criado pela divisão do documento único CM_CockPit_do_medico_v4_25.md em 4 arquivos por seção (ver Skill Designer, “Organização Física: Pasta por Funcionalidade”, Lição #18). Conteúdo desta seção sem alteração de substância em relação à v4.25 do documento original — apenas reorganização física. O histórico de revisões anterior a esta divisão (v4.0 a v4.25, incluindo o racional de cada mudança) está preservado integralmente no documento original, arquivado em Histórico/CM_CockPit_do_medico_v4_25 (documento único, antes da divisão em 4 arquivos).md.