PS3.4

The information in this publication was considered technically sound by the consensus of persons engaged in the development and approval of the document at the time it was developed. Consensus does not necessarily mean that there is unanimous agreement among every person participating in the development of this document.

NEMA standards and guideline publications, of which the document contained herein is one, are developed through a voluntary consensus standards development process. This process brings together volunteers and/or seeks out the views of persons who have an interest in the topic covered by this publication. While NEMA administers the process and establishes rules to promote fairness in the development of consensus, it does not write the document and it does not independently test, evaluate, or verify the accuracy or completeness of any information or the soundness of any judgments contained in its standards and guideline publications.

NEMA disclaims liability for any personal injury, property, or other damages of any nature whatsoever, whether special, indirect, consequential, or compensatory, directly or indirectly resulting from the publication, use of, application, or reliance on this document. NEMA disclaims and makes no guaranty or warranty, expressed or implied, as to the accuracy or completeness of any information published herein, and disclaims and makes no warranty that the information in this document will fulfill any of your particular purposes or needs. NEMA does not undertake to guarantee the performance of any individual manufacturer or seller's products or services by virtue of this standard or guide.

In publishing and making this document available, NEMA is not undertaking to render professional or other services for or on behalf of any person or entity, nor is NEMA undertaking to perform any duty owed by any person or entity to someone else. Anyone using this document should rely on his or her own independent judgment or, as appropriate, seek the advice of a competent professional in determining the exercise of reasonable care in any given circumstances. Information and other standards on the topic covered by this publication may be available from other sources, which the user may wish to consult for additional views or information not covered by this publication.

NEMA has no power, nor does it undertake to police or enforce compliance with the contents of this document. NEMA does not certify, test, or inspect products, designs, or installations for safety or health purposes. Any certification or other statement of compliance with any health or safety-related information in this document shall not be attributable to NEMA and is solely the responsibility of the certifier or maker of the statement.

Foreword

This DICOM Standard was developed according to the procedures of the DICOM Standards Committee.

The DICOM Standard is structured as a multi-part document using the guidelines established in [ISO/IEC Directives, Part 2].

1 Scope and Field of Application

This Part of the DICOM Standard specifies the set of Service Class Definitions that provide an abstract definition of real-world activities applicable to communication of digital medical information. For each Service Class Definition, this Part specifies:

the semantic description of the activities of the Service Class Definition
the group of DIMSE Service operations and notifications applicable to the Service Class Description
one or more functionally-related Service-Object Pair (SOP) Classes that are supported by the Service Class Definition and may be performed between peer DICOM Application Entities
the relationship of each Service-Object Pair (SOP) Classes to applicable Information Object Definitions specified in PS3.3.

For each Service Class Definition, this Part does not specify:

any necessary information for the semantic description of the IOD
relationships to associated real-world objects relevant to the IOD
Attributes that describe the characteristics of the IOD

This Part is related to other parts of the DICOM Standard in that:

PS3.3 Information Object Definitions specifies the set of Information Object Definitions to which the services defined in this Part may be applied
PS3.5 Data Structure and Semantics defines the data encoding used in the DIMSE Protocol when applied to IODs defined in this Part
PS3.6 Data Dictionary contains an index by Tag of all IOD Attributes defined in this Part. This index includes the Value Representation and Value Multiplicity for each Attribute
PS3.7 Message Exchange Protocol defines the DIMSE Services and Protocol that may be applied to IODs defined in this Part.

2 Normative References

The following standards contain provisions which, through reference in this text, constitute provisions of this Standard. At the time of publication, the editions indicated were valid. All standards are subject to revision, and parties to agreements based on this Standard are encouraged to investigate the possibilities of applying the most recent editions of the standards indicated below.

[ISO/IEC Directives, Part 2] ISO/IEC. 2016/05. 7.0. Rules for the structure and drafting of International Standards. http://www.iec.ch/members_experts/refdocs/iec/isoiecdir-2%7Bed7.0%7Den.pdf .

[ISO 7498-1] ISO. 1994. Information Processing Systems - Open Systems Interconnection - Basic Reference Model.

[RFC3986] IETF. Uniform Resource Identifiers (URI): Generic Syntax. http://tools.ietf.org/html/rfc3986 .

[ISO/TR 8509] ISO. Information Processing Systems - Open Systems Interconnection - Service Conventions. ISO/TR 8509 has been withdrawn. See ISO/IEC 2382-26:1993 Information technology - Vocabulary - Part 26: Open systems interconnection .

[RFC7230] IETF. June 2014. Hypertext Transfer Protocol (HTTP/1.1): Message Syntax and Routing. http://tools.ietf.org/html/rfc7230 .

[Porter and Duff 1984] Computer Graphics. Porter, Thomas and Duff, Tom. 1984. 18. 3. 253-259. “Compositing Digital Images”. doi:10.1145/800031.808606 http://keithp.com/~keithp/porterduff/p253-porter.pdf .

[ISO 19980] ISO. 2012. second edition. Ophthalmic instruments - Corneal topographers.

[IHE RAD TF-1] IHE International. 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 1 Integration Profiles. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol1.pdf .

[IHE RAD TF-2] IHE International. 2020. Integrating the Healthcare Enterprise Radiology Technical Framework Volume 2 Transactions. http://www.ihe.net/uploadedFiles/Documents/Radiology/IHE_RAD_TF_Vol2.pdf .

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Reference Model Definitions

This Part of the Standard makes use of the following terms defined in [ISO 7498-1]:

Application Entity: See [ISO 7498-1].
Service: See [ISO 7498-1].
Application Entity Title (AET): See [ISO 7498-1].

3.2 Service Conventions Definitions

This Part of the Standard makes use of the following terms defined in [ISO/TR 8509]:

Primitive: See [ISO/TR 8509].

3.3 DICOM Introduction and Overview Definitions

This Part of the Standard makes use of the following terms defined in PS3.1:

Attribute: See Attribute in PS3.1 .
Command: See Command in PS3.1 .
Data Dictionary: See Data Dictionary in PS3.1 .
Information Object: See Information Object in PS3.1 .
Message: See Message in PS3.1 .
Service-Object Pair Class (SOP Class): See Service-Object Pair Class in PS3.1 .

3.4 DICOM Upper Layer Service Definitions

This Part of the Standard makes use of the following terms defined in PS3.8:

DICOM Upper Layer Service: See DICOM Upper Layer Service in PS3.8 .

3.5 DICOM Message Exchange Definitions

This Part of the Standard makes use of the following terms defined in PS3.7:

DICOM Message Service Element (DIMSE): See DICOM Message Service Element in PS3.7 .
DIMSE-N Services: See DIMSE-N Services in PS3.7 .
DIMSE-C Services: See DIMSE-C Services in PS3.7 .
DIMSE Service Group (DSG): See DIMSE Service Group in PS3.7 .

3.6 DICOM Information Object Definitions

This Part of the Standard makes use of the following terms defined in PS3.3:

Attribute Tag: See Attribute Tag in PS3.3 .
Composite IOD: See Composite IOD in PS3.3 .
DICOM Application Model: See DICOM Application Model in PS3.3 .
DICOM Information Model: See DICOM Information Model in PS3.3 .
Information Object Definition (IOD): See Information Object Definition in PS3.3 .
Module: See Module in PS3.3 .
Normalized IOD: See Normalized IOD in PS3.3 .
Functional Group: See Functional Group in PS3.3 .

3.7 DICOM Conformance

This Part of the Standard makes use of the following terms defined in PS3.2:

Conformance Statement: See Conformance Statement in PS3.2 .
Standard SOP Class: See Standard SOP Class in PS3.2 .
Specialized SOP Class: See Specialized SOP Class in PS3.2 .
Standard Extended SOP Class: See Standard Extended SOP Class in PS3.2 .
Private SOP Class: See Private SOP Class in PS3.2 .
Standard Attribute: See Standard Attribute in PS3.2 .
Private Attribute: See Private Attribute in PS3.2 .

3.8 DICOM Data Structures and Encoding

This Part of the Standard makes use of the following terms defined in PS3.5:

Data Element: See Data Element in PS3.5 .
Data Set: See Data Set in PS3.5 .
Default Character Repertoire: See Default Character Repertoire in PS3.5 .
Unique Identifier (UID): See Unique Identifier in PS3.5 .

3.9 DICOM Service Class Definitions

The following definitions are commonly used in this Part of the DICOM Standard:

