14  Explain DICOM Data Element

14.1 Specific Character Set

14.1.1 1) Brief explanation

Character encoding specification for text data in DICOM

14.1.2 2) Explanation

The Specific Character Set (0008,0005) data element defines how text characters are encoded and interpreted throughout the DICOM file. This is critical because DICOM files can contain text in various languages and scripts, and the system needs to know how to properly decode and display this information.

This element appears in the DICOM header and applies to all text-based data elements within that object unless overridden by more specific character set declarations. It’s particularly important for:

  • Patient names with non-ASCII characters (Asian names, accented characters)
  • Institution names and addresses
  • Study descriptions and comments
  • Any other textual content

The character set affects how bytes are interpreted as characters. Without proper character set specification, text containing non-ASCII characters may display as garbled characters or question marks.

For your radiology data model, this element is crucial for ensuring proper text handling, especially in a Thai hospital environment where you’ll encounter: - Thai script patient names - Mixed Thai-English institutional information - Proper display in reporting systems

14.1.3 3) Example Values

Common values you’ll encounter:

  • ISO_IR 100 - Latin alphabet No. 1 (Western European languages)
  • ISO_IR 192 - UTF-8 Unicode (supports all languages including Thai)
  • ISO_IR 166 - Thai character set (TIS 620)
  • ISO 2022 IR 87 - Japanese Kanji
  • ISO 2022 IR 149 - Korean
  • ISO_IR 100\ISO_IR 192 - Multi-byte encoding (Latin + UTF-8)

In your Thai hospital context, you might see: - ISO_IR 166 for Thai-only text - ISO_IR 192 for mixed Thai-English content (recommended for modern systems) - Empty/absent (defaults to ASCII) in older systems

14.2 Instance Creation Date

14.2.1 1) Brief explanation

Date when the DICOM instance was created

14.2.2 2) Explanation

The Instance Creation Date (0008,0012) records the calendar date when this specific DICOM instance (file) was generated. This is distinct from when the actual imaging study was performed - it represents when the digital DICOM object itself was created by the imaging equipment or processing system.

This timestamp is crucial for: - Tracking data lineage and provenance - Audit trails for regulatory compliance - Understanding workflow timing - Identifying when post-processing or reconstructions occurred

For your radiology data model, this helps distinguish between original acquisition times and subsequent processing events (like when a CT scan was reconstructed with different parameters or when a secondary capture was created).

14.2.3 3) Example Values

  • 20241215 - December 15, 2024
  • 20250708 - July 8, 2025 (today)
  • 20231025 - October 25, 2023

14.3 Instance Creation Time

14.3.1 1) Brief explanation

Time when the DICOM instance was created

14.3.2 2) Explanation

The Instance Creation Time (0008,0013) records the precise time of day when this DICOM instance was generated, complementing the Instance Creation Date. It uses 24-hour format and can include fractional seconds for high precision.

This granular timing is valuable for: - Sequencing multiple instances from the same study - Performance analysis of imaging workflows - Precise audit logging - Correlating with other system events

In your data model, combining this with Instance Creation Date gives you complete temporal context for when each DICOM object entered your system.

14.3.3 3) Example Values

  • 143052 - 2:30:52 PM
  • 091234.567 - 9:12:34.567 AM (with milliseconds)
  • 235959 - 11:59:59 PM
  • 080000 - 8:00:00 AM

14.4 Instance Creator UID

14.4.1 1) Brief explanation

Unique identifier of the device/system that created the DICOM instance

14.4.2 2) Explanation

The Instance Creator UID (0008,0014) is a unique identifier that specifies which device, application, or system created this particular DICOM instance. This is typically the UID of the imaging modality, workstation, or processing software that generated the file.

This identifier is essential for: - Device management and tracking - Quality assurance and calibration correlation - Vendor-specific processing identification - Troubleshooting and maintenance workflows - Multi-vendor environment management

For your hospital’s data model, this helps you track which specific CT scanner, MRI machine, or workstation created each instance, enabling device-specific analytics and maintenance scheduling.

