PS3.2

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

Conformance Statements are critical to interoperability because they provide important information for implementers and system integrators in order to determine whether or not applications do interoperate. In addition, when issues occur, they provide a source of information in order to potentially resolve any problems. Lastly, it is important to provide potential implementers with a consistent template for generating these documents.

PS3.2 defines principles that implementations claiming conformance to the Standard shall follow. PS3.2 specifies:

the minimum general conformance requirements that must be met by any implementation claiming conformance to the DICOM Standard. Additional conformance requirements for particular features, Service Classes, Information Objects, and communications protocols may be found in the conformance sections of other Parts of the DICOM Standard;
the purpose and structure of a Conformance Statement. PS3.2 provides a framework by which conformance information can be placed into a Conformance Statement as dictated by the conformance sections of other Parts of the DICOM Standard.

The DICOM Standard does not specify:

testing or validation procedures to assess an implementation's conformance to the Standard;
testing or validation procedures to assess whether an implementation matches to its Conformance Statement;
what optional features, Service Classes, or Information Objects should be supported for a given type of device.

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.

[ISO 8649] ISO. 1988. Information Processing Systems - Open Systems Interconnection - Service definition for the Association Control Service Element (ACSE).

[ISO 8822] ISO. 1988. Information Processing Systems - Open Systems Interconnection - Connection oriented presentation service definition.

3 Definitions

For the purposes of this Standard the following definitions apply.

3.1 Reference Model Definitions

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

Application Entity (AE): See [ISO 7498-1].
Application Entity Title: See [ISO 7498-1].
Protocol Data Unit: See [ISO 7498-1].
Transfer Syntax: See [ISO 7498-1].

3.2 ACSE Service Definitions

This Part makes use of the following terms defined in [ISO 8649]:

Association: See [ISO 8649].
Association Initiator: See [ISO 8649].

3.3 Presentation Service Definitions

This Part makes use of the following terms defined in [ISO 8822]:

Abstract Syntax: See [ISO 8822].
Abstract Syntax Name: See [ISO 8822].
Presentation Context: See [ISO 8822].
Transfer Syntax Name: See [ISO 8822].

3.4 DICOM Introduction and Overview Definitions

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

Conformance Statement: See Conformance Statement in PS3.1 .
Information Object: See Information Object in PS3.1 .
Service-Object Pair Class (SOP Class): See Service-Object Pair Class in PS3.1 .

3.5 DICOM Information Object Definitions

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

Information Object Definition (IOD): See Information Object Definition in PS3.3 .

3.6 DICOM Service Class Specification Definitions

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

Real-World Activity: See Real-World Activity in PS3.4 .
Service Class: See Service Class in PS3.4 .
Service Class User (SCU): See Service Class User in PS3.4 .
Service Class Provider (SCP): See Service Class Provider in PS3.4 .
Meta Service-Object Pair Class (Meta SOP Class): See Meta Service-Object Pair Class in PS3.4 .

3.7 DICOM Data Structure and Encoding Definitions

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

Data Set: See Data Set in PS3.5 .
DICOM Transfer Syntax: See DICOM Transfer Syntax in PS3.5 .
Unique Identifier (UID): See Unique Identifier in PS3.5 .

3.8 DICOM Message Exchange Definitions

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

Extended Negotiation: See Extended Negotiation in PS3.7 .
Implementation Class UID: See Implementation Class UID in PS3.7 .

3.9 DICOM Upper Layer Service Definitions

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

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

3.10 Media Storage and File Format for Data Interchange

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

File-set: See File-set in PS3.10 .
File-set Creator (FSC): See File-set Creator in PS3.10 .
File-set Reader (FSR): See File-set Reader in PS3.10 .
File-set Updater (FSU): See File-set Updater in PS3.10 .
Media Storage Application Profile: See Media Storage Application Profile in PS3.10 .

3.11 DICOM Conformance

This Part uses the following definitions:

Standard SOP Class

A SOP Class defined in the DICOM Standard that is used in an implementation with no modifications.

Standard Extended SOP Class

A SOP Class defined in the DICOM Standard extended in an implementation with additional Type 3 Attributes. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The semantics of the related Standard SOP Class shall not be modified by the additional Type 3 Attributes when absent. Therefore, the Standard Extended SOP Class utilizes the same UID as the related Standard SOP Class.

Note

IODs from a Standard Extended SOP Class may be freely exchanged between DICOM implementations since implementations that do not recognize the additional Type 3 Attributes would simply ignore them.

Specialized SOP Class

A SOP Class derived from a Standard SOP Class that has been specialized in an implementation by additional Type 1, 1C, 2, 2C, or 3 Attributes, by enumeration of specific permitted values for Attributes, or by enumeration of specific permitted Templates. The additional Attributes may either be drawn from the Data Dictionary in PS3.6, or may be Private Attributes. The enumeration of permitted Attribute values or Templates shall be a subset of those permitted in the related Standard SOP Class. Since the semantics of the related Standard SOP Class may be modified by the additional Attributes, a Specialized SOP Class utilizes a Privately Defined UID that differs from the UID for the related Standard SOP Class.

Note

Since a Specialized SOP Class has a different UID than a Standard or Standard Extended SOP Class, other DICOM implementations may not recognize the Specialized SOP Class. Because of this limitation, a Specialized SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. Before different implementations can exchange Instances in a Specialized SOP Class, the implementations must agree on the UID, content (in particular the additional Type 1, 1C, 2, and 2C Attributes), and semantics of the Specialized SOP Class. A Specialized SOP Class may be used to create a new or experimental SOP Class that is closely related to a Standard SOP Class.
The Association Negotiation for a Specialized SOP Class may include a SOP Class Common Extended Negotiation Sub-Item (as defined in PS3.7) for identification of the Service Class and of the Related General SOP Class from which it was specialized. This may allow a receiving application, without prior agreement on the Specialized SOP Class IOD, to process Instances of that class as if they were instances of a Related General SOP Class.

Private SOP Class

A SOP Class that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.

Note

Since a Private SOP Class is not defined in the DICOM Standard, other DICOM implementations may not recognize the Private SOP Class. Because of this limitation, a Private SOP Class should only be used when a Standard or Standard Extended SOP Class would not be appropriate. In order for different implementations to exchange Instances in a Private SOP Class, the implementations must agree on the UID, content (in particular the Type 1, 1C, 2, and 2C Attributes), and semantics of the Private SOP Class. A Private SOP Class may be used to create a totally new or experimental SOP Class.

Standard Attribute

An Attribute defined in the Data Dictionary in PS3.6.

Private Attribute

An Attribute that is not defined in the DICOM Standard.

Standard Application Profile

An Application Profile defined in the DICOM Standard that is used in an implementation with no modifications.

Augmented Application Profile

An Application Profile derived from a Standard Application Profile by incorporating support for additional Standard or Standard Extended SOP Classes.

Private Application Profile

An Application Profile that is not defined in the DICOM Standard, but is published in an implementation's Conformance Statement.

Security Profile

A mechanism for selecting an appropriate set of choices from the Parts of the DICOM Standard along with corresponding security mechanisms (e.g., encryption algorithms) for the support of security facilities.

Transformation of DICOM SR to CDA

A mechanism for mapping and transforming DICOM SR objects to HL7 CDA documents.

3.12 Hypertext Transfer Protocol (HTTP/HTTPS) Definitions

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

HTTP: See HTTP in PS3.18 .
HTTPS: See HTTPS in PS3.18 .
origin server: See origin server in PS3.18 .
user agent: See user agent in PS3.18 .

3.13 Web Services Definitions

This Part makes use of the following terms defined in PS3.18

Bulk Data: See Bulk Data in PS3.18 .
Bulk Data URI: See Bulk Data URI in PS3.18 .
DICOM Object: See DICOM Object in PS3.18 .
DICOM Resource: See DICOM Resource in PS3.18 .
DIMSE Proxy: See DIMSE Proxy in PS3.18 .
Event Report: See Event Report in PS3.18 .
Metadata: See Metadata in PS3.18 .
RESTful Web Service: See RESTful Web Service in PS3.18 .
Service: See Service in PS3.18 .
sRGB: See sRGB in PS3.18 .
Status Report: See Status Report in PS3.18 .
Subscriber: See Subscriber in PS3.18 .
Target URI: See Target URI in PS3.18 .
Thumbnail: See Thumbnail in PS3.18 .
Transaction: See Transaction in PS3.18 .
UTF-8: See UTF-8 in PS3.18 .

4 Symbols and Abbreviations

The following symbols and abbreviations are used in this Part.

