DICOM (Digital Imaging and Communications in Medicine) is the international standard for storing, transmitting, and managing medical images and associated metadata. It defines both a file format that binds pixel data to rich patient, study, and acquisition attributes, and network services for exchanging images between modalities, archives, and viewing workstations. DICOM enables interoperability across radiology, cardiology, and other imaging-intensive specialities, and serves as the canonical data substrate for medical imaging artificial intelligence.
Semantic Classification
Content
Compositional Relationships (Components)
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMFileFormat))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMNetworkServices))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMSOPClasses))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMStructuredReporting))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMweb))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMSegmentationIOD))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMRTPlan))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:hasPart ai:DICOMDataDictionary))
Dependency Relationships
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:InteroperabilityConformance))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:DataProtectionCompliance))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:PictureArchivingSystem))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:PatientPrivacyControls))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:NetworkTransportLayer))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:requires ai:UniqueIdentifierAllocation))
Capability Relationships
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:MedicalImagingAI))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:ClinicalDecisionSupport))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:CrossVendorInteroperability))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:Teleradiology))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:FederatedLearningOverClinicalImages))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:ImageSegmentationAnnotation))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:enables ai:DigitalPathologyWorkflow))
Implementation Relationships
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:implements ai:SemanticInteroperability))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:implements ai:DataGovernancePolicy))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:implements ai:RESTfulWebServices))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:implements ai:StudySeriesInstanceHierarchy))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:implements ai:ConformanceStatementRequirement))
Reduction Relationships
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:reducesTo ai:BinaryImageFileWithMetadata))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:reducesTo ai:NetworkMessageExchangeProtocol))
Support and Interoperation Relationships
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:supports ai:DeepLearningModelTraining))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:supports ai:ComputerVisionPipeline))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:supports ai:FederatedLearningDataNode))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:supports ai:ClinicalAuditAndProvenance))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:bridgesTo ai:HL7FHIRImagingStudyResource))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:bridgesTo ai:ElectronicHealthRecord))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:contrasts ai:ProprietaryImagingFormat))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:contrasts ai:NIfTIFormat))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:relatedTo ai:DrugDiscoveryDataset))
SubClassOf(ai:DICOMStandard
ObjectSomeValuesFrom(ai:relatedTo ai:AnnotationDataWorkflow))
About
DICOM is the foundational infrastructure of all modern clinical imaging. Originating from a collaboration between the American College of Radiology (ACR) and the National Electrical Manufacturers Association (NEMA) in 1983, the standard evolved from ACR-NEMA 1.0 (1985) through version 2.0 (1988) into the full DICOM 3.0 release published in 1992–1993. The 1993 release was a fundamental redesign: it introduced a hierarchical object model binding patient, study, series, and image instance into a single unit with globally unique UIDs, defined network services for multi-vendor exchange, and established the unique identifier system that enables global disambiguation of every image ever created. Governance migrated to the DICOM Standards Committee in 1995 as cardiology and other specialities joined, and the standard is now also codified as ISO 12052 — most recently updated as SIST EN ISO 12052:2026 covering workflow and data management. The standard is published by NEMA as PS3 (Parts 1 through 20) and evolves continuously: a 2025c release extended AI-annotation support and added profile compliance declarations for DICOMweb implementations. Every imaging modality from CT and MRI to digital mammography, nuclear medicine, and whole slide scanning produces DICOM objects by default, making it the universal input format for any clinical AI or Computer Vision system operating across Medical Imaging.
The relationship between DICOM and HL7 FHIR is complementary and increasingly codified. FHIR carries clinical context, diagnostic reports, and medication data via RESTful APIs, while the FHIR ImagingStudy resource carries DICOM Study Instance UIDs that link back into the Picture Archiving and Communication System for image retrieval — unifying the two world views of a patient encounter into a coherent Electronic Health Record view. This integration is central to Digital Health platform architecture, where imaging and clinical data must flow together to support Clinical Decision Support, research analytics, and population health management. The Data Protection and Privacy requirements governing DICOM objects are substantial: the standard incorporates de-identification profiles (PS3.15, Annex E) with attribute confidentiality options, and compliance with GDPR, HIPAA, and NHS Data Security and Protection Toolkit mandates is a precondition for any production deployment.
The scale of DICOM’s global deployment is extraordinary. Estimates from the DICOM community put global DICOM image volume in the hundreds of billions of instances, with major health systems running petabyte-scale PACS infrastructures. Cloud DICOM services from Google Cloud Healthcare API, Microsoft Azure Health Data Services, and AWS HealthImaging now offer managed DICOMweb-compliant storage with elastic scaling and millisecond query response for QIDO-RS queries over hundreds of millions of instances. These cloud services make Deep Learning model training over large institutional DICOM corpora tractable without on-premises infrastructure investment, and support Federated Learning architectures where DICOM PACS nodes participate as data enclaves without exporting pixel data.
Components / Architecture
DICOM File Format (PS3.10): Each DICOM file begins with a 128-byte preamble, a 4-byte “DICM” prefix, and a File Meta Information header specifying Transfer Syntax UID, SOP Class UID, and SOP Instance UID. Data elements following use (Group, Element) tag pairs — for example (0010,0010) for Patient Name, (0008,0060) for Modality, (7FE0,0010) for Pixel Data — with an explicit or implicit Value Representation (VR) code and a length field before the value. Standard VRs include CS (Code String), LO (Long String), DS (Decimal String), UI (Unique Identifier), OB/OW (Other Byte/Word for pixel data), and SQ (Sequence of Items for nesting complex attributes). The file format is self-describing: every data element carries its own type information, enabling generic DICOM parsers to read any file without requiring external schema knowledge.
SOP Classes and IODs: A Service-Object Pair (SOP) Class binds an Information Object Definition (IOD — the data model for a modality or document type) to a DICOM Service (C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO, N-ACTION). CT Image Storage (1.2.840.10008.5.1.4.1.1.2), MR Image Storage (1.2.840.10008.5.1.4.1.1.4), Digital X-Ray Image Storage, Nuclear Medicine Image Storage, and the Segmentation Storage SOP Class (1.2.840.10008.5.1.4.1.1.66.4) are among hundreds registered in the standard’s data dictionary. Conformance Statements declare which SOP Classes a device or software supports, forming the contractual basis for DICOM interoperability testing.
Unique Identifier (UID) Hierarchy: Every patient, study, series, and instance receives a globally unique UID allocated from a DICOM-registered organisation root. The Study Instance UID / Series Instance UID / SOP Instance UID triplet is the canonical handle for any DICOM object, enabling cross-site reconciliation, deduplication, and stable reference in HL7 FHIR ImagingStudy resources. Organisation roots are registered with NEMA; cloud PACS providers maintain their own roots for dynamically allocated UIDs.
DIMSE Network Services (PS3.7, PS3.8): DICOM’s traditional network layer uses TCP/IP with an association negotiation phase — Application Entity (AE) titles identify sending and receiving systems, and Presentation Contexts declare the SOP Class UIDs and Transfer Syntaxes supported in that association. C-STORE sends objects; C-FIND queries metadata; C-MOVE and C-GET retrieve objects to specified destinations; C-ECHO verifies connectivity. The Modality Worklist (MWL) service delivers scheduled procedure information from the Radiology Information System (RIS) to the modality before acquisition, pre-populating patient and study demographics on the scanner console.
DICOMweb (PS3.18): The RESTful complement to DIMSE, DICOMweb offers three services: STOW-RS (Store Over the Web — HTTP POST of DICOM objects as multipart/related MIME), QIDO-RS (Query based on ID for DICOM Objects — HTTP GET returning JSON or XML metadata), and WADO-RS (Web Access to DICOM Objects — HTTP GET returning pixel data, rendered thumbnails, or bulk data). DICOMweb eliminates the need for DIMSE TCP association management, making DICOM accessible from browser JavaScript, mobile applications, and cloud microservices without specialised DICOM networking libraries. Modern cloud PACS and vendor-neutral archives (VNA) offer DICOMweb as the primary integration API.
Structured Reporting (SR): DICOM SR encodes clinical observations, quantitative measurements, and SNOMED-CT code-referenced findings in a hierarchical content-tree anchored to image references via DICOM UIDs. Template TID 1500 (Measurement Report) is the standard container for AI model outputs — enabling a Medical Imaging AI system to attach structured measurements, region-of-interest annotations, and coded diagnoses directly to the source DICOM images in a machine-readable, standards-compliant form, archivable in the PACS alongside the original images. TID 1500 is the output format mandated by the DICOM SR AI Output Working Group.
Segmentation IOD (PS3.3, Annex A.51): The Segmentation Storage SOP Class carries pixel-precise binary or fractional probability masks, where each segment is labelled using a SNOMED CT code describing the anatomical structure or pathological finding. It is the canonical container for organ, lesion, or tumour segmentations produced by Deep Learning models, and is supported by the open-source highdicom Python library (Bridge et al., 2022) and the OHIF Viewer v3. The Image Segmentation workflow for clinical AI — model inference → DICOM Segmentation encoding → PACS storage → radiologist review in viewer — is now a complete standards-compliant pipeline.
RT (Radiation Therapy) Objects: RT Plan, RT Structure Set, RT Dose, RT Image, and RT Beams Treatment Record form a complete treatment-planning and delivery record. RT Structure Set carries 3-D contour structures of target volumes and organs-at-risk as DICOM objects, interoperating between treatment-planning systems (Eclipse, RayStation), linear accelerators (TrueBeam, Elekta Versa HD), and oncology information systems (Mosaiq, ARIA) exclusively through DICOM RT exchange. The OpenTPS and plastimatch open-source libraries enable research-level access to RT DICOM objects for Deep Learning-based automated contouring.
Use Cases / Major Families
Radiology PACS Workflows: CT, MRI, and radiograph series flow from the modality console via C-STORE into a PACS archive. Radiologists retrieve series via C-MOVE or WADO-RS into a diagnostic viewer — Sectra IDS7, Philips IntelliSpace, Siemens Syngo.via, OHIF, or 3D Slicer — for reporting. The PACS is the operational heart of every hospital imaging department and is entirely DICOM-native. Cardiology, radiation oncology, and nuclear medicine departments maintain DICOM-native subspecialty archives alongside the main radiology PACS. The global PACS market was valued at over $1.6 billion in 2024 and is entirely predicated on DICOM.
Medical Imaging AI Inference: AI tools receive DICOM series via DICOM-native inference services (deployed as DICOMweb SCPs in the PACS workflow), annotate findings in DICOM SR or Segmentation objects, and store results back to the PACS for radiologist review. Vendors including Aidoc, Viz.ai, Annalise.ai, and Deepc (deployed across six NHS trusts from 2024) deliver algorithms that slot into the DICOM workflow without proprietary formats or viewer integration requirements. The DICOM AI Output Working Group and the RSNA AI challenge benchmarks (RSNA Pneumonia, Intracranial Haemorrhage) use DICOM exclusively.
Telehealth and Remote Reporting: Cloud PACS systems replicate DICOM studies to remote sites using DICOMweb STOW-RS, enabling radiologists to report from home or from specialist centres. NHS diagnostic hubs, the NHS nighthawk out-of-hours reporting programme, and teleradiology vendors (Medica, NightHawk Radiology) all depend on DICOM-native cloud replication. Cross-border teleradiology in the EU is facilitated by DICOM’s vendor-neutral, jurisdiction-agnostic encoding.
Research and AI Training Datasets: The Cancer Imaging Archive (TCIA) curates thousands of DICOM datasets — including RIDER Lung, LIDC-IDRI (6,871 CT scans, ~240,000 nodule annotations), TCGA-LIHC (hepatocellular carcinoma), and CPTAC pathology collections — as the primary public benchmark corpus for Medical Imaging AI development. DICOM metadata (modality, acquisition parameters, body part, institution) enables rich cohort selection without opening pixel data, supporting reproducible benchmark comparisons and meta-analyses.
Digital Pathology and Whole Slide Imaging: DICOM Supplement 145 (Whole Slide Imaging) defines the WSI IOD for multi-resolution pyramid tile storage with JPEG, JPEG 2000, or JPEG-XL compression. The DICOM Digital Pathology Working Group (WG26) collected multi-vendor WSI samples from 2020 to 2025 to validate interoperability, reaching production-readiness. Philips in 2025 announced native DICOM JPEG-XL output scanners — the first production scanner to output DICOM WSI natively. The Microsoft Azure Health Data Services DICOM service includes WSI pathology support. DICOM WSI is increasingly required for NHS Digital Pathology transformation programmes under NHS England mandate.
Radiation Oncology: RT Plan and RT Structure Set objects integrate with treatment-planning systems, linear accelerators, and oncology information systems exclusively through DICOM RT exchange. Deep Learning-based automated organ contouring (autosegmentation) workflows save DICOM RT Structure Sets back to the treatment-planning system via C-STORE, closing the AI-to-clinical-workflow loop without format conversion.
Drug Discovery and Clinical Trials: Regulatory submissions to the FDA and EMA increasingly require standardised DICOM imaging data as part of the digital evidence package for new drug applications. Clinical trial imaging core labs (ICON, Medidata, BioClinica) use DICOM as the canonical format for centralised imaging review, quantitative tumour burden assessment (RECIST criteria), and audit trail.
Academic Context
The foundational 1992 paper by Bidgood and Horii (RadioGraphics) established the object-oriented architecture of DICOM and remains the canonical introduction. The 2023 PMC review “Thirty Years of the DICOM Standard” (Bidgood et al., PMC10610864) traces governance, adoption, and technical evolution across three decades. Clunie’s DICOM Structured Reporting (2000, PixelMed Publishing) is the authoritative implementation reference for SR. The LIDC-IDRI dataset (Armato et al., Medical Physics, 2011) — distributed entirely as DICOM — is the most cited lung nodule benchmark, having enabled hundreds of Computer Vision and Convolutional Neural Network evaluation studies. Bridge et al. (2022, Journal of Digital Imaging) introduced highdicom, the Python library enabling standards-compliant encoding of Image Segmentation, Parametric Maps, and Structured Reports — essential infrastructure for DICOM-native Medical Imaging AI pipelines. The December 2024 arXiv preprint “Toward AI-Ready Medical Imaging Data” (arXiv:2512.03541) identifies DICOM metadata standardisation, cohort curation tooling, and de-identification pipeline reproducibility as the three critical prerequisites for safe clinical AI deployment.
Formal ontological treatment of DICOM appears in the DICOM Ontology (DCM) code system integrated into SNOMED CT and referenced in HL7 FHIR Observation resources. The FHIR ImagingStudy and ImagingSelection (R5) resources provide the bridge between DICOM UIDs and FHIR clinical contexts, enabling unified queries across imaging and clinical data in Electronic Health Record systems. The RSNA Imaging AI Certificate programme and MICCAI (Medical Image Computing and Computer-Assisted Intervention) Society both centre their benchmarks and educational materials on DICOM as the canonical data format.
Current Landscape (2026)
DICOM PS3 2025c is the latest published version, extending AI annotation support through the DICOM SR TID 1500 Measurement Report template and adding DICOMweb profile compliance declarations. ISO 12052:2026 brings the standard’s ISO codification up to date with workflow and data management extensions. The NHS mandates DICOM through its Standards Directory (active status) and the NHS Shared Business Services AI, Imaging and Radiotherapy Framework (SBS10034). Six NHS trusts — including Imperial College Healthcare NHS Trust, King’s College Hospital, Guy’s and St Thomas’, Lewisham and Greenwich, University Hospitals Sussex, and East Kent Hospitals — commenced deployment of Deepc’s DeepcOS platform (covering 75+ AI tools) in 2024. The Royal College of Radiologists’ November 2024 guidance (AI Deployment Fundamentals for Medical Imaging) sets minimum standards including DICOM SR output conformance for all AI tools deployed in NHS radiology. England’s 10-Year Health Plan commits to nationwide AI algorithm rollout from 2027 underpinned by the DICOM/PACS infrastructure already in place. Google Cloud Healthcare API, Microsoft Azure Health Data Services, and AWS HealthImaging all provide managed DICOMweb-compliant cloud storage. In digital pathology, the DICOM WG26 interoperability validation programme reached production-readiness in 2025, and NVIDIA FLARE’s federated learning framework now supports direct DICOM PACS federation without data movement.
UK Context
NHS Standards Mandate: DICOM is listed as an “active” standard in the NHS Standards Directory, mandating its use across NHS imaging trusts in England, Wales, Scotland, and Northern Ireland. The NHS Shared Business Services SBS10034 framework (2021–2025) simplified procurement of DICOM-compatible AI and imaging equipment under a single compliance umbrella, covering cloud-ready AI products and imaging modalities. NHS England’s Digital Diagnostics programme requires DICOM conformance as a baseline for all new imaging equipment and AI software procured under NHS frameworks.
NHS AI Deployment: Six NHS trusts commenced deployment of DICOM-native AI platforms in 2024. The NHS nighthawk out-of-hours programme and NHS diagnostic hub model both rely on DICOM-native teleradiology over cloud PACS. The Royal College of Radiologists’ November 2024 guidance (AI Deployment Fundamentals for Medical Imaging) mandates DICOM SR as the output format for all AI tools, replacing proprietary overlay and PDF outputs.
Academic Centres: Imperial College London’s BioMedIA group (Department of Computing) produced foundational Deep Learning results on DICOM cardiac MRI segmentation benchmarks. University College London’s Centre for Medical Image Computing (CMIC) develops DICOM-native registration, segmentation, and Annotation tools. The University of Edinburgh’s Medical School and University of Manchester’s clinical imaging groups are active TCIA data contributors. Oxford’s Computational Health Informatics Lab and Cambridge’s Department of Radiology participate in NHS AI evaluation. The Alan Turing Institute’s Healthcare and AI working group actively engages with DICOM data infrastructure for multi-site Federated Learning research.
Northern Industrial Context: Leeds Teaching Hospitals NHS Trust operates one of the largest NHS digital pathology programmes in England, deploying DICOM WSI at scale. The West Yorkshire Imaging Collaborative uses a shared cloud PACS serving multiple trusts across the Yorkshire and Humber region over DICOMweb. Sheffield Teaching Hospitals and Newcastle Hospitals both participate in NHS AI evaluation through the Yorkshire and Humber Imaging Network. Manchester University NHS Foundation Trust (MFT), the largest NHS trust in England, is a major DICOM PACS deployment site running one of the UK’s largest radiology imaging archives.
Future Directions (2026–2030)
AI Annotation Standardisation: DICOM SR TID 1500 and the Segmentation IOD will become mandatory output formats for AI Clinical Decision Support tools, replacing proprietary JSON overlays and PDF reports. DICOM AI Output Working Group outputs will define standardised templates for specific clinical tasks (stroke detection, lung nodule characterisation, fracture detection), enabling cross-vendor comparison and automated audit.
DICOMweb Native Cloud: All major PACS vendors are migrating from DIMSE socket connections to DICOMweb-native deployments on public cloud infrastructure, enabling elastic scaling, browser-native viewers, and mobile radiology without on-premises DIMSE servers. Cloud-native VNA platforms from NovaTek, Intelerad, Sectra, and Ambra (now Intelerad) are already predominantly DICOMweb-native.
DICOM for Multimodal Foundation Models: Combining DICOM images with FHIR clinical context in Natural Language Processing and computer vision foundation models (Med-Gemini, BioViL-T, CheXagent) will require standardised DICOM-to-FHIR linkage at inference time, driving tighter integration between DICOM UIDs and FHIR ImagingStudy/ImagingSelection resources. DICOM metadata will serve as the retrieval key for multimodal RAG systems querying clinical imaging corpora.
Federated Learning Infrastructure: DICOM PACS nodes will become the primary data enclave endpoints for federated learning consortia such as NVIDIA FLARE federated radiology networks and the UK Biobank Imaging Genetics study. The DICOM metadata catalogue — queryable via QIDO-RS without pixel access — will serve as the cohort-selection and stratification layer, enabling privacy-preserving federated model training across NHS trusts without any centralised data movement.
Digital Pathology at Scale: DICOM WSI will supplant proprietary scanner formats (SVS/NDPI/MRXS) across NHS Digital Pathology programmes, enabled by mandates and ISO 12052:2026. JPEG-XL compression will reduce WSI file sizes dramatically (3–5× over JPEG 2000), enabling cloud-native pathology Medical Imaging AI workflows without the bandwidth constraints that previously blocked cloud pathology adoption.
Quantum-Safe DICOM: NIST post-quantum cryptographic standards (CRYSTALS-Kyber for key encapsulation, CRYSTALS-Dilithium for signatures) will be incorporated into DICOM TLS and object-signing profiles, future-proofing PACS communications and image provenance against quantum adversaries targeting hospital infrastructure.
Formal DICOM Data Model: The Study-Series-Instance Hierarchy
The DICOM data model is a four-tier hierarchy that encodes the real-world structure of a clinical imaging encounter at a level of precision sufficient for safe clinical use, federated research, and automated AI processing. Understanding this hierarchy precisely is prerequisite for Medical Imaging AI pipeline design and Dataset curation.
Patient level: The root of the hierarchy. A Patient is identified by Patient ID (tag 0010,0020), Patient Name (0010,0010), Patient Birth Date (0010,0030), and Patient Sex (0010,0040). In a single-institution PACS, Patient ID is typically the hospital’s Medical Record Number (MRN). Cross-institutional patient matching — essential for longitudinal research and federated learning — requires probabilistic record linkage because Patient IDs are institution-specific and Patient Names may be inconsistently formatted. The EMPI (Enterprise Master Patient Index) is the institutional infrastructure that resolves this, while the FHIR Patient resource provides the portable identifier framework. DICOM de-identification replaces Patient Name and Patient ID with pseudonymous research IDs while retaining the longitudinal linkage structure.
Study level: A Study corresponds to a single clinical imaging encounter — a patient visit that produces one or more imaging series. Study-level identifiers include Study Instance UID (0020,000D — globally unique), Study Date (0008,0020), Study Time (0008,0030), Accession Number (0008,0050 — the radiology department’s unique order identifier, linking to the RIS), Study Description (0008,1030), and Referring Physician Name. The Accession Number is the key for linking DICOM studies to HL7 FHIR ServiceRequest, DiagnosticReport, and ImagingStudy resources. A study may contain one or more series corresponding to different imaging sequences, reconstructions, or modalities performed in the same encounter.
Series level: A Series corresponds to a coherent imaging acquisition — for CT, typically one contrast phase or one reconstruction kernel applied to the full volume; for MRI, one pulse sequence. Series-level identifiers include Series Instance UID (0020,000E), Series Number (0020,0011), Modality (0008,0060 — CT, MR, US, PT, NM, DX, MG, OPT, WSI, etc.), Series Description (0008,103E), Body Part Examined (0018,0015), and Laterality (0020,0060). For Deep Learning Medical Imaging AI, the Series is typically the unit of input: a CT series is a 3D volume, an MRI series is a 3D or 4D tensor, an ultrasound series is a cine clip. Series metadata drives cohort selection in research: “all contrast-enhanced CT portal venous phase series of the abdomen” is a precisely specified query over Series-level DICOM metadata.
Instance level (SOP Instance): A SOP Instance is a single DICOM object — one CT slice, one MRI volume (if 3D), one ultrasound frame, one SR report, one Segmentation object. Instance-level identifiers include SOP Instance UID (0008,0018 — the globally unique identifier for this specific object), SOP Class UID (0008,0016 — identifying the type of object), Instance Number (0020,0013), and Acquisition DateTime (0008,002A). For 2D modalities (CT, MR with 2D acquisition, digital radiography), each slice is a separate SOP Instance within the series; for true 3D modalities (volumetric MR sequences), a single SOP Instance may contain the entire 3D volume in a multi-frame object (using the Enhanced MR Image Storage SOP Class).
The UID system in practice: DICOM UIDs are ISO Object Identifiers (OIDs) in dotted decimal notation, structured as <organisation root>.<local component>. Organisation roots are registered with NEMA or allocated from the ISO arc. Cloud PACS services (Google, Azure, AWS) maintain their own roots for UIDs they generate. The UID system guarantees global uniqueness without central coordination — a property essential for multi-institution data exchange. However, UID management in research workflows (de-identification replacing original UIDs with research-specific UIDs while maintaining internal consistency) is a common source of data integrity errors in DICOM curation pipelines.
The DICOM metadata-AI workflow interface: The metadata hierarchy enables a key pattern in Medical Imaging AI deployment: cohort-first, pixel-second. Given a research or clinical question (e.g., “identify all CE-CT studies of the liver from patients diagnosed with hepatocellular carcinoma between 2018 and 2024”), the DICOM metadata enables cohort selection via QIDO-RS queries without downloading pixel data. Only the relevant series are then retrieved (WADO-RS) for model input. This pattern reduces bandwidth and storage requirements by orders of magnitude compared to bulk download approaches, and enables adaptive sampling strategies during Dataset curation and model evaluation.
DICOM Ecosystem: Tooling, Libraries, and Open Standards
The open-source DICOM tooling ecosystem is rich and mature, enabling implementers, researchers, and clinical AI developers to build on standardised infrastructure without proprietary dependency.
pydicom: The canonical Python DICOM parsing library. pydicom.dcmread() loads a DICOM file into a Dataset object where elements are accessible by tag or keyword. Transfer syntax detection, pixel data decoding (with pydicom.pixel_array), and dataset manipulation are all provided. De-identification workflows typically chain pydicom with the DICOM confidentiality profile definitions from PS3.15. Version 2.x supports streaming large datasets and multiframe pixel data handling.
SimpleITK and ITK: The Insight Segmentation and Registration Toolkit (ITK) and its Python wrapper SimpleITK provide the standard toolkit for DICOM volume I/O, registration, Image Segmentation, and quantitative analysis in medical imaging research. SimpleITK’s ImageSeriesReader reconstructs 3D volumes from DICOM series by sorting by Image Position (Patient) and Slice Location attributes. ITK is the computational backbone of most DICOM-native Deep Learning preprocessing pipelines for CT and MRI.
MONAI (Medical Open Network for AI): NVIDIA’s MONAI framework provides DICOM-native data loading, augmentation, and model training infrastructure specifically designed for medical imaging Deep Learning. MONAI’s LoadImage transform reads DICOM series and applies DICOM-specific normalisation (Hounsfield Unit windowing, voxel spacing normalisation). MONAI Label integrates active learning for DICOM-native annotation workflows, and MONAI Deploy streams DICOM inference results as DICOM SR or Segmentation objects back to the PACS.
highdicom: The Python library for encoding DICOM SR, Segmentation, Parametric Map, and other derived DICOM objects. Provides high-level Python classes (e.g., highdicom.seg.Segmentation, highdicom.sr.MeasurementReport) that abstract the complex encoding rules, enabling Medical Imaging AI models to produce standards-compliant DICOM output without deep expertise in PS3.3. Developed by Christopher Bridge at Massachusetts General Hospital and widely adopted in the TCIA community.
OHIF Viewer: The Open Health Imaging Foundation (OHIF) Viewer is the leading open-source browser-based DICOM viewer, built on DICOMweb for image retrieval and the Cornerstone.js library for rendering. OHIF supports DICOM SR display (structured report viewer), Segmentation overlay rendering, and is the standard research PACS viewer for TCIA datasets. The OHIF Viewer is deployed in cloud PACS integrations and as the default viewer in Google Cloud Healthcare API DICOM store web previews.
dcm4che: The most complete open-source Java DICOM toolkit, implementing both DIMSE and DICOMweb services. dcm4chee is the associated open-source PACS server, capable of serving as a full production PACS for research institutions. The dcm4che WADO-RS/STOW-RS/QIDO-RS server is used as the reference implementation for DICOMweb conformance testing.
3D Slicer: The leading open-source medical image analysis platform, providing DICOM import/export, 3D visualisation, segmentation tools, and a plugin ecosystem for radiomics, registration, and Deep Learning inference. The SlicerDicom plugin and DICOM database in 3D Slicer support the full Study/Series/Instance hierarchy, enabling research workflows from DICOM import through quantitative analysis to DICOM Segmentation and SR export.
TCIA and IDC (Imaging Data Commons): The Cancer Imaging Archive (TCIA) and its cloud successor, NCI Imaging Data Commons (IDC), provide petabyte-scale DICOM dataset infrastructure. IDC hosts TCIA collections on Google Cloud Storage as DICOM objects queryable via DICOMweb and BigQuery DICOM metadata tables, enabling large-scale Dataset analysis without local download. This architecture — cloud-native DICOM + SQL metadata + DICOMweb retrieval — is the emerging model for research data infrastructure.
DICOM Conformance Testing: The NIST DVTK (DICOM Validation ToolKit) and IHE Connectathon events provide formal conformance testing infrastructure. IHE (Integrating the Healthcare Enterprise) defines implementation profiles — Scheduled Workflow (SWF), Radiology Information Reconciliation (RIR), Cross-Enterprise Document Sharing for Imaging (XDS-I) — that combine DICOM and HL7 FHIR services into tested, deployable workflow patterns. NHS England’s PACS procurement framework requires IHE profile conformance as a condition of contract.
DICOM in Multi-Modal AI and Foundation Models
The emergence of medical foundation models — large pre-trained models adapted for clinical imaging — is creating new demands on DICOM infrastructure and opening new research directions.
DICOM as Foundation Model Training Corpus: The largest publicly available medical imaging foundation model training corpora are DICOM-native. CheXpert (224,316 chest radiographs), MIMIC-CXR (227,827 radiograph studies), UK Biobank Imaging (100,000+ participants, 5+ imaging modalities), and NIH ChestX-ray14 (112,120 frontal CXR images) are all DICOM collections or derived from DICOM sources. The metadata richness of DICOM — study date, acquisition parameters, institution, referring department — provides structured context for self-supervised pre-training approaches where report text is aligned with DICOM image content.
Multimodal DICOM + FHIR Foundation Models: Next-generation medical AI architectures (Med-Gemini, BioViL-T, LLaVA-Med, CheXagent) combine DICOM image inputs with text report inputs and structured clinical data from Electronic Health Record systems. DICOM UIDs are the linking mechanism between the imaging modality and the clinical context modality: the Study Instance UID links the DICOM series to the FHIR DiagnosticReport, which links to the FHIR Observation resources encoding laboratory results, and to the FHIR Condition resources encoding diagnoses. Constructing multi-modal training examples requires traversing this DICOM↔HL7 FHIR linkage at scale, which in turn requires DICOM metadata catalogues (QIDO-RS queryable) and FHIR servers with ImagingStudy resources containing the DICOM UIDs.
DICOM and Vision-Language Models: Vision-Language Models (VLMs) trained on medical imaging data (CLIP-based medical variants, PathClip for pathology, RETFound for retinal imaging) encode DICOM images into joint visual-textual embedding spaces, enabling zero-shot or few-shot classification, report generation, and visual question answering. The DICOM image pre-processing pipeline — Hounsfield Unit windowing, pixel spacing normalisation, DICOM orientation correction, de-identification — is a critical upstream step whose correctness directly affects VLM performance. Errors in DICOM pre-processing (e.g., incorrect windowing level producing under-exposed images, or failing to apply DICOM Modality LUT before pixel normalisation) produce training examples that are incorrectly labelled with the DICOM metadata, silently degrading model quality.
Pathology Foundation Models and DICOM WSI: Foundation models for computational pathology (UNI, CONCH, PLIP, Phikon) are trained on gigapixel whole-slide images. The transition from proprietary scanner formats (SVS, NDPI, MRXS) to DICOM WSI for foundation model training corpora is a current research priority, driven by the need for standardised metadata (scanner manufacturer, magnification, stain type via SNOMED CT codes) alongside pixel data. DICOM WSI tile-based retrieval via WADO-RS enables on-demand tile loading without materialising entire gigapixel images, making distributed foundation model training over DICOM WSI archives technically tractable.
DICOM as Inference Context for RAG-augmented Clinical AI: Retrieval-Augmented Generation approaches applied to clinical imaging combine DICOM image embeddings with retrieved clinical knowledge (previous reports, clinical guidelines, similar case findings) to generate diagnostic reports or answer clinical questions. In this architecture, DICOM metadata (Modality, Body Part, Study Description) serves as structured query metadata enabling precise retrieval of relevant prior cases from a PACS-indexed case base. The DICOM-native retrieval pipeline — QIDO-RS metadata query → WADO-RS pixel retrieval → embedding → nearest-neighbour case retrieval — requires the full DICOM stack as infrastructure.
DICOM in the AI Regulatory Landscape
The deployment of Medical Imaging AI algorithms as Software as a Medical Device (SaMD) is regulated in the UK (MHRA), EU (MDR/IVDR), and USA (FDA). DICOM plays a specific and growing role in this regulatory context.
MHRA (UK) and Software as a Medical Device: The MHRA’s Medical Device Regulations 2002 (as amended post-Brexit) classify most Medical Imaging AI diagnostic tools as Class IIa or Class IIb SaMD. Predicate device comparisons and clinical investigation designs typically specify input data format (DICOM series with defined acquisition parameters), preventing manufacturers from cherry-picking favourable image quality. The Royal College of Radiologists’ 2024 guidance mandates DICOM SR or Segmentation output as a condition for AI tool deployment in NHS radiology, creating a de facto regulatory expectation aligned with DICOM standards.
FDA Guidance on AI/ML-Based SaMD: The FDA’s 2021 action plan for AI/ML-based SaMD and 2023 discussion paper on predetermined change control plans reference DICOM-standardised input specifications as a mechanism for scoping the intended use population. A Medical Imaging AI tool specified for “contrast-enhanced CT series acquired per protocol X” has a more clearly defined input distribution than one specified for “CT images” — and DICOM metadata (contrast agent sequence, acquisition parameters) makes that specification machine-verifiable.
EU AI Act and High-Risk AI: The EU AI Act (fully applicable from August 2026) classifies AI systems used as Medical Imaging diagnostic tools as high-risk. High-risk AI systems require technical documentation including dataset curation methodology, model performance metrics across demographic subgroups, and post-market monitoring plans. DICOM metadata-driven cohort analysis is the standard tool for demonstrating dataset representativeness and monitoring performance drift across demographic and institutional subgroups.
Post-Market Surveillance: DICOM audit trails — study timestamps, acquisition parameters, AI output SOP Instance UIDs, and link between source image and SR output — provide the data infrastructure for post-market surveillance. Automated performance monitoring comparing AI DICOM SR outputs to radiologist corrections (tracked via DICOM amendments and structured report versioning) enables continuous safety monitoring without manual data extraction. The NHS AI and Digital Regulations Service (AIDRS) evaluation framework expects this infrastructure.
Research & Literature
- ACR-NEMA Committee (1985). Digital Imaging and Communications Standard Version 1.0. NEMA.
- ACR-NEMA Committee (1988). Digital Imaging and Communications Standard Version 2.0. NEMA.
- Bidgood, W.D., & Horii, S.C. (1992). Introduction to the ACR-NEMA DICOM Standard. RadioGraphics, 12(2), 345–355.
- DICOM Standards Committee (1993). DICOM PS3 Parts 1–9. NEMA.
- DICOM Standards Committee (2025). DICOM PS3 2025c. NEMA. https://dicom.nema.org/medical/dicom/current/
- ISO/CEN (2026). SIST EN ISO 12052:2026 — Health informatics: DICOM including workflow and data management. ISO/CEN. https://standards.iteh.ai/catalog/standards/sist/cca22e11-6400-4b27-b957-8cf5b6888fcc/sist-en-iso-12052-2026
- Armato, S.G., et al. (2011). The Lung Image Database Consortium (LIDC) and Image Database Resource Initiative (IDRI). Medical Physics, 38(2), 915–931.
- Clark, K., et al. (2013). The Cancer Imaging Archive (TCIA). Journal of Digital Imaging, 26(6), 1045–1057.
- Bridge, C.P., et al. (2022). Highdicom: A Python Library for Standardized Encoding of Image Annotations and Machine Learning Model Outputs. Journal of Digital Imaging, 35(6), 1719–1737. https://arxiv.org/abs/2106.07806
- Bidgood, W.D., et al. (2023). Thirty Years of the DICOM Standard. PMC review, PMC10610864. https://pmc.ncbi.nlm.nih.gov/articles/PMC10610864/
- Bhaskaran, A., et al. (2024). Toward AI-Ready Medical Imaging Data. arXiv:2512.03541.
- NHS Digital (2024). Digital Imaging and Communications in Medicine — NHS Standards Directory. https://standards.nhs.uk/published-standards/digital-imaging-and-communications-in-medicine
- Royal College of Radiologists (November 2024). AI Deployment Fundamentals for Medical Imaging. https://www.rcr.ac.uk/media/sbdhwnfl/ai-deployment-fundamentals-for-medical-imaging-2024.pdf
- Digital Health (October 2024). Partnership aims to accelerate NHS adoption of radiology AI. https://www.digitalhealth.net/2024/10/partnership-aims-to-accelerate-nhs-adoption-of-radiology-ai/
- HL7 International (2023). FHIR R5 ImagingStudy Resource. https://hl7.org/fhir/imagingstudy.html
- Healthcare IT News (2024). NHS to roll out radiology AI across 10 health trusts. https://www.healthcareitnews.com/news/nhs-roll-out-radiology-ai-across-10-health-trusts
- Clunie, D.A. (2000). DICOM Structured Reporting. PixelMed Publishing.
- Mainecoon Project (2025). Open-Source Web Viewer for DICOM Whole Slide Images with AI-Integrated PACS. J Imaging Informatics in Medicine. https://link.springer.com/article/10.1007/s10278-025-01425-6
- Philips (2025). Digital pathology scanner with native configurable DICOM JPEG-XL output. https://www.philips.com/a-w/about/news/archive/standard/news/articles/2025/philips-announces-digital-pathology-scanner-with-native-configurable-dicom-jpeg-and-jpeg-xl-output-in-world-first.html
- Meditecs (2026). Interoperable Digital Pathology in 2026: DICOM, AI and Adoption. https://www.meditecs.com/interoperable-digital-pathology-how-to-enable-in-2026/
- AZMed (2025). England 10-Year Health Plan: Radiology AI and Diagnostic Imaging. https://www.azmed.co/news-post/england-10-year-health-plan-and-ai-in-radiology
- Google Cloud (2024). DICOM Conformance Statement — Cloud Healthcare API. https://docs.cloud.google.com/healthcare-api/docs/dicom
- Microsoft Azure (2024). Digital pathology in the DICOM service in Azure Health Data Services. https://learn.microsoft.com/en-us/azure/healthcare-apis/dicom/dicom-digital-pathology
- DICOM Standards Committee WG26 (2024). DICOM Whole Slide Imaging interoperability validation dataset. https://dicom.nema.org/dicom/dicomwsi/
- NHS SBS (2021). SBS10034 — AI, Imaging and Radiotherapy Equipment Framework. NHS Shared Business Services.
- Bernard, O., et al. (2018). Deep Learning Techniques for Automatic MRI Cardiac Multi-Structures Segmentation and Diagnosis. IEEE Transactions on Medical Imaging, 37(11). [DICOM cardiac MRI benchmark]
- Criminisi, A., & Shotton, J. (Eds.) (2013). Decision Forests for Computer Vision and Medical Image Analysis. Springer. [landmark DICOM-grounded training data methodology]
- HL7.org.vn (2024). DICOM — medical imaging standard and FHIR ImagingStudy. https://hl7.org.vn/en/knowledge/dicom/
DICOM and Artificial Intelligence: A Deep Integration
The relationship between DICOM and Medical Imaging AI is not superficial — DICOM is the architectural substrate on which the entire clinical AI pipeline is constructed, from Dataset curation through model training to inference deployment and clinical audit. Understanding this relationship at a technical level is essential for building reliable AI systems in healthcare.
Training data curation: All public medical imaging benchmarks — LIDC-IDRI, BraTS, CHAOS, RSNA Pneumonia Detection, NIH ChestX-ray14, MIMIC-CXR — are distributed as DICOM collections. DICOM metadata enables precise cohort selection using structured queries over patient demographics (age, sex), acquisition parameters (slice thickness, reconstruction kernel, kVp), and clinical context (study description, referring physician department) without downloading pixel data. The TCIA ITKC tool, the highdicom Python library, and DICOMweb QIDO-RS queries are the standard toolkit for metadata-driven Dataset curation. Cohort selection errors (including mismatched laterality, protocol mixing, or de-identification failures) are among the most common sources of bias in medical imaging models, making DICOM metadata hygiene a safety-critical concern.
Model input standardisation: A Convolutional Neural Network or Transformer Architecture vision model consuming CT images must handle DICOM-specific pre-processing steps invisible in natural image computer vision: Hounsfield Unit (HU) windowing (mapping the full HU range, typically -1024 to +3071, to a display window appropriate for the tissue of interest — lung window [-1000, +200], soft tissue [-150, +250], bone [+400, +1800]); handling of multi-frame DICOM objects (4D CT, dynamic MRI, cine cardiac); correct interpretation of pixel spacing and slice thickness for voxel-based operations; and handling of pixel data encoding (12-bit values stored in 16-bit words, potentially with a photometric interpretation of MONOCHROME1 vs MONOCHROME2 requiring intensity inversion). Libraries like pydicom, SimpleITK, and MONAI (Medical Open Network for AI) abstract DICOM loading but require careful handling of these domain-specific edge cases. Transfer Learning from natural image Deep Learning models to medical imaging requires awareness that DICOM-sourced images differ fundamentally from RGB natural images in dimensionality, bit depth, and intensity semantics.
Inference output standardisation: The DICOM SR TID 1500 template is the standards body-sanctioned format for AI inference outputs. A compliant AI tool produces a DICOM SR object containing: (1) the SOP Instance UID of the source image(s); (2) the algorithm name, version, and model identifier in the Referenced Performing Device Sequence; (3) quantitative measurements as Numeric Measurement Observation items with SNOMED-CT coded finding sites; (4) qualitative findings as Coded Observation items; and (5) image references with optional coordinates (POINT, POLYLINE, CIRCLE, ELLIPSE) for spatial localisation. When the output is a pixel-level segmentation, the DICOM Segmentation IOD is used instead, storing binary or fractional masks with SNOMED-CT segment labels. Both formats are stored back to the PACS via C-STORE or STOW-RS, making them first-class DICOM objects viewable in any SR-capable viewer, auditable, and persistently linked to the source images.
Federated learning over DICOM PACS: Federated Learning frameworks operating over clinical imaging data use DICOM PACS nodes as data enclaves. The NVIDIA FLARE framework enables federated training where: (1) a central server distributes a model architecture; (2) each PACS node’s local training loop uses DICOMweb QIDO-RS to query a local cohort of studies, then WADO-RS to retrieve pixel data on demand without full materialisation; (3) model weight gradients (not pixel data) are communicated back to the central server. The DICOM metadata catalogue at each site serves as the federated cohort-selection and stratification layer — patients are selected by DICOM metadata filters without exposing clinical notes or PHI to the central orchestrator. This architecture is being deployed in UK consortia (the NHS AI Lab’s PANDA network, the Leeds-Manchester-Sheffield federated imaging network) for multi-site model development without data movement.
DICOM Standard Structure: The PS3 Parts
DICOM is organised as 20 interconnected but independently usable parts (NEMA PS3.1 through PS3.20), each addressing a specific layer of the standard. Understanding this modular structure is essential for implementers and for appreciating how the standard has evolved without breaking backward compatibility.
PS3.1 — Introduction and Overview: Defines scope, normative references, and the organisation of the remaining parts. Sets out the fundamental DICOM model of the real world — patient, study, series, image — that all other parts reference.
PS3.2 — Conformance: Defines the structure of the Conformance Statement that every DICOM implementation must publish. A Conformance Statement specifies which SOP Classes are supported as SCU (Service Class User — requestor) or SCP (Service Class Provider — responder), which Transfer Syntaxes are supported for each, and which optional attributes are included.
PS3.3 — Information Object Definitions: The data model part. Defines all IODs (CT Image, MR Image, Digital Mammography, Segmentation, RT Plan, Whole Slide Image, etc.) and the modules and attributes they contain. PS3.3 is the authoritative reference for what data any given DICOM object type carries.
PS3.4 — Service Class Specifications: Defines what the DICOM services (C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO, Modality Worklist, etc.) do semantically and what behaviour SCUs and SCPs must exhibit. Specifies status codes for success and failure responses.
PS3.5 — Data Structures and Encoding: Defines the tag-VR-length-value encoding of DICOM data elements and the encoding rules for Transfer Syntaxes. The foundation of DICOM file parsing.
PS3.6 — Data Dictionary: The normative registry of all DICOM attribute tags (Group, Element pairs), their VRs, names, keywords, multiplicity, and the SOP Classes that use them. PS3.6 is machine-readable and is the source for auto-generating DICOM parsers.
PS3.7 — Message Exchange: Defines the DIMSE protocol — the structure of request and response primitives for each DIMSE service (C-STORE-RQ, C-FIND-RSP, etc.) at the message level.
PS3.8 — Network Communication Support for Message Exchange: Defines how DIMSE messages are carried over TCP/IP: the Upper Layer Protocol (ULP) for association establishment, release, and abort; Presentation Context negotiation; and the PDU (Protocol Data Unit) structure.
PS3.10 — Media Storage and File Format: Defines the DICOM file format — preamble, DICM prefix, File Meta Information, and the encoded data set. The basis for DICOM files stored on media (CDs, DVDs, SD cards, PACS disk).
PS3.11 — Media Storage Application Profiles: Defines which SOP Classes and Transfer Syntaxes must be supported for specific media interchange use cases (STD-GEN-USB, STD-GEN-DVD, etc.). Relevant for cross-site image exchange on physical media.
PS3.14 — Grayscale Standard Display Function (GSDF): The psychophysical calibration standard for medical display monitors. Ensures that the same pixel values produce perceptually consistent image appearance across calibrated displays. Critical for radiological reading rooms where diagnostic accuracy depends on display consistency.
PS3.15 — Security and System Management Profiles: TLS transport profiles, de-identification profiles (Confidentiality Profiles), digital signature profiles, and media security profiles. The normative reference for DICOM Privacy and Security compliance.
PS3.16 — Content Mapping Resource: Defines coded terminology context groups — mappings from DICOM code value/scheme designator/code meaning to standardised controlled vocabularies (SNOMED-CT, ICD-10, UCUM, RadLex, LOINC). The basis for interoperable semantic annotations in DICOM SR and Segmentation objects.
PS3.17 — Explanatory Information: Non-normative annexes providing explanatory material, use case narratives, and example implementations that clarify normative requirements in other parts.
PS3.18 — Web Services: DICOMweb — STOW-RS, QIDO-RS, WADO-RS, and the Rendered Resources. The normative specification for RESTful DICOM exchange over HTTP/HTTPS using JSON and multipart MIME. The fastest-growing part of the standard as cloud PACS adoption accelerates.
PS3.19 — Application Hosting: Defines the plug-in API enabling third-party applications (AI tools, post-processing algorithms) to access DICOM data within a host application (viewer, PACS) without direct DICOM protocol implementation.
PS3.20 — Transformation of DICOM to and from HL7 Standards: Defines mappings between DICOM data elements and HL7 FHIR ImagingStudy and HL7 v2 ORM/ORU messages. The normative bridge between the DICOM imaging world and the Electronic Health Record clinical data world.
This modular architecture has allowed DICOM to evolve continuously since 1993 — adding new SOP Classes, extending DICOMweb, and incorporating AI annotation templates — without breaking the backward compatibility of existing implementations that implement only a subset of parts.
DICOM Security and Privacy Architecture
Patient privacy is structurally embedded in DICOM. The standard defines Confidentiality Profiles (PS3.15, Annex E) specifying which attributes must be retained, zeroed, replaced with dummy values, or hashed for each de-identification use case: Basic Application Level Confidentiality (removes patient name, ID, birth date, address), Clean Pixel Data Option (detects and removes burned-in annotations), Retain Device Identity Option (keeps acquisition device UIDs for equipment comparison studies), and Longitudinal Consistency Option (consistently replaces UIDs to maintain longitudinal cohort linkage). These profiles are the standard reference for Data Protection compliance in DICOM-based research.
DICOM Transport Layer Security is defined in PS3.15 Part 8: TLS 1.2/1.3 with mutual certificate authentication is the mandated transport for production DICOM associations over untrusted networks. DICOMweb extends this via standard HTTPS with OAuth 2.0 / SMART on FHIR authentication tokens, enabling single-sign-on integration with hospital identity providers. NHS Digital Security and Protection Toolkit (DSPT) requirements mandate encrypted transport and access logging for all DICOM systems handling patient data, with Data Governance audits conducted annually.
DICOM and Federated Learning: Technical Architecture
Federated Learning over clinical imaging data is one of the most promising approaches to building large-scale Medical Imaging AI models without the privacy risks of data centralisation. DICOM infrastructure — specifically PACS and DICOMweb — is the natural substrate for federated imaging networks, and understanding this architecture precisely is essential for researchers and system builders.
The DICOM PACS as a Federated Node: Each NHS trust or hospital has a PACS containing millions to hundreds of millions of DICOM studies. In a federated learning network, each PACS serves as a data node. The local training loop at each node: (1) uses DICOMweb QIDO-RS to query the local PACS for studies matching the cohort specification (modality = CT, body part = chest, study date range, protocol name); (2) retrieves matching series on demand via WADO-RS (pixel data remains local, never exported); (3) pre-processes DICOM pixel data including HU windowing, slice spacing normalisation, and array formatting; (4) runs the local model update; (5) sends weight gradients (not pixel data) to the central aggregator. The DICOM metadata catalogue at each PACS node serves as the privacy-preserving cohort specification layer — the federated orchestrator specifies cohorts in DICOM metadata terms without requiring local data disclosure.
DICOM De-identification in Federated Research: Even in fully federated architectures where pixel data never leaves the node, DICOM metadata must be carefully managed. Study-level metadata (institution name, equipment manufacturer, acquisition parameters) must be shared with the federated orchestrator for stratified cohort selection and performance monitoring. De-identification of the shared metadata subset — replacing institution names with site IDs, hashing acquisition parameters — is required for Privacy compliance under GDPR and NHS Data Protection standards. The DICOM PS3.15 de-identification profiles provide the normative framework for what must be suppressed.
Differential Privacy over DICOM Corpora: Formal Privacy guarantees for federated learning over DICOM data require differential privacy mechanisms — typically Gaussian noise added to gradients before sharing with the aggregator. The appropriate noise calibration depends on the privacy budget (epsilon, delta) and the sensitivity of the gradient to any individual DICOM study. For imaging models, the sensitivity analysis must account for the high dimensionality of image tensors and the potentially low sample counts for rare disease subgroups — conditions that increase gradient sensitivity and require higher noise levels to satisfy differential privacy. NVIDIA FLARE, the leading open-source federated learning framework for medical imaging, integrates with MONAI for DICOM-native data loading and with differential privacy libraries for formal privacy guarantees.
Performance Heterogeneity Across DICOM Sites: A fundamental challenge in federated medical imaging is scanner heterogeneity: different hospital sites use different CT vendors (Siemens, GE, Philips, Canon), different reconstruction kernels, and different scan protocols, all encoded in DICOM metadata. Models trained at one site often fail to generalise to different acquisition parameters, a phenomenon known as domain shift. DICOM metadata — specifically the Convolution Kernel attribute (0018,1210 for CT), kVp (0018,0060), mAs (0018,1152), and slice thickness (0018,0050) — provides the covariates needed to diagnose and correct domain shift. Federated learning frameworks that incorporate DICOM metadata as conditioning variables (e.g., Federated Domain Adaptation approaches) explicitly use acquisition parameter metadata to reduce cross-site performance variance.
Synthetic DICOM Data Generation: Generative models for synthetic medical imaging data — conditional GANs, Latent Diffusion Models trained on DICOM corpora — produce synthetic DICOM objects that preserve the metadata structure (SOP Class, Study/Series/Instance hierarchy, acquisition parameters) of real data while replacing pixel content with statistically realistic but privacy-safe synthetic imagery. Synthetic DICOM datasets are increasingly used to augment federated training, particularly for rare pathology classes where real data is scarce at any individual site. The synthetic objects must satisfy DICOM conformance to integrate into PACS-based federated learning pipelines, requiring use of DICOM-native generation frameworks (MONAI Generative Models, Highdicom for output encoding).
Key Terminology
SOP Class: A Service-Object Pair Class binds an Information Object Definition (IOD — the data model) to a DICOM Service (C-STORE, C-FIND, etc.), forming the contractual basis for DICOM conformance declarations. Each SOP Class has a globally unique UID registered in the DICOM data dictionary.
UID (Unique Identifier): A dotted-decimal globally unique string allocated from a DICOM-registered organisation root (e.g., 1.2.840.10008.5.1.4.1.1.2 for CT Image Storage), used to identify patients, studies, series, instances, SOP Classes, and Transfer Syntaxes without collision across all DICOM systems worldwide.
Transfer Syntax: A UID specifying the encoding rules — byte order (little-endian implicit, little-endian explicit), VR presence, and compression algorithm (JPEG, JPEG 2000, JPEG-XL, JPEG-LS, deflate, RLE) — for a DICOM byte stream exchanged between Application Entities.
PACS (Picture Archiving and Communication System): The central archive and distribution hub that receives DICOM objects from modalities and serves them to viewers, AI systems, and remote sites via DIMSE or DICOMweb.
DICOMweb: The RESTful family of services (STOW-RS, QIDO-RS, WADO-RS) defined in PS3.18 enabling DICOM exchange over standard HTTP without DIMSE socket connections.
DIMSE (DICOM Message Service Element): The traditional command set (C-STORE, C-FIND, C-MOVE, C-GET, C-ECHO) operating over TCP DICOM associations with AE title negotiation and Presentation Context negotiation.
Value Representation (VR): The two-letter code specifying the data type of a DICOM element (LO = Long String, UI = Unique Identifier, OW = Other Word for pixel data, SQ = Sequence of Items).
Conformance Statement: A vendor-published document declaring which SOP Classes (as SCP or SCU), Transfer Syntaxes, and optional attributes a DICOM device or software supports, forming the basis for interoperability verification.