HL7 May 2001 Working Group Meeting

DICOM Tutorial

Introduction to DICOMIntroduction to DICOM

May 8, 2001, 9:00 – 10:30 a.m.

Fred M. Behlen, Ph.D.

Kurt Rossmann Laboratoriesfor Radiologic Image ResearchDepartment of Radiology

DICOM Standard• ACR-NEMA 1.0

– Published as NEMA PS3-1985

• ACR-NEMA 2.0– Published as NEMA PS-1988

• Digital Imaging and Communications in Medicine (DICOM) 3.0– Published as NEMA PS3-1993(94?), and

(almost) annual updates thereafter.PS3-2000 now available.

DiagnosticImaging

DICOM Scope

PatientBedside

Monitoring

Administrative HIS/RIS

. . .

Lab Data

. . .

Medical Informatics

Scope ofDICOM

Scope of standards

Information Repre- Transfer Signalingmodel sentation mech- method

syntax anism

DICOM X X XHL7 X X XXML XCORBA X XHTTP, FTP XTCP/IP, Ethernet X

DICOM Standard

“The DICOM Standard is structured as a multi‑part document using the guidelines established in the following document: — ISO/IEC Directives, 1989 Part 3: Drafting and Presentation of International Standards.”

DICOM StandardPS 3.1: Introduction and Overview

PS 3.2: ConformancePS 3.3: Information Object Definitions PS 3.4: Service Class Specifications PS 3.5: Data Structure and Encoding PS 3.6: Data Dictionary PS 3.7: Message Exchange PS 3.8: Network Communication Support for Message Exchange PS 3.9: Point‑to‑Point Communication Support for Message ExchangePS 3.10: Media Storage and File Format for Data InterchangePS 3.11: Media Storage Application ProfilesPS 3.12: Storage Functions and Media Formats for Data InterchangePS 3.13: Print Management Point-to-Point Communication SupportPS 3.14: Grayscale Standard Display FunctionPS 3.15: Security ProfilesPS 3.16: Content Mapping Resource (2001)

DICOM Supplements PS 3.1:

PS 3.2:PS 3.3:PS 3.4:PS 3.5:PS 3.6:PS 3.7:PS 3.8:PS 3.9:PS 3.10: PS 3.11: PS 3.12: PS 3.13: PS 3.14: PS 3.15:

Introduction

Part 1 changes

…

Part 3changes

…

Part 6 changes

…

…

Balloted Supplement Published Standard

M edical Im aging Application

D ICO M Application Entity

D ICO MUpper layer

protocolfor T CP/IP

DICO MSession/

Transport/Network

(STN)

O SI Association C ontro lService E lem ent (AC SE)

O SI Presentation Kernel

O SI Session Kernel

O SI Transport

O SI N etw ork

TCP

DICO MData Link

IP

LLC

Standard network physical layer(E thernet, FDDI, ISDN, et cetera)

D ICO MPhysical(50-pin)

O SI UpperLayerServiceboundary

Point-to-pointenvironm ent

Networked environm ent

N ote: The D ICO M STN supports a subset of the O SI upper layer serv ice

PS 3.1: Introduction and Overview

Part 7: Message Exchange

PS 3.3:Information

Object Definitions

PS 3.6:Data

Dictionary

PS 3.5: Data Structureand Semantics

PS 3.8: NetworkCommunication Supportfor Message Exchange

TCP/IP OSI

PS 3.9: Point toPoint Communication

Support forMessage Exchange

PS 3.4: Service Class Specifications

PS

3.2

: C

on

form

ance

Conformance

• DICOM Conformance Statement– Format and Content specified in Part 2

– Required for every claimed DICOM implementation

• “If there’s no Conformance Statement, it’s not DICOM.”

– Intended audience for Conformance Statement is engineer, not customer.

Vendor ASTANDARD

Customer

conformance

Vendor Bconformance

interoperation

contract

contractscope

