LearnPACS administration, explained visually

Short, interactive diagrams for the core ideas behind a PACS. Open a topic, pick a lesson and click through it.

The building blocks of a PACS and how they fit together.
How images and their metadata travel between modalities, PACS and viewers, one DIMSE service at a time.
How a viewer decides what to show and how: layouts, stored views and the monitors.
The DICOM services over HTTP: search, retrieve and store with URLs, JSON and multipart payloads.
How a scanner gets its orders, reports progress and confirms that images are safe.
How a radiology report is created, stored, verified, found again and sent on to the hospital record.
How to tell, from paper, whether two devices will work together.
Look-up tables for the parts of the standard you meet most.
How the PACS and the rest of the hospital keep each other in sync.

What a PACS is made of

BeginnerOpen on its own page →

DICOM
Internal action

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 9

The interface brings in patients and orders

Core step

What happens

The hospital systems tell the PACS about patients and orders in HL7 messages: registrations and changes of patient data (ADT) and imaging orders (ORM, or OMG and OMI in newer HL7 versions). The PACS stores them, so each study can be matched to a patient and an order when the images arrive.

Why it is needed

Without this link a study arrives with only what the technologist typed. With it, the images are filed under the right patient and accession number from the start.

Technical details

HL7 v2 over TCP, usually through an interface engine
ADT: patient registrations, merges and updates
ORM^O01 (or OMG^O19 and OMI^O23 in newer HL7 versions): the imaging order and the scheduled procedure, with the accession number
The RIS often sits in between and is the source of the orders

All steps at a glance

Glossary

PACS: Picture Archiving and Communication System. The set of systems that receives, stores, finds and shows medical images.
Modality: A device that makes images, such as a CT scanner, an MRI, an X-ray room or an ultrasound.
Archive: The storage where the DICOM files are kept. Often fast disks for recent studies and cheaper storage for older ones.
PACS database: The index of what is in the archive: patients, studies, series and images, with a pointer to each file. It is what makes queries fast.
Viewer: The application where a radiologist or clinician looks at the images. It can be a workstation program or a web page.
RIS: Radiology Information System. It holds the radiology orders and schedule, and often the reports.
VNA: Vendor Neutral Archive. A long-term archive that stores images in standard DICOM so that more than one PACS or viewer can use them.
HL7 v2: The standard for text messages between hospital systems, such as patient registrations (ADT) and orders (ORM, or OMG and OMI in newer HL7 versions).

Summary

A PACS is a set of cooperating parts, not one program. The standard defines the services between them, not how they are built inside.
The usual parts are: an HL7 interface, a worklist service, a DICOM storage service, the archive, the database, a routing engine, long-term storage and a viewer.
The archive holds the files. The database holds the index. A study that is in the archive but not in the database cannot be found.
Between the parts, DICOM carries the images and queries (C-STORE, C-FIND, C-MOVE, C-GET, the Modality Worklist) and HL7 carries patients and orders.
A product's Conformance Statement has a table that maps its services to its Application Entities. It shows which part does what, and with which AE title, in your PACS.

The DICOM association: how two devices agree to talk

BeginnerOpen on its own page →

DICOM
Network (TCP)
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 8

Open the TCP connection

Core step

What happens

DICOM runs on top of TCP. The calling side opens a normal TCP connection to the IP address and port of the other device. Nothing DICOM-specific has happened yet.

Why it is needed

If this step fails, the problem is the network: a wrong IP address or port, a firewall, or a service that is not running. No DICOM log line will explain it.

Technical details

PS3.8: port 104 is the well-known DICOM port (needs privileges on many systems); otherwise use the registered port 11112
Port numbers must be configurable: any port works if both sides are set to it
TLS can wrap the connection (Secure Transport Connection Profiles)

All steps at a glance

Glossary

AE / AE title: Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
Association: A negotiated DICOM connection between two AEs, set up on top of a TCP connection. All DIMSE messages travel inside one.
Presentation context: One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
SOP Class: Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Transfer syntax: How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
DIMSE: DICOM Message Service Element. The set of commands (C-STORE, C-FIND, N-CREATE ...) sent inside an association.
SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.

Summary

An association sits between TCP and the DIMSE messages. It is opened with A-ASSOCIATE-RQ and closed with A-RELEASE-RQ.
The caller proposes presentation contexts (SOP Class plus transfer syntaxes). The acceptor accepts each one with exactly one transfer syntax, or refuses it.
Wrong AE titles give an A-ASSOCIATE-RJ. A SOP Class or transfer syntax the other side does not know gives a refused context in the A-ASSOCIATE-AC.
Calling and called are about who opens the association. SCU and SCP are about who requests and who provides the service. They are independent: in a C-MOVE, the PACS is the SCP first and then calls out as SCU.
One association can carry many DIMSE exchanges. Release it properly so the PACS keeps free association slots.

C-ECHO: the DICOM ping

BeginnerOpen on its own page →

DICOM
Network (TCP)
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 6

TCP connection

Core step

What happens

The sender opens a TCP connection to the target IP address and port.

Why it is needed

This is the first thing a C-ECHO checks. "Connection refused" or a timeout means a wrong port, a firewall, a stopped service or a routing problem.

Technical details

Connection refused: host is up, nothing listens on that port
Timeout: usually a firewall or a wrong IP address
Tip: test the port first with a plain TCP check

All steps at a glance

Glossary

AE / AE title: Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
SOP Class: Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Association: A negotiated DICOM connection between two AEs, set up on top of a TCP connection. All DIMSE messages travel inside one.
Status: A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.

Summary

C-ECHO uses the Verification SOP Class 1.2.840.10008.1.1 and carries no data set. PS3.2 requires every DIMSE implementation that accepts associations to accept it as SCP, so it should always be there.
A successful echo proves: TCP path, AE titles accepted, DICOM service answering. It does not prove that CT, MR or any other SOP Class is accepted.
To test a real workflow, send a small test image (C-STORE) or run a C-FIND after the echo succeeds.
Failures map to layers: connection refused or timeout = network; A-ASSOCIATE-RJ = AE title, access list or limits; echo works but store fails = SOP Class or transfer syntax.
C-ECHO is symmetrical in practice: test both directions, because each side keeps its own list of known AE titles.

How a DICOM C-STORE works

BeginnerOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 7

A-ASSOCIATE-RQ with storage contexts

Core step

What happens

The modality opens the association (see the association lesson). It proposes one presentation context per SOP Class it will send, for instance CT Image Storage, each with the transfer syntaxes it can produce.

Why it is needed

The PACS must agree to receive that kind of image in that encoding before any pixel is sent.

Technical details

Abstract syntax 1.2.840.10008.5.1.4.1.1.2 (CT Image Storage)
Transfer syntax 1.2.840.10008.1.2.1 (Explicit VR Little Endian)
Transfer syntax 1.2.840.10008.1.2.4.70 (JPEG Lossless)
Calling AE = modality, Called AE = PACS storage AE

All steps at a glance

Glossary

SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
SOP Class: Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Presentation context: One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
Transfer syntax: How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
Status: A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.
UID: A globally unique identifier made of numbers and dots, used for SOP Classes, transfer syntaxes, studies, series and instances.

Summary

C-STORE moves one SOP instance. A study is many C-STOREs, usually on one association.
The modality is the Storage SCU. The PACS is the Storage SCP.
Command Field 0001 is C-STORE-RQ, 8001 is C-STORE-RSP. The image goes in the data set that follows the command.
Status 0000 is success. Bxxx is a warning (stored, but changed). A7xx, A9xx and Cxxx are failures.
A successful C-STORE-RSP means received, not necessarily safely archived. Storage commitment (N-ACTION / N-EVENT-REPORT) confirms that.

C-FIND: querying the archive

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 7

A-ASSOCIATE-RQ for Query/Retrieve FIND

Core step

What happens

The workstation opens an association and proposes the FIND SOP Class for the query model it uses. Most systems use Study Root; Patient Root is the older alternative.

Why it is needed

The SOP Class sets which levels you can query (Study Root: study, series, image) and so which attributes are allowed in the identifier.

Technical details

Study Root FIND 1.2.840.10008.5.1.4.1.2.2.1
Patient Root FIND 1.2.840.10008.5.1.4.1.2.1.1
Transfer syntax: Implicit VR Little Endian is enough (identifiers are small)

All steps at a glance

Glossary

SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
SOP Class: Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Status: A 16-bit code in every DIMSE response (0000,0900). 0000 is success, FE00 is cancel, FF00 and FF01 are pending, 0001, Bxxx, 0107 and 0116 are warnings, and Axxx, Cxxx, 01xx and 02xx (the others) are failures.
UID: A globally unique identifier made of numbers and dots, used for SOP Classes, transfer syntaxes, studies, series and instances.
Identifier: The data set sent with a C-FIND or C-MOVE request or response. It holds the keys to match or the values returned.

Summary

C-FIND is the search step of Query/Retrieve. It lists; it does not move any image.
The identifier mixes matching keys (with a value) and return keys (empty). QueryRetrieveLevel (0008,0052) selects PATIENT, STUDY, SERIES or IMAGE.
Each match is one C-FIND-RSP with status FF00 (pending). A final 0000 ends the list.
Study Root (1.2.840.10008.5.1.4.1.2.2.1) is the usual model. Patient Root is older.
Limit the query. Unbounded queries load the PACS database and return huge lists.

C-MOVE: retrieving a study (and C-GET)

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 7

C-MOVE-RQ with a Move Destination

Core step

What happens

On an association already opened with a Retrieve SOP Class, the requester sends the C-MOVE request. It carries the AE title of the destination, and an identifier that selects what to move, usually a StudyInstanceUID found with C-FIND.

Why it is needed

The request names the receiver by AE title only. The requester does not tell the PACS where the destination is on the network. That is the PACS's job.

Technical details

Study Root MOVE 1.2.840.10008.5.1.4.1.2.2.2 (Patient Root: ...2.1.2)
(0000,0100) CommandField = 0021
(0000,0600) MoveDestination = DEST_AE (AE title)
(0008,0052) QueryRetrieveLevel = STUDY
(0020,000D) StudyInstanceUID = 1.2.840....

All steps at a glance

Glossary

SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
AE / AE title: Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
Move Destination: The AE title in a C-MOVE request that tells the PACS who should receive the images.
Sub-operation: One C-STORE the PACS performs for a C-MOVE or C-GET. The responses count them.
C-GET: Like C-MOVE, but the images are returned on the same association as C-STORE sub-operations, so no destination is named.

Summary

C-MOVE tells the PACS: send this to destination X. The images do not come back on the same association.
The PACS must know the destination: AE title, IP address and port are set in the PACS node list. Unknown means A801.
The PACS acts as Storage SCU on a different association: it reuses a compatible one to the destination or opens a new one. The destination must accept it as Storage SCP.
The requester only gets C-MOVE-RSP messages with counts: optional FF00 responses while running, then 0000, B000 or a failure at the end.
C-GET returns images on the same association. It needs no destination or inbound port, but few PACS support it well. DICOMweb (WADO-RS) is the modern HTTP alternative.

How a viewer opens a study

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 8

The radiologist opens a study

Core step

What happens

The radiologist selects a study in the reading worklist. The viewer knows the study and its patient, and now has to find everything needed to show it.

Why it is needed

The study is more than its images. The layout and the way each image looks come from other objects.

Technical details

StudyInstanceUID (0020,000D)
PatientID (0010,0020)
Modality and procedure code of the study

All steps at a glance

Glossary

Viewer: The reading workstation software that shows images to the radiologist.
Hanging protocol: A stored object that says which images go where on the screens, for a kind of study.
Presentation state: A stored object that says how an image is displayed: contrast, rotation, annotations.
Display system: The part of the workstation that drives the monitors, which can describe itself with an N-GET.
SOP Instance UID: The unique ID of one stored object. A hanging protocol is retrieved by it.
Prior: An earlier study of the same patient, shown for comparison.

Summary

The viewer first finds the study with C-FIND, then asks for a hanging protocol with a C-FIND on 1.2.840.10008.5.1.4.38.2.
A protocol is retrieved with C-MOVE or C-GET by SOP Instance UID. Images and presentation states are retrieved like any composite object.
The Display System N-GET is optional and tells the viewer about the monitors.
The viewer lays out the screens from the protocol and applies the presentation states, whose transformations replace the images' own.
The standard defines the services. The order of the steps and the choice between several matching protocols or states are up to the viewer.

Presentation states: storing the radiologist's view

IntermediateOpen on its own page →

Filter the tables

51 rows

What a presentation state is and the rules around it

These are the rules PS3.4 Annex N sets for creating, storing and applying a Softcopy Presentation State.

Topic	Rule
What it adds	It extends the Storage Service Class to convey an intended presentation, or to record an existing one. It does not change the images it refers to.
What it can specify	Output grayscale space in P-Values, color output as PCS-Values, grayscale contrast (modality, VOI and presentation LUT), mask subtraction for multi-frame images, the area to show and its rotation or flip, annotations (graphics, text, overlays), and blending of two image sets.
Which images it covers	One state per image, or one common state for several selected images. For grayscale, color and pseudo-color states, all images must be in the same study as the state and of one Composite Image Storage SOP Class. For blending states each set lies in one study, and the sets may be in different studies.
Immutable	The presentation attributes are never modified or updated. A different presentation is a derived SOP Instance with a new SOP Instance UID.
Replaces the image's own values	The transformations in the state replace those in the referenced image. A transformation absent from the state is identity, and the image's own equivalent is not used in its place.
Photometric Interpretation	The value in the referenced image (MONOCHROME1 or MONOCHROME2) is ignored. The grayscale pipeline of the state decides the polarity.
Overlays in the image	The state has a mechanism to switch bit-mapped overlays on or off.
How it is made	How an SCU records or generates a state is outside the standard. It may come from an operator action such as a window level change, or from an algorithm.
Several states for one image	How a viewer chooses between them is outside the standard. A viewer that conforms must make the state available to the user and, if the user selects it, apply all its transformations as defined.

Two devices applying the same grayscale state should show a perceptually similar image, because P-Values are defined in the Grayscale Standard Display Function (PS3.14), whatever the actual displays can do.

The presentation state SOP Classes

Storage SOP Classes of PS3.4. The grayscale state is the one that radiology viewers meet most.

