The ROOT is the overall data model, and there are two main roots in DICOM, STUDY and PATIENT. A third root model also exists called PATIENTSTUDY but it was very rarely used in DICOM and is now officially retired.

Within each root structure, operations (find or GET or MOVE) are done at a particular LEVEL. The allowed combinations are:

PATIENT Root

Allows operations at these levels:

• PATIENT
• STUDY
• SERIES
• IMAGE

STUDY Root

Allows these levels:

• STUDY
• SERIES
• IMAGE

PATIENT/STUDY Only Root

Has 2 levels:

• PATIENT
• STUDY

This is a degenerate version of the PATIENT root, so although whole patient record or whole studies can be retrieved, no querying or retrieval selection at series or instance level is allowed. It offers no advantages over patient root, and was merely a means for older implementations to claim conformance, but it has now been completely retired from the DICOM standard.

Note: There are several currently available commercial implementations which claim to support PATIENT root (and therefore negotiate the PATIENT root SOP class), but in reality only support the functionality of the PATIENT/STUDY root SOP class. Some even admit this in their conformance statements (without realising that series and image level support is not optional in the PATIENT root model) 

Use of the Level Attribute

The Level is defined by Dicom attribute 0008,0052. However even when this is SERIES or IMAGE you still use STUDY or PATIENT for the root in the MOVE or FIND request. Either root will do, but you need to make sure that you have negotiated the correct context according to the root.

Unless relational queries are used (most SCUs and SCPs don’t support them), then it is important for both C-FIND and C-MOVE/C-GET that all unique identifiers (Patient ID, StudyUID & Series UID) between the root and the level being requested are included. For C-MOVE/C-GET, the unique identifier for the level being requested must also be specified (multiple values separated by \ characters are allowed).