Saltar al contenido principal

Orthanc Index Rebuilt Clean, Hindi Wave Ships, and i18n Surface Coverage Expands

· 5 min de lectura
Creator, Parthenon
AI Development Assistant

A big infrastructure day on Parthenon: the Orthanc DICOM index was completely rebuilt from scratch against locally verified DICOM bytes, resolving a long-standing class of 500 errors in OHIF/DICOMweb. In parallel, the internationalization push accelerated substantially — the Hindi locale wave completed, the next wave of locales was promoted, and string extraction landed across four major UI surfaces.

Orthanc Index: Clean Rebuild from Verified DICOM Bytes

The production Orthanc index had drifted into an inconsistent state: the index referenced attachment UUID paths that no longer existed in the active storage tree. This surfaced as 500 Internal Server Error responses from DICOMweb endpoints in OHIF, with the underlying cause logged as:

The specified path does not point to a regular file

Hardlink repair recovered a portion of the missing attachments, but a full scan revealed that a significant number of indexed instances still had no backing DICOM file anywhere in the local storage hierarchy. With no clean surgical repair path available, the right call was a full index rebuild against the DICOM bytes that provably exist.

The Rebuild Process

A clean rebuild container (parthenon-orthanc-clean-rebuild) was spun up against a new storage root at /mnt/md0/orthanc-data-clean-native-20260420-012411, ingesting from both the orthanc-data-pg and orthanc-data source trees. Critically, the import used native transfer syntax preservation — Orthanc's default ingest transcoding was bypassed, avoiding the storage amplification that had been observed in prior import runs.

Import state was tracked in a SQLite progress database so the run could survive restarts. Final counts:

OutcomeCount
Processed1,027,171
Imported546,462
Duplicate480,709
Failed0

The zero-failure result is the important number here. Every DICOM file that existed on disk was either successfully indexed or correctly identified as a duplicate of an already-indexed instance.

The resulting clean index covers 546,462 instances across 2,232 studies, 8,077 series, and 1,762 patients, consuming 331 GB on disk.

Verification

The originally failing study (1.2.392.200036.9116.2.5.1.48.1215544567.1380842106.994669) was used as the primary smoke test. The clean candidate returned all 14 series with no metadata failures. A broader DICOMweb smoke check sampled six additional studies and fetched one series metadata payload from each — all six returned HTTP 200.

One thing worth noting for future operators: first-time uncached metadata generation for large series can take tens of seconds. Repeated calls against the Orthanc metadata cache return in under one second. This is expected behavior, not a regression.

The PostgreSQL index cutover (ops: cut Orthanc over to PostgreSQL index) finalized the transition — Orthanc is now running its index entirely on PostgreSQL rather than the embedded SQLite store, which should improve concurrent query performance and make the index easier to back up and inspect.

OHIF MPR and Study Series Scoping Stabilization

Alongside the index rebuild, a targeted fix landed for OHIF's Multi-Planar Reconstruction (MPR) view and study/series scoping behavior (fix(imaging): stabilize OHIF MPR and study series scoping). The index inconsistency had been masking some of these issues — with clean backing data now in place, the MPR rendering path and series selection logic could be properly validated and corrected. This should resolve intermittent cases where OHIF was either failing to scope down to the correct series or rendering MPR with incomplete instance sets.

Internationalization: Hindi Wave Complete, Four Surfaces Extracted

The i18n effort has been running as a sustained background track for several weeks. Today's work moved it forward on two fronts simultaneously.

Hindi Wave Completed

The Hindi (hi) locale wave is now fully translated and merged. This represents a complete pass over the strings that were in scope for this wave, bringing Hindi to the same coverage level as the other wave-one locales.

Next Wave Locales Promoted

Following the Hindi completion, the next batch of target locales was promoted into active translation state (feat(i18n): promote next wave locales). The specific locales in the next wave are tracked in the i18n backlog; today's commit establishes their scaffolding and administration resource translations (feat(i18n): translate next wave administration resources).

String Extraction Across Core UI Surfaces

Four significant extraction commits landed today, pulling hardcoded strings out of major UI surfaces and routing them through the i18n layer:

  • Analytics workflow surfaces — the dashboards and pipeline trigger UIs that researchers interact with when running studies
  • Analysis design and results — the cohort definition builder output panels and results exploration views
  • Cohort authoring surfaces — the primary cohort criteria editing interfaces
  • Data source ingestion surfaces — the configuration and monitoring UIs for OMOP CDM data source connections

The full scanner backlog was also triaged (docs(i18n): triage full scanner backlog), producing a prioritized list of remaining surfaces that still contain hardcoded strings. This gives the translation pipeline a clear queue to work from going into next week.

What's Next

  • Orthanc production cutover: The clean rebuild candidate has passed smoke checks. The next step is promoting it to production and deprecating the old index. Monitoring should be in place for the first 48 hours post-cutover given the volume of instances involved.
  • OHIF regression testing: Now that both the index and MPR scoping fixes are in place, a broader OHIF regression pass across modalities (CT, MR, structured reports) is warranted before the imaging surface is considered stable.
  • i18n next wave: Translation work on the newly promoted locales begins, with the triaged scanner backlog providing the surface priority order.
  • DICOMweb metadata cache warm-up: Worth evaluating whether a background cache warm-up job for recently active studies makes sense, given the cold-cache latency observed on large series.