Classic Image Storage SOP Class: An Image Storage SOP Class that is defined by an IOD that stores a single frame and defines the majority of the Attributes in the top-level Data Set.
Combined Print Image: A pixel matrix created by superimposing an image and an overlay, the size of which is defined by the smallest rectangle enclosing the superimposed image and overlay.
Enhanced Image Storage SOP Class: An Image Storage SOP Class that is defined by an IOD that stores multiple frames and defines the majority of the Attributes in Functional Group Sequences.
Legacy Converted Enhanced Image Storage SOP Class: A modality-specific Enhanced Image Storage SOP Class that is defined by an IOD that defines only generic Functional Group Sequences, which does not require information that is not present in Classic Image Storage SOP Class Instances, and is intended for storage of converted Classic Image Storage SOP Class Instances when there is insufficient information to use a True Enhanced Image Storage SOP Class.
Meta Service-Object Pair Class (Meta SOP Class): A pre-defined set of SOP Classes that may be associated under a single SOP for the purpose of negotiating the use of the set with a single item.
Non-Patient Object: A SOP Instance that adheres to a Composite Instance IOD Information Model specified in PS3.3, but does not have the Patient Information Entity as its root. Non-Patient Object SOP Instances may still contain patient-related identifiable information, e.g., Inventory SOP Instances
Performed Procedure Step SOP Class: Any SOP Class that encodes the details about the performance of a procedure step.
Performed Procedure Step SOP Instance: An instance of a Performed Procedure Step SOP Class. Note that all UPS instances are instances of the UPS Push SOP Class, which is capable of encoding details about the performance of a procedure step (in addition to details about the scheduled procedure step) and thus qualify as an instance of a Performed Procedure Step SOP Class.
Preformatted Grayscale Image: An image where all annotation, graphics, and grayscale transformations (up to and including the VOI LUT) expected in the printed image have been burnt in or applied before being sent to the SCP. It is a displayable image where the polarity of the intended display is specified by Photometric Interpretation (0028,0004).
Preformatted Color Image: An image where all annotation, graphics, and color transformations expected in the printed image have been burnt in or applied before being sent to the SCP.
Real-World Activity: That which exists in the real world that pertains to specific area of information processing within the area of interest of the DICOM Standard. Such a Real-World Activity may be represented by one or more computer information metaphors called SOP Classes.
Real-World Object: That which exists in the real world upon which operations may be performed that are within the area of interest of the DICOM Standard. Such a Real-World Object may be represented through a computer information metaphor called a SOP Instance.
Related General SOP Class: A SOP Class that is related to another SOP Class as being more generalized in terms of behavior defined in the Standard, and that may be used to identically encode an instance with the same Attributes and values, other than the SOP Class UID. In particular, this may be the SOP Class from which a Specialized SOP Class (see PS3.2) is derived.
Service Class User (SCU): The role played by a DICOM Application Entity (DIMSE-Service-User) that invokes operations and performs notifications on a specific Association.
Service Class Provider (SCP): The role played by a DICOM Application Entity (DIMSE-Service-User) that performs operations and invokes notifications on a specific Association.
Service Class: A collection of SOP Classes and/or Meta SOP Classes that are related in that they are described together to accomplish a single application.
Service-Object Pair Instance (SOP Instance): A concrete occurrence of an Information Object that is managed by a DICOM Application Entity and may be operated upon in a communication context defined by a specific set of DIMSE Services (on a network or interchange media). A SOP Instance is persistent beyond the context of its communication.
True Enhanced Image Storage SOP Class: A modality-specific Enhanced Image Storage SOP Class that is defined by an IOD that defines modality-specific Functional Group Sequences, Attributes and sets of values, and is intended for creation by acquisition devices.

3.10 Device Independent Pixel Values

This Part of the Standard makes use of the following terms defined in PS3.3:

P-Value: See P-Value in PS3.3 .
Profile Connection Space Value (PCS-Value): See Profile Connection Space Value in PS3.3 .

3.11 HTTP Definitions

This Part of the Standard makes use of the following terms defined in [RFC7230]:

origin server: See [RFC7230].
user agent: See [RFC7230].

3.12 Structured Report Definitions

This Part of the Standard makes use of the following terms defined in PS3.3:

Content Item: See Content Item in PS3.3 .
Content Tree: See Content Tree in PS3.3 .

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part of the DICOM Standard.

ACR: American College of Radiology
ASCII: American Standard Code for Information Interchange
AE: Application Entity
ANSI: American National Standards Institute
CDS: Clinical Decision Support
CEN TC251: Comité Européen de Normalisation - Technical Committee 251 - Medical Informatics
Chest CAD: Computer-Aided Detection and/or Computer-Aided Diagnosis for chest radiography
DICOM: Digital Imaging and Communications in Medicine
DIMSE: DICOM Message Service Element
DIMSE-C: DICOM Message Service Element-Composite
DIMSE-N: DICOM Message Service Element-Normalized
HL7: Health Level 7
IE: Information Entity
IEEE: Institute of Electrical and Electronics Engineers
IOD: Information Object Definition
IS: Information System
ISO: International Standards Organization
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
JPIP: JPEG 2000 Interactive Protocol
MAR: Medication Administration Record
NEMA: National Electrical Manufacturers Association
OSI: Open Systems Interconnection
SCP: Service Class Provider
SCU: Service Class User
SOP: Service-Object Pair
UID: Unique Identifier

5 Conventions

5.1 Entity-Relationship Model

5.1.1 Entity

An entity is used in an Entity-Relationship (E-R) model to represent a Real-World Object, class of Real-World Objects, or DICOM data representation (such as IOD or Module). An entity is depicted as a box within this Part of the DICOM Standard as shown in Figure 5-1.

Figure 5-1. Entity Convention

5.1.2 Relationship

A relationship, which defines how entities are related, is depicted as a diamond within this Standard as shown in Figure 5-2.

Figure 5-2. Relationship Convention

The relationship is read from source to destination entity as indicated by the arrows. The a and b show the source and destination cardinality of the relationship respectively. The following cardinalities are permitted:

(a = 1, b = 1) -one source entity is related to one destination entity
(a = 1, b = 0-n) -one source entity is related to zero or more destination entities
(a = 1, b = 1-n) -one source entity is related to one or more destination entities
(a = 1-n, b = 1) -one or more source entities are related to one destination entity
(a = 1-n, b = 0-n) -one or more source entities are related to zero or more destination entities
(a = 1-n, b = 1-n) -one or more source entities are related to one or more destination entities

In a relationship where (a = 1-n, b = 1-n) the values of the source and destination cardinalities may be different. The value "n" simply denotes one or more.

Note

DICOM has added the use of arrows to the E-R diagramming conventions often used in other literature. This has been done to avoid the possibility of inferring an incorrect relationship that can result from reading a relationship in the reverse order of that intended. For example, a relationship "Cat Catches Mouse" could be read "Mouse Catches Cat" if the arrows were not present.

A relationship may be bi-directional (i.e., the relationship is true in both directions). In such a case, the convention used is arrows pointing toward both the source and the destination entities.

5.2 Sequences

Certain tables in this Part of the DICOM Standard denote a Sequence of Items by using the symbol: '>.'

In Annex A, '>' is used to identify a 'Sequence of Modules.' Nested Sequences of Modules are identified by '>>'. In Annex B and Annex C, '>' is used to identify a 'Sequence of Attributes'. See PS3.5 for the complete specification of how Sequences of Items shall be encoded.

Note

Information Object Definitions (IODs) that include the Sequence of Module construct are often called folders. The use of 'Sequences of Attributes' is not limited to 'Folders.'

5.3 Response Status Values

Certain tables in this Part of the DICOM Standard denote an implementation specific response Status Code by using the symbol 'xx' or 'xxx' as part of the code.

Note

Each 'x' symbol may be replaced by an implementation with a hexadecimal digit in the range from 0 to F.

5.4 Usage Specification

The building blocks of SOP Classes are Modules and DIMSE Services. The DIMSE Services associated with a SOP Class may be Mandatory (M) or Optional (U). The usage may be different for the SCU and SCP. The usage is specified as a pair of letters: the former indicating the SCU usage, the latter indicating the SCP usage.

5.4.1 Use of DIMSE Services

The meaning and behavior of the usage specification for DIMSE Services are:

M/M: The SCU shall support the DIMSE Service but is not required to use it on an Association. The SCP shall support the DIMSE Service.
U/M: The SCU may support and use the DIMSE Service. The SCP shall support the DIMSE Service.
U/U: The SCU may support and use the DIMSE Service. The SCP may support the DIMSE Service. If the SCP does not support the DIMSE Service used by the SCU, it shall return a Failure status.

5.4.2 Use of Attributes in Normalized Services

Modules and their usage in Composite IODs are defined in PS3.3. Normalized IODs are also constructed from Modules but usage is specified on an Attribute basis in this Part of the DICOM Standard. The following usage specification applies to all Attributes of Normalized IODs unless superseded by a usage specification in a particular SOP Class Specification.

The term ‘receive’ means the following: the value shall be stored; under certain circumstances (e.g. coercion) the value returned may have changed.

5.4.2.1 DIMSE Service N-CREATE, N-SET, N-ACTION

The following Requirements apply when specifying the use of DIMSE services N-CREATE, N-SET, N-ACTION.

The convention used in the table below are as follows:

SCU Behavior

Mandatory: The SCU shall provide the Attribute.
Optional: The SCU may or may not provide the Attribute.
Undefined: The SCU's usage of the Attribute is undefined.

SCP Behavior

Mandatory: The SCP shall support receiving the Attribute.
Mandatory with Default: The SCP shall support receiving the Attribute. Upon receiving zero-length values, the SCP shall assign values as defined by the specification of the Service Class.
Optional: The SCP may or may not support receiving the Attribute.
Undefined: The SCP’s support of the Attribute is undefined.

	SCU		SCP
Usage	Requirement	Zero Length	Requirement
1/1	Mandatory	Not Permitted	Mandatory
2/1	Mandatory	Permitted	Mandatory with Default
2/2	Mandatory	Permitted	Mandatory
3/1	Optional	Not Permitted	Mandatory
3/2	Optional	Not Permitted	Optional
3/3	Optional	Not Permitted	Optional
-/-	Undefined	Undefined	Undefined

If the SCU does not provide an Attribute that is Mandatory for the SCU, the SCP shall respond with a Failure Status Code of 0120H "Missing Attribute".

If the SCU provides a zero-length value for a Mandatory Attribute when zero length is not permitted, the SCP shall respond with a Failure Status Code of 0121H "Missing Attribute Value".

5.4.2.2 DIMSE Service N-GET, N-EVENT-REPORT

The following Requirements apply when specifying the use of DIMSE services N-GET, N-EVENT-REPORT.

The convention used in the table below are as follows:

SCU Behavior

Optional: The SCU may retrieve the Attribute.
Undefined: The SCU's usage of the Attribute is undefined.

SCP Behavior

Mandatory: The SCP shall support retrieval of the Attribute.
Optional: The SCP may or may not support retrieval of the Attribute.
Undefined: The SCP’s support of the Attribute is undefined.

	SCU	SCP
Usage	Requirement	Requirement	Zero Length
3/1	Optional	Mandatory	Not Permitted
3/2	Optional	Mandatory	Permitted
3/3	Optional	Optional	Not Permitted
-/1	Undefined	Mandatory	Not Permitted
-/2	Undefined	Mandatory	Permitted
-/3	Undefined	Optional	Not Permitted

If support of an Attribute by the SCP is optional and the SCP does not support the Attribute and the Attribute is requested by the SCU, the SCP shall respond with a Failure Status Code of 0106H "Invalid Attribute Value" or 0116H "Attribute Value out of range".

5.4.2.3 Other Requirements

If the SCP usage type designation is modified by a "C" (e.g., 3/1C) the specification stated above shall be modified to include the requirement that the SCP shall support the Attribute if the specified condition is met.