SOP Class	UID	For
Grayscale Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.1`	Grayscale images: contrast, shutter, rotation, annotations.
Color Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.2`	Color images, with an ICC profile.
Pseudo-Color Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.3`	Grayscale images shown through a color palette.
Blending Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.4`	Two sets of images blended, such as PET over CT.
XA/XRF Grayscale Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.5`	Angiography and fluoroscopy, with mask handling per frame.
Advanced Blending Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.8`	Two or more image sets blended.
Variable Modality LUT Softcopy Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.12`	A modality LUT that varies. Optional companion of the Grayscale state for some enhanced images.
Grayscale Planar MPR Volumetric Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.6`	Multiplanar reformats of a volume.
Compositing Planar MPR Volumetric Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.7`	Multiplanar reformats combined from several volumes.
Volume Rendering Volumetric Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.9`	A rendered volume view.
Segmented Volume Rendering Volumetric Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.10`	A rendered volume with segmentation.
Multiple Volume Rendering Volumetric Presentation State Storage	`1.2.840.10008.5.1.4.1.1.11.11`	Several rendered volumes together.
Waveform Presentation State Storage	`1.2.840.10008.5.1.4.1.1.9.100.1`	The display of waveforms such as an ECG.
Waveform Acquisition Presentation State Storage	`1.2.840.10008.5.1.4.1.1.9.100.2`	The presentation of a waveform at acquisition.

Some image SOP Classes are tied to a presentation state in PS3.4. For example an SCP of the Enhanced MR Color Image Storage SOP Class must also support the Color Softcopy Presentation State Storage SOP Class.

The grayscale pipeline, step by step

The conceptual order in which a stored grayscale image becomes a displayed one. A viewer may implement it differently as long as the result looks the same.

Step	What it does	Attributes	If image and state both have it
1. Modality LUT	Turns manufacturer-specific pixel values into values meaningful for the modality, such as Hounsfield units.	Rescale Slope `(0028,1053)` and Intercept `(0028,1052)`, or the Modality LUT Sequence	The state's is used. If the state has none, it is identity and the image's is not used.
2. Mask	For multi-frame images: subtracts other frames from the current one. For X-ray the subtraction is done in a logarithmic space.	Mask Module	The state decides. A Modality LUT in the image is ignored when a mask is used.
3. VOI LUT	The window: turns modality values into values meaningful to the user.	Window Center `(0028,1050)`, Window Width `(0028,1051)`, VOI LUT Sequence, VOI LUT Function `(0028,1056)`	The state's is used, otherwise identity.
4. Presentation LUT	Turns the values into P-Values, the device independent perceptually linear space of PS3.14. Always present in a state.	Presentation LUT Shape `(2050,0020)` or the Presentation LUT Sequence	The state's is used.

There is no separate polarity step. Inverting an image is done with the Presentation LUT: with the shape IDENTITY or INVERSE the minimum value shows as white or black. The minimum P-Value always commands the lowest intensity.

Shutter, annotation, rotation and displayed area

These steps apply after the contrast pipeline, to grayscale P-Values and to color PCS-Values alike.

Step	What it does	Rule
Shutter	Excludes the perimeter outside a region and fills it with a given gray level. The region comes from the Display Shutter Module or from a bit-mapped overlay (Bitmap Display Shutter Module).	A shutter in the image itself is ignored. Annotations follow the shutter, so annotations inside a shuttered area stay visible.
Annotation in image space	Overlays, text and graphics defined on the pixels of the image.	Applied before the spatial transformation.
Spatial transformation	A rotation of 90, 180 or 270 degrees clockwise, followed by an optional horizontal flip. Rotation by another angle is not supported.	The displayed area (Displayed Area Module) selects the part of the image to show, which can magnify or minify it. The method of interpolation is implementation dependent.
Annotation in display space	Text and graphics defined on the displayed area, after all spatial transformations.	They may be anchored to points in either the displayed area or the image.

The number of displayed pixels may differ from the number of image pixels through minification, magnification, interpolation and sub-sampling.

Color and blending

Color and blended states define colors in a device independent space instead of P-Values.

Topic	Rule
ICC profile	Always present in a Color, Pseudo-Color or Blending state. It is an input profile that describes the device that produced the colors. The profile in the state replaces the one in the image.
Profile Connection Space	Output values are PCS-Values (CIEXYZ or CIELab). The viewer converts them for its own display, typically through a display profile. The method is outside the standard.
Image without an ICC profile	Has no defined color space. A color state that carries a profile defines one, often a well-known space such as sRGB.
Blending	The underlying set is grayscale, the superimposed set is mapped through a palette to color. Per pixel: `Ro = RsA + Yu(1-A)`, and the same for green and blue, with A the opacity and Yu the grayscale value.
Blending and registration	Spatial registration, resampling and interpolation are not specified. The two sets are not blended image by image. A viewer may support the Spatial Registration Storage SOP Class, but it is not required.
Color image on a grayscale display	The behavior is not defined.

What a viewer or archive must state

In the conformance statement, as an SCU (a device that creates states) and as an SCP (a device that displays them).

Role	What the conformance statement must say
SCU creating states	How the presentation attributes are derived from the displayed image, an operator action or defaults, and how they go into the IOD.
SCU creating states	Which Image Storage SOP Classes it also supports and that its states may refer to.
SCU creating states	Whether it supports the Compound Graphic Sequence `(0070,0209)` and which compound graphic types it generates.
SCP displaying states	How the presentation attributes influence the display of an image.
SCP displaying states	Which Image Storage SOP Classes it supports for states.
SCP displaying states	Whether it can render compound graphics, and which types. If it does, it shows the compound graphic and not the text and graphic objects that share its Compound Graphic Instance ID.

An SCP must make all mandatory presentation attributes available for the user to apply to the referenced images, for every Image Storage SOP Class named in its conformance statement for which it supports the state.

The image looks different from what the radiologist saw

Each cause follows from a rule above. The first check is whether a presentation state exists for the image at all.

Symptom	Likely cause	Rule behind it
Window level, rotation or annotations missing in a second viewer	The first viewer kept its view in its own database and never stored a presentation state, or stored it in a private format.	The standard does not require a viewer to create a state. Only a stored state travels with the study.
The state exists but the viewer ignores it	The viewer does not support that presentation state SOP Class, or the SOP Class was not negotiated in the association.	The conformance statement lists the SOP Classes. Support is per SOP Class.
Annotations visible, contrast different	The viewer applied the graphic annotations but not the VOI LUT, or applied the image's own window instead of the state's.	When a state is applied, its transformations replace the image's. A missing one is identity.
Image inverted	The viewer used the Photometric Interpretation of the image instead of the Presentation LUT of the state.	With a state, Photometric Interpretation is ignored and the Presentation LUT decides polarity.
Several views of the same image, the wrong one shown	More than one state refers to the image and the viewer picked another by its own rule.	How a viewer chooses between states is not defined by the standard.
Annotations in black areas missing	The viewer drew the annotation before the shutter.	Annotations follow the shutter, so they are visible inside shuttered regions.
Two monitors look different	Different calibration of the displays, not a different state.	P-Values give a perceptually similar result within the limits of the displays and PS3.14.
A correction after sending is not seen	The state was edited in place, but viewers cache the old SOP Instance UID.	A state is immutable: a changed view is a new object with a new SOP Instance UID.

Glossary

Presentation state: A DICOM object that records how images should be displayed, without changing the images.
GSPS: Grayscale Softcopy Presentation State. The common name for the grayscale presentation state.
LUT: Look-up table. A table that maps one set of values to another, such as stored pixel values to display values.
Modality LUT: The first step: it gives pixel values a meaning for the modality, for example Hounsfield units in CT.
VOI LUT / window: Value of interest. The window center and width that choose which values are shown with how much contrast.
P-Values: Presentation values: a device independent, perceptually linear grayscale space defined in PS3.14.
PCS-Values: Profile Connection Space values: the device independent color space of ICC profiles.
Shutter: A mask that hides the edge of an image, for example the area outside the collimated X-ray field.
Immutable: Cannot be edited. A changed presentation is a new object with its own SOP Instance UID.

Summary

A presentation state stores how to show images, not the images themselves. It is sent with C-STORE like any other object.
The grayscale pipeline is Modality LUT, mask, VOI LUT and Presentation LUT, giving P-Values. Then shutter, annotation, rotation and displayed area follow.
When a state is applied, its transformations replace the image's. A transformation the state lacks is identity, and the image's own is not used.
Photometric Interpretation in the image is ignored when a grayscale state is applied.
A state is immutable. A changed view is a new SOP Instance with a new UID.
The standard does not say which state a viewer picks when there are several, and does not require a viewer to create one.
The Grayscale Softcopy Presentation State SOP Class is 1.2.840.10008.5.1.4.1.1.11.1.

Hanging protocols and the display system

IntermediateOpen on its own page →

Filter the tables

44 rows

The SOP Classes involved

One SOP Class stores the protocol, three find and retrieve it, and a separate service describes the display.

SOP Class	UID	Service	Used for
Hanging Protocol Storage	`1.2.840.10008.5.1.4.38.1`	`C-STORE`	Sending a hanging protocol object to an archive or viewer. Part of the Non-Patient Object Storage Service Class.
Hanging Protocol Information Model - FIND	`1.2.840.10008.5.1.4.38.2`	`C-FIND`	Searching the protocols that an SCP holds.
Hanging Protocol Information Model - MOVE	`1.2.840.10008.5.1.4.38.3`	`C-MOVE`	Asking the SCP to send selected protocols to a destination.
Hanging Protocol Information Model - GET	`1.2.840.10008.5.1.4.38.4`	`C-GET`	Retrieving protocols on the same association.
Display System	`1.2.840.10008.5.1.1.40`	`N-GET`	Reading the properties of the display subsystem of a workstation.
Color Palette Storage	`1.2.840.10008.5.1.4.39.1`	`C-STORE`	Sending a color palette used to display images. Same storage service class as hanging protocols.

The Hanging Protocol Query/Retrieve Service Class has a single level, the hanging protocol object. It works like the Basic Worklist Management Service Class for C-FIND and like Query/Retrieve for C-MOVE, but with only one level of retrieval.

The keys used to find a protocol

The matching key types are R (required) and U (unique). A viewer sends the values of the study it is about to open and gets the protocols that fit.

Key	Tag	Type	Matching
SOP Instance UID	`(0008,0018)`	Unique	The key for C-MOVE and C-GET. One UID or a list of UIDs.
Hanging Protocol Name	`(0072,0002)`	Required	Single value, wild card or universal.
Hanging Protocol Level	`(0072,0006)`	Required	Single value or universal.
Hanging Protocol Definition Sequence	`(0072,000C)`	Required	Sequence matching or universal. The next five keys are inside its item.
Modality	`(0008,0060)`	Required, in the sequence	Single value or universal.
Anatomic Region Sequence	`(0008,2218)`	Required, in the sequence	Sequence matching or universal.
Laterality	`(0020,0060)`	Required, in the sequence	Single value or universal.
Procedure Code Sequence	`(0008,1032)`	Required, in the sequence	Sequence matching or universal.
Reason for Requested Procedure Code Sequence	`(0040,100A)`	Required, in the sequence	Sequence matching or universal.
Number of Priors Referenced	`(0072,0014)`	Required	Single value or universal.
Hanging Protocol User Identification Code Sequence	`(0072,000E)`	Required	Sequence matching or universal. Whose protocol it is.
Hanging Protocol User Group Name	`(0072,0010)`	Required	Type 3 return key.
Number of Screens	`(0072,0100)`	Required	The screens the protocol is made for.

The response also returns, without matching on them, the description, the creator, the creation date and time, and the Nominal Screen Definition Sequence (0072,0102) with the pixels and bit depth of each screen the protocol was made for.

Finding and retrieving, step by step

Because the model has a single level, the flow is shorter than the Query/Retrieve flow for studies.

Step	What the viewer does	Rule
1. Ask	C-FIND on `1.2.840.10008.5.1.4.38.2` with the keys of the study to open and zero-length return keys.	One response per matching protocol, all Pending, then Success without an Identifier. The Worklist search method is used.
2. Choose	The viewer picks a protocol from the matches.	The standard does not say how to choose between several matches.
3. Fetch	C-MOVE (`.38.3`) or C-GET (`.38.4`) with the SOP Instance UID, or a list of UIDs.	Query/Retrieve Level `(0008,0052)` must not be present. Relational retrieve and extended behavior are not defined.
4. Receive	The protocol arrives by a `C-STORE` sub-operation under Hanging Protocol Storage.	The SCP states in its conformance statement the storage SOP Class under which the sub-operations are made.
5. Apply	The viewer lays out the images following the protocol.	A display application must apply all mandatory hanging protocol and presentation intent attributes.

The display system: what the monitors are

The Display System Management Service Class lets an application ask the display subsystem about itself, so a protocol can be matched to the real monitors.

Item	Detail
Service	`N-GET` only. The SCU sends the SOP Class `1.2.840.10008.5.1.1.40` and the well-known instance UID `1.2.840.10008.5.1.1.40.1`.
The instance	The SCP creates the Display System SOP Instance when the display system starts. It abstracts the soft-copy display system.
What can be read	Manufacturer, model, serial number, institution, station and department names, and the number of display subsystems with an ID, name and description for each.
Which attributes	The SCU names the attributes it wants. It must not name an attribute inside a sequence; it asks for the sequence in full.
Also described	Calibration details such as the date of the last calibration, the measurement equipment, and ambient light values.

Support is optional and per product. Check the conformance statements of the viewer and of the display system before counting on it.

What the conformance statements must say

PS3.4 asks the creator and the displaying application of a hanging protocol to describe their behavior.

Role	What must be stated
Creating a protocol (SCU)	How the values are derived from displayed images, layouts, operator action or defaults.
Creating a protocol (SCU)	Any private attributes used as the Selector Attribute `(0072,0026)` in the Image Set Selector, Filter Operations or Sorting Operations Sequences.
Creating a protocol (SCU)	The optional attributes it may include.
Displaying a protocol (SCP)	The range of display environments it supports, such as the number and size of screens and overlapping image boxes.
Displaying a protocol (SCP)	Which optional attributes of the hanging protocol it can interpret, and which not.
Displaying a protocol (SCP)	What it does when Partial Data Display Handling `(0072,0208)` is `ADAPT_LAYOUT` or has zero length.
Displaying a protocol (SCP)	What it does when its display environment differs from the one in the protocol: preserve the layout or the spatial resolution.
Displaying a protocol (SCP)	The Image Storage SOP Classes for which it supports hanging protocols.

Why a study opens in the wrong layout

Each cause follows from the rules above.

Symptom	Likely cause	Rule behind it
The viewer shows its default layout	No stored hanging protocol matches: modality, body part, laterality, procedure code or number of priors differ from the study.	The protocol is found by matching those keys.
A protocol made on one workstation looks wrong on another	The number or size of the screens differs from those of the protocol.	The protocol carries the screen definition. The viewer states whether it keeps the layout or the resolution.
Layout correct, but images in the wrong order	The viewer does not support the sorting or selection attributes that the protocol uses.	The viewer states which optional attributes it supports.
The wrong user's protocol is used	Several matches exist, for example one per user, and the viewer picked another.	The standard does not define how to choose between matching protocols.
A change to a protocol is not seen	The viewer cached the previous object.	A modified object is a new object. Retrieve by its SOP Instance UID.
The protocol cannot be retrieved	The query returns it, but the C-MOVE destination is not known to the SCP, or the SOP Class is not accepted.	C-MOVE needs a destination AE title. The SCP states the storage SOP Class it uses for the sub-operations.
Different results on a mixed-vendor setup	The vendors implement only the required attributes.	Optional attributes are listed per product in the conformance statement.

Glossary

Hanging protocol: A stored description of how to arrange the images of a kind of study on the screens, and which image goes where.
Display environment: The monitors a protocol is meant for: how many, their size in pixels, and their bit depth.
Priors: Earlier studies of the same patient that are shown next to the current one for comparison.
Image set: A group of images selected by rules, which a protocol places in a box on the screen.
Display subsystem: The part of a workstation that drives the monitors, such as a graphics board with its screens.
Well-known UID: A fixed UID defined by the standard, here for the single Display System SOP Instance.
SOP Instance UID: The unique identifier of one stored object. It is the only key for retrieving a hanging protocol.

Summary

A hanging protocol is a stored DICOM object with SOP Class 1.2.840.10008.5.1.4.38.1, sent with C-STORE.
Viewers find protocols with C-FIND on .38.2, and retrieve them with C-MOVE (.38.3) or C-GET (.38.4) by SOP Instance UID only.
The matching keys include Modality, Anatomic Region, Laterality, Procedure Code, Number of Priors, the user and the Number of Screens.
The standard does not say how a viewer picks between several matching protocols.
The Display System SOP Class (1.2.840.10008.5.1.1.40) lets an application read the display setup with N-GET. Support is optional.
When a study opens in the wrong layout, compare the study with the protocol keys, and the monitors with the screen definition in the protocol.

How a web viewer opens a study (DICOMweb)

IntermediateOpen on its own page →

DICOMweb (HTTP)
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 10

The radiologist opens a study

Core step

What happens

The viewer starts from what the user chose: a patient and a date, or a link that already holds a Study Instance UID. If it only has the patient, it has to search first.

Why it is needed

Every retrieve URL in DICOMweb is built from UIDs. The search turns what a person knows into those UIDs.

Technical details

Base URI of the service, for example https://pacs.example.org/dicomweb
Patient ID or Accession Number from the worklist
No UID yet: the Search Transaction finds it

All steps at a glance

Glossary

DICOMweb: The DICOM services over HTTP, defined in PS3.18: Studies, Worklist and the other web services.
User agent / origin server: The client that sends the request and the server that holds the resources and answers.
QIDO-RS: The Search Transaction of the Studies Service: a GET that searches studies, series and instances.
WADO-RS: The Retrieve Transaction of the Studies Service: a GET that returns instances, metadata, rendered images and more.
STOW-RS: The Store Transaction of the Studies Service: a POST that stores instances.
Media Type: The format of a payload, such as application/dicom+json or image/jpeg, named in the Accept and Content-Type headers.
Bulk Data URI: A link in the metadata to a large value, such as pixel data, that is retrieved separately.

Summary

DICOMweb Search is a GET on /studies, /series or /instances (QIDO-RS). Matching keys are query parameters.
Retrieve is a GET on /studies/{study} and its sub-resources: instances, /metadata, /rendered, /thumbnail, /bulkdata, /pixeldata and frames (WADO-RS).
Store is a POST to /studies or /studies/{study} with a multipart body (STOW-RS).
A search with no matches is 200 with an empty list. 202 means a store was only partly done.
406 means none of the requested media types is available, and 415 means the server does not accept the media type you sent.
The order of requests is up to the viewer. The standard defines the transactions and their rules.

DICOMweb services at a glance

IntermediateOpen on its own page →

Filter the tables

91 rows

The DICOMweb services

PS3.18 defines one URI service and several REST services. Each service is a set of transactions on a set of resources.

Service	What it manages	Also known as
Studies Service	Studies, series, instances, and their metadata, rendered, thumbnail, frame and bulk data variants.	`WADO-RS` (retrieve), `STOW-RS` (store), `QIDO-RS` (search)
Worklist Service	A worklist of workitems (UPS instances): create, retrieve, update, change state, cancel, search and subscribe.	`UPS-RS`
URI Service	Retrieval of single composite instances by a query string.	`WADO-URI`
Non-Patient Instance Service	Non-patient instances such as color palettes.
Storage Commitment Service	A request that the server takes safekeeping of instances.
Modality Scheduled Procedure Step Service	Searching for scheduled procedure steps.
Modality Performed Procedure Step Service	Reporting progress on performed procedure steps.

Every REST service must implement the Retrieve Capabilities transaction: an `OPTIONS` request on the base URI that returns a machine readable description of what the server supports, as WADL (`application/vnd.sun.wadl+xml`) or `application/json`.

The Studies Service transactions

Three transactions, each with one HTTP method.

Transaction	Method	Request payload	Success response	DIMSE counterpart
Search (`QIDO-RS`)	`GET`	None	A list of matches	`C-FIND`
Retrieve (`WADO-RS`)	`GET`	None	Instances, metadata, renderings, pixel data or bulk data	`C-MOVE` or `C-GET`
Store (`STOW-RS`)	`POST`	Instances	A Store Instances Response	`C-STORE`
Retrieve Capabilities	`OPTIONS`	None	A Capabilities Description	No equivalent

An origin server may be a native implementation or a DIMSE proxy that converts web requests into DIMSE requests and back. A proxy has fewer mandatory search resources.

Search URLs (QIDO-RS)

Six search resources. Native servers support all; DIMSE proxies must support the hierarchical ones.

Resource	URL template	Native	Proxy	Query type
All Studies	`/studies{?search*}`	Mandatory	Mandatory	Hierarchical
Study's Series	`/studies/{study}/series{?search*}`	Mandatory	Mandatory	Hierarchical
Study's Series' Instances	`/studies/{study}/series/{series}/instances{?search*}`	Mandatory	Mandatory	Hierarchical
Study's Instances	`/studies/{study}/instances{?search*}`	Mandatory	Optional	Relational
All Series	`/series{?search*}`	Mandatory	Optional	Relational
All Instances	`/instances{?search*}`	Mandatory	Optional	Relational

Examples from the standard: `/studies?PatientID=11235813&StudyDate=20130509-20130510` and `/studies?00100010=SMITH*&limit=25`. A key can be a keyword or an 8-digit tag.

Search query parameters

All search transactions support these parameters on the origin server. The user agent may use them.

Parameter	Meaning	DIMSE counterpart	Detail
Attribute = value	A matching key	Matching key	Same matching types as C-FIND: single value, wild card, range, UID list. Each attribute once. Characters such as `#`, `[`, `]`, `&`, `=` and `,` must be percent-encoded.
`includefield`	More attributes to return, or `all`	Return key	A comma-separated list, or `all`. If `all` is present no other includefield is allowed.
`limit`	Maximum number of matches in one response	-	An unsigned integer. The server may apply its own system limit.
`offset`	Number of matches to skip	-	An unsigned integer, default 0. The same request returns the same ordered list if the data has not changed.
`fuzzymatching`	Fuzzy matching of person names	Extended negotiation	`true` or `false`, default false. If not supported the server searches literally and adds a `Warning: 299` header.
`emptyvaluematching`	Match attributes that have an empty value	-	Optional, default false. If not supported the server adds a Warning header.
`multiplevaluematching`	Match attributes with several values	-	Optional, default false. If not supported the server adds a Warning header.

