Exames — visão geral
O módulo de Exames é a tela principal do Portal 2.0: a worklist (/exams) onde médicos,
técnicos, gestores e o restante da equipe encontram, filtram e operam os exames do dia a dia —
abrir o laudário, atribuir médico, mudar status/prioridade/unidade, duplicar, cancelar, anexar,
comentar, exportar e, para quem administra a plataforma, cadastrar um exame manualmente.
Este levantamento cobre a interface (Angular) do repositório mm-pacs-portal-main-interface,
branch integration/with-fixlaudo, testada no ambiente https://task4.srv1812538.hstgr.cloud/.
:::caution Pendência deste levantamento — exame de teste sem médico nem imagens O único exame cadastrado na unidade "Unidade Central Docs" ("Paciente Teste Docs Portal2", modalidade CR) foi criado manualmente, sem vínculo com um estudo PACS por trás — por isso ele não tem médico atribuído e a coluna SE/IMG (séries/imagens) fica vazia. Isso é uma limitação real do ambiente de teste, não um bug.
Atualização 24/09/2026: a captura original desta página (contra um task4 desatualizado)
mostrava Abrir Laudário, Exibir áudio e Imprimir protocolo desabilitados nesse exame.
Depois de atualizar o task4 para develop, Abrir Laudário passou a aparecer habilitado
(comportamento correto, batendo com o código) e Exibir áudio passou a não aparecer (em vez de
aparecer desabilitado) — só Imprimir protocolo segue de fato desabilitado. Abrir o laudário
falha por um bug real de schema GraphQL da própria branch develop, documentado em
Laudário — não mais pela falta de imagem em si. Não foi possível,
portanto, capturar o laudário, o modal de áudio nem o fluxo de laudação a partir desta tela.
A confirmar — responsável: time de frontend; data: 24/09/2026: repetir a captura das ações que
dependem de laudo/imagem depois que o bug de schema GraphQL do laudário for corrigido, com um
exame real (ingerido via PACS) ou com um segundo exame de teste que tenha ao menos um laudo
associado.
:::
O que este levantamento cobre e o que fica de fora
O escopo pedido foi só o núcleo da worklist — listagem, filtros, criação manual de exame e as ações da linha — excluindo explicitamente telas que já têm dossiê próprio ou que pertencem a outro momento do roadmap:
| Módulo (com dossiê próprio) | Pasta no código | Por que não entra aqui |
|---|---|---|
| Anexos | features/exam-attachments | Já documentado — o ícone de anexo da worklist só abre o modal descrito lá. |
| Comentários | features/exam-comments | Fora de escopo desta tarefa; o popover de comentário da linha só é citado de passagem. |
| Achado crítico | features/exam-critical-finding | Idem — citado só como gatilho na barra de ações da linha. |
| Laudário (relatório) | pages/exam-report, features/exam-report-* | Rota própria (/exams/:examId/report); tem escopo grande o bastante para um levantamento à parte. |
| Áudio do exame | widgets/exam-audio-list, features/exam-audio*, report-audio-recorder | Idem — módulo próprio. |
O que este levantamento cobre, dentro de src/app/pages/exam, widgets/{exam-worklist, exam-filter-bar} e as features/exam-* restantes:
Páginas deste módulo
| Página | Cobre |
|---|---|
| Listagem de exames (worklist) | Colunas, paginação/ordenação, estados, seleção em lote e a barra de ações em lote |
| Filtros da worklist | Barra de filtros, diálogo de filtro avançado, diálogos de unidade/usuário/especialidade e o botão Adicionar exame |
| Criar exame | O modal Adicionar exame — campos, validações e o que acontece ao salvar |
| Ações da linha | Ícones fixos da linha, o menu Abrir opções, a barra de ações expandida e os ~15 diálogos de ação individual |
Quem acessa o quê — visão rápida
A permissão-base de tudo é exam:read: sem ela, permissionGuard('exam:read')
(src/app/app/routes/exam.routes.ts:13) bloqueia a própria rota /exams. Lendo o catálogo de
papéis do backend
(mm-pacs-portal-main-api/package/identity/authorization/core/models/identity-system-role.ts),
dos 9 perfis de teste deste levantamento (docs-usuarios.md), dois não têm exam:read:
typist (só permissões de laudo — report:*) e financial (só as 4 permissões mínimas de
leitura de usuário/unidade/grupo/tenant, nenhuma de exame). Para esses dois perfis, /exams
não deveria abrir. A confirmar — responsável: time de frontend; data: 24/09/2026: este
levantamento não testou navegando com typist nem financial — só leu o catálogo de permissões.
| Permissão | Quem tem (catálogo do backend) | O que libera nesta tela |
|---|---|---|
exam:read | administrator, manager, doctor, technician, resident, read_only, requestor | Ver a worklist. Sem ela, a rota /exams não abre. |
exam:create | só administrator (linha 81 de identity-system-role.ts, dentro de ADMINISTRATOR_PERMISSIONS) | Botão Adicionar exame na barra de filtros. |
patient:read-identity | administrator e doctor (não os demais) | Ver o nome real do paciente na coluna Paciente. Sem ela, a coluna mostra *** — confirmado navegando com read_only (ver Filtros da worklist). |
exam:write | administrator, manager, doctor, technician, requestor | Base para boa parte das ações de escrita da linha (ver Ações da linha). |
exam:delete | administrator (manager recebe via reconciled(), ver nota abaixo) | Nível "gestor do exame" (isExamManager, exam-policy.ts:116) — cancelar exame concluído, editar SLA, trocar equipe em exame compartilhado, etc. |
:::info Achado de código: manager recebe permissões por um caminho diferente de administrator
O array MANAGER_PERMISSIONS existe em identity-system-role.ts mas não é usado: o método
IdentitySystemRoleCatalog.reconciled() (linha 317), que é o que efetivamente popula o banco na
inicialização (ApplyIdentitySystemRoleCatalogService.apply()), substitui as permissões do
manager por todo o catálogo atribuível, menos report:sign — deliberadamente, segundo o
comentário do código, para o gestor administrar a unidade sem se autodeclarar radiologista ao
abrir o laudário. Na prática, isso significa que manager, neste ambiente, tem exam:create,
exam:delete e a maior parte das permissões "de administrador" sobre exame, mesmo sem constar
explicitamente na lista MANAGER_PERMISSIONS. Não testamos isso navegando (ver pendência acima
sobre perfis não testados) — é uma leitura de código
(identity-system-role.ts:308-328).
:::
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 módulo de Exames. Eles não são fonte de comportamento atual — o Portal 2.0 reimplementa o domínio em NestJS/Angular, e várias regras do legado mudaram ou não foram portadas (ver as ressalvas em cada página de feature e a nota "Fonte de verdade" em Módulo Exame — visão geral (Back)). Listamos aqui só id e título, como contexto histórico:
| Card | Título |
|---|---|
| 522 | F-001 — Ingestão e criação de exame (múltiplas fontes) |
| 526 | F-002 — Worklist, listagem e consulta de exame |
| 530 | F-003 — Marcação clínica e preparação do estudo |
| 534 | F-004 — Motivos (catálogo) e exclusão/restauração de exame |
| 542 | F-006 — Impressão, download e liberação de exame |
| 546 | F-007 — Relacionamentos entre exames (anterior, complemento, conjugado, duplicado) |
| 550 | F-008 — Atribuição de médico/residente ao exame |
| 554 | F-009 — Catálogo clínico (modalidade / subespecialidade) e edição de metadados |
| 566 | F-012 — Catálogo de especialidade/subespecialidade entre unidades |
| 570 | F-013 — Imagem-chave do exame |
| 574 | F-014 — Laudário do exame: abertura, preparação e protocolo |
| 582 | F-S01 — Compartilhamento de exame entre unidades |
| 594 | F-S04 — Substituição de variáveis do exame/empresa no HTML do laudo (impressão) |
(Os ids 1296–1314 no funil são duplicatas dessas mesmas features, mais três cards de outros módulos — anexos duplicados, anexar arquivos e SLA — encontrados na mesma faixa de ids e fora do escopo desta doc.)
Relacionado
- ⚙️ API: Módulo Exame — visão geral
- 🗂️ Ciclo de vida do exame (Back)
- 🔐 Permissões
- 📎 Anexos — modal aberto a partir do ícone de clipe da linha