ACR: American College of Radiology
ACSE: Association Control Service Element
AE: Application Entity
ANSI: American National Standards Institute
AP: Application Profile
API: Application Programming Interface
ASCII: American Standard Code for Information Interchange
CEN TC251: Comite Europeen de Normalisation-Technical Committee 251-Medical Informatics
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
FSC: File-set Creator
FSR: File-set Reader
FSU: File-set Updater
HISPP: Healthcare Informatics Standards Planning Panel
HL7: Health Level 7
IE: Information Entity
IEEE: Institute of Electrical and Electronics Engineers
IOD: Information Object Definition
ISO: International Standards Organization
ISP: International Standardized Profile
JIRA: Japan Medical Imaging and Radiological Systems Industries Association
MSDS: Healthcare Message Standard Developers Sub-Committee
NEMA: National Electrical Manufacturers Association
OSI: Open Systems Interconnection
PDU: Protocol Data Unit
QIDO-RS: Query based on ID for DICOM Objects by RESTful Services
REST: Representational State Transfer
RESTful: A RESTful Web service is a Web service implemented using REST architecture and HTTP (see http://www.ics.uci.edu/~fielding/pubs/dissertation/fielding_dissertation.pdf)
RWA: Real-World Activity
SCP: Service Class Provider
SCU: Service Class User
SOP: Service-Object Pair
STOW-RS: STore Over the Web by RESTful Services
TCP/IP: Transmission Control Protocol/Internet Protocol
UID: Unique Identifier
UML: Unified Modeling Language
WADO-RS: Web Access to DICOM Objects by RESTful Services
WADO-URI: Web Access to DICOM Objects by URI

5 Conventions

5.1 Application Data Flow Diagram

In a Conformance Statement, the relationships between Real-World Activities and Application Entities are illustrated by an Application Data Flow Diagram.

5.1.1 Application Entity

An Application Entity is depicted as a box in an Application Data Flow Diagram, shown in Figure 5.1-1

Figure 5.1-1. Application Entity Convention

5.1.2 Real-World Activity

A Real-World Activity is depicted as a circle in an Application Data Flow Diagram, shown in Figure 5.1-2.

Figure 5.1-2. Real-World Activity Convention

Circles representing multiple Real-World Activities may overlap, indicating a degree of overlap in the Real-World Activities.

5.1.3 Local Relationships

A relationship between a local Real-World Activity and an Application Entity is depicted within an Application Data Flow Diagram by placing the local Real-World Activity to the left of the related Application Entity with a dashed line between them as shown in Figure 5.1-3.

Figure 5.1-3. Local Relationship Convention

An Application Entity may be associated with multiple Real-World Activities.

A Real-World Activity may be associated with multiple Application Entities.

5.1.4 Network-Associations

An Association between a local Application Entity and a remote Application Entity over a network supporting a remote Real-World Activity is depicted within an Application Data Flow Diagram by placing the remote Real-World Activity to the right of the related local Application Entity with one or two arrows drawn between them as shown in Figure 5.1-4. The dashed line represents the DICOM Standard Interface, which could be DICOM DIMSE, DICOM Web Services or DICOM Real Time Video, between the local Application Entities, and whichever remote Application Entities handle the remote Real-World Activities. An arrow from the remote Real-World Activity to the local Application Entity indicates that the local Application Entity expects to receive an Association request when the remote Real-World Activity occurs, causing the local Application Entity to perform the local Real-World Activity.

Figure 5.1-4. Associations Convention

5.1.5 Media Storage File-Set Access

Application Entities exchanging information on media use the DICOM File Service as specified in PS3.10 for access to, or creation of, File-sets. This File Service provides operations that support three basic roles, which are File-set Creator (FSC), File-set Reader (FSR), and File-set Updater (FSU).

These roles are depicted on an Application Data Flow diagram by directional arrows placed between the local Application Entities and the DICOM Storage Media on which the roles are applied.

File-set Creator (FSC), denoted by
File-set Reader (FSR), denoted by
File-set Updater (FSU), denoted by
Physical movement of the medium, denoted by (with or without arrowhead)

Figure 5.1-5 illustrates the three basic roles.

Figure 5.1-5. File-Set Access

The local interactions shown on the left between a local Real-World activity and a local Application Entity are depicted by a dashed line. The arrows on the right represent access by the local Application Entity to a File-set on the DICOM Storage Medium. When an Application Entity supports several roles, this combination is depicted with multiple arrows corresponding to each of the roles. The dotted arrow symbolizes the removable nature of media for an interchange application.

Note

The use of two arrows relative to an FSC and an FSR should be distinguished from the case where a double arrow relative to an FSU is used. For example, an FSU may update a File-set without creating a new File-set, whereas a combined FSC and FSR may be used to create and verify a File-set.

6 Purpose of a Conformance Statement

An implementation need not employ all the optional components of the DICOM Standard. After meeting the minimum general requirements, a conformant DICOM implementation may utilize whatever SOP Classes, communications protocols, Media Storage Application Profiles, optional (Type 3) Attributes, codes and controlled terminology, etc., needed to accomplish its designed task.

Note

In fact, it is expected that an implementation might only support the SOP Classes related to its Real World Activities. For example, a simple film digitizer may not support the SOP Classes for other imaging modalities since such support may not be required. On the other hand, a complex storage server might be required to support SOP Classes from multiple modalities in order to adequately function as a storage server. The choice of which components of the DICOM Standard are utilized by an implementation depends heavily on the intended application and is beyond the scope of this Standard.

In addition, the DICOM Standard allows an implementation to extend or specialize the DICOM defined SOP Classes, as well as define Private SOP Classes.

A Conformance Statement allows a user to determine which optional components of the DICOM Standard are supported by a particular implementation, and what additional extensions or specializations an implementation adds. By comparing the Conformance Statements from two different implementations, a knowledgeable user should be able to determine whether and to what extent communications might be supported between the two implementations.

The content of Conformance Statement uses a consistent structure regardless of whether the implementation supports a DIMSE interface, a DICOM Media Storage interface, a DICOM Web Service interface, DICOM Real Time Video interface, or a combination thereof. A single Conformance Statement shall be provided with the appropriate sections filled in. Sections not relevant for the implementation shall be kept and marked as not applicable. Subsections of a section marked as not applicable need not be included in the Conformance Statement (see the template in Annex N).

The first part of the Conformance Statement contains a DICOM Conformance Statement Overview, which is typically a short summary at the beginning of the document providing a high level description of the system. It should list the transfer capabilities, DIMSE Services, Media Services, DICOM Web Services and DICOM Real Time Video Services, including their roles (SCU/SCP, FSC, FSR, etc.), and supported Transfer Syntaxes. This overview should also include a list of all Root Templates supported by the system.

6.1 Overview of Implementation Model Section For Conformance Statements

A functional overview containing the Application Data Flow Diagram that shows all the Application Entities. It also shows how they relate to both local and remote Real-World Activities.

6.2 Overview of Service and Interoperability Description Section For Conformance Statements

The Service and Interoperability description section of a Conformance Statement consists of the following major parts:

6.2.1 Mapping of Services to Application Entities

Provides an overview of the Application Entities and the Services supported by each AE.

6.2.2 Supported DIMSE Services

Provides a more detailed specification of each SOP Classes supported within the various services (Worklist, MPPS, Storage, Query/Retrieve, Print, etc.)
Provides for each SOP Class related to an Abstract Syntax, a list of any SOP options supported;
Provides a description of any extensions, specializations, and publicly disclosed privatizations in this implementation;
Provides a description of any implementation details that may be related to DICOM conformance or interoperability;
Provides a description of which codes and controlled terminology mechanisms are used.

6.2.3 Supported DICOM Web Services

Provides a more detailed specification of each DICOM Web Service supported

6.2.4 Supported Media Storage Services Section For Conformance Statements

The media storage section of a Conformance Statement consists of the following major parts:

a more detailed specification of each Application Entity listing the Media Storage Application Profiles supported, which outlines the policies with which it creates, reads, or updates File-sets on the media;
a description of any extensions, specializations, and publicly disclosed privatizations in this implementation such as Augmented or Private Application Profiles;
a description of any implementation details that may be related to DICOM conformance or interoperability;
a description of which codes and controlled terminology mechanisms are used.

6.3 Overview of DICOM Configuration Section For Conformance Statements

Section describing DICOM-related configuration details for the supported communication mechanisms:

DIMSE Services
DICOM Web Services
Media Storage Services
Real Time Video Services
Audit Trail - Syslog

6.4 Overview of Network and Media Communication Details Section For Conformance Statements

The network and Media Communication Details section of a Conformance Statement consists of the following major parts:

Real-World activity Data Flow Diagrams that shows the sequencing activities among the Application Entities
Association parameters
Policies with which each Application Entity and Real-World Activity combination initiates or accepts Associations
Transfer syntaxes selection preferences
Status codes and handling for DIMSE Services and DICOM Web Services

7 Conformance Requirements

An implementation claiming DICOM conformance may choose to support one or more of the following communication mechanisms:

Conformance to the DIMSE protocol (see Section 7.1.1 DIMSE Protocol Conformance Requirements)
Conformance to DICOM Web Services (see Section 7.1.2 DICOM Web Services Conformance Requirements)
Conformance to DICOM Media Storage (see Section 7.2 DICOM Media Interchange Conformance Requirements)
Conformance to the DICOM Real Time Video (see Section 7.8 DICOM Real Time Video Conformance Requirements)

7.1 DICOM Networking Conformance Requirements

7.1.1 DIMSE Protocol Conformance Requirements

An implementation claiming DIMSE network conformance shall:

conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Standard or Standard Extended SOP Class as defined in PS3.4;

Note

Conformance to a Standard or Standard Extended SOP Class implies conformance to the related IOD outlined in PS3.3, the Data Elements defined in PS3.6, and the operations and notifications defined in PS3.7.

comply with the rules governing SOP Class types outlined in Section 7.3;
accept a Presentation Context for the Verification SOP Class as an SCP if the implementation accepts any DICOM Association requests;
produce and/or process Data Sets as defined in PS3.5;

Note

Conformance to PS3.5 also implies conformance to PS3.6.

obtain a legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard);
support the following communication mode:
- TCP/IP (See PS3.8).

7.1.2 DICOM Web Services Conformance Requirements

An implementation claiming DICOM Web Services conformance shall:

conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Service as defined in PS3.18;

Note

Conformance to a Service implies conformance to the related Resources defined in PS3.18 and IODs outlined in PS3.3, and Data Elements defined in PS3.6.
comply with the rules governing SOP Class types outlined in Section 7.3;
produce and/or process Data Sets as defined in PS3.5 and/or PS3.18;

Note

Conformance to PS3.5 and/or PS3.18 also implies conformance to PS3.6.
obtain a legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).

7.2 DICOM Media Interchange Conformance Requirements

An implementation claiming DICOM Media Interchange conformance shall:

conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in Annex N;
conform to at least one Standard Application Profile as defined in PS3.11;
support one of the Physical Media and associated Media Format, as specified by PS3.12;
comply with the rules governing SOP Class types outlined in Section 7.3;
comply with the specific rules governing media storage Application Profile according to their types as specified in Section 7.4. No other types of Application Profiles may be used;
read as an FSR or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles encoded in any of the mandatory Transfer Syntaxes.
write as an FSC or FSU all SOP Classes defined as mandatory by each of the supported Application Profiles in one of the mandatory Transfer Syntaxes;
be able to gracefully ignore any Standard, Standard Extended, Specialized or Private SOP Classes that may be present on the Storage Medium but are not defined in any of the Application Profiles to which conformance is claimed.

Note

There may be more than one Application Profile used to create or read a File-set on a single physical medium (e.g., a medium may have a File-set created with Standard and Augmented Application Profiles).

be able to gracefully ignore Directory Records in the DICOMDIR file that do not correspond to Directory Records defined in any of the Application Profiles to which conformance is claimed.
access the File-set(s) on media using the standard roles defined in PS3.10;
produce and/or process Data Sets as defined in PS3.5 encapsulated in DICOM Files;

Note

Conformance to PS3.5 also implies conformance to PS3.6

obtain legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).

An implementation that does not meet all the above requirements shall not claim conformance to DICOM for Media Storage Interchange.

7.3 Rules Governing Types of SOP Classes

Each SOP Class published in a Conformance Statement is one of four basic types. Each SOP Class in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of SOP Class.

Standard SOP Classes conform to all relevant Parts of the DICOM Standard with no additions or changes.

To claim conformance to a Standard SOP Class, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.

Standard Extended SOP Classes shall:

be a proper super set of one Standard SOP Class;
not change the semantics of any Standard Attribute of that Standard SOP Class;
not contain any Private Type 1, 1C, 2, or 2C Attributes, nor add additional Standard Type 1, 1C, 2 or 2C Attributes;
not change any Standard Type 3 Attributes to Type 1, 1C, 2, or 2C;
use the same UID as the Standard SOP Class on which it is based.

A Standard Extended SOP Class may include Standard and/or Private Type 3 Attributes beyond those defined in the IOD on which it is based as long as the Conformance Statement identifies the added Attributes and defines their relationship with the PS3.3 information model. If additional Type 3 Attributes drawn from the Data Dictionary in PS3.6 are sent that affect the encoding of other Attributes, or whose encoding depends on the values of other Attributes, their presence and use shall be consistent.

Note

E.g., An Attribute such as Pixel Padding Value (0028,0120) with a dictionary VR of US or SS would not be allowed to be present without Pixel Representation (0028,0103) also being present to resolve the encoding ambiguity. Further, Pixel Padding Value would not be allowed to be present in the absence of the Pixel Data (7FE0,0010) to which it applies.

An implementation claiming conformance with a Standard Extended SOP Class shall identify in its Conformance Statement the Standard SOP Class being extended, the options, roles, and behavior selected, and describe the Attributes being added with the Standard SOP Class's IOD Model and Modules.

Specialized SOP Classes shall:

be completely conformant to relevant Parts of the DICOM Standard;
be based on a Standard SOP Class, i.e.:
- contain all the Type 1, 1C, 2, and 2C Attributes of Standard SOP Class on which it is based;
- not change the semantics of any Standard Attribute;
- use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);
be based on the DICOM Information Model in PS3.3 and PS3.4.

Specialized SOP Classes may:

contain additional Standard and/or Private Type 1, 1C, 2, or 2C Attributes;
add Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

Note

The usage of any unpublished Attributes may be ignored by other users and providers of the Specialized SOP Class.
enumerate the permitted values for Attributes within the set allowed by the Standard SOP Class;
enumerate the permitted Templates for Content Items within the set allowed by the Standard SOP Class.

An implementation claiming conformance with a Specialized SOP Class shall include in its Conformance Statement the identity of the Standard SOP Class being specialized, a description of usage of all Standard and Private Type 1, 1C, 2, and 2C Attributes in the Specialized SOP Class, a description of the constraints on Attributes values and Templates, and the associated Privately Defined UID.

Private SOP Classes shall:

be completely conformant to relevant Parts of the DICOM Standard with the possible exception that support of the DICOM Default Transfer Syntax or a Transfer Syntax mandated by a media storage Application Profile is not required;
not change the PS3.6 specification of any Standard Attributes;
use a Privately Defined UID for its SOP Class (i.e., shall not be identified with a DICOM Defined UID);
not change existing DIMSE Services or create new ones;
not change existing DICOM File Services defined in PS3.10 or extend them in a manner that jeopardizes interoperability.

Private SOP Classes may:

use or apply DIMSE Services to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);
use or apply Media Storage Operations to privately defined or altered IODs (i.e., not necessarily be based on a Standard SOP Class);
designate any Standard Attribute as Type 1, 1C, 2, or 2C regardless of the Type of the Attribute in other IODs;
define Private Attributes as Type 1, 1C, 2, or 2C;
include Private and Standard Type 3 Attributes, which may or may not be published in the Conformance Statement.