If more results exist the response carries `Warning: 299 <service>: There are <remaining> additional results that can be requested`. A search with no matches is a 200 with an empty payload (an empty JSON array for application/dicom+json). An unsupported parameter is ignored; a supported parameter with an invalid value gives 400.

Required matching attributes and what a search returns

The levels follow the Study Root model: the patient attributes belong to the study. These are the required matching attributes per level.

Level	Required matching attributes	Always returned
Study	Study Date `(0008,0020)`, Study Time, Accession Number `(0008,0050)`, Modalities In Study `(0008,0061)`, Referring Physician Name, Patient Name, Patient ID, Study Instance UID `(0020,000D)`, Study ID	The matching attributes plus Patient's Birth Date and Sex, Number of Study Related Series `(0020,1206)` and Instances `(0020,1208)`, and Retrieve URL `(0008,1190)` when retrievable
Series	Modality `(0008,0060)`, Series Instance UID `(0020,000E)`, Series Number, Performed Procedure Step Start Date and Time, Request Attributes Sequence	Plus Number of Series Related Instances `(0020,1209)`, and Series Description if known
Instance	SOP Class UID `(0008,0016)`, SOP Instance UID `(0008,0018)`, Instance Number	Plus Rows, Columns, Bits Allocated and Number of Frames if known, and Retrieve URL

The list is consistent with the keys of IHE RAD-14. Optionally the server can support the Repository Query attributes Prior Record Key (0008,041C) and Maximum Number of Records (0008,0429). The response may include Available Transfer Syntax UID (0008,3002).

Retrieve URLs (WADO-RS)

The resources of the Retrieve Transaction. All are `GET`.

What you get	URL template	Support
Instances of a study, series or one instance	`/studies/{study}`, `.../series/{series}`, `.../instances/{instance}`	Mandatory
Metadata (without bulk data)	`/studies/{study}/metadata`, `.../series/{series}/metadata`, `.../instances/{instance}/metadata`	Mandatory
Rendered images or documents	`.../rendered` on a study, series or instance, and `.../frames/{frames}/rendered`	Mandatory
Thumbnail	`.../thumbnail` on a study, series, instance or frames	Optional, all or none
Bulk data	`{bulkdataURI}`, and `.../bulkdata` on a study, series or instance	Bulk Data URI mandatory, the `/bulkdata` resources optional
Pixel data	`.../pixeldata` on a study, series or instance	Optional
Frames	`/studies/{study}/series/{series}/instances/{instance}/frames/{frames}`	Mandatory
Rendered MPR volume	`.../renderedmpr`	Optional
Rendered 3D volume	`.../rendered3d`	Optional

`{frames}` is a comma-separated list of frame numbers in ascending order. The retrieve transaction has no request payload. A Bulk Data URI can be absolute, relative with an absolute path, or relative to the metadata request.

Media types

The Accept header chooses the representation. These are the defaults and requirements from PS3.18.

Resource	Media type	Usage
Instances (retrieve)	`multipart/related; type="application/dicom"`	Default
Instances (retrieve)	`multipart/related; type="application/octet-stream"`	Required (the same as retrieving the bulk data)
A single instance	`application/dicom`	Optional. Single part: only for a resource that is one item.
Metadata	`application/dicom+json`	Default. JSON for several instances is one top-level array.
Metadata	`multipart/related; type="application/dicom+xml"`	Required
Bulk data and pixel data	`multipart/related; type="application/octet-stream"`	Required
Thumbnail	`image/jpeg`	Default
Rendered single frame image	`image/jpeg` (default), `image/gif` and `image/png` (required for REST)	Also optional: `image/jp2`, `image/jph`, `image/jxl`
Rendered text	`text/html` (default), `text/plain` (required), `text/xml` (required for REST)	Also optional: `text/rtf`, `application/pdf`
Rendered video	`video/mpeg`, `video/mp4`, `video/H265`	Optional
Search results	`application/dicom+json` (default), `multipart/related; type="application/dicom+xml"` (required)
Capabilities	`application/vnd.sun.wadl+xml` or `application/json`

Two parameters refine a DICOM media type: `transfer-syntax=<UID or *>` and `charset=`. A media type may have only one transfer-syntax value, so several choices are given as several media types with q values. Implicit VR Little Endian and the retired Explicit VR Big Endian must not be used. The default for an uncompressed instance is Explicit VR Little Endian (`1.2.840.10008.1.2.1`).

Parameters for rendered images

These work on the /rendered resources. They are applied as if they were a presentation state, and all are optional for the user agent.

Parameter	Value	Meaning	Errors
`accept`	A rendered media type	The format of the image	406 if not supported
`annotation`	`patient` and/or `technique`	Burns patient or technique information into the picture. Absent means no annotation.	400 for non-keywords; unsupported values are ignored with a Warning
`quality`	1 to 100	Requested quality for formats that allow lossy compression	400 if not an integer from 1 to 100
`viewport`	`vw,vh` or `vw,vh,sx,sy,sw,sh`	Crop a source region and scale it to fit the viewport without distortion. Without it the image keeps its own size.	400 if ill-formed
`window`	`center,width,function`	Window center and width, function `linear`, `linear-exact` or `sigmoid`. All three are required.	400 if missing or ill-formed, and not allowed on a presentation state
`iccprofile`	`no`, `yes`, `srgb`, `adobergb`, `rommrgb` or `displayp3`	Whether and which ICC profile is in the rendered image

The grayscale or color space of a rendered image is not defined by the standard, even if the pipeline works in P-Values. For a presentation state as target the viewport can only be `vw,vh`.

Status codes

DICOMweb uses ordinary HTTP status codes. These are the ones the transactions use most.

Code	Meaning in DICOMweb	Where
`200` OK	All representations are in the payload. For a search with no matches: an empty list. A store where every instance was stored.	Search, Retrieve, Store
`201` Created	One or more new resources were created.	Create
`202` Accepted	The request was accepted but not completed, or for a store only some instances were stored and others have warnings or failures.	Store
`204` No Content	Success without a payload, for example a conditional retrieve that is not modified.	Various
`304` Not Modified	A conditional request found the cached copy up to date.	Capabilities
`400` Bad Request	Bad syntax, an invalid query parameter value, or an invalid header.	All
`401` Unauthorized	No valid credentials. The server sends a WWW-Authenticate header.	All
`403` Forbidden	Understood but refused, for example insufficient privileges. A server may use 404 instead.	All
`404` Not Found	The target resource does not exist, or the server does not disclose that it does.	Retrieve
`405` Method Not Allowed	The method is not supported by the resource. The response has an Allow header.	All
`406` Not Acceptable	No representation matches the Accept header or query parameter.	Retrieve
`409` Conflict	Nothing could be stored because of a conflict: unsupported SOP Class, Study Instance UID mismatch.	Store
`410` Gone	The resource was deleted.	Retrieve
`413` Payload Too Large	A retrieved resource is too large to return, or a search was too broad.	Retrieve, Search
`415` Unsupported Media Type	The Content-Type of the request is not supported.	Store
`501` Not Implemented	Used for SOP Class not supported errors.	Various
`503` Service Unavailable	Temporary overload or maintenance.	All

A failure response should have a Status Report in the payload. The standard notes that policy may require a 404 in place of a 401 or 403 so that a client cannot infer that a resource exists.

DICOMweb next to DIMSE

The services map on each other, but not one to one.

DIMSE	DICOMweb	Difference
`C-FIND` (Study Root)	Search `GET /studies`, `/series`, `/instances`	Matching keys are query parameters, return keys are `includefield`. Paging has `limit` and `offset`. A search with no match returns 200.
`C-MOVE` / `C-GET`	Retrieve `GET /studies/{study}...`	No sub-association and no move destination: the data comes back in the HTTP response.
`C-STORE`	Store `POST /studies`	Many instances in one request, with a multipart body. The status is 200, 202 or 409.
Association negotiation (SOP Classes, transfer syntaxes)	Accept header, `transfer-syntax` parameter, Retrieve Capabilities	The client names the formats it accepts per request.
UPS `N-CREATE`, `N-GET`, `N-SET`, `N-ACTION`, `N-EVENT-REPORT`	UPS-RS: Create, Retrieve, Update, Change State, Request Cancellation, Subscribe; notifications over a WebSocket connection	A workitem is a UPS instance and the worklist is a single collection per service.
Status codes such as `FF00`, `0000`, `A700`	HTTP status codes plus a Warning header	A DICOM status code can be carried in the Warning header text.

WADO-URI: the older single-instance service

The URI Service retrieves one composite instance with one GET. The resource is identified by query parameters, not by a path.

Parameter	Value	Meaning
`requestType`	`WADO`	Required. Anything else the server does not support gives 400.
`studyUID`	A UID	Required, the Study Instance UID.
`seriesUID`	A UID	Required, the Series Instance UID.
`objectUID`	A UID	Required, the SOP Instance UID.
`contentType`	`application/dicom` or a rendered media type	Optional. Transfer-syntax and charset media type parameters are forbidden and give 400.
`charset`	A character set	Optional.

Without a `contentType` and with an Accept header of `*/*` the response defaults to `image/jpeg`, a rendered instance. The URI Service retrieves only single instances and is more limited than the Retrieve Transaction of the Studies Service.

UPS-RS: the Worklist Service

The Worklist Service manages one worklist per service, holding workitems.

Transaction	Method	URL	DIMSE counterpart
Create	`POST`	`/workitems?{workitem}`	N-CREATE
Retrieve	`GET`	`/workitems/{workitem}`	N-GET
Update	`POST`	`/workitems/{workitem}?{TransactionUid}`	N-SET
Change State	`PUT`	`/workitems/{workitem}/state?requester={aetitle}`	N-ACTION
Request Cancellation	`POST`	`/workitems/{workitem}/cancelrequest?requester={aetitle}`	N-ACTION
Search	`GET`	`/workitems` with `match`, `includefield`, `fuzzymatching`, `offset` and `limit`	C-FIND
Subscribe	`POST`	`/workitems/{resource}/subscribers/{subscriber}`, with optional `deletionlock` and `filter`	N-ACTION
Unsubscribe	`DELETE`	The subscription resource	N-ACTION

The workitem UID goes in a query parameter of the Create request, where DIMSE uses the Affected SOP Instance UID. Notifications correspond to N-EVENT-REPORT. The client opens a WebSocket notification connection with `GET /subscribers/{requester}`, and the server sends the event reports over it.

Glossary

Origin server: The server that holds the resources and answers requests. A DICOMweb PACS endpoint.
User agent: The client that sends the request: a viewer, a scanner, an importer.
Resource: Something with a URL, such as a study, a series, an instance or a frame.
Representation: One encoding of a resource, chosen with a media type.
Multipart payload: A body with several parts, each with its own Content-Type and Content-Location, used for instances, frames and bulk data.
Bulk data: Large values in a data set, such as pixel data, that can be retrieved separately by a URI.
Native / proxy: A server that stores DICOM itself, or one that converts web requests into DIMSE requests for another system.
Workitem: One procedure step in the UPS worklist, called a UPS instance in DIMSE.

Summary

Search, Retrieve and Store are GET /studies..., GET /studies/{study}/... and POST /studies: QIDO-RS, WADO-RS and STOW-RS.
Search keys are query parameters, with includefield, limit, offset and fuzzymatching as extras.
application/dicom+json is the default for search and metadata. Instances and bulk data come in multipart/related.
A rendered image is GET .../rendered and defaults to image/jpeg for a single frame image.
A search with no matches returns 200 with an empty list. 202 on a store means only part of it was stored.
Implicit VR Little Endian is not allowed in web services. The default uncompressed transfer syntax is Explicit VR Little Endian.

Why a DICOMweb call fails

IntermediateOpen on its own page →

Filter the tables

48 rows

Start from the status code

What each common code means for the transaction you called, and the first thing to check.

Code	Transaction	What it means	First check
`400`	Any	Bad syntax, or a supported query parameter with an invalid value, or a bad header.	Query string syntax, percent-encoding, a `window` parameter missing a part, `quality` outside 1 to 100.
`401` / `403`	Any	No valid credentials, or not allowed. A server can answer 404 instead, so as not to reveal that the resource exists.	The token or login, and the rights for that study. Do not read a 404 as proof that the study is absent.
`404`	Retrieve	The target resource does not exist, or the server does not say that it does.	The UIDs in the URL, the base path, and whether the instance was moved.
`405`	Any	The method is not supported by that resource. The response lists the allowed methods in an `Allow` header.	Using `POST` on a search or `GET` on a store.
`406`	Retrieve, Search	None of the media types you accepted can be supplied.	The `Accept` header, the `type=` and `transfer-syntax=` parameters, and single part media types on a multi-item resource.
`409`	Store	Nothing was stored because of a conflict: an unsupported SOP Class or a Study Instance UID that does not match the URL.	The SOP Classes the server supports, and whether you posted to `/studies/{study}` with another study in the body.
`202`	Store	Some instances were stored, others have warnings or failures.	The response body and the `Warning` header for the failing instances.
`410`	Retrieve	The resource was deleted.	A cached link to a study that was removed.
`413`	Retrieve, Search	The resource is too large to return, or the search was too broad.	Add match keys, use `limit` and `offset`, or request frames instead of the whole instance.
`415`	Store	The server does not accept the `Content-Type` of the request.	The `Content-Type` of your body: use `multipart/related; type="application/dicom"` or metadata plus bulk data parts.
`501`	Various	Used for a SOP Class that is not supported.	The SOP Classes in the conformance statement.
`503`	Any	Temporary overload or maintenance.	Retry later.

A search returned nothing, or too little

An empty result is not an error. Work through these in order.

