Sonador ACL/Security: Systems & Workflow Documentation (SaMD diagram coverage)
This issue tracks the **systems and workflow documentation** for the Sonador platform — architecture, data-flow, use-case, sequence, component, and deployment diagrams plus the supporting systems documentation that surrounds the ACL/security work. Its goal is to move beyond *test-coverage tracking* and build a **comprehensive systems/workflow picture of the application** suitable for Software-as-a-Medical-Device (SaMD) documentation practices.
> **Provenance:** Split out of oak-tree/medical-imaging/sonador#55 ("Sonador ACL MS1: Test Coverage Tracking"), where the documentation checklist originally lived alongside the functional-test inventory. The original checklist is preserved verbatim (converted to a plain itemized list) as a comment on #55 for traceability, and #55 now links here. Keeping documentation separate lets #55 close on test completion while documentation work continues here.
---
### Why a dedicated systems-documentation set (SaMD framing)
Sonador is medical-imaging software; its documentation should align with the artifact expectations of the relevant SaMD standards/guidance so the system is auditable and submission-ready:
- **IEC 62304** (medical-device software lifecycle): software **architecture** and **detailed-design** descriptions, decomposition into software items/units, and a **SOUP / third-party** inventory.
- **FDA premarket cybersecurity guidance**: a **system/architecture diagram**, **data-flow diagrams** (especially PHI and credential/token flows), a **threat model** with trust boundaries, and a **Software Bill of Materials (SBOM)**.
- **ISO 14971** (risk management) & **IEC 62366** (usability/use specification): **use-case** definition of actors and intended use (the ACL roles map directly to this).
- **HIPAA accountability**: documentation of **audit logging** / access-event recording.
The diagram set below is the practical, consolidated expression of those requirements.
### Inventory of Endpoints
https://docs.google.com/spreadsheets/d/1tiRgj75Dgm1yyI2c1PVXacLIt-AJP-tzxGc-5Po3kHk/edit?usp=sharing
---
### Required documentation artifacts — current coverage
Assessed against the local docs wiki (`oaktree-env/docs`, the GitLab platform-docs wiki). Status legend: ✅ diagram exists · 🟡 partial / prose-only / needs a real diagram · ❌ absent.
| Artifact | SaMD rationale | Current coverage | Status |
|---|---|---|---|
| **High-Level System Architecture Diagram** | IEC 62304 architecture; FDA system diagram | `sonador.production-deployment.svg` (`prod.deployment-guide`, `prod.istio-networking`) is deployment-centric; OHIF viewer has its own architecture diagram (`dev.architecture-sonador.ohif`). No single *logical* diagram spanning all subsystems (Sonador web, Orthanc + plugin, OHIF viewer, IdP/Cognito, Kafka). | 🟡 |
| **Data Flow Diagrams (DFD)** | FDA cybersecurity — PHI & token flows | Kafka producer ASCII flow (`dev.kafka`); authorization-engine SVG (`security.authorization`). No integrated diagram of PHI moving DICOM upload → Orthanc → viewer, nor of credential/token validation at each hop. | 🟡 |
| **Use Case Diagrams** | IEC 62366 actors/intended use | Reviewer-worklist use case described in prose only (`workflow.reviewer-worklists`). No actor diagram for the ADMIN / REVIEWER / TECHNICIAN / REFERRING roles. | ❌ |
| **Sequence Diagrams** | Interaction design / traceability | None. Auth-engine evaluation, OIDC login + IdP group sync, token validation against ACL, and authorized-upload chain are all prose-only (`security.authorization`, `dev.credentials-management`, `security.index`). | ❌ |
| **Component Diagrams** | IEC 62304 software-item decomposition | OHIF viewer architecture diagram + repo structure (`dev.architecture-sonador.ohif`); Orthanc-plugin module/startup structure (`dev.orthanc-plugin`, ASCII-ish); Kafka module table (`dev.kafka`). Backend (Django/FastAPI/Sonador) decomposition is prose. | 🟡 |
| **Deployment Diagrams** | FDA system/deployment context | `sonador.production-deployment.svg` (k8s pods, DBs, PVs, ingress) plus Istio PeerAuthentication / AuthorizationPolicy config (`prod.deployment-guide`, `prod.istio-networking`). | ✅ |
| **Hans Extras** | (placeholder) | @hans.deraad to enumerate additional required items. | ❌ |
| **Accreditation** | Regulatory mapping | No accreditation/standards-mapping document. | ❌ |
### Recommended additions (SaMD gaps not in the original list)
| Artifact | SaMD rationale | Current coverage | Status |
|---|---|---|---|
| **Threat model / security architecture** | FDA cybersecurity — trust boundaries & attack surface | Hierarchical patient→study→series trust-check ASCII (`security.orthanc-authorization-plugin`) + authorization SVG; no attack-surface / threat-scenario / trust-boundary model. | 🟡 |
| **SBOM / SOUP inventory** | IEC 62304 SOUP; FDA SBOM | Dependencies mentioned inline only (SQLAlchemy, Guru client, Sonador IO client, confluent_kafka, OHIF extensions). No formal manifest. | ❌ |
| **Entity/ER diagram** | Design clarity | Data models well-documented in tables (`dev.data-models`: ImagingPatient/Study/Series/DcmInstance, ACL models, worklist, comments) but no ER diagram. | 🟡 |
| **Audit-logging / access-event documentation** | HIPAA accountability | Not documented. | ❌ |
| **Machine-readable API spec (OpenAPI/Swagger)** | Validation & submission | API documented in prose + inline JSON (`security.authorization`, `dev.credentials-management`, `dev.kafka`, `workflow.reviewer-worklists`); no OpenAPI. | 🟡 |
---
### Diagram / documentation checklist
Core set (from the original #55 documentation checklist):
- [ ] High-Level System Architecture Diagram — *consolidate a logical all-subsystem view; deployment SVG + OHIF diagram exist as starting points*
- [ ] Data Flow Diagrams (DFD) — *priority: integrated PHI + credential/token flow across upload → Orthanc → viewer*
- [ ] Use Case Diagrams — *actors = ADMIN / REVIEWER / TECHNICIAN / REFERRING; reviewer-worklist prose can seed this*
- [ ] Sequence Diagrams — *auth-engine evaluation, OIDC login + IdP group sync, token→ACL validation, authorized upload*
- [ ] Component Diagrams — *extend beyond OHIF/Orthanc-plugin to the Django/FastAPI backend decomposition*
- [ ] Deployment Diagrams — *largely complete (`sonador.production-deployment.svg` + Istio); confirm currency*
- [ ] Hans Extras — @hans.deraad please add any additional items here
- [ ] Accreditation — *standards/regulatory mapping document*
SaMD-recommended additions:
- [ ] Threat model / security architecture (trust boundaries, attack surface)
- [ ] SBOM / SOUP third-party component inventory
- [ ] Entity/ER diagram for the data models
- [ ] Audit-logging / access-event documentation
- [ ] Machine-readable API specification (OpenAPI/Swagger)
---
### Notes
- Coverage assessed June 2026 against the platform docs wiki checkout (`oaktree-env/docs`). Re-verify before submission as the docs evolve.
- Deployment documentation is the most mature; **sequence diagrams, use-case diagrams, an integrated PHI/credential DFD, a threat model, and an SBOM** are the highest-value gaps for SaMD readiness.
#### Project Tracking
OP#75
OP#135
issue