An implementation claiming conformance with a Private SOP Class shall provide a PS3.3, PS3.4, and PS3.6-like description of the Private SOP Class in the implementation's Conformance Statement, including descriptions of the usage of all Standard and Private Type 1, 1C, 2, or 2C Attributes in the SOP Class, the DICOM Information Model, and the Privately Defined UIDs.

Note

Unpublished SOP Classes (i.e., SOP Classes that are not defined in the DICOM Standard and are not defined in the Conformance Statement) are permitted in order to allow an implementation to support other abstract syntaxes within the DICOM Application Context. Such unpublished SOP Classes would utilize Privately Defined UIDs. The presence of an unpublished SOP Class does not prevent the implementation from being DICOM conformant but would have no meaning to other implementations and may be ignored.

7.4 Rules Governing Types of Application Profiles

Application Profile used in a Conformance Statement shall be of one of three basic types. Each Application Profile in an implementation claiming conformance to the DICOM Standard shall be handled in accordance with the following rules, as dictated by the type of Application Profile.

7.4.1 Standard Application Profile

A Standard Application Profile shall:

conform to all relevant Parts of DICOM with no changes;
support only one of the Physical Media and associated Media Format, as specified by PS3.12.

To claim conformance to a Standard Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and identify its selected options, roles, and behavior.

An implementation of a Standard Application Profile may extend Standard SOP Classes of this Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3.

7.4.2 Augmented Application Profile

An Augmented Application Profile shall:

be a proper super set of the Standard Application Profile. It adds the support of additional Standard or Standard Extended SOP Classes;
use the same Physical Media and its associated Media Format specified in the corresponding Standard Application Profile;
not include Specialized or Private SOP Classes.

An Augmented Application Profile may:

include one or more Standard or Standard Extended SOP Classes in addition to those of the corresponding Standard Application Profile. These additional SOP Classes may be mandatory or optional;
include the extensions (e.g., additional required keys, additional directory records) to the Basic Directory Information Object corresponding to the SOP Classes defined in a);
add one or more new roles (FSC, FSR, FSU).

To claim conformance to an Augmented Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall identify the Standard Application Profile from which it is derived and specify the augmentations. The implementation shall also identify its selected options, roles, and behavior.

An implementation of a Augmented Application Profile may:

extend Standard SOP Classes of the corresponding Standard application profile. Such Standard Extended SOP Classes shall meet the requirements specified in Section 7.3;
also claim conformance to the Standard Application Profile on which this Augmented Profile is based. In this case, FSC and FSU implementations shall be able to restrict their behavior to the Standard Application Profile (i.e., provide a means to write only the Standard or Standard Extended SOP Classes defined in the corresponding Standard Application Profile).

7.4.3 Private Application Profile

A Private Application Profile:

conforms to PS3.10 and to the Media Storage Service Class specified in PS3.4;
support only one of the Physical Media and associated Media Format, as specified by PS3.12;

Note

The intent of these two conditions is to ensure that at least the DICOMDIR is readable by other APs.
complies with the rules governing SOP Classes in Section 7.3.

To claim conformance to a Private Application Profile, an implementation shall make a declaration of this fact in its Conformance Statement, and shall provide a description of the Application Profile patterned after the descriptions in PS3.11. The implementation shall also identify its selected options, roles, and behavior.

Note

An implementation that does not meet the provisions of Section 7, including the types of Application Profile, is not conformant to DICOM and so is outside the scope of DICOM conformance. Such an implementation is not an Application Profile in DICOM terminology. For example, if an implementation chooses to write DICOM files onto media that is not in PS3.12, or use a file system not defined for a specific media type in PS3.12, then that implementation cannot claim that it conforms to the DICOM Standard using that media or file system.

7.5 Conformance of DICOM Media

DICOM does not define conformance of a piece of medium in a generic sense. DICOM conformance of a piece of medium can only be evaluated within the scope of one or more media storage Application Profiles that define specific contexts for interoperability.

Note

One may accept the statement "this is a DICOM CD-R" when pointing to a storage medium. However, one should not state "this CD-R is DICOM conformant", but rather "this CD-R conforms to the Basic Cardiac X-ray Angiographic DICOM Application Profile".

7.6 Security Profiles

DICOM specifies methods for providing security at different levels of the ISO OSI Basic Reference Model through the use of mechanisms specific to a particular layer. The methods for applying these mechanisms are described in the various parts of the DICOM Standard. Some mechanisms and algorithms are specified in PS3.15 as Security Profiles. An implementation's Conformance Statement describes which Security Profiles can be used by that application.

Note

For example, the Basic TLS Secure Transport Connection Profile defines a mechanism for authenticating entities participating in the exchange of data, and for protecting the integrity and confidentiality of information during interchange.

An implementation shall list in its Conformance Statement any Security Profiles that it supports, how it selects which Security Profiles it uses, how it uses features of that Security Profile, and any extensions it makes to that Security Profile.

An implementation shall list in its Conformance Statement any additional use of the User Identity Association negotiation sub-item that is not specified in a standard Security Profile.

7.7 Transformation of DICOM SR to CDA

DICOM specifies the transformation of DICOM SR objects to CDA documents in PS3.20.

This transformation is unidirectional (DICOM SR to HL7 CDA). Conformance statements shall at a minimum state conformance to the top level templates used for the SR document and the CDA document.

7.8 DICOM Real Time Video Conformance Requirements

An implementation claiming DICOM Real Time Video conformance shall:

conform to the minimum conformance requirements defined in this Section;
provide a Conformance Statement structured according to the rules and policies in this Part and follow the template provided in AnnexA;
conform to at least one Service as defined PS3.22;

Note

Conformance to a Service implies conformance to the related IODs outlined in PS3.3, and Data Elements defined in PS3.6.
comply with the rules governing SOP Class types outlined in Section 7.3;
produce and/or process Data Sets as defined in PS3.5 and/or PS3.22;

Note

Conformance to PS3.5 and/or PS3.22 also implies conformance to PS3.6;
obtain a legitimate right to a registered <org id> for creating UIDs (see PS3.5) if an implementation utilizes Privately Defined UIDs (i.e., UIDs not defined in the DICOM Standard).

A DICOM Conformance Statement Template (Retired)

Retired. See PS3.2-2022d

B Conformance Statement Sample Integrated Modality (Retired)

Retired. See PS3.2-2022d

C Conformance Statement Sample DICOMRis Interface (Retired)

Retired. See PS3.2-2022d

D Conformance Statement Sample DICOM Image Viewer (Retired)

Retired. See PS3.2-2022d

E Conformance Statement Example Print Server (Retired)

Retired. See PS3.2-2022d

F DICOM Conformance Statement Query-Retrieve-Server (Retired)

Retired. See PS3.2-2022d

G Conformance Statement Sample ImageViewer with Hanging Protocol Support (Retired)

Retired. See PS3.2-2022d

H DICOM Conformance Statement Medication-System-Gateway (Retired)

Retired. See PS3.2-2022d

I Conformance Statement Sample WADO Service (Retired)

Retired. See PS3.2-2022d

J Conformance Statement Sample STOW Service (Retired)

Retired. See PS3.2-2022d

K Conformance Statement Sample QIDO-RS Provider (Retired)

Retired. See PS3.2-2022d

L Conformance Statement Sample DICOM-RTV Service Provider (Retired)

Retired. See PS3.2-2022d

M Conformance Statement Sample DICOM-RTV Service Consumer (Retired)

Retired. See PS3.2-2022d

N DICOM Conformance Statement Template (Normative)

The content and organization of DICOM Conformance Statements shall conform to this template

The following formatting conventions are used in this template to guide Conformance Statement authors. Based on the format of the text used in the template, a DICOM Conformance Statement shall:

Include, without modification, text shown in regular font style (i.e., non-italic). Such text is standard "boilerplate" like introductions to sections, tables that list mandatory Attributes, etc.
Remove text shown in italic font style and [enclosed by square brackets]. Such text provides instructions to Conformance Statement authors on how to use this template. The text may be retained until the author has no further use for it but should be removed before publication of the Conformance Statement.
Either remove text shown in italic font style or modify it appropriately and change it to regular font style. Such text is example text that may provide typical phrasing, examples of the types of topics that might be addressed in a certain section, or list optional Attributes which should be deleted if not supported, etc.
Replace text <enclosed in angle brackets> with appropriate text. Such text is a placeholder for variables like the product name. Remove the < > characters when replacing the text.
Replace text <<enclosed in double angle brackets>> with a single Value from the enclosed list. Such text provides a list of alternatives such as DICOM Defined Terms for an Attribute Value. Remove the << >> characters when replacing the text.
- If Values other than those listed may be used, that is indicated by an ellipsis before the closing angle brackets (i.e., "…>>")
- If multiple Values can be selected, instruction text will document that fact.
- If some of the multiple Values are mandatory, the mandatory Values are shown in regular font style and the optional Values are shown in italic font style.

Note

Some sections and tables mix text in multiple fonts. Each piece of text is treated accordingly to its font style.

The following conventions are used in this template to encourage uniformity that makes it easier for consumers to read Conformance Statements from different vendors and find specific pieces of information. A DICOM Conformance Statement shall:

Indicate support in tables (e.g., in the "SCU" and "SCP" column of table with rows for SOP Classes) by using "Y" for yes and "N" for no.
Include rows in tables only for things (e.g., SOP Classes, Services, Attributes, etc.) supported by your implementation. Do not include rows for things that are not supported.
Format supported Value ranges in table cells using square brackets as follows: [lower Value … upper Value].
Format multiple supported Values in table cells separated by a semicolon in the cell.
Replace the content of Sections that are not applicable to the implementation with the text "N/A" and append "- N/A" to the end of the section title. This is done rather than deleting the section; however, if all the subsections in a section are marked "N/A", the subsections may be deleted, and, if so, the parent section should have the text "N/A" as content, and its title should have "- N/A" appended to its original title. This keeps the numbering of sections consistent throughout DICOM Conformance Statements for easier comparison.
If Sections need to be added, append them at the end of the parent Section in order to keep Section numbering consistent with this Template.
Tables shall be numbered sequentially within each major subsection. It is not necessary to follow the table numbering in the template, if specific tables are not applicable for the product described in this DICOM Conformance Statement.
Consider providing information (e.g., extensive explanation) as a footnote under the table when the information exceeds the comfortable size of the cell.

The Annexes are mandatory parts of this template and shall be populated if applicable to the implementation. For example, the IOD definitions must be filled in if the implementation supports creation of DICOM SOP Instances.

If throughout the document any of the tables get too wide for portrait mode it is recommended to switch to landscape mode for the table.

Tables are split into subsections for better readability. If a subsection of the table is not supported, remove the complete subsection from the table.

If the DICOM Conformance Statement describes multiple products/versions in one document, the cover page should indicate which products/versions are covered.

Ensure spelling throughout the entire DICOM Conformance Statement is consistent with the DICOM Standard.

If this template contradicts normative statements in other Parts of the DICOM Standard, those other Parts take precedence.

The template content begins after this line.

[When using this template for creation of a DICOM Conformance Statement, start numbering the actual document content with Section 1 for the Overview, not with N.1.]

N.0 Cover Page

[A DICOM Conformance Statement shall have a cover page, which shall include:

The commercial name(s) and version(s) of the concerned product or products (if applicable to several products) including all optional features. The product version shall correspond to the functionality as described in this Conformance Statement.
Date of the document

]

N.1 Overview