Symptom	Likely cause	Rule behind it
`200` with `[]` for a study that exists	A key does not match: a wrong date or range, a name without a wild card, a modality in the wrong attribute.	Search uses the C-FIND matching rules. Names are literal unless fuzzy matching is supported.
Fewer studies than expected	The server paged the result: it returned the system limit, or your `limit`.	The response has `Warning: 299 ... There are <n> additional results that can be requested`. Ask again with `offset`.
Different pages overlap or skip a study	Studies were added or removed between the page requests.	The same request gives the same order only while the matches do not change.
`fuzzymatching=true` has no effect	The server does not support fuzzy matching.	It searches literally and adds `Warning: 299 ... The fuzzymatching parameter is not supported`.
A filter on an attribute is ignored	The server does not support that parameter or attribute. Unsupported parameters are ignored.	The server processes the request as if the parameter was not there, and may add a warning.
Series or instance attributes missing from a study search	Attributes of a lower level in `includefield` are not returned at study level.	Series or Instance level attributes in `includefield` are not returned for studies.
A series search returns the study attributes too	You searched All Series or All Instances.	For those resources the response also includes the study level, and for All Instances the series level, attributes.
Old systems return 204 for no match	The server follows an earlier release of the standard.	The current text specifies 200 with an empty payload. A client should accept both.

How the server chooses the media type

The Selected Media Type is picked per part and per resource category. Knowing the order explains most 406 answers.

Step	What the server does
1	Identify the resource category of the target: single frame image, multi-frame image, video, text, or other.
2	Take the highest priority media type that it supports, for that category, from the Accept query parameter (WADO-URI `contentType`).
3	If none is supported, take the highest priority supported media type from the Accept header.
4	If the Accept header has a wildcard range that matches the category, use the default media type of the category.
5	Otherwise answer 406 Not Acceptable.

Priority comes from q values (1 when absent), taken from the most specific matching media range. Two cases that surprise: asking for a rendered study with only single part media types in the Accept header gives 406, even for a study with one frame; and 406 is also the answer when the pixels would be too long for the Explicit VR Little Endian transfer syntax.

Media type and transfer syntax mistakes

Common mistakes when a retrieve or store fails or returns an unexpected format.

Mistake	What happens	Rule
Several `transfer-syntax` values in one media type	An invalid header.	A media type may have only one transfer-syntax parameter with one value. Offer a choice as several media types with q values.
Asking for Implicit VR Little Endian	It is not available.	Implicit VR Little Endian and Explicit VR Big Endian must not be used with web services.
No `transfer-syntax` parameter	You get the default.	Explicit VR Little Endian for the instance categories, unless the server has only lossy pixels or pixels too long for it.
`transfer-syntax=*`	The server returns what it stores.	The wildcard lets the server skip transcoding.
Single part `application/dicom` for a series	The server ignores it, and returns 406 if nothing else remains.	Single part media types are only for a resource that is one item.
Quotes around `type=` in `multipart/related`	Some servers reject quotes, others reject their absence.	The standard allows both, and notes that servers differ. A client can try the other form on failure.
`transfer-syntax` or `charset` in a WADO-URI request	`400`	They are forbidden in URI Service requests. WADO-URI uses a query parameter instead.
Posting a PNG or GIF as pixel data	The server transforms it into an uncompressed or lossless form, and drops transparency or an alpha channel.	PNG and GIF are transformed. JPEG, JPEG 2000, JPEG XL and MPEG are kept unchanged, without further lossy compression.

Reading a multipart response

Retrieve and store payloads of several items are `multipart/related`.

Part header	Meaning	Tip
`Content-Type` of the message	`multipart/related; type="..."; boundary=...`. The `type` is the media type of the root part.	Read the boundary from this header, not by guessing.
`Content-Type` of a part	The single part media type of that item, with its transfer syntax parameter.	Each part is chosen separately, so parts can differ.
`Content-Location` of a part	Identifies the resource in that part: a frame, an instance, a bulk data URI.	This is how you match frames to numbers and bulk data to the metadata.
Order of parts	Metadata parts that reference bulk data come before the bulk data part. The root is the first part unless `start` says otherwise.	Do not assume bulk data comes first.

Warning headers

A 200 can still carry a warning. The standard uses the HTTP `Warning` header with code 299.

Warning text	When
`299 <service>: There are <n> additional results that can be requested`	A search had more matches than were returned.
`299 <service>: The fuzzymatching parameter is not supported. Only literal matching has been performed.`	You asked for fuzzy matching and the server cannot do it.
`299 <service>: The emptyvaluematching parameter is not supported. Empty Value Matching has not been performed.`	You asked for empty value matching and the server cannot do it.
`299 <service>: The following annotation values are not supported: <values>`	You asked for annotations the renderer does not support.
`A700 <service>: Out of memory` (example)	A store response may carry a DICOM status code and a reason in the Warning text.

A checklist before you blame the server

Check the request, then the conformance statement.

Check	Why
The base URI and the resource path	A web server may host several services under different base paths.
UIDs in the URL are not padded and have no whitespace	Query parameter values must not be padded to an even length.
Special characters are percent-encoded	`#`, `[`, `]`, `&`, `=` and `,` must be encoded in a query value, and non-ASCII characters too.
The Retrieve Capabilities response (`OPTIONS /`)	It describes the resources, media types and optional parameters that the server supports.
The conformance statement	It lists the resources, media types, optional parameters, maximum number of matches, and whether the server is native or a proxy.
A proxy in front of a DIMSE server	A proxy has fewer mandatory search resources, and behavior may follow the DIMSE side.

Glossary

Status Report: A payload that explains a failure or warning. A failure response should have one.
Warning header: An HTTP header that the server uses to flag something on an otherwise successful response, with code 299 for DICOMweb warnings.
Accept header: The request header that lists the media types the client accepts, with q values for preference.
Selected media type: The media type the server chose for the response, from the ones the client accepts.
Transfer syntax parameter: A media type parameter that names the DICOM transfer syntax of the pixel encoding that is wanted.
Boundary: The string that separates the parts of a multipart payload, declared in the Content-Type header.

Summary

Read the status code first: 400 the request, 406 the media type you can get, 415 the media type you sent, 409 a conflict on store, 404/410 the resource.
A search with no match is 200 with an empty list. Look at keys, paging and the Warning header.
Warning: 299 can come with a 200: more results, fuzzy matching not supported, empty value matching not supported.
The server chooses the media type per category from the Accept query parameter, then the Accept header, then a default.
Offer transfer syntax choices as several media types with q values, never several values in one.
A 404 can hide a permission problem. Policy may require it.

Worklist, MPPS and storage commitment

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 10

An order becomes a worklist entry

Key detail

What happens

A referring system sends an order to the RIS, as an HL7 ORM (or OMG in the HL7 v2.5.1 option of IHE). The RIS gives it an accession number, schedules a procedure step on a modality and stores it where the worklist service can read it.

Why it is needed

Worklist is the single source of truth about who is scheduled. Without it the technologist types the patient data by hand, and typing errors are the biggest cause of mismatched studies.

Technical details

HL7 ORM^O01 (or OMG^O19 in the IHE v2.5.1 option) in from the order placer
Accession number (0008,0050) created by the order filler
Scheduled Procedure Step: station, modality, date and time
Requested Procedure ID, Study Instance UID generated or reserved

All steps at a glance

Glossary

SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
Modality Worklist (MWL): A DICOM service where the modality asks the RIS which patients and procedures are scheduled for it, with a C-FIND.
MPPS: Modality Performed Procedure Step. A DICOM object, created with N-CREATE and updated with N-SET, that reports the start and the end of an exam.
Storage Commitment: A service in which the modality asks a PACS to confirm that listed images are safely stored, with N-ACTION and N-EVENT-REPORT.
DIMSE-N: The "normalized" services: N-CREATE, N-SET, N-GET, N-ACTION, N-DELETE and N-EVENT-REPORT. They work on a managed object, unlike the C- services.
Accession number: The unique ID of one imaging request. It links an image study to its order and report.

Summary

Worklist is a C-FIND on SOP Class 1.2.840.10008.5.1.4.31. It gives the modality the patient and order data so nobody has to type it.
MPPS is N-CREATE (IN PROGRESS) then N-SET (COMPLETED or DISCONTINUED). It tells RIS and PACS what the modality did.
The images travel with C-STORE. The PACS matches them with the order through StudyInstanceUID and AccessionNumber.
Storage Commitment is N-ACTION from the modality and N-EVENT-REPORT from the PACS. It means "safely stored", which is stronger than a C-STORE success.
Most failed exams with the wrong patient or accession number come from skipping the worklist: the data was typed, not selected.

Worklist queries: keys, matching and empty lists

IntermediateOpen on its own page →

Filter the tables

58 rows

How the request and responses work

The Basic Worklist Management Service Class uses only C-FIND, on a single query level. There is no Patient, Study, Series and Image hierarchy as in Query/Retrieve.

Part	What it is	Rule
SOP Class	`1.2.840.10008.5.1.4.31`, Modality Worklist Information Model - FIND	Chosen by the Abstract Syntax of the presentation context. It names the information model for the query.
Matching keys	Attributes with a value, such as the Modality or a date range	The SCP returns only worklist items that match all keys given. An SCU may send any subset of the required matching keys.
Return keys	Attributes sent with zero length	The SCP fills in the values it knows. Every matching key is also returned.
Scheduled Procedure Step Sequence	`(0040,0100)`	The attributes of the step are only retrieved through sequence matching, and the sequence holds a single item.
One match	One Scheduled Procedure Step, with its Requested Procedure, request, visit and patient	One Pending response per step. A step appears in only one response. Patient and procedure data repeat across responses.
A query with no matching keys	An Identifier with only return keys	There are no matches: the SCP returns Success with no Identifier.
End of the list	A response with status Success	No Identifier. When nothing matches, this is the only response.

The worklist only carries information to the modality. The Modality Worklist SOP Class does not send anything back to the information system; progress is reported with MPPS, which is a separate service.

The required matching keys

An SCP must support matching on every required key below. The matching type column says how the key may be matched.

Key	Tag	Matching	Why it matters
Scheduled Station AE Title	`(0040,0001)`	Single value only	Selects the steps booked for this one device. A different AE title returns nothing.
Scheduled Procedure Step Start Date	`(0040,0002)`	Single value or range	The usual way to ask for today, or a window of days.
Scheduled Procedure Step Start Time	`(0040,0003)`	Single value or range	Narrows the date to a time of day. See the range rules below.
Modality	`(0008,0060)`	Single value only	The kind of device, such as `CT` or `MR`. Must equal the value the order system booked.
Scheduled Performing Physician's Name	`(0040,0006)`	Single value or wild card	Limits the list to one physician.
Patient's Name	`(0010,0010)`	Single value or wild card	Finds one patient by name.
Patient ID	`(0010,0020)`	Single value only	Finds one patient by identifier.

The standard also lists optional matching keys, for example the Scheduled Procedure Step Description, Accession Number and Requested Procedure ID. An SCP that does not support one ignores it for matching and treats it as a return key. The conformance statement says which it supports.

The IHE query combinations (RAD-5)

IHE narrows what a modality has to be able to ask. An Acquisition Modality supports at least one of two query types, and an Importer supports the patient-based query.

Query	Keys the SCU supports	Typical use
Patient based query	Patient's Name, Patient ID, Accession Number, Requested Procedure ID. All 15 combinations of one or more keys.	The technologist scans the wristband or types the patient, and the list shows that patient's steps.
Broad query	Scheduled Procedure Step Start Date, Modality, Scheduled Station AE Title. All 7 combinations of one or more keys.	The modality shows everything scheduled for it today: Modality plus date, or its own AE title.

In IHE the SCP matches Accession Number and Requested Procedure ID with single value matching. IHE also recommends adding a wild card at the end of each component of a structured Patient Name when the user did not type one.

What comes back (return keys)

The Type column is the DICOM return key type: 1 must have a value, 2 must be present but may be empty, 1C and 2C are required under a condition, 3 is optional.

Attribute	Tag	Type	Remark
Study Instance UID	`(0020,000D)`	1	The UID the modality puts in the images. This is what ties the images to the order.
Accession Number	`(0008,0050)`	2	IHE: a non-empty value must be returned when the SCU asked for it.
Requested Procedure ID	`(0040,1001)`	1	Identifies the requested procedure that the step belongs to.
Scheduled Procedure Step ID	`(0040,0009)`	1	Identifies the step itself.
Scheduled Procedure Step Description or Scheduled Protocol Code Sequence	`(0040,0007)`, `(0040,0008)`	1C	The SCP must support one or both. Coded values say exactly what to do at the modality.
Requested Procedure Description or Code Sequence	`(0032,1060)`, `(0032,1064)`	1C	The SCP must support one or both. The code sequence holds a single item.
Referenced Study Sequence	`(0008,1110)`	2	IHE: one item per step, and its Referenced SOP Instance UID is the same value as the Study Instance UID.
Patient's Birth Date, Patient's Sex	`(0010,0030)`, `(0010,0040)`	2	Used to check the right patient is on the table.
Referring Physician's Name	`(0008,0090)`	2	Copied into the image header.
Requested Procedure Priority	`(0040,1003)`	2	Shows the urgency to the operator.
Admission ID, Current Patient Location	`(0038,0010)`, `(0038,0300)`	2	Visit information.
Scheduled Procedure Step Status	`(0040,0020)`	3	Optional. A modality cannot count on receiving it.
Requested Contrast Agent, Pre-Medication	`(0032,1070)`, `(0040,0012)`	2C	Present when contrast or pre-medication applies to the step.

Type 3 return keys are only returned if the SCP lists them in its conformance statement. For the sequence, IHE requires the SCP to accept three ways of asking: a zero-length sequence, a sequence with one empty item, or zero-length values for selected attributes inside the item.

How each type of matching works

Matching is defined in PS3.4 Annex C and applied key by key. The worklist model says which type each required key may use.

Type	Rule	Example
Single value	The value must be equal. Dates and times are compared by meaning, not as text.	`Modality = CT`; the time `2230` matches `223000`.
Wild card	`*` matches any run of characters, including none. `?` matches exactly one character. Only for names, strings and similar VRs.	`Patient's Name = DOE`. A single `` is the same as universal matching.
Range	For dates, times and date-times: `a-b` between both, `-b` up to and including, `a-` from and including. It is always matched by meaning.	`Start Date = 20260315-20260317`.
Universal	A zero-length value. It matches everything and asks for the value back.	Every return key.
Sequence	The sequence holds one item whose keys are matched. The Scheduled Procedure Step Sequence is retrieved this way.	The item holds Modality, AE title and date.
List of UID	A backslash separated list of UIDs. Any one may match.	Not a required worklist key.

A value with more than one item matches when any item matches, and then all values are returned. An item with an unknown value (zero length) never matches a value you supply, but it can still be returned by a universal query.

Dates, times and time zones

Date and time matching causes many of the "wrong list" cases, so these rules are worth knowing.

Situation	What the standard says
Date range and time range together	The worklist model combines them into one period. A date range of July 5 to 7 with a time range of 10:00 to 18:00 means from July 5 at 10:00 until July 7 at 18:00, not 10:00 to 18:00 on each day. This differs from the general rule of Query/Retrieve, where the two are matched separately unless negotiated.
A time range on its own across midnight	A time range that crosses midnight is not supported. To cover a night shift, send a date range together with a time range, which is matched as one period.
Single value of a date or time	Matched by meaning. If another application might not do that, use a range with both values the same, which is always matched by meaning.
Time zone	Timezone Offset From UTC `(0008,0201)` is only included when times are to be read in a stated time zone. It is never matched itself.
Character set	Specific Character Set `(0008,0005)` is included when extended character sets may be used. It is never matched, and the SCP may answer in a different set.
Person names	Matched literally unless fuzzy matching is negotiated. The conformance statement says whether the SCP matches names case-insensitively.

Status values of the C-FIND

The statuses a worklist SCP can return.

Status	Code	Identifier	Meaning
Pending	`FF00`	Yes	One match follows. Optional keys were supported like required keys.
Pending, warning	`FF01`	Yes	One match follows, but one or more optional keys were not supported.
Success	`0000`	No	Matching is complete. When there were no matches this is the only response.
Cancel	`FE00`	No	Matching stopped because the SCU sent C-CANCEL-FIND. The SCU may still receive responses until the SCP has processed the cancel.
Refused: out of resources	`A700`	No	The SCP could not take the query now.
Error: data set does not match SOP class	`A900`	No	The Identifier does not fit the Modality Worklist model.
Failed: unable to process	`Cxxx`	No	Any code in this range. The SCP may use the digits to tell causes apart.

Why the worklist is empty or wrong

Each cause follows from a rule above. The first thing to check is what the modality actually sent in the query.

