Laudário — visão geral

O laudário é a tela onde o médico (ou o digitador, sob supervisão dele) escreve, revisa e assina o laudo de um exame — o documento clínico que descreve o achado radiológico e chega ao paciente e ao médico solicitante. É uma rota de tela cheia própria (/exams/:examId/report), aberta a partir do botão Abrir Laudário da worklist, e cobre desde a digitação em texto livre até a assinatura digital, a correção pós-assinatura, os modelos de laudo por modalidade (máscaras) e as configurações de cabeçalho/rodapé/formatação por unidade.

Este levantamento cobre a interface (Angular) do repositório mm-pacs-portal-main-interface, branch integration/with-fixlaudo, pastas src/app/pages/exam-report, src/app/widgets/report-* e src/app/pages/report-masks, testada no ambiente https://task4.srv1812538.hstgr.cloud/.

:::danger Bloqueio confirmado — o laudário não abre neste ambiente (bug de contrato GraphQL, não de configuração) O ambiente task4 foi atualizado em 24/09/2026 para a branch develop (API e front), depois de a versão anterior (integration/all-features) ter ficado desatualizada e quebrar mutations GraphQL. Mesmo assim, clicar em Abrir Laudário falha de verdade: a interface mostra dois toasts "Servidor indisponível, tente novamente mais tarde ou contate o administrador do sistema." e o laudário nunca aparece — a navegação permanece na worklist.

A causa, confirmada pela rede (POST /graphql, dois 400 GRAPHQL_VALIDATION_FAILED — "The GraphQL operation is invalid." — a cada tentativa), são estas duas operações:

graphql
query PreviousExamsFilter { previousExamsFilter { prevSameName prevSimilarName prevSameCode prevSameBirthday prevSameUnit prevMyExams prevSameModality prevPeriod } }
​
query ReportVariables { reportVariables { token name group } }

O frontend (branch develop publicada no ambiente) pede campos que o backend (mesma branch/ambiente) não reconhece — um descompasso de contrato na própria develop, nesta área específica, e não um problema de configuração do task4. Reproduzimos o mesmo resultado logados como docs.administrator e docs.doctor (ambos com exam:read, perfis distintos) — os dois recebem exatamente os mesmos dois erros 400 e a mesma dupla de toasts. Isso está fora do escopo desta documentação corrigir: é uma mudança de código de produto (contrato GraphQL do backend ou do front), não de conteúdo do laudário.

A confirmar — responsável: time de frontend; data: 24/09/2026. Por causa deste bloqueio, nenhum estado interno do laudário foi capturado ao vivo nesta documentação (editor com conteúdo, grade de ícones em uso, diálogos de assinatura, painel de máscaras aberto etc.). Todo o conteúdo abaixo sobre o comportamento dentro da tela vem da leitura do código-fonte (componentes, políticas de permissão e testes .spec.ts), não de observação ao vivo — cada seção sinaliza isso outra vez onde relevante. :::

O que este levantamento cobre

Página	Cobre
Abrir o laudário	Rota, guard, o botão da worklist, a trava de edição (lock), o bug de abertura confirmado acima, o estado de acesso negado e a saída com alterações não salvas
Editar o laudo	Editor de texto, formulário estruturado por modalidade (OIT/mamografia/ecocardiograma), painel BIRADS, grade de ícones rápidos, rascunho automático e os diálogos de apoio (duplicar exame, editar estudo, exames anteriores)
Assinatura e correção	Salvar, pré-laudar, assinar (padrão, com anexo, e ir para o próximo), fechar/devolver à fila, e as ações pós-assinatura (reassinar, revisar ortografia, segunda assinatura, revogar residente, pedir reavaliação)
Máscaras de laudo	Modelos de conteúdo do laudo por modalidade/sexo/BIRADS, nos três escopos (grupo, unidade, pessoal), biblioteca de imagens e compartilhamento
Cabeçalho, rodapé e configurações do laudo	As duas telas de configuração por unidade que não são máscaras: modelos de cabeçalho/rodapé (moldura impressa) e as políticas do laudário da unidade (máscara padrão, formatação, liberação, laudo conjugado etc.)

Permissões e acesso — visão rápida

A rota do laudário (/exams/:examId/report) não tem guard próprio: ela é filha de /exams e herda authGuard + permissionGuard('exam:read') de lá (src/app/app/routes/exam.routes.ts:13,39-43). Ou seja, qualquer perfil que enxerga a worklist consegue, em tese, chegar à rota do laudário — o controle fino de "o que essa pessoa pode fazer dentro do laudo" (editar, assinar, corrigir, reavaliar) é decidido depois, dentro da tela, e em boa parte pelo próprio servidor no momento de abrir o laudo (openReport, ver Abrir o laudário).