[Provide a short description of the product's DICOM functionality.]

[Edit the following illustration, depicting DICOM Services implemented in your product and the interactions with remote systems connected to product. Replace <Product> with your product name and <Remote Systems x> with a system category such as modality, PACS, RIS, or <DICOM Service> by the applicable service such as storage, query/ retrieve, query modality worklist, ….]

Figure N.1-1. Overview of Implemented Services

N.1.1 Content and Transfer

Table N.1-1 lists all Storage SOP Classes and the supported transfer mechanisms as well as the usage scenarios for those instances.

The "Transfer Syntax Set" column lists the sets of Transfer Syntaxes defined in Table N.1-2 that are applicable to each SOP Class. The "DIMSE", "DICOM Web" and "Media Services" columns indicate the roles supported for each SOP Class.

The "Function" columns indicate how the instances are used by the system:

Create: The system creates instances of the SOP Class. The type of the created SOP Class is indicated by one of the following abbreviations:
- S: Standard SOP Class
- SE: Standard Extended SOP Class
- SP: Specialized SOP Class
- P: Private SOP Class
Display: The system displays the instances of the SOP Class to the user, either by displaying the SOP Instances natively or by applying instances of another suitable SOP Class to the image instances (e.g., a Presentation State or CAD SR).
Process: The system processes the instances of the SOP Class to derive some further information that is made available to the user (e.g., a CAD processing algorithm, or a 3D Rendering).
Archive: The system stores the instances of the SOP Class and makes them available again.

[List all Storage SOP Classes supported by the system in numerical order of the SOP Class UID. Indicate in the "Transfer Syntax Set" column which of the Transfer Syntax Sets defined in Table N.1-2 are supported. Note that for each SOP Class, multiple Transfer Syntax Sets can be supported.]

[For the "Create Function" columns, use Values as defined above. For all other supported role/"Function" columns, list "Y" for yes and "N" for no.]

Table N.1-1. Storage SOP Classes

SOP Classes		Transfer Syntax Set	DIMSE Services		DICOM Web Services		Media Services			Function
			SCU	SCP	UA	OS	FSC	FSU	FSR	Create	Display	Process	Archive
Media Storage Directory Storage	1.2.840.10008.1.3.10	NI
Computed Radiography Image Storage	1.2.840.10008.5.1.4.1.1.1	U; LL; L
Digital X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.1.1	U; LL; L
Digital X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.1.1.1	U; LL; L
Digital Mammography X-Ray Image Storage - For Presentation	1.2.840.10008.5.1.4.1.1.1.2	U; LL
VL Photographic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.4	U; LL; L
Video Photographic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.4.1	V
Comprehensive SR Storage	1.2.840.10008.5.1.4.1.1.88.33	NI								See Table N.1-3
Mammography CAD SR Storage	1.2.840.10008.5.1.4.1.1.88.50									See Table N.1-3

[Table N.1-2 defines some example Transfer Syntax Sets that are referenced by their abbreviation in Table N.1-1 above. You can modify the Transfer Syntax Sets to match your product implementation and extend the Table with additional Transfer Syntax Sets as needed. For additional Transfer Syntax Sets, create additional rows and assign abbreviations in "() " that can be referenced in the Table above.]

Table N.1-2. Supported Transfer Syntaxes

Transfer Syntax Set	Transfer Syntax Name	Transfer Syntax UID	DICOM Web Service Bulkdata Media Type
Lossless Compressed Transfer Syntax Set (LL)	JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])	1.2.840.10008.1.2.4.70	image/jpeg
	JPEG 2000 Image Compression (Lossless Only)	1.2.840.10008.1.2.4.90	image/jp2
	RLE Lossless	1.2.840.10008.1.2.5	image/x-dicom-rle
Lossy Compressed Transfer Syntax Set (L)	JPEG Baseline (Process 1)	1.2.840.10008.1.2.4.50	image/jpeg
	JPEG Extended (Process 2 & 4)	1.2.840.10008.1.2.4.51	image/jpeg
	JPEG 2000 Image Compression	1.2.840.10008.1.2.4.91	image/jp2
Non-Image Transfer Syntax Set (NI)	Implicit VR Little Endian	1.2.840.10008.1.2	N/A
	Explicit VR Little Endian	1.2.840.10008.1.2.1	application/octet-stream
	Explicit VR Big Endian (Retired)	1.2.840.10008.1.2.2	N/A
Uncompressed Transfer Syntax Set (U)	Implicit VR Little Endian	1.2.840.10008.1.2	N/A
	Explicit VR Little Endian	1.2.840.10008.1.2.1	application/octet-stream
	Explicit VR Big Endian (Retired)	1.2.840.10008.1.2.2	N/A
Video Transfer Syntax Set (V)	MPEG2 Main Profile / Main Level	1.2.840.10008.1.2.4.100	video/mpeg2
	MPEG2 Main Profile / High Level	1.2.840.10008.1.2.4.101	video/mpeg2
	MPEG-4 AVC/H.264 High Profile / Level 4.1	1.2.840.10008.1.2.4.102	video/mp4
	MPEG-4 AVC/H.264 BD-compatible High Profile / Level 4.1	1.2.840.10008.1.2.4.103	video/mp4
	MPEG-4 AVC/H.264 High Profile / Level 4.2 For 2D Video	1.2.840.10008.1.2.4.104	video/mp4
Real-Time Video Transfer Syntax Set (RTV)	SMPTE ST 2110-20 Uncompressed Progressive Active Video	1.2.840.10008.1.2.7.1	N/A
	SMPTE ST 2110-20 Uncompressed Interlaced Active Video	1.2.840.10008.1.2.7.2	N/A
	SMPTE ST 2110-30 PCM Digital Audio	1.2.840.10008.1.2.7.3	N/A

N.1.1.1 Structured Reporting Root Template IDs

Table N.1-3 lists all Template IDs (TID) of Root Templates that are supported by the system. The "Function" column indicates how the system uses the content of the DICOM SR:

CREATE: The system creates instances using the specified TID.
RENDER: The system displays the content of the SR, without using the data for any processing.
EXTRACT_DATA: The system can extract structured data from the content and use the data for subsequent processing (e.g., reporting).
OVERLAY: The system uses the information in the SR to display information directly on the images (e.g., Mammography CAD markers).
ARCHIVE: The system stores instances for later retrieval.

The "SOP Class UID" column indicates which of the SR Storage SOP Classes are used to encode the information or to store it. If multiple SOP Classes are supported the "Condition" column describes the conditions for using the different SOP Classes.

[Table N.1-3 provides some examples, add/remove TIDs to match your product implementation. Add Root TIDs in ascending numerical order.

For guidance on the meaning of the columns see description above. Note that in the "Function" column multiple Values can be listed.

It is recommended to add a link to the "Root Template ID" column to the relevant subsection of Section N.10.]

Table N.1-3. Supported Root SR Template IDs (TIDs)

Name	Root TID	Function	SOP Classes		Condition
Mammography CAD Document Root	4000	CREATE; ARCHIVE; OVERLAY	Comprehensive SR Storage	1.2.840.10008.5.1.4.1.1.88.33	Based on association negotiation
Mammography CAD Document Root	4000	CREATE; ARCHIVE; OVERLAY	Mammography CAD SR Storage	1.2.840.10008.5.1.4.1.1.88.50	Based on association negotiation
Adult Echocardiography Procedure Report	5200	EXTRACT_DATA	Comprehensive SR Storage	1.2.840.10008.5.1.4.1.1.88.33

N.1.2 DIMSE Services

N.1.2.1 Verification

Table N.1-4 lists support for the Verification SOP Class.

[Modify Table N.1-4 to reflect support for the Verification SOP Class.]

Table N.1-4. Verification SOP Class

SOP Classes		Transfer Syntax		SCU	SCP
Verification	1.2.840.10008.1.1	Implicit VR Little Endian	1.2.840.10008.1.2
Verification	1.2.840.10008.1.1	Explicit VR Little Endian	1.2.840.10008.1.2.1

N.1.2.2 Storage

For details on supported Storage SOP Classes see Section N.1.1.

N.1.2.3 Workflow Management

Table N.1-5 lists all supported Workflow Management SOP Classes.

[Modify Table N.1-5 to reflect SOP Classes in the Workflow Management area that are supported. For each supported service indicate the role it supports. If it neither supports a SOP Class as SCU nor SCP, remove the respective line from the Table]

Table N.1-5. Workflow Management SOP Classes

SOP Classes		Transfer Syntax
Modality Worklist Information Model - FIND	1.2.840.10008.5.1.4.31	Implicit VR Little Endian	1.2.840.10008.1.2
Modality Worklist Information Model - FIND	1.2.840.10008.5.1.4.31	Explicit VR Little Endian	1.2.840.10008.1.2.1
Modality Performed Procedure Step	1.2.840.10008.3.1.2.3.3	Implicit VR Little Endian	1.2.840.10008.1.2
Modality Performed Procedure Step	1.2.840.10008.3.1.2.3.3	Explicit VR Little Endian	1.2.840.10008.1.2.1
Storage Commitment Push Model	1.2.840.10008.1.20.1	Implicit VR Little Endian	1.2.840.10008.1.2
Storage Commitment Push Model	1.2.840.10008.1.20.1	Explicit VR Little Endian	1.2.840.10008.1.2.1
Unified Procedure Step - Push	1.2.840.10008.5.1.4.34.6.1	Implicit VR Little Endian	1.2.840.10008.1.2
Unified Procedure Step - Push	1.2.840.10008.5.1.4.34.6.1	Explicit VR Little Endian	1.2.840.10008.1.2.1
Unified Procedure Step - Watch	1.2.840.10008.5.1.4.34.6.2	Implicit VR Little Endian	1.2.840.10008.1.2
Unified Procedure Step - Watch	1.2.840.10008.5.1.4.34.6.2	Explicit VR Little Endian	1.2.840.10008.1.2.1
Unified Procedure Step - Pull	1.2.840.10008.5.1.4.34.6.3	Implicit VR Little Endian	1.2.840.10008.1.2
Unified Procedure Step - Pull	1.2.840.10008.5.1.4.34.6.3	Explicit VR Little Endian	1.2.840.10008.1.2.1
Unified Procedure Step - Event	1.2.840.10008.5.1.4.34.6.4	Implicit VR Little Endian	1.2.840.10008.1.2
Unified Procedure Step - Event	1.2.840.10008.5.1.4.34.6.4	Explicit VR Little Endian	1.2.840.10008.1.2.1
Instance Availability Notification	1.2.840.10008.5.1.4.33	Implicit VR Little Endian	1.2.840.10008.1.2
Instance Availability Notification	1.2.840.10008.5.1.4.33	Explicit VR Little Endian	1.2.840.10008.1.2.1

N.1.2.4 Query/Retrieve

Table N.1-6 lists all supported Query/Retrieve SOP Classes.

[Table N.1-6 lists some SOP Classes for querying and retrieving from a remote DICOM node, nevertheless PS3.4 defines many more additional SOP Classes for querying and retrieving. If your product supports any of these additional SOP Classes (e.g., any of the SOP Classes supporting C-GET), add them to Table N.1-6 and delete the SOP Classes not supported by your product. If you neither support a SOP Class as SCU or SCP, remove the respective line from Table N.1-6.]

Table N.1-6. Query/Retrieve SOP Classes

SOP Classes		Transfer Syntax
Patient Root Query/Retrieve Information Model - FIND	1.2.840.10008.5.1.4.1.2.1.1	Implicit VR Little Endian	1.2.840.10008.1.2
Patient Root Query/Retrieve Information Model - FIND	1.2.840.10008.5.1.4.1.2.1.1	Explicit VR Little Endian	1.2.840.10008.1.2.1
Study Root Query/Retrieve - Information Model - FIND	1.2.840.10008.5.1.4.1.2.2.1	Implicit VR Little Endian	1.2.840.10008.1.2
Study Root Query/Retrieve - Information Model - FIND	1.2.840.10008.5.1.4.1.2.2.1	Explicit VR Little Endian	1.2.840.10008.1.2.1
Patient Root Query/Retrieve - Information Model - MOVE	1.2.840.10008.5.1.4.1.2.1.2	Implicit VR Little Endian	1.2.840.10008.1.2
Patient Root Query/Retrieve - Information Model - MOVE	1.2.840.10008.5.1.4.1.2.1.2	Explicit VR Little Endian	1.2.840.10008.1.2.1
Study Root Query/Retrieve - Information Model - MOVE	1.2.840.10008.5.1.4.1.2.2.2	Implicit VR Little Endian	1.2.840.10008.1.2
Study Root Query/Retrieve - Information Model - MOVE	1.2.840.10008.5.1.4.1.2.2.2	Explicit VR Little Endian	1.2.840.10008.1.2.1