Symptom	Likely cause	Rule behind it
Empty list, the exam is booked	The Scheduled Station AE Title in the order differs from the AE title of the scanner (spelling, case or a different device).	AE title matches with single value matching only.
Empty list for one device type	The Modality code in the order differs from the one the scanner asks for, for example `DX` against `CR`.	Modality matches with single value matching only.
Yesterday's or tomorrow's exams missing	The query date is today only, or the order is booked on another date.	The start date is matched by date or range.
Night shift exams missing	A time range alone was used for a shift that crosses midnight.	A time range on its own cannot cross midnight. A date range plus a time range is matched as one period.
Patient not found by name	The name was sent without a wild card, with other case, or in a different component order.	Names match literally unless fuzzy matching or case-insensitive matching is supported.
Entry exists but never matches a key	The worklist item has an empty value for the key you query on.	An unknown (zero-length) value fails to match any supplied value.
A filter on the scanner has no effect	The key you sent is an optional key that the server does not support. It is ignored for matching.	Unsupported optional keys are treated as return keys; the server may answer `FF01`.
Right entries but garbled names	Character set mismatch between scanner and server.	The SCP may answer in a different Specific Character Set than requested.
Nothing arrives at all	The order never became a Scheduled Procedure Step in the worklist server, or the association was refused.	The worklist is built from the order. See the HL7 mapping lesson. A refused association shows in the A-ASSOCIATE-RJ.
Scanner shows no accession number	The server returned the key empty or the scanner did not request it.	Accession Number is a return key of type 2. IHE requires a value when it is requested.

Glossary

SCU / SCP: Service Class User and Provider. For a worklist the scanner is the SCU that asks, and the worklist server is the SCP that answers.
Scheduled Procedure Step: One unit of work for a device, such as a CT scan booked for a time. It is the entry point of the Modality Worklist.
Requested Procedure: The procedure ordered for the patient. One requested procedure can be split into several scheduled steps.
Matching key: An attribute with a value in the request. Only items that match all keys are returned.
Return key: An attribute sent with zero length to ask for its value.
Universal matching: A zero-length value. It matches everything and is how return keys are requested.
Scheduled Station AE Title: The AE title of the device the step is booked on. It links an order to one scanner.
MPPS: Modality Performed Procedure Step. The service the scanner uses to report progress back, which a worklist cannot do.

Summary

A worklist query is a C-FIND on 1.2.840.10008.5.1.4.31, with a single query level and one Scheduled Procedure Step per response.
The required matching keys are the Scheduled Station AE Title, start date and time, Modality, the performing physician, Patient's Name and Patient ID.
The AE title, Modality and Patient ID are matched with single value matching only, so they must be exact.
Dates take single value or range matching. A date range and a time range together form one period, and a time range alone cannot cross midnight.
Pending (FF00 or FF01) responses carry one match each. The final 0000 has no Identifier, and with no matches it is the only response.
IHE requires modalities to support a patient based query and a broad query, and requires a non-empty Accession Number when it is requested.
When a list is empty, compare the query with the order: AE title, Modality and date first.

Storage commitment in depth

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 8

The images are sent first

Core step

What happens

The Push Model is meant for senders that decide for themselves when the SOP Instances are transmitted. The SCU sends them by whatever suitable mechanism, normally C-STORE, and asks for commitment afterwards for a list of references to them.

Why it is needed

Commitment is a separate step from the store. A C-STORE status of 0000 means the instance was received and handled; only commitment is the promise to keep it safe.

Technical details

Storage Commitment Push Model SOP Class 1.2.840.10008.1.20.1
The images travel as in the C-STORE lesson
SCU/SCP role selection negotiation is mandatory for this service class
SOP Class extended negotiation shall not be supported

All steps at a glance

Glossary

Storage commitment: An explicit promise from a PACS that it has stored listed SOP Instances safely. It is stronger than a C-STORE success, which only means received.
Push Model: The storage commitment model in which the SCU decides when it sends the instances and then asks for commitment.
Transaction UID: A UID in the N-ACTION (0008,1195) that identifies one commitment request. The result carries the same one. It is used once.
N-ACTION: The DIMSE-N command that asks the peer to perform an action. Here it carries the request, with Action Type ID 1.
N-EVENT-REPORT: The DIMSE-N command that reports an event to the peer. Here it carries the commitment result from the PACS to the modality.
Role selection: A part of association negotiation in which an association requestor proposes to act as SCU, SCP or both for a SOP Class. It lets the PACS send the N-EVENT-REPORT on an association that it opened itself.
Failure reason: A code (0008,1197) per failed instance in a type 2 report, such as 0112 no such object instance or 0213 resource limitation.

Summary

Storage commitment is two steps: an N-ACTION request from the sender, and an N-EVENT-REPORT result from the PACS. A C-STORE success is not commitment.
The request names the instances in ReferencedSOPSequence and carries a new Transaction UID. The result carries the same one, and it is used once.
The N-ACTION-RSP only says the request was received. Event type 1 is full success. Event type 2 lists the failed instances with a FailureReason.
The result can arrive on a different association, opened by the PACS. The modality must accept inbound connections and the PACS must know its AE title, IP address and port.
What happens next (deleting, resending, timeouts) is not defined by the standard. It is in the sender's Conformance Statement.

Radiology reporting workflow (IHE)

IntermediateOpen on its own page →

DICOM
HL7 v2
Internal action

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 8

The radiologist authors the report

Core step

What happens

The radiologist reads the images and the Report Creator turns the findings into a DICOM Structured Report. IHE requires at least a Basic Text SR. If the report has numeric values, such as measurements, it has to be an Enhanced SR. How the creator obtains the content (typing, dictation, templates) is outside the IHE profile.

Why it is needed

A structured object is what lets the report be stored, versioned, queried and linked to the images, which plain text cannot do. The report is tied to its study through the Study Instance UID, and a report on several studies is copied into each one.

Technical details

Basic Text SR Storage 1.2.840.10008.5.1.4.1.1.88.11
Enhanced SR Storage 1.2.840.10008.5.1.4.1.1.88.22 (when numeric values are needed)
Content follows the DICOM template TID 2000, with coded entries from the DICOM Content Mapping Resource (PS3.16)
Recommended: the SR uses the Study Instance UID of the images reported on
Several studies in one report: one copy per study, each with a different SOP Instance UID and an Identical Documents Sequence (0040,A525)

All steps at a glance

Glossary

DICOM Structured Report (SR): A DICOM object that holds a report as structured content: text sections, coded entries, measurements and references to images. It is stored, queried and retrieved like any other DICOM object.
Report Creator: The IHE role that authors the report, usually the reading workstation. It sends the SR to the Report Manager.
Report Manager: The IHE role that owns the state of reports: it completes, verifies, amends and issues them, and exports verified ones to the enterprise.
Report Repository: The IHE role that stores issued SRs and answers queries for them.
Report Reader: The IHE role that queries for reports and retrieves them for viewing.
Completion Flag and Verification Flag: Two attributes of an SR, (0040,A491) and (0040,A493). A final report is COMPLETE and VERIFIED; any other combination is a draft.
Predecessor Documents Sequence: The SR attribute (0040,A360) that lists the earlier reports a new report is based on. It makes the version history followable.
ORU^R01: The HL7 v2 message for an unsolicited observation result. It is how a verified report reaches the hospital record.

Summary

In IHE the report is a DICOM Structured Report: Basic Text SR at minimum, Enhanced SR when it has measurements. It uses the template TID 2000.
A final report has the Completion Flag COMPLETE and the Verification Flag VERIFIED. Anything else is a draft.
Changes never edit a report in place. Each change creates a new SR with a new SOP Instance UID that points to its predecessor.
The transactions are RAD-24 submission (C-STORE), RAD-25 issuing (C-STORE), RAD-26 query (C-FIND), RAD-27 retrieve (C-MOVE or C-GET) and RAD-28 export (HL7 ORU^R01).
Only verified reports are exported to the hospital record, as plain text with result status F.

DICOM Structured Reports as radiology reports

IntermediateOpen on its own page →

Filter the tables

34 rows

The IHE reporting transactions

Five transactions cover the life of a report. Four are DICOM and one is HL7.

Transaction	From and to	Service	What happens
RAD-24 Report Submission	Report Creator to Report Manager	`C-STORE`	The creator sends the SR as a draft or final report. After storage it no longer changes that object.
RAD-25 Report Issuing	Report Manager to Report Repository	`C-STORE`	The manager sends unchanged drafts, new modified reports, or both. Sending drafts can be configured.
RAD-26 Query Reports	Report Reader to Report Repository, Report Manager or an external repository	`C-FIND`	Study Root, optionally Patient Root. Matches on the usual keys and on SR keys such as the flags.
RAD-27 Retrieve Reports	Repository, manager or an imaging document source to Report Reader	`C-MOVE` or `C-GET`, `C-STORE`	The selected SR is sent to the reader for viewing.
RAD-28 Structured Report Export	Report Manager to Enterprise Report Repository	HL7 `ORU^R01`	A verified report goes out as an unsolicited HL7 result, as plain text.

The SR SOP Classes

The SR Storage SOP Classes of PS3.4. IHE needs the first for every report and the second when a report has numeric values.

SOP Class	UID	IOD	In radiology reporting
Basic Text SR Storage	`1.2.840.10008.5.1.4.1.1.88.11`	Basic Text SR	The minimum. Report Creator, Report Manager and Report Repository must all handle it.
Enhanced SR Storage	`1.2.840.10008.5.1.4.1.1.88.22`	Enhanced SR	When the report has numeric values such as measurements. A Report Manager that can receive it must also be able to manage and create it.
Comprehensive SR Storage	`1.2.840.10008.5.1.4.1.1.88.33`	Comprehensive SR	Defined in PS3.4. The IHE reporting transactions are written for Basic Text SR and Enhanced SR.
Comprehensive 3D SR Storage	`1.2.840.10008.5.1.4.1.1.88.34`	Comprehensive 3D SR	Defined in PS3.4. Not used by the IHE reporting transactions.

Reports created in the IHE profile follow the DICOM template TID 2000 and use coded entries from the DICOM Content Mapping Resource (PS3.16). All reporting actors must be able to load configurable code tables. The Report Manager and Report Repository must support Level 2 (Full) storage: all Type 1, 2 and 3 attributes are stored.

Draft, complete and verified

The state of a report is carried by two attributes of the SR and by who verified it.

Attribute	Tag	Meaning	Changed by
Completion Flag	`(0040,A491)`	`COMPLETE` when the report content is complete. Any other value means the report is still partial.	The Report Manager, when it completes a partial report by adding content.
Verification Flag	`(0040,A493)`	`VERIFIED` when the content has been checked for correctness. Any other value means it has not been verified.	The Report Manager, when verifying. The Verifying Observer Sequence is then filled in.
Verifying Observer Sequence	`(0040,A073)`	Who verified the report: organization, date and time, name and an identification code.	The Report Manager, at verification.

A final report is one with the Completion Flag COMPLETE and the Verification Flag VERIFIED. Reports with any other values are considered draft reports.

Attributes that tie a report together

How a report is linked to its study, its order, its images and its versions.

Attribute	Tag	Purpose
Study Instance UID	`(0020,000D)`	The study the report belongs to. IHE recommends the Study Instance UID of the images reported on.
Referenced Request Sequence	`(0040,A370)`	The order behind the report: Study Instance UID, Accession Number `(0008,0050)`, Requested Procedure ID `(0040,1001)`, Requested Procedure Code Sequence `(0032,1064)`, and Placer and Filler Order Number `(0040,2016)`, `(0040,2017)`.
Current Requested Procedure Evidence Sequence	`(0040,A375)`	References to the images and objects the report is based on, for the procedure being reported.
Pertinent Other Evidence Sequence	`(0040,A385)`	References to other studies the report refers to, such as priors.
Retrieve AE Title	`(0008,0054)`	In a reference, the AE title where the referenced object can be retrieved. Optional for a creator; a manager may fill in the AE title of a configured image manager.
Predecessor Documents Sequence	`(0040,A360)`	The earlier reports a new report is based on. It carries the version history.
Identical Documents Sequence	`(0040,A525)`	The other copies of the same report in other studies. The Retrieve AE Title is not sent in these items.
Concept Name Code Sequence	`(0040,A043)`	The code of the document title, which tells what kind of report it is.
Content Date and Time, Observation DateTime	`(0008,0023)`, `(0008,0033)`, `(0040,A032)`	When the content was created or observed. Exported as the HL7 observation date and time.

Changing a report

Reports are never edited in place. These are the rules that apply.

Situation	What happens
Any change of content	PS3.4 Annex O.3: the changed SR gets a new SOP Instance UID if an attribute of the SR Document General or SR Document Content module is added, removed or updated, or if the Series or Study Instance UID is changed.
Complete or verify	The Report Manager creates a new report with the flag set (and the Verifying Observer filled in). It is in a different series than the original, unless creator and manager are the same device, and points back with the Predecessor Documents Sequence.
Amendment	IHE recommends a new SR that contains the original content plus the amendments, with the Predecessor Documents Sequence referring to the original.
Merging reports	A new report built from several earlier ones. If a Basic Text SR is merged with an Enhanced SR, the result is an Enhanced SR.
Adding measurements	A Basic Text SR becomes an Enhanced SR. If numeric values are removed, the manager may convert an Enhanced SR to a Basic Text SR.
Patient data changes	The Report Manager can generate a new version of a report with updated demographics after a Patient Update.
One report, several studies	One copy per study, each with its own SOP Instance UID and the same content, and an Identical Documents Sequence that lists the other copies in each.

Query keys for reports

The SR-specific keys IHE requires, in addition to the usual Study Root keys, when a reader queries for reports.

Key	Tag	Use
Completion Flag	`(0040,A491)`	Ask for complete or partial reports.
Verification Flag	`(0040,A493)`	Ask for verified reports only, or for drafts.
Verifying Observer: name, date and time	`(0040,A075)`, `(0040,A030)`	Who verified it and when.
Concept Name Code Sequence	`(0040,A043)`	The report title code.
Referenced Request Sequence	`(0040,A370)`	Match on the Accession Number or Requested Procedure ID of the order.
Content Date and Time, Observation DateTime	`(0008,0023)`, `(0008,0033)`, `(0040,A032)`	Optional matching keys. The repository returns them.

Glossary

SR (Structured Report): A DICOM document type that holds structured content, with a content tree of text, codes, measurements and references to images.
SOP Instance UID: The unique ID of one report. A changed report gets a new one.
Draft and final report: A final report has the Completion Flag COMPLETE and the Verification Flag VERIFIED. All others are drafts.
Evidence sequence: An SR list of the images and other objects the report is based on. They let a viewer open the images next to the report.
Predecessor: An earlier version of a report that a new report is based on.
Template TID 2000: A DICOM content template for diagnostic imaging reports, from the Content Mapping Resource (PS3.16). IHE uses it for the reports of its profile.

Summary

IHE reports are DICOM SRs: Basic Text SR at minimum, Enhanced SR when numeric values are needed.
Final means Completion Flag COMPLETE and Verification Flag VERIFIED. Anything else is a draft.
A changed report gets a new SOP Instance UID and points to its predecessor with (0040,A360). Nothing is edited in place.
The report links to the study by Study Instance UID, to the order with the Referenced Request Sequence, and to the images with the evidence sequences.
Reports are queried by the flags, the title code and the order references, and stored with Level 2 (Full) storage.

Sending the report to the EHR (HL7 ORU)

IntermediateOpen on its own page →

Filter the tables

28 rows

The message

One ORU^R01 per request in the SR. Only verified, final reports are exported.

Item	IHE RAD-28
Trigger	The Report Manager has verified and finalized a DICOM Structured Report. It then sends an unsolicited ORU.
Message type	`MSH-9` = `ORU^R01`, HL7 v2.3.1 chapter 7.
Segments	`MSH`, `PID`, optional `PV1`, `OBR`, and one or more `OBX`.
PV1	Required when the region or country requires the visit number in `PV1-19`.
Several requests in one SR	If the SR has several items in its Referenced Request Sequence, a separate ORU is generated for each item.
Report text	Plain ASCII. The Report Manager renders the SR consistent with its content and the limits of ASCII. Special formatting characters are avoided and spaces are used for column alignment, because tab characters may not be valid at the final display device.
Acknowledgement	Each message is acknowledged with an HL7 ACK.

MSH, PID and PV1: the patient and the message

Required fields and where the DICOM values come from.