Vendor ASTANDARD

Customer

conformance

Vendor Bconformance

interoperationcontract B

contract A

contract Ascope

contract Bscope

(voila!)

Key Sections

• PS 3.3: Information Object Definitions

• PS 3.4: Service Class Specifications

• PS 3.6: Data Dictionary

DIMSE Services

Composite Normalized

C-STORE N-EVENT-REPORT

C-GET N-GET

C-MOVE N-SET

C-FIND N-ACTION

C-ECHO N-CREATE

N-DELETE

DICOM Application EntityService Classes

- Study Mgt- Patient Image Mgt- Results Mgt

- Storage- Print- Query/Retrieve

Information ObjectsNormalized- Patient- Study- Visit

Composite- CT image- MR image- CR image

DICOM Message Service Element(DIMSE)

(DIMSE-C and DIMSE-N Operations and Notifications)

Upper LayerAssociationServices (1)

Upper Layer Presentation Data Service(see figure 6.1-1)

(1) This figure expands upon figure 6.1-1 by showing that the AssociationServices specified in Part 8 are formally part of the Application Entity.

Part 4

Part 3

Part 7

Part 8andPart 9

AssociationNegotiation

PS 3.3: Information Object Definitions

• Computed Radiography Image • Computed Tomography Image • Magnetic Resonance Image • Nuclear Medicine Image • Ultrasound Image • Ultrasound Multi-Frame Image • Secondary Capture Image • X-Ray Angiographic Image • X-Ray RF Image • Positron Emission Tomography Image • Hardcopy Grayscale Image • Hardcopy Color Image • Digital X-Ray Image • Digital Mammography X-Ray Image • Digital Intra-Oral X-Ray Image

PS 3.3: Information Object Definitions

• Visible Light Image – VL Endoscopic Image – VL Microscopic Image – VL Slide-Coordinates Microscopic Image – VL Photographic Image

• Standalone Overlay • Standalone Curve • Standalone Pet Curve • Stored Print • Standalone Modality Lut • Standalone VOI Lut • Grayscale Softcopy Presentation State • Basic Study Descriptor

PS 3.3: Information Object Definitions

• RT Image • RT Dose • RT Structure Set • RT Plan • RT Beams Treatment Record • RT Brachytherapy Treatment Record • RT Treatment Summary Record • Waveform

– Basic Voice Audio – 12-Lead Electrocardiogram – General Electrocardiogram – Ambulatory Electrocardiogram – Hemodynamic – Basic Cardiac Electrophysiology

• Structured Report Document – Basic Text SR – Enhanced SR– Comprehensive SR

PS 3.4: Service Class Specifications

• Verification• Storage• Query/Retrieve• Study Content Notification• Patient Management• Study Management• Results Management• Print Management• Media Storage• Storage Commitment• Basic Worklist Management• Queue Management• Grayscale Softcopy Presentation State Storage• Structured Reporting Storage

Service-Object Pairs (SOPs)

X X

X X X X X X X X X X

X

X X

X

X X

X

X X

X X

X

Ser

vice

sInformation Objects

STORE

PS 3.5: Data Structure and Encoding

• Presentation Context– Abstract Syntax

• Endianism– Big Endian– Little Endian

• Value Representation– Implicit VR– Explicit VR

– Transfer Syntax• Uncompressed• Compressed modes

Data Set and Data Elements

Data Set

Data Element

Tag Value Length Value Field

optional field - dependent on negotiated Transfer Syntax

VR

Data Elem. Data Elem.Data Elem. Data Elem.

order of transmission

PS 3.3 Annex A IOD ModulesCT IMAGE IOD MODULES

IE Module Reference Usage Patient Patient C.7.1.1 M Study General Study C.7.2.1 M Patient Study C.7.2.2 U Series General Series C.7.3.1 M Frame of Reference

Frame of Reference C.7.4.1 M