N.1.2.5 Printing

Table N.1-7 lists all supported Printing SOP Classes.

[Table N.1-7 lists some SOP Classes for Printing and PS3.4 defines additional SOP Classes for printing. If your product supports any of these additional SOP Classes, add them to Table N.1-7, and remove any rows that do not apply to your product. If you neither support a SOP Class as SCU nor SCP, remove the respective line from Table N.1-7.]

Table N.1-7. Printing SOP Classes

SOP Classes		Transfer Syntax
Basic Grayscale Print Management Meta	1.2.840.10008.5.1.1.9	Implicit VR Little Endian	1.2.840.10008.1.2
Basic Grayscale Print Management Meta	1.2.840.10008.5.1.1.9	Explicit VR Little Endian	1.2.840.10008.1.2.1
Basic Color Print Management Meta	1.2.840.10008.5.1.1.18	Implicit VR Little Endian	1.2.840.10008.1.2
Basic Color Print Management Meta	1.2.840.10008.5.1.1.18	Explicit VR Little Endian	1.2.840.10008.1.2.1
Basic Annotation Box	1.2.840.10008.5.1.1.15	Implicit VR Little Endian	1.2.840.10008.1.2
Basic Annotation Box	1.2.840.10008.5.1.1.15	Explicit VR Little Endian	1.2.840.10008.1.2.1
Print Job	1.2.840.10008.5.1.1.14	Implicit VR Little Endian	1.2.840.10008.1.2
Print Job	1.2.840.10008.5.1.1.14	Explicit VR Little Endian	1.2.840.10008.1.2.1
Presentation LUT	1.2.840.10008.5.1.1.23	Implicit VR Little Endian	1.2.840.10008.1.2
Presentation LUT	1.2.840.10008.5.1.1.23	Explicit VR Little Endian	1.2.840.10008.1.2.1
Printer Configuration Retrieval	1.2.840.10008.5.1.1.17.376	Implicit VR Little Endian	1.2.840.10008.1.2
Printer Configuration Retrieval	1.2.840.10008.5.1.1.17.376	Explicit VR Little Endian	1.2.840.10008.1.2.1

N.1.3 DICOM Web Services

N.1.3.1 URI Service (WADO-URI)

Table N.1-8 lists details on the support of the URI Service.

[Complete Table N.1-8 to indicate support for the URI Web Service.]

Table N.1-8. URI Service

Service	Transaction	User Agent	Origin Server
URI Web Service (WADO-URI)	Retrieve DICOM Instances
URI Web Service (WADO-URI)	Retrieve Rendered Instance

For resources supported see Table N.1-1 in Section N.1.1

N.1.3.2 Studies Service

Table N.1-9 lists details on the support of the Studies Service.

[Complete Table N.1-9 to indicate support for the Studies Web Service]

Table N.1-9. Study Service

Service	Transaction	Resource
Studies Web Service	Retrieve Capabilities
	Retrieve (WADO-RS)	Study
		Study Metadata
		Study Bulkdata
		Study Pixel Data
		Rendered Study
		Study Thumbnail
		Series
		Series Metadata
		Series Bulkdata
		Series Pixel Data
		Rendered Series
		Series Thumbnail
		Instance
		Instance Metadata
		Instance Bulkdata
		Instance Pixel Data
		Rendered Instance
		Instance Thumbnail
		Frames
		Rendered Frames
		Frame Thumbnail
		Bulkdata
	Search (QIDO-RS)	All Studies
		Study
		Study's Series
		Study's Instances
		All Series
		Series
		Series Instances
		All Instances
		Instance
	Store (STOW-RS)	All Studies
		Study
		Bulkdata

N.1.3.3 Worklist Service

Table N.1-10 lists details on the support of the Worklist Service.

[Complete Table N.1-10 to indicate support for the Worklist Web Service.]

Table N.1-10. Worklist Service

Service	Transaction	Resource
Worklist Web Service (UPS-RS)	Retrieve Capabilities
	Create Workitem	Worklist
	Create Workitem	Workitem
	Update Workitem	Workitem
	Retrieve Workitem	Workitem
	Change Workitem State	Workitem
	Request Cancellation	Workitem
	Search	Worklist
	Subscribe	Worklist
		Filtered Worklist
		Workitem
	Unsubscribe	Worklist
		Filtered Worklist
		Workitem
	Suspend Global Subscription	Worklist
	Suspend Global Subscription	Filtered Worklist
	Workitem Event Report

N.1.3.4 Non-Patient Instance Service

Table N.1-11 lists details on the support of Non-Patient Instances Service.

For details on the supported resource categories (e.g., Color Palette, Defined Procedure Protocol, Hanging Protocol or Implant Templates), see Table N.1-1.

[Complete Table N.1-11 to indicate support for the Non-Patient Instance Web Service.]

Table N.1-11. Non-Patient Instance Service

Service	Transaction	Resource	User Agent	Origin Server
Non-Patient Instances Web Service	Retrieve Capabilities
	Retrieve
	Store
	Search (Note)

N.1.4 Media Services

Table N.1-12 lists all supported Media Application Profiles.

[Table N.1-12 lists Media Storage Application profiles and supported roles. Extend/modify the Table to list the profiles supported by your system.]

Table N.1-12. Supported Media Application Profiles

Media Storage Application Profile	FSC	FSR	FSU
Compact Disk - Recordable
STD-GEN-CD
AUG-GEN-CD

DVD
AUG-GEN-DVD-JPEG
AUG-GEN-DVD-J2K
STD-GEN-DVD-JPEG
STD-GEN-DVD-J2K

USB
AUG-GEN-USB-J2K
STD-GEN-USB-J2K

N.1.5 Real Time Video Service

Table N.1-13 lists all supported Real-Time Video SOP Classes and Transfer Syntaxes.

[List all supported Real-Time Video SOP Classes in Table N.1-13. For the "Transfer Syntax Set" column use Transfer Syntax Sets defined in Table N.1-2.]

Table N.1-13. Supported Real-Time Video SOP Classes

SOP Classes		Transfer Syntax Set	RTV
SOP Classes		Transfer Syntax Set	SCU	SCP
Video Endoscopic Image Real-Time Communication	1.2.840.10008.10.1	RTV
Video Photographic Image Real-Time Communication	1.2.840.10008.10.2	RTV
Audio Waveform Real-Time Communication	1.2.840.10008.10.3	RTV
Rendition Selection Document Real-Time Communication	1.2.840.10008.10.4	N/A

N.1.6 De-identification Profiles

Table N.1-14 lists all supported de-identification profiles and options.

[Complete Table N.1-14 to list supported De-Identification profiles and options. If you do not support de-identification, remove this table, and mark section as N/A]

Table N.1-14. De-Identification Profiles

Profile	Option
Basic Application-Level Confidentiality Profile	Clean Pixel Data Option
Basic Application-Level Confidentiality Profile	Clean Structured Content Option

N.1.7 Specific Character Sets

[List all supported Character Sets and the IANA name as well as a description in Table N.1-15.]

Table N.1-15. Supported Specific Character Sets

Defined Term	IANA	Description
Single-Byte Character Sets without Code Extensions
ISO_IR 6	ISO-646	Default Repertoire
ISO_IR 100	ISO-8859-1	Latin Alphabet No.1 (West Europe)

Single-Byte Character Sets with Code Extension
ISO 2022 IR 100		Latin Alphabet No. 1 (West Europe)

Multi-Byte Character Sets without Code Extensions
GB18030	GB18030	GB18030-2000 (P.R China Norm GB18030)

Multi-Byte Character Sets with Code Extensions
ISO 2022 IR 87	ISO-2022-JP	Japanese

N.2 Table of Contents

[The Table of Contents shall be provided to assist readers in easily finding the needed information.]

N.3 Introduction

N.3.1 Revision History

[Provide the revision history for this document including the document revision, the document revision date, the product version(s) the DICOM Conformance Statement applies to and give a high-level description of changes.]

Revision	Date	Product Version(s)	Change
<Revision>	<Date>	<Product Version(s)>	<Change>

N.3.2 Audience

This document is intended for the audience listed below. It is assumed that the reader has a working knowledge of the DICOM Standard.

[Below is a list of typical users of a DICOM Conformance Statement, modify and add other user groups if needed.]

The document structure was designed for easier access to relevant information for different user groups:

Clinical Users, who want to get an overview of the implemented interoperability features of the system can see Section N.4 Implementation Model.
Personnel involved in Sales can use the information in Section N.1 to assess the compatibility between different systems involved in a sales situation.
System Integrators can use information in Section N.6 during system installation and also information from Section N.5 Service and Interoperability Description for details regarding the implemented services.
Field Service Engineers can use the details from Section N.5 Service and Interoperability Description and from Section N.7 Network and Media Communication Details for troubleshooting.
Hospital IT staff focusing on security can use the details provided in Section N.8 Security regarding implemented Security features.
Research Personnel may be interested in using information provided in Section N.9 Information Object Definitions (IODs) or Section N.10 Structured Report Content Encoding to get detailed imaging and measurement information.

N.3.3 Remarks

[Any important remarks, disclaimers, and general information are specified. The following example may be used as a template.]

The scope of this DICOM Conformance Statement is to facilitate integration between < Product> and other DICOM products. The Conformance Statement should be read and understood in conjunction with the DICOM Standard [1]. DICOM by itself does not guarantee interoperability.

The Conformance Statement does, however, facilitate a first-level comparison for interoperability between different applications supporting compatible DICOM functionality.
This Conformance Statement should not replace validation with other DICOM equipment to ensure proper exchange of intended information. In fact, it is the user's responsibility to perform the following validation activities:
- The comparison of Conformance Statements from <Product> and other DICOM conformant equipment is the first step towards assessing interconnectivity and interoperability between those systems.
- Test procedures should be defined and executed to validate the required level of interoperability with specific DICOM conformant equipment, as established by the healthcare facility.

[If the product has an IHE Integration Statement, the following statement may be applicable]:

<Product> has participated in an industry-wide testing program sponsored by Integrating the Healthcare Enterprise (IHE). The IHE Integration Statement of <Product> together with the IHE Technical Framework may facilitate the process of validation testing.

N.3.4 Terms and Definitions

[Terms and definitions should be listed here. The following list includes DICOM terms, delete terms that are not used throughout the Conformance Statement, but do not add or modify terms listed here.]

The following list includes DICOM Terms, that are used throughout this Conformance Statement:

Abstract Syntax	The information agreed to be exchanged between applications, generally equivalent to a Service/Object Pair (SOP) Class. Examples: Verification SOP Class, Modality Worklist Information Model Find SOP Class, Computed Radiography Image Storage SOP Class.
Application Entity (AE)	A representation of the external behavior of an application process in terms of DICOM Network Services, Web Services and/or media exchange capabilities implemented in one or more roles. A single device may have multiple Application Entities.
Application Entity Title (AET)	The externally known name of an Application Entity, used to identify a DICOM application to other DICOM applications on the network.
Application Context	The specification of the type of communication used between Application Entities. Example: DICOM network protocol.
Association	A network communication channel set up between Application Entities.
Attribute	A unit of information in an Information Object Definition; a Data Element identified by a tag. The information may be a complex data structure (Sequence), itself composed of lower-level data elements. Examples: Patient ID (0010,0020), Accession Number (0008,0050), Photometric Interpretation (0028,0004), Procedure Code Sequence (0008,1032).
Data Element	A unit of information as defined by a single entry in the data dictionary. An encoded Information Object Definition (IOD) Attribute that is composed of, at a minimum, three fields: a Data Element Tag, a Value Length, and a Value Field. For some specific Transfer Syntaxes, a Data Element also contains a VR Field where the Value Representation of that Data Element is specified explicitly
Information Object Definition (IOD)	The specified set of Attributes that comprise a type of data object; does not represent a specific instance of the data object, but rather a class of similar data objects that have the same properties. Examples: MR Image IOD, CT Image IOD, Print Job IOD. The Attributes within an IOD may be specified as Mandatory (Type 1), Required but possibly unknown (Type 2), or Optional (Type 3), and there may be conditions associated with the use of an Attribute (Types 1C and 2C).
Media Application Profile	The specification of DICOM information objects and encoding exchanged on removable media (e.g., CDs).
Module	A set of Attributes within an Information Object Definition that are logically related to each other. Example: Patient Module includes Patient's Name, Patient ID, Patient' Birth Date, and Patient's Sex.
Negotiation	First phase of Association establishment that allows Application Entities to agree on the types of data to be exchanged and how that data will be encoded.
Origin Server	Refers to the program that can originate authoritative responses to HTTP requests for a given Target Resource. The term "server" refers to any implementation that receives a web service request message from a user agent.
Presentation Context	The set of DICOM Network Services used over an Association, as negotiated between Application Entities; includes Abstract Syntaxes and Transfer Syntaxes.
Private SOP Class	A SOP Class that is not defined in the DICOM Standard but is published in an implementation's Conformance Statement.
Protocol Data Unit (PDU)	A packet (piece) of a DICOM message sent across the network. Devices must specify the maximum size packet they can receive for DICOM messages.
Security Profile	A set of mechanisms, such as encryption, user authentication, or digital signatures, used by an Application Entity to ensure confidentiality, integrity, and/or availability of exchanged DICOM data.
Service Class Provider (SCP)	Role of an Application Entity that provides a DICOM network service; typically, a server that performs operations requested by another Application Entity (Service Class User). Examples: Picture Archiving and Communication System (image storage SCP, and image query/retrieve SCP), Radiology Information System (modality worklist SCP).
Service Class User (SCU)	Role of an Application Entity that uses a DICOM Network Service; typically, a client. Examples: imaging modality (image storage SCU, and modality worklist SCU), imaging workstation (image query/retrieve SCU).
Service/Object Pair Class (SOP Class)	The specification of the network or media transfer (service) of a particular type of data (object) ; the fundamental unit of a DICOM interoperability specification. Examples: Ultrasound Image Storage Service, Basic Grayscale Print Management.
Service/Object Pair Instance (SOP Instance)	An information object; a specific occurrence of information exchanged in a SOP Class. E.g., a specific X-ray image.
Specialized SOP Class	A SOP Class that is derived from the Standard that is specialized by additional type 1, 1C, 2, 2C, or 3 Attributes, by enumeration of specific permitted Values for Attributes, or by enumeration of specific permitted Templates. The additional Attributes may either be drawn from the Data Dictionary in PS3.6 or may be Private Attributes.
Standard SOP Class	A SOP Class defined in the Standard, and that is implemented and used without any modifications.
Standard Extended SOP Class	A SOP Class that is defined in the standard, and that is extended by additional type 3 Attributes. The additional Attributes may either be drawn from the DICOM Data Dictionary in PS3.6 or may be Private Attributes.
Tag	A 32-bit identifier for a Data Element, represented as a pair of four-digit hexadecimal numbers, the "group" and the "element". If the "group" number is odd, the tag is for a private (manufacturer-specific) data element. Examples: (0010,0020) [Patient ID], (07FE,0010) [Pixel Data], (0019,0210) [private data element].
Transfer Syntax	The encoding used for exchange of DICOM information objects and messages. Examples: JPEG compressed (images), Little Endian Explicit Value Representation.
TLS-Secured Port	TCP port on which an implementation accepts TLS connections to exchange DICOM information.
Unique Identifier (UID)	A globally unique "dotted decimal" string that identifies a specific object or a class of objects; an ISO-8824 Object Identifier. Examples: Study Instance UID, SOP Class UID, SOP Instance UID.
User Agent	A client in a network protocol used in communications within a client-server distributed computing system. In particular, the Hypertext Transfer Protocol (HTTP) identifies the client software originating the request, using a user-agent header, even when the client is not operated by a user.
Value Representation (VR)	The format type of an individual DICOM data element, such as text, an integer, a person's name, or a code. DICOM information objects can be transmitted with either explicit identification of the type of each data element (Explicit VR), or without explicit identification (Implicit VR) ; with Implicit VR, the receiving application must use a DICOM data dictionary to look up the format of each data element.

[Modify: Add a list of product specific definitions here. If none are needed remove the following introduction and table]

The following list includes product specific definitions used throughout this Conformance Statement

Product-specific Term

This is a product specific term used throughout this Conformance Statement

N.3.5 Abbreviations

Abbreviations that are used in this DICOM Conformance Statement are listed here.

[It is important to add any additional terms used by the implementation. Terms in the list may also be deleted at the discretion of the implementer.]

AE	Application Entity
AET	Application Entity Title
CAD	Computer Aided Detection
CDA	Clinical Document Architecture
CID	Context Identifier
DCS	DICOM Conformance Statement
DHCP	Dynamic Host Configuration Protocol
DICOM	Digital Imaging and Communications in Medicine
ELE	Explicit VR Little Endian
FSC	File-Set Creator
FSU	File-Set Updater
FSR	File-Set Reader
IANA	Internet Assigned Numbers Authority
IHE	Integrating the Healthcare Enterprise
ILE	Implicit VR Little Endian
IOD	Information Object Definition
IPv4	Internet Protocol version 4
IPv6	Internet Protocol version 6
ISO	International Organization for Standardization
MPPS	Modality Performed Procedure Step
MWL	Modality Worklist
NEMA	National Electrical Manufacturers Association
NTP	Network Time Protocol
OID	Object Identifier
OS	Origin Server
PDU	Protocol Data Unit
PHI	Protected Health Information
PPS	Performed Procedure Step
QIDO-RS	Query based on ID for DICOM Objects by RESTful Services
RTV	Real Time Video
SCP	Service Class Provider
SCU	Service Class User
SDP	Service Description Protocol
SOP	Service-Object Pair
SPS	Scheduled Procedure Step
SR	Structured Reporting
STOW-RS	STore Over the Web by RESTful Services
TCP/IP	Transmission Control Protocol/Internet Protocol
TID	Template Identifier
UA	User Agent
UI	User Interface
UID	Unique Identifier
UL	Upper Layer
UPS	Unified Procedure Step
UPS-RS	Unified Procedure Step by RESTful Services
VR	Value Representation
WADO-RS	Web Access to DICOM Objects by RESTful Services
WADO-URI	Web Access to DICOM Objects by URI

N.3.6 References

[Referenced documents should be listed here, including appropriate product manuals (such as service manuals that specify how to set DICOM communication parameters). References to the DICOM Standard should provide the URL for the free published version of the Standard, but should not specify a date of publication]:

[1] National Electrical Manufacturers Association (NEMA), Rosslyn, VA USA. PS3 / ISO 12052 Digital Imaging and Communications in Medicine (DICOM) Standard. http://www.dicomstandard.org .

[2] Integrating the Healthcare Enterprise (IHE). IHE Radiology Technical Framework. http://www.ihe.net/Resources/technical_frameworks/#radiology .

N.4 Implementation Model

[Provide a short description of your implementation, including list of product names and versions that this DICOM Conformance Statement (DCS) intends to cover, as well as the use of DICOM Networking, DICOM Media Interchange and DICOM Web Services to achieve their purpose.]

[Also provide some high-level details of your product architecture, which are relevant to the interoperability features of the product (e.g., implementation of functionality in separate applications).]

N.4.1 Application Entities and Data Flow

The network and media interchange application model for the < Product> is shown in Figure N.4-1 <Product> Application Data Flow Diagram.

[Edit the Application Data Flow Diagram and description below as appropriate. Note that the Real-World Activity and Application Entity names specified in the figure must be used consistently throughout the document. If your product supports configurable AE definition, then describe the default configuration of AEs in this section. As a reminder, an AE is a representation of the external behavior of an application process in terms of DICOM network services, web services and/or media exchange capabilities implemented in one or more roles. A single device may have multiple Application Entities.]

Figure N.4-1. <Product> Application Data Flow Diagram

[For each AE listed in Figure N.4-1 add one subsection A.4.1.x to describe the AE's DICOM functionality with regards to supported DIMSE, DICOM Web and Media Services, including the real-world activities that may trigger the service.]

[If your system supports flexible grouping of Services into Application Entities, keep the following paragraph, otherwise delete it]

This section describes the organization of the supported Services into Application Entities based on the default configuration of the system. This may change based on the actual setup at the customer site. See Section N.6 for details about the configurability of Services into AEs.

N.4.1.1 Functional Definition of <Application Entity 1>

[Provide a functional description of <Application Entity 1>, i.e., the DICOM Services (DIMSE, DICOM Web and Media Services), and supported roles, Real World Activities triggering the service and AE specific behavior.]

N.5 Service and Interoperability Description

N.5.1 Mapping of Services to Application Entities

Table N.5-1 provides an overview of the Application Entities and the Services supported by each AE.

[Table N.5-1 provides the mapping between Application Entities, Services and Roles as indicated in the example below.]

Table N.5-1. Service to AE Mapping

Application Entity	Supported Services	Role
		DIMSE		DICOM Web		DICOM Media			Real-Time Video
		SCU	SCP	Origin Server	User Agent	FSC	FSU	FSR	SCU	SCP
<Application Entity 1>	Basic Worklist Management
<Application Entity 1>	MPPS
<Application Entity 2>	Storage
	Storage Commitment
	Query/Retrieve
<Application Entity 3>(see Note 1)	Storage
<Application Entity 3>(see Note 1)	Query/Retrieve
<Application Entity 4>	Print Management
<Media Entity 1>	Media Storage
<RTV Entity 1>	Real-Time Video

[If needed, explain specific behavior of an AE in a note, e.g., if you have an AE that provides specifically storage of de-identified instances or support for querying rejected instances as defined in the IOCM profile, e.g.:

Note

This implementation of Query/Retrieve service handles retrieval of rejected instances as defined in the IHE Radiology IOCM Profile [2].

]

N.5.2 Supported DIMSE Services

[The following sections define the details of the supported DIMSE Services in more details. Fill in the information for all services supported by the system. Tables are given as examples and should be modified to meet the functionality of the system.]

N.5.2.1 Basic Worklist Management Service

N.5.2.1.1 SCU of the Modality Worklist Information Model - FIND SOP Class

As a Service Class User of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RQ message to query the SCP. It supports the Query Keys listed in Table N.5-2.

In the "Matching Type" column, the following Values can be used:

SINGLE_VALUE: SCU can request single Value matching on this Attribute.
UID: SCU can request List of UID matching on this Attribute.
WILDCARD: SCU can request Wildcard matching on this Attribute.
RANGE: SCU can request Range matching on this Attribute.
SEQUENCE: SCU can request sequence matching on this Attribute.
UNIVERSAL: SCU can request that the Attribute be a return Value (universal matching).

In the "Query Value Source" column, the following Values can be used:

FIXED: The query Value cannot be modified by the user or by configuration.
GENERATED: The query Value is generated by the system (e.g., current date as the study date).
CONFIGURATION: The query Value is dependent on system configuration.
USER: The query Value is entered by the user.
SCANNED: The query Value is read from a barcode scanner or similar device.
EMPTY: The query Value is sent with a zero-length Value to indicate it is a return key only.

In the "Display on UI" column the following Values can be used:

D: the return Value is displayed on the main UI by default.
C: the return Value is displayed on the main UI if configured.
N: the return Value is never displayed.

[Modify the Table N.5-2 to include all Attributes supported by your system and use the terms defined for Matching Type, Query Value Source and Display on UI above. If Display on UI Values are modified from the ones received, indicate in a footnote. If multiple Values are supported for the Query Value Source, list all of them.]

Table N.5-2. Supported C-FIND Query Parameters for Modality Worklist - SCU

Attribute Name	Tag	Matching Type	Query Value Source	Value	Display on UI	Comments
Scheduled Procedure Step
Scheduled Procedure Step Sequence	(0040,0100)	SEQUENCE
>Scheduled Station AE Title	(0040,0001)	SINGLE_VALUE	GENERATED		D	AE title of the system performing the query
>Scheduled Procedure StepStart date	(0040,0002)	RANGE	GENERATED		D	Current date and time minus 1 hour plus 24 hours ahead
>Scheduled Procedure StepStart Time	(0040,0003)	RANGE	GENERATED		D	Current date and time minus 1 hour plus 24 hours ahead
>Modality	(0008,0060)	SINGLE_VALUE	FIXED	CT
>Scheduled PerformingPhysician's Name	(0040,0006)	UNIVERSAL	EMPTY		D
…
Requested Procedure

Study Instance UID	(0020,000D)	UNIVERSAL	EMPTY
…
Imaging Service Request
Accession Number	(0008,0050)	SINGLE VALUE	USER		D	See Annex D for details
Issuer of Accession Number Sequence	(0008,0051)	UNIVERSAL	EMPTY
…
Visit Identification
…
Visit Status
…
Patient Identification
Patient's Name	(0010,0010)	WILDCARD	USER		D
…
Patient Demographics

[Describe scenarios in which the product can issue C-FIND-CANCEL requests, e.g.,

The product issues C-FIND CANCEL requests in the following scenarios:* Configurable maximum of matches detected* Initiated by user]

[Also describe the SCU behavior if the cancellation request is ignored by the SCP and the SCP continues sending responses.]

[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN).]