For all N-CREATE, N-SET, N-GET, N-DELETE, N-ACTION and N-EVENT-REPORT operations, the SOP Class is conveyed in the request primitive in Affected SOP Class UID (0000,0002). The SOP Class UID (0008,0016) Attribute shall not be present in the Data Set.

For N-CREATE operations and N-EVENT-REPORT notifications, the SOP Instance is conveyed in Affected SOP Instance UID (0000,1000). The SOP Instance UID (0008,0018) Attribute shall not be present in the Data Set.

Note

In some Service Classes, the SOP Class definition may override the general provision in PS3.7 that allows the SOP Instance UID to be specified or omitted in the N-CREATE request primitive, and require that the SCU be responsible for specifying the SOP Instance UID.

For N-SET, N-GET, N-ACTION and N-DELETE operations, the SOP Instance is conveyed in Requested SOP Instance UID (0000,1001). The SOP Instance UID (0008,0018) Attribute shall not be present in the Data Set.

6 DICOM Information Model

The DICOM Information Model defines the structure and organization of the information related to the communication of medical images. Figure 6-1 shows the relationships between the major structures of the DICOM Information Model.

6.1 Information Object Definition

An Information Object Definition (IOD) is an object-oriented abstract data model used to specify information about Real-World Objects. An IOD provides communicating Application Entities with a common view of the information to be exchanged.

Figure 6-1. Major Structures of DICOM Information Model

An IOD does not represent a specific instance of a Real-World Object, but rather a class of Real-World Objects that share the same properties. An IOD used to represent a single class of Real-World Objects is called a Normalized Information Object. An IOD that includes information about related Real-World Objects is called a Composite Information Object.

6.1.1 Composite IOD

A Composite IOD is an Information Object Definition that represents parts of several entities in the DICOM Model of the Real-World. (see PS3.3.) Such an IOD includes Attributes that are not inherent in the Real-World Object that the IOD represents but rather are inherent in related Real-World Objects.

These related Real-World Objects provide a complete context for the exchanged information. When an instance of a Composite IOD is communicated, this entire context is exchanged between Application Entities. Relationships between Composite IOD Instances shall be conveyed in this contextual information.

Note

Actual communication of IOD Instances is via SOP Instances.
Whenever Composite SOP Instances are in fact related, some of the contextual information is redundant (i.e., the same information about the same Real-World Objects is contained in multiple SOP Instances).

The Composite IODs are specified in PS3.3.

6.1.2 Normalized IOD

A Normalized IOD is an Information Object Definition that generally represents a single entity in the DICOM Model of the Real-World.

When an instance of a Normalized IOD is communicated, the context for that instance is not actually exchanged. Instead, the context is provided through the use of pointers to related Normalized IOD Instances.

The Normalized IODs are specified in PS3.3.

6.2 Attributes

The Attributes of an IOD describe the properties of a Real-World Object Instance. Related Attributes are grouped into Modules that represents a higher level of semantics documented in the Module Specifications found in PS3.3.

Attributes are encoded as Data Elements using the rules, the Value Representation and the Value Multiplicity concepts specified in PS3.5. For specific Data Elements, the Value Representation and Value Multiplicity of Data Elements are specified in the Data Dictionary in PS3.6.

6.3 On-Line Communication and Media Storage Services

For on-line communication the DIMSE Services and Web Services allow a DICOM Application Entity to invoke an operation or notification across a network or a point-to-point interface. DIMSE Services are defined in PS3.7 and Web Services are defined in PS3.18.

For media storage interchange, Media Storage Services allow a DICOM Application Entity to invoke media storage related operations.

Media Storage Services are discussed in PS3.10.

6.3.1 DIMSE-C Services

DIMSE-C Services are services applicable only to a Composite IOD. DIMSE-C provides only operation services.

6.3.2 DIMSE-N Services

DIMSE-N Services are services applicable only to a Normalized IOD. DIMSE-N provides both operation and notification services.

6.4 DIMSE Service Group

A DIMSE Service Group specifies one or more operations/notifications defined in PS3.7 that are applicable to an IOD.

DIMSE Service Groups are defined in this Part of the DICOM Standard, in the specification of a Service-Object Pair Class.

6.5 Service-Object Pair (SOP) Class

The SOP Class definitions in PS3.4 contain the rules and semantics that may restrict the use of the services in the DIMSE Service Group or the Attributes of the IOD. PS3.10 and PS3.18 contain the rules and semantics that may restrict the Attributes of the IOD or the use of the services in the Media Storage Services and the Web Services respectively.

The selection of SOP Classes is used by Application Entities to establish an agreed set of capabilities to support their interaction for SOP Classes based on DIMSE Services. This negotiation is performed at Association establishment time as described in PS3.7. An Extended Negotiation allows Application Entities to further agree on specific options within a SOP Class.

Note

The SOP Class as defined in the DICOM Information Model is equivalent in ISO/OSI terminology to the Managed Object Class. Readers familiar with object-oriented terminology will recognize the SOP Class operations (and notifications) as comprising the methods of an object class.
SOP Class Specifications play a central role in defining DICOM conformance. They allow DICOM Application Entities to select a well-defined application level subset of this Standard to which they may claim conformance. See PS3.2.

6.5.1 Normalized and Composite SOP Classes

DICOM defines two types of SOP Classes, Normalized and Composite. For DIMSE Services, Normalized SOP Classes are defined as the union of a Normalized IOD and a set of DIMSE-N Services, while Composite SOP Classes are defined as the union of a Composite IOD and a set of DIMSE-C Services. Media Storage Services only support Composite IODs and Web Services support both Normalized and Composite SOP Classes.

6.6 Association Negotiation

Association establishment is the first phase of communication between peer DICOM compliant Application Entities. The Application Entities shall use Association establishment to negotiate which SOP Classes can be exchanged and how this data will be encoded.

Association Negotiation is defined in PS3.7.

6.7 Service Class Specification

A Service Class Specification defines a group of one or more SOP Classes related to a specific function that is to be accomplished by communicating Application Entities. A Service Class Specification also defines rules that allow implementations to state some pre-defined level of conformance to one or more SOP Classes. Applications may conform to network SOP Classes as a Service Class User (SCU), Service Class Provider (SCP), user agent or origin server, and to media exchange SOP Classes as a File Set Creator (FSC), File Set Reader (FSR), or File Set Updater (FSU).

Service Class Specifications are defined in this Part of the DICOM Standard.

Note

Network interaction between peer Application Entities work on a 'client/server model.' The SCU or user agent acts as the 'client,' while the SCP or origin server acts as the 'server'. For DIMSE based services the SCU/SCP roles are determined during Association establishment.

7 DICOM Model of the Real World

The DICOM view of the Real-World that identifies the relevant Real-World Objects and their relationships within the scope of the DICOM Standard is described in the DICOM Model of the Real-World Section of PS3.3.

This section also describes the DICOM Information Model that identifies the various IODs specified by the DICOM Standard and their relationship.

8 Coded Entry Usage in Service Specifications

The Macros in this Section specify the usage of the Attributes that correspond to Coded Entries as defined by Table 8.8-1 Code Sequence Macro Attributes.

Not all invocations make use of all the columns. For example, in some invocations, only the "Requirement Type SCU/SCP" is relevant; in others, only the Matching Key Type and Return Key Type columns are used.

Table 8-1a. Enhanced SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning

Attribute Name	Tag	Requirement Type SCU/SCP	Matching Key Type	Return Key Type
Include Table 8-1b “Basic SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”
Equivalent Code Sequence	(0008,0121)	3/3	O	3
>Include Table 8-1b “Basic SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”

Attribute Name

Tag

Requirement Type

SCU/SCP

Matching Key Type

Return Key Type

Include Table 8-1b “Basic SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”

Equivalent Code Sequence

(0008,0121)

3/3

>Include Table 8-1b “Basic SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning”

Table 8-1b. Basic SCU/SCP Coded Entry Macro with SCU Support, Matching Key Support and Mandatory Meaning

Attribute Name	Tag	Requirement Type SCU/SCP	Matching Key Type	Return Key Type
Code Value	(0008,0100)	1C/1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.	RC Required if the code value length is 16 characters or less, and the code value is not a URN or URL.	1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.
Coding Scheme Designator	(0008,0102)	1C/1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.	RC Required if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.	1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.
Coding Scheme Version	(0008,0103)	1C/1C Required if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.	RC Required if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.	1C Required if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.
Code Meaning	(0008,0104)	1/1	-	1
Long Code Value	(0008,0119)	1C/1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.	RC Required if Code Value (0008,0100) is not present, and the code value is not a URN or URL.	1C Required if Code Value (0008,0100) is not present, and the code value is not a URN or URL.
URN Code Value	(0008,0120)	1C/1C Shall be present if Code Value (0008,0100) is not present, and the code value is a URN or URL.	RC Required if Code Value (0008,0100) is not present, and the code value is a URN or URL.	1C Require if Code Value (0008,0100) is not present, and the code value is a URN or URL.
Mapping Resource	(0008,0105)	3/3	-	3
Mapping Resource UID	(0008,0118)	3/3	-	3
Context Group Version	(0008,0106)	3/3	-	3
Context Group Extension Flag	(0008,010B)	3/3	-	3
Context Group Local Version	(0008,0107)	3/3	-	3
Context Group Extension Creator UID	(0008,010D)	3/3	-	3

Table 8-2a. Enhanced Coded Entry Macro with Optional Matching Key Support and Optional Meaning

Attribute Name	Tag	Matching Key Type	Return Key Type
Include Table 8-2b “Basic Coded Entry Macro with Optional Matching Key Support and Optional Meaning”
Equivalent Code Sequence	(0008,0121)	O	3
>Include Table 8-2b “Basic Coded Entry Macro with Optional Matching Key Support and Optional Meaning”

Table 8-2b. Basic Coded Entry Macro with Optional Matching Key Support and Optional Meaning