14.4.3 3) Example Values

  • 1.2.840.10008.5.1.4.1.1.2 - Standard DICOM UID format
  • 1.3.6.1.4.1.5962.99.1.2280943358.716200484.1363785608958.2.0 - Vendor-specific UID
  • 1.2.826.0.1.3680043.2.1125.1.75064368132032.2004102715131435.0 - Philips equipment UID
  • 1.2.840.113619.2.5.1762583153.215519.978957063.78 - GE equipment UID

Note: Each vendor typically has their own UID root, making it possible to identify the manufacturer from the UID structure in your data analytics.

14.5 SOP Class UID

14.5.1 1) Brief explanation

Defines the type and format of DICOM object

14.5.2 2) Explanation

The SOP Class UID (0008,0016) identifies the specific Service-Object Pair (SOP) Class that defines what type of DICOM object this is and what operations can be performed on it. Think of it as the “blueprint” or “template” that determines the object’s structure, required data elements, and allowed behaviors.

This is fundamental to DICOM architecture because it tells any DICOM application: - What type of image or data this contains - Which data elements are required vs optional - What DICOM services can operate on this object - How to properly interpret and display the content

For your radiology data model, SOP Class UID is crucial for: - Categorizing different types of imaging data - Ensuring proper data validation and storage - Building type-specific processing workflows - Managing different display and analysis requirements

The SOP Class UID essentially answers: “What kind of DICOM object is this?”

14.5.3 3) Example Values

Common imaging SOP Classes: - 1.2.840.10008.5.1.4.1.1.2 - CT Image Storage - 1.2.840.10008.5.1.4.1.1.4 - MR Image Storage
- 1.2.840.10008.5.1.4.1.1.1 - CR Image Storage (Computed Radiography) - 1.2.840.10008.5.1.4.1.1.6.1 - US Image Storage (Ultrasound) - 1.2.840.10008.5.1.4.1.1.12.1 - X-Ray Angiographic Image Storage

Structured report and other objects: - 1.2.840.10008.5.1.4.1.1.88.59 - Key Object Selection Document - 1.2.840.10008.5.1.4.1.1.104.1 - Encapsulated PDF Storage - 1.2.840.10008.5.1.4.1.1.66.4 - Segmentation Storage

14.6 SOP Instance UID

14.6.1 1) Brief explanation

Globally unique identifier for this specific DICOM instance

14.6.2 2) Explanation

The SOP Instance UID (0008,0018) is a globally unique identifier that distinguishes this specific DICOM instance from every other DICOM object that has ever been created anywhere in the world. It’s like a “digital fingerprint” for the DICOM file.

This UID is fundamental to DICOM’s architecture because it: - Ensures absolute uniqueness across all DICOM systems globally - Enables precise referencing between related objects - Supports DICOM networking operations (query, retrieve, store) - Prevents duplicate storage and processing - Enables cross-referencing in structured reports

For your hospital’s data model, SOP Instance UID serves as: - Primary key for DICOM instance tables - Reference for linking related objects (like measurements referencing images) - Deduplication mechanism - Audit trail identifier - Inter-system communication reference

Key relationship: While SOP Class UID tells you “what type of object this is,” SOP Instance UID tells you “which specific instance this is.”

14.6.3 3) Example Values

Format pattern: root.suffix.timestamp.sequence

  • 1.2.826.0.1.3680043.2.1125.1.98345618203.20241215.143052.1
  • 1.3.6.1.4.1.5962.99.1.2280943358.716200484.1363785608958.2.0
  • 1.2.840.113619.2.5.1762583153.215519.978957063.78
  • 2.16.124.113543.6006.99.04271060513013105014100449.17123

In your data model, these UIDs enable relationships like:

CT Series Instance UID: 1.2.3.4.5.6.7.8.9
├── CT Image Instance UID: 1.2.3.4.5.6.7.8.9.1
├── CT Image Instance UID: 1.2.3.4.5.6.7.8.9.2  
└── Segmentation Instance UID: 1.2.3.4.5.6.7.8.10 (references images above)

14.7 Study Date

14.7.1 1) Brief explanation

Date when the imaging study was performed

14.7.2 2) Explanation

The Study Date (0008,0020) represents the date when the entire imaging study was conducted. This is typically the date when the patient was scheduled for and underwent the imaging examination. It’s the primary temporal reference for the clinical study and what radiologists use to organize and identify examinations.