Lendo o catálogo de papéis do backend (mm-pacs-portal-main-api/package/identity/authorization/core/models/identity-system-role.ts):

Permissão	Quem tem no catálogo	O que libera
report:read	Todos os 9 perfis exceto financial	Ler o laudo (inclusive via o "olho" só-leitura da worklist)
report:write	administrator, manager, doctor, resident, typist	Digitar/editar o conteúdo do laudo
report:sign	só doctor, no catálogo base	Assinar o laudo. administrator e manager foram deliberadamente excluídos desta permissão em 22/09/2026 — comentário no código: "assinar laudo é ato clínico... o gate de autoclaim do openReport conta com essa exclusão para não confundir 'administra o sistema' com 'é médico'" (identity-system-role.ts:56-61, :312-320). manager recebe todo o catálogo atribuível via reconciled() (mesmo mecanismo documentado no módulo de Exames, seção "Quem acessa o quê"), exceto report:sign, filtrado explicitamente na mesma linha.
report-mask:manage	administrator, manager (via reconciled())	Criar/editar/excluir máscaras no escopo do grupo ou da unidade, e configurar cabeçalho/rodapé
report:canUseUserMask	administrator, doctor, resident, typist	Usar (não necessariamente gerenciar) máscaras pessoais ao laudar

Dos 9 perfis de teste deste levantamento (docs-usuarios.md), isso significa que só docs.doctor consegue assinar um laudo no catálogo base; docs.administrator e docs.manager conseguem abrir, ler, editar e gerenciar máscaras, mas não assinar. A confirmar — responsável: time de frontend; data: 24/09/2026.: por causa do bloqueio de abertura descrito acima, este levantamento não conseguiu confirmar ao vivo se o botão Assinar de fato fica oculto/desabilitado para docs.administrator dentro da tela — a leitura do código (exam-report-page.component.ts) mostra que a página não esconde os botões de assinatura localmente por report:sign; quem recusa é o servidor, no momento de assinar.

Acesso negado — confirmado ao vivo

Testamos a navegação direta por URL para /exams/{id}/report com docs.financial (sem exam:read, portanto sem acesso a nenhuma tela de exame): o resultado é um redirecionamento silencioso para /admin/tenant, sem toast nem página de erro — o mesmo padrão já documentado nos módulos de Áudio e Permissões da unidade.

Contexto de negócio (legado) — Bitrix

Os cards abaixo (funil de features do sistema legado, entityTypeId 1320) descrevem a intenção de produto original do laudário. Eles não são fonte de comportamento atual — o Portal 2.0 reimplementa o domínio em NestJS/Angular, e o próprio backend já documentado registra que nenhuma regra foi copiada do Bitrix sem confirmação direta no código atual (ver "Fonte de verdade" em Módulo Laudo (Report) — visão geral (Back)). Listamos aqui só id e título, como contexto histórico:

Card	Título
712	F-001 — Digitar e editar o laudo do exame - Front
716	F-002 — Assinar o laudo (digital SafeID, residente, complementar) - Front
720	F-003 — Gerir status, atribuição e relaudo do laudo - Front
724	F-004 — Gerar o PDF do laudo - Front
728	F-005 — Imprimir imagens-chave e protocolo do exame - Front
732	F-006 — Gerenciar máscaras (templates) de laudo - Front
736	F-007 — Cabeçalho, rodapé e máscara padrão do laudo (por empresa) - Front
740	F-008 — Notificar laudo por e-mail (paciente e médico solicitante) - Front
754	F-012 — Entregar laudo ao paciente e contabilizar impressão - Front
758	F-013 — Variáveis de laudo (template e por usuário) - Front

Duas observações sobre o mapeamento cartões → Portal 2.0: F-005 (impressão de imagens-chave e protocolo) e F-012 (entrega ao paciente via link público) descrevem fluxos que, na v2, vivem fora do escopo desta pasta (viewer de imagens e portal público de entrega, respectivamente) — não há componente equivalente em pages/exam-report, widgets/report-* ou pages/report-masks. F-008 (notificação por e-mail) já está documentado em Comunicação — Enviar laudo por e-mail (Back). A interface de envio (o diálogo dentro do laudário/worklist) não tem página própria neste levantamento — não faz parte de pages/exam-report, widgets/report-* nem pages/report-masks.

Relacionado

• ⚙️ API: Módulo Laudo (Report) — visão geral
• 🎙️ Áudio — visão geral — o ditado por voz durante o laudo (gravador embutido no laudário)
• 💬 Comentários — visão geral — comentário do exame e achado crítico, ambos também acessíveis a partir da grade de ícones do laudário
• 📋 Exames — visão geral — a worklist de onde se chega ao laudário
• 🔐 Permissões