Attribute Name	Tag	Matching Key Type	Return Key Type
Code Value	(0008,0100)	O	1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.
Coding Scheme Designator	(0008,0102)	O	1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present.
Coding Scheme Version	(0008,0103)	OC May be present only if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously.	3 Applicable only if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously.
Code Meaning	(0008,0104)	O	3
Long Code Value	(0008,0119)	O	1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.
URN Code Value	(0008,0120)	O	1C Shall be present only if Code Value (0008,0100) is not present, and the code value is a URN or URL.
Mapping Resource	(0008,0105)	O	3
Mapping Resource UID	(0008,0118)	O	3
Context Group Version	(0008,0106)	O	3
Context Group Extension Flag	(0008,010B)	O	3
Context Group Local Version	(0008,0107)	O	3
Context Group Extension Creator UID	(0008,010D)	O	3

Table 8-3a. Enhanced SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support

Attribute Name	Tag	Requirement Type SCU/SCP	Matching Key Type
Include Table 8-3b “Basic SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”
Equivalent Code Sequence	(0008,0121)	-/3	-
>Include Table 8-3b “Basic SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Attribute Name

Tag

Requirement Type

SCU/SCP

Matching Key Type

Return Key Type

Include Table 8-3b “Basic SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Equivalent Code Sequence

(0008,0121)

-/3

>Include Table 8-3b “Basic SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support”

Table 8-3b. Basic SCU/SCP Coded Entry Macro with no SCU Support and no Matching Key Support

Attribute Name	Tag	Requirement Type SCU/SCP	Matching Key Type	Return Key Type
Code Value	(0008,0100)	-/1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.	-	1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.
Coding Scheme Designator	(0008,0102)	-/1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.	-	1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.
Coding Scheme Version	(0008,0103)	-/1C Required if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.	-	1C Shall be present if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.
Code Meaning	(0008,0104)	-/1	-	1
Long Code Value	(0008,0119)	-/1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.	-	1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.
URN Code Value	(0008,0120)	-/1C Shall be present if Code Value (0008,0100) is not present, and the code value is a URN or URL.	-	1C Shall be present if Code Value (0008,0100) is not present, and the code value is a URN or URL.
Mapping Resource	(0008,0105)	-/3	-	3
Mapping Resource UID	(0008,0118)	-/3	-	3
Context Group Version	(0008,0106)	-/3	-	3
Context Group Extension Flag	(0008,010B)	-/3	-	3
Context Group Local Version	(0008,0107)	-/3	-	3
Context Group Extension Creator UID	(0008,010D)	-/3	-	3

Table 8-4a. Enhanced Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning

Attribute Name	Tag	Matching Key Type	Return Key Type
Include Table 8-4b “Basic Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”
Equivalent Code Sequence	(0008,0121)	O	3
>Include Table 8-4b “Basic Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning”

Table 8-4b. Basic Coded Entry Macro with Optional Matching Key Support and Mandatory Meaning

Attribute Name	Tag	Matching Key Type	Return Key Type
Code Value	(0008,0100)	O	1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.
Coding Scheme Designator	(0008,0102)	O	1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.
Coding Scheme Version	(0008,0103)	RC Required if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.	1C Shall be present if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.
Code Meaning	(0008,0104)	O	1
Long Code Value	(0008,0119)	O	1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.
URN Code Value	(0008,0120)	O	1C Shall be present if Code Value (0008,0100) is not present, and the code value is a URN or URL.
Mapping Resource	(0008,0105)	O	3
Mapping Resource UID	(0008,0118)	O	3
Context Group Version	(0008,0106)	O	3
Context Group Extension Flag	(0008,010B)	O	3
Context Group Local Version	(0008,0107)	O	3
Context Group Extension Creator UID	(0008,010D)	O	3

Table 8-5a. Enhanced SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP

Attribute Name	Tag	Requirement Type SCU/SCP
Include Table 8-5b “Basic SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”
Equivalent Code Sequence	(0008,0121)	-/3
>Include Table 8-5b “Basic SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

Attribute Name

Tag

Requirement Type

SCU/SCP

Include Table 8-5b “Basic SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

Equivalent Code Sequence

(0008,0121)

-/3

>Include Table 8-5b “Basic SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP”

Table 8-5b. Basic SCU/SCP Coded Entry Macro with no SCU Support and Optional Meaning for SCP

Attribute Name	Tag	Requirement Type SCU/SCP
Code Value	(0008,0100)	-/1C Shall be present if the code value length is 16 characters or less, and the code value is not a URN or URL.
Coding Scheme Designator	(0008,0102)	-/1C Shall be present if Code Value (0008,0100) or Long Code Value (0008,0119) is present. May be present otherwise.
Coding Scheme Version	(0008,0103)	-/1C May be present if the value of Coding Scheme Designator (0008,0102) is present and is not sufficient to identify the Code Value (0008,0100) or Long Code Value (0008,0119) or URN Code Value (0008,0120) unambiguously. Shall not be present if Coding Scheme Designator (0008,0102) is absent. May be present otherwise.
Code Meaning	(0008,0104)	-/3
Long Code Value	(0008,0119)	-/1C Shall be present if Code Value (0008,0100) is not present, and the code value is not a URN or URL.
URN Code Value	(0008,0120)	1C/1C Shall be present if Code Value (0008,0100) is not present, and the code value is a URN or URL.
Mapping Resource	(0008,0105)	-/3
Mapping Resource UID	(0008,0118)	-/3
Context Group Version	(0008,0106)	-/3
Context Group Extension Flag	(0008,010B)	-/3
Context Group Local Version	(0008,0107)	-/3
Context Group Extension Creator UID	(0008,010D)	-/3

A Verification Service Class (Normative)

A.1 Overview

A.1.1 Scope

The Verification Service Class defines a service that verifies application level communication between peer DICOM AEs. This verification is accomplished on an established Association using the C-ECHO DIMSE-C service.

A.2 SCU/SCP Behavior

A DICOM AE, supporting the Verification SOP Class SCU role, requests verification of communication to a remote DICOM AE. This request is performed using the C-ECHO request primitive. The remote DICOM AE, supporting the Verification SOP Class SCP role, issues an C-ECHO response primitive. Upon receipt of the C-ECHO confirmation, the SCU determines that verification is complete. See PS3.7 for the specification of the C-ECHO primitives.

A.3 DIMSE-C Service Group

The C-ECHO DIMSE-C service shall be the mechanism used to verify communications between peer DICOM AEs. The C-ECHO service and protocol parameters shall be required as defined in PS3.7.

A.4 Verification SOP Class

The Verification SOP Class consists of the C-ECHO DIMSE-C service. No associated Information Object Definition is defined. The SOP Class UID shall be "1.2.840.10008.1.1".

No Specialized SOP Classes and/or Meta SOP Classes shall be defined for the Verification SOP Class.

A.5 Association Negotiation

Association establishment is the first phase of any instance of communication between peer DICOM AEs. The following negotiation rules apply to DICOM AEs that support the Verification SOP Class

The Association-requestor (verification SCU role) in the A-ASSOCIATE request shall convey an Abstract Syntax, in a Presentation Context, for the Verification SOP Class. The Abstract Syntax Name shall be equivalent to the Verification SOP Class UID.
The Association-acceptor (verification SCP role) in the A-ASSOCIATE response shall accept the Abstract Syntax, in a Presentation Context, for the supported Verification SOP Class.

No Application Association Information specific to the Verification SOP Class shall be used.

A.6 Conformance

A.6.1 Conformance Supporting the SCU Role

Implementations that conform to the Verification SOP Class SCU role shall meet the:

C-ECHO service requirements as defined by the DIMSE Service Group, Section A.3
Association negotiation rules as defined in Section A.5

A.6.2 Conformance Supporting the SCP Role

Implementations that conform to the Verification SOP Class SCP role shall meet the:

C-ECHO operation rules as defined by the DIMSE Service Group, Section A.3
Association negotiation rules as defined in Section A.5

A.6.3 Conformance Statement

An implementation may conform to the Verification SOP Class as an SCU, SCP, or both. The Conformance Statement shall be in the format defined in PS3.2.

B Storage Service Class (Normative)

B.1 Overview

B.1.1 Scope

The Storage Service Class defines an application-level class-of-service that facilitates the simple transfer of information Instances (objects).. It allows one DICOM AE to send images, waveforms, reports, etc., to another.

Information Object Definitions for Instances that are transferred under the Storage Service Class shall adhere to the Composite Instance IOD Information Model specified in PS3.3, and include at least the Patient, Study, and Series Information Entities.

B.1.2 Service Definition

Two peer DICOM AEs implement a SOP Class of the Storage Service Class with one serving in the SCU role and one serving in the SCP role. SOP Classes of the Storage Service Class are implemented using the C-STORE DIMSE-C service. C-STORE is described in PS3.7. A successful completion of the C-STORE has the following semantics:

Both the SCU and the SCP support the type of information to be stored.
The information is stored in some medium.
For some time frame, the information may be accessed.

Note

Support for Storage SOP Classes does not necessarily involve support for SOP Classes of the Query/Retrieve Service Class. How the information may be accessed is implementation dependent. It is required that some access method exists. This method may require an implementation dependent operation at the SCP of the Storage Service Class. The duration of the storage is also implementation dependent, but is described in the Conformance Statement of the SCP. Storage SOP Classes are intended to be used in a variety of environments: e.g., for modalities to transfer images to workstations or archives, for archives to transfer images to workstations or back to modalities, for workstations to transfer processed images to archives, etc.
For the JPIP Referenced Pixel Data transfer syntaxes, transfers may result in storage of incomplete information in that the pixel data may be partially or completely transferred by some other mechanism at the discretion of the SCP.

B.2 Behavior

This Section discusses the SCU and SCP behavior for SOP Classes of the Storage Service Class. The C-STORE DIMSE-C Service shall be the mechanism used to transfer SOP Instances between peer DICOM AEs as described in PS3.7.

B.2.1 Behavior of an SCU

The SCU invokes a C-STORE DIMSE Service with a SOP Instance that meets the requirements of the corresponding IOD. The SCU shall recognize the status of the C-STORE service and take appropriate action upon the success or failure of the service.

Note

The appropriate action is implementation dependent. It is required that the SCU distinguish between successful and failed C-STORE responses. Appropriate action may differ according to application, but are described in the Conformance Statement of the SCU.