Equipment General Equipment C.7.5.1 M Image General Image C.7.6.1 M Image Plane C.7.6.2 M Image Pixel C.7.6.3 M Contrast/bolus C.7.6.4 C - Required if contrast media

was used in this image CT Image C.8.2.1 M Overlay Plane C.9.2 U VOI LUT C.11.2 U SOP Common C.12.1 M

PS 3.3 Annex C Patient ID

ModulePATIENT IDENTIFICATION MODULE ATTRIBUTES Attribute Name Tag Attribute Description Patient's Name (0010,0010) Patient's full name Patient ID (0010,0020) Primary hospital identification number or code

for the patient Issuer of Patient ID (0010,0021) Name of healthcare provider which issued the

Patient ID Other Patient IDs (0010,1000) Other identification numbers or codes used to

identify the patient Other Patient Names

(0010,1001) Other names used to identify the patient

Patient's Birth Name

(0010,1005) Patient's birth name

Patient's Mother's Birth Name

(0010,1060) Birth name of patient's mother

Medical Record Locator

(0010,1090) An identifier used to find the patient's existing medical record (e.g. film jacket)

PS 3.3 Annex C Pixel ModuleIMAGE PIXEL MODULE ATTRIBUTES

Attribute Name Tag Type Attribute Description Samples per Pixel (0028,0002) 1 Number of samples (planes) in this

image. See C.7.6.3.1.1 for further explanation.

Photometric Interpretation

(0028,0004) 1 Specifies the intended interpretation of the pixel data. See C.7.6.3.1.2 for further explanation.

Rows (0028,0010) 1 Number of rows in the image. Columns (0028,0011) 1 Number of columns in the image Bits Allocated (0028,0100) 1 Number of bits allocated for each pixel

sample. Each sample shall have the same number of bits allocated. See PS 3.5 for further explanation.

Bits Stored (0028,0101) 1 Number of bits stored for each pixel sample. Each sample shall have the same number of bits stored. See PS 3.5 for further explanation.

High Bit (0028,0102) 1 Most significant bit for pixel sample data. Each sample shall have the same high bit. See PS 3.5 for further explanation.

PS 3.3 Annex C Pixel ModuleIMAGE PIXEL MODULE ATTRIBUTES

Attribute Name Tag Type Attribute Description Pixel Representation (0028,0103) 1 Data representation of the pixel

samples. Each sample shall have the same pixel representation. Enumerated Values: 0000H = unsigned integer. 0001H = 2's complement

Pixel Data (7FE0,0010) 1 A data stream of the pixel samples which comprise the Image. See C.7.6.3.1.4 for further explanation.

Planar Configuration (0028,0006) 1C Indicates whether the pixel data are sent color-by-plane or color-by-pixel. Required if Samples per Pixel (0028,0002) has a value greater than 1. See C.7.6.3.1.3 for further explanation.

Pixel Aspect Ratio (0028,0034) 1C Ratio of the vertical size and horizontal size of the pixels in the image specified by a pair of integer values where the first value is the vertical pixel size, and the second value is the horizontal pixel size. Required if the aspect ratio is not 1\1 and the Image Plane Module is not applicable to this Image. See C.7.6.3.1.7.

Pixel Encoding

Image Plane

Pixel i+1Pixel i

Pixel i+2

Example 1: CT Pixel Cell

Bits Allocated = 16Bits Stored = 12High Bit = 11

Example 2: Hypothetical Pixel Cell

Bits Allocated = 24Bits Stored = 18High Bit = 19

015 1112Pixel SamplePixel Sample

Pixel Sample21923 20 0

PS 3.6: Data Dictionary

• Tag Assignments– [xxxx,xxxx]

– Name (non-canonical)

– Value Representation

– Value Multiplicity

• DICOM-assigned UIDs

• Terminology Mapping Resource Registry

• Registry of Templates

Diagnostic Imaging in the