This date is crucial for: - Clinical workflow and scheduling - Patient care timeline - Report organization and retrieval - Billing and administrative purposes - Quality assurance tracking

14.7.3 3) Example Values

  • 20241215 - December 15, 2024
  • 20250708 - July 8, 2025
  • 20231125 - November 25, 2023

14.8 Series Date

14.8.1 1) Brief explanation

Date when the imaging series was acquired

14.8.2 2) Explanation

The Series Date (0008,0021) indicates when a specific series within a study was performed. A study can contain multiple series (different sequences, orientations, or contrast phases), and each series can potentially be acquired on different dates, though typically they’re the same day as the study.

This becomes important for: - Multi-day studies (rare but possible) - Follow-up series added later - Quality control of series timing - Workflow optimization analysis

14.8.3 3) Example Values

  • 20241215 - Same as study date (typical case)
  • 20241216 - Next day (follow-up series)
  • 20241215 - Multiple series same day

14.9 Acquisition Date

14.9.1 1) Brief explanation

Date when the specific image acquisition occurred

14.9.2 2) Explanation

The Acquisition Date (0008,0022) specifies when the actual image data acquisition took place for individual images or image groups. This is the most granular temporal marker for when the imaging hardware actually captured the data.

Critical for: - Precise timing in dynamic studies - Temporal correlation in functional imaging - Motion analysis - Contrast timing studies - Multi-phase acquisitions

14.9.3 3) Example Values

  • 20241215 - Same as series/study (typical)
  • 20241215 - Multiple acquisitions same day at different times
  • 20241216 - Delayed acquisition (reconstruction, etc.)

14.10 Content Date

14.10.1 1) Brief explanation

Date when the image content was last modified

14.10.2 2) Explanation

The Content Date (0008,0023) represents when the image content itself was created or last modified. This can differ from acquisition when images undergo post-processing, reconstruction with different parameters, or annotation.

Important for: - Post-processing workflows - Data integrity tracking - Version control of processed images - Secondary capture identification - AI/CAD processing timestamps

14.10.3 3) Example Values

  • 20241215 - Same as acquisition (unprocessed)
  • 20241216 - Post-processed next day
  • 20250108 - Later reconstruction or modification

14.11 Date: Comparison and Relationships

Here’s how these dates relate in typical radiology workflows:

Timeline Flow:
Study Date ≤ Series Date ≤ Acquisition Date ≤ Content Date

Typical Scenarios:
┌─────────────────┬─────────────────┬─────────────────┬─────────────────┐
│   Study Date    │   Series Date   │ Acquisition Date│  Content Date   │
├─────────────────┼─────────────────┼─────────────────┼─────────────────┤
│   2024-12-15    │   2024-12-15    │   2024-12-15    │   2024-12-15    │
│   (Standard single-day study - all dates same)                        │
├─────────────────┼─────────────────┼─────────────────┼─────────────────┤
│   2024-12-15    │   2024-12-15    │   2024-12-15    │   2024-12-16    │
│   (Post-processing done next day)                                     │
├─────────────────┼─────────────────┼─────────────────┼─────────────────┤
│   2024-12-15    │   2024-12-16    │   2024-12-16    │   2024-12-16    │
│   (Follow-up series added next day)                                   │
└─────────────────┴─────────────────┴─────────────────┴─────────────────┘

Key Differences:

Granularity Level: - Study Date: Examination level (broadest) - Series Date: Series level (protocol-specific) - Acquisition Date: Image/acquisition level (most specific for timing) - Content Date: Content modification level (processing-aware)

Clinical vs Technical: - Study/Series Date: Clinical scheduling perspective - Acquisition Date: Technical imaging perspective
- Content Date: Data processing perspective

For Your Data Model:

Use Study Date for: - Patient scheduling and clinical timelines - Report organization - Billing and administrative queries

Use Acquisition Date for: - Precise temporal analysis - Dynamic study sequencing - Quality control timing validation

Use Content Date for: - Processing workflow tracking - Data lineage and versioning - Post-processing audit trails

Common Query Patterns:

-- Find all studies from last week
WHERE Study_Date BETWEEN '20241208' AND '20241214'

-- Find processed images
WHERE Content_Date > Acquisition_Date

-- Find multi-day studies  
WHERE Series_Date != Study_Date