Updates to Sonador Documentation describing Sonador Viewer (OHIF refactor) to React 18, M3D, and Cornerstone3D viewports

Documentation updates describing refactors made to the Sonador Viewer and tracks changes to oak-tree/medical-imaging/ohif-viewers!58.

• Dependency updates: Cornestone3D, Three.js, React.js
• Significant updates to how the Cornerstone3D cache works within the Sonador Viewer and its React-VTK-JS components.
• Updates to Segmentation Viewer PoC.
• Port of important @ohif/ui-next components to a new module under platform.
• Integration PoC of SegmentationService and ViewportGridService to allow for undo/redo capability within the Semgnetation Viewer.
  • Inclusion of OHIF-V3 segmentation table for managing segmentation and M3D model state.
• Updates to 3D viewer allowing Three.js to store references to data within the Cornerstone3D cache, allowing for all viewports to consume from cached data rather than requiring that data be re-transferred every time an M3D collection or scene is opened.
• Web-development reference documenting the Sonador/Orthanc plugin architecture (the backend view layer that the viewer consumes). See oak-tree/medical-imaging/imaging-development-env#56 (closed).
• Client-API reference documenting the Sonador IO client (local/remote/sr) — how applications consume the Sonador and Orthanc APIs. See oak-tree/medical-imaging/imaging-development-env#56 (closed).

---

Documentation rundown

This MR touches the docs in five groups: the Sonador Viewer (OHIF) refactor docs, a new security page covering the forked authorization plugin, a new data-streaming page covering Kafka, a new web-development page covering the Sonador/Orthanc plugin architecture, and an expanded client-API page covering the Sonador IO client.

📘 Docs split (Sonador vs. framework). General Guru/Acorn framework reference (the lib/guru, lib/secure, filtering/forms patterns, and the Guru Client library conventions that underpin both the view layer and the client) lives in the Acorn docs and is delivered in the companion MR django-apps/docs/guru!1 (merged) — django-apps/docs/guru!1 (merged). This MR keeps the Sonador/MedTech-specific material (the Orthanc plugin, viewer, security plugin, Kafka, and the Sonador IO client) and cross-links to the framework pages rather than duplicating them. Both MRs address oak-tree/medical-imaging/imaging-development-env#56 (closed).

Viewer architecture & frontend (OHIF + Cornerstone3D)

• dev.onboarding (new) — developer onboarding / "start here" entry point.
• dev.architecture-sonador.ohif — viewer monorepo architecture and subsystem overview.
• dev.ohif-frontend — frontend developer index / navigation.
• dev.ohif-frontend.cornerstone3d-architecture — Cornerstone3D integration (cache, rendering, state).
• dev.ohif-frontend.cornerstone3d-tools — Cornerstone3D tools & interaction.
• dev.ohif-frontend.vtk-cornerstone3d (new) — VTK ↔️ Cornerstone3D (volumes / MPR / volume rendering).
• dev.ohif-frontend.segmentation-editor (new) — segmentation editor & polymorphic surface rendering.
• dev.ohif-frontend.m3d-viewer (new) — Three.js STL/GLB model viewer + m3dCache.
• dev.ohif-frontend.react-vtkjs-viewports — legacy react-vtkjs-viewport (now marked deprecated).
• dev.index — development index updated to link the new pages.

Security: Sonador Authorization Plugin (Orthanc)

• security.orthanc-authorization-plugin (new) — documents Sonador's fork of the Orthanc Advanced Authorization Plugin. Covers:
  • Background on the upstream plugin and its hierarchical (per-level) resource checks — the mechanism behind the empty-uri ancestor problem.
  • The IncludeResourceUri config option (leaf-only URI embedding, folded into the cache key) and the action field (closed-enum, e.g. comment, propagated to every hierarchy level) added in the fork.
  • The resource-validation request payload contract and the comment routes (standard Orthanc API + DICOMweb) that trigger action: comment.
  • Caching considerations and the security rationale (action derived from the trusted server-side route, never raw client input; folded into the cache key to prevent cross-action replay).
  • A traceability table linking the driving issues and MRs.
• security.index — security overview updated to link the new page.

Traceability for the authorization page: oak-tree/medical-imaging/orthanc-authorization#1 (closed) (!1), oak-tree/medical-imaging/sonador#52 (closed), oak-tree/medical-imaging/sonador#75 (closed) (!87), and the orthanc-sonador container build (!52). It cross-references the existing security.authorization ACL page.