B.2.2 Behavior of an SCP

An SCP of a Storage SOP Class acts as a performing DIMSE-service-user for the C-STORE Service. By performing this service successfully, the SCP indicates that the SOP Instance has been successfully stored.

B.2.3 Statuses

Table B.2-1 defines the specific Status Code values that might be returned in a C-STORE response. General Status Code values and fields related to Status Code values are defined for C-STORE DIMSE Service in PS3.7.

Table B.2-1. C-STORE Response Status Values

Service Status	Further Meaning	Status Codes	Related Fields
Failure	Refused: Out of resources	A7xx	(0000,0902)
	Error: Data Set does not match SOP Class	A9xx	(0000,0901) (0000,0902)
	Error: Cannot understand	Cxxx	(0000,0901) (0000,0902)
Warning	Coercion of Data Elements	B000	(0000,0901) (0000,0902)
	Data Set does not match SOP Class	B007	(0000,0901) (0000,0902)
	Elements Discarded	B006	(0000,0901) (0000,0902)
Success	Success	0000	None

Some Failure Status Codes are implementation specific.

An SCP implementation shall assign specific Failure Status Codes by replacing each 'x' symbol with a hexadecimal digit in the range from 0 to F. An SCP implementation wishing to differentiate between causes within the same Failure Meaning shall assign those causes specific Status Code Values within valid range specified in Table B.2-1.

An SCU implementation shall recognize any Failure Status Code within the value range specified in Table B.2-1 as an indicator of the Failure Meaning stated in the table. There is no requirement for an SCU implementation to differentiate between specific Status Codes within the valid range.

B.3 Association Negotiation

SCUs and SCPs of Storage SOP Classes operate on SOP Instances specific to the SOP Class. They may use the SOP Class Extended Negotiation Sub-Item defined in PS3.7. This Sub-Item allows DICOM AEs to exchange application information specific to SOP Class specifications. This is achieved by defining the Service-class-application-information field.

SCUs may use the SOP Class Common Extended Negotiation Sub-Item defined in PS3.7. This Sub-Item allows DICOM AEs to exchange information about the nature of the SOP Classes.

The SOP Class Extended Negotiation Sub-Item and SOP Class Common Extended Negotiation Sub-Item negotiation is optional for storage based SOP Classes.

The following negotiation rules apply to all DICOM SOP Classes and Specialized SOP Classes of the Storage Service Class.

The Association-requestor (Storage SCU role) in the A-ASSOCIATE request shall convey:

one Abstract Syntax, in a Presentation Context, for each supported SOP Class of the Storage Service Class
optionally, one SOP Class Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class
optionally, one SOP Class Common Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class

The Association-acceptor (Storage SCP role) in the A-ASSOCIATE request shall accept:

one Abstract Syntax, in a Presentation Context, for each supported SOP Class of the Storage Service Class
optionally, one SOP Class Extended Negotiation Sub-Item, for each supported SOP Class of the Storage Service Class

B.3.1 Extended Negotiation

At the time of Association establishment implementations may exchange information about their respective capabilities, as described in PS3.7 and PS3.8. SCUs and SCPs may use the SOP Class Extended Negotiation Sub-Item Structure as described in Section D.3.3.5 in PS3.7 to exchange information about the level of conformance and options supported. SCUs may use the SOP Class Common Extended Negotiation Sub-Item defined in Section D.3.3.6 in PS3.7 to exchange information about the nature of the SOP Classes.

Extended Negotiation is optional. In the event that either the SCU or the SCP does not support Extended Negotiation, the defaults shall apply.

B.3.1.1 Service-Class-Application-Information (A-ASSOCIATE-RQ)

The SOP Class Extended Negotiation Sub-Item is made of a sequence of mandatory fields as defined by PS3.7. Table B.3-1 shows the format of the Service-class-application-information field of the SOP Class Extended Negotiation Sub-Item for SOP Classes of the Storage Service Class in the A-ASSOCIATE-RQ.

Table B.3-1. Service-Class-Application-Information (A-ASSOCIATE-RQ)

Item Bytes	Field Name	Description of Field
1	Level of Storage Support	This byte field defines the supported Storage Level of the Association-requestor. It shall be encoded as an unsigned binary integer and shall use one of the following values: 0 - Storage Level 0 SCP 1 - Storage Level 1 SCP 2 - Storage Level 2 SCP 3 - N/A Association-requestor is SCU only If Extended Negotiation is not supported, the default shall have a value of 3.
2	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.
3	Level of Digital Signature Support	A Storage Level 2 SCP may further define its behavior in this byte field. 0 - The Signature Level is unspecified, the AE is an SCU only, or the AE is not a Storage Level 2 SCP 1 - Signature Level 1 2 - Signature Level 2 3 - Signature Level 3 If Extended Negotiation is not supported, the default shall have a value of 0.
4	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.
5	Element Coercion	This byte field defines whether the Association-requestor may coerce Data Elements. It shall be encoded as an unsigned binary integer and shall use one of the following values: 0 - does not coerce any Data Element 1 - may coerce Data Elements 2 - N/A - Association-requestor is SCU only If Extended Negotiation is not supported, the default shall have a value of 2.
6	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.

B.3.1.2 Service-Class-Application-Information (A-ASSOCIATE-AC)

The SOP Class Extended Negotiation Sub-Item is made of a sequence of mandatory fields as defined by PS3.7. Table B.3-2 shows the format of the Service-class-application-information field of the SOP Class Extended Negotiation Sub-Item for SOP Classes of the Storage Service Class in the A-ASSOCIATE-AC.

Table B.3-2. Service-Class-Application-Information (A-ASSOCIATE-AC)

Item Bytes	Field Name	Description of Field
1	Level of Storage Support	This byte field defines the supported Storage Level of the Association-acceptor. It shall be encoded as an unsigned binary integer and shall use one of the following values: 0 - Storage Level 0 SCP 1 - Storage Level 1 SCP 2 - Storage Level 2 SCP 3 - N/A - Association-acceptor is SCU only If Extended Negotiation is not supported, no assumptions shall be made by the Association-requestor about the capabilities of the Association-acceptor based upon this Extended Negotiation.
2	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.
3	Level of Digital Signature Support	A Level 2 SCP may further define its behavior in this byte field. 0 - The Signature Level is unspecified, the AE is an SCU only, or the AE is not a Storage Level 2 SCP 1 - Signature Level 1 2 - Signature Level 2 3 - Signature Level 3 If Extended Negotiation is not supported, no assumptions shall be made by the Association-requestor about the capabilities of the Association-acceptor based upon this Extended Negotiation.
4	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.
5	Element Coercion	This byte field defines whether the Association-acceptor may coerce Data Elements. It shall be encoded as an unsigned binary integer and shall use one of the following values: 0 - does not coerce any Data Element 1 - may coerce Data Elements 2 - N/A - Association-acceptor is SCU only If Extended Negotiation is not supported, no assumptions shall be made by the Association-requestor about the capabilities of the Association-acceptor based upon this Extended Negotiation.
6	Reserved	This reserved field shall be sent with a value 00H but not tested to this value when received.

B.3.1.3 Service Class UID (A-ASSOCIATE-RQ)

SOP Class Common Extended Negotiation Sub-Item allows the SCU to convey the Service Class UID of each proposed SOP Class.

The Storage Service Class UID shall be "1.2.840.10008.4.2".

B.3.1.4 Related General SOP Classes (A-ASSOCIATE-RQ)

A limited set of Standard SOP Classes in the Storage Service Class are defined to have one or more Related General SOP Classes. The Related General SOP Classes may be conveyed using the SOP Class Common Extended Negotiation during association establishment as defined in PS3.7. Table B.3-3 identifies which Standard SOP Classes participate in this mechanism. If a Standard SOP Class is not listed in this table, Related General SOP Classes shall not be included in a Related Storage SOP Class Extended Negotiation Sub-Item.

Note

Implementation-defined Specialized SOP Classes (see PS3.2) of the Storage Service Class may convey a Related General SOP Class.

Table B.3-3. Standard and Related General SOP Classes

SOP Class Name	Related General SOP Class Name
12-lead ECG Waveform Storage	General ECG Waveform Storage
12-lead ECG Waveform Storage	General 32-bit ECG Waveform Storage
General ECG Waveform Storage	General 32-bit ECG Waveform Storage
Digital Mammography X-Ray Image Storage - For Presentation	Digital X-Ray Image Storage - For Presentation
Digital Mammography X-Ray Image Storage - For Processing	Digital X-Ray Image Storage - For Processing
Digital Intra-Oral X-Ray Image Storage - For Presentation	Digital X-Ray Image Storage - For Presentation
Digital Intra-Oral X-Ray Image Storage - For Processing	Digital X-Ray Image Storage - For Processing
Basic Text SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Enhanced SR Storage	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Comprehensive SR Storage	Comprehensive 3D SR Storage
Comprehensive SR Storage	Extensible SR Storage
Comprehensive 3D SR Storage	Extensible SR Storage
Procedure Log Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Simplified Adult Echo SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
X-Ray Radiation Dose SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Radiopharmaceutical Radiation Dose SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Patient Radiation Dose SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Enhanced X-Ray Radiation Dose SR Storage	Enhanced SR Storage
	Comprehensive SR Storage
	Comprehensive 3D SR Storage
	Extensible SR Storage
Acquisition Context SR Storage	Enhanced SR Storage (see note)
	Comprehensive SR Storage (see note)
	Comprehensive 3D SR Storage
	Extensible SR Storage
Spectacle Prescription Report Storage	Enhanced SR Storage
Macular Grid Thickness and Volume Report Storage	Enhanced SR Storage
Enhanced CT Image Storage	Legacy Converted Enhanced CT Image Storage
Enhanced MR Image Storage	Legacy Converted Enhanced MR Image Storage
Enhanced PET Image Storage	Legacy Converted Enhanced PET Image Storage

Note

The Acquisition Context SR may be encoded as Enhanced or Comprehensive SR only if it does not contain stereotactic coordinates (SCOORD3D).

B.4 Conformance

