​

Arquitetura de Storage

​

1. Estado atual

​

1.1 PostgreSQL (pacs_postgres — volume pacs_pg_data)

​

Colunas com conteúdo grande

​

Tabelas de metadata (pequenas)

​

1.2 Filesystem (volume pacs_storage)

pacs_storage/
└── thumbnails/
    └── {orthanc_study_id}/
        ├── preview.jpg              (thumbnail do estudo — primeiro frame)
        └── series/
            └── {orthanc_series_id}.jpg  (thumbnails por série)

• Gerador: worker/main.py durante indexação
• Formato: JPEG 300×300 via pydicom + Pillow
• Tamanho por arquivo: 10-50 KB
• Retenção: nenhuma — thumbnails nunca são deletados
• Estimativa: 500 estudos × 70 KB ≈ 35 MB/mês

Confirmado: só thumbnails hoje. Nada mais escrito em filesystem pelo backend.

​

1.3 Orthanc (pacs_orthanc — volume pacs_orthanc_data)

​

1.4 Redis (pacs_redis — volume pacs_redis_data)

​

2. Problemas identificados

​

P1 — report_templates.assets é bomba-relógio 🔴

​

P2 — Blobs base64 inflando o DB 🟠

• ~33% overhead (base64 vs binário)
• Backup do PG inflado (backup de DB deve ser rápido; blobs pesados atrapalham)
• WAL (write-ahead log) cresce mais rápido
• Replicação (quando houver) fica lenta
• Query plans — SELECT * traz blobs sem querer; desenvolvedor precisa lembrar de excluir colunas

​

P3 — Orthanc com SQLite 🟠

• Write serialization: file lock limita escrita concorrente. Várias modalidades de clínicas diferentes fazendo C-STORE simultaneamente = contenção.
• Backup complexo: SQLite em uso precisa de WAL + .backup command; snapshot de volume arrisca corrupção.
• Sem replicação nativa: single point of failure. Perda do volume = perda do índice (DICOM continua no storage, mas Orthanc não sabe mais onde).
• Não escala horizontalmente: só um Orthanc pode abrir o SQLite por vez.

• Metadata DICOM em Postgres (o mesmo pacs_postgres ou dedicado)
• Blobs DICOM continuam em filesystem (ou S3 via plugin separado)
• Múltiplas instâncias Orthanc podem compartilhar o mesmo backend (scale out)

​

P4 — Orthanc sem política de retenção 🟡

​

P5 — Thumbnails sem retenção nem redundância 🟡

• Cresce linear com estudos (~35 MB/mês)
• Sem limpeza de thumbnails de estudos antigos
• Se o volume pacs_storage for perdido, o worker teria que reprocessar todos (função pacs:requeue já existe)
• Filesystem local não funciona com múltiplos backends (quando escalar)

​

P6 — report_revisions duplica conteúdo 🟢

​

3. Visão: Storage em camadas

​

3.1 Conceito

​

3.2 Aplicação ao nosso domínio

​

PostgreSQL (Hot — metadata)

• studies, series, instances (índice)
• patients, users, tenants, units, modalities
• reports.content, report_revisions.*_content (HTML, caso típico 2-5 KB)
• report_presets.default_content

• users.signature → {bucket}/signatures/{user_id}.{ext}
• tenants.logo → {bucket}/tenants/{tenant_id}/logo.{ext}
• report_templates.assets.background → {bucket}/templates/{template_id}/background.{ext}

​

Object Storage (Warm — binários)

• MinIO (self-hosted, S3-compatible) — mesma infra on-prem, sem depender de cloud
• AWS S3 — gerenciado, paga por GB + transfer
• Backblaze B2 / Wasabi — S3-compatible mais barato, bom pra warm/cold
• Cloudflare R2 — sem egress, bom pra servir assets públicos

• Logos, signatures, template backgrounds (hoje em base64 no DB)
• Thumbnails (quando escalar)
• DICOM “mornos” — estudos com 3-24 meses de idade (via plugin Orthanc object-storage)
• PDFs de laudos pré-gerados (futuro, se gerar no backend)

​

Cold Storage (arquivamento legal)

• AWS S3 Glacier / Deep Archive — ~$1/TB/mês, retrieval em 12h
• Cloudflare R2 com lifecycle
• Backblaze B2 com retenção
• Tape (off-site, LTO) — para quem já tem infra

• DICOMs com >2 anos (configurável pelo tenant, respeitando a retenção legal)
• Backups antigos do Postgres (além da janela de PITR)

​

Migração entre camadas

1. Query Postgres (via índice do Orthanc em Postgres): “estudos com study_date < today - 2 years e ainda marcados como quentes”
2. Move o blob do bucket warm para o bucket cold
3. Atualiza referência no Orthanc/Postgres

​

3.3 Arquitetura alvo resumida

┌──────────────────────────────────────────────────────────────┐
│                     APLICAÇÃO (Laravel + Next)               │
└─────┬──────────────────────┬───────────────────────┬─────────┘
      │                      │                       │
      ▼                      ▼                       ▼
┌──────────┐         ┌──────────────┐        ┌──────────────┐
│PostgreSQL│         │Object Storage│        │   Orthanc    │
│          │         │   (warm)     │        │              │
│ metadata │         │              │        │ hot DICOM    │
│ laudos   │◀───refs─│ logos/sigs   │        │ (PG index)   │
│          │         │ backgrounds  │◀───────│ via plugin   │
│          │         │ thumbnails   │        │ object-store │
└──────────┘         │ DICOM warm   │        └──────────────┘
                     └──────┬───────┘
                            │ lifecycle
                            ▼
                     ┌──────────────┐
                     │ Cold Storage │
                     │   (archive)  │
                     │ DICOM >2yrs  │
                     └──────────────┘