Data streaming: Kafka (Orthanc/Sonador)

• dev.kafka (new) — documents how Orthanc/Sonador publishes imaging events to Kafka (the producer side and the message contract on the topic). Addresses every checklist item in #2 (closed):
  • What Kafka is and its role — topic/producer/consumer primer; streaming ingestion, event coordination, AI/ML integration; single-topic-per-imaging-server with messages disambiguated by the Resource field and the operation opcode.
  • Architecture / data exported / triggers — in-Orthanc producer diagram; the async confluent_kafka delivery model (30s TIMER_30S poll, flush-on-ORTHANC_STOPPED, retry-on-failure delivery report); the Sonador → Kafka → {topic, servers} config block; and the two export mechanisms — event-driven (on stored instance and STABLE_PATIENT/STABLE_STUDY/STABLE_SERIES) and on-demand REST (GET previews / POST publishes at /{patients,studies,series,instances}/<id>/kafka plus worklist/comment child endpoints, with a full endpoint↔️opcode table). Complete message schema (OrthancServerId, Resource, ID, DCM, Source, lifted PatientID/StudyID/SeriesInstanceUID, plus push-only User/RequestData/operation/status).
  • Orthanc modules and class structure — module breakdown of sonador_orthanc/kafka and the SonadorProducer, KafkaMixin, OrthancKafkaExportView, OrthancChildKafkaExportView classes.
  • Sonador IO client and tools — the IO-client POST-trigger methods, the CLI, and consumer guidance.
  • Available integrations and examples — quickstart, the Hello Kafka / Docker data-lab blogs, the examples repo, and the planned sample DICOM-SR consumer (oak-tree/medical-imaging/imaging-development-env#92).
• dev.index — development index updated to link the new Kafka page.

Web development: Orthanc Sonador plugin architecture

• dev.orthanc-plugin (new) — documents the Sonador/Orthanc plugin as the backend view layer the viewer and IO client consume. Covers:
  • The OrthancBaseView request lifecycle and how the plugin maps Orthanc REST routes onto Guru-style views.
  • The two-view resource pattern (management view = list + create; REST view = retrieve + update + delete) as it appears in the plugin, mirroring the Guru GuruApiObjectManagementView / GuruApiRestView pattern.
  • The plugin SQLAlchemy data model for extension resources associated with DICOM Core resources.
  • SonadorServerManager and the subsystem inventory (how the plugin wires resources, extension models, and server access together).
  • 📘 Cross-link to the framework pages: the Guru view/form/filter/security patterns this plugin builds on are documented in the Acorn docs and delivered in django-apps/docs/guru!1 (merged) — django-apps/docs/guru!1 (merged). This page is the Sonador-specific application of those patterns.
• _sidebar.md — adds the Orthanc plugin architecture page under the Development section.

Client API: Sonador IO client (dev.data-models)

• dev.data-models — Sonador IO client documentation answering the "How are the APIs consumed?" side of #56 for Sonador. Filled the outstanding TODOs, grounded in the Sonador IO and Sonador ETL client sources:
  • Design philosophy + the two server classes (SonadorServer for the web app; SonadorImagingServer for an Orthanc-backed PACS), the base model interface (fetch_endpoint/pk_attr/resource_url/update/delete), the base collection interface (fetch/fetch_modelinstance/create + parent threading and the cached-lookup mixin), and the REST-like rules of thumb.
  • local — reading and normalizing DICOM from disk (sonador.helpers.local.dcmread_backfill for missing UIDs/timestamps, dcm_part10_backfill for Part-10 file-meta) and the in-memory cached ORM (SonadorLocalObject / SonadorLocalCollection).
  • remote — the imaging resource hierarchy (ImagingPatient → ImagingStudy → ImagingSeries → DcmInstance), querying via secure-find / the query_* family, parented extension models (ResourceComment), and a connect → query → navigate example.
  • sr — DcmSRSeries / DcmSRInstance reference-UID resolution back to the source image series (shared base with DICOM-SEG).
  • 📘 Cross-link to the framework pages: the underlying Guru Client conventions and the "extend the client for a new API" walkthrough live in the Acorn docs and are delivered in django-apps/docs/guru!1 (merged).

Navigation

• _sidebar.md — adds the new viewer pages, the security authorization-plugin page, the data-streaming (Kafka) page, and the Orthanc plugin architecture page to the sidebar.