HL7 field	Name	DICOM source	Notes
`MSH-18`	Character Set	Specific Character Set `(0008,0005)`	Conditional.
`PID-3`	Patient Identifier List	Patient ID `(0010,0020)`	Required.
`PID-5`	Patient Name	Patient's Name `(0010,0010)`	Required.
`PID-7`	Date/Time of Birth	Patient's Birth Date `(0010,0030)`	Required if known.
`PID-8`	Sex	Patient's Sex `(0010,0040)`	Required if known.
`PID-10`	Race	Ethnic Group `(0010,2160)`	Required if known.
`PID-18`	Patient Account Number	Not in the SR	The Report Manager supplies it. At least one of `PID-18` and `PV1-19` has to be valued.
`PV1-2`, `PV1-19`, `PV1-51`	Patient Class, Visit Number, Visit Indicator	Not in the SR	`PV1-19` is conditional. `PV1-51` is `V` when the visit number is present.

The other required MSH fields (sending and receiving application and facility, message control ID, processing ID, version ID) are filled in by the sender as for any HL7 message.

OBR: the order and the result status

Fields of the OBR segment that tie the result to the order.

HL7 field	Name	DICOM source	Notes
`OBR-1`	Set ID	None	One OBR per ORU.
`OBR-2`	Placer Order Number	Referenced Request Sequence: Placer Order Number `(0040,2016)`	If the SR does not have it, the Report Manager is assumed to know it.
`OBR-3`	Filler Order Number	Referenced Request Sequence: Filler Order Number `(0040,2017)`	If the SR does not have it, the Report Manager is assumed to know it.
`OBR-4`	Universal Service ID	Not in the SR	The Report Manager supplies the Universal Service ID of the original order.
`OBR-7`	Observation Date/Time	Observation DateTime `(0040,A032)`, otherwise Content Date `(0008,0023)` and Content Time `(0008,0033)`	Required.
`OBR-25`	Result Status	Fixed value `F`	Final result. Only final reports are exported.
`OBR-32`	Principal Results Interpreter	The Person Observer Name `(0040,A123)` of the content item related to the root with HAS OBS CONTEXT and concept (121008, DCM, "Person Observer Name")	Optional.

OBX: the UIDs, the image references and the text

The OBX segments come in three groups. All have the result status `F` in OBX-11, and no context is assumed between OBX segments.

Group	OBX-2 value type	OBX-3 identifier	OBX-5 value	Notes
First OBX	`HD`	`^SR Instance UID`	The SR SOP Instance UID `(0008,0018)`	Always present, Set ID 1.
Each image content item: Study UID	`HD`	`^Study Instance UID`	Study Instance UID `(0020,000D)` from the matching evidence item	The content item only has the SOP Class and SOP Instance UID. Study and Series UID are found in the Current Requested Procedure Evidence or Pertinent Other Evidence Sequence, matched on the SOP Instance UID.
Each image content item: Series UID	`HD`	`^Series Instance UID`	Series Instance UID `(0020,000E)` from the matching evidence item	Same four OBX share one Observation Sub-ID in `OBX-4`, starting at 1 and increasing for each image.
Each image content item: SOP Instance UID	`HD`	`^SOP Instance UID`	Referenced SOP Instance UID `(0008,1155)`	Lets the enterprise repository look up the referenced image.
Each image content item: SOP Class	`HD`	`^SOP Class ID`	Referenced SOP Class UID `(0008,1150)`	Completes the reference.
Report text	`TX`	`^SR Text`	The report text from the SR object	One or more OBX segments, in plain ASCII.

The four OBX segments of an image reference repeat for each IMAGE content item in the SR. The text OBX segments follow them.

Glossary

ORU^R01: The HL7 v2 message that reports an observation result. Unsolicited means it is sent without a query.
Enterprise Report Repository: The IHE role that receives the exported HL7 results, in practice the hospital record or its result store.
Result status: OBR-25 and OBX-11 say how final a result is. `F` means final.
OBX: The HL7 segment for one observation. A report is sent as several OBX segments: identifiers first, then text.
HD: The HL7 hierarchic designator value type, used here for UIDs.
Observation Sub-ID: OBX-4. Groups OBX segments that belong together, here the four OBX of one image reference.

Summary

RAD-28 sends each verified SR as an unsolicited ORU^R01 (HL7 v2.3.1): MSH, PID, optional PV1, OBR and OBX.
The patient fields come from the SR patient attributes. PID-18 (account number) and the Universal Service ID in OBR-4 come from the Report Manager.
OBR-2 and OBR-3 carry the placer and filler order numbers from the Referenced Request Sequence. OBR-25 is F.
The first OBX carries the SR Instance UID, four OBX per referenced image carry its UIDs, and TX OBX segments carry the report text.
The text is plain ASCII with no tabs, so it can be shown on any receiving system.

Reading a DICOM Conformance Statement

IntermediateOpen on its own page →

DICOM
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 9

Read the Overview of device A

Core step

What happens

Start at the Overview at the front of the statement. It lists, per service (Verification, Storage, Workflow Management, Query/Retrieve, Print, and the DICOM web services), the SOP Classes the product supports, whether it plays SCU, SCP or both, and the transfer syntaxes it supports.

Why it is needed

The Overview is meant as the first-level compatibility check. Sales and integrators use it to decide quickly whether two products could possibly fit before reading the details.

Technical details

Annex N layout: Overview, Table of contents, Introduction, Implementation Model, Service and Interoperability Description, Configuration, Network and Media Communication Details, then Security, IODs and further annexes
Overview: Content and Transfer (storage SOP Classes), DIMSE Services, DICOM Web Services, Media Services, Real-Time Video, De-identification, Character sets
Roles are listed per SOP Class: SCU, SCP, or both

All steps at a glance

Glossary

Conformance Statement: A document from the vendor, structured as defined in DICOM PS3.2 (template in Annex N), that lists what a product supports: SOP Classes, roles, transfer syntaxes and behavior.
AE / AE title: Application Entity: a DICOM application on a device. Its AE title (max 16 characters) is the name other devices use to address it.
SCU: Service Class User. The side that asks for a service, such as a scanner that wants to store images.
SCP: Service Class Provider. The side that provides the service, such as a PACS that stores images.
SOP Class: Service-Object Pair class. A UID naming one kind of object plus the service used on it, e.g. CT Image Storage (1.2.840.10008.5.1.4.1.1.2).
Transfer syntax: How a data set is encoded on the wire: byte order, explicit or implicit VR, and the image compression.
Presentation context: One SOP Class (abstract syntax) paired with the transfer syntaxes offered for it. Each gets an odd ID (1, 3, 5 ...).
Real-World Activity: In the application data flow diagram of a statement: something that happens outside DICOM, such as "technologist sends images", which triggers an AE to use a DICOM service.
Standard Extended SOP Class: A standard SOP Class with extra optional (Type 3) attributes. It keeps the standard UID, so other devices accept it and ignore the extras.
Private SOP Class: A SOP Class that is not in the DICOM Standard but published in a vendor's Conformance Statement. The other side must agree to it beforehand.
IHE integration statement: A vendor document listing which IHE profiles and actors a product supports. It complements the DICOM conformance statement and describes workflows.

Summary

A Conformance Statement follows the PS3.2 Annex N template: Overview, Implementation Model, Service and Interoperability Description, Configuration, Network and Media Communication Details.
The Overview gives a first-level comparison: SOP Classes, SCU or SCP role per class, and transfer syntaxes. Match roles per SOP Class.
Check the SOP Class type. Standard Extended classes interoperate; Specialized and Private classes need prior agreement on UID and content.
An AE that accepts any association must accept the Verification SOP Class (1.2.840.10008.1.1) as SCP, so a C-ECHO is always a valid first test.
The template's own Remarks say DICOM by itself does not guarantee interoperability. Configure AE titles, IP addresses and ports on both sides, then test the real workflows.

Query/Retrieve levels, keys and matching

IntermediateOpen on its own page →

Filter the tables

31 rows

The two information models

Each model has its own SOP Classes for FIND, MOVE and GET. The older Patient/Study Only model is retired. Study Root is common in practice.

Information model	Top level	Levels and their (0008,0052) value	FIND	MOVE	GET
Patient Root	Patient	`PATIENT`, `STUDY`, `SERIES`, `IMAGE`	`1.2.840.10008.5.1.4.1.2.1.1`	`1.2.840.10008.5.1.4.1.2.1.2`	`1.2.840.10008.5.1.4.1.2.1.3`
Study Root	Study	`STUDY`, `SERIES`, `IMAGE`	`1.2.840.10008.5.1.4.1.2.2.1`	`1.2.840.10008.5.1.4.1.2.2.2`	`1.2.840.10008.5.1.4.1.2.2.3`

In Study Root the patient attributes are treated as attributes of the study, so Patient's Name and Patient ID are required keys at the study level. The word IMAGE is historical: the level covers any composite object instance, not only images.

Levels, unique keys and required keys

One unique key identifies a single entity at its level. Required keys are keys every C-FIND SCP must be able to match on. All other attributes of the level are optional keys.

Level	Model	Unique key	Required keys
`PATIENT`	Patient Root only	Patient ID `(0010,0020)`	Patient's Name `(0010,0010)`
`STUDY`	Patient Root	Study Instance UID `(0020,000D)`	Study Date `(0008,0020)`, Study Time `(0008,0030)`, Accession Number `(0008,0050)`, Study ID `(0020,0010)`
`STUDY`	Study Root	Study Instance UID `(0020,000D)`	Study Date, Study Time, Accession Number, Study ID, plus Patient's Name `(0010,0010)` and Patient ID `(0010,0020)`
`SERIES`	Both	Series Instance UID `(0020,000E)`	Modality `(0008,0060)`, Series Number `(0020,0011)`
`IMAGE`	Both	SOP Instance UID `(0008,0018)`	Instance Number `(0020,0013)`

Patient ID may not be unique worldwide, but the Study Instance UID is, so no two studies can be mixed up. The scope of a Patient ID can be given with the Issuer of Patient ID (0010,0021), an optional key.

What the identifier must and must not contain

The rules for the baseline behaviour, which every SCU and SCP supports. "Above" means the levels higher in the hierarchy than the level named in (0008,0052).

Request	Unique keys	Other keys	Not allowed
`C-FIND`, baseline (hierarchical search)	A single value for the unique key of every level above the query level. At the query level, the unique key may be a single value, empty (universal) or a list of UIDs.	Required and optional keys of the query level. An SCU may not assume the SCP supports optional keys.	Required or optional keys of the levels above the query level.
`C-FIND`, relational (extended negotiation)	The unique key of the query level: single value, wildcard, universal or a list of UIDs.	Any combination of keys at any level. The SCP matches on all of them.	Nothing is excluded: the restriction that levels above must be pinned by their unique key is lifted.
`C-MOVE` and `C-GET`, baseline	A single value for the unique key of every level above the retrieve level. At the retrieve level one UID, or a list of UIDs when retrieving at STUDY, SERIES or IMAGE level.	C-MOVE also needs the Move Destination AE title (0000,0600).	Required keys and optional keys. A retrieve carries the unique keys and nothing else to select with.

An SCP answers a C-FIND by searching from the top level down: at each level above the query level it needs an entity with the given unique key, and at the query level it returns one response per match. No match at any step is a normal success with no identifier.

Worked examples

Study Root unless stated. Values after the equals sign are examples; an empty value on the right means "return this".

I want to	Request	Identifier
Find a patient's studies in January 2026	`C-FIND`, level `STUDY`	`(0008,0052)=STUDY`, `(0010,0020)=12345678`, `(0008,0020)=20260101-20260131`, `(0020,000D)=` (empty), `(0008,0050)=` (empty)
Find the studies of a patient in Patient Root	`C-FIND`, level `STUDY`	`(0008,0052)=STUDY`, `(0010,0020)=12345678` (the single unique key of the patient level above), study-level keys to return
List the series of one study	`C-FIND`, level `SERIES`	`(0008,0052)=SERIES`, `(0020,000D)=1.2.840...` (single value), `(0008,0060)=` (empty), `(0020,000E)=` (empty)
List the images of one series	`C-FIND`, level `IMAGE`	`(0008,0052)=IMAGE`, `(0020,000D)=` single value, `(0020,000E)=` single value, `(0008,0018)=` (empty), `(0020,0013)=` (empty)
Retrieve a whole study	`C-MOVE` or `C-GET`, level `STUDY`	`(0008,0052)=STUDY`, `(0020,000D)=1.2.840...`; for C-MOVE also `(0000,0600)=VIEWER_AE`
Retrieve two series	`C-MOVE` or `C-GET`, level `SERIES`	`(0008,0052)=SERIES`, `(0020,000D)=` single value, `(0020,000E)=uid1\uid2` (list of UIDs)
Retrieve one image	`C-MOVE` or `C-GET`, level `IMAGE`	`(0008,0052)=IMAGE`, study UID and series UID as single values, `(0008,0018)=` the SOP Instance UID

What a C-MOVE or C-GET transfers at each level

A retrieve can be at any level, but the transfer itself always takes place at the instance level, as C-STORE sub-operations.

Level	What is transferred
`PATIENT`	All composite object instances related to the patient (Patient Root only).
`STUDY`	All composite object instances related to the study.
`SERIES`	All composite object instances related to the series.
`IMAGE`	The selected individual composite object instances.

With list-of-UID matching, the baseline behaviour lets one request retrieve more than one study, series or image.

Matching types

How a value in a request key is interpreted. They apply in a C-FIND; in a retrieve, unique keys use single values or lists of UIDs.

Type	How to write it	Applies to	Notes
Single value	The exact value.	All attributes.	Dates and times are matched by meaning, not as text, so `223000` matches `2230`. A hyphen in a date or time value means a range.
List of UIDs	UIDs separated by a backslash: `uid1\uid2`.	UI attributes.	Each UID in the list may produce a match.
Universal	A zero-length value.	All attributes.	Everything matches, and the attribute is returned in the responses. This is how you ask for a return key. A lone `*` has the same effect.
Wild card	`*` matches any sequence of characters including none, `?` matches any single character.	AE, CS, LO, LT, PN, SH, ST, UC, UR and UT.	Case sensitive, except for PN (person names), where it is implementation dependent and stated in the Conformance Statement. There is no way to match a literal `*` or `?`.
Range	`20260101-20260131` between, `-20260131` up to and including, `20260101-` from and later.	Dates and times (DA, TM, DT).	Not defined for other types of attribute. Combined date and time ranges need extended negotiation.
Sequence	A sequence with a single item that holds the item keys.	SQ attributes.	Matches if all item keys match at least one item. An empty item returns the whole sequence.
Empty value	Exactly two quotation marks: `""`.	AE, CS, DA, DT, LO, LT, PN, SH, ST, TM, UC, UR and UT.	Needs extended negotiation. Matches a zero-length value or an attribute that is not present.

Matching of DS and IS values (numbers written as text) is implementation dependent, so `+7` and `007` may or may not match `7`. The SCP states its behaviour in its Conformance Statement.

Key types and what an SCP must support

Key type	Meaning	SCP obligation	In a C-FIND	In a C-MOVE or C-GET
Unique	One value identifies exactly one entity at its level.	Supports existence and matching of all unique keys. Every entity has a non-zero length unique key value.	May be present.	Must be present.
Required	A value does not have to identify a single entity.	Supports existence and matching. A zero-length value in the SCP means "unknown" and always matches.	May be present.	Must not be present.
Optional	Everything else at the level.	Free to support or not. If existence is not supported the attribute is never returned. If matching is not supported it is treated like a zero-length required key and matches everything. The SCP's Conformance Statement must list the optional keys it supports.	May be present.	Must not be present.

Because an SCP may ignore optional keys, an SCU has to be ready to filter the responses itself. To see which optional keys a PACS supports, read the Query/Retrieve section of its Conformance Statement.

Glossary

Information model: The hierarchy an archive exposes to queries: Patient Root (patient, study, series, image) or Study Root (study, series, image).
Query/Retrieve level: The level a request works at, given in (0008,0052): PATIENT, STUDY, SERIES or IMAGE.
Unique key: The one attribute per level that identifies a single entity: Patient ID, Study Instance UID, Series Instance UID or SOP Instance UID.
Required key: A key that every C-FIND SCP has to be able to match on, such as Study Date or Modality.
Optional key: Any other attribute of the level. An SCP may or may not support it.
Hierarchical search: The baseline C-FIND method. The request pins every level above the query level with its unique key.
Relational query: An extended C-FIND method, agreed in negotiation, that allows keys at any level in any combination.
Universal matching: A zero-length key value. Everything matches and the attribute is returned.

Summary

There are four levels: PATIENT, STUDY, SERIES and IMAGE. Patient Root has all four, Study Root starts at STUDY.
The unique keys are Patient ID, Study Instance UID, Series Instance UID and SOP Instance UID. They identify one entity at their level.
A baseline C-FIND pins every level above the query level with a single unique key value and does not carry keys of those levels. Relational queries lift that rule when both sides negotiate them.
A C-MOVE or C-GET carries the unique keys down to its level and no required keys. A list of UIDs at the retrieve level retrieves several entities at once.
Optional keys can be silently ignored by the SCP, so filter the responses yourself. Wild cards are case sensitive except for person names.

