Skip to main content

Módulo Laudo (Report) — visão geral

O módulo de laudo é o núcleo clínico do Portal 2.0: cobre a digitação e edição do laudo de um exame, a assinatura (própria, complementar, por residente) e a correção pós-assinatura, as transições de status e reatribuição, o controle de concorrência de quem está editando um laudo, as máscaras de laudo (templates de conteúdo por modalidade/sexo/BIRADS), os modelos de cabeçalho e rodapé usados na composição do PDF, a geração e reprocessamento do PDF do laudo, a revisão por pares (peer review) e a entrega do laudo assinado para sistemas de integração externos (RIS/PACS). Ele vive inteiramente no pacote diagnosis/report do backend (NestJS), branch integration/with-fixlaudo.

O envio do laudo por e-mail (paciente e destinatários avulsos) não faz parte deste levantamento — já está documentado em Notification — Enviar laudo por e-mail; esta página só faz o link cruzado.

Fonte de verdade. Este levantamento foi feito inteiramente a partir do código atual (branch integration/with-fixlaudo, pacote package/diagnosis/report) e dos testes em __test__. Não documentamos SQL, migration nem nome de tabela/coluna — só o contrato observável (rota, permissão, validação, erro, regra de negócio). Cartões de negócio do Bitrix (funil 562, features F-001 a F-013 e F-S002) descrevem o sistema legado (mm-pacs-portal-api, rotas /laudo/*, /mascara/*, tabelas tb_exame_laudo*, tb_exame_mascara*) e foram usados só como pista de intenção de produto — o campo que mapearia "status vs. código real" está vazio em todos os cartões consultados (714, 718, 722, 726, 730, 734, 738, 742, 756, 760, 768), então nenhuma regra de negócio foi copiada do Bitrix sem confirmação direta no código NestJS atual. Onde o comportamento do legado e do v2 divergem (por exemplo, SafeID habilitado por credencial do ator em vez de config global; motor de PDF único via ComposeDiagnosisReportPdfService em vez de dois motores concorrentes), esta página descreve apenas o v2.

Prefixo de rotas e versionamento​

Como nos demais módulos, a API usa versionamento por URI (VersioningType.URI, versão padrão 1): toda rota deste módulo é servida sob /v1/... (ex.: /v1/reports, /v1/report-masks). Todos os controllers aplicam JwtAuthenticationGuard + AuthorizationGuard na classe, e a maior parte também aplica DiagnosisAuthorizationTransactionInterceptor (abre a transação de banco já dentro do escopo de autorização resolvido).

Arquitetura​

Capacidades documentadas​

Conceitos que atravessam várias páginas​

Status do laudo (ReportStatus). CLEARED, SIGNED, REPORTING, PENDING, SECOND_OPINION, RESIGNED, TYPED, RECALL, AI_TYPED, PRE_SIGNED, TYPING. CLEARED é um status sentinela interno (não pode ser setado via API). O status do laudo é espelhado automaticamente no status do exame (DiagnosisClinicalStatusPolicy); as regras de transição aparecem detalhadas em Status, reatribuição e reavaliação.

"Versionamento" do laudo. Não existe uma rota de histórico dedicada. O que existe são operações que, em vez de editar o laudo assinado em memória, criam um novo registro de laudo vinculado ao mesmo exame: reatribuir o dono de um laudo assinado com versionSignedReports: true (ver reatribuição), e solicitar reavaliação de um laudo assinado (ver reavaliação) — em ambos os casos o laudo original passa para RESIGNED e o novo laudo nasce com o próprio id. GET /reports?examId= lista todos os laudos (todas as versões) daquele exame, e é a forma de reconstruir esse histórico a partir da API.

Assinatura digital (SafeID/ICP-Brasil). Quando o token do ator carrega hasSafeId e um accessTokenSafeId, a assinatura efetiva também assina digitalmente o PDF via um cliente externo (DiagnosisDigitalSignatureClient, implementação SafeWeb PSS). Isso acontece de forma assíncrona best-effort depois do commit da transação de assinatura; falhas ficam registradas como "reprocessamento pendente" e podem ser refeitas por POST /reports/:id/pdf-generations.

Compliance​

Este levantamento não reproduz os pareceres de compliance do Bitrix (LGPD/HIPAA/ANVISA) como fato — cada página só afirma o que o código atual efetivamente implementa (guard de MFA na assinatura, licença profissional ativa, trilha de auditoria por evento, sanitização de HTML de máscara). Onde a exigência regulatória citada no Bitrix não tem controle equivalente confirmado no código, a página correspondente registra a pendência com A confirmar — responsável: time de Diagnosis; data: 24/09/2026. em vez de afirmar conformidade.

Relacionado​

  • 📧 Notification — Enviar laudo por e-mail
  • 🔑 Authorization — significado das permissões REPORT_* e RLS por unidade/recurso usadas em todo este módulo.
  • 👤 Usuário — licença profissional ativa (hasActiveProfessionalLicense), exigida para assinar e para ser reatribuído como dono do laudo.
Last updated on by Matheus Carvalho