An implementation that conforms to Storage SOP Classes shall meet the:

C-STORE Service requirements as defined in Section B.2
Association requirements as defined in Section B.3

Note

No SCU or SCP behavior requirements other than those in this section are specified. In particular, an SCP of the Storage SOP Classes may not attach any significance to the particular association or associations over which C-STORE operations are requested, nor the order in which C-STORE operations occur within an association. No constraints are placed on the operations an SCU may perform during any particular association, other than those defined during association negotiation. An SCP may not expect an SCU to perform C-STORE operations in a particular order.

Similarly, no semantics are attached to the closing of an Association, such as the end of a Study or Performed Procedure Step.

B.4.1 Conformance as an SCP

B.4.1.1 Levels of Storage Support

Three Levels of Storage Support are defined for an SCP that claims conformance to the Storage SOP Classes:

Storage Level 0 (Local) indicates that a user-defined subset of the Attributes of the SOP Instance will be stored, and all others will be discarded. This subset of the Attributes shall be defined in the Conformance Statement of the implementer.
Storage Level 1 (Base) indicates that all Type 1 and 2 Attributes defined in the IOD associated with the SOP Class will be stored, and may be accessed. All other Data Elements may be discarded. The SCP may, but is not required to validate that the Attributes of the SOP Instance meets the requirements of the IOD.
Storage Level 2 (Full) indicates that all Type 1, Type 2, and Type 3 Attributes defined in the Information Object Definition associated with the SOP Class, as well as any Standard Extended Attributes (including Private Attributes) included in the SOP Instance, will be stored and may be accessed. The SCP may, but is not required to validate that the Attributes of the SOP Instance meet the requirements of the IOD.

Note

A Storage Level 2 SCP may discard (not store) Type 3 Attributes that are empty (zero length and no Value), since the meaning of an empty Type 3 Attribute is the same as absence of the Attribute. See PS3.5 definition of "Type 3 Optional Data Elements".

B.4.1.2 Support of Additional SOP Classes

An SCP that claims conformance to Storage Level 2 (Full) support of the Storage Service Class may accept any Presentation Context negotiation of a SOP Class that specifies the Storage Service Class during the SOP Class Common Extended Negotiation (see Section B.3.1.3), without asserting conformance to that SOP Class in its Conformance Statement.

Note

The SCP may support storage of all SOP Classes of the Storage Service Class, preserving all Attributes as a Storage Level 2 SCP.
This Extended Negotiation allows an SCP to determine that a Private SOP Class in a proposed Presentation Context follows the semantics of the Storage Service Class, and may be handled accordingly.

An SCP that claims conformance to Storage Level 2 (Full) support of a Related General SOP Class may accept any Presentation Context negotiation of a SOP Class that specifies that Related General SOP Class during the SOP Class Common Extended Negotiation, without asserting conformance to that Specialized SOP Class in its Conformance Statement.

Note

The term "specialized" in this section is used generically, including both Implementation-defined Specialized SOP Classes and Standard SOP Classes specified in Table B.3-3.
The SCP may handle instances of such Specialized SOP Classes using the semantics of the Related General SOP Class, but preserving all additional (potentially Type 1 or 2) Attributes as a Storage Level 2 SCP.
An SCP that has access to the current content of Table B.5-1 might use that to determine acceptance of proposed Presentation Context SOP Classes. This allows an SCP, even without Extended Negotiation, to be able to identify all Standard SOP Classes of the Storage Service Class. Access to Table B.5-1 may be through private means, or to the publication of PS3 on the web site of the DICOM Standards Committee. This provides an automated alternative to manually editing a table of supported Storage SOP Classes.

B.4.1.3 Coercion of Attributes

At any Level of Storage Support, the SCP of the Storage Service Class may modify the Values of certain Attributes in order to coerce the SOP Instance into the Query Model of the SCP. The Attributes that may be modified are shown in Table B.4-1.

Table B.4-1. Attributes Subject to Coercion

Attribute Name	Tag
Patient ID	(0010,0020)
Issuer of Patient ID	(0010,0021)
Other Patient IDs Sequence	(0010,1002)
Study Instance UID	(0020,000D)
Series Instance UID	(0020,000E)

The SCP of the Storage Service Class may modify the Values of Code Sequence Attributes to convert from one coding scheme into another. This includes changing from deprecated Values of Coding Scheme Designator (0008,0102) or Code Value (0008,0100) to currently valid Values.

If an SCP performs such a modification, it shall return a C-STORE response with a status of Warning.

Note

Modification of these Attributes may be necessary if the SCP is also an SCP of a Query/Retrieve SOP Classes. These SOP Classes are described in this Standard. For example, an MR scanner may be implemented to generate Study Instance UIDs for images generated on the MR. When these images are sent to an archive that is HIS/RIS aware, it may choose to change the UID of the study assigned to the study by the PACS. The mechanism by which it performs this coercion is implementation dependent.
An SCP may, for instance, convert retired Code Values with a Coding Scheme Designator Value of "99SDM", "SNM3" or "SRT" to the corresponding SCT Code Values and use the "SCT" Coding Scheme Designator, in accordance with the DICOM conventions for SNOMED (see PS3.16).
Modification of Attributes that may be used to reference a SOP Instance by another SOP Instance (such as Study Instance UID and Series Instance UID Attributes) will make that reference invalid. Modification of these Attributes is strongly discouraged.
Other Attributes may be modified/corrected by an SCP of a Storage SOP Class.
Modification of Attributes may affect digital signatures referencing the content of the SOP Instance.

B.4.1.4 Levels of Digital Signature Support

Three levels of Digital Signature Support are defined for an SCP that claims conformance to Storage Level 2 (Full):

At Signature Level 1, the SCP may not preserve Digital Signatures and does not replace them.
At Signature Level 2, the SCP does not preserve the integrity of incoming Digital Signatures, but does validate the Digital Signatures of SOP Instances being stored, takes implementation-specific measures for ensuring the integrity of data stored, and will add replacement Digital Signatures before sending SOP Instances elsewhere.
At Signature Level 3, the SCP does preserve the integrity of incoming Digital Signatures (i.e., is bit-preserving and stores and retrieves all Attributes regardless of whether they are defined in the IOD).

B.4.2 Conformance as an SCU

The SCU shall generate only C-STORE requests with SOP Instances that meet the requirements of the IOD associated with the SOP Class.

B.4.2.1 SCU Fall-Back Behavior

During Association Negotiation, an application may propose a Specialized SOP Class and its Related General SOP Class in separate Presentation Contexts as a Storage SCU. If the Association Acceptor rejects the Specialized SOP Class Presentation Context, but accepts the Related General SOP Class Presentation Context, the application may send instances of the Specialized SOP Class as instances of the Related General SOP Class. In this fall-back behavior, the SOP Class UID of the instance shall be the UID of the Related General SOP Class, and any special semantics associated with the Specialized SOP Class may be lost; the SOP Instance UID shall remain the same.

Note

The SCU may include the SOP Class UID of the original intended Specialized SOP Class in the Attribute Original Specialized SOP Class UID (0008,001B) of the instance sent under the Related General SOP Class. In some cases, e.g., when all intermediate storage applications are Storage Level 2 SCPs, this may allow an ultimate receiver of the instance to recast it as an instance of the Specialized SOP Class IOD. However, this transformation is not guaranteed.

B.4.3 Conformance Statement Requirements

An implementation may conform to a SOP Class of the Storage Service Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.

B.4.3.1 Conformance Statement for an SCU

The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage SOP Class as an SCU:

The behavior of the SCU in the case of a successful C-STORE response status shall be described.
The behavior of the SCU in each case of an unsuccessful C-STORE response status shall be described.
The behavior of the SCU in the case of a Warning status received in response to a C-STORE operation.
Whether Extended Negotiation is supported.
The optional elements that may be included in Storage SOP Instances for each IOD supported shall be listed.
The standard and privately defined Functional Groups that may be included in Storage SOP Instances for each Multi-frame IOD that support Functional Groups.
The behavior of the SCU in the case of a C-STORE operation using a referenced pixel data transfer syntax such as JPIP Referenced Pixel Data Transfer Syntax shall be described. This includes the duration of validity of the reference

B.4.3.2 Conformance Statement for an SCP

The following issues shall be documented in the Conformance Statement of any implementation claiming conformance to the Storage Service Class as an SCP:

The Level of Storage Support, as defined by Section B.4.1, shall be stated.
The Level of Digital Signature Support, as defined by Section B.4.1, shall be stated.
The optional Attributes that will be discarded (if any) shall be listed for each IOD supported.
The mechanisms by which additional SOP Classes are dynamically supported, as defined by Section B.4.1.2, shall be stated.
The Conformance Statement shall document the policies concerning the Attribute Lossy Image Compression (0028,2110).
The behavior of the SCP in the case of a successful C-STORE operation shall be described. This includes the following:
- the access method for a stored SOP Instance
- the duration of the storage
The meaning of each case of an unsuccessful C-STORE response status shall be described, as well as appropriate recovery action.
The meaning of each case of a warning C-STORE response status shall be described, as well as appropriate action.
If the SCP performs coercion on any Attributes, this shall be stated, and the conditions under which it may occur shall be described.

B.4.4 Specialized Conformance

Implementations may provide Specialized SOP Class conformance by providing a proper superset of the SOP Instances to be stored. Implementations providing Specialized SOP Class Conformance to one of the SOP Classes defined in this Annex shall be conformant as described in the following sections and shall include within their Conformance Statement information as described in the following sections.

An implementation shall be permitted to conform as a Specialization of the Standard SOP Class as an SCU, SCP or both. The Conformance Statement shall be in the format defined in PS3.2.

B.4.4.1 Specialized SOP Class Identification

Any implementation that specializes the Standard SOP Class shall define its specialization as an Allomorphic subclass of the Standard SOP Class. As such, the specialization shall have its own unique SOP Class identification.

The Conformance Statement shall include a SOP Class Identification Statement as defined in PS3.2, declaring a SOP Name and SOP Class UID that identify the Specialized SOP Class. The SOP Name is not guaranteed to be unique (unless the implementer chooses to copyright it) but is provided for informal identification of the SOP Class. The SOP Class UID shall uniquely identify the Specialized SOP Class and conform to the DICOM UID requirements as specified in PS3.5.