DIMSE services at a glance

IntermediateOpen on its own page →

Filter the tables

73 rows

DIMSE-C services: composite objects and queries

Used for images, structured reports and other composite SOP Instances, and for searching and retrieving them. Every service except C-CANCEL is confirmed: the request gets a response.

Service	Command Field	What it does	Request carries	Response carries	Used by
`C-STORE`	`0001` request, `8001` response	Sends one composite SOP Instance (an image or another object) to the peer for storage.	The SOP Instance as a data set. Command elements: Affected SOP Class UID, Affected SOP Instance UID, Priority. Optionally the Move Originator AE and Message ID.	Status only: `0000`, a warning (`Bxxx`) or a failure (`A7xx`, `A9xx`, `Cxxx`).	Storage service class. Also the sub-operations of C-MOVE and C-GET.
`C-FIND`	`0020` request, `8020` response	Matches a set of attributes against the instances the peer holds and returns the matches.	An Identifier: matching keys with values, and return keys left empty. Priority is mandatory.	One response per match with status `FF00` (or `FF01`) and an Identifier, then a final response with `0000` and no Identifier.	Query/Retrieve, Modality Worklist, and the UPS services (Pull, Watch, Query).
`C-GET`	`0010` request, `8010` response	Finds matching instances and retrieves them, with C-STORE sub-operations on the same association.	An Identifier with the unique keys of what to retrieve. Priority is mandatory.	Optional pending responses (`FF00`) with the counts of remaining, completed, failed and warning sub-operations, then a final response.	Query/Retrieve.
`C-MOVE`	`0021` request, `8021` response	Finds matching instances and has the peer send them to a named AE, with C-STORE sub-operations on a separate association.	An Identifier, plus the Move Destination AE title (0000,0600). Priority is mandatory.	Optional pending responses (`FF00`) with the sub-operation counts, then a final response. Cancel, failure and warning responses list the failed instances.	Query/Retrieve.
`C-ECHO`	`0030` request, `8030` response	Verifies end-to-end communication with the peer.	Nothing: no data set. Just the Affected SOP Class UID (Verification).	Status only, normally `0000`.	Verification service class.
`C-CANCEL`	`0FFF` (request only)	Asks the peer to stop a C-FIND, C-GET or C-MOVE that is still running. It is C-CANCEL-FIND, C-CANCEL-GET or C-CANCEL-MOVE depending on the operation.	Message ID Being Responded To, set to the Message ID of the operation to stop. No data set.	No response of its own. The stopped operation ends with status `FE00` (cancel).	Query/Retrieve and the other C-FIND users.

The Command Field of a response is the request value with bit 15 set: 0001 gives 8001, 0020 gives 8020. C-CANCEL has no response value.

DIMSE-N services: managed objects

Used for managed SOP Instances that are created, changed and queried over time, such as a performed procedure step, a storage commitment request or a film session. The request names its target with the Requested SOP Class UID and Requested SOP Instance UID, except N-CREATE and N-EVENT-REPORT, which use the Affected ones.

Service	Command Field	What it does	Request carries	Response carries	Used by
`N-CREATE`	`0140` request, `8140` response	Asks the peer to create a new managed SOP Instance and register its identity.	Affected SOP Class UID (mandatory), Affected SOP Instance UID (optional: the peer assigns one if it is left out), an Attribute List (optional).	Status. On success it returns the Affected SOP Instance UID if the sender did not supply one, and optionally the complete Attribute List that was assigned.	Modality Performed Procedure Step, Instance Availability Notification, Print Management, UPS Push.
`N-SET`	`0120` request, `8120` response	Asks the peer to modify attribute values of a managed SOP Instance.	Requested SOP Class UID and Instance UID, and a Modification List (mandatory).	Status, and optionally the Attribute List with the values that were changed.	Modality Performed Procedure Step, Print Management, UPS Pull.
`N-GET`	`0110` request, `8110` response	Retrieves attribute values from a managed SOP Instance.	Requested SOP Class UID and Instance UID, and optionally an Attribute Identifier List (0000,1005) to limit what is returned. No data set.	Status and, on success, the Attribute List with the values.	Modality Performed Procedure Step (retrieve), Print Management (Printer and Print Job), UPS.
`N-ACTION`	`0130` request, `8130` response	Asks the peer to perform an action on a managed SOP Instance.	Requested SOP Class UID and Instance UID, the Action Type ID (0000,1008, mandatory) and optionally Action Information.	Status and, optionally, an Action Reply.	Storage Commitment (Action Type 1), Print Management (print a film box), UPS (change state, subscribe, request cancel).
`N-DELETE`	`0150` request, `8150` response	Asks the peer to delete a managed SOP Instance and de-register it.	Requested SOP Class UID and Instance UID. No data set.	Status only.	Print Management (film session and film box).
`N-EVENT-REPORT`	`0100` request, `8100` response	Reports an event on a managed SOP Instance to the peer. In the services listed here it is the SCP that reports to the SCU.	Affected SOP Class UID and Instance UID, the Event Type ID (0000,1002, mandatory) and optionally Event Information.	Status and, optionally, an Event Reply.	Storage Commitment (Event Type 1 success, 2 failures), MPPS notification, Print Management (Printer and Print Job), UPS Event.

PS3.4 notes that the Instance Availability Notification is called a notification, but "is in fact performed through Operations rather than Notifications": it is an N-CREATE, not an N-EVENT-REPORT.

Which service class uses which DIMSE service

Taken from the DIMSE Service Group table of each service class in PS3.4. A service class can have several SOP Classes, and each SOP Class uses some of the services listed here.

Service class	DIMSE services	Notes
Verification	`C-ECHO`	Every DIMSE implementation that accepts associations must accept it as SCP (PS3.2).
Storage	`C-STORE`	One SOP Class per object type, such as CT Image Storage.
Query/Retrieve	`C-FIND`, `C-MOVE`, `C-GET`, `C-CANCEL`	C-MOVE and C-GET trigger C-STORE sub-operations, so the SCP of Query/Retrieve acts as Storage SCU.
Basic Worklist Management (Modality Worklist)	`C-FIND`	The modality is the SCU and the worklist provider the SCP.
Modality Performed Procedure Step	`N-CREATE`, `N-SET`	Two companion SOP Classes add `N-GET` (retrieve) and `N-EVENT-REPORT` (notification). N-CREATE may only carry IN PROGRESS.
Storage Commitment Push Model	`N-ACTION`, `N-EVENT-REPORT`	The SCU sends N-ACTION; the SCP answers with N-EVENT-REPORT, on the same or a different association.
Instance Availability Notification	`N-CREATE`	Sent by the holder of the images to tell another system they are available.
Print Management	`N-CREATE`, `N-SET`, `N-GET`, `N-ACTION`, `N-DELETE`, `N-EVENT-REPORT`	Spread over the Film Session, Film Box, Image Box, Printer and Print Job SOP Classes.
Unified Procedure Step (UPS)	`C-FIND`, `N-CREATE`, `N-GET`, `N-SET`, `N-ACTION`, `N-EVENT-REPORT`	Split over the UPS Push, Pull, Watch, Event and Query SOP Classes.

Command elements you see in a trace

Every DIMSE message starts with a command set of elements in group 0000. It is always encoded as Implicit VR Little Endian, with the elements in ascending tag order.

Tag	Name	Meaning
`(0000,0000)`	Command Group Length	Number of bytes of the rest of the command set.
`(0000,0002)`	Affected SOP Class UID	The SOP Class the operation works on.
`(0000,0003)`	Requested SOP Class UID	The SOP Class of the instance an N-GET, N-SET, N-ACTION or N-DELETE addresses.
`(0000,0100)`	Command Field	Which DIMSE operation this is: `0001` C-STORE-RQ, `0010` C-GET-RQ, `0020` C-FIND-RQ, `0021` C-MOVE-RQ, `0030` C-ECHO-RQ, `0100` N-EVENT-REPORT-RQ, `0110` N-GET-RQ, `0120` N-SET-RQ, `0130` N-ACTION-RQ, `0140` N-CREATE-RQ, `0150` N-DELETE-RQ, `0FFF` C-CANCEL-RQ. Responses add `8000`.
`(0000,0110)`	Message ID	Identifies a request. Must be unique among outstanding operations.
`(0000,0120)`	Message ID Being Responded To	In a response, the Message ID of its request. In a C-CANCEL, the Message ID of the operation to stop.
`(0000,0600)`	Move Destination	AE title that receives the C-STORE sub-operations of a C-MOVE.
`(0000,0700)`	Priority	`0002` low, `0000` medium, `0001` high.
`(0000,0800)`	Command Data Set Type	`0101` means no data set follows; any other value means a data set is included.
`(0000,0900)`	Status	Outcome of the operation, see the status table below.
`(0000,0901)`	Offending Element	With a `Cxxx` status, the elements in which the error was found.
`(0000,0902)`	Error Comment	Free-text description of the error.
`(0000,0903)`	Error ID	Optional application-specific error code.
`(0000,1000)`	Affected SOP Instance UID	The SOP Instance the operation worked on or created.
`(0000,1001)`	Requested SOP Instance UID	The SOP Instance an N-GET, N-SET, N-ACTION or N-DELETE addresses.
`(0000,1002)`	Event Type ID	Which event an N-EVENT-REPORT reports. Values are defined by the SOP Class.
`(0000,1005)`	Attribute Identifier List	The attributes an N-GET asks for.
`(0000,1008)`	Action Type ID	Which action an N-ACTION requests. Values are defined by the SOP Class.
`(0000,1020)`	Number of Remaining Sub-operations	C-GET and C-MOVE: C-STORE sub-operations still to do.
`(0000,1021)`	Number of Completed Sub-operations	C-GET and C-MOVE: sub-operations that succeeded.
`(0000,1022)`	Number of Failed Sub-operations	C-GET and C-MOVE: sub-operations that failed.
`(0000,1023)`	Number of Warning Sub-operations	C-GET and C-MOVE: sub-operations that gave a warning.
`(0000,1030)`	Move Originator AE Title	In a C-STORE sub-operation: the AE that issued the C-MOVE.
`(0000,1031)`	Move Originator Message ID	In a C-STORE sub-operation: the Message ID of the C-MOVE request.

Status codes

The Status in (0000,0900) falls into one of five classes. The values 01xx and 02xx are reserved by DICOM and mean the same in every service. Axxx, Bxxx and Cxxx are assigned by a service class in PS3.4 (or by an implementation) and are listed in that service's section.

Status	Class	Meaning
`0000`	Success	The operation completed.
`FE00`	Cancel	Matching or sub-operations were stopped by a C-CANCEL.
`FF00`	Pending	More responses follow. For a C-FIND this response carries a match.
`FF01`	Pending	C-FIND only: more follow, and one or more optional keys were not supported.
`0001`, `Bxxx`	Warning	Done, with a deviation. `B000` on a C-STORE is coercion of data elements, on a C-MOVE or C-GET it means some sub-operations failed.
`0107`	Warning	Attribute list error: some attributes were not recognized.
`0116`	Warning	Attribute value out of range.
`Axxx`, `Cxxx`	Failure	Class-specific failures. `A7xx` out of resources, `A801` move destination unknown, `A9xx` data set does not match the SOP Class, `Cxxx` cannot understand or unable to process.
`0105`	Failure	No such attribute.
`0106`	Failure	Invalid attribute value.
`0110`	Failure	Processing failure.
`0111`	Failure	Duplicate SOP Instance.
`0112`	Failure	No such SOP Instance.
`0113`	Failure	No such event type.
`0114`	Failure	No such argument.
`0115`	Failure	Invalid argument value.
`0117`	Failure	Invalid SOP Instance.
`0118`	Failure	No such SOP Class.
`0119`	Failure	Class-instance conflict.
`0120`	Failure	Missing attribute.
`0121`	Failure	Missing attribute value.
`0122`	Failure	Refused: SOP Class not supported.
`0123`	Failure	No such action type.
`0124`	Failure	Refused: not authorized.
`0210`	Failure	Duplicate invocation.
`0211`	Failure	Unrecognized operation.
`0212`	Failure	Mistyped argument.
`0213`	Failure	Resource limitation.

The classes are defined in PS3.7 Annex C: success 0000, warning 0001, Bxxx, 0107 or 0116, failure Axxx, Cxxx, 01xx (except 0107 and 0116) or 02xx, cancel FE00, pending FF00 and FF01. Implementations may only use the values listed. An SCU must treat any code inside a listed range as that failure.

Glossary

DIMSE: DICOM Message Service Element. The commands (C- and N- services) that two application entities send each other inside an association.
DIMSE-C: The composite services: C-STORE, C-FIND, C-GET, C-MOVE, C-ECHO. They work on composite SOP Instances such as images.
DIMSE-N: The normalized services: N-CREATE, N-SET, N-GET, N-ACTION, N-DELETE, N-EVENT-REPORT. They work on managed SOP Instances such as a procedure step.
Command set: The group 0000 elements that start every DIMSE message. It names the operation, the SOP Class and the message ID, and says whether a data set follows.
Data set: The object that follows the command set when the message carries one: an image, an identifier, an attribute list.
Identifier: The data set of a C-FIND, C-GET or C-MOVE: the keys to match, or the values that matched.
Composite vs normalized: A composite SOP Instance, such as an image, has a fixed content and is stored or queried as a whole. A normalized instance, such as a procedure step, is created and then changed or queried in parts.
Sub-operation: One C-STORE that a C-GET or C-MOVE performs on behalf of the request. The responses count them.

Summary

There are twelve DIMSE messages in two families. DIMSE-C: C-STORE, C-FIND, C-GET, C-MOVE, C-ECHO and C-CANCEL. DIMSE-N: N-CREATE, N-SET, N-GET, N-ACTION, N-DELETE and N-EVENT-REPORT.
A response Command Field is the request value plus 8000. C-CANCEL has no response, and the stopped operation ends with FE00.
(0000,0800) is 0101 when no data set follows. Every response has a Status in (0000,0900): 0000 success, FF00 pending, Bxxx warning, anything else a failure.
C-MOVE and C-GET both run C-STORE sub-operations: C-MOVE on a separate association to a named AE, C-GET on the same association.
The N-services address an instance with the Requested UIDs, apart from N-CREATE and N-EVENT-REPORT. Which services a device supports, and in which role, is in its Conformance Statement.

DICOM and HL7: how the fields line up

IntermediateOpen on its own page →

Filter the tables

58 rows

Which HL7 message does what

The IHE transactions that carry HL7 in the radiology workflow. Every message is acknowledged with an HL7 ACK. "Option" means the HL7 v2.5.1 option of IHE, which a system supports in addition to the HL7 v2.3.1 version.

Transaction	From and to	HL7 v2.3.1	HL7 v2.5.1 option	What it carries
RAD-1 Patient Registration	ADT system to order placer and department scheduler	`ADT^A01` admit in-patient, `A04` register outpatient, `A05` pre-admit	ADT, the same events	Patient and visit data in PID and PV1.
RAD-12 Patient Update	Same	`ADT^A02`, `A03`, `A06`, `A07`, `A08`, `A40`	ADT, the same events	Visit changes, patient updates (`A08`) and merges (`A40`).
RAD-2 Placer Order Management	Order placer to scheduler (order filler)	`ORM^O01`. ORC-1: `NW` new, `CA` cancel, `DC` discontinue	`OMG^O19`. Adds `XO` change order	The order: ORC and OBR with PID and PV1.
RAD-3 Filler Order Management	Scheduler (order filler) to order placer	`ORM^O01`. ORC-1: `SN` new order from the filler, `OC` cancelled by the filler, `SC` status update. Reply `ORR` (`NA`)	`OMG^O19`. Adds `XX` change order. Reply `ORG`	The filler's own orders and the order status (see the status table).
RAD-4 Procedure Scheduled	Scheduler to image manager and report manager	`ORM^O01` with a `ZDS` segment. ORC-1 `NW`, ORC-5 `SC`	`OMI^O23` with `TQ1` and `IPC` segments	One message per requested procedure, with the accession number, procedure and Study Instance UID.
RAD-13 Procedure Update	Scheduler to image manager	`ORM`	`OMI`	Changes to procedure information that is already scheduled.

The scheduler is the "Department System Scheduler/Order Filler": in many sites that is the RIS. A PACS that receives RAD-4 acts as the image manager.

HL7 order fields in a DICOM worklist entry (IHE Appendix B)

Where the values of a modality worklist response come from when the order arrives from the placer as an ORM (v2.3.1) or OMG (v2.5.1), plus the ADT fields marked below. The field is the same in both versions unless stated.