N.5.2.1.2 SCP of the Modality Worklist Information Model - FIND SOP Class

As a Service Class Provider of the Modality Worklist Information Model - FIND SOP Class, the <Product> uses the C-FIND-RSP to communicate matches back to the SCU. It supports the Matching Keys listed in Table N.5-3.

In the "Matching Type" column, the following Values can be used:

SINGLE_VALUE: SCP can perform single Value matching on this Attribute.
UID: SCP can perform List of UID matching on this Attribute.
WILDCARD: SCP can perform Wildcard matching on this Attribute.
RANGE: SCP can perform Range matching on this Attribute.
SEQUENCE: SCP can perform sequence matching on this Attribute.
UNIVERSAL: SCP can provide the Attribute in the C-FIND response (i.e., universal matching).

[Table N.5-3 contains a set of Attributes that could be supported by a product. Add and remove Attributes in order to match your product implementation using the matching type as defined above. If multiple codes are supported, list all of them. Use the "Comments" column if clarification is needed.]

Table N.5-3. Supported C-FIND Return Keys for Modality Worklist - SCP

Attribute Name	Tag	Matching Type
Scheduled Procedure Step
Schedule Procedure Step Sequence	(0040,0100)
>Scheduled Station AE Title	(0040,0001)	SINGLE_VALUE
>Scheduled Procedure StepStart Date	(0040, 0002)	RANGE
>Scheduled Procedure StepStart Time	(0040, 0003)	RANGE
>Modality	(0008,0060)	SINGLE_VALUE
>Scheduled PerformingPhysician's Name	(0040,0006)	WILDCARD
…
Requested Procedure
Study Instance UID	(0020,000D)	UNIVERSAL
…
Imaging Service Request
Accession Number	(0008,0050)	SINGLE_VALUE
Issuer of Accession Number Sequence	(0008,0051)	UNIVERSAL
Requesting Physician	(0032,1032)	UNIVERSAL
Referring Physician's Name	(0008,0090)	UNIVERSAL
…
Visit Identification
…
Visit Relationship
…
Patient Identification
…
Patient Demographics
…

[Describe the behavior of the product when it receives a C-FIND-CANCEL request.]

[Document your product's query capabilities and behavior for handling non-default character sets, especially for handling person names (VR of PN).]

N.5.2.2 Modality Performed Procedure Step Service

N.5.2.2.1 SCU of the Modality Performed Procedure Step SOP Class

As a Service Class User of the Modality Performed Procedure Step SOP Class, the <Product> supports the Attributes listed in Table N.5-4 in the N-CREATE-RQ and N-SET-RQ messages, if it creates the message.

In the "Source" column the following Values can be used:

FIXED: the Value is pre-defined and cannot be modified.
GENERATED: the Value is generated by the system.
CONFIGURATION: the Value is copied from system configuration.
MWL: the Value is copied from modality worklist entry.
USER: the Value is entered by the user.
SCANNED: the Value is read from a barcode scanner or similar device.
EMPTY: The Attribute is sent with a zero-length Value

[List all Attributes provided in the MPPS message and list the Values that are used to populate the N-CREATE or N-SET messages, add or remove Attributes as applicable for your product and note that in the "Source" column, multiple Values can be provided in a semicolon separated list.]

Table N.5-4. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCU

Attribute Name	Tag	Source	Value N-CREATE	Value N-SET
Specific Character Set	(0008,0005)	FIXED	ISO_IR 100	ISO_IR 100
Performed Procedure Step Relationship
Scheduled Step Attribute Sequence	(0040,0270)
>Study Instance UID	(0020,000D)	MWL
>Accession Number	(0008,0050)	MWL; USER; EMPTY
>Issuer of Accession Number Sequence	(0008,0051)	MWL; GENERATED
…
Patient's Name	(0010,0010)	MWL; USER
Patient ID	(0010,0020)	MWL; GENERATED
…
Performed Procedure Step Information
Performed Procedure Step ID	(0040,0253)
…
Performed Procedure Step Status	(0040,0252)	GENERATED	DISCONTINUED
Performed Procedure Step Discontinuation Reason Code Sequence		GENERATED		[Either reference CID 9301 or provide the supported Code Set, if the Performed Procedure Step Status is set to DISCONTINUED]
…
Image Acquisition Results
Modality	(0008,0060)	GENERATED	CT
Study ID	(0020,0010)	GENERATED	Copied from Requested Procedure ID
Performed Protocol Code Sequence	(0040,0260)	GENERATED
…

[Describe the triggers by which your product initiates sending messages, e.g., the N-CREATE is sent when starting image acquisition and N-SET is sent when the study is closed.]

[If product also supports forwarding of MPPS messages (e.g., as described by the MPPS Manager Actor in the IHE Schedule Workflow profile), provide a description of the product behavior here.]

N.5.2.2.2 SCP of the Modality Performed Procedure Step SOP Class

As a Service Class Provider of the Modality Performed Procedure Step SOP Class, the product receives N-CREATE-RQ and N-SET-RQ messages from a remote SCU indicating the status of a procedure.

[Indicate in Table N.5-5 whether your product has specific requirements with regards to the message content, e.g., whether specific Attributes are required using Y for yes and N for no.]

Table N.5-5 lists the message content that is required.

Table N.5-5. Supported N-CREATE and N-SET Attributes for Modality Performed Procedure Step - SCP

Attribute Name	Tag	Required in N-CREATE	Required in N-SET	Comments
Specific Character Set	(0008,0005)
Performed Procedure Step Relationship
Scheduled Step Attribute Sequence	(0040,0270)
>Study Instance UID	(0020,000D)
>Accession Number	(0008,0050)
>Issuer of Accession Number Sequence	(0008,0051)
Patient Name	(0010,0010)
Patient ID	(0010,0020)
…
Performed Procedure Step Information
Performed Procedure Step ID	(0040,0253)
Performed Procedure Step Discontinuation Reason Code Sequence	(0040,0281)
…
Image Acquisition Results
Modality	(0008,0060)
Study ID	(0020,0010)
Performed Protocol Code Sequence	(0040,0260)
…

[Describe the behavior of the product upon receiving an MPPS message, both the N-CREATE and the N SET.]

N.5.2.3 Unified Worklist and Procedure Step Service

[If your product supports any of the Unified Worklist SOP Classes, list the supported SOP Classes, the role, a list of supported messages, and the content of each supported message. If one or more of the Unified Worklist SOP Classes are not supported, keep the section, but include text indicating the SOP Class is "N/A".]

N.5.2.4 Instance Availability Notification Service

N.5.2.4.1 SCU of the Instance Availability Notification SOP Class

As a Service Class User of the Instance Availability Notification SOP Class, the system uses the N-CREATE-RQ message to inform remote SCPs about the availability and status of instances stored. Details of the message content are summarized in Table N.5-6.

In the "Source" column the following Values can be used:

FIXED: The Value is predefined and cannot be modified by data entry or by configuration.
GENERATED: The Value is generated by the system (e.g., current date as the study date).
CONFIGURATION: The Value is dependent on system configuration.
IMAGE: The Value is copied from the SOP Instance.
MWL: The Value is copied from Modality Worklist entry.
MPPS: The Value is copied from the MPPS message.

[Table N.5-6 lists some Attribute for instance availability notification as examples. Complete table with Attributes supported by your product. For the "Source" column use Values as defined above.]

Table N.5-6. Supported N-CREATE Attributes for Instance Availability Notification - SCU

Attribute Name	Tag	Source	Value
Specific Character Set	(0008,0005)	FIXED	ISO_IR 100
Referenced Performed Procedure Step Sequence	(0008,1111)	GENERATED
>…	(0008,1150)
>Performed Workitem Code Sequence	(0040,4019)	GENERATED
>>…
Study Instance UID	(0020,000D)	IMAGE
Referenced Series Sequence	(0008,1115)	IMAGE
>Series Instance UID	(0020,000E)	IMAGE
>Referenced SOP Sequence	(0008,1199)	IMAGE
>>…
>>Instance Availability	(0008,0056)	GENERATED	See Table N.5-7
>>Retrieve AE Title	(0008,0054)	CONFIGURATION
…

The <Product> supports the Values listed in Table N.5-7, for the Instance Availability (0018,0056) Attribute.

[Fill in Table N.5-7 with Values supported for the Instance Availability Attribute and define the meaning of these Values in the context of your <Product>]

Table N.5-7. Meaning of Instance Availability Values- SCU

Value	Meaning
ONLINE
NEARLINE
OFFLINE
UNAVAILABLE

[Describe the mechanism that triggers sending of an Instance Availability Notification, the frequency and retrieve capabilities for referenced instances.]

[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported.]

N.5.2.4.2 SCP of the Instance Availability Notification SOP Class

As a Service Class Provider of the Instance Availability Notification SOP Class, the system receives the N-CREATE-RQ message containing information on the availability and status of instances stored.

Table N.5-8 describes the behavior of <Product> when encountering one of the following Values for the Instance Availability (0018,0056) Attribute.

[Fill in the table with Values supported for the Instance Availability Attribute and define the policies of the product upon encountering these Values.]

Table N.5-8. Behavior on Instance Availability Values -SCP

Value	Behavior
ONLINE
NEARLINE
OFFLINE
UNAVAILABLE

[Describe the relationship between the Instance Availability Notification and Performed Procedure Step SOP Class, if both are supported and if a relationship exists.]

N.5.2.5 Storage Service

N.5.2.5.1 SCU of the Storage SOP Classes

As a Service Class User of the Storage Service Class, the <Product> uses the C-STORE-RQ message to request storage of DICOM objects by a remote SCP. See Section N.1.1 Content and Transfer in the Overview for the list of supported SOP Classes.

For details regarding the content of SOP Instances that are created by the system, see Section N.9, which describes the underlying IOD of the supported SOP Classes.

[Provide some details regarding the triggering of storage requests (e.g., automatically when an instance is stored, automatically when the study is closed, or initiated by the user).]

[Describe when and how your product divides sets of instances into multiple series and or studies and how these are ordered.]

[Describe the behavior of your product in the case of a C-STORE operation using a referenced pixel data Transfer Syntax such as JPIP Referenced Pixel Data Transfer Syntax. This includes the duration of validity of the reference.]

N.5.2.5.1.1 Transcoding of Transfer Syntaxes

[For implementations that store locally using multiple Transfer Syntaxes and if the SCU includes multiple Transfer Syntaxes in each Presentation Context it negotiates, the following can provide a useful summary for assessing compatibility with receiving systems. If this information is not useful for your product, replace the content of this Section with the text "N/A" and append "- N/A" to the end of the section title.]

Table N.5-9 describes supported transcodings between the locally stored encoding of SOP Instances and the negotiated Transfer Syntax. The following Values can be used:

SUPPORTED: Transcoding is possible and same SOP Instance UID is re-used.
NEW_UID: Transcoding is possible; however a new SOP Instance is created for transfer, e.g., due to lossy compression.
NOT_SUPPORTED: Transcoding is not possible.

[Table N.5-9 shows an example of how this transcoding could look, modify and add columns and rows as needed for Transfer Syntaxes supported by your product. If you need to provide further details on specific transcoding those can be added as notes below the table.]

Table N.5-9. Transcoding of Transfer Syntaxes

Stored Transfer Syntax	Sent Transfer Syntax
Stored Transfer Syntax	Implicit VR Little Endian	Explicit VR Little Endian	JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14)	JPEG Baseline (Process 1)	…
Implicit VR Little Endian		SUPPORTED (See Note 1)	SUPPORTED	NEW_UID
Explicit VR Little Endian	SUPPORTED		SUPPORTED	NEW_UID
JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14)	SUPPORTED	SUPPORTED		NEW_UID
JPEG Baseline (Process 1)	NOT_SUPPORTED	NOT_SUPPORTED	NOT_SUPPORTED
ACME Private Transfer Syntax 1 (See Note 2)	NOT_SUPPORTED	SUPPORTED	NOT_SUPPORTED	NOT_SUPPORTED
…