B.4.4.2 Specialized Information Object Definition

The Standard SOP Class may be specialized by supporting additional private Attributes. The Conformance Statement shall describe these specializations and shall be formatted as defined in PS3.2.

B.5 Standard SOP Classes

The SOP Classes in the Storage Service Class identify the Composite IODs to be stored. Table B.5-1 identifies Standard SOP Classes.

Table B.5-1. Standard SOP Classes

SOP Class Name	SOP Class UID	IOD Specification (defined in PS3.3)	Specialization
Computed Radiography Image Storage	1.2.840.10008.5.1.4.1.1.1	Computed Radiography Image IOD
Digital X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.1.1	Digital X-Ray Image IOD	B.5.1.1
Digital X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.1.1.1	Digital X-Ray Image IOD	B.5.1.1
Digital Mammography X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.1.2	Digital Mammography X-Ray Image IOD	B.5.1.2
Digital Mammography X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.1.2.1	Digital Mammography X-Ray Image IOD	B.5.1.2
Digital Intra-Oral X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.1.3	Digital Intra-Oral X-Ray Image IOD	B.5.1.3
Digital Intra-Oral X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.1.3.1	Digital Intra-Oral X-Ray Image IOD	B.5.1.3
CT Image Storage	1.2.840.10008.5.1.4.1.1.2	CT Image IOD
Enhanced CT Image Storage	1.2.840.10008.5.1.4.1.1.2.1	Enhanced CT Image IOD	B.5.1.7 B.5.1.23
Legacy Converted Enhanced CT Image Storage	1.2.840.10008.5.1.4.1.1.2.2	Legacy Converted Enhanced CT Image IOD	B.5.1.7 B.5.1.23
Ultrasound Multi-frame Image Storage	1.2.840.10008.5.1.4.1.1.3.1	Ultrasound Multi-frame Image IOD
MR Image Storage	1.2.840.10008.5.1.4.1.1.4	MR Image IOD
Enhanced MR Image Storage	1.2.840.10008.5.1.4.1.1.4.1	Enhanced MR Image IOD	B.5.1.6 B.5.1.23
MR Spectroscopy Storage	1.2.840.10008.5.1.4.1.1.4.2	MR Spectroscopy IOD
Enhanced MR Color Image Storage	1.2.840.10008.5.1.4.1.1.4.3	Enhanced MR Color Image IOD	B.5.1.8 B.5.1.23
Legacy Converted Enhanced MR Image Storage	1.2.840.10008.5.1.4.1.1.4.4	Legacy Converted Enhanced MR Image IOD	B.5.1.6 B.5.1.23
Ultrasound Image Storage	1.2.840.10008.5.1.4.1.1.6.1	Ultrasound Image IOD
Enhanced US Volume Storage	1.2.840.10008.5.1.4.1.1.6.2	Enhanced US Volume IOD
Photoacoustic Image Storage	1.2.840.10008.5.1.4.1.1.6.3	Photoacoustic Image IOD
Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7	Secondary Capture Image IOD
Multi-frame Single Bit Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7.1	Multi-frame Single Bit Secondary Capture Image IOD
Multi-frame Grayscale Byte Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7.2	Multi-frame Grayscale Byte Secondary Capture Image IOD
Multi-frame Grayscale Word Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7.3	Multi-frame Grayscale Word Secondary Capture Image IOD
Multi-frame True Color Secondary Capture Image Storage	1.2.840.10008.5.1.4.1.1.7.4	Multi-frame True Color Secondary Capture Image IOD
12-lead ECG Waveform Storage	1.2.840.10008.5.1.4.1.1.9.1.1	12-Lead ECG IOD
General ECG Waveform Storage	1.2.840.10008.5.1.4.1.1.9.1.2	General ECG IOD
Ambulatory ECG Waveform Storage	1.2.840.10008.5.1.4.1.1.9.1.3	Ambulatory ECG IOD
General 32-bit ECG Waveform Storage	1.2.840.10008.5.1.4.1.1.9.1.4	General 32-bit ECG IOD
Hemodynamic Waveform Storage	1.2.840.10008.5.1.4.1.1.9.2.1	Hemodynamic Waveform IOD
Cardiac Electrophysiology Waveform Storage	1.2.840.10008.5.1.4.1.1.9.3.1	Basic Cardiac Electrophysiology Waveform IOD
Basic Voice Audio Waveform Storage	1.2.840.10008.5.1.4.1.1.9.4.1	Basic Voice Audio Waveform IOD
General Audio Waveform Storage	1.2.840.10008.5.1.4.1.1.9.4.2	General Audio Waveform IOD
Arterial Pulse Waveform Storage	1.2.840.10008.5.1.4.1.1.9.5.1	Arterial Pulse Waveform IOD
Respiratory Waveform Storage	1.2.840.10008.5.1.4.1.1.9.6.1	Respiratory Waveform IOD
Multi-channel Respiratory Waveform Storage	1.2.840.10008.5.1.4.1.1.9.6.2	Multi-channel Respiratory Waveform IOD
Routine Scalp Electroencephalogram Waveform Storage	1.2.840.10008.5.1.4.1.1.9.7.1	Routine Scalp Electroencephalogram IOD
Electromyogram Waveform Storage	1.2.840.10008.5.1.4.1.1.9.7.2	Electromyogram IOD
Electrooculogram Waveform Storage	1.2.840.10008.5.1.4.1.1.9.7.3	Electrooculogram IOD
Sleep Electroencephalogram Waveform Storage	1.2.840.10008.5.1.4.1.1.9.7.4	Sleep Electroencephalogram IOD
Body Position Waveform Storage	1.2.840.10008.5.1.4.1.1.9.8.1	Body Position Waveform IOD
Grayscale Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.1	Grayscale Softcopy Presentation State IOD
Color Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.2	Color Softcopy Presentation State IOD
Pseudo-Color Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.3	Pseudo-color Softcopy Presentation State IOD
Blending Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.4	Blending Softcopy Presentation State IOD
XA/XRF Grayscale Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.5	XA/XRF Grayscale Softcopy Presentation State IOD
Grayscale Planar MPR Volumetric Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.6	Planar MPR Volumetric Presentation State IOD	B.5.1.19
Compositing Planar MPR Volumetric Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.7	Planar MPR Volumetric Presentation State IOD	B.5.1.19
Advanced Blending Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.8	Advanced Blending Presentation State IOD
Volume Rendering Volumetric Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.9	Volume Rendering Volumetric Presentation State IOD	B.5.1.24
Segmented Volume Rendering Volumetric Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.10	Volume Rendering Volumetric Presentation State IOD	B.5.1.24
Multiple Volume Rendering Volumetric Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.11	Volume Rendering Volumetric Presentation State IOD	B.5.1.24
Variable Modality LUT Softcopy Presentation State Storage	1.2.840.10008.5.1.4.1.1.11.12	Variable Modality LUT Softcopy Presentation State IOD
X-Ray Angiographic Image Storage	1.2.840.10008.5.1.4.1.1.12.1	X-Ray Angiographic Image IOD
Enhanced XA Image Storage	1.2.840.10008.5.1.4.1.1.12.1.1	Enhanced XA Image IOD
X-Ray Radiofluoroscopic Image Storage	1.2.840.10008.5.1.4.1.1.12.2	X-Ray Radiofluoroscopic Image IOD
Enhanced XRF Image Storage	1.2.840.10008.5.1.4.1.1.12.2.1	Enhanced XRF Image IOD
X-Ray 3D Angiographic Image Storage	1.2.840.10008.5.1.4.1.1.13.1.1	X-Ray 3D Angiographic Image IOD
X-Ray 3D Craniofacial Image Storage	1.2.840.10008.5.1.4.1.1.13.1.2	X-Ray 3D Craniofacial Image IOD
Breast Tomosynthesis Image Storage	1.2.840.10008.5.1.4.1.1.13.1.3	Breast Tomosynthesis Image IOD
Breast Projection X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.13.1.4	Breast Projection X-Ray Image IOD	B.5.1.18
Breast Projection X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.13.1.5	Breast Projection X-Ray Image IOD	B.5.1.18
Intravascular Optical Coherence Tomography Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.14.1	Intravascular Optical Coherence Tomography Image IOD	B.5.1.13
Intravascular Optical Coherence Tomography Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.14.2	Intravascular Optical Coherence Tomography Image IOD	B.5.1.13
Nuclear Medicine Image Storage	1.2.840.10008.5.1.4.1.1.20	Nuclear Medicine Image IOD
Parametric Map Storage	1.2.840.10008.5.1.4.1.1.30	Parametric Map IOD
Raw Data Storage	1.2.840.10008.5.1.4.1.1.66	Raw Data IOD	B.5.1.22
Spatial Registration Storage	1.2.840.10008.5.1.4.1.1.66.1	Spatial Registration IOD
Spatial Fiducials Storage	1.2.840.10008.5.1.4.1.1.66.2	Spatial Fiducials IOD
Deformable Spatial Registration Storage	1.2.840.10008.5.1.4.1.1.66.3	Deformable Spatial Registration IOD
Segmentation Storage	1.2.840.10008.5.1.4.1.1.66.4	Segmentation IOD	B.5.1.25
Surface Segmentation Storage	1.2.840.10008.5.1.4.1.1.66.5	Surface Segmentation IOD
Tractography Results Storage	1.2.840.10008.5.1.4.1.1.66.6	Tractography Results IOD
Label Map Segmentation Storage	1.2.840.10008.5.1.4.1.1.66.7	Segmentation IOD	B.5.1.25
Height Map Segmentation Storage	1.2.840.10008.5.1.4.1.1.66.8	Height Map Segmentation IOD
Real World Value Mapping Storage	1.2.840.10008.5.1.4.1.1.67	Real World Value Mapping IOD
Surface Scan Mesh Storage	1.2.840.10008.5.1.4.1.1.68.1	Surface Scan Mesh IOD
Surface Scan Point Cloud Storage	1.2.840.10008.5.1.4.1.1.68.2	Surface Scan Point Cloud IOD
VL Endoscopic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.1	VL Endoscopic Image IOD
Video Endoscopic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.1.1	Video Endoscopic Image IOD
VL Microscopic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.2	VL Microscopic Image IOD
Video Microscopic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.2.1	Video Microscopic Image IOD
VL Slide-Coordinates Microscopic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.3	VL Slide-Coordinates Microscopic Image IOD
VL Photographic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.4	VL Photographic Image IOD
Video Photographic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.4.1	Video Photographic Image IOD
Ophthalmic Photography 8 Bit Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.1	Ophthalmic Photography 8 Bit Image IOD
Ophthalmic Photography 16 Bit Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.2	Ophthalmic Photography 16 Bit Image IOD
Stereometric Relationship Storage	1.2.840.10008.5.1.4.1.1.77.1.5.3	Stereometric Relationship IOD
Ophthalmic Tomography Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.4	Ophthalmic Tomography Image IOD
Wide Field Ophthalmic Photography Stereographic Projection Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.5	Wide Field Ophthalmic Photography Stereographic Projection Image IOD
Wide Field Ophthalmic Photography 3D Coordinates Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.6	Wide Field Ophthalmic Photography 3D Coordinates Image IOD
Ophthalmic Optical Coherence Tomography En Face Image Storage	1.2.840.10008.5.1.4.1.1.77.1.5.7	Ophthalmic Optical Coherence Tomography En Face Image IOD
Ophthalmic Optical Coherence Tomography B-scan Volume Analysis Storage	1.2.840.10008.5.1.4.1.1.77.1.5.8	Ophthalmic Optical Coherence Tomography B-scan Volume Analysis IOD
VL Whole Slide Microscopy Image Storage	1.2.840.10008.5.1.4.1.1.77.1.6	VL Whole Slide Microscopy Image IOD
Dermoscopic Photography Image Storage	1.2.840.10008.5.1.4.1.1.77.1.7	Dermoscopic Photography Image IOD
Confocal Microscopy Image Storage	1.2.840.10008.5.1.4.1.1.77.1.8	Confocal Microscopy Image IOD
Confocal Microscopy Tiled Pyramidal Image Storage	1.2.840.10008.5.1.4.1.1.77.1.9	Confocal Microscopy Tiled Pyramidal Image IOD
Lensometry Measurements Storage	1.2.840.10008.5.1.4.1.1.78.1	Lensometry Measurements IOD
Autorefraction Measurements Storage	1.2.840.10008.5.1.4.1.1.78.2	Autorefraction Measurements IOD
Keratometry Measurements Storage	1.2.840.10008.5.1.4.1.1.78.3	Keratometry Measurements IOD
Subjective Refraction Measurements Storage	1.2.840.10008.5.1.4.1.1.78.4	Subjective Refraction Measurements IOD
Visual Acuity Measurements Storage	1.2.840.10008.5.1.4.1.1.78.5	Visual Acuity Measurements IOD
Spectacle Prescription Report Storage	1.2.840.10008.5.1.4.1.1.78.6	Spectacle Prescription Report IOD	B.5.1.5
Ophthalmic Axial Measurements Storage	1.2.840.10008.5.1.4.1.1.78.7	Ophthalmic Axial Measurements IOD	B.5.1.11
Intraocular Lens Calculations Storage	1.2.840.10008.5.1.4.1.1.78.8	Intraocular Lens Calculations IOD
Macular Grid Thickness and Volume Report	1.2.840.10008.5.1.4.1.1.79.1	Macular Grid Thickness and Volume Report IOD	B.5.1.5
Ophthalmic Visual Field Static Perimetry Measurements Storage	1.2.840.10008.5.1.4.1.1.80.1	Ophthalmic Visual Field Static Perimetry Measurements IOD
Ophthalmic Thickness Map Storage	1.2.840.10008.5.1.4.1.1.81.1	Ophthalmic Thickness Map IOD	B.5.1.14
Corneal Topography Map Storage	1.2.840.10008.5.1.4.1.1.82.1	Corneal Topography Map IOD	B.5.1.17
Basic Text SR Storage	1.2.840.10008.5.1.4.1.1.88.11	Basic Text SR IOD	B.5.1.5
Enhanced SR Storage	1.2.840.10008.5.1.4.1.1.88.22	Enhanced SR IOD	B.5.1.5
Comprehensive SR Storage	1.2.840.10008.5.1.4.1.1.88.33	Comprehensive SR IOD	B.5.1.5
Comprehensive 3D SR Storage	1.2.840.10008.5.1.4.1.1.88.34	Comprehensive 3D SR IOD	B.5.1.5
Extensible SR Storage	1.2.840.10008.5.1.4.1.1.88.35	Extensible SR IOD	B.5.1.5
Procedure Log Storage	1.2.840.10008.5.1.4.1.1.88.40	Procedure Log IOD	B.5.1.5
Mammography CAD SR Storage	1.2.840.10008.5.1.4.1.1.88.50	Mammography CAD SR IOD	B.5.1.5
Key Object Selection Document Storage	1.2.840.10008.5.1.4.1.1.88.59	Key Object Selection Document IOD
Chest CAD SR Storage	1.2.840.10008.5.1.4.1.1.88.65	Chest CAD SR IOD	B.5.1.5
X-Ray Radiation Dose SR Storage	1.2.840.10008.5.1.4.1.1.88.67	X-Ray Radiation Dose SR IOD	B.5.1.5
Radiopharmaceutical Radiation Dose SR Storage	1.2.840.10008.5.1.4.1.1.88.68	Radiopharmaceutical Radiation Dose SR IOD	B.5.1.5
Colon CAD SR Storage	1.2.840.10008.5.1.4.1.1.88.69	Colon CAD SR IOD	B.5.1.5
Implantation Plan SR Storage	1.2.840.10008.5.1.4.1.1.88.70	Implantation Plan SR Document IOD	B.5.1.5
Acquisition Context SR Storage	1.2.840.10008.5.1.4.1.1.88.71	Acquisition Context SR IOD	B.5.1.5
Simplified Adult Echo SR Storage	1.2.840.10008.5.1.4.1.1.88.72	Simplified Adult Echo SR IOD	B.5.1.5
Patient Radiation Dose SR Storage	1.2.840.10008.5.1.4.1.1.88.73	Patient Radiation Dose SR IOD	B.5.1.5
Planned Imaging Agent Administration SR Storage	1.2.840.10008.5.1.4.1.1.88.74	Planned Imaging Agent Administration SR IOD	B.5.1.5
Performed Imaging Agent Administration SR Storage	1.2.840.10008.5.1.4.1.1.88.75	Performed Imaging Agent Administration SR IOD	B.5.1.5
Enhanced X-Ray Radiation Dose SR Storage	1.2.840.10008.5.1.4.1.1.88.76	Enhanced X-Ray Radiation Dose SR IOD	B.5.1.5
Waveform Annotation SR Storage	1.2.840.10008.5.1.4.1.1.88.77	Waveform Annotation SR IOD	B.5.1.5
Content Assessment Results Storage	1.2.840.10008.5.1.4.1.1.90.1	Content Assessment Results IOD	B.5.1.20
Microscopy Bulk Simple Annotations Storage	1.2.840.10008.5.1.4.1.1.91.1	Microscopy Bulk Simple Annotations IOD
Encapsulated PDF Storage	1.2.840.10008.5.1.4.1.1.104.1	Encapsulated PDF IOD
Encapsulated CDA Storage	1.2.840.10008.5.1.4.1.1.104.2	Encapsulated CDA IOD
Encapsulated STL Storage	1.2.840.10008.5.1.4.1.1.104.3	Encapsulated STL IOD
Encapsulated OBJ Storage	1.2.840.10008.5.1.4.1.1.104.4	Encapsulated OBJ IOD
Encapsulated MTL Storage	1.2.840.10008.5.1.4.1.1.104.5	Encapsulated MTL IOD
Positron Emission Tomography Image Storage	1.2.840.10008.5.1.4.1.1.128	Positron Emission Tomography Image IOD
Enhanced PET Image Storage	1.2.840.10008.5.1.4.1.1.130	Enhanced PET Image IOD	B.5.1.16 B.5.1.23
Legacy Converted Enhanced PET Image Storage	1.2.840.10008.5.1.4.1.1.128.1	Legacy Converted Enhanced PET Image IOD	B.5.1.23
Basic Structured Display Storage	1.2.840.10008.5.1.4.1.1.131	Basic Structured Display IOD	B.5.1.9
CT Performed Procedure Protocol Storage	1.2.840.10008.5.1.4.1.1.200.2	CT Performed Procedure Protocol IOD	B.5.1.21
XA Performed Procedure Protocol Storage	1.2.840.10008.5.1.4.1.1.200.8	XA Performed Procedure Protocol IOD	B.5.1.21
RT Image Storage	1.2.840.10008.5.1.4.1.1.481.1	RT Image IOD
RT Dose Storage	1.2.840.10008.5.1.4.1.1.481.2	RT Dose IOD
RT Structure Set Storage	1.2.840.10008.5.1.4.1.1.481.3	RT Structure Set IOD
RT Beams Treatment Record Storage	1.2.840.10008.5.1.4.1.1.481.4	RT Beams Treatment Record IOD
RT Plan Storage	1.2.840.10008.5.1.4.1.1.481.5	RT Plan IOD
RT Brachy Treatment Record Storage	1.2.840.10008.5.1.4.1.1.481.6	RT Brachy Treatment Record IOD
RT Treatment Summary Record Storage	1.2.840.10008.5.1.4.1.1.481.7	RT Treatment Summary Record IOD
RT Ion Plan Storage	1.2.840.10008.5.1.4.1.1.481.8	RT Ion Plan IOD
RT Ion Beams Treatment Record Storage	1.2.840.10008.5.1.4.1.1.481.9	RT Ion Beams Treatment Record IOD
RT Physician Intent Storage	1.2.840.10008.5.1.4.1.1.481.10	RT Physician Intent IOD
RT Segment Annotation Storage	1.2.840.10008.5.1.4.1.1.481.11	RT Segment Annotation IOD
RT Radiation Set Storage	1.2.840.10008.5.1.4.1.1.481.12