DICOM attribute	Tag	HL7 field	Notes
Patient's Name	`(0010,0010)`	`PID-5`	Components map by name, see the conversions table.
Patient ID	`(0010,0020)`	`PID-3.1`	First component of the patient identifier list. IHE Appendix D discusses merge cases.
Issuer of Patient ID	`(0010,0021)`	`PID-3.4`	The assigning authority of the identifier.
Patient's Birth Date	`(0010,0030)`	`PID-7`	First component of the date/time.
Patient's Sex	`(0010,0040)`	`PID-8`	DICOM allows M, F, O or empty.
Patient's Weight	`(0010,1030)`	`OBX-5`	From the OBX that identifies "Body Weight", in kg. IHE shows it coming from an ADT message.
Patient's Size	`(0010,1020)`	`OBX-5`	From the OBX that identifies "Body Height", in m. IHE shows it coming from an ADT message.
Referring Physician's Name	`(0008,0090)`	`PV1-8`	Referring Doctor.
Requesting Physician	`(0032,1032)`	`OBR-16`	Ordering Provider.
Admission ID	`(0038,0010)`	`PV1-19`	Visit Number. If it is empty the value comes from `PID-18`, the account number.
Current Patient Location	`(0038,0300)`	`PV1-3`	Assigned Patient Location.
Pregnancy Status	`(0010,21C0)`	`PV1-15`	Ambulatory Status. The value `B6` maps to `3`, definitely pregnant.
Medical Alerts	`(0010,2000)`	`OBR-13`	Relevant Clinical Info.
Contrast Allergies	`(0010,2110)`	`AL1-3`	Allergy code, from an ADT message.
Confidentiality constraint on patient data	`(0040,3001)`	`PV1-16`	VIP Indicator.
Requested Procedure Priority	`(0040,1003)`	`ORC-7.6` (v2.3.1), `TQ1-9` (v2.5.1)	Mapped as in the conversions table.
Reason for the Requested Procedure	`(0040,1002)`	`OBR-31`	Reason for Study. The code sequence `(0040,100A)` comes from the same field.
Patient Transport Arrangements	`(0040,1004)`	`OBR-30`	Transportation Mode.
Placer Order Number, Imaging Service Request	`(0040,2016)`	`ORC-2`	Issuer and number.
Filler Order Number, Imaging Service Request	`(0040,2017)`	`ORC-3`	Issuer and number.
Scheduled Performing Physician's Name	`(0040,0006)`	`OBR-34`	Technician. Only the first component of the first repetition is used.
Specific Character Set	`(0008,0005)`	`MSH-18`	The character set of the message.
Accession Number, Requested Procedure ID, Study Instance UID, Requested Procedure Description and Code, Scheduled Procedure Step ID, start date and time, station AE title, Modality	`(0008,0050)`, `(0040,1001)`, `(0020,000D)`, `(0032,1060)`, `(0032,1064)`, `(0040,0009)`, `(0040,0002)`, `(0040,0003)`, `(0040,0001)`, `(0008,0060)`	None: generated	Generated by the department system scheduler, not taken from the order. The scheduler decides the modality from the content of the order.

The order carries information about the order, not about scheduling or resources: those belong to the department scheduler. This appendix does not apply to the Procedure Scheduled transaction, which is the next table.

Procedure Scheduled (RAD-4): where the identifiers travel

The scheduler hands what it generated to the image manager (the PACS). The same values then appear in the worklist, the images and the MPPS. The two columns are the two versions of the same message.

DICOM attribute	ORM^O01 (v2.3.1)	OMI^O23 (v2.5.1 option)	Notes
Accession Number `(0008,0050)`	`OBR-18` (Placer Field 1)	`IPC-1` (Accession Identifier)	At most 16 characters. In the v2.5.1 message every IPC segment has the same value.
Requested Procedure ID `(0040,1001)`	`OBR-19` (Placer Field 2)	`IPC-2`	In the v2.3.1 message all OBR segments have the same value.
Study Instance UID `(0020,000D)`	`ZDS-1`	`IPC-3`	ZDS is a custom IHE segment. In ZDS-1 component 1 is the UID, component 3 is "Application" and component 4 is "DICOM".
Scheduled Procedure Step ID `(0040,0009)`	`OBR-20` (Filler Field 1)	`IPC-4`	May repeat when a step has several protocol codes.
Modality `(0008,0060)`	`OBR-24` (Diagnostic Service Section ID)	`IPC-5`	DICOM defined terms, such as CT.
Scheduled Protocol Code `(0040,0008)`	`OBR-4`, components 4 to 6	`IPC-6`	Components 1 to 3 of OBR-4 hold the code of the order.
Requested Procedure Code `(0032,1064)`	`OBR-44`	`OBR-44`	Components 1 to 3 are the code. Component 5 may hold the description.
Laterality, appended to the Requested Procedure Description `(0032,1060)`	`OBR-15` (Specimen Source)	`OBR-46` (Placer Supplemental Service Information)	Only when the code in OBR-4 does not already say left or right. In v2.5.1 OBR-15 must not be present.
Scheduled start date and time	`ORC-7.4` and `OBR-27.4`	`TQ1-7`	In v2.5.1 ORC-7 and OBR-27 are not populated.
Placer Order Number `(0040,2016)`	`ORC-2`, `OBR-2`	`ORC-2`, `OBR-2`	Empty if the scheduler schedules a procedure for an unidentified patient without an order.
Filler Order Number `(0040,2017)`	`ORC-3`, `OBR-3`	`ORC-3`, `OBR-3`	Generated by the scheduler. Different from the accession number.
Order control and status	`ORC-1` = `NW`, `ORC-5` = `SC`	`ORC-1` = `NW`, `ORC-5` = `SC`	New order, status scheduled.
Patient and visit data	`PID`, `PV1`	`PID`, `PV1`, `AL1`, `OBX`	The image manager takes the patient demographics from this message.

Segments in the v2.3.1 message: MSH, PID, PV1, ORC and OBR (repeating) and ZDS. In the v2.5.1 option: MSH, PID, PV1, optional AL1, ORC, TQ1, OBR, optional OBX and IPC. Scheduler and image manager must agree which version they use.

Value conversions to watch

Places where the HL7 value and the DICOM value are not the same thing.

Item	HL7 side	DICOM side	Rule
Patient name	`PID-5`: family, given, middle, suffix, prefix, degree	Patient's Name: family, given, middle, prefix, suffix	IHE maps the components by name, unchanged. The degree is absorbed into the suffix. The positions of suffix and prefix are swapped between the two formats, so map by name, not by position.
Sex	`PID-8`: M, F, O, U ...	M, F, O or an empty value	HL7 `U` (unknown) becomes empty. Any other value must be mapped or left empty, because other DICOM values are illegal.
Priority	`ORC-7.6` or `TQ1-9`: S, A, R, P, C, T	STAT, HIGH, ROUTINE, MEDIUM	`S` gives STAT; `A`, `P` and `C` give HIGH; `R` gives ROUTINE; `T` gives MEDIUM.
Weight and height	`OBX-5` with text "Body Weight" or "Body Height"	Patient's Weight in kg, Patient's Size in m	IHE specifies no coding scheme, only the text and the units. Example: `OBX\|\|ST\|^BODY WEIGHT\|\|62\|kg\|\|\|\|\|F`.
Admission ID	`PV1-19`, otherwise `PID-18`	`(0038,0010)` and its issuer `(0038,0011)`	The visit number wins when it is valued. This only works if visit numbers are unique across all account numbers.
Patient ID and issuer	`PID-3`, the Patient Identifier List, which can repeat	Patient ID and Issuer of Patient ID	Components 1 and 4 of `PID-3`. The older `PID-2` and `PID-4` are kept only for backward compatibility.
Accession number length	`OBR-18` or `IPC-1`	AccessionNumber	At most 16 characters, which is the limit of the DICOM value representation.

Order status: from the exam back to HL7

The scheduler tells the order placer how the order is going with a status update (ORM or OMG with ORC-1 `SC`). The status is in ORC-5.

Status	ORC-5	When the scheduler sends it
In progress	`IP`	After it has processed the first Modality Procedure Step In Progress (an MPPS N-CREATE) for the order. It lets the placer know the exam has started, so it does not cancel it.
Completed	`CM`	When the complete, verified report for the order is available, not when the MPPS is completed. At least one such message is sent, and not before the final verified report of all procedures of the order.
Discontinued	`DC`	When a cancellation arrives after the order is in progress. It is handled as a discontinuation instead.

A status update cannot be used to request an action such as cancelling an order. A cancel request goes from the placer to the scheduler as a RAD-2 message.

Attributes the modality copies from the worklist

IHE Appendix A lists the attributes that must travel unchanged from the worklist response into the images and the MPPS. If the technologist types them instead, order and study no longer match.

Attribute	Tag	In the images and the MPPS
Study Instance UID	`(0020,000D)`	Copied. The worklist also carries it in the Referenced Study Sequence `(0008,1110)`, which is copied as well.
Accession Number	`(0008,0050)`	Copied.
Requested Procedure ID	`(0040,1001)`	Copied. In the images it is inside the Request Attributes Sequence `(0040,0275)`.
Requested Procedure Description	`(0032,1060)`	Copied.
Scheduled Procedure Step ID and Description	`(0040,0009)`, `(0040,0007)`	Copied.
Scheduled Protocol Code Sequence	`(0040,0008)`	Copied.

In the MPPS the scheduled values sit inside the Scheduled Step Attributes Sequence (0040,0270). The performed values, such as the Performed Procedure Step ID, are generated by the modality.

Glossary

HL7 v2: The standard for text messages between hospital systems. A message is made of segments (PID, ORC, OBR), a segment of fields separated by `|`, and a field of components separated by `^`.
Segment and field: PID-5 means field 5 of the PID segment. PID-3.1 means component 1 of field 3.
Order placer: The system where an order is entered, usually the EHR. It sends the order and cancels it if needed.
Order filler, department system scheduler: The system that carries out the order and schedules the exam, usually the RIS. It creates the accession number, the requested procedure ID and the Study Instance UID.
Image manager: The IHE role of the PACS that stores the images and receives the scheduled procedure from the scheduler.
ORC-1, order control: The code that says what an order message does: `NW` new order, `CA` cancel, `DC` discontinue, `XO` change, `SC` status change, and others.
ZDS and IPC: Two segments that carry the Study Instance UID to the image manager. ZDS is a custom IHE segment for HL7 v2.3.1. IPC is the HL7 v2.5.1 Imaging Procedure Control segment.
IHE: Integrating the Healthcare Enterprise. It publishes profiles that say exactly how DICOM and HL7 are used together. The mapping on this page is the IHE one.

Summary

DICOM and HL7 define no mapping to each other. In radiology the usual one is the IHE Radiology Technical Framework, and sites can deviate from it.
Orders go from the placer to the scheduler as ORM^O01 (v2.3.1) or OMG^O19 (v2.5.1 option). The scheduler sends the scheduled procedure to the PACS as ORM^O01 with ZDS, or OMI^O23 with IPC.
The accession number is in OBR-18 (v2.3.1) or IPC-1 (v2.5.1), at most 16 characters. The Study Instance UID is in ZDS-1 or IPC-3. Both are generated by the scheduler, not by the order placer.
Patient data comes from PID and PV1: PID-3 and PID-5 give the patient ID and name. Map name components by name, and map sex U to empty.
Order status comes back as ORC-5 IP after the first MPPS, and CM only when the verified report is available.

PACS and EHR workflow for external images

IntermediateOpen on its own page →

DICOM
HL7 v2
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 6

Images land in PACS

Core step

What happens

Images made elsewhere (a CD, a patient portal, another hospital) are loaded into the PACS. The PACS stores them, but nobody here ordered them, so they are not linked to any request.

Why it is needed

Without an accession number the images float unattached. Radiologists cannot find them in a worklist and reports cannot be linked.

Technical details

PatientID (0010,0020) = local MRN or to be reconciled
AccessionNumber (0008,0050) = empty
StudyInstanceUID (0020,000D) = 1.2.840....

All steps at a glance

Glossary

PACS: Picture Archiving and Communication System. The server that stores and serves medical images.
EHR / EMR: Electronic Health Record. The hospital system holding patients, orders and reports.
Accession number: The unique ID of one imaging request. It links an image study to its order and report.
DICOM: The standard for medical images and for the messages that move them between devices.
HL7 v2: The standard for text messages between hospital systems, such as orders and results.
IAN: Instance Availability Notification. A DICOM message saying “these images are now ready”.
ORM / ACK: ORM is an HL7 order message. ACK is the receiver’s reply: “got it” or “error”.
Study Instance UID: The globally unique ID of the image study itself. Used to match the right study.
MRN: Medical Record Number. The patient’s ID in the hospital.

Summary

The IAN is a DICOM N-CREATE sent by PACS to the EHR. It is not an HL7 message.
The EHR acts as order filler: it creates the internal request and generates the accession number.
The EHR sends the accession number back as an HL7 ORM^O01 with ORC-1 = NW. The accession number goes in OBR-18 (IHE; OBR-3 is the filler order number).
Add a ZDS segment with the Study Instance UID (ZDS-1), so PACS can match the order to the study.
PACS reconciles the study and returns an HL7 ACK, so the EHR knows both systems agree.
Patient identity must match first. Vendor support for IAN varies. In the IHE HL7 v2.5.1 option the message is an OMI^O23 and the accession number and Study Instance UID are in IPC-1 and IPC-3.

ECG without an order: PDF on disk to PACS

IntermediateOpen on its own page →

DICOM
HL7 v2
Internal action
Dashed = reply

Tip: click an arrow or box in the diagram to jump to that step. Time flows top to bottom.

Step 1 of 9

The ECG is saved as a PDF on a server disk

Core step

What happens

The ECG is recorded without an order in the hospital system. The cart (or the ECG management system) writes a PDF to a folder on a server disk. Nothing in the PACS or the EHR knows about it yet.

Why it is needed

This is the difference with a normal exam. There is no worklist entry, so the PDF carries no accession number and no Study Instance UID.

Technical details

File = ECG report as PDF (sometimes with an XML or text file beside it)
Patient ID and name = in the file name, the PDF text or a sidecar file
Accession number = none

All steps at a glance

Glossary

Watcher tool: A small service that monitors a folder, picks up each new file and sends it on. It is not part of the DICOM standard; every site builds or buys its own.
Encapsulated PDF: A DICOM object that carries a PDF file as its payload, so a document can be stored, queried and shown in the PACS like an image study.
IAN: Instance Availability Notification. A DICOM message saying “these objects are now ready”.
Accession number: The unique ID of one imaging request. It links a study to its order and report.
Study Instance UID: The globally unique ID of the study. Here the watcher tool creates it, because the PDF has none.
ORM / ACK: ORM is an HL7 order message. ACK is the receiver’s reply: “got it” or “error”.
MRN: Medical Record Number. The patient’s ID in the hospital.

Summary

The ECG is recorded without an order, so the PDF has no accession number and no Study Instance UID.
A watcher tool creates the Study Instance UID, wraps the PDF in an Encapsulated PDF object (1.2.840.10008.5.1.4.1.1.104.1) and sends it with C-STORE.
The tool moves or deletes the file only after the PACS answers with status 0000.
From the IAN onward the flow is the same as for external images: the EHR creates the request and the accession number and returns it in an HL7 ORM^O01.
The accession number goes in OBR-18 (IHE) and the Study Instance UID in ZDS-1; in the HL7 v2.5.1 option the message is an OMI^O23 with IPC-1 and IPC-3.
The weak spot is patient identity: if the ECG cart has a wrong or mistyped Patient ID, the order is created for the wrong patient or cannot be matched.

LearnPACS administration, explained visually

The interface brings in patients and orders

What happens

Why it is needed

Technical details

The worklist tells the scanner who to scan

What happens

Why it is needed

Technical details

The storage service receives the images

What happens

Why it is needed

Technical details

The archive keeps the files

What happens

Why it is needed

Technical details

The database makes them findable

What happens

Why it is needed

Technical details

Routing rules send copies on

What happens

Why it is needed

Technical details

A copy goes to long-term storage

What happens

Why it is needed

Technical details

The viewer asks for the study

What happens

Why it is needed

Technical details

The images reach the viewer

What happens

Why it is needed

Technical details

All steps at a glance

Glossary

Summary

Open the TCP connection

What happens

Why it is needed

Technical details

A-ASSOCIATE-RQ: propose what to talk about

What happens

Why it is needed

Technical details

The acceptor checks the request

What happens

Why it is needed

Technical details

A-ASSOCIATE-AC: agree on the contexts

What happens

Why it is needed

Technical details

DIMSE request in P-DATA-TF

What happens

Why it is needed

Technical details

DIMSE response in P-DATA-TF

What happens

Why it is needed

Technical details

A-RELEASE-RQ: ask to close

What happens

Why it is needed

Technical details

A-RELEASE-RP: closed

What happens

Why it is needed

Technical details

All steps at a glance

Glossary

Summary

TCP connection

What happens

Why it is needed

Technical details

A-ASSOCIATE-RQ with the Verification SOP Class