​

4. Próximos passos sugeridos (ordem de prioridade)

​

Fase 1 — Tirar blobs do Postgres (~2 semanas de trabalho)

1. Subir MinIO (um novo serviço no docker-compose.yml) com bucket pacs-assets
2. Migrar report_templates.assets.background (maior ofensor)
   • Script one-off: lê base64, faz upload ao MinIO, atualiza coluna pra URL
   • Ajustar backend (ReportTemplateController) pra ler/escrever via S3 SDK
   • Ajustar preview + PDF pra baixar via URL com signed access
3. Migrar tenants.logo e users.signature (mesmo padrão)
4. Remover os campos base64 do DB (após migração validada)

​

Fase 2 — Orthanc com PostgreSQL index

1. Instalar plugin orthanc-plugin-postgresql
2. Configurar para apontar ao pacs_postgres (schema separado) ou DB dedicado
3. Migração do SQLite → Postgres (Orthanc documenta o procedimento)
4. Validar em homolog antes de produção

​

Fase 3 — DICOM em object storage

1. Instalar plugin orthanc-plugin-object-storage (AWS/Azure/GCS S3-compatible)
2. Configurar para gravar novos DICOMs no MinIO/S3
3. Manter estudos existentes em filesystem (ou migrar em lote depois)

​

Fase 4 — Retenção e lifecycle

1. Definir política por tenant (configurável): quanto tempo em hot/warm/cold
2. Job cron de migração
3. UI pra tenant admin configurar retenção

​

5. Questões em aberto

• MinIO self-hosted vs AWS S3 — trade-off custo/complexidade (MinIO = mais infra, S3 = dependência de cloud e billing)
• Orthanc: PostgreSQL plugin AGORA ou depois? — ver checklist de revisão
• Política de retenção legal — qual o padrão CFM e variações estaduais aplicáveis? Definir com advogado antes de implementar cold tier
• Pré-geração de PDFs — hoje o PDF é gerado no frontend sob demanda. Vale gravar uma versão no bucket após finalização do laudo (pra evitar regenerar toda vez)?
• Thumbnails em object storage — migrar quando? Só faz sentido se houver >1 instância de backend, ou se o volume pacs_storage crescer a ponto de incomodar o backup

​

6. Metodologia de execução de fases

​

6.1 Checklist de raio de impacto (por fase)

1. Migrations — schema atual e o que muda
2. Models — casts, $hidden, mutators, accessors, relacionamentos
3. Controllers — quem escreve, quem lê, quem expõe no JSON
4. Services e helpers — wrappers como OrthancService, parsers tipo parseTemplateAssets, makeVisible('signature')
5. Frontend — editores (uploaders), previews, geradores de PDF, listagens que expõem o dado
6. API contracts — páginas do Mintlify (docs/api/*.md) que precisam atualizar
7. Testes — unit/integration que validam o comportamento atual
8. Consumidores externos — webhook do Orthanc, nginx auth_request, OHIF, worker Python

​

6.2 Exemplos por fase

• users.signature — UserController@store/@update (escrita), ReportController@showByStudy/@upsertByStudy/@correctFinal (leitura via makeVisible), downloadStudyReportPdf no frontend
• tenants.logo — TenantSettingsController@show/@update, ReportController (se eager load), PDF generator, componente de logo no header
• report_templates.assets.background — ReportTemplateController@index/@show/@store/@update, ReportTemplateA4Preview, downloadStudyReportPdf, parseTemplateAssets helper

• Webhook Lua do Orthanc que dispara /api/orthanc/webhook
• OrthancService no Laravel (wrapper REST)
• Worker Python (consome via Orthanc REST)
• Nginx CORS proxy (OHIF → Orthanc via DicomWeb + viewer token)
• Queries que dependem de orthanc_study_id / orthanc_series_id — esses IDs continuam válidos porque são do próprio Orthanc; só o backend de índice muda

• Config do plugin orthanc-plugin-object-storage
• Comportamento do OHIF (WADO-RS continua via Orthanc, ele é quem resolve o blob no S3)
• Latência de primeiro acesso a estudo “warm”

​

6.3 Fluxo de execução

1. Disparar subagentes Explore em paralelo, um por área afetada, com prompt pedindo o raio de impacto estruturado
2. Consolidar em docs/plans/{fase-x}.md — lista exaustiva de arquivos a tocar, ordem de execução, plano de rollback (como desfazer se der errado)
3. Aprovação do plano antes de qualquer Edit — nunca partir pra implementação sem plano validado
4. PRs pequenos reviewáveis — não um PR de 50 arquivos. Um por sub-passo (ex.: “migrar só backgrounds”, “remover colunas deprecadas”)
5. Validação em homolog antes de fundir em main
6. Rollback ensaiado — se o plano diz “script X reverte”, testar o revert num ambiente descartável antes

​

6.4 Aplicabilidade

​

7. Referências

• Orthanc PostgreSQL Plugin
• Orthanc Object Storage Plugins
• MinIO Documentation
• Resolução CFM 1.821/2007 — retenção de imagens médicas