Note

Explanation of the details of the transcoding (e.g., for known Private Attributes, the correct VR will be used. All others will be encoded as VR UN)
This Private Transfer Syntax is using Explicit VR Little Endian with compressed pixel data.

N.5.2.5.2 SCP of the Storage SOP Classes

As a Service Class Provider of the Storage Service Class, the <Product> receives the C-STORE-RQ message from remote SCUs. See Section N.1.1 Content and Transfer in the Overview for the list of supported SOP Classes.

Table N.5-10 defines the conformance levels of <Product>.

Table N.5-10. Levels of Conformance

Levels of Conformance	<<0, 1, or 2>>
Level of Digital Signature Support	<<1, 2, or 3>>

The <Product> coerces the Attributes listed in Table N.5-11 upon receiving them from other systems.

The "SOP Class UID" column indicates whether the coercion is applicable to specific SOP Classes or to "ALL" SOP Classes.

The "Type of Change" column defines the coercion done to the Attributes, the following Values can be used:

MODIFIED: The Value of the Attribute is changed; the new Value is described in the "New Value" column.
ADDED: The Attribute is added with the Value defined in the "New Value" column.
REMOVED: That Attribute is completely removed from the instance.

The "Condition" column defines the condition under which coercion is performed. The following Values can be used:

ALWAYS: Data coercion is performed on each instance of the specified SOP Class that is received by the system.
EXTERNAL: Data coercion is performed on instances received from systems external to the institution.
CONFIGURATION: Data coercion is performed based on system configuration.
OTHER: Data coercion is performed for other conditions. Details are defined in the "Comments" column.

[Table N.5-11 defines some examples on which data coercion can be performed. Add/remove scenarios as they apply to your product implementation. In case you use OTHER as a condition, the "Comments" column must be used to define the condition in further detail. It is recommended to include Attributes that are coerced in the Modified Attributes Sequence (0400,0550) of the Original Attributes Sequence (0400,0561), which is documented in Section N.9.1.1.]

Table N.5-11. Attribute Coercion by Storage SCP

Attribute Name	Tag	SOP Class UID	Type of Change	New Value	Condition	Comments
Patient ID	(0010,0020)	ALL	MODIFIED	Local Patient ID	EXTERNAL
Issuer of Patient ID	(0010,0021)	ALL	ADDED	Local site as Issuer	ALWAYS
Lossy Image Compression	(0028,2110)	ALL	ADDED	01	CONFIGURATION	If lossy compression is enabled on system
Patient Name	(0010,0010)	CT Image Storage (1.2.840.10008.5. 1.4.1.1.2)	MODIFIED	Pat_xxx (where xxx is a sequential number)	OTHER	Studies received through CLINICALTRIAL AE
…

Table N.5-12 lists any limitations on displaying or processing instances, e.g., display or processing of the respective SOP Instances is prevented by an unsupported Value for an Attribute or the absence of that Attribute.

[When a Limitation is based on multiple Attributes (e.g., images cannot be displayed, if they are lossless compressed and encoded as Photometric Interpretation RGB), the Attributes are listed each in a row and the "Comments" and "Effect" cells are merged as shown in the example below. The "Comments" column is used to explain as necessary. Also use this mechanism when documenting restrictions based on Private Attributes, e.g., list the Private Creator attribute as well as the Private Attribute.]

The "Effect" column describes what happens if the limitation is encountered. The following Values are used:

ND: Display is not possible
LD: Display is limited
NP: Processing is not possible
LP: Processing is limited
OT: Other effects described in the "Comments" column

[If there are no restrictions on display or processing requirements, replace the sentence above with No restriction to display or post processing apply.]

Table N.5-12. Display and Processing Limitations for Storage SCP

Limitation Case			Effect	Comments
Attribute Name	Tag	Value	Effect	Comments
CT Image Storage (1.2.840.10008.5.1.4.1.1.2)
Bits Stored	(0028,0101)	16	ND
Digital Mammography X-Ray Image - Storage for Processing (1.2.840.10008.5.1.4.1.1.1.2.1)
Detector ID	(0018,700A)	ABSENT	NP	Value needs to be present for Licensing purposes
MR Image Storage (1.2.840.10008.5.1.4.1.1.4)
Private Creator	(0009,00xx)	MyCompanyPrivateCreator	LD	Different Diffusion directions and B Factors are not recognized for Diffusion Images
Diffusion B Factor	(0009,xx01)	ABSENT
Diffusion Direction	(0009,xx02)	ABSENT
All SOP Classes
Transfer Syntax UID	(0002,0010)	1.2.840.10008.1.2.4.70	ND	Lossless compressed RGB images cannot be displayed
Photometric Interpretation	(0028,0004)	RGB	ND	Lossless compressed RGB images cannot be displayed

Table N.5-13 lists the actions performed upon receiving instances from a remote AE and the system behavior when certain conditions are encountered

[Fill in Table N.5-13 for details. The Table shows some examples which can be reused, modified, deleted, or extended based on your product implementation]

Table N.5-13. Behavior when storing Instances

Action upon Receiving	Condition	System Behavior
Perform Attribute Validation	Minor DICOM inconsistencies	Fix error and log warning message: Incorrect characters are replaced with "?" Attributes exceeding length of VR are truncated Type 2 Attributes not present are inserted with zero length
	Duplicate Instance	<Reject/Overwrite/Ignore> Instances
	DICOM Validation error	Send failure code on Association
	Success	Instances are stored in an internal database
Add to an existing study	Mismatch in patient identifying information detected	Instances are stored in an exception queue
Add to an existing study	Success	Instances are stored in a local database
Localize Patient Information	Patient mismatch detected	Instances are stored in an exception queue
Localize Patient Information	Success	Original patient identity information is copied to Other Patient ID Sequence (0010,1002) Instances are stored in an internal database.
Coerce non-patient-identifying Attributes	Success	Original Values of coerced Attributes are copied to the Original Attributes Sequence (0040,0561). Instances are stored in a local database
Evaluate Key Object Selection Document Title	Manifest	Use referenced data for cross-enterprise document sharing (IHE XDS-I).
	Rejected for Quality Reasons Rejected for Patient Safety Reasons	Only provide instances referenced in retrieval on a specialized AE title
	Incorrect Modality Workflist Entry	Hide instances from display and never provide in retrieve requests
	All other document titles	Display key images according to the specified title
…

Table N.5-14 describes how the SCP handles compression for stored instances.

The following Values are used in the "Behavior" column:

AS_IS: Images are stored as received.
CONFIGURATION: Images are compressed based on internal configuration settings.
OTHER: All other conditions, which are further described in the "Comments" column.

The Transfer Syntax is used to describe the compression mechanism applied.

Table N.5-14. Image Compression by Storage SCP

SOP Class		Behavior	Transfer Syntax
Digital Mammography X-Ray Image Storage - For Processing	1.2.840.10008.5.1.4.1.1.1.2.1	CONFIGU-RATION	JPEG Lossless, Non-Hierarchical, First-Order Prediction (Process 14 [Selection Value 1])	1.2.840.10008.1.2.4.70
Video Photographic Image Storage	1.2.840.10008.5.1.4.1.1.77.1.4.1	CONFIGURATION	JPEG Baseline (Process 1)	1.2.840.10008.1.2.4.50
All other SOP Classes		AS_IS

[Describe the mechanism by which additional SOP Classes are dynamically supported.]

[Describe storage details noted in PS3.4 Section B.4.3.2.]

N.5.2.6 Storage Commitment Service

N.5.2.6.1 SCU of the Storage Commitment SOP Class

As a Service Class User of the Storage Commitment SOP Class, the <Product> uses the N-ACTION-RQ message to request storage commitment from a remote SCP. In turn, it receives N-EVENT-REPORT-RQ messages from the SCP indicating success or failure of the request.

[Provide a list of Storage SOP Classes for which the product requests storage commitment. Also indicate whether this is configurable.]

[If Storage Commitment is provided for all supported SOP Classes, you can provide a reference to the list of supported Storage SOP Classes in Section N.1.1]

As a Service Class User of the Storage Commitment Push Model SOP Classes the product supports committing all Storage SOP Classes listed in Section N.1.1 Content and Transfer are supported.

[If Storage Commitment is provided for a subset of all supported Storage SOP Classes, provide a list of those, and delete the paragraph above.]

[Specify whether your product supports the Storage Media File Set ID and UID Attributes in the N-ACTION-Request. If this is supported, also list the Media Application profiles supported in this context.]

[Describe whether your product supports receiving the N-EVENT-REPORT request on the same Association as the N-ACTION.]

[Document the Behavior of <product> upon receiving an N-EVENT-REPORT with an Event Type ID of 1, e.g.

Upon receiving an N-EVENT-REPORT with an Event Type of 1 Instances will be removed from system after a configurable amount of time or if space is needed]

Table N.5-15 lists the behavior of <Product> for each possible Failure Reason (0008,1197) in the Failed SOP Sequence (0008,1198) upon receiving an N-EVENT-REPORT request from the SCP with an Event Type ID of 2 (Storage Commitment Request Complete - Failures Exist).

[Fill in the behavior of your product upon encountering the Status Code. Note that for each code, that is listed in the table, a behavior needs to be provided. If your system does not support specific codes, list "Code is ignored by the system".]

Table N.5-15. Failure Behavior for Storage Commitment SCU

Status Code	Description	Behavior
0110	Processing failure: A general failure in processing the operation was encountered.	The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances
0112	No such object instance: One or more of the elements in the Referenced SOP Instance Sequence was not available.	The instance is re-sent, and the N-ACTION request is repeated.
0119	Class / Instance conflict: The SOP Class of an element in the Referenced SOP Instance Sequence did not correspond to the SOP Class registered for this SOP Instance at the SCP.	Code is ignored by the system
0122	Referenced SOP Class not supported: Storage Commitment has been requested for a SOP Instance with a SOP Class that is not supported by the SCP.	The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances
0131	Duplicate Transaction UID: The Transaction UID of the Storage Commitment Request is already in use.	The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances
0213	Resource limitation: The SCP does not currently have enough resources to store the requested SOP Instance(s).	The request for storage commitment is marked as failed. A warning is displayed if the user tries to delete affected instances

[Describe your product behavior in case the N-EVENT-REPORT request is not received after a specific time, e.g., <Product> expects to receive the N-EVENT-REPORT request in a configurable time frame after the N-ACTION is sent. If the N-EVENT-REPORT is not received within this configurable timeframe it repeats the N-ACTION-REQUEST.]

[Describe the policies for deleting instances from your product, both upon successful storage commitment as well as in failure scenarios.]

N.5.2.6.2 SCP of the Storage Commitment SOP Class

As a Service Class Provider of the Storage Commitment SOP Class, the <Product> receives the N-ACTION-RQ message to request storage commitment from a remote SCU. In turn it initiates the N-EVENT_REPORT-RQ messages to the SCU indicating success or failure of the request.

[Describe whether your product supports sending the N-EVENT-REPORT request on the same Association as the N-ACTION.]

Table N.5-16 lists conditions upon which an error code is sent in the Failure Reason (0008,1197) Attribute in the Failed SOP Sequence (0008,1198) of the N-EVEN-REPORT request.

[Fill in th