OpenDiag: Open Diagnostic Systems
- OpenDiag is a collection of open diagnostic infrastructures that validate DICOM files, detect model biases in pathology, and enable real-time KPI extraction in telecom.
- It leverages community collaboration, privacy-preserving client-side de-identification, and interactive JSON-based reporting to enhance usability and interoperability.
- By integrating standardized protocols and novel machine learning techniques, OpenDiag facilitates robust audits, debugging, and multimodal diagnostic workflows across diverse domains.
OpenDiag is a name used in the supplied literature for several open or open-source diagnostic infrastructures rather than for a single software package. The earliest explicit use designates a community-driven Web DICOM validation service for standard medical imaging objects, intended to detect non-conformant DICOM instances, present structured validation results, enable community sharing, and preserve patient privacy through client-side de-identification (Silva et al., 2018). Later work uses the same name for an open-source, model-agnostic framework for detecting bias and overfitting in whole-slide-image models (Sildnes et al., 3 Mar 2025), and for an in-kernel real-time radio KPI extraction layer that enables KPI-driven congestion control on unrooted Android 5G phones (Larrea et al., 2 Sep 2025). Related papers describe “OpenDiag-style” systems for DICOM-centered multimodal integration, interpretable diagnostic reasoning, robust report generation under missing modalities, open-set diagnosis, and standardized encoding of AI outputs, suggesting a broader association of the term with open, interoperable, and operationally deployable diagnostic workflows (Rijhwani et al., 17 Dec 2025, Wang et al., 2024, Shaik et al., 8 Nov 2025, Prabhu et al., 2019, Bridge et al., 2021, Choudhary et al., 20 Mar 2026, Khushi et al., 2020).
1. Original formulation: community-driven DICOM conformance diagnosis
OpenDiag was first presented as a community-driven validation service for standard medical imaging objects. Its stated target was not only DICOM experts but also programmers, IT staff, and healthcare technicians who need to determine why an object is rejected by PACS, viewers, or archival systems. The motivating problem was that interoperability failures in medical imaging often arise from non-conformant DICOM objects or from objects that are formally close to compliant but inconsistent with the profile or modality they are supposed to represent. The paper enumerates several recurring failure modes: omitted required attributes, malformed or context-inconsistent values, vendor outputs that are technically DICOM yet incompatible in real deployments, and data inconsistencies introduced during manual entry (Silva et al., 2018).
The system was positioned against several limitations of existing validation tools. Those tools were described as tending to focus on low-level syntax checking rather than semantic conformity, requiring expert knowledge to interpret results, being tied to local installations rather than shared services, lacking convenient mechanisms for result reuse across users, and being insufficiently privacy-aware when files contain patient data. OpenDiag therefore defined a broader objective than mere syntax validation: it combined usability, accessibility, collaboration, privacy preservation, and practical diagnosis in a single Web service (Silva et al., 2018).
Its design goals were explicitly stated. They include ease of use, actionable output, privacy preservation, community sharing, support for standard objects, and practical diagnosis. The service aims to identify not only missing tags but also value-level problems and structural inconsistencies, while presenting the findings in a form understandable to users who are not necessarily DICOM experts. This combination distinguishes the 2018 OpenDiag from narrower validators that primarily expose raw standard violations without operational triage.
2. Validation model, workflow, and output schema
The validation workflow described for OpenDiag is service-oriented and privacy-aware. A user submits a standard DICOM instance, such as a Computed Radiography Image Storage object. Before data leave the client side, the design includes de-identification or privacy-preserving handling so that identifying information can be removed or masked. The purpose is twofold: the validator can still inspect structure and conformance, and validation outcomes can be shared within a community without unnecessarily exposing patient-identifying information (Silva et al., 2018).
On the service side, OpenDiag checks the submitted object against the applicable DICOM information model and module requirements. The validator determines whether attributes are missing, present but empty, invalid, or not allowed in the given context. The example report is a machine-readable JSON validation file with fields such as validationid, date, service, valid, and results. Each result is then decomposed by IE and module, and each module is assigned a status of VALID, WARNING, or [HAS](https://www.emergentmind.com/topics/horizon-aware-schedule-has) ERRORS. The inconsistency lists are further structured under missing_attributes, missing_values, invalid_values, and not_allowed (Silva et al., 2018).
The object model used in reporting follows standard DICOM terminology. The example spans Information Entities such as Patient, Study, Series, Image, and Equipment, and also includes modules such as SOP Common and Common Instance Reference. The validator is sensitive to DICOM attribute types, including Type 1, Type 2, Type 3, Type 1C, and Type 2C. The example JSON lists missing attributes such as PatientIdentityRemoved, ClinicalTrialProtocolID, ProcedureCodeSequence, SeriesDate, ImageType, BurnedInAnnotation, LossyImageCompression, InstanceCreationDate, and ReferencedSeriesSequence (Silva et al., 2018).
A further design feature is interactive interpretation. The paper suggests that when validation results are ambiguous, or when a file is incomplete, the user can provide contextual input to help interpret the findings. DICOM compliance often depends on modality, workflow, or institutional conventions; OpenDiag is therefore not presented as a purely rigid checker but as an interactive diagnostic aid. This structured, shareable JSON output makes the service useful for both human diagnosis and software integration, while the module-by-module organization allows rapid triage of where an object becomes suspicious or non-conformant.
3. Standards-aligned ecosystem and multimodal extensions
Several later systems are described as compatible with, or intelligible through, an OpenDiag-style view of diagnostic infrastructure: open standards are preserved, heterogeneous data sources are connected rather than replaced, and outputs remain machine-readable and clinically interoperable. In this ecosystem, DICOM is not merely an image container but the backbone for annotations, measurements, segmentation objects, and multimodal navigation.
The most explicit standards layer is provided by highdicom, a free, open-source Python library that exposes a high-level API for creating, reading, and interpreting DICOM-compliant annotations and machine-learning outputs. Its object model mirrors the DICOM information model through classes derived from highdicom.SOPClass, while retaining low-level pydicom.Dataset behavior. The paper focuses on highdicom.seg.Segmentation, highdicom.sr.ComprehensiveSR, and highdicom.sr.Comprehensive3DSR, and also notes support for the MicroscopyBulkSimpleAnnotations SOP class. The library implements coded content via highdicom.sr.CodedConcept, supports TID 1500 “Measurement Report”, integrates with NumPy, PyTorch, TensorFlow, OpenCV, and ITK, and enables a fully DICOM-based workflow for both pathology and radiology use cases (Bridge et al., 2021).
A DICOM-centered multimodal integration framework for radiology and pathology extends this pattern. That system is designed to operate within Kaapana or as a standalone package, with a PACS/archive layer implemented by dcm4chee-arc, a JavaScript backend API for study retrieval, concept mapping, and segmentation pipeline execution, and a React client served through NGINX. Its combined viewer links OHIF for radiology and SLIM for pathology in a synchronized split-screen layout. Whole-slide images are converted to DICOM-WSI with wsi-dicomizer; radiology studies are converted with dcm2niix, segmented with TotalSegmentator, and packaged into DICOM-SEG via dcmqi; SimpleITK is installed in the standardized Docker workflow. The resulting multimodal package contains the original radiology DICOM volume, the DICOM-WSI pathology file, the anatomical site label, and a DICOM SEG object, thereby supporting organ-level mapping and synchronized cross-modal navigation (Rijhwani et al., 17 Dec 2025).
An earlier digital microscopy workflow anticipates similar concerns from the pathology side. Two Java-based open-source tools, Snapshot Creator and NDPI-Splitter, were developed for very large virtual microscopy files. Snapshot Creator extracts a JPEG snapshot from a large NDPI slide, links it to patient pathology and treatment information in a customized Caisis deployment, and publishes it through Microsoft Deep Zoom. NDPI-Splitter divides large NDPI files into TIFF tiles for analysis in Metamorph or Matlab, with optional filtering of empty tiles via intensity-based or compression-based algorithms. This workflow ties image management, searchable publication, archiving, and downstream analysis into a single open-source pathology infrastructure (Khushi et al., 2020).
Taken together, these systems indicate that OpenDiag-style architectures are tightly coupled to standard objects, standard services, and explicit metadata semantics. A plausible implication is that the original emphasis on DICOM conformance checking naturally broadened into a concern with end-to-end interoperability: validation, annotation encoding, archive integration, synchronized viewing, and downstream AI outputs all remain within the same standards-governed diagnostic substrate.
4. Open-world reasoning, incomplete inputs, and automated diagnosis
The supplied literature also associates OpenDiag with diagnosis under incomplete knowledge, incomplete input, or explicitly inspectable reasoning. In this usage, the emphasis shifts from file conformance to clinical inference, but the recurrent concerns remain interpretability, robustness, and operational usefulness.
DiReCT was introduced as a benchmark for diagnostic reasoning for clinical notes. It contains 511 clinical notes from MIMIC-IV, sampled from 25 disease categories across 5 medical domains—cardiology, gastroenterology, neurology, pulmonology, and endocrinology. Each note includes six extracted fields from the SOAP record, the text explicitly revealing the primary discharge diagnosis is removed, and physician annotators produce explanation tuples of the form , where is an observation, is a rationalization, and is the supported diagnostic node. The diagnostic task is defined as predicting the final diagnosis and explanation from note with either a procedural graph or a richer diagnostic knowledge graph . Evaluation uses diagnostic accuracy, observation completeness, and explanation faithfulness. GPT-4 turbo is strongest among the reported models, reaching under and under 0, but the paper emphasizes a substantial gap between LLM reasoning and physician reasoning (Wang et al., 2024).
Open Set Medical Diagnosis addresses a different incompleteness problem: unseen diseases at deployment. It reframes diagnosis as an open-set learning problem in which a model must both diagnose conditions in 1 and reject out-of-scope conditions as NOTA. The paper distinguishes 2 from 3, compares confidence-thresholded cross-entropy, an explicit background class, and Entropic Open-Set (EOS) loss, and evaluates both centralized diagnosis and distributed multi-site ensembles. Its main conclusion is that explicitly modeling unseen conditions improves robustness, that the background class performs best in centralized open-set diagnosis, and that the optimal strategy in distributed settings depends on the ensemble design (Prabhu et al., 2019).
DiA-gnostic VLVAE treats robustness to missing modalities as the central deployment problem in radiology report generation. The task is defined over triples 4, where 5 is the chest X-ray image, 6 is structured clinical context, and 7 is the report, with the model required to support both 8 and the missing-modality case 9. Its architecture uses EfficientNetB0 with Guided Context Attention for vision, a Transformer for text, a Modality Abstractor with bidirectional cross-attention, and a VL-MoE-VAE that disentangles 0, 1, and 2. The shared posterior is a weighted mixture of modality-specific experts, so when language is missing the router learns 3 and 4. Orthogonality and InfoNCE-based alignment are added to prevent entanglement and clinically unfaithful hallucinations. On IU X-Ray and MIMIC-CXR, the reported BLEU@4 scores are 0.266 and 0.134, respectively (Shaik et al., 8 Nov 2025).
A more procedural example is ODySSeI, an open-source end-to-end framework for invasive coronary angiography. It processes a raw ICA image in three stages: YOLO11m lesion detection, DeepLabv3+ lesion segmentation, and rule-based QCA-free lesion severity estimation. Its Pyramidal Augmentation Scheme (PAS) combines seven static augmentations, five dynamic augmentations, and Mosaic composite augmentation, yielding a 2.5-fold improvement in [email protected] for lesion detection and a 1–3% gain for lesion segmentation over non-augmented baselines. The severity module computes Minimum Lumen Diameter (MLD) and Diameter Stenosis (DS) from the predicted mask, with 5. Reported mean absolute differences in MLD are 2.378 ± 2.023 px on FAME2 validation, 2.470 ± 2.133 px on FAME2 test, and 2.877 ± 2.444 px on FC (Choudhary et al., 20 Mar 2026).
These works are not the same system as the 2018 Web validator. They do, however, extend the scope of open diagnostics into clinician-like reasoning, abstention on unknown conditions, graceful degradation under missing context, and end-to-end lesion analysis. This suggests that, in later usage, OpenDiag can function as a conceptual label for diagnosis that remains inspectable and robust when the input distribution or task structure departs from idealized closed-world assumptions.
5. Pathology model debugging and shortcut detection
A later explicit use of the name refers to an open-source, model-agnostic debugging framework for large pathology images. Here OpenDiag is designed to detect when deep learning models on whole-slide images are exploiting non-clinical shortcuts such as background color, stain intensity, scanner artifacts, tissue preparation artifacts, batch effects, or tissue source site (TSS) signatures rather than learning robust tissue features. The framework works on latent embeddings rather than on architecture-specific attribution mechanisms: for an input tile 6, the model produces an embedding 7, and OpenDiag inspects these feature vectors through UMAP and linear probing (Sildnes et al., 3 Mar 2025).
The methodology has two stages. First, a trained model processes pathology tiles and emits high-dimensional embeddings, such as the 1536-dimensional vectors used with an Inception V4 encoder in the experiments. Second, the framework performs qualitative inspection with UMAP and quantitative shortcut detection with a frozen-backbone linear classifier. The default UMAP implementation is the GPU-optimized RAPIDS/cuML version, with min_dist = 0.1 and n_neighbors = 15; the framework supports comparing feature-space and raw-image-space embeddings, interactive web-based exploration, and hiding or showing classes to inspect cluster structure. Linear probing is trained with Adam for 20 epochs and is intended to measure whether embeddings contain enough information to predict a confounder such as TSS (Sildnes et al., 3 Mar 2025).
The reported experiments use TCGA-LUSC with 1100 slides from 495 patients, including 753 tumor slides and 347 normal slides. Slides are tiled into 1024×1024 patches with 25% overlap, tiles with more than 85% whitespace are removed, tiles are downsampled to 299×299, and Vahadane normalization is applied. Two model families are compared: Phikon-v2, a DINOv2-based foundation model with about 1 billion parameters trained on 460 million pathology tiles, and a self-supervised MoCo v1 with Inception V4 encoder. Linear probing on Phikon-v2 embeddings achieves 63.2% accuracy for TSS prediction, whereas the Inception V4 embeddings achieve 34% accuracy, approximately 14 percentage points above random guessing. GPU UMAP yields about 5× speedup at 1,000 samples and about 8× speedup at 10,000 samples; processing 100,000 feature vectors uses about 17 GB of VRAM. Sequential checkpointing reduces VRAM usage by about 50% but increases training time by 29% (Sildnes et al., 3 Mar 2025).
The significance of this OpenDiag is diagnostic only in the broad sense: it diagnoses the failure modes of models rather than diseases in patients. Its results show that even very large foundation models can strongly encode site-specific artifacts, and that good downstream performance does not imply freedom from hidden confounders. Within the supplied corpus, this is the clearest instance of OpenDiag as a research instrument for robustness auditing.
6. Non-medical reuse of the name: real-time radio KPI extraction
A distinct and non-medical OpenDiag appears as the enabling substrate of Biscay, a radio KPI-driven congestion control system for mobile networks. In this context OpenDiag is an in-kernel real-time radio KPI extraction layer. It was introduced because prior on-device KPI tools were not adequate for live congestion control: MobileInsight is described as offline-oriented and, when used online, effectively provides coarse ~1s granularity; the Android Telephony API exposes only a small KPI subset at coarse cadence; and sniffer-based or base-station-assisted approaches are impractical for ordinary phones (Larrea et al., 2 Sep 2025).
This OpenDiag interfaces directly with the Qualcomm diagnostic path through the kernel diagchar module and bypasses the user-space pipeline used by MobileInsight. A key mechanism is a privileged control channel that instructs the modem to drain its internal buffer every 1 ms. The implementation is a multi-threaded kernel module in which one thread parses diagnostic data and extracts requested KPIs, while another handles the control channel and periodic modem-buffer draining. The KPI family emphasized for bandwidth estimation includes Transport Block Size (TBS) and Number of Physical Resource Blocks (PRBs), with related parameters such as MCS, MIMO, and carrier aggregation. Biscay then reconstructs bandwidth using either a 3GPP formula-based method or a MAC-granted-bytes method (Larrea et al., 2 Sep 2025).
The integration path is explicit: OpenDiag extracts KPIs, the bandwidth-determination layer estimates cellular-link bandwidth, the system compares this with an end-to-end estimate to localize the bottleneck, RTT is obtained from Linux TCP machinery, and the congestion window is set accordingly. The implementation consists of about 2500 lines of C code, was tested on Android 11, 12, 13, and 14, and is reported on devices including Pixel 5, OnePlus Nord 5G, OnePlus Nord N30, Nothing Phone 2, Nexus 6P, Samsung Galaxy Note 4, and Quectel modems. It uses shared memory, triple buffering, and a subscription API; for user-space transport stacks it exposes libOD, a POSIX-style API (Larrea et al., 2 Sep 2025).
The reported measurement result is a granularity improvement of about 100x over alternatives, from approximately 1000 ms to about 10.9 ms. Parsing operates on the order of tens of microseconds, compared with hundreds of milliseconds for MobileInsight, and battery impact is described as negligible over a 60-minute test relative to a screen-on baseline. This OpenDiag is separate from the medical systems discussed above. Its inclusion demonstrates that the name has become polysemous across domains, but in each case it denotes a practical, open, real-time diagnostic layer meant to expose internal system state in a form usable for downstream decision-making.