Patient Care Process• Patient arrives• Physician sees patient, writes order• Patient goes to Imaging Department• Patient is imaged• Radiologist interprets images, writes report• Physician looks at report (and often images)• Physician treats patient based on report• Patient discharged

Imag

ing

Dep

artm

ent

Diagnostic Imaging in the

Patient Care Process Hospital Enterprise

Radiology

Exam context

Results,Images

Exam Context

• Patient identification• Orders• Other clinical information• Scheduling (of some resources)• Financial authorizations

Imaging department obtains from the enterprise:

Patient

Visit

Study

Study ContentNotification

makes has

describes

includes

StudyComponents

Modality PerformedProcedure Steps

Comprisedof

Comprisedof

includes includes contains See Note

Results

contains

Report

LookupTable

StoredPrint

RadiotherapyObjects

1-n

1

0-n

1

1-n

1

1

1-n1

1

1-n

1-n

1-n

1 1 1

0-n

0-n0-n

1-n

0-n

1

0-1

0-n

Series

Frame ofReference

creates

SpatiallyDefines

Equipment

1-n 1-n 1-n

1-n

1-n

0-1

1

Curve

Overlay

0-n

Image

Ammendment

0-n

contains

1

Patient& visit

Study &acquisition

Storeddata

Patient IOD

Visit IOD

Study IOD

Basic StudyDescriptor IOD

references references

describes

references

Study ComponentIOD

Modality PerformedProc. Step IOD

Comprisedof

Comprisedof

references references references See Note

Results IOD

references

Interpretation IODImage IOD

Standalone CurveIOD

Standalone OverlayIOD

Standalone ModalityLUT IOD

Standalone VOI LUTIOD

Stored Print IODSee Figure 7.2b

Radiotherapy IODsSee Figure 7.2c

1-n

1

0-n

1

1-n

1

1

1-n1

1

1-n

1-n

1-n

1 1 1

0-n 0-n

0-n0-n0-n

1-n

0-n

1

0-10-n

Patient& visitIODs

Study &acquisitionIODs

StoreddataIODs

PatientIDdomain^PatientID

Placer OrderPlacer Order Number

Filler OrderFiller Order Number

Requested ProcedureRequested Procedure IDRP Study Instance UID

Performed Procedure StepPerformed Proc. Step UID

SeriesSeries UID

InstanceSOP Instance UID

Scheduled Procedure StepScheduled Proc. Step ID

I-PatientIDdomain^PatientID

I-StudyStudy Instance UID

11-n*

11-n*

10-n

0-n**

0-m**

1

1-n

0-n**

0-m**

1

0-n

11-n

1

1-n

1

0-n

* An Order Placer typically submit a single order (ORM), however, an Order Filler can expand that single order into multiple Requested Procedures. See IHE Y2TF Section 6 for more details.

** See Section 6 for a thorough description of the cardinality relationship options of Modality Performed Procedure Step.

*** The Performed Procedure Step UID is present as the Affected SOP Instance UID.

PatientIDdomain^PatientID

Placer OrderPlacer Order Number

Filler OrderFiller Order Number

Requested ProcedureRequested Procedure IDRP Study Instance UID

Performed Procedure StepPerformed Proc. Step UID

SeriesSeries UID

InstanceSOP Instance UID

Scheduled Procedure StepScheduled Proc. Step ID

I-PatientIDdomain^PatientID

I-StudyStudy Instance UID

11-n*

11-n*

10-n

0-n**

0-m**

1

1-n

0-n**

0-m**

1

0-n

11-n

1

1-n

1

0-n

SR InstanceSOP Instance UID

Results

• Reports

• Images

• Exam status

Imaging department delivers to the enterprise:

http://www.rsna.org/IHEhttp://www.himss.org/IHE

IHE Home Pages

http://medical.nema.org/dicom.html

Committee for the Advancement of DICOMDICOM Resources Pagehttp://www.merge.com/dicom/resources/

DICOM Home Pages